search for: pm_runtime_suspend

...g(dev))) { > > ret = pm_runtime_get_sync(dev); > > if (ret < 0 && ret != -EACCES) > > return ret; > > } > > > > But here's the catch: This only works for an *async* runtime suspend. > > It doesn't work for pm_runtime_put_sync(), pm_runtime_suspend() etc, > > because then the runtime suspend is executed in the context of the caller, > > not in the context of dev->power.work. > > > > So it's not a full solution, but hopefully something that gets you > > going. I'm not really familiar with the code pat...

...gt;dev; if (!(is_pm_work(dev) && pm_runtime_status_suspending(dev))) { ret = pm_runtime_get_sync(dev); if (ret < 0 && ret != -EACCES) return ret; } But here's the catch: This only works for an *async* runtime suspend. It doesn't work for pm_runtime_put_sync(), pm_runtime_suspend() etc, because then the runtime suspend is executed in the context of the caller, not in the context of dev->power.work. So it's not a full solution, but hopefully something that gets you going. I'm not really familiar with the code paths leading to nvkm_i2c_aux_acquire() to come up wi...

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

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

...m_runtime_get_sync(dev); > > > if (ret < 0 && ret != -EACCES) > > > return ret; > > > } > > > > > > But here's the catch: This only works for an *async* runtime suspend. > > > It doesn't work for pm_runtime_put_sync(), pm_runtime_suspend() etc, > > > because then the runtime suspend is executed in the context of the caller, > > > not in the context of dev->power.work. > > > > > > So it's not a full solution, but hopefully something that gets you > > > going. I'm not really f...

...p;& pm_runtime_status_suspending(dev))) { > ret = pm_runtime_get_sync(dev); > if (ret < 0 && ret != -EACCES) > return ret; > } > > But here's the catch: This only works for an *async* runtime suspend. > It doesn't work for pm_runtime_put_sync(), pm_runtime_suspend() etc, > because then the runtime suspend is executed in the context of the caller, > not in the context of dev->power.work. > > So it's not a full solution, but hopefully something that gets you > going. I'm not really familiar with the code paths leading to > nvkm_i...

...ret = pm_runtime_get_sync(dev); > if (ret < 0 && ret != -EACCES) > return ret; > } > > But here's the catch: This only works for an *async* runtime suspend. > It doesn't work for pm_runtime_put_sync(), pm_runtime_suspend() etc, > because then the runtime suspend is executed in the context of the caller, > not in the context of dev->power.work. > > So it's not a full solution, but hopefully something that gets you > going. I'm not really familiar with the code paths leading to > nvkm_i2...

..._dev *pci, dev_info(chip->card->dev, "%s via vga_switcheroo\n", disabled ? "Disabling" : "Enabling"); if (disabled) { - pm_runtime_put_sync_suspend(card->dev); - azx_suspend(card->dev); + list_for_each_codec(codec, &chip->bus) { + pm_runtime_suspend(hda_codec_dev(codec)); + pm_runtime_disable(hda_codec_dev(codec)); + } + pm_runtime_suspend(card->dev); + pm_runtime_disable(card->dev); /* when we get suspended by vga_switcheroo we end up in D3cold, * however we have no ACPI handle, so pci/acpi can't put us there,...

...t;card->dev, "%s via vga_switcheroo\n", > disabled ? "Disabling" : "Enabling"); > if (disabled) { > - pm_runtime_put_sync_suspend(card->dev); > - azx_suspend(card->dev); > + list_for_each_codec(codec, &chip->bus) { > + pm_runtime_suspend(hda_codec_dev(codec)); > + pm_runtime_disable(hda_codec_dev(codec)); > + } > + pm_runtime_suspend(card->dev); > + pm_runtime_disable(card->dev); > /* when we get suspended by vga_switcheroo we end up in D3cold, > * however we have no ACPI handle, so pci/acp...

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