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

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

[Grant Likely]

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.

Devicetree Workshop at Kernel Summit Prague (26 Oct 2017)

[Grant Likely]

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

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

[Thomas Petazzoni]

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

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

[Thomas Petazzoni]

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

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

[Michal Simek]

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

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

[Michal Simek]

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

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

[Rob Herring]

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

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

[Rob Herring]

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

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

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

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

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

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

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

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

[Ben Dooks]

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

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

[Ben Dooks]

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

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

[Heiko Stübner]

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.

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

[Heiko Stübner]

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.

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

[Rob Herring]

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

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

[Rob Herring]

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

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

[Boris Brezillon]

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

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

[Boris Brezillon]

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

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

[Tom Rini]

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

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

[Tom Rini]

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

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

[Grant Likely]

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

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

[Grant Likely]

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

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

[Grant Likely]

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
>

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

[Grant Likely]

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
>

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

[Grant Likely]

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.

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

[Grant Likely]

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

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

[Grant Likely]

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.

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

[Grant Likely]

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

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

[Grant Likely]

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

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

[Grant Likely]

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

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

[Ian Lepore]

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

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

[Ian Lepore]

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

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

[Kumar Gala]

> 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

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

[Kumar Gala]

> 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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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

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

[Rob Herring]

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

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

[Rob Herring]

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

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

[Bird, Timothy]

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

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

[Bird, Timothy]

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

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

[Frank Rowand]

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

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

[Frank Rowand]

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

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

[Thomas Petazzoni]

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

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

[Thomas Petazzoni]

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

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

[Thomas Petazzoni]

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

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

[Thomas Petazzoni]

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

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

[Chen-Yu Tsai]

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

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

[Chen-Yu Tsai]

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

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

[Mark Brown]

[-- 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 --]

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

[Mark Brown]

[-- 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 --]

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

[Grant Likely]

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

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

[Grant Likely]

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

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

[Grant Likely]

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

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

[Pantelis Antoniou]

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

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

[Pantelis Antoniou]

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

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

[Alexandre Belloni]

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

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

[Alexandre Belloni]

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

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

[Geert Uytterhoeven]

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

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

[Geert Uytterhoeven]

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

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

[Michal Simek]

[-- 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 --]

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

[Michal Simek]

[-- 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 --]

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

[Kumar Gala]

> 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

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

[Kumar Gala]

> 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

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

[Kumar Gala]

> 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

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

[Rob Herring]

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

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

[Rob Herring]

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

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

[Andre Przywara]

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.

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

[Andre Przywara]

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

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

[Rob Herring]

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

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

[Rob Herring]

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

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

[Andre Przywara]

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
> 

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

[Andre Przywara]

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
> 

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

[David Woodhouse]

[-- 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 --]

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

[David Woodhouse]

[-- 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 --]

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

[Pantelis Antoniou]

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

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

[Pantelis Antoniou]

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

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

[Bird, Timothy]

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

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

[Bird, Timothy]

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

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

[Bird, Timothy]

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

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

[Bird, Timothy]

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

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

[Tom Rini]

[-- 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 --]

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

[Tom Rini]

[-- 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 --]

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

[Rob Herring]

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/

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

[Rob Herring]

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

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

[Alexandre Belloni]

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

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

[Alexandre Belloni]

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

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

[Andrew Turner]

> 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

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

[Andrew Turner]

> 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

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

[Andrew Turner]

> 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

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

[Rob Herring]

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/

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

[Rob Herring]

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/

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

[Rob Herring]

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/

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

[Mark Brown]

[-- 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 --]

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

[Mark Brown]

[-- 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 --]

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

[Grant Likely]

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.

Re: Devicetree Workshop at Kernel Summit Prague (26 Oct 2017)

[Grant Likely]

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

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

[Alexandre Torgue]

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
> 

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

[Alexandre Torgue]

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
> 

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

[Alexandre Torgue]

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
> 

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

[Rob Herring]

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

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

[Rob Herring]

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

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

[Rob Herring]

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

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

[Frank Rowand]

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
> 

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

[Frank Rowand]

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

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

[Frank Rowand]

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

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

[Alexandre Torgue]

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

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

[Alexandre Torgue]

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

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

[Alexandre Torgue]

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

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

[David Gibson]

[-- 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 --]

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

[David Gibson]

[-- 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 --]

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

[Rob Herring]

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

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

[Rob Herring]

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

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

[Alexandre Torgue]

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
> 

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

[Alexandre Torgue]

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
> 

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

[Alexandre Torgue]

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
> 

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

[David Gibson]

[-- 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 --]

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

[David Gibson]

[-- 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 --]

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

[Boris Brezillon]

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

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

[Boris Brezillon]

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

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

[Maxime Ripard]

[-- 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 --]

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

[Maxime Ripard]

[-- 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 --]

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

[Frank Rowand]

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

Re: Devicetree Workshop at Kernel Summit Prague (26 Oct 2017)

[Frank Rowand]

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

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

[Grant Likely]

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.

Re: Devicetree Workshop at Kernel Summit Prague (26 Oct 2017)

[Grant Likely]

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