> >> Note that usb-ohci.c was not treating 0-interval interrupts as one-shot; I
> >> changed it to treat 0-interval interrupts as 1-shot. However the documentation
> >> (URB.txt) doesn't mention 0-interval/one-shot interrupts at all! So either the
> >> uhci HCDs or the documentation is wrong...?
> >
> >As far as I can recall, these one-shot interrupts were a speciality of uhci
> >and not mentioned in our original URB "spec". I preferred a bulk replacement
> >at that time, but since a driver author (I can't remember who) wanted them,
> >I added this behavior afterwards.
>
> Yes, one-shot 0-interval interrupt URBs are functionally equivalent to bulk
> URBs. However, one-shot non-0-interval URBs are *not* equivalent. Bulk polling
> is as fast as possible, which at least some low-speed interrupt devices can't
> handle (I have one such device).
I'd prefer to get rid of the notion of one-shot interrupt transfers, for
consistency. That isn't the model for any other "periodic" transfers.
> >> -Allow all URB types to be resubmitted (have a urb->resubmit flag).
> >
> >That's exactly the case I don't understand and why the patches for *uhci are
> >actually needed. Why do you need a resubmit for interrupts? Interrupt URBs
> >run as long as you don't kill them. Actually resubmission seems pretty
> >useless to me.
>
> Well, I don't agree that resubmission is useless. Anyway the patch I
> submitted was *disabling* resubmission for interrupt URBs (with a flag), not
> enabling it. Just making sure that's clear.
Likewise, I prefer the simpler model of having only ONE way to make
an interrupt urb stop after submission: usb_urb_unlink(). Adding more
modes multiplies the code paths, and multiplies ways to create bugs ...
> >> -Allow all URB types to be queued! (I think OHCI already does this?)
> >
> >This is a hardware issue. OHCI can do this in hardware, UHCI needs much help
> >with a complicated descriptor structure and pointer handling.
> >For *uhci, only control transfers currently lack the the queue ability,
> >isochrounous did it since beginning and for queued interrupts I simply see no
> >use (a sort of semantic nonsense...).
>
> I disagree, queued non-resubmitting interrupt URBs would be very useful when
> used by usbdevfs (i.e., userspace programs).
Not to be too contrary here, but I'm not sure that's the right model to have
for the periodic schedules. The HCDs seem like they should be populating
the periodic schedule as interrupt/iso urbs are submitted, and then going
away until either an IRQ signals periodic transactions completed, or until
the urbs are descheduled/unlinked. No mucking around otherwise; that
seems like it'd complicate transaction translators more than necessary.
There are other models. Maybe SHM ring buffers, seen by userspace,
could be how usbdevfs should deal with interrupt and iso transfers. Or
maybe something else that can be scheduled once, then left alone.
The "API model" question came up on LKML recently; Johannes mentioned
to Linus that USB periodic transfers (interrupt, iso) don't fit into the pipe/socket
style model of bulk. (And maybe said as much about control urbs too ... I
would have! :) I think it's fair to say that the "usbdevfs" API could be on
the "rethink this" list for 2.5 ... maybe backported, maybe not.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
