Record Board Configurations

See minutes from December 13, 2010 meeting for discussion on this topic, which answers the following questions.

Question from Paul E. McKenney:
Don't the current arch/arm/plat-*/Kconfig files already get this effect?
For example, arch/arm/plat-mxc/Kconfig contains config parameters selecting various Freescale boards, each of which has an arch/arm/mach-*/Kconfig file. Each of the arch/arm/mach-*/Kconfig files has an "if" statement that excludes that file should some other board be selected. For example, arch/arm/mach-mx5/Kconfig starts with an "if ARCH_MX5" statement that spans the entire file. So it appears to me that this work is already done and in mainline as of 2.6.36.
So, what am I missing?

[Jason]:Yes, 2.6.36 has support the config layout, take FSL I.MX as example,
arch/arm/plat-mxc/Kconfig will have "if ARCH_MXC", which excludes non-MXC part and include the ARCH_MXY support.
arch/arm/mach-mxy will have "if ARCH_MXy", which excludes non-MXy part and include the ARCH_MXy family SOC support and
board support config.

So, We need simply select ARCH_MXC, ARCH_MXy which should generate the basic board support config file if we can support one image for all the SOC family board. Even, we can only select ARCH_MXC if we can support one image for all i.MX series SOC board support.[Jason]

[jstultz]: Some details may not be covered by the ARCH_ options in the arch/arm/mach-*/Kconfig, such as mmc drivers or other necessary options for each board. I suspect most of these won't be exclusive to single boards, but there may be some cases where two drivers are incompatible, and the right one for the board may need to be specified.

[jstultz]: Couldn't this also be handled by Kconfig? For example, couldn't we use a configuration parameter, defined in the "mach-" file, that specifies which driver to use? Or are there examples where this does not work out well? (Just want to make sure that we use the existing Kconfig tool where it makes sense to do so.)

[jstultz]: Talking with Jason, we have worked out a way to "mostly" handle doing this via Kconfig fragments. We will likely have a per-board Kconfig fragment, and then a distro specefic Kconfig fragment, and the union of these will provide the proper config for the board. There are some limitations that were discovered by Jason:
  1) The "select" term does not select options that are part of a "choice block". This can be worked around by adding multiple "default <option> if <defconfig option>" to the choice block. Not pretty, but it will work.
  2) Select does not allow for selecting config options that take integer values rather then binary yes/no values. There is no good workaround for this, so we will likely have to modify the config language.
  3) There is no unselect option. This is probably less likely to be necessary, and can probably be worked around via a meta CONFIG_<option>_DISABLE config option which can be selected and then make the option to be deselected have a dependency on !CONFIG_<option>_DISABLE.

2011-03-02: Quick update. Now that we have a method to mostly handle processing Kconfig fragments, I'm working on splitting up the Linaro boad configs into Kconfig fragments.

2011-03-21: After splitting out the linaro configs for each board into kconfig fragments, I posted the code to linaro-dev, where the reaction was of hesitant interest. Folks wanted to see the kconfig fragment bits upstream before being adapted by Linaro. So for 11.05 I suspect the kconfig fragments won't make it into Linaro.

That said, hopefully the broken out kconfig fragments could be used help minimize the per-board config differences.

Work items:
[jstultz] Split out common distro-policy bits from each of board-defconfigs into Linaro specific kconfig fragment: DONE
[jstultz] Rewrite linaro config into kconfig fragment for OMAP/Beagle: DONE
[jstultz] Rewrite linaro config into kconfig fragment for IMX51: DONE
[jstultz] Rewrite linaro config into kconfig fragment for VEXPRESS: DONE
[jstultz] Integrate kconfig fragments into Linaro build system: POSTPONED