armv8: Allow SoCs to override the generic timer
Subsystems (3)
PATCH 1/1 armv8: Allow SoCs to override the generic timer
From: Thierry Reding <[email protected]>
Some SoCs come with a custom timer interface, so allow them to use that instead.
swarren notes: I did consider reworking this patch so the Makefile only compiles generic_timer.c ifndef CONFIG_SYS_TIMER_COUNTER. However, I can foresee a time where generic_timer.c contains both routines to implement U-Boot's internal timer, and to perform other operations related to the generic timer, such as initializing the CNTFRQ register for a booted OS. If that happens, this version of the change will result in simpler future patches.
--- arch/arm/cpu/armv8/generic_timer.c | 2 ++ 1 file changed, 2 insertions(+)
arch/arm/cpu/armv8/generic_timer.c +2 -0
@@ -9,6 +9,7 @@#include <command.h> #include <asm/system.h> +#ifndef CONFIG_SYS_TIMER_COUNTER /* * Generic timer implementation of get_tbclk() */
@@ -40,3 +41,4 @@ unsigned long timer_read_counter(void)#endif return cntpct; } +#endif
Signature · 1 line
1.9.1
PATCH 1/1 armv8: Allow SoCs to override the generic timer
Quoted 13 lines · Stephen Warren
From: Thierry Reding <[email protected]>
Some SoCs come with a custom timer interface, so allow them to use that instead.
swarren notes: I did consider reworking this patch so the
Makefileonly compilesgeneric_timer.cifndefCONFIG_SYS_TIMER_COUNTER. However, I can foresee a time wheregeneric_timer.ccontains both routines to implement U-Boot's internal timer, and to perform other operations related to the generic timer, such as initializing the CNTFRQ register for a booted OS. If that happens, this version of the change will result in simpler future patches.
Quoted 6 lines
Signed-off-by Thierry Reding <[email protected]>Signed-off-by Tom Warren <[email protected]>Signed-off-by Stephen Warren <[email protected]>--- arch/arm/cpu/armv8/generic_timer.c | 2 ++ 1 file changed, 2 insertions(+)
PATCH 1/1 armv8: Allow SoCs to override the generic timer
In reply to Stephen WarrenQuoted 13 lines · Stephen Warren
From: Thierry Reding <[email protected]>
Some SoCs come with a custom timer interface, so allow them to use that instead.
swarren notes: I did consider reworking this patch so the
Makefileonly compilesgeneric_timer.cifndefCONFIG_SYS_TIMER_COUNTER. However, I can foresee a time wheregeneric_timer.ccontains both routines to implement U-Boot's internal timer, and to perform other operations related to the generic timer, such as initializing the CNTFRQ register for a booted OS. If that happens, this version of the change will result in simpler future patches.
Quoted 3 lines
Signed-off-by Thierry Reding <[email protected]>Signed-off-by Tom Warren <[email protected]>Signed-off-by Stephen Warren <[email protected]>
Quoted 3 lines
Signature · 1 line
1.9.1
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150723/2abb6de4/attachment.sig>
PATCH 1/1 armv8: Allow SoCs to override the generic timer
In reply to Stephen WarrenQuoted 13 lines · Stephen Warren
From: Thierry Reding <[email protected]>
Some SoCs come with a custom timer interface, so allow them to use that instead.
swarren notes: I did consider reworking this patch so the
Makefileonly compilesgeneric_timer.cifndefCONFIG_SYS_TIMER_COUNTER. However, I can foresee a time wheregeneric_timer.ccontains both routines to implement U-Boot's internal timer, and to perform other operations related to the generic timer, such as initializing the CNTFRQ register for a booted OS. If that happens, this version of the change will result in simpler future patches.
Quoted 6 lines
Signed-off-by Thierry Reding <[email protected]>Signed-off-by Tom Warren <[email protected]>Signed-off-by Stephen Warren <[email protected]>--- arch/arm/cpu/armv8/generic_timer.c | 2 ++ 1 file changed, 2 insertions(+)
Marc Zyngier and David Feng had objections to this when I posted[0]. I ended up solving this differently, by initializing the architectural timer earlier and then using the architected timer on ARM64.
I'll post the two patches I have in my tree as a replacement for this and sorry for causing such a mess.
Thierry
[0]: http://lists.denx.de/pipermail/u-boot/2015-March/208505.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150728/74770271/attachment.sig>
PATCH 1/2 ARM: tegra: Initialize timer earlier
In reply to Stephen WarrenFrom: Thierry Reding <[email protected]>
A subsequent patch will enable the use of the architected timer on ARMv8. Doing so implies that udelay() will be backed by this timer implementation, and hence the architected timer must be ready when udelay() is first called. The first time udelay() is used is while resetting the debug UART, which happens very early. Make sure that arch_timer_init() is called before that.
--- arch/arm/mach-tegra/board2.c | 6 ++++++ arch/arm/mach-tegra/clock.c | 6 ------ 2 files changed, 6 insertions(+), 6 deletions(-)
arch/arm/mach-tegra/board2.c +6 -0
@@ -218,6 +218,12 @@ void gpio_early_init(void) __attribute__((weak, alias("__gpio_early_init")));int board_early_init_f (void ) { +/* Do any special system timer/TSC setup */ +#if defined(CONFIG_TEGRA_SUPPORT_NON_SECURE ) + if (!tegra_cpu_is_non_secure()) +#endif +arch_timer_init (); +pinmux_init ();board_init_uart_f ();
arch/arm/mach-tegra/clock.c +0 -6
@@ -618,12 +618,6 @@ void clock_init(void)debug ("PLLC = %d\n" , pll_rate[CLOCK_ID_CGENERAL ]);debug ("PLLD = %d\n" , pll_rate[CLOCK_ID_DISPLAY ]);debug ("PLLX = %d\n" , pll_rate[CLOCK_ID_XCPU ]); - -/* Do any special system timer/TSC setup */ -#if defined(CONFIG_TEGRA_SUPPORT_NON_SECURE ) - if (!tegra_cpu_is_non_secure()) -#endif -arch_timer_init (); }static void set_avp_clock_source (u32 src)
Signature · 1 line
2.4.5
PATCH 2/2 ARM: tegra: Use architected timer on ARMv8
From: Thierry Reding <[email protected]>
ARMv8 requires an architected timer to be present, so it can be used instead of the Tegra US timer. This allows for better code reuse.
--- include/configs/tegra-common.h | 3 +++ 1 file changed, 3 insertions(+)
include/configs/tegra-common.h +3 -0
@@ -18,8 +18,11 @@#include <asm/arch/tegra.h> /* get chip and board defs */ +/* Use the Tegra US timer on ARMv7, but the architected timer on ARMv8. */ +#ifndef CONFIG_ARM64 #define CONFIG_SYS_TIMER_RATE 1000000#define CONFIG_SYS_TIMER_COUNTER NV_PA_TMRUS_BASE +#endif /* * Display CPU and Board information
Signature · 1 line
2.4.5
PATCH 2/2 ARM: tegra: Use architected timer on ARMv8
Hi Thierry,
Quoted 27 lines · Thierry Reding
From: Thierry Reding <[email protected]>
ARMv8 requires an architected timer to be present, so it can be used instead of the Tegra US timer. This allows for better code reuse.
Signed-off-by Thierry Reding <[email protected]>--- include/configs/tegra-common.h | 3 +++ 1 file changed, 3 insertions(+)include/configs/tegra-common.h +3
-1@@ -18,8 +18,11 @@#include <asm/arch/tegra.h> /* get chip and board defs */ +/* Use the Tegra US timer on ARMv7, but the architected timer on ARMv8. */ +#ifndef CONFIG_ARM64 #define CONFIG_SYS_TIMER_RATE 1000000#define CONFIG_SYS_TIMER_COUNTER NV_PA_TMRUS_BASE +#endif /* * Display CPU and Board information --
Quoted 2 lines
2.4.5
Shouldn't this go in tegra210-common.h or similar?
Regards,
Simon
PATCH 1/2 ARM: tegra: Initialize timer earlier
In reply to Thierry RedingQuoted 8 lines · Thierry Reding
From: Thierry Reding <[email protected]>
A subsequent patch will enable the use of the architected timer on ARMv8. Doing so implies that
udelay()will be backed by this timer implementation, and hence the architected timer must be ready whenudelay()is first called. The first timeudelay()is used is while resetting the debug UART, which happens very early. Make sure thatarch_timer_init()is called before that.
The series,
Again I've tested these in the context of a downstream/L4T version of U-Boot and they worked out fine. However since I haven't tested the exact upstream code-base, I won't give a Tested-by tag.