[PATCH v4 0/2] Add support rockchip,grf property for RK3399 PMU/GRU

[PATCH v4 0/2] Add support rockchip,grf property for RK3399 PMU/GRU

[Xing Zheng]

Hi,
  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.

Thanks.


Changes in v4:
- separte the binding patch
- update the decription for rockchip,grf property

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

Xing Zheng (2):
  arm64: dts: rockchip: add "rockchip, grf" property for RK3399
    PMUCRU/CRU
  dt-bindings: clk: add rockchip,grf property for RK3399

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

-- 
2.7.4

[PATCH v4 0/2] Add support rockchip,grf property for RK3399 PMU/GRU

[Xing Zheng]

Hi,
  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.

Thanks.


Changes in v4:
- separte the binding patch
- update the decription for rockchip,grf property

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

Xing Zheng (2):
  arm64: dts: rockchip: add "rockchip, grf" property for RK3399
    PMUCRU/CRU
  dt-bindings: clk: add rockchip,grf property for RK3399

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

-- 
2.7.4

[PATCH v4 1/2] 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-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---

Changes in v4:
- separte the binding patch

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

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
 1 file changed, 2 insertions(+)

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@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@ff760000 {
 		compatible = "rockchip,rk3399-cru";
 		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
 		#clock-cells = <1>;
 		#reset-cells = <1>;
 		assigned-clocks =
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/2] 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 v4:
- separte the binding patch

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

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
 1 file changed, 2 insertions(+)

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@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@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 v4 1/2] 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 v4:
- separte the binding patch

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

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
 1 file changed, 2 insertions(+)

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

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Doug Anderson]

Hi,

On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org> 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-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
>
> Changes in v4:
> - separte the binding patch
>
> 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
>
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>  1 file changed, 2 insertions(+)

This seems fine to me, so:

Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

...but I will say that before you actually add any real "MUXGRF"
clocks on rk3399 you _might_ need to rework the code to make things
truly "optional".  If it turns out that any existing clocks that
already exist today already go through one of these muxes in the GRF
and we've always been assuming one setting of the mux, we'll need to
make sure we keep assuming that setting of the mux even if the "grf"
isn't specified.

As I understand it, your motivation for this patch is to eventually be
able to model the EDP reference clock which can either be xin24 or
"edp osc".  Presumably the eDP "reference clock" isn't related to any
of the pre-existing eDP clocks so that one should be safe.

-Doug

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Doug Anderson]

Hi,

On Mon, Jan 9, 2017 at 10:15 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 v4:
> - separte the binding patch
>
> 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
>
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>  1 file changed, 2 insertions(+)

This seems fine to me, so:

Reviewed-by: Douglas Anderson <dianders@chromium.org>

...but I will say that before you actually add any real "MUXGRF"
clocks on rk3399 you _might_ need to rework the code to make things
truly "optional".  If it turns out that any existing clocks that
already exist today already go through one of these muxes in the GRF
and we've always been assuming one setting of the mux, we'll need to
make sure we keep assuming that setting of the mux even if the "grf"
isn't specified.

As I understand it, your motivation for this patch is to eventually be
able to model the EDP reference clock which can either be xin24 or
"edp osc".  Presumably the eDP "reference clock" isn't related to any
of the pre-existing eDP clocks so that one should be safe.

-Doug

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

[Doug Anderson]

Hi,

On Mon, Jan 9, 2017 at 10:15 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 v4:
> - separte the binding patch
>
> 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
>
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>  1 file changed, 2 insertions(+)

This seems fine to me, so:

Reviewed-by: Douglas Anderson <dianders@chromium.org>

...but I will say that before you actually add any real "MUXGRF"
clocks on rk3399 you _might_ need to rework the code to make things
truly "optional".  If it turns out that any existing clocks that
already exist today already go through one of these muxes in the GRF
and we've always been assuming one setting of the mux, we'll need to
make sure we keep assuming that setting of the mux even if the "grf"
isn't specified.

As I understand it, your motivation for this patch is to eventually be
able to model the EDP reference clock which can either be xin24 or
"edp osc".  Presumably the eDP "reference clock" isn't related to any
of the pre-existing eDP clocks so that one should be safe.

-Doug

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Heiko Stübner]

Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> Hi,
> 
> On Mon, Jan 9, 2017 at 10:15 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 v4:
> > - separte the binding patch
> > 
> > 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
> > 
> >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> >  1 file changed, 2 insertions(+)
> 
> This seems fine to me, so:
> 
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> 
> ...but I will say that before you actually add any real "MUXGRF"
> clocks on rk3399 you _might_ need to rework the code to make things
> truly "optional".  If it turns out that any existing clocks that
> already exist today already go through one of these muxes in the GRF
> and we've always been assuming one setting of the mux, we'll need to
> make sure we keep assuming that setting of the mux even if the "grf"
> isn't specified.

I guess I see that a bit more relaxed :-) .

I.e. the GRF being optional is a remnant of syscons not being available when 
the clocks get set up- so were coming in later or not at all. For the rk3288 I 
converted, there we never really had the case of the GRF missing.

And the GRF mux for the vcodec now present is not being used by anything yet 
(neither driver nor binding), so no old devicetree can break.


> As I understand it, your motivation for this patch is to eventually be
> able to model the EDP reference clock which can either be xin24 or
> "edp osc".  Presumably the eDP "reference clock" isn't related to any
> of the pre-existing eDP clocks so that one should be safe.

Same here, so far we don't even have edp or even any other graphical output on 
the rk3399, so again there is no old devicetree that could break when the grf 
is not specified.


So, for me that looks good.


Heiko

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Heiko Stübner]

Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> Hi,
> 
> On Mon, Jan 9, 2017 at 10:15 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 v4:
> > - separte the binding patch
> > 
> > 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
> > 
> >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> >  1 file changed, 2 insertions(+)
> 
> This seems fine to me, so:
> 
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> 
> ...but I will say that before you actually add any real "MUXGRF"
> clocks on rk3399 you _might_ need to rework the code to make things
> truly "optional".  If it turns out that any existing clocks that
> already exist today already go through one of these muxes in the GRF
> and we've always been assuming one setting of the mux, we'll need to
> make sure we keep assuming that setting of the mux even if the "grf"
> isn't specified.

I guess I see that a bit more relaxed :-) .

I.e. the GRF being optional is a remnant of syscons not being available when 
the clocks get set up- so were coming in later or not at all. For the rk3288 I 
converted, there we never really had the case of the GRF missing.

And the GRF mux for the vcodec now present is not being used by anything yet 
(neither driver nor binding), so no old devicetree can break.


> As I understand it, your motivation for this patch is to eventually be
> able to model the EDP reference clock which can either be xin24 or
> "edp osc".  Presumably the eDP "reference clock" isn't related to any
> of the pre-existing eDP clocks so that one should be safe.

Same here, so far we don't even have edp or even any other graphical output on 
the rk3399, so again there is no old devicetree that could break when the grf 
is not specified.


So, for me that looks good.


Heiko

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

[Heiko Stübner]

Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> Hi,
> 
> On Mon, Jan 9, 2017 at 10:15 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 v4:
> > - separte the binding patch
> > 
> > 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
> > 
> >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> >  1 file changed, 2 insertions(+)
> 
> This seems fine to me, so:
> 
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> 
> ...but I will say that before you actually add any real "MUXGRF"
> clocks on rk3399 you _might_ need to rework the code to make things
> truly "optional".  If it turns out that any existing clocks that
> already exist today already go through one of these muxes in the GRF
> and we've always been assuming one setting of the mux, we'll need to
> make sure we keep assuming that setting of the mux even if the "grf"
> isn't specified.

I guess I see that a bit more relaxed :-) .

I.e. the GRF being optional is a remnant of syscons not being available when 
the clocks get set up- so were coming in later or not at all. For the rk3288 I 
converted, there we never really had the case of the GRF missing.

And the GRF mux for the vcodec now present is not being used by anything yet 
(neither driver nor binding), so no old devicetree can break.


> As I understand it, your motivation for this patch is to eventually be
> able to model the EDP reference clock which can either be xin24 or
> "edp osc".  Presumably the eDP "reference clock" isn't related to any
> of the pre-existing eDP clocks so that one should be safe.

Same here, so far we don't even have edp or even any other graphical output on 
the rk3399, so again there is no old devicetree that could break when the grf 
is not specified.


So, for me that looks good.


Heiko

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Heiko Stübner]

Hi Doug,

Am Dienstag, 10. Januar 2017, 20:46:12 schrieb Heiko Stübner:
> Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> > Hi,
> > 
> > On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> 
> 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-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> > > ---
> > > 
> > > Changes in v4:
> > > - separte the binding patch
> > > 
> > > 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
> > > 
> > >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> > >  1 file changed, 2 insertions(+)
> > 
> > This seems fine to me, so:
> > 
> > Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > 
> > ...but I will say that before you actually add any real "MUXGRF"
> > clocks on rk3399 you _might_ need to rework the code to make things
> > truly "optional".  If it turns out that any existing clocks that
> > already exist today already go through one of these muxes in the GRF
> > and we've always been assuming one setting of the mux, we'll need to
> > make sure we keep assuming that setting of the mux even if the "grf"
> > isn't specified.
> 
> I guess I see that a bit more relaxed :-) .
> 
> I.e. the GRF being optional is a remnant of syscons not being available when
> the clocks get set up- so were coming in later or not at all. For the
> rk3288 I converted, there we never really had the case of the GRF missing.
> 
> And the GRF mux for the vcodec now present is not being used by anything yet
> (neither driver nor binding), so no old devicetree can break.
> 
> > As I understand it, your motivation for this patch is to eventually be
> > able to model the EDP reference clock which can either be xin24 or
> > "edp osc".  Presumably the eDP "reference clock" isn't related to any
> > of the pre-existing eDP clocks so that one should be safe.
> 
> Same here, so far we don't even have edp or even any other graphical output
> on the rk3399, so again there is no old devicetree that could break when
> the grf is not specified.

reading all of the above again, it feels like you essentially also said 
similar things already in your original reply and I misread some of it.

But again, I don't see the need for any more code right now, as hopefully the 
simple stuff we currently only support does not have any grf-based muxes in 
it. Xing + Rockchip people, please correct me if I'm wrong here :-)


Heiko

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Heiko Stübner]

Hi Doug,

Am Dienstag, 10. Januar 2017, 20:46:12 schrieb Heiko Stübner:
> Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> > Hi,
> > 
> > On Mon, Jan 9, 2017 at 10:15 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 v4:
> > > - separte the binding patch
> > > 
> > > 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
> > > 
> > >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> > >  1 file changed, 2 insertions(+)
> > 
> > This seems fine to me, so:
> > 
> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > 
> > ...but I will say that before you actually add any real "MUXGRF"
> > clocks on rk3399 you _might_ need to rework the code to make things
> > truly "optional".  If it turns out that any existing clocks that
> > already exist today already go through one of these muxes in the GRF
> > and we've always been assuming one setting of the mux, we'll need to
> > make sure we keep assuming that setting of the mux even if the "grf"
> > isn't specified.
> 
> I guess I see that a bit more relaxed :-) .
> 
> I.e. the GRF being optional is a remnant of syscons not being available when
> the clocks get set up- so were coming in later or not at all. For the
> rk3288 I converted, there we never really had the case of the GRF missing.
> 
> And the GRF mux for the vcodec now present is not being used by anything yet
> (neither driver nor binding), so no old devicetree can break.
> 
> > As I understand it, your motivation for this patch is to eventually be
> > able to model the EDP reference clock which can either be xin24 or
> > "edp osc".  Presumably the eDP "reference clock" isn't related to any
> > of the pre-existing eDP clocks so that one should be safe.
> 
> Same here, so far we don't even have edp or even any other graphical output
> on the rk3399, so again there is no old devicetree that could break when
> the grf is not specified.

reading all of the above again, it feels like you essentially also said 
similar things already in your original reply and I misread some of it.

But again, I don't see the need for any more code right now, as hopefully the 
simple stuff we currently only support does not have any grf-based muxes in 
it. Xing + Rockchip people, please correct me if I'm wrong here :-)


Heiko

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

[Heiko Stübner]

Hi Doug,

Am Dienstag, 10. Januar 2017, 20:46:12 schrieb Heiko St?bner:
> Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> > Hi,
> > 
> > On Mon, Jan 9, 2017 at 10:15 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 v4:
> > > - separte the binding patch
> > > 
> > > 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
> > > 
> > >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> > >  1 file changed, 2 insertions(+)
> > 
> > This seems fine to me, so:
> > 
> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > 
> > ...but I will say that before you actually add any real "MUXGRF"
> > clocks on rk3399 you _might_ need to rework the code to make things
> > truly "optional".  If it turns out that any existing clocks that
> > already exist today already go through one of these muxes in the GRF
> > and we've always been assuming one setting of the mux, we'll need to
> > make sure we keep assuming that setting of the mux even if the "grf"
> > isn't specified.
> 
> I guess I see that a bit more relaxed :-) .
> 
> I.e. the GRF being optional is a remnant of syscons not being available when
> the clocks get set up- so were coming in later or not at all. For the
> rk3288 I converted, there we never really had the case of the GRF missing.
> 
> And the GRF mux for the vcodec now present is not being used by anything yet
> (neither driver nor binding), so no old devicetree can break.
> 
> > As I understand it, your motivation for this patch is to eventually be
> > able to model the EDP reference clock which can either be xin24 or
> > "edp osc".  Presumably the eDP "reference clock" isn't related to any
> > of the pre-existing eDP clocks so that one should be safe.
> 
> Same here, so far we don't even have edp or even any other graphical output
> on the rk3399, so again there is no old devicetree that could break when
> the grf is not specified.

reading all of the above again, it feels like you essentially also said 
similar things already in your original reply and I misread some of it.

But again, I don't see the need for any more code right now, as hopefully the 
simple stuff we currently only support does not have any grf-based muxes in 
it. Xing + Rockchip people, please correct me if I'm wrong here :-)


Heiko

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Doug Anderson]

Hi,

On Tue, Jan 10, 2017 at 11:58 AM, Heiko Stübner <heiko@sntech.de> wrote:
> Hi Doug,
>
> Am Dienstag, 10. Januar 2017, 20:46:12 schrieb Heiko Stübner:
>> Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
>> > Hi,
>> >
>> > On Mon, Jan 9, 2017 at 10:15 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 v4:
>> > > - separte the binding patch
>> > >
>> > > 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
>> > >
>> > >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>> > >  1 file changed, 2 insertions(+)
>> >
>> > This seems fine to me, so:
>> >
>> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
>> >
>> > ...but I will say that before you actually add any real "MUXGRF"
>> > clocks on rk3399 you _might_ need to rework the code to make things
>> > truly "optional".  If it turns out that any existing clocks that
>> > already exist today already go through one of these muxes in the GRF
>> > and we've always been assuming one setting of the mux, we'll need to
>> > make sure we keep assuming that setting of the mux even if the "grf"
>> > isn't specified.
>>
>> I guess I see that a bit more relaxed :-) .
>>
>> I.e. the GRF being optional is a remnant of syscons not being available when
>> the clocks get set up- so were coming in later or not at all. For the
>> rk3288 I converted, there we never really had the case of the GRF missing.
>>
>> And the GRF mux for the vcodec now present is not being used by anything yet
>> (neither driver nor binding), so no old devicetree can break.
>>
>> > As I understand it, your motivation for this patch is to eventually be
>> > able to model the EDP reference clock which can either be xin24 or
>> > "edp osc".  Presumably the eDP "reference clock" isn't related to any
>> > of the pre-existing eDP clocks so that one should be safe.
>>
>> Same here, so far we don't even have edp or even any other graphical output
>> on the rk3399, so again there is no old devicetree that could break when
>> the grf is not specified.
>
> reading all of the above again, it feels like you essentially also said
> similar things already in your original reply and I misread some of it.
>
> But again, I don't see the need for any more code right now, as hopefully the
> simple stuff we currently only support does not have any grf-based muxes in
> it. Xing + Rockchip people, please correct me if I'm wrong here :-)

Right.  I have no objection to Xing's patch.  I just want to make sure
that if it's listed as "Optional" that it's really optional.

I was worried that we would introduce some GRF-based mux in the
_middle_ of some existing clock tree because we simply didn't model
the mux before and assumed one particular setting.  If nothing like
that ever happens then we're fine.

Sorry to be so confusing.

-Doug

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

[Doug Anderson]

Hi,

On Tue, Jan 10, 2017 at 11:58 AM, Heiko St?bner <heiko@sntech.de> wrote:
> Hi Doug,
>
> Am Dienstag, 10. Januar 2017, 20:46:12 schrieb Heiko St?bner:
>> Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
>> > Hi,
>> >
>> > On Mon, Jan 9, 2017 at 10:15 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 v4:
>> > > - separte the binding patch
>> > >
>> > > 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
>> > >
>> > >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>> > >  1 file changed, 2 insertions(+)
>> >
>> > This seems fine to me, so:
>> >
>> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
>> >
>> > ...but I will say that before you actually add any real "MUXGRF"
>> > clocks on rk3399 you _might_ need to rework the code to make things
>> > truly "optional".  If it turns out that any existing clocks that
>> > already exist today already go through one of these muxes in the GRF
>> > and we've always been assuming one setting of the mux, we'll need to
>> > make sure we keep assuming that setting of the mux even if the "grf"
>> > isn't specified.
>>
>> I guess I see that a bit more relaxed :-) .
>>
>> I.e. the GRF being optional is a remnant of syscons not being available when
>> the clocks get set up- so were coming in later or not at all. For the
>> rk3288 I converted, there we never really had the case of the GRF missing.
>>
>> And the GRF mux for the vcodec now present is not being used by anything yet
>> (neither driver nor binding), so no old devicetree can break.
>>
>> > As I understand it, your motivation for this patch is to eventually be
>> > able to model the EDP reference clock which can either be xin24 or
>> > "edp osc".  Presumably the eDP "reference clock" isn't related to any
>> > of the pre-existing eDP clocks so that one should be safe.
>>
>> Same here, so far we don't even have edp or even any other graphical output
>> on the rk3399, so again there is no old devicetree that could break when
>> the grf is not specified.
>
> reading all of the above again, it feels like you essentially also said
> similar things already in your original reply and I misread some of it.
>
> But again, I don't see the need for any more code right now, as hopefully the
> simple stuff we currently only support does not have any grf-based muxes in
> it. Xing + Rockchip people, please correct me if I'm wrong here :-)

Right.  I have no objection to Xing's patch.  I just want to make sure
that if it's listed as "Optional" that it's really optional.

I was worried that we would introduce some GRF-based mux in the
_middle_ of some existing clock tree because we simply didn't model
the mux before and assumed one particular setting.  If nothing like
that ever happens then we're fine.

Sorry to be so confusing.

-Doug

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Heiko Stuebner]

Am Mittwoch, 11. Januar 2017, 16:50:10 CET schrieb Doug Anderson:
> Hi,
> 
> On Tue, Jan 10, 2017 at 11:58 AM, Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> > Hi Doug,
> > 
> > Am Dienstag, 10. Januar 2017, 20:46:12 schrieb Heiko Stübner:
> >> Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> >> > Hi,
> >> > 
> >> > On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >> 
> >> 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-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >> > > ---
> >> > > 
> >> > > Changes in v4:
> >> > > - separte the binding patch
> >> > > 
> >> > > 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
> >> > > 
> >> > >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> >> > >  1 file changed, 2 insertions(+)
> >> > 
> >> > This seems fine to me, so:
> >> > 
> >> > Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >> > 
> >> > ...but I will say that before you actually add any real "MUXGRF"
> >> > clocks on rk3399 you _might_ need to rework the code to make things
> >> > truly "optional".  If it turns out that any existing clocks that
> >> > already exist today already go through one of these muxes in the GRF
> >> > and we've always been assuming one setting of the mux, we'll need to
> >> > make sure we keep assuming that setting of the mux even if the "grf"
> >> > isn't specified.
> >> 
> >> I guess I see that a bit more relaxed :-) .
> >> 
> >> I.e. the GRF being optional is a remnant of syscons not being available
> >> when the clocks get set up- so were coming in later or not at all. For
> >> the rk3288 I converted, there we never really had the case of the GRF
> >> missing.
> >> 
> >> And the GRF mux for the vcodec now present is not being used by anything
> >> yet (neither driver nor binding), so no old devicetree can break.
> >> 
> >> > As I understand it, your motivation for this patch is to eventually be
> >> > able to model the EDP reference clock which can either be xin24 or
> >> > "edp osc".  Presumably the eDP "reference clock" isn't related to any
> >> > of the pre-existing eDP clocks so that one should be safe.
> >> 
> >> Same here, so far we don't even have edp or even any other graphical
> >> output
> >> on the rk3399, so again there is no old devicetree that could break when
> >> the grf is not specified.
> > 
> > reading all of the above again, it feels like you essentially also said
> > similar things already in your original reply and I misread some of it.
> > 
> > But again, I don't see the need for any more code right now, as hopefully
> > the simple stuff we currently only support does not have any grf-based
> > muxes in it. Xing + Rockchip people, please correct me if I'm wrong here
> > :-)
> Right.  I have no objection to Xing's patch.  I just want to make sure
> that if it's listed as "Optional" that it's really optional.
> 
> I was worried that we would introduce some GRF-based mux in the
> _middle_ of some existing clock tree because we simply didn't model
> the mux before and assumed one particular setting.  If nothing like
> that ever happens then we're fine.

Thankfully the clock diagrams on the old socs were pretty verbose, listing all
grf-based clocks as well. For example the rk3288 seems to have two and it
seems I've been carrying dummy definitions for those from the time I did the
initial clock tree [0].

And thankfully grf-based clocks somehow always only get used for more
"esotheric" components like vcodec and iep on the rk3288 :-) .


Heiko

[0] https://github.com/mmind/linux-rockchip/blob/devel/workbench/drivers/clk/rockchip/clk-rk3288.c
lines 371 and 799 .. looks like I'll need to add the iep clock as well
at some point.


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Heiko Stuebner]

Am Mittwoch, 11. Januar 2017, 16:50:10 CET schrieb Doug Anderson:
> Hi,
> 
> On Tue, Jan 10, 2017 at 11:58 AM, Heiko Stübner <heiko@sntech.de> wrote:
> > Hi Doug,
> > 
> > Am Dienstag, 10. Januar 2017, 20:46:12 schrieb Heiko Stübner:
> >> Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> >> > Hi,
> >> > 
> >> > On Mon, Jan 9, 2017 at 10:15 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 v4:
> >> > > - separte the binding patch
> >> > > 
> >> > > 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
> >> > > 
> >> > >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> >> > >  1 file changed, 2 insertions(+)
> >> > 
> >> > This seems fine to me, so:
> >> > 
> >> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> >> > 
> >> > ...but I will say that before you actually add any real "MUXGRF"
> >> > clocks on rk3399 you _might_ need to rework the code to make things
> >> > truly "optional".  If it turns out that any existing clocks that
> >> > already exist today already go through one of these muxes in the GRF
> >> > and we've always been assuming one setting of the mux, we'll need to
> >> > make sure we keep assuming that setting of the mux even if the "grf"
> >> > isn't specified.
> >> 
> >> I guess I see that a bit more relaxed :-) .
> >> 
> >> I.e. the GRF being optional is a remnant of syscons not being available
> >> when the clocks get set up- so were coming in later or not at all. For
> >> the rk3288 I converted, there we never really had the case of the GRF
> >> missing.
> >> 
> >> And the GRF mux for the vcodec now present is not being used by anything
> >> yet (neither driver nor binding), so no old devicetree can break.
> >> 
> >> > As I understand it, your motivation for this patch is to eventually be
> >> > able to model the EDP reference clock which can either be xin24 or
> >> > "edp osc".  Presumably the eDP "reference clock" isn't related to any
> >> > of the pre-existing eDP clocks so that one should be safe.
> >> 
> >> Same here, so far we don't even have edp or even any other graphical
> >> output
> >> on the rk3399, so again there is no old devicetree that could break when
> >> the grf is not specified.
> > 
> > reading all of the above again, it feels like you essentially also said
> > similar things already in your original reply and I misread some of it.
> > 
> > But again, I don't see the need for any more code right now, as hopefully
> > the simple stuff we currently only support does not have any grf-based
> > muxes in it. Xing + Rockchip people, please correct me if I'm wrong here
> > :-)
> Right.  I have no objection to Xing's patch.  I just want to make sure
> that if it's listed as "Optional" that it's really optional.
> 
> I was worried that we would introduce some GRF-based mux in the
> _middle_ of some existing clock tree because we simply didn't model
> the mux before and assumed one particular setting.  If nothing like
> that ever happens then we're fine.

Thankfully the clock diagrams on the old socs were pretty verbose, listing all
grf-based clocks as well. For example the rk3288 seems to have two and it
seems I've been carrying dummy definitions for those from the time I did the
initial clock tree [0].

And thankfully grf-based clocks somehow always only get used for more
"esotheric" components like vcodec and iep on the rk3288 :-) .


Heiko

[0] https://github.com/mmind/linux-rockchip/blob/devel/workbench/drivers/clk/rockchip/clk-rk3288.c
lines 371 and 799 .. looks like I'll need to add the iep clock as well
at some point.

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

[Heiko Stuebner]

Am Mittwoch, 11. Januar 2017, 16:50:10 CET schrieb Doug Anderson:
> Hi,
> 
> On Tue, Jan 10, 2017 at 11:58 AM, Heiko St?bner <heiko@sntech.de> wrote:
> > Hi Doug,
> > 
> > Am Dienstag, 10. Januar 2017, 20:46:12 schrieb Heiko St?bner:
> >> Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> >> > Hi,
> >> > 
> >> > On Mon, Jan 9, 2017 at 10:15 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 v4:
> >> > > - separte the binding patch
> >> > > 
> >> > > 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
> >> > > 
> >> > >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> >> > >  1 file changed, 2 insertions(+)
> >> > 
> >> > This seems fine to me, so:
> >> > 
> >> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> >> > 
> >> > ...but I will say that before you actually add any real "MUXGRF"
> >> > clocks on rk3399 you _might_ need to rework the code to make things
> >> > truly "optional".  If it turns out that any existing clocks that
> >> > already exist today already go through one of these muxes in the GRF
> >> > and we've always been assuming one setting of the mux, we'll need to
> >> > make sure we keep assuming that setting of the mux even if the "grf"
> >> > isn't specified.
> >> 
> >> I guess I see that a bit more relaxed :-) .
> >> 
> >> I.e. the GRF being optional is a remnant of syscons not being available
> >> when the clocks get set up- so were coming in later or not at all. For
> >> the rk3288 I converted, there we never really had the case of the GRF
> >> missing.
> >> 
> >> And the GRF mux for the vcodec now present is not being used by anything
> >> yet (neither driver nor binding), so no old devicetree can break.
> >> 
> >> > As I understand it, your motivation for this patch is to eventually be
> >> > able to model the EDP reference clock which can either be xin24 or
> >> > "edp osc".  Presumably the eDP "reference clock" isn't related to any
> >> > of the pre-existing eDP clocks so that one should be safe.
> >> 
> >> Same here, so far we don't even have edp or even any other graphical
> >> output
> >> on the rk3399, so again there is no old devicetree that could break when
> >> the grf is not specified.
> > 
> > reading all of the above again, it feels like you essentially also said
> > similar things already in your original reply and I misread some of it.
> > 
> > But again, I don't see the need for any more code right now, as hopefully
> > the simple stuff we currently only support does not have any grf-based
> > muxes in it. Xing + Rockchip people, please correct me if I'm wrong here
> > :-)
> Right.  I have no objection to Xing's patch.  I just want to make sure
> that if it's listed as "Optional" that it's really optional.
> 
> I was worried that we would introduce some GRF-based mux in the
> _middle_ of some existing clock tree because we simply didn't model
> the mux before and assumed one particular setting.  If nothing like
> that ever happens then we're fine.

Thankfully the clock diagrams on the old socs were pretty verbose, listing all
grf-based clocks as well. For example the rk3288 seems to have two and it
seems I've been carrying dummy definitions for those from the time I did the
initial clock tree [0].

And thankfully grf-based clocks somehow always only get used for more
"esotheric" components like vcodec and iep on the rk3288 :-) .


Heiko

[0] https://github.com/mmind/linux-rockchip/blob/devel/workbench/drivers/clk/rockchip/clk-rk3288.c
lines 371 and 799 .. looks like I'll need to add the iep clock as well
at some point.

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Xing Zheng]

Hi Doug,

On 2017年01月11日 02:45, Doug Anderson wrote:
> Hi,
>
> On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org> 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-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>> ---
>>
>> Changes in v4:
>> - separte the binding patch
>>
>> 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
>>
>>   arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>>   1 file changed, 2 insertions(+)
> This seems fine to me, so:
>
> Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>
> ...but I will say that before you actually add any real "MUXGRF"
> clocks on rk3399 you _might_ need to rework the code to make things
> truly "optional".  If it turns out that any existing clocks that
> already exist today already go through one of these muxes in the GRF
> and we've always been assuming one setting of the mux, we'll need to
> make sure we keep assuming that setting of the mux even if the "grf"
> isn't specified.
>
> As I understand it, your motivation for this patch is to eventually be
> able to model the EDP reference clock which can either be xin24 or
> "edp osc".  Presumably the eDP "reference clock" isn't related to any
> of the pre-existing eDP clocks so that one should be safe.

Hmm... I had intended to use this patch for EDP reference clock, but we 
don't need to change the parent
clock (see the BUG: 61664).

I just woud like to add this patch to avoid getting some unavailable 
MUXGRF clock and need to debug it again,
if we support it one day in future.

Thanks.

-- 
- Xing Zheng


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Xing Zheng]

Hi Doug,

On 2017年01月11日 02:45, Doug Anderson wrote:
> Hi,
>
> On Mon, Jan 9, 2017 at 10:15 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 v4:
>> - separte the binding patch
>>
>> 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
>>
>>   arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>>   1 file changed, 2 insertions(+)
> This seems fine to me, so:
>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
>
> ...but I will say that before you actually add any real "MUXGRF"
> clocks on rk3399 you _might_ need to rework the code to make things
> truly "optional".  If it turns out that any existing clocks that
> already exist today already go through one of these muxes in the GRF
> and we've always been assuming one setting of the mux, we'll need to
> make sure we keep assuming that setting of the mux even if the "grf"
> isn't specified.
>
> As I understand it, your motivation for this patch is to eventually be
> able to model the EDP reference clock which can either be xin24 or
> "edp osc".  Presumably the eDP "reference clock" isn't related to any
> of the pre-existing eDP clocks so that one should be safe.

Hmm... I had intended to use this patch for EDP reference clock, but we 
don't need to change the parent
clock (see the BUG: 61664).

I just woud like to add this patch to avoid getting some unavailable 
MUXGRF clock and need to debug it again,
if we support it one day in future.

Thanks.

-- 
- Xing Zheng

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

[Xing Zheng]

Hi Doug,

On 2017?01?11? 02:45, Doug Anderson wrote:
> Hi,
>
> On Mon, Jan 9, 2017 at 10:15 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 v4:
>> - separte the binding patch
>>
>> 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
>>
>>   arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>>   1 file changed, 2 insertions(+)
> This seems fine to me, so:
>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
>
> ...but I will say that before you actually add any real "MUXGRF"
> clocks on rk3399 you _might_ need to rework the code to make things
> truly "optional".  If it turns out that any existing clocks that
> already exist today already go through one of these muxes in the GRF
> and we've always been assuming one setting of the mux, we'll need to
> make sure we keep assuming that setting of the mux even if the "grf"
> isn't specified.
>
> As I understand it, your motivation for this patch is to eventually be
> able to model the EDP reference clock which can either be xin24 or
> "edp osc".  Presumably the eDP "reference clock" isn't related to any
> of the pre-existing eDP clocks so that one should be safe.

Hmm... I had intended to use this patch for EDP reference clock, but we 
don't need to change the parent
clock (see the BUG: 61664).

I just woud like to add this patch to avoid getting some unavailable 
MUXGRF clock and need to debug it again,
if we support it one day in future.

Thanks.

-- 
- Xing Zheng

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Heiko Stuebner]

Am Mittwoch, 11. Januar 2017, 09:04:24 CET schrieb Xing Zheng:
> Hi Doug,
> 
> On 2017年01月11日 02:45, Doug Anderson wrote:
> > Hi,
> > 
> > On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org> 
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-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >> ---
> >> 
> >> Changes in v4:
> >> - separte the binding patch
> >> 
> >> 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
> >> 
> >>   arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> >>   1 file changed, 2 insertions(+)
> > 
> > This seems fine to me, so:
> > 
> > Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > 
> > ...but I will say that before you actually add any real "MUXGRF"
> > clocks on rk3399 you _might_ need to rework the code to make things
> > truly "optional".  If it turns out that any existing clocks that
> > already exist today already go through one of these muxes in the GRF
> > and we've always been assuming one setting of the mux, we'll need to
> > make sure we keep assuming that setting of the mux even if the "grf"
> > isn't specified.
> > 
> > As I understand it, your motivation for this patch is to eventually be
> > able to model the EDP reference clock which can either be xin24 or
> > "edp osc".  Presumably the eDP "reference clock" isn't related to any
> > of the pre-existing eDP clocks so that one should be safe.
> 
> Hmm... I had intended to use this patch for EDP reference clock, but we
> don't need to change the parent
> clock (see the BUG: 61664).

Yep that sounds ok. As I said in my replies, we don't support the edp in the 
mainline kernel yet, so nothing old can break here :-)


> I just woud like to add this patch to avoid getting some unavailable
> MUXGRF clock and need to debug it again,
> if we support it one day in future.

could you just check, if we have any other grf-based muxes that we may need in 
the future. Right now I only see pclkin_isp1_wrapper describing such a mux, 
but it would be cool if you could check again.


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Heiko Stuebner]

Am Mittwoch, 11. Januar 2017, 09:04:24 CET schrieb Xing Zheng:
> Hi Doug,
> 
> On 2017年01月11日 02:45, Doug Anderson wrote:
> > Hi,
> > 
> > On Mon, Jan 9, 2017 at 10:15 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 v4:
> >> - separte the binding patch
> >> 
> >> 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
> >> 
> >>   arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> >>   1 file changed, 2 insertions(+)
> > 
> > This seems fine to me, so:
> > 
> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > 
> > ...but I will say that before you actually add any real "MUXGRF"
> > clocks on rk3399 you _might_ need to rework the code to make things
> > truly "optional".  If it turns out that any existing clocks that
> > already exist today already go through one of these muxes in the GRF
> > and we've always been assuming one setting of the mux, we'll need to
> > make sure we keep assuming that setting of the mux even if the "grf"
> > isn't specified.
> > 
> > As I understand it, your motivation for this patch is to eventually be
> > able to model the EDP reference clock which can either be xin24 or
> > "edp osc".  Presumably the eDP "reference clock" isn't related to any
> > of the pre-existing eDP clocks so that one should be safe.
> 
> Hmm... I had intended to use this patch for EDP reference clock, but we
> don't need to change the parent
> clock (see the BUG: 61664).

Yep that sounds ok. As I said in my replies, we don't support the edp in the 
mainline kernel yet, so nothing old can break here :-)


> I just woud like to add this patch to avoid getting some unavailable
> MUXGRF clock and need to debug it again,
> if we support it one day in future.

could you just check, if we have any other grf-based muxes that we may need in 
the future. Right now I only see pclkin_isp1_wrapper describing such a mux, 
but it would be cool if you could check again.


Thanks
Heiko

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

[Heiko Stuebner]

Am Mittwoch, 11. Januar 2017, 09:04:24 CET schrieb Xing Zheng:
> Hi Doug,
> 
> On 2017?01?11? 02:45, Doug Anderson wrote:
> > Hi,
> > 
> > On Mon, Jan 9, 2017 at 10:15 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 v4:
> >> - separte the binding patch
> >> 
> >> 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
> >> 
> >>   arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> >>   1 file changed, 2 insertions(+)
> > 
> > This seems fine to me, so:
> > 
> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > 
> > ...but I will say that before you actually add any real "MUXGRF"
> > clocks on rk3399 you _might_ need to rework the code to make things
> > truly "optional".  If it turns out that any existing clocks that
> > already exist today already go through one of these muxes in the GRF
> > and we've always been assuming one setting of the mux, we'll need to
> > make sure we keep assuming that setting of the mux even if the "grf"
> > isn't specified.
> > 
> > As I understand it, your motivation for this patch is to eventually be
> > able to model the EDP reference clock which can either be xin24 or
> > "edp osc".  Presumably the eDP "reference clock" isn't related to any
> > of the pre-existing eDP clocks so that one should be safe.
> 
> Hmm... I had intended to use this patch for EDP reference clock, but we
> don't need to change the parent
> clock (see the BUG: 61664).

Yep that sounds ok. As I said in my replies, we don't support the edp in the 
mainline kernel yet, so nothing old can break here :-)


> I just woud like to add this patch to avoid getting some unavailable
> MUXGRF clock and need to debug it again,
> if we support it one day in future.

could you just check, if we have any other grf-based muxes that we may need in 
the future. Right now I only see pclkin_isp1_wrapper describing such a mux, 
but it would be cool if you could check again.


Thanks
Heiko

Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU

[Xing Zheng]

Hi Heiko,

On 2017年01月11日 09:12, Heiko Stuebner wrote:
>> I just woud like to add this patch to avoid getting some unavailable
>> MUXGRF clock and need to debug it again,
>> if we support it one day in future.
> could you just check, if we have any other grf-based muxes that we may need in
> the future. Right now I only see pclkin_isp1_wrapper describing such a mux,
> but it would be cool if you could check again.
>
>
OK, we will check these.  :)

Thanks.

-- 
- Xing Zheng

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

[Xing Zheng]

Hi Heiko,

On 2017?01?11? 09:12, Heiko Stuebner wrote:
>> I just woud like to add this patch to avoid getting some unavailable
>> MUXGRF clock and need to debug it again,
>> if we support it one day in future.
> could you just check, if we have any other grf-based muxes that we may need in
> the future. Right now I only see pclkin_isp1_wrapper describing such a mux,
> but it would be cool if you could check again.
>
>
OK, we will check these.  :)

Thanks.

-- 
- Xing Zheng

[PATCH v4 2/2] dt-bindings: clk: add rockchip,grf property for RK3399

[Xing Zheng]

Add support for rockchip,grf property which is used for GRF muxes
on RK3399.

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

Changes in v4:
- update the decription for rockchip,grf property

Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
index 3888dd3..3bc56fa 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
@@ -13,6 +13,12 @@ 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".
+  It is used for GRF muxes, if missing any muxes present in the GRF will not
+  be available.
+
 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
-- 
2.7.4

[PATCH v4 2/2] dt-bindings: clk: add rockchip, grf property for RK3399

[Xing Zheng]

Add support for rockchip,grf property which is used for GRF muxes
on RK3399.

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

Changes in v4:
- update the decription for rockchip,grf property

Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
index 3888dd3..3bc56fa 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
@@ -13,6 +13,12 @@ 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".
+  It is used for GRF muxes, if missing any muxes present in the GRF will not
+  be available.
+
 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
-- 
2.7.4

[PATCH v4 2/2] dt-bindings: clk: add rockchip, grf property for RK3399

[Xing Zheng]

Add support for rockchip,grf property which is used for GRF muxes
on RK3399.

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

Changes in v4:
- update the decription for rockchip,grf property

Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
index 3888dd3..3bc56fa 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
@@ -13,6 +13,12 @@ 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".
+  It is used for GRF muxes, if missing any muxes present in the GRF will not
+  be available.
+
 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
-- 
2.7.4

Re: [PATCH v4 2/2] dt-bindings: clk: add rockchip,grf property for RK3399

[Doug Anderson]

Hi,

On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> Add support for rockchip,grf property which is used for GRF muxes
> on RK3399.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v4:
> - update the decription for rockchip,grf property
>
> Changes in v3: None
> Changes in v2: None
>
>  Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++++++
>  1 file changed, 6 insertions(+)

Reviewed-by: Douglas Anderson <dianders@chromium.org>

[PATCH v4 2/2] dt-bindings: clk: add rockchip, grf property for RK3399

[Doug Anderson]

Hi,

On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> Add support for rockchip,grf property which is used for GRF muxes
> on RK3399.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v4:
> - update the decription for rockchip,grf property
>
> Changes in v3: None
> Changes in v2: None
>
>  Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++++++
>  1 file changed, 6 insertions(+)

Reviewed-by: Douglas Anderson <dianders@chromium.org>

Re: [PATCH v4 2/2] dt-bindings: clk: add rockchip, grf property for RK3399

[Doug Anderson]

Hi,

On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> Add support for rockchip,grf property which is used for GRF muxes
> on RK3399.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v4:
> - update the decription for rockchip,grf property
>
> Changes in v3: None
> Changes in v2: None
>
>  Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++++++
>  1 file changed, 6 insertions(+)

Reviewed-by: Douglas Anderson <dianders@chromium.org>

Re: [PATCH v4 2/2] dt-bindings: clk: add rockchip,grf property for RK3399

[Rob Herring]

On Tue, Jan 10, 2017 at 02:15:30PM +0800, Xing Zheng wrote:
> Add support for rockchip,grf property which is used for GRF muxes
> on RK3399.
> 
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
> 
> Changes in v4:
> - update the decription for rockchip,grf property
> 
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++++++
>  1 file changed, 6 insertions(+)

Acked-by: Rob Herring <robh@kernel.org>

[PATCH v4 2/2] dt-bindings: clk: add rockchip,grf property for RK3399

[Rob Herring]

On Tue, Jan 10, 2017 at 02:15:30PM +0800, Xing Zheng wrote:
> Add support for rockchip,grf property which is used for GRF muxes
> on RK3399.
> 
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
> 
> Changes in v4:
> - update the decription for rockchip,grf property
> 
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++++++
>  1 file changed, 6 insertions(+)

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH v4 2/2] dt-bindings: clk: add rockchip,grf property for RK3399

[Rob Herring]

On Tue, Jan 10, 2017 at 02:15:30PM +0800, Xing Zheng wrote:
> Add support for rockchip,grf property which is used for GRF muxes
> on RK3399.
> 
> Signed-off-by: Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> 
> Changes in v4:
> - update the decription for rockchip,grf property
> 
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++++++
>  1 file changed, 6 insertions(+)

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/2] Add support rockchip,grf property for RK3399 PMU/GRU

[Heiko Stuebner]

Am Dienstag, 10. Januar 2017, 14:15:28 CET schrieb Xing Zheng:
> Hi,
>   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.
> 
> Thanks.

applied both for 4.11

binding-change is in my clock-branch (so that dt-binding doc changes stay 
together) and the dts change is of course in the dts64 branch.


Thanks
Heiko

[PATCH v4 0/2] Add support rockchip, grf property for RK3399 PMU/GRU

[Heiko Stuebner]

Am Dienstag, 10. Januar 2017, 14:15:28 CET schrieb Xing Zheng:
> Hi,
>   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.
> 
> Thanks.

applied both for 4.11

binding-change is in my clock-branch (so that dt-binding doc changes stay 
together) and the dts change is of course in the dts64 branch.


Thanks
Heiko