- Ioremap() msg_res region using res->start (the CPU address), not the ATU
'cpu_addr', which will be replaced with the ATU input address (which may
not be the CPU address) (Frank Li)
- Rename struct dw_pcie_ob_atu_cfg.cpu_addr to 'parent_bus_addr' (Frank Li)
- Call devm_pci_alloc_host_bridge() early in dw_pcie_host_init() to keep
devicetree-related code together (Frank Li)
- Consolidate devicetree handling in dw_pcie_host_get_resources() (Bjorn
Helgaas)
- Add dw_pcie_parent_bus_offset() to look up the parent bus address of a
specified 'reg' property and return the offset from the CPU physical
address (Frank Li)
- Add cross-checking with .cpu_addr_fixup() and debug logging to
dw_pcie_parent_bus_offset() (Frank Li)
- Use devicetree 'reg[config]' via dw_pcie_parent_bus_offset() to derive
CPU -> ATU addr offset for host controller (Frank Li)
- Call epc_create() early in dw_pcie_ep_init() to keep devicetree-related
code together (Bjorn Helgaas)
- Consolidate devicetree handling in dw_pcie_ep_get_resources() (Bjorn
Helgaas)
- Use devicetree 'reg[addr_space]' via dw_pcie_parent_bus_offset() to
derive CPU -> ATU addr offset for endpoint controller (Frank Li)
- Update dw_pcie_find_index() to remove assumption that ATU input address
is non-zero (Frank Li)
- Apply struct dw_pcie.parent_bus_offset in ATU users to remove use of
.cpu_addr_fixup() when programming ATU (Frank Li)
- Remove imx_pcie_cpu_addr_fixup() since dwc core can now derive the ATU
input address (using parent_bus_offset) from devicetree (Frank Li)
- Remove intel_pcie_cpu_addr() since dwc core can now derive the ATU input
address (using parent_bus_offset) from devicetree (Frank Li)
* pci/controller/dwc-cpu-addr-fixup:
PCI: intel-gw: Remove intel_pcie_cpu_addr()
PCI: imx6: Remove imx_pcie_cpu_addr_fixup()
PCI: dwc: Use parent_bus_offset to remove need for .cpu_addr_fixup()
PCI: dwc: ep: Ensure proper iteration over outbound map windows
PCI: dwc: ep: Use devicetree 'reg[addr_space]' to derive CPU -> ATU addr offset
PCI: dwc: ep: Consolidate devicetree handling in dw_pcie_ep_get_resources()
PCI: dwc: ep: Call epc_create() early in dw_pcie_ep_init()
PCI: dwc: Use devicetree 'reg[config]' to derive CPU -> ATU addr offset
PCI: dwc: Add dw_pcie_parent_bus_offset() checking and debug
PCI: dwc: Add dw_pcie_parent_bus_offset()
PCI: dwc: Consolidate devicetree handling in dw_pcie_host_get_resources()
PCI: dwc: Call devm_pci_alloc_host_bridge() early in dw_pcie_host_init()
PCI: dwc: Rename cpu_addr to parent_bus_addr for ATU configuration
PCI: dwc: Use resource start as ioremap() input in dw_pcie_pme_turn_off()
# Conflicts:
# drivers/pci/controller/dwc/pcie-designware.c
# drivers/pci/controller/dwc/pcie-designware.h
- Describe endpoint BAR0 and BAR2 as 64-bit only and BAR1 and BAR3 as
RESERVED (Manivannan Sadhasivam)
- Add optional dma-coherent DT property for Qualcomm SA8775P (Dmitry
Baryshkov)
- Make DT iommu property required for SA8775P and prohibited for SDX55
(Dmitry Baryshkov)
- Add DT iommu and DMA-related properties for Qualcomm SM8450 (Dmitry
Baryshkov)
- Consolidate DMA vs non-DMA cases in DT (Dmitry Baryshkov)
- Add endpoint DT properties for SAR2130P and enable endpoint mode in
driver (Dmitry Baryshkov)
* pci/controller/qcom:
PCI: qcom-ep: Enable EP mode support for SAR2130P
dt-bindings: PCI: qcom-ep: Add SAR2130P compatible
dt-bindings: PCI: qcom-ep: Consolidate DMA vs non-DMA cases
dt-bindings: PCI: qcom-ep: Enable DMA for SM8450
dt-bindings: PCI: qcom-ep: Describe optional IOMMU
dt-bindings: PCI: qcom-ep: Describe optional dma-coherent property
PCI: qcom-ep: Mark BAR0/BAR2 as 64bit BARs and BAR1/BAR3 as RESERVED
- Identify the second controller on i.MX8MQ based on devicetree
'linux,pci-domain' instead of DBI 'reg' address (Richard Zhu)
- Use devm_clk_bulk_get_all() to fetch clocks to simplify the code (Richard
Zhu)
* pci/controller/imx6:
PCI: imx6: Use devm_clk_bulk_get_all() to fetch clocks
PCI: imx6: Identify controller via 'linux,pci-domain', not address
- Call phy_exit() to clean up if histb_pcie_probe() fails (Christophe
JAILLET)
* pci/controller/histb:
PCI: histb: Fix an error handling path in histb_pcie_probe()
- Move struct dwc_pcie_vsec_id to include/linux/pcie-dwc.h, where it can be
shared by debugfs, perf, sysfs, etc (Manivannan Sadhasivam)
- Add dw_pcie_find_vsec_capability() to locate Vendor Specific Extended
Capabilities (Shradha Todi)
- Add debugfs-based Silicon Debug, Error Injection, Statistical Counter
support for DWC (Shradha Todi)
- Add debugfs property to expose LTSSM status of DWC PCIe link (Hans Zhang)
- Add Rockchip Vendor ID and Vendor Specific ID of RAS DES Capability so
the DWC debugfs features work for Rockchip as well (Niklas Cassel)
* pci/controller/dwc:
PCI: dw-rockchip: Hide broken ATS capability for RK3588 running in EP mode
PCI: dwc: ep: Add dw_pcie_ep_hide_ext_capability()
PCI: dwc: ep: Return -ENOMEM for allocation failures
PCI: dwc: Add Rockchip to the RAS DES allowed vendor list
PCI: Add Rockchip Vendor ID
PCI: dwc: Add debugfs property to provide LTSSM status of the PCIe link
PCI: dwc: Add debugfs based Statistical Counter support for DWC
PCI: dwc: Add debugfs based Error Injection support for DWC
PCI: dwc: Add debugfs based Silicon Debug support for DWC
PCI: dwc: Add helper to find the Vendor Specific Extended Capability (VSEC)
perf/dwc_pcie: Move common DWC struct definitions to 'pcie-dwc.h'
- Use for_each_available_child_of_node_scoped() to simplify apple, kirin,
mediatek, mt7621, tegra drivers (Zhang Zekun)
* pci/scoped-cleanup:
PCI: tegra: Use helper function for_each_child_of_node_scoped()
PCI: apple: Use helper function for_each_child_of_node_scoped()
PCI: mt7621: Use helper function for_each_available_child_of_node_scoped()
PCI: mediatek: Use helper function for_each_available_child_of_node_scoped()
PCI: kirin: Tidy up _probe() related function with dev_err_probe()
PCI: kirin: Use helper function for_each_available_child_of_node_scoped()
- Fix endpoint BAR testing so the test can skip disabled BARs instead of
reporting them as failures (Niklas Cassel)
- Verify that pci_endpoint interrupt tests set the correct IRQ type
(Kunihiko Hayashi)
- Fix interpretation of pci_endpoint_test_bars_read_bar() error returns
(Niklas Cassel)
- Fix potential string truncation in pci_endpoint_test_probe() (Niklas
Cassel)
- Increase endpoint test BAR size variable to accommodate BARs larger than
INT_MAX (Niklas Cassel)
- Release IRQs to avoid leak in pci_endpoint interrupt tests (Kunihiko
Hayashi)
- Log the correct IRQ type when pci_endpoint IRQ request test fails
(Kunihiko Hayashi)
- Remove pci_endpoint_test irq_type and no_msi globals; instead use
test->irq_type (Kunihiko Hayashi)
- Remove unnecessary use of managed IRQ functions in pci_endpoint_test
(Kunihiko Hayashi)
- Add and use IRQ_TYPE_* defines in pci_endpoint_test (Niklas Cassel)
- Add struct pci_epc_features.intx_capable and note that RK3568 and RK3588
can't raise INTx interrupts (Niklas Cassel)
- Expose supported IRQ types in CAPS so pci_endpoint_test can set
appropriate type (Niklas Cassel)
- Add PCITEST_IRQ_TYPE_AUTO to pci_endpoint_test for cases where the IRQ
type doesn't matter (Niklas Cassel)
* pci/endpoint-test:
misc: pci_endpoint_test: Add support for PCITEST_IRQ_TYPE_AUTO
PCI: endpoint: pci-epf-test: Expose supported IRQ types in CAPS register
PCI: dw-rockchip: Endpoint mode cannot raise INTx interrupts
PCI: endpoint: Add intx_capable to epc_features struct
selftests: pci_endpoint: Use IRQ_TYPE_* defines from UAPI header
misc: pci_endpoint_test: Use IRQ_TYPE_* defines from UAPI header
PCI: endpoint: pcitest: Add IRQ_TYPE_* defines to UAPI header
misc: pci_endpoint_test: Do not use managed IRQ functions
misc: pci_endpoint_test: Remove global 'irq_type' and 'no_msi'
misc: pci_endpoint_test: Fix 'irq_type' to convey the correct type
misc: pci_endpoint_test: Fix displaying 'irq_type' after 'request_irq' error
misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error
misc: pci_endpoint_test: Handle BAR sizes larger than INT_MAX
misc: pci_endpoint_test: Give disabled BARs a distinct error code
misc: pci_endpoint_test: Fix potential truncation in pci_endpoint_test_probe()
misc: pci_endpoint_test: Fix pci_endpoint_test_bars_read_bar() error handling
selftests: pci_endpoint: Add GET_IRQTYPE checks to each interrupt test
selftests: pci_endpoint: Skip disabled BARs
The arg_count parameter to syscon_regmap_lookup_by_phandle_args()
represents the number of argument cells following the phandle. In this
case, the number of arguments should be 1 instead of 2 since the dt
property looks like this:
fsl,pcie-scfg = <&scfg 0>;
Without this fix, layerscape-pcie fails with the following message on
LS1043A:
OF: /soc/pcie@3500000: phandle scfg@1570000 needs 2, found 1
layerscape-pcie 3500000.pcie: No syscfg phandle specified
layerscape-pcie 3500000.pcie: probe with driver layerscape-pcie failed with error -22
Link: https://lore.kernel.org/r/20250327151949.2765193-1-ioana.ciornei@nxp.com
Fixes: 149fc35734 ("PCI: layerscape: Use syscon_regmap_lookup_by_phandle_args")
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Roy Zang <Roy.Zang@nxp.com>
Cc: stable@vger.kernel.org
Neither RK3568 or RK3588 supports INTx interrupts.
Since epc_features is zero initialized, this is strictly not needed.
However, setting intx_capable explicitly to false makes it more clear
that neither RK3568 or RK3588 supports INTx interrupts.
No functional change.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Link: https://lore.kernel.org/r/20250310111016.859445-14-cassel@kernel.org
We know the parent_bus_offset, either computed from a DT reg property (the
offset is the CPU physical addr - the 'config'/'addr_space' address on the
parent bus) or from a .cpu_addr_fixup() (which may have used a host bridge
window offset).
Apply that parent_bus_offset instead of calling .cpu_addr_fixup() when
programming the ATU.
This assumes all intermediate addresses are at the same offset from the CPU
physical addresses.
[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20250315201548.858189-13-helgaas@kernel.org
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Most systems' PCIe outbound map windows have non-zero physical addresses,
but the possibility of encountering zero increased after following commit
("PCI: dwc: Use parent_bus_offset").
'ep->outbound_addr[n]', representing 'parent_bus_address', might be 0 on
some hardware, which trims high address bits through bus fabric before
sending to the PCIe controller.
Replace the iteration logic with 'for_each_set_bit()' to ensure only
allocated map windows are iterated when determining the ATU index from a
given address.
Link: https://lore.kernel.org/r/20250315201548.858189-12-helgaas@kernel.org
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Endpoint
┌───────────────────────────────────────────────┐
│ pcie-ep@5f010000 │
│ ┌────────────────┐│
│ │ Endpoint ││
│ │ PCIe ││
│ │ Controller ││
│ bus@5f000000 │ ┌────────►
│ ┌──────────┐ │ │ ││dynamically
│ │ │ Outbound Transfer │ ││allocated
│┌─────┐ │ Bus ┼─────►│ ATU ───────┘ ││PCI Addr
││ │ │ Fabric │Bus │ ││
││ CPU ├───►│ │Addr │ ││
││ │CPU │ │0x8000_0000 ││
│└─────┘Addr└──────────┘ │ ││
│ 0x7000_0000 └────────────────┘│
└───────────────────────────────────────────────┘
bus@5f000000 {
compatible = "simple-bus";
ranges = <0x80000000 0x0 0x70000000 0x10000000>;
pcie-ep@5f010000 {
reg = <0x80000000 0x10000000>;
reg-names ="addr_space";
...
};
...
};
In the diagram above, CPU writes data to outbound window address
0x7000_0000, and the bus fabric maps it to 0x8000_0000. The ATU uses
bus address 0x8000_0000 as input address and maps to some PCI address
dynamically allocated by a PCI device driver on the host side.
The pcie-ep@5f010000 'reg[addr_space]' is the parent bus address, which is
the input of PCIe controller, including the ATU.
Set parent_bus_offset, the offset from the CPU address to the PCIe
controller input address using dw_pcie_init_parent_bus_offset(). The
parent_bus_offset is not used yet, so no functional change intended.
[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20250315201548.858189-11-helgaas@kernel.org
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The 'ranges' property of a PCI controller's parent can indicate address
translation information. Most system use 1:1 map between CPU physical and
PCI controller input addresses.
But some hardware, like i.MX8QXP, doesn't use 1:1 map. See below diagram:
┌─────────┐ ┌────────────┐
┌─────┐ │ │ IA: 0x8ff8_0000 │ │
│ CPU ├───►│ ┌────►├─────────────────┐ │ PCI │
└─────┘ │ │ │ IA: 0x8ff0_0000 │ │ │
CPU Addr │ │ ┌─►├─────────────┐ │ │ Controller │
0x7ff8_0000─┼───┘ │ │ │ │ │ │
│ │ │ │ │ │ │ PCI Addr
0x7ff0_0000─┼──────┘ │ │ └──► IOSpace ─┼────────────►
│ │ │ │ │ 0
0x7000_0000─┼────────►├─────────┐ │ │ │
└─────────┘ │ └──────► CfgSpace ─┼────────────►
Bus Fabric │ │ │ 0
│ │ │
└──────────► MemSpace ─┼────────────►
IA: 0x8000_0000 │ │ 0x8000_0000
└────────────┘
bus@5f000000 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x80000000 0x0 0x70000000 0x10000000>;
pcie@5f010000 {
compatible = "fsl,imx8q-pcie";
reg = <0x5f010000 0x10000>, <0x8ff00000 0x80000>;
reg-names = "dbi", "config";
...
};
};
Intermediate address (IA) here means the PCIe controller input address.
The pcie@5f010000 'reg[config]' address is the parent bus (PCIe controller
input) address of CfgSpace.
The ATU in MemSpace is not explicitly described via devicetree, so we
assume the offset from CPU address to intermediate MemSpace address is the
same as that for CfgSpace.
We could use bus@5f000000 'ranges' for the same purpose.
Set parent_bus_offset using dw_pcie_init_parent_bus_offset(). The
parent_bus_offset is not used yet, so no functional change intended.
Link: https://lore.kernel.org/r/20250315201548.858189-8-helgaas@kernel.org
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
dw_pcie_parent_bus_offset() looks up the parent bus address of a PCI
controller 'reg' property in devicetree. If implemented, .cpu_addr_fixup()
is a hard-coded way to get the parent bus address corresponding to a CPU
physical address.
Add debug code to compare the address from .cpu_addr_fixup() with the
address from devicetree. If they match, warn that .cpu_addr_fixup() is
redundant and should be removed; if they differ, warn that something is
wrong with the devicetree.
If .cpu_addr_fixup() is not implemented, the parent bus address should be
identical to the CPU physical address because we previously ignored the
parent bus address from devicetree. If the devicetree has a different
parent bus address, warn about it being broken.
[bhelgaas: split debug to separate patch for easier future revert, commit
log]
Link: https://lore.kernel.org/r/20250315201548.858189-7-helgaas@kernel.org
Signed-off-by: Frank Li <Frank.Li@nxp.com>
[bhelgaas: squash Ioana Ciornei <ioana.ciornei@nxp.com> fix for NULL
pointer deref when driver doesn't supply dw_pcie_ops, e.g., layerscape-pcie
https://lore.kernel.org/r/20250319134339.3114817-1-ioana.ciornei@nxp.com]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Return the offset from CPU physical address to the parent bus address of
the specified element of the devicetree 'reg' property.
[bhelgaas: cpu_phy_addr -> cpu_phys_addr, return offset, split
.cpu_addr_fixup() checking and debug to separate patch]
Link: https://lore.kernel.org/r/20250315201548.858189-6-helgaas@kernel.org
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Move devm_pci_alloc_host_bridge() to the beginning of dw_pcie_host_init().
devm_pci_alloc_host_bridge() is generic code that doesn't depend on any DWC
resource, so moving it earlier keeps all the subsequent devicetree-related
code together.
[bhelgaas: reorder earlier in series]
Link: https://lore.kernel.org/r/20250315201548.858189-4-helgaas@kernel.org
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Rename 'cpu_addr' to 'parent_bus_addr' in the DesignWare ATU configuration.
The ATU translates parent bus addresses to PCI addresses, which are often
the same as CPU addresses but can differ in systems where the bus fabric
translates addresses before passing them to the PCIe controller. This
renaming clarifies the purpose and avoids confusion.
Link: https://lore.kernel.org/r/20250315201548.858189-3-helgaas@kernel.org
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The msg_res region translates writes into PCIe Message TLPs. Previously we
mapped this region using atu.cpu_addr, the input address programmed into
the ATU.
"cpu_addr" is a misnomer because when a bus fabric translates addresses
between the CPU and the ATU, the ATU input address is different from the
CPU address. A future patch will rename "cpu_addr" and correct the value
to be the ATU input address instead of the CPU physical address.
Map the msg_res region before writing to it using the msg_res resource
start, a CPU physical address.
Link: https://lore.kernel.org/r/20250315201548.858189-2-helgaas@kernel.org
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Instead of testing the controller register address to distinguish
controller 1 from controller 0 on i.MX8MQ platforms, use the PCI domain
number, which comes from the devicetree 'linux,pci-domain' property.
All relevant devicetrees should already supply 'linux,pci-domain', which
was added by c0b70f05c8 ("arm64: dts: imx8mq: use_dt_domains for pci
node").
Instead of being set directly in imx_pcie_probe(), pci->dbi_base will be
set by the DWC core in dw_pcie_get_resources().
No functional changes intended.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250226024256.1678103-3-hongxing.zhu@nxp.com
When running the RK3588 in Endpoint mode, with an Intel host with IOMMU
enabled, the host side prints:
DMAR: VT-d detected Invalidation Time-out Error: SID 0
When running the RK3588 in Endpoint mode, with an AMD host with IOMMU
enabled, the host side prints:
iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT device=63:00.0 address=0x42b5b01a0]
Rockchip has confirmed that the ATS support for RK3588 only works when
running the PCIe controller in Root Complex (RC) mode, see:
https://lore.kernel.org/linux-pci/93cdce39-1ae6-4939-a3fc-db10be7564e5@rock-chips.com
Usually, to handle these issues, we add a quirk for the PCI vendor and
device ID in drivers/pci/quirks.c with quirk_no_ats(). That is because
we cannot usually modify the capabilities on the EP side. In this case,
we can modify the capabilities on the EP side.
Thus, hide the broken ATS capability on RK3588 when running in EP mode.
That way, we don't need any quirk on the host side, and we see no errors
on the host side, and we can run pci_endpoint_test successfully, with
the IOMMU enabled on the host side.
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
[kwilczynski: commit log, tidy up code comments and error message]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20250310094826.842681-6-cassel@kernel.org
Looking at section "11.4.4.29 USP_PCIE_RESBAR Registers Summary" in the
Technical Reference Manual (TRM) for RK3588, we can see that none of the
BARs are Fixed BARs, but actually Resizable BARs.
I couldn't find any reference in the TRM for RK3568, but looking at the
downstream PCIe endpoint driver, both RK3568 and RK3588 are treated as
the same, so the BARs on RK3568 must also be Resizable BARs.
Now when we actually have support for Resizable BARs, let's configure
these BARs as such.
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Link: https://lore.kernel.org/r/20250131182949.465530-16-cassel@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
The support for a specific iATU alignment was added in
commit 2a9a801620 ("PCI: endpoint: Add support to specify alignment for
buffers allocated to BARs").
This commit specifically mentions both that the alignment by each DWC
based EP driver should match CX_ATU_MIN_REGION_SIZE, and that AM65x
specifically has a 64 KB alignment.
This also matches the CX_ATU_MIN_REGION_SIZE value specified in the
section "12.2.2.4.7 PCIe Subsystem Address Translation" of the Technical
Reference Manual (TRM) for AM65x:
https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf
This higher value, 1 MB, was obviously an ugly hack used to be able to
handle Resizable BARs which have a minimum size of 1 MB.
Now when we actually have support for Resizable BARs, let's configure the
iATU alignment requirement to the actual requirement.
(BARs described as Resizable will still get aligned to 1 MB.)
Cc: stable+noautosel@kernel.org # Depends on PCI endpoint Resizable BARs series
Fixes: 23284ad677 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms")
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20250131182949.465530-15-cassel@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
The DWC databook specifies three different BARn_SIZING_SCHEME_N as:
- Fixed Mask (0)
- Programmable Mask (1)
- Resizable BAR (2)
Each of these sizing schemes have different instructions for how to
initialize the BAR.
The DWC driver currently does not support resizable BARs.
Instead, in order to somewhat support resizable BARs, the DWC EP driver
currently has an ugly hack that force sets a resizable BAR to 1 MB, if
such a BAR is detected.
Additionally, this hack only works if the DWC glue driver also has lied
in their EPC features, and claimed that the resizable BAR is a 1 MB fixed
size BAR.
This is unintuitive (as you somehow need to know that you need to lie in
your EPC features), but other than that it is overly restrictive, since a
resizable BAR is capable of supporting sizes different than 1 MB.
Add proper support for resizable BARs in the DWC EP driver.
Note that the pci_epc_set_bar() API takes a struct pci_epf_bar which tells
the EPC driver how it wants to configure the BAR.
struct pci_epf_bar only has a single size struct member.
This means that an EPC driver will only be able to set a single supported
size. This is perfectly fine, as we do not need the complexity of allowing
a host to change the size of the BAR. If someone ever wants to support
resizing a resizable BAR, the pci_epc_set_bar() API can be extended in the
future.
With these changes, we allow an EPF driver to configure the size of
Resizable BARs, rather than forcing them to a 1 MB size.
This means that an EPC driver does not need to lie in EPC features, and an
EPF driver will be able to set an arbitrary size (not be forced to a 1 MB
size), just like BAR_PROGRAMMABLE.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20250131182949.465530-13-cassel@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
