From: Quentin Perret <quentin.perret@arm.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Matthias Kaehlcke <mka@chromium.org>,
rjw@rjwysocki.net, sudeep.holla@arm.com, liviu.dudau@arm.com,
lorenzo.pieralisi@arm.com, robh+dt@kernel.org,
mark.rutland@arm.com, nm@ti.com, sboyd@kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
dietmar.eggemann@arm.com
Subject: Re: [PATCH 2/7] cpufreq: dt: Register an Energy Model
Date: Wed, 30 Jan 2019 09:12:27 +0000 [thread overview]
Message-ID: <20190130091055.zjj2jrjvi2n3ht66@queper01-lin> (raw)
In-Reply-To: <20190130051806.fdsos27jaekkwgbs@vireshk-i7>
Hi Viresh,
On Wednesday 30 Jan 2019 at 10:48:06 (+0530), Viresh Kumar wrote:
> On 29-01-19, 09:15, Quentin Perret wrote:
> > On Tuesday 29 Jan 2019 at 10:51:44 (+0530), Viresh Kumar wrote:
> > > On 28-01-19, 11:36, Matthias Kaehlcke wrote:
> > > > I think this patch will result in error messages at registration on
> > > > platforms that use the cpufreq-dt driver and don't specify
> > > > 'dynamic-power-coefficient' for the CPUs in the DT. Not sure if that's
> > > > a problem as long as the cpufreq initialization succeeds regardless,
> > > > it could be seen as a not-so-gentle nudge to add the values.
> > >
> > > That wouldn't be acceptable.
> >
> > Fair enough. What I can propose in this case is to have in PM_OPP a
> > helper called 'dev_pm_opp_of_register_em()' or something like this. This
> > function will check all prerequisites are present (we have the right
> > values in DT, and so on) and then call (or not) em_register_perf_domain().
> > Then we can make the CPUFreq drivers use that instead of calling
> > em_register_perf_domain() directly.
>
> That should be fine.
>
> > That would also make it easy to implement Matthias' suggestion to not
> > call em_register_perf_domain() if an EM is already present.
>
> So you will track registration state within the OPP core for that ?
What I had in mind is something as simple as:
void of_dev_pm_opp_register_em(struct cpumask *cpus)
{
/* Bail out if an EM is there */
if (em_cpu_get(cpumask_first(cpus)))
return;
/* Check prerequisites: dpc coeff in DT, ... */
...
em_register_perf_domain(...);
}
IIUC, Matthias' point was that if the EM is already registered, there is
no good reason to call em_register_perf_domain() again. Now, that should
in fact be harmless because em_register_perf_domain() already does that
check. It's just cleaner and easier to understand from a conceptual
standpoint to not call that function several times for no reason I
assume.
> Sorry but that doesn't sound right. What's wrong with having an
> unregister helper in energy-model to keep proper code flow everywhere
> ?
For the EM we basically allocate the tables in memory once and for all
at boot time and never touch them again. That makes it easy for users
(the scheduler as of now, IPA soon) to access them without messing
around with RCU or so. So there isn't really a concept or unregistering
a pd right now.
Thanks,
Quentin
next prev parent reply other threads:[~2019-01-30 9:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-28 16:55 [PATCH 0/7] Register an Energy Model for Arm reference platforms Quentin Perret
2019-01-28 16:55 ` [PATCH 1/7] PM / OPP: Introduce a power estimation helper Quentin Perret
2019-01-28 19:02 ` Matthias Kaehlcke
2019-01-29 9:03 ` Quentin Perret
2019-01-29 17:52 ` Matthias Kaehlcke
2019-01-29 5:10 ` Viresh Kumar
2019-01-29 9:09 ` Quentin Perret
2019-01-28 16:55 ` [PATCH 2/7] cpufreq: dt: Register an Energy Model Quentin Perret
2019-01-28 19:36 ` Matthias Kaehlcke
2019-01-29 5:21 ` Viresh Kumar
2019-01-29 9:15 ` Quentin Perret
2019-01-30 5:18 ` Viresh Kumar
2019-01-30 9:12 ` Quentin Perret [this message]
2019-01-30 10:17 ` Viresh Kumar
2019-01-30 10:20 ` Quentin Perret
2019-01-29 5:30 ` Viresh Kumar
2019-01-29 9:10 ` Quentin Perret
2019-01-28 16:55 ` [PATCH 3/7] cpufreq: scpi: " Quentin Perret
2019-01-29 5:31 ` Viresh Kumar
2019-01-28 16:55 ` [PATCH 4/7] cpufreq: arm_big_little: " Quentin Perret
2019-01-28 16:55 ` [PATCH 5/7] cpufreq: scmi: " Quentin Perret
2019-01-28 16:55 ` [PATCH 6/7] arm64: dts: juno: Add cpu dynamic-power-coefficient information Quentin Perret
2019-01-29 15:27 ` Sudeep Holla
2019-01-30 10:23 ` Quentin Perret
2019-01-28 16:55 ` [PATCH 7/7] arm: dts: vexpress-v2p-ca15_a7: " Quentin Perret
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=20190130091055.zjj2jrjvi2n3ht66@queper01-lin \
--to=quentin.perret@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=mka@chromium.org \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=viresh.kumar@linaro.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