On Wed, Dec 24, 2014 at 01:39:05AM +0000, Kuninori Morimoto wrote: > > Hi Vinod, Laurent > > > > > The second DMA controller is specific to the sound subsystem. I thus wonder if > > > > the additional complexity of supporting it through the DMA engine API (both in > > > > terms of code complexity on the DMA driver side and the sound driver side and > > > > in terms of DT bindings complexity) is worth it, or if it would be simpler and > > > > cleaner to support it with a driver specific to R-Car sound. You're more > > > > knowledgeable than I am on the subject, so I'll trust your judgment. > > > > > > Yes, I agree to your opinion. R-Car DMAC should keep "general-purpose" DMA engine. > > > It is easy to control if 1st/2nd DMA was separated from sound driver point of view. > > > I guess sound HW which needs 2 DMAC is very rare case(?). I want "keep it simple" > > > > > > Vinod, this means, we want to have 2 different DMA (= 1st/2nd) for sound. > > > 1st DMA is general DMAC, 2nd DMA is sound specific DMAC. > > > What is you opinion ? > > I think this makes sense. Going thru the driver, it was clear that we were > > not really gaining anything for using dmaengine API here. So agree that lets > > use dmanegine for 1st dmac thru dmaengine library and then configure this in > > your sound driver.. > > Thank you for your opinion. > My understanding is that we can replace rcar-audmapp driver same as before. Use my next to rebase > Current DMAEngine branch has fixup(?) branch, and we need to rebase to it. > And, this 2nd DMA needs 1st DMA which was created by Laurent. > So, I will send v3 patch if Laurent's DMA driver was accepted I have the PULL request from Laurent, should be able to process todays -- ~Vinod -- 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
