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>
When TICKLESS_KERNEL is enabled, the current time in ticks is based on
a hardware counter and not interrupt delivery (which is the whole
point of tickless), so irq-locking does not prevent time from
advancing. Disable this test in that configuration.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
In the POSIX architecture, with the inf_clock "SOC", time does
not pass while the CPU is running. Tests that require time to pass
while busy waiting should call k_busy_wait() or in some other way
set the CPU to idle. This test was setting the CPU to idle while
waiting for the next time slice. This is ok if the system tick
(timer) is active and awaking the CPU every system tick period.
But when configured in tickless mode that is not the case, and the
CPU was set to sleep for an indefinite amount of time.
This commit fixes it by using k_busy_wait(a few microseconds) inside
that busy wait loop instead.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
This test was written to assume that on idle the CPU would wake up on
the next tick boundary because of the timer interrupt. No such
interrupt arrives in tickless mode and it hangs forever.
A more whiteboxy test involving setting a clock timout will have to be
written for this feature if we want to keep it on tickless systems.
Alternatively we could move this test out of tests/kernel/context and
always disable tickless.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The theory behind this test seems to be that taking an IRQ lock should
prevent the advance of the kernel's tick counter. That works on
traditional timers only. In tickless mode the timer hardware/driver
is expected to be able to give us an answer for time independent of
interrupt delivery, so the test fails spuriously. The "bug" detected
is a feature of tickless!
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>
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>
The test was using ztest incorrectly exposing everything as one single
test function. We now have multiple tests that can be tracked back to
features and requirements.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
