| Message ID | 1402475861-15354-1-git-send-email-Li.Xiubo@freescale.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 06/11/14 01:37, Xiubo Li wrote: > The third parameter(u64 start_tstamp) of timecounter_init() should > be the start time by ns, not a cycle counter. > > Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com> > --- > drivers/clocksource/arm_arch_timer.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c > index 5163ec1..6c3cfd8 100644 > --- a/drivers/clocksource/arm_arch_timer.c > +++ b/drivers/clocksource/arm_arch_timer.c > @@ -426,7 +426,7 @@ struct timecounter *arch_timer_get_timecounter(void) > > static void __init arch_counter_register(unsigned type) > { > - u64 start_count; > + u64 start_count, start_ns; > > /* Register the CP15 based counter if we have one */ > if (type & ARCH_CP15_TIMER) > @@ -438,7 +438,8 @@ static void __init arch_counter_register(unsigned type) > clocksource_register_hz(&clocksource_counter, arch_timer_rate); > cyclecounter.mult = clocksource_counter.mult; > cyclecounter.shift = clocksource_counter.shift; > - timecounter_init(&timecounter, &cyclecounter, start_count); > + start_ns = cyclecounter_cyc2ns(&cyclecounter, start_count); > + timecounter_init(&timecounter, &cyclecounter, start_ns); > > /* 56 bits minimum, so we assume worst case rollover */ > sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate); This doesn't make much sense. We're converting start_count, which could be a very large number, into nanoseconds. It looks like we're assuming the counter always starts at 0 which is not always true if you sit in a bootloader for a long time. Perhaps it would be better to just do timecounter_init(&timecounter, &cyclecounter, 0); or timecounter_init(&timecounter, &cyclecounter, ktime_to_ns(ktime_get_real()));
> > drivers/clocksource/arm_arch_timer.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/clocksource/arm_arch_timer.c > b/drivers/clocksource/arm_arch_timer.c > > index 5163ec1..6c3cfd8 100644 > > --- a/drivers/clocksource/arm_arch_timer.c > > +++ b/drivers/clocksource/arm_arch_timer.c > > @@ -426,7 +426,7 @@ struct timecounter *arch_timer_get_timecounter(void) > > > > static void __init arch_counter_register(unsigned type) > > { > > - u64 start_count; > > + u64 start_count, start_ns; > > > > /* Register the CP15 based counter if we have one */ > > if (type & ARCH_CP15_TIMER) > > @@ -438,7 +438,8 @@ static void __init arch_counter_register(unsigned type) > > clocksource_register_hz(&clocksource_counter, arch_timer_rate); > > cyclecounter.mult = clocksource_counter.mult; > > cyclecounter.shift = clocksource_counter.shift; > > - timecounter_init(&timecounter, &cyclecounter, start_count); > > + start_ns = cyclecounter_cyc2ns(&cyclecounter, start_count); > > + timecounter_init(&timecounter, &cyclecounter, start_ns); > > > > /* 56 bits minimum, so we assume worst case rollover */ > > sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate); > > This doesn't make much sense. We're converting start_count, which could > be a very large number, into nanoseconds. It looks like we're assuming > the counter always starts at 0 which is not always true if you sit in a > bootloader for a long time. Yes, the counter here may usually start counting at bootloader time from zero. > Perhaps it would be better to just do > > timecounter_init(&timecounter, &cyclecounter, 0); > > or > > timecounter_init(&timecounter, &cyclecounter, > ktime_to_ns(ktime_get_real())); > Here the ktime_get_real() will always return 0, before setting the system clock, Like: "rtc-ds3232 1-0068: setting system clock to 2014-06-12 13:01:24 UTC (1402578084)" And if so, why not just set it to 0 ? And by the way, 0 is must here ? Thanks, BRs Xiubo
On 06/12/14 00:45, Li.Xiubo@freescale.com wrote: > > And if so, why not just set it to 0 ? And by the way, 0 is must here ? > > I would just set it to 0 and be done with it. But all of this doesn't seem very urgent. The only user of this timecounter is using it for the read() and mult/shift members. We never call timecounter_read() or timecounter_cyc2time() so the nsec member is irrelevant.
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 5163ec1..6c3cfd8 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -426,7 +426,7 @@ struct timecounter *arch_timer_get_timecounter(void) static void __init arch_counter_register(unsigned type) { - u64 start_count; + u64 start_count, start_ns; /* Register the CP15 based counter if we have one */ if (type & ARCH_CP15_TIMER) @@ -438,7 +438,8 @@ static void __init arch_counter_register(unsigned type) clocksource_register_hz(&clocksource_counter, arch_timer_rate); cyclecounter.mult = clocksource_counter.mult; cyclecounter.shift = clocksource_counter.shift; - timecounter_init(&timecounter, &cyclecounter, start_count); + start_ns = cyclecounter_cyc2ns(&cyclecounter, start_count); + timecounter_init(&timecounter, &cyclecounter, start_ns); /* 56 bits minimum, so we assume worst case rollover */ sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);
The third parameter(u64 start_tstamp) of timecounter_init() should be the start time by ns, not a cycle counter. Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com> --- drivers/clocksource/arm_arch_timer.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)