Hi Tom, On Wed, Dec 27, 2023 at 1:37 PM Tom Rini <tr...@konsulko.com> wrote: > > On Wed, Dec 27, 2023 at 07:56:26AM +0000, Simon Glass wrote: > > Hi Sumit, > > > > On Tue, Dec 26, 2023 at 10:06 AM Sumit Garg <sumit.g...@linaro.org> wrote: > > > > > > Hi Simon, > > > > > > On Tue, 26 Dec 2023 at 15:17, Simon Glass <s...@chromium.org> wrote: > > > > > > > > Hi Sumit, > > > > > > > > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.g...@linaro.org> > > > > wrote: > > > > > > > > > > On Thu, 21 Dec 2023 at 20:48, Simon Glass <s...@chromium.org> wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote: > > > > > > > > > > > > > > > Prerquisite > > > > > > > > ----------- > > > > > > > > > > > > > > > > This patch series requires devicetree-rebasing git repo to be > > > > > > > > added as a > > > > > > > > subtree to the main U-boot repo via: > > > > > > > > > > > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > > > > > > > \ > > > > > > > > v6.6-dts --squash > > > > > > > > > > > > > > So, I've played with subtree a little and I think this is the > > > > > > > right way > > > > > > > forward in these cases. If anyone wants to take a look at how > > > > > > > this works > > > > > > > in practice, take a look at: > > > > > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads > > > > > > > In that tree I started with the v6.1-dts tag, sync'd all the > > > > > > > configs (to > > > > > > > have an example of a normal commit) and then did a merge of each > > > > > > > tag > > > > > > > until v6.6-dts, so provide some history. And git log looks like > > > > > > > what I > > > > > > > want to see, the squash commit has clear references to what we are > > > > > > > getting and I make a merge commit that says what I did. If you > > > > > > > pull the > > > > > > > tree and checkout the branch, all the code is right there already, > > > > > > > nothing further to do. Same with tarball releases. The only thing > > > > > > > I > > > > > > > don't like is the size growth there, but we'll reclaim some of it > > > > > > > when > > > > > > > we delete our obsolete bindings, and then obsolete dts files. > > > > > > > > > > > > I spent a bit of time with subtree as well, as part of reviewing > > > > > > this > > > > > > series, using the instructions Sumit provided. It seems OK to me. We > > > > > > have to accept that it adds code and there will be changes/churn, > > > > > > but > > > > > > it is not too different to accepting patches on those files within > > > > > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot > > > > > > does support a good proportion of the boards supported by Linux, so > > > > > > I > > > > > > don't see that as a big cost. > > > > > > > > > > > > From my experimentation, subtrees seem to have no impact on > > > > > > buildman, > > > > > > which is great. Am I missing anything? > > > > > > > > > > No it shouldn't cause any regression on existing tools/CI/build > > > > > systems. It is just a version controlled way of importing third party > > > > > source code as a tarball. > > > > > > > > > > > > > > > > > I still worry about the board-level 'switch' between U-Boot DT and > > > > > > upstream ones. I believe that should be at the SoC level instead. > > > > > > > > > > > > > > > > Probably I wasn't clear enough in my earlier replies but this series > > > > > motivates for a SoC level switch only. Patch #7 is essentially a > > > > > switch for Amlogic meson-gxbb SoC and its derived boards. > > > > > > > > OK good...but that's not quite what I mean. You have a fragment like > > > > this in multiple defconfig files: > > > > > > > > +CONFIG_OF_UPSTREAM=y > > > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2" > > > > > > > > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the > > > > Kconfig. > > > > > > Okay I got your point. It makes sense to me. I will do that for v3. > > > > > > > We should not have to specify the filename like this. It is > > > > laborious and error-prone. > > > > > > The only differentiation in naming here is just silicon vendor prefix > > > addition (amlogic/ in this case). The reason for this being that I > > > just want to mirror the whole silicon vendor directory from DT > > > rebasing rather than mirroring individual DT files. Given this do you > > > have any better alternatives? > > > > My current opinion is that a better approach would be to move the > > files first (in the U-Boot tree). That would be easier if we could > > just copy the Linux arch/xxx/boot/dts Makefiles but for now that is > > not possible. The Kconfig options for each SoC are similar but there > > are various differences. > > > > Having a different layout is just a pain and it will get worse, as > > people add new boards, since they need to know to add the correct > > directory. > > > > I will see if I can devise a small series to point this in what I > > consider to be the right direction, in line with Linux, and the U-Boot > > commit 3284c8b8 ("dts: generate multiple device tree blobs"). > > I think we should just go with the approach Sumit has already taken, and > encourage SoC maintainers to migrate sooner rather than later. There's > also nothing stopping people from adding vendor directories under arch/ > at that point, and will likely have to happen anyhow for the case of > platforms that aren't yet in the devicetree-rebasing tree. I am hopeful > it won't be as much of an issue as my general feedback will change from > "what kernel release is this dts in?" to "why didn't you set > OF_UPSTREAM and use the existing tree?"
OK. But I do want to see a move to using the same dir structure as Linux. Regards, Simon
