clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
PATCH 1/1 clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
Some Cortex A9 CPU:s (e.g. zynq) have the tick tied to the CPU frequency. On those CPU:s we cannot use the global-timer as a reliable clocksource with CPU frequency scaling enabled since this is not currently taken into account by the driver.
Add a "tied-to-cpu-freq" boolean to the global-timer dt node indicate this condition.
When the global-timer register function sees this property return immediately and don't register the clocksource.
--- Documentation/devicetree/bindings/arm/global_timer.txt | 4 ++++ drivers/clocksource/arm_global_timer.c | 7 +++++++ 2 files changed, 11 insertions(+)
Documentation/devicetree/bindings/arm/global_timer.txt +4 -0
@@ -17,6 +17,10 @@ - clocks : Should be phandle to a clock. +** Timer node optional properties: + +- tied-to-cpu-freq : indicates that the timer scales with the CPU frequency. + Example: timer at 2c000600 {
drivers/clocksource/arm_global_timer.c +7 -0
@@ -268,6 +268,13 @@ static void __init global_timer_of_register(struct device_node *np)return ; } +#ifdef CONFIG_CPU_FREQ +if (of_property_read_bool (np,"tied-to-cpu-freq" )) { +pr_warn ("global-timer: tied to cpu frequency, not supported with scaling\n" ); +return ; + } +#endif + gt_clk =of_clk_get (np,0 );if (!IS_ERR (gt_clk)) { err =clk_prepare_enable (gt_clk);
Signature · 1 line
2.3.3
PATCH 1/1 clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
Quoted 4 lines · Ola Jeppsson
Some Cortex A9 CPU:s (e.g. zynq) have the tick tied to the CPU frequency. On those CPU:s we cannot use the global-timer as a reliable clocksource with CPU frequency scaling enabled since this is not currently taken into account by the driver.
The global timer is _always_ tied to the CPU frequency -- it's fed by PERIPHCLK, which must have a period which is a multiple of CLK.
Quoted 2 lines
Add a "tied-to-cpu-freq" boolean to the global-timer dt node indicate this condition.
Is this indicating the truism above, or that the kernel is performing frequency scaling? The latter is an OS property rather than a HW property, and thus doesn't belong in the DT.
The SMP TWD driver tries to account for frequency scaling. Assuming that works, the same should be possible here. Otherwise, the global timer is simply unusable with any frequency scaling.
In either case the property seems pointless; all you care about is whether the platform actually performs CPU frequency scaling.
Mark.
Quoted 51 lines
When the global-timer register function sees this property return immediately and don't register the clocksource.
Signed-off-by Ola Jeppsson <[email protected]>--- Documentation/devicetree/bindings/arm/global_timer.txt | 4 ++++ drivers/clocksource/arm_global_timer.c | 7 +++++++ 2 files changed, 11 insertions(+)Documentation/devicetree/bindings/arm/global_timer.txt +4
-0@@ -17,6 +17,10 @@ - clocks : Should be phandle to a clock. +** Timer node optional properties: + +- tied-to-cpu-freq : indicates that the timer scales with the CPU frequency. + Example: timer at 2c000600 {drivers/clocksource/arm_global_timer.c +7
-0@@ -268,6 +268,13 @@ static void __init global_timer_of_register(struct device_node *np)return ; } +#ifdef CONFIG_CPU_FREQ +if (of_property_read_bool (np,"tied-to-cpu-freq" )) { +pr_warn ("global-timer: tied to cpu frequency, not supported with scaling\n" ); +return ; + } +#endif + gt_clk =of_clk_get (np,0 );if (!IS_ERR (gt_clk)) { err =clk_prepare_enable (gt_clk);Signature · 6 lines
2.3.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 1/1 clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
In reply to Ola Jeppsson+Adding Pete and Maxime
Hi Ola,
Thankyou for sending the patch,
I like the Idea, but I have some specific concerns which would break existing SOCs.
Quoted 37 lines · Ola Jeppsson
Some Cortex A9 CPU:s (e.g. zynq) have the tick tied to the CPU frequency. On those CPU:s we cannot use the global-timer as a reliable clocksource with CPU frequency scaling enabled since this is not currently taken into account by the driver.
Add a "tied-to-cpu-freq" boolean to the global-timer dt node indicate this condition.
When the global-timer register function sees this property return immediately and don't register the clocksource.
Signed-off-by Ola Jeppsson <[email protected]>--- Documentation/devicetree/bindings/arm/global_timer.txt | 4 ++++ drivers/clocksource/arm_global_timer.c | 7 +++++++ 2 files changed, 11 insertions(+)Documentation/devicetree/bindings/arm/global_timer.txt +4
-0@@ -17,6 +17,10 @@ - clocks : Should be phandle to a clock. +** Timer node optional properties: + +- tied-to-cpu-freq : indicates that the timer scales with the CPU frequency. + Example: timer at 2c000600 {drivers/clocksource/arm_global_timer.c +0
-0
drivers/clocksource/arm_global_timer.c static void __init global_timer_of_register(struct device_node *np) · line 277
Quoted 10 lines
drivers/clocksource/arm_global_timer.c +7
-0@@ -268,6 +268,13 @@ static void __init global_timer_of_register(struct device_node *np)return ; } +#ifdef CONFIG_CPU_FREQ +if (of_property_read_bool (np,"tied-to-cpu-freq" )) { +pr_warn ("global-timer: tied to cpu frequency, not supported with scaling\n" ); +return ; + } +#endif +
This patch would not let the SOC like STiH415/416 or zynq with "tied-to-cpu-freq" property to boot with multi_v7_defconfig. Which is not correct thing to do, as STi SOC's do not use cpufreq driver however the tick is tied to this clocksource.
--srini
Quoted 4 lines
drivers/clocksource/arm_global_timer.c +0
-0gt_clk =of_clk_get (np,0 );if (!IS_ERR (gt_clk)) { err =clk_prepare_enable (gt_clk);
PATCH 1/1 clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
Hi Srini, Ola,
Quoted 7 lines · Srinivas Kandagatla
+Adding Pete and Maxime
Hi Ola,
Thankyou for sending the patch,I like the Idea, but I have some specific concerns which would break existing SOCs.
I like the idea too.
Quoted 47 lines · Ola Jeppsson
Quoted 44 lines
Some Cortex A9 CPU:s (e.g. zynq) have the tick tied to the CPU frequency. On those CPU:s we cannot use the global-timer as a reliable clocksource with CPU frequency scaling enabled since this is not currently taken into account by the driver.
Add a "tied-to-cpu-freq" boolean to the global-timer dt node indicate this condition.
When the global-timer register function sees this property return immediately and don't register the clocksource.
Signed-off-by Ola Jeppsson <[email protected]>--- Documentation/devicetree/bindings/arm/global_timer.txt | 4 ++++ drivers/clocksource/arm_global_timer.c | 7 +++++++ 2 files changed, 11 insertions(+)Documentation/devicetree/bindings/arm/global_timer.txt +3
-0@@ -17,6 +17,10 @@ - clocks : Should be phandle to a clock. +** Timer node optional properties: + +- tied-to-cpu-freq : indicates that the timer scales with the CPUfrequency.
Documentation/devicetree/bindings/arm/global_timer.txt +1
-0+ Example: timer at 2c000600 {drivers/clocksource/arm_global_timer.c +0
-0@@ -268,6 +268,13 @@ static void __init global_timer_of_register(struct device_node *np) return; }
Quoted 13 lines
drivers/clocksource/arm_global_timer.c static void __init global_timer_of_register(struct device_node *np) · line 277
Quoted 8 lines
drivers/clocksource/arm_global_timer.c +7
-0+#ifdef CONFIG_CPU_FREQ + if (of_property_read_bool(np, "tied-to-cpu-freq")) { + pr_warn("global-timer: tied to cpu frequency, not supported with scaling\n"); + return; + } +#endif +This patch would not let the SOC like STiH415/416 or zynq with "tied-to-cpu-freq" property to boot with
multi_v7_defconfig. Which is not correct thing to do, as STi SOC's do not use cpufreq driver however the tick is tied to this clocksource.
Yes, you are right, but I don't see any cleaner way to do this.
On STi, we have another timer we can use as a clocksource when doing CPU Freq, the ST LPC timer.
It is not upstreamed yet, but we will try to have it for next release.
I propose we set the "tied-to-cpu-freq" in GT node of STi family as soon as we enable the LPC timer one.
Doing that, the STi boot won't break in multi_v7 config.
Kind regards,
Maxime
Quoted 9 lines
--srini
Quoted 4 lines
drivers/clocksource/arm_global_timer.c +0
-0gt_clk =of_clk_get (np,0 );if (!IS_ERR(gt_clk)) { err = clk_prepare_enable(gt_clk);
PATCH 1/1 clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
Hi Srini, Ola, Maxime,
Quoted 2 lines · Maxime Coquelin
Quoted 1 line · Srinivas Kandagatla
+Adding Pete and Maxime
Thanks Srini, as I wouldn't have seen this otherwise.
<snip>
Quoted 11 lines
Quoted 6 lines
Quoted 1 line
+
This patch would not let the SOC like STiH415/416 or zynq with "tied-to-cpu-freq" property to boot with
multi_v7_defconfig. Which is not correct thing to do, as STi SOC's do not use cpufreq driver however the tick is tied to this clocksource.Yes, you are right, but I don't see any cleaner way to do this.
On STi, we have another timer we can use as a clocksource when doing CPU Freq, the ST LPC timer.
It is not upstreamed yet, but we will try to have it for next release.
I just sent a series to add the ST LPC timer to LKML, see here
https://lkml.org/lkml/2015/4/17/181. I've tested this on stih410 and it works ok.
Quoted 3 lines
I propose we set the "tied-to-cpu-freq" in GT node of STi family as soon as we enable the LPC timer one.
Doing that, the STi boot won't break inmulti_v7config.
However this lpc timer IP does not exist on stih415/6 SoCs, and I can't (so far at least) see any other timer which we could use. So basically we would still have a breakage on stih415/6 STi platforms with this proposed change.
Upstreaming st_lpc.c timer is still worthwhile though as it paves the way for adding cpufreq support upstream for stih407 family.
regards,
Peter.
PATCH 1/1 clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
In reply to Srinivas KandagatlaQuoted 49 lines · Srinivas Kandagatla
+Adding Pete and Maxime
Hi Ola,
Thankyou for sending the patch,I like the Idea, but I have some specific concerns which would break existing SOCs.
Quoted 40 lines · Ola Jeppsson
Some Cortex A9 CPU:s (e.g. zynq) have the tick tied to the CPU frequency. On those CPU:s we cannot use the global-timer as a reliable clocksource with CPU frequency scaling enabled since this is not currently taken into account by the driver.
Add a "tied-to-cpu-freq" boolean to the global-timer dt node indicate this condition.
When the global-timer register function sees this property return immediately and don't register the clocksource.
Signed-off-by Ola Jeppsson <[email protected]>--- Documentation/devicetree/bindings/arm/global_timer.txt | 4 ++++ drivers/clocksource/arm_global_timer.c | 7 +++++++ 2 files changed, 11 insertions(+)Documentation/devicetree/bindings/arm/global_timer.txt +4
-0@@ -17,6 +17,10 @@ - clocks : Should be phandle to a clock. +** Timer node optional properties: + +- tied-to-cpu-freq : indicates that the timer scales with the CPU frequency. + Example: timer at 2c000600 {drivers/clocksource/arm_global_timer.c +0
-0@@ -268,6 +268,13 @@ static void __init global_timer_of_register(struct device_node *np)return ; }
Quoted 12 lines
drivers/clocksource/arm_global_timer.c static void __init global_timer_of_register(struct device_node *np) · line 277
Quoted 7 lines
drivers/clocksource/arm_global_timer.c +7
-0+#ifdef CONFIG_CPU_FREQ +if (of_property_read_bool (np,"tied-to-cpu-freq" )) { +pr_warn ("global-timer: tied to cpu frequency, not supported with scaling\n" ); +return ; + } +#endif +This patch would not let the SOC like STiH415/416 or zynq with "tied-to-cpu-freq" property to boot with
multi_v7_defconfig. Which is not correct thing to do, as STi SOC's do not use cpufreq driver however the tick is tied to this clocksource.
For Zynq, it should be OK, since we have the cadence_ttc as alternative clocksource. Though, I have to admit not having tested this patch.
S?ren