Current OMAP build failures

Current OMAP build failures

[Russell King - ARM Linux]

I've observed the following issues while building 2.6.37 + my devel
branch.  I don't believe any of them to be due to anything in my tree,
so would be in 2.6.37 as well.

=== omap1 ===
arch/arm/plat-omap/built-in.o: In function `omap2_i2c_add_bus':
arch/arm/plat-omap/i2c.c:169: undefined reference to `omap2_i2c_mux_pins'

$ grep omap2_i2c_mux_pins arch/arm/*omap* -r
arch/arm/mach-omap2/i2c.c:void __init omap2_i2c_mux_pins(int bus_id)
arch/arm/plat-omap/i2c.c:       omap2_i2c_mux_pins(bus_id);
arch/arm/plat-omap/include/plat/i2c.h:void __init omap2_i2c_mux_pins(int bus_id);

So, OMAP1 doesn't provide this symbol.

=== omap2 ===
arch/arm/plat-omap/devices.c:253: warning: ■omap_init_wdt■ defined but not used
arch/arm/mach-omap2/irq.c:64: warning: ■intc_context■ defined but not used
arch/arm/mach-omap2/prcm.c:122: warning: ■prcm_context■ defined but not used

Missing __maybe_unused or something else?

It also comes with three section mismatches:

WARNING: vmlinux.o(.text+0x1f4c4): Section mismatch in reference from the function omap_early_device_register() to the function .init.text:early_platform_add_devices()
The function omap_early_device_register() references
the function __init early_platform_add_devices().
This is often because omap_early_device_register lacks a __init
annotation or the annotation of early_platform_add_devices is wrong.

As early_platform_add_devices() is marked __init, so too should be
omap_early_device_register().

WARNING: vmlinux.o(.text+0x1f6bc): Section mismatch in reference from the function omap_device_build_ss() to the function .init.text:early_platform_add_devices()
The function omap_device_build_ss() references
the function __init early_platform_add_devices().
This is often because omap_device_build_ss lacks a __init
annotation or the annotation of early_platform_add_devices is wrong.

This looks like omap_early_device_register() has been inlined into
omap_device_build_ss(), and it doesn't look like it can be marked
__init.

Rather than passing an 'is_early_device' into this function, split
out the common code into a separate function which takes a function
pointer to the registration function.  Then you can have two additional
functions, one marked __init which uses omap_early_device_register()
and one not marked __init using omap_device_register().

This also means that we get the init-section type checking further up
the chain.

WARNING: vmlinux.o(.data+0x6bd4): Section mismatch in reference from the variable h4_config to the (unknown reference) .init.data:(unknown)
The variable h4_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,

Maybe it shouldn't be marked __initdata?

=== omap3 ===
WARNING: vmlinux.o(.text+0x1b780): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init()
The function sdp3430_twl_gpio_setup() references
the function __init omap2_hsmmc_init().
This is often because sdp3430_twl_gpio_setup lacks a __init
annotation or the annotation of omap2_hsmmc_init is wrong.

Missing __init on sdp3430_twl_gpio_setup ?

WARNING: vmlinux.o(.text+0x1f714): Section mismatch in reference from the function omap_early_device_register() to the function .init.text:early_platform_add_devices()
The function omap_early_device_register() references
the function __init early_platform_add_devices().
This is often because omap_early_device_register lacks a __init
annotation or the annotation of early_platform_add_devices is wrong.

As before.

WARNING: vmlinux.o(.text+0x1f90c): Section mismatch in reference from the function omap_device_build_ss() to the function .init.text:early_platform_add_devices()
The function omap_device_build_ss() references
the function __init early_platform_add_devices().
This is often because omap_device_build_ss lacks a __init
annotation or the annotation of early_platform_add_devices is wrong.

As before.

WARNING: vmlinux.o(.data+0x20670): Section mismatch in reference from the variable twl_driver to the function .init.text:twl_probe()
The variable twl_driver references
the function __init twl_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,

twl_probe shouldn't be __init ?

=== omap4 ===
Nothing apparantly new over omap3.
--
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

Current OMAP build failures

[Russell King - ARM Linux]

I've observed the following issues while building 2.6.37 + my devel
branch.  I don't believe any of them to be due to anything in my tree,
so would be in 2.6.37 as well.

=== omap1 ===
arch/arm/plat-omap/built-in.o: In function `omap2_i2c_add_bus':
arch/arm/plat-omap/i2c.c:169: undefined reference to `omap2_i2c_mux_pins'

$ grep omap2_i2c_mux_pins arch/arm/*omap* -r
arch/arm/mach-omap2/i2c.c:void __init omap2_i2c_mux_pins(int bus_id)
arch/arm/plat-omap/i2c.c:       omap2_i2c_mux_pins(bus_id);
arch/arm/plat-omap/include/plat/i2c.h:void __init omap2_i2c_mux_pins(int bus_id);

So, OMAP1 doesn't provide this symbol.

=== omap2 ===
arch/arm/plat-omap/devices.c:253: warning: ?omap_init_wdt? defined but not used
arch/arm/mach-omap2/irq.c:64: warning: ?intc_context? defined but not used
arch/arm/mach-omap2/prcm.c:122: warning: ?prcm_context? defined but not used

Missing __maybe_unused or something else?

It also comes with three section mismatches:

WARNING: vmlinux.o(.text+0x1f4c4): Section mismatch in reference from the function omap_early_device_register() to the function .init.text:early_platform_add_devices()
The function omap_early_device_register() references
the function __init early_platform_add_devices().
This is often because omap_early_device_register lacks a __init
annotation or the annotation of early_platform_add_devices is wrong.

As early_platform_add_devices() is marked __init, so too should be
omap_early_device_register().

WARNING: vmlinux.o(.text+0x1f6bc): Section mismatch in reference from the function omap_device_build_ss() to the function .init.text:early_platform_add_devices()
The function omap_device_build_ss() references
the function __init early_platform_add_devices().
This is often because omap_device_build_ss lacks a __init
annotation or the annotation of early_platform_add_devices is wrong.

This looks like omap_early_device_register() has been inlined into
omap_device_build_ss(), and it doesn't look like it can be marked
__init.

Rather than passing an 'is_early_device' into this function, split
out the common code into a separate function which takes a function
pointer to the registration function.  Then you can have two additional
functions, one marked __init which uses omap_early_device_register()
and one not marked __init using omap_device_register().

This also means that we get the init-section type checking further up
the chain.

WARNING: vmlinux.o(.data+0x6bd4): Section mismatch in reference from the variable h4_config to the (unknown reference) .init.data:(unknown)
The variable h4_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,

Maybe it shouldn't be marked __initdata?

=== omap3 ===
WARNING: vmlinux.o(.text+0x1b780): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init()
The function sdp3430_twl_gpio_setup() references
the function __init omap2_hsmmc_init().
This is often because sdp3430_twl_gpio_setup lacks a __init
annotation or the annotation of omap2_hsmmc_init is wrong.

Missing __init on sdp3430_twl_gpio_setup ?

WARNING: vmlinux.o(.text+0x1f714): Section mismatch in reference from the function omap_early_device_register() to the function .init.text:early_platform_add_devices()
The function omap_early_device_register() references
the function __init early_platform_add_devices().
This is often because omap_early_device_register lacks a __init
annotation or the annotation of early_platform_add_devices is wrong.

As before.

WARNING: vmlinux.o(.text+0x1f90c): Section mismatch in reference from the function omap_device_build_ss() to the function .init.text:early_platform_add_devices()
The function omap_device_build_ss() references
the function __init early_platform_add_devices().
This is often because omap_device_build_ss lacks a __init
annotation or the annotation of early_platform_add_devices is wrong.

As before.

WARNING: vmlinux.o(.data+0x20670): Section mismatch in reference from the variable twl_driver to the function .init.text:twl_probe()
The variable twl_driver references
the function __init twl_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,

twl_probe shouldn't be __init ?

=== omap4 ===
Nothing apparantly new over omap3.

RE: Current OMAP build failures

[Santosh Shilimkar]

[-- Attachment #1: Type: text/plain, Size: 5089 bytes --]

Russell,
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Thursday, January 06, 2011 4:34 PM
> To: Tony Lindgren
> Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> Subject: Current OMAP build failures
>

Have you used any custom build/ additional build flags
for omap2/3/4 reported issues ?
I just rebased Tony's 'omap-for-linus' branch with 2.6.37 and
it not seems to report below issues. May be it's getting
fixed as part of 2.6.38 omap queue or my build config is
not same as yours. I used omap2plus_defconfig.

> === omap2 ===
> arch/arm/plat-omap/devices.c:253: warning: │omap_init_wdt│ defined
> but not used
> arch/arm/mach-omap2/irq.c:64: warning: │intc_context│ defined but
> not used
> arch/arm/mach-omap2/prcm.c:122: warning: │prcm_context│ defined but
> not used
>
> Missing __maybe_unused or something else?
These seems to be fixed in omap queue.
>
> It also comes with three section mismatches:
>
> WARNING: vmlinux.o(.text+0x1f4c4): Section mismatch in reference
> from the function omap_early_device_register() to the function
> .init.text:early_platform_add_devices()
> The function omap_early_device_register() references
> the function __init early_platform_add_devices().
> This is often because omap_early_device_register lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> As early_platform_add_devices() is marked __init, so too should be
> omap_early_device_register().
I don't see this one. May be fixed
>
> WARNING: vmlinux.o(.text+0x1f6bc): Section mismatch in reference
> from the function omap_device_build_ss() to the function
> .init.text:early_platform_add_devices()
> The function omap_device_build_ss() references
> the function __init early_platform_add_devices().
> This is often because omap_device_build_ss lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> This looks like omap_early_device_register() has been inlined into
> omap_device_build_ss(), and it doesn't look like it can be marked
> __init.
>
> Rather than passing an 'is_early_device' into this function, split
> out the common code into a separate function which takes a function
> pointer to the registration function.  Then you can have two
> additional
> functions, one marked __init which uses omap_early_device_register()
> and one not marked __init using omap_device_register().
>
> This also means that we get the init-section type checking further
> up
> the chain.
This too
>
> WARNING: vmlinux.o(.data+0x6bd4): Section mismatch in reference from
> the variable h4_config to the (unknown reference)
> .init.data:(unknown)
> The variable h4_config references
> the (unknown reference) __initdata (unknown)
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the
> variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> Maybe it shouldn't be marked __initdata?
This too
>
> === omap3 ===
> WARNING: vmlinux.o(.text+0x1b780): Section mismatch in reference
> from the function sdp3430_twl_gpio_setup() to the function
> .init.text:omap2_hsmmc_init()
> The function sdp3430_twl_gpio_setup() references
> the function __init omap2_hsmmc_init().
> This is often because sdp3430_twl_gpio_setup lacks a __init
> annotation or the annotation of omap2_hsmmc_init is wrong.
>
> Missing __init on sdp3430_twl_gpio_setup ?
This too
>
> WARNING: vmlinux.o(.text+0x1f714): Section mismatch in reference
> from the function omap_early_device_register() to the function
> .init.text:early_platform_add_devices()
> The function omap_early_device_register() references
> the function __init early_platform_add_devices().
> This is often because omap_early_device_register lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> As before.
This too
>
> WARNING: vmlinux.o(.text+0x1f90c): Section mismatch in reference
> from the function omap_device_build_ss() to the function
> .init.text:early_platform_add_devices()
> The function omap_device_build_ss() references
> the function __init early_platform_add_devices().
> This is often because omap_device_build_ss lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> As before.
This too
>
> WARNING: vmlinux.o(.data+0x20670): Section mismatch in reference
> from the variable twl_driver to the function .init.text:twl_probe()
> The variable twl_driver references
> the function __init twl_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the
> variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> twl_probe shouldn't be __init ?
>
I only see the twl_probe section miss-match. Have attached full build
log for reference.

Regards,
Santosh

[-- Attachment #2: 2.6.37_omap_for_linus.tar.bz2 --]
[-- Type: application/octet-stream, Size: 8378 bytes --]

Current OMAP build failures

[Santosh Shilimkar]

Russell,
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Thursday, January 06, 2011 4:34 PM
> To: Tony Lindgren
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Current OMAP build failures
>

Have you used any custom build/ additional build flags
for omap2/3/4 reported issues ?
I just rebased Tony's 'omap-for-linus' branch with 2.6.37 and
it not seems to report below issues. May be it's getting
fixed as part of 2.6.38 omap queue or my build config is
not same as yours. I used omap2plus_defconfig.

> === omap2 ===
> arch/arm/plat-omap/devices.c:253: warning: ?omap_init_wdt? defined
> but not used
> arch/arm/mach-omap2/irq.c:64: warning: ?intc_context? defined but
> not used
> arch/arm/mach-omap2/prcm.c:122: warning: ?prcm_context? defined but
> not used
>
> Missing __maybe_unused or something else?
These seems to be fixed in omap queue.
>
> It also comes with three section mismatches:
>
> WARNING: vmlinux.o(.text+0x1f4c4): Section mismatch in reference
> from the function omap_early_device_register() to the function
> .init.text:early_platform_add_devices()
> The function omap_early_device_register() references
> the function __init early_platform_add_devices().
> This is often because omap_early_device_register lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> As early_platform_add_devices() is marked __init, so too should be
> omap_early_device_register().
I don't see this one. May be fixed
>
> WARNING: vmlinux.o(.text+0x1f6bc): Section mismatch in reference
> from the function omap_device_build_ss() to the function
> .init.text:early_platform_add_devices()
> The function omap_device_build_ss() references
> the function __init early_platform_add_devices().
> This is often because omap_device_build_ss lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> This looks like omap_early_device_register() has been inlined into
> omap_device_build_ss(), and it doesn't look like it can be marked
> __init.
>
> Rather than passing an 'is_early_device' into this function, split
> out the common code into a separate function which takes a function
> pointer to the registration function.  Then you can have two
> additional
> functions, one marked __init which uses omap_early_device_register()
> and one not marked __init using omap_device_register().
>
> This also means that we get the init-section type checking further
> up
> the chain.
This too
>
> WARNING: vmlinux.o(.data+0x6bd4): Section mismatch in reference from
> the variable h4_config to the (unknown reference)
> .init.data:(unknown)
> The variable h4_config references
> the (unknown reference) __initdata (unknown)
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the
> variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> Maybe it shouldn't be marked __initdata?
This too
>
> === omap3 ===
> WARNING: vmlinux.o(.text+0x1b780): Section mismatch in reference
> from the function sdp3430_twl_gpio_setup() to the function
> .init.text:omap2_hsmmc_init()
> The function sdp3430_twl_gpio_setup() references
> the function __init omap2_hsmmc_init().
> This is often because sdp3430_twl_gpio_setup lacks a __init
> annotation or the annotation of omap2_hsmmc_init is wrong.
>
> Missing __init on sdp3430_twl_gpio_setup ?
This too
>
> WARNING: vmlinux.o(.text+0x1f714): Section mismatch in reference
> from the function omap_early_device_register() to the function
> .init.text:early_platform_add_devices()
> The function omap_early_device_register() references
> the function __init early_platform_add_devices().
> This is often because omap_early_device_register lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> As before.
This too
>
> WARNING: vmlinux.o(.text+0x1f90c): Section mismatch in reference
> from the function omap_device_build_ss() to the function
> .init.text:early_platform_add_devices()
> The function omap_device_build_ss() references
> the function __init early_platform_add_devices().
> This is often because omap_device_build_ss lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> As before.
This too
>
> WARNING: vmlinux.o(.data+0x20670): Section mismatch in reference
> from the variable twl_driver to the function .init.text:twl_probe()
> The variable twl_driver references
> the function __init twl_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the
> variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> twl_probe shouldn't be __init ?
>
I only see the twl_probe section miss-match. Have attached full build
log for reference.

Regards,
Santosh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.6.37_omap_for_linus.tar.bz2
Type: application/octet-stream
Size: 8378 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110106/5786427a/attachment.obj>

Re: Current OMAP build failures

[Kevin Hilman]

Hi Russell,

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

> I've observed the following issues while building 2.6.37 + my devel
> branch.  I don't believe any of them to be due to anything in my tree,
> so would be in 2.6.37 as well.

What defconfig are you using for these builds?

Kevin

Current OMAP build failures

[Kevin Hilman]

Hi Russell,

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

> I've observed the following issues while building 2.6.37 + my devel
> branch.  I don't believe any of them to be due to anything in my tree,
> so would be in 2.6.37 as well.

What defconfig are you using for these builds?

Kevin

Re: Current OMAP build failures

[Russell King - ARM Linux]

On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote:
> Hi Russell,
> 
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> > I've observed the following issues while building 2.6.37 + my devel
> > branch.  I don't believe any of them to be due to anything in my tree,
> > so would be in 2.6.37 as well.
> 
> What defconfig are you using for these builds?

I couldn't say offhand because they're built from configs created a while
back.  I tend to just re-run the build with appropriate O= arguments to
test things.

I can send the defconfigs if it'd help.

Current OMAP build failures

[Russell King - ARM Linux]

On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote:
> Hi Russell,
> 
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> > I've observed the following issues while building 2.6.37 + my devel
> > branch.  I don't believe any of them to be due to anything in my tree,
> > so would be in 2.6.37 as well.
> 
> What defconfig are you using for these builds?

I couldn't say offhand because they're built from configs created a while
back.  I tend to just re-run the build with appropriate O= arguments to
test things.

I can send the defconfigs if it'd help.

Re: Current OMAP build failures

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 09:09]:
> On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote:
> > Hi Russell,
> > 
> > Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> > 
> > > I've observed the following issues while building 2.6.37 + my devel
> > > branch.  I don't believe any of them to be due to anything in my tree,
> > > so would be in 2.6.37 as well.
> > 
> > What defconfig are you using for these builds?
> 
> I couldn't say offhand because they're built from configs created a while
> back.  I tend to just re-run the build with appropriate O= arguments to
> test things.
> 
> I can send the defconfigs if it'd help.

I have the following patch queued up as commit be40f7a3d7b53c1a44e11b376b4a395d6b91f58d
which should fix the compile error you're seeing. This seems to be related
to some option in the .config that's not happening with any of the
defconfigs.

Regards,

Tony


commit be40f7a3d7b53c1a44e11b376b4a395d6b91f58d
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Dec 7 16:25:40 2010 -0800

    omap: Fix undefined reference to omap2_i2c_mux_pins
    
    In some cases we can get error function `omap2_i2c_add_bus':
    arch/arm/plat-omap/i2c.c:136: undefined reference to `omap2_i2c_mux_pins'
    arch/arm/plat-omap/i2c.c:141: undefined reference to `omap_hwmod_lookup'
    arch/arm/plat-omap/i2c.c:157: undefined reference to `omap_device_build'
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a6cf4e9..db9c4ef 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -130,6 +130,7 @@ static struct omap_device_pm_latency omap_i2c_latency[] = {
 	},
 };
 
+#ifdef CONFIG_ARCH_OMAP2PLUS
 static inline int omap2_i2c_add_bus(int bus_id)
 {
 	int l;
@@ -166,6 +167,12 @@ static inline int omap2_i2c_add_bus(int bus_id)
 
 	return PTR_ERR(od);
 }
+#else
+static inline int omap2_i2c_add_bus(int bus_id)
+{
+	return 0;
+}
+#endif
 
 static int __init omap_i2c_add_bus(int bus_id)
 {

Current OMAP build failures

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 09:09]:
> On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote:
> > Hi Russell,
> > 
> > Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> > 
> > > I've observed the following issues while building 2.6.37 + my devel
> > > branch.  I don't believe any of them to be due to anything in my tree,
> > > so would be in 2.6.37 as well.
> > 
> > What defconfig are you using for these builds?
> 
> I couldn't say offhand because they're built from configs created a while
> back.  I tend to just re-run the build with appropriate O= arguments to
> test things.
> 
> I can send the defconfigs if it'd help.

I have the following patch queued up as commit be40f7a3d7b53c1a44e11b376b4a395d6b91f58d
which should fix the compile error you're seeing. This seems to be related
to some option in the .config that's not happening with any of the
defconfigs.

Regards,

Tony


commit be40f7a3d7b53c1a44e11b376b4a395d6b91f58d
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Dec 7 16:25:40 2010 -0800

    omap: Fix undefined reference to omap2_i2c_mux_pins
    
    In some cases we can get error function `omap2_i2c_add_bus':
    arch/arm/plat-omap/i2c.c:136: undefined reference to `omap2_i2c_mux_pins'
    arch/arm/plat-omap/i2c.c:141: undefined reference to `omap_hwmod_lookup'
    arch/arm/plat-omap/i2c.c:157: undefined reference to `omap_device_build'
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a6cf4e9..db9c4ef 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -130,6 +130,7 @@ static struct omap_device_pm_latency omap_i2c_latency[] = {
 	},
 };
 
+#ifdef CONFIG_ARCH_OMAP2PLUS
 static inline int omap2_i2c_add_bus(int bus_id)
 {
 	int l;
@@ -166,6 +167,12 @@ static inline int omap2_i2c_add_bus(int bus_id)
 
 	return PTR_ERR(od);
 }
+#else
+static inline int omap2_i2c_add_bus(int bus_id)
+{
+	return 0;
+}
+#endif
 
 static int __init omap_i2c_add_bus(int bus_id)
 {

Re: Current OMAP build failures

[Russell King - ARM Linux]

On Thu, Jan 06, 2011 at 09:49:51AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 09:09]:
> > On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote:
> > > Hi Russell,
> > > 
> > > Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> > > 
> > > > I've observed the following issues while building 2.6.37 + my devel
> > > > branch.  I don't believe any of them to be due to anything in my tree,
> > > > so would be in 2.6.37 as well.
> > > 
> > > What defconfig are you using for these builds?
> > 
> > I couldn't say offhand because they're built from configs created a while
> > back.  I tend to just re-run the build with appropriate O= arguments to
> > test things.
> > 
> > I can send the defconfigs if it'd help.
> 
> I have the following patch queued up as commit be40f7a3d7b53c1a44e11b376b4a395d6b91f58d
> which should fix the compile error you're seeing. This seems to be related
> to some option in the .config that's not happening with any of the
> defconfigs.

That'll be because I have:

CONFIG_I2C_OMAP=y

in my config, whereas most OMAP1 defconfigs don't have it enabled with
the exception of omap_h2_1610_defconfig.

Current OMAP build failures

[Russell King - ARM Linux]

On Thu, Jan 06, 2011 at 09:49:51AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 09:09]:
> > On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote:
> > > Hi Russell,
> > > 
> > > Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> > > 
> > > > I've observed the following issues while building 2.6.37 + my devel
> > > > branch.  I don't believe any of them to be due to anything in my tree,
> > > > so would be in 2.6.37 as well.
> > > 
> > > What defconfig are you using for these builds?
> > 
> > I couldn't say offhand because they're built from configs created a while
> > back.  I tend to just re-run the build with appropriate O= arguments to
> > test things.
> > 
> > I can send the defconfigs if it'd help.
> 
> I have the following patch queued up as commit be40f7a3d7b53c1a44e11b376b4a395d6b91f58d
> which should fix the compile error you're seeing. This seems to be related
> to some option in the .config that's not happening with any of the
> defconfigs.

That'll be because I have:

CONFIG_I2C_OMAP=y

in my config, whereas most OMAP1 defconfigs don't have it enabled with
the exception of omap_h2_1610_defconfig.