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. Asking since if you really need kms locks in rpm paths, and the general design is to grab/drop rpm outside of everything (as nouveau does with the overall ioctl wrapper trick), then there's fundamentally a deadlock, or at least a nice inversion. It shouldn't really be needed ... -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
