1. Article purpose[edit | edit source]
The purpose of this article is to explain how to configure the PCIe internal peripheral using the device tree mechanism, relying on the bindings documentation, that is the description of the required and optional device-tree properties.
It is used by the PCIe Linux drivers[1][2], which registers the relevant information in the PCIe framework.
2. DT bindings documentation[edit | edit source]
The device tree binding documents are stored in the Linux® kernel repository:
For root complex (RC) mode:
- Synopsys DesignWare® PCIe common device tree bindings:Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml
- Synopsys DesignWare® PCIe host device tree bindings: Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
- STM32 PCIe host device tree bindings: Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
For endpoint (EP) mode:
- Synopsys DesignWare® PCIe common device tree bindings:Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml
- Synopsys DesignWare® PCIe endpoint device tree bindings: Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
- STM32 PCIe endpoint device tree bindings: Documentation/devicetree/bindings/pci/st,stm32-pcie-ep.yaml
3. DT configuration[edit | edit source]
This hardware description is a combination of the STM32 microprocessor device tree files (.dtsi extension) and board device tree files (.dts extension). See the device tree for an explanation of the device-tree file organization.
STM32CubeMX can be used to generate the board device tree. Refer to how to configure the DT using STM32CubeMX for more details.
3.1. DT configuration (STM32/SoC level)[edit | edit source]
The PCIe controller can act either as a root complex (RC), or as an endpoint (EP). Each mode is composed of a set of properties, used to describe the PCIe controller: registers address, clocks, resets...
The pcie_rc and pcie_ep DT nodes are declared in:
- stm32mp251.dtsi[3] on STM32MP25x lines
It is composed of a set of properties, used to describe the PCIe controller: registers address, PCIe memory ranges, clocks, resets, interrupts, phys...
3.1.1. PCIe host node[edit | edit source]
pcie_rc: pcie-ep@48400000 {
compatible = "st,stm32mp25-pcie-rc", "snps,dw-pcie";
device_type = "pci";
num-lanes = <1>;
reg = <0x48400000 0x400000>,
<0x10000000 0x10000>;
reg-names = "dbi", "config";
st,syscfg = <&syscfg>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &intc 0 0 GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>,
<0 0 0 2 &intc 0 0 GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>,
<0 0 0 3 &intc 0 0 GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>,
<0 0 0 4 &intc 0 0 GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "aer_msi", "pme_msi";
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x01000000 0 0x10010000 0x10010000 0 0x10000>,
<0x02000000 0 0x10020000 0x10020000 0 0x7fe0000>,
<0x42000000 0 0x18000000 0x18000000 0 0x8000000>;
bus-range = <0x00 0xff>;
clocks = <&rcc CK_BUS_PCIE>;
clock-names = "core";
resets = <&rcc PCIE_R>;
reset-names = "pcie";
phys = <&combophy PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
msi-parent = <&v2m0>;
access-controllers = <&rifsc 68>;
power-domains = <&CLUSTER_PD>;
status = "disabled";
};
3.1.2. PCIe device node[edit | edit source]
pcie_ep: pcie-ep@48400000 {
compatible = "st,stm32mp25-pcie-ep", "snps,dw-pcie-ep";
num-lanes = <1>;
reg = <0x48400000 0x400000>,
<0x10000000 0x8000000>;
reg-names = "dbi", "addr_space";
st,syscfg = <&syscfg>;
clocks = <&rcc CK_BUS_PCIE>;
clock-names = "core";
resets = <&rcc PCIE_R>;
reset-names = "pcie";
phys = <&combophy PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
access-controllers = <&rifsc 68>;
status = "disabled";
};
3.2. DT configuration (board level)[edit | edit source]
The objective of this chapter is to explain how to enable and configure the "PCIe" DT node for a board.
Peripheral configuration should be done in specific board device tree files (board dts file).
3.3. DT configuration for the board configured as root complex[edit | edit source]
- Enable this configuration by setting status = "okay";
&pcie_rc {
status = "okay";
};
- Set the optional GPIO to which the controller asserts PERST# (fundamental reset) to notify the device to initialize.
&pcie_ep {
reset-gpios = <&gpioj 8 GPIO_ACTIVE_LOW>;
};
- Set the optional pinctrl to which the controller receives CLKREQ#.
The PCIe controller needs the COMBOPHY reference clock to be ready to start, so the pinctrl defines an init state to drive the CLKREQ GPIO to low. Once the driver has been probed, the pinmux can come back to the original default state, waiting for the controller or the device to drive it to low. If power management is supported, the GPIO can be put in low power mode with the sleep state.
&pcie_rc {
pinctrl-names = "default", "init", "sleep";
pinctrl-0 = <&pcie_pins_a>;
pinctrl-1 = <&pcie_init_pins_a>;
pinctrl-2 = <&pcie_sleep_pins_a>;
};
- Set the optional power management wake-up pins.
&pcie_rc {
wake-gpios = <&gpioh 5 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)
wakeup-source;
};
3.4. DT configuration for the board configured as end point[edit | edit source]
- Enable this configuration by setting status = "okay";
&pcie_ep {
status = "okay";
};
- Set the optional GPIO to which the controller receives PERST# (fundamental reset) signal to indicate the reference clock is ready.
&pcie_ep {
reset-gpios = <&gpioj 8 GPIO_ACTIVE_LOW>;
};
- Set the optional pinctrl to which the controller deasserts CLKREQ#.
The PCIe controller needs the COMBOPHY reference clock to be ready to start, the pinctrl defines an init state to drive the CLKREQ GPIO to low. Once the probe is done, the pinmux can come back to the original default state since deassertion is done by the controller.
&pcie_ep {
pinctrl-names = "default", "init";
pinctrl-0 = <&pcie_pins_a>;
pinctrl-1 = <&pcie_init_pins_a>;
status = "okay";
};
4. How to configure the DT using STM32CubeMX[edit | edit source]
The STM32CubeMX tool can be used to configure the STM32MPU device and get the corresponding platform configuration device tree files.
STM32CubeMX may not support all the properties described in the DT binding files listed in the above DT bindings documentation paragraph. If so, the tool inserts user sections in the generated device tree. These sections can then be edited to add some properties, and they are preserved from one generation to another. Refer to the STM32CubeMX user manual for further information.
5. References[edit | edit source]
Refer to the following links for additional information:
- ↑ drivers/pci/controller/dwc/pcie-stm32.c
- ↑ drivers/pci/controller/dwc/pcie-stm32-ep.c
- ↑ arch/arm64/boot/dts/st/stm32mp251.dtsi , STM32MP251 device tree file