search for: power_resourc

...is runtime suspended (DSM should still work 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 a...

...okt. 2016 11:30 schreef Mika Westerberg < mika.westerberg at linux.intel.com>: > On Thu, Oct 27, 2016 at 09:15:19AM +0000, Rick Kerkhof wrote: > > I can confirm what Peter said, path contains \_SB_.PCI0.RP05 and > > power_state contains D3hot. > > And there are no power_resources_Dx directories under > /sys/bus/pci/devices/0000:00:1c.4/firmware_node? > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20161027/3617a181/attachment-0001.html>

...esg (or attach it > to that bug)? It should show if the ACPI core even tries to add those > power resources. So Rick has tested this patch now on top of 4.8.4 (mainline fails to boot due to a kbuild issue which I reported elsewhere), but the output is empty. That seems to indicate that flags.power_resources is unset. Given that _PS3 exists and 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: Scop...

...ivers/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_out, -- 2.10.1

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

...ries to add those > > > > power resources. > > > > > > So Rick has tested this patch now on top of 4.8.4 (mainline fails to > > > boot due to a kbuild issue which I reported elsewhere), but the output > > > is empty. That seems to indicate that flags.power_resources is unset. > > > > Is it completely empty or is it empty just for RP05? It should print out > > all devices with power resources. > > \NVP2 and \NVP3 are the only power resources under RP05 and defined in > SSDT1, there are no others. We should probably add a debug pr...

...ev = 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); > + 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.

...fterwards 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; - - 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_out, bool *has_mux, bool *has_opt, bool *has_opt_flags, bool *has_pr3) @@ -250,6 +219,16 @@ static void nouveau_dsm_pci_probe(s...

...ow if the ACPI core even tries to add those > > > power resources. > > > > So Rick has tested this patch now on top of 4.8.4 (mainline fails to > > boot due to a kbuild issue which I reported elsewhere), but the output > > is empty. That seems to indicate that flags.power_resources is unset. > > Is it completely empty or is it empty just for RP05? It should print out > all devices with power resources. > > > Given that _PS3 exists and is indeed a package with some elements, it > > seems that acpi_extract_power_resources is failing. Note that in the...

...tream_bridge(pdev); > + struct acpi_device *ad; > + > + if (!parent_pdev) > + return false; > + > + ad = ACPI_COMPANION(&parent_pdev->dev); > + if (!ad) > + return false; > + > + return ad->power.flags.power_resources; > +} > + > static void nouveau_dsm_pci_probe(struct pci_dev *pdev, bool *has_mux, > - bool *has_opt, bool *has_opt_flags) > + bool *has_opt, bool *has_opt_flags, > + bool *has_power...

...; Will do. > > > > + > > > + if (!parent_pdev) > > > + return false; > > > + > > > + ad = ACPI_COMPANION(&parent_pdev->dev); > > > + 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 wo...

...> + if (!parent_pdev) >> > + return false; >> > + >> > + ad = ACPI_COMPANION(&parent_pdev->dev); >> > + if (!ad) >> > + return false; >> > + >> > + return ad->power.flags.power_resources; >> > +} >> > + >> > static void nouveau_dsm_pci_probe(struct pci_dev *pdev, bool *has_mux, >> > - bool *has_opt, bool *has_opt_flags) >> > + bool *has_opt, bool *has_opt_flags, >>...

...gt; > > > > + return false; > > > > > + > > > > > + ad = ACPI_COMPANION(&parent_pdev->dev); > > > > > + 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. > > > &...

...to add those power resources. diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index fcd4ce6f78d5..af9c3e15dd74 100644 --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -444,6 +444,9 @@ void acpi_power_add_remove_device(struct acpi_device *adev, bool add) if (!adev->power.flags.power_resources) return; + acpi_handle_info(adev->handle, "Adding power resources for %s\n", + dev_name(&adev->dev)); + for (state = ACPI_STATE_D0; state <= ACPI_STATE_D3_HOT; state++) acpi_power_expose_hide(adev, &adev->power.states[state].resources,

...that bug)? It should show if the ACPI core even tries to add those > > power resources. > > So Rick has tested this patch now on top of 4.8.4 (mainline fails to > boot due to a kbuild issue which I reported elsewhere), but the output > is empty. That seems to indicate that flags.power_resources is unset. Is it completely empty or is it empty just for RP05? It should print out all devices with power resources. > Given that _PS3 exists and is indeed a package with some elements, it > seems that acpi_extract_power_resources is failing. Note that in the > SSDT, the power resource...

On Fri, Oct 28, 2016 at 02:30:41PM +0200, Peter Wu wrote: > It was correctly applied. I did some testing with QEMU, it seems that > the \_OSI check is problematic. Removing it makes things work again. I hope Bob and Lv can answer why _OSI fails. In the meantime I think we should check flags.power_resources in nouveau driver (in addition to _PR3) so that it falls back to _DSM if there are no power resources (or if we failed to evaluate them for some reason).

...M should still work 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 Westerbe...

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

...--git a/drivers/acpi/power.c b/drivers/acpi/power.c > index fcd4ce6f78d5..af9c3e15dd74 100644 > --- a/drivers/acpi/power.c > +++ b/drivers/acpi/power.c > @@ -444,6 +444,9 @@ void acpi_power_add_remove_device(struct acpi_device > *adev, bool add) > if (!adev->power.flags.power_resources) > return; > > + acpi_handle_info(adev->handle, "Adding power resources for %s\n", > + dev_name(&adev->dev)); > + > for (state = ACPI_STATE_D0; state <= ACPI_STATE_D3_HOT; state++) > a...

...urn false; > > > > > > + > > > > > > + ad = ACPI_COMPANION(&parent_pdev->dev); > > > > > > + 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...