[alsa-devel] Cirrus Logic CS42L52 Low power codec
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
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
participants (4)
-
Ben Dooks -
Brian Austin -
Mark Brown -
Timur Tabi