On Fri, Oct 12 2018 at 09:46 -0600, Ulf Hansson wrote:
On 12 October 2018 at 17:04, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
On Thu, Oct 11, 2018 at 03:06:09PM -0600, Lina Iyer wrote:
On Thu, Oct 11 2018 at 11:37 -0600, Sudeep Holla wrote:
[...]
>
> Is DDR managed by Linux ? I assumed it was handled by higher exception
> levels. Can you give examples of resources used by CPU in this context.
> When CPU can be powered on or woken up without Linux intervention, the
> same holds true for CPU power down or sleep states. I still see no reason
> other than the firmware has no support to talk to RPMH.
>
DDR, shared clocks, regulators etc. Imagine you are running something on
the screen and CPUs enter low power mode, while the CPUs were active,
there was a need for bunch of display resources, and things the app may
have requested resources, while the CPU powered down the requests may
not be needed the full extent as when the CPU was running, so they can
voted down to a lower state of in some cases turn off the resources
completely. What the driver voted for is dependent on the runtime state
and the usecase currently active. The 'sleep' state value is also
determined by the driver/framework.
Why does CPU going down says that another (screen - supposedly shared)
resource needs to be relinquished ? Shouldn't display decide that on it's
own ? I have no idea why screen/display is brought into this discussion.
CPU can just say: hey I am going down and I don't need my resource.
How can it say: hey I am going down and display or screen also doesn't
need the resource. On a multi-cluster, how will the last CPU on one know
that it needs to act on behalf of the shared resource instead of another
cluster.
Apologize for sidetracking the discussion, just want to fold in a few comments.
No, this is perfect to warp the whole thing around. Thanks Ulf.
This is becoming a complicated story. May I suggest we pick the GIC as
an example instead?
Let's assume the simple case, we have one cluster and when the cluster
becomes powered off, the GIC needs to be re-configured and wakeups
must be routed through some "always on" external logic.
The PSCI spec mentions nothing about how to manage this and not the
rest of the SoC topology for that matter. Hence if the GIC is managed
by Linux - then Linux also needs to take actions before cluster power
down and after cluster power up. So, if PSCI FW can't deal with GIC,
how would manage it?
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.
What is really a system sleep state? One could consider it just being
another idles state, having heaver residency targets and greater
enter/exit latency values, couldn't you?
While I explained the driver's side of the story, for the CPUs, system
sleep is a deeper low power mode that ties in with OSI.
Thanks,
Lina
In the end, there is no reason to keep things powered on, unless they
are being in used (or soon to be used), that is main point.
We are also working on S2I at Linaro. We strive towards being able to
show the same power numbers as for S2R, but then we need to get these
cluster-idle things right.
[...]
Have a nice weekend!
Kind regards
Uffe
