Mark Brown wrote at Sunday, April 10, 2011 7:58 PM:
On Sun, Apr 10, 2011 at 11:18:17AM -0700, Olof Johansson wrote:
built. It also makes it harder to maintain a multiplatform kernel if configuration data is pulled in at build time instead of runtime (i.e. headers vs platform_data or similar).
Note that whatever option is chosen the configuration should be pulled in at runtime, it's purely a question of where the data table goes - do you pass the full thing through platform datra or do you just pass the machine type.
Well, I was thinking of eliminating platform data completely; the selection of the correct ASoC machine driver would be based on the name of the platform device, and the machine driver would use machine_is_*() to determine any machine-specific actions/data. So yes, at run-time, but not using runtime-determined data *tables* at all.
Olof Johansson wrote at Sunday, April 10, 2011 12:18 PM:
On Sat, Apr 9, 2011 at 7:52 PM, Stephen Warren swarren@nvidia.com wrote:
Colin, Erik, Olof,
Do you have any objections to moving arch/arm/mach-tegra/board-*.h and gpio-names.h into arch/arch/mach-tegra/include/mach so that the audio driver source can include those headers simply?
See the thread below for background.
I would prefer to use platform_data and export the information through there.
I know ASoC is in some sense an exception to the rule, but in general there should be no need for any code outside of arch/arm/mach-tegra to have to know anything about the board it is running on, drivers should be generic enough.
In the ASoC case, the whole point of the driver is to be for a specific board, or perhaps set of related/similar boards. This includes defining which CPU DMA engine and which audio codec to hook up. So there isn't really a possibility of being more generic.
Some other platforms use a lot of shared header files between platform code and drivers, and I have always found that to be very awkward to follow when reading code, especially if the same constants are defined in multiple places depending on what board is built.
The whole point of having the ASoC driver include the platform's headers was to avoid defining the same GPIO constants in multiple places.
It also makes it harder to maintain a multiplatform kernel if configuration data is pulled in at build time instead of runtime (i.e. headers vs platform_data or similar).
That's true. I was thinking this through in more detail last night, and did realize that if the ASoC driver includes <mach/board-harmony.h>, then defining what <mach/> means in a multi-SoC kernel is going to be problematic.
Perhaps the best approach is to:
* Keep a single machine driver (at least for Tegra+WM8903; as Mark noted, attempting to share any wider doesn't make sense)
* Rename the driver e.g. tegra_wm8903.c rather than harmony.c since it'll be more generic. Rename the platform data structure and header likewise.
* Expand the platform data structure used by that driver to add anything necessary for Seaboard and derivatives.
* Expand the driver to handle optional/missing GPIO definitions in the platform data (i.e. Harmony/Ventana will fill in int/ext_mic_en, and other boards will set it to -1. Only Kaen will fill in hp_mute GPIO, etc.)
That way, we can still avoid a proliferation in the number of platform headers, platform data types, and ASoC machine drivers.
Does that sound like a plan?
Thanks.