| Message ID | 1330375973-10681-12-git-send-email-sjg@chromium.org |
|---|---|
| State | New, archived |
| Headers | show |
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.
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
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.
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 >
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...
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 >
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.
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 >
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,
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.
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.
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
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 >; };
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(-)