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