ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver

ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver

[David Jander]

On Fri, 9 Sep 2011 08:28:44 +0200
David Jander <david.jander@protonic.nl> wrote:

>[...]
> > i am also interested in a proper fabric example.
> 
> What do you think about creating device-tree bindings for that? I tend to
> like the idea of not needing any special board support code besides the DT,
> and the audio fabric driver part is the only obstacle for that.

Ok, I actually spent a while thinking about this. What about the following
idea:

Given the following devicetree:

		...
		// PSC11 in ac97 mode
		ac97@11b00 {
/* 1 */			compatible = "fsl,mpc5121-psc-ac97", "fsl,mpc5121-psc", "alsa,cpu-dai";
			cell-index = <11>;
			reg = <0x11b00 0x100>;
			interrupts = <40 0x8>;
			fsl,mode = "ac97-slave";
			fsl,rx-fifo-size = <384>;
			fsl,tx-fifo-size = <384>;
			#address-cells = <1>;
			#size-cells = <0>;
/* 2 */			codec0: psc-ac97-analog@0 {
/* 3 */				compatible = "national,lm4550", "ac97-codec";
/* 4 */				alsa,codec-dai-name = "ac97-hifi";
			};
		};

Consider the following pseudo-code in sound/soc/soc-of.c:

static struct snd_soc_card card;
static struct snd_soc_dai_link *of_dai;

static __init int of_fabric_init(void)
{
	of_for_each_compatible_node("alsa,cpu-dai") do {
		count++;
	}

	of_dai = kzalloc(count * (sizeof struct snd_soc_dai_link));

	of_for_each_compatible_node("alsa,cpu-dai") as parent do {
		of_for_each_child(parent) as node {
			of_dai[i].name = of_get_name(parent);  /* "ac97" */
			of_dai[i].stream_name = of_fabric_dai[i].name + str(i);
			of_dai[i].cpu_dai_name = of_get_name(node); /* "psc-ac97-analog" */
			of_dai[i].codec_dai_name = of_get_property(node, "alsa,codec_dai_name");
/* 5 */			of_dai[i].codec_name = match_of_compatible_with_registered_codec_list(node);
			of_dai[i].platform_name = of_soc_name + "-pcm-audio";
			i++;
		}
	}

	card.name = "of-audio";
	card.dai_link = of_dai;
	card.num_links = i;

	pdev = platform_device_alloc("soc-audio", 1);
	platform_set_drvdata(pdev, &card);
	platform_device_add(pdev);
}

Notes in the pseudo-source above:

1: By adding compatible = "alsa,cpu-dai", this DAI is marked for binding.

2: Child nodes list all CPU DAI's and their conected codecs. Child node name
is name of the CPU DAI.

3: Many ac97 codecs are compatible with the generic codec driver "ac97-codec".

4: Don't know if this is the right way to work the codec DAI name in. See the
next note:

5: The pseudo-function match_of_compatible_with_registered_codec_list() will
search through the list of registered ALSA codecs and match the compatible
strings of this codec with one in the list. If one is found, the name is used
for of_dai[i].codec_name, otherwise the current node is discarded (no matching
codec driver registered). Maybe the corresponding "codec-dai-name" can be
extracted from the codec database? That would eliminate line /* 4 */.

Unfortunately, this way we will probably need to get back the Kconfig option
to choose which codecs should be built. Apparently this option existed before,
but was removed.

All comments are welcome.

Best regards,

-- 
David Jander
Protonic Holland.

Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver

[Mark Brown]

On Fri, Sep 09, 2011 at 12:02:16PM +0200, David Jander wrote:

> Ok, I actually spent a while thinking about this. What about the following
> idea:

*Always* CC maintainers.

> 1: By adding compatible = "alsa,cpu-dai", this DAI is marked for binding.

This isn't really something that should go into device tree, ALSA is a
Linux specific concept.

> 3: Many ac97 codecs are compatible with the generic codec driver "ac97-codec".

All should be.  The only reason for specific drivers is to enable
additional non-standard functionality.

> 4: Don't know if this is the right way to work the codec DAI name in. See the
> next note:

What we should really be doing here is to autodiscover by reading the ID
registers in the device.  That needs generic AC'97 bus work which we
don't have right now.

Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver

[David Jander]

On Fri, 9 Sep 2011 17:37:14 +0100
Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> On Fri, Sep 09, 2011 at 12:02:16PM +0200, David Jander wrote:
> 
> > Ok, I actually spent a while thinking about this. What about the following
> > idea:
> 
> *Always* CC maintainers.

Sorry ;-)

> > 1: By adding compatible = "alsa,cpu-dai", this DAI is marked for binding.
> 
> This isn't really something that should go into device tree, ALSA is a
> Linux specific concept.

There are many Linux-specific details in Linux's implementation of Open
Firmware Device Trees. Right now, thanks to Linux, Open-Firmware device trees
are used for much more hardware platforms than just Oracle hardware that
probably isn't manufactured anymore and IBM Power servers. For embedded
systems for example, DT's have been used on all PowerPC platforms and is being
introduced in arch/arm right now. On all these platforms, its sole existence
is purely for running Linux with minimal board support code in the kernel.
So, why not add a few more Linux-specific bits to it, if it helps get rid of
the last bit of board-specific code?
The platforms that will use those bindings, will never have
Open-Firmware bioses in the first place, and their DT sources will be part of
the kernel source tree anyway.

> > 3: Many ac97 codecs are compatible with the generic codec driver
> > "ac97-codec".
> 
> All should be.  The only reason for specific drivers is to enable
> additional non-standard functionality.

I was being careful.

> > 4: Don't know if this is the right way to work the codec DAI name in. See
> > the next note:
> 
> What we should really be doing here is to autodiscover by reading the ID
> registers in the device.  That needs generic AC'97 bus work which we
> don't have right now.

Seems reasonable, but is correct autodiscovery really possible for all
configurations and all DAI-codec combinations?

Best regards,

-- 
David Jander
Protonic Holland.

Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver

[Mark Brown]

On Mon, Sep 12, 2011 at 08:31:58AM +0200, David Jander wrote:
> Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> > This isn't really something that should go into device tree, ALSA is a
> > Linux specific concept.

> There are many Linux-specific details in Linux's implementation of Open
> Firmware Device Trees. Right now, thanks to Linux, Open-Firmware device trees

This is generally considered a bug in the bindings, the bindings are for
cross-platform usage and should not be specific to any OS.

> introduced in arch/arm right now. On all these platforms, its sole existence
> is purely for running Linux with minimal board support code in the kernel.

Other OSs are actively using device tree.

> So, why not add a few more Linux-specific bits to it, if it helps get rid of
> the last bit of board-specific code?

Eliminating board specific code for audio is not a realistic goal, the
configuration of modern audio subsystems is too complex and dynamic.  It
is realistic to make machine drivers which cover broad classes of
devices with similar hardware.

> The platforms that will use those bindings, will never have
> Open-Firmware bioses in the first place, and their DT sources will be part of
> the kernel source tree anyway.

The plan is to push the device trees out of the kernel into a separate
repository.

> > What we should really be doing here is to autodiscover by reading the ID
> > registers in the device.  That needs generic AC'97 bus work which we
> > don't have right now.

> Seems reasonable, but is correct autodiscovery really possible for all
> configurations and all DAI-codec combinations?

Yes, it's a very basic part of AC'97.

Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver

[David Jander]

On Mon, 12 Sep 2011 12:09:50 +0100
Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> On Mon, Sep 12, 2011 at 08:31:58AM +0200, David Jander wrote:
> > Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> 
> > > This isn't really something that should go into device tree, ALSA is a
> > > Linux specific concept.
> 
> > There are many Linux-specific details in Linux's implementation of Open
> > Firmware Device Trees. Right now, thanks to Linux, Open-Firmware device
> > trees
> 
> This is generally considered a bug in the bindings, the bindings are for
> cross-platform usage and should not be specific to any OS.

Ok. I get your point.

> > introduced in arch/arm right now. On all these platforms, its sole
> > existence is purely for running Linux with minimal board support code in
> > the kernel.
> 
> Other OSs are actively using device tree.

Interesting. I wasn't aware of "actively using". Sure, there's MacOS-X-ppc,
IBM AIX, Oracle Solaris.... and I just discovered that Free-/OpenBSD also use
them.

> > So, why not add a few more Linux-specific bits to it, if it helps get rid
> > of the last bit of board-specific code?
> 
> Eliminating board specific code for audio is not a realistic goal, the
> configuration of modern audio subsystems is too complex and dynamic.  

Why not? How complex could it be in order to not be able to describe it in a
Device-Tree in some OS-agnostic way?

> It
> is realistic to make machine drivers which cover broad classes of
> devices with similar hardware.

Ok. That was my original plan... it just occurred to me that describing the
audio fabric in OF-DT would be a better idea :-(

> > The platforms that will use those bindings, will never have
> > Open-Firmware bioses in the first place, and their DT sources will be part
> > of the kernel source tree anyway.
> 
> The plan is to push the device trees out of the kernel into a separate
> repository.

Good idea.... but where should such a repository be hosted?

> > > What we should really be doing here is to autodiscover by reading the ID
> > > registers in the device.  That needs generic AC'97 bus work which we
> > > don't have right now.
> 
> > Seems reasonable, but is correct autodiscovery really possible for all
> > configurations and all DAI-codec combinations?
> 
> Yes, it's a very basic part of AC'97.

Thanks for pointing out. I suspected that already, but since everyone seems to
just go ahead and write his own piece of fabric-code, I started wondering
about the reason. I wouldn't consider a second about just blindfolded
duplicating what several others already did before me without seriously
thinking about a universal "fits almost all" solution instead. And I still
refuse to just copy-cat audio fabric code for our board!

Best regards,

-- 
David Jander
Protonic Holland.

Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver

[Mark Brown]

On Mon, Sep 12, 2011 at 02:55:07PM +0200, David Jander wrote:
> Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> > Other OSs are actively using device tree.

> Interesting. I wasn't aware of "actively using". Sure, there's MacOS-X-ppc,
> IBM AIX, Oracle Solaris.... and I just discovered that Free-/OpenBSD also use
> them.

*BSD are the main ones to consider here.

> > Eliminating board specific code for audio is not a realistic goal, the
> > configuration of modern audio subsystems is too complex and dynamic.  

> Why not? How complex could it be in order to not be able to describe it in a
> Device-Tree in some OS-agnostic way?

Note the "dynamic" bit - the configuration changes at runtime.
Describing the hardware for something like a modern smartphone isn't
particularly useful due to the flexibility, there are too many different
ways of configuring the system and we need code to acutally take those
decision.

> > The plan is to push the device trees out of the kernel into a separate
> > repository.

> Good idea.... but where should such a repository be hosted?

Still an open issue.

Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver

[David Jander]

On Mon, 12 Sep 2011 14:19:24 +0100
Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> On Mon, Sep 12, 2011 at 02:55:07PM +0200, David Jander wrote:
> > Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> 
> > > Other OSs are actively using device tree.
> 
> > Interesting. I wasn't aware of "actively using". Sure, there's MacOS-X-ppc,
> > IBM AIX, Oracle Solaris.... and I just discovered that Free-/OpenBSD also
> > use them.
> 
> *BSD are the main ones to consider here.
> 
> > > Eliminating board specific code for audio is not a realistic goal, the
> > > configuration of modern audio subsystems is too complex and dynamic.  
> 
> > Why not? How complex could it be in order to not be able to describe it in
> > a Device-Tree in some OS-agnostic way?
> 
> Note the "dynamic" bit - the configuration changes at runtime.
> Describing the hardware for something like a modern smartphone isn't
> particularly useful due to the flexibility, there are too many different
> ways of configuring the system and we need code to acutally take those
> decision.

Ok, but you could still describe the hardwired part of it (Audio muxes,
codecs, busses and physical interfaces). Isn't that what OF is all about?
In our case, its just a simple AC97 codec connected to a simple AC97 bus.
Sounds like total overkill having to write a "fabric driver" for this....
while there are already quite a few that are all 99% the same!

> > > The plan is to push the device trees out of the kernel into a separate
> > > repository.
> 
> > Good idea.... but where should such a repository be hosted?
> 
> Still an open issue.

Seems like its hard to find a vendor- and OS-neutral entity to host this?
OpenBIOS maybe?

Best regards,

-- 
David Jander
Protonic Holland.

Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver

[Mark Brown]

On Mon, Sep 12, 2011 at 03:59:05PM +0200, David Jander wrote:
> Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> > Note the "dynamic" bit - the configuration changes at runtime.
> > Describing the hardware for something like a modern smartphone isn't
> > particularly useful due to the flexibility, there are too many different
> > ways of configuring the system and we need code to acutally take those
> > decision.

> Ok, but you could still describe the hardwired part of it (Audio muxes,
> codecs, busses and physical interfaces). Isn't that what OF is all about?
> In our case, its just a simple AC97 codec connected to a simple AC97 bus.
> Sounds like total overkill having to write a "fabric driver" for this....
> while there are already quite a few that are all 99% the same!

I'm not sure I understand what you are talking about.  As I've already
said at least once having a *machine* driver which covers multiple
machines is absolutely OK.  We already have several such drivers in
kernel.

*Please* look at the existing code and read what I'm saying, and ideally
also read the prior discussions on this topic.  Please also try to avoid
inventing your own techncial terms.  It's enormously repetitive and not
terribly useful to have to go through all this stuff from square one
every single time someone looks at this stuff.

> > > > The plan is to push the device trees out of the kernel into a separate
> > > > repository.

> > > Good idea.... but where should such a repository be hosted?

> > Still an open issue.

> Seems like its hard to find a vendor- and OS-neutral entity to host this?
> OpenBIOS maybe?

More a problem of deciding which of the many available options to
choose.

Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver

[Grant Likely]

On Mon, Sep 12, 2011 at 03:52:14PM +0100, Mark Brown wrote:
> On Mon, Sep 12, 2011 at 03:59:05PM +0200, David Jander wrote:
> > Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> 
> > > Note the "dynamic" bit - the configuration changes at runtime.
> > > Describing the hardware for something like a modern smartphone isn't
> > > particularly useful due to the flexibility, there are too many different
> > > ways of configuring the system and we need code to acutally take those
> > > decision.
> 
> > Ok, but you could still describe the hardwired part of it (Audio muxes,
> > codecs, busses and physical interfaces). Isn't that what OF is all about?
> > In our case, its just a simple AC97 codec connected to a simple AC97 bus.
> > Sounds like total overkill having to write a "fabric driver" for this....
> > while there are already quite a few that are all 99% the same!
> 
> I'm not sure I understand what you are talking about.  As I've already
> said at least once having a *machine* driver which covers multiple
> machines is absolutely OK.  We already have several such drivers in
> kernel.

Yes, a machine driver is quite a sane way to manage the huge range of
variability of a machine's audio complex.  If it turns out that an SoC
only ever has one machine driver that handles all possible
configurations, it still isn't really more complex.  If, however, the
permutations are sufficiently different to warrant separate driver
then the groundwork is already established to support it sanely.

BTW, this isn't a question about "what OF is all about".  It makes
perfect sense in the OF context to have a node describing how multiple
devices are aggregated into a single logically composite device.

Do a machine driver.  It's the right thing to do.

g.

Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver

[David Jander]

On Mon, 12 Sep 2011 13:48:50 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:

> On Mon, Sep 12, 2011 at 03:52:14PM +0100, Mark Brown wrote:
> > On Mon, Sep 12, 2011 at 03:59:05PM +0200, David Jander wrote:
> > > Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> > 
> > > > Note the "dynamic" bit - the configuration changes at runtime.
> > > > Describing the hardware for something like a modern smartphone isn't
> > > > particularly useful due to the flexibility, there are too many
> > > > different ways of configuring the system and we need code to acutally
> > > > take those decision.
> > 
> > > Ok, but you could still describe the hardwired part of it (Audio muxes,
> > > codecs, busses and physical interfaces). Isn't that what OF is all about?
> > > In our case, its just a simple AC97 codec connected to a simple AC97 bus.
> > > Sounds like total overkill having to write a "fabric driver" for this....
> > > while there are already quite a few that are all 99% the same!
> > 
> > I'm not sure I understand what you are talking about.  As I've already
> > said at least once having a *machine* driver which covers multiple
> > machines is absolutely OK.  We already have several such drivers in
> > kernel.
> 
> Yes, a machine driver is quite a sane way to manage the huge range of
> variability of a machine's audio complex.  If it turns out that an SoC
> only ever has one machine driver that handles all possible
> configurations, it still isn't really more complex.  If, however, the
> permutations are sufficiently different to warrant separate driver
> then the groundwork is already established to support it sanely.
> 
> BTW, this isn't a question about "what OF is all about".  It makes
> perfect sense in the OF context to have a node describing how multiple
> devices are aggregated into a single logically composite device.
> 
> Do a machine driver.  It's the right thing to do.

Ok, thanks.

Best regards,

-- 
David Jander
Protonic Holland.