soc/sh: Fix I2C dependency for SND_FSI_AK4642

From: Peter Huewe <[email protected]>

The config option SND_FSI_AK4642 selects SND_SOC_AK464 which in turn enables the compilation of ak4642.c - however this codec uses I2C to communicate with the HW.

Consequently when I2C is not set, the compilation fails [1]

This patch fixes this issues.

---
References:
[1] http://kisskb.ellerman.id.au/kisskb/buildresult/2709408/
KernelVersion: linux-next 20100614

 sound/soc/sh/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

index a1d14bc..d26b815 100644
@@ -50,6 +50,7 @@ config SND_FSI_AK4642
 	bool "FSI-AK4642 sound support"
 	depends on SND_SOC_SH4_FSI
 	select SND_SOC_AK4642
+	select I2C
 	help
 	  This option enables generic sound support for the
 	  FSI - AK4642 unit

1.6.4.4

Am Montag 14 Juni 2010 18:10:34 schrieb Mark Brown:

Thanks for pointing this out - I had also a closer look at the codecs and the other FSI related codec (da7210.c) depends on I2C too.

So maybe even move the dependency up to SND_SOC_SH4_FSI since both codecs rely on I2C?

So something like this would be more appropriate?
config SND_SOC_SH4_FSI
tristate "SH4 FSI support"
+ depends on CONFIG_I2C_SH_MOBILE
help
This option enables FSI sound support

If you think this patch sounds correct, I can create a new 'official' patch.

Peter

No, while the two boards in mainline currently may need I2C obviously other board designs with other control interfaces are possible so it should be on the individual boards.

From: Peter Huewe <[email protected]>

The config option SND_FSI_AK4642 selects SND_SOC_AK4642 which in turn enables the compilation of ak4642.c - however this codec uses I2C to communicate with the HW.
Same applies to DA7210.

Consequently when I2C is not set, the compilation fails [1]

This patch fixes this issues, by adding a depencdency on the related HW- controller.

---
How about this one?

References:
[1] http://kisskb.ellerman.id.au/kisskb/buildresult/2709408/
KernelVersion: linux-next 20100615

 sound/soc/sh/Kconfig |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

index a1d14bc..52d7e8e 100644
@@ -48,7 +48,7 @@ config SND_SH7760_AC97
 
 config SND_FSI_AK4642
 	bool "FSI-AK4642 sound support"
-	depends on SND_SOC_SH4_FSI
+	depends on SND_SOC_SH4_FSI && I2C_SH_MOBILE
 	select SND_SOC_AK4642
 	help
 	  This option enables generic sound support for the

@@ -56,7 +56,7 @@ config SND_FSI_AK4642
 
 config SND_FSI_DA7210
 	bool "FSI-DA7210 sound support"
-	depends on SND_SOC_SH4_FSI
+	depends on SND_SOC_SH4_FSI && I2C_SH_MOBILE
 	select SND_SOC_DA7210
 	help
 	  This option enables generic sound support for the

1.6.4.4

It uses I2C, but it doesn't matter which I2C master it's interfaced with. A simple depends on I2C will suffice for this purpose just fine.

Since these are board specific drivers they know which I2C controller they are hooked up to and so can usefully depend on a specific controller - without the correct controller driver they will not function.

I don't really mind one way or the other. Having it depend on the controller is fine, but it's not really much of a stretch to expect it to show up on other boards with other controllers as well.

Very few SH CPUs use the same controller, so in this case it's really more the exception than the norm. As soon as another board takes up one of these blocks then we're forced to either switch to an I2C depends or start making a dependency list for multiple controllers. It's the desire to avoid the latter why I generally prefer the former, but again, I'm fairly impartial regardless.

This is the driver for the board itself and its wiring - it's not a chip driver, it's the driver that says how the chips on a given board are connected. For new boards I'd expect you'd end up with a new driver.

Applied, thanks.