search for: pci_d3cold_disable

...ev; - - if (!parent_pdev) - return false; - - if (!parent_pdev->bridge_d3) { - /* - * Parent PCI bridge is currently not power managed. - * Since userspace can change these afterwards to be on - * the safe side we stick with _DSM and prevent usage of - * _PR3 from the bridge. - */ - pci_d3cold_disable(pdev); - return false; - } - - parent_adev = ACPI_COMPANION(&parent_pdev->dev); - if (!parent_adev) - return false; - - return parent_adev->power.flags.power_resources && - acpi_has_method(parent_adev->handle, "_PR3"); -} - static void nouveau_dsm_pci_probe(struct...

On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst <kherbst at redhat.com> wrote: > > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > > > <mika.westerberg at intel.com> wrote:

...supported? In other words, something like this: nouveau_dsm_pci_probe() { ... if (retval & (NOUVEAU_DSM_HAS_OPT | NOUVEAU_DSM_HAS_MUX)) { /* * We have custom _DSM method to power down the card so * prevent the PCI core from transitioning the * card into D3cold. */ pci_d3cold_disable(pdev); } } (Not sure about those flags above, though). Yes, it does not follow Windows 8+ but if it works... ;-) > There is a wealth of acpidumps on Launchpad bug 752542 > (https://bugs.launchpad.net/bugs/752542). Search for example for > comments in early 2015 or before, those will...

...pdev) if (!parent_pdev) return false; + if (!parent_pdev->bridge_d3) { + /* + * Parent PCI bridge is currently not power managed. + * Since userspace can change these afterwards to be on + * the safe side we stick with _DSM and prevent usage of + * _PR3 from the bridge. + */ + pci_d3cold_disable(pdev); + return false; + } + parent_adev = ACPI_COMPANION(&parent_pdev->dev); if (!parent_adev) return false; -- 2.9.3

..._pci_complete_power_transition); diff --git a/include/linux/pci.h b/include/linux/pci.h index 024a1beda008..ae42289662df 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -1147,6 +1147,8 @@ void pci_pme_wakeup_bus(struct pci_bus *bus); void pci_d3cold_enable(struct pci_dev *dev); void pci_d3cold_disable(struct pci_dev *dev); bool pcie_relaxed_ordering_enabled(struct pci_dev *dev); +void pci_wakeup_bus(struct pci_bus *bus); +void pci_bus_set_current_state(struct pci_bus *bus, pci_power_t state); /* PCI Virtual Channel */ int pci_save_vc_state(struct pci_dev *dev); -- 2.15.1

...ower savings in my testing. > > OK > > What exactly did you do to skip D3cold in your testing? > For that I poked into the PCI registers directly and skipped doing the ACPI calls and simply checked for the idle power consumption on my laptop. But I guess I should retest with calling pci_d3cold_disable from nouveau instead? Or is there a different preferable way of testing this?

...lting in a GPU device which is still in D3 and locks up the kernel on resume (on a Clevo P651RA, GTX965M). Mirror the behavior of Windows 8 and newer[1] (as observed via an AMLi debugger trace) and stop using the DSM functions for D3cold when power resources are available on the parent PCIe port. pci_d3cold_disable() is not used because on some machines, the old DSM method is broken. On a Lenovo T440p (GT 730M) memory and disk corruption would occur, but that is fixed with this patch[2]. [1]: https://msdn.microsoft.com/windows/hardware/drivers/bringup/firmware-requirements-for-d3cold [2]: https://github.co...

Hi, Here are two patches to fix an issue reported on kernel bugzilla (infinite loop due to unchecked function) and a more important fix to fix hanging Optimus machines when runtime PM is enabled (with pm/pci patches). See the first version[1] for a background on the fixed problems. This is the second revision of incorporating feedback from Emil Velikov (patch 1), Mika Westerberg (patch 4).

On Mon, May 30, 2016 at 06:13:51PM +0200, Peter Wu wrote: > Do you have any suggestions for the case where the pcieport driver > refuses to put the bridge in D3 (because the BIOS is too old)? In that > case the nouveau driver needs to fallback to the DSM method (but not > when runtime PM is deliberately disabled by writing control=on). Do you know what Windows does then? I think we

...D3cold in your testing? > > > > For that I poked into the PCI registers directly and skipped doing the > ACPI calls and simply checked for the idle power consumption on my > laptop. That doesn't involve the PCIe port PM, however. > But I guess I should retest with calling pci_d3cold_disable > from nouveau instead? Or is there a different preferable way of > testing this? There is a sysfs attribute called "d3cold_allowed" which can be used for "blocking" D3cold, so can you please retest using that?

Hi, Here are two patches to fix an issue reported on kernel bugzilla (infinite loop due to unchecked function) and a more important fix to fix hanging Optimus machines when runtime PM is enabled (with pm/pci patches). These are the final patches targeting v4.8. Changes compared to v2[1]: collected R-b from Hans and Mika and fixed a minor comment style issue. I recommend it to be merged before

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

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