Question on snd_soc_dai_link

Question on snd_soc_dai_link

[Timur Tabi]

I have a question about these DAI structs for ASoC.

Let's take eti_b1_wm8731.c as an example.  It contains this structure:

static struct snd_soc_dai_link eti_b1_dai = {
	.name = "WM8731",
	.stream_name = "WM8731",
	.cpu_dai = &at91_i2s_dai[1],
	.codec_dai = &wm8731_dai,
	.init = eti_b1_wm8731_init,
	.ops = &eti_b1_ops,
};

Notice that the .cpu_dai field is hard-coded to use the 2nd I2S device on the AT91.

The problem I'm having with this approach is that everything is hard-coded.  On PowerPC, 
this approach doesn't work well, because we have a "device tree" that dictates what 
devices are present on the SOC.

For a Freescale SOC that has two I2S devices (for example), both devices would be listed 
in the device tree, with the base address of the memory-mapped registers.  This means that 
a Freescale I2S driver would have its 'probe' function called (much like PCI does) each 
time the kernel processes an I2S node in the device tree.

This means that when the machine driver (which has the snd_soc_dai_link structure) loads, 
there's no guarantee that the I2S driver has also loaded and the probe functions have been 
called.  It gets even more complicated if only one I2S device has a codec connected to it, 
because then I need to kmalloc the snd_soc_cpu_dai structures and somehow tell the 
snd_soc_dai_link structure which one to use.

Has any thought been given to making these structures more dynamic and handling 
interdependencies among the drivers?  As it stands now, it looks like I'm going to have to 
hard-code everything in the drivers and break the device tree paradigm.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

Re: Question on snd_soc_dai_link

[Liam Girdwood]

On Fri, 2007-05-25 at 16:55 -0500, Timur Tabi wrote:
> I have a question about these DAI structs for ASoC.
> 
> Let's take eti_b1_wm8731.c as an example.  It contains this structure:
> 
> static struct snd_soc_dai_link eti_b1_dai = {
> 	.name = "WM8731",
> 	.stream_name = "WM8731",
> 	.cpu_dai = &at91_i2s_dai[1],
> 	.codec_dai = &wm8731_dai,
> 	.init = eti_b1_wm8731_init,
> 	.ops = &eti_b1_ops,
> };
> 
> Notice that the .cpu_dai field is hard-coded to use the 2nd I2S device on the AT91.
> 
> The problem I'm having with this approach is that everything is hard-coded.  On PowerPC, 
> this approach doesn't work well, because we have a "device tree" that dictates what 
> devices are present on the SOC.
> 

Fwiw, ASoC was designed to only handle static DAI mappings between a
codec and SoC CPU. This is because the audio codec was never intended to
physically change DAI at runtime or be probed (most codecs don't support
any device readback). The DAI mapping between CPU and codec was constant
and always known to the machine driver.

Although, I can now see the need for a more dynamic approach for PowerPC
based systems. Btw, I'm not very familiar with PowerPC, would you be
able to point me at some example "device tree" initialisation code.

Liam

Re: Question on snd_soc_dai_link

[Timur Tabi]

Liam Girdwood wrote:

>> The problem I'm having with this approach is that everything is hard-coded.  On PowerPC, 
>> this approach doesn't work well, because we have a "device tree" that dictates what 
>> devices are present on the SOC.
> 
> Fwiw, ASoC was designed to only handle static DAI mappings between a
> codec and SoC CPU. 

On PowerPC, the mapping *is* static, but unknown until boot time.  OK, maybe that's not what you meant by static.

> This is because the audio codec was never intended to
> physically change DAI at runtime or be probed (most codecs don't support
> any device readback). The DAI mapping between CPU and codec was constant
> and always known to the machine driver.

On PowerPC, the device tree contains information about the board that cannot be obtained via probing the hardware.  Well, sometimes it contains information that *could* be obtained by probing, but that information is there only for probing.  The idea is that we can use a device tree to store device-specific information (like the I2C bus address) instead of passing command-line parameters to the device drivers.

> Although, I can now see the need for a more dynamic approach for PowerPC
> based systems. Btw, I'm not very familiar with PowerPC, would you be
> able to point me at some example "device tree" initialisation code.

All of the device trees are in arch/powerpc/boot/dts/.  A detailed description of the layout can be found in booting_without_of.txt.

In summary, the device tree is a hierarchy of "nodes", where each node lists a device (usually some controller on the SOC or some peripheral on the board), its address (e.g. the base address of the device's memory mapped registers), and a bunch of properties that the driver needs to initialize and communicate with the device.

I have not yet figured out how to represent the codec in the device tree.  In this particular case, the problem is unusual in that there is no I2C bus connected, so there's no way to control the codec, and so there's not much need for a node.

Re: Question on snd_soc_dai_link

[Liam Girdwood]

On Mon, 2007-05-28 at 20:36 -0500, Timur Tabi wrote:
> Liam Girdwood wrote:
> 
> >> The problem I'm having with this approach is that everything is hard-coded.  On PowerPC, 
> >> this approach doesn't work well, because we have a "device tree" that dictates what 
> >> devices are present on the SOC.
> > 
> > Fwiw, ASoC was designed to only handle static DAI mappings between a
> > codec and SoC CPU. 
> 
> On PowerPC, the mapping *is* static, but unknown until boot time.  OK, maybe that's not what you meant by static.
> 
> > This is because the audio codec was never intended to
> > physically change DAI at runtime or be probed (most codecs don't support
> > any device readback). The DAI mapping between CPU and codec was constant
> > and always known to the machine driver.
> 
> On PowerPC, the device tree contains information about the board that cannot be obtained via probing the hardware.  Well, sometimes it contains information that *could* be obtained by probing, but that information is there only for probing.  The idea is that we can use a device tree to store device-specific information (like the I2C bus address) instead of passing command-line parameters to the device drivers.
> 
> > Although, I can now see the need for a more dynamic approach for PowerPC
> > based systems. Btw, I'm not very familiar with PowerPC, would you be
> > able to point me at some example "device tree" initialisation code.
> 
> All of the device trees are in arch/powerpc/boot/dts/.  A detailed description of the layout can be found in booting_without_of.txt.
> 
> In summary, the device tree is a hierarchy of "nodes", where each node lists a device (usually some controller on the SOC or some peripheral on the board), its address (e.g. the base address of the device's memory mapped registers), and a bunch of properties that the driver needs to initialize and communicate with the device.
> 
> I have not yet figured out how to represent the codec in the device tree.  In this particular case, the problem is unusual in that there is no I2C bus connected, so there's no way to control the codec, and so there's not much need for a node.

Ok, I now think I can see now how the PowerPC tree structure defines the
machine. If my understanding is correct, I think it may be possible to
parse the tree and build the DAI mappings and sound configuration at
init, although this may require some device-type additions:-

e.g.

sound-dev@0 {
	device-type = "asoc-sound";
	dai-link@0 {
		device-type = "audio-interface";
		i2s@2400 {		// PSC3
			device_type = "i2s-dai"; // I2S digital audio interface	
			compatible = "mpc5200-psc-i2s";
			cell-index = <2>; // i2s port 3
			reg = <2400 100>;
		};
		codec@0 {
			device_type = "codec";
			compatible = "codec name"; // e.g. WM8731
			i2c_addr = <34>;
		};
	};
	asoc-platform@xxxx {
		device-type = "audio-dma";
		compatible = "&mpc5200_dma";
	};
	asoc-machine@xxxx {
		device-type = "sound";
		compaitble = "machine name";
		interrupts = <2 3 0>;
		interrupt-parent = <&mpc5200_pic>;
	};
};

This maps the WM8731 codec to an imaginary PowerPC 5200 based machine
using PSC3 for I2S audio. It would be preferable to only probe the
parent device and not the children, although I'm not sure if this is
possible using this model. ASoC works on other SoC by being a platform
device.

Please let me know if I'm way off here. The device tree looks like an
elegant solution for machine initialisation/description.

Liam

Re: Question on snd_soc_dai_link

[Timur Tabi]

Liam Girdwood wrote:

> This maps the WM8731 codec to an imaginary PowerPC 5200 based machine
> using PSC3 for I2S audio. It would be preferable to only probe the
> parent device and not the children, although I'm not sure if this is
> possible using this model. ASoC works on other SoC by being a platform
> device.

Yeah, getting a cross-platform driver to work on PowerPC and non-PowerPC architectures is ... difficult.

> 
> Please let me know if I'm way off here. The device tree looks like an
> elegant solution for machine initialisation/description.

I'm going to study this and run it by others in my department (we handle all the Linux architectural issues for Freescale SOCs).  I can tell you that you're very close, but it will require some tweaks.  Off the top of my head, I see a few problems:

1) The I2C addresses are specified in a separate I2C node
2) I don't know much about the 5200, but on my part, the DMA operations are provided by the I2S device.  We don't use the generic DMA engine.
3) The register mapping for the I2S device normally occurs inside the SOC node, not here.  We'd probably need to use some kind of cross-link to represent that.

Re: Question on snd_soc_dai_link

[Liam Girdwood]

On Tue, 2007-05-29 at 09:36 -0500, Timur Tabi wrote:
> Liam Girdwood wrote:
> 
> > 
> > Please let me know if I'm way off here. The device tree looks like an
> > elegant solution for machine initialisation/description.
> 
> I'm going to study this and run it by others in my department (we handle all the Linux architectural issues for Freescale SOCs).  I can tell you that you're very close, but it will require some tweaks.  Off the top of my head, I see a few problems:
> 
> 1) The I2C addresses are specified in a separate I2C node
> 2) I don't know much about the 5200, but on my part, the DMA operations are provided by the I2S device.  We don't use the generic DMA engine.

Fwiw, ASoC splits out the audio DMA code from I2S, AC97 or PCM
controllers as there isn't too much difference between audio DMA code
for each interface. Any controller specific data is passed in at
hw_params time (by the I2S/AC97/PCM controller driver) to configure
addresses, width, etc

Liam