On Thursday 31 March 2005 10:15 am, Alan Stern wrote: > On Thu, 31 Mar 2005, David Brownell wrote: > > > > I suppose I could look at disabling that IRQ source until khubd > > gets around to handling the change, but that would defeat the goal > > of simplifying HCDs. And the OHCI logic there wouldn't be sharable > > with EHCI, or other IRQ-drivable controllers... > > Won't EHCI end up looking more like UHCI?
You didn't send UHCI or EHCI patches, so it's hard to say. I'd have to compare the two to answer that question. Docs suggest that that IRQ is edge triggered on EHCI though. > In any case, I wouldn't expect the logic to be sharable. The sharable stuff would be in usbcore. As I said, "splitting some code out of khubd" so it can be called from IRQ, for root hubs ... splitting out the explicit msleep calls, etc. Normal state machine type code. > How easy is it to disable the INTR_RHSC signal in the IRQ handler and to > re-enable it later? Would it help to add a callback for enabling? As I said, I _could_ look at doing that. The first problem that came to mind is a potential increase in fragility. A callback might help, keeping the "should I re-enable" logic out of the HCD. Ditto for the disable. Arguably this patch should be updated to understand about level-triggered root hub irqs, not assuming edge-triggering This specific problem is very much like the "irqthread" work that's under way for realtime stuff; it'd be easy to argue that's how khubd should work. (And that it should use a realtime scheduling domain...) > Also, remember: The goal wasn't so much to simplify HCDs as to eliminate > polling. It would be surprising if adding root-hub interrupt support > could reduce the complexity of an HCD, considering that it's still > necessary to support some form of polling. But you said it "will" simplify ... :) I certainly understand that getting rid of timers is a worthy goal too. But it still doesn't seem like the HCD complexity should need to increase to do that. > What do you think of accepting the patch as it stands, with the idea of > adding or changing things later to accomodate level-triggered controllers? Purely in terms of OHCI I don't see any point to merging it. I'm biased towards that specific case since it's so widely used on embedded hardware, of course -- where getting rid of timer based polling will help battery life. (Though to be fair, when managing battery power is really critical, one also goes to some lengths to keep the USB host powered off most of the time. E.g. until a Mini-A cable is connected and an OTG device supplies 8mA VBUS power, or the handset connects to a docking station that supplies 100-500mA.) If there were patches to convert EHCI and/or UHCI to use this new IRQ mechanism, then such changes should be worth merging. Changes for the sake of changes don't exactly rock my boat. :) - Dave ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
