[alsa-devel] [PATCH 00/10] OMAP4: ASoC: Support for PandaBoard family
Hello,
the following series will add ASoC support for PandaBoards. PandaBoards have different audio routings compared to SDP4430/Blaze boards, but the differences not that big to justify a new ASoC machine driver.
Main changes: - Rename the sdp4430 ASoC machine driver to use generic name: omap-abe-twl6040 - Convert the ASoC machine driver to platform driver - The type of the board, and the desired sound card name is passed via platform data to the ASoC machine driver - Based on the board type the driver selects different audio routings - Registration of the needed platform devices in board files (sdp4403, panda)
After this series the sound card names will be different for easier UCM integration: "OMAP4-SDP4430" for SDP4430/Blaze boards "OMAP4-Panda" for PandaBoard 4430 "OMAP4-PandaES" for PandaBoard ES (4460)
The series has been tested on Blaze, and PandaBoard ES.
Regards, Peter --- Peter Ujfalusi (10): ASoC: sdp4430: Correct author e-mail address ASoC: OMAP4: Rename the sdp4430 machine driver ASoC: omap-abe-twl6040: Correct internal prefix, Kconfig entry include: platform_data: Platform data header for OMAP4 ASoC audio OMAP4: 4430sdp: Register platform device for OMAP4 audio ASoC: omap-abe-twl6040: Convert to platform deriver ASoC: omap-abe-twl6040: Add support for PandaBoard OMAP4: omap4panda: Enable audio support ASoC: omap-abe-twl6040: Add missing audio route information ASoC: omap-abe-twl6040: Fix DAPM widget type for FM input
arch/arm/mach-omap2/board-4430sdp.c | 15 ++ arch/arm/mach-omap2/board-omap4panda.c | 48 +++++- include/linux/platform_data/omap-abe-twl6040.h | 33 ++++ sound/soc/omap/Kconfig | 14 +- sound/soc/omap/Makefile | 4 +- sound/soc/omap/{sdp4430.c => omap-abe-twl6040.c} | 198 ++++++++++++++++------ 6 files changed, 251 insertions(+), 61 deletions(-) create mode 100644 include/linux/platform_data/omap-abe-twl6040.h rename sound/soc/omap/{sdp4430.c => omap-abe-twl6040.c} (52%)
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com --- sound/soc/omap/sdp4430.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/sdp4430.c b/sound/soc/omap/sdp4430.c index 2735fa0..3186e0a 100644 --- a/sound/soc/omap/sdp4430.c +++ b/sound/soc/omap/sdp4430.c @@ -1,7 +1,7 @@ /* * sdp4430.c -- SoC audio for TI OMAP4430 SDP * - * Author: Misael Lopez Cruz x0052729@ti.com + * Author: Misael Lopez Cruz misael.lopez@ti.com * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -272,7 +272,7 @@ static void __exit sdp4430_soc_exit(void) } module_exit(sdp4430_soc_exit);
-MODULE_AUTHOR("Misael Lopez Cruz x0052729@ti.com"); +MODULE_AUTHOR("Misael Lopez Cruz misael.lopez@ti.com"); MODULE_DESCRIPTION("ALSA SoC SDP4430"); MODULE_LICENSE("GPL");
On Wed, Dec 14, 2011 at 11:46:54AM +0200, Peter Ujfalusi wrote:
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
The same machine driver will support other boards with similar audio configuration (OMAP4, ABE, twl6040). Rename the driver to have more generic name.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com --- sound/soc/omap/Kconfig | 2 +- sound/soc/omap/Makefile | 4 ++-- sound/soc/omap/{sdp4430.c => omap-abe-twl6040.c} | 1 - 3 files changed, 3 insertions(+), 4 deletions(-) rename sound/soc/omap/{sdp4430.c => omap-abe-twl6040.c} (99%)
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index fb1bf25..4eae929 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -97,7 +97,7 @@ config SND_OMAP_SOC_SDP3430 Say Y if you want to add support for SoC audio on Texas Instruments SDP3430.
-config SND_OMAP_SOC_SDP4430 +config SND_OMAP_SOC_OMAP_ABE_TWL6040 tristate "SoC Audio support for Texas Instruments SDP4430" depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP_4430SDP select SND_OMAP_SOC_DMIC diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index 1fd723f..123ac18 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -20,7 +20,7 @@ snd-soc-overo-objs := overo.o snd-soc-omap3evm-objs := omap3evm.o snd-soc-am3517evm-objs := am3517evm.o snd-soc-sdp3430-objs := sdp3430.o -snd-soc-sdp4430-objs := sdp4430.o +snd-soc-omap-abe-twl6040-objs := omap-abe-twl6040.o snd-soc-omap3pandora-objs := omap3pandora.o snd-soc-omap3beagle-objs := omap3beagle.o snd-soc-zoom2-objs := zoom2.o @@ -36,7 +36,7 @@ obj-$(CONFIG_SND_OMAP_SOC_OMAP2EVM) += snd-soc-omap2evm.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3EVM) += snd-soc-omap3evm.o obj-$(CONFIG_SND_OMAP_SOC_AM3517EVM) += snd-soc-am3517evm.o obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o -obj-$(CONFIG_SND_OMAP_SOC_SDP4430) += snd-soc-sdp4430.o +obj-$(CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040) += snd-soc-omap-abe-twl6040.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o obj-$(CONFIG_SND_OMAP_SOC_ZOOM2) += snd-soc-zoom2.o diff --git a/sound/soc/omap/sdp4430.c b/sound/soc/omap/omap-abe-twl6040.c similarity index 99% rename from sound/soc/omap/sdp4430.c rename to sound/soc/omap/omap-abe-twl6040.c index 3186e0a..67c1709 100644 --- a/sound/soc/omap/sdp4430.c +++ b/sound/soc/omap/omap-abe-twl6040.c @@ -275,4 +275,3 @@ module_exit(sdp4430_soc_exit); MODULE_AUTHOR("Misael Lopez Cruz misael.lopez@ti.com"); MODULE_DESCRIPTION("ALSA SoC SDP4430"); MODULE_LICENSE("GPL"); -
On Wed, Dec 14, 2011 at 11:46:55AM +0200, Peter Ujfalusi wrote:
The same machine driver will support other boards with similar audio configuration (OMAP4, ABE, twl6040). Rename the driver to have more generic name.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
Though given that ABE is part of the OMAP4 silicon it seems silly to include it in the name, it's like calling it omap4-abe-mcpdm- and so on.
Change the internal prefixes within the driver from sdp4430. At he same time correct the Kconfig text as well.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com --- sound/soc/omap/Kconfig | 7 ++-- sound/soc/omap/omap-abe-twl6040.c | 65 +++++++++++++++++++------------------ 2 files changed, 37 insertions(+), 35 deletions(-)
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 4eae929..98410b8 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -98,15 +98,16 @@ config SND_OMAP_SOC_SDP3430 SDP3430.
config SND_OMAP_SOC_OMAP_ABE_TWL6040 - tristate "SoC Audio support for Texas Instruments SDP4430" + tristate "SoC Audio support for OMAP boards using ABE and twl6040 codec" depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP_4430SDP select SND_OMAP_SOC_DMIC select SND_OMAP_SOC_MCPDM select SND_SOC_TWL6040 select SND_SOC_DMIC help - Say Y if you want to add support for SoC audio on Texas Instruments - SDP4430. + Say Y if you want to add support for SoC audio on OMAP boards using + ABE and twl6040 codec. This driver currently supports: + - SDP4430/Blaze boards
config SND_OMAP_SOC_OMAP4_HDMI tristate "SoC Audio support for Texas Instruments OMAP4 HDMI" diff --git a/sound/soc/omap/omap-abe-twl6040.c b/sound/soc/omap/omap-abe-twl6040.c index 67c1709..9c6d97a 100644 --- a/sound/soc/omap/omap-abe-twl6040.c +++ b/sound/soc/omap/omap-abe-twl6040.c @@ -1,5 +1,6 @@ /* - * sdp4430.c -- SoC audio for TI OMAP4430 SDP + * omap-abe-twl6040.c -- SoC audio for TI OMAP based boards with ABE and + * twl6040 codec * * Author: Misael Lopez Cruz misael.lopez@ti.com * @@ -38,7 +39,7 @@ #include "omap-pcm.h" #include "../codecs/twl6040.h"
-static int sdp4430_hw_params(struct snd_pcm_substream *substream, +static int omapabe_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { struct snd_soc_pcm_runtime *rtd = substream->private_data; @@ -64,11 +65,11 @@ static int sdp4430_hw_params(struct snd_pcm_substream *substream, return ret; }
-static struct snd_soc_ops sdp4430_ops = { - .hw_params = sdp4430_hw_params, +static struct snd_soc_ops omapabe_ops = { + .hw_params = omapabe_hw_params, };
-static int sdp4430_dmic_hw_params(struct snd_pcm_substream *substream, +static int omapabe_dmic_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { struct snd_soc_pcm_runtime *rtd = substream->private_data; @@ -90,8 +91,8 @@ static int sdp4430_dmic_hw_params(struct snd_pcm_substream *substream, return 0; }
-static struct snd_soc_ops sdp4430_dmic_ops = { - .hw_params = sdp4430_dmic_hw_params, +static struct snd_soc_ops omapabe_dmic_ops = { + .hw_params = omapabe_dmic_hw_params, };
/* Headset jack */ @@ -110,7 +111,7 @@ static struct snd_soc_jack_pin hs_jack_pins[] = { };
/* SDP4430 machine DAPM */ -static const struct snd_soc_dapm_widget sdp4430_twl6040_dapm_widgets[] = { +static const struct snd_soc_dapm_widget twl6040_dapm_widgets[] = { SND_SOC_DAPM_MIC("Ext Mic", NULL), SND_SOC_DAPM_SPK("Ext Spk", NULL), SND_SOC_DAPM_MIC("Headset Mic", NULL), @@ -145,7 +146,7 @@ static const struct snd_soc_dapm_route audio_map[] = { {"AFMR", NULL, "FM Stereo In"}, };
-static int sdp4430_twl6040_init(struct snd_soc_pcm_runtime *rtd) +static int omapabe_twl6040_init(struct snd_soc_pcm_runtime *rtd) { struct snd_soc_codec *codec = rtd->codec; int ret, hs_trim; @@ -175,7 +176,7 @@ static int sdp4430_twl6040_init(struct snd_soc_pcm_runtime *rtd) return ret; }
-static const struct snd_soc_dapm_widget sdp4430_dmic_dapm_widgets[] = { +static const struct snd_soc_dapm_widget dmic_dapm_widgets[] = { SND_SOC_DAPM_MIC("Digital Mic", NULL), };
@@ -184,14 +185,14 @@ static const struct snd_soc_dapm_route dmic_audio_map[] = { {"Digital Mic1 Bias", NULL, "Digital Mic"}, };
-static int sdp4430_dmic_init(struct snd_soc_pcm_runtime *rtd) +static int omapabe_dmic_init(struct snd_soc_pcm_runtime *rtd) { struct snd_soc_codec *codec = rtd->codec; struct snd_soc_dapm_context *dapm = &codec->dapm; int ret;
- ret = snd_soc_dapm_new_controls(dapm, sdp4430_dmic_dapm_widgets, - ARRAY_SIZE(sdp4430_dmic_dapm_widgets)); + ret = snd_soc_dapm_new_controls(dapm, dmic_dapm_widgets, + ARRAY_SIZE(dmic_dapm_widgets)); if (ret) return ret;
@@ -208,8 +209,8 @@ static struct snd_soc_dai_link sdp4430_dai[] = { .codec_dai_name = "twl6040-legacy", .platform_name = "omap-pcm-audio", .codec_name = "twl6040-codec", - .init = sdp4430_twl6040_init, - .ops = &sdp4430_ops, + .init = omapabe_twl6040_init, + .ops = &omapabe_ops, }, { .name = "DMIC", @@ -218,26 +219,26 @@ static struct snd_soc_dai_link sdp4430_dai[] = { .codec_dai_name = "dmic-hifi", .platform_name = "omap-pcm-audio", .codec_name = "dmic-codec", - .init = sdp4430_dmic_init, - .ops = &sdp4430_dmic_ops, + .init = omapabe_dmic_init, + .ops = &omapabe_dmic_ops, }, };
/* Audio machine driver */ -static struct snd_soc_card snd_soc_sdp4430 = { +static struct snd_soc_card omapabe_card = { .name = "SDP4430", .dai_link = sdp4430_dai, .num_links = ARRAY_SIZE(sdp4430_dai),
- .dapm_widgets = sdp4430_twl6040_dapm_widgets, - .num_dapm_widgets = ARRAY_SIZE(sdp4430_twl6040_dapm_widgets), + .dapm_widgets = twl6040_dapm_widgets, + .num_dapm_widgets = ARRAY_SIZE(twl6040_dapm_widgets), .dapm_routes = audio_map, .num_dapm_routes = ARRAY_SIZE(audio_map), };
-static struct platform_device *sdp4430_snd_device; +static struct platform_device *omapabe_snd_device;
-static int __init sdp4430_soc_init(void) +static int __init omapabe_soc_init(void) { int ret;
@@ -245,15 +246,15 @@ static int __init sdp4430_soc_init(void) return -ENODEV; printk(KERN_INFO "SDP4430 SoC init\n");
- sdp4430_snd_device = platform_device_alloc("soc-audio", -1); - if (!sdp4430_snd_device) { + omapabe_snd_device = platform_device_alloc("soc-audio", -1); + if (!omapabe_snd_device) { printk(KERN_ERR "Platform device allocation failed\n"); return -ENOMEM; }
- platform_set_drvdata(sdp4430_snd_device, &snd_soc_sdp4430); + platform_set_drvdata(omapabe_snd_device, &omapabe_card);
- ret = platform_device_add(sdp4430_snd_device); + ret = platform_device_add(omapabe_snd_device); if (ret) goto err;
@@ -261,17 +262,17 @@ static int __init sdp4430_soc_init(void)
err: printk(KERN_ERR "Unable to add platform device\n"); - platform_device_put(sdp4430_snd_device); + platform_device_put(omapabe_snd_device); return ret; } -module_init(sdp4430_soc_init); +module_init(omapabe_soc_init);
-static void __exit sdp4430_soc_exit(void) +static void __exit omapabe_soc_exit(void) { - platform_device_unregister(sdp4430_snd_device); + platform_device_unregister(omapabe_snd_device); } -module_exit(sdp4430_soc_exit); +module_exit(omapabe_soc_exit);
MODULE_AUTHOR("Misael Lopez Cruz misael.lopez@ti.com"); -MODULE_DESCRIPTION("ALSA SoC SDP4430"); +MODULE_DESCRIPTION("ALSA SoC for OMAP boards with ABE and twl6040 codec"); MODULE_LICENSE("GPL");
On Wed, Dec 14, 2011 at 11:46:56AM +0200, Peter Ujfalusi wrote:
Change the internal prefixes within the driver from sdp4430. At he same time correct the Kconfig text as well.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
Include file to be used with the upcoming ASoC machine driver for OMAP platform using ABE with twl6040 codec.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com --- include/linux/platform_data/omap-abe-twl6040.h | 33 ++++++++++++++++++++++++ 1 files changed, 33 insertions(+), 0 deletions(-) create mode 100644 include/linux/platform_data/omap-abe-twl6040.h
diff --git a/include/linux/platform_data/omap-abe-twl6040.h b/include/linux/platform_data/omap-abe-twl6040.h new file mode 100644 index 0000000..afbdff4 --- /dev/null +++ b/include/linux/platform_data/omap-abe-twl6040.h @@ -0,0 +1,33 @@ +/** + * omap-abe-twl6040.h - ASoC machine driver OMAP4+ devices, header. + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com + * All rights reserved. + * + * Author: Peter Ujfalusi peter.ujfalusi@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + */ + +enum board_type { + OMAP_ABE_TWL6040_SDP4430, + OMAP_ABE_TWL6040_PANDA, + OMAP_ABE_TWL6040_PANDA_ES, +}; + +struct omap_abe_twl6040_data { + char *card_name; + enum board_type board; +};
On Wed, Dec 14, 2011 at 11:46:57AM +0200, Peter Ujfalusi wrote:
+enum board_type {
- OMAP_ABE_TWL6040_SDP4430,
- OMAP_ABE_TWL6040_PANDA,
- OMAP_ABE_TWL6040_PANDA_ES,
+};
It seems like it might better in the long run to make this feature based rather than enumerating the individual boards - that means that if boards mix and match the features or add features on the side of additional designs (eg, external amplifiers that need power control) it's easier to scale the options.
On Wednesday 14 December 2011 17:57:47 Mark Brown wrote:
On Wed, Dec 14, 2011 at 11:46:57AM +0200, Peter Ujfalusi wrote:
+enum board_type {
- OMAP_ABE_TWL6040_SDP4430,
- OMAP_ABE_TWL6040_PANDA,
- OMAP_ABE_TWL6040_PANDA_ES,
+};
It seems like it might better in the long run to make this feature based rather than enumerating the individual boards - that means that if boards mix and match the features or add features on the side of additional designs (eg, external amplifiers that need power control) it's easier to scale the options.
Yes this is planed for the Dtree support, but the aim here is to get working audio on PandaBoard as well with upstream kernel.
-- Péter
On Thu, Dec 15, 2011 at 03:02:44PM +0200, Péter Ujfalusi wrote:
On Wednesday 14 December 2011 17:57:47 Mark Brown wrote:
It seems like it might better in the long run to make this feature based rather than enumerating the individual boards - that means that if boards mix and match the features or add features on the side of additional designs (eg, external amplifiers that need power control) it's easier to scale the options.
Yes this is planed for the Dtree support, but the aim here is to get working audio on PandaBoard as well with upstream kernel.
Just do it right to start off with, the device tree bindings should normally map closely onto the platform data where platform data exists already and you're going to have to have the code structured by feature anyway.
Hi Mark, Tony,
On 12/17/2011 11:36 AM, Mark Brown wrote:
Yes this is planed for the Dtree support, but the aim here is to get working audio on PandaBoard as well with upstream kernel.
Just do it right to start off with, the device tree bindings should normally map closely onto the platform data where platform data exists already and you're going to have to have the code structured by feature anyway.
I do not want to 'bloat' the board files under mach-omap2 for sdp4430, Panda with string arrays to pass the DAPM routing from there to the ASoC machine driver to construct the board specific routing. All of this sort of thing will go away with DT in the future (including the platform_data).
I planed to do this similar way as it is done for the tegra_wm8903.c machine driver: - without DT blob we support only sdp4430, Panda boards - with DT we will have similar mapping as tegra is planning to have.
If Tony is fine to add text array constructed under mach-omap2 which describes the ASoC DAPM mapping, I can do it, but AFAIK we should minimize the code size in that part of the kernel.
To pass the routing from the board files I need to modify the platform_data:
struct omap-abe-twl6040-connection { const char *sink; const char *source; };
struct omap_abe_twl6040_data { char *card_name; enum board_type board; struct omap-abe-twl6040-connection *route; int num_of_routes; };
In board files: struct omap-abe-twl6040-connection sdp4430_asoc_route[] = { {"MAINMIC", "Main Mic Bias"}, {"SUBMIC", "Main Mic Bias"}, {"Main Mic Bias", "Ext Mic"}, ... 16 string pair. }
If this is acceptable by Tony, I can do this.
To describe the routing via feature flags is not really practical due to the possible variation I can think of.
Tony: what do you think? Is this something that is allowed to do under plat-omap2?
* Peter Ujfalusi peter.ujfalusi@ti.com [111219 05:33]:
Hi Mark, Tony,
On 12/17/2011 11:36 AM, Mark Brown wrote:
Yes this is planed for the Dtree support, but the aim here is to get working audio on PandaBoard as well with upstream kernel.
Just do it right to start off with, the device tree bindings should normally map closely onto the platform data where platform data exists already and you're going to have to have the code structured by feature anyway.
I do not want to 'bloat' the board files under mach-omap2 for sdp4430, Panda with string arrays to pass the DAPM routing from there to the ASoC machine driver to construct the board specific routing. All of this sort of thing will go away with DT in the future (including the platform_data).
I planed to do this similar way as it is done for the tegra_wm8903.c machine driver:
- without DT blob we support only sdp4430, Panda boards
- with DT we will have similar mapping as tegra is planning to have.
If Tony is fine to add text array constructed under mach-omap2 which describes the ASoC DAPM mapping, I can do it, but AFAIK we should minimize the code size in that part of the kernel.
To pass the routing from the board files I need to modify the platform_data:
struct omap-abe-twl6040-connection { const char *sink; const char *source; };
struct omap_abe_twl6040_data { char *card_name; enum board_type board; struct omap-abe-twl6040-connection *route; int num_of_routes; };
In board files: struct omap-abe-twl6040-connection sdp4430_asoc_route[] = { {"MAINMIC", "Main Mic Bias"}, {"SUBMIC", "Main Mic Bias"}, {"Main Mic Bias", "Ext Mic"}, ... 16 string pair. }
If this is acceptable by Tony, I can do this.
Hmm does it make sense to describe all those in DT? If you can group things in some sane way, then maybe the routings could be stored in the driver itself in the .data associated with the DT compatible flag? That is of course assuming there are some sane ways to group the routings..
To describe the routing via feature flags is not really practical due to the possible variation I can think of.
..which may not be the case. And you need to be careful not to misuse the compatible flag either.
Tony: what do you think? Is this something that is allowed to do under plat-omap2?
Well if that's the way the ASoC people agree to do it, then yes. But if it's a short term hack while waiting for the device tree, then it might be best to keep carry it around as an external patch until DT bindings work.
Regards,
Tony
On Mon, Dec 19, 2011 at 11:20:37AM -0800, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [111219 05:33]:
struct omap-abe-twl6040-connection sdp4430_asoc_route[] = { {"MAINMIC", "Main Mic Bias"}, {"SUBMIC", "Main Mic Bias"}, {"Main Mic Bias", "Ext Mic"},
Hmm does it make sense to describe all those in DT? If you can group things in some sane way, then maybe the routings could be stored in the driver itself in the .data associated with the DT compatible flag? That is of course assuming there are some sane ways to group the routings..
No, and it's not completely trivial to do so until we have a sensible binding for the objects you find on boards, especially jacks which don't map in any sort of straightforward fashion onto the DAPM routes which we need internally as they'll often group a bunch of different signals into a single connector that don't have any direct relationship at the driver level.
The old style MICBIAS widgets that the CODEC driver is using would also be something I'd consider a blocker to direct use in device tree - the way they're hooked up is really Linux specific and not terribly clear either.
On Mon, Dec 19, 2011 at 04:04:53PM +0200, Peter Ujfalusi wrote:
On 12/17/2011 11:36 AM, Mark Brown wrote:
Just do it right to start off with, the device tree bindings should normally map closely onto the platform data where platform data exists already and you're going to have to have the code structured by feature anyway.
I do not want to 'bloat' the board files under mach-omap2 for sdp4430, Panda with string arrays to pass the DAPM routing from there to the ASoC machine driver to construct the board specific routing.
I don't know that you need to push the full DAPM table down there, there's certainly way more compact ways of representing selections like this.
All of this sort of thing will go away with DT in the future (including the platform_data).
I'm not really happy with this as a reason for pushing low quality stuff in - either the code isn't going to be around long so we may as well jump to what we meant to do or it's going to be there for long enough that people will have to work with it (and perhaps pick it up as a reference).
struct omap-abe-twl6040-connection { const char *sink; const char *source; };
omap-abe-mcbsp--mcpdm-twl4030? :P
To be honest if you're going to do this I don't understand why you'd bother defining this type which you'll just have to translate into a dapm_route.
To avoid breakage in audio support with the coming change in ASoC machine driver (conversion to platfrom device).
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com --- arch/arm/mach-omap2/board-4430sdp.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 271e50b..69708a4 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -25,6 +25,7 @@ #include <linux/regulator/fixed.h> #include <linux/leds.h> #include <linux/leds_pwm.h> +#include <linux/platform_data/omap-abe-twl6040.h>
#include <mach/hardware.h> #include <mach/omap4-common.h> @@ -377,12 +378,26 @@ static struct platform_device sdp4430_dmic_codec = { .id = -1, };
+static struct omap_abe_twl6040_data sdp4430_abe_audio_data = { + .card_name = "OMAP4-SDP4430", + .board = OMAP_ABE_TWL6040_SDP4430, +}; + +static struct platform_device sdp4430_abe_audio = { + .name = "omap-abe-twl6040", + .id = -1, + .dev = { + .platform_data = &sdp4430_abe_audio_data, + }, +}; + static struct platform_device *sdp4430_devices[] __initdata = { &sdp4430_gpio_keys_device, &sdp4430_leds_gpio, &sdp4430_leds_pwm, &sdp4430_vbat, &sdp4430_dmic_codec, + &sdp4430_abe_audio, };
static struct omap_musb_board_data musb_board_data = {
Hi,
* Peter Ujfalusi peter.ujfalusi@ti.com [111214 01:17]:
To avoid breakage in audio support with the coming change in ASoC machine driver (conversion to platfrom device).
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com
This series looks OK to me to queue via the ASoC tree:
Acked-by: Tony Lindgren tony@atomide.com
To avoid merge conflicts, you should base the branch on commit deee6d5359969a0ce4e2760cfd7b9f379bd5698a (ARM: 7194/1: OMAP: Fix build after a merge between v3.2-rc4 and ARM restart changes) in Russell's devel-stable branch because of the common.h changes.
This is because at least..
--- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -25,6 +25,7 @@ #include <linux/regulator/fixed.h> #include <linux/leds.h> #include <linux/leds_pwm.h> +#include <linux/platform_data/omap-abe-twl6040.h>
#include <mach/hardware.h> #include <mach/omap4-common.h>
..omap4-common.h no longer exists. Just guessing, might be worth trying a test merge to see what happens.
Regards,
Tony
Convert the OMAP4 ABE/TWL6040 machine driver to platform driver. For the card name use the string provided via platform data. The card's name for OMAP4 SDP4430 has been changed: SDP4430 -> OMAP4-SDP4430
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com --- sound/soc/omap/omap-abe-twl6040.c | 59 ++++++++++++++++++++++-------------- 1 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/sound/soc/omap/omap-abe-twl6040.c b/sound/soc/omap/omap-abe-twl6040.c index 9c6d97a..4974ea1 100644 --- a/sound/soc/omap/omap-abe-twl6040.c +++ b/sound/soc/omap/omap-abe-twl6040.c @@ -23,6 +23,7 @@ #include <linux/clk.h> #include <linux/platform_device.h> #include <linux/mfd/twl6040.h> +#include <linux/platform_data/omap-abe-twl6040.h> #include <linux/module.h>
#include <sound/core.h> @@ -226,7 +227,6 @@ static struct snd_soc_dai_link sdp4430_dai[] = {
/* Audio machine driver */ static struct snd_soc_card omapabe_card = { - .name = "SDP4430", .dai_link = sdp4430_dai, .num_links = ARRAY_SIZE(sdp4430_dai),
@@ -236,43 +236,56 @@ static struct snd_soc_card omapabe_card = { .num_dapm_routes = ARRAY_SIZE(audio_map), };
-static struct platform_device *omapabe_snd_device; - -static int __init omapabe_soc_init(void) +static __devinit int omapabe_probe(struct platform_device *pdev) { + struct omap_abe_twl6040_data *pdata = dev_get_platdata(&pdev->dev); + struct snd_soc_card *card = &omapabe_card; int ret;
- if (!machine_is_omap_4430sdp()) - return -ENODEV; - printk(KERN_INFO "SDP4430 SoC init\n"); + card->dev = &pdev->dev;
- omapabe_snd_device = platform_device_alloc("soc-audio", -1); - if (!omapabe_snd_device) { - printk(KERN_ERR "Platform device allocation failed\n"); - return -ENOMEM; + if (!pdata) { + dev_err(&pdev->dev, "Missing pdata\n"); + return -ENODEV; }
- platform_set_drvdata(omapabe_snd_device, &omapabe_card); + if (pdata->card_name) { + card->name = pdata->card_name; + } else { + dev_err(&pdev->dev, "Card name is not provided\n"); + return -ENODEV; + }
- ret = platform_device_add(omapabe_snd_device); + ret = snd_soc_register_card(card); if (ret) - goto err; - - return 0; + dev_err(&pdev->dev, "snd_soc_register_card() failed: %d\n", + ret);
-err: - printk(KERN_ERR "Unable to add platform device\n"); - platform_device_put(omapabe_snd_device); return ret; } -module_init(omapabe_soc_init);
-static void __exit omapabe_soc_exit(void) +static int __devexit omapabe_remove(struct platform_device *pdev) { - platform_device_unregister(omapabe_snd_device); + struct snd_soc_card *card = platform_get_drvdata(pdev); + + snd_soc_unregister_card(card); + + return 0; } -module_exit(omapabe_soc_exit); + +static struct platform_driver omapabe_driver = { + .driver = { + .name = "omap-abe-twl6040", + .owner = THIS_MODULE, + .pm = &snd_soc_pm_ops, + }, + .probe = omapabe_probe, + .remove = __devexit_p(omapabe_remove), +}; + +module_platform_driver(omapabe_driver);
MODULE_AUTHOR("Misael Lopez Cruz misael.lopez@ti.com"); MODULE_DESCRIPTION("ALSA SoC for OMAP boards with ABE and twl6040 codec"); MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:omap-abe-twl6040");
On Wed, Dec 14, 2011 at 11:46:59AM +0200, Peter Ujfalusi wrote:
The card's name for OMAP4 SDP4430 has been changed: SDP4430 -> OMAP4-SDP4430
Why? The board appaers to be generally known as SDP4430...
On Wednesday 14 December 2011 18:01:00 Mark Brown wrote:
On Wed, Dec 14, 2011 at 11:46:59AM +0200, Peter Ujfalusi wrote:
The card's name for OMAP4 SDP4430 has been changed: SDP4430 -> OMAP4-SDP4430
Why? The board appaers to be generally known as SDP4430...
At the moment we do not have users using the audio on top of the upstream kernel. All distributions are using patched kernel with ABE support. In there the audio card is know as SDP4430, and we have the UCM profile for the ABE version of the OMAP4 boards there which will not work on the upstream kernel since we do not have yet the ABE in mainline kernel. My plan is to add the UCM files for the upstream version of the driver which will be updated as soon we got new features (like the ABE support). It is easier for distros also to move, when time comes to the new kernel.
-- Péter
On Wed, Dec 14, 2011 at 12:15:58PM +0200, Péter Ujfalusi wrote:
On Wednesday 14 December 2011 18:01:00 Mark Brown wrote:
Why? The board appaers to be generally known as SDP4430...
At the moment we do not have users using the audio on top of the upstream kernel. All distributions are using patched kernel with ABE support. In there the audio card is know as SDP4430, and we have the UCM profile for the ABE version of the OMAP4 boards there which will not work on the upstream kernel since we do not have yet the ABE in mainline kernel. My plan is to add the UCM files for the upstream version of the driver which will be updated as soon we got new features (like the ABE support). It is easier for distros also to move, when time comes to the new kernel.
This seems like we need a better system for doing this, we can't go changing the machine name every time there's a kernel space change that affects a UCM file, that's going to get crazy. Not quite sure what the best approach is here - version specific directories perhaps, or some method of keying off the presence of certain controls.
Hi Mark,
On Wednesday 14 December 2011 19:27:11 Mark Brown wrote:
This seems like we need a better system for doing this, we can't go changing the machine name every time there's a kernel space change that affects a UCM file, that's going to get crazy.
As of know we do not have UCM for the driver in upstream. In fact it is not recommended at the moment to use the upstream driver since we do not have the ABE/dynamic PCM upstream. There are UCM files shipped with distributions (like Linaro, ubuntu), but those UCM files will not work with the upstream kernel (due to the missing parts). It can be also confusing to have the same card name for fundamentally different sound cards. We do support the kernel shipped with distributions (with patched up ASoC), but we also need to support clean upstream version. Having to deal with mismatching UCM files does not really help here.
I have not planned to change the card names in the future.
Having said that I can revert back to use the names used by Linaro for example (even if the cards are different): SPD4430/Panda/PandaES
If I write the UCM file it will be for the vanilla upstream sound, so we will have UCM files upstream, which does not work on the Distributions - I think this is even more confusing than having different card names initially untill we get everything upstream.
-- Péter
PS: Liam: what is your take on this?
On Thursday 15 December 2011 10:17:38 Péter Ujfalusi wrote:
Hi Mark,
On Wednesday 14 December 2011 19:27:11 Mark Brown wrote:
This seems like we need a better system for doing this, we can't go changing the machine name every time there's a kernel space change that affects a UCM file, that's going to get crazy.
We can handle the different features on the card with the same name with UCM fine, so I will not change the name of the card. Will be fixed for v2.
-- Péter
PandaBoard has a bit different set of audio features compared to SDP4430: - No DMIC - Earphone pins are not connected - Vibra is not connected
On PandaBoard 4430: - FM receiver is connected to AFML/R input - FM transmitter is connected to AUXL/R output - Input jack is connected as to HSMIC
On PandaBoard ES: - FM receiver/transmitter is not connected - Input jack is connected to AFML/R
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com --- sound/soc/omap/Kconfig | 5 ++- sound/soc/omap/omap-abe-twl6040.c | 82 ++++++++++++++++++++++++++++++++++--- 2 files changed, 80 insertions(+), 7 deletions(-)
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 98410b8..3463ee2 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -99,7 +99,8 @@ config SND_OMAP_SOC_SDP3430
config SND_OMAP_SOC_OMAP_ABE_TWL6040 tristate "SoC Audio support for OMAP boards using ABE and twl6040 codec" - depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP_4430SDP + depends on TWL4030_CORE && SND_OMAP_SOC + depends on MACH_OMAP_4430SDP || MACH_OMAP4_PANDA select SND_OMAP_SOC_DMIC select SND_OMAP_SOC_MCPDM select SND_SOC_TWL6040 @@ -108,6 +109,8 @@ config SND_OMAP_SOC_OMAP_ABE_TWL6040 Say Y if you want to add support for SoC audio on OMAP boards using ABE and twl6040 codec. This driver currently supports: - SDP4430/Blaze boards + - PandaBoard 4430 + - PandaBoard ES (4460)
config SND_OMAP_SOC_OMAP4_HDMI tristate "SoC Audio support for Texas Instruments OMAP4 HDMI" diff --git a/sound/soc/omap/omap-abe-twl6040.c b/sound/soc/omap/omap-abe-twl6040.c index 4974ea1..25a75f3 100644 --- a/sound/soc/omap/omap-abe-twl6040.c +++ b/sound/soc/omap/omap-abe-twl6040.c @@ -119,9 +119,11 @@ static const struct snd_soc_dapm_widget twl6040_dapm_widgets[] = { SND_SOC_DAPM_HP("Headset Stereophone", NULL), SND_SOC_DAPM_SPK("Earphone Spk", NULL), SND_SOC_DAPM_INPUT("FM Stereo In"), + SND_SOC_DAPM_LINE("FM Stereo Out", NULL), + SND_SOC_DAPM_LINE("Line In", NULL), };
-static const struct snd_soc_dapm_route audio_map[] = { +static const struct snd_soc_dapm_route sdp4430_audio_map[] = { /* External Mics: MAINMIC, SUBMIC with bias*/ {"MAINMIC", NULL, "Main Mic Bias"}, {"SUBMIC", NULL, "Main Mic Bias"}, @@ -147,6 +149,42 @@ static const struct snd_soc_dapm_route audio_map[] = { {"AFMR", NULL, "FM Stereo In"}, };
+static const struct snd_soc_dapm_route panda_audio_map[] = { + /* External Speakers: HFL, HFR - through expansion connector */ + {"Ext Spk", NULL, "HFL"}, + {"Ext Spk", NULL, "HFR"}, + + /* Headset Mic: HSMIC with bias */ + {"HSMIC", NULL, "Headset Mic Bias"}, + {"Headset Mic Bias", NULL, "Headset Mic"}, + + /* Headset Stereophone (Headphone): HSOL, HSOR */ + {"Headset Stereophone", NULL, "HSOL"}, + {"Headset Stereophone", NULL, "HSOR"}, + + /* Aux/FM Stereo In: AFML, AFMR */ + {"AFML", NULL, "FM Stereo In"}, + {"AFMR", NULL, "FM Stereo In"}, + + /* AUXL/R output to FM transmitter */ + {"FM Stereo Out", NULL, "AUXL"}, + {"FM Stereo Out", NULL, "AUXR"}, +}; + +static const struct snd_soc_dapm_route pandaes_audio_map[] = { + /* External Speakers: HFL, HFR - through expansion connector */ + {"Ext Spk", NULL, "HFL"}, + {"Ext Spk", NULL, "HFR"}, + + /* Headset Stereophone (Headphone): HSOL, HSOR */ + {"Headset Stereophone", NULL, "HSOL"}, + {"Headset Stereophone", NULL, "HSOR"}, + + /* Line in jack: AFML, AFMR */ + {"AFML", NULL, "Line In"}, + {"AFMR", NULL, "Line In"}, +}; + static int omapabe_twl6040_init(struct snd_soc_pcm_runtime *rtd) { struct snd_soc_codec *codec = rtd->codec; @@ -225,15 +263,23 @@ static struct snd_soc_dai_link sdp4430_dai[] = { }, };
+static struct snd_soc_dai_link panda_dai[] = { + { + .name = "TWL6040", + .stream_name = "TWL6040", + .cpu_dai_name = "omap-mcpdm", + .codec_dai_name = "twl6040-legacy", + .platform_name = "omap-pcm-audio", + .codec_name = "twl6040-codec", + .init = omapabe_twl6040_init, + .ops = &omapabe_ops, + }, +}; + /* Audio machine driver */ static struct snd_soc_card omapabe_card = { - .dai_link = sdp4430_dai, - .num_links = ARRAY_SIZE(sdp4430_dai), - .dapm_widgets = twl6040_dapm_widgets, .num_dapm_widgets = ARRAY_SIZE(twl6040_dapm_widgets), - .dapm_routes = audio_map, - .num_dapm_routes = ARRAY_SIZE(audio_map), };
static __devinit int omapabe_probe(struct platform_device *pdev) @@ -256,6 +302,30 @@ static __devinit int omapabe_probe(struct platform_device *pdev) return -ENODEV; }
+ switch (pdata->board) { + case OMAP_ABE_TWL6040_SDP4430: + card->dai_link = sdp4430_dai; + card->num_links = ARRAY_SIZE(sdp4430_dai); + card->dapm_routes = sdp4430_audio_map; + card->num_dapm_routes = ARRAY_SIZE(sdp4430_audio_map); + break; + case OMAP_ABE_TWL6040_PANDA: + card->dai_link = panda_dai; + card->num_links = ARRAY_SIZE(panda_dai); + card->dapm_routes = panda_audio_map; + card->num_dapm_routes = ARRAY_SIZE(panda_audio_map); + break; + case OMAP_ABE_TWL6040_PANDA_ES: + card->dai_link = panda_dai; + card->num_links = ARRAY_SIZE(panda_dai); + card->dapm_routes = pandaes_audio_map; + card->num_dapm_routes = ARRAY_SIZE(pandaes_audio_map); + break; + default: + dev_err(&pdev->dev, "Invalid board type: %d\n", pdata->board); + return -ENODEV; + } + ret = snd_soc_register_card(card); if (ret) dev_err(&pdev->dev, "snd_soc_register_card() failed: %d\n",
PandaBoard has twl6040 codec for audio. Register the omap4-abe-twl6040 platform device. Add platform data to enable the twl6040 codec. Since there is a difference in audio between PandaBoard 4430 and PandaBoard ES (4460): Use different name for the sound card: "OMAP4-Panda" for PandaBoard 4430 "OMAP4-PandaES" for PandaBoard ES
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com
board: audio for panda --- arch/arm/mach-omap2/board-omap4panda.c | 48 +++++++++++++++++++++++++++++++- 1 files changed, 47 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index a8c2c42..6331626 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -28,6 +28,7 @@ #include <linux/regulator/machine.h> #include <linux/regulator/fixed.h> #include <linux/wl12xx.h> +#include <linux/platform_data/omap-abe-twl6040.h>
#include <mach/hardware.h> #include <mach/omap4-common.h> @@ -90,9 +91,23 @@ static struct platform_device leds_gpio = { }, };
+static struct omap_abe_twl6040_data panda_abe_audio_data = { + .card_name = "OMAP4-Panda", + .board = OMAP_ABE_TWL6040_PANDA, +}; + +static struct platform_device panda_abe_audio = { + .name = "omap-abe-twl6040", + .id = -1, + .dev = { + .platform_data = &panda_abe_audio_data, + }, +}; + static struct platform_device *panda_devices[] __initdata = { &leds_gpio, &wl1271_device, + &panda_abe_audio, };
static const struct usbhs_omap_board_data usbhs_bdata __initconst = { @@ -251,8 +266,25 @@ static int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers) return 0; }
+static struct twl4030_codec_data twl6040_codec = { + /* single-step ramp for headset and handsfree */ + .hs_left_step = 0x0f, + .hs_right_step = 0x0f, + .hf_left_step = 0x1d, + .hf_right_step = 0x1d, +}; + +static struct twl4030_audio_data twl6040_audio = { + .codec = &twl6040_codec, + .audpwron_gpio = 127, + .naudint_irq = OMAP44XX_IRQ_SYS_2N, + .irq_base = TWL6040_CODEC_IRQ_BASE, +}; + /* Panda board uses the common PMIC configuration */ -static struct twl4030_platform_data omap4_panda_twldata; +static struct twl4030_platform_data omap4_panda_twldata = { + .audio = &twl6040_audio, +};
/* * Display monitor features are burnt in their EEPROM as EDID data. The EEPROM @@ -548,6 +580,19 @@ void omap4_panda_display_init(void) omap_display_init(&omap4_panda_dss_data); }
+static void omap4_panda_audio_init(void) +{ + if (cpu_is_omap4430()) { + /* PandaBoard 4430 */ + panda_abe_audio_data.card_name = "OMAP4-Panda"; + panda_abe_audio_data.board = OMAP_ABE_TWL6040_PANDA; + } else { + /* PandaBoard ES */ + panda_abe_audio_data.card_name = "OMAP4-PandaES"; + panda_abe_audio_data.board = OMAP_ABE_TWL6040_PANDA_ES; + } +} + static void __init omap4_panda_init(void) { int package = OMAP_PACKAGE_CBS; @@ -560,6 +605,7 @@ static void __init omap4_panda_init(void) pr_err("error setting wl12xx data\n");
omap4_panda_i2c_init(); + omap4_panda_audio_init(); platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices)); platform_device_register(&omap_vwlan_device); board_serial_init();
* Peter Ujfalusi peter.ujfalusi@ti.com [111214 01:17]:
PandaBoard has twl6040 codec for audio. Register the omap4-abe-twl6040 platform device. Add platform data to enable the twl6040 codec. Since there is a difference in audio between PandaBoard 4430 and PandaBoard ES (4460): Use different name for the sound card: "OMAP4-Panda" for PandaBoard 4430 "OMAP4-PandaES" for PandaBoard ES
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com
This too might have some minor merge conflicts, but looks OK to queue via ASoC tree:
Acked-by: Tony Lindgren tony@atomide.com
AUXL/R: connected to FM transmitter on SDP4430 Vibra: connected to vibrator drivers (only SDP4430)
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com --- sound/soc/omap/omap-abe-twl6040.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-abe-twl6040.c b/sound/soc/omap/omap-abe-twl6040.c index 25a75f3..05c6474 100644 --- a/sound/soc/omap/omap-abe-twl6040.c +++ b/sound/soc/omap/omap-abe-twl6040.c @@ -121,6 +121,7 @@ static const struct snd_soc_dapm_widget twl6040_dapm_widgets[] = { SND_SOC_DAPM_INPUT("FM Stereo In"), SND_SOC_DAPM_LINE("FM Stereo Out", NULL), SND_SOC_DAPM_LINE("Line In", NULL), + SND_SOC_DAPM_SPK("Vibrators", NULL), };
static const struct snd_soc_dapm_route sdp4430_audio_map[] = { @@ -147,6 +148,14 @@ static const struct snd_soc_dapm_route sdp4430_audio_map[] = { /* Aux/FM Stereo In: AFML, AFMR */ {"AFML", NULL, "FM Stereo In"}, {"AFMR", NULL, "FM Stereo In"}, + + /* AUXL/R output to FM transmitter */ + {"FM Stereo Out", NULL, "AUXL"}, + {"FM Stereo Out", NULL, "AUXR"}, + + /* Vibra outputs */ + {"Vibrators", NULL, "VIBRAL"}, + {"Vibrators", NULL, "VIBRAR"}, };
static const struct snd_soc_dapm_route panda_audio_map[] = {
On Wed, Dec 14, 2011 at 11:47:02AM +0200, Peter Ujfalusi wrote:
AUXL/R: connected to FM transmitter on SDP4430 Vibra: connected to vibrator drivers (only SDP4430)
This is an example of the sort of thing I was talking about with the platform data - if someone does a variant of SDP4430 with the FM transmitter removed they'd have to add a completely new board definition.
On Wed, 2011-12-14 at 11:46 +0200, Peter Ujfalusi wrote:
Hello,
the following series will add ASoC support for PandaBoards. PandaBoards have different audio routings compared to SDP4430/Blaze boards, but the differences not that big to justify a new ASoC machine driver.
Main changes:
- Rename the sdp4430 ASoC machine driver to use generic name: omap-abe-twl6040
- Convert the ASoC machine driver to platform driver
- The type of the board, and the desired sound card name is passed via platform data to the ASoC machine driver
- Based on the board type the driver selects different audio routings
- Registration of the needed platform devices in board files (sdp4403, panda)
After this series the sound card names will be different for easier UCM integration: "OMAP4-SDP4430" for SDP4430/Blaze boards "OMAP4-Panda" for PandaBoard 4430 "OMAP4-PandaES" for PandaBoard ES (4460)
1,2,3 Applied.
5 & 8 depend on the others so best to resend with Acks if unchanged.
Thanks
Liam
participants (4)
-
Liam Girdwood -
Mark Brown -
Peter Ujfalusi -
Tony Lindgren