ARM: OMAP: AM35xx: fix some boot warnings with AM3505/3517

Partially fix the hwmod data for the AM35xx USB OTG hwmod. This should resolve the following boot warning on AM35xx platforms:

omap_hwmod: am35x_otg_hs: cannot be enabled for reset (3)

While here, also fix the clkdev records, to avoid warnings about duplicate clock aliases.

The hwmod is also connected to the wrong interconnect. It should be connected to the IPSS, not the L4 CORE. But that is left for a future fix, since it probably has a dependency on some hwmod core changes.

Cc Felipe Balbi <[email protected]>

Cc Hema HK <[email protected]>

Cc Mark A. Greer <[email protected]>

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

Add missing terminators to the arrays of IRQ, DMA, and address space structure records in the AM35xx UART4 hwmod data. Without these terminators, the following warnings appear on boot:

omap_uart.3: failed to claim resource 58
omap_device: omap_uart: build failed (-16)

WARNING: at /home/paul/linux/arch/arm/mach-omap2/serial.c:375 omap_serial_init_port+0x198/0x284()

Could not build omap_device for omap_uart: uart4.

Also, AM35xx uart4_fck has an incorrect parent clock pointer. Fix it and clean up a whitespace issue.

Fix some incorrectly-named macros related to AM35xx UART4.

Cc Kyle Manna <[email protected]>

Cc Mark A. Greer <[email protected]>

Cc Ranjith Lohithakshan <[email protected]>

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

From empirical observation, the AM35xx UART4 IP block requires either

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

Quoted 1 line

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 <[email protected]>

Cc Kyle Manna <[email protected]>

Cc Mark A. Greer <[email protected]>

Cc Ranjith Lohithakshan <[email protected]>

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

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

Quoted 1 line

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<[email protected]>

Cc Kyle Manna<[email protected]>

Cc Mark A. Greer<[email protected]>

Cc Ranjith Lohithakshan<[email protected]>

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

---
  arch/arm/mach-omap2/clock3xxx_data.c       |    8 ++++++--
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   17 +++++++++++++++++
  2 files changed, 23 insertions(+), 2 deletions(-)

arch/arm/mach-omap2/clock3xxx_data.c +6 -2

index 11644bf..12c64db 100644
@@ -3201,8 +3201,12 @@ static struct clk vpfe_fck = {
  };
 
  /*
- * The UART1/2 functional clock acts as the functional
- * clock for UART4. No separate fclk control available.
+ * The UART1/2 functional clock acts as the functional clock for
+ * UART4. No separate fclk control available.  XXX Well now we have a
+ * uart4_fck that is apparently used as the UART4 functional clock,
+ * but it also seems that uart1_fck or uart2_fck are still needed, at
+ * least for UART4 softresets to complete.  This really needs
+ * clarification.
   */
  static struct clk uart4_ick_am35xx = {
  	.name		= "uart4_ick",

arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +17 -0

index c939131..c6653a80 100644
@@ -535,6 +535,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,

@@ -549,6 +563,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,
  };
 

I do not have any clue about that chip, but is this clock really what it is supposed to be? I mean, isn't the uart1_fck the parent of all the UART fck or something like that. Don't we just have an issue becasue the clock names are not accurate?

Hi Beno?t

Quoted 4 lines · Benoit

I do not have any clue about that chip, but is this clock really what it is supposed to be? I mean, isn't the uart1_fck the parent of all the UART fck or something like that. Don't we just have an issue becasue the clock names are not accurate?

I guess that's what I'm trying to find out.

According to the AM3517 TRM rev. B (SPRUGR0B) Figure 14-20 "UART Functional Integration" and Table 14-11 "UART Clocks", all of the UARTs appear to have independent functional clocks. The table even mentions a CM_FCLKEN1_CORE.EN_UART4 bit. But the PRCM chapter of this TRM doesn't mention that at all. So the documentation is not too useful here.

On the rest of the OMAPs, as far as I know, the UART clocks are all separate.

Quoted 2 lines · Paul Walmsley

On the rest of the OMAPs, as far as I know, the UART clocks are all separate.

In fact, not really. The same PER_48M_GFCLK clock is used for every UART instances in OMAP4. We do have a separate modulemode for each UART but as far as clocks are concerned, the source clock is the same.

Quoted 5 lines · Benoit

Quoted 2 lines · Paul Walmsley

On the rest of the OMAPs, as far as I know, the UART clocks are all separate.

Quoted 3 lines

In fact, not really. The same PER_48M_GFCLK clock is used for every UART instances in OMAP4. We do have a separate modulemode for each UART but as far as clocks are concerned, the source clock is the same.

By "separate" I mean that they are all independently gated. This does not appear to be the case with AM3517. Or perhaps it is the case and something isn't right with the idle management FSMs.

But they are not separately gated for OMAP4 either. This is the modulemode trick that make us think that, but it just means that the PRCM should ensure that this clock is needed when at least one UART modulemode is enabled. In fact the SPI modules are using the same clock.

The modulemode is used to do some reference counting, but the gating is done globally. It was the same with the FCK_EN and ICK_EN in OMAP2&3.

The PRCM spec show only one global gating between FUNC_48M_FCLK and PER_48M_GFCLK. All the modules are sharing the exact same clock.

Hello,

this series fixes some of the warnings observed at boot with the AM35xx boards. Intended for either the 3.5 or 3.5-rc merge windows.

Particularly appreciated would be some feedback on the "ARM: OMAP:
AM35xx: fix UART4 softreset" patch from people who know the AM35xx SoC hardware.

Quoted 8 lines · Paul Walmsley

Hello,

this series fixes some of the warnings observed at boot with the AM35xx boards. Intended for either the 3.5 or 3.5-rc merge windows.

Particularly appreciated would be some feedback on the "ARM: OMAP:
AM35xx: fix UART4 softreset" patch from people who know the AM35xx SoC hardware.

What repo/branch are these patches based on?