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
