Documentation/devicetree/bindings/interrupt-controller/fsl,mpic-msi.yaml
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/interrupt-controller/fsl,mpic-msi.yaml
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/interrupt-controller/fsl,mpic-msi.yaml- Extension
.yaml- Size
- 5874 bytes
- Lines
- 162
- 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/fsl,mpic-msi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale MSI interrupt controller
description: |
The Freescale hypervisor and msi-address-64
-------------------------------------------
Normally, PCI devices have access to all of CCSR via an ATMU mapping. The
Freescale MSI driver calculates the address of MSIIR (in the MSI register
block) and sets that address as the MSI message address.
In a virtualized environment, the hypervisor may need to create an IOMMU
mapping for MSIIR. The Freescale ePAPR hypervisor has this requirement
because of hardware limitations of the Peripheral Access Management Unit
(PAMU), which is currently the only IOMMU that the hypervisor supports.
The ATMU is programmed with the guest physical address, and the PAMU
intercepts transactions and reroutes them to the true physical address.
In the PAMU, each PCI controller is given only one primary window. The
PAMU restricts DMA operations so that they can only occur within a window.
Because PCI devices must be able to DMA to memory, the primary window must
be used to cover all of the guest's memory space.
PAMU primary windows can be divided into 256 subwindows, and each
subwindow can have its own address mapping ("guest physical" to "true
physical"). However, each subwindow has to have the same alignment, which
means they cannot be located at just any address. Because of these
restrictions, it is usually impossible to create a 4KB subwindow that
covers MSIIR where it's normally located.
Therefore, the hypervisor has to create a subwindow inside the same
primary window used for memory, but mapped to the MSIR block (where MSIIR
lives). The first subwindow after the end of guest memory is used for
this. The address specified in the msi-address-64 property is the PCI
address of MSIIR. The hypervisor configures the PAMU to map that address to
the true physical address of MSIIR.
maintainers:
- J. Neuschäfer <j.ne@posteo.net>
properties:
compatible:
oneOf:
- enum:
- fsl,mpic-msi
- fsl,mpic-msi-v4.3
- fsl,ipic-msi
- fsl,vmpic-msi
- fsl,vmpic-msi-v4.3
- items:
- enum:
- fsl,mpc8572-msi
- fsl,mpc8610-msi
- fsl,mpc8641-msi
- const: fsl,mpic-msi
reg:
minItems: 1
items:
- description: Address and length of the shared message interrupt
register set
- description: Address of aliased MSIIR or MSIIR1 register for platforms
that have such an alias. If using MSIIR1, the second region must be
added because different MSI group has different MSIIR1 offset.
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.