This driver reads very platform specific information in from Device Tree
and translates it into frequency tables. The generic drivers then use the
tables to conduct frequency and voltage scaling in the normal way.
There are 'ARM' patches in the set which are not necessarily related to CPUFreq,
but are required to get it to work. Anyone who is not interested in general STi
DT changes can safely ignore these.
v1 => v2:
- CPUFreq is no longer it's own device in DT; instead:
- It is probed from the platform area
- Key properties have been moved into the CPU's node
- Driver is less generic [ST => STI]
- Documentation has been updated
- Point one (above) has been accounted for
- Example of bootloader supplied node has been provided
- GPL licensing has been updated to reflected the header
- Kconfig disparity has been rectified [bool => tristate]
Lee Jones (9):
ARM: STi: STiH407: Provide generic (safe) DVFS configuration
ARM: STi: STiH407: Provide CPU with clocking information
ARM: STi: STiH407: Link CPU with its voltage supply
ARM: STi: STiH407: Provide CPU with a means to look-up Major number
ARM: STi: Register CPUFreq device
ARM: STi: STiH407: Move PWM nodes STiH407 => STiH407-family
ARM: multi_v7_defconfig: Enable support for PWM Regulators
dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation
cpufreq: st: Provide runtime initialised driver for ST's platforms
.../devicetree/bindings/cpufreq/cpufreq-st.txt | 72 ++++
arch/arm/boot/dts/stih407-family.dtsi | 45 +++
arch/arm/boot/dts/stih407.dtsi | 28 --
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/mach-sti/Makefile | 2 +-
arch/arm/mach-sti/board-dt.c | 3 +-
arch/arm/mach-sti/{platsmp.c => cpu.c} | 17 +-
arch/arm/mach-sti/{smp.h => cpu.h} | 2 +
drivers/cpufreq/Kconfig.arm | 7 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/sti-cpufreq.c | 447 +++++++++++++++++++++
11 files changed, 593 insertions(+), 32 deletions(-)
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
rename arch/arm/mach-sti/{platsmp.c => cpu.c} (91%)
rename arch/arm/mach-sti/{smp.h => cpu.h} (92%)
create mode 100644 drivers/cpufreq/sti-cpufreq.c
--
1.9.1
You'll notice that the voltage cell is populated with 0's. Voltage
information is very platform specific, even depends on 'cut' and
'substrate' versions. Thus it is left blank for a generic (safe)
implementation. If other nodes/properties are provided by the
bootloader, the ST CPUFreq driver will over-ride these generic
values.
Signed-off-by: Lee Jones <[email protected]>
---
arch/arm/boot/dts/stih407-family.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index be201aa..2680ac7 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -22,11 +22,21 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ /* kHz uV */
+ operating-points = <1500000 0
+ 1200000 0
+ 800000 0
+ 500000 0>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+ /* kHz uV */
+ operating-points = <1500000 0
+ 1200000 0
+ 800000 0
+ 500000 0>;
};
};
--
1.9.1
Signed-off-by: Lee Jones <[email protected]>
---
arch/arm/boot/dts/stih407-family.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 2680ac7..fcab003 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -27,6 +27,10 @@
1200000 0
800000 0
500000 0>;
+
+ clocks = <&clk_m_a9>;
+ clock-names = "cpu";
+ clock-latency = <100000>;
};
cpu@1 {
device_type = "cpu";
--
1.9.1
Used for Voltage Scaling using CPUFreq.
Signed-off-by: Lee Jones <[email protected]>
---
arch/arm/boot/dts/stih407-family.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index fcab003..f48767e 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -31,6 +31,7 @@
clocks = <&clk_m_a9>;
clock-names = "cpu";
clock-latency = <100000>;
+ cpu0-supply = <&pwm_regulator>;
};
cpu@1 {
device_type = "cpu";
--
1.9.1
This is used for CPU Frequency Scaling.
Signed-off-by: Lee Jones <[email protected]>
---
arch/arm/boot/dts/stih407-family.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index f48767e..838f1c3 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -32,6 +32,7 @@
clock-names = "cpu";
clock-latency = <100000>;
cpu0-supply = <&pwm_regulator>;
+ st,syscfg = <&syscfg_core 0x8e0>;
};
cpu@1 {
device_type = "cpu";
--
1.9.1
DT will not allow pseudo-devices. Only devices which represent real
hardware are permitted. So we have to register the CPUFreq driver
from platform code instead.
Rather than create a new file, we're bundling this in with the SMP
functionality and renaming it from 'smp' to the more generic 'cpu'.
Signed-off-by: Lee Jones <[email protected]>
---
arch/arm/mach-sti/Makefile | 2 +-
arch/arm/mach-sti/board-dt.c | 3 ++-
arch/arm/mach-sti/{platsmp.c => cpu.c} | 17 +++++++++++++++--
arch/arm/mach-sti/{smp.h => cpu.h} | 2 ++
4 files changed, 20 insertions(+), 4 deletions(-)
rename arch/arm/mach-sti/{platsmp.c => cpu.c} (91%)
rename arch/arm/mach-sti/{smp.h => cpu.h} (92%)
diff --git a/arch/arm/mach-sti/Makefile b/arch/arm/mach-sti/Makefile
index acb3309..caaeeaa 100644
--- a/arch/arm/mach-sti/Makefile
+++ b/arch/arm/mach-sti/Makefile
@@ -1,2 +1,2 @@
-obj-$(CONFIG_SMP) += platsmp.o headsmp.o
+obj-$(CONFIG_SMP) += cpu.o headsmp.o
obj-$(CONFIG_ARCH_STI) += board-dt.o
diff --git a/arch/arm/mach-sti/board-dt.c b/arch/arm/mach-sti/board-dt.c
index b373aca..482159f 100644
--- a/arch/arm/mach-sti/board-dt.c
+++ b/arch/arm/mach-sti/board-dt.c
@@ -12,7 +12,7 @@
#include <asm/hardware/cache-l2x0.h>
#include <asm/mach/arch.h>
-#include "smp.h"
+#include "cpu.h"
static const char *stih41x_dt_match[] __initdata = {
"st,stih415",
@@ -31,4 +31,5 @@ DT_MACHINE_START(STM, "STiH415/416 SoC with Flattened Device Tree")
L2C_AUX_CTRL_WAY_SIZE(4),
.l2c_aux_mask = 0xc0000fff,
.smp = smp_ops(sti_smp_ops),
+ .init_late = init_cpufreq,
MACHINE_END
diff --git a/arch/arm/mach-sti/platsmp.c b/arch/arm/mach-sti/cpu.c
similarity index 91%
rename from arch/arm/mach-sti/platsmp.c
rename to arch/arm/mach-sti/cpu.c
index d4b624f..283cb30 100644
--- a/arch/arm/mach-sti/platsmp.c
+++ b/arch/arm/mach-sti/cpu.c
@@ -1,5 +1,5 @@
/*
- * arch/arm/mach-sti/platsmp.c
+ * arch/arm/mach-sti/cpu.c
*
* Copyright (C) 2013 STMicroelectronics (R&D) Limited.
* http://www.st.com
@@ -13,6 +13,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/delay.h>
@@ -20,13 +21,17 @@
#include <linux/io.h>
#include <linux/of.h>
#include <linux/of_address.h>
+#include <linux/platform_device.h>
#include <asm/cacheflush.h>
#include <asm/smp_plat.h>
#include <asm/smp_scu.h>
-#include "smp.h"
+#include "cpu.h"
+/**
+ * SMP Operations
+ */
static void write_pen_release(int val)
{
pen_release = val;
@@ -114,3 +119,11 @@ struct smp_operations __initdata sti_smp_ops = {
.smp_secondary_init = sti_secondary_init,
.smp_boot_secondary = sti_boot_secondary,
};
+
+/**
+ * CPUFreq Registration
+ */
+void init_cpufreq(void)
+{
+ platform_device_register_simple("sti-cpufreq", -1, NULL, 0);
+}
diff --git a/arch/arm/mach-sti/smp.h b/arch/arm/mach-sti/cpu.h
similarity index 92%
rename from arch/arm/mach-sti/smp.h
rename to arch/arm/mach-sti/cpu.h
index 1871b72..39e05ff 100644
--- a/arch/arm/mach-sti/smp.h
+++ b/arch/arm/mach-sti/cpu.h
@@ -14,4 +14,6 @@
extern struct smp_operations sti_smp_ops;
+extern void init_cpufreq(void);
+
#endif
--
1.9.1
This also incorporates the STiH410.
Signed-off-by: Lee Jones <[email protected]>
---
arch/arm/boot/dts/stih407-family.dtsi | 29 +++++++++++++++++++++++++++++
arch/arm/boot/dts/stih407.dtsi | 28 ----------------------------
2 files changed, 29 insertions(+), 28 deletions(-)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 838f1c3..477e92a 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -565,5 +565,34 @@
status = "disabled";
};
+
+ /* COMMS PWM Module */
+ pwm0: pwm@9810000 {
+ compatible = "st,sti-pwm";
+ status = "okay";
+ #pwm-cells = <2>;
+ reg = <0x9810000 0x68>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm0_chan0_default>;
+ clock-names = "pwm";
+ clocks = <&clk_sysin>;
+ st,pwm-num-chan = <1>;
+ };
+
+ /* SBC PWM Module */
+ pwm1: pwm@9510000 {
+ compatible = "st,sti-pwm";
+ status = "okay";
+ #pwm-cells = <2>;
+ reg = <0x9510000 0x68>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1_chan0_default
+ &pinctrl_pwm1_chan1_default
+ &pinctrl_pwm1_chan2_default
+ &pinctrl_pwm1_chan3_default>;
+ clock-names = "pwm";
+ clocks = <&clk_sysin>;
+ st,pwm-num-chan = <4>;
+ };
};
};
diff --git a/arch/arm/boot/dts/stih407.dtsi b/arch/arm/boot/dts/stih407.dtsi
index 2c560fc3..3efa3b2 100644
--- a/arch/arm/boot/dts/stih407.dtsi
+++ b/arch/arm/boot/dts/stih407.dtsi
@@ -147,33 +147,5 @@
};
};
};
-
- /* COMMS PWM Module */
- pwm0: pwm@9810000 {
- compatible = "st,sti-pwm";
- status = "disabled";
- #pwm-cells = <2>;
- reg = <0x9810000 0x68>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_pwm0_chan0_default>;
- clock-names = "pwm";
- clocks = <&clk_sysin>;
- };
-
- /* SBC PWM Module */
- pwm1: pwm@9510000 {
- compatible = "st,sti-pwm";
- status = "disabled";
- #pwm-cells = <2>;
- reg = <0x9510000 0x68>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_pwm1_chan0_default
- &pinctrl_pwm1_chan1_default
- &pinctrl_pwm1_chan2_default
- &pinctrl_pwm1_chan3_default>;
- clock-names = "pwm";
- clocks = <&clk_sysin>;
- st,pwm-num-chan = <4>;
- };
};
};
--
1.9.1
Signed-off-by: Lee Jones <[email protected]>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index f632af0..6666973 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -365,6 +365,7 @@ CONFIG_REGULATOR_MAX8907=y
CONFIG_REGULATOR_MAX8973=y
CONFIG_REGULATOR_MAX77686=y
CONFIG_REGULATOR_PALMAS=y
+CONFIG_REGULATOR_PWM=y
CONFIG_REGULATOR_S2MPS11=y
CONFIG_REGULATOR_S5M8767=y
CONFIG_REGULATOR_TPS51632=y
--
1.9.1
Cc: [email protected]
Signed-off-by: Lee Jones <[email protected]>
---
.../devicetree/bindings/cpufreq/cpufreq-st.txt | 72 ++++++++++++++++++++++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
new file mode 100644
index 0000000..e871a9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
@@ -0,0 +1,72 @@
+Binding for ST's CPUFreq driver
+===============================
+
+Required properties [for working voltage scaling]:
+-------------------------------------------------
+
+Located in CPU's node:
+
+- st,syscfg : Phandle to Major number register
+ First cell: offset to major number
+- st,syscfg-eng : Phandle to Minor number and Pcode registers
+ First cell: offset to process code
+ Second cell: offset to minor number
+- st,opp-list : Bootloader provided node containing one or more 'opp@X' sub-nodes
+ - opp@{1..X} : Each 'opp@X' subnode will contain the following properties:
+ - st,avs : List of available voltages [uV] indexed by process code
+ - st,freq : CPU frequency [Hz] for this OPP
+ - st,cuts : Cut version this OPP is suitable for [0xFF means ALL]
+ - st,substrate : Substrate version this OPP is suitable for [0xFF means ALL]
+
+WARNING: The st,opp-list will be provided by the bootloader. Do not attempt to
+ artificially synthesise the st,opp-list node or any of its descendants.
+ They are very platform specific and may damage the hardware if created
+ incorrectly.
+
+Required properties [if the voltage scaling properties are missing]:
+-------------------------------------------------------------------
+
+Located in CPU's node:
+
+- operating-points : [See: ../power/opp.txt]
+
+Example [safe]:
+--------------
+
+cpus {
+ cpu@0 {
+ /* kHz uV */
+ operating-points = <1500000 0
+ 1200000 0
+ 800000 0
+ 500000 0>;
+ };
+};
+
+Example [unsafe]:
+----------------
+
+cpus {
+ cpu@0 {
+ st,syscfg = <&syscfg [major_offset]>;
+ st,syscfg-eng = <&syscfg_eng [pcode_offset] [minor_offset]>;
+
+ /* ########################################################### */
+ /* # WARNING: Do not attempt to copy/replicate this node !!! # */
+ /* ########################################################### */
+ st,opp-list {
+ opp0 {
+ st,avs = <1110 1150 1100 1080 1040 1020 980 930>;
+ st,freq = <1200000>;
+ st,substrate = <0xff>;
+ st,cuts = <0xff>;
+ };
+ opp1 {
+ st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>;
+ st,freq = <1500000>;
+ st,substrate = <0xff>;
+ st,cuts = <0x2>;
+ };
+ };
+ };
+};
--
1.9.1
The bootloader is charged with the responsibility to provide platform
specific Dynamic Voltage and Frequency Scaling (DVFS) information via
Device Tree. This driver takes the supplied configuration and loads
it into the generic OPP subsystem to it can be used as part of the
CPUFreq framework.
Signed-off-by: Lee Jones <[email protected]>
---
drivers/cpufreq/Kconfig.arm | 7 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/sti-cpufreq.c | 447 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 455 insertions(+)
create mode 100644 drivers/cpufreq/sti-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 4f3dbc8..cd0e4e5 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -258,6 +258,13 @@ config ARM_SPEAR_CPUFREQ
help
This adds the CPUFreq driver support for SPEAr SOCs.
+config ARM_STI_CPUFREQ
+ tristate "STi CPUFreq support"
+ depends on SOC_STIH407
+ help
+ OPP list for cpufreq-dt driver can be provided through DT or can be
+ created at runtime. Select this if you want create OPP list at runtime.
+
config ARM_TEGRA_CPUFREQ
bool "TEGRA CPUFreq support"
depends on ARCH_TEGRA
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index cdce92a..557a22c 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_ARM_S5PV210_CPUFREQ) += s5pv210-cpufreq.o
obj-$(CONFIG_ARM_SA1100_CPUFREQ) += sa1100-cpufreq.o
obj-$(CONFIG_ARM_SA1110_CPUFREQ) += sa1110-cpufreq.o
obj-$(CONFIG_ARM_SPEAR_CPUFREQ) += spear-cpufreq.o
+obj-$(CONFIG_ARM_STI_CPUFREQ) += sti-cpufreq.o
obj-$(CONFIG_ARM_TEGRA_CPUFREQ) += tegra-cpufreq.o
obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
diff --git a/drivers/cpufreq/sti-cpufreq.c b/drivers/cpufreq/sti-cpufreq.c
new file mode 100644
index 0000000..48a3410
--- /dev/null
+++ b/drivers/cpufreq/sti-cpufreq.c
@@ -0,0 +1,447 @@
+/*
+ * Create CPUFreq OPP list
+ *
+ * Author: Ajit Pal Singh <[email protected]>
+ * Lee Jones <[email protected]>
+ *
+ * Copyright (C) 2015 STMicroelectronics (R&D) Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/cpu.h>
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/pm_opp.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/mfd/syscon.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/sort.h>
+
+#include <linux/cpufreq.h>
+
+#define VERSION_SHIFT 28
+#define PCODE_INDEX 1
+#define MAJOR_ID_INDEX 1
+#define MINOR_ID_INDEX 2
+
+enum {
+ PCODE = 0,
+ SUBSTRATE,
+ DVFS_MAX_REGFIELDS,
+};
+
+#define STI_DVFS_TAB_MAX 8
+
+struct st_dvfs_tab {
+ unsigned int freq;
+ unsigned int avs;
+};
+
+/**
+ * ST CPUFreq Driver Data
+ *
+ * @dvfs_tab Supported Voltage/Frequency table
+ * @dvfs_tab_count Number of entries in the table above
+ * @pcode Device's Process Code determines the running voltage
+ * @substrate Device's Substrate version -- as above
+ * @regmap_eng Engineering Syscon register map
+ *
+ */
+struct st_cpufreq_ddata {
+ struct device *cpu;
+ struct st_dvfs_tab dvfs_tab[STI_DVFS_TAB_MAX];
+ int dvfs_tab_count;
+ int pcode;
+ int substrate;
+ struct regmap *regmap_eng;
+
+};
+
+struct sti_dvfs_cdata {
+ const struct reg_field *reg_fields;
+};
+
+static int st_cpufreq_cmp(const void *a, const void *b)
+{
+ const struct st_dvfs_tab *a_tab = a, *b_tab = b;
+
+ if (a_tab->freq > b_tab->freq)
+ return -1;
+
+ if (a_tab->freq < b_tab->freq)
+ return 1;
+
+ return 0;
+}
+
+static int st_cpufreq_check_if_matches(struct device_node *child,
+ const char *prop,
+ unsigned int match)
+{
+ unsigned int dt_major, dt_minor;
+ unsigned int soc_major, soc_minor;
+ const __be32 *tmp;
+ unsigned int val;
+ int len = 0;
+ int i;
+
+ tmp = of_get_property(child, prop , &len);
+ if (!tmp || !len)
+ return -EINVAL;
+
+ val = be32_to_cpup(tmp);
+
+ len /= sizeof(u32);
+ if (len == 1 && val == 0xff)
+ /*
+ * If 'cuts' or 'substrate' value is 0xff, it means that
+ * the entry is valid for ALL cuts and substrates
+ */
+ goto matchfound;
+
+ /* Check if this opp node is for us */
+ for (i = 0; i < len; i++) {
+ if (match == val)
+ goto matchfound;
+
+ if (!strcmp(prop, "st,cuts")) {
+ dt_major = val & 0xff;;
+ dt_minor = val >> 8 & 0xff;
+ soc_major = match & 0xff;
+ soc_minor = match >> 8 & 0xff;
+
+ if (dt_major == soc_major &&
+ (!dt_minor || (dt_minor == soc_minor)))
+ goto matchfound;
+ }
+ val++;
+ }
+
+ /* No match found */
+ return -EINVAL;
+
+matchfound:
+ return 0;
+}
+
+static int st_cpufreq_get_version(struct platform_device *pdev,
+ unsigned int *minor, unsigned int *major)
+{
+ struct st_cpufreq_ddata *ddata = platform_get_drvdata(pdev);
+ struct device_node *cpu = ddata->cpu->of_node;
+ struct regmap *syscfg_regmap;
+ unsigned int minor_offset, major_offset;
+ unsigned int socid, minid;
+ int ret;
+
+ /* Get Major */
+ syscfg_regmap = syscon_regmap_lookup_by_phandle(cpu, "st,syscfg");
+ if (IS_ERR(syscfg_regmap)) {
+ dev_err(&pdev->dev,
+ "No syscfg phandle specified in %s [%li]\n",
+ cpu->full_name, PTR_ERR(syscfg_regmap));
+ return PTR_ERR(syscfg_regmap);
+ }
+
+ ret = of_property_read_u32_index(cpu, "st,syscfg",
+ MAJOR_ID_INDEX, &major_offset);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "No minor number offset provided in %s [%d]\n",
+ cpu->full_name, ret);
+ return ret;
+ }
+
+ ret = regmap_read(syscfg_regmap, major_offset, &socid);
+ if (ret)
+ return ret;
+
+ /* Get Minor */
+ ret = of_property_read_u32_index(cpu, "st,syscfg-eng",
+ MINOR_ID_INDEX, &minor_offset);
+ if (ret) {
+ dev_err(&pdev->dev, "No minor number offset provided %s [%d]\n",
+ cpu->full_name, ret);
+ return ret;
+ }
+
+ ret = regmap_read(ddata->regmap_eng, minor_offset, &minid);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Failed to read the minor number from syscon [%d]\n",
+ ret);
+ return ret;
+ }
+
+ *major = ((socid >> VERSION_SHIFT) & 0xf) + 1;
+ *minor = minid & 0xf;
+
+ return 0;
+}
+
+static int st_cpufreq_get_dvfs_info(struct platform_device *pdev)
+{
+ struct st_cpufreq_ddata *ddata = platform_get_drvdata(pdev);
+ struct st_dvfs_tab *dvfs_tab = &ddata->dvfs_tab[0];
+ struct device_node *cpu = ddata->cpu->of_node;
+ struct device_node *opplist, *opp;
+ unsigned int minor = 0, major = 0;
+ int err, ret = 0;
+
+ opplist = of_get_child_by_name(cpu, "st,opp-list");
+ if (!opplist) {
+ dev_err(&pdev->dev, "st,opp-list node missing\n");
+ return -ENODATA;
+ }
+
+ ret = st_cpufreq_get_version(pdev, &minor, &major);
+ if (ret) {
+ dev_err(&pdev->dev, "No OPP match found for this platform\n");
+ return ret;
+ }
+
+ for_each_child_of_node(opplist, opp) {
+ if (ddata->dvfs_tab_count == STI_DVFS_TAB_MAX) {
+ dev_err(&pdev->dev, "Too many DVFS entries found\n");
+ ret = -EOVERFLOW;
+ break;
+ }
+
+ /* Cut version e.g. 2.0 [major.minor] */
+ err = st_cpufreq_check_if_matches(opp, "st,cuts",
+ (minor << 8) | major);
+ if (err)
+ continue;
+
+ ret = st_cpufreq_check_if_matches(opp, "st,substrate",
+ ddata->substrate);
+ if (err)
+ continue;
+
+ ret = of_property_read_u32(opp, "st,freq", &dvfs_tab->freq);
+ if (ret) {
+ dev_err(&pdev->dev, "Can't read frequency: %d\n", ret);
+ goto out;
+ }
+ dvfs_tab->freq *= 1000;
+
+ ret = of_property_read_u32_index(opp, "st,avs",
+ ddata->pcode,
+ &dvfs_tab->avs);
+ if (ret) {
+ dev_err(&pdev->dev, "Can't read AVS: %d\n", ret);
+ goto out;
+ }
+
+ dvfs_tab++;
+ ddata->dvfs_tab_count++;
+ }
+
+ sort(&ddata->dvfs_tab[0], ddata->dvfs_tab_count,
+ sizeof(struct st_dvfs_tab), st_cpufreq_cmp, NULL);
+
+out:
+ of_node_put(opplist);
+
+ if (!ddata->dvfs_tab_count) {
+ dev_err(&pdev->dev, "No suitable AVS table found\n");
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+static int sti_cpufreq_voltage_scaling_init(struct platform_device *pdev)
+{
+ struct st_cpufreq_ddata *ddata = platform_get_drvdata(pdev);
+ struct st_dvfs_tab *dvfs_tab = &ddata->dvfs_tab[0];
+ struct dev_pm_opp *opp;
+ unsigned long highest_freq = 0;
+ int ret;
+ int i;
+
+ /* Populate OPP table with default non-AVS frequency values */
+ of_init_opp_table(ddata->cpu);
+
+ /*
+ * Disable, but keep default values -- this prevents the framework from
+ * erroneously re-adding and enabling entries with missing voltage rates
+ */
+ while (1) {
+ highest_freq++;
+
+ opp = dev_pm_opp_find_freq_ceil(ddata->cpu, &highest_freq);
+ if (IS_ERR(opp))
+ break;
+
+ ret = dev_pm_opp_disable(ddata->cpu, highest_freq);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to disable freq: %li\n",
+ highest_freq);
+ return ret;
+ }
+ }
+
+ for (i = 0; i < ddata->dvfs_tab_count; i++, dvfs_tab++) {
+ unsigned int f = dvfs_tab->freq * 1000;
+ unsigned int v = dvfs_tab->avs * 1000;
+
+ opp = dev_pm_opp_find_freq_exact(ddata->cpu, f, false);
+
+ /* Remove existing voltage-less OPP entry */
+ if (!IS_ERR(opp))
+ dev_pm_opp_remove(ddata->cpu, f);
+
+ /* Supply new fully populated OPP entry */
+ ret = dev_pm_opp_add(ddata->cpu, f, v);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to add OPP %u\n", f);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static int st_cpufreq_fetch_regmap_field(struct platform_device *pdev,
+ const struct reg_field *reg_fields,
+ int pcode_offset, int field)
+{
+ struct st_cpufreq_ddata *ddata = platform_get_drvdata(pdev);
+ struct regmap_field *regmap_field;
+ struct reg_field reg_field = reg_fields[field];
+ unsigned int value;
+ int ret;
+
+ reg_field.reg = pcode_offset;
+ regmap_field = devm_regmap_field_alloc(&pdev->dev,
+ ddata->regmap_eng,
+ reg_field);
+ if (IS_ERR(regmap_field)) {
+ dev_err(&pdev->dev, "Failed to allocate reg field\n");
+ return PTR_ERR(regmap_field);
+ }
+
+ ret = regmap_field_read(regmap_field, &value);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to read %s code\n",
+ field ? "SUBSTRATE" : "PCODE");
+ return ret;
+ }
+
+ return value;
+}
+
+static const struct reg_field sti_stih407_dvfs_regfields[DVFS_MAX_REGFIELDS] = {
+ [PCODE] = REG_FIELD(0, 16, 19),
+ [SUBSTRATE] = REG_FIELD(0, 0, 2),
+};
+
+static const struct reg_field *sti_cpufreq_match(struct platform_device *pdev)
+{
+ if (of_machine_is_compatible("st,stih407") ||
+ of_machine_is_compatible("st,stih410"))
+ return sti_stih407_dvfs_regfields;
+
+ return NULL;
+}
+
+/* Find process code -- calibrated per-SoC */
+static void sti_cpufreq_get_pcode(struct platform_device *pdev)
+{
+ struct st_cpufreq_ddata *ddata = platform_get_drvdata(pdev);
+ struct device_node *cpu = ddata->cpu->of_node;
+ const struct reg_field *reg_fields;
+ int pcode_offset;
+ int ret;
+
+ ddata->regmap_eng = syscon_regmap_lookup_by_phandle(cpu, "st,syscfg-eng");
+ if (IS_ERR(ddata->regmap_eng)) {
+ dev_warn(&pdev->dev, "\"st,syscfg-eng\" not supplied\n");
+ goto set_default;
+ }
+
+ ret = of_property_read_u32_index(cpu, "st,syscfg-eng",
+ PCODE_INDEX, &pcode_offset);
+ if (ret) {
+ dev_warn(&pdev->dev, "Process code offset is required\n");
+ goto set_default;
+ }
+
+ reg_fields = sti_cpufreq_match(pdev);
+ if (!reg_fields) {
+ dev_warn(&pdev->dev, "Machine not supported\n");
+ goto set_default;
+ }
+
+ ddata->pcode = st_cpufreq_fetch_regmap_field(pdev, reg_fields,
+ pcode_offset,
+ PCODE);
+ if (ddata->pcode < 0)
+ goto set_default;
+
+ ddata->substrate = st_cpufreq_fetch_regmap_field(pdev, reg_fields,
+ pcode_offset,
+ SUBSTRATE);
+ if (ddata->substrate < 0)
+ goto set_default;
+
+ return;
+
+set_default:
+ dev_warn(&pdev->dev,
+ "Setting pcode to highest tolerance/voltage for safety\n");
+ ddata->pcode = 0;
+ ddata->substrate = 0;
+}
+
+static int sti_cpufreq_probe(struct platform_device *pdev)
+{
+ struct st_cpufreq_ddata *ddata;
+ int ret;
+
+ ddata = devm_kzalloc(&pdev->dev, sizeof(*ddata), GFP_KERNEL);
+ if (!ddata)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, ddata);
+
+ ddata->cpu = get_cpu_device(0);
+ if (!ddata->cpu) {
+ dev_err(&pdev->dev, "Failed to get cpu0 device\n");
+ return -ENODEV;
+ }
+
+ sti_cpufreq_get_pcode(pdev);
+
+ ret = st_cpufreq_get_dvfs_info(pdev);
+ if (ret)
+ dev_warn(&pdev->dev, "Not doing voltage scaling [%d]\n", ret);
+ else
+ sti_cpufreq_voltage_scaling_init(pdev);
+
+ platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+
+ return 0;
+}
+
+static struct platform_driver sti_cpufreq = {
+ .driver = {
+ .name = "sti-cpufreq",
+ },
+ .probe = sti_cpufreq_probe,
+};
+module_platform_driver(sti_cpufreq);
+
+MODULE_AUTHOR("Ajitpal Singh <[email protected]>");
+MODULE_DESCRIPTION("Creates an OPP list for cpufreq-cpu0 at runtime");
+MODULE_LICENSE("GPL");
+
--
1.9.1
Hello Lee,
On Wed, Jun 24, 2015 at 3:59 PM, Lee Jones <[email protected]> wrote:
> Signed-off-by: Lee Jones <[email protected]>
> ---
> arch/arm/configs/multi_v7_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index f632af0..6666973 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -365,6 +365,7 @@ CONFIG_REGULATOR_MAX8907=y
> CONFIG_REGULATOR_MAX8973=y
> CONFIG_REGULATOR_MAX77686=y
> CONFIG_REGULATOR_PALMAS=y
> +CONFIG_REGULATOR_PWM=y
The current policy is to build as much as possible as a module in
multi_v7_defconfig. Since this is a tristate Kconfig symbol, could you
please change it to =m ?
Best regards,
Javier
On Wed, 24 Jun 2015, Javier Martinez Canillas wrote:
> Hello Lee,
>
> On Wed, Jun 24, 2015 at 3:59 PM, Lee Jones <[email protected]> wrote:
> > Signed-off-by: Lee Jones <[email protected]>
> > ---
> > arch/arm/configs/multi_v7_defconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> > index f632af0..6666973 100644
> > --- a/arch/arm/configs/multi_v7_defconfig
> > +++ b/arch/arm/configs/multi_v7_defconfig
> > @@ -365,6 +365,7 @@ CONFIG_REGULATOR_MAX8907=y
> > CONFIG_REGULATOR_MAX8973=y
> > CONFIG_REGULATOR_MAX77686=y
> > CONFIG_REGULATOR_PALMAS=y
> > +CONFIG_REGULATOR_PWM=y
>
> The current policy is to build as much as possible as a module in
> multi_v7_defconfig. Since this is a tristate Kconfig symbol, could you
> please change it to =m ?
I would prefer that it stays built-in.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hello Lee,
On Thu, Jun 25, 2015 at 10:42 AM, Lee Jones <[email protected]> wrote:
> On Wed, 24 Jun 2015, Javier Martinez Canillas wrote:
[...]
>> > diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>> > index f632af0..6666973 100644
>> > --- a/arch/arm/configs/multi_v7_defconfig
>> > +++ b/arch/arm/configs/multi_v7_defconfig
>> > @@ -365,6 +365,7 @@ CONFIG_REGULATOR_MAX8907=y
>> > CONFIG_REGULATOR_MAX8973=y
>> > CONFIG_REGULATOR_MAX77686=y
>> > CONFIG_REGULATOR_PALMAS=y
>> > +CONFIG_REGULATOR_PWM=y
>>
>> The current policy is to build as much as possible as a module in
>> multi_v7_defconfig. Since this is a tristate Kconfig symbol, could you
>> please change it to =m ?
>
> I would prefer that it stays built-in.
>
Ok, I've no strong opinion on this. I was just mentioning what arm-soc
maintainers prefer nowadays.
May I ask what's the rationale for leaving this option built-in?
Best regards,
Javier
On Thu, 25 Jun 2015, Javier Martinez Canillas wrote:
> On Thu, Jun 25, 2015 at 10:42 AM, Lee Jones <[email protected]> wrote:
> > On Wed, 24 Jun 2015, Javier Martinez Canillas wrote:
>
> [...]
>
> >> > diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> >> > index f632af0..6666973 100644
> >> > --- a/arch/arm/configs/multi_v7_defconfig
> >> > +++ b/arch/arm/configs/multi_v7_defconfig
> >> > @@ -365,6 +365,7 @@ CONFIG_REGULATOR_MAX8907=y
> >> > CONFIG_REGULATOR_MAX8973=y
> >> > CONFIG_REGULATOR_MAX77686=y
> >> > CONFIG_REGULATOR_PALMAS=y
> >> > +CONFIG_REGULATOR_PWM=y
> >>
> >> The current policy is to build as much as possible as a module in
> >> multi_v7_defconfig. Since this is a tristate Kconfig symbol, could you
> >> please change it to =m ?
> >
> > I would prefer that it stays built-in.
> >
>
> Ok, I've no strong opinion on this. I was just mentioning what arm-soc
> maintainers prefer nowadays.
>
> May I ask what's the rationale for leaving this option built-in?
My view is that multi_v7 is used for prototyping, testing and to
ensure all of the vendors are playing nice together. Hopefully
vendors aren't actually releasing kernels built with this defconfig!
During testing/prototyping time; installing and messing around with
modules is an over-head I can do without.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hello Lee,
On Thu, Jun 25, 2015 at 5:02 PM, Lee Jones <[email protected]> wrote:
> On Thu, 25 Jun 2015, Javier Martinez Canillas wrote:
>> On Thu, Jun 25, 2015 at 10:42 AM, Lee Jones <[email protected]> wrote:
>> > On Wed, 24 Jun 2015, Javier Martinez Canillas wrote:
>>
>> [...]
>>
>> >> > diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>> >> > index f632af0..6666973 100644
>> >> > --- a/arch/arm/configs/multi_v7_defconfig
>> >> > +++ b/arch/arm/configs/multi_v7_defconfig
>> >> > @@ -365,6 +365,7 @@ CONFIG_REGULATOR_MAX8907=y
>> >> > CONFIG_REGULATOR_MAX8973=y
>> >> > CONFIG_REGULATOR_MAX77686=y
>> >> > CONFIG_REGULATOR_PALMAS=y
>> >> > +CONFIG_REGULATOR_PWM=y
>> >>
>> >> The current policy is to build as much as possible as a module in
>> >> multi_v7_defconfig. Since this is a tristate Kconfig symbol, could you
>> >> please change it to =m ?
>> >
>> > I would prefer that it stays built-in.
>> >
>>
>> Ok, I've no strong opinion on this. I was just mentioning what arm-soc
>> maintainers prefer nowadays.
>>
>> May I ask what's the rationale for leaving this option built-in?
>
> My view is that multi_v7 is used for prototyping, testing and to
> ensure all of the vendors are playing nice together. Hopefully
> vendors aren't actually releasing kernels built with this defconfig!
Agreed and same for the per SoC family defconfigs, vendors should ship
kernels with a customized defconfig.
> During testing/prototyping time; installing and messing around with
> modules is an over-head I can do without.
>
Right but my question wasn't whether multi_v7 should have the options
as built-in or as modules. That has already been decided by the
arm-soc maintainers who want to have as much as possible as modules.
In fact, there have been patches posted recently to change the current
multi_v7 options from built-in to modules.
Instead my question was what makes this driver special to not follow
the current convention.
I agree that there is a trade off between having options as built-in
or modules and I believe that is why most SoC specific defconfigs have
the opposite policy, that is to enable everything as built-in so one
doesn't have to mess with modules as you said.
But again, I don't have a strong opinion on this. What I think though
is that this should be documented somewhere so the options are enabled
following a documented rule instead of just whatever fits in someone
workflow.
Best regards,
Javier
On Thu, 25 Jun 2015, Javier Martinez Canillas wrote:
> On Thu, Jun 25, 2015 at 5:02 PM, Lee Jones <[email protected]> wrote:
> > On Thu, 25 Jun 2015, Javier Martinez Canillas wrote:
> >> On Thu, Jun 25, 2015 at 10:42 AM, Lee Jones <[email protected]> wrote:
> >> > On Wed, 24 Jun 2015, Javier Martinez Canillas wrote:
> >>
> >> [...]
> >>
> >> >> > diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> >> >> > index f632af0..6666973 100644
> >> >> > --- a/arch/arm/configs/multi_v7_defconfig
> >> >> > +++ b/arch/arm/configs/multi_v7_defconfig
> >> >> > @@ -365,6 +365,7 @@ CONFIG_REGULATOR_MAX8907=y
> >> >> > CONFIG_REGULATOR_MAX8973=y
> >> >> > CONFIG_REGULATOR_MAX77686=y
> >> >> > CONFIG_REGULATOR_PALMAS=y
> >> >> > +CONFIG_REGULATOR_PWM=y
> >> >>
> >> >> The current policy is to build as much as possible as a module in
> >> >> multi_v7_defconfig. Since this is a tristate Kconfig symbol, could you
> >> >> please change it to =m ?
> >> >
> >> > I would prefer that it stays built-in.
> >> >
> >>
> >> Ok, I've no strong opinion on this. I was just mentioning what arm-soc
> >> maintainers prefer nowadays.
> >>
> >> May I ask what's the rationale for leaving this option built-in?
> >
> > My view is that multi_v7 is used for prototyping, testing and to
> > ensure all of the vendors are playing nice together. Hopefully
> > vendors aren't actually releasing kernels built with this defconfig!
>
> Agreed and same for the per SoC family defconfigs, vendors should ship
> kernels with a customized defconfig.
Right.
> > During testing/prototyping time; installing and messing around with
> > modules is an over-head I can do without.
>
> Right but my question wasn't whether multi_v7 should have the options
> as built-in or as modules. That has already been decided by the
> arm-soc maintainers who want to have as much as possible as modules.
> In fact, there have been patches posted recently to change the current
> multi_v7 options from built-in to modules.
Then I need to either stop using multi_v7 or write a pre-build script
to turn it into something useful I guess.
Thanks for the heads-up.
> Instead my question was what makes this driver special to not follow
> the current convention.
There is nothing special about this particular driver to warrant that.
> I agree that there is a trade off between having options as built-in
> or modules and I believe that is why most SoC specific defconfigs have
> the opposite policy, that is to enable everything as built-in so one
> doesn't have to mess with modules as you said.
Precisely.
> But again, I don't have a strong opinion on this. What I think though
> is that this should be documented somewhere so the options are enabled
> following a documented rule instead of just whatever fits in someone
> workflow.
News of this new convention is new to me. As I said, this driver
isn't in any way "special". I was merely enabling it to make it
useful to everyone, rather than only people who are currently
supporting module support in their builds. Which as a low-level guy,
I currently have no requirement for -- it just adds time, complexity
and more things to debug.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On 24-06-15, 14:58, Lee Jones wrote:
> This driver reads very platform specific information in from Device Tree
> and translates it into frequency tables. The generic drivers then use the
> tables to conduct frequency and voltage scaling in the normal way.
>
> There are 'ARM' patches in the set which are not necessarily related to CPUFreq,
> but are required to get it to work. Anyone who is not interested in general STi
> DT changes can safely ignore these.
>
> v1 => v2:
> - CPUFreq is no longer it's own device in DT; instead:
> - It is probed from the platform area
> - Key properties have been moved into the CPU's node
> - Driver is less generic [ST => STI]
> - Documentation has been updated
> - Point one (above) has been accounted for
> - Example of bootloader supplied node has been provided
> - GPL licensing has been updated to reflected the header
> - Kconfig disparity has been rectified [bool => tristate]
Sorry for being so late to get back to this.. Was tooo busy :(
--
viresh
On Wed, 08 Jul 2015, Viresh Kumar wrote:
> On 24-06-15, 14:58, Lee Jones wrote:
> > This driver reads very platform specific information in from Device Tree
> > and translates it into frequency tables. The generic drivers then use the
> > tables to conduct frequency and voltage scaling in the normal way.
> >
> > There are 'ARM' patches in the set which are not necessarily related to CPUFreq,
> > but are required to get it to work. Anyone who is not interested in general STi
> > DT changes can safely ignore these.
> >
> > v1 => v2:
> > - CPUFreq is no longer it's own device in DT; instead:
> > - It is probed from the platform area
> > - Key properties have been moved into the CPU's node
> > - Driver is less generic [ST => STI]
> > - Documentation has been updated
> > - Point one (above) has been accounted for
> > - Example of bootloader supplied node has been provided
> > - GPL licensing has been updated to reflected the header
> > - Kconfig disparity has been rectified [bool => tristate]
>
> Sorry for being so late to get back to this.. Was tooo busy :(
No problem. So long as it's still on your radar.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On 08-07-15, 11:59, Lee Jones wrote:
> No problem. So long as it's still on your radar.
So, for the first 7 patches:
Reviewed-by: Viresh Kumar <[email protected]>
but for the last two:
- I thought we agreed that you will have a look at opp-v2 bindings and
create your new bindings as an extension of those ? As we support
extending opp-v2 bindings per vendor basis.
- And I don't really think you need to create a device for your STM
driver, why not move your stm-cpufreq file to arch/arm/- and call it
from .init_late, from where you call init_cpufreq() today. Your
driver doesn't have anything related to cpufreq-core really and
isn't required to stay in drivers/cpufreq, unless you want it that
way.
I haven't reviewed the driver yet and waiting for an answer to opp-v2
question I asked above. opp-v2 is created because we didn't wanted
platforms to create new separate bindings for OPPs :)
--
viresh