kernel/drivers/pci/controller/dwc/pcie-designware.h, 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: Introduce generic platform clocks and resets

2022-11-23T15:01:55Z

Currently almost each platform driver uses its own resets and clocks naming in order to get the corresponding descriptors. It makes the code harder to maintain and comprehend especially seeing the DWC PCIe core main resets and clocks signals set hasn't changed much for about at least one major IP-core release. So in order to organize things around these signals we suggest to create a generic interface for them in accordance with the naming introduced in the DWC PCIe IP-core reference manual: Application clocks: - "dbi" - data bus interface clock (on some DWC PCIe platforms it's referred as "pclk", "pcie", "sys", "ahb", "cfg", "iface", "gio", "reg", "pcie_apb_sys"); - "mstr" - AXI-bus master interface clock (some DWC PCIe glue drivers refer to this clock as "port", "bus", "pcie_bus", "bus_master/master_bus/axi_m", "pcie_aclk"); - "slv" - AXI-bus slave interface clock (also called as "port", "bus", "pcie_bus", "bus_slave/slave_bus/axi_s", "pcie_aclk", "pcie_inbound_axi"). Core clocks: - "pipe" - core-PCS PIPE interface clock coming from external PHY (it's normally named by the platform drivers as just "pipe"); - "core" - primary clock of the controller (none of the platform drivers declare such a clock but in accordance with the ref. manual the devices may have it separately specified); - "aux" - auxiliary PMC domain clock (it is named by some platforms as "pcie_aux" and just "aux"); - "ref" - Generic reference clock (it is a generic clock source, which can be used as a signal source for multiple interfaces, some platforms call it as "ref", "general", "pcie_phy", "pcie_phy_ref"). Application resets: - "dbi" - Data-bus interface reset (it's CSR interface clock and is normally called as "apb" though technically it's not APB but DWC PCIe-specific interface); - "mstr" - AXI-bus master reset (some platforms call it as "port", "apps", "bus", "axi_m"); - "slv" - ABI-bus slave reset (some platforms call it as "port", "apps", "bus", "axi_s"). Core resets: - "non-sticky" - non-sticky CSR flags reset; - "sticky" - sticky CSR flags reset; - "pipe" - PIPE-interface (Core-PCS) logic reset (some platforms call it just "pipe"); - "core" - controller primary reset (resets everything except PMC module, some platforms refer to this signal as "soft", "pci"); - "phy" - PCS/PHY block reset (strictly speaking it is normally connected to the input of an external block, but the reference manual says it must be available for the PMC working correctly, some existing platforms call it "pciephy", "phy", "link"); - "hot" - PMC hot reset signal (also called as "sleep"); - "pwr" - cold reset signal (can be referred as "pwr", "turnoff"). Bus reset: - "perst" - PCIe standard signal used to reset the PCIe peripheral devices. As you can see each platform uses it's own naming for basically the same set of the signals. In the framework of this commit we suggest to add a set of the clocks and reset signals resources, corresponding names and identifiers for each denoted entity. At current stage the platforms will be able to use the provided infrastructure to automatically request all these resources and manipulate with them in the Host/EP init callbacks. Alas it isn't that easy to create a common cold/hot reset procedure due to too many platform-specifics in the procedure, like the external flags exposure and the delays requirement. Link: https://lore.kernel.org/r/20221113191301.5526-20-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin Signed-off-by: Lorenzo Pieralisi

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 generic controller capabilities interface

2022-11-23T15:01:55Z

Since in addition to the already available iATU unrolled mapping we are about to add a few more DW PCIe platform-specific capabilities (CDM-check and generic clocks/resets resources) let's add a generic interface to set and get the flags indicating their availability. The new interface shall improve maintainability of the platform-specific code. Link: https://lore.kernel.org/r/20221113191301.5526-17-Sergey.Semin@baikalelectronics.ru Signed-off-by: Serge Semin Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Reviewed-by: Manivannan Sadhasivam

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

Merge branch 'pci/ctrl/tegra194'

2022-08-04T16:46:51Z

- Fix tegra_pcie_config_ep() power management in error path (Miaoqian Lin) - Convert DT binding to json-schema (Vidya Sagar) - Add DT bindings and driver support for Tegra234 Root Port and Endpoint mode (Vidya Sagar) - Disable MSI for Tegra234 Root Ports so they use INTx for all events (PCIe doesn't allow mixing INTx and MSI/MSI-X) (Vidya Sagar) - Search for Vendor-Specific RAS-DEC capability instead of hard-coding offset (Vidya Sagar) - Fix unintentional APPL_INTR_STATUS_L0 value overwrite in Root Port interrupt handling (Vidya Sagar) - Clear Bandwidth Management interrupt status bit to avoid interrupt storm (Vidya Sagar) - Set default Max Payload Size to 256 bytes (Vidya Sagar) - Fix offset when clearing bit in Data Link Feature capability (Vidya Sagar) - Extend Endpoint mode support to devices beyond Controller-5 (Vidya Sagar) * pci/ctrl/tegra194: PCI: tegra194: Add Tegra234 PCIe support PCI: tegra194: Extend Endpoint mode support PCI: tegra194: Fix link up retry sequence PCI: tegra194: Clean up the exit path for Endpoint mode PCI: tegra194: Enable support for 256 Byte payload PCI: tegra194: Clear bandwidth management status PCI: tegra194: Fix Root Port interrupt handling PCI: tegra194: Find RAS DES PCIe capability offset Revert "PCI: tegra194: Rename tegra_pcie_dw to tegra194_pcie" PCI: Disable MSI for Tegra234 Root Ports dt-bindings: PCI: tegra234: Add schema for tegra234 Endpoint mode dt-bindings: PCI: tegra234: Add schema for tegra234 Root Port mode dt-bindings: PCI: tegra194: Convert to json-schema PCI: tegra194: Fix PM error handling in tegra_pcie_config_ep() # Conflicts: # drivers/pci/controller/dwc/pcie-designware.h # drivers/pci/controller/dwc/pcie-tegra194.c

Merge branch 'pci/ctrl/qcom'

2022-08-04T16:41:58Z

- Add PHY clock source implementation (Dmitry Baryshkov) - Use new clk_regmap_phy_mux_ops for gcc-sm8450 and gcc-sc7280 PCIe pipe clocks (Dmitry Baryshkov) - Set up rev 2.1.0 PARF_PHY before enabling clocks (Christian Marangi) - Power on PHY before accessing IPQ8074 DBI registers to avoid boot hangs (Robert Marko) - Power on PHY before accessing DBI registers on all variants for consistency (Robert Marko) - Remove unnecessary pipe_clk handling since this is done in PHY drivers (Dmitry Baryshkov) - Drop manual pipe_clk_src handling (Dmitry Baryshkov) - Move GEN3_RELATED DBI definitions to common dwc header (Baruch Siach) - Define slot capabilities using generic PCI_EXP_SLTCAP_* macros (Baruch Siach) - Add IPQ60xx support (Selvam Sathappan Periakaruppan) - Fix DT description typo (Baruch Siach) - Fix DT "compatibles" typo (Johan Hovold) - Allow ASPM L1 and substates for 2.7.0 (Krishna chaitanya chundru) * pci/ctrl/qcom: PCI: qcom: Allow ASPM L1 and substates for 2.7.0 dt-bindings: PCI: qcom: Fix reset conditional dt-bindings: PCI: qcom: Fix description typo PCI: qcom: Add IPQ60xx support PCI: qcom: Define slot capabilities using PCI_EXP_SLTCAP_* PCI: dwc: Move GEN3_RELATED DBI definitions to common header PCI: qcom: Drop manual pipe_clk_src handling PCI: qcom: Remove unnecessary pipe_clk handling PCI: qcom: Power on PHY before DBI register accesses PCI: qcom: Power on PHY before IPQ8074 DBI register accesses PCI: qcom: Set up rev 2.1.0 PARF_PHY before enabling clocks clk: qcom: gcc-sc7280: use new clk_regmap_phy_mux_ops for PCIe pipe clocks clk: qcom: gcc-sm8450: use new clk_regmap_phy_mux_ops for PCIe pipe clocks clk: qcom: regmap: add PHY clock source implementation