Dear Maxime,

On Thu, 26 Nov 2015 21:09:42 +0100
Maxime Ripard wrote:

On Tue, Nov 24, 2015 at 06:27:09PM +0800, Jisheng Zhang wrote:

quoted

+ Sebastian

On Tue, 24 Nov 2015 17:32:15 +0800
Chen-Yu Tsai wrote:
  

quoted

This adds the supported PRCM clocks and reset controls to the A80 dtsi.
The DAUDIO module clocks are not supported yet.

Also update clock and reset phandles for r_uart.

Signed-off-by: Chen-Yu Tsai <redacted>
---
 arch/arm/boot/dts/sun9i-a80.dtsi | 79 +++++++++++++++++++++++++++++++++++++++-
 1 file changed, 78 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 1118bf5cc4fb..a4ce348c0831 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi

@@ -164,6 +164,14 @@
 					     "usb_phy2", "usb_hsic_12M";
 		};
 
+		pll3: clk at 06000008 {
+			/* placeholder until implemented */
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-rate = <0>;
+			clock-output-names = "pll3";
+		};
+
 		pll4: clk at 0600000c {
 			#clock-cells = <0>;
 			compatible = "allwinner,sun9i-a80-pll4-clk";

@@ -350,6 +358,68 @@
 					"apb1_uart2", "apb1_uart3",
 					"apb1_uart4", "apb1_uart5";
 		};
+
+		cpus_clk: clk at 08001410 {
+			compatible = "allwinner,sun9i-a80-cpus-clk";
+			reg = <0x08001410 0x4>;
+			#clock-cells = <0>;
+			clocks = <&osc32k>, <&osc24M>, <&pll4>, <&pll3>;
+			clock-output-names = "cpus";
+		};
+
+		ahbs: ahbs_clk {
+			compatible = "fixed-factor-clock";
+			#clock-cells = <0>;
+			clock-div = <1>;
+			clock-mult = <1>;
+			clocks = <&cpus_clk>;
+			clock-output-names = "ahbs";
+		};  

Dear Sebastian and all,

I just want to take the sunxi clk support in mainline for example.

I'm not sure I understand correctly, it seems to me that some maintainers draw a
line: "having a node for every clock" is a no, no[1]. But here we saw one node for
cpus_clk and apbs below. And <0x08001410 0x4>; <0x0800141c 0x4>; shows they
are close each other, so should we merge them into a single clock complex node
then use mfd, regmap in clk driver?

But IMHO, sunxi dts nodes really represent real HW, so I still can't understand
why we could not have each node for cpus_clk and apbs. Can you please kindly
teach me?  

I'm totally lacking any context, but I'll reply. My view on this is
that they both represent the hardware, simply with a different model.

This preference of the clk maintainers and active clk developers
regarding the model to choose has evolved over time. When we started
the sunxi support, having one node per clock was the preferred way to
do things.

Berlin came much later, and the preference at that time was to have
the entire clock controller represented as single opaque block to the
consumers.

Both have pros and cons. The approach we took allows for an easier mix
and match, especially if the clocks you have in one SoC are reused in
others, without modifying the source code (or barely). AFAIK, this is
also the approach took by mvebu, except that their clock tree is much
much much simpler.

The approach Berlin took allows to have an easier maintainance and
more flexibility, for example to deal with clock registration
ordering, or clocks that share registers.

Our approach works just fine in our case, and I feel no incentive to
move to the new model (quite the opposite actually), but I guess it
also depends on how your clock controller is built, how many SoCs you
have to support, and how much clocks they are sharing.

Great! Thank you a lot for the detailed explanation. Now I can understand
why the clk drivers follow different models, I think I get Sebastian and
Stephen's view points. Although the BG4CT clock/pll IP are shared in all
newer than BG2Q SoCs (the only difference is how many clocks, how many plls,
and their register address), I'll follow Sebastian's suggestions -- one
entire clock controller node for all clocks/plls block

I hope it clears things up.

Yes, it's clear now. I knew the history and the reason why there are different
models in clk drivers.

Will cook a newer BG4CT clk series for review.

Thank you,
Jisheng