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

[Stephen Warren]

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.

If this is OK, I'll submit the rename as part of my patch-set, and have
Mark process it through a separate branch that both the ASoC and Tegra
trees can both merge.

Thanks.

Mark Brown wrote at Friday, April 08, 2011 8:31 PM:
> 
> On Fri, Apr 08, 2011 at 12:43:37PM -0700, Stephen Warren wrote:
> 
> > That said, I noticed that all(?) the other machine drivers simply use
> > hard-coded GPIO numbers (sometimes defined locally, probably sometimes from
> > machine header files), rather than having the values passed in through
> > platform_data. This eliminates the need for platform_data structures etc.
> > Is this simply a legacy because ASoC machine drivers weren't able to be
> > first-class platform_devices, or is this still an acceptable style?
> 
> Partly due to the historical reasons, partly due to the fact that unless
> you actually have multiple boards based off the same design with
> different data there's no point in bouncing the data through platform
> data as there's only one possible answer - the hard coding also includes
> the connections between the devices, the clocking arrangements and so
> on.
> 
> > Seaboard has a couple of derivatives which are very similar, but do have
> > some differences in the audio path and elsewhere. In the ChromeOS kernel,
> > we have a single ASoC machine driver covering Seaboard and two derivatives,
> > with conditional code. I've placed an example at the end of this mail. Do
> > you have a preference for having separate files for each machine without the
> > conditional code v.s. a single machine driver with a lot of conditional code?
> > If we go the conditional route, it might even be possible to merge the
> > Harmony and Seaboard machine drivers into one.
> 
> If the machines are very similar merging the driver is good.  Your code
> looked like a good example of where merging is helpful.

-- 
nvpublic