Documentation/devicetree/bindings/xilinx.txt
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/xilinx.txt
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/xilinx.txt- Extension
.txt- Size
- 5861 bytes
- Lines
- 140
- 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.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
function cores
Annotated Snippet
d) Xilinx IP cores
The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range
of standard device types (network, serial, etc.) and miscellaneous
devices (gpio, LCD, spi, etc). Also, since these devices are
implemented within the fpga fabric every instance of the device can be
synthesised with different options that change the behaviour.
Each IP-core has a set of parameters which the FPGA designer can use to
control how the core is synthesized. Historically, the EDK tool would
extract the device parameters relevant to device drivers and copy them
into an 'xparameters.h' in the form of #define symbols. This tells the
device drivers how the IP cores are configured, but it requires the kernel
to be recompiled every time the FPGA bitstream is resynthesized.
The new approach is to export the parameters into the device tree and
generate a new device tree each time the FPGA bitstream changes. The
parameters which used to be exported as #defines will now become
properties of the device node. In general, device nodes for IP-cores
will take the following form:
(name): (generic-name)@(base-address) {
compatible = "xlnx,(ip-core-name)-(HW_VER)"
[, (list of compatible devices), ...];
reg = <(baseaddr) (size)>;
interrupt-parent = <&interrupt-controller-phandle>;
interrupts = < ... >;
xlnx,(parameter1) = "(string-value)";
xlnx,(parameter2) = <(int-value)>;
};
(generic-name): an open firmware-style name that describes the
generic class of device. Preferably, this is one word, such
as 'serial' or 'ethernet'.
(ip-core-name): the name of the ip block (given after the BEGIN
directive in system.mhs). Should be in lowercase
and all underscores '_' converted to dashes '-'.
(name): is derived from the "PARAMETER INSTANCE" value.
(parameter#): C_* parameters from system.mhs. The C_ prefix is
dropped from the parameter name, the name is converted
to lowercase and all underscore '_' characters are
converted to dashes '-'.
(baseaddr): the baseaddr parameter value (often named C_BASEADDR).
(HW_VER): from the HW_VER parameter.
(size): the address range size (often C_HIGHADDR - C_BASEADDR + 1).
Typically, the compatible list will include the exact IP core version
followed by an older IP core version which implements the same
interface or any other device with the same interface.
'reg' and 'interrupts' are all optional properties.
For example, the following block from system.mhs:
BEGIN opb_uartlite
PARAMETER INSTANCE = opb_uartlite_0
PARAMETER HW_VER = 1.00.b
PARAMETER C_BAUDRATE = 115200
PARAMETER C_DATA_BITS = 8
PARAMETER C_ODD_PARITY = 0
PARAMETER C_USE_PARITY = 0
PARAMETER C_CLK_FREQ = 50000000
PARAMETER C_BASEADDR = 0xEC100000
PARAMETER C_HIGHADDR = 0xEC10FFFF
BUS_INTERFACE SOPB = opb_7
PORT OPB_Clk = CLK_50MHz
PORT Interrupt = opb_uartlite_0_Interrupt
PORT RX = opb_uartlite_0_RX
PORT TX = opb_uartlite_0_TX
Annotation
- Detected declarations: `function cores`.
- 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.