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

Rob Herring robh at kernel.org
Mon Oct 16 19:45:59 UTC 2017


On Mon, Oct 16, 2017 at 11:40 AM, Ben Dooks <ben.dooks at 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


More information about the Ksummit-discuss mailing list