For 32 bit processor to read the 64 bits hpet counter, the HPET spec
2.4.7 suggest to read HPET counter high and low then checking the
high bits to decide if it rollovers or not.
But this logic seems to cause problem for 64 bits processor under SMP,
there is a possible one tick earier under tickless mode. It is likely
to be the cache coherence issue, because a mfence instruction before
reading the timer works.
So we change to read the 64 bits counter by sys_read64 on 64bit
processor to prevent this issue.
Fixes#49611
Signed-off-by: Enjia Mai <enjia.mai@intel.com>
As with previous commit, make the timer irq a simple integer variable
exported by the timer driver for the benefit of this one test
(tests/kernel/context).
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
On some platforms, HPET is not wired to trigger IRQ 2.
This would make HPET non-functional if the legacy
interrupt routing bit is set in the global config
register. This adds a DTS flag so the driver won't
set the bit to enable legacy interrupt.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The weak symbol sys_clock_driver_init has been removed, therefore moving
the init responsability to the drivers themselves. As a result, the init
function has now been made static on all drivers and moved to the
bottom, following the convention used in other areas.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This change adds `k_cycle_get_64()` on platforms that
support a 64-bit cycle counter.
The interface functions `arch_k_cycle_get_64()` and
`sys_clock_cycle_get_64()` are also introduced.
Fixes#39934
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
Add config macro to set interrupt as level triggered for ARM CPUs
Merge all timer configures into one place, then no need to overwrite
hpet_timer_conf_get/set() functions in SoC layer
Make hpet_timer_comparator_set() as the only register access function
to implemented in the SoC layer
Signed-off-by: Dong Wang <dong.d.wang@intel.com>
This converts register access from macro to functions.
This allows SoCs to override these functions if needed.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This allows the HPET timer to use kconfig to specify clock
frequency instead of relying on calculation at runtime.
When the frequency is known at build, this allow the toolchain
to optimize some calculations.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This renames MIN_DELAY to HPET_CMP_MIN_DELAY, and also allows it
to be overridden. The default delay is for HPET with relative
high frequency, and may not suitable for all HPET
implementations.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This extracts the hard-coded value into a macro which can be
overridden. This is in preparation for SoCs where the period
is not in femptoseconds.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Replace suffix ull to ULL to increase code readability and prevent
unexpected behaviours, because the lowercase character l shall not be
used in a literal suffix
Found as a coding guideline violation (MISRA R7.3) by static
coding scanning tool.
Signed-off-by: Maksim Masalski <maksim.masalski@intel.com>
This is another API that is being used in all timer drivers and is not
internal to the clock subsystem. Remove the leading z_ and make promote
it to a cross-subsystem API.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The clock/timer APIs are not application facing APIs, however, similar
to arch_ and a few other APIs they are available to implement drivers
and add support for new hardware and are documented and available to be
used outside of the clock/kernel subsystems.
Remove the leading z_ and provide them as clock_* APIs for someone
writing a new timer driver to use.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Qemu when running more than one processor has a known synchronization
bug where counter values read from the HPET (notionally a single
global device) can be seen going "backwards" when read from different
CPUs.
There was a pre-existing workaround in the ISR that knew about this,
but the problem can crop up anywhere the counter value is used. In
particular I caught it aliasing with the "max_ticks" computation in
z_clock_set_timeout(), where it would cause a rollover and the
resulting negative comparator value would result in no end of
hilarity.
Wrap all access to the counter register with a counter() inline that
(when the workaround is enabled) forces the result to be monotonic by
clamping it to a minimum of one more than the previously read value.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Replaces all existing variants of value clamping with the MIN and MAX
macros with the CLAMP macro.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
This code had one purpose only, feed timing information into a test and
was not used by anything else. The custom trace points unfortunatly were
not accurate and this test was delivering informatin that conflicted
with other tests we have due to placement of such trace points in the
architecture and kernel code.
For such measurements we are planning to use the tracing functionality
in a special mode that would be used for metrics without polluting the
architecture and kernel code with additional tracing and timing code.
Furthermore, much of the assembly code used had issues.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Marking as unused (ARG_UNUSED) the parameter device in the
initialization function z_clock_driver_init when it is not used.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
There is nothing wrong with instance numbers and they are
recommended for use whenever possible, but this is an API
design problem because it's not always possible to get nodes
by instance number; in some cases, drivers need to get node
identifiers from node labels, for example.
Change these APIs (which are not yet in any Zephyr release)
to take node IDs instead of instance IDs.
Fixes: #26984
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The front side bus interrupt delivery feature is a somewhat obscure
part of PC history (in some sense a presaging of MSI interrupts) that
we don't use.
But it's part of the spec, works on hardware, has precedence over the
"legacy" interrupt routing feature we do use, and can be legally
enabled by firmware.
Disable at init time.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The HPET timer was hard-coded to support only edge triggering
interrupts. This adds the necessary bits to enable level
triggering for the timer.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This adds the calls to read_timer_{start,end}_of_tick_handler()
to mark the start and end of ISR which will be used to display
the time spent in ISR with benchmarking tests.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Add a k_timeout_t type, and use it everywhere that kernel API
functions were accepting a millisecond timeout argument. Instead of
forcing milliseconds everywhere (which are often not integrally
representable as system ticks), do the conversion to ticks at the
point where the timeout is created. This avoids an extra unit
conversion in some application code, and allows us to express the
timeout in units other than milliseconds to achieve greater precision.
The existing K_MSEC() et. al. macros now return initializers for a
k_timeout_t.
The K_NO_WAIT and K_FOREVER constants have now become k_timeout_t
values, which means they cannot be operated on as integers.
Applications which have their own APIs that need to inspect these
vs. user-provided timeouts can now use a K_TIMEOUT_EQ() predicate to
test for equality.
Timer drivers, which receive an integer tick count in ther
z_clock_set_timeout() functions, now use the integer-valued
K_TICKS_FOREVER constant instead of K_FOREVER.
For the initial release, to preserve source compatibility, a
CONFIG_LEGACY_TIMEOUT_API kconfig is provided. When true, the
k_timeout_t will remain a compatible 32 bit value that will work with
any legacy Zephyr application.
Some subsystems present timeout (or timeout-like) values to their own
users as APIs that would re-use the kernel's own constants and
conventions. These will require some minor design work to adapt to
the new scheme (in most cases just using k_timeout_t directly in their
own API), and they have not been changed in this patch, instead
selecting CONFIG_LEGACY_TIMEOUT_API via kconfig. These subsystems
include: CAN Bus, the Microbit display driver, I2S, LoRa modem
drivers, the UART Async API, Video hardware drivers, the console
subsystem, and the network buffer abstraction.
k_sleep() now takes a k_timeout_t argument, with a k_msleep() variant
provided that works identically to the original API.
Most of the changes here are just type/configuration management and
documentation, but there are logic changes in mempool, where a loop
that used a timeout numerically has been reworked using a new
z_timeout_end_calc() predicate. Also in queue.c, a (when POLL was
enabled) a similar loop was needlessly used to try to retry the
k_poll() call after a spurious failure. But k_poll() does not fail
spuriously, so the loop was removed.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Some early tickless drivers had a common pattern where they would
compute a tick maximum for the request (i.e. the maximum the hardware
counter can handle) but apply it only on the input tick value and not
on the adjusted final value, opening up the overflow condition it was
supposed to have prevented.
Fixes#20939 (Strictly it fixes the specific pattern that was
discovered in that bug. It's not impossible that other drivers with
alternative implementations have a similar issue, though they look OK
to me via a quick audit).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
At least twice (to be fair: twice among thousands of test runs), I've
seen this device return "backwards" times in SMP, where the counter
value read from one CPU is behind the saved value already seen on the
other. On hardware this should obviously never happen, HPET is a
single global device.
Add a simple workaround on QEMU targets so the math doesn't blow up.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This driver was still using CONFIG_* values to determine its address,
IRQ, etc. Add a binding for an "intel,hpet" device and migrate this
driver to devicetree.
Fixes: #18657
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>
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>
Update reserved function names starting with one underscore, replacing
them as follows:
'_k_' with 'z_'
'_K_' with 'Z_'
'_handler_' with 'z_handl_'
'_Cstart' with 'z_cstart'
'_Swap' with 'z_swap'
This renaming is done on both global and those static function names
in kernel/include and include/. Other static function names in kernel/
are renamed by removing the leading underscore. Other function names
not starting with any prefix listed above are renamed starting with
a 'z_' or 'Z_' prefix.
Function names starting with two or three leading underscores are not
automatcally renamed since these names will collide with the variants
with two or three leading underscores.
Various generator scripts have also been updated as well as perf,
linker and usb files. These are
drivers/serial/uart_handlers.c
include/linker/kobject-text.ld
kernel/include/syscall_handler.h
scripts/gen_kobject_list.py
scripts/gen_syscall_header.py
Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
The newer series of timer drivers will compare counters vs. the last
tick boundary to compute a number of ticks to announce to the kernel.
In the case of CONFIG_TICKLESS=n, this actually represents a change of
behavior from our old scheme where "ticks" always reflected the number
of interrupts received.
The distinction only matters when an interrupt is delayed more than a
full tick, of course. But that actually makes a difference to some
timekeeping code. Restore the old behavior.
This also has the benefit of further reducing code size when !TICKLESS
and improving performance of the ISR by removing the division
(remember Cortex M0 has no hardware divide!).
Fixes#12409
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There are issues using lowercase min and max macros when compiling a C++
application with a third-party toolchain such as GNU ARM Embedded when
using some STL headers i.e. <chrono>.
This is because there are actual C++ functions called min and max
defined in some of the STL headers and these macros interfere with them.
By changing the macros to UPPERCASE, which is consistent with almost all
other pre-processor macros this naming conflict is avoided.
All files that use these macros have been updated.
Signed-off-by: Carlos Stuart <carlosstuart1970@gmail.com>
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>
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>
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>
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>
