[Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017)
robh at kernel.org
Mon Oct 16 14:11:57 UTC 2017
On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr at monstr.eu> wrote:
> 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):
>> 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
> 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?
More information about the Ksummit-discuss