[PATCH 00/16] rmk's patch series for fixing OMAP

[PATCH 00/16] rmk's patch series for fixing OMAP

[Russell King - ARM Linux]

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 <tomi.valkeinen@ti.com>
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.

[PATCH 01/16] ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found

[Russell King - ARM Linux]

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 <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/vp.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 807391d..f16f6a5 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -41,6 +41,11 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
 	u32 val, sys_clk_rate, timeout, waittime;
 	u32 vddmin, vddmax, vstepmin, vstepmax;
 
+	if (!voltdm->pmic) {
+		pr_err("%s: No PMIC info for vdd_%s\n", __func__, voltdm->name);
+		return;
+	}
+
 	if (!voltdm->read || !voltdm->write) {
 		pr_err("%s: No read/write API for accessing vdd_%s regs\n",
 			__func__, voltdm->name);
-- 
1.7.4.4

[PATCH 01/16] ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> 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 <rmk+kernel@arm.linux.org.uk>

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

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 01/16] ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [120208 10:02]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> 
> This is better than Kevin's earlier patch because of the descriptive
> error:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

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.

Regards,

Tony

[PATCH 01/16] ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 03:46:54PM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [120208 10:02]:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> > 
> > This is better than Kevin's earlier patch because of the descriptive
> > error:
> > 
> > Acked-by: Tony Lindgren <tony@atomide.com>
> 
> 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.

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

[PATCH 01/16] ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120209 08:13]:
> On Wed, Feb 08, 2012 at 03:46:54PM -0800, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [120208 10:02]:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> > > 
> > > This is better than Kevin's earlier patch because of the descriptive
> > > error:
> > > 
> > > Acked-by: Tony Lindgren <tony@atomide.com>
> > 
> > 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.
> 
> So, through the discussion in patch 5, do you want me to add the
> second check to my patch 1?

Yes, please do.

Regards,

Tony

[PATCH 04/16] ARM: omap: fix prm44xx.c OMAP44XX_IRQ_PRCM build error

[Russell King - ARM Linux]

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

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/prm44xx.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

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"
-- 
1.7.4.4

[PATCH 04/16] ARM: omap: fix prm44xx.c OMAP44XX_IRQ_PRCM build error

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:06]:
> 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".
 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Other than that:

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 04/16] ARM: omap: fix prm44xx.c OMAP44XX_IRQ_PRCM build error

[Cousson, Benoit]

Hi Tony,

On 2/8/2012 7:39 PM, Tony Lindgren wrote:
> * Russell King - ARM Linux<linux@arm.linux.org.uk>  [120208 08:06]:
>> 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".
> 
>> Signed-off-by: Russell King<rmk+kernel@arm.linux.org.uk>
> 
> Other than that:
> 
> Acked-by: Tony Lindgren<tony@atomide.com>

It looks like prm2xxx_3xxx.c does have the exact same issue than prm44xx.c.

arch/arm/mach-omap2/prm2xxx_3xxx.c:41:11: error: ?INT_34XX_PRCM_MPU_IRQ? undeclared here (not in a function)

Patch will follow.

Regards,
Benoit

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[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 <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/vc.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 031d116..ce45695 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -247,7 +247,7 @@ static void __init omap4_vc_init_channel(struct voltagedomain *voltdm)
  * omap_vc_i2c_init - initialize I2C interface to PMIC
  * @voltdm: voltage domain containing VC data
  *
- * Use PMIC supplied seetings for I2C high-speed mode and
+ * Use PMIC supplied settings for I2C high-speed mode and
  * master code (if set) and program the VC I2C configuration
  * register.
  *
@@ -292,8 +292,7 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)
 	u32 val;
 
 	if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel) {
-		pr_err("%s: PMIC info requried to configure vc for"
-			"vdd_%s not populated.Hence cannot initialize vc\n",
+		pr_err("%s: No PMIC info for vdd_%s\n",
 			__func__, voltdm->name);
 		return;
 	}
-- 
1.7.4.4

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:06]:
> 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 <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:06]:
>> 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 <rmk+kernel@arm.linux.org.uk>
>
> Acked-by: Tony Lindgren <tony@atomide.com>

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.

Thanks,

Kevin

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Tony Lindgren]

* Kevin Hilman <khilman@ti.com> [120208 14:35]:
> Tony Lindgren <tony@atomide.com> writes:
> 
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:06]:
> >> 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 <rmk+kernel@arm.linux.org.uk>
> >
> > Acked-by: Tony Lindgren <tony@atomide.com>
> 
> 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?

Regards,

Tony

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 03:53:58PM -0800, Tony Lindgren wrote:
> * Kevin Hilman <khilman@ti.com> [120208 14:35]:
> > Tony Lindgren <tony@atomide.com> writes:
> > 
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:06]:
> > >> 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 <rmk+kernel@arm.linux.org.uk>
> > >
> > > Acked-by: Tony Lindgren <tony@atomide.com>
> > 
> > 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?

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

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Kevin Hilman]

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

> On Wed, Feb 08, 2012 at 03:53:58PM -0800, Tony Lindgren wrote:
>> * Kevin Hilman <khilman@ti.com> [120208 14:35]:
>> > Tony Lindgren <tony@atomide.com> writes:
>> > 
>> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:06]:
>> > >> 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 <rmk+kernel@arm.linux.org.uk>
>> > >
>> > > Acked-by: Tony Lindgren <tony@atomide.com>
>> > 
>> > 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?
>
> 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.

Kevin

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 04:09:48PM -0800, Kevin Hilman wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> > 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.

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.

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Kevin Hilman]

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

> On Wed, Feb 08, 2012 at 04:09:48PM -0800, Kevin Hilman wrote:
>> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>> > 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.
>
> 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.

Thanks,

Kevin

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Tony Lindgren]

* Kevin Hilman <khilman@ti.com> [120208 15:49]:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> > On Wed, Feb 08, 2012 at 04:09:48PM -0800, Kevin Hilman wrote:
> >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> >> > 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.
> >
> > 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.

Then I'll move the following patches queued by Kevin from cleanup
into fixes:

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

Everybody OK with that?

Tony

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 04:40:27PM -0800, Tony Lindgren wrote:
> * Kevin Hilman <khilman@ti.com> [120208 15:49]:
> > Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> > 
> > > On Wed, Feb 08, 2012 at 04:09:48PM -0800, Kevin Hilman wrote:
> > >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> > >> > 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.
> > >
> > > 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.

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.

> 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?

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120209 08:18]:
> On Wed, Feb 08, 2012 at 04:40:27PM -0800, Tony Lindgren wrote:
> > * Kevin Hilman <khilman@ti.com> [120208 15:49]:
> > > Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> > > 
> > > > On Wed, Feb 08, 2012 at 04:09:48PM -0800, Kevin Hilman wrote:
> > > >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> > > >> > 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.
> > > >
> > > > 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.
> 
> 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.

OK no need to update patch 5 then.
 
> > 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?

OK. Please use your updated patch 1 as it contains the oops in
the description. Kevin, are you OK with that?

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.

Regards,

Tony


>From d269914ece0498f31603ecd85ed3d7a586b3cbcd Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@ti.com>
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 <abhilash.kv@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1e79bdf..00bff46 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -24,6 +24,7 @@
 #include "powerdomain.h"
 #include "clockdomain.h"
 #include "pm.h"
+#include "twl-common.h"
 
 static struct omap_device_pm_latency *pm_lats;
 
@@ -226,11 +227,8 @@ postcore_initcall(omap2_common_pm_init);
 
 static int __init omap2_common_pm_late_init(void)
 {
-	/* Init the OMAP TWL parameters */
-	omap3_twl_init();
-	omap4_twl_init();
-
 	/* Init the voltage layer */
+	omap_pmic_late_init();
 	omap_voltage_late_init();
 
 	/* Initialize the voltages */
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 5224357..10b20c6 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -30,6 +30,7 @@
 #include <plat/usb.h>
 
 #include "twl-common.h"
+#include "pm.h"
 
 static struct i2c_board_info __initdata pmic_i2c_board_info = {
 	.addr		= 0x48,
@@ -48,6 +49,16 @@ void __init omap_pmic_init(int bus, u32 clkrate,
 	omap_register_i2c_bus(bus, clkrate, &pmic_i2c_board_info, 1);
 }
 
+void __init omap_pmic_late_init(void)
+{
+	/* Init the OMAP TWL parameters (if PMIC has been registerd) */
+	if (!pmic_i2c_board_info.irq)
+		return;
+
+	omap3_twl_init();
+	omap4_twl_init();
+}
+
 #if defined(CONFIG_ARCH_OMAP3)
 static struct twl4030_usb_data omap3_usb_pdata = {
 	.usb_mode	= T2_USB_MODE_ULPI,
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 5e83a5b..275dde8 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -1,6 +1,8 @@
 #ifndef __OMAP_PMIC_COMMON__
 #define __OMAP_PMIC_COMMON__
 
+#include <plat/irqs.h>
+
 #define TWL_COMMON_PDATA_USB		(1 << 0)
 #define TWL_COMMON_PDATA_BCI		(1 << 1)
 #define TWL_COMMON_PDATA_MADC		(1 << 2)
@@ -30,6 +32,7 @@ struct twl4030_platform_data;
 
 void omap_pmic_init(int bus, u32 clkrate, const char *pmic_type, int pmic_irq,
 		    struct twl4030_platform_data *pmic_data);
+void omap_pmic_late_init(void);
 
 static inline void omap2_pmic_init(const char *pmic_type,
 				   struct twl4030_platform_data *pmic_data)

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [120209 08:47]:
> 
> 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 <khilman@ti.com>
> 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 <abhilash.kv@ti.com>
> Signed-off-by: Kevin Hilman <khilman@ti.com>

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

Regards,

Tony

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Russell King - ARM Linux]

On Thu, Feb 09, 2012 at 09:27:47AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [120209 08:47]:
> > 
> > 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 <khilman@ti.com>
> > 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 <abhilash.kv@ti.com>
> > Signed-off-by: Kevin Hilman <khilman@ti.com>
> 
> 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?

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120209 09:28]:
> On Thu, Feb 09, 2012 at 09:27:47AM -0800, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [120209 08:47]:
> > > 
> > > 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 <khilman@ti.com>
> > > 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 <abhilash.kv@ti.com>
> > > Signed-off-by: Kevin Hilman <khilman@ti.com>
> > 
> > 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?

Yes as long as Kevin is happy with them.

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

Regards,

Tony

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [120209 09:35]:
> 
> After you repost those two patches, I'll update linux-omap with
> your fixes + tty fixes + my fixes for people to test with.

The branch for testing is now pushed to:

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

Regards,

Tony

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [120208 15:22]:
> * Kevin Hilman <khilman@ti.com> [120208 14:35]:
> > Tony Lindgren <tony@atomide.com> writes:
> > 
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:06]:
> > >> 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 <rmk+kernel@arm.linux.org.uk>
> > >
> > > Acked-by: Tony Lindgren <tony@atomide.com>
> > 
> > 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?

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?

Regards,

Tony

[PATCH 05/16] ARM: omap: fix vc.c PMIC error message

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> * Tony Lindgren <tony@atomide.com> [120208 15:22]:
>> * Kevin Hilman <khilman@ti.com> [120208 14:35]:
>> > Tony Lindgren <tony@atomide.com> writes:
>> > 
>> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:06]:
>> > >> 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 <rmk+kernel@arm.linux.org.uk>
>> > >
>> > > Acked-by: Tony Lindgren <tony@atomide.com>
>> > 
>> > 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?
>
> 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?
> 

Yes.

The AM35xx devices that don't use TWL PMICs have the problem fixed by
this patch.

Looking back, I'm not sure why I called this a cleaup branch when all
the patches are fixes.

Kevin

[PATCH 06/16] ARM: omap: fix uninformative vc/i2c configuration error message

[Russell King - ARM Linux]

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 <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/vc.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index ce45695..ff58dc9 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -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;
 	}
 
-- 
1.7.4.4

[PATCH 06/16] ARM: omap: fix uninformative vc/i2c configuration error message

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:06]:
> 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 <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 06/16] ARM: omap: fix uninformative vc/i2c configuration error message

[Kevin Hilman]

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

> 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 <rmk+kernel@arm.linux.org.uk>

Acked-by: Kevin Hilman <khilman@ti.com>

> ---
>  arch/arm/mach-omap2/vc.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
> index ce45695..ff58dc9 100644
> --- a/arch/arm/mach-omap2/vc.c
> +++ b/arch/arm/mach-omap2/vc.c
> @@ -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;
>  	}

[PATCH 08/16] ARM: omap: fix section mismatch warning in mux.c

[Russell King - ARM Linux]

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 <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/mux.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index e1cc75d..f26b2fa 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -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)
 {
 }
 
-- 
1.7.4.4

[PATCH 08/16] ARM: omap: fix section mismatch warning in mux.c

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:07]:
> 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 <rmk+kernel@arm.linux.org.uk>

I'll separate out the muxing part for v3.4. For the -rc series:

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 09/16] ARM: omap: preemptively fix section mismatch in omap4_sdp4430_wifi_mux_init()

[Russell King - ARM Linux]

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 <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/board-4430sdp.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 39fba9d..49a5aab 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -841,7 +841,7 @@ static struct omap_board_mux board_mux[] __initdata = {
 #define board_mux	NULL
  #endif
 
-static void omap4_sdp4430_wifi_mux_init(void)
+static void __init omap4_sdp4430_wifi_mux_init(void)
 {
 	omap_mux_init_gpio(GPIO_WIFI_IRQ, OMAP_PIN_INPUT |
 				OMAP_PIN_OFF_WAKEUPENABLE);
-- 
1.7.4.4

[PATCH 09/16] ARM: omap: preemptively fix section mismatch in omap4_sdp4430_wifi_mux_init()

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:07]:
> 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 <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 10/16] ARM: omap: fix section mismatch warning for omap_secondary_startup()

[Russell King - ARM Linux]

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 <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/omap-headsmp.S |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

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
-- 
1.7.4.4

[PATCH 10/16] ARM: omap: fix section mismatch warning for omap_secondary_startup()

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:08]:
> 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 <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 11/16] ARM: omap: fix section mismatch error for omap_4430sdp_display_init()

[Russell King - ARM Linux]

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 <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/board-4430sdp.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 49a5aab..3d820bb 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;
 
-- 
1.7.4.4

[PATCH 11/16] ARM: omap: fix section mismatch error for omap_4430sdp_display_init()

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:08]:
> 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 <rmk+kernel@arm.linux.org.uk>

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 12/16] ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup()

[Russell King - ARM Linux]

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 <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/hsmmc.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

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;
 
-- 
1.7.4.4

[PATCH 12/16] ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup()

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:08]:
> 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 <rmk+kernel@arm.linux.org.uk>

We'll try to sort this out also properly for v3.4, meanwhile:

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 13/16] ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c

[Russell King - ARM Linux]

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.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/mux.c |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index f26b2fa..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;
-- 
1.7.4.4

[PATCH 13/16] ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:09]:
> 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.

These too will be back to __init for v3.4 when the mux stuff
is separated from omap2_hsmmc_init(). For -rc:

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 14/16] ARM: omap: fix wrapped error messages in omap_hwmod.c

[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 <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/omap_hwmod.c |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5192cab..eba6cd3 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1517,8 +1517,8 @@ static int _enable(struct omap_hwmod *oh)
 	if (oh->_state != _HWMOD_STATE_INITIALIZED &&
 	    oh->_state != _HWMOD_STATE_IDLE &&
 	    oh->_state != _HWMOD_STATE_DISABLED) {
-		WARN(1, "omap_hwmod: %s: enabled state can only be entered "
-		     "from initialized, idle, or disabled state\n", oh->name);
+		WARN(1, "omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state\n",
+			oh->name);
 		return -EINVAL;
 	}
 
@@ -1600,8 +1600,8 @@ static int _idle(struct omap_hwmod *oh)
 	pr_debug("omap_hwmod: %s: idling\n", oh->name);
 
 	if (oh->_state != _HWMOD_STATE_ENABLED) {
-		WARN(1, "omap_hwmod: %s: idle state can only be entered from "
-		     "enabled state\n", oh->name);
+		WARN(1, "omap_hwmod: %s: idle state can only be entered from enabled state\n",
+			oh->name);
 		return -EINVAL;
 	}
 
@@ -1682,8 +1682,8 @@ static int _shutdown(struct omap_hwmod *oh)
 
 	if (oh->_state != _HWMOD_STATE_IDLE &&
 	    oh->_state != _HWMOD_STATE_ENABLED) {
-		WARN(1, "omap_hwmod: %s: disabled state can only be entered "
-		     "from idle, or enabled state\n", oh->name);
+		WARN(1, "omap_hwmod: %s: disabled state can only be entered from idle, or enabled state\n",
+			oh->name);
 		return -EINVAL;
 	}
 
@@ -2240,8 +2240,8 @@ void omap_hwmod_ocp_barrier(struct omap_hwmod *oh)
 	BUG_ON(!oh);
 
 	if (!oh->class->sysc || !oh->class->sysc->sysc_flags) {
-		WARN(1, "omap_device: %s: OCP barrier impossible due to "
-		      "device configuration\n", oh->name);
+		WARN(1, "omap_device: %s: OCP barrier impossible due to device configuration\n",
+			oh->name);
 		return;
 	}
 
-- 
1.7.4.4

[PATCH 14/16] ARM: omap: fix wrapped error messages in omap_hwmod.c

[Paul Walmsley]

On Wed, 8 Feb 2012, Russell King - ARM Linux wrote:

> 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 <rmk+kernel@arm.linux.org.uk>

Thanks, I'll queue this for 3.4.


- Paul

[PATCH 14/16] ARM: omap: fix wrapped error messages in omap_hwmod.c

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [120208 09:09]:
> On Wed, 8 Feb 2012, Russell King - ARM Linux wrote:
> 
> > 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 <rmk+kernel@arm.linux.org.uk>
> 
> 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?

Regards,

Tony

[PATCH 14/16] ARM: omap: fix wrapped error messages in omap_hwmod.c

[Paul Walmsley]

On Wed, 8 Feb 2012, Tony Lindgren wrote:

> * Paul Walmsley <paul@pwsan.com> [120208 09:09]:
> > On Wed, 8 Feb 2012, Russell King - ARM Linux wrote:
> > 
> > > 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 <rmk+kernel@arm.linux.org.uk>
> > 
> > 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?

No objections.

Acked-by: Paul Walmsley <paul@pwsan.com>


- Paul

[PATCH 14/16] ARM: omap: fix wrapped error messages in omap_hwmod.c

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [120208 10:54]:
> On Wed, 8 Feb 2012, Tony Lindgren wrote:
> 
> > * Paul Walmsley <paul@pwsan.com> [120208 09:09]:
> > > On Wed, 8 Feb 2012, Russell King - ARM Linux wrote:
> > > 
> > > > 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 <rmk+kernel@arm.linux.org.uk>
> > > 
> > > 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?
> 
> No objections.
> 
> Acked-by: Paul Walmsley <paul@pwsan.com>

OK cool:

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 15/16] ARM: omap: resolve nebulous 'Error setting wl12xx data'

[Russell King - ARM Linux]

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 <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/board-4430sdp.c          |   13 +++++++++----
 arch/arm/mach-omap2/board-omap3evm.c         |   23 ++++++++++++++++-------
 arch/arm/mach-omap2/board-omap4panda.c       |    6 ++++--
 arch/arm/mach-omap2/board-zoom-peripherals.c |    6 ++++--
 4 files changed, 33 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 3d820bb..f0942f0 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -868,12 +868,17 @@ static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
 	.board_tcxo_clock = WL12XX_TCXOCLOCK_26,
 };
 
-static void omap4_sdp4430_wifi_init(void)
+static void __init omap4_sdp4430_wifi_init(void)
 {
+	int ret;
+
 	omap4_sdp4430_wifi_mux_init();
-	if (wl12xx_set_platform_data(&omap4_sdp4430_wlan_data))
-		pr_err("Error setting wl12xx data\n");
-	platform_device_register(&omap_vwlan_device);
+	ret = wl12xx_set_platform_data(&omap4_sdp4430_wlan_data);
+	if (ret)
+		pr_err("Error setting wl12xx data: %d\n", ret);
+	ret = platform_device_register(&omap_vwlan_device);
+	if (ret)
+		pr_err("Error registering wl12xx device: %d\n", ret);
 }
 
 static void __init omap_4430sdp_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 003fe34..c775bea 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -617,6 +617,21 @@ static struct gpio omap3_evm_ehci_gpios[] __initdata = {
 	{ OMAP3_EVM_EHCI_SELECT, GPIOF_OUT_INIT_LOW,   "select EHCI port" },
 };
 
+static void __init omap3_evm_wl12xx_init(void)
+{
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+	int ret;
+
+	/* WL12xx WLAN Init */
+	ret = wl12xx_set_platform_data(&omap3evm_wlan_data);
+	if (ret)
+		pr_err("error setting wl12xx data: %d\n", ret);
+	ret = platform_device_register(&omap3evm_wlan_regulator);
+	if (ret)
+		pr_err("error registering wl12xx device: %d\n", ret);
+#endif
+}
+
 static void __init omap3_evm_init(void)
 {
 	omap3_evm_get_revision();
@@ -665,13 +680,7 @@ static void __init omap3_evm_init(void)
 	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
 	omap3evm_init_smsc911x();
 	omap3_evm_display_init();
-
-#ifdef CONFIG_WL12XX_PLATFORM_DATA
-	/* WL12xx WLAN Init */
-	if (wl12xx_set_platform_data(&omap3evm_wlan_data))
-		pr_err("error setting wl12xx data\n");
-	platform_device_register(&omap3evm_wlan_regulator);
-#endif
+	omap3_evm_wl12xx_init();
 }
 
 MACHINE_START(OMAP3EVM, "OMAP3 EVM")
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 30ad40d..8a5c65d 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -478,13 +478,15 @@ void omap4_panda_display_init(void)
 static void __init omap4_panda_init(void)
 {
 	int package = OMAP_PACKAGE_CBS;
+	int ret;
 
 	if (omap_rev() == OMAP4430_REV_ES1_0)
 		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");
+	ret = wl12xx_set_platform_data(&omap_panda_wlan_data);
+	if (ret)
+		pr_err("error setting wl12xx data: %d\n", ret);
 
 	omap4_panda_i2c_init();
 	platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 8d7ce11..c126461 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -296,8 +296,10 @@ static void enable_board_wakeup_source(void)
 
 void __init zoom_peripherals_init(void)
 {
-	if (wl12xx_set_platform_data(&omap_zoom_wlan_data))
-		pr_err("error setting wl12xx data\n");
+	int ret = wl12xx_set_platform_data(&omap_zoom_wlan_data);
+
+	if (ret)
+		pr_err("error setting wl12xx data: %d\n", ret);
 
 	omap_i2c_init();
 	platform_device_register(&omap_vwlan_device);
-- 
1.7.4.4

[PATCH 15/16] ARM: omap: resolve nebulous 'Error setting wl12xx data'

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:09]:
> 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 <rmk+kernel@arm.linux.org.uk>

Looks right to me for -rc. Yes let's plan on fixing this for v3.4.

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 16/16] ARM: omap: disable cpuidle for OMAP3 platforms

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

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/cpuidle34xx.c |    2 ++
 arch/arm/mach-omap2/pm34xx.c      |    2 +-
 2 files changed, 3 insertions(+), 1 deletions(-)

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 fc69875..88e95e6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -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());
-- 
1.7.4.4

[PATCH 16/16] ARM: omap: disable cpuidle for OMAP3 platforms

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:10]:
> 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.
...

> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -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?

Regards,

Tony

[PATCH 16/16] ARM: omap: disable cpuidle for OMAP3 platforms

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 10:59:06AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:10]:
> > 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.
> ...
> 
> > --- a/arch/arm/mach-omap2/pm34xx.c
> > +++ b/arch/arm/mach-omap2/pm34xx.c
> > @@ -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.

That I'd agree on - because it is ugly and it's the best I could do
to revert the commit mentioned above short of reverting a whole raft
of other useful looking commits.

There's got to be a better solution.

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

Well, the fact of the matter is this is a regression, which means it
needs fixing for v3.3.  A simple patch would be preferred over more
complex patches.

So, if there's no other solution but to put the omap-serial patches
in for v3.3, then that's the best solution for v3.3.  First, someone
who understands this code needs to see whether there is a simpler
fix (eg, putting back what was there in a simpler form.)

However, leaving it in its current state for v3.3 is not acceptable.

[PATCH 16/16] ARM: omap: disable cpuidle for OMAP3 platforms

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:10]:
>> 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.
> ...
>
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -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?

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.

Kevin

[PATCH 16/16] ARM: omap: disable cpuidle for OMAP3 platforms

[Kevin Hilman]

Kevin Hilman <khilman@ti.com> writes:

> Tony Lindgren <tony@atomide.com> writes:
>
>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:10]:
>>> 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.
>> ...
>>
>>> --- a/arch/arm/mach-omap2/pm34xx.c
>>> +++ b/arch/arm/mach-omap2/pm34xx.c
>>> @@ -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?
>
> 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.

And he refused (on the 34xx thread). :(

It is a very targetted set of fixes that directly address the problems
in the UART driver, but he has decided they should wait because we went
through a couple revisions.

Maybe you can respond to Greg saying that we really need them for 3.3?

Kevin

[PATCH 00/16] rmk's patch series for fixing OMAP

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> 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've acked all but two. The if (1) hack must have some better
solution, then I'd like to see Paul's ack on the error formatting
patch.

Other than that go for it. Thanks for the nice series, too bad
these were not found earlier.

> 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 <tomi.valkeinen@ti.com>
> 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.

Not good.

Tony

[PATCH 00/16] rmk's patch series for fixing OMAP

[Florian Tobias Schandinat]

Hi Russell,

On 02/08/2012 04:35 PM, Russell King - ARM Linux wrote:
> commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
> Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
> 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.

> 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?

> 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.
This one was also somewhat special as I had to learn how to deal with PGP and
signed tags to make Linus happy.


Best regards,

Florian Tobias Schandinat

[PATCH 00/16] rmk's patch series for fixing OMAP

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 08:31:49PM +0000, Florian Tobias Schandinat wrote:
> Hi Russell,
> 
> On 02/08/2012 04:35 PM, Russell King - ARM Linux wrote:
> > commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
> > Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > 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.
> 
> > 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?

I've no idea when the problem was introduced, that's not the point that
I'm making.  The point that I'm making is that the patch is dated January
17th, it was apparantly committed on the 26th, and it went into mainline
on the 8th February.

For a patch which fixes a _hardware_ _destruction_ issue, three weeks is
_FAR_ too long for it to take to get into mainline.

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?

But that's not really the point.  The point is, for someone to sit on such
a patch for weeks is, in my opinion, as good as saying to your users "I
don't care if you bust your hardware."

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?

And why is there this seemingly lack of care for hardware destruction bugs?

Please, if it affects v3.2, PLEASE PLEASE PLEASE tell the stable people
who know nothing about this commit until I asked them this evening about
it.

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

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

[PATCH 00/16] rmk's patch series for fixing OMAP

[Tomi Valkeinen]

On Thu, 2012-02-09 at 00:53 +0000, Russell King - ARM Linux wrote:

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

> 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?

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

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120209/92321563/attachment.sig>

[PATCH 00/16] rmk's patch series for fixing OMAP

[Teresa Gamez]

Am Donnerstag, den 09.02.2012, 09:02 +0200 schrieb Tomi Valkeinen:
> On Thu, 2012-02-09 at 00:53 +0000, Russell King - ARM Linux wrote:
> 
> > 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.
> 
> > 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?
> 
> 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+.

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

Regards,
Teresa

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

[PATCH 00/16] rmk's patch series for fixing OMAP

[Tomi Valkeinen]

On Thu, 2012-02-09 at 09:30 +0100, Teresa Gamez wrote:
> Am Donnerstag, den 09.02.2012, 09:02 +0200 schrieb Tomi Valkeinen:

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

I pushed three branches to git://gitorious.org/linux-omap-dss2/linux.git

fixes/for-3.0-stable
fixes/for-3.1-stable
fixes/for-3.2-stable

Which contain the necessary backported patches for each version.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120209/d63a7694/attachment.sig>

[PATCH 01] ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found

[Russell King - ARM Linux]

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 <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/vp.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 807391d..0df8882 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -41,6 +41,11 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
 	u32 val, sys_clk_rate, timeout, waittime;
 	u32 vddmin, vddmax, vstepmin, vstepmax;
 
+	if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel) {
+		pr_err("%s: No PMIC info for vdd_%s\n", __func__, voltdm->name);
+		return;
+	}
+
 	if (!voltdm->read || !voltdm->write) {
 		pr_err("%s: No read/write API for accessing vdd_%s regs\n",
 			__func__, voltdm->name);
-- 
1.7.4.4

[PATCH 05] ARM: omap: fix vc.c PMIC error message

[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 <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mach-omap2/vc.c |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 031d116..a7da3da 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -247,7 +247,7 @@ static void __init omap4_vc_init_channel(struct voltagedomain *voltdm)
  * omap_vc_i2c_init - initialize I2C interface to PMIC
  * @voltdm: voltage domain containing VC data
  *
- * Use PMIC supplied seetings for I2C high-speed mode and
+ * Use PMIC supplied settings for I2C high-speed mode and
  * master code (if set) and program the VC I2C configuration
  * register.
  *
@@ -292,9 +292,7 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)
 	u32 val;
 
 	if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel) {
-		pr_err("%s: PMIC info requried to configure vc for"
-			"vdd_%s not populated.Hence cannot initialize vc\n",
-			__func__, voltdm->name);
+		pr_err("%s: No PMIC info for vdd_%s\n", __func__, voltdm->name);
 		return;
 	}
 
-- 
1.7.4.4