linux-kernel - Re: [PATCH RFC v1 7/8] drivers: qcom: cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181012161653.GH2371@codeaurora.org>
Date:   Fri, 12 Oct 2018 10:16:53 -0600
From:   Lina Iyer <ilina@...eaurora.org>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        "Raju P.L.S.S.S.N" <rplsssn@...eaurora.org>,
        Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Kevin Hilman <khilman@...nel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        linux-soc@...r.kernel.org, Rajendra Nayak <rnayak@...eaurora.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Evan Green <evgreen@...omium.org>,
        Doug Anderson <dianders@...omium.org>,
        Matthias Kaehlcke <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 Fri, Oct 12 2018 at 09:46 -0600, Ulf Hansson wrote:
>On 12 October 2018 at 17:04, Sudeep Holla <sudeep.holla@....com> 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