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

[Simon Glass]

Hi Sumit,

On Tue, Dec 26, 2023 at 10:20 AM Sumit Garg <sumit.garg at linaro.org> wrote:
>
> 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.

OK, so long as you are planning to do that next?

Regards,
Simon