Documentation/devicetree/bindings/pinctrl/thead,th1520-pinctrl.yaml

Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/pinctrl/thead,th1520-pinctrl.yaml

File Facts

System
Linux kernel
Corpus path
Documentation/devicetree/bindings/pinctrl/thead,th1520-pinctrl.yaml
Extension
.yaml
Size
5220 bytes
Lines
177
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/pinctrl/thead,th1520-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: T-Head TH1520 SoC pin controller

maintainers:
  - Emil Renner Berthing <emil.renner.berthing@canonical.com>

description: |
  Pinmux and pinconf controller in the T-Head TH1520 RISC-V SoC.

  The TH1520 has 3 groups of pads each controlled from different memory ranges.
  Confusingly the memory ranges are named
    PADCTRL_AOSYS  -> PAD Group 1
    PADCTRL1_APSYS -> PAD Group 2
    PADCTRL0_APSYS -> PAD Group 3

  Each pad can be muxed individually to up to 6 different functions. For most
  pads only a few of those 6 configurations are valid though, and a few pads in
  group 1 does not support muxing at all.

  Pinconf is fairly regular except for a few pads in group 1 that either can't
  be configured or has some special functions. The rest have configurable drive
  strength, input enable, schmitt trigger, slew rate, pull-up and pull-down in
  addition to a special strong pull up.

  Certain pads in group 1 can be muxed to AUDIO_PA0 - AUDIO_PA30 functions and
  are then meant to be used by the audio co-processor. Each such pad can then
  be further muxed to either audio GPIO or one of 4 functions such as UART, I2C
  and I2S. If the audio pad is muxed to one of the 4 functions then pinconf is
  also configured in different registers. All of this is done from a different
  AUDIO_IOCTRL memory range and is left to the audio co-processor for now.

properties:
  compatible:
    enum:
      - thead,th1520-pinctrl
  reg:
    maxItems: 1

  clocks:
    maxItems: 1

  thead,pad-group:
    description: |
      Select the pad group that is associated with the pin controller instance.

        Base Address   Name           Group
        0xFF_FFF4_A000 PADCTRL_AOSYS  1
        0xFF_E7F3_C000 PADCTRL1_APSYS 2
        0xFF_EC00_7000 PADCTRL0_APSYS 3

    $ref: /schemas/types.yaml#/definitions/uint32
    enum: [1, 2, 3]

required:
  - compatible
  - reg
  - clocks

patternProperties:
  '-[0-9]+$':
    type: object
    additionalProperties: false

    patternProperties:
      '-pins$':

Annotation

Implementation Notes