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