+ Gabriel, Alexandre
On Tue, 22 Nov 2022 at 12:38, Ulf Hansson ulf.hansson@linaro.org wrote:
- Vincent, Daniel
On Mon, 21 Nov 2022 at 21:12, Sudeep Holla sudeep.holla@arm.com wrote:
On Mon, Nov 21, 2022 at 11:57:30AM -0800, Wing Li wrote:
+Ulf Hansson ulf.hansson@linaro.org and +Jens Wiklander jens.wiklander@linaro.org, who are able to help with testing.
Hi Sudeep and Jacky,
I wanted to clarify our use case for suspend-to-idle. For mobile and other battery-powered devices, the key capability we need isn't just the ability to enter s2idle, but also reaching equivalent power savings in s2idle compared to suspend-to-RAM. Essentially, if all CPU cores are idle, we want to be able to drop into the deepest low-power state that is just as energy-efficient as suspend-to-RAM, but without hot-unplugging and plugging the CPUs, which means they need to be able to resume in their idle loops. To achieve this, we're planning to leverage the hierarchical power domain representation in the device tree [1], which is currently limited to be used in OS-initiated mode by the PSCI CPUIdle driver [2].
OK, so your choice is OSI and it has nothing to do with S2I not working with PC mode cpuidle. The statement that Linux S2I requires OSI mode of cpuidle was misleading and main trigger for most of these discussions.
Right, I completely agree with the above. S2I isn't limited to work with the OSI-mode. In fact, I believe we should have platforms that support only the PC mode, which already support S2I.
That said, I strongly support the implementation of the OSI-mode in TF-A. Besides Google, there should be at least two more ARM vendors that I expect to be interested in this. Let me reach out to them (offlist), to see if they are able to help with some platform deployments and tests. I personally can try to help by running tests on the old Hikey platform, for example.
Our friends at STMicro have been helping out with review and testing (discussion offlist).
Let me loop them in here to let them update us on their work.
When it comes to running performance/energy comparisons, that would certainly be nice, as we have discussed earlier too. If we manage to land the OSI support in the TF-A, I think we should consider that as the first step to enable us to run these kinds of tests.
Note that, to really make some valid comparisons, I don't think Hikey is going to be a good example, but I may be wrong. Instead, I think we need a platform that takes full benefit of what OSI really provides, which means using the information at the Linux (RichOS) side to make better decisions in the idlepath. So far, there are only Qcom platforms that try to implement this in the upstream Linux kernel (I can provide more pointers to this, if anyone wants - just tell me).
Kind regards Uffe