On 10 Jan. 2017 19:50, "Daniel Vetter" <daniel@xxxxxxxx> wrote:
On Tue, Jan 10, 2017 at 12:12:30PM +1000, Dave Airlie wrote:Hm, we fixed this by doing the rpm stuff always within any of the big core
> 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.
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.
Dave.
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
