On Tue, Sep 30, 2014 at 10:51 AM, Nicolas Pitre <nicolas.pitre@xxxxxxxxxx> wrote: > On Tue, 30 Sep 2014, Kevin Hilman wrote: > >> Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> writes: >> >> > 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.iyer@xxxxxxxxxx> >> >> --- >> >> .../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 0000000..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. >> >> This gets at a little pet peeve of mine: >> >> IMO, naming any state with "WFI" is a bit confusing, because typically >> *every* idle state is entered by one (or more) CPU executing WFI, no? > > Agreed. > > The only state called "WFI" should be the one that only executes the WFI > instruction without any other hardware setup around it. Well, I would go even further in that none of the states should be called WFI, because WFI is used to enter all of them. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
