Hi Simon, On Sat, Nov 14, 2015 at 10:04 AM, Simon Glass <s...@chromium.org> wrote: > Hi Bin, > > On 13 November 2015 at 01:11, Bin Meng <bmeng...@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...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
