search for: powerresourc

...Relevant SSDT excerpt: > > > > Scope (\_SB.PCI0.RP05) > > { > > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > > { > > NVP3 > > }) > > // ... > > } > > > > PowerResource (NVP3, 0x00, 0x0000) Looks wrong order to me. However, _PR3 is a package, for AML opcode that contains PkgLength grammar primitive, forward reference may be OK (for example Method). DefPackage := PackageOp PkgLength NumElements PackageElementList DefMethod := MethodOp PkgLength NameString Method...

...he 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 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,...

...Scope (\_SB.PCI0.RP05) > > > { > > > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > > > { > > > NVP3 > > > }) > > > // ... > > > } > > > > > > PowerResource (NVP3, 0x00, 0x0000) > > Looks wrong order to me. > > However, _PR3 is a package, for AML opcode that contains PkgLength grammar primitive, forward reference may be OK (for example Method). > DefPackage := PackageOp PkgLength NumElements PackageElementList > DefMethod := Method...

...{ NVP3 }) // ... Method (_PS0, 0, NotSerialized) // _PS0: Power State 0 { } Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 { } } Name (MSD3, Zero) PowerResource (NVP3, 0x00, 0x0000) { Name (_STA, One) // _STA: Status // ... Method (_ON, 0, NotSerialized) // _ON_: Power On { // ... } Method (_OFF, 0, NotSerialized) // _OFF: Power Off {...

...ized) // _PS0: Power State 0 > > { > > } > > > > Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 > > { > > } > > } > > > > Name (MSD3, Zero) > > PowerResource (NVP3, 0x00, 0x0000) > > { > > Name (_STA, One) // _STA: Status > > // ... > > > > Method (_ON, 0, NotSerialized) // _ON_: Power On > > { > > // ... > > } > &gt...

...// ... > Method (_PS0, 0, NotSerialized) // _PS0: Power State 0 > { > } > > Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 > { > } > } > > Name (MSD3, Zero) > PowerResource (NVP3, 0x00, 0x0000) > { > Name (_STA, One) // _STA: Status > // ... > > Method (_ON, 0, NotSerialized) // _ON_: Power On > { > // ... > } > > Method (_OFF, 0, NotSeria...

...> 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) That and the fact that they come from an SSDT instead of DSDT may cause this. However, I'm not expert in ACPICA so adding Bob and Lv if they have ideas. Bob, Lv, the bug in question is: https://bugs.freedesktop.org/show_bug.cgi?id=98398

...{ > > > } > > > > > > Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 > > > { > > > } > > > } > > > > > > Name (MSD3, Zero) > > > PowerResource (NVP3, 0x00, 0x0000) > > > { > > > Name (_STA, One) // _STA: Status > > > // ... > > > > > > Method (_ON, 0, NotSerialized) // _ON_: Power On > > > { > > > // ....

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

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

...levant SSDT excerpt: > > > > Scope (\_SB.PCI0.RP05) > > { > > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > > { > > NVP3 > > }) > > // ... > > } > > > > PowerResource (NVP3, 0x00, 0x0000) > > That and the fact that they come from an SSDT instead of DSDT may cause > this. However, I'm not expert in ACPICA so adding Bob and Lv if they > have ideas. > > Bob, Lv, the bug in question is: https://bugs.freedesktop.org/show_bug.cgi?id=98398

...} Method (_PS0, 0, NotSerialized) // _PS0: Power State 0 { Debug = "_PS0" } Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 { Debug = "_PS3" } } PowerResource (NVP3, 0x00, 0x0000) { Name (_STA, One) // _STA: Status Method (_ON, 0, NotSerialized) // _ON_: Power On { Debug = "NVP3._ON" _STA = One } Method (_OFF, 0, NotSerialized) // _OFF: Pow...

...> > > > > > > > Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 > > > > { > > > > } > > > > } > > > > > > > > Name (MSD3, Zero) > > > > PowerResource (NVP3, 0x00, 0x0000) > > > > { > > > > Name (_STA, One) // _STA: Status > > > > // ... > > > > > > > > Method (_ON, 0, NotSerialized) // _ON_: Power On > > > > { > &...

https://bugs.freedesktop.org/show_bug.cgi?id=75985 Priority: medium Bug ID: 75985 Assignee: nouveau at lists.freedesktop.org Summary: HDMI audio device only visible after rescan QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: jean-louis at