2012/3/21 Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>: > 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. I don't think it is a Set Address failures too. It doesn't look like a driver issue. > > 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. > You're right. I did't find any message about timeout. Actually, I have found the xHCI driver has the bug when the address device command timeout before. According to the xHCI spec, when the address device command timeout is happened, the driver have to abort the command ring and wait the event about the command ring stopped. Otherwise, the command ring will wait the response from the device all along. I am waiting for a special device to duplicate the issue and confirm the solution is correct. > 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. Maybe I need to determine the port link state of the port attached by the integrated usb 2.0 hub. I worry that the port link state is transition to other states except for U0 after the integrated 2.0 hub resume from suspend. > > 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? > I agree with your opinions. So we have to add a XHCI_RESET_ON_RESUME quirk for VIA host before the suspend operation is finished. Best Regards, Elric > 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
