OMAP34xx

OMAP34xx

[Russell King - ARM Linux]

Does someone want to try building and running Linux on (eg) an OMAP34xx
platform before I post my next email message on this subject, and
maybe send me a bunch of patches required to fix stuff, to be applied
to my tree _and_ _then_ forwarded to Linus next Friday.

So, think of this as your last chance, and you'll get the picture about
how pissed off I am with the - yet again - current poor state of OMAP
in mainline, which seems to happen every merge window.

Consider this: when Linus started using a PowerPC platform, the PowerPC
people quickly realized that pushing patches upstream which broke stuff
was a really bad idea, because they got publically flamed for such
actions especially when stuff was not obviously tested.

This is no different... and this is _not_ my original email which I have
queued up with the real hot flames in over this.  This is the toned down
version.  The flames won't get sent if OMAP gets fixed quickly - and if
testing improves to stop this constant cycle of regressions at every
merge window.

Thanks.

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 10:24]:
> Does someone want to try building and running Linux on (eg) an OMAP34xx
> platform before I post my next email message on this subject, and
> maybe send me a bunch of patches required to fix stuff, to be applied
> to my tree _and_ _then_ forwarded to Linus next Friday.
> 
> So, think of this as your last chance, and you'll get the picture about
> how pissed off I am with the - yet again - current poor state of OMAP
> in mainline, which seems to happen every merge window.
> 
> Consider this: when Linus started using a PowerPC platform, the PowerPC
> people quickly realized that pushing patches upstream which broke stuff
> was a really bad idea, because they got publically flamed for such
> actions especially when stuff was not obviously tested.
> 
> This is no different... and this is _not_ my original email which I have
> queued up with the real hot flames in over this.  This is the toned down
> version.  The flames won't get sent if OMAP gets fixed quickly - and if
> testing improves to stop this constant cycle of regressions at every
> merge window.

Do you have the patches applied already queued up in arm-soc fixes
branch?

Regards,

Tony

Re: OMAP34xx

[Olof Johansson]

On Sat, Feb 4, 2012 at 11:01 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 10:24]:
>> Does someone want to try building and running Linux on (eg) an OMAP34xx
>> platform before I post my next email message on this subject, and
>> maybe send me a bunch of patches required to fix stuff, to be applied
>> to my tree _and_ _then_ forwarded to Linus next Friday.
>>
>> So, think of this as your last chance, and you'll get the picture about
>> how pissed off I am with the - yet again - current poor state of OMAP
>> in mainline, which seems to happen every merge window.
>>
>> Consider this: when Linus started using a PowerPC platform, the PowerPC
>> people quickly realized that pushing patches upstream which broke stuff
>> was a really bad idea, because they got publically flamed for such
>> actions especially when stuff was not obviously tested.
>>
>> This is no different... and this is _not_ my original email which I have
>> queued up with the real hot flames in over this.  This is the toned down
>> version.  The flames won't get sent if OMAP gets fixed quickly - and if
>> testing improves to stop this constant cycle of regressions at every
>> merge window.
>
> Do you have the patches applied already queued up in arm-soc fixes
> branch?

I've been sitting on those longer than I meant to, my bad. I'll send a
pull request to Linus in a little bit.


-Olof
--
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: OMAP34xx

[Russell King - ARM Linux]

On Sat, Feb 04, 2012 at 11:01:09AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 10:24]:
> > Does someone want to try building and running Linux on (eg) an OMAP34xx
> > platform before I post my next email message on this subject, and
> > maybe send me a bunch of patches required to fix stuff, to be applied
> > to my tree _and_ _then_ forwarded to Linus next Friday.
> > 
> > So, think of this as your last chance, and you'll get the picture about
> > how pissed off I am with the - yet again - current poor state of OMAP
> > in mainline, which seems to happen every merge window.
> > 
> > Consider this: when Linus started using a PowerPC platform, the PowerPC
> > people quickly realized that pushing patches upstream which broke stuff
> > was a really bad idea, because they got publically flamed for such
> > actions especially when stuff was not obviously tested.
> > 
> > This is no different... and this is _not_ my original email which I have
> > queued up with the real hot flames in over this.  This is the toned down
> > version.  The flames won't get sent if OMAP gets fixed quickly - and if
> > testing improves to stop this constant cycle of regressions at every
> > merge window.
> 
> Do you have the patches applied already queued up in arm-soc fixes
> branch?

It really doesn't make much difference - the only improvement I see in
the big collection of issues I have with OMAP this time around is one
build error is gone.  There's _far_ _far_ bigger problems in the OMAP
code this time.

I'm seriously considering requesting that all OMAP changes for the merge
window come through me rather than arm-soc, so that I can boot and build
test them before the merge window opens, and we can cut down on this
repetitive cycle of build (and boot) breakage at every merge window.

One problem isn't yours to solve (the requirement for regulators for
the SMSC network driver which has appeared.)

Another problem (some build errors for OMAP3) do seem to be solved, but
not the section mismatch warnings.  They're easy to verify before code
gets pushed anywhere upstream, especially if you're doing one giant OMAP
build - just enable CONFIG_DEBUG_SECTION_MISMATCH in your build
configuration.  Refuse patches which introduce section mismatches - at
least without an explanation backing up why they do.

My OMAP3 and OMAP4 configurations spit out these - I've not even tried
my OMAP2 configuration yet:

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x15a4): Section mismatch in refe$
The function omap_mux_init_signals() references
the function __init omap_mux_init_signal().
This is often because omap_mux_init_signals lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.

WARNING: arch/arm/mach-omap2/built-in.o(.text+0xd1f0): Section mismatch in refe$
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.

WARNING: vmlinux.o(.text+0x27644): Section mismatch in reference from the funct$
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.

WARNING: vmlinux.o(.text+0x1c7a4): Section mismatch in reference from the function omap_secondary_startup() to the function .cpuinit.text:secondary_startup()
The function omap_secondary_startup() references
the function __cpuinit secondary_startup().
This is often because omap_secondary_startup lacks a __cpuinit 
annotation or the annotation of secondary_startup is wrong.

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

WARNING: vmlinux.o(.text+0x2826c): 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.

WARNING: vmlinux.o(.devinit.text+0x1870): Section mismatch in reference from the function twl_probe() to the function .init.text:twl4030_power_init()
The function __devinit twl_probe() references
a function __init twl4030_power_init().
If twl4030_power_init is only used by twl_probe then
annotate twl4030_power_init with a matching annotation.

Another problem oopses the kernel at boot in the voltage domain code,
which I suspect this has never been boot tested on OMAP34xx CPUs:

omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT
Modules linked in:
CPU: 0    Not tainted  (3.3.0-rc2+ #204)
PC is at omap_vp_init+0x5c/0x15c
LR is at omap_vp_init+0x58/0x15c
pc : [<c03db880>]    lr : [<c03db87c>]    psr: 60000013
sp : c181ff30  ip : c181ff68  fp : c181ff64
r10: c0407808  r9 : c040786c  r8 : c0407814
r7 : c0026868  r6 : c00264fc  r5 : c040ad6c  r4 : 00000000
r3 : 00000040  r2 : 000032c8  r1 : 0000fa00  r0 : 000032c8
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 80004019  DAC: 00000015
Process swapper (pid: 1, stack limit = 0xc181e2e8)
Stack: (0xc181ff30 to 0xc1820000)
ff20:                                     c0381d00 c02e9c6d c0383582 c040786c
ff40: c040ad6c c00264fc c0026868 c0407814 00000000 c03d9de4 c181ff8c c181ff68
ff60: c03db448 c03db830 c02e982c c03fdfb8 c03fe004 c0039988 00000013 00000000
ff80: c181ff9c c181ff90 c03d9df8 c03db390 c181ffdc c181ffa0 c0008798 c03d9df0
ffa0: c181ffc4 c181ffb0 c0055a44 c0187050 c0039988 c03fdfb8 c03fe004 c0039988
ffc0: 00000013 00000000 00000000 00000000 c181fff4 c181ffe0 c03d1284 c0008708
ffe0: 00000000 c03d1208 00000000 c181fff8 c0039988 c03d1214 1077ce40 01f7ee08
Backtrace: 
[<c03db824>] (omap_vp_init+0x0/0x15c) from [<c03db448>] (omap_voltage_late_init+
0xc4/0xfc)
[<c03db384>] (omap_voltage_late_init+0x0/0xfc) from [<c03d9df8>] (omap2_common_p
m_late_init+0x14/0x54)
 r8:00000000 r7:00000013 r6:c0039988 r5:c03fe004 r4:c03fdfb8
[<c03d9de4>] (omap2_common_pm_late_init+0x0/0x54) from [<c0008798>] (do_one_init
call+0x9c/0x164)
[<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03d1284>] (kernel_init+0x7c/0x1
20)
[<c03d1208>] (kernel_init+0x0/0x120) from [<c0039988>] (do_exit+0x0/0x2cc)
 r5:c03d1208 r4:00000000
Code: e5ca300b e5900034 ebf69027 e5994024 (e5941000) 
---[ end trace aed617dddaf32c3d ]---
Kernel panic - not syncing: Attempted to kill init!

And OMAP4 doesn't build.  Fixing the build error in prm44xx.c (which is
virtually the same as the OMAP3 build error in its prm file) gets us to
a buildable state, but... it silently fails to boot.

arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)

At least enabling DEBUG_LL gets this reason:

<1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 
<1>pgd = c0004000                                                               
<1>[00000000] *pgd=00000000                                                     
<0>Internal error: Oops: 5 [#1] SMP                                             
<d>Modules linked in:                                                           
CPU: 1    Not tainted  (3.3.0-rc2+ #271)                                        
PC is at irq_domain_add+0x1c/0x134                                              
LR is at twl_probe+0xd0/0x370                                                   
pc : [<c007bad0>]    lr : [<c029baac>]    psr: 00000113                         
sp : df843c48  ip : df843c68  fp : df843c64                                     
r10: c02b93e4  r9 : 00000000  r8 : c029b9dc                                     
r7 : df9d8a00  r6 : c03bef90  r5 : 00000000  r4 : c03f5240                      
r3 : 00000000  r2 : c03f5240  r1 : 00000015  r0 : c03f5240                      
Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel             
Control: 10c5387d  Table: 8000404a  DAC: 00000015                               
<0>Process swapper/0 (pid: 1, stack limit = 0xdf8422f0)                         
<0>Stack: (0xdf843c48 to 0xdf844000)                                            
<0>3c40:                   00000014 00000170 00000014 c03bef90 df843c9c df843c68
<0>3c60: c029baac c007bac0 00000000 df9d8a20 00000001 c03cd238 c02b93e4 df9d8a20
<0>3c80: df9d8a04 df9d8a00 c029b9dc df8cae08 df843cc4 df843ca0 c01eee70 c029b9e8
<0>3ca0: c01d1df0 df9d8a20 df9d8a20 df9d8a20 c03cd238 df8f0070 df843ce4 df843cc8
<0>3cc0: c01d1f34 c01eedcc df9d8a20 c03cd238 df9d8a20 df843d18 df843cfc df843ce8
<0>3ce0: c01d205c c01d1ea0 c03cd238 df9d8a20 df843d14 df843d00 c01d2148 c01d2018
<0>3d00: 00000000 c01d2104 df843d3c df843d18 c01d0840 c01d2110 df82aa6c df87cd38
<0>3d20: df9d8a20 c03cd978 df9d8a54 df9d8a28 df843d5c df843d40 c01d21f8 c01d07f4
<0>3d40: df843d64 df9d8a20 c03cd978 df9d8a20 df843d7c df843d60 c01d1430 c01d2184
<0>3d60: df843d7c df9d8a20 df9d8a20 00000000 df843db4 df843d80 c01cffb0 c01d1408
<0>3d80: c01d89d8 c01d98b8 df9d8a20 df9d8a00 df843db4 df9d8a20 df9d8a00 df8f0048
<0>3da0: df9d8a04 df9d8a00 df843dcc df843db8 c01d0150 c01cfd1c df843dd0 df9d8a20
<0>3dc0: df843dfc df843dd0 c01ef8d4 c01d013c df8f0048 df8f0048 df8f0070 df8f0048
<0>3de0: df8a6300 df8f0070 00000000 c03cd970 df843e24 df843e00 c01efc88 c01ef7c8
<0>3e00: df843e24 00000000 df8f0048 df843e2c df8cae00 df8a4c54 df843e4c df843e28
<0>3e20: c01efe9c c01efb54 00000010 00000001 c01d1b58 df8f0070 df8f0000 00000000
<0>3e40: df843e84 df843e50 c029ce1c c01efdf4 00000004 00000000 00000190 df843e68
<0>3e60: df8cae08 df8cae08 c03cdb2c c03cdb2c c03ccd00 00000000 df843e94 df843e88
<0>3e80: c01d3484 c029cb30 df843eb4 df843e98 c01d1f34 c01d3470 df8cae08 c03cdb2c
<0>3ea0: c03cdb2c df843ef0 df843ecc df843eb8 c01d205c c01d1ea0 df8cae08 df8cae3c
<0>3ec0: df843eec df843ed0 c01d20e0 c01d2018 c01d2074 00000000 c01d2074 c03cdb2c
<0>3ee0: df843f14 df843ef0 c01d08d8 c01d2080 df82a258 df8a4bb4 c0394f28 c03cdb2c
<0>3f00: c03cdb2c df880b80 df843f24 df843f18 c01d1d80 c01d088c df843f54 df843f28
<0>3f20: c01d115c c01d1d6c c0344ca3 df843f38 c0394f28 c0395180 c03cdb2c 00000013
<0>3f40: 00000000 c0386258 df843f7c df843f58 c01d278c c01d10b4 c00b8bcc c0394f28
<0>3f60: c0395180 c00384c8 00000013 00000000 df843f8c df843f80 c01d37e4 c01d26d0
<0>3f80: df843f9c df843f90 c038626c c01d37a4 df843fdc df843fa0 c00087b8 c0386264
<0>3fa0: 00000000 00000000 df843fc4 df843fb8 c005442c c0394f28 c0395180 c00384c8
<0>3fc0: 00000013 00000000 00000000 00000000 df843ff4 df843fe0 c036c2f4 c0008728
<0>3fe0: 00000000 c036c264 00000000 df843ff8 c00384c8 c036c270 55555555 5555595d
Backtrace:                                                                      
[<c007bab4>] (irq_domain_add+0x0/0x134) from [<c029baac>] (twl_probe+0xd0/0x370)
 r6:c03bef90 r5:00000014 r4:00000170                                            
[<c029b9dc>] (twl_probe+0x0/0x370) from [<c01eee70>] (i2c_device_probe+0xb0/0xe4
)                                                                               
[<c01eedc0>] (i2c_device_probe+0x0/0xe4) from [<c01d1f34>] (really_probe+0xa0/0x
178)                                                                            
 r8:df8f0070 r7:c03cd238 r6:df9d8a20 r5:df9d8a20 r4:df9d8a20                    
[<c01d1e94>] (really_probe+0x0/0x178) from [<c01d205c>] (driver_probe_device+0x5
0/0x68)                                                                         
 r7:df843d18 r6:df9d8a20 r5:c03cd238 r4:df9d8a20                                
[<c01d200c>] (driver_probe_device+0x0/0x68) from [<c01d2148>] (__device_attach+0
x44/0x48)                                                                       
 r5:df9d8a20 r4:c03cd238                                                        
[<c01d2104>] (__device_attach+0x0/0x48) from [<c01d0840>] (bus_for_each_drv+0x58
/0x98)                                                                          
 r5:c01d2104 r4:00000000                                                        
[<c01d07e8>] (bus_for_each_drv+0x0/0x98) from [<c01d21f8>] (device_attach+0x80/0
xac)                                                                            
 r7:df9d8a28 r6:df9d8a54 r5:c03cd978 r4:df9d8a20                                
[<c01d2178>] (device_attach+0x0/0xac) from [<c01d1430>] (bus_probe_device+0x34/0
xa4)                                                                            
 r6:df9d8a20 r5:c03cd978 r4:df9d8a20                                            
[<c01d13fc>] (bus_probe_device+0x0/0xa4) from [<c01cffb0>] (device_add+0x2a0/0x4
20)                                                                             
 r6:00000000 r5:df9d8a20 r4:df9d8a20                                            
[<c01cfd10>] (device_add+0x0/0x420) from [<c01d0150>] (device_register+0x20/0x24
)                                                                               
 r8:df9d8a00 r7:df9d8a04 r6:df8f0048 r5:df9d8a00 r4:df9d8a20                    
[<c01d0130>] (device_register+0x0/0x24) from [<c01ef8d4>] (i2c_new_device+0x118/
0x180)                                                                          
 r4:df9d8a20                                                                    
[<c01ef7bc>] (i2c_new_device+0x0/0x180) from [<c01efc88>] (i2c_register_adapter+
0x140/0x204)                                                                    
 r8:c03cd970 r7:00000000 r6:df8f0070 r5:df8a6300 r4:df8f0048                    
[<c01efb48>] (i2c_register_adapter+0x0/0x204) from [<c01efe9c>] (i2c_add_numbere
d_adapter+0xb4/0xcc)                                                            
 r8:df8a4c54 r7:df8cae00 r6:df843e2c r5:df8f0048 r4:00000000                    
[<c01efde8>] (i2c_add_numbered_adapter+0x0/0xcc) from [<c029ce1c>] (omap_i2c_pro
be+0x2f8/0x3b4)                                                                 
 r6:00000000 r5:df8f0000 r4:df8f0070                                            
[<c029cb24>] (omap_i2c_probe+0x0/0x3b4) from [<c01d3484>] (platform_drv_probe+0x
20/0x24)                                                                        
[<c01d3464>] (platform_drv_probe+0x0/0x24) from [<c01d1f34>] (really_probe+0xa0/
0x178)                                                                          
[<c01d1e94>] (really_probe+0x0/0x178) from [<c01d205c>] (driver_probe_device+0x5
0/0x68)                                                                         
 r7:df843ef0 r6:c03cdb2c r5:c03cdb2c r4:df8cae08                                
[<c01d200c>] (driver_probe_device+0x0/0x68) from [<c01d20e0>] (__driver_attach+0
x6c/0x90)                                                                       
 r5:df8cae3c r4:df8cae08                                                        
[<c01d2074>] (__driver_attach+0x0/0x90) from [<c01d08d8>] (bus_for_each_dev+0x58
/0x98)                                                                          
 r6:c03cdb2c r5:c01d2074 r4:00000000                                            
[<c01d0880>] (bus_for_each_dev+0x0/0x98) from [<c01d1d80>] (driver_attach+0x20/0
x28)                                                                            
 r7:df880b80 r6:c03cdb2c r5:c03cdb2c r4:c0394f28                                
[<c01d1d60>] (driver_attach+0x0/0x28) from [<c01d115c>] (bus_add_driver+0xb4/0x2
30)                                                                             
[<c01d10a8>] (bus_add_driver+0x0/0x230) from [<c01d278c>] (driver_register+0xc8/
0x154)                                                                          
[<c01d26c4>] (driver_register+0x0/0x154) from [<c01d37e4>] (platform_driver_regi
ster+0x4c/0x60)                                                                 
 r8:00000000 r7:00000013 r6:c00384c8 r5:c0395180 r4:c0394f28                    
[<c01d3798>] (platform_driver_register+0x0/0x60) from [<c038626c>] (omap_i2c_ini
t_driver+0x14/0x1c)                                                             
[<c0386258>] (omap_i2c_init_driver+0x0/0x1c) from [<c00087b8>] (do_one_initcall+
0x9c/0x164)                                                                     
[<c000871c>] (do_one_initcall+0x0/0x164) from [<c036c2f4>] (kernel_init+0x90/0x1
38)                                                                             
[<c036c264>] (kernel_init+0x0/0x138) from [<c00384c8>] (do_exit+0x0/0x2ec)      
 r5:c036c264 r4:00000000                                                        
<0>Code: e24dd004 e5903014 e1a04000 e5905010 (e5933000)                         
<4>---[ end trace 1b75b31a2719ed1c ]---                                         
<0>Kernel panic - not syncing: Attempted to kill init!                          
<2>CPU0: stopping                                                               
Backtrace:                                                                      
[<c0017cb0>] (dump_backtrace+0x0/0x10c) from [<c02a02b0>] (dump_stack+0x18/0x1c)
 r7:fa24010c r6:c0399f38 r5:00000000 r4:c03d2bb4                                
[<c02a0298>] (dump_stack+0x0/0x1c) from [<c0018ee8>] (handle_IPI+0xf4/0x17c)    
[<c0018df4>] (handle_IPI+0x0/0x17c) from [<c0008698>] (gic_handle_irq+0xa8/0xb8)
 r5:c03ad900 r4:c00151e4                                                        
[<c00085f0>] (gic_handle_irq+0x0/0xb8) from [<c0013b40>] (__irq_svc+0x40/0x60)  
Exception stack(0xc0399f38 to 0xc0399f80)                                       
9f20:                                                       c03d2cd8 a0000193   
9f40: fa242000 00000000 c0398000 c03b1114 c03d2998 c03ad890 c02a5ca4 411fc092   
9f60: 00000000 c0399f8c c0399f90 c0399f80 c00151e0 c00151e4 60000113 ffffffff   
 r8:c02a5ca4 r7:c0399f6c r6:ffffffff r5:60000113 r4:c00151e4                    
[<c00151b8>] (default_idle+0x0/0x34) from [<c0015868>] (cpu_idle+0xa8/0xf4)     
[<c00157c0>] (cpu_idle+0x0/0xf4) from [<c0299030>] (rest_init+0x60/0x78)        
 r8:8000406a r7:c03d28c0 r6:c03d28cc r5:c03d293c r4:c03adf54                    
[<c0298fd0>] (rest_init+0x0/0x78) from [<c036c8d4>] (start_kernel+0x2a8/0x30c)  
[<c036c62c>] (start_kernel+0x0/0x30c) from [<80008044>] (0x80008044)            
 r7:c03b1104 r6:c03908d8 r5:c03ad8bc r4:10c5387d                                

So, a slight improvement, but overall no material forward progress in
terms of things booting.

And, compared to my previous testing, the OMAP state is worse than ever
as this time, even with your first round of fixes, all my OMAP platforms
are pretty broken.

Re: OMAP34xx

[Russell King - ARM Linux]

On Sat, Feb 04, 2012 at 08:34:53PM +0000, Russell King - ARM Linux wrote:
> And OMAP4 doesn't build.  Fixing the build error in prm44xx.c (which is
> virtually the same as the OMAP3 build error in its prm file) gets us to
> a buildable state, but... it silently fails to boot.
> 
> arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)

BTW, I can tell you why you don't see this error - you're building with
DT enabled, which gives you this header path to those definitions:

arch/arm/mach-omap2/prm44xx.c
 arch/arm/mach-omap2/common.h
  plat/common.h    
   plat/i2c.h
    linux/i2c.h
     linux/of.h
      asm/prom.h
       asm/irq.h
        mach/irqs.h
         plat/irqs.h
          plat/irqs-44xx.h

which, I think you'll agree, is a recipe for disaster if any one of those
decides not to include its child at some point either via configuration
or via mere deletion of an include.

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 12:22]:
> On Sat, Feb 04, 2012 at 08:34:53PM +0000, Russell King - ARM Linux wrote:
> > And OMAP4 doesn't build.  Fixing the build error in prm44xx.c (which is
> > virtually the same as the OMAP3 build error in its prm file) gets us to
> > a buildable state, but... it silently fails to boot.
> > 
> > arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)
> 
> BTW, I can tell you why you don't see this error - you're building with
> DT enabled, which gives you this header path to those definitions:
> 
> arch/arm/mach-omap2/prm44xx.c
>  arch/arm/mach-omap2/common.h
>   plat/common.h    
>    plat/i2c.h
>     linux/i2c.h
>      linux/of.h
>       asm/prom.h
>        asm/irq.h
>         mach/irqs.h
>          plat/irqs.h
>           plat/irqs-44xx.h
> 
> which, I think you'll agree, is a recipe for disaster if any one of those
> decides not to include its child at some point either via configuration
> or via mere deletion of an include.

OK. Sounds like the solution here is to include irqs.h directly
in prmx44xx.c.

Regards,

Tony

Re: OMAP34xx

[Grazvydas Ignotas]

On Sat, Feb 4, 2012 at 10:34 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Another problem oopses the kernel at boot in the voltage domain code,
> which I suspect this has never been boot tested on OMAP34xx CPUs:
>
> omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = c0004000
> [00000000] *pgd=00000000
> Internal error: Oops: 5 [#1] PREEMPT
> Modules linked in:
> CPU: 0    Not tainted  (3.3.0-rc2+ #204)
> PC is at omap_vp_init+0x5c/0x15c
> LR is at omap_vp_init+0x58/0x15c

I've got hit by this too, and it also seems to be DT related, because
if you don't select CONFIG_USE_OF, you lose TWL4030_CORE, which
results in omap_vp errors and NULL dereference. TWL4030_CORE was made
to depend on IRQ_DOMAIN, and that is selected by USE_OF or ARM_GIC. I
guess everyone here builds with USE_OF, but maybe ARCH_OMAP3 should
select ARM_GIC?


-- 
Gražvydas
--
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: OMAP34xx

[Tony Lindgren]

* Grazvydas Ignotas <notasas@gmail.com> [120204 12:37]:
> On Sat, Feb 4, 2012 at 10:34 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > Another problem oopses the kernel at boot in the voltage domain code,
> > which I suspect this has never been boot tested on OMAP34xx CPUs:
> >
> > omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
> > Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > pgd = c0004000
> > [00000000] *pgd=00000000
> > Internal error: Oops: 5 [#1] PREEMPT
> > Modules linked in:
> > CPU: 0    Not tainted  (3.3.0-rc2+ #204)
> > PC is at omap_vp_init+0x5c/0x15c
> > LR is at omap_vp_init+0x58/0x15c
> 
> I've got hit by this too, and it also seems to be DT related, because
> if you don't select CONFIG_USE_OF, you lose TWL4030_CORE, which
> results in omap_vp errors and NULL dereference. TWL4030_CORE was made
> to depend on IRQ_DOMAIN, and that is selected by USE_OF or ARM_GIC. I
> guess everyone here builds with USE_OF, but maybe ARCH_OMAP3 should
> select ARM_GIC?

Thanks for tracking this down. We should not select GIC for omap3 as it
does not have it. Instead we should select IRQ_DOMAIN, there's patch
"[PATCH v4 1/4] ARM: kconfig: always select IRQ_DOMAIN" posted that
does that for all ARMs.

Regards,

Tony
--
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: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 12:03]:
> On Sat, Feb 04, 2012 at 11:01:09AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 10:24]:
> > > Does someone want to try building and running Linux on (eg) an OMAP34xx
> > > platform before I post my next email message on this subject, and
> > > maybe send me a bunch of patches required to fix stuff, to be applied
> > > to my tree _and_ _then_ forwarded to Linus next Friday.
> > > 
> > > So, think of this as your last chance, and you'll get the picture about
> > > how pissed off I am with the - yet again - current poor state of OMAP
> > > in mainline, which seems to happen every merge window.
> > > 
> > > Consider this: when Linus started using a PowerPC platform, the PowerPC
> > > people quickly realized that pushing patches upstream which broke stuff
> > > was a really bad idea, because they got publically flamed for such
> > > actions especially when stuff was not obviously tested.
> > > 
> > > This is no different... and this is _not_ my original email which I have
> > > queued up with the real hot flames in over this.  This is the toned down
> > > version.  The flames won't get sent if OMAP gets fixed quickly - and if
> > > testing improves to stop this constant cycle of regressions at every
> > > merge window.
> > 
> > Do you have the patches applied already queued up in arm-soc fixes
> > branch?
> 
> It really doesn't make much difference - the only improvement I see in
> the big collection of issues I have with OMAP this time around is one
> build error is gone.  There's _far_ _far_ bigger problems in the OMAP
> code this time.
> 
> I'm seriously considering requesting that all OMAP changes for the merge
> window come through me rather than arm-soc, so that I can boot and build
> test them before the merge window opens, and we can cut down on this
> repetitive cycle of build (and boot) breakage at every merge window.

I agree it would be nice to see these issues earlier. I build and boot
test every patch I merge, but mostly with omap2plus_defconfig as that
does the job for all the boards I have with a single zImage.

Looks like the issues you're seeing are related to .config settings.

How about let's plan on testing your .configs with for-next before the
next merge window?

> One problem isn't yours to solve (the requirement for regulators for
> the SMSC network driver which has appeared.)

Yes I noticed that too on booting zoom3.
 
> Another problem (some build errors for OMAP3) do seem to be solved, but
> not the section mismatch warnings.  They're easy to verify before code
> gets pushed anywhere upstream, especially if you're doing one giant OMAP
> build - just enable CONFIG_DEBUG_SECTION_MISMATCH in your build
> configuration.  Refuse patches which introduce section mismatches - at
> least without an explanation backing up why they do.
> 
> My OMAP3 and OMAP4 configurations spit out these - I've not even tried
> my OMAP2 configuration yet:

I agree these would be nice to fix, I'll take a look at these.
Or do you already have a patch for that?
 
> Another problem oopses the kernel at boot in the voltage domain code,
> which I suspect this has never been boot tested on OMAP34xx CPUs:

Boots fine here with omap2plus_defconfig. This must be some .config
option triggering this.

Kevin, can you please track down this one?
 
> And OMAP4 doesn't build.  Fixing the build error in prm44xx.c (which is
> virtually the same as the OMAP3 build error in its prm file) gets us to
> a buildable state, but... it silently fails to boot.
> 
> arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)

Have not seen this one either, have to investigate.
 
> So, a slight improvement, but overall no material forward progress in
> terms of things booting.
> 
> And, compared to my previous testing, the OMAP state is worse than ever
> as this time, even with your first round of fixes, all my OMAP platforms
> are pretty broken.

Sorry to hear that. And thanks for the detailed report on what all
issues you're seeing. They all seem like pretty trivial fixes, so just
hang on for few more days and we'll get them fixed.

Regards,

Tony

Re: OMAP34xx

[Russell King - ARM Linux]

On Sat, Feb 04, 2012 at 03:05:07PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 12:03]:
> > I'm seriously considering requesting that all OMAP changes for the merge
> > window come through me rather than arm-soc, so that I can boot and build
> > test them before the merge window opens, and we can cut down on this
> > repetitive cycle of build (and boot) breakage at every merge window.
> 
> I agree it would be nice to see these issues earlier. I build and boot
> test every patch I merge, but mostly with omap2plus_defconfig as that
> does the job for all the boards I have with a single zImage.
> 
> Looks like the issues you're seeing are related to .config settings.
> 
> How about let's plan on testing your .configs with for-next before the
> next merge window?

I was thinking about something more than just a build-test, because
that's just a part of the problem.

Let me make it clear what my motivation here is (before someone starts
making any accusations).

There is a view widely held that the mainline OMAP kernels are in a
pretty poor shape when it comes to people being buildable (I've been
told so.)  That reflects my experience each cycle when I try to test
a mainline OMAP kernel - and I invariably encounter build or boot
problems of various degrees.

What I would _prefer_ to see is that your tree gets build _and_ boot
tested by people in the OMAP community with a range of configurations,
and any build or boot problems get reported back in a timely manner
so that those problems can be solved before the tree goes to arm-soc.

Obviously, some of that does happen, but it's clearly not enough as
we keep going around this loop at every merge window where there's
breakage each time, there isn't enough of it.  So, we need a different
solution to this.

So, I was thinking about pulling your tree, building and booting
it _and_ requiring it to pass before it goes to mainline.  Yes, that's
pretty drastic, but I think it's about the only way to ensure that
the amount of regressions are reduced down to an acceptable level.

Let's be clear - I'm not talking about the pulls that you'd send to
Arnd and Olof for fixes during or after the merge window.  I'm talking
about the merge window stuff only - because that seems to be where most
of the breakage happens.

I've been wondering whether I could set something up which did this all
automatically - maybe running a build overnight and then automatically
boot testing it and logging the results - including running some
userspace testing.  One of the issues I'd face is that my current build
machine is the laptop, which isn't aways available to run the builds
each day.

But... things are complicated by the OMAP boards having USB to serial
devices on them rather than standard RS232, which rather limits what I
can do to automate testing with them, especially as others require a
USB socket as a source of power to run themselves.

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 15:38]:
> On Sat, Feb 04, 2012 at 03:05:07PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 12:03]:
> > > I'm seriously considering requesting that all OMAP changes for the merge
> > > window come through me rather than arm-soc, so that I can boot and build
> > > test them before the merge window opens, and we can cut down on this
> > > repetitive cycle of build (and boot) breakage at every merge window.
> > 
> > I agree it would be nice to see these issues earlier. I build and boot
> > test every patch I merge, but mostly with omap2plus_defconfig as that
> > does the job for all the boards I have with a single zImage.
> > 
> > Looks like the issues you're seeing are related to .config settings.
> > 
> > How about let's plan on testing your .configs with for-next before the
> > next merge window?
> 
> I was thinking about something more than just a build-test, because
> that's just a part of the problem.
> 
> Let me make it clear what my motivation here is (before someone starts
> making any accusations).
> 
> There is a view widely held that the mainline OMAP kernels are in a
> pretty poor shape when it comes to people being buildable (I've been
> told so.)  That reflects my experience each cycle when I try to test
> a mainline OMAP kernel - and I invariably encounter build or boot
> problems of various degrees.

Hmm well I can only do so much of testing. That's usually build and
boot test on 8 omap machines for pretty much all the patches that I
merge. Naturally I can't do that for all the 50 or so defconfigs that
I'm aware of, so I mostly stick to the generic omap1_defconfig and
omap2plus_defconfig.
 
> What I would _prefer_ to see is that your tree gets build _and_ boot
> tested by people in the OMAP community with a range of configurations,
> and any build or boot problems get reported back in a timely manner
> so that those problems can be solved before the tree goes to arm-soc.

Sure that would be nice. Still the place to do that testing is
for-next as I can't keep track of all driver changes.

> Obviously, some of that does happen, but it's clearly not enough as
> we keep going around this loop at every merge window where there's
> breakage each time, there isn't enough of it.  So, we need a different
> solution to this.
>
> So, I was thinking about pulling your tree, building and booting
> it _and_ requiring it to pass before it goes to mainline.  Yes, that's
> pretty drastic, but I think it's about the only way to ensure that
> the amount of regressions are reduced down to an acceptable level.

I'd rather see this happen on constant basis, otherwise we still have
the problem of these issues popping up too late. But feel free to do
your checks as often as you can :)
 
> Let's be clear - I'm not talking about the pulls that you'd send to
> Arnd and Olof for fixes during or after the merge window.  I'm talking
> about the merge window stuff only - because that seems to be where most
> of the breakage happens.
> 
> I've been wondering whether I could set something up which did this all
> automatically - maybe running a build overnight and then automatically
> boot testing it and logging the results - including running some
> userspace testing.  One of the issues I'd face is that my current build
> machine is the laptop, which isn't aways available to run the builds
> each day.
> 
> But... things are complicated by the OMAP boards having USB to serial
> devices on them rather than standard RS232, which rather limits what I
> can do to automate testing with them, especially as others require a
> USB socket as a source of power to run themselves.

Well maybe mail me your defconfigs, and I'll do build tests on those too
when merging stuff. Sounds like I don't have all the boards you have,
but probably have some of them to boot too.

Regards,

Tony

Regards,

Tony

Re: OMAP34xx

[Russell King - ARM Linux]

Here's another problem to add to the list:

2fd149645eb46d26130d7070c6de037dddf34880 totally screws serial on
OMAP3430 - and by that I mean running the port at 115200 baud causes
a simple 'dmesg' output to take 5+ minutes to output in 16 character
blocks every two seconds.

This fixes it in so far as it effectively reverts that change (the
change itself won't revert cleanly), but it's far from nice.

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 464cffd..1e9256c 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -259,6 +259,8 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
        struct omap3_idle_statedata *cx;
        int ret;
 
+       { new_state_idx = drv->safe_state_index; goto select_state; }
+
        /*
         * Prevent idle completely if CAM is active.
         * CAM does not have wakeup capability in OMAP3.
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b77df73..4b76c4c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
 {
        local_fiq_disable();
 
-       if (omap_irq_pending())
+       if (omap_irq_pending() || 1)
                goto out;
 
        trace_power_start(POWER_CSTATE, 1, smp_processor_id());

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 12:03]:
> 
> Another problem (some build errors for OMAP3) do seem to be solved, but
> not the section mismatch warnings.  They're easy to verify before code
> gets pushed anywhere upstream, especially if you're doing one giant OMAP
> build - just enable CONFIG_DEBUG_SECTION_MISMATCH in your build
> configuration.  Refuse patches which introduce section mismatches - at
> least without an explanation backing up why they do.
>
> My OMAP3 and OMAP4 configurations spit out these - I've not even tried
> my OMAP2 configuration yet:

Weird. The warnings you're seeing all seem valid to me, but I'm not seeing
any the section warnings with the following compilers I have:

gcc version 4.3.5 (Debian 4.3.5-4)
gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)
gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70)

I see _different_ warnings if I compile with an older gcc:
gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)

Any ideas why that would be?

The only warnings I see are:

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19a4): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19a8): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19ac): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19b0): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19b4): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x12b70): Section mismatch in reference from the function cm_t35_init_usbh() to the (unknown reference) .init.data:(unknown)
The function cm_t35_init_usbh() references
the (unknown reference) __initdata (unknown).
This is often because cm_t35_init_usbh lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: vmlinux.o(.text+0x1c424): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: vmlinux.o(.text+0x1c428): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: vmlinux.o(.text+0x1c42c): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: vmlinux.o(.text+0x1c430): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: vmlinux.o(.text+0x1c434): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

WARNING: vmlinux.o(.text+0x2d5f0): Section mismatch in reference from the function cm_t35_init_usbh() to the (unknown reference) .init.data:(unknown)
The function cm_t35_init_usbh() references
the (unknown reference) __initdata (unknown).
This is often because cm_t35_init_usbh lacks a __initdata 
annotation or the annotation of (unknown) is wrong.

[PATCH] arm: omap3: cm-t35: fix section mismatch warning

[Igor Grinberg]

WARNING: arch/arm/mach-omap2/built-in.o(.text+0xeae8):
Section mismatch in reference from the function cm_t35_init_usbh()
to the (unknown reference) .init.data:(unknown)
The function cm_t35_init_usbh() references
the (unknown reference) __initdata (unknown).
This is often because cm_t35_init_usbh lacks a __initdata
annotation or the annotation of (unknown) is wrong.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
---
Sorry about this one. I fixed similar problem for cm-t3517 a while ago,
but somehow missed cm-t35. Thanks for spotting.
Probably enabling the CONFIG_DEBUG_SECTION_MISMATCH in defconfigs
can raise people awareness for this.

 arch/arm/mach-omap2/board-cm-t35.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index d839c05..a8cedbe 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -436,7 +436,7 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
 	.reset_gpio_port[2]  = -EINVAL
 };
 
-static void cm_t35_init_usbh(void)
+static void  __init cm_t35_init_usbh(void)
 {
 	int err;
 
-- 
1.7.3.4

[PATCH] arm: omap3: cm-t35: fix section mismatch warning

[Igor Grinberg]

WARNING: arch/arm/mach-omap2/built-in.o(.text+0xeae8):
Section mismatch in reference from the function cm_t35_init_usbh()
to the (unknown reference) .init.data:(unknown)
The function cm_t35_init_usbh() references
the (unknown reference) __initdata (unknown).
This is often because cm_t35_init_usbh lacks a __initdata
annotation or the annotation of (unknown) is wrong.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
---
Sorry about this one. I fixed similar problem for cm-t3517 a while ago,
but somehow missed cm-t35. Thanks for spotting.
Probably enabling the CONFIG_DEBUG_SECTION_MISMATCH in defconfigs
can raise people awareness for this.

 arch/arm/mach-omap2/board-cm-t35.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index d839c05..a8cedbe 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -436,7 +436,7 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
 	.reset_gpio_port[2]  = -EINVAL
 };
 
-static void cm_t35_init_usbh(void)
+static void  __init cm_t35_init_usbh(void)
 {
 	int err;
 
-- 
1.7.3.4

Re: [PATCH] arm: omap3: cm-t35: fix section mismatch warning

[Tony Lindgren]

* Igor Grinberg <grinberg@compulab.co.il> [120205 03:08]:
> WARNING: arch/arm/mach-omap2/built-in.o(.text+0xeae8):
> Section mismatch in reference from the function cm_t35_init_usbh()
> to the (unknown reference) .init.data:(unknown)
> The function cm_t35_init_usbh() references
> the (unknown reference) __initdata (unknown).
> This is often because cm_t35_init_usbh lacks a __initdata
> annotation or the annotation of (unknown) is wrong.
> 
> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> ---
> Sorry about this one. I fixed similar problem for cm-t3517 a while ago,
> but somehow missed cm-t35. Thanks for spotting.
> Probably enabling the CONFIG_DEBUG_SECTION_MISMATCH in defconfigs
> can raise people awareness for this.

Thanks applying into fixes. Yes let's plan on doing that,
and also make sure we're actually seeing the warnings..

Tony
 
>  arch/arm/mach-omap2/board-cm-t35.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
> index d839c05..a8cedbe 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -436,7 +436,7 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
>  	.reset_gpio_port[2]  = -EINVAL
>  };
>  
> -static void cm_t35_init_usbh(void)
> +static void  __init cm_t35_init_usbh(void)
>  {
>  	int err;
>  
> -- 
> 1.7.3.4
> 

[PATCH] arm: omap3: cm-t35: fix section mismatch warning

[Tony Lindgren]

* Igor Grinberg <grinberg@compulab.co.il> [120205 03:08]:
> WARNING: arch/arm/mach-omap2/built-in.o(.text+0xeae8):
> Section mismatch in reference from the function cm_t35_init_usbh()
> to the (unknown reference) .init.data:(unknown)
> The function cm_t35_init_usbh() references
> the (unknown reference) __initdata (unknown).
> This is often because cm_t35_init_usbh lacks a __initdata
> annotation or the annotation of (unknown) is wrong.
> 
> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> ---
> Sorry about this one. I fixed similar problem for cm-t3517 a while ago,
> but somehow missed cm-t35. Thanks for spotting.
> Probably enabling the CONFIG_DEBUG_SECTION_MISMATCH in defconfigs
> can raise people awareness for this.

Thanks applying into fixes. Yes let's plan on doing that,
and also make sure we're actually seeing the warnings..

Tony
 
>  arch/arm/mach-omap2/board-cm-t35.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
> index d839c05..a8cedbe 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -436,7 +436,7 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
>  	.reset_gpio_port[2]  = -EINVAL
>  };
>  
> -static void cm_t35_init_usbh(void)
> +static void  __init cm_t35_init_usbh(void)
>  {
>  	int err;
>  
> -- 
> 1.7.3.4
> 

[PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Igor Grinberg]

This patch updates omapX_defconfig to 3.3-rc1 and enables
the CONFIG_DEBUG_SECTION_MISMATCH.

The update is done by:
1) make mrproper && make omapX_defconfig
2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
3) make savedefconfig
4) cp defconfig arch/arm/configs/omapX_defconfig

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
---
After updating omap1_defconfig,
there are several section mismatch warnings seen.
Hopefully, I will have time to fix those tomorrow
(unless someone will be kind enough to fix them before me).
The mismatches are:

WARNING: vmlinux.o(.data+0xb7e4): Section mismatch in reference from
the variable latch1_gpio_device to the (unknown reference) .init.rodata:(unknown)
The variable latch1_gpio_device references
the (unknown reference) __initconst (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

WARNING: vmlinux.o(.data+0xb8f4): Section mismatch in reference from
the variable latch1_gpio_device to the (unknown reference) .init.rodata:(unknown)
The variable latch1_gpio_device references
the (unknown reference) __initconst (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

WARNING: vmlinux.o(.data+0xb974): Section mismatch in reference from
the variable latch2_gpio_device to the (unknown reference) .init.rodata:(unknown)
The variable latch2_gpio_device references
the (unknown reference) __initconst (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

WARNING: vmlinux.o(.data+0xba84): Section mismatch in reference from
the variable latch2_gpio_device to the (unknown reference) .init.rodata:(unknown)
The variable latch2_gpio_device references
the (unknown reference) __initconst (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

WARNING: vmlinux.o(.data+0xbb04): Section mismatch in reference from
the variable ams_delta_kp_device to the (unknown reference) .init.data:(unknown)
The variable ams_delta_kp_device 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


 arch/arm/configs/omap1_defconfig     |   35 +++++++++++----------------------
 arch/arm/configs/omap2plus_defconfig |   25 ++++++++---------------
 2 files changed, 21 insertions(+), 39 deletions(-)

diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig
index dde2a1a..1122156 100644
--- a/arch/arm/configs/omap1_defconfig
+++ b/arch/arm/configs/omap1_defconfig
@@ -20,6 +20,7 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_MODULE_FORCE_UNLOAD=y
 # CONFIG_LBDAF is not set
 # CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
 # CONFIG_IOSCHED_DEADLINE is not set
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_ARCH_OMAP=y
@@ -27,7 +28,6 @@ CONFIG_ARCH_OMAP1=y
 CONFIG_OMAP_RESET_CLOCKS=y
 # CONFIG_OMAP_MUX is not set
 CONFIG_OMAP_MBOX_FWK=y
-CONFIG_OMAP_32K_TIMER=y
 CONFIG_OMAP_DM_TIMER=y
 CONFIG_ARCH_OMAP730=y
 CONFIG_ARCH_OMAP850=y
@@ -62,7 +62,6 @@ CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_CMDLINE="root=1f03 rootfstype=jffs2"
 CONFIG_FPE_NWFPE=y
 CONFIG_BINFMT_MISC=y
-CONFIG_PM=y
 # CONFIG_SUSPEND is not set
 CONFIG_PM_RUNTIME=y
 CONFIG_NET=y
@@ -82,8 +81,6 @@ CONFIG_IP_PNP_BOOTP=y
 CONFIG_IPV6=y
 CONFIG_NETFILTER=y
 CONFIG_BT=y
-CONFIG_BT_L2CAP=y
-CONFIG_BT_SCO=y
 CONFIG_BT_RFCOMM=y
 CONFIG_BT_RFCOMM_TTY=y
 CONFIG_BT_BNEP=y
@@ -94,9 +91,6 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_CONNECTOR=y
 # CONFIG_PROC_EVENTS is not set
 CONFIG_MTD=y
-CONFIG_MTD_DEBUG=y
-CONFIG_MTD_DEBUG_VERBOSE=3
-CONFIG_MTD_PARTITIONS=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_CHAR=y
 CONFIG_MTD_BLOCK=y
@@ -118,9 +112,16 @@ CONFIG_CHR_DEV_SG=y
 CONFIG_SCSI_MULTI_LUN=y
 CONFIG_NETDEVICES=y
 CONFIG_TUN=y
-CONFIG_PHYLIB=y
-CONFIG_NET_ETHERNET=y
 CONFIG_SMC91X=y
+CONFIG_PHYLIB=y
+CONFIG_PPP=y
+CONFIG_PPP_BSDCOMP=y
+CONFIG_PPP_DEFLATE=y
+CONFIG_PPP_FILTER=y
+CONFIG_PPP_MULTILINK=y
+CONFIG_PPP_ASYNC=y
+CONFIG_SLIP=y
+CONFIG_SLIP_COMPRESSED=y
 CONFIG_USB_CATC=y
 CONFIG_USB_KAWETH=y
 CONFIG_USB_PEGASUS=y
@@ -128,14 +129,6 @@ CONFIG_USB_RTL8150=y
 CONFIG_USB_USBNET=y
 # CONFIG_USB_NET_AX8817X is not set
 # CONFIG_USB_NET_CDC_SUBSET is not set
-CONFIG_PPP=y
-CONFIG_PPP_MULTILINK=y
-CONFIG_PPP_FILTER=y
-CONFIG_PPP_ASYNC=y
-CONFIG_PPP_DEFLATE=y
-CONFIG_PPP_BSDCOMP=y
-CONFIG_SLIP=y
-CONFIG_SLIP_COMPRESSED=y
 # CONFIG_INPUT_MOUSEDEV is not set
 CONFIG_INPUT_EVDEV=y
 CONFIG_INPUT_EVBUG=y
@@ -146,11 +139,11 @@ CONFIG_TOUCHSCREEN_ADS7846=y
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_UINPUT=y
 # CONFIG_SERIO is not set
+# CONFIG_LEGACY_PTYS is not set
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_NR_UARTS=3
 CONFIG_SERIAL_8250_RUNTIME_UARTS=3
-# CONFIG_LEGACY_PTYS is not set
 CONFIG_HW_RANDOM=y
 CONFIG_I2C=y
 CONFIG_I2C_CHARDEV=y
@@ -247,7 +240,6 @@ CONFIG_NFS_FS=y
 CONFIG_NFS_V3=y
 CONFIG_NFS_V4=y
 CONFIG_ROOT_NFS=y
-CONFIG_PARTITION_ADVANCED=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_CODEPAGE_850=y
 CONFIG_NLS_CODEPAGE_852=y
@@ -261,16 +253,13 @@ CONFIG_NLS_KOI8_R=y
 CONFIG_NLS_UTF8=y
 # CONFIG_ENABLE_MUST_CHECK is not set
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
+CONFIG_DEBUG_SECTION_MISMATCH=y
 CONFIG_DEBUG_SPINLOCK=y
 CONFIG_DEBUG_MUTEXES=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
 CONFIG_DEBUG_USER=y
-CONFIG_DEBUG_ERRORS=y
 CONFIG_SECURITY=y
-CONFIG_CRYPTO_ECB=y
 CONFIG_CRYPTO_PCBC=y
 CONFIG_CRYPTO_DEFLATE=y
 CONFIG_CRYPTO_ZLIB=y
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index d5f00d7..e2e30ef 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -7,8 +7,6 @@ CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=16
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
-# CONFIG_SYSCTL_SYSCALL is not set
-CONFIG_KALLSYMS_EXTRA_PASS=y
 CONFIG_SLAB=y
 CONFIG_PROFILING=y
 CONFIG_OPROFILE=y
@@ -20,6 +18,7 @@ CONFIG_MODULE_FORCE_UNLOAD=y
 CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 # CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
 CONFIG_ARCH_OMAP=y
 CONFIG_OMAP_RESET_CLOCKS=y
 CONFIG_OMAP_MUX_DEBUG=y
@@ -87,21 +86,20 @@ CONFIG_SCSI_MULTI_LUN=y
 CONFIG_SCSI_SCAN_ASYNC=y
 CONFIG_MD=y
 CONFIG_NETDEVICES=y
-CONFIG_SMSC_PHY=y
-CONFIG_NET_ETHERNET=y
-CONFIG_SMC91X=y
-CONFIG_SMSC911X=y
 CONFIG_KS8851=y
 CONFIG_KS8851_MLL=y
-CONFIG_LIBERTAS=m
-CONFIG_LIBERTAS_USB=m
-CONFIG_LIBERTAS_SDIO=m
-CONFIG_LIBERTAS_DEBUG=y
+CONFIG_SMC91X=y
+CONFIG_SMSC911X=y
+CONFIG_SMSC_PHY=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_ALI_M5632=y
 CONFIG_USB_AN2720=y
 CONFIG_USB_EPSON2888=y
 CONFIG_USB_KC2190=y
+CONFIG_LIBERTAS=m
+CONFIG_LIBERTAS_USB=m
+CONFIG_LIBERTAS_SDIO=m
+CONFIG_LIBERTAS_DEBUG=y
 CONFIG_INPUT_JOYDEV=y
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
@@ -137,7 +135,6 @@ CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_TILEBLITTING=y
-CONFIG_FB_OMAP_LCD_VGA=y
 CONFIG_OMAP2_DSS=m
 CONFIG_OMAP2_DSS_RFBI=y
 CONFIG_OMAP2_DSS_SDI=y
@@ -152,7 +149,6 @@ CONFIG_PANEL_ACX565AKM=m
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=y
-CONFIG_DISPLAY_SUPPORT=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_FONTS=y
@@ -213,19 +209,16 @@ CONFIG_NFS_V3=y
 CONFIG_NFS_V3_ACL=y
 CONFIG_NFS_V4=y
 CONFIG_ROOT_NFS=y
-CONFIG_PARTITION_ADVANCED=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_PRINTK_TIME=y
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
+CONFIG_DEBUG_SECTION_MISMATCH=y
 CONFIG_SCHEDSTATS=y
 CONFIG_TIMER_STATS=y
 CONFIG_PROVE_LOCKING=y
-CONFIG_DEBUG_SPINLOCK_SLEEP=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
 CONFIG_SECURITY=y
 CONFIG_CRYPTO_MICHAEL_MIC=y
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
-- 
1.7.3.4

[PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Igor Grinberg]

This patch updates omapX_defconfig to 3.3-rc1 and enables
the CONFIG_DEBUG_SECTION_MISMATCH.

The update is done by:
1) make mrproper && make omapX_defconfig
2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
3) make savedefconfig
4) cp defconfig arch/arm/configs/omapX_defconfig

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
---
After updating omap1_defconfig,
there are several section mismatch warnings seen.
Hopefully, I will have time to fix those tomorrow
(unless someone will be kind enough to fix them before me).
The mismatches are:

WARNING: vmlinux.o(.data+0xb7e4): Section mismatch in reference from
the variable latch1_gpio_device to the (unknown reference) .init.rodata:(unknown)
The variable latch1_gpio_device references
the (unknown reference) __initconst (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

WARNING: vmlinux.o(.data+0xb8f4): Section mismatch in reference from
the variable latch1_gpio_device to the (unknown reference) .init.rodata:(unknown)
The variable latch1_gpio_device references
the (unknown reference) __initconst (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

WARNING: vmlinux.o(.data+0xb974): Section mismatch in reference from
the variable latch2_gpio_device to the (unknown reference) .init.rodata:(unknown)
The variable latch2_gpio_device references
the (unknown reference) __initconst (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

WARNING: vmlinux.o(.data+0xba84): Section mismatch in reference from
the variable latch2_gpio_device to the (unknown reference) .init.rodata:(unknown)
The variable latch2_gpio_device references
the (unknown reference) __initconst (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

WARNING: vmlinux.o(.data+0xbb04): Section mismatch in reference from
the variable ams_delta_kp_device to the (unknown reference) .init.data:(unknown)
The variable ams_delta_kp_device 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


 arch/arm/configs/omap1_defconfig     |   35 +++++++++++----------------------
 arch/arm/configs/omap2plus_defconfig |   25 ++++++++---------------
 2 files changed, 21 insertions(+), 39 deletions(-)

diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig
index dde2a1a..1122156 100644
--- a/arch/arm/configs/omap1_defconfig
+++ b/arch/arm/configs/omap1_defconfig
@@ -20,6 +20,7 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_MODULE_FORCE_UNLOAD=y
 # CONFIG_LBDAF is not set
 # CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
 # CONFIG_IOSCHED_DEADLINE is not set
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_ARCH_OMAP=y
@@ -27,7 +28,6 @@ CONFIG_ARCH_OMAP1=y
 CONFIG_OMAP_RESET_CLOCKS=y
 # CONFIG_OMAP_MUX is not set
 CONFIG_OMAP_MBOX_FWK=y
-CONFIG_OMAP_32K_TIMER=y
 CONFIG_OMAP_DM_TIMER=y
 CONFIG_ARCH_OMAP730=y
 CONFIG_ARCH_OMAP850=y
@@ -62,7 +62,6 @@ CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_CMDLINE="root=1f03 rootfstype=jffs2"
 CONFIG_FPE_NWFPE=y
 CONFIG_BINFMT_MISC=y
-CONFIG_PM=y
 # CONFIG_SUSPEND is not set
 CONFIG_PM_RUNTIME=y
 CONFIG_NET=y
@@ -82,8 +81,6 @@ CONFIG_IP_PNP_BOOTP=y
 CONFIG_IPV6=y
 CONFIG_NETFILTER=y
 CONFIG_BT=y
-CONFIG_BT_L2CAP=y
-CONFIG_BT_SCO=y
 CONFIG_BT_RFCOMM=y
 CONFIG_BT_RFCOMM_TTY=y
 CONFIG_BT_BNEP=y
@@ -94,9 +91,6 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_CONNECTOR=y
 # CONFIG_PROC_EVENTS is not set
 CONFIG_MTD=y
-CONFIG_MTD_DEBUG=y
-CONFIG_MTD_DEBUG_VERBOSE=3
-CONFIG_MTD_PARTITIONS=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_CHAR=y
 CONFIG_MTD_BLOCK=y
@@ -118,9 +112,16 @@ CONFIG_CHR_DEV_SG=y
 CONFIG_SCSI_MULTI_LUN=y
 CONFIG_NETDEVICES=y
 CONFIG_TUN=y
-CONFIG_PHYLIB=y
-CONFIG_NET_ETHERNET=y
 CONFIG_SMC91X=y
+CONFIG_PHYLIB=y
+CONFIG_PPP=y
+CONFIG_PPP_BSDCOMP=y
+CONFIG_PPP_DEFLATE=y
+CONFIG_PPP_FILTER=y
+CONFIG_PPP_MULTILINK=y
+CONFIG_PPP_ASYNC=y
+CONFIG_SLIP=y
+CONFIG_SLIP_COMPRESSED=y
 CONFIG_USB_CATC=y
 CONFIG_USB_KAWETH=y
 CONFIG_USB_PEGASUS=y
@@ -128,14 +129,6 @@ CONFIG_USB_RTL8150=y
 CONFIG_USB_USBNET=y
 # CONFIG_USB_NET_AX8817X is not set
 # CONFIG_USB_NET_CDC_SUBSET is not set
-CONFIG_PPP=y
-CONFIG_PPP_MULTILINK=y
-CONFIG_PPP_FILTER=y
-CONFIG_PPP_ASYNC=y
-CONFIG_PPP_DEFLATE=y
-CONFIG_PPP_BSDCOMP=y
-CONFIG_SLIP=y
-CONFIG_SLIP_COMPRESSED=y
 # CONFIG_INPUT_MOUSEDEV is not set
 CONFIG_INPUT_EVDEV=y
 CONFIG_INPUT_EVBUG=y
@@ -146,11 +139,11 @@ CONFIG_TOUCHSCREEN_ADS7846=y
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_UINPUT=y
 # CONFIG_SERIO is not set
+# CONFIG_LEGACY_PTYS is not set
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_NR_UARTS=3
 CONFIG_SERIAL_8250_RUNTIME_UARTS=3
-# CONFIG_LEGACY_PTYS is not set
 CONFIG_HW_RANDOM=y
 CONFIG_I2C=y
 CONFIG_I2C_CHARDEV=y
@@ -247,7 +240,6 @@ CONFIG_NFS_FS=y
 CONFIG_NFS_V3=y
 CONFIG_NFS_V4=y
 CONFIG_ROOT_NFS=y
-CONFIG_PARTITION_ADVANCED=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_CODEPAGE_850=y
 CONFIG_NLS_CODEPAGE_852=y
@@ -261,16 +253,13 @@ CONFIG_NLS_KOI8_R=y
 CONFIG_NLS_UTF8=y
 # CONFIG_ENABLE_MUST_CHECK is not set
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
+CONFIG_DEBUG_SECTION_MISMATCH=y
 CONFIG_DEBUG_SPINLOCK=y
 CONFIG_DEBUG_MUTEXES=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
 CONFIG_DEBUG_USER=y
-CONFIG_DEBUG_ERRORS=y
 CONFIG_SECURITY=y
-CONFIG_CRYPTO_ECB=y
 CONFIG_CRYPTO_PCBC=y
 CONFIG_CRYPTO_DEFLATE=y
 CONFIG_CRYPTO_ZLIB=y
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index d5f00d7..e2e30ef 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -7,8 +7,6 @@ CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=16
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
-# CONFIG_SYSCTL_SYSCALL is not set
-CONFIG_KALLSYMS_EXTRA_PASS=y
 CONFIG_SLAB=y
 CONFIG_PROFILING=y
 CONFIG_OPROFILE=y
@@ -20,6 +18,7 @@ CONFIG_MODULE_FORCE_UNLOAD=y
 CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 # CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
 CONFIG_ARCH_OMAP=y
 CONFIG_OMAP_RESET_CLOCKS=y
 CONFIG_OMAP_MUX_DEBUG=y
@@ -87,21 +86,20 @@ CONFIG_SCSI_MULTI_LUN=y
 CONFIG_SCSI_SCAN_ASYNC=y
 CONFIG_MD=y
 CONFIG_NETDEVICES=y
-CONFIG_SMSC_PHY=y
-CONFIG_NET_ETHERNET=y
-CONFIG_SMC91X=y
-CONFIG_SMSC911X=y
 CONFIG_KS8851=y
 CONFIG_KS8851_MLL=y
-CONFIG_LIBERTAS=m
-CONFIG_LIBERTAS_USB=m
-CONFIG_LIBERTAS_SDIO=m
-CONFIG_LIBERTAS_DEBUG=y
+CONFIG_SMC91X=y
+CONFIG_SMSC911X=y
+CONFIG_SMSC_PHY=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_ALI_M5632=y
 CONFIG_USB_AN2720=y
 CONFIG_USB_EPSON2888=y
 CONFIG_USB_KC2190=y
+CONFIG_LIBERTAS=m
+CONFIG_LIBERTAS_USB=m
+CONFIG_LIBERTAS_SDIO=m
+CONFIG_LIBERTAS_DEBUG=y
 CONFIG_INPUT_JOYDEV=y
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
@@ -137,7 +135,6 @@ CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_TILEBLITTING=y
-CONFIG_FB_OMAP_LCD_VGA=y
 CONFIG_OMAP2_DSS=m
 CONFIG_OMAP2_DSS_RFBI=y
 CONFIG_OMAP2_DSS_SDI=y
@@ -152,7 +149,6 @@ CONFIG_PANEL_ACX565AKM=m
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=y
-CONFIG_DISPLAY_SUPPORT=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_FONTS=y
@@ -213,19 +209,16 @@ CONFIG_NFS_V3=y
 CONFIG_NFS_V3_ACL=y
 CONFIG_NFS_V4=y
 CONFIG_ROOT_NFS=y
-CONFIG_PARTITION_ADVANCED=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_PRINTK_TIME=y
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
+CONFIG_DEBUG_SECTION_MISMATCH=y
 CONFIG_SCHEDSTATS=y
 CONFIG_TIMER_STATS=y
 CONFIG_PROVE_LOCKING=y
-CONFIG_DEBUG_SPINLOCK_SLEEP=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
 CONFIG_SECURITY=y
 CONFIG_CRYPTO_MICHAEL_MIC=y
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
-- 
1.7.3.4

Re: [PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 12:16:13PM +0200, Igor Grinberg wrote:
> This patch updates omapX_defconfig to 3.3-rc1 and enables
> the CONFIG_DEBUG_SECTION_MISMATCH.

You shouldn't enable this in the kernel supplied defconfigs.

> The update is done by:
> 1) make mrproper && make omapX_defconfig
> 2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
> 3) make savedefconfig
> 4) cp defconfig arch/arm/configs/omapX_defconfig
> 
> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> ---
> After updating omap1_defconfig,
> there are several section mismatch warnings seen.
> Hopefully, I will have time to fix those tomorrow
> (unless someone will be kind enough to fix them before me).
> The mismatches are:

The correct way is to build with:

make ... CONFIG_DEBUG_SECTION_MISMATCH=y

or set it in your private configuration.

[PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 12:16:13PM +0200, Igor Grinberg wrote:
> This patch updates omapX_defconfig to 3.3-rc1 and enables
> the CONFIG_DEBUG_SECTION_MISMATCH.

You shouldn't enable this in the kernel supplied defconfigs.

> The update is done by:
> 1) make mrproper && make omapX_defconfig
> 2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
> 3) make savedefconfig
> 4) cp defconfig arch/arm/configs/omapX_defconfig
> 
> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> ---
> After updating omap1_defconfig,
> there are several section mismatch warnings seen.
> Hopefully, I will have time to fix those tomorrow
> (unless someone will be kind enough to fix them before me).
> The mismatches are:

The correct way is to build with:

make ... CONFIG_DEBUG_SECTION_MISMATCH=y

or set it in your private configuration.

Re: [PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Igor Grinberg]

Hi Russell,

On 02/08/12 12:19, Russell King - ARM Linux wrote:
> On Wed, Feb 08, 2012 at 12:16:13PM +0200, Igor Grinberg wrote:
>> This patch updates omapX_defconfig to 3.3-rc1 and enables
>> the CONFIG_DEBUG_SECTION_MISMATCH.
> 
> You shouldn't enable this in the kernel supplied defconfigs.

Hmmm... Ok, looks like I've forgot the purpose of defconfigs...
It is intended for users rather than developers (right?) and
the CONFIG_DEBUG_SECTION_MISMATCH has no use for users?
Is it the case, or is there anything else?

> 
>> The update is done by:
>> 1) make mrproper && make omapX_defconfig
>> 2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
>> 3) make savedefconfig
>> 4) cp defconfig arch/arm/configs/omapX_defconfig
>>
>> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
>> ---
>> After updating omap1_defconfig,
>> there are several section mismatch warnings seen.
>> Hopefully, I will have time to fix those tomorrow
>> (unless someone will be kind enough to fix them before me).
>> The mismatches are:
> 
> The correct way is to build with:
> 
> make ... CONFIG_DEBUG_SECTION_MISMATCH=y
> 
> or set it in your private configuration.

In my current setup, command line switch would be most appropriate.
Thanks for suggestion.


-- 
Regards,
Igor.

[PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Igor Grinberg]

Hi Russell,

On 02/08/12 12:19, Russell King - ARM Linux wrote:
> On Wed, Feb 08, 2012 at 12:16:13PM +0200, Igor Grinberg wrote:
>> This patch updates omapX_defconfig to 3.3-rc1 and enables
>> the CONFIG_DEBUG_SECTION_MISMATCH.
> 
> You shouldn't enable this in the kernel supplied defconfigs.

Hmmm... Ok, looks like I've forgot the purpose of defconfigs...
It is intended for users rather than developers (right?) and
the CONFIG_DEBUG_SECTION_MISMATCH has no use for users?
Is it the case, or is there anything else?

> 
>> The update is done by:
>> 1) make mrproper && make omapX_defconfig
>> 2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
>> 3) make savedefconfig
>> 4) cp defconfig arch/arm/configs/omapX_defconfig
>>
>> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
>> ---
>> After updating omap1_defconfig,
>> there are several section mismatch warnings seen.
>> Hopefully, I will have time to fix those tomorrow
>> (unless someone will be kind enough to fix them before me).
>> The mismatches are:
> 
> The correct way is to build with:
> 
> make ... CONFIG_DEBUG_SECTION_MISMATCH=y
> 
> or set it in your private configuration.

In my current setup, command line switch would be most appropriate.
Thanks for suggestion.


-- 
Regards,
Igor.

Re: [PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 01:49]:
> On Wed, Feb 08, 2012 at 12:16:13PM +0200, Igor Grinberg wrote:
> > This patch updates omapX_defconfig to 3.3-rc1 and enables
> > the CONFIG_DEBUG_SECTION_MISMATCH.
> 
> You shouldn't enable this in the kernel supplied defconfigs.
> 
> > The update is done by:
> > 1) make mrproper && make omapX_defconfig
> > 2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
> > 3) make savedefconfig
> > 4) cp defconfig arch/arm/configs/omapX_defconfig
> > 
> > Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> > ---
> > After updating omap1_defconfig,
> > there are several section mismatch warnings seen.
> > Hopefully, I will have time to fix those tomorrow
> > (unless someone will be kind enough to fix them before me).
> > The mismatches are:
> 
> The correct way is to build with:
> 
> make ... CONFIG_DEBUG_SECTION_MISMATCH=y
> 
> or set it in your private configuration.

OK that's the way to go then. Having the unoptimizer compiler flag
-fno-inline-functions-called-once is not nice in defconfigs.. And
we should already get the warning to enable section mismatch
warnings anyways.

Regrads,

Tony

[PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 01:49]:
> On Wed, Feb 08, 2012 at 12:16:13PM +0200, Igor Grinberg wrote:
> > This patch updates omapX_defconfig to 3.3-rc1 and enables
> > the CONFIG_DEBUG_SECTION_MISMATCH.
> 
> You shouldn't enable this in the kernel supplied defconfigs.
> 
> > The update is done by:
> > 1) make mrproper && make omapX_defconfig
> > 2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
> > 3) make savedefconfig
> > 4) cp defconfig arch/arm/configs/omapX_defconfig
> > 
> > Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> > ---
> > After updating omap1_defconfig,
> > there are several section mismatch warnings seen.
> > Hopefully, I will have time to fix those tomorrow
> > (unless someone will be kind enough to fix them before me).
> > The mismatches are:
> 
> The correct way is to build with:
> 
> make ... CONFIG_DEBUG_SECTION_MISMATCH=y
> 
> or set it in your private configuration.

OK that's the way to go then. Having the unoptimizer compiler flag
-fno-inline-functions-called-once is not nice in defconfigs.. And
we should already get the warning to enable section mismatch
warnings anyways.

Regrads,

Tony

Re: [PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Janusz Krzysztofik]

On Wednesday 08 of February 2012 12:16:13 Igor Grinberg wrote:
> ...
> After updating omap1_defconfig,
> there are several section mismatch warnings seen.
> Hopefully, I will have time to fix those tomorrow
> (unless someone will be kind enough to fix them before me).

Sound like introduced with my recent ams-delta patches, sorry.
I'll have a look at them.

Thanks,
Janusz

> The mismatches are:
> 
> WARNING: vmlinux.o(.data+0xb7e4): Section mismatch in reference from
> the variable latch1_gpio_device to the (unknown reference)
> .init.rodata:(unknown) The variable latch1_gpio_device references
> the (unknown reference) __initconst (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
> 
> WARNING: vmlinux.o(.data+0xb8f4): Section mismatch in reference from
> the variable latch1_gpio_device to the (unknown reference)
> .init.rodata:(unknown) The variable latch1_gpio_device references
> the (unknown reference) __initconst (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
> 
> WARNING: vmlinux.o(.data+0xb974): Section mismatch in reference from
> the variable latch2_gpio_device to the (unknown reference)
> .init.rodata:(unknown) The variable latch2_gpio_device references
> the (unknown reference) __initconst (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
> 
> WARNING: vmlinux.o(.data+0xba84): Section mismatch in reference from
> the variable latch2_gpio_device to the (unknown reference)
> .init.rodata:(unknown) The variable latch2_gpio_device references
> the (unknown reference) __initconst (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
> 
> WARNING: vmlinux.o(.data+0xbb04): Section mismatch in reference from
> the variable ams_delta_kp_device to the (unknown reference)
> .init.data:(unknown) The variable ams_delta_kp_device 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

[PATCH] ARM: OMAP: update omap1 and omap2plus defconfigs

[Janusz Krzysztofik]

On Wednesday 08 of February 2012 12:16:13 Igor Grinberg wrote:
> ...
> After updating omap1_defconfig,
> there are several section mismatch warnings seen.
> Hopefully, I will have time to fix those tomorrow
> (unless someone will be kind enough to fix them before me).

Sound like introduced with my recent ams-delta patches, sorry.
I'll have a look at them.

Thanks,
Janusz

> The mismatches are:
> 
> WARNING: vmlinux.o(.data+0xb7e4): Section mismatch in reference from
> the variable latch1_gpio_device to the (unknown reference)
> .init.rodata:(unknown) The variable latch1_gpio_device references
> the (unknown reference) __initconst (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
> 
> WARNING: vmlinux.o(.data+0xb8f4): Section mismatch in reference from
> the variable latch1_gpio_device to the (unknown reference)
> .init.rodata:(unknown) The variable latch1_gpio_device references
> the (unknown reference) __initconst (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
> 
> WARNING: vmlinux.o(.data+0xb974): Section mismatch in reference from
> the variable latch2_gpio_device to the (unknown reference)
> .init.rodata:(unknown) The variable latch2_gpio_device references
> the (unknown reference) __initconst (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
> 
> WARNING: vmlinux.o(.data+0xba84): Section mismatch in reference from
> the variable latch2_gpio_device to the (unknown reference)
> .init.rodata:(unknown) The variable latch2_gpio_device references
> the (unknown reference) __initconst (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
> 
> WARNING: vmlinux.o(.data+0xbb04): Section mismatch in reference from
> the variable ams_delta_kp_device to the (unknown reference)
> .init.data:(unknown) The variable ams_delta_kp_device 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

[PATCH] ARM: OMAP1: ams-delta: clean up init data section assignments

[Janusz Krzysztofik]

The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced mostly with recent Amstrad Delta patch series, some of them
rising up only when building with CONFIG_MODULES not set.

While being at it, section assignments of all init data found in the
board file have been revised and hopefully optimised.

Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
 arch/arm/mach-omap1/board-ams-delta.c |   35 +++++++++++++++++----------------
 drivers/input/serio/ams_delta_serio.c |    2 +-
 drivers/mtd/nand/ams-delta.c          |    2 +-
 drivers/video/omap/lcd_ams_delta.c    |    2 +-
 4 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..dc2455f 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -126,7 +126,7 @@ static const unsigned int ams_delta_keymap[] = {
 #define LATCH2_PHYS	0x08000000
 #define LATCH2_VIRT	0xEC000000
 
-static struct map_desc ams_delta_io_desc[] __initdata = {
+static struct map_desc ams_delta_io_desc[] __initconst = {
 	/* AMS_DELTA_LATCH1 */
 	{
 		.virtual	= LATCH1_VIRT,
@@ -150,17 +150,17 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
 	}
 };
 
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initconst = {
 	.ctrl_name	= "internal",
 };
 
-static struct omap_usb_config ams_delta_usb_config __initdata = {
+static struct omap_usb_config ams_delta_usb_config __initdata_or_module = {
 	.register_host	= 1,
 	.hmc_mode	= 16,
 	.pins[0]	= 2,
 };
 
-static struct omap_board_config_kernel ams_delta_config[] __initdata = {
+static struct omap_board_config_kernel ams_delta_config[] __initconst = {
 	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
 };
 
@@ -181,7 +181,7 @@ static struct bgpio_pdata latch1_pdata __initconst = {
 	.ngpio	= LATCH1_NGPIO,
 };
 
-static struct platform_device latch1_gpio_device = {
+static struct platform_device latch1_gpio_device __refdata = {
 	.name		= "basic-mmio-gpio",
 	.id		= 0,
 	.resource	= latch1_resources,
@@ -205,7 +205,7 @@ static struct bgpio_pdata latch2_pdata __initconst = {
 	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
 };
 
-static struct platform_device latch2_gpio_device = {
+static struct platform_device latch2_gpio_device __refdata = {
 	.name		= "basic-mmio-gpio",
 	.id		= 1,
 	.resource	= latch2_resources,
@@ -271,7 +271,7 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
 }
 EXPORT_SYMBOL(ams_delta_latch_write);
 
-static struct resource ams_delta_nand_resources[] = {
+static struct resource ams_delta_nand_resources[] __initconst_or_module = {
 	[0] = {
 		.start	= OMAP1_MPUIO_BASE,
 		.end	= OMAP1_MPUIO_BASE +
@@ -280,14 +280,14 @@ static struct resource ams_delta_nand_resources[] = {
 	},
 };
 
-static struct platform_device ams_delta_nand_device = {
+static struct platform_device ams_delta_nand_device __refdata = {
 	.name	= "ams-delta-nand",
 	.id	= -1,
 	.num_resources	= ARRAY_SIZE(ams_delta_nand_resources),
 	.resource	= ams_delta_nand_resources,
 };
 
-static struct resource ams_delta_kp_resources[] = {
+static struct resource ams_delta_kp_resources[] __initconst_or_module = {
 	[0] = {
 		.start	= INT_KEYBOARD,
 		.end	= INT_KEYBOARD,
@@ -300,14 +300,14 @@ static const struct matrix_keymap_data ams_delta_keymap_data = {
 	.keymap_size	= ARRAY_SIZE(ams_delta_keymap),
 };
 
-static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
+static struct omap_kp_platform_data ams_delta_kp_data __initconst_or_module = {
 	.rows		= 8,
 	.cols		= 8,
 	.keymap_data	= &ams_delta_keymap_data,
 	.delay		= 9,
 };
 
-static struct platform_device ams_delta_kp_device = {
+static struct platform_device ams_delta_kp_device __refdata = {
 	.name		= "omap-keypad",
 	.id		= -1,
 	.dev		= {
@@ -363,7 +363,8 @@ static struct gpio_led_platform_data leds_pdata __initconst = {
 	.num_leds	= ARRAY_SIZE(gpio_leds),
 };
 
-static struct i2c_board_info ams_delta_camera_board_info[] = {
+static struct i2c_board_info __initconst_or_module
+ams_delta_camera_board_info[] = {
 	{
 		I2C_BOARD_INFO("ov6650", 0x60),
 	},
@@ -387,7 +388,7 @@ static int ams_delta_camera_power(struct device *dev, int power)
 #define ams_delta_camera_power	NULL
 #endif
 
-static struct soc_camera_link ams_delta_iclink = {
+static struct soc_camera_link ams_delta_iclink __initconst_or_module = {
 	.bus_id         = 0,	/* OMAP1 SoC camera bus */
 	.i2c_adapter_id = 1,
 	.board_info     = &ams_delta_camera_board_info[0],
@@ -395,7 +396,7 @@ static struct soc_camera_link ams_delta_iclink = {
 	.power		= ams_delta_camera_power,
 };
 
-static struct platform_device ams_delta_camera_device = {
+static struct platform_device ams_delta_camera_device __refdata = {
 	.name   = "soc-camera-pdrv",
 	.id     = 0,
 	.dev    = {
@@ -408,7 +409,7 @@ static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
 	.lclk_khz_max	= 1334,		/* results in 5fps CIF, 10fps QCIF */
 };
 
-static struct platform_device *ams_delta_devices[] __initdata = {
+static struct platform_device *ams_delta_devices[] __initconst = {
 	&latch1_gpio_device,
 	&latch2_gpio_device,
 	&ams_delta_kp_device,
@@ -459,7 +460,7 @@ static void __init ams_delta_init(void)
 	omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
 }
 
-static struct plat_serial8250_port ams_delta_modem_ports[] = {
+static struct plat_serial8250_port ams_delta_modem_ports[] __initdata = {
 	{
 		.membase	= IOMEM(MODEM_VIRT),
 		.mapbase	= MODEM_PHYS,
@@ -473,7 +474,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
 	{ },
 };
 
-static struct platform_device ams_delta_modem_device = {
+static struct platform_device ams_delta_modem_device __refdata = {
 	.name	= "serial8250",
 	.id	= PLAT8250_DEV_PLATFORM1,
 	.dev		= {
diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
index 0571e2e..0830a76 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -103,7 +103,7 @@ static void ams_delta_serio_close(struct serio *serio)
 	gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
 }
 
-static struct gpio ams_delta_gpios[] __initconst_or_module = {
+static const struct gpio ams_delta_gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
 		.flags	= GPIOF_DIR_IN,
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 85934dc..7341695 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -145,7 +145,7 @@ static int ams_delta_nand_ready(struct mtd_info *mtd)
 	return gpio_get_value(AMS_DELTA_GPIO_PIN_NAND_RB);
 }
 
-static struct gpio _mandatory_gpio[] __initconst_or_module = {
+static const struct gpio _mandatory_gpio[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_NAND_NCE,
 		.flags	= GPIOF_OUT_INIT_HIGH,
diff --git a/drivers/video/omap/lcd_ams_delta.c b/drivers/video/omap/lcd_ams_delta.c
index 0e71e28..d3a3113 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -99,7 +99,7 @@ static struct lcd_ops ams_delta_lcd_ops = {
 
 /* omapfb panel section */
 
-static struct gpio _gpios[] __initconst_or_module = {
+static const struct gpio _gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_LCD_VBLEN,
 		.flags	= GPIOF_OUT_INIT_LOW,
-- 
1.7.3.4

[PATCH] ARM: OMAP1: ams-delta: clean up init data section assignments

[Janusz Krzysztofik]

The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced mostly with recent Amstrad Delta patch series, some of them
rising up only when building with CONFIG_MODULES not set.

While being at it, section assignments of all init data found in the
board file have been revised and hopefully optimised.

Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
 arch/arm/mach-omap1/board-ams-delta.c |   35 +++++++++++++++++----------------
 drivers/input/serio/ams_delta_serio.c |    2 +-
 drivers/mtd/nand/ams-delta.c          |    2 +-
 drivers/video/omap/lcd_ams_delta.c    |    2 +-
 4 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..dc2455f 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -126,7 +126,7 @@ static const unsigned int ams_delta_keymap[] = {
 #define LATCH2_PHYS	0x08000000
 #define LATCH2_VIRT	0xEC000000
 
-static struct map_desc ams_delta_io_desc[] __initdata = {
+static struct map_desc ams_delta_io_desc[] __initconst = {
 	/* AMS_DELTA_LATCH1 */
 	{
 		.virtual	= LATCH1_VIRT,
@@ -150,17 +150,17 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
 	}
 };
 
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initconst = {
 	.ctrl_name	= "internal",
 };
 
-static struct omap_usb_config ams_delta_usb_config __initdata = {
+static struct omap_usb_config ams_delta_usb_config __initdata_or_module = {
 	.register_host	= 1,
 	.hmc_mode	= 16,
 	.pins[0]	= 2,
 };
 
-static struct omap_board_config_kernel ams_delta_config[] __initdata = {
+static struct omap_board_config_kernel ams_delta_config[] __initconst = {
 	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
 };
 
@@ -181,7 +181,7 @@ static struct bgpio_pdata latch1_pdata __initconst = {
 	.ngpio	= LATCH1_NGPIO,
 };
 
-static struct platform_device latch1_gpio_device = {
+static struct platform_device latch1_gpio_device __refdata = {
 	.name		= "basic-mmio-gpio",
 	.id		= 0,
 	.resource	= latch1_resources,
@@ -205,7 +205,7 @@ static struct bgpio_pdata latch2_pdata __initconst = {
 	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
 };
 
-static struct platform_device latch2_gpio_device = {
+static struct platform_device latch2_gpio_device __refdata = {
 	.name		= "basic-mmio-gpio",
 	.id		= 1,
 	.resource	= latch2_resources,
@@ -271,7 +271,7 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
 }
 EXPORT_SYMBOL(ams_delta_latch_write);
 
-static struct resource ams_delta_nand_resources[] = {
+static struct resource ams_delta_nand_resources[] __initconst_or_module = {
 	[0] = {
 		.start	= OMAP1_MPUIO_BASE,
 		.end	= OMAP1_MPUIO_BASE +
@@ -280,14 +280,14 @@ static struct resource ams_delta_nand_resources[] = {
 	},
 };
 
-static struct platform_device ams_delta_nand_device = {
+static struct platform_device ams_delta_nand_device __refdata = {
 	.name	= "ams-delta-nand",
 	.id	= -1,
 	.num_resources	= ARRAY_SIZE(ams_delta_nand_resources),
 	.resource	= ams_delta_nand_resources,
 };
 
-static struct resource ams_delta_kp_resources[] = {
+static struct resource ams_delta_kp_resources[] __initconst_or_module = {
 	[0] = {
 		.start	= INT_KEYBOARD,
 		.end	= INT_KEYBOARD,
@@ -300,14 +300,14 @@ static const struct matrix_keymap_data ams_delta_keymap_data = {
 	.keymap_size	= ARRAY_SIZE(ams_delta_keymap),
 };
 
-static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
+static struct omap_kp_platform_data ams_delta_kp_data __initconst_or_module = {
 	.rows		= 8,
 	.cols		= 8,
 	.keymap_data	= &ams_delta_keymap_data,
 	.delay		= 9,
 };
 
-static struct platform_device ams_delta_kp_device = {
+static struct platform_device ams_delta_kp_device __refdata = {
 	.name		= "omap-keypad",
 	.id		= -1,
 	.dev		= {
@@ -363,7 +363,8 @@ static struct gpio_led_platform_data leds_pdata __initconst = {
 	.num_leds	= ARRAY_SIZE(gpio_leds),
 };
 
-static struct i2c_board_info ams_delta_camera_board_info[] = {
+static struct i2c_board_info __initconst_or_module
+ams_delta_camera_board_info[] = {
 	{
 		I2C_BOARD_INFO("ov6650", 0x60),
 	},
@@ -387,7 +388,7 @@ static int ams_delta_camera_power(struct device *dev, int power)
 #define ams_delta_camera_power	NULL
 #endif
 
-static struct soc_camera_link ams_delta_iclink = {
+static struct soc_camera_link ams_delta_iclink __initconst_or_module = {
 	.bus_id         = 0,	/* OMAP1 SoC camera bus */
 	.i2c_adapter_id = 1,
 	.board_info     = &ams_delta_camera_board_info[0],
@@ -395,7 +396,7 @@ static struct soc_camera_link ams_delta_iclink = {
 	.power		= ams_delta_camera_power,
 };
 
-static struct platform_device ams_delta_camera_device = {
+static struct platform_device ams_delta_camera_device __refdata = {
 	.name   = "soc-camera-pdrv",
 	.id     = 0,
 	.dev    = {
@@ -408,7 +409,7 @@ static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
 	.lclk_khz_max	= 1334,		/* results in 5fps CIF, 10fps QCIF */
 };
 
-static struct platform_device *ams_delta_devices[] __initdata = {
+static struct platform_device *ams_delta_devices[] __initconst = {
 	&latch1_gpio_device,
 	&latch2_gpio_device,
 	&ams_delta_kp_device,
@@ -459,7 +460,7 @@ static void __init ams_delta_init(void)
 	omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
 }
 
-static struct plat_serial8250_port ams_delta_modem_ports[] = {
+static struct plat_serial8250_port ams_delta_modem_ports[] __initdata = {
 	{
 		.membase	= IOMEM(MODEM_VIRT),
 		.mapbase	= MODEM_PHYS,
@@ -473,7 +474,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
 	{ },
 };
 
-static struct platform_device ams_delta_modem_device = {
+static struct platform_device ams_delta_modem_device __refdata = {
 	.name	= "serial8250",
 	.id	= PLAT8250_DEV_PLATFORM1,
 	.dev		= {
diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
index 0571e2e..0830a76 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -103,7 +103,7 @@ static void ams_delta_serio_close(struct serio *serio)
 	gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
 }
 
-static struct gpio ams_delta_gpios[] __initconst_or_module = {
+static const struct gpio ams_delta_gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
 		.flags	= GPIOF_DIR_IN,
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 85934dc..7341695 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -145,7 +145,7 @@ static int ams_delta_nand_ready(struct mtd_info *mtd)
 	return gpio_get_value(AMS_DELTA_GPIO_PIN_NAND_RB);
 }
 
-static struct gpio _mandatory_gpio[] __initconst_or_module = {
+static const struct gpio _mandatory_gpio[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_NAND_NCE,
 		.flags	= GPIOF_OUT_INIT_HIGH,
diff --git a/drivers/video/omap/lcd_ams_delta.c b/drivers/video/omap/lcd_ams_delta.c
index 0e71e28..d3a3113 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -99,7 +99,7 @@ static struct lcd_ops ams_delta_lcd_ops = {
 
 /* omapfb panel section */
 
-static struct gpio _gpios[] __initconst_or_module = {
+static const struct gpio _gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_LCD_VBLEN,
 		.flags	= GPIOF_OUT_INIT_LOW,
-- 
1.7.3.4

[PATCH] ARM: OMAP1: ams-delta: clean up init data section assignments

[Janusz Krzysztofik]

The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced mostly with recent Amstrad Delta patch series, some of them
rising up only when building with CONFIG_MODULES not set.

While being at it, section assignments of all init data found in the
board file have been revised and hopefully optimised.

Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
 arch/arm/mach-omap1/board-ams-delta.c |   35 +++++++++++++++++----------------
 drivers/input/serio/ams_delta_serio.c |    2 +-
 drivers/mtd/nand/ams-delta.c          |    2 +-
 drivers/video/omap/lcd_ams_delta.c    |    2 +-
 4 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..dc2455f 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -126,7 +126,7 @@ static const unsigned int ams_delta_keymap[] = {
 #define LATCH2_PHYS	0x08000000
 #define LATCH2_VIRT	0xEC000000
 
-static struct map_desc ams_delta_io_desc[] __initdata = {
+static struct map_desc ams_delta_io_desc[] __initconst = {
 	/* AMS_DELTA_LATCH1 */
 	{
 		.virtual	= LATCH1_VIRT,
@@ -150,17 +150,17 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
 	}
 };
 
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initconst = {
 	.ctrl_name	= "internal",
 };
 
-static struct omap_usb_config ams_delta_usb_config __initdata = {
+static struct omap_usb_config ams_delta_usb_config __initdata_or_module = {
 	.register_host	= 1,
 	.hmc_mode	= 16,
 	.pins[0]	= 2,
 };
 
-static struct omap_board_config_kernel ams_delta_config[] __initdata = {
+static struct omap_board_config_kernel ams_delta_config[] __initconst = {
 	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
 };
 
@@ -181,7 +181,7 @@ static struct bgpio_pdata latch1_pdata __initconst = {
 	.ngpio	= LATCH1_NGPIO,
 };
 
-static struct platform_device latch1_gpio_device = {
+static struct platform_device latch1_gpio_device __refdata = {
 	.name		= "basic-mmio-gpio",
 	.id		= 0,
 	.resource	= latch1_resources,
@@ -205,7 +205,7 @@ static struct bgpio_pdata latch2_pdata __initconst = {
 	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
 };
 
-static struct platform_device latch2_gpio_device = {
+static struct platform_device latch2_gpio_device __refdata = {
 	.name		= "basic-mmio-gpio",
 	.id		= 1,
 	.resource	= latch2_resources,
@@ -271,7 +271,7 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
 }
 EXPORT_SYMBOL(ams_delta_latch_write);
 
-static struct resource ams_delta_nand_resources[] = {
+static struct resource ams_delta_nand_resources[] __initconst_or_module = {
 	[0] = {
 		.start	= OMAP1_MPUIO_BASE,
 		.end	= OMAP1_MPUIO_BASE +
@@ -280,14 +280,14 @@ static struct resource ams_delta_nand_resources[] = {
 	},
 };
 
-static struct platform_device ams_delta_nand_device = {
+static struct platform_device ams_delta_nand_device __refdata = {
 	.name	= "ams-delta-nand",
 	.id	= -1,
 	.num_resources	= ARRAY_SIZE(ams_delta_nand_resources),
 	.resource	= ams_delta_nand_resources,
 };
 
-static struct resource ams_delta_kp_resources[] = {
+static struct resource ams_delta_kp_resources[] __initconst_or_module = {
 	[0] = {
 		.start	= INT_KEYBOARD,
 		.end	= INT_KEYBOARD,
@@ -300,14 +300,14 @@ static const struct matrix_keymap_data ams_delta_keymap_data = {
 	.keymap_size	= ARRAY_SIZE(ams_delta_keymap),
 };
 
-static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
+static struct omap_kp_platform_data ams_delta_kp_data __initconst_or_module = {
 	.rows		= 8,
 	.cols		= 8,
 	.keymap_data	= &ams_delta_keymap_data,
 	.delay		= 9,
 };
 
-static struct platform_device ams_delta_kp_device = {
+static struct platform_device ams_delta_kp_device __refdata = {
 	.name		= "omap-keypad",
 	.id		= -1,
 	.dev		= {
@@ -363,7 +363,8 @@ static struct gpio_led_platform_data leds_pdata __initconst = {
 	.num_leds	= ARRAY_SIZE(gpio_leds),
 };
 
-static struct i2c_board_info ams_delta_camera_board_info[] = {
+static struct i2c_board_info __initconst_or_module
+ams_delta_camera_board_info[] = {
 	{
 		I2C_BOARD_INFO("ov6650", 0x60),
 	},
@@ -387,7 +388,7 @@ static int ams_delta_camera_power(struct device *dev, int power)
 #define ams_delta_camera_power	NULL
 #endif
 
-static struct soc_camera_link ams_delta_iclink = {
+static struct soc_camera_link ams_delta_iclink __initconst_or_module = {
 	.bus_id         = 0,	/* OMAP1 SoC camera bus */
 	.i2c_adapter_id = 1,
 	.board_info     = &ams_delta_camera_board_info[0],
@@ -395,7 +396,7 @@ static struct soc_camera_link ams_delta_iclink = {
 	.power		= ams_delta_camera_power,
 };
 
-static struct platform_device ams_delta_camera_device = {
+static struct platform_device ams_delta_camera_device __refdata = {
 	.name   = "soc-camera-pdrv",
 	.id     = 0,
 	.dev    = {
@@ -408,7 +409,7 @@ static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
 	.lclk_khz_max	= 1334,		/* results in 5fps CIF, 10fps QCIF */
 };
 
-static struct platform_device *ams_delta_devices[] __initdata = {
+static struct platform_device *ams_delta_devices[] __initconst = {
 	&latch1_gpio_device,
 	&latch2_gpio_device,
 	&ams_delta_kp_device,
@@ -459,7 +460,7 @@ static void __init ams_delta_init(void)
 	omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
 }
 
-static struct plat_serial8250_port ams_delta_modem_ports[] = {
+static struct plat_serial8250_port ams_delta_modem_ports[] __initdata = {
 	{
 		.membase	= IOMEM(MODEM_VIRT),
 		.mapbase	= MODEM_PHYS,
@@ -473,7 +474,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
 	{ },
 };
 
-static struct platform_device ams_delta_modem_device = {
+static struct platform_device ams_delta_modem_device __refdata = {
 	.name	= "serial8250",
 	.id	= PLAT8250_DEV_PLATFORM1,
 	.dev		= {
diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
index 0571e2e..0830a76 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -103,7 +103,7 @@ static void ams_delta_serio_close(struct serio *serio)
 	gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
 }
 
-static struct gpio ams_delta_gpios[] __initconst_or_module = {
+static const struct gpio ams_delta_gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
 		.flags	= GPIOF_DIR_IN,
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 85934dc..7341695 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -145,7 +145,7 @@ static int ams_delta_nand_ready(struct mtd_info *mtd)
 	return gpio_get_value(AMS_DELTA_GPIO_PIN_NAND_RB);
 }
 
-static struct gpio _mandatory_gpio[] __initconst_or_module = {
+static const struct gpio _mandatory_gpio[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_NAND_NCE,
 		.flags	= GPIOF_OUT_INIT_HIGH,
diff --git a/drivers/video/omap/lcd_ams_delta.c b/drivers/video/omap/lcd_ams_delta.c
index 0e71e28..d3a3113 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -99,7 +99,7 @@ static struct lcd_ops ams_delta_lcd_ops = {
 
 /* omapfb panel section */
 
-static struct gpio _gpios[] __initconst_or_module = {
+static const struct gpio _gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_LCD_VBLEN,
 		.flags	= GPIOF_OUT_INIT_LOW,
-- 
1.7.3.4

[PATCH] ARM: OMAP1: ams-delta: clean up init data section assignments

[Janusz Krzysztofik]

The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced mostly with recent Amstrad Delta patch series, some of them
rising up only when building with CONFIG_MODULES not set.

While being at it, section assignments of all init data found in the
board file have been revised and hopefully optimised.

Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
 arch/arm/mach-omap1/board-ams-delta.c |   35 +++++++++++++++++----------------
 drivers/input/serio/ams_delta_serio.c |    2 +-
 drivers/mtd/nand/ams-delta.c          |    2 +-
 drivers/video/omap/lcd_ams_delta.c    |    2 +-
 4 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..dc2455f 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -126,7 +126,7 @@ static const unsigned int ams_delta_keymap[] = {
 #define LATCH2_PHYS	0x08000000
 #define LATCH2_VIRT	0xEC000000
 
-static struct map_desc ams_delta_io_desc[] __initdata = {
+static struct map_desc ams_delta_io_desc[] __initconst = {
 	/* AMS_DELTA_LATCH1 */
 	{
 		.virtual	= LATCH1_VIRT,
@@ -150,17 +150,17 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
 	}
 };
 
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initconst = {
 	.ctrl_name	= "internal",
 };
 
-static struct omap_usb_config ams_delta_usb_config __initdata = {
+static struct omap_usb_config ams_delta_usb_config __initdata_or_module = {
 	.register_host	= 1,
 	.hmc_mode	= 16,
 	.pins[0]	= 2,
 };
 
-static struct omap_board_config_kernel ams_delta_config[] __initdata = {
+static struct omap_board_config_kernel ams_delta_config[] __initconst = {
 	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
 };
 
@@ -181,7 +181,7 @@ static struct bgpio_pdata latch1_pdata __initconst = {
 	.ngpio	= LATCH1_NGPIO,
 };
 
-static struct platform_device latch1_gpio_device = {
+static struct platform_device latch1_gpio_device __refdata = {
 	.name		= "basic-mmio-gpio",
 	.id		= 0,
 	.resource	= latch1_resources,
@@ -205,7 +205,7 @@ static struct bgpio_pdata latch2_pdata __initconst = {
 	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
 };
 
-static struct platform_device latch2_gpio_device = {
+static struct platform_device latch2_gpio_device __refdata = {
 	.name		= "basic-mmio-gpio",
 	.id		= 1,
 	.resource	= latch2_resources,
@@ -271,7 +271,7 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
 }
 EXPORT_SYMBOL(ams_delta_latch_write);
 
-static struct resource ams_delta_nand_resources[] = {
+static struct resource ams_delta_nand_resources[] __initconst_or_module = {
 	[0] = {
 		.start	= OMAP1_MPUIO_BASE,
 		.end	= OMAP1_MPUIO_BASE +
@@ -280,14 +280,14 @@ static struct resource ams_delta_nand_resources[] = {
 	},
 };
 
-static struct platform_device ams_delta_nand_device = {
+static struct platform_device ams_delta_nand_device __refdata = {
 	.name	= "ams-delta-nand",
 	.id	= -1,
 	.num_resources	= ARRAY_SIZE(ams_delta_nand_resources),
 	.resource	= ams_delta_nand_resources,
 };
 
-static struct resource ams_delta_kp_resources[] = {
+static struct resource ams_delta_kp_resources[] __initconst_or_module = {
 	[0] = {
 		.start	= INT_KEYBOARD,
 		.end	= INT_KEYBOARD,
@@ -300,14 +300,14 @@ static const struct matrix_keymap_data ams_delta_keymap_data = {
 	.keymap_size	= ARRAY_SIZE(ams_delta_keymap),
 };
 
-static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
+static struct omap_kp_platform_data ams_delta_kp_data __initconst_or_module = {
 	.rows		= 8,
 	.cols		= 8,
 	.keymap_data	= &ams_delta_keymap_data,
 	.delay		= 9,
 };
 
-static struct platform_device ams_delta_kp_device = {
+static struct platform_device ams_delta_kp_device __refdata = {
 	.name		= "omap-keypad",
 	.id		= -1,
 	.dev		= {
@@ -363,7 +363,8 @@ static struct gpio_led_platform_data leds_pdata __initconst = {
 	.num_leds	= ARRAY_SIZE(gpio_leds),
 };
 
-static struct i2c_board_info ams_delta_camera_board_info[] = {
+static struct i2c_board_info __initconst_or_module
+ams_delta_camera_board_info[] = {
 	{
 		I2C_BOARD_INFO("ov6650", 0x60),
 	},
@@ -387,7 +388,7 @@ static int ams_delta_camera_power(struct device *dev, int power)
 #define ams_delta_camera_power	NULL
 #endif
 
-static struct soc_camera_link ams_delta_iclink = {
+static struct soc_camera_link ams_delta_iclink __initconst_or_module = {
 	.bus_id         = 0,	/* OMAP1 SoC camera bus */
 	.i2c_adapter_id = 1,
 	.board_info     = &ams_delta_camera_board_info[0],
@@ -395,7 +396,7 @@ static struct soc_camera_link ams_delta_iclink = {
 	.power		= ams_delta_camera_power,
 };
 
-static struct platform_device ams_delta_camera_device = {
+static struct platform_device ams_delta_camera_device __refdata = {
 	.name   = "soc-camera-pdrv",
 	.id     = 0,
 	.dev    = {
@@ -408,7 +409,7 @@ static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
 	.lclk_khz_max	= 1334,		/* results in 5fps CIF, 10fps QCIF */
 };
 
-static struct platform_device *ams_delta_devices[] __initdata = {
+static struct platform_device *ams_delta_devices[] __initconst = {
 	&latch1_gpio_device,
 	&latch2_gpio_device,
 	&ams_delta_kp_device,
@@ -459,7 +460,7 @@ static void __init ams_delta_init(void)
 	omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
 }
 
-static struct plat_serial8250_port ams_delta_modem_ports[] = {
+static struct plat_serial8250_port ams_delta_modem_ports[] __initdata = {
 	{
 		.membase	= IOMEM(MODEM_VIRT),
 		.mapbase	= MODEM_PHYS,
@@ -473,7 +474,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
 	{ },
 };
 
-static struct platform_device ams_delta_modem_device = {
+static struct platform_device ams_delta_modem_device __refdata = {
 	.name	= "serial8250",
 	.id	= PLAT8250_DEV_PLATFORM1,
 	.dev		= {
diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
index 0571e2e..0830a76 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -103,7 +103,7 @@ static void ams_delta_serio_close(struct serio *serio)
 	gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
 }
 
-static struct gpio ams_delta_gpios[] __initconst_or_module = {
+static const struct gpio ams_delta_gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
 		.flags	= GPIOF_DIR_IN,
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 85934dc..7341695 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -145,7 +145,7 @@ static int ams_delta_nand_ready(struct mtd_info *mtd)
 	return gpio_get_value(AMS_DELTA_GPIO_PIN_NAND_RB);
 }
 
-static struct gpio _mandatory_gpio[] __initconst_or_module = {
+static const struct gpio _mandatory_gpio[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_NAND_NCE,
 		.flags	= GPIOF_OUT_INIT_HIGH,
diff --git a/drivers/video/omap/lcd_ams_delta.c b/drivers/video/omap/lcd_ams_delta.c
index 0e71e28..d3a3113 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -99,7 +99,7 @@ static struct lcd_ops ams_delta_lcd_ops = {
 
 /* omapfb panel section */
 
-static struct gpio _gpios[] __initconst_or_module = {
+static const struct gpio _gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_LCD_VBLEN,
 		.flags	= GPIOF_OUT_INIT_LOW,
-- 
1.7.3.4

Re: [PATCH] ARM: OMAP1: ams-delta: clean up init data section assignments

[Russell King - ARM Linux]

On Thu, Feb 09, 2012 at 12:18:22PM +0100, Janusz Krzysztofik wrote:
> The main purpose of this patch is to fix several section mismatch
> warnings from the board file and a few board specific drivers,
> introduced mostly with recent Amstrad Delta patch series, some of them
> rising up only when building with CONFIG_MODULES not set.
> 
> While being at it, section assignments of all init data found in the
> board file have been revised and hopefully optimised.

There is no optimisation to adding __refdata to stuff.  That's screaming
that you have lots of bugs here.

> 
> Created and tested on top of current linux-omap/omap1, commit
> 967809bd7faf71ddc29c8081e0f21db8b201a0f4.
> 
> Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> ---
>  arch/arm/mach-omap1/board-ams-delta.c |   35 +++++++++++++++++----------------
>  drivers/input/serio/ams_delta_serio.c |    2 +-
>  drivers/mtd/nand/ams-delta.c          |    2 +-
>  drivers/video/omap/lcd_ams_delta.c    |    2 +-
>  4 files changed, 21 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index 87b1303..dc2455f 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -126,7 +126,7 @@ static const unsigned int ams_delta_keymap[] = {
>  #define LATCH2_PHYS	0x08000000
>  #define LATCH2_VIRT	0xEC000000
>  
> -static struct map_desc ams_delta_io_desc[] __initdata = {
> +static struct map_desc ams_delta_io_desc[] __initconst = {

You're not making this comst so don't change it to __initconst.

>  	/* AMS_DELTA_LATCH1 */
>  	{
>  		.virtual	= LATCH1_VIRT,
> @@ -150,17 +150,17 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
>  	}
>  };
>  
> -static struct omap_lcd_config ams_delta_lcd_config = {
> +static struct omap_lcd_config ams_delta_lcd_config __initconst = {

This change probably adds a bug.  Are you sure this will never be used
outside init context?

>  	.ctrl_name	= "internal",
>  };
>  
> -static struct omap_usb_config ams_delta_usb_config __initdata = {
> +static struct omap_usb_config ams_delta_usb_config __initdata_or_module = {

Even if you don't have modules enabled, have you checked whether the
driver can be bound and unbound via
/sys/bus/platform/driver/<name>/{bind,unbind} ?

I suspect this is a bug.

>  	.register_host	= 1,
>  	.hmc_mode	= 16,
>  	.pins[0]	= 2,
>  };
>  
> -static struct omap_board_config_kernel ams_delta_config[] __initdata = {
> +static struct omap_board_config_kernel ams_delta_config[] __initconst = {
>  	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
>  };
>  
> @@ -181,7 +181,7 @@ static struct bgpio_pdata latch1_pdata __initconst = {
>  	.ngpio	= LATCH1_NGPIO,
>  };
>  
> -static struct platform_device latch1_gpio_device = {
> +static struct platform_device latch1_gpio_device __refdata = {
>  	.name		= "basic-mmio-gpio",
>  	.id		= 0,
>  	.resource	= latch1_resources,
> @@ -205,7 +205,7 @@ static struct bgpio_pdata latch2_pdata __initconst = {
>  	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
>  };
>  
> -static struct platform_device latch2_gpio_device = {
> +static struct platform_device latch2_gpio_device __refdata = {
>  	.name		= "basic-mmio-gpio",
>  	.id		= 1,
>  	.resource	= latch2_resources,
> @@ -271,7 +271,7 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
>  }
>  EXPORT_SYMBOL(ams_delta_latch_write);
>  
> -static struct resource ams_delta_nand_resources[] = {
> +static struct resource ams_delta_nand_resources[] __initconst_or_module = {

This change definitely adds a bug.  The resources are _used_ _all_ _the_
_time_ _the_ _device_ _is_ _registered_.  Try catting /proc/iomem after
boot.

>  	[0] = {
>  		.start	= OMAP1_MPUIO_BASE,
>  		.end	= OMAP1_MPUIO_BASE +
> @@ -280,14 +280,14 @@ static struct resource ams_delta_nand_resources[] = {
>  	},
>  };
>  
> -static struct platform_device ams_delta_nand_device = {
> +static struct platform_device ams_delta_nand_device __refdata = {

Therefore, bug.

>  	.name	= "ams-delta-nand",
>  	.id	= -1,
>  	.num_resources	= ARRAY_SIZE(ams_delta_nand_resources),
>  	.resource	= ams_delta_nand_resources,
>  };
>  
> -static struct resource ams_delta_kp_resources[] = {
> +static struct resource ams_delta_kp_resources[] __initconst_or_module = {

Bug.

>  	[0] = {
>  		.start	= INT_KEYBOARD,
>  		.end	= INT_KEYBOARD,
> @@ -300,14 +300,14 @@ static const struct matrix_keymap_data ams_delta_keymap_data = {
>  	.keymap_size	= ARRAY_SIZE(ams_delta_keymap),
>  };
>  
> -static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
> +static struct omap_kp_platform_data ams_delta_kp_data __initconst_or_module = {

Probably a bug if you unbind/rebind the associated driver with modules
disabled.

>  	.rows		= 8,
>  	.cols		= 8,
>  	.keymap_data	= &ams_delta_keymap_data,
>  	.delay		= 9,
>  };
>  
> -static struct platform_device ams_delta_kp_device = {
> +static struct platform_device ams_delta_kp_device __refdata = {
>  	.name		= "omap-keypad",
>  	.id		= -1,
>  	.dev		= {
> @@ -363,7 +363,8 @@ static struct gpio_led_platform_data leds_pdata __initconst = {
>  	.num_leds	= ARRAY_SIZE(gpio_leds),
>  };
>  
> -static struct i2c_board_info ams_delta_camera_board_info[] = {
> +static struct i2c_board_info __initconst_or_module
> +ams_delta_camera_board_info[] = {

No.  It's

static struct foo blah[] __whatever_init_attribute

not

static struct foo __whatever_init_attribute blah[]

I've no idea where this fucked idea came from but it's something that's
wasting a lot of review time with complaints like this about it.

>  	{
>  		I2C_BOARD_INFO("ov6650", 0x60),
>  	},
> @@ -387,7 +388,7 @@ static int ams_delta_camera_power(struct device *dev, int power)
>  #define ams_delta_camera_power	NULL
>  #endif
>  
> -static struct soc_camera_link ams_delta_iclink = {
> +static struct soc_camera_link ams_delta_iclink __initconst_or_module = {

Probably buggy.

>  	.bus_id         = 0,	/* OMAP1 SoC camera bus */
>  	.i2c_adapter_id = 1,
>  	.board_info     = &ams_delta_camera_board_info[0],
> @@ -395,7 +396,7 @@ static struct soc_camera_link ams_delta_iclink = {
>  	.power		= ams_delta_camera_power,
>  };
>  
> -static struct platform_device ams_delta_camera_device = {
> +static struct platform_device ams_delta_camera_device __refdata = {
>  	.name   = "soc-camera-pdrv",
>  	.id     = 0,
>  	.dev    = {
> @@ -408,7 +409,7 @@ static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
>  	.lclk_khz_max	= 1334,		/* results in 5fps CIF, 10fps QCIF */
>  };
>  
> -static struct platform_device *ams_delta_devices[] __initdata = {
> +static struct platform_device *ams_delta_devices[] __initconst = {

Missing const.  If you can't const it, don't put it in __initconst.

>  	&latch1_gpio_device,
>  	&latch2_gpio_device,
>  	&ams_delta_kp_device,
> @@ -459,7 +460,7 @@ static void __init ams_delta_init(void)
>  	omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
>  }
>  
> -static struct plat_serial8250_port ams_delta_modem_ports[] = {
> +static struct plat_serial8250_port ams_delta_modem_ports[] __initdata = {

Buggy.

>  	{
>  		.membase	= IOMEM(MODEM_VIRT),
>  		.mapbase	= MODEM_PHYS,
> @@ -473,7 +474,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
>  	{ },
>  };
>  
> -static struct platform_device ams_delta_modem_device = {
> +static struct platform_device ams_delta_modem_device __refdata = {
>  	.name	= "serial8250",
>  	.id	= PLAT8250_DEV_PLATFORM1,
>  	.dev		= {

[PATCH] ARM: OMAP1: ams-delta: clean up init data section assignments

[Russell King - ARM Linux]

On Thu, Feb 09, 2012 at 12:18:22PM +0100, Janusz Krzysztofik wrote:
> The main purpose of this patch is to fix several section mismatch
> warnings from the board file and a few board specific drivers,
> introduced mostly with recent Amstrad Delta patch series, some of them
> rising up only when building with CONFIG_MODULES not set.
> 
> While being at it, section assignments of all init data found in the
> board file have been revised and hopefully optimised.

There is no optimisation to adding __refdata to stuff.  That's screaming
that you have lots of bugs here.

> 
> Created and tested on top of current linux-omap/omap1, commit
> 967809bd7faf71ddc29c8081e0f21db8b201a0f4.
> 
> Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> ---
>  arch/arm/mach-omap1/board-ams-delta.c |   35 +++++++++++++++++----------------
>  drivers/input/serio/ams_delta_serio.c |    2 +-
>  drivers/mtd/nand/ams-delta.c          |    2 +-
>  drivers/video/omap/lcd_ams_delta.c    |    2 +-
>  4 files changed, 21 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index 87b1303..dc2455f 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -126,7 +126,7 @@ static const unsigned int ams_delta_keymap[] = {
>  #define LATCH2_PHYS	0x08000000
>  #define LATCH2_VIRT	0xEC000000
>  
> -static struct map_desc ams_delta_io_desc[] __initdata = {
> +static struct map_desc ams_delta_io_desc[] __initconst = {

You're not making this comst so don't change it to __initconst.

>  	/* AMS_DELTA_LATCH1 */
>  	{
>  		.virtual	= LATCH1_VIRT,
> @@ -150,17 +150,17 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
>  	}
>  };
>  
> -static struct omap_lcd_config ams_delta_lcd_config = {
> +static struct omap_lcd_config ams_delta_lcd_config __initconst = {

This change probably adds a bug.  Are you sure this will never be used
outside init context?

>  	.ctrl_name	= "internal",
>  };
>  
> -static struct omap_usb_config ams_delta_usb_config __initdata = {
> +static struct omap_usb_config ams_delta_usb_config __initdata_or_module = {

Even if you don't have modules enabled, have you checked whether the
driver can be bound and unbound via
/sys/bus/platform/driver/<name>/{bind,unbind} ?

I suspect this is a bug.

>  	.register_host	= 1,
>  	.hmc_mode	= 16,
>  	.pins[0]	= 2,
>  };
>  
> -static struct omap_board_config_kernel ams_delta_config[] __initdata = {
> +static struct omap_board_config_kernel ams_delta_config[] __initconst = {
>  	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
>  };
>  
> @@ -181,7 +181,7 @@ static struct bgpio_pdata latch1_pdata __initconst = {
>  	.ngpio	= LATCH1_NGPIO,
>  };
>  
> -static struct platform_device latch1_gpio_device = {
> +static struct platform_device latch1_gpio_device __refdata = {
>  	.name		= "basic-mmio-gpio",
>  	.id		= 0,
>  	.resource	= latch1_resources,
> @@ -205,7 +205,7 @@ static struct bgpio_pdata latch2_pdata __initconst = {
>  	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
>  };
>  
> -static struct platform_device latch2_gpio_device = {
> +static struct platform_device latch2_gpio_device __refdata = {
>  	.name		= "basic-mmio-gpio",
>  	.id		= 1,
>  	.resource	= latch2_resources,
> @@ -271,7 +271,7 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
>  }
>  EXPORT_SYMBOL(ams_delta_latch_write);
>  
> -static struct resource ams_delta_nand_resources[] = {
> +static struct resource ams_delta_nand_resources[] __initconst_or_module = {

This change definitely adds a bug.  The resources are _used_ _all_ _the_
_time_ _the_ _device_ _is_ _registered_.  Try catting /proc/iomem after
boot.

>  	[0] = {
>  		.start	= OMAP1_MPUIO_BASE,
>  		.end	= OMAP1_MPUIO_BASE +
> @@ -280,14 +280,14 @@ static struct resource ams_delta_nand_resources[] = {
>  	},
>  };
>  
> -static struct platform_device ams_delta_nand_device = {
> +static struct platform_device ams_delta_nand_device __refdata = {

Therefore, bug.

>  	.name	= "ams-delta-nand",
>  	.id	= -1,
>  	.num_resources	= ARRAY_SIZE(ams_delta_nand_resources),
>  	.resource	= ams_delta_nand_resources,
>  };
>  
> -static struct resource ams_delta_kp_resources[] = {
> +static struct resource ams_delta_kp_resources[] __initconst_or_module = {

Bug.

>  	[0] = {
>  		.start	= INT_KEYBOARD,
>  		.end	= INT_KEYBOARD,
> @@ -300,14 +300,14 @@ static const struct matrix_keymap_data ams_delta_keymap_data = {
>  	.keymap_size	= ARRAY_SIZE(ams_delta_keymap),
>  };
>  
> -static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
> +static struct omap_kp_platform_data ams_delta_kp_data __initconst_or_module = {

Probably a bug if you unbind/rebind the associated driver with modules
disabled.

>  	.rows		= 8,
>  	.cols		= 8,
>  	.keymap_data	= &ams_delta_keymap_data,
>  	.delay		= 9,
>  };
>  
> -static struct platform_device ams_delta_kp_device = {
> +static struct platform_device ams_delta_kp_device __refdata = {
>  	.name		= "omap-keypad",
>  	.id		= -1,
>  	.dev		= {
> @@ -363,7 +363,8 @@ static struct gpio_led_platform_data leds_pdata __initconst = {
>  	.num_leds	= ARRAY_SIZE(gpio_leds),
>  };
>  
> -static struct i2c_board_info ams_delta_camera_board_info[] = {
> +static struct i2c_board_info __initconst_or_module
> +ams_delta_camera_board_info[] = {

No.  It's

static struct foo blah[] __whatever_init_attribute

not

static struct foo __whatever_init_attribute blah[]

I've no idea where this fucked idea came from but it's something that's
wasting a lot of review time with complaints like this about it.

>  	{
>  		I2C_BOARD_INFO("ov6650", 0x60),
>  	},
> @@ -387,7 +388,7 @@ static int ams_delta_camera_power(struct device *dev, int power)
>  #define ams_delta_camera_power	NULL
>  #endif
>  
> -static struct soc_camera_link ams_delta_iclink = {
> +static struct soc_camera_link ams_delta_iclink __initconst_or_module = {

Probably buggy.

>  	.bus_id         = 0,	/* OMAP1 SoC camera bus */
>  	.i2c_adapter_id = 1,
>  	.board_info     = &ams_delta_camera_board_info[0],
> @@ -395,7 +396,7 @@ static struct soc_camera_link ams_delta_iclink = {
>  	.power		= ams_delta_camera_power,
>  };
>  
> -static struct platform_device ams_delta_camera_device = {
> +static struct platform_device ams_delta_camera_device __refdata = {
>  	.name   = "soc-camera-pdrv",
>  	.id     = 0,
>  	.dev    = {
> @@ -408,7 +409,7 @@ static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
>  	.lclk_khz_max	= 1334,		/* results in 5fps CIF, 10fps QCIF */
>  };
>  
> -static struct platform_device *ams_delta_devices[] __initdata = {
> +static struct platform_device *ams_delta_devices[] __initconst = {

Missing const.  If you can't const it, don't put it in __initconst.

>  	&latch1_gpio_device,
>  	&latch2_gpio_device,
>  	&ams_delta_kp_device,
> @@ -459,7 +460,7 @@ static void __init ams_delta_init(void)
>  	omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
>  }
>  
> -static struct plat_serial8250_port ams_delta_modem_ports[] = {
> +static struct plat_serial8250_port ams_delta_modem_ports[] __initdata = {

Buggy.

>  	{
>  		.membase	= IOMEM(MODEM_VIRT),
>  		.mapbase	= MODEM_PHYS,
> @@ -473,7 +474,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
>  	{ },
>  };
>  
> -static struct platform_device ams_delta_modem_device = {
> +static struct platform_device ams_delta_modem_device __refdata = {
>  	.name	= "serial8250",
>  	.id	= PLAT8250_DEV_PLATFORM1,
>  	.dev		= {

Re: [PATCH] ARM: OMAP1: ams-delta: clean up init data section assignments

[Russell King - ARM Linux]

On Thu, Feb 09, 2012 at 12:18:22PM +0100, Janusz Krzysztofik wrote:
> The main purpose of this patch is to fix several section mismatch
> warnings from the board file and a few board specific drivers,
> introduced mostly with recent Amstrad Delta patch series, some of them
> rising up only when building with CONFIG_MODULES not set.
> 
> While being at it, section assignments of all init data found in the
> board file have been revised and hopefully optimised.

There is no optimisation to adding __refdata to stuff.  That's screaming
that you have lots of bugs here.

> 
> Created and tested on top of current linux-omap/omap1, commit
> 967809bd7faf71ddc29c8081e0f21db8b201a0f4.
> 
> Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> ---
>  arch/arm/mach-omap1/board-ams-delta.c |   35 +++++++++++++++++----------------
>  drivers/input/serio/ams_delta_serio.c |    2 +-
>  drivers/mtd/nand/ams-delta.c          |    2 +-
>  drivers/video/omap/lcd_ams_delta.c    |    2 +-
>  4 files changed, 21 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index 87b1303..dc2455f 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -126,7 +126,7 @@ static const unsigned int ams_delta_keymap[] = {
>  #define LATCH2_PHYS	0x08000000
>  #define LATCH2_VIRT	0xEC000000
>  
> -static struct map_desc ams_delta_io_desc[] __initdata = {
> +static struct map_desc ams_delta_io_desc[] __initconst = {

You're not making this comst so don't change it to __initconst.

>  	/* AMS_DELTA_LATCH1 */
>  	{
>  		.virtual	= LATCH1_VIRT,
> @@ -150,17 +150,17 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
>  	}
>  };
>  
> -static struct omap_lcd_config ams_delta_lcd_config = {
> +static struct omap_lcd_config ams_delta_lcd_config __initconst = {

This change probably adds a bug.  Are you sure this will never be used
outside init context?

>  	.ctrl_name	= "internal",
>  };
>  
> -static struct omap_usb_config ams_delta_usb_config __initdata = {
> +static struct omap_usb_config ams_delta_usb_config __initdata_or_module = {

Even if you don't have modules enabled, have you checked whether the
driver can be bound and unbound via
/sys/bus/platform/driver/<name>/{bind,unbind} ?

I suspect this is a bug.

>  	.register_host	= 1,
>  	.hmc_mode	= 16,
>  	.pins[0]	= 2,
>  };
>  
> -static struct omap_board_config_kernel ams_delta_config[] __initdata = {
> +static struct omap_board_config_kernel ams_delta_config[] __initconst = {
>  	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
>  };
>  
> @@ -181,7 +181,7 @@ static struct bgpio_pdata latch1_pdata __initconst = {
>  	.ngpio	= LATCH1_NGPIO,
>  };
>  
> -static struct platform_device latch1_gpio_device = {
> +static struct platform_device latch1_gpio_device __refdata = {
>  	.name		= "basic-mmio-gpio",
>  	.id		= 0,
>  	.resource	= latch1_resources,
> @@ -205,7 +205,7 @@ static struct bgpio_pdata latch2_pdata __initconst = {
>  	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
>  };
>  
> -static struct platform_device latch2_gpio_device = {
> +static struct platform_device latch2_gpio_device __refdata = {
>  	.name		= "basic-mmio-gpio",
>  	.id		= 1,
>  	.resource	= latch2_resources,
> @@ -271,7 +271,7 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
>  }
>  EXPORT_SYMBOL(ams_delta_latch_write);
>  
> -static struct resource ams_delta_nand_resources[] = {
> +static struct resource ams_delta_nand_resources[] __initconst_or_module = {

This change definitely adds a bug.  The resources are _used_ _all_ _the_
_time_ _the_ _device_ _is_ _registered_.  Try catting /proc/iomem after
boot.

>  	[0] = {
>  		.start	= OMAP1_MPUIO_BASE,
>  		.end	= OMAP1_MPUIO_BASE +
> @@ -280,14 +280,14 @@ static struct resource ams_delta_nand_resources[] = {
>  	},
>  };
>  
> -static struct platform_device ams_delta_nand_device = {
> +static struct platform_device ams_delta_nand_device __refdata = {

Therefore, bug.

>  	.name	= "ams-delta-nand",
>  	.id	= -1,
>  	.num_resources	= ARRAY_SIZE(ams_delta_nand_resources),
>  	.resource	= ams_delta_nand_resources,
>  };
>  
> -static struct resource ams_delta_kp_resources[] = {
> +static struct resource ams_delta_kp_resources[] __initconst_or_module = {

Bug.

>  	[0] = {
>  		.start	= INT_KEYBOARD,
>  		.end	= INT_KEYBOARD,
> @@ -300,14 +300,14 @@ static const struct matrix_keymap_data ams_delta_keymap_data = {
>  	.keymap_size	= ARRAY_SIZE(ams_delta_keymap),
>  };
>  
> -static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
> +static struct omap_kp_platform_data ams_delta_kp_data __initconst_or_module = {

Probably a bug if you unbind/rebind the associated driver with modules
disabled.

>  	.rows		= 8,
>  	.cols		= 8,
>  	.keymap_data	= &ams_delta_keymap_data,
>  	.delay		= 9,
>  };
>  
> -static struct platform_device ams_delta_kp_device = {
> +static struct platform_device ams_delta_kp_device __refdata = {
>  	.name		= "omap-keypad",
>  	.id		= -1,
>  	.dev		= {
> @@ -363,7 +363,8 @@ static struct gpio_led_platform_data leds_pdata __initconst = {
>  	.num_leds	= ARRAY_SIZE(gpio_leds),
>  };
>  
> -static struct i2c_board_info ams_delta_camera_board_info[] = {
> +static struct i2c_board_info __initconst_or_module
> +ams_delta_camera_board_info[] = {

No.  It's

static struct foo blah[] __whatever_init_attribute

not

static struct foo __whatever_init_attribute blah[]

I've no idea where this fucked idea came from but it's something that's
wasting a lot of review time with complaints like this about it.

>  	{
>  		I2C_BOARD_INFO("ov6650", 0x60),
>  	},
> @@ -387,7 +388,7 @@ static int ams_delta_camera_power(struct device *dev, int power)
>  #define ams_delta_camera_power	NULL
>  #endif
>  
> -static struct soc_camera_link ams_delta_iclink = {
> +static struct soc_camera_link ams_delta_iclink __initconst_or_module = {

Probably buggy.

>  	.bus_id         = 0,	/* OMAP1 SoC camera bus */
>  	.i2c_adapter_id = 1,
>  	.board_info     = &ams_delta_camera_board_info[0],
> @@ -395,7 +396,7 @@ static struct soc_camera_link ams_delta_iclink = {
>  	.power		= ams_delta_camera_power,
>  };
>  
> -static struct platform_device ams_delta_camera_device = {
> +static struct platform_device ams_delta_camera_device __refdata = {
>  	.name   = "soc-camera-pdrv",
>  	.id     = 0,
>  	.dev    = {
> @@ -408,7 +409,7 @@ static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
>  	.lclk_khz_max	= 1334,		/* results in 5fps CIF, 10fps QCIF */
>  };
>  
> -static struct platform_device *ams_delta_devices[] __initdata = {
> +static struct platform_device *ams_delta_devices[] __initconst = {

Missing const.  If you can't const it, don't put it in __initconst.

>  	&latch1_gpio_device,
>  	&latch2_gpio_device,
>  	&ams_delta_kp_device,
> @@ -459,7 +460,7 @@ static void __init ams_delta_init(void)
>  	omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
>  }
>  
> -static struct plat_serial8250_port ams_delta_modem_ports[] = {
> +static struct plat_serial8250_port ams_delta_modem_ports[] __initdata = {

Buggy.

>  	{
>  		.membase	= IOMEM(MODEM_VIRT),
>  		.mapbase	= MODEM_PHYS,
> @@ -473,7 +474,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
>  	{ },
>  };
>  
> -static struct platform_device ams_delta_modem_device = {
> +static struct platform_device ams_delta_modem_device __refdata = {
>  	.name	= "serial8250",
>  	.id	= PLAT8250_DEV_PLATFORM1,
>  	.dev		= {

Re: [PATCH] ARM: OMAP1: ams-delta: clean up init data section assignments

[Russell King - ARM Linux]

On Thu, Feb 09, 2012 at 12:18:22PM +0100, Janusz Krzysztofik wrote:
> The main purpose of this patch is to fix several section mismatch
> warnings from the board file and a few board specific drivers,
> introduced mostly with recent Amstrad Delta patch series, some of them
> rising up only when building with CONFIG_MODULES not set.
> 
> While being at it, section assignments of all init data found in the
> board file have been revised and hopefully optimised.

There is no optimisation to adding __refdata to stuff.  That's screaming
that you have lots of bugs here.

> 
> Created and tested on top of current linux-omap/omap1, commit
> 967809bd7faf71ddc29c8081e0f21db8b201a0f4.
> 
> Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> ---
>  arch/arm/mach-omap1/board-ams-delta.c |   35 +++++++++++++++++----------------
>  drivers/input/serio/ams_delta_serio.c |    2 +-
>  drivers/mtd/nand/ams-delta.c          |    2 +-
>  drivers/video/omap/lcd_ams_delta.c    |    2 +-
>  4 files changed, 21 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index 87b1303..dc2455f 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -126,7 +126,7 @@ static const unsigned int ams_delta_keymap[] = {
>  #define LATCH2_PHYS	0x08000000
>  #define LATCH2_VIRT	0xEC000000
>  
> -static struct map_desc ams_delta_io_desc[] __initdata = {
> +static struct map_desc ams_delta_io_desc[] __initconst = {

You're not making this comst so don't change it to __initconst.

>  	/* AMS_DELTA_LATCH1 */
>  	{
>  		.virtual	= LATCH1_VIRT,
> @@ -150,17 +150,17 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
>  	}
>  };
>  
> -static struct omap_lcd_config ams_delta_lcd_config = {
> +static struct omap_lcd_config ams_delta_lcd_config __initconst = {

This change probably adds a bug.  Are you sure this will never be used
outside init context?

>  	.ctrl_name	= "internal",
>  };
>  
> -static struct omap_usb_config ams_delta_usb_config __initdata = {
> +static struct omap_usb_config ams_delta_usb_config __initdata_or_module = {

Even if you don't have modules enabled, have you checked whether the
driver can be bound and unbound via
/sys/bus/platform/driver/<name>/{bind,unbind} ?

I suspect this is a bug.

>  	.register_host	= 1,
>  	.hmc_mode	= 16,
>  	.pins[0]	= 2,
>  };
>  
> -static struct omap_board_config_kernel ams_delta_config[] __initdata = {
> +static struct omap_board_config_kernel ams_delta_config[] __initconst = {
>  	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
>  };
>  
> @@ -181,7 +181,7 @@ static struct bgpio_pdata latch1_pdata __initconst = {
>  	.ngpio	= LATCH1_NGPIO,
>  };
>  
> -static struct platform_device latch1_gpio_device = {
> +static struct platform_device latch1_gpio_device __refdata = {
>  	.name		= "basic-mmio-gpio",
>  	.id		= 0,
>  	.resource	= latch1_resources,
> @@ -205,7 +205,7 @@ static struct bgpio_pdata latch2_pdata __initconst = {
>  	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
>  };
>  
> -static struct platform_device latch2_gpio_device = {
> +static struct platform_device latch2_gpio_device __refdata = {
>  	.name		= "basic-mmio-gpio",
>  	.id		= 1,
>  	.resource	= latch2_resources,
> @@ -271,7 +271,7 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
>  }
>  EXPORT_SYMBOL(ams_delta_latch_write);
>  
> -static struct resource ams_delta_nand_resources[] = {
> +static struct resource ams_delta_nand_resources[] __initconst_or_module = {

This change definitely adds a bug.  The resources are _used_ _all_ _the_
_time_ _the_ _device_ _is_ _registered_.  Try catting /proc/iomem after
boot.

>  	[0] = {
>  		.start	= OMAP1_MPUIO_BASE,
>  		.end	= OMAP1_MPUIO_BASE +
> @@ -280,14 +280,14 @@ static struct resource ams_delta_nand_resources[] = {
>  	},
>  };
>  
> -static struct platform_device ams_delta_nand_device = {
> +static struct platform_device ams_delta_nand_device __refdata = {

Therefore, bug.

>  	.name	= "ams-delta-nand",
>  	.id	= -1,
>  	.num_resources	= ARRAY_SIZE(ams_delta_nand_resources),
>  	.resource	= ams_delta_nand_resources,
>  };
>  
> -static struct resource ams_delta_kp_resources[] = {
> +static struct resource ams_delta_kp_resources[] __initconst_or_module = {

Bug.

>  	[0] = {
>  		.start	= INT_KEYBOARD,
>  		.end	= INT_KEYBOARD,
> @@ -300,14 +300,14 @@ static const struct matrix_keymap_data ams_delta_keymap_data = {
>  	.keymap_size	= ARRAY_SIZE(ams_delta_keymap),
>  };
>  
> -static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
> +static struct omap_kp_platform_data ams_delta_kp_data __initconst_or_module = {

Probably a bug if you unbind/rebind the associated driver with modules
disabled.

>  	.rows		= 8,
>  	.cols		= 8,
>  	.keymap_data	= &ams_delta_keymap_data,
>  	.delay		= 9,
>  };
>  
> -static struct platform_device ams_delta_kp_device = {
> +static struct platform_device ams_delta_kp_device __refdata = {
>  	.name		= "omap-keypad",
>  	.id		= -1,
>  	.dev		= {
> @@ -363,7 +363,8 @@ static struct gpio_led_platform_data leds_pdata __initconst = {
>  	.num_leds	= ARRAY_SIZE(gpio_leds),
>  };
>  
> -static struct i2c_board_info ams_delta_camera_board_info[] = {
> +static struct i2c_board_info __initconst_or_module
> +ams_delta_camera_board_info[] = {

No.  It's

static struct foo blah[] __whatever_init_attribute

not

static struct foo __whatever_init_attribute blah[]

I've no idea where this fucked idea came from but it's something that's
wasting a lot of review time with complaints like this about it.

>  	{
>  		I2C_BOARD_INFO("ov6650", 0x60),
>  	},
> @@ -387,7 +388,7 @@ static int ams_delta_camera_power(struct device *dev, int power)
>  #define ams_delta_camera_power	NULL
>  #endif
>  
> -static struct soc_camera_link ams_delta_iclink = {
> +static struct soc_camera_link ams_delta_iclink __initconst_or_module = {

Probably buggy.

>  	.bus_id         = 0,	/* OMAP1 SoC camera bus */
>  	.i2c_adapter_id = 1,
>  	.board_info     = &ams_delta_camera_board_info[0],
> @@ -395,7 +396,7 @@ static struct soc_camera_link ams_delta_iclink = {
>  	.power		= ams_delta_camera_power,
>  };
>  
> -static struct platform_device ams_delta_camera_device = {
> +static struct platform_device ams_delta_camera_device __refdata = {
>  	.name   = "soc-camera-pdrv",
>  	.id     = 0,
>  	.dev    = {
> @@ -408,7 +409,7 @@ static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
>  	.lclk_khz_max	= 1334,		/* results in 5fps CIF, 10fps QCIF */
>  };
>  
> -static struct platform_device *ams_delta_devices[] __initdata = {
> +static struct platform_device *ams_delta_devices[] __initconst = {

Missing const.  If you can't const it, don't put it in __initconst.

>  	&latch1_gpio_device,
>  	&latch2_gpio_device,
>  	&ams_delta_kp_device,
> @@ -459,7 +460,7 @@ static void __init ams_delta_init(void)
>  	omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
>  }
>  
> -static struct plat_serial8250_port ams_delta_modem_ports[] = {
> +static struct plat_serial8250_port ams_delta_modem_ports[] __initdata = {

Buggy.

>  	{
>  		.membase	= IOMEM(MODEM_VIRT),
>  		.mapbase	= MODEM_PHYS,
> @@ -473,7 +474,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
>  	{ },
>  };
>  
> -static struct platform_device ams_delta_modem_device = {
> +static struct platform_device ams_delta_modem_device __refdata = {
>  	.name	= "serial8250",
>  	.id	= PLAT8250_DEV_PLATFORM1,
>  	.dev		= {

Re: [PATCH] ARM: OMAP1: ams-delta: correct init data section assignments

[Janusz Krzysztofik]

On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:

> There is no optimisation to adding __refdata to stuff.  That's screaming
> that you have lots of bugs here.

Thanks for your teaching. I find those aspects not very exhaustively documented 
under Documentation/, so any hints are much appreciated.

> > -static struct map_desc ams_delta_io_desc[] __initdata = {
> > +static struct map_desc ams_delta_io_desc[] __initconst = {
> 
> You're not making this comst so don't change it to __initconst.

OK, however, I think there must be a bug in gcc, otherwise it should probably 
never accept such wrong constructs, while sometimes it does (not only mine, 
see [1]).

> > -static struct omap_lcd_config ams_delta_lcd_config = {
> > +static struct omap_lcd_config ams_delta_lcd_config __initconst = {
> 
> This change probably adds a bug.  Are you sure this will never be used
> outside init context?

I may be wrong, but before I've changed this, and now once again, I've verified 
that a copy of this data is made inside __init omap_init_fb() by means of a 
structure assignment operation.

> > -static struct omap_usb_config ams_delta_usb_config __initdata = {
> > +static struct omap_usb_config ams_delta_usb_config __initdata_or_module
> > = {
> Even if you don't have modules enabled, have you checked whether the
> driver can be bound and unbound via
> /sys/bus/platform/driver/<name>/{bind,unbind} ?

No, I didn't even think of it, I am afraid.

> I suspect this is a bug.

Indeed, that data is not copied on init, only pointed to, moreover, the 
ohci-omap driver provides bind/unbind opearations.

BTW, what are those bind/unbind operations intended for in case of a driver 
dedicated to a non-hotplugable SoC hardware exclusively?

> > -static struct resource ams_delta_nand_resources[] = {
> > +static struct resource ams_delta_nand_resources[] __initconst_or_module
> > = {
> This change definitely adds a bug.  The resources are _used_ _all_ _the_
> _time_ _the_ _device_ _is_ _registered_.  Try catting /proc/iomem after
> boot.

Indeed, I didn't think of that. I expected that standard init data of only 
those devices which can be actually found during init should be copied for 
runtime access, then all (found and not found) dropped instead of keeping them 
all in memory for only some of them being actually used.

> > -static struct i2c_board_info ams_delta_camera_board_info[] = {
> > +static struct i2c_board_info __initconst_or_module
> > +ams_delta_camera_board_info[] = {
> 
> No.  It's
> 
> static struct foo blah[] __whatever_init_attribute
> 
> not
> 
> static struct foo __whatever_init_attribute blah[]
> 
> I've no idea where this fucked idea came from but it's something that's
> wasting a lot of review time with complaints like this about it.

My bad, I blindly copied that pattern from another broken example under 
arch/arm instead of examining the docs carefully enough.

> > -static struct soc_camera_link ams_delta_iclink = {
> > +static struct soc_camera_link ams_delta_iclink __initconst_or_module =
> > {
> 
> Probably buggy.

Indeed. Even if the soc-camera-pdrv driver doesn't support 
unbindind/rebinding, it doesn't seem to make a copy of that platform data, 
only stores a pointer to it for runtime access, wich I missed.

> > -static struct platform_device *ams_delta_devices[] __initdata = {
> > +static struct platform_device *ams_delta_devices[] __initconst = {
> 
> Missing const.  If you can't const it, don't put it in __initconst.

I gave up trying to use both const and __initconst together after my gcc-4.2.4 
(and not only mine, see [1], [2]) refused to accept such constructs a few 
times. Now I see that this false reporting may probably happen in presence of other 
incorrect uses of __initconst without const or __initdata with const.

Hopefully better patches will follow.

Thanks,
Janusz

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/062421.html 
[2] http://permalink.gmane.org/gmane.linux.kernel.commits.head/202285

[PATCH] ARM: OMAP1: ams-delta: correct init data section assignments

[Janusz Krzysztofik]

On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:

> There is no optimisation to adding __refdata to stuff.  That's screaming
> that you have lots of bugs here.

Thanks for your teaching. I find those aspects not very exhaustively documented 
under Documentation/, so any hints are much appreciated.

> > -static struct map_desc ams_delta_io_desc[] __initdata = {
> > +static struct map_desc ams_delta_io_desc[] __initconst = {
> 
> You're not making this comst so don't change it to __initconst.

OK, however, I think there must be a bug in gcc, otherwise it should probably 
never accept such wrong constructs, while sometimes it does (not only mine, 
see [1]).

> > -static struct omap_lcd_config ams_delta_lcd_config = {
> > +static struct omap_lcd_config ams_delta_lcd_config __initconst = {
> 
> This change probably adds a bug.  Are you sure this will never be used
> outside init context?

I may be wrong, but before I've changed this, and now once again, I've verified 
that a copy of this data is made inside __init omap_init_fb() by means of a 
structure assignment operation.

> > -static struct omap_usb_config ams_delta_usb_config __initdata = {
> > +static struct omap_usb_config ams_delta_usb_config __initdata_or_module
> > = {
> Even if you don't have modules enabled, have you checked whether the
> driver can be bound and unbound via
> /sys/bus/platform/driver/<name>/{bind,unbind} ?

No, I didn't even think of it, I am afraid.

> I suspect this is a bug.

Indeed, that data is not copied on init, only pointed to, moreover, the 
ohci-omap driver provides bind/unbind opearations.

BTW, what are those bind/unbind operations intended for in case of a driver 
dedicated to a non-hotplugable SoC hardware exclusively?

> > -static struct resource ams_delta_nand_resources[] = {
> > +static struct resource ams_delta_nand_resources[] __initconst_or_module
> > = {
> This change definitely adds a bug.  The resources are _used_ _all_ _the_
> _time_ _the_ _device_ _is_ _registered_.  Try catting /proc/iomem after
> boot.

Indeed, I didn't think of that. I expected that standard init data of only 
those devices which can be actually found during init should be copied for 
runtime access, then all (found and not found) dropped instead of keeping them 
all in memory for only some of them being actually used.

> > -static struct i2c_board_info ams_delta_camera_board_info[] = {
> > +static struct i2c_board_info __initconst_or_module
> > +ams_delta_camera_board_info[] = {
> 
> No.  It's
> 
> static struct foo blah[] __whatever_init_attribute
> 
> not
> 
> static struct foo __whatever_init_attribute blah[]
> 
> I've no idea where this fucked idea came from but it's something that's
> wasting a lot of review time with complaints like this about it.

My bad, I blindly copied that pattern from another broken example under 
arch/arm instead of examining the docs carefully enough.

> > -static struct soc_camera_link ams_delta_iclink = {
> > +static struct soc_camera_link ams_delta_iclink __initconst_or_module =
> > {
> 
> Probably buggy.

Indeed. Even if the soc-camera-pdrv driver doesn't support 
unbindind/rebinding, it doesn't seem to make a copy of that platform data, 
only stores a pointer to it for runtime access, wich I missed.

> > -static struct platform_device *ams_delta_devices[] __initdata = {
> > +static struct platform_device *ams_delta_devices[] __initconst = {
> 
> Missing const.  If you can't const it, don't put it in __initconst.

I gave up trying to use both const and __initconst together after my gcc-4.2.4 
(and not only mine, see [1], [2]) refused to accept such constructs a few 
times. Now I see that this false reporting may probably happen in presence of other 
incorrect uses of __initconst without const or __initdata with const.

Hopefully better patches will follow.

Thanks,
Janusz

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/062421.html 
[2] http://permalink.gmane.org/gmane.linux.kernel.commits.head/202285

Re: [PATCH] ARM: OMAP1: ams-delta: correct init data section assignments

[Janusz Krzysztofik]

On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:

> There is no optimisation to adding __refdata to stuff.  That's screaming
> that you have lots of bugs here.

Thanks for your teaching. I find those aspects not very exhaustively documented 
under Documentation/, so any hints are much appreciated.

> > -static struct map_desc ams_delta_io_desc[] __initdata = {
> > +static struct map_desc ams_delta_io_desc[] __initconst = {
> 
> You're not making this comst so don't change it to __initconst.

OK, however, I think there must be a bug in gcc, otherwise it should probably 
never accept such wrong constructs, while sometimes it does (not only mine, 
see [1]).

> > -static struct omap_lcd_config ams_delta_lcd_config = {
> > +static struct omap_lcd_config ams_delta_lcd_config __initconst = {
> 
> This change probably adds a bug.  Are you sure this will never be used
> outside init context?

I may be wrong, but before I've changed this, and now once again, I've verified 
that a copy of this data is made inside __init omap_init_fb() by means of a 
structure assignment operation.

> > -static struct omap_usb_config ams_delta_usb_config __initdata = {
> > +static struct omap_usb_config ams_delta_usb_config __initdata_or_module
> > = {
> Even if you don't have modules enabled, have you checked whether the
> driver can be bound and unbound via
> /sys/bus/platform/driver/<name>/{bind,unbind} ?

No, I didn't even think of it, I am afraid.

> I suspect this is a bug.

Indeed, that data is not copied on init, only pointed to, moreover, the 
ohci-omap driver provides bind/unbind opearations.

BTW, what are those bind/unbind operations intended for in case of a driver 
dedicated to a non-hotplugable SoC hardware exclusively?

> > -static struct resource ams_delta_nand_resources[] = {
> > +static struct resource ams_delta_nand_resources[] __initconst_or_module
> > = {
> This change definitely adds a bug.  The resources are _used_ _all_ _the_
> _time_ _the_ _device_ _is_ _registered_.  Try catting /proc/iomem after
> boot.

Indeed, I didn't think of that. I expected that standard init data of only 
those devices which can be actually found during init should be copied for 
runtime access, then all (found and not found) dropped instead of keeping them 
all in memory for only some of them being actually used.

> > -static struct i2c_board_info ams_delta_camera_board_info[] = {
> > +static struct i2c_board_info __initconst_or_module
> > +ams_delta_camera_board_info[] = {
> 
> No.  It's
> 
> static struct foo blah[] __whatever_init_attribute
> 
> not
> 
> static struct foo __whatever_init_attribute blah[]
> 
> I've no idea where this fucked idea came from but it's something that's
> wasting a lot of review time with complaints like this about it.

My bad, I blindly copied that pattern from another broken example under 
arch/arm instead of examining the docs carefully enough.

> > -static struct soc_camera_link ams_delta_iclink = {
> > +static struct soc_camera_link ams_delta_iclink __initconst_or_module =
> > {
> 
> Probably buggy.

Indeed. Even if the soc-camera-pdrv driver doesn't support 
unbindind/rebinding, it doesn't seem to make a copy of that platform data, 
only stores a pointer to it for runtime access, wich I missed.

> > -static struct platform_device *ams_delta_devices[] __initdata = {
> > +static struct platform_device *ams_delta_devices[] __initconst = {
> 
> Missing const.  If you can't const it, don't put it in __initconst.

I gave up trying to use both const and __initconst together after my gcc-4.2.4 
(and not only mine, see [1], [2]) refused to accept such constructs a few 
times. Now I see that this false reporting may probably happen in presence of other 
incorrect uses of __initconst without const or __initdata with const.

Hopefully better patches will follow.

Thanks,
Janusz

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/062421.html 
[2] http://permalink.gmane.org/gmane.linux.kernel.commits.head/202285

Re: [PATCH] ARM: OMAP1: ams-delta: correct init data section assignments

[Janusz Krzysztofik]

On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:

> There is no optimisation to adding __refdata to stuff.  That's screaming
> that you have lots of bugs here.

Thanks for your teaching. I find those aspects not very exhaustively documented 
under Documentation/, so any hints are much appreciated.

> > -static struct map_desc ams_delta_io_desc[] __initdata = {
> > +static struct map_desc ams_delta_io_desc[] __initconst = {
> 
> You're not making this comst so don't change it to __initconst.

OK, however, I think there must be a bug in gcc, otherwise it should probably 
never accept such wrong constructs, while sometimes it does (not only mine, 
see [1]).

> > -static struct omap_lcd_config ams_delta_lcd_config = {
> > +static struct omap_lcd_config ams_delta_lcd_config __initconst = {
> 
> This change probably adds a bug.  Are you sure this will never be used
> outside init context?

I may be wrong, but before I've changed this, and now once again, I've verified 
that a copy of this data is made inside __init omap_init_fb() by means of a 
structure assignment operation.

> > -static struct omap_usb_config ams_delta_usb_config __initdata = {
> > +static struct omap_usb_config ams_delta_usb_config __initdata_or_module
> > = {
> Even if you don't have modules enabled, have you checked whether the
> driver can be bound and unbound via
> /sys/bus/platform/driver/<name>/{bind,unbind} ?

No, I didn't even think of it, I am afraid.

> I suspect this is a bug.

Indeed, that data is not copied on init, only pointed to, moreover, the 
ohci-omap driver provides bind/unbind opearations.

BTW, what are those bind/unbind operations intended for in case of a driver 
dedicated to a non-hotplugable SoC hardware exclusively?

> > -static struct resource ams_delta_nand_resources[] = {
> > +static struct resource ams_delta_nand_resources[] __initconst_or_module
> > = {
> This change definitely adds a bug.  The resources are _used_ _all_ _the_
> _time_ _the_ _device_ _is_ _registered_.  Try catting /proc/iomem after
> boot.

Indeed, I didn't think of that. I expected that standard init data of only 
those devices which can be actually found during init should be copied for 
runtime access, then all (found and not found) dropped instead of keeping them 
all in memory for only some of them being actually used.

> > -static struct i2c_board_info ams_delta_camera_board_info[] = {
> > +static struct i2c_board_info __initconst_or_module
> > +ams_delta_camera_board_info[] = {
> 
> No.  It's
> 
> static struct foo blah[] __whatever_init_attribute
> 
> not
> 
> static struct foo __whatever_init_attribute blah[]
> 
> I've no idea where this fucked idea came from but it's something that's
> wasting a lot of review time with complaints like this about it.

My bad, I blindly copied that pattern from another broken example under 
arch/arm instead of examining the docs carefully enough.

> > -static struct soc_camera_link ams_delta_iclink = {
> > +static struct soc_camera_link ams_delta_iclink __initconst_or_module > > {
> 
> Probably buggy.

Indeed. Even if the soc-camera-pdrv driver doesn't support 
unbindind/rebinding, it doesn't seem to make a copy of that platform data, 
only stores a pointer to it for runtime access, wich I missed.

> > -static struct platform_device *ams_delta_devices[] __initdata = {
> > +static struct platform_device *ams_delta_devices[] __initconst = {
> 
> Missing const.  If you can't const it, don't put it in __initconst.

I gave up trying to use both const and __initconst together after my gcc-4.2.4 
(and not only mine, see [1], [2]) refused to accept such constructs a few 
times. Now I see that this false reporting may probably happen in presence of other 
incorrect uses of __initconst without const or __initdata with const.

Hopefully better patches will follow.

Thanks,
Janusz

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/062421.html 
[2] http://permalink.gmane.org/gmane.linux.kernel.commits.head/202285

[PATCH v2] ARM: OMAP1: ams-delta: clean up init data section assignments

[Janusz Krzysztofik]

The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced with recent Amstrad Delta patch series, some of them rising
up only when building with CONFIG_MODULES not set.

While being at it, section tagging of all init data found in the board
file have been revised and hopefully corrected and/or optimized.

Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
 arch/arm/mach-omap1/board-ams-delta.c |   18 +++++++++---------
 drivers/input/serio/ams_delta_serio.c |    2 +-
 drivers/mtd/nand/ams-delta.c          |    2 +-
 drivers/video/omap/lcd_ams_delta.c    |    2 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..bfe6fd1 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -150,7 +150,7 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
 	}
 };
 
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initdata = {
 	.ctrl_name	= "internal",
 };
 
@@ -167,7 +167,7 @@ static struct omap_board_config_kernel ams_delta_config[] __initdata = {
 #define LATCH1_GPIO_BASE	232
 #define LATCH1_NGPIO		8
 
-static struct resource latch1_resources[] __initconst = {
+static struct resource latch1_resources[] = {
 	[0] = {
 		.name	= "dat",
 		.start	= LATCH1_PHYS,
@@ -176,7 +176,7 @@ static struct resource latch1_resources[] __initconst = {
 	},
 };
 
-static struct bgpio_pdata latch1_pdata __initconst = {
+static struct bgpio_pdata latch1_pdata = {
 	.base	= LATCH1_GPIO_BASE,
 	.ngpio	= LATCH1_NGPIO,
 };
@@ -191,7 +191,7 @@ static struct platform_device latch1_gpio_device = {
 	},
 };
 
-static struct resource latch2_resources[] __initconst = {
+static struct resource latch2_resources[] = {
 	[0] = {
 		.name	= "dat",
 		.start	= LATCH2_PHYS,
@@ -200,7 +200,7 @@ static struct resource latch2_resources[] __initconst = {
 	},
 };
 
-static struct bgpio_pdata latch2_pdata __initconst = {
+static struct bgpio_pdata latch2_pdata = {
 	.base	= AMS_DELTA_LATCH2_GPIO_BASE,
 	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
 };
@@ -215,7 +215,7 @@ static struct platform_device latch2_gpio_device = {
 	},
 };
 
-static struct gpio latch_gpios[] __initconst = {
+static const struct gpio latch_gpios[] __initconst = {
 	{
 		.gpio	= LATCH1_GPIO_BASE + 6,
 		.flags	= GPIOF_OUT_INIT_LOW,
@@ -322,7 +322,7 @@ static struct platform_device ams_delta_lcd_device = {
 	.id	= -1,
 };
 
-static struct gpio_led gpio_leds[] __initconst = {
+static const struct gpio_led gpio_leds[] __initconst = {
 	{
 		.name		 = "camera",
 		.gpio		 = LATCH1_GPIO_BASE + 0,
@@ -358,7 +358,7 @@ static struct gpio_led gpio_leds[] __initconst = {
 	},
 };
 
-static struct gpio_led_platform_data leds_pdata __initconst = {
+static const struct gpio_led_platform_data leds_pdata __initconst = {
 	.leds		= gpio_leds,
 	.num_leds	= ARRAY_SIZE(gpio_leds),
 };
@@ -415,7 +415,7 @@ static struct platform_device *ams_delta_devices[] __initdata = {
 	&ams_delta_camera_device,
 };
 
-static struct platform_device *late_devices[] __initconst = {
+static struct platform_device *late_devices[] __initdata = {
 	&ams_delta_nand_device,
 	&ams_delta_lcd_device,
 };
diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
index 0571e2e..bd5b10e 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -103,7 +103,7 @@ static void ams_delta_serio_close(struct serio *serio)
 	gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
 }
 
-static struct gpio ams_delta_gpios[] __initconst_or_module = {
+static const struct gpio ams_delta_gpios[] __initconst_or_module = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
 		.flags	= GPIOF_DIR_IN,
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 85934dc..7341695 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -145,7 +145,7 @@ static int ams_delta_nand_ready(struct mtd_info *mtd)
 	return gpio_get_value(AMS_DELTA_GPIO_PIN_NAND_RB);
 }
 
-static struct gpio _mandatory_gpio[] __initconst_or_module = {
+static const struct gpio _mandatory_gpio[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_NAND_NCE,
 		.flags	= GPIOF_OUT_INIT_HIGH,
diff --git a/drivers/video/omap/lcd_ams_delta.c b/drivers/video/omap/lcd_ams_delta.c
index 0e71e28..d3a3113 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -99,7 +99,7 @@ static struct lcd_ops ams_delta_lcd_ops = {
 
 /* omapfb panel section */
 
-static struct gpio _gpios[] __initconst_or_module = {
+static const struct gpio _gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_LCD_VBLEN,
 		.flags	= GPIOF_OUT_INIT_LOW,
-- 
1.7.3.4

[PATCH v2] ARM: OMAP1: ams-delta: clean up init data section assignments

[Janusz Krzysztofik]

The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced with recent Amstrad Delta patch series, some of them rising
up only when building with CONFIG_MODULES not set.

While being at it, section tagging of all init data found in the board
file have been revised and hopefully corrected and/or optimized.

Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
 arch/arm/mach-omap1/board-ams-delta.c |   18 +++++++++---------
 drivers/input/serio/ams_delta_serio.c |    2 +-
 drivers/mtd/nand/ams-delta.c          |    2 +-
 drivers/video/omap/lcd_ams_delta.c    |    2 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..bfe6fd1 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -150,7 +150,7 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
 	}
 };
 
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initdata = {
 	.ctrl_name	= "internal",
 };
 
@@ -167,7 +167,7 @@ static struct omap_board_config_kernel ams_delta_config[] __initdata = {
 #define LATCH1_GPIO_BASE	232
 #define LATCH1_NGPIO		8
 
-static struct resource latch1_resources[] __initconst = {
+static struct resource latch1_resources[] = {
 	[0] = {
 		.name	= "dat",
 		.start	= LATCH1_PHYS,
@@ -176,7 +176,7 @@ static struct resource latch1_resources[] __initconst = {
 	},
 };
 
-static struct bgpio_pdata latch1_pdata __initconst = {
+static struct bgpio_pdata latch1_pdata = {
 	.base	= LATCH1_GPIO_BASE,
 	.ngpio	= LATCH1_NGPIO,
 };
@@ -191,7 +191,7 @@ static struct platform_device latch1_gpio_device = {
 	},
 };
 
-static struct resource latch2_resources[] __initconst = {
+static struct resource latch2_resources[] = {
 	[0] = {
 		.name	= "dat",
 		.start	= LATCH2_PHYS,
@@ -200,7 +200,7 @@ static struct resource latch2_resources[] __initconst = {
 	},
 };
 
-static struct bgpio_pdata latch2_pdata __initconst = {
+static struct bgpio_pdata latch2_pdata = {
 	.base	= AMS_DELTA_LATCH2_GPIO_BASE,
 	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
 };
@@ -215,7 +215,7 @@ static struct platform_device latch2_gpio_device = {
 	},
 };
 
-static struct gpio latch_gpios[] __initconst = {
+static const struct gpio latch_gpios[] __initconst = {
 	{
 		.gpio	= LATCH1_GPIO_BASE + 6,
 		.flags	= GPIOF_OUT_INIT_LOW,
@@ -322,7 +322,7 @@ static struct platform_device ams_delta_lcd_device = {
 	.id	= -1,
 };
 
-static struct gpio_led gpio_leds[] __initconst = {
+static const struct gpio_led gpio_leds[] __initconst = {
 	{
 		.name		 = "camera",
 		.gpio		 = LATCH1_GPIO_BASE + 0,
@@ -358,7 +358,7 @@ static struct gpio_led gpio_leds[] __initconst = {
 	},
 };
 
-static struct gpio_led_platform_data leds_pdata __initconst = {
+static const struct gpio_led_platform_data leds_pdata __initconst = {
 	.leds		= gpio_leds,
 	.num_leds	= ARRAY_SIZE(gpio_leds),
 };
@@ -415,7 +415,7 @@ static struct platform_device *ams_delta_devices[] __initdata = {
 	&ams_delta_camera_device,
 };
 
-static struct platform_device *late_devices[] __initconst = {
+static struct platform_device *late_devices[] __initdata = {
 	&ams_delta_nand_device,
 	&ams_delta_lcd_device,
 };
diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
index 0571e2e..bd5b10e 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -103,7 +103,7 @@ static void ams_delta_serio_close(struct serio *serio)
 	gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
 }
 
-static struct gpio ams_delta_gpios[] __initconst_or_module = {
+static const struct gpio ams_delta_gpios[] __initconst_or_module = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
 		.flags	= GPIOF_DIR_IN,
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 85934dc..7341695 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -145,7 +145,7 @@ static int ams_delta_nand_ready(struct mtd_info *mtd)
 	return gpio_get_value(AMS_DELTA_GPIO_PIN_NAND_RB);
 }
 
-static struct gpio _mandatory_gpio[] __initconst_or_module = {
+static const struct gpio _mandatory_gpio[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_NAND_NCE,
 		.flags	= GPIOF_OUT_INIT_HIGH,
diff --git a/drivers/video/omap/lcd_ams_delta.c b/drivers/video/omap/lcd_ams_delta.c
index 0e71e28..d3a3113 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -99,7 +99,7 @@ static struct lcd_ops ams_delta_lcd_ops = {
 
 /* omapfb panel section */
 
-static struct gpio _gpios[] __initconst_or_module = {
+static const struct gpio _gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_LCD_VBLEN,
 		.flags	= GPIOF_OUT_INIT_LOW,
-- 
1.7.3.4

[PATCH v2] ARM: OMAP1: ams-delta: clean up init data section assignments

[Janusz Krzysztofik]

The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced with recent Amstrad Delta patch series, some of them rising
up only when building with CONFIG_MODULES not set.

While being at it, section tagging of all init data found in the board
file have been revised and hopefully corrected and/or optimized.

Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
 arch/arm/mach-omap1/board-ams-delta.c |   18 +++++++++---------
 drivers/input/serio/ams_delta_serio.c |    2 +-
 drivers/mtd/nand/ams-delta.c          |    2 +-
 drivers/video/omap/lcd_ams_delta.c    |    2 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..bfe6fd1 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -150,7 +150,7 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
 	}
 };
 
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initdata = {
 	.ctrl_name	= "internal",
 };
 
@@ -167,7 +167,7 @@ static struct omap_board_config_kernel ams_delta_config[] __initdata = {
 #define LATCH1_GPIO_BASE	232
 #define LATCH1_NGPIO		8
 
-static struct resource latch1_resources[] __initconst = {
+static struct resource latch1_resources[] = {
 	[0] = {
 		.name	= "dat",
 		.start	= LATCH1_PHYS,
@@ -176,7 +176,7 @@ static struct resource latch1_resources[] __initconst = {
 	},
 };
 
-static struct bgpio_pdata latch1_pdata __initconst = {
+static struct bgpio_pdata latch1_pdata = {
 	.base	= LATCH1_GPIO_BASE,
 	.ngpio	= LATCH1_NGPIO,
 };
@@ -191,7 +191,7 @@ static struct platform_device latch1_gpio_device = {
 	},
 };
 
-static struct resource latch2_resources[] __initconst = {
+static struct resource latch2_resources[] = {
 	[0] = {
 		.name	= "dat",
 		.start	= LATCH2_PHYS,
@@ -200,7 +200,7 @@ static struct resource latch2_resources[] __initconst = {
 	},
 };
 
-static struct bgpio_pdata latch2_pdata __initconst = {
+static struct bgpio_pdata latch2_pdata = {
 	.base	= AMS_DELTA_LATCH2_GPIO_BASE,
 	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
 };
@@ -215,7 +215,7 @@ static struct platform_device latch2_gpio_device = {
 	},
 };
 
-static struct gpio latch_gpios[] __initconst = {
+static const struct gpio latch_gpios[] __initconst = {
 	{
 		.gpio	= LATCH1_GPIO_BASE + 6,
 		.flags	= GPIOF_OUT_INIT_LOW,
@@ -322,7 +322,7 @@ static struct platform_device ams_delta_lcd_device = {
 	.id	= -1,
 };
 
-static struct gpio_led gpio_leds[] __initconst = {
+static const struct gpio_led gpio_leds[] __initconst = {
 	{
 		.name		 = "camera",
 		.gpio		 = LATCH1_GPIO_BASE + 0,
@@ -358,7 +358,7 @@ static struct gpio_led gpio_leds[] __initconst = {
 	},
 };
 
-static struct gpio_led_platform_data leds_pdata __initconst = {
+static const struct gpio_led_platform_data leds_pdata __initconst = {
 	.leds		= gpio_leds,
 	.num_leds	= ARRAY_SIZE(gpio_leds),
 };
@@ -415,7 +415,7 @@ static struct platform_device *ams_delta_devices[] __initdata = {
 	&ams_delta_camera_device,
 };
 
-static struct platform_device *late_devices[] __initconst = {
+static struct platform_device *late_devices[] __initdata = {
 	&ams_delta_nand_device,
 	&ams_delta_lcd_device,
 };
diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
index 0571e2e..bd5b10e 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -103,7 +103,7 @@ static void ams_delta_serio_close(struct serio *serio)
 	gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
 }
 
-static struct gpio ams_delta_gpios[] __initconst_or_module = {
+static const struct gpio ams_delta_gpios[] __initconst_or_module = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
 		.flags	= GPIOF_DIR_IN,
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 85934dc..7341695 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -145,7 +145,7 @@ static int ams_delta_nand_ready(struct mtd_info *mtd)
 	return gpio_get_value(AMS_DELTA_GPIO_PIN_NAND_RB);
 }
 
-static struct gpio _mandatory_gpio[] __initconst_or_module = {
+static const struct gpio _mandatory_gpio[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_NAND_NCE,
 		.flags	= GPIOF_OUT_INIT_HIGH,
diff --git a/drivers/video/omap/lcd_ams_delta.c b/drivers/video/omap/lcd_ams_delta.c
index 0e71e28..d3a3113 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -99,7 +99,7 @@ static struct lcd_ops ams_delta_lcd_ops = {
 
 /* omapfb panel section */
 
-static struct gpio _gpios[] __initconst_or_module = {
+static const struct gpio _gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_LCD_VBLEN,
 		.flags	= GPIOF_OUT_INIT_LOW,
-- 
1.7.3.4

[PATCH v2] ARM: OMAP1: ams-delta: clean up init data section assignments

[Janusz Krzysztofik]

The main purpose of this patch is to fix several section mismatch
warnings from the board file and a few board specific drivers,
introduced with recent Amstrad Delta patch series, some of them rising
up only when building with CONFIG_MODULES not set.

While being at it, section tagging of all init data found in the board
file have been revised and hopefully corrected and/or optimized.

Created and tested on top of current linux-omap/omap1, commit
967809bd7faf71ddc29c8081e0f21db8b201a0f4.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
 arch/arm/mach-omap1/board-ams-delta.c |   18 +++++++++---------
 drivers/input/serio/ams_delta_serio.c |    2 +-
 drivers/mtd/nand/ams-delta.c          |    2 +-
 drivers/video/omap/lcd_ams_delta.c    |    2 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 87b1303..bfe6fd1 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -150,7 +150,7 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
 	}
 };
 
-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initdata = {
 	.ctrl_name	= "internal",
 };
 
@@ -167,7 +167,7 @@ static struct omap_board_config_kernel ams_delta_config[] __initdata = {
 #define LATCH1_GPIO_BASE	232
 #define LATCH1_NGPIO		8
 
-static struct resource latch1_resources[] __initconst = {
+static struct resource latch1_resources[] = {
 	[0] = {
 		.name	= "dat",
 		.start	= LATCH1_PHYS,
@@ -176,7 +176,7 @@ static struct resource latch1_resources[] __initconst = {
 	},
 };
 
-static struct bgpio_pdata latch1_pdata __initconst = {
+static struct bgpio_pdata latch1_pdata = {
 	.base	= LATCH1_GPIO_BASE,
 	.ngpio	= LATCH1_NGPIO,
 };
@@ -191,7 +191,7 @@ static struct platform_device latch1_gpio_device = {
 	},
 };
 
-static struct resource latch2_resources[] __initconst = {
+static struct resource latch2_resources[] = {
 	[0] = {
 		.name	= "dat",
 		.start	= LATCH2_PHYS,
@@ -200,7 +200,7 @@ static struct resource latch2_resources[] __initconst = {
 	},
 };
 
-static struct bgpio_pdata latch2_pdata __initconst = {
+static struct bgpio_pdata latch2_pdata = {
 	.base	= AMS_DELTA_LATCH2_GPIO_BASE,
 	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
 };
@@ -215,7 +215,7 @@ static struct platform_device latch2_gpio_device = {
 	},
 };
 
-static struct gpio latch_gpios[] __initconst = {
+static const struct gpio latch_gpios[] __initconst = {
 	{
 		.gpio	= LATCH1_GPIO_BASE + 6,
 		.flags	= GPIOF_OUT_INIT_LOW,
@@ -322,7 +322,7 @@ static struct platform_device ams_delta_lcd_device = {
 	.id	= -1,
 };
 
-static struct gpio_led gpio_leds[] __initconst = {
+static const struct gpio_led gpio_leds[] __initconst = {
 	{
 		.name		 = "camera",
 		.gpio		 = LATCH1_GPIO_BASE + 0,
@@ -358,7 +358,7 @@ static struct gpio_led gpio_leds[] __initconst = {
 	},
 };
 
-static struct gpio_led_platform_data leds_pdata __initconst = {
+static const struct gpio_led_platform_data leds_pdata __initconst = {
 	.leds		= gpio_leds,
 	.num_leds	= ARRAY_SIZE(gpio_leds),
 };
@@ -415,7 +415,7 @@ static struct platform_device *ams_delta_devices[] __initdata = {
 	&ams_delta_camera_device,
 };
 
-static struct platform_device *late_devices[] __initconst = {
+static struct platform_device *late_devices[] __initdata = {
 	&ams_delta_nand_device,
 	&ams_delta_lcd_device,
 };
diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
index 0571e2e..bd5b10e 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -103,7 +103,7 @@ static void ams_delta_serio_close(struct serio *serio)
 	gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
 }
 
-static struct gpio ams_delta_gpios[] __initconst_or_module = {
+static const struct gpio ams_delta_gpios[] __initconst_or_module = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
 		.flags	= GPIOF_DIR_IN,
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 85934dc..7341695 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -145,7 +145,7 @@ static int ams_delta_nand_ready(struct mtd_info *mtd)
 	return gpio_get_value(AMS_DELTA_GPIO_PIN_NAND_RB);
 }
 
-static struct gpio _mandatory_gpio[] __initconst_or_module = {
+static const struct gpio _mandatory_gpio[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_NAND_NCE,
 		.flags	= GPIOF_OUT_INIT_HIGH,
diff --git a/drivers/video/omap/lcd_ams_delta.c b/drivers/video/omap/lcd_ams_delta.c
index 0e71e28..d3a3113 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -99,7 +99,7 @@ static struct lcd_ops ams_delta_lcd_ops = {
 
 /* omapfb panel section */
 
-static struct gpio _gpios[] __initconst_or_module = {
+static const struct gpio _gpios[] = {
 	{
 		.gpio	= AMS_DELTA_GPIO_PIN_LCD_VBLEN,
 		.flags	= GPIOF_OUT_INIT_LOW,
-- 
1.7.3.4

Re: [PATCH] ARM: OMAP1: ams-delta: correct init data section assignments

[Russell King - ARM Linux]

On Fri, Feb 10, 2012 at 05:31:31PM +0100, Janusz Krzysztofik wrote:
> On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:
> > > -static struct map_desc ams_delta_io_desc[] __initdata = {
> > > +static struct map_desc ams_delta_io_desc[] __initconst = {
> > 
> > You're not making this comst so don't change it to __initconst.
> 
> OK, however, I think there must be a bug in gcc, otherwise it should probably 
> never accept such wrong constructs, while sometimes it does (not only mine, 
> see [1]).

No - because you don't understand what's going on with these tags.
The __initconst and other tags are just tell the compiler to place
stuff into a named section.  The name is interpreted by GCC as a mere
string which it passes through to the ELF file.

So, gcc has no idea that a section named '.init.rodata' could be placed
in read-only memory, and therefore has no idea that it should also be
marked 'const'.

Therefore, gcc has no way to verify that 'const' and '__initconst' are
always paired.

> > > -static struct omap_lcd_config ams_delta_lcd_config = {
> > > +static struct omap_lcd_config ams_delta_lcd_config __initconst = {
> > 
> > This change probably adds a bug.  Are you sure this will never be used
> > outside init context?
> 
> I may be wrong, but before I've changed this, and now once again, I've verified 
> that a copy of this data is made inside __init omap_init_fb() by means of a 
> structure assignment operation.

Ok, in that case add a 'const' to it.

> > > -static struct omap_usb_config ams_delta_usb_config __initdata = {
> > > +static struct omap_usb_config ams_delta_usb_config __initdata_or_module
> > > = {
> > Even if you don't have modules enabled, have you checked whether the
> > driver can be bound and unbound via
> > /sys/bus/platform/driver/<name>/{bind,unbind} ?
> 
> No, I didn't even think of it, I am afraid.
> 
> > I suspect this is a bug.
> 
> Indeed, that data is not copied on init, only pointed to, moreover, the 
> ohci-omap driver provides bind/unbind opearations.
> 
> BTW, what are those bind/unbind operations intended for in case of a
> driver dedicated to a non-hotplugable SoC hardware exclusively?

If the driver can be built as a module, they allow exercising the
probe/remove paths for drivers which have been built-in.  Moreover,
it allows you to disable a device driver if desired.

For example, I have two platforms which are essentially the same, except
one has a daughterboard attached (which isn't hotpluggable).  The support
for the daughterboard, although it is a platform driver, can't be
modularised at the moment because quite a bit of other stuff needs it
and it contains IRQ chip code.

One has far less idle wakeups than the other.  Using unbind, I can
effectively detach this board by unbinding its platform device, which
results the entire sub-tree of its on-board devices being unregistered
and released in one big go, all the way down to things like USB devices
on the USB host.  I can then rebind it and bring all that hardware back.

That allows me to evaluate whether there's any impact from those drivers.

However, this bind/unbind is not the only issue here: how do you know
whether the driver takes a copy of the platform data, or merely stores a
pointer to it - and may access your platform data at runtime.

Unless you check, and recheck it regularly (it can change) then placing
this stuff into sections which will be discarded is asking for bugs.

> > > -static struct platform_device *ams_delta_devices[] __initdata = {
> > > +static struct platform_device *ams_delta_devices[] __initconst = {
> > 
> > Missing const.  If you can't const it, don't put it in __initconst.
> 
> I gave up trying to use both const and __initconst together after my gcc-4.2.4 
> (and not only mine, see [1], [2]) refused to accept such constructs a few 
> times. Now I see that this false reporting may probably happen in presence of other 
> incorrect uses of __initconst without const or __initdata with const.

I doubt that the compiler was refusing to accept them.  What you were
probably getting were warnings about where these were used not accepting
a const pointer.

If that's the case, more analysis needs to be done to find out whether
those uses can be converted to accept a const pointer before defining
the data with const and optionally __initconst.

[PATCH] ARM: OMAP1: ams-delta: correct init data section assignments

[Russell King - ARM Linux]

On Fri, Feb 10, 2012 at 05:31:31PM +0100, Janusz Krzysztofik wrote:
> On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:
> > > -static struct map_desc ams_delta_io_desc[] __initdata = {
> > > +static struct map_desc ams_delta_io_desc[] __initconst = {
> > 
> > You're not making this comst so don't change it to __initconst.
> 
> OK, however, I think there must be a bug in gcc, otherwise it should probably 
> never accept such wrong constructs, while sometimes it does (not only mine, 
> see [1]).

No - because you don't understand what's going on with these tags.
The __initconst and other tags are just tell the compiler to place
stuff into a named section.  The name is interpreted by GCC as a mere
string which it passes through to the ELF file.

So, gcc has no idea that a section named '.init.rodata' could be placed
in read-only memory, and therefore has no idea that it should also be
marked 'const'.

Therefore, gcc has no way to verify that 'const' and '__initconst' are
always paired.

> > > -static struct omap_lcd_config ams_delta_lcd_config = {
> > > +static struct omap_lcd_config ams_delta_lcd_config __initconst = {
> > 
> > This change probably adds a bug.  Are you sure this will never be used
> > outside init context?
> 
> I may be wrong, but before I've changed this, and now once again, I've verified 
> that a copy of this data is made inside __init omap_init_fb() by means of a 
> structure assignment operation.

Ok, in that case add a 'const' to it.

> > > -static struct omap_usb_config ams_delta_usb_config __initdata = {
> > > +static struct omap_usb_config ams_delta_usb_config __initdata_or_module
> > > = {
> > Even if you don't have modules enabled, have you checked whether the
> > driver can be bound and unbound via
> > /sys/bus/platform/driver/<name>/{bind,unbind} ?
> 
> No, I didn't even think of it, I am afraid.
> 
> > I suspect this is a bug.
> 
> Indeed, that data is not copied on init, only pointed to, moreover, the 
> ohci-omap driver provides bind/unbind opearations.
> 
> BTW, what are those bind/unbind operations intended for in case of a
> driver dedicated to a non-hotplugable SoC hardware exclusively?

If the driver can be built as a module, they allow exercising the
probe/remove paths for drivers which have been built-in.  Moreover,
it allows you to disable a device driver if desired.

For example, I have two platforms which are essentially the same, except
one has a daughterboard attached (which isn't hotpluggable).  The support
for the daughterboard, although it is a platform driver, can't be
modularised at the moment because quite a bit of other stuff needs it
and it contains IRQ chip code.

One has far less idle wakeups than the other.  Using unbind, I can
effectively detach this board by unbinding its platform device, which
results the entire sub-tree of its on-board devices being unregistered
and released in one big go, all the way down to things like USB devices
on the USB host.  I can then rebind it and bring all that hardware back.

That allows me to evaluate whether there's any impact from those drivers.

However, this bind/unbind is not the only issue here: how do you know
whether the driver takes a copy of the platform data, or merely stores a
pointer to it - and may access your platform data at runtime.

Unless you check, and recheck it regularly (it can change) then placing
this stuff into sections which will be discarded is asking for bugs.

> > > -static struct platform_device *ams_delta_devices[] __initdata = {
> > > +static struct platform_device *ams_delta_devices[] __initconst = {
> > 
> > Missing const.  If you can't const it, don't put it in __initconst.
> 
> I gave up trying to use both const and __initconst together after my gcc-4.2.4 
> (and not only mine, see [1], [2]) refused to accept such constructs a few 
> times. Now I see that this false reporting may probably happen in presence of other 
> incorrect uses of __initconst without const or __initdata with const.

I doubt that the compiler was refusing to accept them.  What you were
probably getting were warnings about where these were used not accepting
a const pointer.

If that's the case, more analysis needs to be done to find out whether
those uses can be converted to accept a const pointer before defining
the data with const and optionally __initconst.

Re: [PATCH] ARM: OMAP1: ams-delta: correct init data section assignments

[Russell King - ARM Linux]

On Fri, Feb 10, 2012 at 05:31:31PM +0100, Janusz Krzysztofik wrote:
> On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:
> > > -static struct map_desc ams_delta_io_desc[] __initdata = {
> > > +static struct map_desc ams_delta_io_desc[] __initconst = {
> > 
> > You're not making this comst so don't change it to __initconst.
> 
> OK, however, I think there must be a bug in gcc, otherwise it should probably 
> never accept such wrong constructs, while sometimes it does (not only mine, 
> see [1]).

No - because you don't understand what's going on with these tags.
The __initconst and other tags are just tell the compiler to place
stuff into a named section.  The name is interpreted by GCC as a mere
string which it passes through to the ELF file.

So, gcc has no idea that a section named '.init.rodata' could be placed
in read-only memory, and therefore has no idea that it should also be
marked 'const'.

Therefore, gcc has no way to verify that 'const' and '__initconst' are
always paired.

> > > -static struct omap_lcd_config ams_delta_lcd_config = {
> > > +static struct omap_lcd_config ams_delta_lcd_config __initconst = {
> > 
> > This change probably adds a bug.  Are you sure this will never be used
> > outside init context?
> 
> I may be wrong, but before I've changed this, and now once again, I've verified 
> that a copy of this data is made inside __init omap_init_fb() by means of a 
> structure assignment operation.

Ok, in that case add a 'const' to it.

> > > -static struct omap_usb_config ams_delta_usb_config __initdata = {
> > > +static struct omap_usb_config ams_delta_usb_config __initdata_or_module
> > > = {
> > Even if you don't have modules enabled, have you checked whether the
> > driver can be bound and unbound via
> > /sys/bus/platform/driver/<name>/{bind,unbind} ?
> 
> No, I didn't even think of it, I am afraid.
> 
> > I suspect this is a bug.
> 
> Indeed, that data is not copied on init, only pointed to, moreover, the 
> ohci-omap driver provides bind/unbind opearations.
> 
> BTW, what are those bind/unbind operations intended for in case of a
> driver dedicated to a non-hotplugable SoC hardware exclusively?

If the driver can be built as a module, they allow exercising the
probe/remove paths for drivers which have been built-in.  Moreover,
it allows you to disable a device driver if desired.

For example, I have two platforms which are essentially the same, except
one has a daughterboard attached (which isn't hotpluggable).  The support
for the daughterboard, although it is a platform driver, can't be
modularised at the moment because quite a bit of other stuff needs it
and it contains IRQ chip code.

One has far less idle wakeups than the other.  Using unbind, I can
effectively detach this board by unbinding its platform device, which
results the entire sub-tree of its on-board devices being unregistered
and released in one big go, all the way down to things like USB devices
on the USB host.  I can then rebind it and bring all that hardware back.

That allows me to evaluate whether there's any impact from those drivers.

However, this bind/unbind is not the only issue here: how do you know
whether the driver takes a copy of the platform data, or merely stores a
pointer to it - and may access your platform data at runtime.

Unless you check, and recheck it regularly (it can change) then placing
this stuff into sections which will be discarded is asking for bugs.

> > > -static struct platform_device *ams_delta_devices[] __initdata = {
> > > +static struct platform_device *ams_delta_devices[] __initconst = {
> > 
> > Missing const.  If you can't const it, don't put it in __initconst.
> 
> I gave up trying to use both const and __initconst together after my gcc-4.2.4 
> (and not only mine, see [1], [2]) refused to accept such constructs a few 
> times. Now I see that this false reporting may probably happen in presence of other 
> incorrect uses of __initconst without const or __initdata with const.

I doubt that the compiler was refusing to accept them.  What you were
probably getting were warnings about where these were used not accepting
a const pointer.

If that's the case, more analysis needs to be done to find out whether
those uses can be converted to accept a const pointer before defining
the data with const and optionally __initconst.

Re: [PATCH] ARM: OMAP1: ams-delta: correct init data section assignments

[Russell King - ARM Linux]

On Fri, Feb 10, 2012 at 05:31:31PM +0100, Janusz Krzysztofik wrote:
> On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:
> > > -static struct map_desc ams_delta_io_desc[] __initdata = {
> > > +static struct map_desc ams_delta_io_desc[] __initconst = {
> > 
> > You're not making this comst so don't change it to __initconst.
> 
> OK, however, I think there must be a bug in gcc, otherwise it should probably 
> never accept such wrong constructs, while sometimes it does (not only mine, 
> see [1]).

No - because you don't understand what's going on with these tags.
The __initconst and other tags are just tell the compiler to place
stuff into a named section.  The name is interpreted by GCC as a mere
string which it passes through to the ELF file.

So, gcc has no idea that a section named '.init.rodata' could be placed
in read-only memory, and therefore has no idea that it should also be
marked 'const'.

Therefore, gcc has no way to verify that 'const' and '__initconst' are
always paired.

> > > -static struct omap_lcd_config ams_delta_lcd_config = {
> > > +static struct omap_lcd_config ams_delta_lcd_config __initconst = {
> > 
> > This change probably adds a bug.  Are you sure this will never be used
> > outside init context?
> 
> I may be wrong, but before I've changed this, and now once again, I've verified 
> that a copy of this data is made inside __init omap_init_fb() by means of a 
> structure assignment operation.

Ok, in that case add a 'const' to it.

> > > -static struct omap_usb_config ams_delta_usb_config __initdata = {
> > > +static struct omap_usb_config ams_delta_usb_config __initdata_or_module
> > > = {
> > Even if you don't have modules enabled, have you checked whether the
> > driver can be bound and unbound via
> > /sys/bus/platform/driver/<name>/{bind,unbind} ?
> 
> No, I didn't even think of it, I am afraid.
> 
> > I suspect this is a bug.
> 
> Indeed, that data is not copied on init, only pointed to, moreover, the 
> ohci-omap driver provides bind/unbind opearations.
> 
> BTW, what are those bind/unbind operations intended for in case of a
> driver dedicated to a non-hotplugable SoC hardware exclusively?

If the driver can be built as a module, they allow exercising the
probe/remove paths for drivers which have been built-in.  Moreover,
it allows you to disable a device driver if desired.

For example, I have two platforms which are essentially the same, except
one has a daughterboard attached (which isn't hotpluggable).  The support
for the daughterboard, although it is a platform driver, can't be
modularised at the moment because quite a bit of other stuff needs it
and it contains IRQ chip code.

One has far less idle wakeups than the other.  Using unbind, I can
effectively detach this board by unbinding its platform device, which
results the entire sub-tree of its on-board devices being unregistered
and released in one big go, all the way down to things like USB devices
on the USB host.  I can then rebind it and bring all that hardware back.

That allows me to evaluate whether there's any impact from those drivers.

However, this bind/unbind is not the only issue here: how do you know
whether the driver takes a copy of the platform data, or merely stores a
pointer to it - and may access your platform data at runtime.

Unless you check, and recheck it regularly (it can change) then placing
this stuff into sections which will be discarded is asking for bugs.

> > > -static struct platform_device *ams_delta_devices[] __initdata = {
> > > +static struct platform_device *ams_delta_devices[] __initconst = {
> > 
> > Missing const.  If you can't const it, don't put it in __initconst.
> 
> I gave up trying to use both const and __initconst together after my gcc-4.2.4 
> (and not only mine, see [1], [2]) refused to accept such constructs a few 
> times. Now I see that this false reporting may probably happen in presence of other 
> incorrect uses of __initconst without const or __initdata with const.

I doubt that the compiler was refusing to accept them.  What you were
probably getting were warnings about where these were used not accepting
a const pointer.

If that's the case, more analysis needs to be done to find out whether
those uses can be converted to accept a const pointer before defining
the data with const and optionally __initconst.

Re: OMAP34xx

[Russell King - ARM Linux]

On Sat, Feb 04, 2012 at 05:25:57PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 12:03]:
> > 
> > Another problem (some build errors for OMAP3) do seem to be solved, but
> > not the section mismatch warnings.  They're easy to verify before code
> > gets pushed anywhere upstream, especially if you're doing one giant OMAP
> > build - just enable CONFIG_DEBUG_SECTION_MISMATCH in your build
> > configuration.  Refuse patches which introduce section mismatches - at
> > least without an explanation backing up why they do.
> >
> > My OMAP3 and OMAP4 configurations spit out these - I've not even tried
> > my OMAP2 configuration yet:
> 
> Weird. The warnings you're seeing all seem valid to me, but I'm not seeing
> any the section warnings with the following compilers I have:
> 
> gcc version 4.3.5 (Debian 4.3.5-4)
> gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)
> gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70)
> 
> I see _different_ warnings if I compile with an older gcc:
> gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)
> 
> Any ideas why that would be?

Different inlining behaviour maybe?  I'm using stock gcc 4.3.5 here.

> The only warnings I see are:
> 
> WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19a4): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
> The function omap_serial_fill_default_pads() references
> the (unknown reference) __initdata (unknown).
> This is often because omap_serial_fill_default_pads lacks a __initdata 
> annotation or the annotation of (unknown) is wrong.
> 
> WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19a8): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
> The function omap_serial_fill_default_pads() references
> the (unknown reference) __initdata (unknown).
> This is often because omap_serial_fill_default_pads lacks a __initdata 
> annotation or the annotation of (unknown) is wrong.
> 
> WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19ac): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
> The function omap_serial_fill_default_pads() references
> the (unknown reference) __initdata (unknown).
> This is often because omap_serial_fill_default_pads lacks a __initdata 
> annotation or the annotation of (unknown) is wrong.
> 
> WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19b0): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
> The function omap_serial_fill_default_pads() references
> the (unknown reference) __initdata (unknown).
> This is often because omap_serial_fill_default_pads lacks a __initdata 
> annotation or the annotation of (unknown) is wrong.
> 
> WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19b4): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
> The function omap_serial_fill_default_pads() references
> the (unknown reference) __initdata (unknown).
> This is often because omap_serial_fill_default_pads lacks a __initdata 
> annotation or the annotation of (unknown) is wrong.
> 
> WARNING: arch/arm/mach-omap2/built-in.o(.text+0x12b70): Section mismatch in reference from the function cm_t35_init_usbh() to the (unknown reference) .init.data:(unknown)
> The function cm_t35_init_usbh() references
> the (unknown reference) __initdata (unknown).
> This is often because cm_t35_init_usbh lacks a __initdata 
> annotation or the annotation of (unknown) is wrong.
> 
> WARNING: vmlinux.o(.text+0x1c424): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
> The function omap_serial_fill_default_pads() references
> the (unknown reference) __initdata (unknown).
> This is often because omap_serial_fill_default_pads lacks a __initdata 
> annotation or the annotation of (unknown) is wrong.
> 
> WARNING: vmlinux.o(.text+0x1c428): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
> The function omap_serial_fill_default_pads() references
> the (unknown reference) __initdata (unknown).
> This is often because omap_serial_fill_default_pads lacks a __initdata 
> annotation or the annotation of (unknown) is wrong.
> 
> WARNING: vmlinux.o(.text+0x1c42c): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
> The function omap_serial_fill_default_pads() references
> the (unknown reference) __initdata (unknown).
> This is often because omap_serial_fill_default_pads lacks a __initdata 
> annotation or the annotation of (unknown) is wrong.
> 
> WARNING: vmlinux.o(.text+0x1c430): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
> The function omap_serial_fill_default_pads() references
> the (unknown reference) __initdata (unknown).
> This is often because omap_serial_fill_default_pads lacks a __initdata 
> annotation or the annotation of (unknown) is wrong.
> 
> WARNING: vmlinux.o(.text+0x1c434): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown)
> The function omap_serial_fill_default_pads() references
> the (unknown reference) __initdata (unknown).
> This is often because omap_serial_fill_default_pads lacks a __initdata 
> annotation or the annotation of (unknown) is wrong.
> 
> WARNING: vmlinux.o(.text+0x2d5f0): Section mismatch in reference from the function cm_t35_init_usbh() to the (unknown reference) .init.data:(unknown)
> The function cm_t35_init_usbh() references
> the (unknown reference) __initdata (unknown).
> This is often because cm_t35_init_usbh lacks a __initdata 
> annotation or the annotation of (unknown) is wrong.

If I look at this warning:

WARNING: vmlinux.o(.text+0x1c434): Section mismatch in reference from the fun$> The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata
annotation or the annotation of (unknown) is wrong.

on OMAP3, where CONFIG_OMAP_MUX=y and CONFIG_CC_OPTIMIZE_FOR_SIZE=y,
then, the reason I don't get that warning is because
omap_serial_fill_default_pads() gets folded into omap_serial_board_init()
for me.  There's not much which can be done to stop that thing happening.

However, the fact that you're not finding stuff like the reference from

static int __devinit
twl_probe(struct i2c_client *client, const struct i2c_device_id *id)

to:

void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)

between two separate files is very worrying, and does indicate that
something is broken - there's no way that the compiler could 'optimize'
this by folding twl4030_power_init() into twl_probe() between the two
files.

In any case, here's my current (tested) patch unbreaking OMAP as a whole,
not only for all these section mismatches but the more fundamental issues
like the broken serial ports on OMAP3 and the irq domain buggeration too.

This leaves one section mismatch for me in the OMAP hotplug code.

 arch/arm/mach-omap2/board-4430sdp.c |    2 +-
 arch/arm/mach-omap2/cpuidle34xx.c   |    2 ++
 arch/arm/mach-omap2/hsmmc.c         |    8 ++++----
 arch/arm/mach-omap2/mux.c           |   22 +++++++++++-----------
 arch/arm/mach-omap2/omap-headsmp.S  |    1 +
 arch/arm/mach-omap2/pm34xx.c        |    2 +-
 arch/arm/mach-omap2/prm44xx.c       |    1 +
 drivers/mfd/Kconfig                 |    2 +-
 drivers/mfd/twl-core.c              |    6 ++++--
 drivers/mfd/twl4030-power.c         |   20 ++++++++++----------
 10 files changed, 36 insertions(+), 30 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 39fba9d..0049587 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -808,7 +808,7 @@ static struct omap_dss_board_info sdp4430_dss_data = {
 	.default_device	= &sdp4430_lcd_device,
 };
 
-static void omap_4430sdp_display_init(void)
+static void __init omap_4430sdp_display_init(void)
 {
 	int r;
 
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 464cffd..1e9256c 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -259,6 +259,8 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
 	struct omap3_idle_statedata *cx;
 	int ret;
 
+	{ new_state_idx = drv->safe_state_index; goto select_state; }
+
 	/*
 	 * Prevent idle completely if CAM is active.
 	 * CAM does not have wakeup capability in OMAP3.
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index ad0adb5..b40c288 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -293,8 +293,8 @@ static inline void omap_hsmmc_mux(struct omap_mmc_platform_data *mmc_controller,
 	}
 }
 
-static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
-					struct omap_mmc_platform_data *mmc)
+static int omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
+				 struct omap_mmc_platform_data *mmc)
 {
 	char *hc_name;
 
@@ -430,7 +430,7 @@ static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
 
 #define MAX_OMAP_MMC_HWMOD_NAME_LEN		16
 
-void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
+void omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
 {
 	struct omap_hwmod *oh;
 	struct platform_device *pdev;
@@ -487,7 +487,7 @@ void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
 	kfree(mmc_data);
 }
 
-void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
+void omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
 {
 	u32 reg;
 
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index e1cc75d..fb8bc9f 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -100,8 +100,8 @@ void omap_mux_write_array(struct omap_mux_partition *partition,
 
 static char *omap_mux_options;
 
-static int __init _omap_mux_init_gpio(struct omap_mux_partition *partition,
-				      int gpio, int val)
+static int _omap_mux_init_gpio(struct omap_mux_partition *partition,
+			       int gpio, int val)
 {
 	struct omap_mux_entry *e;
 	struct omap_mux *gpio_mux = NULL;
@@ -145,7 +145,7 @@ static int __init _omap_mux_init_gpio(struct omap_mux_partition *partition,
 	return 0;
 }
 
-int __init omap_mux_init_gpio(int gpio, int val)
+int omap_mux_init_gpio(int gpio, int val)
 {
 	struct omap_mux_partition *partition;
 	int ret;
@@ -159,9 +159,9 @@ int __init omap_mux_init_gpio(int gpio, int val)
 	return -ENODEV;
 }
 
-static int __init _omap_mux_get_by_name(struct omap_mux_partition *partition,
-					const char *muxname,
-					struct omap_mux **found_mux)
+static int _omap_mux_get_by_name(struct omap_mux_partition *partition,
+				 const char *muxname,
+				 struct omap_mux **found_mux)
 {
 	struct omap_mux *mux = NULL;
 	struct omap_mux_entry *e;
@@ -240,7 +240,7 @@ omap_mux_get_by_name(const char *muxname,
 	return -ENODEV;
 }
 
-int __init omap_mux_init_signal(const char *muxname, int val)
+int omap_mux_init_signal(const char *muxname, int val)
 {
 	struct omap_mux_partition *partition = NULL;
 	struct omap_mux *mux = NULL;
@@ -1094,8 +1094,8 @@ static void omap_mux_init_package(struct omap_mux *superset,
 		omap_mux_package_init_balls(package_balls, superset);
 }
 
-static void omap_mux_init_signals(struct omap_mux_partition *partition,
-				  struct omap_board_mux *board_mux)
+static void __init omap_mux_init_signals(struct omap_mux_partition *partition,
+					 struct omap_board_mux *board_mux)
 {
 	omap_mux_set_cmdline_signals();
 	omap_mux_write_array(partition, board_mux);
@@ -1109,8 +1109,8 @@ static void omap_mux_init_package(struct omap_mux *superset,
 {
 }
 
-static void omap_mux_init_signals(struct omap_mux_partition *partition,
-				  struct omap_board_mux *board_mux)
+static void __init omap_mux_init_signals(struct omap_mux_partition *partition,
+					 struct omap_board_mux *board_mux)
 {
 }
 
diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
index b13ef7e..503ac77 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -18,6 +18,7 @@
 #include <linux/linkage.h>
 #include <linux/init.h>
 
+	__CPUINIT
 /*
  * OMAP4 specific entry point for secondary CPU to jump from ROM
  * code.  This routine also provides a holding flag into which
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b77df73..4b76c4c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
 {
 	local_fiq_disable();
 
-	if (omap_irq_pending())
+	if (omap_irq_pending() || 1)
 		goto out;
 
 	trace_power_start(POWER_CSTATE, 1, smp_processor_id());
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 33dd655..a1d6154 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -19,6 +19,7 @@
 
 #include "common.h"
 #include <plat/cpu.h>
+#include <plat/irqs.h>
 #include <plat/prcm.h>
 
 #include "vp.h"
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 28a301b..bd60ce0 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -200,7 +200,7 @@ config MENELAUS
 
 config TWL4030_CORE
 	bool "Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support"
-	depends on I2C=y && GENERIC_HARDIRQS && IRQ_DOMAIN
+	depends on I2C=y && GENERIC_HARDIRQS
 	help
 	  Say yes here if you have TWL4030 / TWL6030 family chip on your board.
 	  This core driver provides register access and IRQ handling
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index e04e04d..8ce3959 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -263,7 +263,9 @@ struct twl_client {
 
 static struct twl_client twl_modules[TWL_NUM_SLAVES];
 
+#ifdef CONFIG_IRQ_DOMAIN
 static struct irq_domain domain;
+#endif
 
 /* mapping the module id to slave id and base address */
 struct twl_mapping {
@@ -1226,13 +1228,13 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
 	pdata->irq_base = status;
 	pdata->irq_end = pdata->irq_base + nr_irqs;
 
+#ifdef CONFIG_IRQ_DOMAIN
 	domain.irq_base = pdata->irq_base;
 	domain.nr_irq = nr_irqs;
-#ifdef CONFIG_OF_IRQ
 	domain.of_node = of_node_get(node);
 	domain.ops = &irq_domain_simple_ops;
-#endif
 	irq_domain_add(&domain);
+#endif
 
 	if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
 		dev_dbg(&client->dev, "can't talk I2C?\n");
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index d905f51..79ca33d 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -124,7 +124,7 @@ static u8 res_config_addrs[] = {
 	[RES_MAIN_REF]	= 0x94,
 };
 
-static int __init twl4030_write_script_byte(u8 address, u8 byte)
+static int __devinit twl4030_write_script_byte(u8 address, u8 byte)
 {
 	int err;
 
@@ -138,7 +138,7 @@ static int __init twl4030_write_script_byte(u8 address, u8 byte)
 	return err;
 }
 
-static int __init twl4030_write_script_ins(u8 address, u16 pmb_message,
+static int __devinit twl4030_write_script_ins(u8 address, u16 pmb_message,
 					   u8 delay, u8 next)
 {
 	int err;
@@ -158,7 +158,7 @@ static int __init twl4030_write_script_ins(u8 address, u16 pmb_message,
 	return err;
 }
 
-static int __init twl4030_write_script(u8 address, struct twl4030_ins *script,
+static int __devinit twl4030_write_script(u8 address, struct twl4030_ins *script,
 				       int len)
 {
 	int err;
@@ -183,7 +183,7 @@ static int __init twl4030_write_script(u8 address, struct twl4030_ins *script,
 	return err;
 }
 
-static int __init twl4030_config_wakeup3_sequence(u8 address)
+static int __devinit twl4030_config_wakeup3_sequence(u8 address)
 {
 	int err;
 	u8 data;
@@ -208,7 +208,7 @@ static int __init twl4030_config_wakeup3_sequence(u8 address)
 	return err;
 }
 
-static int __init twl4030_config_wakeup12_sequence(u8 address)
+static int __devinit twl4030_config_wakeup12_sequence(u8 address)
 {
 	int err = 0;
 	u8 data;
@@ -262,7 +262,7 @@ static int __init twl4030_config_wakeup12_sequence(u8 address)
 	return err;
 }
 
-static int __init twl4030_config_sleep_sequence(u8 address)
+static int __devinit twl4030_config_sleep_sequence(u8 address)
 {
 	int err;
 
@@ -276,7 +276,7 @@ static int __init twl4030_config_sleep_sequence(u8 address)
 	return err;
 }
 
-static int __init twl4030_config_warmreset_sequence(u8 address)
+static int __devinit twl4030_config_warmreset_sequence(u8 address)
 {
 	int err;
 	u8 rd_data;
@@ -324,7 +324,7 @@ static int __init twl4030_config_warmreset_sequence(u8 address)
 	return err;
 }
 
-static int __init twl4030_configure_resource(struct twl4030_resconfig *rconfig)
+static int __devinit twl4030_configure_resource(struct twl4030_resconfig *rconfig)
 {
 	int rconfig_addr;
 	int err;
@@ -416,7 +416,7 @@ static int __init twl4030_configure_resource(struct twl4030_resconfig *rconfig)
 	return 0;
 }
 
-static int __init load_twl4030_script(struct twl4030_script *tscript,
+static int __devinit load_twl4030_script(struct twl4030_script *tscript,
 	       u8 address)
 {
 	int err;
@@ -527,7 +527,7 @@ void twl4030_power_off(void)
 		pr_err("TWL4030 Unable to power off\n");
 }
 
-void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
+void __devinit twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
 {
 	int err = 0;
 	int i;

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 04:28]:
> On Sat, Feb 04, 2012 at 05:25:57PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 12:03]:
> > > 
> > > Another problem (some build errors for OMAP3) do seem to be solved, but
> > > not the section mismatch warnings.  They're easy to verify before code
> > > gets pushed anywhere upstream, especially if you're doing one giant OMAP
> > > build - just enable CONFIG_DEBUG_SECTION_MISMATCH in your build
> > > configuration.  Refuse patches which introduce section mismatches - at
> > > least without an explanation backing up why they do.
> > >
> > > My OMAP3 and OMAP4 configurations spit out these - I've not even tried
> > > my OMAP2 configuration yet:
> > 
> > Weird. The warnings you're seeing all seem valid to me, but I'm not seeing
> > any the section warnings with the following compilers I have:
> > 
> > gcc version 4.3.5 (Debian 4.3.5-4)
> > gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)
> > gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70)
> > 
> > I see _different_ warnings if I compile with an older gcc:
> > gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)
> > 
> > Any ideas why that would be?
> 
> Different inlining behaviour maybe?  I'm using stock gcc 4.3.5 here.

Hmm I'd assume the Emdebian gcc 4.3.5-4 would be very close to the
stock gcc, need to investigate.
...
 
> If I look at this warning:
> 
> WARNING: vmlinux.o(.text+0x1c434): Section mismatch in reference from the fun$> The function omap_serial_fill_default_pads() references
> the (unknown reference) __initdata (unknown).
> This is often because omap_serial_fill_default_pads lacks a __initdata
> annotation or the annotation of (unknown) is wrong.
> 
> on OMAP3, where CONFIG_OMAP_MUX=y and CONFIG_CC_OPTIMIZE_FOR_SIZE=y,
> then, the reason I don't get that warning is because
> omap_serial_fill_default_pads() gets folded into omap_serial_board_init()
> for me.  There's not much which can be done to stop that thing happening.

I guess the -fno-inline-functions-called-once should keep that from folding
into omap_serial_board_init though?
 
> However, the fact that you're not finding stuff like the reference from
> 
> static int __devinit
> twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> 
> to:
> 
> void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
> 
> between two separate files is very worrying, and does indicate that
> something is broken - there's no way that the compiler could 'optimize'
> this by folding twl4030_power_init() into twl_probe() between the two
> files.

Yes I need to investigate why I'm not seeing the warnings, but sounds
like there's also something else wrong.
 
> In any case, here's my current (tested) patch unbreaking OMAP as a whole,
> not only for all these section mismatches but the more fundamental issues
> like the broken serial ports on OMAP3 and the irq domain buggeration too.
> 
> This leaves one section mismatch for me in the OMAP hotplug code.

OK great all the section mismatch warning fixes look correct to me
except one. The ones that make things __init should be a separate
clean-up patch for the next merge window.

> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -259,6 +259,8 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
>  	struct omap3_idle_statedata *cx;
>  	int ret;
>  
> +	{ new_state_idx = drv->safe_state_index; goto select_state; }
> +
>  	/*
>  	 * Prevent idle completely if CAM is active.
>  	 * CAM does not have wakeup capability in OMAP3.

This is something Kevin needs to look.

> --- a/arch/arm/mach-omap2/hsmmc.c
> +++ b/arch/arm/mach-omap2/hsmmc.c
> @@ -293,8 +293,8 @@ static inline void omap_hsmmc_mux(struct omap_mmc_platform_data *mmc_controller,
>  	}
>  }
>  
> -static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
> -					struct omap_mmc_platform_data *mmc)
> +static int omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
> +				 struct omap_mmc_platform_data *mmc)
>  {
>  	char *hc_name;
>  
> @@ -430,7 +430,7 @@ static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
>  
>  #define MAX_OMAP_MMC_HWMOD_NAME_LEN		16
>  
> -void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
> +void omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
>  {
>  	struct omap_hwmod *oh;
>  	struct platform_device *pdev;
> @@ -487,7 +487,7 @@ void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
>  	kfree(mmc_data);
>  }
>  
> -void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
> +void omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
>  {
>  	u32 reg;
>  

All these hsmmc_init functions should stay __init. There's something wrong
in the calling function if that's not the case. Or else there's something
wrong inside these functions that needs to be fixed.

Does making sdp3430_twl_gpio_setup() into __init fix those warnings
for you? That should be safe as omap3430_i2c_init() is __init.

> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -100,8 +100,8 @@ void omap_mux_write_array(struct omap_mux_partition *partition,
>  
>  static char *omap_mux_options;
>  
> -static int __init _omap_mux_init_gpio(struct omap_mux_partition *partition,
> -				      int gpio, int val)
> +static int _omap_mux_init_gpio(struct omap_mux_partition *partition,
> +			       int gpio, int val)
>  {
>  	struct omap_mux_entry *e;
>  	struct omap_mux *gpio_mux = NULL;
> @@ -145,7 +145,7 @@ static int __init _omap_mux_init_gpio(struct omap_mux_partition *partition,
>  	return 0;
>  }
>  
> -int __init omap_mux_init_gpio(int gpio, int val)
> +int omap_mux_init_gpio(int gpio, int val)
>  {
>  	struct omap_mux_partition *partition;
>  	int ret;
> @@ -159,9 +159,9 @@ int __init omap_mux_init_gpio(int gpio, int val)
>  	return -ENODEV;
>  }
>  
> -static int __init _omap_mux_get_by_name(struct omap_mux_partition *partition,
> -					const char *muxname,
> -					struct omap_mux **found_mux)
> +static int _omap_mux_get_by_name(struct omap_mux_partition *partition,
> +				 const char *muxname,
> +				 struct omap_mux **found_mux)
>  {
>  	struct omap_mux *mux = NULL;
>  	struct omap_mux_entry *e;
> @@ -240,7 +240,7 @@ omap_mux_get_by_name(const char *muxname,
>  	return -ENODEV;
>  }
>  
> -int __init omap_mux_init_signal(const char *muxname, int val)
> +int omap_mux_init_signal(const char *muxname, int val)
>  {
>  	struct omap_mux_partition *partition = NULL;
>  	struct omap_mux *mux = NULL;
> @@ -1094,8 +1094,8 @@ static void omap_mux_init_package(struct omap_mux *superset,
>  		omap_mux_package_init_balls(package_balls, superset);
>  }
>  
> -static void omap_mux_init_signals(struct omap_mux_partition *partition,
> -				  struct omap_board_mux *board_mux)
> +static void __init omap_mux_init_signals(struct omap_mux_partition *partition,
> +					 struct omap_board_mux *board_mux)
>  {
>  	omap_mux_set_cmdline_signals();
>  	omap_mux_write_array(partition, board_mux);
> @@ -1109,8 +1109,8 @@ static void omap_mux_init_package(struct omap_mux *superset,
>  {
>  }
>  
> -static void omap_mux_init_signals(struct omap_mux_partition *partition,
> -				  struct omap_board_mux *board_mux)
> +static void __init omap_mux_init_signals(struct omap_mux_partition *partition,
> +					 struct omap_board_mux *board_mux)
>  {
>  }
>  

All the omap_mux_init_* functions should also __init. Again, there's
something wrong with the calling function if the caller is not __init.

> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
>  {
>  	local_fiq_disable();
>  
> -	if (omap_irq_pending())
> +	if (omap_irq_pending() || 1)
>  		goto out;
>  
>  	trace_power_start(POWER_CSTATE, 1, smp_processor_id());

This does not look right to me. I thought reverting of the serial
patches should have already solved the issue you're seeing with
slow serial port?

Those are the reverting commits drivers/tty/serial/serial-omap.c:

8a74e9ffd97dc9de063de8c02ae32db79dd60436 (Revert "tty: serial: OMAP: ensure
FIFO levels are set correctly in non-DMA mode")

af681cad3f79ad8f7bd6cb170b70990aeef74233 (Revert "tty: serial: OMAP: transmit
FIFO threshold interrupts don't wake the chip")

Kevin, any comments on this?

> --- a/arch/arm/mach-omap2/prm44xx.c
> +++ b/arch/arm/mach-omap2/prm44xx.c
> @@ -19,6 +19,7 @@
>  
>  #include "common.h"
>  #include <plat/cpu.h>
> +#include <plat/irqs.h>
>  #include <plat/prcm.h>
>  
>  #include "vp.h"

Yup, this is the right fix. Probably should be a separate patch with
error description you posted earlier.

> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -200,7 +200,7 @@ config MENELAUS
>  
>  config TWL4030_CORE
>  	bool "Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support"
> -	depends on I2C=y && GENERIC_HARDIRQS && IRQ_DOMAIN
> +	depends on I2C=y && GENERIC_HARDIRQS
>  	help
>  	  Say yes here if you have TWL4030 / TWL6030 family chip on your board.
>  	  This core driver provides register access and IRQ handling
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -263,7 +263,9 @@ struct twl_client {
>  
>  static struct twl_client twl_modules[TWL_NUM_SLAVES];
>  
> +#ifdef CONFIG_IRQ_DOMAIN
>  static struct irq_domain domain;
> +#endif
>  
>  /* mapping the module id to slave id and base address */
>  struct twl_mapping {
> @@ -1226,13 +1228,13 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
>  	pdata->irq_base = status;
>  	pdata->irq_end = pdata->irq_base + nr_irqs;
>  
> +#ifdef CONFIG_IRQ_DOMAIN
>  	domain.irq_base = pdata->irq_base;
>  	domain.nr_irq = nr_irqs;
> -#ifdef CONFIG_OF_IRQ
>  	domain.of_node = of_node_get(node);
>  	domain.ops = &irq_domain_simple_ops;
> -#endif
>  	irq_domain_add(&domain);
> +#endif
>  
>  	if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
>  		dev_dbg(&client->dev, "can't talk I2C?\n");

The above should be a separate fix to the drivers/mfd/twl code.

Also, let's ask Samuel not to merge any more TWL/TPS patches until the
TWL module issues are fixed first. That is, the system should boot without
TWL compiled in, and it should also work as a loadable module.

> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -124,7 +124,7 @@ static u8 res_config_addrs[] = {
>  	[RES_MAIN_REF]	= 0x94,
>  };
>  
> -static int __init twl4030_write_script_byte(u8 address, u8 byte)
> +static int __devinit twl4030_write_script_byte(u8 address, u8 byte)
>  {
>  	int err;
>  
...

These __init to __devinit changes should be a separate clean-up
patch for the next merge window.

Regards,

Tony

Re: OMAP34xx

[Russell King - ARM Linux]

On Sun, Feb 05, 2012 at 09:29:25AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 04:28]:
> > In any case, here's my current (tested) patch unbreaking OMAP as a whole,
> > not only for all these section mismatches but the more fundamental issues
> > like the broken serial ports on OMAP3 and the irq domain buggeration too.
> > 
> > This leaves one section mismatch for me in the OMAP hotplug code.
> 
> OK great all the section mismatch warning fixes look correct to me
> except one. The ones that make things __init should be a separate
> clean-up patch for the next merge window.

Err.  This stuff _really_ isn't merge window stuff.  It's -rc stuff.  Why?

If there's the possibility that stuff in the .init sections could be
called after it has been discarded (which is basically what the
section mismatch warnings are telling you) there is the potential for
OOPSing the kernel.

They are _bug_ fixes.

> > --- a/arch/arm/mach-omap2/hsmmc.c
> > +++ b/arch/arm/mach-omap2/hsmmc.c
> > @@ -293,8 +293,8 @@ static inline void omap_hsmmc_mux(struct omap_mmc_platform_data *mmc_controller,
> >  	}
> >  }
> >  
> > -static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
> > -					struct omap_mmc_platform_data *mmc)
> > +static int omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
> > +				 struct omap_mmc_platform_data *mmc)
> >  {
> >  	char *hc_name;
> >  
> > @@ -430,7 +430,7 @@ static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
> >  
> >  #define MAX_OMAP_MMC_HWMOD_NAME_LEN		16
> >  
> > -void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
> > +void omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
> >  {
> >  	struct omap_hwmod *oh;
> >  	struct platform_device *pdev;
> > @@ -487,7 +487,7 @@ void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
> >  	kfree(mmc_data);
> >  }
> >  
> > -void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
> > +void omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
> >  {
> >  	u32 reg;
> >  
> 
> All these hsmmc_init functions should stay __init. There's something wrong
> in the calling function if that's not the case. Or else there's something
> wrong inside these functions that needs to be fixed.

Incorrect.  Let's see why - taking 3430SDP as an example:

static int sdp3430_twl_gpio_setup(struct device *dev,
                unsigned gpio, unsigned ngpio)
{
        /* gpio + 0 is "mmc0_cd" (input/IRQ),
         * gpio + 1 is "mmc1_cd" (input/IRQ)
         */
        mmc[0].gpio_cd = gpio + 0;
        mmc[1].gpio_cd = gpio + 1;
        omap2_hsmmc_init(mmc);

        /* gpio + 7 is "sub_lcd_en_bkl" (output/PWM1) */
        gpio_request_one(gpio + 7, GPIOF_OUT_INIT_LOW, "sub_lcd_en_bkl");

        /* gpio + 15 is "sub_lcd_nRST" (output) */
        gpio_request_one(gpio + 15, GPIOF_OUT_INIT_LOW, "sub_lcd_nRST");

        return 0;
}

static struct twl4030_gpio_platform_data sdp3430_gpio_data = {
        .setup          = sdp3430_twl_gpio_setup,
};

So, we have a non-__init function calling an __init function which will
be discarded at runtime and the memory associated with omap2_hsmmc_init()
poisoned.

Now, the question is, can this function be called at runtime?  Well,
this is platform data for the TWL4030 GPIO platform device, and the
TWL4030 GPIO platform driver is a loadable module:

config GPIO_TWL4030
        tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"

So, it can be built as a loadable module, and then loaded into the
kernel _after_ the __init code has been discarded.  When that happens
on the 3430SDP, the .setup function will be called, and therefore the
discarded omap2_hsmmc_init() will also be called.

Therefore omap2_hsmmc_init() and its called functions _must_ _not_ be
marked __init - or 3430SDP needs to be fixed so that HSMMC is not
dependent on TWL4030.

But, as long as the code is structured in this way, the HSMMC code
_must_ lose its __init attributes.

What I suggest is that these changes get applied as is for -rc, fixing
the OOPS potential of the current situation.  Then, for the merge window,
a proper solution to the 'omap2_hsmmc_init() might be called after init
time' problem gets merged and then these functions can go back to being
__init marked.

> Does making sdp3430_twl_gpio_setup() into __init fix those warnings
> for you? That should be safe as omap3430_i2c_init() is __init.

See above why that's a very very wrong solution.

> > --- a/arch/arm/mach-omap2/mux.c
> > +++ b/arch/arm/mach-omap2/mux.c
> > @@ -100,8 +100,8 @@ void omap_mux_write_array(struct omap_mux_partition *partition,
> >  
> >  static char *omap_mux_options;
> >  
> > -static int __init _omap_mux_init_gpio(struct omap_mux_partition *partition,
> > -				      int gpio, int val)
> > +static int _omap_mux_init_gpio(struct omap_mux_partition *partition,
> > +			       int gpio, int val)
> >  {
> >  	struct omap_mux_entry *e;
> >  	struct omap_mux *gpio_mux = NULL;
> > @@ -145,7 +145,7 @@ static int __init _omap_mux_init_gpio(struct omap_mux_partition *partition,
> >  	return 0;
> >  }
> >  
> > -int __init omap_mux_init_gpio(int gpio, int val)
> > +int omap_mux_init_gpio(int gpio, int val)
> >  {
> >  	struct omap_mux_partition *partition;
> >  	int ret;
> > @@ -159,9 +159,9 @@ int __init omap_mux_init_gpio(int gpio, int val)
> >  	return -ENODEV;
> >  }
> >  
> > -static int __init _omap_mux_get_by_name(struct omap_mux_partition *partition,
> > -					const char *muxname,
> > -					struct omap_mux **found_mux)
> > +static int _omap_mux_get_by_name(struct omap_mux_partition *partition,
> > +				 const char *muxname,
> > +				 struct omap_mux **found_mux)
> >  {
> >  	struct omap_mux *mux = NULL;
> >  	struct omap_mux_entry *e;
> > @@ -240,7 +240,7 @@ omap_mux_get_by_name(const char *muxname,
> >  	return -ENODEV;
> >  }
> >  
> > -int __init omap_mux_init_signal(const char *muxname, int val)
> > +int omap_mux_init_signal(const char *muxname, int val)
> >  {
> >  	struct omap_mux_partition *partition = NULL;
> >  	struct omap_mux *mux = NULL;
> > @@ -1094,8 +1094,8 @@ static void omap_mux_init_package(struct omap_mux *superset,
> >  		omap_mux_package_init_balls(package_balls, superset);
> >  }
> >  
> > -static void omap_mux_init_signals(struct omap_mux_partition *partition,
> > -				  struct omap_board_mux *board_mux)
> > +static void __init omap_mux_init_signals(struct omap_mux_partition *partition,
> > +					 struct omap_board_mux *board_mux)
> >  {
> >  	omap_mux_set_cmdline_signals();
> >  	omap_mux_write_array(partition, board_mux);
> > @@ -1109,8 +1109,8 @@ static void omap_mux_init_package(struct omap_mux *superset,
> >  {
> >  }
> >  
> > -static void omap_mux_init_signals(struct omap_mux_partition *partition,
> > -				  struct omap_board_mux *board_mux)
> > +static void __init omap_mux_init_signals(struct omap_mux_partition *partition,
> > +					 struct omap_board_mux *board_mux)
> >  {
> >  }
> >  
> 
> All the omap_mux_init_* functions should also __init. Again, there's
> something wrong with the calling function if the caller is not __init.

I disagree.

Unfortunately, you have code which is not __init only which calls them.
As I've already proven above, for example, hsmmc stuff must not be marked
__init given the current structure of OMAP code.  Because hsmmc calls
into the OMAP mux stuff (specifically omap_mux_init_signal()) it too
can't be marked __init.

So, for now the __init stuff must go, until the bigger problem of
why omap2_hsmmc_init() can get called from non-init contexts.

> 
> > --- a/arch/arm/mach-omap2/pm34xx.c
> > +++ b/arch/arm/mach-omap2/pm34xx.c
> > @@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
> >  {
> >  	local_fiq_disable();
> >  
> > -	if (omap_irq_pending())
> > +	if (omap_irq_pending() || 1)
> >  		goto out;
> >  
> >  	trace_power_start(POWER_CSTATE, 1, smp_processor_id());
> 
> This does not look right to me. I thought reverting of the serial
> patches should have already solved the issue you're seeing with
> slow serial port?
> 
> Those are the reverting commits drivers/tty/serial/serial-omap.c:
> 
> 8a74e9ffd97dc9de063de8c02ae32db79dd60436 (Revert "tty: serial: OMAP: ensure
> FIFO levels are set correctly in non-DMA mode")
> 
> af681cad3f79ad8f7bd6cb170b70990aeef74233 (Revert "tty: serial: OMAP: transmit
> FIFO threshold interrupts don't wake the chip")

These commits have absolutely nothing to do with it.  I pointed out the
bad commit in one of my emails:

commit 2fd149645eb46d26130d7070c6de037dddf34880
Author: Govindraj.R <govindraj.raja@ti.com>
Date:   Wed Nov 9 17:41:21 2011 +0530

    ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
    
    Omap_uart_can_sleep function blocks system wide low power state until
    uart is active remove this func and add qos requests to prevent
    MPU from transitioning.
    
    Keep qos request to default value which will allow MPU to transition
    and while uart baud rate is available calculate the latency value
    from the baudrate and use the same to hold constraint while uart clocks
    are enabled, and if uart is auto-idled the constraint is updated with
    default constraint value allowing MPU to transition.
    
    Qos requests are blocking notifier calls so put these requests to
    work queue, also the driver uses irq_safe version of runtime API's
    and callbacks can be called in interrupt disabled context.
    So to avoid warn on slow path warning while using qos update
    API's from runtime callbacks use the qos_work_queue.
    
    During bootup the runtime_resume call backs might not be called and runtime
    callback gets called only after uart is idled by setting the autosuspend
    timeout. So qos_request from runtime resume callback might not activated during
    boot if uart baudrate is calculated during bootup for console uart, so schedule
    the qos_work queue once we calc_latency while configuring the uart port.
    
    Flush and complete any pending qos jobs in work queue while suspending.
    
    Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
    Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes)
    Signed-off-by: Kevin Hilman <khilman@ti.com>

Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs
while in some of the deeper low power modes.

I tried reverting the rest of the patches between this one and HEAD for
omap-serial.c, but they have no effect what so ever on this bug.  As I
said in one of my emails in this thread, the above commit can't be
trivially reverted because some other stuff that the code relied upon
has vanished.

So, the above along with the other part in arch/arm/mach-omap2/cpuidle34xx.c
is the smallest 'fix' I could find of resolving the regression.

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 09:27]:
> On Sun, Feb 05, 2012 at 09:29:25AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 04:28]:
> > > In any case, here's my current (tested) patch unbreaking OMAP as a whole,
> > > not only for all these section mismatches but the more fundamental issues
> > > like the broken serial ports on OMAP3 and the irq domain buggeration too.
> > > 
> > > This leaves one section mismatch for me in the OMAP hotplug code.
> > 
> > OK great all the section mismatch warning fixes look correct to me
> > except one. The ones that make things __init should be a separate
> > clean-up patch for the next merge window.
> 
> Err.  This stuff _really_ isn't merge window stuff.  It's -rc stuff.  Why?
> 
> If there's the possibility that stuff in the .init sections could be
> called after it has been discarded (which is basically what the
> section mismatch warnings are telling you) there is the potential for
> OOPSing the kernel.
> 
> They are _bug_ fixes.

Of course if that's the case.
 
> So, we have a non-__init function calling an __init function which will
> be discarded at runtime and the memory associated with omap2_hsmmc_init()
> poisoned.
> 
> Now, the question is, can this function be called at runtime?  Well,
> this is platform data for the TWL4030 GPIO platform device, and the
> TWL4030 GPIO platform driver is a loadable module:
> 
> config GPIO_TWL4030
>         tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
> 
> So, it can be built as a loadable module, and then loaded into the
> kernel _after_ the __init code has been discarded.  When that happens
> on the 3430SDP, the .setup function will be called, and therefore the
> discarded omap2_hsmmc_init() will also be called.
> 
> Therefore omap2_hsmmc_init() and its called functions _must_ _not_ be
> marked __init - or 3430SDP needs to be fixed so that HSMMC is not
> dependent on TWL4030.
> 
> But, as long as the code is structured in this way, the HSMMC code
> _must_ lose its __init attributes.
> 
> What I suggest is that these changes get applied as is for -rc, fixing
> the OOPS potential of the current situation.  Then, for the merge window,
> a proper solution to the 'omap2_hsmmc_init() might be called after init
> time' problem gets merged and then these functions can go back to being
> __init marked.
> 
> > Does making sdp3430_twl_gpio_setup() into __init fix those warnings
> > for you? That should be safe as omap3430_i2c_init() is __init.
> 
> See above why that's a very very wrong solution.

Argh. Yes you're right, the card change detect GPIOs on I2C cause the
nasty issue here if twl is a module. How horrible.
 
> > All the omap_mux_init_* functions should also __init. Again, there's
> > something wrong with the calling function if the caller is not __init.
> 
> I disagree.
> 
> Unfortunately, you have code which is not __init only which calls them.
> As I've already proven above, for example, hsmmc stuff must not be marked
> __init given the current structure of OMAP code.  Because hsmmc calls
> into the OMAP mux stuff (specifically omap_mux_init_signal()) it too
> can't be marked __init.
> 
> So, for now the __init stuff must go, until the bigger problem of
> why omap2_hsmmc_init() can get called from non-init contexts.

Argh. Yes right you are. We need to fix this properly too though, this
is only a short term solution.

> > > --- a/arch/arm/mach-omap2/pm34xx.c
> > > +++ b/arch/arm/mach-omap2/pm34xx.c
> > > @@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
> > >  {
> > >  	local_fiq_disable();
> > >  
> > > -	if (omap_irq_pending())
> > > +	if (omap_irq_pending() || 1)
> > >  		goto out;
> > >  
> > >  	trace_power_start(POWER_CSTATE, 1, smp_processor_id());
> > 
> > This does not look right to me. I thought reverting of the serial
> > patches should have already solved the issue you're seeing with
> > slow serial port?
> > 
> > Those are the reverting commits drivers/tty/serial/serial-omap.c:
> > 
> > 8a74e9ffd97dc9de063de8c02ae32db79dd60436 (Revert "tty: serial: OMAP: ensure
> > FIFO levels are set correctly in non-DMA mode")
> > 
> > af681cad3f79ad8f7bd6cb170b70990aeef74233 (Revert "tty: serial: OMAP: transmit
> > FIFO threshold interrupts don't wake the chip")
> 
> These commits have absolutely nothing to do with it.  I pointed out the
> bad commit in one of my emails:
> 
> commit 2fd149645eb46d26130d7070c6de037dddf34880
> Author: Govindraj.R <govindraj.raja@ti.com>
> Date:   Wed Nov 9 17:41:21 2011 +0530
> 
>     ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
>     
>     Omap_uart_can_sleep function blocks system wide low power state until
>     uart is active remove this func and add qos requests to prevent
>     MPU from transitioning.
>     
>     Keep qos request to default value which will allow MPU to transition
>     and while uart baud rate is available calculate the latency value
>     from the baudrate and use the same to hold constraint while uart clocks
>     are enabled, and if uart is auto-idled the constraint is updated with
>     default constraint value allowing MPU to transition.
>     
>     Qos requests are blocking notifier calls so put these requests to
>     work queue, also the driver uses irq_safe version of runtime API's
>     and callbacks can be called in interrupt disabled context.
>     So to avoid warn on slow path warning while using qos update
>     API's from runtime callbacks use the qos_work_queue.
>     
>     During bootup the runtime_resume call backs might not be called and runtime
>     callback gets called only after uart is idled by setting the autosuspend
>     timeout. So qos_request from runtime resume callback might not activated during
>     boot if uart baudrate is calculated during bootup for console uart, so schedule
>     the qos_work queue once we calc_latency while configuring the uart port.
>     
>     Flush and complete any pending qos jobs in work queue while suspending.
>     
>     Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
>     Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes)
>     Signed-off-by: Kevin Hilman <khilman@ti.com>
> 
> Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs
> while in some of the deeper low power modes.
> 
> I tried reverting the rest of the patches between this one and HEAD for
> omap-serial.c, but they have no effect what so ever on this bug.  As I
> said in one of my emails in this thread, the above commit can't be
> trivially reverted because some other stuff that the code relied upon
> has vanished.
> 
> So, the above along with the other part in arch/arm/mach-omap2/cpuidle34xx.c
> is the smallest 'fix' I could find of resolving the regression.

OK, thanks, that should be enough info for let Kevin take a look at this.

Regards,

Tony

Re: OMAP34xx

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

[...]

>> > > --- a/arch/arm/mach-omap2/pm34xx.c
>> > > +++ b/arch/arm/mach-omap2/pm34xx.c
>> > > @@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
>> > >  {
>> > >  	local_fiq_disable();
>> > >  
>> > > -	if (omap_irq_pending())
>> > > +	if (omap_irq_pending() || 1)
>> > >  		goto out;
>> > >  
>> > >  	trace_power_start(POWER_CSTATE, 1, smp_processor_id());
>> > 
>> > This does not look right to me. I thought reverting of the serial
>> > patches should have already solved the issue you're seeing with
>> > slow serial port?
>> > 
>> > Those are the reverting commits drivers/tty/serial/serial-omap.c:
>> > 
>> > 8a74e9ffd97dc9de063de8c02ae32db79dd60436 (Revert "tty: serial: OMAP: ensure
>> > FIFO levels are set correctly in non-DMA mode")
>> > 
>> > af681cad3f79ad8f7bd6cb170b70990aeef74233 (Revert "tty: serial: OMAP: transmit
>> > FIFO threshold interrupts don't wake the chip")
>> 
>> These commits have absolutely nothing to do with it.  I pointed out the
>> bad commit in one of my emails:
>> 
>> commit 2fd149645eb46d26130d7070c6de037dddf34880
>> Author: Govindraj.R <govindraj.raja@ti.com>
>> Date:   Wed Nov 9 17:41:21 2011 +0530
>> 
>>     ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
>>     
>>     Omap_uart_can_sleep function blocks system wide low power state until
>>     uart is active remove this func and add qos requests to prevent
>>     MPU from transitioning.
>>     
>>     Keep qos request to default value which will allow MPU to transition
>>     and while uart baud rate is available calculate the latency value
>>     from the baudrate and use the same to hold constraint while uart clocks
>>     are enabled, and if uart is auto-idled the constraint is updated with
>>     default constraint value allowing MPU to transition.
>>     
>>     Qos requests are blocking notifier calls so put these requests to
>>     work queue, also the driver uses irq_safe version of runtime API's
>>     and callbacks can be called in interrupt disabled context.
>>     So to avoid warn on slow path warning while using qos update
>>     API's from runtime callbacks use the qos_work_queue.
>>     
>>     During bootup the runtime_resume call backs might not be called and runtime
>>     callback gets called only after uart is idled by setting the autosuspend
>>     timeout. So qos_request from runtime resume callback might not activated during
>>     boot if uart baudrate is calculated during bootup for console uart, so schedule
>>     the qos_work queue once we calc_latency while configuring the uart port.
>>     
>>     Flush and complete any pending qos jobs in work queue while suspending.
>>     
>>     Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
>>     Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes)
>>     Signed-off-by: Kevin Hilman <khilman@ti.com>
>> 
>> Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs
>> while in some of the deeper low power modes.
>> 
>> I tried reverting the rest of the patches between this one and HEAD for
>> omap-serial.c, but they have no effect what so ever on this bug.  As I
>> said in one of my emails in this thread, the above commit can't be
>> trivially reverted because some other stuff that the code relied upon
>> has vanished.
>> 
>> So, the above along with the other part in arch/arm/mach-omap2/cpuidle34xx.c
>> is the smallest 'fix' I could find if resolving the regression.
>
> OK, thanks, that should be enough info for let Kevin take a look at this.

This one is indeed strange.  I have not seen this on the 34xx devices
I'm using (3430/n900, 3530/Overo, 3630/Zoom3).  

Just to confirm.  I assume you are using v3.3-rc2 (or later Linus
master) which has a few fixes for this driver already.

Also, is this happening on your LDP.  Which ES revision does your 3430
have?
 
Kevin

Re: OMAP34xx

[Víctor M. Jáquez L.]

On Tue, Feb 07, 2012 at 02:36:06PM -0800, Kevin Hilman wrote:
> Tony Lindgren <tony@atomide.com> writes:
> 
> [...]
> 
> >> > > --- a/arch/arm/mach-omap2/pm34xx.c
> >> > > +++ b/arch/arm/mach-omap2/pm34xx.c
> >> > > @@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
> >> > >  {
> >> > >  	local_fiq_disable();
> >> > >  
> >> > > -	if (omap_irq_pending())
> >> > > +	if (omap_irq_pending() || 1)
> >> > >  		goto out;
> >> > >  
> >> > >  	trace_power_start(POWER_CSTATE, 1, smp_processor_id());
> >> > 
> >> > This does not look right to me. I thought reverting of the serial
> >> > patches should have already solved the issue you're seeing with
> >> > slow serial port?
> >> > 
> >> > Those are the reverting commits drivers/tty/serial/serial-omap.c:
> >> > 
> >> > 8a74e9ffd97dc9de063de8c02ae32db79dd60436 (Revert "tty: serial: OMAP: ensure
> >> > FIFO levels are set correctly in non-DMA mode")
> >> > 
> >> > af681cad3f79ad8f7bd6cb170b70990aeef74233 (Revert "tty: serial: OMAP: transmit
> >> > FIFO threshold interrupts don't wake the chip")
> >> 
> >> These commits have absolutely nothing to do with it.  I pointed out the
> >> bad commit in one of my emails:
> >> 
> >> commit 2fd149645eb46d26130d7070c6de037dddf34880
> >> Author: Govindraj.R <govindraj.raja@ti.com>
> >> Date:   Wed Nov 9 17:41:21 2011 +0530
> >> 
> >>     ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
> >>     

[...]

> >> 
> >> Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs
> >> while in some of the deeper low power modes.
> >> 
> >> I tried reverting the rest of the patches between this one and HEAD for
> >> omap-serial.c, but they have no effect what so ever on this bug.  As I
> >> said in one of my emails in this thread, the above commit can't be
> >> trivially reverted because some other stuff that the code relied upon
> >> has vanished.
> >> 
> >> So, the above along with the other part in arch/arm/mach-omap2/cpuidle34xx.c
> >> is the smallest 'fix' I could find if resolving the regression.
> >
> > OK, thanks, that should be enough info for let Kevin take a look at this.
> 
> This one is indeed strange.  I have not seen this on the 34xx devices
> I'm using (3430/n900, 3530/Overo, 3630/Zoom3).  
> 
> Just to confirm.  I assume you are using v3.3-rc2 (or later Linus
> master) which has a few fixes for this driver already.

If it helps, I observed the same issue in a beagleboard rev B6, with v3.3-rc2

Russell's patch fixed it.

vmjl

> 
> Also, is this happening on your LDP.  Which ES revision does your 3430
> have?
>  
> Kevin

Re: OMAP34xx

[Russell King - ARM Linux]

On Tue, Feb 07, 2012 at 04:08:23PM -0800, Kevin Hilman wrote:
> Víctor M. Jáquez L. <vjaquez@igalia.com> writes:
> > If it helps, I observed the same issue in a beagleboard rev B6, with
> > v3.3-rc2
> 
> Great, thanks.  Can you share your ~/.config?

If it helps, ARM Kautobuild V2 is up and running (assuming I don't break
the scripts again) at:

  http://www.arm.linux.org.uk/developer/build/

from where the build configs I use (and the exact ones used in those
compiles) are available.  These aren't configs in arch/arm/configs.

The OMAP oldconfig builds represent my test configs that I try to boot on
my boards.  This version of Kautobuild not only builds kernels, but it
also packages the built image and modules into a tar file.  Everything
else is discarded.

As of yesterday evening, it also transfers the built image to a TFTP
server ready for boards to fetch for boot testing.

The base kernel which is currently being used for this is whatever state
my working tree is in when it runs, so it's not _that_ useful externally
at the moment.

Currently, the builds run on my working laptop, targetted at 2am each
night local time (though they're a little more sporadic at the moment.)
The downside to them running on the laptop is that when I take the
laptop away, they won't run.


I also have a program which monitors a tty port, detects the initial
booting of a board, and can talk to the boot loader and kernel to instruct
them to do various things (like telling uboot to load one of the tftp'd
kernels.)

However, there's a few bits missing from being able to finish this system
off:

(a) properly detecting on machines monitoring boards when a new kernel is
    ready for testing.
(b) sorting out how to reliably reboot the various boards in a safe manner
(c) working out where and how to connect all these boards in a safe manner

For most boards, switching the mains to their individual power supplies
will work.  For something like the OMAP3430 LDP, it's complicated by its
built-in battery which has to be connected for it to power up at all.
It can't be left plugged in because it drains the battery even with an
external USB charger.

As the OMAP4430 only provides USB, practically it's going to have to be
left out of the automatic stuff because I don't have a machine which it
could be connected to which wouldn't also be part of the boot test farm.

In other words, the OMAP platforms I have will only be manually boot
tested for the forseeable future.
--
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: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 01:15]:
> On Tue, Feb 07, 2012 at 04:08:23PM -0800, Kevin Hilman wrote:
> > Víctor M. Jáquez L. <vjaquez@igalia.com> writes:
> > > If it helps, I observed the same issue in a beagleboard rev B6, with
> > > v3.3-rc2
> > 
> > Great, thanks.  Can you share your ~/.config?
> 
> If it helps, ARM Kautobuild V2 is up and running (assuming I don't break
> the scripts again) at:
> 
>   http://www.arm.linux.org.uk/developer/build/
> 
> from where the build configs I use (and the exact ones used in those
> compiles) are available.  These aren't configs in arch/arm/configs.

Great. How do you generate the allnoconfig there?

I tried:

ARCH=arm make KCONFIG_ALLCONFIG=my_config allnoconfig

But it really does a total ARM noconfig that currently has no chance
in building currently?

Regards,

Tony
--
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: OMAP34xx

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 11:55:30AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 01:15]:
> > On Tue, Feb 07, 2012 at 04:08:23PM -0800, Kevin Hilman wrote:
> > > Víctor M. Jáquez L. <vjaquez@igalia.com> writes:
> > > > If it helps, I observed the same issue in a beagleboard rev B6, with
> > > > v3.3-rc2
> > > 
> > > Great, thanks.  Can you share your ~/.config?
> > 
> > If it helps, ARM Kautobuild V2 is up and running (assuming I don't break
> > the scripts again) at:
> > 
> >   http://www.arm.linux.org.uk/developer/build/
> > 
> > from where the build configs I use (and the exact ones used in those
> > compiles) are available.  These aren't configs in arch/arm/configs.
> 
> Great. How do you generate the allnoconfig there?
> 
> I tried:
> 
> ARCH=arm make KCONFIG_ALLCONFIG=my_config allnoconfig
> 
> But it really does a total ARM noconfig that currently has no chance
> in building currently?

Each of the builds have a seed configuration, even allnoconfig.

The seed configuration for the oldconfig's are a 'make savedefconfig'
version of the build config I've been using.

For the allnoconfig, there's a minimal set of configuration symbols
to set - mainly to set the target platform but with CONFIG_MMU=y.

So, for the LDP, it's:

CONFIG_MMU=y
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP2PLUS=y
CONFIG_ARCH_OMAP3=y
CONFIG_SOC_OMAP3430=y
CONFIG_MACH_OMAP_LDP=y

and 4430SDP:

CONFIG_MMU=y
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP2PLUS=y
CONFIG_ARCH_OMAP4=y
CONFIG_MACH_OMAP_4430SDP=y
--
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: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 14:39]:
> On Wed, Feb 08, 2012 at 11:55:30AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 01:15]:
> > > On Tue, Feb 07, 2012 at 04:08:23PM -0800, Kevin Hilman wrote:
> > > > Víctor M. Jáquez L. <vjaquez@igalia.com> writes:
> > > > > If it helps, I observed the same issue in a beagleboard rev B6, with
> > > > > v3.3-rc2
> > > > 
> > > > Great, thanks.  Can you share your ~/.config?
> > > 
> > > If it helps, ARM Kautobuild V2 is up and running (assuming I don't break
> > > the scripts again) at:
> > > 
> > >   http://www.arm.linux.org.uk/developer/build/
> > > 
> > > from where the build configs I use (and the exact ones used in those
> > > compiles) are available.  These aren't configs in arch/arm/configs.
> > 
> > Great. How do you generate the allnoconfig there?
> > 
> > I tried:
> > 
> > ARCH=arm make KCONFIG_ALLCONFIG=my_config allnoconfig
> > 
> > But it really does a total ARM noconfig that currently has no chance
> > in building currently?
> 
> Each of the builds have a seed configuration, even allnoconfig.
> 
> The seed configuration for the oldconfig's are a 'make savedefconfig'
> version of the build config I've been using.
> 
> For the allnoconfig, there's a minimal set of configuration symbols
> to set - mainly to set the target platform but with CONFIG_MMU=y.
> 
> So, for the LDP, it's:
> 
> CONFIG_MMU=y
> CONFIG_ARCH_OMAP=y
> CONFIG_ARCH_OMAP2PLUS=y
> CONFIG_ARCH_OMAP3=y
> CONFIG_SOC_OMAP3430=y
> CONFIG_MACH_OMAP_LDP=y
> 
> and 4430SDP:
> 
> CONFIG_MMU=y
> CONFIG_ARCH_OMAP=y
> CONFIG_ARCH_OMAP2PLUS=y
> CONFIG_ARCH_OMAP4=y
> CONFIG_MACH_OMAP_4430SDP=y

OK thanks, so no KCONFIG_ALLCONFIG type magic there.

Regards,

Tony
--
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: OMAP34xx

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 09:45:58AM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 07, 2012 at 04:08:23PM -0800, Kevin Hilman wrote:
> > Víctor M. Jáquez L. <vjaquez@igalia.com> writes:
> > > If it helps, I observed the same issue in a beagleboard rev B6, with
> > > v3.3-rc2
> > 
> > Great, thanks.  Can you share your ~/.config?
> 
> If it helps, ARM Kautobuild V2 is up and running (assuming I don't break
> the scripts again) at:
> 
>   http://www.arm.linux.org.uk/developer/build/
> 
> from where the build configs I use (and the exact ones used in those
> compiles) are available.  These aren't configs in arch/arm/configs.

FYI, it now has one boot log for the 4430SDP, which is the only platform
I've enabled so far, and it requires me to manually power up the board
(so it's not going to happen for every build, which means the boot
results will only be up there for a day until I can sort out a more
automatic solution.)

It's not too good at detecting boots that 'pass' rather than 'fail' - at
the moment, it assumes it passed if it gets to the end of its script, so
this needs to be found from the boot log.  Currently, that means getting
a login prompt.

If anyone wants to develop a pcre regexp to detect oopses, warnings,
panics and other failures - my current for the page generation are:

errors: /^.*?\b(error|can't register|fail(ed)?)\b.*?$/mi
warnings: /^.*?\bwarning\b.*?$/mi

note that they operate on multi-line strings (hence the 'm' suffix and
the use of non-greedy "*?" as opposed to the greedy "*").  Install pcre
and see pcrepattern(3) for more information on pcre regexps if you're
unfamiliar with these.
--
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: OMAP34xx

[Kevin Hilman]

Kevin Hilman <khilman@ti.com> writes:

> Tony Lindgren <tony@atomide.com> writes:
>
> [...]
>
>>> > > --- a/arch/arm/mach-omap2/pm34xx.c
>>> > > +++ b/arch/arm/mach-omap2/pm34xx.c
>>> > > @@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
>>> > >  {
>>> > >  	local_fiq_disable();
>>> > >  
>>> > > -	if (omap_irq_pending())
>>> > > +	if (omap_irq_pending() || 1)
>>> > >  		goto out;
>>> > >  
>>> > >  	trace_power_start(POWER_CSTATE, 1, smp_processor_id());
>>> > 
>>> > This does not look right to me. I thought reverting of the serial
>>> > patches should have already solved the issue you're seeing with
>>> > slow serial port?
>>> > 
>>> > Those are the reverting commits drivers/tty/serial/serial-omap.c:
>>> > 
>>> > 8a74e9ffd97dc9de063de8c02ae32db79dd60436 (Revert "tty: serial: OMAP: ensure
>>> > FIFO levels are set correctly in non-DMA mode")
>>> > 
>>> > af681cad3f79ad8f7bd6cb170b70990aeef74233 (Revert "tty: serial: OMAP: transmit
>>> > FIFO threshold interrupts don't wake the chip")
>>> 
>>> These commits have absolutely nothing to do with it.  I pointed out the
>>> bad commit in one of my emails:
>>> 
>>> commit 2fd149645eb46d26130d7070c6de037dddf34880
>>> Author: Govindraj.R <govindraj.raja@ti.com>
>>> Date:   Wed Nov 9 17:41:21 2011 +0530
>>> 
>>>     ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
>>>     
>>>     Omap_uart_can_sleep function blocks system wide low power state until
>>>     uart is active remove this func and add qos requests to prevent
>>>     MPU from transitioning.
>>>     
>>>     Keep qos request to default value which will allow MPU to transition
>>>     and while uart baud rate is available calculate the latency value
>>>     from the baudrate and use the same to hold constraint while uart clocks
>>>     are enabled, and if uart is auto-idled the constraint is updated with
>>>     default constraint value allowing MPU to transition.
>>>     
>>>     Qos requests are blocking notifier calls so put these requests to
>>>     work queue, also the driver uses irq_safe version of runtime API's
>>>     and callbacks can be called in interrupt disabled context.
>>>     So to avoid warn on slow path warning while using qos update
>>>     API's from runtime callbacks use the qos_work_queue.
>>>     
>>>     During bootup the runtime_resume call backs might not be called and runtime
>>>     callback gets called only after uart is idled by setting the autosuspend
>>>     timeout. So qos_request from runtime resume callback might not activated during
>>>     boot if uart baudrate is calculated during bootup for console uart, so schedule
>>>     the qos_work queue once we calc_latency while configuring the uart port.
>>>     
>>>     Flush and complete any pending qos jobs in work queue while suspending.
>>>     
>>>     Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
>>>     Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes)
>>>     Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> 
>>> Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs
>>> while in some of the deeper low power modes.
>>> 
>>> I tried reverting the rest of the patches between this one and HEAD for
>>> omap-serial.c, but they have no effect what so ever on this bug.  As I
>>> said in one of my emails in this thread, the above commit can't be
>>> trivially reverted because some other stuff that the code relied upon
>>> has vanished.
>>> 
>>> So, the above along with the other part in arch/arm/mach-omap2/cpuidle34xx.c
>>> is the smallest 'fix' I could find if resolving the regression.
>>
>> OK, thanks, that should be enough info for let Kevin take a look at this.
>
> This one is indeed strange.  I have not seen this on the 34xx devices
> I'm using (3430/n900, 3530/Overo, 3630/Zoom3).  

OK, I've reproduced this on v3.3-rc2.

The reason I wasn't seeing this is because I'm using the fixes Paul has
already posted that fix this problem:

        http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2

Kevin

Re: OMAP34xx

[Grazvydas Ignotas]

On Wed, Feb 8, 2012 at 2:53 AM, Kevin Hilman <khilman@ti.com> wrote:
> Kevin Hilman <khilman@ti.com> writes:
>
>> Tony Lindgren <tony@atomide.com> writes:
>>
>> [...]
>>
>>>> Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs
>>>> while in some of the deeper low power modes.
>>>>
>>>> I tried reverting the rest of the patches between this one and HEAD for
>>>> omap-serial.c, but they have no effect what so ever on this bug.  As I
>>>> said in one of my emails in this thread, the above commit can't be
>>>> trivially reverted because some other stuff that the code relied upon
>>>> has vanished.
>>>>
>>>> So, the above along with the other part in arch/arm/mach-omap2/cpuidle34xx.c
>>>> is the smallest 'fix' I could find if resolving the regression.
>>>
>>> OK, thanks, that should be enough info for let Kevin take a look at this.
>>
>> This one is indeed strange.  I have not seen this on the 34xx devices
>> I'm using (3430/n900, 3530/Overo, 3630/Zoom3).
>
> OK, I've reproduced this on v3.3-rc2.
>
> The reason I wasn't seeing this is because I'm using the fixes Paul has
> already posted that fix this problem:
>
>        http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2
>
> Kevin

But it looks like these are now queued for 3.4 in tty tree?


-- 
Gražvydas
--
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: OMAP34xx

[Kevin Hilman]

Grazvydas Ignotas <notasas@gmail.com> writes:

> On Wed, Feb 8, 2012 at 2:53 AM, Kevin Hilman <khilman@ti.com> wrote:
>> Kevin Hilman <khilman@ti.com> writes:
>>
>>> This one is indeed strange.  I have not seen this on the 34xx devices
>>> I'm using (3430/n900, 3530/Overo, 3630/Zoom3).
>>
>> OK, I've reproduced this on v3.3-rc2.
>>
>> The reason I wasn't seeing this is because I'm using the fixes Paul has
>> already posted that fix this problem:
>>
>>        http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2
>>
>> Kevin
>
> But it looks like these are now queued for 3.4 in tty tree?

I believe they were targettted for 3.3-rc.

Paul, Greg, can you confirm?

Kevin
--
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: OMAP34xx

[Greg KH]

On Wed, Feb 08, 2012 at 09:01:24AM -0800, Kevin Hilman wrote:
> Grazvydas Ignotas <notasas@gmail.com> writes:
> 
> > On Wed, Feb 8, 2012 at 2:53 AM, Kevin Hilman <khilman@ti.com> wrote:
> >> Kevin Hilman <khilman@ti.com> writes:
> >>
> >>> This one is indeed strange.  I have not seen this on the 34xx devices
> >>> I'm using (3430/n900, 3530/Overo, 3630/Zoom3).
> >>
> >> OK, I've reproduced this on v3.3-rc2.
> >>
> >> The reason I wasn't seeing this is because I'm using the fixes Paul has
> >> already posted that fix this problem:
> >>
> >>        http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2
> >>
> >> Kevin
> >
> > But it looks like these are now queued for 3.4 in tty tree?
> 
> I believe they were targettted for 3.3-rc.
> 
> Paul, Greg, can you confirm?

I have no idea what you are refering to here, please be much more
specific.  You can look at the linux-next tree to answer your question
yourself as well...

greg k-h
--
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: OMAP34xx

[Grazvydas Ignotas]

On Wed, Feb 8, 2012 at 7:06 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Wed, Feb 08, 2012 at 09:01:24AM -0800, Kevin Hilman wrote:
>> Grazvydas Ignotas <notasas@gmail.com> writes:
>>
>> > On Wed, Feb 8, 2012 at 2:53 AM, Kevin Hilman <khilman@ti.com> wrote:
>> >> Kevin Hilman <khilman@ti.com> writes:
>> >>
>> >>> This one is indeed strange.  I have not seen this on the 34xx devices
>> >>> I'm using (3430/n900, 3530/Overo, 3630/Zoom3).
>> >>
>> >> OK, I've reproduced this on v3.3-rc2.
>> >>
>> >> The reason I wasn't seeing this is because I'm using the fixes Paul has
>> >> already posted that fix this problem:
>> >>
>> >>        http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2
>> >>
>> >> Kevin
>> >
>> > But it looks like these are now queued for 3.4 in tty tree?
>>
>> I believe they were targettted for 3.3-rc.
>>
>> Paul, Greg, can you confirm?
>
> I have no idea what you are refering to here, please be much more
> specific.  You can look at the linux-next tree to answer your question
> yourself as well...

It's about these patches in gregkh/tty.git tty-next:
6bbcbf2 tty: serial: omap-serial: wakeup latency constraint is in
microseconds, not milliseconds
edbe5db tty: serial: OMAP: block idle while the UART is transferring
data in PIO mode
5816269 tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode

It would look to me like they are queued for 3.4 but Kevin says there
were intended for 3.3-rc.

-- 
Gražvydas
--
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: OMAP34xx

[Greg KH]

On Wed, Feb 08, 2012 at 07:23:34PM +0200, Grazvydas Ignotas wrote:
> On Wed, Feb 8, 2012 at 7:06 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Wed, Feb 08, 2012 at 09:01:24AM -0800, Kevin Hilman wrote:
> >> Grazvydas Ignotas <notasas@gmail.com> writes:
> >>
> >> > On Wed, Feb 8, 2012 at 2:53 AM, Kevin Hilman <khilman@ti.com> wrote:
> >> >> Kevin Hilman <khilman@ti.com> writes:
> >> >>
> >> >>> This one is indeed strange.  I have not seen this on the 34xx devices
> >> >>> I'm using (3430/n900, 3530/Overo, 3630/Zoom3).
> >> >>
> >> >> OK, I've reproduced this on v3.3-rc2.
> >> >>
> >> >> The reason I wasn't seeing this is because I'm using the fixes Paul has
> >> >> already posted that fix this problem:
> >> >>
> >> >>        http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2
> >> >>
> >> >> Kevin
> >> >
> >> > But it looks like these are now queued for 3.4 in tty tree?
> >>
> >> I believe they were targettted for 3.3-rc.
> >>
> >> Paul, Greg, can you confirm?
> >
> > I have no idea what you are refering to here, please be much more
> > specific.  You can look at the linux-next tree to answer your question
> > yourself as well...
> 
> It's about these patches in gregkh/tty.git tty-next:
> 6bbcbf2 tty: serial: omap-serial: wakeup latency constraint is in
> microseconds, not milliseconds
> edbe5db tty: serial: OMAP: block idle while the UART is transferring
> data in PIO mode
> 5816269 tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode
> 
> It would look to me like they are queued for 3.4 but Kevin says there
> were intended for 3.3-rc.

Kevin might have wished they would go into 3.3, but given that the first
round of these patches had to be reverted, I thought it safer to wait
for 3.4.

thanks,

greg k-h
--
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: OMAP34xx

[Kevin Hilman]

Hi Greg,

Greg KH <gregkh@linuxfoundation.org> writes:

[...]

>> It would look to me like they are queued for 3.4 but Kevin says there
>> were intended for 3.3-rc.
>
> Kevin might have wished they would go into 3.3, but given that the first
> round of these patches had to be reverted, I thought it safer to wait
> for 3.4.

Sorry for the churn on these, but I guess we weren't expecting you to
apply the first before it got some testing/acks.  Sorry about that.

The version you have currently queued is needed for v3.3 as they fix
brokenness on v3.3.  Any chance they can be applied queued for 3.3?
We'll have another set of enhancements on top of those that are
targetted for v3.4, but those you have queued currently are defintely
fixes.

Kevin

Re: OMAP34xx

[Greg KH]

On Wed, Feb 08, 2012 at 03:03:19PM -0800, Kevin Hilman wrote:
> Hi Greg,
> 
> Greg KH <gregkh@linuxfoundation.org> writes:
> 
> [...]
> 
> >> It would look to me like they are queued for 3.4 but Kevin says there
> >> were intended for 3.3-rc.
> >
> > Kevin might have wished they would go into 3.3, but given that the first
> > round of these patches had to be reverted, I thought it safer to wait
> > for 3.4.
> 
> Sorry for the churn on these, but I guess we weren't expecting you to
> apply the first before it got some testing/acks.  Sorry about that.

Don't send me anything, saying it needs to get into the -rc merge
window, that you don't actually want to see merged.  Otherwise, how long
am I supposed to know to wait?  That's just looney.

> The version you have currently queued is needed for v3.3 as they fix
> brokenness on v3.3.  Any chance they can be applied queued for 3.3?
> We'll have another set of enhancements on top of those that are
> targetted for v3.4, but those you have queued currently are defintely
> fixes.

At this point in the release cycle, I would prefer to wait.

But, after they go into Linus's tree for the 3.4-rc1 merge, send the git
commit ids of the patches to stable@vger.kernel.org and they can get
merged to the 3.3.y tree to make things better there.

thanks,

greg k-h

Re: OMAP34xx

[Paul Walmsley]

Hi Greg

was just directed at this thread:

On Wed, 8 Feb 2012, Greg KH wrote:

> Don't send me anything, saying it needs to get into the -rc merge 
> window, that you don't actually want to see merged.  Otherwise, how long 
> am I supposed to know to wait?  That's just looney.

We did want to see it merged.  But then we came up with a better fix, 
which is why I asked you to revert the original in favor of the new 
version:

http://marc.info/?l=linux-arm-kernel&m=132760582332651&w=2

If we'd realized that the second version would be delayed until 3.4, we 
wouldn't have wanted the first version to be reverted :-(

> > The version you have currently queued is needed for v3.3 as they fix
> > brokenness on v3.3.  Any chance they can be applied queued for 3.3?
> > We'll have another set of enhancements on top of those that are
> > targetted for v3.4, but those you have queued currently are defintely
> > fixes.
> 
> At this point in the release cycle, I would prefer to wait.

It would be really great if this series could make it in for v3.3-rcX.  
Without it, 3.3 will be unusable for any OMAP users that run the console 
on the serial port.  That's pretty much every OMAP user that runs mainline 
kernels, AFAIK.


- Paul

Re: OMAP34xx

[Greg KH]

On Wed, Feb 08, 2012 at 05:14:18PM -0700, Paul Walmsley wrote:
> Hi Greg
> 
> was just directed at this thread:
> 
> On Wed, 8 Feb 2012, Greg KH wrote:
> 
> > Don't send me anything, saying it needs to get into the -rc merge 
> > window, that you don't actually want to see merged.  Otherwise, how long 
> > am I supposed to know to wait?  That's just looney.
> 
> We did want to see it merged.  But then we came up with a better fix, 
> which is why I asked you to revert the original in favor of the new 
> version:
> 
> http://marc.info/?l=linux-arm-kernel&m=132760582332651&w=2
> 
> If we'd realized that the second version would be delayed until 3.4, we 
> wouldn't have wanted the first version to be reverted :-(

You said the first version was broken.

Anyway, moving on...

> > > The version you have currently queued is needed for v3.3 as they fix
> > > brokenness on v3.3.  Any chance they can be applied queued for 3.3?
> > > We'll have another set of enhancements on top of those that are
> > > targetted for v3.4, but those you have queued currently are defintely
> > > fixes.
> > 
> > At this point in the release cycle, I would prefer to wait.
> 
> It would be really great if this series could make it in for v3.3-rcX.  
> Without it, 3.3 will be unusable for any OMAP users that run the console 
> on the serial port.  That's pretty much every OMAP user that runs mainline 
> kernels, AFAIK.

Show me an OMAP user that actually runs a mainline kernel :)

What changeset(s) do you want me to take from my tty-next tree and put
it in the tty-linus tree to be merged for the 3.3-final timeframe?

thanks,

greg k-h

Re: OMAP34xx

[Kevin Hilman]

Greg KH <gregkh@linuxfoundation.org> writes:

> What changeset(s) do you want me to take from my tty-next tree and put
> it in the tty-linus tree to be merged for the 3.3-final timeframe?

6bbcbf2 tty: serial: omap-serial: wakeup latency constraint is in microseconds, 
edbe5db tty: serial: OMAP: block idle while the UART is transferring data in PIO
5816269 tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode

Thank you,

Kevin

Re: OMAP34xx

[Greg KH]

On Wed, Feb 08, 2012 at 05:39:28PM -0800, Kevin Hilman wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> 
> > What changeset(s) do you want me to take from my tty-next tree and put
> > it in the tty-linus tree to be merged for the 3.3-final timeframe?
> 
> 6bbcbf2 tty: serial: omap-serial: wakeup latency constraint is in microseconds, 
> edbe5db tty: serial: OMAP: block idle while the UART is transferring data in PIO
> 5816269 tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode

Thanks, but they needed to be applied in backwards order :)

greg k-h

Re: OMAP34xx

[Austin, Brian]

On Feb 8, 2012, at 6:47 PM, "Greg KH" <gregkh@linuxfoundation.org> wrote:

> On Wed, Feb 08, 2012 at 05:14:18PM -0700, Paul Walmsley wrote:
>> Hi Greg
>> 
>> was just directed at this thread:
>> 
>> On Wed, 8 Feb 2012, Greg KH wrote:
>> 
>>> Don't send me anything, saying it needs to get into the -rc merge 
>>> window, that you don't actually want to see merged.  Otherwise, how long 
>>> am I supposed to know to wait?  That's just looney.
>> 
>> We did want to see it merged.  But then we came up with a better fix, 
>> which is why I asked you to revert the original in favor of the new 
>> version:
>> 
>> http://marc.info/?l=linux-arm-kernel&m=132760582332651&w=2
>> 
>> If we'd realized that the second version would be delayed until 3.4, we 
>> wouldn't have wanted the first version to be reverted :-(
> 
> You said the first version was broken.
> 
> Anyway, moving on...
> 
>>>> The version you have currently queued is needed for v3.3 as they fix
>>>> brokenness on v3.3.  Any chance they can be applied queued for 3.3?
>>>> We'll have another set of enhancements on top of those that are
>>>> targetted for v3.4, but those you have queued currently are defintely
>>>> fixes.
>>> 
>>> At this point in the release cycle, I would prefer to wait.
>> 
>> It would be really great if this series could make it in for v3.3-rcX.  
>> Without it, 3.3 will be unusable for any OMAP users that run the console 
>> on the serial port.  That's pretty much every OMAP user that runs mainline 
>> kernels, AFAIK.
> 
> Show me an OMAP user that actually runs a mainline kernel :)
> 
We do for our codec and dsp development and the latest ones have given us fits lately :)

> What changeset(s) do you want me to take from my tty-next tree and put
> it in the tty-linus tree to be merged for the 3.3-final timeframe?
> 
> thanks,
> 
> greg k-h
> --
> 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: OMAP34xx

[Jarkko Nikula]

On 02/09/2012 02:47 AM, Greg KH wrote:
> Show me an OMAP user that actually runs a mainline kernel :)
> 
I guess pretty much all these days? Most error reports what I recall
seeing during past 2-3 years are from mainline kernel and not that much
from linux-omap or some board support package kernel.

-- 
Jarkko

Re: OMAP34xx

[Mark Brown]

On Thu, Feb 09, 2012 at 09:25:36AM +0200, Jarkko Nikula wrote:
> On 02/09/2012 02:47 AM, Greg KH wrote:
> > Show me an OMAP user that actually runs a mainline kernel :)

> I guess pretty much all these days? Most error reports what I recall
> seeing during past 2-3 years are from mainline kernel and not that much
> from linux-omap or some board support package kernel.

Most of the other guys are going in via the TI support channels rather
than asking on the public lists I expect (and remember that even if
people are basing their code on mainline the chances are they've still
got a bunch of out of tree changes on top for their own boards if
they're not directly using one of the reference boards).

Re: OMAP34xx

[Tony Lindgren]

* Mark Brown <broonie@opensource.wolfsonmicro.com> [120209 05:06]:
> On Thu, Feb 09, 2012 at 09:25:36AM +0200, Jarkko Nikula wrote:
> > On 02/09/2012 02:47 AM, Greg KH wrote:
> > > Show me an OMAP user that actually runs a mainline kernel :)
> 
> > I guess pretty much all these days? Most error reports what I recall
> > seeing during past 2-3 years are from mainline kernel and not that much
> > from linux-omap or some board support package kernel.
> 
> Most of the other guys are going in via the TI support channels rather
> than asking on the public lists I expect (and remember that even if
> people are basing their code on mainline the chances are they've still
> got a bunch of out of tree changes on top for their own boards if
> they're not directly using one of the reference boards).

Please everybody using omaps with mainline give a test for the
merge of the various fixes planned. I've done a branch with
v3.3-rc3 + Russell's fixes + Paul's serial port fixes + fixes
that I've queued up.

This fixes the various build and boot issues with custom .configs
that don't select CONFIG_MACH_OMAP_GENERIC. It should fix slow serial
console issues. And it fixes booting with DT to minimal enviroment.

If you still see problems with compiling, booting, or slow serial
port, please post the issues to linux-omap and LAKML lists
immediately.

The testing branch is available at:

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap testing-omap-fixes

For reference, see below what commits this branch contains.

Regards,

Tony


Benoit Cousson (1):
      ARM: OMAP2+: board-generic: Add missing handle_irq callbacks

Igor Grinberg (1):
      ARM: OMAP3: cm-t35: fix section mismatch warning

Paul Walmsley (3):
      tty: serial: omap-serial: wakeup latency constraint is in microseconds, not milliseconds
      tty: serial: OMAP: block idle while the UART is transferring data in PIO mode
      tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode

Russell King - ARM Linux (15):
      ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found
      ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c
      ARM: omap: fix broken twl-core dependencies and ifdefs
      ARM: omap: fix prm44xx.c OMAP44XX_IRQ_PRCM build error
      ARM: omap: fix vc.c PMIC error message
      ARM: omap: fix uninformative vc/i2c configuration error message
      ARM: omap: fix section mismatch errors in TWL PMIC driver
      ARM: omap: fix section mismatch warning in mux.c
      ARM: omap: preemptively fix section mismatch in omap4_sdp4430_wifi_mux_init()
      ARM: omap: fix section mismatch warning for omap_secondary_startup()
      ARM: omap: fix section mismatch error for omap_4430sdp_display_init()
      ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup()
      ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c
      ARM: omap: fix wrapped error messages in omap_hwmod.c
      ARM: omap: resolve nebulous 'Error setting wl12xx data'

Santosh Shilimkar (1):
      ARM: OMAP2: Fix the OMAP2 only build break seen with 2011+ ARM tool-chains

Tony Lindgren (2):
      Merge branch 'fixes-dt' into fixes
      Merge branch 'fixes' into testing-omap-fixes

Re: OMAP34xx

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [120209 10:05]:
> 
> This fixes the various build and boot issues with custom .configs
> that don't select CONFIG_MACH_OMAP_GENERIC. It should fix slow serial
> console issues. And it fixes booting with DT to minimal enviroment.

Looks like the serial console is still insanely slow on 2420 both
for dmesg.

On 2430, 3430, 3630 and 4430 it seems the problem with slow
console is now fixed.

So at least one more patch is needed for the 2420 PM/serial regression.

Regards,

Tony

Re: OMAP34xx

[Paul Walmsley]

On Thu, 9 Feb 2012, Tony Lindgren wrote:

> * Tony Lindgren <tony@atomide.com> [120209 10:05]:
> > 
> > This fixes the various build and boot issues with custom .configs
> > that don't select CONFIG_MACH_OMAP_GENERIC. It should fix slow serial
> > console issues. And it fixes booting with DT to minimal enviroment.
> 
> Looks like the serial console is still insanely slow on 2420 both
> for dmesg.
> 
> On 2430, 3430, 3630 and 4430 it seems the problem with slow
> console is now fixed.
> 
> So at least one more patch is needed for the 2420 PM/serial regression.

Yeah, that one is PM related.  If mach-omap2/pm24xx.c is hacked to only 
enter MPU retention, rather than full chip retention, it works (quick hack 
below).  I suspect it is due to the lack of wakeup support in OMAP2 PM, 
but of course it could be something else.


- Paul

>From 98796ac6423302fdb56afa8a0a262fb09e27a1f6 Mon Sep 17 00:00:00 2001
From: Paul Walmsley <paul@pwsan.com>
Date: Thu, 9 Feb 2012 13:07:49 -0700
Subject: [PATCH] fix 2420 serial

---
 arch/arm/mach-omap2/pm24xx.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index b8822f8..1f959e3 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -245,7 +245,7 @@ static void omap2_pm_idle(void)
 	if (omap_irq_pending())
 		goto out;
 
-	omap2_enter_full_retention();
+	omap2_enter_mpu_retention();
 
 out:
 	local_fiq_enable();
-- 
1.7.9

Re: OMAP34xx

[Paul Walmsley]

On Thu, 9 Feb 2012, Paul Walmsley wrote:

> Yeah, that one is PM related.  If mach-omap2/pm24xx.c is hacked to only 
> enter MPU retention, rather than full chip retention, it works (quick hack 
> below).  I suspect it is due to the lack of wakeup support in OMAP2 PM, 
> but of course it could be something else.

Tony and I tracked this one down to some old pm24xx.c code - patch 
forthcoming shortly.


- Paul

Re: OMAP34xx

[Rex Feany]

Thus spake Tony Lindgren (tony@atomide.com):

> Please everybody using omaps with mainline give a test for the
> merge of the various fixes planned. I've done a branch with
> v3.3-rc3 + Russell's fixes + Paul's serial port fixes + fixes
> that I've queued up.
> 
> If you still see problems with compiling, booting, or slow serial
> port, please post the issues to linux-omap and LAKML lists
> immediately.

With the testing branch, my serial port is still very slow. 
The console is set to 115200, dmesg takes almost a minute to print out.
I'm testing on a beagleboard-xm, which has the DM3730.
(if I change omap2_pm_idle() to never call omap_sram_idle() things improve *a lot*).

config: http://tonya.fnordsoft.com/omap-testing/config
dmesg: http://tonya.fnordsoft.com/omap-testing/testing-dmesg

I also get these warnings when compiling:

  CC      arch/arm/mach-omap2/usb-host.o
arch/arm/mach-omap2/usb-host.c: In function 'usbhs_init':
arch/arm/mach-omap2/usb-host.c:528: warning: assignment from incompatible pointer type

  CC      kernel/trace/trace.o
kernel/trace/trace.c: In function 'tracing_mark_write':
kernel/trace/trace.c:3697: warning: 'page2' may be used uninitialized in this function

  CC      drivers/usb/host/ehci-hcd.o
drivers/usb/host/ehci-hub.c:1079: warning: 'ehci_relinquish_port' defined but not used
drivers/usb/host/ehci-hub.c:1088: warning: 'ehci_port_handed_over' defined but not used

with this gcc:
{rfeany@etalinux:~}(0)$ arm-angstrom-linux-gnueabi-gcc --version
arm-angstrom-linux-gnueabi-gcc (GCC) 4.3.3

take care!
/rex.

Re: OMAP34xx

[Kevin Hilman]

Rex Feany <rfeany@laeos.net> writes:

> Thus spake Tony Lindgren (tony@atomide.com):
>
>> Please everybody using omaps with mainline give a test for the
>> merge of the various fixes planned. I've done a branch with
>> v3.3-rc3 + Russell's fixes + Paul's serial port fixes + fixes
>> that I've queued up.
>> 
>> If you still see problems with compiling, booting, or slow serial
>> port, please post the issues to linux-omap and LAKML lists
>> immediately.
>
> With the testing branch, my serial port is still very slow. 
> The console is set to 115200, dmesg takes almost a minute to print out.
> I'm testing on a beagleboard-xm, which has the DM3730.
> (if I change omap2_pm_idle() to never call omap_sram_idle() things improve *a lot*).
>
> config: http://tonya.fnordsoft.com/omap-testing/config
> dmesg: http://tonya.fnordsoft.com/omap-testing/testing-dmesg

Looking at your config, I see quite a few changes from the default
omap2plus_defconfig.

Also, based on your config and your dmesg output, you're booting a
3.3-rc1 kernel.

Tony's branch is based on -rc3, so I'm a bit confused about what you're
testing.

Can you double check that you're building and booting using Tony's -rc3
based branch?

Also, can you do a test using omap2plus_defconfig?

If it works with omap2plus_defconfig, it would be a great help if you
can slowly enable/diable the config options you care about until it
breaks so we can isolate the problem you're seeing.

Thanks,

Kevin

Re: OMAP34xx

[Rex Feany]

Thus spake Kevin Hilman (khilman@ti.com):

> Can you double check that you're building and booting using Tony's -rc3
> based branch?

I believe so, but I cloned it again anyway and it is different from what
I had originally.

> Also, can you do a test using omap2plus_defconfig?

Of course! Serial seems OK with the defconfig, but it doesn't detect the
network chip (it looks like all of the usb stuff is turned off in the
defconfig). dmesg: http://tonya.fnordsoft.com/omap-testing/dmesg-defconfig

I am trying to get usb & networking working, I tried turning on
ohci/ehci and smsc95xx, but it doesn't seem like anything is detected.
Am I just missing a config option? I will go through this more tomorrow,
becuase I have networking working with my other modified defconfig.

dmesg: http://tonya.fnordsoft.com/omap-testing/dmesg-usb-config
config: http://tonya.fnordsoft.com/omap-testing/usb-config 

 USB_EHCI_HCD n -> m
 USB_NET_SMSC95XX n -> y
 USB_OHCI_HCD n -> m
+MFD_OMAP_USB_HOST y
+USB_EHCI_HCD_OMAP y
+USB_EHCI_MV n
+USB_EHCI_ROOT_HUB_TT n
+USB_EHCI_TT_NEWSCHED y
+USB_OHCI_BIG_ENDIAN_DESC n
+USB_OHCI_BIG_ENDIAN_MMIO n
+USB_OHCI_HCD_OMAP1 y
+USB_OHCI_HCD_OMAP3 y
+USB_OHCI_LITTLE_ENDIAN y
+USB_OTG_UTILS y
+USB_SISUSBVGA n

thanks!!
/rex.

Re: OMAP34xx

[Paul Walmsley]

Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's 
testing branch; it works.


- Paul

RE: OMAP34xx

[Hiremath, Vaibhav]

On Fri, Feb 10, 2012 at 07:49:47, Paul Walmsley wrote:
> 
> Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's 
> testing branch; it works.
> 

I tried it on AM37x EVM, it did worked for me but I have some observations,


1) [root@arago /]# cat /tmp/pm_debug/count
usbhost_pwrdm (ON),OFF:434,RET:466,INA:0,ON:901,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm (ON),OFF:3,RET:2,INA:0,ON:6,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
per_pwrdm (ON),OFF:3,RET:2,INA:0,ON:6,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:434,RET:466,INA:0,ON:901,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:434,RET:466,INA:0,ON:901,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:434,RET:466,INA:0,ON:901,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0


The OFF counter for MPU/NEON/DSS/USB is getting incremented to huge value. Is it expected?
Another observation is, if I include DSS driver into the kernel then I get proper count numbers for dss_pwrdm. (not tried same for usb though)

2) Missing clockdomain in usb clock -

[root@arago /]# dmesg | grep -ir hwmod
[    0.114868] omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck.
...

3)  Not sure how this can be handled, since from TWL regulator output perspective it is NA. I enabled DUMMY_REGILATOR option and tried it, it works.


[root@arago /]# dmesg | grep -ir fail
[    0.166717] dpll3_m2_clk rate change failed: -22
[    0.828521] sharp_ls_panel display0: failed to set lcd brightness
[    1.672454] smsc911x smsc911x.0: Failed to get supply 'vdd33a': -19
...


Thanks,
Vaibhav
> 
> - Paul
> --
> 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: OMAP34xx

[Paul Walmsley]

Hi

On Fri, 10 Feb 2012, Hiremath, Vaibhav wrote:

> On Fri, Feb 10, 2012 at 07:49:47, Paul Walmsley wrote:
> > 
> > Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's 
> > testing branch; it works.
> > 
> 
> I tried it on AM37x EVM, it did worked for me but I have some observations,

What .config are you using?  omap2plus_defconfig?


- Paul

RE: OMAP34xx

[Hiremath, Vaibhav]

On Fri, Feb 10, 2012 at 19:49:57, Paul Walmsley wrote:
> Hi
> 
> On Fri, 10 Feb 2012, Hiremath, Vaibhav wrote:
> 
> > On Fri, Feb 10, 2012 at 07:49:47, Paul Walmsley wrote:
> > > 
> > > Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's 
> > > testing branch; it works.
> > > 
> > 
> > I tried it on AM37x EVM, it did worked for me but I have some observations,
> 
> What .config are you using?  omap2plus_defconfig?
> 
Yes.

Thanks,
Vaibhav

> 
> - Paul
> 

Re: OMAP34xx

[Matt Porter]

On Fri, Feb 10, 2012 at 07:10:06AM +0000, Hiremath, Vaibhav wrote:
> On Fri, Feb 10, 2012 at 07:49:47, Paul Walmsley wrote:
> > 
> > Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's 
> > testing branch; it works.
> > 
> 
> I tried it on AM37x EVM, it did worked for me but I have some observations,

...

> 2) Missing clockdomain in usb clock -
> 
> [root@arago /]# dmesg | grep -ir hwmod
> [    0.114868] omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck.
> ...

I also see this on am37x evm, am35x evm, craneboard, and xM Rev B with an
omap2plus_defconfig build from the testing-omap-fixes branch.

> 3)  Not sure how this can be handled, since from TWL regulator output
> perspective it is NA. I enabled DUMMY_REGILATOR option and tried it,
> it works.
> 
> 
> [root@arago /]# dmesg | grep -ir fail
> [    0.166717] dpll3_m2_clk rate change failed: -22
> [    0.828521] sharp_ls_panel display0: failed to set lcd brightness
> [    1.672454] smsc911x smsc911x.0: Failed to get supply 'vdd33a': -19

I posted a patch to address the smsc911x issue. It's a board specific
fixed regulator that's controlled via a TWL GPIO but defaults to on.

See [PATCH] omap: board-omap3evm: add required smsc911x regulators

-Matt

Re: OMAP34xx

[Matt Porter]

On Thu, Feb 09, 2012 at 07:19:47PM -0700, Paul Walmsley wrote:
> 
> Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's 
> testing branch; it works.

Regarding the issue that Vaibhav reported with:

"omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck"

I also see it on my xM Rev. B. I went back and doublechecked 3.2.5 and
this does not occur there. Enabled EHCI+SMSC95xx support on top of
omap2plus_defconfig and that works fine for nfsroot in 3.2.5.

-Matt

Re: OMAP34xx

[Paul Walmsley]

Hello Matt, Vaibhav,

On Fri, 10 Feb 2012, Matt Porter wrote:

> On Thu, Feb 09, 2012 at 07:19:47PM -0700, Paul Walmsley wrote:
> > 
> > Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's 
> > testing branch; it works.
> 
> Regarding the issue that Vaibhav reported with:
> 
> "omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck"
> 
> I also see it on my xM Rev. B. I went back and doublechecked 3.2.5 and
> this does not occur there. Enabled EHCI+SMSC95xx support on top of
> omap2plus_defconfig and that works fine for nfsroot in 3.2.5.

I was planning to send this for v3.4.  But maybe we should propose it for 
v3.3-rc1?  At this point I am unaware of any regressions directly related 
to the usbtll missing clockdomain, but perhaps someone knows of one?


- Paul


From: Paul Walmsley <paul@pwsan.com>
Date: Thu, 26 Jan 2012 12:19:04 -0700
Subject: [PATCH] ARM: OMAP3: clock data: fill in some missing clockdomains

Several clocks are missing clockdomains.  This can cause problems with
the hwmod and power management code.  Fill these in.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Matt Porter <mporter@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
---
 arch/arm/mach-omap2/clock3xxx_data.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index d75e5f6..5e167d6 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -1392,6 +1392,7 @@ static struct clk cpefuse_fck = {
 	.name		= "cpefuse_fck",
 	.ops		= &clkops_omap2_dflt,
 	.parent		= &sys_ck,
+	.clkdm_name	= "core_l4_clkdm",
 	.enable_reg	= OMAP_CM_REGADDR(CORE_MOD, OMAP3430ES2_CM_FCLKEN3),
 	.enable_bit	= OMAP3430ES2_EN_CPEFUSE_SHIFT,
 	.recalc		= &followparent_recalc,
@@ -1401,6 +1402,7 @@ static struct clk ts_fck = {
 	.name		= "ts_fck",
 	.ops		= &clkops_omap2_dflt,
 	.parent		= &omap_32k_fck,
+	.clkdm_name	= "core_l4_clkdm",
 	.enable_reg	= OMAP_CM_REGADDR(CORE_MOD, OMAP3430ES2_CM_FCLKEN3),
 	.enable_bit	= OMAP3430ES2_EN_TS_SHIFT,
 	.recalc		= &followparent_recalc,
@@ -1410,6 +1412,7 @@ static struct clk usbtll_fck = {
 	.name		= "usbtll_fck",
 	.ops		= &clkops_omap2_dflt_wait,
 	.parent		= &dpll5_m2_ck,
+	.clkdm_name	= "core_l4_clkdm",
 	.enable_reg	= OMAP_CM_REGADDR(CORE_MOD, OMAP3430ES2_CM_FCLKEN3),
 	.enable_bit	= OMAP3430ES2_EN_USBTLL_SHIFT,
 	.recalc		= &followparent_recalc,
@@ -1615,6 +1618,7 @@ static struct clk fshostusb_fck = {
 	.name		= "fshostusb_fck",
 	.ops		= &clkops_omap2_dflt_wait,
 	.parent		= &core_48m_fck,
+	.clkdm_name	= "core_l4_clkdm",
 	.enable_reg	= OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
 	.enable_bit	= OMAP3430ES1_EN_FSHOSTUSB_SHIFT,
 	.recalc		= &followparent_recalc,
@@ -2041,6 +2045,7 @@ static struct clk omapctrl_ick = {
 	.enable_reg	= OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
 	.enable_bit	= OMAP3430_EN_OMAPCTRL_SHIFT,
 	.flags		= ENABLE_ON_INIT,
+	.clkdm_name	= "core_l4_clkdm",
 	.recalc		= &followparent_recalc,
 };
 
@@ -2092,6 +2097,7 @@ static struct clk usb_l4_ick = {
 	.clksel_reg	= OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
 	.clksel_mask	= OMAP3430ES1_CLKSEL_FSHOSTUSB_MASK,
 	.clksel		= usb_l4_clksel,
+	.clkdm_name	= "core_l4_clkdm",
 	.recalc		= &omap2_clksel_recalc,
 };
 
-- 
1.7.9

Re: OMAP34xx

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [120209 17:48]:
> 
> Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's 
> testing branch; it works.

Rex, care to confirm this is also the case for you with
your custom .config?

Regards,

Tony

Re: OMAP34xx

[Rex Feany]

Thus spake Tony Lindgren (tony@atomide.com):

> * Paul Walmsley <paul@pwsan.com> [120209 17:48]:
> > 
> > Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's 
> > testing branch; it works.
> 
> Rex, care to confirm this is also the case for you with
> your custom .config?

Yes, it works. Thanks!

take care!
/rex.

Re: OMAP34xx

[Felipe Balbi]

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

Hi,

On Thu, Feb 09, 2012 at 11:34:42AM -0800, Rex Feany wrote:
> I also get these warnings when compiling:
> 
>   CC      arch/arm/mach-omap2/usb-host.o
> arch/arm/mach-omap2/usb-host.c: In function 'usbhs_init':
> arch/arm/mach-omap2/usb-host.c:528: warning: assignment from incompatible pointer type

yeah, I'll send a patch for that.

>   CC      drivers/usb/host/ehci-hcd.o
> drivers/usb/host/ehci-hub.c:1079: warning: 'ehci_relinquish_port' defined but not used
> drivers/usb/host/ehci-hub.c:1088: warning: 'ehci_port_handed_over' defined but not used

This can't really be "fixed" without some extra trickery. The fact is
that OMAP can't handle port handoff (go figure) and if we use those
functions, we might end up in a situation where USB doesn't work just
because you connected a full speed device.

By not using those functions, we guarantee that the full speed device
won't get enumerated but USB will still be functional after you
disconnect such device.

We could add a bunch of __maybe_unused annotation to all those ehci_*
functions. What do you say Alan ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: OMAP34xx

[Alan Stern]

On Tue, 14 Feb 2012, Felipe Balbi wrote:

> Hi,
> 
> On Thu, Feb 09, 2012 at 11:34:42AM -0800, Rex Feany wrote:
> > I also get these warnings when compiling:
> > 
> >   CC      arch/arm/mach-omap2/usb-host.o
> > arch/arm/mach-omap2/usb-host.c: In function 'usbhs_init':
> > arch/arm/mach-omap2/usb-host.c:528: warning: assignment from incompatible pointer type
> 
> yeah, I'll send a patch for that.
> 
> >   CC      drivers/usb/host/ehci-hcd.o
> > drivers/usb/host/ehci-hub.c:1079: warning: 'ehci_relinquish_port' defined but not used
> > drivers/usb/host/ehci-hub.c:1088: warning: 'ehci_port_handed_over' defined but not used
> 
> This can't really be "fixed" without some extra trickery. The fact is
> that OMAP can't handle port handoff (go figure) and if we use those
> functions, we might end up in a situation where USB doesn't work just
> because you connected a full speed device.
> 
> By not using those functions, we guarantee that the full speed device
> won't get enumerated but USB will still be functional after you
> disconnect such device.
> 
> We could add a bunch of __maybe_unused annotation to all those ehci_*
> functions. What do you say Alan ?

Yes, that makes sense for now.  In the future we'll probably rearrange
things so that the annotations aren't needed, but at the moment this
seems like the best solution.

An alternative would be to add a quirks flag for controllers that don't 
support port handoff.  But that would just create more code for all 
architectures and the end result wouldn't be any better.

Alan Stern

Re: OMAP34xx

[Grazvydas Ignotas]

On Thu, Feb 9, 2012 at 8:36 PM, Tony Lindgren <tony@atomide.com> wrote:
> Please everybody using omaps with mainline give a test for the
> merge of the various fixes planned. I've done a branch with
> v3.3-rc3 + Russell's fixes + Paul's serial port fixes + fixes
> that I've queued up.

Seems to be good on pandora with omap2plus_defconfig, only one section mismatch:

WARNING: vmlinux.o(.text+0x22b64): Section mismatch in reference from
the function omap4_hotplug_cpu() to the function
.cpuinit.text:omap_secondary_startup()
The function omap4_hotplug_cpu() references the function __cpuinit
omap_secondary_startup().
This is often because omap4_hotplug_cpu lacks a __cpuinit annotation
or the annotation of omap_secondary_startup is wrong.



-- 
Gražvydas
--
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: OMAP34xx

[Russell King - ARM Linux]

On Fri, Feb 10, 2012 at 01:53:12PM +0200, Grazvydas Ignotas wrote:
> On Thu, Feb 9, 2012 at 8:36 PM, Tony Lindgren <tony@atomide.com> wrote:
> > Please everybody using omaps with mainline give a test for the
> > merge of the various fixes planned. I've done a branch with
> > v3.3-rc3 + Russell's fixes + Paul's serial port fixes + fixes
> > that I've queued up.
> 
> Seems to be good on pandora with omap2plus_defconfig, only one section mismatch:
> 
> WARNING: vmlinux.o(.text+0x22b64): Section mismatch in reference from
> the function omap4_hotplug_cpu() to the function
> .cpuinit.text:omap_secondary_startup()
> The function omap4_hotplug_cpu() references the function __cpuinit
> omap_secondary_startup().
> This is often because omap4_hotplug_cpu lacks a __cpuinit annotation
> or the annotation of omap_secondary_startup is wrong.

That's expected at the moment, and is something that shouldn't be solved
by changing omap_secondary_startup().

However, omap4_hotplug_cpu() and platform_cpu_die() are both things which
run when the CPU is being unplugged, so they should logically be __cpuexit.
However, we would end up with __cpuexit code referencing __cpuinit code,
which will also emit a warning.

So, just like Versatile Express et.al. we persist with the section mismatch
warning being emitted for these platforms, because the reference there is
entirely valid for this code.

Unfortunately, there's no way to place omap4_hotplug_cpu() into the
__cpuexit section and mark it as validly referencing __cpuinit code.
(iow, __ref doesn't work for that.)

Re: OMAP34xx

[Luciano Coelho]

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

Hi Tony,

On Thu, 2012-02-09 at 10:36 -0800, Tony Lindgren wrote: 
> * Mark Brown <broonie@opensource.wolfsonmicro.com> [120209 05:06]:
> > On Thu, Feb 09, 2012 at 09:25:36AM +0200, Jarkko Nikula wrote:
> > > On 02/09/2012 02:47 AM, Greg KH wrote:
> > > > Show me an OMAP user that actually runs a mainline kernel :)
> > 
> > > I guess pretty much all these days? Most error reports what I recall
> > > seeing during past 2-3 years are from mainline kernel and not that much
> > > from linux-omap or some board support package kernel.
> > 
> > Most of the other guys are going in via the TI support channels rather
> > than asking on the public lists I expect (and remember that even if
> > people are basing their code on mainline the chances are they've still
> > got a bunch of out of tree changes on top for their own boards if
> > they're not directly using one of the reference boards).
> 
> Please everybody using omaps with mainline give a test for the
> merge of the various fixes planned. I've done a branch with
> v3.3-rc3 + Russell's fixes + Paul's serial port fixes + fixes
> that I've queued up.
> 
> This fixes the various build and boot issues with custom .configs
> that don't select CONFIG_MACH_OMAP_GENERIC. It should fix slow serial
> console issues. And it fixes booting with DT to minimal enviroment.
> 
> If you still see problems with compiling, booting, or slow serial
> port, please post the issues to linux-omap and LAKML lists
> immediately.
> 
> The testing branch is available at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap testing-omap-fixes

I just tried this on my Panda and I keep getting this kind of BUGs.  It
spams my console so much that is pretty much unusable:

[  336.172302] BUG: sleeping function called from invalid context at include/linux/freezer.h:46                         
[  336.181213] in_atomic(): 0, irqs_disabled(): 128, pid: 1618, name: ntpd                                              
[  336.181213] INFO: lockdep is turned off.                                                                             
[  336.181213] irq event stamp: 0                                                                                       
[  336.181213] hardirqs last  enabled at (0): [<  (null)>]   (null)                                                     
[  336.201660] hardirqs last disabled at (0): [<c0042314>] copy_process+0x3ec/0x105c                                    
[  336.209625] softirqs last  enabled at (0): [<c0042314>] copy_process+0x3ec/0x105c                                    
[  336.217498] softirqs last disabled at (0): [<  (null)>]   (null)                                                     
[  336.217498] [<c001e1e4>] (unwind_backtrace+0x0/0x148) from [<c0502c24>] (dump_stack+0x20/0x24)                       
[  336.232879] [<c0502c24>] (dump_stack+0x20/0x24) from [<c0077998>] (__might_sleep+0x130/0x134)                        
[  336.232879] [<c0077998>] (__might_sleep+0x130/0x134) from [<c0018998>] (do_signal+0x54/0x600)                        
[  336.250793] [<c0018998>] (do_signal+0x54/0x600) from [<c0018fa4>] (do_notify_resume+0x60/0x6c)                       
[  336.250793] [<c0018fa4>] (do_notify_resume+0x60/0x6c) from [<c00154e4>] (work_pending+0x24/0x28)                     

I have also seen this in 3.3-rc3 (both on Panda (OMAP4460) and on Blaze
(OMAP4430) boards) and I was hoping your tree would have the fix for it,
but it doesn't. :( The device boots and seems to work otherwise, but
this is annoying and looks shaky.

I saw something related to this in another thread from a few months ago,
and one patch proposal by Russell, but I didn't find any conclusion or
any related patch queued up for upstream.

Is there any solution for this? I use a tuned .config (attached) and not
the one generated by omap2plus_defconfig (which I didn't try as
vanilla).

-- 
Cheers,
Luca.

[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 62869 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.3.0-rc2 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_SCHED_CLOCK=y
CONFIG_GENERIC_GPIO=y
# CONFIG_ARCH_USES_GETTIMEOFFSET is not set
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_KTIME_SCALAR=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_FHANDLE is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_SPARSE_IRQ is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=32
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_PERF_COUNTERS is not set
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
# CONFIG_INLINE_SPIN_UNLOCK is not set
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
# CONFIG_INLINE_READ_UNLOCK is not set
# CONFIG_INLINE_READ_UNLOCK_BH is not set
# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
# CONFIG_INLINE_WRITE_UNLOCK is not set
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_VEXPRESS is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_BCMRING is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_PRIMA2 is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_MXC is not set
# CONFIG_ARCH_MXS is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_PICOXCELL is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_ARCH_DAVINCI is not set
CONFIG_ARCH_OMAP=y
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_VT8500 is not set
# CONFIG_ARCH_ZYNQ is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set

#
# TI OMAP Common Features
#
# CONFIG_ARCH_OMAP1 is not set
CONFIG_ARCH_OMAP2PLUS=y

#
# OMAP Feature Selections
#
# CONFIG_OMAP_SMARTREFLEX is not set
CONFIG_OMAP_RESET_CLOCKS=y
CONFIG_OMAP_MUX=y
CONFIG_OMAP_MUX_DEBUG=y
CONFIG_OMAP_MUX_WARNINGS=y
CONFIG_OMAP_MCBSP=y
# CONFIG_OMAP_MBOX_FWK is not set
CONFIG_OMAP_32K_TIMER=y
CONFIG_OMAP_32K_TIMER_HZ=128
CONFIG_OMAP_DM_TIMER=y
CONFIG_OMAP_PM_NOOP=y
# CONFIG_MACH_OMAP_GENERIC is not set

#
# TI OMAP2/3/4 Specific Features
#
CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
# CONFIG_ARCH_OMAP2 is not set
# CONFIG_ARCH_OMAP3 is not set
CONFIG_ARCH_OMAP4=y
CONFIG_OMAP_PACKAGE_CBL=y
CONFIG_OMAP_PACKAGE_CBS=y

#
# OMAP Board Type
#
CONFIG_MACH_OMAP_4430SDP=y
CONFIG_MACH_OMAP4_PANDA=y

#
# System MMU
#

#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
CONFIG_ARM_THUMBEE=y
# CONFIG_SWP_EMULATE is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_CACHE_L2X0=y
CONFIG_CACHE_PL310=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_CPU_HAS_PMU=y
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
# CONFIG_ARM_ERRATA_458693 is not set
# CONFIG_ARM_ERRATA_460075 is not set
# CONFIG_ARM_ERRATA_742230 is not set
# CONFIG_ARM_ERRATA_742231 is not set
CONFIG_PL310_ERRATA_588369=y
CONFIG_ARM_ERRATA_720789=y
CONFIG_PL310_ERRATA_727915=y
# CONFIG_ARM_ERRATA_743622 is not set
# CONFIG_ARM_ERRATA_751472 is not set
# CONFIG_PL310_ERRATA_753970 is not set
# CONFIG_ARM_ERRATA_754322 is not set
# CONFIG_ARM_ERRATA_754327 is not set
# CONFIG_ARM_ERRATA_764369 is not set
# CONFIG_PL310_ERRATA_769419 is not set
CONFIG_ARM_GIC=y

#
# Bus support
#
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_HAVE_SMP=y
CONFIG_SMP=y
CONFIG_SMP_ON_UP=y
CONFIG_ARM_CPU_TOPOLOGY=y
# CONFIG_SCHED_MC is not set
# CONFIG_SCHED_SMT is not set
CONFIG_HAVE_ARM_SCU=y
CONFIG_HAVE_ARM_TWD=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_NR_CPUS=2
CONFIG_HOTPLUG_CPU=y
CONFIG_LOCAL_TIMERS=y
CONFIG_ARCH_NR_GPIO=0
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_COUNT=y
CONFIG_HZ=128
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
# CONFIG_HIGHMEM is not set
CONFIG_HW_PERF_EVENTS=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
# CONFIG_COMPACTION is not set
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
# CONFIG_CLEANCACHE is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_LEDS=y
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_DEPRECATED_PARAM_STRUCT is not set

#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
# CONFIG_ARM_APPENDED_DTB is not set
CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
# CONFIG_XIP_KERNEL is not set
CONFIG_KEXEC=y
CONFIG_ATAGS_PROC=y
# CONFIG_CRASH_DUMP is not set
# CONFIG_AUTO_ZRELADDR is not set

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_CAN_PM_TRACE=y
# CONFIG_APM_EMULATION is not set
CONFIG_ARCH_HAS_OPP=y
CONFIG_PM_OPP=y
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_XFRM_MIGRATE=y
# CONFIG_XFRM_STATISTICS is not set
CONFIG_NET_KEY=y
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_ACCT is not set
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NETFILTER_XTABLES is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV4 is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
CONFIG_BQL=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_CFG80211=m
CONFIG_NL80211_TESTMODE=y
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
CONFIG_CFG80211_WEXT=y
# CONFIG_WIRELESS_EXT_SYSFS is not set
CONFIG_LIB80211=m
# CONFIG_LIB80211_DEBUG is not set
CONFIG_MAC80211=m
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
CONFIG_MAC80211_RC_DEFAULT_PID=y
# CONFIG_MAC80211_RC_DEFAULT_MINSTREL is not set
CONFIG_MAC80211_RC_DEFAULT="pid"
# CONFIG_MAC80211_MESH is not set
CONFIG_MAC80211_DEBUGFS=y
CONFIG_MAC80211_DEBUG_MENU=y
# CONFIG_MAC80211_NOINLINE is not set
# CONFIG_MAC80211_VERBOSE_DEBUG is not set
# CONFIG_MAC80211_HT_DEBUG is not set
# CONFIG_MAC80211_TKIP_DEBUG is not set
# CONFIG_MAC80211_IBSS_DEBUG is not set
# CONFIG_MAC80211_VERBOSE_PS_DEBUG is not set
# CONFIG_MAC80211_VERBOSE_TDLS_DEBUG is not set
# CONFIG_MAC80211_DEBUG_COUNTERS is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=m
CONFIG_RFKILL_INPUT=y
CONFIG_RFKILL_REGULATOR=m
CONFIG_RFKILL_GPIO=m
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
# CONFIG_DMA_SHARED_BUFFER is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=y
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
# CONFIG_MTD_OF_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
CONFIG_MTD_OOPS=y
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PHYSMAP_OF is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SST25L is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_DOCG3 is not set
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
# CONFIG_MTD_NAND_GPIO is not set
# CONFIG_MTD_NAND_OMAP2 is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ALAUDA is not set
CONFIG_MTD_ONENAND=y
CONFIG_MTD_ONENAND_VERIFY_WRITE=y
# CONFIG_MTD_ONENAND_GENERIC is not set
# CONFIG_MTD_ONENAND_OTP is not set
# CONFIG_MTD_ONENAND_2X_PROGRAM is not set
# CONFIG_MTD_ONENAND_SIM is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
# CONFIG_MTD_UBI_GLUEBI is not set
# CONFIG_MTD_UBI_DEBUG is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
# CONFIG_PROC_DEVICETREE is not set
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_GPIO=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_SPI=y
CONFIG_OF_MDIO=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_SENSORS_LIS3LV02D is not set
CONFIG_MISC_DEVICES=y
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
# CONFIG_BMP085 is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
CONFIG_EEPROM_93CX6=y
# CONFIG_EEPROM_93XX46 is not set
# CONFIG_IWMC3200TOP is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
CONFIG_SCSI_MULTI_LUN=y
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
# CONFIG_ATA is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BLK_DEV_DM is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set

#
# CAIF transport drivers
#
CONFIG_ETHERNET=y
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_FARADAY=y
# CONFIG_FTMAC100 is not set
# CONFIG_FTGMAC100 is not set
CONFIG_NET_VENDOR_INTEL=y
CONFIG_NET_VENDOR_I825XX=y
CONFIG_NET_VENDOR_MARVELL=y
CONFIG_NET_VENDOR_MICREL=y
CONFIG_KS8851=y
CONFIG_KS8851_MLL=y
CONFIG_NET_VENDOR_MICROCHIP=y
# CONFIG_ENC28J60 is not set
CONFIG_NET_VENDOR_NATSEMI=y
CONFIG_NET_VENDOR_8390=y
# CONFIG_AX88796 is not set
# CONFIG_ETHOC is not set
CONFIG_NET_VENDOR_SEEQ=y
# CONFIG_SEEQ8005 is not set
CONFIG_NET_VENDOR_SMSC=y
CONFIG_SMC91X=y
# CONFIG_SMC911X is not set
CONFIG_SMSC911X=y
# CONFIG_SMSC911X_ARCH_HOOKS is not set
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
CONFIG_SMSC_PHY=y
# CONFIG_BROADCOM_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=y
CONFIG_USB_NET_AX8817X=y
CONFIG_USB_NET_CDCETHER=y
CONFIG_USB_NET_CDC_EEM=y
CONFIG_USB_NET_CDC_NCM=y
CONFIG_USB_NET_DM9601=y
CONFIG_USB_NET_SMSC75XX=y
CONFIG_USB_NET_SMSC95XX=y
CONFIG_USB_NET_GL620A=y
CONFIG_USB_NET_NET1080=y
CONFIG_USB_NET_PLUSB=y
CONFIG_USB_NET_MCS7830=y
CONFIG_USB_NET_RNDIS_HOST=y
CONFIG_USB_NET_CDC_SUBSET=y
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
CONFIG_USB_NET_ZAURUS=y
CONFIG_USB_NET_CX82310_ETH=y
# CONFIG_USB_NET_KALMIA is not set
# CONFIG_USB_HSO is not set
CONFIG_USB_NET_INT51X1=y
CONFIG_USB_IPHETH=y
CONFIG_USB_SIERRA_NET=y
# CONFIG_USB_VL600 is not set
CONFIG_WLAN=y
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8187 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_ATH_COMMON is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_BRCMFMAC is not set
# CONFIG_HOSTAP is not set
# CONFIG_IWM is not set
# CONFIG_LIBERTAS is not set
# CONFIG_P54_COMMON is not set
# CONFIG_RT2X00 is not set
# CONFIG_RTL8192CU is not set
CONFIG_WL1251=m
CONFIG_WL1251_SPI=m
CONFIG_WL1251_SDIO=m
CONFIG_WL12XX_MENU=m
CONFIG_WL12XX=m
CONFIG_WL12XX_SPI=m
CONFIG_WL12XX_SDIO=m
CONFIG_WL12XX_PLATFORM_DATA=y
# CONFIG_ZD1211RW is not set
# CONFIG_MWIFIEX is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_GPIO=y
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_OMAP4 is not set
CONFIG_KEYBOARD_TWL4030=y
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_GPIO is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ADS7846=y
# CONFIG_TOUCHSCREEN_AD7877 is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_EGALAX is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_PIXCIR is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2005 is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_W90X900 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_MPU3050 is not set
# CONFIG_INPUT_GP2A is not set
# CONFIG_INPUT_GPIO_TILT_POLLED is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_KXTJ9 is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
CONFIG_INPUT_TWL4030_PWRBUTTON=y
# CONFIG_INPUT_TWL4030_VIBRA is not set
# CONFIG_INPUT_TWL6040_VIBRA is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_PCF8574 is not set
# CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_CMA3000 is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_DW is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX3107 is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_OF_PLATFORM is not set
CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_RAMOOPS is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_OMAP=y
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_OC_TINY is not set
CONFIG_SPI_OMAP24XX=y
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#

#
# Enable Device Drivers -> PPS to see the PTP clock options.
#
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
CONFIG_GPIO_TWL4030=y
# CONFIG_GPIO_ADP5588 is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#
CONFIG_W1=y
CONFIG_W1_CON=y

#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_DS2490 is not set
# CONFIG_W1_MASTER_DS2482 is not set
# CONFIG_W1_MASTER_DS1WM is not set
# CONFIG_W1_MASTER_GPIO is not set

#
# 1-wire Slaves
#
# CONFIG_W1_SLAVE_THERM is not set
# CONFIG_W1_SLAVE_SMEM is not set
# CONFIG_W1_SLAVE_DS2408 is not set
# CONFIG_W1_SLAVE_DS2423 is not set
# CONFIG_W1_SLAVE_DS2431 is not set
# CONFIG_W1_SLAVE_DS2433 is not set
# CONFIG_W1_SLAVE_DS2760 is not set
# CONFIG_W1_SLAVE_DS2780 is not set
# CONFIG_W1_SLAVE_BQ27000 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_ISP1704 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_TWL4030 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_GPIO is not set
# CONFIG_CHARGER_MANAGER is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_AD7314 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADCXX is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7411 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS620 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_GPIO_FAN is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_LINEAGE is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM70 is not set
# CONFIG_SENSORS_LM73 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_MAX1111 is not set
# CONFIG_SENSORS_MAX16065 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX1668 is not set
# CONFIG_SENSORS_MAX6639 is not set
# CONFIG_SENSORS_MAX6642 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_NTC_THERMISTOR is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_PMBUS is not set
# CONFIG_SENSORS_SHT15 is not set
# CONFIG_SENSORS_SHT21 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH56XX_COMMON is not set
# CONFIG_SENSORS_SCH5627 is not set
# CONFIG_SENSORS_SCH5636 is not set
# CONFIG_SENSORS_ADS1015 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_ADS7871 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_CORE is not set
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_MPCORE_WATCHDOG is not set
CONFIG_OMAP_WATCHDOG=y
CONFIG_TWL4030_WATCHDOG=y
# CONFIG_MAX63XX_WATCHDOG is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
CONFIG_TWL4030_CORE=y
# CONFIG_TWL4030_MADC is not set
CONFIG_TWL4030_POWER=y
# CONFIG_MFD_TWL4030_AUDIO is not set
# CONFIG_TWL6030_PWM is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_S5M_CORE is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_WL1273_CORE is not set
CONFIG_MFD_OMAP_USB_HOST=y
# CONFIG_MFD_AAT2870_CORE is not set
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
# CONFIG_REGULATOR_DUMMY is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_BQ24022 is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
CONFIG_REGULATOR_TWL4030=y
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_AD5398 is not set
# CONFIG_REGULATOR_TPS6524X is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
# CONFIG_FB_CFB_FILLRECT is not set
# CONFIG_FB_CFB_COPYAREA is not set
# CONFIG_FB_CFB_IMAGEBLIT is not set
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_WMT_GE_ROPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
# CONFIG_FB_UVESA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_OMAP2_DSS is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
# CONFIG_LCD_L4F00242T03 is not set
# CONFIG_LCD_LMS283GF05 is not set
# CONFIG_LCD_LTV350QV is not set
# CONFIG_LCD_TDO24M is not set
# CONFIG_LCD_VGG2432A4 is not set
CONFIG_LCD_PLATFORM=y
# CONFIG_LCD_S6E63M0 is not set
# CONFIG_LCD_LD9040 is not set
# CONFIG_LCD_AMS369FG06 is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HID_BATTERY_STRENGTH=y
# CONFIG_HIDRAW is not set

#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_USB_ARCH_HAS_XHCI is not set
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_DWC3 is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_HCD_OMAP=y
# CONFIG_USB_EHCI_MV is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HWA_HCD is not set
# CONFIG_USB_MUSB_HDRC is not set
# CONFIG_USB_RENESAS_USBHS is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
CONFIG_USB_WDM=y
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_REALTEK is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_STORAGE_ENE_UB6250 is not set
# CONFIG_USB_UAS is not set
CONFIG_USB_LIBUSUAL=y

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=y
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_DEBUG=y
CONFIG_USB_GADGET_DEBUG_FILES=y
CONFIG_USB_GADGET_DEBUG_FS=y
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
# CONFIG_USB_FUSB300 is not set
CONFIG_USB_OMAP=y
# CONFIG_USB_R8A66597 is not set
# CONFIG_USB_MV_UDC is not set
# CONFIG_USB_M66592 is not set
# CONFIG_USB_NET2272 is not set
# CONFIG_USB_DUMMY_HCD is not set
CONFIG_USB_ZERO=m
# CONFIG_USB_ETH is not set
# CONFIG_USB_G_NCM is not set
# CONFIG_USB_GADGETFS is not set
# CONFIG_USB_FUNCTIONFS is not set
# CONFIG_USB_FILE_STORAGE is not set
# CONFIG_USB_MASS_STORAGE is not set
# CONFIG_USB_G_SERIAL is not set
# CONFIG_USB_G_PRINTER is not set
# CONFIG_USB_CDC_COMPOSITE is not set
# CONFIG_USB_G_ACM_MS is not set
# CONFIG_USB_G_MULTI is not set
# CONFIG_USB_G_HID is not set
# CONFIG_USB_G_DBGP is not set

#
# OTG and related infrastructure
#
CONFIG_USB_OTG_UTILS=y
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_USB_ULPI is not set
CONFIG_TWL4030_USB=y
CONFIG_TWL6030_USB=y
# CONFIG_NOP_USB_XCEIV is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_UNSAFE_RESUME=y
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_SDIO_UART=y
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
# CONFIG_MMC_SPI is not set
# CONFIG_MMC_DW is not set
# CONFIG_MMC_VUB300 is not set
# CONFIG_MMC_USHC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
CONFIG_RTC_DRV_TWL4030=y
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_BALLOON is not set
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y

#
# Hardware Spinlock drivers
#
# CONFIG_HWSPINLOCK_OMAP is not set
CONFIG_CLKSRC_MMIO=y
CONFIG_IOMMU_SUPPORT=y
# CONFIG_OMAP_IOMMU is not set
# CONFIG_VIRT_DRIVERS is not set
# CONFIG_PM_DEVFREQ is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
# CONFIG_EXT3_FS_XATTR is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_PRINT_QUOTA_WARNING=y
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
CONFIG_JFFS2_SUMMARY=y
CONFIG_JFFS2_FS_XATTR=y
CONFIG_JFFS2_FS_POSIX_ACL=y
CONFIG_JFFS2_FS_SECURITY=y
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_LZO=y
CONFIG_JFFS2_RTIME=y
CONFIG_JFFS2_RUBIN=y
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=y
# CONFIG_JFFS2_CMODE_SIZE is not set
# CONFIG_JFFS2_CMODE_FAVOURLZO is not set
CONFIG_UBIFS_FS=y
# CONFIG_UBIFS_FS_XATTR is not set
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
# CONFIG_UBIFS_FS_DEBUG is not set
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
# CONFIG_NFS_USE_NEW_IDMAPPER is not set
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOCKUP_DETECTOR=y
# CONFIG_HARDLOCKUP_DETECTOR is not set
# CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_KMEMLEAK is not set
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
# CONFIG_PROVE_RCU is not set
# CONFIG_SPARSE_RCU_POINTER is not set
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=60
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_LKDTM is not set
# CONFIG_CPU_NOTIFIER_ERROR_INJECT is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_EVENT_POWER_TRACING_DEPRECATED=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_KPROBE_EVENT=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
CONFIG_DYNAMIC_DEBUG=y
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
CONFIG_OLD_MCOUNT=y
# CONFIG_DEBUG_USER is not set
# CONFIG_DEBUG_LL is not set
# CONFIG_ARM_KPROBES_TEST is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_ENCRYPTED_KEYS is not set
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_NETWORK is not set
# CONFIG_SECURITY_PATH is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_IMA is not set
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
# CONFIG_CRYPTO_MANAGER is not set
# CONFIG_CRYPTO_MANAGER2 is not set
# CONFIG_CRYPTO_USER is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_PCRYPT is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
CONFIG_CRC7=y
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set

Re: OMAP34xx

[Kevin Hilman]

Luciano Coelho <coelho@ti.com> writes:

[...]

> I just tried this on my Panda and I keep getting this kind of BUGs.  It
> spams my console so much that is pretty much unusable:
>
> [  336.172302] BUG: sleeping function called from invalid context at include/linux/freezer.h:46                         
> [  336.181213] in_atomic(): 0, irqs_disabled(): 128, pid: 1618, name: ntpd                                              
> [  336.181213] INFO: lockdep is turned off.                                                                             
> [  336.181213] irq event stamp: 0                                                                                       
> [  336.181213] hardirqs last  enabled at (0): [<  (null)>]   (null)                                                     
> [  336.201660] hardirqs last disabled at (0): [<c0042314>] copy_process+0x3ec/0x105c                                    
> [  336.209625] softirqs last  enabled at (0): [<c0042314>] copy_process+0x3ec/0x105c                                    
> [  336.217498] softirqs last disabled at (0): [<  (null)>]   (null)                                                     
> [  336.217498] [<c001e1e4>] (unwind_backtrace+0x0/0x148) from [<c0502c24>] (dump_stack+0x20/0x24)                       
> [  336.232879] [<c0502c24>] (dump_stack+0x20/0x24) from [<c0077998>] (__might_sleep+0x130/0x134)                        
> [  336.232879] [<c0077998>] (__might_sleep+0x130/0x134) from [<c0018998>] (do_signal+0x54/0x600)                        
> [  336.250793] [<c0018998>] (do_signal+0x54/0x600) from [<c0018fa4>] (do_notify_resume+0x60/0x6c)                       
> [  336.250793] [<c0018fa4>] (do_notify_resume+0x60/0x6c) from [<c00154e4>] (work_pending+0x24/0x28)                     
>
> I have also seen this in 3.3-rc3 (both on Panda (OMAP4460) and on Blaze
> (OMAP4430) boards) and I was hoping your tree would have the fix for it,
> but it doesn't. :( The device boots and seems to work otherwise, but
> this is annoying and looks shaky.
>
> I saw something related to this in another thread from a few months ago,
> and one patch proposal by Russell, but I didn't find any conclusion or
> any related patch queued up for upstream.
>
> Is there any solution for this? I use a tuned .config (attached) and not
> the one generated by omap2plus_defconfig (which I didn't try as
> vanilla).

I see the same thing with your ~/.config, but I don't think this is OMAP
specific.  I suspect this will happen on any ARM platform that  has
CONFIG_DEBUG_ATOMIC_SLEEP=y.

It appears to be a problem with the recently added audit support for
ARM, since reverting the commit below makes this BUG go away.

Based on the BUG you're seeing, there appears to be a missing IRQ
(re)enable in the syscall path with this new audit support, but I did
not dig further, since it seems Russell is planning to revert this patch
anyways due to other problems.

Kevin

commit 29ef73b7a823b77a7cd0bdd7d7cded3fb6c2587b
Author: Nathaniel Husted <nhusted@gmail.com>
Date:   Tue Jan 3 14:23:09 2012 -0500

    Kernel: Audit Support For The ARM Platform
    
    This patch provides functionality to audit system call events on the
    ARM platform. The implementation was based off the structure of the
    MIPS platform and information in this
    (http://lists.fedoraproject.org/pipermail/arm/2009-October/000382.html)
    mailing list thread. The required audit_syscall_exit and
    audit_syscall_entry checks were added to ptrace using the standard
    registers for system call values (r0 through r3). A thread information
    flag was added for auditing (TIF_SYSCALL_AUDIT) and a meta-flag was
    added (_TIF_SYSCALL_WORK) to simplify modifications to the syscall
    entry/exit. Now, if either the TRACE flag is set or the AUDIT flag is
    set, the syscall_trace function will be executed. The prober changes
    were made to Kconfig to allow CONFIG_AUDITSYSCALL to be enabled.
    
    Due to platform availability limitations, this patch was only tested
    on the Android platform running the modified "android-goldfish-2.6.29"
    kernel. A test compile was performed using Code Sourcery's
    cross-compilation toolset and the current linux-3.0 stable kernel. The
    changes compile without error. I'm hoping, due to the simple modifications,
    the patch is "obviously correct".
    
    Signed-off-by: Nathaniel Husted <nhusted@gmail.com>
    Signed-off-by: Eric Paris <eparis@redhat.com>

Re: OMAP34xx

[Kevin Hilman]

On 02/15/2012 03:54 PM, Kevin Hilman wrote:
> Luciano Coelho<coelho@ti.com>  writes:
>
> [...]
>
>> I just tried this on my Panda and I keep getting this kind of BUGs.  It
>> spams my console so much that is pretty much unusable:
>>
>> [  336.172302] BUG: sleeping function called from invalid context at include/linux/freezer.h:46
>> [  336.181213] in_atomic(): 0, irqs_disabled(): 128, pid: 1618, name: ntpd
>> [  336.181213] INFO: lockdep is turned off.
>> [  336.181213] irq event stamp: 0
>> [  336.181213] hardirqs last  enabled at (0): [<   (null)>]   (null)
>> [  336.201660] hardirqs last disabled at (0): [<c0042314>] copy_process+0x3ec/0x105c
>> [  336.209625] softirqs last  enabled at (0): [<c0042314>] copy_process+0x3ec/0x105c
>> [  336.217498] softirqs last disabled at (0): [<   (null)>]   (null)
>> [  336.217498] [<c001e1e4>] (unwind_backtrace+0x0/0x148) from [<c0502c24>] (dump_stack+0x20/0x24)
>> [  336.232879] [<c0502c24>] (dump_stack+0x20/0x24) from [<c0077998>] (__might_sleep+0x130/0x134)
>> [  336.232879] [<c0077998>] (__might_sleep+0x130/0x134) from [<c0018998>] (do_signal+0x54/0x600)
>> [  336.250793] [<c0018998>] (do_signal+0x54/0x600) from [<c0018fa4>] (do_notify_resume+0x60/0x6c)
>> [  336.250793] [<c0018fa4>] (do_notify_resume+0x60/0x6c) from [<c00154e4>] (work_pending+0x24/0x28)
>>
>> I have also seen this in 3.3-rc3 (both on Panda (OMAP4460) and on Blaze
>> (OMAP4430) boards) and I was hoping your tree would have the fix for it,
>> but it doesn't. :( The device boots and seems to work otherwise, but
>> this is annoying and looks shaky.
>>
>> I saw something related to this in another thread from a few months ago,
>> and one patch proposal by Russell, but I didn't find any conclusion or
>> any related patch queued up for upstream.
>>
>> Is there any solution for this? I use a tuned .config (attached) and not
>> the one generated by omap2plus_defconfig (which I didn't try as
>> vanilla).
>
> I see the same thing with your ~/.config, but I don't think this is OMAP
> specific.  I suspect this will happen on any ARM platform that  has
> CONFIG_DEBUG_ATOMIC_SLEEP=y.
>
> It appears to be a problem with the recently added audit support for
> ARM, since reverting the commit below makes this BUG go away.

False alarm.  reverting the audit commit didn't make the problem go 
away.  It was gone only because I also disabled 
CONFIG_DEBUG_ATOMIC_SLEEP.  :/

To debug this further, you might bisect it back to v3.2 because the 
problem isn't there in v3.2

Kevin

Re: OMAP34xx

[NeilBrown]

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

On Wed, 15 Feb 2012 16:13:02 -0800 Kevin Hilman <khilman@deeprootsystems.com>
wrote:

> On 02/15/2012 03:54 PM, Kevin Hilman wrote:
> > Luciano Coelho<coelho@ti.com>  writes:
> >
> > [...]
> >
> >> I just tried this on my Panda and I keep getting this kind of BUGs.  It
> >> spams my console so much that is pretty much unusable:
> >>
> >> [  336.172302] BUG: sleeping function called from invalid context at include/linux/freezer.h:46
> >> [  336.181213] in_atomic(): 0, irqs_disabled(): 128, pid: 1618, name: ntpd
> >> [  336.181213] INFO: lockdep is turned off.
> >> [  336.181213] irq event stamp: 0
> >> [  336.181213] hardirqs last  enabled at (0): [<   (null)>]   (null)
> >> [  336.201660] hardirqs last disabled at (0): [<c0042314>] copy_process+0x3ec/0x105c
> >> [  336.209625] softirqs last  enabled at (0): [<c0042314>] copy_process+0x3ec/0x105c
> >> [  336.217498] softirqs last disabled at (0): [<   (null)>]   (null)
> >> [  336.217498] [<c001e1e4>] (unwind_backtrace+0x0/0x148) from [<c0502c24>] (dump_stack+0x20/0x24)
> >> [  336.232879] [<c0502c24>] (dump_stack+0x20/0x24) from [<c0077998>] (__might_sleep+0x130/0x134)
> >> [  336.232879] [<c0077998>] (__might_sleep+0x130/0x134) from [<c0018998>] (do_signal+0x54/0x600)
> >> [  336.250793] [<c0018998>] (do_signal+0x54/0x600) from [<c0018fa4>] (do_notify_resume+0x60/0x6c)
> >> [  336.250793] [<c0018fa4>] (do_notify_resume+0x60/0x6c) from [<c00154e4>] (work_pending+0x24/0x28)
> >>
> >> I have also seen this in 3.3-rc3 (both on Panda (OMAP4460) and on Blaze
> >> (OMAP4430) boards) and I was hoping your tree would have the fix for it,
> >> but it doesn't. :( The device boots and seems to work otherwise, but
> >> this is annoying and looks shaky.
> >>
> >> I saw something related to this in another thread from a few months ago,
> >> and one patch proposal by Russell, but I didn't find any conclusion or
> >> any related patch queued up for upstream.
> >>
> >> Is there any solution for this? I use a tuned .config (attached) and not
> >> the one generated by omap2plus_defconfig (which I didn't try as
> >> vanilla).
> >
> > I see the same thing with your ~/.config, but I don't think this is OMAP
> > specific.  I suspect this will happen on any ARM platform that  has
> > CONFIG_DEBUG_ATOMIC_SLEEP=y.
> >
> > It appears to be a problem with the recently added audit support for
> > ARM, since reverting the commit below makes this BUG go away.
> 
> False alarm.  reverting the audit commit didn't make the problem go 
> away.  It was gone only because I also disabled 
> CONFIG_DEBUG_ATOMIC_SLEEP.  :/
> 
> To debug this further, you might bisect it back to v3.2 because the 
> problem isn't there in v3.2

I "fixed" this by applying

   https://lkml.org/lkml/2011/8/25/231

as shown here:

http://neil.brown.name/git?p=gta04;a=commitdiff;h=b43a97aefed9990811ed95676db58538f7279eb6

because google found some email that suggested it.  It worked but I didn't
even try to understand the patch.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: OMAP34xx

[Kevin Hilman]

NeilBrown <neilb@suse.de> writes:

> On Wed, 15 Feb 2012 16:13:02 -0800 Kevin Hilman <khilman@deeprootsystems.com>
> wrote:
>
>> On 02/15/2012 03:54 PM, Kevin Hilman wrote:
>> > Luciano Coelho<coelho@ti.com>  writes:
>> >
>> > [...]
>> >
>> >> I just tried this on my Panda and I keep getting this kind of BUGs.  It
>> >> spams my console so much that is pretty much unusable:
>> >>
>> >> [  336.172302] BUG: sleeping function called from invalid context at include/linux/freezer.h:46
>> >> [  336.181213] in_atomic(): 0, irqs_disabled(): 128, pid: 1618, name: ntpd
>> >> [  336.181213] INFO: lockdep is turned off.
>> >> [  336.181213] irq event stamp: 0
>> >> [  336.181213] hardirqs last  enabled at (0): [<   (null)>]   (null)
>> >> [  336.201660] hardirqs last disabled at (0): [<c0042314>] copy_process+0x3ec/0x105c
>> >> [  336.209625] softirqs last  enabled at (0): [<c0042314>] copy_process+0x3ec/0x105c
>> >> [  336.217498] softirqs last disabled at (0): [<   (null)>]   (null)
>> >> [  336.217498] [<c001e1e4>] (unwind_backtrace+0x0/0x148) from [<c0502c24>] (dump_stack+0x20/0x24)
>> >> [  336.232879] [<c0502c24>] (dump_stack+0x20/0x24) from [<c0077998>] (__might_sleep+0x130/0x134)
>> >> [  336.232879] [<c0077998>] (__might_sleep+0x130/0x134) from [<c0018998>] (do_signal+0x54/0x600)
>> >> [  336.250793] [<c0018998>] (do_signal+0x54/0x600) from [<c0018fa4>] (do_notify_resume+0x60/0x6c)
>> >> [  336.250793] [<c0018fa4>] (do_notify_resume+0x60/0x6c) from [<c00154e4>] (work_pending+0x24/0x28)
>> >>
>> >> I have also seen this in 3.3-rc3 (both on Panda (OMAP4460) and on Blaze
>> >> (OMAP4430) boards) and I was hoping your tree would have the fix for it,
>> >> but it doesn't. :( The device boots and seems to work otherwise, but
>> >> this is annoying and looks shaky.
>> >>
>> >> I saw something related to this in another thread from a few months ago,
>> >> and one patch proposal by Russell, but I didn't find any conclusion or
>> >> any related patch queued up for upstream.
>> >>
>> >> Is there any solution for this? I use a tuned .config (attached) and not
>> >> the one generated by omap2plus_defconfig (which I didn't try as
>> >> vanilla).
>> >
>> > I see the same thing with your ~/.config, but I don't think this is OMAP
>> > specific.  I suspect this will happen on any ARM platform that  has
>> > CONFIG_DEBUG_ATOMIC_SLEEP=y.
>> >
>> > It appears to be a problem with the recently added audit support for
>> > ARM, since reverting the commit below makes this BUG go away.
>> 
>> False alarm.  reverting the audit commit didn't make the problem go 
>> away.  It was gone only because I also disabled 
>> CONFIG_DEBUG_ATOMIC_SLEEP.  :/
>> 
>> To debug this further, you might bisect it back to v3.2 because the 
>> problem isn't there in v3.2
>
> I "fixed" this by applying
>
>    https://lkml.org/lkml/2011/8/25/231
>
> as shown here:
>
> http://neil.brown.name/git?p=gta04;a=commitdiff;h=b43a97aefed9990811ed95676db58538f7279eb6
>
> because google found some email that suggested it.  It worked but I didn't
> even try to understand the patch.

Great, thanks for the pointer.

Kevin

Re: OMAP34xx

[Luciano Coelho]

On Wed, 2012-02-15 at 17:28 -0800, Kevin Hilman wrote: 
> NeilBrown <neilb@suse.de> writes:
> 
> > On Wed, 15 Feb 2012 16:13:02 -0800 Kevin Hilman <khilman@deeprootsystems.com>
> > wrote:
> >
> >> On 02/15/2012 03:54 PM, Kevin Hilman wrote:
> >> > Luciano Coelho<coelho@ti.com>  writes:
> >> >
> >> > [...]
> >> >
> >> >> I just tried this on my Panda and I keep getting this kind of BUGs.  It
> >> >> spams my console so much that is pretty much unusable:
> >> >>
> >> >> [  336.172302] BUG: sleeping function called from invalid context at include/linux/freezer.h:46
> >> >> [  336.181213] in_atomic(): 0, irqs_disabled(): 128, pid: 1618, name: ntpd
> >> >> [  336.181213] INFO: lockdep is turned off.
> >> >> [  336.181213] irq event stamp: 0
> >> >> [  336.181213] hardirqs last  enabled at (0): [<   (null)>]   (null)
> >> >> [  336.201660] hardirqs last disabled at (0): [<c0042314>] copy_process+0x3ec/0x105c
> >> >> [  336.209625] softirqs last  enabled at (0): [<c0042314>] copy_process+0x3ec/0x105c
> >> >> [  336.217498] softirqs last disabled at (0): [<   (null)>]   (null)
> >> >> [  336.217498] [<c001e1e4>] (unwind_backtrace+0x0/0x148) from [<c0502c24>] (dump_stack+0x20/0x24)
> >> >> [  336.232879] [<c0502c24>] (dump_stack+0x20/0x24) from [<c0077998>] (__might_sleep+0x130/0x134)
> >> >> [  336.232879] [<c0077998>] (__might_sleep+0x130/0x134) from [<c0018998>] (do_signal+0x54/0x600)
> >> >> [  336.250793] [<c0018998>] (do_signal+0x54/0x600) from [<c0018fa4>] (do_notify_resume+0x60/0x6c)
> >> >> [  336.250793] [<c0018fa4>] (do_notify_resume+0x60/0x6c) from [<c00154e4>] (work_pending+0x24/0x28)
> >> >>
> >> >> I have also seen this in 3.3-rc3 (both on Panda (OMAP4460) and on Blaze
> >> >> (OMAP4430) boards) and I was hoping your tree would have the fix for it,
> >> >> but it doesn't. :( The device boots and seems to work otherwise, but
> >> >> this is annoying and looks shaky.
> >> >>
> >> >> I saw something related to this in another thread from a few months ago,
> >> >> and one patch proposal by Russell, but I didn't find any conclusion or
> >> >> any related patch queued up for upstream.
> >> >>
> >> >> Is there any solution for this? I use a tuned .config (attached) and not
> >> >> the one generated by omap2plus_defconfig (which I didn't try as
> >> >> vanilla).
> >> >
> >> > I see the same thing with your ~/.config, but I don't think this is OMAP
> >> > specific.  I suspect this will happen on any ARM platform that  has
> >> > CONFIG_DEBUG_ATOMIC_SLEEP=y.
> >> >
> >> > It appears to be a problem with the recently added audit support for
> >> > ARM, since reverting the commit below makes this BUG go away.
> >> 
> >> False alarm.  reverting the audit commit didn't make the problem go 
> >> away.  It was gone only because I also disabled 
> >> CONFIG_DEBUG_ATOMIC_SLEEP.  :/
> >> 
> >> To debug this further, you might bisect it back to v3.2 because the 
> >> problem isn't there in v3.2
> >
> > I "fixed" this by applying
> >
> >    https://lkml.org/lkml/2011/8/25/231
> >
> > as shown here:
> >
> > http://neil.brown.name/git?p=gta04;a=commitdiff;h=b43a97aefed9990811ed95676db58538f7279eb6
> >
> > because google found some email that suggested it.  It worked but I didn't
> > even try to understand the patch.
> 
> Great, thanks for the pointer.

I had found this patch also when I searched the list.  That's what I
meant by "one patch proposal by Russell", but it was back in August and
the patch doesn't seem to have been ever applied.  The discussion also
seemed to end abruptly, so my assumption was that no conclusion has been
really reached.

Instead of applying that, I have simply removed the might_sleep() call
in the try_to_freeze() function.  This definitely doesn't solve the
problem, but at least my console doesn't get spammed and it's better
than disabling CONFIG_DEBUG_ATOMIC_SLEEP, because at least I still catch
other sleeps while atomic. ;)

-- 
Cheers,
Luca.

Re: OMAP34xx

[Luciano Coelho]

Hi Kevin,

On Wed, 2012-02-15 at 16:13 -0800, Kevin Hilman wrote: 
> On 02/15/2012 03:54 PM, Kevin Hilman wrote:
> > Luciano Coelho<coelho@ti.com>  writes:
> >
> > [...]
> >
> >> I just tried this on my Panda and I keep getting this kind of BUGs.  It
> >> spams my console so much that is pretty much unusable:
> >>
> >> [  336.172302] BUG: sleeping function called from invalid context at include/linux/freezer.h:46
> >> [  336.181213] in_atomic(): 0, irqs_disabled(): 128, pid: 1618, name: ntpd
> >> [  336.181213] INFO: lockdep is turned off.
> >> [  336.181213] irq event stamp: 0
> >> [  336.181213] hardirqs last  enabled at (0): [<   (null)>]   (null)
> >> [  336.201660] hardirqs last disabled at (0): [<c0042314>] copy_process+0x3ec/0x105c
> >> [  336.209625] softirqs last  enabled at (0): [<c0042314>] copy_process+0x3ec/0x105c
> >> [  336.217498] softirqs last disabled at (0): [<   (null)>]   (null)
> >> [  336.217498] [<c001e1e4>] (unwind_backtrace+0x0/0x148) from [<c0502c24>] (dump_stack+0x20/0x24)
> >> [  336.232879] [<c0502c24>] (dump_stack+0x20/0x24) from [<c0077998>] (__might_sleep+0x130/0x134)
> >> [  336.232879] [<c0077998>] (__might_sleep+0x130/0x134) from [<c0018998>] (do_signal+0x54/0x600)
> >> [  336.250793] [<c0018998>] (do_signal+0x54/0x600) from [<c0018fa4>] (do_notify_resume+0x60/0x6c)
> >> [  336.250793] [<c0018fa4>] (do_notify_resume+0x60/0x6c) from [<c00154e4>] (work_pending+0x24/0x28)
> >>
> >> I have also seen this in 3.3-rc3 (both on Panda (OMAP4460) and on Blaze
> >> (OMAP4430) boards) and I was hoping your tree would have the fix for it,
> >> but it doesn't. :( The device boots and seems to work otherwise, but
> >> this is annoying and looks shaky.
> >>
> >> I saw something related to this in another thread from a few months ago,
> >> and one patch proposal by Russell, but I didn't find any conclusion or
> >> any related patch queued up for upstream.
> >>
> >> Is there any solution for this? I use a tuned .config (attached) and not
> >> the one generated by omap2plus_defconfig (which I didn't try as
> >> vanilla).
> >
> > I see the same thing with your ~/.config, but I don't think this is OMAP
> > specific.  I suspect this will happen on any ARM platform that  has
> > CONFIG_DEBUG_ATOMIC_SLEEP=y.

Right.  I always use CONFIG_DEBUG_ATOMIC_SLEEP.  And yes, according to
what I had seen, this was an ARM issue not only OMAP.


> > It appears to be a problem with the recently added audit support for
> > ARM, since reverting the commit below makes this BUG go away.
> 
> False alarm.  reverting the audit commit didn't make the problem go 
> away.  It was gone only because I also disabled 
> CONFIG_DEBUG_ATOMIC_SLEEP.  :/
> 
> To debug this further, you might bisect it back to v3.2 because the 
> problem isn't there in v3.2

When I was looking a bit further, I found this patch: a0acae0e "freezer:
unexport refrigerator() and update try_to_freeze() slightly", which
seems to be the one introducing the bug.  It's quite far back and quite
large, so reverting it is not that easy.

I may try to do some bisecting later today, but I'm not sure I'll have
the time.

-- 
Cheers,
Luca.

Re: OMAP34xx

[Felipe Contreras]

On Thu, Feb 9, 2012 at 2:47 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> Show me an OMAP user that actually runs a mainline kernel :)

I haven't used anything but mainline kernel since years when I test
stuff on my Nokia N900.

Cheers.

-- 
Felipe Contreras

Re: OMAP34xx

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 11:53:27AM -0800, Greg KH wrote:
> On Wed, Feb 08, 2012 at 07:23:34PM +0200, Grazvydas Ignotas wrote:
> > On Wed, Feb 8, 2012 at 7:06 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > On Wed, Feb 08, 2012 at 09:01:24AM -0800, Kevin Hilman wrote:
> > >> Grazvydas Ignotas <notasas@gmail.com> writes:
> > >>
> > >> > On Wed, Feb 8, 2012 at 2:53 AM, Kevin Hilman <khilman@ti.com> wrote:
> > >> >> Kevin Hilman <khilman@ti.com> writes:
> > >> >>
> > >> >>> This one is indeed strange.  I have not seen this on the 34xx devices
> > >> >>> I'm using (3430/n900, 3530/Overo, 3630/Zoom3).
> > >> >>
> > >> >> OK, I've reproduced this on v3.3-rc2.
> > >> >>
> > >> >> The reason I wasn't seeing this is because I'm using the fixes Paul has
> > >> >> already posted that fix this problem:
> > >> >>
> > >> >>        http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2
> > >> >>
> > >> >> Kevin
> > >> >
> > >> > But it looks like these are now queued for 3.4 in tty tree?
> > >>
> > >> I believe they were targettted for 3.3-rc.
> > >>
> > >> Paul, Greg, can you confirm?
> > >
> > > I have no idea what you are refering to here, please be much more
> > > specific.  You can look at the linux-next tree to answer your question
> > > yourself as well...
> > 
> > It's about these patches in gregkh/tty.git tty-next:
> > 6bbcbf2 tty: serial: omap-serial: wakeup latency constraint is in
> > microseconds, not milliseconds
> > edbe5db tty: serial: OMAP: block idle while the UART is transferring
> > data in PIO mode
> > 5816269 tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode
> > 
> > It would look to me like they are queued for 3.4 but Kevin says there
> > were intended for 3.3-rc.
> 
> Kevin might have wished they would go into 3.3, but given that the first
> round of these patches had to be reverted, I thought it safer to wait
> for 3.4.

Greg,

There's currently a regression here:

2fd149645eb4 (ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos)

which causes OMAP3 platforms to spit out 16 characters every couple of
seconds after typing 'dmesg' on the serial console.  This is something
which used to work before the above commit.

The above commit doesn't revert because there's a bunch of other changes
in later commits which remove some of the stuff it depends on, so a simple
revert is out.

What I'd like to see from OMAP folk is whether there's a simple solution.
If not, then edbe5db looks like it should be targetted for -rc.

However, I've not yet tested edbe5db to confirm whether it solves my
observations (I've not seen it either).
--
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: OMAP34xx

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [120205 08:58]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 04:28]:
> > On Sat, Feb 04, 2012 at 05:25:57PM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 12:03]:
> > > > 
> > > > Another problem (some build errors for OMAP3) do seem to be solved, but
> > > > not the section mismatch warnings.  They're easy to verify before code
> > > > gets pushed anywhere upstream, especially if you're doing one giant OMAP
> > > > build - just enable CONFIG_DEBUG_SECTION_MISMATCH in your build
> > > > configuration.  Refuse patches which introduce section mismatches - at
> > > > least without an explanation backing up why they do.
> > > >
> > > > My OMAP3 and OMAP4 configurations spit out these - I've not even tried
> > > > my OMAP2 configuration yet:
> > > 
> > > Weird. The warnings you're seeing all seem valid to me, but I'm not seeing
> > > any the section warnings with the following compilers I have:
> > > 
> > > gcc version 4.3.5 (Debian 4.3.5-4)
> > > gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)
> > > gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70)
> > > 
> > > I see _different_ warnings if I compile with an older gcc:
> > > gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)
> > > 
> > > Any ideas why that would be?
> > 
> > Different inlining behaviour maybe?  I'm using stock gcc 4.3.5 here.
> 
> Hmm I'd assume the Emdebian gcc 4.3.5-4 would be very close to the
> stock gcc, need to investigate.

FYI, I'm now seeing the same warning as Igor posted with
omap2plus_defconfig using the same compiler as Igor:

gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) 

Still no other warnings though.

Regards,

Tony

Re: OMAP34xx

[Russell King - ARM Linux]

On Mon, Feb 06, 2012 at 10:13:15AM -0800, Tony Lindgren wrote:
> FYI, I'm now seeing the same warning as Igor posted with
> omap2plus_defconfig using the same compiler as Igor:
> 
> gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) 
> 
> Still no other warnings though.

If you're not getting the twl4030_power_init() you still need to
investigate why.  For example, are you sure you're building with
CONFIG_TWL4030_POWER enabled?

Secondly, check what you're actually getting:

$ arm-linux-objdump -t ../build/omap4/drivers/mfd/twl4030-power.o | grep twl4030_power_init
000000c0 g     F .init.text     0000066c twl4030_power_init
$ arm-linux-objdump -r ../build/omap4/drivers/mfd/twl-core.o | grep 'twl4030_power_init\|^RELOC'
RELOCATION RECORDS FOR [.text]:
RELOCATION RECORDS FOR [.init.text]:
RELOCATION RECORDS FOR [.exit.text]:
RELOCATION RECORDS FOR [.devinit.text]:
00000258 R_ARM_PC24        twl4030_power_init

and from this we can see that the compiler is doing what they're told
wrt the sections the code is being placed into, and secondly that the
section mismatch tool is working correctly.

So, if you have all that, but you're still not getting this mismatch
warning:

    WARNING: drivers/mfd/built-in.o(.devinit.text+0x258): Section mismatch in reference from the function twl_probe() to the function .init.text:twl4030_power_init()
    The function __devinit twl_probe() references
    a function __init twl4030_power_init().
    If twl4030_power_init is only used by twl_probe then
    annotate twl4030_power_init with a matching annotation.

then, quite simply, your build setup is broken and can't be relied
upon to give proper warnings.

As I mentioned previously, there's no way that the compiler could
optimize this to get rid of this warning as the function definition is
in a completely separate file to where it's being called.

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120207 01:39]:
> On Mon, Feb 06, 2012 at 10:13:15AM -0800, Tony Lindgren wrote:
> > FYI, I'm now seeing the same warning as Igor posted with
> > omap2plus_defconfig using the same compiler as Igor:
> > 
> > gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) 
> > 
> > Still no other warnings though.
> 
> If you're not getting the twl4030_power_init() you still need to
> investigate why.  For example, are you sure you're building with
> CONFIG_TWL4030_POWER enabled?

Yes it's enabled in omap2plus_defconfig. Same results with one
of your defconfigs. Below is the output from compiler above.
 
> Secondly, check what you're actually getting:
> 
> $ arm-linux-objdump -t ../build/omap4/drivers/mfd/twl4030-power.o | grep twl4030_power_init
> 000000c0 g     F .init.text     0000066c twl4030_power_init

00000650 g     F .init.text     000001a0 twl4030_power_init

> $ arm-linux-objdump -r ../build/omap4/drivers/mfd/twl-core.o | grep 'twl4030_power_init\|^RELOC'
> RELOCATION RECORDS FOR [.text]:
> RELOCATION RECORDS FOR [.init.text]:
> RELOCATION RECORDS FOR [.exit.text]:
> RELOCATION RECORDS FOR [.devinit.text]:
> 00000258 R_ARM_PC24        twl4030_power_init

RELOCATION RECORDS FOR [.text]:
RELOCATION RECORDS FOR [.init.text]:
RELOCATION RECORDS FOR [.exit.text]:
RELOCATION RECORDS FOR [.devinit.text]:
000001c8 R_ARM_CALL        twl4030_power_init
RELOCATION RECORDS FOR [.ARM.exidx]:
RELOCATION RECORDS FOR [.ARM.exidx.init.text]:
RELOCATION RECORDS FOR [.ARM.exidx.exit.text]:
RELOCATION RECORDS FOR [.ARM.exidx.devinit.text]:
RELOCATION RECORDS FOR [___kcrctab+twl_i2c_write]:
RELOCATION RECORDS FOR [___ksymtab+twl_i2c_write_u8]:
RELOCATION RECORDS FOR [___ksymtab+twl_i2c_write]:
RELOCATION RECORDS FOR [___ksymtab+twl_rev]:
RELOCATION RECORDS FOR [___ksymtab_gpl+twl_get_version]:
RELOCATION RECORDS FOR [___kcrctab_gpl+twl_get_type]:
RELOCATION RECORDS FOR [___ksymtab+twl_i2c_read]:
RELOCATION RECORDS FOR [___ksymtab_gpl+twl_get_type]:
RELOCATION RECORDS FOR [___kcrctab+twl_rev]:
RELOCATION RECORDS FOR [___kcrctab+twl_i2c_write_u8]:
RELOCATION RECORDS FOR [___kcrctab+twl_i2c_read_u8]:
RELOCATION RECORDS FOR [___ksymtab+twl_i2c_read_u8]:
RELOCATION RECORDS FOR [___kcrctab+twl_i2c_read]:
RELOCATION RECORDS FOR [___kcrctab_gpl+twl_get_version]:
RELOCATION RECORDS FOR [.data]:
RELOCATION RECORDS FOR [.initcall4.init]:
RELOCATION RECORDS FOR [.exitcall.exit]:
RELOCATION RECORDS FOR [.debug_info]:
RELOCATION RECORDS FOR [.debug_line]:
RELOCATION RECORDS FOR [.debug_frame]:
RELOCATION RECORDS FOR [.debug_loc]:
RELOCATION RECORDS FOR [.debug_pubnames]:
RELOCATION RECORDS FOR [.debug_aranges]:
RELOCATION RECORDS FOR [.debug_ranges]:

> and from this we can see that the compiler is doing what they're told
> wrt the sections the code is being placed into, and secondly that the
> section mismatch tool is working correctly.
> 
> So, if you have all that, but you're still not getting this mismatch
> warning:
> 
>     WARNING: drivers/mfd/built-in.o(.devinit.text+0x258): Section mismatch in reference from the function twl_probe() to the function .init.text:twl4030_power_init()
>     The function __devinit twl_probe() references
>     a function __init twl4030_power_init().
>     If twl4030_power_init is only used by twl_probe then
>     annotate twl4030_power_init with a matching annotation.
> 
> then, quite simply, your build setup is broken and can't be relied
> upon to give proper warnings.

Right, no luck yet getting crosstool-ng built plain gcc working..
Yesterday ftp.gnu.org was down and the script is using that. Have
to continue with that when I get a chance.
 
> As I mentioned previously, there's no way that the compiler could
> optimize this to get rid of this warning as the function definition is
> in a completely separate file to where it's being called.

Yes it seems that there's something wrong..

Tony

Re: OMAP34xx

[Tony Lindgren]

Hi,

* Tony Lindgren <tony@atomide.com> [120207 21:01]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120207 01:39]:
> > On Mon, Feb 06, 2012 at 10:13:15AM -0800, Tony Lindgren wrote:
> > > FYI, I'm now seeing the same warning as Igor posted with
> > > omap2plus_defconfig using the same compiler as Igor:
> > > 
> > > gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) 
> > > 
> > > Still no other warnings though.
> > 
> > If you're not getting the twl4030_power_init() you still need to
> > investigate why.  For example, are you sure you're building with
> > CONFIG_TWL4030_POWER enabled?
> 
> Yes it's enabled in omap2plus_defconfig. Same results with one
> of your defconfigs. Below is the output from compiler above.
>  
> > Secondly, check what you're actually getting:
> > 
> > $ arm-linux-objdump -t ../build/omap4/drivers/mfd/twl4030-power.o | grep twl4030_power_init
> > 000000c0 g     F .init.text     0000066c twl4030_power_init
> > 00000650 g     F .init.text     000001a0 twl4030_power_init
> 
> > $ arm-linux-objdump -r ../build/omap4/drivers/mfd/twl-core.o | grep 'twl4030_power_init\|^RELOC'
> > RELOCATION RECORDS FOR [.text]:
> > RELOCATION RECORDS FOR [.init.text]:
> > RELOCATION RECORDS FOR [.exit.text]:
> > RELOCATION RECORDS FOR [.devinit.text]:
> > 00000258 R_ARM_PC24        twl4030_power_init

I'll post a patch to fix this, it's caused by missing
handling in modpost.c.
 
> > then, quite simply, your build setup is broken and can't be relied
> > upon to give proper warnings.
> 
> Right, no luck yet getting crosstool-ng built plain gcc working..
> Yesterday ftp.gnu.org was down and the script is using that. Have
> to continue with that when I get a chance.

The gnu.org ftp issue was a firewall issue on my build box..

Got the compiler build going further with the following fix to
crosstool-ng in case others are having similar issues. Will send
that separately to crosstool-ng mailing list.

Regards,

Tony


--- a/scripts/build/debug/200-duma.sh	Thu Feb 02 22:43:18 2012 +0100
+++ b/scripts/build/debug/200-duma.sh	Mon Feb 13 12:36:06 2012 -0800
@@ -4,7 +4,7 @@
     # Downloading an non-existing file from sourceforge will give you an
     # HTML file containing an error message, instead of returning a 404.
     # Sigh...
-    CT_GetFile "duma_${CT_DUMA_VERSION}" .tar.gz http://mesh.dl.sourceforge.net/sourceforge/duma/
+    CT_GetFile "duma_${CT_DUMA_VERSION}" .tar.gz http://dfn.dl.sourceforge.net/sourceforge/duma/
     # Downloading from sourceforge may leave garbage, cleanup
     CT_DoExecLog ALL rm -f "${CT_TARBALLS_DIR}/showfiles.php"*
 }
--- a/scripts/build/debug/300-gdb.sh	Thu Feb 02 22:43:18 2012 +0100
+++ b/scripts/build/debug/300-gdb.sh	Mon Feb 13 12:36:06 2012 -0800
@@ -62,7 +62,7 @@
 
     if [ "${do_expat}" = "y" ]; then
         CT_GetFile "expat-${CT_DEBUG_GDB_EXPAT_VERSION}" .tar.gz    \
-                   http://mesh.dl.sourceforge.net/sourceforge/expat/expat/${CT_DEBUG_GDB_EXPAT_VERSION}
+                   http://dfn.dl.sourceforge.net/sourceforge/expat/expat/${CT_DEBUG_GDB_EXPAT_VERSION}
     fi
 }
 
--- a/scripts/build/debug/500-strace.sh	Thu Feb 02 22:43:18 2012 +0100
+++ b/scripts/build/debug/500-strace.sh	Mon Feb 13 12:36:06 2012 -0800
@@ -1,7 +1,7 @@
 # Build script for strace
 
 do_debug_strace_get() {
-    CT_GetFile "strace-${CT_STRACE_VERSION}" http://mesh.dl.sourceforge.net/sourceforge/strace/
+    CT_GetFile "strace-${CT_STRACE_VERSION}" http://dfn.dl.sourceforge.net/sourceforge/strace/
     # Downloading from sourceforge leaves garbage, cleanup
     CT_DoExecLog ALL rm -f "${CT_TARBALLS_DIR}/showfiles.php"*
 }

Re: OMAP34xx

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [120213 12:46]:
> 
> Got the compiler build going further with the following fix to
> crosstool-ng in case others are having similar issues. Will send
> that separately to crosstool-ng mailing list.

Looks like that's already in works according to this:

http://sourceware.org/ml/crossgcc/2012-02/msg00048.html

Regards,

Tony

> --- a/scripts/build/debug/200-duma.sh	Thu Feb 02 22:43:18 2012 +0100
> +++ b/scripts/build/debug/200-duma.sh	Mon Feb 13 12:36:06 2012 -0800
> @@ -4,7 +4,7 @@
>      # Downloading an non-existing file from sourceforge will give you an
>      # HTML file containing an error message, instead of returning a 404.
>      # Sigh...
> -    CT_GetFile "duma_${CT_DUMA_VERSION}" .tar.gz http://mesh.dl.sourceforge.net/sourceforge/duma/
> +    CT_GetFile "duma_${CT_DUMA_VERSION}" .tar.gz http://dfn.dl.sourceforge.net/sourceforge/duma/
>      # Downloading from sourceforge may leave garbage, cleanup
>      CT_DoExecLog ALL rm -f "${CT_TARBALLS_DIR}/showfiles.php"*
>  }
> --- a/scripts/build/debug/300-gdb.sh	Thu Feb 02 22:43:18 2012 +0100
> +++ b/scripts/build/debug/300-gdb.sh	Mon Feb 13 12:36:06 2012 -0800
> @@ -62,7 +62,7 @@
>  
>      if [ "${do_expat}" = "y" ]; then
>          CT_GetFile "expat-${CT_DEBUG_GDB_EXPAT_VERSION}" .tar.gz    \
> -                   http://mesh.dl.sourceforge.net/sourceforge/expat/expat/${CT_DEBUG_GDB_EXPAT_VERSION}
> +                   http://dfn.dl.sourceforge.net/sourceforge/expat/expat/${CT_DEBUG_GDB_EXPAT_VERSION}
>      fi
>  }
>  
> --- a/scripts/build/debug/500-strace.sh	Thu Feb 02 22:43:18 2012 +0100
> +++ b/scripts/build/debug/500-strace.sh	Mon Feb 13 12:36:06 2012 -0800
> @@ -1,7 +1,7 @@
>  # Build script for strace
>  
>  do_debug_strace_get() {
> -    CT_GetFile "strace-${CT_STRACE_VERSION}" http://mesh.dl.sourceforge.net/sourceforge/strace/
> +    CT_GetFile "strace-${CT_STRACE_VERSION}" http://dfn.dl.sourceforge.net/sourceforge/strace/
>      # Downloading from sourceforge leaves garbage, cleanup
>      CT_DoExecLog ALL rm -f "${CT_TARBALLS_DIR}/showfiles.php"*
>  }
> --
> 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: OMAP34xx

[Cousson, Benoit]

+ Grant and Rob

Hi Tony,

On 2/5/2012 6:29 PM, Tony Lindgren wrote:

[...]

>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -200,7 +200,7 @@ config MENELAUS
>>
>>   config TWL4030_CORE
>>   	bool "Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support"
>> -	depends on I2C=y&&  GENERIC_HARDIRQS&&  IRQ_DOMAIN
>> +	depends on I2C=y&&  GENERIC_HARDIRQS
>>   	help
>>   	  Say yes here if you have TWL4030 / TWL6030 family chip on your board.
>>   	  This core driver provides register access and IRQ handling
>> --- a/drivers/mfd/twl-core.c
>> +++ b/drivers/mfd/twl-core.c
>> @@ -263,7 +263,9 @@ struct twl_client {
>>
>>   static struct twl_client twl_modules[TWL_NUM_SLAVES];
>>
>> +#ifdef CONFIG_IRQ_DOMAIN
>>   static struct irq_domain domain;
>> +#endif
>>
>>   /* mapping the module id to slave id and base address */
>>   struct twl_mapping {
>> @@ -1226,13 +1228,13 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
>>   	pdata->irq_base = status;
>>   	pdata->irq_end = pdata->irq_base + nr_irqs;
>>
>> +#ifdef CONFIG_IRQ_DOMAIN
>>   	domain.irq_base = pdata->irq_base;
>>   	domain.nr_irq = nr_irqs;
>> -#ifdef CONFIG_OF_IRQ
>>   	domain.of_node = of_node_get(node);
>>   	domain.ops =&irq_domain_simple_ops;
>> -#endif
>>   	irq_domain_add(&domain);
>> +#endif
>>
>>   	if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
>>   		dev_dbg(&client->dev, "can't talk I2C?\n");
> 
> The above should be a separate fix to the drivers/mfd/twl code.

In theory that patch should not be even needed.
The twl changes were done like that because it was assuming that USE_OF and thus IRQ_DOMAIN will be enabled by default for all OMAP2+ platforms at 3.3 time.
The whole point of doing that was to reduce the ifdefery in every drivers we have to adapt to DT.

You even pulled the patch to enable that a while back [1], but for some reason it did not reach mainline in 3.3-rc1.

Since Rob is about to enable IRQ_DOMAIN for every ARM platforms, I'd rather push the patch to enable OF for every OMAP2+ platform and avoid hacking the twl-core any further since Grant / Rob have anyway some patches to simplify and potentially removed the custom irq_domain from this driver [2].

Regards,
Benoit


[1] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=40c0591f0a349ec074357e05c6ab1a3bc951807c
[2] http://www.spinics.net/lists/arm-kernel/msg157375.html

Re: OMAP34xx

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [120206 14:48]:
> + Grant and Rob
> 
> Hi Tony,
> 
> On 2/5/2012 6:29 PM, Tony Lindgren wrote:
> 
> [...]
> 
> >> --- a/drivers/mfd/Kconfig
> >> +++ b/drivers/mfd/Kconfig
> >> @@ -200,7 +200,7 @@ config MENELAUS
> >>
> >>   config TWL4030_CORE
> >>   	bool "Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support"
> >> -	depends on I2C=y&&  GENERIC_HARDIRQS&&  IRQ_DOMAIN
> >> +	depends on I2C=y&&  GENERIC_HARDIRQS
> >>   	help
> >>   	  Say yes here if you have TWL4030 / TWL6030 family chip on your board.
> >>   	  This core driver provides register access and IRQ handling
> >> --- a/drivers/mfd/twl-core.c
> >> +++ b/drivers/mfd/twl-core.c
> >> @@ -263,7 +263,9 @@ struct twl_client {
> >>
> >>   static struct twl_client twl_modules[TWL_NUM_SLAVES];
> >>
> >> +#ifdef CONFIG_IRQ_DOMAIN
> >>   static struct irq_domain domain;
> >> +#endif
> >>
> >>   /* mapping the module id to slave id and base address */
> >>   struct twl_mapping {
> >> @@ -1226,13 +1228,13 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> >>   	pdata->irq_base = status;
> >>   	pdata->irq_end = pdata->irq_base + nr_irqs;
> >>
> >> +#ifdef CONFIG_IRQ_DOMAIN
> >>   	domain.irq_base = pdata->irq_base;
> >>   	domain.nr_irq = nr_irqs;
> >> -#ifdef CONFIG_OF_IRQ
> >>   	domain.of_node = of_node_get(node);
> >>   	domain.ops =&irq_domain_simple_ops;
> >> -#endif
> >>   	irq_domain_add(&domain);
> >> +#endif
> >>
> >>   	if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
> >>   		dev_dbg(&client->dev, "can't talk I2C?\n");
> > 
> > The above should be a separate fix to the drivers/mfd/twl code.
> 
> In theory that patch should not be even needed.
> The twl changes were done like that because it was assuming that USE_OF and thus IRQ_DOMAIN will be enabled by default for all OMAP2+ platforms at 3.3 time.
> The whole point of doing that was to reduce the ifdefery in every drivers we have to adapt to DT.
> 
> You even pulled the patch to enable that a while back [1], but for some reason it did not reach mainline in 3.3-rc1.
> 
> Since Rob is about to enable IRQ_DOMAIN for every ARM platforms, I'd rather push the patch to enable OF for every OMAP2+ platform and avoid hacking the twl-core any further since Grant / Rob have anyway some patches to simplify and potentially removed the custom irq_domain from this driver [2].

To me it seems that it is safe to enable OF as that's
what we've had with omap2plus_defconfig for a while now
and that's what we're heading to anyways.

Regards,

Tony

> [1] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=40c0591f0a349ec074357e05c6ab1a3bc951807c
> [2] http://www.spinics.net/lists/arm-kernel/msg157375.html

Re: OMAP34xx

[Russell King - ARM Linux]

On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
> In theory that patch should not be even needed.

In theory that change is needed to fix the obviously broken code which
is there at the moment.

So, irrespective of whether OF gets permanently enabled or not, that ifdef
needs to go.

But, forcing OF on at this point probably isn't a good idea (who knows
what else is lurking there) and there's a fairly simple and tested fix
for this as I've shown in my OMAP patch.

That, I feel, is likely to have less side effects than force enabling
USE_OF.

Re: OMAP34xx

[Cousson, Benoit]

Hi Russell,

On 2/7/2012 1:24 AM, Russell King - ARM Linux wrote:
> On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
>> In theory that patch should not be even needed.
>
> In theory that change is needed to fix the obviously broken code which
> is there at the moment.

Well, both patches were supposed to be merged during the last merge 
window, so this code is not broken but was just assuming that the proper 
default configs were there. It is an integration issue between two 
feature trees.

> So, irrespective of whether OF gets permanently enabled or not, that ifdef
> needs to go.

The whole point of adding USE_OF in default omap2plus_config was to 
avoid all the #ifdef that supporting both OF and non-OF build will generate.

> But, forcing OF on at this point probably isn't a good idea (who knows
> what else is lurking there) and there's a fairly simple and tested fix
> for this as I've shown in my OMAP patch.

The issues we are facing right now are already due to the usage of 
config that are not the default ones (omap2plus_defconfig), so adding 
even more options will just lead to even more potential build breaks in 
the future.
I think we need to reduce the amount of options we can support in order 
to avoid the current issues and not adding some more.

Since it was already agreed by the whole arm-soc community that DT is 
the only way to go, I guess that the sooner we enable that the better it is.

> That, I feel, is likely to have less side effects than force enabling
> USE_OF.

If we never enable USE_OF by default, we will never know...
So far I did not observe any regression by enabling USE_OF with a legacy 
board boot.

Regards,
Benoit

Re: OMAP34xx

[Russell King - ARM Linux]

On Tue, Feb 07, 2012 at 01:54:57AM +0100, Cousson, Benoit wrote:
> Hi Russell,
>
> On 2/7/2012 1:24 AM, Russell King - ARM Linux wrote:
>> On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
>>> In theory that patch should not be even needed.
>>
>> In theory that change is needed to fix the obviously broken code which
>> is there at the moment.
>
> Well, both patches were supposed to be merged during the last merge  
> window, so this code is not broken

You're talking out your arse.  It's fucked, because:

        domain.irq_base = pdata->irq_base;
        domain.nr_irq = nr_irqs;
#ifdef CONFIG_OF_IRQ
        domain.of_node = of_node_get(node);
        domain.ops = &irq_domain_simple_ops;
#endif
        irq_domain_add(&domain);

YOU MUST NEVER EVER REGISTER AN IRQ DOMAIN WITH A NULL .ops MEMBER OTHERWISE
THE KERNEL IS GUARANTEED TO OOPS.

I don't care whether you think "oh, but OF_IRQ should have been set".
That's not the point.  The fact is, how this code is _currently_ written,
it is _broken_ and therefore this code needs fixing.

Re: OMAP34xx

[Cousson, Benoit]

On 2/7/2012 9:41 AM, Russell King - ARM Linux wrote:
> On Tue, Feb 07, 2012 at 01:54:57AM +0100, Cousson, Benoit wrote:
>> Hi Russell,
>>
>> On 2/7/2012 1:24 AM, Russell King - ARM Linux wrote:
>>> On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
>>>> In theory that patch should not be even needed.
>>>
>>> In theory that change is needed to fix the obviously broken code which
>>> is there at the moment.
>>
>> Well, both patches were supposed to be merged during the last merge
>> window, so this code is not broken
>
> You're talking out your arse.

Yep, this requires years of practice, but the harder is not necessarily 
to talk but mainly to handle the keyboard.

> It's fucked, because:
>
>          domain.irq_base = pdata->irq_base;
>          domain.nr_irq = nr_irqs;
> #ifdef CONFIG_OF_IRQ
>          domain.of_node = of_node_get(node);
>          domain.ops =&irq_domain_simple_ops;
> #endif
>          irq_domain_add(&domain);
>
> YOU MUST NEVER EVER REGISTER AN IRQ DOMAIN WITH A NULL .ops MEMBER OTHERWISE
> THE KERNEL IS GUARANTEED TO OOPS.

OK, I think I get it now. AFAIR the domain.ops was added inside the 
CONFIG_OF_IRQ because irq_domain_simple_ops was just defined if 
CONFIG_OF_IRQ was defined at that time and thus the build was broken for 
non-DT build.

It appears that this dependency was indeed broken because after googling 
a little bit based on Mark's comment I found that a proper patch to fix 
that was sent during 3.2-rc5.

commit c87fb57346fc7653ace98769f148e0dcd88ac1ee
Author: Jamie Iles <jamie@jamieiles.com>
Date:   Wed Dec 14 23:43:16 2011 +0100

     ARM: 7235/1: irqdomain: export irq_domain_simple_ops for !CONFIG_OF

So indeed, it is now safe and better to remove this CONFIG_OF_IRQ to 
avoid the oops before Grant nuke that code with the new 
irq_domain_add_legacy.

Regards,
Benoit

Re: OMAP34xx

[Grant Likely]

On Mon, Feb 6, 2012 at 5:24 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
>> In theory that patch should not be even needed.
>
> In theory that change is needed to fix the obviously broken code which
> is there at the moment.
>
> So, irrespective of whether OF gets permanently enabled or not, that ifdef
> needs to go.
>
> But, forcing OF on at this point probably isn't a good idea (who knows
> what else is lurking there) and there's a fairly simple and tested fix
> for this as I've shown in my OMAP patch.
>
> That, I feel, is likely to have less side effects than force enabling
> USE_OF.

+1.  Fix the obvious bug in 3.3.  In 3.4 this hunk of code is going to
be replaced anyway.

g.



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: OMAP34xx

[Cousson, Benoit]

On 2/7/2012 5:35 AM, Grant Likely wrote:
> On Mon, Feb 6, 2012 at 5:24 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk>  wrote:
>> On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
>>> In theory that patch should not be even needed.
>>
>> In theory that change is needed to fix the obviously broken code which
>> is there at the moment.
>>
>> So, irrespective of whether OF gets permanently enabled or not, that ifdef
>> needs to go.
>>
>> But, forcing OF on at this point probably isn't a good idea (who knows
>> what else is lurking there) and there's a fairly simple and tested fix
>> for this as I've shown in my OMAP patch.
>>
>> That, I feel, is likely to have less side effects than force enabling
>> USE_OF.
>
> +1.  Fix the obvious bug in 3.3.  In 3.4 this hunk of code is going to
> be replaced anyway.

Yeah, but that's the point. You can fix that by either adding some more 
#ifdef in the driver knowing that this code will be completely removed 
in the next merge window, or you can fix that by adding the USE_OF in 
the omap2+ defconfig like it was supposed to be done originally.

The first one is a temp fix that will be thrown away whereas the second 
approach is the long term solution we have to implement anyway.

It looks to me that doing the long term solution instead of the temp fix 
is much more efficient and will avoid un-necessary churn.

Moreover, with Rob latest series, IRQ_DOMAIN will be enabled on every 
ARM platform, so the "depend IRQ_DOMAIN" that "fix" is removing right 
now will have to be added again once we will move that code to use 
genirq domain support.
Again, that seems to be a lot of churn for nothing...

Anyway, I guess it is Tony's call at the end, so I let him decide.

Regards,
Benoit

Re: OMAP34xx

[Russell King - ARM Linux]

On Tue, Feb 07, 2012 at 06:26:52AM +0100, Cousson, Benoit wrote:
> Moreover, with Rob latest series, IRQ_DOMAIN will be enabled on every  
> ARM platform, so the "depend IRQ_DOMAIN" that "fix" is removing right  
> now will have to be added again once we will move that code to use  
> genirq domain support.

Please, get a clue and realise that the current code, even with IRQ_DOMAIN
set, OOPSes on boot, as I've already reported, and as I've now said several
times now.  The code is fucked.  Therefore code needs fixing.

Re: OMAP34xx

[Mark Brown]

On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:

> The twl changes were done like that because it was assuming that
> USE_OF and thus IRQ_DOMAIN will be enabled by default for all OMAP2+
> platforms at 3.3 time.  The whole point of doing that was to reduce
> the ifdefery in every drivers we have to adapt to DT.

Note that those drivers have been buildable on non-OMAP platforms for a
very long time now in order to give better build coverage for the
function drivers.

Re: OMAP34xx

[Tony Lindgren]

* Mark Brown <broonie@opensource.wolfsonmicro.com> [120207 08:57]:
> On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
> 
> > The twl changes were done like that because it was assuming that
> > USE_OF and thus IRQ_DOMAIN will be enabled by default for all OMAP2+
> > platforms at 3.3 time.  The whole point of doing that was to reduce
> > the ifdefery in every drivers we have to adapt to DT.
> 
> Note that those drivers have been buildable on non-OMAP platforms for a
> very long time now in order to give better build coverage for the
> function drivers.

Good point and should be tested too while at it.

Regards,

Tony

Re: OMAP34xx

[Cousson, Benoit]

Hi Mark,

On 2/7/2012 6:28 PM, Mark Brown wrote:
> On Tue, Feb 07, 2012 at 12:19:50AM +0100, Cousson, Benoit wrote:
>
>> The twl changes were done like that because it was assuming that
>> USE_OF and thus IRQ_DOMAIN will be enabled by default for all OMAP2+
>> platforms at 3.3 time.  The whole point of doing that was to reduce
>> the ifdefery in every drivers we have to adapt to DT.
>
> Note that those drivers have been buildable on non-OMAP platforms for a
> very long time now in order to give better build coverage for the
> function drivers.

Yes, sure, but the only restriction I was adding is to make that driver 
dependent of the IRQ_DOMAIN stuff. That should be there by default on 
every ARM platform soon and this is there as well for PPC. So this will 
still be buildable on other platforms assuming they will support IRQ_DOMAIN.

The point is that once we will fully use the irq_domain support to 
generic-chip that Rob is working on for this driver, we will always need 
IRQ_DOMAIN enabled.

So far the IRQ_DOMAIN support is minimal and just needed for DT because 
that piece of infrastructure was not ready at that time.

Regards,
Benoit

Re: OMAP34xx

[Tony Lindgren]

Hi,

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 12:03]:
> 
> Another problem oopses the kernel at boot in the voltage domain code,
> which I suspect this has never been boot tested on OMAP34xx CPUs:
> 
> omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
...
> Backtrace: 
> [<c03db824>] (omap_vp_init+0x0/0x15c) from [<c03db448>] (omap_voltage_late_init+
> 0xc4/0xfc)
> [<c03db384>] (omap_voltage_late_init+0x0/0xfc) from [<c03d9df8>] (omap2_common_p
> m_late_init+0x14/0x54)
>  r8:00000000 r7:00000013 r6:c0039988 r5:c03fe004 r4:c03fdfb8
> [<c03d9de4>] (omap2_common_pm_late_init+0x0/0x54) from [<c0008798>] (do_one_init
> call+0x9c/0x164)
> [<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03d1284>] (kernel_init+0x7c/0x1
> 20)
> [<c03d1208>] (kernel_init+0x0/0x120) from [<c0039988>] (do_exit+0x0/0x2cc)
>  r5:c03d1208 r4:00000000
...

> And OMAP4 doesn't build.  Fixing the build error in prm44xx.c (which is
> virtually the same as the OMAP3 build error in its prm file) gets us to
> a buildable state, but... it silently fails to boot.
> 
> arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)
> 
> At least enabling DEBUG_LL gets this reason:
> 
> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 
...
> Backtrace:                                                                      
> [<c007bab4>] (irq_domain_add+0x0/0x134) from [<c029baac>] (twl_probe+0xd0/0x370)
>  r6:c03bef90 r5:00000014 r4:00000170                                            
> [<c029b9dc>] (twl_probe+0x0/0x370) from [<c01eee70>] (i2c_device_probe+0xb0/0xe4
> )                                                                               
> [<c01eedc0>] (i2c_device_probe+0x0/0xe4) from [<c01d1f34>] (really_probe+0xa0/0x
> 178)                                                                            
...

Just to verify, it seems that both of these happen because of
IRQ_DOMAIN not being set?

And that causes twl-core to not get built as drivers/mfd/Kconfig wrongly
depends on IRQ_DOMAIN that only gets currently selected with OF..

So I assume the patch you posted at [1] fixes both of the above?

Regards,

Tony


[1] http://marc.info/?l=linuxppc-embedded&m=132839494214427&w=2

Re: OMAP34xx

[Russell King - ARM Linux]

On Sat, Feb 04, 2012 at 05:55:30PM -0800, Tony Lindgren wrote:
> Hi,
> 
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 12:03]:
> > 
> > Another problem oopses the kernel at boot in the voltage domain code,
> > which I suspect this has never been boot tested on OMAP34xx CPUs:
> > 
> > omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
> > Unable to handle kernel NULL pointer dereference at virtual address 00000000
> ...
> > Backtrace: 
> > [<c03db824>] (omap_vp_init+0x0/0x15c) from [<c03db448>] (omap_voltage_late_init+
> > 0xc4/0xfc)
> > [<c03db384>] (omap_voltage_late_init+0x0/0xfc) from [<c03d9df8>] (omap2_common_p
> > m_late_init+0x14/0x54)
> >  r8:00000000 r7:00000013 r6:c0039988 r5:c03fe004 r4:c03fdfb8
> > [<c03d9de4>] (omap2_common_pm_late_init+0x0/0x54) from [<c0008798>] (do_one_init
> > call+0x9c/0x164)
> > [<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03d1284>] (kernel_init+0x7c/0x1
> > 20)
> > [<c03d1208>] (kernel_init+0x0/0x120) from [<c0039988>] (do_exit+0x0/0x2cc)
> >  r5:c03d1208 r4:00000000
> ...
> 
> > And OMAP4 doesn't build.  Fixing the build error in prm44xx.c (which is
> > virtually the same as the OMAP3 build error in its prm file) gets us to
> > a buildable state, but... it silently fails to boot.
> > 
> > arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)
> > 
> > At least enabling DEBUG_LL gets this reason:
> > 
> > <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 
> ...
> > Backtrace:                                                                      
> > [<c007bab4>] (irq_domain_add+0x0/0x134) from [<c029baac>] (twl_probe+0xd0/0x370)
> >  r6:c03bef90 r5:00000014 r4:00000170                                            
> > [<c029b9dc>] (twl_probe+0x0/0x370) from [<c01eee70>] (i2c_device_probe+0xb0/0xe4
> > )                                                                               
> > [<c01eedc0>] (i2c_device_probe+0x0/0xe4) from [<c01d1f34>] (really_probe+0xa0/0x
> > 178)                                                                            
> ...
> 
> Just to verify, it seems that both of these happen because of
> IRQ_DOMAIN not being set?

No.  The OMAP3 boot oops is partly because of that rubbish dependency
preventing the PMIC support code being build, but that is only part of
the problem and therefore that patch is only _part_ of the solution.

It's clearly a legal configuration for the TWL support to be disabled,
and the kernel should NOT oops on boot because of that.  So even though
removing the IRQ_DOMAIN dependency _and_ enabling the driver makes the
oops go away, that's _really_ not a fix by any shape or form.

Code should _never_ oops because something isn't built-in that's required.
The vc layer of the voltage domain cope with the missing pmic, and so
should the vp layer.

As for OMAP4, in no way does that patch fix the problem there, because
OMAP4 has the GIC, and the GIC selects CONFIG_IRQ_DOMAIN.  The problem is
much more fundamental, and of course the code reveals why:

drivers/mfd/twl-core.c:
        domain.irq_base = pdata->irq_base;
        domain.nr_irq = nr_irqs;
#ifdef CONFIG_OF_IRQ
        domain.of_node = of_node_get(node);
        domain.ops = &irq_domain_simple_ops;
#endif
        irq_domain_add(&domain);

kernel/irq/irqdomain.c:
void irq_domain_add(struct irq_domain *domain)
{
        irq_domain_for_each_irq(domain, hwirq, irq) {

include/linux/irqdomain.h:
#define irq_domain_for_each_irq(d, hw, irq) \
        for (hw = d->hwirq_base, irq = irq_domain_to_irq(d, hw); \
             hw < d->hwirq_base + d->nr_irq; \
             hw++, irq = irq_domain_to_irq(d, hw))

static inline unsigned int irq_domain_to_irq(struct irq_domain *d,
                                             unsigned long hwirq)
{
        if (d->ops->to_irq)
                return d->ops->to_irq(d, hwirq);

Basically, the irq domain ops pointer _must_ _always_ be a valid pointer
before an irq domain is added.

At a guess, twl-core.c should be:

drivers/mfd/twl-core.c:
#ifdef CONFIG_IRQ_DOMAIN
        domain.irq_base = pdata->irq_base;
        domain.nr_irq = nr_irqs;
#ifdef CONFIG_OF_IRQ
        domain.of_node = of_node_get(node);
#endif
        domain.ops = &irq_domain_simple_ops;
        irq_domain_add(&domain);
#endif

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 02:39]:
> On Sat, Feb 04, 2012 at 05:55:30PM -0800, Tony Lindgren wrote:
> > Hi,
> > 
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 12:03]:
> > > 
> > > Another problem oopses the kernel at boot in the voltage domain code,
> > > which I suspect this has never been boot tested on OMAP34xx CPUs:
> > > 
> > > omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
> > > Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > ...
> > > Backtrace: 
> > > [<c03db824>] (omap_vp_init+0x0/0x15c) from [<c03db448>] (omap_voltage_late_init+
> > > 0xc4/0xfc)
> > > [<c03db384>] (omap_voltage_late_init+0x0/0xfc) from [<c03d9df8>] (omap2_common_p
> > > m_late_init+0x14/0x54)
> > >  r8:00000000 r7:00000013 r6:c0039988 r5:c03fe004 r4:c03fdfb8
> > > [<c03d9de4>] (omap2_common_pm_late_init+0x0/0x54) from [<c0008798>] (do_one_init
> > > call+0x9c/0x164)
> > > [<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03d1284>] (kernel_init+0x7c/0x1
> > > 20)
> > > [<c03d1208>] (kernel_init+0x0/0x120) from [<c0039988>] (do_exit+0x0/0x2cc)
> > >  r5:c03d1208 r4:00000000
> > ...
> > 
> > > And OMAP4 doesn't build.  Fixing the build error in prm44xx.c (which is
> > > virtually the same as the OMAP3 build error in its prm file) gets us to
> > > a buildable state, but... it silently fails to boot.
> > > 
> > > arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)
> > > 
> > > At least enabling DEBUG_LL gets this reason:
> > > 
> > > <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 
> > ...
> > > Backtrace:                                                                      
> > > [<c007bab4>] (irq_domain_add+0x0/0x134) from [<c029baac>] (twl_probe+0xd0/0x370)
> > >  r6:c03bef90 r5:00000014 r4:00000170                                            
> > > [<c029b9dc>] (twl_probe+0x0/0x370) from [<c01eee70>] (i2c_device_probe+0xb0/0xe4
> > > )                                                                               
> > > [<c01eedc0>] (i2c_device_probe+0x0/0xe4) from [<c01d1f34>] (really_probe+0xa0/0x
> > > 178)                                                                            
> > ...
> > 
> > Just to verify, it seems that both of these happen because of
> > IRQ_DOMAIN not being set?
> 
> No.  The OMAP3 boot oops is partly because of that rubbish dependency
> preventing the PMIC support code being build, but that is only part of
> the problem and therefore that patch is only _part_ of the solution.

OK
 
> It's clearly a legal configuration for the TWL support to be disabled,
> and the kernel should NOT oops on boot because of that.  So even though
> removing the IRQ_DOMAIN dependency _and_ enabling the driver makes the
> oops go away, that's _really_ not a fix by any shape or form.
> 
> Code should _never_ oops because something isn't built-in that's required.
> The vc layer of the voltage domain cope with the missing pmic, and so
> should the vp layer.

Agreed. The TWL support be optional. It is possible to have a some non-TWL/TPS
PMIC: For example Nokia n8x0 were using retu/tahvo instead of TPS PMIC.
 
> As for OMAP4, in no way does that patch fix the problem there, because
> OMAP4 has the GIC, and the GIC selects CONFIG_IRQ_DOMAIN.  The problem is
> much more fundamental, and of course the code reveals why:
> 
> drivers/mfd/twl-core.c:
>         domain.irq_base = pdata->irq_base;
>         domain.nr_irq = nr_irqs;
> #ifdef CONFIG_OF_IRQ
>         domain.of_node = of_node_get(node);
>         domain.ops = &irq_domain_simple_ops;
> #endif
>         irq_domain_add(&domain);
> 
> kernel/irq/irqdomain.c:
> void irq_domain_add(struct irq_domain *domain)
> {
>         irq_domain_for_each_irq(domain, hwirq, irq) {
> 
> include/linux/irqdomain.h:
> #define irq_domain_for_each_irq(d, hw, irq) \
>         for (hw = d->hwirq_base, irq = irq_domain_to_irq(d, hw); \
>              hw < d->hwirq_base + d->nr_irq; \
>              hw++, irq = irq_domain_to_irq(d, hw))
> 
> static inline unsigned int irq_domain_to_irq(struct irq_domain *d,
>                                              unsigned long hwirq)
> {
>         if (d->ops->to_irq)
>                 return d->ops->to_irq(d, hwirq);
> 
> Basically, the irq domain ops pointer _must_ _always_ be a valid pointer
> before an irq domain is added.
> 
> At a guess, twl-core.c should be:
> 
> drivers/mfd/twl-core.c:
> #ifdef CONFIG_IRQ_DOMAIN
>         domain.irq_base = pdata->irq_base;
>         domain.nr_irq = nr_irqs;
> #ifdef CONFIG_OF_IRQ
>         domain.of_node = of_node_get(node);
> #endif
>         domain.ops = &irq_domain_simple_ops;
>         irq_domain_add(&domain);
> #endif

OK makes sense.

Regards,

Tony

Re: OMAP34xx

[Russell King - ARM Linux]

And here's another (set of) problem(s) on the 4430SDP board once the
previous have been worked around:

omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.                       
omap_hwmod: ipu: failed to hardreset                                            
omap_hwmod: mcpdm: cannot be enabled (3)                                        
...
machine_constraints_voltage: VUSB: failed to apply 3300000uV constraint         
...
twl_reg twl_reg.46: can't register VUSB, -22                                    
twl_reg: probe of twl_reg.46 failed with error -22                              
...
omap_vc_i2c_init: I2C config for all channels must match.
omap_vc_i2c_init: I2C config for all channels must match.
Power Management for TI OMAP4.
clock: disabling unused clocks to save power
omapfb omapfb: no driver for display: lcd
omapfb omapfb: no driver for display: lcd2
Failed to set PHY power mode to 1
omapdss HDMI error: failed to power on device
------------[ cut here ]------------
WARNING: at /home/rmk/git/linux-omap/arch/arm/mach-omap2/omap_hwmod.c:1604 _idle
+0x34/0xc8()
omap_hwmod: dss_hdmi: idle state can only be entered from enabled state
Modules linked in:
Backtrace:
[<c0017cb0>] (dump_backtrace+0x0/0x10c) from [<c02bdb98>] (dump_stack+0x18/0x1c)
 r7:df6d7d28 r6:c0023e4c r5:c034973d r4:00000644
[<c02bdb80>] (dump_stack+0x0/0x1c) from [<c003448c>] (warn_slowpath_common+0x58/0x70)
[<c0034434>] (warn_slowpath_common+0x0/0x70) from [<c0034548>] (warn_slowpath_fmt+0x38/0x40)
 r8:00000000 r7:00000000 r6:c03e0b90 r5:a0000113 r4:c03e0b90
[<c0034510>] (warn_slowpath_fmt+0x0/0x40) from [<c0023e4c>] (_idle+0x34/0xc8)
 r3:c03496af r2:c0349a89
[<c0023e18>] (_idle+0x0/0xc8) from [<c0024a0c>] (omap_hwmod_idle+0x34/0x48)
mmc0: Voltage range not supported for power class.
mmc0: power class selection to bus width 8 failed
mmc0: new high speed MMC card at address 0001
mmcblk0: mmc0:0001 SEM08G 7.39 GiB
mmcblk0boot0: mmc0:0001 SEM08G partition 1 1.00 MiB
mmcblk0boot1: mmc0:0001 SEM08G partition 2 1.00 MiB
 mmcblk0: unknown partition table
 r4:c03e0be0
[<c00249d8>] (omap_hwmod_idle+0x0/0x48) from [<c00304a8>] (omap_device_idle_hwmods+0x24/0x3c)
 r6:df51f200 r5:df51f180 r4:00000000
[<c0030484>] (omap_device_idle_hwmods+0x0/0x3c) from [<c003069c>] (_omap_device_deactivate+0x5c/0x134)
 r5:df51f200 r4:df51f180
[<c0030640>] (_omap_device_deactivate+0x0/0x134) from [<c00307c0>] (omap_device_idle+0x4c/0x60)
[<c0030774>] (omap_device_idle+0x0/0x60) from [<c00307f8>] (_od_runtime_suspend+0x24/0x2c)
 r4:00000000
[<c00307d4>] (_od_runtime_suspend+0x0/0x2c) from [<c01f6aac>] (__rpm_callback+0x60/0x88)
 r5:00000000 r4:df515408
[<c01f6a4c>] (__rpm_callback+0x0/0x88) from [<c01f7134>] (rpm_suspend+0x3dc/0x644)
 r5:00000000 r4:00000000
[<c01f6d58>] (rpm_suspend+0x0/0x644) from [<c01f841c>] (__pm_runtime_suspend+0x64/0x7c)
[<c01f83b8>] (__pm_runtime_suspend+0x0/0x7c) from [<c01f3744>] (pm_generic_runtime_idle+0x50/0x58)
 r7:c082f300 r6:00000002 r5:00000000 r4:df515408
[<c01f36f4>] (pm_generic_runtime_idle+0x0/0x58) from [<c0030060>] (_od_runtime_idle+0x10/0x14)
 r4:df515408
[<c0030050>] (_od_runtime_idle+0x0/0x14) from [<c01f6aac>] (__rpm_callback+0x60/0x88)
[<c01f6a4c>] (__rpm_callback+0x0/0x88) from [<c01f7560>] (rpm_idle+0x14c/0x180)
 r5:00000000 r4:df515408
[<c01f7414>] (rpm_idle+0x0/0x180) from [<c01f836c>] (pm_runtime_work+0x68/0xb4)
 r6:00000004 r5:df500540 r4:df515408
[<c01f8304>] (pm_runtime_work+0x0/0xb4) from [<c0049430>] (process_one_work+0x264/0x3bc)
 r4:df5154ac
[<c00491cc>] (process_one_work+0x0/0x3bc) from [<c00499b4>] (worker_thread+0x234
/0x41c)
[<c0049780>] (worker_thread+0x0/0x41c) from [<c005000c>] (kthread+0x8c/0x98)
[<c004ff80>] (kthread+0x0/0x98) from [<c0038828>] (do_exit+0x0/0x2ec)
 r7:00000013 r6:c0038828 r5:c004ff80 r4:df45feb0
---[ end trace 0614d9210f06d794 ]---

Re: OMAP34xx

[Russell King - ARM Linux]

On Sun, Feb 05, 2012 at 12:56:26PM +0000, Russell King - ARM Linux wrote:
> And here's another (set of) problem(s) on the 4430SDP board once the
> previous have been worked around:
> 
> omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
> omap_hwmod: ipu: failed to hardreset
> omap_hwmod: mcpdm: cannot be enabled (3)
> ...
> machine_constraints_voltage: VUSB: failed to apply 3300000uV constraint
> ...
> twl_reg twl_reg.46: can't register VUSB, -22
> twl_reg: probe of twl_reg.46 failed with error -22
> ...
> omap_vc_i2c_init: I2C config for all channels must match.
> omap_vc_i2c_init: I2C config for all channels must match.

Fixing this error message to provide something useful allows this problem
to be diagnosed.

omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).

Let's look at the PMIC data for OMAP4:

static struct omap_voltdm_pmic omap3_mpu_pmic = {
        .i2c_high_speed            = true,
static struct omap_voltdm_pmic omap3_core_pmic = {
        .i2c_high_speed            = true,
static struct omap_voltdm_pmic omap4_mpu_pmic = {
        .i2c_high_speed            = true,
static struct omap_voltdm_pmic omap4_iva_pmic = {
        .i2c_high_speed            = true,
static struct omap_voltdm_pmic omap4_core_pmic = {

So, OMAP4's PMIC information for the core domain does not have I2C high
speed set, yet the others do.  So if this is an illegal configuration
then the TWL data is plainly wrong.  If it's a legal configuration, the
voltage domain code is talking utter crap about requiring all these to
match.  They can't both be right.

Has this code been tested on OMAP4 platforms?  I think not (or if it
was, it was done blindly without regard for the messages the kernel
was spitting out - again, that's a failing of people to properly test
their code _before_ sending it upstream.)

> Power Management for TI OMAP4.
> clock: disabling unused clocks to save power
> omapfb omapfb: no driver for display: lcd
> omapfb omapfb: no driver for display: lcd2

Okay, so this requires backlight support, and TAAL selected, so that sorts
that error, but causes others:

taal display0: taal panel revision e3.83.7d
omapdss DSI error: DSI CIO error, cio irqstatus 200000
DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
omapdss DSI error: DSI CIO error, cio irqstatus 200000
DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
omapdss DSI error: DSI CIO error, cio irqstatus 200000
DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
omapdss DSI error: DSI CIO error, cio irqstatus 200000
DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
omapdss DSI error: DSI CIO error, cio irqstatus 200000
DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
omapdss DSI error: DSI CIO error, cio irqstatus 200000
DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1

> Failed to set PHY power mode to 1
> omapdss HDMI error: failed to power on device

For some reason, enabling TAAL fixes this HDMI error.  Why I don't
understand but it's very very counter intuitive.

> ------------[ cut here ]------------
> WARNING: at /home/rmk/git/linux-omap/arch/arm/mach-omap2/omap_hwmod.c:1604 _idle+0x34/0xc8()
> omap_hwmod: dss_hdmi: idle state can only be entered from enabled state

This message doesn't exist in the kernel source as far as I can find.
Ah, yes it does, someone well wrapped the message.

                WARN(1, "omap_hwmod: %s: idle state can only be entered from "
                     "enabled state\n", oh->name);

So that goes into my patch of omap fixes.  There's others in that file
which will get the same treatment.

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 06:07]:
> On Sun, Feb 05, 2012 at 12:56:26PM +0000, Russell King - ARM Linux wrote:
> > And here's another (set of) problem(s) on the 4430SDP board once the
> > previous have been worked around:
> > 
> > omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
> > omap_hwmod: ipu: failed to hardreset
> > omap_hwmod: mcpdm: cannot be enabled (3)
> > ...
> > machine_constraints_voltage: VUSB: failed to apply 3300000uV constraint
> > ...
> > twl_reg twl_reg.46: can't register VUSB, -22
> > twl_reg: probe of twl_reg.46 failed with error -22
> > ...
> > omap_vc_i2c_init: I2C config for all channels must match.
> > omap_vc_i2c_init: I2C config for all channels must match.
> 
> Fixing this error message to provide something useful allows this problem
> to be diagnosed.
> 
> omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
> omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).
> 
> Let's look at the PMIC data for OMAP4:
> 
> static struct omap_voltdm_pmic omap3_mpu_pmic = {
>         .i2c_high_speed            = true,
> static struct omap_voltdm_pmic omap3_core_pmic = {
>         .i2c_high_speed            = true,
> static struct omap_voltdm_pmic omap4_mpu_pmic = {
>         .i2c_high_speed            = true,
> static struct omap_voltdm_pmic omap4_iva_pmic = {
>         .i2c_high_speed            = true,
> static struct omap_voltdm_pmic omap4_core_pmic = {
> 
> So, OMAP4's PMIC information for the core domain does not have I2C high
> speed set, yet the others do.  So if this is an illegal configuration
> then the TWL data is plainly wrong.  If it's a legal configuration, the
> voltage domain code is talking utter crap about requiring all these to
> match.  They can't both be right.

Indeed.
 
> Has this code been tested on OMAP4 platforms?  I think not (or if it
> was, it was done blindly without regard for the messages the kernel
> was spitting out - again, that's a failing of people to properly test
> their code _before_ sending it upstream.)

Let's let Kevin investigate this one.
 
> > Power Management for TI OMAP4.
> > clock: disabling unused clocks to save power
> > omapfb omapfb: no driver for display: lcd
> > omapfb omapfb: no driver for display: lcd2
> 
> Okay, so this requires backlight support, and TAAL selected, so that sorts
> that error, but causes others:
> 
> taal display0: taal panel revision e3.83.7d
> omapdss DSI error: DSI CIO error, cio irqstatus 200000
> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> omapdss DSI error: DSI CIO error, cio irqstatus 200000
> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> omapdss DSI error: DSI CIO error, cio irqstatus 200000
> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> omapdss DSI error: DSI CIO error, cio irqstatus 200000
> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> omapdss DSI error: DSI CIO error, cio irqstatus 200000
> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> omapdss DSI error: DSI CIO error, cio irqstatus 200000
> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> 
> > Failed to set PHY power mode to 1
> > omapdss HDMI error: failed to power on device
> 
> For some reason, enabling TAAL fixes this HDMI error.  Why I don't
> understand but it's very very counter intuitive.

Let's let Tomi investigate this one.
 
> > ------------[ cut here ]------------
> > WARNING: at /home/rmk/git/linux-omap/arch/arm/mach-omap2/omap_hwmod.c:1604 _idle+0x34/0xc8()
> > omap_hwmod: dss_hdmi: idle state can only be entered from enabled state
> 
> This message doesn't exist in the kernel source as far as I can find.
> Ah, yes it does, someone well wrapped the message.
> 
>                 WARN(1, "omap_hwmod: %s: idle state can only be entered from "
>                      "enabled state\n", oh->name);
> 
> So that goes into my patch of omap fixes.  There's others in that file
> which will get the same treatment.

This is not a fix, this should queued for the next merge window
as clean-up.

Regards,

Tony

Re: OMAP34xx

[Russell King - ARM Linux]

On Sun, Feb 05, 2012 at 09:40:37AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 06:07]:
> > On Sun, Feb 05, 2012 at 12:56:26PM +0000, Russell King - ARM Linux wrote:
> > > And here's another (set of) problem(s) on the 4430SDP board once the
> > > previous have been worked around:
> > > 
> > > omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
> > > omap_hwmod: ipu: failed to hardreset
> > > omap_hwmod: mcpdm: cannot be enabled (3)
> > > ...
> > > machine_constraints_voltage: VUSB: failed to apply 3300000uV constraint
> > > ...
> > > twl_reg twl_reg.46: can't register VUSB, -22
> > > twl_reg: probe of twl_reg.46 failed with error -22
> > > ...
> > > omap_vc_i2c_init: I2C config for all channels must match.
> > > omap_vc_i2c_init: I2C config for all channels must match.
> > 
> > Fixing this error message to provide something useful allows this problem
> > to be diagnosed.
> > 
> > omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
> > omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).
> > 
> > Let's look at the PMIC data for OMAP4:
> > 
> > static struct omap_voltdm_pmic omap3_mpu_pmic = {
> >         .i2c_high_speed            = true,
> > static struct omap_voltdm_pmic omap3_core_pmic = {
> >         .i2c_high_speed            = true,
> > static struct omap_voltdm_pmic omap4_mpu_pmic = {
> >         .i2c_high_speed            = true,
> > static struct omap_voltdm_pmic omap4_iva_pmic = {
> >         .i2c_high_speed            = true,
> > static struct omap_voltdm_pmic omap4_core_pmic = {
> > 
> > So, OMAP4's PMIC information for the core domain does not have I2C high
> > speed set, yet the others do.  So if this is an illegal configuration
> > then the TWL data is plainly wrong.  If it's a legal configuration, the
> > voltage domain code is talking utter crap about requiring all these to
> > match.  They can't both be right.
> 
> Indeed.
>  
> > Has this code been tested on OMAP4 platforms?  I think not (or if it
> > was, it was done blindly without regard for the messages the kernel
> > was spitting out - again, that's a failing of people to properly test
> > their code _before_ sending it upstream.)
> 
> Let's let Kevin investigate this one.
>  
> > > Power Management for TI OMAP4.
> > > clock: disabling unused clocks to save power
> > > omapfb omapfb: no driver for display: lcd
> > > omapfb omapfb: no driver for display: lcd2
> > 
> > Okay, so this requires backlight support, and TAAL selected, so that sorts
> > that error, but causes others:
> > 
> > taal display0: taal panel revision e3.83.7d
> > omapdss DSI error: DSI CIO error, cio irqstatus 200000
> > DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> > omapdss DSI error: DSI CIO error, cio irqstatus 200000
> > DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> > omapdss DSI error: DSI CIO error, cio irqstatus 200000
> > DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> > omapdss DSI error: DSI CIO error, cio irqstatus 200000
> > DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> > omapdss DSI error: DSI CIO error, cio irqstatus 200000
> > DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> > omapdss DSI error: DSI CIO error, cio irqstatus 200000
> > DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> > 
> > > Failed to set PHY power mode to 1
> > > omapdss HDMI error: failed to power on device
> > 
> > For some reason, enabling TAAL fixes this HDMI error.  Why I don't
> > understand but it's very very counter intuitive.
> 
> Let's let Tomi investigate this one.
>  
> > > ------------[ cut here ]------------
> > > WARNING: at /home/rmk/git/linux-omap/arch/arm/mach-omap2/omap_hwmod.c:1604 _idle+0x34/0xc8()
> > > omap_hwmod: dss_hdmi: idle state can only be entered from enabled state
> > 
> > This message doesn't exist in the kernel source as far as I can find.
> > Ah, yes it does, someone well wrapped the message.
> > 
> >                 WARN(1, "omap_hwmod: %s: idle state can only be entered from "
> >                      "enabled state\n", oh->name);
> > 
> > So that goes into my patch of omap fixes.  There's others in that file
> > which will get the same treatment.
> 
> This is not a fix, this should queued for the next merge window
> as clean-up.

I would much rather have your agreement, but at the moment given the
(yet again) poor state of OMAP, I'm not inclined to allow this to be
pushed into the next merge window.

And if that means I have to apply it to my tree in the fixes branch,
that's what I'll do.

The fact is that because of the wrapping, the message is difficult to
find, and that's good enough justification for me to put it in my fixes
branch.

In fact, I'll even send it as a plain patch to Linus so he can see it
for what it is and decide whether _he_ wants to apply it, and I believe
he will apply it without any questions.

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 09:34]:
> On Sun, Feb 05, 2012 at 09:40:37AM -0800, Tony Lindgren wrote:
> >  
> > > > ------------[ cut here ]------------
> > > > WARNING: at /home/rmk/git/linux-omap/arch/arm/mach-omap2/omap_hwmod.c:1604 _idle+0x34/0xc8()
> > > > omap_hwmod: dss_hdmi: idle state can only be entered from enabled state
> > > 
> > > This message doesn't exist in the kernel source as far as I can find.
> > > Ah, yes it does, someone well wrapped the message.
> > > 
> > >                 WARN(1, "omap_hwmod: %s: idle state can only be entered from "
> > >                      "enabled state\n", oh->name);
> > > 
> > > So that goes into my patch of omap fixes.  There's others in that file
> > > which will get the same treatment.
> > 
> > This is not a fix, this should queued for the next merge window
> > as clean-up.
> 
> I would much rather have your agreement, but at the moment given the
> (yet again) poor state of OMAP, I'm not inclined to allow this to be
> pushed into the next merge window.

If you stronly think that this is a necessary fix for the -rc cycle,
then I'm fine with it.

What I'd like to see is a series of targeted critical fixes with
descriptions of the .config options case the issues so we can avoid
similar issues in the future.

Then let's have separate clean-up related patches, even if we merge
them too during the -rc cycle. You've probably done this already in
your series, but I have not seen the series yet.
 
> And if that means I have to apply it to my tree in the fixes branch,
> that's what I'll do.

Even if we go that path I should still apply your patches for some
testing. And I'd like to ack the changes, it's a very nice set of
fixes :)
 
> The fact is that because of the wrapping, the message is difficult to
> find, and that's good enough justification for me to put it in my fixes
> branch.
> 
> In fact, I'll even send it as a plain patch to Linus so he can see it
> for what it is and decide whether _he_ wants to apply it, and I believe
> he will apply it without any questions.

Sure if it saves some time finding a critical error, it makes sense.

Cheers,

Tony

Re: OMAP34xx

[Russell King - ARM Linux]

On Sun, Feb 05, 2012 at 10:49:31AM -0800, Tony Lindgren wrote:
> Then let's have separate clean-up related patches, even if we merge
> them too during the -rc cycle. You've probably done this already in
> your series, but I have not seen the series yet.

Actually I don't - what I have is that single (and growing) patch
which you've seen at the moment.  Once I'm happy that it's in a
reasonable state, I'll then see about splitting it up.

Re: OMAP34xx

[Archit Taneja]

Hi,

On Sunday 05 February 2012 08:08 PM, Russell King - ARM Linux wrote:
> On Sun, Feb 05, 2012 at 12:56:26PM +0000, Russell King - ARM Linux wrote:
>> And here's another (set of) problem(s) on the 4430SDP board once the
>> previous have been worked around:
>>
>> omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
>> omap_hwmod: ipu: failed to hardreset
>> omap_hwmod: mcpdm: cannot be enabled (3)
>> ...
>> machine_constraints_voltage: VUSB: failed to apply 3300000uV constraint
>> ...
>> twl_reg twl_reg.46: can't register VUSB, -22
>> twl_reg: probe of twl_reg.46 failed with error -22
>> ...
>> omap_vc_i2c_init: I2C config for all channels must match.
>> omap_vc_i2c_init: I2C config for all channels must match.
>
> Fixing this error message to provide something useful allows this problem
> to be diagnosed.
>
> omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
> omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).
>
> Let's look at the PMIC data for OMAP4:
>
> static struct omap_voltdm_pmic omap3_mpu_pmic = {
>          .i2c_high_speed            = true,
> static struct omap_voltdm_pmic omap3_core_pmic = {
>          .i2c_high_speed            = true,
> static struct omap_voltdm_pmic omap4_mpu_pmic = {
>          .i2c_high_speed            = true,
> static struct omap_voltdm_pmic omap4_iva_pmic = {
>          .i2c_high_speed            = true,
> static struct omap_voltdm_pmic omap4_core_pmic = {
>
> So, OMAP4's PMIC information for the core domain does not have I2C high
> speed set, yet the others do.  So if this is an illegal configuration
> then the TWL data is plainly wrong.  If it's a legal configuration, the
> voltage domain code is talking utter crap about requiring all these to
> match.  They can't both be right.
>
> Has this code been tested on OMAP4 platforms?  I think not (or if it
> was, it was done blindly without regard for the messages the kernel
> was spitting out - again, that's a failing of people to properly test
> their code _before_ sending it upstream.)
>
>> Power Management for TI OMAP4.
>> clock: disabling unused clocks to save power
>> omapfb omapfb: no driver for display: lcd
>> omapfb omapfb: no driver for display: lcd2
>
> Okay, so this requires backlight support, and TAAL selected, so that sorts
> that error, but causes others:
>
> taal display0: taal panel revision e3.83.7d
> omapdss DSI error: DSI CIO error, cio irqstatus 200000
> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> omapdss DSI error: DSI CIO error, cio irqstatus 200000
> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> omapdss DSI error: DSI CIO error, cio irqstatus 200000
> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> omapdss DSI error: DSI CIO error, cio irqstatus 200000
> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> omapdss DSI error: DSI CIO error, cio irqstatus 200000
> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
> omapdss DSI error: DSI CIO error, cio irqstatus 200000
> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1

This happens when the flex cable connected to the display is faulty or 
loose.

>
>> Failed to set PHY power mode to 1
>> omapdss HDMI error: failed to power on device
>
> For some reason, enabling TAAL fixes this HDMI error.  Why I don't
> understand but it's very very counter intuitive.

This was an issue with our driver. I've posted a fix for this.

Thanks,
Archit

>
>> ------------[ cut here ]------------
>> WARNING: at /home/rmk/git/linux-omap/arch/arm/mach-omap2/omap_hwmod.c:1604 _idle+0x34/0xc8()
>> omap_hwmod: dss_hdmi: idle state can only be entered from enabled state
>
> This message doesn't exist in the kernel source as far as I can find.
> Ah, yes it does, someone well wrapped the message.
>
>                  WARN(1, "omap_hwmod: %s: idle state can only be entered from "
>                       "enabled state\n", oh->name);
>
> So that goes into my patch of omap fixes.  There's others in that file
> which will get the same treatment.
> --
> 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: OMAP34xx

[Russell King - ARM Linux]

On Thu, Feb 09, 2012 at 12:22:42PM +0530, Archit Taneja wrote:
> Hi,
>
> On Sunday 05 February 2012 08:08 PM, Russell King - ARM Linux wrote:
>> Okay, so this requires backlight support, and TAAL selected, so that sorts
>> that error, but causes others:
>>
>> taal display0: taal panel revision e3.83.7d
>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>
> This happens when the flex cable connected to the display is faulty or  
> loose.

Well, I don't know - it works with ES1 and an old kernel just fine.

Re: OMAP34xx

[Archit Taneja]

On Friday 10 February 2012 04:04 AM, Russell King - ARM Linux wrote:
> On Thu, Feb 09, 2012 at 12:22:42PM +0530, Archit Taneja wrote:
>> Hi,
>>
>> On Sunday 05 February 2012 08:08 PM, Russell King - ARM Linux wrote:
>>> Okay, so this requires backlight support, and TAAL selected, so that sorts
>>> that error, but causes others:
>>>
>>> taal display0: taal panel revision e3.83.7d
>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>
>> This happens when the flex cable connected to the display is faulty or
>> loose.
>
> Well, I don't know - it works with ES1 and an old kernel just fine.
>

Okay, I'll look into this more.

Thanks,
Archit

Re: OMAP34xx

[Russell King - ARM Linux]

On Fri, Feb 10, 2012 at 11:56:39AM +0530, Archit Taneja wrote:
> On Friday 10 February 2012 04:04 AM, Russell King - ARM Linux wrote:
>> On Thu, Feb 09, 2012 at 12:22:42PM +0530, Archit Taneja wrote:
>>> Hi,
>>>
>>> On Sunday 05 February 2012 08:08 PM, Russell King - ARM Linux wrote:
>>>> Okay, so this requires backlight support, and TAAL selected, so that sorts
>>>> that error, but causes others:
>>>>
>>>> taal display0: taal panel revision e3.83.7d
>>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>>
>>> This happens when the flex cable connected to the display is faulty or
>>> loose.
>>
>> Well, I don't know - it works with ES1 and an old kernel just fine.
>>
>
> Okay, I'll look into this more.

Any news on this?  I see no progress on this in mainline kernels:

http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=112

Yet I can still boot the kernel with the originally provided kernel
and CPU and it all works fine.

Has anyone else tried to get the LCD panels working on the 4430SDP?

Re: OMAP34xx

[Archit Taneja]

Hi,

On Thursday 05 April 2012 01:54 PM, Russell King - ARM Linux wrote:
> On Fri, Feb 10, 2012 at 11:56:39AM +0530, Archit Taneja wrote:
>> On Friday 10 February 2012 04:04 AM, Russell King - ARM Linux wrote:
>>> On Thu, Feb 09, 2012 at 12:22:42PM +0530, Archit Taneja wrote:
>>>> Hi,
>>>>
>>>> On Sunday 05 February 2012 08:08 PM, Russell King - ARM Linux wrote:
>>>>> Okay, so this requires backlight support, and TAAL selected, so that sorts
>>>>> that error, but causes others:
>>>>>
>>>>> taal display0: taal panel revision e3.83.7d
>>>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>>>> omapdss DSI error: DSI CIO error, cio irqstatus 200000
>>>>> DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
>>>>
>>>> This happens when the flex cable connected to the display is faulty or
>>>> loose.
>>>
>>> Well, I don't know - it works with ES1 and an old kernel just fine.
>>>
>>
>> Okay, I'll look into this more.
>
> Any news on this?  I see no progress on this in mainline kernels:
>
> http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=112
>
> Yet I can still boot the kernel with the originally provided kernel
> and CPU and it all works fine.
>
> Has anyone else tried to get the LCD panels working on the 4430SDP?

We figured out the culprit patch, reverting this prevents the issue:

commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237
Author: Archit Taneja <archit@ti.com>
Date:   Fri Oct 7 03:08:44 2011 -0600

     ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields

     Fix the shift and mask macros for DSIx_PPID fields in 
CONTROL_DSIPHY. The
     OMAP4430 Public TRM vV has these fields mentioned correctly.

     Signed-off-by: Archit Taneja <archit@ti.com>
     Acked-by: Benoit Cousson <b-cousson@ti.com>
     Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
     Signed-off-by: Paul Walmsley <paul@pwsan.com>


This was added to be in sync with the register definitions in newer 
OMAP4 TRMs. But it turns out that the newer TRMs might be actually 
messing up the register fields in question.

The DSIx_PPID register fields are responsible for the pull up/down of 
the DSI lanes. Some SDP versions may already have enough pull up to make 
the panels work, and others might not. We get the contention errors on 
these SDP boards as we don't configure the lanes as pull up.

We were trying to verify from the TRM maintainers if this was a TRM 
mistake, if so, reverting the patch would be the right way to go. We 
haven't got a response, so I'll probe the voltage of DSI lanes on a 
board which gives these errors so that we have enough proof.

Archit

>

Re: OMAP34xx

[Russell King - ARM Linux]

On Thu, Apr 05, 2012 at 02:04:41PM +0530, Archit Taneja wrote:
> We figured out the culprit patch, reverting this prevents the issue:
>
> commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237
> Author: Archit Taneja <archit@ti.com>
> Date:   Fri Oct 7 03:08:44 2011 -0600
>
>     ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields
>
>     Fix the shift and mask macros for DSIx_PPID fields in  
> CONTROL_DSIPHY. The
>     OMAP4430 Public TRM vV has these fields mentioned correctly.
>
>     Signed-off-by: Archit Taneja <archit@ti.com>
>     Acked-by: Benoit Cousson <b-cousson@ti.com>
>     Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>     Signed-off-by: Paul Walmsley <paul@pwsan.com>
>
>
> This was added to be in sync with the register definitions in newer  
> OMAP4 TRMs. But it turns out that the newer TRMs might be actually  
> messing up the register fields in question.

Okay, I've just tried reverting this commit, and the errors have gone.
However, I still see nothing on either display at boot time - not even
the backlight seems to be on.  Should I see anything on the displays?

Re: OMAP34xx

[Archit Taneja]

On Thursday 05 April 2012 02:19 PM, Russell King - ARM Linux wrote:
> On Thu, Apr 05, 2012 at 02:04:41PM +0530, Archit Taneja wrote:
>> We figured out the culprit patch, reverting this prevents the issue:
>>
>> commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237
>> Author: Archit Taneja<archit@ti.com>
>> Date:   Fri Oct 7 03:08:44 2011 -0600
>>
>>      ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields
>>
>>      Fix the shift and mask macros for DSIx_PPID fields in
>> CONTROL_DSIPHY. The
>>      OMAP4430 Public TRM vV has these fields mentioned correctly.
>>
>>      Signed-off-by: Archit Taneja<archit@ti.com>
>>      Acked-by: Benoit Cousson<b-cousson@ti.com>
>>      Acked-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>>      Signed-off-by: Paul Walmsley<paul@pwsan.com>
>>
>>
>> This was added to be in sync with the register definitions in newer
>> OMAP4 TRMs. But it turns out that the newer TRMs might be actually
>> messing up the register fields in question.
>
> Okay, I've just tried reverting this commit, and the errors have gone.
> However, I still see nothing on either display at boot time - not even
> the backlight seems to be on.  Should I see anything on the displays?

Backlight support isn't there yet because the TWL soultion to use it is 
hacky. However, you should be able to see penguins if you have built-in 
DSS2 in the kernel and enabled the following configs:

CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y

Tomi, Benoit,

I tried to probe the DSI1 lines on a board which we get the errors. The 
register fields DSI1_PPID and DSI2_PPID are definitely swapped in the 
newer OMAP TRMs. I get around 950mV on DSI1's D1+ lane, and if I set the 
corresponding D1+ bit in the DSI2_PPID, the voltage becomes 1.28V, the 
DSI spec says that we need 1.2V when opearting in DSI LP mode.

I'll post a patch which reverts this commit.

Archit

Re: OMAP34xx

[Russell King - ARM Linux]

I'm also getting on the OMAP4430SDP:

Error setting wl12xx data

What a wonderfully descriptive error message.  Not.  What happened to
saying _why_ we couldn't set the data?  As for this:

	platform_device_register(&omap_vwlan_device);

and not checking the return code, I really don't see why anyone bothered
even reporting that wl12xx_set_platform_data() failed... why not just
leave people in the dark over the error...

Right, so, this "error" is happening because the WL12xx driver is not
configured, and from what I can see, the WL12xx is something you'd plug
in to the board instead of the SD card.  So it makes no sense to report
an error for a driver for a bit of hardware which is optional.

So... my patch gets larger and gets this fixed for all platforms in
mach-omap2.

PRCM: failed to allocate irq descs: -12

Does OMAP require sparse IRQ, or is NR_IRQS not set sufficiently high for
OMAP?  I can't work this one out, and it looks like things are missing for
this to even work (did something in plat/irqs.h get missed?)

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 08:54]:
> I'm also getting on the OMAP4430SDP:
> 
> Error setting wl12xx data
> 
> What a wonderfully descriptive error message.  Not.  What happened to
> saying _why_ we couldn't set the data?  As for this:
> 
> 	platform_device_register(&omap_vwlan_device);
> 
> and not checking the return code, I really don't see why anyone bothered
> even reporting that wl12xx_set_platform_data() failed... why not just
> leave people in the dark over the error...
> 
> Right, so, this "error" is happening because the WL12xx driver is not
> configured, and from what I can see, the WL12xx is something you'd plug
> in to the board instead of the SD card.  So it makes no sense to report
> an error for a driver for a bit of hardware which is optional.
> 
> So... my patch gets larger and gets this fixed for all platforms in
> mach-omap2.

That sounds like a good clean-up for next merge window.
 
> PRCM: failed to allocate irq descs: -12
> 
> Does OMAP require sparse IRQ, or is NR_IRQS not set sufficiently high for
> OMAP?  I can't work this one out, and it looks like things are missing for
> this to even work (did something in plat/irqs.h get missed?)

Tero, can you please investigate this?

Regards,

Tony

Re: OMAP34xx

[Russell King - ARM Linux]

On Sun, Feb 05, 2012 at 09:47:00AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 08:54]:
> > I'm also getting on the OMAP4430SDP:
> > 
> > Error setting wl12xx data
> > 
> > What a wonderfully descriptive error message.  Not.  What happened to
> > saying _why_ we couldn't set the data?  As for this:
> > 
> > 	platform_device_register(&omap_vwlan_device);
> > 
> > and not checking the return code, I really don't see why anyone bothered
> > even reporting that wl12xx_set_platform_data() failed... why not just
> > leave people in the dark over the error...
> > 
> > Right, so, this "error" is happening because the WL12xx driver is not
> > configured, and from what I can see, the WL12xx is something you'd plug
> > in to the board instead of the SD card.  So it makes no sense to report
> > an error for a driver for a bit of hardware which is optional.
> > 
> > So... my patch gets larger and gets this fixed for all platforms in
> > mach-omap2.
> 
> That sounds like a good clean-up for next merge window.

So in the meantime, people should put up with the kernel reporting an
"Error" at error-message level at boot time because they didn't configure
something?

No, it needs fixing, because it doesn't justify being an error.  It's
wrong, plain and simple.  Again, if you don't want to send it during
-rc, I'll send it to Linus as a patch for him to decide whether he wants
to take it as -rc material.

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 09:37]:
> On Sun, Feb 05, 2012 at 09:47:00AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 08:54]:
> > > I'm also getting on the OMAP4430SDP:
> > > 
> > > Error setting wl12xx data
> > > 
> > > What a wonderfully descriptive error message.  Not.  What happened to
> > > saying _why_ we couldn't set the data?  As for this:
> > > 
> > > 	platform_device_register(&omap_vwlan_device);
> > > 
> > > and not checking the return code, I really don't see why anyone bothered
> > > even reporting that wl12xx_set_platform_data() failed... why not just
> > > leave people in the dark over the error...
> > > 
> > > Right, so, this "error" is happening because the WL12xx driver is not
> > > configured, and from what I can see, the WL12xx is something you'd plug
> > > in to the board instead of the SD card.  So it makes no sense to report
> > > an error for a driver for a bit of hardware which is optional.
> > > 
> > > So... my patch gets larger and gets this fixed for all platforms in
> > > mach-omap2.
> > 
> > That sounds like a good clean-up for next merge window.
> 
> So in the meantime, people should put up with the kernel reporting an
> "Error" at error-message level at boot time because they didn't configure
> something?
> 
> No, it needs fixing, because it doesn't justify being an error.  It's
> wrong, plain and simple.  Again, if you don't want to send it during
> -rc, I'll send it to Linus as a patch for him to decide whether he wants
> to take it as -rc material.

Hmm, maybe I misunderstood you.

Certainly fixing the "Error" makes sense for -rc, but are also thinking
about adding error checking to all platform_device_register() calls?

Regards,

Tony

Re: OMAP34xx

[Russell King - ARM Linux]

On Sun, Feb 05, 2012 at 10:33:16AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 09:37]:
> > So in the meantime, people should put up with the kernel reporting an
> > "Error" at error-message level at boot time because they didn't configure
> > something?
> > 
> > No, it needs fixing, because it doesn't justify being an error.  It's
> > wrong, plain and simple.  Again, if you don't want to send it during
> > -rc, I'll send it to Linus as a patch for him to decide whether he wants
> > to take it as -rc material.
> 
> Hmm, maybe I misunderstood you.
> 
> Certainly fixing the "Error" makes sense for -rc, but are also thinking
> about adding error checking to all platform_device_register() calls?

I do think they're valid for -rc, because should it fail, things won't
work as one desires.

I did stop short of fixing it properly - and by "properly" I mean that
if we fail to register the platform data for the device, then we should
not register the device itself.  That involves a change of behaviour in
the setup of the system which _might_ cause a regression.

Whereas, merely printing an error for a failure to register a device
wouldn't be a regression (it might uncover another error, but that's
arguably a good thing.)

The last bit of "properly" which needs discussion is concerning whether
we should even be trying to register this devices platform data and
device structure if WL12XX_PLATFORM_DATA is not enabled - if this is
not enabled the platform data won't be stored, and presumably the
wireless driver will be missing some vital platform data.

It seems silly to have the device registered without the platform data,
so that if the module is built for the kernel, it could be inserted and
bound to that device...

So even for this apparantly simple looking issue, there's some searching
questions that need answering.

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 10:10]:
> On Sun, Feb 05, 2012 at 10:33:16AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 09:37]:
> > > So in the meantime, people should put up with the kernel reporting an
> > > "Error" at error-message level at boot time because they didn't configure
> > > something?
> > > 
> > > No, it needs fixing, because it doesn't justify being an error.  It's
> > > wrong, plain and simple.  Again, if you don't want to send it during
> > > -rc, I'll send it to Linus as a patch for him to decide whether he wants
> > > to take it as -rc material.
> > 
> > Hmm, maybe I misunderstood you.
> > 
> > Certainly fixing the "Error" makes sense for -rc, but are also thinking
> > about adding error checking to all platform_device_register() calls?
> 
> I do think they're valid for -rc, because should it fail, things won't
> work as one desires.

OK, this easily gets into the area where we might get flames from
Linus like "fixing features during -rc that never worked properly
before"..
 
> I did stop short of fixing it properly - and by "properly" I mean that
> if we fail to register the platform data for the device, then we should
> not register the device itself.  That involves a change of behaviour in
> the setup of the system which _might_ cause a regression.
> 
> Whereas, merely printing an error for a failure to register a device
> wouldn't be a regression (it might uncover another error, but that's
> arguably a good thing.)

OK that sounds safe to me.
 
> The last bit of "properly" which needs discussion is concerning whether
> we should even be trying to register this devices platform data and
> device structure if WL12XX_PLATFORM_DATA is not enabled - if this is
> not enabled the platform data won't be stored, and presumably the
> wireless driver will be missing some vital platform data.

That sounds like the way to go to me.
 
> It seems silly to have the device registered without the platform data,
> so that if the module is built for the kernel, it could be inserted and
> bound to that device...
> 
> So even for this apparantly simple looking issue, there's some searching
> questions that need answering.

I doubt that there's anything else behind it except trying to leave
out some ifdefs.

Regards,

Tony

Re: OMAP34xx

[Russell King - ARM Linux]

On Sun, Feb 05, 2012 at 10:59:40AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 10:10]:
> > On Sun, Feb 05, 2012 at 10:33:16AM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 09:37]:
> > > > So in the meantime, people should put up with the kernel reporting an
> > > > "Error" at error-message level at boot time because they didn't configure
> > > > something?
> > > > 
> > > > No, it needs fixing, because it doesn't justify being an error.  It's
> > > > wrong, plain and simple.  Again, if you don't want to send it during
> > > > -rc, I'll send it to Linus as a patch for him to decide whether he wants
> > > > to take it as -rc material.
> > > 
> > > Hmm, maybe I misunderstood you.
> > > 
> > > Certainly fixing the "Error" makes sense for -rc, but are also thinking
> > > about adding error checking to all platform_device_register() calls?
> > 
> > I do think they're valid for -rc, because should it fail, things won't
> > work as one desires.
> 
> OK, this easily gets into the area where we might get flames from
> Linus like "fixing features during -rc that never worked properly
> before"..

There is a sliding scale of what's acceptable during the -rc.
Certainly this kind of thing would not be welcome during the final
-rc or even the previous -rc, but we're not there yet.

And it's not like it's a feature that never worked.

> I doubt that there's anything else behind it except trying to leave
> out some ifdefs.

I don't think you've properly understood what _should_ be going on
here.  Let me illustrate one possibility of how these code sections
might look:

+static void __init xxx_wl12xx_init(void)
+{
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+       int ret;
+
+       /* WL12xx WLAN Init */
+       ret = wl12xx_set_platform_data(&xxx_wlan_data);
+       if (ret) {
+               pr_err("error setting wl12xx data: %d\n", ret);
+		return;
+	}
+       ret = platform_device_register(&xxx_wlan_regulator);
+       if (ret)
+               pr_err("error registering wl12xx device: %d\n", ret);
+#endif
+}

In that case, the xxx_wlan_regulator device should also be ifdef'd.

In other words, if we fail to setup the platform data, we avoid
registering the device.

But... wait a moment, that device isn't the actual card itself but is a
regulator for the card, and that makes it even less clear whether the
ifdef should include it.  So, maybe this is the proper solution:

+static void __init xxx_wl12xx_init(void)
+{
+       int ret;
+
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+       /* WL12xx WLAN Init */
+       ret = wl12xx_set_platform_data(&xxx_wlan_data);
+       if (ret)
+               pr_err("error setting wl12xx data: %d\n", ret);
+#endif
+       ret = platform_device_register(&xxx_wlan_regulator);
+       if (ret)
+               pr_err("error registering wl12xx device: %d\n", ret);
+}

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 11:40]:
> On Sun, Feb 05, 2012 at 10:59:40AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 10:10]:
> > > On Sun, Feb 05, 2012 at 10:33:16AM -0800, Tony Lindgren wrote:
> > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 09:37]:
> > > > > So in the meantime, people should put up with the kernel reporting an
> > > > > "Error" at error-message level at boot time because they didn't configure
> > > > > something?
> > > > > 
> > > > > No, it needs fixing, because it doesn't justify being an error.  It's
> > > > > wrong, plain and simple.  Again, if you don't want to send it during
> > > > > -rc, I'll send it to Linus as a patch for him to decide whether he wants
> > > > > to take it as -rc material.
> > > > 
> > > > Hmm, maybe I misunderstood you.
> > > > 
> > > > Certainly fixing the "Error" makes sense for -rc, but are also thinking
> > > > about adding error checking to all platform_device_register() calls?
> > > 
> > > I do think they're valid for -rc, because should it fail, things won't
> > > work as one desires.
> > 
> > OK, this easily gets into the area where we might get flames from
> > Linus like "fixing features during -rc that never worked properly
> > before"..
> 
> There is a sliding scale of what's acceptable during the -rc.
> Certainly this kind of thing would not be welcome during the final
> -rc or even the previous -rc, but we're not there yet.
> 
> And it's not like it's a feature that never worked.

Well at least sounds like you have points to argue merging it :)
 
> > I doubt that there's anything else behind it except trying to leave
> > out some ifdefs.
> 
> I don't think you've properly understood what _should_ be going on
> here.  Let me illustrate one possibility of how these code sections
> might look:
> 
> +static void __init xxx_wl12xx_init(void)
> +{
> +#ifdef CONFIG_WL12XX_PLATFORM_DATA
> +       int ret;
> +
> +       /* WL12xx WLAN Init */
> +       ret = wl12xx_set_platform_data(&xxx_wlan_data);
> +       if (ret) {
> +               pr_err("error setting wl12xx data: %d\n", ret);
> +		return;
> +	}
> +       ret = platform_device_register(&xxx_wlan_regulator);
> +       if (ret)
> +               pr_err("error registering wl12xx device: %d\n", ret);
> +#endif
> +}
> 
> In that case, the xxx_wlan_regulator device should also be ifdef'd.
> 
> In other words, if we fail to setup the platform data, we avoid
> registering the device.
> 
> But... wait a moment, that device isn't the actual card itself but is a
> regulator for the card, and that makes it even less clear whether the
> ifdef should include it.  So, maybe this is the proper solution:
> 
> +static void __init xxx_wl12xx_init(void)
> +{
> +       int ret;
> +
> +#ifdef CONFIG_WL12XX_PLATFORM_DATA
> +       /* WL12xx WLAN Init */
> +       ret = wl12xx_set_platform_data(&xxx_wlan_data);
> +       if (ret)
> +               pr_err("error setting wl12xx data: %d\n", ret);
> +#endif
> +       ret = platform_device_register(&xxx_wlan_regulator);
> +       if (ret)
> +               pr_err("error registering wl12xx device: %d\n", ret);
> +}

Hmm I see. Ohad, care to take a look this one?

Regards,

Tony

Re: OMAP34xx

[Ohad Ben-Cohen]

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

On Sun, Feb 5, 2012 at 10:51 PM, Tony Lindgren <tony@atomide.com> wrote:
> Hmm I see. Ohad, care to take a look this one?

All worthy comments, and indeed there's no point in registering the
fixed regulator device in case wl12xx_set_platform_data() fails.

I cooked up something (using wl12xx_set_platform_data()'s -ENOSYS to
avoid ifdef'ing the code) - see below (and attached).

Russell, Tony, please tell me if you want me to cook something similar
for all the other platforms, or would rather use your existing
patch(es).

Thanks,
Ohad.

>From 6bc46ed359c8399a53a9e02bbf8f47b2831dfe0e Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen <ohad@wizery.com>
Date: Mon, 6 Feb 2012 11:53:17 +0200
Subject: [PATCH] ARM: OMAP4: panda: clean up/fix wlan init path

1. Stop intimidating users with scary wlan error messages in case wl12xx
   support wasn't even built.
2. When a wlan init error does happen, provide users with helpful
   information regarding the nature of the failure.
3. Don't bother registering wl12xx's fixed regulator device in case
   wl12xx_set_platform_data() failed.

While we're at it, extract the wlan init code to a dedicated function to
make omap4_panda_init() look a bit nicer.

Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/board-omap4panda.c |   26 ++++++++++++++++++++++----
 1 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 30ad40d..c801e7e 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -475,6 +475,27 @@ void omap4_panda_display_init(void)
 		omap_hdmi_init(0);
 }

+static void __init omap4_panda_wlan_init(void)
+{
+	int ret;
+
+	ret = wl12xx_set_platform_data(&omap_panda_wlan_data);
+
+	/* bail out silently in case wl12xx isn't configured */
+	if (ret == -ENOSYS)
+		return;
+
+	/* bail out verbosely on any other error */
+	if (ret) {
+		pr_err("error setting wl12xx data: %d\n", ret);
+		return;
+	}
+
+	ret = platform_device_register(&omap_vwlan_device);
+	if (ret)
+		pr_err("error registering wl12xx's fixed regulator: %d\n", ret);
+}
+
 static void __init omap4_panda_init(void)
 {
 	int package = OMAP_PACKAGE_CBS;
@@ -483,12 +504,9 @@ static void __init omap4_panda_init(void)
 		package = OMAP_PACKAGE_CBL;
 	omap4_mux_init(board_mux, NULL, package);

-	if (wl12xx_set_platform_data(&omap_panda_wlan_data))
-		pr_err("error setting wl12xx data\n");
-
+	omap4_panda_wlan_init();
 	omap4_panda_i2c_init();
 	platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
-	platform_device_register(&omap_vwlan_device);
 	omap_serial_init();
 	omap_sdrc_init(NULL, NULL);
 	omap4_twl6030_hsmmc_init(mmc);
-- 
1.7.5.4

[-- Attachment #2: 0001-ARM-OMAP4-panda-clean-up-fix-wlan-init-path.patch --]
[-- Type: text/x-patch, Size: 2284 bytes --]

From 6bc46ed359c8399a53a9e02bbf8f47b2831dfe0e Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen <ohad@wizery.com>
Date: Mon, 6 Feb 2012 11:53:17 +0200
Subject: [PATCH] ARM: OMAP4: panda: clean up/fix wlan init path

1. Stop intimidating users with scary wlan error messages in case wl12xx
   support wasn't even built.
2. When a wlan init error does happen, provide users with helpful
   information regarding the nature of the failure.
3. Don't bother registering wl12xx's fixed regulator device in case
   wl12xx_set_platform_data() failed.

While we're at it, extract the wlan init code to a dedicated function to
make omap4_panda_init() look a bit nicer.

Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/board-omap4panda.c |   26 ++++++++++++++++++++++----
 1 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 30ad40d..c801e7e 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -475,6 +475,27 @@ void omap4_panda_display_init(void)
 		omap_hdmi_init(0);
 }
 
+static void __init omap4_panda_wlan_init(void)
+{
+	int ret;
+
+	ret = wl12xx_set_platform_data(&omap_panda_wlan_data);
+
+	/* bail out silently in case wl12xx isn't configured */
+	if (ret == -ENOSYS)
+		return;
+
+	/* bail out verbosely on any other error */
+	if (ret) {
+		pr_err("error setting wl12xx data: %d\n", ret);
+		return;
+	}
+
+	ret = platform_device_register(&omap_vwlan_device);
+	if (ret)
+		pr_err("error registering wl12xx's fixed regulator: %d\n", ret);
+}
+
 static void __init omap4_panda_init(void)
 {
 	int package = OMAP_PACKAGE_CBS;
@@ -483,12 +504,9 @@ static void __init omap4_panda_init(void)
 		package = OMAP_PACKAGE_CBL;
 	omap4_mux_init(board_mux, NULL, package);
 
-	if (wl12xx_set_platform_data(&omap_panda_wlan_data))
-		pr_err("error setting wl12xx data\n");
-
+	omap4_panda_wlan_init();
 	omap4_panda_i2c_init();
 	platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
-	platform_device_register(&omap_vwlan_device);
 	omap_serial_init();
 	omap_sdrc_init(NULL, NULL);
 	omap4_twl6030_hsmmc_init(mmc);
-- 
1.7.5.4

Re: OMAP34xx

[Tero Kristo]

On Sun, 2012-02-05 at 09:47 -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120205 08:54]:
> > I'm also getting on the OMAP4430SDP:
> > 
> > Error setting wl12xx data
> > 
> > What a wonderfully descriptive error message.  Not.  What happened to
> > saying _why_ we couldn't set the data?  As for this:
> > 
> > 	platform_device_register(&omap_vwlan_device);
> > 
> > and not checking the return code, I really don't see why anyone bothered
> > even reporting that wl12xx_set_platform_data() failed... why not just
> > leave people in the dark over the error...
> > 
> > Right, so, this "error" is happening because the WL12xx driver is not
> > configured, and from what I can see, the WL12xx is something you'd plug
> > in to the board instead of the SD card.  So it makes no sense to report
> > an error for a driver for a bit of hardware which is optional.
> > 
> > So... my patch gets larger and gets this fixed for all platforms in
> > mach-omap2.
> 
> That sounds like a good clean-up for next merge window.
>  
> > PRCM: failed to allocate irq descs: -12
> > 
> > Does OMAP require sparse IRQ, or is NR_IRQS not set sufficiently high for
> > OMAP?  I can't work this one out, and it looks like things are missing for
> > this to even work (did something in plat/irqs.h get missed?)
> 
> Tero, can you please investigate this?

Sparse IRQ would be good, PRCM attempts to allocate either 32 or 64
descs based on PRM module revision (omap3 uses 32, omap4+ uses 64.)

Personally I have only seen this error on omap4, but omap4 support is
not fully integrated in mainline yet.

-Tero

Re: OMAP34xx

[Kevin Hilman]

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

[...]

> Another problem oopses the kernel at boot in the voltage domain code,
> which I suspect this has never been boot tested on OMAP34xx CPUs:
>
> omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = c0004000
> [00000000] *pgd=00000000
> Internal error: Oops: 5 [#1] PREEMPT
> Modules linked in:
> CPU: 0    Not tainted  (3.3.0-rc2+ #204)
> PC is at omap_vp_init+0x5c/0x15c
> LR is at omap_vp_init+0x58/0x15c
> pc : [<c03db880>]    lr : [<c03db87c>]    psr: 60000013
> sp : c181ff30  ip : c181ff68  fp : c181ff64
> r10: c0407808  r9 : c040786c  r8 : c0407814
> r7 : c0026868  r6 : c00264fc  r5 : c040ad6c  r4 : 00000000
> r3 : 00000040  r2 : 000032c8  r1 : 0000fa00  r0 : 000032c8
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c5387d  Table: 80004019  DAC: 00000015
> Process swapper (pid: 1, stack limit = 0xc181e2e8)
> Stack: (0xc181ff30 to 0xc1820000)
> ff20:                                     c0381d00 c02e9c6d c0383582 c040786c
> ff40: c040ad6c c00264fc c0026868 c0407814 00000000 c03d9de4 c181ff8c c181ff68
> ff60: c03db448 c03db830 c02e982c c03fdfb8 c03fe004 c0039988 00000013 00000000
> ff80: c181ff9c c181ff90 c03d9df8 c03db390 c181ffdc c181ffa0 c0008798 c03d9df0
> ffa0: c181ffc4 c181ffb0 c0055a44 c0187050 c0039988 c03fdfb8 c03fe004 c0039988
> ffc0: 00000013 00000000 00000000 00000000 c181fff4 c181ffe0 c03d1284 c0008708
> ffe0: 00000000 c03d1208 00000000 c181fff8 c0039988 c03d1214 1077ce40 01f7ee08
> Backtrace: 
> [<c03db824>] (omap_vp_init+0x0/0x15c) from [<c03db448>] (omap_voltage_late_init+
> 0xc4/0xfc)
> [<c03db384>] (omap_voltage_late_init+0x0/0xfc) from [<c03d9df8>] (omap2_common_p
> m_late_init+0x14/0x54)
>  r8:00000000 r7:00000013 r6:c0039988 r5:c03fe004 r4:c03fdfb8
> [<c03d9de4>] (omap2_common_pm_late_init+0x0/0x54) from [<c0008798>] (do_one_init
> call+0x9c/0x164)
> [<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03d1284>] (kernel_init+0x7c/0x1
> 20)
> [<c03d1208>] (kernel_init+0x0/0x120) from [<c0039988>] (do_exit+0x0/0x2cc)
>  r5:c03d1208 r4:00000000
> Code: e5ca300b e5900034 ebf69027 e5994024 (e5941000) 
> ---[ end trace aed617dddaf32c3d ]---
> Kernel panic - not syncing: Attempted to kill init!

FWIW, this problem has been fixed for some time, and in my
for_3.3/cleanup/pm branch (and included in Tony's cleanup branch) which
was supposed to be merged for v3.3.

Kevin

Re: OMAP34xx

[Tony Lindgren]

* Kevin Hilman <khilman@ti.com> [120207 13:38]:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> [...]
> 
> > Another problem oopses the kernel at boot in the voltage domain code,
> > which I suspect this has never been boot tested on OMAP34xx CPUs:
> >
> > omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
> > Unable to handle kernel NULL pointer dereference at virtual address 00000000
...
> > [<c03db824>] (omap_vp_init+0x0/0x15c) from [<c03db448>] (omap_voltage_late_init+
> > 0xc4/0xfc)
...
> 
> FWIW, this problem has been fixed for some time, and in my
> for_3.3/cleanup/pm branch (and included in Tony's cleanup branch) which
> was supposed to be merged for v3.3.

Yes sorry I guess I did not realize it was a fix. This was one of
the three branches that were left out of the last merge window
because it was getting too.

I assume you're talking about commit af9a2ed9667b49e7e125eac526d8f655183ce53e?

Regards,

Tony

Re: OMAP34xx

[Russell King - ARM Linux]

Another issue (through lower priority) is this:

twl-common.c:(.init.text+0x2e48): undefined reference to `omap34xx_vddmpu_volt_data'
twl-common.c:(.init.text+0x2e4c): undefined reference to `omap34xx_vddcore_volt_data'
twl-common.c:(.init.text+0x2e5c): undefined reference to `omap36xx_vddmpu_volt_data'
twl-common.c:(.init.text+0x2e60): undefined reference to `omap36xx_vddcore_volt_data'
twl-common.c:(.init.text+0x2830): undefined reference to `omap44xx_vdd_mpu_volt_data'
twl-common.c:(.init.text+0x283c): undefined reference to `omap44xx_vdd_iva_volt_data'
twl-common.c:(.init.text+0x2844): undefined reference to `omap44xx_vdd_core_volt_data'

produced by the allnoconfig build.

The voltage domain code is always built into the kernel, but it references
the operating point code for the voltage tables.  The voltage tables are
only built in when PM_OPP is enabled.

So, this means that either the voltage tables must always be built in, or
the references need to be surrounded by #ifdef CONFIG_PM_OPP.  The former
can be done in two ways: either move those tables out of opp*.c, or get
rid of PM_OPP entirely as it must always be enabled.

The other allnoconfig issue is:

arch/arm/mach-omap2/built-in.o:(.data+0xa3d0): undefined reference to `omap_i2c_reset'

which looks like hwmod can't cope with the I2C_OMAP being disabled.

I don't propose these are fixed for v3.3, but they certainly should be
fixed for v3.4.

Re: OMAP34xx

[Paul Walmsley]

Hi

On Sun, 12 Feb 2012, Russell King - ARM Linux wrote:

> The other allnoconfig issue is:
> 
> arch/arm/mach-omap2/built-in.o:(.data+0xa3d0): undefined reference to `omap_i2c_reset'
> 
> which looks like hwmod can't cope with the I2C_OMAP being disabled.
> 
> I don't propose these are fixed for v3.3, but they certainly should be
> fixed for v3.4.

Thanks for the report.  Here's a patch for this for 3.4.  Compile-tested 
only; will boot-test it as part of the v2 of the 3.4 hwmod changes.


- Paul

From: Paul Walmsley <paul@pwsan.com>
Date: Sun, 12 Feb 2012 11:49:34 -0700
Subject: [PATCH] ARM: OMAP2+: I2C: always compile I2C reset code, even if I2C
 driver is not built

During kernel init, we reset all IP blocks on the OMAP that we can,
even if there is no driver compiled for that IP block.  Unlike most IP
blocks, the I2C block requires some extra programming for this to
work.  This reset code is incorrectly omitted when the I2C driver is
deselected.  In this circumstance, the build breaks.  Fix by compiling
the I2C reset code unconditionally.

Problem reported by Russell King <linux@arm.linux.org.uk>.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Russell King <linux@arm.linux.org.uk>
---
 arch/arm/mach-omap2/Makefile |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fc9b238..0d5676c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -4,7 +4,7 @@
 
 # Common support
 obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \
-	 common.o gpio.o dma.o wd_timer.o display.o
+	 common.o gpio.o dma.o wd_timer.o display.o i2c.o
 
 omap-2-3-common				= irq.o sdrc.o
 hwmod-common				= omap_hwmod.o \
@@ -182,9 +182,6 @@ obj-$(CONFIG_OMAP_IOMMU)		+= iommu2.o
 iommu-$(CONFIG_OMAP_IOMMU)		:= omap-iommu.o
 obj-y					+= $(iommu-m) $(iommu-y)
 
-i2c-omap-$(CONFIG_I2C_OMAP)		:= i2c.o
-obj-y					+= $(i2c-omap-m) $(i2c-omap-y)
-
 ifneq ($(CONFIG_TIDSPBRIDGE),)
 obj-y					+= dsp.o
 endif
-- 
1.7.9

OMAP34xx

[Paul Walmsley]

Hi

On Sun, 12 Feb 2012, Russell King - ARM Linux wrote:

> The other allnoconfig issue is:
> 
> arch/arm/mach-omap2/built-in.o:(.data+0xa3d0): undefined reference to `omap_i2c_reset'
> 
> which looks like hwmod can't cope with the I2C_OMAP being disabled.
> 
> I don't propose these are fixed for v3.3, but they certainly should be
> fixed for v3.4.

Thanks for the report.  Here's a patch for this for 3.4.  Compile-tested 
only; will boot-test it as part of the v2 of the 3.4 hwmod changes.


- Paul

From: Paul Walmsley <paul@pwsan.com>
Date: Sun, 12 Feb 2012 11:49:34 -0700
Subject: [PATCH] ARM: OMAP2+: I2C: always compile I2C reset code, even if I2C
 driver is not built

During kernel init, we reset all IP blocks on the OMAP that we can,
even if there is no driver compiled for that IP block.  Unlike most IP
blocks, the I2C block requires some extra programming for this to
work.  This reset code is incorrectly omitted when the I2C driver is
deselected.  In this circumstance, the build breaks.  Fix by compiling
the I2C reset code unconditionally.

Problem reported by Russell King <linux@arm.linux.org.uk>.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Russell King <linux@arm.linux.org.uk>
---
 arch/arm/mach-omap2/Makefile |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fc9b238..0d5676c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -4,7 +4,7 @@
 
 # Common support
 obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \
-	 common.o gpio.o dma.o wd_timer.o display.o
+	 common.o gpio.o dma.o wd_timer.o display.o i2c.o
 
 omap-2-3-common				= irq.o sdrc.o
 hwmod-common				= omap_hwmod.o \
@@ -182,9 +182,6 @@ obj-$(CONFIG_OMAP_IOMMU)		+= iommu2.o
 iommu-$(CONFIG_OMAP_IOMMU)		:= omap-iommu.o
 obj-y					+= $(iommu-m) $(iommu-y)
 
-i2c-omap-$(CONFIG_I2C_OMAP)		:= i2c.o
-obj-y					+= $(i2c-omap-m) $(i2c-omap-y)
-
 ifneq ($(CONFIG_TIDSPBRIDGE),)
 obj-y					+= dsp.o
 endif
-- 
1.7.9

Re: OMAP34xx

[Shubhrajyoti]

On Monday 13 February 2012 12:42 AM, Paul Walmsley wrote:
> Hi
>
> On Sun, 12 Feb 2012, Russell King - ARM Linux wrote:
>
>> The other allnoconfig issue is:
>>
>> arch/arm/mach-omap2/built-in.o:(.data+0xa3d0): undefined reference to `omap_i2c_reset'
>>
>> which looks like hwmod can't cope with the I2C_OMAP being disabled.
>>
>> I don't propose these are fixed for v3.3, but they certainly should be
>> fixed for v3.4.
> Thanks for the report.  Here's a patch for this for 3.4.  Compile-tested 
> only; will boot-test it as part of the v2 of the 3.4 hwmod changes.
>
Boot tested on omap4430 sdp.
> - Paul
>
> From: Paul Walmsley <paul@pwsan.com>
> Date: Sun, 12 Feb 2012 11:49:34 -0700
> Subject: [PATCH] ARM: OMAP2+: I2C: always compile I2C reset code, even if I2C
>  driver is not built
>
> During kernel init, we reset all IP blocks on the OMAP that we can,
> even if there is no driver compiled for that IP block.  Unlike most IP
> blocks, the I2C block requires some extra programming for this to
> work.  This reset code is incorrectly omitted when the I2C driver is
> deselected.  In this circumstance, the build breaks.  Fix by compiling
> the I2C reset code unconditionally.
>
> Problem reported by Russell King <linux@arm.linux.org.uk>.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> ---
>  arch/arm/mach-omap2/Makefile |    5 +----
>  1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index fc9b238..0d5676c 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -4,7 +4,7 @@
>  
>  # Common support
>  obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \
> -	 common.o gpio.o dma.o wd_timer.o display.o
> +	 common.o gpio.o dma.o wd_timer.o display.o i2c.o
>  
>  omap-2-3-common				= irq.o sdrc.o
>  hwmod-common				= omap_hwmod.o \
> @@ -182,9 +182,6 @@ obj-$(CONFIG_OMAP_IOMMU)		+= iommu2.o
>  iommu-$(CONFIG_OMAP_IOMMU)		:= omap-iommu.o
>  obj-y					+= $(iommu-m) $(iommu-y)
>  
> -i2c-omap-$(CONFIG_I2C_OMAP)		:= i2c.o
> -obj-y					+= $(i2c-omap-m) $(i2c-omap-y)
> -
>  ifneq ($(CONFIG_TIDSPBRIDGE),)
>  obj-y					+= dsp.o
>  endif

OMAP34xx

[Shubhrajyoti]

On Monday 13 February 2012 12:42 AM, Paul Walmsley wrote:
> Hi
>
> On Sun, 12 Feb 2012, Russell King - ARM Linux wrote:
>
>> The other allnoconfig issue is:
>>
>> arch/arm/mach-omap2/built-in.o:(.data+0xa3d0): undefined reference to `omap_i2c_reset'
>>
>> which looks like hwmod can't cope with the I2C_OMAP being disabled.
>>
>> I don't propose these are fixed for v3.3, but they certainly should be
>> fixed for v3.4.
> Thanks for the report.  Here's a patch for this for 3.4.  Compile-tested 
> only; will boot-test it as part of the v2 of the 3.4 hwmod changes.
>
Boot tested on omap4430 sdp.
> - Paul
>
> From: Paul Walmsley <paul@pwsan.com>
> Date: Sun, 12 Feb 2012 11:49:34 -0700
> Subject: [PATCH] ARM: OMAP2+: I2C: always compile I2C reset code, even if I2C
>  driver is not built
>
> During kernel init, we reset all IP blocks on the OMAP that we can,
> even if there is no driver compiled for that IP block.  Unlike most IP
> blocks, the I2C block requires some extra programming for this to
> work.  This reset code is incorrectly omitted when the I2C driver is
> deselected.  In this circumstance, the build breaks.  Fix by compiling
> the I2C reset code unconditionally.
>
> Problem reported by Russell King <linux@arm.linux.org.uk>.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> ---
>  arch/arm/mach-omap2/Makefile |    5 +----
>  1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index fc9b238..0d5676c 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -4,7 +4,7 @@
>  
>  # Common support
>  obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \
> -	 common.o gpio.o dma.o wd_timer.o display.o
> +	 common.o gpio.o dma.o wd_timer.o display.o i2c.o
>  
>  omap-2-3-common				= irq.o sdrc.o
>  hwmod-common				= omap_hwmod.o \
> @@ -182,9 +182,6 @@ obj-$(CONFIG_OMAP_IOMMU)		+= iommu2.o
>  iommu-$(CONFIG_OMAP_IOMMU)		:= omap-iommu.o
>  obj-y					+= $(iommu-m) $(iommu-y)
>  
> -i2c-omap-$(CONFIG_I2C_OMAP)		:= i2c.o
> -obj-y					+= $(i2c-omap-m) $(i2c-omap-y)
> -
>  ifneq ($(CONFIG_TIDSPBRIDGE),)
>  obj-y					+= dsp.o
>  endif

Re: OMAP34xx

[Paul Walmsley]

On Mon, 13 Feb 2012, Shubhrajyoti wrote:

> Boot tested on omap4430 sdp.

Thanks Shubhrajyoti!  Added your Tested-by.


- Paul

OMAP34xx

[Paul Walmsley]

On Mon, 13 Feb 2012, Shubhrajyoti wrote:

> Boot tested on omap4430 sdp.

Thanks Shubhrajyoti!  Added your Tested-by.


- Paul

Re: OMAP34xx

[Russell King - ARM Linux]

On Sun, Feb 12, 2012 at 10:41:32AM +0000, Russell King - ARM Linux wrote:
> Another issue (through lower priority) is this:
> 
> twl-common.c:(.init.text+0x2e48): undefined reference to `omap34xx_vddmpu_volt_data'
> twl-common.c:(.init.text+0x2e4c): undefined reference to `omap34xx_vddcore_volt_data'
> twl-common.c:(.init.text+0x2e5c): undefined reference to `omap36xx_vddmpu_volt_data'
> twl-common.c:(.init.text+0x2e60): undefined reference to `omap36xx_vddcore_volt_data'
> twl-common.c:(.init.text+0x2830): undefined reference to `omap44xx_vdd_mpu_volt_data'
> twl-common.c:(.init.text+0x283c): undefined reference to `omap44xx_vdd_iva_volt_data'
> twl-common.c:(.init.text+0x2844): undefined reference to `omap44xx_vdd_core_volt_data'
> 
> produced by the allnoconfig build.
> 
> The voltage domain code is always built into the kernel, but it references
> the operating point code for the voltage tables.  The voltage tables are
> only built in when PM_OPP is enabled.
> 
> So, this means that either the voltage tables must always be built in, or
> the references need to be surrounded by #ifdef CONFIG_PM_OPP.  The former
> can be done in two ways: either move those tables out of opp*.c, or get
> rid of PM_OPP entirely as it must always be enabled.

Since no one has picked up on this, here's my current patch for it:

diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
index c005e2f..57db203 100644
--- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
@@ -108,6 +108,7 @@ void __init omap3xxx_voltagedomains_init(void)
 	 * XXX Will depend on the process, validation, and binning
 	 * for the currently-running IC
 	 */
+#ifdef CONFIG_PM_OPP
 	if (cpu_is_omap3630()) {
 		omap3_voltdm_mpu.volt_data = omap36xx_vddmpu_volt_data;
 		omap3_voltdm_core.volt_data = omap36xx_vddcore_volt_data;
@@ -115,6 +116,7 @@ void __init omap3xxx_voltagedomains_init(void)
 		omap3_voltdm_mpu.volt_data = omap34xx_vddmpu_volt_data;
 		omap3_voltdm_core.volt_data = omap34xx_vddcore_volt_data;
 	}
+#endif
 
 	if (cpu_is_omap3517() || cpu_is_omap3505())
 		voltdms = voltagedomains_am35xx;
diff --git a/arch/arm/mach-omap2/voltagedomains44xx_data.c b/arch/arm/mach-omap2/voltagedomains44xx_data.c
index 4e11d02..c3115f6 100644
--- a/arch/arm/mach-omap2/voltagedomains44xx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains44xx_data.c
@@ -100,9 +100,11 @@ void __init omap44xx_voltagedomains_init(void)
 	 * XXX Will depend on the process, validation, and binning
 	 * for the currently-running IC
 	 */
+#ifdef CONFIG_PM_OPP
 	omap4_voltdm_mpu.volt_data = omap44xx_vdd_mpu_volt_data;
 	omap4_voltdm_iva.volt_data = omap44xx_vdd_iva_volt_data;
 	omap4_voltdm_core.volt_data = omap44xx_vdd_core_volt_data;
+#endif
 
 	for (i = 0; voltdm = voltagedomains_omap4[i], voltdm; i++)
 		voltdm->sys_clk.name = sys_clk_name;

Re: OMAP34xx

[Kevin Hilman]

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

> On Sun, Feb 12, 2012 at 10:41:32AM +0000, Russell King - ARM Linux wrote:
>> Another issue (through lower priority) is this:
>> 
>> twl-common.c:(.init.text+0x2e48): undefined reference to `omap34xx_vddmpu_volt_data'
>> twl-common.c:(.init.text+0x2e4c): undefined reference to `omap34xx_vddcore_volt_data'
>> twl-common.c:(.init.text+0x2e5c): undefined reference to `omap36xx_vddmpu_volt_data'
>> twl-common.c:(.init.text+0x2e60): undefined reference to `omap36xx_vddcore_volt_data'
>> twl-common.c:(.init.text+0x2830): undefined reference to `omap44xx_vdd_mpu_volt_data'
>> twl-common.c:(.init.text+0x283c): undefined reference to `omap44xx_vdd_iva_volt_data'
>> twl-common.c:(.init.text+0x2844): undefined reference to `omap44xx_vdd_core_volt_data'
>> 
>> produced by the allnoconfig build.
>> 
>> The voltage domain code is always built into the kernel, but it references
>> the operating point code for the voltage tables.  The voltage tables are
>> only built in when PM_OPP is enabled.
>> 
>> So, this means that either the voltage tables must always be built in, or
>> the references need to be surrounded by #ifdef CONFIG_PM_OPP.  The former
>> can be done in two ways: either move those tables out of opp*.c, or get
>> rid of PM_OPP entirely as it must always be enabled.
>
> Since no one has picked up on this, here's my current patch for it:
>
> diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
> index c005e2f..57db203 100644
> --- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
> +++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
> @@ -108,6 +108,7 @@ void __init omap3xxx_voltagedomains_init(void)
>  	 * XXX Will depend on the process, validation, and binning
>  	 * for the currently-running IC
>  	 */
> +#ifdef CONFIG_PM_OPP
>  	if (cpu_is_omap3630()) {
>  		omap3_voltdm_mpu.volt_data = omap36xx_vddmpu_volt_data;
>  		omap3_voltdm_core.volt_data = omap36xx_vddcore_volt_data;
> @@ -115,6 +116,7 @@ void __init omap3xxx_voltagedomains_init(void)
>  		omap3_voltdm_mpu.volt_data = omap34xx_vddmpu_volt_data;
>  		omap3_voltdm_core.volt_data = omap34xx_vddcore_volt_data;
>  	}
> +#endif
>  
>  	if (cpu_is_omap3517() || cpu_is_omap3505())
>  		voltdms = voltagedomains_am35xx;
> diff --git a/arch/arm/mach-omap2/voltagedomains44xx_data.c b/arch/arm/mach-omap2/voltagedomains44xx_data.c
> index 4e11d02..c3115f6 100644
> --- a/arch/arm/mach-omap2/voltagedomains44xx_data.c
> +++ b/arch/arm/mach-omap2/voltagedomains44xx_data.c
> @@ -100,9 +100,11 @@ void __init omap44xx_voltagedomains_init(void)
>  	 * XXX Will depend on the process, validation, and binning
>  	 * for the currently-running IC
>  	 */
> +#ifdef CONFIG_PM_OPP
>  	omap4_voltdm_mpu.volt_data = omap44xx_vdd_mpu_volt_data;
>  	omap4_voltdm_iva.volt_data = omap44xx_vdd_iva_volt_data;
>  	omap4_voltdm_core.volt_data = omap44xx_vdd_core_volt_data;
> +#endif
>  
>  	for (i = 0; voltdm = voltagedomains_omap4[i], voltdm; i++)
>  		voltdm->sys_clk.name = sys_clk_name;

Looks good to me.  

Are you planning to add this to your fixes? or should I queue it up.  If
you're taking it, feel free to add:

Acked-by: Kevin Hilman <khilman@ti.com>

Re: OMAP34xx

[Russell King - ARM Linux]

Here's another issue which kautobuildv2 just found, as I've now added
randconfig to the suite of OMAP4430 SDP builds.  Obviously, as it's
using a different configuration each time, it's going to find different
issues on each run.

For this, the seed config has the following extra lines compared with
allnoconfig:

CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_THUMB2_KERNEL=n

The reason for the last line is that -mauto-it is not supported by my
toolchain, so if it were to be enabled, it would cause an immediate
build failure.  The second to late line ensures that we don't end up
with randconfig having to dream up a value for CONFIG_PHYS_OFFSET,
which it can't do.

The seed configs can now be viewed or downloaded from the build site.
8<========
From: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: OMAP: fix missing __devexit_p() annotations

Missing __devexit_p() annotations in driver structures for remove functions
marked with __devexit is waiting for build errors to happen, such as:

`omap_system_dma_remove' referenced in section `.data' of arch/arm/plat-omap/built-in.o: defined in discarded section `.devexit.text' of arch/arm/plat-omap/built-in.o

Add the necessary annotation, and as a result of audit, fix others which
are also missing in arch/arm/*omap*.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/smartreflex.c |    2 +-
 arch/arm/plat-omap/dma.c          |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
index 7e755bb..47c77a1 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1012,7 +1012,7 @@ static int __devexit omap_sr_remove(struct platform_device *pdev)
 }
 
 static struct platform_driver smartreflex_driver = {
-	.remove         = omap_sr_remove,
+	.remove         = __devexit_p(omap_sr_remove),
 	.driver		= {
 		.name	= "smartreflex",
 	},
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 002fb4d..cb856fe 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2125,7 +2125,7 @@ static int __devexit omap_system_dma_remove(struct platform_device *pdev)
 
 static struct platform_driver omap_system_dma_driver = {
 	.probe		= omap_system_dma_probe,
-	.remove		= omap_system_dma_remove,
+	.remove		= __devexit_p(omap_system_dma_remove),
 	.driver		= {
 		.name	= "omap_dma_system"
 	},

Re: OMAP34xx

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120212 03:13]:
> Here's another issue which kautobuildv2 just found, as I've now added
> randconfig to the suite of OMAP4430 SDP builds.  Obviously, as it's
> using a different configuration each time, it's going to find different
> issues on each run.
> 
> For this, the seed config has the following extra lines compared with
> allnoconfig:
> 
> CONFIG_ARM_PATCH_PHYS_VIRT=y
> CONFIG_THUMB2_KERNEL=n
> 
> The reason for the last line is that -mauto-it is not supported by my
> toolchain, so if it were to be enabled, it would cause an immediate
> build failure.  The second to late line ensures that we don't end up
> with randconfig having to dream up a value for CONFIG_PHYS_OFFSET,
> which it can't do.
> 
> The seed configs can now be viewed or downloaded from the build site.
> 8<========
> From: Russell King <rmk+kernel@arm.linux.org.uk>
> ARM: OMAP: fix missing __devexit_p() annotations
> 
> Missing __devexit_p() annotations in driver structures for remove functions
> marked with __devexit is waiting for build errors to happen, such as:
> 
> `omap_system_dma_remove' referenced in section `.data' of arch/arm/plat-omap/built-in.o: defined in discarded section `.devexit.text' of arch/arm/plat-omap/built-in.o
> 
> Add the necessary annotation, and as a result of audit, fix others which
> are also missing in arch/arm/*omap*.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

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