[alsa-devel] [PATCH 0/2 v5] dmaengine: rcar-audmapp: independent from SH_DMAE_BASE

[Kuninori Morimoto]

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 at 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