From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (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 17E14201033 for ; Mon, 6 Oct 2025 09:47:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759744076; cv=none; b=CSQKci+r5KtPmD+bnNHURp7nPqD30wUvcRkkMXd/lO4lbYJVb8bg7leT6Q/U77/x2WQQNLKP/64m2Dq9TyiHB/X+mYW9kcbMZu74EHmW9HH/bfESUXx3xw9kjNgz3QSHLFY6fZBFQNO8B3hhK9SRnLrzsQrI4fRmYEHBsMyLWAc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759744076; c=relaxed/simple; bh=NVc36TGbNflxbPQDRRl0haz/TUVlsWdECo1JWukAVH8=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=ErBmgGU7kwZzoFzznfDb5dxFJ2CsW1hz+LsbBUdhDfKebd1bdPx9Y1sqMKFMNqsb+XSJJBlVGqrS2TgoniKySQFDbj1vwTMLurFy5cTaxDELIjYFw3tM4s+km5sPPTg17ftpQ7mViPMEPpfmv6hdOMIa90wQInzFlT4RFgVQTHo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=pUyd3KOf; arc=none smtp.client-ip=209.85.208.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="pUyd3KOf" Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-631df7b2dffso10862948a12.1 for ; Mon, 06 Oct 2025 02:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1759744072; x=1760348872; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=NVc36TGbNflxbPQDRRl0haz/TUVlsWdECo1JWukAVH8=; b=pUyd3KOf/ViqPgLWXTuDX6y5+iT3/e1CzssaJt/0S5qJ7h0NuM+qMuOqhlmV2TceoV PSYCTE/FTbbGNMmAnB3UAudtb27GqkvXy81HmaZ91PkbpedDA8WDLrWvjCnyWtasnVCi JxbbTRUWzMDNvNQoHqvpHQ7xKCZpq3Q9NmYO76PGjQt+0e2Q5UlnJrGAYSZQqg0zeILK QoHGOSOMhoivtPtL4WlxEckSC8On0qEScBVFsWqmQ7G+V1NRycsXUcXucJol6bpa8VM+ oCLcj72Xo6FXcORA0cxXDJAFSQSO9m0Vb/grqt9ir3Yz7fBj3LBzaAGeHpVzwIUtGbLM 8qRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759744072; x=1760348872; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=NVc36TGbNflxbPQDRRl0haz/TUVlsWdECo1JWukAVH8=; b=WNNmMepwVRvdy7FOuUj5ajn+h9g7ZH9up9s+41O36BguqBI/PAwWo0JyrR2G7iD4j+ l1zh9uJjoSAWS7yFqzai/HCRgbkYRqiQoIiTK0MGNwwA2NSYDUSbGOko+Oy5EGCi2FA6 7FWvAvS95AJ5pXM66j0sPIeBR4QQg1uAFRAjmydsXIOSm6Bo+U1skT7/txOnKkM2F9r1 tvdbAMtyU9ptNxO5paSR6DtWpMyV/W+jN9Cq6z8tK7B9S3mM0dvhNQcG5hv9PsGUmKvG JoUT5sYAQsqfQbef0Cnw6SG6BpWmJtXy/FjDCPjeNYrfm68+dpENMjSRdqyHBarklbYe oKOw== X-Forwarded-Encrypted: i=1; AJvYcCVzv8Mq6pCtnB1b8keMG3fqBvFP78DRXnHEuB00B4p1qxAgu2Z+Fe3KzZolGyXB9lInTbExyt1ODRsfjz4=@vger.kernel.org X-Gm-Message-State: AOJu0YwyC0Uloj6WR//0JHg4antNdWDW12UExZKG9YexkOriVkXdZIEO 3A7A/1evKn4EaugO6vMAGhxGoPQj321yQ5w13ksQsaHtI63/kJYL3Jvmz3JSQas1f90= X-Gm-Gg: ASbGncu2SiYYzdp2HZKv55EAea0dom9sjq6iT4pOp4obWzqsEiRg+5HuYy5v6voYEoc jaX2AKHXA0jWvptHKuBrtH+TtMIOXDNzVYvti6zET/NvoOextHjsD1sQROcC/as0rcIjgHmJ+el iPCl7k7LykiW8upH52sAXVgW+N4IobbdPr+NYxkxivLZdeszE5a4XTOMaSwRvNOBykdkWJsadxT w8NEImsvV0cpqSV9UTndXJZBJyLdDmy/1+ZNOOFxqVAauVsKRR7rJfoFVtASKtc2PFv78gek6Db tbo030618Wwn3BuSP6RSXYLp9YGJeA2Q4Pcmk7PperA9Tq+aOKf8cOb1amhxFZDXdclghrg35UM oNXLbF3pr5MpqZz3NY2j1bCuK7KvqCvXDUg6YAra6tv400GO4oeTFvw== X-Google-Smtp-Source: AGHT+IFtzyuEM86nDZ1afipZ9gjtIoBXDJIw39RxT9KiIYyBACUqX8txUSjLeqwb6sRvJD4CXeYSfA== X-Received: by 2002:a05:6402:13d6:b0:636:6e11:2fd1 with SMTP id 4fb4d7f45d1cf-638fcb65499mr14959712a12.4.1759744072376; Mon, 06 Oct 2025 02:47:52 -0700 (PDT) Received: from draszik.lan ([80.111.64.44]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6378811f14bsm9884430a12.45.2025.10.06.02.47.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Oct 2025 02:47:51 -0700 (PDT) Message-ID: Subject: Re: [PATCH v2 02/17] regulator: dt-bindings: add s2mpg10-pmic regulators From: =?ISO-8859-1?Q?Andr=E9?= Draszik To: Krzysztof Kozlowski Cc: Tudor Ambarus , Rob Herring , Conor Dooley , Liam Girdwood , Mark Brown , Lee Jones , Linus Walleij , Bartosz Golaszewski , Peter Griffin , Will McVicker , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio@vger.kernel.org Date: Mon, 06 Oct 2025 10:47:50 +0100 In-Reply-To: <20250611-statuesque-dolphin-of-felicity-6fbf54@kuoka> References: <20250606-s2mpg1x-regulators-v2-0-b03feffd2621@linaro.org> <20250606-s2mpg1x-regulators-v2-2-b03feffd2621@linaro.org> <20250611-statuesque-dolphin-of-felicity-6fbf54@kuoka> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2-2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hi Krzysztof, On Wed, 2025-06-11 at 10:55 +0200, Krzysztof Kozlowski wrote: > On Fri, Jun 06, 2025 at 04:02:58PM GMT, Andr=C3=A9 Draszik wrote: > > The S2MPG10 PMIC is a Power Management IC for mobile applications with > > buck converters, various LDOs, power meters, RTC, clock outputs, and > > additional GPIO interfaces. > >=20 > > It has 10 buck and 31 LDO rails. Several of these can either be > > controlled via software or via external signals, e.g. input pins > > connected to a main processor's GPIO pins. > >=20 > > Add documentation related to the regulator (buck & ldo) parts like > > devicetree definitions, regulator naming patterns, and additional > > properties. > >=20 > > S2MPG10 is typically used as the main-PMIC together with an S2MPG11 > > PMIC in a main/sub configuration, hence the datasheet and the binding > > both suffix the rails with an 'm'. > >=20 > > Signed-off-by: Andr=C3=A9 Draszik > >=20 > > --- > > v2: > > - drop | (literal style mark) from samsung,ext-control-gpios > > =C2=A0 description > > --- > > =C2=A0.../regulator/samsung,s2mpg10-regulator.yaml=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 | 147 +++++++++++++++++++++ > > =C2=A0MAINTAINERS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 1 + > > =C2=A0.../regulator/samsung,s2mpg10-regulator.h=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 48 +++++++ > > =C2=A03 files changed, 196 insertions(+) > >=20 > > diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mpg1= 0-regulator.yaml > > b/Documentation/devicetree/bindings/regulator/samsung,s2mpg10-regulator= .yaml > > new file mode 100644 > > index 0000000000000000000000000000000000000000..82f2b06205e9bdb15cf90b1= e896fe52c335c52c4 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mpg10-regul= ator.yaml > > @@ -0,0 +1,147 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/regulator/samsung,s2mpg10-regulator= .yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Samsung S2MPG10 Power Management IC regulators > > + > > +maintainers: > > +=C2=A0 - Andr=C3=A9 Draszik > > + > > +description: | > > +=C2=A0 This is part of the device tree bindings for the S2MG10 Power M= anagement IC > > +=C2=A0 (PMIC). > > + > > +=C2=A0 The S2MPG10 PMIC provides 10 buck and 31 LDO regulators. > > + > > +=C2=A0 See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.= yaml for > > +=C2=A0 additional information and example. > > + > > +definitions: > > +=C2=A0 s2mpg10-ext-control: > > +=C2=A0=C2=A0=C2=A0 properties: > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 samsung,ext-control: > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description: | > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 These rails can= be controlled via one of several possible external > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (hardware) sign= als. If so, this property configures the signal the PMIC > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 should monitor.= For S2MPG10 rails where external control is possible other > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 than ldo20m, th= e following values generally corresponding to the > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 respective on-c= hip pin are valid: > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 0= # S2MPG10_PCTRLSEL_ON - always on > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 1= # S2MPG10_PCTRLSEL_PWREN - PWREN pin > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 2= # S2MPG10_PCTRLSEL_PWREN_TRG - PWREN_TRG bit in MIMICKING_CTRL > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 3= # S2MPG10_PCTRLSEL_PWREN_MIF - PWREN_MIF pin > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 4= # S2MPG10_PCTRLSEL_PWREN_MIF_TRG - PWREN_MIF_TRG bit in MIMICKING_CTRL > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 5= # S2MPG10_PCTRLSEL_AP_ACTIVE_N - ~AP_ACTIVE_N pin > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 6= # S2MPG10_PCTRLSEL_AP_ACTIVE_N_TRG - ~AP_ACTIVE_N_TRG bit in MIMICKING_CTR= L > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 7= # S2MPG10_PCTRLSEL_CPUCL1_EN - CPUCL1_EN pin > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 8= # S2MPG10_PCTRLSEL_CPUCL1_EN2 - CPUCL1_EN & PWREN pins > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 9= # S2MPG10_PCTRLSEL_CPUCL2_EN - CPUCL2_EN pin > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 1= 0 # S2MPG10_PCTRLSEL_CPUCL2_EN2 - CPUCL2_E2 & PWREN pins > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 1= 1 # S2MPG10_PCTRLSEL_TPU_EN - TPU_EN pin > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 1= 2 # S2MPG10_PCTRLSEL_TPU_EN2 - TPU_EN & ~AP_ACTIVE_N pins > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 1= 3 # S2MPG10_PCTRLSEL_TCXO_ON - TCXO_ON pin > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 1= 4 # S2MPG10_PCTRLSEL_TCXO_ON2 - TCXO_ON & ~AP_ACTIVE_N pins > > + > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For S2MPG10 ldo= 20m, the following values are valid > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 0= # S2MPG10_PCTRLSEL_LDO20M_ON - always on >=20 > No, use standard regulator properties - regulator-always-on >=20 >=20 > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 1= # S2MPG10_PCTRLSEL_LDO20M_EN_SFR - VLDO20M_EN & LDO20M_SFR > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 2= # S2MPG10_PCTRLSEL_LDO20M_EN - VLDO20M_EN pin > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 3= # S2MPG10_PCTRLSEL_LDO20M_SFR - LDO20M_SFR in LDO_CTRL1 register > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 4= # S2MPG10_PCTRLSEL_LDO20M_OFF - disable >=20 > I don't think we allowed such property in the past. I've done some more investigation now - the reason we need to configure control of rails via signals (i.e. input pin on S2MPG1x) is that the PMU and power domains in particular control at least some of them. As an example, power domain g3d disable toggles an output pin on GS101, which is connected to the G3D_EN pin on S2MPG1x on Pixel. The regulator driver needs to configure all the G3D-related-PMIC rails to react to this signal. There a) is a large amount of flexibility as to which rail should react to which signal, and b) the bootloader doesn't configure (all of) them. Therefore, we need to be able to specify which rail should be controlled by which signal, both in DT and in the driver. The alternative would be do add explicit (driver-based) regulator control for each power domain, rather than having the PMU handle this. Such an approach appears suboptimal, because after all that's what the PMU is for. Additionally, there are sequencing requirements on enabling/disabling rails and when using the signals, the PMIC will ensure they're followed, whereas a driver would have to duplicate that information and could get it a) wrong= , b) would use more CPU cycles due to additional code, and c) leave the rail on for longer than necessarily due to timer resolution. Also, it might not work in all cases, e.g. if the PMU disables the rail for the CPU, the Linux driver can not afterwards disable the PMIC rail anymore, leaving it unnecessarily enabled. Equally, the Linux driver can not disable the rail before turning off the power domain, as once the rail is off, the CPU/Linux can not execute any further code. Hope the above justifies the introduction of this property :-) Cheers, Andre'