Thomas Schlichter reports the following issue on his Samsung NC20: "The C-states C1 and C2 to the OS when connected to AC, and additionally provides the C3 C-state when disconnected from AC. However, the number of C-states shown in sysfs is fixed to the number of C-states present at boot. If I boot with AC connected, I always only see the C-states up to C2 even if I disconnect AC. The reason is commit 130a5f692425 (ACPI / cpuidle: remove dev->state_count setting). It removes the update of dev->state_count, but sysfs uses exactly this variable to show the C-states. The fix is to use drv->state_count in sysfs. As this is currently the last user of dev->state_count, this variable can be completely removed." Remove dev->state_count as per the above. Reported-by: Thomas Schlichter <thomas.schlichter@web.de> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Originally, the thresholds used in the cpuidle driver for Armada SOCs
were temporarily chosen, leaving room for improvements.
This commit updates the thresholds for the Armada XP SOCs with values
that positively impact performances:
without patch with patch vendor kernel
- iperf localhost (gbit/sec) ~3.7 ~6.4 ~5.4
- ioping tmpfs (iops) ~163k ~206k ~179k
- ioping tmpfs (mib/s) ~636 ~805 ~699
The idle power consumption is negatively impacted (proportionally less
than the performance gain), and we are still performing better than
the vendor kernel here:
without patch with patch vendor kernel
- power consumption idle (W) ~2.4 ~3.2 ~4.4
- power consumption busy (W) ~8.6 ~8.3 ~8.6
There is still room for improvement regarding the value of these
thresholds, they were chosen to mimic the vendor kernel.
This patch only impacts Armada XP SOCs and was tested on Online Labs
C1 boards. A similar approach can be taken to improve the performances
of the Armada 370 and Armada 38x SOCs.
Thanks a lot to Thomas Petazzoni, Gregory Clement and Willy Tarreau
for the discussions and tips around this topic.
Signed-off-by: Sebastien Rannou <mxs@sbrk.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
As stated in kernel/cpu_pm.c, "Platform is responsible for ensuring that cpu_pm_enter is not called twice on the same CPU before cpu_pm_exit is called.". In the current code in case of failure when calling mvebu_v7_cpu_suspend, the function cpu_pm_exit() is never called whereas cpu_pm_enter() was called just before. This patch moves the cpu_pm_exit() in order to balance the cpu_pm_enter() calls. Cc: stable@vger.kernel.org Reported-by: Fulvio Benini <fbf@libero.it> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Commit 381063133246 (PM / sleep: Re-implement suspend-to-idle handling) overlooked the fact that entering some sufficiently deep idle states by CPUs may cause their local timers to stop and in those cases it is necessary to switch over to a broadcast timer prior to entering the idle state. If the cpuidle driver in use does not provide the new ->enter_freeze callback for any of the idle states, that problem affects suspend-to-idle too, but it is not taken into account after the changes made by commit 381063133246. Fix that by changing the definition of cpuidle_enter_freeze() and re-arranging of the code in cpuidle_idle_call(), so the former does not call cpuidle_enter() any more and the fallback case is handled by cpuidle_idle_call() directly. Fixes: 381063133246 (PM / sleep: Re-implement suspend-to-idle handling) Reported-and-tested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Modify cpuidle_enter_freeze() to do the sanity checks done by cpuidle_select() to avoid crashing the suspend-to-idle code path in case something is missing. Fixes: 381063133246 (PM / sleep: Re-implement suspend-to-idle handling) Original-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Disabling interrupts at the end of cpuidle_enter_freeze() is not useful, because its caller, cpuidle_idle_call(), re-enables them right away after invoking it. To avoid that unnecessary back and forth dance with interrupts, make cpuidle_enter_freeze() enable interrupts after calling enter_freeze_proper() and drop the local_irq_disable() at its end, so that all of the code paths in it end up with interrupts enabled. Then, cpuidle_idle_call() will not need to re-enable interrupts after calling cpuidle_enter_freeze() any more, because the latter will return with interrupts enabled, in analogy with cpuidle_enter(). Reported-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
* pnp: PNP: Switch from __check_region() to __request_region() * pm-cpuidle: cpuidle: powernv: Avoid endianness conversions while parsing DT cpuidle: powernv: Read target_residency value of idle states from DT if available * pm-cpufreq: cpufreq: s3c: remove last use of resume_clocks callback cpufreq: s3c: remove incorrect __init annotations
We currently read the information about idle states from the DT so as to populate the cpuidle table. Use those APIs to read from the DT that can avoid endianness conversions of the property values in the cpuidle driver. Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The device tree now exposes the residency values for different idle states. Read these values instead of calculating residency from the latency values. The values exposed in the DT are validated for optimal power efficiency. However to maintain compatibility with the older firmware code which does not expose residency values, use default values as a fallback mechanism. While at it, use better APIs to parse the powermgmt device tree node. Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com> Acked-by: Stewart Smith <stewart@linux.vnet.ibm.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull suspend-to-idle updates from Rafael Wysocki: "Suspend-to-idle timer quiescing support for v3.20-rc1 Until now suspend-to-idle has not been able to save much more energy than runtime PM because of timer interrupts that periodically bring CPUs out of idle while they are waiting for a wakeup interrupt. Of course, the timer interrupts are not wakeup ones, so the handling of them can be deferred until a real wakeup interrupt happens, but at the same time we don't want to mass-expire timers at that point. The solution is to suspend the entire timekeeping when the last CPU is entering an idle state and resume it when the first CPU goes out of idle. That has to be done with care, though, so as to avoid accessing suspended clocksources etc. end we need extra support from idle drivers for that. This series of commits adds support for quiescing timers during suspend-to-idle and adds the requisite callbacks to intel_idle and the ACPI cpuidle driver" * tag 'suspend-to-idle-3.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / idle: Implement ->enter_freeze callback routine intel_idle: Add ->enter_freeze callbacks PM / sleep: Make it possible to quiesce timers during suspend-to-idle timekeeping: Make it safe to use the fast timekeeper while suspended timekeeping: Pass readout base to update_fast_timekeeper() PM / sleep: Re-implement suspend-to-idle handling