On Tue, Mar 20, 2012 at 12:44:03PM +0800, Elric Fu wrote:
> 2012/3/17 Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>:
> > The xhci_save_registers() function saved the event ring dequeue pointer
> > in the s3 register structure, but xhci_restore_registers() never
> > restored it. No other code in the xHCI successful resume path would
> > ever restore it either. Fix that.
>
> The result is same as RFT 2/5. The hibernate operation is ok but
> the suspend operation is failed.
>
> The suspend operation log:
>
> [ 69.891008] ACPI: Waking up from system sleep state S3
...
> [ 70.109320] usb 9-1: reset high-speed USB device number 2 using xhci_hcd
> [ 70.109485] usb 9-1: Device not responding to set address.
> [ 70.239680] ata3: SATA link down (SStatus 0 SControl 300)
> [ 70.250321] ata4: SATA link down (SStatus 0 SControl 300)
> [ 70.313107] usb 9-1: Device not responding to set address.
> [ 70.517018] usb 9-1: device not accepting address 2, error -71
...
> [ 70.833065] usb 9-1: Device not responding to set address.
> [ 71.036872] usb 9-1: device not accepting address 2, error -71
> [ 71.148698] psmouse serio1: hgpk: ID: 10 00 50
> [ 71.148921] usb 9-1: reset high-speed USB device number 2 using xhci_hcd
> [ 71.149087] usb 9-1: Device not responding to set address.
> [ 71.352886] usb 9-1: Device not responding to set address.
> [ 71.556734] usb 9-1: device not accepting address 2, error -71
> [ 71.668851] usb 9-1: reset high-speed USB device number 2 using xhci_hcd
> [ 71.669015] usb 9-1: Device not responding to set address.
> [ 71.872791] usb 9-1: Device not responding to set address.
> [ 72.076589] usb 9-1: device not accepting address 2, error -71
Oh, right, this is one of those VIA hosts that have one USB 2.0 port on
the xHCI controller, and an integrated USB 2.0 hub that introduces a
"tier mismatch". Is the integrated USB 2.0 hub the device that's not
responding to the Set Address command?
I think we should be able to handle tier mismatches, so I don't think
that's related to the Set Address failures. I've experienced other VIA
hubs that don't respond to the set address command properly, like the
Buffalo VIA USB 3.0 hubs that sold before any USB 3.0 hubs were
certified by the USB-IF. So I'm not sure if we're just not handling the
VIA hub correctly in Linux, or if it just has suspend/resume issues.
If the USB 2.0 hub really isn't responding to the Set Address command,
there's not much we can do about it. I think there is one xHCI driver
bug where it won't issue a command abort when the Set Address command
times out, but you wouldn't see any other xHCI commands work after that
happens. You would also see messages like:
xhci_warn(xhci, "%s while waiting for address device command\n",
timeleft == 0 ? "Timeout" : "Signal");
There's some trickiness to the solution to the set address timeout
handling (you need a flag to make it so the driver doesn't ring the
command ring doorbell or issue a new command abort until you've received
confirmation of the first canceled command), so I haven't had time to
get around to it yet. However, if you're not seeing the Timeout
messages, the device probably is responding to the control transfer.
Maybe you need to ask the firmware team if there's anything special that
needs to be done to initialize the integrated USB 2.0 hub after a resume
from suspend? Maybe it needs a Get Descriptor control transfer before
the Set Address control transfer? Or it could be something completely
different. At this point, I'm not really sure how to fix the issue with
the USB 2.0 hub.
At least we have the hibernate issue solved though! It seems like we
just need these three patches (even though the last two didn't help with
the VIA hub, it could still cause issues on other hosts):
[RFT 2/5] xhci: Don't write zeroed pointers to xHC registers.
[RFT 4/5] xhci: Restore event ring dequeue pointer on resume.
[RFT 5/5] xhci: Fix register save/restore order.
Does that sound correct?
Sarah Sharp
--
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
