[I sent this to a short list of developers a while back but I didn't
get any responses so I thought I'd send it again to the list - sorry
for the noise]
Hi
Sorry to bother all of you at one time. I have some questions about
how the UHCI and OHCI controllers handle ISO transfers.
I've written a host controller for the PPC 850/823. It works fine,
but I can't get ISO transfers to work right because I don't understand
what should really be happening.
Basically, I don't understand how either the UHCI or OHCI controllers
handle isochronous traffic. The 850/823 USB controller needs to
provide the same interface to the usb stack as the UHCI and OHCI
drivers provide.
Here's my basic questions:
- what's the max packet size for an iso transfer? can it be as big as 1024
bytes? (my camera seems to have an endpoint which says 0x3ff as the max
transfer size)... what happens when it's say, 64 bytes? does this even
happen?
- is only one iso "IN" done per frame/per device? Under what conditions
does the controller complete the IN transaction? i.e. is the normal
mode for the controller to do one IN per frame and then fill in buffers
based on the descriptor? Does the controller complete the IN only when
the buffers are full or after each DATA packet?
- I've been trying to use usbstress-0.3 to test iso and I'm failing
miserably. It seems to want to send large frames (over 400 bytes) but
I don't think the endpoint will accept frames this big - so, should
this generate a bunch of iso OUT's (in a single 1ms frame) and then
when the anchor chip echo's them back, should they be agregrated back
into a single xfer?
here's a better description of my question:
usbstress submits 4 urbs (in this order, ASAP set),
2 transmit urbs
2 receive urbs
the transmit urbs specify
16 packets
496 bytes/packet
the recieve urbs specify
16 packets
496 bytes/packet
So, what happens?
I assume the following:
The controller queues up the first tx urb. It can't queue the second
because the device is busy so the second one waits.
The controller queues up the first rx urb. It can't queue the second
because the device is busy so the second one waits.
The controller waits for the next frame time and
sends an OUT + 496 byte DATA0;
sends an IN
the last step (wait + OUT + IN) occurs 16 times, once cycle per 1ms frame
(once the first tx and rx urbs complete the second set are then queued)
Meanwhile, each time an OUT + 496 byte DATA0 is sent, the anchor chip
buffers the packet and waits for an IN. When it receives an IN it
sends out a DATA packet with the data.
Now, one point of confusion is what happens if the max transfer size
is, say 64 bytes? I can bet the OUT's are chopped up in to (496/16 +
1) OUT's. And, I'll bet the anchor chip sends back the small buffers,
one per IN received. But what happens to the IN's on the controller
side? Does the controller keep sending IN's until the descriptor size
is filled? If it only sends one IN, it will just get one fragment, so
it seems like it needs to send (496/16 + 1) IN's also. I'm confused.
Thanks for any/all help. I'm trying to find the folks who have detailed
knowledge of how the two controllers work...
-brad
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
