Date:   Thu, 11 Oct 2018 10:58:22 -0600
From:   Lina Iyer <ilina@...eaurora.org>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     "Raju P.L.S.S.S.N" <rplsssn@...eaurora.org>, andy.gross@...aro.org,
        david.brown@...aro.org, rjw@...ysocki.net, ulf.hansson@...aro.org,
        khilman@...nel.org, linux-arm-msm@...r.kernel.org,
        linux-soc@...r.kernel.org, rnayak@...eaurora.org,
        bjorn.andersson@...aro.org, linux-kernel@...r.kernel.org,
        linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
        sboyd@...nel.org, evgreen@...omium.org, dianders@...omium.org,
        mka@...omium.org, Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Subject: Re: [PATCH RFC v1 7/8] drivers: qcom: cpu_pd: Handle cpu hotplug in
 the domain

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.

>> On Thu, Oct 11 2018 at 05:20 -0600, Sudeep Holla wrote:
>> > On Thu, Oct 11, 2018 at 02:50:54AM +0530, Raju P.L.S.S.S.N wrote:
>> > > Use cpu hotplug callback mechanism to attach/dettach the cpu in
>> > > the cpu power domain. During cpu hotplug callback registration,
>> > > the starting callback is invoked on all online cpus. So there is
>> > > no need to attach from device probe.
>> > >
>> >
>> > To be more explicit, NACK to this series(patches 4-8 to be more specific)
>> > unless you provide details on:
>> >
>> > 1. Why this is not in PSCI implementation ?
>> This is a linux activity and there is no provision in ATF or QC firmware
>> to do this activity. The task of physically powering down the domain,
>> still is a firmware decision and is done through PSCI platform
>> coordinated in the firmware.
>>
>
>Yes that was my understanding. So the addon question here is: if PSCI
>decides to abort entering the idle state, the Linux doing the RPMH
>request is of no use which can be prevented if done once PSCI f/w is
>about to enter the state. I know it may be corner case, but we have
>whole OSI mode based on such corner cases.
>
Yes, it is a possibility and worth the chance taken. On an SoC, there
are other processors that may vote against powering down the shared
resources even when Linux has shutdown and it is a very likely
possibility. Ex., when you are on a phone call, the CPU subsystem could
be powered off and the flush of RPMH requests is a 'waste', but it is a
chance we need to take. The alternate is a synchronization nightmare.

Even 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.

>> > 2. If PSCI is used on this platform, how does it work/co-exist ?
>> Yes PSCI is used in this platform. ATF is the firmware and that supports
>> only Platform Coordinated. This SoC uses cpuidle and the regular PSCI
>> methods to power off the domain from the firmware. However, Linux has
>> responsibilities that it needs to complete before the power down can be
>> beneficial.
>>
>
>I understand the need to inform RPMH. So I take only reason to do that
>in Linux is TF-A doesn't have any support to talk to RPMH ?
>
It may or may not, depending on which firmware you talk to. But consider
this, if the firmware votes for lowering resource state, it is doing it
for its exception level and not for Linux. So Linux has to take care of
its own.

>Now that we have some platform with PC, it's good to compare PC vs OSI
>which we always lacked. Thanks for letting us know this platform is PC
>based.
>
Can I take that you are okay with the OSI idea and this one, then :)
Yes, we are close to having a platform have both, possibly.

>> Isn't sharing ideas a key aspect of working with the community? This
>> series just goes to say that the idea of CPU PM domains are useful,
>> whether PSCI uses it or not. If you still need clarifications, Raju and
>> I will be happy to set up a meeting and go over the idea.
>>
>Ah OK, so this platform will have flattened cpu-idle-states list ? That's
>absolutely fine. But what if we want to represent hierarchical PSCI based
>PM domains and this power domain for some platform. That's the main
>concern I raised. For me, the power-domains in DT introduced in this
>is just to deal with RPMH though the actual work is done by PSCI.
>That just doesn't look that good for me.
>
What problem do you see with that? It would help if you could clarify
your concern.

Thanks,
Lina

Powered by blists - more mailing lists