Displaying 20 results from an estimated 67 matches for "autosuspending".
2024 Oct 08
2
[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
2014 Mar 20
1
[PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm
----- Original Message -----
> From: "Ilia Mirkin" <imirkin at alum.mit.edu>
> To: "David Airlie" <airlied 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:
2014 Mar 19
0
[PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm
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
> unable to come back in
2024 Oct 07
1
[PATCH 00/51] treewide: Switch to __pm_runtime_put_autosuspend()
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:
>
2014 Mar 19
2
[PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm
> 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
2014 Mar 19
0
[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 &&
>> > optimus. Instead of continuing that tradition, get rid of all of them,
>> > only doing the optimus
2014 Mar 19
2
[PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm
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
unable to come back in non-optimus setups.
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
Cc: <stable at
2018 Feb 12
2
[PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers
...e 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg.nohangs
Type: application/...
2018 Feb 12
2
[PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers
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
2024 Oct 09
0
[PATCH 00/51] treewide: Switch to __pm_runtime_put_autosuspend()
On Wed, Oct 9, 2024 at 2:48?PM Richard Fitzgerald
<rf at opensource.cirrus.com> wrote:
>
> On 08/10/2024 7:24 pm, Rafael J. Wysocki wrote:
> > 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:
>
2018 Jul 21
1
[PATCH 1/2] drm/fb_helper: Add drm_fb_helper_output_poll_changed_with_rpm()
On Thu, Jul 19, 2018 at 08:08:15PM -0400, Lyude Paul wrote:
> On Thu, 2018-07-19 at 09:49 +0200, Lukas Wunner wrote:
> > On Wed, Jul 18, 2018 at 04:56:39PM -0400, Lyude Paul wrote:
> > > When DP MST hubs get confused, they can occasionally stop responding for
> > > a good bit of time up until the point where the DRM driver manages to
> > > do the right DPCD
2018 Feb 14
1
[PATCH v2] drm: Allow determining if current task is output poll worker
Introduce a helper to determine if the current task is an output poll
worker.
This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for the output poll worker
to finish and the worker in turn calls a ->detect callback which waits
for runtime suspend to finish. The ->detect callback is invoked from
multiple call sites and
2018 Jul 19
3
[PATCH 1/2] drm/fb_helper: Add drm_fb_helper_output_poll_changed_with_rpm()
On Wed, Jul 18, 2018 at 04:56:39PM -0400, Lyude Paul wrote:
> When DP MST hubs get confused, they can occasionally stop responding for
> a good bit of time up until the point where the DRM driver manages to
> do the right DPCD accesses to get it to start responding again. In a
> worst case scenario however, this process can take upwards of 10+
> seconds.
>
> Currently we use
2018 Feb 12
0
[PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers
...'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 seeing deadlocks is because the output poll
worker is not enabled. And the output poll worker is not enabled
because...
2018 Feb 12
0
[PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers
...nd 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
2018 Aug 07
0
[PATCH v5 10/13] drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()
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:
2019 Jun 24
0
[EXTERNAL] Re: Fixing Drops With SMART1500LCDXL & USB-HID Driver
Updates on this:
1) Making progress in the related Dev list thread here: https://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
2018 Aug 06
1
[PATCH v4 7/8] drm/nouveau: Fix deadlocks in nouveau_connector_detect()
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
2018 Mar 06
0
[PATCH v2 0/7] Modernize vga_switcheroo by using device link for HDA
On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> Modernize vga_switcheroo by using a device link to enforce a runtime PM
> dependency from an HDA controller to the GPU it's integrated into, v2.
>
> Changes since v1:
>
> - Replace patch [1/7] to use pci_save_state() / pci_restore_state()
> for consistency between runtime PM code path of bound and unbound
2017 Jun 13
13
[Bug 101404] New: GTX 970M (GM204-A) not powered off when not in use (DynPwr in stead of DynOff)
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