Patchwork [U-Boot,v6,11/20] tegra: fdt: Add clock bindings for Tegra2 Seaboard

login
register
mail settings
Submitter Simon Glass
Date Feb. 27, 2012, 8:52 p.m.
Message ID <1330375973-10681-12-git-send-email-sjg@chromium.org>
Download mbox | patch
Permalink /patch/143286/
State New, archived
Headers show

Comments

Simon Glass - Feb. 27, 2012, 8:52 p.m.
Add the definition of the oscillator clock frequency.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v6:
- Add new patch to bring in clock bindings to seaboard

 board/nvidia/dts/tegra2-seaboard.dts |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)
Stephen Warren - Feb. 27, 2012, 11:29 p.m.
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.
Simon Glass - Feb. 28, 2012, 5:20 p.m.
Hi Stephen,

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.

Regards,
Simon

>
> --
> nvpublic
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Warren - Feb. 28, 2012, 5:32 p.m.
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.
Simon Glass - Feb. 28, 2012, 5:37 p.m.
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
>
Stephen Warren - Feb. 28, 2012, 6:31 p.m.
Simon Glass wrote at Tuesday, February 28, 2012 10:38 AM:
...
> 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).

Out of curiosity, why does the C preprocessor come into it? Is U-Boot's
build process running cpp on the .dts files or something? That's non-
standard, although perhaps it could be a useful standard...
Simon Glass - Feb. 28, 2012, 6:37 p.m.
Hi Stephen,

On Tue, Feb 28, 2012 at 10:31 AM, Stephen Warren <swarren@nvidia.com> wrote:
> Simon Glass wrote at Tuesday, February 28, 2012 10:38 AM:
> ...
>> 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).
>
> Out of curiosity, why does the C preprocessor come into it? Is U-Boot's
> build process running cpp on the .dts files or something? That's non-
> standard, although perhaps it could be a useful standard...

Yes, but at the moment we only use it for '/include/ ARCH_CPU_DTS'.

Still hoping your symbolic stuff will go in though.

Regards,
Simon

>
> --
> nvpublic
>
Stephen Warren - Feb. 28, 2012, 6:41 p.m.
Simon Glass wrote at Tuesday, February 28, 2012 11:37 AM:
> On Tue, Feb 28, 2012 at 10:31 AM, Stephen Warren <swarren@nvidia.com> wrote:
> > Simon Glass wrote at Tuesday, February 28, 2012 10:38 AM:
> > ...
> >> 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).
> >
> > Out of curiosity, why does the C preprocessor come into it? Is U-Boot's
> > build process running cpp on the .dts files or something? That's non-
> > standard, although perhaps it could be a useful standard...
> 
> Yes, but at the moment we only use it for '/include/ ARCH_CPU_DTS'.

Uggh. That's going to make the device tree files look different between
the kernel and U-Boot:-( With # disallowed in particular, it's going to
prevent U-Boot from /ever/ using the correct protocols for parsing the
device tree. This seems like an extremely bad idea.

> Still hoping your symbolic stuff will go in though.

That looks extremely unlikely in its current form. Ideally, I will get
time to take Jon's or David's patches and push one of them forward to
provide a more complete solution, but it's a very long way out either way.
Simon Glass - Feb. 28, 2012, 6:46 p.m.
Hi Stephen,

On Tue, Feb 28, 2012 at 10:41 AM, Stephen Warren <swarren@nvidia.com> wrote:
> Simon Glass wrote at Tuesday, February 28, 2012 11:37 AM:
>> On Tue, Feb 28, 2012 at 10:31 AM, Stephen Warren <swarren@nvidia.com> wrote:
>> > Simon Glass wrote at Tuesday, February 28, 2012 10:38 AM:
>> > ...
>> >> 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).
>> >
>> > Out of curiosity, why does the C preprocessor come into it? Is U-Boot's
>> > build process running cpp on the .dts files or something? That's non-
>> > standard, although perhaps it could be a useful standard...
>>
>> Yes, but at the moment we only use it for '/include/ ARCH_CPU_DTS'.
>
> Uggh. That's going to make the device tree files look different between
> the kernel and U-Boot:-( With # disallowed in particular, it's going to
> prevent U-Boot from /ever/ using the correct protocols for parsing the
> device tree. This seems like an extremely bad idea.

Until we change it in U-Boot, you mean. We could move to sed or pre-
and post-process the file to remove and re-insert the #.

>
>> Still hoping your symbolic stuff will go in though.
>
> That looks extremely unlikely in its current form. Ideally, I will get
> time to take Jon's or David's patches and push one of them forward to
> provide a more complete solution, but it's a very long way out either way.

That's a shame.

Regards,
Simon

>
> --
> nvpublic
>
Albert ARIBAUD - Feb. 28, 2012, 10:16 p.m.
Le 28/02/2012 19:46, Simon Glass a écrit :
> Hi Stephen,
>
> On Tue, Feb 28, 2012 at 10:41 AM, Stephen Warren<swarren@nvidia.com>  wrote:
>> Simon Glass wrote at Tuesday, February 28, 2012 11:37 AM:
>>> On Tue, Feb 28, 2012 at 10:31 AM, Stephen Warren<swarren@nvidia.com>  wrote:
>>>> Simon Glass wrote at Tuesday, February 28, 2012 10:38 AM:
>>>> ...
>>>>> 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).
>>>>
>>>> Out of curiosity, why does the C preprocessor come into it? Is U-Boot's
>>>> build process running cpp on the .dts files or something? That's non-
>>>> standard, although perhaps it could be a useful standard...
>>>
>>> Yes, but at the moment we only use it for '/include/ ARCH_CPU_DTS'.
>>
>> Uggh. That's going to make the device tree files look different between
>> the kernel and U-Boot:-( With # disallowed in particular, it's going to
>> prevent U-Boot from /ever/ using the correct protocols for parsing the
>> device tree. This seems like an extremely bad idea.
>
> Until we change it in U-Boot, you mean. We could move to sed or pre-
> and post-process the file to remove and re-insert the #.

Rather, to convert # signs into something that the DTS cannot contain 
and the compiler can withstand (and it should be printable ASCII, too). 
is '##' a good candidate?

If so, a forward conversion would e.g. map '/include/' to '#include' and 
any '#' to '##', and the reverse conversion would turn all '##' to '#'.

But something that simple is bound to be wrong in some way...

Amicalement,
Simon Glass - March 3, 2012, 4:26 p.m.
Hi Albert,

On Tue, Feb 28, 2012 at 2:16 PM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Le 28/02/2012 19:46, Simon Glass a écrit :
>
>> Hi Stephen,
>>
>> On Tue, Feb 28, 2012 at 10:41 AM, Stephen Warren<swarren@nvidia.com>
>>  wrote:
>>>
>>> Simon Glass wrote at Tuesday, February 28, 2012 11:37 AM:
>>>>
>>>> On Tue, Feb 28, 2012 at 10:31 AM, Stephen Warren<swarren@nvidia.com>
>>>>  wrote:
>>>>>
>>>>> Simon Glass wrote at Tuesday, February 28, 2012 10:38 AM:
>>>>> ...
>>>>>>
>>>>>> 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).
>>>>>
>>>>>
>>>>> Out of curiosity, why does the C preprocessor come into it? Is U-Boot's
>>>>> build process running cpp on the .dts files or something? That's non-
>>>>> standard, although perhaps it could be a useful standard...
>>>>
>>>>
>>>> Yes, but at the moment we only use it for '/include/ ARCH_CPU_DTS'.
>>>
>>>
>>> Uggh. That's going to make the device tree files look different between
>>> the kernel and U-Boot:-( With # disallowed in particular, it's going to
>>> prevent U-Boot from /ever/ using the correct protocols for parsing the
>>> device tree. This seems like an extremely bad idea.
>>
>>
>> Until we change it in U-Boot, you mean. We could move to sed or pre-
>> and post-process the file to remove and re-insert the #.
>
>
> Rather, to convert # signs into something that the DTS cannot contain and
> the compiler can withstand (and it should be printable ASCII, too). is '##'
> a good candidate?
>
> If so, a forward conversion would e.g. map '/include/' to '#include' and any
> '#' to '##', and the reverse conversion would turn all '##' to '#'.
>
> But something that simple is bound to be wrong in some way...

It seems reasonable, although the /include/ is handled by the dtc
itself. If we bypath that then line number reporting won't work.
However I do have problems getting dtc to find its include files - I
wish it had a -I option.

I will take a look at this in a few weeks once this series in is and I
have looked at the include file problem in more detail.

Regards,
Simon

>
> Amicalement,
> --
> Albert.
Tom Rini - March 5, 2012, 8:46 p.m.
On Tue, Feb 28, 2012 at 10:41:15AM -0800, Stephen Warren wrote:
> Simon Glass wrote at Tuesday, February 28, 2012 11:37 AM:
> > On Tue, Feb 28, 2012 at 10:31 AM, Stephen Warren <swarren@nvidia.com> wrote:
> > > Simon Glass wrote at Tuesday, February 28, 2012 10:38 AM:
> > > ...
> > >> 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).
> > >
> > > Out of curiosity, why does the C preprocessor come into it? Is U-Boot's
> > > build process running cpp on the .dts files or something? That's non-
> > > standard, although perhaps it could be a useful standard...
> > 
> > Yes, but at the moment we only use it for '/include/ ARCH_CPU_DTS'.
> 
> Uggh. That's going to make the device tree files look different between
> the kernel and U-Boot:-( With # disallowed in particular, it's going to
> prevent U-Boot from /ever/ using the correct protocols for parsing the
> device tree. This seems like an extremely bad idea.

Keeping my TI hat on, I think it'd be a bad idea to have dts stuff
divergent from the kernel.  Have you raised the problem you're trying to
solve to the general DT gurus?  My very high level hope is that someday
we can have them shared between kernel and u-boot (either directly or
something silly like a .dtss that spits out a kernel dts and a u-boot
dts).  Going with a manual sync from kernel form to u-boot form seems
like adding a burden on ourselves we might not have to.
Simon Glass - March 7, 2012, 2:48 a.m.
Hi Tom,

On Mon, Mar 5, 2012 at 12:46 PM, Tom Rini <trini@ti.com> wrote:
> On Tue, Feb 28, 2012 at 10:41:15AM -0800, Stephen Warren wrote:
>> Simon Glass wrote at Tuesday, February 28, 2012 11:37 AM:
>> > On Tue, Feb 28, 2012 at 10:31 AM, Stephen Warren <swarren@nvidia.com> wrote:
>> > > Simon Glass wrote at Tuesday, February 28, 2012 10:38 AM:
>> > > ...
>> > >> 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).
>> > >
>> > > Out of curiosity, why does the C preprocessor come into it? Is U-Boot's
>> > > build process running cpp on the .dts files or something? That's non-
>> > > standard, although perhaps it could be a useful standard...
>> >
>> > Yes, but at the moment we only use it for '/include/ ARCH_CPU_DTS'.
>>
>> Uggh. That's going to make the device tree files look different between
>> the kernel and U-Boot:-( With # disallowed in particular, it's going to
>> prevent U-Boot from /ever/ using the correct protocols for parsing the
>> device tree. This seems like an extremely bad idea.
>
> Keeping my TI hat on, I think it'd be a bad idea to have dts stuff
> divergent from the kernel.  Have you raised the problem you're trying to
> solve to the general DT gurus?  My very high level hope is that someday
> we can have them shared between kernel and u-boot (either directly or
> something silly like a .dtss that spits out a kernel dts and a u-boot
> dts).  Going with a manual sync from kernel form to u-boot form seems
> like adding a burden on ourselves we might not have to.

I agree, of course. I think the best solution may be to implement
search paths in dtc. I sent a patch today so let's see what people
think.

It is even worse when we copy the .dts and .dtsi files somewhere else
(e.g. losing the original directory tree relationship by copying all
into one directory).

Regards,
Simon

>
> --
> Tom

Patch

diff --git a/board/nvidia/dts/tegra2-seaboard.dts b/board/nvidia/dts/tegra2-seaboard.dts
index dde5d03..87f58fb 100644
--- a/board/nvidia/dts/tegra2-seaboard.dts
+++ b/board/nvidia/dts/tegra2-seaboard.dts
@@ -16,6 +16,16 @@ 
 		reg = < 0x00000000 0x40000000 >;
 	};
 
+	clocks {
+		osc {
+			clock-frequency = <12000000>;
+		};
+	};
+
+	clock@60006000 {
+		clocks = <&osc>;
+	};
+
 	serial@70006300 {
 		clock-frequency = < 216000000 >;
 	};