zephyr/tests/kernel/common/prj.conf

CONFIG_ZTEST=y
CONFIG_PRINTK=y
CONFIG_LOG=y
CONFIG_POLL=y
CONFIG_QEMU_TICKLESS_WORKAROUND=y
tests: move individual common tests into one test We have many tests that are being built as stand-alone binaries for no good reason. Those can be put in one single test to speed up testing and CI verification. Currently we do support the following in test_common: - byteorder - printk - intmath - slist - atomic - ring_buf In addition, the test now uses the ztest framework. Change-Id: I656ac7f4acf48b7de4ec81c9f5dafc9dea3da911 Signed-off-by: Anas Nashif <anas.nashif@intel.com> 2016-10-31 03:06:06 +08:00			`CONFIG_ZTEST=y`
			`CONFIG_PRINTK=y`
kernel: move to new logger Use the new logger framework for kernel. Signed-off-by: Anas Nashif <anas.nashif@intel.com> 2018-09-17 19:58:09 +08:00			`CONFIG_LOG=y`
tests/kernel/common: add test to verify same tick timeout expiry order Timeouts, when expiring on the same tick, should be handled in the same order they were queued. Change-Id: I23a8e971a47ca056b32b8b48fe179d481bae27c0 Signed-off-by: Benjamin Walsh <walsh.benj@gmail.com> 2017-02-16 11:26:28 +08:00			`CONFIG_POLL=y`
drivers/timer: Add a standard workaround for known qemu issues Qemu doesn't like tickless. By default[1] it tries to be realtime as vied by the host CPU -- presenting read values from hardware cycle counters and interrupt timings at the appropriate real world clock times according to whatever the simulated counter frequency is. But when the host system is loaded, there is always the problem that the qemu process might not see physical CPU time for large chunks of time (i.e. a host OS scheduling quantum -- generally about the same size as guest ticks!) leading to lost cycles. When those timer interrupts are delivered by the emulated hardware at fixed frequencies without software intervention, that's not so bad: the work the guest has to do after the interrupt generally happens synchronously (because the qemu process has just started running) and nothing notices the dropout. But with tickless, the interrupts need to be explicitly programmed by guest software! That means the driver needs to be sure it's going to get some real CPU time within some small fraction of a Zephyr tick of the right time, otherwise the computations get wonky. The end result is that qemu tends to work with tickless well on an unloaded/idle run, but not in situations (like sanitycheck) where it needs to content with other processes for host CPU. So, add a flag that drivers can use to "fake" tickless behavior when run under qemu (only), and enable it (only!) for the small handful of tests that are having trouble. [1] There is an -icount feature to implement proper cycle counting at the expense of real-world-time correspondence. Maybe someday we might get it to work for us. Signed-off-by: Andy Ross <andrew.j.ross@intel.com> 2018-10-12 06:46:13 +08:00			`CONFIG_QEMU_TICKLESS_WORKAROUND=y`