kernel/drivers/pci/controller/dwc/pcie-designware-host.c, branch linux-6.5.y

Revert "PCI: dwc: Wait for link up only if link is started"

2023-07-26T15:49:11Z

This reverts commit da56a1bfbab55189595e588f1d984bdfb5cf5924. Bjorn Andersson, Fabio Estevam, Xiaolei Wang, and Jon Hunter reported that da56a1bfbab5 ("PCI: dwc: Wait for link up only if link is started") broke controller probing by returning an error in case the link does not come up during host initialisation, for example when the slot is empty. As explained in commit 886a9c134755 ("PCI: dwc: Move link handling into common code") and as indicated by the comment "Ignore errors, the link may come up later" in the code, waiting for link up and ignoring errors is the intended behaviour: Let's standardize this to succeed as there are usecases where devices (and the link) appear later even without hotplug. For example, a reconfigured FPGA device. Reverting the offending commit specifically fixes a regression on Qualcomm platforms like the Lenovo ThinkPad X13s which no longer reach the interconnect sync state if a slot does not have a device populated (e.g. an optional modem). Note that enabling asynchronous probing by default as was done for Qualcomm platforms by commit c0e1eb441b1d ("PCI: qcom: Enable async probe by default"), should take care of any related boot time concerns. Finally, note that the intel-gw driver is the only driver currently not providing a .start_link() callback and instead starts the link in its .host_init() callback, which may avoid an additional one-second timeout during probe by making the link-up wait conditional. If anyone cares, that can be done in a follow-up patch with a proper motivation. [bhelgaas: add Fabio Estevam, Xiaolei Wang, Jon Hunter reports] Fixes: da56a1bfbab5 ("PCI: dwc: Wait for link up only if link is started") Link: https://lore.kernel.org/r/20230706082610.26584-1-johan+linaro@kernel.org Reported-by: Bjorn Andersson Signed-off-by: Johan Hovold Reported-by: Fabio Estevam Link: https://lore.kernel.org/r/20230704122635.1362156-1-festevam@gmail.com/ Reported-by: Xiaolei Wang Link: https://lore.kernel.org/r/20230705010624.3912934-1-xiaolei.wang@windriver.com/ Reported-by: Jon Hunter Link: https://lore.kernel.org/r/6ca287a1-6c7c-7b90-9022-9e73fb82b564@nvidia.com Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Cc: Sajid Dalvi Cc: Ajay Agarwal

PCI: dwc: Wait for link up only if link is started

2023-05-26T08:45:12Z

In dw_pcie_host_init() regardless of whether the link has been started or not, the code waits for the link to come up. Even in cases where start_link() is not defined the code ends up spinning in a loop for 1 second. Since in some systems dw_pcie_host_init() gets called during probe, this one second loop for each pcie interface instance ends up extending the boot time. Wait for the link up in only if the start_link() is defined. Link: https://lore.kernel.org/r/20230412093425.3659088-1-ajayagarwal@google.com Tested-by: Will McVicker Signed-off-by: Sajid Dalvi Signed-off-by: Ajay Agarwal Signed-off-by: Lorenzo Pieralisi

PCI: dwc: Add Root Port and Endpoint controller eDMA engine support

2023-02-22T19:46:14Z

Since the DW eDMA core now supports eDMA controllers embedded in locally accessible DW PCIe Root Ports and Endpoints, register these controllers when possible. To do that the DW PCIe core driver needs to perform some preparations first. First of all, it needs to find the eDMA controller CSRs base address, whether they are accessible over the Port Logic or iATU unrolled space. Afterwards it can try to auto-detect the eDMA controller availability and number of read/write channels. If none are found the procedure silently returns without error. Secondly, the platform is supposed to provide either combined or per-channel IRQ signals. If no valid IRQs set is found, the procedure returns without error to be backward compatible with platforms where DW PCIe controllers have eDMA but lack the IRQ description. Finally, before actually probing the eDMA device we need to allocate LLP items buffers. After that the DW eDMA can be registered. If registration is successful, a message regarding the number of detected Read/Write eDMA channels will be printed to the system as is done for the iATU settings. Note: the DW PCI controller driver (either host or endpoint mode) is currently always built-in, so if the DW eDMA core is built as a module (CONFIG_DW_EDMA=m), eDMA controllers will not be registered even if the dw-edma module is later loaded. Link: https://lore.kernel.org/r/20230113171409.30470-28-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Acked-by: Vinod Koul

PCI: dwc: Restrict only coherent DMA mask for MSI address allocation

2023-02-22T19:46:14Z

The MSI target address must be in the lowest 4GB memory to support PCI peripherals without 64-bit MSI support. Since the allocation is done from DMA coherent memory, set only the coherent DMA mask, leaving the streaming DMA mask alone. Thus streaming DMA operations will work with no artificial limitations. It will be specifically useful for the eDMA-capable controllers so the corresponding DMA engine clients would map the DMA buffers with no need for SWIOTLB for buffers allocated above 4GB. Add a brief comment about the reason allocating the MSI target address below 4GB. Link: https://lore.kernel.org/r/20230113171409.30470-26-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Reviewed-by: Robin Murphy

PCI: dwc: Introduce generic resources getter

2022-11-23T15:01:55Z

Currently the DW PCIe Root Port and Endpoint CSR spaces are retrieved in the separate parts of the DW PCIe core driver. It doesn't really make sense since the both controller types have identical set of the core CSR regions: DBI, DBI CS2 and iATU/eDMA. Thus we can simplify the DW PCIe Host and EP initialization methods by moving the platform-specific registers space getting and mapping into a common method. It gets to be even more justified seeing the CSRs base address pointers are preserved in the common DW PCIe descriptor. Note all the OF-based common DW PCIe settings initialization will be moved to the new method too in order to have a single function for all the generic platform properties handling in single place. A nice side-effect of this change is that the pcie-designware-host.c and pcie-designware-ep.c drivers are cleaned up from all the direct dw_pcie storage modification, which makes the DW PCIe core, Root Port and Endpoint modules more coherent. Link: https://lore.kernel.org/r/20221113191301.5526-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring

PCI: dwc: Introduce dma-ranges property support for RC-host

2022-11-23T15:01:55Z

In accordance with the generic PCIe Root Port DT-bindings the "dma-ranges" property has the same format as the "ranges" property. The only difference is in their semantics. The "dma-ranges" property describes the PCIe-to-CPU memory mapping in opposite to the CPU-to-PCIe mapping of the "ranges" property. Even though the DW PCIe controllers are normally equipped with the internal Address Translation Unit which inbound and outbound tables can be used to implement both properties semantics, it was surprising for me to discover that the host-related part of the DW PCIe driver currently supports the "ranges" property only while the "dma-ranges" windows are just ignored. Having the "dma-ranges" supported in the driver would be very handy for the platforms, that don't tolerate the 1:1 CPU-PCIe memory mapping and require a customized PCIe memory layout. So let's fix that by introducing the "dma-ranges" property support. First of all we suggest to rename the dw_pcie_prog_inbound_atu() method to dw_pcie_prog_ep_inbound_atu() and create a new version of the dw_pcie_prog_inbound_atu() function. Thus we'll have two methods for the RC and EP controllers respectively in the same way as it has been developed for the outbound ATU setup methods. Secondly aside with the memory window index and type the new dw_pcie_prog_inbound_atu() function will accept CPU address, PCIe address and size as its arguments. These parameters define the PCIe and CPU memory ranges which will be used to setup the respective inbound ATU mapping. The passed parameters need to be verified against the ATU ranges constraints in the same way as it is done for the outbound ranges. Finally the DMA-ranges detected for the PCIe controller need to be converted to the inbound ATU entries during the host controller initialization procedure. It will be done in the framework of the dw_pcie_iatu_setup() method. Note before setting the inbound ranges up we need to disable all the inbound ATU entries in order to prevent unexpected PCIe TLPs translations defined by some third party software like bootloaders. Link: https://lore.kernel.org/r/20221113191301.5526-16-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Reviewed-by: Manivannan Sadhasivam

PCI: dwc: Drop dependency on ZONE_DMA32

2022-08-29T07:56:33Z

Re-work the msi_msg DMA allocation logic to use dmam_alloc_coherent() which uses the coherent DMA mask to try to return an allocation within the DMA mask limits. With that, we now can drop the msi_page parameter in struct dw_pcie_rp. This allows kernel configurations that disable ZONE_DMA32 to continue supporting a 32-bit DMA mask. Without this patch, the PCIe host device will fail to probe when ZONE_DMA32 is disabled. Link: https://lore.kernel.org/r/20220825235404.4132818-2-willmcvicker@google.com Fixes: 35797e672ff0 ("PCI: dwc: Fix MSI msi_msg DMA mapping") Reported-by: Isaac J. Manjarres Signed-off-by: Will McVicker Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Acked-by: Jingoo Han

PCI: dwc: Handle MSIs routed to multiple GIC interrupts

2022-08-01T20:15:33Z

On some Qualcomm platforms each group of 32 MSI vectors is routed to a separate GIC interrupt. Implement support for such configurations by parsing "msi0" ... "msiX" interrupts and attaching them to the chained handler. Note that if DT doesn't list an array of MSI interrupts and uses a single "msi" IRQ, the driver will limit the number of supported MSI vectors to 32. Link: https://lore.kernel.org/r/20220707134733.2436629-5-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Bjorn Helgaas Reviewed-by: Rob Herring Reviewed-by: Johan Hovold Reviewed-by: Manivannan Sadhasivam

PCI: dwc: Convert struct pcie_port.msi_irq to an array

2022-08-01T20:15:33Z

The Qualcomm DWC PCIe controller supports more than 32 MSI interrupts, but they are routed to separate interrupts in groups of 32 vectors. To support this configuration, change the msi_irq field to an array. Let the DWC core handle all interrupts that were set in this array. [bhelgaas: reorder, drop "irq" temporary to make patch cleaner] Link: https://lore.kernel.org/r/20220707134733.2436629-3-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Bjorn Helgaas Reviewed-by: Rob Herring Reviewed-by: Johan Hovold Reviewed-by: Manivannan Sadhasivam

PCI: dwc: Split MSI IRQ parsing/allocation to a separate function

2022-08-01T20:15:33Z

Split handling of MSI host IRQs to a separate dw_pcie_msi_host_init() function. The code is complex enough to warrant a separate function. [bhelgaas: reorder patch earlier] Link: https://lore.kernel.org/r/20220707134733.2436629-4-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Bjorn Helgaas Reviewed-by: Rob Herring Reviewed-by: Johan Hovold Reviewed-by: Manivannan Sadhasivam