similar to: [PATCH 00/51] treewide: Switch to __pm_runtime_put_autosuspend()

On Tue, Oct 8, 2024 at 12:35?AM Ulf Hansson <ulf.hansson at linaro.org> wrote: > > On Tue, 8 Oct 2024 at 00:25, Laurent Pinchart > <laurent.pinchart at ideasonboard.com> wrote: > > > > Hi Ulf, > > > > On Tue, Oct 08, 2024 at 12:08:24AM +0200, Ulf Hansson wrote: > > > On Mon, 7 Oct 2024 at 20:49, Laurent Pinchart wrote: > > > > On

On Tue, 8 Oct 2024 at 00:25, Laurent Pinchart <laurent.pinchart at ideasonboard.com> wrote: > > Hi Ulf, > > On Tue, Oct 08, 2024 at 12:08:24AM +0200, Ulf Hansson wrote: > > On Mon, 7 Oct 2024 at 20:49, Laurent Pinchart wrote: > > > On Fri, Oct 04, 2024 at 04:38:36PM +0200, Ulf Hansson wrote: > > > > On Fri, 4 Oct 2024 at 11:41, Sakari Ailus wrote: >

Hello everyone, This set will switch the users of pm_runtime_put_autosuspend() to __pm_runtime_put_autosuspend() while the former will soon be re-purposed to include a call to pm_runtime_mark_last_busy(). The two are almost always used together, apart from bugs which are likely common. Going forward, most new users should be using pm_runtime_put_autosuspend(). Once this conversion is done and

It's true we can't resume the device from poll workers in nouveau_connector_detect(). We can however, prevent the autosuspend timer from elapsing immediately if it hasn't already without risking any sort of deadlock with the runtime suspend/resume operations. So do that instead of entirely avoiding grabbing a power reference. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc:

amdgpu's ->runtime_suspend hook calls drm_kms_helper_poll_disable(), which waits for the output poll worker to finish if it's running. The output poll worker meanwhile calls pm_runtime_get_sync() in amdgpu's ->detect hooks, which waits for the ongoing suspend to finish, causing a deadlock. Fix by not acquiring a runtime PM ref if the ->detect hooks are called in the output

Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") converted nouveau to generic fbdev emulation. The driver's internal implementation later got accidentally restored during a merge commit. Remove the file from the driver. No functional changes. v2: * point Fixes tag to merge commit (Alex) Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>

Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") converted nouveau to generic fbdev emulation. Also remove the internal implementation from the driver. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") Cc: Ben Skeggs <bskeggs at redhat.com> Cc:

On Mon, Jan 9, 2023 at 9:06 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") > converted nouveau to generic fbdev emulation. Also remove the internal > implementation from the driver. No functional changes. Looking at 4a16dd9d18a0, it appears to have removed this file already. I guess it

nouveau's ->runtime_suspend hook calls drm_kms_helper_poll_disable(), which waits for the output poll worker to finish if it's running. The output poll worker meanwhile calls pm_runtime_get_sync() in nouveau_connector_detect() which waits for the ongoing suspend to finish, causing a deadlock. Fix by not acquiring a runtime PM ref if nouveau_connector_detect() is called in the output

Hi Am 09.01.23 um 15:15 schrieb Alex Deucher: > On Mon, Jan 9, 2023 at 9:06 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> >> Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") >> converted nouveau to generic fbdev emulation. Also remove the internal >> implementation from the driver. No functional changes. > > Looking

Commit cae9ff036eea effectively disabled the drm poll_helper by checking the wrong flag to see if the driver should enable the poll or not: mode_config.poll_enabled is only set to true by poll_init and it is not indicating if the poll is enabled or not. nouveau_display_create() will initialize the poll and going to disable it right away. After poll_init() the mode_config.poll_enabled will be true,

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 { > - /*

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

On Wed, Aug 01, 2018 at 05:14:58PM -0400, Lyude Paul wrote: > We can't and don't need to try resuming the device from our hotplug > handlers, but hotplug events are generally something we'd like to keep > the device awake for whenever possible. So, grab a PM ref safely in our > hotplug handlers using pm_runtime_get_noresume() and mark the device as > busy once we're

The code claims to grab a runtime PM ref when at least one CRTC is active, but that's not actually the case as we grab a runtime PM ref whenever a CRTC is enabled regardless of it's DPMS state. Meaning that we can end up keeping the GPU awake when there are no screens enabled, something we don't really want to do. Note that we fixed this same issue for nv50 a while ago in: commit

pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

This adds more information to the hotplug uevent and lets user-space know that it's about a particular connector only. Signed-off-by: Simon Ser <contact at emersion.fr> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: David Airlie <airlied at linux.ie> Cc: Karol Herbst <kherbst at redhat.com> ---

While we currently grab a runtime PM ref in nouveau's normal connector detection code, we apparently don't do this for MST. This means if we're in a scenario where the GPU is suspended and userspace attempts to do a connector probe on an MSTC connector, the probe will fail entirely due to the DP aux channel and GPU not being woken up: [ 316.633489] nouveau 0000:01:00.0: i2c: aux

Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com> Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +++++++++++++ drivers/gpu/drm/nouveau/nouveau_dp.c | 9 +++++++++

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