* [PATCH 1/5] cpufreq: enable the DT cpufreq driver on the Integrators
2016-10-19 9:59 [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator Linus Walleij
@ 2016-10-19 9:59 ` Linus Walleij
2016-10-19 9:59 ` [PATCH 2/5] ARM: dts: Add Integrator/AP cpus node and operating points Linus Walleij
` (6 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2016-10-19 9:59 UTC (permalink / raw)
To: Rafael J . Wysocki, Viresh Kumar
Cc: Arnd Bergmann, linux-pm, Linus Walleij, Rafael J . Wysocki,
Russell King, linux-arm-kernel
This enables the generic DT and OPP-based cpufreq driver on the
ARM Integrator/AP and Integrator/CP.
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 71267626456b..142a6f615e52 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -26,6 +26,9 @@ static const struct of_device_id machines[] __initconst = {
{ .compatible = "allwinner,sun8i-a83t", },
{ .compatible = "allwinner,sun8i-h3", },
+ { .compatible = "arm,integrator-ap", },
+ { .compatible = "arm,integrator-cp", },
+
{ .compatible = "hisilicon,hi6220", },
{ .compatible = "fsl,imx27", },
--
2.7.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 2/5] ARM: dts: Add Integrator/AP cpus node and operating points
2016-10-19 9:59 [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator Linus Walleij
2016-10-19 9:59 ` [PATCH 1/5] cpufreq: enable the DT cpufreq driver on the Integrators Linus Walleij
@ 2016-10-19 9:59 ` Linus Walleij
2016-10-19 9:59 ` [PATCH 3/5] ARM: dts: Add Integrator/CP " Linus Walleij
` (5 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2016-10-19 9:59 UTC (permalink / raw)
To: Rafael J . Wysocki, Viresh Kumar
Cc: Arnd Bergmann, linux-pm, Linus Walleij, Rafael J . Wysocki,
Russell King, linux-arm-kernel
This adds the cpus node to the Integrator/AP device tree so
that we have a proper placeholder to put in the DT-defined
operating points for the generic DT/OPP cpufreq driver,
along with the proper operating points.
The old Integrator cpufreq driver would resolve the max
frequency to 71MHz, and the min frequency to 12 MHz, but
the clock driver can actually handle any frequency inbetween
so I picked a few select frequencies as OPPs. The cpufreq
framework doesn't seem to deal with sliding frequency scales,
only fixed points so 7 OPPs is better than 2 atleast.
We define a CPU node since this is required for cpufreq-dt,
however we do not define any compatible string for the CPU
since this architecture has pluggable CPU modules and we
do not know which one will be used. If necessary, the CPU
compatible can be filled in by the boot loader, but for
just cpufreq-dt it is not required.
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/integratorap.dts | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/integratorap.dts b/arch/arm/boot/dts/integratorap.dts
index 6f16d09dc5a4..e8b249f92fb3 100644
--- a/arch/arm/boot/dts/integratorap.dts
+++ b/arch/arm/boot/dts/integratorap.dts
@@ -10,6 +10,41 @@
compatible = "arm,integrator-ap";
dma-ranges = <0x80000000 0x0 0x80000000>;
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ /*
+ * Since the board has pluggable CPU modules, we
+ * cannot define a proper compatible here. Let the
+ * boot loader fill in the apropriate compatible
+ * string if necessary.
+ */
+ /* compatible = "arm,arm926ej-s"; */
+ reg = <0>;
+ /*
+ * The documentation in ARM DUI 0138E page 3-12 states
+ * that the maximum frequency for this clock is 200 MHz
+ * but painful trial-and-error has proved to me that it
+ * is actually just hanging the system above 71 MHz.
+ * Sad but true.
+ */
+ /* kHz uV */
+ operating-points = <71000 0
+ 66000 0
+ 60000 0
+ 48000 0
+ 36000 0
+ 24000 0
+ 12000 0>;
+ clocks = <&cmosc>;
+ clock-names = "cpu";
+ clock-latency = <1000000>; /* 1 ms */
+ };
+ };
+
aliases {
arm,timer-primary = &timer2;
arm,timer-secondary = &timer1;
--
2.7.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 3/5] ARM: dts: Add Integrator/CP cpus node and operating points
2016-10-19 9:59 [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator Linus Walleij
2016-10-19 9:59 ` [PATCH 1/5] cpufreq: enable the DT cpufreq driver on the Integrators Linus Walleij
2016-10-19 9:59 ` [PATCH 2/5] ARM: dts: Add Integrator/AP cpus node and operating points Linus Walleij
@ 2016-10-19 9:59 ` Linus Walleij
2016-10-19 9:59 ` [PATCH 4/5] ARM: defconfig: turn on the DT cpufreq for Integrator Linus Walleij
` (4 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2016-10-19 9:59 UTC (permalink / raw)
To: Rafael J . Wysocki, Viresh Kumar
Cc: Arnd Bergmann, linux-pm, Linus Walleij, Rafael J . Wysocki,
Russell King, linux-arm-kernel
This adds the cpus node to the Integrator/CP device tree so
that we have a proper placeholder to put in the DT-defined
operating points for the generic DT/OPP cpufreq driver,
along with two working operating points.
I have only put in 48 and 50 MHz because going to e.g. 36
MHz hangs the system when CLCD graphics are active.
Presumably the memory bus gets to slow to feed the display
and the systems hangs for this reason. The ideal solution
would be for the display controller to put constraints on
the memory bus frequency, but that need to be a separate
longer-term project.
We define a CPU node since this is required for cpufreq-dt,
however we do not define any compatible string for the CPU
since this architecture has pluggable CPU modules and we
do not know which one will be used. If necessary, the CPU
compatible can be filled in by the boot loader, but for
just cpufreq-dt it is not required.
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/integratorcp.dts | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/integratorcp.dts b/arch/arm/boot/dts/integratorcp.dts
index 1b5e4b006b72..97f38b57a702 100644
--- a/arch/arm/boot/dts/integratorcp.dts
+++ b/arch/arm/boot/dts/integratorcp.dts
@@ -13,6 +13,32 @@
bootargs = "root=/dev/ram0 console=ttyAMA0,38400n8 earlyprintk";
};
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ /*
+ * Since the board has pluggable CPU modules, we
+ * cannot define a proper compatible here. Let the
+ * boot loader fill in the apropriate compatible
+ * string if necessary.
+ */
+ /* compatible = "arm,arm920t"; */
+ reg = <0>;
+ /*
+ * TBD comment.
+ */
+ /* kHz uV */
+ operating-points = <50000 0
+ 48000 0>;
+ clocks = <&cmcore>;
+ clock-names = "cpu";
+ clock-latency = <1000000>; /* 1 ms */
+ };
+ };
+
/*
* The Integrator/CP overall clocking architecture can be found in
* ARM DUI 0184B page 7-28 "Integrator/CP922T system clocks" which
--
2.7.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 4/5] ARM: defconfig: turn on the DT cpufreq for Integrator
2016-10-19 9:59 [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator Linus Walleij
` (2 preceding siblings ...)
2016-10-19 9:59 ` [PATCH 3/5] ARM: dts: Add Integrator/CP " Linus Walleij
@ 2016-10-19 9:59 ` Linus Walleij
2016-10-19 9:59 ` [PATCH 5/5] cpufreq: retire the Integrator cpufreq driver Linus Walleij
` (3 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2016-10-19 9:59 UTC (permalink / raw)
To: Rafael J . Wysocki, Viresh Kumar
Cc: Arnd Bergmann, linux-pm, Linus Walleij, Rafael J . Wysocki,
Russell King, linux-arm-kernel
The Integrators are now migrated to handle the CPUfreq
scaling using the generic devicetree CPUfreq driver using the
common clock framework and have the required device tree
modifications, so turn off the old driver and turn on the new
generic driver.
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/configs/integrator_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/integrator_defconfig b/arch/arm/configs/integrator_defconfig
index 869faae67201..69cb8f1efcea 100644
--- a/arch/arm/configs/integrator_defconfig
+++ b/arch/arm/configs/integrator_defconfig
@@ -26,6 +26,7 @@ CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
+CONFIG_CPUFREQ_DT=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
--
2.7.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 5/5] cpufreq: retire the Integrator cpufreq driver
2016-10-19 9:59 [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator Linus Walleij
` (3 preceding siblings ...)
2016-10-19 9:59 ` [PATCH 4/5] ARM: defconfig: turn on the DT cpufreq for Integrator Linus Walleij
@ 2016-10-19 9:59 ` Linus Walleij
2016-10-19 10:14 ` [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator Arnd Bergmann
` (2 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2016-10-19 9:59 UTC (permalink / raw)
To: Rafael J . Wysocki, Viresh Kumar
Cc: Arnd Bergmann, linux-pm, Linus Walleij, Rafael J . Wysocki,
Russell King, linux-arm-kernel
After switching the core module clocks controlling the Integrator
clock frequencies to the common clock framework, defining the
operating points in the device tree, and activating the generic
DT-based CPUfreq driver, we can retire the old Integrator
cpufreq driver.
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/cpufreq/Kconfig.arm | 8 --
drivers/cpufreq/Makefile | 1 -
drivers/cpufreq/integrator-cpufreq.c | 239 -----------------------------------
3 files changed, 248 deletions(-)
delete mode 100644 drivers/cpufreq/integrator-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index d89b8afe23b6..fdbc630272b3 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -60,14 +60,6 @@ config ARM_IMX6Q_CPUFREQ
If in doubt, say N.
-config ARM_INTEGRATOR
- tristate "CPUfreq driver for ARM Integrator CPUs"
- depends on ARCH_INTEGRATOR
- default y
- help
- This enables the CPUfreq driver for ARM Integrator CPUs.
- If in doubt, say Y.
-
config ARM_KIRKWOOD_CPUFREQ
def_bool MACH_KIRKWOOD
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 0a9b6a093646..7dde82179d62 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -56,7 +56,6 @@ obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ) += imx6q-cpufreq.o
-obj-$(CONFIG_ARM_INTEGRATOR) += integrator-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_MT8173_CPUFREQ) += mt8173-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
diff --git a/drivers/cpufreq/integrator-cpufreq.c b/drivers/cpufreq/integrator-cpufreq.c
deleted file mode 100644
index 79e3ff2771a6..000000000000
--- a/drivers/cpufreq/integrator-cpufreq.c
+++ /dev/null
@@ -1,239 +0,0 @@
-/*
- * Copyright (C) 2001-2002 Deep Blue Solutions Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * CPU support functions
- */
-#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <linux/cpufreq.h>
-#include <linux/sched.h>
-#include <linux/smp.h>
-#include <linux/init.h>
-#include <linux/io.h>
-#include <linux/platform_device.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-
-#include <asm/mach-types.h>
-#include <asm/hardware/icst.h>
-
-static void __iomem *cm_base;
-/* The cpufreq driver only use the OSC register */
-#define INTEGRATOR_HDR_OSC_OFFSET 0x08
-#define INTEGRATOR_HDR_LOCK_OFFSET 0x14
-
-static struct cpufreq_driver integrator_driver;
-
-static const struct icst_params lclk_params = {
- .ref = 24000000,
- .vco_max = ICST525_VCO_MAX_5V,
- .vco_min = ICST525_VCO_MIN,
- .vd_min = 8,
- .vd_max = 132,
- .rd_min = 24,
- .rd_max = 24,
- .s2div = icst525_s2div,
- .idx2s = icst525_idx2s,
-};
-
-static const struct icst_params cclk_params = {
- .ref = 24000000,
- .vco_max = ICST525_VCO_MAX_5V,
- .vco_min = ICST525_VCO_MIN,
- .vd_min = 12,
- .vd_max = 160,
- .rd_min = 24,
- .rd_max = 24,
- .s2div = icst525_s2div,
- .idx2s = icst525_idx2s,
-};
-
-/*
- * Validate the speed policy.
- */
-static int integrator_verify_policy(struct cpufreq_policy *policy)
-{
- struct icst_vco vco;
-
- cpufreq_verify_within_cpu_limits(policy);
-
- vco = icst_hz_to_vco(&cclk_params, policy->max * 1000);
- policy->max = icst_hz(&cclk_params, vco) / 1000;
-
- vco = icst_hz_to_vco(&cclk_params, policy->min * 1000);
- policy->min = icst_hz(&cclk_params, vco) / 1000;
-
- cpufreq_verify_within_cpu_limits(policy);
- return 0;
-}
-
-
-static int integrator_set_target(struct cpufreq_policy *policy,
- unsigned int target_freq,
- unsigned int relation)
-{
- cpumask_t cpus_allowed;
- int cpu = policy->cpu;
- struct icst_vco vco;
- struct cpufreq_freqs freqs;
- u_int cm_osc;
-
- /*
- * Save this threads cpus_allowed mask.
- */
- cpus_allowed = current->cpus_allowed;
-
- /*
- * Bind to the specified CPU. When this call returns,
- * we should be running on the right CPU.
- */
- set_cpus_allowed_ptr(current, cpumask_of(cpu));
- BUG_ON(cpu != smp_processor_id());
-
- /* get current setting */
- cm_osc = __raw_readl(cm_base + INTEGRATOR_HDR_OSC_OFFSET);
-
- if (machine_is_integrator())
- vco.s = (cm_osc >> 8) & 7;
- else if (machine_is_cintegrator())
- vco.s = 1;
- vco.v = cm_osc & 255;
- vco.r = 22;
- freqs.old = icst_hz(&cclk_params, vco) / 1000;
-
- /* icst_hz_to_vco rounds down -- so we need the next
- * larger freq in case of CPUFREQ_RELATION_L.
- */
- if (relation == CPUFREQ_RELATION_L)
- target_freq += 999;
- if (target_freq > policy->max)
- target_freq = policy->max;
- vco = icst_hz_to_vco(&cclk_params, target_freq * 1000);
- freqs.new = icst_hz(&cclk_params, vco) / 1000;
-
- if (freqs.old == freqs.new) {
- set_cpus_allowed_ptr(current, &cpus_allowed);
- return 0;
- }
-
- cpufreq_freq_transition_begin(policy, &freqs);
-
- cm_osc = __raw_readl(cm_base + INTEGRATOR_HDR_OSC_OFFSET);
-
- if (machine_is_integrator()) {
- cm_osc &= 0xfffff800;
- cm_osc |= vco.s << 8;
- } else if (machine_is_cintegrator()) {
- cm_osc &= 0xffffff00;
- }
- cm_osc |= vco.v;
-
- __raw_writel(0xa05f, cm_base + INTEGRATOR_HDR_LOCK_OFFSET);
- __raw_writel(cm_osc, cm_base + INTEGRATOR_HDR_OSC_OFFSET);
- __raw_writel(0, cm_base + INTEGRATOR_HDR_LOCK_OFFSET);
-
- /*
- * Restore the CPUs allowed mask.
- */
- set_cpus_allowed_ptr(current, &cpus_allowed);
-
- cpufreq_freq_transition_end(policy, &freqs, 0);
-
- return 0;
-}
-
-static unsigned int integrator_get(unsigned int cpu)
-{
- cpumask_t cpus_allowed;
- unsigned int current_freq;
- u_int cm_osc;
- struct icst_vco vco;
-
- cpus_allowed = current->cpus_allowed;
-
- set_cpus_allowed_ptr(current, cpumask_of(cpu));
- BUG_ON(cpu != smp_processor_id());
-
- /* detect memory etc. */
- cm_osc = __raw_readl(cm_base + INTEGRATOR_HDR_OSC_OFFSET);
-
- if (machine_is_integrator())
- vco.s = (cm_osc >> 8) & 7;
- else
- vco.s = 1;
- vco.v = cm_osc & 255;
- vco.r = 22;
-
- current_freq = icst_hz(&cclk_params, vco) / 1000; /* current freq */
-
- set_cpus_allowed_ptr(current, &cpus_allowed);
-
- return current_freq;
-}
-
-static int integrator_cpufreq_init(struct cpufreq_policy *policy)
-{
-
- /* set default policy and cpuinfo */
- policy->max = policy->cpuinfo.max_freq = 160000;
- policy->min = policy->cpuinfo.min_freq = 12000;
- policy->cpuinfo.transition_latency = 1000000; /* 1 ms, assumed */
-
- return 0;
-}
-
-static struct cpufreq_driver integrator_driver = {
- .flags = CPUFREQ_NEED_INITIAL_FREQ_CHECK,
- .verify = integrator_verify_policy,
- .target = integrator_set_target,
- .get = integrator_get,
- .init = integrator_cpufreq_init,
- .name = "integrator",
-};
-
-static int __init integrator_cpufreq_probe(struct platform_device *pdev)
-{
- struct resource *res;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENODEV;
-
- cm_base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
- if (!cm_base)
- return -ENODEV;
-
- return cpufreq_register_driver(&integrator_driver);
-}
-
-static int __exit integrator_cpufreq_remove(struct platform_device *pdev)
-{
- return cpufreq_unregister_driver(&integrator_driver);
-}
-
-static const struct of_device_id integrator_cpufreq_match[] = {
- { .compatible = "arm,core-module-integrator"},
- { },
-};
-
-MODULE_DEVICE_TABLE(of, integrator_cpufreq_match);
-
-static struct platform_driver integrator_cpufreq_driver = {
- .driver = {
- .name = "integrator-cpufreq",
- .of_match_table = integrator_cpufreq_match,
- },
- .remove = __exit_p(integrator_cpufreq_remove),
-};
-
-module_platform_driver_probe(integrator_cpufreq_driver,
- integrator_cpufreq_probe);
-
-MODULE_AUTHOR("Russell M. King");
-MODULE_DESCRIPTION("cpufreq driver for ARM Integrator CPUs");
-MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator
2016-10-19 9:59 [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator Linus Walleij
` (4 preceding siblings ...)
2016-10-19 9:59 ` [PATCH 5/5] cpufreq: retire the Integrator cpufreq driver Linus Walleij
@ 2016-10-19 10:14 ` Arnd Bergmann
2016-10-24 19:28 ` Linus Walleij
2016-10-19 21:24 ` Rafael J. Wysocki
2016-10-20 4:20 ` Viresh Kumar
7 siblings, 1 reply; 13+ messages in thread
From: Arnd Bergmann @ 2016-10-19 10:14 UTC (permalink / raw)
To: Linus Walleij
Cc: Rafael J . Wysocki, Viresh Kumar, Russell King, linux-arm-kernel,
linux-pm
On Wednesday, October 19, 2016 11:59:09 AM CEST Linus Walleij wrote:
>
> If people are happy with this approach and approve of the patches
> I'd like an ACK from the cpufreq people and then merge the whole set
> through ARM SoC.
>
I don't see any hard dependency here, so I'd suggest to merge the
two cpufreq patches through the subsystem tree, and the ARM patches
through arm-soc.
The patches look fine.
Removing the custom driver of course means that we break machines
with old .dtb files, so we could consider leaving the driver in
place, but probably there is no need for integrator.
Arnd
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator
2016-10-19 10:14 ` [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator Arnd Bergmann
@ 2016-10-24 19:28 ` Linus Walleij
2016-10-24 20:15 ` Rafael J. Wysocki
0 siblings, 1 reply; 13+ messages in thread
From: Linus Walleij @ 2016-10-24 19:28 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J . Wysocki, linux-pm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Russell King, Arnd Bergmann
On Wed, Oct 19, 2016 at 12:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> I don't see any hard dependency here, so I'd suggest to merge the
> two cpufreq patches through the subsystem tree, and the ARM patches
> through arm-soc.
That's right, Viresh can you merge patches 1 and 5 to the
cpufreq tree please?
I will funnel patches 2, 3 and 4 to ARM SoC.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator
2016-10-24 19:28 ` Linus Walleij
@ 2016-10-24 20:15 ` Rafael J. Wysocki
2016-10-25 7:16 ` Linus Walleij
0 siblings, 1 reply; 13+ messages in thread
From: Rafael J. Wysocki @ 2016-10-24 20:15 UTC (permalink / raw)
To: Linus Walleij
Cc: Viresh Kumar, Rafael J . Wysocki, linux-pm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Russell King, Arnd Bergmann
On Mon, Oct 24, 2016 at 9:28 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Oct 19, 2016 at 12:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> I don't see any hard dependency here, so I'd suggest to merge the
>> two cpufreq patches through the subsystem tree, and the ARM patches
>> through arm-soc.
>
> That's right, Viresh can you merge patches 1 and 5 to the
> cpufreq tree please?
Well, that would be me.
Can you please resend the two as a separate series, with all tags
collected so far if any?
Thanks,
Rafael
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator
2016-10-24 20:15 ` Rafael J. Wysocki
@ 2016-10-25 7:16 ` Linus Walleij
0 siblings, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2016-10-25 7:16 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Viresh Kumar, Rafael J . Wysocki, linux-pm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Russell King, Arnd Bergmann
On Mon, Oct 24, 2016 at 10:15 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Mon, Oct 24, 2016 at 9:28 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Wed, Oct 19, 2016 at 12:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>>> I don't see any hard dependency here, so I'd suggest to merge the
>>> two cpufreq patches through the subsystem tree, and the ARM patches
>>> through arm-soc.
>>
>> That's right, Viresh can you merge patches 1 and 5 to the
>> cpufreq tree please?
>
> Well, that would be me.
>
> Can you please resend the two as a separate series, with all tags
> collected so far if any?
Sure no problem.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator
2016-10-19 9:59 [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator Linus Walleij
` (5 preceding siblings ...)
2016-10-19 10:14 ` [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator Arnd Bergmann
@ 2016-10-19 21:24 ` Rafael J. Wysocki
2016-10-20 4:20 ` Viresh Kumar
7 siblings, 0 replies; 13+ messages in thread
From: Rafael J. Wysocki @ 2016-10-19 21:24 UTC (permalink / raw)
To: Linus Walleij
Cc: Rafael J . Wysocki, Viresh Kumar, linux-pm, linux-arm-kernel,
Arnd Bergmann, Russell King
On Wednesday, October 19, 2016 11:59:09 AM Linus Walleij wrote:
> This switches the ARM Integrator/AP and Integrator/CP to use the
> Device Tree cpufreq policy with its definition of operating points
> using the generic OPP library.
>
> The Integrators does not need to control a regulator to switch
> frequency, only a clock. This clock and its device tree bindings
> have been defined in the device tree and merged upstream for v4.9.
>
> This approach provides a little better granularity on the
> Integrator/AP where I defined a few operating points: before
> this change the Integrator would just switch between min speed
> (12 MHz) and max speed (71 MHz). Now it can switch between a
> few arbitrarily chosen OPPs as in the examples below:
>
> The following tests were made on the Integrator/AP:
>
> /sys/devices/system/cpu/cpufreq/policy0 echo ondemand > scaling_governor
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 24000000 Hz
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 24000000 Hz --> 12000000 Hz
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 24000000 Hz
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 24000000 Hz --> 12000000 Hz
>
> The switch from 12 to 24 MHz is triggered by as little as using the
> command line with the ondemand governor. If we do this:
>
> yes > /dev/null &
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 36000000 Hz
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 36000000 Hz --> 71000000 Hz
> pkill yes
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 12000000 Hz
>
> So the algorithm is indeed using all the OPPs.
>
> Also as a confirmation test to make sure performance is affected by the
> speed changes, we set the performance governor and:
>
> echo 12000 > scaling_max_freq
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 12000000 Hz
> time find /sys|sort|uniq > /dev/null
> real 0m 45.51s
> user 0m 11.15s
> sys 0m 26.74s
>
> echo 71000 > scaling_max_freq
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 71000000 Hz
> time find /sys|sort|uniq
> > /dev/null
> real 0m 9.13s
> user 0m 2.35s
> sys 0m 5.50s
>
> So it is working.
>
> If people are happy with this approach and approve of the patches
> I'd like an ACK from the cpufreq people and then merge the whole set
> through ARM SoC.
>
> Linus Walleij (5):
> cpufreq: enable the DT cpufreq driver on the Integrators
> ARM: dts: Add Integrator/AP cpus node and operating points
> ARM: dts: Add Integrator/CP cpus node and operating points
> ARM: defconfig: turn on the DT cpufreq for Integrator
> cpufreq: retire the Integrator cpufreq driver
The cpufreq changes look good to me, but Viresh is the expert for the DT stuff.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator
2016-10-19 9:59 [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator Linus Walleij
` (6 preceding siblings ...)
2016-10-19 21:24 ` Rafael J. Wysocki
@ 2016-10-20 4:20 ` Viresh Kumar
2016-10-20 4:47 ` Viresh Kumar
7 siblings, 1 reply; 13+ messages in thread
From: Viresh Kumar @ 2016-10-20 4:20 UTC (permalink / raw)
To: Linus Walleij
Cc: Rafael J . Wysocki, linux-pm, linux-arm-kernel, Arnd Bergmann,
Russell King
On 19-10-16, 11:59, Linus Walleij wrote:
> This switches the ARM Integrator/AP and Integrator/CP to use the
> Device Tree cpufreq policy with its definition of operating points
> using the generic OPP library.
>
> The Integrators does not need to control a regulator to switch
> frequency, only a clock. This clock and its device tree bindings
> have been defined in the device tree and merged upstream for v4.9.
>
> This approach provides a little better granularity on the
> Integrator/AP where I defined a few operating points: before
> this change the Integrator would just switch between min speed
> (12 MHz) and max speed (71 MHz). Now it can switch between a
> few arbitrarily chosen OPPs as in the examples below:
>
> The following tests were made on the Integrator/AP:
>
> /sys/devices/system/cpu/cpufreq/policy0 echo ondemand > scaling_governor
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 24000000 Hz
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 24000000 Hz --> 12000000 Hz
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 24000000 Hz
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 24000000 Hz --> 12000000 Hz
>
> The switch from 12 to 24 MHz is triggered by as little as using the
> command line with the ondemand governor. If we do this:
>
> yes > /dev/null &
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 36000000 Hz
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 36000000 Hz --> 71000000 Hz
> pkill yes
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 12000000 Hz
>
> So the algorithm is indeed using all the OPPs.
>
> Also as a confirmation test to make sure performance is affected by the
> speed changes, we set the performance governor and:
>
> echo 12000 > scaling_max_freq
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 12000000 Hz
> time find /sys|sort|uniq > /dev/null
> real 0m 45.51s
> user 0m 11.15s
> sys 0m 26.74s
>
> echo 71000 > scaling_max_freq
> cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 71000000 Hz
> time find /sys|sort|uniq
> > /dev/null
> real 0m 9.13s
> user 0m 2.35s
> sys 0m 5.50s
>
> So it is working.
>
> If people are happy with this approach and approve of the patches
> I'd like an ACK from the cpufreq people and then merge the whole set
> through ARM SoC.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator
2016-10-20 4:20 ` Viresh Kumar
@ 2016-10-20 4:47 ` Viresh Kumar
0 siblings, 0 replies; 13+ messages in thread
From: Viresh Kumar @ 2016-10-20 4:47 UTC (permalink / raw)
To: Linus Walleij
Cc: Rafael J . Wysocki, linux-pm, linux-arm-kernel, Arnd Bergmann,
Russell King
On 20-10-16, 09:50, Viresh Kumar wrote:
> On 19-10-16, 11:59, Linus Walleij wrote:
> > This switches the ARM Integrator/AP and Integrator/CP to use the
> > Device Tree cpufreq policy with its definition of operating points
> > using the generic OPP library.
> >
> > The Integrators does not need to control a regulator to switch
> > frequency, only a clock. This clock and its device tree bindings
> > have been defined in the device tree and merged upstream for v4.9.
> >
> > This approach provides a little better granularity on the
> > Integrator/AP where I defined a few operating points: before
> > this change the Integrator would just switch between min speed
> > (12 MHz) and max speed (71 MHz). Now it can switch between a
> > few arbitrarily chosen OPPs as in the examples below:
> >
> > The following tests were made on the Integrator/AP:
> >
> > /sys/devices/system/cpu/cpufreq/policy0 echo ondemand > scaling_governor
> > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 24000000 Hz
> > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 24000000 Hz --> 12000000 Hz
> > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 24000000 Hz
> > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 24000000 Hz --> 12000000 Hz
> >
> > The switch from 12 to 24 MHz is triggered by as little as using the
> > command line with the ondemand governor. If we do this:
> >
> > yes > /dev/null &
> > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 36000000 Hz
> > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 36000000 Hz --> 71000000 Hz
> > pkill yes
> > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 12000000 Hz
> >
> > So the algorithm is indeed using all the OPPs.
> >
> > Also as a confirmation test to make sure performance is affected by the
> > speed changes, we set the performance governor and:
> >
> > echo 12000 > scaling_max_freq
> > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 12000000 Hz
> > time find /sys|sort|uniq > /dev/null
> > real 0m 45.51s
> > user 0m 11.15s
> > sys 0m 26.74s
> >
> > echo 71000 > scaling_max_freq
> > cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 71000000 Hz
> > time find /sys|sort|uniq
> > > /dev/null
> > real 0m 9.13s
> > user 0m 2.35s
> > sys 0m 5.50s
> >
> > So it is working.
> >
> > If people are happy with this approach and approve of the patches
> > I'd like an ACK from the cpufreq people and then merge the whole set
> > through ARM SoC.
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Integrator is an UP, right? Otherwise you may want to use operating-points-v2
bindings instead.
--
viresh
^ permalink raw reply [flat|nested] 13+ messages in thread