Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml

Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml

File Facts

System
Linux kernel
Corpus path
Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml
Extension
.yaml
Size
4816 bytes
Lines
134
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: configuration, schema, or hardware description
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/pinmux-node.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Generic Pin Multiplexing Node

maintainers:
  - Linus Walleij <linusw@kernel.org>

description: |
  The contents of the pin configuration child nodes are defined by the binding
  for the individual pin controller device. The pin configuration nodes need not
  be direct children of the pin controller device; they may be grandchildren,
  for example. Whether this is legal, and whether there is any interaction
  between the child and intermediate parent nodes, is again defined entirely by
  the binding for the individual pin controller device.

  While not required to be used, there are 3 generic forms of pin muxing nodes
  which pin controller devices can use.

  pin multiplexing nodes:

  Example:

  state_0_node_a {
    uart0 {
      function = "uart0";
      groups = "u0rxtx", "u0rtscts";
    };
  };
  state_1_node_a {
    spi {
      function = "spi0";
      groups = "spi0pins";
    };
  };
  state_2_node_a {
    function = "i2c0";
    pins = "mfio29", "mfio30";
  };

  Optionally an alternative binding can be used if more suitable depending on the
  pin controller hardware. For hardware where there is a large number of identical
  pin controller instances, naming each pin and function can easily become
  unmaintainable. This is especially the case if the same controller is used for
  different pins and functions depending on the SoC revision and packaging.

  For cases like this, the pin controller driver may use pinctrl-pin-array helper
  binding with a hardware based index and a number of pin configuration values:

  pincontroller {
    ... /* Standard DT properties for the device itself elided */
    #pinctrl-cells = <2>;

    state_0_node_a {
      pinctrl-pin-array = <
        0 A_DELAY_PS(0) G_DELAY_PS(120)
        4 A_DELAY_PS(0) G_DELAY_PS(360)
        ...
        >;
    };
    ...
  };

  Above #pinctrl-cells specifies the number of value cells in addition to the
  index of the registers. This is similar to the interrupts-extended binding with
  one exception. There is no need to specify the phandle for each entry as that
  is already known as the defined pins are always children of the pin controller

Annotation

Implementation Notes