On Thu, 28 Dec 2006, Marcelo Tosatti wrote: > Greg added code to make the interrupt handler of the host controller > inform status change events, making polling unnecessary during normal > operation (new_polling flag). > > OHCI and UHCI have been converted to the new scheme, but EHCI hasnt. > > From what I understand from the EHCI spec, the STS_PCD flag (status > change) of USBINTR register covers the following events: > > 4.15.2.1 Port Change Events > > Port registers contain status and status change bits. When the status > change bits are set to a one, the host controller sets the Port Change > Detect bit in the USBSTS register to a one. If the Port Change Interrupt > Enable bit in the USBINTR register is a one, then the host controller > will issue a hardware interrupt. The port status change bits include: > > ⢠Connect Status Change > ⢠Port Enable/Disable Change > ⢠Over-current Change > ⢠Force Port Resume > > Which includes all events reported by ehci_hub_status_data. > > So I've hacked up a patch to switch ehci-hcd to new_polling. > Unfortunately ehci_irq holds ehci->lock, so calling > usb_hcd_poll_rh_status() directly from IRQ context is not possible. > > Due to that, I've moved the call to a workqueue instance.
You can avoid using a workqueue by calling usb_hcd_poll_rh_status() at the end of ehci_irq(), after the spinlock has been released. Doing an extra test of the STS_PCD bit is a lot less overhead than starting up a workqueue. Also, you don't need to clear hcd->poll_rh in the hub_status routine. The core never touches that flag, so it won't get set unless ehci-hcd sets it. > Insertion/removal of cards works as expected, but I'm afraid that there > are corner cases which this simplistic code is not handling? > > Is it necessary to poll status during certain situations? Not as far as I know. Something may turn up in the future. One thing to watch out for is that some controllers might use "level-triggered" rather than "edge-triggered" interrupt reporting, even though the spec says they shouldn't. For such controllers it would be necessary to disable the STS_PCD bit when an interrupt occurs and not re-enable it until hcd->hub_irq_enable() is called. However I don't know whether any existing controllers include this design mistake. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel