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

[Samuel Holland]

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.

[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.

>>>> 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.)

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.

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

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