On Tue, Jan 10, 2017 at 09:46:26PM +1000, Dave Airlie wrote: > On 10 Jan. 2017 19:50, "Daniel Vetter" <daniel@xxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
