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 > > > wrote: > > > > Hi Rob, > > > > > > > > > > > > On 10/19/2017 01:53 AM, Rob Herring wrote: > > > > > On Wed, Oct 18, 2017 at 6:28 PM, Andrew Turner > > > > > 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@lists.linuxfoundation.org > > > 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