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@intel.com)
"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