> Yeah, I think interrupt URB's will vary significantly regardless. Too > many limitation withs UHCI.
Could you elaborate a bit? The functionality is there, from what I've seen, and there are no code comments about particular silicon quirks that might be interfering. > Which reminds me, I need to add balancing to my TODO list for UHCI. I don't think the lack of it has been a real world problem -- though maybe that's wrong, and some of the more random-seeming problem reports are really bandwidth allocation bugs. But I suspect implementing it might help you end up with smaller/tighter code. At least that's what I saw with OHCI ... caught me by surprise how small that part turned out to be when that cleanup was finished, and how neatly ISO fit in to the original interrupt-only logic. >>>USB 1.1 is the same across all HCD's. The only thing I can think of that >>>would differ is what frames interrupt URB's get scheduled into. >> >>Example, the balancing that OHCI does to even out loads. (Which >>applies equally to iso transfers -- they don't need to run every >>frame, though they often seem to.) > > > Careful with Isochronous. By definition, it shouldn't be delayed and > should work identically across all HCD's. > > If they don't, we should fix that. The only way it'd get delayed is if someone disables checking the bandwidth AND actually overruns it. The fix would be make OHCI always do the bandwidth checks ... which I've been thinking about doing anyway. - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
