ALSA: SoC: Add support for TI SDP3430

From: Misael Lopez Cruz <[email protected]>

This patch add ASoC support for TI SDP3430. It's based on Gumstix Overo SoC code by Steve Sakoman.

---
 sound/soc/omap/Kconfig   |    7 ++
 sound/soc/omap/Makefile  |    2 +
 sound/soc/omap/sdp3430.c |  152 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 161 insertions(+), 0 deletions(-)
 create mode 100644 sound/soc/omap/sdp3430.c

index d7b8939..890b1ed 100644
@@ -22,3 +22,10 @@ config SND_OMAP_SOC_OVERO
 	help
 	  Say Y if you want to add support for SoC audio on the Gumstix Overo.
 
+config SND_OMAP_SOC_SDP3430
+	tristate "SoC Audio support for Texas Instruments SDP3430"
+	depends on SND_OMAP_SOC && MACH_OMAP_3430SDP
+	select SND_OMAP_SOC_MCBSP
+	select SND_SOC_TWL4030
+	help
+	  Say Y if you want to add support for SoC audio on Texas Instruments SDP3430.

index b96b97b..c21426b 100644
@@ -8,7 +8,9 @@ obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
 # OMAP Machine Support
 snd-soc-n810-objs := n810.o
 snd-soc-overo-objs := overo.o
+snd-soc-sdp3430-objs := sdp3430.o
 
 obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o
 obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o
+obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o
 

1.5.6.3

depends also on TWL4030_CORE, yes?

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

The machine driver itself doesn't depend on TWL4030_CORE, but TWL4030 SoC codec driver does (sound/soc/codecs/Kconfig)

config SND_SOC_TWL4030
tristate
depends on TWL4030_CORE

Although that dependency is overridden by _select_ statement.

What should be the best way to handle this dependency? Directly in kconfig entry for each TWL4030-related machine driver? --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

No it isn't. Reverse dependencies don't work like you might expect ... even when there's no ambiguity in walking up a chain of them, *no* additional dependencies are flagged.

So as you've written it, SND_SOC_TWL4030 will be active, but not TWL4030_CORE on which it depends.

If you fix that in Kconfig, you'd make a lot of folk fairly happy ... but there'd be fun ambiguities to cope with. Example:

	config X
		select D
	config D
		depends on (A && B) || C

It's not clear whether to enable both A and B; just C; or all of them...

Probably asking the user to resolve such issues would be necessary. Coming up with all the solutions would be a bit more complex than a Prolog interpreter, since Kconfig uses tristate logic not boolean.

The least error-prone answer involves no "select" statements at all, ever. That is, least error-prone in terms of the output of Kconfig being a valid configuration ... in terms of minimizing user error, I suggest just adding the single dependency I mentioned.

- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html