From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6ABE3C433EF for ; Sun, 1 May 2022 00:59:53 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id AA0E7818A3; Sun, 1 May 2022 02:59:50 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 243718339D; Sun, 1 May 2022 02:59:49 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id 3937C80FEC for ; Sun, 1 May 2022 02:59:45 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=andre.przywara@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4E4C41FB; Sat, 30 Apr 2022 17:59:44 -0700 (PDT) Received: from slackpad.lan (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 206763F774; Sat, 30 Apr 2022 17:59:43 -0700 (PDT) Date: Sun, 1 May 2022 01:59:21 +0100 From: Andre Przywara To: Samuel Holland Cc: Tom Rini , Mark Kettenis , robh@kernel.org, u-boot@lists.denx.de, jagan@amarulasolutions.com, sjg@chromium.org Subject: Re: [PATCH 00/12] sunxi: Devicetree sync from Linux v5.18-rc1 Message-ID: <20220501015921.65b15c4d@slackpad.lan> In-Reply-To: <3dfca248-e83f-bcf8-3f14-b421ef1be556@sholland.org> References: <20220427203132.47271-1-samuel@sholland.org> <20220429155159.07799199@donnerap.cambridge.arm.com> <20220429145710.GU1182808@bill-the-cat> <20220429162551.044166f7@donnerap.cambridge.arm.com> <20220429153100.GV1182808@bill-the-cat> <20220429181419.GE1182808@bill-the-cat> <20220430010843.759efafb@slackpad.lan> <3dfca248-e83f-bcf8-3f14-b421ef1be556@sholland.org> Organization: Arm Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean On Fri, 29 Apr 2022 21:38:58 -0500 Samuel Holland wrote: Hi Samuel, > On 4/29/22 7:08 PM, Andre Przywara wrote: > > On Fri, 29 Apr 2022 14:14:19 -0400 > > Tom Rini wrote: > >=20 > > Hi, > > =20 > >> On Fri, Apr 29, 2022 at 06:05:03PM +0200, Mark Kettenis wrote: =20 > >>>> Date: Fri, 29 Apr 2022 11:31:00 -0400 > >>>> From: Tom Rini > >>>> > >>>> On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote: =20 > >>>>> On Fri, 29 Apr 2022 10:57:10 -0400 > >>>>> Tom Rini wrote: > >>>>> > >>>>> Hi, > >>>>> =20 > >>>>>> On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote: = =20 > >>>>>>> On Wed, 27 Apr 2022 15:31:19 -0500 > >>>>>>> Samuel Holland wrote: > >>>>>>> > >>>>>>> Hi Samuel, Tom, > >>>>>>> =20 > >>>>>>>> This series brings all of our devicetrees up to date with Linux. > >>>>>>>> > >>>>>>>> Older SoCs (before A83T) have not been synchronized in over 3 ye= ars. > >>>>>>>> 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 co= nverting > >>>>>>>> the USB PHY driver to get its VBUS detection GPIO/regulator from= the > >>>>>>>> devicetree instead of from a pin name in Kconfig. Many older boa= rds 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' devicetr= ees in > >>>>>>>> Linux relating to the "r_intc" interrupt controller. New kernels= support > >>>>>>>> old devicetrees, but not the other way around. So to be most com= patible > >>>>>>>> and avoid regressions, those changes are skipped here. =20 > >>>>>>> > >>>>>>> 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 t= ake 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, t= he > >>>>>>> current mainline DTs wouldn't boot on older kernels (the changes = affect > >>>>>>> critical devices), so this spoils stable distro and installer ker= nels, > >>>>>>> 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 instan= ce. > >>>>>>> > >>>>>>> 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. =20 > >>>>>> > >>>>>> So, this is I guess a bit annoying. But, we aren't at the point w= here > >>>>>> the common use case is the downstream OS using the DTB we've loade= d 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. S= o 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! =20 > >>>>> > >>>>> While it sounds like the DTs are wildly out of date, this mostly af= fects > >>>>> secondary functionality. The mainline updates for the 64-bit SoCs a= re: > >>>>> - 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 t= hem > >>>>> binding compliant. =20 >=20 > The SoCs where the DTs are wildly out of date (v4.18-rc3) are: > A10 A10s/A13 A31 A20 A80 A23/A33 A83T >=20 > The SoCs with the r_intc binding change are: > A31 A23/A33 A83T A64 H3/H5 H6 >=20 > For the SoCs which are in both lists, yes, it is unlikely that anyone is = using > $fdtcontroladdr for Linux. So we could probably fully update those DTs. T= hat > leaves just A64, H3/H5, and H6 which would temporarily need to exclude the > r_intc-related changes. Yes, I don't really care about those older SoCs, devices using them are probably not really distro / UEFI material anyway. > >>>>> So those DT updates are really only important for mobile devices li= ke the > >>>>> Pinephone, which probably don't use UEFI booting. =20 >=20 > 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? What kernels are those OSes using? 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? > >>>>> At the moment I boot distro grubs and installers just fine, and wit= hout > >>>>> 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). =20 >=20 > FreeBSD already supports the new binding for forwarding interrupts (every= thing > except NMI). Any version with this change should boot fine: >=20 > https://cgit.freebsd.org/src/commit/?id=3D993e8236c30a Ah, sorry, my bad, I was looking at a stale repo (they stopped updating the original master branch and switched to main, for technical reasons). > >>>> 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 gi= ven > >>>> 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 compatibilit= y is > >>>> supposed to be handled? I'm adding in Rob here since this still rea= ds 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?= =20 > >>> > >>> 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. =20 > >=20 > > 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 =3D <3>. =20 >=20 > See above, FreeBSD already supports this. >=20 > > 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. > > =20 > >> 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? =20 > >=20 > > That's one possible solution, yes, and so far the easiest, it provides > > a good balance between features and compatibility. =20 >=20 > This was my understanding of the plan as well. >=20 > > Theoretically we can never fully sync, unless we decide to no longer > > support those older OSes (older Linux kernels and (current) *BSD). =20 >=20 > 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. 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? =46rom experience I'd say there are ways to avoid them, though possibly at some cost (less clean DT, or deviating from some DT rules). > > 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. =20 >=20 > Right, automatically handling this is not really feasible. Users that nee= d 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? Cheers, Andre