OMAP totally fucked?

OMAP totally fucked?

[Russell King - ARM Linux]

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=build&idx=267
http://www.arm.linux.org.uk/developer/build/result.php?type=build&idx=268

which is the result of building:

commit 812108a6044b7b8978329ededb3171be89918a4f
Merge: 8fe6b99 85631d2
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Fri Mar 2 09:27:55 2012 +0000

    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+kernel@arm.linux.org.uk>
Date:   Fri Mar 2 09:23:30 2012 +0000

    Merge branches 'private-fixes' and 'sa11x0-asoc' into devel-3.3

commit 85631d264c35ed7fc43fd92a9f0b0d48b6dbd839
Merge: 92601fd 76374c6
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Mar 1 14:01:56 2012 +0000

    Merge branch 'fixes' into for-next

Re: OMAP totally fucked?

[Tony Lindgren]

* Russell King - ARM Linux <linux@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=build&idx=267
> http://www.arm.linux.org.uk/developer/build/result.php?type=build&idx=268
> 
> which is the result of building:
> 
> commit 812108a6044b7b8978329ededb3171be89918a4f
> Merge: 8fe6b99 85631d2
> Author: Russell King <rmk+kernel@arm.linux.org.uk>
> Date:   Fri Mar 2 09:27:55 2012 +0000
> 
>     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+kernel@arm.linux.org.uk>
> Date:   Fri Mar 2 09:23:30 2012 +0000
> 
>     Merge branches 'private-fixes' and 'sa11x0-asoc' into devel-3.3
> 
> commit 85631d264c35ed7fc43fd92a9f0b0d48b6dbd839
> Merge: 92601fd 76374c6
> Author: Arnd Bergmann <arnd@arndb.de>
> Date:   Thu Mar 1 14:01:56 2012 +0000
> 
>     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>

Re: OMAP totally fucked?

[Arnd Bergmann]

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

Re: OMAP totally fucked?

[Russell King - ARM Linux]

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?

Re: OMAP totally fucked?

[Tony Lindgren]

* Russell King - ARM Linux <linux@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

Re: OMAP totally fucked?

[Russell King - ARM Linux]

On Sat, Mar 03, 2012 at 11:01:40AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@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.

Re: OMAP totally fucked?

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120303 10:57]:
> On Sat, Mar 03, 2012 at 11:01:40AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@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

Re: OMAP totally fucked?

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [120303 11:29]:
> * Russell King - ARM Linux <linux@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 <tony@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 <tony@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 MACH_OMAP2_TUSB6010
 config MACH_OMAP_H4
 	bool "OMAP 2420 H4 board"
 	depends on SOC_OMAP2420
-	default y
 	select OMAP_PACKAGE_ZAF
 	select OMAP_DEBUG_DEVICES
 
 config MACH_OMAP_APOLLON
 	bool "OMAP 2420 Apollon board"
 	depends on SOC_OMAP2420
-	default y
 	select OMAP_PACKAGE_ZAC
 
 config MACH_OMAP_2430SDP
 	bool "OMAP 2430 SDP board"
 	depends on SOC_OMAP2430
-	default y
 	select OMAP_PACKAGE_ZAC
 
 config MACH_OMAP3_BEAGLE
 	bool "OMAP3 BEAGLE board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBB
 
 config MACH_DEVKIT8000
 	bool "DEVKIT8000 board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CUS
 
 config MACH_OMAP_LDP
 	bool "OMAP3 LDP board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBB
 
 config MACH_OMAP3530_LV_SOM
 	bool "OMAP3 Logic 3530 LV SOM board"
 	depends on ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
-	default y
 	help
 	 Support for the LogicPD OMAP3530 SOM Development kit
 	 for full description please see the products webpage at
@@ -179,7 +162,6 @@ config MACH_OMAP3_TORPEDO
 	bool "OMAP3 Logic 35x Torpedo board"
 	depends on ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
-	default y
 	help
 	 Support for the LogicPD OMAP35x Torpedo Development kit
 	 for full description please see the products webpage at
@@ -188,19 +170,16 @@ config MACH_OMAP3_TORPEDO
 config MACH_OVERO
 	bool "Gumstix Overo board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBB
 
 config MACH_OMAP3EVM
 	bool "OMAP 3530 EVM board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBB
 
 config MACH_OMAP3517EVM
 	bool "OMAP3517/ AM3517 EVM board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBB
 
 config MACH_CRANEBOARD
@@ -211,19 +190,16 @@ config MACH_CRANEBOARD
 config MACH_OMAP3_PANDORA
 	bool "OMAP3 Pandora"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 
 config MACH_OMAP3_TOUCHBOOK
 	bool "OMAP3 Touch Book"
 	depends on ARCH_OMAP3
-	default y
 
 config MACH_OMAP_3430SDP
 	bool "OMAP 3430 SDP board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBB
 
 config MACH_NOKIA_N800
@@ -238,7 +214,6 @@ config MACH_NOKIA_N810_WIMAX
 config MACH_NOKIA_N8X0
 	bool "Nokia N800/N810"
 	depends on SOC_OMAP2420
-	default y
 	select OMAP_PACKAGE_ZAC
 	select MACH_NOKIA_N800
 	select MACH_NOKIA_N810
@@ -247,19 +222,16 @@ config MACH_NOKIA_N8X0
 config MACH_NOKIA_RM680
 	bool "Nokia RM-680 board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBB
 
 config MACH_NOKIA_RX51
 	bool "Nokia RX-51 board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBB
 
 config MACH_OMAP_ZOOM2
 	bool "OMAP3 Zoom2 board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBB
 	select SERIAL_8250
 	select SERIAL_CORE_CONSOLE
@@ -269,7 +241,6 @@ config MACH_OMAP_ZOOM2
 config MACH_OMAP_ZOOM3
 	bool "OMAP3630 Zoom3 board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBP
 	select SERIAL_8250
 	select SERIAL_CORE_CONSOLE
@@ -279,14 +250,12 @@ config MACH_OMAP_ZOOM3
 config MACH_CM_T35
 	bool "CompuLab CM-T35/CM-T3730 modules"
 	depends on ARCH_OMAP3
-	default y
 	select MACH_CM_T3730
 	select OMAP_PACKAGE_CUS
 
 config MACH_CM_T3517
 	bool "CompuLab CM-T3517 module"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBB
 
 config MACH_CM_T3730
@@ -295,41 +264,34 @@ config MACH_CM_T3730
 config MACH_IGEP0020
 	bool "IGEP v2 board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBB
 
 config MACH_IGEP0030
 	bool "IGEP OMAP3 module"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBB
 	select MACH_IGEP0020
 
 config MACH_SBC3530
 	bool "OMAP3 SBC STALKER board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CUS
 
 config MACH_OMAP_3630SDP
 	bool "OMAP3630 SDP board"
 	depends on ARCH_OMAP3
-	default y
 	select OMAP_PACKAGE_CBP
 
 config MACH_TI8168EVM
 	bool "TI8168 Evaluation Module"
 	depends on SOC_OMAPTI81XX
-	default y
 
 config MACH_TI8148EVM
 	bool "TI8148 Evaluation Module"
 	depends on SOC_OMAPTI81XX
-	default y
 
 config MACH_OMAP_4430SDP
 	bool "OMAP 4430 SDP board"
-	default y
 	depends on ARCH_OMAP4
 	select OMAP_PACKAGE_CBL
 	select OMAP_PACKAGE_CBS
@@ -337,7 +299,6 @@ config MACH_OMAP_4430SDP
 
 config MACH_OMAP4_PANDA
 	bool "OMAP4 Panda Board"
-	default y
 	depends on ARCH_OMAP4
 	select OMAP_PACKAGE_CBL
 	select OMAP_PACKAGE_CBS

Re: OMAP totally fucked?

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [120303 11:56]:
> * Tony Lindgren <tony@atomide.com> [120303 11:29]:
> > * Russell King - ARM Linux <linux@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

Re: OMAP totally fucked?

[Russell King - ARM Linux]

On Sat, Mar 03, 2012 at 12:34:48PM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [120303 11:56]:
> > * Tony Lindgren <tony@atomide.com> [120303 11:29]:
> > > * Russell King - ARM Linux <linux@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?

Re: OMAP totally fucked?

[Tony Lindgren]

* Arnd Bergmann <arnd@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 <tony@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+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@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>

Re: OMAP totally fucked?

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120303 12:20]:
> On Sat, Mar 03, 2012 at 12:34:48PM -0800, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [120303 11:56]:
> > > * Tony Lindgren <tony@atomide.com> [120303 11:29]:
> > > > * Russell King - ARM Linux <linux@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 <tony@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
@@ -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
@@ -21,16 +20,12 @@ config ARCH_OMAP2PLUS_TYPICAL
 	  Compile a kernel suitable for booting most boards
 
 config ARCH_OMAP2
-	bool "TI OMAP2"
-	depends on ARCH_OMAP2PLUS
-	default y
+	bool
 	select CPU_V6
 	select MULTI_IRQ_HANDLER
 
 config ARCH_OMAP3
-	bool "TI OMAP3"
-	depends on ARCH_OMAP2PLUS
-	default y
+	bool
 	select CPU_V7
 	select USB_ARCH_HAS_EHCI if USB_SUPPORT
 	select ARCH_HAS_OPP
@@ -39,9 +34,7 @@ config ARCH_OMAP3
 	select MULTI_IRQ_HANDLER
 
 config ARCH_OMAP4
-	bool "TI OMAP4"
-	default y
-	depends on ARCH_OMAP2PLUS
+	bool
 	select CACHE_L2X0
 	select CPU_V7
 	select ARM_GIC
@@ -55,37 +48,29 @@ config ARCH_OMAP4
 	select USB_ARCH_HAS_EHCI if USB_SUPPORT
 	select ARM_CPU_SUSPEND if PM
 
-comment "OMAP Core Type"
-	depends on ARCH_OMAP2
-
 config SOC_OMAP2420
-	bool "OMAP2420 support"
-	depends on ARCH_OMAP2
-	default y
+	bool
+	select ARCH_OMAP2
 	select OMAP_DM_TIMER
 	select ARCH_OMAP_OTG
 
 config SOC_OMAP2430
-	bool "OMAP2430 support"
-	depends on ARCH_OMAP2
-	default y
+	bool
+	select ARCH_OMAP2
 	select ARCH_OMAP_OTG
 
 config SOC_OMAP3430
-	bool "OMAP3430 support"
-	depends on ARCH_OMAP3
-	default y
+	bool
+	select ARCH_OMAP3
 	select ARCH_OMAP_OTG
 
 config SOC_OMAPTI81XX
-	bool "TI81XX support"
-	depends on ARCH_OMAP3
-	default y
+	bool
+	select ARCH_OMAP3
 
 config SOC_OMAPAM33XX
-	bool "AM33XX support"
-	depends on ARCH_OMAP3
-	default y
+	bool
+	select ARCH_OMAP3
 
 config OMAP_PACKAGE_ZAF
        bool
@@ -112,64 +97,54 @@ config OMAP_PACKAGE_CBS
        bool
 
 comment "OMAP Board Type"
-	depends on ARCH_OMAP2PLUS
 
 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
 
 config MACH_OMAP2_TUSB6010
 	bool
-	depends on ARCH_OMAP2 && SOC_OMAP2420
+	select SOC_OMAP2420
 	default y if MACH_NOKIA_N8X0
 
 config MACH_OMAP_H4
 	bool "OMAP 2420 H4 board"
-	depends on SOC_OMAP2420
-	default y
+	select SOC_OMAP2420
 	select OMAP_PACKAGE_ZAF
 	select OMAP_DEBUG_DEVICES
 
 config MACH_OMAP_APOLLON
 	bool "OMAP 2420 Apollon board"
-	depends on SOC_OMAP2420
-	default y
+	select SOC_OMAP2420
 	select OMAP_PACKAGE_ZAC
 
 config MACH_OMAP_2430SDP
 	bool "OMAP 2430 SDP board"
-	depends on SOC_OMAP2430
-	default y
+	select SOC_OMAP2430
 	select OMAP_PACKAGE_ZAC
 
 config MACH_OMAP3_BEAGLE
 	bool "OMAP3 BEAGLE board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 
 config MACH_DEVKIT8000
 	bool "DEVKIT8000 board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CUS
 
 config MACH_OMAP_LDP
 	bool "OMAP3 LDP board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 
 config MACH_OMAP3530_LV_SOM
 	bool "OMAP3 Logic 3530 LV SOM board"
-	depends on ARCH_OMAP3
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
-	default y
 	help
 	 Support for the LogicPD OMAP3530 SOM Development kit
 	 for full description please see the products webpage at
@@ -177,9 +152,8 @@ config MACH_OMAP3530_LV_SOM
 
 config MACH_OMAP3_TORPEDO
 	bool "OMAP3 Logic 35x Torpedo board"
-	depends on ARCH_OMAP3
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
-	default y
 	help
 	 Support for the LogicPD OMAP35x Torpedo Development kit
 	 for full description please see the products webpage at
@@ -187,43 +161,37 @@ config MACH_OMAP3_TORPEDO
 
 config MACH_OVERO
 	bool "Gumstix Overo board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 
 config MACH_OMAP3EVM
 	bool "OMAP 3530 EVM board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 
 config MACH_OMAP3517EVM
 	bool "OMAP3517/ AM3517 EVM board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 
 config MACH_CRANEBOARD
 	bool "AM3517/05 CRANE board"
-	depends on ARCH_OMAP3
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 
 config MACH_OMAP3_PANDORA
 	bool "OMAP3 Pandora"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 
 config MACH_OMAP3_TOUCHBOOK
 	bool "OMAP3 Touch Book"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 
 config MACH_OMAP_3430SDP
 	bool "OMAP 3430 SDP board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 
 config MACH_NOKIA_N800
@@ -237,8 +205,7 @@ config MACH_NOKIA_N810_WIMAX
 
 config MACH_NOKIA_N8X0
 	bool "Nokia N800/N810"
-	depends on SOC_OMAP2420
-	default y
+	select SOC_OMAP2420
 	select OMAP_PACKAGE_ZAC
 	select MACH_NOKIA_N800
 	select MACH_NOKIA_N810
@@ -246,20 +213,17 @@ config MACH_NOKIA_N8X0
 
 config MACH_NOKIA_RM680
 	bool "Nokia RM-680 board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 
 config MACH_NOKIA_RX51
 	bool "Nokia RX-51 board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 
 config MACH_OMAP_ZOOM2
 	bool "OMAP3 Zoom2 board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 	select SERIAL_8250
 	select SERIAL_CORE_CONSOLE
@@ -268,8 +232,7 @@ config MACH_OMAP_ZOOM2
 
 config MACH_OMAP_ZOOM3
 	bool "OMAP3630 Zoom3 board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBP
 	select SERIAL_8250
 	select SERIAL_CORE_CONSOLE
@@ -278,15 +241,13 @@ config MACH_OMAP_ZOOM3
 
 config MACH_CM_T35
 	bool "CompuLab CM-T35/CM-T3730 modules"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select MACH_CM_T3730
 	select OMAP_PACKAGE_CUS
 
 config MACH_CM_T3517
 	bool "CompuLab CM-T3517 module"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 
 config MACH_CM_T3730
@@ -294,51 +255,43 @@ config MACH_CM_T3730
 
 config MACH_IGEP0020
 	bool "IGEP v2 board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 
 config MACH_IGEP0030
 	bool "IGEP OMAP3 module"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBB
 	select MACH_IGEP0020
 
 config MACH_SBC3530
 	bool "OMAP3 SBC STALKER board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CUS
 
 config MACH_OMAP_3630SDP
 	bool "OMAP3630 SDP board"
-	depends on ARCH_OMAP3
-	default y
+	select ARCH_OMAP3
 	select OMAP_PACKAGE_CBP
 
 config MACH_TI8168EVM
 	bool "TI8168 Evaluation Module"
-	depends on SOC_OMAPTI81XX
-	default y
+	select SOC_OMAPTI81XX
 
 config MACH_TI8148EVM
 	bool "TI8148 Evaluation Module"
-	depends on SOC_OMAPTI81XX
-	default y
+	select SOC_OMAPTI81XX
 
 config MACH_OMAP_4430SDP
 	bool "OMAP 4430 SDP board"
-	default y
-	depends on ARCH_OMAP4
+	select ARCH_OMAP4
 	select OMAP_PACKAGE_CBL
 	select OMAP_PACKAGE_CBS
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 
 config MACH_OMAP4_PANDA
 	bool "OMAP4 Panda Board"
-	default y
-	depends on ARCH_OMAP4
+	select ARCH_OMAP4
 	select OMAP_PACKAGE_CBL
 	select OMAP_PACKAGE_CBS
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
@@ -354,7 +307,6 @@ config OMAP3_EMU
 config OMAP3_SDRC_AC_TIMING
 	bool "Enable SDRC AC timing register changes"
 	depends on ARCH_OMAP3
-	default n
 	help
 	  If you know that none of your system initiators will attempt to
 	  access SDRAM during CORE DVFS, select Y here.  This should boost

Re: OMAP totally fucked?

[Tony Lindgren]

Hi Arnd & Olof,

* Tony Lindgren <tony@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

Re: OMAP totally fucked?

[Russell King - ARM Linux]

On Sat, Mar 03, 2012 at 01:05:21PM -0800, Tony Lindgren wrote:
> * Arnd Bergmann <arnd@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.

Re: OMAP totally fucked?

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120304 07:27]:
> On Sat, Mar 03, 2012 at 01:05:21PM -0800, Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@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

Re: OMAP totally fucked?

[Cousson, Benoit]

On 3/3/2012 10:21 PM, Tony Lindgren wrote:
> * Russell King - ARM Linux<linux@arm.linux.org.uk>  [120303 12:20]:
>> On Sat, Mar 03, 2012 at 12:34:48PM -0800, Tony Lindgren wrote:
>>> * Tony Lindgren<tony@atomide.com>  [120303 11:56]:
>>>> * Tony Lindgren<tony@atomide.com>  [120303 11:29]:
>>>>> * Russell King - ARM Linux<linux@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

Re: OMAP totally fucked?

[Russell King - ARM Linux]

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?

Re: OMAP totally fucked?

[Peter Ujfalusi]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP totally fucked?

[Arnd Bergmann]

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

Re: OMAP totally fucked?

[Kevin Hilman]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Sat, Mar 03, 2012 at 01:05:21PM -0800, Tony Lindgren wrote:
>> * Arnd Bergmann <arnd@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 <khilman@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+kernel@arm.linux.org.uk>
Signed-off-by: Kevin Hilman <khilman@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

Re: OMAP totally fucked?

[Tony Lindgren]

* Kevin Hilman <khilman@ti.com> [120306 11:13]:
> Russell King - ARM Linux <linux@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

Re: OMAP totally fucked?

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@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

Re: OMAP totally fucked?

[Kevin Hilman]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Sat, Mar 03, 2012 at 01:05:21PM -0800, Tony Lindgren wrote:
>> * Arnd Bergmann <arnd@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 <khilman@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+kernel@arm.linux.org.uk>
Signed-off-by: Kevin Hilman <khilman@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
 /*
-- 
1.7.9.2

Re: OMAP totally fucked?

[Tony Lindgren]

* Kevin Hilman <khilman@ti.com> [120306 11:43]:
> Russell King - ARM Linux <linux@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