[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2511280755440.36486@angie.orcam.me.uk>
Date: Fri, 28 Nov 2025 08:37:36 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>
cc: Manivannan Sadhasivam <mani@...nel.org>, Jingoo Han <jingoohan1@...il.com>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof WilczyĆski <kwilczynski@...nel.org>,
Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Alim Akhtar <alim.akhtar@...sung.com>,
Jonathan Chocron <jonnyc@...zon.com>, linux-pci@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-samsung-soc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v9 4/4] PCI: dwc: Support ECAM mechanism by enabling iATU
'CFG Shift Feature'
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@...000000
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
Download attachment "pci-xxxx-good.log.xz" of type "application/x-xz" (4144 bytes)
Download attachment "pci-xxxx-bad.log.xz" of type "application/x-xz" (4208 bytes)
Powered by blists - more mailing lists