[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240222135702.2005635-1-pierre.gondois@arm.com>
Date: Thu, 22 Feb 2024 14:56:58 +0100
From: Pierre Gondois <pierre.gondois@....com>
To: linux-kernel@...r.kernel.org
Cc: Cristian Marussi <cristian.marussi@....com>,
Christian Loehle <christian.loehle@....com>,
Ionela Voinescu <ionela.voinescu@....com>,
Sudeep Holla <sudeep.holla@....com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Pierre Gondois <pierre.gondois@....com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
linux-arm-kernel@...ts.infradead.org,
linux-pm@...r.kernel.org
Subject: [PATCH 0/3] scmi-cpufreq: Set transition_delay_us
policy's fields definitions:
`transition_delay_us`:
The minimum amount of time between two consecutive freq. requests
for one policy.
`transition_latency`:
Delta between freq. change request and effective freq. change on
the hardware.
cpufreq_policy_transition_delay_us() uses the `transition_delay_us`
value if available. Otherwise a value is induced from the policy's
`transition_latency`.
The scmi-cpufreq driver doesn't populate the `transition_delay_us`.
Values matching the definition are available through the SCMI
specification.
Add support to fetch these values and use them in the scmi-cpufreq
driver.
Pierre Gondois (3):
firmware: arm_scmi: Populate perf commands rate_limit
firmware: arm_scmi: Populate fast channel rate_limit
cpufreq: scmi: Set transition_delay_us
drivers/cpufreq/scmi-cpufreq.c | 26 +++++++++++++
drivers/firmware/arm_scmi/driver.c | 5 ++-
drivers/firmware/arm_scmi/perf.c | 53 +++++++++++++++++++++++++--
drivers/firmware/arm_scmi/powercap.c | 12 ++++--
drivers/firmware/arm_scmi/protocols.h | 4 +-
include/linux/scmi_protocol.h | 8 ++++
6 files changed, 98 insertions(+), 10 deletions(-)
--
2.25.1
Powered by blists - more mailing lists