| Age | Commit message (Collapse) | Author |
|---|
|
R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025 page 585
Figure 9.3.2 Software Reset flow (B) indicates that for peripherals in HSC
domain, after reset has been asserted by writing a matching reset bit into
register SRCR, it is mandatory to wait 1ms.
Because it is the controller driver which can determine whether or not the
controller is in HSC domain based on its compatible string, add the missing
delay in the controller driver.
This 1ms delay is documented on R-Car V4H and V4M; it is currently unclear
whether S4 is affected as well. This patch does apply the extra delay on
R-Car S4 as well.
Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode")
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[mani: added the missing r-b tag from Krzysztof]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Link: https://patch.msgid.link/20250919134644.208098-1-marek.vasut+renesas@mailbox.org
|
|
Designware databook r5.20a, sec 3.10.10.3 documents the 'CFG Shift Feature'
of the internal Address Translation Unit (iATU). When this feature is
enabled, it shifts/maps the BDF contained in the bits [27:12] of the target
address in MEM TLP to become BDF of the CFG TLP. This essentially
implements the Enhanced Configuration Address Mapping (ECAM) mechanism as
defined in PCIe r6.0, sec 7.2.2.
Currently, the driver is not making use of this CFG shift feature, thereby
creating the iATU outbound map for each config access to the devices,
causing latency and wasting CPU cycles.
So to avoid this, configure the controller to enable CFG shift feature by
enabling the 'CFG Shift' bit of the 'iATU Control 2 Register'.
As a result of enabling CFG shift (ECAM), there is no longer a need to map
the DBI register space separately as the DBI region falls under the
'config' space used for ECAM (as DBI is used to access the Root Port).
For enabling ECAM using CFG shift, the platform has to satisfy following
requirements:
1. Size of the 'config' memory space to be used as ECAM memory should be
able to accommodate the number of buses defined in the 'bus-range'
property of the host bridge DT node.
2. The 'config' memory space should be 256 MiB aligned. This requirement
comes from PCIe r6.0, sec 7.2.2, which says the base address of ECAM
memory should be aligned to a 2^(n+20) byte address boundary. For the
DWC cores, n is 8, so this results in 2^28 byte alignment requirement.
It should be noted that some DWC vendor glue drivers like pcie-al may use
their own ECAM mechanism. For those controllers, set
'dw_pcie_rp::native_ecam' flag and skip enabling the CFG Shift feature in
the DWC core.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
[mani: code split, reworded subject/description, comment, native_ecam flag]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250923-controller-dwc-ecam-v10-4-e84390ba75fa@kernel.org
|
|
To support the DWC ECAM mechanism, prepare the driver by performing below
configurations:
1. Since the ELBI region will be covered by the ECAM 'config' space,
override the 'elbi_base' with the address derived from 'dbi_base' and
the offset from PARF_SLV_DBI_ELBI register.
2. Block the transactions from the host bridge to devices other than Root
Port on the root bus to return all F's. This is required when the 'CFG
Shift Feature' of iATU is enabled.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
[mani: code split, reworded subject/description and comments]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250923-controller-dwc-ecam-v10-3-e84390ba75fa@kernel.org
|
|
Shift Feature'
In order to enable PCIe ECAM mechanism in DWC driver as per the 'CFG Shift
Feature' documented in Designware databook r5.20a, sec 3.10.10.3, prepare
the driver to handle the one time iATU setup and creating ECAM window.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
[mani: splitted the preparatory code into a separate commit for bisectability]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250923-controller-dwc-ecam-v10-2-e84390ba75fa@kernel.org
|
|
External Local Bus Interface (ELBI) is an optional register space for all
DWC IPs containing the vendor specific registers. There is no need for the
vendor glue drivers to fetch and map the ELBI region separately.
Hence, optionally fetch and map the resource from DT in the DWC core. This
also warrants dropping the corresponding code from glue drivers. Hence,
drop the ELBI resource fetch and map logic from glue drivers and convert
them to use 'dw_pci::elbi_base'.
Note that the pcie-qcom-ep driver used devm_pci_remap_cfg_resource() to map
the ELBI resource previously. But it was a mistake since
devm_pci_remap_cfg_resource() should only be used for mapping the PCIe
config space region as it maps the region as Non-Posted. As ELBI is used to
hold vendor specific registers, there is no need to map the region as
Non-Posted. With this conversion, the region will get mapped as normal MMIO
memory.
Suggested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
[mani: removed elbi override, converted glue drivers and reworded description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250923-controller-dwc-ecam-v10-1-e84390ba75fa@kernel.org
|
|
The return value from tegra_bpmp_transfer() indicates the success or
failure of the IPC transaction with BPMP. If the transaction succeeded, we
also need to check the actual command's result code.
If we don't have error handling for tegra_bpmp_transfer(), we will set the
pcie->ep_state to EP_STATE_ENABLED even when the tegra_bpmp_transfer()
command fails. Thus, the pcie->ep_state will get out of sync with reality,
and any further PERST# assert + deassert will be a no-op and will not
trigger the hardware initialization sequence.
This is because pex_ep_event_pex_rst_deassert() checks the current
pcie->ep_state, and does nothing if the current state is already
EP_STATE_ENABLED.
Thus, it is important to have error handling for tegra_bpmp_transfer(),
such that the pcie->ep_state can not get out of sync with reality, so that
we will try to initialize the hardware not only during the first PERST#
assert + deassert, but also during any succeeding PERST# assert + deassert.
One example where this fix is needed is when using a rock5b as host.
During the initial PERST# assert + deassert (triggered by the bootloader on
the rock5b) pex_ep_event_pex_rst_deassert() will get called, but for some
unknown reason, the tegra_bpmp_transfer() call to initialize the PHY fails.
Once Linux has been loaded on the rock5b, the PCIe driver will once again
assert + deassert PERST#. However, without tegra_bpmp_transfer() error
handling, this second PERST# assert + deassert will not trigger the
hardware initialization sequence.
With tegra_bpmp_transfer() error handling, the second PERST# assert +
deassert will once again trigger the hardware to be initialized and this
time the tegra_bpmp_transfer() succeeds.
Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194")
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
[cassel: improve commit log]
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250922140822.519796-8-cassel@kernel.org
|
|
Tegra already defines all BARs except BAR0 as BAR_RESERVED. This is
sufficient for pci-epf-test to not allocate backing memory and to not call
set_bar() for those BARs. However, marking a BAR as BAR_RESERVED does not
mean that the BAR gets disabled.
The host side driver, pci_endpoint_test, simply does an ioremap for all
enabled BARs and will run tests against all enabled BARs, so it will run
tests against the BARs marked as BAR_RESERVED.
After running the BAR tests (which will write to all enabled BARs), the
inbound address translation is broken. This is because the tegra controller
exposes the ATU Port Logic Structure in BAR4, so when BAR4 is written, the
inbound address translation settings get overwritten.
To avoid this, implement the dw_pcie_ep_ops .init() callback and start off
by disabling all BARs (pci-epf-test will later enable/configure BARs that
are not defined as BAR_RESERVED).
This matches the behavior of other PCIe endpoint drivers: dra7xx, imx6,
layerscape-ep, artpec6, dw-rockchip, qcom-ep, rcar-gen4, and uniphier-ep.
With this, the PCI endpoint kselftest test case CONSECUTIVE_BAR_TEST (which
was specifically made to detect address translation issues) passes.
Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194")
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250922140822.519796-7-cassel@kernel.org
|
|
Since the driver supports MSI, set the flag to true. This helps
pci_endpoint_test to use the optimal IRQ type when using
PCITEST_IRQ_TYPE_AUTO.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
[mani: splitted this change from the bug fix]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250922140822.519796-6-cassel@kernel.org
|
|
The pci_epc_raise_irq() supplies a MSI or MSI-X interrupt number in range
(1-N), as per the pci_epc_raise_irq() kdoc, where N is 32 for MSI.
But tegra_pcie_ep_raise_msi_irq() incorrectly uses the interrupt number as
the MSI vector. This causes wrong MSI vector to be triggered, leading to
the failure of PCI endpoint Kselftest MSI_TEST test case.
To fix this issue, convert the interrupt number to MSI vector.
Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194")
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250922140822.519796-6-cassel@kernel.org
|
|
Since the PCI subsystem has started enabling all ASPM states for all
devicetree based platforms, the ASPM enablement code from this driver can
now be dropped.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250922-pci-dt-aspm-v2-2-2a65cf84e326@oss.qualcomm.com
|
|
During PERST# assertion tegra_pcie_bpmp_set_pll_state() is currently
called twice.
pex_ep_event_pex_rst_assert() should do the opposite of
pex_ep_event_pex_rst_deassert(), so it is obvious that the duplicate
tegra_pcie_bpmp_set_pll_state() is a mistake, and that the duplicate
tegra_pcie_bpmp_set_pll_state() call should instead be a call to
tegra_pcie_bpmp_set_ctrl_state().
With this, the uninitialization sequence also matches that of
tegra_pcie_unconfig_controller().
Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support")
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
[cassel: improve commit log]
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Link: https://patch.msgid.link/20250911093021.1454385-2-cassel@kernel.org
[mani: added Fixes tag]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
|
|
DT binding allows specifying 'phy' and 'reset' properties in both host
bridge and Root Port nodes, though specifying in the host bridge node is
marked as deprecated. Still, the pcie-qcom driver should support both
combinations for maintaining the DT backwards compatibility. For this
purpose, the driver is holding the relevant pointers of these properties in
two structs: struct qcom_pcie_port and struct qcom_pcie.
However, this causes confusion and increases the driver complexity. Hence,
move the pointers from struct qcom_pcie to struct qcom_pcie_port. As a
result, even if these properties are specified in the host bridge node,
the pointers will be stored in struct qcom_pcie_port as if the properties
are specified in a single Root Port node. This logic simplifies the driver
a lot.
Suggested-by: Bjorn Helgaas <helgaas@kernel.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250912-pci-pwrctrl-perst-v3-2-3c0ac62b032c@oss.qualcomm.com
|
|
dw_pcie_edma_irq_verify() already parses device tree for either "dma" (if
there is a single IRQ for all DMA channels) or "dmaX" (if there is one IRQ
per DMA channel), and initializes dma.nr_irqs accordingly.
Additionally, the probing of the eDMA driver will fail if neither "dma"
nor "dmaX" is defined in the device tree.
Therefore there is no need for a glue driver to specify edma.nr_irqs, so
remove the redundant edma.nr_irqs initialization.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: fix typos]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250908165914.547002-4-cassel@kernel.org
|
|
dw_pcie_edma_irq_verify() is supposed to verify the eDMA IRQs in devicetree
by fetching them using either 'dma' or 'dmaX' IRQ names. Former is used
when the platform uses a single IRQ for all eDMA channels and latter is
used when the platform uses separate IRQ per channel. But currently,
dw_pcie_edma_irq_verify() bails out early if edma::nr_irqs is 1, i.e., when
a single IRQ is used. This gives an impression that the driver could work
with any single IRQ in devicetree, not necessarily with name 'dma'.
But dw_pcie_edma_irq_vector(), which actually requests the IRQ, does
require the single IRQ to be named as 'dma'. So this creates inconsistency
between dw_pcie_edma_irq_verify() and dw_pcie_edma_irq_vector().
Thus, to fix this inconsistency, make sure dw_pcie_edma_irq_verify() also
verifies the single IRQ name by removing the bail out code.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
[mani: reworded subject and description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: fix typos]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250908165914.547002-3-cassel@kernel.org
|
|
When the 3.3Vaux supply is present, fetch it at the probe time and keep it
enabled for the entire PCIe controller lifecycle so that the link can enter
L2 state and the devices can signal wakeup using either Beacon or WAKE#
mechanisms.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
[mani: reworded the subject, description and error message]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20250820022328.2143374-1-hongxing.zhu@nxp.com
|
|
Correct a typo in the macro names GEN3_EQ_FMDC_MAX_PRE_CURSOR_DELTA and
GEN3_EQ_FMDC_MAX_POST_CURSOR_DELTA.
Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
[mani: reworded description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20250904065225.1762793-3-ziyue.zhang@oss.qualcomm.com
|
|
Add lane equalization setting for 8.0 GT/s and 32.0 GT/s to enhance link
stability and avoid AER Correctable Errors reported on some platforms
(eg. SA8775P).
8.0 GT/s, 16.0 GT/s and 32.0 GT/s require the same equalization setting.
This setting is programmed into a group of shadow registers, which can be
switched to configure equalization for different speeds by writing 00b,
01b and 10b to `RATE_SHADOW_SEL`.
Hence, program equalization registers in a loop using link speed as index,
so that equalization setting can be programmed for 8.0 GT/s, 16.0 GT/s
and 32.0 GT/s.
Fixes: 489f14be0e0a ("arm64: dts: qcom: sa8775p: Add pcie0 and pcie1 nodes")
Co-developed-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
[mani: wrapped the warning to fit 100 columns, used post-increment for loop]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250904065225.1762793-2-ziyue.zhang@oss.qualcomm.com
|
|
The era of hand-rolled HIWORD_UPDATE macros is over.
Like many other Rockchip drivers, pcie-dw-rockchip brings with it its
very own flavour of HIWORD_UPDATE. It's occasionally used without a
constant mask, which complicates matters. HIWORD_UPDATE_BIT is a
confusingly named addition, as it doesn't update the bit, it actually
sets all bits in the value to 1. HIWORD_DISABLE_BIT is similarly
confusing; it disables several bits at once by using the value as a mask
and the inverse of value as the value, and the "disabling only these"
effect comes from the hardware actually using the mask. The more obvious
approach would've been HIWORD_UPDATE(val, 0) in my opinion.
This is part of the motivation why this patch uses hw_bitfield.h's
FIELD_PREP_WM16 instead, where possible. FIELD_PREP_WM16 requires a
constant bit mask, which isn't possible where the irq number is used to
generate a bit mask. For that purpose, we replace it with a more robust
macro than what was there but that should also bring close to zero
runtime overhead: we actually mask the IRQ number to make sure we're not
writing garbage.
For the remaining bits, there also are some caveats. For starters, the
PCIE_CLIENT_ENABLE_LTSSM and PCIE_CLIENT_DISABLE_LTSSM were named in a
manner that isn't quite truthful to what they do. Their modification
actually spans not just the LTSSM bit but also another bit, flipping
only the LTSSM one, but keeping the other (which according to the TRM
has a reset value of 0) always enabled. This other bit is reserved as of
the IP version RK3588 uses at least, and I have my doubts as to whether
it was meant to be set, and whether it was meant to be set in that code
path. Either way, it's confusing.
Replace it with just writing either 1 or 0 to the LTSSM bit, using the
new FIELD_PREP_WM16 macro from hw_bitfield.h, which grants us the
benefit of better compile-time error checking.
The change of no longer setting the reserved bit doesn't appear to
change the behaviour on RK3568 in RC mode, where it's not marked as
reserved.
PCIE_CLIENT_RC_MODE/PCIE_CLIENT_EP_MODE was another field that wasn't
super clear on what the bit field modification actually is. As far as I
can tell, switching to RC mode doesn't actually write the correct value
to the field if any of its bits have been set previously, as it only
updates one bit of a 4 bit field.
Replace it by actually writing the full values to the field, using the
new FIELD_PREP_WM16 macro, which grants us the benefit of better
compile-time error checking.
This patch was tested on RK3588 (PCIe3 x4 controller), RK3576 (PCIe2 x1
controller) and RK3568 (PCIe x2 controller), all in RC mode.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
|
|
The qcom_pcie_parse_ports() function currently iterates over all available
child nodes of the PCIe controller's device tree node. This includes
unrelated nodes such as OPP (Operating Performance Points) nodes, which do
not contain the expected 'reset' and 'phy' properties. As a result, parsing
fails and the driver falls back to the legacy method of parsing the
controller node directly. However, this fallback also fails when properties
are shifted to the Root Port node, leading to probe failure.
Fix this by restricting the parsing logic to only consider child nodes with
device_type = "pci", which is the expected and required property for PCIe
bridge nodes as per the pci-bus-common.yaml dtschema.
Fixes: a2fbecdbbb9d ("PCI: qcom: Add support for parsing the new Root Port binding")
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
[mani: reworded subject and description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250826-pakala-v3-3-721627bd5bb0@oss.qualcomm.com
|
|
Replace calls of devm_kzalloc() with devm_kcalloc() in ks_pcie_probe().
As noted in the kernel documentation [1], open-coded multiplication in
allocator arguments is discouraged because it can lead to integer
overflow.
Using devm_kcalloc() provides built-in overflow protection, making the
memory allocation safer when calculating the allocation size compared
to explicit multiplication.
[1]: https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20250819131235.152967-1-rongqianfeng@vivo.com
|
|
The PCI core now provides generic PCI_FIND_NEXT_CAP() macros to search for
PCI capabilities, using config accessors we supply.
Use them in the DWC EP driver to implement dw_pcie_ep_find_capability()
instead of duplicating the algorithm.
Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250819145828.438541-1-18255117159@163.com
|
|
The PCI core now provides generic PCI_FIND_NEXT_CAP() and
PCI_FIND_NEXT_EXT_CAP() macros to search for PCI capabilities, using
config accessors we supply.
Use them in the DWC driver to implement dw_pcie_find_capability() and
dw_pcie_find_ext_capability() instead of duplicating the algorithm.
Signed-off-by: Hans Zhang <18255117159@163.com>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250813144529.303548-5-18255117159@163.com
|
|
struct pci_epc_features has static storage duration, so all struct members
are zero initialized implicitly. Thus, remove explicit zero initialization
for features that are *not* supported so we don't have to touch existing
drivers as new features are added.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
[bhelgaas: squash together, expand commit log rationale]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> #rcar-ep, rcar-gen4
Link: https://patch.msgid.link/20250814152119.1562063-16-cassel@kernel.org
Link: https://patch.msgid.link/20250814152119.1562063-17-cassel@kernel.org
Link: https://patch.msgid.link/20250814152119.1562063-18-cassel@kernel.org
Link: https://patch.msgid.link/20250814152119.1562063-19-cassel@kernel.org
Link: https://patch.msgid.link/20250814152119.1562063-20-cassel@kernel.org
Link: https://patch.msgid.link/20250814152119.1562063-21-cassel@kernel.org
Link: https://patch.msgid.link/20250814152119.1562063-22-cassel@kernel.org
Link: https://patch.msgid.link/20250814152119.1562063-23-cassel@kernel.org
Link: https://patch.msgid.link/20250814152119.1562063-24-cassel@kernel.org
Link: https://patch.msgid.link/20250814152119.1562063-25-cassel@kernel.org
Link: https://patch.msgid.link/20250814152119.1562063-26-cassel@kernel.org
Link: https://patch.msgid.link/20250814152119.1562063-27-cassel@kernel.org
Link: https://patch.msgid.link/20250814152119.1562063-28-cassel@kernel.org
|
|
Add support for handling the AMD Versal Gen 2 MDB PCIe Root Port PERST#
signal via a GPIO by parsing the new PCIe bridge node to acquire the
reset GPIO. If the bridge node is not found, fall back to acquiring it
from the PCIe host bridge node.
As part of this, update the interrupt controller node parsing to use
of_get_child_by_name() instead of of_get_next_child(), since the PCIe
host bridge node now has multiple children. This ensures the correct
node is selected during initialization.
Signed-off-by: Sai Krishna Musham <sai.krishna.musham@amd.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250807074019.811672-3-sai.krishna.musham@amd.com
|
|
R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025 page 4581
Figure 104.3b Initial Setting of PCIEC(example), middle of the figure
indicates that fourth write into register 0x148 [2:0] is 0x3 or
GENMASK(1, 0). The current code writes GENMASK(11, 0) which is a typo. Fix
the typo.
Fixes: faf5a975ee3b ("PCI: rcar-gen4: Add support for R-Car V4H")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250806192548.133140-1-marek.vasut+renesas@mailbox.org
|
|
Select the pwrctrl driver, which is utilized to manage the power supplies
of the devices connected to the standard PCI slots conforming to
specification like PCIe CEM. This ensures that the voltage rails of the
standard PCI slots on some platforms eg. X1E80100-QCP can be correctly
turned on/off if they are described in PCIe Root Port device tree node.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com>
[mani: reworded subject and description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250722091151.1423332-2-quic_wenbyao@quicinc.com
|
|
- Add DT binding and driver for Sophgo SG2044 PCIe controller driver in
Root Complex mode (Inochi Amaoto)
* pci/controller/sophgo:
PCI: dwc: Add Sophgo SG2044 PCIe controller driver in Root Complex mode
dt-bindings: pci: Add Sophgo SG2044 PCIe host
|
|
- Export DWC MSI controller related APIs for use by upcoming DWC-based ECAM
implementation (Mayank Rana)
- Rename gen_pci_init() to pci_host_common_ecam_create() and export for use
by controller drivers (Mayank Rana)
- Add DT binding and driver support for SA8255p, which supports ECAM for
Configuration Space access (Mayank Rana)
- Update DT binding and driver to describe PHYs and per-Root Port resets in
a Root Port stanza and deprecate describing them in the host bridge; this
makes it possible to support multiple Root Ports in the future (Krishna
Chaitanya Chundru)
* pci/controller/qcom:
PCI: qcom: Add support for parsing the new Root Port binding
dt-bindings: PCI: qcom: Move PHY & reset GPIO to Root Port node
PCI: qcom: Add support for Qualcomm SA8255p based PCIe Root Complex
dt-bindings: PCI: qcom,pcie-sa8255p: Document ECAM compliant PCIe root complex
PCI: host-generic: Rename and export gen_pci_init() for PCIe controller drivers
PCI: dwc: Export DWC MSI controller related APIs
|
|
- Add IMX8MQ_EP third 64-bit BAR in epc_features (Richard Zhu)
- Add IMX8MM_EP and IMX8MP_EP fixed 256-byte BAR 4 in epc_features (Richard
Zhu)
- Factor imx_pcie_add_lut_by_rid() out of imx_pcie_enable_device() for use
by LUT configuration (Frank Li)
- Configure LUT for MSI/IOMMU in Endpoint mode so Root Complex can trigger
doorbel on Endpoint (Frank Li)
- Remove apps_reset (LTSSM_EN) from imx_pcie_{assert,deassert}_core_reset(),
which fixes a hotplug regression on i.MX8MM (Richard Zhu)
- Delay Endpoint link start until configfs 'start' written (Richard Zhu)
* pci/controller/imx6:
PCI: imx6: Delay link start until configfs 'start' written
PCI: imx6: Remove apps_reset toggling from imx_pcie_{assert/deassert}_core_reset
PCI: imx6: Add LUT configuration for MSI/IOMMU in Endpoint mode
PCI: imx6: Add helper function imx_pcie_add_lut_by_rid()
PCI: imx6: Add IMX8MM_EP and IMX8MP_EP fixed 256-byte BAR 4 in epc_features
PCI: imx6: Add IMX8MQ_EP third 64-bit BAR in epc_features
|
|
- Prevent race between link training and register update via DBI by
inhibiting link training after hot reset and link down (Wilfred Mallawa)
* pci/controller/dw-rockchip:
PCI: dw-rockchip: Delay link training after hot reset in EP mode
|
|
- Simplify debugfs 'return' statements (Hans Zhang)
- Make dw_pcie_ptm_ops static (Manivannan Sadhasivam)
* pci/controller/dwc:
PCI: dwc: Make dw_pcie_ptm_ops static
PCI: dwc: Simplify the return value of PTM debugfs functions returning bool
|
|
- Rename PCIE_RESET_CONFIG_DEVICE_WAIT_MS to PCIE_RESET_CONFIG_WAIT_MS (the
required delay before sending config requests after a reset) (Niklas
Cassel)
- PCIE_T_RRS_READY_MS and PCIE_RESET_CONFIG_WAIT_MS were two names for the
same delay; replace PCIE_T_RRS_READY_MS with PCIE_RESET_CONFIG_WAIT_MS
and remove PCIE_T_RRS_READY_MS (Niklas Cassel)
- Add required PCIE_RESET_CONFIG_WAIT_MS delay after Link up IRQ to
dw-rockchip, qcom (Niklas Cassel)
- Add required PCIE_RESET_CONFIG_WAIT_MS after waiting for Link up on
Ports that support > 5.0 GT/s in dwc core (Niklas Cassel)
- Move LINK_WAIT_SLEEP_MS and LINK_WAIT_MAX_RETRIES to pci.h and prefix
with 'PCIE_' for potential sharing across drivers (Niklas Cassel)
* pci/controller/linkup-fix:
PCI: Move link up wait time and max retries macros to pci.h
PCI: dwc: Ensure that dw_pcie_wait_for_link() waits 100 ms after link up
PCI: qcom: Wait PCIE_RESET_CONFIG_WAIT_MS after link-up IRQ
PCI: dw-rockchip: Wait PCIE_RESET_CONFIG_WAIT_MS after link-up IRQ
PCI: rockchip-host: Use macro PCIE_RESET_CONFIG_WAIT_MS
PCI: Rename PCIE_RESET_CONFIG_DEVICE_WAIT_MS to PCIE_RESET_CONFIG_WAIT_MS
|
|
Add driver support for DesignWare based PCIe controller in SG2044 SoC. The
driver currently supports the Root Complex mode.
Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
[mani: renamed the driver to 'pcie-sophgo.c' and Kconfig fix]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: whitespace]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250504004420.202685-3-inochiama@gmail.com
|
|
Switch to msi_create_parent_irq_domain() from pci_msi_create_irq_domain()
which was using legacy MSI domain setup.
Signed-off-by: Nam Cao <namcao@linutronix.de>
[mani: reworded commit message]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: rebase on dev_fwnode() conversion]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://patch.msgid.link/04d4a96046490e50139826c16423954e033cdf89.1750858083.git.namcao@linutronix.de
|
|
All irq_domain functions now accept fwnode instead of of_node. But many
PCI controllers still extract dev to of_node and then of_node to fwnode.
Instead, clean this up and simply use the dev_fwnode() helper to extract
fwnode directly from dev. Internally, it still does dev => of_node =>
fwnode steps, but it's now hidden from the users.
In the case of altera, this also removes an unused 'node' variable that is
only used when CONFIG_OF is enabled:
drivers/pci/controller/pcie-altera.c: In function 'altera_pcie_init_irq_domain':
drivers/pci/controller/pcie-altera.c:855:29: error: unused variable 'node' [-Werror=unused-variable]
855 | struct device_node *node = dev->of_node;
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de> # altera
[bhelgaas: squash together, rebase to precede msi-parent]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250521163329.2137973-1-arnd@kernel.org
Link: https://patch.msgid.link/20250611104348.192092-16-jirislaby@kernel.org
Link: https://patch.msgid.link/20250723065907.1841758-1-jirislaby@kernel.org
|
|
According to Documentation/PCI/endpoint/pci-endpoint-cfs.rst, the Endpoint
controller (EPC) should only start the link when userspace writes '1' to
the '/sys/kernel/config/pci_ep/controllers/<EPC>/start' attribute, which
ultimately results in calling imx_pcie_start_link() via
pci_epc_start_store().
To align with the documented behavior, do not start the link automatically
when adding the EP controller.
Fixes: 75c2f26da03f ("PCI: imx6: Add i.MX PCIe EP mode support")
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
[mani: reworded commit subject and description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250709033722.2924372-3-hongxing.zhu@nxp.com
|
|
apps_reset corresponds to LTSSM_EN in i.MX7, i.MX8MQ, i.MX8MM and i.MX8MP
platforms. Since assertion/de-assertion of apps_reset is done in
imx_pcie_ltssm_enable() and imx_pcie_ltssm_disable(), remove it from
imx_pcie_assert_core_reset() and imx_pcie_deassert_core_reset().
This also fixes a failure in enumerating the PI7C9X2G608GP (hotplug) chip
reliably on i.MX8MM, as reported by Tim.
It should be noted that only i.MX7D, i.MX8MQ, i.MX8MM, and i.MX8MP
platforms have the apps_reset logic, so this change doesn't have any effect
on other platforms.
Fixes: ef61c7d8d032 ("PCI: imx6: Deassert apps_reset in imx_pcie_deassert_core_reset()")
Reported-by: Tim Harvey <tharvey@gateworks.com>
Closes: https://lore.kernel.org/all/CAJ+vNU3ohR2YKTwC4xoYrc1z-neDoH2TTZcMHDy+poj9=jSy+w@mail.gmail.com/
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
[mani: reworded commit subject and description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Tim Harvey <tharvey@gateworks.com> # imx8mp-venice-gw74xx (i.MX8MP + hotplug capable switch)
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250709033722.2924372-2-hongxing.zhu@nxp.com
|
|
Add LUT entry for MSI/IOMMU in Endpoint mode by calling
imx_pcie_add_lut_by_rid() helper function. Since only one physical function
is supported in the Endpoint mode for now, '0' is passed as the Device ID.
This sets up a single LUT entry required for MSI/IOMMU.
The Endpoint function can operate without LUT configuration if neither
IOMMU nor MSI is used by the platform. This LUT configuration is used for
the EP doorbell feature by allowing the Root Complex to trigger the
doorbell on the Endpoint with the help of the Endpoint MSI controller.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
[mani: reworded the comments & commit message and dropped tested-by tag]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250710-ep-msi-v21-2-57683fc7fb25@nxp.com
|
|
Add helper function imx_pcie_add_lut_by_rid(), which will be used by the
upcoming LUT configuration for MSI/IOMMU in the Endpoint mode. No
functional change.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
[mani: reworded commit message and dropped tested-by tag]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250710-ep-msi-v21-1-57683fc7fb25@nxp.com
|
|
The DT binding has moved the PHY, PERST# properties to Root Port node from
the Host Bridge node. So add support for parsing the new binding. The new
binding uses 'reset-gpios' property for PERST#, hence parse the same
property in the driver instead of the legacy 'perst-gpios'.
To maintain DT backwards compatibility, fallback to the legacy method of
parsing the host bridge node if the properties are not present in the Root
Port node.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
[mani: refactored the root port parsing code, fixed a bug & commit message rewording]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250702-perst-v5-2-920b3d1f6ee1@qti.qualcomm.com
|
|
Add functionality to enable resource management (like clocks, regulators,
PHY) through firmware and enumerate ECAM compliant Root Complex on SA8255p
SoC, where the PCIe Root Complex is firmware managed and configured into
ECAM compliant mode.
Signed-off-by: Mayank Rana <mayank.rana@oss.qualcomm.com>
[mani: minor code cleanups and commit message rewording]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: add "ECAM" in comment]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250616224259.3549811-5-mayank.rana@oss.qualcomm.com
|
|
For IMX8MM_EP and IMX8MP_EP, add fixed 256-byte BAR 4 and reserved BAR 5
in imx8m_pcie_epc_features.
Fixes: 75c2f26da03f ("PCI: imx6: Add i.MX PCIe EP mode support")
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
[bhelgaas: add details in subject]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250708091003.2582846-3-hongxing.zhu@nxp.com
|
|
IMX8MQ_EP has three 64-bit BAR0/2/4 capable and programmable BARs. For
IMX8MQ_EP, use imx8q_pcie_epc_features (64-bit BARs 0, 2, 4) instead
of imx8m_pcie_epc_features (64-bit BARs 0, 2).
Fixes: 75c2f26da03f ("PCI: imx6: Add i.MX PCIe EP mode support")
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
[bhelgaas: add details in subject]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250708091003.2582846-2-hongxing.zhu@nxp.com
|
|
dw_pcie_ptm_ops is not used outside of this file, so make it static. This
also fixes the sparse warning:
drivers/pci/controller/dwc/pcie-designware-debugfs.c:868:27: warning: symbol 'dw_pcie_ptm_ops' was not declared. Should it be static?
Fixes: 852a1fdd34a8 ("PCI: dwc: Add debugfs support for PTM context")
Reported-by: Bjorn Helgaas <helgaas@kernel.org>
Closes: https://lore.kernel.org/linux-pci/20250617231210.GA1172093@bhelgaas
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250701120856.15839-1-mani@kernel.org
|
|
Export dw_pcie_msi_host_init(), dw_pcie_msi_init(), and dw_pcie_free_msi()
APIs to allow them to be reused by the upcoming DWC based ECAM driver
implementation. Also, move MSI IRQ related initialization code to
dw_pcie_msi_init(), as this code must be executed before dw_pcie_msi_init()
API can be used with ECAM driver.
Signed-off-by: Mayank Rana <mayank.rana@oss.qualcomm.com>
[mani: commit message rewording]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250616224259.3549811-2-mayank.rana@oss.qualcomm.com
|
|
Replace redundant ternary conditional expressions with direct boolean
returns in PTM debugfs functions. Specifically change this pattern:
return (condition) ? true : false;
to the simpler:
return condition;
Signed-off-by: Hans Zhang <18255117159@163.com>
[mani: subject rewording]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Link: https://patch.msgid.link/20250612161226.950937-1-18255117159@163.com
|
|
Move the LINK_WAIT_SLEEP_MS and LINK_WAIT_MAX_RETRIES macros to pci.h.
Prefix the macros with PCIE_ in order to avoid redefining these for
drivers that already have macros named like this.
No functional changes.
Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250625102347.1205584-15-cassel@kernel.org
|
|
As per PCIe r6.0, sec 6.6.1, a Downstream Port that supports Link speeds
greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link
training completes before sending a Configuration Request.
Add this delay in dw_pcie_wait_for_link(), after the link is reported as
up. The delay will only be performed in the success case where the link
came up.
DWC glue drivers that have a link up IRQ (drivers that set
use_linkup_irq = true) do not call dw_pcie_wait_for_link(), instead they
perform this delay in their threaded link up IRQ handler.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Link: https://patch.msgid.link/20250625102347.1205584-14-cassel@kernel.org
|
|
Per PCIe r6.0, sec 6.6.1, software must generally wait a minimum of
100ms (PCIE_RESET_CONFIG_WAIT_MS) after Link training completes before
sending a Configuration Request.
Prior to 36971d6c5a9a ("PCI: qcom: Don't wait for link if we can detect
Link Up"), qcom used dw_pcie_wait_for_link(), which waited between 0
and 90ms after the link came up before we enumerate the bus, and this
was apparently enough for most devices.
After 36971d6c5a9a, qcom_pcie_global_irq_thread() started enumeration
immediately when handling the link-up IRQ, and devices (e.g., Laszlo
Fiat's PLEXTOR PX-256M8PeGN NVMe SSD) may not be ready to handle config
requests yet.
Delay PCIE_RESET_CONFIG_WAIT_MS after the link-up IRQ before starting
enumeration.
Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver")
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Link: https://patch.msgid.link/20250625102347.1205584-13-cassel@kernel.org
|
|
Per PCIe r6.0, sec 6.6.1, software must generally wait a minimum of
100ms (PCIE_RESET_CONFIG_WAIT_MS) after Link training completes before
sending a Configuration Request.
Prior to ec9fd499b9c6 ("PCI: dw-rockchip: Don't wait for link since
we can detect Link Up"), dw-rockchip used dw_pcie_wait_for_link(),
which waited between 0 and 90ms after the link came up before we
enumerate the bus, and this was apparently enough for most devices.
After ec9fd499b9c6, rockchip_pcie_rc_sys_irq_thread() started
enumeration immediately when handling the link-up IRQ, and devices
(e.g., Laszlo Fiat's PLEXTOR PX-256M8PeGN NVMe SSD) may not be ready
to handle config requests yet.
Delay PCIE_RESET_CONFIG_WAIT_MS after the link-up IRQ before starting
enumeration.
Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver")
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Cc: Laszlo Fiat <laszlo.fiat@proton.me>
Link: https://patch.msgid.link/20250625102347.1205584-12-cassel@kernel.org
|
