On 10/01/2013 04:33 PM, Felipe Balbi wrote: > Hi, Hi, > On Tue, Aug 13, 2013 at 07:49:43PM +0200, Sebastian Andrzej Siewior > wrote: >> This patch defines four types of current supported DMA engines >> and assignes them to each dma engine. This should get rid of a >> few ifdefs later on. >> >> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> > > I would *really* like to avoid this construct. Mainly because it's > possible to have the same programming model (from MUSB's point of > view) to start a DMA transfer. What I mean is that the correct way > to set [RT]XCSR is the same no matter which engine you're using. > For DMA-specific parts, we already have ->channel_program() > abstracting that out. This would make it easy to really fast allow all dma engines be compiled in and selected at runtime. However I get your point. From musb's programming model I see a difference between "musb's internal" dma engine which is also used by the ux500 and the model cppi and friends are using. If you look at the ifdefs, they come in those pairs so I think we have two different models here. The RX transfer for instance, ux500 programs the endpoint and starts the transfer. Once the MUSB FIFO is full (interrupt), the driver programs the DMA controller to move the data from the endpoint/MUSB FIFO to memory via DMA. Another interrupt occurs to signal that the DMA transfer completed, packet done. cppi on the other hand programs the DMA engine and triggers musb to start the transfer. In the cppi case the data moved directly from musb into memory and you receive an interrupt once the transfer is complete and inform musb about it. Sebastian -- 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
