About the platform_name field in snd_soc_dai_link

About the platform_name field in snd_soc_dai_link

[Sascha Hauer]

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


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: About the platform_name field in snd_soc_dai_link

[Mark Brown]

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.

Re: About the platform_name field in snd_soc_dai_link

[Sascha Hauer]

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

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: About the platform_name field in snd_soc_dai_link

[Liam Girdwood]

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

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Re: About the platform_name field in snd_soc_dai_link

[Mark Brown]

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.

Re: About the platform_name field in snd_soc_dai_link

[Liam Girdwood]

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
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Re: About the platform_name field in snd_soc_dai_link

[Sascha Hauer]

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


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |