[alsa-devel] [PATCH v2] ARM: Tegra: select MACH_HAS_SND_SOC_TEGRA_WM8903
CONFIG_SND_SOC_TEGRA_WM8903 is useful for many Tegra boards. To avoid the ASoC tegra/Kconfig enumerating them all, instead have the Tegra machine Kconfig select MACH_HAS_SND_SOC_TEGRA_WM8903 where appropriate, and have SND_SOC_TEGRA_WM8903 depend on this.
Signed-off-by: Stephen Warren swarren@nvidia.com --- Mark, this will need to be applied to your tegra branch so it can get merged into both trees. Thanks.
v2: s/HAS/WANT/ in Kconfig variable name. I figured a machine "HAVING" a Kconfig variable didn't make much sense. I also wondered about ALLOW/ENABLE. Still, being consistent with existing variable naming is more important that the finer details of English:-)
arch/arm/mach-tegra/Kconfig | 3 +++ sound/soc/tegra/Kconfig | 10 ++++++++-- 2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig index 3cdeffc..5ec1846 100644 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@ -27,12 +27,14 @@ comment "Tegra board type"
config MACH_HARMONY bool "Harmony board" + select MACH_HAS_SND_SOC_TEGRA_WM8903 help Support for nVidia Harmony development platform
config MACH_KAEN bool "Kaen board" select MACH_SEABOARD + select MACH_HAS_SND_SOC_TEGRA_WM8903 help Support for the Kaen version of Seaboard
@@ -43,6 +45,7 @@ config MACH_PAZ00
config MACH_SEABOARD bool "Seaboard board" + select MACH_HAS_SND_SOC_TEGRA_WM8903 help Support for nVidia Seaboard development platform. It will also be included for some of the derivative boards that diff --git a/sound/soc/tegra/Kconfig b/sound/soc/tegra/Kconfig index 14f7119..de32dfb 100644 --- a/sound/soc/tegra/Kconfig +++ b/sound/soc/tegra/Kconfig @@ -14,10 +14,16 @@ config SND_SOC_TEGRA_I2S Tegra I2S interface. You will also need to select the individual machine drivers to support below.
+config MACH_HAS_SND_SOC_TEGRA_WM8903 + bool + help + Machines that use the SND_SOC_TEGRA_WM8903 driver should select + this config option, in order to allow the user to enable + SND_SOC_TEGRA_WM8903. + config SND_SOC_TEGRA_WM8903 tristate "SoC Audio support for Tegra boards using a WM8903 codec" - depends on SND_SOC_TEGRA && I2C - depends on MACH_HARMONY || MACH_VENTANA || MACH_SEABOARD || MACH_KAEN || MACH_AEBL + depends on SND_SOC_TEGRA && I2C && MACH_HAS_SND_SOC_TEGRA_WM8903 default m select SND_SOC_TEGRA_I2S select SND_SOC_WM8903
On Tue, 2011-04-19 at 10:18 -0600, Stephen Warren wrote:
CONFIG_SND_SOC_TEGRA_WM8903 is useful for many Tegra boards. To avoid the ASoC tegra/Kconfig enumerating them all, instead have the Tegra machine Kconfig select MACH_HAS_SND_SOC_TEGRA_WM8903 where appropriate, and have SND_SOC_TEGRA_WM8903 depend on this.
Signed-off-by: Stephen Warren swarren@nvidia.com
Mark, this will need to be applied to your tegra branch so it can get merged into both trees. Thanks.
v2: s/HAS/WANT/ in Kconfig variable name. I figured a machine "HAVING" a Kconfig variable didn't make much sense. I also wondered about ALLOW/ENABLE. Still, being consistent with existing variable naming is more important that the finer details of English:-)
Acked-by: Liam Girdwood lrg@ti.com
Liam Girdwood wrote at Wednesday, April 20, 2011 5:12 AM:
On Tue, 2011-04-19 at 10:18 -0600, Stephen Warren wrote:
CONFIG_SND_SOC_TEGRA_WM8903 is useful for many Tegra boards. To avoid the ASoC tegra/Kconfig enumerating them all, instead have the Tegra machine Kconfig select MACH_HAS_SND_SOC_TEGRA_WM8903 where appropriate, and have SND_SOC_TEGRA_WM8903 depend on this.
Colin, Erik, Olof,
Does this change look OK? If so, could you please Ack it; I imagine Mark is holding off applying it until you do.
After Mark applies this, Tegra for-next needs to merge Mark's tegra branch, and a few patches I have need to be applied to enable Seaboard audio, which all needs to happen in the next couple of weeks so it's in for-next before rc6. I'll send all the details once this change is applied.
Thanks!
Signed-off-by: Stephen Warren swarren@nvidia.com
Mark, this will need to be applied to your tegra branch so it can get merged into both trees. Thanks.
v2: s/HAS/WANT/ in Kconfig variable name. I figured a machine "HAVING" a Kconfig variable didn't make much sense. I also wondered about ALLOW/ENABLE. Still, being consistent with existing variable naming is more important that the finer details of English:-)
Acked-by: Liam Girdwood lrg@ti.com
On Wed, Apr 20, 2011 at 9:40 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Wed, Apr 20, 2011 at 09:34:27AM -0700, Stephen Warren wrote:
Does this change look OK? If so, could you please Ack it; I imagine Mark is holding off applying it until you do.
I am.
Done.
-Olof
On Tue, Apr 19, 2011 at 9:18 AM, Stephen Warren swarren@nvidia.com wrote:
CONFIG_SND_SOC_TEGRA_WM8903 is useful for many Tegra boards. To avoid the ASoC tegra/Kconfig enumerating them all, instead have the Tegra machine Kconfig select MACH_HAS_SND_SOC_TEGRA_WM8903 where appropriate, and have SND_SOC_TEGRA_WM8903 depend on this.
Signed-off-by: Stephen Warren swarren@nvidia.com
Acked-by: Olof Johansson olof@lixom.net
Thanks!
-Olof
On Tue, Apr 19, 2011 at 10:18:01AM -0600, Stephen Warren wrote:
CONFIG_SND_SOC_TEGRA_WM8903 is useful for many Tegra boards. To avoid the ASoC tegra/Kconfig enumerating them all, instead have the Tegra machine Kconfig select MACH_HAS_SND_SOC_TEGRA_WM8903 where appropriate, and have SND_SOC_TEGRA_WM8903 depend on this.
Signed-off-by: Stephen Warren swarren@nvidia.com
Mark, this will need to be applied to your tegra branch so it can get merged into both trees. Thanks.
I'm fairly sure it's not been generated against that branch - it doesn't apply since the branch doesn't have the rename of the board driver. I've fixed this up but please be more careful.
Mark Brown wrote at Thursday, April 21, 2011 4:58 AM:
On Tue, Apr 19, 2011 at 10:18:01AM -0600, Stephen Warren wrote:
CONFIG_SND_SOC_TEGRA_WM8903 is useful for many Tegra boards. To avoid the ASoC tegra/Kconfig enumerating them all, instead have the Tegra machine Kconfig select MACH_HAS_SND_SOC_TEGRA_WM8903 where appropriate, and have SND_SOC_TEGRA_WM8903 depend on this.
Signed-off-by: Stephen Warren swarren@nvidia.com
Mark, this will need to be applied to your tegra branch so it can get merged into both trees. Thanks.
I'm fairly sure it's not been generated against that branch - it doesn't apply since the branch doesn't have the rename of the board driver. I've fixed this up but please be more careful.
Yes, that patch was against your for-2.6.40 branch.
I'd assumed that since there would either be:
* A conflict applying the patch. * A smooth merge of tegra into 2.6.40.
Or:
* No conflict applying the patch. * A merge conflict merging tegra into 2.6.40.
It didn't matter which way around it was. However, thinking more I was indeed wrong, since the conflicts in the initial application were more complex than I'd thought through.
I guess the correct solution would have been for a clean application to your tegra branch, then you'd be OK with the merge conflict into 2.6.40? I probably should have mentioned it in the patch either way.
Hopefully somebody Googling re: how to work cross-subsystem merges will find these posts and avoid my mistakes.
Thanks for working it out!
On Thu, Apr 21, 2011 at 09:29:30AM -0700, Stephen Warren wrote:
It didn't matter which way around it was. However, thinking more I was indeed wrong, since the conflicts in the initial application were more complex than I'd thought through.
It's not that they were complex, it's more that if you've got a patch which is advertised as being for a particular branch the general expectation is that it would actually apply to that branch.
I guess the correct solution would have been for a clean application to your tegra branch, then you'd be OK with the merge conflict into 2.6.40? I probably should have mentioned it in the patch either way.
Yes, ideally you'd also show the merge result (and possibly even publish versions of both branches after application, especially if the merge is tricky).
participants (4)
-
Liam Girdwood -
Mark Brown -
Olof Johansson -
Stephen Warren