[PATCH] imx8m*_venice: move venice to OF_UPSTREAM
Sumit Garg
sumit.garg at linaro.org
Fri Mar 15 05:59:03 CET 2024
On Thu, 14 Mar 2024 at 21:28, Tim Harvey <tharvey at gateworks.com> wrote:
>
> 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.
The current policy is to sync on major kernel releases only after the
U-Boot next branch opens. Since we would like to avoid any DT ABI
breakages for U-Boot and at the same time provide sufficient time to
fix problems if any. However if DT ABI turns out to be much more
stable for U-Boot then we can revisit this policy.
>
> > 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!
Thanks for your adoption too.
-Sumit
>
> Tim
More information about the U-Boot
mailing list