From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9EFF3BF6 for ; Fri, 20 Oct 2017 13:47:47 +0000 (UTC) Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7EB6EE0 for ; Fri, 20 Oct 2017 13:47:46 +0000 (UTC) To: Rob Herring References: <20171017114823.58476908@bbrezillon> <20171018110958.mh76pngzluazmc7y@sirena.co.uk> <20171018175910.GP12015@bill-the-cat> <23a238d7-0b3d-8b46-b2fe-88b9d0841aa1@st.com> From: Alexandre Torgue Message-ID: <9ba8453b-84f9-5e37-b0f5-6a0d9ebb2ce3@st.com> Date: Fri, 20 Oct 2017 15:47:21 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Cc: Tom Rini , Kumar Gala , "ksummit-discuss@lists.linuxfoundation.org" , Rob Herring , "devicetree-spec@vger.kernel.org" , Pantelis Antoniou , Andrew Turner , Andy Gross , Grant Likely , Lucas Stach , "devicetree@vger.kernel.org" , David Gibson Subject: Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Rob, On 10/19/2017 04:59 PM, 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 > 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexandre Torgue Subject: Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) Date: Fri, 20 Oct 2017 15:47:21 +0200 Message-ID: <9ba8453b-84f9-5e37-b0f5-6a0d9ebb2ce3@st.com> References: <20171017114823.58476908@bbrezillon> <20171018110958.mh76pngzluazmc7y@sirena.co.uk> <20171018175910.GP12015@bill-the-cat> <23a238d7-0b3d-8b46-b2fe-88b9d0841aa1@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: Content-Language: en-US Sender: devicetree-spec-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rob Herring Cc: Andrew Turner , Grant Likely , Tom Rini , Mark Brown , Chen-Yu Tsai , Grant Likely , Kumar Gala , "ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org" , Rob Herring , "devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Pantelis Antoniou , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Andy Gross , David Gibson , Lucas Stach List-Id: devicetree@vger.kernel.org Hi Rob, On 10/19/2017 04:59 PM, 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 > 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexandre Torgue Subject: Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) Date: Fri, 20 Oct 2017 15:47:21 +0200 Message-ID: <9ba8453b-84f9-5e37-b0f5-6a0d9ebb2ce3@st.com> References: <20171017114823.58476908@bbrezillon> <20171018110958.mh76pngzluazmc7y@sirena.co.uk> <20171018175910.GP12015@bill-the-cat> <23a238d7-0b3d-8b46-b2fe-88b9d0841aa1@st.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Language: en-US Sender: devicetree-spec-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="windows-1252"; format="flowed" To: Rob Herring Cc: Andrew Turner , Grant Likely , Tom Rini , Mark Brown , Chen-Yu Tsai , Grant Likely , Kumar Gala , "ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org" , Rob Herring , "devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Pantelis Antoniou , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Andy Gross , David Gibson , Lucas Stach Hi Rob, On 10/19/2017 04:59 PM, 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: >=20 > [...] >=20 >>>> From the FreeBSD perspective I=E2=80=99d like it if there was a comm= on 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 b= oth >>>> using devicetree to handle device enumeration. Having all 5 projects u= sing a >>>> common set of dts files and binding would simplify keeping them in syn= c. >>> >>> >>> 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 Nicol= as. >> Does it concerns only XiP system ? >=20 > 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). >=20 >> -->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 abo= ut >> not used phandle ? >=20 > 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. >=20 > 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=20 are presents in DTB binary. Maybe I didn't use correctly the DTC. Are=20 there specific things to do ? >=20 >> 2- The place of DT files (sources/scripts). I see (and clone) your >> "devicetree-rebasing.git" tree, it's a good start point. Currently (corr= ect >> me if I'm wrong) the Kernel seems to "lead" the devicetree bindings and >> devicetree dts(i) files. >=20 > 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. >=20 >> By using this external repo, it would be maybe >> easier to integrate changes for other components than Linux Kernel ? >=20 > Yes, barebox at least regularly imports it. Yes, I just saw that. So currently it means that we could push DT=20 changes by component (ATF/uBOOT) in this repo directly ? and then get=20 it in our local ATF or Uboot project ? >=20 >> We >> could have (per vendor), same dtsi files which describes the hardware (S= oC + >> board) and a extra dts files (at least at beginning) per software compon= ents >> to overload nodes (to disable some nodes not required (see (1)), to chan= ge >> bindings which are different regarding component ...). >=20 > 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. >=20 We could have different needs. For example I have a board and I would=20 like to have he following bootchain: ATF then Uboot then Kernel. For=20 that, I would like to use the same DTs files for the 3 components (and=20 the memory footprint is not an issue). The idea is to share HW=20 description between several components. But some differences implies to=20 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=20 will not define clocks as kernel done. -Using several DTB is not an issue. For ATF we have to use a DTB as=20 small as possible. It's for this reason I said that using the external repo could be a good=20 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=20 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 o= nly >> 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 discu= ss >> at Prague. >=20 > Yes, but I won't be there. Ok. I hope we will arrive to converge at Prague with Grant and involved=20 peoples ;). As we (ST) have already several components using DT, we=20 could help to prototype. Regards Alex >=20 > Rob >=20