search for: nouveau_fbcon_hotplugged_in_suspend

On Mon, Aug 13, 2018 at 3:07 PM, Lyude Paul <lyude at redhat.com> wrote: > +bool > +nouveau_fbcon_hotplugged_in_suspend(struct nouveau_fbdev *fbcon) > +{ > + bool hotplug; > + > + if (!fbcon) > + return false; > + > + mutex_lock(&fbcon->hotplug_lock); > + hotplug = fbcon->hotplug_waiting; > + mutex_unlock(&fbcon->hotplug_lock); &...

...esumed again. Changes since v5: - Come up with the (hopefully final) solution for solving this dumb problem, one that is a lot less likely to cause issues with locking in the future. This should work around all deadlock conditions with fbcon brought up thus far. Changes since v4: - Add nouveau_fbcon_hotplugged_in_suspend() to workaround deadlock condition that Lukas described - Just move all of this out of drm_fb_helper. It seems that other DRM drivers have already figured out other workarounds for this. If other drivers do end up needing this in the future, we can just move this back into drm_fb_helpe...

...venting us from having to fight > locking for the rest of our lives. So, we work around these deadlocks by > deferring all fbcon hotplug events that happen after the runtime suspend > process starts until after the device is resumed again. > > Changes since v6: > - Remove unused nouveau_fbcon_hotplugged_in_suspend() - Ilia > > Changes since v5: > - Come up with the (hopefully final) solution for solving this dumb > problem, one that is a lot less likely to cause issues with locking in > the future. This should work around all deadlock conditions with fbcon > brought up thus far....

Latest version of https://patchwork.freedesktop.org/series/46815/ with some significant improvements: - I finally figured out a clean way to do this entirely with runtime PM helpers, no avoiding grabbing refs required! - Since this new method removes the need for a lot of the other changes I made (although we probably still want those changes, but not for fixing these deadlocks)

...d also have the benefit of preventing us from having to fight locking for the rest of our lives. So, we work around these deadlocks by deferring all fbcon hotplug events that happen after the runtime suspend process starts until after the device is resumed again. Changes since v6: - Remove unused nouveau_fbcon_hotplugged_in_suspend() - Ilia Changes since v5: - Come up with the (hopefully final) solution for solving this dumb problem, one that is a lot less likely to cause issues with locking in the future. This should work around all deadlock conditions with fbcon brought up thus far. Changes since v4: - Add nouv...

Latest version of https://patchwork.freedesktop.org/series/46815/ , with one small change re: ilia Lyude Paul (5): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend() drm/nouveau: Fix deadlock with fb_helper with async RPM requests drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()

This is the latest version of https://patchwork.freedesktop.org/series/46815/ I moved everything out of fb_helper and back into nouveau, because it seems that other drivers actually do have this handled already as far as I can tell. Lyude Paul (13): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend()

Next version of https://patchwork.freedesktop.org/series/46815/ Same as previous version, but some small changes made to commit messages and acks/rbs have been added Lyude Paul (5): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend() drm/nouveau: Fix deadlock with fb_helper with async RPM requests