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>
