* [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-09 20:39 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-09 20:39 UTC (permalink / raw) To: devicetree, devicetree-spec, ksummit-discuss, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand Kernel Summit is now just over 2 weeks away and it is time to pull together the schedule for the Devicetree workshop. Originally I planned on just an afternoon, but I've got the room for the whole day, so I've got a lot of flexibility on the schedule. Unscheduled time can be used for hacking. Date: 26 Oct 2017 Time: 9:00am-5:30pm (Lunch from 12:30-2:30) Location: Athens room - Hilton Prague If you plan to attend, make sure you update your OSSunmitE/ELCE registration to include the DT Workshop (log in to access and modify your registration): https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= Here is my current list of topics in no particular order, including the topic moderator: Runtime memory consumption (Rob Herring) Overlay maintenance plan (TBC) Stable ABI for devicetree (TBC) DT YAML encoding (Pantelis Antoniou) DT Schema format - option 1 (Pantelis Antoniou) DT Schema format - option 2 (Grant Likely) Sharing Generic bindings (TBC) devicetree.org update (Grant) Reply to this email if you want to propose another topic. Reply privately if there is a particular topic you want to attend but you are unable to be there in the morning or afternoon. I'll put the actual agenda together a week out from the event. g. ^ permalink raw reply [flat|nested] 126+ messages in thread
* Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-09 20:39 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-09 20:39 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand Kernel Summit is now just over 2 weeks away and it is time to pull together the schedule for the Devicetree workshop. Originally I planned on just an afternoon, but I've got the room for the whole day, so I've got a lot of flexibility on the schedule. Unscheduled time can be used for hacking. Date: 26 Oct 2017 Time: 9:00am-5:30pm (Lunch from 12:30-2:30) Location: Athens room - Hilton Prague If you plan to attend, make sure you update your OSSunmitE/ELCE registration to include the DT Workshop (log in to access and modify your registration): https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= Here is my current list of topics in no particular order, including the topic moderator: Runtime memory consumption (Rob Herring) Overlay maintenance plan (TBC) Stable ABI for devicetree (TBC) DT YAML encoding (Pantelis Antoniou) DT Schema format - option 1 (Pantelis Antoniou) DT Schema format - option 2 (Grant Likely) Sharing Generic bindings (TBC) devicetree.org update (Grant) Reply to this email if you want to propose another topic. Reply privately if there is a particular topic you want to attend but you are unable to be there in the morning or afternoon. I'll put the actual agenda together a week out from the event. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-14 12:34 ` Thomas Petazzoni 0 siblings, 0 replies; 126+ messages in thread From: Thomas Petazzoni @ 2017-10-14 12:34 UTC (permalink / raw) To: Grant Likely Cc: devicetree, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson Hello, On Mon, 9 Oct 2017 21:39:51 +0100, Grant Likely wrote: > Here is my current list of topics in no particular order, including > the topic moderator: > > Runtime memory consumption (Rob Herring) > Overlay maintenance plan (TBC) > Stable ABI for devicetree (TBC) > DT YAML encoding (Pantelis Antoniou) > DT Schema format - option 1 (Pantelis Antoniou) > DT Schema format - option 2 (Grant Likely) > Sharing Generic bindings (TBC) > devicetree.org update (Grant) > > Reply to this email if you want to propose another topic. I'd like to propose a quick discussion on how to avoid duplicating DT description when a SoC is composed of aggregations of IP blocks that are duplicated (in 2, 4 or 8 copies). As an example, we currently have arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi and arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi that are almost identical, because they represent the same aggregation of IP blocks, present two times in the same SoC (Marvell Armada 8K). As we are going to have SoCs with more than 2 copies in the future, we want to find a way to avoid duplicating the description of those aggregations. I'd like to present the problem scope, a possible solution solely based on C preprocessor macros, and then open the discussion to see what is the right approach to solve this problem. I don't think that more than 10-15 minutes is needed for presenting the problem scope and one possible solution. The following discussion may be longer though. I'll be attending on both the morning and afternoon, but I'll be leaving at ~4:30 PM. Best regards, Thomas Petazzoni -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-14 12:34 ` Thomas Petazzoni 0 siblings, 0 replies; 126+ messages in thread From: Thomas Petazzoni @ 2017-10-14 12:34 UTC (permalink / raw) To: Grant Likely Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand, Grégory Clement Hello, On Mon, 9 Oct 2017 21:39:51 +0100, Grant Likely wrote: > Here is my current list of topics in no particular order, including > the topic moderator: > > Runtime memory consumption (Rob Herring) > Overlay maintenance plan (TBC) > Stable ABI for devicetree (TBC) > DT YAML encoding (Pantelis Antoniou) > DT Schema format - option 1 (Pantelis Antoniou) > DT Schema format - option 2 (Grant Likely) > Sharing Generic bindings (TBC) > devicetree.org update (Grant) > > Reply to this email if you want to propose another topic. I'd like to propose a quick discussion on how to avoid duplicating DT description when a SoC is composed of aggregations of IP blocks that are duplicated (in 2, 4 or 8 copies). As an example, we currently have arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi and arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi that are almost identical, because they represent the same aggregation of IP blocks, present two times in the same SoC (Marvell Armada 8K). As we are going to have SoCs with more than 2 copies in the future, we want to find a way to avoid duplicating the description of those aggregations. I'd like to present the problem scope, a possible solution solely based on C preprocessor macros, and then open the discussion to see what is the right approach to solve this problem. I don't think that more than 10-15 minutes is needed for presenting the problem scope and one possible solution. The following discussion may be longer though. I'll be attending on both the morning and afternoon, but I'll be leaving at ~4:30 PM. Best regards, Thomas Petazzoni -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 13:30 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-17 13:30 UTC (permalink / raw) To: Thomas Petazzoni Cc: devicetree, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson On Sat, Oct 14, 2017 at 1:34 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Mon, 9 Oct 2017 21:39:51 +0100, Grant Likely wrote: > >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. > > I'd like to propose a quick discussion on how to avoid duplicating DT > description when a SoC is composed of aggregations of IP blocks that > are duplicated (in 2, 4 or 8 copies). > > As an example, we currently have > arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi and > arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi that are almost > identical, because they represent the same aggregation of IP blocks, > present two times in the same SoC (Marvell Armada 8K). As we are going > to have SoCs with more than 2 copies in the future, we want to find a > way to avoid duplicating the description of those aggregations. > > I'd like to present the problem scope, a possible solution solely based > on C preprocessor macros, and then open the discussion to see what is > the right approach to solve this problem. I'll include time for this alongside the overlay maintenance plan topic. It seems to me that they are closely related problems. g. > > I don't think that more than 10-15 minutes is needed for presenting the > problem scope and one possible solution. The following discussion may > be longer though. > > I'll be attending on both the morning and afternoon, but I'll be > leaving at ~4:30 PM. > > Best regards, > > Thomas Petazzoni > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 13:30 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-17 13:30 UTC (permalink / raw) To: Thomas Petazzoni Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand, Grégory Clement On Sat, Oct 14, 2017 at 1:34 PM, Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote: > Hello, > > On Mon, 9 Oct 2017 21:39:51 +0100, Grant Likely wrote: > >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. > > I'd like to propose a quick discussion on how to avoid duplicating DT > description when a SoC is composed of aggregations of IP blocks that > are duplicated (in 2, 4 or 8 copies). > > As an example, we currently have > arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi and > arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi that are almost > identical, because they represent the same aggregation of IP blocks, > present two times in the same SoC (Marvell Armada 8K). As we are going > to have SoCs with more than 2 copies in the future, we want to find a > way to avoid duplicating the description of those aggregations. > > I'd like to present the problem scope, a possible solution solely based > on C preprocessor macros, and then open the discussion to see what is > the right approach to solve this problem. I'll include time for this alongside the overlay maintenance plan topic. It seems to me that they are closely related problems. g. > > I don't think that more than 10-15 minutes is needed for presenting the > problem scope and one possible solution. The following discussion may > be longer though. > > I'll be attending on both the morning and afternoon, but I'll be > leaving at ~4:30 PM. > > Best regards, > > Thomas Petazzoni > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-16 5:36 ` Michal Simek 0 siblings, 0 replies; 126+ messages in thread From: Michal Simek @ 2017-10-16 5:36 UTC (permalink / raw) To: Grant Likely, devicetree, devicetree-spec, ksummit-discuss, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand Hi, On 9.10.2017 22:39, Grant Likely wrote: > Kernel Summit is now just over 2 weeks away and it is time to pull > together the schedule for the Devicetree workshop. Originally I > planned on just an afternoon, but I've got the room for the whole day, > so I've got a lot of flexibility on the schedule. Unscheduled time can > be used for hacking. > > Date: 26 Oct 2017 > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > Location: Athens room - Hilton Prague > > If you plan to attend, make sure you update your OSSunmitE/ELCE > registration to include the DT Workshop (log in to access and modify > your registration): > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > Here is my current list of topics in no particular order, including > the topic moderator: > > Runtime memory consumption (Rob Herring) > Overlay maintenance plan (TBC) > Stable ABI for devicetree (TBC) > DT YAML encoding (Pantelis Antoniou) > DT Schema format - option 1 (Pantelis Antoniou) > DT Schema format - option 2 (Grant Likely) > Sharing Generic bindings (TBC) > devicetree.org update (Grant) > > Reply to this email if you want to propose another topic. > > Reply privately if there is a particular topic you want to attend but > you are unable to be there in the morning or afternoon. I'll put the > actual agenda together a week out from the event. I would like to talk how to add support for AArch32 based on arm64 dts file. And next topic is discuss criteria for adding new DTS board files to kernel for supporting custom boards especially for arm32 which can end up with a lot of dts files in this folder. If make sense to permit only boards with something new or just enable reference boards to go in. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-16 5:36 ` Michal Simek 0 siblings, 0 replies; 126+ messages in thread From: Michal Simek @ 2017-10-16 5:36 UTC (permalink / raw) To: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand Hi, On 9.10.2017 22:39, Grant Likely wrote: > Kernel Summit is now just over 2 weeks away and it is time to pull > together the schedule for the Devicetree workshop. Originally I > planned on just an afternoon, but I've got the room for the whole day, > so I've got a lot of flexibility on the schedule. Unscheduled time can > be used for hacking. > > Date: 26 Oct 2017 > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > Location: Athens room - Hilton Prague > > If you plan to attend, make sure you update your OSSunmitE/ELCE > registration to include the DT Workshop (log in to access and modify > your registration): > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > Here is my current list of topics in no particular order, including > the topic moderator: > > Runtime memory consumption (Rob Herring) > Overlay maintenance plan (TBC) > Stable ABI for devicetree (TBC) > DT YAML encoding (Pantelis Antoniou) > DT Schema format - option 1 (Pantelis Antoniou) > DT Schema format - option 2 (Grant Likely) > Sharing Generic bindings (TBC) > devicetree.org update (Grant) > > Reply to this email if you want to propose another topic. > > Reply privately if there is a particular topic you want to attend but > you are unable to be there in the morning or afternoon. I'll put the > actual agenda together a week out from the event. I would like to talk how to add support for AArch32 based on arm64 dts file. And next topic is discuss criteria for adding new DTS board files to kernel for supporting custom boards especially for arm32 which can end up with a lot of dts files in this folder. If make sense to permit only boards with something new or just enable reference boards to go in. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-16 14:11 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-16 14:11 UTC (permalink / raw) To: Michal Simek Cc: devicetree, Kumar Gala, ksummit-discuss, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr@monstr.eu> wrote: > Hi, > > On 9.10.2017 22:39, Grant Likely wrote: >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. >> >> Reply privately if there is a particular topic you want to attend but >> you are unable to be there in the morning or afternoon. I'll put the >> actual agenda together a week out from the event. > > I would like to talk how to add support for AArch32 based on arm64 dts file. We already have that for RPi3, but it's a bit hacky in that you have to include files from one arch to the other. What I'd like to see ideally is no dependency on $ARCH to build dts files. You can't build dts files for an arch without a cross-compiler installed which is an artificial dependency. The dtb should be independent of whether you're building for 32 or 64 bit. There's the other aspect of being able to do armv8 32-bit builds as there's no explicit support for v8 in arch/arm/. But that's not a DT issue. > And next topic is discuss criteria for adding new DTS board files to > kernel for supporting custom boards especially for arm32 which can end > up with a lot of dts files in this folder. We really should move the arm32 files into subdirs for each SoC vendor IMO, but I think armsoc maintainers have been against that churn. > If make sense to permit only boards with something new or just enable > reference boards to go in. The board dts files are generally pretty minimal. What's the issue here? Just lots of files in arch/arm/boot/dts? Rob ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-16 14:11 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-16 14:11 UTC (permalink / raw) To: Michal Simek Cc: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Frank Rowand On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote: > Hi, > > On 9.10.2017 22:39, Grant Likely wrote: >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. >> >> Reply privately if there is a particular topic you want to attend but >> you are unable to be there in the morning or afternoon. I'll put the >> actual agenda together a week out from the event. > > I would like to talk how to add support for AArch32 based on arm64 dts file. We already have that for RPi3, but it's a bit hacky in that you have to include files from one arch to the other. What I'd like to see ideally is no dependency on $ARCH to build dts files. You can't build dts files for an arch without a cross-compiler installed which is an artificial dependency. The dtb should be independent of whether you're building for 32 or 64 bit. There's the other aspect of being able to do armv8 32-bit builds as there's no explicit support for v8 in arch/arm/. But that's not a DT issue. > And next topic is discuss criteria for adding new DTS board files to > kernel for supporting custom boards especially for arm32 which can end > up with a lot of dts files in this folder. We really should move the arm32 files into subdirs for each SoC vendor IMO, but I think armsoc maintainers have been against that churn. > If make sense to permit only boards with something new or just enable > reference boards to go in. The board dts files are generally pretty minimal. What's the issue here? Just lots of files in arch/arm/boot/dts? Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 14:04 ` Michal Simek 0 siblings, 0 replies; 126+ messages in thread From: Michal Simek @ 2017-10-18 14:04 UTC (permalink / raw) To: Rob Herring Cc: devicetree, Kumar Gala, ksummit-discuss, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson [-- Attachment #1.1: Type: text/plain, Size: 3461 bytes --] On 16.10.2017 16:11, Rob Herring wrote: > On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr@monstr.eu> wrote: >> Hi, >> >> On 9.10.2017 22:39, Grant Likely wrote: >>> Kernel Summit is now just over 2 weeks away and it is time to pull >>> together the schedule for the Devicetree workshop. Originally I >>> planned on just an afternoon, but I've got the room for the whole day, >>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>> be used for hacking. >>> >>> Date: 26 Oct 2017 >>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>> Location: Athens room - Hilton Prague >>> >>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>> registration to include the DT Workshop (log in to access and modify >>> your registration): >>> >>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>> >>> Here is my current list of topics in no particular order, including >>> the topic moderator: >>> >>> Runtime memory consumption (Rob Herring) >>> Overlay maintenance plan (TBC) >>> Stable ABI for devicetree (TBC) >>> DT YAML encoding (Pantelis Antoniou) >>> DT Schema format - option 1 (Pantelis Antoniou) >>> DT Schema format - option 2 (Grant Likely) >>> Sharing Generic bindings (TBC) >>> devicetree.org update (Grant) >>> >>> Reply to this email if you want to propose another topic. >>> >>> Reply privately if there is a particular topic you want to attend but >>> you are unable to be there in the morning or afternoon. I'll put the >>> actual agenda together a week out from the event. >> >> I would like to talk how to add support for AArch32 based on arm64 dts file. > > We already have that for RPi3, but it's a bit hacky in that you have > to include files from one arch to the other. What I'd like to see > ideally is no dependency on $ARCH to build dts files. You can't build > dts files for an arch without a cross-compiler installed which is an > artificial dependency. The dtb should be independent of whether you're > building for 32 or 64 bit. I wasn't aware about RPI3 but yes - I have seen the same for ZynqMP. > > There's the other aspect of being able to do armv8 32-bit builds as > there's no explicit support for v8 in arch/arm/. But that's not a DT > issue. Yep including Kconfig.platforms is required. > >> And next topic is discuss criteria for adding new DTS board files to >> kernel for supporting custom boards especially for arm32 which can end >> up with a lot of dts files in this folder. > > We really should move the arm32 files into subdirs for each SoC vendor > IMO, but I think armsoc maintainers have been against that churn. As you said above maybe we should consider to move all DTS files out of arch folder and sorted them based on SoC vendor. It sounds like a good topic to discuss. >> If make sense to permit only boards with something new or just enable >> reference boards to go in. > > The board dts files are generally pretty minimal. What's the issue > here? Just lots of files in arch/arm/boot/dts? yep. A lot of files there. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 14:04 ` Michal Simek 0 siblings, 0 replies; 126+ messages in thread From: Michal Simek @ 2017-10-18 14:04 UTC (permalink / raw) To: Rob Herring Cc: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Frank Rowand [-- Attachment #1.1: Type: text/plain, Size: 3491 bytes --] On 16.10.2017 16:11, Rob Herring wrote: > On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote: >> Hi, >> >> On 9.10.2017 22:39, Grant Likely wrote: >>> Kernel Summit is now just over 2 weeks away and it is time to pull >>> together the schedule for the Devicetree workshop. Originally I >>> planned on just an afternoon, but I've got the room for the whole day, >>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>> be used for hacking. >>> >>> Date: 26 Oct 2017 >>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>> Location: Athens room - Hilton Prague >>> >>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>> registration to include the DT Workshop (log in to access and modify >>> your registration): >>> >>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>> >>> Here is my current list of topics in no particular order, including >>> the topic moderator: >>> >>> Runtime memory consumption (Rob Herring) >>> Overlay maintenance plan (TBC) >>> Stable ABI for devicetree (TBC) >>> DT YAML encoding (Pantelis Antoniou) >>> DT Schema format - option 1 (Pantelis Antoniou) >>> DT Schema format - option 2 (Grant Likely) >>> Sharing Generic bindings (TBC) >>> devicetree.org update (Grant) >>> >>> Reply to this email if you want to propose another topic. >>> >>> Reply privately if there is a particular topic you want to attend but >>> you are unable to be there in the morning or afternoon. I'll put the >>> actual agenda together a week out from the event. >> >> I would like to talk how to add support for AArch32 based on arm64 dts file. > > We already have that for RPi3, but it's a bit hacky in that you have > to include files from one arch to the other. What I'd like to see > ideally is no dependency on $ARCH to build dts files. You can't build > dts files for an arch without a cross-compiler installed which is an > artificial dependency. The dtb should be independent of whether you're > building for 32 or 64 bit. I wasn't aware about RPI3 but yes - I have seen the same for ZynqMP. > > There's the other aspect of being able to do armv8 32-bit builds as > there's no explicit support for v8 in arch/arm/. But that's not a DT > issue. Yep including Kconfig.platforms is required. > >> And next topic is discuss criteria for adding new DTS board files to >> kernel for supporting custom boards especially for arm32 which can end >> up with a lot of dts files in this folder. > > We really should move the arm32 files into subdirs for each SoC vendor > IMO, but I think armsoc maintainers have been against that churn. As you said above maybe we should consider to move all DTS files out of arch folder and sorted them based on SoC vendor. It sounds like a good topic to discuss. >> If make sense to permit only boards with something new or just enable >> reference boards to go in. > > The board dts files are generally pretty minimal. What's the issue > here? Just lots of files in arch/arm/boot/dts? yep. A lot of files there. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 14:28 ` Andre Przywara 0 siblings, 0 replies; 126+ messages in thread From: Andre Przywara @ 2017-10-18 14:28 UTC (permalink / raw) To: monstr, Rob Herring Cc: devicetree, Kumar Gala, ksummit-discuss, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson Hi, On 18/10/17 15:04, Michal Simek wrote: > On 16.10.2017 16:11, Rob Herring wrote: >> On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr@monstr.eu> wrote: >>> Hi, >>> >>> On 9.10.2017 22:39, Grant Likely wrote: >>>> Kernel Summit is now just over 2 weeks away and it is time to pull >>>> together the schedule for the Devicetree workshop. Originally I >>>> planned on just an afternoon, but I've got the room for the whole day, >>>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>>> be used for hacking. >>>> >>>> Date: 26 Oct 2017 >>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>>> Location: Athens room - Hilton Prague >>>> >>>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>>> registration to include the DT Workshop (log in to access and modify >>>> your registration): >>>> >>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>>> >>>> Here is my current list of topics in no particular order, including >>>> the topic moderator: >>>> >>>> Runtime memory consumption (Rob Herring) >>>> Overlay maintenance plan (TBC) >>>> Stable ABI for devicetree (TBC) >>>> DT YAML encoding (Pantelis Antoniou) >>>> DT Schema format - option 1 (Pantelis Antoniou) >>>> DT Schema format - option 2 (Grant Likely) >>>> Sharing Generic bindings (TBC) >>>> devicetree.org update (Grant) >>>> >>>> Reply to this email if you want to propose another topic. >>>> >>>> Reply privately if there is a particular topic you want to attend but >>>> you are unable to be there in the morning or afternoon. I'll put the >>>> actual agenda together a week out from the event. >>> >>> I would like to talk how to add support for AArch32 based on arm64 dts file. >> >> We already have that for RPi3, but it's a bit hacky in that you have >> to include files from one arch to the other. What I'd like to see >> ideally is no dependency on $ARCH to build dts files. You can't build >> dts files for an arch without a cross-compiler installed which is an >> artificial dependency. The dtb should be independent of whether you're >> building for 32 or 64 bit. > > I wasn't aware about RPI3 but yes - I have seen the same for ZynqMP. > >> >> There's the other aspect of being able to do armv8 32-bit builds as >> there's no explicit support for v8 in arch/arm/. But that's not a DT >> issue. > > Yep including Kconfig.platforms is required. > >> >>> And next topic is discuss criteria for adding new DTS board files to >>> kernel for supporting custom boards especially for arm32 which can end >>> up with a lot of dts files in this folder. >> >> We really should move the arm32 files into subdirs for each SoC vendor >> IMO, but I think armsoc maintainers have been against that churn. > > As you said above maybe we should consider to move all DTS files out of > arch folder and sorted them based on SoC vendor. It sounds like a good > topic to discuss. > > >>> If make sense to permit only boards with something new or just enable >>> reference boards to go in. >> >> The board dts files are generally pretty minimal. What's the issue >> here? Just lots of files in arch/arm/boot/dts? > > yep. A lot of files there. I was wondering whether we should really stop providing .dts files for *boards* in the *kernel* tree. In my impression this was more a stop-gap measure to bridge the transition from board files to DT. Given that the particular board files are rather boring anyway, wouldn't it be sufficient to just include the SoC .dtsi plus one (or two) example .dts, for instance for the official evaluation board? This could be used as a template for creating specific board DTs. Ideally vendors could put those on their boards: into some flash or integrated into the firmware (as part of U-Boot, for instance). And having a source for the .dtsi should make it easier to get a readable de-compilation of a given .dtb. We could collect .dts files for boards somewhere else. It's already the case that we have some boards with a specific SoC "supported by the kernel" and some not, for no technical reason at all, actually. It's just whether there is someone willing to post (and push through) a .dts file. Cheers, Andre. ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 14:28 ` Andre Przywara 0 siblings, 0 replies; 126+ messages in thread From: Andre Przywara @ 2017-10-18 14:28 UTC (permalink / raw) To: monstr-pSz03upnqPeHXe+LvDLADg, Rob Herring Cc: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Frank Rowand Hi, On 18/10/17 15:04, Michal Simek wrote: > On 16.10.2017 16:11, Rob Herring wrote: >> On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote: >>> Hi, >>> >>> On 9.10.2017 22:39, Grant Likely wrote: >>>> Kernel Summit is now just over 2 weeks away and it is time to pull >>>> together the schedule for the Devicetree workshop. Originally I >>>> planned on just an afternoon, but I've got the room for the whole day, >>>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>>> be used for hacking. >>>> >>>> Date: 26 Oct 2017 >>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>>> Location: Athens room - Hilton Prague >>>> >>>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>>> registration to include the DT Workshop (log in to access and modify >>>> your registration): >>>> >>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>>> >>>> Here is my current list of topics in no particular order, including >>>> the topic moderator: >>>> >>>> Runtime memory consumption (Rob Herring) >>>> Overlay maintenance plan (TBC) >>>> Stable ABI for devicetree (TBC) >>>> DT YAML encoding (Pantelis Antoniou) >>>> DT Schema format - option 1 (Pantelis Antoniou) >>>> DT Schema format - option 2 (Grant Likely) >>>> Sharing Generic bindings (TBC) >>>> devicetree.org update (Grant) >>>> >>>> Reply to this email if you want to propose another topic. >>>> >>>> Reply privately if there is a particular topic you want to attend but >>>> you are unable to be there in the morning or afternoon. I'll put the >>>> actual agenda together a week out from the event. >>> >>> I would like to talk how to add support for AArch32 based on arm64 dts file. >> >> We already have that for RPi3, but it's a bit hacky in that you have >> to include files from one arch to the other. What I'd like to see >> ideally is no dependency on $ARCH to build dts files. You can't build >> dts files for an arch without a cross-compiler installed which is an >> artificial dependency. The dtb should be independent of whether you're >> building for 32 or 64 bit. > > I wasn't aware about RPI3 but yes - I have seen the same for ZynqMP. > >> >> There's the other aspect of being able to do armv8 32-bit builds as >> there's no explicit support for v8 in arch/arm/. But that's not a DT >> issue. > > Yep including Kconfig.platforms is required. > >> >>> And next topic is discuss criteria for adding new DTS board files to >>> kernel for supporting custom boards especially for arm32 which can end >>> up with a lot of dts files in this folder. >> >> We really should move the arm32 files into subdirs for each SoC vendor >> IMO, but I think armsoc maintainers have been against that churn. > > As you said above maybe we should consider to move all DTS files out of > arch folder and sorted them based on SoC vendor. It sounds like a good > topic to discuss. > > >>> If make sense to permit only boards with something new or just enable >>> reference boards to go in. >> >> The board dts files are generally pretty minimal. What's the issue >> here? Just lots of files in arch/arm/boot/dts? > > yep. A lot of files there. I was wondering whether we should really stop providing .dts files for *boards* in the *kernel* tree. In my impression this was more a stop-gap measure to bridge the transition from board files to DT. Given that the particular board files are rather boring anyway, wouldn't it be sufficient to just include the SoC .dtsi plus one (or two) example .dts, for instance for the official evaluation board? This could be used as a template for creating specific board DTs. Ideally vendors could put those on their boards: into some flash or integrated into the firmware (as part of U-Boot, for instance). And having a source for the .dtsi should make it easier to get a readable de-compilation of a given .dtb. We could collect .dts files for boards somewhere else. It's already the case that we have some boards with a specific SoC "supported by the kernel" and some not, for no technical reason at all, actually. It's just whether there is someone willing to post (and push through) a .dts file. Cheers, Andre. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 15:32 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-18 15:32 UTC (permalink / raw) To: Andre Przywara, Michal Simek Cc: devicetree, Kumar Gala, ksummit-discuss, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson On Wed, Oct 18, 2017 at 9:28 AM, Andre Przywara <andre.przywara@arm.com> wrote: > Hi, > > On 18/10/17 15:04, Michal Simek wrote: >> On 16.10.2017 16:11, Rob Herring wrote: >>> On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr@monstr.eu> wrote: >>>> Hi, >>>> >>>> On 9.10.2017 22:39, Grant Likely wrote: >>>>> Kernel Summit is now just over 2 weeks away and it is time to pull >>>>> together the schedule for the Devicetree workshop. Originally I >>>>> planned on just an afternoon, but I've got the room for the whole day, >>>>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>>>> be used for hacking. >>>>> >>>>> Date: 26 Oct 2017 >>>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>>>> Location: Athens room - Hilton Prague >>>>> >>>>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>>>> registration to include the DT Workshop (log in to access and modify >>>>> your registration): >>>>> >>>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>>>> >>>>> Here is my current list of topics in no particular order, including >>>>> the topic moderator: >>>>> >>>>> Runtime memory consumption (Rob Herring) >>>>> Overlay maintenance plan (TBC) >>>>> Stable ABI for devicetree (TBC) >>>>> DT YAML encoding (Pantelis Antoniou) >>>>> DT Schema format - option 1 (Pantelis Antoniou) >>>>> DT Schema format - option 2 (Grant Likely) >>>>> Sharing Generic bindings (TBC) >>>>> devicetree.org update (Grant) >>>>> >>>>> Reply to this email if you want to propose another topic. >>>>> >>>>> Reply privately if there is a particular topic you want to attend but >>>>> you are unable to be there in the morning or afternoon. I'll put the >>>>> actual agenda together a week out from the event. >>>> >>>> I would like to talk how to add support for AArch32 based on arm64 dts file. >>> >>> We already have that for RPi3, but it's a bit hacky in that you have >>> to include files from one arch to the other. What I'd like to see >>> ideally is no dependency on $ARCH to build dts files. You can't build >>> dts files for an arch without a cross-compiler installed which is an >>> artificial dependency. The dtb should be independent of whether you're >>> building for 32 or 64 bit. >> >> I wasn't aware about RPI3 but yes - I have seen the same for ZynqMP. >> >>> >>> There's the other aspect of being able to do armv8 32-bit builds as >>> there's no explicit support for v8 in arch/arm/. But that's not a DT >>> issue. >> >> Yep including Kconfig.platforms is required. >> >>> >>>> And next topic is discuss criteria for adding new DTS board files to >>>> kernel for supporting custom boards especially for arm32 which can end >>>> up with a lot of dts files in this folder. >>> >>> We really should move the arm32 files into subdirs for each SoC vendor >>> IMO, but I think armsoc maintainers have been against that churn. >> >> As you said above maybe we should consider to move all DTS files out of >> arch folder and sorted them based on SoC vendor. It sounds like a good >> topic to discuss. That is 2 separate topics really. For the latter, you need to come up with reasons to justify the churn. >>>> If make sense to permit only boards with something new or just enable >>>> reference boards to go in. >>> >>> The board dts files are generally pretty minimal. What's the issue >>> here? Just lots of files in arch/arm/boot/dts? >> >> yep. A lot of files there. Are we approaching the limits of # of files in one directory? Is Arnd/Olof or Linus complaining about there being too many files to maintain? Do sub-arch maintainers not know which files are theirs? What problem are we trying to solve here? If we're talking about moving bindings and dts files out of the kernel, then call it that. Otherwise, let's not mix the topics. Unless you want nothing to happen then tie it to moving to a separate repository. > I was wondering whether we should really stop providing .dts files for > *boards* in the *kernel* tree. In my impression this was more a stop-gap > measure to bridge the transition from board files to DT. Not really. A stop-gap would be a couple of kernel cycles in my mind. PPC dts files have been there forever practically. > Given that the particular board files are rather boring anyway, wouldn't > it be sufficient to just include the SoC .dtsi plus one (or two) example > .dts, for instance for the official evaluation board? That sounds horrible to manage. You are assuming the split between board and SoC specifics are done perfectly from the start. I haven't checked the history, but I'm going to guess that has not been the case. That would effectively make the split be an ABI. Folks have enough issues with the entire dtb being an ABI. However, there is a coming issue with Android project Treble which does say all board specifics are an overlay (or multiple overlays) to a common SoC base dtb which does make the split an ABI. For mainline to handle this, we'd need to start making the board files overlays. And to not break everything, we'd need to apply those overlays at build time to produce a single board dtb. OTOH, phones aren't really supported in mainline and vendors will do it wrong before mainline gets around to it. > This could be used as a template for creating specific board DTs. > Ideally vendors could put those on their boards: into some flash or > integrated into the firmware (as part of U-Boot, for instance). That's really a separate problem from where are dts files maintained. Does u-boot support using the same dtb to configure itself and to pass to the kernel yet? That was a foreign concept though I think it was being worked on. > And having a source for the .dtsi should make it easier to get a > readable de-compilation of a given .dtb. If such a tool existed to add back the annotations. YAML will solve that, I'm sure. > We could collect .dts files for boards somewhere else. It's already the > case that we have some boards with a specific SoC "supported by the > kernel" and some not, for no technical reason at all, actually. It's > just whether there is someone willing to post (and push through) a .dts > file. We could start accepting (but not requiring) patches against the devicetree-rebasing.git tree if that solves the problem of "kernel bindings" and "kernel dts files". We can mechanically convert their paths back to kernel paths and apply them. I've got no issue signing up to that because I fully expect that to be only a trickle. Rob ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 15:32 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-18 15:32 UTC (permalink / raw) To: Andre Przywara, Michal Simek Cc: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Frank Rowand On Wed, Oct 18, 2017 at 9:28 AM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote: > Hi, > > On 18/10/17 15:04, Michal Simek wrote: >> On 16.10.2017 16:11, Rob Herring wrote: >>> On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote: >>>> Hi, >>>> >>>> On 9.10.2017 22:39, Grant Likely wrote: >>>>> Kernel Summit is now just over 2 weeks away and it is time to pull >>>>> together the schedule for the Devicetree workshop. Originally I >>>>> planned on just an afternoon, but I've got the room for the whole day, >>>>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>>>> be used for hacking. >>>>> >>>>> Date: 26 Oct 2017 >>>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>>>> Location: Athens room - Hilton Prague >>>>> >>>>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>>>> registration to include the DT Workshop (log in to access and modify >>>>> your registration): >>>>> >>>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>>>> >>>>> Here is my current list of topics in no particular order, including >>>>> the topic moderator: >>>>> >>>>> Runtime memory consumption (Rob Herring) >>>>> Overlay maintenance plan (TBC) >>>>> Stable ABI for devicetree (TBC) >>>>> DT YAML encoding (Pantelis Antoniou) >>>>> DT Schema format - option 1 (Pantelis Antoniou) >>>>> DT Schema format - option 2 (Grant Likely) >>>>> Sharing Generic bindings (TBC) >>>>> devicetree.org update (Grant) >>>>> >>>>> Reply to this email if you want to propose another topic. >>>>> >>>>> Reply privately if there is a particular topic you want to attend but >>>>> you are unable to be there in the morning or afternoon. I'll put the >>>>> actual agenda together a week out from the event. >>>> >>>> I would like to talk how to add support for AArch32 based on arm64 dts file. >>> >>> We already have that for RPi3, but it's a bit hacky in that you have >>> to include files from one arch to the other. What I'd like to see >>> ideally is no dependency on $ARCH to build dts files. You can't build >>> dts files for an arch without a cross-compiler installed which is an >>> artificial dependency. The dtb should be independent of whether you're >>> building for 32 or 64 bit. >> >> I wasn't aware about RPI3 but yes - I have seen the same for ZynqMP. >> >>> >>> There's the other aspect of being able to do armv8 32-bit builds as >>> there's no explicit support for v8 in arch/arm/. But that's not a DT >>> issue. >> >> Yep including Kconfig.platforms is required. >> >>> >>>> And next topic is discuss criteria for adding new DTS board files to >>>> kernel for supporting custom boards especially for arm32 which can end >>>> up with a lot of dts files in this folder. >>> >>> We really should move the arm32 files into subdirs for each SoC vendor >>> IMO, but I think armsoc maintainers have been against that churn. >> >> As you said above maybe we should consider to move all DTS files out of >> arch folder and sorted them based on SoC vendor. It sounds like a good >> topic to discuss. That is 2 separate topics really. For the latter, you need to come up with reasons to justify the churn. >>>> If make sense to permit only boards with something new or just enable >>>> reference boards to go in. >>> >>> The board dts files are generally pretty minimal. What's the issue >>> here? Just lots of files in arch/arm/boot/dts? >> >> yep. A lot of files there. Are we approaching the limits of # of files in one directory? Is Arnd/Olof or Linus complaining about there being too many files to maintain? Do sub-arch maintainers not know which files are theirs? What problem are we trying to solve here? If we're talking about moving bindings and dts files out of the kernel, then call it that. Otherwise, let's not mix the topics. Unless you want nothing to happen then tie it to moving to a separate repository. > I was wondering whether we should really stop providing .dts files for > *boards* in the *kernel* tree. In my impression this was more a stop-gap > measure to bridge the transition from board files to DT. Not really. A stop-gap would be a couple of kernel cycles in my mind. PPC dts files have been there forever practically. > Given that the particular board files are rather boring anyway, wouldn't > it be sufficient to just include the SoC .dtsi plus one (or two) example > .dts, for instance for the official evaluation board? That sounds horrible to manage. You are assuming the split between board and SoC specifics are done perfectly from the start. I haven't checked the history, but I'm going to guess that has not been the case. That would effectively make the split be an ABI. Folks have enough issues with the entire dtb being an ABI. However, there is a coming issue with Android project Treble which does say all board specifics are an overlay (or multiple overlays) to a common SoC base dtb which does make the split an ABI. For mainline to handle this, we'd need to start making the board files overlays. And to not break everything, we'd need to apply those overlays at build time to produce a single board dtb. OTOH, phones aren't really supported in mainline and vendors will do it wrong before mainline gets around to it. > This could be used as a template for creating specific board DTs. > Ideally vendors could put those on their boards: into some flash or > integrated into the firmware (as part of U-Boot, for instance). That's really a separate problem from where are dts files maintained. Does u-boot support using the same dtb to configure itself and to pass to the kernel yet? That was a foreign concept though I think it was being worked on. > And having a source for the .dtsi should make it easier to get a > readable de-compilation of a given .dtb. If such a tool existed to add back the annotations. YAML will solve that, I'm sure. > We could collect .dts files for boards somewhere else. It's already the > case that we have some boards with a specific SoC "supported by the > kernel" and some not, for no technical reason at all, actually. It's > just whether there is someone willing to post (and push through) a .dts > file. We could start accepting (but not requiring) patches against the devicetree-rebasing.git tree if that solves the problem of "kernel bindings" and "kernel dts files". We can mechanically convert their paths back to kernel paths and apply them. I've got no issue signing up to that because I fully expect that to be only a trickle. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 16:05 ` Andre Przywara 0 siblings, 0 replies; 126+ messages in thread From: Andre Przywara @ 2017-10-18 16:05 UTC (permalink / raw) To: Rob Herring, Michal Simek Cc: devicetree, Kumar Gala, ksummit-discuss, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson Hi, On 18/10/17 16:32, Rob Herring wrote: > On Wed, Oct 18, 2017 at 9:28 AM, Andre Przywara <andre.przywara@arm.com> wrote: >> Hi, >> >> On 18/10/17 15:04, Michal Simek wrote: >>> On 16.10.2017 16:11, Rob Herring wrote: >>>> On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr@monstr.eu> wrote: >>>>> Hi, >>>>> >>>>> On 9.10.2017 22:39, Grant Likely wrote: >>>>>> Kernel Summit is now just over 2 weeks away and it is time to pull >>>>>> together the schedule for the Devicetree workshop. Originally I >>>>>> planned on just an afternoon, but I've got the room for the whole day, >>>>>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>>>>> be used for hacking. >>>>>> >>>>>> Date: 26 Oct 2017 >>>>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>>>>> Location: Athens room - Hilton Prague >>>>>> >>>>>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>>>>> registration to include the DT Workshop (log in to access and modify >>>>>> your registration): >>>>>> >>>>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>>>>> >>>>>> Here is my current list of topics in no particular order, including >>>>>> the topic moderator: >>>>>> >>>>>> Runtime memory consumption (Rob Herring) >>>>>> Overlay maintenance plan (TBC) >>>>>> Stable ABI for devicetree (TBC) >>>>>> DT YAML encoding (Pantelis Antoniou) >>>>>> DT Schema format - option 1 (Pantelis Antoniou) >>>>>> DT Schema format - option 2 (Grant Likely) >>>>>> Sharing Generic bindings (TBC) >>>>>> devicetree.org update (Grant) >>>>>> >>>>>> Reply to this email if you want to propose another topic. >>>>>> >>>>>> Reply privately if there is a particular topic you want to attend but >>>>>> you are unable to be there in the morning or afternoon. I'll put the >>>>>> actual agenda together a week out from the event. >>>>> >>>>> I would like to talk how to add support for AArch32 based on arm64 dts file. >>>> >>>> We already have that for RPi3, but it's a bit hacky in that you have >>>> to include files from one arch to the other. What I'd like to see >>>> ideally is no dependency on $ARCH to build dts files. You can't build >>>> dts files for an arch without a cross-compiler installed which is an >>>> artificial dependency. The dtb should be independent of whether you're >>>> building for 32 or 64 bit. >>> >>> I wasn't aware about RPI3 but yes - I have seen the same for ZynqMP. >>> >>>> >>>> There's the other aspect of being able to do armv8 32-bit builds as >>>> there's no explicit support for v8 in arch/arm/. But that's not a DT >>>> issue. >>> >>> Yep including Kconfig.platforms is required. >>> >>>> >>>>> And next topic is discuss criteria for adding new DTS board files to >>>>> kernel for supporting custom boards especially for arm32 which can end >>>>> up with a lot of dts files in this folder. >>>> >>>> We really should move the arm32 files into subdirs for each SoC vendor >>>> IMO, but I think armsoc maintainers have been against that churn. >>> >>> As you said above maybe we should consider to move all DTS files out of >>> arch folder and sorted them based on SoC vendor. It sounds like a good >>> topic to discuss. > > That is 2 separate topics really. For the latter, you need to come up > with reasons to justify the churn. > >>>>> If make sense to permit only boards with something new or just enable >>>>> reference boards to go in. >>>> >>>> The board dts files are generally pretty minimal. What's the issue >>>> here? Just lots of files in arch/arm/boot/dts? >>> >>> yep. A lot of files there. > > Are we approaching the limits of # of files in one directory? Is > Arnd/Olof or Linus complaining about there being too many files to > maintain? Do sub-arch maintainers not know which files are theirs? > What problem are we trying to solve here? > > If we're talking about moving bindings and dts files out of the > kernel, then call it that. Otherwise, let's not mix the topics. Unless > you want nothing to happen then tie it to moving to a separate > repository. > >> I was wondering whether we should really stop providing .dts files for >> *boards* in the *kernel* tree. In my impression this was more a stop-gap >> measure to bridge the transition from board files to DT. > > Not really. A stop-gap would be a couple of kernel cycles in my mind. > PPC dts files have been there forever practically. > >> Given that the particular board files are rather boring anyway, wouldn't >> it be sufficient to just include the SoC .dtsi plus one (or two) example >> .dts, for instance for the official evaluation board? > > That sounds horrible to manage. You are assuming the split between > board and SoC specifics are done perfectly from the start. I haven't > checked the history, but I'm going to guess that has not been the > case. That would effectively make the split be an ABI. Folks have > enough issues with the entire dtb being an ABI. I agree that we should not create an ABI between the SoC's .dtsi the board's .dts files. But eventually people would put *.dtbs* on their boards, so we don't really care, as long as they are created from the right combination of both. At the end of the day a vendor actually doesn't really need to provide a DT matching exactly the kernel version, as long as it does not violate any bindings. > However, there is a coming issue with Android project Treble which > does say all board specifics are an overlay (or multiple overlays) to > a common SoC base dtb which does make the split an ABI. For mainline > to handle this, we'd need to start making the board files overlays. That does not sound good ... > And to not break everything, we'd need to apply those overlays at > build time to produce a single board dtb. OTOH, phones aren't really > supported in mainline and vendors will do it wrong before mainline > gets around to it. > >> This could be used as a template for creating specific board DTs. >> Ideally vendors could put those on their boards: into some flash or >> integrated into the firmware (as part of U-Boot, for instance). > > That's really a separate problem from where are dts files maintained. > > Does u-boot support using the same dtb to configure itself and to pass > to the kernel yet? That was a foreign concept though I think it was > being worked on. That works already for some platforms or SoCs, as long as someone cares to keep the U-Boot copy up-to-date with the kernel version [1]. I boot the Pine64 with $fdtcontroladdr (which points to U-Boot's .dtb) these days, without the need to load any .dtb. And on some boards U-Boot lives in SPI flash, so the .dtb is really tied to the board. Like on Highbank/Midway ;-) Also this is the default address which the bootuefi command takes when there is nothing more specific provided. But this is purely platform specific, and for some of them the DT used in U-Boot is quite different from the kernel version. Although this can be fixed, as the U-Boot drivers can be changed and don't adhere to some ABI. >> And having a source for the .dtsi should make it easier to get a >> readable de-compilation of a given .dtb. > > If such a tool existed to add back the annotations. YAML will solve > that, I'm sure. Yes, but you need some extra JSON to recover the formatting ;-) >> We could collect .dts files for boards somewhere else. It's already the >> case that we have some boards with a specific SoC "supported by the >> kernel" and some not, for no technical reason at all, actually. It's >> just whether there is someone willing to post (and push through) a .dts >> file. > > We could start accepting (but not requiring) patches against the > devicetree-rebasing.git tree if that solves the problem of "kernel > bindings" and "kernel dts files". We can mechanically convert their > paths back to kernel paths and apply them. I've got no issue signing > up to that because I fully expect that to be only a trickle. But that would mean that they would still live in the kernel, right? Cheers, Andre. [1] http://git.denx.de/?p=u-boot.git;a=commit;h=f98852bfa9a99d7258eb06e4849e5c3d075f44cf > > Rob > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 16:05 ` Andre Przywara 0 siblings, 0 replies; 126+ messages in thread From: Andre Przywara @ 2017-10-18 16:05 UTC (permalink / raw) To: Rob Herring, Michal Simek Cc: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Frank Rowand Hi, On 18/10/17 16:32, Rob Herring wrote: > On Wed, Oct 18, 2017 at 9:28 AM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote: >> Hi, >> >> On 18/10/17 15:04, Michal Simek wrote: >>> On 16.10.2017 16:11, Rob Herring wrote: >>>> On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote: >>>>> Hi, >>>>> >>>>> On 9.10.2017 22:39, Grant Likely wrote: >>>>>> Kernel Summit is now just over 2 weeks away and it is time to pull >>>>>> together the schedule for the Devicetree workshop. Originally I >>>>>> planned on just an afternoon, but I've got the room for the whole day, >>>>>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>>>>> be used for hacking. >>>>>> >>>>>> Date: 26 Oct 2017 >>>>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>>>>> Location: Athens room - Hilton Prague >>>>>> >>>>>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>>>>> registration to include the DT Workshop (log in to access and modify >>>>>> your registration): >>>>>> >>>>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>>>>> >>>>>> Here is my current list of topics in no particular order, including >>>>>> the topic moderator: >>>>>> >>>>>> Runtime memory consumption (Rob Herring) >>>>>> Overlay maintenance plan (TBC) >>>>>> Stable ABI for devicetree (TBC) >>>>>> DT YAML encoding (Pantelis Antoniou) >>>>>> DT Schema format - option 1 (Pantelis Antoniou) >>>>>> DT Schema format - option 2 (Grant Likely) >>>>>> Sharing Generic bindings (TBC) >>>>>> devicetree.org update (Grant) >>>>>> >>>>>> Reply to this email if you want to propose another topic. >>>>>> >>>>>> Reply privately if there is a particular topic you want to attend but >>>>>> you are unable to be there in the morning or afternoon. I'll put the >>>>>> actual agenda together a week out from the event. >>>>> >>>>> I would like to talk how to add support for AArch32 based on arm64 dts file. >>>> >>>> We already have that for RPi3, but it's a bit hacky in that you have >>>> to include files from one arch to the other. What I'd like to see >>>> ideally is no dependency on $ARCH to build dts files. You can't build >>>> dts files for an arch without a cross-compiler installed which is an >>>> artificial dependency. The dtb should be independent of whether you're >>>> building for 32 or 64 bit. >>> >>> I wasn't aware about RPI3 but yes - I have seen the same for ZynqMP. >>> >>>> >>>> There's the other aspect of being able to do armv8 32-bit builds as >>>> there's no explicit support for v8 in arch/arm/. But that's not a DT >>>> issue. >>> >>> Yep including Kconfig.platforms is required. >>> >>>> >>>>> And next topic is discuss criteria for adding new DTS board files to >>>>> kernel for supporting custom boards especially for arm32 which can end >>>>> up with a lot of dts files in this folder. >>>> >>>> We really should move the arm32 files into subdirs for each SoC vendor >>>> IMO, but I think armsoc maintainers have been against that churn. >>> >>> As you said above maybe we should consider to move all DTS files out of >>> arch folder and sorted them based on SoC vendor. It sounds like a good >>> topic to discuss. > > That is 2 separate topics really. For the latter, you need to come up > with reasons to justify the churn. > >>>>> If make sense to permit only boards with something new or just enable >>>>> reference boards to go in. >>>> >>>> The board dts files are generally pretty minimal. What's the issue >>>> here? Just lots of files in arch/arm/boot/dts? >>> >>> yep. A lot of files there. > > Are we approaching the limits of # of files in one directory? Is > Arnd/Olof or Linus complaining about there being too many files to > maintain? Do sub-arch maintainers not know which files are theirs? > What problem are we trying to solve here? > > If we're talking about moving bindings and dts files out of the > kernel, then call it that. Otherwise, let's not mix the topics. Unless > you want nothing to happen then tie it to moving to a separate > repository. > >> I was wondering whether we should really stop providing .dts files for >> *boards* in the *kernel* tree. In my impression this was more a stop-gap >> measure to bridge the transition from board files to DT. > > Not really. A stop-gap would be a couple of kernel cycles in my mind. > PPC dts files have been there forever practically. > >> Given that the particular board files are rather boring anyway, wouldn't >> it be sufficient to just include the SoC .dtsi plus one (or two) example >> .dts, for instance for the official evaluation board? > > That sounds horrible to manage. You are assuming the split between > board and SoC specifics are done perfectly from the start. I haven't > checked the history, but I'm going to guess that has not been the > case. That would effectively make the split be an ABI. Folks have > enough issues with the entire dtb being an ABI. I agree that we should not create an ABI between the SoC's .dtsi the board's .dts files. But eventually people would put *.dtbs* on their boards, so we don't really care, as long as they are created from the right combination of both. At the end of the day a vendor actually doesn't really need to provide a DT matching exactly the kernel version, as long as it does not violate any bindings. > However, there is a coming issue with Android project Treble which > does say all board specifics are an overlay (or multiple overlays) to > a common SoC base dtb which does make the split an ABI. For mainline > to handle this, we'd need to start making the board files overlays. That does not sound good ... > And to not break everything, we'd need to apply those overlays at > build time to produce a single board dtb. OTOH, phones aren't really > supported in mainline and vendors will do it wrong before mainline > gets around to it. > >> This could be used as a template for creating specific board DTs. >> Ideally vendors could put those on their boards: into some flash or >> integrated into the firmware (as part of U-Boot, for instance). > > That's really a separate problem from where are dts files maintained. > > Does u-boot support using the same dtb to configure itself and to pass > to the kernel yet? That was a foreign concept though I think it was > being worked on. That works already for some platforms or SoCs, as long as someone cares to keep the U-Boot copy up-to-date with the kernel version [1]. I boot the Pine64 with $fdtcontroladdr (which points to U-Boot's .dtb) these days, without the need to load any .dtb. And on some boards U-Boot lives in SPI flash, so the .dtb is really tied to the board. Like on Highbank/Midway ;-) Also this is the default address which the bootuefi command takes when there is nothing more specific provided. But this is purely platform specific, and for some of them the DT used in U-Boot is quite different from the kernel version. Although this can be fixed, as the U-Boot drivers can be changed and don't adhere to some ABI. >> And having a source for the .dtsi should make it easier to get a >> readable de-compilation of a given .dtb. > > If such a tool existed to add back the annotations. YAML will solve > that, I'm sure. Yes, but you need some extra JSON to recover the formatting ;-) >> We could collect .dts files for boards somewhere else. It's already the >> case that we have some boards with a specific SoC "supported by the >> kernel" and some not, for no technical reason at all, actually. It's >> just whether there is someone willing to post (and push through) a .dts >> file. > > We could start accepting (but not requiring) patches against the > devicetree-rebasing.git tree if that solves the problem of "kernel > bindings" and "kernel dts files". We can mechanically convert their > paths back to kernel paths and apply them. I've got no issue signing > up to that because I fully expect that to be only a trickle. But that would mean that they would still live in the kernel, right? Cheers, Andre. [1] http://git.denx.de/?p=u-boot.git;a=commit;h=f98852bfa9a99d7258eb06e4849e5c3d075f44cf > > Rob > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 16:20 ` Pantelis Antoniou 0 siblings, 0 replies; 126+ messages in thread From: Pantelis Antoniou @ 2017-10-18 16:20 UTC (permalink / raw) To: Andre Przywara Cc: Rob Herring, Kumar Gala, ksummit-discuss, devicetree, devicetree-spec, Andy Gross, Lucas Stach, David Gibson Hi Andre, On Wed, 2017-10-18 at 17:05 +0100, Andre Przywara wrote: > Hi, > > On 18/10/17 16:32, Rob Herring wrote: > > On Wed, Oct 18, 2017 at 9:28 AM, Andre Przywara <andre.przywara@arm.com> wrote: > >> Hi, > >> > >> On 18/10/17 15:04, Michal Simek wrote: > >>> On 16.10.2017 16:11, Rob Herring wrote: > >>>> On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr@monstr.eu> wrote: > >>>>> Hi, > >>>>> > >>>>> On 9.10.2017 22:39, Grant Likely wrote: > >>>>>> Kernel Summit is now just over 2 weeks away and it is time to pull > >>>>>> together the schedule for the Devicetree workshop. Originally I > >>>>>> planned on just an afternoon, but I've got the room for the whole day, > >>>>>> so I've got a lot of flexibility on the schedule. Unscheduled time can > >>>>>> be used for hacking. > >>>>>> > >>>>>> Date: 26 Oct 2017 > >>>>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > >>>>>> Location: Athens room - Hilton Prague > >>>>>> > >>>>>> If you plan to attend, make sure you update your OSSunmitE/ELCE > >>>>>> registration to include the DT Workshop (log in to access and modify > >>>>>> your registration): > >>>>>> > >>>>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > >>>>>> > >>>>>> Here is my current list of topics in no particular order, including > >>>>>> the topic moderator: > >>>>>> > >>>>>> Runtime memory consumption (Rob Herring) > >>>>>> Overlay maintenance plan (TBC) > >>>>>> Stable ABI for devicetree (TBC) > >>>>>> DT YAML encoding (Pantelis Antoniou) > >>>>>> DT Schema format - option 1 (Pantelis Antoniou) > >>>>>> DT Schema format - option 2 (Grant Likely) > >>>>>> Sharing Generic bindings (TBC) > >>>>>> devicetree.org update (Grant) > >>>>>> > >>>>>> Reply to this email if you want to propose another topic. > >>>>>> > >>>>>> Reply privately if there is a particular topic you want to attend but > >>>>>> you are unable to be there in the morning or afternoon. I'll put the > >>>>>> actual agenda together a week out from the event. > >>>>> > >>>>> I would like to talk how to add support for AArch32 based on arm64 dts file. > >>>> > >>>> We already have that for RPi3, but it's a bit hacky in that you have > >>>> to include files from one arch to the other. What I'd like to see > >>>> ideally is no dependency on $ARCH to build dts files. You can't build > >>>> dts files for an arch without a cross-compiler installed which is an > >>>> artificial dependency. The dtb should be independent of whether you're > >>>> building for 32 or 64 bit. > >>> > >>> I wasn't aware about RPI3 but yes - I have seen the same for ZynqMP. > >>> > >>>> > >>>> There's the other aspect of being able to do armv8 32-bit builds as > >>>> there's no explicit support for v8 in arch/arm/. But that's not a DT > >>>> issue. > >>> > >>> Yep including Kconfig.platforms is required. > >>> > >>>> > >>>>> And next topic is discuss criteria for adding new DTS board files to > >>>>> kernel for supporting custom boards especially for arm32 which can end > >>>>> up with a lot of dts files in this folder. > >>>> > >>>> We really should move the arm32 files into subdirs for each SoC vendor > >>>> IMO, but I think armsoc maintainers have been against that churn. > >>> > >>> As you said above maybe we should consider to move all DTS files out of > >>> arch folder and sorted them based on SoC vendor. It sounds like a good > >>> topic to discuss. > > > > That is 2 separate topics really. For the latter, you need to come up > > with reasons to justify the churn. > > > >>>>> If make sense to permit only boards with something new or just enable > >>>>> reference boards to go in. > >>>> > >>>> The board dts files are generally pretty minimal. What's the issue > >>>> here? Just lots of files in arch/arm/boot/dts? > >>> > >>> yep. A lot of files there. > > > > Are we approaching the limits of # of files in one directory? Is > > Arnd/Olof or Linus complaining about there being too many files to > > maintain? Do sub-arch maintainers not know which files are theirs? > > What problem are we trying to solve here? > > > > If we're talking about moving bindings and dts files out of the > > kernel, then call it that. Otherwise, let's not mix the topics. Unless > > you want nothing to happen then tie it to moving to a separate > > repository. > > > >> I was wondering whether we should really stop providing .dts files for > >> *boards* in the *kernel* tree. In my impression this was more a stop-gap > >> measure to bridge the transition from board files to DT. > > > > Not really. A stop-gap would be a couple of kernel cycles in my mind. > > PPC dts files have been there forever practically. > > > >> Given that the particular board files are rather boring anyway, wouldn't > >> it be sufficient to just include the SoC .dtsi plus one (or two) example > >> .dts, for instance for the official evaluation board? > > > > That sounds horrible to manage. You are assuming the split between > > board and SoC specifics are done perfectly from the start. I haven't > > checked the history, but I'm going to guess that has not been the > > case. That would effectively make the split be an ABI. Folks have > > enough issues with the entire dtb being an ABI. > > I agree that we should not create an ABI between the SoC's .dtsi the > board's .dts files. But eventually people would put *.dtbs* on their > boards, so we don't really care, as long as they are created from the > right combination of both. > At the end of the day a vendor actually doesn't really need to provide a > DT matching exactly the kernel version, as long as it does not violate > any bindings. > > > However, there is a coming issue with Android project Treble which > > does say all board specifics are an overlay (or multiple overlays) to > > a common SoC base dtb which does make the split an ABI. For mainline > > to handle this, we'd need to start making the board files overlays. > > That does not sound good ... > > > And to not break everything, we'd need to apply those overlays at > > build time to produce a single board dtb. OTOH, phones aren't really > > supported in mainline and vendors will do it wrong before mainline > > gets around to it. > > > >> This could be used as a template for creating specific board DTs. > >> Ideally vendors could put those on their boards: into some flash or > >> integrated into the firmware (as part of U-Boot, for instance). > > > > That's really a separate problem from where are dts files maintained. > > > > Does u-boot support using the same dtb to configure itself and to pass > > to the kernel yet? That was a foreign concept though I think it was > > being worked on. > > That works already for some platforms or SoCs, as long as someone cares > to keep the U-Boot copy up-to-date with the kernel version [1]. > I boot the Pine64 with $fdtcontroladdr (which points to U-Boot's .dtb) > these days, without the need to load any .dtb. And on some boards U-Boot > lives in SPI flash, so the .dtb is really tied to the board. Like on > Highbank/Midway ;-) > > Also this is the default address which the bootuefi command takes when > there is nothing more specific provided. > > But this is purely platform specific, and for some of them the DT used > in U-Boot is quite different from the kernel version. Although this can > be fixed, as the U-Boot drivers can be changed and don't adhere to some ABI. > > >> And having a source for the .dtsi should make it easier to get a > >> readable de-compilation of a given .dtb. > > > > If such a tool existed to add back the annotations. YAML will solve > > that, I'm sure. > > Yes, but you need some extra JSON to recover the formatting ;-) > YAML output preserves references and anchors. But still would not be the same as the original sources since we're now heavily using macros and the preprocessor. Close, but no cigar. > >> We could collect .dts files for boards somewhere else. It's already the > >> case that we have some boards with a specific SoC "supported by the > >> kernel" and some not, for no technical reason at all, actually. It's > >> just whether there is someone willing to post (and push through) a .dts > >> file. > > > > We could start accepting (but not requiring) patches against the > > devicetree-rebasing.git tree if that solves the problem of "kernel > > bindings" and "kernel dts files". We can mechanically convert their > > paths back to kernel paths and apply them. I've got no issue signing > > up to that because I fully expect that to be only a trickle. > > But that would mean that they would still live in the kernel, right? > > Cheers, > Andre. > > [1] > http://git.denx.de/?p=u-boot.git;a=commit;h=f98852bfa9a99d7258eb06e4849e5c3d075f44cf > > > > Rob > > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 16:20 ` Pantelis Antoniou 0 siblings, 0 replies; 126+ messages in thread From: Pantelis Antoniou @ 2017-10-18 16:20 UTC (permalink / raw) To: Andre Przywara Cc: Rob Herring, Michal Simek, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Lucas Stach, Kumar Gala, Andy Gross, Frank Rowand Hi Andre, On Wed, 2017-10-18 at 17:05 +0100, Andre Przywara wrote: > Hi, > > On 18/10/17 16:32, Rob Herring wrote: > > On Wed, Oct 18, 2017 at 9:28 AM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote: > >> Hi, > >> > >> On 18/10/17 15:04, Michal Simek wrote: > >>> On 16.10.2017 16:11, Rob Herring wrote: > >>>> On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote: > >>>>> Hi, > >>>>> > >>>>> On 9.10.2017 22:39, Grant Likely wrote: > >>>>>> Kernel Summit is now just over 2 weeks away and it is time to pull > >>>>>> together the schedule for the Devicetree workshop. Originally I > >>>>>> planned on just an afternoon, but I've got the room for the whole day, > >>>>>> so I've got a lot of flexibility on the schedule. Unscheduled time can > >>>>>> be used for hacking. > >>>>>> > >>>>>> Date: 26 Oct 2017 > >>>>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > >>>>>> Location: Athens room - Hilton Prague > >>>>>> > >>>>>> If you plan to attend, make sure you update your OSSunmitE/ELCE > >>>>>> registration to include the DT Workshop (log in to access and modify > >>>>>> your registration): > >>>>>> > >>>>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > >>>>>> > >>>>>> Here is my current list of topics in no particular order, including > >>>>>> the topic moderator: > >>>>>> > >>>>>> Runtime memory consumption (Rob Herring) > >>>>>> Overlay maintenance plan (TBC) > >>>>>> Stable ABI for devicetree (TBC) > >>>>>> DT YAML encoding (Pantelis Antoniou) > >>>>>> DT Schema format - option 1 (Pantelis Antoniou) > >>>>>> DT Schema format - option 2 (Grant Likely) > >>>>>> Sharing Generic bindings (TBC) > >>>>>> devicetree.org update (Grant) > >>>>>> > >>>>>> Reply to this email if you want to propose another topic. > >>>>>> > >>>>>> Reply privately if there is a particular topic you want to attend but > >>>>>> you are unable to be there in the morning or afternoon. I'll put the > >>>>>> actual agenda together a week out from the event. > >>>>> > >>>>> I would like to talk how to add support for AArch32 based on arm64 dts file. > >>>> > >>>> We already have that for RPi3, but it's a bit hacky in that you have > >>>> to include files from one arch to the other. What I'd like to see > >>>> ideally is no dependency on $ARCH to build dts files. You can't build > >>>> dts files for an arch without a cross-compiler installed which is an > >>>> artificial dependency. The dtb should be independent of whether you're > >>>> building for 32 or 64 bit. > >>> > >>> I wasn't aware about RPI3 but yes - I have seen the same for ZynqMP. > >>> > >>>> > >>>> There's the other aspect of being able to do armv8 32-bit builds as > >>>> there's no explicit support for v8 in arch/arm/. But that's not a DT > >>>> issue. > >>> > >>> Yep including Kconfig.platforms is required. > >>> > >>>> > >>>>> And next topic is discuss criteria for adding new DTS board files to > >>>>> kernel for supporting custom boards especially for arm32 which can end > >>>>> up with a lot of dts files in this folder. > >>>> > >>>> We really should move the arm32 files into subdirs for each SoC vendor > >>>> IMO, but I think armsoc maintainers have been against that churn. > >>> > >>> As you said above maybe we should consider to move all DTS files out of > >>> arch folder and sorted them based on SoC vendor. It sounds like a good > >>> topic to discuss. > > > > That is 2 separate topics really. For the latter, you need to come up > > with reasons to justify the churn. > > > >>>>> If make sense to permit only boards with something new or just enable > >>>>> reference boards to go in. > >>>> > >>>> The board dts files are generally pretty minimal. What's the issue > >>>> here? Just lots of files in arch/arm/boot/dts? > >>> > >>> yep. A lot of files there. > > > > Are we approaching the limits of # of files in one directory? Is > > Arnd/Olof or Linus complaining about there being too many files to > > maintain? Do sub-arch maintainers not know which files are theirs? > > What problem are we trying to solve here? > > > > If we're talking about moving bindings and dts files out of the > > kernel, then call it that. Otherwise, let's not mix the topics. Unless > > you want nothing to happen then tie it to moving to a separate > > repository. > > > >> I was wondering whether we should really stop providing .dts files for > >> *boards* in the *kernel* tree. In my impression this was more a stop-gap > >> measure to bridge the transition from board files to DT. > > > > Not really. A stop-gap would be a couple of kernel cycles in my mind. > > PPC dts files have been there forever practically. > > > >> Given that the particular board files are rather boring anyway, wouldn't > >> it be sufficient to just include the SoC .dtsi plus one (or two) example > >> .dts, for instance for the official evaluation board? > > > > That sounds horrible to manage. You are assuming the split between > > board and SoC specifics are done perfectly from the start. I haven't > > checked the history, but I'm going to guess that has not been the > > case. That would effectively make the split be an ABI. Folks have > > enough issues with the entire dtb being an ABI. > > I agree that we should not create an ABI between the SoC's .dtsi the > board's .dts files. But eventually people would put *.dtbs* on their > boards, so we don't really care, as long as they are created from the > right combination of both. > At the end of the day a vendor actually doesn't really need to provide a > DT matching exactly the kernel version, as long as it does not violate > any bindings. > > > However, there is a coming issue with Android project Treble which > > does say all board specifics are an overlay (or multiple overlays) to > > a common SoC base dtb which does make the split an ABI. For mainline > > to handle this, we'd need to start making the board files overlays. > > That does not sound good ... > > > And to not break everything, we'd need to apply those overlays at > > build time to produce a single board dtb. OTOH, phones aren't really > > supported in mainline and vendors will do it wrong before mainline > > gets around to it. > > > >> This could be used as a template for creating specific board DTs. > >> Ideally vendors could put those on their boards: into some flash or > >> integrated into the firmware (as part of U-Boot, for instance). > > > > That's really a separate problem from where are dts files maintained. > > > > Does u-boot support using the same dtb to configure itself and to pass > > to the kernel yet? That was a foreign concept though I think it was > > being worked on. > > That works already for some platforms or SoCs, as long as someone cares > to keep the U-Boot copy up-to-date with the kernel version [1]. > I boot the Pine64 with $fdtcontroladdr (which points to U-Boot's .dtb) > these days, without the need to load any .dtb. And on some boards U-Boot > lives in SPI flash, so the .dtb is really tied to the board. Like on > Highbank/Midway ;-) > > Also this is the default address which the bootuefi command takes when > there is nothing more specific provided. > > But this is purely platform specific, and for some of them the DT used > in U-Boot is quite different from the kernel version. Although this can > be fixed, as the U-Boot drivers can be changed and don't adhere to some ABI. > > >> And having a source for the .dtsi should make it easier to get a > >> readable de-compilation of a given .dtb. > > > > If such a tool existed to add back the annotations. YAML will solve > > that, I'm sure. > > Yes, but you need some extra JSON to recover the formatting ;-) > YAML output preserves references and anchors. But still would not be the same as the original sources since we're now heavily using macros and the preprocessor. Close, but no cigar. > >> We could collect .dts files for boards somewhere else. It's already the > >> case that we have some boards with a specific SoC "supported by the > >> kernel" and some not, for no technical reason at all, actually. It's > >> just whether there is someone willing to post (and push through) a .dts > >> file. > > > > We could start accepting (but not requiring) patches against the > > devicetree-rebasing.git tree if that solves the problem of "kernel > > bindings" and "kernel dts files". We can mechanically convert their > > paths back to kernel paths and apply them. I've got no issue signing > > up to that because I fully expect that to be only a trickle. > > But that would mean that they would still live in the kernel, right? > > Cheers, > Andre. > > [1] > http://git.denx.de/?p=u-boot.git;a=commit;h=f98852bfa9a99d7258eb06e4849e5c3d075f44cf > > > > Rob > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-16 16:40 ` Ben Dooks 0 siblings, 0 replies; 126+ messages in thread From: Ben Dooks @ 2017-10-16 16:40 UTC (permalink / raw) To: monstr, Grant Likely, devicetree, devicetree-spec, ksummit-discuss, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand On 16/10/17 06:36, Michal Simek wrote: > Hi, > > On 9.10.2017 22:39, Grant Likely wrote: >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. >> >> Reply privately if there is a particular topic you want to attend but >> you are unable to be there in the morning or afternoon. I'll put the >> actual agenda together a week out from the event. > > I would like to talk how to add support for AArch32 based on arm64 dts file. > > And next topic is discuss criteria for adding new DTS board files to > kernel for supporting custom boards especially for arm32 which can end > up with a lot of dts files in this folder. > If make sense to permit only boards with something new or just enable > reference boards to go in. I am interested in this, as we seem to be repeating the quantity issue with the board file of having many .dts sources in the kernel. I'm not sure how to deal with this, on one hand only having the reference (and possibly popular) boards is going to keep the size down. On the other hand out of tree .dts files are going to be difficult to find (or vanish with the vendor). It seems we are still no closer to having a DT repository outside the kernel. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-16 16:40 ` Ben Dooks 0 siblings, 0 replies; 126+ messages in thread From: Ben Dooks @ 2017-10-16 16:40 UTC (permalink / raw) To: monstr-pSz03upnqPeHXe+LvDLADg, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand On 16/10/17 06:36, Michal Simek wrote: > Hi, > > On 9.10.2017 22:39, Grant Likely wrote: >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. >> >> Reply privately if there is a particular topic you want to attend but >> you are unable to be there in the morning or afternoon. I'll put the >> actual agenda together a week out from the event. > > I would like to talk how to add support for AArch32 based on arm64 dts file. > > And next topic is discuss criteria for adding new DTS board files to > kernel for supporting custom boards especially for arm32 which can end > up with a lot of dts files in this folder. > If make sense to permit only boards with something new or just enable > reference boards to go in. I am interested in this, as we seem to be repeating the quantity issue with the board file of having many .dts sources in the kernel. I'm not sure how to deal with this, on one hand only having the reference (and possibly popular) boards is going to keep the size down. On the other hand out of tree .dts files are going to be difficult to find (or vanish with the vendor). It seems we are still no closer to having a DT repository outside the kernel. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-16 18:44 ` Heiko Stübner 0 siblings, 0 replies; 126+ messages in thread From: Heiko Stübner @ 2017-10-16 18:44 UTC (permalink / raw) To: ksummit-discuss Cc: devicetree, Kumar Gala, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson Am Montag, 16. Oktober 2017, 17:40:57 CEST schrieb Ben Dooks: > On 16/10/17 06:36, Michal Simek wrote: > > Hi, > > > > On 9.10.2017 22:39, Grant Likely wrote: > >> Kernel Summit is now just over 2 weeks away and it is time to pull > >> together the schedule for the Devicetree workshop. Originally I > >> planned on just an afternoon, but I've got the room for the whole day, > >> so I've got a lot of flexibility on the schedule. Unscheduled time can > >> be used for hacking. > >> > >> Date: 26 Oct 2017 > >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > >> Location: Athens room - Hilton Prague > >> > >> If you plan to attend, make sure you update your OSSunmitE/ELCE > >> registration to include the DT Workshop (log in to access and modify > >> your registration): > >> > >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0& > >> EventsessionId=&Email_Address=&membershipID= > >> > >> Here is my current list of topics in no particular order, including > >> the topic moderator: > >> > >> Runtime memory consumption (Rob Herring) > >> Overlay maintenance plan (TBC) > >> Stable ABI for devicetree (TBC) > >> DT YAML encoding (Pantelis Antoniou) > >> DT Schema format - option 1 (Pantelis Antoniou) > >> DT Schema format - option 2 (Grant Likely) > >> Sharing Generic bindings (TBC) > >> devicetree.org update (Grant) > >> > >> Reply to this email if you want to propose another topic. > >> > >> Reply privately if there is a particular topic you want to attend but > >> you are unable to be there in the morning or afternoon. I'll put the > >> actual agenda together a week out from the event. > > > > I would like to talk how to add support for AArch32 based on arm64 dts > > file. > > > > And next topic is discuss criteria for adding new DTS board files to > > kernel for supporting custom boards especially for arm32 which can end > > up with a lot of dts files in this folder. > > If make sense to permit only boards with something new or just enable > > reference boards to go in. > > I am interested in this, as we seem to be repeating the quantity > issue with the board file of having many .dts sources in the kernel. > > I'm not sure how to deal with this, on one hand only having the > reference (and possibly popular) boards is going to keep the size > down. On the other hand out of tree .dts files are going to be > difficult to find (or vanish with the vendor). > > It seems we are still no closer to having a DT repository outside > the kernel. There exists https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ While the in-kernel sources are still the authoritative ones, you can at least get a feel for what an out-of-tree repo would feel like. ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-16 18:44 ` Heiko Stübner 0 siblings, 0 replies; 126+ messages in thread From: Heiko Stübner @ 2017-10-16 18:44 UTC (permalink / raw) To: ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I Cc: Ben Dooks, monstr-pSz03upnqPeHXe+LvDLADg, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand Am Montag, 16. Oktober 2017, 17:40:57 CEST schrieb Ben Dooks: > On 16/10/17 06:36, Michal Simek wrote: > > Hi, > > > > On 9.10.2017 22:39, Grant Likely wrote: > >> Kernel Summit is now just over 2 weeks away and it is time to pull > >> together the schedule for the Devicetree workshop. Originally I > >> planned on just an afternoon, but I've got the room for the whole day, > >> so I've got a lot of flexibility on the schedule. Unscheduled time can > >> be used for hacking. > >> > >> Date: 26 Oct 2017 > >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > >> Location: Athens room - Hilton Prague > >> > >> If you plan to attend, make sure you update your OSSunmitE/ELCE > >> registration to include the DT Workshop (log in to access and modify > >> your registration): > >> > >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0& > >> EventsessionId=&Email_Address=&membershipID= > >> > >> Here is my current list of topics in no particular order, including > >> the topic moderator: > >> > >> Runtime memory consumption (Rob Herring) > >> Overlay maintenance plan (TBC) > >> Stable ABI for devicetree (TBC) > >> DT YAML encoding (Pantelis Antoniou) > >> DT Schema format - option 1 (Pantelis Antoniou) > >> DT Schema format - option 2 (Grant Likely) > >> Sharing Generic bindings (TBC) > >> devicetree.org update (Grant) > >> > >> Reply to this email if you want to propose another topic. > >> > >> Reply privately if there is a particular topic you want to attend but > >> you are unable to be there in the morning or afternoon. I'll put the > >> actual agenda together a week out from the event. > > > > I would like to talk how to add support for AArch32 based on arm64 dts > > file. > > > > And next topic is discuss criteria for adding new DTS board files to > > kernel for supporting custom boards especially for arm32 which can end > > up with a lot of dts files in this folder. > > If make sense to permit only boards with something new or just enable > > reference boards to go in. > > I am interested in this, as we seem to be repeating the quantity > issue with the board file of having many .dts sources in the kernel. > > I'm not sure how to deal with this, on one hand only having the > reference (and possibly popular) boards is going to keep the size > down. On the other hand out of tree .dts files are going to be > difficult to find (or vanish with the vendor). > > It seems we are still no closer to having a DT repository outside > the kernel. There exists https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ While the in-kernel sources are still the authoritative ones, you can at least get a feel for what an out-of-tree repo would feel like. ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-16 19:45 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-16 19:45 UTC (permalink / raw) To: Ben Dooks Cc: devicetree, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson On Mon, Oct 16, 2017 at 11:40 AM, Ben Dooks <ben.dooks@codethink.co.uk> wrote: > On 16/10/17 06:36, Michal Simek wrote: >> >> Hi, >> >> On 9.10.2017 22:39, Grant Likely wrote: >>> >>> Kernel Summit is now just over 2 weeks away and it is time to pull >>> together the schedule for the Devicetree workshop. Originally I >>> planned on just an afternoon, but I've got the room for the whole day, >>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>> be used for hacking. >>> >>> Date: 26 Oct 2017 >>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>> Location: Athens room - Hilton Prague >>> >>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>> registration to include the DT Workshop (log in to access and modify >>> your registration): >>> >>> >>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>> >>> Here is my current list of topics in no particular order, including >>> the topic moderator: >>> >>> Runtime memory consumption (Rob Herring) >>> Overlay maintenance plan (TBC) >>> Stable ABI for devicetree (TBC) >>> DT YAML encoding (Pantelis Antoniou) >>> DT Schema format - option 1 (Pantelis Antoniou) >>> DT Schema format - option 2 (Grant Likely) >>> Sharing Generic bindings (TBC) >>> devicetree.org update (Grant) >>> >>> Reply to this email if you want to propose another topic. >>> >>> Reply privately if there is a particular topic you want to attend but >>> you are unable to be there in the morning or afternoon. I'll put the >>> actual agenda together a week out from the event. >> >> >> I would like to talk how to add support for AArch32 based on arm64 dts >> file. >> >> And next topic is discuss criteria for adding new DTS board files to >> kernel for supporting custom boards especially for arm32 which can end >> up with a lot of dts files in this folder. >> If make sense to permit only boards with something new or just enable >> reference boards to go in. > > > I am interested in this, as we seem to be repeating the quantity > issue with the board file of having many .dts sources in the kernel. The problem was not so much having board files in the kernel. It was how to scale support for boards and SoCs with each family structuring things their own, different way. IIRC, the ARM tree was at ~400 boards at the start of DT conversion. Now we're at ~1100 boards for arm/arm64. Plus we still have 264 that aren't converted to DT. > I'm not sure how to deal with this, on one hand only having the > reference (and possibly popular) boards is going to keep the size > down. On the other hand out of tree .dts files are going to be > difficult to find (or vanish with the vendor). Why do we care? What problem is that causing? > It seems we are still no closer to having a DT repository outside > the kernel. In relationship to the above what problem would that solve? We've got all the platform maintainers and arm-soc maintainers to handle dts files. Mark and myself along with subsystem maintainers reviewing and applying device bindings. If you move all that to a separate repository, then you have me because no one else has volunteered. I'm pretty sure no one wants me as the single point of failure. Rob ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-16 19:45 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-16 19:45 UTC (permalink / raw) To: Ben Dooks Cc: Michal Simek, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand On Mon, Oct 16, 2017 at 11:40 AM, Ben Dooks <ben.dooks-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org> wrote: > On 16/10/17 06:36, Michal Simek wrote: >> >> Hi, >> >> On 9.10.2017 22:39, Grant Likely wrote: >>> >>> Kernel Summit is now just over 2 weeks away and it is time to pull >>> together the schedule for the Devicetree workshop. Originally I >>> planned on just an afternoon, but I've got the room for the whole day, >>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>> be used for hacking. >>> >>> Date: 26 Oct 2017 >>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>> Location: Athens room - Hilton Prague >>> >>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>> registration to include the DT Workshop (log in to access and modify >>> your registration): >>> >>> >>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>> >>> Here is my current list of topics in no particular order, including >>> the topic moderator: >>> >>> Runtime memory consumption (Rob Herring) >>> Overlay maintenance plan (TBC) >>> Stable ABI for devicetree (TBC) >>> DT YAML encoding (Pantelis Antoniou) >>> DT Schema format - option 1 (Pantelis Antoniou) >>> DT Schema format - option 2 (Grant Likely) >>> Sharing Generic bindings (TBC) >>> devicetree.org update (Grant) >>> >>> Reply to this email if you want to propose another topic. >>> >>> Reply privately if there is a particular topic you want to attend but >>> you are unable to be there in the morning or afternoon. I'll put the >>> actual agenda together a week out from the event. >> >> >> I would like to talk how to add support for AArch32 based on arm64 dts >> file. >> >> And next topic is discuss criteria for adding new DTS board files to >> kernel for supporting custom boards especially for arm32 which can end >> up with a lot of dts files in this folder. >> If make sense to permit only boards with something new or just enable >> reference boards to go in. > > > I am interested in this, as we seem to be repeating the quantity > issue with the board file of having many .dts sources in the kernel. The problem was not so much having board files in the kernel. It was how to scale support for boards and SoCs with each family structuring things their own, different way. IIRC, the ARM tree was at ~400 boards at the start of DT conversion. Now we're at ~1100 boards for arm/arm64. Plus we still have 264 that aren't converted to DT. > I'm not sure how to deal with this, on one hand only having the > reference (and possibly popular) boards is going to keep the size > down. On the other hand out of tree .dts files are going to be > difficult to find (or vanish with the vendor). Why do we care? What problem is that causing? > It seems we are still no closer to having a DT repository outside > the kernel. In relationship to the above what problem would that solve? We've got all the platform maintainers and arm-soc maintainers to handle dts files. Mark and myself along with subsystem maintainers reviewing and applying device bindings. If you move all that to a separate repository, then you have me because no one else has volunteered. I'm pretty sure no one wants me as the single point of failure. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 13:38 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-17 13:38 UTC (permalink / raw) To: Rob Herring Cc: devicetree, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson On Mon, Oct 16, 2017 at 8:45 PM, Rob Herring <robh@kernel.org> wrote: > On Mon, Oct 16, 2017 at 11:40 AM, Ben Dooks <ben.dooks@codethink.co.uk> wrote: >> On 16/10/17 06:36, Michal Simek wrote: >>> >>> Hi, >>> >>> On 9.10.2017 22:39, Grant Likely wrote: >>>> >>>> Kernel Summit is now just over 2 weeks away and it is time to pull >>>> together the schedule for the Devicetree workshop. Originally I >>>> planned on just an afternoon, but I've got the room for the whole day, >>>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>>> be used for hacking. >>>> >>>> Date: 26 Oct 2017 >>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>>> Location: Athens room - Hilton Prague >>>> >>>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>>> registration to include the DT Workshop (log in to access and modify >>>> your registration): >>>> >>>> >>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>>> >>>> Here is my current list of topics in no particular order, including >>>> the topic moderator: >>>> >>>> Runtime memory consumption (Rob Herring) >>>> Overlay maintenance plan (TBC) >>>> Stable ABI for devicetree (TBC) >>>> DT YAML encoding (Pantelis Antoniou) >>>> DT Schema format - option 1 (Pantelis Antoniou) >>>> DT Schema format - option 2 (Grant Likely) >>>> Sharing Generic bindings (TBC) >>>> devicetree.org update (Grant) >>>> >>>> Reply to this email if you want to propose another topic. >>>> >>>> Reply privately if there is a particular topic you want to attend but >>>> you are unable to be there in the morning or afternoon. I'll put the >>>> actual agenda together a week out from the event. >>> >>> >>> I would like to talk how to add support for AArch32 based on arm64 dts >>> file. >>> >>> And next topic is discuss criteria for adding new DTS board files to >>> kernel for supporting custom boards especially for arm32 which can end >>> up with a lot of dts files in this folder. >>> If make sense to permit only boards with something new or just enable >>> reference boards to go in. >> >> >> I am interested in this, as we seem to be repeating the quantity >> issue with the board file of having many .dts sources in the kernel. > > The problem was not so much having board files in the kernel. It was > how to scale support for boards and SoCs with each family structuring > things their own, different way. > > IIRC, the ARM tree was at ~400 boards at the start of DT conversion. > Now we're at ~1100 boards for arm/arm64. Plus we still have 264 that > aren't converted to DT. > >> I'm not sure how to deal with this, on one hand only having the >> reference (and possibly popular) boards is going to keep the size >> down. On the other hand out of tree .dts files are going to be >> difficult to find (or vanish with the vendor). > > Why do we care? What problem is that causing? In fact, for many platforms that would be a good place to get to if the firmware is providing the .dtb. Plus the DT data formats are so simple that it is not difficult to get a DTB back into a DTS. > >> It seems we are still no closer to having a DT repository outside >> the kernel. > > In relationship to the above what problem would that solve? We've got > all the platform maintainers and arm-soc maintainers to handle dts > files. Mark and myself along with subsystem maintainers reviewing and > applying device bindings. If you move all that to a separate > repository, then you have me because no one else has volunteered. I'm > pretty sure no one wants me as the single point of failure. Yes. When it comes to the bindings, and schema files when we have them, they should be maintained with the tools. g. ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 13:38 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-17 13:38 UTC (permalink / raw) To: Rob Herring Cc: Ben Dooks, Michal Simek, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand On Mon, Oct 16, 2017 at 8:45 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > On Mon, Oct 16, 2017 at 11:40 AM, Ben Dooks <ben.dooks-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org> wrote: >> On 16/10/17 06:36, Michal Simek wrote: >>> >>> Hi, >>> >>> On 9.10.2017 22:39, Grant Likely wrote: >>>> >>>> Kernel Summit is now just over 2 weeks away and it is time to pull >>>> together the schedule for the Devicetree workshop. Originally I >>>> planned on just an afternoon, but I've got the room for the whole day, >>>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>>> be used for hacking. >>>> >>>> Date: 26 Oct 2017 >>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>>> Location: Athens room - Hilton Prague >>>> >>>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>>> registration to include the DT Workshop (log in to access and modify >>>> your registration): >>>> >>>> >>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>>> >>>> Here is my current list of topics in no particular order, including >>>> the topic moderator: >>>> >>>> Runtime memory consumption (Rob Herring) >>>> Overlay maintenance plan (TBC) >>>> Stable ABI for devicetree (TBC) >>>> DT YAML encoding (Pantelis Antoniou) >>>> DT Schema format - option 1 (Pantelis Antoniou) >>>> DT Schema format - option 2 (Grant Likely) >>>> Sharing Generic bindings (TBC) >>>> devicetree.org update (Grant) >>>> >>>> Reply to this email if you want to propose another topic. >>>> >>>> Reply privately if there is a particular topic you want to attend but >>>> you are unable to be there in the morning or afternoon. I'll put the >>>> actual agenda together a week out from the event. >>> >>> >>> I would like to talk how to add support for AArch32 based on arm64 dts >>> file. >>> >>> And next topic is discuss criteria for adding new DTS board files to >>> kernel for supporting custom boards especially for arm32 which can end >>> up with a lot of dts files in this folder. >>> If make sense to permit only boards with something new or just enable >>> reference boards to go in. >> >> >> I am interested in this, as we seem to be repeating the quantity >> issue with the board file of having many .dts sources in the kernel. > > The problem was not so much having board files in the kernel. It was > how to scale support for boards and SoCs with each family structuring > things their own, different way. > > IIRC, the ARM tree was at ~400 boards at the start of DT conversion. > Now we're at ~1100 boards for arm/arm64. Plus we still have 264 that > aren't converted to DT. > >> I'm not sure how to deal with this, on one hand only having the >> reference (and possibly popular) boards is going to keep the size >> down. On the other hand out of tree .dts files are going to be >> difficult to find (or vanish with the vendor). > > Why do we care? What problem is that causing? In fact, for many platforms that would be a good place to get to if the firmware is providing the .dtb. Plus the DT data formats are so simple that it is not difficult to get a DTB back into a DTS. > >> It seems we are still no closer to having a DT repository outside >> the kernel. > > In relationship to the above what problem would that solve? We've got > all the platform maintainers and arm-soc maintainers to handle dts > files. Mark and myself along with subsystem maintainers reviewing and > applying device bindings. If you move all that to a separate > repository, then you have me because no one else has volunteered. I'm > pretty sure no one wants me as the single point of failure. Yes. When it comes to the bindings, and schema files when we have them, they should be maintained with the tools. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 23:45 ` Frank Rowand 0 siblings, 0 replies; 126+ messages in thread From: Frank Rowand @ 2017-10-17 23:45 UTC (permalink / raw) To: Grant Likely, Rob Herring Cc: devicetree, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson On 10/17/17 06:38, Grant Likely wrote: > On Mon, Oct 16, 2017 at 8:45 PM, Rob Herring <robh@kernel.org> wrote: >> On Mon, Oct 16, 2017 at 11:40 AM, Ben Dooks <ben.dooks@codethink.co.uk> wrote: >>> On 16/10/17 06:36, Michal Simek wrote: >>>> >>>> Hi, >>>> >>>> On 9.10.2017 22:39, Grant Likely wrote: >>>>> >>>>> Kernel Summit is now just over 2 weeks away and it is time to pull >>>>> together the schedule for the Devicetree workshop. Originally I >>>>> planned on just an afternoon, but I've got the room for the whole day, >>>>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>>>> be used for hacking. >>>>> >>>>> Date: 26 Oct 2017 >>>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>>>> Location: Athens room - Hilton Prague >>>>> >>>>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>>>> registration to include the DT Workshop (log in to access and modify >>>>> your registration): >>>>> >>>>> >>>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>>>> >>>>> Here is my current list of topics in no particular order, including >>>>> the topic moderator: >>>>> >>>>> Runtime memory consumption (Rob Herring) >>>>> Overlay maintenance plan (TBC) >>>>> Stable ABI for devicetree (TBC) >>>>> DT YAML encoding (Pantelis Antoniou) >>>>> DT Schema format - option 1 (Pantelis Antoniou) >>>>> DT Schema format - option 2 (Grant Likely) >>>>> Sharing Generic bindings (TBC) >>>>> devicetree.org update (Grant) >>>>> >>>>> Reply to this email if you want to propose another topic. >>>>> >>>>> Reply privately if there is a particular topic you want to attend but >>>>> you are unable to be there in the morning or afternoon. I'll put the >>>>> actual agenda together a week out from the event. >>>> >>>> >>>> I would like to talk how to add support for AArch32 based on arm64 dts >>>> file. >>>> >>>> And next topic is discuss criteria for adding new DTS board files to >>>> kernel for supporting custom boards especially for arm32 which can end >>>> up with a lot of dts files in this folder. >>>> If make sense to permit only boards with something new or just enable >>>> reference boards to go in. >>> >>> >>> I am interested in this, as we seem to be repeating the quantity >>> issue with the board file of having many .dts sources in the kernel. >> >> The problem was not so much having board files in the kernel. It was >> how to scale support for boards and SoCs with each family structuring >> things their own, different way. >> >> IIRC, the ARM tree was at ~400 boards at the start of DT conversion. >> Now we're at ~1100 boards for arm/arm64. Plus we still have 264 that >> aren't converted to DT. >> >>> I'm not sure how to deal with this, on one hand only having the >>> reference (and possibly popular) boards is going to keep the size >>> down. On the other hand out of tree .dts files are going to be >>> difficult to find (or vanish with the vendor). >> >> Why do we care? What problem is that causing? > > In fact, for many platforms that would be a good place to get to if > the firmware is providing the .dtb. Plus the DT data formats are so > simple that it is not difficult to get a DTB back into a DTS. No, it _is_ difficult to convert a DTB to a useful DTS. The DTB might not be easily extracted from a vendor provided boot image. You do not get a full DTS back from a decompiled DTB. Phandle references are integers instead of strings. Labels are missing. >> >>> It seems we are still no closer to having a DT repository outside >>> the kernel. >> >> In relationship to the above what problem would that solve? We've got >> all the platform maintainers and arm-soc maintainers to handle dts >> files. Mark and myself along with subsystem maintainers reviewing and >> applying device bindings. If you move all that to a separate >> repository, then you have me because no one else has volunteered. I'm >> pretty sure no one wants me as the single point of failure. > > Yes. When it comes to the bindings, and schema files when we have > them, they should be maintained with the tools. Totally disagree. I'm sure we'll have the same discussion we have had at various ELC and ELCE events, where a handful of people want to move the DTS files out of the kernel source tree, and the vast majority of the room is opposed to that. > > g. > . > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 23:45 ` Frank Rowand 0 siblings, 0 replies; 126+ messages in thread From: Frank Rowand @ 2017-10-17 23:45 UTC (permalink / raw) To: Grant Likely, Rob Herring Cc: Ben Dooks, Michal Simek, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring On 10/17/17 06:38, Grant Likely wrote: > On Mon, Oct 16, 2017 at 8:45 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: >> On Mon, Oct 16, 2017 at 11:40 AM, Ben Dooks <ben.dooks-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org> wrote: >>> On 16/10/17 06:36, Michal Simek wrote: >>>> >>>> Hi, >>>> >>>> On 9.10.2017 22:39, Grant Likely wrote: >>>>> >>>>> Kernel Summit is now just over 2 weeks away and it is time to pull >>>>> together the schedule for the Devicetree workshop. Originally I >>>>> planned on just an afternoon, but I've got the room for the whole day, >>>>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>>>> be used for hacking. >>>>> >>>>> Date: 26 Oct 2017 >>>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>>>> Location: Athens room - Hilton Prague >>>>> >>>>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>>>> registration to include the DT Workshop (log in to access and modify >>>>> your registration): >>>>> >>>>> >>>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>>>> >>>>> Here is my current list of topics in no particular order, including >>>>> the topic moderator: >>>>> >>>>> Runtime memory consumption (Rob Herring) >>>>> Overlay maintenance plan (TBC) >>>>> Stable ABI for devicetree (TBC) >>>>> DT YAML encoding (Pantelis Antoniou) >>>>> DT Schema format - option 1 (Pantelis Antoniou) >>>>> DT Schema format - option 2 (Grant Likely) >>>>> Sharing Generic bindings (TBC) >>>>> devicetree.org update (Grant) >>>>> >>>>> Reply to this email if you want to propose another topic. >>>>> >>>>> Reply privately if there is a particular topic you want to attend but >>>>> you are unable to be there in the morning or afternoon. I'll put the >>>>> actual agenda together a week out from the event. >>>> >>>> >>>> I would like to talk how to add support for AArch32 based on arm64 dts >>>> file. >>>> >>>> And next topic is discuss criteria for adding new DTS board files to >>>> kernel for supporting custom boards especially for arm32 which can end >>>> up with a lot of dts files in this folder. >>>> If make sense to permit only boards with something new or just enable >>>> reference boards to go in. >>> >>> >>> I am interested in this, as we seem to be repeating the quantity >>> issue with the board file of having many .dts sources in the kernel. >> >> The problem was not so much having board files in the kernel. It was >> how to scale support for boards and SoCs with each family structuring >> things their own, different way. >> >> IIRC, the ARM tree was at ~400 boards at the start of DT conversion. >> Now we're at ~1100 boards for arm/arm64. Plus we still have 264 that >> aren't converted to DT. >> >>> I'm not sure how to deal with this, on one hand only having the >>> reference (and possibly popular) boards is going to keep the size >>> down. On the other hand out of tree .dts files are going to be >>> difficult to find (or vanish with the vendor). >> >> Why do we care? What problem is that causing? > > In fact, for many platforms that would be a good place to get to if > the firmware is providing the .dtb. Plus the DT data formats are so > simple that it is not difficult to get a DTB back into a DTS. No, it _is_ difficult to convert a DTB to a useful DTS. The DTB might not be easily extracted from a vendor provided boot image. You do not get a full DTS back from a decompiled DTB. Phandle references are integers instead of strings. Labels are missing. >> >>> It seems we are still no closer to having a DT repository outside >>> the kernel. >> >> In relationship to the above what problem would that solve? We've got >> all the platform maintainers and arm-soc maintainers to handle dts >> files. Mark and myself along with subsystem maintainers reviewing and >> applying device bindings. If you move all that to a separate >> repository, then you have me because no one else has volunteered. I'm >> pretty sure no one wants me as the single point of failure. > > Yes. When it comes to the bindings, and schema files when we have > them, they should be maintained with the tools. Totally disagree. I'm sure we'll have the same discussion we have had at various ELC and ELCE events, where a handful of people want to move the DTS files out of the kernel source tree, and the vast majority of the room is opposed to that. > > g. > . > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 13:32 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-17 13:32 UTC (permalink / raw) To: Michal Simek Cc: devicetree, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson On Mon, Oct 16, 2017 at 6:36 AM, Michal Simek <monstr@monstr.eu> wrote: > Hi, > > On 9.10.2017 22:39, Grant Likely wrote: >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. >> >> Reply privately if there is a particular topic you want to attend but >> you are unable to be there in the morning or afternoon. I'll put the >> actual agenda together a week out from the event. > > I would like to talk how to add support for AArch32 based on arm64 dts file. This sounds a lot like the duplicate descriptions topic Thomas proposed. I'll lump them into a single agenda item. > > And next topic is discuss criteria for adding new DTS board files to > kernel for supporting custom boards especially for arm32 which can end > up with a lot of dts files in this folder. > If make sense to permit only boards with something new or just enable > reference boards to go in. Added. > > Thanks, > Michal > > -- > Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 > w: www.monstr.eu p: +42-0-721842854 > Maintainer of Linux kernel - Xilinx Microblaze > Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs > U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 13:32 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-17 13:32 UTC (permalink / raw) To: Michal Simek Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand On Mon, Oct 16, 2017 at 6:36 AM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote: > Hi, > > On 9.10.2017 22:39, Grant Likely wrote: >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. >> >> Reply privately if there is a particular topic you want to attend but >> you are unable to be there in the morning or afternoon. I'll put the >> actual agenda together a week out from the event. > > I would like to talk how to add support for AArch32 based on arm64 dts file. This sounds a lot like the duplicate descriptions topic Thomas proposed. I'll lump them into a single agenda item. > > And next topic is discuss criteria for adding new DTS board files to > kernel for supporting custom boards especially for arm32 which can end > up with a lot of dts files in this folder. > If make sense to permit only boards with something new or just enable > reference boards to go in. Added. > > Thanks, > Michal > > -- > Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 > w: www.monstr.eu p: +42-0-721842854 > Maintainer of Linux kernel - Xilinx Microblaze > Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs > U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 10:08 ` Thomas Petazzoni 0 siblings, 0 replies; 126+ messages in thread From: Thomas Petazzoni @ 2017-10-18 10:08 UTC (permalink / raw) To: Grant Likely Cc: devicetree, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, David Gibson, Lucas Stach Hello, On Tue, 17 Oct 2017 14:32:18 +0100, Grant Likely wrote: > > I would like to talk how to add support for AArch32 based on arm64 dts file. > > This sounds a lot like the duplicate descriptions topic Thomas > proposed. I'll lump them into a single agenda item. I think it's a totally different problem, with most likely different solutions. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 10:08 ` Thomas Petazzoni 0 siblings, 0 replies; 126+ messages in thread From: Thomas Petazzoni @ 2017-10-18 10:08 UTC (permalink / raw) To: Grant Likely Cc: Michal Simek, devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson Hello, On Tue, 17 Oct 2017 14:32:18 +0100, Grant Likely wrote: > > I would like to talk how to add support for AArch32 based on arm64 dts file. > > This sounds a lot like the duplicate descriptions topic Thomas > proposed. I'll lump them into a single agenda item. I think it's a totally different problem, with most likely different solutions. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-16 16:42 ` Ben Dooks 0 siblings, 0 replies; 126+ messages in thread From: Ben Dooks @ 2017-10-16 16:42 UTC (permalink / raw) To: Grant Likely, devicetree, devicetree-spec, ksummit-discuss, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand On 09/10/17 21:39, Grant Likely wrote: > Kernel Summit is now just over 2 weeks away and it is time to pull > together the schedule for the Devicetree workshop. Originally I > planned on just an afternoon, but I've got the room for the whole day, > so I've got a lot of flexibility on the schedule. Unscheduled time can > be used for hacking. > > Date: 26 Oct 2017 > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > Location: Athens room - Hilton Prague > > If you plan to attend, make sure you update your OSSunmitE/ELCE > registration to include the DT Workshop (log in to access and modify > your registration): > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > Here is my current list of topics in no particular order, including > the topic moderator: > > Runtime memory consumption (Rob Herring) > Overlay maintenance plan (TBC) > Stable ABI for devicetree (TBC) > DT YAML encoding (Pantelis Antoniou) > DT Schema format - option 1 (Pantelis Antoniou) > DT Schema format - option 2 (Grant Likely) > Sharing Generic bindings (TBC) > devicetree.org update (Grant) > > Reply to this email if you want to propose another topic. I'd like to see a "device-tree overview" comprising of at-least - where is dt at - where is dt going I am also interested in an "are we actually solving enough of the old board file problems" -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-16 16:42 ` Ben Dooks 0 siblings, 0 replies; 126+ messages in thread From: Ben Dooks @ 2017-10-16 16:42 UTC (permalink / raw) To: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand On 09/10/17 21:39, Grant Likely wrote: > Kernel Summit is now just over 2 weeks away and it is time to pull > together the schedule for the Devicetree workshop. Originally I > planned on just an afternoon, but I've got the room for the whole day, > so I've got a lot of flexibility on the schedule. Unscheduled time can > be used for hacking. > > Date: 26 Oct 2017 > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > Location: Athens room - Hilton Prague > > If you plan to attend, make sure you update your OSSunmitE/ELCE > registration to include the DT Workshop (log in to access and modify > your registration): > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > Here is my current list of topics in no particular order, including > the topic moderator: > > Runtime memory consumption (Rob Herring) > Overlay maintenance plan (TBC) > Stable ABI for devicetree (TBC) > DT YAML encoding (Pantelis Antoniou) > DT Schema format - option 1 (Pantelis Antoniou) > DT Schema format - option 2 (Grant Likely) > Sharing Generic bindings (TBC) > devicetree.org update (Grant) > > Reply to this email if you want to propose another topic. I'd like to see a "device-tree overview" comprising of at-least - where is dt at - where is dt going I am also interested in an "are we actually solving enough of the old board file problems" -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 13:34 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-17 13:34 UTC (permalink / raw) To: Ben Dooks Cc: devicetree, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson On Mon, Oct 16, 2017 at 5:42 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote: > On 09/10/17 21:39, Grant Likely wrote: >> >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. > > > I'd like to see a "device-tree overview" comprising of at-least > > - where is dt at > - where is dt going > > > I am also interested in an > "are we actually solving enough of the old board file problems" Added all three under a "DT health check" topic. Hopefully it won't morph into "Complain about DT". :-) g. ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 13:34 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-17 13:34 UTC (permalink / raw) To: Ben Dooks Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand On Mon, Oct 16, 2017 at 5:42 PM, Ben Dooks <ben.dooks-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org> wrote: > On 09/10/17 21:39, Grant Likely wrote: >> >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. > > > I'd like to see a "device-tree overview" comprising of at-least > > - where is dt at > - where is dt going > > > I am also interested in an > "are we actually solving enough of the old board file problems" Added all three under a "DT health check" topic. Hopefully it won't morph into "Complain about DT". :-) g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 9:48 ` Boris Brezillon 0 siblings, 0 replies; 126+ messages in thread From: Boris Brezillon @ 2017-10-17 9:48 UTC (permalink / raw) To: Grant Likely Cc: devicetree, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson Hello Grant, On Mon, 9 Oct 2017 21:39:51 +0100 Grant Likely <grant.likely@secretlab.ca> wrote: > Kernel Summit is now just over 2 weeks away and it is time to pull > together the schedule for the Devicetree workshop. Originally I > planned on just an afternoon, but I've got the room for the whole day, > so I've got a lot of flexibility on the schedule. Unscheduled time can > be used for hacking. > > Date: 26 Oct 2017 > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > Location: Athens room - Hilton Prague > > If you plan to attend, make sure you update your OSSunmitE/ELCE > registration to include the DT Workshop (log in to access and modify > your registration): > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > Here is my current list of topics in no particular order, including > the topic moderator: > > Runtime memory consumption (Rob Herring) > Overlay maintenance plan (TBC) > Stable ABI for devicetree (TBC) > DT YAML encoding (Pantelis Antoniou) > DT Schema format - option 1 (Pantelis Antoniou) > DT Schema format - option 2 (Grant Likely) > Sharing Generic bindings (TBC) > devicetree.org update (Grant) > > Reply to this email if you want to propose another topic. Not sure yet if I'll attend the DT workshop or not, but I thought I could ask my question here because it might be of interest to someone else who is attending. What happens when the DT bindings is not documented in Linux but in an another project because this project was the first to use it. I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm not sure what's the policy when this happens. Should we add a file under Documentation/devicetree/bindings/... that points to the external doc file, should we duplicate the DT bindings doc in Linux, or should we just leave the bindings undocumented in the kernel tree? Regards, Boris ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 9:48 ` Boris Brezillon 0 siblings, 0 replies; 126+ messages in thread From: Boris Brezillon @ 2017-10-17 9:48 UTC (permalink / raw) To: Grant Likely Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand Hello Grant, On Mon, 9 Oct 2017 21:39:51 +0100 Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > Kernel Summit is now just over 2 weeks away and it is time to pull > together the schedule for the Devicetree workshop. Originally I > planned on just an afternoon, but I've got the room for the whole day, > so I've got a lot of flexibility on the schedule. Unscheduled time can > be used for hacking. > > Date: 26 Oct 2017 > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > Location: Athens room - Hilton Prague > > If you plan to attend, make sure you update your OSSunmitE/ELCE > registration to include the DT Workshop (log in to access and modify > your registration): > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > Here is my current list of topics in no particular order, including > the topic moderator: > > Runtime memory consumption (Rob Herring) > Overlay maintenance plan (TBC) > Stable ABI for devicetree (TBC) > DT YAML encoding (Pantelis Antoniou) > DT Schema format - option 1 (Pantelis Antoniou) > DT Schema format - option 2 (Grant Likely) > Sharing Generic bindings (TBC) > devicetree.org update (Grant) > > Reply to this email if you want to propose another topic. Not sure yet if I'll attend the DT workshop or not, but I thought I could ask my question here because it might be of interest to someone else who is attending. What happens when the DT bindings is not documented in Linux but in an another project because this project was the first to use it. I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm not sure what's the policy when this happens. Should we add a file under Documentation/devicetree/bindings/... that points to the external doc file, should we duplicate the DT bindings doc in Linux, or should we just leave the bindings undocumented in the kernel tree? Regards, Boris ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) 2017-10-17 9:48 ` Boris Brezillon @ 2017-10-17 13:21 ` Tom Rini -1 siblings, 0 replies; 126+ messages in thread From: Tom Rini @ 2017-10-17 13:21 UTC (permalink / raw) To: Boris Brezillon Cc: devicetree, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson On Tue, Oct 17, 2017 at 11:48:23AM +0200, Boris Brezillon wrote: > Hello Grant, > > On Mon, 9 Oct 2017 21:39:51 +0100 > Grant Likely <grant.likely@secretlab.ca> wrote: > > > Kernel Summit is now just over 2 weeks away and it is time to pull > > together the schedule for the Devicetree workshop. Originally I > > planned on just an afternoon, but I've got the room for the whole day, > > so I've got a lot of flexibility on the schedule. Unscheduled time can > > be used for hacking. > > > > Date: 26 Oct 2017 > > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > > Location: Athens room - Hilton Prague > > > > If you plan to attend, make sure you update your OSSunmitE/ELCE > > registration to include the DT Workshop (log in to access and modify > > your registration): > > > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > > > Here is my current list of topics in no particular order, including > > the topic moderator: > > > > Runtime memory consumption (Rob Herring) > > Overlay maintenance plan (TBC) > > Stable ABI for devicetree (TBC) > > DT YAML encoding (Pantelis Antoniou) > > DT Schema format - option 1 (Pantelis Antoniou) > > DT Schema format - option 2 (Grant Likely) > > Sharing Generic bindings (TBC) > > devicetree.org update (Grant) > > > > Reply to this email if you want to propose another topic. > > Not sure yet if I'll attend the DT workshop or not, but I thought I > could ask my question here because it might be of interest to someone > else who is attending. > > What happens when the DT bindings is not documented in Linux but in an > another project because this project was the first to use it. > > I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm > not sure what's the policy when this happens. Should we add a file > under Documentation/devicetree/bindings/... that points to the external > doc file, should we duplicate the DT bindings doc in Linux, or should > we just leave the bindings undocumented in the kernel tree? I really hope (and have tried pushing via some other channels) that given Android's embrace of devicetree for Android 8 they will have people present as there's going to be issues like the above cropping up now. -- Tom ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 13:21 ` Tom Rini 0 siblings, 0 replies; 126+ messages in thread From: Tom Rini @ 2017-10-17 13:21 UTC (permalink / raw) To: Boris Brezillon Cc: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand On Tue, Oct 17, 2017 at 11:48:23AM +0200, Boris Brezillon wrote: > Hello Grant, > > On Mon, 9 Oct 2017 21:39:51 +0100 > Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > > > Kernel Summit is now just over 2 weeks away and it is time to pull > > together the schedule for the Devicetree workshop. Originally I > > planned on just an afternoon, but I've got the room for the whole day, > > so I've got a lot of flexibility on the schedule. Unscheduled time can > > be used for hacking. > > > > Date: 26 Oct 2017 > > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > > Location: Athens room - Hilton Prague > > > > If you plan to attend, make sure you update your OSSunmitE/ELCE > > registration to include the DT Workshop (log in to access and modify > > your registration): > > > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > > > Here is my current list of topics in no particular order, including > > the topic moderator: > > > > Runtime memory consumption (Rob Herring) > > Overlay maintenance plan (TBC) > > Stable ABI for devicetree (TBC) > > DT YAML encoding (Pantelis Antoniou) > > DT Schema format - option 1 (Pantelis Antoniou) > > DT Schema format - option 2 (Grant Likely) > > Sharing Generic bindings (TBC) > > devicetree.org update (Grant) > > > > Reply to this email if you want to propose another topic. > > Not sure yet if I'll attend the DT workshop or not, but I thought I > could ask my question here because it might be of interest to someone > else who is attending. > > What happens when the DT bindings is not documented in Linux but in an > another project because this project was the first to use it. > > I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm > not sure what's the policy when this happens. Should we add a file > under Documentation/devicetree/bindings/... that points to the external > doc file, should we duplicate the DT bindings doc in Linux, or should > we just leave the bindings undocumented in the kernel tree? I really hope (and have tried pushing via some other channels) that given Android's embrace of devicetree for Android 8 they will have people present as there's going to be issues like the above cropping up now. -- Tom -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) 2017-10-17 9:48 ` Boris Brezillon @ 2017-10-17 13:48 ` Grant Likely -1 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-17 13:48 UTC (permalink / raw) To: Boris Brezillon Cc: devicetree, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson On Tue, Oct 17, 2017 at 10:48 AM, Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > Hello Grant, > > On Mon, 9 Oct 2017 21:39:51 +0100 > Grant Likely <grant.likely@secretlab.ca> wrote: > >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. > > Not sure yet if I'll attend the DT workshop or not, but I thought I > could ask my question here because it might be of interest to someone > else who is attending. > > What happens when the DT bindings is not documented in Linux but in an > another project because this project was the first to use it. > > I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm > not sure what's the policy when this happens. Should we add a file > under Documentation/devicetree/bindings/... that points to the external > doc file, should we duplicate the DT bindings doc in Linux, or should > we just leave the bindings undocumented in the kernel tree? I'm going to add this as a topic. I've got my own opinion, but it would be better to discuss in the room because it affects maintainers. g. > > Regards, > > Boris ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 13:48 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-17 13:48 UTC (permalink / raw) To: Boris Brezillon Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand On Tue, Oct 17, 2017 at 10:48 AM, Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote: > Hello Grant, > > On Mon, 9 Oct 2017 21:39:51 +0100 > Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. > > Not sure yet if I'll attend the DT workshop or not, but I thought I > could ask my question here because it might be of interest to someone > else who is attending. > > What happens when the DT bindings is not documented in Linux but in an > another project because this project was the first to use it. > > I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm > not sure what's the policy when this happens. Should we add a file > under Documentation/devicetree/bindings/... that points to the external > doc file, should we duplicate the DT bindings doc in Linux, or should > we just leave the bindings undocumented in the kernel tree? I'm going to add this as a topic. I've got my own opinion, but it would be better to discuss in the room because it affects maintainers. g. > > Regards, > > Boris ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 16:21 ` Ian Lepore 0 siblings, 0 replies; 126+ messages in thread From: Ian Lepore @ 2017-10-17 16:21 UTC (permalink / raw) To: Grant Likely; +Cc: devicetree-spec, devicetree, ksummit-discuss On Tue, 2017-10-17 at 14:48 +0100, Grant Likely wrote: > On Tue, Oct 17, 2017 at 10:48 AM, Boris Brezillon > <boris.brezillon@free-electrons.com> wrote: > > > > Hello Grant, > > > > On Mon, 9 Oct 2017 21:39:51 +0100 > > Grant Likely <grant.likely@secretlab.ca> wrote: > > > > > > > > Kernel Summit is now just over 2 weeks away and it is time to pull > > > together the schedule for the Devicetree workshop. Originally I > > > planned on just an afternoon, but I've got the room for the whole day, > > > so I've got a lot of flexibility on the schedule. Unscheduled time can > > > be used for hacking. > > > > > > Date: 26 Oct 2017 > > > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > > > Location: Athens room - Hilton Prague > > > > > > If you plan to attend, make sure you update your OSSunmitE/ELCE > > > registration to include the DT Workshop (log in to access and modify > > > your registration): > > > > > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > > > > > Here is my current list of topics in no particular order, including > > > the topic moderator: > > > > > > Runtime memory consumption (Rob Herring) > > > Overlay maintenance plan (TBC) > > > Stable ABI for devicetree (TBC) > > > DT YAML encoding (Pantelis Antoniou) > > > DT Schema format - option 1 (Pantelis Antoniou) > > > DT Schema format - option 2 (Grant Likely) > > > Sharing Generic bindings (TBC) > > > devicetree.org update (Grant) > > > > > > Reply to this email if you want to propose another topic. > > Not sure yet if I'll attend the DT workshop or not, but I thought I > > could ask my question here because it might be of interest to someone > > else who is attending. > > > > What happens when the DT bindings is not documented in Linux but in an > > another project because this project was the first to use it. > > > > I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm > > not sure what's the policy when this happens. Should we add a file > > under Documentation/devicetree/bindings/... that points to the external > > doc file, should we duplicate the DT bindings doc in Linux, or should > > we just leave the bindings undocumented in the kernel tree? > I'm going to add this as a topic. I've got my own opinion, but it > would be better to discuss in the room because it affects maintainers. > > g. I've run into the same thing in FreeBSD. We use bindings and dts files, exacted periodically from the linux tree and imported into ours, for all modern arm boards/systems. Several times I've created drivers for small things like i2c RTC chips that aren't supported currently by linux, and it's not clear to me that it's even possible to submit bindings and dts for them back upstream without also submitting a linux driver that uses them (which of course I'm not in a position to do). -- Ian ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 16:21 ` Ian Lepore 0 siblings, 0 replies; 126+ messages in thread From: Ian Lepore @ 2017-10-17 16:21 UTC (permalink / raw) To: Grant Likely Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I On Tue, 2017-10-17 at 14:48 +0100, Grant Likely wrote: > On Tue, Oct 17, 2017 at 10:48 AM, Boris Brezillon > <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote: > > > > Hello Grant, > > > > On Mon, 9 Oct 2017 21:39:51 +0100 > > Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > > > > > > > > Kernel Summit is now just over 2 weeks away and it is time to pull > > > together the schedule for the Devicetree workshop. Originally I > > > planned on just an afternoon, but I've got the room for the whole day, > > > so I've got a lot of flexibility on the schedule. Unscheduled time can > > > be used for hacking. > > > > > > Date: 26 Oct 2017 > > > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > > > Location: Athens room - Hilton Prague > > > > > > If you plan to attend, make sure you update your OSSunmitE/ELCE > > > registration to include the DT Workshop (log in to access and modify > > > your registration): > > > > > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > > > > > Here is my current list of topics in no particular order, including > > > the topic moderator: > > > > > > Runtime memory consumption (Rob Herring) > > > Overlay maintenance plan (TBC) > > > Stable ABI for devicetree (TBC) > > > DT YAML encoding (Pantelis Antoniou) > > > DT Schema format - option 1 (Pantelis Antoniou) > > > DT Schema format - option 2 (Grant Likely) > > > Sharing Generic bindings (TBC) > > > devicetree.org update (Grant) > > > > > > Reply to this email if you want to propose another topic. > > Not sure yet if I'll attend the DT workshop or not, but I thought I > > could ask my question here because it might be of interest to someone > > else who is attending. > > > > What happens when the DT bindings is not documented in Linux but in an > > another project because this project was the first to use it. > > > > I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm > > not sure what's the policy when this happens. Should we add a file > > under Documentation/devicetree/bindings/... that points to the external > > doc file, should we duplicate the DT bindings doc in Linux, or should > > we just leave the bindings undocumented in the kernel tree? > I'm going to add this as a topic. I've got my own opinion, but it > would be better to discuss in the room because it affects maintainers. > > g. I've run into the same thing in FreeBSD. We use bindings and dts files, exacted periodically from the linux tree and imported into ours, for all modern arm boards/systems. Several times I've created drivers for small things like i2c RTC chips that aren't supported currently by linux, and it's not clear to me that it's even possible to submit bindings and dts for them back upstream without also submitting a linux driver that uses them (which of course I'm not in a position to do). -- Ian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 17:02 ` Kumar Gala 0 siblings, 0 replies; 126+ messages in thread From: Kumar Gala @ 2017-10-17 17:02 UTC (permalink / raw) To: Ian Lepore; +Cc: devicetree, devicetree-spec, ksummit-discuss > On Oct 17, 2017, at 11:21 AM, Ian Lepore <ian@freebsd.org> wrote: > > On Tue, 2017-10-17 at 14:48 +0100, Grant Likely wrote: >> On Tue, Oct 17, 2017 at 10:48 AM, Boris Brezillon >> <boris.brezillon@free-electrons.com> wrote: >>> >>> Hello Grant, >>> >>> On Mon, 9 Oct 2017 21:39:51 +0100 >>> Grant Likely <grant.likely@secretlab.ca> wrote: >>> >>>> >>>> Kernel Summit is now just over 2 weeks away and it is time to pull >>>> together the schedule for the Devicetree workshop. Originally I >>>> planned on just an afternoon, but I've got the room for the whole day, >>>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>>> be used for hacking. >>>> >>>> Date: 26 Oct 2017 >>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>>> Location: Athens room - Hilton Prague >>>> >>>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>>> registration to include the DT Workshop (log in to access and modify >>>> your registration): >>>> >>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>>> >>>> Here is my current list of topics in no particular order, including >>>> the topic moderator: >>>> >>>> Runtime memory consumption (Rob Herring) >>>> Overlay maintenance plan (TBC) >>>> Stable ABI for devicetree (TBC) >>>> DT YAML encoding (Pantelis Antoniou) >>>> DT Schema format - option 1 (Pantelis Antoniou) >>>> DT Schema format - option 2 (Grant Likely) >>>> Sharing Generic bindings (TBC) >>>> devicetree.org update (Grant) >>>> >>>> Reply to this email if you want to propose another topic. >>> Not sure yet if I'll attend the DT workshop or not, but I thought I >>> could ask my question here because it might be of interest to someone >>> else who is attending. >>> >>> What happens when the DT bindings is not documented in Linux but in an >>> another project because this project was the first to use it. >>> >>> I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm >>> not sure what's the policy when this happens. Should we add a file >>> under Documentation/devicetree/bindings/... that points to the external >>> doc file, should we duplicate the DT bindings doc in Linux, or should >>> we just leave the bindings undocumented in the kernel tree? >> I'm going to add this as a topic. I've got my own opinion, but it >> would be better to discuss in the room because it affects maintainers. >> >> g. > > > I've run into the same thing in FreeBSD. We use bindings and dts > files, exacted periodically from the linux tree and imported into ours, > for all modern arm boards/systems. Several times I've created drivers > for small things like i2c RTC chips that aren't supported currently by > linux, and it's not clear to me that it's even possible to submit > bindings and dts for them back upstream without also submitting a linux > driver that uses them (which of course I'm not in a position to do). > > -- Ian I think this gets to separating bindings from .dts files. If we had a common place for bindings that are usable by all the various projects that utilize device tree that would help. Rob’s point about now having linux maintainers of subsystems doing binding reviews is a fair point, because we do need more eyes on bindings. So I think we need some middle ground here. I think this also gets to having bindings described in a structured way so they can be utilized for validation of dts files. We are doing a little of this in Zephyr since we are using a structured binding spec to generate code from .dts (since we don’t utilize a runtime dtb). - k ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 17:02 ` Kumar Gala 0 siblings, 0 replies; 126+ messages in thread From: Kumar Gala @ 2017-10-17 17:02 UTC (permalink / raw) To: Ian Lepore Cc: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I > On Oct 17, 2017, at 11:21 AM, Ian Lepore <ian-h+KGxgPPiopAfugRpC6u6w@public.gmane.org> wrote: > > On Tue, 2017-10-17 at 14:48 +0100, Grant Likely wrote: >> On Tue, Oct 17, 2017 at 10:48 AM, Boris Brezillon >> <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote: >>> >>> Hello Grant, >>> >>> On Mon, 9 Oct 2017 21:39:51 +0100 >>> Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: >>> >>>> >>>> Kernel Summit is now just over 2 weeks away and it is time to pull >>>> together the schedule for the Devicetree workshop. Originally I >>>> planned on just an afternoon, but I've got the room for the whole day, >>>> so I've got a lot of flexibility on the schedule. Unscheduled time can >>>> be used for hacking. >>>> >>>> Date: 26 Oct 2017 >>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >>>> Location: Athens room - Hilton Prague >>>> >>>> If you plan to attend, make sure you update your OSSunmitE/ELCE >>>> registration to include the DT Workshop (log in to access and modify >>>> your registration): >>>> >>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >>>> >>>> Here is my current list of topics in no particular order, including >>>> the topic moderator: >>>> >>>> Runtime memory consumption (Rob Herring) >>>> Overlay maintenance plan (TBC) >>>> Stable ABI for devicetree (TBC) >>>> DT YAML encoding (Pantelis Antoniou) >>>> DT Schema format - option 1 (Pantelis Antoniou) >>>> DT Schema format - option 2 (Grant Likely) >>>> Sharing Generic bindings (TBC) >>>> devicetree.org update (Grant) >>>> >>>> Reply to this email if you want to propose another topic. >>> Not sure yet if I'll attend the DT workshop or not, but I thought I >>> could ask my question here because it might be of interest to someone >>> else who is attending. >>> >>> What happens when the DT bindings is not documented in Linux but in an >>> another project because this project was the first to use it. >>> >>> I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm >>> not sure what's the policy when this happens. Should we add a file >>> under Documentation/devicetree/bindings/... that points to the external >>> doc file, should we duplicate the DT bindings doc in Linux, or should >>> we just leave the bindings undocumented in the kernel tree? >> I'm going to add this as a topic. I've got my own opinion, but it >> would be better to discuss in the room because it affects maintainers. >> >> g. > > > I've run into the same thing in FreeBSD. We use bindings and dts > files, exacted periodically from the linux tree and imported into ours, > for all modern arm boards/systems. Several times I've created drivers > for small things like i2c RTC chips that aren't supported currently by > linux, and it's not clear to me that it's even possible to submit > bindings and dts for them back upstream without also submitting a linux > driver that uses them (which of course I'm not in a position to do). > > -- Ian I think this gets to separating bindings from .dts files. If we had a common place for bindings that are usable by all the various projects that utilize device tree that would help. Rob’s point about now having linux maintainers of subsystems doing binding reviews is a fair point, because we do need more eyes on bindings. So I think we need some middle ground here. I think this also gets to having bindings described in a structured way so they can be utilized for validation of dts files. We are doing a little of this in Zephyr since we are using a structured binding spec to generate code from .dts (since we don’t utilize a runtime dtb). - k-- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 17:24 ` Geert Uytterhoeven 0 siblings, 0 replies; 126+ messages in thread From: Geert Uytterhoeven @ 2017-10-17 17:24 UTC (permalink / raw) To: Kumar Gala; +Cc: devicetree, devicetree-spec, ksummit-discuss, Ian Lepore Hi Kumar, On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala@linaro.org> wrote: > I think this also gets to having bindings described in a structured way so they can be utilized for validation of dts files. We are doing a little of this in Zephyr since we are using a structured binding spec to generate code from .dts (since we don’t utilize a runtime dtb). So you are basically generating board files from .dts? (closing the loop ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 17:24 ` Geert Uytterhoeven 0 siblings, 0 replies; 126+ messages in thread From: Geert Uytterhoeven @ 2017-10-17 17:24 UTC (permalink / raw) To: Kumar Gala Cc: Ian Lepore, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I Hi Kumar, On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > I think this also gets to having bindings described in a structured way so they can be utilized for validation of dts files. We are doing a little of this in Zephyr since we are using a structured binding spec to generate code from .dts (since we don’t utilize a runtime dtb). So you are basically generating board files from .dts? (closing the loop ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 17:24 ` Geert Uytterhoeven 0 siblings, 0 replies; 126+ messages in thread From: Geert Uytterhoeven @ 2017-10-17 17:24 UTC (permalink / raw) To: Kumar Gala Cc: Ian Lepore, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I Hi Kumar, On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > I think this also gets to having bindings described in a structured way so they can be utilized for validation of dts files. We are doing a little of this in Zephyr since we are using a structured binding spec to generate code from .dts (since we don’t utilize a runtime dtb). So you are basically generating board files from .dts? (closing the loop ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 19:03 ` Bird, Timothy 0 siblings, 0 replies; 126+ messages in thread From: Bird, Timothy @ 2017-10-17 19:03 UTC (permalink / raw) To: Geert Uytterhoeven, Kumar Gala Cc: devicetree-spec, devicetree, Ian Lepore, ksummit-discuss > -----Original Message----- > From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM > On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala@linaro.org> wrote: > > I think this also gets to having bindings described in a structured way so > they can be utilized for validation of dts files. We are doing a little of this in > Zephyr since we are using a structured binding spec to generate code from > .dts (since we don’t utilize a runtime dtb). > > So you are basically generating board files from .dts? > (closing the loop ;-) I think we ought to do this on Linux, as a size optimization. -- Tim P.S. I think I'll leave it ambiguous whether this was meant as a joke or not. :-) ^ permalink raw reply [flat|nested] 126+ messages in thread
* RE: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 19:03 ` Bird, Timothy 0 siblings, 0 replies; 126+ messages in thread From: Bird, Timothy @ 2017-10-17 19:03 UTC (permalink / raw) To: Geert Uytterhoeven, Kumar Gala Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Ian Lepore [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 848 bytes --] > -----Original Message----- > From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM > On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala@linaro.org> wrote: > > I think this also gets to having bindings described in a structured way so > they can be utilized for validation of dts files. We are doing a little of this in > Zephyr since we are using a structured binding spec to generate code from > .dts (since we donât utilize a runtime dtb). > > So you are basically generating board files from .dts? > (closing the loop ;-) I think we ought to do this on Linux, as a size optimization. -- Tim P.S. I think I'll leave it ambiguous whether this was meant as a joke or not. :-) N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·zøzÚÞz)í æèw*\x1fjg¬±¨\x1e¶Ý¢j.ïÛ°\½½MúgjÌæa×\x02' ©Þ¢¸\f¢·¦j:+v¨wèjØm¶ÿ¾\a«êçzZ+ùÝ¢j"ú!¶i ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 12:14 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-18 12:14 UTC (permalink / raw) To: Bird, Timothy Cc: devicetree, Kumar Gala, Ian Lepore, ksummit-discuss, devicetree-spec On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird@sony.com> wrote: >> -----Original Message----- >> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM >> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala@linaro.org> wrote: >> > I think this also gets to having bindings described in a structured way so >> they can be utilized for validation of dts files. We are doing a little of this in >> Zephyr since we are using a structured binding spec to generate code from >> .dts (since we don’t utilize a runtime dtb). >> >> So you are basically generating board files from .dts? >> (closing the loop ;-) > > I think we ought to do this on Linux, as a size optimization. > -- Tim > > P.S. I think I'll leave it ambiguous whether this was meant as a joke or not. :-) Talk to Nicolas Pitre and Rob Herring about this. They've already made a bunch of progress on reducing memory footprint. g. > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 12:14 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-18 12:14 UTC (permalink / raw) To: Bird, Timothy Cc: Geert Uytterhoeven, Kumar Gala, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, Ian Lepore, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird-7U/KSKJipcs@public.gmane.org> wrote: >> -----Original Message----- >> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM >> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >> > I think this also gets to having bindings described in a structured way so >> they can be utilized for validation of dts files. We are doing a little of this in >> Zephyr since we are using a structured binding spec to generate code from >> .dts (since we don’t utilize a runtime dtb). >> >> So you are basically generating board files from .dts? >> (closing the loop ;-) > > I think we ought to do this on Linux, as a size optimization. > -- Tim > > P.S. I think I'll leave it ambiguous whether this was meant as a joke or not. :-) Talk to Nicolas Pitre and Rob Herring about this. They've already made a bunch of progress on reducing memory footprint. g. > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 12:14 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-18 12:14 UTC (permalink / raw) To: Bird, Timothy Cc: Geert Uytterhoeven, Kumar Gala, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, Ian Lepore, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird-7U/KSKJipcs@public.gmane.org> wrote: >> -----Original Message----- >> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM >> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >> > I think this also gets to having bindings described in a structured way so >> they can be utilized for validation of dts files. We are doing a little of this in >> Zephyr since we are using a structured binding spec to generate code from >> .dts (since we don’t utilize a runtime dtb). >> >> So you are basically generating board files from .dts? >> (closing the loop ;-) > > I think we ought to do this on Linux, as a size optimization. > -- Tim > > P.S. I think I'll leave it ambiguous whether this was meant as a joke or not. :-) Talk to Nicolas Pitre and Rob Herring about this. They've already made a bunch of progress on reducing memory footprint. g. > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 12:59 ` Pantelis Antoniou 0 siblings, 0 replies; 126+ messages in thread From: Pantelis Antoniou @ 2017-10-18 12:59 UTC (permalink / raw) To: Grant Likely Cc: devicetree, Kumar Gala, ksummit-discuss, Ian Lepore, devicetree-spec, Bird, Timothy Hi Grant, > On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely@secretlab.ca> wrote: > > On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird@sony.com> wrote: >>> -----Original Message----- >>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM >>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala@linaro.org> wrote: >>>> I think this also gets to having bindings described in a structured way so >>> they can be utilized for validation of dts files. We are doing a little of this in >>> Zephyr since we are using a structured binding spec to generate code from >>> .dts (since we don’t utilize a runtime dtb). >>> >>> So you are basically generating board files from .dts? >>> (closing the loop ;-) >> >> I think we ought to do this on Linux, as a size optimization. >> -- Tim >> >> P.S. I think I'll leave it ambiguous whether this was meant as a joke or not. :-) > As crazy that sounds it is possible using the YAML bindings, i.e. C structure definitions and fill-up from DT automatically. Whether this is a good idea it’s another question :) > Talk to Nicolas Pitre and Rob Herring about this. They've already made > a bunch of progress on reducing memory footprint. > > g. > >> _______________________________________________ >> Ksummit-discuss mailing list >> Ksummit-discuss@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 12:59 ` Pantelis Antoniou 0 siblings, 0 replies; 126+ messages in thread From: Pantelis Antoniou @ 2017-10-18 12:59 UTC (permalink / raw) To: Grant Likely Cc: Bird, Timothy, Geert Uytterhoeven, Kumar Gala, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, Ian Lepore, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I Hi Grant, > On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > > On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird-7U/KSKJipcs@public.gmane.org> wrote: >>> -----Original Message----- >>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM >>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >>>> I think this also gets to having bindings described in a structured way so >>> they can be utilized for validation of dts files. We are doing a little of this in >>> Zephyr since we are using a structured binding spec to generate code from >>> .dts (since we don’t utilize a runtime dtb). >>> >>> So you are basically generating board files from .dts? >>> (closing the loop ;-) >> >> I think we ought to do this on Linux, as a size optimization. >> -- Tim >> >> P.S. I think I'll leave it ambiguous whether this was meant as a joke or not. :-) > As crazy that sounds it is possible using the YAML bindings, i.e. C structure definitions and fill-up from DT automatically. Whether this is a good idea it’s another question :) > Talk to Nicolas Pitre and Rob Herring about this. They've already made > a bunch of progress on reducing memory footprint. > > g. > >> _______________________________________________ >> Ksummit-discuss mailing list >> Ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org >> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 13:18 ` Alexandre Belloni 0 siblings, 0 replies; 126+ messages in thread From: Alexandre Belloni @ 2017-10-18 13:18 UTC (permalink / raw) To: Pantelis Antoniou Cc: devicetree, Kumar Gala, ksummit-discuss, Ian Lepore, devicetree-spec, Bird, Timothy On 18/10/2017 at 15:59:00 +0300, Pantelis Antoniou wrote: > Hi Grant, > > > On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely@secretlab.ca> wrote: > > > > On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird@sony.com> wrote: > >>> -----Original Message----- > >>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM > >>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala@linaro.org> wrote: > >>>> I think this also gets to having bindings described in a structured way so > >>> they can be utilized for validation of dts files. We are doing a little of this in > >>> Zephyr since we are using a structured binding spec to generate code from > >>> .dts (since we don’t utilize a runtime dtb). > >>> > >>> So you are basically generating board files from .dts? > >>> (closing the loop ;-) > >> > >> I think we ought to do this on Linux, as a size optimization. > >> -- Tim > >> > >> P.S. I think I'll leave it ambiguous whether this was meant as a joke or not. :-) > > > > As crazy that sounds it is possible using the YAML bindings, i.e. C structure definitions > and fill-up from DT automatically. Whether this is a good idea it’s another question :) > But that doesn't work with any driver parsing custom properties (using of_property_read_* and the likes). I would very much like to see what are the boot time improvements when doing that ;) -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 13:18 ` Alexandre Belloni 0 siblings, 0 replies; 126+ messages in thread From: Alexandre Belloni @ 2017-10-18 13:18 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Ian Lepore, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Bird, Timothy On 18/10/2017 at 15:59:00 +0300, Pantelis Antoniou wrote: > Hi Grant, > > > On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > > > > On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird-7U/KSKJipcs@public.gmane.org> wrote: > >>> -----Original Message----- > >>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM > >>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > >>>> I think this also gets to having bindings described in a structured way so > >>> they can be utilized for validation of dts files. We are doing a little of this in > >>> Zephyr since we are using a structured binding spec to generate code from > >>> .dts (since we don’t utilize a runtime dtb). > >>> > >>> So you are basically generating board files from .dts? > >>> (closing the loop ;-) > >> > >> I think we ought to do this on Linux, as a size optimization. > >> -- Tim > >> > >> P.S. I think I'll leave it ambiguous whether this was meant as a joke or not. :-) > > > > As crazy that sounds it is possible using the YAML bindings, i.e. C structure definitions > and fill-up from DT automatically. Whether this is a good idea it’s another question :) > But that doesn't work with any driver parsing custom properties (using of_property_read_* and the likes). I would very much like to see what are the boot time improvements when doing that ;) -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 13:21 ` Geert Uytterhoeven 0 siblings, 0 replies; 126+ messages in thread From: Geert Uytterhoeven @ 2017-10-18 13:21 UTC (permalink / raw) To: Alexandre Belloni Cc: devicetree, Kumar Gala, ksummit-discuss, Ian Lepore, devicetree-spec, Bird, Timothy, Pantelis Antoniou Hi Alexandre, On Wed, Oct 18, 2017 at 3:18 PM, Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote: > On 18/10/2017 at 15:59:00 +0300, Pantelis Antoniou wrote: >> > On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely@secretlab.ca> wrote: >> > On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird@sony.com> wrote: >> >>> -----Original Message----- >> >>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM >> >>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala@linaro.org> wrote: >> >>>> I think this also gets to having bindings described in a structured way so >> >>> they can be utilized for validation of dts files. We are doing a little of this in >> >>> Zephyr since we are using a structured binding spec to generate code from >> >>> .dts (since we don’t utilize a runtime dtb). >> >>> >> >>> So you are basically generating board files from .dts? >> >>> (closing the loop ;-) >> >> >> >> I think we ought to do this on Linux, as a size optimization. >> >> -- Tim >> >> >> >> P.S. I think I'll leave it ambiguous whether this was meant as a joke or not. :-) >> >> As crazy that sounds it is possible using the YAML bindings, i.e. C structure definitions >> and fill-up from DT automatically. Whether this is a good idea it’s another question :) > > But that doesn't work with any driver parsing custom properties (using > of_property_read_* and the likes). I would very much like to see what > are the boot time improvements when doing that ;) Unless you override of_property_read_*() to work on the dense C structures instead? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 13:21 ` Geert Uytterhoeven 0 siblings, 0 replies; 126+ messages in thread From: Geert Uytterhoeven @ 2017-10-18 13:21 UTC (permalink / raw) To: Alexandre Belloni Cc: Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Ian Lepore, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Bird, Timothy Hi Alexandre, On Wed, Oct 18, 2017 at 3:18 PM, Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote: > On 18/10/2017 at 15:59:00 +0300, Pantelis Antoniou wrote: >> > On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: >> > On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird-7U/KSKJipcs@public.gmane.org> wrote: >> >>> -----Original Message----- >> >>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM >> >>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >> >>>> I think this also gets to having bindings described in a structured way so >> >>> they can be utilized for validation of dts files. We are doing a little of this in >> >>> Zephyr since we are using a structured binding spec to generate code from >> >>> .dts (since we don’t utilize a runtime dtb). >> >>> >> >>> So you are basically generating board files from .dts? >> >>> (closing the loop ;-) >> >> >> >> I think we ought to do this on Linux, as a size optimization. >> >> -- Tim >> >> >> >> P.S. I think I'll leave it ambiguous whether this was meant as a joke or not. :-) >> >> As crazy that sounds it is possible using the YAML bindings, i.e. C structure definitions >> and fill-up from DT automatically. Whether this is a good idea it’s another question :) > > But that doesn't work with any driver parsing custom properties (using > of_property_read_* and the likes). I would very much like to see what > are the boot time improvements when doing that ;) Unless you override of_property_read_*() to work on the dense C structures instead? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 17:41 ` Bird, Timothy 0 siblings, 0 replies; 126+ messages in thread From: Bird, Timothy @ 2017-10-18 17:41 UTC (permalink / raw) To: Geert Uytterhoeven, Alexandre Belloni Cc: devicetree, Kumar Gala, ksummit-discuss, Ian Lepore, devicetree-spec, Pantelis Antoniou > -----Original Message----- > From Geert Uytterhoeven on Wednesday, October 18, 2017 6:22 AM > On Wed, Oct 18, 2017 at 3:18 PM, Alexandre Belloni > <alexandre.belloni@free-electrons.com> wrote: > > On 18/10/2017 at 15:59:00 +0300, Pantelis Antoniou wrote: > >> > On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely@secretlab.ca> > wrote: > >> > On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird@sony.com> > wrote: > >> >>> -----Original Message----- > >> >>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM > >> >>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala > <kumar.gala@linaro.org> wrote: > >> >>>> I think this also gets to having bindings described in a structured way > so > >> >>> they can be utilized for validation of dts files. We are doing a little of > this in > >> >>> Zephyr since we are using a structured binding spec to generate code > from > >> >>> .dts (since we don’t utilize a runtime dtb). > >> >>> > >> >>> So you are basically generating board files from .dts? > >> >>> (closing the loop ;-) > >> >> > >> >> I think we ought to do this on Linux, as a size optimization. > >> >> -- Tim > >> >> > >> >> P.S. I think I'll leave it ambiguous whether this was meant as a joke or > not. :-) > >> > >> As crazy that sounds it is possible using the YAML bindings, i.e. C structure > definitions > >> and fill-up from DT automatically. Whether this is a good idea it’s another > question :) > > > > But that doesn't work with any driver parsing custom properties (using > > of_property_read_* and the likes). I would very much like to see what > > are the boot time improvements when doing that ;) > > Unless you override of_property_read_*() to work on the dense C > structures instead? Or turn the property reads into macros that then turn into constant declarations inline in the code. No need stop at dense C structures. Of course you lose all configuration flexibility at runtime. But then that's the kind of trade-off one often makes with embedded software, isn't it? -- Tim ^ permalink raw reply [flat|nested] 126+ messages in thread
* RE: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 17:41 ` Bird, Timothy 0 siblings, 0 replies; 126+ messages in thread From: Bird, Timothy @ 2017-10-18 17:41 UTC (permalink / raw) To: Geert Uytterhoeven, Alexandre Belloni Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Ian Lepore, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2216 bytes --] > -----Original Message----- > From Geert Uytterhoeven on Wednesday, October 18, 2017 6:22 AM > On Wed, Oct 18, 2017 at 3:18 PM, Alexandre Belloni > <alexandre.belloni@free-electrons.com> wrote: > > On 18/10/2017 at 15:59:00 +0300, Pantelis Antoniou wrote: > >> > On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely@secretlab.ca> > wrote: > >> > On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird@sony.com> > wrote: > >> >>> -----Original Message----- > >> >>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM > >> >>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala > <kumar.gala@linaro.org> wrote: > >> >>>> I think this also gets to having bindings described in a structured way > so > >> >>> they can be utilized for validation of dts files. We are doing a little of > this in > >> >>> Zephyr since we are using a structured binding spec to generate code > from > >> >>> .dts (since we donât utilize a runtime dtb). > >> >>> > >> >>> So you are basically generating board files from .dts? > >> >>> (closing the loop ;-) > >> >> > >> >> I think we ought to do this on Linux, as a size optimization. > >> >> -- Tim > >> >> > >> >> P.S. I think I'll leave it ambiguous whether this was meant as a joke or > not. :-) > >> > >> As crazy that sounds it is possible using the YAML bindings, i.e. C structure > definitions > >> and fill-up from DT automatically. Whether this is a good idea itâs another > question :) > > > > But that doesn't work with any driver parsing custom properties (using > > of_property_read_* and the likes). I would very much like to see what > > are the boot time improvements when doing that ;) > > Unless you override of_property_read_*() to work on the dense C > structures instead? Or turn the property reads into macros that then turn into constant declarations inline in the code. No need stop at dense C structures. Of course you lose all configuration flexibility at runtime. But then that's the kind of trade-off one often makes with embedded software, isn't it? -- Tim N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·zøzÚÞz)í æèw*\x1fjg¬±¨\x1e¶Ý¢j.ïÛ°\½½MúgjÌæa×\x02' ©Þ¢¸\f¢·¦j:+v¨wèjØm¶ÿ¾\a«êçzZ+ùÝ¢j"ú!¶i ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 18:00 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-18 18:00 UTC (permalink / raw) To: Bird, Timothy Cc: devicetree, Kumar Gala, ksummit-discuss, Ian Lepore, devicetree-spec, Pantelis Antoniou On Wed, Oct 18, 2017 at 12:41 PM, Bird, Timothy <Tim.Bird@sony.com> wrote: > > >> -----Original Message----- >> From Geert Uytterhoeven on Wednesday, October 18, 2017 6:22 AM >> On Wed, Oct 18, 2017 at 3:18 PM, Alexandre Belloni >> <alexandre.belloni@free-electrons.com> wrote: >> > On 18/10/2017 at 15:59:00 +0300, Pantelis Antoniou wrote: >> >> > On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely@secretlab.ca> >> wrote: >> >> > On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird@sony.com> >> wrote: >> >> >>> -----Original Message----- >> >> >>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM >> >> >>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala >> <kumar.gala@linaro.org> wrote: >> >> >>>> I think this also gets to having bindings described in a structured way >> so >> >> >>> they can be utilized for validation of dts files. We are doing a little of >> this in >> >> >>> Zephyr since we are using a structured binding spec to generate code >> from >> >> >>> .dts (since we don’t utilize a runtime dtb). >> >> >>> >> >> >>> So you are basically generating board files from .dts? >> >> >>> (closing the loop ;-) >> >> >> >> >> >> I think we ought to do this on Linux, as a size optimization. >> >> >> -- Tim >> >> >> >> >> >> P.S. I think I'll leave it ambiguous whether this was meant as a joke or >> not. :-) >> >> >> >> As crazy that sounds it is possible using the YAML bindings, i.e. C structure >> definitions >> >> and fill-up from DT automatically. Whether this is a good idea it’s another >> question :) >> > >> > But that doesn't work with any driver parsing custom properties (using >> > of_property_read_* and the likes). I would very much like to see what >> > are the boot time improvements when doing that ;) >> >> Unless you override of_property_read_*() to work on the dense C >> structures instead? > > Or turn the property reads into macros that then turn into constant declarations inline in the code. > No need stop at dense C structures. Of course you lose all configuration flexibility at runtime. > But then that's the kind of trade-off one often makes with embedded software, isn't it? That's basically what Grant proposed[1]. Turn all the property strings to numeric IDs that can directly reference the original FDT data avoiding storing the property structs. If you don't care about code size then removing runtime configuration within the OF API (i.e. not reworking driver probe functions) is not going to save much. And these days with XIP SPI flash chips, code size is not so much the issue. Maybe you saw Nico's presentation at Connect, but if not it is here[2]. Rob [1] https://www.spinics.net/lists/devicetree/msg197417.html [2] http://connect.linaro.org/resource/las16/las16-407/ ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 18:00 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-18 18:00 UTC (permalink / raw) To: Bird, Timothy Cc: Geert Uytterhoeven, Alexandre Belloni, devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Ian Lepore, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou On Wed, Oct 18, 2017 at 12:41 PM, Bird, Timothy <Tim.Bird-7U/KSKJipcs@public.gmane.org> wrote: > > >> -----Original Message----- >> From Geert Uytterhoeven on Wednesday, October 18, 2017 6:22 AM >> On Wed, Oct 18, 2017 at 3:18 PM, Alexandre Belloni >> <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote: >> > On 18/10/2017 at 15:59:00 +0300, Pantelis Antoniou wrote: >> >> > On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> >> wrote: >> >> > On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird-7U/KSKJipcs@public.gmane.org> >> wrote: >> >> >>> -----Original Message----- >> >> >>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM >> >> >>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala >> <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >> >> >>>> I think this also gets to having bindings described in a structured way >> so >> >> >>> they can be utilized for validation of dts files. We are doing a little of >> this in >> >> >>> Zephyr since we are using a structured binding spec to generate code >> from >> >> >>> .dts (since we don’t utilize a runtime dtb). >> >> >>> >> >> >>> So you are basically generating board files from .dts? >> >> >>> (closing the loop ;-) >> >> >> >> >> >> I think we ought to do this on Linux, as a size optimization. >> >> >> -- Tim >> >> >> >> >> >> P.S. I think I'll leave it ambiguous whether this was meant as a joke or >> not. :-) >> >> >> >> As crazy that sounds it is possible using the YAML bindings, i.e. C structure >> definitions >> >> and fill-up from DT automatically. Whether this is a good idea it’s another >> question :) >> > >> > But that doesn't work with any driver parsing custom properties (using >> > of_property_read_* and the likes). I would very much like to see what >> > are the boot time improvements when doing that ;) >> >> Unless you override of_property_read_*() to work on the dense C >> structures instead? > > Or turn the property reads into macros that then turn into constant declarations inline in the code. > No need stop at dense C structures. Of course you lose all configuration flexibility at runtime. > But then that's the kind of trade-off one often makes with embedded software, isn't it? That's basically what Grant proposed[1]. Turn all the property strings to numeric IDs that can directly reference the original FDT data avoiding storing the property structs. If you don't care about code size then removing runtime configuration within the OF API (i.e. not reworking driver probe functions) is not going to save much. And these days with XIP SPI flash chips, code size is not so much the issue. Maybe you saw Nico's presentation at Connect, but if not it is here[2]. Rob [1] https://www.spinics.net/lists/devicetree/msg197417.html [2] http://connect.linaro.org/resource/las16/las16-407/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 21:10 ` Alexandre Belloni 0 siblings, 0 replies; 126+ messages in thread From: Alexandre Belloni @ 2017-10-18 21:10 UTC (permalink / raw) To: Bird, Timothy Cc: devicetree, Kumar Gala, ksummit-discuss, Ian Lepore, devicetree-spec, Pantelis Antoniou On 18/10/2017 at 17:41:11 +0000, Bird, Timothy wrote: > > > > -----Original Message----- > > From Geert Uytterhoeven on Wednesday, October 18, 2017 6:22 AM > > On Wed, Oct 18, 2017 at 3:18 PM, Alexandre Belloni > > <alexandre.belloni@free-electrons.com> wrote: > > > On 18/10/2017 at 15:59:00 +0300, Pantelis Antoniou wrote: > > >> > On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely@secretlab.ca> > > wrote: > > >> > On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird@sony.com> > > wrote: > > >> >>> -----Original Message----- > > >> >>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM > > >> >>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala > > <kumar.gala@linaro.org> wrote: > > >> >>>> I think this also gets to having bindings described in a structured way > > so > > >> >>> they can be utilized for validation of dts files. We are doing a little of > > this in > > >> >>> Zephyr since we are using a structured binding spec to generate code > > from > > >> >>> .dts (since we don’t utilize a runtime dtb). > > >> >>> > > >> >>> So you are basically generating board files from .dts? > > >> >>> (closing the loop ;-) > > >> >> > > >> >> I think we ought to do this on Linux, as a size optimization. > > >> >> -- Tim > > >> >> > > >> >> P.S. I think I'll leave it ambiguous whether this was meant as a joke or > > not. :-) > > >> > > >> As crazy that sounds it is possible using the YAML bindings, i.e. C structure > > definitions > > >> and fill-up from DT automatically. Whether this is a good idea it’s another > > question :) > > > > > > But that doesn't work with any driver parsing custom properties (using > > > of_property_read_* and the likes). I would very much like to see what > > > are the boot time improvements when doing that ;) > > > > Unless you override of_property_read_*() to work on the dense C > > structures instead? > > Or turn the property reads into macros that then turn into constant declarations inline in the code. > No need stop at dense C structures. Of course you lose all configuration flexibility at runtime. > But then that's the kind of trade-off one often makes with embedded software, isn't it? That is not easily doable unless you are sure you only have only one instance of each device or they all have the same properties. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 21:10 ` Alexandre Belloni 0 siblings, 0 replies; 126+ messages in thread From: Alexandre Belloni @ 2017-10-18 21:10 UTC (permalink / raw) To: Bird, Timothy Cc: Geert Uytterhoeven, devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Ian Lepore, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou On 18/10/2017 at 17:41:11 +0000, Bird, Timothy wrote: > > > > -----Original Message----- > > From Geert Uytterhoeven on Wednesday, October 18, 2017 6:22 AM > > On Wed, Oct 18, 2017 at 3:18 PM, Alexandre Belloni > > <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote: > > > On 18/10/2017 at 15:59:00 +0300, Pantelis Antoniou wrote: > > >> > On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> > > wrote: > > >> > On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird-7U/KSKJipcs@public.gmane.org> > > wrote: > > >> >>> -----Original Message----- > > >> >>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM > > >> >>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala > > <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > > >> >>>> I think this also gets to having bindings described in a structured way > > so > > >> >>> they can be utilized for validation of dts files. We are doing a little of > > this in > > >> >>> Zephyr since we are using a structured binding spec to generate code > > from > > >> >>> .dts (since we don’t utilize a runtime dtb). > > >> >>> > > >> >>> So you are basically generating board files from .dts? > > >> >>> (closing the loop ;-) > > >> >> > > >> >> I think we ought to do this on Linux, as a size optimization. > > >> >> -- Tim > > >> >> > > >> >> P.S. I think I'll leave it ambiguous whether this was meant as a joke or > > not. :-) > > >> > > >> As crazy that sounds it is possible using the YAML bindings, i.e. C structure > > definitions > > >> and fill-up from DT automatically. Whether this is a good idea it’s another > > question :) > > > > > > But that doesn't work with any driver parsing custom properties (using > > > of_property_read_* and the likes). I would very much like to see what > > > are the boot time improvements when doing that ;) > > > > Unless you override of_property_read_*() to work on the dense C > > structures instead? > > Or turn the property reads into macros that then turn into constant declarations inline in the code. > No need stop at dense C structures. Of course you lose all configuration flexibility at runtime. > But then that's the kind of trade-off one often makes with embedded software, isn't it? That is not easily doable unless you are sure you only have only one instance of each device or they all have the same properties. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 16:18 ` David Woodhouse 0 siblings, 0 replies; 126+ messages in thread From: David Woodhouse @ 2017-10-18 16:18 UTC (permalink / raw) To: Alexandre Belloni, Pantelis Antoniou Cc: devicetree, Kumar Gala, ksummit-discuss, Ian Lepore, devicetree-spec, Bird, Timothy [-- Attachment #1: Type: text/plain, Size: 326 bytes --] On Wed, 2017-10-18 at 15:18 +0200, Alexandre Belloni wrote: > > But that doesn't work with any driver parsing custom properties (using > of_property_read_* and the likes). I would very much like to see what > are the boot time improvements when doing that ;) You mean device_property_read_* and the like, I'm sure... [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 4938 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 16:18 ` David Woodhouse 0 siblings, 0 replies; 126+ messages in thread From: David Woodhouse @ 2017-10-18 16:18 UTC (permalink / raw) To: Alexandre Belloni, Pantelis Antoniou Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Ian Lepore, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Bird, Timothy [-- Attachment #1: Type: text/plain, Size: 326 bytes --] On Wed, 2017-10-18 at 15:18 +0200, Alexandre Belloni wrote: > > But that doesn't work with any driver parsing custom properties (using > of_property_read_* and the likes). I would very much like to see what > are the boot time improvements when doing that ;) You mean device_property_read_* and the like, I'm sure... [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 4938 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 14:13 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-18 14:13 UTC (permalink / raw) To: Pantelis Antoniou Cc: devicetree, Kumar Gala, ksummit-discuss, Ian Lepore, devicetree-spec, Bird, Timothy On Wed, Oct 18, 2017 at 7:59 AM, Pantelis Antoniou <panto@antoniou-consulting.com> wrote: > Hi Grant, > >> On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely@secretlab.ca> wrote: >> >> On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird@sony.com> wrote: >>>> -----Original Message----- >>>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM >>>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala@linaro.org> wrote: >>>>> I think this also gets to having bindings described in a structured way so >>>> they can be utilized for validation of dts files. We are doing a little of this in >>>> Zephyr since we are using a structured binding spec to generate code from >>>> .dts (since we don’t utilize a runtime dtb). >>>> >>>> So you are basically generating board files from .dts? >>>> (closing the loop ;-) Briefly, what Zephyr is doing is controlling configuration (what drivers are built) and generating register base addresses and maybe interrupts. That's not really board.dts -> board.c. >>> >>> I think we ought to do this on Linux, as a size optimization. >>> -- Tim >>> >>> P.S. I think I'll leave it ambiguous whether this was meant as a joke or not. :-) >> > > As crazy that sounds it is possible using the YAML bindings, i.e. C structure definitions > and fill-up from DT automatically. Whether this is a good idea it’s another question :) Yeah, yeah. YAML solves *all* the problems. >> Talk to Nicolas Pitre and Rob Herring about this. They've already made >> a bunch of progress on reducing memory footprint. Or just look at linux-next. :) The focus is purely on runtime RAM usage with all code being XIP. Basically, I've reduced the size of the unflattened tree by skipping unflattening of disabled nodes and shrinking the unflattened tree structs. For example removing the kobject for !SYSFS. This reduced RAM usage from 120K to 11K on an stm32 board. The next thing in the heat map of RAM usage is struct device size. There's some things like DMA related elements that could be moved to separate structures, but that will be quite invasive. Another idea is to run the kernel unflattening code on the tree at build time and embed that as const data into the kernel. The unflattening code is pretty self contained and XIP images are platform specific anyway. It would also allow running all dtb files thru unflattening at build time for some validation. Though I'm not sure there's anything unflattening would fail on that dtc can't check. Rob ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 14:13 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-18 14:13 UTC (permalink / raw) To: Pantelis Antoniou Cc: Grant Likely, Bird, Timothy, Geert Uytterhoeven, Kumar Gala, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, Ian Lepore, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I On Wed, Oct 18, 2017 at 7:59 AM, Pantelis Antoniou <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> wrote: > Hi Grant, > >> On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: >> >> On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird-7U/KSKJipcs@public.gmane.org> wrote: >>>> -----Original Message----- >>>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM >>>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >>>>> I think this also gets to having bindings described in a structured way so >>>> they can be utilized for validation of dts files. We are doing a little of this in >>>> Zephyr since we are using a structured binding spec to generate code from >>>> .dts (since we don’t utilize a runtime dtb). >>>> >>>> So you are basically generating board files from .dts? >>>> (closing the loop ;-) Briefly, what Zephyr is doing is controlling configuration (what drivers are built) and generating register base addresses and maybe interrupts. That's not really board.dts -> board.c. >>> >>> I think we ought to do this on Linux, as a size optimization. >>> -- Tim >>> >>> P.S. I think I'll leave it ambiguous whether this was meant as a joke or not. :-) >> > > As crazy that sounds it is possible using the YAML bindings, i.e. C structure definitions > and fill-up from DT automatically. Whether this is a good idea it’s another question :) Yeah, yeah. YAML solves *all* the problems. >> Talk to Nicolas Pitre and Rob Herring about this. They've already made >> a bunch of progress on reducing memory footprint. Or just look at linux-next. :) The focus is purely on runtime RAM usage with all code being XIP. Basically, I've reduced the size of the unflattened tree by skipping unflattening of disabled nodes and shrinking the unflattened tree structs. For example removing the kobject for !SYSFS. This reduced RAM usage from 120K to 11K on an stm32 board. The next thing in the heat map of RAM usage is struct device size. There's some things like DMA related elements that could be moved to separate structures, but that will be quite invasive. Another idea is to run the kernel unflattening code on the tree at build time and embed that as const data into the kernel. The unflattening code is pretty self contained and XIP images are platform specific anyway. It would also allow running all dtb files thru unflattening at build time for some validation. Though I'm not sure there's anything unflattening would fail on that dtc can't check. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) 2017-10-18 14:13 ` Rob Herring @ 2017-10-18 17:45 ` Bird, Timothy -1 siblings, 0 replies; 126+ messages in thread From: Bird, Timothy @ 2017-10-18 17:45 UTC (permalink / raw) To: Rob Herring, Pantelis Antoniou Cc: devicetree, Kumar Gala, ksummit-discuss, Ian Lepore, devicetree-spec > -----Original Message----- > From: Rob on Wednesday, October 18, 2017 7:14 AM > On Wed, Oct 18, 2017 at 7:59 AM, Pantelis Antoniou > <panto@antoniou-consulting.com> wrote: > > Hi Grant, > > > >> On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely@secretlab.ca> wrote: > >> > >> On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird@sony.com> > wrote: > >>>> -----Original Message----- > >>>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM > >>>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala@linaro.org> > wrote: > >>>>> I think this also gets to having bindings described in a structured way > so > >>>> they can be utilized for validation of dts files. We are doing a little of > this in > >>>> Zephyr since we are using a structured binding spec to generate code > from > >>>> .dts (since we don’t utilize a runtime dtb). > >>>> > >>>> So you are basically generating board files from .dts? > >>>> (closing the loop ;-) > > Briefly, what Zephyr is doing is controlling configuration (what > drivers are built) and generating register base addresses and maybe > interrupts. That's not really board.dts -> board.c. > > >>> > >>> I think we ought to do this on Linux, as a size optimization. > >>> -- Tim > >>> > >>> P.S. I think I'll leave it ambiguous whether this was meant as a joke or > not. :-) > >> > > > > As crazy that sounds it is possible using the YAML bindings, i.e. C structure > definitions > > and fill-up from DT automatically. Whether this is a good idea it’s another > question :) > > Yeah, yeah. YAML solves *all* the problems. > > >> Talk to Nicolas Pitre and Rob Herring about this. They've already made > >> a bunch of progress on reducing memory footprint. > > Or just look at linux-next. :) The focus is purely on runtime RAM > usage with all code being XIP. Basically, I've reduced the size of the > unflattened tree by skipping unflattening of disabled nodes and > shrinking the unflattened tree structs. For example removing the > kobject for !SYSFS. This reduced RAM usage from 120K to 11K on an > stm32 board. The next thing in the heat map of RAM usage is struct > device size. There's some things like DMA related elements that could > be moved to separate structures, but that will be quite invasive. > > Another idea is to run the kernel unflattening code on the tree at > build time and embed that as const data into the kernel. The > unflattening code is pretty self contained and XIP images are platform > specific anyway. It would also allow running all dtb files thru > unflattening at build time for some validation. Though I'm not sure > there's anything unflattening would fail on that dtc can't check. I should have read all the way to the end of the thread before responding. It looks like people are already looking at what I've been thinking about for a while. Sorry I missed Nicolas' talk at LC. I'll go take a look at the video. -- Tim ^ permalink raw reply [flat|nested] 126+ messages in thread
* RE: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 17:45 ` Bird, Timothy 0 siblings, 0 replies; 126+ messages in thread From: Bird, Timothy @ 2017-10-18 17:45 UTC (permalink / raw) To: Rob Herring, Pantelis Antoniou Cc: Grant Likely, Geert Uytterhoeven, Kumar Gala, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, Ian Lepore, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3137 bytes --] > -----Original Message----- > From: Rob on Wednesday, October 18, 2017 7:14 AM > On Wed, Oct 18, 2017 at 7:59 AM, Pantelis Antoniou > <panto@antoniou-consulting.com> wrote: > > Hi Grant, > > > >> On Oct 18, 2017, at 15:14 , Grant Likely <grant.likely@secretlab.ca> wrote: > >> > >> On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy <Tim.Bird@sony.com> > wrote: > >>>> -----Original Message----- > >>>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM > >>>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala@linaro.org> > wrote: > >>>>> I think this also gets to having bindings described in a structured way > so > >>>> they can be utilized for validation of dts files. We are doing a little of > this in > >>>> Zephyr since we are using a structured binding spec to generate code > from > >>>> .dts (since we donât utilize a runtime dtb). > >>>> > >>>> So you are basically generating board files from .dts? > >>>> (closing the loop ;-) > > Briefly, what Zephyr is doing is controlling configuration (what > drivers are built) and generating register base addresses and maybe > interrupts. That's not really board.dts -> board.c. > > >>> > >>> I think we ought to do this on Linux, as a size optimization. > >>> -- Tim > >>> > >>> P.S. I think I'll leave it ambiguous whether this was meant as a joke or > not. :-) > >> > > > > As crazy that sounds it is possible using the YAML bindings, i.e. C structure > definitions > > and fill-up from DT automatically. Whether this is a good idea itâs another > question :) > > Yeah, yeah. YAML solves *all* the problems. > > >> Talk to Nicolas Pitre and Rob Herring about this. They've already made > >> a bunch of progress on reducing memory footprint. > > Or just look at linux-next. :) The focus is purely on runtime RAM > usage with all code being XIP. Basically, I've reduced the size of the > unflattened tree by skipping unflattening of disabled nodes and > shrinking the unflattened tree structs. For example removing the > kobject for !SYSFS. This reduced RAM usage from 120K to 11K on an > stm32 board. The next thing in the heat map of RAM usage is struct > device size. There's some things like DMA related elements that could > be moved to separate structures, but that will be quite invasive. > > Another idea is to run the kernel unflattening code on the tree at > build time and embed that as const data into the kernel. The > unflattening code is pretty self contained and XIP images are platform > specific anyway. It would also allow running all dtb files thru > unflattening at build time for some validation. Though I'm not sure > there's anything unflattening would fail on that dtc can't check. I should have read all the way to the end of the thread before responding. It looks like people are already looking at what I've been thinking about for a while. Sorry I missed Nicolas' talk at LC. I'll go take a look at the video. -- Tim N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·zøzÚÞz)í æèw*\x1fjg¬±¨\x1e¶Ý¢j.ïÛ°\½½MúgjÌæa×\x02' ©Þ¢¸\f¢·¦j:+v¨wèjØm¶ÿ¾\a«êçzZ+ùÝ¢j"ú!¶i ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 14:07 ` Kumar Gala 0 siblings, 0 replies; 126+ messages in thread From: Kumar Gala @ 2017-10-18 14:07 UTC (permalink / raw) To: Geert Uytterhoeven Cc: devicetree, devicetree-spec, ksummit-discuss, Ian Lepore > On Oct 17, 2017, at 12:24 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Kumar, > > On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala@linaro.org> wrote: >> I think this also gets to having bindings described in a structured way so they can be utilized for validation of dts files. We are doing a little of this in Zephyr since we are using a structured binding spec to generate code from .dts (since we don’t utilize a runtime dtb). > > So you are basically generating board files from .dts? > (closing the loop ;-) Not exactly board files, more like platform data at this point. IRQ, MMIO addresses, stuff like that. - k ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 14:07 ` Kumar Gala 0 siblings, 0 replies; 126+ messages in thread From: Kumar Gala @ 2017-10-18 14:07 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Ian Lepore, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I > On Oct 17, 2017, at 12:24 PM, Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote: > > Hi Kumar, > > On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >> I think this also gets to having bindings described in a structured way so they can be utilized for validation of dts files. We are doing a little of this in Zephyr since we are using a structured binding spec to generate code from .dts (since we don’t utilize a runtime dtb). > > So you are basically generating board files from .dts? > (closing the loop ;-) Not exactly board files, more like platform data at this point. IRQ, MMIO addresses, stuff like that. - k ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 14:07 ` Kumar Gala 0 siblings, 0 replies; 126+ messages in thread From: Kumar Gala @ 2017-10-18 14:07 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Ian Lepore, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I > On Oct 17, 2017, at 12:24 PM, Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote: > > Hi Kumar, > > On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >> I think this also gets to having bindings described in a structured way so they can be utilized for validation of dts files. We are doing a little of this in Zephyr since we are using a structured binding spec to generate code from .dts (since we don’t utilize a runtime dtb). > > So you are basically generating board files from .dts? > (closing the loop ;-) Not exactly board files, more like platform data at this point. IRQ, MMIO addresses, stuff like that. - k ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 17:25 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-17 17:25 UTC (permalink / raw) To: Ian Lepore; +Cc: devicetree, devicetree-spec, ksummit-discuss On Tue, Oct 17, 2017 at 11:21 AM, Ian Lepore <ian@freebsd.org> wrote: > On Tue, 2017-10-17 at 14:48 +0100, Grant Likely wrote: >> On Tue, Oct 17, 2017 at 10:48 AM, Boris Brezillon >> <boris.brezillon@free-electrons.com> wrote: >> > >> > Hello Grant, >> > >> > On Mon, 9 Oct 2017 21:39:51 +0100 >> > Grant Likely <grant.likely@secretlab.ca> wrote: >> > >> > > >> > > Kernel Summit is now just over 2 weeks away and it is time to pull >> > > together the schedule for the Devicetree workshop. Originally I >> > > planned on just an afternoon, but I've got the room for the whole day, >> > > so I've got a lot of flexibility on the schedule. Unscheduled time can >> > > be used for hacking. >> > > >> > > Date: 26 Oct 2017 >> > > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> > > Location: Athens room - Hilton Prague >> > > >> > > If you plan to attend, make sure you update your OSSunmitE/ELCE >> > > registration to include the DT Workshop (log in to access and modify >> > > your registration): >> > > >> > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> > > >> > > Here is my current list of topics in no particular order, including >> > > the topic moderator: >> > > >> > > Runtime memory consumption (Rob Herring) >> > > Overlay maintenance plan (TBC) >> > > Stable ABI for devicetree (TBC) >> > > DT YAML encoding (Pantelis Antoniou) >> > > DT Schema format - option 1 (Pantelis Antoniou) >> > > DT Schema format - option 2 (Grant Likely) >> > > Sharing Generic bindings (TBC) >> > > devicetree.org update (Grant) >> > > >> > > Reply to this email if you want to propose another topic. >> > Not sure yet if I'll attend the DT workshop or not, but I thought I >> > could ask my question here because it might be of interest to someone >> > else who is attending. >> > >> > What happens when the DT bindings is not documented in Linux but in an >> > another project because this project was the first to use it. >> > >> > I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm >> > not sure what's the policy when this happens. Should we add a file >> > under Documentation/devicetree/bindings/... that points to the external >> > doc file, should we duplicate the DT bindings doc in Linux, or should >> > we just leave the bindings undocumented in the kernel tree? >> I'm going to add this as a topic. I've got my own opinion, but it >> would be better to discuss in the room because it affects maintainers. >> >> g. > > > I've run into the same thing in FreeBSD. We use bindings and dts > files, exacted periodically from the linux tree and imported into ours, > for all modern arm boards/systems. Several times I've created drivers > for small things like i2c RTC chips that aren't supported currently by > linux, and it's not clear to me that it's even possible to submit > bindings and dts for them back upstream without also submitting a linux > driver that uses them (which of course I'm not in a position to do). I will happily take bindings and would like to dispel this myth. Send them to the DT list and just make it clear there's no Linux driver so I know to pick it up if any subsystem maintainers won't (though I'd suspect that most will). dts files are a bit more complicated as I generally don't take those. But please force the issue. If no non-Linux developer submits dts changes, then it is certainly true that dts changes aren't accepted. Rob ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-17 17:25 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-17 17:25 UTC (permalink / raw) To: Ian Lepore Cc: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I On Tue, Oct 17, 2017 at 11:21 AM, Ian Lepore <ian-h+KGxgPPiopAfugRpC6u6w@public.gmane.org> wrote: > On Tue, 2017-10-17 at 14:48 +0100, Grant Likely wrote: >> On Tue, Oct 17, 2017 at 10:48 AM, Boris Brezillon >> <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote: >> > >> > Hello Grant, >> > >> > On Mon, 9 Oct 2017 21:39:51 +0100 >> > Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: >> > >> > > >> > > Kernel Summit is now just over 2 weeks away and it is time to pull >> > > together the schedule for the Devicetree workshop. Originally I >> > > planned on just an afternoon, but I've got the room for the whole day, >> > > so I've got a lot of flexibility on the schedule. Unscheduled time can >> > > be used for hacking. >> > > >> > > Date: 26 Oct 2017 >> > > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> > > Location: Athens room - Hilton Prague >> > > >> > > If you plan to attend, make sure you update your OSSunmitE/ELCE >> > > registration to include the DT Workshop (log in to access and modify >> > > your registration): >> > > >> > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> > > >> > > Here is my current list of topics in no particular order, including >> > > the topic moderator: >> > > >> > > Runtime memory consumption (Rob Herring) >> > > Overlay maintenance plan (TBC) >> > > Stable ABI for devicetree (TBC) >> > > DT YAML encoding (Pantelis Antoniou) >> > > DT Schema format - option 1 (Pantelis Antoniou) >> > > DT Schema format - option 2 (Grant Likely) >> > > Sharing Generic bindings (TBC) >> > > devicetree.org update (Grant) >> > > >> > > Reply to this email if you want to propose another topic. >> > Not sure yet if I'll attend the DT workshop or not, but I thought I >> > could ask my question here because it might be of interest to someone >> > else who is attending. >> > >> > What happens when the DT bindings is not documented in Linux but in an >> > another project because this project was the first to use it. >> > >> > I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm >> > not sure what's the policy when this happens. Should we add a file >> > under Documentation/devicetree/bindings/... that points to the external >> > doc file, should we duplicate the DT bindings doc in Linux, or should >> > we just leave the bindings undocumented in the kernel tree? >> I'm going to add this as a topic. I've got my own opinion, but it >> would be better to discuss in the room because it affects maintainers. >> >> g. > > > I've run into the same thing in FreeBSD. We use bindings and dts > files, exacted periodically from the linux tree and imported into ours, > for all modern arm boards/systems. Several times I've created drivers > for small things like i2c RTC chips that aren't supported currently by > linux, and it's not clear to me that it's even possible to submit > bindings and dts for them back upstream without also submitting a linux > driver that uses them (which of course I'm not in a position to do). I will happily take bindings and would like to dispel this myth. Send them to the DT list and just make it clear there's no Linux driver so I know to pick it up if any subsystem maintainers won't (though I'd suspect that most will). dts files are a bit more complicated as I generally don't take those. But please force the issue. If no non-Linux developer submits dts changes, then it is certainly true that dts changes aren't accepted. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 10:11 ` Thomas Petazzoni 0 siblings, 0 replies; 126+ messages in thread From: Thomas Petazzoni @ 2017-10-18 10:11 UTC (permalink / raw) To: Ian Lepore; +Cc: devicetree-spec, ksummit-discuss, devicetree Hello, On Tue, 17 Oct 2017 10:21:16 -0600, Ian Lepore wrote: > I've run into the same thing in FreeBSD. We use bindings and dts > files, exacted periodically from the linux tree and imported into ours, > for all modern arm boards/systems. Several times I've created drivers > for small things like i2c RTC chips that aren't supported currently by > linux, and it's not clear to me that it's even possible to submit > bindings and dts for them back upstream without also submitting a linux > driver that uses them (which of course I'm not in a position to do). You don't have to submit a driver to submit a binding. Examples of bindings that are not supported by any upstream driver: Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt and there are probably more. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 10:11 ` Thomas Petazzoni 0 siblings, 0 replies; 126+ messages in thread From: Thomas Petazzoni @ 2017-10-18 10:11 UTC (permalink / raw) To: Ian Lepore Cc: Grant Likely, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I Hello, On Tue, 17 Oct 2017 10:21:16 -0600, Ian Lepore wrote: > I've run into the same thing in FreeBSD. We use bindings and dts > files, exacted periodically from the linux tree and imported into ours, > for all modern arm boards/systems. Several times I've created drivers > for small things like i2c RTC chips that aren't supported currently by > linux, and it's not clear to me that it's even possible to submit > bindings and dts for them back upstream without also submitting a linux > driver that uses them (which of course I'm not in a position to do). You don't have to submit a driver to submit a binding. Examples of bindings that are not supported by any upstream driver: Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt and there are probably more. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) 2017-10-17 9:48 ` Boris Brezillon @ 2017-10-18 10:35 ` Chen-Yu Tsai -1 siblings, 0 replies; 126+ messages in thread From: Chen-Yu Tsai @ 2017-10-18 10:35 UTC (permalink / raw) To: Grant Likely Cc: Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, devicetree, Andy Gross, David Gibson, Tom Rini, Lucas Stach Hi Grant, On Tue, Oct 17, 2017 at 5:48 PM, Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > Hello Grant, > > On Mon, 9 Oct 2017 21:39:51 +0100 > Grant Likely <grant.likely@secretlab.ca> wrote: > >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. > > Not sure yet if I'll attend the DT workshop or not, but I thought I > could ask my question here because it might be of interest to someone > else who is attending. > > What happens when the DT bindings is not documented in Linux but in an > another project because this project was the first to use it. > > I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm > not sure what's the policy when this happens. Should we add a file > under Documentation/devicetree/bindings/... that points to the external > doc file, should we duplicate the DT bindings doc in Linux, or should > we just leave the bindings undocumented in the kernel tree? I'd like to add something on the topic of non-Linux projects. In this case it's diverging DT bindings from U-boot: https://patchwork.ozlabs.org/patch/823158/ U-boot already has a set of devicetree binding additions: https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings The patch in question wants to ab(use) the regulator-name property for driver instance binding. In my opinion this is not going to fly, as boards are free to define the names. This either sees no use other than as a dirty workaround for dts files that aren't following the PMIC regulator bindings (regulator node names should follow well defined, identifying names), or results in divergence of the DT files. So far I've been unable to dissuade the author. Unfortunately I won't be attending the workshop, as I had planned on some sightseeing and the workshop is already full right now. Hope this gets discussed in some manner. Regards ChenYu ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 10:35 ` Chen-Yu Tsai 0 siblings, 0 replies; 126+ messages in thread From: Chen-Yu Tsai @ 2017-10-18 10:35 UTC (permalink / raw) To: Grant Likely Cc: Boris Brezillon, devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson, Tom Rini Hi Grant, On Tue, Oct 17, 2017 at 5:48 PM, Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote: > Hello Grant, > > On Mon, 9 Oct 2017 21:39:51 +0100 > Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. > > Not sure yet if I'll attend the DT workshop or not, but I thought I > could ask my question here because it might be of interest to someone > else who is attending. > > What happens when the DT bindings is not documented in Linux but in an > another project because this project was the first to use it. > > I had the case here http://patchwork.ozlabs.org/patch/810275/, and I'm > not sure what's the policy when this happens. Should we add a file > under Documentation/devicetree/bindings/... that points to the external > doc file, should we duplicate the DT bindings doc in Linux, or should > we just leave the bindings undocumented in the kernel tree? I'd like to add something on the topic of non-Linux projects. In this case it's diverging DT bindings from U-boot: https://patchwork.ozlabs.org/patch/823158/ U-boot already has a set of devicetree binding additions: https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings The patch in question wants to ab(use) the regulator-name property for driver instance binding. In my opinion this is not going to fly, as boards are free to define the names. This either sees no use other than as a dirty workaround for dts files that aren't following the PMIC regulator bindings (regulator node names should follow well defined, identifying names), or results in divergence of the DT files. So far I've been unable to dissuade the author. Unfortunately I won't be attending the workshop, as I had planned on some sightseeing and the workshop is already full right now. Hope this gets discussed in some manner. Regards ChenYu -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 11:09 ` Mark Brown 0 siblings, 0 replies; 126+ messages in thread From: Mark Brown @ 2017-10-18 11:09 UTC (permalink / raw) To: Chen-Yu Tsai Cc: Rob Herring, Kumar Gala, ksummit-discuss, devicetree, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, Tom Rini, David Gibson [-- Attachment #1: Type: text/plain, Size: 915 bytes --] On Wed, Oct 18, 2017 at 06:35:24PM +0800, Chen-Yu Tsai wrote: > I'd like to add something on the topic of non-Linux projects. In this > case it's diverging DT bindings from U-boot: > https://patchwork.ozlabs.org/patch/823158/ > U-boot already has a set of devicetree binding additions: > https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings > The patch in question wants to ab(use) the regulator-name property for > driver instance binding. In my opinion this is not going to fly, as > boards are free to define the names. This either sees no use other than > as a dirty workaround for dts files that aren't following the PMIC > regulator bindings (regulator node names should follow well defined, > identifying names), or results in divergence of the DT files. One meta issue I'm seeing here is that the u-boot people appear to have their own divergent copy of some of the binding documents. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 11:09 ` Mark Brown 0 siblings, 0 replies; 126+ messages in thread From: Mark Brown @ 2017-10-18 11:09 UTC (permalink / raw) To: Chen-Yu Tsai Cc: Grant Likely, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, Andy Gross, David Gibson, Tom Rini, Lucas Stach [-- Attachment #1: Type: text/plain, Size: 915 bytes --] On Wed, Oct 18, 2017 at 06:35:24PM +0800, Chen-Yu Tsai wrote: > I'd like to add something on the topic of non-Linux projects. In this > case it's diverging DT bindings from U-boot: > https://patchwork.ozlabs.org/patch/823158/ > U-boot already has a set of devicetree binding additions: > https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings > The patch in question wants to ab(use) the regulator-name property for > driver instance binding. In my opinion this is not going to fly, as > boards are free to define the names. This either sees no use other than > as a dirty workaround for dts files that aren't following the PMIC > regulator bindings (regulator node names should follow well defined, > identifying names), or results in divergence of the DT files. One meta issue I'm seeing here is that the u-boot people appear to have their own divergent copy of some of the binding documents. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 17:59 ` Tom Rini 0 siblings, 0 replies; 126+ messages in thread From: Tom Rini @ 2017-10-18 17:59 UTC (permalink / raw) To: Mark Brown Cc: Rob Herring, Kumar Gala, ksummit-discuss, devicetree, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson [-- Attachment #1: Type: text/plain, Size: 1484 bytes --] On Wed, Oct 18, 2017 at 12:09:58PM +0100, Mark Brown wrote: > On Wed, Oct 18, 2017 at 06:35:24PM +0800, Chen-Yu Tsai wrote: > > > I'd like to add something on the topic of non-Linux projects. In this > > case it's diverging DT bindings from U-boot: > > > https://patchwork.ozlabs.org/patch/823158/ > > > U-boot already has a set of devicetree binding additions: > > https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings > > > The patch in question wants to ab(use) the regulator-name property for > > driver instance binding. In my opinion this is not going to fly, as > > boards are free to define the names. This either sees no use other than > > as a dirty workaround for dts files that aren't following the PMIC > > regulator bindings (regulator node names should follow well defined, > > identifying names), or results in divergence of the DT files. > > One meta issue I'm seeing here is that the u-boot people appear to have > their own divergent copy of some of the binding documents. Putting on my U-Boot hat now, it's mostly unintentional and something in general (yes, the initial topic here is not such an example) we try and avoid, or use u-boot, as the prefix on as it's something that had been previously rejected or deemed inappropriate to be in the upstream version of the binding. But perhaps it's time to try and force the issue again, given what Rob and others have said in other parts of the thread. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 17:59 ` Tom Rini 0 siblings, 0 replies; 126+ messages in thread From: Tom Rini @ 2017-10-18 17:59 UTC (permalink / raw) To: Mark Brown Cc: Chen-Yu Tsai, Grant Likely, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, Andy Gross, David Gibson, Lucas Stach [-- Attachment #1: Type: text/plain, Size: 1484 bytes --] On Wed, Oct 18, 2017 at 12:09:58PM +0100, Mark Brown wrote: > On Wed, Oct 18, 2017 at 06:35:24PM +0800, Chen-Yu Tsai wrote: > > > I'd like to add something on the topic of non-Linux projects. In this > > case it's diverging DT bindings from U-boot: > > > https://patchwork.ozlabs.org/patch/823158/ > > > U-boot already has a set of devicetree binding additions: > > https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings > > > The patch in question wants to ab(use) the regulator-name property for > > driver instance binding. In my opinion this is not going to fly, as > > boards are free to define the names. This either sees no use other than > > as a dirty workaround for dts files that aren't following the PMIC > > regulator bindings (regulator node names should follow well defined, > > identifying names), or results in divergence of the DT files. > > One meta issue I'm seeing here is that the u-boot people appear to have > their own divergent copy of some of the binding documents. Putting on my U-Boot hat now, it's mostly unintentional and something in general (yes, the initial topic here is not such an example) we try and avoid, or use u-boot, as the prefix on as it's something that had been previously rejected or deemed inappropriate to be in the upstream version of the binding. But perhaps it's time to try and force the issue again, given what Rob and others have said in other parts of the thread. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) 2017-10-18 17:59 ` Tom Rini (?) @ 2017-10-18 23:28 ` Andrew Turner -1 siblings, 0 replies; 126+ messages in thread From: Andrew Turner @ 2017-10-18 23:28 UTC (permalink / raw) To: Tom Rini Cc: Rob Herring, Kumar Gala, ksummit-discuss, devicetree, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson > On 18 Oct 2017, at 18:59, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Oct 18, 2017 at 12:09:58PM +0100, Mark Brown wrote: >> On Wed, Oct 18, 2017 at 06:35:24PM +0800, Chen-Yu Tsai wrote: >> >>> I'd like to add something on the topic of non-Linux projects. In this >>> case it's diverging DT bindings from U-boot: >> >>> https://patchwork.ozlabs.org/patch/823158/ >> >>> U-boot already has a set of devicetree binding additions: >>> https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings >> >>> The patch in question wants to ab(use) the regulator-name property for >>> driver instance binding. In my opinion this is not going to fly, as >>> boards are free to define the names. This either sees no use other than >>> as a dirty workaround for dts files that aren't following the PMIC >>> regulator bindings (regulator node names should follow well defined, >>> identifying names), or results in divergence of the DT files. >> >> One meta issue I'm seeing here is that the u-boot people appear to have >> their own divergent copy of some of the binding documents. > > Putting on my U-Boot hat now, it's mostly unintentional and something in > general (yes, the initial topic here is not such an example) we try and > avoid, or use u-boot, as the prefix on as it's something that had been > previously rejected or deemed inappropriate to be in the upstream > version of the binding. > > But perhaps it's time to try and force the issue again, given what Rob > and others have said in other parts of the thread. 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. 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. Andrew ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 23:28 ` Andrew Turner 0 siblings, 0 replies; 126+ messages in thread From: Andrew Turner @ 2017-10-18 23:28 UTC (permalink / raw) To: Tom Rini Cc: Mark Brown, Chen-Yu Tsai, Grant Likely, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, Andy Gross, David Gibson, Lucas Stach > On 18 Oct 2017, at 18:59, Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote: > > On Wed, Oct 18, 2017 at 12:09:58PM +0100, Mark Brown wrote: >> On Wed, Oct 18, 2017 at 06:35:24PM +0800, Chen-Yu Tsai wrote: >> >>> I'd like to add something on the topic of non-Linux projects. In this >>> case it's diverging DT bindings from U-boot: >> >>> https://patchwork.ozlabs.org/patch/823158/ >> >>> U-boot already has a set of devicetree binding additions: >>> https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings >> >>> The patch in question wants to ab(use) the regulator-name property for >>> driver instance binding. In my opinion this is not going to fly, as >>> boards are free to define the names. This either sees no use other than >>> as a dirty workaround for dts files that aren't following the PMIC >>> regulator bindings (regulator node names should follow well defined, >>> identifying names), or results in divergence of the DT files. >> >> One meta issue I'm seeing here is that the u-boot people appear to have >> their own divergent copy of some of the binding documents. > > Putting on my U-Boot hat now, it's mostly unintentional and something in > general (yes, the initial topic here is not such an example) we try and > avoid, or use u-boot, as the prefix on as it's something that had been > previously rejected or deemed inappropriate to be in the upstream > version of the binding. > > But perhaps it's time to try and force the issue again, given what Rob > and others have said in other parts of the thread. 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. 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. Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 23:28 ` Andrew Turner 0 siblings, 0 replies; 126+ messages in thread From: Andrew Turner @ 2017-10-18 23:28 UTC (permalink / raw) To: Tom Rini Cc: Mark Brown, Chen-Yu Tsai, Grant Likely, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, Andy Gross, David Gibson, Lucas Stach > On 18 Oct 2017, at 18:59, Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote: > > On Wed, Oct 18, 2017 at 12:09:58PM +0100, Mark Brown wrote: >> On Wed, Oct 18, 2017 at 06:35:24PM +0800, Chen-Yu Tsai wrote: >> >>> I'd like to add something on the topic of non-Linux projects. In this >>> case it's diverging DT bindings from U-boot: >> >>> https://patchwork.ozlabs.org/patch/823158/ >> >>> U-boot already has a set of devicetree binding additions: >>> https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings >> >>> The patch in question wants to ab(use) the regulator-name property for >>> driver instance binding. In my opinion this is not going to fly, as >>> boards are free to define the names. This either sees no use other than >>> as a dirty workaround for dts files that aren't following the PMIC >>> regulator bindings (regulator node names should follow well defined, >>> identifying names), or results in divergence of the DT files. >> >> One meta issue I'm seeing here is that the u-boot people appear to have >> their own divergent copy of some of the binding documents. > > Putting on my U-Boot hat now, it's mostly unintentional and something in > general (yes, the initial topic here is not such an example) we try and > avoid, or use u-boot, as the prefix on as it's something that had been > previously rejected or deemed inappropriate to be in the upstream > version of the binding. > > But perhaps it's time to try and force the issue again, given what Rob > and others have said in other parts of the thread. >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. 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. Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 23:53 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-18 23:53 UTC (permalink / raw) To: Andrew Turner Cc: Tom Rini, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, devicetree, David Gibson On Wed, Oct 18, 2017 at 6:28 PM, Andrew Turner <andrew@fubar.geek.nz> wrote: > >> On 18 Oct 2017, at 18:59, Tom Rini <trini@konsulko.com> wrote: >> >> On Wed, Oct 18, 2017 at 12:09:58PM +0100, Mark Brown wrote: >>> On Wed, Oct 18, 2017 at 06:35:24PM +0800, Chen-Yu Tsai wrote: >>> >>>> I'd like to add something on the topic of non-Linux projects. In this >>>> case it's diverging DT bindings from U-boot: >>> >>>> https://patchwork.ozlabs.org/patch/823158/ >>> >>>> U-boot already has a set of devicetree binding additions: >>>> https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings >>> >>>> The patch in question wants to ab(use) the regulator-name property for >>>> driver instance binding. In my opinion this is not going to fly, as >>>> boards are free to define the names. This either sees no use other than >>>> as a dirty workaround for dts files that aren't following the PMIC >>>> regulator bindings (regulator node names should follow well defined, >>>> identifying names), or results in divergence of the DT files. >>> >>> One meta issue I'm seeing here is that the u-boot people appear to have >>> their own divergent copy of some of the binding documents. >> >> Putting on my U-Boot hat now, it's mostly unintentional and something in >> general (yes, the initial topic here is not such an example) we try and >> avoid, or use u-boot, as the prefix on as it's something that had been >> previously rejected or deemed inappropriate to be in the upstream >> version of the binding. >> >> But perhaps it's time to try and force the issue again, given what Rob >> and others have said in other parts of the thread. > > 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?, ? Rob [1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 23:53 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-18 23:53 UTC (permalink / raw) To: Andrew Turner Cc: Tom Rini, Mark Brown, Chen-Yu Tsai, Grant Likely, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, Andy Gross, David Gibson, Lucas Stach On Wed, Oct 18, 2017 at 6:28 PM, Andrew Turner <andrew-/GQUgJ3qWXsIvnNNuaVxrw@public.gmane.org> wrote: > >> On 18 Oct 2017, at 18:59, Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote: >> >> On Wed, Oct 18, 2017 at 12:09:58PM +0100, Mark Brown wrote: >>> On Wed, Oct 18, 2017 at 06:35:24PM +0800, Chen-Yu Tsai wrote: >>> >>>> I'd like to add something on the topic of non-Linux projects. In this >>>> case it's diverging DT bindings from U-boot: >>> >>>> https://patchwork.ozlabs.org/patch/823158/ >>> >>>> U-boot already has a set of devicetree binding additions: >>>> https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings >>> >>>> The patch in question wants to ab(use) the regulator-name property for >>>> driver instance binding. In my opinion this is not going to fly, as >>>> boards are free to define the names. This either sees no use other than >>>> as a dirty workaround for dts files that aren't following the PMIC >>>> regulator bindings (regulator node names should follow well defined, >>>> identifying names), or results in divergence of the DT files. >>> >>> One meta issue I'm seeing here is that the u-boot people appear to have >>> their own divergent copy of some of the binding documents. >> >> Putting on my U-Boot hat now, it's mostly unintentional and something in >> general (yes, the initial topic here is not such an example) we try and >> avoid, or use u-boot, as the prefix on as it's something that had been >> previously rejected or deemed inappropriate to be in the upstream >> version of the binding. >> >> But perhaps it's time to try and force the issue again, given what Rob >> and others have said in other parts of the thread. > > 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?, ? Rob [1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-18 23:53 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-18 23:53 UTC (permalink / raw) To: Andrew Turner Cc: Tom Rini, Mark Brown, Chen-Yu Tsai, Grant Likely, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, Andy Gross, David Gibson, Lucas Stach On Wed, Oct 18, 2017 at 6:28 PM, Andrew Turner <andrew-/GQUgJ3qWXsIvnNNuaVxrw@public.gmane.org> wrote: > >> On 18 Oct 2017, at 18:59, Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote: >> >> On Wed, Oct 18, 2017 at 12:09:58PM +0100, Mark Brown wrote: >>> On Wed, Oct 18, 2017 at 06:35:24PM +0800, Chen-Yu Tsai wrote: >>> >>>> I'd like to add something on the topic of non-Linux projects. In this >>>> case it's diverging DT bindings from U-boot: >>> >>>> https://patchwork.ozlabs.org/patch/823158/ >>> >>>> U-boot already has a set of devicetree binding additions: >>>> https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings >>> >>>> The patch in question wants to ab(use) the regulator-name property for >>>> driver instance binding. In my opinion this is not going to fly, as >>>> boards are free to define the names. This either sees no use other than >>>> as a dirty workaround for dts files that aren't following the PMIC >>>> regulator bindings (regulator node names should follow well defined, >>>> identifying names), or results in divergence of the DT files. >>> >>> One meta issue I'm seeing here is that the u-boot people appear to have >>> their own divergent copy of some of the binding documents. >> >> Putting on my U-Boot hat now, it's mostly unintentional and something in >> general (yes, the initial topic here is not such an example) we try and >> avoid, or use u-boot, as the prefix on as it's something that had been >> previously rejected or deemed inappropriate to be in the upstream >> version of the binding. >> >> But perhaps it's time to try and force the issue again, given what Rob >> and others have said in other parts of the thread. > > 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?, ? Rob [1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-19 14:00 ` Alexandre Torgue 0 siblings, 0 replies; 126+ messages in thread From: Alexandre Torgue @ 2017-10-19 14:00 UTC (permalink / raw) To: Rob Herring, Andrew Turner, Grant Likely Cc: Tom Rini, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, devicetree, David Gibson 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: >> >>> On 18 Oct 2017, at 18:59, Tom Rini <trini@konsulko.com> wrote: >>> >>> On Wed, Oct 18, 2017 at 12:09:58PM +0100, Mark Brown wrote: >>>> On Wed, Oct 18, 2017 at 06:35:24PM +0800, Chen-Yu Tsai wrote: >>>> >>>>> I'd like to add something on the topic of non-Linux projects. In this >>>>> case it's diverging DT bindings from U-boot: >>>> >>>>> https://patchwork.ozlabs.org/patch/823158/ >>>> >>>>> U-boot already has a set of devicetree binding additions: >>>>> https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings >>>> >>>>> The patch in question wants to ab(use) the regulator-name property for >>>>> driver instance binding. In my opinion this is not going to fly, as >>>>> boards are free to define the names. This either sees no use other than >>>>> as a dirty workaround for dts files that aren't following the PMIC >>>>> regulator bindings (regulator node names should follow well defined, >>>>> identifying names), or results in divergence of the DT files. >>>> >>>> One meta issue I'm seeing here is that the u-boot people appear to have >>>> their own divergent copy of some of the binding documents. >>> >>> Putting on my U-Boot hat now, it's mostly unintentional and something in >>> general (yes, the initial topic here is not such an example) we try and >>> avoid, or use u-boot, as the prefix on as it's something that had been >>> previously rejected or deemed inappropriate to be in the upstream >>> version of the binding. >>> >>> But perhaps it's time to try and force the issue again, given what Rob >>> and others have said in other parts of the thread. >> >> 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 ? -->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 ? 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. By using this external repo, it would be maybe easier to integrate changes for other components than Linux Kernel ? 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 ...). 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. Regards Alex > > Rob > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-19 14:00 ` Alexandre Torgue 0 siblings, 0 replies; 126+ messages in thread From: Alexandre Torgue @ 2017-10-19 14:00 UTC (permalink / raw) To: Rob Herring, Andrew Turner, Grant Likely Cc: Tom Rini, Mark Brown, Chen-Yu Tsai, Grant Likely, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, Andy Gross, David Gibson, Lucas Stach Hi Rob, On 10/19/2017 01:53 AM, Rob Herring wrote: > On Wed, Oct 18, 2017 at 6:28 PM, Andrew Turner <andrew-/GQUgJ3qWXsIvnNNuaVxrw@public.gmane.org> wrote: >> >>> On 18 Oct 2017, at 18:59, Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote: >>> >>> On Wed, Oct 18, 2017 at 12:09:58PM +0100, Mark Brown wrote: >>>> On Wed, Oct 18, 2017 at 06:35:24PM +0800, Chen-Yu Tsai wrote: >>>> >>>>> I'd like to add something on the topic of non-Linux projects. In this >>>>> case it's diverging DT bindings from U-boot: >>>> >>>>> https://patchwork.ozlabs.org/patch/823158/ >>>> >>>>> U-boot already has a set of devicetree binding additions: >>>>> https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings >>>> >>>>> The patch in question wants to ab(use) the regulator-name property for >>>>> driver instance binding. In my opinion this is not going to fly, as >>>>> boards are free to define the names. This either sees no use other than >>>>> as a dirty workaround for dts files that aren't following the PMIC >>>>> regulator bindings (regulator node names should follow well defined, >>>>> identifying names), or results in divergence of the DT files. >>>> >>>> One meta issue I'm seeing here is that the u-boot people appear to have >>>> their own divergent copy of some of the binding documents. >>> >>> Putting on my U-Boot hat now, it's mostly unintentional and something in >>> general (yes, the initial topic here is not such an example) we try and >>> avoid, or use u-boot, as the prefix on as it's something that had been >>> previously rejected or deemed inappropriate to be in the upstream >>> version of the binding. >>> >>> But perhaps it's time to try and force the issue again, given what Rob >>> and others have said in other parts of the thread. >> >> 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 ? -->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 ? 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. By using this external repo, it would be maybe easier to integrate changes for other components than Linux Kernel ? 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 ...). 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. Regards Alex > > Rob > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-19 14:00 ` Alexandre Torgue 0 siblings, 0 replies; 126+ messages in thread From: Alexandre Torgue @ 2017-10-19 14:00 UTC (permalink / raw) To: Rob Herring, Andrew Turner, Grant Likely Cc: Tom Rini, Mark Brown, Chen-Yu Tsai, Grant Likely, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, Andy Gross, David Gibson, Lucas Stach Hi Rob, On 10/19/2017 01:53 AM, Rob Herring wrote: > On Wed, Oct 18, 2017 at 6:28 PM, Andrew Turner <andrew-/GQUgJ3qWXsIvnNNuaVxrw@public.gmane.org> wrote: >> >>> On 18 Oct 2017, at 18:59, Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote: >>> >>> On Wed, Oct 18, 2017 at 12:09:58PM +0100, Mark Brown wrote: >>>> On Wed, Oct 18, 2017 at 06:35:24PM +0800, Chen-Yu Tsai wrote: >>>> >>>>> I'd like to add something on the topic of non-Linux projects. In this >>>>> case it's diverging DT bindings from U-boot: >>>> >>>>> https://patchwork.ozlabs.org/patch/823158/ >>>> >>>>> U-boot already has a set of devicetree binding additions: >>>>> https://github.com/u-boot/u-boot/tree/master/doc/device-tree-bindings >>>> >>>>> The patch in question wants to ab(use) the regulator-name property for >>>>> driver instance binding. In my opinion this is not going to fly, as >>>>> boards are free to define the names. This either sees no use other than >>>>> as a dirty workaround for dts files that aren't following the PMIC >>>>> regulator bindings (regulator node names should follow well defined, >>>>> identifying names), or results in divergence of the DT files. >>>> >>>> One meta issue I'm seeing here is that the u-boot people appear to have >>>> their own divergent copy of some of the binding documents. >>> >>> Putting on my U-Boot hat now, it's mostly unintentional and something in >>> general (yes, the initial topic here is not such an example) we try and >>> avoid, or use u-boot, as the prefix on as it's something that had been >>> previously rejected or deemed inappropriate to be in the upstream >>> version of the binding. >>> >>> But perhaps it's time to try and force the issue again, given what Rob >>> and others have said in other parts of the thread. >> >> 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 ? -->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 ? 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. By using this external repo, it would be maybe easier to integrate changes for other components than Linux Kernel ? 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 ...). 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. Regards Alex > > Rob > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-19 14:59 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-19 14:59 UTC (permalink / raw) To: Alexandre Torgue Cc: Tom Rini, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andrew Turner, Andy Gross, Grant Likely, Lucas Stach, devicetree, David Gibson 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. > 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 ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-19 14:59 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-19 14:59 UTC (permalink / raw) To: Alexandre Torgue Cc: Andrew Turner, Grant Likely, Tom Rini, Mark Brown, Chen-Yu Tsai, Grant Likely, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, Andy Gross, David Gibson, Lucas Stach On Thu, Oct 19, 2017 at 9:00 AM, Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org> 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-/GQUgJ3qWXsIvnNNuaVxrw@public.gmane.org> >> 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-19 14:59 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-19 14:59 UTC (permalink / raw) To: Alexandre Torgue Cc: Andrew Turner, Grant Likely, Tom Rini, Mark Brown, Chen-Yu Tsai, Grant Likely, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, Andy Gross, David Gibson, Lucas Stach On Thu, Oct 19, 2017 at 9:00 AM, Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org> 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-/GQUgJ3qWXsIvnNNuaVxrw@public.gmane.org> >> 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-19 18:46 ` Frank Rowand 0 siblings, 0 replies; 126+ messages in thread From: Frank Rowand @ 2017-10-19 18:46 UTC (permalink / raw) To: Rob Herring, Alexandre Torgue Cc: Tom Rini, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andrew Turner, Grant Likely, devicetree, Andy Gross, David Gibson, Lucas Stach 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: $ 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 > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-19 18:46 ` Frank Rowand 0 siblings, 0 replies; 126+ messages in thread From: Frank Rowand @ 2017-10-19 18:46 UTC (permalink / raw) To: Rob Herring, Alexandre Torgue Cc: Tom Rini, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, Andrew Turner, Andy Gross, Grant Likely, Lucas Stach, devicetree-u79uwXL29TY76Z2rM5mHXA, David Gibson On 10/19/17 07:59, Rob Herring wrote: > On Thu, Oct 19, 2017 at 9:00 AM, Alexandre Torgue > <alexandre.torgue-qxv4g6HH51o@public.gmane.org> 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-/GQUgJ3qWXsIvnNNuaVxrw@public.gmane.org> >>> 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: $ 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-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-19 18:46 ` Frank Rowand 0 siblings, 0 replies; 126+ messages in thread From: Frank Rowand @ 2017-10-19 18:46 UTC (permalink / raw) To: Rob Herring, Alexandre Torgue Cc: Tom Rini, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, Andrew Turner, Andy Gross, Grant Likely, Lucas Stach, devicetree-u79uwXL29TY76Z2rM5mHXA, David Gibson On 10/19/17 07:59, Rob Herring wrote: > On Thu, Oct 19, 2017 at 9:00 AM, Alexandre Torgue > <alexandre.torgue-qxv4g6HH51o@public.gmane.org> 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-/GQUgJ3qWXsIvnNNuaVxrw@public.gmane.org> >>> 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: $ 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-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-20 9:55 ` Alexandre Torgue 0 siblings, 0 replies; 126+ messages in thread From: Alexandre Torgue @ 2017-10-20 9:55 UTC (permalink / raw) To: Frank Rowand, Rob Herring Cc: Tom Rini, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andrew Turner, Grant Likely, devicetree, Andy Gross, David Gibson, Lucas Stach 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 >> > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-20 9:55 ` Alexandre Torgue 0 siblings, 0 replies; 126+ messages in thread From: Alexandre Torgue @ 2017-10-20 9:55 UTC (permalink / raw) To: Frank Rowand, Rob Herring Cc: Tom Rini, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, Andrew Turner, Andy Gross, Grant Likely, Lucas Stach, devicetree-u79uwXL29TY76Z2rM5mHXA, David Gibson 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-qxv4g6HH51o@public.gmane.org> 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-/GQUgJ3qWXsIvnNNuaVxrw@public.gmane.org> >>>> 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-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org >> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss >> > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-20 9:55 ` Alexandre Torgue 0 siblings, 0 replies; 126+ messages in thread From: Alexandre Torgue @ 2017-10-20 9:55 UTC (permalink / raw) To: Frank Rowand, Rob Herring Cc: Tom Rini, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, Andrew Turner, Andy Gross, Grant Likely, Lucas Stach, devicetree-u79uwXL29TY76Z2rM5mHXA, David Gibson 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-qxv4g6HH51o@public.gmane.org> 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-/GQUgJ3qWXsIvnNNuaVxrw@public.gmane.org> >>>> 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-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org >> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss >> > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-20 10:01 ` David Gibson 0 siblings, 0 replies; 126+ messages in thread From: David Gibson @ 2017-10-20 10:01 UTC (permalink / raw) To: Alexandre Torgue Cc: Rob Herring, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andrew Turner, Grant Likely, devicetree, Andy Gross, Tom Rini, Lucas Stach [-- Attachment #1: Type: text/plain, Size: 8427 bytes --] 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@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) 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-20 10:01 ` David Gibson 0 siblings, 0 replies; 126+ messages in thread From: David Gibson @ 2017-10-20 10:01 UTC (permalink / raw) To: Alexandre Torgue Cc: Frank Rowand, Rob Herring, Tom Rini, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, Andrew Turner, Andy Gross, Grant Likely, Lucas Stach, devicetree-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 8513 bytes --] 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-qxv4g6HH51o@public.gmane.org> 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-/GQUgJ3qWXt9iftTYHNiNg@public.gmane.org.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) 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-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-20 13:37 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-20 13:37 UTC (permalink / raw) To: Alexandre Torgue Cc: Tom Rini, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andrew Turner, Grant Likely, devicetree, Andy Gross, David Gibson, Lucas Stach On Fri, Oct 20, 2017 at 4:55 AM, Alexandre Torgue <alexandre.torgue@st.com> 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@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: >>> >>> >>> [...] >>>> -->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). Ah, you mean removing nodes without a phandle reference, not phandles themselves. There's no way dtc could do that because no reference doesn't equate to unused. For example, there's no phandle reference to the /memory node, but that is for sure needed. We would have to add some annotation to nodes that could be removed if unused. This could be some source annotation (/delete-if-unused/), some extension to status property, or some new property. Another option would be just mark all those nodes disabled and then postprocess the dtb to mark them okay if they have a phandle property and delete the node if not. Rob ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-20 13:37 ` Rob Herring 0 siblings, 0 replies; 126+ messages in thread From: Rob Herring @ 2017-10-20 13:37 UTC (permalink / raw) To: Alexandre Torgue Cc: Frank Rowand, Tom Rini, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, Andrew Turner, Andy Gross, Grant Likely, Lucas Stach, devicetree-u79uwXL29TY76Z2rM5mHXA, David Gibson On Fri, Oct 20, 2017 at 4:55 AM, Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org> 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-qxv4g6HH51o@public.gmane.org> 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-/GQUgJ3qWXsIvnNNuaVxrw@public.gmane.org> >>>>> wrote: >>> >>> >>> [...] >>>> -->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). Ah, you mean removing nodes without a phandle reference, not phandles themselves. There's no way dtc could do that because no reference doesn't equate to unused. For example, there's no phandle reference to the /memory node, but that is for sure needed. We would have to add some annotation to nodes that could be removed if unused. This could be some source annotation (/delete-if-unused/), some extension to status property, or some new property. Another option would be just mark all those nodes disabled and then postprocess the dtb to mark them okay if they have a phandle property and delete the node if not. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-22 8:25 ` David Gibson 0 siblings, 0 replies; 126+ messages in thread From: David Gibson @ 2017-10-22 8:25 UTC (permalink / raw) To: Rob Herring Cc: Tom Rini, Kumar Gala, Alexandre Torgue, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andrew Turner, Grant Likely, devicetree, Andy Gross, Lucas Stach [-- Attachment #1: Type: text/plain, Size: 2975 bytes --] On Fri, Oct 20, 2017 at 08:37:26AM -0500, Rob Herring wrote: > On Fri, Oct 20, 2017 at 4:55 AM, Alexandre Torgue > <alexandre.torgue@st.com> 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@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: > >>> > >>> > >>> [...] > > >>>> -->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). > > Ah, you mean removing nodes without a phandle reference, not phandles > themselves. > > There's no way dtc could do that because no reference doesn't equate > to unused. For example, there's no phandle reference to the /memory > node, but that is for sure needed. We would have to add some > annotation to nodes that could be removed if unused. This could be > some source annotation (/delete-if-unused/), some extension to status > property, or some new property. > > Another option would be just mark all those nodes disabled and then > postprocess the dtb to mark them okay if they have a phandle property > and delete the node if not. I'd be happy enough to merge a patch to dtc which added an option to strip disabled nodes. It's also pretty easy to do using libfdt (see fdt_next_node() and fdt_del_node()). -- 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 #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-22 8:25 ` David Gibson 0 siblings, 0 replies; 126+ messages in thread From: David Gibson @ 2017-10-22 8:25 UTC (permalink / raw) To: Rob Herring Cc: Alexandre Torgue, Frank Rowand, Tom Rini, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, Andrew Turner, Andy Gross, Grant Likely, Lucas Stach, devicetree-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 3046 bytes --] On Fri, Oct 20, 2017 at 08:37:26AM -0500, Rob Herring wrote: > On Fri, Oct 20, 2017 at 4:55 AM, Alexandre Torgue > <alexandre.torgue-qxv4g6HH51o@public.gmane.org> 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-qxv4g6HH51o@public.gmane.org> 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-/GQUgJ3qWXtrsDanXnWFnQ@public.gmane.orgz> > >>>>> wrote: > >>> > >>> > >>> [...] > > >>>> -->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). > > Ah, you mean removing nodes without a phandle reference, not phandles > themselves. > > There's no way dtc could do that because no reference doesn't equate > to unused. For example, there's no phandle reference to the /memory > node, but that is for sure needed. We would have to add some > annotation to nodes that could be removed if unused. This could be > some source annotation (/delete-if-unused/), some extension to status > property, or some new property. > > Another option would be just mark all those nodes disabled and then > postprocess the dtb to mark them okay if they have a phandle property > and delete the node if not. I'd be happy enough to merge a patch to dtc which added an option to strip disabled nodes. It's also pretty easy to do using libfdt (see fdt_next_node() and fdt_del_node()). -- 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 #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-20 13:47 ` Alexandre Torgue 0 siblings, 0 replies; 126+ messages in thread From: Alexandre Torgue @ 2017-10-20 13:47 UTC (permalink / raw) To: Rob Herring Cc: Tom Rini, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andrew Turner, Andy Gross, Grant Likely, Lucas Stach, devicetree, David Gibson 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 > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-20 13:47 ` Alexandre Torgue 0 siblings, 0 replies; 126+ messages in thread From: Alexandre Torgue @ 2017-10-20 13:47 UTC (permalink / raw) To: Rob Herring Cc: Andrew Turner, Grant Likely, Tom Rini, Mark Brown, Chen-Yu Tsai, Grant Likely, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, 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 > <alexandre.torgue-qxv4g6HH51o@public.gmane.org> 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-/GQUgJ3qWXsIvnNNuaVxrw@public.gmane.org> >>> 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 > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-20 13:47 ` Alexandre Torgue 0 siblings, 0 replies; 126+ messages in thread From: Alexandre Torgue @ 2017-10-20 13:47 UTC (permalink / raw) To: Rob Herring Cc: Andrew Turner, Grant Likely, Tom Rini, Mark Brown, Chen-Yu Tsai, Grant Likely, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, 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 > <alexandre.torgue-qxv4g6HH51o@public.gmane.org> 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-/GQUgJ3qWXsIvnNNuaVxrw@public.gmane.org> >>> 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 > ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) 2017-10-18 17:59 ` Tom Rini @ 2017-10-19 0:04 ` Mark Brown -1 siblings, 0 replies; 126+ messages in thread From: Mark Brown @ 2017-10-19 0:04 UTC (permalink / raw) To: Tom Rini Cc: Rob Herring, Kumar Gala, ksummit-discuss, devicetree, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson [-- Attachment #1: Type: text/plain, Size: 955 bytes --] On Wed, Oct 18, 2017 at 01:59:10PM -0400, Tom Rini wrote: > On Wed, Oct 18, 2017 at 12:09:58PM +0100, Mark Brown wrote: > > One meta issue I'm seeing here is that the u-boot people appear to have > > their own divergent copy of some of the binding documents. > Putting on my U-Boot hat now, it's mostly unintentional and something in > general (yes, the initial topic here is not such an example) we try and > avoid, or use u-boot, as the prefix on as it's something that had been > previously rejected or deemed inappropriate to be in the upstream > version of the binding. Yeah, I didn't get the impression this was at all intentional. Unfortunately it's a shared property with divergent definitions rather than something u-boot specific that got added. > But perhaps it's time to try and force the issue again, given what Rob > and others have said in other parts of the thread. Yeah, if DT is going to be cross project we need to do better here. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-19 0:04 ` Mark Brown 0 siblings, 0 replies; 126+ messages in thread From: Mark Brown @ 2017-10-19 0:04 UTC (permalink / raw) To: Tom Rini Cc: Chen-Yu Tsai, Grant Likely, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, devicetree-u79uwXL29TY76Z2rM5mHXA, Andy Gross, David Gibson, Lucas Stach [-- Attachment #1: Type: text/plain, Size: 955 bytes --] On Wed, Oct 18, 2017 at 01:59:10PM -0400, Tom Rini wrote: > On Wed, Oct 18, 2017 at 12:09:58PM +0100, Mark Brown wrote: > > One meta issue I'm seeing here is that the u-boot people appear to have > > their own divergent copy of some of the binding documents. > Putting on my U-Boot hat now, it's mostly unintentional and something in > general (yes, the initial topic here is not such an example) we try and > avoid, or use u-boot, as the prefix on as it's something that had been > previously rejected or deemed inappropriate to be in the upstream > version of the binding. Yeah, I didn't get the impression this was at all intentional. Unfortunately it's a shared property with divergent definitions rather than something u-boot specific that got added. > But perhaps it's time to try and force the issue again, given what Rob > and others have said in other parts of the thread. Yeah, if DT is going to be cross project we need to do better here. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-19 11:10 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-19 11:10 UTC (permalink / raw) To: devicetree, devicetree-spec, ksummit-discuss, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand Hi folks, I've flushed out the schedule. It is still a draft, but I've got names against the topics and put them into a rough order. If your name is listed below, it means I've asked you to frame the problem and moderate discussion for that topic. I'm *not* asking you to present unless the topic is specifically listed as a presentation. If you want you can have a slide or two, but you must get them to me by Tuesday evening, 24 October. I want to keep the time fiddling with projectors to a minimum. Originally this was intended as a 1/2 day workshop, but given that we have the room for the full day, I've spread things out to give a bit more time for hallway track. I can also move things around if need be to avoid conflicts with the maintainers summit and KVM forum. The maintenance topics are in the afternoon under the assumption that there are folks in the maintainers summit who will want to attend. The tooling and schema topics are in the morning. I've also tried really hard to preserve the breaks and lunch to give time for hallway discussion. As always, none of this is set in stone. If you have any specific conflicts or concerns then please say so. Cheers, g. ==Morning== 9:30 Welcome and Schedule bashing (0:10) (Grant Likely) ===Tooling & Schema=== 9:40 (5min) Encoding and Schema checking: Framing the problem (Grant Likely) 9:45 (15min) DT YAML encoding overview (Pantelis Antoniou - presentation) 10:00 (20min) YAML encoding discussion 10:20 (15min) DT Schema format - option 1 (Pantelis Antoniou - presentation) 10:35 (15min) DT Schema format - option 2 (Grant Likely - presentation) 10:50 (20min) DT Schema discussion - what should go in the spec? 11:10-11:50 [Break] ===Runtime usage=== 11:50 (20min) Code Generation from DT (Kumar Gala - presentation) 12:10 (20min) Runtime memory consumption (Rob Herring - presentation) 12:30-14:30 [Lunch] ==Afternoon== ===DTS maintenance issues=== 14:30 (15min) Overlay maintenance plan (Bill Mills) 14:45 (15min) Avoiding duplicate descriptions (Thomas Petazzoni) 15:00 (15min) Criteria for accepting board files 15:15 (15min) Location for maintaining bindings - how to handle 'foreign bindings' (Boris Brezillon) 15:30 (15min) Sharing Generic bindings (Geert Uytterhoeven) 15:45 (15min) ABI Stability (Lucas Stach) 16:00-16:30 [break and overflow discussion] 16:30 (20min) DT health check (Ben Dooks) 16:50 (15min) devicetree.org update (Grant Likely) 17:05 (15min) EBBR Discussion (Grant Likely) 17:20 Closing and feedback On Mon, Oct 9, 2017 at 9:39 PM, Grant Likely <grant.likely@secretlab.ca> wrote: > Kernel Summit is now just over 2 weeks away and it is time to pull > together the schedule for the Devicetree workshop. Originally I > planned on just an afternoon, but I've got the room for the whole day, > so I've got a lot of flexibility on the schedule. Unscheduled time can > be used for hacking. > > Date: 26 Oct 2017 > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > Location: Athens room - Hilton Prague > > If you plan to attend, make sure you update your OSSunmitE/ELCE > registration to include the DT Workshop (log in to access and modify > your registration): > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > Here is my current list of topics in no particular order, including > the topic moderator: > > Runtime memory consumption (Rob Herring) > Overlay maintenance plan (TBC) > Stable ABI for devicetree (TBC) > DT YAML encoding (Pantelis Antoniou) > DT Schema format - option 1 (Pantelis Antoniou) > DT Schema format - option 2 (Grant Likely) > Sharing Generic bindings (TBC) > devicetree.org update (Grant) > > Reply to this email if you want to propose another topic. > > Reply privately if there is a particular topic you want to attend but > you are unable to be there in the morning or afternoon. I'll put the > actual agenda together a week out from the event. > > g. ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-19 11:10 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-19 11:10 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand Hi folks, I've flushed out the schedule. It is still a draft, but I've got names against the topics and put them into a rough order. If your name is listed below, it means I've asked you to frame the problem and moderate discussion for that topic. I'm *not* asking you to present unless the topic is specifically listed as a presentation. If you want you can have a slide or two, but you must get them to me by Tuesday evening, 24 October. I want to keep the time fiddling with projectors to a minimum. Originally this was intended as a 1/2 day workshop, but given that we have the room for the full day, I've spread things out to give a bit more time for hallway track. I can also move things around if need be to avoid conflicts with the maintainers summit and KVM forum. The maintenance topics are in the afternoon under the assumption that there are folks in the maintainers summit who will want to attend. The tooling and schema topics are in the morning. I've also tried really hard to preserve the breaks and lunch to give time for hallway discussion. As always, none of this is set in stone. If you have any specific conflicts or concerns then please say so. Cheers, g. ==Morning== 9:30 Welcome and Schedule bashing (0:10) (Grant Likely) ===Tooling & Schema=== 9:40 (5min) Encoding and Schema checking: Framing the problem (Grant Likely) 9:45 (15min) DT YAML encoding overview (Pantelis Antoniou - presentation) 10:00 (20min) YAML encoding discussion 10:20 (15min) DT Schema format - option 1 (Pantelis Antoniou - presentation) 10:35 (15min) DT Schema format - option 2 (Grant Likely - presentation) 10:50 (20min) DT Schema discussion - what should go in the spec? 11:10-11:50 [Break] ===Runtime usage=== 11:50 (20min) Code Generation from DT (Kumar Gala - presentation) 12:10 (20min) Runtime memory consumption (Rob Herring - presentation) 12:30-14:30 [Lunch] ==Afternoon== ===DTS maintenance issues=== 14:30 (15min) Overlay maintenance plan (Bill Mills) 14:45 (15min) Avoiding duplicate descriptions (Thomas Petazzoni) 15:00 (15min) Criteria for accepting board files 15:15 (15min) Location for maintaining bindings - how to handle 'foreign bindings' (Boris Brezillon) 15:30 (15min) Sharing Generic bindings (Geert Uytterhoeven) 15:45 (15min) ABI Stability (Lucas Stach) 16:00-16:30 [break and overflow discussion] 16:30 (20min) DT health check (Ben Dooks) 16:50 (15min) devicetree.org update (Grant Likely) 17:05 (15min) EBBR Discussion (Grant Likely) 17:20 Closing and feedback On Mon, Oct 9, 2017 at 9:39 PM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > Kernel Summit is now just over 2 weeks away and it is time to pull > together the schedule for the Devicetree workshop. Originally I > planned on just an afternoon, but I've got the room for the whole day, > so I've got a lot of flexibility on the schedule. Unscheduled time can > be used for hacking. > > Date: 26 Oct 2017 > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > Location: Athens room - Hilton Prague > > If you plan to attend, make sure you update your OSSunmitE/ELCE > registration to include the DT Workshop (log in to access and modify > your registration): > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > Here is my current list of topics in no particular order, including > the topic moderator: > > Runtime memory consumption (Rob Herring) > Overlay maintenance plan (TBC) > Stable ABI for devicetree (TBC) > DT YAML encoding (Pantelis Antoniou) > DT Schema format - option 1 (Pantelis Antoniou) > DT Schema format - option 2 (Grant Likely) > Sharing Generic bindings (TBC) > devicetree.org update (Grant) > > Reply to this email if you want to propose another topic. > > Reply privately if there is a particular topic you want to attend but > you are unable to be there in the morning or afternoon. I'll put the > actual agenda together a week out from the event. > > g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-24 7:37 ` Boris Brezillon 0 siblings, 0 replies; 126+ messages in thread From: Boris Brezillon @ 2017-10-24 7:37 UTC (permalink / raw) To: Grant Likely Cc: devicetree, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson Hi Grant, On Thu, 19 Oct 2017 12:10:31 +0100 Grant Likely <grant.likely@secretlab.ca> wrote: > Hi folks, > > I've flushed out the schedule. It is still a draft, but I've got names > against the topics and put them into a rough order. > > If your name is listed below, it means I've asked you to frame the > problem and moderate discussion for that topic. I'm *not* asking you > to present unless the topic is specifically listed as a presentation. > If you want you can have a slide or two, but you must get them to me > by Tuesday evening, 24 October. I want to keep the time fiddling with > projectors to a minimum. > > Originally this was intended as a 1/2 day workshop, but given that we > have the room for the full day, I've spread things out to give a bit > more time for hallway track. I can also move things around if need be > to avoid conflicts with the maintainers summit and KVM forum. The > maintenance topics are in the afternoon under the assumption that > there are folks in the maintainers summit who will want to attend. The > tooling and schema topics are in the morning. I've also tried really > hard to preserve the breaks and lunch to give time for hallway > discussion. > > As always, none of this is set in stone. If you have any specific > conflicts or concerns then please say so. > > Cheers, > g. > > ==Morning== > 9:30 Welcome and Schedule bashing (0:10) (Grant Likely) > > ===Tooling & Schema=== > 9:40 (5min) Encoding and Schema checking: Framing the problem (Grant Likely) > 9:45 (15min) DT YAML encoding overview (Pantelis Antoniou - presentation) > 10:00 (20min) YAML encoding discussion > 10:20 (15min) DT Schema format - option 1 (Pantelis Antoniou - presentation) > 10:35 (15min) DT Schema format - option 2 (Grant Likely - presentation) > 10:50 (20min) DT Schema discussion - what should go in the spec? > > 11:10-11:50 [Break] > > ===Runtime usage=== > 11:50 (20min) Code Generation from DT (Kumar Gala - presentation) > 12:10 (20min) Runtime memory consumption (Rob Herring - presentation) > > 12:30-14:30 [Lunch] > > ==Afternoon== > ===DTS maintenance issues=== > 14:30 (15min) Overlay maintenance plan (Bill Mills) > 14:45 (15min) Avoiding duplicate descriptions (Thomas Petazzoni) > 15:00 (15min) Criteria for accepting board files > 15:15 (15min) Location for maintaining bindings - how to handle > 'foreign bindings' (Boris Brezillon) Sorry for late reply, but I will not attend the Device Tree workshop. I still think the problem should be discussed and you seemed to have an opinion on this, so maybe you can lead the discussion. Regards, Boris > 15:30 (15min) Sharing Generic bindings (Geert Uytterhoeven) > 15:45 (15min) ABI Stability (Lucas Stach) > > 16:00-16:30 [break and overflow discussion] > > 16:30 (20min) DT health check (Ben Dooks) > 16:50 (15min) devicetree.org update (Grant Likely) > 17:05 (15min) EBBR Discussion (Grant Likely) > 17:20 Closing and feedback > > > On Mon, Oct 9, 2017 at 9:39 PM, Grant Likely <grant.likely@secretlab.ca> wrote: > > Kernel Summit is now just over 2 weeks away and it is time to pull > > together the schedule for the Devicetree workshop. Originally I > > planned on just an afternoon, but I've got the room for the whole day, > > so I've got a lot of flexibility on the schedule. Unscheduled time can > > be used for hacking. > > > > Date: 26 Oct 2017 > > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > > Location: Athens room - Hilton Prague > > > > If you plan to attend, make sure you update your OSSunmitE/ELCE > > registration to include the DT Workshop (log in to access and modify > > your registration): > > > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > > > Here is my current list of topics in no particular order, including > > the topic moderator: > > > > Runtime memory consumption (Rob Herring) > > Overlay maintenance plan (TBC) > > Stable ABI for devicetree (TBC) > > DT YAML encoding (Pantelis Antoniou) > > DT Schema format - option 1 (Pantelis Antoniou) > > DT Schema format - option 2 (Grant Likely) > > Sharing Generic bindings (TBC) > > devicetree.org update (Grant) > > > > Reply to this email if you want to propose another topic. > > > > Reply privately if there is a particular topic you want to attend but > > you are unable to be there in the morning or afternoon. I'll put the > > actual agenda together a week out from the event. > > > > g. > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-24 7:37 ` Boris Brezillon 0 siblings, 0 replies; 126+ messages in thread From: Boris Brezillon @ 2017-10-24 7:37 UTC (permalink / raw) To: Grant Likely Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand Hi Grant, On Thu, 19 Oct 2017 12:10:31 +0100 Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > Hi folks, > > I've flushed out the schedule. It is still a draft, but I've got names > against the topics and put them into a rough order. > > If your name is listed below, it means I've asked you to frame the > problem and moderate discussion for that topic. I'm *not* asking you > to present unless the topic is specifically listed as a presentation. > If you want you can have a slide or two, but you must get them to me > by Tuesday evening, 24 October. I want to keep the time fiddling with > projectors to a minimum. > > Originally this was intended as a 1/2 day workshop, but given that we > have the room for the full day, I've spread things out to give a bit > more time for hallway track. I can also move things around if need be > to avoid conflicts with the maintainers summit and KVM forum. The > maintenance topics are in the afternoon under the assumption that > there are folks in the maintainers summit who will want to attend. The > tooling and schema topics are in the morning. I've also tried really > hard to preserve the breaks and lunch to give time for hallway > discussion. > > As always, none of this is set in stone. If you have any specific > conflicts or concerns then please say so. > > Cheers, > g. > > ==Morning== > 9:30 Welcome and Schedule bashing (0:10) (Grant Likely) > > ===Tooling & Schema=== > 9:40 (5min) Encoding and Schema checking: Framing the problem (Grant Likely) > 9:45 (15min) DT YAML encoding overview (Pantelis Antoniou - presentation) > 10:00 (20min) YAML encoding discussion > 10:20 (15min) DT Schema format - option 1 (Pantelis Antoniou - presentation) > 10:35 (15min) DT Schema format - option 2 (Grant Likely - presentation) > 10:50 (20min) DT Schema discussion - what should go in the spec? > > 11:10-11:50 [Break] > > ===Runtime usage=== > 11:50 (20min) Code Generation from DT (Kumar Gala - presentation) > 12:10 (20min) Runtime memory consumption (Rob Herring - presentation) > > 12:30-14:30 [Lunch] > > ==Afternoon== > ===DTS maintenance issues=== > 14:30 (15min) Overlay maintenance plan (Bill Mills) > 14:45 (15min) Avoiding duplicate descriptions (Thomas Petazzoni) > 15:00 (15min) Criteria for accepting board files > 15:15 (15min) Location for maintaining bindings - how to handle > 'foreign bindings' (Boris Brezillon) Sorry for late reply, but I will not attend the Device Tree workshop. I still think the problem should be discussed and you seemed to have an opinion on this, so maybe you can lead the discussion. Regards, Boris > 15:30 (15min) Sharing Generic bindings (Geert Uytterhoeven) > 15:45 (15min) ABI Stability (Lucas Stach) > > 16:00-16:30 [break and overflow discussion] > > 16:30 (20min) DT health check (Ben Dooks) > 16:50 (15min) devicetree.org update (Grant Likely) > 17:05 (15min) EBBR Discussion (Grant Likely) > 17:20 Closing and feedback > > > On Mon, Oct 9, 2017 at 9:39 PM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > > Kernel Summit is now just over 2 weeks away and it is time to pull > > together the schedule for the Devicetree workshop. Originally I > > planned on just an afternoon, but I've got the room for the whole day, > > so I've got a lot of flexibility on the schedule. Unscheduled time can > > be used for hacking. > > > > Date: 26 Oct 2017 > > Time: 9:00am-5:30pm (Lunch from 12:30-2:30) > > Location: Athens room - Hilton Prague > > > > If you plan to attend, make sure you update your OSSunmitE/ELCE > > registration to include the DT Workshop (log in to access and modify > > your registration): > > > > https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= > > > > Here is my current list of topics in no particular order, including > > the topic moderator: > > > > Runtime memory consumption (Rob Herring) > > Overlay maintenance plan (TBC) > > Stable ABI for devicetree (TBC) > > DT YAML encoding (Pantelis Antoniou) > > DT Schema format - option 1 (Pantelis Antoniou) > > DT Schema format - option 2 (Grant Likely) > > Sharing Generic bindings (TBC) > > devicetree.org update (Grant) > > > > Reply to this email if you want to propose another topic. > > > > Reply privately if there is a particular topic you want to attend but > > you are unable to be there in the morning or afternoon. I'll put the > > actual agenda together a week out from the event. > > > > g. > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) 2017-10-24 7:37 ` Boris Brezillon @ 2017-10-25 14:40 ` Maxime Ripard -1 siblings, 0 replies; 126+ messages in thread From: Maxime Ripard @ 2017-10-25 14:40 UTC (permalink / raw) To: Boris Brezillon Cc: devicetree, Kumar Gala, ksummit-discuss, Rob Herring, devicetree-spec, Pantelis Antoniou, Andy Gross, David Gibson, Lucas Stach [-- Attachment #1: Type: text/plain, Size: 616 bytes --] On Tue, Oct 24, 2017 at 09:37:55AM +0200, Boris Brezillon wrote: > > 15:15 (15min) Location for maintaining bindings - how to handle > > 'foreign bindings' (Boris Brezillon) > > Sorry for late reply, but I will not attend the Device Tree workshop. > I still think the problem should be discussed and you seemed to have an > opinion on this, so maybe you can lead the discussion. I will be here though, so I can discuss this instead of Boris, we've been confronted to this recently as well. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-25 14:40 ` Maxime Ripard 0 siblings, 0 replies; 126+ messages in thread From: Maxime Ripard @ 2017-10-25 14:40 UTC (permalink / raw) To: Boris Brezillon Cc: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, Kumar Gala, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, Rob Herring, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou, Andy Gross, Lucas Stach, David Gibson [-- Attachment #1: Type: text/plain, Size: 616 bytes --] On Tue, Oct 24, 2017 at 09:37:55AM +0200, Boris Brezillon wrote: > > 15:15 (15min) Location for maintaining bindings - how to handle > > 'foreign bindings' (Boris Brezillon) > > Sorry for late reply, but I will not attend the Device Tree workshop. > I still think the problem should be discussed and you seemed to have an > opinion on this, so maybe you can lead the discussion. I will be here though, so I can discuss this instead of Boris, we've been confronted to this recently as well. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-26 5:47 ` Frank Rowand 0 siblings, 0 replies; 126+ messages in thread From: Frank Rowand @ 2017-10-26 5:47 UTC (permalink / raw) To: Grant Likely, devicetree, devicetree-spec, ksummit-discuss, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring On 10/19/17 04:10, Grant Likely wrote: > Hi folks, > > I've flushed out the schedule. It is still a draft, but I've got names > against the topics and put them into a rough order. > > If your name is listed below, it means I've asked you to frame the > problem and moderate discussion for that topic. I'm *not* asking you > to present unless the topic is specifically listed as a presentation. > If you want you can have a slide or two, but you must get them to me > by Tuesday evening, 24 October. I want to keep the time fiddling with > projectors to a minimum. > > Originally this was intended as a 1/2 day workshop, but given that we > have the room for the full day, I've spread things out to give a bit > more time for hallway track. I can also move things around if need be > to avoid conflicts with the maintainers summit and KVM forum. The > maintenance topics are in the afternoon under the assumption that > there are folks in the maintainers summit who will want to attend. The > tooling and schema topics are in the morning. I've also tried really > hard to preserve the breaks and lunch to give time for hallway > discussion. > > As always, none of this is set in stone. If you have any specific > conflicts or concerns then please say so. > > Cheers, > g. > > ==Morning== > 9:30 Welcome and Schedule bashing (0:10) (Grant Likely) > > ===Tooling & Schema=== > 9:40 (5min) Encoding and Schema checking: Framing the problem (Grant Likely) > 9:45 (15min) DT YAML encoding overview (Pantelis Antoniou - presentation) > 10:00 (20min) YAML encoding discussion > 10:20 (15min) DT Schema format - option 1 (Pantelis Antoniou - presentation) > 10:35 (15min) DT Schema format - option 2 (Grant Likely - presentation) > 10:50 (20min) DT Schema discussion - what should go in the spec? > < snip > I want to share some information behind a topic that I will bring up during the discussion. One thing that is important in the validation is being able to report the source file and location in the source file of any validation warning or error. I was working on how to generate that information from dtc when run in the mode of source input and source output. Due to my total lack of knowledge of yacc, and attempt to provide a solution without truly learning yacc, my efforts were somewhat extended, and then I ran out of free time, and moved the project to my "todo" list, where it still sits. The main concept I want to share is having an agreed upon format of how to represent location information for the device tree source file that is the result of having processed cpp and processed the /include/ directives. The following attached email is an example of the concept (that was aimed at humans trying to resolve compile errors or understand what file had to be modified to change the final value of an item such as a property, which might be specified and re-specified multiple times. So it is not a proposal of what would be a good format for the validation tools, but instead a concrete example for people to understand the concept. -------- Forwarded Message -------- Subject: [RFC PATCH v6 0/2] dtc: dts source location annotation Date: Fri, 02 Oct 2015 21:44:05 -0700 From: Frank Rowand <frowand.list@gmail.com> Reply-To: frowand.list@gmail.com To: david@gibson.dropbear.id.au, jdl@jdl.com, devicetree-compiler@vger.kernel.org Proof of concept patch. Annotates input source file and line number of nodes and properties as comments in output .dts file when --annotate flag is supplied. A common dts source file convention is for a system .dts file to include default SOC and/or device .dtsi files and then add additional system specific properties or over-ride property values from the .dtsi files. It can be a time consuming and error prone exercise to determine exactly what nodes, properties, and property values are in the final .dtb binary blob and where they originated. Modify the dtc compiler to read a (possibly cpp pre-processed) .dts file and for the output .dts annotate each node and property with the corresponding source location. As an example, one device tree node for the dragonboard in the Linux kernel source tree (hand edited to remove leading path components) is: ----- long format ----- sdhci@f9824900 { /* qcom-apq8074-dragonboard.dts:14.3-18.5 */ compatible = "qcom,sdhci-msm-v4"; /* qcom-msm8974.dtsi:240.4-37 */ reg = <0xf9824900 0x11c 0xf9824000 0x800>; /* qcom-msm8974.dtsi:241.4-49 */ reg-names = "hc_mem", "core_mem"; /* qcom-msm8974.dtsi:242.4-37 */ interrupts = <0x0 0x7b 0x0 0x0 0x8a 0x0>; /* qcom-msm8974.dtsi:243.4-38 */ interrupt-names = "hc_irq", "pwr_irq"; /* qcom-msm8974.dtsi:244.4-42 */ clocks = <0xd 0xd8 0xd 0xd7>; /* qcom-msm8974.dtsi:245.4-36 */ clock-names = "core", "iface"; /* qcom-msm8974.dtsi:246.4-34 */ status = "ok"; /* qcom-apq8074-dragonboard.dts:17.4-18 */ bus-width = <0x8>; /* qcom-apq8074-dragonboard.dts:15.4-20 */ non-removable; /* qcom-apq8074-dragonboard.dts:16.4-18 */ }; /* qcom-apq8074-dragonboard.dts:14.3-18.5 */ ----- short format ----- sdhci@f9824900 { /* qcom-apq8074-dragonboard.dts:14 */ compatible = "qcom,sdhci-msm-v4"; /* qcom-msm8974.dtsi:240 */ reg = <0xf9824900 0x11c 0xf9824000 0x800>; /* qcom-msm8974.dtsi:241 */ reg-names = "hc_mem", "core_mem"; /* qcom-msm8974.dtsi:242 */ interrupts = <0x0 0x7b 0x0 0x0 0x8a 0x0>; /* qcom-msm8974.dtsi:243 */ interrupt-names = "hc_irq", "pwr_irq"; /* qcom-msm8974.dtsi:244 */ clocks = <0xd 0xd8 0xd 0xd7>; /* qcom-msm8974.dtsi:245 */ clock-names = "core", "iface"; /* qcom-msm8974.dtsi:246 */ status = "ok"; /* qcom-apq8074-dragonboard.dts:17 */ bus-width = <0x8>; /* qcom-apq8074-dragonboard.dts:15 */ non-removable; /* qcom-apq8074-dragonboard.dts:16 */ }; /* qcom-apq8074-dragonboard.dts:18 */ qcom-apq8074-dragonboard.dts: - last referenced the sdhci node - changed the value of the "status" property from "disabled" to "ok" - added two properties, "bus-width" and "non-removable" qcom-msm8974.dtsi: - initially set the value the "status" property to "disabled" (not visible in the annotated .dts) - provided all of the other property values When the dtc compiler is run within the Linux kernel build system, the path of the source files will be the full absolute path, just as seen for gcc warnings and errors. I always trim away the path leading up to the Linux kernel source tree by passing the kernel build output through a sed pipe. I have done the same to the above example to remove the excessive verbosity in the source paths. Implementation notes: - Added new function srcpos_string_short() which is similar to srcpos_string() but limits the location information to one line number. The fuller output of srcpos_string() adds noise to the annotation which (in my opinion) is not especially useful in this specific context. The one downside to this choice is that the column numbers for multiple properties on the same input line will not be reported. This is unlikely to be an issue unless a .dts contains all of the properties on a single line (which might be the case for a machine generated .dts). I do not think that the extra noise for the common case justifies handling this case. - The source location of each node and property is saved in the respective node or property during the parse phase because the source location information from current_srcfile is no longer available when the final values are written out from dt_to_source() and the functions that it calls. - A check is added to dtc.c to ensure that input and output format are both device tree source. An alternate choice would be to turn off the --annotate flag if either the input file or the output file is not device tree source. In the alternate case, the disabling of --annotate could be silent or a warning could be issued. TODO: - Update "make check" tests to reflect review comments. - Test against a wider set of .dts files. There are some rules that I did not test extensively (and some rules, such as delete that I did not test at all in this version). - Change the --annotate option to choose either long or short format. - Fix location for: devicetree: '/' nodedef Changes from v5: - Add more pointer checking to patch 1. - Change from two to one srcpos fields in struct node. Move the logic to choose begin or end to the annotation print logic for the case of short location format. - Move the setting of srcpos back to name_node() and build_prop() instead of adding new functions to save that information. - Patch 2 reports the location in long format (beginning and end of the object). Adding patch 3 changes for format to short (the current source line only). . ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-26 5:47 ` Frank Rowand 0 siblings, 0 replies; 126+ messages in thread From: Frank Rowand @ 2017-10-26 5:47 UTC (permalink / raw) To: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring On 10/19/17 04:10, Grant Likely wrote: > Hi folks, > > I've flushed out the schedule. It is still a draft, but I've got names > against the topics and put them into a rough order. > > If your name is listed below, it means I've asked you to frame the > problem and moderate discussion for that topic. I'm *not* asking you > to present unless the topic is specifically listed as a presentation. > If you want you can have a slide or two, but you must get them to me > by Tuesday evening, 24 October. I want to keep the time fiddling with > projectors to a minimum. > > Originally this was intended as a 1/2 day workshop, but given that we > have the room for the full day, I've spread things out to give a bit > more time for hallway track. I can also move things around if need be > to avoid conflicts with the maintainers summit and KVM forum. The > maintenance topics are in the afternoon under the assumption that > there are folks in the maintainers summit who will want to attend. The > tooling and schema topics are in the morning. I've also tried really > hard to preserve the breaks and lunch to give time for hallway > discussion. > > As always, none of this is set in stone. If you have any specific > conflicts or concerns then please say so. > > Cheers, > g. > > ==Morning== > 9:30 Welcome and Schedule bashing (0:10) (Grant Likely) > > ===Tooling & Schema=== > 9:40 (5min) Encoding and Schema checking: Framing the problem (Grant Likely) > 9:45 (15min) DT YAML encoding overview (Pantelis Antoniou - presentation) > 10:00 (20min) YAML encoding discussion > 10:20 (15min) DT Schema format - option 1 (Pantelis Antoniou - presentation) > 10:35 (15min) DT Schema format - option 2 (Grant Likely - presentation) > 10:50 (20min) DT Schema discussion - what should go in the spec? > < snip > I want to share some information behind a topic that I will bring up during the discussion. One thing that is important in the validation is being able to report the source file and location in the source file of any validation warning or error. I was working on how to generate that information from dtc when run in the mode of source input and source output. Due to my total lack of knowledge of yacc, and attempt to provide a solution without truly learning yacc, my efforts were somewhat extended, and then I ran out of free time, and moved the project to my "todo" list, where it still sits. The main concept I want to share is having an agreed upon format of how to represent location information for the device tree source file that is the result of having processed cpp and processed the /include/ directives. The following attached email is an example of the concept (that was aimed at humans trying to resolve compile errors or understand what file had to be modified to change the final value of an item such as a property, which might be specified and re-specified multiple times. So it is not a proposal of what would be a good format for the validation tools, but instead a concrete example for people to understand the concept. -------- Forwarded Message -------- Subject: [RFC PATCH v6 0/2] dtc: dts source location annotation Date: Fri, 02 Oct 2015 21:44:05 -0700 From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Reply-To: frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org To: david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org, jdl-CYoMK+44s/E@public.gmane.org, devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Proof of concept patch. Annotates input source file and line number of nodes and properties as comments in output .dts file when --annotate flag is supplied. A common dts source file convention is for a system .dts file to include default SOC and/or device .dtsi files and then add additional system specific properties or over-ride property values from the .dtsi files. It can be a time consuming and error prone exercise to determine exactly what nodes, properties, and property values are in the final .dtb binary blob and where they originated. Modify the dtc compiler to read a (possibly cpp pre-processed) .dts file and for the output .dts annotate each node and property with the corresponding source location. As an example, one device tree node for the dragonboard in the Linux kernel source tree (hand edited to remove leading path components) is: ----- long format ----- sdhci@f9824900 { /* qcom-apq8074-dragonboard.dts:14.3-18.5 */ compatible = "qcom,sdhci-msm-v4"; /* qcom-msm8974.dtsi:240.4-37 */ reg = <0xf9824900 0x11c 0xf9824000 0x800>; /* qcom-msm8974.dtsi:241.4-49 */ reg-names = "hc_mem", "core_mem"; /* qcom-msm8974.dtsi:242.4-37 */ interrupts = <0x0 0x7b 0x0 0x0 0x8a 0x0>; /* qcom-msm8974.dtsi:243.4-38 */ interrupt-names = "hc_irq", "pwr_irq"; /* qcom-msm8974.dtsi:244.4-42 */ clocks = <0xd 0xd8 0xd 0xd7>; /* qcom-msm8974.dtsi:245.4-36 */ clock-names = "core", "iface"; /* qcom-msm8974.dtsi:246.4-34 */ status = "ok"; /* qcom-apq8074-dragonboard.dts:17.4-18 */ bus-width = <0x8>; /* qcom-apq8074-dragonboard.dts:15.4-20 */ non-removable; /* qcom-apq8074-dragonboard.dts:16.4-18 */ }; /* qcom-apq8074-dragonboard.dts:14.3-18.5 */ ----- short format ----- sdhci@f9824900 { /* qcom-apq8074-dragonboard.dts:14 */ compatible = "qcom,sdhci-msm-v4"; /* qcom-msm8974.dtsi:240 */ reg = <0xf9824900 0x11c 0xf9824000 0x800>; /* qcom-msm8974.dtsi:241 */ reg-names = "hc_mem", "core_mem"; /* qcom-msm8974.dtsi:242 */ interrupts = <0x0 0x7b 0x0 0x0 0x8a 0x0>; /* qcom-msm8974.dtsi:243 */ interrupt-names = "hc_irq", "pwr_irq"; /* qcom-msm8974.dtsi:244 */ clocks = <0xd 0xd8 0xd 0xd7>; /* qcom-msm8974.dtsi:245 */ clock-names = "core", "iface"; /* qcom-msm8974.dtsi:246 */ status = "ok"; /* qcom-apq8074-dragonboard.dts:17 */ bus-width = <0x8>; /* qcom-apq8074-dragonboard.dts:15 */ non-removable; /* qcom-apq8074-dragonboard.dts:16 */ }; /* qcom-apq8074-dragonboard.dts:18 */ qcom-apq8074-dragonboard.dts: - last referenced the sdhci node - changed the value of the "status" property from "disabled" to "ok" - added two properties, "bus-width" and "non-removable" qcom-msm8974.dtsi: - initially set the value the "status" property to "disabled" (not visible in the annotated .dts) - provided all of the other property values When the dtc compiler is run within the Linux kernel build system, the path of the source files will be the full absolute path, just as seen for gcc warnings and errors. I always trim away the path leading up to the Linux kernel source tree by passing the kernel build output through a sed pipe. I have done the same to the above example to remove the excessive verbosity in the source paths. Implementation notes: - Added new function srcpos_string_short() which is similar to srcpos_string() but limits the location information to one line number. The fuller output of srcpos_string() adds noise to the annotation which (in my opinion) is not especially useful in this specific context. The one downside to this choice is that the column numbers for multiple properties on the same input line will not be reported. This is unlikely to be an issue unless a .dts contains all of the properties on a single line (which might be the case for a machine generated .dts). I do not think that the extra noise for the common case justifies handling this case. - The source location of each node and property is saved in the respective node or property during the parse phase because the source location information from current_srcfile is no longer available when the final values are written out from dt_to_source() and the functions that it calls. - A check is added to dtc.c to ensure that input and output format are both device tree source. An alternate choice would be to turn off the --annotate flag if either the input file or the output file is not device tree source. In the alternate case, the disabling of --annotate could be silent or a warning could be issued. TODO: - Update "make check" tests to reflect review comments. - Test against a wider set of .dts files. There are some rules that I did not test extensively (and some rules, such as delete that I did not test at all in this version). - Change the --annotate option to choose either long or short format. - Fix location for: devicetree: '/' nodedef Changes from v5: - Add more pointer checking to patch 1. - Change from two to one srcpos fields in struct node. Move the logic to choose begin or end to the annotation print logic for the case of short location format. - Move the setting of srcpos back to name_node() and build_prop() instead of adding new functions to save that information. - Patch 2 reports the location in long format (beginning and end of the object). Adding patch 3 changes for format to short (the current source line only). . ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-26 7:17 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-26 7:17 UTC (permalink / raw) To: devicetree, devicetree-spec, ksummit-discuss, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand To anyone who is here at ELCE/OSSummit and wants to join the DT workshop, but wasn't able to register: Just show up. There is lots of space in the room. We start at 9:30 this morning. g. On Thu, Oct 19, 2017 at 1:10 PM, Grant Likely <grant.likely@secretlab.ca> wrote: > Hi folks, > > I've flushed out the schedule. It is still a draft, but I've got names > against the topics and put them into a rough order. > > If your name is listed below, it means I've asked you to frame the > problem and moderate discussion for that topic. I'm *not* asking you > to present unless the topic is specifically listed as a presentation. > If you want you can have a slide or two, but you must get them to me > by Tuesday evening, 24 October. I want to keep the time fiddling with > projectors to a minimum. > > Originally this was intended as a 1/2 day workshop, but given that we > have the room for the full day, I've spread things out to give a bit > more time for hallway track. I can also move things around if need be > to avoid conflicts with the maintainers summit and KVM forum. The > maintenance topics are in the afternoon under the assumption that > there are folks in the maintainers summit who will want to attend. The > tooling and schema topics are in the morning. I've also tried really > hard to preserve the breaks and lunch to give time for hallway > discussion. > > As always, none of this is set in stone. If you have any specific > conflicts or concerns then please say so. > > Cheers, > g. > > ==Morning== > 9:30 Welcome and Schedule bashing (0:10) (Grant Likely) > > ===Tooling & Schema=== > 9:40 (5min) Encoding and Schema checking: Framing the problem (Grant Likely) > 9:45 (15min) DT YAML encoding overview (Pantelis Antoniou - presentation) > 10:00 (20min) YAML encoding discussion > 10:20 (15min) DT Schema format - option 1 (Pantelis Antoniou - presentation) > 10:35 (15min) DT Schema format - option 2 (Grant Likely - presentation) > 10:50 (20min) DT Schema discussion - what should go in the spec? > > 11:10-11:50 [Break] > > ===Runtime usage=== > 11:50 (20min) Code Generation from DT (Kumar Gala - presentation) > 12:10 (20min) Runtime memory consumption (Rob Herring - presentation) > > 12:30-14:30 [Lunch] > > ==Afternoon== > ===DTS maintenance issues=== > 14:30 (15min) Overlay maintenance plan (Bill Mills) > 14:45 (15min) Avoiding duplicate descriptions (Thomas Petazzoni) > 15:00 (15min) Criteria for accepting board files > 15:15 (15min) Location for maintaining bindings - how to handle > 'foreign bindings' (Boris Brezillon) > 15:30 (15min) Sharing Generic bindings (Geert Uytterhoeven) > 15:45 (15min) ABI Stability (Lucas Stach) > > 16:00-16:30 [break and overflow discussion] > > 16:30 (20min) DT health check (Ben Dooks) > 16:50 (15min) devicetree.org update (Grant Likely) > 17:05 (15min) EBBR Discussion (Grant Likely) > 17:20 Closing and feedback > > > On Mon, Oct 9, 2017 at 9:39 PM, Grant Likely <grant.likely@secretlab.ca> wrote: >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. >> >> Reply privately if there is a particular topic you want to attend but >> you are unable to be there in the morning or afternoon. I'll put the >> actual agenda together a week out from the event. >> >> g. ^ permalink raw reply [flat|nested] 126+ messages in thread
* Re: Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) @ 2017-10-26 7:17 ` Grant Likely 0 siblings, 0 replies; 126+ messages in thread From: Grant Likely @ 2017-10-26 7:17 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA, devicetree-spec-u79uwXL29TY76Z2rM5mHXA, ksummit-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I, David Gibson, Julia Lawall, Pantelis Antoniou, Lucas Stach, Kumar Gala, Andy Gross, Rob Herring, Frank Rowand To anyone who is here at ELCE/OSSummit and wants to join the DT workshop, but wasn't able to register: Just show up. There is lots of space in the room. We start at 9:30 this morning. g. On Thu, Oct 19, 2017 at 1:10 PM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: > Hi folks, > > I've flushed out the schedule. It is still a draft, but I've got names > against the topics and put them into a rough order. > > If your name is listed below, it means I've asked you to frame the > problem and moderate discussion for that topic. I'm *not* asking you > to present unless the topic is specifically listed as a presentation. > If you want you can have a slide or two, but you must get them to me > by Tuesday evening, 24 October. I want to keep the time fiddling with > projectors to a minimum. > > Originally this was intended as a 1/2 day workshop, but given that we > have the room for the full day, I've spread things out to give a bit > more time for hallway track. I can also move things around if need be > to avoid conflicts with the maintainers summit and KVM forum. The > maintenance topics are in the afternoon under the assumption that > there are folks in the maintainers summit who will want to attend. The > tooling and schema topics are in the morning. I've also tried really > hard to preserve the breaks and lunch to give time for hallway > discussion. > > As always, none of this is set in stone. If you have any specific > conflicts or concerns then please say so. > > Cheers, > g. > > ==Morning== > 9:30 Welcome and Schedule bashing (0:10) (Grant Likely) > > ===Tooling & Schema=== > 9:40 (5min) Encoding and Schema checking: Framing the problem (Grant Likely) > 9:45 (15min) DT YAML encoding overview (Pantelis Antoniou - presentation) > 10:00 (20min) YAML encoding discussion > 10:20 (15min) DT Schema format - option 1 (Pantelis Antoniou - presentation) > 10:35 (15min) DT Schema format - option 2 (Grant Likely - presentation) > 10:50 (20min) DT Schema discussion - what should go in the spec? > > 11:10-11:50 [Break] > > ===Runtime usage=== > 11:50 (20min) Code Generation from DT (Kumar Gala - presentation) > 12:10 (20min) Runtime memory consumption (Rob Herring - presentation) > > 12:30-14:30 [Lunch] > > ==Afternoon== > ===DTS maintenance issues=== > 14:30 (15min) Overlay maintenance plan (Bill Mills) > 14:45 (15min) Avoiding duplicate descriptions (Thomas Petazzoni) > 15:00 (15min) Criteria for accepting board files > 15:15 (15min) Location for maintaining bindings - how to handle > 'foreign bindings' (Boris Brezillon) > 15:30 (15min) Sharing Generic bindings (Geert Uytterhoeven) > 15:45 (15min) ABI Stability (Lucas Stach) > > 16:00-16:30 [break and overflow discussion] > > 16:30 (20min) DT health check (Ben Dooks) > 16:50 (15min) devicetree.org update (Grant Likely) > 17:05 (15min) EBBR Discussion (Grant Likely) > 17:20 Closing and feedback > > > On Mon, Oct 9, 2017 at 9:39 PM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote: >> Kernel Summit is now just over 2 weeks away and it is time to pull >> together the schedule for the Devicetree workshop. Originally I >> planned on just an afternoon, but I've got the room for the whole day, >> so I've got a lot of flexibility on the schedule. Unscheduled time can >> be used for hacking. >> >> Date: 26 Oct 2017 >> Time: 9:00am-5:30pm (Lunch from 12:30-2:30) >> Location: Athens room - Hilton Prague >> >> If you plan to attend, make sure you update your OSSunmitE/ELCE >> registration to include the DT Workshop (log in to access and modify >> your registration): >> >> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID= >> >> Here is my current list of topics in no particular order, including >> the topic moderator: >> >> Runtime memory consumption (Rob Herring) >> Overlay maintenance plan (TBC) >> Stable ABI for devicetree (TBC) >> DT YAML encoding (Pantelis Antoniou) >> DT Schema format - option 1 (Pantelis Antoniou) >> DT Schema format - option 2 (Grant Likely) >> Sharing Generic bindings (TBC) >> devicetree.org update (Grant) >> >> Reply to this email if you want to propose another topic. >> >> Reply privately if there is a particular topic you want to attend but >> you are unable to be there in the morning or afternoon. I'll put the >> actual agenda together a week out from the event. >> >> g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 126+ messages in thread
end of thread, other threads:[~2017-10-26 7:18 UTC | newest] Thread overview: 126+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-10-09 20:39 [Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017) Grant Likely 2017-10-09 20:39 ` Grant Likely 2017-10-14 12:34 ` [Ksummit-discuss] " Thomas Petazzoni 2017-10-14 12:34 ` Thomas Petazzoni 2017-10-17 13:30 ` Grant Likely 2017-10-17 13:30 ` Grant Likely 2017-10-16 5:36 ` Michal Simek 2017-10-16 5:36 ` Michal Simek 2017-10-16 14:11 ` Rob Herring 2017-10-16 14:11 ` Rob Herring 2017-10-18 14:04 ` Michal Simek 2017-10-18 14:04 ` Michal Simek 2017-10-18 14:28 ` Andre Przywara 2017-10-18 14:28 ` Andre Przywara 2017-10-18 15:32 ` Rob Herring 2017-10-18 15:32 ` Rob Herring 2017-10-18 16:05 ` Andre Przywara 2017-10-18 16:05 ` Andre Przywara 2017-10-18 16:20 ` Pantelis Antoniou 2017-10-18 16:20 ` Pantelis Antoniou 2017-10-16 16:40 ` Ben Dooks 2017-10-16 16:40 ` Ben Dooks 2017-10-16 18:44 ` Heiko Stübner 2017-10-16 18:44 ` Heiko Stübner 2017-10-16 19:45 ` Rob Herring 2017-10-16 19:45 ` Rob Herring 2017-10-17 13:38 ` Grant Likely 2017-10-17 13:38 ` Grant Likely 2017-10-17 23:45 ` Frank Rowand 2017-10-17 23:45 ` Frank Rowand 2017-10-17 13:32 ` Grant Likely 2017-10-17 13:32 ` Grant Likely 2017-10-18 10:08 ` Thomas Petazzoni 2017-10-18 10:08 ` Thomas Petazzoni 2017-10-16 16:42 ` Ben Dooks 2017-10-16 16:42 ` Ben Dooks 2017-10-17 13:34 ` Grant Likely 2017-10-17 13:34 ` Grant Likely 2017-10-17 9:48 ` Boris Brezillon 2017-10-17 9:48 ` Boris Brezillon 2017-10-17 13:21 ` Tom Rini 2017-10-17 13:21 ` Tom Rini 2017-10-17 13:48 ` Grant Likely 2017-10-17 13:48 ` Grant Likely 2017-10-17 16:21 ` Ian Lepore 2017-10-17 16:21 ` Ian Lepore 2017-10-17 17:02 ` Kumar Gala 2017-10-17 17:02 ` Kumar Gala 2017-10-17 17:24 ` Geert Uytterhoeven 2017-10-17 17:24 ` Geert Uytterhoeven 2017-10-17 17:24 ` Geert Uytterhoeven 2017-10-17 19:03 ` Bird, Timothy 2017-10-17 19:03 ` Bird, Timothy 2017-10-18 12:14 ` Grant Likely 2017-10-18 12:14 ` Grant Likely 2017-10-18 12:14 ` Grant Likely 2017-10-18 12:59 ` Pantelis Antoniou 2017-10-18 12:59 ` Pantelis Antoniou 2017-10-18 13:18 ` Alexandre Belloni 2017-10-18 13:18 ` Alexandre Belloni 2017-10-18 13:21 ` Geert Uytterhoeven 2017-10-18 13:21 ` Geert Uytterhoeven 2017-10-18 17:41 ` Bird, Timothy 2017-10-18 17:41 ` Bird, Timothy 2017-10-18 18:00 ` Rob Herring 2017-10-18 18:00 ` Rob Herring 2017-10-18 21:10 ` Alexandre Belloni 2017-10-18 21:10 ` Alexandre Belloni 2017-10-18 16:18 ` David Woodhouse 2017-10-18 16:18 ` David Woodhouse 2017-10-18 14:13 ` Rob Herring 2017-10-18 14:13 ` Rob Herring 2017-10-18 17:45 ` Bird, Timothy 2017-10-18 17:45 ` Bird, Timothy 2017-10-18 14:07 ` Kumar Gala 2017-10-18 14:07 ` Kumar Gala 2017-10-18 14:07 ` Kumar Gala 2017-10-17 17:25 ` Rob Herring 2017-10-17 17:25 ` Rob Herring 2017-10-18 10:11 ` Thomas Petazzoni 2017-10-18 10:11 ` Thomas Petazzoni 2017-10-18 10:35 ` Chen-Yu Tsai 2017-10-18 10:35 ` Chen-Yu Tsai 2017-10-18 11:09 ` Mark Brown 2017-10-18 11:09 ` Mark Brown 2017-10-18 17:59 ` Tom Rini 2017-10-18 17:59 ` Tom Rini 2017-10-18 23:28 ` Andrew Turner 2017-10-18 23:28 ` Andrew Turner 2017-10-18 23:28 ` Andrew Turner 2017-10-18 23:53 ` Rob Herring 2017-10-18 23:53 ` Rob Herring 2017-10-18 23:53 ` Rob Herring 2017-10-19 14:00 ` Alexandre Torgue 2017-10-19 14:00 ` Alexandre Torgue 2017-10-19 14:00 ` Alexandre Torgue 2017-10-19 14:59 ` Rob Herring 2017-10-19 14:59 ` Rob Herring 2017-10-19 14:59 ` Rob Herring 2017-10-19 18:46 ` Frank Rowand 2017-10-19 18:46 ` Frank Rowand 2017-10-19 18:46 ` Frank Rowand 2017-10-20 9:55 ` Alexandre Torgue 2017-10-20 9:55 ` Alexandre Torgue 2017-10-20 9:55 ` Alexandre Torgue 2017-10-20 10:01 ` David Gibson 2017-10-20 10:01 ` David Gibson 2017-10-20 13:37 ` Rob Herring 2017-10-20 13:37 ` Rob Herring 2017-10-22 8:25 ` David Gibson 2017-10-22 8:25 ` David Gibson 2017-10-20 13:47 ` Alexandre Torgue 2017-10-20 13:47 ` Alexandre Torgue 2017-10-20 13:47 ` Alexandre Torgue 2017-10-19 0:04 ` Mark Brown 2017-10-19 0:04 ` Mark Brown 2017-10-19 11:10 ` Grant Likely 2017-10-19 11:10 ` Grant Likely 2017-10-24 7:37 ` [Ksummit-discuss] " Boris Brezillon 2017-10-24 7:37 ` Boris Brezillon 2017-10-25 14:40 ` Maxime Ripard 2017-10-25 14:40 ` Maxime Ripard 2017-10-26 5:47 ` Frank Rowand 2017-10-26 5:47 ` Frank Rowand 2017-10-26 7:17 ` [Ksummit-discuss] " Grant Likely 2017-10-26 7:17 ` Grant Likely
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.