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

[Andre Przywara]

On Fri, 29 Apr 2022 11:31:00 -0400
Tom Rini <trini at konsulko.com> wrote:

Hi,

> 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?

AFAIK, the official Linux DT compatibility requirements are to always keep
backwards compatibility (boot newer kernels with older DTs), but leave the
decision to support the other way around (older kernels with newer DTs) to
the respective platform maintainers.
At least in the past sunxi opted to allow non-forward compatible changes
(this r_intc one being an example of), with the rationale that without
proper documentation and with doing "retroactive" development, incompatible
changes are unavoidable, or would require more work than those volunteers
are willing to do.

Those incompatible changes (there were some more, though minor in the
past) are the reason I (grudgingly) held back with DT updates for U-Boot,
so I would very much appreciate if that situation could be cleared up.

As mentioned, I would be happy to take the changed DTs, and would
volunteer to keep those diffs somehow maintained in U-Boot.

Cheers,
Andre