another interesting lock recursion!

Daniel Vetter daniel at ffwll.ch
Tue Mar 25 01:24:07 PDT 2014


On Tue, Mar 25, 2014 at 6:53 AM, Dave Airlie <airlied at gmail.com> wrote:
> So with runtime pm on nouveau, if the card gets powered down, and then
> you access a connector via sysfs,
>
> drm_sysfs.c:status_show locks the connector and calls into the driver,
> the driver then does a runtime_get_sync, which causes resume to happen
> which causes modesetting to reset the mode, which tries to take all
> the locks, and it all deadlocks in a pile,
>
> Ideas to fix this, move the runtime_get_sync into the drm_sysfs code,
> or allow the drivers to provide their own status show functions,
> moving the runtime get into the sysfs code probably involves having
> conditionals for device that support runtime PM at all, otherwise who
> knows what might happen,

You need special runtime suspend/resume functions so that sysfs access
doesn't try to resurrect the world by accident (and so goes into the
modeset code when not needed). i915 runtime PM does that and a lot
more (we can runtime suspend even when the device is open, debugfs,
sysfs, i2c and any other probing and poking just wake up the minimal
parts of the device and state and so on ...). If you look at our
runtime_suspend/resum functions there's very little we actually do ...

Imo moving runtime pm into sysfs is the completely wrong solution
since it imposes random restrictions upon drivers, i.e. midlayer-feel.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dri-devel mailing list