[RFC] clocktree representation in the devicetree

[RFC] clocktree representation in the devicetree

[Sascha Hauer]

Hi All,

The following is an attempt to represent the clocktree of a i.MX53 in
the devicetree. I created this to see how it would look like and to
start a discussion whether we want to move in this direction or not.

Some things to consider:

- It seems to be very flexible. A board can customize the clock tree
  by just adding some clk-parent=<phandle> properties to the muxers.
- clocks can easily be associated with devices.

but:

- The following example registers 127 new platform devices and it's
  not even complete. This adds significant overhead to initialization.



(btw I wasn't crazy enough to handcode the clocktree below, I wrote
a little program which initializes the tree from static c code and
then prints it out. I hope this is enough for playing with different
clock tree formats with a real life example tree. If anyones interested
in the program, let me know)


Sascha

	clock {
		ckil: clkfixed-ckil {
			rate = <0x00008000>;
			compatible = "clk-fixed";
		};
		osc: clkfixed-osc {
			rate = <0x016e3600>;
			compatible = "clk-fixed";
			pll1: pll at 0x63f80000 {
				reg = <0x63f80000 0x4000>;
				compatible = "fsl,imx53-pll";
				cpu_podf: divider-cpu_podf at 0x53fd4010 {
					reg = <0x53fd4010 0x0>;
					shift = <0x00000000>;
					width = <0x00000003>;
					compatible = "fsl,imx53-clk-divider";
				};
			};
			pll2: pll at 0x63f84000 {
				reg = <0x63f84000 0x4000>;
				compatible = "fsl,imx53-pll";
			};
			pll3: pll at 0x63f88000 {
				reg = <0x63f88000 0x4000>;
				compatible = "fsl,imx53-pll";
				usb_phy_pred: divider-usb_phy_pred at 0x53fd4030 {
					reg = <0x53fd4030 0x0>;
					shift = <0x00000003>;
					width = <0x00000003>;
					compatible = "fsl,imx53-clk-divider";
					usb_phy_podf: divider-usb_phy_podf at 0x53fd4030 {
						reg = <0x53fd4030 0x0>;
						shift = <0x00000000>;
						width = <0x00000003>;
						compatible = "fsl,imx53-clk-divider";
					};
				};
				di1_pred: divider-di1_pred at 0x53fd4030 {
					reg = <0x53fd4030 0x0>;
					shift = <0x00000006>;
					width = <0x00000003>;
					compatible = "fsl,imx53-clk-divider";
				};
			};
			pll4: pll at 0x63f8c000 {
				reg = <0x63f8c000 0x4000>;
				compatible = "fsl,imx53-pll";
				di_pll4_podf: divider-di_pll4_podf at 0x53fd4030 {
					reg = <0x53fd4030 0x0>;
					shift = <0x00000010>;
					width = <0x00000003>;
					compatible = "fsl,imx53-clk-divider";
				};
			};
			can2_serial_gate: gate-can2_serial_gate at 0x53fd4078 {
				reg = <0x53fd4078 0x0>;
				shift = <0x00000003>;
				compatible = "fsl,imx53-clk-gate";
			};
			can1_serial_gate: gate-can1_serial_gate at 0x53fd4080 {
				reg = <0x53fd4080 0x0>;
				shift = <0x0000000b>;
				compatible = "fsl,imx53-clk-gate";
			};
		};
		ckih1: clkfixed-ckih1 {
			rate = <0x01588800>;
			compatible = "clk-fixed";
		};
		ckih2: clkfixed-ckih2 {
			rate = <0x00000000>;
			compatible = "clk-fixed";
		};
		lp_apm: clkmux-lp_apm at 0x53fd400c {
			reg = <0x53fd400c 0x0>;
			shift = <0x00000000>;
			width = <0x00000001>;
			parent = <&osc 0>;
			compatible = "fsl,imx53-clk-mux";
		};
		periph_apm: clkmux-periph_apm at 0x53fd4018 {
			reg = <0x53fd4018 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&pll1 &pll3 &lp_apm 0>;
			compatible = "fsl,imx53-clk-mux";
		};
		main_bus: clkmux-main_bus at 0x53fd4014 {
			reg = <0x53fd4014 0x0>;
			shift = <0x00000000>;
			width = <0x00000001>;
			parent = <&pll2 &periph_apm>;
			compatible = "fsl,imx53-clk-mux";
			ahb_root: divider-ahb_root at 0x53fd4014 {
				reg = <0x53fd4014 0x0>;
				shift = <0x0000000a>;
				width = <0x00000003>;
				compatible = "fsl,imx53-clk-divider";
				ipg: divider-ipg at 0x53fd4014 {
					reg = <0x53fd4014 0x0>;
					shift = <0x00000008>;
					width = <0x00000002>;
					compatible = "fsl,imx53-clk-divider";
					iim_gate: gate-iim_gate at 0x53fd4068 {
						reg = <0x53fd4068 0x0>;
						shift = <0x0000000f>;
						compatible = "fsl,imx53-clk-gate";
					};
					uart1_ipg_gate: gate-uart1_ipg_gate at 0x53fd406c {
						reg = <0x53fd406c 0x0>;
						shift = <0x00000003>;
						compatible = "fsl,imx53-clk-gate";
					};
					uart2_ipg_gate: gate-uart2_ipg_gate at 0x53fd406c {
						reg = <0x53fd406c 0x0>;
						shift = <0x00000005>;
						compatible = "fsl,imx53-clk-gate";
					};
					uart3_ipg_gate: gate-uart3_ipg_gate at 0x53fd406c {
						reg = <0x53fd406c 0x0>;
						shift = <0x00000007>;
						compatible = "fsl,imx53-clk-gate";
					};
					epit1_ipg_gate: gate-epit1_ipg_gate at 0x53fd4070 {
						reg = <0x53fd4070 0x0>;
						shift = <0x00000001>;
						compatible = "fsl,imx53-clk-gate";
					};
					epit2_ipg_gate: gate-epit2_ipg_gate at 0x53fd4070 {
						reg = <0x53fd4070 0x0>;
						shift = <0x00000003>;
						compatible = "fsl,imx53-clk-gate";
					};
					pwm1_ipg_gate: gate-pwm1_ipg_gate at 0x53fd4070 {
						reg = <0x53fd4070 0x0>;
						shift = <0x00000005>;
						compatible = "fsl,imx53-clk-gate";
					};
					pwm2_ipg_gate: gate-pwm2_ipg_gate at 0x53fd4070 {
						reg = <0x53fd4070 0x0>;
						shift = <0x00000007>;
						compatible = "fsl,imx53-clk-gate";
					};
					gpt_ipg_gate: gate-gpt_ipg_gate at 0x53fd4070 {
						reg = <0x53fd4070 0x0>;
						shift = <0x00000009>;
						compatible = "fsl,imx53-clk-gate";
					};
					fec_gate: gate-fec_gate at 0x53fd4070 {
						reg = <0x53fd4070 0x0>;
						shift = <0x0000000c>;
						compatible = "fsl,imx53-clk-gate";
					};
					usboh3_ahb_gate: gate-usboh3_ahb_gate at 0x53fd4070 {
						reg = <0x53fd4070 0x0>;
						shift = <0x0000000d>;
						compatible = "fsl,imx53-clk-gate";
					};
					esdhc1_ipg_gate: gate-esdhc1_ipg_gate at 0x53fd4074 {
						reg = <0x53fd4074 0x0>;
						shift = <0x00000000>;
						compatible = "fsl,imx53-clk-gate";
					};
					esdhc2_ipg_gate: gate-esdhc2_ipg_gate at 0x53fd4074 {
						reg = <0x53fd4074 0x0>;
						shift = <0x00000002>;
						compatible = "fsl,imx53-clk-gate";
					};
					esdhc3_ipg_gate: gate-esdhc3_ipg_gate at 0x53fd4074 {
						reg = <0x53fd4074 0x0>;
						shift = <0x00000004>;
						compatible = "fsl,imx53-clk-gate";
					};
					esdhc4_ipg_gate: gate-esdhc4_ipg_gate at 0x53fd4074 {
						reg = <0x53fd4074 0x0>;
						shift = <0x00000006>;
						compatible = "fsl,imx53-clk-gate";
					};
					ssi1_ipg_gate: gate-ssi1_ipg_gate at 0x53fd4074 {
						reg = <0x53fd4074 0x0>;
						shift = <0x00000008>;
						compatible = "fsl,imx53-clk-gate";
					};
					ssi2_ipg_gate: gate-ssi2_ipg_gate at 0x53fd4074 {
						reg = <0x53fd4074 0x0>;
						shift = <0x00000009>;
						compatible = "fsl,imx53-clk-gate";
					};
					ssi3_ipg_gate: gate-ssi3_ipg_gate at 0x53fd4074 {
						reg = <0x53fd4074 0x0>;
						shift = <0x0000000a>;
						compatible = "fsl,imx53-clk-gate";
					};
					pata_gate: gate-pata_gate at 0x53fd4078 {
						reg = <0x53fd4078 0x0>;
						shift = <0x00000000>;
						compatible = "fsl,imx53-clk-gate";
					};
					can2_ipg_gate: gate-can2_ipg_gate at 0x53fd4078 {
						reg = <0x53fd4078 0x0>;
						shift = <0x00000002>;
						compatible = "fsl,imx53-clk-gate";
					};
					ecspi1_ipg_gate: gate-ecspi1_ipg_gate at 0x53fd4078 {
						reg = <0x53fd4078 0x0>;
						shift = <0x00000009>;
						compatible = "fsl,imx53-clk-gate";
					};
					ecspi2_ipg_gate: gate-ecspi2_ipg_gate at 0x53fd4078 {
						reg = <0x53fd4078 0x0>;
						shift = <0x0000000b>;
						compatible = "fsl,imx53-clk-gate";
					};
					cspi_ipg_gate: gate-cspi_ipg_gate at 0x53fd4078 {
						reg = <0x53fd4078 0x0>;
						shift = <0x0000000d>;
						compatible = "fsl,imx53-clk-gate";
					};
					sdma_gate: gate-sdma_gate at 0x53fd4078 {
						reg = <0x53fd4078 0x0>;
						shift = <0x0000000f>;
						compatible = "fsl,imx53-clk-gate";
					};
					can1_ipg_gate: gate-can1_ipg_gate at 0x53fd4080 {
						reg = <0x53fd4080 0x0>;
						shift = <0x0000000a>;
						compatible = "fsl,imx53-clk-gate";
					};
					uart4_ipg_gate: gate-uart4_ipg_gate at 0x53fd4084 {
						reg = <0x53fd4084 0x0>;
						shift = <0x00000004>;
						compatible = "fsl,imx53-clk-gate";
					};
					uart5_ipg_gate: gate-uart5_ipg_gate at 0x53fd4084 {
						reg = <0x53fd4084 0x0>;
						shift = <0x00000006>;
						compatible = "fsl,imx53-clk-gate";
					};
				};
				sata_gate: gate-sata_gate at 0x53fd4078 {
					reg = <0x53fd4078 0x0>;
					shift = <0x00000001>;
					compatible = "fsl,imx53-clk-gate";
				};
			};
			axi_a: divider-axi_a at 0x53fd4014 {
				reg = <0x53fd4014 0x0>;
				shift = <0x00000010>;
				width = <0x00000003>;
				compatible = "fsl,imx53-clk-divider";
			};
			axi_b: divider-axi_b at 0x53fd4014 {
				reg = <0x53fd4014 0x0>;
				shift = <0x00000013>;
				width = <0x00000003>;
				compatible = "fsl,imx53-clk-divider";
			};
		};
		per_lp_apm_sel: clkmux-per_lp_apm_sel at 0x53fd4018 {
			reg = <0x53fd4018 0x0>;
			shift = <0x00000000>;
			width = <0x00000001>;
			parent = <&main_bus &lp_apm>;
			compatible = "fsl,imx53-clk-mux";
			per_pred1: divider-per_pred1 at 0x53fd4014 {
				reg = <0x53fd4014 0x0>;
				shift = <0x00000006>;
				width = <0x00000002>;
				compatible = "fsl,imx53-clk-divider";
				per_pred2: divider-per_pred2 at 0x53fd4014 {
					reg = <0x53fd4014 0x0>;
					shift = <0x00000003>;
					width = <0x00000003>;
					compatible = "fsl,imx53-clk-divider";
					per_podf: divider-per_podf at 0x53fd4014 {
						reg = <0x53fd4014 0x0>;
						shift = <0x00000000>;
						width = <0x00000003>;
						compatible = "fsl,imx53-clk-divider";
					};
				};
			};
		};
		per_root: clkmux-per_root at 0x53fd4018 {
			reg = <0x53fd4018 0x0>;
			shift = <0x00000000>;
			width = <0x00000001>;
			parent = <&per_podf &ipg>;
			compatible = "fsl,imx53-clk-mux";
			i2c1_gate: gate-i2c1_gate at 0x53fd406c {
				reg = <0x53fd406c 0x0>;
				shift = <0x00000009>;
				compatible = "fsl,imx53-clk-gate";
			};
			i2c2_gate: gate-i2c2_gate at 0x53fd406c {
				reg = <0x53fd406c 0x0>;
				shift = <0x0000000a>;
				compatible = "fsl,imx53-clk-gate";
			};
			i2c3_gate: gate-i2c3_gate at 0x53fd406c {
				reg = <0x53fd406c 0x0>;
				shift = <0x0000000b>;
				compatible = "fsl,imx53-clk-gate";
			};
			epit1_hf_gate: gate-epit1_hf_gate at 0x53fd4070 {
				reg = <0x53fd4070 0x0>;
				shift = <0x00000002>;
				compatible = "fsl,imx53-clk-gate";
			};
			epit2_hf_gate: gate-epit2_hf_gate at 0x53fd4070 {
				reg = <0x53fd4070 0x0>;
				shift = <0x00000004>;
				compatible = "fsl,imx53-clk-gate";
			};
			pwm1_hf_gate: gate-pwm1_hf_gate at 0x53fd4070 {
				reg = <0x53fd4070 0x0>;
				shift = <0x00000006>;
				compatible = "fsl,imx53-clk-gate";
			};
			pwm2_hf_gate: gate-pwm2_hf_gate at 0x53fd4070 {
				reg = <0x53fd4070 0x0>;
				shift = <0x00000008>;
				compatible = "fsl,imx53-clk-gate";
			};
			gpt_gate: gate-gpt_gate at 0x53fd4070 {
				reg = <0x53fd4070 0x0>;
				shift = <0x0000000a>;
				compatible = "fsl,imx53-clk-gate";
			};
			owire_gate: gate-owire_gate at 0x53fd4070 {
				reg = <0x53fd4070 0x0>;
				shift = <0x0000000b>;
				compatible = "fsl,imx53-clk-gate";
			};
		};
		uart_sel: clkmux-uart_sel at 0x53fd401c {
			reg = <0x53fd401c 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&pll1 &pll2 &pll3 &lp_apm>;
			compatible = "fsl,imx53-clk-mux";
			uart_pred: divider-uart_pred at 0x53fd4024 {
				reg = <0x53fd4024 0x0>;
				shift = <0x00000003>;
				width = <0x00000003>;
				compatible = "fsl,imx53-clk-divider";
				uart_root: divider-uart_root at 0x53fd4024 {
					reg = <0x53fd4024 0x0>;
					shift = <0x00000000>;
					width = <0x00000003>;
					compatible = "fsl,imx53-clk-divider";
					uart1_per_gate: gate-uart1_per_gate at 0x53fd406c {
						reg = <0x53fd406c 0x0>;
						shift = <0x00000004>;
						compatible = "fsl,imx53-clk-gate";
					};
					uart2_per_gate: gate-uart2_per_gate at 0x53fd406c {
						reg = <0x53fd406c 0x0>;
						shift = <0x00000006>;
						compatible = "fsl,imx53-clk-gate";
					};
					uart3_per_gate: gate-uart3_per_gate at 0x53fd406c {
						reg = <0x53fd406c 0x0>;
						shift = <0x00000008>;
						compatible = "fsl,imx53-clk-gate";
					};
					uart4_per_gate: gate-uart4_per_gate at 0x53fd4084 {
						reg = <0x53fd4084 0x0>;
						shift = <0x00000005>;
						compatible = "fsl,imx53-clk-gate";
					};
					uart5_per_gate: gate-uart5_per_gate at 0x53fd4084 {
						reg = <0x53fd4084 0x0>;
						shift = <0x00000007>;
						compatible = "fsl,imx53-clk-gate";
					};
				};
			};
		};
		esdhc1_sel: clkmux-esdhc1_sel at 0x53fd401c {
			reg = <0x53fd401c 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&pll1 &pll2 &pll3 &lp_apm>;
			compatible = "fsl,imx53-clk-mux";
			esdhc1_pred: divider-esdhc1_pred at 0x53fd4024 {
				reg = <0x53fd4024 0x0>;
				shift = <0x00000010>;
				width = <0x00000003>;
				compatible = "fsl,imx53-clk-divider";
				esdhc1_podf: divider-esdhc1_podf at 0x53fd4024 {
					reg = <0x53fd4024 0x0>;
					shift = <0x0000000b>;
					width = <0x00000003>;
					compatible = "fsl,imx53-clk-divider";
					esdhc1_per_gate: gate-esdhc1_per_gate at 0x53fd4074 {
						reg = <0x53fd4074 0x0>;
						shift = <0x00000001>;
						compatible = "fsl,imx53-clk-gate";
					};
				};
			};
		};
		esdhc3_sel: clkmux-esdhc3_sel at 0x53fd401c {
			reg = <0x53fd401c 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&pll1 &pll2 &pll3 &lp_apm>;
			compatible = "fsl,imx53-clk-mux";
			esdhc3_pred: divider-esdhc3_pred at 0x53fd4024 {
				reg = <0x53fd4024 0x0>;
				shift = <0x00000016>;
				width = <0x00000003>;
				compatible = "fsl,imx53-clk-divider";
				esdhc3_podf: divider-esdhc3_podf at 0x53fd4024 {
					reg = <0x53fd4024 0x0>;
					shift = <0x00000013>;
					width = <0x00000003>;
					compatible = "fsl,imx53-clk-divider";
					esdhc2_per_gate: gate-esdhc2_per_gate at 0x53fd4074 {
						reg = <0x53fd4074 0x0>;
						shift = <0x00000003>;
						compatible = "fsl,imx53-clk-gate";
					};
				};
			};
		};
		esdhc3: clkmux-esdhc3 at 0x53fd401c {
			reg = <0x53fd401c 0x0>;
			shift = <0x00000000>;
			width = <0x00000001>;
			parent = <&esdhc1_podf &esdhc3_podf>;
			compatible = "fsl,imx53-clk-mux";
			esdhc3_per_gate: gate-esdhc3_per_gate at 0x53fd4074 {
				reg = <0x53fd4074 0x0>;
				shift = <0x00000005>;
				compatible = "fsl,imx53-clk-gate";
			};
		};
		esdhc4: clkmux-esdhc4 at 0x53fd401c {
			reg = <0x53fd401c 0x0>;
			shift = <0x00000000>;
			width = <0x00000001>;
			parent = <&esdhc1_podf &esdhc3_podf>;
			compatible = "fsl,imx53-clk-mux";
			esdhc4_per_gate: gate-esdhc4_per_gate at 0x53fd4074 {
				reg = <0x53fd4074 0x0>;
				shift = <0x00000007>;
				compatible = "fsl,imx53-clk-gate";
			};
		};
		ssi1_sel: clkmux-ssi1_sel at 0x53fd401c {
			reg = <0x53fd401c 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&pll1 &pll2 &pll3 0>;
			compatible = "fsl,imx53-clk-mux";
			ssi1_pred: divider-ssi1_pred at 0x53fd4028 {
				reg = <0x53fd4028 0x0>;
				shift = <0x00000006>;
				width = <0x00000003>;
				compatible = "fsl,imx53-clk-divider";
				ssi1_podf: divider-ssi1_podf at 0x53fd4028 {
					reg = <0x53fd4028 0x0>;
					shift = <0x00000000>;
					width = <0x00000006>;
					compatible = "fsl,imx53-clk-divider";
				};
				ssi2_podf: divider-ssi2_podf at 0x53fd402c {
					reg = <0x53fd402c 0x0>;
					shift = <0x00000000>;
					width = <0x00000006>;
					compatible = "fsl,imx53-clk-divider";
				};
			};
			ssi2_pred: divider-ssi2_pred at 0x53fd402c {
				reg = <0x53fd402c 0x0>;
				shift = <0x00000006>;
				width = <0x00000003>;
				compatible = "fsl,imx53-clk-divider";
			};
		};
		ssi2_sel: clkmux-ssi2_sel at 0x53fd401c {
			reg = <0x53fd401c 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&pll1 &pll2 &pll3 0>;
			compatible = "fsl,imx53-clk-mux";
		};
		ssi1_root: clkmux-ssi1_root at 0x53fd4034 {
			reg = <0x53fd4034 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&ssi1_podf 0 0 0>;
			compatible = "fsl,imx53-clk-mux";
		};
		ssi2_root: clkmux-ssi2_root at 0x53fd4034 {
			reg = <0x53fd4034 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&ssi2_podf 0 0 0>;
			compatible = "fsl,imx53-clk-mux";
		};
		ssi3_root: clkmux-ssi3_root at 0x53fd401c {
			reg = <0x53fd401c 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&ssi1_root &ssi2_root>;
			compatible = "fsl,imx53-clk-mux";
		};
		emi_sel: clkmux-emi_sel at 0x53fd4014 {
			reg = <0x53fd4014 0x0>;
			shift = <0x00000000>;
			width = <0x00000001>;
			parent = <&main_bus &ahb_root>;
			compatible = "fsl,imx53-clk-mux";
			emi_slow_root: divider-emi_slow_root at 0x53fd4014 {
				reg = <0x53fd4014 0x0>;
				shift = <0x00000016>;
				width = <0x00000003>;
				compatible = "fsl,imx53-clk-divider";
				enfc_root: divider-enfc_root at 0x53fd4014 {
					reg = <0x53fd4014 0x0>;
					shift = <0x0000000d>;
					width = <0x00000003>;
					compatible = "fsl,imx53-clk-divider";
				};
				emi_slow_gate: gate-emi_slow_gate at 0x53fd407c {
					reg = <0x53fd407c 0x0>;
					shift = <0x00000008>;
					compatible = "fsl,imx53-clk-gate";
				};
			};
		};
		ecspi_sel: clkmux-ecspi_sel at 0x53fd401c {
			reg = <0x53fd401c 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&pll1 &pll2 &pll3 &lp_apm>;
			compatible = "fsl,imx53-clk-mux";
			ecspi_pred: divider-ecspi_pred at 0x53fd4038 {
				reg = <0x53fd4038 0x0>;
				shift = <0x00000019>;
				width = <0x00000003>;
				compatible = "fsl,imx53-clk-divider";
				ecspi_podf: divider-ecspi_podf at 0x53fd4038 {
					reg = <0x53fd4038 0x0>;
					shift = <0x00000013>;
					width = <0x00000006>;
					compatible = "fsl,imx53-clk-divider";
					ecspi1_per_gate: gate-ecspi1_per_gate at 0x53fd4078 {
						reg = <0x53fd4078 0x0>;
						shift = <0x0000000a>;
						compatible = "fsl,imx53-clk-gate";
					};
					ecspi2_per_gate: gate-ecspi2_per_gate at 0x53fd4078 {
						reg = <0x53fd4078 0x0>;
						shift = <0x0000000c>;
						compatible = "fsl,imx53-clk-gate";
					};
				};
			};
		};
		usboh3_sel: clkmux-usboh3_sel at 0x53fd401c {
			reg = <0x53fd401c 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&pll1 &pll2 &pll3 &lp_apm>;
			compatible = "fsl,imx53-clk-mux";
			usboh3_pred: divider-usboh3_pred at 0x53fd4024 {
				reg = <0x53fd4024 0x0>;
				shift = <0x00000008>;
				width = <0x00000003>;
				compatible = "fsl,imx53-clk-divider";
				usboh3_root: divider-usboh3_root at 0x53fd4024 {
					reg = <0x53fd4024 0x0>;
					shift = <0x00000006>;
					width = <0x00000002>;
					compatible = "fsl,imx53-clk-divider";
					usboh3_gate: gate-usboh3_gate at 0x53fd4070 {
						reg = <0x53fd4070 0x0>;
						shift = <0x0000000e>;
						compatible = "fsl,imx53-clk-gate";
					};
				};
			};
		};
		usb_phy_root: clkmux-usb_phy_root at 0x53fd401c {
			reg = <0x53fd401c 0x0>;
			shift = <0x00000000>;
			width = <0x00000001>;
			parent = <&osc &usb_phy_podf>;
			compatible = "fsl,imx53-clk-mux";
			mx53_usb_phy1_gate: gate-mx53_usb_phy1_gate at 0x53fd4078 {
				reg = <0x53fd4078 0x0>;
				shift = <0x00000005>;
				compatible = "fsl,imx53-clk-gate";
			};
			mx53_usb_phy2_gate: gate-mx53_usb_phy2_gate at 0x53fd4078 {
				reg = <0x53fd4078 0x0>;
				shift = <0x00000006>;
				compatible = "fsl,imx53-clk-gate";
			};
		};
		tve_ext_sel: clkmux-tve_ext_sel at 0x53fd401c {
			reg = <0x53fd401c 0x0>;
			shift = <0x00000000>;
			width = <0x00000001>;
			parent = <&pll4 &ckih1>;
			compatible = "fsl,imx53-clk-mux";
			tve_pred: divider-tve_pred at 0x53fd4030 {
				reg = <0x53fd4030 0x0>;
				shift = <0x0000001c>;
				width = <0x00000003>;
				compatible = "fsl,imx53-clk-divider";
				tve_gate: gate-tve_gate at 0x53fd4070 {
					reg = <0x53fd4070 0x0>;
					shift = <0x0000000f>;
					compatible = "fsl,imx53-clk-gate";
				};
			};
		};
		ldb_di0_serial_root: clkmux-ldb_di0_serial_root at 0x53fd4020 {
			reg = <0x53fd4020 0x0>;
			shift = <0x00000000>;
			width = <0x00000001>;
			parent = <&pll3 &pll4>;
			compatible = "fsl,imx53-clk-mux";
			ldb_di0_ipu_mul: divider-fixed {
				mult = <0x00000002>;
				div = <0x00000007>;
				compatible = "clk-divider-fixed";
				ldb_di0_ipu: divider-ldb_di0_ipu at 0x53fd4020 {
					reg = <0x53fd4020 0x0>;
					shift = <0x0000000a>;
					width = <0x00000001>;
					compatible = "fsl,imx53-clk-divider";
				};
			};
		};
		ldb_di1_serial_root: clkmux-ldb_di1_serial_root at 0x53fd4020 {
			reg = <0x53fd4020 0x0>;
			shift = <0x00000000>;
			width = <0x00000001>;
			parent = <&pll3 &pll4>;
			compatible = "fsl,imx53-clk-mux";
			ldb_di1_ipu_mul: divider-fixed {
				mult = <0x00000002>;
				div = <0x00000007>;
				compatible = "clk-divider-fixed";
				ldb_di1_ipu: divider-ldb_di1_ipu at 0x53fd4020 {
					reg = <0x53fd4020 0x0>;
					shift = <0x0000000b>;
					width = <0x00000001>;
					compatible = "fsl,imx53-clk-divider";
				};
			};
		};
		di1_root: clkmux-di1_root at 0x53fd4020 {
			reg = <0x53fd4020 0x0>;
			shift = <0x00000000>;
			width = <0x00000003>;
			parent = <&di1_pred &osc &ckih1 0 0 &ldb_di1_ipu 0 0>;
			compatible = "fsl,imx53-clk-mux";
		};
		di0_root: clkmux-di0_root at 0x53fd4020 {
			reg = <0x53fd4020 0x0>;
			shift = <0x00000000>;
			width = <0x00000003>;
			parent = <&di1_pred &osc &ckih1 &di_pll4_podf 0 &ldb_di0_ipu 0 0>;
			compatible = "fsl,imx53-clk-mux";
		};
		gpu2d_root: clkmux-gpu2d_root at 0x53fd4018 {
			reg = <0x53fd4018 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&axi_a &axi_b &emi_slow_root &ahb_root>;
			compatible = "fsl,imx53-clk-mux";
		};
		arm_axi_root: clkmux-arm_axi_root at 0x53fd4018 {
			reg = <0x53fd4018 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&axi_a &axi_b &emi_slow_root &ahb_root>;
			compatible = "fsl,imx53-clk-mux";
		};
		ipu_hsp_root: clkmux-ipu_hsp_root at 0x53fd4018 {
			reg = <0x53fd4018 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&axi_a &axi_b &emi_slow_root &ahb_root>;
			compatible = "fsl,imx53-clk-mux";
		};
		gpu_root: clkmux-gpu_root at 0x53fd4018 {
			reg = <0x53fd4018 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&axi_a &axi_b &emi_slow_root &ahb_root>;
			compatible = "fsl,imx53-clk-mux";
		};
		vpu_axi_root: clkmux-vpu_axi_root at 0x53fd4018 {
			reg = <0x53fd4018 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&axi_a &axi_b &emi_slow_root &ahb_root>;
			compatible = "fsl,imx53-clk-mux";
		};
		debug_apb_root: clkmux-debug_apb_root at 0x53fd4018 {
			reg = <0x53fd4018 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&axi_a &axi_b &emi_slow_root &ahb_root>;
			compatible = "fsl,imx53-clk-mux";
		};
		ddr_root: clkmux-ddr_root at 0x53fd4018 {
			reg = <0x53fd4018 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&axi_a &axi_b &emi_slow_root &ahb_root>;
			compatible = "fsl,imx53-clk-mux";
		};
	};
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[RFC] clocktree representation in the devicetree

[Arnd Bergmann]

On Monday 17 October 2011, Sascha Hauer wrote:
> The following is an attempt to represent the clocktree of a i.MX53 in
> the devicetree. I created this to see how it would look like and to
> start a discussion whether we want to move in this direction or not.

Very good, thanks for getting this started!

> Some things to consider:
> 
> - It seems to be very flexible. A board can customize the clock tree
>   by just adding some clk-parent=<phandle> properties to the muxers.
> - clocks can easily be associated with devices.
> 
> but:
> 
> - The following example registers 127 new platform devices and it's
>   not even complete. This adds significant overhead to initialization.

I don't understand enough about the clock trees to understand if the
dts representation is good, but it I don't see a reason to represent
it as lots of platform devices in linux. We can have lots of device_nodes
in the device tree that are not a platform_device but we can still
access them through the of_*() functions. Ideally, we would encapsulate
all the clock tree parsing in the clk subsystem and provide high-level
interfaces to clkdev drivers from there.

	Arnd

[RFC] clocktree representation in the devicetree

[Rob Herring]

Sascha,

On 10/17/2011 05:29 AM, Sascha Hauer wrote:
> 
> Hi All,
> 
> The following is an attempt to represent the clocktree of a i.MX53 in
> the devicetree. I created this to see how it would look like and to
> start a discussion whether we want to move in this direction or not.
> 
> Some things to consider:
> 
> - It seems to be very flexible. A board can customize the clock tree
>   by just adding some clk-parent=<phandle> properties to the muxers.
> - clocks can easily be associated with devices.
> 
> but:
> 
> - The following example registers 127 new platform devices and it's
>   not even complete. This adds significant overhead to initialization.
> 

Why? You should only get platform devices if you declare the clocks
block as a simple bus.

I like the clk tree hierarchy reflected in the DT hierarchy. This would
make init ordering easier. However, there is one major problem I see.
You can only describe 1 configuration of the clock tree. How do you show
all possible muxing options for clocks? We need to describe what the mux
options are, but not what the current selection is as that is
discoverable already.

Will clocks ever become generic enough that it makes sense to describe
clocks in DT at the level of muxes, dividers, gates, etc.? Perhaps it
makes more sense to just describe the clock controller to device
connections and any board level clocks in the DT.

Rob

[RFC] clocktree representation in the devicetree

[Sascha Hauer]

On Mon, Oct 17, 2011 at 12:01:37PM -0500, Rob Herring wrote:
> Sascha,
> 
> On 10/17/2011 05:29 AM, Sascha Hauer wrote:
> > 
> > Hi All,
> > 
> > The following is an attempt to represent the clocktree of a i.MX53 in
> > the devicetree. I created this to see how it would look like and to
> > start a discussion whether we want to move in this direction or not.
> > 
> > Some things to consider:
> > 
> > - It seems to be very flexible. A board can customize the clock tree
> >   by just adding some clk-parent=<phandle> properties to the muxers.
> > - clocks can easily be associated with devices.
> > 
> > but:
> > 
> > - The following example registers 127 new platform devices and it's
> >   not even complete. This adds significant overhead to initialization.
> > 
> 
> Why? You should only get platform devices if you declare the clocks
> block as a simple bus.
> 
> I like the clk tree hierarchy reflected in the DT hierarchy. This would
> make init ordering easier. However, there is one major problem I see.
> You can only describe 1 configuration of the clock tree. How do you show
> all possible muxing options for clocks? We need to describe what the mux
> options are, but not what the current selection is as that is
> discoverable already.

The way I did it only dividers and gates are child nodes of their
parents. The muxes instead are located at the base of the clock tree and
have a parent property which describes all possible parents. A board
could then add a current-parent = <phandle> property in its board dts
(similar to the status = enabled property). Something like this:

imx53.dtsi:

...
		periph_apm: clkmux-periph_apm at 0x53fd4018 {
			reg = <0x53fd4018 0x0>;
			shift = <0x00000000>;
			width = <0x00000002>;
			parent = <&pll1 &pll3 &lp_apm 0>;
			compatible = "fsl,imx51-clk-mux";
		};
...

imx53-qsb.dts:

		periph_apm: clkmux-periph_apm at 0x53fd4018 {
			current_parent = <&pll3>
		};


So the entry in imx53-qsb.dts is used to describe what a board wants
and not what the current status is.

> 
> Will clocks ever become generic enough that it makes sense to describe
> clocks in DT at the level of muxes, dividers, gates, etc.?

I think yes. On i.MX processors you only need dividers, gates, muxes and
plls. On other SoCs there may be table based dividers, power-of-2
dividers or similar stuff, but overall there should be a quite limited
set of features to be described.

> Perhaps it
> makes more sense to just describe the clock controller to device
> connections and any board level clocks in the DT.

Describing the clock tree in the device tree also makes it possible for
a board to customize the divider/PLL/mux settings.
Consider a SoC with a PLL where several different devices can derive its
clock from.  One board may want to move all other devices away from this
PLL and use it exclusively for sound to get an exact rate. Another might
use it for the pixel clock and a third one selects a good compromise
between an exact sound clock and the pixel clock. Not describing this in
the device tree means that we need board specific code with
clk_get/clk_get_parent/clk_set_rate orgies. 
I gave up on creating clock code that magically tries to do everything
right based on clk_* functions. With the example above how should the
clock code know how to adjust the mentioned PLL? If you managed to get
it right for one SoC the next totally different SoC will already be in
the pipeline.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[RFC] clocktree representation in the devicetree

[Sascha Hauer]

On Mon, Oct 17, 2011 at 05:02:05PM +0200, Arnd Bergmann wrote:
> On Monday 17 October 2011, Sascha Hauer wrote:
> > The following is an attempt to represent the clocktree of a i.MX53 in
> > the devicetree. I created this to see how it would look like and to
> > start a discussion whether we want to move in this direction or not.
> 
> Very good, thanks for getting this started!
> 
> > Some things to consider:
> > 
> > - It seems to be very flexible. A board can customize the clock tree
> >   by just adding some clk-parent=<phandle> properties to the muxers.
> > - clocks can easily be associated with devices.
> > 
> > but:
> > 
> > - The following example registers 127 new platform devices and it's
> >   not even complete. This adds significant overhead to initialization.
> 
> I don't understand enough about the clock trees to understand if the
> dts representation is good, but it I don't see a reason to represent
> it as lots of platform devices in linux. We can have lots of device_nodes
> in the device tree that are not a platform_device but we can still
> access them through the of_*() functions. Ideally, we would encapsulate
> all the clock tree parsing in the clk subsystem and provide high-level
> interfaces to clkdev drivers from there.

Still we have to parse the compatible stuff and have to match a clock
entry to the corresponding driver. If we don't use platform devices here
I think we have to be careful to not create something which resembles
the platform devices with similar overhead.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[RFC] clocktree representation in the devicetree

[Rob Herring]

On 10/17/2011 01:43 PM, Sascha Hauer wrote:
> On Mon, Oct 17, 2011 at 12:01:37PM -0500, Rob Herring wrote:
>> Sascha,
>>
>> On 10/17/2011 05:29 AM, Sascha Hauer wrote:
>>>
>>> Hi All,
>>>
>>> The following is an attempt to represent the clocktree of a i.MX53 in
>>> the devicetree. I created this to see how it would look like and to
>>> start a discussion whether we want to move in this direction or not.
>>>
>>> Some things to consider:
>>>
>>> - It seems to be very flexible. A board can customize the clock tree
>>>   by just adding some clk-parent=<phandle> properties to the muxers.
>>> - clocks can easily be associated with devices.
>>>
>>> but:
>>>
>>> - The following example registers 127 new platform devices and it's
>>>   not even complete. This adds significant overhead to initialization.
>>>
>>
>> Why? You should only get platform devices if you declare the clocks
>> block as a simple bus.
>>
>> I like the clk tree hierarchy reflected in the DT hierarchy. This would
>> make init ordering easier. However, there is one major problem I see.
>> You can only describe 1 configuration of the clock tree. How do you show
>> all possible muxing options for clocks? We need to describe what the mux
>> options are, but not what the current selection is as that is
>> discoverable already.
> 
> The way I did it only dividers and gates are child nodes of their
> parents. The muxes instead are located at the base of the clock tree and
> have a parent property which describes all possible parents. A board
> could then add a current-parent = <phandle> property in its board dts
> (similar to the status = enabled property). Something like this:
> 
> imx53.dtsi:
> 
> ...
> 		periph_apm: clkmux-periph_apm at 0x53fd4018 {
> 			reg = <0x53fd4018 0x0>;
> 			shift = <0x00000000>;
> 			width = <0x00000002>;
> 			parent = <&pll1 &pll3 &lp_apm 0>;
> 			compatible = "fsl,imx51-clk-mux";
> 		};
> ...
> 
> imx53-qsb.dts:
> 
> 		periph_apm: clkmux-periph_apm at 0x53fd4018 {
> 			current_parent = <&pll3>
> 		};
> 

Okay. Missed that not going far enough down into the dts...

So either a clock can have an explicit parent (or list) or can inherit
from the parent node. That aligns pretty well with how interrupts are done.

Perhaps it should be "clock-parent" rather than just parent.

> 
> So the entry in imx53-qsb.dts is used to describe what a board wants
> and not what the current status is.
> 
I worry that that could result in a lot of combinations of DT's that
won't boot. If it's all generic code, how do you ensure things are done
in the right order. There's lots of gotchas ensuring clocks stay in the
right ranges and ratios when you change them. I don't think the clock
hierarchy alone is enough information. As a simple example, what is the
maximum frequency of internal bus clocks. That is one of the primary
differences between MX51 and MX53 clocks.

Granted this problem exists already, but is it just making it easier to
hang yourself?

>>
>> Will clocks ever become generic enough that it makes sense to describe
>> clocks in DT at the level of muxes, dividers, gates, etc.?
> 
> I think yes. On i.MX processors you only need dividers, gates, muxes and
> plls. On other SoCs there may be table based dividers, power-of-2
> dividers or similar stuff, but overall there should be a quite limited
> set of features to be described.
> 

So how do you bind a "fsl,imx51-clk-mux" to yet to be written generic
clock mux code? More importantly, are the properties exposed sufficient?

While we may ultimately want the compatible strings to be SOC specific,
it would be good to start by generically defining bindings for dividers,
muxes, and gates and ensure we have something that works for all SOCs.

>> Perhaps it
>> makes more sense to just describe the clock controller to device
>> connections and any board level clocks in the DT.
> 
> Describing the clock tree in the device tree also makes it possible for
> a board to customize the divider/PLL/mux settings.
> Consider a SoC with a PLL where several different devices can derive its
> clock from.  One board may want to move all other devices away from this
> PLL and use it exclusively for sound to get an exact rate. Another might
> use it for the pixel clock and a third one selects a good compromise
> between an exact sound clock and the pixel clock. Not describing this in
> the device tree means that we need board specific code with
> clk_get/clk_get_parent/clk_set_rate orgies. 
> I gave up on creating clock code that magically tries to do everything
> right based on clk_* functions. With the example above how should the
> clock code know how to adjust the mentioned PLL? If you managed to get
> it right for one SoC the next totally different SoC will already be in
> the pipeline.
> 
Good point. I guess the board specifics can go all the way back up the
clock tree.

It's good to see a real example. but it would be nice to see some
documentation to update this:

http://www.devicetree.org/ClockBindings

Do you have any code using this? I've updated the OF clock support based
on Mike's latest common clk code that I need to send out. But it's based
on the above clock binding.

Rob

[RFC] clocktree representation in the devicetree

[Sascha Hauer]

On Mon, Oct 17, 2011 at 06:11:56PM -0500, Rob Herring wrote:
> On 10/17/2011 01:43 PM, Sascha Hauer wrote:
> > On Mon, Oct 17, 2011 at 12:01:37PM -0500, Rob Herring wrote:
> >> Sascha,
> >>
> >> On 10/17/2011 05:29 AM, Sascha Hauer wrote:
> >>>
> >>> Hi All,
> >>>
> >>> The following is an attempt to represent the clocktree of a i.MX53 in
> >>> the devicetree. I created this to see how it would look like and to
> >>> start a discussion whether we want to move in this direction or not.
> >>>
> >>> Some things to consider:
> >>>
> >>> - It seems to be very flexible. A board can customize the clock tree
> >>>   by just adding some clk-parent=<phandle> properties to the muxers.
> >>> - clocks can easily be associated with devices.
> >>>
> >>> but:
> >>>
> >>> - The following example registers 127 new platform devices and it's
> >>>   not even complete. This adds significant overhead to initialization.
> >>>
> >>
> >> Why? You should only get platform devices if you declare the clocks
> >> block as a simple bus.
> >>
> >> I like the clk tree hierarchy reflected in the DT hierarchy. This would
> >> make init ordering easier. However, there is one major problem I see.
> >> You can only describe 1 configuration of the clock tree. How do you show
> >> all possible muxing options for clocks? We need to describe what the mux
> >> options are, but not what the current selection is as that is
> >> discoverable already.
> > 
> > The way I did it only dividers and gates are child nodes of their
> > parents. The muxes instead are located at the base of the clock tree and
> > have a parent property which describes all possible parents. A board
> > could then add a current-parent = <phandle> property in its board dts
> > (similar to the status = enabled property). Something like this:
> > 
> > imx53.dtsi:
> > 
> > ...
> > 		periph_apm: clkmux-periph_apm at 0x53fd4018 {
> > 			reg = <0x53fd4018 0x0>;
> > 			shift = <0x00000000>;
> > 			width = <0x00000002>;
> > 			parent = <&pll1 &pll3 &lp_apm 0>;
> > 			compatible = "fsl,imx51-clk-mux";
> > 		};
> > ...
> > 
> > imx53-qsb.dts:
> > 
> > 		periph_apm: clkmux-periph_apm at 0x53fd4018 {
> > 			current_parent = <&pll3>
> > 		};
> > 
> 
> Okay. Missed that not going far enough down into the dts...
> 
> So either a clock can have an explicit parent (or list) or can inherit
> from the parent node. That aligns pretty well with how interrupts are done.
> 
> Perhaps it should be "clock-parent" rather than just parent.

Yes. Also we should make the difference clear between the possible
parents of a mux and the one the user wants to select. So maybe

'clock-parent' for the possible parents of a mux

and

'selected-clock-parent' for the one the user wants to have.

> 
> > 
> > So the entry in imx53-qsb.dts is used to describe what a board wants
> > and not what the current status is.
> > 
> I worry that that could result in a lot of combinations of DT's that
> won't boot. If it's all generic code, how do you ensure things are done
> in the right order. There's lots of gotchas ensuring clocks stay in the
> right ranges and ratios when you change them. I don't think the clock
> hierarchy alone is enough information. As a simple example, what is the
> maximum frequency of internal bus clocks. That is one of the primary
> differences between MX51 and MX53 clocks.

If a user selects higher rates than allowed for a SoC he's doomed, just
like he's doomed when he screws up the devicetree in other ways
nowadays.

I agree that there will be problems when critical bus timings should be
changed via the devicetree. This would either need special handling in
the kernel or simply should be dissallowed.

> 
> Granted this problem exists already, but is it just making it easier to
> hang yourself?
> 
> >>
> >> Will clocks ever become generic enough that it makes sense to describe
> >> clocks in DT at the level of muxes, dividers, gates, etc.?
> > 
> > I think yes. On i.MX processors you only need dividers, gates, muxes and
> > plls. On other SoCs there may be table based dividers, power-of-2
> > dividers or similar stuff, but overall there should be a quite limited
> > set of features to be described.
> > 
> 
> So how do you bind a "fsl,imx51-clk-mux" to yet to be written generic
> clock mux code?

Well my first thought was to use normal (of-)platform devices, but as
mentioned this may have some unwanted overhead. In case of the mux
a generic mux could be used, so maybe compatible = "fsl,imx51-clk-mux",
"clk-mux" should do it. In case of a gate we'll probably need a i.MX5
specific variant as these SoCs use two bits for a single gate.

> More importantly, are the properties exposed sufficient?

No :)

At least there should be a propagates flag, but there may be more.

> 
> While we may ultimately want the compatible strings to be SOC specific,
> it would be good to start by generically defining bindings for dividers,
> muxes, and gates and ensure we have something that works for all SOCs.
> 
> >> Perhaps it
> >> makes more sense to just describe the clock controller to device
> >> connections and any board level clocks in the DT.
> > 
> > Describing the clock tree in the device tree also makes it possible for
> > a board to customize the divider/PLL/mux settings.
> > Consider a SoC with a PLL where several different devices can derive its
> > clock from.  One board may want to move all other devices away from this
> > PLL and use it exclusively for sound to get an exact rate. Another might
> > use it for the pixel clock and a third one selects a good compromise
> > between an exact sound clock and the pixel clock. Not describing this in
> > the device tree means that we need board specific code with
> > clk_get/clk_get_parent/clk_set_rate orgies. 
> > I gave up on creating clock code that magically tries to do everything
> > right based on clk_* functions. With the example above how should the
> > clock code know how to adjust the mentioned PLL? If you managed to get
> > it right for one SoC the next totally different SoC will already be in
> > the pipeline.
> > 
> Good point. I guess the board specifics can go all the way back up the
> clock tree.
> 
> It's good to see a real example. but it would be nice to see some
> documentation to update this:
> 
> http://www.devicetree.org/ClockBindings
> 
> Do you have any code using this? I've updated the OF clock support based
> on Mike's latest common clk code that I need to send out. But it's based
> on the above clock binding.

I wasn't aware of this page. As I see it I could rewrite my suggestion
so that it extends these clock bindings without really changing them.
I have no code working yet, I first wanted to see how the reactions are.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[RFC] clocktree representation in the devicetree

[Rob Herring]

Sascha,

On 10/18/2011 02:16 AM, Sascha Hauer wrote:
> On Mon, Oct 17, 2011 at 06:11:56PM -0500, Rob Herring wrote:
>> On 10/17/2011 01:43 PM, Sascha Hauer wrote:

snip

>>
>> Okay. Missed that not going far enough down into the dts...
>>
>> So either a clock can have an explicit parent (or list) or can inherit
>> from the parent node. That aligns pretty well with how interrupts are done.
>>
>> Perhaps it should be "clock-parent" rather than just parent.
> 
> Yes. Also we should make the difference clear between the possible
> parents of a mux and the one the user wants to select. So maybe
> 
> 'clock-parent' for the possible parents of a mux
> 
> and
> 
> 'selected-clock-parent' for the one the user wants to have.
> 

Looks good.

>>
>>>
>>> So the entry in imx53-qsb.dts is used to describe what a board wants
>>> and not what the current status is.
>>>
>> I worry that that could result in a lot of combinations of DT's that
>> won't boot. If it's all generic code, how do you ensure things are done
>> in the right order. There's lots of gotchas ensuring clocks stay in the
>> right ranges and ratios when you change them. I don't think the clock
>> hierarchy alone is enough information. As a simple example, what is the
>> maximum frequency of internal bus clocks. That is one of the primary
>> differences between MX51 and MX53 clocks.
> 
> If a user selects higher rates than allowed for a SoC he's doomed, just
> like he's doomed when he screws up the devicetree in other ways
> nowadays.
> 
> I agree that there will be problems when critical bus timings should be
> changed via the devicetree. This would either need special handling in
> the kernel or simply should be dissallowed.
> 
>>
>> Granted this problem exists already, but is it just making it easier to
>> hang yourself?
>>
>>>>
>>>> Will clocks ever become generic enough that it makes sense to describe
>>>> clocks in DT at the level of muxes, dividers, gates, etc.?
>>>
>>> I think yes. On i.MX processors you only need dividers, gates, muxes and
>>> plls. On other SoCs there may be table based dividers, power-of-2
>>> dividers or similar stuff, but overall there should be a quite limited
>>> set of features to be described.
>>>
>>
>> So how do you bind a "fsl,imx51-clk-mux" to yet to be written generic
>> clock mux code?
> 
> Well my first thought was to use normal (of-)platform devices, but as
> mentioned this may have some unwanted overhead. In case of the mux
> a generic mux could be used, so maybe compatible = "fsl,imx51-clk-mux",
> "clk-mux" should do it. In case of a gate we'll probably need a i.MX5
> specific variant as these SoCs use two bits for a single gate.
> 

You can easily point a specific compatible property to a generic
implementation. My concern is just that the binding properties be
presented generically so everyone pays attention (hopefully).

>> More importantly, are the properties exposed sufficient?
> 
> No :)
> 
> At least there should be a propagates flag, but there may be more.
> 

At least in the FSL BSP, that was always just an optimization to avoid
walking the tree needlessly. I think it could be determined from parent
and child information in the DT.

>>
>> While we may ultimately want the compatible strings to be SOC specific,
>> it would be good to start by generically defining bindings for dividers,
>> muxes, and gates and ensure we have something that works for all SOCs.
>>
>>>> Perhaps it
>>>> makes more sense to just describe the clock controller to device
>>>> connections and any board level clocks in the DT.
>>>
>>> Describing the clock tree in the device tree also makes it possible for
>>> a board to customize the divider/PLL/mux settings.
>>> Consider a SoC with a PLL where several different devices can derive its
>>> clock from.  One board may want to move all other devices away from this
>>> PLL and use it exclusively for sound to get an exact rate. Another might
>>> use it for the pixel clock and a third one selects a good compromise
>>> between an exact sound clock and the pixel clock. Not describing this in
>>> the device tree means that we need board specific code with
>>> clk_get/clk_get_parent/clk_set_rate orgies. 
>>> I gave up on creating clock code that magically tries to do everything
>>> right based on clk_* functions. With the example above how should the
>>> clock code know how to adjust the mentioned PLL? If you managed to get
>>> it right for one SoC the next totally different SoC will already be in
>>> the pipeline.
>>>
>> Good point. I guess the board specifics can go all the way back up the
>> clock tree.
>>
>> It's good to see a real example. but it would be nice to see some
>> documentation to update this:
>>
>> http://www.devicetree.org/ClockBindings
>>
>> Do you have any code using this? I've updated the OF clock support based
>> on Mike's latest common clk code that I need to send out. But it's based
>> on the above clock binding.
> 
> I wasn't aware of this page. As I see it I could rewrite my suggestion
> so that it extends these clock bindings without really changing them.
> I have no code working yet, I first wanted to see how the reactions are.
> 

To be clear, these are just proposed bindings, so they can be changed
still. In fact, Grant said at LPC that he wants to make some changes.
Perhaps Grant can chime in.

Honestly, I like your proposal better. I think having a single clock per
DT node is a good thing. This can simplify parsing the tree and should
make implementing generic code easier.

Do we need clock name strings on outputs or just phandles? Many
intermediate clocks don't really need a name other than the phandle name.

IIRC, Grant suggesting aligning with how doing reg names (aka
resource_byname) was agreed upon at LPC. Something like this:

clocks = <&clk_phandle1, &clk_phandle2>;
clock-names = <"clk1", "clk2">;

clock-names could then be optional.

Rob

[RFC] clocktree representation in the devicetree

[Sascha Hauer]

On Tue, Oct 18, 2011 at 10:35:04AM -0500, Rob Herring wrote:
> Sascha,
> 
> On 10/18/2011 02:16 AM, Sascha Hauer wrote:
> > On Mon, Oct 17, 2011 at 06:11:56PM -0500, Rob Herring wrote:
> >> On 10/17/2011 01:43 PM, Sascha Hauer wrote:
> 
> snip
> 
> >>
> >> Okay. Missed that not going far enough down into the dts...
> >>
> >> So either a clock can have an explicit parent (or list) or can inherit
> >> from the parent node. That aligns pretty well with how interrupts are done.
> >>
> >> Perhaps it should be "clock-parent" rather than just parent.
> > 
> > Yes. Also we should make the difference clear between the possible
> > parents of a mux and the one the user wants to select. So maybe
> > 
> > 'clock-parent' for the possible parents of a mux
> > 
> > and
> > 
> > 'selected-clock-parent' for the one the user wants to have.
> > 
> 
> Looks good.
> 
> >>
> >>>
> >>> So the entry in imx53-qsb.dts is used to describe what a board wants
> >>> and not what the current status is.
> >>>
> >> I worry that that could result in a lot of combinations of DT's that
> >> won't boot. If it's all generic code, how do you ensure things are done
> >> in the right order. There's lots of gotchas ensuring clocks stay in the
> >> right ranges and ratios when you change them. I don't think the clock
> >> hierarchy alone is enough information. As a simple example, what is the
> >> maximum frequency of internal bus clocks. That is one of the primary
> >> differences between MX51 and MX53 clocks.
> > 
> > If a user selects higher rates than allowed for a SoC he's doomed, just
> > like he's doomed when he screws up the devicetree in other ways
> > nowadays.
> > 
> > I agree that there will be problems when critical bus timings should be
> > changed via the devicetree. This would either need special handling in
> > the kernel or simply should be dissallowed.
> > 
> >>
> >> Granted this problem exists already, but is it just making it easier to
> >> hang yourself?
> >>
> >>>>
> >>>> Will clocks ever become generic enough that it makes sense to describe
> >>>> clocks in DT at the level of muxes, dividers, gates, etc.?
> >>>
> >>> I think yes. On i.MX processors you only need dividers, gates, muxes and
> >>> plls. On other SoCs there may be table based dividers, power-of-2
> >>> dividers or similar stuff, but overall there should be a quite limited
> >>> set of features to be described.
> >>>
> >>
> >> So how do you bind a "fsl,imx51-clk-mux" to yet to be written generic
> >> clock mux code?
> > 
> > Well my first thought was to use normal (of-)platform devices, but as
> > mentioned this may have some unwanted overhead. In case of the mux
> > a generic mux could be used, so maybe compatible = "fsl,imx51-clk-mux",
> > "clk-mux" should do it. In case of a gate we'll probably need a i.MX5
> > specific variant as these SoCs use two bits for a single gate.
> > 
> 
> You can easily point a specific compatible property to a generic
> implementation. My concern is just that the binding properties be
> presented generically so everyone pays attention (hopefully).
> 
> >> More importantly, are the properties exposed sufficient?
> > 
> > No :)
> > 
> > At least there should be a propagates flag, but there may be more.
> > 
> 
> At least in the FSL BSP, that was always just an optimization to avoid
> walking the tree needlessly. I think it could be determined from parent
> and child information in the DT.

You mean something like 'propagate up until a clock has a sibling?'

I'm unsure whether this works as expected.

> 
> >>
> >> While we may ultimately want the compatible strings to be SOC specific,
> >> it would be good to start by generically defining bindings for dividers,
> >> muxes, and gates and ensure we have something that works for all SOCs.
> >>
> >>>> Perhaps it
> >>>> makes more sense to just describe the clock controller to device
> >>>> connections and any board level clocks in the DT.
> >>>
> >>> Describing the clock tree in the device tree also makes it possible for
> >>> a board to customize the divider/PLL/mux settings.
> >>> Consider a SoC with a PLL where several different devices can derive its
> >>> clock from.  One board may want to move all other devices away from this
> >>> PLL and use it exclusively for sound to get an exact rate. Another might
> >>> use it for the pixel clock and a third one selects a good compromise
> >>> between an exact sound clock and the pixel clock. Not describing this in
> >>> the device tree means that we need board specific code with
> >>> clk_get/clk_get_parent/clk_set_rate orgies. 
> >>> I gave up on creating clock code that magically tries to do everything
> >>> right based on clk_* functions. With the example above how should the
> >>> clock code know how to adjust the mentioned PLL? If you managed to get
> >>> it right for one SoC the next totally different SoC will already be in
> >>> the pipeline.
> >>>
> >> Good point. I guess the board specifics can go all the way back up the
> >> clock tree.
> >>
> >> It's good to see a real example. but it would be nice to see some
> >> documentation to update this:
> >>
> >> http://www.devicetree.org/ClockBindings
> >>
> >> Do you have any code using this? I've updated the OF clock support based
> >> on Mike's latest common clk code that I need to send out. But it's based
> >> on the above clock binding.
> > 
> > I wasn't aware of this page. As I see it I could rewrite my suggestion
> > so that it extends these clock bindings without really changing them.
> > I have no code working yet, I first wanted to see how the reactions are.
> > 
> 
> To be clear, these are just proposed bindings, so they can be changed
> still. In fact, Grant said at LPC that he wants to make some changes.
> Perhaps Grant can chime in.
> 
> Honestly, I like your proposal better. I think having a single clock per
> DT node is a good thing. This can simplify parsing the tree and should
> make implementing generic code easier.

Ah, I see. In the example given the pll has two clock outputs, 'pll'
and 'pll-switched'. That's not so nice, but can we avoid it? I'm
just thinking about a single register bit that switches multiple
clocks in hardware. On i.MX we don't have this, but maybe others do.

> 
> Do we need clock name strings on outputs or just phandles? Many
> intermediate clocks don't really need a name other than the phandle name.

If a single node represents one clock no name strings should be
necessary.

> 
> IIRC, Grant suggesting aligning with how doing reg names (aka
> resource_byname) was agreed upon at LPC. Something like this:
> 
> clocks = <&clk_phandle1, &clk_phandle2>;
> clock-names = <"clk1", "clk2">;
> 
> clock-names could then be optional.
> 
> Rob
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[RFC] clocktree representation in the devicetree

[Grant Likely]

On Tue, Oct 18, 2011 at 1:16 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Mon, Oct 17, 2011 at 06:11:56PM -0500, Rob Herring wrote:
>> Good point. I guess the board specifics can go all the way back up the
>> clock tree.
>>
>> It's good to see a real example. but it would be nice to see some
>> documentation to update this:
>>
>> http://www.devicetree.org/ClockBindings
>>
>> Do you have any code using this? I've updated the OF clock support based
>> on Mike's latest common clk code that I need to send out. But it's based
>> on the above clock binding.
>
> I wasn't aware of this page. As I see it I could rewrite my suggestion
> so that it extends these clock bindings without really changing them.
> I have no code working yet, I first wanted to see how the reactions are.

Some working code that implements that proposal already exists in my
devicetree/test branch, but I'm not very happy with the binding (even
though I wrote it).  I'm uncomfortable about mixing phandle and string
values in the same property since it isn't a common device tree idiom.
 Rob and I talked about this at Connect last week, and I actually sat
down to rework the binding an patches to something that I'm happier
with.  I'll post the patches as an RFC later today.

A big thing for me is I don't want to require a separate node for each
and every clock source.  In some cases the clock complex can be
considered to be a single block for the whole SoC, particularly when
the internal interconnects are never visible to device drivers.  In a
case like that I don't want to force the DT writer to explode the
whole think out into nodes when there isn't a benefit to doing so.

Also, the rewritten binding is designed to follow the pattern already
established somewhat by the interrupts and gpio binding where the clk
tree is completely independent of the natural DT structure so that
arbitrary complex mappings can be described easily.

Cheers,
g.