All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Kaehlcke <mka@chromium.org>
To: Quentin Perret <quentin.perret@arm.com>
Cc: rjw@rjwysocki.net, viresh.kumar@linaro.org, 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 1/7] PM / OPP: Introduce a power estimation helper
Date: Tue, 29 Jan 2019 09:52:15 -0800	[thread overview]
Message-ID: <20190129175215.GK81583@google.com> (raw)
In-Reply-To: <20190129090331.fgygq3dsaoqvegsl@queper01-lin>

Hi Quentin,

On Tue, Jan 29, 2019 at 09:03:34AM +0000, Quentin Perret wrote:
> Hi Matthias,
> 
> On Monday 28 Jan 2019 at 11:02:51 (-0800), Matthias Kaehlcke wrote:
> > > +/**
> > > + * of_dev_pm_opp_get_cpu_power() - Estimates the power of a CPU
> > > + * @mW:		pointer to the power estimate in milli-watts
> > > + * @KHz:	pointer to the OPP's frequency, in kilo-hertz
> > 
> > nit: should be kHz
> 
> Right, I can change that :-)
> 
> > 
> > > + * @cpu:	CPU for which power needs to be estimated
> > > + *
> > > + * Computes the power estimated by @CPU at the first OPP above @KHz (ceil),
> > > + * and updates @KHz and @mW accordingly.
> > > + *
> > > + * The power is estimated as P = C * V^2 * f, with C the CPU's capacitance
> > > + * (read from the 'dynamic-power-coefficient' devicetree binding) and V and f
> > > + * respectively the voltage and frequency of the OPP.
> > > + *
> > > + * Return: -ENODEV if the CPU device cannot be found, -EINVAL if the power
> > > + * calculation failed because of missing parameters, 0 otherwise.
> > > + */
> > > +int of_dev_pm_opp_get_cpu_power(unsigned long *mW, unsigned long *KHz, int cpu)
> > 
> > I think it is more common to put the input parameters first, then the
> > output ones, i.e. cpu, kHz, mW.
> 
> Hmm, the issue is this must match the expectations of the EM framework:
> 
> https://elixir.bootlin.com/linux/v5.0-rc4/source/include/linux/energy_model.h#L62
> 
> So, I don't really have a choice. Or we can change the core code if this
> _really_ is a problem -- we don't have users yet so now is the best time
> to do so I guess ...

I see.

I think it would be preferable to follow the common scheme, but it's
also not a major issue, up to you whether you want to change the
definition of the callback. It's certainly true that now would be the
best time for a change.

Cheers

Matthias

WARNING: multiple messages have this Message-ID (diff)
From: Matthias Kaehlcke <mka@chromium.org>
To: Quentin Perret <quentin.perret@arm.com>
Cc: mark.rutland@arm.com, rjw@rjwysocki.net, nm@ti.com,
	lorenzo.pieralisi@arm.com, devicetree@vger.kernel.org,
	sboyd@kernel.org, viresh.kumar@linaro.org,
	linux-pm@vger.kernel.org, liviu.dudau@arm.com,
	linux-kernel@vger.kernel.org, robh+dt@kernel.org,
	sudeep.holla@arm.com, dietmar.eggemann@arm.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/7] PM / OPP: Introduce a power estimation helper
Date: Tue, 29 Jan 2019 09:52:15 -0800	[thread overview]
Message-ID: <20190129175215.GK81583@google.com> (raw)
In-Reply-To: <20190129090331.fgygq3dsaoqvegsl@queper01-lin>

Hi Quentin,

On Tue, Jan 29, 2019 at 09:03:34AM +0000, Quentin Perret wrote:
> Hi Matthias,
> 
> On Monday 28 Jan 2019 at 11:02:51 (-0800), Matthias Kaehlcke wrote:
> > > +/**
> > > + * of_dev_pm_opp_get_cpu_power() - Estimates the power of a CPU
> > > + * @mW:		pointer to the power estimate in milli-watts
> > > + * @KHz:	pointer to the OPP's frequency, in kilo-hertz
> > 
> > nit: should be kHz
> 
> Right, I can change that :-)
> 
> > 
> > > + * @cpu:	CPU for which power needs to be estimated
> > > + *
> > > + * Computes the power estimated by @CPU at the first OPP above @KHz (ceil),
> > > + * and updates @KHz and @mW accordingly.
> > > + *
> > > + * The power is estimated as P = C * V^2 * f, with C the CPU's capacitance
> > > + * (read from the 'dynamic-power-coefficient' devicetree binding) and V and f
> > > + * respectively the voltage and frequency of the OPP.
> > > + *
> > > + * Return: -ENODEV if the CPU device cannot be found, -EINVAL if the power
> > > + * calculation failed because of missing parameters, 0 otherwise.
> > > + */
> > > +int of_dev_pm_opp_get_cpu_power(unsigned long *mW, unsigned long *KHz, int cpu)
> > 
> > I think it is more common to put the input parameters first, then the
> > output ones, i.e. cpu, kHz, mW.
> 
> Hmm, the issue is this must match the expectations of the EM framework:
> 
> https://elixir.bootlin.com/linux/v5.0-rc4/source/include/linux/energy_model.h#L62
> 
> So, I don't really have a choice. Or we can change the core code if this
> _really_ is a problem -- we don't have users yet so now is the best time
> to do so I guess ...

I see.

I think it would be preferable to follow the common scheme, but it's
also not a major issue, up to you whether you want to change the
definition of the callback. It's certainly true that now would be the
best time for a change.

Cheers

Matthias

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-01-29 17:52 UTC|newest]

Thread overview: 52+ 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 ` Quentin Perret
2019-01-28 16:55 ` [PATCH 1/7] PM / OPP: Introduce a power estimation helper Quentin Perret
2019-01-28 16:55   ` Quentin Perret
2019-01-28 19:02   ` Matthias Kaehlcke
2019-01-28 19:02     ` Matthias Kaehlcke
2019-01-29  9:03     ` Quentin Perret
2019-01-29  9:03       ` Quentin Perret
2019-01-29 17:52       ` Matthias Kaehlcke [this message]
2019-01-29 17:52         ` Matthias Kaehlcke
2019-01-29  5:10   ` Viresh Kumar
2019-01-29  5:10     ` Viresh Kumar
2019-01-29  9:09     ` Quentin Perret
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 16:55   ` Quentin Perret
2019-01-28 16:55   ` Quentin Perret
2019-01-28 19:36   ` Matthias Kaehlcke
2019-01-28 19:36     ` Matthias Kaehlcke
2019-01-29  5:21     ` Viresh Kumar
2019-01-29  5:21       ` Viresh Kumar
2019-01-29  9:15       ` Quentin Perret
2019-01-29  9:15         ` Quentin Perret
2019-01-30  5:18         ` Viresh Kumar
2019-01-30  5:18           ` Viresh Kumar
2019-01-30  9:12           ` Quentin Perret
2019-01-30  9:12             ` Quentin Perret
2019-01-30 10:17             ` Viresh Kumar
2019-01-30 10:17               ` Viresh Kumar
2019-01-30 10:17               ` Viresh Kumar
2019-01-30 10:20               ` Quentin Perret
2019-01-30 10:20                 ` Quentin Perret
2019-01-29  5:30   ` Viresh Kumar
2019-01-29  5:30     ` Viresh Kumar
2019-01-29  9:10     ` Quentin Perret
2019-01-29  9:10       ` Quentin Perret
2019-01-28 16:55 ` [PATCH 3/7] cpufreq: scpi: " Quentin Perret
2019-01-28 16:55   ` Quentin Perret
2019-01-29  5:31   ` Viresh Kumar
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   ` Quentin Perret
2019-01-28 16:55 ` [PATCH 5/7] cpufreq: scmi: " Quentin Perret
2019-01-28 16:55   ` Quentin Perret
2019-01-28 16:55 ` [PATCH 6/7] arm64: dts: juno: Add cpu dynamic-power-coefficient information Quentin Perret
2019-01-28 16:55   ` Quentin Perret
2019-01-29 15:27   ` Sudeep Holla
2019-01-29 15:27     ` Sudeep Holla
2019-01-30 10:23     ` Quentin Perret
2019-01-30 10:23       ` Quentin Perret
2019-01-28 16:55 ` [PATCH 7/7] arm: dts: vexpress-v2p-ca15_a7: " Quentin Perret
2019-01-28 16:55   ` 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=20190129175215.GK81583@google.com \
    --to=mka@chromium.org \
    --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=nm@ti.com \
    --cc=quentin.perret@arm.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 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.