From: Leonard Crestez <leonard.crestez@nxp.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Chanwoo Choi <cw00.choi@samsung.com>
Cc: "Matthias Kaehlcke" <mka@chromium.org>,
"Kyungmin Park" <kyungmin.park@samsung.com>,
"MyungJoo Ham" <myungjoo.ham@samsung.com>,
"Artur Świgoń" <a.swigon@partner.samsung.com>,
"Georgi Djakov" <georgi.djakov@linaro.org>,
"Jacky Bai" <ping.bai@nxp.com>,
"Viresh Kumar" <viresh.kumar@linaro.org>,
"NXP Linux Team" <linux-imx@nxp.com>,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/2] PM / devfreq: Add dev_pm_qos support
Date: Thu, 5 Dec 2019 12:05:05 +0200 [thread overview]
Message-ID: <cover.1575540224.git.leonard.crestez@nxp.com> (raw)
Add dev_pm_qos notifiers to devfreq core in order to support frequency
limits via dev_pm_qos_add_request.
Unlike the rest of devfreq the dev_pm_qos frequency is measured in kHz,
this is consistent with current dev_pm_qos usage for cpufreq and
allows frequencies above 2Ghz (pm_qos expresses limits as s32).
Like with cpufreq the handling of min_freq/max_freq is moved to the
dev_pm_qos mechanism. Constraints from userspace are no longer clamped on
store, instead all values can be written and we only check against OPPs in a
new devfreq_get_freq_range function. This is consistent with the design of
dev_pm_qos.
Notifiers from pm_qos are executed under a single global dev_pm_qos_mtx and
need to take devfreq->lock, this means that calls into dev_pm_qos while holding
devfreq->lock are not allowed (lockdep warns about possible deadlocks).
Fix this by only adding the qos request and notifiers after devfreq->lock is
released inside devfreq_add_device. In theory this means sysfs writes
are possible before the min/max requests are initialized so we guard
against that explictly. The dev_pm_qos_update_request function would
otherwise print a big WARN splat.
This series depends on recently accepted series restoring
DEV_PM_QOS_MIN/MAX_FREQUENCY inside the pm core:
https://patchwork.kernel.org/cover/11262633/
It would be great for this to get into 5.5-rc1
---
Changes since RFC v1:
* Trim cover letter
* Drop RFC since DEV_PM_QOS_MIN/MAX_FREQUENCY was restored
* Collect Acks.
* No code changes
Link to v1: https://patchwork.kernel.org/cover/11252415/
Changes since "big version" v10:
* Drop accepted cleanups
* Work with current locking approach (split cleanups into other series)
* Drop acks and deliberately relabel as a new series. It still incorporates
most previous discussion but takes a different approach to locking.
* Don't print errors if devfreq_dev_release is called on error cleanup from
devfreq_add_device, just accept that requests and notifiers might not be
registered yet. I wish dev_pm_qos cleanups behaved like standard "kfree" and
silently did nothing when there's nothing to be done.
Link to v10: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=196443
Leonard Crestez (2):
PM / devfreq: Add PM QoS support
PM / devfreq: Use PM QoS for sysfs min/max_freq
drivers/devfreq/devfreq.c | 151 ++++++++++++++++++++++++++++++++++----
include/linux/devfreq.h | 14 +++-
2 files changed, 145 insertions(+), 20 deletions(-)
--
2.17.1
next reply other threads:[~2019-12-05 10:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-05 10:05 Leonard Crestez [this message]
2019-12-05 10:05 ` [PATCH v2 1/2] PM / devfreq: Add PM QoS support Leonard Crestez
2019-12-05 17:48 ` Matthias Kaehlcke
2019-12-10 1:24 ` Leonard Crestez
2019-12-05 10:05 ` [PATCH v2 2/2] PM / devfreq: Use PM QoS for sysfs min/max_freq Leonard Crestez
2019-12-05 18:02 ` Matthias Kaehlcke
2019-12-06 2:38 ` Chanwoo Choi
2019-12-05 10:12 ` [PATCH v2 0/2] PM / devfreq: Add dev_pm_qos support Rafael J. Wysocki
2019-12-05 10:44 ` Leonard Crestez
2019-12-06 3:27 ` Chanwoo Choi
2019-12-06 4:54 ` Chanwoo Choi
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=cover.1575540224.git.leonard.crestez@nxp.com \
--to=leonard.crestez@nxp.com \
--cc=a.swigon@partner.samsung.com \
--cc=cw00.choi@samsung.com \
--cc=georgi.djakov@linaro.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-pm@vger.kernel.org \
--cc=mka@chromium.org \
--cc=myungjoo.ham@samsung.com \
--cc=ping.bai@nxp.com \
--cc=rjw@rjwysocki.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).