Documentation/fpga/dfl.rst
Source file repositories/reference/linux-study-clean/Documentation/fpga/dfl.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/fpga/dfl.rst- Extension
.rst- Size
- 30533 bytes
- Lines
- 688
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- 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.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
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
=================================================
FPGA Device Feature List (DFL) Framework Overview
=================================================
Authors:
- Enno Luebbers <enno.luebbers@intel.com>
- Xiao Guangrong <guangrong.xiao@linux.intel.com>
- Wu Hao <hao.wu@intel.com>
- Xu Yilun <yilun.xu@intel.com>
The Device Feature List (DFL) FPGA framework (and drivers according to
this framework) hides the very details of low layer hardware and provides
unified interfaces to userspace. Applications could use these interfaces to
configure, enumerate, open and access FPGA accelerators on platforms which
implement the DFL in the device memory. Besides this, the DFL framework
enables system level management functions such as FPGA reconfiguration.
Device Feature List (DFL) Overview
==================================
Device Feature List (DFL) defines a linked list of feature headers within the
device MMIO space to provide an extensible way of adding features. Software can
walk through these predefined data structures to enumerate FPGA features:
FPGA Interface Unit (FIU), Accelerated Function Unit (AFU) and Private Features,
as illustrated below::
Header Header Header Header
+----------+ +-->+----------+ +-->+----------+ +-->+----------+
| Type | | | Type | | | Type | | | Type |
| FIU | | | Private | | | Private | | | Private |
+----------+ | | Feature | | | Feature | | | Feature |
| Next_DFH |--+ +----------+ | +----------+ | +----------+
+----------+ | Next_DFH |--+ | Next_DFH |--+ | Next_DFH |--> NULL
| ID | +----------+ +----------+ +----------+
+----------+ | ID | | ID | | ID |
| Next_AFU |--+ +----------+ +----------+ +----------+
+----------+ | | Feature | | Feature | | Feature |
| Header | | | Register | | Register | | Register |
| Register | | | Set | | Set | | Set |
| Set | | +----------+ +----------+ +----------+
+----------+ | Header
+-->+----------+
| Type |
| AFU |
+----------+
| Next_DFH |--> NULL
+----------+
| GUID |
+----------+
| Header |
| Register |
| Set |
+----------+
FPGA Interface Unit (FIU) represents a standalone functional unit for the
interface to FPGA, e.g. the FPGA Management Engine (FME) and Port (more
descriptions on FME and Port in later sections).
Accelerated Function Unit (AFU) represents an FPGA programmable region and
always connects to a FIU (e.g. a Port) as its child as illustrated above.
Private Features represent sub features of the FIU and AFU. They could be
various function blocks with different IDs, but all private features which
belong to the same FIU or AFU, must be linked to one list via the Next Device
Feature Header (Next_DFH) pointer.
Each FIU, AFU and Private Feature could implement its own functional registers.
The functional register set for FIU and AFU, is named as Header Register Set,
e.g. FME Header Register Set, and the one for Private Feature, is named as
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.