Hi all,
I think the main problem with the ->next pointer is that it
is designed without queueuing in mind. But all!!!
transfer types can use some sort of queueing because
we can not guartantee that the CPU can handle a HC interrupt
immediately (and therefore without transfer queueing we get gaps).
As far as I understand it it should work as
following (without queueing):
URB_1->next = URB_2
- Submit an URB_1 to the HCD
- than the HC handles the transfer
- than after! the transfer HCD looks at the ->next pointer and
if it points to another URB we submit that other URB_2.
Here we will likely get a >1ms gap between the end of the transfer
of URB_1 and the submition of the ->next URB_2
(needs CPU interrupt routine).
Now with queued URBs:
- Submit a chain (URB_1, URB_2) immediately to the HCD
/* I think we still need to submit both URBs seperately? */
- than the HC handles the transfer (URB_1)
- than the HC handles the next transfer (queued URB_2)
\ at the same time HCD looks at the ->next pointer of URB_1
(it points to URB_2) but URB_2 is still queued so what now?????
Should we resubmit an active URB ?!?
Here the ->next pointer always points to the
next (an active) URB which is queued and
therefore has to be already submitted.
- Roman
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
