Adds few missing zephyr/ prefixes to leftover #include statements that
either got added recently or were using double quote format.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
In order to bring consistency in-tree, migrate all boards code to the
new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
switch all in tree usage of zephyr,mmc-spi-slot to zephyr,sdhc-spi-slot.
This will change all boards to use the new SD subsystem instead of the
SDMMC SPI driver
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Fix spelling errors in assorted .rst files. The errors were found
using a tool called 'codespell'.
Signed-off-by: Aleksandar Markovic <aleksandar.markovic.sa@gmail.com>
Allow shield to be used with any board that has an
arduino nano connector.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@huawei.com>
This maps the Arduino Rev3 header's pins expected by the shield overlay
to the real Arduino Nano header pins of the Arduino Nano 33 BLE board and
aliases the I2C and SPI interfaces accordingly.
Fixes: #43927
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@huawei.com>
This update Atmel sam serial drivers to use pinctrl driver and API. It
updates all boards with new pinctrl groups format.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
The driver is already enabled when turning CONFIG_DISPLAY on and
enabling the display node in Devicetree.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This adds an overlay defining a dummy arduino_header with three pins
required by the adafruit 2.8 TFT display to work on arduino_nano_33_ble.
While the nano form factor doesn't really have a proper Rev3 header, this
allows to connect the display to the nano pins and make the display work.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@huawei.com>
The Keyestudio CAN-BUS Shield (KS0411) is equipped with a Microchip
MCP2551 CAN transceiver with a maximum bitrate of 1Mbit/s.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The DFRobot CAN BUS Shield V2.0 is equipped with a NXP TJA1050 CAN
transceiver with a maximum bitrate of 1Mbit/s.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
In upstream the LV_COLOR_DEPTH_BITS option is called LV_COLOR_DEPTH, this
needs changing if we want to support v8.2.0.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
We're now using the Kconfig copied from the upstream lvgl repository. It
uses the LV_ prefix for all options while we're using LVGL_ for
Zephyr-specific ones. Make the latter consistent with upstream but also
make sure they're distinct from lvgl's by using LV_Z_ as the prefix.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@huawei.com>
Start using the upstream Kconfig from LVGL and move the glue code out
of the zephyr tree and put it under lvgl/zephyr/ in modules.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@huawei.com>
Add support for the Keyestudio CAN-BUS shield (KS0411). This shield is
very similar to the DFRobot CAN-BUS shield v2.0.
Rename the MCP2515 devicetree nodes in order not to conflict with
on-chip CAN controllers and switch to specifying the sample point
instead of time quantas.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Kconfig entries used for changing an option default value should not
re-define the option prompt. We should probably introduce a check for
that (any option has a single prompt and help).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Remove the requirement for specifying #address-cells and #size-cells
properties for CAN controller devicetree nodes.
CAN controllers do not have a common concept of devicetree child nodes
and thus have no need for these properties. This is in line with
upstream Linux kernel devicetree bindings.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove options LVGL_HOR_RES_MAX and LVGL_VER_RES_MAX.
Keep the options for mimxrt10xx_evk boards as they
cannot yet be obtained there from devicetree.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Remove Kconfig option LVGL_DISPLAY_DEV_NAME.
Also remove it from mimxrt10xx_evk boards to have consistent
configuration, even if they do not benefit from it that much.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Include common display controller bindings.
Add required height and width properties to "ilitek,ili9340"
and "ilitek,ili9488" users.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Refactors all of the on-chip GPIO drivers to use a shared driver class
initialization priority configuration, CONFIG_GPIO_INIT_PRIORITY, to
allow configuring GPIO drivers separately from other devices. This is
similar to other driver classes like I2C and SPI.
Most drivers previously used CONFIG_KERNEL_INIT_PRIORITY_DEFAULT or
CONFIG_KERNEL_INIT_PRIORITY_DEVICE, therefore the default for this new
option is the lower of the two, which means earlier initialization.
Driver-specific options for off-chip I2C- or SPI-based GPIO drivers are
left intact because they often need to be initialized at a different
priority than on-chip GPIO drivers.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
Rename the Zephyr chosen property for specifying the default CAN bus
controller from "zephyr,can-primary" to "zephyr,canbus".
The "zephyr,can-primary" property name was selected in antipation of
adding support for redundant CAN networks, which we have yet to
add. Meanwhile, the "primary" term causes confusion for non-redundant
CAN bus configurations (and the "can" term doesn't match the name of the
Zephyr CAN bus subsystem).
The CAN in Automation (CiA) 302-6, which deals with CANopen network
redundancy, uses the terms "default interface" and "redundant
interface". If/when we add support for redundant CAN networks, the
"zephyr,canbus" chosen property can be supplemented with a
"zephyr,canbus-redundant" chosen property.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Refactors all of the EEPROM drivers to use a shared driver class
initialization priority configuration, CONFIG_EEPROM_INIT_PRIORITY, to
allow configuring EEPROM drivers separately from other devices. This is
similar to other driver classes like I2C and SPI.
The default is set to CONFIG_KERNEL_INIT_PRIORITY_DEVICE to preserve the
existing default initialization priority for most drivers. The
exceptions are at2x and emul drivers which have dependencies on SPI,
I2C, or flash drivers and must therefore initialize later than the
default device priority.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
Refactors all of the DAC drivers to use a shared driver class
initialization priority configuration, CONFIG_DAC_INIT_PRIORITY, to
allow configuring DAC drivers separately from other devices. This is
similar to other driver classes like I2C and SPI.
The default is set to CONFIG_KERNEL_INIT_PRIORITY_DEVICE to preserve the
existing default initialization priority for most drivers. The
exceptions are dacx0508, dacx3608, and mcp4725 drivers which have
dependencies on SPI or I2C drivers and must therefore initialize later
than the default device priority.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
Refactors all of the CAN drivers to use a shared driver class
initialization priority configuration, CONFIG_CAN_INIT_PRIORITY, to
allow configuring CAN drivers separately from other devices. This is
similar to other driver classes like I2C and SPI.
The default is set to CONFIG_KERNEL_INIT_PRIORITY_DEVICE to preserve the
existing default initialization priority for most drivers. The exception
is the mcp2515 driver which has a dependency on a SPI driver and must
therefore initialize later than the default device priority.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
Refactors all of the ADC drivers to use a shared driver class
initialization priority configuration, CONFIG_ADC_INIT_PRIORITY, to
allow configuring ADC drivers separately from other devices. This is
similar to other driver classes like I2C and SPI.
The default is set to CONFIG_KERNEL_INIT_PRIORITY_DEVICE to preserve the
existing default initialization priority for most drivers. The
exceptions are lmp90xxx, mcp320x, and mcux_adc16 drivers which have
dependencies on GPIO, SPI, and/or DMA drivers and must therefore
initialize later than the default device priority.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
Remove Kconfig options for enabling device instances in favor of
taking that information only from device tree. Prior to that
change there was a mix of devicetree and Kconfig.
Bring back use of CONFIG_GPIO_NRF_INIT_PRIORITY.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
It should be "u-blox,sara-r4", because the vendor prefix for this
company is "u-blox", not "ublox".
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Standard Arduino CLK signal is on D13,
nucleo_l476rg board has been modified accordingly.
Need an overlay to use default x_nucleo_idb05a1 spin D3 (PB3)
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
This shield is working out of the box on Arduino connector,
even if it is not with all standard Arduino SPI CS/CLK pins.
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
There are a number of platforms that the x_nucleo_eeprma2 eeprom sample
can't build on. Also fix issue with missing include of <mem.h> header
to get DT_SIZE_* macros used by the overlay.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
This commit adds st microelectronics x-nucleo-eeprma2 shield,
which has populated 6 different i2c and spi eeproms.
They are all compatible with the existing at24 and at25 drivers.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
File prj.mcp2515.conf was previously removed from project as it was
made redundant.
Paths containing uppercase CAN were changed to lowercase.
Signed-off-by: Nick Ward <nick.ward@setec.com.au>
Rename the NXP LPCXpresso55S16 board definition from
lpcxpresso55s16_ns (non-secure) to lpcxpresso55s16 and remove TF-M
configuration options.
While the LPC55S16 does have Arm TrustZone support, there is no TF-M
support available upstream yet.
Fixes#35100
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Recently WiFi ESP32 driver (utilizing WiFi radio in ESP32 SoC) was
introduced into drivers/wifi/esp32/ and it already caused confusion as
there was existing drivers/wifi/esp/ directory for ESP-AT
driver (utilizing external WiFi chip, by communicating using AT commands
from any serial capable platform). So question has arisen whether it is
good to merge both, while they are totally different drivers.
Rename ESP-AT driver to be placed in drivers/wifi/esp_at/, so that it is
easier to figure out difference between "esp32" and "esp_at" just by
looking at driver name. Rename also DT compatible and all Kconfig
options for the same reason.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
This very first version supports the 160x128 pixels adafruit TFT display
Signed-off-by: Kim Bøndergaard <kim@fam-boendergaard.dk>
Signed-off-by: Kim Bøndergaard <kibo@prevas.dk>
Take the int-pin information (i.e. what pin between INT1
and INT2 the drdy is attached to) directly from DT.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
