Re: Tegra ASoC, multiple boards, platform data, and conditionals in machine driver

[Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>]

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.