On Thu, 1 Oct 2009, Sarah Sharp wrote: > The xHCI watchdog timer will run in interrupt context. It looks like > the EHCI driver doesn't really care that the halting of the host can > take up to 2ms (16 microframes) in interrupt context. I was going to be > nice and spawn a work queue to halt, reset, and giveback the URBs if the > stop endpoint command timed out. Should I bother? Or should I just do > all that work in the timer interrupt? Given that this is expected to happen only when the hardware is failing, I guess it's okay to do it all in the timer interrupt. > > > 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. > > On second thought, why does the documentation say usb_hc_died() is only > necessary for non-PCI buses? Is that because usb_hc_died() is called > from the PCI interrupt handler when HC_STATE_HALT is set? That's not right. There _is_ no PCI interrupt handler -- there's just usb_hcd_irq(). I assume the comment refers to the PCI resume handler in hcd-pci.c, since that's the only place where the PCI bus glue calls usb_hc_died(). As such, the comment is rather misleading. > If I set that > state in the watchdog timer function or spawned work queue, will the USB > core ever notice if that state is set if there are no more PCI > interrupts? Or will I have to call usb_hc_died() from the xHCI driver? You will have to call it yourself. > > It's important that the state _not_ be set to HC_STATE_HALT at times > > when the controller might interrupt the CPU. > > Gotcha. So it's probably safe to set HC_STATE_HALT when the interrupt > handler or urb_dequeue function detects the PCI card has been removed. > If it comes back, it will be initialized as a different bus, correct? Yes to both. If you set the state to HALT in the interrupt handler and don't return IRQ_NONE then the core will call usb_hc_died() for you. > > 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? > > Yes, the xHCI hardware generates all the split transactions itself. The > xHCI The xHCI spec refers to section 8.4.2 and 11.14 of the USB2 spec, > but doesn't place any requirements on how hardware is supposed to > generate split transactions. There is a "split transaction error" that > the xHCI driver is supposed to handle like a stalled endpoint, but I > haven't put that in yet, and haven't seen that error on any hardware I'm > currently testing on. Doing all this in software is already quite complicated. I wonder how the hardware manages to handle it all. Alan Stern -- 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
