On Tue, May 02, 2000, tom <[EMAIL PROTECTED]> wrote:
> > Originally the one-shot-feature was missing in usb-uhci, we only
> implemented
> > it for usb-scsi to make porting simpler. I can't imagine a situation
> where
> > you really need it and couldn't use bulk messages instead. So in the
> long
> > term, this "feature" should disappear. This automatically solves the
> > question about unlinking the urb for one-shot-interrupts...
>
> OK, how about you have a device which doesn't have bulk, is low-speed
> USB, and does support interrupt out. You want to send it a few interrupt
> packets, then want to stop.
Actually, you overload the code to perform bulk transfers to do your one
shot Interrupt transfer.
A one shot Interrupt transfer and a bulk transfer which is less than max
packet size for the pipe are identical on the bus.
Essentially, instead of using FILL_INT_URB, you use FILL_BULK_URB and
don't bother about using an interval.
Also, make sure to use usb_sndbulkpipe instead of usb_sndintpipe (or
usb_rcvbulkpipe instead of usb_rcvintpipe)
> With JE's uhci, I can simply return an interval of 0 after the last
> completion routine happened and be done with it.
>
> With AFS usb-uhci, I can do the same, but it doesn't stop the loop. I
> don't want to send any information at that time to the device anymore. I
> *have nothing* to send. The device does not have bulk endpoints (ever
> seen bulk on low-speed USB?)
>
> How do I go about stopping it? Setting the interval to 0 is a nice "end
> of my interrupt transfers" marker, IMHO.
>
> Under Windows (I know I probably shouldn't compare, but what the heck),
> interrupt transfers do *not* get re-submitted automatically. If you want
> an interrupt transfer to re-start, you need to re-submit it. Having the
> feature of automatically re-starting the interrupt transfer (in or out)
> is a nice feature, but you need to have a way to stop that cycle.
I'm a bit indifferent about this.
On one hand, using the bulk code to handle interval==0 makes everything
easier. On the other hand, I hate overloading things like that.
> > (b) this is using interval==0 in a way that was not intended;
>
> I guess so. The docs state the use of interval == 0 to have only one
> interrupt take place.
Unfortunately, this isn't the first time the docs are different than
implementation.
> > (c) Georg's statement that to stop an ongoing interrupt, you
> > should use usb_unlink_urb() is correct;
>
> Which I'll have to call from the completion handler, meaning that I need
> ASYNC_UNLINK flag. This used to oops my machine badly, but I need to
> re-test it. Might have been a different thing. I'll let you know when I
> tried it. If it works fine, I have nothing against it - it was my first
> approach, because it seems to be the logical approach.
>
> About the async unlinking - can I re-use the urb as soon as the
> usb_unlink_urb() returns (even with the ASYNC flag set)? Or are there
> any dangling pointers/references/... on the urb structures?
>
> > (d) an HCD could prevent this behavior by a driver callback
> > function by adding a (private) one_shot flag instead
> > of checking interval==0 after the callback.
>
> I'd rather have a cleanly defined way of stopping interrupt transfers
> than have private flags. I guess everyone agrees on this one
>
> Currently, I'm using the interval == 0 to end my int-out transfers.
> Works like a charm, haven't had a problem so far. I'll test with the
> unlink code and let you know how it goes.
I'd like to make interval==0 act like it does in my driver (one
transfer, then unlink) and leave the implementation up to the HCD.
But, I won't argue the point :)
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
