I guess I should have read that more closely ;-)
Yep, your #2 part (1) is certainly what sounds the best to me. And as you said, it would remove any need for special handling of int-outs. And the BW should certainly be allocated while any URBs are in the queue. Also, this would be a good opportunity for UHCI HCDs to add Control-URB queueing ;) On Mon, 25 Feb 2002, David Brownell wrote: >> If INTs could be queued, there would not really even be a need to >> 'resubmit' the URBs. The completion handler can simply resubmit a >> completed URB (if desired) without any loss of data or polling time. > >For the record, this is going down the path of the "support >multi-buffering" proposal I sketched out (API change #2) ... >you might look at that a bit more, and share comments on >that part of the original RFC. > >One difference between that and what Roman sketched >was that I did was in the model for schedule management: > >- He suggested a new HCD level "set_endpoint_properties" > call (perhaps coupled to set_config and set_interface?) > to schedule the bandwidth. > >- I'd suggested that the bandwidth would stay scheduled until > after an interrupt transfer completed, there was no transfer > queued. > >Yes, I tend to think that it might be worth breaking existing >interrupt transfer code in this way to get an improved API. >But it'd be work... > >- Dave > >p.s. I have similar comments about ISO transfers... :) > > Apart from some wire-level differences, the main > structural difference between INTR and ISO is > supposed to be that (a) no lowspeed ISO, (b) for > fullspeed, INTR has a smaller maxpacket (64 bytes > vs 1023 for ISO), (c) at all speeds, errors on INTR > transfers are supposed to get retried, but ISO ones > get reported. Both are supposed to respect the > endpoint poll period, and "high bandwidth" mode > (up to 24 MByte/sec, highspeed) works much the same. > > In short, we may want to consider corresponding > updates to the ISO transfer model, since it's not > intended to be as different from the INTR one as > it is today in Linux. > > -- Dan Streetman [EMAIL PROTECTED] -------------------------------------------------- 186,282 miles per second: It isn't just a good idea, it's the law! _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
