similar to: [PATCH v2] drm/nouveau/acpi: fix check for power resources support

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

On Tue, Nov 1, 2016 at 12:55 AM, Dave Airlie <airlied at gmail.com> wrote: > On 1 November 2016 at 08:48, Peter Wu <peter at lekensteyn.nl> wrote: >> 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).

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_acpi.c | 44 ++++++-------------------- 1 file changed, 10 insertions(+), 34

On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote: > On Thu, Oct 27, 2016 at 09:42:28AM +0000, Rick Kerkhof wrote: > > No, there are not. Here is the recursive directory listing: > > Are you able to try the following patch and send me dmesg (or attach it > to that bug)? It should show if the ACPI core even tries to add those > power resources. So Rick has

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

Hi, Mika > From: Mika Westerberg [mailto:mika.westerberg at linux.intel.com] > Subject: Re: Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources > > On Thu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote: > > On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote: > > > On Thu, Oct 27, 2016 at 09:42:28AM +0000, Rick Kerkhof

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

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

No, there are not. Here is the recursive directory listing: http://sprunge.us/FIRE Op do 27 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

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

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

On 1 November 2016 at 08:48, Peter Wu <peter at lekensteyn.nl> wrote: > 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.

On Tue, Nov 01, 2016 at 09:24:23AM -0400, Alex Deucher wrote: > On Tue, Nov 1, 2016 at 12:55 AM, Dave Airlie <airlied at gmail.com> wrote: > > On 1 November 2016 at 08:48, Peter Wu <peter at lekensteyn.nl> wrote: > >> Check whether the kernel really supports power resources for a device, > >> otherwise the power might not be removed when the device is runtime

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

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

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;

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

On Fri, Oct 28, 2016 at 11:56:30AM +0300, Mika Westerberg wrote: > On Thu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote: > > On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote: > > > On Thu, Oct 27, 2016 at 09:42:28AM +0000, Rick Kerkhof wrote: > > > > No, there are not. Here is the recursive directory listing: > > > > > > Are