Linux-ARM-MSM Archive on
 help / color / Atom feed
From: Rajendra Nayak <>
To: Viresh Kumar <>,,,
Subject: Re: [RFC v2 01/11] OPP: Don't overwrite rounded clk rate
Date: Fri, 14 Jun 2019 11:24:28 +0530
Message-ID: <> (raw)
In-Reply-To: <20190613095419.lfjeko7nmxtix2n4@vireshk-i7>

> Now, the request to change the frequency starts from cpufreq
> governors, like schedutil when they calls:
> __cpufreq_driver_target(policy, 599 MHz, CPUFREQ_RELATION_L);
> CPUFREQ_RELATION_L means: lowest frequency at or above target. And so
> I would expect the frequency to get set to 600MHz (if we look at clock
> driver) or 700MHz (if we look at OPP table). I think we should decide
> this thing from the OPP table only as that's what the platform guys
> want us to use. So, we should end up with 700 MHz.
> Then we land into dev_pm_opp_set_rate(), which does this (which is
> code copied from earlier version of cpufreq-dt driver):

so before we land into dev_pm_opp_set_rate() from a __cpufreq_driver_target()
I guess we do have a cpufreq driver callback that gets called in between?
which is either .target_index or .target

In case of .target_index, the cpufreq core looks for a OPP index
and we would land up with 700Mhz i guess, so we are good.

In case of .target though the 'relation' CPUFREQ_RELATION_L does get passed over
to the cpufreq driver which I am guessing is expected to handle it in some way to
make sure the target frequency set is not less than whats requested? instead of
simply passing the requested frequency over to dev_pm_opp_set_rate()?

Looking at all the existing cpufreq drivers upstream, while most support .target_index
the 3 which do support .target seem to completely ignore this 'relation' input that's
passed to them.

drivers/cpufreq/cppc_cpufreq.c:	.target = cppc_cpufreq_set_target,
drivers/cpufreq/cpufreq-nforce2.c:	.target = nforce2_target,
drivers/cpufreq/pcc-cpufreq.c:	.target = pcc_cpufreq_target,

> This kind of behavior (introduced by this patch) is important for
> other devices which want to run at the nearest frequency to target
> one, but not for CPUs/GPUs. So, we need to tag these IO devices
> separately, maybe from DT ? So we select the closest match instead of
> most optimal one.

yes we do need some way to distinguish between CPU/GPU devices and other
IO devices. CPU/GPU can always run at fmax for a given voltage, that's not true
for IO devices and I don't see how we can satisfy both cases without
clearly knowing if we are serving a processor or an IO device, unless the
higher layers (cpufreq/devfreq) are able to handle this somehow without
expecting the OPP layer to handle the differences.

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

  parent reply index

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-20  9:49 [RFC v2 00/11] DVFS in the OPP core Rajendra Nayak
2019-03-20  9:49 ` [RFC v2 01/11] OPP: Don't overwrite rounded clk rate Rajendra Nayak
2019-06-11 10:54   ` Viresh Kumar
2019-06-12  7:42     ` Rajendra Nayak
2019-06-12  8:25       ` Viresh Kumar
2019-06-13  9:54         ` Viresh Kumar
2019-06-14  5:27           ` Viresh Kumar
2019-06-17  3:50             ` Viresh Kumar
2019-06-17  4:07               ` Rajendra Nayak
2019-06-17  4:17                 ` Viresh Kumar
2019-06-17  4:25                   ` Rajendra Nayak
2019-06-14  5:54           ` Rajendra Nayak [this message]
2019-03-20  9:49 ` [RFC v2 02/11] OPP: Make dev_pm_opp_set_rate() with freq=0 as valid Rajendra Nayak
2019-06-14  6:32   ` Viresh Kumar
2019-06-17  4:04     ` Rajendra Nayak
2019-03-20  9:49 ` [RFC v2 03/11] tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state Rajendra Nayak
2019-03-20  9:49 ` [RFC v2 04/11] spi: spi-geni-qcom: " Rajendra Nayak
2019-03-20  9:49 ` [RFC v2 05/11] arm64: dts: sdm845: Add OPP table for all qup devices Rajendra Nayak
2019-03-20  9:49 ` [RFC v2 06/11] scsi: ufs: Add support to manage multiple power domains in ufshcd-pltfrm Rajendra Nayak
2019-03-20  9:49 ` [RFC v2 07/11] scsi: ufs: Add support for specifying OPP tables in DT Rajendra Nayak
2019-03-20  9:49 ` [RFC v2 08/11] arm64: dts: sdm845: Add ufs opps and power-domains Rajendra Nayak
2019-05-14  7:53   ` Ulf Hansson
2019-03-20  9:49 ` [RFC v2 09/11] drm/msm/dpu: Use OPP API to set clk/perf state Rajendra Nayak
2019-04-10  3:49   ` Viresh Kumar
2019-04-10  3:49     ` Viresh Kumar
2019-03-20  9:49 ` [RFC v2 10/11] drm/msm: dsi: " Rajendra Nayak
2019-03-20  9:49 ` [RFC v2 11/11] arm64: dts: sdm845: Add DSI and MDP OPP tables and power-domains Rajendra Nayak
2019-04-10  3:51 ` [RFC v2 00/11] DVFS in the OPP core Viresh Kumar
2019-04-10  3:51   ` Viresh Kumar
2019-05-21  6:22 ` Viresh Kumar
2019-05-24  6:03   ` Rajendra Nayak
2019-06-17  4:26 ` Viresh Kumar

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ARM-MSM Archive on

Archives are clonable:
	git clone --mirror linux-arm-msm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-msm linux-arm-msm/ \
	public-inbox-index linux-arm-msm

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox