On 03.10.2016 13:09, Mathias Nyman wrote:
I'm writing a workaround that will disable runtime PM for the xhci controller
In case we are about to put (keep) it in D0 without PME# wake support.
I also learned the lspci -vv might wake up the controller from D3cold so it's also
possible that PME# is failing in D3Cold.
Could you do two more things to verify the D state so that I fix the right issue:
1. check the D state from sysfs, on-battery, in state where usb devices are not detected:
cat /sys/bus/pci/devices/0000\:00\:14.0/firmware_node/power_state
2. send the DSDT table of your machine, it includes the ACPI methods that dictate the possible D states
copy /sys/firmware/acpi/tables/DSDT to a file and send it (a link to it, or attachment) to me, It's binary.
Thanks, I got the info off-list, and device is really in D0 and ACPI DSDT (provided by firmware) is
the one enforcing it:
From DSDT:
Scope (_SB.PCI0)
{
Device (XHC)
{
...
Method (_S0W, 0, NotSerialized) // _S0W: S0 Device Wake State
{
If (LEqual (XFLT, Zero))
{
Return (Zero)
}
Else
{
Return (Zero)
}
}
_S0W will return the deepest allowed runtime suspend D state, always zero in this case.
Normally if driver has all the needed quirks in place then XFLT == 3 (As linux xhci-hcd does)
then _S0W usually returns "3". But with this firmware _S0W always returns zero.
checking XFLT is useless.
Anyways, I'll write a workaround for this case in xhci, disabling runtime PM if
lowest runtime sleep state (highest D state) is D0 and PME# is disabled in D0.
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
