On Thursday 31 March 2005 2:11 pm, Alan Stern wrote: > On Thu, 31 Mar 2005, David Brownell wrote: > > > > 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.
Not without a contract about what khubd does ... e.g. a guarantee that when it scans a hub, it'll clear all port and hub change bits. Given such a guarantee, the HCD could re-enable the IRQ automagically. > 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? Yes and yes. > > 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... Right now? I'd have suspected "never" would be the right time ... ;) > > 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! If usbcore can handle the re-enabling it should be more or less OK. > 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. Actually most IRQ handlers I've seen _don't_ disable the IRQ source; why should they? Their task is to (a) clear the source of the IRQ, and (b) ack the IRQ itself (clearing latched status). This is a case where edge triggering vs level triggering may want slightly different code though, at least at the level of the IRQ controller dispatch logic. > > 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. Sounds good to me. Presumably you've got some sort of quirk handling for the boards that can't be IRQ driven? > 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. I won't have much time to look at that for either OHCI or EHCI (took me long enough to try building on this patch!) so don't rush on my behalf. - 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
