similar to: [PATCH 0/9] Fix runtime pm ref leaks

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

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

On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: > When a drm_crtc structure is destroyed with drm_crtc_cleanup(), the DRM > core does not turn off the crtc first and neither do the drivers. With > nouveau, radeon and amdgpu, this causes a runtime pm ref to be leaked on > driver unload if at least one crtc was enabled. > > (See usage of have_disp_power_ref in

On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner <lukas at wunner.de> wrote: > > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote: >> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: >> > When a drm_crtc structure is destroyed with drm_crtc_cleanup(), the DRM >> > core does not turn off the crtc first and neither do the drivers. With

On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote: > On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote: > > On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner <lukas at wunner.de> wrote: > > > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote: > > >> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: > > >>

On Fri, Jun 03, 2016 at 09:30:06AM +0200, Lukas Wunner wrote: > On Wed, Jun 01, 2016 at 04:40:12PM +0200, Daniel Vetter wrote: > > On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote: > > > On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote: > > > > On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner <lukas at wunner.de> wrote: > > > >

This is the latest version of https://patchwork.freedesktop.org/series/45862/ . One new patch has been added that also addresses some additional issues I found with pmops_runtime_idle that would stop nouveau from suspending the GPU when running under X. Additionally, "drm/nouveau: Fix runtime PM leak in nv50_disp_atomic_commit()" has had it's CC to stable removed. Lyude Paul (3):

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

I have the issue when loading nouveau with runpm=0 set, that further nouveau loads without runpm set or runpm=1 don't put the card into sleep state. This is caused by calling pm_runtime_get_sync in drm_device.unload when the usage_counter isn't 0. pm_runtime_get_sync always increases the suage_counter and so the usage_counter gets increased allthough runpm=0 is set, meaning nouveau leaves

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

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

Fix Thunderbolt-related issues in apple-gmux and vga_switcheroo: Patch [1/5] ("Recognize Thunderbolt devices") has already been subjected to a fair amount of scrutiny over at linux-pci@, I've submitted it 5 times total since May 2016. With luck it may be in ack-able shape now. Patch [2/5] amends apple-gmux to handle combined DP/Thunderbolt ports properly on newer MacBook Pros.

On Fri, Feb 24, 2017 at 1:19 PM, Lukas Wunner <lukas at wunner.de> wrote: > An external Thunderbolt GPU can neither drive the laptop's panel nor be > powered off by the platform, so there's no point in registering it with > vga_switcheroo. > In fact, when the external GPU is runtime suspended, > vga_switcheroo will cut power to the internal discrete GPU, resulting in

This is especially true when variables or functions are just called dsm without specifying the v1. Changes since v1: * Fix typo in commit explanation * Change has_dsm to has_mux in nouveau_dsm_detect Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau/nouveau_acpi.c | 72 +++++++++++++++++++++++----------------------- drm/nouveau/nouveau_acpi.h | 4 +--

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 devices. (Rafael, Bjorn) - Patch [5/7]: Drop an unnecessary initialization. (Bjorn) Rephrase

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

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. Remove thereby obsoleted code and fix a bunch of bugs. Device links were introduced in v4.10. Users might see a small power saving if the discrete GPU is in use and its HDA controller is not, because the HDA controller is now allowed to runtime

This is a trimmed down version of https://patchwork.freedesktop.org/series/46637/ with all of the review comments addressed. The last version of this series had fixes for the i2c and DP aux busses to ensure that the GPU would be turned on whenever anything tried to access the i2c/aux busses. Unfortunately: one of the fixes apparently contained some very incorrect usage of Linux's runtime PM

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

This is especially true when variables or functions are just called dsm without precising the v1. Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau/nouveau_acpi.c | 64 +++++++++++++++++++++++----------------------- drm/nouveau/nouveau_acpi.h | 4 +-- drm/nouveau/nouveau_drm.c | 4 +-- drm/nouveau/nouveau_vga.c | 10 ++++---- 4 files changed, 41 insertions(+), 41