Re: Linux USB file storage gadget with new UDC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, Jan 22, 2013 at 05:22:58PM +0800, victor yeo wrote:
> >> >> > Is there any way to to further debug into why do_scsi_command() is not called?
> >> >>
> >> >> usbmon, printk(), trace_printk(), kernel function tracer, there are many
> >> >> ways choose one and spend some time debugging, I'm sure you'll find the
> >> >> bug.
> >> >
> >> > It sounds like the UDC driver now works okay for control transfers but
> >> > not for bulk transfers.
> >> >
> >>
> >> Some code in file_storage.c that i cannot understand. In
> >> ep0_complete(), the code snippet:
> >>
> >>         if (req->status == 0 && req->context)
> >>                 ((fsg_routine_t) (req->context))(fsg);
> >>
> >> Does the UDC driver provide the context pointer to file_storage.c?
> >
> > That belongs to the gadget driver. file_storage.c maintains that
> > req->context.
> >
> >> Another gadget question: get_next_command() is receiving command from
> >> host PC, UDC HW isr routine is also receiving data from host PC. What
> >> is the difference between these two?
> >
> > hmm... ISR receives data and bounces it back to gadget driver. What do
> > you mean ?
> 
> Ok, rephrase the question, is this the flow for bulk transfer?
> 
> 1) data is received by Usb mass storage HW, the UDC driver ISR is
> called to read the data to usb_request buffer
> 2) bulk_out_complete() in gadget driver, is called to set buffer state to full
> 3) get_next_command() in gadget driver, is called to read the CBW.
> 4) do_scsi_command() to process SCSI command encoded in CBW
> 5) send_status() sends the CSW to host

Something like below:

OUT Token -> ISR -> giveback() -> bulk_out_complete() ->
get_next_command() -> do_scsi_command() -> usb_ep_queue() -> OUT/IN
Token -> ISR -> bulk_out_complete() -> send_status()

> i see this code snippet in fsg_main_thread(), i cannot understand it,
> please tell me what the purpose of this code is. is handle_exception()
> tries to process error condition?
> 
>    if (exception_in_progress(fsg) || signal_pending(current)) {
>                         handle_exception(fsg);
>    }

Mass storage is processed in thread context. This is just the main loop.
It tells us to continue running while we have a signal_pending() (like
SIGHUP and the like) or an exception which is raised with
raise_exception().

-- 
balbi

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux