Hi Rob, For clarity - these notes were hastily taken during conversation. They may not be internally consistent, as you've noticed. On Thu, Sep 26, 2019 at 07:02:00PM +0000, Rob Herring wrote: >On 9/26/19 12:07 PM, Steve McIntyre wrote: >> 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. > >Really? u-boot is. Run git log on include/dt-bindings/. It's a bunch of >'copy from Linux x.y' commits. A blind sync it is not though. ACK. >> 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. > >IMO, we should have a flag day switching the direction of >devicetree-rebasing.git at least for .dts files. Platform maintainers >have to start sending patches to the external repo all at once. Then we >just sync it back into the kernel and it is transparent to users. That >avoids many of the issues listed. Moving SoCs/boards out 1 by 1 seems >like a lot of manual work and problematic for people knowing which tree >to apply changes to. OK, that's an alternative view - see below. >The bindings have to be treated separately though as they don't get >applied by a single maintainer (or maintainer group). > >> 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? > >Above you said move everything together? > >By device bindings, you mean device schema I assume. We kind of have >this already. dt-schema has common schema only in it. But I haven't set >a hard rule and so we have common schema in the kernel tree too now. We >could move the common ones, but having to know and look in 2 places >isn't that ideal for users. I've already gotten complaints about that. >So now I tend to think we should have all schema in one place. ACK, fair point. >> 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. > >All binding changes are reviewed assuming they are documented, sent to >the DT list and the subsystem maintainer doesn't apply before I review >it (that's networking primarily). > >> >> 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. > >Last we talked Arnd was not on board with maintaining this. Don't know >about Olof. > >And let's not kid ourselves, there is no 'to start with' here. Sorry, that should have been clearer. We acknowledge that you will end up dealing with this. We also want to get more people up to speed to help, to spread the load. >> 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? > >devicetree-rebasing.git already does this though not LTS. How many dts >changes are going into LTS's and of those how many do people really care >about? That's a good question that people were wondering. It would be nice to have a process to allow us to backport fixes to DT data too, even if it's rarely used. >> 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. > >I asked for this years ago. New DT with older kernel also needs testing >(would you want a new BIOS update to break your OS booting?) Agreed. broonie said he's happy to help get this going. >> 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 > >I think we need to start with getting the dt-rebasing tree looking like >we want it to end up as. For example, it seems maybe we want 2 repos for >the dts files and bindings/schemas. Right. Let's get some agreement on that, then. I'm hearing a range of different ideas from you, Arnd, Grant and Mathieu so far. All of them sound plausible enough to me, but I don't have remotely the same level of experience as you guys. :-) Is it worth organising a call to discuss just this piece? >> * 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 > >We should get u-boot folks on board and committed to using this. IMO, >they are the only other project with wide enough h/w support to care and >benefit. I'd guess anything else can list their h/w support in a single >page. Nod. >> mailing list: >> >> boot-architecture? not ideal >> devicetree=spec? done (hence CC here!) > >Did you mean to Cc devicetree-spec because you didn't. Nod, thanks. Fixed on this reply, and initial mail forwarded too. Cheers, -- Steve McIntyre steve.mcintyre@xxxxxxxxxx <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
