[PATCH 4/8] dts: Add alternative location for upstream DTB builds

[Sumit Garg]

On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Sumit,
>
> On Wed, Dec 20, 2023 at 12:01 PM Sumit Garg <sumit.garg at linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Wed, 20 Dec 2023 at 10:17, Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hi Sumit,
> > >
> > > On Thu, 14 Dec 2023 at 06:52, Sumit Garg <sumit.garg at linaro.org> wrote:
> > > >
> > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > directory.
> > >
> > > Also add a new Makefile for arm64.
> >
> > I suppose you are referring to dts/arch/arm64/Makefile which has been
> > added by this patch.
>
> Yes, I just mean that you should mention this in the commit message
>

Okay, I will append the commit message.

> >
> > >
> > > >
> > > > This will help easy migration for platforms which currently are compliant
> > > > with upstream Linux kernel devicetree files.
> > > >
> > > > Signed-off-by: Sumit Garg <sumit.garg at linaro.org>
> > > > ---
> > > >  dts/Kconfig             | 11 +++++++++++
> > > >  dts/Makefile            | 17 ++++++++++++++---
> > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > >  create mode 100644 dts/arch/arm64/Makefile
> > > >
> > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > index 00c0aeff893..96396f12b67 100644
> > > > --- a/dts/Kconfig
> > > > +++ b/dts/Kconfig
> > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > >           enables a live tree which is available after relocation,
> > > >           and can be adjusted as needed.
> > > >
> > > > +config OF_UPSTREAM
> > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > +       help
> > > > +         Traditionally, U-boot platforms used to have their custom devicetree
> > >
> > > U-Boot
> > >
> > > (I think I mentioned this, but you thought I said U-boot...but it
> > > really is U-Boot). Perhaps grep your patches next time.
> >
> > Ah, I see. It looks like I missed that bit, and will take care of it
> > in the next revision.
> >
> > >
> > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > +         a regular sync will be maintained every major Linux kernel release
> > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > +         bits maintained as part of *-u-boot.dtsi files.
> > >
> > > I'm a bit nervous about this. It means that boards chose between this
> > > dir of the local files. It means there is some effort to switch.
> > >
> > > I wonder if we could default to using the rebasing thing, with boards
> > > having to 'opt out'? So this should be 'default y' ?
> >
> > Ideally that should be our migration path going forward once we get
> > enough boards migrated to use rebasing repo. But at this initial stage
> > we have to put some effort on migrating boards to use rebasing
> > subtree, although effort should be just adding (given DT bindings
> > compliance) following to defconfig (see patch #7):
> >
> > CONFIG_OF_UPSTREAM=y
> > CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"
> >
> > and create a mirrored copy of:
> > ../../../devicetree-rebasing/src/arm64/amlogic/ into
> > dts/arch/arm64/amlogic/ with modifications to add targets to
> > dts/arch/arm64/Makefile.
> >
> > I am happy to put in that effort but certainly for new board support
> > that would like to import DT from Linux it should be the default. That
> > stands true for the Qcom platform series for which Caleb is currently
> > working on.
>
> The problem I see is that this is board-by-board, so will never
> happen. Changing one board (e.g. rockpro64-rk3399) typically involves
> changing the .dtsi files it includes (e.g. rk3399.dtsi) so it is
> hard/impossible to do one board without doing all.
>
> So this is why I believe the setting should be on an SoC basis, not on
> a board basis.

Sure, I will enable OF_UPSTREAM on a per SoC basis.

>
> >
> > >
> > >
> > > > +
> > > >  choice
> > > >         prompt "Provider of DTB for DT control"
> > > >         depends on OF_CONTROL
> > > > diff --git a/dts/Makefile b/dts/Makefile
> > > > index 3437e54033d..8098bf8191a 100644
> > > > --- a/dts/Makefile
> > > > +++ b/dts/Makefile
> > > > @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),)
> > > >  DEVICE_TREE := unset
> > > >  endif
> > > >
> > > > +ifeq ($(CONFIG_OF_UPSTREAM),y)
> > > > +ifeq ($(CONFIG_ARM64),y)
> > > > +DEVICE_TREE_LOC := dts/arch/arm64
> > >
> > > dt_dir ?
> >
> > Okay I will rename it.
> >
> > >
> > > Should we move the arm64 DTs to arch/arm64 ?
> >
> > IMO, the migration path should be to use rebasing subtree via
> > dts/arch/arm64/ and dropping DTs except *-u-boot.dtsi from
> > arch/$(ARCH)/dts. So moving DTs from arch/arm/ to arch/arm64/ seems
> > like a redundant change to me.
>
> I can see that argument, but having two different directory structures
> would be confusing.

I can see your point but U-Boot arch arm64 code is also contained in
arch/arm/. However, I would suggest first migrating to DT rebasing and
then we can do a move for the leftovers (*-u-boot.dtsi and such). A
double move won't add much value.

-Sumit

>
> >
> > >
> > > What about the subdirs used in Linux?
> >
> > I hope I have described above regarding how subdirs are mirrored.
> > However, have a look at patch #7 for the amlogic/ subdir example.
>
> OK
>
> Regards,
> Simon