On Thu, 14 Mar 2024 at 21:28, Tim Harvey tharvey@gateworks.com wrote:
On Thu, Mar 14, 2024 at 12:50 AM Sumit Garg sumit.garg@linaro.org wrote:
- Tom
Hi Tim,
On Wed, 13 Mar 2024 at 22:01, Tim Harvey tharvey@gateworks.com wrote:
On Wed, Mar 13, 2024 at 6:20 AM Sumit Garg sumit.garg@linaro.org wrote:
On Wed, 13 Mar 2024 at 06:46, Fabio Estevam festevam@gmail.com wrote:
Hi Tim,
On Tue, Mar 12, 2024 at 4:05 PM Tim Harvey tharvey@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@gateworks.com
...
33 files changed, 13 insertions(+), 10658 deletions(-)
This diff looks great :-)
+1
Reviewed-by: Sumit Garg sumit.garg@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:
- 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@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-rebasi...
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@linaro.org Date: Thu Mar 14 12:20:27 2024 +0530
Subtree merge tag 'v6.8-dts' of devicetree-rebasing repo [1] intodts/upstream
[1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
- 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/cont...).
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?
- 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):
- You can play around with $ ./dts/update-dts-subtree.sh pull <tag>
- 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