[alsa-devel] Tegra ASoC, multiple boards, platform data, and conditionals in machine driver

[Stephen Warren]

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
> 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.

-- 
nvpublic