Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017)

[Alexandre Torgue <alexandre.torgue@st.com>]

Hi Frank,

On 10/19/2017 08:46 PM, Frank Rowand wrote:
> On 10/19/17 07:59, Rob Herring wrote:
>> On Thu, Oct 19, 2017 at 9:00 AM, Alexandre Torgue
>> <alexandre.torgue@st.com> 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@fubar.geek.nz>
>>>> 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:
> 

Are there DTC "extra" options to use to not build those useless phandles 
? I just tried to revert the dtb to dts (using following command:
  ./scripts/dtc/dtc -I dtb -O dts -o stm32f469-disco-flat.dts 
arch/arm/boot/dts/stm32f469-disco.dtb)

I see that phandles not used are in the dts output file. It is 
especially an issue for pinmux phandles. All pinmux groups possibilities 
are written inside (in my case) stm32f4-pinctrl.dtsi. This file is 
included in each stm32 board dts files, and in those stm32 board dts 
files only required node are enabled. But I see that all pinmux 
definitions are embedded inside dtb binary (even ones not used in board 
dts file).


regards
Alex

> $ 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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>>
>