Re: [PATCH v2] iio: iadc: Qualcomm SPMI PMIC current ADC driver
On Sat, 2014-09-27 at 10:50 +0100, Jonathan Cameron wrote: On 25/09/14 20:21, Ivan T. Ivanov wrote: On Thu, 2014-09-25 at 17:02 +0100, Mark Rutland wrote: On Thu, Sep 25, 2014 at 10:47:15AM +0100, Ivan T. Ivanov wrote: snip +- interrupts: +Usage: optional +Value type: prop-encoded-array +Definition: End of conversion interrupt number. If property is +missing driver will use polling to detect end of conversion +completion. Driver details shouldn't be in the binding. If the driver can poll, that's good, but it should be dropped form this description. Will remove driver details. Is this the only interrupt? Yes. What do you mean be End of conversion interrupt number? Just describe what the interrupt logically is from the PoV of the device -- interrupts is a standard property so we don't need to be too explicit about the type. Badly worded. Just, End of conversion interrupt? The part I didn't understand was what was meant by End of conversion, but dropping number is certainly better. It is clear now, right? End of ADC conversion. Sorry if I'm being thick here, but it's still somewhat confusing to me. That's a consequence of me not being familiar with the HW more than anything, I'm just missing simple details regarding the model of operation, suchs as exactly what the end of ADC conversion entails. There are a few things that could potentially mean depending on how the HW was designed and intended to be used. Does the device periodically sample, convert some number of values (possibly just 1), and trigger an interrupt to state that a buffer is full / values are available? Or is the interrupt triggered for some other reason? Interrupt is triggered after ADC convert analog signal to digital. Other details are irrelevant, I believe. Often called a data ready interrupt. However, here it is per channel so perhaps that description is confusing as well... Not exactly. There is only one interrupt. Simultaneous conversions are not possible. Regards, Ivan -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] cpufreq: allow driver-specific flags
On 27 September 2014 15:44, Mike Turquette mike.turque...@linaro.org wrote: I have another use case for exposing driver flags and I have created a similar patch to this locally in my git tree. Basically some cpufreq drivers may block or sleep during their .set_target callback, and others will not. E.g. the former case is the common pattern to use the clock framework and the regulator framework, both of which hold mutexes and may have slow operations and the latter case is more like the Intel P-state driver with just some register writes. For the energy-aware scheduling work it is desirable to know if the cpufreq driver can do a fast transition of it might sleep, since that affects whether we adjust the cpu frequency from the scheduler context of whether need to put new work on the workqueue (e.g. waking up a kthread dedicated to calling .set_target). I wasn't against exposing the flags but using the same variable to store driver specific data. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM: DT: apq8064 DT patches.
These patches adds dt nodes for RPM, USB and SATA IPs found in APQ8064. All the driver support for these IPs are already available in v3.17, except the RPM driver which is now accepted by Lee and Mark. These patches depend on the header file from http://www.spinics.net/lists/arm-kernel/msg364310.html for regulators. Now that the RPM patch is accepted, should RPM patch go via arm-soc tree? so that we can get more functionality on IFC6410 board in v3.18 mainline. All these patches are tested on IFC6410 board. Am hoping to get these patches for v3.18, as these patches were sitting in my dev tree since last 3 merge windows. Thanks, srini Srinivas Kandagatla (4): ARM: DT: apq8064: add rpm support ARM: DT: apq8064: Add usb host support. ARM: DT: apq8064: Add USB OTG support ARM: DT: apq8064: Add SATA controller support. arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 30 + arch/arm/boot/dts/qcom-apq8064.dtsi| 190 + 2 files changed, 220 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: DT: apq8064: add rpm support
This patch adds rpm node to apq8064 dt as rpm would be used by other
devices for regulator support.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index b3154c0..9c2c8e6 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -3,6 +3,7 @@
#include skeleton.dtsi
#include dt-bindings/clock/qcom,gcc-msm8960.h
#include dt-bindings/clock/qcom,mmcc-msm8960.h
+#include dt-bindings/mfd/qcom-rpm.h
#include dt-bindings/soc/qcom,gsbi.h
#include dt-bindings/interrupt-controller/arm-gic.h
@@ -246,6 +247,24 @@
#reset-cells = 1;
};
+ apcs: syscon@2011000 {
+ compatible = syscon;
+ reg = 0x2011000 0x1000;
+ };
+
+ rpm@108000 {
+ compatible = qcom,rpm-apq8064;
+ reg = 0x108000 0x1000;
+ qcom,ipc = apcs 0x8 2;
+
+ interrupts = 0 19 0, 0 21 0, 0 22 0;
+ interrupt-names = ack, err, wakeup;
+
+ #address-cells = 1;
+ #size-cells = 0;
+
+ };
+
/* Temporary fixed regulator */
vsdcc_fixed: vsdcc-regulator {
compatible = regulator-fixed;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: DT: apq8064: Add SATA controller support.
This patch adds AHCI based SATA controller support to APQ8064.
Tested on IFC6410 board.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 40 +
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 38d3efa..fa057b7 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -274,6 +274,17 @@
regulator-always-on;
};
+ pm8921_s4: pm8921-s4 {
+ compatible = qcom,rpm-pm8921-smps;
+ reg = QCOM_RPM_PM8921_SMPS4;
+
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ qcom,boot-load = 20;
+ qcom,switch-mode-frequency = 320;
+ regulator-always-on;
+ };
+
pm8921_l3: pm8921-l3 {
compatible = qcom,rpm-pm8921-pldo;
reg = QCOM_RPM_PM8921_LDO3;
@@ -396,6 +407,35 @@
usb-phy = usb4_phy;
};
+ sata_phy0:sata-phy@1b40{
+ compatible = qcom,apq8064-sata-phy;
+ reg = 0x1b40 0x200;
+ reg-names = phy_mem;
+ clocks = gcc SATA_PHY_CFG_CLK;
+ clock-names = cfg;
+ #phy-cells = 0;
+ };
+
+ sata0: sata@2900 {
+ compatible = generic-ahci;
+ reg = 0x2900 0x180;
+ interrupts = 0 209 0;
+ clocks = gcc SFAB_SATA_S_H_CLK, gcc SATA_H_CLK,
+gcc SATA_A_CLK, gcc SATA_RXOOB_CLK,
+gcc SATA_PMALIVE_CLK;
+
+ clock-names = slave_iface, iface,
+ bus, rxoob,
+ core_pmalive;
+ assigned-clocks = gcc SATA_RXOOB_CLK,
+ gcc SATA_PMALIVE_CLK;
+ assigned-clock-rates = 1, 1;
+
+ phys = sata_phy0;
+ phy-names = sata-phy;
+ target-supply = pm8921_s4;
+ };
+
/* Temporary fixed regulator */
vsdcc_fixed: vsdcc-regulator {
compatible = regulator-fixed;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: DT: apq8064: Add usb host support.
This patch adds device tree nodes to support two usb hosts on APQ8064
SOC.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 16 ++
arch/arm/boot/dts/qcom-apq8064.dtsi| 85 ++
2 files changed, 101 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index b396c83..d6036b8 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -40,6 +40,22 @@
};
};
+ usb3_phy:phy@1252 {
+ status = ok;
+ };
+
+ usb4_phy:phy@1253 {
+ status = ok;
+ };
+
+ usb3: usb@1252 {
+ status = ok;
+ };
+
+ usb4: usb@1253 {
+ status = ok;
+ };
+
amba {
/* eMMC */
sdcc1: sdcc@1240 {
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 9c2c8e6..491a136 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -263,6 +263,91 @@
#address-cells = 1;
#size-cells = 0;
+ pm8921_s3: pm8921-s3 {
+ compatible = qcom,rpm-pm8921-smps;
+ reg = QCOM_RPM_PM8921_SMPS3;
+
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 140;
+ qcom,boot-load = 49360;
+ qcom,switch-mode-frequency = 320;
+ regulator-always-on;
+ };
+
+ pm8921_l3: pm8921-l3 {
+ compatible = qcom,rpm-pm8921-pldo;
+ reg = QCOM_RPM_PM8921_LDO3;
+
+ regulator-min-microvolt = 305;
+ regulator-max-microvolt = 330;
+ regulator-always-on;
+ qcom,boot-load = 5;
+ };
+
+ pm8921_l23: pm8921-l23 {
+ compatible = qcom,rpm-pm8921-pldo;
+ reg = QCOM_RPM_PM8921_LDO23;
+
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 180;
+ qcom,boot-load = 5;
+ regulator-always-on;
+ };
+
+ };
+
+ usb3_phy:phy@1252 {
+ compatible = qcom,usb-otg-ci;
+ reg = 0x1252 0x400;
+ interrupts = 0 188 0;
+ status = disabled;
+ dr_mode = host;
+
+ clocks = gcc USB_HS3_XCVR_CLK,
+ gcc USB_HS3_H_CLK;
+ clock-names = core, iface;
+
+ vddcx-supply= pm8921_s3;
+ v3p3-supply = pm8921_l3;
+ v1p8-supply = pm8921_l23;
+
+ resets = gcc USB_HS3_RESET;
+ reset-names = link;
+ };
+
+ usb4_phy:phy@1253 {
+ compatible = qcom,usb-otg-ci;
+ reg = 0x1253 0x400;
+ interrupts = 0 215 0;
+ status = disabled;
+ dr_mode = host;
+
+ clocks = gcc USB_HS4_XCVR_CLK,
+ gcc USB_HS4_H_CLK;
+ clock-names = core, iface;
+
+ vddcx-supply= pm8921_s3;
+ v3p3-supply = pm8921_l3;
+ v1p8-supply = pm8921_l23;
+
+ resets = gcc USB_HS4_RESET;
+ reset-names = link;
+ };
+
+ usb3: usb@1252 {
+ compatible = qcom,ehci-host;
+ reg = 0x1252 0x400;
+ interrupts = 0 188 0;
+ status = disabled;
+ usb-phy = usb3_phy;
+ };
+
+ usb4: usb@1253 {
+ compatible = qcom,ehci-host;
+ reg = 0x1253 0x400;
+
[PATCH 3/4] ARM: DT: apq8064: Add USB OTG support
This patch adds USB OTG support on USB1 of APQ8064 SOC.
Tested on IFC6410 with ethernet gadget.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 14 +
arch/arm/boot/dts/qcom-apq8064.dtsi| 46 ++
2 files changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index d6036b8..f41fb39 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -40,6 +40,11 @@
};
};
+ /* OTG */
+ usb1_phy:phy@1250 {
+ status = ok;
+ };
+
usb3_phy:phy@1252 {
status = ok;
};
@@ -48,6 +53,15 @@
status = ok;
};
+ gadget1:gadget@1250 {
+ status = ok;
+ };
+
+ /* OTG */
+ usb1: usb@1250 {
+ status = ok;
+ };
+
usb3: usb@1252 {
status = ok;
};
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 491a136..38d3efa 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -284,6 +284,16 @@
qcom,boot-load = 5;
};
+ pm8921_l4: pm8921-l4 {
+ compatible = qcom,rpm-pm8921-pldo;
+ reg = QCOM_RPM_PM8921_LDO4;
+
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ qcom,boot-load = 5;
+ };
+
pm8921_l23: pm8921-l23 {
compatible = qcom,rpm-pm8921-pldo;
reg = QCOM_RPM_PM8921_LDO23;
@@ -296,6 +306,25 @@
};
+ usb1_phy:phy@1250 {
+ compatible = qcom,usb-otg-ci;
+ reg = 0x1250 0x400;
+ interrupts = 0 100 0;
+ status = disabled;
+ dr_mode = host;
+
+ clocks = gcc USB_HS1_XCVR_CLK,
+ gcc USB_HS1_H_CLK;
+ clock-names = core, iface;
+
+ vddcx-supply= pm8921_s3;
+ v3p3-supply = pm8921_l3;
+ v1p8-supply = pm8921_l4;
+
+ resets = gcc USB_HS1_RESET;
+ reset-names = link;
+ };
+
usb3_phy:phy@1252 {
compatible = qcom,usb-otg-ci;
reg = 0x1252 0x400;
@@ -334,6 +363,23 @@
reset-names = link;
};
+ gadget1:gadget@1250 {
+ compatible = qcom,ci-hdrc;
+ reg = 0x1250 0x400;
+ status = disabled;
+ dr_mode = peripheral;
+ interrupts = 0 100 0;
+ usb-phy = usb1_phy;
+ };
+
+ usb1: usb@1250 {
+ compatible = qcom,ehci-host;
+ reg = 0x1250 0x400;
+ interrupts = 0 100 0;
+ status = disabled;
+ usb-phy = usb1_phy;
+ };
+
usb3: usb@1252 {
compatible = qcom,ehci-host;
reg = 0x1252 0x400;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: DT: apq8064: add CM-QS600 board
Hi Mike,
On 09/26/14 19:32, Mike Rapoport wrote:
CM-QS600 is a APQ8064 based computer on module.
The details are available at
http://compulab.co.il/products/computer-on-modules/cm-qs600/
Signed-off-by: Mike Rapoport mike.rapop...@gmail.com
Thanks for working on this!
Some minor notes...
Can we have the subject aligned with other submissions, e.g.
ARM: dts: qcom: ...
?
---
v2 changes: duplicate the settings for the cm-qs600 board in its .dts file as
Kumar suggested
v3 changes: add board details and keep dts Makefile sorted alphabetically
[...]
new file mode 100644
index 000..db7cf03
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
@@ -0,0 +1,59 @@
[...]
+ eeprom: eeprom@52 {
+ compatible = atmel,24c128;
I believe the above should be 24c02.
And the address is 0x50.
+ reg = 0x52;
+ pagesize = 32;
pagesize is 16.
[...]
Apart from the eeprom stuff above:
Acked-by: Igor Grinberg grinb...@compulab.co.il
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: DT: apq8064: add CM-QS600 board
On 09/29/14 12:35, Igor Grinberg wrote:
Hi Mike,
On 09/26/14 19:32, Mike Rapoport wrote:
CM-QS600 is a APQ8064 based computer on module.
The details are available at
http://compulab.co.il/products/computer-on-modules/cm-qs600/
Signed-off-by: Mike Rapoport mike.rapop...@gmail.com
Thanks for working on this!
Some minor notes...
Can we have the subject aligned with other submissions, e.g.
ARM: dts: qcom: ...
?
---
v2 changes: duplicate the settings for the cm-qs600 board in its .dts file
as Kumar suggested
v3 changes: add board details and keep dts Makefile sorted alphabetically
[...]
new file mode 100644
index 000..db7cf03
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
@@ -0,0 +1,59 @@
[...]
+eeprom: eeprom@52 {
+compatible = atmel,24c128;
I believe the above should be 24c02.
And the address is 0x50.
Also, atmel is not the only vendor for the eeprom chips we use,
so I think at24 instead of atmel will do better here.
+reg = 0x52;
+pagesize = 32;
pagesize is 16.
[...]
Apart from the eeprom stuff above:
Acked-by: Igor Grinberg grinb...@compulab.co.il
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/7] qcom: spm: Add Subsystem Power Manager driver
Hi Lina,
After enabling CONFIG_DEBUG_SECTION_MISMATCH I see few section mismatch
warnings like:
WARNING: drivers/soc/qcom/built-in.o(.text+0x2f0): Section mismatch in
reference from the function spm_dev_probe() to the (unknown reference)
.init.rodata:(unknown)
The function spm_dev_probe() references
the (unknown reference) __initconst (unknown).
This is often because spm_dev_probe lacks a __initconst
annotation or the annotation of (unknown) is wrong.
On Saturday 27 September 2014 06:28 AM, Lina Iyer wrote:
Based on work by many authors, available at codeaurora.org
SPM is a hardware block that controls the peripheral logic surrounding
the application cores (cpu/l$). When the core executes WFI instruction,
the SPM takes over the putting the core in low power state as
configured. The wake up for the SPM is an interrupt at the GIC, which
..
+
+static const struct of_device_id spm_match_table[] __initconst = {
Removing __initconst fixes the warning.
+ { .compatible = qcom,msm8974-saw2-v2.1-cpu,
+ .data = spm_reg_8974_8084_cpu },
+ { .compatible = qcom,apq8084-saw2-v2.1-cpu,
+ .data = spm_reg_8974_8084_cpu },
+ { },
+};
+
+static int spm_dev_probe(struct platform_device *pdev)
+{
Thanks
Pramod
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 5/7] qcom: cpuidle: Add cpuidle driver for QCOM cpus
Hi Lina
One sections mismatch warning here as well:
WARNING: drivers/cpuidle/built-in.o(.text+0x2740): Section mismatch in
reference from the function qcom_cpuidle_probe() to the (unknown
reference) .init.rodata:(unknown)
The function qcom_cpuidle_probe() references
the (unknown reference) __initconst (unknown).
This is often because qcom_cpuidle_probe lacks a __initconst
annotation or the annotation of (unknown) is wrong.
On Saturday 27 September 2014 06:28 AM, Lina Iyer wrote:
Add cpuidle driver interface to allow cpus to go into C-States. Use the
cpuidle DT interface common across ARM architectures to provide the
C-State information to the cpuidle framework.
..
+};
+
+static const struct of_device_id qcom_idle_state_match[] __initconst = {
This is causing it.
+ { .compatible = qcom,idle-state-wfi, .data = qcom_lpm_enter_wfi },
+ { .compatible = qcom,idle-state-spc, .data = qcom_lpm_enter_spc },
+ { },
+};
+
Thanks
Pramod
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ARM: DT: apq8064: Add USB OTG support
Hi Srinivas,
Some review are comments inline.
On Monday 29 September 2014 02:45 PM, Srinivas Kandagatla wrote:
This patch adds USB OTG support on USB1 of APQ8064 SOC.
Tested on IFC6410 with ethernet gadget.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 14 +
arch/arm/boot/dts/qcom-apq8064.dtsi| 46
++
2 files changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index d6036b8..f41fb39 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -40,6 +40,11 @@
};
};
+ /* OTG */
+ usb1_phy:phy@1250 {
+ status = ok;
Its canonical value is okay (although in practice anything
other than disabled should work).
+ };
+
usb3_phy:phy@1252 {
status = ok;
};
@@ -48,6 +53,15 @@
status = ok;
};
+ gadget1:gadget@1250 {
+ status = ok;
+ };
+
+ /* OTG */
+ usb1: usb@1250 {
+ status = ok;
+ };
+
usb3: usb@1252 {
status = ok;
};
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 491a136..38d3efa 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -284,6 +284,16 @@
qcom,boot-load = 5;
};
+ pm8921_l4: pm8921-l4 {
+ compatible = qcom,rpm-pm8921-pldo;
+ reg = QCOM_RPM_PM8921_LDO4;
+
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ qcom,boot-load = 5;
+ };
+
pm8921_l23: pm8921-l23 {
compatible = qcom,rpm-pm8921-pldo;
reg = QCOM_RPM_PM8921_LDO23;
@@ -296,6 +306,25 @@
};
+ usb1_phy:phy@1250 {
+ compatible = qcom,usb-otg-ci;
+ reg = 0x1250 0x400;
+ interrupts = 0 100 0;
The trailing 0 might be IRQ_TYPE_NONE?
+ status = disabled;
Usually the status property goes first.
+ dr_mode = host;
+
+ clocks = gcc USB_HS1_XCVR_CLK,
+ gcc USB_HS1_H_CLK;
+ clock-names = core, iface;
+
+ vddcx-supply= pm8921_s3;
+ v3p3-supply = pm8921_l3;
+ v1p8-supply = pm8921_l4;
+
+ resets = gcc USB_HS1_RESET;
+ reset-names = link;
+ };
+
usb3_phy:phy@1252 {
compatible = qcom,usb-otg-ci;
reg = 0x1252 0x400;
@@ -334,6 +363,23 @@
reset-names = link;
};
+ gadget1:gadget@1250 {
+ compatible = qcom,ci-hdrc;
+ reg = 0x1250 0x400;
+ status = disabled;
+ dr_mode = peripheral;
+ interrupts = 0 100 0;
+ usb-phy = usb1_phy;
+ };
+
+ usb1: usb@1250 {
+ compatible = qcom,ehci-host;
+ reg = 0x1250 0x400;
+ interrupts = 0 100 0;
+ status = disabled;
+ usb-phy = usb1_phy;
+ };
+
usb3: usb@1252 {
compatible = qcom,ehci-host;
reg = 0x1252 0x400;
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] scsi: fix sparse warning
This patch fixes newly introduced sparse warning, introduced by
scis: fixing the type for well known LUs.
Sparse warning:
drivers/scsi/scsi_scan.c:825: warning: format '%16p' expects type
'void *', but argument 6 has type 'u64'
Signed-off-by: Dolev Raviv dra...@codeaurora.org
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index c6c5716..74b28c9 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -813,8 +813,8 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned
char *inq_result,
*/
if (scsi_is_wlun(sdev-lun) sdev-type != TYPE_WLUN) {
sdev_printk(KERN_WARNING, sdev,
- %s: correcting incorrect peripheral device
type 0x%x for W-LUN 0x%16phN\n,
- __func__, sdev-type, sdev-lun);
+ %s: correcting incorrect peripheral device
type 0x%x for W-LUN 0x%16xhN\n,
+ __func__, sdev-type, (unsigned int)sdev-lun);
sdev-type = TYPE_WLUN;
}
--
1.8.5.2
--
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] scsi: ufs: fix sparse warning
This patch fixes newly introduced sparse warning, introduced by
UFS power management series.
Sparse warning:
drivers/scsi/ufs/ufshcd.c:1867:5: sparse: symbol
'ufshcd_uic_pwr_ctrl' was not declared. Should it be static?
drivers/scsi/ufs/ufshcd.c:2025:5: sparse: symbol
'ufshcd_change_power_mode' was not declared. Should it be static?
Signed-off-by: Dolev Raviv dra...@codeaurora.org
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 5c78c3d..497c38a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2146,7 +2146,7 @@ EXPORT_SYMBOL_GPL(ufshcd_dme_get_attr);
*
* Returns 0 on success, non-zero value on failure
*/
-int ufshcd_uic_pwr_ctrl(struct ufs_hba *hba, struct uic_command *cmd)
+static int ufshcd_uic_pwr_ctrl(struct ufs_hba *hba, struct uic_command *cmd)
{
struct completion uic_async_done;
unsigned long flags;
@@ -2309,7 +2309,7 @@ static int ufshcd_get_max_pwr_mode(struct ufs_hba *hba)
return 0;
}
-int ufshcd_change_power_mode(struct ufs_hba *hba,
+static int ufshcd_change_power_mode(struct ufs_hba *hba,
struct ufs_pa_layer_attr *pwr_mode)
{
int ret;
--
1.8.5.2
--
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mtd: ubi: Extend UBI layer debug/messaging capabilities
Hi Tanya, On Sunday 28 September 2014 12:06 PM, Tanya Brokhman wrote: If there is more then one UBI device mounted, there is no way to distinguish between messages from different UBI devices. Add device number to all ubi layer message types. Signed-off-by: Tanya Brokhman tlin...@codeaurora.org --- drivers/mtd/ubi/attach.c | 138 drivers/mtd/ubi/build.c | 130 -- drivers/mtd/ubi/cdev.c| 37 +- drivers/mtd/ubi/debug.c | 9 +-- drivers/mtd/ubi/eba.c | 54 +++--- drivers/mtd/ubi/fastmap.c | 108 drivers/mtd/ubi/io.c | 177 +++--- drivers/mtd/ubi/kapi.c| 6 +- drivers/mtd/ubi/misc.c| 6 +- drivers/mtd/ubi/ubi.h | 13 ++-- drivers/mtd/ubi/vmt.c | 76 +++- drivers/mtd/ubi/vtbl.c| 54 -- drivers/mtd/ubi/wl.c | 87 +++ 13 files changed, 521 insertions(+), 374 deletions(-) Compilation breaks while I try to compile with this patch. May be you need to update remaining ubi layer messages also. Thanks, --Kiran -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ARM: DT: apq8064: Add USB OTG support
On Mon, Sep 29, 2014 at 11:26:41AM +0100, Kiran Padwal wrote:
Hi Srinivas,
Some review are comments inline.
On Monday 29 September 2014 02:45 PM, Srinivas Kandagatla wrote:
This patch adds USB OTG support on USB1 of APQ8064 SOC.
Tested on IFC6410 with ethernet gadget.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 14 +
arch/arm/boot/dts/qcom-apq8064.dtsi| 46
++
2 files changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index d6036b8..f41fb39 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -40,6 +40,11 @@
};
};
+ /* OTG */
+ usb1_phy:phy@1250 {
+ status = ok;
Its canonical value is okay (although in practice anything
other than disabled should work).
That's not quite true, there are other bad values like fail and
fail-sss documented by ePAPR. In Linux, of_device_is_available errs on
the side of caution and checks for either okay or ok, failing
otherwise
Regardless, please use the canonical okay.
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ARM: DT: apq8064: Add USB OTG support
On 29/09/14 11:53, Mark Rutland wrote: Its canonical value is okay (although in practice anything other than disabled should work). That's not quite true, there are other bad values like fail and fail-sss documented by ePAPR. In Linux, of_device_is_available errs on the side of caution and checks for either okay or ok, failing otherwise Regardless, please use the canonical okay. I will fix this in v2. --srini -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mtd: ubi: Extend UBI layer debug/messaging capabilities
Am 29.09.2014 12:50, schrieb Kiran Padwal: Hi Tanya, On Sunday 28 September 2014 12:06 PM, Tanya Brokhman wrote: If there is more then one UBI device mounted, there is no way to distinguish between messages from different UBI devices. Add device number to all ubi layer message types. Signed-off-by: Tanya Brokhman tlin...@codeaurora.org --- drivers/mtd/ubi/attach.c | 138 drivers/mtd/ubi/build.c | 130 -- drivers/mtd/ubi/cdev.c| 37 +- drivers/mtd/ubi/debug.c | 9 +-- drivers/mtd/ubi/eba.c | 54 +++--- drivers/mtd/ubi/fastmap.c | 108 drivers/mtd/ubi/io.c | 177 +++--- drivers/mtd/ubi/kapi.c| 6 +- drivers/mtd/ubi/misc.c| 6 +- drivers/mtd/ubi/ubi.h | 13 ++-- drivers/mtd/ubi/vmt.c | 76 +++- drivers/mtd/ubi/vtbl.c| 54 -- drivers/mtd/ubi/wl.c | 87 +++ 13 files changed, 521 insertions(+), 374 deletions(-) Compilation breaks while I try to compile with this patch. May be you need to update remaining ubi layer messages also. Please always share the errors you face. Maybe you have a different config. Thanks, //richard -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/7] QCOM 8974 and 8084 cpuidle driver
Hi Lina,
Thanks for the patches. Tested these patches on my Dragonboard APQ8074
and with cpuidle tests from Linaro. They all pass.
And the proper names of the cpuidle state (wfi and spc) are also
reflecting in sysfs.
Tested-by: pramod.gu...@smartplayin.com.
Thanks
Pramod
On Saturday 27 September 2014 06:28 AM, Lina Iyer wrote:
Changes since v6:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg11012.html ]
- SPM device nodes merged with existing SAW DT nodes
- SPM register information is handled within the driver
- Clean up from using 'msm' to 'qcom'
- Shorten some enumerations as well
- Review comments from v6 addressed
- New: Support for 8084 SoC
- Not tested. I do not have a board with this SoC, but the SPM
configuration should be identical for WFI and SPC
Changes since v5:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10559.html ]
- Merge spm-devices.c and spm.c into one file and one patch
- Simplify implementation of the driver.
- Update documentation mapping the DT properties with corresponding
SPM register information.
- Removed scm-boot changes for quad core warmboot, its has been pulled in.
Changes since v4:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10327.html ]
- Update to the v8 of ARM generic idle states patches
- Use platform device model for cpuidle-qcom
- Clean up msm-pm.c to remove unnecessary include files and functions
- Update commit text and documentation for all idle states
- Remove scm-boot relocate patch from this series, submitted earlier
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10518.html ]
Changes since v3:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10288.html ]
- Fix CONFIG_QCOM_PM Kconfig as bool
- More clean ups in spm.c and spm-devices.c
- Removed and re-organized data structures to make initialization simple
- Remove export of sequence flush functions
- Updated commit text
- Comments for use of barriers.
- Rebase on top of 3.17-rc1
Changes since v2:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10148.html ]
- Prune all the drivers to support basic WFI and power down cpuidle
functionality. Remove debug code.
- Integrate KConfig changes into the drivers' patches.
- Use Lorenzo's ARM idle-states patches as the basis for reading cpuidle
c-states from DT.
[ http://marc.info/?l=linux-pmm=140794514812383w=2 ]
- Incorporate review comments
- Rebase on top of 3.16
Changes since v1/RFC:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10065.html ]
- Remove hotplug from the patch series. Will submit it separately.
- Fix SPM drivers per the review comments
- Modify patch sequence to compile SPM drivers independent of msm-pm, so as to
allow wfi() calls to use SPM even without SoC interface driver.
8074/8084 like any ARM SoC can do architectural clock gating, that helps save
on power, but not enough of leakage power. Leakage power of the SoC can be
further reduced by turning off power to the core. To aid this, every core (cpu
and L2) is accompanied by a Sub-system Power Manager (SPM), that can be
configured to indicate the low power mode, the core would be put into and the
SPM programs the peripheral h/w accordingly to enter low power and turn off
the
power rail to the core.
The idle invocation hierarchy -
CPUIDLE
|
cpuidle-qcom.c [CPUIdle driver]
|
-- pm.c [SoC Interface layer for QCOM chipsets]
|
-- spm.c [SPM driver]
|
-- scm-boot.c [SCM interface layer]
|
|--
(EL) Secure Monitor Code
|
|
wfi();
|--
(HW) [CPU] {clock gate}
|
- [SPM] {statemachine}
The patchset does the following -
- Introduce the SPM driver to control power to the core
- Add device bindings for 8974 CPU SPM devices
- Add device bindings for 8084 CPU SPM devices
- Introduce the SoC interface layer to configure SPM per the core's idle
state.
- Add CPUIDLE driver for QCOM cpus, using ARM generic idle state definitions.
- Add device bindings for 8974 idle-states - WFI and SPC
- Add device bindings for 8084 idle-states - WFI and SPC
Thanks,
Lina
Lina Iyer (7):
qcom: spm: Add Subsystem Power Manager driver
arm: dts: qcom: Add SPM device bindings for 8974
arm: dts: qcom: Add SPM device bindings for 8084
qcom: pm: Add cpu low power mode functions
qcom: cpuidle: Add cpuidle driver for QCOM cpus
arm: dts: qcom: Add idle states device nodes for 8974
arm: dts: qcom: Add idle
Re: [PATCH] mtd: ubi: Extend UBI layer debug/messaging capabilities
On Monday 29 September 2014 05:31 PM, Richard Weinberger wrote: Am 29.09.2014 12:50, schrieb Kiran Padwal: Hi Tanya, On Sunday 28 September 2014 12:06 PM, Tanya Brokhman wrote: If there is more then one UBI device mounted, there is no way to distinguish between messages from different UBI devices. Add device number to all ubi layer message types. Signed-off-by: Tanya Brokhman tlin...@codeaurora.org --- drivers/mtd/ubi/attach.c | 138 drivers/mtd/ubi/build.c | 130 -- drivers/mtd/ubi/cdev.c| 37 +- drivers/mtd/ubi/debug.c | 9 +-- drivers/mtd/ubi/eba.c | 54 +++--- drivers/mtd/ubi/fastmap.c | 108 drivers/mtd/ubi/io.c | 177 +++--- drivers/mtd/ubi/kapi.c| 6 +- drivers/mtd/ubi/misc.c| 6 +- drivers/mtd/ubi/ubi.h | 13 ++-- drivers/mtd/ubi/vmt.c | 76 +++- drivers/mtd/ubi/vtbl.c| 54 -- drivers/mtd/ubi/wl.c | 87 +++ 13 files changed, 521 insertions(+), 374 deletions(-) Compilation breaks while I try to compile with this patch. May be you need to update remaining ubi layer messages also. Please always share the errors you face. Maybe you have a different config. Sure, I will take care of this next time. Macros have been changed but some instances of older macros still remained, which caused many errors like, drivers/mtd/ubi/build.c: In function ‘ubi_init’: drivers/mtd/ubi/build.c:1322:49: error: expected ‘)’ before ‘err’ ubi_err(block: cannot initialize, error %d, err); ^ Thanks, //richard -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mtd: ubi: Extend UBI layer debug/messaging capabilities
Am 29.09.2014 14:32, schrieb Kiran Padwal: On Monday 29 September 2014 05:31 PM, Richard Weinberger wrote: Am 29.09.2014 12:50, schrieb Kiran Padwal: Hi Tanya, On Sunday 28 September 2014 12:06 PM, Tanya Brokhman wrote: If there is more then one UBI device mounted, there is no way to distinguish between messages from different UBI devices. Add device number to all ubi layer message types. Signed-off-by: Tanya Brokhman tlin...@codeaurora.org --- drivers/mtd/ubi/attach.c | 138 drivers/mtd/ubi/build.c | 130 -- drivers/mtd/ubi/cdev.c| 37 +- drivers/mtd/ubi/debug.c | 9 +-- drivers/mtd/ubi/eba.c | 54 +++--- drivers/mtd/ubi/fastmap.c | 108 drivers/mtd/ubi/io.c | 177 +++--- drivers/mtd/ubi/kapi.c| 6 +- drivers/mtd/ubi/misc.c| 6 +- drivers/mtd/ubi/ubi.h | 13 ++-- drivers/mtd/ubi/vmt.c | 76 +++- drivers/mtd/ubi/vtbl.c| 54 -- drivers/mtd/ubi/wl.c | 87 +++ 13 files changed, 521 insertions(+), 374 deletions(-) Compilation breaks while I try to compile with this patch. May be you need to update remaining ubi layer messages also. Please always share the errors you face. Maybe you have a different config. Sure, I will take care of this next time. Macros have been changed but some instances of older macros still remained, which caused many errors like, drivers/mtd/ubi/build.c: In function ‘ubi_init’: drivers/mtd/ubi/build.c:1322:49: error: expected ‘)’ before ‘err’ ubi_err(block: cannot initialize, error %d, err); Ohh. :( Tanya, did you test your patch? Thanks, //richard -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] thermal: Add QPNP PMIC temperature alarm driver
On Fri, 2014-09-26 at 16:51 +0530, Kiran Padwal wrote:
On Thursday 25 September 2014 07:00 PM, Ivan T. Ivanov wrote:
Add support for the temperature alarm peripheral found inside
Qualcomm plug-and-play (QPNP) PMIC chips. The temperature alarm
peripheral outputs a pulse on an interrupt line whenever the
thermal over temperature stage value changes. Implement an ISR
to manage this interrupt.
snip
+ * This function updates the internal temp value based on the
+ * current thermal stage and threshold as well as the previous stage
+ */
+static int qpnp_tm_update_temp_no_adc(struct qpnp_tm_chip *chip)
+{
+ unsigned int stage;
+ int rc;
+ u8 reg;
+
+ rc = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, reg);
+ if (rc 0)
+ return rc;
+
+ stage = reg STATUS_STAGE_MASK;
During compilation, getting a waring as below,
drivers/thermal/qpnp-temp-alarm.c: In function ‘qpnp_tm_update_temp_no_adc’:
drivers/thermal/qpnp-temp-alarm.c:135:8: warning: ‘reg’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
stage = reg STATUS_STAGE_MASK;
Could you share compiler version and options which you are using.
I am unable to trigger this warning. Looking code I can not
see how this could happen.
+
+ if (stage chip-stage) {
+ /* increasing stage, use lower bound */
+ chip-temp = (stage - 1) * TEMP_STAGE_STEP +
+chip-thresh * TEMP_THRESH_STEP +
+TEMP_STAGE_HYSTERESIS + TEMP_THRESH_MIN;
+ } else if (stage chip-stage) {
+ /* decreasing stage, use upper bound */
+ chip-temp = stage * TEMP_STAGE_STEP +
+chip-thresh * TEMP_THRESH_STEP -
+TEMP_STAGE_HYSTERESIS + TEMP_THRESH_MIN;
+ }
+
+ chip-stage = stage;
+
+ return 0;
+}
+
snip
+
+#define QPNP_TM_PM_OPS (qpnp_tm_pm_ops)
+#else
+#define QPNP_TM_PM_OPS NULL
+#endif
+
+static struct of_device_id qpnp_tm_match_table[] = {
It must be static const struct of_device_id, because all OF functions handle
it as const.
Sure, will fix it.
Thank you,
Ivan
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/7] QCOM 8974 and 8084 cpuidle driver
On Mon, Sep 29 2014 at 06:18 -0600, Pramod Gurav wrote:
Hi Lina,
Thanks for the patches. Tested these patches on my Dragonboard APQ8074
and with cpuidle tests from Linaro. They all pass.
And the proper names of the cpuidle state (wfi and spc) are also
reflecting in sysfs.
Tested-by: pramod.gu...@smartplayin.com.
Thanks.
Thanks
Pramod
On Saturday 27 September 2014 06:28 AM, Lina Iyer wrote:
Changes since v6:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg11012.html ]
- SPM device nodes merged with existing SAW DT nodes
- SPM register information is handled within the driver
- Clean up from using 'msm' to 'qcom'
- Shorten some enumerations as well
- Review comments from v6 addressed
- New: Support for 8084 SoC
- Not tested. I do not have a board with this SoC, but the SPM
configuration should be identical for WFI and SPC
Changes since v5:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10559.html ]
- Merge spm-devices.c and spm.c into one file and one patch
- Simplify implementation of the driver.
- Update documentation mapping the DT properties with corresponding
SPM register information.
- Removed scm-boot changes for quad core warmboot, its has been pulled in.
Changes since v4:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10327.html ]
- Update to the v8 of ARM generic idle states patches
- Use platform device model for cpuidle-qcom
- Clean up msm-pm.c to remove unnecessary include files and functions
- Update commit text and documentation for all idle states
- Remove scm-boot relocate patch from this series, submitted earlier
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10518.html ]
Changes since v3:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10288.html ]
- Fix CONFIG_QCOM_PM Kconfig as bool
- More clean ups in spm.c and spm-devices.c
- Removed and re-organized data structures to make initialization simple
- Remove export of sequence flush functions
- Updated commit text
- Comments for use of barriers.
- Rebase on top of 3.17-rc1
Changes since v2:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10148.html ]
- Prune all the drivers to support basic WFI and power down cpuidle
functionality. Remove debug code.
- Integrate KConfig changes into the drivers' patches.
- Use Lorenzo's ARM idle-states patches as the basis for reading cpuidle
c-states from DT.
[ http://marc.info/?l=linux-pmm=140794514812383w=2 ]
- Incorporate review comments
- Rebase on top of 3.16
Changes since v1/RFC:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10065.html ]
- Remove hotplug from the patch series. Will submit it separately.
- Fix SPM drivers per the review comments
- Modify patch sequence to compile SPM drivers independent of msm-pm, so as to
allow wfi() calls to use SPM even without SoC interface driver.
8074/8084 like any ARM SoC can do architectural clock gating, that helps save
on power, but not enough of leakage power. Leakage power of the SoC can be
further reduced by turning off power to the core. To aid this, every core (cpu
and L2) is accompanied by a Sub-system Power Manager (SPM), that can be
configured to indicate the low power mode, the core would be put into and the
SPM programs the peripheral h/w accordingly to enter low power and turn off the
power rail to the core.
The idle invocation hierarchy -
CPUIDLE
|
cpuidle-qcom.c [CPUIdle driver]
|
-- pm.c [SoC Interface layer for QCOM chipsets]
|
-- spm.c [SPM driver]
|
-- scm-boot.c [SCM interface layer]
|
|--
(EL)Secure Monitor Code
|
|
wfi();
|--
(HW)[CPU] {clock gate}
|
- [SPM] {statemachine}
The patchset does the following -
- Introduce the SPM driver to control power to the core
- Add device bindings for 8974 CPU SPM devices
- Add device bindings for 8084 CPU SPM devices
- Introduce the SoC interface layer to configure SPM per the core's idle state.
- Add CPUIDLE driver for QCOM cpus, using ARM generic idle state definitions.
- Add device bindings for 8974 idle-states - WFI and SPC
- Add device bindings for 8084 idle-states - WFI and SPC
Thanks,
Lina
Lina Iyer (7):
qcom: spm: Add Subsystem Power Manager driver
arm: dts: qcom: Add SPM device bindings for 8974
arm: dts: qcom: Add SPM device bindings for 8084
qcom: pm: Add cpu low power mode functions
qcom: cpuidle: Add cpuidle driver for QCOM cpus
arm: dts: qcom: Add idle states device nodes for 8974
arm: dts: qcom: Add idle
Re: [PATCH v7 5/7] qcom: cpuidle: Add cpuidle driver for QCOM cpus
On Mon, Sep 29 2014 at 04:27 -0600, Pramod Gurav wrote:
Hi Lina
One sections mismatch warning here as well:
WARNING: drivers/cpuidle/built-in.o(.text+0x2740): Section mismatch in
reference from the function qcom_cpuidle_probe() to the (unknown
reference) .init.rodata:(unknown)
The function qcom_cpuidle_probe() references
the (unknown reference) __initconst (unknown).
This is often because qcom_cpuidle_probe lacks a __initconst
annotation or the annotation of (unknown) is wrong.
Thanks, will fix it.
On Saturday 27 September 2014 06:28 AM, Lina Iyer wrote:
Add cpuidle driver interface to allow cpus to go into C-States. Use the
cpuidle DT interface common across ARM architectures to provide the
C-State information to the cpuidle framework.
..
+};
+
+static const struct of_device_id qcom_idle_state_match[] __initconst = {
This is causing it.
+ { .compatible = qcom,idle-state-wfi, .data = qcom_lpm_enter_wfi },
+ { .compatible = qcom,idle-state-spc, .data = qcom_lpm_enter_spc },
+ { },
+};
+
Thanks
Pramod
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 5/7] qcom: cpuidle: Add cpuidle driver for QCOM cpus
Hi Lina, On Sat, Sep 27, 2014 at 01:58:13AM +0100, Lina Iyer wrote: Add cpuidle driver interface to allow cpus to go into C-States. Use the cpuidle DT interface common across ARM architectures to provide the C-State information to the cpuidle framework. Supported modes at this time are clock gating (wfi) and cpu power down (Standalone PC or spc). Signed-off-by: Lina Iyer lina.i...@linaro.org --- .../bindings/arm/msm/qcom,idle-state.txt | 72 + drivers/cpuidle/Kconfig.arm| 7 ++ drivers/cpuidle/Makefile | 1 + drivers/cpuidle/cpuidle-qcom.c | 89 ++ 4 files changed, 169 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt create mode 100644 drivers/cpuidle/cpuidle-qcom.c diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt new file mode 100644 index 000..47095b9 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt @@ -0,0 +1,72 @@ +QCOM Idle States for cpuidle driver + +ARM provides idle-state node to define the cpuidle states, as defined in [1]. +cpuidle-qcom is the cpuidle driver for Qualcomm SoCs and uses these idle +states. Idle states have different enter/exit latency and residency values. +The idle states supported by the QCOM SoC are defined as - + +* WFI +* Retention +* Standalone Power Collapse (Standalone PC or SPC) +* Power Collapse (PC) + +WFI: WFI does a little more in addition to architectural clock gating. ARM This may be misleading. Call it PlatformWFI or something like that, not WFI if that's not what it is. +processors when execute the wfi instruction will gate their internal clocks. +QCOM cpus use this instruction as a trigger for the SPM state machine. Usually +with a cpu entering WFI, the SPM is configured to do clock-gating as well. The +SPM state machine waits for the interrrupt to trigger the core back in to s/interrrupt/interrupt/ +active. When all CPUs in the SoC, clock gate using the ARM wfi instruction, the +second level cache usually can also clock gate sensing no cpu activity. When a +cpu is ready to run, it needs the cache to be active before starting execution. +Allowing the SPM to execute the clock gating statemachine and waiting for s/statemachine/state machine/ You are defining a generic binding for Qualcomm idle states, so it should not be tied to a specific cache level (ie L2 gating), otherwise if the same state shows up in a future system with L3 you are back to square one. Platform WFI or something like that ? You got what I mean. +interrupt on behalf of the processor has a benefit of guaranteeing that the +system state is conducive for the core to resume execution. + +Retention: Retention is a low power state where the core is clockgated and the +memory and the registers associated with the core are retained. The voltage +may be reduced to the minimum value needed to keep the processor registers +active. Retention is triggered when the core executes wfi instruction. The SPM I think that saying ..is triggered when the core executes wfi instruction is not necessary. I am not aware of any other _proper_ way of entering an ARM idle state other than executing wfi and I hope I will never have to to become aware of one. +should be configured to execute the retention sequence and would wait for +interrupt, before restoring the cpu to execution state. Retention may have a +slightly higher latency than WFI. + +Standalone PC: A cpu can power down and warmboot if there is a sufficient time +between now and the next know wake up. SPC mode is used to indicate a core s/know/known/ +entering a power down state without consulting any other cpu or the system +resources. This helps save power only on that core. Like WFI and Retention, the +core executes wfi and the SPM programmed to do SPC would use the cpu control +logic to power down the core's supply and restore it back when woken up by an +interrupt. Applying power and reseting the core causes the core to warmboot s/reseting/resetting/ +back into secure mode which trampolines the control back to the kernel. To +enter a power down state the kernel needs to call into the secure layer which +would then execute the ARM wfi instruction. Failing to do so, would result in a +crash enforced by the warm boot code in the secure layer. On a SoC with +write-back L1 cache, the cache would need to be flushed. +Power Collapse: This state is similiar to the SPC mode, but distinguishes s/similiar/similar/ +itself in the fact that the cpu acknowledges and permits the SoC to enter s/in the fact that/in that/ +deeper sleep modes. In a hierarchical power domain SoC, this means L2 and other +caches can be flushed, system bus, clocks -
Re: [PATCH v7 5/7] qcom: cpuidle: Add cpuidle driver for QCOM cpus
On Mon, Sep 29 2014 at 09:31 -0600, Lorenzo Pieralisi wrote: Hi Lina, On Sat, Sep 27, 2014 at 01:58:13AM +0100, Lina Iyer wrote: +The idle states supported by the QCOM SoC are defined as - + +* WFI +* Retention +* Standalone Power Collapse (Standalone PC or SPC) +* Power Collapse (PC) + +WFI: WFI does a little more in addition to architectural clock gating. ARM This may be misleading. Call it PlatformWFI or something like that, not WFI if that's not what it is. Hmm.. Not elegant. Let me see what I can do. +processors when execute the wfi instruction will gate their internal clocks. +QCOM cpus use this instruction as a trigger for the SPM state machine. Usually +with a cpu entering WFI, the SPM is configured to do clock-gating as well. The +SPM state machine waits for the interrrupt to trigger the core back in to s/interrrupt/interrupt/ +active. When all CPUs in the SoC, clock gate using the ARM wfi instruction, the +second level cache usually can also clock gate sensing no cpu activity. When a +cpu is ready to run, it needs the cache to be active before starting execution. +Allowing the SPM to execute the clock gating statemachine and waiting for s/statemachine/state machine/ You are defining a generic binding for Qualcomm idle states, so it should not be tied to a specific cache level (ie L2 gating), otherwise if the same state shows up in a future system with L3 you are back to square one. Platform WFI or something like that ? You got what I mean. I am not, I am just explaining the difference between Architectural and Platform WFI and how the WFI on the core, can help L2 enter shallower idle states, which is true for L3 as well (provided there is enough time and we are not allowed to do power down states). +interrupt on behalf of the processor has a benefit of guaranteeing that the +system state is conducive for the core to resume execution. + +Retention: Retention is a low power state where the core is clockgated and the +memory and the registers associated with the core are retained. The voltage +may be reduced to the minimum value needed to keep the processor registers +active. Retention is triggered when the core executes wfi instruction. The SPM I think that saying ..is triggered when the core executes wfi instruction is not necessary. I am not aware of any other _proper_ way of entering an ARM idle state other than executing wfi and I hope I will never have to to become aware of one. Hopefully so :) +should be configured to execute the retention sequence and would wait for +interrupt, before restoring the cpu to execution state. Retention may have a +slightly higher latency than WFI. + +Standalone PC: A cpu can power down and warmboot if there is a sufficient time +between now and the next know wake up. SPC mode is used to indicate a core s/know/known/ +entering a power down state without consulting any other cpu or the system +resources. This helps save power only on that core. Like WFI and Retention, the +core executes wfi and the SPM programmed to do SPC would use the cpu control +logic to power down the core's supply and restore it back when woken up by an +interrupt. Applying power and reseting the core causes the core to warmboot s/reseting/resetting/ +back into secure mode which trampolines the control back to the kernel. To +enter a power down state the kernel needs to call into the secure layer which +would then execute the ARM wfi instruction. Failing to do so, would result in a +crash enforced by the warm boot code in the secure layer. On a SoC with +write-back L1 cache, the cache would need to be flushed. +Power Collapse: This state is similiar to the SPC mode, but distinguishes s/similiar/similar/ +itself in the fact that the cpu acknowledges and permits the SoC to enter s/in the fact that/in that/ +deeper sleep modes. In a hierarchical power domain SoC, this means L2 and other +caches can be flushed, system bus, clocks - lowered, and SoC main XO turned off +and voltages reduced, provided all cpus enter this state. In other words, it is +a coupled idle state. Since the span of low power modes possible at this state Careful with the wording here. Coupled idle states are defined in the kernel for systems where the CPUs must enter power down with a specific ordering. I do not think Power Collapse is a coupled state from this perspective, it seems to me more like a cluster state, a state that is entered when all (not necessarily coordinated) CPUs in the cluster enter that state. Feel free to call it a hierarchical state, if it makes sense to you. Okay. I thought I changed it from coupled to cluster.. I will change it to cluster. +is vast, the exit latency and the residency of this low power mode would be +considered high even though at a cpu level, this essentially is cpu power down. +The SPM in this state also may handshake with the Resource power manager +processor in the SoC to indicate a complete subsystem shut
Re: [PATCH v7 5/7] qcom: cpuidle: Add cpuidle driver for QCOM cpus
On Mon, Sep 29, 2014 at 05:16:25PM +0100, Lina Iyer wrote:
[...]
+processors when execute the wfi instruction will gate their internal
clocks.
+QCOM cpus use this instruction as a trigger for the SPM state machine.
Usually
+with a cpu entering WFI, the SPM is configured to do clock-gating as
well. The
+SPM state machine waits for the interrrupt to trigger the core back in to
s/interrrupt/interrupt/
+active. When all CPUs in the SoC, clock gate using the ARM wfi
instruction, the
+second level cache usually can also clock gate sensing no cpu activity.
When a
+cpu is ready to run, it needs the cache to be active before starting
execution.
+Allowing the SPM to execute the clock gating statemachine and waiting for
s/statemachine/state machine/
You are defining a generic binding for Qualcomm idle states, so it should
not be tied to a specific cache level (ie L2 gating), otherwise if the
same state shows up in a future system with L3 you are back to square
one.
Platform WFI or something like that ? You got what I mean.
I am not, I am just explaining the difference between Architectural and
Platform WFI and how the WFI on the core, can help L2 enter shallower
idle states, which is true for L3 as well (provided there is enough time
and we are not allowed to do power down states).
I wanted to say that instead of referring to L2 you can refer to the
computing system as a whole, it is a computing subsystem clock gating.
Instead of referring to L2, refer to cache hierarchy, generically.
It is just a nitpick to make your life easier in the future.
[...]
+static int qcom_cpuidle_probe(struct platform_device *pdev)
+{
+ struct cpuidle_driver *drv = qcom_cpuidle_driver;
+ int ret;
+
+ qcom_idle_enter = (void *)(pdev-dev.platform_data);
Casting a void* to a void* does not seem that useful to me, and that's valid
for other CPUidle drivers too, the cast can be removed unless you explain
to me what it is for.
Sure, I dont need it.
Thanks for your time, Lorenzo.
You are welcome, thanks for you patience in converting the driver to the
new DT API.
Lorenzo
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH resend] arm:extend the reserved memory for initrd to be page aligned
On Fri, 26 Sep 2014 10:40:54 +0800, Wang, Yalin said: I am really confused, I read this web: http://www.arm.linux.org.uk/developer/patches/info.php it said use diff -urN to generate patch like this: diff -Nru linux.orig/lib/string.c linux/lib/string.c but I see other developers use git format-patch to generate patch and submit to the patch system. Git format-patch format can also be accepted by the patch system correctly ? If yes, I think this web should update, Use git format-patch to generate patch is more convenient than use diff -urN 'diff -urN' has the advantage that it will work against a tree extracted from a release tarball, and doesn't have a requirement that you have git installed. Having said that, somebody who has access to the website probably should update it to mention that both methods are acceptable pgpzWNoX3Itxn.pgp Description: PGP signature
[PATCH] i2c: qup: Fix order of runtime pm initialization
The runtime pm calls need to be done before populating the children via the i2c_add_adapter call. If this is not done, a child can run into issues trying to do i2c read/writes due to the pm_runtime_sync failing. Signed-off-by: Andy Gross agr...@codeaurora.org --- drivers/i2c/busses/i2c-qup.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c index 3a4d64e..092d89b 100644 --- a/drivers/i2c/busses/i2c-qup.c +++ b/drivers/i2c/busses/i2c-qup.c @@ -674,16 +674,20 @@ static int qup_i2c_probe(struct platform_device *pdev) qup-adap.dev.of_node = pdev-dev.of_node; strlcpy(qup-adap.name, QUP I2C adapter, sizeof(qup-adap.name)); - ret = i2c_add_adapter(qup-adap); - if (ret) - goto fail; - pm_runtime_set_autosuspend_delay(qup-dev, MSEC_PER_SEC); pm_runtime_use_autosuspend(qup-dev); pm_runtime_set_active(qup-dev); pm_runtime_enable(qup-dev); + + ret = i2c_add_adapter(qup-adap); + if (ret) + goto fail_runtime; + return 0; +fail_runtime: + pm_runtime_disable(qup-dev); + pm_runtime_set_suspended(qup-dev); fail: qup_i2c_disable_clocks(qup); return ret; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] dmaengine: qcom_bam_dma: Generalize BAM register offset calculations
On Mon, Sep 29, 2014 at 10:03:07AM +0530, Archit Taneja wrote: The BAM DMA IP comes in different versions. The register offset layout varies among these versions. The layouts depend on which generation/family of SoCs they belong to. The current SoCs(like 8084, 8074) have a layout where the Top level registers come in the beginning of the address range, followed by pipe and event registers. The BAM revision numbers fall above 1.4.0. The older SoCs (like 8064, 8960) have a layout where the pipe registers come first, and the top level come later. These have BAM revision numbers lesser than 1.4.0. It isn't suitable to have macros provide the register offsets with the layouts changed. Future BAM revisions may have different register layouts too. The register addresses are now calculated by referring a table which contains a base offset and multipliers for pipe/evnt/ee registers. We have a common function bam_addr() which computes addresses for all the registers. When computing address of top level/ee registers, we pass 0 to the pipe argument in addr() since they don't have any multiple instances. Some of the unused register definitions are removed. We can add new registers as we need them. Vinod, These changes replace the patch set I had that implemented support for the v.1.3.0 register set. -- sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: DT: apq8064: add rpm support
On 09/29/14 02:14, Srinivas Kandagatla wrote:
@@ -246,6 +247,24 @@
#reset-cells = 1;
};
+ apcs: syscon@2011000 {
+ compatible = syscon;
+ reg = 0x2011000 0x1000;
+ };
This is actually a clock controller block that hw designers decided was
good place to shove the ipc bits (because there's room!). Can we call it
l2cc: clock-controller@2011000 {
compatible = syscon;
reg = 0x2011000 0x1000;
};
Eventually I'll add the specific krait compatible when we merge krait
clock support:
l2cc: clock-controller@2011000 {
compatible = qcom,kpss-gcc, syscon;
reg = 0x2011000 0x1000;
clock-output-names = acpu_l2_aux;
};
+
+ rpm@108000 {
+ compatible = qcom,rpm-apq8064;
+ reg = 0x108000 0x1000;
+ qcom,ipc = apcs 0x8 2;
There are actually 3 ipc bits. I guess if we ever have to use the other
two we'll extend this binding to have the other bits specified some
other way?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: DT: apq8064: Add SATA controller support.
On 09/29/14 02:15, Srinivas Kandagatla wrote:
@@ -396,6 +407,35 @@
usb-phy = usb4_phy;
};
+ sata_phy0:sata-phy@1b40{
add some spaces here?
+ compatible = qcom,apq8064-sata-phy;
+ reg = 0x1b40 0x200;
+ reg-names = phy_mem;
+ clocks = gcc SATA_PHY_CFG_CLK;
+ clock-names = cfg;
+ #phy-cells = 0;
These two lost the pretty tabs.
+ };
+
+ sata0: sata@2900 {
+ compatible = generic-ahci;
+ reg = 0x2900 0x180;
+ interrupts = 0 209 0;
Sorry I'm nitpicking but it annoys me. Either align it all or don't
align it.
+ clocks = gcc SFAB_SATA_S_H_CLK, gcc SATA_H_CLK,
+ gcc SATA_A_CLK, gcc SATA_RXOOB_CLK,
+ gcc SATA_PMALIVE_CLK;
+
+ clock-names = slave_iface, iface,
+ bus, rxoob,
+ core_pmalive;
+ assigned-clocks = gcc SATA_RXOOB_CLK,
+ gcc SATA_PMALIVE_CLK;
+ assigned-clock-rates = 1, 1;
+
+ phys = sata_phy0;
+ phy-names = sata-phy;
+ target-supply = pm8921_s4;
+ };
+
/* Temporary fixed regulator */
vsdcc_fixed: vsdcc-regulator {
compatible = regulator-fixed;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: qup: Fix order of runtime pm initialization
On Mon, Sep 29, 2014 at 05:00:51PM -0500, Andy Gross wrote: The runtime pm calls need to be done before populating the children via the i2c_add_adapter call. If this is not done, a child can run into issues trying to do i2c read/writes due to the pm_runtime_sync failing. Signed-off-by: Andy Gross agr...@codeaurora.org Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v7 2/7] arm: dts: qcom: Add SPM device bindings for 8974
On 09/26/14 17:58, Lina Iyer wrote:
@@ -144,7 +148,27 @@
};
};
- saw_l2: regulator@f9012000 {
+ saw0: saw@f9089000 {
+ compatible = qcom,msm8974-saw2-v2.1-cpu;
+ reg = 0xf9089000 0x1000;
There is another reg property as part of the binding that should be
specified here.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 5/7] qcom: cpuidle: Add cpuidle driver for QCOM cpus
On 09/26/14 17:58, Lina Iyer wrote:
diff --git a/drivers/cpuidle/cpuidle-qcom.c b/drivers/cpuidle/cpuidle-qcom.c
new file mode 100644
index 000..2fcf79a
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-qcom.c
@@ -0,0 +1,89 @@
+/*
+ * Copyright (c) 2014, Linaro Limited.
+ *
+ * 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/cpu_pm.h
+#include linux/cpuidle.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/platform_device.h
+
+#include soc/qcom/pm.h
+#include dt_idle_states.h
+
+static void (*qcom_idle_enter)(enum pm_sleep_mode);
+
+static int qcom_lpm_enter_wfi(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index)
+{
+ qcom_idle_enter(PM_SLEEP_MODE_WFI);
Why can't we just pass index here? It would be nice to not need to
include soc/qcom/pm.h in this file.
+
+ return index;
+}
+
+static int qcom_lpm_enter_spc(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index)
+{
+ cpu_pm_enter();
+ qcom_idle_enter(PM_SLEEP_MODE_SPC);
+ cpu_pm_exit();
+
+ return index;
+}
+
+static struct cpuidle_driver qcom_cpuidle_driver = {
+ .name = qcom_cpuidle,
+ .owner = THIS_MODULE,
+};
+
+static const struct of_device_id qcom_idle_state_match[] __initconst = {
+ { .compatible = qcom,idle-state-wfi, .data = qcom_lpm_enter_wfi },
+ { .compatible = qcom,idle-state-spc, .data = qcom_lpm_enter_spc },
+ { },
+};
+
+static int qcom_cpuidle_probe(struct platform_device *pdev)
+{
+ struct cpuidle_driver *drv = qcom_cpuidle_driver;
+ int ret;
+
+ qcom_idle_enter = (void *)(pdev-dev.platform_data);
+ if (!qcom_idle_enter)
+ return -EFAULT;
Error code looks a little wrong. -ENODEV?
+
+ /* Probe for other states including platform WFI */
+ ret = dt_init_idle_driver(drv, qcom_idle_state_match, 0);
+ if (ret = 0) {
+ pr_err(%s: No cpuidle state found.\n, __func__);
This would be true if ret == 0, but if it's 0 that isn't true. Drop
the print?
+ return ret;
+ }
+
+ ret = cpuidle_register(drv, NULL);
+ if (ret) {
+ pr_err(%s: failed to register cpuidle driver\n, __func__);
This seems redundant given that cpuidle_register() already prints an
error when it fails.
+ return ret;
+ }
+
+ return 0;
Could just be return cpuidle_register(drv, NULL);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/7] qcom: spm: Add Subsystem Power Manager driver
On 09/26/14 17:58, Lina Iyer wrote:
Based on work by many authors, available at codeaurora.org
SPM is a hardware block that controls the peripheral logic surrounding
the application cores (cpu/l$). When the core executes WFI instruction,
the SPM takes over the putting the core in low power state as
configured. The wake up for the SPM is an interrupt at the GIC, which
then completes the rest of low power mode sequence and brings the core
out of low power mode.
The SPM has a set of control registers that configure the SPMs
individually based on the type of the core and the runtime conditions.
SPM is a finite state machine block to which a sequence is provided and
it interprets the bytes and executes them in sequence. Each low power
mode that the core can enter into is provided to the SPM as a sequence.
Configure the SPM to set the core (cpu or L2) into its low power mode,
the index of the first command in the sequence is set in the SPM_CTL
register. When the core executes ARM wfi instruction, it triggers the
SPM state machine to start executing from that index. The SPM state
machine waits until the interrupt occurs and starts executing the rest
of the sequence until it hits the end of the sequence. The end of the
sequence jumps the core out of its low power mode.
Signed-off-by: Lina Iyer lina.i...@linaro.org
[lina: simplify the driver for initial submission, clean up and update
commit text]
---
.../devicetree/bindings/arm/msm/qcom,saw2.txt | 10 +-
drivers/soc/qcom/Kconfig | 8 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/spm.c | 216
+
include/soc/qcom/spm.h | 35
5 files changed, 264 insertions(+), 6 deletions(-)
create mode 100644 drivers/soc/qcom/spm.c
create mode 100644 include/soc/qcom/spm.h
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
index 1505fb8..9a9cc99 100644
--- a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
@@ -14,10 +14,9 @@ PROPERTIES
Value type: string
Definition: shall contain qcom,saw2. A more specific value should be
one of:
- qcom,saw2-v1
- qcom,saw2-v1.1
- qcom,saw2-v2
- qcom,saw2-v2.1
+ qcom,apq8064-saw2-v1.1-cpu
+ qcom,msm8974-saw2-v2.1-cpu
+ qcom,apq8084-saw2-v2.1-cpu
It's probably not good to remove the old compatibles. Just add more to
the list. Please Cc dt reviewers on dt bindings.
- reg:
Usage: required
@@ -26,10 +25,9 @@ PROPERTIES
the register region. An optional second element specifies
the base address and size of the alias register region.
-
Example:
- regulator@2099000 {
+ saw@2099000 {
saw is not a standard thing. Hence the usage of regulator here. I agree
when it doesn't directly control a regulator then it should be called
something else, power-controller perhaps? I don't really see a need to
change this example though.
compatible = qcom,saw2;
reg = 0x02099000 0x1000, 0x02009000 0x1000;
};
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 7dcd554..cd249c4 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -11,3 +11,11 @@ config QCOM_GSBI
config QCOM_SCM
bool
+
+config QCOM_PM
+ bool Qualcomm Power Management
+ depends on PM ARCH_QCOM
Drop the PM dependency. There isn't any right? Honestly we don't want
this type of option at all. We want an option for each driver introduced.
+ help
+ QCOM Platform specific power driver to manage cores and L2 low power
+ modes. It interface with various system drivers to put the cores in
+ low power modes.
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 70d52ed..20b329f 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o
+obj-$(CONFIG_QCOM_PM)+= spm.o
CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
obj-$(CONFIG_QCOM_SCM) += scm.o scm-boot.o
diff --git a/drivers/soc/qcom/spm.c b/drivers/soc/qcom/spm.c
new file mode 100644
index 000..0ba7949
--- /dev/null
+++ b/drivers/soc/qcom/spm.c
@@ -0,0 +1,216 @@
+/* Copyright (c) 2011-2014, 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
Re: [PATCH v7 4/7] qcom: pm: Add cpu low power mode functions
On 09/26/14 17:58, Lina Iyer wrote:
Based on work by many authors, available at codeaurora.org
Add interface layer to abstract and handle hardware specific
functionality for executing various cpu low power modes in QCOM
chipsets.
QCOM cpus support multiple low power modes. The C-States are defined as -
* WFI (clock gating)
* Retention (clock gating at lower power)
* Standalone Power Collapse (Standalone PC or SPC) - The power to
the cpu is lost and the cpu warmboots.
* Power Collapse (PC) - Same as SPC, but is a cognizant of the fact
that the SoC may do deeper sleep modes.
Signed-off-by: Lina Iyer lina.i...@linaro.org
[lina: simplify the driver for an initial submission, add commit text
description of idle states]
Maintainer tags don't really make sense unless there is another author.
---
drivers/soc/qcom/Makefile | 2 +-
drivers/soc/qcom/pm.c | 109
++
include/soc/qcom/pm.h | 26 +++
3 files changed, 136 insertions(+), 1 deletion(-)
create mode 100644 drivers/soc/qcom/pm.c
create mode 100644 include/soc/qcom/pm.h
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 20b329f..19900ed 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o
-obj-$(CONFIG_QCOM_PM)+= spm.o
+obj-$(CONFIG_QCOM_PM)+= spm.o pm.o
CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
obj-$(CONFIG_QCOM_SCM) += scm.o scm-boot.o
diff --git a/drivers/soc/qcom/pm.c b/drivers/soc/qcom/pm.c
new file mode 100644
index 000..a2f7d72
--- /dev/null
+++ b/drivers/soc/qcom/pm.c
@@ -0,0 +1,109 @@
+/* Copyright (c) 2010-2014, 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/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include asm/proc-fns.h
+#include asm/suspend.h
+
+#include soc/qcom/pm.h
+#include soc/qcom/scm.h
+#include soc/qcom/scm-boot.h
+#include soc/qcom/spm.h
+
+#define SCM_CMD_TERMINATE_PC (0x2)
+#define SCM_FLUSH_FLAG_MASK (0x3)
+#define SCM_L2_ON(0x0)
+#define SCM_L2_OFF (0x1)
+
+
+static int set_up_boot_address(void *entry, int cpu)
+{
+ static int flags[NR_CPUS] = {
+ SCM_FLAG_WARMBOOT_CPU0,
+ SCM_FLAG_WARMBOOT_CPU1,
+ SCM_FLAG_WARMBOOT_CPU2,
+ SCM_FLAG_WARMBOOT_CPU3,
+ };
+ static DEFINE_PER_CPU(void *, last_known_entry);
+
+ if (entry == per_cpu(last_known_entry, cpu))
+ return 0;
+
+ per_cpu(last_known_entry, cpu) = entry;
+ return scm_set_boot_addr(virt_to_phys(entry), flags[cpu]);
+}
+
+static int qcom_pm_collapse(unsigned long int unused)
+{
+ int ret;
+ u32 flag;
+
+ ret = set_up_boot_address(cpu_resume, raw_smp_processor_id());
Preemption better be off here, so why are we using raw_smp_processor_id()?
+ if (ret) {
+ pr_err(Failed to set warm boot address for cpu %d\n,
+ raw_smp_processor_id());
Stuff cpu into a local variable?
+ return ret;
+ }
+
+ flag = SCM_L2_ON SCM_FLUSH_FLAG_MASK;
+ scm_call_atomic1(SCM_SVC_BOOT, SCM_CMD_TERMINATE_PC, flag);
+
+ return 0;
+}
+
+/**
+ * qcom_cpu_pm_enter_sleep(): Enter a low power mode on current cpu
+ *
+ * @mode - sleep mode to enter
+ *
+ * The code should be called with interrupts disabled and on the core on
+ * which the low power mode is to be executed.
+ *
+ */
+static int qcom_cpu_pm_enter_sleep(enum pm_sleep_mode mode)
+{
+ int ret;
+
+ switch (mode) {
+ case PM_SLEEP_MODE_SPC:
+ qcom_spm_set_low_power_mode(SPM_MODE_POWER_COLLAPSE);
Isn't it a one-to-one between PM_SLEEP_MODE_SPC and
SPM_MODE_POWER_COLLAPSE? The enum to enum map seems overly complicated.
+ ret = cpu_suspend(0, qcom_pm_collapse);
+ break;
+ default:
+ case PM_SLEEP_MODE_WFI:
+ qcom_spm_set_low_power_mode(SPM_MODE_CLOCK_GATING);
+ ret = cpu_do_idle();
+ break;
+ }
+
+ local_irq_enable();
+
+ return ret;
+}
+
+static struct platform_device qcom_cpuidle_device = {
+ .name = qcom_cpuidle,
+ .id= -1,
+ .dev.platform_data = qcom_cpu_pm_enter_sleep,
+};
This doesn't need to be static. Use
Re: [PATCH v2 4/4] clk: Use ww_mutexes for clk_prepare_{lock/unlock}
On 09/27/14 19:41, Mike Turquette wrote:
Quoting Stephen Boyd (2014-09-03 18:01:06)
@@ -1069,11 +1305,24 @@ static void __clk_recalc_accuracies(struct clk *clk)
*/
long clk_get_accuracy(struct clk *clk)
{
+ struct ww_acquire_ctx ctx;
+ LIST_HEAD(list);
unsigned long accuracy;
- clk_prepare_lock();
+ if (clk !(clk-flags CLK_GET_ACCURACY_NOCACHE)) {
+ ww_mutex_lock(clk-lock, NULL);
+ } else {
+ ww_acquire_init(ctx, prepare_ww_class);
+ clk_lock_subtree(clk, list, ctx);
+ ww_acquire_done(ctx);
+ }
It looks a little weird to access clk-flags outside of the lock, but
flags is immutable after registration-time, so I guess it is OK. Let me
know if I'm wrong.
Right. We can ww_acquire_init() and ww_mutex_lock() with that context
before checking the flags. In the single lock case it's better to just
grab the mutex though, without the context, to avoid the whole deadlock
detection overhead that we don't care about.
+
rate = __clk_get_rate(clk);
- clk_prepare_unlock();
+
+ if (clk !(clk-flags CLK_GET_RATE_NOCACHE))
+ ww_mutex_unlock(clk-lock);
+ else
+ clk_unlock(list, ctx);
return rate;
}
@@ -1317,9 +1579,11 @@ out:
return ret;
}
-static void clk_calc_subtree(struct clk *clk, unsigned long new_rate,
-struct clk *new_parent, u8 p_index)
+static int clk_calc_subtree(struct clk *clk, unsigned long new_rate,
+struct clk *new_parent, u8 p_index,
+struct list_head *list, struct ww_acquire_ctx
*ctx)
{
+ int ret;
struct clk *child;
clk-new_rate = new_rate;
@@ -1331,27 +1595,43 @@ static void clk_calc_subtree(struct clk *clk,
unsigned long new_rate,
new_parent-new_child = clk;
hlist_for_each_entry(child, clk-children, child_node) {
+ ret = clk_lock_one(child, list, ctx);
+ if (ret == -EDEADLK)
+ return ret;
Why bother with any locking here at all? Why not call clk_lock_subtree
from clk_calc_new_rates? I guess you avoid an extra tree walk?
Yes we save on the tree walk.
+
child-new_rate = clk_recalc(child, new_rate);
- clk_calc_subtree(child, child-new_rate, NULL, 0);
+ ret = clk_calc_subtree(child, child-new_rate, NULL, 0, list,
+ ctx);
+ if (ret)
+ return ret;
}
+
+ return 0;
}
/*
* calculate the new rates returning the topmost clock that has to be
* changed.
*/
-static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate)
+static struct clk *
+clk_calc_new_rates(struct clk *clk, unsigned long rate, struct list_head
*list,
+ struct ww_acquire_ctx *ctx)
{
struct clk *top = clk;
struct clk *old_parent, *parent;
unsigned long best_parent_rate = 0;
unsigned long new_rate;
int p_index = 0;
+ int ret;
/* sanity */
if (IS_ERR_OR_NULL(clk))
return NULL;
+ ret = clk_lock_one(clk, list, ctx);
+ if (ret == -EDEADLK)
+ return ERR_PTR(ret);
It seems to me that we should call clk_parent_lock here instead, since
we access the parent's rate. I know that any concurrent access to the
parent which would change its rate would fail, since we can't lock the
subtree (including *this* lock). But it still seems more correct to lock
the parent to me. Let me know what you think.
Blocking the other user of the parent is bad. In our CPU case we have XO
- PLLn - CPUn for each CPU. So if we want to change the frequency of
CPU0 we change the frequency of PLL0. If we were to always lock the
parent, in this case XO, then we wouldn't gain anything because the two
CPUs trying to change rates independently would both be trying to
acquire the XO clock's lock, thus synchronizing the two things we're
trying to parallelize.
It might also help the collision case fail faster since you will fail
trying to grab the parent lock instead of grabbing the parent lock, then
failing to lock the subtree.
I don't follow this part. Hopefully it doesn't matter though.
Though in all honestly, I haven't finished thinking it through. The
wait/wound algorithm opens up a lot of possibilities around very
aggressive locking strategies to prevent contention. For example if we
call clk_parent_lock it will lock the subtree starting from the parent,
thus holding potentially a LOT more child locks, which only need to be
updated during the recalc rate phase. We could avoid holding those
children until the moment that we need to lock them... I'll think about
it some more.
Oh wait, no we couldn't. We have to take all of our locks
[RFC 7/7] regulator: qcom-smd-rpm: Regulator driver for the Qualcomm RPM
Driver for regulators exposed by the Resource Power Manager (RPM) found
in Qualcomm 8974 based devices.
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
According to the datasheet for the PMIC the regulators are indeed programmed in
steps, but the steps seems to vary between different regulators and the details
are hidden by the RPM that exposes contiguous voltage ranges.
Either we run with this, add a few more compatibles to encode the steps or have
the step coming from devicetree. I prefer the current implementation as that is
the cleanest of these.
drivers/regulator/Kconfig | 12 ++
drivers/regulator/Makefile |1 +
drivers/regulator/qcom_smd-regulator.c | 229
3 files changed, 242 insertions(+)
create mode 100644 drivers/regulator/qcom_smd-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 0e59754..ad01acf 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -461,6 +461,18 @@ config REGULATOR_QCOM_RPM
Qualcomm RPM as a module. The module will be named
qcom_rpm-regulator.
+config REGULATOR_QCOM_SMD_RPM
+ tristate Qualcomm SMD based RPM regulator driver
+ depends on MFD_QCOM_SMD_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
+ 8974 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_smd-regulator.
+
config REGULATOR_RC5T583
tristate RICOH RC5T583 Power regulators
depends on MFD_RC5T583
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 9c50dc6..b022270 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -56,6 +56,7 @@ 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_QCOM_SMD_RPM) += qcom_smd-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_smd-regulator.c
b/drivers/regulator/qcom_smd-regulator.c
new file mode 100644
index 000..510cb44
--- /dev/null
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -0,0 +1,229 @@
+/*
+ * 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/of.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/regulator/of_regulator.h
+#include linux/mfd/qcom-smd-rpm.h
+#include dt-bindings/mfd/qcom-rpm.h
+
+struct qcom_rpm_reg {
+ struct qcom_smd_rpm *rpm;
+ unsigned resource;
+
+ struct regulator_desc desc;
+
+ int is_enabled;
+ int uV;
+};
+
+struct rpm_regulator_req {
+ u32 key;
+ u32 nbytes;
+ u32 value;
+};
+
+#define RPM_KEY_SWEN 0x6e657773 /* swen */
+#define RPM_KEY_UV 0x7675 /* uv */
+#define RPM_KEY_MV 0x616d /* ma */
+
+static int rpm_reg_enable(struct regulator_dev *rdev)
+{
+ struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev);
+ struct rpm_regulator_req req;
+ int ret;
+
+ req.key = RPM_KEY_SWEN;
+ req.nbytes = sizeof(u32);
+ req.value = 1;
+
+ ret = qcom_rpm_smd_write(vreg-rpm, vreg-resource, req, sizeof(req));
+ if (!ret)
+ vreg-is_enabled = 1;
+
+ 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 int rpm_reg_disable(struct regulator_dev *rdev)
+{
+ struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev);
+ struct rpm_regulator_req req;
+ int ret;
+
+ req.key = RPM_KEY_SWEN;
+ req.nbytes = sizeof(u32);
+ req.value = 0;
+
+ ret = qcom_rpm_smd_write(vreg-rpm, vreg-resource, req, sizeof(req));
+ if (!ret)
+ vreg-is_enabled = 0;
+
+ return ret;
+}
+
+static int rpm_reg_get_voltage(struct regulator_dev *rdev)
+{
+
[RFC 6/7] mfd: qcom-smd-rpm: Driver for the Qualcomm RPM over SMD
Driver for the Resource Power Manager (RPM) found in Qualcomm 8974 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.anders...@sonymobile.com
---
Note that the qcom_rpm_smd_write is equivalent of qcom_rpm_write and there is a
possibility of re-using at least the clock implementation on top of this. This
would however require some logic for calling the right implementation so I have
not done it at this time to keep things as clean as possible.
An idea for improvement is that in qcom_rpm_smd_write we put the ack_status and
completion on the stack and register this with idr using the message id, upon
receiving the interrupt we would find the right client and complete this.
Allowing for multiple requests to be in flight at any given time.
I did not implement this because I haven't done any measurements on what kind
of improvements this could give and it would be a clean iteration ontop of
this.
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile |1 +
drivers/mfd/qcom-smd-rpm.c | 299 ++
include/linux/mfd/qcom-smd-rpm.h |9 ++
4 files changed, 323 insertions(+)
create mode 100644 drivers/mfd/qcom-smd-rpm.c
create mode 100644 include/linux/mfd/qcom-smd-rpm.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6743e88..c62c7f5 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -553,6 +553,20 @@ config MFD_QCOM_RPM
Say M here if you want to include support for the Qualcomm RPM as a
module. This will build a module called qcom_rpm.
+config MFD_QCOM_SMD_RPM
+ tristate Qualcomm Resource Power Manager (RPM) over SMD
+ depends on QCOM_SMD OF
+ help
+ If you say yes to this option, support will be included for the
+ Resource Power Manager system found in the Qualcomm 8974 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-smd-rpm.
+
config MFD_RDC321X
tristate RDC R-321x southbridge
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 3f2fc89..e19ab12 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -154,6 +154,7 @@ obj-$(CONFIG_MFD_CS5535)+= cs5535-mfd.o
obj-$(CONFIG_MFD_OMAP_USB_HOST)+= omap-usb-host.o omap-usb-tll.o
obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o ssbi.o
obj-$(CONFIG_MFD_QCOM_RPM) += qcom_rpm.o
+obj-$(CONFIG_MFD_QCOM_SMD_RPM) += qcom-smd-rpm.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
obj-$(CONFIG_MFD_TPS65090) += tps65090.o
obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
diff --git a/drivers/mfd/qcom-smd-rpm.c b/drivers/mfd/qcom-smd-rpm.c
new file mode 100644
index 000..3f77f87
--- /dev/null
+++ b/drivers/mfd/qcom-smd-rpm.c
@@ -0,0 +1,299 @@
+/*
+ * 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_platform.h
+#include linux/io.h
+#include linux/interrupt.h
+
+#include linux/soc/qcom/qcom_smd.h
+#include linux/mfd/qcom-smd-rpm.h
+
+#include dt-bindings/mfd/qcom-rpm.h
+
+#define RPM_REQUEST_TIMEOUT (5 * HZ)
+
+struct qcom_rpm_resource {
+ u32 resource_type;
+ u32 resource_id;
+};
+
+struct qcom_rpm_data {
+ const struct qcom_rpm_resource *resource_table;
+ unsigned nresources;
+};
+
+struct qcom_smd_rpm {
+ struct device *dev;
+ struct qcom_smd_channel *rpm_channel;
+
+ struct completion ack;
+ struct mutex lock;
+ int ack_status;
+
+ const struct qcom_rpm_data *data;
+};
+
+struct qcom_rpm_header {
+ u32 service_type;
+ u32 length;
+};
+
+struct qcom_rpm_request {
+ u32 msg_id;
+ u32 flags;
+ u32 resource_type;
+ u32 resource_id;
+ u32 data_len;
+};
+
+struct qcom_rpm_message {
+ u32 msg_type;
+ u32 length;
+ union {
+ u32 msg_id;
+ u8 message[0];
+ };
+};
+
+#define RPM_SERVICE_TYPE_REQUEST 0x00716572 /* req\0 */
+
+#define RPM_MSG_TYPE_ERR 0x00727265 /* err\0 */
+#define
[RFC 4/7] soc: qcom: Add Shared Memory Manager driver
The Shared Memory Manager driver implements an interface for allocating
and accessing items in the memory area shared among all of the
processors in a Qualcomm platform.
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
In later platforms this is extended to support secure smem, I do
unfortunately not have any devices that I could test this with so I have only
implemented the insecure version for now.
I was thinking about implementing an of_xlate as this would make sense for many
things. It is however not feasible for SMD, that would require us to list 257
items.
It would make sense to enhance this with a method of keeping track of currently
consumed items, both to take care of mutual exclusion between consumers as
well as knowing when it's safe to remove the device and/or unload the driver.
I did consider exposing the items as regmaps, but for many of the items the
regmap context is consuming far more space then the actual data. And we would
end up creating 3-400 regmap contexts in a normal system.
Also note that the hwspinlock framework does not yet support devicetree based
retrieval of spinlock handles, so that part needs to be changed.
drivers/soc/qcom/Kconfig |8 +
drivers/soc/qcom/Makefile |1 +
drivers/soc/qcom/qcom_smem.c | 328
include/linux/soc/qcom/qcom_smem.h | 14 ++
4 files changed, 351 insertions(+)
create mode 100644 drivers/soc/qcom/qcom_smem.c
create mode 100644 include/linux/soc/qcom/qcom_smem.h
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 7bd2c94..9e6bc56 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -9,3 +9,11 @@ config QCOM_GSBI
functions for connecting the underlying serial UART, SPI, and I2C
devices to the output pins.
+config QCOM_SMEM
+ tristate Qualcomm Shared Memory Interface
+ depends on ARCH_QCOM
+ help
+ Say y here to enable support for the Qualcomm Shared Memory Manager.
+ The driver provides an interface to items in a heap shared among all
+ processors in a Qualcomm platform and is used for exchanging
+ information as well as a fifo based communication mechanism (SMD).
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 4389012..b1f7b18 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
+obj-$(CONFIG_QCOM_SMEM) += qcom_smem.o
diff --git a/drivers/soc/qcom/qcom_smem.c b/drivers/soc/qcom/qcom_smem.c
new file mode 100644
index 000..9766c86
--- /dev/null
+++ b/drivers/soc/qcom/qcom_smem.c
@@ -0,0 +1,328 @@
+/*
+ * 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/io.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/hwspinlock.h
+#include linux/soc/qcom/qcom_smem.h
+
+#define AUX_BASE_MASK 0xfffc
+#define HWSPINLOCK_TIMEOUT 1000
+#define SMEM_MAX_ITEMS 512
+
+/**
+ * struct smem_proc_comm - proc_comm communication struct (legacy)
+ * @command: current command to be executed
+ * @status: status of the currently requested command
+ * @params: parameters to the command
+ */
+struct smem_proc_comm {
+ u32 command;
+ u32 status;
+ u32 params[2];
+};
+
+/**
+ * struct smem_entry - entry to reference smem items on the heap
+ * @allocated: boolean to indicate if this entry is used
+ * @offset:offset to the allocated space
+ * @size: size of the allocated space, 8 byte aligned
+ * @aux_base: base address for the memory region used by this unit, or 0 for
+ * the default region. bits 0,1 are reserved
+ */
+struct smem_entry {
+ u32 allocated;
+ u32 offset;
+ u32 size;
+ u32 aux_base; /* bits 1:0 reserved */
+};
+
+/**
+ * struct smem_header - header found in beginning of primary smem region
+ * @proc_comm: proc_comm communication interface (legacy)
+ * @version: array of versions for the various subsystems
+ * @smem_initialized: boolean to indicate that smem is initialized
+ * @free_offset: index of the first unallocated byte in smem
+ * @available: number of bytes available for allocation
+ * @unused:reserved field
+ * toc:array of references to smem entries
+ */
[RFC 3/7] mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding
Add binding documentation for the Qualcomm Resource Power Manager (RPM)
using shared memory (Qualcomm SMD) as transport mechanism. This is found
in 8974 and newer based devices.
The binding currently describes the rpm itself and the regulator
subnodes.
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
Note that this patch extends the rpm dt-bindings header from [1].
[1] https://lkml.org/lkml/2014/9/22/733
.../devicetree/bindings/mfd/qcom-rpm-smd.txt | 122
include/dt-bindings/mfd/qcom-rpm.h | 36 ++
2 files changed, 158 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
new file mode 100644
index 000..a846101
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
@@ -0,0 +1,122 @@
+Qualcomm Resource Power Manager (RPM) over SMD
+
+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-msm8974
+
+- qcom,smd-channels:
+ Usage: required
+ Value type: stringlist
+ Definition: Shared Memory Channel used for communication with the RPM
+
+- #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-pm8841-smps
+ qcom,rpm-pm8941-smps
+
+
+- reg:
+ Usage: required
+ Value type: u32
+ Definition: resource as defined in dt-bindings/mfd/qcom-rpm.h
+ must be one of:
+ QCOM_RPM_PM8841_SMPS1 - QCOM_RPM_PM8841_SMPS4,
+ QCOM_RPM_PM8941_SMPS1 - QCOM_RPM_PM8941_SMPS3
+
+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-pm8941-ldo
+
+- reg:
+ Usage: required
+ Value type: u32
+ Definition: resource as defined in dt-bindings/mfd/qcom-rpm.h
+ must be one of:
+ QCOM_RPM_PM8941_LDO1 - QCOM_RPM_PM8941_LDO24
+
+Standard regulator bindings are used inside switch low-dropout 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-pm8941-switch
+
+- reg:
+ Usage: required
+ Value type: u32
+ Definition: resource as defined in dt-bindings/mfd/qcom/qcom-rpm.h
+ must be one of:
+ QCOM_RPM_PM8941_LVS1 - QCOM_RPM_PM8941_LVS3,
+ QCOM_RPM_PM8941_MVS1 - QCOM_RPM_PM8941_MVS2
+
+Standard regulator bindings are used inside switch regulator subnodes. Check
+Documentation/devicetree/bindings/regulator/regulator.txt for more details.
+
+= EXAMPLE
+
+ #include dt-bindings/mfd/qcom-rpm.h
+
+ rpm@108000 {
+ compatible = qcom,rpm-msm8960;
+ qcom,smd-channels = rpm_requests;
+
+ #address-cells = 1;
+ #size-cells = 0;
+
+ pm8941_s1: regulator-s1 {
+ compatible = qcom,rpm-pm8941-smps;
+ reg = QCOM_RPM_PM8941_SMPS1;
+
+ regulator-min-microvolt = 130;
+ regulator-max-microvolt = 130;
+ };
+
+ pm8941_l3: pm8941-l3 {
+ compatible = qcom,rpm-pm8941-ldo;
+ reg = QCOM_RPM_PM8941_LDO3;
+
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ };
+
+ };
+
diff --git a/include/dt-bindings/mfd/qcom-rpm.h
b/include/dt-bindings/mfd/qcom-rpm.h
index 388a6f3..a5c473e 100644
--- a/include/dt-bindings/mfd/qcom-rpm.h
+++ b/include/dt-bindings/mfd/qcom-rpm.h
@@ -141,6 +141,42 @@
#define QCOM_RPM_SYS_FABRIC_MODE 131
#define QCOM_RPM_USB_OTG_SWITCH132
#define QCOM_RPM_VDDMIN_GPIO
[RFC 2/7] soc: qcom: Add device tree binding for SMD
Add device tree binding documentation for the Qualcomm Shared Memory
Device.
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
I was looking at having one smd node per remote processor - e.g flatten the
first and second level. As all the channels, for all the remote processors are
allocated from the same pool this does however not feel very natural.
.../devicetree/bindings/soc/qcom/qcom,smd.txt | 82
1 file changed, 82 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
new file mode 100644
index 000..c56e4fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
@@ -0,0 +1,82 @@
+Qualcomm Shared Memory Driver (SMD) binding
+
+This binding describes the Qualcomm Shared Memory Driver, a fifo based
+communication channel for sending data between the various subsystems in
+Qualcomm platforms.
+
+- compatible:
+ Usage: required
+ Value type: stringlist
+ Definition: must be qcom,smd
+
+- qcom,smem:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: reference to a smem node managing the shared memory items
+ used for smd
+
+= EDGES
+
+Each subnode of the SMD node represents a remote subsystem, i.e. a remote
+processor of some sort - in SMD language called an edge. The name of the
+edges are not important.
+
+- interrupts:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: should specify the IRQ used by the remote processor to
+ signal this processor about communication related updates
+
+- qcom,ipc:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: three entries specifying the outgoing ipc bit used for
+ signaling the remote processor:
+ - phandle to a syscon node representing the apcs registers
+ - u32 representing offset to the register within the syscon
+ - u32 representing the ipc bit within the register
+
+- qcom,smd-edge:
+ Usage: required
+ Value type: u32
+ Definition: an identifier representing the remote processor
+
+= SMD DEVICES
+
+In turn, subnodes of the edges represent devices tied to SMD channels on that
+edge. The names of the devices are not important. The properties of these
+nodes are defined by the individual bindings for the SMD devices - but must
+contain the following property:
+
+- qcom,smd-channels:
+ Usage: required
+ Value type: stringlist
+ Definition: a list of channels tied to this device, used for matching
+ the device to channels
+
+= EXAMPLE
+
+The following example represents a smd node, with one edge representing the
+rpm subsystem. For the rpm subsystem we have a device tied to the
+rpm_request channel.
+
+smd {
+compatible = qcom,smd;
+qcom,smem = smem;
+
+rpm {
+interrupts = 0 168 1;
+qcom,ipc = apcs 8 0;
+qcom,smd-edge = 15;
+
+rpm_requests {
+compatible = qcom,rpm-msm8974;
+qcom,smd-channels = rpm_requests;
+
+#address-cells = 1;
+#size-cells = 0;
+
+ ...
+ };
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/7] Qualcomm SMEM, SMD, RPM and regulators
All Qualcomm platforms implements a shared heap among the processors in the SoC, used for sharing data with other parts of the system. One consumer of items from this heap is the Shared Memory Driver, a ring buffer based point-to-point communication mechanism used to send either stream or packet based data to remote processors. Starting with 8x74 this system is used to talk to the Resource Power Manager (RPM), a power efficient coprocessor with responsibility of aggregate votes from the various systems in the SoC related to regulators, clocks and bus frequencies. The PMIC regulators and root clocks in these platforms are only accessible via the RPM, so to get access to these we need the full chain of smem, smd, rpm and a regulator driver implemented. And that is exactly what this series provides. A key outstanding question is where in the tree we should put the implementation, for now I dropped them in drivers/soc/qcom but that's only because I don't know where to put it otherwise. I have not found any equivalent of the SMEM driver, SMD resembles mailbox and rpmsg - but comments in that patch on why it's neither. RPM is a mfd and regulator is a regulator :) Part from the rpm regulators I've tested this by hacking up a firmware loader and making some adoptions to the wcn36xx WiFi driver and I can indeed communicate with this system as well. Missing for that part is the coupling with remoteproc to reset smd channels when a remote system goes down. But that is indeed a separate set of patches. Bjorn Andersson (7): soc: qcom: Add device tree binding for SMEM soc: qcom: Add device tree binding for SMD mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding soc: qcom: Add Shared Memory Manager driver soc: qcom: Add Shared Memory Driver mfd: qcom-smd-rpm: Driver for the Qualcomm RPM over SMD regulator: qcom-smd-rpm: Regulator driver for the Qualcomm RPM .../devicetree/bindings/mfd/qcom-rpm-smd.txt | 122 +++ .../devicetree/bindings/soc/qcom/qcom,smd.txt | 82 ++ .../devicetree/bindings/soc/qcom/qcom,smem.txt | 34 + drivers/mfd/Kconfig| 14 + drivers/mfd/Makefile |1 + drivers/mfd/qcom-smd-rpm.c | 299 ++ drivers/regulator/Kconfig | 12 + drivers/regulator/Makefile |1 + drivers/regulator/qcom_smd-regulator.c | 229 + drivers/soc/qcom/Kconfig | 16 + drivers/soc/qcom/Makefile |2 + drivers/soc/qcom/qcom_smd.c| 1043 drivers/soc/qcom/qcom_smem.c | 328 ++ include/dt-bindings/mfd/qcom-rpm.h | 36 + include/linux/mfd/qcom-smd-rpm.h |9 + include/linux/soc/qcom/qcom_smd.h | 47 + include/linux/soc/qcom/qcom_smem.h | 14 + 17 files changed, 2289 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt create mode 100644 drivers/mfd/qcom-smd-rpm.c create mode 100644 drivers/regulator/qcom_smd-regulator.c create mode 100644 drivers/soc/qcom/qcom_smd.c create mode 100644 drivers/soc/qcom/qcom_smem.c create mode 100644 include/linux/mfd/qcom-smd-rpm.h create mode 100644 include/linux/soc/qcom/qcom_smd.h create mode 100644 include/linux/soc/qcom/qcom_smem.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/7] soc: qcom: Add device tree binding for SMEM
Add device tree binding documentation for the Qualcom Shared Memory
manager.
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
Exposed by this node is a set of items of different sizes. For many things a
standard of_xlate method of referencing the individual nodes would be
preferable, so a #something-cells would make sense. We do however also needs
access to these items without explicitly stating the references in devicetree
(e.g. SMD references 257 of these). I haven't found any good example of how to
implement this, so suggestions are welcome.
Note that the hwspinlock reference is not yet supported in the mainline, but
this will likely need a few iterations so I wanted to get this out.
.../devicetree/bindings/soc/qcom/qcom,smem.txt | 34
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
new file mode 100644
index 000..ddd58c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
@@ -0,0 +1,34 @@
+Qualcomm Shared Memory binding
+
+This binding describes the Qualcomm Shared Memory, used to share data between
+various subsystems and OSes in Qualcomm platforms.
+
+- compatible:
+ Usage: required
+ Value type: stringlist
+ Definition: must be:
+ qcom,smem
+
+- reg:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: base address and size pair for each area representing the
+ shared memory. The first pair will must represent the main
+ area, where the shared memory header and table-of-content
+ can be found.
+
+- hwspinlocks:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: reference to a hwspinlock used to protect allocations from
+ the shared memory
+
+= EXAMPLE
+
+smem: smem@fa0 {
+compatible = qcom,smem;
+reg = 0x0fa0 0x20,
+ 0xfc428000 0x4000;
+
+hwspinlocks = tcsr_mutex 3;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: qup: Fix order of runtime pm initialization
On Mon 29 Sep 15:00 PDT 2014, Andy Gross wrote: The runtime pm calls need to be done before populating the children via the i2c_add_adapter call. If this is not done, a child can run into issues trying to do i2c read/writes due to the pm_runtime_sync failing. May I ask in what case this would fail? I thought we tested this as we found the faulty error check after calling pm_runtime_get_sync(). Nontheless, Acked-by: Bjorn Andersson bjorn.anders...@sonymobile.com Regards, Bjorn Signed-off-by: Andy Gross agr...@codeaurora.org --- drivers/i2c/busses/i2c-qup.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c index 3a4d64e..092d89b 100644 --- a/drivers/i2c/busses/i2c-qup.c +++ b/drivers/i2c/busses/i2c-qup.c @@ -674,16 +674,20 @@ static int qup_i2c_probe(struct platform_device *pdev) qup-adap.dev.of_node = pdev-dev.of_node; strlcpy(qup-adap.name, QUP I2C adapter, sizeof(qup-adap.name)); - ret = i2c_add_adapter(qup-adap); - if (ret) - goto fail; - pm_runtime_set_autosuspend_delay(qup-dev, MSEC_PER_SEC); pm_runtime_use_autosuspend(qup-dev); pm_runtime_set_active(qup-dev); pm_runtime_enable(qup-dev); + + ret = i2c_add_adapter(qup-adap); + if (ret) + goto fail_runtime; + return 0; +fail_runtime: + pm_runtime_disable(qup-dev); + pm_runtime_set_suspended(qup-dev); fail: qup_i2c_disable_clocks(qup); return ret; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] thermal: Add QPNP PMIC temperature alarm driver
On Monday 29 September 2014 07:24 PM, Ivan T. Ivanov wrote:
On Fri, 2014-09-26 at 16:51 +0530, Kiran Padwal wrote:
On Thursday 25 September 2014 07:00 PM, Ivan T. Ivanov wrote:
Add support for the temperature alarm peripheral found inside
Qualcomm plug-and-play (QPNP) PMIC chips. The temperature alarm
peripheral outputs a pulse on an interrupt line whenever the
thermal over temperature stage value changes. Implement an ISR
to manage this interrupt.
snip
+ * This function updates the internal temp value based on the
+ * current thermal stage and threshold as well as the previous stage
+ */
+static int qpnp_tm_update_temp_no_adc(struct qpnp_tm_chip *chip)
+{
+ unsigned int stage;
+ int rc;
+ u8 reg;
+
+ rc = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, reg);
+ if (rc 0)
+ return rc;
+
+ stage = reg STATUS_STAGE_MASK;
During compilation, getting a waring as below,
drivers/thermal/qpnp-temp-alarm.c: In function ‘qpnp_tm_update_temp_no_adc’:
drivers/thermal/qpnp-temp-alarm.c:135:8: warning: ‘reg’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
stage = reg STATUS_STAGE_MASK;
Could you share compiler version and options which you are using.
I am unable to trigger this warning. Looking code I can not
see how this could happen.
I have Linaro cross tool chain with version-4.8.3 and I am simply doing make
zImage without any option.
Thanks,
--Kiran
+
+ if (stage chip-stage) {
+ /* increasing stage, use lower bound */
+ chip-temp = (stage - 1) * TEMP_STAGE_STEP +
+chip-thresh * TEMP_THRESH_STEP +
+TEMP_STAGE_HYSTERESIS + TEMP_THRESH_MIN;
+ } else if (stage chip-stage) {
+ /* decreasing stage, use upper bound */
+ chip-temp = stage * TEMP_STAGE_STEP +
+chip-thresh * TEMP_THRESH_STEP -
+TEMP_STAGE_HYSTERESIS + TEMP_THRESH_MIN;
+ }
+
+ chip-stage = stage;
+
+ return 0;
+}
+
snip
+
+#define QPNP_TM_PM_OPS (qpnp_tm_pm_ops)
+#else
+#define QPNP_TM_PM_OPS NULL
+#endif
+
+static struct of_device_id qpnp_tm_match_table[] = {
It must be static const struct of_device_id, because all OF functions handle
it as const.
Sure, will fix it.
Thank you,
Ivan
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] hwspinlock: qcom: Add support for Qualcomm HW Mutex block
From: Kumar Gala ga...@codeaurora.org
Add driver for Qualcomm Hardware Mutex block that exists on newer
Qualcomm SoCs.
Cc: Jeffrey Hugo jh...@codeaurora.org
Cc: Eric Holmberg eholm...@codeaurora.org
Cc: Courtney Cavin courtney.ca...@sonymobile.com
Signed-off-by: Kumar Gala ga...@codeaurora.org
[bjorn: added pm_runtime calls, from Courtney,
added sfpb-mutex compatible,
updated DT binding documentation formatting,
replaced msm prefix with qcom,
cleaned up includes]
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
We need this driver to add support for the shared memory manager, so I'm
reviving Kumars patch from a year ago, with some additional sprinkles on top.
Changes since v3:
- Reverted back to getting stride from of_match, per Kumars request
Changes since v2:
- MODULE_DEVICE_TABLE
- Changed prefix to qcom
- Cleaned up includes
- Rely on reg and num-locks to figure out stride, instead of of_match data
Changes since v1:
- Added the pm_runtime calls needed to be able to boot a kernel with
pm_runtime and this driver, patch from Courtney.
- Added sfpb-mutex compatible, for re-use of the driver in family A platforms.
- Updated formatting of DT binding documentation, while adding the extra
compatible.
- Dropped Stephen Boyds Reviewed-by due to these changes.
.../devicetree/bindings/hwlock/qcom-hwspinlock.txt | 35 +
drivers/hwspinlock/Kconfig | 11 ++
drivers/hwspinlock/Makefile|1 +
drivers/hwspinlock/qcom_hwspinlock.c | 151
4 files changed, 198 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
create mode 100644 drivers/hwspinlock/qcom_hwspinlock.c
diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
new file mode 100644
index 000..27c7c80
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
@@ -0,0 +1,35 @@
+Qualcomm Hardware Mutex Block:
+
+The hardware block provides mutexes utilized between different processors
+on the SoC as part of the communication protocol used by these processors.
+
+- compatible:
+ Usage: required
+ Value type: string
+ Definition: must be one of:
+ qcom,sfpb-mutex,
+ qcom,tcsr-mutex
+
+- reg:
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: base address and size of the mutex registers
+
+- reg-names:
+ Usage: required
+ Value type: string
+ Definition: must be mutex-base
+
+- qcom,num-locks:
+ Usage: required
+ Value type: u32
+ Definition: the number of locks/mutex available in this block
+
+Example:
+
+ hwlock@fd484000 {
+ compatible = qcom,tcsr-mutex;
+ reg = 0xfd484000 0x1000;
+ reg-names = mutex-base;
+ qcom,num-locks = 32;
+ };
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 3612cb5..af4c7e6 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -8,6 +8,17 @@ config HWSPINLOCK
menu Hardware Spinlock drivers
+config HWSPINLOCK_QCOM
+ tristate Qualcomm Hardware Spinlock device
+ depends on ARCH_QCOM
+ select HWSPINLOCK
+ help
+ Say y here to support the Qualcomm Hardware Mutex functionality, which
+ provides a synchronisation mechanism for the various processors on
+ the SoC.
+
+ If unsure, say N.
+
config HWSPINLOCK_OMAP
tristate OMAP Hardware Spinlock device
depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX ||
SOC_AM43XX
diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
index 93eb64b..f3bff48 100644
--- a/drivers/hwspinlock/Makefile
+++ b/drivers/hwspinlock/Makefile
@@ -3,5 +3,6 @@
#
obj-$(CONFIG_HWSPINLOCK) += hwspinlock_core.o
+obj-$(CONFIG_HWSPINLOCK_QCOM) += qcom_hwspinlock.o
obj-$(CONFIG_HWSPINLOCK_OMAP) += omap_hwspinlock.o
obj-$(CONFIG_HSEM_U8500) += u8500_hsem.o
diff --git a/drivers/hwspinlock/qcom_hwspinlock.c
b/drivers/hwspinlock/qcom_hwspinlock.c
new file mode 100644
index 000..d1b3328
--- /dev/null
+++ b/drivers/hwspinlock/qcom_hwspinlock.c
@@ -0,0 +1,151 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014, Sony Mobile Communications AB
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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
Re: [PATCH 1/4] ARM: DT: apq8064: add rpm support
On Mon 29 Sep 15:17 PDT 2014, Stephen Boyd wrote:
On 09/29/14 02:14, Srinivas Kandagatla wrote:
@@ -246,6 +247,24 @@
#reset-cells = 1;
};
+ apcs: syscon@2011000 {
+ compatible = syscon;
+ reg = 0x2011000 0x1000;
+ };
This is actually a clock controller block that hw designers decided was
good place to shove the ipc bits (because there's room!). Can we call it
l2cc: clock-controller@2011000 {
compatible = syscon;
reg = 0x2011000 0x1000;
};
Eventually I'll add the specific krait compatible when we merge krait
clock support:
l2cc: clock-controller@2011000 {
compatible = qcom,kpss-gcc, syscon;
reg = 0x2011000 0x1000;
clock-output-names = acpu_l2_aux;
};
As long as we can get hold of the regmap that would be fine. I pressume the
idea is to have the kpss-gcc using syscon, just like the rpm. But hopefully the
syscon patches that are floating around (merged?) will allow any driver to
expose a syscon regmap.
+
+ rpm@108000 {
+ compatible = qcom,rpm-apq8064;
+ reg = 0x108000 0x1000;
+ qcom,ipc = apcs 0x8 2;
There are actually 3 ipc bits. I guess if we ever have to use the other
two we'll extend this binding to have the other bits specified some
other way?
I haven't seen any indications of us using more than this bit. If we want to do
that, we could simply make it apcs 8 2 apcs 8 3 apcs 8 4 (or whatever
those indices are). That way this should be easy it keep compatible.
Regards,
Bjorn
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: DT: apq8064: add rpm support
On Mon 29 Sep 02:14 PDT 2014, Srinivas Kandagatla wrote:
This patch adds rpm node to apq8064 dt as rpm would be used by other
devices for regulator support.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index b3154c0..9c2c8e6 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -3,6 +3,7 @@
#include skeleton.dtsi
#include dt-bindings/clock/qcom,gcc-msm8960.h
#include dt-bindings/clock/qcom,mmcc-msm8960.h
+#include dt-bindings/mfd/qcom-rpm.h
#include dt-bindings/soc/qcom,gsbi.h
#include dt-bindings/interrupt-controller/arm-gic.h
@@ -246,6 +247,24 @@
#reset-cells = 1;
};
+ apcs: syscon@2011000 {
+ compatible = syscon;
+ reg = 0x2011000 0x1000;
+ };
+
+ rpm@108000 {
+ compatible = qcom,rpm-apq8064;
+ reg = 0x108000 0x1000;
+ qcom,ipc = apcs 0x8 2;
I don't like your indentation, but please stick with one way of doing it :)
+
+ interrupts = 0 19 0, 0 21 0, 0 22 0;
+ interrupt-names = ack, err, wakeup;
+
+ #address-cells = 1;
+ #size-cells = 0;
+
This part looks good.
But how about adding all the regulators here as well?
Like:
pm8921_l5: pm8921-l5 {
compatible = qcom,rpm-pm8921-pldo;
reg = QCOM_RPM_PM8921_LDO5;
};
...
That way we can update the references from this file (while still allowing the
dts to override it if needed). I'm not sure if we should add some sane defaults
or just completely deferr specifying the voltage ranges to the dts. The benefit
of the latter is that the regulators not configured by the dts author will not
be accessible.
But simply listing all the nodes here would be nice and I dont see much reason
to postpone this work.
+ };
+
/* Temporary fixed regulator */
vsdcc_fixed: vsdcc-regulator {
compatible = regulator-fixed;
Regards,
Bjorn
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: DT: apq8064: Add usb host support.
On Mon 29 Sep 02:15 PDT 2014, Srinivas Kandagatla wrote:
This patch adds device tree nodes to support two usb hosts on APQ8064
SOC.
Sorry for not looking at the entire series before answering patch 1.
I still think you should add all the regulators in the first patch anyways.
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -263,6 +263,91 @@
#address-cells = 1;
#size-cells = 0;
+ pm8921_s3: pm8921-s3 {
+ compatible = qcom,rpm-pm8921-smps;
+ reg = QCOM_RPM_PM8921_SMPS3;
+
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 140;
+ qcom,boot-load = 49360;
As it was unclear how to handle load in the driver I dropped boot-load for now.
Please leave it out until someone have added it to the driver.
+ qcom,switch-mode-frequency = 320;
+ regulator-always-on;
+ };
+
+ pm8921_l3: pm8921-l3 {
+ compatible = qcom,rpm-pm8921-pldo;
+ reg = QCOM_RPM_PM8921_LDO3;
+
+ regulator-min-microvolt = 305;
+ regulator-max-microvolt = 330;
+ regulator-always-on;
+ qcom,boot-load = 5;
Dito
+ };
+
+ pm8921_l23: pm8921-l23 {
+ compatible = qcom,rpm-pm8921-pldo;
+ reg = QCOM_RPM_PM8921_LDO23;
+
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 180;
+ qcom,boot-load = 5;
Dito
+ regulator-always-on;
Why are all these always-on?
+ };
+
+ };
+
/* Temporary fixed regulator */
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
