[PATCH v6 11/20] tegra: fdt: Add clock bindings for Tegra2 Seaboard
Simon Glass
sjg at chromium.org
Wed Feb 29 04:37:57 EST 2012
Hi Stephen,
On Tue, Feb 28, 2012 at 9:32 AM, Stephen Warren <swarren at 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 at 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 at 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
>
More information about the devicetree-discuss
mailing list