Re: [PATCH V5 1/6] clk: OMAP: introduce device tree binding to kernel clock data
* Mike Turquette mturque...@linaro.org [130513 16:56]: Quoting Nishanth Menon (2013-05-08 12:06:11) snip Overall strategy introduced here is simple: a clock node described in device tree blob is used to identify the exact clock provided in the SoC specific data. This is then linked back using of_clk_add_provider to the device node to be accessible by of_clk_get. FYI, I'm working on moving the OMAP clocks over to DT which is a better alternative than this patch. I'll share what I have on the list, hopefully next week. That's good news! What's your plan on using the indexing the clocks? I'd rather avoid indexing as that's basically same as the old IRQ numbering and GPIO numbering schemes that don't work well in the long term. We already have quite a few sets of clocks for omaps, so the indexing is already an issue. My thinking is that indexing should only be used if the same physical clock has multiple outputs. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 1/6] clk: OMAP: introduce device tree binding to kernel clock data
* Mike Turquette mturque...@linaro.org [130516 12:52]:
Quoting Tony Lindgren (2013-05-16 10:43:56)
* Mike Turquette mturque...@linaro.org [130513 16:56]:
Quoting Nishanth Menon (2013-05-08 12:06:11)
snip
Overall strategy introduced here is simple: a clock node described in
device tree blob is used to identify the exact clock provided in the
SoC specific data. This is then linked back using of_clk_add_provider
to the device node to be accessible by of_clk_get.
FYI, I'm working on moving the OMAP clocks over to DT which is a better
alternative than this patch. I'll share what I have on the list,
hopefully next week.
That's good news! What's your plan on using the indexing the clocks?
I'd rather avoid indexing as that's basically same as the old IRQ
numbering and GPIO numbering schemes that don't work well in the long
term.
We already have quite a few sets of clocks for omaps, so the indexing
is already an issue. My thinking is that indexing should only be used
if the same physical clock has multiple outputs.
At present I am actually describing the clock hardware in DT. Each
clock is a node (not a device) using the established clock binding in
Documentation/devicetree/bindings/clocks/clock-bindings.txt.
To do this I am introducing new bindings for the common types: gate, mux
divider. These are the ones I am migrating to DT first. Eventually
I'll create bindings for the OMAP-specifc clocks after this.
Great, that's the way to go.
I currently have this DT approach co-existing with the static data. As
a start I have used the fixed-clock and mux-clock bindings to put all of
the root clocks and sys_clk into arch/arm/boot/dts/omap4-clocks.dtsi.
This file is included by arch/arm/boot/dts/omap4.dtsi.
OK.
The DT clocks are parsed prior to the static clock registration:
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 88e37a4..7cc4cae 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/clk/omap.h
#include soc.h
#include iomap.h
@@ -1442,27 +1443,11 @@ static struct omap_clk omap443x_clks[] = {
* clocks common to omap44xx
*/
static struct omap_clk omap44xx_clks[] = {
- CLK(NULL, extalt_clkin_ck, extalt_clkin_ck),
CLK(NULL, pad_clks_src_ck, pad_clks_src_ck),
CLK(NULL, pad_clks_ck, pad_clks_ck),
- CLK(NULL, pad_slimbus_core_clks_ck,
pad_slimbus_core_clks_ck),
- CLK(NULL, secure_32k_clk_src_ck,secure_32k_clk_src_ck),
CLK(NULL, slimbus_src_clk, slimbus_src_clk),
CLK(NULL, slimbus_clk, slimbus_clk),
CLK(NULL, sys_32k_ck, sys_32k_ck),
- CLK(NULL, virt_1200_ck, virt_1200_ck),
- CLK(NULL, virt_1300_ck, virt_1300_ck),
- CLK(NULL, virt_1680_ck, virt_1680_ck),
- CLK(NULL, virt_1920_ck, virt_1920_ck),
- CLK(NULL, virt_2600_ck, virt_2600_ck),
- CLK(NULL, virt_2700_ck, virt_2700_ck),
- CLK(NULL, virt_3840_ck, virt_3840_ck),
- CLK(NULL, sys_clkin_ck, sys_clkin_ck),
- CLK(NULL, tie_low_clock_ck, tie_low_clock_ck),
- CLK(NULL, utmi_phy_clkout_ck, utmi_phy_clkout_ck),
- CLK(NULL, xclk60mhsp1_ck, xclk60mhsp1_ck),
- CLK(NULL, xclk60mhsp2_ck, xclk60mhsp2_ck),
- CLK(NULL, xclk60motg_ck,xclk60motg_ck),
CLK(NULL, abe_dpll_bypass_clk_mux_ck,
abe_dpll_bypass_clk_mux_ck),
CLK(NULL, abe_dpll_refclk_mux_ck,
abe_dpll_refclk_mux_ck),
CLK(NULL, dpll_abe_ck, dpll_abe_ck),
@@ -1690,6 +1675,9 @@ int __init omap4xxx_clk_init(void)
{
int rc;
+ /* FIXME register clocks from DT first */
+ dt_omap_clk_init();
+
if (cpu_is_omap443x()) {
cpu_mask = RATE_IN_4430;
omap_clocks_register(omap443x_clks, ARRAY_SIZE(omap443x_clks));
Ideally dt_omap_clk_init() will go away and instead by replaced by the
probe from drivers/clk/omap/clk.c (new omap clock driver). However I
still need to register the root clocks before the PLLs and other
dividers for now to avoid many issues (divide by zero errors, failed
reparent operations, etc). And furthermore I don't think the hwmod code
will work if the clock tree is not populated before module_init. So for
now the omap clock driver does not properly probe or call module_init,
but some day that might be fixed.
Yes,
Re: [PATCH V5 1/6] clk: OMAP: introduce device tree binding to kernel clock data
Quoting Nishanth Menon (2013-05-08 12:06:11)
snip
Overall strategy introduced here is simple: a clock node described in
device tree blob is used to identify the exact clock provided in the
SoC specific data. This is then linked back using of_clk_add_provider
to the device node to be accessible by of_clk_get.
FYI, I'm working on moving the OMAP clocks over to DT which is a better
alternative than this patch. I'll share what I have on the list,
hopefully next week.
Regards,
Mike
Based on discussion contributions from Roger Quadros, Grygorii Strashko
and others.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
[t...@atomide.com: co-developed]
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in this version:
- review comments incorporated.
Previous version of this patch was discussed in:
http://marc.info/?t=13658075851r=1w=2
.../devicetree/bindings/clock/omap-clock.txt | 40 +
drivers/clk/Makefile |1 +
drivers/clk/omap/Makefile |1 +
drivers/clk/omap/clk.c | 91
4 files changed, 133 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
create mode 100644 drivers/clk/omap/Makefile
create mode 100644 drivers/clk/omap/clk.c
diff --git a/Documentation/devicetree/bindings/clock/omap-clock.txt
b/Documentation/devicetree/bindings/clock/omap-clock.txt
new file mode 100644
index 000..047c1e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap-clock.txt
@@ -0,0 +1,40 @@
+Device Tree Clock bindings for Texas Instrument's OMAP compatible platforms
+
+This binding is an initial minimal binding that may be enhanced as part of
+transitioning OMAP clock data out of kernel image.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be ti,omap-clock
+- #clock-cells : from common clock binding; shall be set to 0.
+NOTE:
+node name should map to clock database in
arch/arm/mach-omap2/cclockSoC_data.c
+Since all clocks are described with _ck, the node name is optimized to drop
the
+usage of _ck. For example, a clock called dpll1_ck will be defined as dpll1.
+
+Example #1: describing clock node for CPU on OMAP34xx platform:
+Ref: arch/arm/mach-omap2/cclock3xxx_data.c
+describes the CPU clock to be as follows
+ CLK(NULL, dpll1_ck, dpll1_ck, CK_3XXX),
+Corresponding binding will be:
+ dpll1: dpll1 {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+And it's usage will be:
+ clocks = dpll1;
+
+Example #2: describing clock node for auxilary clock #3 on OMAP443x platform:
+Ref: arch/arm/mach-omap2/cclock44xx_data.c
+describes the auxclk3 clock to be as follows:
+ CLK(NULL, auxclk3_ck, auxclk3_ck,CK_443X),
+Corresponding binding will be:
+ auxclk3: auxclk3 {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+And it's usage will be:
+ clocks = auxclk3;
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 137d3e7..1d5a2ec 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
obj-$(CONFIG_ARCH_ZYNQ)+= clk-zynq.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
+obj-$(CONFIG_ARCH_OMAP)+= omap/
obj-$(CONFIG_X86) += x86/
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y += clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 000..5a3c6d9
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,91 @@
+/*
+ * Texas Instruments OMAP Clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon n...@ti.com
+ * Tony Lindgren t...@atomide.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/kernel.h
+#include linux/module.h
+#include
