Replying to my own post ... I've found a way to make my code work without having to deallocate / reallocate the urb.
It seems that after a successful call, urb->dev is getting set to 0. In my write_callback routine I simply re-set urb->dev to its correct value (which is stored in the private device structure) and the subsequent calls using that urb are fine. I haven't found anything in my code that could be stepping on it, but I guess I'm not quite ready to rule that possibility out yet either. On Tue, 2003-11-11 at 15:59, Henry Culver wrote: > On Tue, 2003-11-11 at 15:23, Alan Stern wrote: > > On Tue, 11 Nov 2003, Henry Culver wrote: > > > > > I am in the process of writing a device driver for a device which is a > > > combination vacuum flourescent display and ir receiver. The driver is > > > functional, but has some problems. > > > > > > The device has a single configuration, and single interface with 2 endpoints. > > > The endpoints are transfer type "interrupt". > > > > > > My open routine allocates 2 urb's (one for each endpoint, in and out) and > > > fills them with usb_fill_int_urb. I have an "in" callback routine and an > > > "out" callback routine. > > > > > > I can read ir byte codes from the device and write characters to the display > > > including control codes which position subsequent character writes, clear > > > the display and set brightness. > > > > > > My problem is that I cannot seem to reuse the out urb. When my write_callback > > > routine is called, the urb->status is 0, but another write to the device > > > blocks and the urb->status is thereafter -EINPROGRESS. If in my callback > > > routine I usb_unlink_urb, usb_free_urb and then usb_alloc_urb(0) and > > > re-initialize the structure, everything behaves correctly. > > > > I don't understand. What do you mean "another write to the device > > blocks"? If the write blocked, how would you know what urb->status was > > afterwards? -- your machine would be locked up. After submission, > > usb->status is _supposed_ to be -EINPROGRESS; it stays that value more or > > less until it has completed. > > Sorry for the missing details. It's linux-2.4.21. When I say it blocks > I mean that I call interruptible_sleep_on in the write routine and > wake_up in the write_callback routine. If I remove the > interruptible_sleep_on, the write never seems to finish (the status > never changes from EINPROGRESS and the data never appears on the > display). That is to say, the write_callback doesn't get called > for the 2nd write. As near as I can tell the 2nd urb is never > finishing. > > My next step I guess is to printk the various fields in the urb and see > exactly how a new urb is different from a used one. > > > > > > After each successful write, I have to release and then re-allocate the > > > out urb. Shouldn't I be able to reuse it? If so, does anyone have any > > > helpful hints as to what might be going on here? > > > > You certainly should be able to reuse it. What version of Linux and which > > host controller driver are you using? If you aren't using 2.6, try it out > > and see if it works any better. > > > > Alan Stern > > > > Thanks, > -Henry Culver > -Culver Consulting > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
