[alsa-devel] Tegra ASoC, multiple boards, platform data, and conditionals in machine driver
swarren at nvidia.com
Mon Apr 11 17:27:51 CEST 2011
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 at 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
> 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
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
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,
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?
More information about the Alsa-devel