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 DC8C2C433F5 for ; Sun, 1 May 2022 16:26:08 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4AC2883EFA; Sun, 1 May 2022 18:26:05 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="O84tsk0Y"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 063CA83F05; Sun, 1 May 2022 18:26:02 +0200 (CEST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 18343834AD for ; Sun, 1 May 2022 18:25:58 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qk1-x732.google.com with SMTP id j9so9985722qkg.1 for ; Sun, 01 May 2022 09:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=panYlFhyKVxBvXbE+mwrc5dzU0zviISkOnJWt3vO3sE=; b=O84tsk0YOefO+N+UufIZDuhJYc5/wU3raO0D+5HLeTasDk0iXK2Wmex7B+trAc/rCh fvmeMOzeyNKhuz+0DqzwNmW5VDkUJGEA45+/6e6b5LTOq58ClMdvzCanPI2P5z/sTq3w p2F7eS6/1wMTAb0d2q5JoedYJBnUDCeCmp6to= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=panYlFhyKVxBvXbE+mwrc5dzU0zviISkOnJWt3vO3sE=; b=qxU9hN8BXL5uTfHhctlMyaAhSzudRLxjW+D4aUPS2k9nk5TpK9Gl/Ch4H+XOFUvQCg tHhKJUwhHm5uR52IGR1tkKC+q5+SsmY/4AIQ5nKJA2m7glwVMVLuV7cn1z46oNeJXLaP 2ZJ07IBK2Y8kO4OxcnXvLZMUTOsRcYaia+QbsqXRHeQKWqWv7+k0aU7a6iMy9FF76LKu RYveJUZctYdtyaahBPXe69TZRj+6JD1YVr9NgFk+irzNbHLfe9ROLTkqcxE1DgJRDwNq siUQ4Y1NWqKNbXXNoq9R9/+/oqXIb0RNPsSvR1LEKqo/90AVvkhphfndOV1tV8j5oVc9 vBew== X-Gm-Message-State: AOAM530NFBkzcMEBESgEKlSEVAHdo7tFoGep1iyrjnlyPLCuQovOFz0n BrOFsFOK8HM6+UwmthI3Ea9zj8NKsSfajQ== X-Google-Smtp-Source: ABdhPJwv22LFHXodgc/nLw0h1vVQlcy8Bdf+4ZuNHH5YivJzd3wj6SoegcvUWRpWlIeJDHWw65EtFQ== X-Received: by 2002:ae9:ddc5:0:b0:69e:6b21:10c8 with SMTP id r188-20020ae9ddc5000000b0069e6b2110c8mr6007879qkf.677.1651422356837; Sun, 01 May 2022 09:25:56 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-4500-bd1b-0659-9336-7b01.res6.spectrum.com. [2603:6081:7b01:4500:bd1b:659:9336:7b01]) by smtp.gmail.com with ESMTPSA id k12-20020ac8604c000000b002f39b99f6aesm2784474qtm.72.2022.05.01.09.25.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 May 2022 09:25:55 -0700 (PDT) Date: Sun, 1 May 2022 12:25:53 -0400 From: Tom Rini To: Andre Przywara 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: <20220501162553.GL1182808@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> <20220430010843.759efafb@slackpad.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5mN69Y7OHXGepfYh" Content-Disposition: inline In-Reply-To: <20220430010843.759efafb@slackpad.lan> X-Clacks-Overhead: GNU Terry Pratchett 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 --5mN69Y7OHXGepfYh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 30, 2022 at 01:08:43AM +0100, 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: > > > > Date: Fri, 29 Apr 2022 11:31:00 -0400 > > > > From: Tom Rini > > > >=20 > > > > 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: > > > > >=20 > > > > > 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: > > > > > > >=20 > > > > > > > Hi Samuel, Tom, > > > > > > > =20 > > > > > > > > This series brings all of our devicetrees up to date with L= inux. > > > > > > > >=20 > > > > > > > > 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 ar= e not major > > > > > > > > changes to those devicetrees either. > > > > > > > >=20 > > > > > > > > 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 olde= r boards had > > > > > > > > those properties added or fixed since the last devicetree s= ync. This PHY > > > > > > > > driver change is necessary to complete the DM_GPIO migratio= n. > > > > > > > >=20 > > > > > > > > A couple of breaking changes were made to several SoCs' dev= icetrees in > > > > > > > > Linux relating to the "r_intc" interrupt controller. New ke= rnels support > > > > > > > > old devicetrees, but not the other way around. So to be mos= t compatible > > > > > > > > and avoid regressions, those changes are skipped here. = =20 > > > > > > >=20 > > > > > > > Many thanks for considering this! I just skimmed over the A64= and H6 > > > > > > > patches, and this is indeed the only difference. > > > > > > >=20 > > > > > > > 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. > > > > > > >=20 > > > > > > > Tom, can you give your opinion here? As Samuel mentioned abov= e, the > > > > > > > current mainline DTs wouldn't boot on older kernels (the chan= ges affect > > > > > > > critical devices), so this spoils stable distro and installer= kernels, > > > > > > > when using $fdtcontroladdr, for instance when booting via UEF= I. > > > > > > >=20 > > > > > > > As a side effect of always defining SYS_SOC to "sunxi", we ca= nnot easily > > > > > > > use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for in= stance. > > > > > > >=20 > > > > > > > For context, those changed properties were in the mainline ke= rnel tree at > > > > > > > some point, but have been amended since. So it's not some ran= dom change. =20 > > > > > >=20 > > > > > > So, this is I guess a bit annoying. But, we aren't at the poin= t where > > > > > > the common use case is the downstream OS using the DTB we've lo= aded 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 t= hey can't > > > > > > be using $fdtcontroladdr in this case, right? Or am I missing = the use > > > > > > case that's in the wild atm? Thanks! =20 > > > > >=20 > > > > > 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 tim= er > > > > > - A64: adding GPU DVFS, adding DRAM DVFS, add support for seconda= ry > > > > > 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. > > > > >=20 > > > > > At the moment I boot distro grubs and installers just fine, and w= ithout > > > > > losing any real functionality (minus suspend/resume, maybe). The > > > > > out-of-the-box default boot works now, and would break when pulli= ng in the > > > > > pure mainline DTs. Plus FreeBSD (which relies more heavily on UEF= I, IIUC), > > > > > can only deal with the older DTs (#interrupt-cells for r_intc mus= t be 2). =20 > > > >=20 > > > > 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 g= iven > > > > 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 compatibili= ty is > > > > supposed to be handled? I'm adding in Rob here since this still re= ads a > > > > bit confusing as to what's supposed to happen, but maybe we also ju= st > > > > need to check in with some other-OS folks to see what their plan is= ? =20 > > >=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. > > >=20 > > > 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 > 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>. > 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 > 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. --=20 Tom --5mN69Y7OHXGepfYh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmJutJEACgkQFHw5/5Y0 tyx06gv/Xwo4qhgKdi0uxP+BuYZpThQjBrkJ0Ls48mS2tCQlgoIP4dTHaWBaM13/ 4uwv1YcJ0LA6kiO5/B37RwDf1GlWQVrEgoAtmqpDRHOcZ/xmiaI3Y9B/X+Bnb6zC SWM+3BJiRUsIVQQcIx8/5UTkPRCSpV2iue0/jmbhes6ycaSjRQtzX/VvK+kkEIk5 Ds0smae2EODXfGWHhikEuq48fV+LAlMW9QEWVKGp/H+ix0plO/jMZZAVUfjEP2wf HiFADUs778pvf68CZVMgnvPBFbQqPKnmp6RQ2n1f02I2aKmZp+sGrBUxrFS1+IA2 ykVBqk2DPRA1ypsznDAavBumP+Vq28e3PqZg5oHHT+MYAACjedj21yM2RQKB/X3c vFJKSnB0/oIO0m2/1F2qnvo49dRNjivtxhgTvqhKQPxMgVa7+i1CQEsjO7562nx2 6n+BxEb/29fQwLDjw7MFSsmQa5SvFXRZkAtDR961S0L0JVjLhAVTCE+Z1UP/u1uN ncO/ga9j =KK7J -----END PGP SIGNATURE----- --5mN69Y7OHXGepfYh--