+linux-usb On Fri, Jan 13, 2012 at 01:28:58PM +0200, Felipe Balbi wrote: > Hi, > > (always add linux-usb@xxxxxxxxxxxxxxx to Cc list) > > On Fri, Jan 13, 2012 at 04:03:32PM +0530, Praveen Bajantri wrote: > > I was going through the DWC3 code, I had some queries. > > 1.In �__dwc3_gadget_ep0_queue, a request is processed only if�xfernotready > > event has�already�occurred (a flag DWC3_EP_PENDING_REQUEST is set when > > xfernotready event has�occurred�and endpoint's request_list is empty). > > instead of checking for a flag you could have directly checked the > > request_list empty or no.�i.e if the request_list is empty then start > > processing the request. > > May i know, is there any specific reason why you are setting a > > flag(DWC3_EP_PENDING_REQUEST) in dwc3_ep0_do_control_data function and > > checking it in queue to process the requests, when request processing can > > be easily done by checking request_list? > > We want to process requests based on XferNotReady alone. If we were to > start requests when there was something available on the list, we would > them before the host wants to see them on the wire, which in some weird > cases it could fall into NAK Limitation. > > > 2.Setting up of trb's is done after the xfernotready interrupt( except for > > the receiving SETUP packets ) i.e �for example: > > DWC3_TRBCTL_CONTROL_STATUS3 trb's can be setup as soon as we complete the > > data phase, but looking at the code what i can understand is trb's are > > prepared when xfernotready interrupt has�occurred.�i.e when device wants > > to start the transfer but no valid trb is available(i am just guessing > > here). > > Not the device, the device never wants to start a transfer. The device > does what the host asks. XferNotReady is triggered when we get IN or OUT > token from the host but there are no initialized/cached TRBs with HWO > set. > > > Is there any advantage in following the method what you are following? > > yes > > > because we can setup trb's before device generates xfernotready event. > > Please correct me, if my understanding of the driver is wrong. > > yes, we can, but we could, again, fall into NAK limitation if the Host > doesn't want to see this transfer now. We rely on XferNotReady solely > because we don't want to enable the internal DMA engine unless it's > strictly necessary to do so. > > -- > balbi -- balbi
Attachment:
signature.asc
Description: Digital signature
