Hi Morimoto-san, On Wednesday 21 January 2015 00:51:20 Kuninori Morimoto wrote: > Hi Laurent, Vinod > > Thank you for your feedback > > >> This time I added SoC/platform side setting patches too (= 3) - 6)). > >> SoC/platform side setting needs many entries for this rcar-audmapp, > >> because it has many combinations. > >> But, I believe this is very normal DMAEngine style, not special. > > > > Vinod commented on 22/12/2014 (Message-ID: > > <20141222151447.GL16827@xxxxxxxxx>) > > > > "I think this makes sense. Going thru the driver, it was clear that we > > were not really gaining anything for using dmaengine API here. So agree > > that lets use dmanegine for 1st dmac thru dmaengine library and then > > configure this in your sound driver.." > > > > My understanding is that a solution specific to the sound driver was > > preferred, instead of a generic DMA engine driver. Have I missed something > > ? > > Grr... my understanding was that > "1st DMAC will use dmaengine library (= sound framework has sound-dma-xxx > functions) 2nd DMAC will use normal dmaengine API" > > But, I need to fixup sound driver ? > - 1st DMAC = normal DMAEngine API > - 2nd DMAC = part of sound driver > > Sorry, for discuss it again here, but I want flexible switching > for 1st/2nd DMAC (because of 1st/2nd DMAC path combination). > So, using same DMAEngine interface from sound driver is easy to > implement/understanding. > - 1st DMAC = normal DMAEngine API > - 2nd DMAC = normal DMAEngine API The first DMA engine (the one handling transfer from/to memory) is a general- purpose DMA engine. It should be handled by a driver that implement the DMA engine API, no doubt about that. The second "DMA engine" is dedicated to the sound IP cores and is far from being general-purpose, given that it only supports peripheral-to-peripheral transfers, without even interrupts to report transfer completion. I'm not even sure we can call it a DMA engine as there's no Direct Memory Access involved here :-) The hardware looks more like a crossbar switch with programmable routing of audio channels. That's why Vinod and I were wondering whether it really makes sense to implement it using the DMA engine API, given the resulting complexity of the DT bindings (the sound DT nodes look a bit scary), or if it could be simpler to implement it as part of the Renesas sound drivers. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
