Hi Vinod, On Tuesday 16 December 2014 22:09:04 Vinod Koul wrote: > On Tue, Dec 16, 2014 at 09:03:38AM +0000, Kuninori Morimoto wrote: > > Hi Vinod > > > > > > This rcar-audmapp driver is very limited usage, and user is only sound > > > > device/driver. Sound driver configures both 1st/2nd DMAC if needed > > > > (it depends on platform). Sound driver knows all reg address / mem > > > > address which are needed for 1st/2nd DMAC settings. 1st/2nd DMAC > > > > needs general DMAEngine settings method, not special. Now, sound > > > > driver + 1st/2nd DMAC works well on my local environment.> > > > > Are you not using the sound dmaengine library then, right? > > > > At this point, yes. > > But, I got request from Mark to use it > > Yes that is the subsytem recommendation > > > # current dmaengine "method" on my driver is same as library. > > # but I need to fix non-dmaengine area > > > > > One more question, audio data will be in system memory and then it needs > > > to be transfered to periphral FIFO, how will data travel thru these two > > > DMAs? > > > > like this > > > > 1st DMA 2nd DMA > > > > [mem] -> [periphral IP-A] -> [periphral IP-B] -> speaker > > Okay and by current implementation you wont be able to use the generic > dmaengine sound layer. That layer assumes you will have only one dmaengine > channel to configure and will configure only one DMA and which is 1st DMA > here. > > So what do we do we 2nd one here. The point that 2nd DMA is behind the 1st > DMA, should the users know about it and configure? I am not sure... > If not, then who should configure this. Another candidate is 1st DMA, but > then from the point of 1st DMA should it configure 2nd DMA as well, treat it > as its salve... sounds plausible but am not too sure... comments? The second DMA is not a slave of the first one, given that there's a peripheral in-between. Not that I'm advocating for it, but given how simple the second DMA engine is, and given that it is dedicated to a single function (transferring data between sound-related IPs, nothing else is possible) and can't thus be used as a general purpose DMA engine, I wouldn't mind handling it internally as part of the sound drivers instead of exposing it through the DMA engine API. -- Regards, Laurent Pinchart -- 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
