diff mbox

[v9,1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings

Message ID 56b9d5c38cfe46da1228c54f001a49773c3e31dc.1531531808.git.collinsd@codeaurora.org (mailing list archive)
State Not Applicable, archived
Delegated to: Andy Gross
Headers show

Commit Message

David Collins July 14, 2018, 1:50 a.m. UTC
Introduce bindings for RPMh regulator devices found on some
Qualcomm Technlogies, Inc. SoCs.  These devices allow a given
processor within the SoC to make PMIC regulator requests which
are aggregated within the RPMh hardware block along with requests
from other processors in the SoC to determine the final PMIC
regulator hardware state.

Signed-off-by: David Collins <collinsd@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
---
 .../bindings/regulator/qcom,rpmh-regulator.txt     | 160 +++++++++++++++++++++
 .../dt-bindings/regulator/qcom,rpmh-regulator.h    |  36 +++++
 2 files changed, 196 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
 create mode 100644 include/dt-bindings/regulator/qcom,rpmh-regulator.h

Comments

Doug Anderson July 23, 2018, 8:09 p.m. UTC | #1
Hi Mark,

On Fri, Jul 13, 2018 at 6:50 PM, David Collins <collinsd@codeaurora.org> wrote:
> Introduce bindings for RPMh regulator devices found on some
> Qualcomm Technlogies, Inc. SoCs.  These devices allow a given
> processor within the SoC to make PMIC regulator requests which
> are aggregated within the RPMh hardware block along with requests
> from other processors in the SoC to determine the final PMIC
> regulator hardware state.
>
> Signed-off-by: David Collins <collinsd@codeaurora.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> ---
>  .../bindings/regulator/qcom,rpmh-regulator.txt     | 160 +++++++++++++++++++++
>  .../dt-bindings/regulator/qcom,rpmh-regulator.h    |  36 +++++
>  2 files changed, 196 insertions(+)

I know you are still looking for time to review the RPMh-regulator
driver and that's fine.  One idea I had though: if the bindings look
OK to you and are less controversial, is there any chance they could
land in the meantime?

Specifically it would be very handy to be able to post up device tree
files that refer to regulators and even get those landed, but they
can't land without the bindings.

If that's not possible then no worries, but I figured I'd check.


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Brown July 24, 2018, 2:57 p.m. UTC | #2
On Mon, Jul 23, 2018 at 01:09:05PM -0700, Doug Anderson wrote:

> I know you are still looking for time to review the RPMh-regulator
> driver and that's fine.  One idea I had though: if the bindings look
> OK to you and are less controversial, is there any chance they could
> land in the meantime?

This appears to have a bunch of dependencies which I've got no idea
what's going on with the merging of and no idea if they'll affect the
bindings or anything, nobody's said anything and last I looked it was
unclear what was going on.  I'm kind of hoping that things might have
sorted themselves out of the merge window.

Some of the decisions in the code have flowed out into the bindings
before so I'm not keen to merge the bindings separately, and if the
driver for the thing used to communicate with the device is still in
review then that's definitely a red flag.
Doug Anderson July 24, 2018, 3:11 p.m. UTC | #3
Hi,

On Tue, Jul 24, 2018 at 7:57 AM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Jul 23, 2018 at 01:09:05PM -0700, Doug Anderson wrote:
>
>> I know you are still looking for time to review the RPMh-regulator
>> driver and that's fine.  One idea I had though: if the bindings look
>> OK to you and are less controversial, is there any chance they could
>> land in the meantime?
>
> This appears to have a bunch of dependencies which I've got no idea
> what's going on with the merging of and no idea if they'll affect the
> bindings or anything, nobody's said anything and last I looked it was
> unclear what was going on.

RPMh itself landed in Andy's tree and he sent a pull request on
Saturday.  Feel free to refer to the request ("[GIT PULL] Qualcomm
Driver updates for 4.19") AKA
<https://patchwork.kernel.org/patch/10539125/>.

It doesn't look like arm-soc has picked up Andy's pull request yet
though.  If having it in arm-soc is a requirement then I'm happy to
monitor arm-soc and ping this thread again when it's there.


> I'm kind of hoping that things might have
> sorted themselves out of the merge window.
>
> Some of the decisions in the code have flowed out into the bindings
> before so I'm not keen to merge the bindings separately,

Fair point.  I was thinking that we had pared the driver down enough
now that the bindings were no longer anything other than just
boilerplate bits describing the hardware, but it's obviously your
decision when you're happy to land them.


> and if the
> driver for the thing used to communicate with the device is still in
> review then that's definitely a red flag.

As per above it's been landed, so hopefully this red flag is removed?


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Brown July 24, 2018, 3:25 p.m. UTC | #4
On Tue, Jul 24, 2018 at 08:11:30AM -0700, Doug Anderson wrote:

> RPMh itself landed in Andy's tree and he sent a pull request on
> Saturday.  Feel free to refer to the request ("[GIT PULL] Qualcomm
> Driver updates for 4.19") AKA
> <https://patchwork.kernel.org/patch/10539125/>.

> It doesn't look like arm-soc has picked up Andy's pull request yet
> though.  If having it in arm-soc is a requirement then I'm happy to
> monitor arm-soc and ping this thread again when it's there.

There was also some other thing called command DB as well which was a
separate series.  Ideally there'd be a branch I could pull as there's a
build dependency on rpmh so I can't apply until the code has landed in
my tree, don't know what command DB is exactly.
Doug Anderson July 24, 2018, 3:43 p.m. UTC | #5
Hi,

On Tue, Jul 24, 2018 at 8:25 AM, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Jul 24, 2018 at 08:11:30AM -0700, Doug Anderson wrote:
>
>> RPMh itself landed in Andy's tree and he sent a pull request on
>> Saturday.  Feel free to refer to the request ("[GIT PULL] Qualcomm
>> Driver updates for 4.19") AKA
>> <https://patchwork.kernel.org/patch/10539125/>.
>
>> It doesn't look like arm-soc has picked up Andy's pull request yet
>> though.  If having it in arm-soc is a requirement then I'm happy to
>> monitor arm-soc and ping this thread again when it's there.
>
> There was also some other thing called command DB as well which was a
> separate series.  Ideally there'd be a branch I could pull as there's a
> build dependency on rpmh so I can't apply until the code has landed in
> my tree, don't know what command DB is exactly.

Yup.  That one landed in May and is already in mainline Linux.  Refer
to commit 312416d9171a ("drivers: qcom: add command DB driver").

Adding Andy to this thread (I guess he wasn't on it?).  Hopefully he
can provide you with the branch.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Brown July 24, 2018, 4:59 p.m. UTC | #6
On Tue, Jul 24, 2018 at 08:43:46AM -0700, Doug Anderson wrote:
> On Tue, Jul 24, 2018 at 8:25 AM, Mark Brown <broonie@kernel.org> wrote:

> > There was also some other thing called command DB as well which was a
> > separate series.  Ideally there'd be a branch I could pull as there's a
> > build dependency on rpmh so I can't apply until the code has landed in
> > my tree, don't know what command DB is exactly.

> Yup.  That one landed in May and is already in mainline Linux.  Refer
> to commit 312416d9171a ("drivers: qcom: add command DB driver").

That's good at least - the cover letter said it was still under review,
guess it just hadn't been updated.

> Adding Andy to this thread (I guess he wasn't on it?).  Hopefully he
> can provide you with the branch.

Andy?
Andy Gross July 26, 2018, 6:39 p.m. UTC | #7
+ olof

On Tue, Jul 24, 2018 at 05:59:42PM +0100, Mark Brown wrote:
> On Tue, Jul 24, 2018 at 08:43:46AM -0700, Doug Anderson wrote:
> > On Tue, Jul 24, 2018 at 8:25 AM, Mark Brown <broonie@kernel.org> wrote:
> 
> > > There was also some other thing called command DB as well which was a
> > > separate series.  Ideally there'd be a branch I could pull as there's a
> > > build dependency on rpmh so I can't apply until the code has landed in
> > > my tree, don't know what command DB is exactly.
> 
> > Yup.  That one landed in May and is already in mainline Linux.  Refer
> > to commit 312416d9171a ("drivers: qcom: add command DB driver").
> 
> That's good at least - the cover letter said it was still under review,
> guess it just hadn't been updated.
> 
> > Adding Andy to this thread (I guess he wasn't on it?).  Hopefully he
> > can provide you with the branch.
> 
Mark,

The arm-soc guys merged the Qualcomm pull requests.  So you can just use my
qcom-drivers-for-4.19 tag.  That won't change at this point.

git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git
qcom-drivers-for-4.19

Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Doug Anderson Aug. 6, 2018, 10:55 p.m. UTC | #8
Mark,

On Thu, Jul 26, 2018 at 11:39 AM, Andy Gross <andy.gross@linaro.org> wrote:
> + olof
>
> On Tue, Jul 24, 2018 at 05:59:42PM +0100, Mark Brown wrote:
>> On Tue, Jul 24, 2018 at 08:43:46AM -0700, Doug Anderson wrote:
>> > On Tue, Jul 24, 2018 at 8:25 AM, Mark Brown <broonie@kernel.org> wrote:
>>
>> > > There was also some other thing called command DB as well which was a
>> > > separate series.  Ideally there'd be a branch I could pull as there's a
>> > > build dependency on rpmh so I can't apply until the code has landed in
>> > > my tree, don't know what command DB is exactly.
>>
>> > Yup.  That one landed in May and is already in mainline Linux.  Refer
>> > to commit 312416d9171a ("drivers: qcom: add command DB driver").
>>
>> That's good at least - the cover letter said it was still under review,
>> guess it just hadn't been updated.
>>
>> > Adding Andy to this thread (I guess he wasn't on it?).  Hopefully he
>> > can provide you with the branch.
>>
> Mark,
>
> The arm-soc guys merged the Qualcomm pull requests.  So you can just use my
> qcom-drivers-for-4.19 tag.  That won't change at this point.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git
> qcom-drivers-for-4.19

Did Andy's idea of using the above tag work for you?  It appears that
there are a few patches you don't need there, but it shouldn't hurt to
pick them up too I think?  Here's what I see:

---

$ git log --oneline linux/master..qcom-drivers-for-4.19
78ee559d7fc6 (tag: qcom-drivers-for-4.19) soc: qcom: rmtfs-mem: fix
memleak in probe error paths
4da3b0452bc6 soc: qcom: llc-slice: Add missing MODULE_LICENSE()
6c805adf17d4 drivers: qcom: rpmh: fix unwanted error check for get_tcs_of_type()
efa1c257b3fc drivers: qcom: rpmh-rsc: fix the loop index check in
get_req_from_tcs
a0b1561f8461 firmware: qcom: scm: add a dummy qcom_scm_assign_mem()
fdd102b52cfd drivers: qcom: rpmh-rsc: Check cmd_db_ready() to help children
2de4b8d33eab drivers: qcom: rpmh-rsc: allow active requests from wake TCS
c8790cb6da58 drivers: qcom: rpmh: add support for batch RPMH request
564b5e24ccd4 drivers: qcom: rpmh: allow requests to be sent asynchronously
600513dfeef3 drivers: qcom: rpmh: cache sleep/wake state requests
9a3afcfbc0cc drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS
fa460e453a83 drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS
c1038456b02b drivers: qcom: rpmh: add RPMH helper functions
fc087fe5a45e drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE
2e4690a09fca dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs
658628e7ef78 drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs
a3134fb09e0b drivers: soc: Add LLCC driver
7e5700ae64f6 dt-bindings: Documentation for qcom, llcc
0b65c59e3a54 soc: qcom: smem: Correct check for global partition

---

It seems like it's too late to land RPMh-regulator for 4.19, so I
guess we'll have to aim for 4.20.  I'm not sure if that means you're
going to want to wait until 4.20-rc1 comes out to use as a base before
thinking about landing RPMh-regulator?  If so then I guess we've got
~3 weeks before something could land and we could start landing device
tree bits using RPMh-regulator.  If that's the plan then we'll
probably just start landing things in the Chrome OS tree now and suck
up the extra work of trying to resolve differences later...

Thanks!

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Brown Aug. 6, 2018, 11:55 p.m. UTC | #9
On Mon, Aug 06, 2018 at 03:55:53PM -0700, Doug Anderson wrote:
> On Thu, Jul 26, 2018 at 11:39 AM, Andy Gross <andy.gross@linaro.org> wrote:

> > The arm-soc guys merged the Qualcomm pull requests.  So you can just use my
> > qcom-drivers-for-4.19 tag.  That won't change at this point.

> > git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git
> > qcom-drivers-for-4.19

> Did Andy's idea of using the above tag work for you?  It appears that
> there are a few patches you don't need there, but it shouldn't hurt to
> pick them up too I think?  Here's what I see:

It does make my pull request look larger which is hard to get enthused
about.

> a3134fb09e0b drivers: soc: Add LLCC driver

Stuff like this jumped out for example.

> It seems like it's too late to land RPMh-regulator for 4.19, so I
> guess we'll have to aim for 4.20.  I'm not sure if that means you're
> going to want to wait until 4.20-rc1 comes out to use as a base before
> thinking about landing RPMh-regulator?  If so then I guess we've got

If I apply it after the merge window it's going to be based on -rc1.  If
I get to it this week I guess I'll have to pull in the drivers tag.
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
new file mode 100644
index 0000000..7ef2dbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
@@ -0,0 +1,160 @@ 
+Qualcomm Technologies, Inc. RPMh Regulators
+
+rpmh-regulator devices support PMIC regulator management via the Voltage
+Regulator Manager (VRM) and Oscillator Buffer (XOB) RPMh accelerators.  The APPS
+processor communicates with these hardware blocks via a Resource State
+Coordinator (RSC) using command packets.  The VRM allows changing three
+parameters for a given regulator: enable state, output voltage, and operating
+mode.  The XOB allows changing only a single parameter for a given regulator:
+its enable state.  Despite its name, the XOB is capable of controlling the
+enable state of any PMIC peripheral.  It is used for clock buffers, low-voltage
+switches, and LDO/SMPS regulators which have a fixed voltage and mode.
+
+=======================
+Required Node Structure
+=======================
+
+RPMh regulators must be described in two levels of device nodes.  The first
+level describes the PMIC containing the regulators and must reside within an
+RPMh device node.  The second level describes each regulator within the PMIC
+which is to be used on the board.  Each of these regulators maps to a single
+RPMh resource.
+
+The names used for regulator nodes must match those supported by a given PMIC.
+Supported regulator node names:
+	PM8998:		smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2
+	PMI8998:	bob
+	PM8005:		smps1 - smps4
+
+========================
+First Level Nodes - PMIC
+========================
+
+- compatible
+	Usage:      required
+	Value type: <string>
+	Definition: Must be one of: "qcom,pm8998-rpmh-regulators",
+		    "qcom,pmi8998-rpmh-regulators" or
+		    "qcom,pm8005-rpmh-regulators".
+
+- qcom,pmic-id
+	Usage:      required
+	Value type: <string>
+	Definition: RPMh resource name suffix used for the regulators found on
+		    this PMIC.  Typical values: "a", "b", "c", "d", "e", "f".
+
+- vdd-s1-supply
+- vdd-s2-supply
+- vdd-s3-supply
+- vdd-s4-supply
+	Usage:      optional (PM8998 and PM8005 only)
+	Value type: <phandle>
+	Definition: phandle of the parent supply regulator of one or more of the
+		    regulators for this PMIC.
+
+- vdd-s5-supply
+- vdd-s6-supply
+- vdd-s7-supply
+- vdd-s8-supply
+- vdd-s9-supply
+- vdd-s10-supply
+- vdd-s11-supply
+- vdd-s12-supply
+- vdd-s13-supply
+- vdd-l1-l27-supply
+- vdd-l2-l8-l17-supply
+- vdd-l3-l11-supply
+- vdd-l4-l5-supply
+- vdd-l6-supply
+- vdd-l7-l12-l14-l15-supply
+- vdd-l9-supply
+- vdd-l10-l23-l25-supply
+- vdd-l13-l19-l21-supply
+- vdd-l16-l28-supply
+- vdd-l18-l22-supply
+- vdd-l20-l24-supply
+- vdd-l26-supply
+- vin-lvs-1-2-supply
+	Usage:      optional (PM8998 only)
+	Value type: <phandle>
+	Definition: phandle of the parent supply regulator of one or more of the
+		    regulators for this PMIC.
+
+- vdd-bob-supply
+	Usage:      optional (PMI8998 only)
+	Value type: <phandle>
+	Definition: BOB regulator parent supply phandle
+
+===============================
+Second Level Nodes - Regulators
+===============================
+
+- qcom,always-wait-for-ack
+	Usage:      optional
+	Value type: <empty>
+	Definition: Boolean flag which indicates that the application processor
+		    must wait for an ACK or a NACK from RPMh for every request
+		    sent for this regulator including those which are for a
+		    strictly lower power state.
+
+Other properties defined in Documentation/devicetree/bindings/regulator.txt
+may also be used.  regulator-initial-mode and regulator-allowed-modes may be
+specified for VRM regulators using mode values from
+include/dt-bindings/regulator/qcom,rpmh-regulator.h.  regulator-allow-bypass
+may be specified for BOB type regulators managed via VRM.
+regulator-allow-set-load may be specified for LDO type regulators managed via
+VRM.
+
+========
+Examples
+========
+
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+&apps_rsc {
+	pm8998-rpmh-regulators {
+		compatible = "qcom,pm8998-rpmh-regulators";
+		qcom,pmic-id = "a";
+
+		vdd-l7-l12-l14-l15-supply = <&pm8998_s5>;
+
+		smps2 {
+			regulator-min-microvolt = <1100000>;
+			regulator-max-microvolt = <1100000>;
+		};
+
+		pm8998_s5: smps5 {
+			regulator-min-microvolt = <1904000>;
+			regulator-max-microvolt = <2040000>;
+		};
+
+		ldo7 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-allowed-modes =
+				<RPMH_REGULATOR_MODE_LPM
+				 RPMH_REGULATOR_MODE_HPM>;
+			regulator-allow-set-load;
+		};
+
+		lvs1 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+		};
+	};
+
+	pmi8998-rpmh-regulators {
+		compatible = "qcom,pmi8998-rpmh-regulators";
+		qcom,pmic-id = "b";
+
+		bob {
+			regulator-min-microvolt = <3312000>;
+			regulator-max-microvolt = <3600000>;
+			regulator-allowed-modes =
+				<RPMH_REGULATOR_MODE_AUTO
+				 RPMH_REGULATOR_MODE_HPM>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>;
+		};
+	};
+};
diff --git a/include/dt-bindings/regulator/qcom,rpmh-regulator.h b/include/dt-bindings/regulator/qcom,rpmh-regulator.h
new file mode 100644
index 0000000..86713dc
--- /dev/null
+++ b/include/dt-bindings/regulator/qcom,rpmh-regulator.h
@@ -0,0 +1,36 @@ 
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved. */
+
+#ifndef __QCOM_RPMH_REGULATOR_H
+#define __QCOM_RPMH_REGULATOR_H
+
+/*
+ * These mode constants may be used to specify modes for various RPMh regulator
+ * device tree properties (e.g. regulator-initial-mode).  Each type of regulator
+ * supports a subset of the possible modes.
+ *
+ * %RPMH_REGULATOR_MODE_RET:	Retention mode in which only an extremely small
+ *				load current is allowed.  This mode is supported
+ *				by LDO and SMPS type regulators.
+ * %RPMH_REGULATOR_MODE_LPM:	Low power mode in which a small load current is
+ *				allowed.  This mode corresponds to PFM for SMPS
+ *				and BOB type regulators.  This mode is supported
+ *				by LDO, HFSMPS, BOB, and PMIC4 FTSMPS type
+ *				regulators.
+ * %RPMH_REGULATOR_MODE_AUTO:	Auto mode in which the regulator hardware
+ *				automatically switches between LPM and HPM based
+ *				upon the real-time load current.  This mode is
+ *				supported by HFSMPS, BOB, and PMIC4 FTSMPS type
+ *				regulators.
+ * %RPMH_REGULATOR_MODE_HPM:	High power mode in which the full rated current
+ *				of the regulator is allowed.  This mode
+ *				corresponds to PWM for SMPS and BOB type
+ *				regulators.  This mode is supported by all types
+ *				of regulators.
+ */
+#define RPMH_REGULATOR_MODE_RET		0
+#define RPMH_REGULATOR_MODE_LPM		1
+#define RPMH_REGULATOR_MODE_AUTO	2
+#define RPMH_REGULATOR_MODE_HPM		3
+
+#endif