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

Tue May 3 16:53:59 CEST 2022

On Mon, 2 May 2022 20:57:35 -0500
Samuel Holland <samuel at sholland.org> wrote:

Hi Samuel,

> On 4/30/22 7:59 PM, Andre Przywara wrote:
> >>>>>>> So those DT updates are really only important for mobile devices like the
> >>>>>>> Pinephone, which probably don't use UEFI booting.    
> >>
> >> We would really like to use UEFI booting on the PinePhone, and the out-of-date
> >> devicetree is one thing blocking that. We need to use $fdtcontroladdr to pick up
> >> the CPU idle states that are added at runtime by TF-A.  
> > 
> > Yes, I was wondering about that. I could imagine that suspend/resume is
> > a killer feature for the PinePhone. It probably sounds useful to fully
> > update just the Pinephone .dts, giving up compatibility for older
> > kernels. IIUC the PinePhone doesn't run normal "desktop" distros, but
> > relies more on custom OSes, tailored to a Phone use case in general?  
> 
> There is a mix of desktop distros, mobile spins of desktop distros (the
> largest/most popular category), and mobile-specific OSes[1].
> 
> [1]: https://wiki.pine64.org/wiki/PinePhone_Software_Releases
> 
> > What kernels are those OSes using?  
> 
> Most are using Ondrej's fork[2]. Some (at least Mobian) maintain their own patch
> set.

So that means it's all quite Pinephone specific then, and none of
them are using actual mainline kernels? So people don't run a stock Debian
mini.iso on it, for instance?
When I was asking for "kernels", I was hoping for mainline kernel *version
numbers*, not forks, but I get the idea ;-)

> [2]: https://github.com/megous/linux/tags
> 
> > The only caveat would be that this adds to the mess and increases the
> > diff to mainline, but maybe this could be solved by a
> > sun50i-a64-pinephone-u-boot.dtsi?  
> 
> Devicetree changes are still needed for camera and USB Type C support, so the
> r_intc changes could go in with those. I don't think we need to do anything
> special from the U-Boot side at this point.

I was thinking about putting the r_intc changes just in the
pinephone-u-boot.dtsi, so that the Pinephone gets them, but every other
(development) board does not. Sounds somewhat dodgy, but would
pragmatically solve the problem of stability for devboards *and* the
Pinephone being usable. Do Pinephone users actually use U-Boot?

Also I am not so much concerned about non-essential devices like a camera
or USB-C alternative functions, I guess those could even be fixed up using
DT overlays while running Linux already, from some script.
The problem with the r_intc changes is that last time I checked they break
already when booting an initrd, because of the pinctrl driver not 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.    
> >>
> >> This was my understanding of the plan as well.
> >>  
> >>> Theoretically we can never fully sync, unless we decide to no longer
> >>> support those older OSes (older Linux kernels and (current) *BSD).    
> >>
> >> Do we have any guidance for when this could be? After the n+1 LTS kernel/BSD
> >> release? After the distro/BSD installers update their kernels?  
> > 
> > More the latter, I'd say when major distros stop shipping those
> > old kernels in relevant releases. Especially Debian is one to keep an
> > eye on I guess, since they are on 5.10 *currently*, and their installer
> > properly stays there for a while. Ubuntu 20.04 shipped with 5.4, and I'd
> > like to support that say at least one more year still. Don't really
> > keep track of the kernels in other distros, but I think these two are
> > among the more conservative ones.  
> 
> OK, that makes sense.
> 
> > Samuel, since I have you here: With your new hat Linux hat on, can you
> > say whether incompatible DT changes won't happen in the future anymore?  
> 
> No, I really cannot.
> 
> As for major breaking changes, there is some push from the Linux clock
> maintainers toward finishing the conversion from legacy to sunxi-ng clock
> drivers. This affects A31, A23/A33, and A80. (In fact, this unfinished
> conversion is causing me quite some trouble trying to expand the DM clock
> drivers in U-Boot.)

I am personally less concerned about those older devices, especially those
SoCs you mentioned, which were mostly somewhat "embedded" anyway. Plus
their DTs in the U-Boot tree are outdated already.

In my understanding the A10/A20/H3 devices see quite some more wide-spread
usage, some running off-the-shelf distros (I certainly do).
And I care more about the v8 devices, especially since arm64 has a more
grown-up boot story.

> And then there are always little easy-to-miss things (like adding references to
> new ASoC widgets) that prevent drivers from loading on old kernels.

As mentioned, if that affects secondary features like audio, video,
camera, that is less concerning to me. Not being able to boot at all
is a different story, though.

> > From experience I'd say there are ways to avoid them, though possibly at
> > some cost (less clean DT, or deviating from some DT rules).  
> 
> and, as I'm sure you're painfully aware of, delays in adding support for new
> hardware, until we can get the binding perfect, because we know we will be stuck
> with it.

Yes, I understand ;-)
I totally see that, and was already wondering about some kind of "grace
period" for new SoCs, so that we declare their DTs unstable initially, to
unblock development and gather experience with it in the field.

Just to make this clear: I understand that it's not easy to maintain DT
compatibility, but I think it's essential to make this a "serious"
platform.
I was just wondering if this compatibility goal is something that's
considered worth fighting for; in the past that was outright dismissed.

Cheers,
Andre

> >>> One thing we could explore is patching the DT at runtime, but U-Boot
> >>> cannot know if the OS supports the new style or not, so it has to be
> >>> manually triggered.    
> >>
> >> Right, automatically handling this is not really feasible. Users that need the
> >> r_intc changes for suspend/resume will have to load a DTB or overlay from disk.
> >> (We could possibly build in such an overlay, and load it based on some
> >> environment variable, but this seems like little benefit when most users load a
> >> DTB from disk anyway.)  
> > 
> > But loading from disk would lose any manipulation that previous
> > firmware did, for instance TF-A. Plus I think reserved memory is not
> > properly propagated, at least last time I checked. Also the DT would
> > really need to be loaded by U-Boot, loading it via grub would lose even
> > more manipulations like the DRAM size and MAC address.
> > 
> > So I believe an overlay is the way to go. I have a patch sitting here
> > that applies all .dtbo files found in a directory on some block device
> > (e.g. "fdt apply_all mmc 0:1 overlays/"), would that help?  
> 
> Possibly? I will defer to others on how devicetree overlays could/should be
> integrated into the distro boot process.
> 
> Regards,
> Samuel