[1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding

Commit Message

Bjorn Andersson May 27, 2014, 5:28 p.m. UTC

Add binding for the Qualcomm Resource Power Manager (RPM) found in 8660, 8960
and 8064 based devices. The binding currently describes the rpm itself and the
regulator subnodes.

Signed-off-by: Bjorn Andersson <[e-mail]>
---
 Documentation/devicetree/bindings/mfd/qcom,rpm.txt | 284 +++++++++++++++++++++
 include/dt-bindings/mfd/qcom_rpm.h                 | 142 +++++++++++
 2 files changed, 426 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/qcom,rpm.txt
 create mode 100644 include/dt-bindings/mfd/qcom_rpm.h

Comments

Kumar Gala May 28, 2014, 4:34 p.m. UTC | #1

On May 27, 2014, at 12:28 PM, Bjorn Andersson <[e-mail]> wrote:

> Add binding for the Qualcomm Resource Power Manager (RPM) found in 8660, 8960
> and 8064 based devices. The binding currently describes the rpm itself and the
> regulator subnodes.
> 
> Signed-off-by: Bjorn Andersson <[e-mail]>
> ---
> Documentation/devicetree/bindings/mfd/qcom,rpm.txt | 284 +++++++++++++++++++++
> include/dt-bindings/mfd/qcom_rpm.h                 | 142 +++++++++++
> 2 files changed, 426 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/qcom,rpm.txt
> create mode 100644 include/dt-bindings/mfd/qcom_rpm.h
> 
> diff --git a/Documentation/devicetree/bindings/mfd/qcom,rpm.txt b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt
> new file mode 100644
> index 0000000..3908a5d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt
> @@ -0,0 +1,284 @@
> +Qualcomm Resource Power Manager (RPM)
> +
> +This driver is used to interface with the Resource Power Manager (RPM) found in
> +various Qualcomm platforms. The RPM allows each component in the system to vote
> +for state of the system resources, such as clocks, regulators and bus
> +frequencies.
> +
> +- compatible:
> +	Usage: required
> +	Value type: <string>
> +	Definition: must be one of:
> +		    "qcom,rpm-apq8064"
> +		    "qcom,rpm-msm8660"
> +		    "qcom,rpm-msm8960"
> +
> +- reg:
> +	Usage: required
> +	Value type: <prop-encoded-array>
> +	Definition: two entries specifying the RPM's message ram and ipc register
> +
> +- reg-names:
> +	Usage: required
> +	Value type: <string-array>
> +	Definition: must contain the following, in order:
> +		    "msg_ram"
> +		    “ipc"

If order maters, it should be on reg not reg-names.  If order doesn’t mater than this should say the names should match the reg

> +
> +- interrupts:
> +	Usage: required
> +	Value type: <prop-encoded-array>
> +	Definition: three entries specifying the RPM's:
> +		    1. acknowledgement interrupt
> +		    2. error interrupt
> +		    3. wakeup interrupt
> +
> +- interrupt-names:
> +	Usage: required
> +	Value type: <string-array>
> +	Definition: must be the three strings "ack", "err" and "wakeup", in order

again, if order maters it should be with the interrupts prop, not the name.

> +
> +- #address-cells:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: must be 1
> +
> +- #size-cells:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: must be 0
> +
> +
> += SUBDEVICES
> +
> +The RPM exposes resources to its subnodes. The below bindings specify the set
> +of valid subnodes that can operate on these resources.
> +
> +== Switch-mode Power Supply regulator
> +
> +- compatible:
> +	Usage: required
> +	Value type: <string>
> +	Definition: must be one of:
> +		    "qcom,rpm-pm8058-smps"
> +		    "qcom,rpm-pm8901-ftsmps"
> +		    "qcom,rpm-pm8921-smps"
> +		    "qcom,rpm-pm8921-ftsmps"
> +
> +- reg:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: resource as defined in <dt-bindings/mfd/qcom_rpm.h>

Can we provide a bit more description about what “namespace” this reg is work in.

> +
> +- qcom,switch-mode-frequency:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: Frequency (Hz) of the switch-mode power supply;
> +		    must be one of:
> +		    19200000, 9600000, 6400000, 4800000, 3840000, 3200000,
> +		    2740000, 2400000, 2130000, 1920000, 1750000, 1600000,
> +		    1480000, 1370000, 1280000, 1200000
> +
> +- qcom,hpm-threshold:
> +	Usage: optional
> +	Value type: <u32>
> +	Definition: indicates the breaking point at which the regulator should
> +	            switch to high power mode

in what units?

> +
> +- qcom,load-bias:
> +	Usage: optional
> +	Value type: <u32>
> +	Definition: specifies a base load on the specific regulator

in what units?

> +
> +- qcom,boot-load:
> +	Usage: optional
> +	Value type: <u32>
> +	Definition: specifies the configured load on boot for the specific
> +	            regulator

in what units?

> +
> +- qcom,force-mode-none:
> +	Usage: optional (default if no other qcom,force-mode is specified)
> +	Value type: <empty>
> +	Defintion: indicates that the regulator should not be forced to any
> +	           particular mode
> +
> +- qcom,force-mode-lpm:
> +	Usage: optional
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be forced to operate in
> +	            low-power-mode
> +
> +- qcom,force-mode-auto:
> +	Usage: optional (only available for 8960/8064)
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be automatically pick
> +	            operating mode
> +
> +- qcom,force-mode-hpm:
> +	Usage: optional (only available for 8960/8064)
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be forced to operate in
> +	            high-power-mode
> +
> +- qcom,force-mode-bypass: (only for 8960/8064)
> +	Usage: optional (only available for 8960/8064)
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be forced to operate in
> +	            bypass mode
> +

Is force-mode really an enum?  Or can we really have multiple force-mode’s set?

> +- qcom,power-mode-hysteretic:
> +	Usage: optional
> +	Value type: <empty>
> +	Definition: indicates that the power supply should operate in hysteretic
> +		    mode (defaults to qcom,power-mode-pwm if not specified)
> +
> +- qcom,power-mode-pwm:
> +	Usage: optional
> +	Value type: <empty>
> +	Definition: indicates that the power supply should operate in pwm mode
> +

Same question here is power-mode either pwm or hysteretic or can we set both?

> +Standard regulator bindings are used inside switch mode power supply subnodes.
> +Check Documentation/devicetree/bindings/regulator/regulator.txt for more
> +details.
> +
> +== Low-dropout regulator
> +
> +- compatible:
> +	Usage: required
> +	Value type: <string>
> +	Definition: must be one of:
> +		    "qcom,rpm-pm8058-pldo"
> +		    "qcom,rpm-pm8058-nldo"
> +		    "qcom,rpm-pm8901-pldo"
> +		    "qcom,rpm-pm8901-nldo"
> +		    "qcom,rpm-pm8921-pldo"
> +		    "qcom,rpm-pm8921-nldo"
> +		    "qcom,rpm-pm8921-nldo1200"
> +
> +- reg:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: resource as defined in <dt-bindings/mfd/qcom_rpm.h>
> +
> +- qcom,hpm-threshold:
> +	Usage: optional
> +	Value type: <u32>
> +	Definition: indicates the breaking point at which the regulator should
> +	            switch to high power mode
> +
> +- qcom,load-bias:
> +	Usage: optional
> +	Value type: <u32>
> +	Definition: specifies a base load on the specific regulator
> +
> +- qcom,boot-load:
> +	Usage: optional
> +	Value type: <u32>
> +	Definition: specifies the configured load on boot for the specific
> +	            regulator
> +
> +- qcom,force-mode-none:
> +	Usage: optional (default if no other qcom,force-mode is specified)
> +	Value type: <empty>
> +	Defintion: indicates that the regulator should not be forced to any
> +	           particular mode
> +
> +- qcom,force-mode-lpm:
> +	Usage: optional
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be forced to operate in
> +	            low-power-mode
> +
> +- qcom,force-mode-auto:
> +	Usage: optional (only available for 8960/8064)
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be automatically pick
> +	            operating mode
> +
> +- qcom,force-mode-hpm:
> +	Usage: optional (only available for 8960/8064)
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be forced to operate in
> +	            high-power-mode
> +
> +- qcom,force-mode-bypass: (only for 8960/8064)
> +	Usage: optional (only available for 8960/8064)
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be forced to operate in
> +	            bypass mode
> +
> +Standard regulator bindings are used inside switch low-dropout regulator
> +subnodes.  Check Documentation/devicetree/bindings/regulator/regulator.txt for
> +more details.
> +
> +== Negative Charge Pump
> +
> +- compatible:
> +	Usage: required
> +	Value type: <string>
> +	Definition: must be one of:
> +		    "qcom,rpm-pm8058-ncp"
> +		    "qcom,rpm-pm8921-ncp"
> +		    "qcom,rpm-pm8921-nldo1200"
> +
> +- reg:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: resource as defined in <dt-bindings/mfd/qcom_rpm.h>
> +
> +- qcom,switch-mode-frequency:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: Frequency (Hz) of the swith mode power supply;
> +		    must be one of:
> +		    19200000, 9600000, 6400000, 4800000, 3840000, 3200000,
> +		    2740000, 2400000, 2130000, 1920000, 1750000, 1600000,
> +		    1480000, 1370000, 1280000, 1200000
> +
> +Standard regulator bindings are used inside negative charge pump regulator
> +subnodes.  Check Documentation/devicetree/bindings/regulator/regulator.txt for
> +more details.
> +
> +== Switch
> +
> +- compatible:
> +	Usage: required
> +	Value type: <string>
> +	Definition: must be one of:
> +		    "qcom,rpm-pm8058-switch"
> +		    "qcom,rpm-pm8901-switch"
> +		    "qcom,rpm-pm8921-switch"
> +
> +- reg:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: resource as defined in <dt-bindings/mfd/qcom_rpm.h>
> +
> +
> += EXAMPLE
> +
> +	#include <dt-bindings/mfd/qcom_rpm.h>
> +
> +	rpm@108000 {
> +		compatible = "qcom,rpm-msm8960";
> +		reg = <0x108000 0x1000 0x2011008 0x4>;
> +
> +		interrupts = <0 19 0>, <0 21 0>, <0 22 0>;
> +		interrupt-names = "ack", "err", "wakeup";
> +
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		pm8921_s1: pm8921-s1 {
> +			compatible = "qcom,rpm-pm8921-smps";
> +			reg = <QCOM_RPM_PM8921_S1>;
> +
> +			regulator-min-microvolt = <1225000>;
> +			regulator-max-microvolt = <1225000>;
> +			regulator-always-on;
> +
> +			qcom,switch-mode-frequency = <3200000>;
> +			qcom,hpm-threshold = <100000>;
> +		};
> +	};
> +
> diff --git a/include/dt-bindings/mfd/qcom_rpm.h b/include/dt-bindings/mfd/qcom_rpm.h
> new file mode 100644
> index 0000000..277e789
> --- /dev/null
> +++ b/include/dt-bindings/mfd/qcom_rpm.h
> @@ -0,0 +1,142 @@
> +/*
> + * This header provides constants for the Qualcomm RPM bindings.
> + */
> +
> +#ifndef _DT_BINDINGS_MFD_QCOM_RPM_H
> +#define _DT_BINDINGS_MFD_QCOM_RPM_H
> +
> +#define QCOM_RPM_APPS_FABRIC_ARB		1
> +#define QCOM_RPM_APPS_FABRIC_CLK		2
> +#define QCOM_RPM_APPS_FABRIC_HALT		3
> +#define QCOM_RPM_APPS_FABRIC_IOCTL		4
> +#define QCOM_RPM_APPS_FABRIC_MODE		5
> +#define QCOM_RPM_APPS_L2_CACHE_CTL		6
> +#define QCOM_RPM_CFPB_CLK			7
> +#define QCOM_RPM_CXO_BUFFERS			8
> +#define QCOM_RPM_CXO_CLK			9
> +#define QCOM_RPM_DAYTONA_FABRIC_CLK		10
> +#define QCOM_RPM_DDR_DMM			11
> +#define QCOM_RPM_EBI1_CLK			12
> +#define QCOM_RPM_HDMI_SWITCH			13
> +#define QCOM_RPM_MMFPB_CLK			14
> +#define QCOM_RPM_MM_FABRIC_ARB			15
> +#define QCOM_RPM_MM_FABRIC_CLK			16
> +#define QCOM_RPM_MM_FABRIC_HALT			17
> +#define QCOM_RPM_MM_FABRIC_IOCTL		18
> +#define QCOM_RPM_MM_FABRIC_MODE			19
> +#define QCOM_RPM_PLL_4				20
> +#define QCOM_RPM_PM8058_LDO0			21
> +#define QCOM_RPM_PM8058_LDO1			22
> +#define QCOM_RPM_PM8058_LDO2			23
> +#define QCOM_RPM_PM8058_LDO3			24
> +#define QCOM_RPM_PM8058_LDO4			25
> +#define QCOM_RPM_PM8058_LDO5			26
> +#define QCOM_RPM_PM8058_LDO6			27
> +#define QCOM_RPM_PM8058_LDO7			28
> +#define QCOM_RPM_PM8058_LDO8			29
> +#define QCOM_RPM_PM8058_LDO9			30
> +#define QCOM_RPM_PM8058_LDO10			31
> +#define QCOM_RPM_PM8058_LDO11			32
> +#define QCOM_RPM_PM8058_LDO12			33
> +#define QCOM_RPM_PM8058_LDO13			34
> +#define QCOM_RPM_PM8058_LDO14			35
> +#define QCOM_RPM_PM8058_LDO15			36
> +#define QCOM_RPM_PM8058_LDO16			37
> +#define QCOM_RPM_PM8058_LDO17			38
> +#define QCOM_RPM_PM8058_LDO18			39
> +#define QCOM_RPM_PM8058_LDO19			40
> +#define QCOM_RPM_PM8058_LDO20			41
> +#define QCOM_RPM_PM8058_LDO21			42
> +#define QCOM_RPM_PM8058_LDO22			43
> +#define QCOM_RPM_PM8058_LDO23			44
> +#define QCOM_RPM_PM8058_LDO24			45
> +#define QCOM_RPM_PM8058_LDO25			46
> +#define QCOM_RPM_PM8058_LVS0			47
> +#define QCOM_RPM_PM8058_LVS1			48
> +#define QCOM_RPM_PM8058_NCP			49
> +#define QCOM_RPM_PM8058_SMPS0			50
> +#define QCOM_RPM_PM8058_SMPS1			51
> +#define QCOM_RPM_PM8058_SMPS2			52
> +#define QCOM_RPM_PM8058_SMPS3			53
> +#define QCOM_RPM_PM8058_SMPS4			54
> +#define QCOM_RPM_PM8821_L1			55
> +#define QCOM_RPM_PM8821_S1			56
> +#define QCOM_RPM_PM8821_S2			57
> +#define QCOM_RPM_PM8901_LDO0			58
> +#define QCOM_RPM_PM8901_LDO1			59
> +#define QCOM_RPM_PM8901_LDO2			60
> +#define QCOM_RPM_PM8901_LDO3			61
> +#define QCOM_RPM_PM8901_LDO4			62
> +#define QCOM_RPM_PM8901_LDO5			63
> +#define QCOM_RPM_PM8901_LDO6			64
> +#define QCOM_RPM_PM8901_LVS0			65
> +#define QCOM_RPM_PM8901_LVS1			66
> +#define QCOM_RPM_PM8901_LVS2			67
> +#define QCOM_RPM_PM8901_LVS3			68
> +#define QCOM_RPM_PM8901_MVS			69
> +#define QCOM_RPM_PM8901_SMPS0			70
> +#define QCOM_RPM_PM8901_SMPS1			71
> +#define QCOM_RPM_PM8901_SMPS2			72
> +#define QCOM_RPM_PM8901_SMPS3			73
> +#define QCOM_RPM_PM8901_SMPS4			74
> +#define QCOM_RPM_PM8921_CLK1			75
> +#define QCOM_RPM_PM8921_CLK2			76
> +#define QCOM_RPM_PM8921_L1			77
> +#define QCOM_RPM_PM8921_L2			78
> +#define QCOM_RPM_PM8921_L3			79
> +#define QCOM_RPM_PM8921_L4			80
> +#define QCOM_RPM_PM8921_L5			81
> +#define QCOM_RPM_PM8921_L6			82
> +#define QCOM_RPM_PM8921_L7			83
> +#define QCOM_RPM_PM8921_L8			84
> +#define QCOM_RPM_PM8921_L9			85
> +#define QCOM_RPM_PM8921_L10			86
> +#define QCOM_RPM_PM8921_L11			87
> +#define QCOM_RPM_PM8921_L12			88
> +#define QCOM_RPM_PM8921_L13			89
> +#define QCOM_RPM_PM8921_L14			90
> +#define QCOM_RPM_PM8921_L15			91
> +#define QCOM_RPM_PM8921_L16			92
> +#define QCOM_RPM_PM8921_L17			93
> +#define QCOM_RPM_PM8921_L18			94
> +#define QCOM_RPM_PM8921_L19			95
> +#define QCOM_RPM_PM8921_L20			96
> +#define QCOM_RPM_PM8921_L21			97
> +#define QCOM_RPM_PM8921_L22			98
> +#define QCOM_RPM_PM8921_L23			99
> +#define QCOM_RPM_PM8921_L24			100
> +#define QCOM_RPM_PM8921_L25			101
> +#define QCOM_RPM_PM8921_L26			102
> +#define QCOM_RPM_PM8921_L27			103
> +#define QCOM_RPM_PM8921_L28			104
> +#define QCOM_RPM_PM8921_L29			105
> +#define QCOM_RPM_PM8921_LVS1			106
> +#define QCOM_RPM_PM8921_LVS2			107
> +#define QCOM_RPM_PM8921_LVS3			108
> +#define QCOM_RPM_PM8921_LVS4			109
> +#define QCOM_RPM_PM8921_LVS5			110
> +#define QCOM_RPM_PM8921_LVS6			111
> +#define QCOM_RPM_PM8921_LVS7			112
> +#define QCOM_RPM_PM8921_MVS			113
> +#define QCOM_RPM_PM8921_NCP			114
> +#define QCOM_RPM_PM8921_S1			115
> +#define QCOM_RPM_PM8921_S2			116
> +#define QCOM_RPM_PM8921_S3			117
> +#define QCOM_RPM_PM8921_S4			118
> +#define QCOM_RPM_PM8921_S5			119
> +#define QCOM_RPM_PM8921_S6			120
> +#define QCOM_RPM_PM8921_S7			121
> +#define QCOM_RPM_PM8921_S8			122
> +#define QCOM_RPM_PXO_CLK			123
> +#define QCOM_RPM_QDSS_CLK			124
> +#define QCOM_RPM_SFPB_CLK			125
> +#define QCOM_RPM_SMI_CLK			126
> +#define QCOM_RPM_SYS_FABRIC_ARB			127
> +#define QCOM_RPM_SYS_FABRIC_CLK			128
> +#define QCOM_RPM_SYS_FABRIC_HALT		129
> +#define QCOM_RPM_SYS_FABRIC_IOCTL		130
> +#define QCOM_RPM_SYS_FABRIC_MODE		131
> +#define QCOM_RPM_USB_OTG_SWITCH			132
> +#define QCOM_RPM_VDDMIN_GPIO			133

Are these values arbitrary or do they mean something to hw?

> +
> +#endif
> -- 
> 1.8.2.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Srinivas Kandagatla May 29, 2014, 4:19 p.m. UTC | #2

Hi Bjorn,

On 27/05/14 18:28, Bjorn Andersson wrote:
> Add binding for the Qualcomm Resource Power Manager (RPM) found in 8660, 8960
> and 8064 based devices. The binding currently describes the rpm itself and the
> regulator subnodes.
>
> Signed-off-by: Bjorn Andersson <[e-mail]>
> ---
>   Documentation/devicetree/bindings/mfd/qcom,rpm.txt | 284 +++++++++++++++++++++
>   include/dt-bindings/mfd/qcom_rpm.h                 | 142 +++++++++++
>   2 files changed, 426 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/mfd/qcom,rpm.txt
>   create mode 100644 include/dt-bindings/mfd/qcom_rpm.h
>
> diff --git a/Documentation/devicetree/bindings/mfd/qcom,rpm.txt b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt
> new file mode 100644
> index 0000000..3908a5d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt
> @@ -0,0 +1,284 @@
> +Qualcomm Resource Power Manager (RPM)
> +
> +This driver is used to interface with the Resource Power Manager (RPM) found in
> +various Qualcomm platforms. The RPM allows each component in the system to vote
> +for state of the system resources, such as clocks, regulators and bus
> +frequencies.
> +
> +- compatible:
> +	Usage: required
> +	Value type: <string>
> +	Definition: must be one of:
> +		    "qcom,rpm-apq8064"
> +		    "qcom,rpm-msm8660"
> +		    "qcom,rpm-msm8960"
> +
> +- reg:
> +	Usage: required
> +	Value type: <prop-encoded-array>
> +	Definition: two entries specifying the RPM's message ram and ipc register
> +
> +- reg-names:
> +	Usage: required
> +	Value type: <string-array>
> +	Definition: must contain the following, in order:
> +		    "msg_ram"
> +		    "ipc"

+1 for kumar's comment.

cant enforce the order here. should fix it in the driver.

> +
> +- interrupts:
> +	Usage: required
> +	Value type: <prop-encoded-array>
> +	Definition: three entries specifying the RPM's:
> +		    1. acknowledgement interrupt
> +		    2. error interrupt
> +		    3. wakeup interrupt
> +
> +- interrupt-names:
> +	Usage: required
> +	Value type: <string-array>
> +	Definition: must be the three strings "ack", "err" and "wakeup", in order
> +
> +- #address-cells:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: must be 1
> +
> +- #size-cells:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: must be 0
> +
> +
> += SUBDEVICES
> +
> +The RPM exposes resources to its subnodes. The below bindings specify the set
> +of valid subnodes that can operate on these resources.

Why should these devices be on sub nodes?

Any reason not to implement it like this,

rpm: rpm@108000 {
	compatible = "qcom,rpm-msm8960";
	reg = <0x108000 0x1000 0x2011008 0x4>;

	interrupts = <0 19 0>, <0 21 0>, <0 22 0>;
	interrupt-names = "ack", "err", "wakeup";
};

pm8921_s1: pm8921-s1 {
	compatible = "qcom,rpm-pm8921-smps";
	
	regulator-min-microvolt = <1225000>;
	regulator-max-microvolt = <1225000>;
	regulator-always-on;

	qcom,rpm = <&rpm QCOM_RPM_PM8921_S1>;
	qcom,switch-mode-frequency = <3200000>;
	qcom,hpm-threshold = <100000>;
};

This would simplify the driver code too and handle the interface neatly 
then depending on device hierarchy.
rpm would be a interface library to the clients. Makes the drivers more 
independent, and re-usable if we do this way.

??


> +
> +== Switch-mode Power Supply regulator
> +
> +- compatible:
> +	Usage: required
> +	Value type: <string>
> +	Definition: must be one of:
> +		    "qcom,rpm-pm8058-smps"
> +		    "qcom,rpm-pm8901-ftsmps"
> +		    "qcom,rpm-pm8921-smps"
> +		    "qcom,rpm-pm8921-ftsmps"
> +
> +- reg:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: resource as defined in <dt-bindings/mfd/qcom_rpm.h>
> +
> +- qcom,switch-mode-frequency:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: Frequency (Hz) of the switch-mode power supply;
> +		    must be one of:
> +		    19200000, 9600000, 6400000, 4800000, 3840000, 3200000,
> +		    2740000, 2400000, 2130000, 1920000, 1750000, 1600000,
> +		    1480000, 1370000, 1280000, 1200000
> +
> +- qcom,hpm-threshold:
> +	Usage: optional
> +	Value type: <u32>
> +	Definition: indicates the breaking point at which the regulator should
> +	            switch to high power mode
> +
> +- qcom,load-bias:
> +	Usage: optional
> +	Value type: <u32>
> +	Definition: specifies a base load on the specific regulator
> +
> +- qcom,boot-load:
> +	Usage: optional
> +	Value type: <u32>
> +	Definition: specifies the configured load on boot for the specific
> +	            regulator
> +

[...
> +- qcom,force-mode-none:
> +	Usage: optional (default if no other qcom,force-mode is specified)
> +	Value type: <empty>
> +	Defintion: indicates that the regulator should not be forced to any
> +	           particular mode
> +
> +- qcom,force-mode-lpm:
> +	Usage: optional
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be forced to operate in
> +	            low-power-mode
> +
> +- qcom,force-mode-auto:
> +	Usage: optional (only available for 8960/8064)
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be automatically pick
> +	            operating mode
> +
> +- qcom,force-mode-hpm:
> +	Usage: optional (only available for 8960/8064)
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be forced to operate in
> +	            high-power-mode
> +
> +- qcom,force-mode-bypass: (only for 8960/8064)
> +	Usage: optional (only available for 8960/8064)
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be forced to operate in
> +	            bypass mode
> +
...]

Probably qcom,force-mode:
	Usage: optional.
	Value type: <string>
	Definition: must be one of:
	"none"
	"lpm"
	"auto"
	"hpm"
	"bypass"

Makes it much simpler, as they seems to be mutually exclusive. simillar 
comments apply to other bindings too.


[...
> +- qcom,power-mode-hysteretic:
> +	Usage: optional
> +	Value type: <empty>
> +	Definition: indicates that the power supply should operate in hysteretic
> +		    mode (defaults to qcom,power-mode-pwm if not specified)
> +
> +- qcom,power-mode-pwm:
> +	Usage: optional
> +	Value type: <empty>
> +	Definition: indicates that the power supply should operate in pwm mode
> +
...]

Probably qcom,power-mode:
	Usage: optional.
	Value type: <string>
	Definition: must be one of:
	"pwm"
	"hysteretic"


Makes it much simpler, as they seems to be mutually exclusive. simillar 
comments apply to other bindings too.




Thanks,
srini
> +Standard regulator bindings are used inside switch mode power supply subnodes.
> +Check Documentation/devicetree/bindings/regulator/regulator.txt for more
> +details.
> +
> +== Low-dropout regulator
> +
> +- compatible:
> +	Usage: required
> +	Value type: <string>
> +	Definition: must be one of:
> +		    "qcom,rpm-pm8058-pldo"
> +		    "qcom,rpm-pm8058-nldo"
> +		    "qcom,rpm-pm8901-pldo"
> +		    "qcom,rpm-pm8901-nldo"
> +		    "qcom,rpm-pm8921-pldo"
> +		    "qcom,rpm-pm8921-nldo"
> +		    "qcom,rpm-pm8921-nldo1200"
> +
> +- reg:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: resource as defined in <dt-bindings/mfd/qcom_rpm.h>
> +
> +- qcom,hpm-threshold:
> +	Usage: optional
> +	Value type: <u32>
> +	Definition: indicates the breaking point at which the regulator should
> +	            switch to high power mode
> +
> +- qcom,load-bias:
> +	Usage: optional
> +	Value type: <u32>
> +	Definition: specifies a base load on the specific regulator
> +
> +- qcom,boot-load:
> +	Usage: optional
> +	Value type: <u32>
> +	Definition: specifies the configured load on boot for the specific
> +	            regulator
> +
> +- qcom,force-mode-none:
> +	Usage: optional (default if no other qcom,force-mode is specified)
> +	Value type: <empty>
> +	Defintion: indicates that the regulator should not be forced to any
> +	           particular mode
> +
> +- qcom,force-mode-lpm:
> +	Usage: optional
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be forced to operate in
> +	            low-power-mode
> +
> +- qcom,force-mode-auto:
> +	Usage: optional (only available for 8960/8064)
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be automatically pick
> +	            operating mode
> +
> +- qcom,force-mode-hpm:
> +	Usage: optional (only available for 8960/8064)
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be forced to operate in
> +	            high-power-mode
> +
> +- qcom,force-mode-bypass: (only for 8960/8064)
> +	Usage: optional (only available for 8960/8064)
> +	Value type: <empty>
> +	Definition: indicates that the regulator should be forced to operate in
> +	            bypass mode
> +
> +Standard regulator bindings are used inside switch low-dropout regulator
> +subnodes.  Check Documentation/devicetree/bindings/regulator/regulator.txt for
> +more details.
> +
> +== Negative Charge Pump
> +
> +- compatible:
> +	Usage: required
> +	Value type: <string>
> +	Definition: must be one of:
> +		    "qcom,rpm-pm8058-ncp"
> +		    "qcom,rpm-pm8921-ncp"
> +		    "qcom,rpm-pm8921-nldo1200"
> +
> +- reg:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: resource as defined in <dt-bindings/mfd/qcom_rpm.h>
> +
> +- qcom,switch-mode-frequency:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: Frequency (Hz) of the swith mode power supply;
> +		    must be one of:
> +		    19200000, 9600000, 6400000, 4800000, 3840000, 3200000,
> +		    2740000, 2400000, 2130000, 1920000, 1750000, 1600000,
> +		    1480000, 1370000, 1280000, 1200000
> +
> +Standard regulator bindings are used inside negative charge pump regulator
> +subnodes.  Check Documentation/devicetree/bindings/regulator/regulator.txt for
> +more details.
> +
> +== Switch
> +
> +- compatible:
> +	Usage: required
> +	Value type: <string>
> +	Definition: must be one of:
> +		    "qcom,rpm-pm8058-switch"
> +		    "qcom,rpm-pm8901-switch"
> +		    "qcom,rpm-pm8921-switch"
> +
> +- reg:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: resource as defined in <dt-bindings/mfd/qcom_rpm.h>
> +
> +
> += EXAMPLE
> +
> +	#include <dt-bindings/mfd/qcom_rpm.h>
> +
> +	rpm@108000 {
> +		compatible = "qcom,rpm-msm8960";
> +		reg = <0x108000 0x1000 0x2011008 0x4>;
> +
> +		interrupts = <0 19 0>, <0 21 0>, <0 22 0>;
> +		interrupt-names = "ack", "err", "wakeup";
> +
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		pm8921_s1: pm8921-s1 {
> +			compatible = "qcom,rpm-pm8921-smps";
> +			reg = <QCOM_RPM_PM8921_S1>;
> +
> +			regulator-min-microvolt = <1225000>;
> +			regulator-max-microvolt = <1225000>;
> +			regulator-always-on;
> +
> +			qcom,switch-mode-frequency = <3200000>;
> +			qcom,hpm-threshold = <100000>;
> +		};
> +	};

...
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Kumar Gala May 29, 2014, 4:30 p.m. UTC | #3

On May 29, 2014, at 11:19 AM, Srinivas Kandagatla <[e-mail]> wrote:

>> += SUBDEVICES
>> +
>> +The RPM exposes resources to its subnodes. The below bindings specify the set
>> +of valid subnodes that can operate on these resources.
> 
> Why should these devices be on sub nodes?
> 
> Any reason not to implement it like this,
> 
> rpm: rpm@108000 {
> 	compatible = "qcom,rpm-msm8960";
> 	reg = <0x108000 0x1000 0x2011008 0x4>;
> 
> 	interrupts = <0 19 0>, <0 21 0>, <0 22 0>;
> 	interrupt-names = "ack", "err", "wakeup";
> };
> 
> pm8921_s1: pm8921-s1 {
> 	compatible = "qcom,rpm-pm8921-smps";
> 	
> 	regulator-min-microvolt = <1225000>;
> 	regulator-max-microvolt = <1225000>;
> 	regulator-always-on;
> 
> 	qcom,rpm = <&rpm QCOM_RPM_PM8921_S1>;
> 	qcom,switch-mode-frequency = <3200000>;
> 	qcom,hpm-threshold = <100000>;
> };
> 
> This would simplify the driver code too and handle the interface neatly then depending on device hierarchy.
> rpm would be a interface library to the clients. Makes the drivers more independent, and re-usable if we do this way.
> 
> ??

One reason to go with sub nodes is it creates a proper driver ordering dependency as I assume rpm driver will end up calling of_platform_populate for the sub nodes at the point that the RPM driver is ready.  We could do this with deferred probe but doing it explicitly is better in my opinion as it limits the amount of time between when RPM is ready vs when the children can start doing things

- k

Lee Jones May 29, 2014, 4:54 p.m. UTC | #4

> Add binding for the Qualcomm Resource Power Manager (RPM) found in 8660, 8960
> and 8064 based devices. The binding currently describes the rpm itself and the
> regulator subnodes.
> 
> Signed-off-by: Bjorn Andersson <[e-mail]>
> ---
>  Documentation/devicetree/bindings/mfd/qcom,rpm.txt | 284 +++++++++++++++++++++
>  include/dt-bindings/mfd/qcom_rpm.h                 | 142 +++++++++++
>  2 files changed, 426 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/qcom,rpm.txt
>  create mode 100644 include/dt-bindings/mfd/qcom_rpm.h

[...]

> diff --git a/include/dt-bindings/mfd/qcom_rpm.h b/include/dt-bindings/mfd/qcom_rpm.h
> new file mode 100644
> index 0000000..277e789
> --- /dev/null
> +++ b/include/dt-bindings/mfd/qcom_rpm.h
> @@ -0,0 +1,142 @@
> +/*
> + * This header provides constants for the Qualcomm RPM bindings.
> + */

Proper header please.

> +#ifndef _DT_BINDINGS_MFD_QCOM_RPM_H
> +#define _DT_BINDINGS_MFD_QCOM_RPM_H
> +
> +#define QCOM_RPM_APPS_FABRIC_ARB		1
> +#define QCOM_RPM_APPS_FABRIC_CLK		2
> +#define QCOM_RPM_APPS_FABRIC_HALT		3

[...]

> +#define QCOM_RPM_SYS_FABRIC_MODE		131
> +#define QCOM_RPM_USB_OTG_SWITCH		132
> +#define QCOM_RPM_VDDMIN_GPIO			133

Are you sure you don't want these in 0xXY format?

Srinivas Kandagatla May 29, 2014, 5:09 p.m. UTC | #5

On 29/05/14 17:30, Kumar Gala wrote:
>
> On May 29, 2014, at 11:19 AM, Srinivas Kandagatla <[e-mail]> wrote:
>
>>> += SUBDEVICES
>>> +
>>> +The RPM exposes resources to its subnodes. The below bindings specify the set
>>> +of valid subnodes that can operate on these resources.
>>
>> Why should these devices be on sub nodes?
>>
>> Any reason not to implement it like this,
>>
>> rpm: rpm@108000 {
>> 	compatible = "qcom,rpm-msm8960";
>> 	reg = <0x108000 0x1000 0x2011008 0x4>;
>>
>> 	interrupts = <0 19 0>, <0 21 0>, <0 22 0>;
>> 	interrupt-names = "ack", "err", "wakeup";
>> };
>>
>> pm8921_s1: pm8921-s1 {
>> 	compatible = "qcom,rpm-pm8921-smps";
>> 	
>> 	regulator-min-microvolt = <1225000>;
>> 	regulator-max-microvolt = <1225000>;
>> 	regulator-always-on;
>>
>> 	qcom,rpm = <&rpm QCOM_RPM_PM8921_S1>;
>> 	qcom,switch-mode-frequency = <3200000>;
>> 	qcom,hpm-threshold = <100000>;
>> };
>>
>> This would simplify the driver code too and handle the interface neatly then depending on device hierarchy.
>> rpm would be a interface library to the clients. Makes the drivers more independent, and re-usable if we do this way.
>>
>> ??
>
> One reason to go with sub nodes is it creates a proper driver ordering dependency as I assume rpm driver will end up calling of_platform_populate for the sub nodes at the point that the RPM driver is ready.  We could do this with deferred probe but doing it explicitly is better in my opinion as it limits the amount of time between when RPM is ready vs when the children can start doing things
>

I agree, there might be a win. But Am not sure to what extent this win 
is a win to rpm driver, as a side effect this brings other 
responsibilities to the rpm driver like adding sub-device power 
management awareness, device life cycle management to the rpm driver.

Only thing which made me think of this approach is the number of sub 
nodes it would end up with and passing ID using reg property.

Thanks,
srini

> - k
>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bjorn Andersson May 29, 2014, 6:24 p.m. UTC | #6

On Wed, May 28, 2014 at 9:34 AM, Kumar Gala <[e-mail]> wrote:
>
> On May 27, 2014, at 12:28 PM, Bjorn Andersson <[e-mail]> wrote:
>
>> Add binding for the Qualcomm Resource Power Manager (RPM) found in 8660, 8960
>> and 8064 based devices. The binding currently describes the rpm itself and the
>> regulator subnodes.
>>
>> Signed-off-by: Bjorn Andersson <[e-mail]>
>> ---
>> Documentation/devicetree/bindings/mfd/qcom,rpm.txt | 284 +++++++++++++++++++++
>> include/dt-bindings/mfd/qcom_rpm.h                 | 142 +++++++++++
>> 2 files changed, 426 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/qcom,rpm.txt
>> create mode 100644 include/dt-bindings/mfd/qcom_rpm.h
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/qcom,rpm.txt b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt
>> new file mode 100644
>> index 0000000..3908a5d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt
>> @@ -0,0 +1,284 @@
>> +Qualcomm Resource Power Manager (RPM)
>> +
>> +This driver is used to interface with the Resource Power Manager (RPM) found in
>> +various Qualcomm platforms. The RPM allows each component in the system to vote
>> +for state of the system resources, such as clocks, regulators and bus
>> +frequencies.
>> +
>> +- compatible:
>> +     Usage: required
>> +     Value type: <string>
>> +     Definition: must be one of:
>> +                 "qcom,rpm-apq8064"
>> +                 "qcom,rpm-msm8660"
>> +                 "qcom,rpm-msm8960"
>> +
>> +- reg:
>> +     Usage: required
>> +     Value type: <prop-encoded-array>
>> +     Definition: two entries specifying the RPM's message ram and ipc register
>> +
>> +- reg-names:
>> +     Usage: required
>> +     Value type: <string-array>
>> +     Definition: must contain the following, in order:
>> +                 "msg_ram"
>> +                 “ipc"
>
> If order maters, it should be on reg not reg-names.  If order doesn’t mater than this should say the names should match the reg

The DT guys have been clear on that the order of the reg property must
be fixed, no matter if you have reg-names or not. But I will make sure
to clarify this by being specific in the definition of "reg" as well.

>
>> +
>> +- interrupts:
>> +     Usage: required
>> +     Value type: <prop-encoded-array>
>> +     Definition: three entries specifying the RPM's:
>> +                 1. acknowledgement interrupt
>> +                 2. error interrupt
>> +                 3. wakeup interrupt
>> +
>> +- interrupt-names:
>> +     Usage: required
>> +     Value type: <string-array>
>> +     Definition: must be the three strings "ack", "err" and "wakeup", in order
>
> again, if order maters it should be with the interrupts prop, not the name.

I'll add something to the definition of "interrupts" to clarify this fact.

>
>> +
>> +- #address-cells:
>> +     Usage: required
>> +     Value type: <u32>
>> +     Definition: must be 1
>> +
>> +- #size-cells:
>> +     Usage: required
>> +     Value type: <u32>
>> +     Definition: must be 0
>> +
>> +
>> += SUBDEVICES
>> +
>> +The RPM exposes resources to its subnodes. The below bindings specify the set
>> +of valid subnodes that can operate on these resources.
>> +
>> +== Switch-mode Power Supply regulator
>> +
>> +- compatible:
>> +     Usage: required
>> +     Value type: <string>
>> +     Definition: must be one of:
>> +                 "qcom,rpm-pm8058-smps"
>> +                 "qcom,rpm-pm8901-ftsmps"
>> +                 "qcom,rpm-pm8921-smps"
>> +                 "qcom,rpm-pm8921-ftsmps"
>> +
>> +- reg:
>> +     Usage: required
>> +     Value type: <u32>
>> +     Definition: resource as defined in <dt-bindings/mfd/qcom_rpm.h>
>
> Can we provide a bit more description about what “namespace” this reg is work in.

Based on that I split this up in the different regulator types I
should be able to glob the possible resources here now; I'll give it a
try.

>
>> +
>> +- qcom,switch-mode-frequency:
>> +     Usage: required
>> +     Value type: <u32>
>> +     Definition: Frequency (Hz) of the switch-mode power supply;
>> +                 must be one of:
>> +                 19200000, 9600000, 6400000, 4800000, 3840000, 3200000,
>> +                 2740000, 2400000, 2130000, 1920000, 1750000, 1600000,
>> +                 1480000, 1370000, 1280000, 1200000
>> +
>> +- qcom,hpm-threshold:
>> +     Usage: optional
>> +     Value type: <u32>
>> +     Definition: indicates the breaking point at which the regulator should
>> +                 switch to high power mode
>
> in what units?

Thanks

>
>> +
>> +- qcom,load-bias:
>> +     Usage: optional
>> +     Value type: <u32>
>> +     Definition: specifies a base load on the specific regulator
>
> in what units?

Thanks

>
>> +
>> +- qcom,boot-load:
>> +     Usage: optional
>> +     Value type: <u32>
>> +     Definition: specifies the configured load on boot for the specific
>> +                 regulator
>
> in what units?

Thanks

>
>> +
>> +- qcom,force-mode-none:
>> +     Usage: optional (default if no other qcom,force-mode is specified)
>> +     Value type: <empty>
>> +     Defintion: indicates that the regulator should not be forced to any
>> +                particular mode
>> +
>> +- qcom,force-mode-lpm:
>> +     Usage: optional
>> +     Value type: <empty>
>> +     Definition: indicates that the regulator should be forced to operate in
>> +                 low-power-mode
>> +
>> +- qcom,force-mode-auto:
>> +     Usage: optional (only available for 8960/8064)
>> +     Value type: <empty>
>> +     Definition: indicates that the regulator should be automatically pick
>> +                 operating mode
>> +
>> +- qcom,force-mode-hpm:
>> +     Usage: optional (only available for 8960/8064)
>> +     Value type: <empty>
>> +     Definition: indicates that the regulator should be forced to operate in
>> +                 high-power-mode
>> +
>> +- qcom,force-mode-bypass: (only for 8960/8064)
>> +     Usage: optional (only available for 8960/8064)
>> +     Value type: <empty>
>> +     Definition: indicates that the regulator should be forced to operate in
>> +                 bypass mode
>> +
>
> Is force-mode really an enum?  Or can we really have multiple force-mode’s set?
>

Force mode is an enum, you can only set one of these.

Looking around you can find three ways of doing this:
1) Make it an int and provide defines in a dt-bindings header file
2) Make it a string and list the possible values
3) Make it a set of boolean properties

I just spent some time in the pinctrl struff that implements 3), I
like the feel of it and I like how the dts ended up looking like.

But if there's a strong opinion regarding this I could change it.

>> +- qcom,power-mode-hysteretic:
>> +     Usage: optional
>> +     Value type: <empty>
>> +     Definition: indicates that the power supply should operate in hysteretic
>> +                 mode (defaults to qcom,power-mode-pwm if not specified)
>> +
>> +- qcom,power-mode-pwm:
>> +     Usage: optional
>> +     Value type: <empty>
>> +     Definition: indicates that the power supply should operate in pwm mode
>> +
>
> Same question here is power-mode either pwm or hysteretic or can we set both?
>

Same as for force-mode

>> +Standard regulator bindings are used inside switch mode power supply subnodes.
>> +Check Documentation/devicetree/bindings/regulator/regulator.txt for more
>> +details.
>> +

[...]

>> diff --git a/include/dt-bindings/mfd/qcom_rpm.h b/include/dt-bindings/mfd/qcom_rpm.h
>> new file mode 100644
>> index 0000000..277e789
>> --- /dev/null
>> +++ b/include/dt-bindings/mfd/qcom_rpm.h
[...]
>> +#define QCOM_RPM_SYS_FABRIC_CLK                      128
>> +#define QCOM_RPM_SYS_FABRIC_HALT             129
>> +#define QCOM_RPM_SYS_FABRIC_IOCTL            130
>> +#define QCOM_RPM_SYS_FABRIC_MODE             131
>> +#define QCOM_RPM_USB_OTG_SWITCH                      132
>> +#define QCOM_RPM_VDDMIN_GPIO                 133
>
> Are these values arbitrary or do they mean something to hw?

They are just arbitrary values, similar to what you find in e.g. the
clock definitions.

Thanks for the review.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bjorn Andersson May 29, 2014, 6:38 p.m. UTC | #7

On Thu, May 29, 2014 at 9:19 AM, Srinivas Kandagatla
<[e-mail]> wrote:
>> +- reg:
>> +       Usage: required
>> +       Value type: <prop-encoded-array>
>> +       Definition: two entries specifying the RPM's message ram and ipc
>> register
>> +
>> +- reg-names:
>> +       Usage: required
>> +       Value type: <string-array>
>> +       Definition: must contain the following, in order:
>> +                   "msg_ram"
>> +                   "ipc"
>
>
> +1 for kumar's comment.
>
> cant enforce the order here. should fix it in the driver.
>

Yes I can, this is as decided by the devicetree maintainers. The order
of e.g. reg and interrupts must be defined.

>> += SUBDEVICES
>> +
>> +The RPM exposes resources to its subnodes. The below bindings specify the
>> set
>> +of valid subnodes that can operate on these resources.
>
>
> Why should these devices be on sub nodes?
>
> Any reason not to implement it like this,
>
> rpm: rpm@108000 {
>         compatible = "qcom,rpm-msm8960";
>
>         reg = <0x108000 0x1000 0x2011008 0x4>;
>
>         interrupts = <0 19 0>, <0 21 0>, <0 22 0>;
>         interrupt-names = "ack", "err", "wakeup";
> };
>
> pm8921_s1: pm8921-s1 {
>         compatible = "qcom,rpm-pm8921-smps";
>
>         regulator-min-microvolt = <1225000>;
>         regulator-max-microvolt = <1225000>;
>         regulator-always-on;
>
>         qcom,rpm = <&rpm QCOM_RPM_PM8921_S1>;
>         qcom,switch-mode-frequency = <3200000>;
>         qcom,hpm-threshold = <100000>;
> };
>
> This would simplify the driver code too and handle the interface neatly then
> depending on device hierarchy.
> rpm would be a interface library to the clients. Makes the drivers more
> independent, and re-usable if we do this way.

The subnodes doesn't describe separate pieces of hardware but rather
pieces of the rpm, that's why they should live inside the rpm. There
will not be any re-use of these drivers outside having a rpm as
parent.

I do have some patches for family b, where I'm moving things around a
little bit in the implementation to be able to re-use child-devices
where that makes sense (clock implementation is the same for the two).
But that is implementation specific and does not affect the dt.


Implementation wise, having the individual subnodes as children in the
device model makes a lot of sense, as the children should be probed
when the rpm appears and when the rpm goes away it should bring down
all subnodes. If there was any power management it would be the same
thing.

So I think this makes for a cleaner implementation; all I need to do
is to call of_platform_populate at the end of the probe and in remove
I need to tell the children that they should go away. I do not need to
support any phandle based lookups and separate life cycle management.

>
> [...
>
>> +- qcom,force-mode-none:
>> +       Usage: optional (default if no other qcom,force-mode is specified)
>> +       Value type: <empty>
>> +       Defintion: indicates that the regulator should not be forced to
>> any
>> +                  particular mode
>> +
>> +- qcom,force-mode-lpm:
>> +       Usage: optional
>> +       Value type: <empty>
>> +       Definition: indicates that the regulator should be forced to
>> operate in
>> +                   low-power-mode
>> +
>> +- qcom,force-mode-auto:
>> +       Usage: optional (only available for 8960/8064)
>> +       Value type: <empty>
>> +       Definition: indicates that the regulator should be automatically
>> pick
>> +                   operating mode
>> +
>> +- qcom,force-mode-hpm:
>> +       Usage: optional (only available for 8960/8064)
>> +       Value type: <empty>
>> +       Definition: indicates that the regulator should be forced to
>> operate in
>> +                   high-power-mode
>> +
>> +- qcom,force-mode-bypass: (only for 8960/8064)
>> +       Usage: optional (only available for 8960/8064)
>> +       Value type: <empty>
>> +       Definition: indicates that the regulator should be forced to
>> operate in
>> +                   bypass mode
>> +
>
> ...]
>
> Probably qcom,force-mode:
>         Usage: optional.
>         Value type: <string>
>
>         Definition: must be one of:
>         "none"
>         "lpm"
>         "auto"
>         "hpm"
>         "bypass"
>
> Makes it much simpler, as they seems to be mutually exclusive. simillar
> comments apply to other bindings too.

Please see my answer to Kumar.


Thanks for the comments!

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bjorn Andersson May 29, 2014, 7:05 p.m. UTC | #8

On Thu, May 29, 2014 at 9:54 AM, Lee Jones <[e-mail]> wrote:
>> diff --git a/include/dt-bindings/mfd/qcom_rpm.h b/include/dt-bindings/mfd/qcom_rpm.h
>> new file mode 100644
>> index 0000000..277e789
>> --- /dev/null
>> +++ b/include/dt-bindings/mfd/qcom_rpm.h
>> @@ -0,0 +1,142 @@
>> +/*
>> + * This header provides constants for the Qualcomm RPM bindings.
>> + */
>
> Proper header please.

Will do.

>
>> +#ifndef _DT_BINDINGS_MFD_QCOM_RPM_H
>> +#define _DT_BINDINGS_MFD_QCOM_RPM_H
>> +
>> +#define QCOM_RPM_APPS_FABRIC_ARB             1
>> +#define QCOM_RPM_APPS_FABRIC_CLK             2
>> +#define QCOM_RPM_APPS_FABRIC_HALT            3
>
> [...]
>
>> +#define QCOM_RPM_SYS_FABRIC_MODE             131
>> +#define QCOM_RPM_USB_OTG_SWITCH              132
>> +#define QCOM_RPM_VDDMIN_GPIO                 133
>
> Are you sure you don't want these in 0xXY format?

This is just a list of virtual identifiers, so unless you object to
much I'll leave them in base 10.

Thanks,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Srinivas Kandagatla May 29, 2014, 9:25 p.m. UTC | #9

On 29/05/14 19:38, Bjorn Andersson wrote:
> On Thu, May 29, 2014 at 9:19 AM, Srinivas Kandagatla
> <[e-mail]> wrote:
>>> +- reg:
>>> +       Usage: required
>>> +       Value type: <prop-encoded-array>
>>> +       Definition: two entries specifying the RPM's message ram and ipc
>>> register
>>> +
>>> +- reg-names:
>>> +       Usage: required
>>> +       Value type: <string-array>
>>> +       Definition: must contain the following, in order:
>>> +                   "msg_ram"
>>> +                   "ipc"
>>
>>
>> +1 for kumar's comment.
>>
>> cant enforce the order here. should fix it in the driver.
>>
>
> Yes I can, this is as decided by the devicetree maintainers. The order
> of e.g. reg and interrupts must be defined.
>
Does not make sense. Unless Am missing something obvious.
Having reg-names/interrupt-names would give driver flexibility to get 
the resources by name, as long as the order of reg and reg-names match.

So the order of reg is really not really necessary. Unless the driver is 
coded to access it via index.

Hardly 1/2 bindings documents enforce this.


>>> += SUBDEVICES
>>> +
>>> +The RPM exposes resources to its subnodes. The below bindings specify the
>>> set
>>> +of valid subnodes that can operate on these resources.
>>
>>
>> Why should these devices be on sub nodes?
>>
>> Any reason not to implement it like this,
>>
>> rpm: rpm@108000 {
>>          compatible = "qcom,rpm-msm8960";
>>
>>          reg = <0x108000 0x1000 0x2011008 0x4>;
>>
>>          interrupts = <0 19 0>, <0 21 0>, <0 22 0>;
>>          interrupt-names = "ack", "err", "wakeup";
>> };
>>
>> pm8921_s1: pm8921-s1 {
>>          compatible = "qcom,rpm-pm8921-smps";
>>
>>          regulator-min-microvolt = <1225000>;
>>          regulator-max-microvolt = <1225000>;
>>          regulator-always-on;
>>
>>          qcom,rpm = <&rpm QCOM_RPM_PM8921_S1>;
>>          qcom,switch-mode-frequency = <3200000>;
>>          qcom,hpm-threshold = <100000>;
>> };
>>
>> This would simplify the driver code too and handle the interface neatly then
>> depending on device hierarchy.
>> rpm would be a interface library to the clients. Makes the drivers more
>> independent, and re-usable if we do this way.
>
> The subnodes doesn't describe separate pieces of hardware but rather
> pieces of the rpm, that's why they should live inside the rpm. There
> will not be any re-use of these drivers outside having a rpm as
> parent.
>
> I do have some patches for family b, where I'm moving things around a
> little bit in the implementation to be able to re-use child-devices
> where that makes sense (clock implementation is the same for the two).
> But that is implementation specific and does not affect the dt.
>
Good point, Am more of thinking of some other SOCs might have similar pmic.

>
> Implementation wise, having the individual subnodes as children in the
> device model makes a lot of sense, as the children should be probed
> when the rpm appears and when the rpm goes away it should bring down
> all subnodes. If there was any power management it would be the same
> thing.
Thats great, you have already thought about it.
>
> So I think this makes for a cleaner implementation; all I need to do
> is to call of_platform_populate at the end of the probe and in remove
> I need to tell the children that they should go away. I do not need to
> support any phandle based lookups and separate life cycle management.
>
Am ok with either approaches.

>>
>> [...
>>
>>> +- qcom,force-mode-none:
>>> +       Usage: optional (default if no other qcom,force-mode is specified)
>>> +       Value type: <empty>
>>> +       Defintion: indicates that the regulator should not be forced to
>>> any
>>> +                  particular mode
>>> +
>>> +- qcom,force-mode-lpm:
>>> +       Usage: optional
>>> +       Value type: <empty>
>>> +       Definition: indicates that the regulator should be forced to
>>> operate in
>>> +                   low-power-mode
>>> +
>>> +- qcom,force-mode-auto:
>>> +       Usage: optional (only available for 8960/8064)
>>> +       Value type: <empty>
>>> +       Definition: indicates that the regulator should be automatically
>>> pick
>>> +                   operating mode
>>> +
>>> +- qcom,force-mode-hpm:
>>> +       Usage: optional (only available for 8960/8064)
>>> +       Value type: <empty>
>>> +       Definition: indicates that the regulator should be forced to
>>> operate in
>>> +                   high-power-mode
>>> +
>>> +- qcom,force-mode-bypass: (only for 8960/8064)
>>> +       Usage: optional (only available for 8960/8064)
>>> +       Value type: <empty>
>>> +       Definition: indicates that the regulator should be forced to
>>> operate in
>>> +                   bypass mode
>>> +
>>
>> ...]
>>
>> Probably qcom,force-mode:
>>          Usage: optional.
>>          Value type: <string>
>>
>>          Definition: must be one of:
>>          "none"
>>          "lpm"
>>          "auto"
>>          "hpm"
>>          "bypass"
>>
>> Makes it much simpler, as they seems to be mutually exclusive. simillar
>> comments apply to other bindings too.
>
> Please see my answer to Kumar.
>
Ok. I don’t have a strong feeling on any of those 3 approaches.

Thanks,
srini
>
> Thanks for the comments!
>
> Regards,
> Bjorn
>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Frank Rowand May 29, 2014, 10:32 p.m. UTC | #10

On 5/29/2014 11:24 AM, Bjorn Andersson wrote:
> On Wed, May 28, 2014 at 9:34 AM, Kumar Gala <[e-mail]> wrote:
>>
>> On May 27, 2014, at 12:28 PM, Bjorn Andersson <[e-mail]> wrote:
>>
>>> Add binding for the Qualcomm Resource Power Manager (RPM) found in 8660, 8960
>>> and 8064 based devices. The binding currently describes the rpm itself and the
>>> regulator subnodes.
>>>
>>> Signed-off-by: Bjorn Andersson <[e-mail]>
>>> ---
>>> Documentation/devicetree/bindings/mfd/qcom,rpm.txt | 284 +++++++++++++++++++++
>>> include/dt-bindings/mfd/qcom_rpm.h                 | 142 +++++++++++
>>> 2 files changed, 426 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/mfd/qcom,rpm.txt
>>> create mode 100644 include/dt-bindings/mfd/qcom_rpm.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/qcom,rpm.txt b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt
>>> new file mode 100644
>>> index 0000000..3908a5d
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt

< snip >

>>> +
>>> +- qcom,force-mode-none:
>>> +     Usage: optional (default if no other qcom,force-mode is specified)
>>> +     Value type: <empty>
>>> +     Defintion: indicates that the regulator should not be forced to any
>>> +                particular mode
>>> +
>>> +- qcom,force-mode-lpm:
>>> +     Usage: optional
>>> +     Value type: <empty>
>>> +     Definition: indicates that the regulator should be forced to operate in
>>> +                 low-power-mode
>>> +
>>> +- qcom,force-mode-auto:
>>> +     Usage: optional (only available for 8960/8064)
>>> +     Value type: <empty>
>>> +     Definition: indicates that the regulator should be automatically pick
>>> +                 operating mode
>>> +
>>> +- qcom,force-mode-hpm:
>>> +     Usage: optional (only available for 8960/8064)
>>> +     Value type: <empty>
>>> +     Definition: indicates that the regulator should be forced to operate in
>>> +                 high-power-mode
>>> +
>>> +- qcom,force-mode-bypass: (only for 8960/8064)
>>> +     Usage: optional (only available for 8960/8064)
>>> +     Value type: <empty>
>>> +     Definition: indicates that the regulator should be forced to operate in
>>> +                 bypass mode
>>> +
>>
>> Is force-mode really an enum?  Or can we really have multiple force-mode’s set?
>>
> 
> Force mode is an enum, you can only set one of these.
> 
> Looking around you can find three ways of doing this:
> 1) Make it an int and provide defines in a dt-bindings header file
> 2) Make it a string and list the possible values
> 3) Make it a set of boolean properties
> 
> I just spent some time in the pinctrl struff that implements 3), I
> like the feel of it and I like how the dts ended up looking like.
> 
> But if there's a strong opinion regarding this I could change it.

The problem with separate properties is that there is not a way to
detect the error of specifying multiple conflicting force-modes
at compile time.

It also means you can not override the default force-mode from one
.dts/.dtsi in another .dts/.dtsi.

< snip >

-Frank

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/Documentation/devicetree/bindings/mfd/qcom,rpm.txt b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt
new file mode 100644
index 0000000..3908a5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt
@@ -0,0 +1,284 @@ 
+Qualcomm Resource Power Manager (RPM)
+
+This driver is used to interface with the Resource Power Manager (RPM) found in
+various Qualcomm platforms. The RPM allows each component in the system to vote
+for state of the system resources, such as clocks, regulators and bus
+frequencies.
+
+- compatible:
+	Usage: required
+	Value type: <string>
+	Definition: must be one of:
+		    "qcom,rpm-apq8064"
+		    "qcom,rpm-msm8660"
+		    "qcom,rpm-msm8960"
+
+- reg:
+	Usage: required
+	Value type: <prop-encoded-array>
+	Definition: two entries specifying the RPM's message ram and ipc register
+
+- reg-names:
+	Usage: required
+	Value type: <string-array>
+	Definition: must contain the following, in order:
+		    "msg_ram"
+		    "ipc"
+
+- interrupts:
+	Usage: required
+	Value type: <prop-encoded-array>
+	Definition: three entries specifying the RPM's:
+		    1. acknowledgement interrupt
+		    2. error interrupt
+		    3. wakeup interrupt
+
+- interrupt-names:
+	Usage: required
+	Value type: <string-array>
+	Definition: must be the three strings "ack", "err" and "wakeup", in order
+
+- #address-cells:
+	Usage: required
+	Value type: <u32>
+	Definition: must be 1
+
+- #size-cells:
+	Usage: required
+	Value type: <u32>
+	Definition: must be 0
+
+
+= SUBDEVICES
+
+The RPM exposes resources to its subnodes. The below bindings specify the set
+of valid subnodes that can operate on these resources.
+
+== Switch-mode Power Supply regulator
+
+- compatible:
+	Usage: required
+	Value type: <string>
+	Definition: must be one of:
+		    "qcom,rpm-pm8058-smps"
+		    "qcom,rpm-pm8901-ftsmps"
+		    "qcom,rpm-pm8921-smps"
+		    "qcom,rpm-pm8921-ftsmps"
+
+- reg:
+	Usage: required
+	Value type: <u32>
+	Definition: resource as defined in <dt-bindings/mfd/qcom_rpm.h>
+
+- qcom,switch-mode-frequency:
+	Usage: required
+	Value type: <u32>
+	Definition: Frequency (Hz) of the switch-mode power supply;
+		    must be one of:
+		    19200000, 9600000, 6400000, 4800000, 3840000, 3200000,
+		    2740000, 2400000, 2130000, 1920000, 1750000, 1600000,
+		    1480000, 1370000, 1280000, 1200000
+
+- qcom,hpm-threshold:
+	Usage: optional
+	Value type: <u32>
+	Definition: indicates the breaking point at which the regulator should
+	            switch to high power mode
+
+- qcom,load-bias:
+	Usage: optional
+	Value type: <u32>
+	Definition: specifies a base load on the specific regulator
+
+- qcom,boot-load:
+	Usage: optional
+	Value type: <u32>
+	Definition: specifies the configured load on boot for the specific
+	            regulator
+
+- qcom,force-mode-none:
+	Usage: optional (default if no other qcom,force-mode is specified)
+	Value type: <empty>
+	Defintion: indicates that the regulator should not be forced to any
+	           particular mode
+
+- qcom,force-mode-lpm:
+	Usage: optional
+	Value type: <empty>
+	Definition: indicates that the regulator should be forced to operate in
+	            low-power-mode
+
+- qcom,force-mode-auto:
+	Usage: optional (only available for 8960/8064)
+	Value type: <empty>
+	Definition: indicates that the regulator should be automatically pick
+	            operating mode
+
+- qcom,force-mode-hpm:
+	Usage: optional (only available for 8960/8064)
+	Value type: <empty>
+	Definition: indicates that the regulator should be forced to operate in
+	            high-power-mode
+
+- qcom,force-mode-bypass: (only for 8960/8064)
+	Usage: optional (only available for 8960/8064)
+	Value type: <empty>
+	Definition: indicates that the regulator should be forced to operate in
+	            bypass mode
+
+- qcom,power-mode-hysteretic:
+	Usage: optional
+	Value type: <empty>
+	Definition: indicates that the power supply should operate in hysteretic
+		    mode (defaults to qcom,power-mode-pwm if not specified)
+
+- qcom,power-mode-pwm:
+	Usage: optional
+	Value type: <empty>
+	Definition: indicates that the power supply should operate in pwm mode
+
+Standard regulator bindings are used inside switch mode power supply subnodes.
+Check Documentation/devicetree/bindings/regulator/regulator.txt for more
+details.
+
+== Low-dropout regulator
+
+- compatible:
+	Usage: required
+	Value type: <string>
+	Definition: must be one of:
+		    "qcom,rpm-pm8058-pldo"
+		    "qcom,rpm-pm8058-nldo"
+		    "qcom,rpm-pm8901-pldo"
+		    "qcom,rpm-pm8901-nldo"
+		    "qcom,rpm-pm8921-pldo"
+		    "qcom,rpm-pm8921-nldo"
+		    "qcom,rpm-pm8921-nldo1200"
+
+- reg:
+	Usage: required
+	Value type: <u32>
+	Definition: resource as defined in <dt-bindings/mfd/qcom_rpm.h>
+
+- qcom,hpm-threshold:
+	Usage: optional
+	Value type: <u32>
+	Definition: indicates the breaking point at which the regulator should
+	            switch to high power mode
+
+- qcom,load-bias:
+	Usage: optional
+	Value type: <u32>
+	Definition: specifies a base load on the specific regulator
+
+- qcom,boot-load:
+	Usage: optional
+	Value type: <u32>
+	Definition: specifies the configured load on boot for the specific
+	            regulator
+
+- qcom,force-mode-none:
+	Usage: optional (default if no other qcom,force-mode is specified)
+	Value type: <empty>
+	Defintion: indicates that the regulator should not be forced to any
+	           particular mode
+
+- qcom,force-mode-lpm:
+	Usage: optional
+	Value type: <empty>
+	Definition: indicates that the regulator should be forced to operate in
+	            low-power-mode
+
+- qcom,force-mode-auto:
+	Usage: optional (only available for 8960/8064)
+	Value type: <empty>
+	Definition: indicates that the regulator should be automatically pick
+	            operating mode
+
+- qcom,force-mode-hpm:
+	Usage: optional (only available for 8960/8064)
+	Value type: <empty>
+	Definition: indicates that the regulator should be forced to operate in
+	            high-power-mode
+
+- qcom,force-mode-bypass: (only for 8960/8064)
+	Usage: optional (only available for 8960/8064)
+	Value type: <empty>
+	Definition: indicates that the regulator should be forced to operate in
+	            bypass mode
+
+Standard regulator bindings are used inside switch low-dropout regulator
+subnodes.  Check Documentation/devicetree/bindings/regulator/regulator.txt for
+more details.
+
+== Negative Charge Pump
+
+- compatible:
+	Usage: required
+	Value type: <string>
+	Definition: must be one of:
+		    "qcom,rpm-pm8058-ncp"
+		    "qcom,rpm-pm8921-ncp"
+		    "qcom,rpm-pm8921-nldo1200"
+
+- reg:
+	Usage: required
+	Value type: <u32>
+	Definition: resource as defined in <dt-bindings/mfd/qcom_rpm.h>
+
+- qcom,switch-mode-frequency:
+	Usage: required
+	Value type: <u32>
+	Definition: Frequency (Hz) of the swith mode power supply;
+		    must be one of:
+		    19200000, 9600000, 6400000, 4800000, 3840000, 3200000,
+		    2740000, 2400000, 2130000, 1920000, 1750000, 1600000,
+		    1480000, 1370000, 1280000, 1200000
+
+Standard regulator bindings are used inside negative charge pump regulator
+subnodes.  Check Documentation/devicetree/bindings/regulator/regulator.txt for
+more details.
+
+== Switch
+
+- compatible:
+	Usage: required
+	Value type: <string>
+	Definition: must be one of:
+		    "qcom,rpm-pm8058-switch"
+		    "qcom,rpm-pm8901-switch"
+		    "qcom,rpm-pm8921-switch"
+
+- reg:
+	Usage: required
+	Value type: <u32>
+	Definition: resource as defined in <dt-bindings/mfd/qcom_rpm.h>
+
+
+= EXAMPLE
+
+	#include <dt-bindings/mfd/qcom_rpm.h>
+
+	rpm@108000 {
+		compatible = "qcom,rpm-msm8960";
+		reg = <0x108000 0x1000 0x2011008 0x4>;
+
+		interrupts = <0 19 0>, <0 21 0>, <0 22 0>;
+		interrupt-names = "ack", "err", "wakeup";
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		pm8921_s1: pm8921-s1 {
+			compatible = "qcom,rpm-pm8921-smps";
+			reg = <QCOM_RPM_PM8921_S1>;
+
+			regulator-min-microvolt = <1225000>;
+			regulator-max-microvolt = <1225000>;
+			regulator-always-on;
+
+			qcom,switch-mode-frequency = <3200000>;
+			qcom,hpm-threshold = <100000>;
+		};
+	};
+
diff --git a/include/dt-bindings/mfd/qcom_rpm.h b/include/dt-bindings/mfd/qcom_rpm.h
new file mode 100644
index 0000000..277e789
--- /dev/null
+++ b/include/dt-bindings/mfd/qcom_rpm.h
@@ -0,0 +1,142 @@ 
+/*
+ * This header provides constants for the Qualcomm RPM bindings.
+ */
+
+#ifndef _DT_BINDINGS_MFD_QCOM_RPM_H
+#define _DT_BINDINGS_MFD_QCOM_RPM_H
+
+#define QCOM_RPM_APPS_FABRIC_ARB		1
+#define QCOM_RPM_APPS_FABRIC_CLK		2
+#define QCOM_RPM_APPS_FABRIC_HALT		3
+#define QCOM_RPM_APPS_FABRIC_IOCTL		4
+#define QCOM_RPM_APPS_FABRIC_MODE		5
+#define QCOM_RPM_APPS_L2_CACHE_CTL		6
+#define QCOM_RPM_CFPB_CLK			7
+#define QCOM_RPM_CXO_BUFFERS			8
+#define QCOM_RPM_CXO_CLK			9
+#define QCOM_RPM_DAYTONA_FABRIC_CLK		10
+#define QCOM_RPM_DDR_DMM			11
+#define QCOM_RPM_EBI1_CLK			12
+#define QCOM_RPM_HDMI_SWITCH			13
+#define QCOM_RPM_MMFPB_CLK			14
+#define QCOM_RPM_MM_FABRIC_ARB			15
+#define QCOM_RPM_MM_FABRIC_CLK			16
+#define QCOM_RPM_MM_FABRIC_HALT			17
+#define QCOM_RPM_MM_FABRIC_IOCTL		18
+#define QCOM_RPM_MM_FABRIC_MODE			19
+#define QCOM_RPM_PLL_4				20
+#define QCOM_RPM_PM8058_LDO0			21
+#define QCOM_RPM_PM8058_LDO1			22
+#define QCOM_RPM_PM8058_LDO2			23
+#define QCOM_RPM_PM8058_LDO3			24
+#define QCOM_RPM_PM8058_LDO4			25
+#define QCOM_RPM_PM8058_LDO5			26
+#define QCOM_RPM_PM8058_LDO6			27
+#define QCOM_RPM_PM8058_LDO7			28
+#define QCOM_RPM_PM8058_LDO8			29
+#define QCOM_RPM_PM8058_LDO9			30
+#define QCOM_RPM_PM8058_LDO10			31
+#define QCOM_RPM_PM8058_LDO11			32
+#define QCOM_RPM_PM8058_LDO12			33
+#define QCOM_RPM_PM8058_LDO13			34
+#define QCOM_RPM_PM8058_LDO14			35
+#define QCOM_RPM_PM8058_LDO15			36
+#define QCOM_RPM_PM8058_LDO16			37
+#define QCOM_RPM_PM8058_LDO17			38
+#define QCOM_RPM_PM8058_LDO18			39
+#define QCOM_RPM_PM8058_LDO19			40
+#define QCOM_RPM_PM8058_LDO20			41
+#define QCOM_RPM_PM8058_LDO21			42
+#define QCOM_RPM_PM8058_LDO22			43
+#define QCOM_RPM_PM8058_LDO23			44
+#define QCOM_RPM_PM8058_LDO24			45
+#define QCOM_RPM_PM8058_LDO25			46
+#define QCOM_RPM_PM8058_LVS0			47
+#define QCOM_RPM_PM8058_LVS1			48
+#define QCOM_RPM_PM8058_NCP			49
+#define QCOM_RPM_PM8058_SMPS0			50
+#define QCOM_RPM_PM8058_SMPS1			51
+#define QCOM_RPM_PM8058_SMPS2			52
+#define QCOM_RPM_PM8058_SMPS3			53
+#define QCOM_RPM_PM8058_SMPS4			54
+#define QCOM_RPM_PM8821_L1			55
+#define QCOM_RPM_PM8821_S1			56
+#define QCOM_RPM_PM8821_S2			57
+#define QCOM_RPM_PM8901_LDO0			58
+#define QCOM_RPM_PM8901_LDO1			59
+#define QCOM_RPM_PM8901_LDO2			60
+#define QCOM_RPM_PM8901_LDO3			61
+#define QCOM_RPM_PM8901_LDO4			62
+#define QCOM_RPM_PM8901_LDO5			63
+#define QCOM_RPM_PM8901_LDO6			64
+#define QCOM_RPM_PM8901_LVS0			65
+#define QCOM_RPM_PM8901_LVS1			66
+#define QCOM_RPM_PM8901_LVS2			67
+#define QCOM_RPM_PM8901_LVS3			68
+#define QCOM_RPM_PM8901_MVS			69
+#define QCOM_RPM_PM8901_SMPS0			70
+#define QCOM_RPM_PM8901_SMPS1			71
+#define QCOM_RPM_PM8901_SMPS2			72
+#define QCOM_RPM_PM8901_SMPS3			73
+#define QCOM_RPM_PM8901_SMPS4			74
+#define QCOM_RPM_PM8921_CLK1			75
+#define QCOM_RPM_PM8921_CLK2			76
+#define QCOM_RPM_PM8921_L1			77
+#define QCOM_RPM_PM8921_L2			78
+#define QCOM_RPM_PM8921_L3			79
+#define QCOM_RPM_PM8921_L4			80
+#define QCOM_RPM_PM8921_L5			81
+#define QCOM_RPM_PM8921_L6			82
+#define QCOM_RPM_PM8921_L7			83
+#define QCOM_RPM_PM8921_L8			84
+#define QCOM_RPM_PM8921_L9			85
+#define QCOM_RPM_PM8921_L10			86
+#define QCOM_RPM_PM8921_L11			87
+#define QCOM_RPM_PM8921_L12			88
+#define QCOM_RPM_PM8921_L13			89
+#define QCOM_RPM_PM8921_L14			90
+#define QCOM_RPM_PM8921_L15			91
+#define QCOM_RPM_PM8921_L16			92
+#define QCOM_RPM_PM8921_L17			93
+#define QCOM_RPM_PM8921_L18			94
+#define QCOM_RPM_PM8921_L19			95
+#define QCOM_RPM_PM8921_L20			96
+#define QCOM_RPM_PM8921_L21			97
+#define QCOM_RPM_PM8921_L22			98
+#define QCOM_RPM_PM8921_L23			99
+#define QCOM_RPM_PM8921_L24			100
+#define QCOM_RPM_PM8921_L25			101
+#define QCOM_RPM_PM8921_L26			102
+#define QCOM_RPM_PM8921_L27			103
+#define QCOM_RPM_PM8921_L28			104
+#define QCOM_RPM_PM8921_L29			105
+#define QCOM_RPM_PM8921_LVS1			106
+#define QCOM_RPM_PM8921_LVS2			107
+#define QCOM_RPM_PM8921_LVS3			108
+#define QCOM_RPM_PM8921_LVS4			109
+#define QCOM_RPM_PM8921_LVS5			110
+#define QCOM_RPM_PM8921_LVS6			111
+#define QCOM_RPM_PM8921_LVS7			112
+#define QCOM_RPM_PM8921_MVS			113
+#define QCOM_RPM_PM8921_NCP			114
+#define QCOM_RPM_PM8921_S1			115
+#define QCOM_RPM_PM8921_S2			116
+#define QCOM_RPM_PM8921_S3			117
+#define QCOM_RPM_PM8921_S4			118
+#define QCOM_RPM_PM8921_S5			119
+#define QCOM_RPM_PM8921_S6			120
+#define QCOM_RPM_PM8921_S7			121
+#define QCOM_RPM_PM8921_S8			122
+#define QCOM_RPM_PXO_CLK			123
+#define QCOM_RPM_QDSS_CLK			124
+#define QCOM_RPM_SFPB_CLK			125
+#define QCOM_RPM_SMI_CLK			126
+#define QCOM_RPM_SYS_FABRIC_ARB			127
+#define QCOM_RPM_SYS_FABRIC_CLK			128
+#define QCOM_RPM_SYS_FABRIC_HALT		129
+#define QCOM_RPM_SYS_FABRIC_IOCTL		130
+#define QCOM_RPM_SYS_FABRIC_MODE		131
+#define QCOM_RPM_USB_OTG_SWITCH			132
+#define QCOM_RPM_VDDMIN_GPIO			133
+
+#endif