[adding Kevin Hilman as cc who was also interested in CPUidle for Exynos] Hello Krzysztof, On 08/23/2015 03:26 AM, Krzysztof Kozlowski wrote: [snip] > 2015-08-21 16:21 GMT+09:00 Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx>: > > The big.LITTLE cpuidle driver is not a typical Exynos cpuidle driver. > It only executes CPU suspend on a cluster which essentially is a power > down operation. > You are correct, looking at the the big.LITTLE CPUidle driver I see that it only has two C-states: C0 (normal WFI) and C1 (single CPU power-down) which as you said, places the CPU into power-down mode by using the MCPM infrastructure so it's basically a CPU suspend AFAIU. So what you are saying is that there are deeper C-states supported by the Exynos 542x SoC family but these are not handled by the b.L CPUidle driver. > When we talk about cpuidle on Exynos, we have in mind one of sleep > modes: AFTR or LPA (sometimes instead of LPA there is LPD or W-AFTR). > Actually this is more like a system idle mode, not CPU idle. The power > savings are much bigger than disabling only one cluster. > Interesting, I was not aware of AFTR and LPA but I looked in the manual now. Thanks a lot for the information. I see that the Exynos CPUidle driver (drivers/cpuidle/cpuidle-exynos.c) also has only two C-states (WFI and C1) but C1 makes the system to enter in AFTR (system-level power gating). This is similar to what the downstream ChromiumOS 3.8 kernel CPUidle driver does IIUC [0]. > So the question is still valid - whether someone wants or plans to > implement cpuidle for Exynos 542x family. Odroid XU3 is not a priority > here because energy consumption is not an issue there. This is not a > mobile device. > That's true but it will be interesting for the 5420 and 5800 based Chromebooks since optimizing power consumption would be useful there. I thought that big.LITTLE platforms were encouraged to use the generic b.L CPUidle driver just like DT platforms should use the generic CPUFreq DT driver but I guess I misunderstood. So the b.L CPUidle driver is only to have minimum CPUidle support but a SoC specific driver is needed to fine tune and get most out of the platform? Or should the b.L CPUidle driver be extended to add per platform C-states? > Best regards, > Krzysztof > [0]: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/cpuidle.c Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |