Hi Stephen, On Wed, Feb 15, 2012 at 11:14 AM, Stephen Warren <swarren@xxxxxxxxxx> wrote: > Simon Glass wrote at Wednesday, February 15, 2012 11:45 AM: >> On Wed, Feb 15, 2012 at 10:14 AM, Stephen Warren <swarren@xxxxxxxxxx> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
