On Mon, 2011-01-17 at 13:56 +0000, ext Mark Brown wrote:
On Mon, Jan 17, 2011 at 10:52:26AM +0200, Matti J. Aaltonen wrote:
On Fri, 2011-01-14 at 12:22 +0000, ext Mark Brown wrote:
help Normally ASoC codec drivers are only built if a machine driver which uses them is also built since they are only usable with a machine driver. Selecting this option will allow these drivers to be built without an explicit machine driver for test and development purposes.
I'm not entirely clear how that follows from the above? The issue here is primarily in terms of test building with SND_SOC_ALL_CODECS.
Would you be happy with the following change?
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 937517a..c2b39fa 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -43,7 +43,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TWL6040 if TWL4030_CORE select SND_SOC_UDA134X select SND_SOC_UDA1380 if I2C - select SND_SOC_WL1273 if RADIO_WL1273 + select SND_SOC_WL1273 select SND_SOC_WM2000 if I2C select SND_SOC_WM8350 if MFD_WM8350 select SND_SOC_WM8400 if MFD_WM8400
That way the compilation of the codec would be independent of the rest of the driver...
And as I said, with my original design the core (MFD) could have been compiled (and used) with either child driver: the codec and the V4L2 part. A fact is that Mauro didn't accept that structure, he wanted to have all functionality (except for the audio) in the V4L2 driver.
I don't particularly care if the resulting driver is useful but it should at least be possible to build the two subsystems independantly. If it's not even possible to do that then why is there a MFD driver in the first place?
After I had to break the original design of functional core with add-on interfaces, I have also started question things... But actually I didn't remember the above Kconfic dependence to the V4L2 driver (I was mainly thinking about building a codec that can in some sense be run)...
And also the question is: what should be done now or next. If you mean that the dependence between V4L2 part and the core should be removed, that's easy to do but what's we gain with that? I would like to return to the original structure, but that doesn't seem to be possible?
It means we'd be able to get build coverage of each subsystem without having to enable the other, having to pick up only the core rather than an entire new subsystem.
With above change you only need to have the core header file in place and then the codec can be compiled.