[U-Boot] [PATCH 1/2] common: Remove timer_init() call for x86

With driver model timer support, there should not be an explict call to timer_init(). Remove this call for x86.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
common/board_f.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c index b035c90..92c42c5 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -807,7 +807,7 @@ static init_fnc_t init_sequence_f[] = { /* TODO: can we rename this to timer_init()? */ init_timebase, #endif -#if defined(CONFIG_X86) || defined(CONFIG_ARM) || defined(CONFIG_MIPS) || \ +#if defined(CONFIG_ARM) || defined(CONFIG_MIPS) || \ defined(CONFIG_BLACKFIN) || defined(CONFIG_NDS32) timer_init, /* initialize timer */ #endif

Right now i8254_init() is called from timer_init() in the tsc timer driver. But actually i8254 and tsc are completely different things. Since tsc timer has been converted to driver model, we should find a new place that is appropriate for U-Boot to call i8254_init(), which is now x86_cpu_init_f().
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/cpu.c | 5 +++++ drivers/timer/tsc_timer.c | 10 ---------- 2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c index 1707993..381d835 100644 --- a/arch/x86/cpu/cpu.c +++ b/arch/x86/cpu/cpu.c @@ -399,6 +399,11 @@ int x86_cpu_init_f(void) } }
+#ifdef CONFIG_I8254_TIMER + /* Set up the i8254 timer if required */ + i8254_init(); +#endif + return 0; }
diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c index 6aa2437..5c4ec00 100644 --- a/drivers/timer/tsc_timer.c +++ b/drivers/timer/tsc_timer.c @@ -325,16 +325,6 @@ void __udelay(unsigned long usec) #endif }
-int timer_init(void) -{ -#ifdef CONFIG_I8254_TIMER - /* Set up the i8254 timer if required */ - i8254_init(); -#endif - - return 0; -} - static int tsc_timer_get_count(struct udevice *dev, u64 *count) { u64 now_tick = rdtsc();

On 2 December 2015 at 02:30, Bin Meng bmeng.cn@gmail.com wrote:
Right now i8254_init() is called from timer_init() in the tsc timer driver. But actually i8254 and tsc are completely different things. Since tsc timer has been converted to driver model, we should find a new place that is appropriate for U-Boot to call i8254_init(), which is now x86_cpu_init_f().
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/cpu.c | 5 +++++ drivers/timer/tsc_timer.c | 10 ---------- 2 files changed, 5 insertions(+), 10 deletions(-)
Acked-by: Simon Glass sjg@chromium.org

Hi Bin,
On 2 December 2015 at 02:30, Bin Meng bmeng.cn@gmail.com wrote:
With driver model timer support, there should not be an explict call to timer_init(). Remove this call for x86.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
common/board_f.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c index b035c90..92c42c5 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -807,7 +807,7 @@ static init_fnc_t init_sequence_f[] = { /* TODO: can we rename this to timer_init()? */ init_timebase, #endif -#if defined(CONFIG_X86) || defined(CONFIG_ARM) || defined(CONFIG_MIPS) || \ +#if defined(CONFIG_ARM) || defined(CONFIG_MIPS) || \ defined(CONFIG_BLACKFIN) || defined(CONFIG_NDS32) timer_init, /* initialize timer */
#endif
1.8.2.1
Acked-by: Simon Glass sjg@chromium.org
I have two questions:
1. Should we define a point during boot where the timer becomes available? I can't think of a good reason, but we should think about it.
2. Should we provide an 'early timer' before DM is ready, a bit like we do with the UART?
Regards, Simon

Hi Simon,
On Thu, Dec 3, 2015 at 5:06 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 2 December 2015 at 02:30, Bin Meng bmeng.cn@gmail.com wrote:
With driver model timer support, there should not be an explict call to timer_init(). Remove this call for x86.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
common/board_f.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c index b035c90..92c42c5 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -807,7 +807,7 @@ static init_fnc_t init_sequence_f[] = { /* TODO: can we rename this to timer_init()? */ init_timebase, #endif -#if defined(CONFIG_X86) || defined(CONFIG_ARM) || defined(CONFIG_MIPS) || \ +#if defined(CONFIG_ARM) || defined(CONFIG_MIPS) || \ defined(CONFIG_BLACKFIN) || defined(CONFIG_NDS32) timer_init, /* initialize timer */
#endif
1.8.2.1
Acked-by: Simon Glass sjg@chromium.org
I have two questions:
- Should we define a point during boot where the timer becomes
available? I can't think of a good reason, but we should think about it.
I would rather not create such a special point for timer, instead we just use the generic driver model limitations for the timer as well. That is, with dm timer support, these U-Boot timer APIs should only be available after driver model is initialized.
- Should we provide an 'early timer' before DM is ready, a bit like
we do with the UART?
I cannot think of a use case that uses timer in that early time.
Regards, Bin

Hi Bin,
On Dec 2, 2015 18:52, "Bin Meng" bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Dec 3, 2015 at 5:06 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 2 December 2015 at 02:30, Bin Meng bmeng.cn@gmail.com wrote:
With driver model timer support, there should not be an explict call to timer_init(). Remove this call for x86.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
common/board_f.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c index b035c90..92c42c5 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -807,7 +807,7 @@ static init_fnc_t init_sequence_f[] = { /* TODO: can we rename this to timer_init()? */ init_timebase, #endif -#if defined(CONFIG_X86) || defined(CONFIG_ARM) ||
defined(CONFIG_MIPS) || \
+#if defined(CONFIG_ARM) || defined(CONFIG_MIPS) || \ defined(CONFIG_BLACKFIN) || defined(CONFIG_NDS32) timer_init, /* initialize timer */
#endif
1.8.2.1
Acked-by: Simon Glass sjg@chromium.org
I have two questions:
- Should we define a point during boot where the timer becomes
available? I can't think of a good reason, but we should think about it.
I would rather not create such a special point for timer, instead we just use the generic driver model limitations for the timer as well. That is, with dm timer support, these U-Boot timer APIs should only be available after driver model is initialized.
- Should we provide an 'early timer' before DM is ready, a bit like
we do with the UART?
I cannot think of a use case that uses timer in that early time.
I can thing of two.
Bootstage requires a timer and the earliest we can mark the start time, the better.
In spl we may want to start DM after we have Sdram running, but Sdram may need time delays to work.
Regards, Simon
participants (2)
-
Bin Meng
-
Simon Glass