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

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

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

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:

  omap3: cm-t3517: add support for TI HECC (2010-09-27 15:15:35 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-hwmods

Benoit Cousson (3):
      OMAP4: hwmod data: Add watchdog timer
      OMAP4: UART: Add uart1-4 hwmods data for omap4
      OMAP4: hwmod: add I2C hwmods for OMAP4430

Govindraj.R (8):
      OMAP2: UART: remove set_uart_globals
      OMAP clock: Add uart4_ick/fck definitions for 3630
      OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs
      OMAP3: PM: Add prepare idle and resume idle call for uart4
      OMAP3: serial: Fix uart4 handling for 3630
      serial: Add OMAP high-speed UART driver
      OMAP: SERIAL: Enable omap-serial driver in Kconfig
      OMAP3: SERIAL: Initialize all omap-uarts for zoom boards

Kevin Hilman (7):
      OMAP2/3: UART: add omap_hwmod data for UARTs 1-4
      OMAP: UART: omap_device conversions, remove implicit 8520 assumptions
      OMAP: UART: don't do automatic bus-level suspend/resume
      OMAP: UART: use non-locking versions of hwmod enable/idle functions
      Merge branch 'pm-hwmod-wdog' into pm-hwmods
      manual merge for pm-hwmod-uart due to conflicts
      manual merge for pm-hwmod-i2c due to conflicts

Paul Walmsley (2):
      OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430
      OMAP: I2C: split device registration and convert OMAP2+ to omap_device

Rajendra Nayak (2):
      OMAP3: hwmod: add I2C hwmods for OMAP3430
      OMAP: I2C: Convert i2c driver to use PM runtime api's

Varadarajan, Charulatha (5):
      OMAP3: hwmod data: Add watchdog timer
      OMAP2420: hwmod data: Add watchdog timer
      OMAP2430: hwmod data: Add watchdog timer
      OMAP: WDT: Split OMAP1 and OMAP2PLUS device registration
      OMAP: WDT: Use PM runtime APIs instead of clk FW APIs

 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

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

[Tony Lindgren]

* Kevin Hilman <khilman@deeprootsystems.com> [100928 11:25]:
> 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.

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

Tony

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

[Kevin Hilman]

Rajendra,

Tony Lindgren <tony@atomide.com> writes:

> * Kevin Hilman <khilman@deeprootsystems.com> [100928 11:25]:
>> 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.
>
> 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.

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

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

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Wednesday, September 29, 2010 3:06 AM
> To: Nayak, Rajendra; Tony Lindgren
> Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, Govindraj
> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> 
> Rajendra,
> 
> Tony Lindgren <tony@atomide.com> writes:
> 
> > * Kevin Hilman <khilman@deeprootsystems.com> [100928 11:25]:
> >> 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.
> >
> > 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.
> 
> Rajendra, can you look into this on OMAP2?  This is happening for Tony
> on both n8x0 and 2430sdp.

Sure, I'll have a look.

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

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

<snip>..

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


diff --git a/arch/arm/mach-omap2/cm-regbits-24xx.h b/arch/arm/mach-omap2/cm-regbits-24xx.h
index 5986e2b..9a106c0 100644
--- a/arch/arm/mach-omap2/cm-regbits-24xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-24xx.h
@@ -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
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 8bf46c1..ca4edd3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -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,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 92f4ec0..9498847 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -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,
> 
> >
> > >> 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

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

> -----Original Message-----
> From: Nayak, Rajendra
> Sent: Wednesday, September 29, 2010 9:44 PM
> To: Nayak, Rajendra; Kevin Hilman; Tony Lindgren
> Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, Govindraj
> Subject: RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> 
> <snip>..
> 
> > > > 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?

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 ]---
> 
> 
> diff --git a/arch/arm/mach-omap2/cm-regbits-24xx.h b/arch/arm/mach-omap2/cm-regbits-24xx.h
> index 5986e2b..9a106c0 100644
> --- a/arch/arm/mach-omap2/cm-regbits-24xx.h
> +++ b/arch/arm/mach-omap2/cm-regbits-24xx.h
> @@ -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
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> index 8bf46c1..ca4edd3 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> @@ -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,
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> index 92f4ec0..9498847 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> @@ -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,
> >
> > >
> > > >> 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

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

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

[...]

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

> [    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 ]---
>> 
>> 
>> diff --git a/arch/arm/mach-omap2/cm-regbits-24xx.h b/arch/arm/mach-omap2/cm-regbits-24xx.h
>> index 5986e2b..9a106c0 100644
>> --- a/arch/arm/mach-omap2/cm-regbits-24xx.h
>> +++ b/arch/arm/mach-omap2/cm-regbits-24xx.h
>> @@ -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
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>> index 8bf46c1..ca4edd3 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>> @@ -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,
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>> index 92f4ec0..9498847 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>> @@ -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,
>> >
>> > >
>> > > >> 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

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Thursday, September 30, 2010 12:49 AM
> To: Nayak, Rajendra; Raja, Govindraj
> Cc: Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha
> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> 
> "Nayak, Rajendra" <rnayak@ti.com> writes:
> 
> [...]
> 
> >
> > 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)

> 
> Thanks,
> 
> Kevin
> 
> > [    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 ]---
> >>
> >>
> >> diff --git a/arch/arm/mach-omap2/cm-regbits-24xx.h b/arch/arm/mach-omap2/cm-regbits-24xx.h
> >> index 5986e2b..9a106c0 100644
> >> --- a/arch/arm/mach-omap2/cm-regbits-24xx.h
> >> +++ b/arch/arm/mach-omap2/cm-regbits-24xx.h
> >> @@ -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
> >> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-
> omap2/omap_hwmod_2420_data.c
> >> index 8bf46c1..ca4edd3 100644
> >> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> >> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> >> @@ -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,
> >> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-
> omap2/omap_hwmod_2430_data.c
> >> index 92f4ec0..9498847 100644
> >> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> >> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> >> @@ -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,
> >> >
> >> > >
> >> > > >> 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

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

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> Sent: Thursday, September 30, 2010 12:49 AM
>> To: Nayak, Rajendra; Raja, Govindraj
>> Cc: Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha
>> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
>> 
>> "Nayak, Rajendra" <rnayak@ti.com> writes:
>> 
>> [...]
>> 
>> >
>> > 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)
>

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


diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 92f4ec0..5b61f7c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -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,
-			.idlest_reg_id = 1,
+			.idlest_reg_id = 2,
 			.idlest_idle_bit = OMAP24XX_EN_UART3_SHIFT,
 		},
 	},

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Thursday, September 30, 2010 1:11 AM
> To: Nayak, Rajendra
> Cc: Raja, Govindraj; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha
> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> 
> "Nayak, Rajendra" <rnayak@ti.com> writes:
> 
> >> -----Original Message-----
> >> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> >> Sent: Thursday, September 30, 2010 12:49 AM
> >> To: Nayak, Rajendra; Raja, Govindraj
> >> Cc: Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha
> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> >>
> >> "Nayak, Rajendra" <rnayak@ti.com> writes:
> >>
> >> [...]
> >>
> >> >
> >> > 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)
> >
> 
> 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
> 
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> index 92f4ec0..5b61f7c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> @@ -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,
> -			.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.

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

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

[...]

>> > 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
>> 
>> 
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>> index 92f4ec0..5b61f7c 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>> @@ -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,
>> -			.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.

Thanks for testing Rajendra,

I'll fold this into the UART hwmod data for OMAP2 since that was
originally done by me, not Govindraj.

Kevin

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

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

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

Thanks for digging into this.

[...]

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

Yes please.

Kevin

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

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> * Kevin Hilman <khilman@deeprootsystems.com> [100928 11:25]:
>> 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.
>
> 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

Kevin

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

[Tony Lindgren]

* Kevin Hilman <khilman@deeprootsystems.com> [100929 15:15]:
> Tony Lindgren <tony@atomide.com> writes:
> 
> > * Kevin Hilman <khilman@deeprootsystems.com> [100928 11:25]:
> >> 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.
> >
> > 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.

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:

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

OK, sounds like we may be able to merge this then after the remaining
issues are sorted out.

Tony

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

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [100929 19:10]:
> 
> 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

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?

Regards,

Tony

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Shilimkar, Santosh]

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

> -----Original Message-----
> From: Tony Lindgren [mailto:tony@atomide.com]
> Sent: Thursday, September 30, 2010 8:00 AM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; Nayak, Rajendra;
> Raja, Govindraj; Kevin Hilman
> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions:
> watchdog, UART, i2c
> 
> * Tony Lindgren <tony@atomide.com> [100929 19:10]:
> >
> > 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
> 
> 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?
>
Below is the patch(also attached)which fixes the OMAP1 build issue.
---------
>From c06e887f402ceff03e6c28bb377bcbfe35318719 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
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 <santosh.shilimkar@ti.com>
---
 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

diff --git a/arch/arm/mach-omap1/include/mach/control.h b/arch/arm/mach-omap1/include/mach/control.h
new file mode 100644
index 0000000..c1fd4c0
--- /dev/null
+++ b/arch/arm/mach-omap1/include/mach/control.h
@@ -0,0 +1,3 @@
+/*
+ * arch/arm/mach-omap1/include/mach/control.h
+ */
diff --git a/arch/arm/mach-omap2/include/mach/control.h b/arch/arm/mach-omap2/include/mach/control.h
new file mode 100644
index 0000000..dd41272
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/control.h
@@ -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>
+
diff --git a/arch/arm/plat-omap/include/plat/control.h b/arch/arm/plat-omap/include/plat/control.h
index 19c9b2a..7b047e5 100644
--- a/arch/arm/plat-omap/include/plat/control.h
+++ b/arch/arm/plat-omap/include/plat/control.h
@@ -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)					\
-- 
1.6.0.4

 


[-- Attachment #2: 0001-omap-control-Fix-the-omap1-build-break.patch --]
[-- Type: application/octet-stream, Size: 2442 bytes --]

From c06e887f402ceff03e6c28bb377bcbfe35318719 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
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 <santosh.shilimkar@ti.com>
---
 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

diff --git a/arch/arm/mach-omap1/include/mach/control.h b/arch/arm/mach-omap1/include/mach/control.h
new file mode 100644
index 0000000..c1fd4c0
--- /dev/null
+++ b/arch/arm/mach-omap1/include/mach/control.h
@@ -0,0 +1,3 @@
+/*
+ * arch/arm/mach-omap1/include/mach/control.h
+ */
diff --git a/arch/arm/mach-omap2/include/mach/control.h b/arch/arm/mach-omap2/include/mach/control.h
new file mode 100644
index 0000000..dd41272
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/control.h
@@ -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>
+
diff --git a/arch/arm/plat-omap/include/plat/control.h b/arch/arm/plat-omap/include/plat/control.h
index 19c9b2a..7b047e5 100644
--- a/arch/arm/plat-omap/include/plat/control.h
+++ b/arch/arm/plat-omap/include/plat/control.h
@@ -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)					\
-- 
1.6.0.4

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Paul Walmsley]

On Thu, 30 Sep 2010, Shilimkar, Santosh wrote:

> > -----Original Message-----
> > From: Tony Lindgren [mailto:tony@atomide.com]
> > Sent: Thursday, September 30, 2010 8:00 AM
> > To: Shilimkar, Santosh
> > Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; Nayak, Rajendra;
> > Raja, Govindraj; Kevin Hilman
> > Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions:
> > watchdog, UART, i2c
> > 
> > * Tony Lindgren <tony@atomide.com> [100929 19:10]:
> > >
> > > 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
> > 
> > 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?
> >
> Below is the patch(also attached)which fixes the OMAP1 build issue.
> ---------
> >From c06e887f402ceff03e6c28bb377bcbfe35318719 Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> 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 <santosh.shilimkar@ti.com>
> ---
>  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
> 
> diff --git a/arch/arm/mach-omap1/include/mach/control.h b/arch/arm/mach-omap1/include/mach/control.h
> new file mode 100644
> index 0000000..c1fd4c0
> --- /dev/null
> +++ b/arch/arm/mach-omap1/include/mach/control.h
> @@ -0,0 +1,3 @@
> +/*
> + * arch/arm/mach-omap1/include/mach/control.h
> + */

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

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


> diff --git a/arch/arm/mach-omap2/include/mach/control.h b/arch/arm/mach-omap2/include/mach/control.h
> new file mode 100644
> index 0000000..dd41272
> --- /dev/null
> +++ b/arch/arm/mach-omap2/include/mach/control.h
> @@ -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>
> +
> diff --git a/arch/arm/plat-omap/include/plat/control.h b/arch/arm/plat-omap/include/plat/control.h
> index 19c9b2a..7b047e5 100644
> --- a/arch/arm/plat-omap/include/plat/control.h
> +++ b/arch/arm/plat-omap/include/plat/control.h
> @@ -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)					\
> -- 
> 1.6.0.4
> 
>  
> 
> 


- Paul

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Paul Walmsley]

On Fri, 1 Oct 2010, Paul Walmsley wrote:

> OMAP1 doesn't have a SCM, so this is the wrong fix.  A better approach is 
> here:
> 
> https://patchwork.kernel.org/patch/218992/

Sorry, cut and paste error, should have been

    http://marc.info/?l=linux-omap&m=128596931417802&w=2


thanks to Kevin for letting me know -

- Paul

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

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> * Kevin Hilman <khilman@deeprootsystems.com> [100929 15:15]:
>> Tony Lindgren <tony@atomide.com> writes:
>> 
>> > * Kevin Hilman <khilman@deeprootsystems.com> [100928 11:25]:
>> >> 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.
>> >
>> > 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.
>
> 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 ]---
>

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

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

> Then trying to build for omap1 OSK fails with:

phew, guess I'm off the hook on that one.

Kevin

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

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> Tony Lindgren <tony@atomide.com> writes:
>
>> * Kevin Hilman <khilman@deeprootsystems.com> [100929 15:15]:
>>> Tony Lindgren <tony@atomide.com> writes:
>>> 
>>> > * Kevin Hilman <khilman@deeprootsystems.com> [100928 11:25]:
>>> >> 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.
>>> >
>>> > 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.
>>
>> 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 ]---
>>
>
> 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...

Kevin

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Thursday, September 30, 2010 9:37 PM
> To: Tony Lindgren; Nayak, Rajendra
> Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, Govindraj
> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> 
> Kevin Hilman <khilman@deeprootsystems.com> writes:
> 
> > Kevin Hilman <khilman@deeprootsystems.com> writes:
> >
> >> Tony Lindgren <tony@atomide.com> writes:
> >>
> >>> * Kevin Hilman <khilman@deeprootsystems.com> [100929 15:15]:
> >>>> Tony Lindgren <tony@atomide.com> writes:
> >>>>
> >>>> > * Kevin Hilman <khilman@deeprootsystems.com> [100928 11:25]:
> >>>> >> 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.
> >>>> >
> >>>> > 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.
> >>>
> >>> 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 ]---
> >>>
> >>
> >> 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.

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

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

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

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

[...]

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

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

Happy debugging!   this sounds like a tricky one,

Kevin

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

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> "Nayak, Rajendra" <rnayak@ti.com> writes:
>
> [...]
>
>>> >>
>>> >> 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.

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

Kevin

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

[Tony Lindgren]

* Kevin Hilman <khilman@deeprootsystems.com> [101001 13:38]:
> Kevin Hilman <khilman@deeprootsystems.com> writes:
> 
> > "Nayak, Rajendra" <rnayak@ti.com> writes:
> >
> > [...]
> >
> >>> >>
> >>> >> 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.
> 
> 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

OK, pulling this on top of Paul's control/mcbsp changes.

Looks like some rebasing is needed after I have merged
Paul's changes into omap-for-linus in a few days.

Regards,

Tony

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

[Cousson, Benoit]

On 10/1/2010 3:28 PM, Nayak, Rajendra wrote:
>
>
>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> Sent: Thursday, September 30, 2010 9:37 PM
>> To: Tony Lindgren; Nayak, Rajendra
>> Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, Govindraj
>> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
>>
>> Kevin Hilman<khilman@deeprootsystems.com>  writes:
>>
>>> Kevin Hilman<khilman@deeprootsystems.com>  writes:
>>>
>>>> Tony Lindgren<tony@atomide.com>  writes:
>>>>
>>>>> * Kevin Hilman<khilman@deeprootsystems.com>  [100929 15:15]:
>>>>>> Tony Lindgren<tony@atomide.com>  writes:
>>>>>>
>>>>>>> * Kevin Hilman<khilman@deeprootsystems.com>  [100928 11:25]:
>>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>> 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 ]---
>>>>>
>>>>
>>>> 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.
>
> 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.

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

Regards
Benoit

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

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

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 6376 bytes --]

Hello Benoît, Rajendra, Kevin,

On Fri, 1 Oct 2010, Cousson, Benoit wrote:

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

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

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 <paul@pwsan.com>
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/linux-omap@vger.kernel.org/msg36300.html

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 955861a..fbcfe14 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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 */
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index c1835af..5a1e058 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -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/linux-omap@vger.kernel.org/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

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Tuesday, October 05, 2010 11:32 AM
> To: Cousson, Benoit
> Cc: Nayak, Rajendra; Kevin Hilman; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
> Govindraj
> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> 
> Hello Benoît, Rajendra, Kevin,
> 
> On Fri, 1 Oct 2010, Cousson, Benoit wrote:
> 
> > 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 ?
> 
> > 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 :-)
> 
> 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.
One minor comment of the changelog below..

> 
> 
> - Paul
> 
> From: Paul Walmsley <paul@pwsan.com>
> 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

Maybe it should say 'PRCM deasserts its IdleReq'

> 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/linux-omap@vger.kernel.org/msg36300.html
> 
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Benoît Cousson <b-cousson@ti.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> ---
>  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(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 955861a..fbcfe14 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -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 */
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> index c1835af..5a1e058 100644
> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> @@ -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/linux-omap@vger.kernel.org/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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Paul Walmsley]

Hi Rajendra,

On Tue, 5 Oct 2010, Nayak, Rajendra wrote:

> > -----Original Message-----
> > From: Paul Walmsley [mailto:paul@pwsan.com]
> > 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'

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


- Paul

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5832 bytes --]

On Tue, 5 Oct 2010, Paul Walmsley wrote:

> On Tue, 5 Oct 2010, Nayak, Rajendra wrote:
> 
> > > -----Original Message-----
> > > From: Paul Walmsley [mailto:paul@pwsan.com]
> > > 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'
> 
> Oops, yes, you are right; will fix and repost an updated version.

Here's the update.


- Paul

From: Paul Walmsley <paul@pwsan.com>
Date: Mon, 4 Oct 2010 23:15:23 -0600
Subject: [PATCH] OMAP: hwmod: add configurable device enable delay after PRCM IdleReq 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 IdleReq 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 enable_delay value.

This problem was identified by Kevin Hilman and Rajendra Nayak.
Benoît Cousson identified the solution.  Rajendra Nayak noted a bug
in the patch comments - thanks Rajendra.

1. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36300.html

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 955861a..fbcfe14 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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 */
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index c1835af..3754490 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -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 IdleReq to the
+ * module.  @enable_delay specifies the number of microseconds for the
+ * hwmod code to udelay() between the time that the PRCM deasserts the
+ * IdleReq, 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/linux-omap@vger.kernel.org/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

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

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

<snip>..

> >
> > 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 <rnayak@ti.com>
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 <rnayak@ti.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 955861a..5a30658 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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);
 }
 
 /**
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index c1835af..7eaa8ed 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -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



[-- Attachment #2: 0001-OMAP-hwmod-Handle-modules-with-16bit-registers.patch --]
[-- Type: application/octet-stream, Size: 4614 bytes --]

From af9733f2e63a16b446635d52015e05d631f0788f Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <rnayak@ti.com>
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 <rnayak@ti.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 955861a..5a30658 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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);
 }
 
 /**
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index c1835af..7eaa8ed 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -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

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

> -----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; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, Govindraj
> Subject: RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> 
> <snip>..
> 
> > >
> > > 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.

Sorry, I meant to say __raw_readl/writel instead.

> 
> 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 <rnayak@ti.com>
> 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 <rnayak@ti.com>
> ---
>  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(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 955861a..5a30658 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -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);
>  }
> 
>  /**
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> index c1835af..7eaa8ed 100644
> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> @@ -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
> 

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Paul Walmsley]

On Tue, 5 Oct 2010, Nayak, Rajendra wrote:

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

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 <paul@pwsan.com>


- Paul

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Paul Walmsley]

On Tue, 5 Oct 2010, Paul Walmsley wrote:

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

Unlikely anyone cares too much about this, but just to follow up, this 
appears to be caused by using -march=armv6 or -march=armv7-a on the gcc 
command line.  Dropping the -march or using -march=armv5 avoids the uxt.
That's with arm-linux-gcc (Sourcery G++ Lite 2008q3-72) 4.3.2.  Minimal 
case follows.  This appears to be gcc bug 40893:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40893


- Paul

void foo(unsigned int v)
{
  *(volatile unsigned short *)0xabcdefab = (v);
}

arm-linux-gcc  -O2 -march=armv7-a -c test.c; arm-linux-objdump -DS test.o 
| less


00000000 <foo>:
   0:   e30e3fff        movw    r3, #61439      ; 0xefff
   4:   e34a3bcd        movt    r3, #43981      ; 0xabcd
   8:   e6ff0070        uxth    r0, r0
   c:   e14305b4        strh    r0, [r3, #-84]
  10:   e12fff1e        bx      lr

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Tuesday, October 05, 2010 10:28 PM
> To: Nayak, Rajendra
> Cc: Cousson, Benoit; Kevin Hilman; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
> Govindraj
> Subject: RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> 
> On Tue, 5 Oct 2010, Nayak, Rajendra wrote:
> 
> > 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 <rnayak@ti.com>
> > 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 <rnayak@ti.com>
> 
> Nice work, looks good to me.  Hopefully we won't need that enable_delay
> patch!

Yeah, unless Benoit thinks it's needed for OMAP4 where he's seeing some
issues with FDIF and ISS.

> 
> 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 <paul@pwsan.com>
> 
> 
> - Paul

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

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

> <snip>..
>
>> >
>> > 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 <rnayak@ti.com>
> 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 <rnayak@ti.com>

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

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Tuesday, October 05, 2010 10:34 PM
> To: Nayak, Rajendra
> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
> Govindraj
> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> 
> "Nayak, Rajendra" <rnayak@ti.com> writes:
> 
> > <snip>..
> >
> >> >
> >> > 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 <rnayak@ti.com>
> > 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 <rnayak@ti.com>
> 
> 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?

Regards,
Rajendra

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

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

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> Sent: Tuesday, October 05, 2010 10:34 PM
>> To: Nayak, Rajendra
>> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
>> Govindraj
>> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
>> 
>> "Nayak, Rajendra" <rnayak@ti.com> writes:
>> 
>> > <snip>..
>> >
>> >> >
>> >> > 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 <rnayak@ti.com>
>> > 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 <rnayak@ti.com>
>> 
>> 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.

Thanks,

Kevin

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

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



> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Wednesday, October 06, 2010 1:19 AM
> To: Nayak, Rajendra
> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
> Govindraj
> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> 
> "Nayak, Rajendra" <rnayak@ti.com> writes:
> 
> >> -----Original Message-----
> >> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> >> Sent: Tuesday, October 05, 2010 10:34 PM
> >> To: Nayak, Rajendra
> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
> >> Govindraj
> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> >>
> >> "Nayak, Rajendra" <rnayak@ti.com> writes:
> >>
> >> > <snip>..
> >> >
> >> >> >
> >> >> > 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 <rnayak@ti.com>
> >> > 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 <rnayak@ti.com>
> >>
> >> 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 <rnayak@ti.com>
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 <rnayak@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 25d6da2..c588854 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -263,6 +263,7 @@ static struct omap_hwmod omap2420_i2c1_hwmod = {
 	.class		= &i2c_class,
 	.dev_attr	= &i2c_dev_attr,
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+	.flags		= HWMOD_16BIT_REG,
 };
 
 /* I2C2 */
@@ -301,6 +302,7 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
 	.class		= &i2c_class,
 	.dev_attr	= &i2c_dev_attr,
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+	.flags		= HWMOD_16BIT_REG,
 };
 
 static __initdata struct omap_hwmod *omap2420_hwmods[] = {
-- 
1.7.0.4

> 
> Thanks,
> 
> Kevin

[-- Attachment #2: 0001-OMAP2-hmwod-Fix-impresice-aborts-seen-on-n800-n810.patch --]
[-- Type: application/octet-stream, Size: 1359 bytes --]

From 06b4bb7a0ce96776d6d9b344b4786b48fceeffe1 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <rnayak@ti.com>
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 <rnayak@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 25d6da2..c588854 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -263,6 +263,7 @@ static struct omap_hwmod omap2420_i2c1_hwmod = {
 	.class		= &i2c_class,
 	.dev_attr	= &i2c_dev_attr,
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+	.flags		= HWMOD_16BIT_REG,
 };
 
 /* I2C2 */
@@ -301,6 +302,7 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
 	.class		= &i2c_class,
 	.dev_attr	= &i2c_dev_attr,
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+	.flags		= HWMOD_16BIT_REG,
 };
 
 static __initdata struct omap_hwmod *omap2420_hwmods[] = {
-- 
1.7.0.4

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

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> Sent: Wednesday, October 06, 2010 1:19 AM
>> To: Nayak, Rajendra
>> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
>> Govindraj
>> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
>> 
>> "Nayak, Rajendra" <rnayak@ti.com> writes:
>> 
>> >> -----Original Message-----
>> >> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> >> Sent: Tuesday, October 05, 2010 10:34 PM
>> >> To: Nayak, Rajendra
>> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
>> >> Govindraj
>> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
>> >>
>> >> "Nayak, Rajendra" <rnayak@ti.com> writes:
>> >>
>> >> > <snip>..
>> >> >
>> >> >> >
>> >> >> > 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 <rnayak@ti.com>
>> >> > 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 <rnayak@ti.com>
>> >>
>> >> 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 <rnayak@ti.com>
> 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 <rnayak@ti.com>
> ---
>  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

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Wednesday, October 06, 2010 2:05 AM
> To: Nayak, Rajendra
> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
> Govindraj
> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> 
> "Nayak, Rajendra" <rnayak@ti.com> writes:
> 
> >> -----Original Message-----
> >> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> >> Sent: Wednesday, October 06, 2010 1:19 AM
> >> To: Nayak, Rajendra
> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
> >> Govindraj
> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> >>
> >> "Nayak, Rajendra" <rnayak@ti.com> writes:
> >>
> >> >> -----Original Message-----
> >> >> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> >> >> Sent: Tuesday, October 05, 2010 10:34 PM
> >> >> To: Nayak, Rajendra
> >> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha;
> Raja,
> >> >> Govindraj
> >> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> >> >>
> >> >> "Nayak, Rajendra" <rnayak@ti.com> writes:
> >> >>
> >> >> > <snip>..
> >> >> >
> >> >> >> >
> >> >> >> > 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 <rnayak@ti.com>
> >> >> > 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 <rnayak@ti.com>
> >> >>
> >> >> 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 <rnayak@ti.com>
> > 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 <rnayak@ti.com>
> > ---
> >  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?

Yeah, actually i2c modules on all OMAPs including OMAP4 have had 16 bit registers.
But somehow only 2420 seemed to cause issues.
That's why I mentioned modules with 'hard requirement' :-)
Maybe I'll post a patch adding this for all i2c's across OMAP's? 

> 
> Kevin

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

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> Sent: Wednesday, October 06, 2010 2:05 AM
>> To: Nayak, Rajendra
>> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
>> Govindraj
>> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
>> 
>> "Nayak, Rajendra" <rnayak@ti.com> writes:
>> 
>> >> -----Original Message-----
>> >> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> >> Sent: Wednesday, October 06, 2010 1:19 AM
>> >> To: Nayak, Rajendra
>> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
>> >> Govindraj
>> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
>> >>
>> >> "Nayak, Rajendra" <rnayak@ti.com> writes:
>> >>
>> >> >> -----Original Message-----
>> >> >> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> >> >> Sent: Tuesday, October 05, 2010 10:34 PM
>> >> >> To: Nayak, Rajendra
>> >> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha;
>> Raja,
>> >> >> Govindraj
>> >> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
>> >> >>
>> >> >> "Nayak, Rajendra" <rnayak@ti.com> writes:
>> >> >>
>> >> >> > <snip>..
>> >> >> >
>> >> >> >> >
>> >> >> >> > 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 <rnayak@ti.com>
>> >> >> > 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 <rnayak@ti.com>
>> >> >>
>> >> >> 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 <rnayak@ti.com>
>> > 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 <rnayak@ti.com>
>> > ---
>> >  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?
>
> 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

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Nayak, Rajendra]

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Wednesday, October 06, 2010 2:14 AM
> To: Nayak, Rajendra
> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
> Govindraj
> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> 
> "Nayak, Rajendra" <rnayak@ti.com> writes:
> 
> >> -----Original Message-----
> >> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> >> Sent: Wednesday, October 06, 2010 2:05 AM
> >> To: Nayak, Rajendra
> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja,
> >> Govindraj
> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> >>
> >> "Nayak, Rajendra" <rnayak@ti.com> writes:
> >>
> >> >> -----Original Message-----
> >> >> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> >> >> Sent: Wednesday, October 06, 2010 1:19 AM
> >> >> To: Nayak, Rajendra
> >> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha;
> Raja,
> >> >> Govindraj
> >> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> >> >>
> >> >> "Nayak, Rajendra" <rnayak@ti.com> writes:
> >> >>
> >> >> >> -----Original Message-----
> >> >> >> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> >> >> >> Sent: Tuesday, October 05, 2010 10:34 PM
> >> >> >> To: Nayak, Rajendra
> >> >> >> Cc: Paul Walmsley; Cousson, Benoit; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha;
> >> Raja,
> >> >> >> Govindraj
> >> >> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> >> >> >>
> >> >> >> "Nayak, Rajendra" <rnayak@ti.com> writes:
> >> >> >>
> >> >> >> > <snip>..
> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > 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 <rnayak@ti.com>
> >> >> >> > 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 <rnayak@ti.com>
> >> >> >>
> >> >> >> 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 <rnayak@ti.com>
> >> > 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 <rnayak@ti.com>
> >> > ---
> >> >  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?
> >
> > 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,

Ok, thanks.

> 
> Thanks,
> 
> Kevin

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

[Cousson, Benoit]

Hi Paul,

On 10/5/2010 8:01 AM, Paul Walmsley wrote:
> Hello Benoît, Rajendra, Kevin,
>
> On Fri, 1 Oct 2010, Cousson, Benoit wrote:
>
>> 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 ?

In theory yes :-(

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

I'll try it on OMAP4.

Thanks,
Benoit

>
>
> - Paul
>
> From: Paul Walmsley<paul@pwsan.com>
> 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/linux-omap@vger.kernel.org/msg36300.html
>
> Signed-off-by: Paul Walmsley<paul@pwsan.com>
> Cc: Benoît Cousson<b-cousson@ti.com>
> Cc: Rajendra Nayak<rnayak@ti.com>
> Cc: Kevin Hilman<khilman@deeprootsystems.com>
> ---
>   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(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 955861a..fbcfe14 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -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 */
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> index c1835af..5a1e058 100644
> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> @@ -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/linux-omap@vger.kernel.org/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;

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

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

[Tony Lindgren]

* Kevin Hilman <khilman@deeprootsystems.com> [100930 07:31]:
> 
> 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. :(

I guess the options there are to leave out tons of boards and some other
omaps, or to use kexec to get around that limit.

Regards,

Tony

RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c

[Varadarajan, Charulatha]

Kevin,

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Tuesday, September 28, 2010 11:55 PM
> To: linux-omap@vger.kernel.org
> 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.

Minor observations as mentioned below.

> 
> Kevin
> 
> 
> The following changes since commit
> b6a26b4b87d7b030a546e7bdaf390ffc58323f36:

<<snip>>

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

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

>  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

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

[Kevin Hilman]

"Varadarajan, Charulatha" <charu@ti.com> writes:

> Kevin,
>
>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> Sent: Tuesday, September 28, 2010 11:55 PM
>> To: linux-omap@vger.kernel.org
>> 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.
>
> Minor observations as mentioned below.

Charu, thanks for the review.  

I need to look at this closer.  

Rather than me trying to solve this with a manual merge, I may have to
request the various authors to rebase.

Kevin

>> 
>> Kevin
>> 
>> 
>> The following changes since commit
>> b6a26b4b87d7b030a546e7bdaf390ffc58323f36:
>
> <<snip>>
>
>> 
>>  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
>
>>  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.
>
>>  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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html