search for: _pr3

...eeds 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 should do the same if > > possible. > > If the BIOS is too old, then it probably does not have _PR3 objects nor > calls to _OSI("Windows 2013"). See below. > > > If user has disabled runtime PM from the root port deliberately, there > > might be good reason to do so. Why we want to fallback to something that > > could cause problems? I mean _DSM on such systems...

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

Replace nouveau_pr3_present() in favor of a more generic one, pci_pr3_present(). Also the presence of upstream bridge _PR3 doesn't need to go hand in hand with device's _DSM, so check _PR3 before _DSM. Signed-off-by: Kai-Heng Feng <kai.heng.feng at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_ac...

...> 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 should do the same if > possible. If the BIOS is too old, then it probably does not have _PR3 objects nor calls to _OSI("Windows 2013"). See below. > If user has disabled runtime PM from the root port deliberately, there > might be good reason to do so. Why we want to fallback to something that > could cause problems? I mean _DSM on such systems is probably not that >...

...i_extract_power_resources is failing. Note that in the > > SSDT, the power resource NVP3 was referenced before it was defined, > > could that result in this enumeration failure? Relevant SSDT excerpt: > > > > Scope (\_SB.PCI0.RP05) > > { > > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > > { > > NVP3 > > }) > > // ... > > } > > > > PowerResource (NVP3, 0x00, 0x0000) Looks wrong order to me. However, _PR3 is a package, for AML opcode that cont...

...d is indeed a package with some elements, it seems that acpi_extract_power_resources is failing. Note that in the SSDT, the power resource NVP3 was referenced before it was defined, could that result in this enumeration failure? Relevant SSDT excerpt: Scope (\_SB.PCI0.RP05) { Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot { NVP3 }) // ... } PowerResource (NVP3, 0x00, 0x0000) Kind regards, Peter > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c > index fcd4ce6f78d5..af9c3e15dd74 100644 > --- a/drivers/...

...cheroo_handler nouveau_dsm_handler = { > .get_client_id = nouveau_dsm_get_client_id, > }; > > +/* Firmware supporting Windows 8 or later do not use _DSM to put the device into > + * D3cold, they instead rely on disabling power resources on the parent. */ > +static bool nouveau_pr3_present(struct pci_dev *pdev) > +{ > + struct pci_dev *parent_pdev = pci_upstream_bridge(pdev); > + struct acpi_device *ad; Nit: please call this adev instead of ad. > + > + if (!parent_pdev) > + return false; > + > + ad = ACPI_COMPANION(&parent_pdev->dev); > +...

...e should instead happen: - \_SB.PCI0.RP05.PEGP._PS3 (does nothing besides updating _STA) - PCIe core removes power for the PCIe port since all its children are in D3 and are willing to transition to D3cold. It does so by invoking \NVP3._OFF (where \NVP3 is the power resource from \_SB.PCI0.RP05._PR3) That is how I think it should work in theory, but on Ricks laptop running 4.8.4, /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 devices (which I do have on my own laptop for 0000:01:0). The SSDT1 of Rick's Acer laptop shows this structure: If (\_OSI ("Wi...

...> > > }; > > > > > > > > > > +/* Firmware supporting Windows 8 or later do not use _DSM to put the device into > > > > > + * D3cold, they instead rely on disabling power resources on the parent. */ > > > > > +static bool nouveau_pr3_present(struct pci_dev *pdev) > > > > > +{ > > > > > + struct pci_dev *parent_pdev = pci_upstream_bridge(pdev); > > > > > + struct acpi_device *ad; > > > > > > > > Nit: please call this adev instead of ad. > > > > &g...

...report for a GT 525M (laptop brand/model unknown). Maybe there are more affected users, but then they did not notice it because they did not use HDMI audio. > > > > The powered on issue will also only appear on devices produced in 2013 > > and newer that happen to have this ACPI _PR3 ACPI method (which is quite > > common for new machines supporting Windows 8 though). > > > > For these newer laptops, after the pci/pm merge and after a patch like > > http://www.spinics.net/lists/linux-pci/msg52601.html, the user can > > revert to the old DSM method...

..._client_id = nouveau_dsm_get_client_id, > > > }; > > > > > > +/* Firmware supporting Windows 8 or later do not use _DSM to put the device into > > > + * D3cold, they instead rely on disabling power resources on the parent. */ > > > +static bool nouveau_pr3_present(struct pci_dev *pdev) > > > +{ > > > + struct pci_dev *parent_pdev = pci_upstream_bridge(pdev); > > > + struct acpi_device *ad; > > > > Nit: please call this adev instead of ad. > > Will do. > > > > + > > > + if (!parent_p...

...B.PCI0.RP05.PEGP._PS3 (does nothing besides updating _STA) > > - PCIe core removes power for the PCIe port since all its children are in > > D3 and are willing to transition to D3cold. It does so by invoking > > \NVP3._OFF (where \NVP3 is the power resource from \_SB.PCI0.RP05._PR3) > > > > That is how I think it should work in theory, but on Ricks laptop running > > 4.8.4, > > /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 > > devices (which I do have on my own laptop for 0000:01:0). > > > > The SSDT1 of...

...; > > > > > > + if (!ad) > > > > > > + return false; > > > > > > + > > > > > > + 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 i...

...ailing. Note that in the > > > SSDT, the power resource NVP3 was referenced before it was defined, > > > could that result in this enumeration failure? Relevant SSDT excerpt: > > > > > > Scope (\_SB.PCI0.RP05) > > > { > > > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > > > { > > > NVP3 > > > }) > > > // ... > > > } > > > > > > PowerResource (NVP3, 0x00, 0x0000) > > Looks wrong order to me. > &g...

...1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c b/drivers/gpu/drm/nouveau/nouveau_acpi.c index dc57b62..193573d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c @@ -240,7 +240,8 @@ static bool nouveau_pr3_present(struct pci_dev *pdev) if (!parent_adev) return false; - return acpi_has_method(parent_adev->handle, "_PR3"); + return parent_adev->power.flags.power_resources && + acpi_has_method(parent_adev->handle, "_PR3"); } static void nouveau_dsm_pci_pr...

...ork in these cases where PR does not). This is a workaround for a problem where ACPICA and Windows 10 differ in behavior. ACPICA does not correctly enumerate power resources within a conditional block (due to delayed execution of such blocks) and as a result power_resources is set to false even if _PR3 exists. Fixes: 692a17dcc292 ("drm/nouveau/acpi: fix lockup with PCIe runtime PM") Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398 Reported-and-tested-by: Rick Kerkhof <rick.2889 at gmail.com> Reviewed-by: Mika Westerberg <mika.westerberg at linux.intel.com> Signed-of...

...dler = { > > .get_client_id = nouveau_dsm_get_client_id, > > }; > > > > +/* Firmware supporting Windows 8 or later do not use _DSM to put the device into > > + * D3cold, they instead rely on disabling power resources on the parent. */ > > +static bool nouveau_pr3_present(struct pci_dev *pdev) > > +{ > > + struct pci_dev *parent_pdev = pci_upstream_bridge(pdev); > > + struct acpi_device *ad; > > Nit: please call this adev instead of ad. Will do. > > + > > + if (!parent_pdev) > > + return false; > > + > &...

....freedesktop.org/show_bug.cgi?id=75985). For my laptop I also had to runtime suspend/resume before lspci -H1 shows the device, loading with runpm=0 didn't return my HDMI audio device. The powered on issue will also only appear on devices produced in 2013 and newer that happen to have this ACPI _PR3 ACPI method (which is quite common for new machines supporting Windows 8 though). For these newer laptops, after the pci/pm merge and after a patch like http://www.spinics.net/lists/linux-pci/msg52601.html, the user can revert to the old DSM method by booting with pcie_port_pm=off which will retai...

...ds to fallback to the DSM method (but not > when runtime PM is deliberately disabled by writing control=on). The BIOS cut-off date is meant to avoid issues when suspending ports on older chipsets. However if the port is used for an Optimus GPU and we can clearly identify that, and there's a _PR3 method provided, it's probably safe to say that the port is *intended* to be suspended. So you may want to consider amending pci_bridge_d3_possible() to allow D3 for such ports regardless of the BIOS date, as I've done for Thunderbolt in this commit: https://github.com/l1k/linux/commit/3cb...

...get_client_id, > > > > }; > > > > > > > > +/* Firmware supporting Windows 8 or later do not use _DSM to put the device into > > > > + * D3cold, they instead rely on disabling power resources on the parent. */ > > > > +static bool nouveau_pr3_present(struct pci_dev *pdev) > > > > +{ > > > > + struct pci_dev *parent_pdev = pci_upstream_bridge(pdev); > > > > + struct acpi_device *ad; > > > > > > Nit: please call this adev instead of ad. > > > > Will do. > > > &g...