Hi Laurent, Vinod, and Arnd # I added Linux ALSA ML and Mark > > >> 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. If you are caring about naming (= DMA), it is "Audio *DMAC* peri peri". I wonder dma_transfer_direction has DMA_DEV_TO_DEV (this driver is not using it though...) it is for peripheral-to-peripheral ? And API point of view, 2nd DMAC doesn't need new DMAEngine API. >From DRY (= Don't Repeat Yourself) point of view, I don't want to re-create "similar but different" implementation for naming issue. >From DT bindings complexity point of view, which is complex ? DMAC driver side ? DT node side ? Indeed sound driver needs many node, but is is regular arrangement, not complex, and, it needs many node for 1st DMAC too. I don't understand why 1st is OK, 2nd is not OK ? >From DMAC driver side complexity point of view, 1st DMAC has same complexity (= it accepts many node from many drivers) ? If I need to move 2nd DMAC from DMAEngine to sound driver side, please explain it to Mark Brown (= ALSA SoC maintainer) Best regards --- Kuninori Morimoto Best regards --- Kuninori Morimoto -- 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
