Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml

Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml

File Facts

System
Linux kernel
Corpus path
Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml
Extension
.yaml
Size
22760 bytes
Lines
670
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/phy/nvidia,tegra194-xusb-padctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: NVIDIA Tegra194 XUSB pad controller

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

description: |
  The Tegra XUSB pad controller manages a set of I/O lanes (with differential
  signals) which connect directly to pins/pads on the SoC package. Each lane
  is controlled by a HW block referred to as a "pad" in the Tegra hardware
  documentation. Each such "pad" may control either one or multiple lanes,
  and thus contains any logic common to all its lanes. Each lane can be
  separately configured and powered up.

  Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
  super-speed USB. Other lanes are for various types of low-speed, full-speed
  or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
  contains a software-configurable mux that sits between the I/O controller
  ports (e.g. PCIe) and the lanes.

  In addition to per-lane configuration, USB 3.0 ports may require additional
  settings on a per-board basis.

  Pads will be represented as children of the top-level XUSB pad controller
  device tree node. Each lane exposed by the pad will be represented by its
  own subnode and can be referenced by users of the lane using the standard
  PHY bindings, as described by the phy-bindings.txt file in this directory.

  The Tegra hardware documentation refers to the connection between the XUSB
  pad controller and the XUSB controller as "ports". This is confusing since
  "port" is typically used to denote the physical USB receptacle. The device
  tree binding in this document uses the term "port" to refer to the logical
  abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
  for the USB signal, the VBUS power supply, the USB 2.0 companion port for
  USB 3.0 receptacles, ...).

properties:
  compatible:
    enum:
      - nvidia,tegra194-xusb-padctl
      - nvidia,tegra234-xusb-padctl

  reg:
    items:
      - description: pad controller registers
      - description: AO registers

  reg-names:
    items:
      - const: padctl
      - const: ao

  interrupts:
    items:
      - description: XUSB pad controller interrupt

  resets:
    items:
      - description: pad controller reset

  reset-names:
    items:
      - const: padctl

Annotation

Implementation Notes