Use Devicetree to describe the radio and IEEE 802.15.4. This allows to
remove usage of IEEE802154_CC13XX_CC26XX_DRV_NAME in preparation for the
removal of NET_CONFIG_IEEE802154_DEV_NAME. All boards used in testing
have been updated to enable the peripheral in DT as well.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add boolean properties to the binding for the nRF RADIO peripheral
to indicate whether the following features are supported:
- IEEE 802.15.4 mode
- 2 Mbps BLE mode
- coded BLE PHY
- high TX power settings
Set these properties appropriately in devicetree radio nodes for all
nRF SoCs.
Add also such properties and set them in appropriate nodes for nRF
flash controllers to indicate whether they support partial erase.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Add missing devicetree nodes representing the following peripherals
in nRF SoCs:
- ACL
- BPROT
- CCM
- COMP/LPCOMP
- CTRLAP
- DCNF
- MPU (nRF MPU peripheral in nRF51 Series, not ARM MPU)
- MUTEX
- MWU
- NFCT
- OSCILLATORS
- POWER (in nRF51 and nRF52 Series)
- PPI
- RESET
- SWI
- USBREG
Add also corresponding bindings and validation of base addresses of
these nodes.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This will be used to take a phandle to a FEM device, either a generic
two pin device or an nRF21540. Keep the nRF21540 binding example up to
date.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The way the nRF21540 device is configured makes sense once you
understand it, but it's quite unusual: a single peripheral is
configured with two separate devicetree nodes linked by a phandle.
Since this risks entering "exploding head" territory for beginners, it
deserves a thorough example. Add one to the binding's description.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is a helper binding for radio front-end modules that have a
two-pin control interface, where one pin is used to turn on an power
amplifier (PA) for TX, and another is used to turn on a low-noise
amplifier (LNA) for RX.
Such hardware is already supported by the Bluetooth subsystem, but via
PA/LNA Kconfig settings. Since this is hardware configuration, it is
better to move this to devicetree instead.
Add a binding that makes it possible to define nodes which contain the
same information, along with a bit of extra information related to the
gain in dB of each amplifier not currently available from Kconfig.
This is similar to the existing binding for the nordic,nrf21540-fem
compatible.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>
This is to support upcoming external radio coexistence implementations,
see binding documentation for more info.
Signed-off-by: Jonathan Rico <jonathan.rico@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>
Clean up multi-line strings so they will show up properly in the
bindings index in the HTML documentation.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Change dfe-ant-num propert name to dfe-antenna-num.
The change is conde to keep the same naming style
for all properies, like dfe-pdu-antenna property.
Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no>
Add initialization of GPIOs that are used for antenna switching.
GPIOs provided to DFE extension in Radio peripheral, to drive
antenna switching, should be initialized in GPIO peripheral beforehand.
The initialization is optional and may be disabled by Kconfig.
Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no>
Add radio peripheral to nrf52833 DTS including antenna matrix
congiuration for Direction Finding extennsion.
Add appropriate binding file for nRF radio peripheral.
There is no default antenna matrix configuration. Antennas number
and GPIOS mapping to DFEGPIOS is project specific.
Complete configuration must be provided by end user as overaly.
Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no>
Apart from the previously added pins, nRF21540's GPIO interface includes
also MODE pin. This commit adds it to the relevant binding.
Signed-off-by: Jedrzej Ciupis <jedrzej.ciupis@nordicsemi.no>
The nRF21540 radio front-end-module can optionally be controlled by a
SPI interface. Add a binding and property to link the SPI bus
configuration data to the FEM node.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
This device is not an ARM MCU, it's a radio front-end module. Based
on existing Linux practice it belongs in net/wireless.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
