Message ID | 20121019023300.GN30550@atomide.com |
---|---|
State | New |
Headers | show |
On Friday 19 October 2012, Tony Lindgren wrote: > Hi Arnd & Olof, > > Here's the first set of omap plat header removal for v3.8 merge > window. I have at least one more related set coming, but I wanted > to get these into linux next before driver patches add more > things for me to chase down and fix. > > Oh, forgot to mention in the tag that the increase in diffstat > is mostly because plat-omap/clock shared clock code is duplicated > as that's also needed for the common clock framework patches > coming up. Hi Tony, This is very cool, great work! I'm sorry for taking so long before we processed them, I wasn't coordinating well with Olof for the last week. I've applied all of it to a new next/headers branch. I thought about using the next/cleanup branch, but since it touches a lot of files outside of arch/arm, I decided to keep it separate. We might decide to merge it later after all. I tried running my old multiplatform scripts again and have a few comments, but none of them serious: $ git grep include.*mach-omap2 arch/arm/plat-omap/debug-devices.c:#include "../mach-omap2/debug-devices.h" arch/arm/plat-omap/dma.c:#include "../mach-omap2/soc.h" arch/arm/plat-omap/dmtimer.c:#include "../mach-omap2/omap-pm.h" arch/arm/plat-omap/i2c.c:#include "../mach-omap2/soc.h" arch/arm/plat-omap/include/plat/cpu.h:#include "../../mach-omap2/soc.h" arch/arm/plat-omap/omap-pm-noop.c:#include "../mach-omap2/omap_device.h" arch/arm/plat-omap/omap-pm-noop.c:#include "../mach-omap2/omap-pm.h" arch/arm/plat-omap/sram.c:#include "../mach-omap2/soc.h" arch/arm/plat-omap/sram.c:#include "../mach-omap2/iomap.h" arch/arm/plat-omap/sram.c:#include "../mach-omap2/prm2xxx_3xxx.h" arch/arm/plat-omap/sram.c:#include "../mach-omap2/sdrc.h" I don't like the relative include paths too much. I would have preferred adding the mach-omap2/include/mach path in the plat-omap Makefile, but I suppose you want to leave it like it is now since you mention you have already built on top of it. drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/powerdomain.h> drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/clockdomain.h> drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/cm2xxx_3xxx.h> drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/prm-regbits-34xx.h> drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/cm-regbits-34xx.h> drivers/staging/tidspbridge/core/tiomap3430_pwr.c:#include <mach-omap2/prm-regbits-34xx.h> drivers/staging/tidspbridge/core/tiomap3430_pwr.c:#include <mach-omap2/cm-regbits-34xx.h> drivers/staging/tidspbridge/rmgr/drv_interface.c:#include <mach-omap2/omap3-opp.h> This code is broken now. I wonder whether it's time to remove it from staging since we now have rpmsg/remoteproc, rather than getting it to compile again. sound/soc/omap/am3517evm.c:#include <mach-omap2/hardware.h> sound/soc/omap/am3517evm.c:#include <mach-omap2/gpio.h> sound/soc/omap/ams-delta.c:#include <mach-omap2/board-ams-delta.h> sound/soc/omap/n810.c:#include <mach-omap2/hardware.h> sound/soc/omap/sdp3430.c:#include <mach-omap2/hardware.h> sound/soc/omap/sdp3430.c:#include <mach-omap2/gpio.h> sound/soc/omap/zoom2.c:#include <mach-omap2/hardware.h> sound/soc/omap/zoom2.c:#include <mach-omap2/gpio.h> sound/soc/omap/zoom2.c:#include <mach-omap2/board-zoom.h> Not sure if you were just missing these or if you already have other patch lined up for them. $ git grep include.*mach-omap1 drivers/video/omap/lcd_ams_delta.c:#include <mach-omap1/board-ams-delta.h> drivers/video/omap/lcd_inn1510.c:#include <mach-omap1/hardware.h> drivers/video/omap/lcd_osk.c:#include <mach-omap1/mux.h> drivers/video/omap/lcdc.c:#include <mach-omap1/lcdc.h> sound/soc/omap/osk5912.c:#include <mach-omap1/hardware.h> Same thing here. Arnd
* Arnd Bergmann <arnd@arndb.de> [121026 07:04]: > On Friday 19 October 2012, Tony Lindgren wrote: > > Hi Arnd & Olof, > > > > Here's the first set of omap plat header removal for v3.8 merge > > window. I have at least one more related set coming, but I wanted > > to get these into linux next before driver patches add more > > things for me to chase down and fix. > > > > Oh, forgot to mention in the tag that the increase in diffstat > > is mostly because plat-omap/clock shared clock code is duplicated > > as that's also needed for the common clock framework patches > > coming up. > > Hi Tony, > > This is very cool, great work! I'm sorry for taking so long before > we processed them, I wasn't coordinating well with Olof for the last > week. > > I've applied all of it to a new next/headers branch. I thought about > using the next/cleanup branch, but since it touches a lot of files > outside of arch/arm, I decided to keep it separate. We might decide > to merge it later after all. OK thanks, yes it's OK to keep it separate as I have few more pull requests coming to this as I get acks. It should all merge fine with other branches, let me know if that's not the case. > I tried running my old multiplatform scripts again and have a few > comments, but none of them serious: > > $ git grep include.*mach-omap2 > arch/arm/plat-omap/debug-devices.c:#include "../mach-omap2/debug-devices.h" > arch/arm/plat-omap/dma.c:#include "../mach-omap2/soc.h" > arch/arm/plat-omap/dmtimer.c:#include "../mach-omap2/omap-pm.h" > arch/arm/plat-omap/i2c.c:#include "../mach-omap2/soc.h" > arch/arm/plat-omap/include/plat/cpu.h:#include "../../mach-omap2/soc.h" > arch/arm/plat-omap/omap-pm-noop.c:#include "../mach-omap2/omap_device.h" > arch/arm/plat-omap/omap-pm-noop.c:#include "../mach-omap2/omap-pm.h" > arch/arm/plat-omap/sram.c:#include "../mach-omap2/soc.h" > arch/arm/plat-omap/sram.c:#include "../mach-omap2/iomap.h" > arch/arm/plat-omap/sram.c:#include "../mach-omap2/prm2xxx_3xxx.h" > arch/arm/plat-omap/sram.c:#include "../mach-omap2/sdrc.h" > > I don't like the relative include paths too much. I would have preferred > adding the mach-omap2/include/mach path in the plat-omap Makefile, but > I suppose you want to leave it like it is now since you mention you > have already built on top of it. Well I wanted to keep them local to arch/arm/*omap*/ directories, and not have them exposed at all for drivers. Other than that I don't have an issue using non-relative paths, except mach-omap2/include/mach traditionally has been exposed to drivers as the legacy #include <mach/*.h>, so IMHO local headers in the arch/arm/*omap*/ directories are better. But now I wonder if we can somehow have drivers not be able to include these local headers? > drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/powerdomain.h> > drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/clockdomain.h> > drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/cm2xxx_3xxx.h> > drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/prm-regbits-34xx.h> > drivers/staging/tidspbridge/core/_tiomap.h:#include <mach-omap2/cm-regbits-34xx.h> > drivers/staging/tidspbridge/core/tiomap3430_pwr.c:#include <mach-omap2/prm-regbits-34xx.h> > drivers/staging/tidspbridge/core/tiomap3430_pwr.c:#include <mach-omap2/cm-regbits-34xx.h> > drivers/staging/tidspbridge/rmgr/drv_interface.c:#include <mach-omap2/omap3-opp.h> > > This code is broken now. I wonder whether it's time to remove it from > staging since we now have rpmsg/remoteproc, rather than getting it to > compile again. Oh crap, I totally missed these :( The drivers _should_not_ include these files at all. Whatever they are doing with those includes is totally wrong and a bad layering violation. If it's not fixed, then yeah, I'd say let's just remove the breaking pieces. Let's give Omar and Laurent a quick chance to fix it up before dropping it though, I've added them to cc. > sound/soc/omap/am3517evm.c:#include <mach-omap2/hardware.h> > sound/soc/omap/am3517evm.c:#include <mach-omap2/gpio.h> > sound/soc/omap/ams-delta.c:#include <mach-omap2/board-ams-delta.h> > sound/soc/omap/n810.c:#include <mach-omap2/hardware.h> > sound/soc/omap/sdp3430.c:#include <mach-omap2/hardware.h> > sound/soc/omap/sdp3430.c:#include <mach-omap2/gpio.h> > sound/soc/omap/zoom2.c:#include <mach-omap2/hardware.h> > sound/soc/omap/zoom2.c:#include <mach-omap2/gpio.h> > sound/soc/omap/zoom2.c:#include <mach-omap2/board-zoom.h> > > Not sure if you were just missing these or if you already have other > patch lined up for them. In which branch do you see the above? I'm not seeing them in v3.7-rc2, looks like all sound/soc/omap/*.c files have already been fixed up. > $ git grep include.*mach-omap1 > drivers/video/omap/lcd_ams_delta.c:#include <mach-omap1/board-ams-delta.h> > drivers/video/omap/lcd_inn1510.c:#include <mach-omap1/hardware.h> > drivers/video/omap/lcd_osk.c:#include <mach-omap1/mux.h> > drivers/video/omap/lcdc.c:#include <mach-omap1/lcdc.h> > sound/soc/omap/osk5912.c:#include <mach-omap1/hardware.h> > > Same thing here. I'm not seeing these either, you're probably looking at some experimental branch modified with your automated scripts? In any case, let's not have #include <mach-omap1/*.h> or #include <mach-omap2/*.h> includes in the drivers, they are wrong. Those headers are meant to be local, the legacy shared headers should be in #include <mach/*.h>. Whatever needs to be passed from arch/arm/*omap*/ to drivers, should be done using include/linux/platform_data/*.h files. For omap1, we might as well keep the existing ones from #include <mach/*.h> as they are until somebody wants to fix up things properly for omap1 for CONFIG_MULTIPLATFORM. Regards, Tony
On Friday 26 October 2012, Tony Lindgren wrote: > * Arnd Bergmann <arnd@arndb.de> [121026 07:04]: > > > I tried running my old multiplatform scripts again and have a few > > comments, but none of them serious: > > > > $ git grep include.*mach-omap2 > > arch/arm/plat-omap/debug-devices.c:#include "../mach-omap2/debug-devices.h" > > arch/arm/plat-omap/dma.c:#include "../mach-omap2/soc.h" > > arch/arm/plat-omap/dmtimer.c:#include "../mach-omap2/omap-pm.h" > > arch/arm/plat-omap/i2c.c:#include "../mach-omap2/soc.h" > > arch/arm/plat-omap/include/plat/cpu.h:#include "../../mach-omap2/soc.h" > > arch/arm/plat-omap/omap-pm-noop.c:#include "../mach-omap2/omap_device.h" > > arch/arm/plat-omap/omap-pm-noop.c:#include "../mach-omap2/omap-pm.h" > > arch/arm/plat-omap/sram.c:#include "../mach-omap2/soc.h" > > arch/arm/plat-omap/sram.c:#include "../mach-omap2/iomap.h" > > arch/arm/plat-omap/sram.c:#include "../mach-omap2/prm2xxx_3xxx.h" > > arch/arm/plat-omap/sram.c:#include "../mach-omap2/sdrc.h" > > > > I don't like the relative include paths too much. I would have preferred > > adding the mach-omap2/include/mach path in the plat-omap Makefile, but > > I suppose you want to leave it like it is now since you mention you > > have already built on top of it. > > Well I wanted to keep them local to arch/arm/*omap*/ directories, > and not have them exposed at all for drivers. > > Other than that I don't have an issue using non-relative paths, except > mach-omap2/include/mach traditionally has been exposed to drivers > as the legacy #include <mach/*.h>, so IMHO local headers in the > arch/arm/*omap*/ directories are better. > > But now I wonder if we can somehow have drivers not be able to > include these local headers? 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" > > sound/soc/omap/am3517evm.c:#include <mach-omap2/hardware.h> > > sound/soc/omap/am3517evm.c:#include <mach-omap2/gpio.h> > > sound/soc/omap/ams-delta.c:#include <mach-omap2/board-ams-delta.h> > > sound/soc/omap/n810.c:#include <mach-omap2/hardware.h> > > sound/soc/omap/sdp3430.c:#include <mach-omap2/hardware.h> > > sound/soc/omap/sdp3430.c:#include <mach-omap2/gpio.h> > > sound/soc/omap/zoom2.c:#include <mach-omap2/hardware.h> > > sound/soc/omap/zoom2.c:#include <mach-omap2/gpio.h> > > sound/soc/omap/zoom2.c:#include <mach-omap2/board-zoom.h> > > > > Not sure if you were just missing these or if you already have other > > patch lined up for them. > > In which branch do you see the above? > > I'm not seeing them in v3.7-rc2, looks like all sound/soc/omap/*.c > files have already been fixed up. I am looking at the arm-soc for-next branch, which is based on v3.7-rc2. Note that before my script, this reads #include <mach/hardware.h> not #include <mach-omap2/hardware.h> but the effect is the same if the file is not available. > In any case, let's not have #include <mach-omap1/*.h> or > #include <mach-omap2/*.h> includes in the drivers, they are > wrong. Those headers are meant to be local, the legacy shared > headers should be in #include <mach/*.h>. Whatever needs to > be passed from arch/arm/*omap*/ to drivers, should be done > using include/linux/platform_data/*.h files. I'm not suggesting to use mach-omap2/*.h, it's just what my old script shows when hunting for platform header files that are used in device drivers. > For omap1, we might as well keep the existing ones from > #include <mach/*.h> as they are until somebody wants to fix > up things properly for omap1 for CONFIG_MULTIPLATFORM. Fair enough. Arnd
* Arnd Bergmann <arnd@arndb.de> [121026 10:30]: > On Friday 26 October 2012, Tony Lindgren wrote: > > * Arnd Bergmann <arnd@arndb.de> [121026 07:04]: > > > > > I tried running my old multiplatform scripts again and have a few > > > comments, but none of them serious: > > > > > > $ git grep include.*mach-omap2 > > > arch/arm/plat-omap/debug-devices.c:#include "../mach-omap2/debug-devices.h" > > > arch/arm/plat-omap/dma.c:#include "../mach-omap2/soc.h" > > > arch/arm/plat-omap/dmtimer.c:#include "../mach-omap2/omap-pm.h" > > > arch/arm/plat-omap/i2c.c:#include "../mach-omap2/soc.h" > > > arch/arm/plat-omap/include/plat/cpu.h:#include "../../mach-omap2/soc.h" > > > arch/arm/plat-omap/omap-pm-noop.c:#include "../mach-omap2/omap_device.h" > > > arch/arm/plat-omap/omap-pm-noop.c:#include "../mach-omap2/omap-pm.h" > > > arch/arm/plat-omap/sram.c:#include "../mach-omap2/soc.h" > > > arch/arm/plat-omap/sram.c:#include "../mach-omap2/iomap.h" > > > arch/arm/plat-omap/sram.c:#include "../mach-omap2/prm2xxx_3xxx.h" > > > arch/arm/plat-omap/sram.c:#include "../mach-omap2/sdrc.h" > > > > > > I don't like the relative include paths too much. I would have preferred > > > adding the mach-omap2/include/mach path in the plat-omap Makefile, but > > > I suppose you want to leave it like it is now since you mention you > > > have already built on top of it. > > > > Well I wanted to keep them local to arch/arm/*omap*/ directories, > > and not have them exposed at all for drivers. > > > > Other than that I don't have an issue using non-relative paths, except > > mach-omap2/include/mach traditionally has been exposed to drivers > > as the legacy #include <mach/*.h>, so IMHO local headers in the > > arch/arm/*omap*/ directories are better. > > > > But now I wonder if we can somehow have drivers not be able to > > include these local headers? > > 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. > > > sound/soc/omap/am3517evm.c:#include <mach-omap2/hardware.h> > > > sound/soc/omap/am3517evm.c:#include <mach-omap2/gpio.h> > > > sound/soc/omap/ams-delta.c:#include <mach-omap2/board-ams-delta.h> > > > sound/soc/omap/n810.c:#include <mach-omap2/hardware.h> > > > sound/soc/omap/sdp3430.c:#include <mach-omap2/hardware.h> > > > sound/soc/omap/sdp3430.c:#include <mach-omap2/gpio.h> > > > sound/soc/omap/zoom2.c:#include <mach-omap2/hardware.h> > > > sound/soc/omap/zoom2.c:#include <mach-omap2/gpio.h> > > > sound/soc/omap/zoom2.c:#include <mach-omap2/board-zoom.h> > > > > > > Not sure if you were just missing these or if you already have other > > > patch lined up for them. > > > > In which branch do you see the above? > > > > I'm not seeing them in v3.7-rc2, looks like all sound/soc/omap/*.c > > files have already been fixed up. > > I am looking at the arm-soc for-next branch, which is based on v3.7-rc2. > > Note that before my script, this reads > > #include <mach/hardware.h> > > not > > #include <mach-omap2/hardware.h> > > but the effect is the same if the file is not available. Well for omap2+, drivers should no longer include anything with #include <mach/*.h> (or #include <mach-omap2/hardware.h>) and the drivers should be fixed instead. For omap2+, mach/hardware.h is empty now. It still needs to be included for omap1, so that might require some conditional includes for the shared code between omap1 and omap2+ like sound/soc/omap/*mcbsp*.c. And that code should just be able to use platform_data for omap1, and not need hardware.h either eventually. AFAIK, all the sound/soc/omap/*.c files are almost fixed up for omap2+, so let's not change those includes in arm-soc tree as that will just cause conflicts. All the remaining #include <mach/*.h> and #include <plat/*.h> under sound/soc/omap can eventually be just removed for omap2+. For omap1, we can just leave them as they are for now. Those are the sound/soc/omap/ams-delta.c and sound/soc/omap/osk5912.c files for omap1. > > In any case, let's not have #include <mach-omap1/*.h> or > > #include <mach-omap2/*.h> includes in the drivers, they are > > wrong. Those headers are meant to be local, the legacy shared > > headers should be in #include <mach/*.h>. Whatever needs to > > be passed from arch/arm/*omap*/ to drivers, should be done > > using include/linux/platform_data/*.h files. > > I'm not suggesting to use mach-omap2/*.h, it's just what my > old script shows when hunting for platform header files that are > used in device drivers. OK makes sense :) Well we should no have any of them after v3.8 merge window except for the legacy ones for omap1. Your script found a real issue though, and that's the tidspbridge include of private headers from mach-omap2! That's something that needs to be fixed or removed to cut the dependency between core omap code and device drivers. > > For omap1, we might as well keep the existing ones from > > #include <mach/*.h> as they are until somebody wants to fix > > up things properly for omap1 for CONFIG_MULTIPLATFORM. > > Fair enough. Sounds good. Tony
On Friday 26 October 2012, Tony Lindgren wrote: > 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? Hi Tony, thanks for the quick follow-up. Using the absolute #include statements again looks good, but now there is another problem: > 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 > + This is not what I meant, I don't think we want to have the entire arch/arm/ hierarchy visible in platform directories. Instead, I thought we'd keep using the existing arch/arm/mach-$foo/include/mach directories that are currently visible to all files and make them available only to platforms that explicitly add -I$(srctree)/arch/arm/include/mach-$foo/include to their local include path. This of course requires moving all those headers back to where they just came from. Arnd
On Fri, Oct 26, 2012 at 03:38:49PM -0700, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [121026 10:57]: > > * Arnd Bergmann <arnd@arndb.de> [121026 10:30]: > > > > > > 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 <arnd@arndb.de>, 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 > + Rather than moving all the files from plat-omap/include/plat into plat-omap and then having all these totally disgusting relative includes, why don't you add to these makefiles: ccflags += -I$(srctree)/arch/arm/plat-omap/include and avoid all that include moving and all the include name fixup?
* Arnd Bergmann <arnd@arndb.de> [121027 01:11]: > On Friday 26 October 2012, Tony Lindgren wrote: > > 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? > > Hi Tony, > > thanks for the quick follow-up. Using the absolute #include statements > again looks good, but now there is another problem: > > > 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 > > + > > This is not what I meant, I don't think we want to have the entire > arch/arm/ hierarchy visible in platform directories. Instead, I thought > we'd keep using the existing arch/arm/mach-$foo/include/mach directories > that are currently visible to all files and make them available only > to platforms that explicitly add -I$(srctree)/arch/arm/include/mach-$foo/include > to their local include path. > > This of course requires moving all those headers back to where they just came > from. OK I'll take a look. Most of them should be local to mach-omap2, so it may not be that bad with the file moves. Regards, Tony
* Russell King - ARM Linux <linux@arm.linux.org.uk> [121027 02:03]: > > Rather than moving all the files from plat-omap/include/plat into plat-omap > and then having all these totally disgusting relative includes, why don't > you add to these makefiles: > > ccflags += -I$(srctree)/arch/arm/plat-omap/include > > and avoid all that include moving and all the include name fixup? I'll take a look. Most of these headers should be local, so it should not be too many files to move for plat-omap to fix this. Regards, Tony
* Tony Lindgren <tony@atomide.com> [121027 09:34]: > * Russell King - ARM Linux <linux@arm.linux.org.uk> [121027 02:03]: > > > > Rather than moving all the files from plat-omap/include/plat into plat-omap > > and then having all these totally disgusting relative includes, why don't > > you add to these makefiles: > > > > ccflags += -I$(srctree)/arch/arm/plat-omap/include > > > > and avoid all that include moving and all the include name fixup? > > I'll take a look. Most of these headers should be local, > so it should not be too many files to move for plat-omap > to fix this. Posted a series to fix the issue with relative includes as "[PATCH 00/11] Fix relative includes for omaps introduced by recent clean-up". Regards, Tony