Add support for DM_USB for TI's DRA7 EVMs and AM57 EVMs platforms

syscon_regmap_lookup_by_phandle() can be used to get the regmap of a

device from a reference in the DTS. It operates similarly to the linux version of the namesake function.

Signed-off-by Jean-Jacques Hiblot <[email protected]>

---

Changes in v5: None
Changes in v4:
- Fix word missing in commit log

Changes in v3:
- in syscon_regmap_lookup_by_phandle(), use dev_dbg() instead of printf()
- added unit test for syscon_regmap_lookup_by_phandle()

Changes in v2: None

 arch/sandbox/dts/test.dts    |  6 ++++--
 drivers/core/syscon-uclass.c | 23 +++++++++++++++++++++++
 include/syscon.h             | 13 +++++++++++++
 test/dm/syscon.c             | 29 +++++++++++++++++++++++++++++
 4 files changed, 69 insertions(+), 2 deletions(-)

This drivers supports the USB2 PHY found on omap5 and dra7 SOCs.

Signed-off-by Jean-Jacques Hiblot <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- omap-usb2-phy: Implement power_on and power_off callbacks

 drivers/phy/Kconfig         |   8 ++
 drivers/phy/Makefile        |   1 +
 drivers/phy/omap-usb2-phy.c | 196 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 205 insertions(+)
 create mode 100644 drivers/phy/omap-usb2-phy.c

drivers/phy/Kconfig +0 -0

index 119edec..ed2b0a8 100644

+DECLARE_GLOBAL_DATA_PTR;

drivers/phy/Kconfig +15 -0

+		/*
+		 *
+		 * Reduce the sensitivity of internal PHY by enabling the
+		 * DISCON_BYP_LATCH of the USB2PHY_ANA_CONFIG1 register. This
+		 * resolves issues with certain devices which can otherwise
+		 * be prone to false disconnects.
+		 *
+		 */
+		val = readl(priv->phy_base + USB2PHY_ANA_CONFIG1);
+		val |= USB2PHY_DISCON_BYP_LATCH;
+		writel(val, priv->phy_base + USB2PHY_ANA_CONFIG1);
+	}
+
+	return 0;
+}

For USB ports that use the Driver Model, turn on the clocks during the late init stage.

Signed-off-by Jean-Jacques Hiblot <[email protected]>

Reviewed-by Tom Rini <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 board/ti/dra7xx/evm.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

board/ti/dra7xx/evm.c +13 -0

index 06f061c..c1e1b8e 100644
@@ -647,6 +647,19 @@ int dram_init_banksize(void)
 	return 0;
 }
 
+#if CONFIG_IS_ENABLED(DM_USB) && CONFIG_IS_ENABLED(OF_CONTROL)
+static int device_okay(const char *path)
+{
+	int node;
+
+	node = fdt_path_offset(gd->fdt_blob, path);
+	if (node < 0)
+		return 0;
+
+	return fdtdec_get_is_enabled(gd->fdt_blob, node);
+}
+#endif
+
 int board_late_init(void)
 {
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG

Quoted 42 lines · Jean-Jacques Hiblot

For USB ports that use the Driver Model, turn on the clocks during the late init stage.

Signed-off-by Jean-Jacques Hiblot <[email protected]>

Reviewed-by Tom Rini <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  board/ti/dra7xx/evm.c | 19 +++++++++++++++++++
  1 file changed, 19 insertions(+)

board/ti/dra7xx/evm.c +13 -0

index 06f061c..c1e1b8e 100644
@@ -647,6 +647,19 @@ int dram_init_banksize(void)
  	return 0;
  }
 
+#if CONFIG_IS_ENABLED(DM_USB) && CONFIG_IS_ENABLED(OF_CONTROL)
+static int device_okay(const char *path)
+{
+	int node;
+
+	node = fdt_path_offset(gd->fdt_blob, path);
+	if (node < 0)
+		return 0;
+
+	return fdtdec_get_is_enabled(gd->fdt_blob, node);
+}
+#endif
+
  int board_late_init(void)
  {
  #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG

@@ -686,6 +699,12 @@ int board_late_init(void)
  	if (board_is_dra71x_evm())
  		palmas_i2c_write_u8(LP873X_I2C_SLAVE_ADDR, 0x9, 0x7);

board/ti/dra7xx/evm.c int board_late_init(void) · line 707

Quoted 7 lines

board/ti/dra7xx/evm.c +6 -0

  #endif
+#if CONFIG_IS_ENABLED(DM_USB) && CONFIG_IS_ENABLED(OF_CONTROL)
+	if (device_okay("/ocp/omap_dwc3_1 at 48880000"))
+		enable_usb_clocks(0);
+	if (device_okay("/ocp/omap_dwc3_2 at 488c0000"))
+		enable_usb_clocks(1);
+#endif

Shouldnt the driver turn this on?

Quoted 42 lines · Marek Vasut

Quoted 41 lines · Jean-Jacques Hiblot

For USB ports that use the Driver Model, turn on the clocks during the late init stage.

Signed-off-by Jean-Jacques Hiblot <[email protected]>

Reviewed-by Tom Rini <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  board/ti/dra7xx/evm.c | 19 +++++++++++++++++++

  1 file changed, 19 insertions(+)

board/ti/dra7xx/evm.c +12 -0

index 06f061c..c1e1b8e 100644
@@ -647,6 +647,19 @@ int dram_init_banksize(void)
       return 0;
   }
   +#if CONFIG_IS_ENABLED(DM_USB) && CONFIG_IS_ENABLED(OF_CONTROL)
+static int device_okay(const char *path)
+{
+    int node;
+
+    node = fdt_path_offset(gd->fdt_blob, path);
+    if (node < 0)
+        return 0;
+
+    return fdtdec_get_is_enabled(gd->fdt_blob, node);
+}
+#endif
+
   int board_late_init(void)
   {
   #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG

@@ -686,6 +699,12 @@ int board_late_init(void)
       if (board_is_dra71x_evm())
           palmas_i2c_write_u8(LP873X_I2C_SLAVE_ADDR, 0x9, 0x7);

Quoted 8 lines

board/ti/dra7xx/evm.c int board_late_init(void) · line 707

Quoted 7 lines

board/ti/dra7xx/evm.c +6 -0

   #endif
+#if CONFIG_IS_ENABLED(DM_USB) && CONFIG_IS_ENABLED(OF_CONTROL)
+    if (device_okay("/ocp/omap_dwc3_1 at 48880000"))
+        enable_usb_clocks(0);
+    if (device_okay("/ocp/omap_dwc3_2 at 488c0000"))
+        enable_usb_clocks(1);
+#endif

Shouldnt the driver turn this on?

AFAIK there is no clock driver for the OMAP. So we have to do it before the driver is probed.

Quoted 52 lines · Jean-Jacques Hiblot

Quoted 50 lines · Marek Vasut

Quoted 39 lines · Jean-Jacques Hiblot

For USB ports that use the Driver Model, turn on the clocks during the late init stage.

Signed-off-by Jean-Jacques Hiblot <[email protected]>

Reviewed-by Tom Rini <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

   board/ti/dra7xx/evm.c | 19 +++++++++++++++++++
   1 file changed, 19 insertions(+)

board/ti/dra7xx/evm.c +12 -0

index 06f061c..c1e1b8e 100644
@@ -647,6 +647,19 @@ int dram_init_banksize(void)
       return 0;
   }
   +#if CONFIG_IS_ENABLED(DM_USB) && CONFIG_IS_ENABLED(OF_CONTROL)
+static int device_okay(const char *path)
+{
+    int node;
+
+    node = fdt_path_offset(gd->fdt_blob, path);
+    if (node < 0)
+        return 0;
+
+    return fdtdec_get_is_enabled(gd->fdt_blob, node);
+}
+#endif
+
   int board_late_init(void)
   {
   #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG

board/ti/dra7xx/evm.c int board_late_init(void) · line 707

Quoted 9 lines

board/ti/dra7xx/evm.c +6 -0

@@ -686,6 +699,12 @@ int board_late_init(void)
       if (board_is_dra71x_evm())
           palmas_i2c_write_u8(LP873X_I2C_SLAVE_ADDR, 0x9, 0x7);
   #endif
+#if CONFIG_IS_ENABLED(DM_USB) && CONFIG_IS_ENABLED(OF_CONTROL)
+    if (device_okay("/ocp/omap_dwc3_1 at 48880000"))
+        enable_usb_clocks(0);
+    if (device_okay("/ocp/omap_dwc3_2 at 488c0000"))
+        enable_usb_clocks(1);
+#endif

Shouldnt the driver turn this on?

Quoted 2 lines

AFAIK there is no clock driver for the OMAP. So we have to do it before the driver is probed.

Maybe it's time to implement it instead of piling up those hacks ?

Quoted 53 lines · Marek Vasut

Quoted 52 lines · Jean-Jacques Hiblot

Quoted 50 lines · Marek Vasut

Quoted 39 lines · Jean-Jacques Hiblot

For USB ports that use the Driver Model, turn on the clocks during the late init stage.

Signed-off-by Jean-Jacques Hiblot <[email protected]>

Reviewed-by Tom Rini <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

   board/ti/dra7xx/evm.c | 19 +++++++++++++++++++

   1 file changed, 19 insertions(+)

board/ti/dra7xx/evm.c +12 -0

index 06f061c..c1e1b8e 100644
@@ -647,6 +647,19 @@ int dram_init_banksize(void)
        return 0;
    }
    +#if CONFIG_IS_ENABLED(DM_USB) && CONFIG_IS_ENABLED(OF_CONTROL)
+static int device_okay(const char *path)
+{
+    int node;
+
+    node = fdt_path_offset(gd->fdt_blob, path);
+    if (node < 0)
+        return 0;
+
+    return fdtdec_get_is_enabled(gd->fdt_blob, node);
+}
+#endif
+
    int board_late_init(void)
    {
    #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG

board/ti/dra7xx/evm.c int board_late_init(void) · line 707

Quoted 9 lines

board/ti/dra7xx/evm.c +6 -0

@@ -686,6 +699,12 @@ int board_late_init(void)
        if (board_is_dra71x_evm())
            palmas_i2c_write_u8(LP873X_I2C_SLAVE_ADDR, 0x9, 0x7);
    #endif
+#if CONFIG_IS_ENABLED(DM_USB) && CONFIG_IS_ENABLED(OF_CONTROL)
+    if (device_okay("/ocp/omap_dwc3_1 at 48880000"))
+        enable_usb_clocks(0);
+    if (device_okay("/ocp/omap_dwc3_2 at 488c0000"))
+        enable_usb_clocks(1);
+#endif

Shouldnt the driver turn this on?

Quoted 3 lines

Quoted 2 lines

AFAIK there is no clock driver for the OMAP. So we have to do it before the driver is probed.

Maybe it's time to implement it instead of piling up those hacks ?

I was thinking along the same lines at some point but then I realized that it will make the SPL really big. And we are already tight on some platforms like am335x.

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

Shouldnt the driver turn this on?

AFAIK there is no clock driver for the OMAP. So we have to do it before the driver is probed.

Maybe it's time to implement it instead of piling up those hacks ?

I was thinking along the same lines at some point but then I realized that it will make the SPL really big. And we are already tight on some platforms like am335x.

But this is not only SPL , right ? And yes, for SPL you might need to poke registers or something.

Hi Marek,

Quoted 11 lines · Marek Vasut

Quoted 9 lines

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

Shouldnt the driver turn this on?

AFAIK there is no clock driver for the OMAP. So we have to do it before
the driver is probed.

Maybe it's time to implement it instead of piling up those hacks ?

I was thinking along the same lines at some point but then I realized that it will make the SPL really big. And we are already tight on some platforms like am335x.

But this is not only SPL , right ? And yes, for SPL you might need to poke registers or something.

IMHO having 2 different ways to enable the clocks in SPL and in u-boot is an not improvement over the current situation.
In any case, This is a subject that can be discussed.

Tom, Lokesh,  do you have an opinion on this ?

Meanwhile It would nice to have DM_USB support for the DRA7/AM57 platforms. It allows using a USB ether adapter with CONFIG_DM_ETHER enabled (default on TI's platform). And this series allows using the USB 3.0 on AM57 evm.

JJ

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Hi Marek,

Quoted 9 lines · Marek Vasut

Quoted 9 lines

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

Shouldnt the driver turn this on?

AFAIK there is no clock driver for the OMAP. So we have to do it before
the driver is probed.

Maybe it's time to implement it instead of piling up those hacks ?

I was thinking along the same lines at some point but then I realized that it will make the SPL really big. And we are already tight on some platforms like am335x.

Quoted 2 lines

But this is not only SPL , right ? And yes, for SPL you might need to poke registers or something.

IMHO having 2 different ways to enable the clocks in SPL and in u-boot is an not improvement over the current situation.
In any case, This is a subject that can be discussed.

Tom, Lokesh,  do you have an opinion on this ?

Meanwhile It would nice to have DM_USB support for the DRA7/AM57 platforms. It allows using a USB ether adapter with CONFIG_DM_ETHER enabled (default on TI's platform). And this series allows using the USB 3.0 on AM57 evm.

JJ

Quoted 12 lines · Jean-Jacques Hiblot

Hi Marek,

Quoted 8 lines · Marek Vasut

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Shouldnt the driver turn this on?

AFAIK there is no clock driver for the OMAP. So we have to do it before
the driver is probed.

Maybe it's time to implement it instead of piling up those hacks ?

I was thinking along the same lines at some point but then I realized that it will make the SPL really big. And we are already tight on some platforms like am335x.

Quoted 5 lines

Quoted 2 lines

But this is not only SPL , right ? And yes, for SPL you might need to poke registers or something.

IMHO having 2 different ways to enable the clocks in SPL and in u-boot is an not improvement over the current situation.
In any case, This is a subject that can be discussed.

Do you have a better idea ?

Quoted 12 lines

Tom, Lokesh,  do you have an opinion on this ?

Meanwhile It would nice to have DM_USB support for the DRA7/AM57 platforms. It allows using a USB ether adapter with CONFIG_DM_ETHER enabled (default on TI's platform). And this series allows using the USB 3.0 on AM57 evm.

JJ

Quoted 13 lines · Marek Vasut

Quoted 12 lines · Jean-Jacques Hiblot

Hi Marek,

Quoted 8 lines · Marek Vasut

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Shouldnt the driver turn this on?

AFAIK there is no clock driver for the OMAP. So we have to do it before
the driver is probed.

Maybe it's time to implement it instead of piling up those hacks ?

I was thinking along the same lines at some point but then I realized that it will make the SPL really big. And we are already tight on some platforms like am335x.

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

But this is not only SPL , right ? And yes, for SPL you might need to poke registers or something.

IMHO having 2 different ways to enable the clocks in SPL and in u-boot is an not improvement over the current situation.
In any case, This is a subject that can be discussed.

Do you have a better idea ?

I would keep it as it is today.

After studying the clock management in Linux, I believe that implementing the clock drivers in u-boot won't be an easy task and moreover won't make things much cleaner.
The way clocks are handled in Linux for the omap platforms is not completely standard. There are a lot of clocks that are handled by the clock framework (pll, mux, some gates, ...) but most of the clock gating for peripherals is handled the HWMOD subsystem which automatically enables/disables the clocks of the peripherals. Parameters for this subsystem are hard-coded in platform code (in arch/arm/mach-omap2/omap-hwmod_xxx_data.c) not in the DTS. It also handle clock and power domains.
HWMOD is probably going to go away some day, I'm not sure that we want to implement it in u-boot. Until hwmod has completely replaced by more generic frameworks, I would stick to platform code to enable clocks in u-boot.

Quoted 23 lines · Jean-Jacques Hiblot

Quoted 13 lines · Marek Vasut

Quoted 12 lines · Jean-Jacques Hiblot

Hi Marek,

Quoted 8 lines · Marek Vasut

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Shouldnt the driver turn this on?

AFAIK there is no clock driver for the OMAP. So we have to do it before
the driver is probed.

Maybe it's time to implement it instead of piling up those hacks ?

I was thinking along the same lines at some point but then I realized that it will make the SPL really big. And we are already tight on some platforms like am335x.

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

But this is not only SPL , right ? And yes, for SPL you might need to poke registers or something.

IMHO having 2 different ways to enable the clocks in SPL and in u-boot is an not improvement over the current situation.
In any case, This is a subject that can be discussed.

Do you have a better idea ?

I would keep it as it is today.

Quoted 15 lines

After studying the clock management in Linux, I believe that implementing the clock drivers in u-boot won't be an easy task and moreover won't make things much cleaner.
The way clocks are handled in Linux for the omap platforms is not completely standard. There are a lot of clocks that are handled by the clock framework (pll, mux, some gates, ...) but most of the clock gating for peripherals is handled the HWMOD subsystem which automatically enables/disables the clocks of the peripherals. Parameters for this subsystem are hard-coded in platform code (in arch/arm/mach-omap2/omap-hwmod_xxx_data.c) not in the DTS. It also handle clock and power domains.
HWMOD is probably going to go away some day, I'm not sure that we want to implement it in u-boot. Until hwmod has completely replaced by more generic frameworks, I would stick to platform code to enable clocks in u-boot.

But if this keeps going on, eventually we will regress to where we were years ago -- having huge platform specific list of registers to poke to set a platform up and that'd be it ?

Quoted 24 lines · Jean-Jacques Hiblot

Quoted 13 lines · Marek Vasut

Quoted 12 lines · Jean-Jacques Hiblot

Hi Marek,

Quoted 8 lines · Marek Vasut

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Shouldnt the driver turn this on?

AFAIK there is no clock driver for the OMAP. So we have to do it before
the driver is probed.

Maybe it's time to implement it instead of piling up those hacks ?

I was thinking along the same lines at some point but then I realized that it will make the SPL really big. And we are already tight on some platforms like am335x.

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

But this is not only SPL , right ? And yes, for SPL you might need to poke registers or something.

IMHO having 2 different ways to enable the clocks in SPL and in u-boot is an not improvement over the current situation.
In any case, This is a subject that can be discussed.

Do you have a better idea ?

I would keep it as it is today.

Quoted 15 lines

After studying the clock management in Linux, I believe that implementing the clock drivers in u-boot won't be an easy task and moreover won't make things much cleaner.
The way clocks are handled in Linux for the omap platforms is not completely standard. There are a lot of clocks that are handled by the clock framework (pll, mux, some gates, ...) but most of the clock gating for peripherals is handled the HWMOD subsystem which automatically enables/disables the clocks of the peripherals. Parameters for this subsystem are hard-coded in platform code (in arch/arm/mach-omap2/omap-hwmod_xxx_data.c) not in the DTS. It also handle clock and power domains.
HWMOD is probably going to go away some day, I'm not sure that we want to implement it in u-boot. Until hwmod has completely replaced by more generic frameworks, I would stick to platform code to enable clocks in u-boot.

But if this keeps going on, eventually we will regress to where we were years ago -- having huge platform specific list of registers to poke to set a platform up and that'd be it ?

Quoted 39 lines · Marek Vasut

Quoted 38 lines · Jean-Jacques Hiblot

Quoted 13 lines · Marek Vasut

Quoted 12 lines · Jean-Jacques Hiblot

Hi Marek,

Quoted 8 lines · Marek Vasut

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Shouldnt the driver turn this on?

AFAIK there is no clock driver for the OMAP. So we have to do it before
the driver is probed.

Maybe it's time to implement it instead of piling up those hacks ?

I was thinking along the same lines at some point but then I realized that it will make the SPL really big. And we are already tight on some platforms like am335x.

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

But this is not only SPL , right ? And yes, for SPL you might need to poke registers or something.

IMHO having 2 different ways to enable the clocks in SPL and in u-boot is an not improvement over the current situation.
In any case, This is a subject that can be discussed.

Do you have a better idea ?

I would keep it as it is today.

After studying the clock management in Linux, I believe that implementing the clock drivers in u-boot won't be an easy task and moreover won't make things much cleaner.
The way clocks are handled in Linux for the omap platforms is not completely standard. There are a lot of clocks that are handled by the clock framework (pll, mux, some gates, ...) but most of the clock gating for peripherals is handled the HWMOD subsystem which automatically enables/disables the clocks of the peripherals. Parameters for this subsystem are hard-coded in platform code (in arch/arm/mach-omap2/omap-hwmod_xxx_data.c) not in the DTS. It also handle clock and power domains.
HWMOD is probably going to go away some day, I'm not sure that we want to implement it in u-boot. Until hwmod has completely replaced by more generic frameworks, I would stick to platform code to enable clocks in u-boot.

Quoted 3 lines

But if this keeps going on, eventually we will regress to where we were years ago -- having huge platform specific list of registers to poke to set a platform up and that'd be it ?

We should certainly re-evaluate the situation once hwmod finally gets replaced in the kernel. That's a long-standing and slowly-but-surely happening thing.

Quoted 13 lines · Marek Vasut

Quoted 12 lines · Jean-Jacques Hiblot

Hi Marek,

Quoted 8 lines · Marek Vasut

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Shouldnt the driver turn this on?

AFAIK there is no clock driver for the OMAP. So we have to do it before
the driver is probed.

Maybe it's time to implement it instead of piling up those hacks ?

I was thinking along the same lines at some point but then I realized that it will make the SPL really big. And we are already tight on some platforms like am335x.

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

But this is not only SPL , right ? And yes, for SPL you might need to poke registers or something.

IMHO having 2 different ways to enable the clocks in SPL and in u-boot is an not improvement over the current situation.
In any case, This is a subject that can be discussed.

Do you have a better idea ?

I would keep it as it is today.

After studying the clock management in Linux, I believe that implementing the clock drivers in u-boot won't be an easy task and moreover won't make things much cleaner.
The way clocks are handled in Linux for the omap platforms is not completely standard. There are a lot of clocks that are handled by the clock framework (pll, mux, some gates, ...) but most of the clock gating for peripherals is handled the HWMOD subsystem which automatically enables/disables the clocks of the peripherals. Parameters for this subsystem are hard-coded in platform code (in arch/arm/mach-omap2/omap-hwmod_xxx_data.c) not in the DTS. It also handle clock and power domains.
HWMOD is probably going to go away some day, I'm not sure that we want to implement it in u-boot. Until hwmod has completely replaced by more generic frameworks, I would stick to platform code to enable clocks in u-boot.