search for: disable_depth

...nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index c7ec86d6c3c9..e851ef7b6373 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -835,6 +835,8 @@ nouveau_pmops_runtime_suspend(struct device *dev) return -EBUSY; } + dev->power.disable_depth++; + drm_kms_helper_poll_disable(drm_dev); nouveau_switcheroo_optimus_dsm(); ret = nouveau_do_suspend(drm_dev, true); @@ -843,6 +845,8 @@ nouveau_pmops_runtime_suspend(struct device *dev) pci_ignore_hotplug(pdev); pci_set_power_state(pdev, PCI_D3cold); drm_dev->switch_power_state = D...

.... > This includes modesetting locks, i2c bus locks, etc. [snip] > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c > @@ -835,6 +835,8 @@ nouveau_pmops_runtime_suspend(struct device *dev) > return -EBUSY; > } > > + dev->power.disable_depth++; > + I'm not sure if that variable is actually private to the PM core. Grepping through the tree I only find a single occurrence where it's accessed outside the PM core and that's in amdgpu. So this looks a little fishy TBH. It may make sense to cc such patches to linux-pm to ge...

pm_runtime_get*() may return -EACCESS to indicate a device does not have runtime PM enabled. This is the case when the nouveau.runpm parameter is set to 0, and is not an error in that context. Handle this case without failure. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-

On Tue, Jul 17, 2018 at 02:24:31PM -0400, Lyude Paul wrote: > On Tue, 2018-07-17 at 20:20 +0200, Lukas Wunner wrote: > > Okay, the PCI device is suspending and the nvkm_i2c_aux_acquire() > > wants it in resumed state, so is waiting forever for the device to > > runtime suspend in order to resume it again immediately afterwards. > > > > The deadlock in the stack

...it seems like -EACCES is indeed returned when runtime power- management hasn't been enabled for a device. This is done automatically for PCI devices, but not for platform devices. We don't support runtime power-management on gk20a yet, therefore pm_runtime_enable() is never called, causing disable_depth to remain at -1 and therefore runtime PM helpers return -EACCES. Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/nouveau/atta...

...t the context if passing in an additional parameter is not feasible > for some reason. That was the case with d61a5c106351. That approach > only works for work items though. Something I'm curious about. This isn't the first time I've hit a situation like this (see: the improper disable_depth fix I added into amdgpu I now need to go and fix), which makes me wonder: is there actually any reason Linux's runtime PM core doesn't just turn get/puts() in the context of s/r callbacks into no-ops by default? > > Lukas

This fixes quite a number of runtime PM bugs I found that have been causing some pretty nasty issues such as: - Deadlocking on boot - Connector probing potentially not working while the GPU is in runtime suspend - i2c char dev not working while the GPU is in runtime suspend - aux char dev not working while the GPU is in runtime suspend There's definitely more parts of nouveau that need

...s locks, etc. > > [snip] > > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c > > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c > > @@ -835,6 +835,8 @@ nouveau_pmops_runtime_suspend(struct device *dev) > > return -EBUSY; > > } > > > > + dev->power.disable_depth++; > > + > > I'm not sure if that variable is actually private to the PM core. > Grepping through the tree I only find a single occurrence where it's > accessed outside the PM core and that's in amdgpu. So this looks > a little fishy TBH. It may make sense to cc...

...ES is indeed returned when runtime power- > management hasn't been enabled for a device. This is done automatically > for PCI devices, but not for platform devices. We don't support runtime > power-management on gk20a yet, therefore pm_runtime_enable() is never > called, causing disable_depth to remain at -1 and therefore runtime PM > helpers return -EACCES. I will fix the commit message, as indeed the -EACCES code is not directly related to the runpm parameter, but rather to the fact pm_runtime_enable() is not called for platform devices yet. Do we however agree on the issue that...

On Wed, Aug 01, 2018 at 05:14:57PM -0400, Lyude Paul wrote: > When we disable hotplugging on the GPU, we need to be able to > synchronize with each connector's hotplug interrupt handler before the > interrupt is finally disabled. This can be a problem however, since > nouveau_connector_detect() currently grabs a runtime power reference > when handling connector probing. This