[PATCH V5 1/6] clk: OMAP: introduce device tree binding to kernel clock data

Quoting Tony Lindgren (2013-05-16 10:43:56)

* Mike Turquette [off-list ref] [130513 16:56]:

quoted

Quoting Nishanth Menon (2013-05-08 12:06:11)
<snip>

quoted

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.

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.

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_12000000_ck",		&virt_12000000_ck),
-	CLK(NULL,	"virt_13000000_ck",		&virt_13000000_ck),
-	CLK(NULL,	"virt_16800000_ck",		&virt_16800000_ck),
-	CLK(NULL,	"virt_19200000_ck",		&virt_19200000_ck),
-	CLK(NULL,	"virt_26000000_ck",		&virt_26000000_ck),
-	CLK(NULL,	"virt_27000000_ck",		&virt_27000000_ck),
-	CLK(NULL,	"virt_38400000_ck",		&virt_38400000_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.

I know that putting all of the data into DT is not a popular idea with
everybody.  I also know that I am not a DT expert, so I'm sure there are
some better approaches to the some of the decisions I'm making.  I'll
post an RFC to the list next week with cleaned-up patches and then we
can all take it from there.

Regards,
Mike

Regards,

Tony