Hi Simon,
On Sat, Nov 14, 2015 at 10:04 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 13 November 2015 at 01:11, Bin Meng bmeng.cn@gmail.com wrote:
There are timers with a 64-bit counter value but current timer uclass driver assumes a 32-bit one. Modify timer_get_count() to ask timer driver to always return a 64-bit counter value, and provide an inline helper function timer_conv_64() to handle the 32-bit/64-bit conversion automatically.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Changes in v3:
- Update commit message to reflect the v2 changes (ie: there is no "counter-64bit" property)
Changes in v2:
- Do not use "counter-64bit" property, instead create an inline function for 32-bit timer driver to construct a 64-bit timer value.
drivers/timer/altera_timer.c | 4 ++-- drivers/timer/sandbox_timer.c | 2 +- drivers/timer/timer-uclass.c | 8 +++----- include/timer.h | 23 ++++++++++++++++++++--- lib/time.c | 9 ++++++--- 5 files changed, 32 insertions(+), 14 deletions(-)
Is there a binding file for this timer somewhere? If both altera and sandbox share this property, should we add a generic binding? It doesn't look like Linux has one though.
Missed this comment in my previous post.
I cannot find one too. But this is quite natural as without a frequency the timer does not count :) I believe 'clock-frequency' might be dynamically calculated on some platforms like ARM SoCs, which is similar to the ns16550 serial clock source frequency (we've had such discussion before).
[snip]
Regards, Bin