> 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.
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.
> (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.
> (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.
Thanks for all the considerations,
..tom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
