All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Valentin <edubezval@gmail.com>
To: Quentin Perret <quentin.perret@arm.com>
Cc: linux-pm@vger.kernel.org, rjw@rjwysocki.net, vireshk@kernel.org,
	nm@ti.com, sboyd@codeaurora.org, sudeep.holla@arm.com,
	amit.kachhap@gmail.com, javi.merino@kernel.org,
	rui.zhang@intel.com, matthias.bgg@gmail.com,
	dietmar.eggemann@arm.com, morten.rasmussen@arm.com,
	patrick.bellasi@arm.com, ionela.voinescu@arm.com
Subject: Re: [PATCH 0/2] thermal, OPP: move the CPU power estimation to the OPP library
Date: Wed, 10 Jan 2018 11:34:33 -0800	[thread overview]
Message-ID: <20180110193431.GE3837@localhost.localdomain> (raw)
In-Reply-To: <20180109110252.13557-1-quentin.perret@arm.com>

On Tue, Jan 09, 2018 at 11:02:50AM +0000, Quentin Perret wrote:
> Currently, IPA estimates the power dissipated by a CPU at each available OPP
> using its capacitance (the dynamic-power-coefficient DT binding). This series
> relocates this feature into the OPP library as a preparation for future
> changes. More specifically:
> 
>    1. The current DT-based approach for power estimation will need deep
>       changes to support SCMI-provided power values. While the thermal
>       subsystem is not necessarily the best place to hide multiple power
>       estimation methods, the OPP library appears to be a good candidate to
>       implement the required platform abstraction.
>    2. The energy models of CPUs will be needed by other clients in the future
>       (such as the task scheduler or CPUFreq governors for example) in order
>       to make energy-aware decisions. The relocation to the OPP library will
>       enable code re-use and all clients will benefit form the platform
>       abstraction mentioned previously.

To be quite frank, I am happy to see this leaving thermal subsystem.
However, a few concerns with the patch set as it is. First, I am not
convinced PM OPP is the right place to put this, nor I see a good
explanation put in the patch set why it must be part of PM OPP.
Second, looks like we are following ARM "good" practice of fixing
problems of the future. I would only really sign off for this series
when we see real "other future users", otherwise we end up with the
infamous static power scenario in 2-3 years down the row. If we
currently do not have users of this IN MAINLINE KERNEL, then the series
is not for upstream.

> 
> Quentin Perret (2):
>   PM / OPP: introduce an OPP power estimation helper
>   thermal: cpu_cooling: use power models from the OPP library
> 
>  drivers/cpufreq/arm_big_little.c   |  2 ++
>  drivers/cpufreq/cpufreq-dt.c       |  2 ++
>  drivers/cpufreq/mediatek-cpufreq.c |  2 ++
>  drivers/opp/core.c                 | 40 +++++++++++++++++++++++++
>  drivers/opp/of.c                   | 61 ++++++++++++++++++++++++++++++++++++++
>  drivers/opp/opp.h                  |  4 +++
>  drivers/thermal/cpu_cooling.c      | 33 ++++++---------------
>  include/linux/pm_opp.h             | 20 +++++++++++++
>  8 files changed, 140 insertions(+), 24 deletions(-)
> 
> -- 
> 2.15.1
> 

  parent reply	other threads:[~2018-01-10 19:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 11:02 [PATCH 0/2] thermal, OPP: move the CPU power estimation to the OPP library Quentin Perret
2018-01-09 11:02 ` [PATCH 1/2] PM / OPP: introduce an OPP power estimation helper Quentin Perret
2018-01-10  4:36   ` Viresh Kumar
2018-01-10 10:20     ` Quentin Perret
2018-01-10 10:25       ` Viresh Kumar
2018-01-10 10:36         ` Quentin Perret
2018-01-09 11:02 ` [PATCH 2/2] thermal: cpu_cooling: use power models from the OPP library Quentin Perret
2018-01-10  4:37   ` Viresh Kumar
2018-01-10 19:34 ` Eduardo Valentin [this message]
2018-01-11  9:42   ` [PATCH 0/2] thermal, OPP: move the CPU power estimation to " Viresh Kumar
2018-01-11  9:42   ` Quentin Perret
2018-01-12 17:24     ` Eduardo Valentin
2018-01-12 17:44       ` Quentin Perret
2018-01-12 17:47         ` Eduardo Valentin
2018-01-12 17:50           ` Quentin Perret
2018-01-15  4:26       ` Viresh Kumar
2018-01-15 17:46         ` Eduardo Valentin
2018-01-16  9:16           ` 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=20180110193431.GE3837@localhost.localdomain \
    --to=edubezval@gmail.com \
    --cc=amit.kachhap@gmail.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=ionela.voinescu@arm.com \
    --cc=javi.merino@kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=morten.rasmussen@arm.com \
    --cc=nm@ti.com \
    --cc=patrick.bellasi@arm.com \
    --cc=quentin.perret@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=rui.zhang@intel.com \
    --cc=sboyd@codeaurora.org \
    --cc=sudeep.holla@arm.com \
    --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 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.