[alsa-devel] About the platform_name field in snd_soc_dai_link
Hi,
I'm wondering what exactly a snd_soc_platform is. Apparently the snd_pcm_ops/pcm_new/pcm_free are specific to a platform. For my understanding these operations are more specific to a cpu_dai. Looking at the tree it seems that each cpu_dai has exactly one possible platform, which seems logical to me because the cpu_dai knows how to transfer the data.
My problem on i.MX is that I currently have two possible cpu dais (imx-ssi.[01]) and each can be configured to use dma or fiq depending on the dma capabilities. So the cpu_dai knows which pcm_ops we have to use, but currently it's the soc glue code which has to decide in platform_name. Am I understanding something wrong here?
Sascha
On Tue, Aug 10, 2010 at 03:38:18PM +0200, Sascha Hauer wrote:
I'm wondering what exactly a snd_soc_platform is. Apparently the snd_pcm_ops/pcm_new/pcm_free are specific to a platform. For my understanding these operations are more specific to a cpu_dai. Looking at the tree it seems that each cpu_dai has exactly one possible platform, which seems logical to me because the cpu_dai knows how to transfer the data.
They're for the DMA bit of the CPU. While most platforms have a single DMA controller (though some have more than one) it's moderately common to have more than one DAI (eg, dedicated I2S and DSP mode controllers rather than a programmable serial port, or an AC'97 controller) so it's useful to share the DMA code.
My problem on i.MX is that I currently have two possible cpu dais (imx-ssi.[01]) and each can be configured to use dma or fiq depending on the dma capabilities. So the cpu_dai knows which pcm_ops we have to use, but currently it's the soc glue code which has to decide in platform_name. Am I understanding something wrong here?
This is mostly a holdover from the existing (current mainline) ASoC structuring at the minute, that also has the DMA configured per machine. This may change depending on future hardware requirements, though.
On Tue, Aug 10, 2010 at 02:47:55PM +0100, Mark Brown wrote:
On Tue, Aug 10, 2010 at 03:38:18PM +0200, Sascha Hauer wrote:
I'm wondering what exactly a snd_soc_platform is. Apparently the snd_pcm_ops/pcm_new/pcm_free are specific to a platform. For my understanding these operations are more specific to a cpu_dai. Looking at the tree it seems that each cpu_dai has exactly one possible platform, which seems logical to me because the cpu_dai knows how to transfer the data.
They're for the DMA bit of the CPU. While most platforms have a single DMA controller (though some have more than one) it's moderately common to have more than one DAI (eg, dedicated I2S and DSP mode controllers rather than a programmable serial port, or an AC'97 controller) so it's useful to share the DMA code.
I didn't want to question that it's useful to share the code. It's just that in current i.MX implementation it would be simple to instantiate snd_pcm_ops (of fiq or dma type) in the platform_driver probe function passing all needed data like dma request line, fifo address and the like. Passing this data through the soc-core seems not very convenient.
My problem on i.MX is that I currently have two possible cpu dais (imx-ssi.[01]) and each can be configured to use dma or fiq depending on the dma capabilities. So the cpu_dai knows which pcm_ops we have to use, but currently it's the soc glue code which has to decide in platform_name. Am I understanding something wrong here?
This is mostly a holdover from the existing (current mainline) ASoC structuring at the minute, that also has the DMA configured per machine. This may change depending on future hardware requirements, though.
I would welcome such change.
/Me is looking further to make the i.MX part working on multi-component.
Sascha
On Tue, 2010-08-10 at 14:47 +0100, Mark Brown wrote:
On Tue, Aug 10, 2010 at 03:38:18PM +0200, Sascha Hauer wrote:
I'm wondering what exactly a snd_soc_platform is. Apparently the snd_pcm_ops/pcm_new/pcm_free are specific to a platform. For my understanding these operations are more specific to a cpu_dai. Looking at the tree it seems that each cpu_dai has exactly one possible platform, which seems logical to me because the cpu_dai knows how to transfer the data.
They're for the DMA bit of the CPU. While most platforms have a single DMA controller (though some have more than one) it's moderately common to have more than one DAI (eg, dedicated I2S and DSP mode controllers rather than a programmable serial port, or an AC'97 controller) so it's useful to share the DMA code.
My problem on i.MX is that I currently have two possible cpu dais (imx-ssi.[01]) and each can be configured to use dma or fiq depending on the dma capabilities. So the cpu_dai knows which pcm_ops we have to use, but currently it's the soc glue code which has to decide in platform_name. Am I understanding something wrong here?
This is mostly a holdover from the existing (current mainline) ASoC structuring at the minute, that also has the DMA configured per machine. This may change depending on future hardware requirements, though. _______________________________________________
With multi-component it's possible to register both FIQ and DMA platform together. i.e. ssi0 could use DMA and ssi1 FIQ.
So for OMAP4 I have two platforms. One is the SDMA driver and the other a DSP. So I could have the following DAI link :-
static struct snd_soc_dai_link sdp4430_dai[] = { .name = "TWL6040-SDMA", .stream_name = "TWL6040", .cpu_dai_name ="omap-mcpdm-dai", .codec_dai_name = "twl6040-hifi", .platform_name = "omap-pcm-audio", <<<< SDMA audio device .codec_name = "twl6040-codec", .init = sdp4430_twl6040_init, .ops = &sdp4430_ops, }, { .name = "TWL6040-DSP", .stream_name = "TWL6040", .cpu_dai_name ="omap-mcpdm-dai", .codec_dai_name = "twl6040-hifi", .platform_name = "omap-dsp-audio", <<< DSP audio device. .codec_name = "twl6040-codec", .init = sdp4430_twl6040_init, .ops = &sdp4430_ops, };
The snd_soc_dai_set_dma_data() can be used to pass DMA type data between the SSI ports and FIQ/SDMA components.
Liam
On Tue, Aug 10, 2010 at 03:16:09PM +0100, Liam Girdwood wrote:
On Tue, 2010-08-10 at 14:47 +0100, Mark Brown wrote:
This is mostly a holdover from the existing (current mainline) ASoC structuring at the minute, that also has the DMA configured per machine. This may change depending on future hardware requirements, though.
With multi-component it's possible to register both FIQ and DMA platform together. i.e. ssi0 could use DMA and ssi1 FIQ.
Yup, although I think for pretty much all hardware the decision about which DMA driver to use is going to be fixed by silicon consideratons (eg, in the i.MX case it'd be odd to want to use the FIQ driver when {S,}DMA support is available) so it probably does make sense for the DAIs to be able to provide at least a default DMA controller.
On Tue, 2010-08-10 at 15:42 +0100, Mark Brown wrote:
On Tue, Aug 10, 2010 at 03:16:09PM +0100, Liam Girdwood wrote:
On Tue, 2010-08-10 at 14:47 +0100, Mark Brown wrote:
This is mostly a holdover from the existing (current mainline) ASoC structuring at the minute, that also has the DMA configured per machine. This may change depending on future hardware requirements, though.
With multi-component it's possible to register both FIQ and DMA platform together. i.e. ssi0 could use DMA and ssi1 FIQ.
Yup, although I think for pretty much all hardware the decision about which DMA driver to use is going to be fixed by silicon consideratons (eg, in the i.MX case it'd be odd to want to use the FIQ driver when {S,}DMA support is available) so it probably does make sense for the DAIs to be able to provide at least a default DMA controller.
Yes, exactly - this was just an example showing two different DMA controllers.
Liam
On Tue, Aug 10, 2010 at 03:16:09PM +0100, Liam Girdwood wrote:
On Tue, 2010-08-10 at 14:47 +0100, Mark Brown wrote:
On Tue, Aug 10, 2010 at 03:38:18PM +0200, Sascha Hauer wrote:
I'm wondering what exactly a snd_soc_platform is. Apparently the snd_pcm_ops/pcm_new/pcm_free are specific to a platform. For my understanding these operations are more specific to a cpu_dai. Looking at the tree it seems that each cpu_dai has exactly one possible platform, which seems logical to me because the cpu_dai knows how to transfer the data.
They're for the DMA bit of the CPU. While most platforms have a single DMA controller (though some have more than one) it's moderately common to have more than one DAI (eg, dedicated I2S and DSP mode controllers rather than a programmable serial port, or an AC'97 controller) so it's useful to share the DMA code.
My problem on i.MX is that I currently have two possible cpu dais (imx-ssi.[01]) and each can be configured to use dma or fiq depending on the dma capabilities. So the cpu_dai knows which pcm_ops we have to use, but currently it's the soc glue code which has to decide in platform_name. Am I understanding something wrong here?
This is mostly a holdover from the existing (current mainline) ASoC structuring at the minute, that also has the DMA configured per machine. This may change depending on future hardware requirements, though. _______________________________________________
With multi-component it's possible to register both FIQ and DMA platform together. i.e. ssi0 could use DMA and ssi1 FIQ.
Whether we have to use FIQ depends on the codec connected (given that DMA is available, which is not yet the case). On the phyCORE board we have a wm9712 codec. This codec sends us data gpio status data in slot 12. The i.MX hardware is silly enough to put this data into the rx fifo, so the fiq handler has to sort out this data.
In the longer term we want to use DMA for everything, but first we have to extend the pcm-dma to sort aout this data aswell.
Sascha
participants (3)
-
Liam Girdwood -
Mark Brown -
Sascha Hauer