[PATCH V5 0/6] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[PATCH V5 0/6] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[Nishanth Menon]

The following version 5 of the series arose from trying to use
BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0.
This series enables the generic cpufreq-cpu0 driver to be used in
device tree enabled boot while maintaining support of the legacy
omap-cpufreq driver when used in non device tree enabled boot.

However, in order to enable complete SoC entitlement for OMAP
platforms, with this series, key features are still pending on device
tree adaptation for OMAP:
A) clock framework data transition to DT - this series provides an
driver to allow device tree definition of clock node.
B) On processors that use voltage controller, voltage processor
(VC/VP hardware loop using I2C_SR path) - we have started work on
transitioning them to regulator framework driven by DT.
C) Adaptive Body Bias[2] and SmartReflex AVS conversion to DT.

Note: Common Clock Framework(CCF) could also control regulators[3] and
AVS to ensure proper sequencing required for full DVFS sequencing.
Once these conversions are complete, there might be minimal cleanup
work to switch to the new data structure changes.

Key benefit of the series is to allow all relevant TI platforms now to
use a single cpufreq driver and equivalent frameworks in addition be
part of the transition to device tree.

NOTE on this series:
1. omap-cpufreq will be used only in non device tree boot scenario. we
should delete this driver once the 100% DT conversion is complete.
2. Generic cpufreq-cpu0 will be used only in device tree boot scenario
boot systems
3. clock data movement as approached by Tero in [4] is not the
objective of this series
4. meant for post 3.10-rc1 tag

Key changes in version 5 since version 4:
	- rebase with master for 3.10-rc1 intermediate
	- review comments incorporated

version 4 of the series:
	http://marc.info/?l=linux-arm-kernel&m=136580742724210&w=2
	available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v4

version 3 of the series:
	http://marc.info/?l=linux-pm&m=136450759315742&w=2
	available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v3

version 2 of the series:
	http://marc.info/?t=136371570200003&r=1&w=2
	available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2

version 1 of the series:
	http://marc.info/?t=136329485400005&r=1&w=2
	available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1

[1] Original discussion thread which triggered this series:
	http://marc.info/?l=linux-pm&m=136304313700602&w=2
	https://patchwork.kernel.org/patch/2251841/
	https://patchwork.kernel.org/patch/2251851/
[2] ABB series: http://marc.info/?l=linux-omap&m=136751559523901&w=2 (ABB DTS merge pending)
[3] CCF DVFS patches:
https://patchwork.kernel.org/patch/2195431/
https://patchwork.kernel.org/patch/2195421/
https://patchwork.kernel.org/patch/2195451/
https://patchwork.kernel.org/patch/2195441/
https://patchwork.kernel.org/patch/2195461/
[4] http://marc.info/?t=136388745000001&r=1&w=2

Version 5 is now based on master since all requisite for-next branches have been merged.
	master 5af43c2 Merge branch 'akpm' (incoming from Andrew)

Version 4 is also available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v5
	git link: git://github.com/nmenon/linux-2.6-playground.git
	branch: cpufreq-cpu0-omap-all-v5

Test coverage:
	test script:  http://pastebin.com/GsavxiDe
	(note - to allow testing, I followed the suggestion in https://lkml.org/lkml/2013/5/8/19 )

Platforms verified:
	beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/zANKsYBp
	beagleboard (rev C1D) - OMAP3430 compatible
		- DT enabled boot:  http://pastebin.com/q4qZYVaK
		- No DT enabled boot: http://pastebin.com/c1CbQmV5
	omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/ibUABcA0
	SDP4430 -(OMAP4430 ES2.2) - http://pastebin.com/wYwUc3fU
	Pandaboard-ES -(OMAP4460 ES1.1) - http://pastebin.com/FB2RiFp2

Nishanth Menon (6):
  clk: OMAP: introduce device tree binding to kernel clock data
[Clk driver probably belongs to mike's tree?]
  ARM: dts: OMAP3: add clock nodes for CPU
  ARM: dts: OMAP4: add clock nodes for CPU
  ARM: dts: AM33XX: add clock nodes for CPU
[The above probably belong to Benoit's tree]
  ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init
  ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot
[The above probably belong to Kevin/Tony's tree]

 .../devicetree/bindings/clock/omap-clock.txt       |   40 +++++++++
 arch/arm/boot/dts/am33xx.dtsi                      |    7 ++
 arch/arm/boot/dts/omap3.dtsi                       |    7 ++
 arch/arm/boot/dts/omap4.dtsi                       |    7 ++
 arch/arm/mach-omap2/board-generic.c                |    1 +
 arch/arm/mach-omap2/cclock33xx_data.c              |    1 -
 arch/arm/mach-omap2/common.h                       |    1 +
 arch/arm/mach-omap2/io.c                           |    6 ++
 arch/arm/mach-omap2/pm.c                           |   11 ++-
 drivers/clk/Makefile                               |    1 +
 drivers/clk/omap/Makefile                          |    1 +
 drivers/clk/omap/clk.c                             |   91 ++++++++++++++++++++
 12 files changed, 170 insertions(+), 4 deletions(-)
 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

Regards,
Nishanth Menon
-- 
1.7.9.5

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

[Nishanth Menon]

OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
However, this presents an obstacle for using these clock nodes in
Device Tree definitions. This is especially true for board specific
clocks initially. The fixed clocks are currently found via clock
aliases table. There are many possible approaches to this problem as
discussed in the following thread:
http://marc.info/?t=136370325600009&r=1&w=2.
Highlights of the options:
a) device specific clk_add_alias:
   cons: driver handling required
b) using an generic clk node and indexing to reach the clock required.
   This is similar in approach taken by tegra and few other platforms.
   Example usage: clock = <&clk 5>;
   cons: potential to have mismatches in indexed table and associated
   dtb data. In addition, managing continued documentation in bindings
   as clock indexing increases. Even though readability angle could be
   improved by using preprocessing of DT using macros, indexed
   approach is inherently risky from cases like the following:
   clk indexes in kernel:
   1 - mpu_dpll
   2 - aux_clk1
   3 - core_clk
   DT entry for peripheral X uses <&clk 2> to reach aux_clk1. Now, let's
   say kernel updates indices to:
   1 - mpu_dpll
   2 - per_dpll
   3 - aux_clk1
   4 - core_clk
   using the old dtb(or dts missing an update), on new kernel which
   has updated indices will result in per_dpll now controlled for
   peripheral X without warning or any potential error detection.

   Even though we could claim this is user error, such errors are hard
   to track down and fix.

An alternate approach introduced here is to introduce device tree
bindings corresponding to the clock nodes required in DT definition
for SoC which automatically maps back to the definitions in
cclockXYZ_data.c.

The driver introduced here to do this mapping will eventually be the
place where the clock handling will migrate to. We need to consider
this angle as well so that the solution will be an valid transition
point for moving the clock data out of kernel image (into device tree
or firmware load etc..).

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.

Based on discussion contributions from Roger Quadros, Grygorii Strashko
and others.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Paul Walmsley <paul@pwsan.com>
[tony at atomide.com: co-developed]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes in this version:
	- review comments incorporated.
Previous version of this patch was discussed in:
	http://marc.info/?t=136580758500001&r=1&w=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 0000000..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/cclock<SoC>_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 0000000..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 0000000..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 <nm@ti.com>
+ *	Tony Lindgren <tony@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 <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/string.h>
+
+static const struct of_device_id omap_clk_of_match[] = {
+	{.compatible = "ti,omap-clock",},
+	{},
+};
+
+/**
+ * omap_clk_src_get() - Get OMAP clock from node name when needed
+ * @clkspec:	clkspec argument
+ * @data:	unused
+ *
+ * REVISIT: We assume the following:
+ * 1. omap clock names end with _ck
+ * 2. omap clock names are under 32 characters in length
+ */
+static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void *data)
+{
+	struct clk *clk;
+	char clk_name[32];
+	struct device_node *np = clkspec->np;
+
+	snprintf(clk_name, 32, "%s_ck", np->name);
+	clk = clk_get(NULL, clk_name);
+	if (IS_ERR(clk))
+		pr_err("%s: could not get clock %s(%ld)\n", __func__,
+		       clk_name, PTR_ERR(clk));
+
+	return clk;
+}
+
+/**
+ * omap_clk_probe() - create link from DT definition to clock data
+ * @pdev:	device node
+ *
+ * NOTE: we look up the clock lazily when the consumer driver does
+ * of_clk_get() and initialize a NULL clock here.
+ */
+static int omap_clk_probe(struct platform_device *pdev)
+{
+	int res;
+	struct device_node *np = pdev->dev.of_node;
+
+	/* This allows the driver to of_clk_get() */
+	res = of_clk_add_provider(np, omap_clk_src_get, NULL);
+	if (res)
+		dev_err(&pdev->dev, "could not add provider(%d)\n", res);
+
+	return res;
+}
+
+static struct platform_driver omap_clk_driver = {
+	.probe = omap_clk_probe,
+	.driver = {
+		   .name = "omap_clk",
+		   .of_match_table = of_match_ptr(omap_clk_of_match),
+		   },
+};
+
+static int __init omap_clk_init(void)
+{
+	return platform_driver_register(&omap_clk_driver);
+}
+arch_initcall(omap_clk_init);
+
+MODULE_DESCRIPTION("OMAP Clock driver");
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5

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

[Mike Turquette]

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 <khilman@deeprootsystems.com>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Paul Walmsley <paul@pwsan.com>
> [tony at atomide.com: co-developed]
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Changes in this version:
>         - review comments incorporated.
> Previous version of this patch was discussed in:
>         http://marc.info/?t=136580758500001&r=1&w=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 0000000..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/cclock<SoC>_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 0000000..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 0000000..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 <nm@ti.com>
> + *     Tony Lindgren <tony@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 <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/string.h>
> +
> +static const struct of_device_id omap_clk_of_match[] = {
> +       {.compatible = "ti,omap-clock",},
> +       {},
> +};
> +
> +/**
> + * omap_clk_src_get() - Get OMAP clock from node name when needed
> + * @clkspec:   clkspec argument
> + * @data:      unused
> + *
> + * REVISIT: We assume the following:
> + * 1. omap clock names end with _ck
> + * 2. omap clock names are under 32 characters in length
> + */
> +static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void *data)
> +{
> +       struct clk *clk;
> +       char clk_name[32];
> +       struct device_node *np = clkspec->np;
> +
> +       snprintf(clk_name, 32, "%s_ck", np->name);
> +       clk = clk_get(NULL, clk_name);
> +       if (IS_ERR(clk))
> +               pr_err("%s: could not get clock %s(%ld)\n", __func__,
> +                      clk_name, PTR_ERR(clk));
> +
> +       return clk;
> +}
> +
> +/**
> + * omap_clk_probe() - create link from DT definition to clock data
> + * @pdev:      device node
> + *
> + * NOTE: we look up the clock lazily when the consumer driver does
> + * of_clk_get() and initialize a NULL clock here.
> + */
> +static int omap_clk_probe(struct platform_device *pdev)
> +{
> +       int res;
> +       struct device_node *np = pdev->dev.of_node;
> +
> +       /* This allows the driver to of_clk_get() */
> +       res = of_clk_add_provider(np, omap_clk_src_get, NULL);
> +       if (res)
> +               dev_err(&pdev->dev, "could not add provider(%d)\n", res);
> +
> +       return res;
> +}
> +
> +static struct platform_driver omap_clk_driver = {
> +       .probe = omap_clk_probe,
> +       .driver = {
> +                  .name = "omap_clk",
> +                  .of_match_table = of_match_ptr(omap_clk_of_match),
> +                  },
> +};
> +
> +static int __init omap_clk_init(void)
> +{
> +       return platform_driver_register(&omap_clk_driver);
> +}
> +arch_initcall(omap_clk_init);
> +
> +MODULE_DESCRIPTION("OMAP Clock driver");
> +MODULE_AUTHOR("Texas Instruments Inc.");
> +MODULE_LICENSE("GPL v2");
> -- 
> 1.7.9.5

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

[Tony Lindgren]

* Mike Turquette <mturquette@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

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

[Mike Turquette]

Quoting Tony Lindgren (2013-05-16 10:43:56)
> * Mike Turquette <mturquette@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.

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

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

[Tony Lindgren]

* Mike Turquette <mturquette@linaro.org> [130516 12:52]:
> Quoting Tony Lindgren (2013-05-16 10:43:56)
> > * Mike Turquette <mturquette@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_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.

Yes, I'm sure there are some dependencies to untangle there..
 
> 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.

The DT related bloat issues can be avoided with the following:

1. Allow defining all clocks as needed in the .dtsi files

   This way we have the clocks available for timer, uart, mmc and
   whatever people might need.

2. Optionally allow loading the complete clock set from /lib/firmware

   This way we can avoid large amount of data in the .dtsi files
   to make booting faster. Naturally this is optional, and not needed
   if all the clocks are already defined in .dtsi files. And this can
   of course done later on if needed as long as we just keep that
   option open.

Regards,

Tony

[PATCH V5 2/6] ARM: dts: OMAP3: add clock nodes for CPU

[Nishanth Menon]

OMAP34xx and OMAP36xx platforms use dpll1 clock. Add same to common
definition.

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
no change in current revision.
Previous version: http://marc.info/?l=linux-kernel&m=136580740024201&w=2

 arch/arm/boot/dts/omap3.dtsi |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 4ad03d9..4f445ca 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -23,6 +23,8 @@
 	cpus {
 		cpu at 0 {
 			compatible = "arm,cortex-a8";
+			clocks = <&dpll1>;
+			clock-names = "cpu";
 		};
 	};
 
@@ -73,6 +75,11 @@
 			ti,hwmods = "counter_32k";
 		};
 
+		dpll1: dpll1 {
+			#clock-cells = <0>;
+			compatible = "ti,omap-clock";
+		};
+
 		intc: interrupt-controller at 48200000 {
 			compatible = "ti,omap2-intc";
 			interrupt-controller;
-- 
1.7.9.5

[PATCH V5 3/6] ARM: dts: OMAP4: add clock nodes for CPU

[Nishanth Menon]

OMAP443x, OMAP446x and OMAP447x platforms use dpll_mpu clock.
Add same to common definition.

Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
no change in current revision.
Previous version: http://marc.info/?l=linux-kernel&m=136580751024225&w=2

 arch/arm/boot/dts/omap4.dtsi |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..1c6d969 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -31,6 +31,8 @@
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
 			next-level-cache = <&L2>;
+			clocks = <&dpll_mpu>;
+			clock-names = "cpu";
 		};
 		cpu at 1 {
 			compatible = "arm,cortex-a9";
@@ -106,6 +108,11 @@
 			ti,hwmods = "counter_32k";
 		};
 
+		dpll_mpu: dpll_mpu {
+			#clock-cells = <0>;
+			compatible = "ti,omap-clock";
+		};
+
 		omap4_pmx_core: pinmux at 4a100040 {
 			compatible = "ti,omap4-padconf", "pinctrl-single";
 			reg = <0x4a100040 0x0196>;
-- 
1.7.9.5

[PATCH V5 4/6] ARM: dts: AM33XX: add clock nodes for CPU

[Nishanth Menon]

AM33XX based platforms use dpll_mpu clock. Add same to common dtsi
and remove the dummy clock node entry as AM33XX platform supports
only device tree based boot.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Change in this revision from previous:
	- rebase, no functional change.
Previous version: http://marc.info/?l=linux-kernel&m=136580755324232&w=2

 arch/arm/boot/dts/am33xx.dtsi         |    7 +++++++
 arch/arm/mach-omap2/cclock33xx_data.c |    1 -
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index d110110..27f6eb1 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -42,6 +42,8 @@
 				275000  1125000
 			>;
 			voltage-tolerance = <2>; /* 2 percentage */
+			clocks = <&dpll_mpu>;
+			clock-names = "cpu";
 			clock-latency = <300000>; /* From omap-cpufreq driver */
 		};
 	};
@@ -89,6 +91,11 @@
 			reg = <0x48200000 0x1000>;
 		};
 
+		dpll_mpu: dpll_mpu {
+			#clock-cells = <0>;
+			compatible = "ti,omap-clock";
+		};
+
 		gpio0: gpio at 44e07000 {
 			compatible = "ti,omap4-gpio";
 			ti,hwmods = "gpio1";
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
index 6ebc780..4e39171 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -860,7 +860,6 @@ static struct omap_clk am33xx_clks[] = {
 	CLK(NULL,	"dpll_core_m5_ck",	&dpll_core_m5_ck),
 	CLK(NULL,	"dpll_core_m6_ck",	&dpll_core_m6_ck),
 	CLK(NULL,	"dpll_mpu_ck",		&dpll_mpu_ck),
-	CLK("cpu0",	NULL,			&dpll_mpu_ck),
 	CLK(NULL,	"dpll_mpu_m2_ck",	&dpll_mpu_m2_ck),
 	CLK(NULL,	"dpll_ddr_ck",		&dpll_ddr_ck),
 	CLK(NULL,	"dpll_ddr_m2_ck",	&dpll_ddr_m2_ck),
-- 
1.7.9.5

[PATCH V5 5/6] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init

[Nishanth Menon]

Call OMAP2+ generic lateinit hook from AM specific late init hook.
This allows the generic late initializations such as cpufreq hooks
to be active.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Change in this revision compared to previous revision:
	- rebase, no functional change.
Previous version: http://marc.info/?l=linux-kernel&m=136580760924258&w=2

 arch/arm/mach-omap2/board-generic.c |    1 +
 arch/arm/mach-omap2/common.h        |    1 +
 arch/arm/mach-omap2/io.c            |    6 ++++++
 3 files changed, 8 insertions(+)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 88aa6b1..2c5c67c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -141,6 +141,7 @@ DT_MACHINE_START(AM33XX_DT, "Generic AM33XX (Flattened Device Tree)")
 	.init_irq	= omap_intc_of_init,
 	.handle_irq	= omap3_intc_handle_irq,
 	.init_machine	= omap_generic_init,
+	.init_late	= am33xx_init_late,
 	.init_time	= omap3_gptimer_timer_init,
 	.dt_compat	= am33xx_boards_compat,
 	.restart	= am33xx_restart,
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index d555cf2..e2d7ecf 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -107,6 +107,7 @@ void omap35xx_init_late(void);
 void omap3630_init_late(void);
 void am35xx_init_late(void);
 void ti81xx_init_late(void);
+void am33xx_init_late(void);
 int omap2_common_pm_late_init(void);
 
 #ifdef CONFIG_SOC_BUS
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 09abf99..401e268 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -584,6 +584,12 @@ void __init am33xx_init_early(void)
 	omap_hwmod_init_postsetup();
 	omap_clk_init = am33xx_clk_init;
 }
+
+void __init am33xx_init_late(void)
+{
+	omap2_common_pm_late_init();
+}
+
 #endif
 
 #ifdef CONFIG_ARCH_OMAP4
-- 
1.7.9.5

[PATCH V5 6/6] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Nishanth Menon]

With OMAP3+ and AM33xx supported SoC having defined CPU device tree
entries with operating-points and clock nodes defined, we can now use
the SoC generic cpufreq-cpu0 driver by registering appropriate device.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
no change in current revision.
Previous version: http://marc.info/?l=linux-omap&m=136580759924239&w=2

 arch/arm/mach-omap2/pm.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index e742118..11bd585 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -266,7 +266,12 @@ static void __init omap4_init_voltages(void)
 
 static inline void omap_init_cpufreq(void)
 {
-	struct platform_device_info devinfo = { .name = "omap-cpufreq", };
+	struct platform_device_info devinfo = { };
+
+	if (!of_have_populated_dt())
+		devinfo.name = "omap-cpufreq";
+	else
+		devinfo.name = "cpufreq-cpu0";
 	platform_device_register_full(&devinfo);
 }
 
@@ -300,9 +305,9 @@ int __init omap2_common_pm_late_init(void)
 		/* Smartreflex device init */
 		omap_devinit_smartreflex();
 
-		/* cpufreq dummy device instantiation */
-		omap_init_cpufreq();
 	}
+	/* cpufreq dummy device instantiation */
+	omap_init_cpufreq();
 
 #ifdef CONFIG_SUSPEND
 	suspend_set_ops(&omap_pm_ops);
-- 
1.7.9.5

[PATCH V5 0/6] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[Kevin Hilman]

Hi Nishanth,

Nishanth Menon <nm@ti.com> writes:

> The following version 5 of the series arose from trying to use
> BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0.
> This series enables the generic cpufreq-cpu0 driver to be used in
> device tree enabled boot while maintaining support of the legacy
> omap-cpufreq driver when used in non device tree enabled boot.

What's the status of this series?  Is it still waiting on the clock DT
changes?

Kevin

> However, in order to enable complete SoC entitlement for OMAP
> platforms, with this series, key features are still pending on device
> tree adaptation for OMAP:
> A) clock framework data transition to DT - this series provides an
> driver to allow device tree definition of clock node.
> B) On processors that use voltage controller, voltage processor
> (VC/VP hardware loop using I2C_SR path) - we have started work on
> transitioning them to regulator framework driven by DT.
> C) Adaptive Body Bias[2] and SmartReflex AVS conversion to DT.
>
> Note: Common Clock Framework(CCF) could also control regulators[3] and
> AVS to ensure proper sequencing required for full DVFS sequencing.
> Once these conversions are complete, there might be minimal cleanup
> work to switch to the new data structure changes.
>
> Key benefit of the series is to allow all relevant TI platforms now to
> use a single cpufreq driver and equivalent frameworks in addition be
> part of the transition to device tree.
>
> NOTE on this series:
> 1. omap-cpufreq will be used only in non device tree boot scenario. we
> should delete this driver once the 100% DT conversion is complete.
> 2. Generic cpufreq-cpu0 will be used only in device tree boot scenario
> boot systems
> 3. clock data movement as approached by Tero in [4] is not the
> objective of this series
> 4. meant for post 3.10-rc1 tag
>
> Key changes in version 5 since version 4:
> 	- rebase with master for 3.10-rc1 intermediate
> 	- review comments incorporated
>
> version 4 of the series:
> 	http://marc.info/?l=linux-arm-kernel&m=136580742724210&w=2
> 	available at:
> 	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v4
>
> version 3 of the series:
> 	http://marc.info/?l=linux-pm&m=136450759315742&w=2
> 	available at:
> 	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v3
>
> version 2 of the series:
> 	http://marc.info/?t=136371570200003&r=1&w=2
> 	available at:
> 	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2
>
> version 1 of the series:
> 	http://marc.info/?t=136329485400005&r=1&w=2
> 	available at:
> 	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1
>
> [1] Original discussion thread which triggered this series:
> 	http://marc.info/?l=linux-pm&m=136304313700602&w=2
> 	https://patchwork.kernel.org/patch/2251841/
> 	https://patchwork.kernel.org/patch/2251851/
> [2] ABB series: http://marc.info/?l=linux-omap&m=136751559523901&w=2 (ABB DTS merge pending)
> [3] CCF DVFS patches:
> https://patchwork.kernel.org/patch/2195431/
> https://patchwork.kernel.org/patch/2195421/
> https://patchwork.kernel.org/patch/2195451/
> https://patchwork.kernel.org/patch/2195441/
> https://patchwork.kernel.org/patch/2195461/
> [4] http://marc.info/?t=136388745000001&r=1&w=2
>
> Version 5 is now based on master since all requisite for-next branches have been merged.
> 	master 5af43c2 Merge branch 'akpm' (incoming from Andrew)
>
> Version 4 is also available at:
> 	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v5
> 	git link: git://github.com/nmenon/linux-2.6-playground.git
> 	branch: cpufreq-cpu0-omap-all-v5
>
> Test coverage:
> 	test script:  http://pastebin.com/GsavxiDe
> 	(note - to allow testing, I followed the suggestion in https://lkml.org/lkml/2013/5/8/19 )
>
> Platforms verified:
> 	beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/zANKsYBp
> 	beagleboard (rev C1D) - OMAP3430 compatible
> 		- DT enabled boot:  http://pastebin.com/q4qZYVaK
> 		- No DT enabled boot: http://pastebin.com/c1CbQmV5
> 	omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/ibUABcA0
> 	SDP4430 -(OMAP4430 ES2.2) - http://pastebin.com/wYwUc3fU
> 	Pandaboard-ES -(OMAP4460 ES1.1) - http://pastebin.com/FB2RiFp2
>
> Nishanth Menon (6):
>   clk: OMAP: introduce device tree binding to kernel clock data
> [Clk driver probably belongs to mike's tree?]
>   ARM: dts: OMAP3: add clock nodes for CPU
>   ARM: dts: OMAP4: add clock nodes for CPU
>   ARM: dts: AM33XX: add clock nodes for CPU
> [The above probably belong to Benoit's tree]
>   ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init
>   ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot
> [The above probably belong to Kevin/Tony's tree]
>
>  .../devicetree/bindings/clock/omap-clock.txt       |   40 +++++++++
>  arch/arm/boot/dts/am33xx.dtsi                      |    7 ++
>  arch/arm/boot/dts/omap3.dtsi                       |    7 ++
>  arch/arm/boot/dts/omap4.dtsi                       |    7 ++
>  arch/arm/mach-omap2/board-generic.c                |    1 +
>  arch/arm/mach-omap2/cclock33xx_data.c              |    1 -
>  arch/arm/mach-omap2/common.h                       |    1 +
>  arch/arm/mach-omap2/io.c                           |    6 ++
>  arch/arm/mach-omap2/pm.c                           |   11 ++-
>  drivers/clk/Makefile                               |    1 +
>  drivers/clk/omap/Makefile                          |    1 +
>  drivers/clk/omap/clk.c                             |   91 ++++++++++++++++++++
>  12 files changed, 170 insertions(+), 4 deletions(-)
>  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
>
> Regards,
> Nishanth Menon

[PATCH V5 0/6] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[Nishanth Menon]

fixing Benoit's mail ID.
On 10/03/2013 11:43 AM, Kevin Hilman wrote:
> Hi Nishanth,
> 
> Nishanth Menon <nm@ti.com> writes:
> 
>> The following version 5 of the series arose from trying to use
>> BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0.
>> This series enables the generic cpufreq-cpu0 driver to be used in
>> device tree enabled boot while maintaining support of the legacy
>> omap-cpufreq driver when used in non device tree enabled boot.
> 
> What's the status of this series?  Is it still waiting on the clock DT
> changes?

yes - i do have a new series lined up at the moment here[1] - trying
to ensure everything is dandy before public post. ofcourse, we'd like
to ensure we have feedback on tero's series[2]. I am now working on
ensuring ABB regulator[3](again depends on Tero's series) fits on top
of Mike's voltage notifier series[4]

So, yep, everything is blocked due to lack of feedback on Tero's
series [2].

[1]
https://github.com/nmenon/linux-2.6-playground/commits/devel/cpufreq-cpu0
[2] http://marc.info/?t=138009899400001&r=1&w=2
[3]
https://github.com/nmenon/linux-2.6-playground/commits/push/abb-regulator-dts
[4]
http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=shortlog;h=refs/heads/clk-next-volt
-- 
Regards,
Nishanth Menon

[PATCH V5 0/6] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> fixing Benoit's mail ID.
> On 10/03/2013 11:43 AM, Kevin Hilman wrote:
>> Hi Nishanth,
>> 
>> Nishanth Menon <nm@ti.com> writes:
>> 
>>> The following version 5 of the series arose from trying to use
>>> BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0.
>>> This series enables the generic cpufreq-cpu0 driver to be used in
>>> device tree enabled boot while maintaining support of the legacy
>>> omap-cpufreq driver when used in non device tree enabled boot.
>> 
>> What's the status of this series?  Is it still waiting on the clock DT
>> changes?
>
> yes - i do have a new series lined up at the moment here[1] - trying
> to ensure everything is dandy before public post. ofcourse, we'd like
> to ensure we have feedback on tero's series[2]. I am now working on
> ensuring ABB regulator[3](again depends on Tero's series) fits on top
> of Mike's voltage notifier series[4]
>
> So, yep, everything is blocked due to lack of feedback on Tero's
> series [2].

OK, thanks for the update. 

Kevin