[alsa-devel] [PATCH 2.6.37-rc1] ASoC: OMAP: fix OMAP1 compilation problem

Tony Lindgren tony at atomide.com
Thu Nov 25 00:35:11 CET 2010

* Jarkko Nikula <jhnikula at gmail.com> [101122 23:16]:
> On Mon, 22 Nov 2010 17:48:24 -0700 (MST)
> Paul Walmsley <paul at pwsan.com> wrote:
> > > Signed-off-by: Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>
> > 
> > Thanks for fixing this.  What do you think about the following patch 
> > instead?  It should avoid any compiler issues.
> > 
> Hmm.. looks like Janusz's patch is still in Liam's for-2.6.37
> branch only.
> > +/*
> > + * The following functions are only required on an OMAP1-only build.
> > + * mach-omap2/mcbsp.c contains the real functions
> > + */
> > +int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
> > +{
> Would that create a new problem if we are able to compile some day
> omap1 and omap2 support into same kernel? I agree with you that passing
> these via platform_data sounds the right solution.

This should not be a problem because there's no ifdef else and
in that case the functions would be there.

In general, the way to avoid problems like this is to make all
code under drivers arch independent and pass the platform data
from arch specific code.

In this case the ASoC platform data should be passed from
arch/arm/*omap*/ board-*.c files to make the drivers generic.

We are going to get rid of cpu_is_omapxxxx macros in the drivers,
so please consider this when patching the ASoC drivers.

Anyways, Paul's patch should be merged during the -rc cycle
because it is currently blocking Amstrad delta being built:


Acked-by: Tony Lindgren <tony at atomide.com>

More information about the Alsa-devel mailing list