Hi Stephen,
On Tue, Feb 28, 2012 at 9:32 AM, Stephen Warren swarren@nvidia.com wrote:
Simon Glass wrote at Tuesday, February 28, 2012 10:21 AM:
On Mon, Feb 27, 2012 at 3:29 PM, Stephen Warren swarren@nvidia.com wrote:
On 02/27/2012 01:52 PM, Simon Glass wrote:
Add the definition of the oscillator clock frequency.
diff --git a/board/nvidia/dts/tegra2-seaboard.dts b/board/nvidia/dts/tegra2-seaboard.dts
- clock@60006000 {
- clocks = <&osc>;
- };
The CAR takes two clock inputs; one 32KHz clock (typically from the PMU/PMIC) and one from the oscillator. The 32KHz one is missing here. I guess this won't make any difference to U-Boot since it isn't using the clock inputs in the CAR driver, but it'd be best if the .dts file contained the correct content so it didn't act as an incorrect example. See the example in the binding documentation for what should be there.
Yes I saw that - but it adds an i2c binding which I don't yet have. I add i2c in the next series.
I will add that one i2c node here.
The clock doesn't /have/ to be represented by its full I2C source; you could represent it as another global fixed-clock source until the I2C node is available to act as a clock source.
Note that in order to actually use the tps6586x node to provide the clock source, you'll need to write or modify the tps6586x's bindings to document which clock sources it provides. I haven't actually looked at the tps6586x's bindings at all; it's possible that part of the example is entirely incorrect. In my original email I quoted above, the part of the example I was caring about was that the CAR itself needs two entries in its clocks property; I don't really care where they come from at present.
I don't have tps6586x bindings and don't have support for them in U-Boot at present. U-Boot also doesn't look at the clocks property so I think your request is entirely about keeping things in sync with what we expect will go into the kernel in the future.
I am going to add your binding, less the #clock-cells which U-Boot currently can't support because it conflicts with the C preprocessor (at some point I may look at a patch to use sed or some other means of avoiding this).
Regards, Simon
-- nvpublic