On Sat, Jan 14, 2012 at 1:36 AM, Felipe Balbi <balbi@xxxxxx> wrote: > Hi, > > (do NOT send html or multipart emails, configure your email client to > send text/plain) > > On Fri, Jan 13, 2012 at 05:58:18PM +0530, Praveen Bajantri wrote: >> (always add [2]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. >> >> >> I was under the assumption that whenever we issue a start_transfer command >> (via dwc3_send_gadget_ep_cmd ), device caches the TRB's but doesn't put >> data on wire, and the data gets transmitted/received when IN or OUT token >> is received and after the transmission/reception is done for the last TRB, >> Xfercompete is triggered. > > That might be true, indeed. Although, I _do_ remember that initialy we > were starting transfers as soon as they were queued and we had a bunch > some issues with host side cancelling URBs. > > On top of that, a Start Transfer will start the DMA engine for nothing, > meaning that if we wanted to go to a SoC lower power state, we would > have to, first, issue END Transfer to any pending TRBs before the DMA > gets to an idle state where we could go down to retention. > > Relying on XferNotReady also prevents that extra End Transfer command. > The DMA will always be idle until we enable it with a Start Transfer > command. To receive the first setup data, the TRB initialization is done in udc_start function ( without relying on XferNotReady event ) is there any specific reason? > >> > 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. >> >> Do you mean that, as soon as we program the parameter and command >> registers(in dwc3_send_gadget_ep_cmd ) data is put on wire? >> >> >> We rely on XferNotReady solely >> because we don't want to enable the internal DMA engine unless it's >> strictly necessary to do so. >> >> If your answer to the above query is no, then by relying on XferNotReady >> event don't you think that, extra interrupts are getting generated which >> will reduce the device speed? > > One interrupt alone ? I think it has barely any effect. What we do is > that we start as many requests as there are queued. Meaning that if > gadget driver queued 30 requests, we will start 30 requests on the next > XferNotReady (well, not so true, we start one which doesn't have LST bit > set, but you got my point). > > So far, I see no need to start transfers earlier, we are seeing pretty > good throughput with HS and something which could be improved (later) on > SS. > > Bottomline, is that I don't see (as of today) any needs to change the > way the driver handles transfers, transfer complete and transfer not > ready events, so I will not be changing it and will not accept any > patch doing so without a REALLY good explanation and at least a week of > stress testing. > > Before changing anything on that area, it would be better to get it even > more stable first. > > -- > balbi My only intention is to understand the driver flow and device behavior, i don't have any plans(as of today) to change the way driver handles the transfers. -- 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
