Hi, On Mon, Jan 16, 2012 at 02:39:50PM +0530, Praveen Bajantri wrote: > >> 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? do you not have the docs ? There's not XferNotReady for SETUP phase. Anyway, the core will not generate XferNotReady event for SETUP phase (which is a shame IMHO), so the EP0 OUT transaction for SETUP has to be always started. -- balbi
Attachment:
signature.asc
Description: Digital signature
