| Message ID | 20240715-pci-qcom-hotplug-v1-0-5f3765cc873a@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | PCI: qcom: Simulate PCIe hotplug using 'global' interrupt | expand |
On 15.07.2024 7:33 PM, Manivannan Sadhasivam via B4 Relay wrote: > Hi, > > This series adds support to simulate PCIe hotplug using the Qcom specific > 'global' IRQ. Historically, Qcom PCIe RC controllers lack standard hotplug > support. So when an endpoint is attached to the SoC, users have to rescan the > bus manually to enumerate the device. But this can be avoided by simulating the > PCIe hotplug using Qcom specific way. > > Qcom PCIe RC controllers are capable of generating the 'global' SPI interrupt > to the host CPUs. The device driver can use this event to identify events such > as PCIe link specific events, safety events etc... > > One such event is the PCIe Link up event generated when an endpoint is detected > on the bus and the Link is 'up'. This event can be used to simulate the PCIe > hotplug in the Qcom SoCs. > > So add support for capturing the PCIe Link up event using the 'global' interrupt > in the driver. Once the Link up event is received, the bus underneath the host > bridge is scanned to enumerate PCIe endpoint devices, thus simulating hotplug. > > This series also has some cleanups to the Qcom PCIe EP controller driver for > interrupt handling. Welp I've reviewed this series, and only now came to the realization that the PCIe RC and PCIe EP descriptions are borderline identical.. perhaps for new platforms we could get a new binding that could have a structure like pcie@abcd1234 { // commmon properties pcie-ep { // ep specifics }; pcie-rc { // rc specifics } }; or better yet, have a single node no matter what, but consume only the required resources from the driver and have something akin to phy-mode, just like we solved the DP/eDP dual-mode controller story Although here it may not be so simple given there's properties like iommu-map that map to bus specifics.. Konrad
On Mon, Jul 15, 2024 at 10:10:47PM +0200, Konrad Dybcio wrote: > On 15.07.2024 7:33 PM, Manivannan Sadhasivam via B4 Relay wrote: > > Hi, > > > > This series adds support to simulate PCIe hotplug using the Qcom specific > > 'global' IRQ. Historically, Qcom PCIe RC controllers lack standard hotplug > > support. So when an endpoint is attached to the SoC, users have to rescan the > > bus manually to enumerate the device. But this can be avoided by simulating the > > PCIe hotplug using Qcom specific way. > > > > Qcom PCIe RC controllers are capable of generating the 'global' SPI interrupt > > to the host CPUs. The device driver can use this event to identify events such > > as PCIe link specific events, safety events etc... > > > > One such event is the PCIe Link up event generated when an endpoint is detected > > on the bus and the Link is 'up'. This event can be used to simulate the PCIe > > hotplug in the Qcom SoCs. > > > > So add support for capturing the PCIe Link up event using the 'global' interrupt > > in the driver. Once the Link up event is received, the bus underneath the host > > bridge is scanned to enumerate PCIe endpoint devices, thus simulating hotplug. > > > > This series also has some cleanups to the Qcom PCIe EP controller driver for > > interrupt handling. > > Welp I've reviewed this series, and only now came to the realization that > the PCIe RC and PCIe EP descriptions are borderline identical.. perhaps for > new platforms we could get a new binding that could have a structure like > > pcie@abcd1234 { > // commmon properties > > pcie-ep { > // ep specifics > }; > > pcie-rc { > // rc specifics > } > }; > > or better yet, have a single node no matter what, but consume only the > required resources from the driver and have something akin to phy-mode, > just like we solved the DP/eDP dual-mode controller story > > Although here it may not be so simple given there's properties like > iommu-map that map to bus specifics.. > It's not that simple, but I wouldn't rule out the technical possibility. Also with the addition of PCIe bridges and endpoint descriptions (thanks to the new pwrctl driver), it will look even messier. And then there will also be the driver side ugliness... - Mani
Hi, This series adds support to simulate PCIe hotplug using the Qcom specific 'global' IRQ. Historically, Qcom PCIe RC controllers lack standard hotplug support. So when an endpoint is attached to the SoC, users have to rescan the bus manually to enumerate the device. But this can be avoided by simulating the PCIe hotplug using Qcom specific way. Qcom PCIe RC controllers are capable of generating the 'global' SPI interrupt to the host CPUs. The device driver can use this event to identify events such as PCIe link specific events, safety events etc... One such event is the PCIe Link up event generated when an endpoint is detected on the bus and the Link is 'up'. This event can be used to simulate the PCIe hotplug in the Qcom SoCs. So add support for capturing the PCIe Link up event using the 'global' interrupt in the driver. Once the Link up event is received, the bus underneath the host bridge is scanned to enumerate PCIe endpoint devices, thus simulating hotplug. This series also has some cleanups to the Qcom PCIe EP controller driver for interrupt handling. Testing ======= This series is tested on Qcom SM8450 based development board that has 2 SoCs connected over PCIe. - Mani Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> --- Manivannan Sadhasivam (14): PCI: qcom-ep: Drop the redundant masking of global IRQ events PCI: qcom-ep: Reword the error message for receiving unknown global IRQ event dt-bindings: PCI: pci-ep: Update Maintainers dt-bindings: PCI: pci-ep: Document 'linux,pci-domain' property dt-bindings: PCI: qcom-ep: Document "linux,pci-domain" property PCI: endpoint: Assign PCI domain number for endpoint controllers PCI: qcom-ep: Modify 'global_irq' and 'perst_irq' IRQ device names ARM: dts: qcom: sdx55: Add 'linux,pci-domain' to PCIe EP controller node ARM: dts: qcom: sdx65: Add 'linux,pci-domain' to PCIe EP controller node arm64: dts: qcom: sa8775p: Add 'linux,pci-domain' to PCIe EP controller nodes dt-bindings: PCI: qcom: Add 'global' interrupt dt-bindings: PCI: qcom,pcie-sm8450: Add 'global' interrupt PCI: qcom: Simulate PCIe hotplug using 'global' interrupt arm64: dts: qcom: sm8450: Add 'global' interrupt to the PCIe RC node Documentation/devicetree/bindings/pci/pci-ep.yaml | 14 +++++- .../devicetree/bindings/pci/qcom,pcie-common.yaml | 4 +- .../devicetree/bindings/pci/qcom,pcie-ep.yaml | 1 + .../devicetree/bindings/pci/qcom,pcie-sm8450.yaml | 10 ++-- arch/arm/boot/dts/qcom/qcom-sdx55.dtsi | 1 + arch/arm/boot/dts/qcom/qcom-sdx65.dtsi | 1 + arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 + arch/arm64/boot/dts/qcom/sm8450.dtsi | 12 +++-- drivers/pci/controller/dwc/pcie-qcom-ep.c | 21 +++++++-- drivers/pci/controller/dwc/pcie-qcom.c | 55 ++++++++++++++++++++++ drivers/pci/endpoint/pci-epc-core.c | 1 + include/linux/pci-epc.h | 2 + 12 files changed, 108 insertions(+), 16 deletions(-) --- base-commit: 91e3b24eb7d297d9d99030800ed96944b8652eaf change-id: 20240715-pci-qcom-hotplug-bcde1c13d91f Best regards,