On Tue, 29 Sep 2009, Sarah Sharp wrote: > So yes, this is a problem. I'll have to think more about how to > integrate a watchdog timer in the code for the case where the hardware > is not responding to a stop endpoint command. > > > > If the timer expires the hcd would run through all queues and > > > complete (with an error) all urbs. > > Should it cancel all the URBs? The hardware could be completing URBs > for other endpoints in the system, since each endpoint has its own > transfer ring. If the hardware isn't able to stop one endpoint in the > system but other endpoints are working, should we assume the HC is just > broken, halt and reset it, and complete all URBs with an error? This is more or less up to you. When the watchdog timer expires, you have to stop the hardware from accessing the URBs you're about to give back. If you can do this without disturbing other URBs, then fine. If not, every URB you are forced to abort should complete with a -ESHUTDOWN status. > > David is right. This isn't the way dead host controllers are handled > > in the other HCDs. > > > > The drivers test at some appropriate point for whether the controller > > is still connected and alive (generally from within the IRQ handler, > > the resume routine, and/or a watchdog timer routine). If it isn't, the > > driver sets hcd->state to HC_STATE_HALT (to tell usbcore that the > > controller is dead), possibly calls usb_hc_died(), resets the > > controller hardware, and sets a private flag. > > The documentation for usb_hc_died() says it's only for host controllers > attached to non-PCI buses, so I don't think that applies to xHCI. I'll > rework this patch to set hcd->state to HC_STATE_HALT. > > I wish there was some documentation on when a host controller is > supposed to set hcd->state. I mostly don't touch it at all, so are > there any other conditions where I should change it? hcd->state is a big mess. :-( It isn't documented properly, it gets set both by the core and by the HCD under various circumstances, and there aren't any clear guidelines on how to use it. Basically it should work like this: Whenever you reset or stop the controller, set the state to HC_STATE_HALT. Whenever you start the root hub, set the state to HC_STATE_RUNNING. usbcore will set the state to HC_QUIESCING, HC_SUSPENDED, and HC_RESUMING at the appropriate times. It's important that the state _not_ be set to HC_STATE_HALT at times when the controller might interrupt the CPU. > > Routines involved in unlinking and giving back URBs check the private > > flag. If it is set then they bypass the hardware and carry out the > > software part of their job immediately. > > The xHCI routines to give back URBs are only called when the hardware > interrupts with an event on the event ring. xHCI doesn't periodically > scan the frame list like EHCI. If the timer runs, it's going to have to > give back the URBs itself. The timer routine can call the same subroutines as the interrupt handler, to avoid duplicating code. Alan Stern PS: xHCI must handle split transactions somehow, since there's no other way to communicate with a USB-1.1 device behind a USB-2.0 hub. Does the xHCI spec describe how the hardware schedules split transactions? Does it obey all the scheduling rules in the USB-2.0 spec? -- 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
