When I do several back to usb_bulk_msg calls (64 byte writes), I notice
each one takes about 1 ms to complete. I decided to probe the usb trace
on the hardware. I noticed that even when the device and driver are
idle, I see packets being transmitted every 1ms. I am showing my
ignorance here, b
Hi,
I just started developing a driver for the USB 2.0 data acquisition
board I just built. I based the driver design on usb-skeleton.c file.
Everything is working fine so far, but I am having a throughput problem.
I am currently testing the device plugged into a USB 1 controller.
When I do se
Just to be clear:
- usb_unlink_urb() doesn't care any more about that state.
(There seemed to be agreement that it must not matter.)
There is agreement, yes. But right now the host controllers can't
handle this check not being there. I've put it back in, with a big
FIXME comment.
You mean just
On Fri, Mar 07, 2003 at 03:11:16PM -0800, David Brownell wrote:
> Just to be clear:
>
> >>>- usb_unlink_urb() doesn't care any more about that state.
> >>> (There seemed to be agreement that it must not matter.)
> >
> >There is agreement, yes. But right now the host controllers can't
> >handle th
Just to be clear:
- usb_unlink_urb() doesn't care any more about that state.
(There seemed to be agreement that it must not matter.)
There is agreement, yes. But right now the host controllers can't
handle this check not being there. I've put it back in, with a big
FIXME comment.
You mean just
On Thu, 6 Mar 2003, Greg KH wrote:
> On Mon, Mar 03, 2003 at 02:14:54PM -0500, Alan Stern wrote:
> > Here is a slightly updated patch for usb-skeleton.c. It has been tested
> > minimally with real hardware, but David Brownell would like to see some
> > more tests using "gadget zero".
>
> Um, is
