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

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

Hi Rob,

On 10/19/2017 04:59 PM, 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
> 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.

I responded to Frank. On my side, disabled nodes and not used phandles 
are presents in DTB binary. Maybe I didn't use correctly the DTC. Are 
there specific things to do ?

> 
>> 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.

Yes, I just saw that. So currently it means that we could push DT 
changes by component (ATF/uBOOT) in this repo directly ?  and then get 
it in our local ATF or Uboot project ?

> 
>> 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.
> 

We could have different needs. For example I have a board and I would 
like to have he following bootchain: ATF then Uboot then Kernel. For 
that, I would like to use the same DTs files for the 3 components (and 
the memory footprint is not an issue). The idea is to share HW 
description between several components. But some differences implies to 
overload dts files per component:

-bindings could be slightly different (the case between Linux and uboot)
-frameworks bindings (basically phandles) depends on sw component: ATF 
will not define clocks as kernel done.
-Using several DTB is not an issue. For ATF we have to use a DTB as 
small as possible.

It's for this reason I said that using the external repo could be a good 
thing in order to add extra dts files per components for overloading.

I understand that people wants also to have the same binary for several 
components but it doesn't prevent to have the both solutions.


>> 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.

Ok. I hope we will arrive to converge at Prague with Grant and involved 
peoples ;). As we (ST) have already several components using DT, we 
could help to prototype.

Regards
Alex

> 
> Rob
>