search for: pm_runtime_get

[cc += linux-pm] Hi Lyude, First of all, thanks a lot for looking into this. On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: > In order to fix all of the spots that need to have runtime PM get/puts() > added, we need to ensure that it's possible for us to call > pm_runtime_get/put() in any context, regardless of how deep, since > almost all of the spots that are currently missing refs can potentially > get called in the runtime suspend/resume path. Otherwise, we'll try to > resume the GPU as we're trying to resume the GPU (and vice-versa) and > cause...

While working on refactoring how we handle connector hotplugging/probing + a bunch of misc DP stuff, I found a bunch of runtime_pm errors that were mostly introduced by me at one point. Oops. A lot of these aren't triggered consistently on a lot of systems, so it's not terribly surprising these got swept under the rug. Lyude Paul (9): drm/nouveau/kms: Handle -EINPROGRESS in

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/n...

..., 2018-07-17 at 09:16 +0200, Lukas Wunner wrote: > > On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: > > > In order to fix all of the spots that need to have runtime PM get/puts() > > > added, we need to ensure that it's possible for us to call > > > pm_runtime_get/put() in any context, regardless of how deep, since > > > almost all of the spots that are currently missing refs can potentially > > > get called in the runtime suspend/resume path. Otherwise, we'll try to > > > resume the GPU as we're trying to resume the GPU (a...

...because otherwise they might > race with the power domain code. It also means that we can't powergate The powerdomain framework won't call any powergating method as long as a module in the domain is still active. So as long as drivers don't try to reset the hw without having done a pm_runtime_get(), we shouldn't have such a race? > modules on demand because they might be in the same power domain as one > other module that's still busy. > The powerdomain framework keeps track of which modules are active (by hooking into runtime pm) and won't try to shutdown a domain u...

On Mon, Feb 10, 2014 at 9:34 PM, Thierry Reding <thierry.reding at gmail.com> wrote: > On Mon, Feb 10, 2014 at 02:58:12PM +0900, Alexandre Courbot wrote: >> pm_runtime_get*() may return -EACCESS to indicate a device does not have > > s/-EACCESS/-EACCES/ Oops. >> 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. >> >> Sign...

In order to fix all of the spots that need to have runtime PM get/puts() added, we need to ensure that it's possible for us to call pm_runtime_get/put() in any context, regardless of how deep, since almost all of the spots that are currently missing refs can potentially get called in the runtime suspend/resume path. Otherwise, we'll try to resume the GPU as we're trying to resume the GPU (and vice-versa) and cause the kernel to deadlo...

...with the power domain code. It also means that we can't powergate > > > > The powerdomain framework won't call any powergating method as long as a > > module in the domain is still active. So as long as drivers don't try to > > reset the hw without having done a pm_runtime_get(), we shouldn't have such > > a race? > Agree. And as long as the driver has the correct reset procedure, that should > be fine to occur between power ungating and gating sequences. > > > > > > modules on demand because they might be in the same power domain as o...

...6 +0200, Lukas Wunner wrote: > > > On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: > > > > In order to fix all of the spots that need to have runtime PM get/puts() > > > > added, we need to ensure that it's possible for us to call > > > > pm_runtime_get/put() in any context, regardless of how deep, since > > > > almost all of the spots that are currently missing refs can potentially > > > > get called in the runtime suspend/resume path. Otherwise, we'll try to > > > > resume the GPU as we're trying to re...

...uveau_fbcon_output_poll_changed(struct drm_device *dev) > +{ > + struct nouveau_drm *drm = nouveau_drm(dev); > + struct nouveau_fbdev *fbcon = drm->fbcon; > + int ret; > + > + if (!fbcon) > + return; > + > + mutex_lock(&fbcon->hotplug_lock); > + > + ret = pm_runtime_get(dev->dev); > + if (ret == 1 || ret == -EACCES) { > + drm_fb_helper_hotplug_event(&fbcon->helper); > + > + pm_runtime_mark_last_busy(dev->dev); > + pm_runtime_put_autosuspend(dev->dev); > + } else if (ret == 0) { > + /* If the GPU was already in the process o...

...09:16 +0200, Lukas Wunner wrote: >> > On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: >> > > In order to fix all of the spots that need to have runtime PM get/puts() >> > > added, we need to ensure that it's possible for us to call >> > > pm_runtime_get/put() in any context, regardless of how deep, since >> > > almost all of the spots that are currently missing refs can potentially >> > > get called in the runtime suspend/resume path. Otherwise, we'll try to >> > > resume the GPU as we're trying to resum...

...> > First of all, thanks a lot for looking into this. > > On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: > > In order to fix all of the spots that need to have runtime PM get/puts() > > added, we need to ensure that it's possible for us to call > > pm_runtime_get/put() in any context, regardless of how deep, since > > almost all of the spots that are currently missing refs can potentially > > get called in the runtime suspend/resume path. Otherwise, we'll try to > > resume the GPU as we're trying to resume the GPU (and vice-versa)...

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

...edesktop.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() drm/nouveau: Fix deadlocks in nouveau_connector_detect() drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 42 +++++++++++---- drivers/gpu/drm/nouveau/nouveau_display.c | 9 ++-- drivers/gpu/drm/nouveau/nouveau...

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/n...

On Mon, Feb 10, 2014 at 02:58:12PM +0900, Alexandre Courbot wrote: > pm_runtime_get*() may return -EACCESS to indicate a device does not have s/-EACCESS/-EACCES/ > 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 <ac...

pm_runtime_get*() may return -EACCES to indicate a device does not have runtime PM enabled. This is currently the case with platform devices on Nouveau, and is not an error in that context. Handle this case without failure. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- Changes since v1: - F...

...ight > > race with the power domain code. It also means that we can't powergate > > The powerdomain framework won't call any powergating method as long as a > module in the domain is still active. So as long as drivers don't try to > reset the hw without having done a pm_runtime_get(), we shouldn't have such > a race? Agree. And as long as the driver has the correct reset procedure, that should be fine to occur between power ungating and gating sequences. > > > modules on demand because they might be in the same power domain as one > > other module that...

...e with the power domain code. It also means that we can't powergate >>> The powerdomain framework won't call any powergating method as long as a >>> module in the domain is still active. So as long as drivers don't try to >>> reset the hw without having done a pm_runtime_get(), we shouldn't have such >>> a race? >> Agree. And as long as the driver has the correct reset procedure, that should >> be fine to occur between power ungating and gating sequences. >> >>>> modules on demand because they might be in the same power domain...

...if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) { + NV_DEBUG(drm, "service %s\n", name); + drm_dp_cec_irq(&nv_connector->aux); + if ((nv_encoder = find_encoder(connector, DCB_OUTPUT_DP))) + nv50_mstm_service(nv_encoder->dp.mstm); + + return NVIF_NOTIFY_KEEP; + } ret = pm_runtime_get(drm->dev->dev); if (ret == 0) { @@ -1149,25 +1159,16 @@ nouveau_connector_hotplug(struct nvif_notify *notify) return NVIF_NOTIFY_DROP; } - if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) { - NV_DEBUG(drm, "service %s\n", name); - drm_dp_cec_irq(&nv_connector->aux);...