From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] drivers/clocksource/fttmr010: Implement delay timer
Date: Mon, 12 Jun 2017 09:30:31 +0200 [thread overview]
Message-ID: <20170612073031.GA2261@mai> (raw)
In-Reply-To: <20170611212617.6906-2-linus.walleij@linaro.org>
On Sun, Jun 11, 2017 at 11:26:17PM +0200, Linus Walleij wrote:
> This timer is often used on the ARM architecture, so as with so
> many siblings, we can implement delay timers, removing the need
> for the system to calibrate jiffys at boot, and potentially
> handling CPU frequency scaling on targets.
>
> We cannot just protect the Kconfig with a "depends on ARM" because
> it is already known that different architectures are using Faraday
> IP blocks, so it is better to make things open-ended and use
>
> Result on boot dmesg:
>
> Switching to timer-based delay loop, resolution 40n
> Calibrating delay loop (skipped), value calculated using
> timer frequency.. 50.00 BogoMIPS (lpj=250000)
>
> This is accurately the timer frequency, 250MHz on the APB
> bus.
>
> Cc: Andrew Jeffery <andrew@aj.id.au>
> Cc: Joel Stanley <joel@jms.id.au>
> Cc: Jonas Jensen <jonas.jensen@gmail.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/clocksource/timer-fttmr010.c | 35 ++++++++++++++++++++++++++++++++++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/timer-fttmr010.c b/drivers/clocksource/timer-fttmr010.c
> index 5e82469995cb..0074d89cd2ce 100644
> --- a/drivers/clocksource/timer-fttmr010.c
> +++ b/drivers/clocksource/timer-fttmr010.c
> @@ -17,6 +17,7 @@
> #include <linux/clk.h>
> #include <linux/slab.h>
> #include <linux/bitops.h>
> +#include <linux/delay.h>
>
> /*
> * Register definitions for the timers
> @@ -81,9 +82,15 @@ struct fttmr010 {
> bool count_down;
> u32 t1_enable_val;
> struct clock_event_device clkevt;
> +#ifdef CONFIG_ARM
> + struct delay_timer delay_timer;
> +#endif
> };
>
> -/* A local singleton used by sched_clock, which is stateless */
> +/*
> + * A local singleton used by sched_clock and delay timer reads, which are
> + * fast and stateless
> + */
> static struct fttmr010 *local_fttmr;
>
> static inline struct fttmr010 *to_fttmr010(struct clock_event_device *evt)
> @@ -101,6 +108,20 @@ static u64 notrace fttmr010_read_sched_clock_down(void)
> return ~readl(local_fttmr->base + TIMER2_COUNT);
> }
>
> +#ifdef CONFIG_ARM
> +
> +static unsigned long fttmr010_read_current_timer_up(void)
> +{
> + return readl(local_fttmr->base + TIMER2_COUNT);
> +}
> +
> +static unsigned long fttmr010_read_current_timer_down(void)
> +{
> + return ~readl(local_fttmr->base + TIMER2_COUNT);
> +}
> +
> +#endif
> +
These functions are duplicated with fttmr010_read_sched_clock_down() /
fttmr010_read_sched_clock_up().
Could you factor them out?
eg.
static inline unsigned long fttmr010_read_current_timer_up(void)
{
return readl(local_fttmr->base + TIMER2_COUNT);
}
static inline unsigned long fttmr010_read_current_timer_down(void)
{
return ~readl(local_fttmr->base + TIMER2_COUNT);
}
static u64 notrace fttmr010_read_sched_clock_down(void)
{
return fttmr010_read_current_timer_down()
}
static u64 notrace fttmr010_read_sched_clock_up(void)
{
return fttmr010_read_current_timer_up();
}
So we get rid of these CONFIG_ARM section above.
> static int fttmr010_timer_set_next_event(unsigned long cycles,
> struct clock_event_device *evt)
> {
> @@ -349,6 +370,18 @@ static int __init fttmr010_timer_init(struct device_node *np)
> fttmr010->tick_rate,
> 1, 0xffffffff);
>
> +#ifdef CONFIG_ARM
> + /* Also use this timer for delays */
> + if (fttmr010->count_down)
> + fttmr010->delay_timer.read_current_timer =
> + fttmr010_read_current_timer_down;
> + else
> + fttmr010->delay_timer.read_current_timer =
> + fttmr010_read_current_timer_up;
> + fttmr010->delay_timer.freq = fttmr010->tick_rate;
> + register_current_timer_delay(&fttmr010->delay_timer);
> +#endif
> +
> return 0;
>
> out_unmap:
> --
> 2.9.4
>
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Joel Stanley <joel@jms.id.au>,
Jonas Jensen <jonas.jensen@gmail.com>,
Janos Laube <janos.dev@gmail.com>,
Paulius Zaleckas <paulius.zaleckas@gmail.com>,
linux-arm-kernel@lists.infradead.org,
Hans Ulli Kroll <ulli.kroll@googlemail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
linux-kernel@vger.kernel.org, Andrew Jeffery <andrew@aj.id.au>
Subject: Re: [PATCH 2/2] drivers/clocksource/fttmr010: Implement delay timer
Date: Mon, 12 Jun 2017 09:30:31 +0200 [thread overview]
Message-ID: <20170612073031.GA2261@mai> (raw)
In-Reply-To: <20170611212617.6906-2-linus.walleij@linaro.org>
On Sun, Jun 11, 2017 at 11:26:17PM +0200, Linus Walleij wrote:
> This timer is often used on the ARM architecture, so as with so
> many siblings, we can implement delay timers, removing the need
> for the system to calibrate jiffys at boot, and potentially
> handling CPU frequency scaling on targets.
>
> We cannot just protect the Kconfig with a "depends on ARM" because
> it is already known that different architectures are using Faraday
> IP blocks, so it is better to make things open-ended and use
>
> Result on boot dmesg:
>
> Switching to timer-based delay loop, resolution 40n
> Calibrating delay loop (skipped), value calculated using
> timer frequency.. 50.00 BogoMIPS (lpj=250000)
>
> This is accurately the timer frequency, 250MHz on the APB
> bus.
>
> Cc: Andrew Jeffery <andrew@aj.id.au>
> Cc: Joel Stanley <joel@jms.id.au>
> Cc: Jonas Jensen <jonas.jensen@gmail.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/clocksource/timer-fttmr010.c | 35 ++++++++++++++++++++++++++++++++++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/timer-fttmr010.c b/drivers/clocksource/timer-fttmr010.c
> index 5e82469995cb..0074d89cd2ce 100644
> --- a/drivers/clocksource/timer-fttmr010.c
> +++ b/drivers/clocksource/timer-fttmr010.c
> @@ -17,6 +17,7 @@
> #include <linux/clk.h>
> #include <linux/slab.h>
> #include <linux/bitops.h>
> +#include <linux/delay.h>
>
> /*
> * Register definitions for the timers
> @@ -81,9 +82,15 @@ struct fttmr010 {
> bool count_down;
> u32 t1_enable_val;
> struct clock_event_device clkevt;
> +#ifdef CONFIG_ARM
> + struct delay_timer delay_timer;
> +#endif
> };
>
> -/* A local singleton used by sched_clock, which is stateless */
> +/*
> + * A local singleton used by sched_clock and delay timer reads, which are
> + * fast and stateless
> + */
> static struct fttmr010 *local_fttmr;
>
> static inline struct fttmr010 *to_fttmr010(struct clock_event_device *evt)
> @@ -101,6 +108,20 @@ static u64 notrace fttmr010_read_sched_clock_down(void)
> return ~readl(local_fttmr->base + TIMER2_COUNT);
> }
>
> +#ifdef CONFIG_ARM
> +
> +static unsigned long fttmr010_read_current_timer_up(void)
> +{
> + return readl(local_fttmr->base + TIMER2_COUNT);
> +}
> +
> +static unsigned long fttmr010_read_current_timer_down(void)
> +{
> + return ~readl(local_fttmr->base + TIMER2_COUNT);
> +}
> +
> +#endif
> +
These functions are duplicated with fttmr010_read_sched_clock_down() /
fttmr010_read_sched_clock_up().
Could you factor them out?
eg.
static inline unsigned long fttmr010_read_current_timer_up(void)
{
return readl(local_fttmr->base + TIMER2_COUNT);
}
static inline unsigned long fttmr010_read_current_timer_down(void)
{
return ~readl(local_fttmr->base + TIMER2_COUNT);
}
static u64 notrace fttmr010_read_sched_clock_down(void)
{
return fttmr010_read_current_timer_down()
}
static u64 notrace fttmr010_read_sched_clock_up(void)
{
return fttmr010_read_current_timer_up();
}
So we get rid of these CONFIG_ARM section above.
> static int fttmr010_timer_set_next_event(unsigned long cycles,
> struct clock_event_device *evt)
> {
> @@ -349,6 +370,18 @@ static int __init fttmr010_timer_init(struct device_node *np)
> fttmr010->tick_rate,
> 1, 0xffffffff);
>
> +#ifdef CONFIG_ARM
> + /* Also use this timer for delays */
> + if (fttmr010->count_down)
> + fttmr010->delay_timer.read_current_timer =
> + fttmr010_read_current_timer_down;
> + else
> + fttmr010->delay_timer.read_current_timer =
> + fttmr010_read_current_timer_up;
> + fttmr010->delay_timer.freq = fttmr010->tick_rate;
> + register_current_timer_delay(&fttmr010->delay_timer);
> +#endif
> +
> return 0;
>
> out_unmap:
> --
> 2.9.4
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2017-06-12 7:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-11 21:26 [PATCH 1/2] drivers/clocksource/fttmr010: Optimize sched_clock() Linus Walleij
2017-06-11 21:26 ` Linus Walleij
2017-06-11 21:26 ` [PATCH 2/2] drivers/clocksource/fttmr010: Implement delay timer Linus Walleij
2017-06-11 21:26 ` Linus Walleij
2017-06-12 7:30 ` Daniel Lezcano [this message]
2017-06-12 7:30 ` Daniel Lezcano
2017-06-12 12:41 ` Jonas Jensen
2017-06-12 12:41 ` Jonas Jensen
2017-06-13 9:18 ` Linus Walleij
2017-06-13 9:18 ` Linus Walleij
2017-06-13 6:10 ` Andrew Jeffery
2017-06-13 6:10 ` Andrew Jeffery
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170612073031.GA2261@mai \
--to=daniel.lezcano@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.