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@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@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@linux.intel.com Signed-off-by: Daniel Vetter daniel.vetter@intel.com Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-24-git-send-ema...
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