[alsa-devel] Question on snd_soc_dai_link
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.
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
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.
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
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.
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:
- The I2C addresses are specified in a separate I2C node
- 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
participants (2)
-
Liam Girdwood -
Timur Tabi