Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml

Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml

File Facts

System
Linux kernel
Corpus path
Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml
Extension
.yaml
Size
8936 bytes
Lines
248
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 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/nvidia,tegra186-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: NVIDIA Tegra GPIO Controller (Tegra186 and later)

maintainers:
  - Thierry Reding <thierry.reding@gmail.com>
  - Jon Hunter <jonathanh@nvidia.com>

description: |
  Tegra186 contains two GPIO controllers; a main controller and an "AON"
  controller. This binding document applies to both controllers. The register
  layouts for the controllers share many similarities, but also some
  significant differences. Hence, this document describes closely related but
  different bindings and compatible values.

  The Tegra186 GPIO controller allows software to set the IO direction of,
  and read/write the value of, numerous GPIO signals. Routing of GPIO signals
  to package balls is under the control of a separate pin controller hardware
  block. Two major sets of registers exist:

    a) Security registers, which allow configuration of allowed access to the
       GPIO register set. These registers exist in a single contiguous block
       of physical address space. The size of this block, and the security
       features available, varies between the different GPIO controllers.

       Access to this set of registers is not necessary in all circumstances.
       Code that wishes to configure access to the GPIO registers needs access
       to these registers to do so. Code which simply wishes to read or write
       GPIO data does not need access to these registers.

    b) GPIO registers, which allow manipulation of the GPIO signals. In some
       GPIO controllers, these registers are exposed via multiple "physical
       aliases" in address space, each of which access the same underlying
       state. See the hardware documentation for rationale. Any particular
       GPIO client is expected to access just one of these physical aliases.

    Tegra HW documentation describes a unified naming convention for all GPIOs
    implemented by the SoC. Each GPIO is assigned to a port, and a port may
    control a number of GPIOs. Thus, each GPIO is named according to an
    alphabetical port name and an integer GPIO name within the port. For
    example, GPIO_PA0, GPIO_PN6, or GPIO_PCC3.

    The number of ports implemented by each GPIO controller varies. The number
    of implemented GPIOs within each port varies. GPIO registers within a
    controller are grouped and laid out according to the port they affect.

    The mapping from port name to the GPIO controller that implements that
    port, and the mapping from port name to register offset within a
    controller, are both extremely non-linear. The header file
    <dt-bindings/gpio/tegra186-gpio.h> describes the port-level mapping. In
    that file, the naming convention for ports matches the HW documentation.
    The values chosen for the names are alphabetically sorted within a
    particular controller. Drivers need to map between the DT GPIO IDs and HW
    register offsets using a lookup table.

    Each GPIO controller can generate a number of interrupt signals. Each
    signal represents the aggregate status for all GPIOs within a set of
    ports. Thus, the number of interrupt signals generated by a controller
    varies as a rough function of the number of ports it implements. Note
    that the HW documentation refers to both the overall controller HW
    module and the sets-of-ports as "controllers".

    Each GPIO controller in fact generates multiple interrupts signals for
    each set of ports. Each GPIO may be configured to feed into a specific
    one of the interrupt signals generated by a set-of-ports. The intent is
    for each generated signal to be routed to a different CPU, thus allowing

Annotation

Implementation Notes