On Fri, 15 Jul 2005 [EMAIL PROTECTED] wrote: >My understanding is that each TT has one buffer, and it's tied >up for as long as that split transaction is pending. Remember >that the reason to have the buffer is so that the TT can save >the data then retransmit it at a different speed ... e.g. take >most of a frame to transmit or collect a full speed ISO buffer. > >Of course, I could be wrong. Anyone with time to contribute >to make the TT support better is encouraged to do so. It'll >help if you like tricky interval arithmetic problems. :)
I'll check into it on the hw side, and also see if I can play with the code some to try queueing a couple split transactions to see if a TT can handle it. >> So if there are two devices each with 1ms >> interval interrupt-in endpoints, that fills up the tt's scedule and no >> more interrupt-in endpoints can be used. I'm seeing the problem when I >> connect only 3 devices to a high-speed hub, although the devices have >> several interrupt-in endpoints each with less-than 1ms poll rates. > >Shouldn't be that way, though maybe something borked the scheduling. >Unless you're not talking current 2.6 EHCI code? No, it is the current code, 2.6.12.2. I think the max number of interrupt transfers is an inverse function of their period, isn't it? Just add up all endpoint's poll rates (inverted) and it can't be more than the number of transfers per frame (assume 2)...so if there are two devices with 1ms interval interrupt-in endpoints, they get scheduled for each and every frame, and there's no more space to put any more interrupt-in split-transactions... Anyway, there certainly is some limit on the number of devices that is much lower than the actual USB bus (1.1 or 2.0) bandwidth limits. >> If I remove the tt_no_collision function, > >Why are you suspecting that function? That's just enforcing >the scheduling that the single _scheduled_ buffer must not >be double-booked. I'm not suspecting it of being buggy at all, I'm saying it makes the assumption TT's can't handle queueing split transactions, that is it's entire job :) If the design is changed to queue split transactions, tt_no_collision would need to be either removed or updated to allow queueing split transactions. If I get tt queueing working, I'll send a patch for your review... -- Dan Streetman [EMAIL PROTECTED] --------------------- 186,272 miles per second: It isn't just a good idea, it's the law! ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&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
