On 09/26/2019 14:28, Steve McIntyre wrote: > 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). Every time this has been proposed at devicetree BoFs at the Embedded Linux Conference and Embedded Linux Conference Europe, the overwhelming response has been: do not remove the .dts files from the Linux kernel source tree. I'm coming up on some major deadlines, so it will probably be after Embedded Linux Conference Europe before I reply further. I have major concerns with moving .dts files out of the Linux tree. Anyone who is attending ELCE might want to discuss this topic there. (I note that later in this email that Arnd is tasked to organize a session at ELCE.) -Frank > > 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 >
