Cirrus Logic CS42L52 Low power codec

Cirrus Logic CS42L52 Low power codec

[Brian Austin]

Hello,

I have a codec I would like to submit.  The Cirrus Logic CS42L52 Low
Power codec.  I have the codec code as well as the machine code for the
Cirrus Logic EP9407A, but cannot submit that yet.  Is it OK to just
submit the codec code for now?  This does not use the new API, so a hint
as to which tree to make the diff from would help.

Thanks,

Brian Austin

Re: Cirrus Logic CS42L52 Low power codec

[Mark Brown]

On Mon, Feb 18, 2008 at 08:17:53AM -0600, Brian Austin wrote:

> I have a codec I would like to submit.  The Cirrus Logic CS42L52 Low
> Power codec.  I have the codec code as well as the machine code for the
> Cirrus Logic EP9407A, but cannot submit that yet.  Is it OK to just
> submit the codec code for now?  This does not use the new API, so a hint
> as to which tree to make the diff from would help.

Assuming that this is an ASoC codec driver please go ahead and submit
the codec by itself - there's no requirement for an in-tree machine
driver.  For ASoC v1 a patch against any of current alsa-driver hg,
Linus' current kernel or the dev branch of the ASoC repository at
git://opensource.wolfsonmicro.com/linux-2.6-asoc should be fine -
whichever you find most convenient.

Re: Cirrus Logic CS42L52 Low power codec

[Brian Austin]

I was under the impression that the ASoc v1 ties the codec to a specific
machine, and that v2 eliminates that need.  Is that a correct
assumption?


-----Original Message-----
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Brian Austin <brian.austin@cirrus.com>
Cc: alsa-devel@alsa-project.org <alsa-devel@alsa-project.org>
Subject: Re: [alsa-devel] Cirrus Logic CS42L52 Low power codec
Date: Mon, 18 Feb 2008 14:36:55 +0000

On Mon, Feb 18, 2008 at 08:17:53AM -0600, Brian Austin wrote:

> I have a codec I would like to submit.  The Cirrus Logic CS42L52 Low
> Power codec.  I have the codec code as well as the machine code for the
> Cirrus Logic EP9407A, but cannot submit that yet.  Is it OK to just
> submit the codec code for now?  This does not use the new API, so a hint
> as to which tree to make the diff from would help.

Assuming that this is an ASoC codec driver please go ahead and submit
the codec by itself - there's no requirement for an in-tree machine
driver.  For ASoC v1 a patch against any of current alsa-driver hg,
Linus' current kernel or the dev branch of the ASoC repository at
git://opensource.wolfsonmicro.com/linux-2.6-asoc should be fine -
whichever you find most convenient.

Re: Cirrus Logic CS42L52 Low power codec

[Timur Tabi]

Brian Austin wrote:
> I was under the impression that the ASoc v1 ties the codec to a specific
> machine, and that v2 eliminates that need.  Is that a correct
> assumption?

Not exactly.  The codec isn't technically tied to the machine with V1, but on 
some architecture (like PowerPC), it might be difficult to get configuration 
information to the codec driver without a cooperating machine driver.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Cirrus Logic CS42L52 Low power codec

[Mark Brown]

On Mon, Feb 18, 2008 at 08:45:49AM -0600, Brian Austin wrote:
> I was under the impression that the ASoc v1 ties the codec to a specific
> machine, and that v2 eliminates that need.  Is that a correct
> assumption?

No, codec drivers shouldn't be tied to a specific platform in either
version - the main new feature in v2 from the point of view of codec
support is that it allows a machine to have more than one codec at once,
but that's not a change that affects the codec driver.

Re: Cirrus Logic CS42L52 Low power codec

[Brian Austin]

On Mon, Feb 18, 2008 at 08:45:49AM -0600, Brian Austin wrote:
> I was under the impression that the ASoc v1 ties the codec to a specific
> machine, and that v2 eliminates that need.  Is that a correct
> assumption?

No, codec drivers shouldn't be tied to a specific platform in either
version - the main new feature in v2 from the point of view of codec
support is that it allows a machine to have more than one codec at once,
but that's not a change that affects the codec driver.

Since the codecs are not tied to the machine, the user must then add to the Kconfig of the 
ARCH to select which codec they want to use?

Using s3c2410_defconfig will only let you select the devices that are added in the Kconfig for the s3c24xx.

If the codec isn't tied to the machine, why can't we select from a list of supported codecs?
Just trying to get a better understanding of how this works.


Thanks,

Brian

Re: Cirrus Logic CS42L52 Low power codec

[Timur Tabi]

Brian Austin wrote:

> Since the codecs are not tied to the machine, the user must then add to the Kconfig of the 
> ARCH to select which codec they want to use?

Yes.  For most ASoC V1 platforms, the use selects a Kconfig for his platform, 
and *that* Kconfig selects the codec.  Example:

config SND_SOC_MPC8610_HPCD
         bool "ALSA SoC support for the Freescale MPC8610 HPCD board"
         depends on SND_SOC_MPC8610
         select SND_SOC_CS4270
	^^^^^^^^^^^^^^^^^^^^^

> If the codec isn't tied to the machine, why can't we select from a list of supported codecs?
> Just trying to get a better understanding of how this works.

The codec is not tied to the machine, but the machine is tied to the codec.

That is, in ASoC V1, the machine driver must know about the codec driver at 
compile time.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Cirrus Logic CS42L52 Low power codec

[Ben Dooks]

On Mon, Feb 18, 2008 at 10:34:33AM -0600, Brian Austin wrote:
> On Mon, Feb 18, 2008 at 08:45:49AM -0600, Brian Austin wrote:
> > I was under the impression that the ASoc v1 ties the codec to a specific
> > machine, and that v2 eliminates that need.  Is that a correct
> > assumption?
> 
> No, codec drivers shouldn't be tied to a specific platform in either
> version - the main new feature in v2 from the point of view of codec
> support is that it allows a machine to have more than one codec at once,
> but that's not a change that affects the codec driver.
> 
> Since the codecs are not tied to the machine, the user must then add to the Kconfig of the 
> ARCH to select which codec they want to use?
> 
> Using s3c2410_defconfig will only let you select the devices that are added in the Kconfig for the s3c24xx.

Yes, whilst the codecs are not locked to the machine, they do require
the machine<>codec bindings to be present, otherwise there is no setup
information about how the codec is connected, clock sources for the
codec and what devices are connected to the codec. Supplying that all
via the commandline would have an mass of extra complexity to the system.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

Re: Cirrus Logic CS42L52 Low power codec

[Mark Brown]

On Mon, Feb 18, 2008 at 10:34:33AM -0600, Brian Austin wrote:
[Reflowed to fit into 80 columns.]

> Since the codecs are not tied to the machine, the user must then add
> to the Kconfig of the ARCH to select which codec they want to use?

No - ASoC codec drivers shouldn't be directly visible in the kernel
configuration user interface.

> If the codec isn't tied to the machine, why can't we select from a
> list of supported codecs?  Just trying to get a better understanding
> of how this works.

The dependency is from machine to codec rather than from codec to
machine.  Using a codec in ASoC always requires explicit configuration
through a machine driver in order to specify how the codec is connected
to the rest of the system but the same codec driver can be used by many
machines.

Given that this is the embedded space and only a small proportion of the
machine drivers that get written ever get merged it's useful to have
codec drivers merged even if there are no currently merged machine
drivers which need them.  Having the codec driver merged makes it easier
for people to get the driver and if they do want to contribute their
machine driver then having the codec driver already there makes that
easier.

This pattern of merging codec drivers before machine support is fairly
common for reference platforms like you're talking about - often the
codec driver will be ready first.  For example, the recently merged
mpc8610_hpcd and DaVinci platforms both did this.

Re: Cirrus Logic CS42L52 Low power codec

[Brian Austin]

Makes sense.

So lets take a for-instance.
say I have 4 low power codecs and I want these codecs to be supported by
say NXP, SMDK24XX, FSL, and EP9X.  Then I would need to write the
machine code for each codec on each dev board?
Then allow the Kconfig to select what codecs I have for each machine.

correct?

In thinking ahead,  I can see how this will mean that in the future we
can have to option of several codecs per machine.  I guess that's the
deal with v2.   cool

so when I submit the CS42L52, I just need to .c and .h and a mod'ed
Kconfig for sound/soc/codecs.
fair enough

Thanks,

Brian



-----Original Message-----
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Brian Austin <brian.austin@cirrus.com>
Cc: alsa-devel@alsa-project.org <alsa-devel@alsa-project.org>
Subject: Re: [alsa-devel] Cirrus Logic CS42L52 Low power codec
Date: Mon, 18 Feb 2008 17:58:22 +0000

On Mon, Feb 18, 2008 at 10:34:33AM -0600, Brian Austin wrote:
[Reflowed to fit into 80 columns.]

> Since the codecs are not tied to the machine, the user must then add
> to the Kconfig of the ARCH to select which codec they want to use?

No - ASoC codec drivers shouldn't be directly visible in the kernel
configuration user interface.

> If the codec isn't tied to the machine, why can't we select from a
> list of supported codecs?  Just trying to get a better understanding
> of how this works.

The dependency is from machine to codec rather than from codec to
machine.  Using a codec in ASoC always requires explicit configuration
through a machine driver in order to specify how the codec is connected
to the rest of the system but the same codec driver can be used by many
machines.

Given that this is the embedded space and only a small proportion of the
machine drivers that get written ever get merged it's useful to have
codec drivers merged even if there are no currently merged machine
drivers which need them.  Having the codec driver merged makes it easier
for people to get the driver and if they do want to contribute their
machine driver then having the codec driver already there makes that
easier.

This pattern of merging codec drivers before machine support is fairly
common for reference platforms like you're talking about - often the
codec driver will be ready first.  For example, the recently merged
mpc8610_hpcd and DaVinci platforms both did this.

Re: Cirrus Logic CS42L52 Low power codec

[Mark Brown]

On Mon, Feb 18, 2008 at 12:07:40PM -0600, Brian Austin wrote:
> say I have 4 low power codecs and I want these codecs to be supported by
> say NXP, SMDK24XX, FSL, and EP9X.  Then I would need to write the
> machine code for each codec on each dev board?
> Then allow the Kconfig to select what codecs I have for each machine.

> correct?

Yes.

> In thinking ahead,  I can see how this will mean that in the future we
> can have to option of several codecs per machine.  I guess that's the
> deal with v2.   cool

The main thing with v2 from the point of view of codec discovery is that
it removes the requirement that v1 has that the codec driver be loaded
initialised the machine driver.  That creates problems if your system is
able to discover the control interface for the codec through some other
means like the PowerPC device trees.

You can have multiple runtime codec options per machine with v1, it just
has to be implemented in the machine driver and you end up having to
compile in all the codec drivers you might need all the time.

> so when I submit the CS42L52, I just need to .c and .h and a mod'ed
> Kconfig for sound/soc/codecs.
> fair enough

Yes, exactly.