Add a kernel timer driver for the MEC1501 32KHz RTOS timer.
This timer is a count down 32-bit counter clocked at a fixed
32768 Hz. It features one-shot, auto-reload, and halt count down
while the Cortex-M is halted by JTAG/SWD. This driver is based
on the new Intel local APIC driver. The driver was tuned for
accuracy at small sleep values. Added a work-around for RTOS
timer restart issue. RTOS timer driver requires board ticks per
second to be 32768 if tickless operation is configured.
Signed-off-by: Scott Worley <scott.worley@microchip.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>
The native_posix timer driver was still using the
legacy timer API.
Replace it with a new version, which is aligned with
the new kernel<->system timer driver API,
and which has TICKLESS_CAPABLE support
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
When the tick rate was less than MIN_DELAY, bumping a "too soon"
expiration by just one tick may not be enough and we could
theoretically miss the counter.
Instead, eliminate the MIN_DELAY computation and write to the spec:
NRF guarantees that the RTC will generate an interrupt for a
comparator value two cycles in the future. And further, we can test
at the set point to see if we "just missed" the interrupt (i.e. zero
cycles delay) and flag a synchronous interrupt. So we only need to
miss a requested interrupt now for the special case of exactly one
cycle in the future, and then we're only late by one cycle. That's
optimal.
Also fixes an off-by-one in the next cycle computation. By API
convention, an ticks argument of one or less means "at the next tick"
and not "right now". So we need to add one to the target cycle to
avoid incorrectly triggering a synchronous interrupt. This was a
non-issue when a tick is longer than a hardware cycle but is needed
now.
Also handles the edge case with zero latency interrupts (which are
unmaskable) which might mess up timing. This was always a problem,
but we're more sensitive now and it's comparatively more likely to
occur.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The MVIC is no longer supported, and only the APIC-based interrupt
subsystem remains. Thus this layer of indirection is unnecessary.
This also corrects an oversight left over from the Jailhouse x2APIC
implementation affecting EOI delivery for direct ISRs only.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
This is an oddball API. It's untested. In fact testing its proper
behavior requires very elaborate automation (you need a device outside
the Zephyr hardware to measure real world time, and a mechanism for
getting the device into and out of idle without using the timer
driver). And this makes for needless difficulty managing code
coverage metrics.
It was always just a hint anyway. Mark the old API deprecated and
replace it with a kconfig tunable. The effect of that is just to
change the timeout value passed to the timer driver, where we can
manage code coverage metrics more easily (only one driver cares to
actually support this feature anyway).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
move misc/util.h to sys/util.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move clock_control.h to drivers/clock_control.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move power.h to power/power.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Fix path for system_timer.h and loapic.h, we moved it to
include/drivers/timer/ and include/drivers/interrupt_controller/
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The existing local APIC timer driver (loapic_timer.c) has bitrotted
and doesn't support TICKLESS_KERNEL, which is the preferred mode of
operation. This patch introduces a completely new driver, called
the APIC timer driver - the name is changed to allow the drivers to
continue to coexist in the short term, and also because "APIC timer"
isn't ambiguous (the I/O APICs do not have timers).
This driver makes no attempt to work with the MVIC timer as the
previous version did, because MVIC support is deprecated.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
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>
The Quark D2000 is the only x86 with an MVIC, and since support for
it has been dropped, the interrupt controller is orphaned. Removed.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
The defines related to IRQ priority don't exist and aren't used. So
just pass 0 to IRQ_CONNECT for the priority field.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The defines should have had a _0 on them, now that we generate the
proper defines, fixup the cases that used that old scheme.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Found a few annoying typos and figured I better run script and
fix anything it can find, here are the results...
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Change code from using now deprecated DT_<COMPAT>_<INSTANCE>_<PROP>
defines to using DT_INST_<INSTANCE>_<COMPAT>_<PROP>.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
More clearly differentiate MVIC vs. APIC timer code, and use new APIC
accessors in include/drivers/loapic.h. Remove extraneous comments, and
other light cleanup work.
This driver is in need of a serious overhaul -- despite appearing to
have support for TICKLESS_KERNEL and DEVICE_POWER_MANAGEMENT, bitrot
has taken its toll and the driver will not build with these enabled.
These should be removed or made to work... but not in this patch.
Old x2APIC-related accessors in kernel_arch_func.h are eliminated.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Simple renaming and Kconfig reorganization. Choice of local APIC
access method isn't specific to the Jailhouse hypervisor.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
The litex_timer driver used hard coded tick rate (set to 100 ticks
per second). This commit replaces the fixed value with a call to
system function which takes under account system configuration.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
Add LiteX timer driver with bindings for this device.
Signed-off-by: Filip Kokosinski <fkokosinski@internships.antmicro.com>
Signed-off-by: Mateusz Holenko <mholenko@antmicro.com>
We shall not enable by default a system timer in ARM
platforms, namely the SysTick, the Nordic, or the SAM0
RTC timer, simply by assessing the hardware capabilities
(e.g. by conditioning on CPU_CORTEX_M_HAS_SYSTICK).
Instead, now, all ARM platforms needs to explicitly set
their system timer module. Note that this has already
been the case for ca 80% of the ARM platforms.
This clean-up allows us to decouple HW capabilities from
system configuration (for example, Nordic platforms may
enable option CPU_CORTEX_M_HAS_SYSTICK, and still use
the platform-specific RTC timer for system timing).
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit renames the symbol CPU_HAS_SYSTICK to
CPU_CORTEX_M_HAS_SYSTICK, to look similar to all
other CPU_CORTEX_M_HAS_ options, and moves the
K-config symbol definition from arm/core/Kconfig to
arm/core/cortex_m/Kconfig.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Enabling the RTC event is intended to support peripheral-to-peripheral
interconnects, so introduces a request for HFCLK and PCLK16M when the
event is triggered. This specific event is never used with PPI so
enabling events apparently does nothing but increase power consumption.
Closes#15513
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Clearing the pending IRQs when resetting the timeout fixes the
forward time drifting, but the change needs more investigation
until we are sure this won't break kernel time management.
Reverting the change to get 1.14 release out.
This reverts commit 2895da02a4.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
In the unlucky scenario of a SysTick event (wrap) occurring
while we re-program the last_load value, the SysTick ISR
will run immediately after we unlock interrupts. In that
case the timeout we have just configured will expire
instantaneously, leading to operations being executed
much earlier than expected. Avoid this by clearing possibly
pending SysTick exceptions (writing 1 to ICSR.PENDSTCLR).
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
When the counter reaches zero, it reloads the value in
SYST_RVR on the next clock edge. This means that if the
LOAD value is N, the interrupt ("tick") is triggered
every N+1 cycles. Therefore, when we operate in tickless
mode, and we want to schedule the next timeout, we need
to configure the LOAD value with last_load - 1, in order
to get an event in last_load cycles.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
When the counter reaches zero, it reloads the value in
SYST_RVR on the next clock edge. This means that if the
LOAD value is N, the interrupt ("tick") is triggered
every N+1 cycles. Therefore, when we operate in non-
tickless mode, we need to configure the LOAD value
with CYC_PER_TICK - 1, in order to get an event
every CYC_PER_TICK cycles.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
The SysTick logic looked logically sound, but it was allowing us to
set a LOAD value as low as 512 cycles. On other platforms, that
minimum future interrupt delay is there to protect the "read, compute,
write, unmask" cycle that sets the new interrupt from trying to set
one sooner than it can handle.
But with SysTick, that value then becomes the value of the LOAD
register, which is effectively the frequency with which timer
interrupts arrive. This has two side effects:
1. It opens up the possibility that future code that masks interrupts
longer than 512 cycles will miss more than one overflow, slipping
the clock backward as viewed by z_clock_announce().
2. The original code only understood one overflow cycle, so in the
event we do set one of these very near timeouts and then mask
interrupts, we'll only add at most one overflow to the "elapsed()"
time, slipping the CURRENT time backward (actually turning it into
a non-monotonic sawtooth which would slip every LOAD cycle) and
thus messing up future scheduled interrupts, slipping those forward
relative to what the ISR was counting.
This patch simplifies the logic for reading SysTick VAL/CTRL (the loop
wasn't needed), handles the case where we see more than one overflow,
and increases the MIN_DELAY cycles from 512 to 1/16th of a tick.
Fixes#15216
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Update the files which contain no license information with the
'Apache-2.0' SPDX license identifier. Many source files in the tree are
missing licensing information, which makes it harder for compliance
tools to determine the correct license.
By default all files without license information are under the default
license of Zephyr, which is Apache version 2.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Rename reserved function names in drivers/ subdirectory. Update
function macros concatenatenating function names with '##'. As
there is a conflict between the existing gpio_sch_manage_callback()
and _gpio_sch_manage_callback() names, leave the latter unmodified.
Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
Per #13610, recent changes to this driver seem to have introduced
unexpected latency regressions. This patch effectively reverts these
patches which changed the meat of the driver:
ac36886e62 drivers: nrf: timer: add inline qualifier where
inlining is intended
084363a0dc drivers: timer: nrf: refactor for speed and correctness
71882ff8c4 drivers: timer: nrf: drop unnecessary counter mask
4b24e88fa4 drivers: timer: nrf: use irq_lock instead of spinlock
While backporting these seemingly unrelated hygiene patches:
7cbdb6c5c0 drivers/timer: Restore non-tickless tick count behavior
d30c9aeafd drivers: nrf_power_clock: Migrate to DTS.
75f77db432 include: misc: util.h: Rename min/max to MIN/MAX
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The existing device_set_power_state() API works only in synchronous
mode and this is not desirable for devices(ex: Gyro) which take
longer time (few 100 mSec) to suspend/resume.
To support async mode, a new callback argument is added to the API.
The device drivers can asynchronously suspend/resume and call the
callback function upon completion of the async request.
This commit adds the missing callback parameter to all the drivers
to make it compliant with the new API.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
This is intended to initialize CPU-local timer devices, but HPET is
global so we have nothing to do.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Redefining the config will not let another (out-of-source) driver be
chosen instead of the default. The driver is practically forced by the
soc settings. This commit moves default settings from soc/arm/nordic_nrf
into the drivers themselves.
Signed-off-by: Thomas Stenersen <thomas.stenersen@nordicsemi.no>
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>
Converts the rv32m1 timer driver to use 'DT_' prefixed defines instead
of deprecated non-prefixed defines.
Signed-off-by: Maureen Helm <maureen.helm@nxp.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>
nrf_rtc_timer was selecting counter RTC1 instance even though it
is not using counter API at all.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
The system timer uses RTC1, but does not implement the counter API with
it. Instead of auto-enabling the counter API on the system timer make
the two conflict until/unless both APIs are supported by the peripheral.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
The selection of the Cortex M systick driver to be used
as a system clock driver is controlled by
CONFIG_CORTEX_M_SYSTICK.
To replace it by another driver CONFIG_CORTEX_M_SYSTICK
must be set to 'n'. Unfortunately this also controls
the interrupt vector for the systick interrupt. It is
now routed to __reserved. More bad the interrupt vector
can not be set by IRQ_CONNECT as it is one of the hard
coded interrupts in the interrupt table.
Route the hard coded systick interrupt to z_clock_isr
and make z_clock_isr a weak symbol that can be overwritten
by an alternative systick system clock driver.
Signed-off-by: Bobby Noelte <b0661n0e17e@gmail.com>
This board is unmaintained and unsupported. It is not known to work and
has lots of conditional code across the tree that makes code
unmaintainable.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
* MIN_DELAY: 1024 -> 512
* optimzie some code sequence
* fix a bug in setting the new timer limit value
* case: before set limit register with new value,
if counter rolls back to 0, the limit value should be
adjusted.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
The smp_timer_init() was removed during timer re-write.
This results in undefined references error during compilation
when CONFIG_SMP=y. So add it back so we can compile for SMP.
The logic is updated from the previous version to the latest
in the driver.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Add sam0_rtc_driver that implements system timer API on top of the RTC
and can be used as a replacement for the default systick timer.
Signed-off-by: Martin Benda <martin.benda@omsquare.com>
Add a level 2 interrupt controller for the RV32M1 SoC. This uses the
INTMUX peripheral.
As a first customer, convert the timer driver over to using this,
adding nodes for the LPTMR peripherals. This lets users select the
timer instance they want to use, and what intmux channel they want to
route its interrupt to, using DT overlays.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Signed-off-by: Mike Scott <mike@foundries.io>
The OpenISA RV32M1 SoC has four CPU cores. Two of these are RISC-V
32-bit cores, which are named "RI5CY" and "ZERO-RISCY". (The other two
cores are ARM Cortex-M0+ and -M4.) This patch adds basic SoC
enablement for the RISC-V cores:
- basic dtsi, to be extended as additional drivers are added
- SoC definition in soc/riscv32/openisa_rv32m1 for RI5CY / ZERO-RISCY
- system timer driver for RI5CY, based on LPTMR0 peripheral
The timer driver will be generalized a bit soon once proper
multi-level interrupt support is available.
Emphasis is on supporting the RI5CY core as the more capable of the
two; the ZERO-RISCY SoC definitions are a good starting point, but
additional work setting up a dtsi and initial drivers is needed to
support that core.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Signed-off-by: Michael Scott <mike@foundries.io>
Not necessary with gcc, and Zephyr is inconsistent about using the
qualifier, but making the intent explicit is a good thing.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
The existing implementation of z_clock_set_timeout() calculates the
compare value based on a complex series of operations including an
unconditional integer division and multiplication intended to ensure the
compare value is aligned to a tick boundary. On the nRF51 this division
requires a call to an outline function with a data-dependent execution
time.
In the common case where the timeout is set less than one tick past the
last observed tick the devision can be elided, as can several extra
operations intended to deal with fractional ticks.
The code also failed to account for a ticks-per-cycle that violated the
minimum delay required to guarantee a compare value would result in a
match without wrapping. The minimum delay was also unreasonably long
(about 1 ms). Reduce it to a more reasonable value to allow for a
higher ticks-per-second, and diagnose attempts to set the tick frequency
above the supported maximum (8192 Hz).
Finally, move the parts of the compare calculation that are not
dependent on the live counter value out of the locked region.
Prior to this change the observed time between the irq_lock() and
irq_unlock() in z_clock_set_timeout() on the nRF51 ranged between 5 us
and 8 us.
With the revised algorithm the observed lock duration is between 2.16 us
(1024 Hz) and 2.88 us (100 Hz) in the common case that the compare is
set within the current tick. If the compare is set late the duration
will be higher, but no greater than the previous implementation.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
The RTC COUNTER register doesn't care that it receives a value larger
than it can hold; it'll discard the bits internally. No need to spend
cycles doing it manually.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
spinlock gains us nothing on an architecture that doesn't support SMP.
Use the standard irq_lock() API so when we search for conditions that
may decrease ISR responsiveness we can find them.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Cleanup dependencies in Kconfig and convert some top-level options to
menuconfig. guard all dependent options with if instead of using
'depends on' for readibility.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Minor adjustments are done to the nRF clock_control and rtc_timer
drivers to make them usable on nRF9160 as well.
The arm_irq_vector_table test code is modified only because it uses
the function that has been renamed in the nrf_rtc_timer driver.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This commit renames the nrf5_clock_control.h and
nrf5_clock_control.c files to nrf_clock_control.h and
nrf_clock_control.c, respectively, as they are used
in nRF9160 builds, as well.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit renames the CLOCK_CONTROL_NRF5 Kconfig symbol to
CLOCK_CONTROL_NRF. The change is required to aleviates confusion
when selecting the symbol in nRF9160 SOC definition.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
When tickless was disabled, this inverted test would never fire the
first interrupt and the timer would be silent. Just remove it.
There's no harm in unconditionally enabling a single timer interrupt
at boot.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This patch adds a x86_64 architecture and qemu_x86_64 board to Zephyr.
Only the basic architecture support needed to run 64 bit code is
added; no drivers are added, though a low-level console exists and is
wired to printk().
The support is built on top of a "X86 underkernel" layer, which can be
built in isolation as a unit test on a Linux host.
Limitations:
+ Right now the SDK lacks an x86_64 toolchain. The build will fall
back to a host toolchain if it finds no cross compiler defined,
which is tested to work on gcc 8.2.1 right now.
+ No x87/SSE/AVX usage is allowed. This is a stronger limitation than
other architectures where the instructions work from one thread even
if the context switch code doesn't support it. We are passing
-no-sse to prevent gcc from automatically generating SSE
instructions for non-floating-point purposes, which has the side
effect of changing the ABI. Future work to handle the FPU registers
will need to be combined with an "application" ABI distinct from the
kernel one (or just to require USERSPACE).
+ Paging is enabled (it has to be in long mode), but is a 1:1 mapping
of all memory. No MMU/USERSPACE support yet.
+ We are building with -mno-red-zone for stack size reasons, but this
is a valuable optimization. Enabling it requires automatic stack
switching, which requires a TSS, which means it has to happen after
MMU support.
+ The OS runs in 64 bit mode, but for compatibility reasons is
compiled to the 32 bit "X32" ABI. So while the full 64 bit
registers and instruction set are available, C pointers are 32 bits
long and Zephyr is constrained to run in the bottom 4G of memory.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The HPET default is to deliver events on the same INTIn as the legacy
PIT IRQ, and in fact our code requires that because it uses the
"legacy routing" option. So this isn't really a configurable and has
to be set correctly. Do it right in the kconfig default instead of
forcing boards to set it.
(No, I have no idea where "20" came from either.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This patch fixes a bug in System timer driver where
the sys_clock_disable() function was enabling the
timer instead of disabling it.
Change-Id: I4a667d30d43d1f84094d074241ee18d7bb2b2565
Signed-off-by: David Vincze <david.vincze@arm.com>
Two subtractions failed to account for the possibility that a calculated
time exceeded the counter resolution, allowing a comparison to
improperly indicate that a minimum delay was satisfied.
Use the subtraction helper to avoid the problem.
(The subtraction in z_clock_set_timeout was the cause of issue #11694;
the one in rtc1_nrf5_isr was replaced based on inspection rather than
testing.)
Closes#11694
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
If we just had the kernel's implementation, we could
just move this to lib/, but possible arch-specific
implementations dictate that we just make this a
syscall.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We still have one platform using (for now) the pre-asm2 integration
where the timer interrupt was handled via custom assembly. It calls a
function named "_timer_int_handler" always, not the one we register
with IRQ_CONNECT.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Rewritten Xtensa CCOUNT driver along the lines of all the other new
drivers. The new API permits much smaller code.
Notably: The Xtensa counter is a 32 bit up-counter with a comparator
register. It's in some sense the archetype of this kind of timer as
it's the simplest of the bunch (everything else has quirks: NRF is
very slow and 24 bit, HPET has a runtime frequency detection, RISC-V
is 64 bit...). I should have written this one first.
Note also that this includes a blacklist of the xtensa architecture on
the tests/driver/ipm test. I'm getting spurious failures there where
a k_sem_take() call with a non-zero timeout is being made out of the
console output code in interrupt context. This seems to have nothing
to do with the timer; I suspect it's because the old timer drivers
would (incorrectly!) call z_clock_announce() in non-interrupt context
in some contexts (e.g. "expiring really soon"). Apparently this test
(or something in the IPM or Xtensa console code) was somehow relying
on that on Xtensa. But IPM is a Quark thing and there's no particular
reason to run this test there.
Signed-off-by: Andy Ross <andrew.j.ross@intel.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>
Reworked using the older hardware interface code, but with an
implementation of the new API only. Much smaller & simpler.
As yet, tested (manually) only on a nrf52_pca10056 board.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Rewritten along the lines of ARM SysTick. Implements only the new,
simplified API. MUCH smaller. Works with tickless pervasively. No
loss of functionality.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Many drivers won't need to implement z_clock_idle_exit() or
sys_clock_disable(). Make those weak stubs too.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add a TICKLESS_CAPABLE kconfig variable which is used by the kernel to
select tickless mode's default automatically on drivers that support
it (rather than having to set the default per-board). Select it from
the ARM SysTick and Intel HPET drivers.
Also remove the old qemu_cortex_m3 default settings which this
replaces.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Qemu doesn't like tickless. By default[1] it tries to be realtime as
vied by the host CPU -- presenting read values from hardware cycle
counters and interrupt timings at the appropriate real world clock
times according to whatever the simulated counter frequency is. But
when the host system is loaded, there is always the problem that the
qemu process might not see physical CPU time for large chunks of time
(i.e. a host OS scheduling quantum -- generally about the same size as
guest ticks!) leading to lost cycles.
When those timer interrupts are delivered by the emulated hardware at
fixed frequencies without software intervention, that's not so bad:
the work the guest has to do after the interrupt generally happens
synchronously (because the qemu process has just started running) and
nothing notices the dropout.
But with tickless, the interrupts need to be explicitly programmed by
guest software! That means the driver needs to be sure it's going to
get some real CPU time within some small fraction of a Zephyr tick of
the right time, otherwise the computations get wonky.
The end result is that qemu tends to work with tickless well on an
unloaded/idle run, but not in situations (like sanitycheck) where it
needs to content with other processes for host CPU.
So, add a flag that drivers can use to "fake" tickless behavior when
run under qemu (only), and enable it (only!) for the small handful of
tests that are having trouble.
[1] There is an -icount feature to implement proper cycle counting at
the expense of real-world-time correspondence. Maybe someday we might
get it to work for us.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Newer, and much smaller driver written to the new timer API. Supports
all the features the old one did (including shutting off the clock
when clock_always_on is disabled), should be faster in practice, and
should be significantly more accurate due to the "lost cycle" trick
applied in z_clock_set_timeout().
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Since CCOMPARE* registers have undefined values after reset,
set compare value first before enabling timer interrupt.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
I was pretty careful, but these snuck in. Most of them are due to
overbroad string replacements in comments. The pull request is very
large, and I'm too lazy to find exactly where to back-merge all of
these.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Now that the API has been fixed up, replace the existing timeout queue
with a much smaller version. The basic algorithm is unchanged:
timeouts are stored in a sorted dlist with each node nolding a delta
time from the previous node in the list; the announce call just walks
this list pulling off the heads as needed. Advantages:
* Properly spinlocked and SMP-aware. The earlier timer implementation
relied on only CPU 0 doing timeout work, and on an irq_lock() being
taken before entry (something that was violated in a few spots).
Now any CPU can wake up for an event (or all of them) and everything
works correctly.
* The *_thread_timeout() API is now expressible as a clean wrapping
(just one liners) around the lower-level interface based on function
pointer callbacks. As a result the timeout objects no longer need
to store backpointers to the thread and wait_q and have shrunk by
33%.
* MUCH smaller, to the tune of hundreds of lines of code removed.
* Future proof, in that all operations on the queue are now fronted by
just two entry points (_add_timeout() and z_clock_announce()) which
can easily be augmented with fancier data structures.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The current z_clock_uptime() call (recently renamed from
_get_elapsed_program_time) requires the driver to track a full 64 bit
uptime value in ticks, which is entirely separate from the one the
kernel is already keeping.
Don't do that. Just ask the drivers to track uptime since the last
call to z_clock_announce(), since that is going to map better to
built-in hardware capability.
Obviously existing drivers already have this feature, so they're
actually getting slightly larger in order to implement the new API in
terms of the old one. But future drivers will thank us.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Useful for tick-only drivers like Pulpino that don't support this.
Ideally we'd have a header-level interface definition for individual
timer drivers to eliminate the noop function call, but this is clean
for now (even the Pulpino hardware looks like it should support
timeouts just fine, so effort would be better spent there than on a
clean "ticked" interface).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The tickless driver had a bunch of "hairy" APIs which forced the timer
drivers to do needless low-level accounting for the benefit of the
kernel, all of which then proceeded to implement them via cut and
paste. Specifically the "program_time" calls forced the driver to
expose to the kernel exactly when the next interrupt was due and how
much time had elapsed, in a parallel API to the existing "what time is
it" and "announce a tick" interrupts that carry the same information.
Remove these from the kernel, replacing them with synthesized logic
written in terms of the simpler APIs.
In some cases there will be a performance impact due to the use of the
64 bit uptime call, but that will go away soon.
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>
There were three separate "announce ticks" entry points exposed for
use by drivers. Unify them to just a single z_clock_announce()
function, making the "final" tick announcement the business of the
driver only, not the kernel.
Note the oddness with "_sys_idle_elapsed_ticks": this was a global
variable exposed by the kernel. But it was never actually used by the
kernel. It was updated and inspected only within the timer drivers,
and only so that it could be passed back to the kernel as the default
(actually hidden) argument to the announce function. Break this false
dependency by putting this variable into each timer driver
individually.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The system tick count is a 64 bit quantity that gets updated from
interrupt context, meaning that it's dangerously non-atomic and has to
be locked. The core kernel clock code did this right.
But the value was also exposed to the rest of the universe as a global
variable, and virtually nothing else was doing this correctly. Even
in the timer ISRs themselves, the interrupts may be themselves
preempted (most of our architectures support nested interrupts) by
code that wants to set timeouts and inspect system uptime.
Define a z_tick_{get,set}() API, eliminate the old variable, and make
sure everyone uses the right mechanism.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This was another "global variable" API. Give it function syntax too.
Also add a warning, because on nRF devices (at least) the cycle clock
runs in kHz and is too slow to give a precise answer here.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This just got turned into a function from a "variable" API, but
post-the-most-recent-patch it turns out to be degenerate anyway.
Everyone everywhere should always have been using the kconfig variable
directly, and it was only a weirdness in the tickless API that made it
confusing. Fix.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The existing API defined sys_clock_{hw_cycles,ticks}_per_sec as simple
"variables" to be shared, except that they were only real storage in
certain modes (the HPET driver, basically) and everywhere else they
were a build constant.
Properly, these should be an API defined by the timer driver (who
controls those rates) and consumed by the clock subsystem. So give
them function syntax as a stepping stone to get there.
Note that this also removes the deprecated variable
_sys_clock_us_per_tick rather than give it the same treatment.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Simplify the Kconfig dependency for the nrf timer driver.
CLOCK_CONTROL_NRF5 depends on the SOC_FAMILY_NRF already.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Add support for CONFIG_SYSTEM_CLOCK_DISABLE so applications
may be compiled with CONFIG_REBOOT.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
The code assumes that when the systick counter hits zero,
the timer interrupt will be taken before the loop can
read the LOAD/VAL registers, but this is not architecturally
guaranteed, and so the code can see a post-reload SysTick->VAL
and a pre-reload clock_accumulated_count, which causes it to
return an incorrectly small cycle count. By adding a ISB we
overcome this issue.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Move to more generic tracing hooks that can be implemented in different
ways and do not interfere with the kernel.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Define generic interface and hooks for tracing to replace
kernel_event_logger and existing tracing facilities with something more
common.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This patch provides support needed to get timing related
information from riscv32 based SOC.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
This patch provides support needed to get timing related
information from nios2 based SOC.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
This patch provides support needed to get timing related
information from xtensa based SOC.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
The benchmark application timing_info needs certain hooks to be
present in the kernel to get the accurate measurements. This
patch adds these hook at all the required locations.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
irq_lock returns an unsigned int, though, several places was using
signed int. This commit fix this behaviour.
In order to avoid this error happens again, a coccinelle script was
added and can be used to check violations.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Consistently use
config FOO
bool/int/hex/string "Prompt text"
instead of
config FOO
bool/int/hex/string
prompt "Prompt text"
(...and a bunch of other variations that e.g. swapped the order of the
type and the 'prompt', or put other properties between them).
The shorthand is fully equivalent to using 'prompt'. It saves lines and
avoids tricking people into thinking there is some semantic difference.
Most of the grunt work was done by a modified version of
https://unix.stackexchange.com/questions/26284/how-can-i-use-sed-to-replace-a-multi-line-string/26290#26290, but some
of the rarer variations had to be converted manually.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This commit removes redundant reads of RTC_COUNTER register
propagating optimizations made in the k_cycle_get_32() function.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
The previous implementation of _timer_cycle_get_32() (which is directly
mapped to k_cycle_get_32()) taken from 87 to 132 cycles. As result it
was too heavy for using it as source of time for logger.
This commit makes this function faster by removing redundant access
to the RTC register (each access consumed 28 CPU cycles) as well as
loop, which made this call non-deterministic.
After these changes the k_cycle_get_32() needs only 50-52 cycles
in to calculate 32-bit timestamp.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
A few function prototypes were missing in the native_posix
board and its drivers.
Let's add them.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Intel SDM Vol3 10.5.4.1 states that "A write to LVT Timer Register that
changes the timer mode disarms the local APIC timer".
This implies that LVT Timer register needs to be programmed before
Initial Count register, otherwise the LOAPIC timer could not be armed.
Signed-off-by: Zide Chen <zide.chen@intel.com>
On some architectures tick time cannot be expressed as integer
number of microseconds, introducing error in calculations using
sys_clock_us_per_tick variable.
This commit deprecates the sys_clock_us_per_tick variable and
replaces its usage by more precise calculations based on
sys_clock_hw_cycles_per_sec and sys_clock_ticks_per_sec.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
In case of tickless kernel, k_busy_wait() calls __enable_sys_clock()
which in turn calls _set_time() with maximum RTC counter programmable
value. This will set the expected_sys_ticks to maximum tick value even
though there is no explicit timeout is requested from the kernel or from
an application. In this scenario, if an app calls k_sleep() which in
turn calls _add_timeout() which will adjust timeout value as per the
elapsed program time which based on incorrectly set expected_sys_ticks.
To fix this issue, we should not set the expected_sys_ticks in case
of __enable_sys_clock() as it just requests to run the counter but
a timeout event request.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
Bool symbols implicitly default to 'n'.
A 'default n' can make sense e.g. in a Kconfig.defconfig file, if you
want to override a 'default y' on the base definition of the symbol. It
isn't used like that on any of these symbols though, and is
inconsistent.
This will make the auto-generated Kconfig documentation have "No
defaults. Implicitly defaults to n." as well, which is clearer than
'default n if ...'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Uncovered by clang we have some functions being only used conditionally,
so gaurd them to make them only available when those conditions are met.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
To enable for easier testing, replace direct use of registers
from Nordic's nrfx MDK with accesses via its HAL inlined functions
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
The nrf_rtc_timer used own method to calculate number of timer cycles
per tick. As the result value was different than the one used by
the kernel, the reported time was incorrect.
This commit fixes the problem described above by using global
sys_clock_hw_cycles_per_tick instead of custom RTC_TICKS_PER_SYS_TICK.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
Remove redundant declaration of youve_print. This probably
had been a review oversight and upstreamed.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
This commit exposes the RTC1 ISR handling function, so the
function can be directly used in tests which generate
customized vector tables manually and require a visible symbol
for the ISR function.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Remove RTOS-2676 from the comment, this is a jira issue number that was
used with zephyr in the past and not available anywhere for reference.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Upcoming Nordic ICs that share many of the peripherals and architecture
with the currently supported nRF5x ones are no longer part of the nRF5
family. In order to accomodate that, rename the SoC family from nrf5 to
nrf, so that it can contain all of the members of the wider Nordic
family.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
On a stm32, When we use the k_busy_wait function to wait a
delay (500us) just after an idle tickless period the delay could be
lower than the requested one. Consecutive readings of the cycle counter
made with the function k_cycle_get_32 juste after tickeless period
provides erroneous values (value jump) after some time (100 us).
To fix this issue we needs:
- Add the update of clock_accumulated_count value in the
_timer_idle_exit function.
- Treat the case in the get_elapsed_count function when the reload value
of the timer is set to a remaining value to wait until end of tick (see
_timer_idle_exit) . In this case the time elapsed until the systick
timer restart was not yet added to clock_accumulated_count. To retrieve
a correct cycle count we must therefore consider the number of cycle
since current tick period start and not only the cycle number since the
timer restart.
Fixes#6164
Signed-off-by: Holman Greenhand <greenhandholman@gmail.com>
In SMP, the system timer is used for timeslicing on auxiliary CPUs,
but the base system timekeeping via _nano_sys_clock_tick_announce() is
still done on CPU0 only (because the framework isn't prepared for
asynchronous notification yet). Skip processing on CPU1+.
Also, due to a hardware interaction* that is difficult to work around,
timer initialization on the auxiliary CPUs is done at the very end of
the CPU bringup, just before the swap into the scheduler. A
smp_timer_init() API has been added for this purpose.
* On ESP-32, enabling the timer seems to result in a near-synchronous
interrupt being delivered despite my best attempts to keep it
masked, then blowing things up because the CPU record isn't set up
to handle it yet.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The earlier xtensa layer put the timer initialization and update
directly into the interrupt handler, which is... weird. Under asm2,
it's just a regular ISR and needs to do the work in the driver.
Really, this driver needs a bunch of cleanup. The xtensa CPU timer is
two registers and one ISR: a global cycle count register, and a
compare register that will fire the IRQ when they match. There is
*way* too much code here.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The existing hand-written interrupt code is manually calling the timer
ISR, which is sort of silly and about to be replaced. Correctly
declare the ISR with IRQ_CONNECT() so that a conventional interrupt
handling implementation can find it. With current code this is a
noop.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Bugfix in the tickless mode part:
During _time_idle_exit it was not announcing to the kernel the
already passed silent ticks, but it was left for the tick interrupt
itself.
This did not cause any trouble so far as there was only the timer
interrupt in this board.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Added possibility to reconfigure CONFIG_SYS_CLOCK_TICKS_PER_SEC
for the native_posix board (before it could only be 100)
+
Fixed tickless idle support
+
Minor fixes in irq wrapping
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Delete the native timer soft IP driver as we will be reusing
the Altera's HAL drivers for most of the soft IP's.
Add shim driver support for Altera timer system clock soft IP.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
Introducing CMake is an important step in a larger effort to make
Zephyr easy to use for application developers working on different
platforms with different development environment needs.
Simplified, this change retains Kconfig as-is, and replaces all
Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild
offers is replaced by a set of CMake extentions. These extentions have
either provided simple one-to-one translations of KBuild features or
introduced new concepts that replace KBuild concepts.
This is a breaking change for existing test infrastructure and build
scripts that are maintained out-of-tree. But for FW itself, no porting
should be necessary.
For users that just want to continue their work with minimal
disruption the following should suffice:
Install CMake 3.8.2+
Port any out-of-tree Makefiles to CMake.
Learn the absolute minimum about the new command line interface:
$ cd samples/hello_world
$ mkdir build && cd build
$ cmake -DBOARD=nrf52_pca10040 ..
$ cd build
$ make
PR: zephyrproject-rtos#4692
docs: http://docs.zephyrproject.org/getting_started/getting_started.html
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
Besides the fact that we did not have that for the current supported
boards, that makes sense for this new, virtualized mode, that is meant
to be run on top of full-fledged x86 64 CPUs.
By having xAPIC mode access only, Jailhouse has to intercept those MMIO
reads and writes, in order to examine what they do and arbitrate if it's
safe or not (e.g. not all values are accepted to ICR register). This
means that we can't run away from having a VM-exit event for each and
every access to APIC memory region and this impacts the latency the
guest OS observes over bare metal a lot.
When in x2APIC mode, Jailhouse does not require VM-exits for MSR
accesses other that writes to the ICR register, so the latency the guest
observes is reduced to almost zero.
Here are some outputs of the the command line
$ sudo ./tools/jailhouse cell stats tiny-demo
on a Jailhouse's root cell console, for one of the Zephyr demos using
LOAPIC timers, left for a couple of seconds:
Statistics for tiny-demo cell (x2APIC root, x2APIC inmate)
COUNTER SUM PER SEC
vmexits_total 7 0
vmexits_management 3 0
vmexits_cr 2 0
vmexits_cpuid 1 0
vmexits_msr 1 0
vmexits_exception 0 0
vmexits_hypercall 0 0
vmexits_mmio 0 0
vmexits_pio 0 0
vmexits_xapic 0 0
vmexits_xsetbv 0 0
Statistics for tiny-demo cell (xAPIC root, xAPIC inmate)
COUNTER SUM PER SEC
vmexits_total 4087 40
vmexits_xapic 4080 40
vmexits_management 3 0
vmexits_cr 2 0
vmexits_cpuid 1 0
vmexits_msr 1 0
vmexits_exception 0 0
vmexits_hypercall 0 0
vmexits_mmio 0 0
vmexits_pio 0 0
vmexits_xsetbv 0 0
Statistics for tiny-demo cell (xAPIC root, x2APIC inmate)
COUNTER SUM PER SEC
vmexits_total 4087 40
vmexits_msr 4080 40
vmexits_management 3 0
vmexits_cr 2 0
vmexits_cpuid 1 0
vmexits_exception 0 0
vmexits_hypercall 0 0
vmexits_mmio 0 0
vmexits_pio 0 0
vmexits_xapic 0 0
vmexits_xsetbv 0 0
See that under x2APIC mode on both Jailhouse/root-cell and guest, the
interruptions from the hypervisor are minimal. That is not the case when
Jailhouse is on xAPIC mode, though. Note also that, as a plus, x2APIC
accesses on the guest will map to xAPIC MMIO on the hypervisor just
fine.
Signed-off-by: Gustavo Lima Chaves <gustavo.lima.chaves@intel.com>
nrf SOC uses nrf rtc timer (not sys tick), which is 32kHz,
whereas CPU runs at higher speed (nrf52 runs at 64MHz).
So 32Khz is too slow to measure critical kernel parameters.
This patch does :-
1. Add support for nrf SOC for timing_info benchmarking.
2. Uses SOC timer to measure kernel parameters.
Jira: ZEP-2314
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
The API/Variable names in timing_info looks very speicific to
platform (like systick etc), whereas these variabled are used
across platforms (nrf/arm/quark).
So this patch :-
1. changing API/Variable names to generic one.
2. Creating some of Macros whose implimentation is platform
depenent.
Jira: ZEP-2314
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
Add support for TICKLESS KERNEL in nrf_rtc_timer for Nordic family of
processors. This patch includes :-
1. Programming RTC based on "next timer" value from timeout queue while
A. exiting idle_exit.
B. on RTC interrupt.
2. Impliments some of functions which will be required by sys_clock and
scheduler.
ZEP-1819
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
In Tickeless kernel Platform timekeeping is having error because
"_sys_clock_tick_count" is not getting updated correctly.
Currently "OVERFLOW" Flag (bit 16 in timer control register)
is reset before it is taken into account into _sys_clock_tick_count.
This patch sets a flag as soon as Timer Overflow occues and clears
it when time is accounted into _sys_clock_tick_count.
Jira : ZEP-2217
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
By the time we get to POST_KERNEL, kernel services and kernel objects
should be available for use. This should include timers and the random
number generator, but we don't init the system clock until sometime
during the POST_KERNEL phase. Initialize it earlier.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Fix nRF RTC timer from returning more than actual cycles
in _timer_cycle_get_32, under race condition when ISR
announces to kernel.
Jira: ZEP-2229
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
XT_* macros are defined in xtensa HAL headers as xcc intrinsics. gcc
does not have any of these intrinsics. Replace XT_* macros with inline
assembly or provide gcc-compatible definitions.
Change-Id: If823ea8a7898a11a3a8363b17efdba27dee4c6a4
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Add tickless kernel support. Sets timer always in one
shot mode to the time the kernel scheduler needs the
next timer event. Uses mili seconds as the scheduling
time unit.
Jira: ZEP-1817
Change-Id: Ia2e63711cdd9d7d9c241b9ff08a606aa79575012
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
Add tickless kernel support. Sets timer always in one
shot mode to the time the kernel scheduler needs the
next timer event. Uses mili seconds as the scheduling
time unit.
Jira: ZEP-1818
Change-Id: I21ce037b571c4c6ff588033a15aa49624cba7a57
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
Add tickless kernel support. Sets timer always in one
shot mode to the time the kerneel scheduler needs the
next timer event. Uses mili seconds as the scheduling
time unit.
Jira: ZEP-1816
Change-Id: I85232b572759b9653c6396edc057ff4409525c97
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
Update the timer to use the tickless kernel interface
provided by kernel to operate in event based mode. In
this mode, the timer would not generate periodic ticks
and would only be programmed in one shot mode. It would
announce elapsed time in wall time units instead of
ticks. Timer can also be disabled enabling waiting
forever for a non-timer event.
Jira: ZEP-1812
Change-Id: I13110b9fb53b33a9244cc91a3d991f8452d330b1
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
Adds event based scheduling logic to the kernel. Updates
management of timeouts, timers, idling etc. based on
time tracked at events rather than periodic ticks. Provides
interfaces for timers to announce and get next timer expiry
based on kernel scheduling decisions involving time slicing
of threads, timeouts and idling. Uses wall time units instead
of ticks in all scheduling activities.
The implementation involves changes in the following areas
1. Management of time in wall units like ms/us instead of ticks
The existing implementation already had an option to configure
number of ticks in a second. The new implementation builds on
top of that feature and provides option to set the size of the
scheduling granurality to mili seconds or micro seconds. This
allows most of the current implementation to be reused. Due to
this re-use and co-existence with tick based kernel, the names
of variables may contain the word "tick". However, in the
tickless kernel implementation, it represents the currently
configured time unit, which would be be mili seconds or
micro seconds. The APIs that take time as a parameter are not
impacted and they continue to pass time in mili seconds.
2. Timers would not be programmed in periodic mode
generating ticks. Instead they would be programmed in one
shot mode to generate events at the time the kernel scheduler
needs to gain control for its scheduling activities like
timers, timeouts, time slicing, idling etc.
3. The scheduler provides interfaces that the timer drivers
use to announce elapsed time and get the next time the scheduler
needs a timer event. It is possible that the scheduler may not
need another timer event, in which case the system would wait
for a non-timer event to wake it up if it is idling.
4. New APIs are defined to be implemented by timer drivers. Also
they need to handler timer events differently. These changes
have been done in the HPET timer driver. In future other timers
that support tickles kernel should implement these APIs as well.
These APIs are to re-program the timer, update and announce
elapsed time.
5. Philosopher and timer_api applications have been enabled to
test tickless kernel. Separate configuration files are created
which define the necessary CONFIG flags. Run these apps using
following command
make pristine && make BOARD=qemu_x86 CONF_FILE=prj_tickless.conf qemu
Jira: ZEP-339 ZEP-1946 ZEP-948
Change-Id: I7d950c31bf1ff929a9066fad42c2f0559a2e5983
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
Convert code to use u{8,16,32,64}_t and s{8,16,32,64}_t instead of C99
integer types. This handles the remaining includes and kernel, plus
touching up various points that we skipped because of include
dependancies. We also convert the PRI printf formatters in the arch
code over to normal formatters.
Jira: ZEP-2051
Change-Id: Iecbb12601a3ee4ea936fd7ddea37788a645b08b0
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Convert code to use u{8,16,32,64}_t and s{8,16,32,64}_t instead of C99
integer types.
Jira: ZEP-2051
Change-Id: I08f51e2bfd475f6245771c1bd2df7ffc744c48c4
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
This is a start to move away from the C99 {u}int{8,16,32,64}_t types to
Zephyr defined u{8,16,32,64}_t and s{8,16,32,64}_t. This allows Zephyr
to define the sized types in a consistent manor across all the
architectures we support and not conflict with what various compilers
and libc might do with regards to the C99 types.
We introduce <zephyr/types.h> as part of this and have it include
<stdint.h> for now until we transition all the code away from the C99
types.
We go with u{8,16,32,64}_t and s{8,16,32,64}_t as there are some
existing variables defined u8 & u16 as well as to be consistent with
Zephyr naming conventions.
Jira: ZEP-2051
Change-Id: I451fed0623b029d65866622e478225dfab2c0ca8
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Fix doxygen comment typos used to generate API docs
Change-Id: I6fd5051c99bdcc731740c92001e525349c254d85
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
CONFIG_* usually come from Kconfig, rename variables that are locally
defined to avoid confusion about where they are set.
Change-Id: I83b8459913c5deb68dc1b9f5386b8934363a6d1f
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Rearming the riscv machine timer is done by first updating the
mtimecmp low value register. If the low value is updated with a
relatively small value, a timer interrupt can be generated while
updating the mtimecmp high value.
To avoid such a spurious interrupt to occur, disable the timer
interrupt while rearming the timer.
Change-Id: I50ab3f19554a9a8dfe70943b6da0d20be3de88dc
Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
Clear pending IRQ when starting and restore back the RTC1 state when
disabling sys_clock, to avoid issues when soft rebooting the device or
chainloading another Zephyr image (e.g. mcuboot).
Change-Id: I693d9168196ad2cfb8475ecfa2051eac043b1fbd
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
We need to account for the interrupt happening in the middle
of the calculation.
Issue: ZEP-1546
Change-Id: I193534856d7521cac7ca354d3e5b65e93b984bb1
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Fixes an unlikely issue that could arise if the RTC handler in the nRF RTC
driver was blocked for more than one sys tick interval. This could lead to
_sys_clock_tick_announce() being called with more than one sys tick when the
kernel did not expect it.
Jira: ZEP-1763
Change-ID: I5608fca6f0ac97a17c1ce452c1c5c67696a49a9a
Signed-off-by: Øyvind Hovdsveen <oyvind.hovdsveen@nordicsemi.no>
The LOAPIC driver was doing this in a way susceptible to a very
nasty race condition: the CCR register could reset and be readable
before the associated interrupt could be delivered.
This resulted in a small window of time where CCR was reset, but
accumulated_cycle_count not updated, causing some calls to
k_cycle_get_32() to appear to jump backwards in time.
Just use the x86 TSC for these cycle timestamps. A divisor may be
provided in cases where the CPU clock speed is some multiple of
the bus speed. Modern x86 CPUs do not change their TSC rate even
when adjusting cpu frequency, so this should be a reliable timing
source.
Issue: ZEP-1546
Change-Id: I441bd8e32af866587a91f306e89e3fa0ece512b5
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
It's possible the timer interrupt could occur when performing the
computation, resulting in incorrect values returned.
It's still possible for bad values to be returned if the function is
called with interrupts locked, but that is only fixable with a second
timer source.
Issue: ZEP-1546
Change-Id: I16d5b04c3e32377f7249eb4fb1bf2f7c22bd0836
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This is a reworked version of the previous RTC driver. The main
changed is related to the handling _timer_idle_exit() on non-RTC
wake-ups. The previous version didn't announce the elapsed time
to the kernel in _timer_idle_exit(). Additionally, the driver now
makes sure never to announce more idle ticks than the kernel asked
for, since the kernel does not handle negative deltas in its timeout
queues.
Change-Id: I312a357a7ce8f0c22adf5153731064b92870e47e
Signed-off-by: Wojciech Bober <wojciech.bober@nordicsemi.no>
Signed-off-by: Øyvind Hovdsveen <oyvind.hovdsveen@nordicsemi.no>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Some arches may want to define this as an inline function, or
define in core arch code instead of timer driver code.
Unfortunately, this means we need to remove from the footprint
tests, but this is not typically a large function.
Issue: ZEP-1546
Change-Id: Ic0d7a33507da855995838f4703d872cd613a2ca2
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
On Nios II the same timer peripheral IP block can't function
as a periodic system timer and a high-resolution timestamp source.
A second timer instance with different configuration is required.
Until that is implemented, just return the accumulated cycle count.
Issue: ZEP-1546
Change-Id: If3dcebdc60334bf3aa0ab45ccd82f1b2531b6bc1
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
There are race conditions trying to coordinate the value between
the accumulated_cycle_count (updated at interrupt time) and
trying to compute the delta from the last interrupt using the
mtime registers. An unlucky call could result in the timestamp
appearing to move backwards in time.
the 'mtime' register isn't reset at every interrupt. Since we just
want a cycle counter, report its raw value.
Issue: ZEP-1546
Change-Id: I9f404b33214d6502fea47374fcf0ecbf84ef8136
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This driver was written for v1.5 before the introduction of the function
_sys_clock_final_tick_announce. At that time _sys_idle_elapsed_ticks was reset
to 0 automatically. Now that it is reset by the new function, the driver needed
to be fixed.
Change-Id: I039b4dbacb691aaf992b37e44404abd19a54a833
Signed-off-by: Mazen NEIFER <mazen@nestwave.com>
This is needed by next commit as some assembly files handling interrupts use
some options from this file.
This file is not included in next commit to separate code and build system
aptches.
Change-Id: Iff3a8019362599beb0c0058c3169480fa5183c1c
Signed-off-by: Mazen NEIFER <mazen@nestwave.com>
Enabling the riscv_machine_timer driver by default for riscv32
causes compilation issues on riscv32 boards (like zedboard_pulpino)
not supporting it.
Boards supporting the driver enable it via their respective
config file.
Change-Id: Ieb0d25fa339834fd386ae2725f40b6b7b72dc52b
Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
This flag is no longer necessary and TICKLESS_IDLE will be
enabled by default if SYS_POWER_MANAGEMENT is enabled.
Jira: ZEP-1325
Change-Id: Ic6cd4b8dc0a17c6a413cabf6509b215a4558318d
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
riscv defines the machine-mode timer registers that are implemented
by the all riscv SOCs that follow the riscv privileged architecture
specification.
The timer registers implemented in riscv-qemu follow this specification.
To account for future riscv SOCs, reimplement the riscv_qemu_driver by
the riscv_machine_driver.
Change-Id: I645b03c91b4e07d0f2609908decc27ba9b8240d4
Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
Replace _ScbExcPrioSet with calls to NVIC_SetPriority as it handles both
interrupt and exception priorities. We don't need to shift around the
priority values for NVIC_SetPriority.
Jira: ZEP-1568
Change-Id: Iccd68733c3f7faa82b7ccb17200eef328090b6da
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Convert driver to use the CMSIS NVIC APIs rather than the internal ones
so we can remove them in the future.
Change-Id: I31c2f37bc0aa35668a441f4ef2821b768dd7b817
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Remove use of __scs structures and defines in place of CMSIS defined
ones. Also, use __ISB() instead of inline asm.
Jira: ZEP-1568
Change-Id: I8798206a12680f6c50105c7c28112632ac9dde50
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Replace the existing Apache 2.0 boilerplate header with an SPDX tag
throughout the zephyr code tree. This patch was generated via a
script run over the master branch.
Also updated doc/porting/application.rst that had a dependency on
line numbers in a literal include.
Manually updated subsys/logging/sys_log.c that had a malformed
header in the original file. Also cleanup several cases that already
had a SPDX tag and we either got a duplicate or missed updating.
Jira: ZEP-1457
Change-Id: I6131a1d4ee0e58f5b938300c2d2fc77d2e69572c
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The riscv-qemu timer driver does not implement
TICKLESS_IDLE
Change-Id: I3eeb5abb05b3f16b55ab9343c2045295b3010cfd
Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
The pulpino_timer driver does not implement TICKLESS_IDLE
for the time being.
Change-Id: I0cce8c8a7e203d551a924863462e6c86af4c98ff
Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
Force-align all variables defined via asm .word to ensure 4-byte
alignment.
The straddled_tick_on_idle_enter variable was a bool, which resolved in
an one-byte quantity. Changing it to a 32-bit integer. It would have
occupied 4 bytes anyway with alignment.
Fixes ZEP-1549.
Change-Id: If5e0aa1a75dbc73d896b44616f059d221fe191c6
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
On the nRF5x platforms we need always need the NRF_RTC_TIMER and it
depends on the CLOCK_CONTROL_NRF5. So enable all of these always.
Fixes issues if one tries to build nRF5x platforms w/o CONFIG_BLUETOOTH.
Change-Id: I0f9af785e785f37ec289a935ddf70ee6dec08cd4
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
rename NANOKERNEL_TICKLESS_IDLE_SUPPORTED to
TICKLESS_IDLE_SUPPORTED and remove nanokernel occurances in Kconfig
files.
Make TICKLESS_IDLE depend on hardware that supports it.
Change-Id: I6a2e4fb0f7cf4b45475b48e71823ea089ee98759
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Scott Worley