Commit graph

6 commits

Author SHA1 Message Date
Chanho Park
74fbd74ed2 riscv: timer: add timer_get_boot_us for BOOTSTAGE
timer_get_boot_us function is required to record the boot stages as
us-based timestamp.
To get a micro-second time from a timer tick, this converts the
formula like below to avoid zero result of (tick / rate) part.

From: time(us) = (tick / rate) * 1000000
To  : time(us) = (tick * 1000) / (rate / 1000)

Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
2023-10-04 17:55:20 +08:00
Torsten Duwe
f39f8f77a5 riscv: allow riscv timer to be instantiated via device tree
For the architectural timer on riscv, there already is a defined
device tree binding[1]. Allow timer instances to be created from
device tree matches, but for now retain the old mechanism, which
registers the timer biggy-back with the CPU.

[1] linux/Documentation/devicetree/bindings/timer/riscv,timer.yaml

Signed-off-by: Torsten Duwe <duwe@suse.de>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
2023-09-05 10:53:36 +08:00
Pragnesh Patel
bc8d12bfd8 riscv: timer: Add support for an early timer
Added support for timer_early_get_count() and timer_early_get_rate()
This is mostly useful in tracing.

Signed-off-by: Pragnesh Patel <pragnesh.patel@sifive.com>
Reviewed-by: Rick Chen <rick@andestech.com>
2021-01-18 11:06:32 +08:00
Sean Anderson
8af7bb914f timer: Return count from timer_ops.get_count
No timer drivers return an error from get_count. Instead of possibly
returning an error, just return the count directly.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-22 09:54:53 -04:00
Sean Anderson
c33efafaf9 riscv: Rework riscv timer driver to only support S-mode
The riscv-timer driver currently serves as a shim for several riscv timer
drivers. This is not too desirable because it bypasses the usual timer
selection via the driver model. There is no easy way to specify an
alternate timing driver, or have the tick rate depend on the cpu's
configured frequency. The timer drivers also do not have device structs,
and so have to rely on storing parameters in gd_t. Lastly, there is no
initialization call, so driver init is done in the same function which
reads the time. This can result in confusing error messages. To a user, it
looks like the driver failed when trying to read the time, whereas it may
have failed while initializing.

This patch removes the shim functionality from the riscv-timer driver, and
has it instead implement the former rdtime.c timer driver. This is because
existing u-boot users who pass in a device tree (e.g. qemu) do not create a
timer device for S-mode u-boot. The existing behavior of creating the
riscv-timer device in the riscv cpu driver must be kept. The actual reading
of the CSRs has been redone in the style of Linux's get_cycles64.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Rick Chen <rick@andestech.com>
2020-09-30 08:54:45 +08:00
Bin Meng
60262cd041 timer: Add generic driver for RISC-V privileged architecture defined timer
RISC-V privileged architecture v1.10 defines a real-time counter,
exposed as a memory-mapped machine-mode register - mtime. mtime must
run at constant frequency, and the platform must provide a mechanism
for determining the timebase of mtime. The mtime register has a
64-bit precision on all RV32, RV64, and RV128 systems.

Different platform may have different implementation of the mtime
block hence an API riscv_get_time() is required by this driver for
platform codes to hide such implementation details. For example,
on some platforms mtime is provided by the CLINT module, while on
some other platforms a simple 'rdtime' can be used to get the timer
counter.

With this timer driver the U-Boot timer functionalities like delay
works correctly now.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Anup Patel <anup@brainfault.org>
2018-12-18 09:56:26 +08:00