[PATCH 7/7] drm: Resurrect atomic rmfb code

[Maarten Lankhorst]

Op 09-12-16 om 21:59 schreef Daniel Vetter:
> On Fri, Dec 09, 2016 at 03:19:44PM +0100, Daniel Vetter wrote:
>> 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.
>>
>> FIXME: This seems to break audio rpm refcounting somehow! See:
>>
>> commit 0dcac5008fcf57cce66ef091204efbde86956c7a
>> Author: Daniel Vetter <daniel.vetter at ffwll.ch>
>> Date:   Thu Jul 14 15:16:34 2016 +0200
>>
>>     Revert "drm: Resurrect atomic rmfb code"
>>
>> v2: Use new atomic state refcounting.
>>
>> Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
>> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>> Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-24-git-send-email-daniel.vetter@ffwll.ch
> intel-gfx CI told me this breaks the world. I guess back to the drawing
> board.
What happens when we add an argument to __drm_framebuffer_remove whether crtc has to be disabled or not, and make drm_framebuffer_remove always say it has to disable crtc, while being called from rmfb_work_fn tries to keep crtc enabled?

~Maarten