Hi, sorry for the delay... On Wed, Oct 02, 2013 at 03:07:25PM +0200, Sebastian Andrzej Siewior wrote: > > 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. true. > 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. you still need to program the endpoint, no ? I think that's just a minor discrepancy which should be removed. What I'm trying to say is that musb driver should look the same no matter the DMA engine, iow CPPI case is the one which looks more correct; it first programs CSR register then call ->channel_program(). I agree that we need a wait to choose the dma engine in runtime, but I believe cleaning up endpoint programming should be done first. cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
