This commit updates the riscv_machine_timer driver to resolve MTIME and
MTIMECMP register addresses by their `reg-names` instead of relying on
index order.
This improves clarity and robustness in DTS bindings, and is a prerequisite
for handling cases where not both MTIME and MTIMECMP registers are present
or accessible.
Signed-off-by: Chen Xingyu <hi@xingrz.me>
This commit replaces a bunch of ifdefs and bindings with a single
extensible binding, and makes all standard mtime system timers consistent.
Signed-off-by: Camille BAUD <mail@massdriver.space>
There are two issues being fixed here:
1) The code currently clamps timeout length so not to overflow the
computed cycle difference variable or the sys_clock_announce()
argument's range. But this completely fails to take into account
the case where two successive timeouts with enough time between them
will still overflow the cycle difference and/or the tick count.
2) If a timeout with K_TICKS_FOREVER is provided then the comparator is
set with UINT64_MAX which is bogus. Not only this value doesn't make
much sense in the context of a running cycle counter, but it also
opens the possibility for the same cycle diff and/or ticks overflow
as above.
Fix both of those by clamping the actual number of cycles to wait for
based on the previous report occurrence rather than clamping the timeout
ticks.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Timer "drivers" do not use the device model infrastructure, they are
singletons with a SYS_INIT call. This means they do not have to include
device.h but init.h. Things worked because device.h includes init.h.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Usage of 64-bit address constants from devicetree without
an UINT64_C wrapping macro results in the following warning
and the cut-off of the address value:
"warning: integer constant is so large that it is unsigned"
This change fixes such issue for PLIC, MTIMER and UART in case
they are used with some 64-bit RISC-V platforms
Signed-off-by: Alexander Razinkov <alexander.razinkov@syntacore.com>
The init infrastructure, found in `init.h`, is currently used by:
- `SYS_INIT`: to call functions before `main`
- `DEVICE_*`: to initialize devices
They are all sorted according to an initialization level + a priority.
`SYS_INIT` calls are really orthogonal to devices, however, the required
function signature requires a `const struct device *dev` as a first
argument. The only reason for that is because the same init machinery is
used by devices, so we have something like:
```c
struct init_entry {
int (*init)(const struct device *dev);
/* only set by DEVICE_*, otherwise NULL */
const struct device *dev;
}
```
As a result, we end up with such weird/ugly pattern:
```c
static int my_init(const struct device *dev)
{
/* always NULL! add ARG_UNUSED to avoid compiler warning */
ARG_UNUSED(dev);
...
}
```
This is really a result of poor internals isolation. This patch proposes
a to make init entries more flexible so that they can accept sytem
initialization calls like this:
```c
static int my_init(void)
{
...
}
```
This is achieved using a union:
```c
union init_function {
/* for SYS_INIT, used when init_entry.dev == NULL */
int (*sys)(void);
/* for DEVICE*, used when init_entry.dev != NULL */
int (*dev)(const struct device *dev);
};
struct init_entry {
/* stores init function (either for SYS_INIT or DEVICE*)
union init_function init_fn;
/* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows
* to know which union entry to call.
*/
const struct device *dev;
}
```
This solution **does not increase ROM usage**, and allows to offer clean
public APIs for both SYS_INIT and DEVICE*. Note that however, init
machinery keeps a coupling with devices.
**NOTE**: This is a breaking change! All `SYS_INIT` functions will need
to be converted to the new signature. See the script offered in the
following commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
init: convert SYS_INIT functions to the new signature
Conversion scripted using scripts/utils/migrate_sys_init.py.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
manifest: update projects for SYS_INIT changes
Update modules with updated SYS_INIT calls:
- hal_ti
- lvgl
- sof
- TraceRecorderSource
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: devicetree: devices: adjust test
Adjust test according to the recently introduced SYS_INIT
infrastructure.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: kernel: threads: adjust SYS_INIT call
Adjust to the new signature: int (*init_fn)(void);
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Syntacore RISC-V platforms have dedicated MTIMER_DIVIDER register which
should be configured during the Timer initialization.
The configuration of dedicated MTIMER_DIVIDER register could now
be performed during initialization if its address is provided.
Signed-off-by: Alexander Razinkov <alexander.razinkov@syntacore.com>
If for any reason the timer counter didn't hold a value close enough to
zero on boot then the cycle delta could overflow and the reported ticks
won't be right. Those who really want the hardware uptime where this
makes sense (as opposed to Zephyr's uptime) can still rely on
sys_clock_cycle_get_64().
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Several issues:
- `last_count` should not be updated with current time or this will
cause a time drift and induce jitter due to IRQ servicing latency.
- `sys_clock_set_timeout()` should not base its `mtime` on the current
time either. Tracking the `last_tick` and `last_elapsed` values avoids
the need for all the tick rounding computation.
- The MIN_DELAY thing is pointless. If the delay gets close or even behind
current time then the IRQ will be triggered right away. This is unlikely
to happen very often anyway so the constant overhead is uncalled for.
- Runtime 64-bits divisions on 32-bits hardware are very expensive.
Fix the above, and improve the following:
- Prime the accounting by simply invoking the IRQ handler from the init
code. That will make the "ticks since boot" counter right.
- Remove excessive casts, especially a few wrong ones.
- Simplify the code overall.
Here's the output from the timer_jitter_drift test.
Before this patch:
|timer clock rate 60000000, kernel tick rate 10000
|period duration statistics for 10000 samples (0 rollovers):
| expected: 1000 us, 60000.000000 cycles
| min: 907.600000 us, 54456 cycles
| max: 1099.750000 us, 65985 cycles
| mean: 1008.594633 us, 60515.678000 cycles
| variance: 2.184205 us, 7863.136316 cycles
| stddev: 1.477906 us, 88.674332 cycles
|timer start cycle 995589, end cycle 606152369,
|total time 10085946.333333 us, expected time 10000000.000000 us,
|expected time drift 0.000000 us, difference 85946.333333 us
After this patch:
|timer clock rate 60000000, kernel tick rate 10000
|period duration statistics for 10000 samples (0 rollovers):
| expected: 1000 us, 60000.000000 cycles
| min: 992.116667 us, 59527 cycles
| max: 1030.366667 us, 61822 cycles
| mean: 1000.001902 us, 60000.114100 cycles
| variance: 0.105334 us, 379.201081 cycles
| stddev: 0.324551 us, 19.473087 cycles
|timer start cycle 987431, end cycle 600988572,
|total time 10000019.016667 us, expected time 10000000.000000 us,
|expected time drift 0.000000 us, difference 19.016667 us
The mean, variance and standard deviation number differences speak for
themselves, even in the absence of competing ISRs and/or IRQ-disabled
periods which would have made the comparison even worse.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Update machine timer drivers to use DT_HAS_<compat>_ENABLED Kconfig symbol
to expose the driver and enable it by default based on NIOSV devicetree.
Signed-off-by: Khor Swee Aun <swee.aun.khor@intel.com>
It is not guaranteed that a multi-core RISC-V hart numbering scheme
will match Zephyr's sequential cpu numbering scheme. Read the hartid and
use that value in calculation to get mtime_cmp reg, instead of the
current_cpu id.
Signed-off-by: Conor Paxton <conor.paxton@microchip.com>
Change automated searching for files using "IRQ_CONNECT()" API not
including <zephyr/irq.h>.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
IRQ7 is placed on the second element of interrupt definition.
Select it by DT_INST_IRQ_BY_IDX() explicitly.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
Obtain machine timer addresses and IRQ from Devicetree. Note that driver
supports multiple compatibles because mtime/mtimecmp registers are
implemented in different ways depending on the vendor. That means
Devicetree representations can be slightly different and so code to
collect the information needs to treat each compatible differently.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
As with previous commit, make the timer irq a simple integer variable
exported by the timer driver for the benefit of this one test
(tests/kernel/context).
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This commit introduces changes in three places in order to fix the
problem with timer-related tests on FE310-based boards:
* tests/kernel/sleep/kernel.common.timing
* tests/kernel/tickless/tickless_concept/kernel.tickless.concept
* tests/kernel/workq/work_queue/kernel.workqueue
The first change is the modification of the SYS_CLOCK_HW_CYCLES_PER_SEC
value back to 32768 Hz to match FE310's datasheet description.
The second change is CLINT frequency reduction in Renode simulation
model to 16 MHz to correspond with the oscillator frequency given by the
FE310's datasheet and the HiFive1 board schematic. This fixes the first
two tests.
The last change is reducing the MIN_DELAY define to 100. This causes the
RISC-V machine timer driver to update the mtimecmp register more often,
which in turn addresses the `work_queue/kernel.workqueue` problem with
work items finishing prematurely, causing the above-mentioned test to
fail.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
GD32V SoC uses divided clock from core-clock for machine timer clock.
Add config of clock divide factor to support GD32V.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
The weak symbol sys_clock_driver_init has been removed, therefore moving
the init responsability to the drivers themselves. As a result, the init
function has now been made static on all drivers and moved to the
bottom, following the convention used in other areas.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This change adds `k_cycle_get_64()` on platforms that
support a 64-bit cycle counter.
The interface functions `arch_k_cycle_get_64()` and
`sys_clock_cycle_get_64()` are also introduced.
Fixes#39934
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
If CYC_PER_TICK does not divide the (now - last_count) quantity exactly with integer math, the subsequent multiplication before incrementing last_count causes a drift. This commit eliminates the redundant division-followed-by-multiplication and fixes https://github.com/zephyrproject-rtos/zephyr/issues/37852
Signed-off-by: Berend Ozceri <berend@recogni.com>
This is another API that is being used in all timer drivers and is not
internal to the clock subsystem. Remove the leading z_ and make promote
it to a cross-subsystem API.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The clock/timer APIs are not application facing APIs, however, similar
to arch_ and a few other APIs they are available to implement drivers
and add support for new hardware and are documented and available to be
used outside of the clock/kernel subsystems.
Remove the leading z_ and provide them as clock_* APIs for someone
writing a new timer driver to use.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
If next_timeout() returns INT_MAX and pass it to
z_clock_set_timeout(), and machine goes to freeze or slow down.
Bad scenario as follows:
- If an argument int32_t ticks is set large value 0xffffffff,
ticks = MAX(MIN(ticks - 1, (int32_t)MAX_TICKS), 0);
replaces it into MAX_TICKS.
- uint32_t cyc will be set near by 0xffffffff
(this is 0xfffd7280 in 100 ticks per second).
- Add adjustment to cyc, adjustment max value is MAX_CYC.
(cyc = 0xffff14fd)
- Over 0x80000000 value of uint32_t is considered as negative
value of int32_t.
if ((int32_t)(cyc + last_count - now) < MIN_DELAY)
This condition is always true.
- Because cyc += CYC_PER_TICK will get overflow, driver sets mtimecmp
near value of current mtime.
(cyc = 0x00007fc0)
- Next timer interrupt will happen soon after return from interrupt
handler.
- By repeating these events, machine cannot go to next instruction,
and it's going to freeze or slow down.
Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
Replaces all existing variants of value clamping with the MIN and MAX
macros with the CLAMP macro.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Marking as unused (ARG_UNUSED) the parameter device in the
initialization function z_clock_driver_init when it is not used.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Add a k_timeout_t type, and use it everywhere that kernel API
functions were accepting a millisecond timeout argument. Instead of
forcing milliseconds everywhere (which are often not integrally
representable as system ticks), do the conversion to ticks at the
point where the timeout is created. This avoids an extra unit
conversion in some application code, and allows us to express the
timeout in units other than milliseconds to achieve greater precision.
The existing K_MSEC() et. al. macros now return initializers for a
k_timeout_t.
The K_NO_WAIT and K_FOREVER constants have now become k_timeout_t
values, which means they cannot be operated on as integers.
Applications which have their own APIs that need to inspect these
vs. user-provided timeouts can now use a K_TIMEOUT_EQ() predicate to
test for equality.
Timer drivers, which receive an integer tick count in ther
z_clock_set_timeout() functions, now use the integer-valued
K_TICKS_FOREVER constant instead of K_FOREVER.
For the initial release, to preserve source compatibility, a
CONFIG_LEGACY_TIMEOUT_API kconfig is provided. When true, the
k_timeout_t will remain a compatible 32 bit value that will work with
any legacy Zephyr application.
Some subsystems present timeout (or timeout-like) values to their own
users as APIs that would re-use the kernel's own constants and
conventions. These will require some minor design work to adapt to
the new scheme (in most cases just using k_timeout_t directly in their
own API), and they have not been changed in this patch, instead
selecting CONFIG_LEGACY_TIMEOUT_API via kconfig. These subsystems
include: CAN Bus, the Microbit display driver, I2S, LoRa modem
drivers, the UART Async API, Video hardware drivers, the console
subsystem, and the network buffer abstraction.
k_sleep() now takes a k_timeout_t argument, with a k_msleep() variant
provided that works identically to the original API.
Most of the changes here are just type/configuration management and
documentation, but there are logic changes in mempool, where a loop
that used a timeout numerically has been reworked using a new
z_timeout_end_calc() predicate. Also in queue.c, a (when POLL was
enabled) a similar loop was needlessly used to try to retry the
k_poll() call after a spurious failure. But k_poll() does not fail
spuriously, so the loop was removed.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When debugging on a long running platform, the MCU may get reset by
the debugger with an ndmreset toggle. Since there is no requirement
that this resets anything in particular on the platform, the CLINT
registers may not get reset. When this occurs with an mtime register
value that is larger than 32 bits the riscv machine timer will
continuously interrupt the system when the mtime register exceeds 32
bits in value. This is because the last_count value is used to update
the mtimecmp register, and its value is initialized to zero. Its
first update is with a 32-bit value, which loses information when the
mtime register exceeds 32 bits.
The proposed solution is to set the last_count value to the current
value in the mtime register when the timer is initialized. Since the
timer is fired at intervals that are less than 32 bits in value, the
next update of last_count will remain valid, and the system will
function as expected.
Signed-off-by: Jaron Kelleher <jkelleher@fb.com>
riscv64 CPUs can access full 64-bit memory-mapped register by a single
instruction, so we can directly access these registers.
Signed-off-by: Jim Shu <cwshu@andestech.com>
Some early tickless drivers had a common pattern where they would
compute a tick maximum for the request (i.e. the maximum the hardware
counter can handle) but apply it only on the input tick value and not
on the adjusted final value, opening up the overflow condition it was
supposed to have prevented.
Fixes#20939 (Strictly it fixes the specific pattern that was
discovered in that bug. It's not impossible that other drivers with
alternative implementations have a similar issue, though they look OK
to me via a quick audit).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
On some SoCs the frequency of the system clock is obtained at run time
as the exact configuration of the hardware is not known at compile time.
On such platforms using CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC define
directly introduces timing errors.
This commit replaces CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC by the call
to inline function sys_clock_hw_cycles_per_sec() which always returns
correct frequency of the system clock.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
Move internal and architecture specific headers from include/drivers to
subfolder for timer:
include/drivers/timer
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Update reserved function names starting with one underscore, replacing
them as follows:
'_k_' with 'z_'
'_K_' with 'Z_'
'_handler_' with 'z_handl_'
'_Cstart' with 'z_cstart'
'_Swap' with 'z_swap'
This renaming is done on both global and those static function names
in kernel/include and include/. Other static function names in kernel/
are renamed by removing the leading underscore. Other function names
not starting with any prefix listed above are renamed starting with
a 'z_' or 'Z_' prefix.
Function names starting with two or three leading underscores are not
automatcally renamed since these names will collide with the variants
with two or three leading underscores.
Various generator scripts have also been updated as well as perf,
linker and usb files. These are
drivers/serial/uart_handlers.c
include/linker/kobject-text.ld
kernel/include/syscall_handler.h
scripts/gen_kobject_list.py
scripts/gen_syscall_header.py
Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
The newer series of timer drivers will compare counters vs. the last
tick boundary to compute a number of ticks to announce to the kernel.
In the case of CONFIG_TICKLESS=n, this actually represents a change of
behavior from our old scheme where "ticks" always reflected the number
of interrupts received.
The distinction only matters when an interrupt is delayed more than a
full tick, of course. But that actually makes a difference to some
timekeeping code. Restore the old behavior.
This also has the benefit of further reducing code size when !TICKLESS
and improving performance of the ISR by removing the division
(remember Cortex M0 has no hardware divide!).
Fixes#12409
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There are issues using lowercase min and max macros when compiling a C++
application with a third-party toolchain such as GNU ARM Embedded when
using some STL headers i.e. <chrono>.
This is because there are actual C++ functions called min and max
defined in some of the STL headers and these macros interfere with them.
By changing the macros to UPPERCASE, which is consistent with almost all
other pre-processor macros this naming conflict is avoided.
All files that use these macros have been updated.
Signed-off-by: Carlos Stuart <carlosstuart1970@gmail.com>
Rewritten driver along the lines of all the other new drivers,
implementing the new timer API. Structurally, the machine timer is an
up-counter with comparator, so it works broadly the same way HPET and
NRF do. The quirk here is that it's a 64 bit counter, which needs a
little more care.
Unlike the other timer reworks, this driver has grown by a few lines
as it used to be very simple. But in exchange, we get full tickless
support on the platform.
Fixes#10609 in the process (the 64 bit timer registers are unlatched
for sub-word transfers, so you have to use careful ordering).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Rename timer driver API functions to be consistent. ADD DOCS TO THE
HEADER so implementations understand what the requirements are.
Remove some unused functions that don't need declarations here.
Also removes the per-platform #if's around the power control callback
in favor of a weak-linked noop function in the driver initialization
(adds a few bytes of code to default platforms -- we'll live, I
think).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The existing API had two almost identical functions: _set_time() and
_timer_idle_enter(). Both simply instruct the timer driver to set the
next timer interrupt expiration appropriately so that the call to
z_clock_announce() will be made at the requested number of ticks. On
most/all hardware, these should be implementable identically.
Unfortunately because they are specified differently, existing drivers
have implemented them in parallel.
Specify a new, unified, z_clock_set_timeout(). Document it clearly
for implementors. And provide a shim layer for legacy drivers that
will continue to use the old functions.
Note that this patch fixes an existing bug found by inspection: the
old call to _set_time() out of z_clock_announce() failed to test for
the "wait forever" case in the situation where clock_always_on is
true, meaning that a system that reached this point and then never set
another timeout would freeze its uptime clock incorrectly.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
