On Fri, 7 Aug 2009, Madhavi Manchala wrote:
> The gadget driver has two threads. First thread sends 10 bytes of data
> on bulk-in pipe. Second thread sends 4 bytes of data on same bulk-in
> pipe.
Do the two threads use the same usb_request structure?
> After the bulk-in transfer is finished bulk-in callback is
> called for 4 bytes of data instead of 10 bytes data. So there is a
> mismatch of actual data sent to received data length. The below code
> fails.
>
> bulk_in_complete()
> {
> .
> .
> //Here req->actual is not equal req->length
> if (req->status || req->actual != req->length)
> DBG(fsg, "%s --> %d, %u/%u\n", __func__,
> req->status, req->actual, req->length);
> .
> .
> }
>
> The debug message I get here is "bulk-in --> 4/10". The storage driver
> callback is invoked and gets EOVERFLOW(-75) as URB status.
It sounds like both of your threads are trying to use the same
usb_request structure.
> The bulk-in complete is expecting 10 bytes but the callback is invoked
> with 4 bytes. The storage driver has multiple threads as gadget driver
> where it can send multiple commands from each thread.
>
> So, is there any way I can synchronize data on same pipe in the gadget driver.
Use separate usb_request structures in the different threads.
> > I really don't understand why you are doing this. What reason is there
> > to have more than one thread? Is it really much faster to submit two
> > I/O operations at a time than to wait for the first operation to finish
> > before submitting the second?
> >
>
> I have implemented the multiple threads in the gadget driver code to
> handle the multiple commands in the gadget driver code. The storage
> driver issues the multiple commands to the device without waiting for
> the response from the device for each command. That is the reason, I
> have implemented the threads in the gadget driver code to handle the
> multiple commands. While processing one thread one command, the main
> thread receives the another command and passes it to the another,
> second, thread. Here, the first thread and the second thread uses the
> same pipe. For making the storage driver asynchronous, these
> modifiations are required in the gadget driver code.
That's not true. The driver can be made to work asynchronously with
only one thread. All you have to do is implement a queue of incoming
commands. The thread can process the commands one at a time, as they
reach the head of the queue.
> Please refer to
> same thread dated on 22-July-2009 which describes about the design.
Are you referring to this message?
http://marc.info/?l=linux-usb&m=124835453113445&w=2
It describes the design briefly, but it does not explain why you chose
to use two threads instead of a simpler single-thread design.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
