[PATCH] dmaengine: add CSR SiRFprimaII DMAC driver
Vinod Koul
vinod.koul at intel.com
Wed Sep 14 01:07:17 EDT 2011
On Mon, 2011-09-12 at 12:03 +0530, Jassi Brar wrote:
> On 11 September 2011 21:32, Vinod Koul <vkoul at infradead.org> wrote:
> > On Fri, 2011-09-09 at 16:18 +0800, Barry Song wrote:
>
> >> Jassi prefer to use a transfer type instead of a control command.
> >> though we will not really change the interleaved setting for every
> >> transfer(it is more possible for one device, we will not change the
> >> xlen/ylen/dma_width setting in the whole life period), i do believe
> >> the transfer type is enough flexible for my possible applications to
> >> change xlen, ylen and dma_width in different transfers.
>
> > Is this usually the assumption or yours is a special case, how about
> > your's Jassi?
>
> 1) Having type per transfer is more flexible than having to set the type
> for a channel using a control command. The overhead is negligible
> because the client reuses the same descriptors with only changed
> source/destination addresses.
> 2) DMA_SLAVE_CONFIG is meant for slave (Mem<->Dev) channels,
> whereas it is very likely(for multimedia drives) to have such operations
> Mem->Mem as well.
> 3) Someday if people realize we can fold many, if not all, transfer types into
> one, this api has the potential to be the survivor.
>
> That was where my mind was grazing when I chose to do what I did.
I would agree that it makes sense to have it in API rather than config.
--
~Vinod
More information about the linux-arm-kernel
mailing list