* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [121217 01:33]:
> On 2012-12-16 22:03, Tony Lindgren wrote:
> > Looks like we missed plat-omap/fb.c for cpu_is_omap usage
> > mach-omap2. This is the last user of cpu_is_omap, so let's
> > quickly fix it up so we can finally remove plat/cpu.h for
> > omap2lus.
> >
> > We want to limit cpu_is_omap macro usage to mach-omap2 only so
> > we can make plat/cpu.h private. After this we can finally drop
> > plat/cpu.h for omap2+.
> >
> > Cc: Tomi Valkeinen <tomi.valkeinen@xxxxxx>
> > Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
> > ---
> > arch/arm/mach-omap1/Makefile | 2 +
> > arch/arm/mach-omap1/fb.c | 80 ++++++++++++++++++++++++++++++++++++++++++
> > arch/arm/mach-omap2/Makefile | 2 +
> > arch/arm/mach-omap2/fb.c | 50 +-------------------------
> > arch/arm/plat-omap/Makefile | 2 +
> > 5 files changed, 85 insertions(+), 51 deletions(-)
> > create mode 100644 arch/arm/mach-omap1/fb.c
> > rename arch/arm/{plat-omap/fb.c => mach-omap2/fb.c} (76%)
>
> Ok, I didn't realize that plat-omap cannot refer to cpu_is_omap either.
We could, but I'd rather not as what we have left in plat-omap should
all be just drivers eventually. And in this case the fb code is already
completely separate for omap1 and omap2+, so it's better just to split
it up. It makes fixing up the initcalls for omap2+ multiplatform easier
when booting on other SoCs than omap.
> The patch looks fine, except the subject should say "split fb.c", not
> "split vrfb.c".
Thanks I'll update the subject.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
