Linux Power Management development
 help / color / mirror / Atom feed
From: Zhang Rui <rui.zhang@intel.com>
To: Lukasz Luba <lukasz.luba@arm.com>,
	linux-pm@vger.kernel.org, edubezval@gmail.com
Cc: javi.merino@kernel.org, chris.diamand@arm.com
Subject: Re: [PATCH v3 0/3] devfreq_cooling: let the driver supply the
Date: Wed, 10 May 2017 09:14:12 +0800	[thread overview]
Message-ID: <1494378852.2129.12.camel@intel.com> (raw)
In-Reply-To: <9045ed39-02eb-726a-256e-ea578e9452d6@arm.com>

On Tue, 2017-05-09 at 10:48 +0100, Lukasz Luba wrote:
> Hi Eduardo, Rui,
> 
> gentle ping. Any hope to merge it soon?
> 
yes, it's in my queue, and I will send out the pull request soon.

thanks,
rui
> Regards,
> Lukasz
> 
> On 04/05/17 12:34, Lukasz Luba wrote:
> > 
> > Hi,
> > 
> > This patchset introduces a new interface for devfreq cooling in
> > thermal
> > framework. The first version of the patch can be seen here [1],
> > second [2].
> > I have simplified the implementation and introduced resource
> > utilization
> > scaling factor.
> > 
> > The current implementation in the thermal devfreq cooling subsystem
> > uses
> > pre-calculated power table for each device to make a decision about
> > allowed
> > running state. When the driver registers itself to the thermal
> > devfreq cooling
> > subsystem, the framework creates the power table.
> > The power table is then used by the thermal subsystem to keep
> > the device in the thermal envelope.
> > In the previous implementation the pre-calculated device's power
> > table was scaled by current 'utilization'
> > ('busy_time' and 'total_time' taken from devfreq 'last_status').
> > 
> > This idea meets the expectations of the devices which know better
> > the actual
> > power that they consume (thanks to power counters). When some
> > parts/features of the device are not used the power value might be
> > lower,
> > while the frequency and utilization are the same.
> > 
> > The proposed implementation provides possibility to register a
> > driver to
> > thermal devfreq cooling subsystem and use the driver's code during
> > the
> > calculation of the power in runtime.
> > 
> > The device driver can still use pre-calculated power table when
> > these new
> > functions are not provided (the new extension can co-exist with old
> > implementation).
> > 
> > The first patch contains some refactoring for getting the voltage,
> > the second implements the new feature, the third one changes trace
> > function.
> > Patchset is based on v4.11-rc8.
> > 
> > 
> > Changes
> > v3:
> > - refactor OPP code to fit into new dev_pm_opp API
> > v2:
> > - removed 'flags' and power2state function,
> > - split into a few patches,
> > - simplified the logic of the new interface,
> > - added resource utilization scaling factor,
> > 
> > Regards,
> > Lukasz Luba
> > 
> > [1] https://marc.info/?l=linux-pm&m=147395070729989&w=2
> > [2] http://marc.info/?l=linux-pm&m=148587920122854&w=2
> > 
> > Lukasz Luba (3):
> >   thermal: devfreq_cooling: refactor code and add get_voltage
> > function
> >   thermal: devfreq_cooling: add new interface for direct power read
> >   trace: thermal: add another parameter 'power' to the tracing
> > function
> > 
> >  drivers/thermal/devfreq_cooling.c | 152
> > ++++++++++++++++++++++++++++----------
> >  include/linux/devfreq_cooling.h   |  19 +++++
> >  include/trace/events/thermal.h    |  11 ++-
> >  3 files changed, 137 insertions(+), 45 deletions(-)
> > 

  reply	other threads:[~2017-05-10  1:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-04 11:34 [PATCH v3 0/3] devfreq_cooling: let the driver supply the Lukasz Luba
2017-05-04 11:34 ` [PATCH v3 1/3] thermal: devfreq_cooling: refactor code and add get_voltage function Lukasz Luba
2017-05-04 11:34 ` [PATCH v3 2/3] thermal: devfreq_cooling: add new interface for direct power read Lukasz Luba
2017-05-04 11:34 ` [PATCH v3 3/3] trace: thermal: add another parameter 'power' to the tracing function Lukasz Luba
2017-05-09  9:48 ` [PATCH v3 0/3] devfreq_cooling: let the driver supply the Lukasz Luba
2017-05-10  1:14   ` Zhang Rui [this message]
2017-05-10  7:47     ` Lukasz Luba

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=1494378852.2129.12.camel@intel.com \
    --to=rui.zhang@intel.com \
    --cc=chris.diamand@arm.com \
    --cc=edubezval@gmail.com \
    --cc=javi.merino@kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    /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