Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml- Extension
.yaml- Size
- 10224 bytes
- Lines
- 296
- 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.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/mailbox/ti,omap-mailbox.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI OMAP2+ and K3 Mailbox devices
maintainers:
- Suman Anna <s-anna@ti.com>
description: |
The OMAP Mailbox hardware facilitates communication between different
processors using a queued mailbox interrupt mechanism. The IP block is
external to the various processor subsystems and is connected on an
interconnect bus. The communication is achieved through a set of registers
for message storage and interrupt configuration registers.
Each mailbox IP block/cluster has a certain number of h/w fifo queues and
output interrupt lines. An output interrupt line is routed to an interrupt
controller within a processor subsystem, and there can be more than one line
going to a specific processor's interrupt controller. The interrupt line
connections are fixed for an instance and are dictated by the IP integration
into the SoC (excluding the SoCs that have an Interrupt Crossbar or an
Interrupt Router IP). Each interrupt line is programmable through a set of
interrupt configuration registers, and have a rx and tx interrupt source per
h/w fifo. Communication between different processors is achieved through the
appropriate programming of the rx and tx interrupt sources on the appropriate
interrupt lines.
The number of h/w fifo queues and interrupt lines dictate the usable
registers. All the current OMAP SoCs except for the newest DRA7xx SoC has a
single IP instance. DRA7xx has multiple instances with different number of
h/w fifo queues and interrupt lines between different instances. The interrupt
lines can also be routed to different processor sub-systems on DRA7xx as they
are routed through the Crossbar, a kind of interrupt router/multiplexer. The
K3 AM65x, J721E and J7200 SoCs has each of these instances form a cluster and
combine multiple clusters into a single IP block present within the Main
NavSS. The interrupt lines from all these clusters are multiplexed and routed
to different processor subsystems over a limited number of common interrupt
output lines of an Interrupt Router. The AM64x SoCS also uses a single IP
block comprising of multiple clusters, but the number of clusters are
smaller, and the interrupt output lines are connected directly to various
processors.
Mailbox Controller Nodes
=========================
A Mailbox device node is used to represent a Mailbox IP instance/cluster
within a SoC. The sub-mailboxes (actual communication channels) are
represented as child nodes of this parent node.
Mailbox Users
==============
A device needing to communicate with a target processor device should specify
them using the common mailbox binding properties, "mboxes" and the optional
"mbox-names" (please see Documentation/devicetree/bindings/mailbox/mailbox.txt
for details). Each value of the mboxes property should contain a phandle to
the mailbox controller device node and an args specifier that will be the
phandle to the intended sub-mailbox child node to be used for communication.
The equivalent "mbox-names" property value can be used to give a name to the
communication channel to be used by the client user.
$defs:
omap-mbox-descriptor:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
The omap-mbox-descriptor is made of up of 3 cells and represents a single
uni-directional communication channel. A typical sub-mailbox device uses
two such channels - one for transmitting (Tx) and one for receiving (Rx).
items:
Annotation
- Immediate include surface: `dt-bindings/interrupt-controller/arm-gic.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.