On Thu, 31 Mar 2005, David Brownell wrote: > > 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.
That's what I meant. So converting EHCI to use the new facility shouldn't be much harder than converting UHCI will be -- i.e., not very, although the conversion involves changing a bunch of code because the driver will now be in control of when the polling occurs. > > 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. Yes, and a real pain. Part of the reason for making khubd a separate process is to avoid doing stuff like that. It sounds like a much bigger job than actively managing INTR_RHSC in the OHCI driver. > > 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. In fact a callback would be necessary; otherwise there's no way for the HCD to know when it's time to re-enable the interrupt source. Disable doesn't need a callback though -- it should happen whenever your IRQ handler sees INTR_RHSC. (Is that what you meant by "Ditto for the disable"?) By the way, am I understanding you correctly that it's possible to turn INTR_RHSC on and off independent of all the other interrupt request logic? Don't you currently run with it turned off? > Arguably this patch should be updated to understand > about level-triggered root hub irqs, not assuming edge-triggering Well, I can certainly update it to include that callback. Rewriting a major part of khubd isn't something I want to get into right now... > 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...) But khubd doesn't need to work like that for external hubs. It only matters for root hubs. And then only for OHCI. > > 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 ... :) Lack of proper context. The part of the patch that adds rh-interrupt support makes HCDs more complicated. The part that lets them control when polling occurs makes them simpler. > 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. How much complexity does it add to enable/disable INTR_RHSC at the appropriate times? Surely not very much! After all, every device driver is expected to disable the interrupt source whenever an IRQ arrives. The only question is when to re-enable it -- slightly harder in this case because it has to be after the IRQ handler completes. > 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.) In fact we should be doing both. > 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. :) I'm been working pretty hard on uhci-hcd for the last week or so. There's about 5 preliminary patches needed before the rh-interrupt stuff can go in. They're just about ready; I'll submit them soon. Then when the time comes, I could send in both the updated rh-interrupt patch and the corresponding UHCI changes. Or do you prefer to see the update sooner? At least now we know from your testing that it won't break OHCI in either legacy or polling mode. Alan Stern ------------------------------------------------------- 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
