Re: [PATCH 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On 5/29/2014 11:24 AM, Bjorn Andersson wrote: > On Wed, May 28, 2014 at 9:34 AM, Kumar Gala wrote: >> >> On May 27, 2014, at 12:28 PM, 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 >>> --- >>> 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 000..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: >>> + Defintion: indicates that the regulator should not be forced to any >>> +particular mode >>> + >>> +- qcom,force-mode-lpm: >>> + Usage: optional >>> + Value type: >>> + 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: >>> + Definition: indicates that the regulator should be automatically pick >>> + operating mode >>> + >>> +- qcom,force-mode-hpm: >>> + Usage: optional (only available for 8960/8064) >>> + Value type: >>> + 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: >>> + 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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On 29/05/14 19:38, Bjorn Andersson wrote:
On Thu, May 29, 2014 at 9:19 AM, Srinivas Kandagatla
wrote:
+- reg:
+ Usage: required
+ Value type:
+ Definition: two entries specifying the RPM's message ram and ipc
register
+
+- reg-names:
+ Usage: required
+ Value type:
+ 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 = <320>;
qcom,hpm-threshold = <10>;
};
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:
+ Defintion: indicates that the regulator should not be forced to
any
+ particular mode
+
+- qcom,force-mode-lpm:
+ Usage: optional
+ Value type:
+ 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:
+ Definition: indicates that the regulator should be automatically
pick
+ operating mode
+
+- qcom,force-mode-hpm:
+ Usage: optional (only available for 8960/8064)
+ Value type:
+ 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:
+ Definition: indicates that the regulator should be forced to
operate in
+ bypass mode
+
...]
Probably qcom,force-mode:
Usage: optional.
Value type:
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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ a
Re: [PATCH 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On Thu, May 29, 2014 at 9:54 AM, Lee Jones wrote: >> diff --git a/include/dt-bindings/mfd/qcom_rpm.h >> b/include/dt-bindings/mfd/qcom_rpm.h >> new file mode 100644 >> index 000..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_HALT3 > > [...] > >> +#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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On Thu, May 29, 2014 at 9:19 AM, Srinivas Kandagatla
wrote:
>> +- reg:
>> + Usage: required
>> + Value type:
>> + Definition: two entries specifying the RPM's message ram and ipc
>> register
>> +
>> +- reg-names:
>> + Usage: required
>> + Value type:
>> + 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 = <320>;
> qcom,hpm-threshold = <10>;
> };
>
> 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:
>> + Defintion: indicates that the regulator should not be forced to
>> any
>> + particular mode
>> +
>> +- qcom,force-mode-lpm:
>> + Usage: optional
>> + Value type:
>> + 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:
>> + Definition: indicates that the regulator should be automatically
>> pick
>> + operating mode
>> +
>> +- qcom,force-mode-hpm:
>> + Usage: optional (only available for 8960/8064)
>> + Value type:
>> + 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:
>> + Definition: indicates that the regulator should be forced to
>> operate in
>> + bypass mode
>> +
>
> ...]
>
> Probably qcom,force-mode:
> Usage: optional.
> Value type:
>
> 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On Wed, May 28, 2014 at 9:34 AM, Kumar Gala wrote: > > On May 27, 2014, at 12:28 PM, 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 >> --- >> 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 000..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: >> + Definition: must be one of: >> + "qcom,rpm-apq8064" >> + "qcom,rpm-msm8660" >> + "qcom,rpm-msm8960" >> + >> +- reg: >> + Usage: required >> + Value type: >> + Definition: two entries specifying the RPM's message ram and ipc >> register >> + >> +- reg-names: >> + Usage: required >> + Value type: >> + 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: >> + Definition: three entries specifying the RPM's: >> + 1. acknowledgement interrupt >> + 2. error interrupt >> + 3. wakeup interrupt >> + >> +- interrupt-names: >> + Usage: required >> + Value type: >> + 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: >> + Definition: must be 1 >> + >> +- #size-cells: >> + Usage: required >> + Value type: >> + 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: >> + 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: >> + Definition: resource as defined in > > 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: >> + Definition: Frequency (Hz) of the switch-mode power supply; >> + must be one of: >> + 1920, 960, 640, 480, 384, 320, >> + 274, 240, 213, 192, 175, 160, >> + 148, 137, 128, 120 >> + >> +- qcom,hpm-threshold: >> + Usage: optional >> + Value type: >> + 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: >> + Definition: specifies a base load on the specific regulator > > in what units? Thanks > >> + >> +- qcom,boot-load: >> + Usage: optional >> + Value type: >> + 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: >> + Defintion: indicates th
Re: [PATCH 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On 29/05/14 17:30, Kumar Gala wrote:
On May 29, 2014, at 11:19 AM, Srinivas Kandagatla
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 = <320>;
qcom,hpm-threshold = <10>;
};
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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
> 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 > --- > 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 000..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_HALT3 [...] > +#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? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On May 29, 2014, at 11:19 AM, Srinivas Kandagatla
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 = <320>;
> qcom,hpm-threshold = <10>;
> };
>
> 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
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
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
---
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 000..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:
+ Definition: must be one of:
+ "qcom,rpm-apq8064"
+ "qcom,rpm-msm8660"
+ "qcom,rpm-msm8960"
+
+- reg:
+ Usage: required
+ Value type:
+ Definition: two entries specifying the RPM's message ram and ipc
register
+
+- reg-names:
+ Usage: required
+ Value type:
+ 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:
+ Definition: three entries specifying the RPM's:
+ 1. acknowledgement interrupt
+ 2. error interrupt
+ 3. wakeup interrupt
+
+- interrupt-names:
+ Usage: required
+ Value type:
+ Definition: must be the three strings "ack", "err" and "wakeup", in
order
+
+- #address-cells:
+ Usage: required
+ Value type:
+ Definition: must be 1
+
+- #size-cells:
+ Usage: required
+ Value type:
+ 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 = <320>;
qcom,hpm-threshold = <10>;
};
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:
+ 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:
+ Definition: resource as defined in
+
+- qcom,switch-mode-frequency:
+ Usage: required
+ Value type:
+ Definition: Frequency (Hz) of the switch-mode power supply;
+ must be one of:
+ 1920, 960, 640, 480, 384, 320,
+ 274, 240, 213, 192, 175, 160,
+ 148, 137, 128, 120
+
+- qcom,hpm-threshold:
+ Usage: optional
+ Value type:
+ Definition: indicates the breaking point at which the regulator should
+ switch to high power mode
+
+- qcom,load-bias:
+ Usage: optional
+ Value type:
+ Definition: specifies a base load on the specific regulator
+
+- qcom,boot-load:
+ Usage: optional
+ Value type:
+ 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:
+ Defintion: indicates that the regulator should not be forced to any
+ particular mode
+
+- qcom,force-mode-lpm:
+ Usage: optional
+ Value type:
+ Definition: indicates that
Re: [PATCH 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On May 27, 2014, at 12:28 PM, 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 > --- > 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 000..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: > + Definition: must be one of: > + "qcom,rpm-apq8064" > + "qcom,rpm-msm8660" > + "qcom,rpm-msm8960" > + > +- reg: > + Usage: required > + Value type: > + Definition: two entries specifying the RPM's message ram and ipc > register > + > +- reg-names: > + Usage: required > + Value type: > + 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: > + Definition: three entries specifying the RPM's: > + 1. acknowledgement interrupt > + 2. error interrupt > + 3. wakeup interrupt > + > +- interrupt-names: > + Usage: required > + Value type: > + 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: > + Definition: must be 1 > + > +- #size-cells: > + Usage: required > + Value type: > + 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: > + 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: > + Definition: resource as defined in Can we provide a bit more description about what “namespace” this reg is work in. > + > +- qcom,switch-mode-frequency: > + Usage: required > + Value type: > + Definition: Frequency (Hz) of the switch-mode power supply; > + must be one of: > + 1920, 960, 640, 480, 384, 320, > + 274, 240, 213, 192, 175, 160, > + 148, 137, 128, 120 > + > +- qcom,hpm-threshold: > + Usage: optional > + Value type: > + 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: > + Definition: specifies a base load on the specific regulator in what units? > + > +- qcom,boot-load: > + Usage: optional > + Value type: > + 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: > + Defintion: indicates that the regulator should not be forced to any > +particular mode > + > +- qcom,force-mode-lpm: > + Usage: optional > + Value type: > + 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: > + Definition: indicates that the regulator should be automatically pick > + operating mode > + > +- qcom,force-mode-hpm: > + Usage: optional (only available for 8960/8064) > + Value type: > + Definition: indicates that the regulator should be forced to operate in > +
