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

Reply via email to