From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9A86A2D7806 for ; Wed, 20 Aug 2025 08:42:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755679335; cv=none; b=kNGofl3+rN8D+SA/5NC5Z9MrGVZFI97s49lzPnugEIqVZA80yDX7KAIV8rCyNyGT8GLfO1TYD7deWCPLtphj3xrRXMCcLWIZ6QNX48JUq5CpYghiowVl2n0CNgH9g000oWo3SRhRqZPjZz2C7KS5kNkMukjkUNPkOpmHQ98B0hw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755679335; c=relaxed/simple; bh=zMxp/Y9NCrKDYrER4UyjAnXSn/8lzKPXQ7dHBNQTR30=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=crIRzFwsoiYRG227xHmjGsBkuvxhvEtjD/lzIq4dNFjbHslpV2czBXiR8V+vejuTcXgmRNWlhvSoahiDk3fQ0bT/MAQtM4o0bOFPhnIBSrbBOFX5TXJTXBELRXk9INFq9Cbh3m7O/+oFTezgws3Q1YqM+9bh5uO78pp/9NA2/n4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=fairphone.com; spf=pass smtp.mailfrom=fairphone.com; dkim=pass (2048-bit key) header.d=fairphone.com header.i=@fairphone.com header.b=Hisoo03y; arc=none smtp.client-ip=209.85.218.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=fairphone.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fairphone.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fairphone.com header.i=@fairphone.com header.b="Hisoo03y" Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-afcb73394b4so926483166b.0 for ; Wed, 20 Aug 2025 01:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fairphone.com; s=fair; t=1755679331; x=1756284131; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dETmxzysQAIIrfvzFS6NhiwZKV/rguUqMxZ2Lb2+BiA=; b=Hisoo03y9XPP464yOPXxVjUqj3dwzI25SNF2mh3om6L87mrSL1I5xseXAIYxPdKBah 5RqXOfK2i5/qLPMiB3BIezAA8BW/FUitmmeBZP78Dg3zLQjnW2GR0pUgZxyLiLSK4ho5 KLWWPPZgeSLCeMf6xUAFwNxBx1V8PnUuBTBN4lYlDw9mkWmOiBlLczleThtGSBjWw34N fkg2BAGdIr7YwKWut46Nc3C/lF1izmKhSjonPW7/CMlGok0JJs4zmNezrp82BIkgayOe Fhva+a1ixV6qGtSHTwapA54vX9olPxwaqCYBLVTXwaHGYP09zOkRBg6etgFL1C5+SiuC +WgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755679331; x=1756284131; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=dETmxzysQAIIrfvzFS6NhiwZKV/rguUqMxZ2Lb2+BiA=; b=q7f42T51YYyPM6MAIlNOgPZc6sCGHE0ELNRzCDKtH5M28KyhH+7unqqjUX5VIkgeEB qOQsMzj21aYUNqzyt9qfOp9RTPDBfnXrMnL+FAxqtoc7EkgLuXgINp43Uw/BIj/+Rigb CVhWTBS7NgZFg+Xq1jULZKrEmRF8C9udGa776NJWXLMNyQ1GWaE9rk5Tz75GeOv3Dk3Z BDKnW2e1z+Cb6lIEGHKzNZU7vTLuWFtLDQSpLQNIo0KOxPnnUs3KJpcELay2h94rm2Bo Ylmb26BnPWXOWzr+6Zp37w7iVCX9K+c6S6YkiszWApsLWpsvg5QsLQq3vC6mLPcZLVbG kv3w== X-Forwarded-Encrypted: i=1; AJvYcCXo3lxkAl0nkDcyTgsjN//ndui0hIE/aZ3UmYaUU69qrA3V4NNkIviA6MZYapKlTlGxnm/N79teTA==@vger.kernel.org X-Gm-Message-State: AOJu0YwO+rYgtsH4xaJ1yjd/nCdxb9zjjfvUr3H3dSNJbyRmlQuiGFNi L/MzsPoKQ38doMHehcLb7G7rGv2S3yQ20S3Puyc48dxb63HlyYDDWJl0+NdPJ2OupNE= X-Gm-Gg: ASbGncsL5EpApuVQl4/Oo33upowwBkmvBMRzQrvzP2LiK3zfPWsdJM5bWIMvE33eJd6 MTtULUdRIN7VIv6CuQUZAQfbRLFvPEKfIybrxKiCrjAvu8b7+7WVcNi+cgI6rOTI2//898VpUi9 sPt56LVCF7bnn3V3FF3TLnsVfeZ20OpFy4EACFEZZpJjRTN6Jj33yKciFNIJFzLFMEGqbXsITod mdfpTja7kRvZ6DhHlfZpukuKIPSKrZ2Z8KnoNjKPdKbbg5tW3kwJpopc8J0ImsZV6O3zkINSoPS M03UJwbhdWBX0SwTFvL93aSOcnVmn41p8Yg4bxaikmJBFdXWQs1zxJ0/ERyNzNSIv2+s2zsSlX2 HxPnhtJ/oFBC9esOIwtoXZyOUTdN2AQdccT2OKwCK4iQUQL4+AFXj3MElFLM7CAimBVY= X-Google-Smtp-Source: AGHT+IEac2OEaqE2OoGnweWa6iOptxoUoAiXM3h5Vw1WEpE7VDgBBgHTZqHGUTgnoBZuEdKM1TFNmg== X-Received: by 2002:a17:907:9715:b0:ae3:6f35:36fe with SMTP id a640c23a62f3a-afdf01e915cmr146724366b.47.1755679330638; Wed, 20 Aug 2025 01:42:10 -0700 (PDT) Received: from localhost (144-178-202-139.static.ef-service.nl. [144.178.202.139]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-afded478bf3sm138377366b.53.2025.08.20.01.42.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Aug 2025 01:42:10 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 20 Aug 2025 10:42:09 +0200 Message-Id: Cc: <~postmarketos/upstreaming@lists.sr.ht>, , , , , , , , , , Subject: Re: [PATCH v2 14/15] arm64: dts: qcom: Add initial Milos dtsi From: "Luca Weiss" To: "Konrad Dybcio" , "Will Deacon" , "Robin Murphy" , "Joerg Roedel" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , "Rafael J. Wysocki" , "Viresh Kumar" , "Manivannan Sadhasivam" , "Herbert Xu" , "David S. Miller" , "Vinod Koul" , "Bjorn Andersson" , "Konrad Dybcio" , "Robert Marko" , "Das Srinagesh" , "Thomas Gleixner" , "Jassi Brar" , "Amit Kucheria" , "Thara Gopinath" , "Daniel Lezcano" , "Zhang Rui" , "Lukasz Luba" , "Ulf Hansson" X-Mailer: aerc 0.20.1-0-g2ecb8770224a-dirty References: <20250713-sm7635-fp6-initial-v2-0-e8f9a789505b@fairphone.com> <20250713-sm7635-fp6-initial-v2-14-e8f9a789505b@fairphone.com> <3e0299ad-766a-4876-912e-438fe2cc856d@oss.qualcomm.com> <55420d89-fcd4-4cb5-a918-d8bbe2a03d19@oss.qualcomm.com> In-Reply-To: <55420d89-fcd4-4cb5-a918-d8bbe2a03d19@oss.qualcomm.com> Hi Konrad, On Sat Aug 2, 2025 at 2:04 PM CEST, Konrad Dybcio wrote: > On 7/29/25 8:49 AM, Luca Weiss wrote: >> Hi Konrad, >>=20 >> On Thu Jul 17, 2025 at 11:46 AM CEST, Luca Weiss wrote: >>> Hi Konrad, >>> >>> On Thu Jul 17, 2025 at 10:29 AM CEST, Luca Weiss wrote: >>>> On Mon Jul 14, 2025 at 1:06 PM CEST, Konrad Dybcio wrote: >>>>> On 7/13/25 10:05 AM, Luca Weiss wrote: >>>>>> Add a devicetree description for the Milos SoC, which is for example >>>>>> Snapdragon 7s Gen 3 (SM7635). >>>>>> >>>>>> Signed-off-by: Luca Weiss >>>>>> --- >>>>> >>>>> [...] >>>>>> + >>>>>> + spmi_bus: spmi@c400000 { >>>>>> + compatible =3D "qcom,spmi-pmic-arb"; >>>>> >>>>> There's two bus instances on this platform, check out the x1e binding >>>> >>>> Will do >>> >>> One problem: If we make the labels spmi_bus0 and spmi_bus1 then we can'= t >>> reuse the existing PMIC dtsi files since they all reference &spmi_bus. >>> >>> On FP6 everything's connected to PMIC_SPMI0_*, and PMIC_SPMI1_* is not >>> connected to anything so just adding the label spmi_bus on spmi_bus0 >>> would be fine. >>> >>> Can I add this to the device dts? Not going to be pretty though... >>> >>> diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/ar= m64/boot/dts/qcom/milos-fairphone-fp6.dts >>> index d12eaa585b31..69605c9ed344 100644 >>> --- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts >>> +++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts >>> @@ -11,6 +11,9 @@ >>> #include >>> #include >>> #include "milos.dtsi" >>> + >>> +spmi_bus: &spmi_bus0 {}; >>> + >>> #include "pm7550.dtsi" >>> #include "pm8550vs.dtsi" >>> #include "pmiv0104.dtsi" /* PMIV0108 */ >>> >>> Or I can add a second label for the spmi_bus0 as 'spmi_bus'. Not sure >>> other designs than SM7635 recommend using spmi_bus1 for some stuff. >>> >>> But I guess longer term we'd need to figure out a solution to this, how >>> to place a PMIC on a given SPMI bus, if reference designs start to >>> recommend putting different PMIC on the separate busses. >>=20 >> Any feedback on this regarding the spmi_bus label? > > I had an offline chat with Bjorn and we only came up with janky > solutions :) > > What you propose works well if the PMICs are all on bus0, which is > not the case for the newest platforms. If some instances are on bus0 > and others are on bus1, things get ugly really quick and we're going > to drown in #ifdefs. > > > An alternative that I've seen downstream is to define PMIC nodes in > the root of a dtsi file (not in the root of DT, i.e. NOT under / { }) > and do the following: > > &spmi_busN { > #include "pmABCDX.dtsi" > }; > > Which is "okay", but has the visible downside of having to define the > temp alarm thermal zone in each board's DT separately (and doing > mid-file includes which is.. fine I guess, but also something we avoided > upstream for the longest time) > > > Both are less than ideal when it comes to altering the SID under > "interrupts", fixing that would help immensely. We were hoping to > leverage something like Johan's work on drivers/mfd/qcom-pm8008.c, > but that seems like a longer term project. > > Please voice your opinions Since nobody else jumped in, how can we continue? One janky solution in my mind is somewhat similar to the PMxxxx_SID defines, doing something like "#define PM7550_SPMI spmi_bus0" and then using "&PM7550_SPMI {}" in the dtsi. I didn't try it so not sure that actually works but something like this should I imagine. But fortunately my Milos device doesn't have the problem that it actually uses both SPMI busses for different PMICs, so similar to other SoCs that already have two SPMI busses, I could somewhat ignore the problem and let someone else figure out how to actually place PMICs on spmi_bus0 and spmi_bus1 if they have such a hardware. Regards Luca > > Konrad