> Just to be sure, you mean if "URB1" is done at frameX then "URB2" must > be done at frameX + URB2->intervall ? Can you point out the section of > USB spec that explains this, please ?
Forget about URB2->interval; it's an error in the device driver if that's not the same as URB1->interval (or URB3->interval etc), and the HCDs generally won't bother testing for that error. The whole point about periodic transfers -- interrupt or ISO -- is that they are periodic. And that period is, by default, the one listed in the endpoint descriptor. But Linux doesn't enforce that, using URB1->interval not f(ep->desc.bInterval); sometimes hardware lists 1/msec interrupt transfers for events that are both rare (so the polling is normally NAKed) and latency-insensitive (so 1-msec periods waste even more reservable bandwidth). > BTW, in "balance" function, why does index "i" start to 0 and not to > current frame number ? Why not? All that it guarantees is periodicity. Linux-USB hasn't yet made any guarantees about the analogue of clock phase; once a periodic transfer is established, phase is constant so long as the endpoint's transfer queue never empties. > > > 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. > > oh ok, usbcore calls hcd's "disable_endpoint" function when an > endpoint has no more pending URBs. So why endpoint deschedule is not > done in this function ? You mean, just for periodic endpoints? For one thing, it will already have been done when the last URB completes. More fundamentally, if Linux has a policy about bandwidth allocation, it's "on demand". Changing to some other policy would be work. What would that policy be? And what benefit would there be to keeping bandwidth allocated when it's not actually in use? (It sure sounds like it'd be a wasteful policy...) HCDs would need to define a second (error prone!) representation of the periodic schedule ... or else leave the periodic schedule active almost all the time, even when it's not in use. That costs DMA bandwidth (on most hardware) and IRQ bandwidth (on things like SL811), as well as battery power (on most systems with SL811) ... in short, I only see negatives down that path. > It seems to appear in "finish_request" when no > more (periodic and async) transfers are pending. Again, what possible benefits could come from deferring that? - 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
