search for: pm_runtime_suspended

On Tue, Jul 17, 2018 at 02:24:31PM -0400, Lyude Paul wrote: > On Tue, 2018-07-17 at 20:20 +0200, Lukas Wunner wrote: > > Okay, the PCI device is suspending and the nvkm_i2c_aux_acquire() > > wants it in resumed state, so is waiting forever for the device to > > runtime suspend in order to resume it again immediately afterwards. > > > > The deadlock in the stack

On Tue, Jul 17, 2018 at 12:53:11PM -0400, Lyude Paul wrote: > On Tue, 2018-07-17 at 09:16 +0200, Lukas Wunner wrote: > > On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: > > > In order to fix all of the spots that need to have runtime PM get/puts() > > > added, we need to ensure that it's possible for us to call > > > pm_runtime_get/put() in any

...rid of vga_switcheroo_set_dynamic_switch() to solve this. The function has two purposes: Number one, vga_switcheroo updates its internal power state representation for the GPU. That is actually pointless for driver power control because we can always query the driver core for this information (e.g. pm_runtime_suspended()). The second purpose is to switch the audio client on and off. If we would use a "device link" to express the dependency between the audio device and the GPU, we wouldn't need this. So moving to "device links" is a prerequisite to make runtime pm work for muxed laptops. I...

...subdev->device->dev; int pstate; if (!atomic_xchg(&clk->waiting, 0)) @@ -345,7 +346,14 @@ nvkm_clk_update_work(struct work_struct *work) pstate = NVKM_CLK_PSTATE_DEFAULT; } - clk->func->update(clk, pstate); + // only call into the code if the GPU is powered on + if (!pm_runtime_suspended(dev)) { + // it would be a shame if the GPU goes into suspend + // while doing the reclock + pm_runtime_get_sync(dev); + clk->func->update(clk, pstate); + pm_runtime_put(dev); + } wake_up_all(&clk->wait); nvkm_notify_get(&clk->pwrsrc_ntfy); -- 2.12.0

On Tue, 2018-07-17 at 20:32 +0200, Lukas Wunner wrote: > On Tue, Jul 17, 2018 at 02:24:31PM -0400, Lyude Paul wrote: > > On Tue, 2018-07-17 at 20:20 +0200, Lukas Wunner wrote: > > > Okay, the PCI device is suspending and the nvkm_i2c_aux_acquire() > > > wants it in resumed state, so is waiting forever for the device to > > > runtime suspend in order to resume it

On Tue, 2018-07-17 at 20:20 +0200, Lukas Wunner wrote: > On Tue, Jul 17, 2018 at 12:53:11PM -0400, Lyude Paul wrote: > > On Tue, 2018-07-17 at 09:16 +0200, Lukas Wunner wrote: > > > On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: > > > > In order to fix all of the spots that need to have runtime PM get/puts() > > > > added, we need to ensure

On Tue, Jul 17, 2018 at 8:20 PM, Lukas Wunner <lukas at wunner.de> wrote: > On Tue, Jul 17, 2018 at 12:53:11PM -0400, Lyude Paul wrote: >> On Tue, 2018-07-17 at 09:16 +0200, Lukas Wunner wrote: >> > On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: >> > > In order to fix all of the spots that need to have runtime PM get/puts() >> > > added,

Back in 2013, runtime PM for GPUs with integrated HDA controller was introduced with commits 0d69704ae348 ("gpu/vga_switcheroo: add driver control power feature. (v3)") and 246efa4a072f ("snd/hda: add runtime suspend/resume on optimus support (v4)"). Briefly, the idea was that the HDA controller is forced on and off in unison with the GPU. The original code is mostly still in

On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote: > Back in 2013, runtime PM for GPUs with integrated HDA controller was > introduced with commits 0d69704ae348 ("gpu/vga_switcheroo: add driver > control power feature. (v3)") and 246efa4a072f ("snd/hda: add runtime > suspend/resume on optimus support (v4)"). > > Briefly, the idea was that the HDA

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

[cc += linux-pm] Hi Lyude, First of all, thanks a lot for looking into this. On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: > In order to fix all of the spots that need to have runtime PM get/puts() > added, we need to ensure that it's possible for us to call > pm_runtime_get/put() in any context, regardless of how deep, since > almost all of the spots that are

After resuming more than once on battery these HP Ivybridge laptops, the XHCI devices stop working. Have anyone seen this before? I wanted to check before diving in deeper. Let me know if you have any ideas. Thanks! Facts - Xen 4.0.3, Linux 3.2.7 PVOPs - Happens on HP Ivybridge. Doesn''t happen on very similar HP Sandybridge Clash system. - Happens on battery, but not on AC. -

This series addresses various issues inside the reclocking code: 1. after resume the set clocks are reset 2. reclocking not possible while GPU is suspended Some of the patches were part of the bigger reclocking series I sent months ago, some things have changed though. This is also preparation work of changing the clock state due to temperature changes and dynamic reclocking. v2: remove commits

This series addresses various issues inside the reclocking code: 1. after resume the set clocks are reset 2. reclocking not possible while GPU is suspended 3. nouveau always does full reclocks even if only a change of the voltage is required Some of the patches were part of the bigger reclocking series I sent months ago, some things have changed though. This is also preparation work of

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

Adds Nouveau controlled thermal throttling for Kepler+ GPUs. With this I feel safe enough to add support for Maxwell2 reclocking later on (still hidden behind a switch, but we can be fairly sure to not overheat hardware if a user isn't carefull enough) Contains all patches from my clk update series, but I thought it makes sense to include those in this series as well for completness. Please

these are usually used for dynamic reclocking on gt215 and newer The counters are used to get the load of the core, memory, video and pcie loads currently I expose the loads through a debugfs "current_load" file, but I want to move that to nvif and just add a wrapper around that in debugfs for convenience Anyway there are still some issues I would like to discuss: 1. currently the

these are usually used for dynamic reclocking on gt215 and newer The counters are used to get the load of the core, memory, video and pcie loads currently I expose the loads through a debugfs "current_load" file, but I want to move that to nvif and just add a wrapper around that in debugfs for convenience. Using nvif would have the advantage, that userspace tools can easily get loads

reworked this series quite a lot. Now we want the Host to configure the counters through the PMU. The series isn't complete though because it needs: 1. reordering 2. better commit messages but I felt like sending those out before doing a final version. I also found some weird register overwriting issue on the PMU I have to track down, because it interfers with the counter read out. I am

I think I am done reworking the series and getting to a point where I think it is basically finished. The configuration of the slots could be improved later on when working on dynamic reclocking, but for now it's good enough to report the current GPU utilization to userspace. Patches 1-4 imeplement PMU commands to setup and readout the counters. Patches 5-6 lets Nouveau make use of 1-4. Patch