Re: [PATCHv2 0/4] cpufreq-dt, platform_data based proposal
On 8 October 2014 05:29, Rafael J. Wysocki wrote: > So can you please send me links to the patches? I probably can find them, > but honestly I have too little time for other stuff already. Sure: https://patchwork.kernel.org/patch/4876641/ https://patchwork.kernel.org/patch/4876651/ https://patchwork.kernel.org/patch/4876661/ https://patchwork.kernel.org/patch/4876671/ -- 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 4/4] clk: Use ww_mutexes for clk_prepare_{lock/unlock}
On 09/29/2014 05:12 PM, Stephen Boyd wrote: I'm also auditing clock drivers to find potential brokenness. These are places where we re-enter the framework under drivers/clk/. It looks like sirf can be ported to use determine_rate() and something like my "safe parent" patch. Tegra is concerning given that they call clk_get_rate() in atomic context which is bad because that clk_get_rate() can sleep on the prepare mutex. Otherwise we can probably just convert that to use the unlocked variants. I'm aware of the qcom one, maybe we need a framework flag that indicates that all parent clocks must be enabled to switch this clock's parent. The last one is versatile which I hope we can convert to use assigned-rates? drivers/clk/sirf/clk-common.c:409:ret1 = clk_set_parent(hw->clk, clk_pll1.hw.clk); drivers/clk/sirf/clk-common.c:414:ret1 = clk_set_parent(hw->clk, clk_pll2.hw.clk); drivers/clk/sirf/clk-common.c:419:ret1 = clk_set_parent(hw->clk, clk_pll3.hw.clk); drivers/clk/sirf/clk-common.c:427:ret1 = clk_set_parent(hw->clk, clk_pll2.hw.clk); drivers/clk/sirf/clk-common.c:433:ret1 = clk_set_parent(hw->clk, clk_pll1.hw.clk); drivers/clk/versatile/clk-sp810.c:103: clk_set_parent(hw->clk, new_parent); drivers/clk/sirf/clk-common.c:431:ret2 = clk_set_rate(clk_pll1.hw.clk, rate); drivers/clk/qcom/mmcc-msm8960.c:520:ret = clk_prepare_enable(clk_get_parent_by_index(clk, i)); drivers/clk/qcom/mmcc-msm8960.c:549: clk_disable_unprepare(clk_get_parent_by_index(clk, i)); Not necessary? drivers/clk/sirf/clk-common.c:168:struct clk *parent_clk = clk_get_parent(hw->clk); Not necessary? drivers/clk/sirf/clk-common.c:169:struct clk *pll_parent_clk = clk_get_parent(parent_clk); Not necessary! drivers/clk/sirf/clk-common.c:181:struct clk *parent_clk = clk_get_parent(hw->clk); drivers/clk/sirf/clk-common.c:423:cur_parent = clk_get_parent(hw->clk); drivers/clk/spear/clk-vco-pll.c:90: __clk_get_rate(__clk_get_parent(__clk_get_parent(hw->clk))); drivers/clk/tegra/clk-pll.c:732:unsigned long input_rate = clk_get_rate(clk_get_parent(hw->clk)); drivers/clk/tegra/clk-pll.c:1288:unsigned long input_rate = clk_get_rate(clk_get_parent(hw->clk)); drivers/clk/versatile/clk-sp810.c:82:struct clk *old_parent = __clk_get_parent(hw->clk); drivers/clk/qcom/mmcc-msm8960.c:520:ret = clk_prepare_enable(clk_get_parent_by_index(clk, i)); drivers/clk/versatile/clk-sp810.c:102: clk_prepare(new_parent); drivers/clk/versatile/clk-sp810.c:104: clk_unprepare(old_parent); -- 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 1/2] input: Add Qualcomm PM8941 power key driver
On Tue, Oct 07, 2014 at 04:30:46PM -0700, Bjorn Andersson wrote:
> On Tue 07 Oct 02:54 PDT 2014, Kiran Padwal wrote:
>
> > On Tuesday 07 October 2014 06:42 AM, Bjorn Andersson wrote:
> > > From: Courtney Cavin
> > >
> > > Signed-off-by: Courtney Cavin
> > > Signed-off-by: Bjorn Andersson
> > > ---
> > > drivers/input/misc/Kconfig | 12 +++
> > > drivers/input/misc/Makefile|1 +
> > > drivers/input/misc/pm8941-pwrkey.c | 196
> > >
> >
> >
> >
> > > +
> > > + platform_set_drvdata(pdev, pwrkey);
> > > + device_init_wakeup(&pdev->dev, 1);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int pm8941_pwrkey_remove(struct platform_device *pdev)
> > > +{
> > > + device_init_wakeup(&pdev->dev, 0);
> >
> > Shouldn't we unregister input device?
> >
>
> It's allocated with devm_input_allocate_device() so I assumed that it goes
> away
> upon the device being removed. Looking at input_register_device() seems to
> confirm that.
Yes, devices allocated with devm_input_allocate_device() will be
unregistered and freed automatically.
Thanks.
--
Dmitry
--
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: [PATCHv2 0/4] cpufreq-dt, platform_data based proposal
On Tuesday, October 07, 2014 09:00:16 AM Viresh Kumar wrote: > On 7 October 2014 04:23, Rafael J. Wysocki wrote: > > I'm still seeing discussion going on about patch [1/4], though. > > That's V1's 1/4 and we finalized V2.. > > > Is that irrelevant? > > No. > > > Also I'd prefer Viresh to tell me that this is 3.18 material instead of > > sending ACKs in random replies and hoping that I'll notice them. I may > > not. > > Hmm, so yeah its for 3.18.. OK So can you please send me links to the patches? I probably can find them, but honestly I have too little time for other stuff already. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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/2] input: Add Qualcomm PM8941 power key driver
On Tue 07 Oct 02:54 PDT 2014, Kiran Padwal wrote:
> On Tuesday 07 October 2014 06:42 AM, Bjorn Andersson wrote:
> > From: Courtney Cavin
> >
> > Signed-off-by: Courtney Cavin
> > Signed-off-by: Bjorn Andersson
> > ---
> > drivers/input/misc/Kconfig | 12 +++
> > drivers/input/misc/Makefile|1 +
> > drivers/input/misc/pm8941-pwrkey.c | 196
> >
>
>
>
> > +
> > + platform_set_drvdata(pdev, pwrkey);
> > + device_init_wakeup(&pdev->dev, 1);
> > +
> > + return 0;
> > +}
> > +
> > +static int pm8941_pwrkey_remove(struct platform_device *pdev)
> > +{
> > + device_init_wakeup(&pdev->dev, 0);
>
> Shouldn't we unregister input device?
>
It's allocated with devm_input_allocate_device() so I assumed that it goes away
upon the device being removed. Looking at input_register_device() seems to
confirm that.
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id pm8941_pwr_key_id_table[] = {
> > + { .compatible = "qcom,pm8941-pwrkey" },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, pm8941_pwr_key_id_table);
> > +
> > +static struct platform_driver pm8941_pwrkey_driver = {
> > + .probe = pm8941_pwrkey_probe,
> > + .remove = pm8941_pwrkey_remove,
> > + .driver = {
> > + .name = "pm8941-pwrkey",
> > + .owner = THIS_MODULE,
>
> This field can be removed because this driver which use the
> module_platform_driver api as this is overridden in
> platform_driver_register.
>
Thanks
> > + .pm = &pm8941_pwr_key_pm_ops,
> > + .of_match_table = of_match_ptr(pm8941_pwr_key_id_table),
> > + },
> > +};
> > +module_platform_driver(pm8941_pwrkey_driver);
> > +
> > +MODULE_DESCRIPTION("PM8941 Power Key driver");
> > +MODULE_LICENSE("GPL v2");
>
> May be you can add module author name.
>
Courtney based this driver on the skeleton from pmic8xxx-pwrkey, so I don't
think it's right to say that there's any particular author. And you have the
git log...
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 v8 2/7] arm: dts: qcom: Add power-controller device node for 8974 Krait CPUs
On 10/07/2014 02:41 PM, Lina Iyer wrote:
@@ -144,7 +148,27 @@
};
};
- saw_l2: regulator@f9012000 {
+ saw0: power-controller@f9089000 {
+ compatible = "qcom,msm8974-saw2-v2.1-cpu";
+ reg = <0xf9089000 0x1000>;
Please add the aliases.
--
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 2/4] ARM: qcom: add description of KPSS WDT for IPQ8064
On 10/07/2014 03:10 PM, Josh Cartwright wrote:
On Thu, Oct 02, 2014 at 12:08:38PM -0700, Stephen Boyd wrote:
[..]
On 10/01/14 11:15, Josh Cartwright wrote:
Something like this perhaps:
timer@200a000 {
compatible = "qcom,kpss-timer", "qcom,msm-timer";
interrupts = <1 1 0x301>,
<1 2 0x301>,
<1 3 0x301>;
reg = <0x0200a000 0x100>;
clock-frequency = <2500>,
<32768>;
cpu-offset = <0x8>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
cpu0_wdt0: watchdog@208a038 {
compatible = "qcom,kpss-wdt";
reg = <0x208a038 0x40>;
interrupts = <1 4 0x301>,
clocks = <&sleep_clk>;
timeout-sec = <10>;
cpu = <&cpu0>;
};
cpu0_wdt1: watchdog@208a060 {
compatible = "qcom,kpss-wdt";
reg = <0x208a060 0x40>;
interrupts = <1 5 0x301>,
clocks = <&sleep_clk>;
timeout-sec = <20>;
cpu = <&cpu0>;
};
cpu1_wdt0: watchdog@209a038 {
compatible = "qcom,kpss-wdt";
reg = <0x209a038 0x40>;
interrupts = <1 4 0x301>,
clocks = <&sleep_clk>;
timeout-sec = <8>;
cpu = <&cpu1>;
};
cpu1_wdt1: watchdog@209a060 {
compatible = "qcom,kpss-wdt";
reg = <0x209a060 0x40>;
interrupts = <1 5 0x301>,
clocks = <&sleep_clk>;
timeout-sec = <15>;
cpu = <&cpu1>;
};
};
I'm thinking:
timer@200a000 {
compatible = "qcom,kpss-timer", "qcom,msm-timer";
interrupts = <1 1 0x301>,
<1 2 0x301>,
<1 3 0x301>,
<1 4 0x301>,
<1 5 0x301>;
reg = <0x0200a000 0x100>;
clock-frequency = <2700>,
<32768>;
clocks = <&cxo>, <&sleep_clk>;
clock-names = "ref", "sleep";
cpu-offset = <0x8>;
};
Where'd the default timeout configuration go? Or, should we have one
timeout-sec property and not allow setting the default timeouts per WDT
instance? Or no configurable timeout at all?
Ah sorry. How about a timeout-sec-0, timeout-sec-1 property that is
per-cpu and maps to the first and second watchdog timer? Something like:
timeout-sec-wdt0 = <10 8>;
timeout-sec-wdt1 = <20 15>;
--
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 2/4] ARM: qcom: add description of KPSS WDT for IPQ8064
On Thu, Oct 02, 2014 at 12:08:38PM -0700, Stephen Boyd wrote:
[..]
> On 10/01/14 11:15, Josh Cartwright wrote:
> > The percpu-ness of the two WDTs makes configuration even more
> > interesting, as it's possible you'd want to independently configure
> > timeouts for CPU0_WDT0 and CPU1_WDT0, supporting this with a coalesced
> > timer/wdt would be cumbersome.
>
> We already do similar things for the timers on each cpu. It doesn't seem
> that bad, but that's a matter of opinion.
I think the difference in this case is that each of the 2 per-cpu WDTs
can conceivably be registered independently, each with their own default
timeout configuration. If we wanted to allow the most flexibility, it
seemed to me that making use of subnodes would be the best, but maybe
you have some other idea.
> > Something like this perhaps:
> >
> > timer@200a000 {
> > compatible = "qcom,kpss-timer", "qcom,msm-timer";
> > interrupts = <1 1 0x301>,
> > <1 2 0x301>,
> > <1 3 0x301>;
> > reg = <0x0200a000 0x100>;
> > clock-frequency = <2500>,
> > <32768>;
> > cpu-offset = <0x8>;
> >
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges;
> >
> > cpu0_wdt0: watchdog@208a038 {
> > compatible = "qcom,kpss-wdt";
> > reg = <0x208a038 0x40>;
> > interrupts = <1 4 0x301>,
> > clocks = <&sleep_clk>;
> > timeout-sec = <10>;
> > cpu = <&cpu0>;
> > };
> >
> > cpu0_wdt1: watchdog@208a060 {
> > compatible = "qcom,kpss-wdt";
> > reg = <0x208a060 0x40>;
> > interrupts = <1 5 0x301>,
> > clocks = <&sleep_clk>;
> > timeout-sec = <20>;
> > cpu = <&cpu0>;
> > };
> >
> > cpu1_wdt0: watchdog@209a038 {
> > compatible = "qcom,kpss-wdt";
> > reg = <0x209a038 0x40>;
> > interrupts = <1 4 0x301>,
> > clocks = <&sleep_clk>;
> > timeout-sec = <8>;
> > cpu = <&cpu1>;
> > };
> >
> > cpu1_wdt1: watchdog@209a060 {
> > compatible = "qcom,kpss-wdt";
> > reg = <0x209a060 0x40>;
> > interrupts = <1 5 0x301>,
> > clocks = <&sleep_clk>;
> > timeout-sec = <15>;
> > cpu = <&cpu1>;
> > };
> > };
> >
> >
>
> I'm thinking:
>
> timer@200a000 {
> compatible = "qcom,kpss-timer", "qcom,msm-timer";
> interrupts = <1 1 0x301>,
> <1 2 0x301>,
> <1 3 0x301>,
> <1 4 0x301>,
> <1 5 0x301>;
> reg = <0x0200a000 0x100>;
> clock-frequency = <2700>,
> <32768>;
> clocks = <&cxo>, <&sleep_clk>;
> clock-names = "ref", "sleep";
> cpu-offset = <0x8>;
> };
Where'd the default timeout configuration go? Or, should we have one
timeout-sec property and not allow setting the default timeouts per WDT
instance? Or no configurable timeout at all?
> Can you explain the need for the cpu handle? Luckily this device only
> exists in configurations that have up to 4 CPUs and so mapping the
> logical CPU number to the watchdog for that CPU is "easy" in that we can
> convert the CPU from logical to physical and then do the math taking
> into account the cpu-offset to figure out where the non-aliased
> registers are. Once we get into pairs of watchdogs for different
> clusters this isn't so easy and it's better to have the phandle
> somewhere (either in the watchdog node or the cpu node) and then have
> multiple nodes for the watchdog block per-cpu so that we can map the CPU
> to the device. We realized this when making the saw binding.
Ah, yeah, now that I think about it, it's fairly straightforward to map
backward using the parent cpu-offset to determine the corresponding CPU,
so it wouldn't be necessary.
--
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 v8 1/7] qcom: spm: Add Subsystem Power Manager driver
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.
Based on work by: Mahesh Sivasubramanian ,
Ai Li , Praveen Chidambaram
Original tree available at -
git://codeaurora.org/quic/la/kernel/msm-3.10.git
Signed-off-by: Lina Iyer
---
.../devicetree/bindings/arm/msm/qcom,saw2.txt | 31 ++-
drivers/soc/qcom/Kconfig | 8 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/spm.c | 223 +
4 files changed, 257 insertions(+), 6 deletions(-)
create mode 100644 drivers/soc/qcom/spm.c
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
index 1505fb8..a18e8fc 100644
--- a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
@@ -2,11 +2,20 @@ SPM AVS Wrapper 2 (SAW2)
The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable
-micro-controller that transitions a piece of hardware (like a processor or
+power-controller that transitions a piece of hardware (like a processor or
subsystem) into and out of low power modes via a direct connection to
the PMIC. It can also be wired up to interact with other processors in the
system, notifying them when a low power state is entered or exited.
+Multiple revisions of the SAW hardware is supported using these Device Nodes.
+SAW2 revisions differ in the register offset and configuration data. Also,
+same revision of the SAW in different SoCs may have different configuration
+data due the the differences in hardware capabilities. Hence the SoC name, the
+version of the SAW hardware in that SoC and the distinction between cpu (big
+or Little) or cache, may be needed to uniquely identify the SAW register
+configuration and initialization data. The compatible string is used to
+indicate this parameter.
+
PROPERTIES
- compatible:
@@ -14,10 +23,13 @@ PROPERTIES
Value type:
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,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"
- reg:
Usage: required
@@ -26,10 +38,17 @@ PROPERTIES
the register region. An optional second element specifies
the base address and size of the alias register region.
+- regulator:
+ Usage: optional
+ Value type: boolean
+ Definition: Indicates that this SPM device acts as a regulator device
+ device for the core (CPU or Cache) the SPM is attached
+ to.
Example:
- regulator@2099000 {
+ power-controller@2099000 {
compatible = "qcom,saw2";
reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
+ regulator;
};
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 7dcd554..012fb37 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 ARCH_QCOM
+ 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
[PATCH v8 5/7] qcom: cpuidle: Add cpuidle driver for QCOM cpus
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 Standby and Standalone Power Collapse.
Signed-off-by: Lina Iyer
---
.../bindings/arm/msm/qcom,idle-state.txt | 81 ++
drivers/cpuidle/Kconfig.arm| 7 ++
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/cpuidle-qcom.c | 79 +
4 files changed, 168 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..87f1742
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt
@@ -0,0 +1,81 @@
+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 -
+
+* Standby
+* Retention
+* Standalone Power Collapse (Standalone PC or SPC)
+* Power Collapse (PC)
+
+Standby: Standby does a little more in addition to architectural clock gating.
+When the WFI instruction is executed the ARM core would gate its internal
+clocks. In addition to gating the clocks, QCOM cpus use this instruction as a
+trigger to execute the SPM state machine. The SPM state machine waits for the
+interrupt to trigger the core back in to active. This triggers the cache
+heirarchy to enter standby states, when all cpus are idle. An interrupt brings
+the SPM state machine out of its wait, the next step is to ensure that the
+cache heirarchy is also out of standby, and then the cpu is allowed to resume
+execution.
+
+Retention: Retention is a low power state where the core is clock gated 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. The SPM 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 Standby.
+
+Standalone PC: A cpu can power down and warmboot if there is a sufficient time
+between the time it enters idle and the next known wake up. SPC mode is used
+to indicate a core entering a power down state without consulting any other
+cpu or the system resources. This helps save power only on that core. The SPM
+sequence for this idle state is programmed to power down the supply to the
+core, wait for the interrupt, restore power to the core, and ensure the
+system state including cache hierarchy is ready before allowing core to
+resume. Applying power and resetting the core causes the core to warmboot
+back into Elevation Level (EL) which trampolines the control back to the
+kernel. Entering a power down state for the cpu, needs to be done by trapping
+into a EL. Failing to do so, would result in a crash enforced by the warm boot
+code in the EL for the SoC. On SoCs with write-back L1 cache, the cache has to
+be flushed in s/w, before powering down the core.
+
+Power Collapse: This state is similar to the SPC mode, but distinguishes
+itself in that the cpu acknowledges and permits the SoC to enter 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 clock gated and
+voltages reduced, provided all cpus enter this state. Since the span of low
+power modes possible at this state 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
+application processor subsystem shut down.
+
+The idle-state for QCOM SoCs are distinguished by the compatible property of
+the idle-states device node.
+The devicetree representation of the idle state should be -
+
+Required properties:
+
+- compatible: Must be one of -
+ "qcom,idle-state-stby",
+ "qcom,idle-state-ret",
+ "qcom,idle-state-spc",
+ "qcom,idle-state-pc",
+ and "arm,idle-state".
+
+Other required and optional properties are specified in [1].
+
+Example:
+
+ idle-states {
+ CPU_SPC: spc {
+ compatible = "qcom,idle-state-spc", "arm,idle-state";
+ entry-latency-us = <150>;
+
[PATCH v8 0/7] QCOM 8974 and 8084 cpuidle driver
Hi,
This v8 revision of the cpuidle driver is available at
git.linaro.org:/people/lina.iyer/linux-next cpuidle-v8
Changes since v7:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg11199.html ]
- Address review comments
- Tested on 8974 but not 8084
- WFI renamed to Standby
- Update commit text with original author and link to the downstream tree
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-pm&m=140794514812383&w=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 power-controller device node for 8974 Krait CPUs
arm: dts: qcom: Add power-controller device node for 8084 Krait CPUs
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
[PATCH v8 7/7] arm: dts: qcom: Add idle states device nodes for 8084
Add allowable C-States for each cpu using the cpu-idle-states node.
Support standby and standalone power collapse (power down that does not
affect any SoC idle states) for each cpu.
Signed-off-by: Lina Iyer
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index 1581b12..68eb4bb1 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -19,6 +19,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc0>;
qcom,saw = <&saw0>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
cpu@1 {
@@ -29,6 +30,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc1>;
qcom,saw = <&saw1>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
cpu@2 {
@@ -39,6 +41,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc2>;
qcom,saw = <&saw2>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
cpu@3 {
@@ -49,6 +52,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc3>;
qcom,saw = <&saw3>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
L2: l2-cache {
@@ -56,6 +60,22 @@
cache-level = <2>;
qcom,saw = <&saw_l2>;
};
+
+ idle-states {
+ CPU_STBY: standby {
+ compatible = "qcom,idle-state-stby",
"arm,idle-state";
+ entry-latency-us = <1>;
+ exit-latency-us = <1>;
+ min-residency-us = <2>;
+ };
+
+ CPU_SPC: spc {
+ compatible = "qcom,idle-state-spc",
"arm,idle-state";
+ entry-latency-us = <150>;
+ exit-latency-us = <200>;
+ min-residency-us = <2000>;
+ };
+ };
};
cpu-pmu {
--
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 v8 6/7] arm: dts: qcom: Add idle states device nodes for 8974
Add allowable C-States for each cpu using the cpu-idle-states node.
Support Standby and Standalone power collapse (power down that does not
affect any SoC idle states) for each cpu.
Signed-off-by: Lina Iyer
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 70c4329..a5e51fe 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -22,6 +22,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc0>;
qcom,saw = <&saw0>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
cpu@1 {
@@ -32,6 +33,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc1>;
qcom,saw = <&saw1>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
cpu@2 {
@@ -42,6 +44,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc2>;
qcom,saw = <&saw2>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
cpu@3 {
@@ -52,6 +55,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc3>;
qcom,saw = <&saw3>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
L2: l2-cache {
@@ -59,6 +63,22 @@
cache-level = <2>;
qcom,saw = <&saw_l2>;
};
+
+ idle-states {
+ CPU_STBY: standby {
+ compatible = "qcom,idle-state-stby",
"arm,idle-state";
+ entry-latency-us = <1>;
+ exit-latency-us = <1>;
+ min-residency-us = <2>;
+ };
+
+ CPU_SPC: spc {
+ compatible = "qcom,idle-state-spc",
"arm,idle-state";
+ entry-latency-us = <150>;
+ exit-latency-us = <200>;
+ min-residency-us = <2000>;
+ };
+ };
};
cpu-pmu {
--
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 v8 4/7] qcom: pm: Add cpu low power mode functions
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 -
* Standby
* Retention (clock gating at lower power)
* Standalone Power Collapse (Standalone PC or SPC) - The power to
the cpu is removed and core is reset upon resume.
* Power Collapse (PC) - Same as SPC, but is a cognizant of the fact
that the SoC may do deeper sleep modes.
Support Standby and SPC for the currently available QCOM SoCs.
Based on work by: Mahesh Sivasubramanian ,
Praveen Chidambaram , Murali Nalajala
Original tree available at -
git://codeaurora.org/quic/la/kernel/msm-3.10.git
Signed-off-by: Lina Iyer
---
drivers/soc/qcom/Makefile | 2 +-
drivers/soc/qcom/pm.c | 115 ++
include/soc/qcom/pm.h | 28 +++
3 files changed, 144 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..1cb622e
--- /dev/null
+++ b/drivers/soc/qcom/pm.c
@@ -0,0 +1,115 @@
+/* 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
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+
+#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);
+ int ret;
+
+ if (entry == per_cpu(last_known_entry, cpu))
+ return 0;
+
+ ret = scm_set_boot_addr(virt_to_phys(entry), flags[cpu]);
+ if (!ret)
+ per_cpu(last_known_entry, cpu) = entry;
+
+ return ret;
+}
+
+static int qcom_pm_collapse(unsigned long int unused)
+{
+ int ret;
+ u32 flag;
+ int cpu = smp_processor_id();
+
+ ret = set_up_boot_address(cpu_resume, cpu);
+ if (ret) {
+ pr_err("Failed to set warm boot address for cpu %d\n", cpu);
+ return ret;
+ }
+
+ flag = SCM_L2_ON & SCM_FLUSH_FLAG_MASK;
+ scm_call_atomic1(SCM_SVC_BOOT, SCM_CMD_TERMINATE_PC, flag);
+
+ /**
+* Returns here only if there was a pending interrupt and we did not
+* power down as a result.
+*/
+ 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;
+
+ ret = qcom_spm_set_low_power_mode(mode);
+ if (ret)
+ return ret;
+
+ switch (mode) {
+ case PM_SLEEP_MODE_SPC:
+ cpu_suspend(0, qcom_pm_collapse);
+ break;
+ default:
+ case PM_SLEEP_MODE_STBY:
+ cpu_do_idle();
+ break;
+ }
+
+ return 0;
+}
+
+static struct platform_device qcom_cpuidle_device = {
+ .name = "qcom_cpuidle",
+ .id= -1,
+ .dev.platform_data = qcom_cpu_pm_enter_sleep,
+};
+
+static int __init qcom_pm_device_init(void)
+{
+ platform_device_register(&qcom_cpuidle_device);
+
+ return 0;
+}
+module_init(qcom_pm_device_init);
diff --git a/include/soc/qcom/pm.h b/include/soc/qcom/pm.h
new file mode 100644
index 000..e63dc1c
--- /dev/null
+++ b/include/soc/qcom/pm.h
@@ -0,0 +1,28 @@
+/*
+ * Copyright (c) 2009-2014, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU Genera
[PATCH v8 2/7] arm: dts: qcom: Add power-controller device node for 8974 Krait CPUs
Each Krait CPU in the QCOM 8974 SoC has an SAW power controller to
regulate the power to the cpu and aide the core in entering idle states.
Reference the SAW instance and associate the instance with the CPU core.
Signed-off-by: Lina Iyer
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 69dca2a..70c4329 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -21,6 +21,7 @@
reg = <0>;
next-level-cache = <&L2>;
qcom,acc = <&acc0>;
+ qcom,saw = <&saw0>;
};
cpu@1 {
@@ -30,6 +31,7 @@
reg = <1>;
next-level-cache = <&L2>;
qcom,acc = <&acc1>;
+ qcom,saw = <&saw1>;
};
cpu@2 {
@@ -39,6 +41,7 @@
reg = <2>;
next-level-cache = <&L2>;
qcom,acc = <&acc2>;
+ qcom,saw = <&saw2>;
};
cpu@3 {
@@ -48,6 +51,7 @@
reg = <3>;
next-level-cache = <&L2>;
qcom,acc = <&acc3>;
+ qcom,saw = <&saw3>;
};
L2: l2-cache {
@@ -144,7 +148,27 @@
};
};
- saw_l2: regulator@f9012000 {
+ saw0: power-controller@f9089000 {
+ compatible = "qcom,msm8974-saw2-v2.1-cpu";
+ reg = <0xf9089000 0x1000>;
+ };
+
+ saw1: power-controller@f9099000 {
+ compatible = "qcom,msm8974-saw2-v2.1-cpu";
+ reg = <0xf9099000 0x1000>;
+ };
+
+ saw2: power-controller@f90a9000 {
+ compatible = "qcom,msm8974-saw2-v2.1-cpu";
+ reg = <0xf90a9000 0x1000>;
+ };
+
+ saw3: power-controller@f90b9000 {
+ compatible = "qcom,msm8974-saw2-v2.1-cpu";
+ reg = <0xf90b9000 0x1000>;
+ };
+
+ saw_l2: power-controller@f9012000 {
compatible = "qcom,saw2";
reg = <0xf9012000 0x1000>;
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
[PATCH v8 3/7] arm: dts: qcom: Add power-controller device node for 8084 Krait CPUs
Each Krait CPU in the QCOM 8084 SoC has an SAW power controller to
regulate the power to the cpu and aide the core in entering idle states.
Reference the SAW instance and associate the instance with the CPU core.
Signed-off-by: Lina Iyer
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index e3e009a..1581b12 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -18,6 +18,7 @@
enable-method = "qcom,kpss-acc-v2";
next-level-cache = <&L2>;
qcom,acc = <&acc0>;
+ qcom,saw = <&saw0>;
};
cpu@1 {
@@ -27,6 +28,7 @@
enable-method = "qcom,kpss-acc-v2";
next-level-cache = <&L2>;
qcom,acc = <&acc1>;
+ qcom,saw = <&saw1>;
};
cpu@2 {
@@ -36,6 +38,7 @@
enable-method = "qcom,kpss-acc-v2";
next-level-cache = <&L2>;
qcom,acc = <&acc2>;
+ qcom,saw = <&saw2>;
};
cpu@3 {
@@ -45,6 +48,7 @@
enable-method = "qcom,kpss-acc-v2";
next-level-cache = <&L2>;
qcom,acc = <&acc3>;
+ qcom,saw = <&saw3>;
};
L2: l2-cache {
@@ -141,7 +145,27 @@
};
};
- saw_l2: regulator@f9012000 {
+ saw0: power-controller@f9089000 {
+ compatible = "qcom,apq8084-saw2-v2.1-cpu";
+ reg = <0xf9089000 0x1000>;
+ };
+
+ saw1: power-controller@f9099000 {
+ compatible = "qcom,apq8084-saw2-v2.1-cpu";
+ reg = <0xf9099000 0x1000>;
+ };
+
+ saw2: power-controller@f90a9000 {
+ compatible = "qcom,apq8084-saw2-v2.1-cpu";
+ reg = <0xf90a9000 0x1000>;
+ };
+
+ saw3: power-controller@f90b9000 {
+ compatible = "qcom,apq8084-saw2-v2.1-cpu";
+ reg = <0xf90b9000 0x1000>;
+ };
+
+ saw_l2: power-controller@f9012000 {
compatible = "qcom,saw2";
reg = <0xf9012000 0x1000>;
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
[PATCH 5/7] qcom: cpuidle: Add cpuidle driver for QCOM cpus
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 Standby and Standalone Power Collapse.
Signed-off-by: Lina Iyer
---
.../bindings/arm/msm/qcom,idle-state.txt | 81 ++
drivers/cpuidle/Kconfig.arm| 7 ++
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/cpuidle-qcom.c | 79 +
4 files changed, 168 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..87f1742
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt
@@ -0,0 +1,81 @@
+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 -
+
+* Standby
+* Retention
+* Standalone Power Collapse (Standalone PC or SPC)
+* Power Collapse (PC)
+
+Standby: Standby does a little more in addition to architectural clock gating.
+When the WFI instruction is executed the ARM core would gate its internal
+clocks. In addition to gating the clocks, QCOM cpus use this instruction as a
+trigger to execute the SPM state machine. The SPM state machine waits for the
+interrupt to trigger the core back in to active. This triggers the cache
+heirarchy to enter standby states, when all cpus are idle. An interrupt brings
+the SPM state machine out of its wait, the next step is to ensure that the
+cache heirarchy is also out of standby, and then the cpu is allowed to resume
+execution.
+
+Retention: Retention is a low power state where the core is clock gated 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. The SPM 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 Standby.
+
+Standalone PC: A cpu can power down and warmboot if there is a sufficient time
+between the time it enters idle and the next known wake up. SPC mode is used
+to indicate a core entering a power down state without consulting any other
+cpu or the system resources. This helps save power only on that core. The SPM
+sequence for this idle state is programmed to power down the supply to the
+core, wait for the interrupt, restore power to the core, and ensure the
+system state including cache hierarchy is ready before allowing core to
+resume. Applying power and resetting the core causes the core to warmboot
+back into Elevation Level (EL) which trampolines the control back to the
+kernel. Entering a power down state for the cpu, needs to be done by trapping
+into a EL. Failing to do so, would result in a crash enforced by the warm boot
+code in the EL for the SoC. On SoCs with write-back L1 cache, the cache has to
+be flushed in s/w, before powering down the core.
+
+Power Collapse: This state is similar to the SPC mode, but distinguishes
+itself in that the cpu acknowledges and permits the SoC to enter 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 clock gated and
+voltages reduced, provided all cpus enter this state. Since the span of low
+power modes possible at this state 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
+application processor subsystem shut down.
+
+The idle-state for QCOM SoCs are distinguished by the compatible property of
+the idle-states device node.
+The devicetree representation of the idle state should be -
+
+Required properties:
+
+- compatible: Must be one of -
+ "qcom,idle-state-stby",
+ "qcom,idle-state-ret",
+ "qcom,idle-state-spc",
+ "qcom,idle-state-pc",
+ and "arm,idle-state".
+
+Other required and optional properties are specified in [1].
+
+Example:
+
+ idle-states {
+ CPU_SPC: spc {
+ compatible = "qcom,idle-state-spc", "arm,idle-state";
+ entry-latency-us = <150>;
+
[PATCH 3/7] arm: dts: qcom: Add power-controller device node for 8084 Krait CPUs
Each Krait CPU in the QCOM 8084 SoC has an SAW power controller to
regulate the power to the cpu and aide the core in entering idle states.
Reference the SAW instance and associate the instance with the CPU core.
Signed-off-by: Lina Iyer
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index e3e009a..1581b12 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -18,6 +18,7 @@
enable-method = "qcom,kpss-acc-v2";
next-level-cache = <&L2>;
qcom,acc = <&acc0>;
+ qcom,saw = <&saw0>;
};
cpu@1 {
@@ -27,6 +28,7 @@
enable-method = "qcom,kpss-acc-v2";
next-level-cache = <&L2>;
qcom,acc = <&acc1>;
+ qcom,saw = <&saw1>;
};
cpu@2 {
@@ -36,6 +38,7 @@
enable-method = "qcom,kpss-acc-v2";
next-level-cache = <&L2>;
qcom,acc = <&acc2>;
+ qcom,saw = <&saw2>;
};
cpu@3 {
@@ -45,6 +48,7 @@
enable-method = "qcom,kpss-acc-v2";
next-level-cache = <&L2>;
qcom,acc = <&acc3>;
+ qcom,saw = <&saw3>;
};
L2: l2-cache {
@@ -141,7 +145,27 @@
};
};
- saw_l2: regulator@f9012000 {
+ saw0: power-controller@f9089000 {
+ compatible = "qcom,apq8084-saw2-v2.1-cpu";
+ reg = <0xf9089000 0x1000>;
+ };
+
+ saw1: power-controller@f9099000 {
+ compatible = "qcom,apq8084-saw2-v2.1-cpu";
+ reg = <0xf9099000 0x1000>;
+ };
+
+ saw2: power-controller@f90a9000 {
+ compatible = "qcom,apq8084-saw2-v2.1-cpu";
+ reg = <0xf90a9000 0x1000>;
+ };
+
+ saw3: power-controller@f90b9000 {
+ compatible = "qcom,apq8084-saw2-v2.1-cpu";
+ reg = <0xf90b9000 0x1000>;
+ };
+
+ saw_l2: power-controller@f9012000 {
compatible = "qcom,saw2";
reg = <0xf9012000 0x1000>;
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
[PATCH 7/7] arm: dts: qcom: Add idle states device nodes for 8084
Add allowable C-States for each cpu using the cpu-idle-states node.
Support standby and standalone power collapse (power down that does not
affect any SoC idle states) for each cpu.
Signed-off-by: Lina Iyer
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index 1581b12..68eb4bb1 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -19,6 +19,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc0>;
qcom,saw = <&saw0>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
cpu@1 {
@@ -29,6 +30,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc1>;
qcom,saw = <&saw1>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
cpu@2 {
@@ -39,6 +41,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc2>;
qcom,saw = <&saw2>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
cpu@3 {
@@ -49,6 +52,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc3>;
qcom,saw = <&saw3>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
L2: l2-cache {
@@ -56,6 +60,22 @@
cache-level = <2>;
qcom,saw = <&saw_l2>;
};
+
+ idle-states {
+ CPU_STBY: standby {
+ compatible = "qcom,idle-state-stby",
"arm,idle-state";
+ entry-latency-us = <1>;
+ exit-latency-us = <1>;
+ min-residency-us = <2>;
+ };
+
+ CPU_SPC: spc {
+ compatible = "qcom,idle-state-spc",
"arm,idle-state";
+ entry-latency-us = <150>;
+ exit-latency-us = <200>;
+ min-residency-us = <2000>;
+ };
+ };
};
cpu-pmu {
--
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 6/7] arm: dts: qcom: Add idle states device nodes for 8974
Add allowable C-States for each cpu using the cpu-idle-states node.
Support Standby and Standalone power collapse (power down that does not
affect any SoC idle states) for each cpu.
Signed-off-by: Lina Iyer
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 70c4329..a5e51fe 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -22,6 +22,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc0>;
qcom,saw = <&saw0>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
cpu@1 {
@@ -32,6 +33,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc1>;
qcom,saw = <&saw1>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
cpu@2 {
@@ -42,6 +44,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc2>;
qcom,saw = <&saw2>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
cpu@3 {
@@ -52,6 +55,7 @@
next-level-cache = <&L2>;
qcom,acc = <&acc3>;
qcom,saw = <&saw3>;
+ cpu-idle-states = <&CPU_STBY &CPU_SPC>;
};
L2: l2-cache {
@@ -59,6 +63,22 @@
cache-level = <2>;
qcom,saw = <&saw_l2>;
};
+
+ idle-states {
+ CPU_STBY: standby {
+ compatible = "qcom,idle-state-stby",
"arm,idle-state";
+ entry-latency-us = <1>;
+ exit-latency-us = <1>;
+ min-residency-us = <2>;
+ };
+
+ CPU_SPC: spc {
+ compatible = "qcom,idle-state-spc",
"arm,idle-state";
+ entry-latency-us = <150>;
+ exit-latency-us = <200>;
+ min-residency-us = <2000>;
+ };
+ };
};
cpu-pmu {
--
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/7] arm: dts: qcom: Add power-controller device node for 8974 Krait CPUs
Each Krait CPU in the QCOM 8974 SoC has an SAW power controller to
regulate the power to the cpu and aide the core in entering idle states.
Reference the SAW instance and associate the instance with the CPU core.
Signed-off-by: Lina Iyer
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 69dca2a..70c4329 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -21,6 +21,7 @@
reg = <0>;
next-level-cache = <&L2>;
qcom,acc = <&acc0>;
+ qcom,saw = <&saw0>;
};
cpu@1 {
@@ -30,6 +31,7 @@
reg = <1>;
next-level-cache = <&L2>;
qcom,acc = <&acc1>;
+ qcom,saw = <&saw1>;
};
cpu@2 {
@@ -39,6 +41,7 @@
reg = <2>;
next-level-cache = <&L2>;
qcom,acc = <&acc2>;
+ qcom,saw = <&saw2>;
};
cpu@3 {
@@ -48,6 +51,7 @@
reg = <3>;
next-level-cache = <&L2>;
qcom,acc = <&acc3>;
+ qcom,saw = <&saw3>;
};
L2: l2-cache {
@@ -144,7 +148,27 @@
};
};
- saw_l2: regulator@f9012000 {
+ saw0: power-controller@f9089000 {
+ compatible = "qcom,msm8974-saw2-v2.1-cpu";
+ reg = <0xf9089000 0x1000>;
+ };
+
+ saw1: power-controller@f9099000 {
+ compatible = "qcom,msm8974-saw2-v2.1-cpu";
+ reg = <0xf9099000 0x1000>;
+ };
+
+ saw2: power-controller@f90a9000 {
+ compatible = "qcom,msm8974-saw2-v2.1-cpu";
+ reg = <0xf90a9000 0x1000>;
+ };
+
+ saw3: power-controller@f90b9000 {
+ compatible = "qcom,msm8974-saw2-v2.1-cpu";
+ reg = <0xf90b9000 0x1000>;
+ };
+
+ saw_l2: power-controller@f9012000 {
compatible = "qcom,saw2";
reg = <0xf9012000 0x1000>;
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
[PATCH 4/7] qcom: pm: Add cpu low power mode functions
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 -
* Standby
* Retention (clock gating at lower power)
* Standalone Power Collapse (Standalone PC or SPC) - The power to
the cpu is removed and core is reset upon resume.
* Power Collapse (PC) - Same as SPC, but is a cognizant of the fact
that the SoC may do deeper sleep modes.
Support Standby and SPC for the currently available QCOM SoCs.
Based on work by: Mahesh Sivasubramanian ,
Praveen Chidambaram , Murali Nalajala
Original tree available at -
git://codeaurora.org/quic/la/kernel/msm-3.10.git
Signed-off-by: Lina Iyer
---
drivers/soc/qcom/Makefile | 2 +-
drivers/soc/qcom/pm.c | 115 ++
include/soc/qcom/pm.h | 28 +++
3 files changed, 144 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..1cb622e
--- /dev/null
+++ b/drivers/soc/qcom/pm.c
@@ -0,0 +1,115 @@
+/* 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
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+
+#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);
+ int ret;
+
+ if (entry == per_cpu(last_known_entry, cpu))
+ return 0;
+
+ ret = scm_set_boot_addr(virt_to_phys(entry), flags[cpu]);
+ if (!ret)
+ per_cpu(last_known_entry, cpu) = entry;
+
+ return ret;
+}
+
+static int qcom_pm_collapse(unsigned long int unused)
+{
+ int ret;
+ u32 flag;
+ int cpu = smp_processor_id();
+
+ ret = set_up_boot_address(cpu_resume, cpu);
+ if (ret) {
+ pr_err("Failed to set warm boot address for cpu %d\n", cpu);
+ return ret;
+ }
+
+ flag = SCM_L2_ON & SCM_FLUSH_FLAG_MASK;
+ scm_call_atomic1(SCM_SVC_BOOT, SCM_CMD_TERMINATE_PC, flag);
+
+ /**
+* Returns here only if there was a pending interrupt and we did not
+* power down as a result.
+*/
+ 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;
+
+ ret = qcom_spm_set_low_power_mode(mode);
+ if (ret)
+ return ret;
+
+ switch (mode) {
+ case PM_SLEEP_MODE_SPC:
+ cpu_suspend(0, qcom_pm_collapse);
+ break;
+ default:
+ case PM_SLEEP_MODE_STBY:
+ cpu_do_idle();
+ break;
+ }
+
+ return 0;
+}
+
+static struct platform_device qcom_cpuidle_device = {
+ .name = "qcom_cpuidle",
+ .id= -1,
+ .dev.platform_data = qcom_cpu_pm_enter_sleep,
+};
+
+static int __init qcom_pm_device_init(void)
+{
+ platform_device_register(&qcom_cpuidle_device);
+
+ return 0;
+}
+module_init(qcom_pm_device_init);
diff --git a/include/soc/qcom/pm.h b/include/soc/qcom/pm.h
new file mode 100644
index 000..e63dc1c
--- /dev/null
+++ b/include/soc/qcom/pm.h
@@ -0,0 +1,28 @@
+/*
+ * Copyright (c) 2009-2014, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU Genera
[PATCH 1/7] qcom: spm: Add Subsystem Power Manager driver
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.
Based on work by: Mahesh Sivasubramanian ,
Ai Li , Praveen Chidambaram
Original tree available at -
git://codeaurora.org/quic/la/kernel/msm-3.10.git
Signed-off-by: Lina Iyer
---
.../devicetree/bindings/arm/msm/qcom,saw2.txt | 31 ++-
drivers/soc/qcom/Kconfig | 8 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/spm.c | 223 +
4 files changed, 257 insertions(+), 6 deletions(-)
create mode 100644 drivers/soc/qcom/spm.c
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
index 1505fb8..a18e8fc 100644
--- a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
@@ -2,11 +2,20 @@ SPM AVS Wrapper 2 (SAW2)
The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable
-micro-controller that transitions a piece of hardware (like a processor or
+power-controller that transitions a piece of hardware (like a processor or
subsystem) into and out of low power modes via a direct connection to
the PMIC. It can also be wired up to interact with other processors in the
system, notifying them when a low power state is entered or exited.
+Multiple revisions of the SAW hardware is supported using these Device Nodes.
+SAW2 revisions differ in the register offset and configuration data. Also,
+same revision of the SAW in different SoCs may have different configuration
+data due the the differences in hardware capabilities. Hence the SoC name, the
+version of the SAW hardware in that SoC and the distinction between cpu (big
+or Little) or cache, may be needed to uniquely identify the SAW register
+configuration and initialization data. The compatible string is used to
+indicate this parameter.
+
PROPERTIES
- compatible:
@@ -14,10 +23,13 @@ PROPERTIES
Value type:
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,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"
- reg:
Usage: required
@@ -26,10 +38,17 @@ PROPERTIES
the register region. An optional second element specifies
the base address and size of the alias register region.
+- regulator:
+ Usage: optional
+ Value type: boolean
+ Definition: Indicates that this SPM device acts as a regulator device
+ device for the core (CPU or Cache) the SPM is attached
+ to.
Example:
- regulator@2099000 {
+ power-controller@2099000 {
compatible = "qcom,saw2";
reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
+ regulator;
};
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 7dcd554..012fb37 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 ARCH_QCOM
+ 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
Re: [PATCH v2 04/15] clk: divider: Make generic for usage elsewhere
On 07/10/14 19:26, Stephen Boyd wrote: On 10/07/2014 10:27 AM, Srinivas Kandagatla wrote: Hi Stephen, Just noticed this regression while testing the patch on Arndale board. https://bugs.linaro.org/show_bug.cgi?id=740 If you return value it works correctly right? Am really not sure, as this bug was originally reported as part of Linaro tracking kernel. --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 2/2] input: pm8941-pwrkey: Add DT binding documentation
On Oct 6, 2014, at 8:12 PM, Bjorn Andersson
wrote:
> From: Courtney Cavin
>
> Signed-off-by: Courtney Cavin
> Signed-off-by: Bjorn Andersson
> ---
> .../bindings/input/qcom,pm8941-pwrkey.txt | 43
> 1 file changed, 43 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
>
> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> new file mode 100644
> index 000..4d75e2c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> @@ -0,0 +1,43 @@
> +Qualcomm PM8941 PMIC Power Key
> +
> +PROPERTIES
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be one of:
> + "qcom,pm8941-pwrkey"
> +
> +- reg:
> + Usage: required
> + Value type:
> + Definition: base address of registers for block
> +
> +- interrupts:
> + Usage: required
> + Value type:
> + Definition: key change interrupt; The format of the specifier is
> + defined by the binding document describing the node's
> + interrupt parent.
> +
> +- debounce:
> + Usage: optional
> + Value type:
> + Definition: time in microseconds that key must be pressed or released
> + for state change interrupt to trigger.
> +
> +- bias-pull-up:
> + Usage: optional
> + Value type:
boolean, is probably better than here.
> + Definition: presence of this property indicates that the KPDPWR_N pin
> + should be configured for pull up.
> +
> +EXAMPLE
> +
> + pwrkey@800 {
> + compatible = "qcom,pm8941-pwrkey";
> + reg = <0x800>;
> + interrupts = <0x0 0x8 0 0>;
> + debounce = <15625>;
> + bias-pull-up;
> + };
> --
> 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
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-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 0/2] Qualcomm PM8941 power key driver
On Tue 07 Oct 02:01 PDT 2014, Ivan T. Ivanov wrote: > > Hi Bjorn, > > On Mon, 2014-10-06 at 18:11 -0700, Bjorn Andersson wrote: > > These patches add dt bindings and a device driver for the power key block in > > the Qualcomm PM8941 pmic. > > > > Courtney Cavin (2): > > input: Add Qualcomm PM8941 power key driver > > input: pm8941-pwrkey: Add DT binding documentation > > > > .../bindings/input/qcom,pm8941-pwrkey.txt | 43 + > > drivers/input/misc/Kconfig | 12 ++ > > drivers/input/misc/Makefile|1 + > > drivers/input/misc/pm8941-pwrkey.c | 196 > > > > 4 files changed, 252 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt > > create mode 100644 drivers/input/misc/pm8941-pwrkey.c > > Any reason why we cannot reuse pm8xxx-pwrkey driver? It have been > converted to regmap already. > The boilerplate code is the same, but configuration registers have different layout and values written in them are different. The pm8xxx block have separate interrupts for press and release events while pm8941 have one interrupt for both, so the pm8941 must read out the irq status bits to figure out which event it was. Maybe if we introduce some vagueness related to interrupts in the dt binding documentation for pm8xxx we could simply reuse that binding. 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 v2 04/15] clk: divider: Make generic for usage elsewhere
On 10/07/2014 10:27 AM, Srinivas Kandagatla wrote: Hi Stephen, Just noticed this regression while testing the patch on Arndale board. https://bugs.linaro.org/show_bug.cgi?id=740 If you return value it works correctly right? -- 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 2/4] Input: pmic8xxx-keypad - use regmap_field for register access
Hi Ivan, On Tue, Oct 07, 2014 at 12:50:46PM +0300, Ivan T. Ivanov wrote: > @@ -527,10 +538,55 @@ static int pmic8xxx_kp_probe(struct platform_device > *pdev) > > platform_set_drvdata(pdev, kp); > > + if (rows < info->min_rows) > + rows = info->min_rows; > + > + if (cols < info->min_cols) > + cols = info->min_cols; > + > kp->num_rows= rows; > kp->num_cols= cols; > kp->dev = &pdev->dev; > > + kp->events = devm_regmap_field_alloc(kp->dev, kp->regmap, > + info->events); > + if (IS_ERR(kp->events)) > + return PTR_ERR(kp->events); > + > + kp->scan_rows = devm_regmap_field_alloc(kp->dev, kp->regmap, > + info->scan_rows); > + if (IS_ERR(kp->scan_rows)) > + return PTR_ERR(kp->scan_rows); > + > + kp->scan_cols = devm_regmap_field_alloc(kp->dev, kp->regmap, > + info->scan_cols); > + if (IS_ERR(kp->scan_cols)) > + return PTR_ERR(kp->scan_cols); > + > + kp->enable = devm_regmap_field_alloc(kp->dev, kp->regmap, > + info->enable); > + if (IS_ERR(kp->enable)) > + return PTR_ERR(kp->enable); > + > + kp->read_state = devm_regmap_field_alloc(kp->dev, kp->regmap, > + info->read_state); > + if (IS_ERR(kp->read_state)) > + return PTR_ERR(kp->read_state); > + > + kp->dbonce = devm_regmap_field_alloc(kp->dev, kp->regmap, > + info->dbonce); > + if (IS_ERR(kp->dbonce)) > + return PTR_ERR(kp->dbonce); > + > + kp->pause = devm_regmap_field_alloc(kp->dev, kp->regmap, info->pause); > + if (IS_ERR(kp->pause)) > + return PTR_ERR(kp->pause); > + > + kp->row_hold = devm_regmap_field_alloc(kp->dev, kp->regmap, > +info->row_hold); > + if (IS_ERR(kp->row_hold)) > + return PTR_ERR(kp->row_hold); Why do we have to allocate all regmap fields separately instead of embedding them into keypad structure? Thanks. -- Dmitry -- 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 04/15] clk: divider: Make generic for usage elsewhere
Hi Stephen,
Just noticed this regression while testing the patch on Arndale board.
https://bugs.linaro.org/show_bug.cgi?id=740
--srini
On 03/10/14 19:07, Stephen Boyd wrote:
On 09/05/14 15:47, Stephen Boyd wrote:
+
+int divider_get_val(unsigned long rate, unsigned long parent_rate,
+ const struct clk_div_table *table, u8 width,
+ unsigned long flags)
+{
unsigned int div, value;
- unsigned long flags = 0;
- u32 val;
div = DIV_ROUND_UP(parent_rate, rate);
- if (!_is_valid_div(divider, div))
+ if (!_is_valid_div(table, div, flags))
return -EINVAL;
- value = _get_val(divider, div);
+ value = _get_val(table, div, flags);
+
+ min_t(unsigned int, value, div_mask(width));
+
+ return 0;
This should be return value, not return 0.
+}
+EXPORT_SYMBOL_GPL(divider_get_val);
--
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 v4 3/4] pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver
On Tue, Sep 30, 2014 at 7:02 PM, Bjorn Andersson wrote: > On Wed 24 Sep 06:09 PDT 2014, Ivan T. Ivanov wrote: >> I am unable to make this work. of_gpio_simple_xlate() didn't know that >> GPIO range is offset with 1. Requesting last GPIO return error. And >> debug output looks weird, for example: >> >> # cat /sys/kernel/debug/gpio >> ... >> GPIOs 220-255, platform/0.c000.gpios, 0.c000.gpios: >> ... >> >> # cat /sys/kernel/debug/pinctrl/0.c000.gpios/gpio-ranges >> GPIO ranges handled: >> 1: 0.c000.gpios GPIOS [221 - 256] PINS [0 - 35] >> >> Advice, please. > > Looking at of_gpio_simple_xlate() shows that you're right. It doesn't seem to > be possible to have a gpiochip that is not 0-based. Then I guess you have to > have your own "off-by-one-xlate". > > @Linus, any comments on this? All documentation states that we have > gpio1-gpioXX in these chips, so we have to expose it as such or things will be > messy. I remember that drivers/pinctrl/nomadik/pinctrl-abx500.c had the same problem, but I don't remember how we solved it sadly :-/ Yours, Linus Walleij -- 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: [RFC/PATCH 1/5] mtd: ubi: Read disturb infrastructure
Am 02.10.2014 15:42, schrieb Tanya Brokhman: > How do you test all of your fastmap fixes? Some of them are not easy to > reproduce (the pq saving for example). Besides heavy stability testing, I was > testing my changes manually by > a lot of dbg prints in the code and analyzing the logs manually. Not the > optimal way I'm currently implementing a test framework for fastmap. Using it I've found many issues. I hope I can release it soon, but first some legal issues have to be resolved. 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 v3 1/2] iio: vadc: Qualcomm SPMI PMIC voltage ADC driver
On Sat, 2014-10-04 at 12:51 +0100, Jonathan Cameron wrote:
> On 02/10/14 13:08, Ivan T. Ivanov wrote:
> > +iio maintainers
> >
> > On Thu, 2014-10-02 at 12:29 +0300, Ivan T. Ivanov wrote:
> >> Hi Stan,
> >>
> >> On 09/24/2014 03:56 PM, Stanimir Varbanov wrote:
> >>
> >>
> >>
> >>> +static int vadc_get_dt_data(struct vadc_priv *vadc, struct device_node
> >>> *node)
> >>> +{
> >>> + struct iio_chan_spec *iio_chan = vadc->iio_chans;
> >>> + const struct vadc_channels *vadc_chan;
> >>> + struct vadc_channel_prop prop;
> >>> + struct device_node *child;
> >>> + int ret, index = 0;
> >>> +
> >>> + for_each_available_child_of_node(node, child) {
> >>> + ret = vadc_get_dt_channel_data(vadc->dev, &prop, child);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + vadc->chan_props[index] = prop;
> >>> +
> >>> + vadc_chan = &vadc_chans[prop.channel];
> >>> +
> >>> + iio_chan->channel = prop.channel;
> >>> + iio_chan->datasheet_name = vadc_chan->datasheet_name;
> >>> + iio_chan->info_mask_separate = vadc_chan->info_mask;
> >>> + iio_chan->type = vadc_chan->type;
> >>> + iio_chan->indexed = 1;
> >>> + iio_chan->scan_type.sign = 's';
> >>> + iio_chan->scan_type.realbits = 15;
> >>> + iio_chan->scan_type.storagebits = 16;
> >>> + iio_chan->address = index++;
> >>> +
> >>> + iio_chan++;
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>
> >>
> >>
> >>> +static int vadc_probe(struct platform_device *pdev)
> >>> +{
> >>
> >>
> >>
> >>> +
> >>> + indio_dev->dev.parent = dev;
> >>> + indio_dev->dev.of_node = node;
> >>> + indio_dev->name = pdev->name;
> >>> + indio_dev->modes = INDIO_DIRECT_MODE;
> >>> + indio_dev->info = &vadc_info;
> >>> + indio_dev->channels = vadc->iio_chans;
> >>> + indio_dev->num_channels = vadc->nchannels;
> >>
> >> This will not work as we thought. Registration will be fine and entries
> >> in sysfs are created as expected, but this is breaking numbering scheme
> >> for client drivers. For us the problem is that iio framework expect
> >> channels
> >> numbering to be linear and channel number should not be greater than
> >> channel count. For example even if die temperature channel is always 8, if
> >> I describe only 5 channels in DTS files (4 for reference points
> >> measurement)
> >> and 1 for die temperature, clients could not get OF reference to
> >> temperature
> >> channel using io-channels = <&pm8941_vadc 8>;
> >>
> >> Jonathan, please, could you advise us.
> I'd like to let the solution you proposed sit on the list a little longer.
> It seems fairly sensible, but lets see what others suggest.
Sure.
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 v5 0/4] Qualcomm SPMI PMIC pin controller drivers
On Fri, 2014-10-03 at 16:53 -0700, Bjorn Andersson wrote: > On Wed 01 Oct 09:30 PDT 2014, Ivan T. Ivanov wrote: > > This looks good and I gave it a spin on one of our 8974 devices and verified > that gpio_keys works :) > > Acked-by: Bjorn Andersson Thank you Bjorn. Regards, Ivan > > 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 v3] iio: iadc: Qualcomm SPMI PMIC current ADC driver
On Sat, 2014-10-04 at 13:03 +0100, Jonathan Cameron wrote: > On 01/10/14 17:14, Ivan T. Ivanov wrote: > > The current ADC is peripheral of Qualcomm SPMI PMIC chips. It has > > 16 bits resolution and register space inside PMIC accessible across > > SPMI bus. > > > > The driver registers itself through IIO interface. > > > > Signed-off-by: Ivan T. Ivanov > Looks good to me. I would however like to wait for Mark Rutland to > say whether he is happy with the bindings (and the rest if he > feels like it ;) > > Given the merge window will open shortly and hence the IIO merge > window is long closed, we aren't in a particular rush at the moment. Sure. Thank you. Ivan > > > Jonathan -- 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/2] input: Add Qualcomm PM8941 power key driver
On Tuesday 07 October 2014 06:42 AM, Bjorn Andersson wrote:
> From: Courtney Cavin
>
> Signed-off-by: Courtney Cavin
> Signed-off-by: Bjorn Andersson
> ---
> drivers/input/misc/Kconfig | 12 +++
> drivers/input/misc/Makefile|1 +
> drivers/input/misc/pm8941-pwrkey.c | 196
>
> +
> + platform_set_drvdata(pdev, pwrkey);
> + device_init_wakeup(&pdev->dev, 1);
> +
> + return 0;
> +}
> +
> +static int pm8941_pwrkey_remove(struct platform_device *pdev)
> +{
> + device_init_wakeup(&pdev->dev, 0);
Shouldn't we unregister input device?
> +
> + return 0;
> +}
> +
> +static const struct of_device_id pm8941_pwr_key_id_table[] = {
> + { .compatible = "qcom,pm8941-pwrkey" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, pm8941_pwr_key_id_table);
> +
> +static struct platform_driver pm8941_pwrkey_driver = {
> + .probe = pm8941_pwrkey_probe,
> + .remove = pm8941_pwrkey_remove,
> + .driver = {
> + .name = "pm8941-pwrkey",
> + .owner = THIS_MODULE,
This field can be removed because this driver which use the
module_platform_driver api as this is overridden in
platform_driver_register.
> + .pm = &pm8941_pwr_key_pm_ops,
> + .of_match_table = of_match_ptr(pm8941_pwr_key_id_table),
> + },
> +};
> +module_platform_driver(pm8941_pwrkey_driver);
> +
> +MODULE_DESCRIPTION("PM8941 Power Key driver");
> +MODULE_LICENSE("GPL v2");
May be you can add module author name.
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
[PATCH 3/4] Input: pmic8xxx-keypad - add support keypad found in pm8941
Controller seems to be the same. Just access to it is over SPMI bus
and registers and bits are reshuffled. Hopefully this is nicely
abstracted by regmap helpers.
Signed-off-by: Ivan T. Ivanov
---
.../bindings/input/qcom,pm8xxx-keypad.txt | 1 +
drivers/input/keyboard/pmic8xxx-keypad.c | 27 ++
2 files changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
index 7d8cb92..2b60f8a 100644
--- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
@@ -8,6 +8,7 @@ PROPERTIES
Definition: must be one of:
"qcom,pm8058-keypad"
"qcom,pm8921-keypad"
+ "qcom,pm8941-keypad"
- reg:
Usage: required
diff --git a/drivers/input/keyboard/pmic8xxx-keypad.c
b/drivers/input/keyboard/pmic8xxx-keypad.c
index b82d161..2d4fa07 100644
--- a/drivers/input/keyboard/pmic8xxx-keypad.c
+++ b/drivers/input/keyboard/pmic8xxx-keypad.c
@@ -136,6 +136,32 @@ static const struct pmic8xxx_kp_info ssbi_kp = {
.row_hold = REG_FIELD(0x149, 6, 7),
};
+static const struct pmic8xxx_kp_info spmi_kp = {
+ .max_rows = 10,
+ .min_rows = 2,
+ .max_cols = 8,
+ .min_cols = 1,
+
+ .rows_select = {
+ 1, 2, 3, 4, 5, 6, 7,
+ 8, 9, 10
+ },
+
+ .recent_data= 0xa87c,
+ .old_data = 0xa85c,
+ .read_stride= 2,
+
+ .events = REG_FIELD(0xa808, 0, 1),
+ .scan_rows = REG_FIELD(0xa840, 0, 3),
+ .scan_cols = REG_FIELD(0xa840, 4, 6),
+ .enable = REG_FIELD(0xa846, 7, 7),
+
+ .read_state = REG_FIELD(0xa844, 0, 0),
+ .dbonce = REG_FIELD(0xa842, 0, 1),
+ .pause = REG_FIELD(0xa842, 3, 5),
+ .row_hold = REG_FIELD(0xa842, 6, 7),
+};
+
static u8 pmic8xxx_col_state(struct pmic8xxx_kp *kp, u8 col)
{
/* all keys pressed on that particular row? */
@@ -715,6 +741,7 @@ static SIMPLE_DEV_PM_OPS(pm8xxx_kp_pm_ops,
static const struct of_device_id pm8xxx_match_table[] = {
{ .compatible = "qcom,pm8058-keypad", .data = (void *)&ssbi_kp },
{ .compatible = "qcom,pm8921-keypad", .data = (void *)&ssbi_kp },
+ { .compatible = "qcom,pm8941-keypad", .data = (void *)&spmi_kp },
{ }
};
MODULE_DEVICE_TABLE(of, pm8xxx_match_table);
--
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] Input: pmic8xxx-keypad - update DT bindings documentation
Fix incorrect dimensions for 'debonce' and 'scan-delay' times. Now they represent what driver really expect. Add possible time quants for 'debonce', 'scan-delay' and 'row-hold' times. Update bindings example. Signed-off-by: Ivan T. Ivanov --- Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt index 2b60f8a..df5e2a1 100644 --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt @@ -54,20 +54,23 @@ PROPERTIES - debounce: Usage: optional Value type: - Definition: time in microseconds that key must be pressed or release + Definition: time in miliseconds that key must be pressed or release for key sense interrupt to trigger. + Possible values: 5, 10, 15, 20. - scan-delay: Usage: optional Value type: - Definition: time in microseconds to pause between successive scans + Definition: time in miliseconds to pause between successive scans of the matrix array. + Possible values: 1, 2, 4, 8, 16, 32, 64, 128. - row-hold: Usage: optional Value type: Definition: time in nanoseconds to pause between scans of each row in the matrix array. + Possible values: 30500, 61000, 122000. EXAMPLE @@ -86,5 +89,5 @@ EXAMPLE keypad,num-columns = <5>; debounce = <15>; scan-delay = <32>; - row-hold = <91500>; + row-hold = <61000>; }; -- 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] Input: pmic8xxx-keypad - use regmap_field for register access
Abstract access to bit and register definitions to simplify adding
support for similar controller, which be found on SPMI based pm8941.
Group hardware capabilities to controller specific structure, and
pass it to driver, based on compatible string.
Pre-compute minimum number of rows and columns to avoid runtime checks.
Signed-off-by: Ivan T. Ivanov
---
drivers/input/keyboard/pmic8xxx-keypad.c | 260 ++-
1 file changed, 154 insertions(+), 106 deletions(-)
diff --git a/drivers/input/keyboard/pmic8xxx-keypad.c
b/drivers/input/keyboard/pmic8xxx-keypad.c
index dd1fc95..b82d161 100644
--- a/drivers/input/keyboard/pmic8xxx-keypad.c
+++ b/drivers/input/keyboard/pmic8xxx-keypad.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#define PM8XXX_MAX_ROWS18
@@ -28,9 +29,6 @@
#define PM8XXX_ROW_SHIFT 3
#define PM8XXX_MATRIX_MAX_SIZE (PM8XXX_MAX_ROWS * PM8XXX_MAX_COLS)
-#define PM8XXX_MIN_ROWS5
-#define PM8XXX_MIN_COLS5
-
#define MAX_SCAN_DELAY 128
#define MIN_SCAN_DELAY 1
@@ -41,34 +39,34 @@
#define MAX_DEBOUNCE_TIME 20
#define MIN_DEBOUNCE_TIME 5
-#define KEYP_CTRL 0x148
-
-#define KEYP_CTRL_EVNTS_MASK 0x3
-
-#define KEYP_CTRL_SCAN_COLS_SHIFT 5
-#define KEYP_CTRL_SCAN_COLS_MIN5
-#define KEYP_CTRL_SCAN_COLS_BITS 0x3
-
-#define KEYP_CTRL_SCAN_ROWS_SHIFT 2
-#define KEYP_CTRL_SCAN_ROWS_MIN5
-#define KEYP_CTRL_SCAN_ROWS_BITS 0x7
-
-#define KEYP_CTRL_KEYP_EN BIT(7)
-
-#define KEYP_SCAN 0x149
-
-#define KEYP_SCAN_DBOUNCE_SHIFT1
-#define KEYP_SCAN_PAUSE_SHIFT 3
-#define KEYP_SCAN_ROW_HOLD_SHIFT 6
-
-/* bits of these registers represent
- * '0' for key press
- * '1' for key release
- */
-#define KEYP_RECENT_DATA 0x14B
-#define KEYP_OLD_DATA 0x14C
-
-#define KEYP_CLOCK_FREQ32768
+#define KEYP_CLOCK_FREQ32768
+
+/* Keypad capabilities and registers description */
+struct pmic8xxx_kp_info {
+ unsigned int max_rows;
+ unsigned int min_rows;
+ unsigned int max_cols;
+ unsigned int min_cols;
+
+ unsigned int rows_select[PM8XXX_MAX_ROWS];
+ /*
+* bits of these registers represent
+* '0' for key press
+* '1' for key release
+*/
+ unsigned int recent_data;
+ unsigned int old_data;
+ unsigned int read_stride;
+
+ struct reg_field events;
+ struct reg_field scan_rows;
+ struct reg_field scan_cols;
+ struct reg_field enable;
+ struct reg_field read_state;
+ struct reg_field dbonce;
+ struct reg_field pause;
+ struct reg_field row_hold;
+};
/**
* struct pmic8xxx_kp - internal keypad data structure
@@ -98,7 +96,44 @@ struct pmic8xxx_kp {
u16 keystate[PM8XXX_MAX_ROWS];
u16 stuckstate[PM8XXX_MAX_ROWS];
- u8 ctrl_reg;
+ struct regmap_field *events;
+ struct regmap_field *scan_rows;
+ struct regmap_field *scan_cols;
+ struct regmap_field *enable;
+ struct regmap_field *read_state;
+ struct regmap_field *dbonce;
+ struct regmap_field *pause;
+ struct regmap_field *row_hold;
+
+ unsigned int recent_data;
+ unsigned int old_data;
+ unsigned int read_stride;
+};
+
+static const struct pmic8xxx_kp_info ssbi_kp = {
+ .max_rows = 18,
+ .min_rows = 5,
+ .max_cols = 8,
+ .min_cols = 5,
+
+ .rows_select = {
+ 0, 1, 2, 3, 4, 4, 5,
+ 5, 6, 6, 6, 7, 7, 7,
+ },
+
+ .recent_data= 0x14b,
+ .old_data = 0x14c,
+ .read_stride= 0,
+
+ .events = REG_FIELD(0x148, 0, 1),
+ .scan_rows = REG_FIELD(0x148, 2, 4),
+ .scan_cols = REG_FIELD(0x148, 5, 6),
+ .enable = REG_FIELD(0x148, 7, 7),
+
+ .read_state = REG_FIELD(0x149, 0, 0),
+ .dbonce = REG_FIELD(0x149, 1, 2),
+ .pause = REG_FIELD(0x149, 3, 5),
+ .row_hold = REG_FIELD(0x149, 6, 7),
};
static u8 pmic8xxx_col_state(struct pmic8xxx_kp *kp, u8 col)
@@ -125,17 +160,8 @@ static u8 pmic8xxx_col_state(struct pmic8xxx_kp *kp, u8
col)
static int pmic8xxx_chk_sync_read(struct pmic8xxx_kp *kp)
{
int rc;
- unsigned int scan_val;
-
- rc = regmap_read(kp->regmap, KEYP_SCAN, &scan_val);
- if (rc < 0) {
- dev_err(kp->dev, "Error reading KEYP_SCAN reg, rc=%d\n", rc);
- return rc;
- }
-
- scan_val |= 0x1;
- rc = regmap_write(kp->regmap, KEYP_SCAN, scan_val);
+ rc = regmap_field_write(kp->read_state, 1);
if (rc < 0) {
dev_err(kp->dev, "Error writing KEYP_SCAN reg, rc=%d\n", rc);
return rc;
@@ -151,10 +177
[PATCH 1/4] Input: pmic8xxx-keypad - remove unused register and bit definitions
These defines are not used by driver. Remove them. Signed-off-by: Ivan T. Ivanov --- drivers/input/keyboard/pmic8xxx-keypad.c | 12 1 file changed, 12 deletions(-) diff --git a/drivers/input/keyboard/pmic8xxx-keypad.c b/drivers/input/keyboard/pmic8xxx-keypad.c index 80c6b0e..dd1fc95 100644 --- a/drivers/input/keyboard/pmic8xxx-keypad.c +++ b/drivers/input/keyboard/pmic8xxx-keypad.c @@ -43,7 +43,6 @@ #define KEYP_CTRL 0x148 -#define KEYP_CTRL_EVNTSBIT(0) #define KEYP_CTRL_EVNTS_MASK 0x3 #define KEYP_CTRL_SCAN_COLS_SHIFT 5 @@ -58,21 +57,10 @@ #define KEYP_SCAN 0x149 -#define KEYP_SCAN_READ_STATE BIT(0) #define KEYP_SCAN_DBOUNCE_SHIFT1 #define KEYP_SCAN_PAUSE_SHIFT 3 #define KEYP_SCAN_ROW_HOLD_SHIFT 6 -#define KEYP_TEST 0x14A - -#define KEYP_TEST_CLEAR_RECENT_SCANBIT(6) -#define KEYP_TEST_CLEAR_OLD_SCAN BIT(5) -#define KEYP_TEST_READ_RESET BIT(4) -#define KEYP_TEST_DTEST_EN BIT(3) -#define KEYP_TEST_ABORT_READ BIT(0) - -#define KEYP_TEST_DBG_SELECT_SHIFT 1 - /* bits of these registers represent * '0' for key press * '1' for key release -- 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 0/4] Input: pmic8xxx-keypad - add support for pm8941 keypad
Hi, Following set of patches reorganize and add support for keypad controller found in Qualcomm PMIC pm8941 chip, at least. Controllers found in pm8058 and pm8921, currently supported by driver, seems to be similar to controller found in pm8941. Difference is register access, SSBI vs SPMI bus, registers offsets and bit definitions. To be able to easily add support for new controller, driver have been converted to use struct regmap_field. Regards, Ivan Ivan T. Ivanov (4): Input: pmic8xxx-keypad - remove unused register and bit definitions Input: pmic8xxx-keypad - use regmap_field for register access Input: pmic8xxx-keypad - add support keypad found in pm8941 Input: pmic8xxx-keypad - update DT bindings documentation .../bindings/input/qcom,pm8xxx-keypad.txt | 10 +- drivers/input/keyboard/pmic8xxx-keypad.c | 299 + 2 files changed, 188 insertions(+), 121 deletions(-) -- 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 0/2] Qualcomm PM8941 power key driver
Hi Bjorn, On Mon, 2014-10-06 at 18:11 -0700, Bjorn Andersson wrote: > These patches add dt bindings and a device driver for the power key block in > the Qualcomm PM8941 pmic. > > Courtney Cavin (2): > input: Add Qualcomm PM8941 power key driver > input: pm8941-pwrkey: Add DT binding documentation > > .../bindings/input/qcom,pm8941-pwrkey.txt | 43 + > drivers/input/misc/Kconfig | 12 ++ > drivers/input/misc/Makefile|1 + > drivers/input/misc/pm8941-pwrkey.c | 196 > > 4 files changed, 252 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt > create mode 100644 drivers/input/misc/pm8941-pwrkey.c Any reason why we cannot reuse pm8xxx-pwrkey driver? It have been converted to regmap already. 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
