search for: autosuspend

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

...ed at redhat.com> > Cc: "Ben Skeggs" <skeggsb at gmail.com>, "Ben Skeggs" <bskeggs at redhat.com>, nouveau at lists.freedesktop.org > Sent: Thursday, 20 March, 2014 9:49:47 AM > Subject: Re: [Nouveau] [PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm > > On Wed, Mar 19, 2014 at 7:45 PM, David Airlie <airlied at redhat.com> wrote: > > > >> On Thu, Mar 20, 2014 at 1:28 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > >> > There was a proliferation of duplicated checks for runpm == -1 &...

...as yet untested, but I wanted to send this out to the list > since I think a few people are still running into these annoying > issues. > > I don't have access to an actual optimus configuration, so if someone > could give this a shot on such a setup and confirm that things > autosuspend as expected without any runpm parameters, that'd be great. > > drm/nouveau_drm.c | 18 +++++------------- > drm/nouveau_vga.c | 4 +--- > 2 files changed, 6 insertions(+), 16 deletions(-) > > diff --git a/drm/nouveau_drm.c b/drm/nouveau_drm.c > index 8f811a5..a6225ee 1006...

...> 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 > &gt...

> On Thu, Mar 20, 2014 at 1:28 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > > There was a proliferation of duplicated checks for runpm == -1 && > > optimus. Instead of continuing that tradition, get rid of all of them, > > only doing the optimus computation once on load. > > > > This should hopefully fix secondary cards suspending and then being

On Wed, Mar 19, 2014 at 7:45 PM, David Airlie <airlied at redhat.com> wrote: > >> On Thu, Mar 20, 2014 at 1:28 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> > There was a proliferation of duplicated checks for runpm == -1 && >> > optimus. Instead of continuing that tradition, get rid of all of them, >> > only doing the optimus

....org> # 3.12+ --- This is as yet untested, but I wanted to send this out to the list since I think a few people are still running into these annoying issues. I don't have access to an actual optimus configuration, so if someone could give this a shot on such a setup and confirm that things autosuspend as expected without any runpm parameters, that'd be great. drm/nouveau_drm.c | 18 +++++------------- drm/nouveau_vga.c | 4 +--- 2 files changed, 6 insertions(+), 16 deletions(-) diff --git a/drm/nouveau_drm.c b/drm/nouveau_drm.c index 8f811a5..a6225ee 100644 --- a/drm/nouveau_drm.c +++ b/...

...ltiple DRI_PRIME >> glxgears, in parallel, serial waiting the 12 seconds and serial within >> the 12 seconds and I couldn't reproduce it > > The discrete GPU needs to runtime suspend, that's the trigger, > so no DRI_PRIME executables should be running. Just let it > autosuspend after boot. Do you see "waiting 12 sec" messages > in dmesg? If not it's not autosuspending. > > Thanks, > > Lukas Hi Yes I'm seeing those messages, I'm just not seeing the hangs I've attached the dmesg in case you're interested Regards Mike -----...

Hi I've not been able to reproduce the original problem you're trying to solve on amdgpu thats with or without your patch set and the above "trigger" too Is anything else required to trigger it, I started multiple DRI_PRIME glxgears, in parallel, serial waiting the 12 seconds and serial within the 12 seconds and I couldn't reproduce it Regards Mike

...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 li...

...() and attempting to > > > communicate with the hub, we end up confusing it and cause it to stop > > > responding for at least 10 seconds > > > - After 5 seconds of being in drm_fb_helper_output_poll_changed(), the > > > pm core attempts to put the GPU into autosuspend, which ends up > > > calling drm_kms_helper_poll_disable() > > > - While the runtime PM core is waiting in drm_kms_helper_poll_disable() > > > for the output poll to finish, we end up finally detecting an MST > > > display > > > - We notice the new...

...suspend to finish. The ->detect callback is invoked from multiple call sites and waiting for runtime suspend to finish is the correct thing to do except if it's executing in the context of the worker. v2: Expand kerneldoc to specifically mention deadlock between output poll worker and autosuspend worker as use case. (Lyude) Cc: Dave Airlie <airlied at redhat.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Alex Deucher <alexander.deucher at amd.com> Reviewed-by: Lyude Paul <lyude at redhat.com> Signed-off-by: Lukas Wunner <lukas at wunner.de> --- drivers/gpu/d...

...;re in drm_fb_helper_output_poll_changed() and attempting to > communicate with the hub, we end up confusing it and cause it to stop > responding for at least 10 seconds > - After 5 seconds of being in drm_fb_helper_output_poll_changed(), the > pm core attempts to put the GPU into autosuspend, which ends up > calling drm_kms_helper_poll_disable() > - While the runtime PM core is waiting in drm_kms_helper_poll_disable() > for the output poll to finish, we end up finally detecting an MST > display > - We notice the new display and tries to enable it, which triggers &g...

...glxgears, in parallel, serial waiting the 12 seconds and serial within > > > the 12 seconds and I couldn't reproduce it > > > > The discrete GPU needs to runtime suspend, that's the trigger, > > so no DRI_PRIME executables should be running. Just let it > > autosuspend after boot. Do you see "waiting 12 sec" messages > > in dmesg? If not it's not autosuspending. > > Yes I'm seeing those messages, I'm just not seeing the hangs > > I've attached the dmesg in case you're interested Okay the reason you're not s...

...to trigger it, I started multiple DRI_PRIME > glxgears, in parallel, serial waiting the 12 seconds and serial within > the 12 seconds and I couldn't reproduce it The discrete GPU needs to runtime suspend, that's the trigger, so no DRI_PRIME executables should be running. Just let it autosuspend after boot. Do you see "waiting 12 sec" messages in dmesg? If not it's not autosuspending. Thanks, Lukas

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: stable at vger.kernel.org Cc: Luka...

...s://alioth-lists.debian.net/pipermail/nut-upsdev/2019-June/007440.html I’ll keep that thread up to date with progress as I go. But if there are specific things it would make sense to test here, just let me know. Otherwise, I figure reducing redundancy makes sense? 2) I tried disabling usbcore.autosuspend, but that did not seem to stop the drops An example of what I tried is below. I believe simply echo-ing “-1” will change the setting until the next reboot and it should apply to any newly connected devices, so I did that, connected the device to the virtual machine, and checked syslog. [root at lo...

...> nv_connector->edid = NULL; > } > > - /* Outputs are only polled while runtime active, so resuming the > - * device here is unnecessary (and would deadlock upon runtime suspend > - * because it waits for polling to finish). We do however, want to > - * prevent the autosuspend timer from elapsing during this operation > - * if possible. > + /* Output polling and HPD only happens while we're runtime active, so > + * resuming the device here is unnecessary (and would deadlock upon > + * runtime suspend because it waits for polling to finish). We do >...

...sed branch to: > https://github.com/l1k/linux/commits/switcheroo_devlink_v2 > > Minimal test procedure: > > - Note well: Recent Optimus require that a Mini-DP or HDMI cable is > plugged in on boot for the HDA device to be present. > > - Check that HDA, GPU and root port autosuspend when not in use: > cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status # HDA > cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status # GPU > cat /sys/bus/pci/devices/0000:00:01.0/power/runtime_status # Root Port > > - Check that all three autoresume when accessi...

https://bugs.freedesktop.org/show_bug.cgi?id=101404 Bug ID: 101404 Summary: GTX 970M (GM204-A) not powered off when not in use (DynPwr in stead of DynOff) Product: xorg Version: unspecified Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium