search for: acpi_state_d3_cold

...pci_write_config_word(PCI_PM_CTRL, D3hot) <-- set to D3hot > __pci_complete_power_transition(D3cold) > pci_platform_power_transition(D3cold) > platform_pci_set_power_state(D3cold) > acpi_pci_set_power_state(D3cold) > acpi_device_set_power(ACPI_STATE_D3_COLD) > ... > acpi_evaluate_object("_OFF") <-- set to D3cold > > I did not understand the connection with platform (ACPI) power > management from your patch. It sounds like you want this entire path > except that you want to skip the PCI_...

On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote: > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port > can be runtime-suspended which disables power resources via ACPI. This > is incompatible with DSM, resulting in a GPU device which is still in D3 > and locks up the kernel on resume. > > Mirror the behavior of Windows 8 and newer[1] (as

...; > It is indeed set whenever there is any _PRx method. I wonder if it is > appropriate to access fields directly like this, perhaps this would be > more accurate (based on device_pm.c): > > /* Check whether the _PR3 method is available. */ > return adev->power.states[ACPI_STATE_D3_COLD].flags.valid; > > I am also considering adding a check in case the pcieport driver does > not support D3cold via runtime PM, what do you think of this? > > if (!parent_pdev) > return false; > /* If the PCIe port does not support D3cold via runtime PM, allow a...

...x method. I wonder if it is > > > appropriate to access fields directly like this, perhaps this would be > > > more accurate (based on device_pm.c): > > > > > > /* Check whether the _PR3 method is available. */ > > > return adev->power.states[ACPI_STATE_D3_COLD].flags.valid; > > > > > > I am also considering adding a check in case the pcieport driver does > > > not support D3cold via runtime PM, what do you think of this? > > > > > > if (!parent_pdev) > > > return false; > > >...

...is > > > > appropriate to access fields directly like this, perhaps this would be > > > > more accurate (based on device_pm.c): > > > > > > > > /* Check whether the _PR3 method is available. */ > > > > return adev->power.states[ACPI_STATE_D3_COLD].flags.valid; > > > > > > > > I am also considering adding a check in case the pcieport driver does > > > > not support D3cold via runtime PM, what do you think of this? > > > > > > > > if (!parent_pdev) > > > > r...

...- set to D3hot > > > __pci_complete_power_transition(D3cold) > > > pci_platform_power_transition(D3cold) > > > platform_pci_set_power_state(D3cold) > > > acpi_pci_set_power_state(D3cold) > > > acpi_device_set_power(ACPI_STATE_D3_COLD) > > > ... > > > acpi_evaluate_object("_OFF") <-- set to D3cold > > > > > > I did not understand the connection with platform (ACPI) power > > > management from your patch. It sounds like you want this enti...

...therwise this looks okay to me. It is indeed set whenever there is any _PRx method. I wonder if it is appropriate to access fields directly like this, perhaps this would be more accurate (based on device_pm.c): /* Check whether the _PR3 method is available. */ return adev->power.states[ACPI_STATE_D3_COLD].flags.valid; I am also considering adding a check in case the pcieport driver does not support D3cold via runtime PM, what do you think of this? if (!parent_pdev) return false; /* If the PCIe port does not support D3cold via runtime PM, allow a * fallback to the Optimus DSM...

...CI_PM_CTRL, D3hot) <-- set to D3hot > > __pci_complete_power_transition(D3cold) > > pci_platform_power_transition(D3cold) > > platform_pci_set_power_state(D3cold) > > acpi_pci_set_power_state(D3cold) > > acpi_device_set_power(ACPI_STATE_D3_COLD) > > ... > > acpi_evaluate_object("_OFF") <-- set to D3cold > > > > I did not understand the connection with platform (ACPI) power > > management from your patch. It sounds like you want this entire path > > except...

...whenever there is any _PRx method. I wonder if it is > > appropriate to access fields directly like this, perhaps this would be > > more accurate (based on device_pm.c): > > > > /* Check whether the _PR3 method is available. */ > > return adev->power.states[ACPI_STATE_D3_COLD].flags.valid; > > > > I am also considering adding a check in case the pcieport driver does > > not support D3cold via runtime PM, what do you think of this? > > > > if (!parent_pdev) > > return false; > > /* If the PCIe port does not supp...

but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the platform means of putting the device into D3cold, right? That's actually what should still happen, just the D3hot step should be skipped. On Wed, Oct 16, 2019 at 9:14 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > On Wed, Oct 16, 2019 at 04:44:49PM +0200, Karol Herbst wrote: > > Fixes state transitions of

..._raw_set_power_state pci_write_config_word(PCI_PM_CTRL, D3hot) <-- set to D3hot __pci_complete_power_transition(D3cold) pci_platform_power_transition(D3cold) platform_pci_set_power_state(D3cold) acpi_pci_set_power_state(D3cold) acpi_device_set_power(ACPI_STATE_D3_COLD) ... acpi_evaluate_object("_OFF") <-- set to D3cold I did not understand the connection with platform (ACPI) power management from your patch. It sounds like you want this entire path except that you want to skip the PCI_PM_CTRL write? That seems li...