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@xxxxxxxxxxxxxxx> >> 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@xxxxxxxx> >> 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@xxxxxxxxxxxxxxx> >> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> >> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> >> Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-24-git-send-email-daniel.vetter@xxxxxxxx > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
