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 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>
- 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>
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>
