Re: [PATCH RFC v1 7/8] drivers: qcom: cpu_pd: Handle cpu hotplug in the domain

[Lina Iyer]

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