On Saturday 07 July 2007, Alan Stern wrote: > 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?
Yes; submit a big scatterlist of 128 KBytes, and unless there's some other controller operation going on at the same time there won't be an IRQ until the very last packet completes. > 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. Ah, I see. "Worst penalty for not being able to queue all requests at once." > > > 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. You can't fit that into one TD though. > 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. It's actually pretty good, all things told. > 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). Right ... > > > 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. :-) Hey, I didn't want to do it 3-4 years back myself. And still don't want to. Not that it's a bad idea; it would just be a boatload of work, changing the innards of everything. ;) - Dave ------------------------------------------------------------------------- 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
