On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> ... or at least deserving of deletion in the 2.5 series.
>
> For starters, it's always been superfluous. "audio.c" has always
> done ISO streaming without using urb->next. It just queues a
> bunch of ISO urbs, and the completion handler resubmits them
>
> Here's how the ISO transfers are handled today by device drivers
> that use urb->next:
>
> - Prepare a bunch of ISO urbs
> - Set them up in a ring using urb->next
> - Queue all the driver's ISO URBs at once
>
> Host controller drivers, after issuing urb->complete for an ISO
> urb with an urb->next value:
>
> - Make sure the ring isn't broken (*)
> - If not, resubmit the URB (**)
> - Swallow all errors
>
> (*) There are some minor differences in how the HCDs do this
> check. Some have ring size limits, some don't insist on
> having a ring. Portable drivers don't rely on such differences.
> (**) This isn't like the interrupt case, which can get lots of short
> circuiting.
>
>
> PROBLEMS with that current scheme include:
> - Clearly the urb->next is superfluous. The real work
> is queuing ISO urbs (like for bulk, and often control).
> - Swallowing errors is an evil principle. Better to have
> clean reporting paths.
> - Having that second mechanism for URB queuing has
> just confused new developers.
> - Those HCD differences aren't current problems, but
> they should still go away.
> - Removing urb->next support would simplify the host
> controller drivers.
I completely and wholeheartedly agree.
> > It sounds like we should probably move some of the checks from
> > hcd_submit_urb into usb_submit_urb so they cover all of the HCD's?
>
> Ideally, _all_ of the checks would move. The ONLY trouble spots I know
> of today relate to ISO.
>
> My proposal is as follows:
>
> - Drivers should stop using urb->next, and should instead
> just re-queue ISO urbs in their completion handlers. They
> can then at least detect the resubmit errors that would be
> swallowed today.
>
> - At the same time they should change to init urb->interval
> correctly.
>
> - In usbcore, delete the urb->next field. And make all the
> HCDs stop using it.
>
> - At some point move the hcd_submit_urb logic
> into usb_submit_urb, geting rid of that particular
> entry point in the hcd layer. (That will let the "old
> style" hcds get rid of many/most submit-path error
> checks ... roughly at the same time they start to
> use urb->interval for iso.)
>
> Right now, HCDs using hcd_submit_urb() will report errors if
> there are urb->next values, or urb->interval isn't set.
>
> So far as I know, these change would only affect the USB vide
> drivers -- audio behaves already -- and the "old style" HCD.
> ("ohci-hcd" is set already.)
>
> So you can see how small the effect on device drivers is, I
> attach a patch showing how to make the 2.4 version of
> "cpia_usb" work this way. (I've got a 2.5 version too, but
> nobody would see that work because of the other issues
> preventing USB video from working on 2.5 ... :)
Could you explain what urb->interval is used for with respect to ISO
URB's?
It's still documented (Documentation/usb/URB.txt) as being significant
for Interrupt URB's only and I can't think how it would apply to ISO
URB's?
JE
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
