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 <andrew.j.ross@intel.com>
This commit is contained in:
Andy Ross 2019-06-11 11:18:20 -07:00 committed by Anas Nashif
commit 669730f030
3 changed files with 11 additions and 9 deletions

View file

@ -1684,8 +1684,7 @@ static inline void *z_impl_k_timer_user_data_get(struct k_timer *timer)
* @rst * @rst
* While this function returns time in milliseconds, it does * While this function returns time in milliseconds, it does
* not mean it has millisecond resolution. The actual resolution depends on * not mean it has millisecond resolution. The actual resolution depends on
* :option:`CONFIG_SYS_CLOCK_TICKS_PER_SEC` config option, and with the * :option:`CONFIG_SYS_CLOCK_TICKS_PER_SEC` config option.
* default setting of 100, system time is updated in increments of 10ms.
* @endrst * @endrst
* *
* @return Current uptime in milliseconds. * @return Current uptime in milliseconds.
@ -1741,8 +1740,7 @@ __deprecated static inline void k_disable_sys_clock_always_on(void)
* @rst * @rst
* While this function returns time in milliseconds, it does * While this function returns time in milliseconds, it does
* not mean it has millisecond resolution. The actual resolution depends on * not mean it has millisecond resolution. The actual resolution depends on
* :option:`CONFIG_SYS_CLOCK_TICKS_PER_SEC` config option, and with the * :option:`CONFIG_SYS_CLOCK_TICKS_PER_SEC` config option
* default setting of 100, system time is updated in increments of 10ms.
* @endrst * @endrst
* *
* @return Current uptime in milliseconds. * @return Current uptime in milliseconds.

View file

@ -529,9 +529,11 @@ config ARCH_HAS_CUSTOM_BUSY_WAIT
config SYS_CLOCK_TICKS_PER_SEC config SYS_CLOCK_TICKS_PER_SEC
int "System tick frequency (in ticks/second)" int "System tick frequency (in ticks/second)"
default 100 if QEMU_TARGET || SOC_POSIX
default 10000 if TICKLESS_CAPABLE
default 100 default 100
help 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 Depending on the choice made, an amount of possibly expensive math must
occur when converting ticks to milliseconds and vice-versa. Some values 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. and the user should generally avoid modifying it via the menu configuration.
config SYS_CLOCK_EXISTS config SYS_CLOCK_EXISTS
def_bool (SYS_CLOCK_TICKS_PER_SEC != 0) bool "System clock exists and is enabled"
# omit prompt to signify a "hidden" option default y
help help
This option specifies that the kernel lacks timer support. 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 config XIP
bool "Execute in place" bool "Execute in place"

View file

@ -1,3 +1,2 @@
# No timer support in the kernel # No timer support in the kernel
CONFIG_SYS_CLOCK_EXISTS=n
CONFIG_SYS_CLOCK_TICKS_PER_SEC=0