This adds support for the local APIC in one-shot mode as the timeout
event source for those cases where the CPU supports invariant TSC but
no TSC deadline capability. It is presented as another timer choice.
Existing Kconfig symbols were preserved to minimize board config
disturbance.
This hybrid approach was implemented kind of backward in the apic_timer
driver but it is far cleaner to carry this here.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Let's replicate a common code pattern for this to be abstracted more
easily in the future. In addition to duplicating the correctness fixes
implemented in the ARM and RISC-V drivers, this eliminates a couple large
runtime divisions.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
We have already code using toolchain provided __get_cpuid(), clean up
apic_tsc and make it consistent with the rest of the code.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
add support for retrieve clock frequency (HW clock cycle per sec) of
system timer at runtime by reading cpu clock via cpuid
Signed-off-by: Najumon B.A <najumon.ba@intel.com>
Timer "drivers" do not use the device model infrastructure, they are
singletons with a SYS_INIT call. This means they do not have to include
device.h but init.h. Things worked because device.h includes init.h.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
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>
Change automated searching for files using "IRQ_CONNECT()" API not
including <zephyr/irq.h>.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
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>
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>
Modern hardware all supports a TSC_DEADLINE mode for the APIC timer,
where the same GHz-scale 64 bit TSC used for performance monitoring
becomes the free-running counter used for cpu-local timer interrupts.
Being a free running counter that does not need to be reset, it will
not lose time in an interrupt. Being 64 bit, it needs no rollover or
clamping logic in the driver when presented with a 32 bit tick count.
Being a proper comparator, it will correctly trigger interrupts for
times set "in the past" and thus needs no minimum/clamping logic. The
counter is synchronized across the system architecturally (modulo one
burp where firmware likes to change the adjustment value) so usage is
SMP-safe by default. Access to the 64 bit counter and comparator
value are single-instruction atomics even on 32 bit systems, so it
beats even the RISC-V machine timer in complexity (which was our
reigning champ for "simplest timer driver").
Really this is just ideal for Zephyr. So rather than try to add
support for it to the existing APIC driver and increase complexity,
make this a new standalone driver instead. All modern hardware has
what it needs. The sole gotcha is that it's not easily emulatable
(qemu supports it only under kvm where they can freeload on the host
TSC) so it can be exercised only on hardware platforms right now.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
