[PATCH] imx8m*_venice: move venice to OF_UPSTREAM

[Tim Harvey]

On Thu, Mar 14, 2024 at 12:50 AM Sumit Garg <sumit.garg at linaro.org> wrote:
>
> + Tom
>
> Hi Tim,
>
> On Wed, 13 Mar 2024 at 22:01, Tim Harvey <tharvey at gateworks.com> wrote:
> >
> > On Wed, Mar 13, 2024 at 6:20 AM Sumit Garg <sumit.garg at linaro.org> wrote:
> > >
> > > On Wed, 13 Mar 2024 at 06:46, Fabio Estevam <festevam at gmail.com> wrote:
> > > >
> > > > Hi Tim,
> > > >
> > > > On Tue, Mar 12, 2024 at 4:05 PM Tim Harvey <tharvey at gateworks.com> wrote:
> > > > >
> > > > > Move to imx8m{m,n,p}-venice to OF_UPSTREAM:
> > > > >  - replace the non-upstream generic imx8m{m,n,p}-venice dt with one of the
> > > > >    dt's from the OF_LIST
> > > > >  - handle the fact that dtbs now have a 'freescale/' prefix
> > > > >  - imply OF_UPSTREAM
> > > > >  - remove rudundant files from arch/arm/dts leaving only the
> > > > >    *-u-boot.dtsi files
> > > > >
> > > > > Signed-off-by: Tim Harvey <tharvey at gateworks.com>
> > > > ...
> > > > >  33 files changed, 13 insertions(+), 10658 deletions(-)
> > > >
> > > > This diff looks great :-)
> > >
> > > +1
> > >
> > > Reviewed-by: Sumit Garg <sumit.garg at linaro.org>
> > >
> >
> > Hi Sumit,
> >
> > Thanks for your work on this - I imagine over time this will
> > de-duplicate a lot of work!
> >
> > I have a couple of questions about OF_UPSTREAM I haven't found the
> > answer to yet:
> > 1. how do you determine what the last sync point was in dts/upstream?
> > (ie what kernel version is it currently sync'd with)
>
> You can get that information from merge commits that happen over
> dts/upstream sub-directory. It was somewhat raw information for the
> first time we added dts/upstream as (commit aaba2d45dc2a pointing to
> v6.7-dts [1]):
>
> commit 53633a893a06bd5a0c807287d9cc29337806eaf7
> Author: Tom Rini <trini at konsulko.com>
> Date:   Thu Feb 29 12:33:36 2024 -0500
>
>     Squashed 'dts/upstream/' content from commit aaba2d45dc2a
>
>     git-subtree-dir: dts/upstream
>     git-subtree-split: aaba2d45dc2a1b3bbb710f2a3808ee1c9f340abe
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/tag/?h=v6.7-dts
>
> However, further syncs would be more clear from merge commit
> description, try following:
>
> $ ./dts/update-dts-subtree.sh pull v6.8-dts
>
> You will see merge commit saying:
>
> commit 57508745cd2b07e55b5c414c6d646de4865418d2 (HEAD -> dt_uprev)
> Merge: 3987e15e88a 14c9e8c0856
> Author: Sumit Garg <sumit.garg at linaro.org>
> Date:   Thu Mar 14 12:20:27 2024 +0530
>
>     Subtree merge tag 'v6.8-dts' of devicetree-rebasing repo [1] into
> dts/upstream
>
>     [1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
>
> > 2. how often will dts/upstream get re-synced (not the
> > devicetree-rebasing.git but u-boot dts/upstream),
>
> You can see the re-syncing details here (section: "Resyncing with
> devicetree-rebasing",
> https://source.denx.de/u-boot/u-boot/-/blob/next/doc/develop/devicetree/control.rst?ref_type=heads).
>

Thanks - I was confused about this as I originally figured it was done
via a git submodule. When I looked at the commit history of
dts/upstream it wasn't clear at all because of the first mergebeing
done differently as you explain above. As long as
update-dts-subtree.sh is run with a clear named tag that has the
kernel version in it then it's easy to follow via the short commit
description.

> > who do you suspect
> > will do be doing it?
>
> Tom will be doing that. I suppose we are just in time for a resync
> since the Linux kernel v6.8 was released.
>

Ok, that makes sense. I assume Tom will be updating it on major kernel
releases and possibly rc's leading up to as well.

> Tom,
>
> Do you think we can make v6.8-dts sync for the U-Boot next?
>
> > 3. how would one go about adding a new feature via dt to uboot when
> > the same feature has not yet landed in dts upstream? perhaps the
> > answer is it must land upstream first or do you suspect it would be ok
> > to put something in a u-boot.dtsi that can later get removed as
> > redundant?
>
> From an upstream perspective, we should aim for minimal contents in
> *-u-boot.dtsi, ideally it would be better to get rid of them. For eg.
> all bootph_* properties should all be pushed upstream.
>
> However, from the new features perspective we can consider using
> *-u-boot.dtsi if the changes are minimal like enabling some DT nodes.
> But if the changes are significant then that board can just opt out of
> OF_USTREAM but still reusing all the DT includes. The reasoning behind
> this is to minimize any chances of breakage if DT features in
> *-u-boot.dtsi diverge from DT upstream.
>
> > I ask mainly for being able to add things quickly to a
> > downstream U-Boot repo that lags behind upstream U-Boot
> >

The specific case I imagine is for example I have a couple of boards
that have TPM's that I have submitted dts updates to enable which did
not make the 6.8 cutoff so will be in 6.9. Meanwhile I will want to
pull them manually to our downstream vendor fork of an earlier U-Boot
(which in the future will have OF_UPSTEAM for our boards). Now that I
see this doesn't use git submodules I can just alter the files as
needed if I'm in a downstream fork while upstream can patiently wait
for the sync.

>
> Working downstream can always be fun, allowing additional options (can
> be useful for advance testing too):
>
> 1. You can play around with $ ./dts/update-dts-subtree.sh pull <tag>
> 2. You can manually sync the vendor directories
> (dts/upstream/src/<arch>/<vendor>/).
> 3. You can manually sync/update the individual DTS files too.
>

Yes... very cool. Thank you for taking the time to do this. It is a
significant improvement to U-Boot!

Tim