linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leonard Crestez <leonard.crestez@nxp.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Linux ACPI" <linux-acpi@vger.kernel.org>,
	"Linux PM" <linux-pm@vger.kernel.org>,
	"Sudeep Holla" <sudeep.holla@arm.com>,
	"Dmitry Osipenko" <digetx@gmail.com>,
	"Matthias Kaehlcke" <mka@chromium.org>,
	"Kyungmin Park" <kyungmin.park@samsung.com>,
	"Chanwoo Choi" <cw00.choi@samsung.com>,
	"Artur Świgoń" <a.swigon@samsung.com>,
	"Georgi Djakov" <georgi.djakov@linaro.org>,
	dl-linux-imx <linux-imx@nxp.com>,
	"Saravana Kannan" <saravanak@google.com>,
	"MyungJoo Ham" <myungjoo.ham@samsung.com>
Subject: Re: [RFT][PATCH 0/3] cpufreq / PM: QoS: Introduce frequency QoS and use it in cpufreq
Date: Tue, 22 Oct 2019 22:06:01 +0000	[thread overview]
Message-ID: <VI1PR04MB7023DF47D046AEADB4E051EBEE680@VI1PR04MB7023.eurprd04.prod.outlook.com> (raw)

Hello,

I've been working on a series which add DEV_PM_QOS support to devfreq, 
now at v9:

	https://patchwork.kernel.org/cover/11171807/

Your third patch removes DEV_PM_QOS_FREQUENCY_MIN/MAX that my series 
depends upon. I found the email on patchwork, hopefully the in-reply-to 
header is OK?

As far as I can tell the replacement ("frequency qos") needs constraints 
to be managed outside the device infrastructure and it's not obviously 
usable a generic mechanism for making "min_freq/max_freq" requests to a 
specific device.

I've read a bit through your emails and it seems the problem is that 
you're dealing with dev_pm_qos on per-policy basis but each "struct 
cpufreq_policy" can cover multiple CPU devices.

An alternative solution which follows dev_pm_qos would be to add 
notifiers for each CPU inside cpufreq_online and cpufreq_offline. This 
makes quite a bit of sense because each CPU is a separate "device" with 
a possibly distinct list of qos requests.

If cpufreq needs a group of CPUs to run at the same frequency then it 
should deal with this by doing dev_pm_qos_read_frequency on each CPU 
device and picking a frequency that attempts to satisfy all constraints.

Handling sysfs min/max_freq through dev_pm_qos would be of dubious 
value, though I guess you could register identical requests for each CPU.

I'm not familiar with what you're trying to accomplish with PM_QOS other 
than replace the sysfs min_freq/max_freq files: What I want to do is add 
a driver using the interconnect driver which translates requests for 
"bandwidth-on-a-path" into "frequency-on-a-device". More specifically a 
display driver could request bandwidth to RAM and this would be 
translated into min frequency for NoC and the DDR controller, both of 
which implement scaling via devfreq:

	https://patchwork.kernel.org/cover/11104113/
	https://patchwork.kernel.org/cover/11111865/

This is part of an effort to upstream an out-of-tree "busfreq" feature 
which allows device device to make "min frequency requests" through an 
entirely out-of-tree mechanism. It would also allow finer-grained 
scaling that what IMX tree currently support.

If you're making cpufreq qos constrains be "per-cpufreq-policy" then 
it's not clear how you would handle in-kernel constraints from other 
subsystems. Would users have to get a pointer to struct cpufreq_policy 
and struct freq_constraints? That would make object lifetime a 
nightmare! But dev_pm_qos solves this by tying to struct device.

And if you don't care about in-kernel requests then what's the purpose 
of involving PM QoS? The old min/max_freq sysfs implementation worked.

--
Regards,
Leonard

             reply	other threads:[~2019-10-22 22:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-22 22:06 Leonard Crestez [this message]
2019-10-22 22:47 ` [RFT][PATCH 0/3] cpufreq / PM: QoS: Introduce frequency QoS and use it in cpufreq Rafael J. Wysocki
2019-10-23  2:20   ` Leonard Crestez
2019-10-23  8:54     ` Rafael J. Wysocki
2019-10-23  8:57       ` Rafael J. Wysocki
2019-10-23 13:33       ` Leonard Crestez
2019-10-24 13:42         ` Rafael J. Wysocki
2019-10-24 17:47           ` Leonard Crestez
2019-10-24 21:10             ` Rafael J. Wysocki
2019-10-25 18:04               ` Leonard Crestez
  -- strict thread matches above, loose matches on Subject: below --
2019-10-16 10:37 Rafael J. Wysocki
2019-10-16 14:23 ` Sudeep Holla
2019-10-17  9:57   ` Viresh Kumar
2019-10-17  9:59     ` Sudeep Holla
2019-10-17 16:34       ` Rafael J. Wysocki
2019-10-17 16:42         ` Sudeep Holla
2019-10-18  5:44         ` Viresh Kumar
2019-10-18  8:24           ` Rafael J. Wysocki
2019-10-18  8:27             ` Viresh Kumar
2019-10-18  8:30               ` Rafael J. Wysocki
2019-10-18  9:24                 ` Viresh Kumar
2019-10-18  9:26                   ` Rafael J. Wysocki
2019-10-18  9:28                     ` Viresh Kumar
2019-10-17 17:14   ` Sudeep Holla
2019-10-17  9:46 ` Viresh Kumar

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=VI1PR04MB7023DF47D046AEADB4E051EBEE680@VI1PR04MB7023.eurprd04.prod.outlook.com \
    --to=leonard.crestez@nxp.com \
    --cc=a.swigon@samsung.com \
    --cc=cw00.choi@samsung.com \
    --cc=digetx@gmail.com \
    --cc=georgi.djakov@linaro.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=mka@chromium.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=rjw@rjwysocki.net \
    --cc=saravanak@google.com \
    --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 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).