search for: firmware_nod

...D3 and are willing to transition to D3cold. It does so by invoking > > \NVP3._OFF (where \NVP3 is the power resource from \_SB.PCI0.RP05._PR3) > > > > That is how I think it should work in theory, but on Ricks laptop running > > 4.8.4, > > /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 > > devices (which I do have on my own laptop for 0000:01:0). > > > > The SSDT1 of Rick's Acer laptop shows this structure: > > > > If (\_OSI ("Windows 2013")) > > { > > Scope (\_SB.PCI0.RP0...

...nsition to D3cold. It does so by invoking > > > \NVP3._OFF (where \NVP3 is the power resource from \_SB.PCI0.RP05._PR3) > > > > > > That is how I think it should work in theory, but on Ricks laptop running > > > 4.8.4, > > > /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 > > > devices (which I do have on my own laptop for 0000:01:0). > > > > > > The SSDT1 of Rick's Acer laptop shows this structure: > > > > > > If (\_OSI ("Windows 2013")) > > > { > &gt...

...for the PCIe port since all its children are in D3 and are willing to transition to D3cold. It does so by invoking \NVP3._OFF (where \NVP3 is the power resource from \_SB.PCI0.RP05._PR3) That is how I think it should work in theory, but on Ricks laptop running 4.8.4, /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 devices (which I do have on my own laptop for 0000:01:0). The SSDT1 of Rick's Acer laptop shows this structure: If (\_OSI ("Windows 2013")) { Scope (\_SB.PCI0.RP05) { //... Name (_PR0, Package (0x01) //...

...nvoking > > > > \NVP3._OFF (where \NVP3 is the power resource from > \_SB.PCI0.RP05._PR3) > > > > > > > > That is how I think it should work in theory, but on Ricks laptop > running > > > > 4.8.4, > > > > /sys/bus/devices/0000:1c.4/firmware_node/ does not have > power_resources_D0 > > > > devices (which I do have on my own laptop for 0000:01:0). > > > > > > > > The SSDT1 of Rick's Acer laptop shows this structure: > > > > > > > > If (\_OSI ("Windows 2013")) &...

...s children are in > D3 and are willing to transition to D3cold. It does so by invoking > \NVP3._OFF (where \NVP3 is the power resource from \_SB.PCI0.RP05._PR3) > > That is how I think it should work in theory, but on Ricks laptop running > 4.8.4, > /sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0 > devices (which I do have on my own laptop for 0000:01:0). > > The SSDT1 of Rick's Acer laptop shows this structure: > > If (\_OSI ("Windows 2013")) > { > Scope (\_SB.PCI0.RP05) > { > //.....

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?

Hi everyone, after following in the footsteps of the following discussion (http://lists.xenproject.org/archives/html/xen-users/2013-09/msg00106.html) I had been able to turn my GTX 480 into a Quadro 6000. When I VT-d passthrough it to a Debian jessie VM it shows up fine and CUDA 5.5 seems to function properly up to a point: lspci -v: 00:04.0 VGA compatible controller: NVIDIA Corporation GF100GL

....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/attachments/20161027/3617a181/attachment-0001.html>

...stuff/blob/master/d3test/fakedev.asl If you adapt if for your environment, note: - I have only tested this with the q35 machine type with an additional ioh3420 root port. See the XPS956/boot-vm script. - The \_SB.PCI0.SE0 device should match the root port: cat /sys/bus/pci/devices/0000:00:1c.0/firmware_node/path (the SE0 name is chosen by QEMU.) - The "NET" (\_SB.PCI0.SE0.NET) device name is arbitrary chosen by me, it currently assumes PCI address 01:00.0: Name (_ADR, 0x00000000) // _ADR: Address (dev+fn only, 01:00.0) - The _DSM method is copied from the XPS 9560 SSDT with external m...

On Tue, Aug 28, 2018 at 5:57 PM, Peter Wu <peter at lekensteyn.nl> wrote: > Just to be sure, after "sleep", do both devices report "suspended" in > /sys/bus/pci/devices/0000:00:1c.0/power/runtime_status > /sys/bus/pci/devices/0000:01:00.0/power/runtime_status > > and was this reproduced with a recent mainline kernel with no special > cmdline options? The

...e the attached ASL file to AML (iasl ssdt1.dsl). (You can remove the If(\_OSI(...)) check to see the difference. 3. Boot QEMU and watch the dmesg for the debug prints. Alternatively, just boot QEMU with this SSDT and check against any Linux distro and inspect /sys/bus/pci/devices/0000:00:01.3/firmware_node/. Tested with Linux v4.8.5, QEMU 2.7.0, iasl 20160831. The SSDT structure is adapted from Ricks SSDT1 file and modified for the 00:01.3 device in QEMU. The QEMU command I used was: qemu-system-x86_64 -m 1G -M pc,accel=kvm -nographic \ -kernel arch/x86/boot/bzImage -serial file:/dev/s...

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