[PATCH V3] ARM: tegra: Define Tegra20 CAR binding
Simon Glass
sjg at chromium.org
Thu Feb 16 05:44:38 EST 2012
Hi Stephen,
On Wed, Feb 15, 2012 at 10:14 AM, Stephen Warren <swarren at nvidia.com> wrote:
> The Tegra20 CAR (Clock And Reset) Controller controls most aspects of
> most clocks within Tegra20. The device tree binding models this as a
> single monolithic clock provider, which exports ~130 clocks. This reduces
> the number of nodes needed in device tree to represent these clocks.
>
> This binding is only useful for Tegra20; the set of clocks that exists on
> Tegra30 is sufficiently different to merit its own binding.
>
It seems there is a large common element - they are almost backwards
compatible. Should we not at least look at this now?
>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> ---
> v3:
> * Re-order clock ID list so that IDs 0..95 match the CLK_OUT_ENB register
> layout where possible. For register bits that affect multiple clocks,
> assign those clocks IDs outside the range to make this clear.
>
Great!
> * Double-checked the documentation, and added a couple more cases where
> a single CLK_OUT_ENB bit affects multiple clocks.
> * Split the binding example into separate SoC and board file sections.
> v2:
> * Remove clock-names, clock-output-names properties; Tegra will solely
> use integer IDs for clocks in DT.
> * Fixed typo in compatible flag
> * Resolve FIXME re: multiple clocks with the same "reset ID"; give each
> unique clock an ID, and ignore the reset bits, since this is purely a
> clock binding. Code (e.g. U-Boot) that wants to use this to determine
> CAR reset bit numbers would need a table to convert from the clock IDs
> in this binding to the related reset bit number, if any. In general, I
> think that's true, and the U-Boot code that handles "peripheral IDs"
> should be reworked to handle "clocks", the peripheral clocks being a
> subset of all clocks.
> * Define clock IDs for all the non-peripheral clocks too; inputs, PLLs,
> etc.
> * Separate tegra-seaboard.dts usage example into a separate patch.
>
> This patch conceptually relies on Grant Likely's common clock binding patch
> series. However, since that seems pretty stable and people agree with it, I
> think we can check in this patch without waiting for Grant's.
> ---
> .../bindings/clock/nvidia,tegra20-car.txt | 207
> ++++++++++++++++++++
> arch/arm/boot/dts/tegra20.dtsi | 6 +
> 2 files changed, 213 insertions(+), 0 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
>
> diff --git
> a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> new file mode 100644
> index 0000000..5c07fca
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> @@ -0,0 +1,207 @@
> +NVIDIA Tegra20 Clock And Reset Controller
> +
> +This binding uses the common clock binding:
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
> +for muxing and gating Tegra's clocks, and setting their rates.
> +
> +Required properties :
> +- compatible : Should be "nvidia,tegra20-car"
> +- reg : Should contain CAR registers location and length
> +- clocks : Should contain phandle and clock specifiers for two clocks:
> + the 32 KHz "32k_in", and the board-specific oscillator "osc".
> +- #clock-cells : Should be 1.
> + In clock consumers, this cell represents the clock ID exposed by the
> CAR.
> +
> + The first 96 clocks are numbered to match the bits in the CAR's
> CLK_OUT_ENB
> + registers. These IDs often match those in the CAR's RST_DEVICES
> registers,
> + but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks.
> In
> + this case, those clocks are assigned IDs above 95 in order to highlight
> + this issue. Implementations that interpret these clock IDs as bit values
> + within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
> + explicitly handle these special cases.
> +
> + The balance of the clocks controlled by the CAR are assigned IDs of 96
> and
> + above.
> +
> + 0 cpu
> + 1 unassigned
> + 2 unassigned
> + 3 ac97
> + 4 rtc
> + 5 tmr
> + 6 uart1
> + 7 unassigned (register bit affects uart2 and vfir)
> + 8 gpio
> + 9 sdmmc2
> + 10 unassigned (register bit affects spdif_in and spdif_out)
> + 11 i2s1
> + 12 i2c1
> + 13 ndflash
> + 14 sdmmc1
> + 15 sdmmc4
> + 16 twc
> + 17 pwm
> + 18 i2s2
> + 19 epp
> + 20 unassigned (register bit affects vi and vi_sensor)
> + 21 2d
> + 22 usbd
> + 23 isp
> + 24 3d
> + 25 ide
> + 26 disp2
> + 27 disp1
> + 28 host1x
> + 29 vcp
> + 30 unassigned
> + 31 cache2
> +
> + 32 mem
> + 33 ahbdma
> + 34 apbdma
> + 35 unassigned
> + 36 kbc
> + 37 stat_mon
> + 38 pmc
> + 39 fuse
> + 40 kfuse
> + 41 sbc1
> + 42 snor
> + 43 spi1
> + 44 sbc2
> + 45 xio
> + 46 sbc3
> + 47 dvc
> + 48 dsi
> + 49 unassigned (register bit affects tvo and cve)
> + 50 mipi
> + 51 hdmi
> + 52 csi
> + 53 tvdac
> + 54 i2c2
> + 55 uart3
> + 56 unassigned
> + 57 emc
> + 58 usb2
> + 59 usb3
> + 60 mpe
> + 61 vde
> + 62 bsea
> + 63 bsev
> +
> + 64 speedo
> + 65 uart4
> + 66 uart5
> + 67 i2c3
> + 68 sbc4
> + 69 sdmmc3
> + 70 pcie
> + 71 owr
> + 72 afi
> + 73 csite
>
Would 'coresight' be better given that you have csi also?
> + 74 unassigned
> + 75 avpucq
> + 76 la
>
What is this one?
> + 77 unassigned
> + 78 unassigned
> + 79 unassigned
> + 80 unassigned
> + 81 unassigned
> + 82 unassigned
> + 83 unassigned
> + 84 irama
> + 85 iramb
> + 86 iramc
> + 87 iramd
> + 88 cram2
> + 89 audio_2x a/k/a audio_2x_sync_clk
> + 90 clk_d
> + 91 unassigned
> + 92 sus
> + 93 cdev1
> + 94 cdev2
> + 95 unassigned
> +
> + 96 uart2
> + 97 vfir
> + 98 spdif_in
> + 99 spdif_out
> + 100 vi
> + 101 vi_sensor
> + 102 tvo
> + 103 cve
>
These clocks follow on directly from the above numbers. What is your plan
for T30? I think this has another 64 clocks. Should we reserve those spaces
now so that the binding are compatible between the two?
> + 104 osc
+ 105 clk_32k a/k/a clk_s
> + 106 clk_m
> + 107 sclk
> + 108 cclk
> + 109 hclk
> + 110 pclk
> + 111 blink
> + 112 pll_a
> + 113 pll_a_out0
> + 114 pll_c
> + 115 pll_c_out1
> + 116 pll_d
> + 117 pll_d_out0
> + 118 pll_e
> + 119 pll_m
> + 120 pll_m_out1
> + 121 pll_p
> + 122 pll_p_out1
> + 123 pll_p_out2
> + 124 pll_p_out3
> + 125 pll_p_out4
> + 126 pll_s
> + 127 pll_u
> + 128 pll_x
> + 129 cop a/k/a avp
> + 130 audio a/k/a audio_sync_clk
> +
> +Example SoC include file:
> +
> +/ {
> + tegra_car: clock at 60006000 {
> + compatible = "nvidia,tegra20-car";
> + reg = <0x60006000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + usb at c5004000 {
> + clocks = <&tegra_car 58>; /* usb2 */
> + };
> +};
> +
> +Example board file:
> +
> +/ {
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + osc: clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <12000000>;
> + };
> + };
> +
> + i2c at 7000d000 {
> + pmic at 34 {
> + compatible = "ti,tps6586x";
> + reg = <0x34>;
> +
> + clk_32k: clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <32768>;
> + };
> + };
> + };
> +
> + &tegra_car {
> + clocks = <&clk_32k> <&osc>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/tegra20.dtsi
> b/arch/arm/boot/dts/tegra20.dtsi
> index ec1f010..550da98 100644
> --- a/arch/arm/boot/dts/tegra20.dtsi
> +++ b/arch/arm/boot/dts/tegra20.dtsi
> @@ -4,6 +4,12 @@
> compatible = "nvidia,tegra20";
> interrupt-parent = <&intc>;
>
> + tegra_car: clock at 60006000 {
> + compatible = "nvidia,tegra20-car";
> + reg = <0x60006000 1000>;
> + #clock-cells = <1>;
> + };
> +
> pmc at 7000f400 {
> compatible = "nvidia,tegra20-pmc";
> reg = <0x7000e400 0x400>;
> --
> 1.7.0.4
>
Regards,
Simon
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120215/f02cd494/attachment.html>
More information about the devicetree-discuss
mailing list