search for: _ps0

tools/firmware: remove "_PS0/3" Method Do not expose the ACPI power management "_PS0/3" Method to guest firmware. According to section 3.4 of the APCI specification 4.0, PCI device control the device power through its own specification but not through APCI. Qemu pushes "_PS0/3" to guest will cause a...

...}) Name (_PR2, Package (0x01) // _PR2: Power Resources for D2 { NVP2 }) Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot { 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: St...

...> { > > NVP2 > > }) > > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > > { > > NVP3 > > }) > > // ... > > Method (_PS0, 0, NotSerialized) // _PS0: Power State 0 > > { > > } > > > > Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 > > { > > } > > } > > > > Name (MSD3, Zero) >...

...(0x01) // _PR2: Power Resources for D2 > { > NVP2 > }) > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > { > NVP3 > }) > // ... > Method (_PS0, 0, NotSerialized) // _PS0: Power State 0 > { > } > > Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 > { > } > } > > Name (MSD3, Zero) > PowerResource (NVP3, 0x00, 0x0000) &...

...NVP2 > > > }) > > > Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot > > > { > > > NVP3 > > > }) > > > // ... > > > Method (_PS0, 0, NotSerialized) // _PS0: Power State 0 > > > { > > > } > > > > > > Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 > > > { > > > } > > > } > > >...

Hi all, if a device doesn''t support power management (pm_cap == 0) but it is acpi_pci_power_manageable() because there is a _PS0 method declared for it and _EJ0 is also declared for the slot then nobody is going to set current_state = PCI_D0 for this device. This is what I think it is happening: pci_enable_device | __pci_enable_device_flags /* here we do not set current_state because !pm_cap */ | do_pci_enable_dev...

On Mon, May 30, 2016 at 06:13:51PM +0200, Peter Wu wrote: > Do you have any suggestions for the case where the pcieport driver > refuses to put the bridge in D3 (because the BIOS is too old)? In that > case the nouveau driver needs to fallback to the DSM method (but not > when runtime PM is deliberately disabled by writing control=on). Do you know what Windows does then? I think we

...r happens on pci/pm (8b71f565) without other patches: > > 1. nouveau invokes _DSM and _PS3, device is put in D3cold. > 2. pcieport driver calls PG00._OFF (PG00 is returned by _PR3). > 3. Wake up Nvidia device (e.g. by power=on). > 4. This will trigger PG00._ON (via pcieport) and _PS0 (via nouveau). > 5. Nvidia card is not really ready (observed via "restoring config > space at offset ... (was 0xffffffff, writing ...)", a soft lockup > and RCU stall after that requiring a reboot to recover). > > nouveau could be patched not to invoke DSM when P...

...ould the parent port be in D3hot at that point? Wouldn't that be > > > > a suspend ordering violation? > > > > > > No. We put the GPU into D3hot first, > > OK > > Does this involve any AML, like a _PS3 under the GPU object? I don't see _PS3 (nor _PS0) for that object. If I read it right the GPU itself is not described in ACPI tables at all. > > > then the root port and then turn > > > off the power resource (which is attached to the root port) resulting > > > the topology entering D3cold. > > > > I don...

On Tue, Aug 28, 2018 at 5:57 PM, Peter Wu <peter at lekensteyn.nl> wrote: > Only non-bridge devices can be passed to a guest, but perhaps logging > access to the emulated bridge is already sufficient. The Prefetchable > Base Upper 32 Bits register is at offset 0x28. > > In a trace where the Nvidia device is disabled/enabled via Device > Manager, I see writes on the enable

...the same time. The latter happens on pci/pm (8b71f565) without other patches: 1. nouveau invokes _DSM and _PS3, device is put in D3cold. 2. pcieport driver calls PG00._OFF (PG00 is returned by _PR3). 3. Wake up Nvidia device (e.g. by power=on). 4. This will trigger PG00._ON (via pcieport) and _PS0 (via nouveau). 5. Nvidia card is not really ready (observed via "restoring config space at offset ... (was 0xffffffff, writing ...)", a soft lockup and RCU stall after that requiring a reboot to recover). nouveau could be patched not to invoke DSM when PR3 is detected (proposal...

...t; > > a suspend ordering violation? > > > > > > > > > > No. We put the GPU into D3hot first, > > > > > > OK > > > > > > Does this involve any AML, like a _PS3 under the GPU object? > > > > I don't see _PS3 (nor _PS0) for that object. If I read it right the GPU > > itself is not described in ACPI tables at all. > > OK > > > > > > then the root port and then turn > > > > > off the power resource (which is attached to the root port) resulting > > > > > t...

...egister is cleared when > the HDA controller is hidden and set if it's exposed, so reread the flag > after exposing the HDA. Is it possible that this works on Windows but not Linux because they handle ACPI hotplug slightly differently? Martin did some nice debug [1] and found that _DSM, _PS0, and _PS3 functions write the config bit at 0x488. The dmesg log [2] from zigarrre seems to show that _OSC failed (which I *think* means we won't use pciehp) and that there's a slot registered by acpiphp. Maybe this works on Windows via an ACPI hotplug event that runs AML to flip the 0x48...

...t; > > a suspend ordering violation? > > > > > > > > > > No. We put the GPU into D3hot first, > > > > > > OK > > > > > > Does this involve any AML, like a _PS3 under the GPU object? > > > > I don't see _PS3 (nor _PS0) for that object. If I read it right the GPU > > itself is not described in ACPI tables at all. > > OK > > > > > > then the root port and then turn > > > > > off the power resource (which is attached to the root port) resulting > > > > >...

...}) > > > > Name (_PR3, Package (0x01) // _PR3: Power Resources for > D3hot > > > > { > > > > NVP3 > > > > }) > > > > // ... > > > > Method (_PS0, 0, NotSerialized) // _PS0: Power State 0 > > > > { > > > > } > > > > > > > > Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 > > > > { > > > > } > > &g...

...oint? Wouldn't that be > > > > > a suspend ordering violation? > > > > > > > > No. We put the GPU into D3hot first, > > > > OK > > > > Does this involve any AML, like a _PS3 under the GPU object? > > I don't see _PS3 (nor _PS0) for that object. If I read it right the GPU > itself is not described in ACPI tables at all. OK > > > > then the root port and then turn > > > > off the power resource (which is attached to the root port) resulting > > > > the topology entering D3cold. >...

On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote: > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > > <mika.westerberg at intel.com> wrote: > > > > > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote: > > > > > last week or so I found

From: Lukas Wunner <lukas at wunner.de> The integrated HDA controller on Nvidia GPUs can be hidden with a bit in the GPU's config space. Information about this scheme was provided by NVIDIA on their forums. Many laptops now ship with this device hidden, meaning that Linux users of affected platforms (where the HDMI connector comes off the NVIDIA GPU) cannot use HDMI audio

...n? > > > > > > > > > > > > No. We put the GPU into D3hot first, > > > > > > > > OK > > > > > > > > Does this involve any AML, like a _PS3 under the GPU object? > > > > > > I don't see _PS3 (nor _PS0) for that object. If I read it right the GPU > > > itself is not described in ACPI tables at all. > > > > OK > > > > > > > > then the root port and then turn > > > > > > off the power resource (which is attached to the root port) result...

...S0W, 0, NotSerialized) // _S0W: S0 Device Wake State { Debug = "_S0W" // Return(3) Return(4) } Method (_DSW, 3, NotSerialized) // _DSW: Device Sleep Wake { } Method (_PS0, 0, NotSerialized) // _PS0: Power State 0 { Debug = "_PS0" } Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 { Debug = "_PS3" } } PowerResource (NVP3, 0x00, 0x0...