search for: device_pm

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

...if it has power resources in general, not necessarily _PR3. > > > > Otherwise 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? > >...

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

...> > > > Otherwise 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 &gt...

...thought it > returns true if it has power resources in general, not necessarily _PR3. > > Otherwise 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 fal...

...eneral, not necessarily _PR3. > > > > > > Otherwise 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...