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

[Simon Glass]

Hi Stephen,

On Wed, Feb 15, 2012 at 11:14 AM, Stephen Warren <swarren at nvidia.com> wrote:
> Simon Glass wrote at Wednesday, February 15, 2012 11:45 AM:
>> 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?
>
> 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?

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

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

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