From mboxrd@z Thu Jan 1 00:00:00 1970 From: vkoul@infradead.org (Vinod Koul) Date: Fri, 09 Sep 2011 21:51:22 +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> Message-ID: <1315585282.30522.1.camel@vkoul-mobl4> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, 2011-09-09 at 16:18 +0800, Barry Song wrote: > 2011/9/9 Vinod Koul : > > Looks like Jassi got a user for his proposed API. I am not sure whats > > going on with TI folks, they never showed up here @LPC. > > yes, i can definitely be an user of Jassi's new generic api. it seems > the api is just there for dma in 2d. > > 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. > > as we know, interleaved DMA can also be used for audio driver. for > some audio controllers, if there are n channels, it can't tranfer the > whole audio frame to sound card by one dma channel, and it needs to > tranfer every channel by separate dma. typically, we can define this > kind of xfer to skip other n-1 channel. > > Jassi, you might think my reply as an ACK to "[PATCH] DMAEngine: > Define generic transfer request api". Great, can you two redo patch along with this driver as user of new API :) -- ~Vinod Koul Intel Corp.