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

[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 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c

[Russell King - ARM Linux]

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

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

Unable to handle kernel NULL pointer dereference at virtual address 00000038
pgd = c0004000
[00000038] *pgd\0000000
Internal error: Oops: 5 [#1] PREEMPT
Modules linked in:
CPU: 0    Not tainted  (3.3.0-rc2+ #228)
PC is at regulator_enable+0x10/0x70
LR is at omapdss_dpi_display_enable+0x54/0x15c
pc : [<c01b9a08>]    lr : [<c01af994>]    psr: 60000013
sp : c181fd90  ip : c181fdb0  fp : c181fdac
r10: c042eff0  r9 : 00000060  r8 : c044a164
r7 : c042c0e4  r6 : c042bd60  r5 : 00000000  r4 : c042bd60
r3 : c084de48  r2 : c181e000  r1 : c042bd60  r0 : 00000000
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: (0xc181fd90 to 0xc1820000)
fd80:                                     c001754c c042bd60 00000000 c042bd60
fda0: c181fdcc c181fdb0 c01af994 c01b9a04 c0016104 c042bd60 c042bd60 c044a338
fdc0: c181fdec c181fdd0 c01b5ed0 c01af94c c042bd60 c042bd60 c1aa8000 c1aa8a0c
fde0: c181fe04 c181fdf0 c01b5f54 c01b5ea8 c02fc18c c042bd60 c181fe3c c181fe08
fe00: c01b2a18 c01b5f48 c01aed14 c02fc160 c01df8ec 00000002 c042bd60 00000003
fe20: c042bd60 c1aa8000 c1aa8a0c c042eff8 c181fe84 c181fe40 c01b3874 c01b29fc
fe40: c042eff8 00000000 c042f000 c0449db8 c044ed78 00000000 c181fe74 c042eff8
fe60: c042eff8 c0449db8 c0449db8 c044ed78 00000000 00000000 c181fe94 c181fe88
fe80: c01e452c c01b35e8 c181feb4 c181fe98 c01e2fdc c01e4518 c042eff8 c0449db8
fea0: c0449db8 c181fef0 c181fecc c181feb8 c01e3104 c01e2f48 c042eff8 c042f02c
fec0: c181feec c181fed0 c01e3190 c01e30c0 c01e311c 00000000 c01e311c c0449db8
fee0: c181ff14 c181fef0 c01e1998 c01e3128 c18330a8 c1892290 c04165e8 c0449db8
ff00: c0449db8 c1ab60c0 c181ff24 c181ff18 c01e2e28 c01e194c c181ff54 c181ff28
ff20: c01e2218 c01e2e14 c039afed c181ff38 c04165e8 c041660c c0449db8 00000013
ff40: 00000000 c03ffdb8 c181ff7c c181ff58 c01e384c c01e217c c181ff7c c04165e8
ff60: c041660c c003a37c 00000013 00000000 c181ff8c c181ff80 c01e488c c01e3790
ff80: c181ff9c c181ff90 c03ffdcc c01e484c c181ffdc c181ffa0 c0008798 c03ffdc4
ffa0: c181ffc4 c181ffb0 c0056440 c0187810 c003a37c c04165e8 c041660c c003a37c
ffc0: 00000013 00000000 00000000 00000000 c181fff4 c181ffe0 c03ea284 c0008708
ffe0: 00000000 c03ea208 00000000 c181fff8 c003a37c c03ea214 1073cec0 01f7ee08
Backtrace:
[<c01b99f8>] (regulator_enable+0x0/0x70) from [<c01af994>] (omapdss_dpi_display_enable+0x54/0x15c)
 r6:c042bd60 r5:00000000 r4:c042bd60
[<c01af940>] (omapdss_dpi_display_enable+0x0/0x15c) from [<c01b5ed0>] (generic_dpi_panel_power_on+0x34/0x78)
 r6:c044a338 r5:c042bd60 r4:c042bd60
[<c01b5e9c>] (generic_dpi_panel_power_on+0x0/0x78) from [<c01b5f54>] (generic_dpi_panel_enable+0x18/0x28)
 r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:c042bd60
[<c01b5f3c>] (generic_dpi_panel_enable+0x0/0x28) from [<c01b2a18>] (omapfb_init_display+0x28/0x150)
 r4:c042bd60
[<c01b29f0>] (omapfb_init_display+0x0/0x150) from [<c01b3874>] (omapfb_probe+0x298/0x318)
 r8:c042eff8 r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:00000003
[<c01b35dc>] (omapfb_probe+0x0/0x318) from [<c01e452c>] (platform_drv_probe+0x20/0x24)
[<c01e450c>] (platform_drv_probe+0x0/0x24) from [<c01e2fdc>] (really_probe+0xa0/0x178)
[<c01e2f3c>] (really_probe+0x0/0x178) from [<c01e3104>] (driver_probe_device+0x50/0x68)
 r7:c181fef0 r6:c0449db8 r5:c0449db8 r4:c042eff8
[<c01e30b4>] (driver_probe_device+0x0/0x68) from [<c01e3190>] (__driver_attach+0x74/0x98)
 r5:c042f02c r4:c042eff8
[<c01e311c>] (__driver_attach+0x0/0x98) from [<c01e1998>] (bus_for_each_dev+0x58/0x98)
 r6:c0449db8 r5:c01e311c r4:00000000
[<c01e1940>] (bus_for_each_dev+0x0/0x98) from [<c01e2e28>] (driver_attach+0x20/0x28)
 r7:c1ab60c0 r6:c0449db8 r5:c0449db8 r4:c04165e8
[<c01e2e08>] (driver_attach+0x0/0x28) from [<c01e2218>] (bus_add_driver+0xa8/0x22c)
[<c01e2170>] (bus_add_driver+0x0/0x22c) from [<c01e384c>] (driver_register+0xc8/0x154)
[<c01e3784>] (driver_register+0x0/0x154) from [<c01e488c>] (platform_driver_register+0x4c/0x60)
 r8:00000000 r7:00000013 r6:c003a37c r5:c041660c r4:c04165e8
[<c01e4840>] (platform_driver_register+0x0/0x60) from [<c03ffdcc>] (omapfb_init+0x14/0x34)
[<c03ffdb8>] (omapfb_init+0x0/0x34) from [<c0008798>] (do_one_initcall+0x9c/0x164)
[<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03ea284>] (kernel_init+0x7c/0x120)
[<c03ea208>] (kernel_init+0x0/0x120) from [<c003a37c>] (do_exit+0x0/0x2d8)
 r5:c03ea208 r4:00000000
Code: e1a0c00d e92dd870 e24cb004 e24dd004 (e5906038)
---[ end trace 9e2474c2e193b223 ]---

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/video/omap2/dss/dpi.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 395d658..faaf305 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -180,6 +180,11 @@ int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
 {
 	int r;
 
+	if (cpu_is_omap34xx() && !dpi.vdds_dsi_reg) {
+		DSSERR("no VDSS_DSI regulator\n");
+		return -ENODEV;
+	}
+
 	if (dssdev->manager = NULL) {
 		DSSERR("failed to enable display: no manager\n");
 		return -ENODEV;
-- 
1.7.4.4

[PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c

[Russell King - ARM Linux]

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

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

Unable to handle kernel NULL pointer dereference at virtual address 00000038
pgd = c0004000
[00000038] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT
Modules linked in:
CPU: 0    Not tainted  (3.3.0-rc2+ #228)
PC is at regulator_enable+0x10/0x70
LR is at omapdss_dpi_display_enable+0x54/0x15c
pc : [<c01b9a08>]    lr : [<c01af994>]    psr: 60000013
sp : c181fd90  ip : c181fdb0  fp : c181fdac
r10: c042eff0  r9 : 00000060  r8 : c044a164
r7 : c042c0e4  r6 : c042bd60  r5 : 00000000  r4 : c042bd60
r3 : c084de48  r2 : c181e000  r1 : c042bd60  r0 : 00000000
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: (0xc181fd90 to 0xc1820000)
fd80:                                     c001754c c042bd60 00000000 c042bd60
fda0: c181fdcc c181fdb0 c01af994 c01b9a04 c0016104 c042bd60 c042bd60 c044a338
fdc0: c181fdec c181fdd0 c01b5ed0 c01af94c c042bd60 c042bd60 c1aa8000 c1aa8a0c
fde0: c181fe04 c181fdf0 c01b5f54 c01b5ea8 c02fc18c c042bd60 c181fe3c c181fe08
fe00: c01b2a18 c01b5f48 c01aed14 c02fc160 c01df8ec 00000002 c042bd60 00000003
fe20: c042bd60 c1aa8000 c1aa8a0c c042eff8 c181fe84 c181fe40 c01b3874 c01b29fc
fe40: c042eff8 00000000 c042f000 c0449db8 c044ed78 00000000 c181fe74 c042eff8
fe60: c042eff8 c0449db8 c0449db8 c044ed78 00000000 00000000 c181fe94 c181fe88
fe80: c01e452c c01b35e8 c181feb4 c181fe98 c01e2fdc c01e4518 c042eff8 c0449db8
fea0: c0449db8 c181fef0 c181fecc c181feb8 c01e3104 c01e2f48 c042eff8 c042f02c
fec0: c181feec c181fed0 c01e3190 c01e30c0 c01e311c 00000000 c01e311c c0449db8
fee0: c181ff14 c181fef0 c01e1998 c01e3128 c18330a8 c1892290 c04165e8 c0449db8
ff00: c0449db8 c1ab60c0 c181ff24 c181ff18 c01e2e28 c01e194c c181ff54 c181ff28
ff20: c01e2218 c01e2e14 c039afed c181ff38 c04165e8 c041660c c0449db8 00000013
ff40: 00000000 c03ffdb8 c181ff7c c181ff58 c01e384c c01e217c c181ff7c c04165e8
ff60: c041660c c003a37c 00000013 00000000 c181ff8c c181ff80 c01e488c c01e3790
ff80: c181ff9c c181ff90 c03ffdcc c01e484c c181ffdc c181ffa0 c0008798 c03ffdc4
ffa0: c181ffc4 c181ffb0 c0056440 c0187810 c003a37c c04165e8 c041660c c003a37c
ffc0: 00000013 00000000 00000000 00000000 c181fff4 c181ffe0 c03ea284 c0008708
ffe0: 00000000 c03ea208 00000000 c181fff8 c003a37c c03ea214 1073cec0 01f7ee08
Backtrace:
[<c01b99f8>] (regulator_enable+0x0/0x70) from [<c01af994>] (omapdss_dpi_display_enable+0x54/0x15c)
 r6:c042bd60 r5:00000000 r4:c042bd60
[<c01af940>] (omapdss_dpi_display_enable+0x0/0x15c) from [<c01b5ed0>] (generic_dpi_panel_power_on+0x34/0x78)
 r6:c044a338 r5:c042bd60 r4:c042bd60
[<c01b5e9c>] (generic_dpi_panel_power_on+0x0/0x78) from [<c01b5f54>] (generic_dpi_panel_enable+0x18/0x28)
 r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:c042bd60
[<c01b5f3c>] (generic_dpi_panel_enable+0x0/0x28) from [<c01b2a18>] (omapfb_init_display+0x28/0x150)
 r4:c042bd60
[<c01b29f0>] (omapfb_init_display+0x0/0x150) from [<c01b3874>] (omapfb_probe+0x298/0x318)
 r8:c042eff8 r7:c1aa8a0c r6:c1aa8000 r5:c042bd60 r4:00000003
[<c01b35dc>] (omapfb_probe+0x0/0x318) from [<c01e452c>] (platform_drv_probe+0x20/0x24)
[<c01e450c>] (platform_drv_probe+0x0/0x24) from [<c01e2fdc>] (really_probe+0xa0/0x178)
[<c01e2f3c>] (really_probe+0x0/0x178) from [<c01e3104>] (driver_probe_device+0x50/0x68)
 r7:c181fef0 r6:c0449db8 r5:c0449db8 r4:c042eff8
[<c01e30b4>] (driver_probe_device+0x0/0x68) from [<c01e3190>] (__driver_attach+0x74/0x98)
 r5:c042f02c r4:c042eff8
[<c01e311c>] (__driver_attach+0x0/0x98) from [<c01e1998>] (bus_for_each_dev+0x58/0x98)
 r6:c0449db8 r5:c01e311c r4:00000000
[<c01e1940>] (bus_for_each_dev+0x0/0x98) from [<c01e2e28>] (driver_attach+0x20/0x28)
 r7:c1ab60c0 r6:c0449db8 r5:c0449db8 r4:c04165e8
[<c01e2e08>] (driver_attach+0x0/0x28) from [<c01e2218>] (bus_add_driver+0xa8/0x22c)
[<c01e2170>] (bus_add_driver+0x0/0x22c) from [<c01e384c>] (driver_register+0xc8/0x154)
[<c01e3784>] (driver_register+0x0/0x154) from [<c01e488c>] (platform_driver_register+0x4c/0x60)
 r8:00000000 r7:00000013 r6:c003a37c r5:c041660c r4:c04165e8
[<c01e4840>] (platform_driver_register+0x0/0x60) from [<c03ffdcc>] (omapfb_init+0x14/0x34)
[<c03ffdb8>] (omapfb_init+0x0/0x34) from [<c0008798>] (do_one_initcall+0x9c/0x164)
[<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03ea284>] (kernel_init+0x7c/0x120)
[<c03ea208>] (kernel_init+0x0/0x120) from [<c003a37c>] (do_exit+0x0/0x2d8)
 r5:c03ea208 r4:00000000
Code: e1a0c00d e92dd870 e24cb004 e24dd004 (e5906038)
---[ end trace 9e2474c2e193b223 ]---

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/video/omap2/dss/dpi.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 395d658..faaf305 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -180,6 +180,11 @@ int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
 {
 	int r;
 
+	if (cpu_is_omap34xx() && !dpi.vdds_dsi_reg) {
+		DSSERR("no VDSS_DSI regulator\n");
+		return -ENODEV;
+	}
+
 	if (dssdev->manager == NULL) {
 		DSSERR("failed to enable display: no manager\n");
 		return -ENODEV;
-- 
1.7.4.4

[PATCH 03/16] ARM: omap: fix broken twl-core dependencies and ifdefs

[Russell King - ARM Linux]

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

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

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

However, even with IRQ_DOMAIN enabled, the driver oopses:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] SMP
Modules linked in:
CPU: 1    Not tainted  (3.3.0-rc2+ #271)
PC is at irq_domain_add+0x1c/0x134
LR is at twl_probe+0xd0/0x370
pc : [<c007bad0>]    lr : [<c029baac>]    psr: 00000113
sp : df843c48  ip : df843c68  fp : df843c64
r10: c02b93e4  r9 : 00000000  r8 : c029b9dc
r7 : df9d8a00  r6 : c03bef90  r5 : 00000000  r4 : c03f5240
r3 : 00000000  r2 : c03f5240  r1 : 00000015  r0 : c03f5240
Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 8000404a  DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xdf8422f0)
Stack: (0xdf843c48 to 0xdf844000)
3c40:                   00000014 00000170 00000014 c03bef90 df843c9c df843c68
3c60: c029baac c007bac0 00000000 df9d8a20 00000001 c03cd238 c02b93e4 df9d8a20
3c80: df9d8a04 df9d8a00 c029b9dc df8cae08 df843cc4 df843ca0 c01eee70 c029b9e8
...
Backtrace:
[<c007bab4>] (irq_domain_add+0x0/0x134) from [<c029baac>] (twl_probe+0xd0/0x370)
 r6:c03bef90 r5:00000014 r4:00000170
[<c029b9dc>] (twl_probe+0x0/0x370) from [<c01eee70>] (i2c_device_probe+0xb0/0xe4)
[<c01eedc0>] (i2c_device_probe+0x0/0xe4) from [<c01d1f34>] (really_probe+0xa0/0x178)
 r8:df8f0070 r7:c03cd238 r6:df9d8a20 r5:df9d8a20 r4:df9d8a20
[<c01d1e94>] (really_probe+0x0/0x178) from [<c01d205c>] (driver_probe_device+0x50/0x68)
 r7:df843d18 r6:df9d8a20 r5:c03cd238 r4:df9d8a20
[<c01d200c>] (driver_probe_device+0x0/0x68) from [<c01d2148>] (__device_attach+0x44/0x48)
 r5:df9d8a20 r4:c03cd238
[<c01d2104>] (__device_attach+0x0/0x48) from [<c01d0840>] (bus_for_each_drv+0x58/0x98)
 r5:c01d2104 r4:00000000
[<c01d07e8>] (bus_for_each_drv+0x0/0x98) from [<c01d21f8>] (device_attach+0x80/0xac)
 r7:df9d8a28 r6:df9d8a54 r5:c03cd978 r4:df9d8a20
[<c01d2178>] (device_attach+0x0/0xac) from [<c01d1430>] (bus_probe_device+0x34/0xa4)
 r6:df9d8a20 r5:c03cd978 r4:df9d8a20
[<c01d13fc>] (bus_probe_device+0x0/0xa4) from [<c01cffb0>] (device_add+0x2a0/0x420)
 r6:00000000 r5:df9d8a20 r4:df9d8a20
[<c01cfd10>] (device_add+0x0/0x420) from [<c01d0150>] (device_register+0x20/0x24)
 r8:df9d8a00 r7:df9d8a04 r6:df8f0048 r5:df9d8a00 r4:df9d8a20
[<c01d0130>] (device_register+0x0/0x24) from [<c01ef8d4>] (i2c_new_device+0x118/0x180)
 r4:df9d8a20
[<c01ef7bc>] (i2c_new_device+0x0/0x180) from [<c01efc88>] (i2c_register_adapter+0x140/0x204)
 r8:c03cd970 r7:00000000 r6:df8f0070 r5:df8a6300 r4:df8f0048
[<c01efb48>] (i2c_register_adapter+0x0/0x204) from [<c01efe9c>] (i2c_add_numbered_adapter+0xb4/0xcc)
 r8:df8a4c54 r7:df8cae00 r6:df843e2c r5:df8f0048 r4:00000000
[<c01efde8>] (i2c_add_numbered_adapter+0x0/0xcc) from [<c029ce1c>] (omap_i2c_probe+0x2f8/0x3b4)
 r6:00000000 r5:df8f0000 r4:df8f0070
[<c029cb24>] (omap_i2c_probe+0x0/0x3b4) from [<c01d3484>] (platform_drv_probe+0x20/0x24)
[<c01d3464>] (platform_drv_probe+0x0/0x24) from [<c01d1f34>] (really_probe+0xa0/0x178)
[<c01d1e94>] (really_probe+0x0/0x178) from [<c01d205c>] (driver_probe_device+0x50/0x68)
 r7:df843ef0 r6:c03cdb2c r5:c03cdb2c r4:df8cae08
[<c01d200c>] (driver_probe_device+0x0/0x68) from [<c01d20e0>] (__driver_attach+0x6c/0x90)
 r5:df8cae3c r4:df8cae08
[<c01d2074>] (__driver_attach+0x0/0x90) from [<c01d08d8>] (bus_for_each_dev+0x58/0x98)
 r6:c03cdb2c r5:c01d2074 r4:00000000
[<c01d0880>] (bus_for_each_dev+0x0/0x98) from [<c01d1d80>] (driver_attach+0x20/0x28)
 r7:df880b80 r6:c03cdb2c r5:c03cdb2c r4:c0394f28
[<c01d1d60>] (driver_attach+0x0/0x28) from [<c01d115c>] (bus_add_driver+0xb4/0x230)
[<c01d10a8>] (bus_add_driver+0x0/0x230) from [<c01d278c>] (driver_register+0xc8/0x154)
[<c01d26c4>] (driver_register+0x0/0x154) from [<c01d37e4>] (platform_driver_register+0x4c/0x60)
 r8:00000000 r7:00000013 r6:c00384c8 r5:c0395180 r4:c0394f28
[<c01d3798>] (platform_driver_register+0x0/0x60) from [<c038626c>] (omap_i2c_init_driver+0x14/0x1c)
[<c0386258>] (omap_i2c_init_driver+0x0/0x1c) from [<c00087b8>] (do_one_initcall+0x9c/0x164)
[<c000871c>] (do_one_initcall+0x0/0x164) from [<c036c2f4>] (kernel_init+0x90/0x138)
[<c036c264>] (kernel_init+0x0/0x138) from [<c00384c8>] (do_exit+0x0/0x2ec)
 r5:c036c264 r4:00000000
<0>Code: e24dd004 e5903014 e1a04000 e5905010 (e5933000)
<4>---[ end trace 1b75b31a2719ed1c ]---

This happens because we try to register an IRQ domain with a NULL ops
structure, and the first thing irq_domain_add() does is try to
dereference this ops structure.

So, fix the problem by getting rid of the incorrect OF_IRQ ifdef and
wrapping the IRQ domain bits of the driver with an IRQ_DOMAIN ifdef
instead.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/mfd/Kconfig    |    2 +-
 drivers/mfd/twl-core.c |    6 ++++--
 2 files changed, 5 insertions(+), 3 deletions(-)

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

[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

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

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

[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 07/16] ARM: omap: fix section mismatch errors in TWL PMIC driver

[Russell King - ARM Linux]

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

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

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/mfd/twl4030-power.c |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index d905f51..79ca33d 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -124,7 +124,7 @@ static u8 res_config_addrs[] = {
 	[RES_MAIN_REF]	= 0x94,
 };
 
-static int __init twl4030_write_script_byte(u8 address, u8 byte)
+static int __devinit twl4030_write_script_byte(u8 address, u8 byte)
 {
 	int err;
 
@@ -138,7 +138,7 @@ static int __init twl4030_write_script_byte(u8 address, u8 byte)
 	return err;
 }
 
-static int __init twl4030_write_script_ins(u8 address, u16 pmb_message,
+static int __devinit twl4030_write_script_ins(u8 address, u16 pmb_message,
 					   u8 delay, u8 next)
 {
 	int err;
@@ -158,7 +158,7 @@ static int __init twl4030_write_script_ins(u8 address, u16 pmb_message,
 	return err;
 }
 
-static int __init twl4030_write_script(u8 address, struct twl4030_ins *script,
+static int __devinit twl4030_write_script(u8 address, struct twl4030_ins *script,
 				       int len)
 {
 	int err;
@@ -183,7 +183,7 @@ static int __init twl4030_write_script(u8 address, struct twl4030_ins *script,
 	return err;
 }
 
-static int __init twl4030_config_wakeup3_sequence(u8 address)
+static int __devinit twl4030_config_wakeup3_sequence(u8 address)
 {
 	int err;
 	u8 data;
@@ -208,7 +208,7 @@ static int __init twl4030_config_wakeup3_sequence(u8 address)
 	return err;
 }
 
-static int __init twl4030_config_wakeup12_sequence(u8 address)
+static int __devinit twl4030_config_wakeup12_sequence(u8 address)
 {
 	int err = 0;
 	u8 data;
@@ -262,7 +262,7 @@ static int __init twl4030_config_wakeup12_sequence(u8 address)
 	return err;
 }
 
-static int __init twl4030_config_sleep_sequence(u8 address)
+static int __devinit twl4030_config_sleep_sequence(u8 address)
 {
 	int err;
 
@@ -276,7 +276,7 @@ static int __init twl4030_config_sleep_sequence(u8 address)
 	return err;
 }
 
-static int __init twl4030_config_warmreset_sequence(u8 address)
+static int __devinit twl4030_config_warmreset_sequence(u8 address)
 {
 	int err;
 	u8 rd_data;
@@ -324,7 +324,7 @@ static int __init twl4030_config_warmreset_sequence(u8 address)
 	return err;
 }
 
-static int __init twl4030_configure_resource(struct twl4030_resconfig *rconfig)
+static int __devinit twl4030_configure_resource(struct twl4030_resconfig *rconfig)
 {
 	int rconfig_addr;
 	int err;
@@ -416,7 +416,7 @@ static int __init twl4030_configure_resource(struct twl4030_resconfig *rconfig)
 	return 0;
 }
 
-static int __init load_twl4030_script(struct twl4030_script *tscript,
+static int __devinit load_twl4030_script(struct twl4030_script *tscript,
 	       u8 address)
 {
 	int err;
@@ -527,7 +527,7 @@ void twl4030_power_off(void)
 		pr_err("TWL4030 Unable to power off\n");
 }
 
-void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
+void __devinit twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
 {
 	int err = 0;
 	int i;
-- 
1.7.4.4

[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

[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 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()

[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 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()

[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 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()

[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 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()

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

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

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

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

[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

Re: [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

[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

Re: [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]

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

Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> When a PMIC is not found, this driver is unable to obtain its
> 'vdds_dsi_reg' regulator.  Even through its initialization function
> fails, other code still calls its enable function, which fails to
> check whether it has this regulator before asking for it to be enabled.
> 
> This fixes the oops, however a better fix would be to sort out the
> upper layers to prevent them calling into a module which failed to
> initialize.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

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

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

Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> When a PMIC is not found, this driver is unable to obtain its
> 'vdds_dsi_reg' regulator.  Even through its initialization function
> fails, other code still calls its enable function, which fails to
> check whether it has this regulator before asking for it to be enabled.
> 
> This fixes the oops, however a better fix would be to sort out the
> upper layers to prevent them calling into a module which failed to
> initialize.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

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

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

Re: [PATCH 03/16] ARM: omap: fix broken twl-core dependencies and ifdefs

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> In commit aeb5032b3f, a dependency on IRQ_DOMAIN was added, which causes
> regressions on previously working setups: a previously working non-DT
> kernel configuration now loses its PMIC support.  The lack of PMIC
> support in turn causes the loss of other functionality the kernel had.
> 
> This dependency was added because the driver now registers its
> interrupts with the IRQ domain code, presumably to prevent a build error.
> 
> The result is that OMAP3 oopses in the vp.c code (fixed by a previous
> commit) due to the lack of PMIC support.
> 
> However, even with IRQ_DOMAIN enabled, the driver oopses:
...
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This should be checked that it compiles on other platforms like x86.

Other than that:

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

Re: [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

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

Re: [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

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

Re: [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

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

Re: [PATCH 07/16] ARM: omap: fix section mismatch errors in TWL PMIC driver

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:07]:
> WARNING: drivers/mfd/built-in.o(.devinit.text+0x258): Section mismatch in reference from the function twl_probe() to the function .init.text:twl4030_power_init()
> The function __devinit twl_probe() references
> a function __init twl4030_power_init().
> If twl4030_power_init is only used by twl_probe then
> annotate twl4030_power_init with a matching annotation.
> 
> twl4030_power_init() references other __init marked functions, so
> these too must become __devinit.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

We'll take a look at sorting this out for v3.4 properly.
Meanwhile:

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

Re: [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 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>

Re: [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 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>

Re: [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 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>

Re: [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 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>

Re: [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 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>

Re: [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 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>

Re: [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

[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

Re: [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 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>

Re: [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

[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

Re: [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

Re: [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

[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

Re: [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

[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

Re: [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 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>

Re: [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

Re: [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

[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

Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 10:36:07AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> > When a PMIC is not found, this driver is unable to obtain its
> > 'vdds_dsi_reg' regulator.  Even through its initialization function
> > fails, other code still calls its enable function, which fails to
> > check whether it has this regulator before asking for it to be enabled.
> > 
> > This fixes the oops, however a better fix would be to sort out the
> > upper layers to prevent them calling into a module which failed to
> > initialize.
> > 
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Tomi can look into fixing this properly for v3.4:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

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

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

Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c

[Russell King - ARM Linux]

On Wed, Feb 08, 2012 at 10:36:07AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> > When a PMIC is not found, this driver is unable to obtain its
> > 'vdds_dsi_reg' regulator.  Even through its initialization function
> > fails, other code still calls its enable function, which fails to
> > check whether it has this regulator before asking for it to be enabled.
> > 
> > This fixes the oops, however a better fix would be to sort out the
> > upper layers to prevent them calling into a module which failed to
> > initialize.
> > 
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Tomi can look into fixing this properly for v3.4:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

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

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

Re: [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

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

Re: [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

[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

Re: [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 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;
>  	}

Re: [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]

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

Re: [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 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

Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 14:19]:
> On Wed, Feb 08, 2012 at 10:36:07AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> > > When a PMIC is not found, this driver is unable to obtain its
> > > 'vdds_dsi_reg' regulator.  Even through its initialization function
> > > fails, other code still calls its enable function, which fails to
> > > check whether it has this regulator before asking for it to be enabled.
> > > 
> > > This fixes the oops, however a better fix would be to sort out the
> > > upper layers to prevent them calling into a module which failed to
> > > initialize.
> > > 
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > 
> > Tomi can look into fixing this properly for v3.4:
> > 
> > Acked-by: Tony Lindgren <tony@atomide.com>
> 
> No, it's a thing for v3.3, because you can still get this oops.
> 
> I expect _most_ of these patches will go into v3.3, and anything with
> 'fix' or 'oops' in especially I want to see in v3.3.

I acked your patch for -rc. Then Tomi can work on  the "better fix part"
you mention above for v3.4 and that's what I meant by my comment
above.

Or is there something else that needs fixing for the -rc series there?

Regards,

Tony

Re: [PATCH 02/16] ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 14:19]:
> On Wed, Feb 08, 2012 at 10:36:07AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [120208 08:05]:
> > > When a PMIC is not found, this driver is unable to obtain its
> > > 'vdds_dsi_reg' regulator.  Even through its initialization function
> > > fails, other code still calls its enable function, which fails to
> > > check whether it has this regulator before asking for it to be enabled.
> > > 
> > > This fixes the oops, however a better fix would be to sort out the
> > > upper layers to prevent them calling into a module which failed to
> > > initialize.
> > > 
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > 
> > Tomi can look into fixing this properly for v3.4:
> > 
> > Acked-by: Tony Lindgren <tony@atomide.com>
> 
> No, it's a thing for v3.3, because you can still get this oops.
> 
> I expect _most_ of these patches will go into v3.3, and anything with
> 'fix' or 'oops' in especially I want to see in v3.3.

I acked your patch for -rc. Then Tomi can work on  the "better fix part"
you mention above for v3.4 and that's what I meant by my comment
above.

Or is there something else that needs fixing for the -rc series there?

Regards,

Tony

Re: [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

[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

Re: [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

[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

Re: [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

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

Re: [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

[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

Re: [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

[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

Re: [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 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

Re: [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

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

Re: [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

[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

Re: [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

[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

Re: [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?)

Re: [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

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

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

[Tomi Valkeinen]

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

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Tomi Valkeinen]

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

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

Re: [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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[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

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

[Tomi Valkeinen]

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

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Tomi Valkeinen]

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

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

Re: [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

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

Re: [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

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

Re: [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 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

Re: [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]

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

Re: [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

[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

Re: [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

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

[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

Re: [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]

* 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

Re: [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> [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

Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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