Hi Laurent, everyone, On Mon, Jan 26, 2015 at 12:01 PM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > Hi Morimoto-san, > > On Monday 26 January 2015 02:57:32 Kuninori Morimoto wrote: >> 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. > > No worries, I haven't found it rude. I know it could seem that I've trying to > block this patch series without any reason, so a straight to the point reply > was expected :-) > >> 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. > > I'd like to hear Marc's opinion, yes. And if Vinod is fine with your proposal, > that's totally fine with me as well. >From my side anything is fine really, and I agree that the DT integration patch looked rather "special". =) At the same time I do think it makes sense to model the DT after the hardware. So if there is a separate DMA controller device then I can't see what is wrong with representing that in DT as a separate device. That aside, the current implementation may not have been entirely clean so perhaps we can begin by fixing that and see where that leads us. So I wonder as an incremental approach, how about simply reworking the DT interface (old code has 200+ channels mapped out individually) to something more manageable (maybe 20+ groups instead)? If that still seems completely wrong DT-wise then we can look into how to rework the architecture. Cheers, / magnus -- 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
