Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml- Extension
.yaml- Size
- 10147 bytes
- Lines
- 332
- 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/clock/omap4.hdt-bindings/clock/omap5.hdt-bindings/clock/dra7.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/remoteproc/ti,omap-remoteproc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: OMAP4+ Remoteproc Devices
maintainers:
- Suman Anna <s-anna@ti.com>
description:
The OMAP family of SoCs usually have one or more slave processor sub-systems
that are used to offload some of the processor-intensive tasks, or to manage
other hardware accelerators, for achieving various system level goals.
The processor cores in the sub-system are usually behind an IOMMU, and may
contain additional sub-modules like Internal RAM and/or ROMs, L1 and/or L2
caches, an Interrupt Controller, a Cache Controller etc.
The OMAP SoCs usually have a DSP processor sub-system and/or an IPU processor
sub-system. The DSP processor sub-system can contain any of the TI's C64x,
C66x or C67x family of DSP cores as the main execution unit. The IPU processor
sub-system usually contains either a Dual-Core Cortex-M3 or Dual-Core
Cortex-M4 processors.
Each remote processor sub-system is represented as a single DT node. Each node
has a number of required or optional properties that enable the OS running on
the host processor (MPU) to perform the device management of the remote
processor and to communicate with the remote processor. The various properties
can be classified as constant or variable. The constant properties are
dictated by the SoC and does not change from one board to another having the
same SoC. Examples of constant properties include 'iommus', 'reg'. The
variable properties are dictated by the system integration aspects such as
memory on the board, or configuration used within the corresponding firmware
image. Examples of variable properties include 'mboxes', 'memory-region',
'timers', 'watchdog-timers' etc.
properties:
compatible:
enum:
- ti,omap4-dsp
- ti,omap5-dsp
- ti,dra7-dsp
- ti,omap4-ipu
- ti,omap5-ipu
- ti,dra7-ipu
iommus:
minItems: 1
maxItems: 2
description: |
phandles to OMAP IOMMU nodes, that need to be programmed
for this remote processor to access any external RAM memory or
other peripheral device address spaces. This property usually
has only a single phandle. Multiple phandles are used only in
cases where the sub-system has different ports for different
sub-modules within the processor sub-system (eg: DRA7 DSPs),
and need the same programming in both the MMUs.
mboxes:
minItems: 1
maxItems: 2
description: |
OMAP Mailbox specifier denoting the sub-mailbox, to be used for
communication with the remote processor. The specifier format is
as per the bindings,
Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml
This property should match with the sub-mailbox node used in
the firmware image.
Annotation
- Immediate include surface: `dt-bindings/clock/omap4.h`, `dt-bindings/clock/omap5.h`, `dt-bindings/clock/dra7.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.