* Tony Lindgren [off-list ref] [121026 10:57]:

quoted

* Arnd Bergmann [off-list ref] [121026 10:30]:

quoted

Well, once CONFIG_MULTIPLATFORM gets enabled, the mach/*.h files are
not visible to drivers any more, but they are still visible to files
in plat-omap if you add a line like

ccflags-$(CONFIG_ARCH_OMAP2) := -I$(srctree)/arch/arm/mach-omap2/include
ccflags-$(CONFIG_ARCH_OMAP1) := -I$(srctree)/arch/arm/mach-omap1/include

to arch/arm/plat-omap/Makefile. That is how the other multiplatform
Makefiles do it. If a driver writer really wants to cheat, they can of
course do the same thing in their directory, but they can also do
#include "../../../../arch/arm/mach-omap2/foo.h"

OK thanks for clarifying that. Sounds like that can be used to
fix up the relative includes for plat-omap. I'll do some patches
for that after we have the #include <plat/*.h> and #include <mach/*.h>
issue sorted out.

Here's a patch for that. It's against what I have queued up in
omap-for-v3.8/cleanup-headers. Does that look OK to you?

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Fri, 26 Oct 2012 15:06:40 -0700
Subject: [PATCH] ARM: OMAP: Fix relative includes for plat-omap with ccflags

As suggested by Arnd Bergmann [off-list ref], we can keep
these headers local to arch/arm/*omap*/ by modifying the
ccflags in plat/omap/Makefile.

Note that eventually even most of these will go away
as things like SRAM and PRCM become just regular device
drivers.

Also note that this will not fix plat/cpu.h, but that
will be removed anyways as soon as the drivers are
fixed.

While at it, also sort the includes the standard way.

Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index cd169c3..03b1e80 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile

@@ -2,6 +2,8 @@
 # Makefile for the linux kernel.
 #
 
+ccflags-$(CONFIG_ARCH_OMAP) := -I$(srctree)/arch/arm
+