doc: s/device tree/devicetree/

DTSpec writes this as a single word, presumably to make it easier to
grep for / more precise. Follow along in the rest of the docs now that
our main DT docs page agrees with this usage.

Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>

boards/arm/96b_avenger96/doc/index.rst

@@ -195,7 +195,7 @@ Serial Port
 by default to the RAM console to be dumped by the Linux Remoteproc Framework
 on Cortex®-A7 core. Alternatively, Zephyr console output can be assigned to
 UART7 which is disabled by default. UART console can be enabled through
-board's device tree and 96b_avenger96_defconfig board file (or prj.conf
+board's devicetree and 96b_avenger96_defconfig board file (or prj.conf
 project files), and will disable existing RAM console output. Default UART
 console settings are 115200 8N1.
 

boards/arm/nrf52840_pca10056/doc/index.rst

@@ -172,7 +172,7 @@ Using UART1
 The following approach can be used when an application needs to use
 more than one UART for connecting peripheral devices:
 
-1. Add device tree overlay file to the main directory of your application:
+1. Add devicetree overlay file to the main directory of your application:
 
    .. code-block:: console
 
@@ -195,8 +195,9 @@ more than one UART for connecting peripheral devices:
 
 Overlay file naming
 ===================
+
 The file has to be named ``<board>.overlay`` and placed in the app main directory to be
-picked up automatically by the device tree compiler.
+picked up automatically by the build system.
 
 Selecting the pins
 ==================
@@ -211,7 +212,7 @@ In the table 7.1.1 'aQFN73 ball assignments' select the pins marked
 'General purpose I/O'.  Note that pins marked as 'low frequency I/O only' can only be used
 in under-10KHz applications. They are not suitable for 115200 speed of UART.
 
-Translate 'Pin' into number for Device tree by using the following formula::
+Translate the 'Pin' into number for devicetree by using the following formula::
 
    pin_no = b\*32 + a
 

boards/arm/nucleo_f429zi/doc/index.rst

@@ -187,8 +187,8 @@ Flash partitions for MCUBoot bootloader
 
 The on-board STM32F429ZI MCU has 2MBs of internal flash memory. To use `MCUboot`_,
 define a :ref:`Zephyr partition table <flash_partitions>` for the flash memory in
-its device tree file ``nucleo_f429zi.dts``. As a reference, a partition table for
+its devicetree file ``nucleo_f429zi.dts``. As a reference, a partition table for
-MCUBoot is already defined in the device tree file, with these settings:
+MCUBoot is already defined in the devicetree file, with these settings:
 
 - `MCUBoot`_ bootloader partition takes 64K bytes.
 - Zephyr settings partition takes 64K bytes.

boards/arm/stm32h747i_disco/doc/index.rst

@@ -119,7 +119,7 @@ two cores. This is done in 3 ways:
 - **Compilation**: Clock configuration is only accessible to M7 core. M4 core only
   has access to bus clock activation and deactivation.
 - **Static pre-compilation assignment**: Peripherals such as a UART are assigned in
-  device tree before compilation. The user must ensure peripherals are not assigned
+  devicetree before compilation. The user must ensure peripherals are not assigned
   to both cores at the same time.
 - **Run time protection**: Interrupt-controller and GPIO configurations could be
   accessed by both cores at run time. Accesses are protected by a hardware semaphore

boards/arm/stm32mp157c_dk2/doc/stm32mp157_dk2.rst

@@ -214,7 +214,7 @@ The Zephyr console output is assigned by default to the RAM console to be dumped
 by the Linux Remoteproc Framework on Cortex®-A7 core. In order to keep the UART7
 free for future serial interactions with Arduino shield, the Zephyr UART console
 output is USART3 and is disabled by default. UART console can be enable through
-board's device tree and stm32mp157c_dk2_defconfig board file (or prj.conf
+board's devicetree and stm32mp157c_dk2_defconfig board file (or prj.conf
 project files), and will disable existing RAM console output. Default UART
 console settings are 115200 8N1.
 

boards/arm/twr_ke18f/doc/index.rst

@@ -111,7 +111,7 @@ accelerometer and magnetometer for sensor values
 
 In order to support FXOS8700 triggers (interrupts) the 0 ohm resistors
 ``R47`` and and ``R57`` must be mounted on the TWR-KE18F board. The
-device tree must also be modified to describe the FXOS8700 interrupt
+devicetree must also be modified to describe the FXOS8700 interrupt
 GPIOs:
 
 .. code-block:: none

boards/posix/native_posix/doc/index.rst

@@ -540,7 +540,7 @@ The following peripherals are currently provided with this board:
   on the host file system.
 
   The size of the flash device can be configured through the native POSIX board
-  device tree and the sector size is configurable via the Kconfig option
+  devicetree and the sector size is configurable via the Kconfig option
   :option:`CONFIG_FLASH_NATIVE_POSIX_SECTOR_SIZE`. The sector size will only be
   used to return flash page layout related information and no restrictions are
   imposed by the driver based on the configured sector size. As such an erase
@@ -552,7 +552,7 @@ The following peripherals are currently provided with this board:
   By default the binary data is located in the file *flash.bin* in the current
   working directory. The location of this file can be changed through the
   command line parameter *--flash*. The flash data will be stored in raw format
-  and the file will be truncated to match the size specified in the device tree
+  and the file will be truncated to match the size specified in the devicetree
   configuration. In case the file does not exists the driver will take care of
   creating the file, else the existing file is used.
 

doc/application/index.rst

@@ -118,9 +118,8 @@ subdirectories which are not described here.
     Device driver code.
 
 :file:`dts`
-    Device tree source (.dts) files used to describe non-discoverable
+    :ref:`device-tree` source files used to describe non-discoverable
-    board-specific hardware details previously hard coded in the OS
+    board-specific hardware details.
-    source code.
 
 :file:`ext`
     Externally created code that has been integrated into Zephyr
@@ -232,11 +231,8 @@ Follow these steps to create a new application directory. (Refer to
    are interested in.  See :ref:`application_kconfig` for more details, and
    :ref:`configuration_options` for a complete list of available options.
 
-#. Optionally, you can also configure any Device Tree overlays needed by your
+#. Optionally, you can also configure any devicetree overlays needed by your
-   application. Zephyr uses the same Device Tree system as the Linux kernel,
+   application. See :ref:`application_dt` below for details.
-   but with its own definitions.
-
-   This is usually not necessary; see :ref:`application_dt` below for details.
 
 .. _important-build-vars:
 
@@ -276,10 +272,10 @@ should know about.
   semicolons. Each file includes Kconfig configuration values that override
   the default configuration values.
 
-* :makevar:`DTC_OVERLAY_FILE`: Indicates the name of one or more Device Tree
+* :makevar:`DTC_OVERLAY_FILE`: Indicates the name of one or more devicetree
   overlay files. Multiple filenames can be separated with either spaces or
-  semicolons. Each file includes Device Tree values that override the default
+  semicolons. Each file includes devicetree values that override the default
-  DT values. See :ref:`application_dt` below for details on device tree
+  DT values. See :ref:`application_dt` below for details on devicetree
   overlays, and :ref:`device-tree` for an overview on devicetree and Zephyr.
 
 * :makevar:`ZEPHYR_MODULES`: A CMake list containing absolute paths of
@@ -1093,7 +1089,7 @@ Make sure to follow these steps in order.
 
    More details are available below in :ref:`application_kconfig`.
 
-#. If your application uses a Device Tree overlay file or files other than
+#. If your application uses a devicetree overlay file or files other than
    the usual :file:`<board>.overlay`, add lines setting the
    :makevar:`DTC_OVERLAY_FILE` variable to these files appropriately.
 
@@ -1490,33 +1486,33 @@ docstrings at the top of ``scripts/kconfig/menuconfig.py`` and
 
 .. _application_dt:
 
-Device Tree Overlays
+Devicetree Overlays
-====================
+===================
 
-As described in :ref:`device-tree`, Zephyr uses Device Tree to describe the
+As described in :ref:`device-tree`, Zephyr uses devicetree to describe the
 hardware it runs on. This section describes how you can modify an application
-build's device tree using overlay files. For additional information regarding
+build's devicetree using overlay files. For additional information regarding
-the relationship between Device Tree and Kconfig see :ref:`dt_vs_kconfig`. For
+the relationship between devicetree and Kconfig see :ref:`dt_vs_kconfig`. For
 an example of how to use custom overlays with ``west build``, see
 :ref:`west-building-cmake-args`.
 
-In some cases the information contained in Device Tree files is closely
+In some cases the information contained in devicetree files is closely
 connected to the software and might need to be modified using the overlay file
-concept. This can be relevant for many of the different Device Tree nodes, but
+concept. This can be relevant for many of the different devicetree nodes, but
 is particularly useful for :ref:`certain types of nodes <dt-alias-chosen>`.
 
 Overlay files, which customarily have the :file:`.overlay` extension,
-contain device tree fragments which add to or modify the device tree
+contain devicetree fragments which add to or modify the devicetree
 used while building a Zephyr application. To add an overlay file or
 files to the build, set the CMake variable :makevar:`DTC_OVERLAY_FILE`
 to a whitespace-separated list of your overlay files.
 
-The Zephyr build system begins creation of a device tree by running
+The Zephyr build system begins creation of a devicetree by running
 the C preprocessor on a file which includes the following:
 
 #. Configuration options from :ref:`Kconfig <configuration_options>`.
 
-#. The board's device tree source file, which by default is the Zephyr
+#. The board's devicetree source file, which by default is the Zephyr
    file :file:`boards/<ARCHITECTURE>/<BOARD>/<BOARD>.dts`. (This location
    can be overridden by setting the :makevar:`DTS_SOURCE` CMake
    variable.)
@@ -1526,7 +1522,7 @@ the C preprocessor on a file which includes the following:
    overlays can be overridden by setting the
    :makevar:`DTS_COMMON_OVERLAYS` CMake variable.)
 
-   The file :file:`common.dts` conditionally includes device tree
+   The file :file:`common.dts` conditionally includes devicetree
    fragments based on Kconfig settings. For example, it includes a
    fragment for MCUboot chain-loading, located at
    :file:`dts/common/mcuboot.overlay`, if
@@ -1551,8 +1547,8 @@ is determined, and then stops looking:
 If :makevar:`DTC_OVERLAY_FILE` specifies multiple files, they are
 included in order by the C preprocessor.
 
-After running the preprocessor, the final device tree used in the
+After running the preprocessor, the final devicetree used in the
-build is created by running the device tree compiler, ``dtc``, on the
+build is created by running the devicetree compiler, ``dtc``, on the
 preprocessor output.
 
 Application-Specific Code

doc/guides/dts/index.rst

@@ -5,7 +5,7 @@ Devicetree
 
 Zephyr uses the *devicetree* data structure to describe the hardware available
 on a board, as well as its initial configuration in an application. Note that
-"devicetree" -- without spaces -- is preferred to "device tree". The
+"devicetree" -- without spaces -- is preferred to "devicetree". The
 `Devicetree specification`_ fully defines this data structure and its source
 and binary representations.
 

doc/guides/env_vars.rst

@@ -146,7 +146,7 @@ behavior.
   :ref:`important-build-vars`.
 - :envvar:`CONF_FILE`: allows adding Kconfig fragments to an application build;
   see :ref:`important-build-vars`.
-- :envvar:`DTC_OVERLAY_FILE`: allows adding device tree overlays to an
+- :envvar:`DTC_OVERLAY_FILE`: allows adding devicetree overlays to an
   application build; see :ref:`important-build-vars`.
 - :envvar:`ZEPHYR_BASE`: the absolute path to the main ``zephyr`` repository.
   This is set whenever you run the ``zephyr-env.sh`` or ``zephyr-env.cmd``

doc/guides/kconfig/index.rst

@@ -34,7 +34,7 @@ sense for the user to change its value.
 In Zephyr, Kconfig configuration is done after selecting a machine, so in
 general, it does not make sense to put a prompt on a symbol that corresponds to
 a fixed machine-specific setting. Usually, such settings should be handled via
-device tree (``.dts``) files instead.
+devicetree (``.dts``) files instead.
 
 Symbols without prompts can't be configured directly by the user (they derive
 their value from other symbols), so less restrictions apply to them. If some
@@ -808,12 +808,12 @@ Kconfig Functions
 *****************
 
 Kconfiglib provides user-defined preprocessor functions that
-we use in Zephyr to expose Device Tree information to Kconfig.
+we use in Zephyr to expose devicetree information to Kconfig.
 For example, we can get the default value for a Kconfig symbol
-from the device tree.
+from the devicetree.
 
-Device Tree Related Functions
+Devicetree Related Functions
-=============================
+============================
 
 See the Python docstrings in ``scripts/kconfig/kconfigfunctions.py`` for more
 details on the functions.
@@ -831,7 +831,7 @@ Example Usage
 -------------
 
 The following example shows the usage of the ``dt_node_reg_addr`` function.
-This function will take a path to a device tree node and register the register
+This function will take a path to a devicetree node and register the register
 address of that node:
 
 .. code-block:: none

doc/guides/porting/shields.rst

@@ -23,8 +23,8 @@ under :zephyr_file:`/boards/shields`:
 
 These files provides shield configuration as follows:
 
-* **<shield>.overlay**: This file provides a shield description in device tree
+* **<shield>.overlay**: This file provides a shield description in devicetree
-  format that is merged with the board's device tree information before
+  format that is merged with the board's devicetree information before
   compilation.
 
 * **<shield>.conf**: This file defines values for Kconfig symbols that are
@@ -47,8 +47,8 @@ This should be done at two different level:
 
 * Pinmux: Connector pins should be correctly configured to match shield pins
 
-* Device tree: A board device tree file should define a node alias for each
+* Devicetree: A board :ref:`device-tree` file should define a node alias for
-  connector interface.  For example, for Arduino I2C:
+  each connector interface. For example, for Arduino I2C:
 
 .. code-block:: none
 

doc/guides/west/build-flash-debug.rst

@@ -191,7 +191,7 @@ are given. All command-line arguments to ``west build`` after a ``--`` are
 passed to CMake.
 
 To set :ref:`DTC_OVERLAY_FILE <application_dt>` to :file:`enable-modem.overlay`,
-using that file as a :ref:`device tree overlay <device-tree>`::
+using that file as a :ref:`devicetree overlay <device-tree>`::
 
   west build -b reel_board -- -DDTC_OVERLAY_FILE=enable-modem.overlay
 

doc/introduction/index.rst

@@ -99,11 +99,9 @@ Zephyr offers a large and ever growing number of features including:
    drivers configured into the system and Allows the reuse of drivers across
    platforms that have common devices/IP blocks
 
-**Device Tree Support**
+**Devicetree Support**
-   Use of Device Tree (DTS) to describe hardware and configuration information for
+   Use of :ref:`device-tree` to describe hardware. Information from devicetree
-   boards. The DTS information will be used only during compile time.
+   is used to create the application image.
-   Information about the system is extracted from the compiled DTS and used to
-   create the application image.
 
 **Native Networking Stack supporting multiple protocols**
    Networking support is fully featured and optimized, including LwM2M and BSD

doc/reference/storage/disk/sdhc.rst

@@ -25,7 +25,7 @@ MMC cards are not supported and will be ignored.
 Enabling
 ********
 
-For example, this device tree fragment adds an SDHC card slot on ``spi1``,
+For example, this devicetree fragment adds an SDHC card slot on ``spi1``,
 uses ``PA27`` for chip select, and runs the SPI bus at 24 MHz once the
 SDHC card has been initialized:
 

samples/basic/blinky/README.rst

@@ -15,7 +15,7 @@ Requirements
 
 The demo assumes that an LED is connected to one of GPIO lines. The
 sample code is configured to work on boards that have defined the led0
-alias in their board device tree description file. Doing so will generate
+alias in their board devicetree description file. Doing so will generate
 these variables:
 
 - DT_ALIAS_LED0_GPIOS_CONTROLLER

samples/basic/button/README.rst

@@ -22,7 +22,7 @@ header file. The :file:`board.h` must define the following variables:
 - DT_ALIAS_SW0_GPIOS_PIN
 
 Alternatively, this could also be done by defining 'sw0' alias in the board
-device tree description file.
+devicetree description file.
 
 
 Building and Running

samples/bluetooth/hci_spi/README.rst

@@ -21,8 +21,8 @@ In order to use this application, you need a board with a Bluetooth
 controller and SPI slave drivers, and a spare GPIO to use as an
 interrupt line to the SPI master.
 
-You then need to ensure that your Device Tree settings provide a definition
+You then need to ensure that your :ref:`device-tree` settings provide a
-for the slave HCI SPI device::
+definition for the slave HCI SPI device::
 
 	bt-hci@0 {
 		compatible = "zephyr,bt-hci-spi-slave";

samples/drivers/CAN/README.rst

@@ -18,7 +18,7 @@ In loopback mode, the board receives its own messages. This could be used for
 standalone testing.
 
 The sample can be built and executed on boards supporting CAN.
-The LED output pin is defined in the board's device tree.
+The LED output pin is defined in the board's devicetree.
 
 Sample output
 =============

samples/shields/x_nucleo_iks01a1/README.rst

@@ -19,7 +19,7 @@ Requirements
 This sample communicates over I2C with the X-NUCLEO-IKS01A1 shield
 stacked on a board with an Arduino connector. The board's I2C must be
 configured for the I2C Arduino connector (both for pin muxing
-and device tree).
+and devicetree).
 Please note that this sample can't be used with boards already supporting
 one of the sensors available on the shield (such as disco_l475_iot1) as zephyr
 does not yet support sensors multiple instances.

samples/shields/x_nucleo_iks01a2/README.rst

@@ -19,7 +19,7 @@ Requirements
 This sample communicates over I2C with the X-NUCLEO-IKS01A2 shield
 stacked on a board with an Arduino connector. The board's I2C must be
 configured for the I2C Arduino connector (both for pin muxing
-and device tree). See for example the :ref:`nucleo_f401re_board` board
+and devicetree). See for example the :ref:`nucleo_f401re_board` board
 source code:
 
 - :zephyr_file:`boards/arm/nucleo_f401re/nucleo_f401re.dts`

samples/shields/x_nucleo_iks01a3/sensorhub/README.rst

@@ -32,7 +32,7 @@ Requirements
 This sample communicates over I2C with the X-NUCLEO-IKS01A3 shield
 stacked on a board with an Arduino connector. The board's I2C must be
 configured for the I2C Arduino connector (both for pin muxing
-and device tree). See for example the :ref:`nucleo_f401re_board` board
+and devicetree). See for example the :ref:`nucleo_f401re_board` board
 source code:
 
 - :file:`$ZEPHYR_BASE/boards/arm/nucleo_f401re/nucleo_f401re.dts`

samples/shields/x_nucleo_iks01a3/standard/README.rst

@@ -25,7 +25,7 @@ Requirements
 This sample communicates over I2C with the X-NUCLEO-IKS01A3 shield
 stacked on a board with an Arduino connector. The board's I2C must be
 configured for the I2C Arduino connector (both for pin muxing
-and device tree). See for example the :ref:`nucleo_f401re_board` board
+and devicetree). See for example the :ref:`nucleo_f401re_board` board
 source code:
 
 - :file:`$ZEPHYR_BASE/boards/arm/nucleo_f401re/nucleo_f401re.dts`