[PATCH 4/4] drm: Resurrect atomic rmfb code, v2

[Sinclair Yeh]

On Wed, Jan 25, 2017 at 09:36:36AM +0100, Maarten Lankhorst wrote:
> Op 25-01-17 om 09:09 schreef Thomas Hellstrom:
> > On 01/25/2017 05:54 AM, Daniel Vetter wrote:
> >> On Tue, Jan 24, 2017 at 01:44:54PM -0800, Matt Roper wrote:
> >>> On Wed, Jan 11, 2017 at 05:15:47PM +0100, Daniel Vetter wrote:
> >>>> On Thu, Dec 15, 2016 at 03:29:45PM +0100, Maarten Lankhorst wrote:
> >>>>> From: Daniel Vetter <daniel.vetter at ffwll.ch>
> >>>>>
> >>>>> This was somehow lost between v3 and the merged version in Maarten's
> >>>>> patch merged as:
> >>>>>
> >>>>> commit f2d580b9a8149735cbc4b59c4a8df60173658140
> >>>>> Author: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> >>>>> Date:   Wed May 4 14:38:26 2016 +0200
> >>>>>
> >>>>>     drm/core: Do not preserve framebuffer on rmfb, v4.
> >>>>>
> >>>>> Actual code copied from Maarten's patch, but with the slight change to
> >>>>> just use dev->mode_config.funcs->atomic_commit to decide whether to
> >>>>> use the atomic path or not.
> >>>>>
> >>>>> v2:
> >>>>> - Remove plane->fb assignment, done by drm_atomic_clean_old_fb.
> >>>>> - Add WARN_ON when atomic_remove_fb fails.
> >>>>> - Always call drm_atomic_state_put.
> >>>>>
> >>>>> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> >>>>> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> >>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> >>>> Would be great if someone else could r-b this, I've proven pretty well
> >>>> that I don't understand the complexity here :(
> >>>> -Daniel
> >>> It looks like this will change the behavior slightly in that rmfb will
> >>> cause primary planes to be disabled, but no longer cause the entire CRTC
> >>> to be turned off.  You'll probably want to note that in the commit
> >>> message, along with the justification on why this is okay ABI-wise.
> >>>
> >>> I know that 13803132818c ("drm/core: Preserve the framebuffer after
> >>> removing it.") was initially trying to not only leave the CRTC on, but
> >>> also preserve the framebuffer and leave the planes on; that wound up
> >>> causing some kind of regression for vmwgfx, but I'm unclear on the
> >>> details there.  I'd suggest getting an Ack from one of the vmware guys
> >>> to ensure that the less drastic change in behavior here won't cause them
> >>> any problems.
> > The vmware Xorg driver is currently relying on rmfb to turn all attached
> > crtcs off. Even if we were to fix that in the Xorg driver now, older
> > Xorgs with newer kernels still would break.
> Is it allowed for vmwgfx to keep the crtc enabled, but the primary plane disabled?
> 
> If so, when vmwgfx is eventually converted to atomic then we need to special-case rmfb for them somehow.

FYI, we are in the process of converting things to atomic.  This may happen
around 4.12