rmk's patch series for fixing OMAP

When the PMIC is not found, voltdm->pmic will be NULL. vp.c's initialization function tries to dereferences this, which causes an oops:

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_pm_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_initcall+0x9c/0x164)
[<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03d1284>] (kernel_init+0x7c/0x120)
[<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!

Signed-off-by Russell King <[email protected]>

* Russell King - ARM Linux <[email protected]> [120208 08:05]:

This is better than Kevin's earlier patch because of the descriptive error:

Acked-by Tony Lindgren <[email protected]>

Quoted 6 lines · Tony Lindgren

* Russell King - ARM Linux <[email protected]> [120208 08:05]:

This is better than Kevin's earlier patch because of the descriptive error:

Acked-by Tony Lindgren <[email protected]>

Hmm looks like the patch from Ahilash that Kevin queued has the also a test for missing uv_to_vsel:

if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel)

So there seems to be more to it than what Russell's patch is doing.

Quoted 11 lines · Tony Lindgren

Quoted 6 lines · Tony Lindgren

* Russell King - ARM Linux <[email protected]> [120208 08:05]:

This is better than Kevin's earlier patch because of the descriptive error:

Acked-by Tony Lindgren <[email protected]>

Hmm looks like the patch from Ahilash that Kevin queued has the also a test for missing uv_to_vsel:

Quoted 4 lines

if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel)

So there seems to be more to it than what Russell's patch is doing.

So, through the discussion in patch 5, do you want me to add the second check to my patch 1?

When a PMIC is not found, this driver is unable to obtain its 'vdds_dsi_reg' regulator. Even through its initialization function fails, other code still calls its enable function, which fails to check whether it has this regulator before asking for it to be enabled.

This fixes the oops, however a better fix would be to sort out the upper layers to prevent them calling into a module which failed to initialize.

Signed-off-by Russell King <[email protected]>

Quoted 9 lines · Russell King - ARM Linux

When a PMIC is not found, this driver is unable to obtain its 'vdds_dsi_reg' regulator. Even through its initialization function fails, other code still calls its enable function, which fails to check whether it has this regulator before asking for it to be enabled.

This fixes the oops, however a better fix would be to sort out the upper layers to prevent them calling into a module which failed to initialize.

Quoted 1 line

Signed-off-by Russell King <[email protected]>

Tomi can look into fixing this properly for v3.4:

Acked-by Tony Lindgren <[email protected]>

Quoted 12 lines · Tony Lindgren

Quoted 10 lines · Russell King - ARM Linux

When a PMIC is not found, this driver is unable to obtain its 'vdds_dsi_reg' regulator. Even through its initialization function fails, other code still calls its enable function, which fails to check whether it has this regulator before asking for it to be enabled.

This fixes the oops, however a better fix would be to sort out the upper layers to prevent them calling into a module which failed to initialize.

Signed-off-by Russell King <[email protected]>

Quoted 3 lines

Tomi can look into fixing this properly for v3.4:

Acked-by Tony Lindgren <[email protected]>

No, it's a thing for v3.3, because you can still get this oops.

I expect _most_ of these patches will go into v3.3, and anything with 'fix' or 'oops' in especially I want to see in v3.3.

In commit aeb5032b3f, a dependency on IRQ_DOMAIN was added, which causes regressions on previously working setups: a previously working non-DT kernel configuration now loses its PMIC support. The lack of PMIC support in turn causes the loss of other functionality the kernel had.

This dependency was added because the driver now registers its interrupts with the IRQ domain code, presumably to prevent a build error.

The result is that OMAP3 oopses in the vp.c code (fixed by a previous commit) due to the lack of PMIC support.

However, even with IRQ_DOMAIN enabled, the driver oopses:

Signed-off-by Russell King <[email protected]>

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

Signed-off-by Russell King <[email protected]>

Quoted 1 line · Russell King - ARM Linux

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

Can you please add something like "This happens when CONFIG_OF is not selected".

Quoted 1 line

Signed-off-by Russell King<[email protected]>

Other than that:

Acked-by Tony Lindgren<[email protected]>

While testing on my OMAP3430 platform, this error message was emitted:

omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc

Trying to find this message was difficult because it was wrapped across several lines. It also mis-spells "required", doesn't read very well, and has spaces lacking. Let's replace it with a more concise:

omap_vc_init_channel: No PMIC info for vdd_core

While we're here, fix a simple spelling error in a comment.

Signed-off-by Russell King <[email protected]>

Quoted 8 lines · Russell King - ARM Linux

While testing on my OMAP3430 platform, this error message was emitted:

omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc

Trying to find this message was difficult because it was wrapped across several lines. It also mis-spells "required", doesn't read very well, and has spaces lacking. Let's replace it with a more concise:

Quoted 5 lines

omap_vc_init_channel: No PMIC info for vdd_core

While we're here, fix a simple spelling error in a comment.

Signed-off-by Russell King <[email protected]>

Acked-by Tony Lindgren <[email protected]>

Quoted 15 lines · Tony Lindgren

Quoted 13 lines · Russell King - ARM Linux

While testing on my OMAP3430 platform, this error message was emitted:

omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc

Trying to find this message was difficult because it was wrapped across several lines. It also mis-spells "required", doesn't read very well, and has spaces lacking. Let's replace it with a more concise:

omap_vc_init_channel: No PMIC info for vdd_core

While we're here, fix a simple spelling error in a comment.

Signed-off-by Russell King <[email protected]>

Quoted 1 line

Acked-by Tony Lindgren <[email protected]>

NAK.

Tony, please use the patches already in your cleanup branch (that came from my for_3.3/cleanup/pm) that fix this and also fix a similar problem for VP.

Quoted 17 lines · Kevin Hilman

Quoted 15 lines · Tony Lindgren

Quoted 13 lines · Russell King - ARM Linux

While testing on my OMAP3430 platform, this error message was emitted:

omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc

Trying to find this message was difficult because it was wrapped across several lines. It also mis-spells "required", doesn't read very well, and has spaces lacking. Let's replace it with a more concise:

omap_vc_init_channel: No PMIC info for vdd_core

While we're here, fix a simple spelling error in a comment.

Signed-off-by Russell King <[email protected]>

Quoted 7 lines

Quoted 1 line

Acked-by Tony Lindgren <[email protected]>

NAK.

Tony, please use the patches already in your cleanup branch (that came from my for_3.3/cleanup/pm) that fix this and also fix a similar problem for VP.

Ah OK, there's the VP part there too.

So that would be the following two patches then for me to move to fixes from cleanup:

cd63040e00ea83729673acfea1675d85fde6ea59 ARM: OMAP: voltage: cleanup VC/VP error messages af9a2ed9667b49e7e125eac526d8f655183ce53e ARM: OMAP2+: voltage: add check for missing PMIC info in VP init

And patches 1 and 5 for Russell to drop then.

Everybody OK with that?

Quoted 31 lines · Tony Lindgren

Quoted 17 lines · Kevin Hilman

Quoted 15 lines · Tony Lindgren

Quoted 13 lines · Russell King - ARM Linux

While testing on my OMAP3430 platform, this error message was emitted:

omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc

Trying to find this message was difficult because it was wrapped across several lines. It also mis-spells "required", doesn't read very well, and has spaces lacking. Let's replace it with a more concise:

omap_vc_init_channel: No PMIC info for vdd_core

While we're here, fix a simple spelling error in a comment.

Signed-off-by Russell King <[email protected]>

Quoted 7 lines

Quoted 1 line

Acked-by Tony Lindgren <[email protected]>

NAK.

Tony, please use the patches already in your cleanup branch (that came from my for_3.3/cleanup/pm) that fix this and also fix a similar problem for VP.

Ah OK, there's the VP part there too.

So that would be the following two patches then for me to move to fixes from cleanup:

Quoted 6 lines

cd63040e00ea83729673acfea1675d85fde6ea59 ARM: OMAP: voltage: cleanup VC/VP error messages af9a2ed9667b49e7e125eac526d8f655183ce53e ARM: OMAP2+: voltage: add check for missing PMIC info in VP init

And patches 1 and 5 for Russell to drop then.

Everybody OK with that?

Does it fix the other issues I mention in the commit log as well?

Quoted 1 line · Russell King - ARM Linux

Does it fix the other issues I mention in the commit log as well?

Like your patches 1 & 5, my series fixes the oops and also makes the error strings simple, non-wrapping ones.

The one thing it doesn't fix is the spelling typo you fixed in the comment, but IMO we can leave that out for -rc.

Quoted 3 lines · Kevin Hilman

Quoted 1 line · Russell King - ARM Linux

Does it fix the other issues I mention in the commit log as well?

Quoted 5 lines

Like your patches 1 & 5, my series fixes the oops and also makes the error strings simple, non-wrapping ones.

The one thing it doesn't fix is the spelling typo you fixed in the comment, but IMO we can leave that out for -rc.

OK, but it would be much better for that simple fix to go with another simple patch. On its own it doesn't make sense as a commit.

Quoted 7 lines · Russell King - ARM Linux

Quoted 6 lines · Kevin Hilman

Quoted 1 line · Russell King - ARM Linux

Does it fix the other issues I mention in the commit log as well?

Like your patches 1 & 5, my series fixes the oops and also makes the error strings simple, non-wrapping ones.

Quoted 5 lines

Quoted 2 lines

The one thing it doesn't fix is the spelling typo you fixed in the comment, but IMO we can leave that out for -rc.

OK, but it would be much better for that simple fix to go with another simple patch. On its own it doesn't make sense as a commit.

Agreed. We'll have some other VC/VP cleanup for v3.4, and I'll add this into that cleanup.

Quoted 9 lines · Kevin Hilman

Quoted 7 lines · Russell King - ARM Linux

Quoted 6 lines · Kevin Hilman

Quoted 1 line · Russell King - ARM Linux

Does it fix the other issues I mention in the commit log as well?

Like your patches 1 & 5, my series fixes the oops and also makes the error strings simple, non-wrapping ones.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

The one thing it doesn't fix is the spelling typo you fixed in the comment, but IMO we can leave that out for -rc.

OK, but it would be much better for that simple fix to go with another simple patch. On its own it doesn't make sense as a commit.

Agreed. We'll have some other VC/VP cleanup for v3.4, and I'll add this into that cleanup.

Eek, looking at it, I'd rather stay away from this formatting patch for -rc series because the flaming potential causes me rash!

Russell's patch 5 has way better description for the -rc series.

So I now suggest that Russell drops patch 1 and updates patch 5 to cover both vp.c and vc.c.

d269914ece0498f31603ecd85ed3d7a586b3cbcd ARM: OMAP2+: PM: only register TWL with voltage layer when device is present af9a2ed9667b49e7e125eac526d8f655183ce53e ARM: OMAP2+: voltage: add check for missing PMIC info in VP init

Quoted 19 lines · Tony Lindgren

Quoted 9 lines · Kevin Hilman

Quoted 7 lines · Russell King - ARM Linux

Quoted 6 lines · Kevin Hilman

Quoted 1 line · Russell King - ARM Linux

Does it fix the other issues I mention in the commit log as well?

Like your patches 1 & 5, my series fixes the oops and also makes the error strings simple, non-wrapping ones.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

The one thing it doesn't fix is the spelling typo you fixed in the comment, but IMO we can leave that out for -rc.

OK, but it would be much better for that simple fix to go with another simple patch. On its own it doesn't make sense as a commit.

Agreed. We'll have some other VC/VP cleanup for v3.4, and I'll add this into that cleanup.

Quoted 7 lines

Eek, looking at it, I'd rather stay away from this formatting patch for -rc series because the flaming potential causes me rash!

Russell's patch 5 has way better description for the -rc series.

So I now suggest that Russell drops patch 1 and updates patch 5 to cover both vp.c and vc.c.

I'm not sure what you want me to update in patch 5. vp.c already contains:

        if (!voltdm->pmic) {
                pr_err("%s: No PMIC info for vdd_%s\n", __func__, voltdm->name);
                return;
        }

which is where I got the idea for the message I put into vc.c.

Quoted 2 lines

d269914ece0498f31603ecd85ed3d7a586b3cbcd ARM: OMAP2+: PM: only register TWL with voltage layer when device is present af9a2ed9667b49e7e125eac526d8f655183ce53e ARM: OMAP2+: voltage: add check for missing PMIC info in VP init

I'd like at least the first in my tree too, otherwise my stuff becomes untestable without patch 1. What's the second doing?

From d269914ece0498f31603ecd85ed3d7a586b3cbcd Mon Sep 17 00:00:00 2001

So that leaves me only the second one to queue that adds checks for the PMIC info for boards that don't have it, see below.

From d269914ece0498f31603ecd85ed3d7a586b3cbcd Mon Sep 17 00:00:00 2001
From: Kevin Hilman <[email protected]>
Date: Fri, 30 Sep 2011 11:24:04 -0700
Subject: [PATCH] ARM: OMAP2+: PM: only register TWL with voltage layer when device is present

Current code registers voltage layer details for TWL PMIC even when a TWL has not been registered. Fix this to only register the TWL with voltage layer when the TWL PMIC is initialized by board-level code.

Tested-by Abhilash Koyamangalath <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

Quoted 3 lines · Tony Lindgren

So that leaves me only the second one to queue that adds checks for the PMIC info for boards that don't have it, see below.

...

Quoted 9 lines

From d269914ece0498f31603ecd85ed3d7a586b3cbcd Mon Sep 17 00:00:00 2001
From: Kevin Hilman <[email protected]>
Date: Fri, 30 Sep 2011 11:24:04 -0700
Subject: [PATCH] ARM: OMAP2+: PM: only register TWL with voltage layer when device is present

Current code registers voltage layer details for TWL PMIC even when a TWL has not been registered. Fix this to only register the TWL with voltage layer when the TWL PMIC is initialized by board-level code.

Quoted 2 lines

Tested-by Abhilash Koyamangalath <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

Never mind. This one is already in mainline as commit 46232a3622c6e33605906ee6690dfef372925f53.

Quoted 15 lines · Tony Lindgren

Quoted 3 lines · Tony Lindgren

So that leaves me only the second one to queue that adds checks for the PMIC info for boards that don't have it, see below.

...

Quoted 9 lines

From d269914ece0498f31603ecd85ed3d7a586b3cbcd Mon Sep 17 00:00:00 2001
From: Kevin Hilman <[email protected]>
Date: Fri, 30 Sep 2011 11:24:04 -0700
Subject: [PATCH] ARM: OMAP2+: PM: only register TWL with voltage layer when device is present

Current code registers voltage layer details for TWL PMIC even when a TWL has not been registered. Fix this to only register the TWL with voltage layer when the TWL PMIC is initialized by board-level code.

Quoted 5 lines

Quoted 2 lines

Tested-by Abhilash Koyamangalath <[email protected]>

Signed-off-by Kevin Hilman <[email protected]>

Never mind. This one is already in mainline as commit 46232a3622c6e33605906ee6690dfef372925f53.

Okay, I'll re-send patches 1 and 5 for acks then. Once I have those, can I assume that everyone is happy for patches 1 to 15 to go upstream?

After you repost those two patches, I'll update linux-omap with your fixes + tty fixes + my fixes for people to test with.

Quoted 17 lines · Kevin Hilman

Quoted 15 lines · Tony Lindgren

Quoted 13 lines · Russell King - ARM Linux

While testing on my OMAP3430 platform, this error message was emitted:

omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc

Trying to find this message was difficult because it was wrapped across several lines. It also mis-spells "required", doesn't read very well, and has spaces lacking. Let's replace it with a more concise:

omap_vc_init_channel: No PMIC info for vdd_core

While we're here, fix a simple spelling error in a comment.

Signed-off-by Russell King <[email protected]>

Quoted 7 lines

Quoted 1 line

Acked-by Tony Lindgren <[email protected]>

NAK.

Tony, please use the patches already in your cleanup branch (that came from my for_3.3/cleanup/pm) that fix this and also fix a similar problem for VP.

Ah OK, there's the VP part there too.

So that would be the following two patches then for me to move to fixes from cleanup:

cd63040e00ea83729673acfea1675d85fde6ea59 ARM: OMAP: voltage: cleanup VC/VP error messages af9a2ed9667b49e7e125eac526d8f655183ce53e ARM: OMAP2+: voltage: add check for missing PMIC info in VP init

And patches 1 and 5 for Russell to drop then.

Everybody OK with that?

Quoted 36 lines · Tony Lindgren

Quoted 17 lines · Kevin Hilman

Quoted 15 lines · Tony Lindgren

Quoted 13 lines · Russell King - ARM Linux

While testing on my OMAP3430 platform, this error message was emitted:

omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc

Trying to find this message was difficult because it was wrapped across several lines. It also mis-spells "required", doesn't read very well, and has spaces lacking. Let's replace it with a more concise:

omap_vc_init_channel: No PMIC info for vdd_core

While we're here, fix a simple spelling error in a comment.

Signed-off-by Russell King <[email protected]>

Quoted 7 lines

Quoted 1 line

Acked-by Tony Lindgren <[email protected]>

NAK.

Tony, please use the patches already in your cleanup branch (that came from my for_3.3/cleanup/pm) that fix this and also fix a similar problem for VP.

Ah OK, there's the VP part there too.

So that would be the following two patches then for me to move to fixes from cleanup:

cd63040e00ea83729673acfea1675d85fde6ea59 ARM: OMAP: voltage: cleanup VC/VP error messages af9a2ed9667b49e7e125eac526d8f655183ce53e ARM: OMAP2+: voltage: add check for missing PMIC info in VP init

And patches 1 and 5 for Russell to drop then.

Quoted 1 line

Everybody OK with that?

Also, what about this one in the cleanup branch:

d269914ece0498f31603ecd85ed3d7a586b3cbcd ARM: OMAP2+: PM: only register TWL with voltage layer when device is present

Should that be a fix too?

On my OMAP4 platform, I'm getting this error message repeated several times at boot:

omap_vc_i2c_init: I2C config for all channels must match.
omap_vc_i2c_init: I2C config for all channels must match.

This doesn't help identify what the problem is. Fix this message to be more informative:

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).

This allows us to identify which voltage domains have a problem, and what the I2C configuration state (a boolean, i2c_high_speed) setting being used actually is.

omap4_iva_pmic and omap4_mpu_pmic both have it set true.

Signed-off-by Russell King <[email protected]>

On my OMAP4 platform, I'm getting this error message repeated several times at boot:

omap_vc_i2c_init: I2C config for all channels must match.
omap_vc_i2c_init: I2C config for all channels must match.

This doesn't help identify what the problem is. Fix this message to be more informative:

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).

This allows us to identify which voltage domains have a problem, and what the I2C configuration state (a boolean, i2c_high_speed) setting being used actually is.

omap4_iva_pmic and omap4_mpu_pmic both have it set true.

Signed-off-by Russell King <[email protected]>

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

arch/arm/mach-omap2/vc.c +2 -2

index ce45695..ff58dc9 100644
@@ -265,8 +265,8 @@ static void __init omap_vc_i2c_init(struct voltagedomain *voltdm)
 
 	if (initialized) {
 		if (voltdm->pmic->i2c_high_speed != i2c_high_speed)
-			pr_warn("%s: I2C config for all channels must match.",
-				__func__);
+			pr_warn("%s: I2C config for vdd_%s does not match other channels (%u).",
+				__func__, voltdm->name, i2c_high_speed);
 		return;
 	}

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.

twl4030_power_init() references other __init marked functions, so these too must become __devinit.

Signed-off-by Russell King <[email protected]>

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x15a4): Section mismatch in reference from the function omap_mux_init_signals() to the function .init.text:omap_mux_init_signal() 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.

Signed-off-by Russell King <[email protected]>

Found by review.

omap4_sdp4430_wifi_mux_init() is called by an __init marked function, and only calls omap_mux_init_gpio() and omap_mux_init_signal() which are both also an __init marked functions.

The only reason this doesn't issue a warning is because the compiler inlines omap4_sdp4430_wifi_mux_init() into omap4_sdp4430_wifi_init().

So, lets add the __init annotation to ensure this remains safe should the compiler choose not to inline.

Signed-off-by Russell King <[email protected]>

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

Unfortunately, fixing this causes a new warning which is harder to solve:

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

because omap4_hotplug_cpu() is used by power management code as well, which may not end up using omap_secondary_startup().

Signed-off-by Russell King <[email protected]>

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

Fix this by adding __init to omap_4430sdp_display_init().

Signed-off-by Russell King <[email protected]>

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

sdp3430_twl_gpio_setup() is called via platform data from the gpio-twl4030 module, which can be inserted and removed at runtime. This makes sdp3430_twl_gpio_setup() callable at runtime, and prevents it being marked with an __init annotation.

As it calls omap2_hsmmc_init() unconditionally, the only resolution to this warning is to remove the __init markings from omap2_hsmmc_init() and its called functions. This addresses the functions in hsmmc.c.

Signed-off-by Russell King <[email protected]>

The previous commit causes new section mismatch warnings:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Again, as for omap2_hsmmc_init(), these functions are callable at runtime via the gpio-twl4030.c driver, and so these can't be marked __init.

While trying to debug my OMAP platforms, they emitted this message:

omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state

The following backtrace said it was from a function called '_enable', which didn't provide much clue. Grepping didn't find it either.

The message is wrapped, so unwrap the message so grep can find it. Do the same for three other messages in this file.

Signed-off-by Russell King <[email protected]>

Quoted 7 lines · Russell King - ARM Linux

While trying to debug my OMAP platforms, they emitted this message:

omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state

The following backtrace said it was from a function called '_enable', which didn't provide much clue. Grepping didn't find it either.

Quoted 4 lines

The message is wrapped, so unwrap the message so grep can find it. Do the same for three other messages in this file.

Signed-off-by Russell King <[email protected]>

Thanks, I'll queue this for 3.4.

Quoted 14 lines · Paul Walmsley

Quoted 11 lines · Russell King - ARM Linux

While trying to debug my OMAP platforms, they emitted this message:

omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state

The following backtrace said it was from a function called '_enable', which didn't provide much clue. Grepping didn't find it either.

The message is wrapped, so unwrap the message so grep can find it. Do the same for three other messages in this file.

Signed-off-by Russell King <[email protected]>

Quoted 1 line

Thanks, I'll queue this for 3.4.

Looks like Russell is willing to take potential flamage and argue this should go into -rc because of the hard to find message.

Care to ack instead, or do you have objections to this being merged during the -rc?

Quoted 20 lines · Tony Lindgren

Quoted 9 lines · Paul Walmsley

Quoted 7 lines · Russell King - ARM Linux

While trying to debug my OMAP platforms, they emitted this message:

omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state

The following backtrace said it was from a function called '_enable', which didn't provide much clue. Grepping didn't find it either.

Quoted 6 lines

Quoted 4 lines

The message is wrapped, so unwrap the message so grep can find it. Do the same for three other messages in this file.

Signed-off-by Russell King <[email protected]>

Thanks, I'll queue this for 3.4.

Looks like Russell is willing to take potential flamage and argue this should go into -rc because of the hard to find message.

Quoted 2 lines

Care to ack instead, or do you have objections to this being merged during the -rc?

No objections.

Acked-by Paul Walmsley <[email protected]>

It's useful to print the error code when a called function fails so a diagnosis of why it failed is possible. In this case, it fails because we try to register some data for the wl12xx driver, but as the driver is not configured, a stub function is used which simply returns -ENOSYS.

Let's do the simple thing for -rc and print the error code.

Also, the return code from platform_register_device() at each of these sites was not being checked. Add some checking, and again print the error code.

This should be fixed properly for the next merge window so we don't issue error messages merely because a driver is not configured.

Signed-off-by Russell King <[email protected]>

Commit 2fd149645eb4 (ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos) has caused a regression on OMAP3 platforms.

When the UART is trying to transmit data, if we enter a low power mode, transmission stops, which makes serial on OMAP3 unusable - a 'dmesg' takes five minutes to be output at 115200 baud, at a rate of around a block of 16 characters every couple of seconds.

Unfortunately, the commit above can't be reverted because of many other changes in this area, so this implements a dirty fix by disabling CPU idle in the places the original commit does, irrespective of the UART state.

Quoted 12 lines · Russell King - ARM Linux

Commit 2fd149645eb4 (ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos) has caused a regression on OMAP3 platforms.

When the UART is trying to transmit data, if we enter a low power mode, transmission stops, which makes serial on OMAP3 unusable - a 'dmesg' takes five minutes to be output at 115200 baud, at a rate of around a block of 16 characters every couple of seconds.

Unfortunately, the commit above can't be reverted because of many other changes in this area, so this implements a dirty fix by disabling CPU idle in the places the original commit does, irrespective of the UART state.

...

Quoted 6 lines

arch/arm/mach-omap2/pm34xx.c +0 -0

@@ -421,7 +421,7 @@ static void omap3_pm_idle(void)
 	local_irq_disable();
 	local_fiq_disable();
 

arch/arm/mach-omap2/pm34xx.c static void omap3_pm_idle(void) · line 427

Quoted 5 lines

arch/arm/mach-omap2/pm34xx.c +1 -1

-	if (omap_irq_pending() || need_resched())
+	if (omap_irq_pending() || need_resched() || 1)
 		goto out;
 
 	trace_power_start(POWER_CSTATE, 1, smp_processor_id());

Argh, this is just too ugly. There has got to be a better fix for the -rc series.

Looks like the patches to fix omap-serial.c are queued for v3.4, so that won't help.

Quoted 12 lines · Russell King - ARM Linux

Commit 2fd149645eb4 (ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos) has caused a regression on OMAP3 platforms.

When the UART is trying to transmit data, if we enter a low power mode, transmission stops, which makes serial on OMAP3 unusable - a 'dmesg' takes five minutes to be output at 115200 baud, at a rate of around a block of 16 characters every couple of seconds.

Unfortunately, the commit above can't be reverted because of many other changes in this area, so this implements a dirty fix by disabling CPU idle in the places the original commit does, irrespective of the UART state.

...

arch/arm/mach-omap2/pm34xx.c static void omap3_pm_idle(void) · line 427

Quoted 11 lines

arch/arm/mach-omap2/pm34xx.c +1 -1

@@ -421,7 +421,7 @@ static void omap3_pm_idle(void)
 	local_irq_disable();
 	local_fiq_disable();
 
-	if (omap_irq_pending() || need_resched())
+	if (omap_irq_pending() || need_resched() || 1)
 		goto out;
 
 	trace_power_start(POWER_CSTATE, 1, smp_processor_id());

Argh, this is just too ugly. There has got to be a better fix for the -rc series.

Looks like the patches to fix omap-serial.c are queued for v3.4, so that won't help.

Kevin, what do you have for the -rc fix here to avoid the if (1) hack?

Quoted 30 lines · Tony Lindgren

Quoted 12 lines · Russell King - ARM Linux

Commit 2fd149645eb4 (ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos) has caused a regression on OMAP3 platforms.

When the UART is trying to transmit data, if we enter a low power mode, transmission stops, which makes serial on OMAP3 unusable - a 'dmesg' takes five minutes to be output at 115200 baud, at a rate of around a block of 16 characters every couple of seconds.

Unfortunately, the commit above can't be reverted because of many other changes in this area, so this implements a dirty fix by disabling CPU idle in the places the original commit does, irrespective of the UART state.

...

arch/arm/mach-omap2/pm34xx.c static void omap3_pm_idle(void) · line 427

Quoted 11 lines

arch/arm/mach-omap2/pm34xx.c +1 -1

@@ -421,7 +421,7 @@ static void omap3_pm_idle(void)
 	local_irq_disable();
 	local_fiq_disable();
 
-	if (omap_irq_pending() || need_resched())
+	if (omap_irq_pending() || need_resched() || 1)
 		goto out;
 
 	trace_power_start(POWER_CSTATE, 1, smp_processor_id());

Argh, this is just too ugly. There has got to be a better fix for the -rc series.

Quoted 5 lines

Looks like the patches to fix omap-serial.c are queued for v3.4, so that won't help.

Kevin, what do you have for the -rc fix here to avoid the if (1) hack?

There was confusion with Greg about this serial fixes which were supposed to be for -rc.

He pulled the original series in to -rc, and reverted them when Paul updated the series. Then he decided to queue the updated series for 3.4. :(

I've now asked Greg if he can queue that series for 3.3.

This is my set of patches for fixing OMAP for v3.3.

This is the complete series of patches I'm currently applying to _my_ tree to get v3.3-rc2 into a usable and sane state.

I want to see most of the problems uncovered in this series fixed sooner rather than later, and certainly not taking three plus weeks to get into mainline like this rather serious looking commit did:

commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd

Author: Tomi Valkeinen <[email protected]>
Date:   Tue Jan 17 11:09:57 2012 +0200

OMAPDSS: HDMI: PHY burnout fix

A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board if the HDMI PHY is kept powered on when the cable is not connected.

which now has me wondering if, by trying to boot v3.3-rc2 on this board during the past week, I have a destroyed HDMI interface on it.

So, a big thanks for sitting on that fix and exposing peoples hardware to damage, that shows real professionalism.

commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd

Author: Tomi Valkeinen <[email protected]>
Date:   Tue Jan 17 11:09:57 2012 +0200

OMAPDSS: HDMI: PHY burnout fix

A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board if the HDMI PHY is kept powered on when the cable is not connected.

which now has me wondering if, by trying to boot v3.3-rc2 on this board during the past week, I have a destroyed HDMI interface on it.

So, a big thanks for sitting on that fix and exposing peoples hardware to damage, that shows real professionalism.

Hi Russell,

Quoted 8 lines · Russell King - ARM Linux

commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd

Author: Tomi Valkeinen <[email protected]>
Date:   Tue Jan 17 11:09:57 2012 +0200

OMAPDSS: HDMI: PHY burnout fix

A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board if the HDMI PHY is kept powered on when the cable is not connected.

I agree this is a serious issue.

Quoted 2 lines

which now has me wondering if, by trying to boot v3.3-rc2 on this board during the past week, I have a destroyed HDMI interface on it.

I am not sure as I don't keep track of all OMAP changes, but you make it sound like a regression, is there any difference to 3.2 behavior?

Quoted 2 lines

So, a big thanks for sitting on that fix and exposing peoples hardware to damage, that shows real professionalism.

Well, I am no professional to begin with, at least in the sense of getting paid for it. That said I'm quite happy if I manage to find a few hours every weekend to do the work. Given that the final thing should be tested in -next before I ask Linus to pull, it is completely usual (and even quite fast) if things take 8-13 days on my end. If this isn't fast enough for Tomi, he'd better ask Linus to pull directly for such issues.

Moreover, only last Monday did I enable the OMAP2 DSS subsystem on the 4430 SDP platform, _including_ the HDMI code, and looking at the commit it could be one of those platforms which is affected.

As I don't have a HDMI cable connected to the system, and I ran that kernel overnight, and I tried opening each /dev/fb* device, what I'm now wondering is: have I destroyed the HDMI PHY on my 4430SDP?

However, you raise another point, a much more serious one at that. Is this problem also present in 3.2? The patch seems to apply almost cleanly to that kernel version, so I guess it is. It fails to apply to v3.1 because of missing files, so I guess 3.1 is unaffected.

So, why isn't this patch copied to the stable people?

For hardware destruction issues, once the problem has been identified, it should be shouted about very loudly to get it upstream as quickly as possible. I'm sure Linus would've even taken it in patch form.

(You do realise that Linus does apply patches as well as pulling trees?)

Quoted 8 lines

Moreover, only last Monday did I enable the OMAP2 DSS subsystem on the 4430 SDP platform, _including_ the HDMI code, and looking at the commit it could be one of those platforms which is affected.

As I don't have a HDMI cable connected to the system, and I ran that kernel overnight, and I tried opening each /dev/fb* device, what I'm now wondering is: have I destroyed the HDMI PHY on my 4430SDP?

Probably not. I don't know the exact details of the HW bug (I wrote the patch as it took too long for the person responsible for it to come up with a decent patch), but my understanding is that the cable needs to be plugged in at some point, and then removed.

Thinking about this now, I guess I should've sent queries to get a proper description of the situation where the bug happens.

Quoted 5 lines

However, you raise another point, a much more serious one at that. Is this problem also present in 3.2? The patch seems to apply almost cleanly to that kernel version, so I guess it is. It fails to apply to v3.1 because of missing files, so I guess 3.1 is unaffected.

Quoted 1 line

So, why isn't this patch copied to the stable people?

Good point, I'll take it to the stable people.

The problem is present in all kernels where we have the HDMI driver, so 2.6.39+.

Quoted 6 lines

For hardware destruction issues, once the problem has been identified, it should be shouted about very loudly to get it upstream as quickly as possible. I'm sure Linus would've even taken it in patch form.

(You do realise that Linus does apply patches as well as pulling trees?)

Yes, I should've taken this directly to Linus.

Tomi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Am Donnerstag, den 09.02.2012, 09:02 +0200 schrieb Tomi Valkeinen:

Quoted 2 lines

The problem is present in all kernels where we have the HDMI driver, so 2.6.39+.

Are there already backported patches out there for 3.0/3.1? We are quite interested in this.