similar to: [PATCH 1/1] drm/nouveau: Use generic helper to check _PR3 presence

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

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

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 (on a Clevo P651RA, GTX965M). Mirror the behavior of Windows 8 and newer[1] (as observed via an AMLi debugger trace) and stop using the

Check whether the kernel really supports power resources for a device, otherwise the power might not be removed when the device is runtime suspended (DSM should still work in these cases where PR does not). Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398 Fixes: 692a17dcc292 ("drm/nouveau/acpi: fix lockup with PCIe runtime PM") Signed-off-by: Peter Wu <peter at

Hi Peter, On 24 May 2016 at 23:53, Peter Wu <peter at lekensteyn.nl> 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

On 27 May 2016 at 22:31, Peter Wu <peter at lekensteyn.nl> wrote: > On Fri, May 27, 2016 at 02:01:39PM +0100, Emil Velikov wrote: >> Hi Peter, >> >> On 24 May 2016 at 23:53, Peter Wu <peter at lekensteyn.nl> wrote: >> > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port >> > can be runtime-suspended which disables

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). An older (obsolete) patch for the first issue was tested by the reporter: https://bugzilla.kernel.org/show_bug.cgi?id=104791#c11 (it is replaced by "check for function 0x1B

The call site of nouveau_dsm_pci_probe() uses single set of output variables for all invocations. So, we must not write anything to them unless it's an NVIDIA device. Otherwise, if we are called with another device after the NVIDIA device, we'll clober the result of the NVIDIA device. For example, if the other device doesn't have _PR3 resources, the detection later would miss the

On Mon, May 30, 2016 at 02:20:10PM +0200, Peter Wu wrote: > On Mon, May 30, 2016 at 12:57:09PM +0300, Mika Westerberg wrote: > > +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: > > >

+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 > >

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 observed via an AMLi debugger trace) and stop using the DSM functions for D3cold when

On Fri, May 27, 2016 at 02:01:39PM +0100, Emil Velikov wrote: > Hi Peter, > > On 24 May 2016 at 23:53, Peter Wu <peter at lekensteyn.nl> 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

Even if PR3 support is available on the bridge, it will not be used if the PCI layer considers it unavailable (i.e. on all laptops from 2013 and 2014). Ensure that this condition is checked to allow a fallback to the Optimus DSM for device poweroff. Initially I wanted to call pci_d3cold_enable before checking bridge_d3 (in case the user changed d3cold_allowed), but that is such an unlikely case

On Mon, May 30, 2016 at 11:48:34AM +0100, Emil Velikov wrote: > On 27 May 2016 at 22:31, Peter Wu <peter at lekensteyn.nl> wrote: > > On Fri, May 27, 2016 at 02:01:39PM +0100, Emil Velikov wrote: > >> Hi Peter, > >> > >> On 24 May 2016 at 23:53, Peter Wu <peter at lekensteyn.nl> wrote: > >> > Since "PCI: Add runtime PM support for

Check whether the kernel really supports power resources for a device, otherwise the power might not be removed when the device 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

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

On Mon, May 30, 2016 at 04:09:09PM +0300, Mika Westerberg wrote: ... > > > > > > + > > > > > > + if (!parent_pdev) > > > > > > + return false; > > > > > > + > > > > > > + ad = ACPI_COMPANION(&parent_pdev->dev); > > > > > > + if (!ad) > > > > > > + return false;

Do not unconditionally invoke function 0x1B without checking for its availability, it leads to an infinite loop on some firmware. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791 Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)") Signed-off-by: Peter Wu <peter at lekensteyn.nl> --- Hi, I am not sure what exactly 0x1B is used for, it seems related to HDMI

Do not unconditionally invoke function 0x1B without checking for its availability, it leads to an infinite loop on some firmware. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791 Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)") Signed-off-by: Peter Wu <peter at lekensteyn.nl> --- drivers/gpu/drm/nouveau/nouveau_acpi.c | 18 +++++++++++++----- 1 file

Do not unconditionally invoke function 0x1B without checking for its availability, it leads to an infinite loop on some firmware. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791 Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)") Reviewed-by: Hans de Goede <hdegoede at redhat.com> Signed-off-by: Peter Wu <peter at lekensteyn.nl> ---