[PATCH 1/2 v3] powerpc/fsl: Use new clockgen binding

[Yuantian Tang]

From: Scott Wood 

The driver retains compatibility with old device trees, but we don't
want the old nodes lying around to be copied, or used as a reference
(some of the mux options are incorrect), or even just being clutter.

Signed-off-by: Scott Wood 
Signed-off-by: Tang Yuantian 
---
v3:
  - update the commit message
  - split the dts and driver to different patchset

 arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi |4 +-
 arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi |8 ++--
 arch/powerpc/boot/dts/fsl/b4si-post.dtsi   |   15 -
 arch/powerpc/boot/dts/fsl/p2041si-post.dtsi|   18 --
 arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi |8 ++--
 arch/powerpc/boot/dts/fsl/p3041si-post.dtsi|   18 --
 arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi |8 ++--
 arch/powerpc/boot/dts/fsl/p4080si-post.dtsi|   70 
 arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi |   16 +++---
 arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi |4 +-
 arch/powerpc/boot/dts/fsl/p5040si-post.dtsi|   18 --
 arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi |8 ++--
 arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi |   55 +++
 arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi |   38 +++--
 arch/powerpc/boot/dts/fsl/t1023si-post.dtsi|   16 --
 arch/powerpc/boot/dts/fsl/t102xsi-pre.dtsi |4 +-
 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi|   44 ---
 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi |8 ++--
 arch/powerpc/boot/dts/fsl/t2081si-post.dtsi|   22 
 arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi |8 ++--
 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|   61 -
 arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi |   24 
 22 files changed, 66 insertions(+), 409 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi 
b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
index 88d8423..bb7b9b9 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
@@ -70,14 +70,14 @@
cpu0: PowerPC,e6500@0 {
device_type = "cpu";
reg = <0 1>;
-   clocks = <>;
+   clocks = < 1 0>;
next-level-cache = <_1>;
fsl,portid-mapping = <0x8000>;
};
cpu1: PowerPC,e6500@2 {
device_type = "cpu";
reg = <2 3>;
-   clocks = <>;
+   clocks = < 1 0>;
next-level-cache = <_1>;
fsl,portid-mapping = <0x8000>;
};
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi 
b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
index f3f968c..388ba1b 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
@@ -75,28 +75,28 @@
cpu0: PowerPC,e6500@0 {
device_type = "cpu";
reg = <0 1>;
-   clocks = <>;
+   clocks = < 1 0>;
next-level-cache = <_1>;
fsl,portid-mapping = <0x8000>;
};
cpu1: PowerPC,e6500@2 {
device_type = "cpu";
reg = <2 3>;
-   clocks = <>;
+   clocks = < 1 0>;
next-level-cache = <_1>;
fsl,portid-mapping = <0x8000>;
};
cpu2: PowerPC,e6500@4 {
device_type = "cpu";
reg = <4 5>;
-   clocks = <>;
+   clocks = < 1 0>;
next-level-cache = <_1>;
fsl,portid-mapping = <0x8000>;
};
cpu3: PowerPC,e6500@6 {
device_type = "cpu";
reg = <6 7>;
-   clocks = <>;
+   clocks = < 1 0>;
next-level-cache = <_1>;
fsl,portid-mapping = <0x8000>;
};
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 1b33f51..4f044b4 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -398,21 +398,6 @@
};
 
 /include/ "qoriq-clockgen2.dtsi"
-   clockgen: global-utilities@e1000 {
-   compatible = "fsl,b4-clockgen", "fsl,qoriq-clockgen-2.0";
-   reg = <0xe1000 0x1000>;
-
-   mux0: mux0@0 {
-   #clock-cells = <0>;
-   reg = <0x0 0x4>;
-   compatible = "fsl,qoriq-core-mux-2.0";
-   clocks = < 0>, < 1>, < 2>,
-   

[PATCH 2/2 v3] clk: qoriq: add more compatibles strings

[Yuantian Tang]

Add more SoC compatible strings to support more chips.

Signed-off-by: Yuantian Tang 
---
v3:
  - undo deleting old bindings
  - split the dts and driver to different patchset

 .../devicetree/bindings/clock/qoriq-clock.txt  |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt 
b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
index 97f46ad..c655f28 100644
--- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
+++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
@@ -28,6 +28,12 @@ Required properties:
* "fsl,p4080-clockgen"
* "fsl,p5020-clockgen"
* "fsl,p5040-clockgen"
+   * "fsl,t1023-clockgen"
+   * "fsl,t1024-clockgen"
+   * "fsl,t1040-clockgen"
+   * "fsl,t1042-clockgen"
+   * "fsl,t2080-clockgen"
+   * "fsl,t2081-clockgen"
* "fsl,t4240-clockgen"
* "fsl,b4420-clockgen"
* "fsl,b4860-clockgen"
-- 
1.7.1

[PATCH] powerpc/mpc85xx: fix issues in clock node

[Yuantian Tang]

The compatible string is not correct in the clock node.
The clocks property refers to the wrong node too.
This patch is to fix them.

Signed-off-by: Tang Yuantian 
---
 arch/powerpc/boot/dts/fsl/t1023si-post.dtsi |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
index 4908af5..763caf4 100644
--- a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
@@ -348,7 +348,7 @@
mux0: mux0@0 {
#clock-cells = <0>;
reg = <0x0 4>;
-   compatible = "fsl,core-mux-clock";
+   compatible = "fsl,qoriq-core-mux-2.0";
clocks = < 0>, < 1>;
clock-names = "pll0_0", "pll0_1";
clock-output-names = "cmux0";
@@ -356,9 +356,9 @@
mux1: mux1@20 {
#clock-cells = <0>;
reg = <0x20 4>;
-   compatible = "fsl,core-mux-clock";
-   clocks = < 0>, < 1>;
-   clock-names = "pll0_0", "pll0_1";
+   compatible = "fsl,qoriq-core-mux-2.0";
+   clocks = < 0>, < 1>;
+   clock-names = "pll1_0", "pll1_1";
clock-output-names = "cmux1";
};
};
-- 
1.7.1

RE: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details

[Yuantian Tang]

PING.

Regards,
Yuantian

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Saturday, July 09, 2016 5:07 AM
> To: Michael Turquette <mturque...@baylibre.com>; Russell King
> <li...@armlinux.org.uk>; Stephen Boyd <sb...@codeaurora.org>; Viresh
> Kumar <viresh.ku...@linaro.org>; Rafael J. Wysocki <r...@rjwysocki.net>
> Cc: linux-...@vger.kernel.org; linux...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Yuantian Tang <yuantian.t...@nxp.com>; Yang-Leo Li
> <leoyang...@nxp.com>; Xiaofeng Ren <xiaofeng@nxp.com>
> Subject: Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock
> implementation details
> 
> On Thu, 2016-07-07 at 19:26 -0700, Michael Turquette wrote:
> > Quoting Scott Wood (2016-07-06 21:13:23)
> > >
> > > On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:
> > > >
> > > > Quoting Scott Wood (2016-06-15 23:21:25)
> > > > >
> > > > >
> > > > > -static struct device_node *cpu_to_clk_node(int cpu)
> > > > > +static struct clk *cpu_to_clk(int cpu)
> > > > >  {
> > > > > -   struct device_node *np, *clk_np;
> > > > > +   struct device_node *np;
> > > > > +   struct clk *clk;
> > > > >
> > > > > if (!cpu_present(cpu))
> > > > > return NULL;
> > > > > @@ -112,37 +80,28 @@ static struct device_node
> > > > > *cpu_to_clk_node(int
> > > > > cpu)
> > > > > if (!np)
> > > > > return NULL;
> > > > >
> > > > > -   clk_np = of_parse_phandle(np, "clocks", 0);
> > > > > -   if (!clk_np)
> > > > > -   return NULL;
> > > > > -
> > > > > +   clk = of_clk_get(np, 0);
> > > > Why not use devm_clk_get here?
> > > devm_clk_get() is a wrapper around clk_get() which is not the same
> > > as of_clk_get().  What device would you pass to devm_clk_get(), and
> > > what name would you pass?
> > I'm fuzzy on whether or not you get a struct device from a cpufreq
> > driver. If so, then that would be the one to use. I would hope that
> > cpufreq drivers model cpus as devices, but I'm really not sure without
> > looking into the code.
> 
> It's not the cpufreq code that provides it, but get_cpu_device() could be
> used.
> 
> Do you have any comments on the first patch of this set?
> 
> -Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Yuantian Tang]

> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Thursday, June 30, 2016 10:24 AM
> To: Yuantian Tang <yuantian.t...@nxp.com>
> Cc: Scott Wood <o...@buserror.net>; Russell King <li...@armlinux.org.uk>;
> Michael Turquette <mturque...@baylibre.com>; Stephen Boyd
> <sb...@codeaurora.org>; Viresh Kumar <viresh.ku...@linaro.org>; linux-
> c...@vger.kernel.org; linux...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Yang-Leo Li <leoyang...@nxp.com>; Xiaofeng Ren
> <xiaofeng@nxp.com>; Scott Wood <scottw...@freescale.com>
> Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible
> parent clocks
> 
> On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote:
> > > -Original Message-
> > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > > Sent: Thursday, June 30, 2016 9:47 AM
> > > To: Yuantian Tang <yuantian.t...@nxp.com>
> > > Cc: Scott Wood <o...@buserror.net>; Russell King
> > > <li...@armlinux.org.uk>; Michael Turquette
> > > <mturque...@baylibre.com>; Stephen Boyd <sb...@codeaurora.org>;
> > > Viresh Kumar <viresh.ku...@linaro.org>; linux- c...@vger.kernel.org;
> > > linux...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org; Yang-Leo
> > > Li <leoyang...@nxp.com>; Xiaofeng Ren <xiaofeng@nxp.com>; Scott
> > > Wood <scottw...@freescale.com>
> > > Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering
> > > possible parent clocks
> > >
> > > On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:
> > > > Hi,
> > > >
> > > > This patch is acked by clock maintainer. If no comments from
> > > > anyone else,
> > > we will merge it in next week.
> > >
> > > There is a cpufreq commit depending on it.  Are you going to handle
> > > that one too?
> > >
> > That one has been acked by cpufreq maintainer. You can get this from
> patch comments.
> 
> I know that it has been ACKed.
> 
> My question is whether or not you are going to apply it along the [1/2].
> 
> If not, it will have to be deferred until the [1/2] is merged and then applied
> which may not be desirable.
> 
I hope we can apply both at same time. Seems Scott has a few concerns.

What you think about this patch? Can you apply it?
If you have applied this patch, then I can push CPUfreq maintainer to apply 
another one which will be delayed.

Regards,
Yuantian

> Thanks,
> Rafael

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Yuantian Tang]

> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Thursday, June 30, 2016 9:47 AM
> To: Yuantian Tang <yuantian.t...@nxp.com>
> Cc: Scott Wood <o...@buserror.net>; Russell King <li...@armlinux.org.uk>;
> Michael Turquette <mturque...@baylibre.com>; Stephen Boyd
> <sb...@codeaurora.org>; Viresh Kumar <viresh.ku...@linaro.org>; linux-
> c...@vger.kernel.org; linux...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Yang-Leo Li <leoyang...@nxp.com>; Xiaofeng Ren
> <xiaofeng@nxp.com>; Scott Wood <scottw...@freescale.com>
> Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible
> parent clocks
> 
> On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:
> > Hi,
> >
> > This patch is acked by clock maintainer. If no comments from anyone else,
> we will merge it in next week.
> 
> There is a cpufreq commit depending on it.  Are you going to handle that one
> too?
> 
That one has been acked by cpufreq maintainer. You can get this from patch 
comments.

Regards,
Yuantian

Re
> Thanks,
> Rafael

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Yuantian Tang]

Hi,

This patch is acked by clock maintainer. If no comments from anyone else, we 
will merge it in next week.

Thanks,
Yuantian

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Thursday, June 16, 2016 2:21 PM
> To: Russell King <li...@armlinux.org.uk>; Michael Turquette
> <mturque...@baylibre.com>; Stephen Boyd <sb...@codeaurora.org>;
> Viresh Kumar <viresh.ku...@linaro.org>; Rafael J. Wysocki
> <r...@rjwysocki.net>
> Cc: linux-...@vger.kernel.org; linux...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Yuantian Tang <yuantian.t...@nxp.com>; Yang-Leo Li
> <leoyang...@nxp.com>; Xiaofeng Ren <xiaofeng@nxp.com>; Scott Wood
> <scottw...@freescale.com>
> Subject: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible
> parent clocks
> 
> From: Scott Wood <scottw...@freescale.com>
> 
> Commit fc4a05d4b0eb ("clk: Remove unused provider APIs") removed
> __clk_get_num_parents() and clk_hw_get_parent_by_index(), leaving only
> true provider API versions that operate on struct clk_hw.
> 
> qoriq-cpufreq needs these functions in order to determine the options it has
> for calling clk_set_parent() and thus populate the cpufreq table, so revive
> them as legitimate consumer APIs.
> 
> Signed-off-by: Scott Wood <scottw...@freescale.com>
> ---
> v2: Add missing 'static inline' to stub functions.
> 
> v3: no changes
> 
>  drivers/clk/clk.c   | 19 +++
>  include/linux/clk.h | 31 +++
>  2 files changed, 50 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index d584004..d61a3fe 
> 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -290,6 +290,12 @@ struct clk_hw *__clk_get_hw(struct clk *clk)  }
> EXPORT_SYMBOL_GPL(__clk_get_hw);
> 
> +unsigned int clk_get_num_parents(struct clk *clk) {
> + return !clk ? 0 : clk->core->num_parents; }
> +EXPORT_SYMBOL_GPL(clk_get_num_parents);
> +
>  unsigned int clk_hw_get_num_parents(const struct clk_hw *hw)  {
>   return hw->core->num_parents;
> @@ -358,6 +364,19 @@ static struct clk_core
> *clk_core_get_parent_by_index(struct clk_core *core,
>   return core->parents[index];
>  }
> 
> +struct clk *clk_get_parent_by_index(struct clk *clk, unsigned int
> +index) {
> + struct clk_core *parent;
> +
> + if (!clk)
> + return NULL;
> +
> + parent = clk_core_get_parent_by_index(clk->core, index);
> +
> + return !parent ? NULL : parent->hw->clk; }
> +EXPORT_SYMBOL_GPL(clk_get_parent_by_index);
> +
>  struct clk_hw *
>  clk_hw_get_parent_by_index(const struct clk_hw *hw, unsigned int index)
> { diff --git a/include/linux/clk.h b/include/linux/clk.h index 
> 0df4a51..acd115f
> 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -392,6 +392,26 @@ int clk_set_parent(struct clk *clk, struct clk *parent);
> struct clk *clk_get_parent(struct clk *clk);
> 
>  /**
> + * clk_get_parent_by_index - get a possible parent clock by index
> + * @clk: clock source
> + * @index: index into the array of possible parents of this clock
> + *
> + * Returns struct clk corresponding to the requested possible
> + * parent clock source, or NULL.
> + */
> +struct clk *clk_get_parent_by_index(struct clk *clk,
> + unsigned int index);
> +
> +/**
> + * clk_get_num_parents - get number of possible parents
> + * @clk: clock source
> + *
> + * Returns the number of possible parents of this clock,
> + * which can then be enumerated using clk_get_parent_by_index().
> + */
> +unsigned int clk_get_num_parents(struct clk *clk);
> +
> +/**
>   * clk_get_sys - get a clock based upon the device name
>   * @dev_id: device name
>   * @con_id: connection ID
> @@ -461,6 +481,17 @@ static inline struct clk *clk_get_parent(struct clk *clk)
>   return NULL;
>  }
> 
> +static inline struct clk *clk_get_parent_by_index(struct clk *clk,
> +   unsigned int index)
> +{
> + return NULL;
> +}
> +
> +static inline unsigned int clk_get_num_parents(struct clk *clk) {
> + return 0;
> +}
> +
>  #endif
> 
>  /* clk_prepare_enable helps cases using clk_enable in non-atomic context.
> */
> --
> 2.5.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/2] fsl: Add binding for RCPM

[Yuantian Tang]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 16, 2015 10:32 AM
> To: Wang Dongsheng-B40534 
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> B18965 ; Jin Zhengxiong-R64188
> ; Zhao Chenhui-B35336
> ; Tang Yuantian-B29983
> 
> Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> 
> On Tue, 2015-09-15 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
> > Hi Scott,
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 16, 2015 10:19 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > > B18965; Jin
> > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > >
> > > On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> > > > Hi Scott,
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 16, 2015 7:57 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang
> > > > > robh+Huan-
> > > > > B18965; Jin
> > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > >
> > > > > On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > > > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > +---
> > > > > > +Required rcpm-wakeup property should be added to a device
> > > > > > +node if the
> > > > > > device
> > > > > > +can be used as a wakeup source.
> > > > > > +
> > > > > > +  - rcpm-wakeup: The value of the property consists of 3 cells.
> > > > > > + The
> > > > > > first
> > > > > > cell
> > > > > > + is a pointer to the rcpm node, the second cell is the
> > > > > > + bit mask
> > > > > > that
> > > > > > + should be set in IPPDEXPCR0, and the last cell is for
> > > > > > IPPDEXPCR1.
> > > > > > + Note: If the platform has no IPPDEXPCR1 register, put a
> > > > > > + zero
> > > > > > here.
> > > > >
> > > > > What if a future platform has more than two of these registers?
> > > >
> > > > Those registers are only used for wakeup device, we have a lot of
> > > > available bit for feature. For example, In LS1021a platform only
> > > > 7bits has used in the registers, and 57bits is reserved.
> > >
> > > Still, it'd be better to for the rcpm node to advertise the number
> > > of cells it expects.
> >
> > For the foreseeable future it should be enough to use, even if not
> > enough to use in the future at that time we can update the binding.
> 
> That's the whole point.  Device tree is stable ABI.  Updating it later to not 
> be
> fixed to two cells would be a lot harder than getting it right from the
> beginning.  Putting the number of cells in the phandle target is a standard
> device tree idiom.
> 
I agree with you. But what's the point a SOC has more than 64 wakeup source?

Regards,
Yuantian

> -Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v5] powerpc/rcpm: add RCPM driver

[Yuantian . Tang]

From: Tang Yuantian yuantian.t...@freescale.com

There is a RCPM (Run Control/Power Management) in Freescale QorIQ
series processors. The device performs tasks associated with device
run control and power management.

The driver implements some features: mask/unmask irq, enter/exit low
power states, freeze time base, etc.

Signed-off-by: Chenhui Zhao chenhui.z...@freescale.com
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
v5:
- update chassis version for t1040 in bindings
v4:
- refine bindings document
v3:
- added static and __init modifier to fsl_rcpm_init
v2:
- fix code style issues
- refine compatible string match part

 Documentation/devicetree/bindings/soc/fsl/rcpm.txt |  44 +++
 arch/powerpc/include/asm/fsl_guts.h| 105 +++
 arch/powerpc/include/asm/fsl_pm.h  |  48 +++
 arch/powerpc/platforms/85xx/Kconfig|   1 +
 arch/powerpc/sysdev/Kconfig|   5 +
 arch/powerpc/sysdev/Makefile   |   1 +
 arch/powerpc/sysdev/fsl_rcpm.c | 338 +
 7 files changed, 542 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/fsl/rcpm.txt
 create mode 100644 arch/powerpc/include/asm/fsl_pm.h
 create mode 100644 arch/powerpc/sysdev/fsl_rcpm.c

diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt 
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
new file mode 100644
index 000..dc52f70
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -0,0 +1,44 @@
+* Run Control and Power Management
+
+The RCPM performs all device-level tasks associated with device run control
+and power management.
+
+Required properites:
+  - reg : Offset and length of the register set of RCPM block.
+  - compatible : Sould contain a chip-specific RCPM block compatible string
+   and (if applicable) may contain a chassis-version RCPM compatible 
string.
+   Chip-specific strings are of the form fsl,chip-rcpm, such as:
+   * fsl,p2041-rcpm
+   * fsl,p3041-rcpm
+   * fsl,p4080-rcpm
+   * fsl,p5020-rcpm
+   * fsl,p5040-rcpm
+   * fsl,t4240-rcpm
+   * fsl,b4420-rcpm
+   * fsl,b4860-rcpm
+
+   Chassis-version RCPM strings include:
+   * fsl,qoriq-rcpm-1.0: for chassis 1.0 rcpm
+   * fsl,qoriq-rcpm-2.0: for chassis 2.0 rcpm
+   * fsl,qoriq-rcpm-2.1: for chassis 2.1 rcpm
+
+All references to 1.0 and 2.0 refer to the QorIQ chassis version to
+which the chip complies.
+Chassis VersionExample Chips
+------
+1.0p4080, p5020, p5040, p2041, p3041
+2.0t4240, b4860, b4420
+2.1t1040
+
+Example:
+The RCPM node for T4240:
+   rcpm: global-utilities@e2000 {
+   compatible = fsl,t4240-rcpm, fsl,qoriq-rcpm-2.0;
+   reg = 0xe2000 0x1000;
+   };
+
+The RCPM node for P4080:
+   rcpm: global-utilities@e2000 {
+   compatible = fsl,qoriq-rcpm-1.0;
+   reg = 0xe2000 0x1000;
+   };
diff --git a/arch/powerpc/include/asm/fsl_guts.h 
b/arch/powerpc/include/asm/fsl_guts.h
index 43b6bb1..a67413c 100644
--- a/arch/powerpc/include/asm/fsl_guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -188,5 +188,110 @@ static inline void guts_set_pmuxcr_dma(struct ccsr_guts 
__iomem *guts,
 
 #endif
 
+struct ccsr_rcpm_v1 {
+   u8  res[4];
+   __be32  cdozsr; /* 0x0004 Core Doze Status Register */
+   u8  res0008[4];
+   __be32  cdozcr; /* 0x000c Core Doze Control Register */
+   u8  res0010[4];
+   __be32  cnapsr; /* 0x0014 Core Nap Status Register */
+   u8  res0018[4];
+   __be32  cnapcr; /* 0x001c Core Nap Control Register */
+   u8  res0020[4];
+   __be32  cdozpsr;/* 0x0024 Core Doze Previous Status Register */
+   u8  res0028[4];
+   __be32  cnappsr;/* 0x002c Core Nap Previous Status Register */
+   u8  res0030[4];
+   __be32  cwaitsr;/* 0x0034 Core Wait Status Register */
+   u8  res0038[4];
+   __be32  cwdtdsr;/* 0x003c Core Watchdog Detect Status Register */
+   __be32  powmgtcsr;  /* 0x0040 PM ControlStatus Register */
+#define RCPM_POWMGTCSR_SLP 0x0002
+   u8  res0044[12];
+   __be32  ippdexpcr;  /* 0x0050 IP Powerdown Exception Control Register */
+   u8  res0054[16];
+   __be32  cpmimr; /* 0x0064 Core PM IRQ Mask Register */
+   u8  res0068[4];
+   __be32  cpmcimr;/* 0x006c Core PM Critical IRQ Mask Register */
+   u8  res0070[4];
+   __be32  cpmmcmr;/* 0x0074 Core PM Machine Check Mask Register */
+   u8  res0078[4];
+   __be32  cpmnmimr;   /* 0x007c Core PM NMI Mask Register */
+   u8  res0080[4];
+   __be32  ctbenr; /* 

RE: [PATCH v3] powerpc/rcpm: add RCPM driver

[Yuantian Tang]

Please see my replay inline.

Thanks,
Yuantian


 -Original Message-
 From: Bob Cochran [mailto:p...@mindchasers.com]
 Sent: Wednesday, June 17, 2015 2:00 AM
 To: Tang Yuantian-B29983; Wood Scott-B07421
 Cc: linuxppc-dev@lists.ozlabs.org; Zhao Chenhui-B35336
 Subject: Re: [PATCH v3] powerpc/rcpm: add RCPM driver
 
 On 06/16/2015 05:26 AM, yuantian.t...@freescale.com wrote:
  From: Tang Yuantian yuantian.t...@freescale.com
 
  There is a RCPM (Run Control/Power Management) in Freescale QorIQ
  series processors. The device performs tasks associated with device
  run control and power management.
 
  The driver implements some features: mask/unmask irq, enter/exit low
  power states, freeze time base, etc.
 
  Signed-off-by: Chenhui Zhao chenhui.z...@freescale.com
  Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
  ---
  v3:
  - added static and __init modifier to fsl_rcpm_init
  v2:
  - fix code style issues
  - refine compatible string match part
 
Documentation/devicetree/bindings/soc/fsl/rcpm.txt |  22 ++
arch/powerpc/include/asm/fsl_guts.h| 105 +++
arch/powerpc/include/asm/fsl_pm.h  |  48 +++
arch/powerpc/platforms/85xx/Kconfig|   1 +
arch/powerpc/sysdev/Kconfig|   5 +
arch/powerpc/sysdev/Makefile   |   1 +
arch/powerpc/sysdev/fsl_rcpm.c | 338
 +
7 files changed, 520 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/fsl/rcpm.txt
create mode 100644 arch/powerpc/include/asm/fsl_pm.h
create mode 100644 arch/powerpc/sysdev/fsl_rcpm.c
 
  diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
  b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
  new file mode 100644
  index 000..5318999
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
  @@ -0,0 +1,22 @@
  +* Run Control and Power Management
  +
  +The RCPM performs all device-level tasks associated with device run
  +control and power management.
  +
  +Required properites:
  +  - reg : Offset and length of the register set of RCPM block.
  +  - compatible : Specifies the compatibility list for the RCPM. The
 type
  +should be string, such as fsl,qoriq-rcpm-1.0, fsl,qoriq-rcpm-
 2.0.
 
 
 I just checked both my T1040 RM and datasheet, and I didn't see mention
 of the RCPM version that's used ( I assume it's 2.0 ). Is there a
 general rule for which SoCs have which version?  If so, perhaps you'll
 want to include it here along with your examples.
 
No such rule exists. The only way you can get the RCPM version is to refer to 
the DTS.

 
 
  +
  +Example:
  +The RCPM node for T4240:
  +   rcpm: global-utilities@e2000 {
  +   compatible = fsl,t4240-rcpm, fsl,qoriq-rcpm-2.0;
  +   reg = 0xe2000 0x1000;
  +   };
  +
  +The RCPM node for P4080:
  +   rcpm: global-utilities@e2000 {
  +   compatible = fsl,qoriq-rcpm-1.0;
  +   reg = 0xe2000 0x1000;
  +   };
 
 -- cut ---
 
  diff --git a/arch/powerpc/include/asm/fsl_pm.h
  b/arch/powerpc/include/asm/fsl_pm.h
  new file mode 100644
  index 000..4b09f09
  --- /dev/null
  +++ b/arch/powerpc/include/asm/fsl_pm.h
  @@ -0,0 +1,48 @@
  +/*
  + * Support Power Management
  + *
  + * Copyright 2014-2015 Freescale Semiconductor Inc.
  + *
  + * 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;  either version 2 of the  License, or
  +(at your
  + * option) any later version.
  + */
  +#ifndef __PPC_FSL_PM_H
  +#define __PPC_FSL_PM_H
  +#ifdef __KERNEL__
  +
  +#define E500_PM_PH10   1
  +#define E500_PM_PH15   2
  +#define E500_PM_PH20   3
  +#define E500_PM_PH30   4
  +#define E500_PM_DOZE   E500_PM_PH10
  +#define E500_PM_NAPE500_PM_PH15
 
 
 Are you using E500 in your labels for historical reasons? I can use
 this driver with E5500 and E6500 cores, right?  However, maybe I'm
 mistaken since some of your states don't seem to map to my E5500 / T1040
 (e.g., my RCPM doesn't seem to support PH20 or PH30, but I do have LPM10
 and LPM35, which I don't think your driver supports).  My RM states that
 LPM35 is a newer PM state, so maybe this is future work to be done?
 
These are all the PM states for E500 series socs. The states a board supports 
are from one to the other.
T1040 and some other platforms support LPM35 which will be implemented in 
future patch.

Regards,
Yuantian

 
  +
  +#define PLAT_PM_SLEEP  20
  +#define PLAT_PM_LPM20  30
  +
  +#define FSL_PM_SLEEP   (1  0)
  +#define FSL_PM_DEEP_SLEEP  (1  1)
 
 
 I don't see where you use FSL_PM_DEEP_SLEEP, and I'm wondering if this
 was provisioned for LPM35, which is documented to be a deep sleep mode.
 
 
  +
  +struct fsl_pm_ops {
  +   /* mask pending interrupts to the RCPM 

RE: [PATCH v2] powerpc/rcpm: add RCPM driver

[Yuantian Tang]

That makes sense. Thanks for pointing out.

Thanks,
Yuantian

 -Original Message-
 From: Paul Bolle [mailto:pebo...@tiscali.nl]
 Sent: Friday, June 12, 2015 4:58 PM
 To: Tang Yuantian-B29983
 Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; linux-
 ker...@vger.kernel.org; devicet...@vger.kernel.org; Zhao Chenhui-B35336
 Subject: Re: [PATCH v2] powerpc/rcpm: add RCPM driver
 
 Just a nit.
 
 On Thu, 2015-06-11 at 14:32 +0800, yuantian.t...@freescale.com wrote:
  --- /dev/null
  +++ b/arch/powerpc/sysdev/fsl_rcpm.c
 
  +int fsl_rcpm_init(void)
 
 This is used only through early_initcall(). I took the cargo cult
 approach of looking at the other uses of early_initcall() in
 arch/powerpc/. That approach tells me this function could be static and
 marked as __init. Would that work here too?
 
  +{
  +   [...]
  +}
  +
  +/* need to call this before SMP init */
  +early_initcall(fsl_rcpm_init);
 
 Thanks,
 
 Paul Bolle

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3] powerpc/cache: add cache flush operation for various e500

[Yuantian Tang]

Please see my replay inline.

From: Wood Scott-B07421
Sent: Wednesday, June 10, 2015 6:28 AM
To: Tang Yuantian-B29983
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; 
linux-ker...@vger.kernel.org; Zhao Chenhui-B35336; Tang Yuantian
Subject: Re: [PATCH v3] powerpc/cache: add cache flush operation for various 
e500

On Tue, 2015-06-09 at 09:53 +0800, yuantian.t...@freescale.com wrote:
 From: Tang Yuantian yuantian.t...@freescale.com

 Various e500 core have different cache architecture, so they
 need different cache flush operations. Therefore, add a callback
 function cpu_flush_caches to the struct cpu_spec. The cache flush
 operation for the specific kind of e500 is selected at init time.
 The callback function will flush all caches inside the current cpu.

 Signed-off-by: Chenhui Zhao chenhui.z...@freescale.com
 Signed-off-by: Tang Yuantian yuantian.t...@feescale.com
 ---
 v3:
   - change all flush_caches to cpu_down_flush
   - replace whitespace with tab
[snip]
.cpu_setup  = __setup_cpu_e500v2,
   .machine_check  = machine_check_e500,
   .platform   = ppc8548,
 + .cpu_down_flush = cpu_down_flush_e500v2,

It's still not lined up.  I'm not a fan of the line up all the =
style, as it's a pain to maintain (and can be harder to read if the =
is too far to the right), but mixing the two is worse.

[Yuantian]:
I need more clear about this.
The only difference here is that my function puts ONE tab before = and ONE 
white space after =; 
but the other functions in this structure use TWO tabs before =.  Is that 
what you want?

Regards,
Yuantian
 
-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] powerpc/config: add SCSI configs for corenet64_smp_defconfig

[Yuantian Tang]

 -Original Message-
 From: Wood Scott-B07421
 Sent: Friday, April 03, 2015 7:56 AM
 To: Tang Yuantian-B29983
 Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Xie Shaohui-B21989
 Subject: Re: [PATCH] powerpc/config: add SCSI configs for
 corenet64_smp_defconfig
 
 On Tue, 2015-03-31 at 18:00 +0800, yuantian.t...@freescale.com wrote:
  From: Tang Yuantian yuantian.t...@freescale.com
 
  Otherwise there wil be no SCSI device nodes.
 
  Signed-off-by: Shaohui Xie shaohui@freescale.com
  Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
  ---
   arch/powerpc/configs/corenet64_smp_defconfig | 7 +++
   1 file changed, 7 insertions(+)
 
  diff --git a/arch/powerpc/configs/corenet64_smp_defconfig
  b/arch/powerpc/configs/corenet64_smp_defconfig
  index 04737aa..77a8151 100644
  --- a/arch/powerpc/configs/corenet64_smp_defconfig
  +++ b/arch/powerpc/configs/corenet64_smp_defconfig
  @@ -75,6 +75,13 @@ CONFIG_BLK_DEV_LOOP=y  CONFIG_BLK_DEV_RAM=y
   CONFIG_BLK_DEV_RAM_SIZE=131072
   CONFIG_EEPROM_LEGACY=y
  +CONFIG_BLK_DEV_SD=y
  +CONFIG_CHR_DEV_ST=y
  +CONFIG_BLK_DEV_SR=y
  +CONFIG_CHR_DEV_SG=y
 
 Ben already sent a patch enabling these (except ST -- do we really need
 that?) in both corenet32 and corenet64.
 
  +CONFIG_SCSI_MULTI_LUN=y
 
 This option was removed by c309b35171dd
 
  +CONFIG_SCSI_LOGGING=y
  +CONFIG_SCSI_SPI_ATTRS=y
 
 If you want these enabled, do it in a separate patch with an explanation
 of why we should enable them by default, and do it for other 85xx/corenet
 configs as well.
 
OK, I will investigate this and resend if needed.

Thanks,
Yuantian

 -Scott
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 08/10] powerpc/corenet: Enable CLK_QORIQ

[Yuantian Tang]

 -Original Message-
 From: Emil Medve [mailto:emilian.me...@freescale.com]
 Sent: Wednesday, January 21, 2015 6:04 PM
 To: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
 mturque...@linaro.org; haoke...@gmail.com; Tang Yuantian-B29983
 Cc: Medve Emilian-EMMEDVE1
 Subject: [PATCH v2 08/10] powerpc/corenet: Enable CLK_QORIQ
 
 Change-Id: I1a80ad7b9f6854791bd270b746f93a91439155a6
 Signed-off-by: Emil Medve emilian.me...@freescale.com
 ---
  arch/powerpc/configs/corenet32_smp_defconfig | 1 +
 arch/powerpc/configs/corenet64_smp_defconfig | 1 +
  2 files changed, 2 insertions(+)
 
 diff --git a/arch/powerpc/configs/corenet32_smp_defconfig
 b/arch/powerpc/configs/corenet32_smp_defconfig
 index 611efe9..cce62e9 100644
 --- a/arch/powerpc/configs/corenet32_smp_defconfig
 +++ b/arch/powerpc/configs/corenet32_smp_defconfig
 @@ -147,6 +147,7 @@ CONFIG_STAGING=y
  CONFIG_MEMORY=y
  CONFIG_VIRT_DRIVERS=y
  CONFIG_FSL_HV_MANAGER=y
 +CONFIG_CLK_QORIQ=y
  CONFIG_EXT2_FS=y
  CONFIG_EXT3_FS=y
  # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set diff --git
 a/arch/powerpc/configs/corenet64_smp_defconfig
 b/arch/powerpc/configs/corenet64_smp_defconfig
 index be24a18..c9e8057 100644
 --- a/arch/powerpc/configs/corenet64_smp_defconfig
 +++ b/arch/powerpc/configs/corenet64_smp_defconfig
 @@ -117,6 +117,7 @@ CONFIG_DMADEVICES=y
  CONFIG_FSL_DMA=y
  CONFIG_VIRT_DRIVERS=y
  CONFIG_FSL_HV_MANAGER=y
 +CONFIG_CLK_QORIQ=y
  CONFIG_FSL_CORENET_CF=y
  CONFIG_MEMORY=y
  CONFIG_EXT2_FS=y
 --
 2.2.1

Acked-by: Tang Yuantian yuantian.t...@freescale.com

Regards,
Yuantian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 09/10] clk: qoriq: Add support for the platform PLL

[Yuantian Tang]

 -Original Message-
 From: Emil Medve [mailto:emilian.me...@freescale.com]
 Sent: Wednesday, January 21, 2015 6:04 PM
 To: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
 mturque...@linaro.org; haoke...@gmail.com; Tang Yuantian-B29983
 Cc: Medve Emilian-EMMEDVE1
 Subject: [PATCH v2 09/10] clk: qoriq: Add support for the platform PLL
 
 Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f
 Signed-off-by: Emil Medve emilian.me...@freescale.com
 ---
  drivers/clk/clk-qoriq.c | 83
 +
  1 file changed, 83 insertions(+)
 
 diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c index
 07bdfc5..cda90a9 100644
 --- a/drivers/clk/clk-qoriq.c
 +++ b/drivers/clk/clk-qoriq.c
 @@ -271,9 +271,92 @@ static void __init sysclk_init(struct device_node
 *node)
   if (!IS_ERR(clk))
   of_clk_add_provider(np, of_clk_src_simple_get, clk);  }
 +
 +static void __init pltfrm_pll_init(struct device_node *np) {
 + void __iomem *base;
 + uint32_t mult;
 + const char *parent_name, *clk_name;
 + int i, _errno;
 + struct clk_onecell_data *cod;
 +
 + base = of_iomap(np, 0);
 + if (!base) {
 + pr_err(%s(): %s: of_iomap() failed\n, __func__, np-name);
 + return;
 + }
 +
 + /* Get the multiple of PLL */
 + mult = ioread32be(base);
 +
 + iounmap(base);
 +
 + /* Check if this PLL is disabled */
 + if (mult  PLL_KILL) {
 + pr_debug(%s(): %s: Disabled\n, __func__, np-name);
 + return;
 + }
 + mult = (mult  GENMASK(6, 1))  1;
 +
 + parent_name = of_clk_get_parent_name(np, 0);
 + if (!parent_name) {
 + pr_err(%s(): %s: of_clk_get_parent_name() failed\n,
 +__func__, np-name);
 + return;
 + }
 +
 + i = of_property_count_strings(np, clock-output-names);
 + if (i  0) {
 + pr_err(%s(): %s: of_property_count_strings(clock-output-
 names) = %d\n,
 +__func__, np-name, i);
 + return;
 + }
 +
 + cod = kmalloc(sizeof(*cod) + i * sizeof(struct clk *), GFP_KERNEL);
 + if (!cod)
 + return;
 + cod-clks = (struct clk **)(cod + 1);
 + cod-clk_num = i;
 +
 + for (i = 0; i  cod-clk_num; i++) {
 + _errno = of_property_read_string_index(np, clock-output-
 names,
 +i, clk_name);
 + if (_errno  0) {
 + pr_err(%s(): %s: of_property_read_string_index(clock-
 output-names) = %d\n,
 +__func__, np-name, _errno);
 + goto return_clk_unregister;
 + }
 +
 + cod-clks[i] = clk_register_fixed_factor(NULL, clk_name,
 +parent_name, 0, mult, 1 + i);
 + if (IS_ERR(cod-clks[i])) {
 + pr_err(%s(): %s: clk_register_fixed_factor(%s) =
 %ld\n,
 +__func__, np-name,
 +clk_name, PTR_ERR(cod-clks[i]));
 + goto return_clk_unregister;
 + }
 + }
 +
 + _errno = of_clk_add_provider(np, of_clk_src_onecell_get, cod);
 + if (_errno  0) {
 + pr_err(%s(): %s: of_clk_add_provider() = %d\n,
 +__func__, np-name, _errno);
 + goto return_clk_unregister;
 + }
 +
 + return;
 +
 +return_clk_unregister:
 + while (--i = 0)
 + clk_unregister(cod-clks[i]);
 + kfree(cod);
 +}
 +
  CLK_OF_DECLARE(qoriq_sysclk_1, fsl,qoriq-sysclk-1.0, sysclk_init);
 CLK_OF_DECLARE(qoriq_sysclk_2, fsl,qoriq-sysclk-2.0, sysclk_init);
 CLK_OF_DECLARE(qoriq_core_pll_1, fsl,qoriq-core-pll-1.0,
 core_pll_init);  CLK_OF_DECLARE(qoriq_core_pll_2, fsl,qoriq-core-pll-
 2.0, core_pll_init);  CLK_OF_DECLARE(qoriq_core_mux_1, fsl,qoriq-core-
 mux-1.0, core_mux_init);  CLK_OF_DECLARE(qoriq_core_mux_2, fsl,qoriq-
 core-mux-2.0, core_mux_init);
 +CLK_OF_DECLARE(qoriq_pltfrm_pll_1, fsl,qoriq-platform-pll-1.0,
 +pltfrm_pll_init); CLK_OF_DECLARE(qoriq_pltfrm_pll_2,
 +fsl,qoriq-platform-pll-2.0, pltfrm_pll_init);
 --
 2.2.1

Acked-by: Tang Yuantian yuantian.t...@freescale.com

Regards,
Yuantian


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 8/8] clk: ppc-corenet: Add support for the platform PLL

[Yuantian Tang]

Hello Emil,

From the RM and your code, I didn't see any difference between the two type of 
PLL.
Could you provide some use cases or feature that prove this is necessary?

If there did have some features that current function didn't contain, can we 
expend the current one to include it?

BTW: if you did need this, please update the binding as well, if any:
Documentation/devicetree/bindings/clock/qoriq-clock.txt

Thanks,
Yuantian

 -Original Message-
 From: Emil Medve [mailto:emilian.me...@freescale.com]
 Sent: Wednesday, January 21, 2015 5:03 PM
 To: Tang Yuantian-B29983; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
 mturque...@linaro.org; haoke...@gmail.com
 Subject: Re: [PATCH 8/8] clk: ppc-corenet: Add support for the platform PLL
 
 Hello Yuan-Tian,
 
 
 On 01/21/2015 02:35 AM, Tang Yuantian-B29983 wrote:
  Hi Emil,
 
  I don't think it is the best to add a function that is very similar to 
  existing one.
  If you think the function name is not appropriate, rename it.
 
 It's not a naming matter. As I said, core_pll_init() assumptions and decisions
 based on the number of clocks in the DT. My hunch is some of these assumptions
 are not necessary and/or should be explicit based on the node/device 
 compatible.
 Having a standalone platform PLL initialization function wasn't a unilateral 
 lack of
 foresight
 
 
 Cheers,
 
 
  Thanks,
  Yuantian
 
  -Original Message-
  From: Emil Medve [mailto:emilian.me...@freescale.com]
  Sent: Wednesday, January 21, 2015 4:20 PM
  To: Tang Yuantian-B29983; linuxppc-dev@lists.ozlabs.org; Wood
  Scott-B07421; mturque...@linaro.org; haoke...@gmail.com
  Subject: Re: [PATCH 8/8] clk: ppc-corenet: Add support for the
  platform PLL
 
  Hello Yuan-Tian,
 
 
  On 01/20/2015 11:42 PM, Tang Yuantian-B29983 wrote:
  Which platform are you trying to use this on?
 
  CoreNet chassis v1 and v2 SoC(s)
 
  Can this be initialized by core pll function core_pll_init()?
  I just saw most of this function is silimar to the core_pll_init().
 
  Yes, the flow is similar, but core_pll_init() makes assumptions that
  it shouldn't or are not relevant to the platform PLL
 
 
  Cheers,
 
 
  Thanks,
  Yuantian
 
  -Original Message-
  From: Emil Medve [mailto:emilian.me...@freescale.com]
  Sent: Tuesday, January 20, 2015 6:10 PM
  To: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
  mturque...@linaro.org; haoke...@gmail.com; Tang Yuantian-B29983
  Cc: Medve Emilian-EMMEDVE1
  Subject: [PATCH 8/8] clk: ppc-corenet: Add support for the platform
  PLL
 
  Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f
  Signed-off-by: Emil Medve emilian.me...@freescale.com
  ---
   drivers/clk/clk-ppc-corenet.c | 85
  +++
   1 file changed, 85 insertions(+)
 
  diff --git a/drivers/clk/clk-ppc-corenet.c
  b/drivers/clk/clk-ppc-corenet.c index
  91816b1..ff425e1 100644
  --- a/drivers/clk/clk-ppc-corenet.c
  +++ b/drivers/clk/clk-ppc-corenet.c
  @@ -7,6 +7,9 @@
*
* clock driver for Freescale PowerPC corenet SoCs.
*/
  +
  +#define pr_fmt(fmt) KBUILD_MODNAME :  fmt
  +
   #include linux/clk-provider.h
   #include linux/io.h
   #include linux/kernel.h
  @@ -261,9 +264,91 @@ static void __init sysclk_init(struct
  device_node
  *node)
   of_clk_add_provider(np, of_clk_src_simple_get, clk);  }
 
  +static void __init pltfrm_pll_init(struct device_node *np) {
  +void __iomem *base;
  +uint32_t mult;
  +const char *parent_name, *clk_name;
  +int i, _errno;
  +struct clk_onecell_data *cod;
  +
  +base = of_iomap(np, 0);
  +if (!base) {
  +pr_err(%s(): %s: of_iomap() failed\n, __func__, 
  np-name);
  +return;
  +}
  +
  +/* Get the multiple of PLL */
  +mult = ioread32be(base);
  +
  +iounmap(base);
  +
  +/* Check if this PLL is disabled */
  +if (mult  PLL_KILL) {
  +pr_debug(%s(): %s: Disabled\n, __func__, np-name);
  +return;
  +}
  +mult = (mult  GENMASK(6, 1))  1;
  +
  +parent_name = of_clk_get_parent_name(np, 0);
  +if (!parent_name) {
  +pr_err(%s(): %s: of_clk_get_parent_name() failed\n,
  +   __func__, np-name);
  +return;
  +}
  +
  +i = of_property_count_strings(np, clock-output-names);
  +if (i  0) {
  +pr_err(%s(): %s: 
  of_property_count_strings(clock-output-names)
  = %d\n,
  +   __func__, np-name, i);
  +return;
  +}
  +
  +cod = kmalloc(sizeof(*cod) + i * sizeof(struct clk *), 
  GFP_KERNEL);
  +if (!cod)
  +return;
  +cod-clks = (struct clk **)(cod + 1);
  +cod-clk_num = i;
  +
  +for (i = 0; i  cod-clk_num; i++) {
  +_errno = of_property_read_string_index(np,
 clock-output-names,
  + 

RE: [PATCH 8/8] clk: ppc-corenet: Add support for the platform PLL

[Yuantian Tang]

Hi Emil,

I don't think it is the best to add a function that is very similar to existing 
one. 
If you think the function name is not appropriate, rename it.

Thanks,
Yuantian

 -Original Message-
 From: Emil Medve [mailto:emilian.me...@freescale.com]
 Sent: Wednesday, January 21, 2015 4:20 PM
 To: Tang Yuantian-B29983; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
 mturque...@linaro.org; haoke...@gmail.com
 Subject: Re: [PATCH 8/8] clk: ppc-corenet: Add support for the platform PLL
 
 Hello Yuan-Tian,
 
 
 On 01/20/2015 11:42 PM, Tang Yuantian-B29983 wrote:
  Which platform are you trying to use this on?
 
 CoreNet chassis v1 and v2 SoC(s)
 
  Can this be initialized by core pll function core_pll_init()?
  I just saw most of this function is silimar to the core_pll_init().
 
 Yes, the flow is similar, but core_pll_init() makes assumptions that it 
 shouldn't or
 are not relevant to the platform PLL
 
 
 Cheers,
 
 
  Thanks,
  Yuantian
 
  -Original Message-
  From: Emil Medve [mailto:emilian.me...@freescale.com]
  Sent: Tuesday, January 20, 2015 6:10 PM
  To: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
  mturque...@linaro.org; haoke...@gmail.com; Tang Yuantian-B29983
  Cc: Medve Emilian-EMMEDVE1
  Subject: [PATCH 8/8] clk: ppc-corenet: Add support for the platform
  PLL
 
  Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f
  Signed-off-by: Emil Medve emilian.me...@freescale.com
  ---
   drivers/clk/clk-ppc-corenet.c | 85
  +++
   1 file changed, 85 insertions(+)
 
  diff --git a/drivers/clk/clk-ppc-corenet.c
  b/drivers/clk/clk-ppc-corenet.c index
  91816b1..ff425e1 100644
  --- a/drivers/clk/clk-ppc-corenet.c
  +++ b/drivers/clk/clk-ppc-corenet.c
  @@ -7,6 +7,9 @@
*
* clock driver for Freescale PowerPC corenet SoCs.
*/
  +
  +#define pr_fmt(fmt) KBUILD_MODNAME :  fmt
  +
   #include linux/clk-provider.h
   #include linux/io.h
   #include linux/kernel.h
  @@ -261,9 +264,91 @@ static void __init sysclk_init(struct device_node
 *node)
 of_clk_add_provider(np, of_clk_src_simple_get, clk);  }
 
  +static void __init pltfrm_pll_init(struct device_node *np) {
  +  void __iomem *base;
  +  uint32_t mult;
  +  const char *parent_name, *clk_name;
  +  int i, _errno;
  +  struct clk_onecell_data *cod;
  +
  +  base = of_iomap(np, 0);
  +  if (!base) {
  +  pr_err(%s(): %s: of_iomap() failed\n, __func__, np-name);
  +  return;
  +  }
  +
  +  /* Get the multiple of PLL */
  +  mult = ioread32be(base);
  +
  +  iounmap(base);
  +
  +  /* Check if this PLL is disabled */
  +  if (mult  PLL_KILL) {
  +  pr_debug(%s(): %s: Disabled\n, __func__, np-name);
  +  return;
  +  }
  +  mult = (mult  GENMASK(6, 1))  1;
  +
  +  parent_name = of_clk_get_parent_name(np, 0);
  +  if (!parent_name) {
  +  pr_err(%s(): %s: of_clk_get_parent_name() failed\n,
  + __func__, np-name);
  +  return;
  +  }
  +
  +  i = of_property_count_strings(np, clock-output-names);
  +  if (i  0) {
  +  pr_err(%s(): %s: of_property_count_strings(clock-output-names)
  = %d\n,
  + __func__, np-name, i);
  +  return;
  +  }
  +
  +  cod = kmalloc(sizeof(*cod) + i * sizeof(struct clk *), GFP_KERNEL);
  +  if (!cod)
  +  return;
  +  cod-clks = (struct clk **)(cod + 1);
  +  cod-clk_num = i;
  +
  +  for (i = 0; i  cod-clk_num; i++) {
  +  _errno = of_property_read_string_index(np, clock-output-names,
  + i, clk_name);
  +  if (_errno  0) {
  +  pr_err(%s(): %s:
  of_property_read_string_index(clock-output-names) = %d\n,
  + __func__, np-name, _errno);
  +  goto return_clk_unregister;
  +  }
  +
  +  cod-clks[i] = clk_register_fixed_factor(NULL, clk_name,
  + parent_name, 0, mult, 1 + i);
  +  if (IS_ERR(cod-clks[i])) {
  +  pr_err(%s(): %s: clk_register_fixed_factor(%s) = 
  %ld\n,
  + __func__, np-name,
  + clk_name, PTR_ERR(cod-clks[i]));
  +  goto return_clk_unregister;
  +  }
  +  }
  +
  +  _errno = of_clk_add_provider(np, of_clk_src_onecell_get, cod);
  +  if (_errno  0) {
  +  pr_err(%s(): %s: of_clk_add_provider() = %d\n,
  + __func__, np-name, _errno);
  +  goto return_clk_unregister;
  +  }
  +
  +  return;
  +
  +return_clk_unregister:
  +  while (--i = 0)
  +  clk_unregister(cod-clks[i]);
  +  kfree(cod);
  +}
  +
   CLK_OF_DECLARE(qoriq_sysclk_1, fsl,qoriq-sysclk-1.0, sysclk_init);
  CLK_OF_DECLARE(qoriq_sysclk_2, fsl,qoriq-sysclk-2.0, sysclk_init);
  CLK_OF_DECLARE(qoriq_core_pll_1, fsl,qoriq-core-pll-1.0,
  core_pll_init); CLK_OF_DECLARE(qoriq_core_pll_2,
  fsl,qoriq-core-pll-2.0, core_pll_init);
  CLK_OF_DECLARE(qoriq_core_mux_1, 

RE: [PATCH 0/8] clk: ppc-corenet: Add support for the platform PLL

[Yuantian Tang]

Hi Emil,

Thanks for fixing those warnings. The patch set you based on is merged.
I sent another two patches and one of them got merged. You probably need to 
rebase your patches.
My patch link:
http://patchwork.ozlabs.org/patch/429257/
http://patchwork.ozlabs.org/patch/429258/

Thanks,
Yuantian

 -Original Message-
 From: Emil Medve [mailto:emilian.me...@freescale.com]
 Sent: Tuesday, January 20, 2015 6:09 PM
 To: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; mturque...@linaro.org;
 haoke...@gmail.com; Tang Yuantian-B29983
 Cc: Medve Emilian-EMMEDVE1
 Subject: [PATCH 0/8] clk: ppc-corenet: Add support for the platform PLL
 
 These patches are based on:
 
 http://patchwork.ozlabs.org/patch/417297
 http://patchwork.ozlabs.org/patch/417295
 http://patchwork.ozlabs.org/patch/417292
 
 The first 5 patches below are checkpatch/static analysis fixes
 
 Emil Medve (8):
   clk: ppc-corenet: Fix checkpatch type PARENTHESIS_ALIGNMENT
   clk: ppc-corenet: Fix checkpatch type ALLOC_WITH_MULTIPLY
   clk: ppc-corenet: Fix checkpatch type ALLOC_SIZEOF_STRUCT
   clk: ppc-corenet: Fix checkpatch type OOM_MESSAGE
   clk: ppc-corenet: Make local symbol 'static'
   clk: ppc-corenet: Replace kzalloc() with kmalloc()
   powerpc/corenet: Enable CLK_PPC_CORENET
   clk: ppc-corenet: Add support for the platform PLL
 
  arch/powerpc/configs/corenet32_smp_defconfig |   1 +
  arch/powerpc/configs/corenet64_smp_defconfig |   1 +
  drivers/clk/clk-ppc-corenet.c| 120
 ++-
  3 files changed, 101 insertions(+), 21 deletions(-)
 
 --
 2.2.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 8/8] clk: ppc-corenet: Add support for the platform PLL

[Yuantian Tang]

Which platform are you trying to use this on? Can this be initialized by core 
pll function core_pll_init()?
I just saw most of this function is silimar to the core_pll_init().

Thanks,
Yuantian

 -Original Message-
 From: Emil Medve [mailto:emilian.me...@freescale.com]
 Sent: Tuesday, January 20, 2015 6:10 PM
 To: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; mturque...@linaro.org;
 haoke...@gmail.com; Tang Yuantian-B29983
 Cc: Medve Emilian-EMMEDVE1
 Subject: [PATCH 8/8] clk: ppc-corenet: Add support for the platform PLL
 
 Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f
 Signed-off-by: Emil Medve emilian.me...@freescale.com
 ---
  drivers/clk/clk-ppc-corenet.c | 85
 +++
  1 file changed, 85 insertions(+)
 
 diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c 
 index
 91816b1..ff425e1 100644
 --- a/drivers/clk/clk-ppc-corenet.c
 +++ b/drivers/clk/clk-ppc-corenet.c
 @@ -7,6 +7,9 @@
   *
   * clock driver for Freescale PowerPC corenet SoCs.
   */
 +
 +#define pr_fmt(fmt) KBUILD_MODNAME :  fmt
 +
  #include linux/clk-provider.h
  #include linux/io.h
  #include linux/kernel.h
 @@ -261,9 +264,91 @@ static void __init sysclk_init(struct device_node *node)
   of_clk_add_provider(np, of_clk_src_simple_get, clk);  }
 
 +static void __init pltfrm_pll_init(struct device_node *np) {
 + void __iomem *base;
 + uint32_t mult;
 + const char *parent_name, *clk_name;
 + int i, _errno;
 + struct clk_onecell_data *cod;
 +
 + base = of_iomap(np, 0);
 + if (!base) {
 + pr_err(%s(): %s: of_iomap() failed\n, __func__, np-name);
 + return;
 + }
 +
 + /* Get the multiple of PLL */
 + mult = ioread32be(base);
 +
 + iounmap(base);
 +
 + /* Check if this PLL is disabled */
 + if (mult  PLL_KILL) {
 + pr_debug(%s(): %s: Disabled\n, __func__, np-name);
 + return;
 + }
 + mult = (mult  GENMASK(6, 1))  1;
 +
 + parent_name = of_clk_get_parent_name(np, 0);
 + if (!parent_name) {
 + pr_err(%s(): %s: of_clk_get_parent_name() failed\n,
 +__func__, np-name);
 + return;
 + }
 +
 + i = of_property_count_strings(np, clock-output-names);
 + if (i  0) {
 + pr_err(%s(): %s: of_property_count_strings(clock-output-names)
 = %d\n,
 +__func__, np-name, i);
 + return;
 + }
 +
 + cod = kmalloc(sizeof(*cod) + i * sizeof(struct clk *), GFP_KERNEL);
 + if (!cod)
 + return;
 + cod-clks = (struct clk **)(cod + 1);
 + cod-clk_num = i;
 +
 + for (i = 0; i  cod-clk_num; i++) {
 + _errno = of_property_read_string_index(np, clock-output-names,
 +i, clk_name);
 + if (_errno  0) {
 + pr_err(%s(): %s:
 of_property_read_string_index(clock-output-names) = %d\n,
 +__func__, np-name, _errno);
 + goto return_clk_unregister;
 + }
 +
 + cod-clks[i] = clk_register_fixed_factor(NULL, clk_name,
 +parent_name, 0, mult, 1 + i);
 + if (IS_ERR(cod-clks[i])) {
 + pr_err(%s(): %s: clk_register_fixed_factor(%s) = 
 %ld\n,
 +__func__, np-name,
 +clk_name, PTR_ERR(cod-clks[i]));
 + goto return_clk_unregister;
 + }
 + }
 +
 + _errno = of_clk_add_provider(np, of_clk_src_onecell_get, cod);
 + if (_errno  0) {
 + pr_err(%s(): %s: of_clk_add_provider() = %d\n,
 +__func__, np-name, _errno);
 + goto return_clk_unregister;
 + }
 +
 + return;
 +
 +return_clk_unregister:
 + while (--i = 0)
 + clk_unregister(cod-clks[i]);
 + kfree(cod);
 +}
 +
  CLK_OF_DECLARE(qoriq_sysclk_1, fsl,qoriq-sysclk-1.0, sysclk_init);
 CLK_OF_DECLARE(qoriq_sysclk_2, fsl,qoriq-sysclk-2.0, sysclk_init);
 CLK_OF_DECLARE(qoriq_core_pll_1, fsl,qoriq-core-pll-1.0, core_pll_init);
 CLK_OF_DECLARE(qoriq_core_pll_2, fsl,qoriq-core-pll-2.0, core_pll_init);
 CLK_OF_DECLARE(qoriq_core_mux_1, fsl,qoriq-core-mux-1.0, core_mux_init);
 CLK_OF_DECLARE(qoriq_core_mux_2, fsl,qoriq-core-mux-2.0, core_mux_init);
 +CLK_OF_DECLARE(qoriq_pltfrm_pll_1, fsl,qoriq-platform-pll-1.0,
 +pltfrm_pll_init); CLK_OF_DECLARE(qoriq_pltfrm_pll_2,
 +fsl,qoriq-platform-pll-2.0, pltfrm_pll_init);
 --
 2.2.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/3] Revert clk: ppc-corenet: Fix Section mismatch warning

[Yuantian Tang]

PING!

Thanks,
Yuantian

 -Original Message-
 From: Kevin Hao [mailto:haoke...@gmail.com]
 Sent: Wednesday, December 03, 2014 4:54 PM
 To: linuxppc-dev@lists.ozlabs.org
 Cc: Benjamin Herrenschmidt; Wood Scott-B07421; Mike Turquette; Lu
 Jingchang-B35083; Gerhard Sittig; Tang Yuantian-B29983
 Subject: [PATCH v3 1/3] Revert clk: ppc-corenet: Fix Section mismatch 
 warning
 
 This reverts commit da788acb28386aa896224e784954bb73c99ff26c.
 
 That commit tried to fix the section mismatch warning by moving the
 ppc_corenet_clk_driver struct to init section. This is definitely wrong 
 because the
 kernel would free the memories occupied by this struct after boot while this
 driver is still registered in the driver core.
 The kernel would panic when accessing this driver struct.
 
 Cc: sta...@vger.kernel.org # 3.17
 Signed-off-by: Kevin Hao haoke...@gmail.com
 Acked-by: Scott Wood scottw...@freescale.com
 Acked-by: Michael Turquette mturque...@linaro.org
 ---
 v3: Cc stable and add ack.
 
 v2: A new patch in v2.
 
  drivers/clk/clk-ppc-corenet.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c 
 index
 b6e6c85507a5..0a47d6f49cd6 100644
 --- a/drivers/clk/clk-ppc-corenet.c
 +++ b/drivers/clk/clk-ppc-corenet.c
 @@ -291,7 +291,7 @@ static const struct of_device_id ppc_clk_ids[] __initconst
 = {
   {}
  };
 
 -static struct platform_driver ppc_corenet_clk_driver __initdata = {
 +static struct platform_driver ppc_corenet_clk_driver = {
   .driver = {
   .name = ppc_corenet_clock,
   .of_match_table = ppc_clk_ids,
 --
 1.9.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 0/3] fix a kernel panic on fsl corenet board when CONFIG_CLK_PPC_CORENET is enabled

[Yuantian Tang]

Hello Mike,

Could you please apply this patch?
This patch has been acked for a while.

Thanks,
Yuantian

 -Original Message-
 From: Linuxppc-dev
 [mailto:linuxppc-dev-bounces+b29983=freescale@lists.ozlabs.org] On
 Behalf Of Scott Wood
 Sent: Friday, November 07, 2014 12:08 PM
 To: Kevin Hao
 Cc: Mike Turquette; Gerhard Sittig; Lu Jingchang-B35083;
 linuxppc-dev@lists.ozlabs.org
 Subject: Re: [PATCH v2 0/3] fix a kernel panic on fsl corenet board when
 CONFIG_CLK_PPC_CORENET is enabled
 
 On Sun, 2014-10-19 at 14:11 +0800, Kevin Hao wrote:
  Hi,
 
  I have done a boot test on p2014rdb and t4240qds boards. I don't have
  an access to mpc512x board, so only build test for that.
 
  v2:
   - Revert the commit da788acb2838 first.
   - Invoke of_clk_init() from a common place.
 
  v1
  This tries to fix a kernel panic introduced by commit da788acb2838
  (clk: ppc-corenet: Fix Section mismatch warning).
 
  Kevin Hao (3):
Revert clk: ppc-corenet: Fix Section mismatch warning
powerpc: call of_clk_init() from time_init()
clk: ppc-corenet: fix section mismatch warning
 
   arch/powerpc/kernel/time.c|  5 
   arch/powerpc/platforms/512x/clock-commonclk.c | 11 ---
   drivers/clk/clk-ppc-corenet.c | 43 
  ---
   3 files changed, 16 insertions(+), 43 deletions(-)
 
 
 Acked-by: Scott Wood scottw...@freescale.com
 
 Whose tree should this go through?
 
 -Scott
 
 
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] cpufreq: qoriq: rename the driver

[Yuantian Tang]

Hello Viresh,

When I use -C -M options, checkpatch reports error:

[tangyt@titan linux-pm]$ ./scripts/checkpatch.pl 
0002-cpufreq-qoriq-rename-the-driver.patch 
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#15: 
 drivers/cpufreq/{ppc-corenet-cpufreq.c = qoriq-cpufreq.c} | 0

ERROR: Does not appear to be a unified-diff format patch

total: 1 errors, 1 warnings, 0 lines checked

0002-cpufreq-qoriq-rename-the-driver.patch has style problems, please review.

I just rename it and do not change anyting. Isn't that allowed?

Thanks,
Yuantian

 -Original Message-
 From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
 Sent: Friday, November 21, 2014 3:56 PM
 To: Tang Yuantian-B29983
 Cc: Rafael J. Wysocki; Linux Kernel Mailing List; linux...@vger.kernel.org;
 linuxppc-...@ozlabs.org; Jin Zhengxiong-R64188
 Subject: Re: [PATCH 2/2] cpufreq: qoriq: rename the driver
 
 On 21 November 2014 12:58, Tang Yuantian yuantian.t...@freescale.com
 wrote:
  This driver works on all QorIQ platforms which include ARM-based cores
  and PPC-based cores.
  Rename it in order to represent better.
 
  Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
  ---
   drivers/cpufreq/ppc-corenet-cpufreq.c | 371 
  --
   drivers/cpufreq/qoriq-cpufreq.c   | 371
 ++
   2 files changed, 371 insertions(+), 371 deletions(-)  delete mode
  100644 drivers/cpufreq/ppc-corenet-cpufreq.c
   create mode 100644 drivers/cpufreq/qoriq-cpufreq.c
 
 This is not reviewable at all.. How do I verify that you haven't changed 
 something
 in the files as well ?
 
 To make life easy always create patches with:
 
 git format-patch -C -M
 
 Above options handle renames pretty well.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ platforms

[Yuantian Tang]

 -Original Message-
 From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
 Sent: Tuesday, October 21, 2014 5:04 PM
 To: Tang Yuantian-B29983
 Cc: Rafael J. Wysocki; Linux Kernel Mailing List; linux...@vger.kernel.org;
 linuxppc-...@ozlabs.org
 Subject: Re: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ
 platforms
 
 On 21 October 2014 14:29, Yuantian Tang yuantian.t...@freescale.com
 wrote:
  If I do so, menuconfig will display like this(on PPC):
  PowerPC CPU frequency scaling drivers  
  QorIQ CPU Frequency scaling  ---
  * CPU frequency scaling driver for Freescale QorIQ
  SoCs On ARM, there should be a similar problem.
  Isn't weird?
 
 Similar is true for cpufreq-cpu0 driver as well.. Maybe we can create a
 Kconfig.drivers configuration and include it from all architecture specific 
 ones ?
 
 @ Rafael ?

Do we have a conclusion yet?

Regards,
Yuantian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ platforms

[Yuantian Tang]

  #ifndef CONFIG_SMP
  static inline const struct cpumask *cpu_core_mask(int cpu) { @@ -79,6
  +75,79 @@ static inline const struct cpumask *cpu_core_mask(int cpu) }
  #endif
 
  +#if defined(CONFIG_PPC_E500MC)
 
 Probably should just be CONFIG_PPC, but do we need this at all.  Can't we just
 use topology_core_id() on both ARM  PPC?
 
topology_core_id() doesn't work on PPC.
This function only supports PPC64 and non-thread SOCs.

I can make it work on PPC, but we are used to use get_hard_smp_processor_id() 
on ppc.

Regards,
Yuantian

  +static int get_cpu_physical_id(int cpu) {
  +   return get_hard_smp_processor_id(cpu); } #elif defined(CONFIG_ARM)
  +static int get_cpu_physical_id(int cpu) {
  +   return topology_core_id(cpu);
  +}
  +#endif
  +

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ platforms

[Yuantian Tang]

  -config PPC_CORENET_CPUFREQ
  -   tristate CPU frequency scaling driver for Freescale E500MC SoCs
  -   depends on PPC_E500MC  OF  COMMON_CLK
  +config QORIQ_CPUFREQ
  +   tristate CPU frequency scaling driver for Freescale QorIQ SoCs
  +   depends on OF  COMMON_CLK
  select CLK_PPC_CORENET
  help
  - This adds the CPUFreq driver support for Freescale e500mc,
  - e5500 and e6500 series SoCs which are capable of changing
  - the CPU's frequency dynamically.
  + This adds the CPUFreq driver support for Freescale QorIQ SoCs
  + which are capable of changing the CPU's frequency dynamically.
 
   config CPU_FREQ_PMAC
  bool Support for Apple PowerBooks
 
 Don't need this duplication at all. Just move this to Kconfig instead of .arm 
 and
 ppc.
 
If I do so, menuconfig will display like this(on PPC):
PowerPC CPU frequency scaling drivers    
QorIQ CPU Frequency scaling  ---
* CPU frequency scaling driver for Freescale QorIQ SoCs
On ARM, there should be a similar problem.
Isn't weird?

Regards,
Yuantian

  diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
  b/drivers/cpufreq/qoriq-cpufreq.c
 
   /**
* struct cpu_data - per CPU data struct @@ -69,9 +68,6 @@ static
  const u32 *fmask;
 
   static DEFINE_PER_CPU(struct cpu_data *, cpu_data);
 
  -/* cpumask in a cluster */
  -static DEFINE_PER_CPU(cpumask_var_t, cpu_mask);
  -
   #ifndef CONFIG_SMP
   static inline const struct cpumask *cpu_core_mask(int cpu)  { @@
  -79,6 +75,79 @@ static inline const struct cpumask *cpu_core_mask(int
  cpu)  }  #endif
 
  +#if defined(CONFIG_PPC_E500MC)
  +static int get_cpu_physical_id(int cpu) {
  +   return get_hard_smp_processor_id(cpu); } #elif
  +defined(CONFIG_ARM)
 
 Wouldn't a #else work here as there are just two platforms we are talking 
 about ?
 
  +static int get_cpu_physical_id(int cpu) {
  +   return topology_core_id(cpu);
  +}
  +#endif
  +
  +static u32 get_bus_freq(void)
  +{
  +   struct device_node *soc;
  +   u32 sysfreq;
  +
  +   soc = of_find_node_by_type(NULL, soc);
  +   if (!soc)
  +   return 0;
  +
  +   if (of_property_read_u32(soc, bus-frequency, sysfreq))
  +   sysfreq = 0;
  +
  +   of_node_put(soc);
  +
  +   return sysfreq;
  +}
  +
  +static struct device_node *cpu_to_clk_node(int cpu) {
  +   struct device_node *np, *clk_np;
  +
  +   if (!cpu_present(cpu))
  +   return NULL;
  +
  +   np = of_get_cpu_node(cpu, NULL);
  +   if (!np)
  +   return NULL;
  +
  +   clk_np = of_parse_phandle(np, clocks, 0);
  +   if (!clk_np)
  +   return NULL;
  +
  +   of_node_put(np);
  +
  +   return clk_np;
  +}
  +
  +/* traverse cpu nodes to get cpu mask of sharing clock wire */ static
  +void set_affected_cpus(struct cpufreq_policy *policy) {
  +   struct device_node *np, *clk_np;
  +   struct cpumask *dstp = policy-cpus;
  +   int i;
  +
  +   np = cpu_to_clk_node(policy-cpu);
  +   if (!np)
  +   return;
  +
  +   for_each_present_cpu(i) {
  +   clk_np = cpu_to_clk_node(i);
  +   if (!clk_np)
  +   continue;
  +
  +   if (clk_np == np)
  +   cpumask_set_cpu(i, dstp);
 
 So you are depending on matching the clock-nodes from DT for getting this
 information, right ? There is nothing that the architecture gives?
 
  +
  +   of_node_put(clk_np);
  +   }
  +   of_node_put(np);
  +}
  +
   /* reduce the duplicated frequencies in frequency table */  static
  void freq_table_redup(struct cpufreq_frequency_table *freq_table,
  int count)
  @@ -105,6 +174,7 @@ static void freq_table_sort(struct
 cpufreq_frequency_table *freq_table,
  int i, j, ind;
  unsigned int freq, max_freq;
  struct cpufreq_frequency_table table;
  +
  for (i = 0; i  count - 1; i++) {
  max_freq = freq_table[i].frequency;
  ind = i;
  @@ -129,7 +199,7 @@ static void freq_table_sort(struct
 cpufreq_frequency_table *freq_table,
  }
   }
 
  -static int corenet_cpufreq_cpu_init(struct cpufreq_policy *policy)
  +static int qoriq_cpufreq_cpu_init(struct cpufreq_policy *policy)
   {
  struct device_node *np;
  int i, count, ret;
  @@ -145,10 +215,8 @@ static int corenet_cpufreq_cpu_init(struct
 cpufreq_policy *policy)
  return -ENODEV;
 
  data = kzalloc(sizeof(*data), GFP_KERNEL);
  -   if (!data) {
  -   pr_err(%s: no memory\n, __func__);
 
 Wasn't this useful ?
 
  +   if (!data)
  goto err_np;
  -   }
 
  policy-clk = of_clk_get(np, 0);
  if (IS_ERR(policy-clk)) {
  @@ -170,7 +238,7 @@ static int corenet_cpufreq_cpu_init(struct
 cpufreq_policy *policy)
  }
 

RE: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ platforms

[Yuantian Tang]

Thanks for your comments.  Your comments will be addressed in next version.
Some explanations inline.

Thanks,
Yuantian

 -Original Message-
 From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
 Sent: Friday, October 17, 2014 4:09 PM
 To: Tang Yuantian-B29983
 Cc: Rafael J. Wysocki; Linux Kernel Mailing List; linux...@vger.kernel.org;
 linuxppc-...@ozlabs.org; Tang Yuantian-B29983
 Subject: Re: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ
 platforms
 
 On 17 October 2014 08:43,  b29...@freescale.com wrote:
 
 Hi B29983 :)
 
  From: Tang Yuantian yuantian.t...@freescale.com
 
  Freescale introduced new ARM core-based SoCs which support dynamic
  frequency switch feature. DFS on new SoCs are compatible with current
  PowerPC CoreNet platforms. In order to support those new platforms,
  this driver needs to be slightly adjusted. The main changes include:
 
  1. Changed the names of driver and functions in driver.
  2. Added two new functions get_cpu_physical_id() and get_bus_freq().
  3. Used a new way to get all the CPUs which sharing clock wire.
 
  Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
  ---
   drivers/cpufreq/Kconfig.arm|   8 ++
   drivers/cpufreq/Kconfig.powerpc|  11 +-
   drivers/cpufreq/Makefile   |   2 +-
   .../{ppc-corenet-cpufreq.c = qoriq-cpufreq.c} | 150
 ++---
   4 files changed, 114 insertions(+), 57 deletions(-)  rename
  drivers/cpufreq/{ppc-corenet-cpufreq.c = qoriq-cpufreq.c} (72%)
 
  diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
  index 83a75dc..1925ae94 100644
  --- a/drivers/cpufreq/Kconfig.arm
  +++ b/drivers/cpufreq/Kconfig.arm
  @@ -247,3 +247,11 @@ config ARM_TEGRA_CPUFREQ
  default y
  help
This adds the CPUFreq driver support for TEGRA SOCs.
  +
  +config QORIQ_CPUFREQ
  +   tristate CPU frequency scaling driver for Freescale QorIQ SoCs
  +   depends on OF  COMMON_CLK
  +   select CLK_PPC_CORENET
  +   help
  + This adds the CPUFreq driver support for Freescale QorIQ SoCs
  + which are capable of changing the CPU's frequency dynamically.
  diff --git a/drivers/cpufreq/Kconfig.powerpc
  b/drivers/cpufreq/Kconfig.powerpc index 72564b7..3a34248 100644
  --- a/drivers/cpufreq/Kconfig.powerpc
  +++ b/drivers/cpufreq/Kconfig.powerpc
  @@ -23,14 +23,13 @@ config CPU_FREQ_MAPLE
This adds support for frequency switching on Maple 970FX
Evaluation Board and compatible boards (IBM JS2x blades).
 
  -config PPC_CORENET_CPUFREQ
  -   tristate CPU frequency scaling driver for Freescale E500MC SoCs
  -   depends on PPC_E500MC  OF  COMMON_CLK
  +config QORIQ_CPUFREQ
  +   tristate CPU frequency scaling driver for Freescale QorIQ SoCs
  +   depends on OF  COMMON_CLK
  select CLK_PPC_CORENET
  help
  - This adds the CPUFreq driver support for Freescale e500mc,
  - e5500 and e6500 series SoCs which are capable of changing
  - the CPU's frequency dynamically.
  + This adds the CPUFreq driver support for Freescale QorIQ SoCs
  + which are capable of changing the CPU's frequency dynamically.
 
   config CPU_FREQ_PMAC
  bool Support for Apple PowerBooks
 
 Don't need this duplication at all. Just move this to Kconfig instead of .arm 
 and
 ppc.
 
  diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
  b/drivers/cpufreq/qoriq-cpufreq.c
 
   /**
* struct cpu_data - per CPU data struct @@ -69,9 +68,6 @@ static
  const u32 *fmask;
 
   static DEFINE_PER_CPU(struct cpu_data *, cpu_data);
 
  -/* cpumask in a cluster */
  -static DEFINE_PER_CPU(cpumask_var_t, cpu_mask);
  -
   #ifndef CONFIG_SMP
   static inline const struct cpumask *cpu_core_mask(int cpu)  { @@
  -79,6 +75,79 @@ static inline const struct cpumask *cpu_core_mask(int
  cpu)  }  #endif
 
  +#if defined(CONFIG_PPC_E500MC)
  +static int get_cpu_physical_id(int cpu) {
  +   return get_hard_smp_processor_id(cpu); } #elif
  +defined(CONFIG_ARM)
 
 Wouldn't a #else work here as there are just two platforms we are talking 
 about ?
 
  +static int get_cpu_physical_id(int cpu) {
  +   return topology_core_id(cpu);
  +}
  +#endif
  +
  +static u32 get_bus_freq(void)
  +{
  +   struct device_node *soc;
  +   u32 sysfreq;
  +
  +   soc = of_find_node_by_type(NULL, soc);
  +   if (!soc)
  +   return 0;
  +
  +   if (of_property_read_u32(soc, bus-frequency, sysfreq))
  +   sysfreq = 0;
  +
  +   of_node_put(soc);
  +
  +   return sysfreq;
  +}
  +
  +static struct device_node *cpu_to_clk_node(int cpu) {
  +   struct device_node *np, *clk_np;
  +
  +   if (!cpu_present(cpu))
  +   return NULL;
  +
  +   np = of_get_cpu_node(cpu, NULL);
  +   if (!np)
  +   return NULL;
  +
  +   clk_np = of_parse_phandle(np, clocks, 0);
  +   if 

RE: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ platforms

[Yuantian Tang]

Thanks for your comments.  Will address them in next version.
Also some explanations inline for your comments.

Thanks,
Yuantian

 -Original Message-
 From: Kumar Gala [mailto:ga...@kernel.crashing.org]
 Sent: Friday, October 17, 2014 4:04 PM
 To: Tang Yuantian-B29983
 Cc: r...@rjwysocki.net; viresh.ku...@linaro.org; linux-ker...@vger.kernel.org;
 linux...@vger.kernel.org; linuxppc-...@ozlabs.org; Tang Yuantian-B29983
 Subject: Re: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ
 platforms
 
 
 On Oct 17, 2014, at 5:13 AM, b29...@freescale.com wrote:
 
  From: Tang Yuantian yuantian.t...@freescale.com
 
  Freescale introduced new ARM core-based SoCs which support dynamic
  frequency switch feature. DFS on new SoCs are compatible with current
  PowerPC CoreNet platforms. In order to support those new platforms,
  this driver needs to be slightly adjusted. The main changes include:
 
  1. Changed the names of driver and functions in driver.
 
 split the name changes/renaming into a separate patch from the other changes.
 
  2. Added two new functions get_cpu_physical_id() and get_bus_freq().
  3. Used a new way to get all the CPUs which sharing clock wire.
 
  Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
  ---
  drivers/cpufreq/Kconfig.arm|   8 ++
  drivers/cpufreq/Kconfig.powerpc|  11 +-
  drivers/cpufreq/Makefile   |   2 +-
  .../{ppc-corenet-cpufreq.c = qoriq-cpufreq.c} | 150 
  ++---
  4 files changed, 114 insertions(+), 57 deletions(-) rename
  drivers/cpufreq/{ppc-corenet-cpufreq.c = qoriq-cpufreq.c} (72%)
 
  diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
  index 83a75dc..1925ae94 100644
  --- a/drivers/cpufreq/Kconfig.arm
  +++ b/drivers/cpufreq/Kconfig.arm
  @@ -247,3 +247,11 @@ config ARM_TEGRA_CPUFREQ
  default y
  help
This adds the CPUFreq driver support for TEGRA SOCs.
  +
  +config QORIQ_CPUFREQ
  +   tristate CPU frequency scaling driver for Freescale QorIQ SoCs
  +   depends on OF  COMMON_CLK
  +   select CLK_PPC_CORENET
 
 Why are you not also renaming 'CLK_PPC_CORENET' to 'CLK_QORIQ' or
 something like that?  Seems rather odd to select a PPC CLK support on ARM ;)
 
Yes, someone else is working on that.

  +   help
  + This adds the CPUFreq driver support for Freescale QorIQ SoCs
  + which are capable of changing the CPU's frequency dynamically.
  diff --git a/drivers/cpufreq/Kconfig.powerpc
  b/drivers/cpufreq/Kconfig.powerpc index 72564b7..3a34248 100644
  --- a/drivers/cpufreq/Kconfig.powerpc
  +++ b/drivers/cpufreq/Kconfig.powerpc
  @@ -23,14 +23,13 @@ config CPU_FREQ_MAPLE
This adds support for frequency switching on Maple 970FX
Evaluation Board and compatible boards (IBM JS2x blades).
 
  -config PPC_CORENET_CPUFREQ
  -   tristate CPU frequency scaling driver for Freescale E500MC SoCs
  -   depends on PPC_E500MC  OF  COMMON_CLK
  +config QORIQ_CPUFREQ
  +   tristate CPU frequency scaling driver for Freescale QorIQ SoCs
  +   depends on OF  COMMON_CLK
  select CLK_PPC_CORENET
  help
  - This adds the CPUFreq driver support for Freescale e500mc,
  - e5500 and e6500 series SoCs which are capable of changing
  - the CPU's frequency dynamically.
  + This adds the CPUFreq driver support for Freescale QorIQ SoCs
  + which are capable of changing the CPU's frequency dynamically.
 
  config CPU_FREQ_PMAC
  bool Support for Apple PowerBooks
  diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index
  40c53dc..0020049 100644
  --- a/drivers/cpufreq/Makefile
  +++ b/drivers/cpufreq/Makefile
  @@ -84,7 +84,7 @@ obj-$(CONFIG_CPU_FREQ_CBE)+=
 ppc-cbe-cpufreq.o
  ppc-cbe-cpufreq-y   += ppc_cbe_cpufreq_pervasive.o
 ppc_cbe_cpufreq.o
  obj-$(CONFIG_CPU_FREQ_CBE_PMI)  += ppc_cbe_cpufreq_pmi.o
  obj-$(CONFIG_CPU_FREQ_MAPLE)+= maple-cpufreq.o
  -obj-$(CONFIG_PPC_CORENET_CPUFREQ)   += ppc-corenet-cpufreq.o
  +obj-$(CONFIG_QORIQ_CPUFREQ)+= qoriq-cpufreq.o
  obj-$(CONFIG_CPU_FREQ_PMAC) += pmac32-cpufreq.o
  obj-$(CONFIG_CPU_FREQ_PMAC64)   += pmac64-cpufreq.o
  obj-$(CONFIG_PPC_PASEMI_CPUFREQ)+= pasemi-cpufreq.o
  diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
  b/drivers/cpufreq/qoriq-cpufreq.c similarity index 72% rename from
  drivers/cpufreq/ppc-corenet-cpufreq.c
  rename to drivers/cpufreq/qoriq-cpufreq.c index bee5df7..80def0c
  100644
  --- a/drivers/cpufreq/ppc-corenet-cpufreq.c
  +++ b/drivers/cpufreq/qoriq-cpufreq.c
  @@ -1,7 +1,7 @@
  /*
   * Copyright 2013 Freescale Semiconductor, Inc.
   *
  - * CPU Frequency Scaling driver for Freescale PowerPC corenet SoCs.
  + * CPU Frequency Scaling driver for Freescale QorIQ SoCs.
   *
   * 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

RE: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support

[Yuantian Tang]

 -Original Message-
 From: Wood Scott-B07421
 Sent: Tuesday, September 30, 2014 7:58 AM
 To: Tang Yuantian-B29983
 Cc: Mike Turquette; linuxppc-dev@lists.ozlabs.org; 
 linux-ker...@vger.kernel.org;
 linux-arm-ker...@lists.infradead.org; Lu Jingchang-B35083
 Subject: Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add
 CLK_OF_DECLARE support
 
 On Sat, 2014-09-27 at 21:18 -0500, Tang Yuantian-B29983 wrote:
   -Original Message-
   From: Linuxppc-dev
   [mailto:linuxppc-dev-bounces+b29983=freescale@lists.ozlabs.org]
   On Behalf Of Mike Turquette
   Sent: Saturday, September 27, 2014 7:29 AM
   To: Wood Scott-B07421
   Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org;
   linux-arm-ker...@lists.infradead.org; Lu Jingchang-B35083
   Subject: Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add
   CLK_OF_DECLARE support
  
   Quoting Scott Wood (2014-09-25 15:56:20)
On Thu, 2014-09-25 at 15:54 -0700, Mike Turquette wrote:
 Quoting Scott Wood (2014-09-25 13:08:00)
  Well, like I said, I'd rather see the CLK_OF_DECLARE stuff be
  made to work on PPC rather than have the driver carry around
  two binding methods.

 I guess that is an existing problem, and not related directly to
 this patch? This patch is essentially just renames (though the
 V1.0/V2.0 stuff seems weird).
   
This patch is adding CLK_OF_DECLARE.
  
   I'm fine taking this patch but your comments are still unresolved.
   What do you think needs to be done to fix the problems that you see?
  
  CLK_OF_DECLARE is totally worked on PPC. I will do it in a separate patch.
  Regarding V1.0 and V2.0, it is not wired just same for now. But we are not 
  sure
 if it is same for v3.0 in the future.
 
  Besides updating drivers/cpufreq/Kconfig.powerpc, there is one more thing I
 am not comfortable with:
  This patch uses  fixed-clock as sysclk's compatible string, while on PPC 
  we
 treated it as  fsl,qoriq-sysclk-[1-2].0.
  That's inconsistent on both ARM and PPC platforms, neither did on bindings.
 
 fsl,qoriq-sysclk-XXX is the way it is because of compatibility with the 
 fixups in
 existing U-Boots.  It shouldn't be used as a model.
 
 That said, I don't think you really mean this patch, as it doesn't contain 
 the
 device tree updates, and fixed-clock does not appear.
 
fixed-clock will appear when ls102x platform DTS gets upstreamed eventually.
That would be fine if you don't think fsl,qoriq-sysclk-xxx having different 
meaning on ARM and PowerPC is a issue.

Thanks,
Yuantian
 -Scott
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support

[Yuantian Tang]

 -Original Message-
 From: Linuxppc-dev
 [mailto:linuxppc-dev-bounces+b29983=freescale@lists.ozlabs.org] On
 Behalf Of Mike Turquette
 Sent: Saturday, September 27, 2014 7:29 AM
 To: Wood Scott-B07421
 Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org;
 linux-arm-ker...@lists.infradead.org; Lu Jingchang-B35083
 Subject: Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add
 CLK_OF_DECLARE support
 
 Quoting Scott Wood (2014-09-25 15:56:20)
  On Thu, 2014-09-25 at 15:54 -0700, Mike Turquette wrote:
   Quoting Scott Wood (2014-09-25 13:08:00)
Well, like I said, I'd rather see the CLK_OF_DECLARE stuff be made
to work on PPC rather than have the driver carry around two
binding methods.
  
   I guess that is an existing problem, and not related directly to
   this patch? This patch is essentially just renames (though the
   V1.0/V2.0 stuff seems weird).
 
  This patch is adding CLK_OF_DECLARE.
 
 I'm fine taking this patch but your comments are still unresolved. What do you
 think needs to be done to fix the problems that you see?
 
CLK_OF_DECLARE is totally worked on PPC. I will do it in a separate patch.
Regarding V1.0 and V2.0, it is not wired just same for now. But we are not sure 
if it is same for v3.0 in the future.

Besides updating drivers/cpufreq/Kconfig.powerpc, there is one more thing I am 
not comfortable with:
This patch uses  fixed-clock as sysclk's compatible string, while on PPC we 
treated it as  fsl,qoriq-sysclk-[1-2].0.
That's inconsistent on both ARM and PPC platforms, neither did on bindings.

Thanks,
Yuantian

 Regards,
 Mike
 
 
  -Scott
 
 
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] clk: corenet: Update the clock bindings

[Yuantian Tang]

   Instead, how about a note like this near the top of the file:
  
   All references to 1.0 and 2.0 refer to the QorIQ chassis version
   to which the chip complies.
  
   Chassis Version   Example Chips
   ---   -
   1.0   p4080, p5020, p5040
   2.0   t4240, b4860, t1040
  
  Better, I will update.
 
  
   BTW, this binding and the associated driver really should be called
   qoriq-clock, not corenet-clock.  This would match the compatible
   string, and it doesn't really have much to do with corenet (which is
   part of the QorIQ chassis v1 and v2, but not *this* part).  Do you
   know if the chassis v3 clock interface will be similar enough to
 share a driver?
  
  Doesn't QorIQ include some low-end socs, like p1022, p1020?
 
 Yes, but those aren't QorIQ Chassis 1.0 or QorIQ Chassis 2.0.
 They're mpc85xx-family chips.
 
 In any case, if qoriq makes sense for the compatible, I don't see why
 it doesn't make sense for the driver.
 
So, Corenet is appropriate for driver.
If something should change, that must be compatible string.

Regards,
Yuantian

  This driver has nothing to do with these boards.
  I have no idea about chassis v3. If it has similar clock tree, this
 driver can be shared.
  Even the driver can't be used by v3, we can easily add v3 support
  since it has different Compatible string.
 
 The reason I mentioned it is that chassis v3 will involve ARM chips that
 have their own interconnect rather than corenet.
 
 -Scott
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] clk: corenet: Update the clock bindings

[Yuantian Tang]

 -Original Message-
 From: Wood Scott-B07421
 Sent: 2014年1月24日 星期五 10:36
 To: Tang Yuantian-B29983
 Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org;
 devicet...@vger.kernel.org; Kushwaha Prabhakar-B32579
 Subject: Re: [PATCH] clk: corenet: Update the clock bindings
 
 On Thu, 2014-01-23 at 20:33 -0600, Tang Yuantian-B29983 wrote:
 Instead, how about a note like this near the top of the file:

 All references to 1.0 and 2.0 refer to the QorIQ chassis
 version to which the chip complies.

 Chassis Version   Example Chips
 ---   -
 1.0   p4080, p5020, p5040
 2.0   t4240, b4860, t1040

Better, I will update.
   

 BTW, this binding and the associated driver really should be
 called qoriq-clock, not corenet-clock.  This would match the
 compatible string, and it doesn't really have much to do with
 corenet (which is part of the QorIQ chassis v1 and v2, but not
 *this* part).  Do you know if the chassis v3 clock interface
 will be similar enough to
   share a driver?

Doesn't QorIQ include some low-end socs, like p1022, p1020?
  
   Yes, but those aren't QorIQ Chassis 1.0 or QorIQ Chassis 2.0.
   They're mpc85xx-family chips.
  
   In any case, if qoriq makes sense for the compatible, I don't see
   why it doesn't make sense for the driver.
  
  So, Corenet is appropriate for driver.
  If something should change, that must be compatible string.
 
 No.  Corenet is a bus interconnect, not a chip family (despite abuse of
 the name in other contexts in Linux/U-Boot).  And the binding with qoriq
 has already been accepted.
 
QorIQ is not the best name either since it include the low-end socs.
What the name should be? 

Regards,
Yuantian

 -Scott
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] clk: corenet: Update the clock bindings

[Yuantian Tang]

 In any case, if qoriq makes sense for the compatible, I don't
 see why it doesn't make sense for the driver.

So, Corenet is appropriate for driver.
If something should change, that must be compatible string.
  
   No.  Corenet is a bus interconnect, not a chip family (despite abuse
   of the name in other contexts in Linux/U-Boot).  And the binding
   with qoriq has already been accepted.
  
  QorIQ is not the best name either since it include the low-end socs.
  What the name should be?
 
 Again, those low-end chips do not implement QorIQ Chassis 1.0 or QorIQ
 Chassis 2.0.  That they have QorIQ in their name is irrelevant.
 
Got it. 

Regards,
Yuantian

 -Scott
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] clk: corenet: Update the clock bindings

[Yuantian Tang]

 -Original Message-
 From: Wood Scott-B07421
 Sent: 2014年1月23日 星期四 8:44
 To: Tang Yuantian-B29983
 Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc-
 d...@lists.ozlabs.org; devicet...@vger.kernel.org; Kushwaha Prabhakar-
 B32579
 Subject: Re: [PATCH] clk: corenet: Update the clock bindings
 
 On Tue, 2014-01-21 at 10:02 +0800, Tang Yuantian wrote:
  From: Tang Yuantian yuantian.t...@freescale.com
 
  Main changs include:
  - Clarified the clock nodes' version number
  - Fixed a issue in example
 
  Singed-off-by: Tang Yuantian yuantian.t...@freescale.com
  ---
   Documentation/devicetree/bindings/clock/corenet-clock.txt | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)
 
  diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt
  b/Documentation/devicetree/bindings/clock/corenet-clock.txt
  index 24711af..d6cadef 100644
  --- a/Documentation/devicetree/bindings/clock/corenet-clock.txt
  +++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
  @@ -54,6 +54,8 @@ Required properties:
  It takes parent's clock-frequency as its clock.
  * fsl,qoriq-sysclk-2.0: for input system clock (v2.0).
  It takes parent's clock-frequency as its clock.
  +   Note: v1.0 and v2.0 are clock version which should align to
  +   clockgen node's they belong to which is chassis version.
 
 Instead, how about a note like this near the top of the file:
 
 All references to 1.0 and 2.0 refer to the QorIQ chassis version to
 which the chip complies.
 
 Chassis Version   Example Chips
 ---   -
 1.0   p4080, p5020, p5040
 2.0   t4240, b4860, t1040
 
Better, I will update.

 
 BTW, this binding and the associated driver really should be called
 qoriq-clock, not corenet-clock.  This would match the compatible
 string, and it doesn't really have much to do with corenet (which is part
 of the QorIQ chassis v1 and v2, but not *this* part).  Do you know if the
 chassis v3 clock interface will be similar enough to share a driver?
 
Doesn't QorIQ include some low-end socs, like p1022, p1020? 
This driver has nothing to do with these boards. 
I have no idea about chassis v3. If it has similar clock tree, this driver can 
be shared.
Even the driver can't be used by v3, we can easily add v3 support since it has 
different
Compatible string.

Regards,
Yuantian

 -Scott
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v9] clk: corenet: Adds the clock binding

[Yuantian Tang]

 -Original Message-
 From: Wood Scott-B07421
 Sent: 2014年1月18日 星期六 9:06
 To: Tang Yuantian-B29983
 Cc: Wood Scott-B07421; ga...@kernel.crashing.org; mark.rutl...@arm.com;
 devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Li Yang-Leo-
 R58472
 Subject: Re: [PATCH v9] clk: corenet: Adds the clock binding
 
 On Mon, 2014-01-13 at 16:16 +0800, Tang Yuantian wrote:
  +Example for clock block and clock provider:
  +/ {
  +   clockgen: global-utilities@e1000 {
  +   compatible = fsl,p5020-clockgen, fsl,qoriq-clockgen-1.0;
  +   ranges = 0x0 0xe1000 0x1000;
  +   clock-frequency = 13;
 
 Missing  around 13, and the actual p5020ds input clock (based on
 observing what U-Boot fills in) is 1, not 13.
 
Sorry, :(

 I'll fix when applying.
 
Thank you very much.

Regards,
Yuantian

 -Scott
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: 答复: [v7] clk: corenet: Adds the clock binding

[Yuantian Tang]

Thanks for your review. I will send next version of patch.

Thanks,
Yuantian


 -Original Message-
 From: Wood Scott-B07421
 Sent: 2014年1月10日 星期五 5:19
 To: Tang Yuantian-B29983
 Cc: Mark Rutland; ga...@kernel.crashing.org; devicet...@vger.kernel.org;
 linuxppc-dev@lists.ozlabs.org
 Subject: Re: 答复: [v7] clk: corenet: Adds the clock binding
 
 On Wed, 2014-01-08 at 20:57 -0600, Tang Yuantian-B29983 wrote:
  Thanks for you review.
  See my response inline.
 
  Thanks,
  Yuantian
 
   -Original Message-
   From: Wood Scott-B07421
   Sent: 2014年1月9日 星期四 2:44
   To: Mark Rutland
   Cc: Tang Yuantian-B29983; ga...@kernel.crashing.org;
   devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
   Subject: Re: 答复: [v7] clk: corenet: Adds the clock binding
  
   On Wed, 2014-01-08 at 09:30 +, Mark Rutland wrote:
On Wed, Jan 08, 2014 at 08:53:56AM +, Yuantian Tang wrote:

 
 发件人: Wood Scott-B07421
 发送时间: 2014年1月8日 8:21
 收件人: Tang Yuantian-B29983
 抄送: ga...@kernel.crashing.org; mark.rutl...@arm.com;
 devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
 主题: Re: [v7] clk: corenet: Adds the clock binding

 On Wed, Nov 20, 2013 at 05:04:49PM +0800, tang yuantian wrote:
  +Recommended properties:
  +- ranges: Allows valid translation between child's address
  +space
   and
  + parent's. Must be present if the device has sub-nodes.
  +- #address-cells: Specifies the number of cells used to
 represent
  + physical base addresses.  Must be present if the device
 has
  + sub-nodes and set to 1 if present
  +- #size-cells: Specifies the number of cells used to represent
  + the size of an address. Must be present if the device has
  + sub-nodes and set to 1 if present

 Why are we specifying #address-cells/#size-cells here?

 A: it has sub-nodes which have REG property, don't we need to
 specify #address-cells/#size-cells?
   
If a node has a reg entry, its parent should have #size-cells and
#address-cells to allow it to be parsed properly.
  
   Yes, but why do we need to specify in this binding how many cells
   there will be, especially since this binding only addresses the
   clock provider aspect of the clockgen nodes (e.g. it doesn't
   describe the reg)?  Or rather, it's partially describing the
   non-clock aspect, and doesn't address the clock aspect at all AFAICT.
  
  First of all, they are not Required properties, they are optional.
  If present, we should give them a value of 1.
 
 Why does it matter, so long as the values translate properly?  It's not
 as if you're defining a special reg format.  It's not that big of a deal,
 but it seems unnecessary.
 
  Then, yes, this binding describes clockgen node which is CLOCK BLOCK.
 
 Sorry, I missed where reg was documented due to the
 required/recommended split.
 
   Where does the actual input clock frequency go?  U-Boot puts it in
   the clockgen node itself as clock-frequency, but that isn't
   described in the binding.  How does that relate to the sysclk node?
   If fsl,qoriq-sysclk- 1.0 is supposed to indicate that
   clock-frequency can be found in the parent node, that isn't
   specified by the binding, nor is clock-frequency shown in the example.
  
  clock-frequency is a wired property.
 
 Do you mean weird?
 
  It is in clockgen node right now.
  But it should be placed somewhere in clock nodes.
 
 If we were doing this from scratch, yes, but there's existing U-Boot code
 that we want to be compatible with.
 
  If I describe here, I would be asked why it is related to clockgen node?
 
 That's not a good reason to leave it undocumented.
 
   What is the difference between fsl,qoriq-sysclk-1.0 and
   fsl,qoriq- sysclk-2.0?  How does the concept of a fixed input clock
 change?
  
  Technically, there is no difference between *sysclk-1.0 and *-2.0,
  just like
  Clockgen-2.0 and 1.0. Naming like this just to indicate they belong to
  chassis 2.0 and 1.0 respectively.
 
 I guess it's OK if it encourages people to consider switching to the
 standard fixed-clock for future chassis.
 
 So the only thing that really needs to be fixed is the missing clock-
 frequency documentation.
 
 -Scott
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

答复: [v7] clk: corenet: Adds the clock binding

[Yuantian Tang]

发件人: Wood Scott-B07421
发送时间: 2014年1月8日 8:21
收件人: Tang Yuantian-B29983
抄送: ga...@kernel.crashing.org; mark.rutl...@arm.com; 
devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
主题: Re: [v7] clk: corenet: Adds the clock binding

On Wed, Nov 20, 2013 at 05:04:49PM +0800, tang yuantian wrote:
 +Recommended properties:
 +- ranges: Allows valid translation between child's address space and
 + parent's. Must be present if the device has sub-nodes.
 +- #address-cells: Specifies the number of cells used to represent
 + physical base addresses.  Must be present if the device has
 + sub-nodes and set to 1 if present
 +- #size-cells: Specifies the number of cells used to represent
 + the size of an address. Must be present if the device has
 + sub-nodes and set to 1 if present

Why are we specifying #address-cells/#size-cells here?

A: it has sub-nodes which have REG property, don't we need to 
specify #address-cells/#size-cells?
 
 +2. Clock Provider/Consumer Binding
 +
 +Most of the bindings are from the common clock binding[1].
 + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 +
 +Required properties:
 +- compatible : Should include one of the following:
 + * fsl,qoriq-core-pll-1.0 for core PLL clocks (v1.0)
 +* fsl,qoriq-core-pll-2.0 for core PLL clocks (v2.0)
 +* fsl,qoriq-core-mux-1.0 for core mux clocks (v1.0)
 +* fsl,qoriq-core-mux-2.0 for core mux clocks (v2.0)
 + * fsl,qoriq-sysclk-1.0: for input system clock (v1.0)
 + * fsl,qoriq-sysclk-2.0: for input system clock (v2.0)

Some of those lines use tabs and others spaces -- I can fix when applying.
A: sorry for this and thanks for fixing.

Regards,
Yuantian

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: 答复: [v7] clk: corenet: Adds the clock binding

[Yuantian Tang]

Thanks for you review.
See my response inline.

Thanks,
Yuantian

 -Original Message-
 From: Wood Scott-B07421
 Sent: 2014年1月9日 星期四 2:44
 To: Mark Rutland
 Cc: Tang Yuantian-B29983; ga...@kernel.crashing.org;
 devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
 Subject: Re: 答复: [v7] clk: corenet: Adds the clock binding
 
 On Wed, 2014-01-08 at 09:30 +, Mark Rutland wrote:
  On Wed, Jan 08, 2014 at 08:53:56AM +, Yuantian Tang wrote:
  
   
   发件人: Wood Scott-B07421
   发送时间: 2014年1月8日 8:21
   收件人: Tang Yuantian-B29983
   抄送: ga...@kernel.crashing.org; mark.rutl...@arm.com;
   devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
   主题: Re: [v7] clk: corenet: Adds the clock binding
  
   On Wed, Nov 20, 2013 at 05:04:49PM +0800, tang yuantian wrote:
+Recommended properties:
+- ranges: Allows valid translation between child's address space
 and
+ parent's. Must be present if the device has sub-nodes.
+- #address-cells: Specifies the number of cells used to represent
+ physical base addresses.  Must be present if the device has
+ sub-nodes and set to 1 if present
+- #size-cells: Specifies the number of cells used to represent
+ the size of an address. Must be present if the device has
+ sub-nodes and set to 1 if present
  
   Why are we specifying #address-cells/#size-cells here?
  
   A: it has sub-nodes which have REG property, don't we need to
   specify #address-cells/#size-cells?
 
  If a node has a reg entry, its parent should have #size-cells and
  #address-cells to allow it to be parsed properly.
 
 Yes, but why do we need to specify in this binding how many cells there
 will be, especially since this binding only addresses the clock provider
 aspect of the clockgen nodes (e.g. it doesn't describe the reg)?  Or
 rather, it's partially describing the non-clock aspect, and doesn't
 address the clock aspect at all AFAICT.
 
First of all, they are not Required properties, they are optional.
If present, we should give them a value of 1.
Then, yes, this binding describes clockgen node which is CLOCK BLOCK.
It should take care of its sub-nodes which are clock nodes to be parsed 
properly.

 Where does the actual input clock frequency go?  U-Boot puts it in the
 clockgen node itself as clock-frequency, but that isn't described in the
 binding.  How does that relate to the sysclk node?  If fsl,qoriq-sysclk-
 1.0 is supposed to indicate that clock-frequency can be found in the
 parent node, that isn't specified by the binding, nor is clock-frequency
 shown in the example.
 
clock-frequency is a wired property. It is in clockgen node right now.
But it should be placed somewhere in clock nodes.
If I describe here, I would be asked why it is related to clockgen node?
If you think showing it up is OK, I like to do it.
 
 What is the difference between fsl,qoriq-sysclk-1.0 and fsl,qoriq-
 sysclk-2.0?  How does the concept of a fixed input clock change?

Technically, there is no difference between *sysclk-1.0 and *-2.0, just like
Clockgen-2.0 and 1.0. Naming like this just to indicate they belong to chassis 
2.0 
and 1.0 respectively.

Regards,
Yuantian
 
 -Scott
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v7] clk: corenet: Adds the clock binding

[Yuantian Tang]

PING.

Thanks,
Yuantian

 -Original Message-
 From: Tang Yuantian-B29983
 Sent: 2013年11月20日 星期三 17:05
 To: ga...@kernel.crashing.org
 Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
 mark.rutl...@arm.com; Wood Scott-B07421; grant.lik...@secretlab.ca; Tang
 Yuantian-B29983; Tang Yuantian-B29983; Li Yang-Leo-R58472
 Subject: [PATCH v7] clk: corenet: Adds the clock binding
 
 From: Tang Yuantian yuantian.t...@freescale.com
 
 Adds the clock bindings for Freescale PowerPC CoreNet platforms
 
 Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
 Signed-off-by: Li Yang le...@freescale.com
 ---
 v7:
   - refined some properties' definitions
 v6:
   - splited the previous patch into 2 parts, one is for binding(this
 one),
 the other is for DTS modification(will submit once this gets
 accepted)
   - fixed typo
   - refined #clock-cells and clock-output-names properties
   - removed fixed-clock compatible string
 v5:
   - refine the binding document
   - update the compatible string
 v4:
   - add binding document
   - update compatible string
   - update the reg property
 v3:
   - fix typo
 v2:
   - add t4240, b4420, b4860 support
   - remove pll/4 clock from p2041, p3041 and p5020 board
  .../devicetree/bindings/clock/corenet-clock.txt| 128
 +
  1 file changed, 128 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/clock/corenet-
 clock.txt
 
 diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt
 b/Documentation/devicetree/bindings/clock/corenet-clock.txt
 new file mode 100644
 index 000..609ba2b
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
 @@ -0,0 +1,128 @@
 +* Clock Block on Freescale CoreNet Platforms
 +
 +Freescale CoreNet chips take primary clocking input from the external
 +SYSCLK signal. The SYSCLK input (frequency) is multiplied using
 +multiple phase locked loops (PLL) to create a variety of frequencies
 +which can then be passed to a variety of internal logic, including
 +cores and peripheral IP blocks.
 +Please refer to the Reference Manual for details.
 +
 +1. Clock Block Binding
 +
 +Required properties:
 +- compatible: Should contain a specific clock block compatible string
 + and a single chassis clock compatible string.
 + Clock block strings include, but not limited to, one of the:
 + * fsl,p2041-clockgen
 + * fsl,p3041-clockgen
 + * fsl,p4080-clockgen
 + * fsl,p5020-clockgen
 + * fsl,p5040-clockgen
 + * fsl,t4240-clockgen
 + * fsl,b4420-clockgen
 + * fsl,b4860-clockgen
 + Chassis clock strings include:
 + * fsl,qoriq-clockgen-1.0: for chassis 1.0 clocks
 + * fsl,qoriq-clockgen-2.0: for chassis 2.0 clocks
 +- reg: Offset and length of the clock register set
 +
 +Recommended properties:
 +- ranges: Allows valid translation between child's address space and
 + parent's. Must be present if the device has sub-nodes.
 +- #address-cells: Specifies the number of cells used to represent
 + physical base addresses.  Must be present if the device has
 + sub-nodes and set to 1 if present
 +- #size-cells: Specifies the number of cells used to represent
 + the size of an address. Must be present if the device has
 + sub-nodes and set to 1 if present
 +
 +2. Clock Provider/Consumer Binding
 +
 +Most of the bindings are from the common clock binding[1].
 + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 +
 +Required properties:
 +- compatible : Should include one of the following:
 + * fsl,qoriq-core-pll-1.0 for core PLL clocks (v1.0)
 +* fsl,qoriq-core-pll-2.0 for core PLL clocks (v2.0)
 +* fsl,qoriq-core-mux-1.0 for core mux clocks (v1.0)
 +* fsl,qoriq-core-mux-2.0 for core mux clocks (v2.0)
 + * fsl,qoriq-sysclk-1.0: for input system clock (v1.0)
 + * fsl,qoriq-sysclk-2.0: for input system clock (v2.0)
 +- #clock-cells: From common clock binding. The number of cells in a
 + clock-specifier. Should be 0 for fsl,qoriq-sysclk-[1,2].0
 + clocks, or 1 for fsl,qoriq-core-pll-[1,2].0 clocks.
 + For fsl,qoriq-core-pll-[1,2].0 clocks, the single
 + clock-specifier cell may take the following values:
 + * 0 - equal to the PLL frequency
 + * 1 - equal to the PLL frequency divided by 2
 + * 2 - equal to the PLL frequency divided by 4
 +
 +Recommended properties:
 +- clocks: Should be the phandle of input parent clock
 +- clock-names: From common clock binding, indicates the clock name
 +- clock-output-names: From common clock binding, indicates the names of
 + output clocks
 +- reg: Should be the offset and length of clock block base address.
 + The length should be 4.
 +
 +Example for clock block and clock provider:
 +/ {
 + clockgen: global-utilities@e1000 {
 + compatible = fsl,p5020-clockgen, fsl,qoriq-clockgen-1.0;
 + ranges = 0x0 0xe1000 0x1000;
 +

RE: [PATCH v7] clk: corenet: Adds the clock binding

[Yuantian Tang]

Hi Scott,
Do you have any comments about this patch? If not, please pick it up.

Thanks,
Yuantian

 -Original Message-
 From: Tang Yuantian-B29983
 Sent: 2013年11月20日 星期三 17:05
 To: ga...@kernel.crashing.org
 Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
 mark.rutl...@arm.com; Wood Scott-B07421; grant.lik...@secretlab.ca; Tang
 Yuantian-B29983; Tang Yuantian-B29983; Li Yang-Leo-R58472
 Subject: [PATCH v7] clk: corenet: Adds the clock binding
 
 From: Tang Yuantian yuantian.t...@freescale.com
 
 Adds the clock bindings for Freescale PowerPC CoreNet platforms
 
 Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
 Signed-off-by: Li Yang le...@freescale.com
 ---
 v7:
   - refined some properties' definitions
 v6:
   - splited the previous patch into 2 parts, one is for binding(this
 one),
 the other is for DTS modification(will submit once this gets
 accepted)
   - fixed typo
   - refined #clock-cells and clock-output-names properties
   - removed fixed-clock compatible string
 v5:
   - refine the binding document
   - update the compatible string
 v4:
   - add binding document
   - update compatible string
   - update the reg property
 v3:
   - fix typo
 v2:
   - add t4240, b4420, b4860 support
   - remove pll/4 clock from p2041, p3041 and p5020 board
  .../devicetree/bindings/clock/corenet-clock.txt| 128
 +
  1 file changed, 128 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/clock/corenet-
 clock.txt
 
 diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt
 b/Documentation/devicetree/bindings/clock/corenet-clock.txt
 new file mode 100644
 index 000..609ba2b
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
 @@ -0,0 +1,128 @@
 +* Clock Block on Freescale CoreNet Platforms
 +
 +Freescale CoreNet chips take primary clocking input from the external
 +SYSCLK signal. The SYSCLK input (frequency) is multiplied using
 +multiple phase locked loops (PLL) to create a variety of frequencies
 +which can then be passed to a variety of internal logic, including
 +cores and peripheral IP blocks.
 +Please refer to the Reference Manual for details.
 +
 +1. Clock Block Binding
 +
 +Required properties:
 +- compatible: Should contain a specific clock block compatible string
 + and a single chassis clock compatible string.
 + Clock block strings include, but not limited to, one of the:
 + * fsl,p2041-clockgen
 + * fsl,p3041-clockgen
 + * fsl,p4080-clockgen
 + * fsl,p5020-clockgen
 + * fsl,p5040-clockgen
 + * fsl,t4240-clockgen
 + * fsl,b4420-clockgen
 + * fsl,b4860-clockgen
 + Chassis clock strings include:
 + * fsl,qoriq-clockgen-1.0: for chassis 1.0 clocks
 + * fsl,qoriq-clockgen-2.0: for chassis 2.0 clocks
 +- reg: Offset and length of the clock register set
 +
 +Recommended properties:
 +- ranges: Allows valid translation between child's address space and
 + parent's. Must be present if the device has sub-nodes.
 +- #address-cells: Specifies the number of cells used to represent
 + physical base addresses.  Must be present if the device has
 + sub-nodes and set to 1 if present
 +- #size-cells: Specifies the number of cells used to represent
 + the size of an address. Must be present if the device has
 + sub-nodes and set to 1 if present
 +
 +2. Clock Provider/Consumer Binding
 +
 +Most of the bindings are from the common clock binding[1].
 + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 +
 +Required properties:
 +- compatible : Should include one of the following:
 + * fsl,qoriq-core-pll-1.0 for core PLL clocks (v1.0)
 +* fsl,qoriq-core-pll-2.0 for core PLL clocks (v2.0)
 +* fsl,qoriq-core-mux-1.0 for core mux clocks (v1.0)
 +* fsl,qoriq-core-mux-2.0 for core mux clocks (v2.0)
 + * fsl,qoriq-sysclk-1.0: for input system clock (v1.0)
 + * fsl,qoriq-sysclk-2.0: for input system clock (v2.0)
 +- #clock-cells: From common clock binding. The number of cells in a
 + clock-specifier. Should be 0 for fsl,qoriq-sysclk-[1,2].0
 + clocks, or 1 for fsl,qoriq-core-pll-[1,2].0 clocks.
 + For fsl,qoriq-core-pll-[1,2].0 clocks, the single
 + clock-specifier cell may take the following values:
 + * 0 - equal to the PLL frequency
 + * 1 - equal to the PLL frequency divided by 2
 + * 2 - equal to the PLL frequency divided by 4
 +
 +Recommended properties:
 +- clocks: Should be the phandle of input parent clock
 +- clock-names: From common clock binding, indicates the clock name
 +- clock-output-names: From common clock binding, indicates the names of
 + output clocks
 +- reg: Should be the offset and length of clock block base address.
 + The length should be 4.
 +
 +Example for clock block and clock provider:
 +/ {
 + clockgen: global-utilities@e1000 {
 + compatible = fsl,p5020-clockgen, 

RE: [PATCH v6] clk: corenet: Adds the clock binding

[Yuantian Tang]

  +++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
  @@ -0,0 +1,123 @@
  +* Clock Block on Freescale CoreNet Platforms
  +
  +Freescale CoreNet chips take primary clocking input from the external
  +SYSCLK signal. The SYSCLK input (frequency) is multiplied using
  +multiple phase locked loops (PLL) to create a variety of frequencies
  +which can then be passed to a variety of internal logic, including
  +cores and peripheral IP blocks.
  +Please refer to the Reference Manual for details.
  +
  +1. Clock Block Binding
  +
  +Required properties:
  +- compatible: Should include one or more of the following:
 
 When you say one or more, I assume you mean of the specific clock block
 strings, and then a chassis string?
 
 If so, it might be better to say smoething like:
 
 - compatible: Should contain a specific clock block compatible string
   and a single chassis clock compatible string.
 
   Clock block strings include:
   * fsl,p2041-clockgen
   * fsl,p3041-clockgen
 
   Chassis clock strings include:
   * fsl,qoriq-clockgen-1.0: for chassis 1.0 clocks
   * fsl,qoriq-clockgen-2.0: for chassis 2.0 clock
 
Sounds better.

  +   * fsl,chip-clockgen: for chip specific clock block, here chip
  +   could be but not limited to one of the: p2041, p3041, p4080,
  +   p5020, p5040, t4240, b4420, b4860
  +   * fsl,qoriq-clockgen-1.0: for chassis 1.0 clocks
  +   * fsl,qoriq-clockgen-2.0: for chassis 2.0 clocks
  +   Notes that fsl,qoriq-clockgen-1.0 and fsl,qoriq-clockgen-2.0
  +   cannot be included simultaneously.
  +- reg: Offset and length of the clock register set
  +
  +Recommended properties:
  +- ranges: Allows valid translation between child's address space and
  +   parent's. Must be present if the device has sub-nodes.
  +- #address-cells: Specifies the number of cells used to represent
  +   physical base addresses.  Must be present if the device has
  +   sub-nodes and set to 1 if present
  +- #size-cells: Specifies the number of cells used to represent
  +   the size of an address. Must be present if the device has
  +   sub-nodes and set to 1 if present
 
 Is there any particular reason these _must_ be 1?
 
They are one u32 variable long and no other options, so, they should be set to 
1.

  +
  +2. Clock Provider/Consumer Binding
  +
  +Most of the bindings are from the common clock binding[1].
  + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
  +
  +Required properties:
  +- compatible : Should include one of the following:
  +   * fsl,qoriq-core-pll-1.0 for core PLL clocks (v1.0)
  +* fsl,qoriq-core-pll-2.0 for core PLL clocks (v2.0)
  +* fsl,qoriq-core-mux-1.0 for core mux clocks (v1.0)
  +* fsl,qoriq-core-mux-2.0 for core mux clocks (v2.0)
  +   * fsl,qoriq-sysclk-1.0: for input system clock (v1.0)
  +   * fsl,qoriq-sysclk-2.0: for input system clock (v2.0)
  +- #clock-cells: From common clock binding; indicates the number of
  +   output clock. 0 is for fsl,qoriq-sysclk-[1,2].0 and
  +   fsl,qoriq-core-mux-[1,2].0; 1 for fsl,qoriq-core-pll-[1,2].0.
 
 Nit: #clock-cells defines the number of cells in a clock-specifier, not
 the number of output clocks. How about:
 
 - #clock-cells: The number of cells in a clock-specifier. Should be 0
   for fsl,qoriq-sysclk-[1,2].0 clocks, or 1 for
   fsl,qoriq-core-pll-[1,2].0 clocks.
 
  +   If #clock-cells has a value of 1, its clock consumer should specify
  +   the desired clock by having the clock ID in its clocks phandle
  +   cell. The following is a full list IDs:
 
 The ID is in the clock-specifier, not the phandle. How about the
 following instead:
 
 For fsl,qoriq-core-pll-[1,2].0 clocks, the single clock-specifier cell
 may take the following values:
 
OK, thanks.

  +   * 0 - equal to the PLL frequency
  +   * 1 - equal to the PLL frequency divided by 2
  +   * 2 - equal to the PLL frequency divided by 4
  +
  +Recommended properties:
  +- clocks: Should be the phandle of input parent clock
  +- clock-names: From common clock binding, indicates the clock name
 
 Is this not well defined and common across all of the clocks? The set of
 inputs they have must be well known, and if it isn't then this property
 isn't all that useful.
 
  +- clock-output-names: From common clock binding, indicates the names
 of
  +   output clocks
 
 Similarly, I'd expect that there might be well defined output names.
 
The clock-output-names and clock-names vary both from nodes to nodes and
from platforms to platforms. There is no general rules to define it.
I think the *-names properties should be added easily by following the example 
below.

  +- reg: Should be the offset and length of clock block base address.
  +   The length should be 4.
  +
  +Example for clock block and clock provider:
  +/ {
  +   clockgen: global-utilities@e1000 {
  +   compatible = fsl,p5020-clockgen, fsl,qoriq-clockgen-1.0;
  +   ranges = 0x0 0xe1000 0x1000;
  +   reg = 0xe1000 0x1000;
  +