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

[Simon Glass]

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

>
> >
> > >
> > > 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.

>
> >
> >
> > > +
> > >  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.

>
> >
> > 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