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 19784C433EF for ; Sat, 30 Apr 2022 00:09:24 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 0E9A083B19; Sat, 30 Apr 2022 02:09:22 +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 4981683B3D; Sat, 30 Apr 2022 02:09:20 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id B2D1283A9F for ; Sat, 30 Apr 2022 02:09:16 +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 CA4A11042; Fri, 29 Apr 2022 17:09:15 -0700 (PDT) Received: from slackpad.lan (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 98DD03F774; Fri, 29 Apr 2022 17:09:14 -0700 (PDT) Date: Sat, 30 Apr 2022 01:08:43 +0100 From: Andre Przywara To: Tom Rini Cc: Mark Kettenis , robh@kernel.org, samuel@sholland.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: <20220430010843.759efafb@slackpad.lan> In-Reply-To: <20220429181419.GE1182808@bill-the-cat> 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> 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: 7bit 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 14:14:19 -0400 Tom Rini 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 > > > > > > On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote: > > > > On Fri, 29 Apr 2022 10:57:10 -0400 > > > > Tom Rini 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 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). 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. Cheers, Andre