On Thu, Mar 22, 2018 at 05:51:35PM +0100, Noralf Trønnes wrote: > tinydrm is also using plane->fb: > > $ grep -r "plane\.fb" drivers/gpu/drm/tinydrm/ > drivers/gpu/drm/tinydrm/repaper.c: if (tdev->pipe.plane.fb != fb) > drivers/gpu/drm/tinydrm/mipi-dbi.c: if (tdev->pipe.plane.fb != fb) > drivers/gpu/drm/tinydrm/mipi-dbi.c: struct drm_framebuffer *fb = > mipi->tinydrm.pipe.plane.fb; Oh dear, and naturally it's the most annoying one of the bunch. So we want to take the plane lock in the fb.dirty() hook to look at the fb, but mipi-dbi.c calls that directly from the bowels of its .atomic_enable() hook. So that would deadlock pretty neatly if the commit happens while already holding the lock. So we'd either need to plumb an acquire context into fb.dirty(), or maybe have tinydrm provide a lower level lockless dirty() hook that gets called by both (there are just too many layers in this particular cake to immediately see where such a hook would be best placed). Or maybe there's some other solution I didn't think of. Looking at this I'm also left wondering how this is supposed handle fb.dirty() getting called concurrently with a modeset. The dirty_mutex only seems to offer any protection for fb.dirty() against another fb.dirty()... -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
