Hi,
I have looked at EHCI sources in 2.5.63 and have some questions.
For each element of urb->iso_frame_desc there is one allocated iTD. It
Yes.
looks like that one iso_frame_desc element should describe all transactions in one frame (not uframe) because one iTD can handle eight uframes.
Not necessarily, it depends how they're scheduled. A driver that's scheduling ISO at period 1/4 uframe wouldn't necessarily want to know where the frame boundaries start; it could easily put more than one URB in place.
On the other hand, currently there are shortcuts in the periodic scheduling that prevent sharing. The accounting should be in place, but the logic to use it isn't. And the (high speed) ISO support hasn't really been used yet, since its first appearance about a year ago ... there's been a shortage of high speed ISO devices.
But in itd_fill is iso_frame_desc[x].length compared to endpoint's max packet size which describes one uframe. Also in itd_complete is iso_frame_desc[x].status is updated in according to itd->hw_transaction which describes one uframe too.
Yes, that's a shortcut taken in the high speed ISO support.
Does in means that this code can handle only iso endpoints with interval 8 i.e. one transaction (no high bandwith) per frame?
For the moment, yes. It's not on my list of things to change, but working patches from someone else would be a Fine Thing.
... though I'd want the ISO support to have a "pseudo-qh" kind of data structure, so that adding a new ISO URB to an endpoint's queue is simpler.
- Dave
------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
