summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
diff options
context:
space:
mode:
authorPaul Walmsley <paul@pwsan.com>2012-06-27 14:53:46 -0600
committerPaul Walmsley <paul@pwsan.com>2012-06-27 14:53:46 -0600
commit82ee620dc6e1906fe064e93047489f0aea72b75b (patch)
tree22da8bc3941b9b82be61eebf0161f1f3771a05ac /arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
parentbf7652372777c3a6003a05a3e9e462c3dcd0c90d (diff)
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>
Diffstat (limited to 'arch/arm/mach-omap2/omap_hwmod_3xxx_data.c')
-rw-r--r--arch/arm/mach-omap2/omap_hwmod_3xxx_data.c17
1 files changed, 17 insertions, 0 deletions
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 2f4889e514e5..1120d388eca3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -536,6 +536,20 @@ static struct omap_hwmod_dma_info am35xx_uart4_sdma_reqs[] = {
{ .dma_req = -1 }
};
+/*
+ * XXX AM35xx UART4 cannot complete its softreset without uart1_fck or
+ * uart2_fck being enabled. So we add uart1_fck as an optional clock,
+ * below, and set the HWMOD_CONTROL_OPT_CLKS_IN_RESET. This really
+ * should not be needed. The functional clock structure of the AM35xx
+ * UART4 is extremely unclear and opaque; it is unclear what the role
+ * of uart1/2_fck is for the UART4. Any clarification from either
+ * empirical testing or the AM3505/3517 hardware designers would be
+ * most welcome.
+ */
+static struct omap_hwmod_opt_clk am35xx_uart4_opt_clks[] = {
+ { .role = "softreset_uart1_fck", .clk = "uart1_fck" },
+};
+
static struct omap_hwmod am35xx_uart4_hwmod = {
.name = "uart4",
.mpu_irqs = am35xx_uart4_mpu_irqs,
@@ -550,6 +564,9 @@ static struct omap_hwmod am35xx_uart4_hwmod = {
.idlest_idle_bit = AM35XX_ST_UART4_SHIFT,
},
},
+ .opt_clks = am35xx_uart4_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(am35xx_uart4_opt_clks),
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.class = &omap2_uart_class,
};