The LL_APBx_GRPn_ReleaseReset clears reset bit in RCC,
however this bit is reset by default. Code that set
this bit was removed in previous commit
0856e99155
Keepint the autonomous clocks for STM32U5 family.
Signed-off-by: Adam Berlinger <adam.berlinger@st.com>
Add ability to set a wakeup counter in case OS Timer is
disabled in certain low power modes. Also add code to
compensate the tick value.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
When running SOF on Intel ADSP we choose to only serve the timer
interrupt on the primary core.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
This commit enhances the accuracy of hardware cycle calculation before
setting the IT8xxx2 event timer. The next target cycle is calculated by
the last, elapsed, and expected timeout ticks. And then, the difference
in hardware cycles between the target cycle and the current cycle is set
into the event timer. This increased accuracy effectively resolves the
clock drift issue.
Tested with:
west build -p always -b it8xxx2_evb tests/kernel/timer/timer_api
-T kernel.timer.tickless
west build -p always -b it8xxx2_evb tests/kernel/timer/timer_behavior
-T kernel.timer.timer
Fixes#67474#67833
Signed-off-by: Ruibin Chang <Ruibin.Chang@ite.com.tw>
Signed-off-by: Ren Chen <Ren.Chen@ite.com.tw>
Include into compilation the nrfx_gppi_dppi_ppib helper and related
interconnect layers when DPPIC nodes are enabled in DTS. Provide macro
definitions required by those interconnect layers based on information
from devicetree (the nrf_grtc_timer is only modified because a macro
that it uses became more generic).
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This was part of the mega hwmv2 commit. Looks like hpet drivers heavily
relies on soc.h. Reverting this for now while we look for a proper fix
and remove reliance on soc.h for drivers.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
When CONFIG_SYSTEM_SLOPPY_IDLE is not set, then system
can sleep for -1 means waking Up at the max possible
counter value (INT_MAX)
When CONFIG_SYSTEM_SLOPPY_IDLE is set sleeping K_TICKS_FOREVER
means never wakingUp
Signed-off-by: Francois Ramu <francois.ramu@st.com>
... in the related parts, so that the driver can be used on nRF54H20
where the clock control is not present yet.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Move code that prepares `NRFX_CONFIG_GRTC_*` definitions based on
information from devicetree from the nRF54L15 nrfx_config header
to the global one, so that the code can be used by nRF54H20, too.
The checks that validate owned-channels and child-owned-channels
DT properties are moved to the nrf_grtc_timer driver so that
the global nrfx_config is not polluted unnecessarily.
The default values in nrfx_config_nrf54l15_enga_application.h
are restored to those from the corresponding template file.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Add support for a backup standby timer in STM32 LPTIM driver for cases
when the LPTIM is not available (ie standby low power mode).
A counter (typically RTC) is used for such a case.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
Remove initialization of static variable to 0 to prevent resetting the
value when reinitializing the driver after resume from standby.
This has no impact since static variables are initialized to 0 by default.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
Now that STM32_LPTIM_CLOCK choice symbol is defined from device tree,
remove the prompt which was defining it as a user selectable entry.
Remove the warning related to possible symbol misalignment with
device tree setting.
Signed-off-by: Erwan Gouriou <erwan.gouriou@st.com>
In sys_clock_set_timeout(), input "ticks" is used to compute next
timeout point, Ambiq's STimer API used to sets next timeout has input
parameter as ui32Delta, which inside the API is using
"this value to add to the STimer counter and load into the comparator
register" according to its spec, thus the this delta clock is
almost equivalent to input "ticks"'s concept, and is not related to
last_count, it should be computed directly from input "ticks".
This correction fixes the test case failure at
zephyr\tests\kernel\tickless\tickless_concept.
Signed-off-by: Bryan Zhu <bzhu@ambiq.com>
In init function, start timer with period CYC_PER_TICK if tickless is
not enabled, This change is for fixing the issue that disabling
CONFIG_TICKLESS_KERNEL the OS tick is not work issue, this
causes the OS not starting scheduling correctly.
Signed-off-by: Bryan Zhu <bzhu@ambiq.com>
If GDBSTUB is enabled and the kernel runs in tickless mode, the timer
must not convert the delta cycles to a 32-bit data type (cycle_diff_t in
this case). The delta_ticks variable would overflow and the next timeout
would be set before the current timestamp, thus generating an interrupt
right after leaving the handler. As a result, the system would receive
tens of thousands of interrupts per second and would not boot.
Cc: Michal Sojka <michal.sojka@cvut.cz>
Signed-off-by: Marek Vedral <marek.vedral@gmail.com>
NRFX has introduced HALY software layer which is a superset of HAL
and aggregates some hardware registers manipulations in a single
function calls.
Quote from nrfx changelog:
"HALY is an extension of the HAL layer that aggregates basic hardware
use cases within single functions. Now it is used instead of HAL
in the corresponding drivers."
This commit zephyr's driver to be aligned with the approach used
in nrfx, where drivers has been switched to use HALY instead of HAL.
Signed-off-by: Adam Wojasinski <adam.wojasinski@nordicsemi.no>
With low LPTIM freq when prescaler is set to 16 or 32,
the CONFIG_SYS_CLOCK_TICKS_PER_SEC must be reduced to
LPTIM CLOCK_/prescaler to avoid spurious timer wakeup activity.
Assert error if the CONFIG_SYS_CLOCK_TICKS_PER_SEC
is not compatible with the lptim clock freq.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Rename to LPTIM_PRESCALER, the <st,property> prescaler of
the stm32 LPTimer. This commit gives better readability than
LPTIM_CLOCK_RATIO.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
SysTick usually has higher measurement resolution than the IDLE timer.
When the time in low power mode is very short or 0, it is possible that
SysTick usually has measures more time since the sys_clock_set_timeout
than the idle timer.
Handle that case to keep uptime correct.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
The idle timer has its max value and can overflow. We measure time passed
since the sys_clock_set_timeout call. Take possibility of the overflow
into account.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
When the idle timer is in use, we calculate number of cycles passed
since the sys_clock_set_timeout call.
The cycle counter can overflow easily, when the counter is 32-bit wide.
Handle that case.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Revert "drivers: timer: lptim timer clock on stm32u5 has a prescaler"
This reverts commit c14670abea.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Allow enabling the Cortex-m idle timer only if power management is set.
It doesn't make sense to use an idle timer without PM.
It allows adding the idle timer chosen node to dts without enabling the
idle timer by default. Now, the PM config has to be set as well.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
The timer driver doesn't annouce/set the timeout at the tick boundary
but at the absolute next expiration time.
It will cause the accumatlation of the tick drift and cannot pass the
kernel/timer/timer_behavior test suite.
This commit fixes the tick drift problem by annouce the time at the tick
bouandry.
Fixes#59594
Signed-off-by: Jun Lin <CHLin56@nuvoton.com>
Some chips, that use Cortex-M SysTick as the system timer, disable a
clock in a low power mode, that is the input for the SysTick e.g.
STM32Fx family.
It blocks enabling power management for these chips. The wake-up
function doesn't work and the time measurement is lost.
Add an additional IDLE timer that handles these functionality when the
system is about to enter IDLE. It has to wake up the chip and update the
cycle counter by time not measured by the SysTick. The IDLE timer has to
support counter API (setting alarm and reading current value).
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Let's make the nrf rtc kconfig depend on the SOC_COMPATIBLE
options which are set both by the real and simulated targets
so the configuration matches in both cases.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
`last_load` is the full N cycles and `SysTick->LOAD` should
be loaded with `last_load - 1` for the calculations work
correctly.
Note: This only affects a kernel in ticked operation.
Tickless kernels periodically restart the timer correctly.
Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
The existing implementation did not properly
handle when `SysTick->VAL` is zero.
This caused three subtle edge cases:
* val1=0,COUNTFLAG=0,val2=0
This should result in no cycles elapsed,
however `(last_load - val2) = last_load`.
So an extra `last_load` cycles was returned.
* val1=0,COUNTFLAG=0,val2=(last_load-1)
This should result in 1 cycle elapsed,
however `val1 < val2` so an extra `last_load`
cycles was returned.
* val1=[2,1,0],COUNTFLAG=1,val2=0
This should result in `last_load` cycles elapsed.
However, `last_load * 2` cycles was returned.
To fix the calculation, val1 and val2 are first
wrapped/realigned from [0:last_load-1] to [1:last_load].
Tidy comments to better reflect the SysTick
behaviour and link reference manuals.
Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
The `SOC_NRF53_RTC_PRETICK` option is now allowed to be used with
`NRF_802154_RADIO_DRIVER`.
Signed-off-by: Andrzej Kuroś <andrzej.kuros@nordicsemi.no>
The nrf53 pretick can be used with non-zero
`NRF_RTC_TIMER_USER_CHAN_COUNT` Kconfig option.
The nrf53 pretick requires just one RTC1 CC channel.
The nrf53 pretick handles also RTC1 and RTC0 both CCs and OVERFLOW
events by examination of events scheduled on them. The pretick is set
based on number of ticks to the closest event scheduled that can trigger
an interrupt.
Because the operation in `z_arm_on_enter_cpu_idle` hook would
take too much time with interrupts disabled, the
`z_arm_on_enter_cpu_idle_prepare` hook enabled by Kconfig option
`ARM_ON_ENTER_CPU_IDLE_PREPARE_HOOK` is used. It performs RTC0 and RTC1
examination, and sets pretick without interrupts being blocked.
The LDREX/STREX are leveraged to detect if exception took place
between start of `z_arm_on_enter_cpu_idle_prepare` and
`z_arm_on_enter_cpu_idle`. If exception has not been taken, the pretick
calculation can be trusted because source data could not changed and
too much time could not pass. Otherwise the sleep attempt is disallowed,
the idle will loop again and try later.
Prompt for `SOC_NRF53_RTC_PRETICK` Kconfig option allows to control
this option by an user and turn the feature off if necessary.
Signed-off-by: Andrzej Kuroś <andrzej.kuros@nordicsemi.no>
Add RTC pretick option that triggers HW activity one tick before and
RTC event that leads to the interrupt. Option is active only on nrf53
network core.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
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>
The CMSIS module glue code was part of arch/ directory. Move it to
modules/cmsis, and provide a single entry point for it: cmsis_core.h.
This entry header will include the right CMSIS header (M or A/R).
To make this change possible, CMSIS module Kconfig/CMake are declared as
external, allowing us to add a new Zephyr include directory.
All files including CMSIS have been updated.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This commit addst support for the system timer peripheral which
can be found in Apollo4 SoCs.
Signed-off-by: Maciej Sobkowski <msobkowski@antmicro.com>
Refactor the ESP32 target SOCs together with
all related boards. Most braking changes includes:
- changing the CONFIG_SOC_ESP32* to refer to
the actual soc line (esp32,esp32s2,esp32s3,esp32c3)
- replacing CONFIG_SOC with the CONFIG_SOC_SERIES
- creating CONFIG_SOC_FAMILY_ESP32 to embrace all
the ESP32 across all used architectures
- introducing CONFIG_SOC_PART_NUMBER_* to
provide a SOC model config
- introducing the 'common' folder to hide all
commonly used configs and files.
- updating west.yml to reflect previous changes in hal
Signed-off-by: Marek Matej <marek.matej@espressif.com>
This PR is Calling "clock_control_on" and checking return value
(as is done elsewhere 10 out of 11 times)
CID 322066: Error handling issues (CHECKED_RETURN)
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This change introduces the "_rtc_timer" suffix for the system tick timer
driver "compatible" property and aligns naming conventions with the
actual CC13/26xx SoC series product policy.
This frees up the "_rtc" namespace to introduce additional APIs based on
the same peripheral in the future (not part of this PR):
rtc: rtc@... {
compatible = "ti,cc13xx-cc26xx-rtc";
...
timer {
compatible = "ti,cc13xx-cc26xx-rtc-timer";
...
};
counter {
compatible = "ti,cc13xx-cc26xx-rtc-counter";
...
};
pps {
compatible = "ti,cc13xx-cc26xx-rtc-pps";
...
};
};
Or alternatively an MFD pattern with similar requirements.
Fixing the namespacing now makes sense standalone as it reduces the
chance of custom drivers being broken in the future.
Redundant extension of the mandatory system clock devicetree node is
replaced with a single `status = "okay"` which seems to be the more
sensible default to avoid user error when defining custom boards.
Knowledgeable users can still override this if really needed.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Removes duplicate code and inconsistencies in the naming of the
cc13xx_cc26xx devicetree and RTC driver hierarchy and alignes it with
the actual TI product series naming hierarchy.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
This driver, due to its limited 24-bits counter, is already tracking a
cycle count in software. Allow that count to be a 64-bits value so this
won't wrap in a matter of only a few seconds when the hardware clock
is fast.
This is very cheap to do as expensive math operations (i.e. divisions)
are performed only on counter intervals whose values fit in 32 bits like
before.
Signed-off-by: Nicolas Pitre <npitre@baylibre.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>
Generic header for system clock allows to define a sys_clock_idle_exit
function for the clock implementation.
Implemented the function in the intel_adsp_timer to reinitialize
device driver after the idle exit state.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
The function `z_nrf_rtc_timer_exact_set` is added to allow
setting compare channel without possible creeping of cc val.
Signed-off-by: Andrzej Kuroś <andrzej.kuros@nordicsemi.no>
Using EM2 or deeper sleep states (where HF clocks are off) requires
special care if BLE radio is used, since BLE radio relies on that clock,
and its power/clock requirements need to be taken into account
On SiLabs, radio PM is implemented as part of RAIL blob, which relies
on sl_power_manager HAL service. I've implemented SoC PM
state changes using sl_power_manager instead of emlib, and added
call to RAIL PM initialization in Gecko HCI driver.
Signed-off-by: Roman Dobrodii <rdobrodii@antmicro.com>
Before BURTC is initialized, clock to its APB CSR file is stopped, so
any attempt to read BURTC regs results in BusFault. However,
many parts of Zephyr may call sys_clock getters even before sys_clock
driver itself is initialized. This change adds support for that:
sys_clock_elapsed() and sys_clock_cycle_get_32() simply return 0
if BURTC is not init yet.
Signed-off-by: Roman Dobrodii <rdobrodii@antmicro.com>
The function to enable wakeup from deep sleep modes is not
available on all SoC's. Hence compile this only when the
wakeup_source property is enabled.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
The stm32_lptim_wait_ready() is waiting for the DIEROK flag
with a while loop. It should not be repeated.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This PR will divide the LPTIM clock freq to increase the max timeout.
Only one LPTIM instance is considered for PM timer.
The input freq becomes a fraction of the internal PCLK
source (mainly LSE clock). As the tick per sec does not change,
the minimum lptim counter must always be >0.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
On the stm32U5, when modifying the DIER register of the LPTIM peripheral,
a new write operation to can only be performed when the previous write
operation is completed and before going-on.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
- Add Gecko BURTC sys_clock driver to handle wake up from EM2,3 states
- Remove custom PM policy and dependency on HAL sl_power_manager service
- EM1 supported in all configurations
- EM2,3 supported only if SysTick is replaced by BURTC
Signed-off-by: Roman Dobrodii <rdobrodii@antmicro.com>
Many areas of Zephyr divide and round up without using the DIV_ROUND_UP
macro. Make use of it, so that we make use of a tested system macro and
at the same time we make code more readable.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
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>
GPT timer driver previously used "restart mode", where the timer would
count to a given value, then rollover. In this mode, "Any write access
to the Compare register of Channel 1 will reset the GPT counter". Since
a write to the compare register takes affect after 1 cycle of the
module's bus clock, and the bus clock is not synchonized with the GPT
module's low frequency counter clock, writing to the compare register
will induce a counter reset, and can cause the GPT to lose time
synchronization. This can induce time drift over time.
To fix this, rework the GPT driver to use "free run" mode. Note that
free run mode is not used directly, rather the GPT is configured to
reset on a tick boundary at boot, and then the second compare register
is used to set capture points. This way, the GPT interrupt will always
fire at a tick boundary, and no calculations are needed to handle
the counter rollover.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Unify the drivers/*/Kconfig menuconfig title strings to the format
"<class> [(acronym)] [bus] drivers".
Including both the full name of the driver class and an acronym makes
menuconfig more user friendly as some of the acronyms are less well-known
than others. It also improves Kconfig search, both via menuconfig and via
the generated Kconfig documentation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
- That MIN_DELAY is a magic arbitrary number that is never going to be
right for all cases. Get rid of it in favor of a smarter solution.
- `sys_clock_set_timeout()` should not base its next match value on the
current time. Tracking the `last_tick` and `last_elapsed` values avoids
the need for all the tick rounding computation.
- Clamp the next timeout to HPET_MAX_TICKS/2. This leaves room for the
added elapsed time and any possible IRQ servicing delay.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Add missing guard which prevents use of nrf_rtc_timer on
the same RTC instance (RTC1) as counter driver instance.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
In general, RTC and TIMER driver implements counter API but there
are exception when those peripherals are used in a custom way
(e.g. for system timer or bluetooth). In that case, system must
prevent using counter based on a reserved instance. Previously,
it was managed by Kconfig options but that cannot be maintained
when switching to devicetree configuration of the counter driver.
A new approach removes Kconfig options and instead adds static
asserts in the files which are using direct peripherals. Those
asserts check if given node is not enabled in the device tree.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
System uptime is not getting incremented when TICKLESS_KERNEL is enabled.
This fixes it by changing the clock_annouce and updating
last_count increment accordingly.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Make sure that the interrupt and event routing enable bits have the
reset values in case the Zephyr firmware image is chain-loaded.
When started by MCUboot, these registers values aren't the reset values,
but then Zephyr initializes them in same way. Yet, when the Zephyr
firmware image is chain-loaded by nRF5 bootloader, they may have values
that cause the scheduler to behave in unexpected ways.
Signed-off-by: Giancarlo Stasi <giancarlo.stasi.co@gmail.com>
Couple issues:
- `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. The hardware performs a signed
comparison. 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.
- The timer must be enabled before the count can return a sensible
value during driver init (at least on qemu_cortex_a9).
Discussion in PR #54919 applies here too.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This commit finish to fix the bug describe by 85e2a0679a68f02f7ef.
With the previous correction, the uptime read could be in the past:
if the counter rewinds just after testing ARRM flag, we had lost
some counts.
Signed-off-by: Julien D'Ascenzio <julien.dascenzio@paratronic.fr>
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>
`#defines` do NOT sepecify a type. They will either adopt a native
system type or type of the value that was passed into the expression.
This can lead to warnings such as, "warning: comparison of integer
expressions of different signedness: 'uint32_t' {aka 'unsigned int'}
and 'int' [-Wsign-compare]".
By casting expressions, such as `MAX_TICKS` to `k_ticks_t`, we can
force the appropriate types and resolve these warnings.
Signed-off-by: Zachary J. Fields <zachary_fields@yahoo.com>
This is a follow-up to commits cf871aec64
and 205e684958.
It turns out that the current implementation of the nrf_rtc_timer may
still fail to properly handle a timeout if that timeout is set in very
specific conditions - when a previously set timeout is about to expire.
When that happens, the new timeout is handled 512 seconds later (when
the system timer overflows) than it should be.
A recently added nrf_rtc_timer test case (test_tight_rescheduling)
exposes this problem and this commit fixes it by adding examination
of COMPARE events that appear during setting of the CC register value
for a given timeout.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This function name is misleading as the absolute time values handled
by the driver are 64-bit and this function receives a 32-bit parameter,
which is supposed to be a CC register value, not the target time.
Correct the name of this function and its parameter, and remove a now
unnecessary masking from its body.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
On the stm32U5, when modifying the DIER register of the LPTIM peripheral,
a new write operation to can only be performed when the previous write
operation is completed and before going-on.
This is done with a function call for better readability.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The introduction of cc2c05a90c caused
CONFIG_MCUX_LPTMR_TIMER to always be enabled for boards where the NXP LPTMR
is enabled in the board devicetree.
Using this low-power timer as system timer only makes sense when using
power management. Otherwise, it just results in a lower tick resolution and
non-tickless operation.
Add dependency on CONFIG_PM for CONFIG_MCUX_LPTMR_TIMER.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.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>
This is a follow-up to commit 205e684958.
The recently added nrf_rtc_timer test case (test_next_cycle_timeouts)
revealed a problem in the current implementation of this function.
Adjust it to avoid missing COMPARE events in specific circumstances.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Add dependency on SYS_CLOCK_EXISTS to all timer configurations.
This would avoid a situation where a possible timer configuration would
be wrongfully selected but SYS_CLOCK_EXISTS is disabled.
This simplifies code that wants to check for system clock capabilities
don't have to check if the system clock exists in addition.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
There is no need to disable interrupts while just checking if
a channel needs to be processed in the ISR, as that section
does not contain anything that needs to be protected against
overwriting from some other context. In particular, if a given
timeout is changed or even aborted while its event is being
checked, this will be correctly handled in the code that follows
and that checks the expiration time.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Values to be set to the comparator need to be specified in RTC cycles,
not ticks, so the initial value used in the tickless mode needs to be
MAX_CYCLES, otherwise when CONFIG_SYS_CLOCK_TICKS_PER_SEC is set to
a value less then the RTC frequency, the initially configured timeout
will be unnecessarily shorter.
On the occassion, remove also the call to counter() when setting the
initial timeout value in non-tickless mode. RTC is cleared a few lines
above, so at this point it will most likely be 0, and even if it was
not, compare_set() would properly handle a target time value that had
already passed.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
In non-tickless mode, the timeout handler always announced maximum 1
tick to kernel, but in fact it cannot be guaranteed that the handler
execution is not delayed and that the number of elapsed ticks does not
exceed 1. Use the actual number instead.
Switch also to using a 32-bit value for `dticks` to get a bit simpler
generated code (ticks delta is not supposed to be that huge).
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Align the condition checked in compare_set_no_locks() with what
set_absolute_alarm() actually provides (and slightly correct the
latter function so that it provides what it is supposed to).
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
