On Thu, 31 Mar 2005, David Brownell wrote: > > 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.
That's what I had in mind. And how can the HCD know when khubd is finished scanning a hub? Answer: via the callback! > 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). I should have said "turn off" or "clear" the source instead of "disable" the source; this comprises both your (a) and (b). It's not really the same as what would be needed here. > 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. Such code is needed in general, isn't it? This is just the sort of thing Russell King was worried about. I can't imagine why the architecture-specific interrupt core routines don't already handle these issues. Then there's an additional level of confusion related to whether the edge- vs. level-triggering refers to the signals being sent to the interrupt controller or to the signals within the peripheral controller itself. > > 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? Just so. The driver falls back on polling, and it helps to know that the polling will continue even though khubd unlinks its status URB when the root hub is suspended. > 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. Okay. It probably won't take too long in any case. Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
