Hi,
I'd like to see us reach an agreement on this situation.
We need to have the HCDs work alike and we need for
the documentation to match the HCD code.
Tom, what is your latest opinion and code?
Does it work/is it workable? If so, which method/solution
are you using?
(more below)
> ----- Original Message -----
> From: "..tom" <[EMAIL PROTECTED]>
> To: "Georg Acher" <[EMAIL PROTECTED]>
> Sent: Sunday, April 30, 2000 1:35 PM
> Subject: Re: [linux-usb] Re: One-shot interrupts with usb-uhci
>
>
> > From: "Georg Acher" <[EMAIL PROTECTED]>
> >
> > > Hm, when you submit an interrupt with an interval of zero, it is
> supposed
> > > to do a one-shot-interrupt. Whether the urb is then automatically
> > unlinked, is
> > > another issue (was there a consensus lately?). To
> officially stop an ongoing
> > > interrupt, you should issue usb_unlink_urb().
No concensus yet, I guess.
interval == 0 was meant as a one-shot interrupt, not as
a means to disable an outstanding interrupt.
It was originally used by the usb_scsi driver (now
usb-storage), but I can't see that usb-storage uses it now.
I expect that noone else is using interval==0 for one-shot
interrupts (other than Tom). If Tom has another solution,
should we consider removing this "feature"?
It looks to me like [with tom's int_unlink patch]
(a) both UHCI HCDs will unlink any interrupt request if
the interrupt callback function sets interval to 0;
(b) this is using interval==0 in a way that was not intended;
(c) Georg's statement that to stop an ongoing interrupt, you
should use usb_unlink_urb() is correct;
(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.
Let's get some comments on this and then make a decision
instead of leaving it hanging.
~Randy
> > I haven't tried that one yet. The situation I have here is
> that I want to
> > start an interrupt for a number of transfers, then stop it
> (from within a
> > completion handler). My luck with usb_unlink_urb has been,
> well, not too
> > nice. If I *don't* set the asynchronous unlink flag, it
> comes back with 0,
> > but doesn't unlink. If I do set the asynchronous unlink flag (as I
> should),
> > it oopses nicely - chances are that this is caused by me trying to
> re-start
> > the interrupt cycle afresh.
> >
> > I have decided that it is cleaner for my particular
> application to submit
> > the urb, have the transfer going on, and when I need to
> stop it, return
> > interval=0. Works with JE usb, and (after the patch I sent
> out yesterday)
> > with AFS usb-uhci as well. I'll try the usb_unlink_urb()
> again when I get
> > back to the machine with the code on it...
> >
> > Thanks for the info,
> > ..tom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
