Message-ID: <ihappv6m5k7hvbfn7h65j7e52jqben7mgrvg7sem3hskfzgxyn@meq5xq33hgpc>
Date: Mon, 29 Sep 2025 19:55:50 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Randolph Lin <randolph@...estech.com>, linux-kernel@...r.kernel.org, 
	linux-pci@...r.kernel.org, linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org, 
	jingoohan1@...il.com, lpieralisi@...nel.org, kwilczynski@...nel.org, robh@...nel.org, 
	bhelgaas@...gle.com, krzk+dt@...nel.org, conor+dt@...nel.org, alex@...ti.fr, 
	aou@...s.berkeley.edu, palmer@...belt.com, paul.walmsley@...ive.com, 
	ben717@...estech.com, inochiama@...il.com, thippeswamy.havalige@....com, 
	namcao@...utronix.de, shradha.t@...sung.com, randolph.sklin@...il.com, 
	tim609@...estech.com
Subject: Re: [PATCH v3 1/5] PCI: dwc: Skip failed outbound iATU and continue

On Fri, Sep 26, 2025 at 04:10:23PM -0500, Bjorn Helgaas wrote:
> On Wed, Sep 24, 2025 at 08:58:11PM +0800, Randolph Lin wrote:
> > On Tue, Sep 23, 2025 at 09:42:23AM -0500, Bjorn Helgaas wrote:
> > > On Tue, Sep 23, 2025 at 07:36:43PM +0800, Randolph Lin wrote:
> > > > Previously, outbound iATU programming included range checks
> > > > based on hardware limitations. If a configuration did not meet
> > > > these constraints, the loop would stop immediately.
> > > >
> > > > This patch updates the behavior to enhance flexibility. Instead
> > > > of stopping at the first issue, it now logs a warning with
> > > > details of the affected window and proceeds to program the
> > > > remaining iATU entries.
> > > >
> > > > This enables partial configuration to complete in cases where
> > > > some iATU windows may not meet requirements, improving overall
> > > > compatibility.
> > > 
> > > It's not really clear why this is needed.  I assume it's related
> > > to dropping qilai_pcie_outbound_atu_addr_valid().
> > 
> > Yes, I want to drop the previous atu_addr_valid function.
> > 
> > > I guess dw_pcie_prog_outbound_atu() must return an error for one
> > > of the QiLai ranges?  Which one, and what exactly is the problem?
> > > I still suspect something wrong in the devicetree description.
> > 
> > The main issue is not the returned error; just need to avoid
> > terminating the process when the configuration exceeds the
> > hardware’s expected limits.
> > 
> > There are two methods to fix the issue on the Qilai SoC:
> > 
> > 1. Simply skip the entries that do not match the designware hardware
> > iATU limitations.  An error will be returned, but it can be ignored.
> > On the Qilai SoC, the iATU limitation is the 4GB boundary. Qilai SoC
> > only need to configure iATU support to translate addresses below the
> > "32-bits" address range. Although 64-bits addresses do not match the
> > designware hardware iATU limitations, there is no need to configure
> > 64-bits addresses, since the connection is hard-wired.
> > 

Why does the DT supplies broken 'ranges' in the first place? DT describes the
hardware and if the hardware only supports 32bit OB window, then DT has to
supply the range accordingly. It is not currently clear on what issue you are
trying to solve by skipping the range check for broken resources.

> > 2. Set the devicetree only 2 viewport for iATU and force using
> > devicetree value.  This is a workaround in the devicetree, but the
> > fix logic is not easy to document.  Instead, we should enforce the
> > use of the viewport defined in the devicetree and modify the
> > designware generic code accordingly — using the viewport values from
> > the devicetree instead of reading them from the designware
> > registers.  Since only two viewports are available for iATU, we
> > should reserve one for the configuration registers and the other for
> > 32-bit address access.  Therefore, reverse logic still needs to be
> > added to the designware generic code.
> > 

'num-viewport' property is deprecated. So should not be used in new DTs.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Powered by blists - more mailing lists