I agree, it is a neat feature, and if it's the right
thing to do, we can keep it.
My main point really is that the HCDs need to behave alike,
not differently.
~Randy
> -----Original Message-----
> From: tom [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 10, 2000 1:06 PM
> To: Johannes Erdfelt; Dunlap, Randy
> Cc: Georg Acher; [EMAIL PROTECTED]
> Subject: Re: [linux-usb] Fw: [linux-usb] Re: One-shot interrupts with
> usb- uhci
>
> From: "Johannes Erdfelt" <[EMAIL PROTECTED]>
>
> > On Wed, May 10, 2000, Dunlap, Randy <[EMAIL PROTECTED]> wrote:
> > >
> > > Any results, patches on this subject?
> > >
> > > Personally I'd like to see us remove one-shot
> > > interrupts. It was added to the URB rewrite for
> > > backwards-compatibility usage for usb_scsi (now
> > > usb-storage), which no longer uses it.
> > >
> > > The suggestion to use a bulk transfer request
> > > in place of a one-shot interrupt does have a
> > > downside -- one that I expect Tom would discover
> > > even if we didn't bring it up. Interrupt transfers
> > > fall into the guaranteed bandwidth area of USB
> > > [if usb_submit_urb() doesn't return an error],
> > > whild bulk transfers have no such guarantee.
> > > This could make a difference on a device like a
> > > force-feedback joystick while other guaranteed
> > > bandwidth transfers are occurring, like large Isoc.
> > > camera input transfers.
> >
> > Good point. I personally hadn't thought about it that way.
>
> Agreed with Johannes. Also, if you use bulks but really mean
> interrupts, it might confuse people down the road.
>
> > I'd still like to see interval == 0 mean a one shot interrupt,
> > automatically unlinked after execution.
>
> This is a *really* neat feature for the only few (one?) people using
> interrupt out. It removes any kind of state machines and asynchronous
> uncertainties when you are done with a few transfers. Works
> like a charm
> on Johannes' uhci, BTW, and with a little help also in
> Georg's usb-uhci.
>
> > How an HC driver implements it is up to them.
> >
> > This would ensure that bandwidth (when it is implemented
> correctly) is counted correctly.
>
> Again, I have to agree. I don't know enough *really in-depth*
> to make an
> educated decision. So, consider my input as a "halfway educated guess"
> ;-)
>
> Thanks for keeping at it,
> ..tom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
