This is a little similar to the discussion we were having last week about how to do interrupt transfers on the usbdevfs interface. The answer seemed to end up being that you should just do bulk transfers.
I have read the USB spec several times now and see that there are 4 sorts of endpoint and assumed that they required different calls into the hardware to use them. Is that infact not the case? What is an interrupt transfer really? Is it just a transfer which is sent again and again by the driver, or do you submit an interrupt transfer to the hardware as an interrupt and it actually interrupts you (hardware interrupt) on a regular basis? I initially thought it was the latter, I'm now starting to think think that it's the former and it's the driver which continually resubmits the transfer every <interrupt period>. How is that supposed to work with output transfers then? If you schedule an interrupt transfer and the driver continues to resubmit it, doesn't that just mean that, as the initial writer in this thread noted, you get the same data sent to the endpoint again and again? What are interrupt outputs supposed to do? If you have just one thing to send are you better off always just sending a bulk one even to an interrupt endpoint? Roland At 09:43 AM 2/19/02 +1000, Simon Gittins wrote: >Hi > >(Sorry Dave, I hit the wrong button) > >Correct me if I am wrong, I'm a little new to this myself. > >It seems to me that the distinction between interrupt transfers and bulk >transfers is somewhat artificial. > >Despite advice to the contrary I find that a usb_bulk_msg seems to be able >to get a packet through an interrupt endpoint no hassles (on my target >platform, OHCI). For a device that requires a lot of send/receive >transactions (I wrote a driver for a simple smart card reader on a specific >platform), I found that this was the easiest way to talk to the device. I >didn't have to worry about any completion routines, URB management, or >synchronisation (I don't need an interrupt context to wake me up explicitly >when I hope for a reply; I just usb_bulk_msg for a reply). > >I realise that this might not be portable. If so, why do we not have a >usb_irq_msg function/macro? Would this be somewhat easier than going >through the steps a-f below? Is this sort of request so uncommon that we >shouldn't abstract it into some sort of easier process? > >Thanks >Simon Gittins > > > -----Original Message----- > > From: David Brownell [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, 19 February 2002 7:16 AM > > To: Vladimir Dergachev; [EMAIL PROTECTED] > > Subject: Re: [linux-usb-devel] stopping interrupt transfers.. > > > > > > Right now the only portable solution is rather awkward. > > That is: > > > > (a) make sure urb->interval is long enough that it's > > probably not going to suffer interrupt/scheduling > > latency problems (causing extra transfers), and > > submit the URB > > (b) have your completion handler signal the thread > > doing initialization, say using"struct completion" > > and calling complete() on it; > > (c) have that initialization thread wait for that, using > > wait_for_completion() perhaps; > > (d) when that thead wakes up after one transfer, > > may a synchronous usb_unlink_urb() call. > > (e) you'll get one more completion call, with a > > special call saying it's unlinked. > > (f) now it's unlinked. > > > > (Normally the unlink would be done in disconnect > > processing, not device open... which has its own > > set of portability issues, being fixed in 2.5.) > > > > Less portable solutions involve making an async > > usb_unlink_urb() call in the completion handler, > > which works now for EHCI and OHCI (bugfix for > > UHCI will be forthcoming, says Johannes). > > > > Or the UHCI drivers support a "one shot" mode, > > with urb->interval of zero having special meaning. > > > > - Dave > > > > > > > > ----- Original Message ----- > > From: "Vladimir Dergachev" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, February 18, 2002 10:44 AM > > Subject: [linux-usb-devel] stopping interrupt transfers.. > > > > > > > > > > Stupid question: > > > > > > I have a device that has two interrupt endpoints - in and out. > > > During initialization I need to transfer two small packets > > to the devices. > > > The problem is that USB seems to keep transferring the last packet.. > > > How do I stop this ? (usb_unlink_urb does not seem to help). > > > > > > thanks ! > > > > > > Vladimir Dergachev > > > > > > > > > > > _______________________________________________ > > [EMAIL PROTECTED] > > To unsubscribe, use the last form field at: > > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > > > >_______________________________________________ >[EMAIL PROTECTED] >To unsubscribe, use the last form field at: >https://lists.sourceforge.net/lists/listinfo/linux-usb-devel _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
