On Sat, Apr 30, 2022 at 01:08:43AM +0100, Andre Przywara wrote: > On Fri, 29 Apr 2022 14:14:19 -0400 > Tom Rini <tr...@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 <tr...@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 <tr...@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 <sam...@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
signature.asc
Description: PGP signature
