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(-)
> >
next prev parent 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 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.