Displaying 10 results from an estimated 10 matches for "_prx".
Did you mean:
_prt
2019 Oct 21
2
[PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...t; >
> > Those should be documented in the ACPI spec. Chapter 7 should explain
> > power resources and the device power methods in detail.
>
> either I looked up the wrong spec or the documentation isn't really
> saying much there.
Well it explains those methods, _PSx, _PRx and _ON()/_OFF(). In case of
PCIe device you also want to check PCIe spec. PCIe 5.0 section 5.8 "PCI
Function Power State Transitions" has a picture about the supported
power state transitions and there we can find that function must be in
D3hot before it can be transitioned into D3cold s...
2016 May 25
3
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime 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
2016 May 30
2
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
...ags.power_resources;
> >
> > Is this sufficient to tell if the parent device has _PR3? I 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 al...
2016 May 30
3
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
...sufficient to tell if the parent device has _PR3? I 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[A...
2016 May 30
0
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
...parent device has _PR3? I 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. */
> > > > retur...
2016 May 27
0
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
...> > + return ad->power.flags.power_resources;
>
> Is this sufficient to tell if the parent device has _PR3? I 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 ca...
2019 Oct 22
0
[PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...pec. Chapter 7 should explain
> > > > power resources and the device power methods in detail.
> > >
> > > either I looked up the wrong spec or the documentation isn't really
> > > saying much there.
> >
> > Well it explains those methods, _PSx, _PRx and _ON()/_OFF(). In case of
> > PCIe device you also want to check PCIe spec. PCIe 5.0 section 5.8 "PCI
> > Function Power State Transitions" has a picture about the supported
> > power state transitions and there we can find that function must be in
> > D3hot bef...
2019 Oct 21
2
[PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Mon, Oct 21, 2019 at 03:54:09PM +0200, Karol Herbst wrote:
> > I really would like to provide you more information about such
> > workaround but I'm not aware of any ;-) I have not seen any issues like
> > this when D3cold is properly implemented in the platform. That's why
> > I'm bit skeptical that this has anything to do with specific Intel PCIe
> >
2019 Oct 21
1
[PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
...ld be documented in the ACPI spec. Chapter 7 should explain
> > > power resources and the device power methods in detail.
> >
> > either I looked up the wrong spec or the documentation isn't really
> > saying much there.
>
> Well it explains those methods, _PSx, _PRx and _ON()/_OFF(). In case of
> PCIe device you also want to check PCIe spec. PCIe 5.0 section 5.8 "PCI
> Function Power State Transitions" has a picture about the supported
> power state transitions and there we can find that function must be in
> D3hot before it can be transi...
2016 May 30
0
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
...> > > Is this sufficient to tell if the parent device has _PR3? I 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....