Turns off time slicing as these tests do not expect time slicing and
previously operated without time slicing, but now fallback to the new
default of a time slice size of 20 added in e337b7b. This explicitly sets
the time slice size to 0.
Signed-off-by: Daniel Mangum <georgedanielmangum@gmail.com>
Improve naming of the scheduler and call it what it is: simple. Using
'dumb' for the default scheduler algorithm in Zephyr is a bad idea.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
CONFIG_ENTROPY_GENERATOR is now enabled by default as soon as
"zephyr,entropy" is set in the device-tree. Since the sub-Kconfig
CONFIG_ENTROPY_NRF5_RNG is also enabled by default on nrf boards,
this means that the driver is pulled in the build and intialized
at boot. This might cause runtime issues during some IRQ/kernel
tests, so it's better to remove "zephyr,entropy" on these tests.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
rand32.h does not make much sense, since the random subsystem
provides more APIs than just getting a random 32 bits value.
Rename it to random.h and get consistently with other
subsystems.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
lib -> libraries to be consistent with everything else.
And fix identifier for a few stray tests that were wrongly
labeled/tagged.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move runtime checks to use arch_num_cpus() and build checks
to use CONFIG_MP_MAX_NUM_CPUS. This is to allow runtime
determination of the number of CPUs in the future.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Change for loops of the form:
for (i = 0; i < CONFIG_MP_NUM_CPUS; i++)
...
to
unsigned int num_cpus = arch_num_cpus();
for (i = 0; i < num_cpus; i++)
...
We do the call outside of the for loop so that it only happens once,
rather than on every iteration.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add a bunch of missing "zephyr/" prefixes to #include statements in
various test and test framework files.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Log messages from workqueue are very chatty and on some systems cause
dropping of messages coming from the tests, so set the level to not get
warnings.
Fixes#45670
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
In order to bring consistency in-tree, migrate all tests 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>
Move to CMake 3.20.0.
At the Toolchain WG it was decided to move to CMake 3.20.0.
The main reason for increasing CMake version is better toolchain
support.
Better toolchain support is added in the following CMake versions:
- armclang, CMake 3.15
- Intel oneAPI, CMake 3.20
- IAR, CMake 3.15 and 3.20
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The code here was written to "get out of the way just long enough for
the trivial context switch and callback to execute". But on a machine
with 50 kHz ticks, that's not reliably enough time and this was
failing spuriously. Which would have been a reasonably forgivable
mistake to make had I not written this code with this very machine in
mind...
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add test for the P4 Work Queue gadget. Includes coverage sections
detailing all elements of the API, and a reasonably extensive stress
suite that will saturate the device for 1k events.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
