From: Mark Langsdorf <hidden> Date: 2012-12-05 16:48:26
This patch series adds cpufreq support for the Calxeda
ECX-1000 (highbank) SoCs. The EnergyCore Management Engine (ECME) on
the ECX-1000 manages the voltage for the part and communications with
Linux through a pl320 mailbox. clk notifications are used to control
when to send messages to the ECME.
--Mark Langsdorf
Calxeda, Inc.
From: Mark Langsdorf <hidden> Date: 2012-12-05 16:48:27
From: Rob Herring <redacted>
Signed-off-by: Rob Herring <redacted>
Signed-off-by: Mark Langsdorf <redacted>
---
Changes from v4, v5, v6, v7
None.
Changes from v3
No longer setting *clk to NULL in twd_get_clock().
Changes from v2
Turned the check for the node pointer into an if-then-else statement.
Removed the second, redundant clk_get_rate.
Changes from v1
None.
arch/arm/kernel/smp_twd.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
From: Mark Langsdorf <hidden> Date: 2012-12-05 16:48:28
The highbank clock will glitch with the current code if the
clock rate is reset without relocking the PLL. Program the PLL
correctly to prevent glitches.
Signed-off-by: Mark Langsdorf <redacted>
Signed-off-by: Rob Herring <redacted>
Cc: mturquette at linaro.org
---
Changes from v6, v7
None.
Changes from v5
Added Mike Turquette's ack.
Changes from v4
None.
Changes from v3
Changelog text and patch name now correspond to the actual patch.
was clk, highbank: remove non-bypass reset mode.
Changes from v2
None.
Changes from v1
Removed erroneous reformating.
drivers/clk/clk-highbank.c | 2 ++
1 file changed, 2 insertions(+)
From: Mark Langsdorf <hidden> Date: 2012-12-05 16:48:53
Highbank processors depend on the external ECME to perform voltage
management based on a requested frequency. Communication between the
A9 cores and the ECME happens over the pl320 IPC channel.
Signed-off-by: Mark Langsdorf <redacted>
Cc: shawn.guo at linaro.org
Cc: mturquette at linaro.org
---
Changes from v7
Removed old attribution to cpufreq-cpu0.
Added some description in the documentation.
Made cpu_dev, cpu_clk into local variables.
Removed __devinit.
Removed some unneeded includes.
Added a brace to clarify some nested if logic.
Changes from v6
Removed devicetree bindings documentation.
Restructured driver to use clk notifications.
Core driver logic is now cpufreq-clk0.
Changes from v5
Changed ipc_transmit() to pl320_ipc_transmit().
Changes from v4
Removed erroneous changes to arch/arm/Kconfig.
Removed unnecessary changes to drivers/cpufreq/Kconfig.arm
Alphabetized additions to arch/arm/mach-highbank/Kconfig
Changed ipc call and header to match new ipc location in
drivers/mailbox.
Changes from v3
None.
Changes from v2
Changed transition latency binding in code to match documentation.
Changes from v1
Added highbank specific Kconfig changes.
arch/arm/boot/dts/highbank.dts | 10 ++++
arch/arm/mach-highbank/Kconfig | 2 +
drivers/cpufreq/Kconfig.arm | 16 ++++++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/highbank-cpufreq.c | 102 +++++++++++++++++++++++++++++++++++++
5 files changed, 131 insertions(+)
create mode 100644 drivers/cpufreq/highbank-cpufreq.c
From: Mark Langsdorf <hidden> Date: 2012-12-05 16:49:12
These functions are needed to make the cpufreq-core0 and highbank-cpufreq
drivers loadable as modules.
Signed-off-by: Mark Langsdorf <redacted>
Acked-by: Nishanth Menon <nm@ti.com>
---
Changes from v4, v5, v6, v7
None.
Changes from v3
includes linux/export.h instead of module.h.
Changes from v2
None.
Changes from v1
Added Nishanth Menon's ack.
Clarified the purpose of the change in the commit message.
drivers/base/power/opp.c | 4 ++++
1 file changed, 4 insertions(+)
From: Mark Langsdorf <hidden> Date: 2012-12-05 16:49:37
From: Rob Herring <redacted>
The pl320 IPC allows for interprocessor communication between the highbank A9
and the EnergyCore Management Engine. The pl320 implements a straightforward
mailbox protocol.
This patch depends on Omar Ramirez Luna's [off-list ref]
mailbox driver patch series.
Signed-off-by: Mark Langsdorf <redacted>
Signed-off-by: Rob Herring <redacted>
Cc: Omar Ramirez Luna <redacted>
Cc: Arnd Bergmann <arnd@arndb.de>
---
Changes from v6, v7
None.
Changes from v5
Renamed ipc_transmit() to pl320_ipc_transmit().
Properly exported pl320_ipc_{un}register_notifier().
Changes from v4
Moved pl320-ipc.c from arch/arm/mach-highbank to drivers/mailbox.
Moved header information to include/linux/mailbox.h.
Added Kconfig options to reflect the new code location.
Change drivers/mailbox/Makefile to build the omap mailboxes only
when they are configured.
Removed ipc_call_fast and renamed ipc_call_slow ipc_transmit.
Changes from v3, v2
None.
Changes from v1
Removed erroneous changes for cpufreq Kconfig.
arch/arm/mach-highbank/Kconfig | 2 +
drivers/mailbox/Kconfig | 9 ++
drivers/mailbox/Makefile | 4 +
drivers/mailbox/pl320-ipc.c | 199 +++++++++++++++++++++++++++++++++++++++++
include/linux/mailbox.h | 19 +++-
5 files changed, 232 insertions(+), 1 deletion(-)
create mode 100644 drivers/mailbox/Makefile
create mode 100644 drivers/mailbox/pl320-ipc.c
From: Mark Langsdorf <hidden> Date: 2012-12-05 16:49:52
This patch is withdrawn due to a need for severe rework.
Changes from v4
Withdrawn.
Changes from v3, v2
None.
Changes from v1
Implemented a simple round-up algorithm instead of the over/under
method that could cause errors on Intel processors with boost mode.
From: Mike Turquette <hidden> Date: 2012-12-05 18:25:06
On Wed, Dec 5, 2012 at 8:48 AM, Mark Langsdorf
[off-list ref] wrote:
The highbank clock will glitch with the current code if the
clock rate is reset without relocking the PLL. Program the PLL
correctly to prevent glitches.
Signed-off-by: Mark Langsdorf <redacted>
Signed-off-by: Rob Herring <redacted>
Cc: mturquette at linaro.org
---
Changes from v6, v7
None.
Changes from v5
Added Mike Turquette's ack.
It appears that my Ack has not been added to this version of the patch.
Regards,
Mike
quoted hunk
Changes from v4
None.
Changes from v3
Changelog text and patch name now correspond to the actual patch.
was clk, highbank: remove non-bypass reset mode.
Changes from v2
None.
Changes from v1
Removed erroneous reformating.
drivers/clk/clk-highbank.c | 2 ++
1 file changed, 2 insertions(+)
Looks pretty good to me. Some tedious nitpicks and discussion below.
<snip>
+static int hb_voltage_change(unsigned int freq)
+{
+ int i;
+ u32 msg[7];
+
+ msg[0] = HB_CPUFREQ_CHANGE_NOTE;
+ msg[1] = freq / 1000000;
+ for (i = 2; i < 7; i++)
+ msg[i] = 0;
+
+ return pl320_ipc_transmit(msg);
+}
+
+static int hb_cpufreq_clk_notify(struct notifier_block *nb,
+ unsigned long action, void *hclk)
+{
+ struct clk_notifier_data *clk_data = hclk;
+ int i = 0;
+
+ if (action == PRE_RATE_CHANGE) {
+ if (clk_data->new_rate > clk_data->old_rate)
+ while (hb_voltage_change(clk_data->new_rate))
+ if (i++ > 15)
There are a few magic numbers here. How about something like:
#define HB_VOLT_CHANGE_MAX_TRIES 15
Maybe do the same for the i2c message length?
+ return NOTIFY_STOP;
How about NOTIFY_BAD? It more clearly signals that an error has occurred.
You could also return notifier_from_errno(-ETIMEDOUT) here if you
prefer but that would only be for the sake of readability.
clk_set_rate doesn't actually return the notifier error code in the
event of a notifier abort.
+ } else if (action == POST_RATE_CHANGE) {
+ if (clk_data->new_rate < clk_data->old_rate)
+ while (hb_voltage_change(clk_data->new_rate))
+ if (i++ > 15)
+ break;
Same as above. It is true that the clock framework does nothing with
post-rate change notifier aborts but that might change in the future.
Do you have any plans to convert your voltage change routine over to
the regulator framework? Likewise do you plan to use the OPP library
in the future? I can understand if you do not do that since your
regulator/dvfs programming model makes things very simple for you.
The reason I bring this up is that I did float a patch a while back
for a generalized dvfs notifier handler. The prereqs for using it are
1) ccf, 2) regulator fwk, 3) opp definitions. Here is the patch:
https://github.com/mturquette/linux/commit/05a280bbc0819a6858d73088a632666f0c7f68a4
And an example usage in the OMAP CPUfreq driver:
https://github.com/mturquette/linux/commit/958f10bb98a293aa912e7eb9cd6edbdc51c1c04a
I understand if this approach incurs too much software overhead for
you but I wanted to throw it out there. It might working nicely in
the cpufreq-cpu0 driver or some other "generic" CPUfreq driver for
implementing DVFS.
Regards,
Mike
Do you have any plans to convert your voltage change routine over to
the regulator framework? Likewise do you plan to use the OPP library
in the future? I can understand if you do not do that since your
regulator/dvfs programming model makes things very simple for you.
I looked at treating the ECME as a voltage regulator, but it was a very
bad fit. The ECME has a certain amount of intelligence built into it and
corporate plans are to treat voltage control as a black box.
The current solution is actually nicely generic from my perspective. The
clk notifiers guarantee we can make the voltage changes at the right
time regardless of the underlying cpufreq driver implementation. I don't
think we need more until we get into cpufreq QoS issues, and even then
I'd want to stick with something like the current structure.
--Mark Langsdorf
Calxeda, Inc.
On Wed, Dec 05, 2012 at 10:48:41AM -0600, Mark Langsdorf wrote:
Highbank processors depend on the external ECME to perform voltage
management based on a requested frequency. Communication between the
A9 cores and the ECME happens over the pl320 IPC channel.
Signed-off-by: Mark Langsdorf <redacted>
Cc: shawn.guo at linaro.org
From: Rafael J. Wysocki <hidden> Date: 2012-12-27 13:07:36
On Wednesday, December 05, 2012 10:48:35 AM Mark Langsdorf wrote:
This patch series adds cpufreq support for the Calxeda
ECX-1000 (highbank) SoCs. The EnergyCore Management Engine (ECME) on
the ECX-1000 manages the voltage for the part and communications with
Linux through a pl320 mailbox. clk notifications are used to control
when to send messages to the ECME.
If you want me to handle this, can you please resend the whole patchset (with
all of the comments addressed, if possible)?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
From: Mark Langsdorf <hidden> Date: 2012-12-27 13:41:36
I thought I had addressed all the issues with the v9 version. The only comments I got on it was Mike's reviewed-by and I didn't think that warranted a resend.
If you do want me to send it again, do you want it updated to current top-of-tree? That may take a bit, since there's an unrelated bug that's preventing my test box from booting.
--Mark Langsdorf
Calxeda, Inc.
________________________________________
From: Rafael J. Wysocki [rjw at sisk.pl]
Sent: Thursday, December 27, 2012 7:12 AM
To: Mark Langsdorf
Cc: linux-kernel at vger.kernel.org; cpufreq at vger.kernel.org; linux-pm at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH 0/6 v8] cpufreq: add support for Calxeda ECX-1000 (highbank)
On Wednesday, December 05, 2012 10:48:35 AM Mark Langsdorf wrote:
This patch series adds cpufreq support for the Calxeda
ECX-1000 (highbank) SoCs. The EnergyCore Management Engine (ECME) on
the ECX-1000 manages the voltage for the part and communications with
Linux through a pl320 mailbox. clk notifications are used to control
when to send messages to the ECME.
If you want me to handle this, can you please resend the whole patchset (with
all of the comments addressed, if possible)?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
From: Rafael J. Wysocki <hidden> Date: 2012-12-27 14:38:19
On Thursday, December 27, 2012 08:28:22 AM Mark Langsdorf wrote:
I thought I had addressed all the issues with the v9 version. The only
comments I got on it was Mike's reviewed-by and I didn't think that
warranted a resend.
If you do want me to send it again, do you want it updated to current
top-of-tree?
Yes, please.
That may take a bit, since there's an unrelated bug that's preventing my
test box from booting.
Sure.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.