[rfc] fix output poll execute lockdep

[Daniel Vetter]

On Tue, Jan 10, 2017 at 09:46:26PM +1000, Dave Airlie wrote:
> On 10 Jan. 2017 19:50, "Daniel Vetter" <daniel at ffwll.ch> wrote:
> 
> On Tue, Jan 10, 2017 at 12:12:30PM +1000, Dave Airlie wrote:
> > On runtime resume, nouveau can try and take the mode_config
> > mutex in the poll reenable, however a poll can race with this,
> > and take the mutex and get stuck waiting for the runtime to
> > finish completion. These two patches allow the driver to
> > get hooked in before the mutex is taken.
> >
> > I think radeon/amdgpu will also need similar patches to nouveau.
> >
> > I found this while trying to track down a runtime regression
> > on W541 laptop, I'm not sure I found what the reporter was seeing yet.
> 
> Hm, we fixed this by doing the rpm stuff always within any of the big core
> locks. And I think that's the much more reasonable design, at least as
> soon as you have more fine-grained locking.
> 
> But maybe there's a cheap way out - why does nouveau take the modeset
> lock? Ime you can remove a lot of the kms locking super easily because
> it's all cargo-culted. The last hold-out was connector_list walking, but
> that's fixed now and also doesn't need any of the heavy-weight kms locks
> anymore.
> 
> 
> Reenable polling takes the lock.

I think with the revamped connector_locking we can nuke that. All the
other stuff checked (poll_enabled and similar) are either intentionally
racy, or synchronized through the right order of the driver setup/teardown
code.

I'll be typing some patches.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch