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. > > 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
Attachment:
signature.asc
Description: Digital signature
