Re: [PATCH v2] PM / devfreq: Add support for QCOM devfreq firmware
From: Sudeep Holla <hidden>
Date: 2018-05-23 16:09:07
Also in:
linux-pm, lkml
As mentioned on the thread that add firmware based cpufreq support, IMO these 2 bindings look too similar and can be combined or at-least aligned. On Fri, May 18, 2018 at 12:52:40AM -0700, Saravana Kannan wrote:
The firmware present in some QCOM chipsets offloads the steps necessary for changing the frequency of some devices (Eg: L3). This driver implements the devfreq interface for this firmware so that various governors could be used to scale the frequency of these devices.
Is this firmware the same one which controls the CPUFreq described in the other thread adding cpufreq support ?
quoted hunk ↗ jump to hunk
Each client (say cluster 0 and cluster 1) that wants to vote for a particular device's frequency (say, L3 frequency) is represented as a separate voter device (qcom,devfreq-fw-voter) that's a child of the firmware device (qcom,devfreq-fw). Signed-off-by: Saravana Kannan <redacted> --- .../bindings/devfreq/devfreq-qcom-fw.txt | 41 +++ drivers/devfreq/Kconfig | 14 + drivers/devfreq/Makefile | 1 + drivers/devfreq/devfreq_qcom_fw.c | 330 +++++++++++++++++++++ 4 files changed, 386 insertions(+) create mode 100644 Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt create mode 100644 drivers/devfreq/devfreq_qcom_fw.cdiff --git a/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt new file mode 100644 index 0000000..f882a0b --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt@@ -0,0 +1,41 @@ +QCOM Devfreq firmware device + +Some Qualcomm Technologies, Inc. (QTI) chipsets have a firmware that +offloads the steps for frequency switching. It provides a table of +supported frequencies and a register to request one of the supported +freqencies. + +The qcom,devfreq-fw represents this firmware as a device. Sometimes,
As a whole or just a part of it ? I am getting an impression that this firmware is divided into 'n' different pieces and each of them is represented as a separate device.
+multiple entities want to vote on the frequency request that is sent to the +firmware. The qcom,devfreq-fw-voter represents these voters as child +devices of the corresponding qcom,devfreq-fw device. + +Required properties: +- compatible: Must be "qcom,devfreq-fw" or "qcom,devfreq-fw-voter"
If this is the same firmware, name it after. What do you need one name per subsystem in Linux for the same firmware ?
+Only for qcom,devfreq-fw: +- reg: Pairs of physical base addresses and region sizes of + memory mapped registers. +- reg-names: Names of the bases for the above registers. + Required register regions are: + - "en-base": address of register to check if the + firmware is enabled. + - "ftbl-base": address region for the frequency + table.
It's called "lut-base" in the cpufreq binding and that's the only difference I see.
+ - "perf-base": address of register to request a + frequency. +
[...]
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lut-base");
+ if (!res) {
+ dev_err(dev, "Unable to find lut-base!\n");
+ return -EINVAL;
+ }
+...but in the binding it's called "ftbl-base" -- Regards, Sudeep