[PATCH 00/12] sunxi: Devicetree sync from Linux v5.18-rc1

[Tom Rini]

On Sat, Apr 30, 2022 at 01:08:43AM +0100, Andre Przywara wrote:
> On Fri, 29 Apr 2022 14:14:19 -0400
> Tom Rini <trini at konsulko.com> wrote:
> 
> Hi,
> 
> > On Fri, Apr 29, 2022 at 06:05:03PM +0200, Mark Kettenis wrote:
> > > > Date: Fri, 29 Apr 2022 11:31:00 -0400
> > > > From: Tom Rini <trini at konsulko.com>
> > > > 
> > > > On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote:  
> > > > > On Fri, 29 Apr 2022 10:57:10 -0400
> > > > > Tom Rini <trini at konsulko.com> wrote:
> > > > > 
> > > > > Hi,
> > > > >   
> > > > > > On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote:  
> > > > > > > On Wed, 27 Apr 2022 15:31:19 -0500
> > > > > > > Samuel Holland <samuel at sholland.org> wrote:
> > > > > > > 
> > > > > > > Hi Samuel, Tom,
> > > > > > >     
> > > > > > > > This series brings all of our devicetrees up to date with Linux.
> > > > > > > > 
> > > > > > > > Older SoCs (before A83T) have not been synchronized in over 3 years.
> > > > > > > > And I don't have any of this hardware to test. But there are not major
> > > > > > > > changes to those devicetrees either.
> > > > > > > > 
> > > > > > > > The big motivation for including older SoCs in this update is converting
> > > > > > > > the USB PHY driver to get its VBUS detection GPIO/regulator from the
> > > > > > > > devicetree instead of from a pin name in Kconfig. Many older boards had
> > > > > > > > those properties added or fixed since the last devicetree sync. This PHY
> > > > > > > > driver change is necessary to complete the DM_GPIO migration.
> > > > > > > > 
> > > > > > > > A couple of breaking changes were made to several SoCs' devicetrees in
> > > > > > > > Linux relating to the "r_intc" interrupt controller. New kernels support
> > > > > > > > old devicetrees, but not the other way around. So to be most compatible
> > > > > > > > and avoid regressions, those changes are skipped here.    
> > > > > > > 
> > > > > > > Many thanks for considering this! I just skimmed over the A64 and H6
> > > > > > > patches, and this is indeed the only difference.
> > > > > > > 
> > > > > > > But while I love this pragmatic approach, and would be happy to take this,
> > > > > > > this goes against our own rules, and more importantly against Tom's one's:
> > > > > > > to take only direct DT file copies from the kernel tree.
> > > > > > > 
> > > > > > > Tom, can you give your opinion here? As Samuel mentioned above, the
> > > > > > > current mainline DTs wouldn't boot on older kernels (the changes affect
> > > > > > > critical devices), so this spoils stable distro and installer kernels,
> > > > > > > when using $fdtcontroladdr, for instance when booting via UEFI.
> > > > > > > 
> > > > > > > As a side effect of always defining SYS_SOC to "sunxi", we cannot easily
> > > > > > > use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance.
> > > > > > > 
> > > > > > > For context, those changed properties were in the mainline kernel tree at
> > > > > > > some point, but have been amended since. So it's not some random change.    
> > > > > > 
> > > > > > So, this is I guess a bit annoying.  But, we aren't at the point where
> > > > > > the common use case is the downstream OS using the DTB we've loaded and
> > > > > > are using, are we?  I mean, we can't be, as ours are so far out of date,
> > > > > > so this will only be an option when we use a recent DT ourself.  So we
> > > > > > should be able to sync in the changes and update our code, as they can't
> > > > > > be using $fdtcontroladdr in this case, right?  Or am I missing the use
> > > > > > case that's in the wild atm?  Thanks!  
> > > > > 
> > > > > While it sounds like the DTs are wildly out of date, this mostly affects
> > > > > secondary functionality. The mainline updates for the 64-bit SoCs are:
> > > > > - H6: adding the VP9 video h/w codec and an additional wakeup timer
> > > > > - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary
> > > > > digital audio interfaces, plus the wakeup timer
> > > > > Also there are cosmetic changes, like changing node names to make them
> > > > > binding compliant.
> > > > > So those DT updates are really only important for mobile devices like the
> > > > > Pinephone, which probably don't use UEFI booting.
> > > > > 
> > > > > At the moment I boot distro grubs and installers just fine, and without
> > > > > losing any real functionality (minus suspend/resume, maybe). The
> > > > > out-of-the-box default boot works now, and would break when pulling in the
> > > > > pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, IIUC),
> > > > > can only deal with the older DTs (#interrupt-cells for r_intc must be 2).  
> > > > 
> > > > I guess the first point is, yes, we should sync in what we can sync in,
> > > > to bring things closer to proper alignment.  I further guess that given
> > > > that we have to support both "new Linux" and "not Linux", we have to
> > > > keep the old style DT information instead as that's how compatibility is
> > > > supposed to be handled?  I'm adding in Rob here since this still reads a
> > > > bit confusing as to what's supposed to happen, but maybe we also just
> > > > need to check in with some other-OS folks to see what their plan is?  
> > > 
> > > My goal with OpenBSD has always been to make the OS boot with the DT
> > > built into U-Boot, but to allow users to use a more up-to-date Linux
> > > DT by putting the apropriate .dtb file on the ESP.  However it is easy
> > > to miss changes that break backwards compatibility of the bindings in
> > > the noise of other changes.  So in many cases we only notice this when
> > > the changes make it into U-Boot and we update the OpenBSD U-Boot port.
> > > 
> > > I'll drag out one of my A64 boards and see what needs to be done to
> > > support the routing of these interrupts through r_intc.
> 
> In FreeBSD the change would be fairly small, I think: just ignoring the
> first parameter of an r_intc interrupt specifier when it advertises
> #interrupt-cells = <3>.
> In OpenBSD I don't find the allwinner,sun6i-a31-r-intc (or any other
> intc related) compatible string at all, and so far we just lose the NMI
> from the PMIC. But this would radically change with the new DT: now the
> two PIOs and the RTC are routed through that IRQ controller, so they
> would probably fail probing.
> 
> > So, does that mean the plan is to keep the r_intc changes out of U-Boot
> > for now, but we can sync the rest, and come up with a plan to fully
> > update in time?
> 
> That's one possible solution, yes, and so far the easiest, it provides
> a good balance between features and compatibility.
> Theoretically we can never fully sync, unless we decide to no longer
> support those older OSes (older Linux kernels and (current) *BSD).

I believe saying older OSes need to load and pass their device tee,
rather than be able to rely on the run-time one, is reasonable.  We need
to document this somewhere, and then specifically call this out in
release emails.  But, it seems like a reasonable compromise for
supporting older OSes.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220501/133c1169/attachment.sig>