From mboxrd@z Thu Jan 1 00:00:00 1970 From: vinod.koul@intel.com (Vinod Koul) Date: Wed, 14 Sep 2011 10:37:17 +0530 Subject: [PATCH] dmaengine: add CSR SiRFprimaII DMAC driver In-Reply-To: References: <1315374075-15479-1-git-send-email-Baohua.Song@csr.com> <438BB0150E931F4B9CE701519A4463010871804A46@bgsmsx502.gar.corp.intel.com> <438BB0150E931F4B9CE701519A4463010871804A48@bgsmsx502.gar.corp.intel.com> <1315518378.6638.2.camel@vkoul-mobl4> <1315756966.2246.3.camel@vkoul-mobl4> Message-ID: <1315976837.26251.473.camel@vkoul-udesk3> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, 2011-09-12 at 12:03 +0530, Jassi Brar wrote: > On 11 September 2011 21:32, Vinod Koul 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