non-completed bulk transfers eating memory

bridged with qdn.public.ddk.usb
Post Reply
Nazim Ali Bharmal

non-completed bulk transfers eating memory

Post by Nazim Ali Bharmal » Tue Jul 30, 2002 4:30 pm

I'm writing a driver for a CCD camera, and have managed to get the driver to
half-work. The timing issues are poorly detailed so I've been forced to use
as much of the Linux driver methodology as possible.

Whilst most of the USB communication (via endpoint 0) is successful, the
downloading of data (via a bulk endpoint) is not so great. Essentially, I
submit an URB requesting N bytes. Either I get N bytes back, or none and
usbd_urb_status says the transfer is in progress. I can't wait for some time
(doesn't work, ends up waiting for all URBs subsequently) so I just call
usbd_io again without submitting an URB until it either receives the data (this
can mean between 2 and 100 repetitions) or it reaches a repetition limit of
1000 and gracefully gives up - this means a lost row of the image.

The latter might be a problem; the ammount of memory during these operations
goes up dramatically (up to 30Mb for about 312Kb transfer) and is all due to
the devu-uhci driver. When I slay it, all the memory is nicely returned so it
seems that my download process (which is the only place where this memory
increase occurs) is somehow queuing data in the USB stack. How can I release it
after every read? Any ideas as to how best to download the data once only,
so I don't have to effectivley poll the USB stack?

Nice to see it take pictures in QNX though!

development system email / NOT ARCHIVED

Post Reply

Return to “qdn.public.ddk.usb”