RE: [PATCH V3] ARM: tegra: Define Tegra20 CAR binding

Simon Glass wrote at Wednesday, February 15, 2012 11:45 AM:

On Wed, Feb 15, 2012 at 10:14 AM, Stephen Warren [off-list ref] wrote:

quoted

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?

I don't believe there's any need for the clock IDs for the two chips to
align in any way. These are two different chips, with different sets of
clocks, different tegra*.dtsi files, different clock "drivers" that define
the available clocks, etc.

And while as you say, there are a lot of similarities, there are also a
number of differences within these first 96 clocks which make having
things completely aligned impractical. I imagine you'd rather that
Tegra30's binding follow Tegra30's CLK_OUT_ENB register layouts exactly,
rather than attempting to align with Tegra20 even in the face of
differences in HW.

quoted

+  73   csite

Would 'coresight' be better given that you have csi also?

The clock is named "csite" in the TRM; renaming it would make it harder
to correlate the binding with the TRM.

quoted

+  76   la

What is this one?

It's in the kernel's tegra2_clocks.c. It's undocumented, but I've
confirmed that it does exist.

+  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?

For Tegra30, I imagine the first 160 clock IDs would be assigned in a
way that matches the CLK)OUT_ENB registers (since there are 160 bits in
them), and any other clocks would be assigned IDs starting with 160.

P.S. Your HTML mail was a little hard to quote.

-- 
nvpublic