* [PATCH] clocksource: arch_arm_timer: Fix timecounter initialization @ 2014-06-11 8:37 ` Xiubo Li 0 siblings, 0 replies; 8+ messages in thread From: Xiubo Li @ 2014-06-11 8:37 UTC (permalink / raw) To: linux-arm-kernel 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); -- 1.8.5 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH] clocksource: arch_arm_timer: Fix timecounter initialization @ 2014-06-11 8:37 ` Xiubo Li 0 siblings, 0 replies; 8+ messages in thread From: Xiubo Li @ 2014-06-11 8:37 UTC (permalink / raw) To: daniel.lezcano, tglx, linux-arm-kernel; +Cc: linux-kernel, Xiubo Li 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); -- 1.8.5 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH] clocksource: arch_arm_timer: Fix timecounter initialization 2014-06-11 8:37 ` Xiubo Li @ 2014-06-11 19:02 ` Stephen Boyd -1 siblings, 0 replies; 8+ messages in thread From: Stephen Boyd @ 2014-06-11 19:02 UTC (permalink / raw) To: linux-arm-kernel 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())); -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] clocksource: arch_arm_timer: Fix timecounter initialization @ 2014-06-11 19:02 ` Stephen Boyd 0 siblings, 0 replies; 8+ messages in thread From: Stephen Boyd @ 2014-06-11 19:02 UTC (permalink / raw) To: Xiubo Li; +Cc: daniel.lezcano, tglx, linux-arm-kernel, linux-kernel, Marc Zyngier 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())); -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] clocksource: arch_arm_timer: Fix timecounter initialization 2014-06-11 19:02 ` Stephen Boyd @ 2014-06-12 7:45 ` Li.Xiubo -1 siblings, 0 replies; 8+ messages in thread From: Li.Xiubo at freescale.com @ 2014-06-12 7:45 UTC (permalink / raw) To: linux-arm-kernel > > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH] clocksource: arch_arm_timer: Fix timecounter initialization @ 2014-06-12 7:45 ` Li.Xiubo 0 siblings, 0 replies; 8+ messages in thread From: Li.Xiubo @ 2014-06-12 7:45 UTC (permalink / raw) To: Stephen Boyd Cc: Marc Zyngier, tglx@linutronix.de, daniel.lezcano@linaro.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org > > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] clocksource: arch_arm_timer: Fix timecounter initialization 2014-06-12 7:45 ` Li.Xiubo @ 2014-06-12 17:58 ` Stephen Boyd -1 siblings, 0 replies; 8+ messages in thread From: Stephen Boyd @ 2014-06-12 17:58 UTC (permalink / raw) To: linux-arm-kernel On 06/12/14 00:45, Li.Xiubo at 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. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] clocksource: arch_arm_timer: Fix timecounter initialization @ 2014-06-12 17:58 ` Stephen Boyd 0 siblings, 0 replies; 8+ messages in thread From: Stephen Boyd @ 2014-06-12 17:58 UTC (permalink / raw) To: Li.Xiubo@freescale.com Cc: Marc Zyngier, tglx@linutronix.de, daniel.lezcano@linaro.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-06-12 17:58 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-06-11 8:37 [PATCH] clocksource: arch_arm_timer: Fix timecounter initialization Xiubo Li 2014-06-11 8:37 ` Xiubo Li 2014-06-11 19:02 ` Stephen Boyd 2014-06-11 19:02 ` Stephen Boyd 2014-06-12 7:45 ` Li.Xiubo at freescale.com 2014-06-12 7:45 ` Li.Xiubo 2014-06-12 17:58 ` Stephen Boyd 2014-06-12 17:58 ` Stephen Boyd
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.