From f70bb21de02d58491685ad9dbf108881940f9ac8 Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Mon, 10 Jun 2019 15:50:26 -0700 Subject: [PATCH 01/21] drivers/timer/nrf_rtc_timer: Fix round-up for rapid tick rates When the tick rate was less than MIN_DELAY, bumping a "too soon" expiration by just one tick may not be enough and we could theoretically miss the counter. Instead, eliminate the MIN_DELAY computation and write to the spec: NRF guarantees that the RTC will generate an interrupt for a comparator value two cycles in the future. And further, we can test at the set point to see if we "just missed" the interrupt (i.e. zero cycles delay) and flag a synchronous interrupt. So we only need to miss a requested interrupt now for the special case of exactly one cycle in the future, and then we're only late by one cycle. That's optimal. Also fixes an off-by-one in the next cycle computation. By API convention, an ticks argument of one or less means "at the next tick" and not "right now". So we need to add one to the target cycle to avoid incorrectly triggering a synchronous interrupt. This was a non-issue when a tick is longer than a hardware cycle but is needed now. Also handles the edge case with zero latency interrupts (which are unmaskable) which might mess up timing. This was always a problem, but we're more sensitive now and it's comparatively more likely to occur. Signed-off-by: Andy Ross --- drivers/timer/nrf_rtc_timer.c | 78 +++++++++++++++++++++++++++++++---- 1 file changed, 69 insertions(+), 9 deletions(-) diff --git a/drivers/timer/nrf_rtc_timer.c b/drivers/timer/nrf_rtc_timer.c index 9f300b57344f..cb8a9c915b11 100644 --- a/drivers/timer/nrf_rtc_timer.c +++ b/drivers/timer/nrf_rtc_timer.c @@ -20,8 +20,6 @@ / CONFIG_SYS_CLOCK_TICKS_PER_SEC) #define MAX_TICKS ((COUNTER_MAX - CYC_PER_TICK) / CYC_PER_TICK) -#define MIN_DELAY 32 - static struct k_spinlock lock; static u32_t last_count; @@ -63,7 +61,10 @@ void rtc1_nrf_isr(void *arg) if (!IS_ENABLED(CONFIG_TICKLESS_KERNEL)) { u32_t next = last_count + CYC_PER_TICK; - if (counter_sub(next, t) < MIN_DELAY) { + /* As below: we're guaranteed to get an interrupt as + * long as it's set two or more cycles in the future + */ + if (counter_sub(next, t) < 3) { next += CYC_PER_TICK; } set_comparator(next); @@ -117,21 +118,80 @@ void z_clock_set_timeout(s32_t ticks, bool idle) ticks = MAX(MIN(ticks - 1, (s32_t)MAX_TICKS), 0); k_spinlock_key_t key = k_spin_lock(&lock); - u32_t cyc, t = counter(); + u32_t cyc, dt, t = counter(); + bool flagged = false; /* Round up to next tick boundary */ - cyc = ticks * CYC_PER_TICK + counter_sub(t, last_count); + cyc = ticks * CYC_PER_TICK + 1 + counter_sub(t, last_count); cyc += (CYC_PER_TICK - 1); cyc = (cyc / CYC_PER_TICK) * CYC_PER_TICK; cyc += last_count; - if (counter_sub(cyc, t) < MIN_DELAY) { - cyc += CYC_PER_TICK; + /* Per NRF docs, the RTC is guaranteed to trigger a compare + * event if the comparator value to be set is at least two + * cycles later than the current value of the counter. So if + * we're three or more cycles out, we can set it blindly. If + * not, check the time again immediately after setting: it's + * possible we "just missed it" and can flag an immediate + * interrupt. Or it could be exactly two cycles out, which + * will have worked. Otherwise, there's no way to get an + * interrupt at the right time and we have to slip the event + * by one clock cycle (or we could spin, but this is a slow + * clock and spinning for a whole cycle can be thousands of + * instructions!) + * + * You might ask: why not set the comparator first and then + * check the timer synchronously to see if we missed it, which + * would avoid the need for a slipped cycle. That doesn't + * work, the states overlap inside the counter hardware. It's + * possible to set a comparator value of "N", issue a DSB + * instruction to flush the pipeline, and then immediately + * read a counter value of "N-1" (i.e. the comparator is still + * in the future), and yet still not receive an interrupt at + * least on nRF52. Some experimentation on nrf52840 shows + * that you need to be early by about 400 processor cycles + * (about 1/5th of a RTC cycle) in order to reliably get the + * interrupt. The docs say two cycles, they mean two cycles. + */ + if (counter_sub(cyc, t) > 2) { + set_comparator(cyc); + } else { + set_comparator(cyc); + dt = counter_sub(cyc, counter()); + if (dt == 0 || dt > 0x7fffff) { + /* Missed it! */ + NVIC_SetPendingIRQ(RTC1_IRQn); + if (IS_ENABLED(CONFIG_ZERO_LATENCY_IRQS)) { + flagged = true; + } + } else if (dt == 1) { + /* Too soon, interrupt won't arrive. */ + set_comparator(cyc + 1); + } + /* Otherwise it was two cycles out, we're fine */ } - set_comparator(cyc); - k_spin_unlock(&lock, key); +#ifdef CONFIG_ZERO_LATENCY_IRQS + /* Failsafe. ZLIs can preempt us even though interrupts are + * masked, blowing up the sensitive timing above. If enabled, + * we need a final check (in a loop! because this too can be + * interrupted) to see that the comparator is still in the + * future. Don't bother being fancy with cycle counting here, + * just set an interrupt "soon" that we know will get the + * timer back to a known state. This handles (via some hairy + * modular expressions) the wraparound cases where we are + * preempted for as much as half the counter space. + */ + if (!flagged && counter_sub(cyc, counter()) <= 0x7fffff) { + while (counter_sub(cyc, counter() + 2) > 0x7fffff) { + cyc = counter() + 3; + set_comparator(cyc); + } + } #endif + + k_spin_unlock(&lock, key); +#endif /* CONFIG_TICKLESS_KERNEL */ } u32_t z_clock_elapsed(void) From 6a7fe6156392db9e5b6d6dd520c3416efb14a332 Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Tue, 11 Jun 2019 10:38:20 -0700 Subject: [PATCH 02/21] tests/kernel/mem_pool: Fix timeout units This code was clearly written to assume that the timeout argument to k_mem_pool_alloc() was in ticks and not ms. Adjust to what appears to have been the intent. It was working as intended (i.e waiting one or 1/10th of a second) only on systems where the default tick rate was 100 Hz. Signed-off-by: Andy Ross --- tests/kernel/mem_pool/mem_pool/src/main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/kernel/mem_pool/mem_pool/src/main.c b/tests/kernel/mem_pool/mem_pool/src/main.c index 9f7e447c30fb..5d21913ca028 100644 --- a/tests/kernel/mem_pool/mem_pool/src/main.c +++ b/tests/kernel/mem_pool/mem_pool/src/main.c @@ -22,8 +22,8 @@ #include #include -#define ONE_SECOND (CONFIG_SYS_CLOCK_TICKS_PER_SEC) -#define TENTH_SECOND (CONFIG_SYS_CLOCK_TICKS_PER_SEC / 10) +#define ONE_SECOND 1000 +#define TENTH_SECOND 100 #define NUM_BLOCKS 64 From c17a362c052dbb62545f05ecb907aeb213c56558 Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Tue, 11 Jun 2019 11:02:01 -0700 Subject: [PATCH 03/21] tests: samples: Apps shouldn't set tick rate Tick rate is becoming a platform tunable in the tickless world. Some apps were setting it due to requirements of drivers or subsystems (or sometimes for reasons that don't make much sense), but the dependency goes the other way around now: board/soc/arch level code is responsible for setting tick rates that work with their devices. A few tests still use hard-configured tick rates, as they have baked-in assumptions (like e.g. "a tick will be longer than a millisecond") that need to be addressed first. Signed-off-by: Andy Ross --- samples/bluetooth/mesh/microbit_gatt.conf | 1 - samples/bluetooth/mesh/prj_bbc_microbit.conf | 1 - samples/bluetooth/mesh_demo/prj_bbc_microbit.conf | 1 - samples/boards/bbc_microbit/display/prj.conf | 1 - samples/boards/bbc_microbit/pong/prj.conf | 1 - samples/boards/bbc_microbit/sound/prj.conf | 1 - samples/philosophers/prj.conf | 1 - samples/portability/cmsis_rtos_v1/philosophers/prj.conf | 1 - .../portability/cmsis_rtos_v1/timer_synchronization/prj.conf | 1 - samples/portability/cmsis_rtos_v2/philosophers/prj.conf | 1 - .../portability/cmsis_rtos_v2/timer_synchronization/prj.conf | 1 - tests/bluetooth/mesh/microbit.conf | 1 - tests/bluetooth/mesh/microbit_gatt.conf | 1 - tests/drivers/build_all/sensors_a_h.conf | 4 ---- tests/kernel/tickless/tickless/prj.conf | 3 +++ 15 files changed, 3 insertions(+), 17 deletions(-) diff --git a/samples/bluetooth/mesh/microbit_gatt.conf b/samples/bluetooth/mesh/microbit_gatt.conf index fc5f62c164fc..a0682b0771dd 100644 --- a/samples/bluetooth/mesh/microbit_gatt.conf +++ b/samples/bluetooth/mesh/microbit_gatt.conf @@ -3,7 +3,6 @@ CONFIG_MAIN_STACK_SIZE=320 CONFIG_IDLE_STACK_SIZE=128 CONFIG_DISPLAY=y CONFIG_MICROBIT_DISPLAY=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=250 CONFIG_GPIO=y CONFIG_BT_PERIPHERAL=y diff --git a/samples/bluetooth/mesh/prj_bbc_microbit.conf b/samples/bluetooth/mesh/prj_bbc_microbit.conf index 79755b5ab4c0..bba9139a5585 100644 --- a/samples/bluetooth/mesh/prj_bbc_microbit.conf +++ b/samples/bluetooth/mesh/prj_bbc_microbit.conf @@ -2,7 +2,6 @@ CONFIG_INIT_STACKS=y CONFIG_MAIN_STACK_SIZE=512 CONFIG_DISPLAY=y CONFIG_MICROBIT_DISPLAY=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=250 CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048 CONFIG_GPIO=y diff --git a/samples/bluetooth/mesh_demo/prj_bbc_microbit.conf b/samples/bluetooth/mesh_demo/prj_bbc_microbit.conf index 24844682d973..8066cb3ec0be 100644 --- a/samples/bluetooth/mesh_demo/prj_bbc_microbit.conf +++ b/samples/bluetooth/mesh_demo/prj_bbc_microbit.conf @@ -2,7 +2,6 @@ CONFIG_MAIN_STACK_SIZE=512 #CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=1280 CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=250 CONFIG_GPIO=y CONFIG_DISPLAY=y CONFIG_MICROBIT_DISPLAY=y diff --git a/samples/boards/bbc_microbit/display/prj.conf b/samples/boards/bbc_microbit/display/prj.conf index cf12d62ca051..76f2b8952b50 100644 --- a/samples/boards/bbc_microbit/display/prj.conf +++ b/samples/boards/bbc_microbit/display/prj.conf @@ -2,4 +2,3 @@ CONFIG_GPIO=y CONFIG_DISPLAY=y CONFIG_MICROBIT_DISPLAY=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=250 diff --git a/samples/boards/bbc_microbit/pong/prj.conf b/samples/boards/bbc_microbit/pong/prj.conf index 32e93267f7dd..4ed8dca23a1e 100644 --- a/samples/boards/bbc_microbit/pong/prj.conf +++ b/samples/boards/bbc_microbit/pong/prj.conf @@ -1,4 +1,3 @@ -CONFIG_SYS_CLOCK_TICKS_PER_SEC=250 CONFIG_ISR_STACK_SIZE=1024 CONFIG_BT=y CONFIG_BT_CENTRAL=y diff --git a/samples/boards/bbc_microbit/sound/prj.conf b/samples/boards/bbc_microbit/sound/prj.conf index 62489c8f7bfb..2bce0fda2c3e 100644 --- a/samples/boards/bbc_microbit/sound/prj.conf +++ b/samples/boards/bbc_microbit/sound/prj.conf @@ -3,4 +3,3 @@ CONFIG_DISPLAY=y CONFIG_MICROBIT_DISPLAY=y CONFIG_PWM=y CONFIG_PWM_NRF5_SW=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=250 diff --git a/samples/philosophers/prj.conf b/samples/philosophers/prj.conf index 0b432095bcda..7a2c808f1012 100644 --- a/samples/philosophers/prj.conf +++ b/samples/philosophers/prj.conf @@ -1,5 +1,4 @@ CONFIG_STDOUT_CONSOLE=n -CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 CONFIG_ASSERT=y CONFIG_ASSERT_LEVEL=2 CONFIG_NUM_COOP_PRIORITIES=29 diff --git a/samples/portability/cmsis_rtos_v1/philosophers/prj.conf b/samples/portability/cmsis_rtos_v1/philosophers/prj.conf index 7c657b272d92..2b8481640ea1 100644 --- a/samples/portability/cmsis_rtos_v1/philosophers/prj.conf +++ b/samples/portability/cmsis_rtos_v1/philosophers/prj.conf @@ -1,4 +1,3 @@ -CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 CONFIG_ASSERT=y CONFIG_ASSERT_LEVEL=2 CONFIG_CMSIS_RTOS_V1=y diff --git a/samples/portability/cmsis_rtos_v1/timer_synchronization/prj.conf b/samples/portability/cmsis_rtos_v1/timer_synchronization/prj.conf index 0319f1d16ab6..26e412ac7c11 100644 --- a/samples/portability/cmsis_rtos_v1/timer_synchronization/prj.conf +++ b/samples/portability/cmsis_rtos_v1/timer_synchronization/prj.conf @@ -1,4 +1,3 @@ -CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 CONFIG_ASSERT=y CONFIG_ASSERT_LEVEL=2 CONFIG_CMSIS_RTOS_V1=y diff --git a/samples/portability/cmsis_rtos_v2/philosophers/prj.conf b/samples/portability/cmsis_rtos_v2/philosophers/prj.conf index 57a6fcb2bd26..700dfdc61a2d 100644 --- a/samples/portability/cmsis_rtos_v2/philosophers/prj.conf +++ b/samples/portability/cmsis_rtos_v2/philosophers/prj.conf @@ -1,4 +1,3 @@ -CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 CONFIG_ASSERT=y CONFIG_ASSERT_LEVEL=2 CONFIG_CMSIS_RTOS_V2=y diff --git a/samples/portability/cmsis_rtos_v2/timer_synchronization/prj.conf b/samples/portability/cmsis_rtos_v2/timer_synchronization/prj.conf index e5e0dec481e8..2dd440581e3c 100644 --- a/samples/portability/cmsis_rtos_v2/timer_synchronization/prj.conf +++ b/samples/portability/cmsis_rtos_v2/timer_synchronization/prj.conf @@ -1,4 +1,3 @@ -CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 CONFIG_ASSERT=y CONFIG_ASSERT_LEVEL=2 CONFIG_CMSIS_RTOS_V2=y diff --git a/tests/bluetooth/mesh/microbit.conf b/tests/bluetooth/mesh/microbit.conf index db5a81b206a5..7324a83c9aec 100644 --- a/tests/bluetooth/mesh/microbit.conf +++ b/tests/bluetooth/mesh/microbit.conf @@ -3,7 +3,6 @@ CONFIG_INIT_STACKS=y CONFIG_MAIN_STACK_SIZE=512 CONFIG_DISPLAY=y CONFIG_MICROBIT_DISPLAY=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=250 CONFIG_GPIO=y CONFIG_BT=y diff --git a/tests/bluetooth/mesh/microbit_gatt.conf b/tests/bluetooth/mesh/microbit_gatt.conf index 3c3a08e35511..5a9737b3f554 100644 --- a/tests/bluetooth/mesh/microbit_gatt.conf +++ b/tests/bluetooth/mesh/microbit_gatt.conf @@ -3,7 +3,6 @@ CONFIG_TEST=y CONFIG_MAIN_STACK_SIZE=512 CONFIG_DISPLAY=y CONFIG_MICROBIT_DISPLAY=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=250 CONFIG_GPIO=y CONFIG_BT_PERIPHERAL=y diff --git a/tests/drivers/build_all/sensors_a_h.conf b/tests/drivers/build_all/sensors_a_h.conf index 582e3719bcad..4cb970605325 100644 --- a/tests/drivers/build_all/sensors_a_h.conf +++ b/tests/drivers/build_all/sensors_a_h.conf @@ -6,10 +6,6 @@ CONFIG_SPI=y CONFIG_LOG=y CONFIG_SENSOR_LOG_LEVEL_DBG=y CONFIG_TEST_USERSPACE=y - -# Some sensor drivers (notably HP206C) demand high tick rates: -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 - CONFIG_ADC=y CONFIG_ADT7420=y CONFIG_ADXL362=y diff --git a/tests/kernel/tickless/tickless/prj.conf b/tests/kernel/tickless/tickless/prj.conf index 999abd18cda8..221188ede02b 100644 --- a/tests/kernel/tickless/tickless/prj.conf +++ b/tests/kernel/tickless/tickless/prj.conf @@ -1,2 +1,5 @@ CONFIG_SYS_POWER_MANAGEMENT=y CONFIG_ZTEST=y + +# The code is written to assume a slow tick rate +CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 \ No newline at end of file From b423594c7c8844bd96a2d317f6420806739bf7de Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Tue, 11 Jun 2019 11:18:20 -0700 Subject: [PATCH 04/21] kernel: Crank up default tick rate When tickless is available, all existing devices can handle much higher timing precision than 10ms. A 10kHz default seems acceptable without introducing too much range limitation (rollover for a signed time delta will happen at 2.5 days). Leave the 100 Hz default in place for ticked configurations, as those are going to be special purpose usages where the user probably actually cares about interrupt rate. Note that the defaulting logic interacts with an obscure trick: setting the tick rate to zero would indicate "no clock exists" to the configuration (some platforms use this to drop code from the build). But now that becomes a kconfig cycle, so to break it we expose CONFIG_SYS_CLOCK_EXISTS as an app-defined tunable and not a derived value from the tick rate. Only one test actually did this. Signed-off-by: Andy Ross --- include/kernel.h | 6 ++---- kernel/Kconfig | 11 ++++++++--- samples/basic/minimal/no-timers.conf | 3 +-- 3 files changed, 11 insertions(+), 9 deletions(-) diff --git a/include/kernel.h b/include/kernel.h index fe58675098d4..d1a84c353573 100644 --- a/include/kernel.h +++ b/include/kernel.h @@ -1684,8 +1684,7 @@ static inline void *z_impl_k_timer_user_data_get(struct k_timer *timer) * @rst * While this function returns time in milliseconds, it does * not mean it has millisecond resolution. The actual resolution depends on - * :option:`CONFIG_SYS_CLOCK_TICKS_PER_SEC` config option, and with the - * default setting of 100, system time is updated in increments of 10ms. + * :option:`CONFIG_SYS_CLOCK_TICKS_PER_SEC` config option. * @endrst * * @return Current uptime in milliseconds. @@ -1741,8 +1740,7 @@ __deprecated static inline void k_disable_sys_clock_always_on(void) * @rst * While this function returns time in milliseconds, it does * not mean it has millisecond resolution. The actual resolution depends on - * :option:`CONFIG_SYS_CLOCK_TICKS_PER_SEC` config option, and with the - * default setting of 100, system time is updated in increments of 10ms. + * :option:`CONFIG_SYS_CLOCK_TICKS_PER_SEC` config option * @endrst * * @return Current uptime in milliseconds. diff --git a/kernel/Kconfig b/kernel/Kconfig index f161fd693af9..609e6b343feb 100644 --- a/kernel/Kconfig +++ b/kernel/Kconfig @@ -529,9 +529,11 @@ config ARCH_HAS_CUSTOM_BUSY_WAIT config SYS_CLOCK_TICKS_PER_SEC int "System tick frequency (in ticks/second)" + default 100 if QEMU_TARGET || SOC_POSIX + default 10000 if TICKLESS_CAPABLE default 100 help - This option specifies the frequency of the system clock in Hz. + This option specifies the nominal frequency of the system clock in Hz. Depending on the choice made, an amount of possibly expensive math must occur when converting ticks to milliseconds and vice-versa. Some values @@ -567,10 +569,13 @@ config SYS_CLOCK_HW_CYCLES_PER_SEC and the user should generally avoid modifying it via the menu configuration. config SYS_CLOCK_EXISTS - def_bool (SYS_CLOCK_TICKS_PER_SEC != 0) - # omit prompt to signify a "hidden" option + bool "System clock exists and is enabled" + default y help This option specifies that the kernel lacks timer support. + Some device configurations can eliminate significant code if + this is disabled. Obviously timeout-related APIs will not + work. config XIP bool "Execute in place" diff --git a/samples/basic/minimal/no-timers.conf b/samples/basic/minimal/no-timers.conf index 05dc0d53afd1..961178ee05c7 100644 --- a/samples/basic/minimal/no-timers.conf +++ b/samples/basic/minimal/no-timers.conf @@ -1,3 +1,2 @@ # No timer support in the kernel - -CONFIG_SYS_CLOCK_TICKS_PER_SEC=0 +CONFIG_SYS_CLOCK_EXISTS=n From 7ceac5e4afc0620507bc01b3d05d88ac0e420aef Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Tue, 11 Jun 2019 11:20:51 -0700 Subject: [PATCH 05/21] boards/arm: Remove 1000 Hz tick rate on STM32 boards These all have what appears to be a promiscuously cut-and-pasted declaration for a 1000 Hz tick rate. They are all SysTick boards and will work very well with the new 10 kHz default, so use that instead. Signed-off-by: Andy Ross --- boards/arm/96b_argonkey/96b_argonkey_defconfig | 1 - boards/arm/96b_carbon/96b_carbon_defconfig | 1 - boards/arm/96b_neonkey/96b_neonkey_defconfig | 1 - boards/arm/96b_stm32_sensor_mez/96b_stm32_sensor_mez_defconfig | 1 - boards/arm/disco_l475_iot1/disco_l475_iot1_defconfig | 1 - .../mikroe_mini_m4_for_stm32/mikroe_mini_m4_for_stm32_defconfig | 1 - boards/arm/nucleo_f207zg/nucleo_f207zg_defconfig | 1 - boards/arm/nucleo_f302r8/nucleo_f302r8_defconfig | 1 - boards/arm/nucleo_f401re/nucleo_f401re_defconfig | 1 - boards/arm/nucleo_f411re/nucleo_f411re_defconfig | 1 - boards/arm/nucleo_f412zg/nucleo_f412zg_defconfig | 1 - boards/arm/nucleo_f413zh/nucleo_f413zh_defconfig | 1 - boards/arm/nucleo_f429zi/nucleo_f429zi_defconfig | 1 - boards/arm/nucleo_f446re/nucleo_f446re_defconfig | 1 - boards/arm/nucleo_f746zg/nucleo_f746zg_defconfig | 1 - boards/arm/nucleo_f756zg/nucleo_f756zg_defconfig | 1 - boards/arm/nucleo_l053r8/nucleo_l053r8_defconfig | 1 - boards/arm/nucleo_wb55rg/nucleo_wb55rg_defconfig | 1 - boards/arm/olimex_stm32_e407/olimex_stm32_e407_defconfig | 1 - boards/arm/olimex_stm32_h407/olimex_stm32_h407_defconfig | 1 - boards/arm/olimex_stm32_p405/olimex_stm32_p405_defconfig | 1 - boards/arm/stm32f3_disco/stm32f3_disco_defconfig | 1 - boards/arm/stm32f411e_disco/stm32f411e_disco_defconfig | 1 - boards/arm/stm32f412g_disco/stm32f412g_disco_defconfig | 1 - boards/arm/stm32f429i_disc1/stm32f429i_disc1_defconfig | 1 - boards/arm/stm32f469i_disco/stm32f469i_disco_defconfig | 1 - boards/arm/stm32f4_disco/stm32f4_disco_defconfig | 1 - boards/arm/stm32f723e_disco/stm32f723e_disco_defconfig | 1 - boards/arm/stm32f746g_disco/stm32f746g_disco_defconfig | 1 - boards/arm/stm32f769i_disco/stm32f769i_disco_defconfig | 1 - 30 files changed, 30 deletions(-) diff --git a/boards/arm/96b_argonkey/96b_argonkey_defconfig b/boards/arm/96b_argonkey/96b_argonkey_defconfig index 0f08a3092f07..5e3b9c597e20 100644 --- a/boards/arm/96b_argonkey/96b_argonkey_defconfig +++ b/boards/arm/96b_argonkey/96b_argonkey_defconfig @@ -7,7 +7,6 @@ CONFIG_CORTEX_M_SYSTICK=y # 84MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=84000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # enable uart driver CONFIG_SERIAL=y diff --git a/boards/arm/96b_carbon/96b_carbon_defconfig b/boards/arm/96b_carbon/96b_carbon_defconfig index 7e12df46884e..53898d992f39 100644 --- a/boards/arm/96b_carbon/96b_carbon_defconfig +++ b/boards/arm/96b_carbon/96b_carbon_defconfig @@ -7,7 +7,6 @@ CONFIG_CORTEX_M_SYSTICK=y # 84MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=84000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/96b_neonkey/96b_neonkey_defconfig b/boards/arm/96b_neonkey/96b_neonkey_defconfig index 4f57013337be..27b171e16bc4 100644 --- a/boards/arm/96b_neonkey/96b_neonkey_defconfig +++ b/boards/arm/96b_neonkey/96b_neonkey_defconfig @@ -7,7 +7,6 @@ CONFIG_CORTEX_M_SYSTICK=y # 84MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=84000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # enable uart driver CONFIG_SERIAL=y diff --git a/boards/arm/96b_stm32_sensor_mez/96b_stm32_sensor_mez_defconfig b/boards/arm/96b_stm32_sensor_mez/96b_stm32_sensor_mez_defconfig index 261e2773788c..47b9b78d8cb2 100644 --- a/boards/arm/96b_stm32_sensor_mez/96b_stm32_sensor_mez_defconfig +++ b/boards/arm/96b_stm32_sensor_mez/96b_stm32_sensor_mez_defconfig @@ -8,7 +8,6 @@ CONFIG_CORTEX_M_SYSTICK=y # 84MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=84000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/disco_l475_iot1/disco_l475_iot1_defconfig b/boards/arm/disco_l475_iot1/disco_l475_iot1_defconfig index c51404249da9..d2d32663dd27 100644 --- a/boards/arm/disco_l475_iot1/disco_l475_iot1_defconfig +++ b/boards/arm/disco_l475_iot1/disco_l475_iot1_defconfig @@ -5,7 +5,6 @@ CONFIG_BOARD_DISCO_L475_IOT1=y CONFIG_SOC_SERIES_STM32L4X=y CONFIG_SOC_STM32L475XX=y CONFIG_CORTEX_M_SYSTICK=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # enable uart driver CONFIG_SERIAL=y diff --git a/boards/arm/mikroe_mini_m4_for_stm32/mikroe_mini_m4_for_stm32_defconfig b/boards/arm/mikroe_mini_m4_for_stm32/mikroe_mini_m4_for_stm32_defconfig index 3d755828b301..62488a9cd53e 100644 --- a/boards/arm/mikroe_mini_m4_for_stm32/mikroe_mini_m4_for_stm32_defconfig +++ b/boards/arm/mikroe_mini_m4_for_stm32/mikroe_mini_m4_for_stm32_defconfig @@ -5,7 +5,6 @@ CONFIG_SOC_STM32F415XX=y # 168MHz system clock CONFIG_CORTEX_M_SYSTICK=y CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=168000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/nucleo_f207zg/nucleo_f207zg_defconfig b/boards/arm/nucleo_f207zg/nucleo_f207zg_defconfig index 60cf723c75cf..4fb325f45880 100644 --- a/boards/arm/nucleo_f207zg/nucleo_f207zg_defconfig +++ b/boards/arm/nucleo_f207zg/nucleo_f207zg_defconfig @@ -6,7 +6,6 @@ CONFIG_SOC_SERIES_STM32F2X=y CONFIG_SOC_STM32F207XX=y CONFIG_CORTEX_M_SYSTICK=y CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=120000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 CONFIG_SERIAL=y diff --git a/boards/arm/nucleo_f302r8/nucleo_f302r8_defconfig b/boards/arm/nucleo_f302r8/nucleo_f302r8_defconfig index d9ccefa129ef..5b96a90db71d 100644 --- a/boards/arm/nucleo_f302r8/nucleo_f302r8_defconfig +++ b/boards/arm/nucleo_f302r8/nucleo_f302r8_defconfig @@ -6,7 +6,6 @@ CONFIG_SOC_STM32F302X8=y CONFIG_CORTEX_M_SYSTICK=y # 72 MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=72000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 CONFIG_SERIAL=y diff --git a/boards/arm/nucleo_f401re/nucleo_f401re_defconfig b/boards/arm/nucleo_f401re/nucleo_f401re_defconfig index 3e7dcc1cd1b5..da0333f84ecb 100644 --- a/boards/arm/nucleo_f401re/nucleo_f401re_defconfig +++ b/boards/arm/nucleo_f401re/nucleo_f401re_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F401XE=y CONFIG_CORTEX_M_SYSTICK=y # 84MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=84000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/nucleo_f411re/nucleo_f411re_defconfig b/boards/arm/nucleo_f411re/nucleo_f411re_defconfig index b363ba79a1d9..9f3f9c15050a 100644 --- a/boards/arm/nucleo_f411re/nucleo_f411re_defconfig +++ b/boards/arm/nucleo_f411re/nucleo_f411re_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F411XE=y CONFIG_CORTEX_M_SYSTICK=y # 96MHz system clock (highest value to get a precise USB clock) CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=96000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/nucleo_f412zg/nucleo_f412zg_defconfig b/boards/arm/nucleo_f412zg/nucleo_f412zg_defconfig index 8d33e9099b7b..ea5f2b028134 100644 --- a/boards/arm/nucleo_f412zg/nucleo_f412zg_defconfig +++ b/boards/arm/nucleo_f412zg/nucleo_f412zg_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F412ZG=y CONFIG_CORTEX_M_SYSTICK=y # 96MHz system clock (highest value to get a precise USB clock) CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=96000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/nucleo_f413zh/nucleo_f413zh_defconfig b/boards/arm/nucleo_f413zh/nucleo_f413zh_defconfig index 610f287768f4..e45c3014e229 100644 --- a/boards/arm/nucleo_f413zh/nucleo_f413zh_defconfig +++ b/boards/arm/nucleo_f413zh/nucleo_f413zh_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F413XX=y CONFIG_CORTEX_M_SYSTICK=y # 96MHz system clock (highest value to get a precise USB clock) CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=96000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/nucleo_f429zi/nucleo_f429zi_defconfig b/boards/arm/nucleo_f429zi/nucleo_f429zi_defconfig index 22de8a3af8dd..a3845865d260 100644 --- a/boards/arm/nucleo_f429zi/nucleo_f429zi_defconfig +++ b/boards/arm/nucleo_f429zi/nucleo_f429zi_defconfig @@ -6,7 +6,6 @@ CONFIG_SOC_STM32F429XX=y CONFIG_CORTEX_M_SYSTICK=y # 168MHz system clock (highest value to get a precise USB clock) CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=168000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/nucleo_f446re/nucleo_f446re_defconfig b/boards/arm/nucleo_f446re/nucleo_f446re_defconfig index 73840f749bc6..2e5b4c217495 100644 --- a/boards/arm/nucleo_f446re/nucleo_f446re_defconfig +++ b/boards/arm/nucleo_f446re/nucleo_f446re_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F446XX=y CONFIG_CORTEX_M_SYSTICK=y # 96MHz system clock (highest value to get a precise USB clock) CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=96000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/nucleo_f746zg/nucleo_f746zg_defconfig b/boards/arm/nucleo_f746zg/nucleo_f746zg_defconfig index f57de499da87..34c6222b4d35 100644 --- a/boards/arm/nucleo_f746zg/nucleo_f746zg_defconfig +++ b/boards/arm/nucleo_f746zg/nucleo_f746zg_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F746XX=y CONFIG_CORTEX_M_SYSTICK=y # 72MHz system clock (CubeMX Defaults) CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=72000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/nucleo_f756zg/nucleo_f756zg_defconfig b/boards/arm/nucleo_f756zg/nucleo_f756zg_defconfig index 3ec3bc6dd373..303071bb0de6 100644 --- a/boards/arm/nucleo_f756zg/nucleo_f756zg_defconfig +++ b/boards/arm/nucleo_f756zg/nucleo_f756zg_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F756XX=y CONFIG_CORTEX_M_SYSTICK=y # 72MHz system clock (CubeMX Defaults) CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=72000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/nucleo_l053r8/nucleo_l053r8_defconfig b/boards/arm/nucleo_l053r8/nucleo_l053r8_defconfig index d484e27cb3c9..aaa47cc692da 100644 --- a/boards/arm/nucleo_l053r8/nucleo_l053r8_defconfig +++ b/boards/arm/nucleo_l053r8/nucleo_l053r8_defconfig @@ -12,7 +12,6 @@ CONFIG_BOARD_NUCLEO_L053R8=y # General Kernel Options CONFIG_CORTEX_M_SYSTICK=y CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=32000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Kernel Options due to Low Memory (8k) CONFIG_MAIN_STACK_SIZE=640 diff --git a/boards/arm/nucleo_wb55rg/nucleo_wb55rg_defconfig b/boards/arm/nucleo_wb55rg/nucleo_wb55rg_defconfig index 44b6f189201d..524f5f20a6f7 100644 --- a/boards/arm/nucleo_wb55rg/nucleo_wb55rg_defconfig +++ b/boards/arm/nucleo_wb55rg/nucleo_wb55rg_defconfig @@ -4,7 +4,6 @@ CONFIG_SOC_STM32WB55XX=y CONFIG_CORTEX_M_SYSTICK=y # 32MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=32000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # enable uart driver CONFIG_SERIAL=y diff --git a/boards/arm/olimex_stm32_e407/olimex_stm32_e407_defconfig b/boards/arm/olimex_stm32_e407/olimex_stm32_e407_defconfig index fe56bfdc6a7b..261c059a4af0 100644 --- a/boards/arm/olimex_stm32_e407/olimex_stm32_e407_defconfig +++ b/boards/arm/olimex_stm32_e407/olimex_stm32_e407_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F407XG=y CONFIG_CORTEX_M_SYSTICK=y # 168MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=168000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/olimex_stm32_h407/olimex_stm32_h407_defconfig b/boards/arm/olimex_stm32_h407/olimex_stm32_h407_defconfig index 5333950770d8..57d0a72c722b 100644 --- a/boards/arm/olimex_stm32_h407/olimex_stm32_h407_defconfig +++ b/boards/arm/olimex_stm32_h407/olimex_stm32_h407_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F407XG=y CONFIG_CORTEX_M_SYSTICK=y # 168MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=168000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/olimex_stm32_p405/olimex_stm32_p405_defconfig b/boards/arm/olimex_stm32_p405/olimex_stm32_p405_defconfig index 29efc222d247..5234f3c5e644 100644 --- a/boards/arm/olimex_stm32_p405/olimex_stm32_p405_defconfig +++ b/boards/arm/olimex_stm32_p405/olimex_stm32_p405_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F405XG=y CONFIG_CORTEX_M_SYSTICK=y # 168MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=168000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/stm32f3_disco/stm32f3_disco_defconfig b/boards/arm/stm32f3_disco/stm32f3_disco_defconfig index 6ea53565147b..e767b78342fc 100644 --- a/boards/arm/stm32f3_disco/stm32f3_disco_defconfig +++ b/boards/arm/stm32f3_disco/stm32f3_disco_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F303XC=y CONFIG_CORTEX_M_SYSTICK=y # 72MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=72000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # ARM Options CONFIG_CPU_HAS_FPU=y diff --git a/boards/arm/stm32f411e_disco/stm32f411e_disco_defconfig b/boards/arm/stm32f411e_disco/stm32f411e_disco_defconfig index d66de781e635..4a94d7aecaf1 100644 --- a/boards/arm/stm32f411e_disco/stm32f411e_disco_defconfig +++ b/boards/arm/stm32f411e_disco/stm32f411e_disco_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F411XE=y CONFIG_CORTEX_M_SYSTICK=y # 100MHz system clock (highest value to get a precise USB clock should be 96MHz) CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=100000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/stm32f412g_disco/stm32f412g_disco_defconfig b/boards/arm/stm32f412g_disco/stm32f412g_disco_defconfig index 58ff0497eabc..5ed2ea215705 100644 --- a/boards/arm/stm32f412g_disco/stm32f412g_disco_defconfig +++ b/boards/arm/stm32f412g_disco/stm32f412g_disco_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F412ZG=y CONFIG_CORTEX_M_SYSTICK=y # 100MHz system clock (highest value to get a precise USB clock should be 96MHz) CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=100000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/stm32f429i_disc1/stm32f429i_disc1_defconfig b/boards/arm/stm32f429i_disc1/stm32f429i_disc1_defconfig index 1473d9851f5a..9243449cd2f1 100644 --- a/boards/arm/stm32f429i_disc1/stm32f429i_disc1_defconfig +++ b/boards/arm/stm32f429i_disc1/stm32f429i_disc1_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F429XX=y CONFIG_CORTEX_M_SYSTICK=y # 168MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=168000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/stm32f469i_disco/stm32f469i_disco_defconfig b/boards/arm/stm32f469i_disco/stm32f469i_disco_defconfig index 7fa0ea1347b7..0e9f92f9fdc9 100644 --- a/boards/arm/stm32f469i_disco/stm32f469i_disco_defconfig +++ b/boards/arm/stm32f469i_disco/stm32f469i_disco_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F469XX=y CONFIG_CORTEX_M_SYSTICK=y # 180MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=180000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/stm32f4_disco/stm32f4_disco_defconfig b/boards/arm/stm32f4_disco/stm32f4_disco_defconfig index 8c726ca2be34..5f79a98f038a 100644 --- a/boards/arm/stm32f4_disco/stm32f4_disco_defconfig +++ b/boards/arm/stm32f4_disco/stm32f4_disco_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F407XG=y CONFIG_CORTEX_M_SYSTICK=y # 168MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=168000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 # Enable MPU CONFIG_ARM_MPU=y diff --git a/boards/arm/stm32f723e_disco/stm32f723e_disco_defconfig b/boards/arm/stm32f723e_disco/stm32f723e_disco_defconfig index c1bb9f4b6515..f76f16d631a6 100644 --- a/boards/arm/stm32f723e_disco/stm32f723e_disco_defconfig +++ b/boards/arm/stm32f723e_disco/stm32f723e_disco_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F723XX=y CONFIG_CORTEX_M_SYSTICK=y # 216MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=216000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 CONFIG_SERIAL=y diff --git a/boards/arm/stm32f746g_disco/stm32f746g_disco_defconfig b/boards/arm/stm32f746g_disco/stm32f746g_disco_defconfig index d498e33052f0..8ee4f6c0be05 100644 --- a/boards/arm/stm32f746g_disco/stm32f746g_disco_defconfig +++ b/boards/arm/stm32f746g_disco/stm32f746g_disco_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F746XX=y CONFIG_CORTEX_M_SYSTICK=y # 216MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=216000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 CONFIG_SERIAL=y diff --git a/boards/arm/stm32f769i_disco/stm32f769i_disco_defconfig b/boards/arm/stm32f769i_disco/stm32f769i_disco_defconfig index 6f9492e4747c..c27631f96e88 100644 --- a/boards/arm/stm32f769i_disco/stm32f769i_disco_defconfig +++ b/boards/arm/stm32f769i_disco/stm32f769i_disco_defconfig @@ -7,7 +7,6 @@ CONFIG_SOC_STM32F769XX=y CONFIG_CORTEX_M_SYSTICK=y # 216MHz system clock CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=216000000 -CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 CONFIG_SERIAL=y From b76ab9b5aa2d7ddfc9f2f0e7e05ac9ebf02f8b72 Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Tue, 11 Jun 2019 11:29:06 -0700 Subject: [PATCH 06/21] boards/arc: Remove tick rate settings for ARC hardware The ARC timer is a MHz-scale cycle counter and works very well with the new 10 kHz default tick rate. Remove the settings for ARC hardware. Note that the nsim board definitions are left at 100 Hz. That is a software emulation environment that (like qemu) exposes the host clock as "real" time and thus is subject to clock jitter due to host scheduling. Signed-off-by: Andy Ross --- boards/arc/arduino_101_sss/arduino_101_sss_defconfig | 1 - boards/arc/em_starterkit/em_starterkit_defconfig | 1 - boards/arc/em_starterkit/em_starterkit_em11d_defconfig | 1 - boards/arc/em_starterkit/em_starterkit_em7d_defconfig | 1 - boards/arc/em_starterkit/em_starterkit_em7d_v22_defconfig | 1 - boards/arc/iotdk/iotdk_defconfig | 1 - .../quark_se_c1000_ss_devboard_defconfig | 1 - 7 files changed, 7 deletions(-) diff --git a/boards/arc/arduino_101_sss/arduino_101_sss_defconfig b/boards/arc/arduino_101_sss/arduino_101_sss_defconfig index 9492e52e6415..4ae6e67ec543 100644 --- a/boards/arc/arduino_101_sss/arduino_101_sss_defconfig +++ b/boards/arc/arduino_101_sss/arduino_101_sss_defconfig @@ -3,7 +3,6 @@ CONFIG_ARC=y CONFIG_SOC_QUARK_SE_C1000_SS=y CONFIG_BOARD_ARDUINO_101_SSS=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=32000000 CONFIG_XIP=y CONFIG_PRINTK=y diff --git a/boards/arc/em_starterkit/em_starterkit_defconfig b/boards/arc/em_starterkit/em_starterkit_defconfig index 15414a299518..09fc75787a9f 100644 --- a/boards/arc/em_starterkit/em_starterkit_defconfig +++ b/boards/arc/em_starterkit/em_starterkit_defconfig @@ -5,7 +5,6 @@ CONFIG_SOC_EMSK=y CONFIG_SOC_EMSK_EM9D=y CONFIG_BOARD_EM_STARTERKIT=y CONFIG_BOARD_EM_STARTERKIT_R23=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 CONFIG_XIP=n CONFIG_BUILD_OUTPUT_BIN=n CONFIG_PRINTK=y diff --git a/boards/arc/em_starterkit/em_starterkit_em11d_defconfig b/boards/arc/em_starterkit/em_starterkit_em11d_defconfig index 0dd02c0bbb52..52c89a9dfde3 100644 --- a/boards/arc/em_starterkit/em_starterkit_em11d_defconfig +++ b/boards/arc/em_starterkit/em_starterkit_em11d_defconfig @@ -5,7 +5,6 @@ CONFIG_SOC_EMSK=y CONFIG_SOC_EMSK_EM11D=y CONFIG_BOARD_EM_STARTERKIT=y CONFIG_BOARD_EM_STARTERKIT_R23=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 CONFIG_XIP=n CONFIG_BUILD_OUTPUT_BIN=n CONFIG_PRINTK=y diff --git a/boards/arc/em_starterkit/em_starterkit_em7d_defconfig b/boards/arc/em_starterkit/em_starterkit_em7d_defconfig index 77ab17a9c6a3..457315494d4b 100644 --- a/boards/arc/em_starterkit/em_starterkit_em7d_defconfig +++ b/boards/arc/em_starterkit/em_starterkit_em7d_defconfig @@ -5,7 +5,6 @@ CONFIG_SOC_EMSK=y CONFIG_SOC_EMSK_EM7D=y CONFIG_BOARD_EM_STARTERKIT=y CONFIG_BOARD_EM_STARTERKIT_R23=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 CONFIG_XIP=n CONFIG_BUILD_OUTPUT_BIN=n CONFIG_PRINTK=y diff --git a/boards/arc/em_starterkit/em_starterkit_em7d_v22_defconfig b/boards/arc/em_starterkit/em_starterkit_em7d_v22_defconfig index bdbcb53f252f..2b41c70d6924 100644 --- a/boards/arc/em_starterkit/em_starterkit_em7d_v22_defconfig +++ b/boards/arc/em_starterkit/em_starterkit_em7d_v22_defconfig @@ -5,7 +5,6 @@ CONFIG_SOC_EMSK=y CONFIG_SOC_EMSK_EM7D=y CONFIG_BOARD_EM_STARTERKIT=y CONFIG_BOARD_EM_STARTERKIT_R22=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 CONFIG_XIP=n CONFIG_BUILD_OUTPUT_BIN=n CONFIG_PRINTK=y diff --git a/boards/arc/iotdk/iotdk_defconfig b/boards/arc/iotdk/iotdk_defconfig index f69414846b51..686b1264cfbe 100644 --- a/boards/arc/iotdk/iotdk_defconfig +++ b/boards/arc/iotdk/iotdk_defconfig @@ -3,7 +3,6 @@ CONFIG_ARC=y CONFIG_SOC_ARC_IOT=y CONFIG_BOARD_IOTDK=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 CONFIG_XIP=n CONFIG_BUILD_OUTPUT_BIN=n CONFIG_PRINTK=y diff --git a/boards/arc/quark_se_c1000_ss_devboard/quark_se_c1000_ss_devboard_defconfig b/boards/arc/quark_se_c1000_ss_devboard/quark_se_c1000_ss_devboard_defconfig index 2d32dceb29c7..82ee4970d022 100644 --- a/boards/arc/quark_se_c1000_ss_devboard/quark_se_c1000_ss_devboard_defconfig +++ b/boards/arc/quark_se_c1000_ss_devboard/quark_se_c1000_ss_devboard_defconfig @@ -3,7 +3,6 @@ CONFIG_ARC=y CONFIG_SOC_QUARK_SE_C1000_SS=y CONFIG_BOARD_QUARK_SE_C1000_DEVBOARD_SS=y -CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=32000000 CONFIG_XIP=y CONFIG_PRINTK=y From b22a05de6e0795ddb377ed66424512a95346a2fb Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Tue, 11 Jun 2019 11:44:59 -0700 Subject: [PATCH 07/21] soc/arm: Increase nRF timer default to the cycle rate. The nRF timer runs at only 32 kHz, so there's little reason to try to divide it to get a synthesized tick rate. Just use the raw clock as the tick rate, which provides maximal precision and very singnificantly simplifies the generated code for the ISR. Signed-off-by: Andy Ross --- soc/arm/nordic_nrf/Kconfig.defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/soc/arm/nordic_nrf/Kconfig.defconfig b/soc/arm/nordic_nrf/Kconfig.defconfig index f3756b4e3bbf..f618c0c3d905 100644 --- a/soc/arm/nordic_nrf/Kconfig.defconfig +++ b/soc/arm/nordic_nrf/Kconfig.defconfig @@ -24,7 +24,7 @@ config SYS_CLOCK_HW_CYCLES_PER_SEC config SYS_CLOCK_TICKS_PER_SEC int - default 128 + default 32768 config ARCH_HAS_CUSTOM_BUSY_WAIT default y From c9e0787da93c626a055e18942b3599b4df428b83 Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Tue, 11 Jun 2019 11:48:21 -0700 Subject: [PATCH 08/21] soc/arm: Remove 1 kHz tick rate default for mcimx7_m4 and msp432p401r As with the STM32 boards, these had an existing default for tick rate that is now lower than the 10 kHz default. They're SysTick devices that can handle the higher rate just fine. Use that. Signed-off-by: Andy Ross --- soc/arm/nxp_imx/mcimx7_m4/Kconfig.defconfig.mcimx7_m4 | 4 ---- .../ti_simplelink/msp432p4xx/Kconfig.defconfig.msp432p401r | 4 ---- 2 files changed, 8 deletions(-) diff --git a/soc/arm/nxp_imx/mcimx7_m4/Kconfig.defconfig.mcimx7_m4 b/soc/arm/nxp_imx/mcimx7_m4/Kconfig.defconfig.mcimx7_m4 index 8d8b2427c68f..d87ce815c2e4 100644 --- a/soc/arm/nxp_imx/mcimx7_m4/Kconfig.defconfig.mcimx7_m4 +++ b/soc/arm/nxp_imx/mcimx7_m4/Kconfig.defconfig.mcimx7_m4 @@ -11,10 +11,6 @@ config SOC string default "mcimx7d" -config SYS_CLOCK_TICKS_PER_SEC - int - default 1000 - config SYS_CLOCK_HW_CYCLES_PER_SEC int default 200000000 diff --git a/soc/arm/ti_simplelink/msp432p4xx/Kconfig.defconfig.msp432p401r b/soc/arm/ti_simplelink/msp432p4xx/Kconfig.defconfig.msp432p401r index 3989fccd6201..472f94e7cf19 100644 --- a/soc/arm/ti_simplelink/msp432p4xx/Kconfig.defconfig.msp432p401r +++ b/soc/arm/ti_simplelink/msp432p4xx/Kconfig.defconfig.msp432p401r @@ -15,10 +15,6 @@ config SYS_CLOCK_HW_CYCLES_PER_SEC int default 48000000 -config SYS_CLOCK_TICKS_PER_SEC - int - default 1000 - config NUM_IRQS int default 64 From fe069898936b9afeacf19e9eb8a61692e3d32b2f Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Wed, 12 Jun 2019 10:01:32 -0700 Subject: [PATCH 09/21] tests/kernel/sched/schedule_api: Fix slice time test for fast ticks When ticks are sub-millisecond, the math produces minimum and maximum values for the slice duration test that are equal. But because of aliasing across tick boundaries, it's always possible (for any time period, nothing specific to time slicing here) to measure one tick more than an intended duration. So make sure there's always at least a range of 1ms. Signed-off-by: Andy Ross --- .../kernel/sched/schedule_api/src/test_slice_scheduling.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/tests/kernel/sched/schedule_api/src/test_slice_scheduling.c b/tests/kernel/sched/schedule_api/src/test_slice_scheduling.c index f31c4a4690ce..f03bf4eecc84 100644 --- a/tests/kernel/sched/schedule_api/src/test_slice_scheduling.c +++ b/tests/kernel/sched/schedule_api/src/test_slice_scheduling.c @@ -44,6 +44,14 @@ static void thread_tslice(void *p1, void *p2, void *p3) s64_t expected_slice_min = __ticks_to_ms(z_ms_to_ticks(SLICE_SIZE)); s64_t expected_slice_max = __ticks_to_ms(z_ms_to_ticks(SLICE_SIZE) + 1); + /* Clumsy, but need to handle the precision loss with + * submillisecond ticks. It's always possible to alias and + * produce a tdelta of "1", no matter how fast ticks are. + */ + if (expected_slice_max == expected_slice_min) { + expected_slice_max = expected_slice_min + 1; + } + while (1) { s64_t tdelta = k_uptime_delta(&elapsed_slice); TC_PRINT("%c", thread_parameter); From 074694c5a9b507da29a7cc185f9b0032aec5591e Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Wed, 12 Jun 2019 14:25:17 -0700 Subject: [PATCH 10/21] tests/kernel/common: Fix uptime delta test for fast ticks The test for the k_uptime_delta utilities was calling it in a loop and waiting for the uptime to advance. But the code was specifically wanting it to advance 5ms or more at one go, which clearly isn't going to work for a tick rate above 200 Hz. The weird thing is that the test knew this and even commented about the limitation. Which seems silly: it's perfectly fine for the clock to advance just a single millisecond. That's correct behavior too. Let's test for that, and it will work everywhere. Signed-off-by: Andy Ross --- tests/kernel/common/src/clock.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/tests/kernel/common/src/clock.c b/tests/kernel/common/src/clock.c index 762e0ef80f42..1101912dbaa0 100644 --- a/tests/kernel/common/src/clock.c +++ b/tests/kernel/common/src/clock.c @@ -61,8 +61,7 @@ void test_clock_uptime(void) /**TESTPOINT: uptime delta*/ d64 = k_uptime_delta(&d64); - /* Note: this will stall if the systick period < 5ms */ - while (k_uptime_delta(&d64) < 5) { + while (k_uptime_delta(&d64) == 0) { #if defined(CONFIG_ARCH_POSIX) k_busy_wait(50); #endif @@ -70,8 +69,7 @@ void test_clock_uptime(void) /**TESTPOINT: uptime delta lower 32-bit*/ k_uptime_delta_32(&d64); - /* Note: this will stall if the systick period < 5ms */ - while (k_uptime_delta_32(&d64) < 5) { + while (k_uptime_delta_32(&d64) == 0) { #if defined(CONFIG_ARCH_POSIX) k_busy_wait(50); #endif From f9182982f4421bf83137405cdbd2f420a8414472 Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Wed, 12 Jun 2019 14:33:40 -0700 Subject: [PATCH 11/21] tests/kernel/context: Fix sleep test for fast ticks The sleep test was checking that the sleep took no longer than "2 ticks" longer than requested. But "2 ticks" for fast tick rate configurations can be "zero ms", and for aliasing reasons it's always possible to delay for 1 unit more than requested (becuase you can cross a millisecond/tick/whatever boundary in your own code on either side of the sleep). So that "slop" value needs to be no less than 1ms. Signed-off-by: Andy Ross --- tests/kernel/context/src/main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tests/kernel/context/src/main.c b/tests/kernel/context/src/main.c index 50dea35246f1..25887ae96f6f 100644 --- a/tests/kernel/context/src/main.c +++ b/tests/kernel/context/src/main.c @@ -697,7 +697,9 @@ static void thread_sleep(void *delta, void *arg2, void *arg3) timestamp = k_uptime_get() - timestamp; TC_PRINT(" thread back from sleep\n"); - if (timestamp < timeout || timestamp > timeout + __ticks_to_ms(2)) { + int slop = MAX(__ticks_to_ms(2), 1); + + if (timestamp < timeout || timestamp > timeout + slop) { TC_ERROR("timestamp out of range, got %d\n", (int)timestamp); return; } From 13f7b2760eb711e4b3c1edcaa31e8faa9678b111 Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Wed, 12 Jun 2019 14:45:06 -0700 Subject: [PATCH 12/21] drivers/sensor/hp206c: Clarify tick rate warning The default tick rate is now 10 kHz, but that driver was demanding that it be exactly 1 kHz instead of at least that rate. I checked the source, and the driver isn't actually extracting "ticks" from the kernel illegally, it just needs fine-grained timers that work with the existing millisecond API. Let it build, this is fine. Signed-off-by: Andy Ross --- drivers/sensor/hp206c/hp206c.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/sensor/hp206c/hp206c.h b/drivers/sensor/hp206c/hp206c.h index 9d7c1259dff4..76502bee0e0b 100644 --- a/drivers/sensor/hp206c/hp206c.h +++ b/drivers/sensor/hp206c/hp206c.h @@ -74,7 +74,7 @@ struct hp206c_device_data { struct device *i2c; -#if CONFIG_SYS_CLOCK_TICKS_PER_SEC != 1000 +#if CONFIG_SYS_CLOCK_TICKS_PER_SEC < 1000 #error "driver needs millisecond tick granularity" #endif struct k_timer tmr; From 355200fc0d0da90789c65824be5389a8b2cab96b Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Sat, 15 Jun 2019 19:32:04 -0700 Subject: [PATCH 13/21] kernel/sched: Interpret zero timeslice time correctly The scheduler API has always allowed setting a zero slice size as a way to disable timeslicing. But the workaround introduced for CONFIG_SWAP_NONATOMIC forgot that convention, and was calling reset_time_slice() with that zero value (i.e. requesting an immediate interrupt) in circumstances where z_swap() had been interrupted nonatomically. In practice, this never happened. And if it did, it was a single spurious no-op interrupt that no one cared about. Until it did, anyway... Now that ticks on nRF devices are at full 32 kHz speed, we can get into a situation where the rapidly triggering timeslice interrupts are interrupting z_swap() calls, and the process feeds back on itself and becomes self-sustaining. Put that test into the time slice code itself to prevent this kind of mistake in the future. Signed-off-by: Andy Ross --- kernel/sched.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/kernel/sched.c b/kernel/sched.c index 49b78b4a995f..a7ebb68d3748 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -255,9 +255,10 @@ static void reset_time_slice(void) * slice count, as we'll see those "expired" ticks arrive in a * FUTURE z_time_slice() call. */ - _current_cpu->slice_ticks = slice_time + z_clock_elapsed(); - - z_set_timeout_expiry(slice_time, false); + if (slice_time != 0) { + _current_cpu->slice_ticks = slice_time + z_clock_elapsed(); + z_set_timeout_expiry(slice_time, false); + } } void k_sched_time_slice_set(s32_t slice, int prio) From c5044a134476bab439d0d681330d49bac9d5c029 Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Sat, 15 Jun 2019 20:35:14 -0700 Subject: [PATCH 14/21] tests/kernel/sleep: Fix usleep test for fast ticks The logic about minimal sleep sizes due to "tick" aliasing was correct, but drivers also have similar behavior with "cycle" aliasing too. When cycles are 3-4 orders of magnitude faster than ticks, it's undetectable noise. But now on nRF they're exactly the same and we need to correct for that, essentially doubling the number of ticks a usleep() might wait for. The logic here was simply too strict, basically. Fast tick rates can't guarantee what the test promised. Note that this relaxes the test bounds on the other side of the equation too: it's no longer an error to usleep() for only one tick (i.e. an improved sleep/timeout implementation no longer gets detected as a test failure). Signed-off-by: Andy Ross --- tests/kernel/sleep/src/usleep.c | 39 +++++++++++++++------------------ 1 file changed, 18 insertions(+), 21 deletions(-) diff --git a/tests/kernel/sleep/src/usleep.c b/tests/kernel/sleep/src/usleep.c index 7780ac6ded81..aca124c78da5 100644 --- a/tests/kernel/sleep/src/usleep.c +++ b/tests/kernel/sleep/src/usleep.c @@ -16,17 +16,23 @@ #define RETRIES 10 /* - * Theory of operation: we can't use absolute units (e.g., "sleep for 10us") - * in testing k_usleep() because the granularity of sleeps is highly dependent - * on the hardware's capabilities and kernel configuration. Instead, we - * test that k_usleep() actually sleeps for the minimum possible duration. - * (That minimum duration is presently two ticks; see below.) So, we loop - * k_usleep()ing for as many iterations as should comprise a second, and - * check to see that a total of one second has elapsed. + * Theory of operation: we can't use absolute units (e.g., "sleep for + * 10us") in testing k_usleep() because the granularity of sleeps is + * highly dependent on the hardware's capabilities and kernel + * configuration. Instead, we test that k_usleep() actually sleeps for + * the minimum possible duration. So, we loop k_usleep()ing for as + * many iterations as should comprise a second, and check to see that + * a total of one second has elapsed. */ -#define LOWER_BOUND_MS 900 /* +/- 10%, might be too lax */ -#define UPPER_BOUND_MS 1100 +#define LOOPS (CONFIG_SYS_CLOCK_TICKS_PER_SEC / 2) + +/* It should never iterate faster than the tick rate. It might be as + * much as 4x slower on drivers with fast tick rates (each of the app, + * sleep, timeout and cycle layers may need to align). + */ +#define LOWER_BOUND_MS ((1000 * LOOPS) / CONFIG_SYS_CLOCK_TICKS_PER_SEC) +#define UPPER_BOUND_MS ((4 * 1000 * LOOPS) / CONFIG_SYS_CLOCK_TICKS_PER_SEC) void test_usleep(void) { @@ -41,16 +47,7 @@ void test_usleep(void) ++retries; start_ms = k_uptime_get(); - for (i = 0; i < (CONFIG_SYS_CLOCK_TICKS_PER_SEC / 2); ++i) { - /* - * this will always sleep for TWO ticks: - * - * the conversion from 1us to ticks is rounded - * up to the nearest tick boundary, and sleeps - * always have _TICK_ALIGN (currently 1) added - * to their durations. - */ - + for (i = 0; i < LOOPS; ++i) { k_usleep(1); } @@ -60,12 +57,12 @@ void test_usleep(void) /* if at first you don't succeed, keep sucking. */ if ((elapsed_ms >= LOWER_BOUND_MS) && - (elapsed_ms < UPPER_BOUND_MS)) { + (elapsed_ms <= UPPER_BOUND_MS)) { break; } } printk("elapsed_ms = %lld\n", elapsed_ms); zassert_true(elapsed_ms >= LOWER_BOUND_MS, "short sleep"); - zassert_true(elapsed_ms < UPPER_BOUND_MS, "overslept"); + zassert_true(elapsed_ms <= UPPER_BOUND_MS, "overslept"); } From 6d3a8df53d3c50b6689e512cae02143df35b5561 Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Sat, 15 Jun 2019 20:43:28 -0700 Subject: [PATCH 15/21] tests/kernel/tickless/tickless_concept: Force 100 Hz ticks This test was written to assume ~100 Hz ticks in ways that are difficult to fix. It wants to sleep for periods on the order of the TICKLESS_IDLE_THRESH kconfig, which is extremely small on high tick rate systems and (on nRF in particular) does not have a cleanly divisible representation in milliseconds. Fixing precision issues by cranking the idle threshold up on a per-system basis seems like an abuse, as that is what we want to be testing in the first place. Just let the test run at the tick rate it has always expected. Signed-off-by: Andy Ross --- tests/kernel/tickless/tickless_concept/prj.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/kernel/tickless/tickless_concept/prj.conf b/tests/kernel/tickless/tickless_concept/prj.conf index 2905502ce96e..c1ad3543fdce 100644 --- a/tests/kernel/tickless/tickless_concept/prj.conf +++ b/tests/kernel/tickless/tickless_concept/prj.conf @@ -1,5 +1,5 @@ CONFIG_ZTEST=y CONFIG_SYS_POWER_MANAGEMENT=y CONFIG_TICKLESS_IDLE_THRESH=20 - CONFIG_SMP=n +CONFIG_SYS_CLOCK_TICKS_PER_SEC=100 From ab7179a94a4f31137ffba26bf3a0a67790a00cbf Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Sat, 15 Jun 2019 20:54:16 -0700 Subject: [PATCH 16/21] tests/kernel/early_sleep: Fix for fast ticks "50" ticks is fine with 100 Hz timer precision but way too short to survive the conversion to milliseconds on fast, non-decimal tick rates. Make it half a second, which was the original intent. Signed-off-by: Andy Ross --- tests/kernel/early_sleep/src/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/kernel/early_sleep/src/main.c b/tests/kernel/early_sleep/src/main.c index 7874ef7aeb9c..20d3ea10312c 100644 --- a/tests/kernel/early_sleep/src/main.c +++ b/tests/kernel/early_sleep/src/main.c @@ -33,7 +33,7 @@ #define THREAD_STACK (384 + CONFIG_TEST_EXTRA_STACKSIZE) -#define TEST_TICKS_TO_SLEEP 50 +#define TEST_TICKS_TO_SLEEP (CONFIG_SYS_CLOCK_TICKS_PER_SEC / 2) /* Helper thread data */ static K_THREAD_STACK_DEFINE(helper_tstack, THREAD_STACK); From 259512b5b28ee46a2c42a2596878180397567d1c Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Sat, 15 Jun 2019 21:57:42 -0700 Subject: [PATCH 17/21] tests/kernel/workq/work_queue: Fix for fast/non-standard tick rates This test was written to properly align its millisecond-measured wait time and assumed that there would be no other overhead. In fact on fast tick rate systems (or even ones where the alignment computation doesn't provide the needed padding as "slop") that's not quite enough time to complete the full test. There are cycles between the sleep calls that need to be accounted for, and aren't. Just give it one extra work item of time before failing. We aren't testing work queue timing precision here, just evaluation semantics. Signed-off-by: Andy Ross --- tests/kernel/workq/work_queue/src/main.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/tests/kernel/workq/work_queue/src/main.c b/tests/kernel/workq/work_queue/src/main.c index 77e44e85b59b..96f587d5d7f8 100644 --- a/tests/kernel/workq/work_queue/src/main.c +++ b/tests/kernel/workq/work_queue/src/main.c @@ -27,6 +27,11 @@ #define STACK_SIZE (1024 + CONFIG_TEST_EXTRA_STACKSIZE) +/* How long to wait for the full test suite to complete. Allow for a + * little slop + */ +#define CHECK_WAIT ((NUM_TEST_ITEMS + 1) * WORK_ITEM_WAIT_ALIGNED) + struct test_item { int key; struct k_delayed_work work; @@ -144,7 +149,7 @@ static void test_sequence(void) test_items_submit(); TC_PRINT(" - Waiting for work to finish\n"); - k_sleep(NUM_TEST_ITEMS * WORK_ITEM_WAIT_ALIGNED); + k_sleep(CHECK_WAIT); check_results(NUM_TEST_ITEMS); reset_results(); @@ -184,7 +189,7 @@ static void test_resubmit(void) k_work_submit(&tests[0].work.work); TC_PRINT(" - Waiting for work to finish\n"); - k_sleep(NUM_TEST_ITEMS * WORK_ITEM_WAIT_ALIGNED); + k_sleep(CHECK_WAIT); TC_PRINT(" - Checking results\n"); check_results(NUM_TEST_ITEMS); @@ -336,7 +341,7 @@ static void test_delayed_resubmit(void) k_delayed_work_submit(&tests[0].work, WORK_ITEM_WAIT); TC_PRINT(" - Waiting for work to finish\n"); - k_sleep(NUM_TEST_ITEMS * WORK_ITEM_WAIT_ALIGNED); + k_sleep(CHECK_WAIT); TC_PRINT(" - Checking results\n"); check_results(NUM_TEST_ITEMS); @@ -408,7 +413,7 @@ static void test_delayed(void) test_delayed_submit(); TC_PRINT(" - Waiting for delayed work to finish\n"); - k_sleep(NUM_TEST_ITEMS * WORK_ITEM_WAIT_ALIGNED); + k_sleep(CHECK_WAIT); TC_PRINT(" - Checking results\n"); check_results(NUM_TEST_ITEMS); From a33b6d804e62309ce27cd07bedbd0ecdbd792b71 Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Sat, 15 Jun 2019 22:19:49 -0700 Subject: [PATCH 18/21] tests/posix/common: Adjust miscalibrated timing test This test seems a little confused. It does a POSIX usleep() for 90ms, then checks the time taken, and verifies that it was no less than... 91ms! On existing platforms, tick alignment makes sure that we always take a little longer, so this passes. But on high tick rate configurations we get it exactly right. And fail. Adjust the calibration to allow (exactly) 90ms sleeps. Also fixed a comment that described the wrong units. Signed-off-by: Andy Ross --- tests/posix/common/src/clock.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/tests/posix/common/src/clock.c b/tests/posix/common/src/clock.c index 0e410ee47f7e..41109646544e 100644 --- a/tests/posix/common/src/clock.c +++ b/tests/posix/common/src/clock.c @@ -84,10 +84,10 @@ void test_posix_realtime(void) zassert_equal(ret, 0, "Fail to set realtime clock"); /* - * Loop for 20 10ths of a second, sleeping a little bit for - * each, making sure that the arithmetic roughly makes sense. - * This tries to catch all of the boundary conditions of the - * clock to make sure there are no errors in the arithmetic. + * Loop 20 times, sleeping a little bit for each, making sure + * that the arithmetic roughly makes sense. This tries to + * catch all of the boundary conditions of the clock to make + * sure there are no errors in the arithmetic. */ s64_t last_delta = 0; for (int i = 1; i <= 20; i++) { @@ -100,7 +100,7 @@ void test_posix_realtime(void) (s64_t)nts.tv_sec * NSEC_PER_SEC) + ((s64_t)rts.tv_nsec - (s64_t)nts.tv_nsec); - /* Make the delta 10ths of a second. */ + /* Make the delta milliseconds. */ delta /= (NSEC_PER_SEC / 1000U); zassert_true(delta > last_delta, "Clock moved backward"); @@ -108,9 +108,11 @@ void test_posix_realtime(void) /* printk("Delta %d: %lld\n", i, delta); */ - /* Allow for a little drift */ - zassert_true(error > 90, "Clock inaccurate"); - zassert_true(error < 110, "Clock inaccurate"); + /* Allow for a little drift upward, but not + * downward + */ + zassert_true(error >= 90, "Clock inaccurate %d", error); + zassert_true(error < 110, "Clock inaccurate %d", error); last_delta = delta; } From 8df996c191b4a2f94d550477ff5a871c9d96dba7 Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Sun, 16 Jun 2019 09:32:09 -0700 Subject: [PATCH 19/21] tests/cmsis_rtos_v1: Correct timing assumptions This test was written to assume that k_busy_wait() and CMSIS osKernelSysTick() (which is just k_cycle_get_32()) were perfectly synchronized. On nRF, they aren't (one is the 32 kHz RTC timer, the other is a calibrated spin loop using the CPU frequency). When ticks were being reported at 100 Hz granularity, there wasn't enough precision to detect the mismatch. Now there is. Rework the test to require that the clocks match to within 1%. Signed-off-by: Andy Ross --- tests/cmsis_rtos_v1/src/kernel_apis.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/tests/cmsis_rtos_v1/src/kernel_apis.c b/tests/cmsis_rtos_v1/src/kernel_apis.c index 7b48f6653b32..646c33929c3b 100644 --- a/tests/cmsis_rtos_v1/src/kernel_apis.c +++ b/tests/cmsis_rtos_v1/src/kernel_apis.c @@ -39,7 +39,7 @@ void test_kernel_start(void) */ void test_kernel_systick(void) { - u32_t start_time, stop_time, diff; + u32_t start_time, stop_time, diff, max, min; start_time = osKernelSysTick(); k_busy_wait(WAIT_TIME_US); @@ -48,5 +48,14 @@ void test_kernel_systick(void) diff = SYS_CLOCK_HW_CYCLES_TO_NS(stop_time - start_time) / NSEC_PER_USEC; - zassert_true(diff >= WAIT_TIME_US, NULL); + /* Check that it's within 1%. On some Zephyr platforms + * (e.g. nRF5x) the busy wait loop and the system timer are + * based on different mechanisms and may not align perfectly. + */ + max = WAIT_TIME_US + (WAIT_TIME_US / 100); + min = WAIT_TIME_US - (WAIT_TIME_US / 100); + + zassert_true(diff < max && diff > min, + "start %d stop %d (diff %d) wait %d\n", + start_time, stop_time, diff, WAIT_TIME_US); } From 4a212b7e47bfc7e168345cc6e39546e02e082bb4 Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Sun, 16 Jun 2019 14:50:32 -0700 Subject: [PATCH 20/21] CMSIS v2: Work around time unit confusion The current CMSIS v2 implementation is clearly assuming that timeout arguments being passed to e.g. osDelay() are in units of Zephyr ticks, not milliseconds as specified by ARM or (inconsistently) assumed by our test code. Most tests work with the ~100 Hz default tick rate, but they tend to fail on precision issues at higher tick rates. Force the CMSIS v2 applications to be 1000 Hz for now as a workaround, and detect the mismatch as a build failure. Signed-off-by: Andy Ross --- lib/cmsis_rtos_v2/kernel.c | 7 +++++++ samples/portability/cmsis_rtos_v2/philosophers/prj.conf | 1 + .../cmsis_rtos_v2/timer_synchronization/prj.conf | 3 +++ tests/cmsis_rtos_v2/prj.conf | 3 +++ 4 files changed, 14 insertions(+) diff --git a/lib/cmsis_rtos_v2/kernel.c b/lib/cmsis_rtos_v2/kernel.c index ffdaa6c99bf0..dad2b177f569 100644 --- a/lib/cmsis_rtos_v2/kernel.c +++ b/lib/cmsis_rtos_v2/kernel.c @@ -10,6 +10,13 @@ #include #include +/* Currently the timing implementations for timeouts and osDelay + * assume that the arguments are in Zephyr ticks, even though ARM + * documentation and at least some of our test code assume they are + * milliseconds. They must match for now. + */ +BUILD_ASSERT(CONFIG_SYS_CLOCK_TICKS_PER_SEC == 1000); + extern u32_t z_tick_get_32(void); /** diff --git a/samples/portability/cmsis_rtos_v2/philosophers/prj.conf b/samples/portability/cmsis_rtos_v2/philosophers/prj.conf index 700dfdc61a2d..7bf7415a2a66 100644 --- a/samples/portability/cmsis_rtos_v2/philosophers/prj.conf +++ b/samples/portability/cmsis_rtos_v2/philosophers/prj.conf @@ -9,3 +9,4 @@ CONFIG_THREAD_MONITOR=y CONFIG_INIT_STACKS=y CONFIG_POLL=y CONFIG_SCHED_SCALABLE=y +CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 diff --git a/samples/portability/cmsis_rtos_v2/timer_synchronization/prj.conf b/samples/portability/cmsis_rtos_v2/timer_synchronization/prj.conf index 2dd440581e3c..cd8feb23b3f9 100644 --- a/samples/portability/cmsis_rtos_v2/timer_synchronization/prj.conf +++ b/samples/portability/cmsis_rtos_v2/timer_synchronization/prj.conf @@ -10,3 +10,6 @@ CONFIG_INIT_STACKS=y CONFIG_POLL=y CONFIG_SCHED_SCALABLE=y CONFIG_SMP=n + +# The Zephyr CMSIS v2 emulation assumes that ticks are ms, currently +CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 diff --git a/tests/cmsis_rtos_v2/prj.conf b/tests/cmsis_rtos_v2/prj.conf index c90084c57444..ab8d18fcfd6e 100644 --- a/tests/cmsis_rtos_v2/prj.conf +++ b/tests/cmsis_rtos_v2/prj.conf @@ -13,3 +13,6 @@ CONFIG_SCHED_SCALABLE=y CONFIG_CMSIS_V2_MEM_SLAB_MAX_DYNAMIC_SIZE=128 CONFIG_CMSIS_V2_THREAD_MAX_COUNT=23 CONFIG_CMSIS_V2_THREAD_DYNAMIC_MAX_COUNT=10 + +# The Zephyr CMSIS emulation assumes that ticks are ms, currently +CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 From a256306da5be2af7204c3a708b4e327b105000dc Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Sun, 16 Jun 2019 17:23:25 -0700 Subject: [PATCH 21/21] kernel/mempool: Fix ticks/ms confusion The mempool blocking implementation was mixing tick and millisecond APIs. Get it right. Signed-off-by: Andy Ross --- kernel/mempool.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/kernel/mempool.c b/kernel/mempool.c index 35c42ddf14b3..08bc7650e0c2 100644 --- a/kernel/mempool.c +++ b/kernel/mempool.c @@ -55,7 +55,7 @@ int k_mem_pool_alloc(struct k_mem_pool *p, struct k_mem_block *block, __ASSERT(!(z_is_in_isr() && timeout != K_NO_WAIT), ""); if (timeout > 0) { - end = z_tick_get() + z_ms_to_ticks(timeout); + end = k_uptime_get() + timeout; } while (true) { @@ -93,9 +93,8 @@ int k_mem_pool_alloc(struct k_mem_pool *p, struct k_mem_block *block, z_pend_curr_unlocked(&p->wait_q, timeout); if (timeout != K_FOREVER) { - timeout = end - z_tick_get(); - - if (timeout < 0) { + timeout = end - k_uptime_get(); + if (timeout <= 0) { break; } }