[PATCH 0/8] cpufreq support for Marvell Armada XP

[PATCH 0/8] cpufreq support for Marvell Armada XP

[Thomas Petazzoni]

Mike, Viresh, Rafael, Jason, Gregory, Andrew, Sebastian,

This series of commits adds cpufreq support for the Marvell Armada XP
processor. Adding this support involves touching several different
areas:

 - The core clock framework, to add a new clk_set_rate() notifier. See
   below for the explanation. This should go through Mike Turquette's
   tree. This is PATCH 01/08.

 - Addition of an Armada XP cpufreq driver. This should go through the
   cpufreq maintainers, Viresh Kumar and Rafael J. Wysocki. This is
   PATCH 02/08.

 - Improvements to the existing Armada XP cpu-clock driver. This
   should also go through Mike Turquette's tree, probably thanks to a
   pull request to be sent by the mvebu platform maintainers. This is
   PATCH 03/08.

 - Extension of the Marvell EBU PMSU code in arch/arm/mach-mvebu/ to
   implement a clock notifier needed for the dynamic frequency change
   procedure. This patch should go through the mvebu maintainers
   tree. This is PATCH 05/08. Note that this patch has a build
   dependency on PATCH 01/08, while all other patches don't have any
   other build dependency.

 - Misc other small changes (defconfigs, Device Tree, SMP
   initialization code) that are specific to the mvebu platform, also
   to be handled by the mvebu maintainers. Those are patches 4, 6, 7
   and 8.

The only tricky part in this series is the addition of the
APPLY_RATE_CHANGE clock notifier. All the details about why a new
clock notifier is needed are exposed in the commit log of the first
patch, "clk: add an APPLY_RATE_CHANGE notifier event during
clk_set_rate()". Please read carefully this commit log to understand
the reasons for this proposed clock notifier.

Basically, the issue is that the procedure to change the CPU clock
frequency involves touching registers managed by the CPU clock driver,
but also registers from the PMSU which is used for a wide range of
power management activities, and is therefore handled by platform
specific code in mach-mvebu.

Jason, this patch series is based on 3.16-rc3, but it applies fine
even with mvebu/fixes and mvebu/soc merged (which contain some PMSU
changes), so I haven't based the patch series on those branches.

Thanks,

Thomas

Thomas Petazzoni (8):
  clk: add an APPLY_RATE_CHANGE notifier event during clk_set_rate()
  cpufreq: add driver for Armada XP
  clk: mvebu: extend clk-cpu for dynamic frequency scaling
  ARM: mvebu: ensure CPU clocks are enabled
  ARM: mvebu: extend PMSU code to support dynamic frequency scaling
  ARM: mvebu: update Armada XP DT for dynamic frequency scaling
  ARM: mvebu: allow enabling of cpufreq on Armada XP
  ARM: mvebu: update mvebu_v7_defconfig with cpufreq support

 .../devicetree/bindings/clock/mvebu-cpu-clock.txt  |   5 +-
 arch/arm/boot/dts/armada-xp.dtsi                   |   2 +-
 arch/arm/configs/mvebu_v7_defconfig                |   1 +
 arch/arm/mach-mvebu/Kconfig                        |   1 +
 arch/arm/mach-mvebu/platsmp.c                      |   1 +
 arch/arm/mach-mvebu/pmsu.c                         | 168 +++++++++++++++++++++
 drivers/clk/clk.c                                  |   3 +
 drivers/clk/mvebu/clk-cpu.c                        |  79 +++++++++-
 drivers/cpufreq/Kconfig.arm                        |   6 +
 drivers/cpufreq/Makefile                           |   1 +
 drivers/cpufreq/armadaxp-cpufreq.c                 | 112 ++++++++++++++
 include/linux/clk.h                                |   4 +
 12 files changed, 375 insertions(+), 8 deletions(-)
 create mode 100644 drivers/cpufreq/armadaxp-cpufreq.c

-- 
2.0.0

[PATCH 0/8] cpufreq support for Marvell Armada XP

[Thomas Petazzoni]

Mike, Viresh, Rafael, Jason, Gregory, Andrew, Sebastian,

This series of commits adds cpufreq support for the Marvell Armada XP
processor. Adding this support involves touching several different
areas:

 - The core clock framework, to add a new clk_set_rate() notifier. See
   below for the explanation. This should go through Mike Turquette's
   tree. This is PATCH 01/08.

 - Addition of an Armada XP cpufreq driver. This should go through the
   cpufreq maintainers, Viresh Kumar and Rafael J. Wysocki. This is
   PATCH 02/08.

 - Improvements to the existing Armada XP cpu-clock driver. This
   should also go through Mike Turquette's tree, probably thanks to a
   pull request to be sent by the mvebu platform maintainers. This is
   PATCH 03/08.

 - Extension of the Marvell EBU PMSU code in arch/arm/mach-mvebu/ to
   implement a clock notifier needed for the dynamic frequency change
   procedure. This patch should go through the mvebu maintainers
   tree. This is PATCH 05/08. Note that this patch has a build
   dependency on PATCH 01/08, while all other patches don't have any
   other build dependency.

 - Misc other small changes (defconfigs, Device Tree, SMP
   initialization code) that are specific to the mvebu platform, also
   to be handled by the mvebu maintainers. Those are patches 4, 6, 7
   and 8.

The only tricky part in this series is the addition of the
APPLY_RATE_CHANGE clock notifier. All the details about why a new
clock notifier is needed are exposed in the commit log of the first
patch, "clk: add an APPLY_RATE_CHANGE notifier event during
clk_set_rate()". Please read carefully this commit log to understand
the reasons for this proposed clock notifier.

Basically, the issue is that the procedure to change the CPU clock
frequency involves touching registers managed by the CPU clock driver,
but also registers from the PMSU which is used for a wide range of
power management activities, and is therefore handled by platform
specific code in mach-mvebu.

Jason, this patch series is based on 3.16-rc3, but it applies fine
even with mvebu/fixes and mvebu/soc merged (which contain some PMSU
changes), so I haven't based the patch series on those branches.

Thanks,

Thomas

Thomas Petazzoni (8):
  clk: add an APPLY_RATE_CHANGE notifier event during clk_set_rate()
  cpufreq: add driver for Armada XP
  clk: mvebu: extend clk-cpu for dynamic frequency scaling
  ARM: mvebu: ensure CPU clocks are enabled
  ARM: mvebu: extend PMSU code to support dynamic frequency scaling
  ARM: mvebu: update Armada XP DT for dynamic frequency scaling
  ARM: mvebu: allow enabling of cpufreq on Armada XP
  ARM: mvebu: update mvebu_v7_defconfig with cpufreq support

 .../devicetree/bindings/clock/mvebu-cpu-clock.txt  |   5 +-
 arch/arm/boot/dts/armada-xp.dtsi                   |   2 +-
 arch/arm/configs/mvebu_v7_defconfig                |   1 +
 arch/arm/mach-mvebu/Kconfig                        |   1 +
 arch/arm/mach-mvebu/platsmp.c                      |   1 +
 arch/arm/mach-mvebu/pmsu.c                         | 168 +++++++++++++++++++++
 drivers/clk/clk.c                                  |   3 +
 drivers/clk/mvebu/clk-cpu.c                        |  79 +++++++++-
 drivers/cpufreq/Kconfig.arm                        |   6 +
 drivers/cpufreq/Makefile                           |   1 +
 drivers/cpufreq/armadaxp-cpufreq.c                 | 112 ++++++++++++++
 include/linux/clk.h                                |   4 +
 12 files changed, 375 insertions(+), 8 deletions(-)
 create mode 100644 drivers/cpufreq/armadaxp-cpufreq.c

-- 
2.0.0

[PATCH 1/8] clk: add an APPLY_RATE_CHANGE notifier event during clk_set_rate()

[Thomas Petazzoni]

The current clk_set_rate() logic allows notifiers to be notified of
three different events:

 * PRE_RATE_CHANGE: before the clock driver ->set_rate() function is
   called.
 * ABORT_RATE_CHANGE: called if the rate change failed
 * POST_RATE_CHANGE: called after the rate change has been
   successfully done, but after ->recalc_rate() has been called, and
   only if the rate of the clock has actually changed.

This commit adds an additional APPLY_RATE_CHANGE, which we require on
Armada XP to implement dynamic frequency scaling of the CPU
clocks. The problem is as follows.

On Armada XP, there are three hardware blocks involved in the dynamic
frequency scaling of the CPU clocks:

 - The CPU clocks hardware block itself, whose registers are already
   "managed" by drivers/clk/mvebu/clk-cpu.c (compatible string:
   marvell,armada-xp-cpu-clock). The driver currently only supports
   changing the rate of the CPU clock when the clock is off (i.e
   before we boot the secondary CPUs).

 - The PMU DFS registers, which are used to configure the target
   frequency for a dynamic rate change. Those registers are relatively
   well isolated from other PMU registers, so they can also be
   "managed" by the drivers/clk/mvebu/clk-cpu.c.

 - The PMSU registers, which are used to actually trigger the dynamic
   frequency change procedure, which consists in programming a bunch
   of PMSU registers, entering the idle state on the CPU we want to
   change the frequency, and then again reprogram a bunch of PMSU
   registers.

The procedure to change the frequency is:

 1/ Reset some clocks using the CPU clocks hardware block.
 2/ Define the target frequency using the PMU DFS registers.
 3/ Do the actual frequency change using the PMSU registers.

However, the PMSU registers are already "managed" by a driver in
arch/arm/mach-mvebu/pmsu.c, and the code there is needed for a wide
variety of power management activities: booting of secondary CPUs, CPU
hotplug, cpuidle, cpufreq, and soon suspend/resume. The same registers
in the PMSU are used for several of those activities.

So, what we need to do is to have steps (1) and (2) above done in the
CPU clocks driver, and then step (3) done through a clk notifier.

However, the current POST_RATE_CHANGE notifier is called too late
(after ->recalc_rate) and only if the rate has changed. So it works
fine for a pure notification of a frequency change, but it doesn't
work if the notified code is actually involved in the frequency
change, which is exactly the case we have here. Until the sequence
that uses the PMSU registers has been executed, the rate of the CPU
clock has not changed.

In order to solve this problem, we propose to add an APPLY_RATE_CHANGE
notifier event, which gets called right after ->set_rate(), but before
->recalc_rate(), and therefore regardless of whether there was an
actualy frequency change or not.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 drivers/clk/clk.c   | 3 +++
 include/linux/clk.h | 4 ++++
 2 files changed, 7 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8b73ede..afa559b 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1525,6 +1525,9 @@ static void clk_change_rate(struct clk *clk)
 	if (!skip_set_rate && clk->ops->set_rate)
 		clk->ops->set_rate(clk->hw, clk->new_rate, best_parent_rate);
 
+	if (clk->notifier_count)
+		__clk_notify(clk, APPLY_RATE_CHANGE, old_rate, clk->new_rate);
+
 	clk->rate = clk_recalc(clk, best_parent_rate);
 
 	if (clk->notifier_count && old_rate != clk->rate)
diff --git a/include/linux/clk.h b/include/linux/clk.h
index fb5e097..9ea9f5f 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -39,10 +39,14 @@ struct clk;
  * POST_RATE_CHANGE - called after the clk rate change has successfully
  *     completed.  Callbacks must always return NOTIFY_DONE or NOTIFY_OK.
  *
+ * APPLY_RATE_CHANGE - called right after calling ->set_rate(), but
+ *     before recalculating the rate.
+ *
  */
 #define PRE_RATE_CHANGE			BIT(0)
 #define POST_RATE_CHANGE		BIT(1)
 #define ABORT_RATE_CHANGE		BIT(2)
+#define APPLY_RATE_CHANGE		BIT(3)
 
 /**
  * struct clk_notifier - associate a clk with a notifier
-- 
2.0.0

[PATCH 1/8] clk: add an APPLY_RATE_CHANGE notifier event during clk_set_rate()

[Thomas Petazzoni]

The current clk_set_rate() logic allows notifiers to be notified of
three different events:

 * PRE_RATE_CHANGE: before the clock driver ->set_rate() function is
   called.
 * ABORT_RATE_CHANGE: called if the rate change failed
 * POST_RATE_CHANGE: called after the rate change has been
   successfully done, but after ->recalc_rate() has been called, and
   only if the rate of the clock has actually changed.

This commit adds an additional APPLY_RATE_CHANGE, which we require on
Armada XP to implement dynamic frequency scaling of the CPU
clocks. The problem is as follows.

On Armada XP, there are three hardware blocks involved in the dynamic
frequency scaling of the CPU clocks:

 - The CPU clocks hardware block itself, whose registers are already
   "managed" by drivers/clk/mvebu/clk-cpu.c (compatible string:
   marvell,armada-xp-cpu-clock). The driver currently only supports
   changing the rate of the CPU clock when the clock is off (i.e
   before we boot the secondary CPUs).

 - The PMU DFS registers, which are used to configure the target
   frequency for a dynamic rate change. Those registers are relatively
   well isolated from other PMU registers, so they can also be
   "managed" by the drivers/clk/mvebu/clk-cpu.c.

 - The PMSU registers, which are used to actually trigger the dynamic
   frequency change procedure, which consists in programming a bunch
   of PMSU registers, entering the idle state on the CPU we want to
   change the frequency, and then again reprogram a bunch of PMSU
   registers.

The procedure to change the frequency is:

 1/ Reset some clocks using the CPU clocks hardware block.
 2/ Define the target frequency using the PMU DFS registers.
 3/ Do the actual frequency change using the PMSU registers.

However, the PMSU registers are already "managed" by a driver in
arch/arm/mach-mvebu/pmsu.c, and the code there is needed for a wide
variety of power management activities: booting of secondary CPUs, CPU
hotplug, cpuidle, cpufreq, and soon suspend/resume. The same registers
in the PMSU are used for several of those activities.

So, what we need to do is to have steps (1) and (2) above done in the
CPU clocks driver, and then step (3) done through a clk notifier.

However, the current POST_RATE_CHANGE notifier is called too late
(after ->recalc_rate) and only if the rate has changed. So it works
fine for a pure notification of a frequency change, but it doesn't
work if the notified code is actually involved in the frequency
change, which is exactly the case we have here. Until the sequence
that uses the PMSU registers has been executed, the rate of the CPU
clock has not changed.

In order to solve this problem, we propose to add an APPLY_RATE_CHANGE
notifier event, which gets called right after ->set_rate(), but before
->recalc_rate(), and therefore regardless of whether there was an
actualy frequency change or not.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 drivers/clk/clk.c   | 3 +++
 include/linux/clk.h | 4 ++++
 2 files changed, 7 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8b73ede..afa559b 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1525,6 +1525,9 @@ static void clk_change_rate(struct clk *clk)
 	if (!skip_set_rate && clk->ops->set_rate)
 		clk->ops->set_rate(clk->hw, clk->new_rate, best_parent_rate);
 
+	if (clk->notifier_count)
+		__clk_notify(clk, APPLY_RATE_CHANGE, old_rate, clk->new_rate);
+
 	clk->rate = clk_recalc(clk, best_parent_rate);
 
 	if (clk->notifier_count && old_rate != clk->rate)
diff --git a/include/linux/clk.h b/include/linux/clk.h
index fb5e097..9ea9f5f 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -39,10 +39,14 @@ struct clk;
  * POST_RATE_CHANGE - called after the clk rate change has successfully
  *     completed.  Callbacks must always return NOTIFY_DONE or NOTIFY_OK.
  *
+ * APPLY_RATE_CHANGE - called right after calling ->set_rate(), but
+ *     before recalculating the rate.
+ *
  */
 #define PRE_RATE_CHANGE			BIT(0)
 #define POST_RATE_CHANGE		BIT(1)
 #define ABORT_RATE_CHANGE		BIT(2)
+#define APPLY_RATE_CHANGE		BIT(3)
 
 /**
  * struct clk_notifier - associate a clk with a notifier
-- 
2.0.0

[PATCH 2/8] cpufreq: add driver for Armada XP

[Thomas Petazzoni]

This commit adds a simple cpufreq driver for the Armada XP SoC, which
has one separately controllable clock for each CPU. For this reason,
the existing cpufreq-cpu0 generic driver cannot be used because it
currently assumes that there is only one clock controlling the
frequency of all CPUs.

There are on-going discussions on extending the cpufreq-cpu0 to cover
the case of having one clock for each CPU, but there are still some
unresolved issues to get this extended cpufreq-cpu0 driver merged. In
the mean time, we propose to have an Armada XP specific cpufreq
driver, and since the choice of the cpufreq driver does not affect the
DT binding at all, it will always be time to get rid of this
SoC-specific driver and use a more generic one when it becomes
available.

In terms of implementation, this cpufreq driver supports two
frequencies: the nominal frequency of the CPU (which cannot be
hardcoded, since it can be changed through Sample At Reset pins) and
half of this frequency. The frequency change itself is implemented by
simply calling clk_set_rate() on the appropriate CPU clock.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 drivers/cpufreq/Kconfig.arm        |   6 ++
 drivers/cpufreq/Makefile           |   1 +
 drivers/cpufreq/armadaxp-cpufreq.c | 112 +++++++++++++++++++++++++++++++++++++
 3 files changed, 119 insertions(+)
 create mode 100644 drivers/cpufreq/armadaxp-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index ebac671..825b273 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -24,6 +24,12 @@ config ARM_VEXPRESS_SPC_CPUFREQ
           This add the CPUfreq driver support for Versatile Express
 	  big.LITTLE platforms using SPC for power management.
 
+config ARM_ARMADAXP_CPUFREQ
+	bool "Marvell Armada XP"
+	depends on MACH_ARMADA_XP
+	default y
+	help
+	  This adds the CPUFreq driver for Marvell Armada XP SoC.
 
 config ARM_EXYNOS_CPUFREQ
 	bool
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 738c8b7..e260a0c 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ)	+= arm_big_little.o
 # LITTLE drivers, so that it is probed last.
 obj-$(CONFIG_ARM_DT_BL_CPUFREQ)		+= arm_big_little_dt.o
 
+obj-$(CONFIG_ARM_ARMADAXP_CPUFREQ)	+= armadaxp-cpufreq.o
 obj-$(CONFIG_ARCH_DAVINCI_DA850)	+= davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500)		+= dbx500-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)	+= exynos-cpufreq.o
diff --git a/drivers/cpufreq/armadaxp-cpufreq.c b/drivers/cpufreq/armadaxp-cpufreq.c
new file mode 100644
index 0000000..e59581f
--- /dev/null
+++ b/drivers/cpufreq/armadaxp-cpufreq.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2014 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/clk.h>
+#include <linux/cpufreq.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+
+#define MAX_CPU_CLKS 4
+
+struct priv {
+	struct clk *cpu_clks[MAX_CPU_CLKS];
+} priv;
+
+#define STATE_CPU_FREQ    0x01
+#define STATE_FABRIC_FREQ 0x02
+
+static struct cpufreq_frequency_table armadaxp_freq_table[] = {
+	{0, STATE_CPU_FREQ,	0},
+	{0, STATE_FABRIC_FREQ,	0},
+	{0, 0,			CPUFREQ_TABLE_END},
+};
+
+static unsigned int armadaxp_cpufreq_get_cpu_frequency(unsigned int cpu)
+{
+	return clk_get_rate(priv.cpu_clks[cpu]) / 1000;
+}
+
+static int armadaxp_cpufreq_target(struct cpufreq_policy *policy,
+			    unsigned int index)
+{
+	clk_set_rate(priv.cpu_clks[policy->cpu],
+		     armadaxp_freq_table[index].frequency * 1000);
+	return 0;
+}
+
+static int armadaxp_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+	if (!cpu_online(policy->cpu))
+		return -ENODEV;
+	policy->cpuinfo.transition_latency = 5000;
+	return cpufreq_table_validate_and_show(policy, armadaxp_freq_table);
+}
+
+static struct cpufreq_driver armadaxp_cpufreq_driver = {
+	.flags	= CPUFREQ_NEED_INITIAL_FREQ_CHECK,
+	.get	= armadaxp_cpufreq_get_cpu_frequency,
+	.verify	= cpufreq_generic_frequency_table_verify,
+	.target_index = armadaxp_cpufreq_target,
+	.init	= armadaxp_cpufreq_cpu_init,
+	.name	= "armadaxp-cpufreq",
+	.attr	= cpufreq_generic_attr,
+};
+
+static int armadaxp_cpufreq_probe(struct platform_device *pdev)
+{
+	struct device_node *np;
+	unsigned long cpu_freq;
+	int i;
+
+	for (i = 0; i < MAX_CPU_CLKS; i++) {
+		np = of_get_cpu_node(i, NULL);
+		if (!np)
+			continue;
+
+		priv.cpu_clks[i] = of_clk_get(np, 0);
+		of_node_put(np);
+	}
+
+	cpu_freq = clk_get_rate(priv.cpu_clks[0]) / 1000;
+
+	/*
+	 * The available frequencies are the nominal CPU frequency,
+	 * and half of it, which is the fabric frequency.
+	 */
+	armadaxp_freq_table[0].frequency = cpu_freq;
+	armadaxp_freq_table[1].frequency = cpu_freq / 2;
+
+	return cpufreq_register_driver(&armadaxp_cpufreq_driver);
+
+}
+
+static int armadaxp_cpufreq_remove(struct platform_device *pdev)
+{
+	cpufreq_unregister_driver(&armadaxp_cpufreq_driver);
+	return 0;
+}
+
+static struct platform_driver armadaxp_cpufreq_platform_driver = {
+	.probe = armadaxp_cpufreq_probe,
+	.remove = armadaxp_cpufreq_remove,
+	.driver = {
+		.name = "armadaxp-cpufreq",
+		.owner = THIS_MODULE,
+	},
+};
+
+module_platform_driver(armadaxp_cpufreq_platform_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Thomas Petazzoni <thomas.petazzoni@free-electrons.com");
+MODULE_DESCRIPTION("cpufreq driver for Marvell's Armada XP CPU");
+MODULE_ALIAS("platform:armadaxp-cpufreq");
-- 
2.0.0

[PATCH 2/8] cpufreq: add driver for Armada XP

[Thomas Petazzoni]

This commit adds a simple cpufreq driver for the Armada XP SoC, which
has one separately controllable clock for each CPU. For this reason,
the existing cpufreq-cpu0 generic driver cannot be used because it
currently assumes that there is only one clock controlling the
frequency of all CPUs.

There are on-going discussions on extending the cpufreq-cpu0 to cover
the case of having one clock for each CPU, but there are still some
unresolved issues to get this extended cpufreq-cpu0 driver merged. In
the mean time, we propose to have an Armada XP specific cpufreq
driver, and since the choice of the cpufreq driver does not affect the
DT binding at all, it will always be time to get rid of this
SoC-specific driver and use a more generic one when it becomes
available.

In terms of implementation, this cpufreq driver supports two
frequencies: the nominal frequency of the CPU (which cannot be
hardcoded, since it can be changed through Sample At Reset pins) and
half of this frequency. The frequency change itself is implemented by
simply calling clk_set_rate() on the appropriate CPU clock.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 drivers/cpufreq/Kconfig.arm        |   6 ++
 drivers/cpufreq/Makefile           |   1 +
 drivers/cpufreq/armadaxp-cpufreq.c | 112 +++++++++++++++++++++++++++++++++++++
 3 files changed, 119 insertions(+)
 create mode 100644 drivers/cpufreq/armadaxp-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index ebac671..825b273 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -24,6 +24,12 @@ config ARM_VEXPRESS_SPC_CPUFREQ
           This add the CPUfreq driver support for Versatile Express
 	  big.LITTLE platforms using SPC for power management.
 
+config ARM_ARMADAXP_CPUFREQ
+	bool "Marvell Armada XP"
+	depends on MACH_ARMADA_XP
+	default y
+	help
+	  This adds the CPUFreq driver for Marvell Armada XP SoC.
 
 config ARM_EXYNOS_CPUFREQ
 	bool
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 738c8b7..e260a0c 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ)	+= arm_big_little.o
 # LITTLE drivers, so that it is probed last.
 obj-$(CONFIG_ARM_DT_BL_CPUFREQ)		+= arm_big_little_dt.o
 
+obj-$(CONFIG_ARM_ARMADAXP_CPUFREQ)	+= armadaxp-cpufreq.o
 obj-$(CONFIG_ARCH_DAVINCI_DA850)	+= davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500)		+= dbx500-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)	+= exynos-cpufreq.o
diff --git a/drivers/cpufreq/armadaxp-cpufreq.c b/drivers/cpufreq/armadaxp-cpufreq.c
new file mode 100644
index 0000000..e59581f
--- /dev/null
+++ b/drivers/cpufreq/armadaxp-cpufreq.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2014 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/clk.h>
+#include <linux/cpufreq.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+
+#define MAX_CPU_CLKS 4
+
+struct priv {
+	struct clk *cpu_clks[MAX_CPU_CLKS];
+} priv;
+
+#define STATE_CPU_FREQ    0x01
+#define STATE_FABRIC_FREQ 0x02
+
+static struct cpufreq_frequency_table armadaxp_freq_table[] = {
+	{0, STATE_CPU_FREQ,	0},
+	{0, STATE_FABRIC_FREQ,	0},
+	{0, 0,			CPUFREQ_TABLE_END},
+};
+
+static unsigned int armadaxp_cpufreq_get_cpu_frequency(unsigned int cpu)
+{
+	return clk_get_rate(priv.cpu_clks[cpu]) / 1000;
+}
+
+static int armadaxp_cpufreq_target(struct cpufreq_policy *policy,
+			    unsigned int index)
+{
+	clk_set_rate(priv.cpu_clks[policy->cpu],
+		     armadaxp_freq_table[index].frequency * 1000);
+	return 0;
+}
+
+static int armadaxp_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+	if (!cpu_online(policy->cpu))
+		return -ENODEV;
+	policy->cpuinfo.transition_latency = 5000;
+	return cpufreq_table_validate_and_show(policy, armadaxp_freq_table);
+}
+
+static struct cpufreq_driver armadaxp_cpufreq_driver = {
+	.flags	= CPUFREQ_NEED_INITIAL_FREQ_CHECK,
+	.get	= armadaxp_cpufreq_get_cpu_frequency,
+	.verify	= cpufreq_generic_frequency_table_verify,
+	.target_index = armadaxp_cpufreq_target,
+	.init	= armadaxp_cpufreq_cpu_init,
+	.name	= "armadaxp-cpufreq",
+	.attr	= cpufreq_generic_attr,
+};
+
+static int armadaxp_cpufreq_probe(struct platform_device *pdev)
+{
+	struct device_node *np;
+	unsigned long cpu_freq;
+	int i;
+
+	for (i = 0; i < MAX_CPU_CLKS; i++) {
+		np = of_get_cpu_node(i, NULL);
+		if (!np)
+			continue;
+
+		priv.cpu_clks[i] = of_clk_get(np, 0);
+		of_node_put(np);
+	}
+
+	cpu_freq = clk_get_rate(priv.cpu_clks[0]) / 1000;
+
+	/*
+	 * The available frequencies are the nominal CPU frequency,
+	 * and half of it, which is the fabric frequency.
+	 */
+	armadaxp_freq_table[0].frequency = cpu_freq;
+	armadaxp_freq_table[1].frequency = cpu_freq / 2;
+
+	return cpufreq_register_driver(&armadaxp_cpufreq_driver);
+
+}
+
+static int armadaxp_cpufreq_remove(struct platform_device *pdev)
+{
+	cpufreq_unregister_driver(&armadaxp_cpufreq_driver);
+	return 0;
+}
+
+static struct platform_driver armadaxp_cpufreq_platform_driver = {
+	.probe = armadaxp_cpufreq_probe,
+	.remove = armadaxp_cpufreq_remove,
+	.driver = {
+		.name = "armadaxp-cpufreq",
+		.owner = THIS_MODULE,
+	},
+};
+
+module_platform_driver(armadaxp_cpufreq_platform_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Thomas Petazzoni <thomas.petazzoni@free-electrons.com");
+MODULE_DESCRIPTION("cpufreq driver for Marvell's Armada XP CPU");
+MODULE_ALIAS("platform:armadaxp-cpufreq");
-- 
2.0.0

[PATCH 3/8] clk: mvebu: extend clk-cpu for dynamic frequency scaling

[Thomas Petazzoni]

This commit extends the existing clk-cpu driver used on Marvell Armada
XP platforms to support the dynamic frequency scaling of the CPU
clock. Non-dynamic frequency change was already supported (and used
before secondary CPUs are started), but the dynamic frequency change
requires a completely different procedure.

In order to achieve this, the clk_cpu_set_rate() function is reworked
to handle two separate cases:

 - The case where the clock is enabled, which is the new dynamic
   frequency change code, implemented in clk_cpu_on_set_rate(). This
   part will be used for cpufreq activities.

 - The case where the clock is disabled, which is the existing
   frequency change code, moved in clk_cpu_off_set_rate(). This part
   is already used to set the clock frequency of the secondary CPUs
   before starting them.

In order to implement the dynamic frequency change function, we need
to access the PMU DFS registers, which are outside the currently
mapped "Clock Complex" registers, so a new area of registers is now
mapped. This affects the Device Tree binding, but we are careful to do
it in a backward-compatible way (by allowing the second pair of
registers to be non-existent, and in this case, ensuring
clk_cpu_on_set_rate() returns an error).

Note that technically speaking, the clk_cpu_on_set_rate() does not do
the entire procedure needed to change the frequency dynamically, as it
involves touching a number of PMSU registers. This is done through a
clock notifier registered by the PMSU driver in followup commits.

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 .../devicetree/bindings/clock/mvebu-cpu-clock.txt  |  5 +-
 drivers/clk/mvebu/clk-cpu.c                        | 79 ++++++++++++++++++++--
 2 files changed, 77 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
index feb8301..99c2146 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
@@ -3,14 +3,15 @@ Device Tree Clock bindings for cpu clock of Marvell EBU platforms
 Required properties:
 - compatible : shall be one of the following:
 	"marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP
-- reg : Address and length of the clock complex register set
+- reg : Address and length of the clock complex register set, followed
+        by address and length of the PMU DFS registers
 - #clock-cells : should be set to 1.
 - clocks : shall be the input parent clock phandle for the clock.
 
 cpuclk: clock-complex@d0018700 {
 	#clock-cells = <1>;
 	compatible = "marvell,armada-xp-cpu-clock";
-	reg = <0xd0018700 0xA0>;
+	reg = <0xd0018700 0xA0>, <0x1c054 0x10>;
 	clocks = <&coreclk 1>;
 }
 
diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
index 8ebf757..b931e72 100644
--- a/drivers/clk/mvebu/clk-cpu.c
+++ b/drivers/clk/mvebu/clk-cpu.c
@@ -16,10 +16,18 @@
 #include <linux/io.h>
 #include <linux/of.h>
 #include <linux/delay.h>
+#include <asm/smp_plat.h>
 
-#define SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET    0x0
-#define SYS_CTRL_CLK_DIVIDER_VALUE_OFFSET   0xC
-#define SYS_CTRL_CLK_DIVIDER_MASK	    0x3F
+#define SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET               0x0
+#define   SYS_CTRL_CLK_DIVIDER_CTRL_RESET_ALL          0xff
+#define   SYS_CTRL_CLK_DIVIDER_CTRL_RESET_SHIFT        8
+#define SYS_CTRL_CLK_DIVIDER_CTRL2_OFFSET              0x8
+#define   SYS_CTRL_CLK_DIVIDER_CTRL2_NBCLK_RATIO_SHIFT 16
+#define SYS_CTRL_CLK_DIVIDER_VALUE_OFFSET              0xC
+#define SYS_CTRL_CLK_DIVIDER_MASK                      0x3F
+
+#define PMU_DFS_RATIO_SHIFT 16
+#define PMU_DFS_RATIO_MASK  0x3F
 
 #define MAX_CPU	    4
 struct cpu_clk {
@@ -28,6 +36,7 @@ struct cpu_clk {
 	const char *clk_name;
 	const char *parent_name;
 	void __iomem *reg_base;
+	void __iomem *pmu_dfs;
 };
 
 static struct clk **clks;
@@ -62,8 +71,9 @@ static long clk_cpu_round_rate(struct clk_hw *hwclk, unsigned long rate,
 	return *parent_rate / div;
 }
 
-static int clk_cpu_set_rate(struct clk_hw *hwclk, unsigned long rate,
-			    unsigned long parent_rate)
+static int clk_cpu_off_set_rate(struct clk_hw *hwclk, unsigned long rate,
+				unsigned long parent_rate)
+
 {
 	struct cpu_clk *cpuclk = to_cpu_clk(hwclk);
 	u32 reg, div;
@@ -95,6 +105,58 @@ static int clk_cpu_set_rate(struct clk_hw *hwclk, unsigned long rate,
 	return 0;
 }
 
+static int clk_cpu_on_set_rate(struct clk_hw *hwclk, unsigned long rate,
+			       unsigned long parent_rate)
+{
+	u32 reg;
+	unsigned long fabric_div, target_div, cur_rate;
+	struct cpu_clk *cpuclk = to_cpu_clk(hwclk);
+
+	/*
+	 * PMU DFS registers are not mapped, Device Tree does not
+	 * describes them. We cannot change the frequency dynamically.
+	 */
+	if (!cpuclk->pmu_dfs)
+		return -ENODEV;
+
+	cur_rate = __clk_get_rate(hwclk->clk);
+
+	reg = readl(cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL2_OFFSET);
+	fabric_div = (reg >> SYS_CTRL_CLK_DIVIDER_CTRL2_NBCLK_RATIO_SHIFT) &
+		SYS_CTRL_CLK_DIVIDER_MASK;
+
+	/* Frequency is going up */
+	if (rate == 2 * cur_rate)
+		target_div = fabric_div / 2;
+	/* Frequency is going down */
+	else
+		target_div = fabric_div;
+
+	if (target_div == 0)
+		target_div = 1;
+
+	reg = readl(cpuclk->pmu_dfs);
+	reg &= ~(PMU_DFS_RATIO_MASK << PMU_DFS_RATIO_SHIFT);
+	reg |= (target_div << PMU_DFS_RATIO_SHIFT);
+	writel(reg, cpuclk->pmu_dfs);
+
+	reg = readl(cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET);
+	reg |= (SYS_CTRL_CLK_DIVIDER_CTRL_RESET_ALL <<
+		SYS_CTRL_CLK_DIVIDER_CTRL_RESET_SHIFT);
+	writel(reg, cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET);
+
+	return 0;
+}
+
+static int clk_cpu_set_rate(struct clk_hw *hwclk, unsigned long rate,
+			    unsigned long parent_rate)
+{
+	if (__clk_is_enabled(hwclk->clk))
+		return clk_cpu_on_set_rate(hwclk, rate, parent_rate);
+	else
+		return clk_cpu_off_set_rate(hwclk, rate, parent_rate);
+}
+
 static const struct clk_ops cpu_ops = {
 	.recalc_rate = clk_cpu_recalc_rate,
 	.round_rate = clk_cpu_round_rate,
@@ -105,6 +167,7 @@ static void __init of_cpu_clk_setup(struct device_node *node)
 {
 	struct cpu_clk *cpuclk;
 	void __iomem *clock_complex_base = of_iomap(node, 0);
+	void __iomem *pmu_dfs_base = of_iomap(node, 1);
 	int ncpus = 0;
 	struct device_node *dn;
 
@@ -114,6 +177,10 @@ static void __init of_cpu_clk_setup(struct device_node *node)
 		return;
 	}
 
+	if (pmu_dfs_base == NULL)
+		pr_warn("%s: pmu-dfs base register not set, dynamic frequency scaling not available\n",
+			__func__);
+
 	for_each_node_by_type(dn, "cpu")
 		ncpus++;
 
@@ -146,6 +213,8 @@ static void __init of_cpu_clk_setup(struct device_node *node)
 		cpuclk[cpu].clk_name = clk_name;
 		cpuclk[cpu].cpu = cpu;
 		cpuclk[cpu].reg_base = clock_complex_base;
+		if (pmu_dfs_base)
+			cpuclk[cpu].pmu_dfs = pmu_dfs_base + 4 * cpu;
 		cpuclk[cpu].hw.init = &init;
 
 		init.name = cpuclk[cpu].clk_name;
-- 
2.0.0

[PATCH 3/8] clk: mvebu: extend clk-cpu for dynamic frequency scaling

[Thomas Petazzoni]

This commit extends the existing clk-cpu driver used on Marvell Armada
XP platforms to support the dynamic frequency scaling of the CPU
clock. Non-dynamic frequency change was already supported (and used
before secondary CPUs are started), but the dynamic frequency change
requires a completely different procedure.

In order to achieve this, the clk_cpu_set_rate() function is reworked
to handle two separate cases:

 - The case where the clock is enabled, which is the new dynamic
   frequency change code, implemented in clk_cpu_on_set_rate(). This
   part will be used for cpufreq activities.

 - The case where the clock is disabled, which is the existing
   frequency change code, moved in clk_cpu_off_set_rate(). This part
   is already used to set the clock frequency of the secondary CPUs
   before starting them.

In order to implement the dynamic frequency change function, we need
to access the PMU DFS registers, which are outside the currently
mapped "Clock Complex" registers, so a new area of registers is now
mapped. This affects the Device Tree binding, but we are careful to do
it in a backward-compatible way (by allowing the second pair of
registers to be non-existent, and in this case, ensuring
clk_cpu_on_set_rate() returns an error).

Note that technically speaking, the clk_cpu_on_set_rate() does not do
the entire procedure needed to change the frequency dynamically, as it
involves touching a number of PMSU registers. This is done through a
clock notifier registered by the PMSU driver in followup commits.

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 .../devicetree/bindings/clock/mvebu-cpu-clock.txt  |  5 +-
 drivers/clk/mvebu/clk-cpu.c                        | 79 ++++++++++++++++++++--
 2 files changed, 77 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
index feb8301..99c2146 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
@@ -3,14 +3,15 @@ Device Tree Clock bindings for cpu clock of Marvell EBU platforms
 Required properties:
 - compatible : shall be one of the following:
 	"marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP
-- reg : Address and length of the clock complex register set
+- reg : Address and length of the clock complex register set, followed
+        by address and length of the PMU DFS registers
 - #clock-cells : should be set to 1.
 - clocks : shall be the input parent clock phandle for the clock.
 
 cpuclk: clock-complex at d0018700 {
 	#clock-cells = <1>;
 	compatible = "marvell,armada-xp-cpu-clock";
-	reg = <0xd0018700 0xA0>;
+	reg = <0xd0018700 0xA0>, <0x1c054 0x10>;
 	clocks = <&coreclk 1>;
 }
 
diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
index 8ebf757..b931e72 100644
--- a/drivers/clk/mvebu/clk-cpu.c
+++ b/drivers/clk/mvebu/clk-cpu.c
@@ -16,10 +16,18 @@
 #include <linux/io.h>
 #include <linux/of.h>
 #include <linux/delay.h>
+#include <asm/smp_plat.h>
 
-#define SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET    0x0
-#define SYS_CTRL_CLK_DIVIDER_VALUE_OFFSET   0xC
-#define SYS_CTRL_CLK_DIVIDER_MASK	    0x3F
+#define SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET               0x0
+#define   SYS_CTRL_CLK_DIVIDER_CTRL_RESET_ALL          0xff
+#define   SYS_CTRL_CLK_DIVIDER_CTRL_RESET_SHIFT        8
+#define SYS_CTRL_CLK_DIVIDER_CTRL2_OFFSET              0x8
+#define   SYS_CTRL_CLK_DIVIDER_CTRL2_NBCLK_RATIO_SHIFT 16
+#define SYS_CTRL_CLK_DIVIDER_VALUE_OFFSET              0xC
+#define SYS_CTRL_CLK_DIVIDER_MASK                      0x3F
+
+#define PMU_DFS_RATIO_SHIFT 16
+#define PMU_DFS_RATIO_MASK  0x3F
 
 #define MAX_CPU	    4
 struct cpu_clk {
@@ -28,6 +36,7 @@ struct cpu_clk {
 	const char *clk_name;
 	const char *parent_name;
 	void __iomem *reg_base;
+	void __iomem *pmu_dfs;
 };
 
 static struct clk **clks;
@@ -62,8 +71,9 @@ static long clk_cpu_round_rate(struct clk_hw *hwclk, unsigned long rate,
 	return *parent_rate / div;
 }
 
-static int clk_cpu_set_rate(struct clk_hw *hwclk, unsigned long rate,
-			    unsigned long parent_rate)
+static int clk_cpu_off_set_rate(struct clk_hw *hwclk, unsigned long rate,
+				unsigned long parent_rate)
+
 {
 	struct cpu_clk *cpuclk = to_cpu_clk(hwclk);
 	u32 reg, div;
@@ -95,6 +105,58 @@ static int clk_cpu_set_rate(struct clk_hw *hwclk, unsigned long rate,
 	return 0;
 }
 
+static int clk_cpu_on_set_rate(struct clk_hw *hwclk, unsigned long rate,
+			       unsigned long parent_rate)
+{
+	u32 reg;
+	unsigned long fabric_div, target_div, cur_rate;
+	struct cpu_clk *cpuclk = to_cpu_clk(hwclk);
+
+	/*
+	 * PMU DFS registers are not mapped, Device Tree does not
+	 * describes them. We cannot change the frequency dynamically.
+	 */
+	if (!cpuclk->pmu_dfs)
+		return -ENODEV;
+
+	cur_rate = __clk_get_rate(hwclk->clk);
+
+	reg = readl(cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL2_OFFSET);
+	fabric_div = (reg >> SYS_CTRL_CLK_DIVIDER_CTRL2_NBCLK_RATIO_SHIFT) &
+		SYS_CTRL_CLK_DIVIDER_MASK;
+
+	/* Frequency is going up */
+	if (rate == 2 * cur_rate)
+		target_div = fabric_div / 2;
+	/* Frequency is going down */
+	else
+		target_div = fabric_div;
+
+	if (target_div == 0)
+		target_div = 1;
+
+	reg = readl(cpuclk->pmu_dfs);
+	reg &= ~(PMU_DFS_RATIO_MASK << PMU_DFS_RATIO_SHIFT);
+	reg |= (target_div << PMU_DFS_RATIO_SHIFT);
+	writel(reg, cpuclk->pmu_dfs);
+
+	reg = readl(cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET);
+	reg |= (SYS_CTRL_CLK_DIVIDER_CTRL_RESET_ALL <<
+		SYS_CTRL_CLK_DIVIDER_CTRL_RESET_SHIFT);
+	writel(reg, cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET);
+
+	return 0;
+}
+
+static int clk_cpu_set_rate(struct clk_hw *hwclk, unsigned long rate,
+			    unsigned long parent_rate)
+{
+	if (__clk_is_enabled(hwclk->clk))
+		return clk_cpu_on_set_rate(hwclk, rate, parent_rate);
+	else
+		return clk_cpu_off_set_rate(hwclk, rate, parent_rate);
+}
+
 static const struct clk_ops cpu_ops = {
 	.recalc_rate = clk_cpu_recalc_rate,
 	.round_rate = clk_cpu_round_rate,
@@ -105,6 +167,7 @@ static void __init of_cpu_clk_setup(struct device_node *node)
 {
 	struct cpu_clk *cpuclk;
 	void __iomem *clock_complex_base = of_iomap(node, 0);
+	void __iomem *pmu_dfs_base = of_iomap(node, 1);
 	int ncpus = 0;
 	struct device_node *dn;
 
@@ -114,6 +177,10 @@ static void __init of_cpu_clk_setup(struct device_node *node)
 		return;
 	}
 
+	if (pmu_dfs_base == NULL)
+		pr_warn("%s: pmu-dfs base register not set, dynamic frequency scaling not available\n",
+			__func__);
+
 	for_each_node_by_type(dn, "cpu")
 		ncpus++;
 
@@ -146,6 +213,8 @@ static void __init of_cpu_clk_setup(struct device_node *node)
 		cpuclk[cpu].clk_name = clk_name;
 		cpuclk[cpu].cpu = cpu;
 		cpuclk[cpu].reg_base = clock_complex_base;
+		if (pmu_dfs_base)
+			cpuclk[cpu].pmu_dfs = pmu_dfs_base + 4 * cpu;
 		cpuclk[cpu].hw.init = &init;
 
 		init.name = cpuclk[cpu].clk_name;
-- 
2.0.0

[PATCH 4/8] ARM: mvebu: ensure CPU clocks are enabled

[Thomas Petazzoni]

In the Armada XP SMP support code, we are reading the clock frequency
of the booting CPU, and use that to assign the same frequency to the
other CPUs, and we do this while the clocks are disabled.

However, the CPU clocks are in fact never prepared/enabled, and to
support cpufreq, we now have two code paths to change the frequency of
the CPU clocks in the CPU clock driver: one when the clock is enabled
(dynamic frequency scaling), one when the clock is disabled (adjusting
the CPU frequency before starting the CPU). In order for this to work,
the CPU clocks now have to be prepared and enabled after the initial
synchronization of the clock frequencies is done, so that all future
rate changes of the CPU clocks will trigger a dynamic frequency
scaling transition.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/mach-mvebu/platsmp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 88b976b3..4880b0f 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -67,6 +67,7 @@ static void __init set_secondary_cpus_clock(void)
 		if (!cpu_clk)
 			return;
 		clk_set_rate(cpu_clk, rate);
+		clk_prepare_enable(cpu_clk);
 	}
 }
 
-- 
2.0.0

[PATCH 4/8] ARM: mvebu: ensure CPU clocks are enabled

[Thomas Petazzoni]

In the Armada XP SMP support code, we are reading the clock frequency
of the booting CPU, and use that to assign the same frequency to the
other CPUs, and we do this while the clocks are disabled.

However, the CPU clocks are in fact never prepared/enabled, and to
support cpufreq, we now have two code paths to change the frequency of
the CPU clocks in the CPU clock driver: one when the clock is enabled
(dynamic frequency scaling), one when the clock is disabled (adjusting
the CPU frequency before starting the CPU). In order for this to work,
the CPU clocks now have to be prepared and enabled after the initial
synchronization of the clock frequencies is done, so that all future
rate changes of the CPU clocks will trigger a dynamic frequency
scaling transition.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/mach-mvebu/platsmp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 88b976b3..4880b0f 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -67,6 +67,7 @@ static void __init set_secondary_cpus_clock(void)
 		if (!cpu_clk)
 			return;
 		clk_set_rate(cpu_clk, rate);
+		clk_prepare_enable(cpu_clk);
 	}
 }
 
-- 
2.0.0

[PATCH 5/8] ARM: mvebu: extend PMSU code to support dynamic frequency scaling

[Thomas Petazzoni]

This commit adds the necessary code in the Marvell EBU PMSU driver to
support dynamic frequency scaling. In essence, what this new code does
is that it registers a clock notifier of the CPU clocks. The notifier
function listens to the newly introduced APPLY_RATE_CHANGE event, and
uses that to finalize the frequency transition by doing the part of
the procedure that involves the PMSU.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/mach-mvebu/pmsu.c | 168 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 168 insertions(+)

diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
index 53a55c8..a114e4a 100644
--- a/arch/arm/mach-mvebu/pmsu.c
+++ b/arch/arm/mach-mvebu/pmsu.c
@@ -18,20 +18,25 @@
 
 #define pr_fmt(fmt) "mvebu-pmsu: " fmt
 
+#include <linux/clk.h>
 #include <linux/cpu_pm.h>
+#include <linux/delay.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/of_address.h>
+#include <linux/of_device.h>
 #include <linux/io.h>
 #include <linux/platform_device.h>
 #include <linux/smp.h>
 #include <linux/resource.h>
+#include <linux/slab.h>
 #include <asm/cacheflush.h>
 #include <asm/cp15.h>
 #include <asm/smp_plat.h>
 #include <asm/suspend.h>
 #include <asm/tlbflush.h>
 #include "common.h"
+#include "armada-370-xp.h"
 
 static void __iomem *pmsu_mp_base;
 
@@ -57,6 +62,10 @@ static void __iomem *pmsu_mp_base;
 #define PMSU_STATUS_AND_MASK_IRQ_MASK		BIT(24)
 #define PMSU_STATUS_AND_MASK_FIQ_MASK		BIT(25)
 
+#define PMSU_EVENT_STATUS_AND_MASK(cpu)     ((cpu * 0x100) + 0x120)
+#define PMSU_EVENT_STATUS_AND_MASK_DFS_DONE        BIT(1)
+#define PMSU_EVENT_STATUS_AND_MASK_DFS_DONE_MASK   BIT(17)
+
 #define PMSU_BOOT_ADDR_REDIRECT_OFFSET(cpu) ((cpu * 0x100) + 0x124)
 
 /* PMSU fabric registers */
@@ -296,3 +305,162 @@ int __init armada_370_xp_cpu_pm_init(void)
 
 arch_initcall(armada_370_xp_cpu_pm_init);
 early_initcall(armada_370_xp_pmsu_init);
+
+static void armada_xp_cpufreq_clk_set_local(void *data)
+{
+	u32 reg;
+	u32 cpu = smp_processor_id();
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	/* Prepare to enter idle */
+	reg = readl(pmsu_mp_base + PMSU_STATUS_AND_MASK(cpu));
+	reg |= PMSU_STATUS_AND_MASK_CPU_IDLE_WAIT |
+	       PMSU_STATUS_AND_MASK_IRQ_MASK     |
+	       PMSU_STATUS_AND_MASK_FIQ_MASK;
+	writel(reg, pmsu_mp_base + PMSU_STATUS_AND_MASK(cpu));
+
+	/* Request the DFS transition */
+	reg = readl(pmsu_mp_base + PMSU_CONTROL_AND_CONFIG(cpu));
+	reg |= PMSU_CONTROL_AND_CONFIG_DFS_REQ;
+	writel(reg, pmsu_mp_base + PMSU_CONTROL_AND_CONFIG(cpu));
+
+	/* The fact of entering idle will trigger the DFS transition */
+	wfi();
+
+	/*
+	 * We're back from idle, the DFS transition has completed,
+	 * clear the idle wait indication.
+	 */
+	reg = readl(pmsu_mp_base + PMSU_STATUS_AND_MASK(cpu));
+	reg &= ~PMSU_STATUS_AND_MASK_CPU_IDLE_WAIT;
+	writel(reg, pmsu_mp_base + PMSU_STATUS_AND_MASK(cpu));
+
+	local_irq_restore(flags);
+}
+
+struct armada_xp_cpufreq_notifier_block {
+	struct notifier_block nb;
+	int cpu;
+};
+
+static int armada_xp_cpufreq_clk_notify(struct notifier_block *self,
+					unsigned long action, void *data)
+{
+	struct armada_xp_cpufreq_notifier_block *nb =
+		container_of(self, struct armada_xp_cpufreq_notifier_block, nb);
+	unsigned long timeout;
+	int cpu = nb->cpu;
+	u32 reg;
+
+	if (action != APPLY_RATE_CHANGE)
+		return 0;
+
+	/* Clear any previous DFS DONE event */
+	reg = readl(pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+	reg &= ~PMSU_EVENT_STATUS_AND_MASK_DFS_DONE;
+	writel(reg, pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+
+	/* Mask the DFS done interrupt, since we are going to poll */
+	reg = readl(pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+	reg |= PMSU_EVENT_STATUS_AND_MASK_DFS_DONE_MASK;
+	writel(reg, pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+
+	/* Trigger the DFS on the appropriate CPU */
+	smp_call_function_single(get_logical_index(cpu),
+				 armada_xp_cpufreq_clk_set_local, NULL, false);
+
+	/* Poll until the DFS done event is generated */
+	timeout = jiffies + HZ;
+	while (time_before(jiffies, timeout)) {
+		reg = readl(pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+		if (reg & PMSU_EVENT_STATUS_AND_MASK_DFS_DONE)
+			break;
+		udelay(10);
+	}
+
+	/* Restore the DFS mask to its original state */
+	reg = readl(pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+	reg &= ~BIT(17);
+	writel(reg, pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+
+	return NOTIFY_DONE;
+}
+
+static int __init armada_xp_pmsu_cpufreq_init(void)
+{
+	struct device_node *np;
+	struct resource res;
+	int i, ret;
+
+	if (!of_machine_is_compatible("marvell,armadaxp"))
+		return 0;
+
+	/*
+	 * In order to have proper cpufreq handling, we need to ensure
+	 * that the Device Tree description of the CPU clock includes
+	 * the definition of the PMU DFS registers. If not, we do not
+	 * register the clock notifier and the cpufreq driver. This
+	 * piece of code is only for compatibility with old Device
+	 * Trees.
+	 */
+	np = of_find_compatible_node(NULL, NULL, "marvell,armada-xp-cpu-clock");
+	if (!np)
+		return 0;
+
+	ret = of_address_to_resource(np, 1, &res);
+	if (ret) {
+		pr_warn(FW_WARN "not enabling cpufreq, deprecated armada-xp-cpu-clock binding\n");
+		of_node_put(np);
+		return 0;
+	}
+
+	of_node_put(np);
+
+	for (i = 0; i < ARMADA_XP_MAX_CPUS; i++) {
+		struct clk *clk;
+		struct armada_xp_cpufreq_notifier_block *nbs;
+		struct device_node *np;
+		int ret;
+
+		np = of_get_cpu_node(i, NULL);
+		if (!np)
+			return -ENODEV;
+
+		clk = of_clk_get(np, 0);
+		if (!clk) {
+			pr_err("Cannot get clock for CPU %d\n", i);
+			of_node_put(np);
+			return -ENODEV;
+		}
+
+		nbs = kzalloc(sizeof(struct armada_xp_cpufreq_notifier_block),
+			      GFP_KERNEL);
+		if (!nbs) {
+			pr_err("Cannot allocate memory for cpufreq notifier\n");
+			clk_put(clk);
+			of_node_put(np);
+			return -ENOMEM;
+		}
+
+		nbs->nb.notifier_call = armada_xp_cpufreq_clk_notify;
+		nbs->cpu = i;
+
+		ret = clk_notifier_register(clk, &nbs->nb);
+		if (ret) {
+			pr_err("Cannot register clock notifier\n");
+			kfree(nbs);
+			clk_put(clk);
+			of_node_put(np);
+			return ret;
+		}
+
+		of_node_put(np);
+	}
+
+	platform_device_register_simple("armadaxp-cpufreq", -1, NULL, 0);
+	return 0;
+}
+
+arch_initcall(armada_xp_pmsu_cpufreq_init);
-- 
2.0.0

[PATCH 5/8] ARM: mvebu: extend PMSU code to support dynamic frequency scaling

[Thomas Petazzoni]

This commit adds the necessary code in the Marvell EBU PMSU driver to
support dynamic frequency scaling. In essence, what this new code does
is that it registers a clock notifier of the CPU clocks. The notifier
function listens to the newly introduced APPLY_RATE_CHANGE event, and
uses that to finalize the frequency transition by doing the part of
the procedure that involves the PMSU.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/mach-mvebu/pmsu.c | 168 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 168 insertions(+)

diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
index 53a55c8..a114e4a 100644
--- a/arch/arm/mach-mvebu/pmsu.c
+++ b/arch/arm/mach-mvebu/pmsu.c
@@ -18,20 +18,25 @@
 
 #define pr_fmt(fmt) "mvebu-pmsu: " fmt
 
+#include <linux/clk.h>
 #include <linux/cpu_pm.h>
+#include <linux/delay.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/of_address.h>
+#include <linux/of_device.h>
 #include <linux/io.h>
 #include <linux/platform_device.h>
 #include <linux/smp.h>
 #include <linux/resource.h>
+#include <linux/slab.h>
 #include <asm/cacheflush.h>
 #include <asm/cp15.h>
 #include <asm/smp_plat.h>
 #include <asm/suspend.h>
 #include <asm/tlbflush.h>
 #include "common.h"
+#include "armada-370-xp.h"
 
 static void __iomem *pmsu_mp_base;
 
@@ -57,6 +62,10 @@ static void __iomem *pmsu_mp_base;
 #define PMSU_STATUS_AND_MASK_IRQ_MASK		BIT(24)
 #define PMSU_STATUS_AND_MASK_FIQ_MASK		BIT(25)
 
+#define PMSU_EVENT_STATUS_AND_MASK(cpu)     ((cpu * 0x100) + 0x120)
+#define PMSU_EVENT_STATUS_AND_MASK_DFS_DONE        BIT(1)
+#define PMSU_EVENT_STATUS_AND_MASK_DFS_DONE_MASK   BIT(17)
+
 #define PMSU_BOOT_ADDR_REDIRECT_OFFSET(cpu) ((cpu * 0x100) + 0x124)
 
 /* PMSU fabric registers */
@@ -296,3 +305,162 @@ int __init armada_370_xp_cpu_pm_init(void)
 
 arch_initcall(armada_370_xp_cpu_pm_init);
 early_initcall(armada_370_xp_pmsu_init);
+
+static void armada_xp_cpufreq_clk_set_local(void *data)
+{
+	u32 reg;
+	u32 cpu = smp_processor_id();
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	/* Prepare to enter idle */
+	reg = readl(pmsu_mp_base + PMSU_STATUS_AND_MASK(cpu));
+	reg |= PMSU_STATUS_AND_MASK_CPU_IDLE_WAIT |
+	       PMSU_STATUS_AND_MASK_IRQ_MASK     |
+	       PMSU_STATUS_AND_MASK_FIQ_MASK;
+	writel(reg, pmsu_mp_base + PMSU_STATUS_AND_MASK(cpu));
+
+	/* Request the DFS transition */
+	reg = readl(pmsu_mp_base + PMSU_CONTROL_AND_CONFIG(cpu));
+	reg |= PMSU_CONTROL_AND_CONFIG_DFS_REQ;
+	writel(reg, pmsu_mp_base + PMSU_CONTROL_AND_CONFIG(cpu));
+
+	/* The fact of entering idle will trigger the DFS transition */
+	wfi();
+
+	/*
+	 * We're back from idle, the DFS transition has completed,
+	 * clear the idle wait indication.
+	 */
+	reg = readl(pmsu_mp_base + PMSU_STATUS_AND_MASK(cpu));
+	reg &= ~PMSU_STATUS_AND_MASK_CPU_IDLE_WAIT;
+	writel(reg, pmsu_mp_base + PMSU_STATUS_AND_MASK(cpu));
+
+	local_irq_restore(flags);
+}
+
+struct armada_xp_cpufreq_notifier_block {
+	struct notifier_block nb;
+	int cpu;
+};
+
+static int armada_xp_cpufreq_clk_notify(struct notifier_block *self,
+					unsigned long action, void *data)
+{
+	struct armada_xp_cpufreq_notifier_block *nb =
+		container_of(self, struct armada_xp_cpufreq_notifier_block, nb);
+	unsigned long timeout;
+	int cpu = nb->cpu;
+	u32 reg;
+
+	if (action != APPLY_RATE_CHANGE)
+		return 0;
+
+	/* Clear any previous DFS DONE event */
+	reg = readl(pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+	reg &= ~PMSU_EVENT_STATUS_AND_MASK_DFS_DONE;
+	writel(reg, pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+
+	/* Mask the DFS done interrupt, since we are going to poll */
+	reg = readl(pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+	reg |= PMSU_EVENT_STATUS_AND_MASK_DFS_DONE_MASK;
+	writel(reg, pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+
+	/* Trigger the DFS on the appropriate CPU */
+	smp_call_function_single(get_logical_index(cpu),
+				 armada_xp_cpufreq_clk_set_local, NULL, false);
+
+	/* Poll until the DFS done event is generated */
+	timeout = jiffies + HZ;
+	while (time_before(jiffies, timeout)) {
+		reg = readl(pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+		if (reg & PMSU_EVENT_STATUS_AND_MASK_DFS_DONE)
+			break;
+		udelay(10);
+	}
+
+	/* Restore the DFS mask to its original state */
+	reg = readl(pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+	reg &= ~BIT(17);
+	writel(reg, pmsu_mp_base + PMSU_EVENT_STATUS_AND_MASK(cpu));
+
+	return NOTIFY_DONE;
+}
+
+static int __init armada_xp_pmsu_cpufreq_init(void)
+{
+	struct device_node *np;
+	struct resource res;
+	int i, ret;
+
+	if (!of_machine_is_compatible("marvell,armadaxp"))
+		return 0;
+
+	/*
+	 * In order to have proper cpufreq handling, we need to ensure
+	 * that the Device Tree description of the CPU clock includes
+	 * the definition of the PMU DFS registers. If not, we do not
+	 * register the clock notifier and the cpufreq driver. This
+	 * piece of code is only for compatibility with old Device
+	 * Trees.
+	 */
+	np = of_find_compatible_node(NULL, NULL, "marvell,armada-xp-cpu-clock");
+	if (!np)
+		return 0;
+
+	ret = of_address_to_resource(np, 1, &res);
+	if (ret) {
+		pr_warn(FW_WARN "not enabling cpufreq, deprecated armada-xp-cpu-clock binding\n");
+		of_node_put(np);
+		return 0;
+	}
+
+	of_node_put(np);
+
+	for (i = 0; i < ARMADA_XP_MAX_CPUS; i++) {
+		struct clk *clk;
+		struct armada_xp_cpufreq_notifier_block *nbs;
+		struct device_node *np;
+		int ret;
+
+		np = of_get_cpu_node(i, NULL);
+		if (!np)
+			return -ENODEV;
+
+		clk = of_clk_get(np, 0);
+		if (!clk) {
+			pr_err("Cannot get clock for CPU %d\n", i);
+			of_node_put(np);
+			return -ENODEV;
+		}
+
+		nbs = kzalloc(sizeof(struct armada_xp_cpufreq_notifier_block),
+			      GFP_KERNEL);
+		if (!nbs) {
+			pr_err("Cannot allocate memory for cpufreq notifier\n");
+			clk_put(clk);
+			of_node_put(np);
+			return -ENOMEM;
+		}
+
+		nbs->nb.notifier_call = armada_xp_cpufreq_clk_notify;
+		nbs->cpu = i;
+
+		ret = clk_notifier_register(clk, &nbs->nb);
+		if (ret) {
+			pr_err("Cannot register clock notifier\n");
+			kfree(nbs);
+			clk_put(clk);
+			of_node_put(np);
+			return ret;
+		}
+
+		of_node_put(np);
+	}
+
+	platform_device_register_simple("armadaxp-cpufreq", -1, NULL, 0);
+	return 0;
+}
+
+arch_initcall(armada_xp_pmsu_cpufreq_init);
-- 
2.0.0

[PATCH 6/8] ARM: mvebu: update Armada XP DT for dynamic frequency scaling

[Thomas Petazzoni]

In order to support dynamic frequency scaling, the cpuclk Device Tree
node needs to be updated to describe a second set of registers
describing the PMU DFS registers.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/boot/dts/armada-xp.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 5902e83..bff9f6c 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -99,7 +99,7 @@
 			cpuclk: clock-complex@18700 {
 				#clock-cells = <1>;
 				compatible = "marvell,armada-xp-cpu-clock";
-				reg = <0x18700 0xA0>;
+				reg = <0x18700 0xA0>, <0x1c054 0x10>;
 				clocks = <&coreclk 1>;
 			};
 
-- 
2.0.0

[PATCH 6/8] ARM: mvebu: update Armada XP DT for dynamic frequency scaling

[Thomas Petazzoni]

In order to support dynamic frequency scaling, the cpuclk Device Tree
node needs to be updated to describe a second set of registers
describing the PMU DFS registers.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/boot/dts/armada-xp.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 5902e83..bff9f6c 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -99,7 +99,7 @@
 			cpuclk: clock-complex at 18700 {
 				#clock-cells = <1>;
 				compatible = "marvell,armada-xp-cpu-clock";
-				reg = <0x18700 0xA0>;
+				reg = <0x18700 0xA0>, <0x1c054 0x10>;
 				clocks = <&coreclk 1>;
 			};
 
-- 
2.0.0

[PATCH 7/8] ARM: mvebu: allow enabling of cpufreq on Armada XP

[Thomas Petazzoni]

Now that all the pieces to enable cpufreq on Armada XP are in place,
we can make MACH_ARMADA_XP select ARCH_HAS_CPUFREQ to allow the usage
of dynamic frequency scaling on this platform.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/mach-mvebu/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index b9bc599..1ff60ef 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -66,6 +66,7 @@ config MACH_ARMADA_XP
 	select CPU_PJ4B
 	select MACH_MVEBU_V7
 	select PINCTRL_ARMADA_XP
+	select ARCH_HAS_CPUFREQ
 	help
 	  Say 'Y' here if you want your kernel to support boards based
 	  on the Marvell Armada XP SoC with device tree.
-- 
2.0.0

[PATCH 7/8] ARM: mvebu: allow enabling of cpufreq on Armada XP

[Thomas Petazzoni]

Now that all the pieces to enable cpufreq on Armada XP are in place,
we can make MACH_ARMADA_XP select ARCH_HAS_CPUFREQ to allow the usage
of dynamic frequency scaling on this platform.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/mach-mvebu/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index b9bc599..1ff60ef 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -66,6 +66,7 @@ config MACH_ARMADA_XP
 	select CPU_PJ4B
 	select MACH_MVEBU_V7
 	select PINCTRL_ARMADA_XP
+	select ARCH_HAS_CPUFREQ
 	help
 	  Say 'Y' here if you want your kernel to support boards based
 	  on the Marvell Armada XP SoC with device tree.
-- 
2.0.0

[PATCH 8/8] ARM: mvebu: update mvebu_v7_defconfig with cpufreq support

[Thomas Petazzoni]

Now that the Armada XP supports dynamic CPU frequency scaling, it
makes sense to enable the cpufreq subsystem in
mvebu_v7_defconfig. There's no need to explicitly enable the Armada XP
specific driver because it has a 'default y' with a 'depends on
MACH_ARMADA_XP' so it gets enabled automatically as soon as the
cpufreq subsystem is enabled.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/configs/mvebu_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index b0bfefa..22b94ea 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -29,6 +29,7 @@ CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
+CONFIG_CPU_FREQ=y
 CONFIG_VFP=y
 CONFIG_NET=y
 CONFIG_INET=y
-- 
2.0.0

[PATCH 8/8] ARM: mvebu: update mvebu_v7_defconfig with cpufreq support

[Thomas Petazzoni]

Now that the Armada XP supports dynamic CPU frequency scaling, it
makes sense to enable the cpufreq subsystem in
mvebu_v7_defconfig. There's no need to explicitly enable the Armada XP
specific driver because it has a 'default y' with a 'depends on
MACH_ARMADA_XP' so it gets enabled automatically as soon as the
cpufreq subsystem is enabled.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/configs/mvebu_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index b0bfefa..22b94ea 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -29,6 +29,7 @@ CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
+CONFIG_CPU_FREQ=y
 CONFIG_VFP=y
 CONFIG_NET=y
 CONFIG_INET=y
-- 
2.0.0

Re: [PATCH 2/8] cpufreq: add driver for Armada XP

[Viresh Kumar]

On 4 July 2014 15:14, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> This commit adds a simple cpufreq driver for the Armada XP SoC, which
> has one separately controllable clock for each CPU. For this reason,
> the existing cpufreq-cpu0 generic driver cannot be used because it
> currently assumes that there is only one clock controlling the
> frequency of all CPUs.
>
> There are on-going discussions on extending the cpufreq-cpu0 to cover
> the case of having one clock for each CPU, but there are still some
> unresolved issues to get this extended cpufreq-cpu0 driver merged.

Exactly, and those changes would get merged in one form or the other.
Surely in 3.17 atleast, if not 3.16 as we are already reaching rc4..

So, it would be great if you can test on top of those changes to see if
something isn't solved for your platform yet?

git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v3

--
viresh

[PATCH 2/8] cpufreq: add driver for Armada XP

[Viresh Kumar]

On 4 July 2014 15:14, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> This commit adds a simple cpufreq driver for the Armada XP SoC, which
> has one separately controllable clock for each CPU. For this reason,
> the existing cpufreq-cpu0 generic driver cannot be used because it
> currently assumes that there is only one clock controlling the
> frequency of all CPUs.
>
> There are on-going discussions on extending the cpufreq-cpu0 to cover
> the case of having one clock for each CPU, but there are still some
> unresolved issues to get this extended cpufreq-cpu0 driver merged.

Exactly, and those changes would get merged in one form or the other.
Surely in 3.17 atleast, if not 3.16 as we are already reaching rc4..

So, it would be great if you can test on top of those changes to see if
something isn't solved for your platform yet?

git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v3

--
viresh

Re: [PATCH 2/8] cpufreq: add driver for Armada XP

[Thomas Petazzoni]

Dear Viresh Kumar,

Thanks for your feedback!

On Fri, 4 Jul 2014 15:25:35 +0530, Viresh Kumar wrote:
> On 4 July 2014 15:14, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > This commit adds a simple cpufreq driver for the Armada XP SoC, which
> > has one separately controllable clock for each CPU. For this reason,
> > the existing cpufreq-cpu0 generic driver cannot be used because it
> > currently assumes that there is only one clock controlling the
> > frequency of all CPUs.
> >
> > There are on-going discussions on extending the cpufreq-cpu0 to cover
> > the case of having one clock for each CPU, but there are still some
> > unresolved issues to get this extended cpufreq-cpu0 driver merged.
> 
> Exactly, and those changes would get merged in one form or the other.
> Surely in 3.17 atleast, if not 3.16 as we are already reaching rc4..
> 
> So, it would be great if you can test on top of those changes to see if
> something isn't solved for your platform yet?
> 
> git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v3

One other problem with cpufreq-cpu0 is that it assumes the Device Tree
can contain a static OPP table, with the frequency/voltage points.
Unfortunately, in the case of the Armada XP platform, this is not
possible, because we cannot hardcode into the Device Tree the possible
CPU frequencies.

The nominal CPU frequency is selected by Sample on Reset pins (i.e pins
of the CPUs that are sampled during the reset sequence) and can
therefore change from one board to the other, and they can also be
changed via special U-Boot commands. And the frequencies supported by
cpufreq are the nominal frequency of the CPU as determined by the
sample at reset pins, and half of this frequency.

That's why the proposed armadaxp-cpufreq driver does not hardcode the
possible frequencies, but instead creates the frequency table by using
the current CPU frequency (nominal frequency) and half of it.

This doesn't work very well with the idea of having the OPP table
statically encoded in to the Device Tree. Options are:

 - Improve the cpufreq-cpu0 driver so that the OPP table can be passed
   through platform_data, and therefore built dynamically by the
   platform code and passed when registering the cpufreq
   platform_device.

 - Dynamically build/update the OPP table in the Device Tree.

Which option do you think is appropriate here?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 2/8] cpufreq: add driver for Armada XP

[Thomas Petazzoni]

Dear Viresh Kumar,

Thanks for your feedback!

On Fri, 4 Jul 2014 15:25:35 +0530, Viresh Kumar wrote:
> On 4 July 2014 15:14, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > This commit adds a simple cpufreq driver for the Armada XP SoC, which
> > has one separately controllable clock for each CPU. For this reason,
> > the existing cpufreq-cpu0 generic driver cannot be used because it
> > currently assumes that there is only one clock controlling the
> > frequency of all CPUs.
> >
> > There are on-going discussions on extending the cpufreq-cpu0 to cover
> > the case of having one clock for each CPU, but there are still some
> > unresolved issues to get this extended cpufreq-cpu0 driver merged.
> 
> Exactly, and those changes would get merged in one form or the other.
> Surely in 3.17 atleast, if not 3.16 as we are already reaching rc4..
> 
> So, it would be great if you can test on top of those changes to see if
> something isn't solved for your platform yet?
> 
> git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v3

One other problem with cpufreq-cpu0 is that it assumes the Device Tree
can contain a static OPP table, with the frequency/voltage points.
Unfortunately, in the case of the Armada XP platform, this is not
possible, because we cannot hardcode into the Device Tree the possible
CPU frequencies.

The nominal CPU frequency is selected by Sample on Reset pins (i.e pins
of the CPUs that are sampled during the reset sequence) and can
therefore change from one board to the other, and they can also be
changed via special U-Boot commands. And the frequencies supported by
cpufreq are the nominal frequency of the CPU as determined by the
sample at reset pins, and half of this frequency.

That's why the proposed armadaxp-cpufreq driver does not hardcode the
possible frequencies, but instead creates the frequency table by using
the current CPU frequency (nominal frequency) and half of it.

This doesn't work very well with the idea of having the OPP table
statically encoded in to the Device Tree. Options are:

 - Improve the cpufreq-cpu0 driver so that the OPP table can be passed
   through platform_data, and therefore built dynamically by the
   platform code and passed when registering the cpufreq
   platform_device.

 - Dynamically build/update the OPP table in the Device Tree.

Which option do you think is appropriate here?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH 2/8] cpufreq: add driver for Armada XP

[Andrew Lunn]

> This doesn't work very well with the idea of having the OPP table
> statically encoded in to the Device Tree. Options are:
> 
>  - Improve the cpufreq-cpu0 driver so that the OPP table can be passed
>    through platform_data, and therefore built dynamically by the
>    platform code and passed when registering the cpufreq
>    platform_device.
> 
>  - Dynamically build/update the OPP table in the Device Tree.
> 
> Which option do you think is appropriate here?

It should also be noted that that applies to many Marvell SoCs.
Kirkwood and Dove are the same.

	 Andrew

[PATCH 2/8] cpufreq: add driver for Armada XP

[Andrew Lunn]

> This doesn't work very well with the idea of having the OPP table
> statically encoded in to the Device Tree. Options are:
> 
>  - Improve the cpufreq-cpu0 driver so that the OPP table can be passed
>    through platform_data, and therefore built dynamically by the
>    platform code and passed when registering the cpufreq
>    platform_device.
> 
>  - Dynamically build/update the OPP table in the Device Tree.
> 
> Which option do you think is appropriate here?

It should also be noted that that applies to many Marvell SoCs.
Kirkwood and Dove are the same.

	 Andrew

Re: [PATCH 2/8] cpufreq: add driver for Armada XP

[Lucas Stach]

Am Freitag, den 04.07.2014, 13:12 +0200 schrieb Thomas Petazzoni:
[...]
> This doesn't work very well with the idea of having the OPP table
> statically encoded in to the Device Tree. Options are:
> 
>  - Improve the cpufreq-cpu0 driver so that the OPP table can be passed
>    through platform_data, and therefore built dynamically by the
>    platform code and passed when registering the cpufreq
>    platform_device.
> 
>  - Dynamically build/update the OPP table in the Device Tree.

This sounds like the right thing to do. Ideally your bootloader would do
this for you, so you don't have to encode those properties statically at
all.

Barebox already has facilities to fixup any loaded device tree. Have a
look at of_register_fixup() there.

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH 2/8] cpufreq: add driver for Armada XP

[Lucas Stach]

Am Freitag, den 04.07.2014, 13:12 +0200 schrieb Thomas Petazzoni:
[...]
> This doesn't work very well with the idea of having the OPP table
> statically encoded in to the Device Tree. Options are:
> 
>  - Improve the cpufreq-cpu0 driver so that the OPP table can be passed
>    through platform_data, and therefore built dynamically by the
>    platform code and passed when registering the cpufreq
>    platform_device.
> 
>  - Dynamically build/update the OPP table in the Device Tree.

This sounds like the right thing to do. Ideally your bootloader would do
this for you, so you don't have to encode those properties statically at
all.

Barebox already has facilities to fixup any loaded device tree. Have a
look at of_register_fixup() there.

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

Re: [PATCH 2/8] cpufreq: add driver for Armada XP

[Andrew Lunn]

On Fri, Jul 04, 2014 at 03:52:14PM +0200, Lucas Stach wrote:
> Am Freitag, den 04.07.2014, 13:12 +0200 schrieb Thomas Petazzoni:
> [...]
> > This doesn't work very well with the idea of having the OPP table
> > statically encoded in to the Device Tree. Options are:
> > 
> >  - Improve the cpufreq-cpu0 driver so that the OPP table can be passed
> >    through platform_data, and therefore built dynamically by the
> >    platform code and passed when registering the cpufreq
> >    platform_device.
> > 
> >  - Dynamically build/update the OPP table in the Device Tree.
> 
> This sounds like the right thing to do. Ideally your bootloader would do
> this for you, so you don't have to encode those properties statically at
> all.
> 
> Barebox already has facilities to fixup any loaded device tree. Have a
> look at of_register_fixup() there.

We are talking about legacy devices here, which have been in the field
for years. There is very little chance of a boot loader
upgrade. Appended DT is the norm for these devices, and modifying the
DT would have to happen in kernel.

   Andrew

[PATCH 2/8] cpufreq: add driver for Armada XP

[Andrew Lunn]

On Fri, Jul 04, 2014 at 03:52:14PM +0200, Lucas Stach wrote:
> Am Freitag, den 04.07.2014, 13:12 +0200 schrieb Thomas Petazzoni:
> [...]
> > This doesn't work very well with the idea of having the OPP table
> > statically encoded in to the Device Tree. Options are:
> > 
> >  - Improve the cpufreq-cpu0 driver so that the OPP table can be passed
> >    through platform_data, and therefore built dynamically by the
> >    platform code and passed when registering the cpufreq
> >    platform_device.
> > 
> >  - Dynamically build/update the OPP table in the Device Tree.
> 
> This sounds like the right thing to do. Ideally your bootloader would do
> this for you, so you don't have to encode those properties statically at
> all.
> 
> Barebox already has facilities to fixup any loaded device tree. Have a
> look at of_register_fixup() there.

We are talking about legacy devices here, which have been in the field
for years. There is very little chance of a boot loader
upgrade. Appended DT is the norm for these devices, and modifying the
DT would have to happen in kernel.

   Andrew

Re: [PATCH 2/8] cpufreq: add driver for Armada XP

[Viresh Kumar]

On 4 July 2014 19:45, Andrew Lunn <andrew@lunn.ch> wrote:
> We are talking about legacy devices here, which have been in the field
> for years. There is very little chance of a boot loader
> upgrade. Appended DT is the norm for these devices, and modifying the
> DT would have to happen in kernel.

FWIW, I should mention that we don't need to fix DT's at all in your case.
Just add OPPs at runtime using dev_pm_opp_add() API from within
kernel, maybe from your arch/arm/mach-* folder and cpufreq-cpu0
would be able to parse them.

--
viresh

[PATCH 2/8] cpufreq: add driver for Armada XP

[Viresh Kumar]

On 4 July 2014 19:45, Andrew Lunn <andrew@lunn.ch> wrote:
> We are talking about legacy devices here, which have been in the field
> for years. There is very little chance of a boot loader
> upgrade. Appended DT is the norm for these devices, and modifying the
> DT would have to happen in kernel.

FWIW, I should mention that we don't need to fix DT's at all in your case.
Just add OPPs at runtime using dev_pm_opp_add() API from within
kernel, maybe from your arch/arm/mach-* folder and cpufreq-cpu0
would be able to parse them.

--
viresh

Re: [PATCH 2/8] cpufreq: add driver for Armada XP

[Thomas Petazzoni]

Dear Viresh Kumar,

On Fri, 4 Jul 2014 15:25:35 +0530, Viresh Kumar wrote:
> On 4 July 2014 15:14, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > This commit adds a simple cpufreq driver for the Armada XP SoC, which
> > has one separately controllable clock for each CPU. For this reason,
> > the existing cpufreq-cpu0 generic driver cannot be used because it
> > currently assumes that there is only one clock controlling the
> > frequency of all CPUs.
> >
> > There are on-going discussions on extending the cpufreq-cpu0 to cover
> > the case of having one clock for each CPU, but there are still some
> > unresolved issues to get this extended cpufreq-cpu0 driver merged.
> 
> Exactly, and those changes would get merged in one form or the other.
> Surely in 3.17 atleast, if not 3.16 as we are already reaching rc4..
> 
> So, it would be great if you can test on top of those changes to see if
> something isn't solved for your platform yet?
> 
> git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v3

Are these changes in linux-next ? The mvebu maintainer Jason Cooper has
pulled the cpufreq support for Armada XP, so it will appear in
linux-next tomorrow. It would be good of the cpufreq-generic driver
improvements (to support one clock per CPU) were also part of
linux-next so that we could test that the combination works as expected
(of course, I did test locally, but I'd like to ensure it still works
in linux-next).

Could you get your tree in linux-next, or get your patches merged by
Rafael in his linux-next branch so that they will appear in linux-next ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 2/8] cpufreq: add driver for Armada XP

[Thomas Petazzoni]

Dear Viresh Kumar,

On Fri, 4 Jul 2014 15:25:35 +0530, Viresh Kumar wrote:
> On 4 July 2014 15:14, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > This commit adds a simple cpufreq driver for the Armada XP SoC, which
> > has one separately controllable clock for each CPU. For this reason,
> > the existing cpufreq-cpu0 generic driver cannot be used because it
> > currently assumes that there is only one clock controlling the
> > frequency of all CPUs.
> >
> > There are on-going discussions on extending the cpufreq-cpu0 to cover
> > the case of having one clock for each CPU, but there are still some
> > unresolved issues to get this extended cpufreq-cpu0 driver merged.
> 
> Exactly, and those changes would get merged in one form or the other.
> Surely in 3.17 atleast, if not 3.16 as we are already reaching rc4..
> 
> So, it would be great if you can test on top of those changes to see if
> something isn't solved for your platform yet?
> 
> git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v3

Are these changes in linux-next ? The mvebu maintainer Jason Cooper has
pulled the cpufreq support for Armada XP, so it will appear in
linux-next tomorrow. It would be good of the cpufreq-generic driver
improvements (to support one clock per CPU) were also part of
linux-next so that we could test that the combination works as expected
(of course, I did test locally, but I'd like to ensure it still works
in linux-next).

Could you get your tree in linux-next, or get your patches merged by
Rafael in his linux-next branch so that they will appear in linux-next ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH 2/8] cpufreq: add driver for Armada XP

[Viresh Kumar]

On 16 July 2014 19:32, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Could you get your tree in linux-next, or get your patches merged by
> Rafael in his linux-next branch so that they will appear in linux-next ?

They aren't in yet and Rafael haven't started pushing stuff for 3.16 yet.
But it might be pushed sometime soon, no deadlines decided yet.

[PATCH 2/8] cpufreq: add driver for Armada XP

[Viresh Kumar]

On 16 July 2014 19:32, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Could you get your tree in linux-next, or get your patches merged by
> Rafael in his linux-next branch so that they will appear in linux-next ?

They aren't in yet and Rafael haven't started pushing stuff for 3.16 yet.
But it might be pushed sometime soon, no deadlines decided yet.

Re: [PATCH 2/8] cpufreq: add driver for Armada XP

[Thomas Petazzoni]

Dear Viresh Kumar,

On Wed, 16 Jul 2014 20:55:21 +0530, Viresh Kumar wrote:
> On 16 July 2014 19:32, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > Could you get your tree in linux-next, or get your patches merged by
> > Rafael in his linux-next branch so that they will appear in linux-next ?
> 
> They aren't in yet and Rafael haven't started pushing stuff for 3.16 yet.

I guess you meant 3.17, right?

> But it might be pushed sometime soon, no deadlines decided yet.

Would be good to have this soon, since the 3.17 merge window is
approaching. You asked me to use this cpufreq-generic driver instead of
a custom cpufreq driver, and I did the work to do that. So now I clearly
hope that cpufreq-generic will be merged in 3.17.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 2/8] cpufreq: add driver for Armada XP

[Thomas Petazzoni]

Dear Viresh Kumar,

On Wed, 16 Jul 2014 20:55:21 +0530, Viresh Kumar wrote:
> On 16 July 2014 19:32, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > Could you get your tree in linux-next, or get your patches merged by
> > Rafael in his linux-next branch so that they will appear in linux-next ?
> 
> They aren't in yet and Rafael haven't started pushing stuff for 3.16 yet.

I guess you meant 3.17, right?

> But it might be pushed sometime soon, no deadlines decided yet.

Would be good to have this soon, since the 3.17 merge window is
approaching. You asked me to use this cpufreq-generic driver instead of
a custom cpufreq driver, and I did the work to do that. So now I clearly
hope that cpufreq-generic will be merged in 3.17.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH 2/8] cpufreq: add driver for Armada XP

[Viresh Kumar]

On 16 July 2014 20:58, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> I guess you meant 3.17, right?

Yeah, sorry.

> Would be good to have this soon, since the 3.17 merge window is
> approaching. You asked me to use this cpufreq-generic driver instead of
> a custom cpufreq driver, and I did the work to do that. So now I clearly
> hope that cpufreq-generic will be merged in 3.17.

Yeah, I have already pinged Rafael few days back on this. He came back
from holidays last week and this is what he told me:

Jul 11 19:58:34 <vireshk> rafael, when are you going to pick stuff for 3.17?
Jul 11 19:59:11 <rafael> vireshk: next week i suppose


Do you depend on this patch btw?

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg675398.html

Actually there had been some objections to comparing clocks this way and
we *might* hold this off, unless the bindings are finalized. Will get all other
patches merged though.

[PATCH 2/8] cpufreq: add driver for Armada XP

[Viresh Kumar]

On 16 July 2014 20:58, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> I guess you meant 3.17, right?

Yeah, sorry.

> Would be good to have this soon, since the 3.17 merge window is
> approaching. You asked me to use this cpufreq-generic driver instead of
> a custom cpufreq driver, and I did the work to do that. So now I clearly
> hope that cpufreq-generic will be merged in 3.17.

Yeah, I have already pinged Rafael few days back on this. He came back
from holidays last week and this is what he told me:

Jul 11 19:58:34 <vireshk> rafael, when are you going to pick stuff for 3.17?
Jul 11 19:59:11 <rafael> vireshk: next week i suppose


Do you depend on this patch btw?

https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg675398.html

Actually there had been some objections to comparing clocks this way and
we *might* hold this off, unless the bindings are finalized. Will get all other
patches merged though.

Re: [PATCH 2/8] cpufreq: add driver for Armada XP

[Thomas Petazzoni]

Dear Viresh Kumar,

On Wed, 16 Jul 2014 21:02:29 +0530, Viresh Kumar wrote:

> > Would be good to have this soon, since the 3.17 merge window is
> > approaching. You asked me to use this cpufreq-generic driver instead of
> > a custom cpufreq driver, and I did the work to do that. So now I clearly
> > hope that cpufreq-generic will be merged in 3.17.
> 
> Yeah, I have already pinged Rafael few days back on this. He came back
> from holidays last week and this is what he told me:
> 
> Jul 11 19:58:34 <vireshk> rafael, when are you going to pick stuff for 3.17?
> Jul 11 19:59:11 <rafael> vireshk: next week i suppose

Ok.

> Do you depend on this patch btw?
> 
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg675398.html
> 
> Actually there had been some objections to comparing clocks this way and
> we *might* hold this off, unless the bindings are finalized. Will get all other
> patches merged though.

I'm not sure to fully understand what this patch is doing, but I
believe I depend on it. My system has one clock for each CPU, and
therefore each CPU has a separately controllable frequency. See
http://git.infradead.org/linux-mvebu.git/blob/3843607838cc5436d02a6771e661969a54c2fee0:/arch/arm/boot/dts/armada-xp-mv78460.dtsi#l30
for the Device Tree part describing the CPUs. So the existing
cpufreq-cpu0 (as of 3.16) doesn't work because it assumes there is one
single clock controlling the frequency.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 2/8] cpufreq: add driver for Armada XP

[Thomas Petazzoni]

Dear Viresh Kumar,

On Wed, 16 Jul 2014 21:02:29 +0530, Viresh Kumar wrote:

> > Would be good to have this soon, since the 3.17 merge window is
> > approaching. You asked me to use this cpufreq-generic driver instead of
> > a custom cpufreq driver, and I did the work to do that. So now I clearly
> > hope that cpufreq-generic will be merged in 3.17.
> 
> Yeah, I have already pinged Rafael few days back on this. He came back
> from holidays last week and this is what he told me:
> 
> Jul 11 19:58:34 <vireshk> rafael, when are you going to pick stuff for 3.17?
> Jul 11 19:59:11 <rafael> vireshk: next week i suppose

Ok.

> Do you depend on this patch btw?
> 
> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg675398.html
> 
> Actually there had been some objections to comparing clocks this way and
> we *might* hold this off, unless the bindings are finalized. Will get all other
> patches merged though.

I'm not sure to fully understand what this patch is doing, but I
believe I depend on it. My system has one clock for each CPU, and
therefore each CPU has a separately controllable frequency. See
http://git.infradead.org/linux-mvebu.git/blob/3843607838cc5436d02a6771e661969a54c2fee0:/arch/arm/boot/dts/armada-xp-mv78460.dtsi#l30
for the Device Tree part describing the CPUs. So the existing
cpufreq-cpu0 (as of 3.16) doesn't work because it assumes there is one
single clock controlling the frequency.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH 2/8] cpufreq: add driver for Armada XP

[Viresh Kumar]

On 16 July 2014 21:17, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> I'm not sure to fully understand what this patch is doing, but I
> believe I depend on it.

Yes, you do. I have cc'd you to the other thread where this was in discussion.

--
viresh

[PATCH 2/8] cpufreq: add driver for Armada XP

[Viresh Kumar]

On 16 July 2014 21:17, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> I'm not sure to fully understand what this patch is doing, but I
> believe I depend on it.

Yes, you do. I have cc'd you to the other thread where this was in discussion.

--
viresh