Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml- Extension
.yaml- Size
- 6764 bytes
- Lines
- 217
- 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.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
dt-bindings/interrupt-controller/arm-gic.hdt-bindings/mailbox/tegra186-hsp.hdt-bindings/memory/tegra186-mc.h
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/firmware/nvidia,tegra186-bpmp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra Boot and Power Management Processor (BPMP)
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
description: |
The BPMP is a specific processor in Tegra chip, which is designed for
booting process handling and offloading the power management, clock
management, and reset control tasks from the CPU. The binding document
defines the resources that would be used by the BPMP firmware driver,
which can create the interprocessor communication (IPC) between the
CPU and BPMP.
This node is a mailbox consumer. See the following files for details
of the mailbox subsystem, and the specifiers implemented by the
relevant provider(s):
- .../mailbox/mailbox.txt
- .../mailbox/nvidia,tegra186-hsp.yaml
This node is a clock, power domain, and reset provider. See the
following files for general documentation of those features, and the
specifiers implemented by this node:
- .../clock/clock-bindings.txt
- <dt-bindings/clock/tegra186-clock.h>
- ../power/power-domain.yaml
- <dt-bindings/power/tegra186-powergate.h>
- .../reset/reset.txt
- <dt-bindings/reset/tegra186-reset.h>
The BPMP implements some services which must be represented by
separate nodes. For example, it can provide access to certain I2C
controllers, and the I2C bindings represent each I2C controller as a
device tree node. Such nodes should be nested directly inside the main
BPMP node.
Software can determine whether a child node of the BPMP node
represents a device by checking for a compatible property. Any node
with a compatible property represents a device that can be
instantiated. Nodes without a compatible property may be used to
provide configuration information regarding the BPMP itself, although
no such configuration nodes are currently defined by this binding.
The BPMP firmware defines no single global name-/numbering-space for
such services. Put another way, the numbering scheme for I2C buses is
distinct from the numbering scheme for any other service the BPMP may
provide (e.g. a future hypothetical SPI bus service). As such, child
device nodes will have no reg property, and the BPMP node will have no
"#address-cells" or "#size-cells" property.
The shared memory area for the IPC TX and RX between CPU and BPMP are
predefined and work on top of either sysram, which is an SRAM inside the
chip, or in normal SDRAM.
See ".../sram/sram.yaml" for the bindings for the SRAM case.
See "../reserved-memory/nvidia,tegra264-bpmp-shmem.yaml" for bindings for
the SDRAM case.
properties:
compatible:
oneOf:
- items:
- enum:
Annotation
- Immediate include surface: `dt-bindings/interrupt-controller/arm-gic.h`, `dt-bindings/mailbox/tegra186-hsp.h`, `dt-bindings/memory/tegra186-mc.h`.
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.