* [PATCH v3 0/3] Qualcomm Resource Power Manager driver
@ 2014-06-16 18:46 Bjorn Andersson
2014-06-16 18:46 ` [PATCH v3 1/3] soc: devicetree: bindings: Add Qualcomm RPM DT binding Bjorn Andersson
` (4 more replies)
0 siblings, 5 replies; 23+ messages in thread
From: Bjorn Andersson @ 2014-06-16 18:46 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Kumar Gala
Cc: Lee Jones, Josh Cartwright, devicetree, linux-kernel,
linux-arm-kernel, linux-arm-msm
This series adds a regulator driver for the Resource Power Manager found in
Qualcomm 8660, 8960 and 8064 based devices.
The RPM driver exposes resources to its child devices, that can be accessed to
implement drivers for the regulators, clocks and bus frequency control that's
owned by the RPM in these devices.
Changes since v2:
- Fix copy-paste error in dt binding
- Correct incomplete move from mfd to soc
- Correct const mistake in regulator driver
Changes since v1:
- Moved rpm driver to drivers/soc
- Extracted resource table structs from rpm struct, as per Srinivas request
- Dropped mode setting support for the regulators for now. Unsure if we need
it and it requires some rework from the codeaurora solution.
- Using set_voltage_sel instead of rolling my own "snapping", as per Marks
request
- Split regulator ops in mV, uV and swtich versions as per Marks request.
- Added devicetree property to enable pull down.
Bjorn Andersson (3):
soc: devicetree: bindings: Add Qualcomm RPM DT binding
soc: qcom-rpm: Driver for the Qualcomm RPM
regulator: qcom-rpm: Regulator driver for the Qualcomm RPM
.../devicetree/bindings/soc/qcom/qcom,rpm.txt | 261 +++++++
drivers/regulator/Kconfig | 12 +
drivers/regulator/Makefile | 1 +
drivers/regulator/qcom_rpm-regulator.c | 787 +++++++++++++++++++++
drivers/soc/qcom/Kconfig | 14 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/qcom_rpm.c | 573 +++++++++++++++
include/dt-bindings/soc/qcom,rpm.h | 142 ++++
include/linux/soc/qcom_rpm.h | 12 +
9 files changed, 1803 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt
create mode 100644 drivers/regulator/qcom_rpm-regulator.c
create mode 100644 drivers/soc/qcom/qcom_rpm.c
create mode 100644 include/dt-bindings/soc/qcom,rpm.h
create mode 100644 include/linux/soc/qcom_rpm.h
--
1.8.2.2
^ permalink raw reply [flat|nested] 23+ messages in thread* [PATCH v3 1/3] soc: devicetree: bindings: Add Qualcomm RPM DT binding 2014-06-16 18:46 [PATCH v3 0/3] Qualcomm Resource Power Manager driver Bjorn Andersson @ 2014-06-16 18:46 ` Bjorn Andersson 2014-06-17 23:59 ` Stephen Boyd 2014-07-04 6:05 ` Pramod Gurav 2014-06-16 18:46 ` [PATCH v3 2/3] soc: qcom-rpm: Driver for the Qualcomm RPM Bjorn Andersson ` (3 subsequent siblings) 4 siblings, 2 replies; 23+ messages in thread From: Bjorn Andersson @ 2014-06-16 18:46 UTC (permalink / raw) To: Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Kumar Gala Cc: Lee Jones, Josh Cartwright, devicetree, linux-kernel, linux-arm-kernel, linux-arm-msm 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 <bjorn.andersson@sonymobile.com> --- .../devicetree/bindings/soc/qcom/qcom,rpm.txt | 260 +++++++++++++++++++++ include/dt-bindings/soc/qcom,rpm.h | 142 +++++++++++ 2 files changed, 402 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt create mode 100644 include/dt-bindings/soc/qcom,rpm.h diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt new file mode 100644 index 0000000..0366533 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt @@ -0,0 +1,260 @@ +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/soc/qcom,rpm.h> + +- bias-pull-down: + Usage: optional + Value type: <empty> + Definition: enable pull down of the regulator when inactive + +- 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,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/soc/qcom,rpm.h> + +- bias-pull-down: + Usage: optional + Value type: <empty> + Definition: enable pull down of the regulator when inactive + +- 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" + +- reg: + Usage: required + Value type: <u32> + Definition: resource as defined in <dt-bindings/soc/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/soc/qcom/qcom,rpm.h> + + += EXAMPLE + + #include <dt-bindings/soc/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; + + bias-pull-down; + + qcom,switch-mode-frequency = <3200000>; + }; + }; + diff --git a/include/dt-bindings/soc/qcom,rpm.h b/include/dt-bindings/soc/qcom,rpm.h new file mode 100644 index 0000000..d9d840b --- /dev/null +++ b/include/dt-bindings/soc/qcom,rpm.h @@ -0,0 +1,142 @@ +/* + * This header provides constants for the Qualcomm RPM bindings. + */ + +#ifndef _DT_BINDINGS_SOC_QCOM_RPM_H +#define _DT_BINDINGS_SOC_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 -- 1.8.2.2 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH v3 1/3] soc: devicetree: bindings: Add Qualcomm RPM DT binding 2014-06-16 18:46 ` [PATCH v3 1/3] soc: devicetree: bindings: Add Qualcomm RPM DT binding Bjorn Andersson @ 2014-06-17 23:59 ` Stephen Boyd [not found] ` <53A0D651.20605-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2014-06-18 8:34 ` Srinivas Kandagatla 2014-07-04 6:05 ` Pramod Gurav 1 sibling, 2 replies; 23+ messages in thread From: Stephen Boyd @ 2014-06-17 23:59 UTC (permalink / raw) To: Bjorn Andersson Cc: Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Kumar Gala, Lee Jones, Josh Cartwright, devicetree, linux-kernel, linux-arm-kernel, linux-arm-msm On 06/16/14 11:46, Bjorn Andersson wrote: > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt > new file mode 100644 > index 0000000..0366533 > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt > @@ -0,0 +1,260 @@ > +Qualcomm Resource Power Manager (RPM) > + [...] > + > +- 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" ipc is concerning.... > + rpm@108000 { > + compatible = "qcom,rpm-msm8960"; > + reg = <0x108000 0x1000 0x2011008 0x4>; > + (reg-names is missing from the example) because ipc is actually a register inside the Krait complex's global clock control/distribution hardware block (it's located at 0x2011000). >From what I can tell, this is the only non-clock/power register inside there. I plan to send out a driver for this hardware block so that I can switch the L2 aux source mux over to PLL8 instead of PXO (done with a single register write to 0x2011028) and this mapping/use here is going to conflict with that unless I only map the single register like is done here. I wonder if we'd be better off making this region a separate node and having some phandle to it here in the RPM node? That way we have a driver that provides a clock and some IPC handle the RPM driver can get. The SMD driver also uses the same register to kick other processors so having some generic IPC handle may be useful there too. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <53A0D651.20605-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [PATCH v3 1/3] soc: devicetree: bindings: Add Qualcomm RPM DT binding [not found] ` <53A0D651.20605-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> @ 2014-06-18 5:19 ` Bjorn Andersson 0 siblings, 0 replies; 23+ messages in thread From: Bjorn Andersson @ 2014-06-18 5:19 UTC (permalink / raw) To: Stephen Boyd Cc: Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Kumar Gala, Lee Jones, Josh Cartwright, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-arm-msm On Tue, Jun 17, 2014 at 4:59 PM, Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote: [...] > > because ipc is actually a register inside the Krait complex's global > clock control/distribution hardware block (it's located at 0x2011000). > From what I can tell, this is the only non-clock/power register inside > there. I plan to send out a driver for this hardware block so that I can > switch the L2 aux source mux over to PLL8 instead of PXO (done with a > single register write to 0x2011028) and this mapping/use here is going > to conflict with that unless I only map the single register like is done > here. > > I wonder if we'd be better off making this region a separate node and > having some phandle to it here in the RPM node? That way we have a > driver that provides a clock and some IPC handle the RPM driver can get. > The SMD driver also uses the same register to kick other processors so > having some generic IPC handle may be useful there too. Thanks Stephen, I never connected the dots here but now that I found the right pieces of documentation I can only agree with you. This would better be some sort of reverse interrupt chip. Another such use case would be the smsm and smp2p, which in the codeaurora tree are modelled with a custom "state change" api and as gpios respectively. Both of these seems like they should better just be modelled as incoming virtual interrupts and then some sort of outgoing "interrupts" or "signals". Maybe I'm over optimistic regarding the reusability here, but I definitely agree with you that having a "ipc = <&apcs 0>;" does look like a better solution. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 1/3] soc: devicetree: bindings: Add Qualcomm RPM DT binding 2014-06-17 23:59 ` Stephen Boyd [not found] ` <53A0D651.20605-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> @ 2014-06-18 8:34 ` Srinivas Kandagatla 2014-06-18 19:16 ` Stephen Boyd 1 sibling, 1 reply; 23+ messages in thread From: Srinivas Kandagatla @ 2014-06-18 8:34 UTC (permalink / raw) To: Stephen Boyd, Bjorn Andersson Cc: Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Kumar Gala, Lee Jones, Josh Cartwright, devicetree, linux-kernel, linux-arm-kernel, linux-arm-msm On 18/06/14 00:59, Stephen Boyd wrote: > On 06/16/14 11:46, Bjorn Andersson wrote: >> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt >> new file mode 100644 >> index 0000000..0366533 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt >> @@ -0,0 +1,260 @@ >> +Qualcomm Resource Power Manager (RPM) >> + > [...] >> + >> +- 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" > > ipc is concerning.... > >> + rpm@108000 { >> + compatible = "qcom,rpm-msm8960"; >> + reg = <0x108000 0x1000 0x2011008 0x4>; >> + > > (reg-names is missing from the example) > > because ipc is actually a register inside the Krait complex's global > clock control/distribution hardware block (it's located at 0x2011000). > From what I can tell, this is the only non-clock/power register inside > there. I plan to send out a driver for this hardware block so that I can > switch the L2 aux source mux over to PLL8 instead of PXO (done with a > single register write to 0x2011028) and this mapping/use here is going > to conflict with that unless I only map the single register like is done > here. > > I wonder if we'd be better off making this region a separate node and > having some phandle to it here in the RPM node? That way we have a Can't we use syscon based on regmap here? syscon is a better way to share a common register space across multiple drivers. > driver that provides a clock and some IPC handle the RPM driver can get. > The SMD driver also uses the same register to kick other processors so > having some generic IPC handle may be useful there too. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 1/3] soc: devicetree: bindings: Add Qualcomm RPM DT binding 2014-06-18 8:34 ` Srinivas Kandagatla @ 2014-06-18 19:16 ` Stephen Boyd 0 siblings, 0 replies; 23+ messages in thread From: Stephen Boyd @ 2014-06-18 19:16 UTC (permalink / raw) To: Srinivas Kandagatla Cc: Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Kumar Gala, Lee Jones, Josh Cartwright, devicetree, linux-kernel, linux-arm-kernel, linux-arm-msm On 06/18/14 01:34, Srinivas Kandagatla wrote: > > > On 18/06/14 00:59, Stephen Boyd wrote: >> On 06/16/14 11:46, Bjorn Andersson wrote: >>> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt >>> b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt >>> new file mode 100644 >>> index 0000000..0366533 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt >>> @@ -0,0 +1,260 @@ >>> +Qualcomm Resource Power Manager (RPM) >>> + >> [...] >>> + >>> +- 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" >> >> ipc is concerning.... >> >>> + rpm@108000 { >>> + compatible = "qcom,rpm-msm8960"; >>> + reg = <0x108000 0x1000 0x2011008 0x4>; >>> + >> >> (reg-names is missing from the example) >> >> because ipc is actually a register inside the Krait complex's global >> clock control/distribution hardware block (it's located at 0x2011000). >> From what I can tell, this is the only non-clock/power register inside >> there. I plan to send out a driver for this hardware block so that I can >> switch the L2 aux source mux over to PLL8 instead of PXO (done with a >> single register write to 0x2011028) and this mapping/use here is going >> to conflict with that unless I only map the single register like is done >> here. >> >> I wonder if we'd be better off making this region a separate node and >> having some phandle to it here in the RPM node? That way we have a > > Can't we use syscon based on regmap here? syscon is a better way to > share a common register space across multiple drivers. How would the mux clock be registered? I'd like it to be registered by the driver associated with this device with something like devm_clk_register(). From what I can tell syscon wouldn't allow that unless we extend the syscon driver to handle more specific compatible strings. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: [PATCH v3 1/3] soc: devicetree: bindings: Add Qualcomm RPM DT binding 2014-06-16 18:46 ` [PATCH v3 1/3] soc: devicetree: bindings: Add Qualcomm RPM DT binding Bjorn Andersson 2014-06-17 23:59 ` Stephen Boyd @ 2014-07-04 6:05 ` Pramod Gurav 1 sibling, 0 replies; 23+ messages in thread From: Pramod Gurav @ 2014-07-04 6:05 UTC (permalink / raw) To: Bjorn Andersson Cc: Mark Rutland, devicetree, linux-arm-msm, Josh Cartwright, Liam Girdwood, Rob Herring, linux-kernel, Mark Brown, Kumar Gala, Lee Jones, linux-arm-kernel Hi Bjorn, -----Original Message----- From: "Bjorn Andersson" <bjorn.andersson@sonymobile.com> Sent: Tuesday, 17 June, 2014 12:16am To: "Rob Herring" <robh+dt@kernel.org>, "Mark Rutland" <mark.rutland@arm.com>, "Liam Girdwood" <lgirdwood@gmail.com>, "Mark Brown" <broonie@kernel.org>, "Kumar Gala" <galak@codeaurora.org> Cc: "Lee Jones" <lee.jones@linaro.org>, "Josh Cartwright" <joshc@codeaurora.org>, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org Subject: [PATCH v3 1/3] soc: 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 <bjorn.andersson@sonymobile.com> --- .../devicetree/bindings/soc/qcom/qcom,rpm.txt | 260 +++++++++++++++++++++ include/dt-bindings/soc/qcom,rpm.h | 142 +++++++++++ 2 files changed, 402 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt create mode 100644 include/dt-bindings/soc/qcom,rpm.h diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt new file mode 100644 index 0000000..0366533 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt @@ -0,0 +1,260 @@ +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/soc/qcom,rpm.h> + +- bias-pull-down: + Usage: optional + Value type: <empty> + Definition: enable pull down of the regulator when inactive + +- 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,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/soc/qcom,rpm.h> + +- bias-pull-down: + Usage: optional + Value type: <empty> + Definition: enable pull down of the regulator when inactive + +- 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" + +- reg: + Usage: required + Value type: <u32> + Definition: resource as defined in <dt-bindings/soc/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/soc/qcom/qcom,rpm.h> + + += EXAMPLE + + #include <dt-bindings/soc/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; + + bias-pull-down; + + qcom,switch-mode-frequency = <3200000>; + }; + }; + I may be late here to comment, but came across this extra line at EOF when I was applying these patches on my kernel just now. diff --git a/include/dt-bindings/soc/qcom,rpm.h b/include/dt-bindings/soc/qcom,rpm.h new file mode 100644 index 0000000..d9d840b --- /dev/null +++ b/include/dt-bindings/soc/qcom,rpm.h @@ -0,0 +1,142 @@ +/* + * This header provides constants for the Qualcomm RPM bindings. + */ + +#ifndef _DT_BINDINGS_SOC_QCOM_RPM_H +#define _DT_BINDINGS_SOC_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 -- 1.8.2.2 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH v3 2/3] soc: qcom-rpm: Driver for the Qualcomm RPM 2014-06-16 18:46 [PATCH v3 0/3] Qualcomm Resource Power Manager driver Bjorn Andersson 2014-06-16 18:46 ` [PATCH v3 1/3] soc: devicetree: bindings: Add Qualcomm RPM DT binding Bjorn Andersson @ 2014-06-16 18:46 ` Bjorn Andersson 2014-07-04 6:16 ` pramod gurav 2014-06-16 18:46 ` [PATCH v3 3/3] regulator: qcom-rpm: Regulator driver " Bjorn Andersson ` (2 subsequent siblings) 4 siblings, 1 reply; 23+ messages in thread From: Bjorn Andersson @ 2014-06-16 18:46 UTC (permalink / raw) To: Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Kumar Gala Cc: Lee Jones, Josh Cartwright, devicetree, linux-kernel, linux-arm-kernel, linux-arm-msm Driver for the Resource Power Manager (RPM) found in Qualcomm 8660, 8960 and 8064 based devices. The driver exposes resources that child drivers can operate on; to implementing regulator, clock and bus frequency drivers. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> --- drivers/soc/qcom/Kconfig | 14 ++ drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/qcom_rpm.c | 573 +++++++++++++++++++++++++++++++++++++++++++ include/linux/soc/qcom_rpm.h | 12 + 4 files changed, 600 insertions(+) create mode 100644 drivers/soc/qcom/qcom_rpm.c create mode 100644 include/linux/soc/qcom_rpm.h diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig index 7bd2c94..a8c2a96 100644 --- a/drivers/soc/qcom/Kconfig +++ b/drivers/soc/qcom/Kconfig @@ -9,3 +9,17 @@ config QCOM_GSBI functions for connecting the underlying serial UART, SPI, and I2C devices to the output pins. +config QCOM_RPM + tristate "Qualcomm Resource Power Manager (RPM)" + depends on ARCH_QCOM && OF + help + If you say yes to this option, support will be included for the + Resource Power Manager system found in the Qualcomm 8660, 8960 and + 8064 based devices. + + This is required to access many regulators, clocks and bus + frequencies controlled by the RPM on these devices. + + Say M here if you want to include support for the Qualcomm RPM as a + module. This will build a module called "qcom_rpm". + diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile index 4389012..e7706e8 100644 --- a/drivers/soc/qcom/Makefile +++ b/drivers/soc/qcom/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o +obj-$(CONFIG_QCOM_RPM) += qcom_rpm.o diff --git a/drivers/soc/qcom/qcom_rpm.c b/drivers/soc/qcom/qcom_rpm.c new file mode 100644 index 0000000..6fc683a --- /dev/null +++ b/drivers/soc/qcom/qcom_rpm.c @@ -0,0 +1,573 @@ +/* + * Copyright (c) 2014, Sony Mobile Communications AB. + * Copyright (c) 2013, The Linux Foundation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/module.h> +#include <linux/platform_device.h> +#include <linux/of_platform.h> +#include <linux/io.h> +#include <linux/interrupt.h> +#include <linux/soc/qcom_rpm.h> + +#include <dt-bindings/soc/qcom,rpm.h> + +struct qcom_rpm_resource { + unsigned target_id; + unsigned status_id; + unsigned select_id; + unsigned size; +}; + +struct qcom_rpm_data { + u32 version; + const struct qcom_rpm_resource *resource_table; + unsigned n_resources; +}; + +struct qcom_rpm { + struct device *dev; + struct completion ack; + struct mutex lock; + + void __iomem *status_regs; + void __iomem *ctrl_regs; + void __iomem *req_regs; + + void __iomem *ipc_rpm_reg; + + u32 ack_status; + + const struct qcom_rpm_data *data; +}; + +#define RPM_STATUS_REG(rpm, i) ((rpm)->status_regs + (i) * 4) +#define RPM_CTRL_REG(rpm, i) ((rpm)->ctrl_regs + (i) * 4) +#define RPM_REQ_REG(rpm, i) ((rpm)->req_regs + (i) * 4) + +#define RPM_REQUEST_TIMEOUT (5 * HZ) + +#define RPM_REQUEST_CONTEXT 3 +#define RPM_REQ_SELECT 11 +#define RPM_ACK_CONTEXT 15 +#define RPM_ACK_SELECTOR 23 +#define RPM_SELECT_SIZE 7 + +#define RPM_ACTIVE_STATE BIT(0) +#define RPM_NOTIFICATION BIT(30) +#define RPM_REJECTED BIT(31) + +#define RPM_SIGNAL BIT(2) + +static const struct qcom_rpm_resource apq8064_rpm_resource_table[] = { + [QCOM_RPM_CXO_CLK] = { 25, 9, 5, 1 }, + [QCOM_RPM_PXO_CLK] = { 26, 10, 6, 1 }, + [QCOM_RPM_APPS_FABRIC_CLK] = { 27, 11, 8, 1 }, + [QCOM_RPM_SYS_FABRIC_CLK] = { 28, 12, 9, 1 }, + [QCOM_RPM_MM_FABRIC_CLK] = { 29, 13, 10, 1 }, + [QCOM_RPM_DAYTONA_FABRIC_CLK] = { 30, 14, 11, 1 }, + [QCOM_RPM_SFPB_CLK] = { 31, 15, 12, 1 }, + [QCOM_RPM_CFPB_CLK] = { 32, 16, 13, 1 }, + [QCOM_RPM_MMFPB_CLK] = { 33, 17, 14, 1 }, + [QCOM_RPM_EBI1_CLK] = { 34, 18, 16, 1 }, + [QCOM_RPM_APPS_FABRIC_HALT] = { 35, 19, 18, 1 }, + [QCOM_RPM_APPS_FABRIC_MODE] = { 37, 20, 19, 1 }, + [QCOM_RPM_APPS_FABRIC_IOCTL] = { 40, 21, 20, 1 }, + [QCOM_RPM_APPS_FABRIC_ARB] = { 41, 22, 21, 12 }, + [QCOM_RPM_SYS_FABRIC_HALT] = { 53, 23, 22, 1 }, + [QCOM_RPM_SYS_FABRIC_MODE] = { 55, 24, 23, 1 }, + [QCOM_RPM_SYS_FABRIC_IOCTL] = { 58, 25, 24, 1 }, + [QCOM_RPM_SYS_FABRIC_ARB] = { 59, 26, 25, 30 }, + [QCOM_RPM_MM_FABRIC_HALT] = { 89, 27, 26, 1 }, + [QCOM_RPM_MM_FABRIC_MODE] = { 91, 28, 27, 1 }, + [QCOM_RPM_MM_FABRIC_IOCTL] = { 94, 29, 28, 1 }, + [QCOM_RPM_MM_FABRIC_ARB] = { 95, 30, 29, 21 }, + [QCOM_RPM_PM8921_S1] = { 116, 31, 30, 2 }, + [QCOM_RPM_PM8921_S2] = { 118, 33, 31, 2 }, + [QCOM_RPM_PM8921_S3] = { 120, 35, 32, 2 }, + [QCOM_RPM_PM8921_S4] = { 122, 37, 33, 2 }, + [QCOM_RPM_PM8921_S5] = { 124, 39, 34, 2 }, + [QCOM_RPM_PM8921_S6] = { 126, 41, 35, 2 }, + [QCOM_RPM_PM8921_S7] = { 128, 43, 36, 2 }, + [QCOM_RPM_PM8921_S8] = { 130, 45, 37, 2 }, + [QCOM_RPM_PM8921_L1] = { 132, 47, 38, 2 }, + [QCOM_RPM_PM8921_L2] = { 134, 49, 39, 2 }, + [QCOM_RPM_PM8921_L3] = { 136, 51, 40, 2 }, + [QCOM_RPM_PM8921_L4] = { 138, 53, 41, 2 }, + [QCOM_RPM_PM8921_L5] = { 140, 55, 42, 2 }, + [QCOM_RPM_PM8921_L6] = { 142, 57, 43, 2 }, + [QCOM_RPM_PM8921_L7] = { 144, 59, 44, 2 }, + [QCOM_RPM_PM8921_L8] = { 146, 61, 45, 2 }, + [QCOM_RPM_PM8921_L9] = { 148, 63, 46, 2 }, + [QCOM_RPM_PM8921_L10] = { 150, 65, 47, 2 }, + [QCOM_RPM_PM8921_L11] = { 152, 67, 48, 2 }, + [QCOM_RPM_PM8921_L12] = { 154, 69, 49, 2 }, + [QCOM_RPM_PM8921_L13] = { 156, 71, 50, 2 }, + [QCOM_RPM_PM8921_L14] = { 158, 73, 51, 2 }, + [QCOM_RPM_PM8921_L15] = { 160, 75, 52, 2 }, + [QCOM_RPM_PM8921_L16] = { 162, 77, 53, 2 }, + [QCOM_RPM_PM8921_L17] = { 164, 79, 54, 2 }, + [QCOM_RPM_PM8921_L18] = { 166, 81, 55, 2 }, + [QCOM_RPM_PM8921_L19] = { 168, 83, 56, 2 }, + [QCOM_RPM_PM8921_L20] = { 170, 85, 57, 2 }, + [QCOM_RPM_PM8921_L21] = { 172, 87, 58, 2 }, + [QCOM_RPM_PM8921_L22] = { 174, 89, 59, 2 }, + [QCOM_RPM_PM8921_L23] = { 176, 91, 60, 2 }, + [QCOM_RPM_PM8921_L24] = { 178, 93, 61, 2 }, + [QCOM_RPM_PM8921_L25] = { 180, 95, 62, 2 }, + [QCOM_RPM_PM8921_L26] = { 182, 97, 63, 2 }, + [QCOM_RPM_PM8921_L27] = { 184, 99, 64, 2 }, + [QCOM_RPM_PM8921_L28] = { 186, 101, 65, 2 }, + [QCOM_RPM_PM8921_L29] = { 188, 103, 66, 2 }, + [QCOM_RPM_PM8921_CLK1] = { 190, 105, 67, 2 }, + [QCOM_RPM_PM8921_CLK2] = { 192, 107, 68, 2 }, + [QCOM_RPM_PM8921_LVS1] = { 194, 109, 69, 1 }, + [QCOM_RPM_PM8921_LVS2] = { 195, 110, 70, 1 }, + [QCOM_RPM_PM8921_LVS3] = { 196, 111, 71, 1 }, + [QCOM_RPM_PM8921_LVS4] = { 197, 112, 72, 1 }, + [QCOM_RPM_PM8921_LVS5] = { 198, 113, 73, 1 }, + [QCOM_RPM_PM8921_LVS6] = { 199, 114, 74, 1 }, + [QCOM_RPM_PM8921_LVS7] = { 200, 115, 75, 1 }, + [QCOM_RPM_PM8821_S1] = { 201, 116, 76, 2 }, + [QCOM_RPM_PM8821_S2] = { 203, 118, 77, 2 }, + [QCOM_RPM_PM8821_L1] = { 205, 120, 78, 2 }, + [QCOM_RPM_PM8921_NCP] = { 207, 122, 80, 2 }, + [QCOM_RPM_CXO_BUFFERS] = { 209, 124, 81, 1 }, + [QCOM_RPM_USB_OTG_SWITCH] = { 210, 125, 82, 1 }, + [QCOM_RPM_HDMI_SWITCH] = { 211, 126, 83, 1 }, + [QCOM_RPM_DDR_DMM] = { 212, 127, 84, 2 }, + [QCOM_RPM_VDDMIN_GPIO] = { 215, 131, 89, 1 }, +}; + +static const struct qcom_rpm_data apq8064_template = { + .version = 3, + .resource_table = apq8064_rpm_resource_table, + .n_resources = ARRAY_SIZE(apq8064_rpm_resource_table), +}; + +static const struct qcom_rpm_resource msm8660_rpm_resource_table[] = { + [QCOM_RPM_CXO_CLK] = { 32, 12, 5, 1 }, + [QCOM_RPM_PXO_CLK] = { 33, 13, 6, 1 }, + [QCOM_RPM_PLL_4] = { 34, 14, 7, 1 }, + [QCOM_RPM_APPS_FABRIC_CLK] = { 35, 15, 8, 1 }, + [QCOM_RPM_SYS_FABRIC_CLK] = { 36, 16, 9, 1 }, + [QCOM_RPM_MM_FABRIC_CLK] = { 37, 17, 10, 1 }, + [QCOM_RPM_DAYTONA_FABRIC_CLK] = { 38, 18, 11, 1 }, + [QCOM_RPM_SFPB_CLK] = { 39, 19, 12, 1 }, + [QCOM_RPM_CFPB_CLK] = { 40, 20, 13, 1 }, + [QCOM_RPM_MMFPB_CLK] = { 41, 21, 14, 1 }, + [QCOM_RPM_SMI_CLK] = { 42, 22, 15, 1 }, + [QCOM_RPM_EBI1_CLK] = { 43, 23, 16, 1 }, + [QCOM_RPM_APPS_L2_CACHE_CTL] = { 44, 24, 17, 1 }, + [QCOM_RPM_APPS_FABRIC_HALT] = { 45, 25, 18, 2 }, + [QCOM_RPM_APPS_FABRIC_MODE] = { 47, 26, 19, 3 }, + [QCOM_RPM_APPS_FABRIC_ARB] = { 51, 28, 21, 6 }, + [QCOM_RPM_SYS_FABRIC_HALT] = { 63, 29, 22, 2 }, + [QCOM_RPM_SYS_FABRIC_MODE] = { 65, 30, 23, 3 }, + [QCOM_RPM_SYS_FABRIC_ARB] = { 69, 32, 25, 22 }, + [QCOM_RPM_MM_FABRIC_HALT] = { 105, 33, 26, 2 }, + [QCOM_RPM_MM_FABRIC_MODE] = { 107, 34, 27, 3 }, + [QCOM_RPM_MM_FABRIC_ARB] = { 111, 36, 29, 23 }, + [QCOM_RPM_PM8901_SMPS0] = { 134, 37, 30, 2 }, + [QCOM_RPM_PM8901_SMPS1] = { 136, 39, 31, 2 }, + [QCOM_RPM_PM8901_SMPS2] = { 138, 41, 32, 2 }, + [QCOM_RPM_PM8901_SMPS3] = { 140, 43, 33, 2 }, + [QCOM_RPM_PM8901_SMPS4] = { 142, 45, 34, 2 }, + [QCOM_RPM_PM8901_LDO0] = { 144, 47, 35, 2 }, + [QCOM_RPM_PM8901_LDO1] = { 146, 49, 36, 2 }, + [QCOM_RPM_PM8901_LDO2] = { 148, 51, 37, 2 }, + [QCOM_RPM_PM8901_LDO3] = { 150, 53, 38, 2 }, + [QCOM_RPM_PM8901_LDO4] = { 152, 55, 39, 2 }, + [QCOM_RPM_PM8901_LDO5] = { 154, 57, 40, 2 }, + [QCOM_RPM_PM8901_LDO6] = { 156, 59, 41, 2 }, + [QCOM_RPM_PM8901_LVS0] = { 158, 61, 42, 1 }, + [QCOM_RPM_PM8901_LVS1] = { 159, 62, 43, 1 }, + [QCOM_RPM_PM8901_LVS2] = { 160, 63, 44, 1 }, + [QCOM_RPM_PM8901_LVS3] = { 161, 64, 45, 1 }, + [QCOM_RPM_PM8901_MVS] = { 162, 65, 46, 1 }, + [QCOM_RPM_PM8058_SMPS0] = { 163, 66, 47, 2 }, + [QCOM_RPM_PM8058_SMPS1] = { 165, 68, 48, 2 }, + [QCOM_RPM_PM8058_SMPS2] = { 167, 70, 49, 2 }, + [QCOM_RPM_PM8058_SMPS3] = { 169, 72, 50, 2 }, + [QCOM_RPM_PM8058_SMPS4] = { 171, 74, 51, 2 }, + [QCOM_RPM_PM8058_LDO0] = { 173, 76, 52, 2 }, + [QCOM_RPM_PM8058_LDO1] = { 175, 78, 53, 2 }, + [QCOM_RPM_PM8058_LDO2] = { 177, 80, 54, 2 }, + [QCOM_RPM_PM8058_LDO3] = { 179, 82, 55, 2 }, + [QCOM_RPM_PM8058_LDO4] = { 181, 84, 56, 2 }, + [QCOM_RPM_PM8058_LDO5] = { 183, 86, 57, 2 }, + [QCOM_RPM_PM8058_LDO6] = { 185, 88, 58, 2 }, + [QCOM_RPM_PM8058_LDO7] = { 187, 90, 59, 2 }, + [QCOM_RPM_PM8058_LDO8] = { 189, 92, 60, 2 }, + [QCOM_RPM_PM8058_LDO9] = { 191, 94, 61, 2 }, + [QCOM_RPM_PM8058_LDO10] = { 193, 96, 62, 2 }, + [QCOM_RPM_PM8058_LDO11] = { 195, 98, 63, 2 }, + [QCOM_RPM_PM8058_LDO12] = { 197, 100, 64, 2 }, + [QCOM_RPM_PM8058_LDO13] = { 199, 102, 65, 2 }, + [QCOM_RPM_PM8058_LDO14] = { 201, 104, 66, 2 }, + [QCOM_RPM_PM8058_LDO15] = { 203, 106, 67, 2 }, + [QCOM_RPM_PM8058_LDO16] = { 205, 108, 68, 2 }, + [QCOM_RPM_PM8058_LDO17] = { 207, 110, 69, 2 }, + [QCOM_RPM_PM8058_LDO18] = { 209, 112, 70, 2 }, + [QCOM_RPM_PM8058_LDO19] = { 211, 114, 71, 2 }, + [QCOM_RPM_PM8058_LDO20] = { 213, 116, 72, 2 }, + [QCOM_RPM_PM8058_LDO21] = { 215, 118, 73, 2 }, + [QCOM_RPM_PM8058_LDO22] = { 217, 120, 74, 2 }, + [QCOM_RPM_PM8058_LDO23] = { 219, 122, 75, 2 }, + [QCOM_RPM_PM8058_LDO24] = { 221, 124, 76, 2 }, + [QCOM_RPM_PM8058_LDO25] = { 223, 126, 77, 2 }, + [QCOM_RPM_PM8058_LVS0] = { 225, 128, 78, 1 }, + [QCOM_RPM_PM8058_LVS1] = { 226, 129, 79, 1 }, + [QCOM_RPM_PM8058_NCP] = { 227, 130, 80, 2 }, + [QCOM_RPM_CXO_BUFFERS] = { 229, 132, 81, 1 }, +}; + +static const struct qcom_rpm_data msm8660_template = { + .version = -1, + .resource_table = msm8660_rpm_resource_table, + .n_resources = ARRAY_SIZE(msm8660_rpm_resource_table), +}; + +static const struct qcom_rpm_resource msm8960_rpm_resource_table[] = { + [QCOM_RPM_CXO_CLK] = { 25, 9, 5, 1 }, + [QCOM_RPM_PXO_CLK] = { 26, 10, 6, 1 }, + [QCOM_RPM_APPS_FABRIC_CLK] = { 27, 11, 8, 1 }, + [QCOM_RPM_SYS_FABRIC_CLK] = { 28, 12, 9, 1 }, + [QCOM_RPM_MM_FABRIC_CLK] = { 29, 13, 10, 1 }, + [QCOM_RPM_DAYTONA_FABRIC_CLK] = { 30, 14, 11, 1 }, + [QCOM_RPM_SFPB_CLK] = { 31, 15, 12, 1 }, + [QCOM_RPM_CFPB_CLK] = { 32, 16, 13, 1 }, + [QCOM_RPM_MMFPB_CLK] = { 33, 17, 14, 1 }, + [QCOM_RPM_EBI1_CLK] = { 34, 18, 16, 1 }, + [QCOM_RPM_APPS_FABRIC_HALT] = { 35, 19, 18, 1 }, + [QCOM_RPM_APPS_FABRIC_MODE] = { 37, 20, 19, 1 }, + [QCOM_RPM_APPS_FABRIC_IOCTL] = { 40, 21, 20, 1 }, + [QCOM_RPM_APPS_FABRIC_ARB] = { 41, 22, 21, 12 }, + [QCOM_RPM_SYS_FABRIC_HALT] = { 53, 23, 22, 1 }, + [QCOM_RPM_SYS_FABRIC_MODE] = { 55, 24, 23, 1 }, + [QCOM_RPM_SYS_FABRIC_IOCTL] = { 58, 25, 24, 1 }, + [QCOM_RPM_SYS_FABRIC_ARB] = { 59, 26, 25, 29 }, + [QCOM_RPM_MM_FABRIC_HALT] = { 88, 27, 26, 1 }, + [QCOM_RPM_MM_FABRIC_MODE] = { 90, 28, 27, 1 }, + [QCOM_RPM_MM_FABRIC_IOCTL] = { 93, 29, 28, 1 }, + [QCOM_RPM_MM_FABRIC_ARB] = { 94, 30, 29, 23 }, + [QCOM_RPM_PM8921_S1] = { 117, 31, 30, 2 }, + [QCOM_RPM_PM8921_S2] = { 119, 33, 31, 2 }, + [QCOM_RPM_PM8921_S3] = { 121, 35, 32, 2 }, + [QCOM_RPM_PM8921_S4] = { 123, 37, 33, 2 }, + [QCOM_RPM_PM8921_S5] = { 125, 39, 34, 2 }, + [QCOM_RPM_PM8921_S6] = { 127, 41, 35, 2 }, + [QCOM_RPM_PM8921_S7] = { 129, 43, 36, 2 }, + [QCOM_RPM_PM8921_S8] = { 131, 45, 37, 2 }, + [QCOM_RPM_PM8921_L1] = { 133, 47, 38, 2 }, + [QCOM_RPM_PM8921_L2] = { 135, 49, 39, 2 }, + [QCOM_RPM_PM8921_L3] = { 137, 51, 40, 2 }, + [QCOM_RPM_PM8921_L4] = { 139, 53, 41, 2 }, + [QCOM_RPM_PM8921_L5] = { 141, 55, 42, 2 }, + [QCOM_RPM_PM8921_L6] = { 143, 57, 43, 2 }, + [QCOM_RPM_PM8921_L7] = { 145, 59, 44, 2 }, + [QCOM_RPM_PM8921_L8] = { 147, 61, 45, 2 }, + [QCOM_RPM_PM8921_L9] = { 149, 63, 46, 2 }, + [QCOM_RPM_PM8921_L10] = { 151, 65, 47, 2 }, + [QCOM_RPM_PM8921_L11] = { 153, 67, 48, 2 }, + [QCOM_RPM_PM8921_L12] = { 155, 69, 49, 2 }, + [QCOM_RPM_PM8921_L13] = { 157, 71, 50, 2 }, + [QCOM_RPM_PM8921_L14] = { 159, 73, 51, 2 }, + [QCOM_RPM_PM8921_L15] = { 161, 75, 52, 2 }, + [QCOM_RPM_PM8921_L16] = { 163, 77, 53, 2 }, + [QCOM_RPM_PM8921_L17] = { 165, 79, 54, 2 }, + [QCOM_RPM_PM8921_L18] = { 167, 81, 55, 2 }, + [QCOM_RPM_PM8921_L19] = { 169, 83, 56, 2 }, + [QCOM_RPM_PM8921_L20] = { 171, 85, 57, 2 }, + [QCOM_RPM_PM8921_L21] = { 173, 87, 58, 2 }, + [QCOM_RPM_PM8921_L22] = { 175, 89, 59, 2 }, + [QCOM_RPM_PM8921_L23] = { 177, 91, 60, 2 }, + [QCOM_RPM_PM8921_L24] = { 179, 93, 61, 2 }, + [QCOM_RPM_PM8921_L25] = { 181, 95, 62, 2 }, + [QCOM_RPM_PM8921_L26] = { 183, 97, 63, 2 }, + [QCOM_RPM_PM8921_L27] = { 185, 99, 64, 2 }, + [QCOM_RPM_PM8921_L28] = { 187, 101, 65, 2 }, + [QCOM_RPM_PM8921_L29] = { 189, 103, 66, 2 }, + [QCOM_RPM_PM8921_CLK1] = { 191, 105, 67, 2 }, + [QCOM_RPM_PM8921_CLK2] = { 193, 107, 68, 2 }, + [QCOM_RPM_PM8921_LVS1] = { 195, 109, 69, 1 }, + [QCOM_RPM_PM8921_LVS2] = { 196, 110, 70, 1 }, + [QCOM_RPM_PM8921_LVS3] = { 197, 111, 71, 1 }, + [QCOM_RPM_PM8921_LVS4] = { 198, 112, 72, 1 }, + [QCOM_RPM_PM8921_LVS5] = { 199, 113, 73, 1 }, + [QCOM_RPM_PM8921_LVS6] = { 200, 114, 74, 1 }, + [QCOM_RPM_PM8921_LVS7] = { 201, 115, 75, 1 }, + [QCOM_RPM_PM8921_NCP] = { 202, 116, 80, 2 }, + [QCOM_RPM_CXO_BUFFERS] = { 204, 118, 81, 1 }, + [QCOM_RPM_USB_OTG_SWITCH] = { 205, 119, 82, 1 }, + [QCOM_RPM_HDMI_SWITCH] = { 206, 120, 83, 1 }, + [QCOM_RPM_DDR_DMM] = { 207, 121, 84, 2 }, +}; + +static const struct qcom_rpm_data msm8960_template = { + .version = 3, + .resource_table = msm8960_rpm_resource_table, + .n_resources = ARRAY_SIZE(msm8960_rpm_resource_table), +}; + +static const struct of_device_id qcom_rpm_of_match[] = { + { .compatible = "qcom,rpm-apq8064", .data = &apq8064_template }, + { .compatible = "qcom,rpm-msm8660", .data = &msm8660_template }, + { .compatible = "qcom,rpm-msm8960", .data = &msm8960_template }, + { } +}; +MODULE_DEVICE_TABLE(of, qcom_rpm_of_match); + +struct qcom_rpm *dev_get_qcom_rpm(struct device *dev) +{ + return dev_get_drvdata(dev); +} +EXPORT_SYMBOL(dev_get_qcom_rpm); + +int qcom_rpm_write(struct qcom_rpm *rpm, int resource, u32 *buf, size_t count) +{ + const struct qcom_rpm_resource *res; + const struct qcom_rpm_data *data = rpm->data; + u32 sel_mask[RPM_SELECT_SIZE] = { 0 }; + int left; + int ret = 0; + int i; + + if (WARN_ON(resource < 0 || resource >= data->n_resources)) + return -EINVAL; + + res = &data->resource_table[resource]; + if (WARN_ON(res->size != count)) + return -EINVAL; + + mutex_lock(&rpm->lock); + + for (i = 0; i < res->size; i++) + writel_relaxed(buf[i], RPM_REQ_REG(rpm, res->target_id + i)); + + bitmap_set((unsigned long *)sel_mask, res->select_id, 1); + for (i = 0; i < ARRAY_SIZE(sel_mask); i++) { + writel_relaxed(sel_mask[i], + RPM_CTRL_REG(rpm, RPM_REQ_SELECT + i)); + } + + writel_relaxed(RPM_ACTIVE_STATE, + RPM_CTRL_REG(rpm, RPM_REQUEST_CONTEXT)); + + reinit_completion(&rpm->ack); + writel(RPM_SIGNAL, rpm->ipc_rpm_reg); + + left = wait_for_completion_timeout(&rpm->ack, RPM_REQUEST_TIMEOUT); + if (!left) + ret = -ETIMEDOUT; + else if (rpm->ack_status & RPM_REJECTED) + ret = -EIO; + + mutex_unlock(&rpm->lock); + + return ret; +} +EXPORT_SYMBOL(qcom_rpm_write); + +static irqreturn_t qcom_rpm_ack_interrupt(int irq, void *dev) +{ + struct qcom_rpm *rpm = dev; + u32 ack; + int i; + + ack = readl_relaxed(RPM_CTRL_REG(rpm, RPM_ACK_CONTEXT)); + for (i = 0; i < RPM_SELECT_SIZE; i++) + writel_relaxed(0, RPM_CTRL_REG(rpm, RPM_ACK_SELECTOR + i)); + writel(0, RPM_CTRL_REG(rpm, RPM_ACK_CONTEXT)); + + if (ack & RPM_NOTIFICATION) { + dev_warn(rpm->dev, "ignoring notification!\n"); + } else { + rpm->ack_status = ack; + complete(&rpm->ack); + } + + return IRQ_HANDLED; +} + +static irqreturn_t qcom_rpm_err_interrupt(int irq, void *dev) +{ + struct qcom_rpm *rpm = dev; + + writel(0x1, rpm->ipc_rpm_reg); + + dev_err(rpm->dev, "RPM triggered fatal error\n"); + + return IRQ_HANDLED; +} + +static irqreturn_t qcom_rpm_wakeup_interrupt(int irq, void *dev) +{ + return IRQ_HANDLED; +} + +static int qcom_rpm_probe(struct platform_device *pdev) +{ + const struct of_device_id *match; + struct resource *res; + struct qcom_rpm *rpm; + u32 fw_version[3]; + int irq_wakeup; + int irq_ack; + int irq_err; + int ret; + + rpm = devm_kzalloc(&pdev->dev, sizeof(*rpm), GFP_KERNEL); + if (!rpm) { + dev_err(&pdev->dev, "Can't allocate qcom_rpm\n"); + return -ENOMEM; + } + rpm->dev = &pdev->dev; + mutex_init(&rpm->lock); + init_completion(&rpm->ack); + + irq_ack = platform_get_irq_byname(pdev, "ack"); + if (irq_ack < 0) { + dev_err(&pdev->dev, "required ack interrupt missing\n"); + return irq_ack; + } + + irq_err = platform_get_irq_byname(pdev, "err"); + if (irq_err < 0) { + dev_err(&pdev->dev, "required err interrupt missing\n"); + return irq_err; + } + + irq_wakeup = platform_get_irq_byname(pdev, "wakeup"); + if (irq_wakeup < 0) { + dev_err(&pdev->dev, "required wakeup interrupt missing\n"); + return irq_wakeup; + } + + match = of_match_device(qcom_rpm_of_match, &pdev->dev); + rpm->data = match->data; + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + rpm->status_regs = devm_ioremap_resource(&pdev->dev, res); + rpm->ctrl_regs = rpm->status_regs + 0x400; + rpm->req_regs = rpm->status_regs + 0x600; + if (IS_ERR(rpm->status_regs)) + return PTR_ERR(rpm->status_regs); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 1); + rpm->ipc_rpm_reg = devm_ioremap_resource(&pdev->dev, res); + if (IS_ERR(rpm->ipc_rpm_reg)) + return PTR_ERR(rpm->ipc_rpm_reg); + + dev_set_drvdata(&pdev->dev, rpm); + + fw_version[0] = readl(RPM_STATUS_REG(rpm, 0)); + fw_version[1] = readl(RPM_STATUS_REG(rpm, 1)); + fw_version[2] = readl(RPM_STATUS_REG(rpm, 2)); + if (fw_version[0] != rpm->data->version) { + dev_err(&pdev->dev, + "RPM version %u.%u.%u incompatible with driver version %u", + fw_version[0], + fw_version[1], + fw_version[2], + rpm->data->version); + return -EFAULT; + } + + dev_info(&pdev->dev, "RPM firmware %u.%u.%u\n", fw_version[0], + fw_version[1], + fw_version[2]); + + writel(fw_version[0], RPM_CTRL_REG(rpm, 0)); + writel(fw_version[1], RPM_CTRL_REG(rpm, 1)); + writel(fw_version[2], RPM_CTRL_REG(rpm, 2)); + + ret = devm_request_irq(&pdev->dev, + irq_ack, + qcom_rpm_ack_interrupt, + IRQF_TRIGGER_RISING | IRQF_NO_SUSPEND, + "qcom_rpm_ack", + rpm); + if (ret) { + dev_err(&pdev->dev, "failed to request ack interrupt\n"); + return ret; + } + + ret = irq_set_irq_wake(irq_ack, 1); + if (ret) + dev_warn(&pdev->dev, "failed to mark ack irq as wakeup\n"); + + ret = devm_request_irq(&pdev->dev, + irq_err, + qcom_rpm_err_interrupt, + IRQF_TRIGGER_RISING, + "qcom_rpm_err", + rpm); + if (ret) { + dev_err(&pdev->dev, "failed to request err interrupt\n"); + return ret; + } + + ret = devm_request_irq(&pdev->dev, + irq_wakeup, + qcom_rpm_wakeup_interrupt, + IRQF_TRIGGER_RISING, + "qcom_rpm_wakeup", + rpm); + if (ret) { + dev_err(&pdev->dev, "failed to request wakeup interrupt\n"); + return ret; + } + + ret = irq_set_irq_wake(irq_wakeup, 1); + if (ret) + dev_warn(&pdev->dev, "failed to mark wakeup irq as wakeup\n"); + + return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev); +} + +static int qcom_rpm_remove_child(struct device *dev, void *unused) +{ + platform_device_unregister(to_platform_device(dev)); + return 0; +} + +static int qcom_rpm_remove(struct platform_device *pdev) +{ + device_for_each_child(&pdev->dev, NULL, qcom_rpm_remove_child); + return 0; +} + +static struct platform_driver qcom_rpm_driver = { + .probe = qcom_rpm_probe, + .remove = qcom_rpm_remove, + .driver = { + .name = "qcom_rpm", + .owner = THIS_MODULE, + .of_match_table = qcom_rpm_of_match, + }, +}; + +static int __init qcom_rpm_init(void) +{ + return platform_driver_register(&qcom_rpm_driver); +} +arch_initcall(qcom_rpm_init); + +static void __exit qcom_rpm_exit(void) +{ + platform_driver_unregister(&qcom_rpm_driver); +} +module_exit(qcom_rpm_exit) + +MODULE_DESCRIPTION("Qualcomm Resource Power Manager driver"); +MODULE_LICENSE("GPL v2"); diff --git a/include/linux/soc/qcom_rpm.h b/include/linux/soc/qcom_rpm.h new file mode 100644 index 0000000..a52bc37 --- /dev/null +++ b/include/linux/soc/qcom_rpm.h @@ -0,0 +1,12 @@ +#ifndef __QCOM_RPM_H__ +#define __QCOM_RPM_H__ + +#include <linux/types.h> + +struct device; +struct qcom_rpm; + +struct qcom_rpm *dev_get_qcom_rpm(struct device *dev); +int qcom_rpm_write(struct qcom_rpm *rpm, int resource, u32 *buf, size_t count); + +#endif -- 1.8.2.2 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH v3 2/3] soc: qcom-rpm: Driver for the Qualcomm RPM 2014-06-16 18:46 ` [PATCH v3 2/3] soc: qcom-rpm: Driver for the Qualcomm RPM Bjorn Andersson @ 2014-07-04 6:16 ` pramod gurav 0 siblings, 0 replies; 23+ messages in thread From: pramod gurav @ 2014-07-04 6:16 UTC (permalink / raw) To: Bjorn Andersson Cc: Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Kumar Gala, Lee Jones, Josh Cartwright, devicetree, linux-kernel, linux-arm-kernel, linux-arm-msm Hi Bjorn, On Tue, Jun 17, 2014 at 12:16 AM, Bjorn Andersson <bjorn.andersson@sonymobile.com> wrote: > Driver for the Resource Power Manager (RPM) found in Qualcomm 8660, 8960 > and 8064 based devices. The driver exposes resources that child drivers > can operate on; to implementing regulator, clock and bus frequency > drivers. > > Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> > --- > drivers/soc/qcom/Kconfig | 14 ++ > drivers/soc/qcom/Makefile | 1 + > drivers/soc/qcom/qcom_rpm.c | 573 +++++++++++++++++++++++++++++++++++++++++++ > include/linux/soc/qcom_rpm.h | 12 + > 4 files changed, 600 insertions(+) > create mode 100644 drivers/soc/qcom/qcom_rpm.c > create mode 100644 include/linux/soc/qcom_rpm.h > > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig > index 7bd2c94..a8c2a96 100644 > --- a/drivers/soc/qcom/Kconfig > +++ b/drivers/soc/qcom/Kconfig > @@ -9,3 +9,17 @@ config QCOM_GSBI > functions for connecting the underlying serial UART, SPI, and I2C > devices to the output pins. > > +config QCOM_RPM > + tristate "Qualcomm Resource Power Manager (RPM)" > + depends on ARCH_QCOM && OF > + help > + If you say yes to this option, support will be included for the > + Resource Power Manager system found in the Qualcomm 8660, 8960 and > + 8064 based devices. > + > + This is required to access many regulators, clocks and bus > + frequencies controlled by the RPM on these devices. > + > + Say M here if you want to include support for the Qualcomm RPM as a > + module. This will build a module called "qcom_rpm". > + Adds extra line EOF here. > diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile > index 4389012..e7706e8 100644 > --- a/drivers/soc/qcom/Makefile br, Pramod ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v3 3/3] regulator: qcom-rpm: Regulator driver for the Qualcomm RPM 2014-06-16 18:46 [PATCH v3 0/3] Qualcomm Resource Power Manager driver Bjorn Andersson 2014-06-16 18:46 ` [PATCH v3 1/3] soc: devicetree: bindings: Add Qualcomm RPM DT binding Bjorn Andersson 2014-06-16 18:46 ` [PATCH v3 2/3] soc: qcom-rpm: Driver for the Qualcomm RPM Bjorn Andersson @ 2014-06-16 18:46 ` Bjorn Andersson 2014-06-17 17:07 ` [PATCH v3 0/3] Qualcomm Resource Power Manager driver Kevin Hilman 2014-06-17 21:49 ` Srinivas Kandagatla 4 siblings, 0 replies; 23+ messages in thread From: Bjorn Andersson @ 2014-06-16 18:46 UTC (permalink / raw) To: Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Kumar Gala Cc: Lee Jones, Josh Cartwright, devicetree, linux-kernel, linux-arm-kernel, linux-arm-msm Driver for regulators exposed by the Resource Power Manager (RPM) found in Qualcomm 8660, 8960 and 8064 based devices. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> --- drivers/regulator/Kconfig | 12 + drivers/regulator/Makefile | 1 + drivers/regulator/qcom_rpm-regulator.c | 787 +++++++++++++++++++++++++++++++++ 3 files changed, 800 insertions(+) create mode 100644 drivers/regulator/qcom_rpm-regulator.c diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index 903eb37..ea5a405 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -423,6 +423,18 @@ config REGULATOR_PFUZE100 Say y here to support the regulators found on the Freescale PFUZE100/PFUZE200 PMIC. +config REGULATOR_QCOM_RPM + tristate "Qualcomm RPM regulator driver" + depends on QCOM_RPM + help + If you say yes to this option, support will be included for the + regulators exposed by the Resource Power Manager found in Qualcomm + 8660, 8960 and 8064 based devices. + + Say M here if you want to include support for the regulators on the + Qualcomm RPM as a module. The module will be named + "qcom_rpm-regulator". + config REGULATOR_RC5T583 tristate "RICOH RC5T583 Power regulators" depends on MFD_RC5T583 diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile index 12ef277..53b5ce8 100644 --- a/drivers/regulator/Makefile +++ b/drivers/regulator/Makefile @@ -52,6 +52,7 @@ obj-$(CONFIG_REGULATOR_MAX77693) += max77693.o obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o +obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o obj-$(CONFIG_REGULATOR_TPS51632) += tps51632-regulator.o diff --git a/drivers/regulator/qcom_rpm-regulator.c b/drivers/regulator/qcom_rpm-regulator.c new file mode 100644 index 0000000..f28ccdb --- /dev/null +++ b/drivers/regulator/qcom_rpm-regulator.c @@ -0,0 +1,787 @@ +/* + * Copyright (c) 2014, Sony Mobile Communications AB. + * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/module.h> +#include <linux/platform_device.h> +#include <linux/of.h> +#include <linux/of_device.h> +#include <linux/regulator/driver.h> +#include <linux/regulator/machine.h> +#include <linux/regulator/of_regulator.h> +#include <linux/soc/qcom_rpm.h> + +#define MAX_REQUEST_LEN 2 + +struct request_member { + int word; + unsigned int mask; + int shift; +}; + +struct rpm_reg_parts { + struct request_member mV; /* used if voltage is in mV */ + struct request_member uV; /* used if voltage is in uV */ + struct request_member ip; /* peak current in mA */ + struct request_member pd; /* pull down enable */ + struct request_member ia; /* average current in mA */ + struct request_member fm; /* force mode */ + struct request_member pm; /* power mode */ + struct request_member pc; /* pin control */ + struct request_member pf; /* pin function */ + struct request_member enable_state; /* NCP and switch */ + struct request_member comp_mode; /* NCP */ + struct request_member freq; /* frequency: NCP and SMPS */ + struct request_member freq_clk_src; /* clock source: SMPS */ + struct request_member hpm; /* switch: control OCP and SS */ + int request_len; +}; + +#define FORCE_MODE_IS_2_BITS(reg) \ + ((vreg->parts->fm.mask >> vreg->parts->fm.shift) == 3) +#define FORCE_MODE_IS_3_BITS(reg) \ + ((vreg->parts->fm.mask >> vreg->parts->fm.shift) == 7) + +struct qcom_rpm_reg { + struct qcom_rpm *rpm; + + struct mutex lock; + struct device *dev; + struct regulator_desc desc; + const struct rpm_reg_parts *parts; + + int resource; + u32 val[MAX_REQUEST_LEN]; + + int uV; + int is_enabled; +}; + +static const struct rpm_reg_parts rpm8660_ldo_parts = { + .request_len = 2, + .mV = { 0, 0x00000FFF, 0 }, + .ip = { 0, 0x00FFF000, 12 }, + .fm = { 0, 0x03000000, 24 }, + .pc = { 0, 0x3C000000, 26 }, + .pf = { 0, 0xC0000000, 30 }, + .pd = { 1, 0x00000001, 0 }, + .ia = { 1, 0x00001FFE, 1 }, +}; + +static const struct rpm_reg_parts rpm8660_smps_parts = { + .request_len = 2, + .mV = { 0, 0x00000FFF, 0 }, + .ip = { 0, 0x00FFF000, 12 }, + .fm = { 0, 0x03000000, 24 }, + .pc = { 0, 0x3C000000, 26 }, + .pf = { 0, 0xC0000000, 30 }, + .pd = { 1, 0x00000001, 0 }, + .ia = { 1, 0x00001FFE, 1 }, + .freq = { 1, 0x001FE000, 13 }, + .freq_clk_src = { 1, 0x00600000, 21 }, +}; + +static const struct rpm_reg_parts rpm8660_switch_parts = { + .request_len = 1, + .enable_state = { 0, 0x00000001, 0 }, + .pd = { 0, 0x00000002, 1 }, + .pc = { 0, 0x0000003C, 2 }, + .pf = { 0, 0x000000C0, 6 }, + .hpm = { 0, 0x00000300, 8 }, +}; + +static const struct rpm_reg_parts rpm8660_ncp_parts = { + .request_len = 1, + .mV = { 0, 0x00000FFF, 0 }, + .enable_state = { 0, 0x00001000, 12 }, + .comp_mode = { 0, 0x00002000, 13 }, + .freq = { 0, 0x003FC000, 14 }, +}; + +static const struct rpm_reg_parts rpm8960_ldo_parts = { + .request_len = 2, + .uV = { 0, 0x007FFFFF, 0 }, + .pd = { 0, 0x00800000, 23 }, + .pc = { 0, 0x0F000000, 24 }, + .pf = { 0, 0xF0000000, 28 }, + .ip = { 1, 0x000003FF, 0 }, + .ia = { 1, 0x000FFC00, 10 }, + .fm = { 1, 0x00700000, 20 }, +}; + +static const struct rpm_reg_parts rpm8960_smps_parts = { + .request_len = 2, + .uV = { 0, 0x007FFFFF, 0 }, + .pd = { 0, 0x00800000, 23 }, + .pc = { 0, 0x0F000000, 24 }, + .pf = { 0, 0xF0000000, 28 }, + .ip = { 1, 0x000003FF, 0 }, + .ia = { 1, 0x000FFC00, 10 }, + .fm = { 1, 0x00700000, 20 }, + .pm = { 1, 0x00800000, 23 }, + .freq = { 1, 0x1F000000, 24 }, + .freq_clk_src = { 1, 0x60000000, 29 }, +}; + +static const struct rpm_reg_parts rpm8960_switch_parts = { + .request_len = 1, + .enable_state = { 0, 0x00000001, 0 }, + .pd = { 0, 0x00000002, 1 }, + .pc = { 0, 0x0000003C, 2 }, + .pf = { 0, 0x000003C0, 6 }, + .hpm = { 0, 0x00000C00, 10 }, +}; + +static const struct rpm_reg_parts rpm8960_ncp_parts = { + .request_len = 1, + .uV = { 0, 0x007FFFFF, 0 }, + .enable_state = { 0, 0x00800000, 23 }, + .comp_mode = { 0, 0x01000000, 24 }, + .freq = { 0, 0x3E000000, 25 }, +}; + +/* + * Physically available PMIC regulator voltage ranges + */ +static const struct regulator_linear_range pldo_ranges[] = { + REGULATOR_LINEAR_RANGE( 750000, 0, 59, 12500), + REGULATOR_LINEAR_RANGE(1500000, 60, 123, 25000), + REGULATOR_LINEAR_RANGE(3100000, 124, 160, 50000), +}; + +static const struct regulator_linear_range nldo_ranges[] = { + REGULATOR_LINEAR_RANGE( 750000, 0, 63, 12500), +}; + +static const struct regulator_linear_range nldo1200_ranges[] = { + REGULATOR_LINEAR_RANGE( 375000, 0, 59, 6250), + REGULATOR_LINEAR_RANGE( 750000, 60, 123, 12500), +}; + +static const struct regulator_linear_range smps_ranges[] = { + REGULATOR_LINEAR_RANGE( 375000, 0, 29, 12500), + REGULATOR_LINEAR_RANGE( 750000, 30, 89, 12500), + REGULATOR_LINEAR_RANGE(1500000, 90, 153, 25000), +}; + +static const struct regulator_linear_range ftsmps_ranges[] = { + REGULATOR_LINEAR_RANGE( 350000, 0, 6, 50000), + REGULATOR_LINEAR_RANGE( 700000, 7, 63, 12500), + REGULATOR_LINEAR_RANGE(1500000, 64, 100, 50000), +}; + +static const struct regulator_linear_range ncp_ranges[] = { + REGULATOR_LINEAR_RANGE(1500000, 0, 31, 50000), +}; + +static int rpm_reg_write(struct qcom_rpm_reg *vreg, + const struct request_member *req, + const int value) +{ + if (WARN_ON((value << req->shift) & ~req->mask)) + return -EINVAL; + + vreg->val[req->word] &= ~req->mask; + vreg->val[req->word] |= value << req->shift; + + return qcom_rpm_write(vreg->rpm, + vreg->resource, + vreg->val, + vreg->parts->request_len); +} + +static int rpm_reg_set_mV_sel(struct regulator_dev *rdev, + unsigned selector) +{ + struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev); + const struct rpm_reg_parts *parts = vreg->parts; + const struct request_member *req = &parts->mV; + int ret = 0; + int uV; + + if (req->mask == 0) + return -EINVAL; + + uV = regulator_list_voltage_linear_range(rdev, selector); + if (uV < 0) + return uV; + + mutex_lock(&vreg->lock); + vreg->uV = uV; + if (vreg->is_enabled) + ret = rpm_reg_write(vreg, req, vreg->uV / 1000); + mutex_unlock(&vreg->lock); + + return ret; +} + +static int rpm_reg_set_uV_sel(struct regulator_dev *rdev, + unsigned selector) +{ + struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev); + const struct rpm_reg_parts *parts = vreg->parts; + const struct request_member *req = &parts->uV; + int ret = 0; + int uV; + + if (req->mask == 0) + return -EINVAL; + + uV = regulator_list_voltage_linear_range(rdev, selector); + if (uV < 0) + return uV; + + mutex_lock(&vreg->lock); + vreg->uV = uV; + if (vreg->is_enabled) + ret = rpm_reg_write(vreg, req, vreg->uV); + mutex_unlock(&vreg->lock); + + return ret; +} + +static int rpm_reg_get_voltage(struct regulator_dev *rdev) +{ + struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev); + + return vreg->uV; +} + +static int rpm_reg_mV_enable(struct regulator_dev *rdev) +{ + struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev); + const struct rpm_reg_parts *parts = vreg->parts; + const struct request_member *req = &parts->mV; + int ret; + + if (req->mask == 0) + return -EINVAL; + + mutex_lock(&vreg->lock); + ret = rpm_reg_write(vreg, req, vreg->uV / 1000); + if (!ret) + vreg->is_enabled = 1; + mutex_unlock(&vreg->lock); + + return ret; +} + +static int rpm_reg_uV_enable(struct regulator_dev *rdev) +{ + struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev); + const struct rpm_reg_parts *parts = vreg->parts; + const struct request_member *req = &parts->uV; + int ret; + + if (req->mask == 0) + return -EINVAL; + + mutex_lock(&vreg->lock); + ret = rpm_reg_write(vreg, req, vreg->uV); + if (!ret) + vreg->is_enabled = 1; + mutex_unlock(&vreg->lock); + + return ret; +} + +static int rpm_reg_switch_enable(struct regulator_dev *rdev) +{ + struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev); + const struct rpm_reg_parts *parts = vreg->parts; + const struct request_member *req = &parts->enable_state; + int ret; + + if (req->mask == 0) + return -EINVAL; + + mutex_lock(&vreg->lock); + ret = rpm_reg_write(vreg, req, 1); + if (!ret) + vreg->is_enabled = 1; + mutex_unlock(&vreg->lock); + + return ret; +} + +static int rpm_reg_mV_disable(struct regulator_dev *rdev) +{ + struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev); + const struct rpm_reg_parts *parts = vreg->parts; + const struct request_member *req = &parts->mV; + int ret; + + if (req->mask == 0) + return -EINVAL; + + mutex_lock(&vreg->lock); + ret = rpm_reg_write(vreg, req, 0); + if (!ret) + vreg->is_enabled = 0; + mutex_unlock(&vreg->lock); + + return ret; +} + +static int rpm_reg_uV_disable(struct regulator_dev *rdev) +{ + struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev); + const struct rpm_reg_parts *parts = vreg->parts; + const struct request_member *req = &parts->uV; + int ret; + + if (req->mask == 0) + return -EINVAL; + + mutex_lock(&vreg->lock); + ret = rpm_reg_write(vreg, req, 0); + if (!ret) + vreg->is_enabled = 0; + mutex_unlock(&vreg->lock); + + return ret; +} + +static int rpm_reg_switch_disable(struct regulator_dev *rdev) +{ + struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev); + const struct rpm_reg_parts *parts = vreg->parts; + const struct request_member *req = &parts->enable_state; + int ret; + + if (req->mask == 0) + return -EINVAL; + + mutex_lock(&vreg->lock); + ret = rpm_reg_write(vreg, req, 0); + if (!ret) + vreg->is_enabled = 0; + mutex_unlock(&vreg->lock); + + return ret; +} + +static int rpm_reg_is_enabled(struct regulator_dev *rdev) +{ + struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev); + + return vreg->is_enabled; +} + +static struct regulator_ops uV_ops = { + .list_voltage = regulator_list_voltage_linear_range, + + .set_voltage_sel = rpm_reg_set_uV_sel, + .get_voltage = rpm_reg_get_voltage, + + .enable = rpm_reg_uV_enable, + .disable = rpm_reg_uV_disable, + .is_enabled = rpm_reg_is_enabled, +}; + +static struct regulator_ops mV_ops = { + .list_voltage = regulator_list_voltage_linear_range, + + .set_voltage_sel = rpm_reg_set_mV_sel, + .get_voltage = rpm_reg_get_voltage, + + .enable = rpm_reg_mV_enable, + .disable = rpm_reg_mV_disable, + .is_enabled = rpm_reg_is_enabled, +}; + +static struct regulator_ops switch_ops = { + .enable = rpm_reg_switch_enable, + .disable = rpm_reg_switch_disable, + .is_enabled = rpm_reg_is_enabled, +}; + +/* + * PM8058 regulators + */ +static const struct qcom_rpm_reg pm8058_pldo = { + .desc.linear_ranges = pldo_ranges, + .desc.n_linear_ranges = ARRAY_SIZE(pldo_ranges), + .desc.n_voltages = 161, + .desc.ops = &mV_ops, + .parts = &rpm8660_ldo_parts, +}; + +static const struct qcom_rpm_reg pm8058_nldo = { + .desc.linear_ranges = nldo_ranges, + .desc.n_linear_ranges = ARRAY_SIZE(nldo_ranges), + .desc.n_voltages = 64, + .desc.ops = &mV_ops, + .parts = &rpm8660_ldo_parts, +}; + +static const struct qcom_rpm_reg pm8058_smps = { + .desc.linear_ranges = smps_ranges, + .desc.n_linear_ranges = ARRAY_SIZE(smps_ranges), + .desc.n_voltages = 154, + .desc.ops = &mV_ops, + .parts = &rpm8660_smps_parts, +}; + +static const struct qcom_rpm_reg pm8058_ncp = { + .desc.linear_ranges = ncp_ranges, + .desc.n_linear_ranges = ARRAY_SIZE(ncp_ranges), + .desc.n_voltages = 32, + .desc.ops = &mV_ops, + .parts = &rpm8660_ncp_parts, +}; + +static const struct qcom_rpm_reg pm8058_switch = { + .desc.ops = &switch_ops, + .parts = &rpm8660_switch_parts, +}; + +/* + * PM8901 regulators + */ +static const struct qcom_rpm_reg pm8901_pldo = { + .desc.linear_ranges = pldo_ranges, + .desc.n_linear_ranges = ARRAY_SIZE(pldo_ranges), + .desc.n_voltages = 161, + .desc.ops = &mV_ops, + .parts = &rpm8660_ldo_parts, +}; + +static const struct qcom_rpm_reg pm8901_nldo = { + .desc.linear_ranges = nldo_ranges, + .desc.n_linear_ranges = ARRAY_SIZE(nldo_ranges), + .desc.n_voltages = 64, + .desc.ops = &mV_ops, + .parts = &rpm8660_ldo_parts, +}; + +static const struct qcom_rpm_reg pm8901_ftsmps = { + .desc.linear_ranges = ftsmps_ranges, + .desc.n_linear_ranges = ARRAY_SIZE(ftsmps_ranges), + .desc.n_voltages = 101, + .desc.ops = &mV_ops, + .parts = &rpm8660_smps_parts, +}; + +static const struct qcom_rpm_reg pm8901_switch = { + .desc.ops = &switch_ops, + .parts = &rpm8660_switch_parts, +}; + +/* + * PM8921 regulators + */ +static const struct qcom_rpm_reg pm8921_pldo = { + .desc.linear_ranges = pldo_ranges, + .desc.n_linear_ranges = ARRAY_SIZE(pldo_ranges), + .desc.n_voltages = 161, + .desc.ops = &uV_ops, + .parts = &rpm8960_ldo_parts, +}; + +static const struct qcom_rpm_reg pm8921_nldo = { + .desc.linear_ranges = nldo_ranges, + .desc.n_linear_ranges = ARRAY_SIZE(nldo_ranges), + .desc.n_voltages = 64, + .desc.ops = &uV_ops, + .parts = &rpm8960_ldo_parts, +}; + +static const struct qcom_rpm_reg pm8921_nldo1200 = { + .desc.linear_ranges = nldo1200_ranges, + .desc.n_linear_ranges = ARRAY_SIZE(nldo1200_ranges), + .desc.n_voltages = 124, + .desc.ops = &uV_ops, + .parts = &rpm8960_ldo_parts, +}; + +static const struct qcom_rpm_reg pm8921_smps = { + .desc.linear_ranges = smps_ranges, + .desc.n_linear_ranges = ARRAY_SIZE(smps_ranges), + .desc.n_voltages = 154, + .desc.ops = &uV_ops, + .parts = &rpm8960_smps_parts, +}; + +static const struct qcom_rpm_reg pm8921_ftsmps = { + .desc.linear_ranges = ftsmps_ranges, + .desc.n_linear_ranges = ARRAY_SIZE(ftsmps_ranges), + .desc.n_voltages = 101, + .desc.ops = &uV_ops, + .parts = &rpm8960_smps_parts, +}; + +static const struct qcom_rpm_reg pm8921_ncp = { + .desc.linear_ranges = ncp_ranges, + .desc.n_linear_ranges = ARRAY_SIZE(ncp_ranges), + .desc.n_voltages = 32, + .desc.ops = &uV_ops, + .parts = &rpm8960_ncp_parts, +}; + +static const struct qcom_rpm_reg pm8921_switch = { + .desc.ops = &switch_ops, + .parts = &rpm8960_switch_parts, +}; + +static const struct of_device_id rpm_of_match[] = { + { .compatible = "qcom,rpm-pm8058-pldo", .data = &pm8058_pldo }, + { .compatible = "qcom,rpm-pm8058-nldo", .data = &pm8058_nldo }, + { .compatible = "qcom,rpm-pm8058-smps", .data = &pm8058_smps }, + { .compatible = "qcom,rpm-pm8058-ncp", .data = &pm8058_ncp }, + { .compatible = "qcom,rpm-pm8058-switch", .data = &pm8058_switch }, + + { .compatible = "qcom,rpm-pm8901-pldo", .data = &pm8901_pldo }, + { .compatible = "qcom,rpm-pm8901-nldo", .data = &pm8901_nldo }, + { .compatible = "qcom,rpm-pm8901-ftsmps", .data = &pm8901_ftsmps }, + { .compatible = "qcom,rpm-pm8901-switch", .data = &pm8901_switch }, + + { .compatible = "qcom,rpm-pm8921-pldo", .data = &pm8921_pldo }, + { .compatible = "qcom,rpm-pm8921-nldo", .data = &pm8921_nldo }, + { .compatible = "qcom,rpm-pm8921-nldo1200", .data = &pm8921_nldo1200 }, + { .compatible = "qcom,rpm-pm8921-smps", .data = &pm8921_smps }, + { .compatible = "qcom,rpm-pm8921-ftsmps", .data = &pm8921_ftsmps }, + { .compatible = "qcom,rpm-pm8921-ncp", .data = &pm8921_ncp }, + { .compatible = "qcom,rpm-pm8921-switch", .data = &pm8921_switch }, + { } +}; +MODULE_DEVICE_TABLE(of, rpm_of_match); + +static int rpm_reg_set(struct qcom_rpm_reg *vreg, + const struct request_member *req, + const int value) +{ + if (req->mask == 0 || (value << req->shift) & ~req->mask) + return -EINVAL; + + vreg->val[req->word] &= ~req->mask; + vreg->val[req->word] |= value << req->shift; + + return 0; +} + +static int rpm_reg_of_parse_freq(struct device *dev, struct qcom_rpm_reg *vreg) +{ + static const int freq_table[] = { + 19200000, 9600000, 6400000, 4800000, 3840000, 3200000, 2740000, + 2400000, 2130000, 1920000, 1750000, 1600000, 1480000, 1370000, + 1280000, 1200000, + + }; + const char *key; + u32 freq; + int ret; + int i; + + key = "qcom,switch-mode-frequency"; + ret = of_property_read_u32(dev->of_node, key, &freq); + if (ret) { + dev_err(dev, "regulator requires %s property\n", key); + return -EINVAL; + } + + for (i = 0; i < ARRAY_SIZE(freq_table); i++) { + if (freq == freq_table[i]) { + rpm_reg_set(vreg, &vreg->parts->freq, i + 1); + return 0; + } + } + + dev_err(dev, "invalid frequency %d\n", freq); + return -EINVAL; +} + +static int rpm_reg_of_select_one(struct device *dev, + const char * const keys[], + const int count, int def) +{ + int found = -1; + int i; + + for (i = 0; i < count; i++) { + if (!of_property_read_bool(dev->of_node, keys[i])) + continue; + + if (found >= 0) { + dev_err(dev, "%s and %s are mutually exclusive\n", + keys[i], keys[found]); + return -EINVAL; + } + found = i; + } + + if (found == -1) + return def; + + return found; +} + +static int rpm_reg_probe(struct platform_device *pdev) +{ + struct regulator_init_data *initdata; + const struct qcom_rpm_reg *template; + const struct of_device_id *match; + struct regulator_config config = { 0 }; + struct regulator_dev *rdev; + struct qcom_rpm_reg *vreg; + const char *key; + u32 val; + int ret; + + match = of_match_device(rpm_of_match, &pdev->dev); + template = match->data; + + initdata = of_get_regulator_init_data(&pdev->dev, pdev->dev.of_node); + if (!initdata) + return -EINVAL; + + vreg = devm_kmalloc(&pdev->dev, sizeof(*vreg), GFP_KERNEL); + if (!vreg) { + dev_err(&pdev->dev, "failed to allocate vreg\n"); + return -ENOMEM; + } + memcpy(vreg, template, sizeof(*vreg)); + mutex_init(&vreg->lock); + vreg->dev = &pdev->dev; + vreg->desc.id = -1; + vreg->desc.owner = THIS_MODULE; + vreg->desc.type = REGULATOR_VOLTAGE; + vreg->desc.name = pdev->dev.of_node->name; + + vreg->rpm = dev_get_qcom_rpm(pdev->dev.parent); + if (!vreg->rpm) { + dev_err(&pdev->dev, "unable to retrieve handle to rpm\n"); + return -ENODEV; + } + + key = "reg"; + ret = of_property_read_u32(pdev->dev.of_node, key, &val); + if (ret) { + dev_err(&pdev->dev, "failed to read %s\n", key); + return ret; + } + vreg->resource = val; + + if ((vreg->parts->uV.mask || vreg->parts->mV.mask) && + (!initdata->constraints.min_uV || !initdata->constraints.max_uV)) { + dev_err(&pdev->dev, "no voltage specified for regulator\n"); + return -EINVAL; + } + + key = "bias-pull-down"; + if (of_property_read_bool(pdev->dev.of_node, key)) { + ret = rpm_reg_set(vreg, &vreg->parts->pd, 1); + if (ret) { + dev_err(&pdev->dev, "%s is invalid", key); + return ret; + } + } + + if (vreg->parts->freq.mask) { + ret = rpm_reg_of_parse_freq(&pdev->dev, vreg); + if (ret < 0) + return ret; + } + + if (vreg->parts->pm.mask) { + static const char * const keys[] = { + "qcom,power-mode-hysteretic", + "qcom,power-mode-pwm", + }; + + ret = rpm_reg_of_select_one(&pdev->dev, + keys, ARRAY_SIZE(keys), 1); + if (ret < 0) + return ret; + + ret = rpm_reg_set(vreg, &vreg->parts->pm, ret); + if (ret) { + dev_err(&pdev->dev, "failed to set power mode\n"); + return ret; + } + } + + if (FORCE_MODE_IS_2_BITS(vreg)) { + static const char * const keys[] = { + "qcom,force-mode-none", + "qcom,force-mode-lpm", + "qcom,force-mode-hpm" + }; + + ret = rpm_reg_of_select_one(&pdev->dev, + keys, ARRAY_SIZE(keys), 0); + if (ret < 0) + return ret; + + ret = rpm_reg_set(vreg, &vreg->parts->fm, ret); + if (ret) { + dev_err(&pdev->dev, "failed to set force mode\n"); + return ret; + } + } else if (FORCE_MODE_IS_3_BITS(vreg)) { + static const char * const keys[] = { + "qcom,force-mode-none", + "qcom,force-mode-lpm", + "qcom,force-mode-auto", + "qcom,force-mode-hpm", + "qcom,force-mode-bypass", + }; + + ret = rpm_reg_of_select_one(&pdev->dev, + keys, ARRAY_SIZE(keys), 0); + if (ret < 0) + return ret; + + ret = rpm_reg_set(vreg, &vreg->parts->fm, ret); + if (ret) { + dev_err(&pdev->dev, "failed to set force mode\n"); + return ret; + } + } + + config.dev = &pdev->dev; + config.init_data = initdata; + config.driver_data = vreg; + config.of_node = pdev->dev.of_node; + rdev = devm_regulator_register(&pdev->dev, &vreg->desc, &config); + if (IS_ERR(rdev)) { + dev_err(&pdev->dev, "can't register regulator\n"); + return PTR_ERR(rdev); + } + + return 0; +} + +static struct platform_driver rpm_reg_driver = { + .probe = rpm_reg_probe, + .driver = { + .name = "qcom_rpm_reg", + .owner = THIS_MODULE, + .of_match_table = of_match_ptr(rpm_of_match), + }, +}; + +static int __init rpm_reg_init(void) +{ + return platform_driver_register(&rpm_reg_driver); +} +subsys_initcall(rpm_reg_init); + +static void __exit rpm_reg_exit(void) +{ + platform_driver_unregister(&rpm_reg_driver); +} +module_exit(rpm_reg_exit) + +MODULE_DESCRIPTION("Qualcomm RPM regulator driver"); +MODULE_LICENSE("GPL v2"); -- 1.8.2.2 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver 2014-06-16 18:46 [PATCH v3 0/3] Qualcomm Resource Power Manager driver Bjorn Andersson ` (2 preceding siblings ...) 2014-06-16 18:46 ` [PATCH v3 3/3] regulator: qcom-rpm: Regulator driver " Bjorn Andersson @ 2014-06-17 17:07 ` Kevin Hilman 2014-06-17 17:15 ` Bjorn Andersson 2014-06-17 21:49 ` Srinivas Kandagatla 4 siblings, 1 reply; 23+ messages in thread From: Kevin Hilman @ 2014-06-17 17:07 UTC (permalink / raw) To: Bjorn Andersson Cc: Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Kumar Gala, Lee Jones, Josh Cartwright, devicetree, linux-kernel, linux-arm-kernel, linux-arm-msm, Paul Walmsley +Paul Walmsley Bjorn Andersson <bjorn.andersson@sonymobile.com> writes: > This series adds a regulator driver for the Resource Power Manager found in > Qualcomm 8660, 8960 and 8064 based devices. > > The RPM driver exposes resources to its child devices, that can be accessed to > implement drivers for the regulators, clocks and bus frequency control that's > owned by the RPM in these devices. > > Changes since v2: > - Fix copy-paste error in dt binding > - Correct incomplete move from mfd to soc > - Correct const mistake in regulator driver > > Changes since v1: > - Moved rpm driver to drivers/soc I'm not sure I follow the motivation for having this under drivers/soc? In fact, my (possibly incorrect) understanding of this Resource Power Manager is that it's actually to manage communication/control of resources that are actually handled off the SoC by a microcontroller. I added Paul W. to Cc so he can correct me, but I think this is a ways off from the goal of what drivers/soc was for. Kevin ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver 2014-06-17 17:07 ` [PATCH v3 0/3] Qualcomm Resource Power Manager driver Kevin Hilman @ 2014-06-17 17:15 ` Bjorn Andersson 2014-06-18 15:53 ` Kevin Hilman 0 siblings, 1 reply; 23+ messages in thread From: Bjorn Andersson @ 2014-06-17 17:15 UTC (permalink / raw) To: Kevin Hilman, Lee Jones Cc: Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Kumar Gala, Josh Cartwright, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm, Paul Walmsley On Tue, Jun 17, 2014 at 10:07 AM, Kevin Hilman <khilman@linaro.org> wrote: > +Paul Walmsley > > Bjorn Andersson <bjorn.andersson@sonymobile.com> writes: > >> This series adds a regulator driver for the Resource Power Manager found in >> Qualcomm 8660, 8960 and 8064 based devices. >> >> The RPM driver exposes resources to its child devices, that can be accessed to >> implement drivers for the regulators, clocks and bus frequency control that's >> owned by the RPM in these devices. >> >> Changes since v2: >> - Fix copy-paste error in dt binding >> - Correct incomplete move from mfd to soc >> - Correct const mistake in regulator driver >> >> Changes since v1: >> - Moved rpm driver to drivers/soc > > I'm not sure I follow the motivation for having this under drivers/soc? > Hi Kevin, I've made the argument that to me this is conceptually a black box handling regulators, clocks and other stuff; hence similar to a PMIC, which would fit nicely into drivers/mfd. I still think this is the case and now that I look back I didn't get any pushback from Lee Jones so maybe the move was premature? Regards, Bjorn ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver 2014-06-17 17:15 ` Bjorn Andersson @ 2014-06-18 15:53 ` Kevin Hilman 2014-06-18 16:03 ` Kumar Gala 0 siblings, 1 reply; 23+ messages in thread From: Kevin Hilman @ 2014-06-18 15:53 UTC (permalink / raw) To: Bjorn Andersson Cc: Lee Jones, Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Kumar Gala, Josh Cartwright, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm, Paul Walmsley Bjorn Andersson <bjorn@kryo.se> writes: > On Tue, Jun 17, 2014 at 10:07 AM, Kevin Hilman <khilman@linaro.org> wrote: >> +Paul Walmsley >> >> Bjorn Andersson <bjorn.andersson@sonymobile.com> writes: >> >>> This series adds a regulator driver for the Resource Power Manager found in >>> Qualcomm 8660, 8960 and 8064 based devices. >>> >>> The RPM driver exposes resources to its child devices, that can be accessed to >>> implement drivers for the regulators, clocks and bus frequency control that's >>> owned by the RPM in these devices. >>> >>> Changes since v2: >>> - Fix copy-paste error in dt binding >>> - Correct incomplete move from mfd to soc >>> - Correct const mistake in regulator driver >>> >>> Changes since v1: >>> - Moved rpm driver to drivers/soc >> >> I'm not sure I follow the motivation for having this under drivers/soc? >> > Hi Kevin, > > I've made the argument that to me this is conceptually a black box > handling regulators, clocks and other stuff; hence similar to a PMIC, > which would fit nicely into drivers/mfd. > > I still think this is the case and now that I look back I didn't get > any pushback from Lee Jones so maybe the move was premature? Yes, IMO, the move was premature, but hopefully the drivers/soc folks can chime in an clarify the criteria for inclusion there. Kevin ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver 2014-06-18 15:53 ` Kevin Hilman @ 2014-06-18 16:03 ` Kumar Gala 2014-06-18 16:44 ` Kevin Hilman 2014-06-18 16:48 ` Lee Jones 0 siblings, 2 replies; 23+ messages in thread From: Kumar Gala @ 2014-06-18 16:03 UTC (permalink / raw) To: Kevin Hilman Cc: Bjorn Andersson, Lee Jones, Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Josh Cartwright, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm, Paul Walmsley On Jun 18, 2014, at 10:53 AM, Kevin Hilman <khilman@linaro.org> wrote: > Bjorn Andersson <bjorn@kryo.se> writes: > >> On Tue, Jun 17, 2014 at 10:07 AM, Kevin Hilman <khilman@linaro.org> wrote: >>> +Paul Walmsley >>> >>> Bjorn Andersson <bjorn.andersson@sonymobile.com> writes: >>> >>>> This series adds a regulator driver for the Resource Power Manager found in >>>> Qualcomm 8660, 8960 and 8064 based devices. >>>> >>>> The RPM driver exposes resources to its child devices, that can be accessed to >>>> implement drivers for the regulators, clocks and bus frequency control that's >>>> owned by the RPM in these devices. >>>> >>>> Changes since v2: >>>> - Fix copy-paste error in dt binding >>>> - Correct incomplete move from mfd to soc >>>> - Correct const mistake in regulator driver >>>> >>>> Changes since v1: >>>> - Moved rpm driver to drivers/soc >>> >>> I'm not sure I follow the motivation for having this under drivers/soc? >>> >> Hi Kevin, >> >> I've made the argument that to me this is conceptually a black box >> handling regulators, clocks and other stuff; hence similar to a PMIC, >> which would fit nicely into drivers/mfd. >> >> I still think this is the case and now that I look back I didn't get >> any pushback from Lee Jones so maybe the move was premature? > > Yes, IMO, the move was premature, but hopefully the drivers/soc folks > can chime in an clarify the criteria for inclusion there. > > Kevin I dont agree, I think having this in drivers/soc means that we can clearly go through drivers/soc in the future and look for patterns across SoCs that should be re-factored. Where MFD seems like its become the new drivers misc. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver 2014-06-18 16:03 ` Kumar Gala @ 2014-06-18 16:44 ` Kevin Hilman [not found] ` <7hegym6uca.fsf-4poPxKt068f/PtFMR13I2A@public.gmane.org> 2014-06-20 5:17 ` Bjorn Andersson 2014-06-18 16:48 ` Lee Jones 1 sibling, 2 replies; 23+ messages in thread From: Kevin Hilman @ 2014-06-18 16:44 UTC (permalink / raw) To: Kumar Gala Cc: Bjorn Andersson, Lee Jones, Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Josh Cartwright, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm, Paul Walmsley, jaswinder.singh Kumar Gala <galak@codeaurora.org> writes: > On Jun 18, 2014, at 10:53 AM, Kevin Hilman <khilman@linaro.org> wrote: > >> Bjorn Andersson <bjorn@kryo.se> writes: >> >>> On Tue, Jun 17, 2014 at 10:07 AM, Kevin Hilman <khilman@linaro.org> wrote: >>>> +Paul Walmsley >>>> >>>> Bjorn Andersson <bjorn.andersson@sonymobile.com> writes: >>>> >>>>> This series adds a regulator driver for the Resource Power Manager found in >>>>> Qualcomm 8660, 8960 and 8064 based devices. >>>>> >>>>> The RPM driver exposes resources to its child devices, that can be accessed to >>>>> implement drivers for the regulators, clocks and bus frequency control that's >>>>> owned by the RPM in these devices. >>>>> >>>>> Changes since v2: >>>>> - Fix copy-paste error in dt binding >>>>> - Correct incomplete move from mfd to soc >>>>> - Correct const mistake in regulator driver >>>>> >>>>> Changes since v1: >>>>> - Moved rpm driver to drivers/soc >>>> >>>> I'm not sure I follow the motivation for having this under drivers/soc? >>>> >>> Hi Kevin, >>> >>> I've made the argument that to me this is conceptually a black box >>> handling regulators, clocks and other stuff; hence similar to a PMIC, >>> which would fit nicely into drivers/mfd. >>> >>> I still think this is the case and now that I look back I didn't get >>> any pushback from Lee Jones so maybe the move was premature? >> >> Yes, IMO, the move was premature, but hopefully the drivers/soc folks >> can chime in an clarify the criteria for inclusion there. >> >> Kevin > > I dont agree, I think having this in drivers/soc means that we can > clearly go through drivers/soc in the future and look for patterns > across SoCs that should be re-factored. I don't believe that was the goal in creating drivers/soc. > Where MFD seems like its become the new drivers misc. Well, I don't think that drivers/soc wants to be the new drivers/misc either. ;) Thinking more about what this RPM driver actually does, and since you mentioned patterns across SoCs, it seems to me the RPM driver bascially just doing the IPC. So, rather than MFD or drivers/soc, it seems to me that it should be implmented as a controller in the new common mailbox framwork[1] being worked on by Jassi Brar (added to Cc.) IIUC, RPM is actually only doing one-way IPC (it only exposes a write() interface to clients) so it seems like a rather simple implementation of a mailbox controller. I believe Bjorn is already on the list of folks Cc'd on the common mailbox framework, so it would be good to hear from him why RPM wouldn't fit under that framework. Thanks, Kevin [1] https://lkml.org/lkml/2014/6/12/470 ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <7hegym6uca.fsf-4poPxKt068f/PtFMR13I2A@public.gmane.org>]
* Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver [not found] ` <7hegym6uca.fsf-4poPxKt068f/PtFMR13I2A@public.gmane.org> @ 2014-06-19 3:55 ` Jassi Brar 2014-06-19 18:22 ` Bjorn Andersson 0 siblings, 1 reply; 23+ messages in thread From: Jassi Brar @ 2014-06-19 3:55 UTC (permalink / raw) To: Kevin Hilman Cc: Kumar Gala, Bjorn Andersson, Lee Jones, Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Josh Cartwright, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-arm-msm, Paul Walmsley On 18 June 2014 22:14, Kevin Hilman <khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> writes: > >> On Jun 18, 2014, at 10:53 AM, Kevin Hilman <khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >> >>> Bjorn Andersson <bjorn-UYDU3/A3LUY@public.gmane.org> writes: >>> >>>> On Tue, Jun 17, 2014 at 10:07 AM, Kevin Hilman <khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >>>>> +Paul Walmsley >>>>> >>>>> Bjorn Andersson <bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org> writes: >>>>> >>>>>> This series adds a regulator driver for the Resource Power Manager found in >>>>>> Qualcomm 8660, 8960 and 8064 based devices. >>>>>> >>>>>> The RPM driver exposes resources to its child devices, that can be accessed to >>>>>> implement drivers for the regulators, clocks and bus frequency control that's >>>>>> owned by the RPM in these devices. >>>>>> >>>>>> Changes since v2: >>>>>> - Fix copy-paste error in dt binding >>>>>> - Correct incomplete move from mfd to soc >>>>>> - Correct const mistake in regulator driver >>>>>> >>>>>> Changes since v1: >>>>>> - Moved rpm driver to drivers/soc >>>>> >>>>> I'm not sure I follow the motivation for having this under drivers/soc? >>>>> >>>> Hi Kevin, >>>> >>>> I've made the argument that to me this is conceptually a black box >>>> handling regulators, clocks and other stuff; hence similar to a PMIC, >>>> which would fit nicely into drivers/mfd. >>>> >>>> I still think this is the case and now that I look back I didn't get >>>> any pushback from Lee Jones so maybe the move was premature? >>> >>> Yes, IMO, the move was premature, but hopefully the drivers/soc folks >>> can chime in an clarify the criteria for inclusion there. >>> >>> Kevin >> >> I dont agree, I think having this in drivers/soc means that we can >> clearly go through drivers/soc in the future and look for patterns >> across SoCs that should be re-factored. > > I don't believe that was the goal in creating drivers/soc. > >> Where MFD seems like its become the new drivers misc. > > Well, I don't think that drivers/soc wants to be the new drivers/misc > either. ;) > > Thinking more about what this RPM driver actually does, and since you > mentioned patterns across SoCs, it seems to me the RPM driver bascially > just doing the IPC. > > So, rather than MFD or drivers/soc, it seems to me that it should be > implmented as a controller in the new common mailbox framwork[1] being > worked on by Jassi Brar (added to Cc.) > > IIUC, RPM is actually only doing one-way IPC (it only exposes a write() > interface to clients) so it seems like a rather simple implementation of > a mailbox controller. > Yup, qcom_rpm.c is exactly what drivers/mailbox/ is meant for. Agreed the driver is _very_ SoC specific (Qualcomm) but so is any other mailbox driver in my knowledge. So either we move all to drivers/mailbox/ or empty that out into drivers/soc/ I tend to lean towards the first option. Thanks -Jassi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver 2014-06-19 3:55 ` Jassi Brar @ 2014-06-19 18:22 ` Bjorn Andersson 2014-06-19 20:01 ` Jassi Brar 0 siblings, 1 reply; 23+ messages in thread From: Bjorn Andersson @ 2014-06-19 18:22 UTC (permalink / raw) To: Jassi Brar Cc: Kevin Hilman, Kumar Gala, Lee Jones, Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Josh Cartwright, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm, Paul Walmsley On Wed, Jun 18, 2014 at 8:55 PM, Jassi Brar <jaswinder.singh@linaro.org> wrote: > On 18 June 2014 22:14, Kevin Hilman <khilman@linaro.org> wrote: [...] >> Thinking more about what this RPM driver actually does, and since you >> mentioned patterns across SoCs, it seems to me the RPM driver bascially >> just doing the IPC. >> >> So, rather than MFD or drivers/soc, it seems to me that it should be >> implmented as a controller in the new common mailbox framwork[1] being >> worked on by Jassi Brar (added to Cc.) >> >> IIUC, RPM is actually only doing one-way IPC (it only exposes a write() >> interface to clients) so it seems like a rather simple implementation of >> a mailbox controller. >> > Yup, qcom_rpm.c is exactly what drivers/mailbox/ is meant for. > The RPM provides a register file with 80ish registers of variable size, to program the hardware you write to these registers. Then you write to a register selector register and then signal an outgoing interrupt. That is, the interface exposed to the kernel by the SoC is not an mailbox like interface. So I do not share your view that this is "exactly what mailbox is meant for", because if so then you're just re-inventing regmap - with variable size regs. The reason why I'm not using a regmap as my abstraction between the rpm and the clients (e.g. regulator driver) is because it only supports fixed size registers. To me the mailbox api is supposed to abstract communication hardware, not to abstract communication between software components. Regards, Bjorn ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver 2014-06-19 18:22 ` Bjorn Andersson @ 2014-06-19 20:01 ` Jassi Brar 2014-06-20 4:59 ` Bjorn Andersson 0 siblings, 1 reply; 23+ messages in thread From: Jassi Brar @ 2014-06-19 20:01 UTC (permalink / raw) To: Bjorn Andersson Cc: Kevin Hilman, Kumar Gala, Lee Jones, Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Josh Cartwright, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm, Paul Walmsley On 19 June 2014 23:52, Bjorn Andersson <bjorn@kryo.se> wrote: > On Wed, Jun 18, 2014 at 8:55 PM, Jassi Brar <jaswinder.singh@linaro.org> wrote: >> On 18 June 2014 22:14, Kevin Hilman <khilman@linaro.org> wrote: > [...] >>> Thinking more about what this RPM driver actually does, and since you >>> mentioned patterns across SoCs, it seems to me the RPM driver bascially >>> just doing the IPC. >>> >>> So, rather than MFD or drivers/soc, it seems to me that it should be >>> implmented as a controller in the new common mailbox framwork[1] being >>> worked on by Jassi Brar (added to Cc.) >>> >>> IIUC, RPM is actually only doing one-way IPC (it only exposes a write() >>> interface to clients) so it seems like a rather simple implementation of >>> a mailbox controller. >>> >> Yup, qcom_rpm.c is exactly what drivers/mailbox/ is meant for. >> > > The RPM provides a register file with 80ish registers of variable size, to > program the hardware you write to these registers. Then you write to a register > selector register and then signal an outgoing interrupt. > For mailbox_request_channel(), you have dev_get_qcom_rpm() and qcom_rpm_write() for mbox_send_message() Rest all is what you need to fire off a message to remote or register for interrupts. So nothing new to me. > That is, the interface exposed to the kernel by the SoC is not an mailbox like > interface. > I don't understand how having to program 80 registers makes it "not like mailbox"? I have used mailbox api to pass messages between CPUs (using PPI) under same instance of Linux and otoh I think it could also support IPC over gpio (if someone gets that desperate). Mailbox isn't about how you program the h/w. Do whatever is needed to send a message across. BTW I haven't looked closely, but probably you could push the data tables in DT? Cheers -Jassi ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver 2014-06-19 20:01 ` Jassi Brar @ 2014-06-20 4:59 ` Bjorn Andersson 0 siblings, 0 replies; 23+ messages in thread From: Bjorn Andersson @ 2014-06-20 4:59 UTC (permalink / raw) To: Jassi Brar Cc: Kevin Hilman, Kumar Gala, Lee Jones, Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Josh Cartwright, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm, Paul Walmsley On Thu, Jun 19, 2014 at 1:01 PM, Jassi Brar <jaswinder.singh@linaro.org> wrote: [...] > Mailbox isn't about how you program the h/w. Do whatever is needed to > send a message across. > But there are no messages to get across here, each individual resource is exposed directly in the address space of the Linux system. > BTW I haven't looked closely, but probably you could push the data tables in DT? > The first RFC for this had all configuration in devicetree; we decided not to go that path as this gave a cleaner abstraction and is less error prone. Regards, Bjorn ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver 2014-06-18 16:44 ` Kevin Hilman [not found] ` <7hegym6uca.fsf-4poPxKt068f/PtFMR13I2A@public.gmane.org> @ 2014-06-20 5:17 ` Bjorn Andersson 2014-06-20 13:18 ` Jassi Brar 1 sibling, 1 reply; 23+ messages in thread From: Bjorn Andersson @ 2014-06-20 5:17 UTC (permalink / raw) To: Kevin Hilman Cc: Kumar Gala, Lee Jones, Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Josh Cartwright, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm, Paul Walmsley, Jaswinder Singh On Wed, Jun 18, 2014 at 9:44 AM, Kevin Hilman <khilman@linaro.org> wrote: [...] > Thinking more about what this RPM driver actually does, and since you > mentioned patterns across SoCs, it seems to me the RPM driver bascially > just doing the IPC. > Yes, technically this is IPC. But it's all exposed in memory as if it was hardware, so there's no messages or packets to be interpreted by the other side. > So, rather than MFD or drivers/soc, it seems to me that it should be > implmented as a controller in the new common mailbox framwork[1] being > worked on by Jassi Brar (added to Cc.) > > IIUC, RPM is actually only doing one-way IPC (it only exposes a write() > interface to clients) so it seems like a rather simple implementation of > a mailbox controller. > What I think you miss here is the detail of that what the regulator writes is not what is passed over the IPC, but rather is just an interface to abstract away how things are spread our in the register space. So the only place where we do have a "mailbox" here is the actual function call between the regulator and the rpm drivers; not between the rpm driver and the rpm. > I believe Bjorn is already on the list of folks Cc'd on the common > mailbox framework, so it would be good to hear from him why RPM wouldn't > fit under that framework. > In a separate group of Qualcomm platforms the communication with the RPM is done by passing messages over a shared memory channel; as this requires a completely different implementation of the rpm driver, I have started to look at Jassi's patch series. Unfortunately at this point it does not look like the proposed mailbox framework would reduce the complexity of the implementation nor provide any additional benefits when it comes to being able to exchange the underlaying communication methods. But I will continue to follow the development of the mailbox framework. Regards, Bjorn ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver 2014-06-20 5:17 ` Bjorn Andersson @ 2014-06-20 13:18 ` Jassi Brar 0 siblings, 0 replies; 23+ messages in thread From: Jassi Brar @ 2014-06-20 13:18 UTC (permalink / raw) To: Bjorn Andersson Cc: Kevin Hilman, Kumar Gala, Lee Jones, Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Josh Cartwright, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm, Paul Walmsley On 20 June 2014 10:47, Bjorn Andersson <bjorn@kryo.se> wrote: > On Wed, Jun 18, 2014 at 9:44 AM, Kevin Hilman <khilman@linaro.org> wrote: > [...] >> Thinking more about what this RPM driver actually does, and since you >> mentioned patterns across SoCs, it seems to me the RPM driver bascially >> just doing the IPC. >> > > Yes, technically this is IPC. But it's all exposed in memory as if it > was hardware, so there's no messages or packets to be interpreted by > the other side. > >> So, rather than MFD or drivers/soc, it seems to me that it should be >> implmented as a controller in the new common mailbox framwork[1] being >> worked on by Jassi Brar (added to Cc.) >> >> IIUC, RPM is actually only doing one-way IPC (it only exposes a write() >> interface to clients) so it seems like a rather simple implementation of >> a mailbox controller. >> > > What I think you miss here is the detail of that what the regulator > writes is not what is passed over the IPC, but rather is just an > interface to abstract away how things are spread our in the register > space. > > So the only place where we do have a "mailbox" here is the actual > function call between the regulator and the rpm drivers; not between > the rpm driver and the rpm. > Is the RPM a firmware running on a separate processor outside the scope of Linux ? Is an irq raised to the RPM when you do writel(RPM_SIGNAL, rpm->ipc_rpm_reg) ? Do you get the qcom_rpm_ack_interrupt() only when the RPM firmware has taken action on Linux's request (i.e, values filled in 80ish registers)? I maybe wrong but I think the answer to all above is Yes, and that is the reason I think its no different than other mailbox controllers. For example, look at pl320_ipc_transmit() >> I believe Bjorn is already on the list of folks Cc'd on the common >> mailbox framework, so it would be good to hear from him why RPM wouldn't >> fit under that framework. >> > > In a separate group of Qualcomm platforms the communication with the > RPM is done by passing messages over a shared memory channel; as this > requires a completely different implementation of the rpm driver, I > have started to look at Jassi's patch series. > > Unfortunately at this point it does not look like the proposed mailbox > framework would reduce the complexity of the implementation nor > provide any additional benefits when it comes to being able to > exchange the underlaying communication methods. > For your simple one-way communication, using mailbox api isn't going to change lives. Cheers, -Jassi ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver 2014-06-18 16:03 ` Kumar Gala 2014-06-18 16:44 ` Kevin Hilman @ 2014-06-18 16:48 ` Lee Jones 1 sibling, 0 replies; 23+ messages in thread From: Lee Jones @ 2014-06-18 16:48 UTC (permalink / raw) To: Kumar Gala Cc: Kevin Hilman, Bjorn Andersson, Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Josh Cartwright, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm, Paul Walmsley On Wed, 18 Jun 2014, Kumar Gala wrote: > > On Jun 18, 2014, at 10:53 AM, Kevin Hilman <khilman@linaro.org> wrote: > > > Bjorn Andersson <bjorn@kryo.se> writes: > > > >> On Tue, Jun 17, 2014 at 10:07 AM, Kevin Hilman <khilman@linaro.org> wrote: > >>> +Paul Walmsley > >>> > >>> Bjorn Andersson <bjorn.andersson@sonymobile.com> writes: > >>> > >>>> This series adds a regulator driver for the Resource Power Manager found in > >>>> Qualcomm 8660, 8960 and 8064 based devices. > >>>> > >>>> The RPM driver exposes resources to its child devices, that can be accessed to > >>>> implement drivers for the regulators, clocks and bus frequency control that's > >>>> owned by the RPM in these devices. > >>>> > >>>> Changes since v2: > >>>> - Fix copy-paste error in dt binding > >>>> - Correct incomplete move from mfd to soc > >>>> - Correct const mistake in regulator driver > >>>> > >>>> Changes since v1: > >>>> - Moved rpm driver to drivers/soc > >>> > >>> I'm not sure I follow the motivation for having this under drivers/soc? > >>> > >> Hi Kevin, > >> > >> I've made the argument that to me this is conceptually a black box > >> handling regulators, clocks and other stuff; hence similar to a PMIC, > >> which would fit nicely into drivers/mfd. > >> > >> I still think this is the case and now that I look back I didn't get > >> any pushback from Lee Jones so maybe the move was premature? > > > > Yes, IMO, the move was premature, but hopefully the drivers/soc folks > > can chime in an clarify the criteria for inclusion there. > > > > Kevin > > I dont agree, I think having this in drivers/soc means that we can > clearly go through drivers/soc in the future and look for patterns > across SoCs that should be re-factored. > Where MFD seems like its become the new drivers misc. Do you have any grounds for that statement? I only know of one driver which doesn't fit the bounds of a true MFD. If you know of more, I'd like to hear about it. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver 2014-06-16 18:46 [PATCH v3 0/3] Qualcomm Resource Power Manager driver Bjorn Andersson ` (3 preceding siblings ...) 2014-06-17 17:07 ` [PATCH v3 0/3] Qualcomm Resource Power Manager driver Kevin Hilman @ 2014-06-17 21:49 ` Srinivas Kandagatla 4 siblings, 0 replies; 23+ messages in thread From: Srinivas Kandagatla @ 2014-06-17 21:49 UTC (permalink / raw) To: Bjorn Andersson, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown, Kumar Gala Cc: devicetree, linux-arm-msm, Josh Cartwright, linux-kernel, Lee Jones, linux-arm-kernel Hi Bjorn, Thankyou for the patches, these were handy for testing USB on APQ8064. Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> --srini On 16/06/14 19:46, Bjorn Andersson wrote: > This series adds a regulator driver for the Resource Power Manager found in > Qualcomm 8660, 8960 and 8064 based devices. > > The RPM driver exposes resources to its child devices, that can be accessed to > implement drivers for the regulators, clocks and bus frequency control that's > owned by the RPM in these devices. > > Changes since v2: > - Fix copy-paste error in dt binding > - Correct incomplete move from mfd to soc > - Correct const mistake in regulator driver > > Changes since v1: > - Moved rpm driver to drivers/soc > - Extracted resource table structs from rpm struct, as per Srinivas request > - Dropped mode setting support for the regulators for now. Unsure if we need > it and it requires some rework from the codeaurora solution. > - Using set_voltage_sel instead of rolling my own "snapping", as per Marks > request > - Split regulator ops in mV, uV and swtich versions as per Marks request. > - Added devicetree property to enable pull down. > > Bjorn Andersson (3): > soc: devicetree: bindings: Add Qualcomm RPM DT binding > soc: qcom-rpm: Driver for the Qualcomm RPM > regulator: qcom-rpm: Regulator driver for the Qualcomm RPM > > .../devicetree/bindings/soc/qcom/qcom,rpm.txt | 261 +++++++ > drivers/regulator/Kconfig | 12 + > drivers/regulator/Makefile | 1 + > drivers/regulator/qcom_rpm-regulator.c | 787 +++++++++++++++++++++ > drivers/soc/qcom/Kconfig | 14 + > drivers/soc/qcom/Makefile | 1 + > drivers/soc/qcom/qcom_rpm.c | 573 +++++++++++++++ > include/dt-bindings/soc/qcom,rpm.h | 142 ++++ > include/linux/soc/qcom_rpm.h | 12 + > 9 files changed, 1803 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt > create mode 100644 drivers/regulator/qcom_rpm-regulator.c > create mode 100644 drivers/soc/qcom/qcom_rpm.c > create mode 100644 include/dt-bindings/soc/qcom,rpm.h > create mode 100644 include/linux/soc/qcom_rpm.h > ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2014-07-04 6:16 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-16 18:46 [PATCH v3 0/3] Qualcomm Resource Power Manager driver Bjorn Andersson
2014-06-16 18:46 ` [PATCH v3 1/3] soc: devicetree: bindings: Add Qualcomm RPM DT binding Bjorn Andersson
2014-06-17 23:59 ` Stephen Boyd
[not found] ` <53A0D651.20605-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-06-18 5:19 ` Bjorn Andersson
2014-06-18 8:34 ` Srinivas Kandagatla
2014-06-18 19:16 ` Stephen Boyd
2014-07-04 6:05 ` Pramod Gurav
2014-06-16 18:46 ` [PATCH v3 2/3] soc: qcom-rpm: Driver for the Qualcomm RPM Bjorn Andersson
2014-07-04 6:16 ` pramod gurav
2014-06-16 18:46 ` [PATCH v3 3/3] regulator: qcom-rpm: Regulator driver " Bjorn Andersson
2014-06-17 17:07 ` [PATCH v3 0/3] Qualcomm Resource Power Manager driver Kevin Hilman
2014-06-17 17:15 ` Bjorn Andersson
2014-06-18 15:53 ` Kevin Hilman
2014-06-18 16:03 ` Kumar Gala
2014-06-18 16:44 ` Kevin Hilman
[not found] ` <7hegym6uca.fsf-4poPxKt068f/PtFMR13I2A@public.gmane.org>
2014-06-19 3:55 ` Jassi Brar
2014-06-19 18:22 ` Bjorn Andersson
2014-06-19 20:01 ` Jassi Brar
2014-06-20 4:59 ` Bjorn Andersson
2014-06-20 5:17 ` Bjorn Andersson
2014-06-20 13:18 ` Jassi Brar
2014-06-18 16:48 ` Lee Jones
2014-06-17 21:49 ` Srinivas Kandagatla
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).