aboutsummaryrefslogtreecommitdiff
path: root/drivers/pci/controller/pcie-rcar-ep.c
AgeCommit message (Collapse)AuthorFilesLines
2024-04-10PCI: endpoint: Remove "core_init_notifier" flagManivannan Sadhasivam1-0/+2
"core_init_notifier" flag is set by the glue drivers requiring refclk from the host to complete the DWC core initialization. Also, those drivers will send a notification to the EPF drivers once the initialization is fully completed using the pci_epc_init_notify() API. Only then, the EPF drivers will start functioning. For the rest of the drivers generating refclk locally, EPF drivers will start functioning post binding with them. EPF drivers rely on the 'core_init_notifier' flag to differentiate between the drivers. Unfortunately, this creates two different flows for the EPF drivers. So to avoid that, let's get rid of the "core_init_notifier" flag and follow a single initialization flow for the EPF drivers. This is done by calling the dw_pcie_ep_init_notify() from all glue drivers after the completion of dw_pcie_ep_init_registers() API. This will allow all the glue drivers to send the notification to the EPF drivers once the initialization is fully completed. Only difference here is that, the drivers requiring refclk from host will send the notification once refclk is received, while others will send it during probe time itself. But this also requires the EPC core driver to deliver the notification after EPF driver bind. Because, the glue driver can send the notification before the EPF drivers bind() and in those cases the EPF drivers will miss the event. To accommodate this, EPC core is now caching the state of the EPC initialization in 'init_complete' flag and pci-ep-cfs driver sends the notification to EPF drivers based on that after each EPF driver bind. Link: https://lore.kernel.org/linux-pci/[email protected] Tested-by: Niklas Cassel <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Frank Li <[email protected]> Reviewed-by: Niklas Cassel <[email protected]>
2024-02-16PCI: endpoint: Clean up hardware description for BARsNiklas Cassel1-5/+9
The hardware description for BARs is scattered in many different variables in pci_epc_features. Some of these things are mutually exclusive, so it can create confusion over which variable that has precedence over another. Improve the situation by creating a struct pci_epc_bar_desc, and a new enum pci_epc_bar_type, and convert the endpoint controller drivers to use this more well defined format. Additionally, some endpoint controller drivers mark the BAR succeeding a "64-bit only BAR" as reserved, while some do not. By definition, a 64-bit BAR uses the succeeding BAR for the upper 32-bits, so an EPF driver cannot use a BAR succeeding a 64-bit BAR. Ensure that all endpoint controller drivers are uniform, and actually describe a reserved BAR as reserved. Signed-off-by: Niklas Cassel <[email protected]> Reviewed-by: Kishon Vijay Abraham I <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]>
2023-12-18PCI: endpoint: Drop PCI_EPC_IRQ_XXX definitionsDamien Le Moal1-4/+3
linux/pci.h defines the IRQ flags PCI_IRQ_INTX, PCI_IRQ_MSI and PCI_IRQ_MSIX. Let's use these flags directly instead of the endpoint definitions provided by enum pci_epc_irq_type. This removes the need for defining this enum type completely. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Serge Semin <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Manivannan Sadhasivam <[email protected]>
2023-10-03PCI: Use PCI_HEADER_TYPE_* instead of literalsIlpo Järvinen1-1/+1
Replace literals under drivers/pci/ with PCI_HEADER_TYPE_MASK, PCI_HEADER_TYPE_NORMAL, and PCI_HEADER_TYPE_MFD. Also replace !! boolean conversions with FIELD_GET(). Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> # for Renesas R-Car
2021-10-08PCI: rcar-ep: Remove unneeded includesGeert Uytterhoeven1-4/+1
Remove includes that are not needed, to speed up (re)compilation. Include <linux/pm_runtime.h>, which is needed, and was included implicitly through <linux/phy/phy.h> before. Most of these are relics from splitting the driver in a host and a common part and adding endpoint support. [bhelgaas: use driver tag consistent with cadence-ep, designware-ep] Link: https://lore.kernel.org/r/7c708841a2bf84f85b14a963271c3e99c8ba38a5.1633090444.git.geert+renesas@glider.be Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]>
2021-09-02Merge branch 'remotes/lorenzo/pci/endpoint'Bjorn Helgaas1-9/+10
- Add max-virtual-functions to endpoint binding (Kishon Vijay Abraham I) - Add pci_epf_add_vepf() API to add virtual function to endpoint (Kishon Vijay Abraham I) - Add pci_epf_vepf_link() to link virtual function to endpoint physical function (Kishon Vijay Abraham I) - Add virtual function number to pci_epc_ops endpoint ops interfaces (Kishon Vijay Abraham I) - Simplify register base address computation for endpoint BAR configuration (Kishon Vijay Abraham I) - Add support to configure virtual functions in cadence endpoint driver (Kishon Vijay Abraham I) - Add SR-IOV configuration to endpoint test driver (Kishon Vijay Abraham I) - Document configfs usage to create virtual functions for endpoints (Kishon Vijay Abraham I) * remotes/lorenzo/pci/endpoint: Documentation: PCI: endpoint/pci-endpoint-cfs: Guide to use SR-IOV misc: pci_endpoint_test: Populate sriov_configure ops to configure SR-IOV device PCI: cadence: Add support to configure virtual functions PCI: cadence: Simplify code to get register base address for configuring BAR PCI: endpoint: Add virtual function number in pci_epc ops PCI: endpoint: Add support to link a physical function to a virtual function PCI: endpoint: Add support to add virtual function in endpoint core dt-bindings: PCI: pci-ep: Add binding to specify virtual function
2021-08-19PCI: endpoint: Add virtual function number in pci_epc opsKishon Vijay Abraham I1-9/+10
Add virtual function number in pci_epc ops. EPC controller driver can perform virtual function specific initialization based on the virtual function number. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kishon Vijay Abraham I <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]>
2021-08-05PCI: rcar: Fix runtime PM imbalance in rcar_pcie_ep_probe()Dinghao Liu1-2/+2
pm_runtime_get_sync() will increase the runtime PM counter even it returns an error. Thus a pairing decrement is needed to prevent refcount leak. Fix this by replacing this API with pm_runtime_resume_and_get(), which will not change the runtime PM counter on error. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dinghao Liu <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]>
2020-05-22PCI: rcar: Add endpoint mode supportLad Prabhakar1-0/+563
Add support for R-Car PCIe controller to work in endpoint mode. Link: https://lore.kernel.org/r/1588854799-13710-8-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Lad Prabhakar <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]>