Hi Simon,
Quoting Simon Arlott (2015-12-10 13:49:21)
> +periph_clk: periph_clk {
> + compatible = "brcm,bcm63168-gate-clk", "brcm,bcm6345-gate-clk";
> + regmap = <&periph_cntl>;
> + offset = <0x4>;
> +
> + #clock-cells = <1>;
> + clock-indices =
> + <1>, <2>, <3>, <4>, <5>,
> + <6>, <7>, <8>, <9>, <10>,
> + <11>, <12>, <13>, <14>, <15>,
> + <16>, <17>, <18>, <19>, <20>,
> + <27>, <31>;
> + clock-output-names =
> + "vdsl_qproc", "vdsl_afe", "vdsl", "mips", "wlan_ocp",
> + "dect", "fap0", "fap1", "sar", "robosw",
> + "pcm", "usbd", "usbh", "ipsec", "spi",
> + "hsspi", "pcie", "phymips", "gmac", "nand",
> + "tbus", "robosw250";
Why is clock-output-names required? Because you don't have any clock
data in your driver? Or is there another reason?
FYI, I'm not a fan of clock-output-names, and prefer for the clk
consumer devices to specify the clock-names property.
Another question, is it correct that this binding requires a DT node for
every register that contains clock control bits? If so, I'm skeptical of
that approach. What if you have a clock controller IP block on a future
soc that has several registers worth of clock controls?
Regards,
Mike
> +};
> +
> +timer_clk: timer_clk {
> + compatible = "brcm,bcm63168-gate-clk", "brcm,bcm6345-gate-clk";
> + regmap = <&timer_cntl>;
> + offset = <0x4>;
> +
> + #clock-cells = <1>;
> + clock-indices = <17>, <18>;
> + clock-output-names = "uto_extin", "usb_ref";
> +};
> +
> +ehci0: usb@10002500 {
> + compatible = "brcm,bcm63168-ehci", "brcm,bcm6345-ehci", "generic-ehci";
> + reg = <0x10002500 0x100>;
> + big-endian;
> + interrupt-parent = <&periph_intc>;
> + interrupts = <10>;
> + clocks = <&periph_clk 13>, <&timer_clk 18>;
> + phys = <&usbh>;
> +};
> --
> 2.1.4
>
> --
> Simon Arlott
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
