From: Sudeep Holla <sudeep.holla@arm.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Nicola Mazzucato <nicola.mazzucato@arm.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, rjw@rjwysocki.net,
vireshk@kernel.org, robh+dt@kernel.org, sboyd@kernel.org,
nm@ti.com, daniel.lezcano@linaro.org, morten.rasmussen@arm.com,
chris.redpath@arm.com
Subject: Re: [PATCH v4 3/4] scmi-cpufreq: get opp_shared_cpus from opp-v2 for EM
Date: Wed, 9 Dec 2020 09:41:21 +0000 [thread overview]
Message-ID: <20201209094121.b6jloegdzpmcphqz@bogus> (raw)
In-Reply-To: <20201209054502.ajomw6glcxx5hue2@vireshk-i7>
On Wed, Dec 09, 2020 at 11:15:02AM +0530, Viresh Kumar wrote:
> On 08-12-20, 11:20, Sudeep Holla wrote:
> > It is because of per-CPU vs per domain drama here. Imagine a system with
> > 4 CPUs which the firmware puts in individual domains while they all are
> > in the same perf domain and hence OPP is marked shared in DT.
> >
> > Since this probe gets called for all the cpus, we need to skip adding
> > OPPs for the last 3(add only for 1st one and mark others as shared).
>
> Okay and this wasn't happening before this series because the firmware
> was only returning the current CPU from scmi_get_sharing_cpus() ?
>
> Is this driver also used for the cases where we have multiple CPUs in
> a policy ? Otherwise we won't be required to call
> dev_pm_opp_set_sharing_cpus().
>
> So I assume that we want to support both the cases here ?
>
Yes indeed, completely depends on what granularity firmware provides the
performance control. It could be individual CPUs, could be pair of CPUs
(or all the threads in the core) or subset of CPUs in the performance
domain. The subset could be full set.
> > If we attempt to add OPPs on second cpu probe, it *will* shout as duplicate
> > OPP as we would have already marked it as shared table with the first cpu.
> > Am I missing anything ? I suggested this as Nicola saw OPP duplicate
> > warnings when he was hacking up this patch.
>
> The common stuff (for all the CPUs) is better moved to probe() in this
> case, instead of the ->init() callback. Otherwise it will always be
> messy. You can initialize the OPP and cpufreq tables in probe()
> itself, save the pointer somewhere and then just use it here in
> ->init().
>
> Also do EM registration from there.
>
Makes sense.
--
Regards,
Sudeep
next prev parent reply other threads:[~2020-12-09 9:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-02 17:23 [PATCH v4 0/4] CPUFreq: Add support for opp-sharing cpus Nicola Mazzucato
2020-12-02 17:23 ` [PATCH v4 1/4] dt-bindings/opp: Update documentation for opp-shared Nicola Mazzucato
2020-12-08 4:29 ` Viresh Kumar
2020-12-08 7:15 ` Nicola Mazzucato
2020-12-02 17:23 ` [PATCH v4 2/4] opp/of: Allow empty opp-table with opp-shared Nicola Mazzucato
2020-12-02 17:23 ` [PATCH v4 3/4] scmi-cpufreq: get opp_shared_cpus from opp-v2 for EM Nicola Mazzucato
2020-12-08 5:50 ` Viresh Kumar
2020-12-08 7:22 ` Nicola Mazzucato
2020-12-08 7:26 ` Viresh Kumar
2020-12-08 10:58 ` Nicola Mazzucato
2020-12-08 11:01 ` Viresh Kumar
2020-12-08 11:21 ` Sudeep Holla
2020-12-08 11:20 ` Sudeep Holla
2020-12-08 11:34 ` Lukasz Luba
2020-12-08 12:22 ` Sudeep Holla
2020-12-08 13:17 ` Nicola Mazzucato
2020-12-09 5:45 ` Viresh Kumar
2020-12-09 9:20 ` Nicola Mazzucato
2020-12-09 9:41 ` Sudeep Holla [this message]
2020-12-02 17:23 ` [PATCH v4 4/4] cpufreq: blacklist Arm Vexpress platforms in cpufreq-dt-platdev Nicola Mazzucato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201209094121.b6jloegdzpmcphqz@bogus \
--to=sudeep.holla@arm.com \
--cc=chris.redpath@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=nicola.mazzucato@arm.com \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=vireshk@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox