for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Tony,

The following pull request will bring hwmod driver conversions for watchdog, UART and i2c drivers. It is based on your omap-for-linus branch.

The i2c driver is waiting for final signoff/ack from the upstream subsystem maintainers, but are otherwise ready to go for broader testing. After I get the final ack, I will update the branch for a final pull.

In the meantime, I'd like to get them into l-o master (or omap-testing) for broader testing.

Note this also depends on a handful of patches from my pm-backports branch, most of which you have picked into omap-testing, except for the one I just posted to linux-arm-kernel:

ARM: add cpu_idle_wait() to support CPUidle on SMP systems.

This one is required now that the default config enables SMP.

Quoted 6 lines · Kevin Hilman

Tony,

The following pull request will bring hwmod driver conversions for watchdog, UART and i2c drivers. It is based on your omap-for-linus branch.

Quoted 7 lines

The i2c driver is waiting for final signoff/ack from the upstream subsystem maintainers, but are otherwise ready to go for broader testing. After I get the final ack, I will update the branch for a final pull.

In the meantime, I'd like to get them into l-o master (or omap-testing) for broader testing.

Tried pulling it but I'm getting tons of these errors on omap2:

WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1237 _omap_hwmod_idle+0x28/0xd8()
omap_hwmod: i2c1: idle state can only be entered from enabled state
Modules linked in:
[<c0054534>] (unwind_backtrace+0x0/0xec) from [<c008b55c>] (warn_slowpath_common+0x4c/0x64)
[<c008b55c>] (warn_slowpath_common+0x4c/0x64) from [<c008b5f4>] (warn_slowpath_fmt+0x2c/0x3c)
[<c008b5f4>] (warn_slowpath_fmt+0x2c/0x3c) from [<c005e2f8>] (_omap_hwmod_idle+0x28/0xd8)
[<c005e2f8>] (_omap_hwmod_idle+0x28/0xd8) from [<c005e3d0>] (omap_hwmod_idle+0x28/0x38)
[<c005e3d0>] (omap_hwmod_idle+0x28/0x38) from [<c006bc6c>] (omap_device_idle_hwmods+0x1c/0x34)
[<c006bc6c>] (omap_device_idle_hwmods+0x1c/0x34) from [<c006bd40>] (_omap_device_deactivate+0x4c/0x154)
[<c006bd40>] (_omap_device_deactivate+0x4c/0x154) from [<c006c018>] (omap_device_idle+0x44/0x64)
[<c006c018>] (omap_device_idle+0x44/0x64) from [<c005fbfc>] (omap_pm_runtime_suspend+0x2c/0x50)
[<c005fbfc>] (omap_pm_runtime_suspend+0x2c/0x50) from [<c0292ecc>] (__pm_runtime_suspend+0x210/0x36c)
[<c0292ecc>] (__pm_runtime_suspend+0x210/0x36c) from [<c02930c8>] (pm_runtime_suspend+0x20/0x34)
[<c02930c8>] (pm_runtime_suspend+0x20/0x34) from [<c0293898>] (pm_generic_runtime_idle+0x40/0x48)
[<c0293898>] (pm_generic_runtime_idle+0x40/0x48) from [<c02927d0>] (__pm_runtime_idle+0x164/0x1a0)
[<c02927d0>] (__pm_runtime_idle+0x164/0x1a0) from [<c029288c>] (pm_runtime_idle+0x1c/0x30)
[<c029288c>] (pm_runtime_idle+0x1c/0x30) from [<c028d5cc>] (driver_probe_device+0x168/0x188)
[<c028d5cc>] (driver_probe_device+0x168/0x188) from [<c028d654>] (__driver_attach+0x68/0x8c)
[<c028d654>] (__driver_attach+0x68/0x8c) from [<c028cce0>] (bus_for_each_dev+0x44/0x74)
[<c028cce0>] (bus_for_each_dev+0x44/0x74) from [<c028c610>] (bus_add_driver+0x104/0x294)
[<c028c610>] (bus_add_driver+0x104/0x294) from [<c028d94c>] (driver_register+0xa8/0x130)
[<c028d94c>] (driver_register+0xa8/0x130) from [<c004d574>] (do_one_initcall+0xc8/0x1a0)
[<c004d574>] (do_one_initcall+0xc8/0x1a0) from [<c00085f0>] (kernel_init+0x14c/0x214)
[<c00085f0>] (kernel_init+0x14c/0x214) from [<c004eca8>] (kernel_thread_exit+0x0/0x8)

This is with the omap2plus_defconfig and after editing cmdline to have console set to ttyO2.

Would be nice to have those fixed before we merge it.

Quoted 7 lines

Note this also depends on a handful of patches from my pm-backports branch, most of which you have picked into omap-testing, except for the one I just posted to linux-arm-kernel:

ARM: add cpu_idle_wait() to support CPUidle on SMP systems.

This one is required now that the default config enables SMP.

I'll apply that into omap-testing branch.

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Wednesday, September 29, 2010 3:06 AM
To: Nayak, Rajendra; Tony Lindgren
Cc: [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Rajendra,

Quoted 17 lines · Tony Lindgren

Quoted 6 lines · Kevin Hilman

Tony,

The following pull request will bring hwmod driver conversions for watchdog, UART and i2c drivers. It is based on your omap-for-linus branch.

Quoted 7 lines

The i2c driver is waiting for final signoff/ack from the upstream subsystem maintainers, but are otherwise ready to go for broader testing. After I get the final ack, I will update the branch for a final pull.

In the meantime, I'd like to get them into l-o master (or omap-testing) for broader testing.

Tried pulling it but I'm getting tons of these errors on omap2:

Quoted 9 lines

WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1237 _omap_hwmod_idle+0x28/0xd8()
omap_hwmod: i2c1: idle state can only be entered from enabled state
Modules linked in:
[<c0054534>] (unwind_backtrace+0x0/0xec) from [<c008b55c>] (warn_slowpath_common+0x4c/0x64)
[<c008b55c>] (warn_slowpath_common+0x4c/0x64) from [<c008b5f4>] (warn_slowpath_fmt+0x2c/0x3c)
[<c008b5f4>] (warn_slowpath_fmt+0x2c/0x3c) from [<c005e2f8>] (_omap_hwmod_idle+0x28/0xd8)
[<c005e2f8>] (_omap_hwmod_idle+0x28/0xd8) from [<c005e3d0>] (omap_hwmod_idle+0x28/0x38)
[<c005e3d0>] (omap_hwmod_idle+0x28/0x38) from [<c006bc6c>] (omap_device_idle_hwmods+0x1c/0x34)
[<c006bc6c>] (omap_device_idle_hwmods+0x1c/0x34) from [<c006bd40>]

(_omap_device_deactivate+0x4c/0x154)

Quoted 16 lines

[<c006bd40>] (_omap_device_deactivate+0x4c/0x154) from [<c006c018>] (omap_device_idle+0x44/0x64) [<c006c018>] (omap_device_idle+0x44/0x64) from [<c005fbfc>] (omap_pm_runtime_suspend+0x2c/0x50) [<c005fbfc>] (omap_pm_runtime_suspend+0x2c/0x50) from [<c0292ecc>] (__pm_runtime_suspend+0x210/0x36c) [<c0292ecc>] (__pm_runtime_suspend+0x210/0x36c) from [<c02930c8>] (pm_runtime_suspend+0x20/0x34) [<c02930c8>] (pm_runtime_suspend+0x20/0x34) from [<c0293898>] (pm_generic_runtime_idle+0x40/0x48) [<c0293898>] (pm_generic_runtime_idle+0x40/0x48) from [<c02927d0>] (__pm_runtime_idle+0x164/0x1a0) [<c02927d0>] (__pm_runtime_idle+0x164/0x1a0) from [<c029288c>] (pm_runtime_idle+0x1c/0x30) [<c029288c>] (pm_runtime_idle+0x1c/0x30) from [<c028d5cc>] (driver_probe_device+0x168/0x188) [<c028d5cc>] (driver_probe_device+0x168/0x188) from [<c028d654>] (__driver_attach+0x68/0x8c) [<c028d654>] (__driver_attach+0x68/0x8c) from [<c028cce0>] (bus_for_each_dev+0x44/0x74) [<c028cce0>] (bus_for_each_dev+0x44/0x74) from [<c028c610>] (bus_add_driver+0x104/0x294) [<c028c610>] (bus_add_driver+0x104/0x294) from [<c028d94c>] (driver_register+0xa8/0x130) [<c028d94c>] (driver_register+0xa8/0x130) from [<c004d574>] (do_one_initcall+0xc8/0x1a0) [<c004d574>] (do_one_initcall+0xc8/0x1a0) from [<c00085f0>] (kernel_init+0x14c/0x214) [<c00085f0>] (kernel_init+0x14c/0x214) from [<c004eca8>] (kernel_thread_exit+0x0/0x8)

Quoted 4 lines

This is with the omap2plus_defconfig and after editing cmdline to have console set to ttyO2.

Would be nice to have those fixed before we merge it.

Rajendra, can you look into this on OMAP2? This is happening for Tony on both n8x0 and 2430sdp.

Quoted 10 lines

Quoted 8 lines

Note this also depends on a handful of patches from my pm-backports branch, most of which you have picked into omap-testing, except for the one I just posted to linux-arm-kernel:

ARM: add cpu_idle_wait() to support CPUidle on SMP systems.

This one is required now that the default config enables SMP.

I'll apply that into omap-testing branch.

Thanks,

Kevin

Quoted 7 lines

Quoted 4 lines

This is with the omap2plus_defconfig and after editing cmdline to have console set to ttyO2.

Would be nice to have those fixed before we merge it.

Rajendra, can you look into this on OMAP2? This is happening for Tony on both n8x0 and 2430sdp.

Sure, I'll have a look.

Quoted 15 lines

Quoted 11 lines

Quoted 9 lines

Note this also depends on a handful of patches from my pm-backports branch, most of which you have picked into omap-testing, except for the one I just posted to linux-arm-kernel:

ARM: add cpu_idle_wait() to support CPUidle on SMP systems.

This one is required now that the default config enables SMP.

I'll apply that into omap-testing branch.

Thanks,

Kevin

-----Original Message-----
From: Nayak, Rajendra
Sent: Wednesday, September 29, 2010 9:44 PM
To: Nayak, Rajendra; Kevin Hilman; Tony Lindgren
Cc: [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

<snip>..

Quoted 9 lines

Quoted 7 lines

Quoted 4 lines

This is with the omap2plus_defconfig and after editing cmdline to have console set to ttyO2.

Would be nice to have those fixed before we merge it.

Rajendra, can you look into this on OMAP2? This is happening for Tony on both n8x0 and 2430sdp.

Sure, I'll have a look.

Kevin,

I saw 3 issues with the patch which adds OMAP2 hwmods which I never seem to have caught with the boottest on 2430 that I tried before I posted the patches.

These were causing the hwmod enable at init to fail and subsequent idle would throw WARN's

Looking back at my bootlog on 2430, I did see the "cannot be enable" errors during hwmod init, but the WARN's never came and I seem to have overlooked these errors.
The only reason I can think of why the WARN's were not thrown was if for some reason (usecounting) the pm_runtime_put_sync's from the i2c driver were not translating into a omap_device/hmwod disable/idle call.

Partial 2430 bootlog from pm-core branch..
----
<6>Clocking rate (Crystal/DPLL/MPU): 13.0/660/330 MHz
Clocking rate (Crystal/DPLL/MPU): 13.0/660/330 MHz
<4>omap_hwmod: i2c1: cannot clk_get main_clk i2c1_fck
omap_hwmod: i2c1: cannot clk_get main_clk i2c1_fck
<4>omap_hwmod: i2c2: cannot clk_get main_clk i2c2_fck
omap_hwmod: i2c2: cannot clk_get main_clk i2c2_fck
<4>omap_hwmod: i2c1: cannot be enabled (3)
omap_hwmod: i2c1: cannot be enabled (3)
<4>omap_hwmod: i2c2: cannot be enabled (3)
omap_hwmod: i2c2: cannot be enabled (3)
<6>GPMC revision 3.0
GPMC revision 3.0
<6>IRQ: Found an INTC at 0xfa0fe000 (revision 3.0) with 96 interrupts
IRQ: Found an INTC at 0xfa0fe000 (revision 3.0) with 96 interrupts <6>Total of 96 interrupts on 1 active controller
Total of 96 interrupts on 1 active controller
<6>OMAP GPIO hardware version 2.4
OMAP GPIO hardware version 2.4
<6>OMAP clockevent source: GPTIMER1 at 32000 Hz
OMAP clockevent source: GPTIMER1 at 32000 Hz
Console: colour dummy device 80x30
Console: colour dummy device 80x30
<6>Calibrating delay loop... Calibrating delay loop... <c>320.37 BogoMIPS (lpj=1253376) 320.37 BogoMIPS (lpj=1253376)
<6>pid_max: default: 32768 minimum: 301
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Mount-cache hash table entries: 512
<6>CPU: Testing write buffer coherency: CPU: Testing write buffer coherency: ok ok
<6>regulator: core version 0.5
regulator: core version 0.5
<6>NET: Registered protocol family 16
NET: Registered protocol family 16
<7>mux: Setting signal i2c2_scl.i2c2_scl 0x0000 -> 0x0100
mux: Setting signal i2c2_scl.i2c2_scl 0x0000 -> 0x0100
<7>mux: Setting signal i2c2_sda.i2c2_sda 0x0000 -> 0x0100
mux: Setting signal i2c2_sda.i2c2_sda 0x0000 -> 0x0100
<3>look up for i2c2 successful
look up for i2c2 successful
<7>mux: Setting signal usb0hs_data1.usb0_dat 0x0004 -> 0x0004
mux: Setting signal usb0hs_data1.usb0_dat 0x0004 -> 0x0004
<7>mux: Setting signal usb0hs_data0.usb0_txen 0x0004 -> 0x0004
mux: Setting signal usb0hs_data0.usb0_txen 0x0004 -> 0x0004
<7>mux: Setting signal usb0hs_data2.usb0_se0 0x0004 -> 0x0004
mux: Setting signal usb0hs_data2.usb0_se0 0x0004 -> 0x0004
USB: hmc 0USB: hmc 0, usb0 3 wires, usb0 3 wires, Mini-AB on usb0, Mini-AB on usb0

<7>mux: Setting signal usb0hs_stp.usb0hs_stp 0x0018 -> 0x0018
mux: Setting signal usb0hs_stp.usb0hs_stp 0x0018 -> 0x0018 <7>mux: Setting signal gpio_149.gpio149 0x0018 -> 0x0103
mux: Setting signal gpio_149.gpio149 0x0018 -> 0x0103 <6>OMAP DMA hardware revision 4.0
OMAP DMA hardware revision 4.0
bio: create slab <bio-0> at 0
bio: create slab <bio-0> at 0
<4>omap_device: i2c_omap.1: new worst case activate latency 0: 2563476
omap_device: i2c_omap.1: new worst case activate latency 0: 2563476 <6>i2c_omap i2c_omap.1: bus 1 rev3.7 at 100 kHz
i2c_omap i2c_omap.1: bus 1 rev3.7 at 100 kHz
<6>i2c_omap i2c_omap.2: bus 2 rev3.7 at 2600 kHz
i2c_omap i2c_omap.2: bus 2 rev3.7 at 2600 kHz
----

These are the fixes that make it boot on 2430sdp. Should I repost the original patch with these fixes?

arch/arm/mach-omap2/cm-regbits-24xx.h +4 -4

index 5986e2b..9a106c0 100644
@@ -126,12 +126,12 @@
 #define OMAP24XX_ST_HDQ_MASK				(1 << 23)
 #define OMAP2420_ST_I2C2_SHIFT				20
 #define OMAP2420_ST_I2C2_MASK				(1 << 20)
-#define OMAP2430_ST_I2CHS1_SHIFT			20
-#define OMAP2430_ST_I2CHS1_MASK				(1 << 20)
+#define OMAP2430_ST_I2CHS1_SHIFT			19
+#define OMAP2430_ST_I2CHS1_MASK				(1 << 19)
 #define OMAP2420_ST_I2C1_SHIFT				19
 #define OMAP2420_ST_I2C1_MASK				(1 << 19)
-#define OMAP2430_ST_I2CHS2_SHIFT			19
-#define OMAP2430_ST_I2CHS2_MASK				(1 << 19)
+#define OMAP2430_ST_I2CHS2_SHIFT			20
+#define OMAP2430_ST_I2CHS2_MASK				(1 << 20)
 #define OMAP24XX_ST_MCBSP2_SHIFT			16
 #define OMAP24XX_ST_MCBSP2_MASK				(1 << 16)
 #define OMAP24XX_ST_MCBSP1_SHIFT			15

arch/arm/mach-omap2/omap_hwmod_2420_data.c +2 -0

index 8bf46c1..ca4edd3 100644
@@ -504,6 +504,7 @@ static struct omap_hwmod omap2420_i2c1_hwmod = {
 	.main_clk	= "i2c1_fck",
 	.prcm		= {
 		.omap2 = {
+			.module_offs = CORE_MOD,
 			.prcm_reg_id = 1,
 			.module_bit = OMAP2420_EN_I2C1_SHIFT,
 			.idlest_reg_id = 1,

@@ -541,6 +542,7 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
 	.main_clk	= "i2c2_fck",
 	.prcm		= {
 		.omap2 = {
+			.module_offs = CORE_MOD,
 			.prcm_reg_id = 1,
 			.module_bit = OMAP2420_EN_I2C2_SHIFT,
 			.idlest_reg_id = 1,

arch/arm/mach-omap2/omap_hwmod_2430_data.c +4 -2

index 92f4ec0..9498847 100644
@@ -502,7 +502,7 @@ static struct omap_hwmod omap2430_i2c1_hwmod = {
 	.mpu_irqs_cnt	= ARRAY_SIZE(i2c1_mpu_irqs),
 	.sdma_reqs	= i2c1_sdma_reqs,
 	.sdma_reqs_cnt	= ARRAY_SIZE(i2c1_sdma_reqs),
-	.main_clk	= "i2c1_fck",
+	.main_clk	= "i2chs1_fck",
 	.prcm		= {
 		.omap2 = {
 			/*

@@ -513,6 +513,7 @@ static struct omap_hwmod omap2430_i2c1_hwmod = {
 			 * additonal flags when clk handling is moved
 			 * to hwmod framework.
 			 */
+			.module_offs = CORE_MOD,
 			.prcm_reg_id = 1,
 			.module_bit = OMAP2430_EN_I2CHS1_SHIFT,
 			.idlest_reg_id = 1,

@@ -551,9 +552,10 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
 	.mpu_irqs_cnt	= ARRAY_SIZE(i2c2_mpu_irqs),
 	.sdma_reqs	= i2c2_sdma_reqs,
 	.sdma_reqs_cnt	= ARRAY_SIZE(i2c2_sdma_reqs),
-	.main_clk	= "i2c2_fck",
+	.main_clk	= "i2chs2_fck",
 	.prcm		= {
 		.omap2 = {
+			.module_offs = CORE_MOD,
 			.prcm_reg_id = 1,
 			.module_bit = OMAP2430_EN_I2CHS2_SHIFT,
 			.idlest_reg_id = 1,

Quoted 15 lines

Quoted 15 lines

Quoted 11 lines

Quoted 9 lines

Note this also depends on a handful of patches from my pm-backports branch, most of which you have picked into omap-testing, except for the one I just posted to linux-arm-kernel:

ARM: add cpu_idle_wait() to support CPUidle on SMP systems.

This one is required now that the default config enables SMP.

I'll apply that into omap-testing branch.

Thanks,

Kevin

I forgot to mention, there are similar WARN's that I see on 2430sdp even with UART

[    0.000000] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1237 _omap_hwmod_idle+0x28/0xd8()
[    0.000000] omap_hwmod: uart3: idle state can only be entered from enabled state
[    0.000000] Modules linked in:
[    0.000000] [<c0053478>] (unwind_backtrace+0x0/0xe4) from [<c00897f4>] (warn_slowpath_common+0x4c/0x64)
[    0.000000] [<c00897f4>] (warn_slowpath_common+0x4c/0x64) from [<c008988c>] (warn_slowpath_fmt+0x2c/0x3c)
[    0.000000] [<c008988c>] (warn_slowpath_fmt+0x2c/0x3c) from [<c005d138>] (_omap_hwmod_idle+0x28/0xd8)
[    0.000000] [<c005d138>] (_omap_hwmod_idle+0x28/0xd8) from [<c005d210>] (omap_hwmod_idle+0x28/0x38)
[    0.000000] [<c005d210>] (omap_hwmod_idle+0x28/0x38) from [<c000fd48>] (omap_serial_init_port+0x164/0x42c)
[    0.000000] [<c000fd48>] (omap_serial_init_port+0x164/0x42c) from [<c0010028>] (omap_serial_init+0x18/0x40)
[    0.000000] [<c0010028>] (omap_serial_init+0x18/0x40) from [<c0012a44>] (omap_2430sdp_init+0x48/0xcc)
[    0.000000] [<c0012a44>] (omap_2430sdp_init+0x48/0xcc) from [<c000b650>] (customize_machine+0x18/0x24)
[    0.000000] [<c000b650>] (customize_machine+0x18/0x24) from [<c004c578>] (do_one_initcall+0xcc/0x1a4)
[    0.000000] [<c004c578>] (do_one_initcall+0xcc/0x1a4) from [<c00085e0>] (kernel_init+0x148/0x210)
[    0.000000] [<c00085e0>] (kernel_init+0x148/0x210) from [<c004dcb8>] (kernel_thread_exit+0x0/0x8)
[    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1237 _omap_hwmod_idle+0x28/0xd8()
[    0.000000] omap_hwmod: uart3: idle state can only be entered from enabled state
[    0.000000] Modules linked in:
[    0.000000] [<c0053478>] (unwind_backtrace+0x0/0xe4) from [<c00897f4>] (warn_slowpath_common+0x4c/0x64)
[    0.000000] [<c00897f4>] (warn_slowpath_common+0x4c/0x64) from [<c008988c>] (warn_slowpath_fmt+0x2c/0x3c)
[    0.000000] [<c008988c>] (warn_slowpath_fmt+0x2c/0x3c) from [<c005d138>] (_omap_hwmod_idle+0x28/0xd8)
[    0.000000] [<c005d138>] (_omap_hwmod_idle+0x28/0xd8) from [<c0058c48>] (uart_idle_hwmod+0x10/0x18)
[    0.000000] [<c0058c48>] (uart_idle_hwmod+0x10/0x18) from [<c006a994>] (_omap_device_deactivate+0x58/0x144)
[    0.000000] [<c006a994>] (_omap_device_deactivate+0x58/0x144) from [<c006ac44>] (omap_device_idle+0x48/0x68)
[    0.000000] [<c006ac44>] (omap_device_idle+0x48/0x68) from [<c000ff08>] (omap_serial_init_port+0x324/0x42c)
[    0.000000] [<c000ff08>] (omap_serial_init_port+0x324/0x42c) from [<c0010028>] (omap_serial_init+0x18/0x40)
[    0.000000] [<c0010028>] (omap_serial_init+0x18/0x40) from [<c0012a44>] (omap_2430sdp_init+0x48/0xcc)
[    0.000000] [<c0012a44>] (omap_2430sdp_init+0x48/0xcc) from [<c000b650>] (customize_machine+0x18/0x24)
[    0.000000] [<c000b650>] (customize_machine+0x18/0x24) from [<c004c578>] (do_one_initcall+0xcc/0x1a4)
[    0.000000] [<c004c578>] (do_one_initcall+0xcc/0x1a4) from [<c00085e0>] (kernel_init+0x148/0x210)
[    0.000000] [<c00085e0>] (kernel_init+0x148/0x210) from [<c004dcb8>] (kernel_thread_exit+0x0/0x8)
[    0.000000] ---[ end trace 1b75b31a2719ed1d ]---

Quoted 91 lines

arch/arm/mach-omap2/cm-regbits-24xx.h +4 -4

index 5986e2b..9a106c0 100644
@@ -126,12 +126,12 @@
 #define OMAP24XX_ST_HDQ_MASK				(1 << 23)
 #define OMAP2420_ST_I2C2_SHIFT				20
 #define OMAP2420_ST_I2C2_MASK				(1 << 20)
-#define OMAP2430_ST_I2CHS1_SHIFT			20
-#define OMAP2430_ST_I2CHS1_MASK				(1 << 20)
+#define OMAP2430_ST_I2CHS1_SHIFT			19
+#define OMAP2430_ST_I2CHS1_MASK				(1 << 19)
 #define OMAP2420_ST_I2C1_SHIFT				19
 #define OMAP2420_ST_I2C1_MASK				(1 << 19)
-#define OMAP2430_ST_I2CHS2_SHIFT			19
-#define OMAP2430_ST_I2CHS2_MASK				(1 << 19)
+#define OMAP2430_ST_I2CHS2_SHIFT			20
+#define OMAP2430_ST_I2CHS2_MASK				(1 << 20)
 #define OMAP24XX_ST_MCBSP2_SHIFT			16
 #define OMAP24XX_ST_MCBSP2_MASK				(1 << 16)
 #define OMAP24XX_ST_MCBSP1_SHIFT			15

arch/arm/mach-omap2/omap_hwmod_2420_data.c +2 -0

index 8bf46c1..ca4edd3 100644
@@ -504,6 +504,7 @@ static struct omap_hwmod omap2420_i2c1_hwmod = {
 	.main_clk	= "i2c1_fck",
 	.prcm		= {
 		.omap2 = {
+			.module_offs = CORE_MOD,
 			.prcm_reg_id = 1,
 			.module_bit = OMAP2420_EN_I2C1_SHIFT,
 			.idlest_reg_id = 1,

@@ -541,6 +542,7 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
 	.main_clk	= "i2c2_fck",
 	.prcm		= {
 		.omap2 = {
+			.module_offs = CORE_MOD,
 			.prcm_reg_id = 1,
 			.module_bit = OMAP2420_EN_I2C2_SHIFT,
 			.idlest_reg_id = 1,

arch/arm/mach-omap2/omap_hwmod_2430_data.c +4 -2

index 92f4ec0..9498847 100644
@@ -502,7 +502,7 @@ static struct omap_hwmod omap2430_i2c1_hwmod = {
 	.mpu_irqs_cnt	= ARRAY_SIZE(i2c1_mpu_irqs),
 	.sdma_reqs	= i2c1_sdma_reqs,
 	.sdma_reqs_cnt	= ARRAY_SIZE(i2c1_sdma_reqs),
-	.main_clk	= "i2c1_fck",
+	.main_clk	= "i2chs1_fck",
 	.prcm		= {
 		.omap2 = {
 			/*

@@ -513,6 +513,7 @@ static struct omap_hwmod omap2430_i2c1_hwmod = {
 			 * additonal flags when clk handling is moved
 			 * to hwmod framework.
 			 */
+			.module_offs = CORE_MOD,
 			.prcm_reg_id = 1,
 			.module_bit = OMAP2430_EN_I2CHS1_SHIFT,
 			.idlest_reg_id = 1,

@@ -551,9 +552,10 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
 	.mpu_irqs_cnt	= ARRAY_SIZE(i2c2_mpu_irqs),
 	.sdma_reqs	= i2c2_sdma_reqs,
 	.sdma_reqs_cnt	= ARRAY_SIZE(i2c2_sdma_reqs),
-	.main_clk	= "i2c2_fck",
+	.main_clk	= "i2chs2_fck",
 	.prcm		= {
 		.omap2 = {
+			.module_offs = CORE_MOD,
 			.prcm_reg_id = 1,
 			.module_bit = OMAP2430_EN_I2CHS2_SHIFT,
 			.idlest_reg_id = 1,

Quoted 15 lines

Quoted 15 lines

Quoted 11 lines

Quoted 9 lines

Note this also depends on a handful of patches from my pm-backports branch, most of which you have picked into omap-testing, except for the one I just posted to linux-arm-kernel:

ARM: add cpu_idle_wait() to support CPUidle on SMP systems.

This one is required now that the default config enables SMP.

I'll apply that into omap-testing branch.

Thanks,

Kevin

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Thursday, September 30, 2010 12:49 AM
To: Nayak, Rajendra; Raja, Govindraj
Cc: Tony Lindgren; [email protected]; Varadarajan, Charulatha
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

"Nayak, Rajendra" <[email protected]> writes:

[...]

Quoted 1 line

Quoted 2 lines

I forgot to mention, there are similar WARN's that I see on 2430sdp even with UART

Govidraj, can you look into these UART issues please?

Looks like you might need to double check the bitfields and the module_offs for both of these.

Thanks,

Kevin

Quoted 4 lines

[    0.000000] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1237 _omap_hwmod_idle+0x28/0xd8()
[    0.000000] omap_hwmod: uart3: idle state can only be entered from enabled state
[    0.000000] Modules linked in:
[    0.000000] [<c0053478>] (unwind_backtrace+0x0/0xe4) from [<c00897f4>]

(warn_slowpath_common+0x4c/0x64)

Quoted 1 line

[    0.000000] [<c00897f4>] (warn_slowpath_common+0x4c/0x64) from [<c008988c>]

(warn_slowpath_fmt+0x2c/0x3c)

Quoted 1 line

[    0.000000] [<c008988c>] (warn_slowpath_fmt+0x2c/0x3c) from [<c005d138>]

(_omap_hwmod_idle+0x28/0xd8)

Quoted 1 line

[    0.000000] [<c005d138>] (_omap_hwmod_idle+0x28/0xd8) from [<c005d210>]

(omap_hwmod_idle+0x28/0x38)

Quoted 1 line

[    0.000000] [<c005d210>] (omap_hwmod_idle+0x28/0x38) from [<c000fd48>]

(omap_serial_init_port+0x164/0x42c)

Quoted 1 line

[    0.000000] [<c000fd48>] (omap_serial_init_port+0x164/0x42c) from [<c0010028>]

(omap_serial_init+0x18/0x40)

Quoted 2 lines

[    0.000000] [<c0010028>] (omap_serial_init+0x18/0x40) from [<c0012a44>] (omap_2430sdp_init+0x48/0xcc)
[    0.000000] [<c0012a44>] (omap_2430sdp_init+0x48/0xcc) from [<c000b650>]

(customize_machine+0x18/0x24)

Quoted 9 lines

[    0.000000] [<c000b650>] (customize_machine+0x18/0x24) from [<c004c578>] (do_one_initcall+0xcc/0x1a4)
[    0.000000] [<c004c578>] (do_one_initcall+0xcc/0x1a4) from [<c00085e0>] (kernel_init+0x148/0x210)
[    0.000000] [<c00085e0>] (kernel_init+0x148/0x210) from [<c004dcb8>] (kernel_thread_exit+0x0/0x8)
[    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1237 _omap_hwmod_idle+0x28/0xd8()
[    0.000000] omap_hwmod: uart3: idle state can only be entered from enabled state
[    0.000000] Modules linked in:
[    0.000000] [<c0053478>] (unwind_backtrace+0x0/0xe4) from [<c00897f4>]

(warn_slowpath_common+0x4c/0x64)

Quoted 1 line

[    0.000000] [<c00897f4>] (warn_slowpath_common+0x4c/0x64) from [<c008988c>]

(warn_slowpath_fmt+0x2c/0x3c)

Quoted 1 line

[    0.000000] [<c008988c>] (warn_slowpath_fmt+0x2c/0x3c) from [<c005d138>]

(_omap_hwmod_idle+0x28/0xd8)

Quoted 2 lines

[    0.000000] [<c005d138>] (_omap_hwmod_idle+0x28/0xd8) from [<c0058c48>] (uart_idle_hwmod+0x10/0x18)
[    0.000000] [<c0058c48>] (uart_idle_hwmod+0x10/0x18) from [<c006a994>]

(_omap_device_deactivate+0x58/0x144)

Quoted 1 line

[    0.000000] [<c006a994>] (_omap_device_deactivate+0x58/0x144) from [<c006ac44>]

(omap_device_idle+0x48/0x68)

Quoted 1 line

[    0.000000] [<c006ac44>] (omap_device_idle+0x48/0x68) from [<c000ff08>]

(omap_serial_init_port+0x324/0x42c)

Quoted 1 line

[    0.000000] [<c000ff08>] (omap_serial_init_port+0x324/0x42c) from [<c0010028>]

(omap_serial_init+0x18/0x40)

Quoted 2 lines

[    0.000000] [<c0010028>] (omap_serial_init+0x18/0x40) from [<c0012a44>] (omap_2430sdp_init+0x48/0xcc)
[    0.000000] [<c0012a44>] (omap_2430sdp_init+0x48/0xcc) from [<c000b650>]

(customize_machine+0x18/0x24)

Quoted 20 lines

[    0.000000] [<c000b650>] (customize_machine+0x18/0x24) from [<c004c578>] (do_one_initcall+0xcc/0x1a4)
[    0.000000] [<c004c578>] (do_one_initcall+0xcc/0x1a4) from [<c00085e0>] (kernel_init+0x148/0x210)
[    0.000000] [<c00085e0>] (kernel_init+0x148/0x210) from [<c004dcb8>] (kernel_thread_exit+0x0/0x8)
[    0.000000] ---[ end trace 1b75b31a2719ed1d ]---

Quoted 16 lines

arch/arm/mach-omap2/cm-regbits-24xx.h +2 -2

index 5986e2b..9a106c0 100644
@@ -126,12 +126,12 @@
 #define OMAP24XX_ST_HDQ_MASK				(1 << 23)
 #define OMAP2420_ST_I2C2_SHIFT				20
 #define OMAP2420_ST_I2C2_MASK				(1 << 20)
-#define OMAP2430_ST_I2CHS1_SHIFT			20
-#define OMAP2430_ST_I2CHS1_MASK				(1 << 20)
+#define OMAP2430_ST_I2CHS1_SHIFT			19
+#define OMAP2430_ST_I2CHS1_MASK				(1 << 19)
 #define OMAP2420_ST_I2C1_SHIFT				19
 #define OMAP2420_ST_I2C1_MASK				(1 << 19)

Quoted 8 lines

arch/arm/mach-

Quoted 8 lines

arch/arm/mach-omap2/cm-regbits-24xx.h +2 -2

-#define OMAP2430_ST_I2CHS2_SHIFT			19
-#define OMAP2430_ST_I2CHS2_MASK				(1 << 19)
+#define OMAP2430_ST_I2CHS2_SHIFT			20
+#define OMAP2430_ST_I2CHS2_MASK				(1 << 20)
 #define OMAP24XX_ST_MCBSP2_SHIFT			16
 #define OMAP24XX_ST_MCBSP2_MASK				(1 << 16)
 #define OMAP24XX_ST_MCBSP1_SHIFT			15

arch/arm/mach- renamed from arch/arm/mach-omap2/omap_hwmod_2420_data.c +0 -0

omap2/omap_hwmod_2420_data.c

Quoted 12 lines

Quoted 12 lines

index 8bf46c1..ca4edd3 100644

arch/arm/mach-omap2/omap_hwmod_2420_data.c +1 -0

@@ -504,6 +504,7 @@ static struct omap_hwmod omap2420_i2c1_hwmod = {
 	.main_clk	= "i2c1_fck",
 	.prcm		= {
 		.omap2 = {
+			.module_offs = CORE_MOD,
 			.prcm_reg_id = 1,
 			.module_bit = OMAP2420_EN_I2C1_SHIFT,
 			.idlest_reg_id = 1,

@@ -541,6 +542,7 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {

Quoted 8 lines

arch/arm/mach-

Quoted 8 lines

arch/arm/mach-omap2/omap_hwmod_2420_data.c +1 -0

 	.main_clk	= "i2c2_fck",
 	.prcm		= {
 		.omap2 = {
+			.module_offs = CORE_MOD,
 			.prcm_reg_id = 1,
 			.module_bit = OMAP2420_EN_I2C2_SHIFT,
 			.idlest_reg_id = 1,

arch/arm/mach- renamed from arch/arm/mach-omap2/omap_hwmod_2430_data.c +0 -0

omap2/omap_hwmod_2430_data.c

Quoted 47 lines

Quoted 47 lines

index 92f4ec0..9498847 100644

arch/arm/mach-omap2/omap_hwmod_2430_data.c +4 -2

@@ -502,7 +502,7 @@ static struct omap_hwmod omap2430_i2c1_hwmod = {
 	.mpu_irqs_cnt	= ARRAY_SIZE(i2c1_mpu_irqs),
 	.sdma_reqs	= i2c1_sdma_reqs,
 	.sdma_reqs_cnt	= ARRAY_SIZE(i2c1_sdma_reqs),
-	.main_clk	= "i2c1_fck",
+	.main_clk	= "i2chs1_fck",
 	.prcm		= {
 		.omap2 = {
 			/*

@@ -513,6 +513,7 @@ static struct omap_hwmod omap2430_i2c1_hwmod = {
 			 * additonal flags when clk handling is moved
 			 * to hwmod framework.
 			 */
+			.module_offs = CORE_MOD,
 			.prcm_reg_id = 1,
 			.module_bit = OMAP2430_EN_I2CHS1_SHIFT,
 			.idlest_reg_id = 1,

@@ -551,9 +552,10 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
 	.mpu_irqs_cnt	= ARRAY_SIZE(i2c2_mpu_irqs),
 	.sdma_reqs	= i2c2_sdma_reqs,
 	.sdma_reqs_cnt	= ARRAY_SIZE(i2c2_sdma_reqs),
-	.main_clk	= "i2c2_fck",
+	.main_clk	= "i2chs2_fck",
 	.prcm		= {
 		.omap2 = {
+			.module_offs = CORE_MOD,
 			.prcm_reg_id = 1,
 			.module_bit = OMAP2430_EN_I2CHS2_SHIFT,
 			.idlest_reg_id = 1,

Quoted 15 lines

Quoted 15 lines

Quoted 11 lines

Quoted 9 lines

Note this also depends on a handful of patches from my pm-backports branch, most of which you have picked into omap-testing, except for the one I just posted to linux-arm-kernel:

ARM: add cpu_idle_wait() to support CPUidle on SMP systems.

This one is required now that the default config enables SMP.

I'll apply that into omap-testing branch.

Thanks,

Kevin

Quoted 12 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Thursday, September 30, 2010 12:49 AM
To: Nayak, Rajendra; Raja, Govindraj
Cc: Tony Lindgren; [email protected]; Varadarajan, Charulatha
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

"Nayak, Rajendra" <[email protected]> writes:

[...]

Quoted 1 line

Quoted 7 lines

Quoted 2 lines

I forgot to mention, there are similar WARN's that I see on 2430sdp even with UART

Govidraj, can you look into these UART issues please?

Looks like you might need to double check the bitfields and the module_offs for both of these.

Btw, the WARN's come only for UART3 and the error at hwmod init shows that maybe _wait_target_ready fails.

[    0.000000] NR_IRQS:402
[    0.000000] Clocking rate (Crystal/DPLL/MPU): 13.0/660/330 MHz
[    0.000000] omap_hwmod: uart3: cannot be enabled (3)

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Thursday, September 30, 2010 1:11 AM
To: Nayak, Rajendra
Cc: Raja, Govindraj; Tony Lindgren; [email protected]; Varadarajan, Charulatha
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 20 lines · Rajendra

Quoted 12 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Thursday, September 30, 2010 12:49 AM
To: Nayak, Rajendra; Raja, Govindraj
Cc: Tony Lindgren; [email protected]; Varadarajan, Charulatha
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

"Nayak, Rajendra" <[email protected]> writes:

[...]

Quoted 1 line

Quoted 7 lines

Quoted 2 lines

I forgot to mention, there are similar WARN's that I see on 2430sdp even with UART

Govidraj, can you look into these UART issues please?

Looks like you might need to double check the bitfields and the module_offs for both of these.

Quoted 7 lines

Btw, the WARN's come only for UART3 and the error at hwmod init shows that maybe _wait_target_ready fails.

[    0.000000] NR_IRQS:402
[    0.000000] Clocking rate (Crystal/DPLL/MPU): 13.0/660/330 MHz
[    0.000000] omap_hwmod: uart3: cannot be enabled (3)

UART3 on 24xx is in CM_IDLEST2_CORE, and the 2430 hwmod data has it in CM_IDLEST1_CORE.

Can you test the change below? I don't have a 2430, and it appears that this is already correct in the 2420 hwmod data.

Kevin

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

index 92f4ec0..5b61f7c 100644
@@ -449,9 +449,9 @@ static struct omap_hwmod omap2430_uart3_hwmod = {
 	.prcm		= {

Quoted 28 lines

Quoted 7 lines

Btw, the WARN's come only for UART3 and the error at hwmod init shows that maybe _wait_target_ready fails.

[    0.000000] NR_IRQS:402
[    0.000000] Clocking rate (Crystal/DPLL/MPU): 13.0/660/330 MHz
[    0.000000] omap_hwmod: uart3: cannot be enabled (3)

UART3 on 24xx is in CM_IDLEST2_CORE, and the 2430 hwmod data has it in CM_IDLEST1_CORE.

Can you test the change below? I don't have a 2430, and it appears that this is already correct in the 2420 hwmod data.

Kevin

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

index 92f4ec0..5b61f7c 100644
@@ -449,9 +449,9 @@ static struct omap_hwmod omap2430_uart3_hwmod = {
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
-			.prcm_reg_id = 1,
+			.prcm_reg_id = 2,
 			.module_bit = OMAP24XX_EN_UART3_SHIFT,

arch/arm/mach-omap2/omap_hwmod_2430_data.c static struct omap_hwmod omap2430_uart3_hwmod = { · line 457

Quoted 5 lines

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

-			.idlest_reg_id = 1,
+			.idlest_reg_id = 2,
 			.idlest_idle_bit = OMAP24XX_EN_UART3_SHIFT,
 		},
 	},

This does seem to fix the issue on 2430. I don't see the error at hwmod init or the WARN's later.

<snip>..

Quoted 8 lines

Quoted 7 lines

Quoted 4 lines

This is with the omap2plus_defconfig and after editing cmdline to have console set to ttyO2.

Would be nice to have those fixed before we merge it.

Rajendra, can you look into this on OMAP2? This is happening for Tony on both n8x0 and 2430sdp.

Quoted 1 line

Sure, I'll have a look.

Kevin,

I saw 3 issues with the patch which adds OMAP2 hwmods which I never seem to have caught with the boottest on 2430 that I tried before I posted the patches.

These are the fixes that make it boot on 2430sdp. Should I repost the original patch with these fixes?

Quoted 11 lines · Kevin Hilman

Tony,

The following pull request will bring hwmod driver conversions for watchdog, UART and i2c drivers. It is based on your omap-for-linus branch.

The i2c driver is waiting for final signoff/ack from the upstream subsystem maintainers, but are otherwise ready to go for broader testing. After I get the final ack, I will update the branch for a final pull.

Quoted 2 lines

In the meantime, I'd like to get them into l-o master (or omap-testing) for broader testing.

Tried pulling it but I'm getting tons of these errors on omap2:

Quoted 12 lines · Tony Lindgren

Quoted 11 lines · Kevin Hilman

Tony,

The following pull request will bring hwmod driver conversions for watchdog, UART and i2c drivers. It is based on your omap-for-linus branch.

The i2c driver is waiting for final signoff/ack from the upstream subsystem maintainers, but are otherwise ready to go for broader testing. After I get the final ack, I will update the branch for a final pull.

Quoted 4 lines

Quoted 2 lines

In the meantime, I'd like to get them into l-o master (or omap-testing) for broader testing.

Tried pulling it but I'm getting tons of these errors on omap2:

Tony,

Can you pull the latest version of my pm-hwmods branch from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-hwmods

This version has the updated patch from Rajendra for i2c as well as some UART3 fixes for a problem he noticed on 2430 as well.

Before this is final, I'm still waiting on two things:

1) ack from Ben Dooks for the drivers/i2c change
2) additional patch from Charu to prevent reset when CONFIG_OMAP_WATCHDOG=n

Then trying to build for omap1 OSK fails with:

In file included from arch/arm/plat-omap/common.c:35:
arch/arm/plat-omap/include/plat/control.h:20:40: error: mach/ctrl_module_core_44xx.h: No such file or directory arch/arm/plat-omap/include/plat/control.h:21:40: error: mach/ctrl_module_wkup_44xx.h: No such file or directory arch/arm/plat-omap/include/plat/control.h:22:44: error: mach/ctrl_module_pad_core_44xx.h: No such file or directory arch/arm/plat-omap/include/plat/control.h:23:44: error: mach/ctrl_module_pad_wkup_44xx.h: No such file or directory

-----Original Message-----
From: Tony Lindgren [mailto:[email protected]]
Sent: Thursday, September 30, 2010 8:00 AM
To: Shilimkar, Santosh
Cc: [email protected]; Varadarajan, Charulatha; Nayak, Rajendra; Raja, Govindraj; Kevin Hilman
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions:
watchdog, UART, i2c

Quoted 5 lines · Tony Lindgren

Then trying to build for omap1 OSK fails with:

In file included from arch/arm/plat-omap/common.c:35:
arch/arm/plat-omap/include/plat/control.h:20:40: error:

mach/ctrl_module_core_44xx.h: No such file or directory

Quoted 1 line

arch/arm/plat-omap/include/plat/control.h:21:40: error:

mach/ctrl_module_wkup_44xx.h: No such file or directory

Quoted 1 line

arch/arm/plat-omap/include/plat/control.h:22:44: error:

mach/ctrl_module_pad_core_44xx.h: No such file or directory

Quoted 1 line

arch/arm/plat-omap/include/plat/control.h:23:44: error:

mach/ctrl_module_pad_wkup_44xx.h: No such file or directory

This seems to be related to Santosh' commit 802edcb7.

Santosh, can you do a patch to fix this against the current omap-for-linus branch?

From c06e887f402ceff03e6c28bb377bcbfe35318719 Mon Sep 17 00:00:00 2001

Quoted 16 lines

-----Original Message-----
From: Tony Lindgren [mailto:[email protected]]
Sent: Thursday, September 30, 2010 8:00 AM
To: Shilimkar, Santosh
Cc: [email protected]; Varadarajan, Charulatha; Nayak, Rajendra; Raja, Govindraj; Kevin Hilman
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions:
watchdog, UART, i2c

Quoted 5 lines · Tony Lindgren

Then trying to build for omap1 OSK fails with:

In file included from arch/arm/plat-omap/common.c:35:
arch/arm/plat-omap/include/plat/control.h:20:40: error:

mach/ctrl_module_core_44xx.h: No such file or directory

Quoted 9 lines

Quoted 1 line

arch/arm/plat-omap/include/plat/control.h:21:40: error:

mach/ctrl_module_wkup_44xx.h: No such file or directory

Quoted 1 line

arch/arm/plat-omap/include/plat/control.h:22:44: error:

mach/ctrl_module_pad_core_44xx.h: No such file or directory

Quoted 1 line

arch/arm/plat-omap/include/plat/control.h:23:44: error:

mach/ctrl_module_pad_wkup_44xx.h: No such file or directory

This seems to be related to Santosh' commit 802edcb7.

:(

Quoted 3 lines

Santosh, can you do a patch to fix this against the current omap-for-linus branch?

Below is the patch(also attached)which fixes the OMAP1 build issue.
---------

Quoted 1 line

From c06e887f402ceff03e6c28bb377bcbfe35318719 Mon Sep 17 00:00:00 2001

From: Santosh Shilimkar <[email protected]>
Date: Thu, 30 Sep 2010 12:23:07 +0530
Subject: [PATCH] omap: control: Fix the omap1 build break

The commit 802edcb7 broke the omap1 build

In file included from arch/arm/plat-omap/common.c:35:
arch/arm/plat-omap/include/plat/control.h:20:
fatal error: mach/ctrl_module_core_44xx.h: No such file or directory compilation terminated.
make[1]: *** [arch/arm/plat-omap/common.o] Error 1
make: *** [arch/arm/plat-omap] Error 2

Fix it by creating the headers needed for compiling under mach-omap1/include/mach and mach-omap2/include/mach. Also move omap4 specific headers under mach-omap2/control.h

Signed-off-by Santosh Shilimkar <[email protected]>

---
 arch/arm/mach-omap1/include/mach/control.h |    3 +++
 arch/arm/mach-omap2/include/mach/control.h |    8 ++++++++
 arch/arm/plat-omap/include/plat/control.h  |    5 +----
 3 files changed, 12 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/mach-omap1/include/mach/control.h
 create mode 100644 arch/arm/mach-omap2/include/mach/control.h

arch/arm/mach-omap1/include/mach/control.h new file +0 -0

new file mode 100644
index 0000000..c1fd4c0

arch/arm/mach-omap2/include/mach/control.h new file +8 -0

new file mode 100644
index 0000000..dd41272
@@ -0,0 +1,8 @@
+/*
+ * arch/arm/mach-omap2/include/mach/control.h
+ */
+#include <mach/ctrl_module_core_44xx.h>
+#include <mach/ctrl_module_wkup_44xx.h>
+#include <mach/ctrl_module_pad_core_44xx.h>
+#include <mach/ctrl_module_pad_wkup_44xx.h>
+

arch/arm/plat-omap/include/plat/control.h +1 -4

index 19c9b2a..7b047e5 100644
@@ -17,10 +17,7 @@
 #define __ASM_ARCH_CONTROL_H
 
 #include <mach/io.h>
-#include <mach/ctrl_module_core_44xx.h>
-#include <mach/ctrl_module_wkup_44xx.h>
-#include <mach/ctrl_module_pad_core_44xx.h>
-#include <mach/ctrl_module_pad_wkup_44xx.h>
+#include <mach/control.h>
 
 #ifndef __ASSEMBLY__
 #define OMAP242X_CTRL_REGADDR(reg)					\

Signature · 1 line

1.6.0.4

OMAP1 doesn't have a SCM, so this is the wrong fix. A better approach is here:

https://patchwork.kernel.org/patch/218992/

Quoted 19 lines · Kevin Hilman

Quoted 12 lines · Tony Lindgren

Quoted 11 lines · Kevin Hilman

Tony,

The following pull request will bring hwmod driver conversions for watchdog, UART and i2c drivers. It is based on your omap-for-linus branch.

The i2c driver is waiting for final signoff/ack from the upstream subsystem maintainers, but are otherwise ready to go for broader testing. After I get the final ack, I will update the branch for a final pull.

Quoted 4 lines

Quoted 2 lines

In the meantime, I'd like to get them into l-o master (or omap-testing) for broader testing.

Tried pulling it but I'm getting tons of these errors on omap2:

Quoted 7 lines

Tony,

Can you pull the latest version of my pm-hwmods branch from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-hwmods

This version has the updated patch from Rajendra for i2c as well as some UART3 fixes for a problem he noticed on 2430 as well.

Getting closer.. Now 2430sdp boots OK. But on N800 (2420) I get the following very early on:

...

[    0.000000] Calibrating delay loop... 318.27 BogoMIPS (lpj=1245184)
[    0.000000] pid_max: default: 32768 minimum: 301
[    0.000000] Security Framework initialized
[    0.000000] Mount-cache hash table entries: 512
[    0.000000] CPU: Testing write buffer coherency: ok
[    0.000000] Unhandled fault: imprecise external abort (0xc06) at 0x00000000
[    0.000000] Internal error: : c06 [#1] SMP
[    0.000000] last sysfs file:
[    0.000000] Modules linked in:
[    0.000000] CPU: 0    Not tainted  (2.6.36-rc6-08801-g332f930 #395)
[    0.000000] PC is at kernel_thread_helper+0x0/0x14
[    0.000000] LR is at kernel_thread_helper+0x0/0x14
[    0.000000] pc : [<c004cc94>]    lr : [<c004cc94>]    psr: 00000093
[    0.000000] sp : c7825ff8  ip : 00000000  fp : 00000000
[    0.000000] r10: 00000000  r9 : 00000000  r8 : 00000000
[    0.000000] r7 : 00000013  r6 : c004cca8  r5 : c00a4dc0  r4 : 00000000
[    0.000000] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000000

[    0.000000] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    0.000000] Control: 00c5387f  Table: 80004000  DAC: 00000017
[    0.000000] Process swapper (pid: 2, stack limit = 0xc78242f8)
[    0.000000] Stack: (0xc7825ff8 to 0xc7826000)
[    0.000000] 5fe0:                                                       ffffffff ffffffff
[    0.000000] [<c004cc94>] (kernel_thread_helper+0x0/0x14) from [<ffffffff>] (0xffffffff)
[    0.000000] Code: c04d9ba8 c04de459 c05ca0a0 c04caf13 (eb01ac97)
[    0.000000] ---[ end trace 1b75b31a2719ed1c ]---

Then trying to build for omap1 OSK fails with:

Quoted 49 lines · Tony Lindgren

Quoted 19 lines · Kevin Hilman

Quoted 12 lines · Tony Lindgren

Quoted 11 lines · Kevin Hilman

Tony,

The following pull request will bring hwmod driver conversions for watchdog, UART and i2c drivers. It is based on your omap-for-linus branch.

The i2c driver is waiting for final signoff/ack from the upstream subsystem maintainers, but are otherwise ready to go for broader testing. After I get the final ack, I will update the branch for a final pull.

Quoted 4 lines

Quoted 2 lines

In the meantime, I'd like to get them into l-o master (or omap-testing) for broader testing.

Tried pulling it but I'm getting tons of these errors on omap2:

Quoted 7 lines

Tony,

Can you pull the latest version of my pm-hwmods branch from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-hwmods

This version has the updated patch from Rajendra for i2c as well as some UART3 fixes for a problem he noticed on 2430 as well.

Getting closer.. Now 2430sdp boots OK. But on N800 (2420) I get the following very early on:

...

[    0.000000] Calibrating delay loop... 318.27 BogoMIPS (lpj=1245184)
[    0.000000] pid_max: default: 32768 minimum: 301
[    0.000000] Security Framework initialized
[    0.000000] Mount-cache hash table entries: 512
[    0.000000] CPU: Testing write buffer coherency: ok
[    0.000000] Unhandled fault: imprecise external abort (0xc06) at 0x00000000
[    0.000000] Internal error: : c06 [#1] SMP
[    0.000000] last sysfs file:
[    0.000000] Modules linked in:
[    0.000000] CPU: 0    Not tainted  (2.6.36-rc6-08801-g332f930 #395)
[    0.000000] PC is at kernel_thread_helper+0x0/0x14
[    0.000000] LR is at kernel_thread_helper+0x0/0x14
[    0.000000] pc : [<c004cc94>]    lr : [<c004cc94>]    psr: 00000093
[    0.000000] sp : c7825ff8  ip : 00000000  fp : 00000000
[    0.000000] r10: 00000000  r9 : 00000000  r8 : 00000000
[    0.000000] r7 : 00000013  r6 : c004cca8  r5 : c00a4dc0  r4 : 00000000
[    0.000000] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000000

Quoted 9 lines

[    0.000000] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    0.000000] Control: 00c5387f  Table: 80004000  DAC: 00000017
[    0.000000] Process swapper (pid: 2, stack limit = 0xc78242f8)
[    0.000000] Stack: (0xc7825ff8 to 0xc7826000)
[    0.000000] 5fe0:                                                       ffffffff ffffffff
[    0.000000] [<c004cc94>] (kernel_thread_helper+0x0/0x14) from [<ffffffff>] (0xffffffff)
[    0.000000] Code: c04d9ba8 c04de459 c05ca0a0 c04caf13 (eb01ac97)
[    0.000000] ---[ end trace 1b75b31a2719ed1c ]---

Hmm, this fault is very early and long before any PM code has initialzed. I suspect this happens with the master branch too ??

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Thursday, September 30, 2010 9:37 PM
To: Tony Lindgren; Nayak, Rajendra
Cc: [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 66 lines · Kevin Hilman

Quoted 63 lines · Kevin Hilman

Quoted 49 lines · Tony Lindgren

Quoted 19 lines · Kevin Hilman

Quoted 12 lines · Tony Lindgren

Quoted 11 lines · Kevin Hilman

Tony,

The following pull request will bring hwmod driver conversions for watchdog, UART and i2c drivers. It is based on your omap-for-linus branch.

The i2c driver is waiting for final signoff/ack from the upstream subsystem maintainers, but are otherwise ready to go for broader testing. After I get the final ack, I will update the branch for a final pull.

Quoted 4 lines

Quoted 2 lines

In the meantime, I'd like to get them into l-o master (or omap-testing) for broader testing.

Tried pulling it but I'm getting tons of these errors on omap2:

Quoted 7 lines

Tony,

Can you pull the latest version of my pm-hwmods branch from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-hwmods

This version has the updated patch from Rajendra for i2c as well as some UART3 fixes for a problem he noticed on 2430 as well.

Getting closer.. Now 2430sdp boots OK. But on N800 (2420) I get the following very early on:

...

[    0.000000] Calibrating delay loop... 318.27 BogoMIPS (lpj=1245184)
[    0.000000] pid_max: default: 32768 minimum: 301
[    0.000000] Security Framework initialized
[    0.000000] Mount-cache hash table entries: 512
[    0.000000] CPU: Testing write buffer coherency: ok
[    0.000000] Unhandled fault: imprecise external abort (0xc06) at 0x00000000
[    0.000000] Internal error: : c06 [#1] SMP
[    0.000000] last sysfs file:
[    0.000000] Modules linked in:
[    0.000000] CPU: 0    Not tainted  (2.6.36-rc6-08801-g332f930 #395)
[    0.000000] PC is at kernel_thread_helper+0x0/0x14
[    0.000000] LR is at kernel_thread_helper+0x0/0x14
[    0.000000] pc : [<c004cc94>]    lr : [<c004cc94>]    psr: 00000093
[    0.000000] sp : c7825ff8  ip : 00000000  fp : 00000000
[    0.000000] r10: 00000000  r9 : 00000000  r8 : 00000000
[    0.000000] r7 : 00000013  r6 : c004cca8  r5 : c00a4dc0  r4 : 00000000
[    0.000000] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000000

Quoted 9 lines

[    0.000000] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    0.000000] Control: 00c5387f  Table: 80004000  DAC: 00000017
[    0.000000] Process swapper (pid: 2, stack limit = 0xc78242f8)
[    0.000000] Stack: (0xc7825ff8 to 0xc7826000)
[    0.000000] 5fe0:                                                       ffffffff ffffffff
[    0.000000] [<c004cc94>] (kernel_thread_helper+0x0/0x14) from [<ffffffff>] (0xffffffff)
[    0.000000] Code: c04d9ba8 c04de459 c05ca0a0 c04caf13 (eb01ac97)
[    0.000000] ---[ end trace 1b75b31a2719ed1c ]---

Hmm, this fault is very early and long before any PM code has initialzed. I suspect this happens with the master branch too ??

Quoted 4 lines

I've reproduced this now, and it doesn't happen on the master branch and only happens after merge pm-hwmods.

Debugging now...

OK, so this failure is (somehow) related to the i2c hwmods, but I did not figure out how. Rajendra, can you dig into this? It only seems to happen on 2420/n800, and all other platforms seem OK.

I tried

(quoted diff) +1 -0

+	.flags          = HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE,

for the i2c hwmods, and that didn't help either. The only thing that made the system boot further was commenting out the i2c hwmods in the omap2420_hwmod array.

Attached is the defconfig I used to get a kernel small enough for nolo to load it on my n810.

Kevin

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

Hmm, this fault is very early and long before any PM code has initialzed. I suspect this happens with the master branch too ??

Quoted 8 lines

Quoted 4 lines

I've reproduced this now, and it doesn't happen on the master branch and only happens after merge pm-hwmods.

Debugging now...

OK, so this failure is (somehow) related to the i2c hwmods, but I did not figure out how. Rajendra, can you dig into this? It only seems to happen on 2420/n800, and all other platforms seem OK.

Hi Kevin,

I was able to reproduce the crash on the n800 and have been debugging it for a while. Like you said putting a HWMOD_INIT_NO_RESET did not seem to fix it for me, and the only way I can get the n800 to completely bootup is by removing the sysc completely for i2c. That is quite surprising since the only thing that can be done using the sysconfig on omap2420 is a softreset.

I verified that its not the sysc read itself that causes a crash (clocks seem to be enabled, idlest seems fine) but somehow just these sysc reads (if I have HWMOD_INIT_NO_RESET set) seem to be enough to cause the crash. Nothing gets written back to the sysc register either. I was suspecting the omap_readl's done in hmwod framework on the 16bit 2420 registers to be an issue, but I am yet to figure out how.

I am debugging this further, but in the meantime since this is gating all other patches to get merged in omap-testing, should I just remove the sysc for i2c on 2420? The only thing it will prevent is a i2c softreset at boot, which anyway does not seem to be causing any issues on n800.

"Nayak, Rajendra" <[email protected]> writes:

[...]

Quoted 12 lines

Quoted 12 lines

Quoted 8 lines

Quoted 3 lines

Hmm, this fault is very early and long before any PM code has initialzed. I suspect this happens with the master branch too ??

I've reproduced this now, and it doesn't happen on the master branch and only happens after merge pm-hwmods.

Debugging now...

OK, so this failure is (somehow) related to the i2c hwmods, but I did not figure out how. Rajendra, can you dig into this? It only seems to happen on 2420/n800, and all other platforms seem OK.

For omap-testing, I will just drop the i2c series for now until this is better understood.

Quoted 16 lines · Kevin Hilman

"Nayak, Rajendra" <[email protected]> writes:

[...]

Quoted 12 lines

Quoted 12 lines

Quoted 8 lines

Quoted 3 lines

Hmm, this fault is very early and long before any PM code has initialzed. I suspect this happens with the master branch too ??

I've reproduced this now, and it doesn't happen on the master branch and only happens after merge pm-hwmods.

Debugging now...

OK, so this failure is (somehow) related to the i2c hwmods, but I did not figure out how. Rajendra, can you dig into this? It only seems to happen on 2420/n800, and all other platforms seem OK.

[...]

Quoted 2 lines

For omap-testing, I will just drop the i2c series for now until this is better understood.

Tony,

I pushed a new version of the pm-hwmods branch, this time with only UART and watchdog

Please pull the latest from here:

ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-hwmods

Quoted 77 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Thursday, September 30, 2010 9:37 PM
To: Tony Lindgren; Nayak, Rajendra
Cc: [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 66 lines · Kevin Hilman

Quoted 63 lines · Kevin Hilman

Quoted 49 lines · Tony Lindgren

Quoted 19 lines · Kevin Hilman

Quoted 12 lines · Tony Lindgren

Quoted 11 lines · Kevin Hilman

Tony,

The following pull request will bring hwmod driver conversions for watchdog, UART and i2c drivers. It is based on your omap-for-linus branch.

The i2c driver is waiting for final signoff/ack from the upstream subsystem maintainers, but are otherwise ready to go for broader testing. After I get the final ack, I will update the branch for a final pull.

Quoted 4 lines

Quoted 2 lines

In the meantime, I'd like to get them into l-o master (or omap-testing) for broader testing.

Tried pulling it but I'm getting tons of these errors on omap2:

Quoted 7 lines

Tony,

Can you pull the latest version of my pm-hwmods branch from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-hwmods

This version has the updated patch from Rajendra for i2c as well as some UART3 fixes for a problem he noticed on 2430 as well.

Getting closer.. Now 2430sdp boots OK. But on N800 (2420) I get the following very early on:

...

[    0.000000] Calibrating delay loop... 318.27 BogoMIPS (lpj=1245184)
[    0.000000] pid_max: default: 32768 minimum: 301
[    0.000000] Security Framework initialized
[    0.000000] Mount-cache hash table entries: 512
[    0.000000] CPU: Testing write buffer coherency: ok
[    0.000000] Unhandled fault: imprecise external abort (0xc06) at 0x00000000
[    0.000000] Internal error: : c06 [#1] SMP
[    0.000000] last sysfs file:
[    0.000000] Modules linked in:
[    0.000000] CPU: 0    Not tainted  (2.6.36-rc6-08801-g332f930 #395)
[    0.000000] PC is at kernel_thread_helper+0x0/0x14
[    0.000000] LR is at kernel_thread_helper+0x0/0x14
[    0.000000] pc : [<c004cc94>]    lr : [<c004cc94>]    psr: 00000093
[    0.000000] sp : c7825ff8  ip : 00000000  fp : 00000000
[    0.000000] r10: 00000000  r9 : 00000000  r8 : 00000000
[    0.000000] r7 : 00000013  r6 : c004cca8  r5 : c00a4dc0  r4 : 00000000
[    0.000000] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000000

Quoted 9 lines

[    0.000000] Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    0.000000] Control: 00c5387f  Table: 80004000  DAC: 00000017
[    0.000000] Process swapper (pid: 2, stack limit = 0xc78242f8)
[    0.000000] Stack: (0xc7825ff8 to 0xc7826000)
[    0.000000] 5fe0:                                                       ffffffff ffffffff
[    0.000000] [<c004cc94>] (kernel_thread_helper+0x0/0x14) from [<ffffffff>] (0xffffffff)
[    0.000000] Code: c04d9ba8 c04de459 c05ca0a0 c04caf13 (eb01ac97)
[    0.000000] ---[ end trace 1b75b31a2719ed1c ]---

Hmm, this fault is very early and long before any PM code has initialzed. I suspect this happens with the master branch too ??

Quoted 8 lines

Quoted 4 lines

I've reproduced this now, and it doesn't happen on the master branch and only happens after merge pm-hwmods.

Debugging now...

OK, so this failure is (somehow) related to the i2c hwmods, but I did not figure out how. Rajendra, can you dig into this? It only seems to happen on 2420/n800, and all other platforms seem OK.

Hi Kevin,

I was able to reproduce the crash on the n800 and have been debugging it for a while. Like you said putting a HWMOD_INIT_NO_RESET did not seem to fix it for me, and the only way I can get the n800 to completely bootup is by removing the sysc completely for i2c.
That is quite surprising since the only thing that can be done using the sysconfig on omap2420 is a softreset.

I verified that its not the sysc read itself that causes a crash (clocks seem to be enabled, idlest seems fine) but somehow just these sysc reads (if I have HWMOD_INIT_NO_RESET set) seem to be enough to cause the crash.

Nothing gets written back to the sysc register either.
I was suspecting the omap_readl's done in hmwod framework on the 16bit 2420 registers to be an issue, but I am yet to figure out how.

I am debugging this further, but in the meantime since this is gating all other patches to get merged in omap-testing, should I just remove the sysc for i2c on 2420? The only
thing it will prevent is a i2c softreset at boot, which anyway does not seem to be causing any issues on n800.

Regards,
Rajendra

Quoted 5 lines

I tried

(quoted diff) +1 -0

+	.flags          = HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE,

Quoted 9 lines

for the i2c hwmods, and that didn't help either. The only thing that made the system boot further was commenting out the i2c hwmods in the omap2420_hwmod array.

Attached is the defconfig I used to get a kernel small enough for nolo to load it on my n810.

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

The issue is that 2420 idlest does not reflect the real status of the OCP bus clock, but just the fact that the idle_req is asserted or not.

So potentially, the IP is still not accessible when you think it is. This imprecise external abort always happen when you try to access an IP that is not properly clock.

BTW, this is exactly the same kind of issue we have with FDIF and ISS on OMAP4.

The easy quick and dirty fix is to comment out the sysconfig structure in the hwmod definition. You will then prevent any access to the sysconfig. Otherwise, I'm quite sure that a small udelay(1000) can help fixing such issue as well.

Do not forget that 2420 is the very first implementation of the PRCM + smartidle mechanism... It was broken for most IPs at that time :-)

-----Original Message-----
From: Paul Walmsley [mailto:[email protected]]
Sent: Tuesday, October 05, 2010 11:32 AM
To: Cousson, Benoit
Cc: Nayak, Rajendra; Kevin Hilman; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Hello Benoît, Rajendra, Kevin,

Quoted 9 lines · Benoit

The issue is that 2420 idlest does not reflect the real status of the OCP bus clock, but just the fact that the idle_req is asserted or not.

So potentially, the IP is still not accessible when you think it is. This imprecise external abort always happen when you try to access an IP that is not properly clock.

BTW, this is exactly the same kind of issue we have with FDIF and ISS on OMAP4.

Won't the new idle protocol resolve this for OMAP4 ?

Quoted 5 lines

The easy quick and dirty fix is to comment out the sysconfig structure in the hwmod definition. You will then prevent any access to the sysconfig. Otherwise, I'm quite sure that a small udelay(1000) can help fixing such issue as well.

Quoted 2 lines

Do not forget that 2420 is the very first implementation of the PRCM + smartidle mechanism... It was broken for most IPs at that time :-)

Below is an untested patch to provide some mechanism to deal with this -- I'd appreciate everyone's comments on this, particularly the comments in the patch code on how to deal with this problem.

- Paul

From: Paul Walmsley <[email protected]>
Date: Mon, 4 Oct 2010 23:15:23 -0600
Subject: [PATCH] OMAP: hwmod: add configurable device enable delay after PRCM IdleAck deasserts
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some IP blocks may require extra time to become ready for register reads/writes after the PRCM deasserts its IdleAck signal to the

module. If an imprecise external abort happens during or shortly after the hwmod is enabled, extra time is needed[1]. For those modules, add a new struct omap_hwmod field, .enable_delay. This field represents the number of microseconds that the hwmod code should delay before attempting to access the IP block's registers or relinquishing control to the calling code.

Copious guidance is also provided to aid developers in determining the appropriate hwmod value.

This problem was identified by Kevin Hilman and Rajendra Nayak. Benoît Cousson identified the solution.

1. http://www.mail-archive.com/[email protected]/msg36300.html

Signed-off-by Paul Walmsley <[email protected]>

Cc Benoît Cousson <[email protected]>

Cc Rajendra Nayak <[email protected]>

Cc Kevin Hilman <[email protected]>

---
 arch/arm/mach-omap2/omap_hwmod.c             |    3 ++
 arch/arm/plat-omap/include/plat/omap_hwmod.h |   33 ++++++++++++++++++++++++-
 2 files changed, 34 insertions(+), 2 deletions(-)

arch/arm/mach-omap2/omap_hwmod.c +3 -0

index 955861a..fbcfe14 100644
@@ -1204,6 +1204,9 @@ int _omap_hwmod_enable(struct omap_hwmod *oh)
 
 	r = _wait_target_ready(oh);
 	if (!r) {
+		if (oh->enable_delay)
+			udelay(oh->enable_delay);
+
 		oh->_state = _HWMOD_STATE_ENABLED;
 
 		/* Access the sysconfig only if the target is ready */

arch/arm/plat-omap/include/plat/omap_hwmod.h +31 -3

index c1835af..5a1e058 100644
@@ -434,6 +434,7 @@ struct omap_hwmod_class {
  * @main_clk: main clock: OMAP clock name
  * @_clk: pointer to the main struct clk (filled in at runtime)
  * @opt_clks: other device clocks that drivers can request (0..*)
+ * @enable_delay: number of microseconds to wait after IdleReq is deasserted
  * @masters: ptr to array of OCP ifs that this hwmod can initiate on
  * @slaves: ptr to array of OCP ifs that this hwmod can respond on
  * @dev_attr: arbitrary device attributes that can be passed to the driver

@@ -460,8 +461,35 @@ struct omap_hwmod_class {
  * accesses to complete."  Modules may not have a main clock if the
  * interface clock also serves as a main clock.
  *
- * Parameter names beginning with an underscore are managed internally by
- * the omap_hwmod code and should not be set during initialization.
+ * On OMAP SoCs prior to OMAP4, some hwmods may require a non-zero
+ * @enable_delay value.  A hwmod needs a non-zero @enable_delay if an
+ * imprecise external abort occurs while the hwmod is being enabled.
+ * This can happen if the hwmod takes a significant time to become
+ * ready for OCP transactions after the PRCM deasserts IdleAck to the
+ * module.  @enable_delay specifies the number of microseconds for the
+ * hwmod code to udelay() between the time that the PRCM deasserts the
+ * IdleAck, and the time when the module is ready to handle register
+ * reads/writes.  Most hwmods shouldn't need anything here and can
+ * leave @enable_delay blank.  For hwmods that do need a value here,
+ * to estimate the required value, the best thing to do is to set the
+ * IP block to run at the slowest interface and functional clock rates
+ * and the lowest voltages.  First, try out a small value, say, 10
+ * microseconds, and keep increasing it until the kernel no longer
+ * crashes.  Then add a safety margin to the value that you arrived at
+ * -- say, 50% -- and specify the value in the structure record
+ * initializer for @enable_delay as (value + safety_margin).  Try not
+ * to overestimate this number; if @enable_delay is too large, then
+ * energy will be wasted and the CPU will spin for an unnecessarily
+ * long time while enabling the device.  If @enable_delay is too
+ * small, the device will trigger an abort.  More information is
+ * available here:
+ * http://www.mail-archive.com/[email protected]/msg36300.html
+ * XXX @enable_value will need to be taken into consideration by the
+ * omap_device code to determine whether the device's current wakeup
+ * latency constraint can be satisfied if the module is placed into idle.
+ *
+ * Parameter names beginning with an underscore are managed internally
+ * by the omap_hwmod code and should not be set during initialization.
  */
 struct omap_hwmod {
 	const char			*name;

@@ -484,6 +512,7 @@ struct omap_hwmod {
 	void __iomem			*_mpu_rt_va;
 	struct mutex			_mutex;
 	struct list_head		node;
+	u16				enable_delay;
 	u16				flags;
 	u8				_mpu_port_index;
 	u8				msuspendmux_reg_id;
--

1.7.1

Quoted 6 lines

-----Original Message-----
From: Paul Walmsley [mailto:[email protected]]
Sent: Tuesday, October 05, 2010 11:32 AM

Some IP blocks may require extra time to become ready for register reads/writes after the PRCM deasserts its IdleAck signal to the

Maybe it should say 'PRCM deasserts its IdleReq'

Quoted 4 lines · Rajendra

Quoted 4 lines

-----Original Message-----
From: Paul Walmsley [mailto:[email protected]]
Sent: Tuesday, October 05, 2010 11:32 AM

Quoted 4 lines

Quoted 2 lines

Some IP blocks may require extra time to become ready for register reads/writes after the PRCM deasserts its IdleAck signal to the

Maybe it should say 'PRCM deasserts its IdleReq'

Oops, yes, you are right; will fix and repost an updated version.

Quoted 4 lines

Below is an untested patch to provide some mechanism to deal with this -- I'd appreciate everyone's comments on this, particularly the comments in the patch code on how to deal with this problem.

Hi Paul,

I'll test this patch to see if it solves the issue seen with i2c on n800.

From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001

-----Original Message-----
From: Nayak, Rajendra
Sent: Tuesday, October 05, 2010 6:04 PM
To: Nayak, Rajendra; Paul Walmsley; Cousson, Benoit
Cc: Kevin Hilman; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

<snip>..

Quoted 7 lines

Quoted 4 lines

Below is an untested patch to provide some mechanism to deal with this -- I'd appreciate everyone's comments on this, particularly the comments in the patch code on how to deal with this problem.

Hi Paul,

Quoted 1 line

I'll test this patch to see if it solves the issue seen with i2c on n800.

Hi Paul, Benoit, Kevin,

So looks like the issue with i2c on n800 isn't really because of additional delay needed after a clock enable, but related to the omap_readl/writel's done on the 16bit i2c registers as I was suspecting earlier.

The below patch fixes the n800 issue for me. My mailer might mess up the alignment hence attaching it too.

From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <[email protected]>
Date: Tue, 5 Oct 2010 16:36:30 +0530
Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers

Some modules which have 16bit registers can cause imprecise aborts if a __raw_readl/writel is used to read/write 32 bits.

Add an additional flag to identify modules which have such hard requirement, and handle it in the hwmod framework.

Signed-off-by Rajendra Nayak <[email protected]>

---
 arch/arm/mach-omap2/omap_hwmod.c             |   24 +++++++++++++++---------
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    6 ++++--
 2 files changed, 19 insertions(+), 11 deletions(-)

arch/arm/mach-omap2/omap_hwmod.c +15 -9

index 955861a..5a30658 100644
@@ -184,7 +184,7 @@ static int _update_sysc_cache(struct omap_hwmod *oh)
 
 	/* XXX ensure module interface clock is up */
 
-	oh->_sysc_cache = omap_hwmod_readl(oh, oh->class->sysc->sysc_offs);
+	oh->_sysc_cache = omap_hwmod_read(oh, oh->class->sysc->sysc_offs);
 
 	if (!(oh->class->sysc->sysc_flags & SYSC_NO_CACHE))
 		oh->_int_flags |= _HWMOD_SYSCONFIG_LOADED;

@@ -211,7 +211,7 @@ static void _write_sysconfig(u32 v, struct omap_hwmod *oh)
 
 	if (oh->_sysc_cache != v) {
 		oh->_sysc_cache = v;
-		omap_hwmod_writel(v, oh, oh->class->sysc->sysc_offs);
+		omap_hwmod_write(v, oh, oh->class->sysc->sysc_offs);
 	}
 }
 

@@ -1133,12 +1133,12 @@ static int _reset(struct omap_hwmod *oh)
 	_write_sysconfig(v, oh);
 
 	if (oh->class->sysc->sysc_flags & SYSS_HAS_RESET_STATUS)
-		omap_test_timeout((omap_hwmod_readl(oh,
+		omap_test_timeout((omap_hwmod_read(oh,
 						    oh->class->sysc->syss_offs)
 				   & SYSS_RESETDONE_MASK),
 				  MAX_MODULE_SOFTRESET_WAIT, c);
 	else if (oh->class->sysc->sysc_flags & SYSC_HAS_RESET_STATUS)
-		omap_test_timeout(!(omap_hwmod_readl(oh,
+		omap_test_timeout(!(omap_hwmod_read(oh,
 						     oh->class->sysc->sysc_offs)
 				   & SYSC_TYPE2_SOFTRESET_MASK),
 				  MAX_MODULE_SOFTRESET_WAIT, c);

@@ -1378,14 +1378,20 @@ static int _setup(struct omap_hwmod *oh, void *data)
 
 /* Public functions */
 
-u32 omap_hwmod_readl(struct omap_hwmod *oh, u16 reg_offs)
+u32 omap_hwmod_read(struct omap_hwmod *oh, u16 reg_offs)
 {
-	return __raw_readl(oh->_mpu_rt_va + reg_offs);
+	if (oh->flags & HWMOD_16BIT_REG)
+		return __raw_readw(oh->_mpu_rt_va + reg_offs);
+	else
+		return __raw_readl(oh->_mpu_rt_va + reg_offs);
 }
 
-void omap_hwmod_writel(u32 v, struct omap_hwmod *oh, u16 reg_offs)
+void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16 reg_offs)
 {
-	__raw_writel(v, oh->_mpu_rt_va + reg_offs);
+	if (oh->flags & HWMOD_16BIT_REG)
+		__raw_writew(v, oh->_mpu_rt_va + reg_offs);
+	else
+		__raw_writel(v, oh->_mpu_rt_va + reg_offs);
 }
 
 /**

@@ -1732,7 +1738,7 @@ void omap_hwmod_ocp_barrier(struct omap_hwmod *oh)
 	 * Forces posted writes to complete on the OCP thread handling
 	 * register writes
 	 */
-	omap_hwmod_readl(oh, oh->class->sysc->sysc_offs);
+	omap_hwmod_read(oh, oh->class->sysc->sysc_offs);
 }
 
 /**

arch/arm/plat-omap/include/plat/omap_hwmod.h +4 -3

index c1835af..7eaa8ed 100644
@@ -370,6 +370,7 @@ struct omap_hwmod_omap4_prcm {
  *     This is needed for devices like DSS that require optional clocks enabled
  *     in order to complete the reset. Optional clocks will be disabled
  *     again after the reset.
+ * HWMOD_16BIT_REG: Module has 16bit registers
  */
 #define HWMOD_SWSUP_SIDLE			(1 << 0)
 #define HWMOD_SWSUP_MSTANDBY			(1 << 1)

@@ -379,6 +380,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_SET_DEFAULT_CLOCKACT		(1 << 5)
 #define HWMOD_NO_IDLEST				(1 << 6)
 #define HWMOD_CONTROL_OPT_CLKS_IN_RESET		(1 << 7)
+#define HWMOD_16BIT_REG				(1 << 8)
 
 /*
  * omap_hwmod._int_flags definitions

@@ -527,8 +529,8 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode);
 int omap_hwmod_reset(struct omap_hwmod *oh);
 void omap_hwmod_ocp_barrier(struct omap_hwmod *oh);
 
-void omap_hwmod_writel(u32 v, struct omap_hwmod *oh, u16 reg_offs);
-u32 omap_hwmod_readl(struct omap_hwmod *oh, u16 reg_offs);
+void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16 reg_offs);
+u32 omap_hwmod_read(struct omap_hwmod *oh, u16 reg_offs);
 
 int omap_hwmod_count_resources(struct omap_hwmod *oh);
 int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
--

1.7.0.4

So looks like the issue with i2c on n800 isn't really because of additional delay needed after a clock enable, but related to the omap_readl/writel's done on the 16bit i2c registers as I was suspecting earlier.

The below patch fixes the n800 issue for me. My mailer might mess up the alignment hence attaching it too.

Quoted 1 line

From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001

From: Rajendra Nayak <[email protected]>
Date: Tue, 5 Oct 2010 16:36:30 +0530
Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers

Some modules which have 16bit registers can cause imprecise aborts if a __raw_readl/writel is used to read/write 32 bits.

Add an additional flag to identify modules which have such hard requirement, and handle it in the hwmod framework.

Signed-off-by Rajendra Nayak <[email protected]>

                __raw_writew(v, oh->_mpu_rt_va + reg_offs);
      28:       16ff3070        uxthne  r3, r0
      2c:       118130b2        strhne  r3, [r1, r2]

gcc for some reason decides to zero-extend it first, but that is not your bug to fix.

-----Original Message-----
From: Paul Walmsley [mailto:[email protected]]
Sent: Tuesday, October 05, 2010 10:28 PM
To: Nayak, Rajendra
Cc: Cousson, Benoit; Kevin Hilman; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 15 lines · Rajendra

So looks like the issue with i2c on n800 isn't really because of additional delay needed after a clock enable, but related to the omap_readl/writel's done on the 16bit i2c registers as I was suspecting earlier.

The below patch fixes the n800 issue for me. My mailer might mess up the alignment hence attaching it too.

Quoted 1 line

From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001

From: Rajendra Nayak <[email protected]>
Date: Tue, 5 Oct 2010 16:36:30 +0530
Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers

Some modules which have 16bit registers can cause imprecise aborts if a __raw_readl/writel is used to read/write 32 bits.

Quoted 4 lines

Add an additional flag to identify modules which have such hard requirement, and handle it in the hwmod framework.

Signed-off-by Rajendra Nayak <[email protected]>

Nice work, looks good to me. Hopefully we won't need that enable_delay patch!

I was initially concerned that your patch tried to store a 32-bit quantity into a 16-bit register. But I guess the cast to unsigned short in the __raw_writew macro takes care of this:

                __raw_writew(v, oh->_mpu_rt_va + reg_offs);
      28:       16ff3070        uxthne  r3, r0
      2c:       118130b2        strhne  r3, [r1, r2]

gcc for some reason decides to zero-extend it first, but that is not your bug to fix.

This patch is targeted for merging via 2.6.37 via Tony's tree.

Acked-by Paul Walmsley <[email protected]>

- Paul

<snip>..

Quoted 8 lines

Quoted 4 lines

Below is an untested patch to provide some mechanism to deal with this -- I'd appreciate everyone's comments on this, particularly the comments in the patch code on how to deal with this problem.

Hi Paul,

I'll test this patch to see if it solves the issue seen with i2c on n800.

Hi Paul, Benoit, Kevin,

So looks like the issue with i2c on n800 isn't really because of additional delay needed after a clock enable, but related to the omap_readl/writel's done on the 16bit i2c registers as I was suspecting earlier.

The below patch fixes the n800 issue for me. My mailer might mess up the alignment hence attaching it too.

From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <[email protected]>
Date: Tue, 5 Oct 2010 16:36:30 +0530
Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers

Some modules which have 16bit registers can cause imprecise aborts if a __raw_readl/writel is used to read/write 32 bits.

Add an additional flag to identify modules which have such hard requirement, and handle it in the hwmod framework.

Signed-off-by Rajendra Nayak <[email protected]>

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, October 05, 2010 10:34 PM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 28 lines · Rajendra

<snip>..

Quoted 8 lines

Quoted 4 lines

Below is an untested patch to provide some mechanism to deal with this -- I'd appreciate everyone's comments on this, particularly the comments in the patch code on how to deal with this problem.

Hi Paul,

I'll test this patch to see if it solves the issue seen with i2c on n800.

Hi Paul, Benoit, Kevin,

So looks like the issue with i2c on n800 isn't really because of additional delay needed after a clock enable, but related to the omap_readl/writel's done on the 16bit i2c registers as I was suspecting earlier.

The below patch fixes the n800 issue for me. My mailer might mess up the alignment hence attaching it too.

From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <[email protected]>
Date: Tue, 5 Oct 2010 16:36:30 +0530
Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers

Some modules which have 16bit registers can cause imprecise aborts if a __raw_readl/writel is used to read/write 32 bits.

Quoted 4 lines

Add an additional flag to identify modules which have such hard requirement, and handle it in the hwmod framework.

Signed-off-by Rajendra Nayak <[email protected]>

Can you also send a corresponding patch to the i2c hwmod data.

I'll rebase the rest of the series against current l-o master, and maybe we can still get this in for .37.

Kevin

Quoted 41 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, October 05, 2010 10:34 PM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 31 lines · Rajendra

<snip>..

Quoted 8 lines

Quoted 4 lines

Below is an untested patch to provide some mechanism to deal with this -- I'd appreciate everyone's comments on this, particularly the comments in the patch code on how to deal with this problem.

Hi Paul,

I'll test this patch to see if it solves the issue seen with i2c on n800.

Hi Paul, Benoit, Kevin,

So looks like the issue with i2c on n800 isn't really because of additional delay needed after a clock enable, but related to the omap_readl/writel's done on the 16bit i2c registers as I was suspecting earlier.

The below patch fixes the n800 issue for me. My mailer might mess up the alignment hence attaching it too.

From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <[email protected]>
Date: Tue, 5 Oct 2010 16:36:30 +0530
Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers

Some modules which have 16bit registers can cause imprecise aborts if a __raw_readl/writel is used to read/write 32 bits.

Add an additional flag to identify modules which have such hard requirement, and handle it in the hwmod framework.

Quoted 3 lines

Quoted 1 line

Signed-off-by Rajendra Nayak <[email protected]>

Can you also send a corresponding patch to the i2c hwmod data.

Hi Kevin,

Ok, I'll repost the original patch which adds the omap2 hwmod data with these flags added for omap2420. Does that sound fine?

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Wednesday, October 06, 2010 1:19 AM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 43 lines · Rajendra

Quoted 43 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, October 05, 2010 10:34 PM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 32 lines · Rajendra

<snip>..

Quoted 8 lines

Quoted 4 lines

Below is an untested patch to provide some mechanism to deal with this -- I'd appreciate everyone's comments on this, particularly the comments in the patch code on how to deal with this problem.

Hi Paul,

I'll test this patch to see if it solves the issue seen with i2c on n800.

Hi Paul, Benoit, Kevin,

So looks like the issue with i2c on n800 isn't really because of additional delay needed after a clock enable, but related to the omap_readl/writel's done on the 16bit i2c registers as I was suspecting earlier.

The below patch fixes the n800 issue for me. My mailer might mess up the alignment hence attaching it too.

From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <[email protected]>
Date: Tue, 5 Oct 2010 16:36:30 +0530
Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers

Some modules which have 16bit registers can cause imprecise aborts if a __raw_readl/writel is used to read/write 32 bits.

Add an additional flag to identify modules which have such hard requirement, and handle it in the hwmod framework.

Signed-off-by Rajendra Nayak <[email protected]>

Quoted 5 lines

Quoted 1 line

Can you also send a corresponding patch to the i2c hwmod data.

Hi Kevin,

Ok, I'll repost the original patch which adds the omap2 hwmod data with these flags added for omap2420. Does that sound fine?

Since I've alrady done some manual merge conflicts here, you can just post an additional patch and I will fold it in.

From 06b4bb7a0ce96776d6d9b344b4786b48fceeffe1 Mon Sep 17 00:00:00 2001

Thanks,

Kevin

Quoted 53 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Wednesday, October 06, 2010 1:19 AM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 43 lines · Rajendra

Quoted 43 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, October 05, 2010 10:34 PM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 32 lines · Rajendra

<snip>..

Quoted 8 lines

Quoted 4 lines

Below is an untested patch to provide some mechanism to deal with this -- I'd appreciate everyone's comments on this, particularly the comments in the patch code on how to deal with this problem.

Hi Paul,

I'll test this patch to see if it solves the issue seen with i2c on n800.

Hi Paul, Benoit, Kevin,

So looks like the issue with i2c on n800 isn't really because of additional delay needed after a clock enable, but related to the omap_readl/writel's done on the 16bit i2c registers as I was suspecting earlier.

The below patch fixes the n800 issue for me. My mailer might mess up the alignment hence attaching it too.

From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <[email protected]>
Date: Tue, 5 Oct 2010 16:36:30 +0530
Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers

Some modules which have 16bit registers can cause imprecise aborts if a __raw_readl/writel is used to read/write 32 bits.

Add an additional flag to identify modules which have such hard requirement, and handle it in the hwmod framework.

Signed-off-by Rajendra Nayak <[email protected]>

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Can you also send a corresponding patch to the i2c hwmod data.

Hi Kevin,

Ok, I'll repost the original patch which adds the omap2 hwmod data with these flags added for omap2420. Does that sound fine?

Since I've alrady done some manual merge conflicts here, you can just post an additional patch and I will fold it in.

Ok, so here's the patch
------
From 06b4bb7a0ce96776d6d9b344b4786b48fceeffe1 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <[email protected]>
Date: Wed, 6 Oct 2010 01:49:32 +0530
Subject: [PATCH] OMAP2: hmwod: Fix impresice aborts seen on n800/n810

I2C module on OMAP2420 has 16bit registers and causes imprecise aborts if 32bits are read/wriitten into.
Use the HWMOD_16BIT_REG flag to notify the hmwod framework of this hard requirement so that __raw_writew/readw is used to read /write the mdoule registers.

Signed-off-by Rajendra Nayak <[email protected]>

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

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Wednesday, October 06, 2010 2:05 AM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 8 lines · Rajendra

Quoted 8 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Wednesday, October 06, 2010 1:19 AM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines · Rajendra

Quoted 5 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, October 05, 2010 10:34 PM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha;

Raja,

Quoted 60 lines

Quoted 38 lines

Quoted 38 lines

Quoted 38 lines

Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 32 lines · Rajendra

<snip>..

Quoted 8 lines

Quoted 4 lines

Below is an untested patch to provide some mechanism to deal with this -- I'd appreciate everyone's comments on this, particularly the comments in the patch code on how to deal with this problem.

Hi Paul,

I'll test this patch to see if it solves the issue seen with i2c on n800.

Hi Paul, Benoit, Kevin,

So looks like the issue with i2c on n800 isn't really because of additional delay needed after a clock enable, but related to the omap_readl/writel's done on the 16bit i2c registers as I was suspecting earlier.

The below patch fixes the n800 issue for me. My mailer might mess up the alignment hence attaching it too.

From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <[email protected]>
Date: Tue, 5 Oct 2010 16:36:30 +0530
Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers

Some modules which have 16bit registers can cause imprecise aborts if a __raw_readl/writel is used to read/write 32 bits.

Add an additional flag to identify modules which have such hard requirement, and handle it in the hwmod framework.

Signed-off-by Rajendra Nayak <[email protected]>

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Can you also send a corresponding patch to the i2c hwmod data.

Hi Kevin,

Ok, I'll repost the original patch which adds the omap2 hwmod data with these flags added for omap2420. Does that sound fine?

Since I've alrady done some manual merge conflicts here, you can just post an additional patch and I will fold it in.

Ok, so here's the patch
------
From 06b4bb7a0ce96776d6d9b344b4786b48fceeffe1 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <[email protected]>
Date: Wed, 6 Oct 2010 01:49:32 +0530
Subject: [PATCH] OMAP2: hmwod: Fix impresice aborts seen on n800/n810

I2C module on OMAP2420 has 16bit registers and causes imprecise aborts if 32bits are read/wriitten into.
Use the HWMOD_16BIT_REG flag to notify the hmwod framework of this hard requirement so that __raw_writew/readw is used to read /write the mdoule registers.

Quoted 4 lines

Signed-off-by Rajendra Nayak <[email protected]>

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

Thanks.

Shouldn't we do the same for 2430? I guess the imprecise aborts aren't happening on 2430, but I think we should still use the 16-bit accesses there too.

What do you think?

Kevin

Quoted 93 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Wednesday, October 06, 2010 2:05 AM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 8 lines · Rajendra

Quoted 8 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Wednesday, October 06, 2010 1:19 AM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines · Rajendra

Quoted 5 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, October 05, 2010 10:34 PM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha;

Raja,

Quoted 60 lines

Quoted 38 lines

Quoted 38 lines

Quoted 38 lines

Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 32 lines · Rajendra

<snip>..

Quoted 8 lines

Quoted 4 lines

Below is an untested patch to provide some mechanism to deal with this -- I'd appreciate everyone's comments on this, particularly the comments in the patch code on how to deal with this problem.

Hi Paul,

I'll test this patch to see if it solves the issue seen with i2c on n800.

Hi Paul, Benoit, Kevin,

So looks like the issue with i2c on n800 isn't really because of additional delay needed after a clock enable, but related to the omap_readl/writel's done on the 16bit i2c registers as I was suspecting earlier.

The below patch fixes the n800 issue for me. My mailer might mess up the alignment hence attaching it too.

From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <[email protected]>
Date: Tue, 5 Oct 2010 16:36:30 +0530
Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers

Some modules which have 16bit registers can cause imprecise aborts if a __raw_readl/writel is used to read/write 32 bits.

Add an additional flag to identify modules which have such hard requirement, and handle it in the hwmod framework.

Signed-off-by Rajendra Nayak <[email protected]>

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Can you also send a corresponding patch to the i2c hwmod data.

Hi Kevin,

Ok, I'll repost the original patch which adds the omap2 hwmod data with these flags added for omap2420. Does that sound fine?

Since I've alrady done some manual merge conflicts here, you can just post an additional patch and I will fold it in.

Ok, so here's the patch
------
From 06b4bb7a0ce96776d6d9b344b4786b48fceeffe1 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <[email protected]>
Date: Wed, 6 Oct 2010 01:49:32 +0530
Subject: [PATCH] OMAP2: hmwod: Fix impresice aborts seen on n800/n810

I2C module on OMAP2420 has 16bit registers and causes imprecise aborts if 32bits are read/wriitten into.
Use the HWMOD_16BIT_REG flag to notify the hmwod framework of this hard requirement so that __raw_writew/readw is used to read /write the mdoule registers.

Quoted 4 lines

Signed-off-by Rajendra Nayak <[email protected]>

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

Thanks.

Quoted 5 lines

Shouldn't we do the same for 2430? I guess the imprecise aborts aren't happening on 2430, but I think we should still use the 16-bit accesses there too.

What do you think?

Yeah, actually i2c modules on all OMAPs including OMAP4 have had 16 bit registers. But somehow only 2420 seemed to cause issues.

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Wednesday, October 06, 2010 2:14 AM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 8 lines · Rajendra

Quoted 8 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Wednesday, October 06, 2010 2:05 AM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha; Raja, Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines · Rajendra

Quoted 5 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Wednesday, October 06, 2010 1:19 AM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha;

Raja,

Quoted 84 lines

Quoted 83 lines

Quoted 10 lines

Quoted 10 lines

Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 5 lines · Rajendra

Quoted 5 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, October 05, 2010 10:34 PM
To: Nayak, Rajendra
Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; [email protected]; Varadarajan, Charulatha;

Raja,

Quoted 60 lines

Quoted 38 lines

Quoted 38 lines

Quoted 38 lines

Govindraj
Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Quoted 32 lines · Rajendra

<snip>..

Quoted 8 lines

Quoted 4 lines

Below is an untested patch to provide some mechanism to deal with this -- I'd appreciate everyone's comments on this, particularly the comments in the patch code on how to deal with this problem.

Hi Paul,

I'll test this patch to see if it solves the issue seen with i2c on n800.

Hi Paul, Benoit, Kevin,

So looks like the issue with i2c on n800 isn't really because of additional delay needed after a clock enable, but related to the omap_readl/writel's done on the 16bit i2c registers as I was suspecting earlier.

The below patch fixes the n800 issue for me. My mailer might mess up the alignment hence attaching it too.

From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <[email protected]>
Date: Tue, 5 Oct 2010 16:36:30 +0530
Subject: [PATCH] OMAP: hwmod: Handle modules with 16bit registers

Some modules which have 16bit registers can cause imprecise aborts if a __raw_readl/writel is used to read/write 32 bits.

Add an additional flag to identify modules which have such hard requirement, and handle it in the hwmod framework.

Signed-off-by Rajendra Nayak <[email protected]>

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Can you also send a corresponding patch to the i2c hwmod data.

Hi Kevin,

Ok, I'll repost the original patch which adds the omap2 hwmod data with these flags added for omap2420. Does that sound fine?

Since I've alrady done some manual merge conflicts here, you can just post an additional patch and I will fold it in.

Ok, so here's the patch
------
From 06b4bb7a0ce96776d6d9b344b4786b48fceeffe1 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <[email protected]>
Date: Wed, 6 Oct 2010 01:49:32 +0530
Subject: [PATCH] OMAP2: hmwod: Fix impresice aborts seen on n800/n810

I2C module on OMAP2420 has 16bit registers and causes imprecise aborts if 32bits are read/wriitten into.
Use the HWMOD_16BIT_REG flag to notify the hmwod framework of this hard requirement so that __raw_writew/readw is used to read /write the mdoule registers.

Quoted 4 lines

Signed-off-by Rajendra Nayak <[email protected]>

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

Thanks.

Shouldn't we do the same for 2430? I guess the imprecise aborts aren't happening on 2430, but I think we should still use the 16-bit accesses there too.

What do you think?

Quoted 2 lines

Yeah, actually i2c modules on all OMAPs including OMAP4 have had 16 bit registers. But somehow only 2420 seemed to cause issues.

OK, then let's keep this as a targetted fix for this merge window, and we can discuss whether this needs to be done for all OMAPs later.

I'll use you current patch,

Thanks,

Kevin

Hello Benoît, Rajendra, Kevin,

Quoted 3 lines · Benoit

The issue is that 2420 idlest does not reflect the real status of the OCP bus clock, but just the fact that the idle_req is asserted or not.

Quoted 6 lines

So potentially, the IP is still not accessible when you think it is. This imprecise external abort always happen when you try to access an IP that is not properly clock.

BTW, this is exactly the same kind of issue we have with FDIF and ISS on OMAP4.

Won't the new idle protocol resolve this for OMAP4 ?

Quoted 6 lines

The easy quick and dirty fix is to comment out the sysconfig structure in the hwmod definition. You will then prevent any access to the sysconfig. Otherwise, I'm quite sure that a small udelay(1000) can help fixing such issue as well.

Quoted 2 lines

Do not forget that 2420 is the very first implementation of the PRCM + smartidle mechanism... It was broken for most IPs at that time :-)

Below is an untested patch to provide some mechanism to deal with this -- I'd appreciate everyone's comments on this, particularly the comments in the patch code on how to deal with this problem.

- Paul

From: Paul Walmsley<[email protected]>
Date: Mon, 4 Oct 2010 23:15:23 -0600
Subject: [PATCH] OMAP: hwmod: add configurable device enable delay after PRCM IdleAck deasserts
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some IP blocks may require extra time to become ready for register reads/writes after the PRCM deasserts its IdleAck signal to the module. If an imprecise external abort happens during or shortly after the hwmod is enabled, extra time is needed[1]. For those modules, add a new struct omap_hwmod field, .enable_delay. This field represents the number of microseconds that the hwmod code should delay before attempting to access the IP block's registers or relinquishing control to the calling code.

Copious guidance is also provided to aid developers in determining the appropriate hwmod value.

This problem was identified by Kevin Hilman and Rajendra Nayak. Benoît Cousson identified the solution.

1. http://www.mail-archive.com/[email protected]/msg36300.html

Signed-off-by Paul Walmsley<[email protected]>

Cc Benoît Cousson<[email protected]>

Cc Rajendra Nayak<[email protected]>

Cc Kevin Hilman<[email protected]>

---
  arch/arm/mach-omap2/omap_hwmod.c             |    3 ++
  arch/arm/plat-omap/include/plat/omap_hwmod.h |   33 ++++++++++++++++++++++++-
  2 files changed, 34 insertions(+), 2 deletions(-)

arch/arm/mach-omap2/omap_hwmod.c +3 -0

index 955861a..fbcfe14 100644
@@ -1204,6 +1204,9 @@ int _omap_hwmod_enable(struct omap_hwmod *oh)
 
  	r = _wait_target_ready(oh);
  	if (!r) {
+		if (oh->enable_delay)
+			udelay(oh->enable_delay);
+
  		oh->_state = _HWMOD_STATE_ENABLED;
 
  		/* Access the sysconfig only if the target is ready */

arch/arm/plat-omap/include/plat/omap_hwmod.h +30 -2

index c1835af..5a1e058 100644
@@ -434,6 +434,7 @@ struct omap_hwmod_class {
   * @main_clk: main clock: OMAP clock name
   * @_clk: pointer to the main struct clk (filled in at runtime)
   * @opt_clks: other device clocks that drivers can request (0..*)
+ * @enable_delay: number of microseconds to wait after IdleReq is deasserted
   * @masters: ptr to array of OCP ifs that this hwmod can initiate on
   * @slaves: ptr to array of OCP ifs that this hwmod can respond on
   * @dev_attr: arbitrary device attributes that can be passed to the driver

@@ -460,8 +461,35 @@ struct omap_hwmod_class {
   * accesses to complete."  Modules may not have a main clock if the
   * interface clock also serves as a main clock.
   *
- * Parameter names beginning with an underscore are managed internally by
- * the omap_hwmod code and should not be set during initialization.
+ * On OMAP SoCs prior to OMAP4, some hwmods may require a non-zero
+ * @enable_delay value.  A hwmod needs a non-zero @enable_delay if an
+ * imprecise external abort occurs while the hwmod is being enabled.
+ * This can happen if the hwmod takes a significant time to become
+ * ready for OCP transactions after the PRCM deasserts IdleAck to the
+ * module.  @enable_delay specifies the number of microseconds for the
+ * hwmod code to udelay() between the time that the PRCM deasserts the
+ * IdleAck, and the time when the module is ready to handle register
+ * reads/writes.  Most hwmods shouldn't need anything here and can
+ * leave @enable_delay blank.  For hwmods that do need a value here,
+ * to estimate the required value, the best thing to do is to set the
+ * IP block to run at the slowest interface and functional clock rates
+ * and the lowest voltages.  First, try out a small value, say, 10
+ * microseconds, and keep increasing it until the kernel no longer
+ * crashes.  Then add a safety margin to the value that you arrived at
+ * -- say, 50% -- and specify the value in the structure record
+ * initializer for @enable_delay as (value + safety_margin).  Try not
+ * to overestimate this number; if @enable_delay is too large, then
+ * energy will be wasted and the CPU will spin for an unnecessarily
+ * long time while enabling the device.  If @enable_delay is too
+ * small, the device will trigger an abort.  More information is
+ * available here:
+ * http://www.mail-archive.com/[email protected]/msg36300.html
+ * XXX @enable_value will need to be taken into consideration by the
+ * omap_device code to determine whether the device's current wakeup
+ * latency constraint can be satisfied if the module is placed into idle.
+ *
+ * Parameter names beginning with an underscore are managed internally
+ * by the omap_hwmod code and should not be set during initialization.
   */
  struct omap_hwmod {
  	const char			*name;

What config are you using to get a small enough kernel to boot on your n810? nolo on my n810 only accepts a maximum size kernel of 2097152 bytes. :(

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, September 28, 2010 11:55 PM
To: [email protected]
Cc: Varadarajan, Charulatha; Nayak, Rajendra; Raja, Govindraj
Subject: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Tony,

The following pull request will bring hwmod driver conversions for watchdog, UART and i2c drivers. It is based on your omap-for-linus branch.

The i2c driver is waiting for final signoff/ack from the upstream subsystem maintainers, but are otherwise ready to go for broader testing. After I get the final ack, I will update the branch for a final pull.

In the meantime, I'd like to get them into l-o master (or omap-testing) for broader testing.

Note this also depends on a handful of patches from my pm-backports branch, most of which you have picked into omap-testing, except for the one I just posted to linux-arm-kernel:

ARM: add cpu_idle_wait() to support CPUidle on SMP systems.

This one is required now that the default config enables SMP.

Charu, Rajendra, Govindraj, since all of the hwmod data changes touch the same files, pulling these together meant I had to manually merge these together. Please do a sanity check of the resulting merge. Thanks.

Kevin

The following changes since commit
b6a26b4b87d7b030a546e7bdaf390ffc58323f36:

 arch/arm/mach-omap1/devices.c                 |   27 +
 arch/arm/mach-omap2/Kconfig                   |   11 +-
 arch/arm/mach-omap2/board-3630sdp.c           |    1 -
 arch/arm/mach-omap2/board-zoom-peripherals.c  |    1 +
 arch/arm/mach-omap2/clock3xxx_data.c          |   22 +
 arch/arm/mach-omap2/cm-regbits-24xx.h         |    4 +
 arch/arm/mach-omap2/cm-regbits-34xx.h         |    2 +
 arch/arm/mach-omap2/devices.c                 |   39 +
 arch/arm/mach-omap2/omap_hwmod_2420_data.c    |  397 ++++++++-

 arch/arm/mach-omap2/omap_hwmod_2430_data.c    |  410 ++++++++-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c    |  549 ++++++++++-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c    |  605 +++++++++++

 arch/arm/mach-omap2/pm34xx.c                  |   17 +-
 arch/arm/mach-omap2/prcm-common.h             |    5 +
 arch/arm/mach-omap2/prm-regbits-34xx.h        |    4 +
 arch/arm/mach-omap2/serial.c                  |  555 ++++++-----
 arch/arm/plat-omap/common.c                   |   16 -
 arch/arm/plat-omap/devices.c                  |   41 -
 arch/arm/plat-omap/i2c.c                      |  124 +--
 arch/arm/plat-omap/include/plat/common.h      |    1 -
 arch/arm/plat-omap/include/plat/dma.h         |    2 +
 arch/arm/plat-omap/include/plat/i2c.h         |   13 +
 arch/arm/plat-omap/include/plat/irqs.h        |    2 +
 arch/arm/plat-omap/include/plat/l4_3xxx.h     |   24 +
 arch/arm/plat-omap/include/plat/omap-serial.h |  129 +++
 drivers/i2c/busses/i2c-omap.c                 |   69 +-
 drivers/serial/Kconfig                        |   27 +
 drivers/serial/Makefile                       |    1 +
 drivers/serial/omap-serial.c                  | 1333
+++++++++++++++++++++++++
 drivers/watchdog/omap_wdt.c                   |   42 +-
 include/linux/i2c-omap.h                      |    5 +
 include/linux/serial_core.h                   |    3 +
 32 files changed, 3984 insertions(+), 497 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/l4_3xxx.h
 create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h
 create mode 100644 drivers/serial/omap-serial.c

Kevin,

Quoted 28 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, September 28, 2010 11:55 PM
To: [email protected]
Cc: Varadarajan, Charulatha; Nayak, Rajendra; Raja, Govindraj
Subject: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

Tony,

The following pull request will bring hwmod driver conversions for watchdog, UART and i2c drivers. It is based on your omap-for-linus branch.

The i2c driver is waiting for final signoff/ack from the upstream subsystem maintainers, but are otherwise ready to go for broader testing. After I get the final ack, I will update the branch for a final pull.

In the meantime, I'd like to get them into l-o master (or omap-testing) for broader testing.

Note this also depends on a handful of patches from my pm-backports branch, most of which you have picked into omap-testing, except for the one I just posted to linux-arm-kernel:

ARM: add cpu_idle_wait() to support CPUidle on SMP systems.

Quoted 6 lines

This one is required now that the default config enables SMP.

Charu, Rajendra, Govindraj, since all of the hwmod data changes touch the same files, pulling these together meant I had to manually merge these together. Please do a sanity check of the resulting merge. Thanks.

Minor observations as mentioned below.

Quoted 6 lines

Kevin

The following changes since commit
b6a26b4b87d7b030a546e7bdaf390ffc58323f36:

<<snip>>

Quoted 10 lines

 arch/arm/mach-omap1/devices.c                 |   27 +
 arch/arm/mach-omap2/Kconfig                   |   11 +-
 arch/arm/mach-omap2/board-3630sdp.c           |    1 -
 arch/arm/mach-omap2/board-zoom-peripherals.c  |    1 +
 arch/arm/mach-omap2/clock3xxx_data.c          |   22 +
 arch/arm/mach-omap2/cm-regbits-24xx.h         |    4 +
 arch/arm/mach-omap2/cm-regbits-34xx.h         |    2 +
 arch/arm/mach-omap2/devices.c                 |   39 +
 arch/arm/mach-omap2/omap_hwmod_2420_data.c    |  397 ++++++++-

"cm-regbits-24xx.h" is included twice in this file

Quoted 3 lines

 arch/arm/mach-omap2/omap_hwmod_2430_data.c    |  410 ++++++++-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c    |  549 ++++++++++-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c    |  605 +++++++++++

The order of hwmod structures for different modules are mixed up. Example, under 'wd_timer' class, uart sysc definitions are placed.

Quoted 17 lines

 arch/arm/mach-omap2/pm34xx.c                  |   17 +-
 arch/arm/mach-omap2/prcm-common.h             |    5 +
 arch/arm/mach-omap2/prm-regbits-34xx.h        |    4 +
 arch/arm/mach-omap2/serial.c                  |  555 ++++++-----
 arch/arm/plat-omap/common.c                   |   16 -
 arch/arm/plat-omap/devices.c                  |   41 -
 arch/arm/plat-omap/i2c.c                      |  124 +--
 arch/arm/plat-omap/include/plat/common.h      |    1 -
 arch/arm/plat-omap/include/plat/dma.h         |    2 +
 arch/arm/plat-omap/include/plat/i2c.h         |   13 +
 arch/arm/plat-omap/include/plat/irqs.h        |    2 +
 arch/arm/plat-omap/include/plat/l4_3xxx.h     |   24 +
 arch/arm/plat-omap/include/plat/omap-serial.h |  129 +++
 drivers/i2c/busses/i2c-omap.c                 |   69 +-
 drivers/serial/Kconfig                        |   27 +
 drivers/serial/Makefile                       |    1 +
 drivers/serial/omap-serial.c                  | 1333

Quoted 8 lines

+++++++++++++++++++++++++

 drivers/watchdog/omap_wdt.c                   |   42 +-
 include/linux/i2c-omap.h                      |    5 +
 include/linux/serial_core.h                   |    3 +
 32 files changed, 3984 insertions(+), 497 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/l4_3xxx.h
 create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h
 create mode 100644 drivers/serial/omap-serial.c

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html