From: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
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 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>
---
drivers/pci/controller/dwc/pcie-al.c | 1 +
drivers/pci/controller/dwc/pcie-designware-host.c | 32 +++++++++++++++++++++++
drivers/pci/controller/dwc/pcie-designware.h | 1 +
3 files changed, 34 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-al.c b/drivers/pci/controller/dwc/pcie-al.c
index 643115f74092d1c9319e9738db6e94b2752d30c4..345c281c74fefd2113233ef5461f96834b3765de 100644
--- a/drivers/pci/controller/dwc/pcie-al.c
+++ b/drivers/pci/controller/dwc/pcie-al.c
@@ -352,6 +352,7 @@ static int al_pcie_probe(struct platform_device *pdev)
return -ENOENT;
}
al_pcie->ecam_size = resource_size(ecam_res);
+ pci->pp.native_ecam = true;
controller_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
"controller");
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 94e0fe11a0b062d0f14e09fe586e20bde46a4266..20c9333bcb1c4812e2fd96047a49944574df1e6f 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -8,6 +8,7 @@
* Author: Jingoo Han <jg1.han@samsung.com>
*/
+#include <linux/align.h>
#include <linux/iopoll.h>
#include <linux/irqchip/chained_irq.h>
#include <linux/irqchip/irq-msi-lib.h>
@@ -32,6 +33,8 @@ static struct pci_ops dw_child_pcie_ops;
MSI_FLAG_PCI_MSIX | \
MSI_GENERIC_FLAGS_MASK)
+#define IS_256MB_ALIGNED(x) IS_ALIGNED(x, SZ_256M)
+
static const struct msi_parent_ops dw_pcie_msi_parent_ops = {
.required_flags = DW_PCIE_MSI_FLAGS_REQUIRED,
.supported_flags = DW_PCIE_MSI_FLAGS_SUPPORTED,
@@ -474,6 +477,34 @@ static int dw_pcie_create_ecam_window(struct dw_pcie_rp *pp, struct resource *re
return 0;
}
+static bool dw_pcie_ecam_enabled(struct dw_pcie_rp *pp, struct resource *config_res)
+{
+ struct resource *bus_range;
+ u64 nr_buses;
+
+ /* Vendor glue drivers may implement their own ECAM mechanism */
+ if (pp->native_ecam)
+ return false;
+
+ /*
+ * PCIe spec r6.0, sec 7.2.2 mandates the base address used for ECAM to
+ * be aligned on a 2^(n+20) byte boundary, where n is the number of bits
+ * used for representing 'bus' in BDF. Since the DWC cores always use 8
+ * bits for representing 'bus', the base address has to be aligned to
+ * 2^28 byte boundary, which is 256 MiB.
+ */
+ if (!IS_256MB_ALIGNED(config_res->start))
+ return false;
+
+ bus_range = resource_list_first_type(&pp->bridge->windows, IORESOURCE_BUS)->res;
+ if (!bus_range)
+ return false;
+
+ nr_buses = resource_size(config_res) >> PCIE_ECAM_BUS_SHIFT;
+
+ return nr_buses >= resource_size(bus_range);
+}
+
static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
{
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
@@ -492,6 +523,7 @@ static int dw_pcie_host_get_resources(struct dw_pcie_rp *pp)
pp->cfg0_size = resource_size(res);
pp->cfg0_base = res->start;
+ pp->ecam_enabled = dw_pcie_ecam_enabled(pp, res);
if (pp->ecam_enabled) {
ret = dw_pcie_create_ecam_window(pp, res);
if (ret)
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index cfeb99b89c3739b867a54da38e0f94835c2ce3a0..6ec0a737294b2a69bbcc05bbdbe0a11c5f8310bb 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -430,6 +430,7 @@ struct dw_pcie_rp {
struct pci_eq_presets presets;
struct pci_config_window *cfg;
bool ecam_enabled;
+ bool native_ecam;
};
struct dw_pcie_ep_ops {
--
2.45.2On Tue, 9 Sep 2025, Manivannan Sadhasivam wrote:
> From: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>
> 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.
So this broke a parallel port on my HiFive Unmatched machine (a SiFive
FU740-C000 based system), the driver no longer registers the device, no
/dev/parport0 anymore.
I've had to bisect it with commit a1978b692a39 ("PCI: dwc: Use custom
pci_ops for root bus DBI vs ECAM config access") and commit fc2bc2623e3a
("Revert "PCI: qcom: Prepare for the DWC ECAM enablement"") applied on top
and it's affirmative it's this change, i.e. upstream commit 0da48c5b2fa7
("PCI: dwc: Support ECAM mechanism by enabling iATU 'CFG Shift Feature'").
Here's the relevant part of a diff between bootstrap logs:
--- dmesg-good.log 2025-11-28 03:41:18.943097032 +0100
+++ dmesg-bad.log 2025-11-28 03:47:29.582049781 +0100
@@ -1,5 +1,5 @@
-Booting Linux on hartid 3
-Linux version 6.17.0-rc1-00008-g4660e50cf818-dirty (macro@angie) (riscv64-linux-gnu-gcc (GCC) 13.0.0 20220602 (experimental), GNU ld (GNU Binutils) 2.38.50.20220503) #19 SMP Fri Nov 28 02:37:51 GMT 2025
+Booting Linux on hartid 1
+Linux version 6.17.0-rc1-00009-g0da48c5b2fa7-dirty (macro@angie) (riscv64-linux-gnu-gcc (GCC) 13.0.0 20220602 (experimental), GNU ld (GNU Binutils) 2.38.50.20220503) #20 SMP Fri Nov 28 02:43:00 GMT 2025
Machine model: SiFive HiFive Unmatched A00
SBI specification v0.3 detected
SBI implementation ID=0x1 Version=0x9
@@ -61,7 +61,7 @@
EFI services will not be available.
smp: Bringing up secondary CPUs ...
smp: Brought up 1 node, 4 CPUs
-Memory: 16383064K/16777216K available (10746K kernel code, 2200K rwdata, 4972K rodata, 537K init, 371K bss, 389448K reserved, 0K cma-reserved)
+Memory: 16383064K/16777216K available (10746K kernel code, 2200K rwdata, 4972K rodata, 536K init, 371K bss, 389448K reserved, 0K cma-reserved)
devtmpfs: initialized
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
posixtimers hash table entries: 2048 (order: 3, 32768 bytes, linear)
@@ -161,6 +161,7 @@
fu740-pcie e00000000.pcie: IO 0x0060080000..0x006008ffff -> 0x0060080000
fu740-pcie e00000000.pcie: MEM 0x0060090000..0x007fffffff -> 0x0060090000
fu740-pcie e00000000.pcie: MEM 0x2000000000..0x3fffffffff -> 0x2000000000
+fu740-pcie e00000000.pcie: ECAM at [mem 0xdf0000000-0xdffffffff] for [bus 00-ff]
fu740-pcie e00000000.pcie: Using 256 MSI vectors
fu740-pcie e00000000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4096G
fu740-pcie e00000000.pcie: cap_exp at 70
@@ -655,7 +656,7 @@
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.17
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: xHCI Host Controller
-usb usb1: Manufacturer: Linux 6.17.0-rc1-00008-g4660e50cf818-dirty xhci-hcd
+usb usb1: Manufacturer: Linux 6.17.0-rc1-00009-g0da48c5b2fa7-dirty xhci-hcd
usb usb1: SerialNumber: 0000:04:00.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
@@ -663,7 +664,7 @@
usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.17
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: xHCI Host Controller
-usb usb2: Manufacturer: Linux 6.17.0-rc1-00008-g4660e50cf818-dirty xhci-hcd
+usb usb2: Manufacturer: Linux 6.17.0-rc1-00009-g0da48c5b2fa7-dirty xhci-hcd
usb usb2: SerialNumber: 0000:04:00.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
@@ -735,8 +736,6 @@
pcieport 0000:06:01.0: enabling bus mastering
parport_pc 0000:07:00.0: enabling device (0000 -> 0001)
PCI parallel port detected: 1415:c118, I/O at 0x1000(0x1008), IRQ 35
-parport0: PC-style at 0x1000 (0x1008), irq 35, using FIFO [PCSPP,TRISTATE,EPP,ECP]
-lp0: using parport0 (interrupt-driven).
parport_pc 0000:07:00.0: vgaarb: pci_notify
serial 0000:07:00.3: vgaarb: pci_notify
serial 0000:07:00.3: assign IRQ: got 40
and then it goes on with insignificant changes only owing to differences
in the order of messages produced, the kernel version ID or date stamps.
As you can see the PCIe parallel port device continues being accessible,
it's only the driver that doesn't pick up the device anymore.
I'm stumped as to where it might be coming from. Any ideas?
Maciej
On 11/28/2025 8:47 AM, Maciej W. Rozycki wrote:
> On Tue, 9 Sep 2025, Manivannan Sadhasivam wrote:
>
>> From: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>>
>> 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.
> So this broke a parallel port on my HiFive Unmatched machine (a SiFive
> FU740-C000 based system), the driver no longer registers the device, no
> /dev/parport0 anymore.
Hi Maciej, can you share us lspci -vvv o/p with working & non working
case and also can you point us parport driver. - Krishna Chaitanya.
> I've had to bisect it with commit a1978b692a39 ("PCI: dwc: Use custom
> pci_ops for root bus DBI vs ECAM config access") and commit fc2bc2623e3a
> ("Revert "PCI: qcom: Prepare for the DWC ECAM enablement"") applied on top
> and it's affirmative it's this change, i.e. upstream commit 0da48c5b2fa7
> ("PCI: dwc: Support ECAM mechanism by enabling iATU 'CFG Shift Feature'").
>
> Here's the relevant part of a diff between bootstrap logs:
>
> --- dmesg-good.log 2025-11-28 03:41:18.943097032 +0100
> +++ dmesg-bad.log 2025-11-28 03:47:29.582049781 +0100
> @@ -1,5 +1,5 @@
> -Booting Linux on hartid 3
> -Linux version 6.17.0-rc1-00008-g4660e50cf818-dirty (macro@angie) (riscv64-linux-gnu-gcc (GCC) 13.0.0 20220602 (experimental), GNU ld (GNU Binutils) 2.38.50.20220503) #19 SMP Fri Nov 28 02:37:51 GMT 2025
> +Booting Linux on hartid 1
> +Linux version 6.17.0-rc1-00009-g0da48c5b2fa7-dirty (macro@angie) (riscv64-linux-gnu-gcc (GCC) 13.0.0 20220602 (experimental), GNU ld (GNU Binutils) 2.38.50.20220503) #20 SMP Fri Nov 28 02:43:00 GMT 2025
> Machine model: SiFive HiFive Unmatched A00
> SBI specification v0.3 detected
> SBI implementation ID=0x1 Version=0x9
> @@ -61,7 +61,7 @@
> EFI services will not be available.
> smp: Bringing up secondary CPUs ...
> smp: Brought up 1 node, 4 CPUs
> -Memory: 16383064K/16777216K available (10746K kernel code, 2200K rwdata, 4972K rodata, 537K init, 371K bss, 389448K reserved, 0K cma-reserved)
> +Memory: 16383064K/16777216K available (10746K kernel code, 2200K rwdata, 4972K rodata, 536K init, 371K bss, 389448K reserved, 0K cma-reserved)
> devtmpfs: initialized
> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> posixtimers hash table entries: 2048 (order: 3, 32768 bytes, linear)
> @@ -161,6 +161,7 @@
> fu740-pcie e00000000.pcie: IO 0x0060080000..0x006008ffff -> 0x0060080000
> fu740-pcie e00000000.pcie: MEM 0x0060090000..0x007fffffff -> 0x0060090000
> fu740-pcie e00000000.pcie: MEM 0x2000000000..0x3fffffffff -> 0x2000000000
> +fu740-pcie e00000000.pcie: ECAM at [mem 0xdf0000000-0xdffffffff] for [bus 00-ff]
> fu740-pcie e00000000.pcie: Using 256 MSI vectors
> fu740-pcie e00000000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4096G
> fu740-pcie e00000000.pcie: cap_exp at 70
> @@ -655,7 +656,7 @@
> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.17
> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb1: Product: xHCI Host Controller
> -usb usb1: Manufacturer: Linux 6.17.0-rc1-00008-g4660e50cf818-dirty xhci-hcd
> +usb usb1: Manufacturer: Linux 6.17.0-rc1-00009-g0da48c5b2fa7-dirty xhci-hcd
> usb usb1: SerialNumber: 0000:04:00.0
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 2 ports detected
> @@ -663,7 +664,7 @@
> usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.17
> usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb2: Product: xHCI Host Controller
> -usb usb2: Manufacturer: Linux 6.17.0-rc1-00008-g4660e50cf818-dirty xhci-hcd
> +usb usb2: Manufacturer: Linux 6.17.0-rc1-00009-g0da48c5b2fa7-dirty xhci-hcd
> usb usb2: SerialNumber: 0000:04:00.0
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 2 ports detected
> @@ -735,8 +736,6 @@
> pcieport 0000:06:01.0: enabling bus mastering
> parport_pc 0000:07:00.0: enabling device (0000 -> 0001)
> PCI parallel port detected: 1415:c118, I/O at 0x1000(0x1008), IRQ 35
> -parport0: PC-style at 0x1000 (0x1008), irq 35, using FIFO [PCSPP,TRISTATE,EPP,ECP]
> -lp0: using parport0 (interrupt-driven).
> parport_pc 0000:07:00.0: vgaarb: pci_notify
> serial 0000:07:00.3: vgaarb: pci_notify
> serial 0000:07:00.3: assign IRQ: got 40
>
> and then it goes on with insignificant changes only owing to differences
> in the order of messages produced, the kernel version ID or date stamps.
> As you can see the PCIe parallel port device continues being accessible,
> it's only the driver that doesn't pick up the device anymore.
>
> I'm stumped as to where it might be coming from. Any ideas?
>
> Maciej
On Fri, 28 Nov 2025, Krishna Chaitanya Chundru wrote:
> > > 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.
> > So this broke a parallel port on my HiFive Unmatched machine (a SiFive
> > FU740-C000 based system), the driver no longer registers the device, no
> > /dev/parport0 anymore.
> Hi Maciej, can you share us lspci -vvv o/p with working & non working case and
> also can you point us parport driver. - Krishna Chaitanya.
I'm not sure what you mean as to the parport driver; it's standard stuff:
$ zgrep PARPORT /proc/config.gz
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
# CONFIG_PARPORT_SERIAL is not set
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_1284=y
# CONFIG_PATA_PARPORT is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_USB_SERIAL_MOS7715_PARPORT is not set
$
I've attached output from `lspci -xxxx' so that you can decode it yourself
however you need, though I fail to see anything standing out there.
If you can't figure out what's going on here, then I'll try to poke at
the driver to see what exactly it is that causes it to fail there, but I'm
a little constrained on the resources and completely unfamiliar with the
ECAM feature (and the lack of documentation for the DW IP does not help).
I have no slightest idea why it should cause a regression such as this,
it seems totally unrelated. Yet it's 100% reproducible. Could this be
because it's the only device in the system that actually uses PCI/e port
I/O?
# cat /proc/ioports
00000000-0000ffff : pcie@e00000000
00001000-00002fff : PCI Bus 0000:01
00001000-00002fff : PCI Bus 0000:02
00001000-00002fff : PCI Bus 0000:05
00001000-00002fff : PCI Bus 0000:06
00001000-00001fff : PCI Bus 0000:07
00001000-00001007 : 0000:07:00.0
00001000-00001002 : parport0
00001003-00001007 : parport0
00001008-0000100b : 0000:07:00.0
00001008-0000100a : parport0
00002000-00002fff : PCI Bus 0000:08
00002000-00002fff : PCI Bus 0000:09
00002000-000020ff : 0000:09:01.0
00002100-0000217f : 0000:09:02.0
#
(Hmm, indentation does not appear correct to me for buses below 0000:07.)
Maciej
On 11/28/2025 2:07 PM, Maciej W. Rozycki wrote:
> On Fri, 28 Nov 2025, Krishna Chaitanya Chundru wrote:
>
>>>> 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.
>>> So this broke a parallel port on my HiFive Unmatched machine (a SiFive
>>> FU740-C000 based system), the driver no longer registers the device, no
>>> /dev/parport0 anymore.
>> Hi Maciej, can you share us lspci -vvv o/p with working & non working case and
>> also can you point us parport driver. - Krishna Chaitanya.
> I'm not sure what you mean as to the parport driver; it's standard stuff:
>
> $ zgrep PARPORT /proc/config.gz
> CONFIG_PARPORT=y
> CONFIG_PARPORT_PC=y
> # CONFIG_PARPORT_SERIAL is not set
> CONFIG_PARPORT_PC_FIFO=y
> CONFIG_PARPORT_1284=y
> # CONFIG_PATA_PARPORT is not set
> # CONFIG_I2C_PARPORT is not set
> # CONFIG_USB_SERIAL_MOS7715_PARPORT is not set
> $
>
> I've attached output from `lspci -xxxx' so that you can decode it yourself
> however you need, though I fail to see anything standing out there.
>
> If you can't figure out what's going on here, then I'll try to poke at
> the driver to see what exactly it is that causes it to fail there, but I'm
> a little constrained on the resources and completely unfamiliar with the
> ECAM feature (and the lack of documentation for the DW IP does not help).
>
> I have no slightest idea why it should cause a regression such as this,
> it seems totally unrelated. Yet it's 100% reproducible. Could this be
> because it's the only device in the system that actually uses PCI/e port
> I/O?
Hi Maciej, Can you try attached patch and let me know if that is helping
you or not. - Krishna Chaitanya.
> # cat /proc/ioports
> 00000000-0000ffff : pcie@e00000000
> 00001000-00002fff : PCI Bus 0000:01
> 00001000-00002fff : PCI Bus 0000:02
> 00001000-00002fff : PCI Bus 0000:05
> 00001000-00002fff : PCI Bus 0000:06
> 00001000-00001fff : PCI Bus 0000:07
> 00001000-00001007 : 0000:07:00.0
> 00001000-00001002 : parport0
> 00001003-00001007 : parport0
> 00001008-0000100b : 0000:07:00.0
> 00001008-0000100a : parport0
> 00002000-00002fff : PCI Bus 0000:08
> 00002000-00002fff : PCI Bus 0000:09
> 00002000-000020ff : 0000:09:01.0
> 00002100-0000217f : 0000:09:02.0
> #
>
> (Hmm, indentation does not appear correct to me for buses below 0000:07.)
>
> Maciej
From ad002661c2e559ee3ec523b00e23948407968cd7 Mon Sep 17 00:00:00 2001
From: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Date: Fri, 28 Nov 2025 16:44:17 +0530
Subject: [PATCH] PCI: qcom: Enable iATU mapping for memory & IO regions
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
.../pci/controller/dwc/pcie-designware-host.c | 24 ++++++++++++++-----
drivers/pci/controller/dwc/pcie-designware.c | 3 +++
drivers/pci/controller/dwc/pcie-designware.h | 2 +-
3 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index e92513c5bda5..a60f1539fadc 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -36,6 +36,7 @@ static struct pci_ops dw_child_pcie_ops;
#define IS_256MB_ALIGNED(x) IS_ALIGNED(x, SZ_256M)
+static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp);
static const struct msi_parent_ops dw_pcie_msi_parent_ops = {
.required_flags = DW_PCIE_MSI_FLAGS_REQUIRED,
.supported_flags = DW_PCIE_MSI_FLAGS_SUPPORTED,
@@ -427,13 +428,17 @@ static int dw_pcie_config_ecam_iatu(struct dw_pcie_rp *pp)
bus = resource_list_first_type(&pp->bridge->windows, IORESOURCE_BUS);
+ ret = dw_pcie_iatu_setup(pp);
+ if (ret)
+ return ret;
+
/*
* Root bus under the host bridge doesn't require any iATU configuration
* as DBI region will be used to access root bus config space.
* Immediate bus under Root Bus, needs type 0 iATU configuration and
* remaining buses need type 1 iATU configuration.
*/
- atu.index = 0;
+ atu.index = pp->ob_atu_index;
atu.type = PCIE_ATU_TYPE_CFG0;
atu.parent_bus_addr = pp->cfg0_base + SZ_1M;
/* 1MiB is to cover 1 (bus) * 32 (devices) * 8 (functions) */
@@ -443,19 +448,26 @@ static int dw_pcie_config_ecam_iatu(struct dw_pcie_rp *pp)
if (ret)
return ret;
+
bus_range_max = resource_size(bus->res);
if (bus_range_max < 2)
return 0;
+ pp->ob_atu_index++;
+
/* Configure remaining buses in type 1 iATU configuration */
- atu.index = 1;
+ atu.index = pp->ob_atu_index;
atu.type = PCIE_ATU_TYPE_CFG1;
atu.parent_bus_addr = pp->cfg0_base + SZ_2M;
atu.size = (SZ_1M * bus_range_max) - SZ_2M;
atu.ctrl2 = PCIE_ATU_CFG_SHIFT_MODE_ENABLE;
- return dw_pcie_prog_outbound_atu(pci, &atu);
+ ret = dw_pcie_prog_outbound_atu(pci, &atu);
+ if (!ret)
+ pp->ob_atu_index++;
+
+ return ret;
}
static int dw_pcie_create_ecam_window(struct dw_pcie_rp *pp, struct resource *res)
@@ -942,7 +954,7 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
dev_warn(pci->dev, "Ranges exceed outbound iATU size (%d)\n",
pci->num_ob_windows);
- pp->msg_atu_index = i;
+ pp->ob_atu_index = i;
i = 0;
resource_list_for_each_entry(entry, &pp->bridge->dma_ranges) {
@@ -1113,7 +1125,7 @@ static int dw_pcie_pme_turn_off(struct dw_pcie *pci)
void __iomem *mem;
int ret;
- if (pci->num_ob_windows <= pci->pp.msg_atu_index)
+ if (pci->num_ob_windows <= pci->pp.ob_atu_index)
return -ENOSPC;
if (!pci->pp.msg_res)
@@ -1123,7 +1135,7 @@ static int dw_pcie_pme_turn_off(struct dw_pcie *pci)
atu.routing = PCIE_MSG_TYPE_R_BC;
atu.type = PCIE_ATU_TYPE_MSG;
atu.size = resource_size(pci->pp.msg_res);
- atu.index = pci->pp.msg_atu_index;
+ atu.index = pci->pp.ob_atu_index;
atu.parent_bus_addr = pci->pp.msg_res->start - pci->parent_bus_offset;
diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
index c644216995f6..d27b469b417b 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -478,6 +478,9 @@ int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
limit_addr = parent_bus_addr + atu->size - 1;
+ if (atu->index > pci->num_ob_windows)
+ return -ENOSPC;
+
if ((limit_addr & ~pci->region_limit) != (parent_bus_addr & ~pci->region_limit) ||
!IS_ALIGNED(parent_bus_addr, pci->region_align) ||
!IS_ALIGNED(atu->pci_addr, pci->region_align) || !atu->size) {
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index e995f692a1ec..69d0bd8b3c57 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -423,8 +423,8 @@ struct dw_pcie_rp {
struct pci_host_bridge *bridge;
raw_spinlock_t lock;
DECLARE_BITMAP(msi_irq_in_use, MAX_MSI_IRQS);
+ int ob_atu_index;
bool use_atu_msg;
- int msg_atu_index;
struct resource *msg_res;
bool use_linkup_irq;
struct pci_eq_presets presets;
--
2.34.1
On Fri, 28 Nov 2025, Krishna Chaitanya Chundru wrote: > > I have no slightest idea why it should cause a regression such as this, > > it seems totally unrelated. Yet it's 100% reproducible. Could this be > > because it's the only device in the system that actually uses PCI/e port > > I/O? > Hi Maciej, Can you try attached patch and let me know if that is helping you > or not. - Krishna Chaitanya. No change, it's still broken, sorry. Maciej
On 11/28/2025 10:46 PM, Maciej W. Rozycki wrote:
> On Fri, 28 Nov 2025, Krishna Chaitanya Chundru wrote:
>
>>> I have no slightest idea why it should cause a regression such as this,
>>> it seems totally unrelated. Yet it's 100% reproducible. Could this be
>>> because it's the only device in the system that actually uses PCI/e port
>>> I/O?
>> Hi Maciej, Can you try attached patch and let me know if that is helping you
>> or not. - Krishna Chaitanya.
> No change, it's still broken, sorry.
HI Maciej,
For the previous patch can you apply this diff and share me dmesg o/p
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -448,7 +448,6 @@ static int dw_pcie_config_ecam_iatu(struct
dw_pcie_rp *pp)
if (ret)
return ret;
-
bus_range_max = resource_size(bus->res);
if (bus_range_max < 2)
@@ -456,6 +455,8 @@ static int dw_pcie_config_ecam_iatu(struct
dw_pcie_rp *pp)
pp->ob_atu_index++;
+ dev_err(pci->dev, "Current iATU OB index %d\n", pp->ob_atu_index);
+
/* Configure remaining buses in type 1 iATU configuration */
atu.index = pp->ob_atu_index;
atu.type = PCIE_ATU_TYPE_CFG1;
@@ -931,6 +932,7 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
}
}
+ dev_err(pci->dev, "Current iATU OB index %d\n", i);
if (pp->io_size) {
if (pci->num_ob_windows > ++i) {
atu.index = i;
@@ -946,6 +948,7 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
return ret;
}
} else {
+ dev_err(pci->dev, "Using shared io index %d\n", i);
pp->cfg0_io_shared = true;
}
}
- Krishna Chaitanya.
> Maciej
On Sat, 29 Nov 2025, Krishna Chaitanya Chundru wrote:
> > > Hi Maciej, Can you try attached patch and let me know if that is helping
> > > you
> > > or not. - Krishna Chaitanya.
> > No change, it's still broken, sorry.
> HI Maciej,
> For the previous patch can you apply this diff and share me dmesg o/p
Your patch came though garbled, likely due to:
Content-Type: text/plain; charset=UTF-8; format=flowed
Please refer Documentation/process/email-clients.rst and reconfigure your
e-mail client if possible.
Regardless, I've fixed it up by hand and the only difference in the log,
except for usual noise which I removed, is this:
--- dmesg-bad.log 2025-11-28 03:47:29.582049781 +0100
+++ dmesg-debug.log 2025-11-29 05:41:23.384645926 +0100
@@ -164,6 +164,8 @@
fu740-pcie e00000000.pcie: ECAM at [mem 0xdf0000000-0xdffffffff] for [bus 00-ff]
fu740-pcie e00000000.pcie: Using 256 MSI vectors
fu740-pcie e00000000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4096G
+fu740-pcie e00000000.pcie: Current iATU OB index 2
+fu740-pcie e00000000.pcie: Current iATU OB index 4
fu740-pcie e00000000.pcie: cap_exp at 70
fu740-pcie e00000000.pcie: PCIe Gen.1 x8 link up
fu740-pcie e00000000.pcie: changing speed back to original
I've attached a full copy of the debug log too. I hope this helps you
narrow the issue down or otherwise let me know what to try next.
NB I note that code you've been poking at only refers resources of the
IORESOURCE_MEM type. What about IORESOURCE_IO, which seems more relevant
here?
Also as a quick check I've now reconfigured the defxx driver for PCI port
I/O (which is a one-liner; the mapping used to be selectable by hand, but
distributions got it wrong for systems w/o PCI port I/O, so I switched the
driver to an automatic choice a few years ago, but the logic remains):
# cat /proc/ioports
00000000-0000ffff : pcie@e00000000
00001000-00002fff : PCI Bus 0000:01
00001000-00002fff : PCI Bus 0000:02
00001000-00002fff : PCI Bus 0000:05
00001000-00002fff : PCI Bus 0000:06
00001000-00001fff : PCI Bus 0000:07
00001000-00001007 : 0000:07:00.0
00001000-00001002 : parport0
00001003-00001007 : parport0
00001008-0000100b : 0000:07:00.0
00001008-0000100a : parport0
00002000-00002fff : PCI Bus 0000:08
00002000-00002fff : PCI Bus 0000:09
00002000-000020ff : 0000:09:01.0
00002100-0000217f : 0000:09:02.0
00002100-0000217f : defxx
#
and:
defxx 0000:09:02.0: assign IRQ: got 40
defxx: v1.12 2021/03/10 Lawrence V. Stefani and others
defxx 0000:09:02.0: enabling device (0000 -> 0003)
defxx 0000:09:02.0: enabling bus mastering
0000:09:02.0: DEFPA at I/O addr = 0x2100, IRQ = 40, Hardware addr = 00-60-6d-xx-xx-xx
0000:09:02.0: registered as fddi0
(as at commit 4660e50cf818) and likewise it has stopped working here from
commit 0da48c5b2fa7 onwards:
defxx 0000:09:02.0: assign IRQ: got 40
defxx: v1.12 2021/03/10 Lawrence V. Stefani and others
defxx 0000:09:02.0: enabling device (0000 -> 0003)
defxx 0000:09:02.0: enabling bus mastering
0000:09:02.0: Could not read adapter factory MAC address!
So it's definitely nothing specific to the parport driver, but rather a
general issue with PCI/e port I/O not working anymore. I do hope these
observations will let you address the issue now. You might be able to
reproduce it with hardware you have available even.
Maciej
On Sat, Nov 29, 2025 at 06:04:24AM +0000, Maciej W. Rozycki wrote: > On Sat, 29 Nov 2025, Krishna Chaitanya Chundru wrote: > > > > > Hi Maciej, Can you try attached patch and let me know if that is helping > > > > you > > > > or not. - Krishna Chaitanya. > > > No change, it's still broken, sorry. > > HI Maciej, > > For the previous patch can you apply this diff and share me dmesg o/p > > Your patch came though garbled, likely due to: > > Content-Type: text/plain; charset=UTF-8; format=flowed > > Please refer Documentation/process/email-clients.rst and reconfigure your > e-mail client if possible. > > Regardless, I've fixed it up by hand and the only difference in the log, > except for usual noise which I removed, is this: > > --- dmesg-bad.log 2025-11-28 03:47:29.582049781 +0100 > +++ dmesg-debug.log 2025-11-29 05:41:23.384645926 +0100 > @@ -164,6 +164,8 @@ > fu740-pcie e00000000.pcie: ECAM at [mem 0xdf0000000-0xdffffffff] for [bus 00-ff] > fu740-pcie e00000000.pcie: Using 256 MSI vectors > fu740-pcie e00000000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4096G > +fu740-pcie e00000000.pcie: Current iATU OB index 2 > +fu740-pcie e00000000.pcie: Current iATU OB index 4 > fu740-pcie e00000000.pcie: cap_exp at 70 > fu740-pcie e00000000.pcie: PCIe Gen.1 x8 link up > fu740-pcie e00000000.pcie: changing speed back to original > > I've attached a full copy of the debug log too. I hope this helps you > narrow the issue down or otherwise let me know what to try next. > > NB I note that code you've been poking at only refers resources of the > IORESOURCE_MEM type. What about IORESOURCE_IO, which seems more relevant > here? > > Also as a quick check I've now reconfigured the defxx driver for PCI port > I/O (which is a one-liner; the mapping used to be selectable by hand, but > distributions got it wrong for systems w/o PCI port I/O, so I switched the > driver to an automatic choice a few years ago, but the logic remains): > > # cat /proc/ioports > 00000000-0000ffff : pcie@e00000000 > 00001000-00002fff : PCI Bus 0000:01 > 00001000-00002fff : PCI Bus 0000:02 > 00001000-00002fff : PCI Bus 0000:05 > 00001000-00002fff : PCI Bus 0000:06 > 00001000-00001fff : PCI Bus 0000:07 > 00001000-00001007 : 0000:07:00.0 > 00001000-00001002 : parport0 > 00001003-00001007 : parport0 > 00001008-0000100b : 0000:07:00.0 > 00001008-0000100a : parport0 > 00002000-00002fff : PCI Bus 0000:08 > 00002000-00002fff : PCI Bus 0000:09 > 00002000-000020ff : 0000:09:01.0 > 00002100-0000217f : 0000:09:02.0 > 00002100-0000217f : defxx > # > > and: > > defxx 0000:09:02.0: assign IRQ: got 40 > defxx: v1.12 2021/03/10 Lawrence V. Stefani and others > defxx 0000:09:02.0: enabling device (0000 -> 0003) > defxx 0000:09:02.0: enabling bus mastering > 0000:09:02.0: DEFPA at I/O addr = 0x2100, IRQ = 40, Hardware addr = 00-60-6d-xx-xx-xx > 0000:09:02.0: registered as fddi0 > > (as at commit 4660e50cf818) and likewise it has stopped working here from > commit 0da48c5b2fa7 onwards: > > defxx 0000:09:02.0: assign IRQ: got 40 > defxx: v1.12 2021/03/10 Lawrence V. Stefani and others > defxx 0000:09:02.0: enabling device (0000 -> 0003) > defxx 0000:09:02.0: enabling bus mastering > 0000:09:02.0: Could not read adapter factory MAC address! > > So it's definitely nothing specific to the parport driver, but rather a > general issue with PCI/e port I/O not working anymore. I do hope these > observations will let you address the issue now. You might be able to > reproduce it with hardware you have available even. > Yes, looks like the I/O port access is not working with the CFG Shift feature. The spec says that both I/O and MEM TLPs should be handled by this feature, so we are currently unsure why MEM works, but not I/O. The issue you reported with parport_pc driver is that the driver gets probed, but it fails to detect the parallel ports on the device. More precisely, it fails due to the parport_SPP_supported() check in drivers/parport/parport_pc.c. This function performs some read/write checks to make sure that the port exists, but most likely the read value doesn't match the written one. And since there is no log printed in this function, it just failed silently. We will check why I/O access fails with ECAM mode and revert back asap. Since the merge window is now open, it becomes difficult to revert the CFG shift feature cleanly. The timing of the report also made it difficult to fix the issue in v6.18. Hopefully, we can backport the fix once we identify the culprit. Sorry for the inconvenience! - Mani -- மணிவண்ணன் சதாசிவம்
On Mon, Dec 01, 2025 at 05:21:50PM +0530, Manivannan Sadhasivam wrote: > On Sat, Nov 29, 2025 at 06:04:24AM +0000, Maciej W. Rozycki wrote: > > On Sat, 29 Nov 2025, Krishna Chaitanya Chundru wrote: > > > > > > > Hi Maciej, Can you try attached patch and let me know if that is helping > > > > > you > > > > > or not. - Krishna Chaitanya. > > > > No change, it's still broken, sorry. > > > HI Maciej, > > > For the previous patch can you apply this diff and share me dmesg o/p > > > > Your patch came though garbled, likely due to: > > > > Content-Type: text/plain; charset=UTF-8; format=flowed > > > > Please refer Documentation/process/email-clients.rst and reconfigure your > > e-mail client if possible. > > > > Regardless, I've fixed it up by hand and the only difference in the log, > > except for usual noise which I removed, is this: > > > > --- dmesg-bad.log 2025-11-28 03:47:29.582049781 +0100 > > +++ dmesg-debug.log 2025-11-29 05:41:23.384645926 +0100 > > @@ -164,6 +164,8 @@ > > fu740-pcie e00000000.pcie: ECAM at [mem 0xdf0000000-0xdffffffff] for [bus 00-ff] > > fu740-pcie e00000000.pcie: Using 256 MSI vectors > > fu740-pcie e00000000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4096G > > +fu740-pcie e00000000.pcie: Current iATU OB index 2 > > +fu740-pcie e00000000.pcie: Current iATU OB index 4 > > fu740-pcie e00000000.pcie: cap_exp at 70 > > fu740-pcie e00000000.pcie: PCIe Gen.1 x8 link up > > fu740-pcie e00000000.pcie: changing speed back to original > > > > I've attached a full copy of the debug log too. I hope this helps you > > narrow the issue down or otherwise let me know what to try next. > > > > NB I note that code you've been poking at only refers resources of the > > IORESOURCE_MEM type. What about IORESOURCE_IO, which seems more relevant > > here? > > > > Also as a quick check I've now reconfigured the defxx driver for PCI port > > I/O (which is a one-liner; the mapping used to be selectable by hand, but > > distributions got it wrong for systems w/o PCI port I/O, so I switched the > > driver to an automatic choice a few years ago, but the logic remains): > > > > # cat /proc/ioports > > 00000000-0000ffff : pcie@e00000000 > > 00001000-00002fff : PCI Bus 0000:01 > > 00001000-00002fff : PCI Bus 0000:02 > > 00001000-00002fff : PCI Bus 0000:05 > > 00001000-00002fff : PCI Bus 0000:06 > > 00001000-00001fff : PCI Bus 0000:07 > > 00001000-00001007 : 0000:07:00.0 > > 00001000-00001002 : parport0 > > 00001003-00001007 : parport0 > > 00001008-0000100b : 0000:07:00.0 > > 00001008-0000100a : parport0 > > 00002000-00002fff : PCI Bus 0000:08 > > 00002000-00002fff : PCI Bus 0000:09 > > 00002000-000020ff : 0000:09:01.0 > > 00002100-0000217f : 0000:09:02.0 > > 00002100-0000217f : defxx > > # > > > > and: > > > > defxx 0000:09:02.0: assign IRQ: got 40 > > defxx: v1.12 2021/03/10 Lawrence V. Stefani and others > > defxx 0000:09:02.0: enabling device (0000 -> 0003) > > defxx 0000:09:02.0: enabling bus mastering > > 0000:09:02.0: DEFPA at I/O addr = 0x2100, IRQ = 40, Hardware addr = 00-60-6d-xx-xx-xx > > 0000:09:02.0: registered as fddi0 > > > > (as at commit 4660e50cf818) and likewise it has stopped working here from > > commit 0da48c5b2fa7 onwards: > > > > defxx 0000:09:02.0: assign IRQ: got 40 > > defxx: v1.12 2021/03/10 Lawrence V. Stefani and others > > defxx 0000:09:02.0: enabling device (0000 -> 0003) > > defxx 0000:09:02.0: enabling bus mastering > > 0000:09:02.0: Could not read adapter factory MAC address! > > > > So it's definitely nothing specific to the parport driver, but rather a > > general issue with PCI/e port I/O not working anymore. I do hope these > > observations will let you address the issue now. You might be able to > > reproduce it with hardware you have available even. > > > > Yes, looks like the I/O port access is not working with the CFG Shift feature. > The spec says that both I/O and MEM TLPs should be handled by this feature, so > we are currently unsure why MEM works, but not I/O. > > The issue you reported with parport_pc driver is that the driver gets probed, > but it fails to detect the parallel ports on the device. More precisely, it > fails due to the parport_SPP_supported() check in drivers/parport/parport_pc.c. > This function performs some read/write checks to make sure that the port exists, > but most likely the read value doesn't match the written one. And since there is > no log printed in this function, it just failed silently. > > We will check why I/O access fails with ECAM mode and revert back asap. Since > the merge window is now open, it becomes difficult to revert the CFG shift > feature cleanly. The timing of the report also made it difficult to fix the > issue in v6.18. Hopefully, we can backport the fix once we identify the culprit. > Can you try the attached patch? It is a reworked version of Krishna's patch. I just moved things around to check potential override issue. - Mani -- மணிவண்ணன் சதாசிவம்
On Mon, 1 Dec 2025, Manivannan Sadhasivam wrote: > > > So it's definitely nothing specific to the parport driver, but rather a > > > general issue with PCI/e port I/O not working anymore. I do hope these > > > observations will let you address the issue now. You might be able to > > > reproduce it with hardware you have available even. > > > > > > > Yes, looks like the I/O port access is not working with the CFG Shift feature. > > The spec says that both I/O and MEM TLPs should be handled by this feature, so > > we are currently unsure why MEM works, but not I/O. As I say, last time I checked (for another reason) documentation was not available to the general public, so I can't help with that. > > The issue you reported with parport_pc driver is that the driver gets probed, > > but it fails to detect the parallel ports on the device. More precisely, it > > fails due to the parport_SPP_supported() check in drivers/parport/parport_pc.c. > > This function performs some read/write checks to make sure that the port exists, > > but most likely the read value doesn't match the written one. And since there is > > no log printed in this function, it just failed silently. Whatever the exact transaction conditions are port I/O TLPs seem not to make it through to the requested target device anymore. FWIW the defxx driver issues a command to the device's command register and wants to see a successful completion status in the status register before retrieving the MAC address via the data register. So it's not a simple case of poking at a register and reading it back, but the end result is the same: the device cannot be talked to. > > We will check why I/O access fails with ECAM mode and revert back asap. Since > > the merge window is now open, it becomes difficult to revert the CFG shift > > feature cleanly. The timing of the report also made it difficult to fix the > > issue in v6.18. Hopefully, we can backport the fix once we identify the culprit. No worries, I've been around for long enough (short of 30 years) to know the process. FWIW the original change would've best been reverted for 6.18 as a fatal regression, however port I/O is uncommon enough nowadays we can defer any final decision to 6.19 I suppose. I'm glad I've tripped over this in the first place as I'm not eager to upgrade all my lab devices all the time, and it was owing to another issue only that I chose this moment to move forward, not so long after the original commit. > Can you try the attached patch? It is a reworked version of Krishna's patch. I > just moved things around to check potential override issue. No change in behaviour, sorry. I suppose it's this range of host address decoding: fu740-pcie e00000000.pcie: IO 0x0060080000..0x006008ffff -> 0x0060080000 aka: pci_bus 0000:00: root bus resource [io 0x0000-0xffff] (bus address [0x60080000-0x6008ffff]) that you're after. Are you sure your code discovers it correctly? As I say I can only see IORESOURCE_MEM references and no IORESOURCE_IO ones as would be appropriate for the root bus resource quoted. Maciej
On Mon, Dec 01, 2025 at 04:42:42PM +0000, Maciej W. Rozycki wrote: > On Mon, 1 Dec 2025, Manivannan Sadhasivam wrote: > > > > > So it's definitely nothing specific to the parport driver, but rather a > > > > general issue with PCI/e port I/O not working anymore. I do hope these > > > > observations will let you address the issue now. You might be able to > > > > reproduce it with hardware you have available even. > > > > > > > > > > Yes, looks like the I/O port access is not working with the CFG Shift feature. > > > The spec says that both I/O and MEM TLPs should be handled by this feature, so > > > we are currently unsure why MEM works, but not I/O. > > As I say, last time I checked (for another reason) documentation was not > available to the general public, so I can't help with that. > Sure. I know that the DWC documentation is well secured behind firewalls. So not asking for help here. > > > The issue you reported with parport_pc driver is that the driver gets probed, > > > but it fails to detect the parallel ports on the device. More precisely, it > > > fails due to the parport_SPP_supported() check in drivers/parport/parport_pc.c. > > > This function performs some read/write checks to make sure that the port exists, > > > but most likely the read value doesn't match the written one. And since there is > > > no log printed in this function, it just failed silently. > > Whatever the exact transaction conditions are port I/O TLPs seem not to > make it through to the requested target device anymore. > > FWIW the defxx driver issues a command to the device's command register > and wants to see a successful completion status in the status register > before retrieving the MAC address via the data register. So it's not a > simple case of poking at a register and reading it back, but the end > result is the same: the device cannot be talked to. > > > > We will check why I/O access fails with ECAM mode and revert back asap. Since > > > the merge window is now open, it becomes difficult to revert the CFG shift > > > feature cleanly. The timing of the report also made it difficult to fix the > > > issue in v6.18. Hopefully, we can backport the fix once we identify the culprit. > > No worries, I've been around for long enough (short of 30 years) to know > the process. > > FWIW the original change would've best been reverted for 6.18 as a fatal > regression, however port I/O is uncommon enough nowadays we can defer any > final decision to 6.19 I suppose. I'm glad I've tripped over this in the > first place as I'm not eager to upgrade all my lab devices all the time, > and it was owing to another issue only that I chose this moment to move > forward, not so long after the original commit. > > > Can you try the attached patch? It is a reworked version of Krishna's patch. I > > just moved things around to check potential override issue. > > No change in behaviour, sorry. I suppose it's this range of host address > decoding: > > fu740-pcie e00000000.pcie: IO 0x0060080000..0x006008ffff -> 0x0060080000 > > aka: > > pci_bus 0000:00: root bus resource [io 0x0000-0xffff] (bus address [0x60080000-0x6008ffff]) > > that you're after. Are you sure your code discovers it correctly? As I > say I can only see IORESOURCE_MEM references and no IORESOURCE_IO ones as > would be appropriate for the root bus resource quoted. > The I/O resource is discovered by the driver correctly as seen from the logs: pci_bus 0000:00: root bus resource [io 0x0000-0xffff] (bus address [0x60080000-0x6008ffff]) pci_bus 0000:00: root bus resource [mem 0x60090000-0x7fffffff] pci_bus 0000:00: root bus resource [mem 0x2000000000-0x3fffffffff pref] But we believe that the iATU is not programmed for the I/O port, resulting in the I/O access not going out to the device. Krishna found an issue in the previous patch that got shared. So I've attached a new one. Could you please try and let us know? If it didn't help, please share the dmesg log that will have some more info. - Mani -- மணிவண்ணன் சதாசிவம்
On Tue, 2 Dec 2025, Manivannan Sadhasivam wrote: > > No change in behaviour, sorry. I suppose it's this range of host address > > decoding: > > > > fu740-pcie e00000000.pcie: IO 0x0060080000..0x006008ffff -> 0x0060080000 > > > > aka: > > > > pci_bus 0000:00: root bus resource [io 0x0000-0xffff] (bus address [0x60080000-0x6008ffff]) > > > > that you're after. Are you sure your code discovers it correctly? As I > > say I can only see IORESOURCE_MEM references and no IORESOURCE_IO ones as > > would be appropriate for the root bus resource quoted. > > The I/O resource is discovered by the driver correctly as seen from the logs: > > pci_bus 0000:00: root bus resource [io 0x0000-0xffff] (bus address [0x60080000-0x6008ffff]) > pci_bus 0000:00: root bus resource [mem 0x60090000-0x7fffffff] > pci_bus 0000:00: root bus resource [mem 0x2000000000-0x3fffffffff pref] > > But we believe that the iATU is not programmed for the I/O port, resulting in > the I/O access not going out to the device. > > Krishna found an issue in the previous patch that got shared. So I've attached a > new one. Could you please try and let us know? If it didn't help, please share > the dmesg log that will have some more info. This does work correctly, thank you; see the log diff below (I checked the defxx driver separately too). Please make a proper submission and I'll give it a Tested-by: tag after final verification against 6.18. --- dmesg-bad.log 2025-11-28 03:47:29.582049781 +0100 +++ dmesg-fixed.log 2025-12-02 13:58:56.627947450 +0100 @@ -1,5 +1,5 @@ -Booting Linux on hartid 1 -Linux version 6.17.0-rc1-00009-g0da48c5b2fa7-dirty (macro@angie) (riscv64-linux-gnu-gcc (GCC) 13.0.0 20220602 (experimental), GNU ld (GNU Binutils) 2.38.50.20220503) #20 SMP Fri Nov 28 02:43:00 GMT 2025 +Booting Linux on hartid 4 +Linux version 6.17.0-rc1-00009-g0da48c5b2fa7-dirty (macro@angie) (riscv64-linux-gnu-gcc (GCC) 13.0.0 20220602 (experimental), GNU ld (GNU Binutils) 2.38.50.20220503) #32 SMP Tue Dec 2 12:46:23 GMT 2025 Machine model: SiFive HiFive Unmatched A00 SBI specification v0.3 detected SBI implementation ID=0x1 Version=0x9 @@ -164,6 +164,9 @@ fu740-pcie e00000000.pcie: ECAM at [mem 0xdf0000000-0xdffffffff] for [bus 00-ff] fu740-pcie e00000000.pcie: Using 256 MSI vectors fu740-pcie e00000000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4096G +fu740-pcie e00000000.pcie: dw_pcie_iatu_setup: 921 MEM index: 2 +fu740-pcie e00000000.pcie: dw_pcie_iatu_setup: 941 I/O index: 3 +fu740-pcie e00000000.pcie: dw_pcie_iatu_setup: 949 Final index: 4 fu740-pcie e00000000.pcie: cap_exp at 70 fu740-pcie e00000000.pcie: PCIe Gen.1 x8 link up fu740-pcie e00000000.pcie: changing speed back to original @@ -736,6 +739,8 @@ pcieport 0000:06:01.0: enabling bus mastering parport_pc 0000:07:00.0: enabling device (0000 -> 0001) PCI parallel port detected: 1415:c118, I/O at 0x1000(0x1008), IRQ 35 +parport0: PC-style at 0x1000 (0x1008), irq 35, using FIFO [PCSPP,TRISTATE,EPP,ECP] +lp0: using parport0 (interrupt-driven). parport_pc 0000:07:00.0: vgaarb: pci_notify serial 0000:07:00.3: vgaarb: pci_notify serial 0000:07:00.3: assign IRQ: got 40 Maciej
On Tue, Dec 02, 2025 at 01:39:14PM +0000, Maciej W. Rozycki wrote: > On Tue, 2 Dec 2025, Manivannan Sadhasivam wrote: > > > > No change in behaviour, sorry. I suppose it's this range of host address > > > decoding: > > > > > > fu740-pcie e00000000.pcie: IO 0x0060080000..0x006008ffff -> 0x0060080000 > > > > > > aka: > > > > > > pci_bus 0000:00: root bus resource [io 0x0000-0xffff] (bus address [0x60080000-0x6008ffff]) > > > > > > that you're after. Are you sure your code discovers it correctly? As I > > > say I can only see IORESOURCE_MEM references and no IORESOURCE_IO ones as > > > would be appropriate for the root bus resource quoted. > > > > The I/O resource is discovered by the driver correctly as seen from the logs: > > > > pci_bus 0000:00: root bus resource [io 0x0000-0xffff] (bus address [0x60080000-0x6008ffff]) > > pci_bus 0000:00: root bus resource [mem 0x60090000-0x7fffffff] > > pci_bus 0000:00: root bus resource [mem 0x2000000000-0x3fffffffff pref] > > > > But we believe that the iATU is not programmed for the I/O port, resulting in > > the I/O access not going out to the device. > > > > Krishna found an issue in the previous patch that got shared. So I've attached a > > new one. Could you please try and let us know? If it didn't help, please share > > the dmesg log that will have some more info. > > This does work correctly, thank you; see the log diff below (I checked > the defxx driver separately too). Cool! Thanks a lot for testing and sorry for the breakage once again. Btw, the issue that was fixed in the last diff has been present for some time. It was fortunate that you didn't hit that before. > Please make a proper submission and > I'll give it a Tested-by: tag after final verification against 6.18. > Sure thing. Krishna will post the fix(es) as there are two separate issues and will CC you. - Mani -- மணிவண்ணன் சதாசிவம்
On 9/9/2025 12:37 PM, Manivannan Sadhasivam wrote: > 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 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). nit : there is no longer a need Thanks, Alok
© 2016 - 2026 Red Hat, Inc.