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

Simon Glass sjg at chromium.org
Sun Mar 4 03:26:47 EST 2012


Hi Albert,

On Tue, Feb 28, 2012 at 2:16 PM, Albert ARIBAUD
<albert.u.boot at 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 at 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 at 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.


More information about the devicetree-discuss mailing list