zephyr/drivers/can/Kconfig
Andy Ross 7832738ae9 kernel/timeout: Make timeout arguments an opaque type
Add a k_timeout_t type, and use it everywhere that kernel API
functions were accepting a millisecond timeout argument.  Instead of
forcing milliseconds everywhere (which are often not integrally
representable as system ticks), do the conversion to ticks at the
point where the timeout is created.  This avoids an extra unit
conversion in some application code, and allows us to express the
timeout in units other than milliseconds to achieve greater precision.

The existing K_MSEC() et. al. macros now return initializers for a
k_timeout_t.

The K_NO_WAIT and K_FOREVER constants have now become k_timeout_t
values, which means they cannot be operated on as integers.
Applications which have their own APIs that need to inspect these
vs. user-provided timeouts can now use a K_TIMEOUT_EQ() predicate to
test for equality.

Timer drivers, which receive an integer tick count in ther
z_clock_set_timeout() functions, now use the integer-valued
K_TICKS_FOREVER constant instead of K_FOREVER.

For the initial release, to preserve source compatibility, a
CONFIG_LEGACY_TIMEOUT_API kconfig is provided.  When true, the
k_timeout_t will remain a compatible 32 bit value that will work with
any legacy Zephyr application.

Some subsystems present timeout (or timeout-like) values to their own
users as APIs that would re-use the kernel's own constants and
conventions.  These will require some minor design work to adapt to
the new scheme (in most cases just using k_timeout_t directly in their
own API), and they have not been changed in this patch, instead
selecting CONFIG_LEGACY_TIMEOUT_API via kconfig.  These subsystems
include: CAN Bus, the Microbit display driver, I2S, LoRa modem
drivers, the UART Async API, Video hardware drivers, the console
subsystem, and the network buffer abstraction.

k_sleep() now takes a k_timeout_t argument, with a k_msleep() variant
provided that works identically to the original API.

Most of the changes here are just type/configuration management and
documentation, but there are logic changes in mempool, where a loop
that used a timeout numerically has been reworked using a new
z_timeout_end_calc() predicate.  Also in queue.c, a (when POLL was
enabled) a similar loop was needlessly used to try to retry the
k_poll() call after a spurious failure.  But k_poll() does not fail
spuriously, so the loop was removed.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2020-03-31 19:40:47 -04:00

84 lines
2.0 KiB
Plaintext

# CAN configuration options
# Copyright (c) 2018 Alexander Wachter
# SPDX-License-Identifier: Apache-2.0
#
# CAN options
#
menuconfig CAN
bool "CAN Drivers"
select LEGACY_TIMEOUT_API
help
Enable CAN Driver Configuration
if CAN
module = CAN
module-str = CAN
source "subsys/logging/Kconfig.template.log_config"
config CAN_SHELL
bool "Enable CAN Shell"
depends on SHELL
help
Enable CAN Shell for testing.
config CAN_INIT_PRIORITY
int "CAN driver init priority"
default 80
help
CAN device driver initialization priority.
Do not mess with it unless you know what you are doing.
Note that the priority needs to be lower than the net stack
so that it can start before the networking sub-system.
config CAN_WORKQ_FRAMES_BUF_CNT
int "Work queue buffer frame count"
default 4
range 1 65534
help
Number of frames in the buffer of a zcan_work.
config CAN_RX_TIMESTAMP
bool "Enable receiving timestamps"
depends on CAN_STM32 || CAN_MCUX_FLEXCAN
help
This option enables a timestamp value of the CAN free running timer.
The value is incremented every bit time and starts when the controller
is initialized.
config CAN_AUTO_BUS_OFF_RECOVERY
bool "Enable automatic recovery from bus-off"
default y
help
This option enables the automatic bus-off recovery according to
ISO 11898-1 (recovery after 128 occurrences of 11 consecutive
recessive bits). When this option is enabled, the recovery API is not
available.
config CAN_0
bool "Enable CAN 0"
help
Enable CAN controller 0
config CAN_1
bool "Enable CAN 1"
help
Enable CAN controller 1
config CAN_2
bool "Enable CAN 2"
depends on SOC_SERIES_STM32F4X
help
Enable CAN controller 2 on the STM32F4 series of processors.
(Tested on the STM32F4 series, may also work on F7, F1, F2 and L4)
source "drivers/can/Kconfig.stm32"
source "drivers/can/Kconfig.mcux"
source "drivers/can/Kconfig.mcp2515"
source "drivers/can/Kconfig.loopback"
source "drivers/can/Kconfig.net"
endif # CAN