* [PATCH 01/13] timekeeping: add CONFIG_LEGACY_TIMER_TICK
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
@ 2020-10-08 15:46 ` Arnd Bergmann
2020-10-09 22:18 ` Finn Thain
2020-10-12 13:14 ` Geert Uytterhoeven
2020-10-08 15:46 ` [PATCH 02/13] ia64: convert to legacy_timer_tick Arnd Bergmann
` (12 subsequent siblings)
13 siblings, 2 replies; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-08 15:46 UTC (permalink / raw)
To: linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, Arnd Bergmann, linux-ia64,
Stephen Boyd, Helge Deller, Daniel Lezcano, Russell King,
Finn Thain, James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
All platforms that currently do not use generic clockevents roughly call
the same set of functions in their timer interrupts: xtime_update(),
update_process_times() and profile_tick(), sometimes in a different
sequence.
Add a helper function that performs all three of them, to make the
callers more uniform and simplify the interface.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/timekeeping.h | 1 +
kernel/time/Kconfig | 7 +++++++
kernel/time/Makefile | 1 +
kernel/time/tick-legacy.c | 19 +++++++++++++++++++
4 files changed, 28 insertions(+)
create mode 100644 kernel/time/tick-legacy.c
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 7f7e4a3f4394..3670cb1670ff 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -12,6 +12,7 @@ extern int timekeeping_suspended;
/* Architecture timer tick functions: */
extern void update_process_times(int user);
extern void xtime_update(unsigned long ticks);
+extern void legacy_timer_tick(unsigned long ticks);
/*
* Get and set timeofday
diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
index a09b1d61df6a..f2b0cfeade47 100644
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -61,6 +61,13 @@ config POSIX_CPU_TIMERS_TASK_WORK
bool
default y if POSIX_TIMERS && HAVE_POSIX_CPU_TIMERS_TASK_WORK
+config LEGACY_TIMER_TICK
+ bool
+ help
+ The legacy timer tick helper is used by platforms that
+ lack support for the generic clockevent framework.
+ New platforms should use generic clockevents instead.
+
if GENERIC_CLOCKEVENTS
menu "Timers subsystem"
diff --git a/kernel/time/Makefile b/kernel/time/Makefile
index c8f00168afe8..1fb1c1ef6a19 100644
--- a/kernel/time/Makefile
+++ b/kernel/time/Makefile
@@ -16,6 +16,7 @@ ifeq ($(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST),y)
endif
obj-$(CONFIG_GENERIC_SCHED_CLOCK) += sched_clock.o
obj-$(CONFIG_TICK_ONESHOT) += tick-oneshot.o tick-sched.o
+obj-$(CONFIG_LEGACY_TIMER_TICK) += tick-legacy.o
obj-$(CONFIG_HAVE_GENERIC_VDSO) += vsyscall.o
obj-$(CONFIG_DEBUG_FS) += timekeeping_debug.o
obj-$(CONFIG_TEST_UDELAY) += test_udelay.o
diff --git a/kernel/time/tick-legacy.c b/kernel/time/tick-legacy.c
new file mode 100644
index 000000000000..73c5a0af4743
--- /dev/null
+++ b/kernel/time/tick-legacy.c
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Timer tick function for architectures that lack generic clockevents,
+ * consolidated here from m68k/ia64/parisc/arm.
+ */
+
+#include <linux/irq.h>
+#include <linux/profile.h>
+#include <linux/timekeeper_internal.h>
+
+#include "tick-internal.h"
+
+void legacy_timer_tick(unsigned long ticks)
+{
+ if (ticks)
+ xtime_update(ticks);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
+}
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [PATCH 01/13] timekeeping: add CONFIG_LEGACY_TIMER_TICK
2020-10-08 15:46 ` [PATCH 01/13] timekeeping: add CONFIG_LEGACY_TIMER_TICK Arnd Bergmann
@ 2020-10-09 22:18 ` Finn Thain
2020-10-10 20:31 ` Arnd Bergmann
2020-10-12 13:14 ` Geert Uytterhoeven
1 sibling, 1 reply; 43+ messages in thread
From: Finn Thain @ 2020-10-09 22:18 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, linux-ia64, Stephen Boyd,
Helge Deller, Daniel Lezcano, linux-kernel, Russell King,
James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
Hi Arnd,
On Thu, 8 Oct 2020, Arnd Bergmann wrote:
> All platforms that currently do not use generic clockevents roughly call
> the same set of functions in their timer interrupts: xtime_update(),
> update_process_times() and profile_tick(), sometimes in a different
> sequence.
>
> Add a helper function that performs all three of them, to make the
> callers more uniform and simplify the interface.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> include/linux/timekeeping.h | 1 +
> kernel/time/Kconfig | 7 +++++++
> kernel/time/Makefile | 1 +
> kernel/time/tick-legacy.c | 19 +++++++++++++++++++
> 4 files changed, 28 insertions(+)
> create mode 100644 kernel/time/tick-legacy.c
>
> diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
> index 7f7e4a3f4394..3670cb1670ff 100644
> --- a/include/linux/timekeeping.h
> +++ b/include/linux/timekeeping.h
> @@ -12,6 +12,7 @@ extern int timekeeping_suspended;
> /* Architecture timer tick functions: */
> extern void update_process_times(int user);
> extern void xtime_update(unsigned long ticks);
> +extern void legacy_timer_tick(unsigned long ticks);
>
> /*
> * Get and set timeofday
> diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> index a09b1d61df6a..f2b0cfeade47 100644
> --- a/kernel/time/Kconfig
> +++ b/kernel/time/Kconfig
> @@ -61,6 +61,13 @@ config POSIX_CPU_TIMERS_TASK_WORK
> bool
> default y if POSIX_TIMERS && HAVE_POSIX_CPU_TIMERS_TASK_WORK
>
> +config LEGACY_TIMER_TICK
> + bool
> + help
> + The legacy timer tick helper is used by platforms that
> + lack support for the generic clockevent framework.
> + New platforms should use generic clockevents instead.
> +
> if GENERIC_CLOCKEVENTS
> menu "Timers subsystem"
>
> diff --git a/kernel/time/Makefile b/kernel/time/Makefile
> index c8f00168afe8..1fb1c1ef6a19 100644
> --- a/kernel/time/Makefile
> +++ b/kernel/time/Makefile
> @@ -16,6 +16,7 @@ ifeq ($(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST),y)
> endif
> obj-$(CONFIG_GENERIC_SCHED_CLOCK) += sched_clock.o
> obj-$(CONFIG_TICK_ONESHOT) += tick-oneshot.o tick-sched.o
> +obj-$(CONFIG_LEGACY_TIMER_TICK) += tick-legacy.o
> obj-$(CONFIG_HAVE_GENERIC_VDSO) += vsyscall.o
> obj-$(CONFIG_DEBUG_FS) += timekeeping_debug.o
> obj-$(CONFIG_TEST_UDELAY) += test_udelay.o
> diff --git a/kernel/time/tick-legacy.c b/kernel/time/tick-legacy.c
> new file mode 100644
> index 000000000000..73c5a0af4743
> --- /dev/null
> +++ b/kernel/time/tick-legacy.c
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Timer tick function for architectures that lack generic clockevents,
> + * consolidated here from m68k/ia64/parisc/arm.
> + */
> +
> +#include <linux/irq.h>
> +#include <linux/profile.h>
> +#include <linux/timekeeper_internal.h>
> +
> +#include "tick-internal.h"
> +
> +void legacy_timer_tick(unsigned long ticks)
> +{
> + if (ticks)
> + xtime_update(ticks);
> + update_process_times(user_mode(get_irq_regs()));
> + profile_tick(CPU_PROFILING);
> +}
>
It's good to see this code refactored in this way because, as well as
de-duplication, it reveals the logic that's common to the relevant
platforms and may shed some light on the need for that logic.
Yet it's not clear to me that the clockevents framework is able to replace
that logic on all of the affected hardware. I suppose it remains to be
seen.
I hate to quibble about naming, but you seem to be using "legacy" here to
mean "deprecated" (?) Is it a good idea to prepend such adjectives to
symbol names?
IMO, the term "legacy" is redundant in this context. That term covers a
large portion of kernel code, a large number of hardware features in
current silicon, a large portion of the userspace ABI, a large number of
production Linux systems, probably all "Unix" systems, etc.
As a corollary, cutting edge ("non-legacy") code is often kept out of open
source projects by the owners of the intellectual property rights.
_______________________________________________
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] 43+ messages in thread* Re: [PATCH 01/13] timekeeping: add CONFIG_LEGACY_TIMER_TICK
2020-10-09 22:18 ` Finn Thain
@ 2020-10-10 20:31 ` Arnd Bergmann
0 siblings, 0 replies; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-10 20:31 UTC (permalink / raw)
To: Finn Thain
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, Parisc List, linux-ia64, Stephen Boyd,
Helge Deller, Daniel Lezcano, linux-kernel, Russell King,
James E.J. Bottomley, linux-m68k, Geert Uytterhoeven, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
On Sat, Oct 10, 2020 at 12:18 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> On Thu, 8 Oct 2020, Arnd Bergmann wrote:
>
> It's good to see this code refactored in this way because, as well as
> de-duplication, it reveals the logic that's common to the relevant
> platforms and may shed some light on the need for that logic.
>
> Yet it's not clear to me that the clockevents framework is able to replace
> that logic on all of the affected hardware. I suppose it remains to be
> seen.
I suspect that the change I did for one platform in patch 13/13 could be
duplicated for all 16 platforms, adding lots of trivial clockevent drivers that
only support periodic ticks, but any platform that can instead support
oneshot timers should probably do that, or it won't provide any better
behavior.
What do others think we should do here?
> As a corollary, cutting edge ("non-legacy") code is often kept out of open
> source projects by the owners of the intellectual property rights.
I'm happy to change the name in any way if you have a suggestion
that the clock event maintainers (Daniel and Thomas) like.
Arnd
_______________________________________________
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] 43+ messages in thread
* Re: [PATCH 01/13] timekeeping: add CONFIG_LEGACY_TIMER_TICK
2020-10-08 15:46 ` [PATCH 01/13] timekeeping: add CONFIG_LEGACY_TIMER_TICK Arnd Bergmann
2020-10-09 22:18 ` Finn Thain
@ 2020-10-12 13:14 ` Geert Uytterhoeven
1 sibling, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2020-10-12 13:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
Linux Kernel Mailing List, Finn Thain, Russell King,
James E.J. Bottomley, linux-m68k, Thomas Gleixner, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
On Thu, Oct 8, 2020 at 5:47 PM Arnd Bergmann <arnd@arndb.de> wrote:
> All platforms that currently do not use generic clockevents roughly call
> the same set of functions in their timer interrupts: xtime_update(),
> update_process_times() and profile_tick(), sometimes in a different
> sequence.
>
> Add a helper function that performs all three of them, to make the
> callers more uniform and simplify the interface.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] 43+ messages in thread
* [PATCH 02/13] ia64: convert to legacy_timer_tick
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
2020-10-08 15:46 ` [PATCH 01/13] timekeeping: add CONFIG_LEGACY_TIMER_TICK Arnd Bergmann
@ 2020-10-08 15:46 ` Arnd Bergmann
2020-10-08 15:46 ` [PATCH 03/13] ARM: rpc: use legacy_timer_tick Arnd Bergmann
` (11 subsequent siblings)
13 siblings, 0 replies; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-08 15:46 UTC (permalink / raw)
To: linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, Arnd Bergmann, linux-ia64,
Stephen Boyd, Helge Deller, Daniel Lezcano, Russell King,
Finn Thain, James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
ia64 is the only architecture that calls xtime_update() in a loop,
once for each jiffie that has passed since the last event.
Before commit 3171a0305d62 ("[PATCH] simplify update_times (avoid
jiffies/jiffies_64 aliasing problem)") in 2006, it could not actually do
this any differently, but now it seems simpler to just pass the number
of jiffies that passed in the meantime.
While this loses the ability process interrupts in the middle of
the timer tick by calling local_irq_enable(), doing so is fairly
peculiar anyway and it seems better to just do what everyone
else does here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/ia64/Kconfig | 1 +
arch/ia64/kernel/time.c | 36 +++++++++++++-----------------------
2 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 39b25a5a591b..db8c2a365b70 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -46,6 +46,7 @@ config IA64
select ARCH_THREAD_STACK_ALLOCATOR
select ARCH_CLOCKSOURCE_DATA
select GENERIC_TIME_VSYSCALL
+ select LEGACY_TIMER_TICK
select SWIOTLB
select SYSCTL_ARCH_UNALIGN_NO_WARN
select HAVE_MOD_ARCH_SPECIFIC
diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c
index 7abc5f37bfaf..9431edb08508 100644
--- a/arch/ia64/kernel/time.c
+++ b/arch/ia64/kernel/time.c
@@ -161,39 +161,29 @@ void vtime_account_idle(struct task_struct *tsk)
static irqreturn_t
timer_interrupt (int irq, void *dev_id)
{
- unsigned long new_itm;
+ unsigned long cur_itm, new_itm, ticks;
if (cpu_is_offline(smp_processor_id())) {
return IRQ_HANDLED;
}
new_itm = local_cpu_data->itm_next;
+ cur_itm = ia64_get_itc();
- if (!time_after(ia64_get_itc(), new_itm))
+ if (!time_after(cur_itm, new_itm)) {
printk(KERN_ERR "Oops: timer tick before it's due (itc=%lx,itm=%lx)\n",
- ia64_get_itc(), new_itm);
-
- profile_tick(CPU_PROFILING);
-
- while (1) {
- update_process_times(user_mode(get_irq_regs()));
-
- new_itm += local_cpu_data->itm_delta;
-
- if (smp_processor_id() == time_keeper_id)
- xtime_update(1);
-
- local_cpu_data->itm_next = new_itm;
+ cur_itm, new_itm);
+ ticks = 1;
+ } else {
+ ticks = DIV_ROUND_UP(cur_itm - new_itm,
+ local_cpu_data->itm_delta);
+ new_itm += ticks * local_cpu_data->itm_delta;
+ }
- if (time_after(new_itm, ia64_get_itc()))
- break;
+ if (smp_processor_id() != time_keeper_id)
+ ticks = 0;
- /*
- * Allow IPIs to interrupt the timer loop.
- */
- local_irq_enable();
- local_irq_disable();
- }
+ legacy_timer_tick(ticks);
do {
/*
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* [PATCH 03/13] ARM: rpc: use legacy_timer_tick
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
2020-10-08 15:46 ` [PATCH 01/13] timekeeping: add CONFIG_LEGACY_TIMER_TICK Arnd Bergmann
2020-10-08 15:46 ` [PATCH 02/13] ia64: convert to legacy_timer_tick Arnd Bergmann
@ 2020-10-08 15:46 ` Arnd Bergmann
2020-10-08 15:46 ` [PATCH 04/13] parisc: " Arnd Bergmann
` (10 subsequent siblings)
13 siblings, 0 replies; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-08 15:46 UTC (permalink / raw)
To: linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, Arnd Bergmann, linux-ia64,
Stephen Boyd, Helge Deller, Daniel Lezcano, Russell King,
Finn Thain, James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
rpc is the only user of the timer_tick() function now, and can
just call the newly added generic version instead.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/mach/time.h | 2 --
arch/arm/kernel/time.c | 14 --------------
arch/arm/mach-rpc/time.c | 2 +-
4 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fe2f17eb2b50..13af8d7a6c17 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -467,6 +467,7 @@ config ARCH_RPC
select HAVE_IDE
select HAVE_PATA_PLATFORM
select ISA_DMA_API
+ select LEGACY_TIMER_TICK
select NEED_MACH_IO_H
select NEED_MACH_MEMORY_H
select NO_IOPORT_MAP
diff --git a/arch/arm/include/asm/mach/time.h b/arch/arm/include/asm/mach/time.h
index d75d39280db7..5f522916ec99 100644
--- a/arch/arm/include/asm/mach/time.h
+++ b/arch/arm/include/asm/mach/time.h
@@ -7,8 +7,6 @@
#ifndef __ASM_ARM_MACH_TIME_H
#define __ASM_ARM_MACH_TIME_H
-extern void timer_tick(void);
-
typedef void (*clock_access_fn)(struct timespec64 *);
extern int register_persistent_clock(clock_access_fn read_persistent);
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 09b149b09c43..b3836c94dc74 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -60,20 +60,6 @@ unsigned long profile_pc(struct pt_regs *regs)
EXPORT_SYMBOL(profile_pc);
#endif
-#ifndef CONFIG_GENERIC_CLOCKEVENTS
-/*
- * Kernel system timer support.
- */
-void timer_tick(void)
-{
- profile_tick(CPU_PROFILING);
- xtime_update(1);
-#ifndef CONFIG_SMP
- update_process_times(user_mode(get_irq_regs()));
-#endif
-}
-#endif
-
static void dummy_clock_access(struct timespec64 *ts)
{
ts->tv_sec = 0;
diff --git a/arch/arm/mach-rpc/time.c b/arch/arm/mach-rpc/time.c
index da85cac761ba..9f8edcfe9357 100644
--- a/arch/arm/mach-rpc/time.c
+++ b/arch/arm/mach-rpc/time.c
@@ -81,7 +81,7 @@ static irqreturn_t
ioc_timer_interrupt(int irq, void *dev_id)
{
ioc_time += RPC_LATCH;
- timer_tick();
+ legacy_timer_tick(1);
return IRQ_HANDLED;
}
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* [PATCH 04/13] parisc: use legacy_timer_tick
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
` (2 preceding siblings ...)
2020-10-08 15:46 ` [PATCH 03/13] ARM: rpc: use legacy_timer_tick Arnd Bergmann
@ 2020-10-08 15:46 ` Arnd Bergmann
2020-10-08 15:46 ` [PATCH 05/13] m68k: coldfire: use legacy_timer_tick() Arnd Bergmann
` (9 subsequent siblings)
13 siblings, 0 replies; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-08 15:46 UTC (permalink / raw)
To: linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, Arnd Bergmann, linux-ia64,
Stephen Boyd, Helge Deller, Daniel Lezcano, Russell King,
Finn Thain, James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
parisc has selected CONFIG_GENERIC_CLOCKEVENTS since commit 43b1f6abd590
("parisc: Switch to generic sched_clock implementation"), but does not
appear to actually be using it, and instead calls the low-level
timekeeping functions directly.
Remove the GENERIC_CLOCKEVENTS select again, and instead convert to
the newly added legacy_timer_tick() helper.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Documentation/features/time/clockevents/arch-support.txt | 2 +-
arch/parisc/Kconfig | 2 +-
arch/parisc/kernel/time.c | 9 +++------
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/Documentation/features/time/clockevents/arch-support.txt b/Documentation/features/time/clockevents/arch-support.txt
index 8287b6aa522e..61a5c9d68c15 100644
--- a/Documentation/features/time/clockevents/arch-support.txt
+++ b/Documentation/features/time/clockevents/arch-support.txt
@@ -21,7 +21,7 @@
| nds32: | ok |
| nios2: | ok |
| openrisc: | ok |
- | parisc: | ok |
+ | parisc: | TODO |
| powerpc: | ok |
| riscv: | ok |
| s390: | ok |
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index b234e8154cbd..78b17621ee4a 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -52,7 +52,7 @@ config PARISC
select HAVE_REGS_AND_STACK_ACCESS_API
select GENERIC_SCHED_CLOCK
select HAVE_UNSTABLE_SCHED_CLOCK if SMP
- select GENERIC_CLOCKEVENTS
+ select LEGACY_TIMER_TICK
select CPU_NO_EFFICIENT_FFS
select NEED_DMA_MAP_STATE
select NEED_SG_DMA_LENGTH
diff --git a/arch/parisc/kernel/time.c b/arch/parisc/kernel/time.c
index 04508158815c..889aaaa555ea 100644
--- a/arch/parisc/kernel/time.c
+++ b/arch/parisc/kernel/time.c
@@ -70,8 +70,6 @@ irqreturn_t __irq_entry timer_interrupt(int irq, void *dev_id)
/* gcc can optimize for "read-only" case with a local clocktick */
unsigned long cpt = clocktick;
- profile_tick(CPU_PROFILING);
-
/* Initialize next_tick to the old expected tick time. */
next_tick = cpuinfo->it_value;
@@ -86,10 +84,9 @@ irqreturn_t __irq_entry timer_interrupt(int irq, void *dev_id)
cpuinfo->it_value = next_tick;
/* Go do system house keeping. */
- if (cpu == 0)
- xtime_update(ticks_elapsed);
-
- update_process_times(user_mode(get_irq_regs()));
+ if (cpu != 0)
+ ticks_elapsed = 0;
+ legacy_timer_tick(ticks_elapsed);
/* Skip clockticks on purpose if we know we would miss those.
* The new CR16 must be "later" than current CR16 otherwise
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* [PATCH 05/13] m68k: coldfire: use legacy_timer_tick()
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
` (3 preceding siblings ...)
2020-10-08 15:46 ` [PATCH 04/13] parisc: " Arnd Bergmann
@ 2020-10-08 15:46 ` Arnd Bergmann
2020-10-09 12:53 ` Greg Ungerer
2020-10-08 15:46 ` [PATCH 06/13] m68k: split heartbeat out of timer function Arnd Bergmann
` (8 subsequent siblings)
13 siblings, 1 reply; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-08 15:46 UTC (permalink / raw)
To: linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, Arnd Bergmann, linux-ia64,
Stephen Boyd, Helge Deller, Daniel Lezcano, Russell King,
Finn Thain, James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
Replace the indirect function calls in the timer code
with direct calls to the newly added legacy_timer_tick()
helper for those that have not yet been converted to
generic clockevents.
This makes the timer code a little more self-contained.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/m68k/Kconfig.cpu | 35 +++++++++++++++++++++++++++++------
arch/m68k/coldfire/Makefile | 32 ++++++++++++++++++--------------
arch/m68k/coldfire/sltimers.c | 6 ++----
arch/m68k/coldfire/timers.c | 6 ++----
4 files changed, 51 insertions(+), 28 deletions(-)
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index 694c4fca9f5d..322a35ef14c6 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -137,6 +137,7 @@ config M5206
bool "MCF5206"
depends on !MMU
select COLDFIRE_SW_A7
+ select COLDFIRE_TIMERS
select HAVE_MBAR
select CPU_NO_EFFICIENT_FFS
help
@@ -146,6 +147,7 @@ config M5206e
bool "MCF5206e"
depends on !MMU
select COLDFIRE_SW_A7
+ select COLDFIRE_TIMERS
select HAVE_MBAR
select CPU_NO_EFFICIENT_FFS
help
@@ -154,7 +156,7 @@ config M5206e
config M520x
bool "MCF520x"
depends on !MMU
- select GENERIC_CLOCKEVENTS
+ select COLDFIRE_PIT_TIMER
select HAVE_CACHE_SPLIT
help
Freescale Coldfire 5207/5208 processor support.
@@ -162,7 +164,7 @@ config M520x
config M523x
bool "MCF523x"
depends on !MMU
- select GENERIC_CLOCKEVENTS
+ select COLDFIRE_PIT_TIMER
select HAVE_CACHE_SPLIT
select HAVE_IPSBAR
help
@@ -172,6 +174,7 @@ config M5249
bool "MCF5249"
depends on !MMU
select COLDFIRE_SW_A7
+ select COLDFIRE_TIMERS
select HAVE_MBAR
select CPU_NO_EFFICIENT_FFS
help
@@ -181,6 +184,7 @@ config M525x
bool "MCF525x"
depends on !MMU
select COLDFIRE_SW_A7
+ select COLDFIRE_TIMERS
select HAVE_MBAR
select CPU_NO_EFFICIENT_FFS
help
@@ -189,10 +193,10 @@ config M525x
config M5271
bool "MCF5271"
depends on !MMU
+ select COLDFIRE_PIT_TIMER
select M527x
select HAVE_CACHE_SPLIT
select HAVE_IPSBAR
- select GENERIC_CLOCKEVENTS
help
Freescale (Motorola) ColdFire 5270/5271 processor support.
@@ -200,6 +204,7 @@ config M5272
bool "MCF5272"
depends on !MMU
select COLDFIRE_SW_A7
+ select COLDFIRE_TIMERS
select HAVE_MBAR
select CPU_NO_EFFICIENT_FFS
help
@@ -208,17 +213,17 @@ config M5272
config M5275
bool "MCF5275"
depends on !MMU
+ select COLDFIRE_PIT_TIMER
select M527x
select HAVE_CACHE_SPLIT
select HAVE_IPSBAR
- select GENERIC_CLOCKEVENTS
help
Freescale (Motorola) ColdFire 5274/5275 processor support.
config M528x
bool "MCF528x"
depends on !MMU
- select GENERIC_CLOCKEVENTS
+ select COLDFIRE_PIT_TIMER
select HAVE_CACHE_SPLIT
select HAVE_IPSBAR
help
@@ -227,6 +232,7 @@ config M528x
config M5307
bool "MCF5307"
depends on !MMU
+ select COLDFIRE_TIMERS
select COLDFIRE_SW_A7
select HAVE_CACHE_CB
select HAVE_MBAR
@@ -237,6 +243,7 @@ config M5307
config M532x
bool "MCF532x"
depends on !MMU
+ select COLDFIRE_TIMERS
select M53xx
select HAVE_CACHE_CB
help
@@ -245,6 +252,7 @@ config M532x
config M537x
bool "MCF537x"
depends on !MMU
+ select COLDFIRE_TIMERS
select M53xx
select HAVE_CACHE_CB
help
@@ -254,6 +262,7 @@ config M5407
bool "MCF5407"
depends on !MMU
select COLDFIRE_SW_A7
+ select COLDFIRE_TIMERS
select HAVE_CACHE_CB
select HAVE_MBAR
select CPU_NO_EFFICIENT_FFS
@@ -263,6 +272,7 @@ config M5407
config M547x
bool "MCF547x"
select M54xx
+ select COLDFIRE_SLTIMERS
select MMU_COLDFIRE if MMU
select FPU if MMU
select HAVE_CACHE_CB
@@ -273,6 +283,7 @@ config M547x
config M548x
bool "MCF548x"
+ select COLDFIRE_SLTIMERS
select MMU_COLDFIRE if MMU
select FPU if MMU
select M54xx
@@ -284,8 +295,8 @@ config M548x
config M5441x
bool "MCF5441x"
+ select COLDFIRE_PIT_TIMER
select MMU_COLDFIRE if MMU
- select GENERIC_CLOCKEVENTS
select HAVE_CACHE_CB
help
Freescale Coldfire 54410/54415/54416/54417/54418 processor support.
@@ -302,6 +313,18 @@ config M54xx
select HAVE_PCI
bool
+config COLDFIRE_PIT_TIMER
+ bool
+ select GENERIC_CLOCKEVENTS
+
+config COLDFIRE_TIMERS
+ bool
+ select LEGACY_TIMER_TICK
+
+config COLDFIRE_SLTIMERS
+ bool
+ select LEGACY_TIMER_TICK
+
endif # COLDFIRE
diff --git a/arch/m68k/coldfire/Makefile b/arch/m68k/coldfire/Makefile
index 573eabca1a3a..a3e18d73d8b8 100644
--- a/arch/m68k/coldfire/Makefile
+++ b/arch/m68k/coldfire/Makefile
@@ -16,20 +16,24 @@
asflags-$(CONFIG_FULLDEBUG) := -DDEBUGGER_COMPATIBLE_CACHE=1
obj-$(CONFIG_COLDFIRE) += cache.o clk.o device.o dma.o entry.o vectors.o
-obj-$(CONFIG_M5206) += m5206.o timers.o intc.o reset.o
-obj-$(CONFIG_M5206e) += m5206.o timers.o intc.o reset.o
-obj-$(CONFIG_M520x) += m520x.o pit.o intc-simr.o reset.o
-obj-$(CONFIG_M523x) += m523x.o pit.o dma_timer.o intc-2.o reset.o
-obj-$(CONFIG_M5249) += m5249.o timers.o intc.o intc-5249.o reset.o
-obj-$(CONFIG_M525x) += m525x.o timers.o intc.o intc-525x.o reset.o
-obj-$(CONFIG_M527x) += m527x.o pit.o intc-2.o reset.o
-obj-$(CONFIG_M5272) += m5272.o intc-5272.o timers.o
-obj-$(CONFIG_M528x) += m528x.o pit.o intc-2.o reset.o
-obj-$(CONFIG_M5307) += m5307.o timers.o intc.o reset.o
-obj-$(CONFIG_M53xx) += m53xx.o timers.o intc-simr.o reset.o
-obj-$(CONFIG_M5407) += m5407.o timers.o intc.o reset.o
-obj-$(CONFIG_M54xx) += m54xx.o sltimers.o intc-2.o
-obj-$(CONFIG_M5441x) += m5441x.o pit.o intc-simr.o reset.o
+obj-$(CONFIG_M5206) += m5206.o intc.o reset.o
+obj-$(CONFIG_M5206e) += m5206.o intc.o reset.o
+obj-$(CONFIG_M520x) += m520x.o intc-simr.o reset.o
+obj-$(CONFIG_M523x) += m523x.o dma_timer.o intc-2.o reset.o
+obj-$(CONFIG_M5249) += m5249.o intc.o intc-5249.o reset.o
+obj-$(CONFIG_M525x) += m525x.o intc.o intc-525x.o reset.o
+obj-$(CONFIG_M527x) += m527x.o intc-2.o reset.o
+obj-$(CONFIG_M5272) += m5272.o intc-5272.o
+obj-$(CONFIG_M528x) += m528x.o intc-2.o reset.o
+obj-$(CONFIG_M5307) += m5307.o intc.o reset.o
+obj-$(CONFIG_M53xx) += m53xx.o intc-simr.o reset.o
+obj-$(CONFIG_M5407) += m5407.o intc.o reset.o
+obj-$(CONFIG_M54xx) += m54xx.o intc-2.o
+obj-$(CONFIG_M5441x) += m5441x.o intc-simr.o reset.o
+
+obj-$(CONFIG_COLDFIRE_PIT_TIMER) += pit.o
+obj-$(CONFIG_COLDFIRE_TIMERS) += timers.o
+obj-$(CONFIG_COLDFIRE_SLTIMERS) += sltimers.o
obj-$(CONFIG_NETtel) += nettel.o
obj-$(CONFIG_CLEOPATRA) += nettel.o
diff --git a/arch/m68k/coldfire/sltimers.c b/arch/m68k/coldfire/sltimers.c
index 5ab81c9c552d..25a1319f3cb8 100644
--- a/arch/m68k/coldfire/sltimers.c
+++ b/arch/m68k/coldfire/sltimers.c
@@ -83,14 +83,13 @@ void mcfslt_profile_init(void)
static u32 mcfslt_cycles_per_jiffy;
static u32 mcfslt_cnt;
-static irq_handler_t timer_interrupt;
-
static irqreturn_t mcfslt_tick(int irq, void *dummy)
{
/* Reset Slice Timer 0 */
__raw_writel(MCFSLT_SSR_BE | MCFSLT_SSR_TE, TA(MCFSLT_SSR));
mcfslt_cnt += mcfslt_cycles_per_jiffy;
- return timer_interrupt(irq, dummy);
+ legacy_timer_tick(1);
+ return IRQ_HANDLED;
}
static u64 mcfslt_read_clk(struct clocksource *cs)
@@ -136,7 +135,6 @@ void hw_timer_init(irq_handler_t handler)
/* initialize mcfslt_cnt knowing that slice timers count down */
mcfslt_cnt = mcfslt_cycles_per_jiffy;
- timer_interrupt = handler;
r = request_irq(MCF_IRQ_TIMER, mcfslt_tick, IRQF_TIMER, "timer", NULL);
if (r) {
pr_err("Failed to request irq %d (timer): %pe\n", MCF_IRQ_TIMER,
diff --git a/arch/m68k/coldfire/timers.c b/arch/m68k/coldfire/timers.c
index b8301fddf901..24b5e2d1b00b 100644
--- a/arch/m68k/coldfire/timers.c
+++ b/arch/m68k/coldfire/timers.c
@@ -48,8 +48,6 @@ void coldfire_profile_init(void);
static u32 mcftmr_cycles_per_jiffy;
static u32 mcftmr_cnt;
-static irq_handler_t timer_interrupt;
-
/***************************************************************************/
static void init_timer_irq(void)
@@ -77,7 +75,8 @@ static irqreturn_t mcftmr_tick(int irq, void *dummy)
__raw_writeb(MCFTIMER_TER_CAP | MCFTIMER_TER_REF, TA(MCFTIMER_TER));
mcftmr_cnt += mcftmr_cycles_per_jiffy;
- return timer_interrupt(irq, dummy);
+ legacy_timer_tick(1);
+ return IRQ_HANDLED;
}
/***************************************************************************/
@@ -126,7 +125,6 @@ void hw_timer_init(irq_handler_t handler)
clocksource_register_hz(&mcftmr_clk, FREQ);
- timer_interrupt = handler;
init_timer_irq();
r = request_irq(MCF_IRQ_TIMER, mcftmr_tick, IRQF_TIMER, "timer", NULL);
if (r) {
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [PATCH 05/13] m68k: coldfire: use legacy_timer_tick()
2020-10-08 15:46 ` [PATCH 05/13] m68k: coldfire: use legacy_timer_tick() Arnd Bergmann
@ 2020-10-09 12:53 ` Greg Ungerer
2020-10-09 13:23 ` Arnd Bergmann
0 siblings, 1 reply; 43+ messages in thread
From: Greg Ungerer @ 2020-10-09 12:53 UTC (permalink / raw)
To: Arnd Bergmann, linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
linux-parisc, Stephen Boyd, Helge Deller, Daniel Lezcano,
Russell King, Finn Thain, James E.J. Bottomley, linux-m68k,
Geert Uytterhoeven, linux-arm-kernel, John Stultz,
Philip Blundell, Thomas Gleixner, Joshua Thompson
Hi Arnd,
On 9/10/20 1:46 am, Arnd Bergmann wrote:
> Replace the indirect function calls in the timer code
> with direct calls to the newly added legacy_timer_tick()
> helper for those that have not yet been converted to
> generic clockevents.
>
> This makes the timer code a little more self-contained.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I tested this series on a couple of different ColdFire parts
(5208 and 5475) and under QEMU emulating the 5208. All checked
out good, all worked as expected. So for the ColdFire changes:
Tested-by: Greg Ungerer <gerg@linux-m68k.org>
Regards
Greg
> ---
> arch/m68k/Kconfig.cpu | 35 +++++++++++++++++++++++++++++------
> arch/m68k/coldfire/Makefile | 32 ++++++++++++++++++--------------
> arch/m68k/coldfire/sltimers.c | 6 ++----
> arch/m68k/coldfire/timers.c | 6 ++----
> 4 files changed, 51 insertions(+), 28 deletions(-)
>
> diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
> index 694c4fca9f5d..322a35ef14c6 100644
> --- a/arch/m68k/Kconfig.cpu
> +++ b/arch/m68k/Kconfig.cpu
> @@ -137,6 +137,7 @@ config M5206
> bool "MCF5206"
> depends on !MMU
> select COLDFIRE_SW_A7
> + select COLDFIRE_TIMERS
> select HAVE_MBAR
> select CPU_NO_EFFICIENT_FFS
> help
> @@ -146,6 +147,7 @@ config M5206e
> bool "MCF5206e"
> depends on !MMU
> select COLDFIRE_SW_A7
> + select COLDFIRE_TIMERS
> select HAVE_MBAR
> select CPU_NO_EFFICIENT_FFS
> help
> @@ -154,7 +156,7 @@ config M5206e
> config M520x
> bool "MCF520x"
> depends on !MMU
> - select GENERIC_CLOCKEVENTS
> + select COLDFIRE_PIT_TIMER
> select HAVE_CACHE_SPLIT
> help
> Freescale Coldfire 5207/5208 processor support.
> @@ -162,7 +164,7 @@ config M520x
> config M523x
> bool "MCF523x"
> depends on !MMU
> - select GENERIC_CLOCKEVENTS
> + select COLDFIRE_PIT_TIMER
> select HAVE_CACHE_SPLIT
> select HAVE_IPSBAR
> help
> @@ -172,6 +174,7 @@ config M5249
> bool "MCF5249"
> depends on !MMU
> select COLDFIRE_SW_A7
> + select COLDFIRE_TIMERS
> select HAVE_MBAR
> select CPU_NO_EFFICIENT_FFS
> help
> @@ -181,6 +184,7 @@ config M525x
> bool "MCF525x"
> depends on !MMU
> select COLDFIRE_SW_A7
> + select COLDFIRE_TIMERS
> select HAVE_MBAR
> select CPU_NO_EFFICIENT_FFS
> help
> @@ -189,10 +193,10 @@ config M525x
> config M5271
> bool "MCF5271"
> depends on !MMU
> + select COLDFIRE_PIT_TIMER
> select M527x
> select HAVE_CACHE_SPLIT
> select HAVE_IPSBAR
> - select GENERIC_CLOCKEVENTS
> help
> Freescale (Motorola) ColdFire 5270/5271 processor support.
>
> @@ -200,6 +204,7 @@ config M5272
> bool "MCF5272"
> depends on !MMU
> select COLDFIRE_SW_A7
> + select COLDFIRE_TIMERS
> select HAVE_MBAR
> select CPU_NO_EFFICIENT_FFS
> help
> @@ -208,17 +213,17 @@ config M5272
> config M5275
> bool "MCF5275"
> depends on !MMU
> + select COLDFIRE_PIT_TIMER
> select M527x
> select HAVE_CACHE_SPLIT
> select HAVE_IPSBAR
> - select GENERIC_CLOCKEVENTS
> help
> Freescale (Motorola) ColdFire 5274/5275 processor support.
>
> config M528x
> bool "MCF528x"
> depends on !MMU
> - select GENERIC_CLOCKEVENTS
> + select COLDFIRE_PIT_TIMER
> select HAVE_CACHE_SPLIT
> select HAVE_IPSBAR
> help
> @@ -227,6 +232,7 @@ config M528x
> config M5307
> bool "MCF5307"
> depends on !MMU
> + select COLDFIRE_TIMERS
> select COLDFIRE_SW_A7
> select HAVE_CACHE_CB
> select HAVE_MBAR
> @@ -237,6 +243,7 @@ config M5307
> config M532x
> bool "MCF532x"
> depends on !MMU
> + select COLDFIRE_TIMERS
> select M53xx
> select HAVE_CACHE_CB
> help
> @@ -245,6 +252,7 @@ config M532x
> config M537x
> bool "MCF537x"
> depends on !MMU
> + select COLDFIRE_TIMERS
> select M53xx
> select HAVE_CACHE_CB
> help
> @@ -254,6 +262,7 @@ config M5407
> bool "MCF5407"
> depends on !MMU
> select COLDFIRE_SW_A7
> + select COLDFIRE_TIMERS
> select HAVE_CACHE_CB
> select HAVE_MBAR
> select CPU_NO_EFFICIENT_FFS
> @@ -263,6 +272,7 @@ config M5407
> config M547x
> bool "MCF547x"
> select M54xx
> + select COLDFIRE_SLTIMERS
> select MMU_COLDFIRE if MMU
> select FPU if MMU
> select HAVE_CACHE_CB
> @@ -273,6 +283,7 @@ config M547x
>
> config M548x
> bool "MCF548x"
> + select COLDFIRE_SLTIMERS
> select MMU_COLDFIRE if MMU
> select FPU if MMU
> select M54xx
> @@ -284,8 +295,8 @@ config M548x
>
> config M5441x
> bool "MCF5441x"
> + select COLDFIRE_PIT_TIMER
> select MMU_COLDFIRE if MMU
> - select GENERIC_CLOCKEVENTS
> select HAVE_CACHE_CB
> help
> Freescale Coldfire 54410/54415/54416/54417/54418 processor support.
> @@ -302,6 +313,18 @@ config M54xx
> select HAVE_PCI
> bool
>
> +config COLDFIRE_PIT_TIMER
> + bool
> + select GENERIC_CLOCKEVENTS
> +
> +config COLDFIRE_TIMERS
> + bool
> + select LEGACY_TIMER_TICK
> +
> +config COLDFIRE_SLTIMERS
> + bool
> + select LEGACY_TIMER_TICK
> +
> endif # COLDFIRE
>
>
> diff --git a/arch/m68k/coldfire/Makefile b/arch/m68k/coldfire/Makefile
> index 573eabca1a3a..a3e18d73d8b8 100644
> --- a/arch/m68k/coldfire/Makefile
> +++ b/arch/m68k/coldfire/Makefile
> @@ -16,20 +16,24 @@
> asflags-$(CONFIG_FULLDEBUG) := -DDEBUGGER_COMPATIBLE_CACHE=1
>
> obj-$(CONFIG_COLDFIRE) += cache.o clk.o device.o dma.o entry.o vectors.o
> -obj-$(CONFIG_M5206) += m5206.o timers.o intc.o reset.o
> -obj-$(CONFIG_M5206e) += m5206.o timers.o intc.o reset.o
> -obj-$(CONFIG_M520x) += m520x.o pit.o intc-simr.o reset.o
> -obj-$(CONFIG_M523x) += m523x.o pit.o dma_timer.o intc-2.o reset.o
> -obj-$(CONFIG_M5249) += m5249.o timers.o intc.o intc-5249.o reset.o
> -obj-$(CONFIG_M525x) += m525x.o timers.o intc.o intc-525x.o reset.o
> -obj-$(CONFIG_M527x) += m527x.o pit.o intc-2.o reset.o
> -obj-$(CONFIG_M5272) += m5272.o intc-5272.o timers.o
> -obj-$(CONFIG_M528x) += m528x.o pit.o intc-2.o reset.o
> -obj-$(CONFIG_M5307) += m5307.o timers.o intc.o reset.o
> -obj-$(CONFIG_M53xx) += m53xx.o timers.o intc-simr.o reset.o
> -obj-$(CONFIG_M5407) += m5407.o timers.o intc.o reset.o
> -obj-$(CONFIG_M54xx) += m54xx.o sltimers.o intc-2.o
> -obj-$(CONFIG_M5441x) += m5441x.o pit.o intc-simr.o reset.o
> +obj-$(CONFIG_M5206) += m5206.o intc.o reset.o
> +obj-$(CONFIG_M5206e) += m5206.o intc.o reset.o
> +obj-$(CONFIG_M520x) += m520x.o intc-simr.o reset.o
> +obj-$(CONFIG_M523x) += m523x.o dma_timer.o intc-2.o reset.o
> +obj-$(CONFIG_M5249) += m5249.o intc.o intc-5249.o reset.o
> +obj-$(CONFIG_M525x) += m525x.o intc.o intc-525x.o reset.o
> +obj-$(CONFIG_M527x) += m527x.o intc-2.o reset.o
> +obj-$(CONFIG_M5272) += m5272.o intc-5272.o
> +obj-$(CONFIG_M528x) += m528x.o intc-2.o reset.o
> +obj-$(CONFIG_M5307) += m5307.o intc.o reset.o
> +obj-$(CONFIG_M53xx) += m53xx.o intc-simr.o reset.o
> +obj-$(CONFIG_M5407) += m5407.o intc.o reset.o
> +obj-$(CONFIG_M54xx) += m54xx.o intc-2.o
> +obj-$(CONFIG_M5441x) += m5441x.o intc-simr.o reset.o
> +
> +obj-$(CONFIG_COLDFIRE_PIT_TIMER) += pit.o
> +obj-$(CONFIG_COLDFIRE_TIMERS) += timers.o
> +obj-$(CONFIG_COLDFIRE_SLTIMERS) += sltimers.o
>
> obj-$(CONFIG_NETtel) += nettel.o
> obj-$(CONFIG_CLEOPATRA) += nettel.o
> diff --git a/arch/m68k/coldfire/sltimers.c b/arch/m68k/coldfire/sltimers.c
> index 5ab81c9c552d..25a1319f3cb8 100644
> --- a/arch/m68k/coldfire/sltimers.c
> +++ b/arch/m68k/coldfire/sltimers.c
> @@ -83,14 +83,13 @@ void mcfslt_profile_init(void)
> static u32 mcfslt_cycles_per_jiffy;
> static u32 mcfslt_cnt;
>
> -static irq_handler_t timer_interrupt;
> -
> static irqreturn_t mcfslt_tick(int irq, void *dummy)
> {
> /* Reset Slice Timer 0 */
> __raw_writel(MCFSLT_SSR_BE | MCFSLT_SSR_TE, TA(MCFSLT_SSR));
> mcfslt_cnt += mcfslt_cycles_per_jiffy;
> - return timer_interrupt(irq, dummy);
> + legacy_timer_tick(1);
> + return IRQ_HANDLED;
> }
>
> static u64 mcfslt_read_clk(struct clocksource *cs)
> @@ -136,7 +135,6 @@ void hw_timer_init(irq_handler_t handler)
> /* initialize mcfslt_cnt knowing that slice timers count down */
> mcfslt_cnt = mcfslt_cycles_per_jiffy;
>
> - timer_interrupt = handler;
> r = request_irq(MCF_IRQ_TIMER, mcfslt_tick, IRQF_TIMER, "timer", NULL);
> if (r) {
> pr_err("Failed to request irq %d (timer): %pe\n", MCF_IRQ_TIMER,
> diff --git a/arch/m68k/coldfire/timers.c b/arch/m68k/coldfire/timers.c
> index b8301fddf901..24b5e2d1b00b 100644
> --- a/arch/m68k/coldfire/timers.c
> +++ b/arch/m68k/coldfire/timers.c
> @@ -48,8 +48,6 @@ void coldfire_profile_init(void);
> static u32 mcftmr_cycles_per_jiffy;
> static u32 mcftmr_cnt;
>
> -static irq_handler_t timer_interrupt;
> -
> /***************************************************************************/
>
> static void init_timer_irq(void)
> @@ -77,7 +75,8 @@ static irqreturn_t mcftmr_tick(int irq, void *dummy)
> __raw_writeb(MCFTIMER_TER_CAP | MCFTIMER_TER_REF, TA(MCFTIMER_TER));
>
> mcftmr_cnt += mcftmr_cycles_per_jiffy;
> - return timer_interrupt(irq, dummy);
> + legacy_timer_tick(1);
> + return IRQ_HANDLED;
> }
>
> /***************************************************************************/
> @@ -126,7 +125,6 @@ void hw_timer_init(irq_handler_t handler)
>
> clocksource_register_hz(&mcftmr_clk, FREQ);
>
> - timer_interrupt = handler;
> init_timer_irq();
> r = request_irq(MCF_IRQ_TIMER, mcftmr_tick, IRQF_TIMER, "timer", NULL);
> if (r) {
>
_______________________________________________
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] 43+ messages in thread* Re: [PATCH 05/13] m68k: coldfire: use legacy_timer_tick()
2020-10-09 12:53 ` Greg Ungerer
@ 2020-10-09 13:23 ` Arnd Bergmann
0 siblings, 0 replies; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-09 13:23 UTC (permalink / raw)
To: Greg Ungerer
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
linux-kernel, Finn Thain, Russell King, James E.J. Bottomley,
linux-m68k, Geert Uytterhoeven, Linux ARM, John Stultz,
Philip Blundell, Thomas Gleixner, Joshua Thompson
On Fri, Oct 9, 2020 at 2:53 PM Greg Ungerer <gerg@linux-m68k.org> wrote:
>
> Hi Arnd,
>
> On 9/10/20 1:46 am, Arnd Bergmann wrote:
> > Replace the indirect function calls in the timer code
> > with direct calls to the newly added legacy_timer_tick()
> > helper for those that have not yet been converted to
> > generic clockevents.
> >
> > This makes the timer code a little more self-contained.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> I tested this series on a couple of different ColdFire parts
> (5208 and 5475) and under QEMU emulating the 5208. All checked
> out good, all worked as expected. So for the ColdFire changes:
>
> Tested-by: Greg Ungerer <gerg@linux-m68k.org>
Awesome, thanks for testing!
Arnd
_______________________________________________
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] 43+ messages in thread
* [PATCH 06/13] m68k: split heartbeat out of timer function
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
` (4 preceding siblings ...)
2020-10-08 15:46 ` [PATCH 05/13] m68k: coldfire: use legacy_timer_tick() Arnd Bergmann
@ 2020-10-08 15:46 ` Arnd Bergmann
2020-10-12 13:14 ` Geert Uytterhoeven
2020-10-08 15:46 ` [PATCH 07/13] m68k: sun3/sun3c: use legacy_timer_tick Arnd Bergmann
` (7 subsequent siblings)
13 siblings, 1 reply; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-08 15:46 UTC (permalink / raw)
To: linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, Arnd Bergmann, linux-ia64,
Stephen Boyd, Helge Deller, Daniel Lezcano, Russell King,
Finn Thain, James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
The heartbeat functionality is mostly separate from the
actual timer interrupt handling, and it is only used on
five platforms.
Split it out into a separate function and call that directly
from the timer irq on those platforms.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/m68k/amiga/config.c | 1 +
arch/m68k/apollo/config.c | 1 +
arch/m68k/atari/time.c | 2 ++
arch/m68k/hp300/time.c | 1 +
arch/m68k/include/asm/machdep.h | 7 +++++++
arch/m68k/kernel/time.c | 7 +++++--
arch/m68k/q40/q40ints.c | 2 ++
7 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/amiga/config.c b/arch/m68k/amiga/config.c
index bee9f240f35d..29f92333119e 100644
--- a/arch/m68k/amiga/config.c
+++ b/arch/m68k/amiga/config.c
@@ -480,6 +480,7 @@ static irqreturn_t ciab_timer_handler(int irq, void *dev_id)
clk_total += jiffy_ticks;
clk_offset = 0;
timer_routine(0, NULL);
+ timer_heartbeat();
return IRQ_HANDLED;
}
diff --git a/arch/m68k/apollo/config.c b/arch/m68k/apollo/config.c
index 762da5d7a415..30915f1a8760 100644
--- a/arch/m68k/apollo/config.c
+++ b/arch/m68k/apollo/config.c
@@ -173,6 +173,7 @@ irqreturn_t dn_timer_int(int irq, void *dev_id)
volatile unsigned char x;
timer_handler(irq, dev_id);
+ timer_heartbeat();
x = *(volatile unsigned char *)(apollo_timer + 3);
x = *(volatile unsigned char *)(apollo_timer + 5);
diff --git a/arch/m68k/atari/time.c b/arch/m68k/atari/time.c
index ce923a523695..ce4a5961ca93 100644
--- a/arch/m68k/atari/time.c
+++ b/arch/m68k/atari/time.c
@@ -21,6 +21,7 @@
#include <linux/export.h>
#include <asm/atariints.h>
+#include <asm/machdep.h>
DEFINE_SPINLOCK(rtc_lock);
EXPORT_SYMBOL_GPL(rtc_lock);
@@ -49,6 +50,7 @@ static irqreturn_t mfp_timer_c_handler(int irq, void *dev_id)
} while (last_timer_count == 1);
clk_total += INT_TICKS;
timer_routine(0, NULL);
+ timer_heartbeat();
local_irq_restore(flags);
return IRQ_HANDLED;
diff --git a/arch/m68k/hp300/time.c b/arch/m68k/hp300/time.c
index bfee13e1d0fe..e3cd938de0f9 100644
--- a/arch/m68k/hp300/time.c
+++ b/arch/m68k/hp300/time.c
@@ -65,6 +65,7 @@ static irqreturn_t hp300_tick(int irq, void *dev_id)
clk_total += INTVAL;
clk_offset = 0;
timer_routine(0, NULL);
+ timer_heartbeat();
local_irq_restore(flags);
/* Turn off the network and SCSI leds */
diff --git a/arch/m68k/include/asm/machdep.h b/arch/m68k/include/asm/machdep.h
index 49bd3266b4b1..e62a39d01ae4 100644
--- a/arch/m68k/include/asm/machdep.h
+++ b/arch/m68k/include/asm/machdep.h
@@ -35,6 +35,13 @@ extern void (*mach_beep) (unsigned int, unsigned int);
/* Hardware clock functions */
extern void hw_timer_init(irq_handler_t handler);
extern unsigned long hw_timer_offset(void);
+#ifdef CONFIG_HEARTBEAT
+extern void timer_heartbeat(void);
+#else
+static inline void timer_heartbeat(void)
+{
+}
+#endif
extern void config_BSP(char *command, int len);
diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
index c2697a4d4ddd..c05cec21b05f 100644
--- a/arch/m68k/kernel/time.c
+++ b/arch/m68k/kernel/time.c
@@ -45,8 +45,12 @@ static irqreturn_t timer_interrupt(int irq, void *dummy)
xtime_update(1);
update_process_times(user_mode(get_irq_regs()));
profile_tick(CPU_PROFILING);
+ return IRQ_HANDLED;
+}
#ifdef CONFIG_HEARTBEAT
+void timer_heartbeat(void)
+{
/* use power LED as a heartbeat instead -- much more useful
for debugging -- based on the version for PReP by Cort */
/* acts like an actual heart beat -- ie thump-thump-pause... */
@@ -68,9 +72,8 @@ static irqreturn_t timer_interrupt(int irq, void *dummy)
dist = period / 4;
}
}
-#endif /* CONFIG_HEARTBEAT */
- return IRQ_HANDLED;
}
+#endif /* CONFIG_HEARTBEAT */
#ifdef CONFIG_M68KCLASSIC
#if !IS_BUILTIN(CONFIG_RTC_DRV_GENERIC)
diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
index 1c696906c159..b01b545a2db0 100644
--- a/arch/m68k/q40/q40ints.c
+++ b/arch/m68k/q40/q40ints.c
@@ -17,6 +17,7 @@
#include <linux/interrupt.h>
#include <linux/irq.h>
+#include <asm/machdep.h>
#include <asm/ptrace.h>
#include <asm/traps.h>
@@ -144,6 +145,7 @@ static irqreturn_t q40_timer_int(int irq, void *dev_id)
local_irq_save(flags);
timer_routine(0, NULL);
+ timer_heartbeat();
local_irq_restore(flags);
}
return IRQ_HANDLED;
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [PATCH 06/13] m68k: split heartbeat out of timer function
2020-10-08 15:46 ` [PATCH 06/13] m68k: split heartbeat out of timer function Arnd Bergmann
@ 2020-10-12 13:14 ` Geert Uytterhoeven
0 siblings, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2020-10-12 13:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
Linux Kernel Mailing List, Finn Thain, Russell King,
James E.J. Bottomley, linux-m68k, Thomas Gleixner, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
On Thu, Oct 8, 2020 at 5:48 PM Arnd Bergmann <arnd@arndb.de> wrote:
> The heartbeat functionality is mostly separate from the
> actual timer interrupt handling, and it is only used on
> five platforms.
>
> Split it out into a separate function and call that directly
> from the timer irq on those platforms.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
And finally (for Amiga):
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] 43+ messages in thread
* [PATCH 07/13] m68k: sun3/sun3c: use legacy_timer_tick
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
` (5 preceding siblings ...)
2020-10-08 15:46 ` [PATCH 06/13] m68k: split heartbeat out of timer function Arnd Bergmann
@ 2020-10-08 15:46 ` Arnd Bergmann
2020-10-12 13:15 ` Geert Uytterhoeven
2020-10-08 15:46 ` [PATCH 08/13] m68k: m68328: use legacy_timer_tick() Arnd Bergmann
` (6 subsequent siblings)
13 siblings, 1 reply; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-08 15:46 UTC (permalink / raw)
To: linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, Arnd Bergmann, linux-ia64,
Stephen Boyd, Helge Deller, Daniel Lezcano, Russell King,
Finn Thain, James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
These two are different from all other machines:
* sun3 does not call timer_routine() but open-codes it
except for the profile_tick() call that appears to
be unintentionally missing.
* sun3x has a commented-out timer irq handler but no
functional timer tick I could find.
Change both to calling the new legacy_timer_tick here,
which includes the call to profile_tick() but does not
fix sun3x as that is still commented out.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/m68k/Kconfig.machine | 2 ++
arch/m68k/sun3/sun3ints.c | 3 +--
arch/m68k/sun3x/time.c | 3 +--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
index 17e8c3a292d7..e3c835440d9a 100644
--- a/arch/m68k/Kconfig.machine
+++ b/arch/m68k/Kconfig.machine
@@ -99,6 +99,7 @@ config HP300
config SUN3X
bool "Sun3x support"
depends on MMU
+ select LEGACY_TIMER_TICK
select MMU_MOTOROLA if MMU
select M68030
help
@@ -126,6 +127,7 @@ config SUN3
depends on MMU
depends on !MMU_MOTOROLA
select MMU_SUN3 if MMU
+ select LEGACY_TIMER_TICK
select NO_DMA
select M68020
help
diff --git a/arch/m68k/sun3/sun3ints.c b/arch/m68k/sun3/sun3ints.c
index a5824abb4a39..41ae422119d3 100644
--- a/arch/m68k/sun3/sun3ints.c
+++ b/arch/m68k/sun3/sun3ints.c
@@ -73,8 +73,7 @@ static irqreturn_t sun3_int5(int irq, void *dev_id)
#ifdef CONFIG_SUN3
intersil_clear();
#endif
- xtime_update(1);
- update_process_times(user_mode(get_irq_regs()));
+ legacy_timer_tick(1);
cnt = kstat_irqs_cpu(irq, 0);
if (!(cnt % 20))
sun3_leds(led_pattern[cnt % 160 / 20]);
diff --git a/arch/m68k/sun3x/time.c b/arch/m68k/sun3x/time.c
index 9163294b0fb6..f6e25fdc008c 100644
--- a/arch/m68k/sun3x/time.c
+++ b/arch/m68k/sun3x/time.c
@@ -77,14 +77,13 @@ int sun3x_hwclk(int set, struct rtc_time *t)
#if 0
static irqreturn_t sun3x_timer_tick(int irq, void *dev_id)
{
- irq_handler_t timer_routine = dev_id;
unsigned long flags;
local_irq_save(flags);
/* Clear the pending interrupt - pulse the enable line low */
disable_irq(5);
enable_irq(5);
- timer_routine(0, NULL);
+ legacy_timer_tick(1);
local_irq_restore(flags);
return IRQ_HANDLED;
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [PATCH 07/13] m68k: sun3/sun3c: use legacy_timer_tick
2020-10-08 15:46 ` [PATCH 07/13] m68k: sun3/sun3c: use legacy_timer_tick Arnd Bergmann
@ 2020-10-12 13:15 ` Geert Uytterhoeven
0 siblings, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2020-10-12 13:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
Linux Kernel Mailing List, Finn Thain, Russell King,
James E.J. Bottomley, linux-m68k, Thomas Gleixner, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
On Thu, Oct 8, 2020 at 5:48 PM Arnd Bergmann <arnd@arndb.de> wrote:
> These two are different from all other machines:
>
> * sun3 does not call timer_routine() but open-codes it
> except for the profile_tick() call that appears to
> be unintentionally missing.
>
> * sun3x has a commented-out timer irq handler but no
> functional timer tick I could find.
>
> Change both to calling the new legacy_timer_tick here,
> which includes the call to profile_tick() but does not
> fix sun3x as that is still commented out.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] 43+ messages in thread
* [PATCH 08/13] m68k: m68328: use legacy_timer_tick()
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
` (6 preceding siblings ...)
2020-10-08 15:46 ` [PATCH 07/13] m68k: sun3/sun3c: use legacy_timer_tick Arnd Bergmann
@ 2020-10-08 15:46 ` Arnd Bergmann
2020-10-12 13:15 ` Geert Uytterhoeven
2020-10-08 15:46 ` [PATCH 09/13] m68k: change remaining timers to legacy_timer_tick Arnd Bergmann
` (5 subsequent siblings)
13 siblings, 1 reply; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-08 15:46 UTC (permalink / raw)
To: linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, Arnd Bergmann, linux-ia64,
Stephen Boyd, Helge Deller, Daniel Lezcano, Russell King,
Finn Thain, James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
A couple of machines share the m68328 timer code that
is based on calling timer_interrupt(). Change these
to the new and slightly more generic legacy_timer_tick()
helper.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/m68k/68000/timers.c | 5 ++---
arch/m68k/Kconfig.machine | 4 ++++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/m68k/68000/timers.c b/arch/m68k/68000/timers.c
index e8dfdd2556a5..3aa006f8e7ea 100644
--- a/arch/m68k/68000/timers.c
+++ b/arch/m68k/68000/timers.c
@@ -52,7 +52,6 @@
#endif
static u32 m68328_tick_cnt;
-static irq_handler_t timer_interrupt;
/***************************************************************************/
@@ -62,7 +61,8 @@ static irqreturn_t hw_tick(int irq, void *dummy)
TSTAT &= 0;
m68328_tick_cnt += TICKS_PER_JIFFY;
- return timer_interrupt(irq, dummy);
+ legacy_timer_tick(1);
+ return IRQ_HANDLED;
}
/***************************************************************************/
@@ -113,7 +113,6 @@ void hw_timer_init(irq_handler_t handler)
/* Enable timer 1 */
TCTL |= TCTL_TEN;
clocksource_register_hz(&m68328_clk, TICKS_PER_JIFFY*HZ);
- timer_interrupt = handler;
}
/***************************************************************************/
diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
index e3c835440d9a..0ff9338b958e 100644
--- a/arch/m68k/Kconfig.machine
+++ b/arch/m68k/Kconfig.machine
@@ -146,6 +146,7 @@ config PILOT
config PILOT3
bool "Pilot 1000/5000, PalmPilot Personal/Pro, or PalmIII support"
depends on M68328
+ select LEGACY_TIMER_TICK
select PILOT
help
Support for the Palm Pilot 1000/5000, Personal/Pro and PalmIII.
@@ -159,18 +160,21 @@ config XCOPILOT_BUGS
config UCSIMM
bool "uCsimm module support"
depends on M68EZ328
+ select LEGACY_TIMER_TICK
help
Support for the Arcturus Networks uCsimm module.
config UCDIMM
bool "uDsimm module support"
depends on M68VZ328
+ select LEGACY_TIMER_TICK
help
Support for the Arcturus Networks uDsimm module.
config DRAGEN2
bool "DragenEngine II board support"
depends on M68VZ328
+ select LEGACY_TIMER_TICK
help
Support for the DragenEngine II board.
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [PATCH 08/13] m68k: m68328: use legacy_timer_tick()
2020-10-08 15:46 ` [PATCH 08/13] m68k: m68328: use legacy_timer_tick() Arnd Bergmann
@ 2020-10-12 13:15 ` Geert Uytterhoeven
2020-10-12 15:30 ` Arnd Bergmann
0 siblings, 1 reply; 43+ messages in thread
From: Geert Uytterhoeven @ 2020-10-12 13:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
Linux Kernel Mailing List, Finn Thain, Russell King,
James E.J. Bottomley, linux-m68k, Thomas Gleixner, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
Hi Arnd,
On Thu, Oct 8, 2020 at 5:48 PM Arnd Bergmann <arnd@arndb.de> wrote:
> A couple of machines share the m68328 timer code that
> is based on calling timer_interrupt(). Change these
> to the new and slightly more generic legacy_timer_tick()
> helper.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks for your patch!
> --- a/arch/m68k/Kconfig.machine
> +++ b/arch/m68k/Kconfig.machine
> @@ -146,6 +146,7 @@ config PILOT
> config PILOT3
> bool "Pilot 1000/5000, PalmPilot Personal/Pro, or PalmIII support"
> depends on M68328
> + select LEGACY_TIMER_TICK
> select PILOT
> help
> Support for the Palm Pilot 1000/5000, Personal/Pro and PalmIII.
> @@ -159,18 +160,21 @@ config XCOPILOT_BUGS
> config UCSIMM
> bool "uCsimm module support"
> depends on M68EZ328
> + select LEGACY_TIMER_TICK
> help
> Support for the Arcturus Networks uCsimm module.
>
> config UCDIMM
> bool "uDsimm module support"
> depends on M68VZ328
> + select LEGACY_TIMER_TICK
> help
> Support for the Arcturus Networks uDsimm module.
>
> config DRAGEN2
> bool "DragenEngine II board support"
> depends on M68VZ328
> + select LEGACY_TIMER_TICK
> help
> Support for the DragenEngine II board.
Given this feature is SoC-specific, not platform-specific, perhaps
it makes sense to move the selects to the M68{,EZ,VZ}328 symbols?
Regardless:
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] 43+ messages in thread* Re: [PATCH 08/13] m68k: m68328: use legacy_timer_tick()
2020-10-12 13:15 ` Geert Uytterhoeven
@ 2020-10-12 15:30 ` Arnd Bergmann
2020-10-12 20:33 ` Geert Uytterhoeven
0 siblings, 1 reply; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-12 15:30 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
Linux Kernel Mailing List, Finn Thain, Russell King,
James E.J. Bottomley, linux-m68k, Thomas Gleixner, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
On Mon, Oct 12, 2020 at 3:15 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Given this feature is SoC-specific, not platform-specific, perhaps
> it makes sense to move the selects to the M68{,EZ,VZ}328 symbols?
>
> Regardless:
> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Ok, folded in the change blow, using one less line. I couldn't figure
out whether
it should just be part of the CONFIG_M68000 instead, which doesn't appear
to have any machine support by itself. The dragonball CPU configuration
looks really odd, because you have to build exactly one of M68{,EZ,VZ}328
into the kernel to get a successful compilation, while Kconfig allows
many other combinations.
Arnd
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index 322a35ef14c6..648054d4f860 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -104,6 +104,7 @@ config M68060
config M68328
bool "MC68328"
depends on !MMU
+ select LEGACY_TIMER_TICK
select M68000
help
Motorola 68328 processor support.
@@ -111,6 +112,7 @@ config M68328
config M68EZ328
bool "MC68EZ328"
depends on !MMU
+ select LEGACY_TIMER_TICK
select M68000
help
Motorola 68EX328 processor support.
@@ -118,6 +120,7 @@ config M68EZ328
config M68VZ328
bool "MC68VZ328"
depends on !MMU
+ select LEGACY_TIMER_TICK
select M68000
help
Motorola 68VZ328 processor support.
diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
index 0ff9338b958e..e3c835440d9a 100644
--- a/arch/m68k/Kconfig.machine
+++ b/arch/m68k/Kconfig.machine
@@ -146,7 +146,6 @@ config PILOT
config PILOT3
bool "Pilot 1000/5000, PalmPilot Personal/Pro, or PalmIII support"
depends on M68328
- select LEGACY_TIMER_TICK
select PILOT
help
Support for the Palm Pilot 1000/5000, Personal/Pro and PalmIII.
@@ -160,21 +159,18 @@ config XCOPILOT_BUGS
config UCSIMM
bool "uCsimm module support"
depends on M68EZ328
- select LEGACY_TIMER_TICK
help
Support for the Arcturus Networks uCsimm module.
config UCDIMM
bool "uDsimm module support"
depends on M68VZ328
- select LEGACY_TIMER_TICK
help
Support for the Arcturus Networks uDsimm module.
config DRAGEN2
bool "DragenEngine II board support"
depends on M68VZ328
- select LEGACY_TIMER_TICK
help
Support for the DragenEngine II board.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [PATCH 08/13] m68k: m68328: use legacy_timer_tick()
2020-10-12 15:30 ` Arnd Bergmann
@ 2020-10-12 20:33 ` Geert Uytterhoeven
0 siblings, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2020-10-12 20:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
Linux Kernel Mailing List, Finn Thain, Russell King,
James E.J. Bottomley, linux-m68k, Thomas Gleixner, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
Hi Arnd,
On Mon, Oct 12, 2020 at 5:31 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Oct 12, 2020 at 3:15 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > Given this feature is SoC-specific, not platform-specific, perhaps
> > it makes sense to move the selects to the M68{,EZ,VZ}328 symbols?
> >
> > Regardless:
> > Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Ok, folded in the change blow, using one less line. I couldn't figure
Thanks, looks good.
> out whether
> it should just be part of the CONFIG_M68000 instead, which doesn't appear
It must definitely not be selected by CONFIG_M68000, as the plain MC68000
is a CPU, not an SoC, and does not have the timer.
> to have any machine support by itself. The dragonball CPU configuration
> looks really odd, because you have to build exactly one of M68{,EZ,VZ}328
> into the kernel to get a successful compilation, while Kconfig allows
> many other combinations.
While CONFIG_M68000 could be used for a "pure" MC68000-based machine,
I believe we don't support any yet.
M68{,EZ,VZ}328 select M68000 as they are SoCs containing a 68000
CPU core.
Other m68k SoCs have a CPU32 core, which is a simplified 68020 CPU core
(hmm, what happened to 68360 support? Oh, removed in 2016, so nothing
selects CPU32 anymore).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] 43+ messages in thread
* [PATCH 09/13] m68k: change remaining timers to legacy_timer_tick
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
` (7 preceding siblings ...)
2020-10-08 15:46 ` [PATCH 08/13] m68k: m68328: use legacy_timer_tick() Arnd Bergmann
@ 2020-10-08 15:46 ` Arnd Bergmann
2020-10-12 13:15 ` Geert Uytterhoeven
2020-10-08 15:46 ` [PATCH 10/13] m68k: remove timer_interrupt() function Arnd Bergmann
` (4 subsequent siblings)
13 siblings, 1 reply; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-08 15:46 UTC (permalink / raw)
To: linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, Arnd Bergmann, linux-ia64,
Stephen Boyd, Helge Deller, Daniel Lezcano, Russell King,
Finn Thain, James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
There are nine more machines that each have their own timer interrupt
calling the m68k timer_interrupt() function through an indirect pointer.
This function is now the same as legacy_timer_tick, so just call that
directly and select the corresponding Kconfig symbol.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/m68k/Kconfig.machine | 9 +++++++++
arch/m68k/amiga/config.c | 6 ++----
arch/m68k/apollo/config.c | 6 ++----
arch/m68k/atari/time.c | 5 ++---
arch/m68k/bvme6000/config.c | 5 ++---
arch/m68k/hp300/time.c | 5 ++---
arch/m68k/mac/via.c | 6 ++----
arch/m68k/mvme147/config.c | 5 ++---
arch/m68k/mvme16x/config.c | 5 ++---
arch/m68k/q40/q40ints.c | 6 ++----
10 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
index 0ff9338b958e..8a4e8bd8aade 100644
--- a/arch/m68k/Kconfig.machine
+++ b/arch/m68k/Kconfig.machine
@@ -7,6 +7,7 @@ config AMIGA
bool "Amiga support"
depends on MMU
select MMU_MOTOROLA if MMU
+ select LEGACY_TIMER_TICK
help
This option enables support for the Amiga series of computers. If
you plan to use this kernel on an Amiga, say Y here and browse the
@@ -17,6 +18,7 @@ config ATARI
depends on MMU
select MMU_MOTOROLA if MMU
select HAVE_ARCH_NVRAM_OPS
+ select LEGACY_TIMER_TICK
help
This option enables support for the 68000-based Atari series of
computers (including the TT, Falcon and Medusa). If you plan to use
@@ -28,6 +30,7 @@ config MAC
depends on MMU
select MMU_MOTOROLA if MMU
select HAVE_ARCH_NVRAM_OPS
+ select LEGACY_TIMER_TICK
help
This option enables support for the Apple Macintosh series of
computers (yes, there is experimental support now, at least for part
@@ -40,6 +43,7 @@ config APOLLO
bool "Apollo support"
depends on MMU
select MMU_MOTOROLA if MMU
+ select LEGACY_TIMER_TICK
help
Say Y here if you want to run Linux on an MC680x0-based Apollo
Domain workstation such as the DN3500.
@@ -58,6 +62,7 @@ config MVME147
bool "MVME147 support"
depends on MMU
depends on VME
+ select LEGACY_TIMER_TICK
help
Say Y to include support for early Motorola VME boards. This will
build a kernel which can run on MVME147 single-board computers. If
@@ -68,6 +73,7 @@ config MVME16x
bool "MVME162, 166 and 167 support"
depends on MMU
depends on VME
+ select LEGACY_TIMER_TICK
help
Say Y to include support for Motorola VME boards. This will build a
kernel which can run on MVME162, MVME166, MVME167, MVME172, and
@@ -79,6 +85,7 @@ config BVME6000
bool "BVME4000 and BVME6000 support"
depends on MMU
depends on VME
+ select LEGACY_TIMER_TICK
help
Say Y to include support for VME boards from BVM Ltd. This will
build a kernel which can run on BVME4000 and BVME6000 boards. If
@@ -89,6 +96,7 @@ config HP300
bool "HP9000/300 and HP9000/400 support"
depends on MMU
select MMU_MOTOROLA if MMU
+ select LEGACY_TIMER_TICK
help
This option enables support for the HP9000/300 and HP9000/400 series
of workstations. Support for these machines is still somewhat
@@ -115,6 +123,7 @@ config Q40
bool "Q40/Q60 support"
depends on MMU
select MMU_MOTOROLA if MMU
+ select LEGACY_TIMER_TICK
help
The Q40 is a Motorola 68040-based successor to the Sinclair QL
manufactured in Germany. There is an official Q40 home page at
diff --git a/arch/m68k/amiga/config.c b/arch/m68k/amiga/config.c
index 29f92333119e..91dc87b86411 100644
--- a/arch/m68k/amiga/config.c
+++ b/arch/m68k/amiga/config.c
@@ -475,11 +475,9 @@ static u32 clk_total, clk_offset;
static irqreturn_t ciab_timer_handler(int irq, void *dev_id)
{
- irq_handler_t timer_routine = dev_id;
-
clk_total += jiffy_ticks;
clk_offset = 0;
- timer_routine(0, NULL);
+ legacy_timer_tick(1);
timer_heartbeat();
return IRQ_HANDLED;
@@ -504,7 +502,7 @@ static void __init amiga_sched_init(irq_handler_t timer_routine)
* SCSI code. We'll have to take a look at this later
*/
if (request_irq(IRQ_AMIGA_CIAB_TA, ciab_timer_handler, IRQF_TIMER,
- "timer", timer_routine))
+ "timer", NULL))
pr_err("Couldn't register timer interrupt\n");
/* start timer */
ciab.cra |= 0x11;
diff --git a/arch/m68k/apollo/config.c b/arch/m68k/apollo/config.c
index 30915f1a8760..17d59fa6b25b 100644
--- a/arch/m68k/apollo/config.c
+++ b/arch/m68k/apollo/config.c
@@ -168,11 +168,9 @@ void __init config_apollo(void)
irqreturn_t dn_timer_int(int irq, void *dev_id)
{
- irq_handler_t timer_handler = dev_id;
-
volatile unsigned char x;
- timer_handler(irq, dev_id);
+ legacy_timer_tick(1);
timer_heartbeat();
x = *(volatile unsigned char *)(apollo_timer + 3);
@@ -199,7 +197,7 @@ void dn_sched_init(irq_handler_t timer_routine)
*(volatile unsigned char *)(apollo_timer + 0x3));
#endif
- if (request_irq(IRQ_APOLLO, dn_timer_int, 0, "time", timer_routine))
+ if (request_irq(IRQ_APOLLO, dn_timer_int, 0, "time", NULL))
pr_err("Couldn't register timer interrupt\n");
}
diff --git a/arch/m68k/atari/time.c b/arch/m68k/atari/time.c
index ce4a5961ca93..36d811ae09ee 100644
--- a/arch/m68k/atari/time.c
+++ b/arch/m68k/atari/time.c
@@ -41,7 +41,6 @@ static u8 last_timer_count;
static irqreturn_t mfp_timer_c_handler(int irq, void *dev_id)
{
- irq_handler_t timer_routine = dev_id;
unsigned long flags;
local_irq_save(flags);
@@ -49,7 +48,7 @@ static irqreturn_t mfp_timer_c_handler(int irq, void *dev_id)
last_timer_count = st_mfp.tim_dt_c;
} while (last_timer_count == 1);
clk_total += INT_TICKS;
- timer_routine(0, NULL);
+ legacy_timer_tick(1);
timer_heartbeat();
local_irq_restore(flags);
@@ -65,7 +64,7 @@ atari_sched_init(irq_handler_t timer_routine)
st_mfp.tim_ct_cd = (st_mfp.tim_ct_cd & 15) | 0x60;
/* install interrupt service routine for MFP Timer C */
if (request_irq(IRQ_MFP_TIMC, mfp_timer_c_handler, IRQF_TIMER, "timer",
- timer_routine))
+ NULL))
pr_err("Couldn't register timer interrupt\n");
clocksource_register_hz(&atari_clk, INT_CLK);
diff --git a/arch/m68k/bvme6000/config.c b/arch/m68k/bvme6000/config.c
index 50f4d01363df..d3f5963021d3 100644
--- a/arch/m68k/bvme6000/config.c
+++ b/arch/m68k/bvme6000/config.c
@@ -165,7 +165,6 @@ static u32 clk_total, clk_offset;
static irqreturn_t bvme6000_timer_int (int irq, void *dev_id)
{
- irq_handler_t timer_routine = dev_id;
unsigned long flags;
volatile RtcPtr_t rtc = (RtcPtr_t)BVME_RTC_BASE;
unsigned char msr;
@@ -175,7 +174,7 @@ static irqreturn_t bvme6000_timer_int (int irq, void *dev_id)
rtc->msr = msr | 0x20; /* Ack the interrupt */
clk_total += RTC_TIMER_CYCLES;
clk_offset = 0;
- timer_routine(0, NULL);
+ legacy_timer_tick(1);
local_irq_restore(flags);
return IRQ_HANDLED;
@@ -198,7 +197,7 @@ void bvme6000_sched_init (irq_handler_t timer_routine)
rtc->msr = 0; /* Ensure timer registers accessible */
if (request_irq(BVME_IRQ_RTC, bvme6000_timer_int, IRQF_TIMER, "timer",
- timer_routine))
+ NULL))
panic ("Couldn't register timer int");
rtc->t1cr_omr = 0x04; /* Mode 2, ext clk */
diff --git a/arch/m68k/hp300/time.c b/arch/m68k/hp300/time.c
index e3cd938de0f9..011fc2e5a68a 100644
--- a/arch/m68k/hp300/time.c
+++ b/arch/m68k/hp300/time.c
@@ -55,7 +55,6 @@ static u32 clk_total, clk_offset;
static irqreturn_t hp300_tick(int irq, void *dev_id)
{
- irq_handler_t timer_routine = dev_id;
unsigned long flags;
unsigned long tmp;
@@ -64,7 +63,7 @@ static irqreturn_t hp300_tick(int irq, void *dev_id)
asm volatile ("movpw %1@(5),%0" : "=d" (tmp) : "a" (CLOCKBASE));
clk_total += INTVAL;
clk_offset = 0;
- timer_routine(0, NULL);
+ legacy_timer_tick(1);
timer_heartbeat();
local_irq_restore(flags);
@@ -106,7 +105,7 @@ void __init hp300_sched_init(irq_handler_t vector)
asm volatile(" movpw %0,%1@(5)" : : "d" (INTVAL), "a" (CLOCKBASE));
- if (request_irq(IRQ_AUTO_6, hp300_tick, IRQF_TIMER, "timer tick", vector))
+ if (request_irq(IRQ_AUTO_6, hp300_tick, IRQF_TIMER, "timer tick", NULL))
pr_err("Couldn't register timer interrupt\n");
out_8(CLOCKBASE + CLKCR2, 0x1); /* select CR1 */
diff --git a/arch/m68k/mac/via.c b/arch/m68k/mac/via.c
index ac77d73af19a..ba444e1774b8 100644
--- a/arch/m68k/mac/via.c
+++ b/arch/m68k/mac/via.c
@@ -602,11 +602,9 @@ static u32 clk_total, clk_offset;
static irqreturn_t via_timer_handler(int irq, void *dev_id)
{
- irq_handler_t timer_routine = dev_id;
-
clk_total += VIA_TIMER_CYCLES;
clk_offset = 0;
- timer_routine(0, NULL);
+ legacy_timer_tick(1);
return IRQ_HANDLED;
}
@@ -614,7 +612,7 @@ static irqreturn_t via_timer_handler(int irq, void *dev_id)
void __init via_init_clock(irq_handler_t timer_routine)
{
if (request_irq(IRQ_MAC_TIMER_1, via_timer_handler, IRQF_TIMER, "timer",
- timer_routine)) {
+ NULL)) {
pr_err("Couldn't register %s interrupt\n", "timer");
return;
}
diff --git a/arch/m68k/mvme147/config.c b/arch/m68k/mvme147/config.c
index 490700aa2212..5dabbc915b8d 100644
--- a/arch/m68k/mvme147/config.c
+++ b/arch/m68k/mvme147/config.c
@@ -112,14 +112,13 @@ static u32 clk_total;
static irqreturn_t mvme147_timer_int (int irq, void *dev_id)
{
- irq_handler_t timer_routine = dev_id;
unsigned long flags;
local_irq_save(flags);
m147_pcc->t1_int_cntrl = PCC_TIMER_INT_CLR;
m147_pcc->t1_cntrl = PCC_TIMER_CLR_OVF;
clk_total += PCC_TIMER_CYCLES;
- timer_routine(0, NULL);
+ legacy_timer_tick(1);
local_irq_restore(flags);
return IRQ_HANDLED;
@@ -129,7 +128,7 @@ static irqreturn_t mvme147_timer_int (int irq, void *dev_id)
void mvme147_sched_init (irq_handler_t timer_routine)
{
if (request_irq(PCC_IRQ_TIMER1, mvme147_timer_int, IRQF_TIMER,
- "timer 1", timer_routine))
+ "timer 1", NULL))
pr_err("Couldn't register timer interrupt\n");
/* Init the clock with a value */
diff --git a/arch/m68k/mvme16x/config.c b/arch/m68k/mvme16x/config.c
index 5b86d10e0f84..ae9bb7fda161 100644
--- a/arch/m68k/mvme16x/config.c
+++ b/arch/m68k/mvme16x/config.c
@@ -372,14 +372,13 @@ static u32 clk_total;
static irqreturn_t mvme16x_timer_int (int irq, void *dev_id)
{
- irq_handler_t timer_routine = dev_id;
unsigned long flags;
local_irq_save(flags);
out_8(PCCTIC1, in_8(PCCTIC1) | PCCTIC1_INT_CLR);
out_8(PCCTOVR1, PCCTOVR1_OVR_CLR);
clk_total += PCC_TIMER_CYCLES;
- timer_routine(0, NULL);
+ legacy_timer_tick(1);
local_irq_restore(flags);
return IRQ_HANDLED;
@@ -396,7 +395,7 @@ void mvme16x_sched_init (irq_handler_t timer_routine)
out_8(PCCTOVR1, in_8(PCCTOVR1) | PCCTOVR1_TIC_EN | PCCTOVR1_COC_EN);
out_8(PCCTIC1, PCCTIC1_INT_EN | 6);
if (request_irq(MVME16x_IRQ_TIMER, mvme16x_timer_int, IRQF_TIMER, "timer",
- timer_routine))
+ NULL))
panic ("Couldn't register timer int");
clocksource_register_hz(&mvme16x_clk, PCC_TIMER_CLOCK_FREQ);
diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
index b01b545a2db0..4c6c409053fd 100644
--- a/arch/m68k/q40/q40ints.c
+++ b/arch/m68k/q40/q40ints.c
@@ -130,8 +130,6 @@ void q40_mksound(unsigned int hz, unsigned int ticks)
static irqreturn_t q40_timer_int(int irq, void *dev_id)
{
- irq_handler_t timer_routine = dev_id;
-
ql_ticks = ql_ticks ? 0 : 1;
if (sound_ticks) {
unsigned char sval=(sound_ticks & 1) ? 128-SVOL : 128+SVOL;
@@ -144,7 +142,7 @@ static irqreturn_t q40_timer_int(int irq, void *dev_id)
unsigned long flags;
local_irq_save(flags);
- timer_routine(0, NULL);
+ legacy_timer_tick(1);
timer_heartbeat();
local_irq_restore(flags);
}
@@ -157,7 +155,7 @@ void q40_sched_init (irq_handler_t timer_routine)
timer_irq = Q40_IRQ_FRAME;
- if (request_irq(timer_irq, q40_timer_int, 0, "timer", timer_routine))
+ if (request_irq(timer_irq, q40_timer_int, 0, "timer", NULL))
panic("Couldn't register timer int");
master_outb(-1, FRAME_CLEAR_REG);
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [PATCH 09/13] m68k: change remaining timers to legacy_timer_tick
2020-10-08 15:46 ` [PATCH 09/13] m68k: change remaining timers to legacy_timer_tick Arnd Bergmann
@ 2020-10-12 13:15 ` Geert Uytterhoeven
0 siblings, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2020-10-12 13:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
Linux Kernel Mailing List, Finn Thain, Russell King,
James E.J. Bottomley, linux-m68k, Thomas Gleixner, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
On Thu, Oct 8, 2020 at 5:48 PM Arnd Bergmann <arnd@arndb.de> wrote:
> There are nine more machines that each have their own timer interrupt
> calling the m68k timer_interrupt() function through an indirect pointer.
>
> This function is now the same as legacy_timer_tick, so just call that
> directly and select the corresponding Kconfig symbol.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
And finally (for Amiga and Atari/ARAnyM):
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] 43+ messages in thread
* [PATCH 10/13] m68k: remove timer_interrupt() function
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
` (8 preceding siblings ...)
2020-10-08 15:46 ` [PATCH 09/13] m68k: change remaining timers to legacy_timer_tick Arnd Bergmann
@ 2020-10-08 15:46 ` Arnd Bergmann
2020-10-12 13:15 ` Geert Uytterhoeven
2020-10-08 15:46 ` [PATCH 11/13] timekeeping: remove xtime_update Arnd Bergmann
` (3 subsequent siblings)
13 siblings, 1 reply; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-08 15:46 UTC (permalink / raw)
To: linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, Arnd Bergmann, linux-ia64,
Stephen Boyd, Helge Deller, Daniel Lezcano, Russell King,
Finn Thain, James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
This gets passed to a number of init functions, but is
ignored everywhere, so remove the function and change the
mach_sched_init callback to take no arguments.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/m68k/68000/timers.c | 2 +-
arch/m68k/amiga/config.c | 4 ++--
arch/m68k/apollo/config.c | 4 ++--
arch/m68k/atari/config.c | 2 +-
arch/m68k/atari/time.c | 2 +-
arch/m68k/bvme6000/config.c | 4 ++--
arch/m68k/coldfire/pit.c | 2 +-
arch/m68k/coldfire/sltimers.c | 2 +-
arch/m68k/coldfire/timers.c | 2 +-
arch/m68k/hp300/time.c | 2 +-
arch/m68k/hp300/time.h | 2 +-
arch/m68k/include/asm/machdep.h | 5 ++---
arch/m68k/kernel/setup_mm.c | 2 +-
arch/m68k/kernel/setup_no.c | 2 +-
arch/m68k/kernel/time.c | 15 +--------------
arch/m68k/mac/config.c | 6 +++---
arch/m68k/mac/via.c | 2 +-
arch/m68k/mvme147/config.c | 4 ++--
arch/m68k/mvme16x/config.c | 4 ++--
arch/m68k/q40/config.c | 2 +-
arch/m68k/q40/q40ints.c | 2 +-
arch/m68k/sun3/config.c | 4 ++--
arch/m68k/sun3x/time.c | 2 +-
arch/m68k/sun3x/time.h | 2 +-
24 files changed, 33 insertions(+), 47 deletions(-)
diff --git a/arch/m68k/68000/timers.c b/arch/m68k/68000/timers.c
index 3aa006f8e7ea..0d0417cebc7f 100644
--- a/arch/m68k/68000/timers.c
+++ b/arch/m68k/68000/timers.c
@@ -91,7 +91,7 @@ static struct clocksource m68328_clk = {
/***************************************************************************/
-void hw_timer_init(irq_handler_t handler)
+void hw_timer_init(void)
{
int ret;
diff --git a/arch/m68k/amiga/config.c b/arch/m68k/amiga/config.c
index 91dc87b86411..50e9a2c6523e 100644
--- a/arch/m68k/amiga/config.c
+++ b/arch/m68k/amiga/config.c
@@ -92,7 +92,7 @@ static char *amiga_models[] __initdata = {
static char amiga_model_name[13] = "Amiga ";
-static void amiga_sched_init(irq_handler_t handler);
+static void amiga_sched_init(void);
static void amiga_get_model(char *model);
static void amiga_get_hardware_list(struct seq_file *m);
extern void amiga_mksound(unsigned int count, unsigned int ticks);
@@ -483,7 +483,7 @@ static irqreturn_t ciab_timer_handler(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static void __init amiga_sched_init(irq_handler_t timer_routine)
+static void __init amiga_sched_init(void)
{
static struct resource sched_res = {
.name = "timer", .start = 0x00bfd400, .end = 0x00bfd5ff,
diff --git a/arch/m68k/apollo/config.c b/arch/m68k/apollo/config.c
index 17d59fa6b25b..36c2cd97f228 100644
--- a/arch/m68k/apollo/config.c
+++ b/arch/m68k/apollo/config.c
@@ -26,7 +26,7 @@ u_long cpuctrl_physaddr;
u_long timer_physaddr;
u_long apollo_model;
-extern void dn_sched_init(irq_handler_t handler);
+extern void dn_sched_init(void);
extern void dn_init_IRQ(void);
extern int dn_dummy_hwclk(int, struct rtc_time *);
extern void dn_dummy_reset(void);
@@ -179,7 +179,7 @@ irqreturn_t dn_timer_int(int irq, void *dev_id)
return IRQ_HANDLED;
}
-void dn_sched_init(irq_handler_t timer_routine)
+void dn_sched_init(void)
{
/* program timer 1 */
*(volatile unsigned char *)(apollo_timer + 3) = 0x01;
diff --git a/arch/m68k/atari/config.c b/arch/m68k/atari/config.c
index 7ec3161e8517..50fda4bea521 100644
--- a/arch/m68k/atari/config.c
+++ b/arch/m68k/atari/config.c
@@ -77,7 +77,7 @@ static void atari_heartbeat(int on);
#endif
/* atari specific timer functions (in time.c) */
-extern void atari_sched_init(irq_handler_t);
+extern void atari_sched_init(void);
extern int atari_mste_hwclk (int, struct rtc_time *);
extern int atari_tt_hwclk (int, struct rtc_time *);
diff --git a/arch/m68k/atari/time.c b/arch/m68k/atari/time.c
index 36d811ae09ee..1068670cb741 100644
--- a/arch/m68k/atari/time.c
+++ b/arch/m68k/atari/time.c
@@ -56,7 +56,7 @@ static irqreturn_t mfp_timer_c_handler(int irq, void *dev_id)
}
void __init
-atari_sched_init(irq_handler_t timer_routine)
+atari_sched_init(void)
{
/* set Timer C data Register */
st_mfp.tim_dt_c = INT_TICKS;
diff --git a/arch/m68k/bvme6000/config.c b/arch/m68k/bvme6000/config.c
index d3f5963021d3..b37f8ce034e7 100644
--- a/arch/m68k/bvme6000/config.c
+++ b/arch/m68k/bvme6000/config.c
@@ -38,7 +38,7 @@
#include <asm/bvme6000hw.h>
static void bvme6000_get_model(char *model);
-extern void bvme6000_sched_init(irq_handler_t handler);
+extern void bvme6000_sched_init(void);
extern int bvme6000_hwclk (int, struct rtc_time *);
extern void bvme6000_reset (void);
void bvme6000_set_vectors (void);
@@ -189,7 +189,7 @@ static irqreturn_t bvme6000_timer_int (int irq, void *dev_id)
* so divide by 8 to get the microsecond result.
*/
-void bvme6000_sched_init (irq_handler_t timer_routine)
+void bvme6000_sched_init (void)
{
volatile RtcPtr_t rtc = (RtcPtr_t)BVME_RTC_BASE;
unsigned char msr = rtc->msr & 0xc0;
diff --git a/arch/m68k/coldfire/pit.c b/arch/m68k/coldfire/pit.c
index fd1d9c915daa..855d0af47097 100644
--- a/arch/m68k/coldfire/pit.c
+++ b/arch/m68k/coldfire/pit.c
@@ -136,7 +136,7 @@ static struct clocksource pit_clk = {
/***************************************************************************/
-void hw_timer_init(irq_handler_t handler)
+void hw_timer_init(void)
{
int ret;
diff --git a/arch/m68k/coldfire/sltimers.c b/arch/m68k/coldfire/sltimers.c
index 25a1319f3cb8..f9d572ee63db 100644
--- a/arch/m68k/coldfire/sltimers.c
+++ b/arch/m68k/coldfire/sltimers.c
@@ -118,7 +118,7 @@ static struct clocksource mcfslt_clk = {
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
-void hw_timer_init(irq_handler_t handler)
+void hw_timer_init(void)
{
int r;
diff --git a/arch/m68k/coldfire/timers.c b/arch/m68k/coldfire/timers.c
index 24b5e2d1b00b..05a42d8e0a59 100644
--- a/arch/m68k/coldfire/timers.c
+++ b/arch/m68k/coldfire/timers.c
@@ -107,7 +107,7 @@ static struct clocksource mcftmr_clk = {
/***************************************************************************/
-void hw_timer_init(irq_handler_t handler)
+void hw_timer_init(void)
{
int r;
diff --git a/arch/m68k/hp300/time.c b/arch/m68k/hp300/time.c
index 011fc2e5a68a..1d1b7b3b5dd4 100644
--- a/arch/m68k/hp300/time.c
+++ b/arch/m68k/hp300/time.c
@@ -98,7 +98,7 @@ static u64 hp300_read_clk(struct clocksource *cs)
return ticks;
}
-void __init hp300_sched_init(irq_handler_t vector)
+void __init hp300_sched_init(void)
{
out_8(CLOCKBASE + CLKCR2, 0x1); /* select CR1 */
out_8(CLOCKBASE + CLKCR1, 0x1); /* reset */
diff --git a/arch/m68k/hp300/time.h b/arch/m68k/hp300/time.h
index 1d77b55cc72a..040a098b7db1 100644
--- a/arch/m68k/hp300/time.h
+++ b/arch/m68k/hp300/time.h
@@ -1 +1 @@
-extern void hp300_sched_init(irq_handler_t vector);
+extern void hp300_sched_init(void);
diff --git a/arch/m68k/include/asm/machdep.h b/arch/m68k/include/asm/machdep.h
index e62a39d01ae4..7181ed43ba22 100644
--- a/arch/m68k/include/asm/machdep.h
+++ b/arch/m68k/include/asm/machdep.h
@@ -12,7 +12,7 @@ struct rtc_time;
struct rtc_pll_info;
struct buffer_head;
-extern void (*mach_sched_init) (irq_handler_t handler);
+extern void (*mach_sched_init) (void);
/* machine dependent irq functions */
extern void (*mach_init_IRQ) (void);
extern void (*mach_get_model) (char *model);
@@ -33,8 +33,7 @@ extern void (*mach_l2_flush) (int);
extern void (*mach_beep) (unsigned int, unsigned int);
/* Hardware clock functions */
-extern void hw_timer_init(irq_handler_t handler);
-extern unsigned long hw_timer_offset(void);
+extern void hw_timer_init(void);
#ifdef CONFIG_HEARTBEAT
extern void timer_heartbeat(void);
#else
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index ab8aa7be260f..0628733bfb88 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -82,7 +82,7 @@ static struct m68k_mem_info m68k_ramdisk __initdata;
static char m68k_command_line[CL_SIZE] __initdata;
-void (*mach_sched_init) (irq_handler_t handler) __initdata = NULL;
+void (*mach_sched_init) (void) __initdata = NULL;
/* machine dependent irq functions */
void (*mach_init_IRQ) (void) __initdata = NULL;
void (*mach_get_model) (char *model);
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index f66f4b1d062e..e377b4219528 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -49,7 +49,7 @@ EXPORT_SYMBOL(memory_end);
char __initdata command_line[COMMAND_LINE_SIZE];
/* machine dependent timer functions */
-void (*mach_sched_init)(irq_handler_t handler) __initdata = NULL;
+void (*mach_sched_init)(void) __initdata = NULL;
int (*mach_hwclk) (int, struct rtc_time*);
/* machine dependent reboot functions */
diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
index c05cec21b05f..340ffeea0a9d 100644
--- a/arch/m68k/kernel/time.c
+++ b/arch/m68k/kernel/time.c
@@ -35,19 +35,6 @@
unsigned long (*mach_random_get_entropy)(void);
EXPORT_SYMBOL_GPL(mach_random_get_entropy);
-
-/*
- * timer_interrupt() needs to keep up the real-time clock,
- * as well as call the "xtime_update()" routine every clocktick
- */
-static irqreturn_t timer_interrupt(int irq, void *dummy)
-{
- xtime_update(1);
- update_process_times(user_mode(get_irq_regs()));
- profile_tick(CPU_PROFILING);
- return IRQ_HANDLED;
-}
-
#ifdef CONFIG_HEARTBEAT
void timer_heartbeat(void)
{
@@ -157,5 +144,5 @@ module_init(rtc_init);
void __init time_init(void)
{
- mach_sched_init(timer_interrupt);
+ mach_sched_init();
}
diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index 0ac53d87493c..0dbe0fedd826 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -58,7 +58,7 @@ extern int mac_hwclk(int, struct rtc_time *);
extern void iop_preinit(void);
extern void iop_init(void);
extern void via_init(void);
-extern void via_init_clock(irq_handler_t func);
+extern void via_init_clock(void);
extern void oss_init(void);
extern void psc_init(void);
extern void baboon_init(void);
@@ -69,9 +69,9 @@ static void mac_get_model(char *str);
static void mac_identify(void);
static void mac_report_hardware(void);
-static void __init mac_sched_init(irq_handler_t vector)
+static void __init mac_sched_init(void)
{
- via_init_clock(vector);
+ via_init_clock();
}
/*
diff --git a/arch/m68k/mac/via.c b/arch/m68k/mac/via.c
index ba444e1774b8..8ad734e3c934 100644
--- a/arch/m68k/mac/via.c
+++ b/arch/m68k/mac/via.c
@@ -609,7 +609,7 @@ static irqreturn_t via_timer_handler(int irq, void *dev_id)
return IRQ_HANDLED;
}
-void __init via_init_clock(irq_handler_t timer_routine)
+void __init via_init_clock(void)
{
if (request_irq(IRQ_MAC_TIMER_1, via_timer_handler, IRQF_TIMER, "timer",
NULL)) {
diff --git a/arch/m68k/mvme147/config.c b/arch/m68k/mvme147/config.c
index 5dabbc915b8d..4fc43b5d7545 100644
--- a/arch/m68k/mvme147/config.c
+++ b/arch/m68k/mvme147/config.c
@@ -37,7 +37,7 @@
static void mvme147_get_model(char *model);
-extern void mvme147_sched_init(irq_handler_t handler);
+extern void mvme147_sched_init(void);
extern int mvme147_hwclk (int, struct rtc_time *);
extern void mvme147_reset (void);
@@ -125,7 +125,7 @@ static irqreturn_t mvme147_timer_int (int irq, void *dev_id)
}
-void mvme147_sched_init (irq_handler_t timer_routine)
+void mvme147_sched_init (void)
{
if (request_irq(PCC_IRQ_TIMER1, mvme147_timer_int, IRQF_TIMER,
"timer 1", NULL))
diff --git a/arch/m68k/mvme16x/config.c b/arch/m68k/mvme16x/config.c
index ae9bb7fda161..18e158887ec9 100644
--- a/arch/m68k/mvme16x/config.c
+++ b/arch/m68k/mvme16x/config.c
@@ -43,7 +43,7 @@ extern t_bdid mvme_bdid;
static MK48T08ptr_t volatile rtc = (MK48T08ptr_t)MVME_RTC_BASE;
static void mvme16x_get_model(char *model);
-extern void mvme16x_sched_init(irq_handler_t handler);
+extern void mvme16x_sched_init(void);
extern int mvme16x_hwclk (int, struct rtc_time *);
extern void mvme16x_reset (void);
@@ -384,7 +384,7 @@ static irqreturn_t mvme16x_timer_int (int irq, void *dev_id)
return IRQ_HANDLED;
}
-void mvme16x_sched_init (irq_handler_t timer_routine)
+void mvme16x_sched_init(void)
{
uint16_t brdno = be16_to_cpu(mvme_bdid.brdno);
int irq;
diff --git a/arch/m68k/q40/config.c b/arch/m68k/q40/config.c
index 4627de3c0603..55f76f0fa29b 100644
--- a/arch/m68k/q40/config.c
+++ b/arch/m68k/q40/config.c
@@ -37,7 +37,7 @@
extern void q40_init_IRQ(void);
static void q40_get_model(char *model);
-extern void q40_sched_init(irq_handler_t handler);
+extern void q40_sched_init(void);
static int q40_hwclk(int, struct rtc_time *);
static unsigned int q40_get_ss(void);
diff --git a/arch/m68k/q40/q40ints.c b/arch/m68k/q40/q40ints.c
index 4c6c409053fd..6886a5d0007b 100644
--- a/arch/m68k/q40/q40ints.c
+++ b/arch/m68k/q40/q40ints.c
@@ -149,7 +149,7 @@ static irqreturn_t q40_timer_int(int irq, void *dev_id)
return IRQ_HANDLED;
}
-void q40_sched_init (irq_handler_t timer_routine)
+void q40_sched_init (void)
{
int timer_irq;
diff --git a/arch/m68k/sun3/config.c b/arch/m68k/sun3/config.c
index 7204c0ea0dc7..f7dd47232b6c 100644
--- a/arch/m68k/sun3/config.c
+++ b/arch/m68k/sun3/config.c
@@ -36,7 +36,7 @@
char sun3_reserved_pmeg[SUN3_PMEGS_NUM];
-static void sun3_sched_init(irq_handler_t handler);
+static void sun3_sched_init(void);
extern void sun3_get_model (char* model);
extern int sun3_hwclk(int set, struct rtc_time *t);
@@ -151,7 +151,7 @@ void __init config_sun3(void)
sun3_bootmem_alloc(memory_start, memory_end);
}
-static void __init sun3_sched_init(irq_handler_t timer_routine)
+static void __init sun3_sched_init(void)
{
sun3_disable_interrupts();
intersil_clock->cmd_reg=(INTERSIL_RUN|INTERSIL_INT_DISABLE|INTERSIL_24H_MODE);
diff --git a/arch/m68k/sun3x/time.c b/arch/m68k/sun3x/time.c
index f6e25fdc008c..a2c97821faf2 100644
--- a/arch/m68k/sun3x/time.c
+++ b/arch/m68k/sun3x/time.c
@@ -90,7 +90,7 @@ static irqreturn_t sun3x_timer_tick(int irq, void *dev_id)
}
#endif
-void __init sun3x_sched_init(irq_handler_t vector)
+void __init sun3x_sched_init(void)
{
sun3_disable_interrupts();
diff --git a/arch/m68k/sun3x/time.h b/arch/m68k/sun3x/time.h
index 86ce78bb3c28..7cfff22e4986 100644
--- a/arch/m68k/sun3x/time.h
+++ b/arch/m68k/sun3x/time.h
@@ -3,7 +3,7 @@
#define SUN3X_TIME_H
extern int sun3x_hwclk(int set, struct rtc_time *t);
-void sun3x_sched_init(irq_handler_t vector);
+void sun3x_sched_init(void);
struct mostek_dt {
volatile unsigned char csr;
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [PATCH 10/13] m68k: remove timer_interrupt() function
2020-10-08 15:46 ` [PATCH 10/13] m68k: remove timer_interrupt() function Arnd Bergmann
@ 2020-10-12 13:15 ` Geert Uytterhoeven
0 siblings, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2020-10-12 13:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
Linux Kernel Mailing List, Finn Thain, Russell King,
James E.J. Bottomley, linux-m68k, Thomas Gleixner, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
Hi Arnd,
On Thu, Oct 8, 2020 at 5:48 PM Arnd Bergmann <arnd@arndb.de> wrote:
> This gets passed to a number of init functions, but is
> ignored everywhere, so remove the function and change the
> mach_sched_init callback to take no arguments.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
And finally (for Amiga and Atari/ARAnyM):
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
> --- a/arch/m68k/include/asm/machdep.h
> +++ b/arch/m68k/include/asm/machdep.h
> @@ -33,8 +33,7 @@ extern void (*mach_l2_flush) (int);
> extern void (*mach_beep) (unsigned int, unsigned int);
>
> /* Hardware clock functions */
> -extern void hw_timer_init(irq_handler_t handler);
> -extern unsigned long hw_timer_offset(void);
Yeah, this never-used prototype, which entered through the nommu merge,
can go. But that's not really related to this patch.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] 43+ messages in thread
* [PATCH 11/13] timekeeping: remove xtime_update
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
` (9 preceding siblings ...)
2020-10-08 15:46 ` [PATCH 10/13] m68k: remove timer_interrupt() function Arnd Bergmann
@ 2020-10-08 15:46 ` Arnd Bergmann
2020-10-12 13:15 ` Geert Uytterhoeven
2020-10-08 15:46 ` [PATCH 12/13] timekeeping: default GENERIC_CLOCKEVENTS to enabled Arnd Bergmann
` (2 subsequent siblings)
13 siblings, 1 reply; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-08 15:46 UTC (permalink / raw)
To: linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, Arnd Bergmann, linux-ia64,
Stephen Boyd, Helge Deller, Daniel Lezcano, Russell King,
Finn Thain, James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
There are no more users of xtime_update aside from legacy_timer_tick(),
so fold it into that function and remove the declaration.
update_process_times() is now only called inside of the kernel/time/
code, so the declaration can be moved there.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/timekeeping.h | 4 +---
kernel/time/tick-legacy.c | 22 ++++++++++++++++++++--
kernel/time/timekeeping.c | 16 ----------------
kernel/time/timekeeping.h | 1 +
4 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 3670cb1670ff..a8bef0ffcbdd 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -9,9 +9,7 @@
void timekeeping_init(void);
extern int timekeeping_suspended;
-/* Architecture timer tick functions: */
-extern void update_process_times(int user);
-extern void xtime_update(unsigned long ticks);
+/* Architecture timer tick functions */
extern void legacy_timer_tick(unsigned long ticks);
/*
diff --git a/kernel/time/tick-legacy.c b/kernel/time/tick-legacy.c
index 73c5a0af4743..af225b32f5b3 100644
--- a/kernel/time/tick-legacy.c
+++ b/kernel/time/tick-legacy.c
@@ -10,10 +10,28 @@
#include "tick-internal.h"
+/**
+ * legacy_timer_tick() - advances the timekeeping infrastructure
+ * @ticks: number of ticks, that have elapsed since the last call.
+ *
+ * This is used by platforms that have not been converted to
+ * generic clockevents.
+ *
+ * If 'ticks' is zero, the CPU is not handling timekeeping, so
+ * only perform process accounting and profiling.
+ *
+ * Must be called with interrupts disabled.
+ */
void legacy_timer_tick(unsigned long ticks)
{
- if (ticks)
- xtime_update(ticks);
+ if (ticks) {
+ raw_spin_lock(&jiffies_lock);
+ write_seqcount_begin(&jiffies_seq);
+ do_timer(ticks);
+ write_seqcount_end(&jiffies_seq);
+ raw_spin_unlock(&jiffies_lock);
+ update_wall_time();
+ }
update_process_times(user_mode(get_irq_regs()));
profile_tick(CPU_PROFILING);
}
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 6858a31364b6..2c7814411f83 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -2461,19 +2461,3 @@ void hardpps(const struct timespec64 *phase_ts, const struct timespec64 *raw_ts)
}
EXPORT_SYMBOL(hardpps);
#endif /* CONFIG_NTP_PPS */
-
-/**
- * xtime_update() - advances the timekeeping infrastructure
- * @ticks: number of ticks, that have elapsed since the last call.
- *
- * Must be called with interrupts disabled.
- */
-void xtime_update(unsigned long ticks)
-{
- raw_spin_lock(&jiffies_lock);
- write_seqcount_begin(&jiffies_seq);
- do_timer(ticks);
- write_seqcount_end(&jiffies_seq);
- raw_spin_unlock(&jiffies_lock);
- update_wall_time();
-}
diff --git a/kernel/time/timekeeping.h b/kernel/time/timekeeping.h
index 099737f6f10c..d94b69c5b869 100644
--- a/kernel/time/timekeeping.h
+++ b/kernel/time/timekeeping.h
@@ -22,6 +22,7 @@ static inline int sched_clock_suspend(void) { return 0; }
static inline void sched_clock_resume(void) { }
#endif
+extern void update_process_times(int user);
extern void do_timer(unsigned long ticks);
extern void update_wall_time(void);
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [PATCH 11/13] timekeeping: remove xtime_update
2020-10-08 15:46 ` [PATCH 11/13] timekeeping: remove xtime_update Arnd Bergmann
@ 2020-10-12 13:15 ` Geert Uytterhoeven
2020-10-12 13:37 ` Arnd Bergmann
0 siblings, 1 reply; 43+ messages in thread
From: Geert Uytterhoeven @ 2020-10-12 13:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
Linux Kernel Mailing List, Finn Thain, Russell King,
James E.J. Bottomley, linux-m68k, Thomas Gleixner, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
Hi Arnd,
On Thu, Oct 8, 2020 at 5:48 PM Arnd Bergmann <arnd@arndb.de> wrote:
> There are no more users of xtime_update aside from legacy_timer_tick(),
> so fold it into that function and remove the declaration.
>
> update_process_times() is now only called inside of the kernel/time/
> code, so the declaration can be moved there.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks for your patch!
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
The comment about xtime_update() in arch/ia64/kernel/time.c needs
an update.
Does the comment about update_process_times() in
arch/openrisc/kernel/time.c needs an update, too?
For Amiga and Atari/ARAnyM:
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] 43+ messages in thread* Re: [PATCH 11/13] timekeeping: remove xtime_update
2020-10-12 13:15 ` Geert Uytterhoeven
@ 2020-10-12 13:37 ` Arnd Bergmann
2020-10-12 20:44 ` Thomas Gleixner
0 siblings, 1 reply; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-12 13:37 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
Linux Kernel Mailing List, Finn Thain, Russell King,
James E.J. Bottomley, linux-m68k, Thomas Gleixner, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
On Mon, Oct 12, 2020 at 3:16 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Oct 8, 2020 at 5:48 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > There are no more users of xtime_update aside from legacy_timer_tick(),
> > so fold it into that function and remove the declaration.
> >
> > update_process_times() is now only called inside of the kernel/time/
> > code, so the declaration can be moved there.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks for your patch!
>
> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> The comment about xtime_update() in arch/ia64/kernel/time.c needs
> an update.
I think the correct action for ia64 would be to make it a
proper clockevent driver with oneshot support, and remove
the rest of this logic.
I could try to rewrite the comment, but I tried not to touch that
part since I don't understand the logic behind it. Maybe the
ia64 maintainers can comment here why it even tries to skip
a timer tick. Is there a danger of ending up with the timer irq
permanently disabled if the timer_interrupt() function returns
with the itm register in the past, or is this simply about not having
too many interrupts in a row?
> Does the comment about update_process_times() in
> arch/openrisc/kernel/time.c needs an update, too?
I think that one is still technically correct.
Arnd
_______________________________________________
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] 43+ messages in thread* Re: [PATCH 11/13] timekeeping: remove xtime_update
2020-10-12 13:37 ` Arnd Bergmann
@ 2020-10-12 20:44 ` Thomas Gleixner
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Gleixner @ 2020-10-12 20:44 UTC (permalink / raw)
To: Arnd Bergmann, Geert Uytterhoeven
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
Linux Kernel Mailing List, Finn Thain, Russell King,
James E.J. Bottomley, linux-m68k, John Stultz, Linux ARM,
Philip Blundell, Greg Ungerer, Joshua Thompson
On Mon, Oct 12 2020 at 15:37, Arnd Bergmann wrote:
> On Mon, Oct 12, 2020 at 3:16 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Thu, Oct 8, 2020 at 5:48 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> The comment about xtime_update() in arch/ia64/kernel/time.c needs
>> an update.
>
> I think the correct action for ia64 would be to make it a
> proper clockevent driver with oneshot support, and remove
> the rest of this logic.
Correct action would be to remove all of arch/ia64 :)
> I could try to rewrite the comment, but I tried not to touch that
> part since I don't understand the logic behind it. Maybe the
> ia64 maintainers can comment here why it even tries to skip
> a timer tick. Is there a danger of ending up with the timer irq
> permanently disabled if the timer_interrupt() function returns
> with the itm register in the past, or is this simply about not having
> too many interrupts in a row?
There was a comment in the initial ia64 code:
* There is a race condition here: to be on the "safe"
* side, we process timer ticks until itm.next is
* ahead of the itc by at least half the timer
* interval. This should give us enough time to set
* the new itm value without losing a timer tick.
The ITM (Interval Timer Match) register is raising an interrupt when the
ITM value matches the ITC (Interval Timer Counter) register. If the new
counter is already past the match then the timer interrupt will happen
once ITC wrapped around and reaches the match value again. Might take
ages for a 64bit counter to do that. :)
IIRC, PXA had the same problem and HPET definitely has it as well. Seems
Intel patented the concept of broken timers, but at least they listened
when they proposed to implement the TSC deadline timer on x86 in the
exact same way.
See hpet_clkevt_set_next_event() for the gory details how to handle that
correctly.
Thanks,
tglx
_______________________________________________
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] 43+ messages in thread
* [PATCH 12/13] timekeeping: default GENERIC_CLOCKEVENTS to enabled
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
` (10 preceding siblings ...)
2020-10-08 15:46 ` [PATCH 11/13] timekeeping: remove xtime_update Arnd Bergmann
@ 2020-10-08 15:46 ` Arnd Bergmann
2020-10-12 13:15 ` Geert Uytterhoeven
2020-10-08 15:46 ` [RFC 13/13] m68k: mac: convert to generic clockevent Arnd Bergmann
2020-10-12 22:18 ` [PATCH 00/13] Clean up legacy clock tick users Linus Walleij
13 siblings, 1 reply; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-08 15:46 UTC (permalink / raw)
To: linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, Arnd Bergmann, linux-ia64,
Stephen Boyd, Helge Deller, Daniel Lezcano, Russell King,
Finn Thain, James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
Almost all machines use GENERIC_CLOCKEVENTS, so it feels wrong to
require each one to select that symbol manually.
Instead, enable it whenever CONFIG_LEGACY_TIMER_TICK is disabled as
a simplification. It should be possible to select both
GENERIC_CLOCKEVENTS and LEGACY_TIMER_TICK from an architecture now
and decide at runtime between the two.
For the clockevents arch-support.txt file, this means that additional
architectures are marked as TODO when they have at least one machine
that still uses LEGACY_TIMER_TICK, rather than being marked 'ok' when
at least one machine has been converted. This means that both m68k and
arm (for riscpc) revert to TODO.
At this point, we could just always enable CONFIG_GENERIC_CLOCKEVENTS
rather than leaving it off when not needed. I built an m68k
defconfig kernel (using gcc-10.1.0) and found that this would add
around 5.5KB in kernel image size:
text data bss dec hex filename
3861936 1092236 196656 5150828 4e986c obj-m68k/vmlinux-no-clockevent
3866201 1093832 196184 5156217 4ead79 obj-m68k/vmlinux-clockevent
On Arm (MACH_RPC), that difference appears to be twice as large,
around 11KB on top of an 6MB vmlinux.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
.../features/time/clockevents/arch-support.txt | 6 +++---
arch/alpha/Kconfig | 1 -
arch/arc/Kconfig | 1 -
arch/arm/Kconfig | 12 ------------
arch/arm64/Kconfig | 1 -
arch/arm64/Kconfig.platforms | 1 -
arch/c6x/Kconfig | 1 -
arch/csky/Kconfig | 1 -
arch/h8300/Kconfig | 1 -
arch/hexagon/Kconfig | 1 -
arch/m68k/Kconfig.cpu | 1 -
arch/microblaze/Kconfig | 1 -
arch/mips/Kconfig | 1 -
arch/nds32/Kconfig | 1 -
arch/nios2/Kconfig | 1 -
arch/openrisc/Kconfig | 1 -
arch/powerpc/Kconfig | 1 -
arch/riscv/Kconfig | 1 -
arch/s390/Kconfig | 1 -
arch/sh/Kconfig | 1 -
arch/sparc/Kconfig | 1 -
arch/um/Kconfig | 1 -
arch/x86/Kconfig | 1 -
arch/xtensa/Kconfig | 1 -
kernel/time/Kconfig | 2 +-
25 files changed, 4 insertions(+), 38 deletions(-)
diff --git a/Documentation/features/time/clockevents/arch-support.txt b/Documentation/features/time/clockevents/arch-support.txt
index 61a5c9d68c15..6863a3fbddad 100644
--- a/Documentation/features/time/clockevents/arch-support.txt
+++ b/Documentation/features/time/clockevents/arch-support.txt
@@ -1,6 +1,6 @@
#
# Feature name: clockevents
-# Kconfig: GENERIC_CLOCKEVENTS
+# Kconfig: !LEGACY_TIMER_TICK
# description: arch support generic clock events
#
-----------------------
@@ -8,14 +8,14 @@
-----------------------
| alpha: | ok |
| arc: | ok |
- | arm: | ok |
+ | arm: | TODO |
| arm64: | ok |
| c6x: | ok |
| csky: | ok |
| h8300: | ok |
| hexagon: | ok |
| ia64: | TODO |
- | m68k: | ok |
+ | m68k: | TODO |
| microblaze: | ok |
| mips: | ok |
| nds32: | ok |
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index d6e9fc7a7b19..f0a700946cac 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -27,7 +27,6 @@ config ALPHA
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select AUDIT_ARCH
- select GENERIC_CLOCKEVENTS
select GENERIC_CPU_VULNERABILITIES
select GENERIC_SMP_IDLE_THREAD
select GENERIC_STRNCPY_FROM_USER
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 0a89cc9def65..061eb8e23739 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -19,7 +19,6 @@ config ARC
select COMMON_CLK
select DMA_DIRECT_REMAP
select GENERIC_ATOMIC64 if !ISA_ARCV2 || !(ARC_HAS_LL64 && ARC_HAS_LLSC)
- select GENERIC_CLOCKEVENTS
select GENERIC_FIND_FIRST_BIT
# for now, we don't need GENERIC_IRQ_PROBE, CONFIG_GENERIC_IRQ_CHIP
select GENERIC_IRQ_SHOW
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 13af8d7a6c17..7adbc7387146 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -322,7 +322,6 @@ config ARCH_MULTIPLATFORM
select AUTO_ZRELADDR
select TIMER_OF
select COMMON_CLK
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_MULTI_HANDLER
select HAVE_PCI
select PCI_DOMAINS_GENERIC if PCI
@@ -337,7 +336,6 @@ config ARM_SINGLE_ARMV7M
select TIMER_OF
select COMMON_CLK
select CPU_V7M
- select GENERIC_CLOCKEVENTS
select NO_IOPORT_MAP
select SPARSE_IRQ
select USE_OF
@@ -366,7 +364,6 @@ config ARCH_EP93XX
select CLKDEV_LOOKUP
select CLKSRC_MMIO
select CPU_ARM920T
- select GENERIC_CLOCKEVENTS
select GPIOLIB
select HAVE_LEGACY_CLK
help
@@ -376,7 +373,6 @@ config ARCH_FOOTBRIDGE
bool "FootBridge"
select CPU_SA110
select FOOTBRIDGE
- select GENERIC_CLOCKEVENTS
select HAVE_IDE
select NEED_MACH_IO_H if !MMU
select NEED_MACH_MEMORY_H
@@ -404,7 +400,6 @@ config ARCH_IXP4XX
select ARCH_SUPPORTS_BIG_ENDIAN
select CPU_XSCALE
select DMABOUNCE if PCI
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_MULTI_HANDLER
select GPIO_IXP4XX
select GPIOLIB
@@ -420,7 +415,6 @@ config ARCH_IXP4XX
config ARCH_DOVE
bool "Marvell Dove"
select CPU_PJ4
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_MULTI_HANDLER
select GPIOLIB
select HAVE_PCI
@@ -444,7 +438,6 @@ config ARCH_PXA
select CLKSRC_MMIO
select TIMER_OF
select CPU_XSCALE if !CPU_XSC3
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_MULTI_HANDLER
select GPIO_PXA
select GPIOLIB
@@ -485,7 +478,6 @@ config ARCH_SA1100
select COMMON_CLK
select CPU_FREQ
select CPU_SA1100
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_MULTI_HANDLER
select GPIOLIB
select HAVE_IDE
@@ -500,7 +492,6 @@ config ARCH_S3C24XX
bool "Samsung S3C24XX SoCs"
select ATAGS
select CLKSRC_SAMSUNG_PWM
- select GENERIC_CLOCKEVENTS
select GPIO_SAMSUNG
select GPIOLIB
select GENERIC_IRQ_MULTI_HANDLER
@@ -524,7 +515,6 @@ config ARCH_OMAP1
select ARCH_OMAP
select CLKDEV_LOOKUP
select CLKSRC_MMIO
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_CHIP
select GENERIC_IRQ_MULTI_HANDLER
select GPIOLIB
@@ -787,7 +777,6 @@ config ARCH_ACORN
config PLAT_IOP
bool
- select GENERIC_CLOCKEVENTS
config PLAT_ORION
bool
@@ -1178,7 +1167,6 @@ config HAVE_SMP
config SMP
bool "Symmetric Multi-Processing"
depends on CPU_V6K || CPU_V7
- depends on GENERIC_CLOCKEVENTS
depends on HAVE_SMP
depends on MMU || ARM_MPU
select IRQ_WORK
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 08fa3a1c50f0..3e56f6840a32 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -101,7 +101,6 @@ config ARM64
select FRAME_POINTER
select GENERIC_ALLOCATOR
select GENERIC_ARCH_TOPOLOGY
- select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST
select GENERIC_CPU_AUTOPROBE
select GENERIC_CPU_VULNERABILITIES
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 6f2494dd6d60..748e6d8c3b94 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -256,7 +256,6 @@ config ARCH_TEGRA
select ARM_GIC_PM
select CLKSRC_MMIO
select TIMER_OF
- select GENERIC_CLOCKEVENTS
select GPIOLIB
select PINCTRL
select PM
diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig
index 48d66bf0465d..bdeeac28b1be 100644
--- a/arch/c6x/Kconfig
+++ b/arch/c6x/Kconfig
@@ -19,7 +19,6 @@ config C6X
select IRQ_DOMAIN
select OF
select OF_EARLY_FLATTREE
- select GENERIC_CLOCKEVENTS
select MODULES_USE_ELF_RELA
select MMU_GATHER_NO_RANGE if MMU
select SET_FS
diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
index 50bb8b4477be..8fec85ab5da6 100644
--- a/arch/csky/Kconfig
+++ b/arch/csky/Kconfig
@@ -28,7 +28,6 @@ config CSKY
select GENERIC_LIB_UCMPDI2
select GENERIC_ALLOCATOR
select GENERIC_ATOMIC64
- select GENERIC_CLOCKEVENTS
select GENERIC_CPU_DEVICES
select GENERIC_IRQ_CHIP
select GENERIC_IRQ_PROBE
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 7945de067e9f..3e3e0f16f7e0 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -12,7 +12,6 @@ config H8300
select FRAME_POINTER
select GENERIC_CPU_DEVICES
select MODULES_USE_ELF_RELA
- select GENERIC_CLOCKEVENTS
select COMMON_CLK
select ARCH_WANT_FRAME_POINTERS
select OF
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index f2afabbadd43..6e00c16a36b5 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -27,7 +27,6 @@ config HEXAGON
select GENERIC_IOMAP
select GENERIC_SMP_IDLE_THREAD
select STACKTRACE_SUPPORT
- select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST
select MODULES_USE_ELF_RELA
select GENERIC_CPU_DEVICES
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index 322a35ef14c6..abeb2e4dc72d 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -315,7 +315,6 @@ config M54xx
config COLDFIRE_PIT_TIMER
bool
- select GENERIC_CLOCKEVENTS
config COLDFIRE_TIMERS
bool
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 33925ffed68f..2f0d3f431faf 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -17,7 +17,6 @@ config MICROBLAZE
select COMMON_CLK
select DMA_DIRECT_REMAP if MMU
select GENERIC_ATOMIC64
- select GENERIC_CLOCKEVENTS
select GENERIC_CPU_DEVICES
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_PROBE
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index f52fa211a4cf..977c50d90933 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -21,7 +21,6 @@ config MIPS
select CPU_NO_EFFICIENT_FFS if (TARGET_ISA_REV < 1)
select CPU_PM if CPU_IDLE
select GENERIC_ATOMIC64 if !64BIT
- select GENERIC_CLOCKEVENTS
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
select GENERIC_GETTIMEOFDAY
diff --git a/arch/nds32/Kconfig b/arch/nds32/Kconfig
index e8e541fd2267..62313902d75d 100644
--- a/arch/nds32/Kconfig
+++ b/arch/nds32/Kconfig
@@ -17,7 +17,6 @@ config NDS32
select DMA_DIRECT_REMAP
select GENERIC_ATOMIC64
select GENERIC_CPU_DEVICES
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_CHIP
select GENERIC_IRQ_SHOW
select GENERIC_IOREMAP
diff --git a/arch/nios2/Kconfig b/arch/nios2/Kconfig
index c7c6ba6bec9d..c24955c81c92 100644
--- a/arch/nios2/Kconfig
+++ b/arch/nios2/Kconfig
@@ -10,7 +10,6 @@ config NIOS2
select COMMON_CLK
select TIMER_OF
select GENERIC_ATOMIC64
- select GENERIC_CLOCKEVENTS
select GENERIC_CPU_DEVICES
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 6233c6293180..591acc5990dc 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -24,7 +24,6 @@ config OPENRISC
select GENERIC_CPU_DEVICES
select HAVE_UID16
select GENERIC_ATOMIC64
- select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 47a639ba7084..4a4c0c9e2287 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -163,7 +163,6 @@ config PPC
select EDAC_ATOMIC_SCRUB
select EDAC_SUPPORT
select GENERIC_ATOMIC64 if PPC32
- select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 44377fd7860e..3842bbb4fe62 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -37,7 +37,6 @@ config RISCV
select EDAC_SUPPORT
select GENERIC_ARCH_TOPOLOGY if SMP
select GENERIC_ATOMIC64 if !64BIT
- select GENERIC_CLOCKEVENTS
select GENERIC_EARLY_IOREMAP
select GENERIC_GETTIMEOFDAY if HAVE_GENERIC_VDSO
select GENERIC_IOREMAP
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 34371539a9b9..a91a678b33f9 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -116,7 +116,6 @@ config S390
select CLONE_BACKWARDS2
select DMA_OPS if PCI
select DYNAMIC_FTRACE if FUNCTION_TRACER
- select GENERIC_CLOCKEVENTS
select GENERIC_CPU_AUTOPROBE
select GENERIC_CPU_VULNERABILITIES
select GENERIC_FIND_FIRST_BIT
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 159da4ed578f..5fa580219a86 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -16,7 +16,6 @@ config SUPERH
select CPU_NO_EFFICIENT_FFS
select DMA_DECLARE_COHERENT
select GENERIC_ATOMIC64
- select GENERIC_CLOCKEVENTS
select GENERIC_CMOS_UPDATE if SH_SH03 || SH_DREAMCAST
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_SHOW
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 54bd4143b02f..36a69443241c 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -39,7 +39,6 @@ config SPARC
select HAVE_EBPF_JIT if SPARC64
select HAVE_DEBUG_BUGVERBOSE
select GENERIC_SMP_IDLE_THREAD
- select GENERIC_CLOCKEVENTS
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
select MODULES_USE_ELF_RELA
diff --git a/arch/um/Kconfig b/arch/um/Kconfig
index 78c14216c11b..27a964cba2a5 100644
--- a/arch/um/Kconfig
+++ b/arch/um/Kconfig
@@ -17,7 +17,6 @@ config UML
select NO_DMA
select GENERIC_IRQ_SHOW
select GENERIC_CPU_DEVICES
- select GENERIC_CLOCKEVENTS
select HAVE_GCC_PLUGINS
select SET_FS
select TTY # Needed for line.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index fca50af29faf..badeb71fdf6e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -108,7 +108,6 @@ config X86
select DCACHE_WORD_ACCESS
select EDAC_ATOMIC_SCRUB
select EDAC_SUPPORT
- select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST if X86_64 || (X86_32 && X86_LOCAL_APIC)
select GENERIC_CLOCKEVENTS_MIN_ADJUST
select GENERIC_CMOS_UPDATE
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index d0dfa50bd0bb..2611ba336af8 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -16,7 +16,6 @@ config XTENSA
select COMMON_CLK
select DMA_REMAP if MMU
select GENERIC_ATOMIC64
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_SHOW
select GENERIC_PCI_IOMAP
select GENERIC_SCHED_CLOCK
diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
index f2b0cfeade47..22ec4d89e57d 100644
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -32,7 +32,7 @@ config ARCH_USES_GETTIMEOFFSET
# The generic clock events infrastructure
config GENERIC_CLOCKEVENTS
- bool
+ def_bool !LEGACY_TIMER_TICK
# Architecture can handle broadcast in a driver-agnostic way
config ARCH_HAS_TICK_BROADCAST
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [PATCH 12/13] timekeeping: default GENERIC_CLOCKEVENTS to enabled
2020-10-08 15:46 ` [PATCH 12/13] timekeeping: default GENERIC_CLOCKEVENTS to enabled Arnd Bergmann
@ 2020-10-12 13:15 ` Geert Uytterhoeven
0 siblings, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2020-10-12 13:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
Linux Kernel Mailing List, Finn Thain, Russell King,
James E.J. Bottomley, linux-m68k, Thomas Gleixner, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
On Thu, Oct 8, 2020 at 5:48 PM Arnd Bergmann <arnd@arndb.de> wrote:
> Almost all machines use GENERIC_CLOCKEVENTS, so it feels wrong to
> require each one to select that symbol manually.
>
> Instead, enable it whenever CONFIG_LEGACY_TIMER_TICK is disabled as
> a simplification. It should be possible to select both
> GENERIC_CLOCKEVENTS and LEGACY_TIMER_TICK from an architecture now
> and decide at runtime between the two.
>
> For the clockevents arch-support.txt file, this means that additional
> architectures are marked as TODO when they have at least one machine
> that still uses LEGACY_TIMER_TICK, rather than being marked 'ok' when
> at least one machine has been converted. This means that both m68k and
> arm (for riscpc) revert to TODO.
>
> At this point, we could just always enable CONFIG_GENERIC_CLOCKEVENTS
> rather than leaving it off when not needed. I built an m68k
> defconfig kernel (using gcc-10.1.0) and found that this would add
> around 5.5KB in kernel image size:
>
> text data bss dec hex filename
> 3861936 1092236 196656 5150828 4e986c obj-m68k/vmlinux-no-clockevent
> 3866201 1093832 196184 5156217 4ead79 obj-m68k/vmlinux-clockevent
>
> On Arm (MACH_RPC), that difference appears to be twice as large,
> around 11KB on top of an 6MB vmlinux.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
> arch/m68k/Kconfig.cpu | 1 -
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] 43+ messages in thread
* [RFC 13/13] m68k: mac: convert to generic clockevent
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
` (11 preceding siblings ...)
2020-10-08 15:46 ` [PATCH 12/13] timekeeping: default GENERIC_CLOCKEVENTS to enabled Arnd Bergmann
@ 2020-10-08 15:46 ` Arnd Bergmann
2020-10-09 22:21 ` Finn Thain
2020-10-12 22:18 ` [PATCH 00/13] Clean up legacy clock tick users Linus Walleij
13 siblings, 1 reply; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-08 15:46 UTC (permalink / raw)
To: linux-kernel
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, Arnd Bergmann, linux-ia64,
Stephen Boyd, Helge Deller, Daniel Lezcano, Russell King,
Finn Thain, James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
Now that the infrastructure allows kernels to have both legacy timer
ticks and clockevent drivers in the same image, start by moving one
platform to generic clockevents.
As qemu only supports the q800 platform among the classic m68k, use
that as an example.
I also tried adding oneshot mode, which was successful but broke
the clocksource. It's probably not hard to make it work properly,
but this is where I've stopped.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I have never tried implementing a clockevent or clocksource
driver in the past, so this is really just an experiment and
I expect I got something wrong.
arch/m68k/Kconfig.machine | 2 +-
arch/m68k/mac/via.c | 44 ++++++++++++++++++++++++++++++++-------
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
index 8a4e8bd8aade..cccabdad618e 100644
--- a/arch/m68k/Kconfig.machine
+++ b/arch/m68k/Kconfig.machine
@@ -30,7 +30,7 @@ config MAC
depends on MMU
select MMU_MOTOROLA if MMU
select HAVE_ARCH_NVRAM_OPS
- select LEGACY_TIMER_TICK
+ select GENERIC_CLOCKEVENTS
help
This option enables support for the Apple Macintosh series of
computers (yes, there is experimental support now, at least for part
diff --git a/arch/m68k/mac/via.c b/arch/m68k/mac/via.c
index 8ad734e3c934..dd4c13c318b6 100644
--- a/arch/m68k/mac/via.c
+++ b/arch/m68k/mac/via.c
@@ -24,6 +24,7 @@
*/
#include <linux/clocksource.h>
+#include <linux/clockchips.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/mm.h>
@@ -602,27 +603,54 @@ static u32 clk_total, clk_offset;
static irqreturn_t via_timer_handler(int irq, void *dev_id)
{
+ struct clock_event_device *evt = dev_id;
+
clk_total += VIA_TIMER_CYCLES;
clk_offset = 0;
- legacy_timer_tick(1);
+ evt->event_handler(evt);
return IRQ_HANDLED;
}
-void __init via_init_clock(void)
+static int via_set_periodic(struct clock_event_device *evt)
{
- if (request_irq(IRQ_MAC_TIMER_1, via_timer_handler, IRQF_TIMER, "timer",
- NULL)) {
- pr_err("Couldn't register %s interrupt\n", "timer");
- return;
- }
-
via1[vT1LL] = VIA_TC_LOW;
via1[vT1LH] = VIA_TC_HIGH;
via1[vT1CL] = VIA_TC_LOW;
via1[vT1CH] = VIA_TC_HIGH;
via1[vACR] |= 0x40;
+ return 0;
+}
+
+static int via_set_shutdown(struct clock_event_device *evt)
+{
+ via1[vACR] &= ~0x40;
+
+ return 0;
+}
+
+static struct clock_event_device via_clk_event = {
+ .name = "via1",
+ .rating = 250,
+ .irq = IRQ_MAC_TIMER_1,
+ .owner = THIS_MODULE,
+
+ .features = CLOCK_EVT_FEAT_PERIODIC,
+ .set_state_shutdown = via_set_shutdown,
+ .set_state_periodic = via_set_periodic,
+};
+
+void __init via_init_clock(void)
+{
+ clockevents_config_and_register(&via_clk_event, VIA_CLOCK_FREQ, 1, 0xffff);
+
+ if (request_irq(IRQ_MAC_TIMER_1, via_timer_handler, IRQF_TIMER, "timer",
+ &via_clk_event)) {
+ pr_err("Couldn't register %s interrupt\n", "timer");
+ return;
+ }
+
clocksource_register_hz(&mac_clk, VIA_CLOCK_FREQ);
}
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [RFC 13/13] m68k: mac: convert to generic clockevent
2020-10-08 15:46 ` [RFC 13/13] m68k: mac: convert to generic clockevent Arnd Bergmann
@ 2020-10-09 22:21 ` Finn Thain
2020-10-10 18:52 ` Arnd Bergmann
0 siblings, 1 reply; 43+ messages in thread
From: Finn Thain @ 2020-10-09 22:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, linux-parisc, linux-ia64, Stephen Boyd,
Helge Deller, Daniel Lezcano, linux-kernel, Russell King,
James E.J. Bottomley, linux-m68k, Geert Uytterhoeven,
linux-arm-kernel, John Stultz, Philip Blundell, Greg Ungerer,
Joshua Thompson
Hi Arnd,
Perhaps patch 13 does not belong in this series (?).
All m68k platforms will need conversion before the TODO can be removed
from Documentation/features/time/clockevents/arch-support.txt.
On m68k, HZ is fixed at 100. Without addressing that, would there be any
benefit from adopting GENERIC_CLOCKEVENTS as per this RFC patch?
On Thu, 8 Oct 2020, Arnd Bergmann wrote:
> Now that the infrastructure allows kernels to have both legacy timer
> ticks and clockevent drivers in the same image, start by moving one
> platform to generic clockevents.
>
> As qemu only supports the q800 platform among the classic m68k, use that
> as an example.
>
Correct VIA emulation is suprisingly difficult, so this kind of work
should be tested on real hardware.
I say that because when I did the clocksource conversion for m68k I ran
into a bug in QEMU (since fixed) and also because I once worked on some of
the bugs in the emulated VIA device used in MAME/MESS.
> I also tried adding oneshot mode, which was successful but broke the
> clocksource. It's probably not hard to make it work properly, but this
> is where I've stopped.
>
I'm not so sure that one timer is able to support both a clocksource
driver and a clockevent driver. In some cases we may have to drop the
clocksource driver (i.e. fall back on the jiffies clocksource).
Anyway, even on Macs with only one VIA chip we still have two timers. So I
think we should try to use Timer 1 as a freerunning clocksource and Timer
2 as a oneshot clock event. This may result in better accuracy and simpler
code. This may require some experimentation though.
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> I have never tried implementing a clockevent or clocksource
> driver in the past, so this is really just an experiment and
> I expect I got something wrong.
>
Writing clockevent drivers is new to me too. I'm still trying to discover
what the implications might be if the only available clockevent device
offers oneshot mode or periodic mode but not both.
_______________________________________________
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] 43+ messages in thread
* Re: [RFC 13/13] m68k: mac: convert to generic clockevent
2020-10-09 22:21 ` Finn Thain
@ 2020-10-10 18:52 ` Arnd Bergmann
2020-10-15 1:18 ` Finn Thain
0 siblings, 1 reply; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-10 18:52 UTC (permalink / raw)
To: Finn Thain
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, Parisc List, linux-ia64, Stephen Boyd,
Helge Deller, Daniel Lezcano, linux-kernel, Russell King,
James E.J. Bottomley, linux-m68k, Geert Uytterhoeven, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
On Sat, Oct 10, 2020 at 12:21 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> Hi Arnd,
>
> Perhaps patch 13 does not belong in this series (?).
>
> All m68k platforms will need conversion before the TODO can be removed
> from Documentation/features/time/clockevents/arch-support.txt.
Yes, correct. I marked this patch as RFC instead of PATCH, as I'm
just trying to find out where it should be headed. I would hope the
other patches can just get merged.
> On m68k, HZ is fixed at 100. Without addressing that, would there be any
> benefit from adopting GENERIC_CLOCKEVENTS as per this RFC patch?
I don't think so, I mainly did it to see if there is a problem with mixing
the two modes, and I couldn't find any. The behavior seems unchanged
before and after my patch, the main difference being a few extra kilobytes
in kernel .text for the generic clockevents code.
> On Thu, 8 Oct 2020, Arnd Bergmann wrote:
>
> > Now that the infrastructure allows kernels to have both legacy timer
> > ticks and clockevent drivers in the same image, start by moving one
> > platform to generic clockevents.
> >
> > As qemu only supports the q800 platform among the classic m68k, use that
> > as an example.
> >
>
> Correct VIA emulation is suprisingly difficult, so this kind of work
> should be tested on real hardware.
>
> I say that because when I did the clocksource conversion for m68k I ran
> into a bug in QEMU (since fixed) and also because I once worked on some of
> the bugs in the emulated VIA device used in MAME/MESS.
Good point, though I would be surprised if anything went wrong with
this patch on real hardware but not in emulation, as all the register-level
interactions with the timer are the same.
Adding oneshot mode is a completely different matter though, that
clearly needs to be tested on real hardware.
> > I also tried adding oneshot mode, which was successful but broke the
> > clocksource. It's probably not hard to make it work properly, but this
> > is where I've stopped.
> >
>
> I'm not so sure that one timer is able to support both a clocksource
> driver and a clockevent driver. In some cases we may have to drop the
> clocksource driver (i.e. fall back on the jiffies clocksource).
>
> Anyway, even on Macs with only one VIA chip we still have two timers. So I
> think we should try to use Timer 1 as a freerunning clocksource and Timer
> 2 as a oneshot clock event. This may result in better accuracy and simpler
> code. This may require some experimentation though.
Ah, good. This is partly what I had been hoping for, as my patch
can be used as a starting point for that if you want to give it a go.
Arnd
_______________________________________________
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] 43+ messages in thread* Re: [RFC 13/13] m68k: mac: convert to generic clockevent
2020-10-10 18:52 ` Arnd Bergmann
@ 2020-10-15 1:18 ` Finn Thain
[not found] ` <CAK8P3a2ymv79j1edtJ983-VgjtxvT_6co7V0VRnHzcneW+0ZtA@mail.gmail.com>
2020-10-23 7:52 ` Arnd Bergmann
0 siblings, 2 replies; 43+ messages in thread
From: Finn Thain @ 2020-10-15 1:18 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, Parisc List, linux-ia64, Stephen Boyd,
Helge Deller, Daniel Lezcano, linux-kernel, Russell King,
James E.J. Bottomley, linux-m68k, Geert Uytterhoeven, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
On Sat, 10 Oct 2020, Arnd Bergmann wrote:
> > Perhaps patch 13 does not belong in this series (?).
> >
> > All m68k platforms will need conversion before the TODO can be removed
> > from Documentation/features/time/clockevents/arch-support.txt.
>
> Yes, correct. I marked this patch as RFC instead of PATCH, as I'm just
> trying to find out where it should be headed. I would hope the other
> patches can just get merged.
>
I wonder whether we can improve support for your proposed configuration
i.e. a system with no oneshot clockevent device.
The 16 platforms you identified are not all in that category but I suspect
that there are others which are (though they don't appear in this series
because they already use GENERIC_CLOCKEVENTS).
One useful optimization would be some way to elide oneshot clockevent
support (perhaps with the help of Link Time Optimization).
> > On m68k, HZ is fixed at 100. Without addressing that, would there be
> > any benefit from adopting GENERIC_CLOCKEVENTS as per this RFC patch?
>
> I don't think so, I mainly did it to see if there is a problem with
> mixing the two modes, and I couldn't find any. The behavior seems
> unchanged before and after my patch, the main difference being a few
> extra kilobytes in kernel .text for the generic clockevents code.
>
I think that is a good reason to convert all m68k platforms at once and to
elide some of the dead code.
> > On Thu, 8 Oct 2020, Arnd Bergmann wrote:
> >
> > > Now that the infrastructure allows kernels to have both legacy timer
> > > ticks and clockevent drivers in the same image, start by moving one
> > > platform to generic clockevents.
> > >
> > > As qemu only supports the q800 platform among the classic m68k, use
> > > that as an example.
> > >
> >
> > Correct VIA emulation is suprisingly difficult, so this kind of work
> > should be tested on real hardware.
> >
> > I say that because when I did the clocksource conversion for m68k I
> > ran into a bug in QEMU (since fixed) and also because I once worked on
> > some of the bugs in the emulated VIA device used in MAME/MESS.
>
> Good point, though I would be surprised if anything went wrong with this
> patch on real hardware but not in emulation, as all the register-level
> interactions with the timer are the same.
>
On the subject of register accesses, via1[ACR] is shared with ADB drivers,
so this patch probably has to protect those accesses with
local_irq_save/restore or local_irq_disable/enable. (I can't be sure of
the contexts in which .set_state_shutdown and .set_state_periodic methods
are called.)
> Adding oneshot mode is a completely different matter though, that
> clearly needs to be tested on real hardware.
>
Right, and many emulators trade-off timing accuracy for performance which
makes them unsuitable for testing invasive changes of that sort.
> > > I also tried adding oneshot mode, which was successful but broke the
> > > clocksource. It's probably not hard to make it work properly, but
> > > this is where I've stopped.
> > >
> >
> > I'm not so sure that one timer is able to support both a clocksource
> > driver and a clockevent driver. In some cases we may have to drop the
> > clocksource driver (i.e. fall back on the jiffies clocksource).
> >
> > Anyway, even on Macs with only one VIA chip we still have two timers.
> > So I think we should try to use Timer 1 as a freerunning clocksource
> > and Timer 2 as a oneshot clock event. This may result in better
> > accuracy and simpler code. This may require some experimentation
> > though.
>
> Ah, good. This is partly what I had been hoping for, as my patch can be
> used as a starting point for that if you want to give it a go.
>
After looking at the chip documentation I don't think it's viable to use
the hardware timers in the way I proposed. A VIA register access requires
at least one full VIA clock cycle (about 1.3 us) which means register
accesses themselves cause timing delays. They also make clocksource reads
expensive.
I think this rules out oneshot clockevent devices because if the system
offered such a device it would preferentially get used as a tick device.
So I think your approach (periodic clockevent device driven by the
existing periodic tick interrupt) is best for this platform due to
simplicity (not much code) and performance (good accuracy, no additional
overhead).
I suspect the same approach would work equally well on other platforms too
(even though they are probably be capable of oneshot clockevent devices).
> Arnd
>
_______________________________________________
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] 43+ messages in thread[parent not found: <CAK8P3a2ymv79j1edtJ983-VgjtxvT_6co7V0VRnHzcneW+0ZtA@mail.gmail.com>]
* Re: [RFC 13/13] m68k: mac: convert to generic clockevent
[not found] ` <CAK8P3a2ymv79j1edtJ983-VgjtxvT_6co7V0VRnHzcneW+0ZtA@mail.gmail.com>
@ 2020-10-18 0:54 ` Finn Thain
0 siblings, 0 replies; 43+ messages in thread
From: Finn Thain @ 2020-10-18 0:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, Parisc List, linux-ia64, Stephen Boyd,
Helge Deller, Daniel Lezcano, linux-kernel, Russell King,
James E.J. Bottomley, linux-m68k, Geert Uytterhoeven, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
On Thu, 15 Oct 2020, Arnd Bergmann wrote:
> On Thu, Oct 15, 2020 at 3:19 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> >
> > On Sat, 10 Oct 2020, Arnd Bergmann wrote:
> >
> > > > Perhaps patch 13 does not belong in this series (?).
> > > >
> > > > All m68k platforms will need conversion before the TODO can be removed
> > > > from Documentation/features/time/clockevents/arch-support.txt.
> > >
> > > Yes, correct. I marked this patch as RFC instead of PATCH, as I'm just
> > > trying to find out where it should be headed. I would hope the other
> > > patches can just get merged.
> > >
> >
> > I wonder whether we can improve support for your proposed configuration
> > i.e. a system with no oneshot clockevent device.
> >
> > The 16 platforms you identified are not all in that category but I suspect
> > that there are others which are (though they don't appear in this series
> > because they already use GENERIC_CLOCKEVENTS).
> >
> > One useful optimization would be some way to elide oneshot clockevent
> > support (perhaps with the help of Link Time Optimization).
>
> I think this already happens if one picks CONFIG_HZ_PERIODIC while
> disabling HIGH_RES_TIMERS. In that case, CONFIG_TICK_ONESHOT
> remains disabled.
>
That configuration still produces the same 5 KiB of bloat. I see that
kernel/time/Kconfig has this --
# Core internal switch. Selected by NO_HZ_COMMON / HIGH_RES_TIMERS. This is
# only related to the tick functionality. Oneshot clockevent devices
# are supported independent of this.
config TICK_ONESHOT
bool
But my question was really about both kinds of dead code (oneshot device
support and oneshot tick support). Anyway, after playing with the code for
a bit I don't see any easy way to reduce the growth in text size.
> ...
> > After looking at the chip documentation I don't think it's viable to
> > use the hardware timers in the way I proposed. A VIA register access
> > requires at least one full VIA clock cycle (about 1.3 us) which means
> > register accesses themselves cause timing delays. They also make
> > clocksource reads expensive.
> >
> > I think this rules out oneshot clockevent devices because if the
> > system offered such a device it would preferentially get used as a
> > tick device.
> >
> > So I think your approach (periodic clockevent device driven by the
> > existing periodic tick interrupt) is best for this platform due to
> > simplicity (not much code) and performance (good accuracy, no
> > additional overhead).
>
> Yes, makes sense. I think the one remaining problem with the periodic
> mode in this driver is that it can drop timer ticks when interrupts are
> disabled for too long, while in oneshot mode there may be a way to know
> how much time has passed since the last tick as long as the counter does
> not overflow.
Is there any benefit from adopting a oneshot tick (rather than periodic)
if no clocksource is consulted when calculating the next interval? (I'm
assuming NO_HZ is not in use, for reasons discussed below.)
> I would agree that despite this oneshot mode is probably worse overall
> for timekeeping if the register accesses introduce systematic errors.
>
It probably has to be tried. But consulting a VIA clocksource on every
tick would be expensive on this platform, so if that was the only way to
avoid cumulative errors, I'd probably just stick with the periodic tick.
> ...
> The arm/rpc timer seems to be roughly in the same category as most of
> the m68k ones or the i8253 counter on a PC. It's possible that some of
> them could use the same logic as drivers/clocksource/i8253.o as long as
> there is any hardware oneshot mode.
>
There appear to be 15 platforms in that category. 4 have no clocksource
besides the jiffies clocksource, meaning there's no practical alternative
to using a periodic tick, like you did in your RFC patch:
arch/m68k/apollo/config.c
arch/m68k/q40/q40ints.c
arch/m68k/sun3/sun3ints.c
arch/m68k/sun3x/time.c
The other 11 platforms in that category also have 'synthetic' clocksources
derived from a timer reload interrupt. In 3 cases, the clocksource read
method does not (or can not) check for a pending counter reload interrupt.
For these also, I see no practical alternative to the approach you've
taken in your RFC patch:
arch/m68k/68000/timers.c
arch/m68k/atari/time.c
arch/m68k/coldfire/timers.c
That leaves 8 platforms that have reliable clocksource devices which
should be able to provide an accurate reading even in the presence of a
dropped tick (due to drivers disabling interrupts for too long):
arch/arm/mach-rpc/time.c
arch/m68k/amiga/config.c
arch/m68k/bvme6000/config.c
arch/m68k/coldfire/sltimers.c
arch/m68k/hp300/time.c
arch/m68k/mac/via.c
arch/m68k/mvme147/config.c
arch/m68k/mvme16x/config.c
But is there any reason to adopt a oneshot tick on any of these platforms,
if NO_HZ won't eliminate the timer interrupt that's needed to run a
'synthetic' clocksource?
_______________________________________________
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] 43+ messages in thread
* Re: [RFC 13/13] m68k: mac: convert to generic clockevent
2020-10-15 1:18 ` Finn Thain
[not found] ` <CAK8P3a2ymv79j1edtJ983-VgjtxvT_6co7V0VRnHzcneW+0ZtA@mail.gmail.com>
@ 2020-10-23 7:52 ` Arnd Bergmann
2020-10-23 9:24 ` Geert Uytterhoeven
2020-10-30 0:41 ` Finn Thain
1 sibling, 2 replies; 43+ messages in thread
From: Arnd Bergmann @ 2020-10-23 7:52 UTC (permalink / raw)
To: Finn Thain
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, Parisc List, linux-ia64, Stephen Boyd,
Helge Deller, Daniel Lezcano, linux-kernel, Russell King,
James E.J. Bottomley, linux-m68k, Geert Uytterhoeven, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
On Sun, Oct 18, 2020 at 2:55 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> On Thu, 15 Oct 2020, Arnd Bergmann wrote:
> > On Thu, Oct 15, 2020 at 3:19 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> > > On Sat, 10 Oct 2020, Arnd Bergmann wrote:
>
> That configuration still produces the same 5 KiB of bloat. I see that
> kernel/time/Kconfig has this --
>
> # Core internal switch. Selected by NO_HZ_COMMON / HIGH_RES_TIMERS. This is
> # only related to the tick functionality. Oneshot clockevent devices
> # are supported independent of this.
> config TICK_ONESHOT
> bool
>
> But my question was really about both kinds of dead code (oneshot device
> support and oneshot tick support). Anyway, after playing with the code for
> a bit I don't see any easy way to reduce the growth in text size.
Did you look more deeply into where those 5KB are? Is this just
the code in kernel/time/{clockevents,tick-common}.c and the
added platform specific bits, or is there something more?
I suppose the sysfs interface and the clockevents_update_freq()
logic are not really needed on m68k, but it wouldn't make much
sense to split those out either.
How does the 5KB bloat compare to the average bloat we get
from one release to the next? Geert has been collecting statistics
for this.
> > Yes, makes sense. I think the one remaining problem with the periodic
> > mode in this driver is that it can drop timer ticks when interrupts are
> > disabled for too long, while in oneshot mode there may be a way to know
> > how much time has passed since the last tick as long as the counter does
> > not overflow.
>
> Is there any benefit from adopting a oneshot tick (rather than periodic)
> if no clocksource is consulted when calculating the next interval? (I'm
> assuming NO_HZ is not in use, for reasons discussed below.)
If the clocksource does not set CLOCK_SOURCE_IS_CONTINOUS,
the kernel will keep using periodic timers and not allow hrtimers.
> > I would agree that despite this oneshot mode is probably worse overall
> > for timekeeping if the register accesses introduce systematic errors.
> >
>
> It probably has to be tried. But consulting a VIA clocksource on every
> tick would be expensive on this platform, so if that was the only way to
> avoid cumulative errors, I'd probably just stick with the periodic tick.
I'm sure there is a tradeoff somewhere. Without hrtimers, some
events will take longer when they have to wait for the next tick, and
using NO_HZ_FULL can help help make things faster on some
workloads.
> > The arm/rpc timer seems to be roughly in the same category as most of
> > the m68k ones or the i8253 counter on a PC. It's possible that some of
> > them could use the same logic as drivers/clocksource/i8253.o as long as
> > there is any hardware oneshot mode.
> >
>
> There appear to be 15 platforms in that category. 4 have no clocksource
> besides the jiffies clocksource, meaning there's no practical alternative
> to using a periodic tick, like you did in your RFC patch:
>
> arch/m68k/apollo/config.c
> arch/m68k/q40/q40ints.c
> arch/m68k/sun3/sun3ints.c
> arch/m68k/sun3x/time.c
Do any of these have users? I'm fairly sure sun3x has never worked in mainline,
sun3 seems to still need the same few patches it did 20 years ago. I
couldn't find
much about Linux on Apollo or q40, the information on the web for either
of them seems to all be for linux-2.4 kernels.
> The other 11 platforms in that category also have 'synthetic' clocksources
> derived from a timer reload interrupt. In 3 cases, the clocksource read
> method does not (or can not) check for a pending counter reload interrupt.
> For these also, I see no practical alternative to the approach you've
> taken in your RFC patch:
>
> arch/m68k/68000/timers.c
> arch/m68k/atari/time.c
> arch/m68k/coldfire/timers.c
Agreed. It's possible there is a way, but I don't see one either.
> That leaves 8 platforms that have reliable clocksource devices which
> should be able to provide an accurate reading even in the presence of a
> dropped tick (due to drivers disabling interrupts for too long):
>
> arch/arm/mach-rpc/time.c
> arch/m68k/amiga/config.c
> arch/m68k/bvme6000/config.c
> arch/m68k/coldfire/sltimers.c
> arch/m68k/hp300/time.c
> arch/m68k/mac/via.c
> arch/m68k/mvme147/config.c
> arch/m68k/mvme16x/config.c
>
> But is there any reason to adopt a oneshot tick on any of these platforms,
> if NO_HZ won't eliminate the timer interrupt that's needed to run a
> 'synthetic' clocksource?
I would expect that these could be changed to behave more like
drivers/clocksource/i8253.c, which does support a clocksource
in oneshot mode.
Arnd
_______________________________________________
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] 43+ messages in thread* Re: [RFC 13/13] m68k: mac: convert to generic clockevent
2020-10-23 7:52 ` Arnd Bergmann
@ 2020-10-23 9:24 ` Geert Uytterhoeven
2020-10-25 12:45 ` Geert Uytterhoeven
2020-11-06 2:52 ` Finn Thain
2020-10-30 0:41 ` Finn Thain
1 sibling, 2 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2020-10-23 9:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
linux-kernel, Finn Thain, Russell King, James E.J. Bottomley,
linux-m68k, Thomas Gleixner, Linux ARM, John Stultz,
Philip Blundell, Greg Ungerer, Joshua Thompson
Hi Arnd,
On Fri, Oct 23, 2020 at 9:52 AM Arnd Bergmann <arnd@kernel.org> wrote:
> On Sun, Oct 18, 2020 at 2:55 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> > On Thu, 15 Oct 2020, Arnd Bergmann wrote:
> > > On Thu, Oct 15, 2020 at 3:19 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> > > > On Sat, 10 Oct 2020, Arnd Bergmann wrote:
> >
> > That configuration still produces the same 5 KiB of bloat. I see that
> > kernel/time/Kconfig has this --
> >
> > # Core internal switch. Selected by NO_HZ_COMMON / HIGH_RES_TIMERS. This is
> > # only related to the tick functionality. Oneshot clockevent devices
> > # are supported independent of this.
> > config TICK_ONESHOT
> > bool
> >
> > But my question was really about both kinds of dead code (oneshot device
> > support and oneshot tick support). Anyway, after playing with the code for
> > a bit I don't see any easy way to reduce the growth in text size.
>
> Did you look more deeply into where those 5KB are? Is this just
> the code in kernel/time/{clockevents,tick-common}.c and the
> added platform specific bits, or is there something more?
> I suppose the sysfs interface and the clockevents_update_freq()
> logic are not really needed on m68k, but it wouldn't make much
> sense to split those out either.
>
> How does the 5KB bloat compare to the average bloat we get
> from one release to the next? Geert has been collecting statistics
> for this.
It would be a fair share of the typical increase of ca. 30 KiB per
kernel release. Still, it would be lost in the noise of the increase for
v5.10-rc1:
add/remove: 1200/455 grow/shrink: 1419/821 up/down: 468970/-93714 (375256)
Function old new delta
_printk_rb_static_infos - 180224 +180224
write_buf 8192 32768 +24576
_printk_rb_static_descs - 24576 +24576
HUF_decompress4X4_usingDTable_internal - 5664 +5664
HUF_decompress4X2_usingDTable_internal - 5006 +5006
__ext4_ioctl - 4774 +4774
sock_ops_convert_ctx_access 3840 8462 +4622
ZSTD_decompressSequences - 3100 +3100
> > > The arm/rpc timer seems to be roughly in the same category as most of
> > > the m68k ones or the i8253 counter on a PC. It's possible that some of
> > > them could use the same logic as drivers/clocksource/i8253.o as long as
> > > there is any hardware oneshot mode.
> >
> > There appear to be 15 platforms in that category. 4 have no clocksource
> > besides the jiffies clocksource, meaning there's no practical alternative
> > to using a periodic tick, like you did in your RFC patch:
> >
> > arch/m68k/apollo/config.c
> > arch/m68k/q40/q40ints.c
> > arch/m68k/sun3/sun3ints.c
> > arch/m68k/sun3x/time.c
>
> Do any of these have users? I'm fairly sure sun3x has never worked in mainline,
> sun3 seems to still need the same few patches it did 20 years ago. I
> couldn't find
> much about Linux on Apollo or q40, the information on the web for either
> of them seems to all be for linux-2.4 kernels.
They probably don't have any users.
AFAIK, the only users are the usual triumvirate of amiga/atari/mac
(and perhaps the fleet of VME boards in the Australian navy? ;)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] 43+ messages in thread* Re: [RFC 13/13] m68k: mac: convert to generic clockevent
2020-10-23 9:24 ` Geert Uytterhoeven
@ 2020-10-25 12:45 ` Geert Uytterhoeven
2020-11-06 2:52 ` Finn Thain
1 sibling, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2020-10-25 12:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
linux-kernel, Finn Thain, Russell King, James E.J. Bottomley,
linux-m68k, Thomas Gleixner, Linux ARM, John Stultz,
Philip Blundell, Greg Ungerer, Joshua Thompson
On Fri, Oct 23, 2020 at 11:24 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Oct 23, 2020 at 9:52 AM Arnd Bergmann <arnd@kernel.org> wrote:
> > On Sun, Oct 18, 2020 at 2:55 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> > > On Thu, 15 Oct 2020, Arnd Bergmann wrote:
> > > > On Thu, Oct 15, 2020 at 3:19 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> > > > > On Sat, 10 Oct 2020, Arnd Bergmann wrote:
> > >
> > > That configuration still produces the same 5 KiB of bloat. I see that
> > > kernel/time/Kconfig has this --
> > >
> > > # Core internal switch. Selected by NO_HZ_COMMON / HIGH_RES_TIMERS. This is
> > > # only related to the tick functionality. Oneshot clockevent devices
> > > # are supported independent of this.
> > > config TICK_ONESHOT
> > > bool
> > >
> > > But my question was really about both kinds of dead code (oneshot device
> > > support and oneshot tick support). Anyway, after playing with the code for
> > > a bit I don't see any easy way to reduce the growth in text size.
> >
> > Did you look more deeply into where those 5KB are? Is this just
> > the code in kernel/time/{clockevents,tick-common}.c and the
> > added platform specific bits, or is there something more?
> > I suppose the sysfs interface and the clockevents_update_freq()
> > logic are not really needed on m68k, but it wouldn't make much
> > sense to split those out either.
> >
> > How does the 5KB bloat compare to the average bloat we get
> > from one release to the next? Geert has been collecting statistics
> > for this.
>
> It would be a fair share of the typical increase of ca. 30 KiB per
> kernel release. Still, it would be lost in the noise of the increase for
> v5.10-rc1:
>
> add/remove: 1200/455 grow/shrink: 1419/821 up/down: 468970/-93714 (375256)
> Function old new delta
> _printk_rb_static_infos - 180224 +180224
> write_buf 8192 32768 +24576
> _printk_rb_static_descs - 24576 +24576
> HUF_decompress4X4_usingDTable_internal - 5664 +5664
> HUF_decompress4X2_usingDTable_internal - 5006 +5006
> __ext4_ioctl - 4774 +4774
> sock_ops_convert_ctx_access 3840 8462 +4622
> ZSTD_decompressSequences - 3100 +3100
FTR, 3.9 KiB reclaimed by upgrading from gcc 8.4.0 in Ubuntu 18.04LTS to
gcc 9.3.0 in Ubuntu 20.04LTS.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] 43+ messages in thread* Re: [RFC 13/13] m68k: mac: convert to generic clockevent
2020-10-23 9:24 ` Geert Uytterhoeven
2020-10-25 12:45 ` Geert Uytterhoeven
@ 2020-11-06 2:52 ` Finn Thain
2020-11-16 23:27 ` Sam Creasey
1 sibling, 1 reply; 43+ messages in thread
From: Finn Thain @ 2020-11-06 2:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sam Creasey, Arnd Bergmann, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Fenghua Yu, Stephen Boyd, Helge Deller,
Daniel Lezcano, linux-kernel, Russell King, James E.J. Bottomley,
linux-m68k, Thomas Gleixner, Linux ARM, John Stultz,
Philip Blundell, Greg Ungerer, Joshua Thompson
On Fri, 23 Oct 2020, Geert Uytterhoeven wrote:
> > > > The arm/rpc timer seems to be roughly in the same category as most
> > > > of the m68k ones or the i8253 counter on a PC. It's possible that
> > > > some of them could use the same logic as
> > > > drivers/clocksource/i8253.o as long as there is any hardware
> > > > oneshot mode.
> > >
> > > There appear to be 15 platforms in that category. 4 have no
> > > clocksource besides the jiffies clocksource, meaning there's no
> > > practical alternative to using a periodic tick, like you did in your
> > > RFC patch:
> > >
> > > arch/m68k/apollo/config.c
> > > arch/m68k/q40/q40ints.c
> > > arch/m68k/sun3/sun3ints.c
> > > arch/m68k/sun3x/time.c
> >
> > Do any of these have users? I'm fairly sure sun3x has never worked in
> > mainline, sun3 seems to still need the same few patches it did 20
> > years ago. I couldn't find much about Linux on Apollo or q40, the
> > information on the web for either of them seems to all be for
> > linux-2.4 kernels.
>
> They probably don't have any users.
I have access to several Sun 3 machines but no time to work on that port,
unfortunately.
Are these 4 platforms (those with no clocksource besides the "jiffies"
clocksource) the only reason for CONFIG_TIME_LOW_RES on m68k?
_______________________________________________
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] 43+ messages in thread
* Re: [RFC 13/13] m68k: mac: convert to generic clockevent
2020-11-06 2:52 ` Finn Thain
@ 2020-11-16 23:27 ` Sam Creasey
0 siblings, 0 replies; 43+ messages in thread
From: Sam Creasey @ 2020-11-16 23:27 UTC (permalink / raw)
To: Finn Thain
Cc: Sam Creasey, Arnd Bergmann, Linus Walleij, Tony Luck,
Thomas Gleixner, Parisc List, Fenghua Yu, Stephen Boyd,
Helge Deller, Daniel Lezcano, linux-kernel, Russell King,
James E.J. Bottomley, linux-ia64, Geert Uytterhoeven, Linux ARM,
John Stultz, Philip Blundell, linux-m68k, Greg Ungerer,
Joshua Thompson
On Fri, Nov 06, 2020 at 01:52:01PM +1100, Finn Thain wrote:
> On Fri, 23 Oct 2020, Geert Uytterhoeven wrote:
>
> > > > > The arm/rpc timer seems to be roughly in the same category as most
> > > > > of the m68k ones or the i8253 counter on a PC. It's possible that
> > > > > some of them could use the same logic as
> > > > > drivers/clocksource/i8253.o as long as there is any hardware
> > > > > oneshot mode.
> > > >
> > > > There appear to be 15 platforms in that category. 4 have no
> > > > clocksource besides the jiffies clocksource, meaning there's no
> > > > practical alternative to using a periodic tick, like you did in your
> > > > RFC patch:
> > > >
> > > > arch/m68k/apollo/config.c
> > > > arch/m68k/q40/q40ints.c
> > > > arch/m68k/sun3/sun3ints.c
> > > > arch/m68k/sun3x/time.c
> > >
> > > Do any of these have users? I'm fairly sure sun3x has never worked in
> > > mainline, sun3 seems to still need the same few patches it did 20
> > > years ago. I couldn't find much about Linux on Apollo or q40, the
> > > information on the web for either of them seems to all be for
> > > linux-2.4 kernels.
> >
> > They probably don't have any users.
>
> I have access to several Sun 3 machines but no time to work on that port,
> unfortunately.
>
> Are these 4 platforms (those with no clocksource besides the "jiffies"
> clocksource) the only reason for CONFIG_TIME_LOW_RES on m68k?
Sun3x was probably at least as close (if not closer) than Sun3 to
working in mainline back in the day, but unfortunately I'm in the same
place as Finn... I've got the hardware, but time is harder to come
by.
-- Sam
_______________________________________________
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] 43+ messages in thread
* Re: [RFC 13/13] m68k: mac: convert to generic clockevent
2020-10-23 7:52 ` Arnd Bergmann
2020-10-23 9:24 ` Geert Uytterhoeven
@ 2020-10-30 0:41 ` Finn Thain
2020-10-30 13:12 ` Greg Ungerer
1 sibling, 1 reply; 43+ messages in thread
From: Finn Thain @ 2020-10-30 0:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck,
Thomas Gleixner, Parisc List, linux-ia64, Stephen Boyd,
Helge Deller, Daniel Lezcano, linux-kernel, Russell King,
James E.J. Bottomley, linux-m68k, Geert Uytterhoeven, Linux ARM,
John Stultz, Philip Blundell, Greg Ungerer, Joshua Thompson
On Fri, 23 Oct 2020, Arnd Bergmann wrote:
> On Sun, Oct 18, 2020 at 2:55 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> > On Thu, 15 Oct 2020, Arnd Bergmann wrote:
> > > On Thu, Oct 15, 2020 at 3:19 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> > > > On Sat, 10 Oct 2020, Arnd Bergmann wrote:
> >
> > That configuration still produces the same 5 KiB of bloat. I see that
> > kernel/time/Kconfig has this --
> >
> > # Core internal switch. Selected by NO_HZ_COMMON / HIGH_RES_TIMERS. This is
> > # only related to the tick functionality. Oneshot clockevent devices
> > # are supported independent of this.
> > config TICK_ONESHOT
> > bool
> >
> > But my question was really about both kinds of dead code (oneshot
> > device support and oneshot tick support). Anyway, after playing with
> > the code for a bit I don't see any easy way to reduce the growth in
> > text size.
>
> Did you look more deeply into where those 5KB are? Is this just the code
> in kernel/time/{clockevents,tick-common}.c and the added platform
> specific bits, or is there something more?
What I did was to list the relevant functions using scripts/bloat-o-meter
and tried stubbing out some code related to oneshot clockevent devices. I
didn't find any low fruit and don't plan to pursue that without the help
of LTO.
> I suppose the sysfs interface and the clockevents_update_freq() logic
> are not really needed on m68k, but it wouldn't make much sense to split
> those out either.
>
> How does the 5KB bloat compare to the average bloat we get from one
> release to the next? Geert has been collecting statistics for this.
>
Perhaps that 5 KB is justified by gaining the hrtimers feature... hard to
say; it's never been available on these platforms. I can see the value in
it though.
> > > Yes, makes sense. I think the one remaining problem with the
> > > periodic mode in this driver is that it can drop timer ticks when
> > > interrupts are disabled for too long, while in oneshot mode there
> > > may be a way to know how much time has passed since the last tick as
> > > long as the counter does not overflow.
> >
> > Is there any benefit from adopting a oneshot tick (rather than
> > periodic) if no clocksource is consulted when calculating the next
> > interval? (I'm assuming NO_HZ is not in use, for reasons discussed
> > below.)
>
> If the clocksource does not set CLOCK_SOURCE_IS_CONTINOUS, the kernel
> will keep using periodic timers and not allow hrtimers.
>
IIUC, when HIGH_RES_TIMERS=y, the kernel will enable hrtimers only if the
platform provides both a continuous clocksource device and a oneshot
clockevent device. However, the "jiffies" clocksource does not set
CLOCK_SOURCE_IS_CONTINOUS and neither does the one in
arch/arm/mach-rpc/time.c.
When HIGH_RES_TIMERS=n and NO_HZ_COMMON=n (which is presently the case for
all platforms with GENERIC_CLOCKEVENTS=n) there's no use for a oneshot
clockevent device, right?
It seems likely that NO_HZ_COMMON=n because the clocksources on these
platforms produce a periodic interrupt regardless (e.g.
clocksource/i8253.c, arm/rpc, m68k platform timers etc.).
Finally, HIGH_RES_TIMERS=n seems likely if the only clocksource is
unreliable (e.g. because it loses time due to interrupt priorities). There
may be a few of platforms in this category (Mac, Atari?).
> > > I would agree that despite this oneshot mode is probably worse
> > > overall for timekeeping if the register accesses introduce
> > > systematic errors.
> > >
> >
> > It probably has to be tried. But consulting a VIA clocksource on every
> > tick would be expensive on this platform, so if that was the only way
> > to avoid cumulative errors, I'd probably just stick with the periodic
> > tick.
>
> I'm sure there is a tradeoff somewhere. Without hrtimers, some events
> will take longer when they have to wait for the next tick, and using
> NO_HZ_FULL can help help make things faster on some workloads.
>
Yes, such a tradeoff is discussed in drivers/iio/adc/ep93xx_adc.c.
But OTOH, Documentation/timers/timers-howto.rst says,
On slower systems, (embedded, OR perhaps a speed-stepped PC!) the
overhead of setting up the hrtimers for usleep *may* not be worth it
I guess it has to be tried.
> ...
> > The other 11 platforms in that category also have 'synthetic'
> > clocksources derived from a timer reload interrupt. In 3 cases, the
> > clocksource read method does not (or can not) check for a pending
> > counter reload interrupt. For these also, I see no practical
> > alternative to the approach you've taken in your RFC patch:
> >
> > arch/m68k/68000/timers.c
> > arch/m68k/atari/time.c
> > arch/m68k/coldfire/timers.c
>
> Agreed. It's possible there is a way, but I don't see one either.
>
For arch/m68k/68000/timers.c, I suppose we may be able to check for the
TMR1 bit in the Interrupt Status Register at 0xFFFFF30C or the COMP bit in
the Timer Status Register at 0xFFFFF60A. But testing that patch could be
difficult.
I expect that equivalent flags are available in Coldfire registers, making
it possible to improve upon mcftmr_read_clk() and m68328_read_clk() if
need be -- that is, if it turns out that the clocksource interrupt was
subject to higher priority IRQs that would slow down the clocksource or
defeat its monotonicity.
The other difficulty is a lack of hardware timers. There's only one timer
on MC68EZ328. On Atari, for now only Timer C is available though Michael
has said that it would be possible to free up Timer D. Some Coldfire chips
have only 2 timers and the second timer seems to be allocated to
profiling.
> > That leaves 8 platforms that have reliable clocksource devices which
> > should be able to provide an accurate reading even in the presence of
> > a dropped tick (due to drivers disabling interrupts for too long):
> >
> > arch/arm/mach-rpc/time.c
> > arch/m68k/amiga/config.c
> > arch/m68k/bvme6000/config.c
> > arch/m68k/coldfire/sltimers.c
> > arch/m68k/hp300/time.c
> > arch/m68k/mac/via.c
> > arch/m68k/mvme147/config.c
> > arch/m68k/mvme16x/config.c
> >
> > But is there any reason to adopt a oneshot tick on any of these platforms,
> > if NO_HZ won't eliminate the timer interrupt that's needed to run a
> > 'synthetic' clocksource?
>
> I would expect that these could be changed to behave more like
> drivers/clocksource/i8253.c, which does support a clocksource in oneshot
> mode.
>
I think you meant to write, "... support a clockevent device in oneshot
mode". I would agree.
Since Macs do have a spare hardware timer, I will attempt to convert
arch/m68k/mac/via.c to a oneshot clockevent, using your
GENERIC_CLOCKEVENTS patch series as a basis, and see what effect that has
in the NO_HZ_COMMON=n, HIGH_RES_TIMERS=y case.
> Arnd
>
_______________________________________________
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] 43+ messages in thread* Re: [RFC 13/13] m68k: mac: convert to generic clockevent
2020-10-30 0:41 ` Finn Thain
@ 2020-10-30 13:12 ` Greg Ungerer
2020-11-06 3:12 ` Finn Thain
0 siblings, 1 reply; 43+ messages in thread
From: Greg Ungerer @ 2020-10-30 13:12 UTC (permalink / raw)
To: Finn Thain, Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Stephen Boyd, Helge Deller, Daniel Lezcano,
linux-kernel, Russell King, James E.J. Bottomley, linux-m68k,
Geert Uytterhoeven, Linux ARM, John Stultz, Philip Blundell,
Thomas Gleixner, Joshua Thompson
On 30/10/20 10:41 am, Finn Thain wrote:
> On Fri, 23 Oct 2020, Arnd Bergmann wrote:
>> On Sun, Oct 18, 2020 at 2:55 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>>> On Thu, 15 Oct 2020, Arnd Bergmann wrote:
>>>> On Thu, Oct 15, 2020 at 3:19 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>>>>> On Sat, 10 Oct 2020, Arnd Bergmann wrote:
>>>
>>> That configuration still produces the same 5 KiB of bloat. I see that
>>> kernel/time/Kconfig has this --
>>>
>>> # Core internal switch. Selected by NO_HZ_COMMON / HIGH_RES_TIMERS. This is
>>> # only related to the tick functionality. Oneshot clockevent devices
>>> # are supported independent of this.
>>> config TICK_ONESHOT
>>> bool
>>>
>>> But my question was really about both kinds of dead code (oneshot
>>> device support and oneshot tick support). Anyway, after playing with
>>> the code for a bit I don't see any easy way to reduce the growth in
>>> text size.
>>
>> Did you look more deeply into where those 5KB are? Is this just the code
>> in kernel/time/{clockevents,tick-common}.c and the added platform
>> specific bits, or is there something more?
>
> What I did was to list the relevant functions using scripts/bloat-o-meter
> and tried stubbing out some code related to oneshot clockevent devices. I
> didn't find any low fruit and don't plan to pursue that without the help
> of LTO.
>
>> I suppose the sysfs interface and the clockevents_update_freq() logic
>> are not really needed on m68k, but it wouldn't make much sense to split
>> those out either.
>>
>> How does the 5KB bloat compare to the average bloat we get from one
>> release to the next? Geert has been collecting statistics for this.
>>
>
> Perhaps that 5 KB is justified by gaining the hrtimers feature... hard to
> say; it's never been available on these platforms. I can see the value in
> it though.
>
>>>> Yes, makes sense. I think the one remaining problem with the
>>>> periodic mode in this driver is that it can drop timer ticks when
>>>> interrupts are disabled for too long, while in oneshot mode there
>>>> may be a way to know how much time has passed since the last tick as
>>>> long as the counter does not overflow.
>>>
>>> Is there any benefit from adopting a oneshot tick (rather than
>>> periodic) if no clocksource is consulted when calculating the next
>>> interval? (I'm assuming NO_HZ is not in use, for reasons discussed
>>> below.)
>>
>> If the clocksource does not set CLOCK_SOURCE_IS_CONTINOUS, the kernel
>> will keep using periodic timers and not allow hrtimers.
>>
>
> IIUC, when HIGH_RES_TIMERS=y, the kernel will enable hrtimers only if the
> platform provides both a continuous clocksource device and a oneshot
> clockevent device. However, the "jiffies" clocksource does not set
> CLOCK_SOURCE_IS_CONTINOUS and neither does the one in
> arch/arm/mach-rpc/time.c.
>
> When HIGH_RES_TIMERS=n and NO_HZ_COMMON=n (which is presently the case for
> all platforms with GENERIC_CLOCKEVENTS=n) there's no use for a oneshot
> clockevent device, right?
>
> It seems likely that NO_HZ_COMMON=n because the clocksources on these
> platforms produce a periodic interrupt regardless (e.g.
> clocksource/i8253.c, arm/rpc, m68k platform timers etc.).
>
> Finally, HIGH_RES_TIMERS=n seems likely if the only clocksource is
> unreliable (e.g. because it loses time due to interrupt priorities). There
> may be a few of platforms in this category (Mac, Atari?).
>
>>>> I would agree that despite this oneshot mode is probably worse
>>>> overall for timekeeping if the register accesses introduce
>>>> systematic errors.
>>>>
>>>
>>> It probably has to be tried. But consulting a VIA clocksource on every
>>> tick would be expensive on this platform, so if that was the only way
>>> to avoid cumulative errors, I'd probably just stick with the periodic
>>> tick.
>>
>> I'm sure there is a tradeoff somewhere. Without hrtimers, some events
>> will take longer when they have to wait for the next tick, and using
>> NO_HZ_FULL can help help make things faster on some workloads.
>>
>
> Yes, such a tradeoff is discussed in drivers/iio/adc/ep93xx_adc.c.
>
> But OTOH, Documentation/timers/timers-howto.rst says,
>
> On slower systems, (embedded, OR perhaps a speed-stepped PC!) the
> overhead of setting up the hrtimers for usleep *may* not be worth it
>
> I guess it has to be tried.
>
>> ...
>>> The other 11 platforms in that category also have 'synthetic'
>>> clocksources derived from a timer reload interrupt. In 3 cases, the
>>> clocksource read method does not (or can not) check for a pending
>>> counter reload interrupt. For these also, I see no practical
>>> alternative to the approach you've taken in your RFC patch:
>>>
>>> arch/m68k/68000/timers.c
>>> arch/m68k/atari/time.c
>>> arch/m68k/coldfire/timers.c
>>
>> Agreed. It's possible there is a way, but I don't see one either.
>>
>
> For arch/m68k/68000/timers.c, I suppose we may be able to check for the
> TMR1 bit in the Interrupt Status Register at 0xFFFFF30C or the COMP bit in
> the Timer Status Register at 0xFFFFF60A. But testing that patch could be
> difficult.
>
> I expect that equivalent flags are available in Coldfire registers, making
> it possible to improve upon mcftmr_read_clk() and m68328_read_clk() if
> need be -- that is, if it turns out that the clocksource interrupt was
> subject to higher priority IRQs that would slow down the clocksource or
> defeat its monotonicity.
>
> The other difficulty is a lack of hardware timers. There's only one timer
> on MC68EZ328. On Atari, for now only Timer C is available though Michael
> has said that it would be possible to free up Timer D. Some Coldfire chips
> have only 2 timers and the second timer seems to be allocated to
> profiling.
FWIW, I would have no problem with ditching the profiling clock,
and using both on ColdFire platforms that have this. I doubt anyone has
used that profiling setup in a _very_ long time.
Regards
Greg
_______________________________________________
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] 43+ messages in thread* Re: [RFC 13/13] m68k: mac: convert to generic clockevent
2020-10-30 13:12 ` Greg Ungerer
@ 2020-11-06 3:12 ` Finn Thain
0 siblings, 0 replies; 43+ messages in thread
From: Finn Thain @ 2020-11-06 3:12 UTC (permalink / raw)
To: Greg Ungerer
Cc: Sam Creasey, Arnd Bergmann, Linus Walleij, Tony Luck, linux-ia64,
Parisc List, Fenghua Yu, Stephen Boyd, Helge Deller,
Daniel Lezcano, linux-kernel, Russell King, James E.J. Bottomley,
linux-m68k, Geert Uytterhoeven, Linux ARM, John Stultz,
Philip Blundell, Thomas Gleixner, Joshua Thompson
On Fri, 30 Oct 2020, Greg Ungerer wrote:
> >
> > > ...
> > > > The other 11 platforms in that category also have 'synthetic'
> > > > clocksources derived from a timer reload interrupt. In 3 cases,
> > > > the clocksource read method does not (or can not) check for a
> > > > pending counter reload interrupt. For these also, I see no
> > > > practical alternative to the approach you've taken in your RFC
> > > > patch:
> > > >
> > > > arch/m68k/68000/timers.c
> > > > arch/m68k/atari/time.c
> > > > arch/m68k/coldfire/timers.c
> > >
> > > Agreed. It's possible there is a way, but I don't see one either.
> > >
> >
> > For arch/m68k/68000/timers.c, I suppose we may be able to check for
> > the TMR1 bit in the Interrupt Status Register at 0xFFFFF30C or the
> > COMP bit in the Timer Status Register at 0xFFFFF60A. But testing that
> > patch could be difficult.
> >
> > I expect that equivalent flags are available in Coldfire registers,
> > making it possible to improve upon mcftmr_read_clk() and
> > m68328_read_clk() if need be -- that is, if it turns out that the
> > clocksource interrupt was subject to higher priority IRQs that would
> > slow down the clocksource or defeat its monotonicity.
> >
> > The other difficulty is a lack of hardware timers. There's only one
> > timer on MC68EZ328. On Atari, for now only Timer C is available though
> > Michael has said that it would be possible to free up Timer D. Some
> > Coldfire chips have only 2 timers and the second timer seems to be
> > allocated to profiling.
>
> FWIW, I would have no problem with ditching the profiling clock, and
> using both on ColdFire platforms that have this. I doubt anyone has used
> that profiling setup in a _very_ long time.
>
If we ditched the Coldfire profiling clock, it would be possible to
dedicate one hardware timer to the clocksource device and the other to the
(oneshot) clockevent device.
That's a win if it means that the clocksource can use the full counter
width (making timer interrupts less frequent and timer interrupt latency
less problematic) and run at higher frequency (making the clocksource more
precise).
Also, note that hrtimers won't work with a periodic clockevent device (as
in Arnd's RFC patch). If you want hrtimers, I think you'll need both
hardware timers or else re-implement the existing synthetic clocksource
using the same oneshot timer driving a new oneshot clockevent device.
Please note that the lack of a spare hardware timer is a separate issue to
the failure of mcftmr_read_clk() and m68328_read_clk() to check the timer
reload interrupt flag (which may make those clocksources needlessly
susceptible to issues caused by timer interrupt latency...).
_______________________________________________
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] 43+ messages in thread
* Re: [PATCH 00/13] Clean up legacy clock tick users
2020-10-08 15:46 [PATCH 00/13] Clean up legacy clock tick users Arnd Bergmann
` (12 preceding siblings ...)
2020-10-08 15:46 ` [RFC 13/13] m68k: mac: convert to generic clockevent Arnd Bergmann
@ 2020-10-12 22:18 ` Linus Walleij
13 siblings, 0 replies; 43+ messages in thread
From: Linus Walleij @ 2020-10-12 22:18 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Creasey, Fenghua Yu, linux-ia64, Tony Luck, Thomas Gleixner,
linux-parisc, Stephen Boyd, Helge Deller, Daniel Lezcano,
linux-kernel, Finn Thain, Russell King, James E.J. Bottomley,
linux-m68k, Geert Uytterhoeven, Linux ARM, John Stultz,
Philip Blundell, Greg Ungerer, Joshua Thompson
On Thu, Oct 8, 2020 at 5:47 PM Arnd Bergmann <arnd@arndb.de> wrote:
> When I created the patch removing CONFIG_ARCH_GETTIMEOFFSET,
> I also had a look at CONFIG_GENERIC_CLOCKEVENTS, which is
> selected by most, but not all, platforms today, each of the
> ones that lack it doing the timer tick slightly differently.
>
> The cleanups here make the old platforms a bit more
> consistent, in multiple ways:
>
> - rather than selecting GENERIC_CLOCKEVENTS on modern
> platforms, select LEGACY_TIMER_TICK on the old ones.
>
> - Hide some more of the internal implementation and only
> provide a single common entry point for the timer tick,
> which also makes the behavior more consistent.
>
> - Remove the m68k and arm specific infrastructure pieces
> and call the common helper directly from each timer
> interrupt function.
>
> I tested the series on m68k with the qemu q800 target
> platform, both with the legacy_timer_tick() implementation
> and after converting that to a periodic clockevent driver.
I am a big fan of this patch series:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Maybe the RFC patch can be kept in the sidelines but the
rest should be merged ASAP in my opinion, the kernel just
looks so much better after this.
Yours,
Linus Walleij
_______________________________________________
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] 43+ messages in thread