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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
