another interesting lock recursion!

[Dave Airlie]

On Tue, Mar 25, 2014 at 6:24 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> 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 ...

Our runtime pm is completely different than i915, since the chip is
completely off, with a hard power switch which the GPU isn't aware off
so we have to switch it back on again and post it do anything, even
probe a connector, and if you post it you may as well reset the mode,
granted maybe we don't need to care about the modeset I might play a
bit tomorrow with just removing the modeset from the runtime resume
path.

Dave.