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>
Pull in a more recent version of libmetal, motivated by the void
pointer fixes in efc33fe.
libmetal's b4b5bea to a4f7630 spans:
a4f7630 linux: device: fix max chars to copy for the dev name
10a0d5b lib: system: freertos: mutex: change to use atomic_int ...
4e670c5 ci: Zephyr env var for toolchain
3bef6f0 cmake: Fix Zephyr library integration
13158c3 compiler: add IAR compiler file
0820a2e microblaze: suppress io 64-bit R/W access if 64 bit atomic ...
e2e5608 io: suppress io 64 bit R/W access if 64 bit atomic not ...
efc33fe io: fix compilation error for void pointers.
32ad1d2 cache: fix compilation issue
c1ade0d travis CI: update Zephyr SDK version to 0.9.3
c49d7cd travis CI: updated arm compiler ubuntu package
d279a6a travis ci: Update FreeRTOS download path
5c70105 irq: update sys_irq_restore_enable and sys_irq_save_disable
05f0cd4 cmake: Only look for doxygen package if docs enabled
b4b5bea zephyr: Introduce WITH_ZEPHYR_LIB option
At current time of writing, libmetal's HEAD is 5bc2106641.
However this failed to build in their Travis CI.
The latest passing commit is a4f7630.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.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>
Bool symbols implicitly default to 'n'.
A 'default n' could make sense e.g. in a Kconfig.defconfig file, if you
wanted to override a 'default y' on the base definition of the symbol,
but it doesn't seem to be used like that on any of these symbols.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Introduce a Kconfig option (CONFIG_LIBMETAL_SRC_PATH) that allows us to
point to an external copy of libmetal.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
With recent changes to libmetal we can now include and build it directly
as a zephyr library rather than doing a recursive make. We remove
ext/hal/libmetal.cmake as part of this change and introduce a Kconfig
option for libmetal.
This is a partial fix for issue #7673.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Pull in a slightly more recent version of libmetal with changes
to the build system to improve integration with Zephyr. This change
will break anything that builds with Zephyr and libmetal (which at this
point is only the open-amp example). Will fix that shortly.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
libmetal itself isn't an ipc library, its a generic HAL abstraction
library so move it into ext/hal where it belongs.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Andy Ross