Re: OMAP totally fucked?
On 3/3/2012 10:21 PM, Tony Lindgren wrote: * Russell King - ARM Linuxli...@arm.linux.org.uk [120303 12:20]: On Sat, Mar 03, 2012 at 12:34:48PM -0800, Tony Lindgren wrote: * Tony Lindgrent...@atomide.com [120303 11:56]: * Tony Lindgrent...@atomide.com [120303 11:29]: * Russell King - ARM Linuxli...@arm.linux.org.uk [120303 10:57]: Even with the full config, making oldconfig I get: OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) May I remind you of this mail from Linus: https://lkml.org/lkml/2012/1/6/354 So really this is a rather horrid mess. Hmm yes. Sounds like we need to remove the defaults and instead add them to omap2plus_defconfig. I'll do a patch to fix that. How about the following patch after we revert commit 72b026a4? That still leaves the randconfig not necessarily selecting any of ARCH_OMAP2/3/4 issue, but that can be dealt separately later on. Grr, need to look at it more.. Now it leaves out ARCH_OMAP2/3/4 when doing a make oldconfig with some existing .config file. There's also something else wrong: * * OMAP Core Type * OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) n OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) n OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) n TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) n AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) n OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) n * * OMAP Board Type * Generic OMAP2+ board (MACH_OMAP_GENERIC) [Y/?] y OMAP3 debugging peripherals (OMAP3_EMU) [N/y/?] (NEW) Enable SDRC AC timing register changes (OMAP3_SDRC_AC_TIMING) [N/y/?] (NEW) Shouldn't the last two options depend on OMAP3 stuff? Yes it should. Looks like the default n there can go too. I think the best solution is to have the board select the omap type. From user point of view there's really no need to have separate menu for selecting the omap type, selecting just the board is a bit more intuitive. Anyways, we should revert commit 72b026a4 because of the breakage it causes. And why do we have: config ARCH_OMAP2PLUS select USE_OF Do we really _need_ OF, or is it just irqdomain that's required? Let's check, maybe the irqdomain is still enough here except for MACH_OMAP_GENERIC to here. Eventually we'll be needing OF, but that's still few merge cycles away. We added that to avoid cluttering the drivers with a bunch of #ifdef CONFIG_OF as proposed by Grant and Rob... and most drivers adaptation were done having that assumption. So if we removed that today, it will be like removing the IRQDOMAIN define during the last merge window, it will break when the drivers DT adaptation will be pulled. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
On Tue, Mar 06, 2012 at 03:58:34PM +0100, Cousson, Benoit wrote: We added that to avoid cluttering the drivers with a bunch of #ifdef CONFIG_OF as proposed by Grant and Rob... and most drivers adaptation were done having that assumption. So if we removed that today, it will be like removing the IRQDOMAIN define during the last merge window, it will break when the drivers DT adaptation will be pulled. But aren't the OF interfaces stubbed out in linux/of.h when DT support is disabled? Or are you saying that we're heading for a situation where _existing_ drivers stop working when OF isn't enabled? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
On 03/03/2012 08:04 PM, Tony Lindgren wrote: Then looks like there's a mismerge with ASoC. And ASoC patch [PATCH v3 2/3] MFD: twl6040: Convert to i2c driver, and separate it from twl core that produces another build error. Looks like we also have a new section warning with ASoC changes: WARNING: arch/arm/mach-omap2/built-in.o(.text+0x14504): Section mismatch in reference from the function omap4_pmic_init() to th The function omap4_pmic_init() references the (unknown reference) __initdata (unknown). This is often because omap4_pmic_init lacks a __initdata annotation or the annotation of (unknown) is wrong. Peter, care to look if below is right resolve for the mismerge? Also can you please also fix the new section warning? I have sent a revert series (you were on the CC) to Samuel regarding to this series going via the MFD tree. I have the corrected series waiting for the event Samuel applies the reverts on his for-next branch, so we can queue the fixed patches via ASoC. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
On Tuesday 06 March 2012, Russell King - ARM Linux wrote: On Tue, Mar 06, 2012 at 03:58:34PM +0100, Cousson, Benoit wrote: We added that to avoid cluttering the drivers with a bunch of #ifdef CONFIG_OF as proposed by Grant and Rob... and most drivers adaptation were done having that assumption. So if we removed that today, it will be like removing the IRQDOMAIN define during the last merge window, it will break when the drivers DT adaptation will be pulled. But aren't the OF interfaces stubbed out in linux/of.h when DT support is disabled? Or are you saying that we're heading for a situation where existing drivers stop working when OF isn't enabled? Most of the interfaces are stubbed out, but not all. I guess it would be nice to add stubs for the remaining ones, too. More consistent as well. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Sat, Mar 03, 2012 at 01:05:21PM -0800, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [120303 09:57]:
On Saturday 03 March 2012, Tony Lindgren wrote:
Well 85631d2 builds fine, looks like now some more includes of
plat/hardware.h are now needed.Have not yet tracked down which
commit triggers the build errors. Eventually those should become
local headers too..
I've tried building arm-soc/for-next and rmk/for-next, they are both
fine, just merging the two gives me the same build errors that Russell
saw.
Adding plat/hardware.h in all files that break solves the problems,
aside from the iommu dependency for rpmsg for which Ohad has provided
a fix already that I should pull.
Here's a patch for you to the cleanup branch to fix the hardware.h
build errors.
Right, with this applied, things are better:
1. omap3430ldp allnoconfig is the first build without warnings, congrats.
2. omap4430sdp allnoconfig has a bunch of new section mismatch warnings,
a couple of compiler warnings, and builds:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x183c): Section mismatch in
reference from the function omap2_init_processor_devices() to the function
.init.text:_init_omap_device()
The function omap2_init_processor_devices() references
the function __init _init_omap_device().
This is often because omap2_init_processor_devices lacks a __init
annotation or the annotation of _init_omap_device is wrong.
Below is a fix for this one.
My compiler (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)) was
inlining these so I wasn't seeing this warning. I had to make
omap2_init_processor_devices() static to make the warning appear.
Anyways, fix is trivial, patch below.
Kevin
From d8d4a0917c731a5fd846cd846296e2b8a5f2348d Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Tue, 6 Mar 2012 11:38:01 -0800
Subject: [PATCH] ARM: OMAP2+: PM: fix section mismatch with
omap2_init_processor_devices()
Fix the below warning by making omap2_init_processor_devices() __init.
It is called by an __init function and calls only __init functions, so
it should also be init.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x183c): Section mismatch in
reference from the function omap2_init_processor_devices() to the function
.init.text:_init_omap_device()
The function omap2_init_processor_devices() references
the function __init _init_omap_device().
This is often because omap2_init_processor_devices lacks a __init
annotation or the annotation of _init_omap_device is wrong.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..d00c39e 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -49,7 +49,7 @@ static int _init_omap_device(char *name)
/*
* Build omap_devices for processors and bus.
*/
-static void omap2_init_processor_devices(void)
+static void __init omap2_init_processor_devices(void)
{
_init_omap_device(mpu);
if (omap3_has_iva())
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
* Kevin Hilman khil...@ti.com [120306 11:13]: Russell King - ARM Linux li...@arm.linux.org.uk writes: WARNING: arch/arm/mach-omap2/built-in.o(.text+0x183c): Section mismatch in reference from the function omap2_init_processor_devices() to the function .init.text:_init_omap_device() The function omap2_init_processor_devices() references the function __init _init_omap_device(). This is often because omap2_init_processor_devices lacks a __init annotation or the annotation of _init_omap_device is wrong. Below is a fix for this one. My compiler (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)) was inlining these so I wasn't seeing this warning. I had to make omap2_init_processor_devices() static to make the warning appear. Anyways, fix is trivial, patch below. Thanks, I'll add that to fixes-non-critical-part2. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
* Peter Ujfalusi peter.ujfal...@ti.com [120306 06:57]: On 03/03/2012 08:04 PM, Tony Lindgren wrote: Then looks like there's a mismerge with ASoC. And ASoC patch [PATCH v3 2/3] MFD: twl6040: Convert to i2c driver, and separate it from twl core that produces another build error. Looks like we also have a new section warning with ASoC changes: WARNING: arch/arm/mach-omap2/built-in.o(.text+0x14504): Section mismatch in reference from the function omap4_pmic_init() to th The function omap4_pmic_init() references the (unknown reference) __initdata (unknown). This is often because omap4_pmic_init lacks a __initdata annotation or the annotation of (unknown) is wrong. Peter, care to look if below is right resolve for the mismerge? Also can you please also fix the new section warning? I have sent a revert series (you were on the CC) to Samuel regarding to this series going via the MFD tree. I have the corrected series waiting for the event Samuel applies the reverts on his for-next branch, so we can queue the fixed patches via ASoC. OK thanks! Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Sat, Mar 03, 2012 at 01:05:21PM -0800, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [120303 09:57]:
On Saturday 03 March 2012, Tony Lindgren wrote:
Well 85631d2 builds fine, looks like now some more includes of
plat/hardware.h are now needed.Have not yet tracked down which
commit triggers the build errors. Eventually those should become
local headers too..
I've tried building arm-soc/for-next and rmk/for-next, they are both
fine, just merging the two gives me the same build errors that Russell
saw.
Adding plat/hardware.h in all files that break solves the problems,
aside from the iommu dependency for rpmsg for which Ohad has provided
a fix already that I should pull.
Here's a patch for you to the cleanup branch to fix the hardware.h
build errors.
Right, with this applied, things are better:
1. omap3430ldp allnoconfig is the first build without warnings, congrats.
2. omap4430sdp allnoconfig has a bunch of new section mismatch warnings,
a couple of compiler warnings, and builds:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x183c): Section mismatch in
reference from the function omap2_init_processor_devices() to the function
.init.text:_init_omap_device()
The function omap2_init_processor_devices() references
the function __init _init_omap_device().
This is often because omap2_init_processor_devices lacks a __init
annotation or the annotation of _init_omap_device is wrong.
arch/arm/mach-omap2/io.c:51: warning: 'omap24xx_io_desc' defined but not used
arch/arm/mach-omap2/omap-wakeupgen.c:181: warning: 'wakeupgen_irqmask_all'
defined but not used
And here's a fix for the wakeupgen one.
Kevin
From 9f6b1ac3b6012fdb2001dbec14ac3d72d81b50d8 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Tue, 6 Mar 2012 12:00:25 -0800
Subject: [PATCH] ARM: OMAP2+: PM: fix wakeupgen warning when hotplug disabled
When CONFIG_HOTPLUG_CPU=n, there are unused functions in wakeupgen:
arch/arm/mach-omap2/omap-wakeupgen.c:181: warning: 'wakeupgen_irqmask_all'
defined but not used
Fix this by moving all the functions only used when CONFIG_HOTPLUG_CPU=y
together and wrapping in an #ifdef.
No functional changes.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap-wakeupgen.c | 53 ++
1 file changed, 28 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index d3d8971..42cd7fb 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -43,7 +43,6 @@
static void __iomem *wakeupgen_base;
static void __iomem *sar_base;
-static DEFINE_PER_CPU(u32 [NR_REG_BANKS], irqmasks);
static DEFINE_SPINLOCK(wakeupgen_lock);
static unsigned int irq_target_cpu[NR_IRQS];
@@ -67,14 +66,6 @@ static inline void sar_writel(u32 val, u32 offset, u8 idx)
__raw_writel(val, sar_base + offset + (idx * 4));
}
-static void _wakeupgen_set_all(unsigned int cpu, unsigned int reg)
-{
- u8 i;
-
- for (i = 0; i NR_REG_BANKS; i++)
- wakeupgen_writel(reg, i, cpu);
-}
-
static inline int _wakeupgen_get_irq_info(u32 irq, u32 *bit_posn, u8
*reg_index)
{
unsigned int spi_irq;
@@ -130,22 +121,6 @@ static void _wakeupgen_set(unsigned int irq, unsigned int
cpu)
wakeupgen_writel(val, i, cpu);
}
-static void _wakeupgen_save_masks(unsigned int cpu)
-{
- u8 i;
-
- for (i = 0; i NR_REG_BANKS; i++)
- per_cpu(irqmasks, cpu)[i] = wakeupgen_readl(i, cpu);
-}
-
-static void _wakeupgen_restore_masks(unsigned int cpu)
-{
- u8 i;
-
- for (i = 0; i NR_REG_BANKS; i++)
- wakeupgen_writel(per_cpu(irqmasks, cpu)[i], i, cpu);
-}
-
/*
* Architecture specific Mask extension
*/
@@ -170,6 +145,33 @@ static void wakeupgen_unmask(struct irq_data *d)
spin_unlock_irqrestore(wakeupgen_lock, flags);
}
+#ifdef CONFIG_HOTPLUG_CPU
+static DEFINE_PER_CPU(u32 [NR_REG_BANKS], irqmasks);
+
+static void _wakeupgen_save_masks(unsigned int cpu)
+{
+ u8 i;
+
+ for (i = 0; i NR_REG_BANKS; i++)
+ per_cpu(irqmasks, cpu)[i] = wakeupgen_readl(i, cpu);
+}
+
+static void _wakeupgen_restore_masks(unsigned int cpu)
+{
+ u8 i;
+
+ for (i = 0; i NR_REG_BANKS; i++)
+ wakeupgen_writel(per_cpu(irqmasks, cpu)[i], i, cpu);
+}
+
+static void _wakeupgen_set_all(unsigned int cpu, unsigned int reg)
+{
+ u8 i;
+
+ for (i = 0; i NR_REG_BANKS; i++)
+ wakeupgen_writel(reg, i, cpu);
+}
+
/*
* Mask or unmask all interrupts on given CPU.
* 0 = Mask all interrupts on the 'cpu'
@@ -191,6 +193,7 @@ static void wakeupgen_irqmask_all(unsigned int cpu,
unsigned int set)
}
spin_unlock_irqrestore(wakeupgen_lock, flags);
}
+#endif
#ifdef CONFIG_CPU_PM
Re: OMAP totally fucked?
* Kevin Hilman khil...@ti.com [120306 11:43]: Russell King - ARM Linux li...@arm.linux.org.uk writes: arch/arm/mach-omap2/io.c:51: warning: 'omap24xx_io_desc' defined but not used arch/arm/mach-omap2/omap-wakeupgen.c:181: warning: 'wakeupgen_irqmask_all' defined but not used And here's a fix for the wakeupgen one. Thanks, applying into fixes-non-critical-part2. Also posted a fix for the omap24xx_io_desc warning. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
* Russell King - ARM Linux li...@arm.linux.org.uk [120304 07:27]: On Sat, Mar 03, 2012 at 01:05:21PM -0800, Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [120303 09:57]: On Saturday 03 March 2012, Tony Lindgren wrote: Well 85631d2 builds fine, looks like now some more includes of plat/hardware.h are now needed.Have not yet tracked down which commit triggers the build errors. Eventually those should become local headers too.. I've tried building arm-soc/for-next and rmk/for-next, they are both fine, just merging the two gives me the same build errors that Russell saw. Adding plat/hardware.h in all files that break solves the problems, aside from the iommu dependency for rpmsg for which Ohad has provided a fix already that I should pull. Here's a patch for you to the cleanup branch to fix the hardware.h build errors. Right, with this applied, things are better: 1. omap3430ldp allnoconfig is the first build without warnings, congrats. 2. omap4430sdp allnoconfig has a bunch of new section mismatch warnings, a couple of compiler warnings, and builds: WARNING: arch/arm/mach-omap2/built-in.o(.text+0x183c): Section mismatch in reference from the function omap2_init_processor_devices() to the function .init.text:_init_omap_device() The function omap2_init_processor_devices() references the function __init _init_omap_device(). This is often because omap2_init_processor_devices lacks a __init annotation or the annotation of _init_omap_device is wrong. arch/arm/mach-omap2/io.c:51: warning: 'omap24xx_io_desc' defined but not used arch/arm/mach-omap2/omap-wakeupgen.c:181: warning: 'wakeupgen_irqmask_all' defined but not used 3. omap4430sdp randconfig built with these omap specific warnings (exluding ones already mentioned): arch/arm/mach-omap2/board-n8x0.c:39: warning: 'slot1_cover_open' defined but not used arch/arm/mach-omap2/board-n8x0.c:40: warning: 'slot2_cover_open' defined but not used arch/arm/mach-omap2/board-n8x0.c:41: warning: 'mmc_device' defined but not used I'll do some patches to fix these warnings. and, of course, this is with these configs building OMAP2..OMAP4 because of the config. That should get fixed soon too with revert. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
On Sat, Mar 03, 2012 at 01:05:21PM -0800, Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [120303 09:57]: On Saturday 03 March 2012, Tony Lindgren wrote: Well 85631d2 builds fine, looks like now some more includes of plat/hardware.h are now needed.Have not yet tracked down which commit triggers the build errors. Eventually those should become local headers too.. I've tried building arm-soc/for-next and rmk/for-next, they are both fine, just merging the two gives me the same build errors that Russell saw. Adding plat/hardware.h in all files that break solves the problems, aside from the iommu dependency for rpmsg for which Ohad has provided a fix already that I should pull. Here's a patch for you to the cleanup branch to fix the hardware.h build errors. Right, with this applied, things are better: 1. omap3430ldp allnoconfig is the first build without warnings, congrats. 2. omap4430sdp allnoconfig has a bunch of new section mismatch warnings, a couple of compiler warnings, and builds: WARNING: arch/arm/mach-omap2/built-in.o(.text+0x183c): Section mismatch in reference from the function omap2_init_processor_devices() to the function .init.text:_init_omap_device() The function omap2_init_processor_devices() references the function __init _init_omap_device(). This is often because omap2_init_processor_devices lacks a __init annotation or the annotation of _init_omap_device is wrong. arch/arm/mach-omap2/io.c:51: warning: 'omap24xx_io_desc' defined but not used arch/arm/mach-omap2/omap-wakeupgen.c:181: warning: 'wakeupgen_irqmask_all' defined but not used 3. omap4430sdp randconfig built with these omap specific warnings (exluding ones already mentioned): arch/arm/mach-omap2/board-n8x0.c:39: warning: 'slot1_cover_open' defined but not used arch/arm/mach-omap2/board-n8x0.c:40: warning: 'slot2_cover_open' defined but not used arch/arm/mach-omap2/board-n8x0.c:41: warning: 'mmc_device' defined but not used and, of course, this is with these configs building OMAP2..OMAP4 because of the config. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP totally fucked?
There's not much more to say other than that in the subject over this level of build breakage: http://www.arm.linux.org.uk/developer/build/result.php?type=buildidx=267 http://www.arm.linux.org.uk/developer/build/result.php?type=buildidx=268 which is the result of building: commit 812108a6044b7b8978329ededb3171be89918a4f Merge: 8fe6b99 85631d2 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Fri Mar 2 09:27:55 2012 + Merge remote-tracking branch 'arm-soc' Conflicts: arch/arm/Kconfig arch/arm/mach-vexpress/Kconfig commit 8fe6b99253c69412b08cb541155791ada1ba202a Merge: 8a27184 605ade3 492f076 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Fri Mar 2 09:23:30 2012 + Merge branches 'private-fixes' and 'sa11x0-asoc' into devel-3.3 commit 85631d264c35ed7fc43fd92a9f0b0d48b6dbd839 Merge: 92601fd 76374c6 Author: Arnd Bergmann a...@arndb.de Date: Thu Mar 1 14:01:56 2012 + Merge branch 'fixes' into for-next -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
* Russell King - ARM Linux li...@arm.linux.org.uk [120303 07:15]:
There's not much more to say other than that in the subject over this
level of build breakage:
http://www.arm.linux.org.uk/developer/build/result.php?type=buildidx=267
http://www.arm.linux.org.uk/developer/build/result.php?type=buildidx=268
which is the result of building:
commit 812108a6044b7b8978329ededb3171be89918a4f
Merge: 8fe6b99 85631d2
Author: Russell King rmk+ker...@arm.linux.org.uk
Date: Fri Mar 2 09:27:55 2012 +
Merge remote-tracking branch 'arm-soc'
Conflicts:
arch/arm/Kconfig
arch/arm/mach-vexpress/Kconfig
commit 8fe6b99253c69412b08cb541155791ada1ba202a
Merge: 8a27184 605ade3 492f076
Author: Russell King rmk+ker...@arm.linux.org.uk
Date: Fri Mar 2 09:23:30 2012 +
Merge branches 'private-fixes' and 'sa11x0-asoc' into devel-3.3
commit 85631d264c35ed7fc43fd92a9f0b0d48b6dbd839
Merge: 92601fd 76374c6
Author: Arnd Bergmann a...@arndb.de
Date: Thu Mar 1 14:01:56 2012 +
Merge branch 'fixes' into for-next
Well 85631d2 builds fine, looks like now some more includes of
plat/hardware.h are now needed.Have not yet tracked down which
commit triggers the build errors. Eventually those should become
local headers too..
Then looks like there's a mismerge with ASoC. And ASoC patch
[PATCH v3 2/3] MFD: twl6040: Convert to i2c driver, and separate
it from twl core that produces another build error.
Looks like we also have a new section warning with ASoC changes:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x14504): Section mismatch in
reference from the function omap4_pmic_init() to th
The function omap4_pmic_init() references
the (unknown reference) __initdata (unknown).
This is often because omap4_pmic_init lacks a __initdata
annotation or the annotation of (unknown) is wrong.
Peter, care to look if below is right resolve for the
mismerge? Also can you please also fix the new section
warning?
Regards,
Tony
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index c1a852d..9868d5a 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -279,7 +279,7 @@ static int __init omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers)
return 0;
}
-static struct twl4030_codec_data twl6040_codec = {
+static struct twl6040_codec_data twl6040_codec = {
/* single-step ramp for headset and handsfree */
.hs_left_step = 0x0f,
.hs_right_step = 0x0f,
@@ -287,17 +287,14 @@ static struct twl4030_codec_data twl6040_codec = {
.hf_right_step = 0x1d,
};
-static struct twl4030_audio_data twl6040_audio = {
+static struct twl6040_platform_data twl6040_data = {
.codec = twl6040_codec,
.audpwron_gpio = 127,
- .naudint_irq= OMAP44XX_IRQ_SYS_2N,
.irq_base = TWL6040_CODEC_IRQ_BASE,
};
/* Panda board uses the common PMIC configuration */
-static struct twl4030_platform_data omap4_panda_twldata = {
- .audio = twl6040_audio,
-};
+static struct twl4030_platform_data omap4_panda_twldata;
/*
* Display monitor features are burnt in their EEPROM as EDID data. The EEPROM
diff --git a/arch/arm/mach-omap2/cm2xxx_3xxx.c
b/arch/arm/mach-omap2/cm2xxx_3xxx.c
index c79ed63..389f9f8 100644
--- a/arch/arm/mach-omap2/cm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/cm2xxx_3xxx.c
@@ -18,6 +18,8 @@
#include linux/err.h
#include linux/io.h
+#include plat/hardware.h
+
#include iomap.h
#include common.h
#include cm.h
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 93419de..1549c11 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -17,6 +17,7 @@
#include linux/clk.h
#include linux/io.h
+#include plat/hardware.h
#include plat/board.h
#include plat/mux.h
#include plat/clock.h
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 2fd5fd1..08e674b 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -15,6 +15,7 @@
#include linux/kernel.h
#include linux/io.h
+#include plat/hardware.h
#include plat/sdrc.h
#include iomap.h
diff --git a/arch/arm/mach-omap2/sdrc2xxx.c b/arch/arm/mach-omap2/sdrc2xxx.c
index 2c329a6..1133bb2 100644
--- a/arch/arm/mach-omap2/sdrc2xxx.c
+++ b/arch/arm/mach-omap2/sdrc2xxx.c
@@ -24,6 +24,7 @@
#include linux/clk.h
#include linux/io.h
+#include plat/hardware.h
#include plat/clock.h
#include plat/sram.h
#include plat/sdrc.h
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
On Saturday 03 March 2012, Tony Lindgren wrote: Well 85631d2 builds fine, looks like now some more includes of plat/hardware.h are now needed.Have not yet tracked down which commit triggers the build errors. Eventually those should become local headers too.. I've tried building arm-soc/for-next and rmk/for-next, they are both fine, just merging the two gives me the same build errors that Russell saw. Adding plat/hardware.h in all files that break solves the problems, aside from the iommu dependency for rpmsg for which Ohad has provided a fix already that I should pull. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
On Sat, Mar 03, 2012 at 10:04:29AM -0800, Tony Lindgren wrote: Well 85631d2 builds fine, looks like now some more includes of plat/hardware.h are now needed.Have not yet tracked down which commit triggers the build errors. Eventually those should become local headers too.. It looks like this has happened because you've made stuff far too reliant on DT. You rely on asm/irq.h in asm/prom.h. I've got rid of that, so because you're missing lots of required includes in your .c files, things are failing. And... it seems my config has started to enable all SoCs and boards for some idiotic reason... I guess this is because you're trying to make 'randconfig' just work without seeding it properly? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
* Russell King - ARM Linux li...@arm.linux.org.uk [120303 10:00]: On Sat, Mar 03, 2012 at 10:04:29AM -0800, Tony Lindgren wrote: Well 85631d2 builds fine, looks like now some more includes of plat/hardware.h are now needed.Have not yet tracked down which commit triggers the build errors. Eventually those should become local headers too.. It looks like this has happened because you've made stuff far too reliant on DT. You rely on asm/irq.h in asm/prom.h. I've got rid of that, so because you're missing lots of required includes in your .c files, things are failing. OK, well that's easy to fix. And... it seems my config has started to enable all SoCs and boards for some idiotic reason... I guess this is because you're trying to make 'randconfig' just work without seeding it properly? Hmm that sounds like a bug. A big chunk mach-omap2 randconfigs were failing because none of ARCH_OMAP2/3/4 were selected. Sounds like something goes wrong now with make defconfig with old config files, need to look into it. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
On Sat, Mar 03, 2012 at 11:01:40AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [120303 10:00]: On Sat, Mar 03, 2012 at 10:04:29AM -0800, Tony Lindgren wrote: Well 85631d2 builds fine, looks like now some more includes of plat/hardware.h are now needed.Have not yet tracked down which commit triggers the build errors. Eventually those should become local headers too.. It looks like this has happened because you've made stuff far too reliant on DT. You rely on asm/irq.h in asm/prom.h. I've got rid of that, so because you're missing lots of required includes in your .c files, things are failing. OK, well that's easy to fix. And... it seems my config has started to enable all SoCs and boards for some idiotic reason... I guess this is because you're trying to make 'randconfig' just work without seeding it properly? Hmm that sounds like a bug. A big chunk mach-omap2 randconfigs were failing because none of ARCH_OMAP2/3/4 were selected. No, it's a result of those changes. The result of adding those 'default y' statements means that a previous config created by savedefconfig will end up with those options enabled, as their default state has changed. And really, having no ARCH_OMAP2/3/4 selected by a plain randconfig is not the problem - what is the root cause is that no board type is selected, and that should be done via a seeded configuration. Even with the full config, making oldconfig I get: OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) May I remind you of this mail from Linus: https://lkml.org/lkml/2012/1/6/354 So really this is a rather horrid mess. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
* Russell King - ARM Linux li...@arm.linux.org.uk [120303 10:57]: On Sat, Mar 03, 2012 at 11:01:40AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [120303 10:00]: On Sat, Mar 03, 2012 at 10:04:29AM -0800, Tony Lindgren wrote: Well 85631d2 builds fine, looks like now some more includes of plat/hardware.h are now needed.Have not yet tracked down which commit triggers the build errors. Eventually those should become local headers too.. It looks like this has happened because you've made stuff far too reliant on DT. You rely on asm/irq.h in asm/prom.h. I've got rid of that, so because you're missing lots of required includes in your .c files, things are failing. OK, well that's easy to fix. And... it seems my config has started to enable all SoCs and boards for some idiotic reason... I guess this is because you're trying to make 'randconfig' just work without seeding it properly? Hmm that sounds like a bug. A big chunk mach-omap2 randconfigs were failing because none of ARCH_OMAP2/3/4 were selected. No, it's a result of those changes. The result of adding those 'default y' statements means that a previous config created by savedefconfig will end up with those options enabled, as their default state has changed. Right.. And really, having no ARCH_OMAP2/3/4 selected by a plain randconfig is not the problem - what is the root cause is that no board type is selected, and that should be done via a seeded configuration. Even with the full config, making oldconfig I get: OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) May I remind you of this mail from Linus: https://lkml.org/lkml/2012/1/6/354 So really this is a rather horrid mess. Hmm yes. Sounds like we need to remove the defaults and instead add them to omap2plus_defconfig. I'll do a patch to fix that. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
* Tony Lindgren t...@atomide.com [120303 11:29]: * Russell King - ARM Linux li...@arm.linux.org.uk [120303 10:57]: Even with the full config, making oldconfig I get: OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) May I remind you of this mail from Linus: https://lkml.org/lkml/2012/1/6/354 So really this is a rather horrid mess. Hmm yes. Sounds like we need to remove the defaults and instead add them to omap2plus_defconfig. I'll do a patch to fix that. How about the following patch after we revert commit 72b026a4? That still leaves the randconfig not necessarily selecting any of ARCH_OMAP2/3/4 issue, but that can be dealt separately later on. Sorry for the breakage, I guess I'm too stuck on just doing make omap2plus_defconfig and don't even have other hardware specific .config files any longer. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Sat, 3 Mar 2012 12:10:29 -0800 Subject: [PATCH] ARM: OMAP2+: Remove default y for mach-omap2/Kconfig This can make existing .config files too greedy when running make oldconfig. Further default y should not be set as pointed out by Russell King and explained by Linus Torvalds at: https://lkml.org/lkml/2012/1/6/354 Instead, let's update omap2plus_defconfig with the existing boards as this defconfig is supposed to boot on all omap2plus boards. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index d5f00d7..56084fb 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -23,6 +23,44 @@ CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_ARCH_OMAP=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y +CONFIG_MACH_OMAP_GENERIC=y +CONFIG_ARCH_OMAP2PLUS_TYPICAL=y +CONFIG_ARCH_OMAP2=y +CONFIG_ARCH_OMAP3=y +CONFIG_ARCH_OMAP4=y +CONFIG_SOC_OMAP2420=y +CONFIG_SOC_OMAP2430=y +CONFIG_SOC_OMAP3430=y +CONFIG_SOC_OMAPTI81XX=y +CONFIG_SOC_OMAPAM33XX=y +CONFIG_MACH_OMAP_H4=y +CONFIG_MACH_OMAP_APOLLON=y +CONFIG_MACH_OMAP_2430SDP=y +CONFIG_MACH_OMAP3_BEAGLE=y +CONFIG_MACH_DEVKIT8000=y +CONFIG_MACH_OMAP_LDP=y +CONFIG_MACH_OMAP3530_LV_SOM=y +CONFIG_MACH_OMAP3_TORPEDO=y +CONFIG_MACH_OVERO=y +CONFIG_MACH_OMAP3EVM=y +CONFIG_MACH_OMAP3517EVM=y +CONFIG_MACH_OMAP3_PANDORA=y +CONFIG_MACH_OMAP3_TOUCHBOOK=y +CONFIG_MACH_OMAP_3430SDP=y +CONFIG_MACH_NOKIA_N8X0=y +CONFIG_MACH_NOKIA_RM680=y +CONFIG_MACH_NOKIA_RX51=y +CONFIG_MACH_OMAP_ZOOM2=y +CONFIG_MACH_OMAP_ZOOM3=y +CONFIG_MACH_CM_T35=y +CONFIG_MACH_CM_T3517=y +CONFIG_MACH_IGEP0030=y +CONFIG_MACH_SBC3530=y +CONFIG_MACH_OMAP_3630SDP=y +CONFIG_MACH_TI8168EVM=y +CONFIG_MACH_TI8148EVM=y +CONFIG_MACH_OMAP_4430SDP=y +CONFIG_MACH_OMAP4_PANDA=y CONFIG_ARM_THUMBEE=y CONFIG_ARM_ERRATA_411920=y CONFIG_NO_HZ=y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 337f98d..1749d03 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -4,7 +4,6 @@ menu TI OMAP2/3/4 Specific Features config ARCH_OMAP2PLUS_TYPICAL bool Typical OMAP configuration - default y select AEABI select REGULATOR select PM_RUNTIME @@ -23,14 +22,12 @@ config ARCH_OMAP2PLUS_TYPICAL config ARCH_OMAP2 bool TI OMAP2 depends on ARCH_OMAP2PLUS - default y select CPU_V6 select MULTI_IRQ_HANDLER config ARCH_OMAP3 bool TI OMAP3 depends on ARCH_OMAP2PLUS - default y select CPU_V7 select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARCH_HAS_OPP @@ -40,7 +37,6 @@ config ARCH_OMAP3 config ARCH_OMAP4 bool TI OMAP4 - default y depends on ARCH_OMAP2PLUS select CACHE_L2X0 select CPU_V7 @@ -61,31 +57,26 @@ comment OMAP Core Type config SOC_OMAP2420 bool OMAP2420 support depends on ARCH_OMAP2 - default y select OMAP_DM_TIMER select ARCH_OMAP_OTG config SOC_OMAP2430 bool OMAP2430 support depends on ARCH_OMAP2 - default y select ARCH_OMAP_OTG config SOC_OMAP3430 bool OMAP3430 support depends on ARCH_OMAP3 - default y select ARCH_OMAP_OTG config SOC_OMAPTI81XX bool TI81XX support depends on ARCH_OMAP3 - default y config SOC_OMAPAM33XX bool AM33XX support depends on ARCH_OMAP3 - default y config OMAP_PACKAGE_ZAF bool @@ -118,7 +109,6 @@ config MACH_OMAP_GENERIC bool Generic OMAP2+ board depends on ARCH_OMAP2PLUS select USE_OF - default y help Support for generic TI OMAP2+ boards using Flattened Device Tree. More information at Documentation/devicetree @@ -131,45 +121,38 @@ config
Re: OMAP totally fucked?
* Tony Lindgren t...@atomide.com [120303 11:56]: * Tony Lindgren t...@atomide.com [120303 11:29]: * Russell King - ARM Linux li...@arm.linux.org.uk [120303 10:57]: Even with the full config, making oldconfig I get: OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) May I remind you of this mail from Linus: https://lkml.org/lkml/2012/1/6/354 So really this is a rather horrid mess. Hmm yes. Sounds like we need to remove the defaults and instead add them to omap2plus_defconfig. I'll do a patch to fix that. How about the following patch after we revert commit 72b026a4? That still leaves the randconfig not necessarily selecting any of ARCH_OMAP2/3/4 issue, but that can be dealt separately later on. Grr, need to look at it more.. Now it leaves out ARCH_OMAP2/3/4 when doing a make oldconfig with some existing .config file. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
On Sat, Mar 03, 2012 at 12:34:48PM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120303 11:56]: * Tony Lindgren t...@atomide.com [120303 11:29]: * Russell King - ARM Linux li...@arm.linux.org.uk [120303 10:57]: Even with the full config, making oldconfig I get: OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) May I remind you of this mail from Linus: https://lkml.org/lkml/2012/1/6/354 So really this is a rather horrid mess. Hmm yes. Sounds like we need to remove the defaults and instead add them to omap2plus_defconfig. I'll do a patch to fix that. How about the following patch after we revert commit 72b026a4? That still leaves the randconfig not necessarily selecting any of ARCH_OMAP2/3/4 issue, but that can be dealt separately later on. Grr, need to look at it more.. Now it leaves out ARCH_OMAP2/3/4 when doing a make oldconfig with some existing .config file. There's also something else wrong: * * OMAP Core Type * OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) n OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) n OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) n TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) n AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) n OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) n * * OMAP Board Type * Generic OMAP2+ board (MACH_OMAP_GENERIC) [Y/?] y OMAP3 debugging peripherals (OMAP3_EMU) [N/y/?] (NEW) Enable SDRC AC timing register changes (OMAP3_SDRC_AC_TIMING) [N/y/?] (NEW) Shouldn't the last two options depend on OMAP3 stuff? And why do we have: config ARCH_OMAP2PLUS select USE_OF Do we really _need_ OF, or is it just irqdomain that's required? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
* Arnd Bergmann a...@arndb.de [120303 09:57]: On Saturday 03 March 2012, Tony Lindgren wrote: Well 85631d2 builds fine, looks like now some more includes of plat/hardware.h are now needed.Have not yet tracked down which commit triggers the build errors. Eventually those should become local headers too.. I've tried building arm-soc/for-next and rmk/for-next, they are both fine, just merging the two gives me the same build errors that Russell saw. Adding plat/hardware.h in all files that break solves the problems, aside from the iommu dependency for rpmsg for which Ohad has provided a fix already that I should pull. Here's a patch for you to the cleanup branch to fix the hardware.h build errors. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Sat, 3 Mar 2012 09:47:45 -0800 Subject: [PATCH] ARM: OMAP2+: Fix build error after merge Commit 9890ce44 (ARM: get rid of asm/irq.h in asm/prom.h) removed include of asm/irq.h in asm/prom.h. This commit together with recent omap cleanup to remove io.h causes build breakage: arrch/arm/mach-omap2/control.c: In function 'omap3_ctrl_write_boot_mode': arch/arm/mach-omap2/control.c:238: error: 'OMAP343X_CTRL_BASE' undeclared (first use in this function) ... Fix this by including hardware.h directly where needed instead of relying on asm/irq.h in asm/prom.h. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap2/cm2xxx_3xxx.c b/arch/arm/mach-omap2/cm2xxx_3xxx.c index c79ed63..389f9f8 100644 --- a/arch/arm/mach-omap2/cm2xxx_3xxx.c +++ b/arch/arm/mach-omap2/cm2xxx_3xxx.c @@ -18,6 +18,8 @@ #include linux/err.h #include linux/io.h +#include plat/hardware.h + #include iomap.h #include common.h #include cm.h diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c index 93419de..1549c11 100644 --- a/arch/arm/mach-omap2/common.c +++ b/arch/arm/mach-omap2/common.c @@ -17,6 +17,7 @@ #include linux/clk.h #include linux/io.h +#include plat/hardware.h #include plat/board.h #include plat/mux.h #include plat/clock.h diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 2fd5fd1..08e674b 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -15,6 +15,7 @@ #include linux/kernel.h #include linux/io.h +#include plat/hardware.h #include plat/sdrc.h #include iomap.h diff --git a/arch/arm/mach-omap2/sdrc2xxx.c b/arch/arm/mach-omap2/sdrc2xxx.c index 2c329a6..1133bb2 100644 --- a/arch/arm/mach-omap2/sdrc2xxx.c +++ b/arch/arm/mach-omap2/sdrc2xxx.c @@ -24,6 +24,7 @@ #include linux/clk.h #include linux/io.h +#include plat/hardware.h #include plat/clock.h #include plat/sram.h #include plat/sdrc.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP totally fucked?
* Russell King - ARM Linux li...@arm.linux.org.uk [120303 12:20]: On Sat, Mar 03, 2012 at 12:34:48PM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120303 11:56]: * Tony Lindgren t...@atomide.com [120303 11:29]: * Russell King - ARM Linux li...@arm.linux.org.uk [120303 10:57]: Even with the full config, making oldconfig I get: OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) May I remind you of this mail from Linus: https://lkml.org/lkml/2012/1/6/354 So really this is a rather horrid mess. Hmm yes. Sounds like we need to remove the defaults and instead add them to omap2plus_defconfig. I'll do a patch to fix that. How about the following patch after we revert commit 72b026a4? That still leaves the randconfig not necessarily selecting any of ARCH_OMAP2/3/4 issue, but that can be dealt separately later on. Grr, need to look at it more.. Now it leaves out ARCH_OMAP2/3/4 when doing a make oldconfig with some existing .config file. There's also something else wrong: * * OMAP Core Type * OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) n OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) n OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) n TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) n AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) n OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) n * * OMAP Board Type * Generic OMAP2+ board (MACH_OMAP_GENERIC) [Y/?] y OMAP3 debugging peripherals (OMAP3_EMU) [N/y/?] (NEW) Enable SDRC AC timing register changes (OMAP3_SDRC_AC_TIMING) [N/y/?] (NEW) Shouldn't the last two options depend on OMAP3 stuff? Yes it should. Looks like the default n there can go too. I think the best solution is to have the board select the omap type. From user point of view there's really no need to have separate menu for selecting the omap type, selecting just the board is a bit more intuitive. Anyways, we should revert commit 72b026a4 because of the breakage it causes. And why do we have: config ARCH_OMAP2PLUS select USE_OF Do we really _need_ OF, or is it just irqdomain that's required? Let's check, maybe the irqdomain is still enough here except for MACH_OMAP_GENERIC to here. Eventually we'll be needing OF, but that's still few merge cycles away. Below is a second attempt for the Kconfig changes. Now the CONFIG_MACH_ needs to be set in your seed .config. Regards, Tony Author: Tony Lindgren t...@atomide.com Date: Sat Mar 3 12:10:29 2012 -0800 ARM: OMAP2+: Remove default y for mach-omap2/Kconfig This can make existing .config files too greedy when running make oldconfig. Further default y should not be set as pointed out by Russell King and explained by Linus Torvalds at: https://lkml.org/lkml/2012/1/6/354 Instead, let's have the selected board select the SoC it needs. And let's update omap2plus_defconfig with the existing boards as this defconfig is supposed to boot on all omap2plus boards. Note that we can also remove depends on ARCH_OMAP2PLUS as that's implied for this Kconfig file. And the default n line can go too. diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index d5f00d7..56084fb 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -23,6 +23,44 @@ CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_ARCH_OMAP=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y +CONFIG_MACH_OMAP_GENERIC=y +CONFIG_ARCH_OMAP2PLUS_TYPICAL=y +CONFIG_ARCH_OMAP2=y +CONFIG_ARCH_OMAP3=y +CONFIG_ARCH_OMAP4=y +CONFIG_SOC_OMAP2420=y +CONFIG_SOC_OMAP2430=y +CONFIG_SOC_OMAP3430=y +CONFIG_SOC_OMAPTI81XX=y +CONFIG_SOC_OMAPAM33XX=y +CONFIG_MACH_OMAP_H4=y +CONFIG_MACH_OMAP_APOLLON=y +CONFIG_MACH_OMAP_2430SDP=y +CONFIG_MACH_OMAP3_BEAGLE=y +CONFIG_MACH_DEVKIT8000=y +CONFIG_MACH_OMAP_LDP=y +CONFIG_MACH_OMAP3530_LV_SOM=y +CONFIG_MACH_OMAP3_TORPEDO=y +CONFIG_MACH_OVERO=y +CONFIG_MACH_OMAP3EVM=y +CONFIG_MACH_OMAP3517EVM=y +CONFIG_MACH_OMAP3_PANDORA=y +CONFIG_MACH_OMAP3_TOUCHBOOK=y +CONFIG_MACH_OMAP_3430SDP=y +CONFIG_MACH_NOKIA_N8X0=y +CONFIG_MACH_NOKIA_RM680=y +CONFIG_MACH_NOKIA_RX51=y +CONFIG_MACH_OMAP_ZOOM2=y +CONFIG_MACH_OMAP_ZOOM3=y +CONFIG_MACH_CM_T35=y +CONFIG_MACH_CM_T3517=y +CONFIG_MACH_IGEP0030=y +CONFIG_MACH_SBC3530=y +CONFIG_MACH_OMAP_3630SDP=y +CONFIG_MACH_TI8168EVM=y +CONFIG_MACH_TI8148EVM=y +CONFIG_MACH_OMAP_4430SDP=y +CONFIG_MACH_OMAP4_PANDA=y CONFIG_ARM_THUMBEE=y CONFIG_ARM_ERRATA_411920=y CONFIG_NO_HZ=y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 337f98d..7ea6c67 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@
Re: OMAP totally fucked?
Hi Arnd Olof, * Tony Lindgren t...@atomide.com [120303 12:49]: Anyways, we should revert commit 72b026a4 because of the breakage it causes. Correction, we should revert commit c295fb63. The above commit is wrong and only exists on my machine. Arnd Olof, can you please revert commit c295fb63 (ARM: OMAP2+: Fix multiple randconfig errors with SOC_OMAP and SOC_OMAP_NOOP) in omap/fixes-non-critical? This commit by me generates bloated .config files with make oldconfig on existing .config files. Further mach-omap2/Kconfig changes can then wait until they're properly tested.. Below is a second attempt for the Kconfig changes. Now the CONFIG_MACH_ needs to be set in your seed .config. ..as this patch needs at least one more change to add a submenu for MACH_OMAP_GENERIC to select the SoC type. Other boards should not need that, so it might be best to make it available only for MACH_OMAP_GENERIC. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
