On Fri, Oct 20, 2017 at 11:55:20AM +0200, Alexandre Torgue wrote:
> 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@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:
> >
>
> 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)
As he said, phandles are only created if referenced in the normal mode
of operation. Only if you add extra options for allowing overlays
(-@) will phandles be created for all labelled nodes (because it's
impossible for dtc to determine which ones are necessary).
> I see that phandles not used are in the dts output file.
Uh.. what do you mean by that? Do you just mean you don't see any
&whatever in the dts output? You'll never get that - once the
phandles are resolved, they're just integers, when decompiling there's
no way for dtc to determine which integers used to be phandles.
> 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@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> > >
> >
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
