[PATCH v3] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[PATCH v3] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Xing Zheng]

The structure rockchip_clk_provider needs to refer the GRF regmap
in somewhere, if the CRU node has not "rockchip,grf" property,
calling syscon_regmap_lookup_by_phandle will return an invalid GRF
regmap, and the MUXGRF type clock will be not supported.

Therefore, we need to add them.

Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
---

Changes in v3:
- add optional roperty rockchip,grf in rockchip,rk3399-cru.txt

Changes in v2:
- referring pmugrf for PMUGRU
- fix the typo "invaild" in COMMIT message

 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 5 +++++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi                        | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
index 3888dd3..f476b3d 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
@@ -13,6 +13,11 @@ Required Properties:
 - #clock-cells: should be 1.
 - #reset-cells: should be 1.
 
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+  If missing pll rates are not changable, due to the missing pll lock status.
+
 Each clock is assigned an identifier and client nodes can use this identifier
 to specify the clock which they consume. All available clocks are defined as
 preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index c928015..081621b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1077,6 +1077,7 @@
 	pmucru: pmu-clock-controller at ff750000 {
 		compatible = "rockchip,rk3399-pmucru";
 		reg = <0x0 0xff750000 0x0 0x1000>;
+		rockchip,grf = <&pmugrf>;
 		#clock-cells = <1>;
 		#reset-cells = <1>;
 		assigned-clocks = <&pmucru PLL_PPLL>;
@@ -1086,6 +1087,7 @@
 	cru: clock-controller at ff760000 {
 		compatible = "rockchip,rk3399-cru";
 		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
 		#clock-cells = <1>;
 		#reset-cells = <1>;
 		assigned-clocks =
-- 
2.7.4

[PATCH v3] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Shawn Lin]

On 2017/1/10 9:27, Xing Zheng wrote:
> The structure rockchip_clk_provider needs to refer the GRF regmap
> in somewhere, if the CRU node has not "rockchip,grf" property,
> calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> regmap, and the MUXGRF type clock will be not supported.
>
> Therefore, we need to add them.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v3:
> - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
>
> Changes in v2:
> - referring pmugrf for PMUGRU
> - fix the typo "invaild" in COMMIT message
>
>  Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 5 +++++
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi                        | 2 ++
>  2 files changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
> index 3888dd3..f476b3d 100644
> --- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
> @@ -13,6 +13,11 @@ Required Properties:
>  - #clock-cells: should be 1.
>  - #reset-cells: should be 1.
>
> +Optional Properties:
> +
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> +  If missing pll rates are not changable, due to the missing pll lock status.
> +

It twists my tongue w/o proper punctuation:)

- rockchip,grf: phandle to the syscon managing the "general register 
files". If missing, pll rates are not changable due to the missing pll
lock status.


>  Each clock is assigned an identifier and client nodes can use this identifier
>  to specify the clock which they consume. All available clocks are defined as
>  preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index c928015..081621b 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1077,6 +1077,7 @@
>  	pmucru: pmu-clock-controller at ff750000 {
>  		compatible = "rockchip,rk3399-pmucru";
>  		reg = <0x0 0xff750000 0x0 0x1000>;
> +		rockchip,grf = <&pmugrf>;
>  		#clock-cells = <1>;
>  		#reset-cells = <1>;
>  		assigned-clocks = <&pmucru PLL_PPLL>;
> @@ -1086,6 +1087,7 @@
>  	cru: clock-controller at ff760000 {
>  		compatible = "rockchip,rk3399-cru";
>  		reg = <0x0 0xff760000 0x0 0x1000>;
> +		rockchip,grf = <&grf>;
>  		#clock-cells = <1>;
>  		#reset-cells = <1>;
>  		assigned-clocks =
>


-- 
Best Regards
Shawn Lin

[PATCH v3] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Doug Anderson]

Hi,

On Mon, Jan 9, 2017 at 5:27 PM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> The structure rockchip_clk_provider needs to refer the GRF regmap
> in somewhere, if the CRU node has not "rockchip,grf" property,
> calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> regmap, and the MUXGRF type clock will be not supported.
>
> Therefore, we need to add them.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v3:
> - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
>
> Changes in v2:
> - referring pmugrf for PMUGRU
> - fix the typo "invaild" in COMMIT message
>
>  Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 5 +++++
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi                        | 2 ++

"dts" and bindings shouldn't change in the same patch since they go
through different trees.  This is why I said:

> This looks sane to me, but before you land it you need to first send
> up a (separate) patch that adjusts:
>       --------

AKA: you need a two patch series here.

Sometimes it's OK to include bindings together with code changes
(depends on the maintainer), but never with dts changes.

-Doug

[PATCH v3] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Doug Anderson]

Hi,

On Mon, Jan 9, 2017 at 5:27 PM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> +Optional Properties:
> +
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> +  If missing pll rates are not changable, due to the missing pll lock status.

On rk3399 the GRF isn't used for pll lock status.  It's used for PLL muxes.

...so technically if you don't include it then the PLL muxes won't be
changeable.  Hopefully the code handles this if the property is listed
as "Optional".  ...and unless Heiko says otherwise, you probably need
to list it as "Optional" since (presumably) there might be backward
compatibility issues.

-Doug

[PATCH v3] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Xing Zheng]

Hi, Doug

On 2017?01?10? 11:06, Doug Anderson wrote:
> Hi,
>
> On Mon, Jan 9, 2017 at 5:27 PM, Xing Zheng <zhengxing@rock-chips.com> wrote:
>> The structure rockchip_clk_provider needs to refer the GRF regmap
>> in somewhere, if the CRU node has not "rockchip,grf" property,
>> calling syscon_regmap_lookup_by_phandle will return an invalid GRF
>> regmap, and the MUXGRF type clock will be not supported.
>>
>> Therefore, we need to add them.
>>
>> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
>> ---
>>
>> Changes in v3:
>> - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
>>
>> Changes in v2:
>> - referring pmugrf for PMUGRU
>> - fix the typo "invaild" in COMMIT message
>>
>>   Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 5 +++++
>>   arch/arm64/boot/dts/rockchip/rk3399.dtsi                        | 2 ++
> "dts" and bindings shouldn't change in the same patch since they go
> through different trees.  This is why I said:
>
>> This looks sane to me, but before you land it you need to first send
>> up a (separate) patch that adjusts:
>>        --------
> AKA: you need a two patch series here.
>
> Sometimes it's OK to include bindings together with code changes
> (depends on the maintainer), but never with dts changes.
>
> -Doug
For little lazy, I did refer other SoC platform to using "dts" and 
bindings in the same patch...

OK, I will use a two patch series.

Thanks

>
>

-- 
- Xing Zheng