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

[Lina Iyer]

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