Lines Matching +full:current +full:- +full:source +full:- +full:pin

1 .. _dt-design:
8 specific examples about how they impact Zephyr's source code, and areas where
11 Single source for hardware information
14 Zephyr's built-in device drivers and sample applications shall obtain
20 - New device drivers shall use devicetree APIs to determine which :ref:`devices
21   to create <dt-create-devices>`.
23 - In-tree sample applications shall use :ref:`aliases <dt-alias-chosen>` to
25   used in the current build. For example, the :zephyr:code-sample:`blinky` sample uses this to
28 - Boot-time pin muxing and pin control for new SoCs shall be accomplished via a
29   devicetree-based pinctrl driver
34 - Zephyr's :ref:`twister_script` currently use :file:`board.yaml` files to
38 - Legacy device drivers currently use Kconfig to determine which instances of a
42 - Board-level documentation still contains tables of hardware support which are
46 - Runtime determination of ``struct device`` relationships should be done using
49 .. _dt-source-compatibility:
51 Source compatibility with other operating systems
57 Zephyr's binding language *semantics* can support Zephyr-specific attributes,
58 but shall not express Zephyr-specific relationships.
63 - Zephyr's devicetree source parser, :ref:`dtlib.py <dt-scripts>`, is
64   source-compatible with other tools like `dtc`_ in both directions:
68 - Zephyr's "extended dtlib" library, :file:`edtlib.py`, shall not include
69   Zephyr-specific features. Its purpose is to provide a higher-level view of the
72   Only the high-level :file:`gen_defines.py` script, which is built on top of
73   :file:`edtlib.py`, contains Zephyr-specific knowledge and features.
80 - Zephyr has a custom :ref:`dt-bindings` language *syntax*. While Linux's
84 - Due to inflexibility in the bindings language, Zephyr cannot support the full
87 - Devicetree source sharing between Zephyr and Linux is not done.