> > Again, _transfers_ don't reserve bandwidth, endpoints do. > > I think I misunderstood this point....
If you looked much at 2.4 code, that may be why. :) > When you say NAK is not an error case, this is true except for setup > stage. Functions cannot issue a NAK packet in response to a setup > packet. In that case, it is an _error_, is it correct ? If they can't issue it, why are you worried about how your host side code would handle such out-of-spec peripherals? Do you have one that "must work" with your code? (Out-of-spec means you can handle those peripherals any convenient way...) A good rule in protocols is "be strict when sending and tolerant when receiving". Strict function/peripheral code won't NAK any SETUP packets. Lenient host code will recover (where possible) from peripherals that do make that mistake. > Most important question, let say for an interrupt point "URB1" is > submitted. The HCD checks that this endpoint is not already scheduled > and if not it schedules it if there's enough bandwidth. OK... > Now "URB2" is > submitted for the same endpoint and "URB1" is still in the queue. The > driver detects that the endpoint is already scheduled and so does > nothing (BTW, URB2->start_frame is not setup, isn't it ?). That's right. The start_frame thing is a minor oversight; I don't think any in-tree drivers ever used that field. > Why bandwith allocation is not done ? Because the bandwidth was already allocated; allocations apply to the entire time that the endpoint stays scheduled. Allocation is on-demand, where "demand" == "an URB is submitted". > Now "URB1" is processed and > "finish_request" is called. "URB2" is the next periodic transfer in > the queue and so is the next transfer for this endpoint. it seems to > be started in the same frame as "URB1", shouldn't it be started for > the next period ? You may be confusing the async schedule (which always takes the next transfer from a ring, any number of times before end-of-frame) with the periodic schedule (which scans a fixed list of transfers for each frame). The periodic schedule can't do multiple transfers to a given endpoint in one frame. (High speed is a bit different, of course.) > In "finish_request", if the endpoint has not more transaction in its > queue, when is "ep" variable freed ? Endpoints are freed when usbcore disables endpoints. (After all pending URBs have first completed...) They're not coupled to URBs in the way you imply. - Dave ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
