[PATCH 7/7] drm: Resurrect atomic rmfb code
Daniel Vetter
daniel at ffwll.ch
Mon Dec 12 09:23:08 UTC 2016
On Mon, Dec 12, 2016 at 09:46:59AM +0100, Maarten Lankhorst wrote:
> 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?
tbh I'm not sure what the regression this time around was. But I guess
long-term we want some kind of atomic rmfb, since iirc it blocks the
re-adding of ww_acquire_done? I've thrown this patch out of my pile for
now, got burned too often ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list