Re: [PATCH] dmaengine: add CSR SiRFprimaII DMAC driver

[Vinod Koul]

On Mon, 2011-09-12 at 12:03 +0530, Jassi Brar wrote:
> On 11 September 2011 21:32, Vinod Koul <vkoul@xxxxxxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/