All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Quentin Perret <qperret@google.com>
Cc: Vincent Donnefort <vincent.donnefort@arm.com>,
	peterz@infradead.org, rjw@rjwysocki.net,
	vincent.guittot@linaro.org, linux-pm@vger.kernel.org,
	ionela.voinescu@arm.com, lukasz.luba@arm.com,
	dietmar.eggemann@arm.com
Subject: Re: [PATCH v3 3/6] cpufreq: Add an interface to mark inefficient frequencies
Date: Tue, 22 Jun 2021 14:55:51 +0530	[thread overview]
Message-ID: <20210622092551.zauoukpakpxdxso7@vireshk-i7> (raw)
In-Reply-To: <YNGm+W/BBQnvfPe/@google.com>

On 22-06-21, 09:01, Quentin Perret wrote:
> On Tuesday 15 Jun 2021 at 15:47:06 (+0530), Viresh Kumar wrote:
> > The point is that I don't want cpufreq to carry this for users, we
> > have EM today, tomorrow we may want to mark a frequency as inefficient
> > from somewhere else. The call need to initiate from EM core.
> > 
> > And this isn't a cpufreq only thing, but is going to be generic along
> > with other device types.
> >
> > This is exactly why I asked you earlier to play with OPP core for
> > this. That is the central place for data for all such users.
> 
> The thing is, the very reason for the existence of PM_EM in the first
> place is to NOT depend on PM_OPP which was deemed too Arm-specific. So
> let's not create those dependencies now please.

I am not asking to create one here.

What I am saying is that users of EM, which eventually call
em_dev_register_perf_domain() have the necessary details about about
the performance states (like voltage/freq pairs, or power) and the EM
core should talk to those users directly.

The struct em_data_callback is already there for this reason so we can
keep EM core independent of its users. I suggested to add another
callback there to mark a frequency inefficient, that's all.

In the case of ARM platforms, that would automatically mean OPP core,
and for others it can be anything that has this knowledge.

> > If this information is present at the OPP table (somehow), then we can
> > just fix dev_pm_opp_init_cpufreq_table() to set this for cpufreq core
> > as well.
> 
> Honnestly, I don't think PM_OPP should have anything to do with this,
> for the reason mentionned above.
> 
> I don't really see the problem with cpufreq core querying the EM data
> directly, we already have core subsystems doing that (the scheduler) so
> why would that be a problem?

If EM core is going to be the only entity ever which can provide this
information, then maybe we can get add some core support for this. But
if it is just another driver/layer which can add this information,
then it is always better to provide APIs which such users can call.
And so I was looking for cpufreq to provide an API, which can be
called from such users.

The problem here happened because we registered with the EM core from
policy's ->init() and we couldn't get back to cpufreq core from there
as the policy is only half initialized.

> If the only concern is for non-CPU devices,
> all we'd need is a matching feature in devfreq core and everything
> should be good no?

-- 
viresh

  reply	other threads:[~2021-06-22  9:26 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-04 11:05 [PATCH v3 0/6] EM / PM: Inefficient OPPs Vincent Donnefort
2021-06-04 11:05 ` [PATCH v3 1/6] PM / EM: Fix inefficient states detection Vincent Donnefort
2021-06-04 18:09   ` Matthias Kaehlcke
2021-06-04 11:05 ` [PATCH v3 2/6] PM / EM: Mark inefficient states Vincent Donnefort
2021-06-04 18:12   ` Matthias Kaehlcke
2021-06-04 11:05 ` [PATCH v3 3/6] cpufreq: Add an interface to mark inefficient frequencies Vincent Donnefort
2021-06-04 18:19   ` Matthias Kaehlcke
2021-06-14 13:40     ` Vincent Donnefort
2021-06-07  5:02   ` Viresh Kumar
2021-06-07 10:14     ` Lukasz Luba
2021-06-14  7:28   ` Viresh Kumar
2021-06-14 13:35     ` Vincent Donnefort
2021-06-15  5:02       ` Viresh Kumar
2021-06-15  8:44         ` Vincent Donnefort
2021-06-15 10:17           ` Viresh Kumar
2021-06-15 17:15             ` Vincent Donnefort
2021-06-16  7:35               ` Viresh Kumar
2021-06-16  9:03                 ` Lukasz Luba
2021-06-16  9:31                   ` Viresh Kumar
2021-06-16 10:33                     ` Lukasz Luba
2021-06-16 10:53                       ` Viresh Kumar
2021-06-16 12:45                         ` Lukasz Luba
2021-07-02 14:21                           ` Lukasz Luba
2021-07-02 15:46                             ` Rafael J. Wysocki
2021-07-02 16:04                               ` Rafael J. Wysocki
2021-07-02 16:08                                 ` Lukasz Luba
2021-07-02 17:53                                   ` Rafael J. Wysocki
2021-07-02 19:04                                     ` Lukasz Luba
2021-07-02 19:17                                     ` Vincent Donnefort
2021-07-05 14:09                                       ` Rafael J. Wysocki
2021-07-06  8:12                                         ` Vincent Donnefort
2021-07-06  8:37                                           ` Viresh Kumar
2021-07-06  8:43                                             ` Vincent Donnefort
2021-07-06  8:50                                               ` Viresh Kumar
2021-07-06 12:11                                           ` Rafael J. Wysocki
2021-07-02 16:13                               ` Vincent Donnefort
2021-07-02 17:38                                 ` Rafael J. Wysocki
2021-06-22  9:01             ` Quentin Perret
2021-06-22  9:25               ` Viresh Kumar [this message]
2021-06-04 11:05 ` [PATCH v3 4/6] cpufreq: Skip inefficient frequencies in cpufreq_driver_resolve_freq() Vincent Donnefort
2021-06-04 18:25   ` Matthias Kaehlcke
2021-06-04 11:06 ` [PATCH v3 5/6] cpufreq: Mark inefficient frequencies using the Energy Model Vincent Donnefort
2021-06-04 18:35   ` Matthias Kaehlcke
2021-06-04 11:06 ` [PATCH v3 6/6] PM / EM: Skip inefficient states Vincent Donnefort
2021-06-04 18:49   ` Matthias Kaehlcke

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=20210622092551.zauoukpakpxdxso7@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=ionela.voinescu@arm.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=peterz@infradead.org \
    --cc=qperret@google.com \
    --cc=rjw@rjwysocki.net \
    --cc=vincent.donnefort@arm.com \
    --cc=vincent.guittot@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.