On Wed, Jul 22, 2009 at 8:51 PM, Alan Stern<stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 22 Jul 2009, Madhavi Manchala wrote:
>
>> My doubt about this variable is, how it will be filled and where it
>> will be filled? I have used the dummy hcd driver for this.
>
> There are plenty of lines in file_storage.c of the form:
>
> fsg->next_buffhg_to_file = ...
>
> That's how the variable gets set.
>
>> How can the req->context is equivalent to the struct fsg_buffhd? OR Is
>> there any API that passes the struct fsg_buffhd pointer to the upper
>> layers like dummy hcd / usb core?
>
> If you look in do_set_interface(), you'll find a line that says:
>
> bh->inreq->context = bh->outreq->context = bh;
>
> That's how req->context gets set to point to an fsg_buffhd structure.
>
> Alan Stern
Dear Alan,
Thanks for the information.
I overlooked the **preq in the alloc_request() function. I understand
it now a little bit more.
I have been modifying the file storage gadget driver code to handle
the multiple commands from a few days. As a part of this, first I have
implemented the three threads as shown below.
main thread
|
|
---------------------
| |
Thread-1 Thread-2
The idea behind it is, the main thread queues the commands and wakeups
the thread-1 (currently I have created only main thread and thread-1).
Then the thread-1 do the remaining functionality.
main thread functionality
-----------------------------------
1) Invokes the get_next_command and waits for the command.
2) This will be signaled from completion callback function.
3) Then, queues the command.
4) Wakeups the thread-1 to process command.
5) Again, sleeps to get the next command.
thread-1 functionality
------------------------------
1) This thread will be started from the fsg_bind function and waits to
receive a signal from the main thread.
2) After wakeup from the main thread, it performs the do_scsi_command,
finish_reply and send_status functionality.
3) Again, sleeps to wake from the main thread.
After doing the above modifications, the file_storage gadget driver
works fine without any issues.
However, I need some clarifications for the following.
1) Is it possible to handle the multiple commands in the gadget driver
code if we do the modifications as said above without doing any
modifications to the dummy_hcd driver at all. Ofcourse, if the mass
storage driver sends the multiple commands.
2) I would like to wake up thread-2 from main thread when ever there
is a next command to process (at this time thread-1 is busy processing
first command). I guess, to handle like this, I need to create
different buffer heads for each thread. Am I correct? Is there any
different approach to handle multiple commands?
Please let me know, whether this is a feasible or not.
Thanks in advance.
With Regards,
Madhavi M.
--
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
