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

[Kuninori Morimoto]

Hi Arnd

I need your comment about this, too.
Because, you are ARM platform maintainer, and my DTS patch for it was rejected before.
So, It needs total agreement from
 - DMAEngine maintainer
 - ALSA SoC maintainer
 - ARM platform maintainer

> > > > 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)
> 
> http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focus=42054
> http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focus=42998
> 
> Sorry for sudden request, but can you please check above mail thread ?
> This topic is for Renesas sound DMAC driver.
> Renesas sound driver is using 2 DMAEngine now (= 1st/2nd).
> And, this mail thread was started for replacement of 2nd DMAC.
> (This replacement is because 2nd DMAC driver's bug fix).
> 
> In this mail thread, (I was misunderstanding about agreement though... but)
> Vinod/Laurent are thinking that 2nd DMAC should be implemented in sound driver side.
> (I'm thinking that both 1st/2nd DMAC on DMAEngine is useful)
> But if we need to move 2nd DMAC from DMAEngine to sound driver,
> I need to get agreement from you.
> What is you opinion ? If you agree about it, I will send the patch to
> ALSA/DMAEngine ML.
> 
> Best regards
> ---
> Kuninori Morimoto
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html