Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml- Extension
.yaml- Size
- 7478 bytes
- Lines
- 208
- 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
- No C-style include directives detected by the generator.
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/arm,mhuv2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM MHUv2 Mailbox Controller
maintainers:
- Tushar Khandelwal <tushar.khandelwal@arm.com>
- Viresh Kumar <viresh.kumar@linaro.org>
description: |
The Arm Message Handling Unit (MHU) Version 2 is a mailbox controller that has
between 1 and 124 channel windows (each 32-bit wide) to provide unidirectional
communication with remote processor(s), where the number of channel windows
are implementation dependent.
Given the unidirectional nature of the controller, an MHUv2 mailbox may only
be written to or read from. If a pair of MHU controllers is implemented
between two processing elements to provide bidirectional communication, these
must be specified as two separate mailboxes.
If the interrupts property is present in device tree node, then its treated as
a "receiver" mailbox, otherwise a "sender".
An MHU controller must be specified along with the supported transport
protocols. The transport protocols determine the method of data transmission
as well as the number of provided mailbox channels.
Following are the possible transport protocols.
- Data-transfer: Each transfer is made of one or more words, using one or more
channel windows.
- Doorbell: Each transfer is made up of single bit flag, using any one of the
bits in a channel window. A channel window can support up to 32 doorbells
and the entire window shall be used in doorbell protocol. Optionally, data
may be transmitted through a shared memory region, wherein the MHU is used
strictly as an interrupt generation mechanism but that is out of the scope
of these bindings.
# We need a select here so we don't match all nodes with 'arm,primecell'
select:
properties:
compatible:
contains:
enum:
- arm,mhuv2-tx
- arm,mhuv2-rx
required:
- compatible
properties:
compatible:
oneOf:
- description: Sender mode
items:
- const: arm,mhuv2-tx
- const: arm,primecell
- description: Receiver-mode
items:
- const: arm,mhuv2-rx
- const: arm,primecell
reg:
maxItems: 1
interrupts:
Annotation
- 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.