* Tomi Valkeinen [off-list ref] [121217 01:33]:

On 2012-12-16 22:03, Tony Lindgren wrote:

quoted

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 <redacted>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 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