ARM: OMAP: AM35xx: fix UART4 softreset
authorPaul Walmsley <paul@pwsan.com>
Wed, 27 Jun 2012 20:53:46 +0000 (14:53 -0600)
committerPaul Walmsley <paul@pwsan.com>
Wed, 27 Jun 2012 20:53:46 +0000 (14:53 -0600)
commit82ee620dc6e1906fe064e93047489f0aea72b75b
tree22da8bc3941b9b82be61eebf0161f1f3771a05ac
parentbf7652372777c3a6003a05a3e9e462c3dcd0c90d
ARM: OMAP: AM35xx: fix UART4 softreset

During kernel init, the AM3505/AM3517 UART4 cannot complete its softreset:

omap_hwmod: uart4: softreset failed (waited 10000 usec)

This also results in another warning later in the boot process:

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

From empirical observation, the AM35xx UART4 IP block requires either
uart1_fck or uart2_fck to be enabled while UART4 resets.  Otherwise
the reset will never complete.  So this patch adds uart1_fck as an
optional clock for UART4 and adds the appropriate hwmod flag to cause
uart1_fck to be enabled during the reset process.  (The choice of
uart1_fck over uart2_fck was arbitrary.)

Unfortunately this observation raises many questions.  Is it necessary
for uart1_fck or uart2_fck to be controlled with uart4_fck for the
UART4 to work correctly?  What exactly do the AM35xx UART4 clock
tree and the related PRCM idle management FSMs look like?  If anyone
has the ability to answer these questions through empirical functional
testing, or hardware information from the AM35xx designers, it would
be greatly appreciated.

Cc: BenoƮt Cousson <b-cousson@ti.com>
Cc: Kyle Manna <kyle.manna@fuel7.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Mark A. Greer <mgreer@animalcreek.com>
arch/arm/mach-omap2/clock3xxx_data.c
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c