similar to: [PATCH v2] drm/nouveau: don't detect DSM for non-NVIDIA 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

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 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 > > is incompatible with DSM, resulting in a GPU device which is still in D3 > > and

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;

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: > > > > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port

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

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

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

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

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

As I mentioned last week, I've been developing a package that I call Rdsm ("R distributed shared memory"), modeled after a similar package, PerlDSM, I wrote for Perl some years ago. It is now in alpha form, so I'm not uploading to CRAN yet, but it is definitely usable, and I am releasing it at http://heather.cs.ucdavis.edu/~matloff/R/Rdsm I hope many try it out, and give me

The present code assumes that optimus is present whenever two VGA (PCI_CLASS_DISPLAY_VGA) devices are present. This does not seem to be the case of newer laptops with optimus, in which case the nvidia gpu is a PCI_CLASS_DISPLAY_3D device. Rework the logic so that we count both VGA and 3D devices, when contemplating if optimus is present on the platform. Bugzilla:

Return the set of supported functions to the caller. No functional changes. Signed-off-by: Peter Wu <peter at lekensteyn.nl> --- drivers/gpu/drm/nouveau/nouveau_acpi.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c b/drivers/gpu/drm/nouveau/nouveau_acpi.c index 45fa9b2..71d5e6a 100644 ---

Return the set of supported functions to the caller. No functional changes. Signed-off-by: Peter Wu <peter at lekensteyn.nl> --- drivers/gpu/drm/nouveau/nouveau_acpi.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c b/drivers/gpu/drm/nouveau/nouveau_acpi.c index 886a67c..572ac30 100644 ---

Return the set of supported functions to the caller. No functional changes. Reviewed-by: Hans de Goede <hdegoede at redhat.com> Signed-off-by: Peter Wu <peter at lekensteyn.nl> --- drivers/gpu/drm/nouveau/nouveau_acpi.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c b/drivers/gpu/drm/nouveau/nouveau_acpi.c

I've got one of these on the way right now - BestBuy has a special on them and I think Buy.com is doing a 30$ rebate. I gather that it's based on the ZenSonic units which supposedly supports Ogg, but that particular bit of code isn't quite up to speed yet. > Well i did it, i finally broke down and bought a hardware based media > player, the dlink dsm 320. > Not only can i