Alan Stern wrote:
> A more serious problem is that your dequeue method forgets to call
> usb_hcd_check_unlink_urb().
>
Thank you, fixed.
>> Case 2) seems very strange to me - how can more data be sent than expected?
>> I have run usbmon traces on both the mx21 and intel systems and the camera
>> setup commands are the same.
>>
> One possibility is that the amount expected is wrong (too small).
>
Yes I thought of that but it doesn't explain:
PC (UHCI + PWC)
URB requests 10 * 196 bytes
Received 10 * 192 bytes
iMX21
URB requests 10 * 196 bytes
Received 196 bytes + data overrun
> What do you mean by "iso scheduling arrives too late"? The algorithm
> used by uhci-hcd goes like this:
>
>
I use something similar to determine the start frame for each URB and
hence the frame for each TD (using interval). Hence in
imx21_hc_urb_enqueue_isoc() I get a list of struct td each with its
frame number.
Now the iMX21 hardware has:
32 ETD structures
Data memory
Various registers
Any type of transfer (isoc or otherwise) goes like this from a hardware
point of view:
Obtain a free ETD
Fill it in (transfer type, data memory offset, frame number for
isoc, ...)
Setup DMA between USB Data memory and system memory
Activate ETD
Get interrupt when done.
For isoc transfers I use 2 ETDs. I setup the first two with the first
two struct td s calculated during enqueuing.
Then when the first ETD done interrupt occurs I replace the first ETD
with the third struct td etc. (schedule_iso_etds())
So all this means that I calculate all the frame numbers up front during
submission but get one interrupt per TD. So my question is what should I
do if when the interrupt occurs the current frame number (as read from
the hardware) is already > precalculated frame number (latency,...) [I
have actually seen this happen occasionally]:
Signal an error for the URB?
Recalculate the frame numbers?
More generally I notice the UHCI and OHCI drivers only generate an
interrupt for the last TD of the URB.
Unfortunately with my hardware I can't do that. I could do a little
better because it is in fact possible to send two data packets per ETD
(not done in my driver yet). Alternatively I could use more ETDs per
endpoint but there are only 32 of them.
> If the stream isn't already active, choose a suitable start
> frame in the near future.
>
I use current frame + 1 (maybe too soon?)
> If the stream is already active and there are URBs queued,
> use the next slot after the end of the last URB in the queue.
>
> If the stream is active but no URBs are queued and
> URB_ISO_ASAP is set, choose the next slot after the current
> frame (as a result some slots may get skipped).
>
> If the stream is active but no URBs are queued and
> URB_ISO_ASAP is not set, use the next slot after the most
> recent URB. The frame for this slot may already have
> expired; if it has then one or more of the
> urb->iso_frame_desc[].status values will be set to -EXDEV.
>
I thought that if URB_ISO_ASAP is not set the submitter is supposed to
specify the frame number in urb->start_frame.
Thanks for your advice,
Martin Fuzzey
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
