ARM: OMAP: add external clock provider support

External clock provider can now be used to register external clocks under it. This is needed as the TI clock driver only registers clocks hierarchically under clock providers, and external clocks do not belong under any of the current ones.

Signed-off-by Tero Kristo <[email protected]>

External clock provider can now be used to register external clocks under it. This is needed as the TI clock driver only registers clocks hierarchically under clock providers, and external clocks do not belong under any of the current ones.

From the limited description above it sounds like the only reason this

Signed-off-by Tero Kristo <[email protected]>

---
 .../devicetree/bindings/arm/omap/ext-clocks.txt    |   32 ++++++++++++++++++++
 arch/arm/mach-omap2/io.c                           |   12 ++++++--
 drivers/clk/ti/clk.c                               |   23 ++++++++++++++
 include/linux/clk/ti.h                             |    2 ++
 4 files changed, 67 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/ext-clocks.txt

Documentation/devicetree/bindings/arm/omap/ext-clocks.txt new file +32 -0

new file mode 100644
index 0000000..8e784bb
@@ -0,0 +1,32 @@
+TI external clock provider properties
+
+External clock provider is used to group SoC external board specific
+clock nodes. A separate provider node is required as the TI clock
+driver registers clocks hierarchically.
+
+Required properties:
+- compatible:		Shall be: "ti,external-clocks"
+- clocks:		Contains the external clocks for the board
+- clockdomains:		Contains the external clockdomains for the board
+
+Example:
+
+ext_clocks {
+	compatible = "ti,external-clocks";
+
+	ext_clocks: clocks {
+	};
+
+	ext_clockdomains: clockdomains {
+	};
+};
+
+...
+
+&ext_clocks {
+	gpio_test_clock {
+		compatible = "gpio-clock";
+		#clock-cells = <0>;
+		enable-gpios = <&gpio5 25 GPIO_ACTIVE_HIGH>;
+	};
+};

arch/arm/mach-omap2/io.c +10 -2

index 8f55945..77be18b 100644
@@ -21,6 +21,8 @@
 #include <linux/init.h>
 #include <linux/io.h>
 #include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/clk/ti.h>
 
 #include <asm/tlb.h>
 #include <asm/mach/map.h>

@@ -729,8 +731,14 @@ int __init omap_clk_init(void)
 		return 0;
 
 	ret = of_prcm_init();
-	if (!ret)
-		ret = omap_clk_soc_init();
+	if (ret)
+		return ret;
+
+	ret = ti_dt_clk_ext_init();
+	if (ret)
+		return ret;
+
+	ret = omap_clk_soc_init();
 
 	return ret;
 }

drivers/clk/ti/clk.c +23 -0

index b1a6f71..c84ce4d 100644
@@ -165,3 +165,26 @@ void ti_dt_clk_init_provider(struct device_node *parent, int index)
 		kfree(retry);
 	}
 }
+
+static struct of_device_id ti_ext_clk_match_table[] = {
+	{ .compatible = "ti,external-clocks" },
+	{ }
+};
+
+/**
+ * ti_dt_clk_ext_init - initialize external clocks from DT
+ *
+ * Some clocks are provided from external chips outside the main SoC.
+ * The details for these are given under a special DT node, which will
+ * be parsed by this function.
+ */
+int ti_dt_clk_ext_init(void)
+{
+	struct device_node *np;
+
+	for_each_matching_node(np, ti_ext_clk_match_table) {
+		ti_dt_clk_init_provider(np, -1);
+	}
+
+	return 0;
+}

include/linux/clk/ti.h +2 -0

index e8d8a35..188270c 100644
@@ -310,6 +310,8 @@ int am43xx_dt_clk_init(void);
 int omap2420_dt_clk_init(void);
 int omap2430_dt_clk_init(void);
 
+int ti_dt_clk_ext_init(void);
+
 #ifdef CONFIG_OF
 void of_ti_clk_allow_autoidle_all(void);
 void of_ti_clk_deny_autoidle_all(void);

Signature · 6 lines

1.7.9.5

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

Hi Tero,

Quoted 4 lines · Tero Kristo

External clock provider can now be used to register external clocks under it. This is needed as the TI clock driver only registers clocks hierarchically under clock providers, and external clocks do not belong under any of the current ones.

I must admit that I don't understand the justification for this binding.

Why can't these clocks be descrbied elsewhere and wired up as usual? Why must they be under the TI clock provide node?

From the limited description above it sounds like the only reason this
exists is to work around a deficiency in the TI clock driver. That does not sound like a very good reason for having this.

Thanks,
Mark.

Quoted 130 lines

Signed-off-by Tero Kristo <[email protected]>

---
  .../devicetree/bindings/arm/omap/ext-clocks.txt    |   32 ++++++++++++++++++++
  arch/arm/mach-omap2/io.c                           |   12 ++++++--
  drivers/clk/ti/clk.c                               |   23 ++++++++++++++
  include/linux/clk/ti.h                             |    2 ++
  4 files changed, 67 insertions(+), 2 deletions(-)

create mode 100644 Documentation/devicetree/bindings/arm/omap/ext-clocks.txt

Documentation/devicetree/bindings/arm/omap/ext-clocks.txt new file +32 -0

new file mode 100644
index 0000000..8e784bb
@@ -0,0 +1,32 @@
+TI external clock provider properties
+
+External clock provider is used to group SoC external board specific
+clock nodes. A separate provider node is required as the TI clock
+driver registers clocks hierarchically.
+
+Required properties:
+- compatible:		Shall be: "ti,external-clocks"
+- clocks:		Contains the external clocks for the board
+- clockdomains:		Contains the external clockdomains for the board
+
+Example:
+
+ext_clocks {
+	compatible = "ti,external-clocks";
+
+	ext_clocks: clocks {
+	};
+
+	ext_clockdomains: clockdomains {
+	};
+};
+
+...
+
+&ext_clocks {
+	gpio_test_clock {
+		compatible = "gpio-clock";
+		#clock-cells = <0>;
+		enable-gpios = <&gpio5 25 GPIO_ACTIVE_HIGH>;
+	};
+};

arch/arm/mach-omap2/io.c +10 -2

index 8f55945..77be18b 100644
@@ -21,6 +21,8 @@
  #include <linux/init.h>
  #include <linux/io.h>
  #include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/clk/ti.h>
 
  #include <asm/tlb.h>
  #include <asm/mach/map.h>

@@ -729,8 +731,14 @@ int __init omap_clk_init(void)
  		return 0;
 
  	ret = of_prcm_init();
-	if (!ret)
-		ret = omap_clk_soc_init();
+	if (ret)
+		return ret;
+
+	ret = ti_dt_clk_ext_init();
+	if (ret)
+		return ret;
+
+	ret = omap_clk_soc_init();
 
  	return ret;
  }

drivers/clk/ti/clk.c +23 -0

index b1a6f71..c84ce4d 100644
@@ -165,3 +165,26 @@ void ti_dt_clk_init_provider(struct device_node *parent, int index)
  		kfree(retry);
  	}
  }
+
+static struct of_device_id ti_ext_clk_match_table[] = {
+	{ .compatible = "ti,external-clocks" },
+	{ }
+};
+
+/**
+ * ti_dt_clk_ext_init - initialize external clocks from DT
+ *
+ * Some clocks are provided from external chips outside the main SoC.
+ * The details for these are given under a special DT node, which will
+ * be parsed by this function.
+ */
+int ti_dt_clk_ext_init(void)
+{
+	struct device_node *np;
+
+	for_each_matching_node(np, ti_ext_clk_match_table) {
+		ti_dt_clk_init_provider(np, -1);
+	}
+
+	return 0;
+}

include/linux/clk/ti.h +2 -1

index e8d8a35..188270c 100644
@@ -310,6 +310,8 @@ int am43xx_dt_clk_init(void);
  int omap2420_dt_clk_init(void);
  int omap2430_dt_clk_init(void);
 
+int ti_dt_clk_ext_init(void);
+
  #ifdef CONFIG_OF
  void of_ti_clk_allow_autoidle_all(void);
  void of_ti_clk_deny_autoidle_all(void);
--

1.7.9.5

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

Quoted 9 lines · Mark Rutland

Hi Tero,

Quoted 5 lines · Tero Kristo

External clock provider can now be used to register external clocks under
it. This is needed as the TI clock driver only registers clocks hierarchically under clock providers, and external clocks do not belong under any of the current ones.

Quoted 8 lines

I must admit that I don't understand the justification for this binding.

Why can't these clocks be descrbied elsewhere and wired up as usual? Why must they be under the TI clock provide node?

From the limited description above it sounds like the only reason this
exists is to work around a deficiency in the TI clock driver. That does not sound like a very good reason for having this.

I wouldn't call it a deficiency, but its by design due to need for registering clocks and clock providers hierarchically.

I guess it might be possible to re-work the TI clock init to check for the parent node, and if it is a clock provider, see if it has been initialized or not. The clock provider maps the IO range so it must be initialized before any clocks under it are initialized. I'll experiment with this a bit and see how it works out.

Quoted 141 lines

Thanks,
Mark.

Quoted 136 lines

Signed-off-by Tero Kristo <[email protected]>

---
  .../devicetree/bindings/arm/omap/ext-clocks.txt    |   32
++++++++++++++++++++
  arch/arm/mach-omap2/io.c                           |   12 ++++++--
  drivers/clk/ti/clk.c                               |   23
++++++++++++++
  include/linux/clk/ti.h                             |    2 ++
  4 files changed, 67 insertions(+), 2 deletions(-)

create mode 100644
Documentation/devicetree/bindings/arm/omap/ext-clocks.txt

diff --git a/Documentation/devicetree/bindings/arm/omap/ext-clocks.txt b/Documentation/devicetree/bindings/arm/omap/ext-clocks.txt new file mode 100644
index 0000000..8e784bb

Documentation/devicetree/bindings/arm/omap/ext-clocks.txt new file +32 -0

@@ -0,0 +1,32 @@
+TI external clock provider properties
+
+External clock provider is used to group SoC external board specific
+clock nodes. A separate provider node is required as the TI clock
+driver registers clocks hierarchically.
+
+Required properties:
+- compatible:        Shall be: "ti,external-clocks"
+- clocks:        Contains the external clocks for the board
+- clockdomains:        Contains the external clockdomains for the board
+
+Example:
+
+ext_clocks {
+    compatible = "ti,external-clocks";
+
+    ext_clocks: clocks {
+    };
+
+    ext_clockdomains: clockdomains {
+    };
+};
+
+...
+
+&ext_clocks {
+    gpio_test_clock {
+        compatible = "gpio-clock";
+        #clock-cells = <0>;
+        enable-gpios = <&gpio5 25 GPIO_ACTIVE_HIGH>;
+    };
+};

arch/arm/mach-omap2/io.c +10 -2

index 8f55945..77be18b 100644
@@ -21,6 +21,8 @@
  #include <linux/init.h>
  #include <linux/io.h>
  #include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/clk/ti.h>
 
  #include <asm/tlb.h>
  #include <asm/mach/map.h>

@@ -729,8 +731,14 @@ int __init omap_clk_init(void)
          return 0;
 
      ret = of_prcm_init();
-    if (!ret)
-        ret = omap_clk_soc_init();
+    if (ret)
+        return ret;
+
+    ret = ti_dt_clk_ext_init();
+    if (ret)
+        return ret;
+
+    ret = omap_clk_soc_init();
 
      return ret;
  }

drivers/clk/ti/clk.c +23 -0

index b1a6f71..c84ce4d 100644
@@ -165,3 +165,26 @@ void ti_dt_clk_init_provider(struct device_node
 *parent, int index)
          kfree(retry);
      }
  }
+
+static struct of_device_id ti_ext_clk_match_table[] = {
+    { .compatible = "ti,external-clocks" },
+    { }
+};
+
+/**
+ * ti_dt_clk_ext_init - initialize external clocks from DT
+ *
+ * Some clocks are provided from external chips outside the main SoC.
+ * The details for these are given under a special DT node, which will
+ * be parsed by this function.
+ */
+int ti_dt_clk_ext_init(void)
+{
+    struct device_node *np;
+
+    for_each_matching_node(np, ti_ext_clk_match_table) {
+        ti_dt_clk_init_provider(np, -1);
+    }
+
+    return 0;
+}

include/linux/clk/ti.h +2 -1

index e8d8a35..188270c 100644
@@ -310,6 +310,8 @@ int am43xx_dt_clk_init(void);
  int omap2420_dt_clk_init(void);
  int omap2430_dt_clk_init(void);
 
+int ti_dt_clk_ext_init(void);
+
  #ifdef CONFIG_OF
  void of_ti_clk_allow_autoidle_all(void);
  void of_ti_clk_deny_autoidle_all(void);
--

1.7.9.5

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

Hi,

This patch adds possibility to register external clocks (outside the main SoC) on TI boards through device tree. Clock sources as such include for example twl-6030 / twl-6040 chips and variants which can be used to clock for example audio / WLAN chips.

This patch can be queued once someone has a use-case + patches that requires usage of such clocks.

-Tero

Quoted 6 lines · Tero Kristo

Hi,

This patch adds possibility to register external clocks (outside the main SoC) on TI boards through device tree. Clock sources as such include for example twl-6030 / twl-6040 chips and variants which can be used to clock for example audio / WLAN chips.

Just one question to Mike and Tero:
would it be possible to have generic binding for such an external clocks? We have the palmas clock driver already upstream which handles the 32K clocks from the PMIC. Palmas class of PMICs can be used with TI/nVidia(/Intel?) platforms. We use Palmas on omap5-uevm, DRA7-EVM also uses Palmas compatible PMIC and some nVidia platform also uses this class of devices (and they all need to have control over the 32K clock(s)).

Quoted 6 lines

This patch can be queued once someone has a use-case + patches that requires usage of such clocks.

-Tero

Quoted 8 lines · Tero Kristo

Quoted 6 lines

Hi,

This patch adds possibility to register external clocks (outside the main SoC) on TI boards through device tree. Clock sources as such include for example twl-6030 / twl-6040 chips and variants which can be used to clock for example audio / WLAN chips.

Quoted 7 lines

Just one question to Mike and Tero:
would it be possible to have generic binding for such an external clocks? We have the palmas clock driver already upstream which handles the 32K clocks from the PMIC. Palmas class of PMICs can be used with TI/nVidia(/Intel?) platforms. We use Palmas on omap5-uevm, DRA7-EVM also uses Palmas compatible PMIC and some nVidia platform also uses this class of devices (and they all need to have control over the 32K clock(s)).

Other platforms initialize their clocks in different manner, they can use generic of_clk_init I believe. If they can't use that for some reason, then they need to implement something similar to this.

-Tero

Quoted 8 lines

Quoted 6 lines

This patch can be queued once someone has a use-case + patches that requires usage of such clocks.

-Tero

Quoting Tero Kristo (2014-08-04 05:36:19)

Quoted 17 lines · Peter Ujfalusi

Quoted 8 lines · Tero Kristo

Quoted 6 lines

Hi,

This patch adds possibility to register external clocks (outside the main SoC) on TI boards through device tree. Clock sources as such include for example twl-6030 / twl-6040 chips and variants which can be used to clock for example audio / WLAN chips.

Quoted 7 lines

Just one question to Mike and Tero:
would it be possible to have generic binding for such an external clocks? We have the palmas clock driver already upstream which handles the 32K clocks from the PMIC. Palmas class of PMICs can be used with TI/nVidia(/Intel?) platforms. We use Palmas on omap5-uevm, DRA7-EVM also uses Palmas compatible PMIC and some nVidia platform also uses this class of devices (and they all need to have control over the 32K clock(s)).

Quoted 3 lines

Other platforms initialize their clocks in different manner, they can use generic of_clk_init I believe. If they can't use that for some reason, then they need to implement something similar to this.

Right. To answer Peter's question, we do have a generic binding, it is the clock binding ;-)

Even the idea of having a "TI clock provider" isn't really a good way to do things. IP blocks that generate clocks are clock providers, not companies. As such if Palmas or Gaia or whatever generate clocks then we don't need any new infrastructure in the clock core to accomodate this. Those drivers simply need to include clk-provider.h and register their clocks with the framework.

Some good examples of this are the omap3-isp.c driver, and qcom's hdmi phy driver (sorry, don't have the path handy) which both consume clocks generated by other clock providers, and they provide their own clocks which are generated within their own IP/module.

A big part of the design of the ccf (and later, the DT bindings) is that we do not need a centralized place to store every piece of clock generation knowledge and clock routing knowledge.

Regards,
Mike

Quoted 12 lines

-Tero

Quoted 8 lines

Quoted 6 lines

This patch can be queued once someone has a use-case + patches that requires usage of such clocks.

-Tero