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 EFD4BC433F5 for ; Fri, 29 Apr 2022 18:14:29 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1B5F583AE2; Fri, 29 Apr 2022 20:14:28 +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="LsZ3ypwf"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id ED0AE83AE2; Fri, 29 Apr 2022 20:14:26 +0200 (CEST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 E489283966 for ; Fri, 29 Apr 2022 20:14:23 +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-x729.google.com with SMTP id a22so3422362qkl.5 for ; Fri, 29 Apr 2022 11:14:23 -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=DE2WJRtGBeH3BeyRKd+60sMDrYqWAdD3R7SusWUfWgs=; b=LsZ3ypwfsZGJ984+IRiXBIOvJyH4XUrkXrfHgxs6SSHo7v35HHkGxkHXWhFzXIGNHJ 3HDSmobz/wYNPN4hSLUdfEQzE+R61zcrvamV9bmTdRMG6aoJLEBWeLZRSSW8Oc47tNnc 4S/ItxPSF72tzspNXWdhunB/ED9dL2kW2HFNI= 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=DE2WJRtGBeH3BeyRKd+60sMDrYqWAdD3R7SusWUfWgs=; b=1sPpHz1xMMtr4IehPEvtPcv63E9D4jHj3n5WnWeJXvNVKN7jHlTfL90Ogn2oeIBDrC BKryWnMFG5RaLf62Fct8eurQUT5ltdRNFCW3T2/abZXtv+rirldJlZqb/jeKlQD+KxeL OAkrNb29wzYoamAavURSrNB2+qRkYRUjluO8N+q1CGD3XN+e5MZDf2EgFPFWfKsw/ROL mTx6k2gxX0z7TNLPsKqctJHufE/tAwNbDWavyX7kXIJZLLRUt7KxqVSHOJsz9BS3V7to O0zKX5CRbQ774CTQYnLfb0rH/p4Fw/H5EcEXNmEUYQ3XQ4tKK1Gd4dZ88Demn097I8Fb zSxw== X-Gm-Message-State: AOAM533R4WxcdTnKBko6shFCFCV3INL0BABWxqSzLUbahQN6ILEluhUV /cfBixrN3N20h9vISgIjjb5uRlE454c0/w== X-Google-Smtp-Source: ABdhPJyA0uzTE7lmL7aCNOlEv1NGdzdruopVqJmmtNtk1g1X3zIbNKbx1j39xE+gjclRPlEfHlp8nQ== X-Received: by 2002:a05:620a:4115:b0:69f:c00e:7aec with SMTP id j21-20020a05620a411500b0069fc00e7aecmr271485qko.631.1651256062736; Fri, 29 Apr 2022 11:14:22 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-4500-a827-6dbc-a8e1-e6af.res6.spectrum.com. [2603:6081:7b01:4500:a827:6dbc:a8e1:e6af]) by smtp.gmail.com with ESMTPSA id cb27-20020a05622a1f9b00b002f39a56e69asm559652qtb.40.2022.04.29.11.14.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Apr 2022 11:14:21 -0700 (PDT) Date: Fri, 29 Apr 2022 14:14:19 -0400 From: Tom Rini To: Mark Kettenis Cc: andre.przywara@arm.com, 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: <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wwSkEpePV3aFlXly" Content-Disposition: inline In-Reply-To: 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 --wwSkEpePV3aFlXly Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > > 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: > > > > > 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 Linux. > > > > > >=20 > > > > > > Older SoCs (before A83T) have not been synchronized in over 3 y= ears. > > > > > > And I don't have any of this hardware to test. But there are no= t major > > > > > > changes to those devicetrees either. > > > > > >=20 > > > > > > The big motivation for including older SoCs in this update is c= onverting > > > > > > the USB PHY driver to get its VBUS detection GPIO/regulator fro= m the > > > > > > devicetree instead of from a pin name in Kconfig. Many older bo= ards had > > > > > > those properties added or fixed since the last devicetree sync.= This PHY > > > > > > driver change is necessary to complete the DM_GPIO migration. > > > > > >=20 > > > > > > A couple of breaking changes were made to several SoCs' devicet= rees in > > > > > > Linux relating to the "r_intc" interrupt controller. New kernel= s support > > > > > > old devicetrees, but not the other way around. So to be most co= mpatible > > > > > > 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 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. > > > > >=20 > > > > > 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. > > > > >=20 > > > > > 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. > > > > >=20 > > > > > 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 > > > >=20 > > > > So, this is I guess a bit annoying. But, we aren't at the point wh= ere > > > > 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! > > >=20 > > > While it sounds like the DTs are wildly out of date, this mostly affe= cts > > > 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. > > >=20 > > > At the moment I boot distro grubs and installers just fine, and witho= ut > > > losing any real functionality (minus suspend/resume, maybe). The > > > out-of-the-box default boot works now, and would break when pulling i= n the > > > pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, I= IUC), > > > can only deal with the older DTs (#interrupt-cells for r_intc must be= 2). > >=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 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? >=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. 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 Tom --wwSkEpePV3aFlXly Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmJsKvgACgkQFHw5/5Y0 tyzx7AwAnoICVrhsXLZv//AsQuxHRduO+c0WGZxRn2vZOr6rH2uSROro83KYzqYe XB+H8mH8zegQY9lMGlezUg+tFJamW5ZiL5vOYBUGQMpCs3qrogn05IkyNRq3pXyf y4wHX/ypgxspiJ0jqG+wLe2X2oO5Kdn3W83v5olJIsp3GcdUX0Vd14PizIZUWexu e/XQTTppLAm/1sgU8uUCZIpB/ZJE2DPLcJUxmasO3q8Qzs8QDVd9s+WTGPQRsKxP oF++i9OKyJroIz96xHDLrWYNg7Kd4kq2WdxXGAA9cvHK+aObA+iIuzA534BEj4EQ /FtUBmHMySJpwvBc4C5iWUo4hu4Du1NQIpd2ruTiEJBhyF98cH2vRr0+JJIU1KZu 9CCR33pK6/n8vsG+X0+23bv3K5zxc6xwmy0Ty/ajXLigLseNMcKXtA120q0XhVcx pyxuaN/wItFiD/Uzo1wxRIFvvYb2MyL+x/1soV3e4l7s7PgsfIE5oFsd/lWM1Jig T08PaInK =iHl+ -----END PGP SIGNATURE----- --wwSkEpePV3aFlXly--