On Thu, Oct 11, 2018 at 10:58:22AM -0600, Lina Iyer wrote:DDR, shared clocks, regulators etc. Imagine you are running something on
On Thu, Oct 11 2018 at 10:19 -0600, Sudeep Holla wrote:
> On Thu, Oct 11, 2018 at 10:00:53AM -0600, Lina Iyer wrote:
> > Sudeep,
> > The CPU PD does not power off the domain from Linux. That is done from
> > PSCI firmware (ATF). These patches are doing the part that Linux has do,
> > when powering off the CPUs, to achieve a low standby power consumption.
> I don't understand why Linux *has do* this part as PSCI manages CPU PM.
If we don't do this, then we leave a lot of power saving on the table,
when the CPU powered off. Why should the DDR and the shared busses and
clocks be idling at high power, when not needed ? PSCI has no clue to
what resource requests was made my Linux and its Linux's responsibility
to relinquish them when not needed. Therefore has to done from Linux.
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.
Yes, the last CPU is what we are getting to with this series.. Now thisEven with all the unnecessary flushing it is totally worth it. OSI helps
alleviates this a bit because it embodies the same CPU PD concepts at
its core. Imagine if you didn't have CPU PM domain, the every CPU would
be flushing RPMH request, whenever they power down, because you never know
when all CPUs are going to be powered down at the same time. That is the
biggest benefit of OSI over PC mode in PSCI.
I am not saying every CPU needs to do that, last CPU can do that in PSCI.
Oh interesting, wasn't aware RPMH really needs to care about exceptionSome resources are secure resources used in secure environments. They
level. For me, we know CPU is powering down, so it needs to release all
the resource. RPMH needs to know that and any exception level can let
RPMH know that. Sorry may be I don't have enough knowledge on SDM SoC.
We are far from it, for that, atleast now. But we will get there.Yes, we are close to having a platform have both, possibly.
Comparison numbers please :)
Having to adapt DT to the firmware though the feature is fully discoverableThe firmware is ATF and does not support OSI.
is not at all good IMO. So the DT in this series *should work* with OSI
mode if the firmware has the support for it, it's as simple as that.