On Mon, Jan 16, 2012 at 2:45 PM, Felipe Balbi <balbi@xxxxxx> wrote: > 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 Thanks Felipe, thanks a lot for helping me to understand the driver. Hope you don't mind answering my queries in future. -- 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
