search for: pm_runtime_forbid

...assuming I'm looking at the correct code): static int nouveau_pmops_runtime_suspend(struct device *dev) { struct pci_dev *pdev = to_pci_dev(dev); struct drm_device *drm_dev = pci_get_drvdata(pdev); int ret; if (!nouveau_pmops_runtime()) { pm_runtime_forbid(dev); return -EBUSY; } nouveau_switcheroo_optimus_dsm(); ret = nouveau_do_suspend(drm_dev, true); pci_save_state(pdev); pci_disable_device(pdev); pci_ignore_hotplug(pdev); pci_set_power_state(pdev, PCI_D3cold); drm_dev...

In preparation for runtime pm on muxed dual GPU laptops, I've fixed all runtime pm ref leaks I could find in nouveau, radeon and amdgpu. To ease reviewing, I've pushed this series to GitHub: https://github.com/l1k/linux/commits/drm_runpm_fixes_v1 @Alex Deucher: I do not have an AMD GPU so couldn't test this beyond verifying that it compiles. Please double-check the patches and test

...<ffffffff8c920fab>] ? __schedule+0x2fb/0xb30 [ 246.899605] [<ffffffff8c921820>] schedule+0x40/0x90 [ 246.899608] [<ffffffff8c5ff8da>] rpm_resume+0x14a/0x740 [ 246.899614] [<ffffffff8c0e1c10>] ? wake_atomic_t_function+0x60/0x60 [ 246.899617] [<ffffffff8c6012e3>] pm_runtime_forbid+0x43/0x50 [ 246.899678] [<ffffffffc08f67c5>] nouveau_pmops_runtime_suspend+0xc5/0xd0 [nouveau] [ 246.899684] [<ffffffff8c4ced8d>] pci_pm_runtime_suspend+0x5d/0x190 [ 246.899687] [<ffffffff8c4ced30>] ? pci_pm_runtime_resume+0xa0/0xa0 [ 246.899690] [<ffffffff8c5ff252>...

...ode): > > static int > nouveau_pmops_runtime_suspend(struct device *dev) > { > struct pci_dev *pdev = to_pci_dev(dev); > struct drm_device *drm_dev = pci_get_drvdata(pdev); > int ret; > > if (!nouveau_pmops_runtime()) { > pm_runtime_forbid(dev); > return -EBUSY; > } > > nouveau_switcheroo_optimus_dsm(); > ret = nouveau_do_suspend(drm_dev, true); > pci_save_state(pdev); > pci_disable_device(pdev); > pci_ignore_hotplug(pdev); > pci_set_po...

On Wed, Nov 20, 2019 at 12:58:00PM +0100, Karol Herbst wrote: > overall, what I really want to know is, _why_ does it work on windows? So do I ;-) > Or what are we doing differently on Linux so that it doesn't work? If > anybody has any idea on how we could dig into this and figure it out > on this level, this would probably allow us to get closer to the root > cause? no?

...ouveau_runtime_pm == -1 && !nouveau_is_optimus() && !nouveau_is_v1_dsm()) { + if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && !nouveau_is_v1_dsm() && !nouveau_has_gmux_dsm()) { DRM_DEBUG_DRIVER("failing to power off - not optimus\n"); pm_runtime_forbid(dev); return -EBUSY; @@ -780,7 +780,7 @@ nouveau_pmops_runtime_idle(struct device *dev) } /* are we optimus enabled? */ - if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && !nouveau_is_v1_dsm()) { + if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() &&a...

...> inside nouveau to fix that as I think nouveau is the only driver > > actually hit by this issue, but nothing turned out to be reliable > > enough. > > Can't you just block runtime PM from the nouveau driver until this is > understood better? That can be done by calling pm_runtime_forbid() (or > not calling pm_runtime_allow() in the driver). Or in case of PCI driver > you just don't decrease the reference count when probe() ends. > the thing is, it does work for a lot of laptops. We could only observe this on kaby lake and skylake ones. Even on Cannon Lakes it seems t...

Second iteration of my endeavour to rid nouveau, radeon and amdgpu of runtime pm ref leaks. Patches 1 to 8 are identical to v1. Patch 9 of v1 modified the DRM core to turn off all CRTCs on driver unload. Based on feedback by Daniel Vetter, I've replaced this with a helper to turn off all CRTCs, which is called by nouveau, radeon and amdgpu on unload. In other words, this is now opt-in. So

This is the latest version of https://patchwork.freedesktop.org/series/45862/ . One new patch has been added that also addresses some additional issues I found with pmops_runtime_idle that would stop nouveau from suspending the GPU when running under X. Additionally, "drm/nouveau: Fix runtime PM leak in nv50_disp_atomic_commit()" has had it's CC to stable removed. Lyude Paul (3):

.../* are we optimus enabled? */ - if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && !nouveau_is_v1_dsm()) { + if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && !nouveau_has_mux()) { DRM_DEBUG_DRIVER("failing to power off - not optimus\n"); pm_runtime_forbid(dev); return -EBUSY; @@ -780,7 +780,7 @@ nouveau_pmops_runtime_idle(struct device *dev) } /* are we optimus enabled? */ - if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && !nouveau_is_v1_dsm()) { + if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() &&a...

.../* are we optimus enabled? */ - if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && !nouveau_is_v1_dsm()) { + if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && !nouveau_has_mux()) { DRM_DEBUG_DRIVER("failing to power off - not optimus\n"); pm_runtime_forbid(dev); return -EBUSY; @@ -780,7 +780,7 @@ nouveau_pmops_runtime_idle(struct device *dev) } /* are we optimus enabled? */ - if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && !nouveau_is_v1_dsm()) { + if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() &&a...

We need to call drm_helper_hpd_irq_event() on resume to properly detect monitor connection / disconnection on some laptops. For runtime-resume (which gets called on resume from normal suspend too) we must call drm_helper_hpd_irq_event() from a workqueue to avoid a deadlock. Rename acpi_work to hpd_work, and move it out of the #ifdef CONFIG_ACPI blocks to make it suitable for generic work.

...is the only driver > > > > actually hit by this issue, but nothing turned out to be reliable > > > > enough. > > > > > > Can't you just block runtime PM from the nouveau driver until this is > > > understood better? That can be done by calling pm_runtime_forbid() (or > > > not calling pm_runtime_allow() in the driver). Or in case of PCI driver > > > you just don't decrease the reference count when probe() ends. > > > > > > > the thing is, it does work for a lot of laptops. We could only observe > > this on...

...resume(struct device *dev) static int nouveau_pmops_runtime_idle(struct device *dev) { - struct pci_dev *pdev = to_pci_dev(dev); - struct drm_device *drm_dev = pci_get_drvdata(pdev); - struct nouveau_drm *drm = nouveau_drm(drm_dev); - struct drm_crtc *crtc; - if (!nouveau_pmops_runtime()) { pm_runtime_forbid(dev); return -EBUSY; } - list_for_each_entry(crtc, &drm->dev->mode_config.crtc_list, head) { - if (crtc->enabled) { - DRM_DEBUG_DRIVER("failing to power off - crtc active\n"); - return -EBUSY; - } - } pm_runtime_mark_last_busy(dev); pm_runtime_autosuspend(dev...

...orkaround we could have > inside nouveau to fix that as I think nouveau is the only driver > actually hit by this issue, but nothing turned out to be reliable > enough. Can't you just block runtime PM from the nouveau driver until this is understood better? That can be done by calling pm_runtime_forbid() (or not calling pm_runtime_allow() in the driver). Or in case of PCI driver you just don't decrease the reference count when probe() ends. I think that would be much better than blocking any devices behind Kabylake PCIe root ports from entering D3 (I don't really think the problem is in...

On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: > nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0, > but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally. > We therefore leak a runtime pm ref whenever nouveau is loaded with > runpm=0 and then unloaded. The GPU will subsequently never runtime > suspend even if nouveau is loaded again

...l pm_runtime_get_sync(), which will implicitly set the runtime status to "active" and which should also wake parents. So how did you ever reach a point where you loaded nouveau and the root port stayed asleep? Clearly we have a bug there, question is where. This shouldn't work only if pm_runtime_forbid() was called on driver unload. Thanks for the extensive testing! Lukas > > Peter > > > --- > > drivers/gpu/drm/nouveau/nouveau_drm.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c...

On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg <mika.westerberg at linux.intel.com> wrote: > > On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote: > > still happens with your patch applied. The machine simply gets shut down. > > > > dmesg can be found here: > >

...[<ffffffff81019bd3>] ? native_sched_clock+0x28/0x93 [ 240.558987] [<ffffffff815c3e43>] schedule+0x69/0x6b [ 240.563936] [<ffffffff8146b222>] rpm_resume+0x220/0x4b7 [ 240.569231] [<ffffffff81088191>] ? __wake_up_sync+0x12/0x12 [ 240.574871] [<ffffffff8146b710>] pm_runtime_forbid+0x42/0x4f [ 240.580599] [<ffffffff8142f6cd>] nouveau_pmops_runtime_suspend+0x32/0xd2 [ 240.587366] [<ffffffff812e2972>] pci_pm_runtime_suspend+0x63/0x110 [ 240.593612] [<ffffffff812e290f>] ? pci_legacy_suspend+0xbe/0xbe [ 240.599598] [<ffffffff8146a40c>] __rpm_callba...

...x that as I think nouveau is the only driver > > > actually hit by this issue, but nothing turned out to be reliable > > > enough. > > > > Can't you just block runtime PM from the nouveau driver until this is > > understood better? That can be done by calling pm_runtime_forbid() (or > > not calling pm_runtime_allow() in the driver). Or in case of PCI driver > > you just don't decrease the reference count when probe() ends. > > > > the thing is, it does work for a lot of laptops. We could only observe > this on kaby lake and skylake ones. E...