similar to: [PATCH] drm: fix issue by messing up runpm usage_counter

On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: > nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0, > but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally. > We therefore leak a runtime pm ref whenever nouveau is loaded with > runpm=0 and then unloaded. The GPU will subsequently never runtime > suspend even if nouveau is loaded again

In preparation for runtime pm on muxed dual GPU laptops, I've fixed all runtime pm ref leaks I could find in nouveau, radeon and amdgpu. To ease reviewing, I've pushed this series to GitHub: https://github.com/l1k/linux/commits/drm_runpm_fixes_v1 @Alex Deucher: I do not have an AMD GPU so couldn't test this beyond verifying that it compiles. Please double-check the patches and test

Hi Peter, On Fri, May 27, 2016 at 03:07:33AM +0200, Peter Wu wrote: > On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: > > nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0, > > but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally. > > We therefore leak a runtime pm ref whenever nouveau is loaded with > > runpm=0 and then

Second iteration of my endeavour to rid nouveau, radeon and amdgpu of runtime pm ref leaks. Patches 1 to 8 are identical to v1. Patch 9 of v1 modified the DRM core to turn off all CRTCs on driver unload. Based on feedback by Daniel Vetter, I've replaced this with a helper to turn off all CRTCs, which is called by nouveau, radeon and amdgpu on unload. In other words, this is now opt-in. So

nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0, but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally. We therefore leak a runtime pm ref whenever nouveau is loaded with runpm=0 and then unloaded. The GPU will subsequently never runtime suspend even if nouveau is loaded again with runpm=1. Fix by taking the runtime pm ref under the same condition that it was

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

We received a donation of a Titan which has this useless feature allowing users to control the brightness of the LED behind the logo of NVIDIA. In the true spirit of open source, let's expose that to the users of very expensive cards! This patch hooks up this LED/PWM to the LED subsystem which allows blinking it in sync with cpu/disk/network/whatever activity (heartbeat is quite nice!). Users

On 23/08/16 11:31, Karol Herbst wrote: > maybe it makes sense to expose the SLI LED, too. > > Regardless of my comments this patch is reviewed-by me. You reviewed the wrong patch, I should have named the re-send v3. I accidentally sent the v1 patch as a v2 :s > > 2016-08-23 1:39 GMT+02:00 Martin Peres <martin.peres at free.fr>: >> We received a donation of a Titan

On Sun, May 29, 2016 at 05:50:06PM +0200, Lukas Wunner wrote: > Hi Peter, > > On Fri, May 27, 2016 at 03:07:33AM +0200, Peter Wu wrote: > > On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: > > > nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0, > > > but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally. > >

[+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime) resume")] On Fri, Mar 22, 2019 at 06:30:15AM -0500, Bjorn Helgaas wrote: > On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote: > > On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote: > > > On Fri, 2019-02-15 at 16:17 -0500, Lyude Paul wrote: > > > > On Thu,

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

> 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

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

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

https://bugs.freedesktop.org/show_bug.cgi?id=93065 Bug ID: 93065 Summary: nouveau kernel module needs to increase runpm use counter more often Product: xorg Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=70464 Priority: medium Bug ID: 70464 Assignee: nouveau at lists.freedesktop.org Summary: [NVC3] runpm not working QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: michele.cane at gmail.com

On Thu, Nov 29, 2018 at 2:29 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Thu, Nov 29, 2018 at 12:21:31AM +0100, Karol Herbst wrote: > > this was already debugged and there is no point in searching inside > > the Firmware. It's not a firmware bug or anything. > > > > The proper fix is to do something inside Nouveau so that we don't > >

On Wed, Nov 28, 2018 at 10:09:22AM -0500, Michael S. Tsirkin wrote: > Yea all this is weird, in particular I wonder why does everyone > using dsm insists on saying Arg4 > when they actually mean Arg3. ACPI numbers arguments from 0. > > So it's a bit ugly, and maybe worth fixing but unlikely to be > an actual issue simply because we end up not using DSM in the end. I agree.

Fix a deadlock on hybrid graphics laptops that's been present since 2013: DRM drivers poll connectors in 10 sec intervals. The poll worker is stopped on ->runtime_suspend with cancel_delayed_work_sync(). However the poll worker invokes the DRM drivers' ->detect callbacks, which call pm_runtime_get_sync(). If the poll worker starts after runtime suspend has begun,