Re: [PATCH RFC 3/3] PM / Domains: Introduce generic PM domain for cpu domain

On 11.06.2015 01:57, Lina Iyer wrote:

On Sun, Jun 07 2015 at 03:43 -0600, Krzysztof Kozlowski wrote:

quoted

W dniu 05.06.2015 o 07:29, Lina Iyer pisze:

quoted

Generally cpus are grouped under a power domain in a SoC. When all cpus
in the domain are in their power off state,

What do you exactly mean here by "CPU in power off state"? How does it
map to kernel understanding of CPU device (hotplug? cpuidle?)?

Both cpuidle and hotplug could end with with core being powered down at
the platform driver or at PSCI (on V8). It does not matter which of
these two frameworks resulted in the cpu being powered off. But, if all
cpus in the domain are powered off, then the domain could be powered off
as well. This is the premise of this change. It is probably easier to
power off the domain when the cores in that domain/cluster have been
hotplugged off. It saves power to turn off the domain at that time, but
more power savings can be achieved if the domain could also be powered
off during cpuidle. Hotplug is not a common occurance, while cpuidle is.

OK, it answers my questions, thanks.

quoted

quoted

the cpu domain can also be
powered off. Genpd provides the framework for defining cpus as devices
that are part of a cpu domain.

The problem which is solved looks to me like the same problem which
coupled cpuidle tried to solve: a certain deep sleep mode (e.g. power
off) can be entered when whole cluster is idle or other CPUs in cluster
are powered off completely.

It seems a little like duplicating the effort around coupled cpuidle.

I see where are you are going with this, but genpd solution is not
exactly a duplicate of the solution.

Couple state is used to put the cpus in a deeper sleep state, which
could also result in powering off the domain. Coupled cpuidle is a
cpuidle mechanism for choosing a deeper sleep mode on certain hardware
that can only enter such a mode when all cpus cooperate.

This patch attempts to describe the backend of a cpu domain. CPUs are
responsible for individual cpuidle states, cpus do enter their
recommended deepest idle state at the time of no activity. A cpu-domain
could be comprised of cpus, and other devices like GIC, busses etc, that
all need to idle before the domain can be powered off. This patch does
not dictate which idle state any those devices should enter, or
coordinate the idle states between devices. But, if cpus, choose to
power down, then this patch recognizes that and reduces the reference
usage count on the domain. Only when all devices in the domain remove
their usage count, will the domain be powered off.

It would be nice to see the usage of this patch in cpuidle driver or
platform code but I think I get the idea.

Actually I like the approach.
I am thinking how to utilize it to replace coupled cpuidle for our case.
In our case we use coupled cpuidle because the SoC can be put in low
power mode only if non-boot CPUs are powered down.

However in our case:
1. Some other devices (buses, clocks) also should be idle. This would
perfectly match with this patch and with runtime PM.

2. Some non-boot idle CPU could power itself down but it cannot wake up.
Only the alive CPU can wake others. This probably means that we cannot
provide a cpuidle driver which will power off unused cores and then, if
boot CPU is idle, disable the CPU power domain by entering to low power
mode.

Anyway, as I said, I like the approach.

There are two things this patch provides -

i. A generic way to initialize a genpd specifically for cpus. (The
platform specifies the relation between a cpu and its domain in the DT
and provides the memory for the genpd structure)

ii. On behalf of a platform, we track when the cpus power up and down
and use runtime_get and runtime_put on the genpd.

Unlike coupled cpuidle, individual cpu idle state is not manipulated.
Coupled cpuidle does not care if the domain is powered off, it is used
to allow a certain C-state for the cpu, based on the idleness of other
cpus in that cluster. The focus of the series is powering down the
domain when the devices (cpus included) are powered off. You could see
this patch as a cpu-pm and runtime-pm interface layer.

Hope that helps.

Thanks,
Lina

Best regards,
Krzysztof