search for: rp05

...rg/archives/dri-devel/2015-May/083448.html [2]: https://lists.freedesktop.org/archives/dri-devel/2015-May/083449.html On 09:42 PM - May 18 2016, Marcos Paulo de Souza wrote: > nouveau_optimus_dsm is using ACPI_TYPE_BUFFER, and this triggers warnings on ACPI: > [ 7.730564] ACPI: \_SB_.PCI0.RP05.PEGP: failed to evaluate _DSM > [ 7.730570] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (201509 30/nsarguments-95) > > To fix it, change ACPI_TYPE_BUFFER to ACPI_TYPE_PACKAGE, as the warning tells to do. > > Sig...

...M +0000, bugzilla-daemon at freedesktop.org wrote: > > https://bugs.freedesktop.org/show_bug.cgi?id=98398 > > > > --- Comment #11 from Peter Wu <peter at lekensteyn.nl> --- > > So 4.7 and before used the "DSM" method on runtime-suspend: > > - \_SB.PCI0.RP05.PEGP._DSM would be invoked to enable Optimus > > - \_SB.PCI0.RP05.PEGP._PS3 is then invoked which would enter D3cold > > (note, this method is still used in 4.8 on older laptops or with the > > pcie_pm_port=off kernel option) > > > > Since 4.8, _DSM is not called anym...

...y/083448.html > [2]: https://lists.freedesktop.org/archives/dri-devel/2015-May/083449.html > > On 09:42 PM - May 18 2016, Marcos Paulo de Souza wrote: > > nouveau_optimus_dsm is using ACPI_TYPE_BUFFER, and this triggers > warnings on ACPI: > > [ 7.730564] ACPI: \_SB_.PCI0.RP05.PEGP: failed to evaluate _DSM > > [ 7.730570] ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type > mismatch - Found [Buffer], ACPI requires [Package] (201509 > 30/nsarguments-95) > > > > To fix it, change ACPI_TYPE_BUFFER to ACPI_TYPE_PACKAGE, as the warning > t...

https://bugs.freedesktop.org/show_bug.cgi?id=98398 --- Comment #11 from Peter Wu <peter at lekensteyn.nl> --- So 4.7 and before used the "DSM" method on runtime-suspend: - \_SB.PCI0.RP05.PEGP._DSM would be invoked to enable Optimus - \_SB.PCI0.RP05.PEGP._PS3 is then invoked which would enter D3cold (note, this method is still used in 4.8 on older laptops or with the pcie_pm_port=off kernel option) Since 4.8, _DSM is not called anymore by nouveau (when support from the PCI core is...

...at freedesktop.org wrote: > > > https://bugs.freedesktop.org/show_bug.cgi?id=98398 > > > > > > --- Comment #11 from Peter Wu <peter at lekensteyn.nl> --- > > > So 4.7 and before used the "DSM" method on runtime-suspend: > > > - \_SB.PCI0.RP05.PEGP._DSM would be invoked to enable Optimus > > > - \_SB.PCI0.RP05.PEGP._PS3 is then invoked which would enter D3cold > > > (note, this method is still used in 4.8 on older laptops or with the > > > pcie_pm_port=off kernel option) > > > > > > Since 4.8...

...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: Scope (\_SB.PCI0.RP05) { Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot { NVP3 }) // ... } PowerResource (NVP3, 0x00, 0x0000) Kind regards, Peter > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c > index fcd4ce6f78d5..af9c3e15dd74...

...Oct 26, 2016 at 10:42:07PM +0000, bugzilla-daemon at freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=98398 > > --- Comment #11 from Peter Wu <peter at lekensteyn.nl> --- > So 4.7 and before used the "DSM" method on runtime-suspend: > - \_SB.PCI0.RP05.PEGP._DSM would be invoked to enable Optimus > - \_SB.PCI0.RP05.PEGP._PS3 is then invoked which would enter D3cold > (note, this method is still used in 4.8 on older laptops or with the > pcie_pm_port=off kernel option) > > Since 4.8, _DSM is not called anymore by nouveau (when supp...

https://bugs.freedesktop.org/show_bug.cgi?id=93934 Bug ID: 93934 Summary: DRI_PRIME=1: DeadIsland crashes when loading finish Product: Mesa Version: 11.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

I can confirm what Peter said, path contains \_SB_.PCI0.RP05 and power_state contains D3hot. Op do 27 okt. 2016 11:06 schreef Peter Wu <peter at lekensteyn.nl>: > On Thu, Oct 27, 2016 at 11:17:48AM +0300, Mika Westerberg wrote: > > On Thu, Oct 27, 2016 at 12:56:41AM +0200, Peter Wu wrote: > > > Hi PCI/ACPI PM experts, > > >...

...; > > 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 NVP3 was referenced before it was defin...

...gt; 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 NVP3 was referenced before it was defined, > could that resul...

...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 print before checking flags.power_resources just to be sure the patch is correctly appl...

...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 NVP3 was refer...

...ot. 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 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/...

...r: b.rowlingson at gmail.com QA Contact: xorg-team at lists.x.org Installed Linux Mint 17.1, installed all package updates to current (12/Mar/2015). Reboot, dmesg reports unknown chipset from the nouveau kernel module: [ 1.048477] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.RP05.PEGP handle [ 1.048495] checking generic (d0000000 580000) vs hw (e0000000 10000000) [ 1.048497] checking generic (d0000000 580000) vs hw (f0000000 2000000) [ 1.049793] [drm] hdmi device not found 8 0 1 [ 1.049924] nouveau E[ DEVICE][0000:08:00.0] unknown chipset, 0x118010a2 [ 1.04...

...> > 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. Kind regards, Peter > > Given that _PS3 exists and is indeed a package with some elements, it > > seems that acpi_extract_pow...

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?

https://bugs.freedesktop.org/show_bug.cgi?id=104835 Bug ID: 104835 Summary: MMIO read of 00000000 FAULT at 10ac08 [ IBUS ] Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=98386 Bug ID: 98386 Summary: [NVE7] bus: MMIO write of FAULT at [ IBUS ], Pointer to {TDMS,flat panel) table invalid Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority:

...h 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 print before checking > flags.power_resources just to...