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.