* Re: [PATCH] clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
@ 2015-04-14 7:41 ` Srinivas Kandagatla
0 siblings, 0 replies; 12+ messages in thread
From: Srinivas Kandagatla @ 2015-04-14 7:41 UTC (permalink / raw)
To: Ola Jeppsson, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann,
Srinivas Kandagatla, Michal Simek, Stuart Menefy, Olof Johansson,
Sören Brinkmann, Peter Griffin, Maxime Coquelin
+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.
On 13/04/15 18:37, Ola Jeppsson wrote:
> 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 <ola-hhg9azYwhpdWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/global_timer.txt | 4 ++++
> drivers/clocksource/arm_global_timer.c | 7 +++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt b/Documentation/devicetree/bindings/arm/global_timer.txt
> index bdae3a818793..465e02c17b5b 100644
> --- a/Documentation/devicetree/bindings/arm/global_timer.txt
> +++ b/Documentation/devicetree/bindings/arm/global_timer.txt
> @@ -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@2c000600 {
> diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c
> index e6833771a716..8913ebda3f09 100644
> --- a/drivers/clocksource/arm_global_timer.c
> +++ b/drivers/clocksource/arm_global_timer.c
> @@ -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
> gt_clk = of_clk_get(np, 0);
> if (!IS_ERR(gt_clk)) {
> err = clk_prepare_enable(gt_clk);
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH] clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
@ 2015-04-14 8:06 ` Maxime Coquelin
0 siblings, 0 replies; 12+ messages in thread
From: Maxime Coquelin @ 2015-04-14 8:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi Srini, Ola,
On 04/14/2015 09:41 AM, Srinivas Kandagatla wrote:
> +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.
>
>
> On 13/04/15 18:37, Ola Jeppsson wrote:
>> 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 <ola@adapteva.com>
>> ---
>> Documentation/devicetree/bindings/arm/global_timer.txt | 4 ++++
>> drivers/clocksource/arm_global_timer.c | 7 +++++++
>> 2 files changed, 11 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt
>> b/Documentation/devicetree/bindings/arm/global_timer.txt
>> index bdae3a818793..465e02c17b5b 100644
>> --- a/Documentation/devicetree/bindings/arm/global_timer.txt
>> +++ b/Documentation/devicetree/bindings/arm/global_timer.txt
>> @@ -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 {
>> diff --git a/drivers/clocksource/arm_global_timer.c
>> b/drivers/clocksource/arm_global_timer.c
>> index e6833771a716..8913ebda3f09 100644
>> --- a/drivers/clocksource/arm_global_timer.c
>> +++ b/drivers/clocksource/arm_global_timer.c
>> @@ -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.
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
>
>
>
> --srini
>
>> gt_clk = of_clk_get(np, 0);
>> if (!IS_ERR(gt_clk)) {
>> err = clk_prepare_enable(gt_clk);
>>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
@ 2015-04-14 8:06 ` Maxime Coquelin
0 siblings, 0 replies; 12+ messages in thread
From: Maxime Coquelin @ 2015-04-14 8:06 UTC (permalink / raw)
To: Srinivas Kandagatla, Ola Jeppsson,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann,
Srinivas Kandagatla, Michal Simek, Stuart Menefy, Olof Johansson,
Sören Brinkmann, Peter Griffin
Hi Srini, Ola,
On 04/14/2015 09:41 AM, Srinivas Kandagatla wrote:
> +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.
>
>
> On 13/04/15 18:37, Ola Jeppsson wrote:
>> 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 <ola-hhg9azYwhpdWk0Htik3J/w@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/arm/global_timer.txt | 4 ++++
>> drivers/clocksource/arm_global_timer.c | 7 +++++++
>> 2 files changed, 11 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt
>> b/Documentation/devicetree/bindings/arm/global_timer.txt
>> index bdae3a818793..465e02c17b5b 100644
>> --- a/Documentation/devicetree/bindings/arm/global_timer.txt
>> +++ b/Documentation/devicetree/bindings/arm/global_timer.txt
>> @@ -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@2c000600 {
>> diff --git a/drivers/clocksource/arm_global_timer.c
>> b/drivers/clocksource/arm_global_timer.c
>> index e6833771a716..8913ebda3f09 100644
>> --- a/drivers/clocksource/arm_global_timer.c
>> +++ b/drivers/clocksource/arm_global_timer.c
>> @@ -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.
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
>
>
>
> --srini
>
>> gt_clk = of_clk_get(np, 0);
>> if (!IS_ERR(gt_clk)) {
>> err = clk_prepare_enable(gt_clk);
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH] clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
@ 2015-04-17 12:49 ` Peter Griffin
0 siblings, 0 replies; 12+ messages in thread
From: Peter Griffin @ 2015-04-17 12:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi Srini, Ola, Maxime,
On Tue, 14 Apr 2015, Maxime Coquelin wrote:
> On 04/14/2015 09:41 AM, Srinivas Kandagatla wrote:
> >+Adding Pete and Maxime
Thanks Srini, as I wouldn't have seen this otherwise.
<snip>
> >>+
> >
> >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.
> 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.
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
@ 2015-04-17 12:49 ` Peter Griffin
0 siblings, 0 replies; 12+ messages in thread
From: Peter Griffin @ 2015-04-17 12:49 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Srinivas Kandagatla, Ola Jeppsson,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann,
Srinivas Kandagatla, Michal Simek, Stuart Menefy, Olof Johansson,
Sören Brinkmann
Hi Srini, Ola, Maxime,
On Tue, 14 Apr 2015, Maxime Coquelin wrote:
> On 04/14/2015 09:41 AM, Srinivas Kandagatla wrote:
> >+Adding Pete and Maxime
Thanks Srini, as I wouldn't have seen this otherwise.
<snip>
> >>+
> >
> >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.
> 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.
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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
2015-04-14 7:41 ` Srinivas Kandagatla
@ 2015-04-14 13:50 ` Sören Brinkmann
-1 siblings, 0 replies; 12+ messages in thread
From: Sören Brinkmann @ 2015-04-14 13:50 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 2015-04-14 at 08:41AM +0100, Srinivas Kandagatla wrote:
> +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.
>
> On 13/04/15 18:37, Ola Jeppsson wrote:
> >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 <ola@adapteva.com>
> >---
> > Documentation/devicetree/bindings/arm/global_timer.txt | 4 ++++
> > drivers/clocksource/arm_global_timer.c | 7 +++++++
> > 2 files changed, 11 insertions(+)
> >
> >diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt b/Documentation/devicetree/bindings/arm/global_timer.txt
> >index bdae3a818793..465e02c17b5b 100644
> >--- a/Documentation/devicetree/bindings/arm/global_timer.txt
> >+++ b/Documentation/devicetree/bindings/arm/global_timer.txt
> >@@ -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 {
> >diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c
> >index e6833771a716..8913ebda3f09 100644
> >--- a/drivers/clocksource/arm_global_timer.c
> >+++ b/drivers/clocksource/arm_global_timer.c
> >@@ -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.
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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
@ 2015-04-14 13:50 ` Sören Brinkmann
0 siblings, 0 replies; 12+ messages in thread
From: Sören Brinkmann @ 2015-04-14 13:50 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: devicetree, Ola Jeppsson, Arnd Bergmann, Srinivas Kandagatla,
Michal Simek, Peter Griffin, Stuart Menefy, Olof Johansson,
linux-arm-kernel, Maxime Coquelin
On Tue, 2015-04-14 at 08:41AM +0100, Srinivas Kandagatla wrote:
> +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.
>
> On 13/04/15 18:37, Ola Jeppsson wrote:
> >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 <ola@adapteva.com>
> >---
> > Documentation/devicetree/bindings/arm/global_timer.txt | 4 ++++
> > drivers/clocksource/arm_global_timer.c | 7 +++++++
> > 2 files changed, 11 insertions(+)
> >
> >diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt b/Documentation/devicetree/bindings/arm/global_timer.txt
> >index bdae3a818793..465e02c17b5b 100644
> >--- a/Documentation/devicetree/bindings/arm/global_timer.txt
> >+++ b/Documentation/devicetree/bindings/arm/global_timer.txt
> >@@ -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@2c000600 {
> >diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c
> >index e6833771a716..8913ebda3f09 100644
> >--- a/drivers/clocksource/arm_global_timer.c
> >+++ b/drivers/clocksource/arm_global_timer.c
> >@@ -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.
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread