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

[Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

Simon Glass wrote at Wednesday, February 15, 2012 11:45 AM:
> On Wed, Feb 15, 2012 at 10:14 AM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 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?

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.

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

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