Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml- Extension
.yaml- Size
- 5427 bytes
- Lines
- 174
- 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.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
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/interrupt-controller/riscv,imsics.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: RISC-V Incoming MSI Controller (IMSIC)
maintainers:
- Anup Patel <anup@brainfault.org>
description: |
The RISC-V advanced interrupt architecture (AIA) defines a per-CPU incoming
MSI controller (IMSIC) for handling MSIs in a RISC-V platform. The RISC-V
AIA specification can be found at https://github.com/riscv/riscv-aia.
The IMSIC is a per-CPU (or per-HART) device with separate interrupt file
for each privilege level (machine or supervisor). The configuration of
a IMSIC interrupt file is done using AIA CSRs and it also has a 4KB MMIO
space to receive MSIs from devices. Each IMSIC interrupt file supports a
fixed number of interrupt identities (to distinguish MSIs from devices)
which is same for given privilege level across CPUs (or HARTs).
The device tree of a RISC-V platform will have one IMSIC device tree node
for each privilege level (machine or supervisor) which collectively describe
IMSIC interrupt files at that privilege level across CPUs (or HARTs).
The arrangement of IMSIC interrupt files in MMIO space of a RISC-V platform
follows a particular scheme defined by the RISC-V AIA specification. A IMSIC
group is a set of IMSIC interrupt files co-located in MMIO space and we can
have multiple IMSIC groups (i.e. clusters, sockets, chiplets, etc) in a
RISC-V platform. The MSI target address of a IMSIC interrupt file at given
privilege level (machine or supervisor) encodes group index, HART index,
and guest index (shown below).
XLEN-1 > (HART Index MSB) 12 0
| | | |
-------------------------------------------------------------
|xxxxxx|Group Index|xxxxxxxxxxx|HART Index|Guest Index| 0 |
-------------------------------------------------------------
allOf:
- $ref: /schemas/interrupt-controller.yaml#
- $ref: /schemas/interrupt-controller/msi-controller.yaml#
properties:
compatible:
items:
- enum:
- qemu,imsics
- spacemit,k3-imsics
- const: riscv,imsics
reg:
minItems: 1
maxItems: 16384
description:
Base address of each IMSIC group.
interrupt-controller: true
"#interrupt-cells":
const: 0
msi-controller: true
"#msi-cells":
const: 0
interrupts-extended:
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
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.