asoc multi-component: almost there!

asoc multi-component: almost there!

[Timur Tabi]

Liam,

I almost got it working.  I can generate names that match, so it finds it:

soc_bind_dai_link:1136 cpu_dai->name=e0016000.ssi,
dai_link->cpu_dai_name=e0016000.ssi
soc_bind_dai_link:1159 codec->name=cs4270-codec.0-004f,
dai_link->codec_name=cs4270-codec.0-004f
soc_bind_dai_link:1169 codec_dai->name=e0016000.ssi,
dai_link->codec_dai_name=cs4270-hifi
soc_bind_dai_link:1169 codec_dai->name=cs4270-hifi,
dai_link->codec_dai_name=cs4270-hifi
soc_bind_dai_link:1194 platform->name=e0021180.dma-channel,
dai_link->platform_name=e0021100.dma-channel
soc_bind_dai_link:1194 platform->name=e0021100.dma-channel,
dai_link->platform_name=e0021100.dma-channel
soc_bind_dai_link:1136 cpu_dai->name=e0016000.ssi,
dai_link->cpu_dai_name=e0016000.ssi
soc_bind_dai_link:1159 codec->name=cs4270-codec.0-004f,
dai_link->codec_name=cs4270-codec.0-004f
soc_bind_dai_link:1169 codec_dai->name=e0016000.ssi,
dai_link->codec_dai_name=cs4270-hifi
soc_bind_dai_link:1169 codec_dai->name=cs4270-hifi,
dai_link->codec_dai_name=cs4270-hifi
soc_bind_dai_link:1194 platform->name=e0021180.dma-channel,
dai_link->platform_name=e0021180.dma-channel
asoc: cs4270-hifi <-> e0016000.ssi mapping ok

but then I get this:

sysfs: cannot create duplicate filename '/devices/platform/soc-audio/cs4270'

I'm registering two DAIs -- one for playback, one for capture, but I'm
using the same name for the codec DAI.  How do I resolve this?

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: asoc multi-component: almost there!

[Liam Girdwood]

On Mon, 2010-07-26 at 17:37 -0500, Timur Tabi wrote:
> Liam,
> 
> I almost got it working.  I can generate names that match, so it finds it:
> 
> soc_bind_dai_link:1136 cpu_dai->name=e0016000.ssi,
> dai_link->cpu_dai_name=e0016000.ssi
> soc_bind_dai_link:1159 codec->name=cs4270-codec.0-004f,
> dai_link->codec_name=cs4270-codec.0-004f
> soc_bind_dai_link:1169 codec_dai->name=e0016000.ssi,
> dai_link->codec_dai_name=cs4270-hifi
> soc_bind_dai_link:1169 codec_dai->name=cs4270-hifi,
> dai_link->codec_dai_name=cs4270-hifi
> soc_bind_dai_link:1194 platform->name=e0021180.dma-channel,
> dai_link->platform_name=e0021100.dma-channel
> soc_bind_dai_link:1194 platform->name=e0021100.dma-channel,
> dai_link->platform_name=e0021100.dma-channel
> soc_bind_dai_link:1136 cpu_dai->name=e0016000.ssi,
> dai_link->cpu_dai_name=e0016000.ssi
> soc_bind_dai_link:1159 codec->name=cs4270-codec.0-004f,
> dai_link->codec_name=cs4270-codec.0-004f
> soc_bind_dai_link:1169 codec_dai->name=e0016000.ssi,
> dai_link->codec_dai_name=cs4270-hifi
> soc_bind_dai_link:1169 codec_dai->name=cs4270-hifi,
> dai_link->codec_dai_name=cs4270-hifi
> soc_bind_dai_link:1194 platform->name=e0021180.dma-channel,
> dai_link->platform_name=e0021180.dma-channel
> asoc: cs4270-hifi <-> e0016000.ssi mapping ok
> 
> but then I get this:
> 
> sysfs: cannot create duplicate filename '/devices/platform/soc-audio/cs4270'
> 
> I'm registering two DAIs -- one for playback, one for capture, but I'm
> using the same name for the codec DAI.  How do I resolve this?

You don't need to register two CODEC DAIs here. One will do, since we
only have the one CODEC.

Thanks

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

Re: asoc multi-component: almost there!

[Timur Tabi]

On Tue, Jul 27, 2010 at 5:42 AM, Liam Girdwood <lrg@slimlogic.co.uk> wrote:

> You don't need to register two CODEC DAIs here. One will do, since we
> only have the one CODEC.

I don't see how I can avoid it.  I register one DAI for playback, and
another for capture.  In the past, multi-component was able to handle
this.  It's only with the most recent change that it's broken.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: asoc multi-component: almost there!

[Liam Girdwood]

On Mon, 2010-07-26 at 17:37 -0500, Timur Tabi wrote:
> Liam,
> 
> I almost got it working.  I can generate names that match, so it finds it:
> 
> soc_bind_dai_link:1136 cpu_dai->name=e0016000.ssi,
> dai_link->cpu_dai_name=e0016000.ssi
> soc_bind_dai_link:1159 codec->name=cs4270-codec.0-004f,
> dai_link->codec_name=cs4270-codec.0-004f
> soc_bind_dai_link:1169 codec_dai->name=e0016000.ssi,
> dai_link->codec_dai_name=cs4270-hifi
> soc_bind_dai_link:1169 codec_dai->name=cs4270-hifi,
> dai_link->codec_dai_name=cs4270-hifi
> soc_bind_dai_link:1194 platform->name=e0021180.dma-channel,
> dai_link->platform_name=e0021100.dma-channel
> soc_bind_dai_link:1194 platform->name=e0021100.dma-channel,
> dai_link->platform_name=e0021100.dma-channel
> soc_bind_dai_link:1136 cpu_dai->name=e0016000.ssi,
> dai_link->cpu_dai_name=e0016000.ssi
> soc_bind_dai_link:1159 codec->name=cs4270-codec.0-004f,
> dai_link->codec_name=cs4270-codec.0-004f
> soc_bind_dai_link:1169 codec_dai->name=e0016000.ssi,
> dai_link->codec_dai_name=cs4270-hifi
> soc_bind_dai_link:1169 codec_dai->name=cs4270-hifi,
> dai_link->codec_dai_name=cs4270-hifi
> soc_bind_dai_link:1194 platform->name=e0021180.dma-channel,
> dai_link->platform_name=e0021180.dma-channel
> asoc: cs4270-hifi <-> e0016000.ssi mapping ok
> 
> but then I get this:
> 
> sysfs: cannot create duplicate filename '/devices/platform/soc-audio/cs4270'
> 
> I'm registering two DAIs -- one for playback, one for capture, but I'm
> using the same name for the codec DAI.  How do I resolve this?
> 

Ah ok, I thought you meant two CODEC DAIs earlier rather than two
machine DAI links. 

Each machine DAI link now has a sysfs entry so we can inspect its
configuration/status now. Hence each machine DAI link must be named
differently. You could have a "cs4270 playback" and "cs4270 capture" DAI
links now.

Thanks

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

Re: asoc multi-component: almost there!

[Timur Tabi]

On Tue, Jul 27, 2010 at 8:49 AM, Liam Girdwood <lrg@slimlogic.co.uk> wrote:

> Each machine DAI link now has a sysfs entry so we can inspect its
> configuration/status now.

I have a suspicion that this will totally break my code.

> Hence each machine DAI link must be named
> differently. You could have a "cs4270 playback" and "cs4270 capture" DAI
> links now.

That won't work either.  For one thing, the CS4270 driver registers
only one DAI, and it's called "cs4270-hifi".  So I have to call it
"cs4270-hifi".  So I can't call it anything else.

ASoC should detect when the machine driver is registering a connection
between a CPU object and a codec, if the codec's DAI has already been
given a sysfs entry.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: asoc multi-component: almost there!

[Liam Girdwood]

On Tue, 2010-07-27 at 10:20 -0500, Timur Tabi wrote:
> On Tue, Jul 27, 2010 at 8:49 AM, Liam Girdwood <lrg@slimlogic.co.uk> wrote:
> 
> > Each machine DAI link now has a sysfs entry so we can inspect its
> > configuration/status now.
> 
> I have a suspicion that this will totally break my code.

I think you are probably a special case here since you are the only
person who is dynamically building a DAI link array atm. Everyone else
has a static table. To further complicate matters, you are having to
read from a device tree that has not been optimised for creating ASoC
DAI link tables (hence the meeting at UDS this year to come up with some
device tree ASoC format).

Fwiw, I've just again tested another multiple DAI mapping to single
CODEC DAI :-

 	{
		.name = "DAI test1",
		.stream_name = "Multimedia",

		.cpu_dai_name = "omap-mcbsp-dai.1",
		.platform_name = "omap-pcm-audio",

		.codec_dai_name =  "twl6040-dl1",
		.codec_name = "twl6040-codec",
	},
	{
		.name = "DAI test2",
		.stream_name = "Multimedia",

		.cpu_dai_name = "omap-mcbsp-dai.3",
		.platform_name = "omap-pcm-audio",

		.codec_dai_name =  "twl6040-dl1",
		.codec_name = "twl6040-codec",
	}


Works fine for me.

> 
> > Hence each machine DAI link must be named
> > differently. You could have a "cs4270 playback" and "cs4270 capture" DAI
> > links now.
> 
> That won't work either.  For one thing, the CS4270 driver registers
> only one DAI, and it's called "cs4270-hifi".  So I have to call it
> "cs4270-hifi".  So I can't call it anything else.

I was meaning the DAI _link_ name (above as "DAI test1" and "DAI test
2") and not the CODEC DAI name ("twl6040-dl1" above).

I think you should be creating two DAI links like this:-

	{
		.name = "cs4270-playback",
		.stream_name = "Playback",

		.cpu_dai_name = "fsl-ssi-blah.0",
		.platform_name = "fsl-blah-pcm-audio",

		.codec_dai_name =  "cs4270-hifi",
		.codec_name = "cs4270-codec-addr",
	},
	{
		.name = "cs4270-capture",
		.stream_name = "Capture",

		.cpu_dai_name = "fsl-ssi-blah.1",
		.platform_name = "fsl-blah-pcm-audio",

		.codec_dai_name =  "cs4270-hifi",
		.codec_name = "cs4270-codec-addr",
	},

The only differences between both DAI links is the name, stream_name and
cpu_dai_name (iirc your DMA has to be different too?)

Thanks

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

Re: asoc multi-component: almost there!

[Timur Tabi]

On Tue, Jul 27, 2010 at 12:26 PM, Liam Girdwood <lrg@slimlogic.co.uk> wrote:

> I think you are probably a special case here since you are the only
> person who is dynamically building a DAI link array atm. Everyone else
> has a static table.

I thought the whole point behind this "multi-component" stuff was to
eliminate the need for static tables!

> To further complicate matters, you are having to
> read from a device tree that has not been optimised for creating ASoC
> DAI link tables (hence the meeting at UDS this year to come up with some
> device tree ASoC format).

I don't think that's a factor.  The outcome of that meeting is to
determine how a device tree should represent the relationship between
the SSI, DMA, and codec nodes.  I already have a definition for that,
and the machine driver uses it, but other people apparently don't like
it.  However, the only thing that will change is the specific code I
use to traverse the device tree in the machine driver.  I will still
have the same problems I'm having now.

> Fwiw, I've just again tested another multiple DAI mapping to single
> CODEC DAI :-
>
>        {
>                .name = "DAI test1",
>                .stream_name = "Multimedia",
>
>                .cpu_dai_name = "omap-mcbsp-dai.1",
>                .platform_name = "omap-pcm-audio",
>
>                .codec_dai_name =  "twl6040-dl1",
>                .codec_name = "twl6040-codec",
>        },
>        {
>                .name = "DAI test2",
>                .stream_name = "Multimedia",
>
>                .cpu_dai_name = "omap-mcbsp-dai.3",
>                .platform_name = "omap-pcm-audio",
>
>                .codec_dai_name =  "twl6040-dl1",
>                .codec_name = "twl6040-codec",
>        }
>
>
> Works fine for me.

Look at cs4270.c.  The chip has only one digital interface, so I have
a single DAI structure.  Are you telling me that I need to have two
DAIs in the CS4270 driver?  Won't that break something else?

> I was meaning the DAI _link_ name (above as "DAI test1" and "DAI test
> 2") and not the CODEC DAI name ("twl6040-dl1" above).
>
> I think you should be creating two DAI links like this:-

Ugh.  So you're saying that ASOC no longer supports having two CPU
DAIs connect to the same codec DAI?

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: asoc multi-component: almost there!

[Mark Brown]

On Tue, Jul 27, 2010 at 01:20:58PM -0500, Timur Tabi wrote:
> On Tue, Jul 27, 2010 at 12:26 PM, Liam Girdwood <lrg@slimlogic.co.uk> wrote:

> > I think you are probably a special case here since you are the only
> > person who is dynamically building a DAI link array atm. Everyone else
> > has a static table.

> I thought the whole point behind this "multi-component" stuff was to
> eliminate the need for static tables!

For most systems the major win is that we can have more than one CODEC
(or other register based device) in a single system.  Static tables
really aren't a problem for anyone else, at the end of the day you have
a static table somewhere for the board - it's just that with your device
tree usage you've put that data into the device tree.

The change in the particular static data to provide a layer of
indirection from the actual DAI/CODEC structures is a win for other
people because it helps probe multiple instances of the same CODEC, but
there's still some static data.

> Look at cs4270.c.  The chip has only one digital interface, so I have
> a single DAI structure.  Are you telling me that I need to have two
> DAIs in the CS4270 driver?  Won't that break something else?

Yeah, I think if we can't have the same audio interface in more than one
DAI link we probably have a problem with multi-drop links and with
independant wiring of TX and RX directions.

Re: asoc multi-component: almost there!

[Timur Tabi]

Is the machine driver required to run last?  The reason I ask is that
my DMA driver is currently initialized via arch_initcall().  If I
change that to module_init(), ASOC fails to register any sound cards.

Here's the debug output with arch_initcall():

soc_bind_dai_link:1136 cpu_dai->name=e0016000.ssi,
dai_link->cpu_dai_name=e0016000.ssi
soc_bind_dai_link:1159 codec->name=cs4270-codec.0-004f,
dai_link->codec_name=cs4270-codec.0-004f
soc_bind_dai_link:1169 codec_dai->name=e0016000.ssi,
dai_link->codec_dai_name=cs4270-hifi
soc_bind_dai_link:1169 codec_dai->name=cs4270-hifi,
dai_link->codec_dai_name=cs4270-hifi
soc_bind_dai_link:1194 platform->name=e0021180.dma-channel,
dai_link->platform_name=e0021100.dma-channel
soc_bind_dai_link:1194 platform->name=e0021100.dma-channel,
dai_link->platform_name=e0021100.dma-channel
soc_bind_dai_link:1136 cpu_dai->name=e0016000.ssi,
dai_link->cpu_dai_name=e0016000.ssi
soc_bind_dai_link:1159 codec->name=cs4270-codec.0-004f,
dai_link->codec_name=cs4270-codec.0-004f
soc_bind_dai_link:1169 codec_dai->name=e0016000.ssi,
dai_link->codec_dai_name=cs4270-hifi
soc_bind_dai_link:1169 codec_dai->name=cs4270-hifi,
dai_link->codec_dai_name=cs4270-hifi
soc_bind_dai_link:1194 platform->name=e0021180.dma-channel,
dai_link->platform_name=e0021180.dma-channel
asoc: cs4270-hifi <-> e0016000.ssi mapping ok
asoc: cs4270-hifi <-> e0016000.ssi mapping ok
mpc8610_hpcd_probe:516
ALSA device list:
  #0: MPC8610 HPCD

And here it is with module_init():

soc_bind_dai_link:1136 cpu_dai->name=e0016000.ssi,
dai_link->cpu_dai_name=e0016000.ssi
soc_bind_dai_link:1159 codec->name=cs4270-codec.0-004f,
dai_link->codec_name=cs4270-codec.0-004f
soc_bind_dai_link:1169 codec_dai->name=e0016000.ssi,
dai_link->codec_dai_name=cs4270-hifi
soc_bind_dai_link:1169 codec_dai->name=cs4270-hifi,
dai_link->codec_dai_name=cs4270-hifi
soc_bind_dai_link:1136 cpu_dai->name=e0016000.ssi,
dai_link->cpu_dai_name=e0016000.ssi
soc_bind_dai_link:1159 codec->name=cs4270-codec.0-004f,
dai_link->codec_name=cs4270-codec.0-004f
soc_bind_dai_link:1169 codec_dai->name=e0016000.ssi,
dai_link->codec_dai_name=cs4270-hifi
soc_bind_dai_link:1169 codec_dai->name=cs4270-hifi,
dai_link->codec_dai_name=cs4270-hifi
mpc8610_hpcd_probe:516
Freescale Elo DMA ASoC PCM Driver
fsl_soc_dma_probe:852
soc_bind_dai_link:1194 platform->name=e0021100.dma-channel,
dai_link->platform_name=e0021100.dma-channel
soc_bind_dai_link:1194 platform->name=e0021100.dma-channel,
dai_link->platform_name=e0021180.dma-channel
fsl_soc_dma_probe:852
soc_bind_dai_link:1194 platform->name=e0021180.dma-channel,
dai_link->platform_name=e0021180.dma-channel
ALSA device list:
  No soundcards found.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: asoc multi-component: almost there!

[Liam Girdwood]

On Tue, 2010-07-27 at 16:23 -0500, Timur Tabi wrote:
> Is the machine driver required to run last?  The reason I ask is that
> my DMA driver is currently initialized via arch_initcall().  If I
> change that to module_init(), ASOC fails to register any sound cards.

Oh, that one is my fault. I had tried to optimize part of the probe() a
little and have reverted that change now.

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

Re: asoc multi-component: almost there!

[Timur Tabi]

Liam Girdwood wrote:
> Oh, that one is my fault. I had tried to optimize part of the probe() a
> little and have reverted that change now.

Ok, it works now.  Thanks.