On 10/19/17 07:59, Rob Herring wrote:
> On Thu, Oct 19, 2017 at 9:00 AM, Alexandre Torgue
> <alexandre.torgue@xxxxxx> wrote:
>> Hi Rob,
>>
>>
>> On 10/19/2017 01:53 AM, Rob Herring wrote:
>>> On Wed, Oct 18, 2017 at 6:28 PM, Andrew Turner <andrew@xxxxxxxxxxxxx>
>>> wrote:
>
> [...]
>
>>>> From the FreeBSD perspective I’d like it if there was a common repo for
>>>> all devicetree consumers to share. We are trying to not have FreeBSD
>>>> specific properties as this has caused issues in the past where we had (and
>>>> still have) FreeBSD specific dts files. We are trying to remove these as
>>>> drivers are updated to handle the common bindings.
>>>
>>>
>>> Are you aware of this repo[1]? I don't have a sense for how widely
>>> used it is. If not, it is intended to provide a common repository of
>>> binding docs and dts files. If so, what are your issues with using it?
>>> It's generated from the kernel tree with git-filter-branch and through
>>> the kernel tree is the only way to add things currently. But there's
>>> no requirement that you add a Linux driver to submit a binding or dts
>>> change. We could consider taking patches against the tree directly,
>>> and the maintainers (me) can fixup the paths and apply to the kernel
>>> tree.
>>>
>>> If there's bindings in the kernel tree you think are crap and Linux
>>> specific, I'd like to know that too. We should start flagging those.
>>>
>>>> I have also spoken with some NetBSD and OpenBSD developers. They are both
>>>> using devicetree to handle device enumeration. Having all 5 projects using a
>>>> common set of dts files and binding would simplify keeping them in sync.
>>>
>>>
>>> There's more than 5 likely: linux, 3x BSD, u-boot, barebox, zephyr,
>>> ARM trusted firmware?, UEFI?, ?
>>
>>
>> First, sorry to come late in this discussion (please be tolerant if you
>> already respond to following requests/interrogations in precedent mails :)).
>> From STmicro point of view we have the same kind of requests/needs than
>> Andrew. We think about the possibility to use same DTS files for Linux,
>> U-boot, ATF and Zephir (others could come with other vendors). Currently our
>> main concerns about this are:
>>
>> 1-How to reduce dtb size:
>> --> Reading some thread, you already start this task with Nicolas.
>> Does it concerns only XiP system ?
>
> That's the main focus ATM. Nico has looked at shrinking code usage too
> such as the tty layer and scheduler, but those have faced resistance.
> We need actual products to prove the value (and that's a chicken and
> egg problem).
>
>> -->For example, I want to use the same dtsi files between Linux and
>> U-boot. If in u-boot dts file I overload several "status" entry by
>> "disabled", is it possible that compiler doesn't build it ? And what about
>> not used phandle ?
>
> You certainly could remove disabled nodes in dtc. I'm not sure how
> hard it would be to plumb into dtc. I think phandle properties are
> already only created if there's a reference to them. If that is
Yes, phandles are only created if referenced, unless compiled
for loading overlays into:
$ cat test1.dts
/dts-v1/;
/ {
mynode: node {
};
};
$ cat test2.dts
/dts-v1/;
/ {
mynode: node {
myprop = < &mynode >;
};
};
$ scripts/dtc/dtx_diff test1.dts
/dts-v1/;
/ {
mynode: node {
};
};
$ scripts/dtc/dtx_diff test2.dts
/dts-v1/;
/ {
mynode: node {
myprop = <0x1>;
phandle = <0x1>;
};
};
If symbols are enabled for a base device tree, so that overlays
can later reference them, then all symbols generate phandles:
$ dtc -@ -O dts test1.dts
/dts-v1/;
/ {
mynode: node {
phandle = <0x1>;
};
__symbols__ {
mynode = "/node";
};
};
> created before you deleted nodes, then it would probably be hard to
> find and remove all of those. It would be similar to solving the
> device dependency problem. Or do you mean something like disable the
> clock controller node if there are no enabled references to it? I
> don't think we could do something like that generically and reliably.
>
> We did recently stop creating both "phandle" and "linux,phandle"
> properties by default in dtc, so that will save some size.
>
>> 2- The place of DT files (sources/scripts). I see (and clone) your
>> "devicetree-rebasing.git" tree, it's a good start point. Currently (correct
>> me if I'm wrong) the Kernel seems to "lead" the devicetree bindings and
>> devicetree dts(i) files.
>
> Yes, and there's not really any changing that regardless of where
> bindings and dts files live given Linux has the broadest h/w support.
>
>> By using this external repo, it would be maybe
>> easier to integrate changes for other components than Linux Kernel ?
>
> Yes, barebox at least regularly imports it.
>
>> We
>> could have (per vendor), same dtsi files which describes the hardware (SoC +
>> board) and a extra dts files (at least at beginning) per software components
>> to overload nodes (to disable some nodes not required (see (1)), to change
>> bindings which are different regarding component ...).
>
> You mean dtsi files to disable nodes for linux, u-boot, etc. That may
> make sense for mutually exclusive things like FreeBSD vs. Linux, but
> for say u-boot, we really want u-boot and Linux (or whatever OS is
> loaded) to use the same dtb. Having different dtbs is going to
> increase your memory usage.
>
>> It will also allow to have all dt script / tools for all components at only
>> one place.
>>
>> Once again, sorry if I repeat things already discussed but I wanted to
>> expose what STMicro has in mind for DT. It will be a good topic to discuss
>> at Prague.
>
> Yes, but I won't be there.
>
> Rob
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@xxxxxxxxxxxxxxxxxxxxxxxxx
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
