FW: Meeting notes: Planning around splitting devicetree data out of the Linux tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Arg, missed the CC to the devicetree-spec list.

----- Forwarded message from Steve McIntyre <steve.mcintyre@xxxxxxxxxx> -----

From: Steve McIntyre <steve.mcintyre@xxxxxxxxxx>
To: dte-all@xxxxxxxxxx
Cc: dan.handley@xxxxxxx, Mathieu Poirier <mathieu.poirier@xxxxxxxxxx>,
	broonie@xxxxxxxxxx
Date: Thu, 26 Sep 2019 18:07:30 +0100
Subject: Meeting notes: Planning around splitting devicetree data out of the
	Linux tree
User-Agent: Mutt/1.10.1 (2018-07-13)

Hi all,

A large group of us met yesterday at Linaro Connect in San Diego to
discuss this topic. I hope most people are on one of the two the
mailing lists here already - please forward if you think somebody is
not and should see this.

(probably incomplete) list of attendees
=======================================
Steve McIntyre, Arm/Linaro
Bill Fletcher, Linaro
Bruce Ashfield, Xilinx
Mark Brown, Arm
Stefano Stabellini, Xilinx
Arnd Bergmann, Linaro
Grant Likely, Arm
Mathieu Poirier, Linaro
Loic Pallardy, ST
???, Socionext

Notes
=====

Please correct me if you think I'm missed/mis-described something...

We believe that it's time to move arm and arm64 DT data out of the
kernel tree to a separate repo, on github. Arnd showed a graph showing
the number of dts files, grouped by architecture. Vast majority are
for arm/arm64, with a small number elsewhere. *Still* not all arm
platforms have moved across to DT totally (e.g. omap2).

What work needs to be done?

 * create repo (github.com/devicetree.org/dts)
 * move the dts files, bindings, and header files across *together* -
   they make no sense separately.

Is anybody else except Linux using the header files we have? not that
we know of.

As the first aim, we'd copy things from the external repo into the
kernel tree periodically - just like we do with dtc already. Later on,
we might revisit that decision.

if we move the DTS files out, would we still want to build them with
the kernel? Why? Should the kernel build sync things across
automatically at build time? Sometimes mips and ppc build the DTB
files into a bootable image format, so there is a dependency there for
those arches. Not for arm/arm64.

We have a prototype patchset for the kernel which would add support
for out-of-tree dts files. Needs re-evaluating, it's gone stale.

How would the kernel devs pick the right DTB from an external tree?
Worry about forwards/backwards compat. Follow the same release cadence
as the kernel for now, tag it matching? How do we keep it in sync?

Two different sets of versioning here - DT versioning, and Linux
versioning.

We should have tooling and data in separate repos. Common schema in
with tooling, device bindings in the data repo?

How do we keep DTS and drivers in sync between the two repos? In early
development, we will need maintainers of both repos to work together.

Currently not all the driver bindings changes are reviewed. This will
become more of a problem if we separate the data out. We need
commitment of responsive maintainers for the DT repo. We need to get
more people involved, spreading the load - that's a problem already.

So we do all arches, or just arm? Start with arm, iron out the
kinks. Once we're happy, move risc-v, ppc, etc. as/when their
maintainers care. There are a number of quiet arches with very few dts
files, as seen already. The SoC maintainers and Rob will clearly end
up maintaining the new tree to start with.

How do we do tagging etc.? Same release cadence as the kernel. Add a
-next style process. Also need to integrate with the linux-next
process? Probably not. kernelCI watches linux-next and does boot
testing. We should extend that to help us here.

Should we do automatic tagging to match the kernel releases, including
LTS? Would that make sense?

We will want to test the tip DT tree with other kernel releases.

How do we track which hash of the DT repo we want to use? We *could*
store it in the kernel, but that's not a great way to work.

We could tag using the Linux tags *and* the U-Boot tags *and* the DT
tags. Could even dump post-lopper [System DT] output in and tag *if we
want* to do that, but we probably don't - let's not store processed
output. If we're shipping tarballs of DTBs, then we might do that
there.

Testing should start tracking the hash of the DT repo alongside the
kernel tree. Should we get somebody to do a DT -next tree? Gives us a
complicated testing matrix for bisection etc. Get kernelCI to do two
tests for each kernel build - one with the previous release of the DT
branch, and one with current.

Headers will have to be cloned into the kernel tree to not block
device driver updates. Add a script to automate the update - pull
things from the dt repo and commit into kernel. Headers need to go
into the DT repo *first*, then people can pull the header update into
their tree before the driver updates. Must never be rebased, to make
things safe. Can mostly be automated. People may occasionally end up
making changes to the headers directly in -next, and this would
break. We'll just have to deal with that and fix things. Try to get
Linus to pull updates from the DT tree early, so that bindings will
come that way. Should be cleaner. Maybe some git request-pull noise to
come?

How much lives in the header files that doesn't need to be? Maybe
quite a bit.

Should the pull request process for headers also pull in the dts files
at the same point? Would be nice, but we don't have the same
"add-only" policy as for the header files so probably would not work.

We need to publicise this discussion and work, and engage with people
disagreeing or suggesting alternative ideas.

Olof might have more ideas that won't quite match this. Maybe keep
reference platforms in the kernel like with ppc?

Idea: start with a shadow process for a couple of cycles and make sure
that things are working before we go live with everything. Once that
works, pick a couple of platforms to start with. Get tooling organised
in the dt repo to validate that things are working. Choose a single
SoC and start working with that - which one? Arm reference platforms -
maybe not good, not enough changes there. stm32?

Actions
-------

 * Resurrect the external DT patch - Grant to prod
 * Arnd to discuss with Olof about his ideas
 * Set up a target tree on github (good for CI etc.) Grant will give
   Arnd access. Start with importing the dt-rebasing tree
 * broonie will get kernelCI to look at the new DT tree too
 * Stefano will check if the ZU+ is a good candidate for us to work
   with
 * Arm foundation model stuff is heading into LAVA soon. broonie to
   chase on that
 * Add CI - TF-A and U-Boot pulling from our DT tree and validating
   (overlap with System DT)
 * Don't break everyone!
 * Regular meetings:
   + Arnd to organise a session at ELC-E
   + We'll organise a (monthly?) sync-up

mailing list:

 boot-architecture? not ideal
 devicetree=spec? done (hence CC here!)

If I've missed anything here, please reply and correct me...

Cheers,

Steve

-- 
Steve McIntyre                                steve.mcintyre@xxxxxxxxxx
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs



----- End forwarded message -----
-- 
Steve McIntyre                                steve.mcintyre@xxxxxxxxxx
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs




[Index of Archives]     [Device Tree]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Photos]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]

  Powered by Linux