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