On Tuesday 07 February 2006 5:07 pm, Curran, Dominic wrote: > Lets say a new device is plugged into a EHCI port. > My understanding is that this generates and interrupt and the USBSTS's > 'Port Change Detect' bit is set (STS_PCD). > > So what functions get called ? > > ehci_irq() -> ehci_work() -> ???
Erm, not at all. If ehci_irq() is called and just the PCD bit is set, there's only one block of "real" code gets called ... the PCD handler. Today that only handles some remote wakeup paths. It could be switched over to the "new style" irq-driven root hub though, calling the newish usb_hcd_poll_rh_status() routine. At this point I don't happen to know of any boards or controller where that wouldn't work, and it's quite possible that the EHCI compliance testing has kept such bugs out of circulation. The rest is just overhead ... handling the CardBus eject case, tracking statistics, acking the hardware, locking, etc. > I'm fairly sure the root hub code gets called in order to enumerate the > new device like this: And currently that's all driven through the root hub timer, instead of through the PCD irq ... PCD is only used to detect remote wakeup. If someone changed the EHCI driver to use root hub IRQs, then the same root hub enumeration would happen ... but it would kick off sooner, and there wouldn't be the cost of a root hub timer polling 4x/second (which on some platforms would mean statistically significant power savings). - Dave ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
