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

Hi Stephen,

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

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

quoted

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.

OK my question was really more about how you deal with multi-arch in
Linux / U-Boot. Does it make sense to ignore the commonality. Perhaps
instead the range from 96 to 160 should be reserved?

quoted

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.

OK

quoted

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.

OK

quoted

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

Sorry, I turned it on to send something odd, and forgot to turn it off.

Regards,
Simon

--
nvpublic