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
