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

[Kuninori Morimoto]

Hi Laurent

> > 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)
> 
> I'm not saying you need to, I just wanted to raise the issue. From what I 
> understood Vinod was also having doubts on using the DMA engine API for this 
> device, given that it doesn't really match what the DMA engine API has been 
> designed for. If everybody else is fine with your patches, and if the sound DT 
> nodes are not considered overly complex with the DMA engine bindings, then I 
> have no objection.

Thank you for your feedback,
and I'm so sorry for my previous rude mail.

I think 2nd DMAC doesn't be complex issue, because it is very simple device.
But, this is my side (sound driver point) opinion.
Of course I can agree about DMAEngine side opinion/concern.
I don't know what it the best solution.

Now, I asked about it to Mark (= ALSA SoC maintainer).
I can follow ALSA SoC maintainer + DMAEngine maintainer.

Best regards
---
Kuninori Morimoto