Add missing EGU and TIMER nodes. We already have compatibles for these
defined, and the peripherals are present, so define them for
consistency across SoCs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add missing RADIO and EGU nodes. We already have compatibles for these
defined, and the peripherals are present, so define them for
consistency across SoCs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add missing RADIO and EGU nodes. We already have compatibles for these
defined, and the peripherals are present, so define them for
consistency across SoCs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add missing FICR, UICR, RADIO, and EGU nodes. We already have
compatibles for these defined, and the peripherals are present, so
define them for consistency across SoCs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add missing FICR, UICR, RADIO nodes. We already have compatibles for
these defined, and the peripherals are present, so define them for
consistency across SoCs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The way we currently handle direction finding extension (DFE) support
on Nordic nRF5 controllers relies on required devicetree properties
related to DFE in the "nordic,nrf-radio" node.
That doesn't make sense on radios without DFE support, though.
Any .dtsi for an SoC without DFE support which has such a node would
require extraneous DFE related properties like dfe-antenna-num.
Instead of making the properties required, mark them optional. We
indicate the presence of DFE support via a new 'dfe-supported' boolean
property which the SoC .dtsi files can set (or not) depending on
support.
This gives us the opportunity to do some cleanup in the Kconfig,
removing CONFIG_HAS_HW_NRF_RADIO_BLE_DF since we know from the
devicetree whether DFE support is available.
Handle that change appropriately in radio_df.c. This gives us an
opportunity to improve readability in the devicetree-related macro
magic in that file.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The documentation for Bluetooth Direction Finding Extension (DFE)
samples has various issues:
- references to 'child' images, which do not exist in mainline zephyr
- invalid RST syntax: there are missing ` characters to end arguments
to :zephyr_file: roles, creating unintelligible output
- incorrect RST usage:
- using :zephyr_file: instead of :file: when referring to a file
that the user must create, creating broken links to nonexistent
files in the zephyr tree
- using :code: instead of :kconfig: to refer to kconfig options,
creating output without links to the help for those options
- redundant or duplicated information
- grammar, typos, various bits and pieces
Clean this up. As part of that, move various common bits and pieces of
information to the devicetree bindings index so they can just be
linked to from the sample docs.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no>
Sort by unit address. This involves multiple files since there are
includes and secure/non-secure files to deal with.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This has an unrecognized vendor prefix which does not seem to serve
any purpose. Removing it is a way forward to turning warnings into
errors on unrecognized vendor prefixes.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The Linux vendor prefixes list uses 'cdns'. Match it, especially since
we have that prefix in our own list as well.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
These IP blocks' vendor is Cadence, whose proper vendor prefix is
'cdns' if we are going to match the Linux vendor prefixes list.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
As far as I can tell, 'vexriscv' does not name a vendor:
https://github.com/SpinalHDL/VexRiscv
It also doesn't seem entrenched enough to merit a special case
exception to the de factor rule 'the "vnd,foo" namespace is for
vendors'. This is open to debate and we can revise as needed in the
future, but for now let's just rename the compatible to avoid
triggering warnings/errors about unknown vendors.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The original NIOS-II developer and former vendor is Altera, which is
now part of Intel. Let's not add a new vendor prefix for something
that already exists and has been acquired; move it to use the existing
'altr,' prefix instead.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Rename:
- grove,light to seeed,grove-light
- grove,temperature to seeed,grove-temperature
The "grove" brand applies to a family of products by Seeed (sic):
https://www.seeedstudio.com/category/Grove-c-1003.html
Therefore we should use the existing vendor seeed.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
I can't find any reference anywhere showing that the manufacturer of
the LPD8803 or LPD8806 LED scripts is a company called 'colorway'.
Use 'greeled' instead; these seem to actually be manufactured by
GreeLed corporation.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
It should be "maxim,max30101", because the vendor prefix for this
company is "maxim", not "max".
Signed-off-by: Martí Bolívar <marti.bolivar@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>
We have a ftdi,ft800 binding, and it's easy to imagine additional
bindings coming in the future since their USB/UART chips are very
commonly used.
I didn't find anything in Linux for this vendor.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is used for microbit,edge-connector. I couldn't find anything in
Linux, which is not surprising given these boards have constrained
Cortex-M chips.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We have various compatibles matching this in a DTSI file.
Linux tracks this vendor too:
4071883fd8
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We have a binding for apa,apa102 in zephyr.
I can't find any bindings for this vendor in Linux.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We have a binding for compatible "quectel,bg9x".
I can't find any bindings for this vendor in Linux.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We have a binding for wiznet,w5500 in zephyr.
Linux has a binding for this device, too:
d5ad8ec3cf/Documentation/devicetree/bindings/net/wiznet,w5x00.txt
But 'wiznet' is not present in the Linux vendor prefixes file for some
reason.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This PR will change accessing the related pinctrl macro from soc_dt.h
And the pinctrl of SCL and SDA were got from pinctrl-0 and pinctrl-1,
respectively. Change it to get from pinctrl-0 only.
Signed-off-by: Tim Lin <tim2.lin@ite.corp-partner.google.com>
This adds the driver for Omnivision OV2640 image sensor.
The driver provides support for 10 different resolutions in range from
160x120 to 1600x1200 in both JPEG and RGB565 pixel formats. There are
also mutliple configuration options, e.g. hflip, vflip, saturation and
brightness control.
Signed-off-by: Robert Szczepanski <rszczepanski@antmicro.com>
Add sifive-e24 cpu binding. This introduce riscv,cpu binding to
be used as riscv cpu base and riscv,sifive, which define specific
properties for this vendor. Both are necessary to create the e24
core.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
Add missing dts binding for sensor, this was causing build errors with
CONFIG_PM set on bt510/bt6x0 boards.
Fixes#37675
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
