[PATCH v2 0/3] ARM: shmobile: kzm9d: migrate to common clock framework with DT

[PATCH v2 0/3] ARM: shmobile: kzm9d: migrate to common clock framework with DT

[takasi-y at ops.dti.ne.jp]

This patch series makes kzm9d to move to new clk implementation
 based on the common clock framework and device tree, when configured
 as a part of multi-platform.

These patches do not remove sh-clkfwk version, even on emev2.
Non multi-platform configuration still uses sh-clkfwk.

Should be applied and compiled on
 kernel/git/horms/renesas.git tag:renesas-devel-20131008

Confirmed for boot up to command prompt.
- kzm9d board / multi-platform + kzm9d configuration
- kzm9d board / kzm9d configuration for regression
for compilation
- ape6evm(non-multi-platform) configuration for regression.

Changes since v1:

Generally, simplified, depending on
 [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update
series posted recently by Magnus.

[PATCH 1/6] clocksource: em_sti: convert to clk_prepare/unprepare
[PATCH 2/6] serial8250-em: convert to clk_prepare/unprepare
Removed because the new base includes it.
Thank you for your review, Daniel, Greg, Laurent, and Magnus.

[PATCH 3/6] sh: clkfwk: Select sh-/common- clkfwk alternatively
Removed because "KZM9D Multiplatform update" had made this not needed.

[PATCH v2 1/3] clk: emev2: Add support for emev2 SMU clocks with DT
[PATCH v2 2/3] ARM: shmobile: emev2: Add clock tree description in DT
(was 3/6, 4/6)
Add @unit-address to smu in dts.
Reassemble patches to (.txt + .c) + .dts from .txt + (.c + .dts).
Only used when multi-platform configuration.
Extra blank line removed.

[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework
(was 6/6)
No Kconfig modification because of "KZM9D Multiplatform update".


Takashi YOSHII (3):
  clk: emev2: Add support for emev2 SMU clocks with DT
  ARM: shmobile: emev2: Add clock tree description in DT
  ARM: shmobile: kzm9d: Use common clock framework

 .../devicetree/bindings/clock/emev2-clock.txt      |  98 +++++++++++++++++++
 arch/arm/boot/dts/emev2.dtsi                       |  84 +++++++++++++++++
 arch/arm/mach-shmobile/board-kzm9d-reference.c     |   5 +-

[PATCH v2 1/3] clk: emev2: Add support for emev2 SMU clocks with DT

[takasi-y at ops.dti.ne.jp]

Device tree clock binding document for EMMA Mobile EV2 SMU,
And Common clock framework based implementation of it.
Following nodes are defined to describe clock tree.
- renesas,emev2-smu
- renesas,emev2-smu-clkdiv
- renesas,emev2-smu-gclk

These bindings are designed manually based on
 19UH0037EJ1000_SMU : System Management Unit User's Manual

So far, reparent is not implemented, and is fixed to index #0.
Clock tree description is not included, and should be provided
by device-tree.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 .../devicetree/bindings/clock/emev2-clock.txt      |  98 +++++++++++++++++++
 drivers/clk/Makefile                               |   1 +
 drivers/clk/shmobile/Makefile                      |   3 +
 drivers/clk/shmobile/clk-emev2.c                   | 104 +++++++++++++++++++++
 4 files changed, 206 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/emev2-clock.txt
 create mode 100644 drivers/clk/shmobile/Makefile
 create mode 100644 drivers/clk/shmobile/clk-emev2.c

diff --git a/Documentation/devicetree/bindings/clock/emev2-clock.txt b/Documentation/devicetree/bindings/clock/emev2-clock.txt
new file mode 100644
index 0000000..60bbb1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/emev2-clock.txt
@@ -0,0 +1,98 @@
+Device tree Clock bindings for Renesas EMMA Mobile EV2
+
+This binding uses the common clock binding.
+
+* SMU
+System Management Unit described in user's manual R19UH0037EJ1000_SMU.
+This is not a clock provider, but clocks under SMU depend on it.
+
+Required properties:
+- compatible: Should be "renesas,emev2-smu"
+- reg: Address and Size of SMU registers
+
+* SMU_CLKDIV
+Function block with an input mux and a divider, which corresponds to
+"Serial clock generator" in fig."Clock System Overview" of the manual,
+and "xxx frequency division setting register" (XXXCLKDIV) registers.
+This makes internal (neither input nor output) clock that is provided
+to input of xxxGCLK block.
+
+Required properties:
+- compatible: Should be "renesas,emev2-smu-clkdiv"
+- reg: Byte offset from SMU base and Bit position in the register
+- clocks: Parent clocks. Input clocks as described in clock-bindings.txt
+- #clock-cells: Should be <0>
+
+* SMU_GCLK
+Clock gating node shown as "Clock stop processing block" in the
+fig."Clock System Overview" of the manual.
+Registers are "xxx clock gate control register" (XXXGCLKCTRL).
+
+Required properties:
+- compatible: Should be "renesas,emev2-smu-gclk"
+- reg: Byte offset from SMU base and Bit position in the register
+- clocks: Input clock as described in clock-bindings.txt
+- #clock-cells: Should be <0>
+
+Example of provider:
+
+usia_u0_sclkdiv: usia_u0_sclkdiv {
+	compatible = "renesas,emev2-smu-clkdiv";
+	reg = <0x610 0>;
+	clocks = <&pll3_fo>, <&pll4_fo>, <&pll1_fo>, <&osc1_fo>;
+	#clock-cells = <0>;
+};
+
+usia_u0_sclk: usia_u0_sclk {
+	compatible = "renesas,emev2-smu-gclk";
+	reg = <0x4a0 1>;
+	clocks = <&usia_u0_sclkdiv>;
+	#clock-cells = <0>;
+};
+
+Example of consumer:
+
+uart at e1020000 {
+	compatible = "renesas,em-uart";
+	reg = <0xe1020000 0x38>;
+	interrupts = <0 8 0>;
+	clocks = <&usia_u0_sclk>;
+	clock-names = "sclk";
+};
+
+Example of clock-tree description:
+
+ This describes a clock path in the clock tree
+  c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk
+
+smu at e0110000 {
+	compatible = "renesas,emev2-smu";
+	reg = <0xe0110000 0x10000>;
+	#address-cells = <2>;
+	#size-cells = <0>;
+
+	c32ki: c32ki {
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+		#clock-cells = <0>;
+	};
+	pll3_fo: pll3_fo {
+		compatible = "fixed-factor-clock";
+		clocks = <&c32ki>;
+		clock-div = <1>;
+		clock-mult = <7000>;
+		#clock-cells = <0>;
+	};
+	usia_u0_sclkdiv: usia_u0_sclkdiv {
+		compatible = "renesas,emev2-smu-clkdiv";
+		reg = <0x610 0>;
+		clocks = <&pll3_fo>;
+		#clock-cells = <0>;
+	};
+	usia_u0_sclk: usia_u0_sclk {
+		compatible = "renesas,emev2-smu-gclk";
+		reg = <0x4a0 1>;
+		clocks = <&usia_u0_sclkdiv>;
+		#clock-cells = <0>;
+	};
+};
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 7b11106..d25da26 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
 obj-$(CONFIG_ARCH_ZYNQ)		+= zynq/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
 obj-$(CONFIG_PLAT_SAMSUNG)	+= samsung/
+obj-$(CONFIG_ARCH_SHMOBILE_MULTI)	+= shmobile/
 
 obj-$(CONFIG_X86)		+= x86/
 
diff --git a/drivers/clk/shmobile/Makefile b/drivers/clk/shmobile/Makefile
new file mode 100644
index 0000000..2240730
--- /dev/null
+++ b/drivers/clk/shmobile/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_ARCH_EMEV2)	+= clk-emev2.o
+# for emply built-in.o
+obj-n	:= dummy
diff --git a/drivers/clk/shmobile/clk-emev2.c b/drivers/clk/shmobile/clk-emev2.c
new file mode 100644
index 0000000..6c7c929
--- /dev/null
+++ b/drivers/clk/shmobile/clk-emev2.c
@@ -0,0 +1,104 @@
+/*
+ * EMMA Mobile EV2 common clock framework support
+ *
+ * Copyright (C) 2013 Takashi Yoshii <takashi.yoshii.ze@renesas.com>
+ * Copyright (C) 2012 Magnus Damm
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+/* EMEV2 SMU registers */
+#define USIAU0_RSTCTRL 0x094
+#define USIBU1_RSTCTRL 0x0ac
+#define USIBU2_RSTCTRL 0x0b0
+#define USIBU3_RSTCTRL 0x0b4
+#define STI_RSTCTRL 0x124
+#define STI_CLKSEL 0x688
+
+static DEFINE_SPINLOCK(lock);
+
+/* not pretty, but hey */
+void __iomem *smu_base;
+
+static void __init emev2_smu_write(unsigned long value, int offs)
+{
+	BUG_ON(!smu_base || (offs >= PAGE_SIZE));
+	writel_relaxed(value, smu_base + offs);
+}
+
+static const struct of_device_id smu_id[] __initconst = {
+	{ .compatible = "renesas,emev2-smu", },
+	{},
+};
+
+static void __init emev2_smu_init(void)
+{
+	struct device_node *np;
+
+	np = of_find_matching_node(NULL, smu_id);
+	BUG_ON(!np);
+	smu_base = of_iomap(np, 0);
+	BUG_ON(!smu_base);
+	of_node_put(np);
+
+	/* setup STI timer to run on 32.768 kHz and deassert reset */
+	emev2_smu_write(0, STI_CLKSEL);
+	emev2_smu_write(1, STI_RSTCTRL);
+
+	/* deassert reset for UART0->UART3 */
+	emev2_smu_write(2, USIAU0_RSTCTRL);
+	emev2_smu_write(2, USIBU1_RSTCTRL);
+	emev2_smu_write(2, USIBU2_RSTCTRL);
+	emev2_smu_write(2, USIBU3_RSTCTRL);
+}
+
+static void __init emev2_smu_clkdiv_init(struct device_node *np)
+{
+	u32 reg[2];
+	struct clk *clk;
+	const char *parent_name = of_clk_get_parent_name(np, 0);
+	if (WARN_ON(of_property_read_u32_array(np, "reg", reg, 2)))
+		return;
+	if (!smu_base)
+		emev2_smu_init();
+	clk = clk_register_divider(NULL, np->name, parent_name, 0,
+				   smu_base + reg[0], reg[1], 8, 0, &lock);
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	clk_register_clkdev(clk, np->name, NULL);
+	pr_debug("## %s %s %p\n", __func__, np->name, clk);
+}
+CLK_OF_DECLARE(emev2_smu_clkdiv, "renesas,emev2-smu-clkdiv",
+		emev2_smu_clkdiv_init);
+
+static void __init emev2_smu_gclk_init(struct device_node *np)
+{
+	u32 reg[2];
+	struct clk *clk;
+	const char *parent_name = of_clk_get_parent_name(np, 0);
+	if (WARN_ON(of_property_read_u32_array(np, "reg", reg, 2)))
+		return;
+	if (!smu_base)
+		emev2_smu_init();
+	clk = clk_register_gate(NULL, np->name, parent_name, 0,
+				smu_base + reg[0], reg[1], 0, &lock);
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	clk_register_clkdev(clk, np->name, NULL);
+	pr_debug("## %s %s %p\n", __func__, np->name, clk);
+}
+CLK_OF_DECLARE(emev2_smu_gclk, "renesas,emev2-smu-gclk", emev2_smu_gclk_init);
-- 
1.8.1.5

[PATCH v2 1/3] clk: emev2: Add support for emev2 SMU clocks with DT

[Magnus Damm]

On Tue, Oct 8, 2013 at 2:32 PM,  <takasi-y@ops.dti.ne.jp> wrote:
> Device tree clock binding document for EMMA Mobile EV2 SMU,
> And Common clock framework based implementation of it.
> Following nodes are defined to describe clock tree.
> - renesas,emev2-smu
> - renesas,emev2-smu-clkdiv
> - renesas,emev2-smu-gclk
>
> These bindings are designed manually based on
>  19UH0037EJ1000_SMU : System Management Unit User's Manual
>
> So far, reparent is not implemented, and is fixed to index #0.
> Clock tree description is not included, and should be provided
> by device-tree.
>
> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> ---
>  .../devicetree/bindings/clock/emev2-clock.txt      |  98 +++++++++++++++++++
>  drivers/clk/Makefile                               |   1 +
>  drivers/clk/shmobile/Makefile                      |   3 +
>  drivers/clk/shmobile/clk-emev2.c                   | 104 +++++++++++++++++++++
>  4 files changed, 206 insertions(+)

Thanks for cleaning up the Makefile bits, Yoshii-san.

This patch and the bindings look fine to me from a SoC point of view.
Using these together with the topology information in emev2.dtsi makes
it possible for us to use CCF and multiplatform as expected on the
EMEV2 SoC.

Acked-by: Magnus Damm <damm@opensource.se>

[PATCH v2 1/3] clk: emev2: Add support for emev2 SMU clocks with DT

[Simon Horman]

On Tue, Oct 08, 2013 at 02:58:08PM +0900, Magnus Damm wrote:
> On Tue, Oct 8, 2013 at 2:32 PM,  <takasi-y@ops.dti.ne.jp> wrote:
> > Device tree clock binding document for EMMA Mobile EV2 SMU,
> > And Common clock framework based implementation of it.
> > Following nodes are defined to describe clock tree.
> > - renesas,emev2-smu
> > - renesas,emev2-smu-clkdiv
> > - renesas,emev2-smu-gclk
> >
> > These bindings are designed manually based on
> >  19UH0037EJ1000_SMU : System Management Unit User's Manual
> >
> > So far, reparent is not implemented, and is fixed to index #0.
> > Clock tree description is not included, and should be provided
> > by device-tree.
> >
> > Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> > ---
> >  .../devicetree/bindings/clock/emev2-clock.txt      |  98 +++++++++++++++++++
> >  drivers/clk/Makefile                               |   1 +
> >  drivers/clk/shmobile/Makefile                      |   3 +
> >  drivers/clk/shmobile/clk-emev2.c                   | 104 +++++++++++++++++++++
> >  4 files changed, 206 insertions(+)
> 
> Thanks for cleaning up the Makefile bits, Yoshii-san.
> 
> This patch and the bindings look fine to me from a SoC point of view.
> Using these together with the topology information in emev2.dtsi makes
> it possible for us to use CCF and multiplatform as expected on the
> EMEV2 SoC.
> 
> Acked-by: Magnus Damm <damm@opensource.se>

Thanks. I will send a pull request for this change to Mike Turquette.

[PATCH v2 1/3] clk: emev2: Add support for emev2 SMU clocks with DT

[Ben Dooks]

On 09/10/13 05:38, Simon Horman wrote:
> On Tue, Oct 08, 2013 at 02:58:08PM +0900, Magnus Damm wrote:
>> On Tue, Oct 8, 2013 at 2:32 PM,<takasi-y@ops.dti.ne.jp>  wrote:
>>> Device tree clock binding document for EMMA Mobile EV2 SMU,
>>> And Common clock framework based implementation of it.
>>> Following nodes are defined to describe clock tree.
>>> - renesas,emev2-smu
>>> - renesas,emev2-smu-clkdiv
>>> - renesas,emev2-smu-gclk
>>>
>>> These bindings are designed manually based on
>>>   19UH0037EJ1000_SMU : System Management Unit User's Manual
>>>
>>> So far, reparent is not implemented, and is fixed to index #0.
>>> Clock tree description is not included, and should be provided
>>> by device-tree.
>>>
>>> Signed-off-by: Takashi Yoshii<takasi-y@ops.dti.ne.jp>
>>> ---
>>>   .../devicetree/bindings/clock/emev2-clock.txt      |  98 +++++++++++++++++++
>>>   drivers/clk/Makefile                               |   1 +
>>>   drivers/clk/shmobile/Makefile                      |   3 +
>>>   drivers/clk/shmobile/clk-emev2.c                   | 104 +++++++++++++++++++++
>>>   4 files changed, 206 insertions(+)
>>
>> Thanks for cleaning up the Makefile bits, Yoshii-san.
>>
>> This patch and the bindings look fine to me from a SoC point of view.
>> Using these together with the topology information in emev2.dtsi makes
>> it possible for us to use CCF and multiplatform as expected on the
>> EMEV2 SoC.
>>
>> Acked-by: Magnus Damm<damm@opensource.se>
>
> Thanks. I will send a pull request for this change to Mike Turquette.

I was going to comment on the last set but forgot.

My set dealt with the following issues

This set does not have any of the module clocks, which I added
in mine. This is also an issue with the clock and serial drivers
which do not ensure the bus/module clocks have been enabled in
the driver.

Mine also dealt with the multiple parents that some of these
clocks have.

I can try and re-post tonight for discussion.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

[PATCH v2 2/3] ARM: shmobile: emev2: Add clock tree description in DT

[takasi-y at ops.dti.ne.jp]

Add minimum clock tree description to .dts file.
This provides same set of clocks as current sh-clkfwk version .c
code does.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 arch/arm/boot/dts/emev2.dtsi | 84 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 84 insertions(+)

diff --git a/arch/arm/boot/dts/emev2.dtsi b/arch/arm/boot/dts/emev2.dtsi
index 9063a44..df1d4cd 100644
--- a/arch/arm/boot/dts/emev2.dtsi
+++ b/arch/arm/boot/dts/emev2.dtsi
@@ -52,34 +52,118 @@
 			     <0 121 4>;
 	};
 
+	smu at e0110000 {
+		compatible = "renesas,emev2-smu";
+		reg = <0xe0110000 0x10000>;
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		c32ki: c32ki {
+			compatible = "fixed-clock";
+			clock-frequency = <32768>;
+			#clock-cells = <0>;
+		};
+		pll3_fo: pll3_fo {
+			compatible = "fixed-factor-clock";
+			clocks = <&c32ki>;
+			clock-div = <1>;
+			clock-mult = <7000>;
+			#clock-cells = <0>;
+		};
+		usia_u0_sclkdiv: usia_u0_sclkdiv {
+			compatible = "renesas,emev2-smu-clkdiv";
+			reg = <0x610 0>;
+			clocks = <&pll3_fo>;
+			#clock-cells = <0>;
+		};
+		usib_u1_sclkdiv: usib_u1_sclkdiv {
+			compatible = "renesas,emev2-smu-clkdiv";
+			reg = <0x65c 0>;
+			clocks = <&pll3_fo>;
+			#clock-cells = <0>;
+		};
+		usib_u2_sclkdiv: usib_u2_sclkdiv {
+			compatible = "renesas,emev2-smu-clkdiv";
+			reg = <0x65c 16>;
+			clocks = <&pll3_fo>;
+			#clock-cells = <0>;
+		};
+		usib_u3_sclkdiv: usib_u3_sclkdiv {
+			compatible = "renesas,emev2-smu-clkdiv";
+			reg = <0x660 0>;
+			clocks = <&pll3_fo>;
+			#clock-cells = <0>;
+		};
+		usia_u0_sclk: usia_u0_sclk {
+			compatible = "renesas,emev2-smu-gclk";
+			reg = <0x4a0 1>;
+			clocks = <&usia_u0_sclkdiv>;
+			#clock-cells = <0>;
+		};
+		usib_u1_sclk: usib_u1_sclk {
+			compatible = "renesas,emev2-smu-gclk";
+			reg = <0x4b8 1>;
+			clocks = <&usib_u1_sclkdiv>;
+			#clock-cells = <0>;
+		};
+		usib_u2_sclk: usib_u2_sclk {
+			compatible = "renesas,emev2-smu-gclk";
+			reg = <0x4bc 1>;
+			clocks = <&usib_u2_sclkdiv>;
+			#clock-cells = <0>;
+		};
+		usib_u3_sclk: usib_u3_sclk {
+			compatible = "renesas,emev2-smu-gclk";
+			reg = <0x4c0 1>;
+			clocks = <&usib_u3_sclkdiv>;
+			#clock-cells = <0>;
+		};
+		sti_sclk: sti_sclk {
+			compatible = "renesas,emev2-smu-gclk";
+			reg = <0x528 1>;
+			clocks = <&c32ki>;
+			#clock-cells = <0>;
+		};
+	};
+
 	sti at e0180000 {
 		compatible = "renesas,em-sti";
 		reg = <0xe0180000 0x54>;
 		interrupts = <0 125 0>;
+		clocks = <&sti_sclk>;
+		clock-names = "sclk";
 	};
 
 	uart at e1020000 {
 		compatible = "renesas,em-uart";
 		reg = <0xe1020000 0x38>;
 		interrupts = <0 8 0>;
+		clocks = <&usia_u0_sclk>;
+		clock-names = "sclk";
 	};
 
 	uart at e1030000 {
 		compatible = "renesas,em-uart";
 		reg = <0xe1030000 0x38>;
 		interrupts = <0 9 0>;
+		clocks = <&usib_u1_sclk>;
+		clock-names = "sclk";
 	};
 
 	uart at e1040000 {
 		compatible = "renesas,em-uart";
 		reg = <0xe1040000 0x38>;
 		interrupts = <0 10 0>;
+		clocks = <&usib_u2_sclk>;
+		clock-names = "sclk";
 	};
 
 	uart at e1050000 {
 		compatible = "renesas,em-uart";
 		reg = <0xe1050000 0x38>;
 		interrupts = <0 11 0>;
+		clocks = <&usib_u3_sclk>;
+		clock-names = "sclk";
 	};
 
 	gpio0: gpio at e0050000 {
-- 
1.8.1.5

[PATCH v2 2/3] ARM: shmobile: emev2: Add clock tree description in DT

[Magnus Damm]

On Tue, Oct 8, 2013 at 2:33 PM,  <takasi-y@ops.dti.ne.jp> wrote:
> Add minimum clock tree description to .dts file.
> This provides same set of clocks as current sh-clkfwk version .c
> code does.
>
> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> ---
>  arch/arm/boot/dts/emev2.dtsi | 84 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 84 insertions(+)

Looking good, thanks Yoshii-san!

Acked-by: Magnus Damm <damm@opensource.se>

[PATCH v2 2/3] ARM: shmobile: emev2: Add clock tree description in DT

[Simon Horman]

On Tue, Oct 08, 2013 at 02:54:26PM +0900, Magnus Damm wrote:
> On Tue, Oct 8, 2013 at 2:33 PM,  <takasi-y@ops.dti.ne.jp> wrote:
> > Add minimum clock tree description to .dts file.
> > This provides same set of clocks as current sh-clkfwk version .c
> > code does.
> >
> > Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

Thanks.

I plan to add this patch to a new topic branch,
topic/emev2-common-clock, in the renesas tree and
queue it up from there for inclusion in mainline
if/when the first patch of this series is accepted
by Mike Turquette.

[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework

[takasi-y at ops.dti.ne.jp]

Use common clock framework version of clock
 drivers/clk/shmobile/clk-emev2.c
instead of sh-clkfwk version
 arch/arm/mach-shmobile/clock-emev2.c
when it is configured as a part of multi-platform.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
---
 arch/arm/mach-shmobile/board-kzm9d-reference.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-kzm9d-reference.c b/arch/arm/mach-shmobile/board-kzm9d-reference.c
index 054d8d5..853003c 100644
--- a/arch/arm/mach-shmobile/board-kzm9d-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9d-reference.c
@@ -20,15 +20,14 @@
 
 #include <linux/init.h>
 #include <linux/of_platform.h>
+#include <linux/clk-provider.h>
 #include <mach/emev2.h>
 #include <mach/common.h>
 #include <asm/mach/arch.h>
 
 static void __init kzm9d_add_standard_devices(void)
 {
-	if (!IS_ENABLED(CONFIG_COMMON_CLK))
-		emev2_clock_init();
-
+	of_clk_init(NULL);
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-- 
1.8.1.5

[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework

[Magnus Damm]

On Tue, Oct 8, 2013 at 2:34 PM,  <takasi-y@ops.dti.ne.jp> wrote:
> Use common clock framework version of clock
>  drivers/clk/shmobile/clk-emev2.c
> instead of sh-clkfwk version
>  arch/arm/mach-shmobile/clock-emev2.c
> when it is configured as a part of multi-platform.
>
> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> ---
>  arch/arm/mach-shmobile/board-kzm9d-reference.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-kzm9d-reference.c b/arch/arm/mach-shmobile/board-kzm9d-reference.c
> index 054d8d5..853003c 100644
> --- a/arch/arm/mach-shmobile/board-kzm9d-reference.c
> +++ b/arch/arm/mach-shmobile/board-kzm9d-reference.c
> @@ -20,15 +20,14 @@
>
>  #include <linux/init.h>
>  #include <linux/of_platform.h>
> +#include <linux/clk-provider.h>
>  #include <mach/emev2.h>
>  #include <mach/common.h>
>  #include <asm/mach/arch.h>
>
>  static void __init kzm9d_add_standard_devices(void)
>  {
> -       if (!IS_ENABLED(CONFIG_COMMON_CLK))
> -               emev2_clock_init();
> -
> +       of_clk_init(NULL);

Hi Yoshii-san,

Thanks, this looks very good. It is the correct way now when
renesas-devel-20131008 includes the following series:
[PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update

Acked-by: Magnus Damm <damm@opensource.se>

Cheers,

/ magnus

[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework

[Simon Horman]

On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y at ops.dti.ne.jp wrote:
> Use common clock framework version of clock
>  drivers/clk/shmobile/clk-emev2.c
> instead of sh-clkfwk version
>  arch/arm/mach-shmobile/clock-emev2.c
> when it is configured as a part of multi-platform.
> 
> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

Thanks.

I plan to add this patch to a new topic branch,
topic/emev2-common-clock, in the renesas tree and
queue it up from there for inclusion in mainline
if/when the first patch of this series is accepted
by Mike Turquette.

[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework

[Magnus Damm]

Hi Simon,

On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote:
> On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y at ops.dti.ne.jp wrote:
>> Use common clock framework version of clock
>>  drivers/clk/shmobile/clk-emev2.c
>> instead of sh-clkfwk version
>>  arch/arm/mach-shmobile/clock-emev2.c
>> when it is configured as a part of multi-platform.
>>
>> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
>
> Thanks.
>
> I plan to add this patch to a new topic branch,
> topic/emev2-common-clock, in the renesas tree and
> queue it up from there for inclusion in mainline
> if/when the first patch of this series is accepted
> by Mike Turquette.

Thanks for picking up patches, Simon.

I think you can simply merge this patch after the following series:

[PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update

There are no build time dependencies on patch 1 and 2 so this patch
can be merged independently. Regarding run-time operation, the
multiplatform series above makes KZM9D DT reference only build for
multiplatform, and in such case CCF is required.

So if you want to keep KZM9D DT reference working until Mike Turquette
accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
have been merged.

Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
Multiplatform update" before the EMEV2 CCF bits, but if so you may as
well merge this patch as well IMO. This
multiplatform-update-series-merge-before-CCF plan will result in
untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
fine with me.

Cheers,

/ magnus

[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework

[Simon Horman]

On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y at ops.dti.ne.jp wrote:
> >> Use common clock framework version of clock
> >>  drivers/clk/shmobile/clk-emev2.c
> >> instead of sh-clkfwk version
> >>  arch/arm/mach-shmobile/clock-emev2.c
> >> when it is configured as a part of multi-platform.
> >>
> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> >
> > Thanks.
> >
> > I plan to add this patch to a new topic branch,
> > topic/emev2-common-clock, in the renesas tree and
> > queue it up from there for inclusion in mainline
> > if/when the first patch of this series is accepted
> > by Mike Turquette.
> 
> Thanks for picking up patches, Simon.
> 
> I think you can simply merge this patch after the following series:
> 
> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update

This is already queued up.

> There are no build time dependencies on patch 1 and 2 so this patch
> can be merged independently. Regarding run-time operation, the
> multiplatform series above makes KZM9D DT reference only build for
> multiplatform, and in such case CCF is required.
> 
> So if you want to keep KZM9D DT reference working until Mike Turquette
> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
> have been merged.
> 
> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
> Multiplatform update" before the EMEV2 CCF bits, but if so you may as
> well merge this patch as well IMO. This
> multiplatform-update-series-merge-before-CCF plan will result in
> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
> fine with me.

I am mainly concerned that the bindings may change before
they are finally merged. And I thought it would be nice to avoid
having to fix up the usage of the bindings if they change.

But I'm happy to just queue-up patches 2 and 3 of this series
now if you prefer.

[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework

[Magnus Damm]

Hi Simon,

On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote:
>> Hi Simon,
>>
>> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote:
>> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y at ops.dti.ne.jp wrote:
>> >> Use common clock framework version of clock
>> >>  drivers/clk/shmobile/clk-emev2.c
>> >> instead of sh-clkfwk version
>> >>  arch/arm/mach-shmobile/clock-emev2.c
>> >> when it is configured as a part of multi-platform.
>> >>
>> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
>> >
>> > Thanks.
>> >
>> > I plan to add this patch to a new topic branch,
>> > topic/emev2-common-clock, in the renesas tree and
>> > queue it up from there for inclusion in mainline
>> > if/when the first patch of this series is accepted
>> > by Mike Turquette.
>>
>> Thanks for picking up patches, Simon.
>>
>> I think you can simply merge this patch after the following series:
>>
>> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update
>
> This is already queued up.

Yes, I know, thanks for that. I tried to explain the dependency in the
00/00 cover letter but I will try to be more clear next time!

>> There are no build time dependencies on patch 1 and 2 so this patch
>> can be merged independently. Regarding run-time operation, the
>> multiplatform series above makes KZM9D DT reference only build for
>> multiplatform, and in such case CCF is required.
>>
>> So if you want to keep KZM9D DT reference working until Mike Turquette
>> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
>> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
>> have been merged.
>>
>> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
>> Multiplatform update" before the EMEV2 CCF bits, but if so you may as
>> well merge this patch as well IMO. This
>> multiplatform-update-series-merge-before-CCF plan will result in
>> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
>> fine with me.
>
> I am mainly concerned that the bindings may change before
> they are finally merged. And I thought it would be nice to avoid
> having to fix up the usage of the bindings if they change.

Sure, but the code in this patch looks like it simply starts DT CCF
probing regardless of what the bindings look like. So I don't think
you will have to worry about actual bindings detail.

> But I'm happy to just queue-up patches 2 and 3 of this series
> now if you prefer.

Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =)

/ magnus

[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework

[Simon Horman]

On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote:
> >> Hi Simon,
> >>
> >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote:
> >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y at ops.dti.ne.jp wrote:
> >> >> Use common clock framework version of clock
> >> >>  drivers/clk/shmobile/clk-emev2.c
> >> >> instead of sh-clkfwk version
> >> >>  arch/arm/mach-shmobile/clock-emev2.c
> >> >> when it is configured as a part of multi-platform.
> >> >>
> >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> >> >
> >> > Thanks.
> >> >
> >> > I plan to add this patch to a new topic branch,
> >> > topic/emev2-common-clock, in the renesas tree and
> >> > queue it up from there for inclusion in mainline
> >> > if/when the first patch of this series is accepted
> >> > by Mike Turquette.
> >>
> >> Thanks for picking up patches, Simon.
> >>
> >> I think you can simply merge this patch after the following series:
> >>
> >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update
> >
> > This is already queued up.
> 
> Yes, I know, thanks for that. I tried to explain the dependency in the
> 00/00 cover letter but I will try to be more clear next time!
> 
> >> There are no build time dependencies on patch 1 and 2 so this patch
> >> can be merged independently. Regarding run-time operation, the
> >> multiplatform series above makes KZM9D DT reference only build for
> >> multiplatform, and in such case CCF is required.
> >>
> >> So if you want to keep KZM9D DT reference working until Mike Turquette
> >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
> >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
> >> have been merged.
> >>
> >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
> >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as
> >> well merge this patch as well IMO. This
> >> multiplatform-update-series-merge-before-CCF plan will result in
> >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
> >> fine with me.
> >
> > I am mainly concerned that the bindings may change before
> > they are finally merged. And I thought it would be nice to avoid
> > having to fix up the usage of the bindings if they change.
> 
> Sure, but the code in this patch looks like it simply starts DT CCF
> probing regardless of what the bindings look like. So I don't think
> you will have to worry about actual bindings detail.
> 
> > But I'm happy to just queue-up patches 2 and 3 of this series
> > now if you prefer.
> 
> Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =)

Thanks, I understand now.

I'll queue-up 3/3.

[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework

[Simon Horman]

On Wed, Oct 09, 2013 at 07:39:18PM +0900, Simon Horman wrote:
> On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote:
> > Hi Simon,
> > 
> > On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote:
> > > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote:
> > >> Hi Simon,
> > >>
> > >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote:
> > >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y at ops.dti.ne.jp wrote:
> > >> >> Use common clock framework version of clock
> > >> >>  drivers/clk/shmobile/clk-emev2.c
> > >> >> instead of sh-clkfwk version
> > >> >>  arch/arm/mach-shmobile/clock-emev2.c
> > >> >> when it is configured as a part of multi-platform.
> > >> >>
> > >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> > >> >
> > >> > Thanks.
> > >> >
> > >> > I plan to add this patch to a new topic branch,
> > >> > topic/emev2-common-clock, in the renesas tree and
> > >> > queue it up from there for inclusion in mainline
> > >> > if/when the first patch of this series is accepted
> > >> > by Mike Turquette.
> > >>
> > >> Thanks for picking up patches, Simon.
> > >>
> > >> I think you can simply merge this patch after the following series:
> > >>
> > >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update
> > >
> > > This is already queued up.
> > 
> > Yes, I know, thanks for that. I tried to explain the dependency in the
> > 00/00 cover letter but I will try to be more clear next time!
> > 
> > >> There are no build time dependencies on patch 1 and 2 so this patch
> > >> can be merged independently. Regarding run-time operation, the
> > >> multiplatform series above makes KZM9D DT reference only build for
> > >> multiplatform, and in such case CCF is required.
> > >>
> > >> So if you want to keep KZM9D DT reference working until Mike Turquette
> > >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
> > >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
> > >> have been merged.
> > >>
> > >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
> > >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as
> > >> well merge this patch as well IMO. This
> > >> multiplatform-update-series-merge-before-CCF plan will result in
> > >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
> > >> fine with me.
> > >
> > > I am mainly concerned that the bindings may change before
> > > they are finally merged. And I thought it would be nice to avoid
> > > having to fix up the usage of the bindings if they change.
> > 
> > Sure, but the code in this patch looks like it simply starts DT CCF
> > probing regardless of what the bindings look like. So I don't think
> > you will have to worry about actual bindings detail.
> > 
> > > But I'm happy to just queue-up patches 2 and 3 of this series
> > > now if you prefer.
> > 
> > Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =)
> 
> Thanks, I understand now.
> 
> I'll queue-up 3/3.

Which I did.

Then some time passed...

Mike has accepted my pull-request for patch 1 of this series
and accordingly I have queued-up this patch for v3.14.
It should appear in the devel branch the next time that I push it.

[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework

[Simon Horman]

On Tue, Oct 29, 2013 at 01:42:41PM +0900, Simon Horman wrote:
> On Wed, Oct 09, 2013 at 07:39:18PM +0900, Simon Horman wrote:
> > On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote:
> > > Hi Simon,
> > > 
> > > On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote:
> > > > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote:
> > > >> Hi Simon,
> > > >>
> > > >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote:
> > > >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y at ops.dti.ne.jp wrote:
> > > >> >> Use common clock framework version of clock
> > > >> >>  drivers/clk/shmobile/clk-emev2.c
> > > >> >> instead of sh-clkfwk version
> > > >> >>  arch/arm/mach-shmobile/clock-emev2.c
> > > >> >> when it is configured as a part of multi-platform.
> > > >> >>
> > > >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> > > >> >
> > > >> > Thanks.
> > > >> >
> > > >> > I plan to add this patch to a new topic branch,
> > > >> > topic/emev2-common-clock, in the renesas tree and
> > > >> > queue it up from there for inclusion in mainline
> > > >> > if/when the first patch of this series is accepted
> > > >> > by Mike Turquette.
> > > >>
> > > >> Thanks for picking up patches, Simon.
> > > >>
> > > >> I think you can simply merge this patch after the following series:
> > > >>
> > > >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update
> > > >
> > > > This is already queued up.
> > > 
> > > Yes, I know, thanks for that. I tried to explain the dependency in the
> > > 00/00 cover letter but I will try to be more clear next time!
> > > 
> > > >> There are no build time dependencies on patch 1 and 2 so this patch
> > > >> can be merged independently. Regarding run-time operation, the
> > > >> multiplatform series above makes KZM9D DT reference only build for
> > > >> multiplatform, and in such case CCF is required.
> > > >>
> > > >> So if you want to keep KZM9D DT reference working until Mike Turquette
> > > >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
> > > >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
> > > >> have been merged.
> > > >>
> > > >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
> > > >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as
> > > >> well merge this patch as well IMO. This
> > > >> multiplatform-update-series-merge-before-CCF plan will result in
> > > >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
> > > >> fine with me.
> > > >
> > > > I am mainly concerned that the bindings may change before
> > > > they are finally merged. And I thought it would be nice to avoid
> > > > having to fix up the usage of the bindings if they change.
> > > 
> > > Sure, but the code in this patch looks like it simply starts DT CCF
> > > probing regardless of what the bindings look like. So I don't think
> > > you will have to worry about actual bindings detail.
> > > 
> > > > But I'm happy to just queue-up patches 2 and 3 of this series
> > > > now if you prefer.
> > > 
> > > Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =)
> > 
> > Thanks, I understand now.
> > 
> > I'll queue-up 3/3.
> 
> Which I did.
> 
> Then some time passed...
> 
> Mike has accepted my pull-request for patch 1 of this series
> and accordingly I have queued-up this patch for v3.14.
> It should appear in the devel branch the next time that I push it.

I was mistaken. It was not queued up  for v3.14.
And still has not been queued up.

I have un-queued this patch accordingly.

[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework

[Mike Turquette]

Quoting Simon Horman (2013-12-01 18:25:51)
> On Tue, Oct 29, 2013 at 01:42:41PM +0900, Simon Horman wrote:
> > On Wed, Oct 09, 2013 at 07:39:18PM +0900, Simon Horman wrote:
> > > On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote:
> > > > Hi Simon,
> > > > 
> > > > On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote:
> > > > > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote:
> > > > >> Hi Simon,
> > > > >>
> > > > >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote:
> > > > >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y at ops.dti.ne.jp wrote:
> > > > >> >> Use common clock framework version of clock
> > > > >> >>  drivers/clk/shmobile/clk-emev2.c
> > > > >> >> instead of sh-clkfwk version
> > > > >> >>  arch/arm/mach-shmobile/clock-emev2.c
> > > > >> >> when it is configured as a part of multi-platform.
> > > > >> >>
> > > > >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> > > > >> >
> > > > >> > Thanks.
> > > > >> >
> > > > >> > I plan to add this patch to a new topic branch,
> > > > >> > topic/emev2-common-clock, in the renesas tree and
> > > > >> > queue it up from there for inclusion in mainline
> > > > >> > if/when the first patch of this series is accepted
> > > > >> > by Mike Turquette.
> > > > >>
> > > > >> Thanks for picking up patches, Simon.
> > > > >>
> > > > >> I think you can simply merge this patch after the following series:
> > > > >>
> > > > >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update
> > > > >
> > > > > This is already queued up.
> > > > 
> > > > Yes, I know, thanks for that. I tried to explain the dependency in the
> > > > 00/00 cover letter but I will try to be more clear next time!
> > > > 
> > > > >> There are no build time dependencies on patch 1 and 2 so this patch
> > > > >> can be merged independently. Regarding run-time operation, the
> > > > >> multiplatform series above makes KZM9D DT reference only build for
> > > > >> multiplatform, and in such case CCF is required.
> > > > >>
> > > > >> So if you want to keep KZM9D DT reference working until Mike Turquette
> > > > >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
> > > > >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
> > > > >> have been merged.
> > > > >>
> > > > >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
> > > > >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as
> > > > >> well merge this patch as well IMO. This
> > > > >> multiplatform-update-series-merge-before-CCF plan will result in
> > > > >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
> > > > >> fine with me.
> > > > >
> > > > > I am mainly concerned that the bindings may change before
> > > > > they are finally merged. And I thought it would be nice to avoid
> > > > > having to fix up the usage of the bindings if they change.
> > > > 
> > > > Sure, but the code in this patch looks like it simply starts DT CCF
> > > > probing regardless of what the bindings look like. So I don't think
> > > > you will have to worry about actual bindings detail.
> > > > 
> > > > > But I'm happy to just queue-up patches 2 and 3 of this series
> > > > > now if you prefer.
> > > > 
> > > > Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =)
> > > 
> > > Thanks, I understand now.
> > > 
> > > I'll queue-up 3/3.
> > 
> > Which I did.
> > 
> > Then some time passed...
> > 
> > Mike has accepted my pull-request for patch 1 of this series
> > and accordingly I have queued-up this patch for v3.14.
> > It should appear in the devel branch the next time that I push it.
> 
> I was mistaken. It was not queued up  for v3.14.
> And still has not been queued up.
> 
> I have un-queued this patch accordingly.

I have pulled in the emev2 SMU clock support patch now.

Regards,
Mike

[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework

[Simon Horman]

On Sun, Dec 22, 2013 at 10:41:03PM -0800, Mike Turquette wrote:
> Quoting Simon Horman (2013-12-01 18:25:51)
> > On Tue, Oct 29, 2013 at 01:42:41PM +0900, Simon Horman wrote:
> > > On Wed, Oct 09, 2013 at 07:39:18PM +0900, Simon Horman wrote:
> > > > On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote:
> > > > > Hi Simon,
> > > > > 
> > > > > On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote:
> > > > > > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote:
> > > > > >> Hi Simon,
> > > > > >>
> > > > > >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote:
> > > > > >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y at ops.dti.ne.jp wrote:
> > > > > >> >> Use common clock framework version of clock
> > > > > >> >>  drivers/clk/shmobile/clk-emev2.c
> > > > > >> >> instead of sh-clkfwk version
> > > > > >> >>  arch/arm/mach-shmobile/clock-emev2.c
> > > > > >> >> when it is configured as a part of multi-platform.
> > > > > >> >>
> > > > > >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> > > > > >> >
> > > > > >> > Thanks.
> > > > > >> >
> > > > > >> > I plan to add this patch to a new topic branch,
> > > > > >> > topic/emev2-common-clock, in the renesas tree and
> > > > > >> > queue it up from there for inclusion in mainline
> > > > > >> > if/when the first patch of this series is accepted
> > > > > >> > by Mike Turquette.
> > > > > >>
> > > > > >> Thanks for picking up patches, Simon.
> > > > > >>
> > > > > >> I think you can simply merge this patch after the following series:
> > > > > >>
> > > > > >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update
> > > > > >
> > > > > > This is already queued up.
> > > > > 
> > > > > Yes, I know, thanks for that. I tried to explain the dependency in the
> > > > > 00/00 cover letter but I will try to be more clear next time!
> > > > > 
> > > > > >> There are no build time dependencies on patch 1 and 2 so this patch
> > > > > >> can be merged independently. Regarding run-time operation, the
> > > > > >> multiplatform series above makes KZM9D DT reference only build for
> > > > > >> multiplatform, and in such case CCF is required.
> > > > > >>
> > > > > >> So if you want to keep KZM9D DT reference working until Mike Turquette
> > > > > >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
> > > > > >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
> > > > > >> have been merged.
> > > > > >>
> > > > > >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
> > > > > >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as
> > > > > >> well merge this patch as well IMO. This
> > > > > >> multiplatform-update-series-merge-before-CCF plan will result in
> > > > > >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
> > > > > >> fine with me.
> > > > > >
> > > > > > I am mainly concerned that the bindings may change before
> > > > > > they are finally merged. And I thought it would be nice to avoid
> > > > > > having to fix up the usage of the bindings if they change.
> > > > > 
> > > > > Sure, but the code in this patch looks like it simply starts DT CCF
> > > > > probing regardless of what the bindings look like. So I don't think
> > > > > you will have to worry about actual bindings detail.
> > > > > 
> > > > > > But I'm happy to just queue-up patches 2 and 3 of this series
> > > > > > now if you prefer.
> > > > > 
> > > > > Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =)
> > > > 
> > > > Thanks, I understand now.
> > > > 
> > > > I'll queue-up 3/3.
> > > 
> > > Which I did.
> > > 
> > > Then some time passed...
> > > 
> > > Mike has accepted my pull-request for patch 1 of this series
> > > and accordingly I have queued-up this patch for v3.14.
> > > It should appear in the devel branch the next time that I push it.
> > 
> > I was mistaken. It was not queued up  for v3.14.
> > And still has not been queued up.
> > 
> > I have un-queued this patch accordingly.
> 
> I have pulled in the emev2 SMU clock support patch now.

Thanks

[PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework

[Simon Horman]

On Mon, Dec 23, 2013 at 05:00:36PM +0900, Simon Horman wrote:
> On Sun, Dec 22, 2013 at 10:41:03PM -0800, Mike Turquette wrote:
> > Quoting Simon Horman (2013-12-01 18:25:51)
> > > On Tue, Oct 29, 2013 at 01:42:41PM +0900, Simon Horman wrote:
> > > > On Wed, Oct 09, 2013 at 07:39:18PM +0900, Simon Horman wrote:
> > > > > On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote:
> > > > > > Hi Simon,
> > > > > > 
> > > > > > On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote:
> > > > > > > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote:
> > > > > > >> Hi Simon,
> > > > > > >>
> > > > > > >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote:
> > > > > > >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y at ops.dti.ne.jp wrote:
> > > > > > >> >> Use common clock framework version of clock
> > > > > > >> >>  drivers/clk/shmobile/clk-emev2.c
> > > > > > >> >> instead of sh-clkfwk version
> > > > > > >> >>  arch/arm/mach-shmobile/clock-emev2.c
> > > > > > >> >> when it is configured as a part of multi-platform.
> > > > > > >> >>
> > > > > > >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
> > > > > > >> >
> > > > > > >> > Thanks.
> > > > > > >> >
> > > > > > >> > I plan to add this patch to a new topic branch,
> > > > > > >> > topic/emev2-common-clock, in the renesas tree and
> > > > > > >> > queue it up from there for inclusion in mainline
> > > > > > >> > if/when the first patch of this series is accepted
> > > > > > >> > by Mike Turquette.
> > > > > > >>
> > > > > > >> Thanks for picking up patches, Simon.
> > > > > > >>
> > > > > > >> I think you can simply merge this patch after the following series:
> > > > > > >>
> > > > > > >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update
> > > > > > >
> > > > > > > This is already queued up.
> > > > > > 
> > > > > > Yes, I know, thanks for that. I tried to explain the dependency in the
> > > > > > 00/00 cover letter but I will try to be more clear next time!
> > > > > > 
> > > > > > >> There are no build time dependencies on patch 1 and 2 so this patch
> > > > > > >> can be merged independently. Regarding run-time operation, the
> > > > > > >> multiplatform series above makes KZM9D DT reference only build for
> > > > > > >> multiplatform, and in such case CCF is required.
> > > > > > >>
> > > > > > >> So if you want to keep KZM9D DT reference working until Mike Turquette
> > > > > > >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
> > > > > > >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
> > > > > > >> have been merged.
> > > > > > >>
> > > > > > >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
> > > > > > >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as
> > > > > > >> well merge this patch as well IMO. This
> > > > > > >> multiplatform-update-series-merge-before-CCF plan will result in
> > > > > > >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
> > > > > > >> fine with me.
> > > > > > >
> > > > > > > I am mainly concerned that the bindings may change before
> > > > > > > they are finally merged. And I thought it would be nice to avoid
> > > > > > > having to fix up the usage of the bindings if they change.
> > > > > > 
> > > > > > Sure, but the code in this patch looks like it simply starts DT CCF
> > > > > > probing regardless of what the bindings look like. So I don't think
> > > > > > you will have to worry about actual bindings detail.
> > > > > > 
> > > > > > > But I'm happy to just queue-up patches 2 and 3 of this series
> > > > > > > now if you prefer.
> > > > > > 
> > > > > > Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =)
> > > > > 
> > > > > Thanks, I understand now.
> > > > > 
> > > > > I'll queue-up 3/3.
> > > > 
> > > > Which I did.
> > > > 
> > > > Then some time passed...
> > > > 
> > > > Mike has accepted my pull-request for patch 1 of this series
> > > > and accordingly I have queued-up this patch for v3.14.
> > > > It should appear in the devel branch the next time that I push it.
> > > 
> > > I was mistaken. It was not queued up  for v3.14.
> > > And still has not been queued up.
> > > 
> > > I have un-queued this patch accordingly.
> > 
> > I have pulled in the emev2 SMU clock support patch now.
> 
> Thanks

I have queued up kzm9d this patch again.