[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120917203233.GW4521@atomide.com>
Date: Mon, 17 Sep 2012 13:32:33 -0700
From: Tony Lindgren <tony@...mide.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Olof Johansson <olof@...om.net>,
linux-arm-kernel@...ts.infradead.org, linux-next@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the final tree
(arm-soc tree related)
* Tony Lindgren <tony@...mide.com> [120917 10:25]:
> * Arnd Bergmann <arnd@...db.de> [120917 07:30]:
> >
> > If it requires plat/cpu.h, it should actually be limited to CONFIG_ARCH_OMAP,
> > otherwise we will get the same problem on non-OMAP ARM builds. From what
> > I can tell, the problem is the clocks_init function, which is the only
> > part that is not completely generic.
> >
> > The trivial workaround would be to enclose the "#include <plat/cpu.h>"
> > statement in #ifdef CONFIG_ARCH_OMAP, but with the common clock code
> > in place, we should probably be able to come up with a better solution
> > that works independent of the omap platform.
>
> There are patches coming to remove cpu_is_omap usage from drivers,
> and until then we should just ifdef the plat/cpu.h include.
>
> It is possible to use these kind of external PM chips with other
> SoCs, they're just not omap related and that's why there drivers
> have not had the Kconfig dependency. I'll post a patch for that.
Looks like we can just remove the cpu_is_omap code with clock
aliases, patch posted with Subject:
[PATCH] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists