On Thu, Mar 20, 2014 at 02:26:34PM +0100, Daniel Vetter wrote:
We have two calling contexts for thise function:
In the crtc helper code itself as part of the ->set_config implementation. In this calling context all modeset locks are already held, as they should.
In drivers not implementing fastboot before the fbdev/fbcon setup and initialization. This has been added for all drivers in
commit 76a39dbfb2d1bc45219839e5a95d4ceaf6ca114f Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Sun Jan 20 23:12:54 2013 +0100
drm/fb-helper: don't disable everything in initial_config
In this calling context we do not hold any modeset locks since the immediately following call to initialize the fbev emulation grabs all these locks themselves.
There are two exceptions to the above rule: shmob doesn't have fbdev emulation support. I've manually checked the callchain up to the driver load function and no kms locks are held.
The right fix therefore is to split this helper into an internal and external version and add the required locking to the function exported to drivers.
This remedies locking inconsistencies exposed by me adding locking WARNs as part of the recent kerneldoc abi polishing done in
commit 62ff94a5492175759546f8bc61383189d6b49122 Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Thu Jan 23 22:18:47 2014 +0100
drm/crtc-helper: remove LOCKING from kerneldoc
and
commit 63951385052f7974155fa38f962f0f4e9847f90a Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Thu Jan 23 15:14:15 2014 +0100
drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c
v2: It helps when I actually git add the entire thing.
Cc: Chris Wilson chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch
Reviewed-by: Chris Wilson chris@chris-wilson.co.uk -Chris