On Fri, Oct 12 2018 at 11:01 -0600, Sudeep Holla wrote:
On Fri, Oct 12, 2018 at 10:04:27AM -0600, Lina Iyer wrote:
On Fri, Oct 12 2018 at 09:04 -0600, Sudeep Holla wrote:
[...]
Yes all these are fine but with multiple power-domains/cluster, it's
hard to determine the first CPU. You may be able to identify it within
the power domain but not system wide. So this doesn't scale with large
systems(e.g. 4 - 8 clusters with 16 CPUs).
We would probably not worry too much about power savings in a msec
scale, if we have that big a system. The driver is a platform specific
driver, primarily intended for a mobile class CPU and usage. In fact, we
haven't done this for QC's server class CPUs.
> I think we are mixing the system sleep states with CPU idle here.
> If it's system sleeps states, the we need to deal it in some system ops
> when it's the last CPU in the system and not the cluster/power domain.
>
I think the confusion for you is system sleep vs suspend. System sleep
here (probably more of a QC terminology), refers to powering down the
entire SoC for very small durations, while not actually suspended. The
drivers are unaware that this is happening. No hotplug happens and the
interrupts are not migrated during system sleep. When all the CPUs go
into cpuidle, the system sleep state is activated and the resource
requirements are lowered. The resources are brought back to their
previous active values before we exit cpuidle on any CPU. The drivers
have no idea that this happened. We have been doing this on QCOM SoCs
for a decade, so this is not something new for this SoC. Every QCOM SoC
has been doing this, albeit differently because of their architecture.
The newer ones do most of these transitions in hardware as opposed to an
remote CPU. But this is the first time, we are upstreaming this :)
Indeed, I know mobile platforms do such optimisations and I agree it may
save power. As I mentioned above it doesn't scale well with large systems
and also even with single power domains having multiple idle states where
only one state can do this system level idle but not all. As I mentioned
in the other email to Ulf, it's had to generalise this even with DT.
So it's better to have this dealt transparently in the firmware.
Good, then we are on agreement here.
But this is how this platform is. It cannot be done in firmware and what
we doing here is a Linux platform driver that cleans up nicely without
having to piggy back on an external dependency.
Thanks,
Lina
