New subject: Please upstream commits from Google Chromium repository (was: XHCI device disconnect on S3 standby)

11 Jun 2014

      On 6/4/2014 1:06 PM, Duncan Laurie wrote:
...
On Tue, May 27, 2014 at 3:17 PM, Matt DeVillier
matt.devillier@gmail.com wrote:
...
Greetings,
I'm unable to use any USB devices connected to an XHCI controller to resume from S3 standby, as something causes all connected devices to disconnect just prior to entering standby, as per the output of dmesg.
I've traced the relevant sections in the southbridge and ACPI source for my device (a haswell-based ChromeOS device with an Intel lynxpoint southbridge), but have been unable to find the culprit.
CONFIG_FINALIZE_USB_ROUTE_XHCI is set, as this device only has USB3 ports (4x), but having it set either way doesn't make a difference.  The usb_xhci_sleep_prepare() call doesn't seem to be the culprit, as commenting it out has no (positive) effect.
Resuming via the power switch or wake on lan work perfectly, so it's not a general resuming issue.
Appreciate any pointers on how to proceed
USB/XHCI devices disconnecting in the kernel before the system goes to
suspend suggests it may be an intentional OS (via udev?) action.
Which distro are you using?
I think the panther mainboard has not been upstreamed yet so I assume
you are using a checkout from the chromium coreboot?  Or is this
pulling the chromium panther mainboard into the upstream coreboot?
Here are a few things to check:

Is there an XHCI device visible (and set as enabled) in

/proc/acpi/wakeup output?

When you go to suspend what does the kernel print about XHCI

controller itself?  (ignoring the devices for the moment)
I would expect to see lines like this before it actually goes to suspend:
xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
xhci_hcd 0000:00:14.0: power state changed by ACPI to D3cold
And then after resume:
xhci_hcd 0000:00:14.0: power state changed by ACPI to D0
xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
In an attempt to debug further it could help to send some additional output:

dmesg after a suspend/resume cycle
/sys/firmware/acpi/tables/DSDT (after run through iasl -d)  I don't

expect issues here if wake-on-lan is working, but worth a check.
Thanks,
-duncan
Hi Duncan,
I'm currently testing on OpenELEC 4.0.4 (k 3.14.5, 3.15.0) and Ubuntu 14.04 (k 3.14.1).
This is using upstream coreboot with the panther mainboard info pulled from the panther chromium branch.  I also pulled over any changes to the northbridge/haswell and southbridge/lynxpoint directories that hadn't made it back upstream yet.
'cat /proc/acpi/wakeup' shows the xhci controller as enabled, as does 'cat /sys/bus/usb/devices/<dev #>/power/wakeup' for all connected devices.
dmesg shows the following prior to entering suspend:
xhci_hcd 0000:00:14.0: remove, state 4
usb usb2: USB disconnect, device number 1
xhci_hcd 0000:00:14.0: USB bus 2 deregistered
xhci_hcd 0000:00:14.0: remove, state 1
usb usb1: USB disconnect, device number 1
usb 1-2: USB disconnect, device number 2
usb 1-4: USB disconnect, device number 5
usb 1-5: USB disconnect, device number 4
xhci_hcd 0000:00:14.0: USB bus 1 deregistered
<snip>
PM: Entering mem sleep
and coming out of resume, nothing xhci related prior to 'PM: Finishing wakeup.'
afterwards, it re-inits the xhci controller identically to at boot:
xhci_hcd 0000:00:14.0: xHCI Host Controller
xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
etc etc.  Nothing related to setting the power states either prior to or after suspend.
thanks,
Matt

Re: [coreboot] XHCI device disconnect on S3 standby