All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Luba <lukasz.luba@arm.com>
To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Cc: vireshk@kernel.org, rafael@kernel.org, daniel.lezcano@linaro.org,
	Dietmar.Eggemann@arm.com, lukasz.luba@arm.com, amitk@kernel.org,
	rui.zhang@intel.com, cw00.choi@samsung.com,
	myungjoo.ham@samsung.com, kyungmin.park@samsung.com
Subject: [RFC][PATCH 0/3] New thermal interface allowing IPA to get max power
Date: Tue, 26 Jan 2021 10:39:58 +0000	[thread overview]
Message-ID: <20210126104001.20361-1-lukasz.luba@arm.com> (raw)

Hi all,

This patch set tries to add the missing feature in the Intelligent Power
Allocation (IPA) governor which is: frequency limit set by user space.
User can set max allowed frequency for a given device which has impact on
max allowed power. In current design there is no mechanism to figure this
out. IPA must know the maximum allowed power for every device. It is then
used for proper power split and divvy-up. When the user limit for max
frequency is not know, IPA assumes it is the highest possible frequency.
It causes wrong power split across the devices.

This new mechanism provides the max allowed frequency to the thermal
framework and then max allowed power to the IPA.
The implementation is done in this way because currently there is no way
to retrieve the limits from the PM QoS, without uncapping the local
thermal limit and reading the next value. It would be a heavy way of
doing these things, since it should be done every polling time (e.g. 50ms).
Also, the value stored in PM QoS can be different than the real OPP 'rate'
so still would need conversion into proper OPP for comparison with EM.
Furthermore, uncapping the device in thermal just to check the user freq
limit is not the safest way.
Thus, this simple implementation moves the calculation of the proper
frequency to the sysfs write code, since it's called less often. The value
is then used as-is in the thermal framework without any hassle.

As it's a RFC, it still misses the cpufreq sysfs implementation, but would
be addressed if all agree.

Regards,
Lukasz Luba

Lukasz Luba (3):
  PM /devfreq: add user frequency limits into devfreq struct
  thermal: devfreq_cooling: add new callback to get user limit for min
    state
  thermal: power_allocator: get proper max power limited by user

 drivers/devfreq/devfreq.c             | 41 ++++++++++++++++++++++++---
 drivers/thermal/devfreq_cooling.c     | 33 +++++++++++++++++++++
 drivers/thermal/gov_power_allocator.c | 17 +++++++++--
 include/linux/devfreq.h               |  4 +++
 include/linux/thermal.h               |  1 +
 5 files changed, 90 insertions(+), 6 deletions(-)

-- 
2.17.1


             reply	other threads:[~2021-01-26 11:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-26 10:39 Lukasz Luba [this message]
2021-01-26 10:39 ` [RFC][PATCH 1/3] PM /devfreq: add user frequency limits into devfreq struct Lukasz Luba
2021-02-03 10:11   ` Chanwoo Choi
2021-02-03 10:21     ` Lukasz Luba
2021-02-11 11:07       ` Lukasz Luba
2021-02-11 22:27         ` Lukasz Luba
2021-02-15 15:00           ` Chanwoo Choi
2021-02-16 10:41             ` Lukasz Luba
2021-02-24  8:04               ` Chanwoo Choi
2021-01-26 10:40 ` [RFC][PATCH 2/3] thermal: devfreq_cooling: add new callback to get user limit for min state Lukasz Luba
2021-01-26 10:40 ` [RFC][PATCH 3/3] thermal: power_allocator: get proper max power limited by user Lukasz Luba
2021-01-27  9:15 ` [RFC][PATCH 0/3] New thermal interface allowing IPA to get max power Viresh Kumar
2021-01-27 10:11   ` Lukasz Luba
2021-01-27 10:13     ` Viresh Kumar
2021-02-01 11:23 ` Lukasz Luba
2021-02-01 14:21   ` Daniel Lezcano
2021-02-01 16:37     ` Lukasz Luba
2021-02-02  9:31   ` Chanwoo Choi
2021-02-02  9:56     ` Lukasz Luba
2021-02-01 14:19 ` Rafael J. Wysocki
2021-02-01 16:37   ` Lukasz Luba
2021-02-22 10:22 ` Daniel Lezcano
2021-02-22 12:10   ` 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=20210126104001.20361-1-lukasz.luba@arm.com \
    --to=lukasz.luba@arm.com \
    --cc=Dietmar.Eggemann@arm.com \
    --cc=amitk@kernel.org \
    --cc=cw00.choi@samsung.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.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.