On Fri, 6 Jul 2007, David Brownell wrote: > > The total number of interrupts would depend on the HCD. Right now OHCI > > is probably the worst case. > > Worst??? No, I'd say it's intermediate between UHCI (lots of IRQs) > and EHCI (can have virtually none).
Is ehci-hcd really capable of doing that? I didn't know. Anyway, by "worst" I meant that it would experience the largest increase in the number of interrupts. So EHCI would be the worst case. > > so if you submit up to 16 URBs at a time then you would gain > > little or no overhead. (Note that at full speed, it takes almost 27 ms > > to transfer eight 4-KB URBs. I think getting an IRQ even every 10 ms > > would be okay.) > > It'd be an IRQ every 7+N msec, where N is the time for one URB; > if you assume that's one page, every 10 msec is sot of right. > > It wouldn't be 27 msec ... the biggest TD would hold 8 KBytes, > closer to 15 msec total (7+N). No, no. At a maximum of 19 64-byte bulk transactions per frame, a full-speed transfer of 32 KB requires 512 transactions and hence 512/19 = 27 frames. That's where the 27 ms comes from. I had thought that an OHCI controller could be instructed not to interrupt at all upon retiring a TD, but evidently that's not correct. So you're forced to get an interrupt every 10 or 15 ms whether you want it or not. Okay; it's not great but it's not terrible. UHCI is more flexible. But the space requirement for the TDs is so large that we wouldn't want to use a very deep pipeline. Once again, an interrupt every 10 or 15 ms seems appropriate. With EHCI it makes more sense to preallocate enough resources to handle an entire 120 KB transfer (the default value for max_sectors). > > Actually, the best way to approach this would be to relax the guarantee > > that completion routines are called with interrupts disabled. There's > > no real reason for that guarantee; it's just an historical remnant. > > But drivers do rely on it (the handlers call spin_lock rather than > > spin_lock_irqsave, for example), so changing it would require a fair > > amount of work. Worthwhile, in my opinion, but I don't want to do it. > > Except for RT support? :) Well, let's say I don't want to do it right now. :-) Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
