similar to: [PATCH] drm/nouveau: Fix drm poll_helper handling

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

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)

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()

This is the latest version of https://patchwork.freedesktop.org/series/46815/ With a bunch of fixes to the new fb_helper to prevent it from breaking module loading/unloading with nouveau. Also; lots of documentation fixes and one fix in response to a kbuild bot. Lyude Paul (8): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Enable polling even if we have runtime

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()

Turns out this part is my fault for not noticing when reviewing 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work(). This makes basically no sense however, because that means we're calling drm_kms_helper_poll_enable() every time we schedule the hotplug detection work. This is also against the

This is the next version of https://patchwork.freedesktop.org/series/46815/ With a lot more thought put into it so as to avoid the potential deadlock scenarios I missed. This also required fixing some bogus DRM helper usage. Try and deadlock me now, nouveau. I dare you!!! Lyude Paul (8): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Enable polling even if we

Does what it says on the label, a lot of these calls are already handled somewhere else and don't appear to be here for a legitimate reason anymore. Lyude Paul (3): drm/nouveau: Remove useless poll_enable() call in switcheroo_set_state() drm/nouveau: Remove useless poll_disable() call in switcheroo_set_state() drm/nouveau: Remove useless poll_enable() call in drm_load()

Next version of https://patchwork.freedesktop.org/series/48131/ Only changes are new A-Bs and R-Bs Lyude Paul (3): drm/nouveau: Remove useless poll_enable() call in switcheroo_set_state() drm/nouveau: Remove useless poll_disable() call in switcheroo_set_state() drm/nouveau: Remove useless poll_enable() call in drm_load() drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +---

On Fri, Jan 27, 2017 at 04:06:38PM +0100, Peter Wu wrote: > Also note that many laptops with these card suffer from a problem > that cause lockups when runpm kicks in. > See https://bugzilla.kernel.org/show_bug.cgi?id=156341 Peter, I notice you weren't cc'ed on the last few messages of the 'PCI: Revert "PCI: Add runtime PM support for PCIe ports"' thread, the

As it turns out, on cards that actually have CRTCs on them we're already calling drm_kms_helper_poll_enable(drm_dev) from nouveau_display_resume() before we call it in nouveau_pmops_runtime_resume(). This leads us to accidentally trying to enable polling twice, which results in a potential deadlock between the RPM locks and drm_dev->mode_config.mutex if we end up trying to enable polling

As it turns out, on cards that actually have CRTCs on them we're already calling drm_kms_helper_poll_enable(drm_dev) from nouveau_display_resume() before we call it in nouveau_pmops_runtime_resume(). This leads us to accidentally trying to enable polling twice, which results in a potential deadlock between the RPM locks and drm_dev->mode_config.mutex if we end up trying to enable polling

On Wed, Aug 01, 2018 at 05:14:52PM -0400, Lyude Paul wrote: > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c > @@ -592,10 +592,11 @@ nouveau_drm_load(struct drm_device *dev, unsigned long flags) > pm_runtime_allow(dev->dev); > pm_runtime_mark_last_busy(dev->dev); > pm_runtime_put(dev->dev); > - } else { > - /*

Having runtime PM makes no difference on whether or not we want polling, and it's now safe to just enable polling unconditionally in drm_load() thanks to d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend") Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Lukas Wunner <lukas at wunner.de> Cc: Peter Ujfalusi <peter.ujfalusi at ti.com> Cc: stable at

Hi, When will Nvidia Geforce 965M nouveau driver be available? It's just that when I use linux, i have to use intel HD graphics :\ Thanks, Ze. H -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20170123/15d077a0/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=98690 --- Comment #77 from Gleb Nemshilov <gleb at fastmail.com> --- Hi Peter and everyone! I've seen that the latest patch which solves the issue was merged to 4.12 and 4.9, but the initial fix with 1s delay is still in the tree. Will this also be resolved? It looks like the previous patch can be reverted as the proper fix is now available.

The local #define of ACPI_VIDEO_NOTIFY_PROBE was only added temporarily to avoid a dependency between the acpi and nouveau trees while merging. This is now properly defined in acpi/video.h and the local #define can be dropped. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_display.c | 9 --------- 1 file changed, 9 deletions(-) diff --git

Again, this doesn't do anything. drm_kms_helper_poll_enable() will have already been called in nouveau_display_init() Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Lukas Wunner <lukas at wunner.de> Cc: Karol Herbst <karolherbst at gmail.com> [omitting stable Cc, this probably doesn't fix any real bugs] --- drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +--- 1 file

This doesn't do anything, drm_kms_helper_poll_enable() gets called in nouveau_pmops_resume()->nouveau_display_resume()->nouveau_display_init() already. Signed-off-by: Lyude Paul <lyude at redhat.com> Reviewed-by: Karol Herbst <kherbst at redhat.com> Acked-by: Daniel Vetter <daniel at ffwll.ch> Cc: Lukas Wunner <lukas at wunner.de> ---

From: Lyude Paul <lyude at redhat.com> [ Upstream commit ac0de16a38a9ec7026ca96132e3883c564497068 ] Currently, we enable hotplug detection only after we re-enable the display. However, this is too late if we're planning on sending sideband messages during the resume process - which we'll need to do in order to reprobe the topology on resume. So, enable hotplug events before