Re: DT DMA channel binding for Tegra I2S
From: Rob Herring <hidden>
Date: 2011-11-25 15:55:23
Also in:
linux-tegra
On 11/23/2011 05:26 PM, Stephen Warren wrote:
Rob Herring wrote at Wednesday, November 23, 2011 2:55 PM:quoted
On 11/23/2011 03:25 PM, Stephen Warren wrote:quoted
Rob, Grant, Re: http://www.spinics.net/lists/arm-kernel/msg148899.html Background: Tegra's DMA controller needs to be told which DMA "request select" to use for each transfer. The identifies which peripheral to transfer to/from. The Tegra I2S driver needs to know its own "request select" value to pass to the audio driver DMA path. The board files typically provide this to the driver as an IORESOURCE_DMA. I don't think there's any standard binding that creates such a resource when instantiating a platform device from device tree, and the discussions I found when looking for one didn't seem to reach conclusion that there should be one. So, I proposed the following property in the I2S driver's DT binding for this:I think this is a case of every platform being different and IORESOURCE_DMA is not too widely used. Even on PPC, there's not a standard way.quoted
Doc: - dma-channel : The Tegra DMA controller's channel ID for this I2S controller Example: i2s@70002800 { compatible = "nvidia,tegra20-i2s"; reg = <0x70002800 0x200>; interrupts = < 45 >; dma-channel = < 2 >; }; Does that look reasonable? Or, should I pursue some more standardized solution?I had some discussion with Thomas Abraham about this for the pl330 dma: http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-September/008269.html So I would just add a phandle to the dma controller here.So you mean just modify the binding as follows: apbdma: dma@NNNNN { ... }; i2s@70002800 { dma-channel = < &apbdma, 2 >; }; ... and leave the code I quoted as-is?
Right. Although, I think you are possibly missing some other properties for i2s mode like word size and master/slave mode. I think the ideal case is that a single ASoC platform driver for DT could handle multiple SoCs.
I /think/ the rest of the patch you linked isn't really relevant to Tegra at present, since it isn't ported to the DMA engine (yet?).
Yes, of course.. Rob