search for: parent_adev

...n(-) 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_probe(struct pci_dev *pdev, acpi_handle *dhandle_ou...

...- * 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 *parent_adev; - - 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. - */ - pc...

...+/* 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 *parent_adev; + + if (!parent_pdev) + return false; + + parent_adev = ACPI_COMPANION(&parent_pdev->dev); + if (!parent_adev) + return false; + + return acpi_has_method(parent_adev->handle, "_PR3"); +} + static void nouveau_dsm_pci_probe(struct pci_dev *pdev, acpi_handle *dhandle_out,...

...n(-) 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_probe(struct pci_dev *pdev, acpi_handle *dhandle_ou...

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).

...!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

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

...> > I suggested the no_d3cold check such that DSM can still be called even > though the runtime PM on the PCIe port does nothing. Somehow it does not feel right to poke parent device's fields directly. What if you just check if it has the method like: bool no_dsm = acpi_has_method(parent_adev->handle, "_PR3"); That should follow what Windows is doing. > > > Out of curiosity I looked up an pre-2015 laptop (found Acer V5-573G, > > > apparently from November 2013, Windows 8.1) and extracted the ACPI > > > tables from the BIOS images. BIOS 2.28 (201...

...d check such that DSM can still be called even > > though the runtime PM on the PCIe port does nothing. > > Somehow it does not feel right to poke parent device's fields directly. > > What if you just check if it has the method like: > > bool no_dsm = acpi_has_method(parent_adev->handle, "_PR3"); > > That should follow what Windows is doing. Checking for _PR3 was the intention, but it seems that the ACPI core does not really store it somewhere. Your check should be simple enough, I'll use that in the next version. Do you have any suggestions for t...

+Rafael On Fri, May 27, 2016 at 01:10:37PM +0200, Peter Wu wrote: > On Wed, May 25, 2016 at 04:55:35PM +0300, Mika Westerberg wrote: > > 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 > >