From: Bjorn Helgaas <helgaas@kernel.org>
To: Randolph Lin <randolph@andestech.com>
Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
jingoohan1@gmail.com, mani@kernel.org, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
krzk+dt@kernel.org, conor+dt@kernel.org, alex@ghiti.fr,
aou@eecs.berkeley.edu, palmer@dabbelt.com,
paul.walmsley@sifive.com, ben717@andestech.com,
inochiama@gmail.com, thippeswamy.havalige@amd.com,
namcao@linutronix.de, shradha.t@samsung.com,
randolph.sklin@gmail.com, tim609@andestech.com
Subject: Re: [PATCH v3 1/5] PCI: dwc: Skip failed outbound iATU and continue
Date: Fri, 26 Sep 2025 16:10:23 -0500 [thread overview]
Message-ID: <20250926211023.GA2128495@bhelgaas> (raw)
In-Reply-To: <aNPq42O1Ml3ppF2M@swlinux02>
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.
>
> 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.
>
> Method 2 adds excessive complexity to the designware generic code.
> Instead, directly configuring the iATU and reporting an error when
> the configuration exceeds the hardware iATU limitations is a simpler
> and more effective approach to applying the fix.
I don't know the DesignWare iATU design very well, so I don't know if
this issue is something unique to Qilai or if it's something that
could be handled via devicetree.
Will look for input/acks from DesignWare maintainers (Jingoo, Mani).
> Conclusion:
> 1. The iATU needs to be configured for 32-bits address space.
> In compliance with hardware limitations.
> 2. The iATU needs to be configured for config space.
> In compliance with hardware limitations.
> 3. The iATU needs to be configured for 64-bit address space.
> This does not comply with hardware limitations and will print an error.
> As long as it does not return an error value that terminates subsequent
> operations, it is acceptable.
> Simply skipping this entry when configuring the iATU is acceptable.
>
> > > Signed-off-by: Randolph Lin <randolph@andestech.com>
> > > ---
> > > drivers/pci/controller/dwc/pcie-designware-host.c | 9 +++++----
> > > 1 file changed, 5 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > index 952f8594b501..91ee6b903934 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > @@ -756,7 +756,7 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
> > > if (resource_type(entry->res) != IORESOURCE_MEM)
> > > continue;
> > >
> > > - if (pci->num_ob_windows <= ++i)
> > > + if (pci->num_ob_windows <= i)
> > > break;
> > >
> > > atu.index = i;
> > > @@ -773,9 +773,10 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
> > >
> > > ret = dw_pcie_prog_outbound_atu(pci, &atu);
> > > if (ret) {
> > > - dev_err(pci->dev, "Failed to set MEM range %pr\n",
> > > - entry->res);
> > > - return ret;
> > > + dev_warn(pci->dev, "Failed to set MEM range %pr\n",
> > > + entry->res);
> > > + } else {
> > > + i++;
> > > }
> > > }
> > >
> > > --
> > > 2.34.1
> > >
> > >
> > > _______________________________________________
> > > linux-riscv mailing list
> > > linux-riscv@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> Sincerely,
> Randolph
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Randolph Lin <randolph@andestech.com>
Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
jingoohan1@gmail.com, mani@kernel.org, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
krzk+dt@kernel.org, conor+dt@kernel.org, alex@ghiti.fr,
aou@eecs.berkeley.edu, palmer@dabbelt.com,
paul.walmsley@sifive.com, ben717@andestech.com,
inochiama@gmail.com, thippeswamy.havalige@amd.com,
namcao@linutronix.de, shradha.t@samsung.com,
randolph.sklin@gmail.com, tim609@andestech.com
Subject: Re: [PATCH v3 1/5] PCI: dwc: Skip failed outbound iATU and continue
Date: Fri, 26 Sep 2025 16:10:23 -0500 [thread overview]
Message-ID: <20250926211023.GA2128495@bhelgaas> (raw)
In-Reply-To: <aNPq42O1Ml3ppF2M@swlinux02>
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.
>
> 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.
>
> Method 2 adds excessive complexity to the designware generic code.
> Instead, directly configuring the iATU and reporting an error when
> the configuration exceeds the hardware iATU limitations is a simpler
> and more effective approach to applying the fix.
I don't know the DesignWare iATU design very well, so I don't know if
this issue is something unique to Qilai or if it's something that
could be handled via devicetree.
Will look for input/acks from DesignWare maintainers (Jingoo, Mani).
> Conclusion:
> 1. The iATU needs to be configured for 32-bits address space.
> In compliance with hardware limitations.
> 2. The iATU needs to be configured for config space.
> In compliance with hardware limitations.
> 3. The iATU needs to be configured for 64-bit address space.
> This does not comply with hardware limitations and will print an error.
> As long as it does not return an error value that terminates subsequent
> operations, it is acceptable.
> Simply skipping this entry when configuring the iATU is acceptable.
>
> > > Signed-off-by: Randolph Lin <randolph@andestech.com>
> > > ---
> > > drivers/pci/controller/dwc/pcie-designware-host.c | 9 +++++----
> > > 1 file changed, 5 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > index 952f8594b501..91ee6b903934 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > @@ -756,7 +756,7 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
> > > if (resource_type(entry->res) != IORESOURCE_MEM)
> > > continue;
> > >
> > > - if (pci->num_ob_windows <= ++i)
> > > + if (pci->num_ob_windows <= i)
> > > break;
> > >
> > > atu.index = i;
> > > @@ -773,9 +773,10 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
> > >
> > > ret = dw_pcie_prog_outbound_atu(pci, &atu);
> > > if (ret) {
> > > - dev_err(pci->dev, "Failed to set MEM range %pr\n",
> > > - entry->res);
> > > - return ret;
> > > + dev_warn(pci->dev, "Failed to set MEM range %pr\n",
> > > + entry->res);
> > > + } else {
> > > + i++;
> > > }
> > > }
> > >
> > > --
> > > 2.34.1
> > >
> > >
> > > _______________________________________________
> > > linux-riscv mailing list
> > > linux-riscv@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> Sincerely,
> Randolph
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-09-26 21:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 11:36 [PATCH v3 0/5] Add support for Andes Qilai SoC PCIe controller Randolph Lin
2025-09-23 11:36 ` [PATCH v3 1/5] PCI: dwc: Skip failed outbound iATU and continue Randolph Lin
2025-09-23 14:42 ` Bjorn Helgaas
2025-09-23 14:42 ` Bjorn Helgaas
2025-09-24 12:58 ` Randolph Lin
2025-09-24 12:58 ` Randolph Lin
2025-09-26 21:10 ` Bjorn Helgaas [this message]
2025-09-26 21:10 ` Bjorn Helgaas
2025-09-29 14:03 ` Rob Herring
2025-09-29 14:03 ` Rob Herring
2025-09-30 12:05 ` Randolph Lin
2025-09-30 12:05 ` Randolph Lin
2025-09-29 14:25 ` Manivannan Sadhasivam
2025-09-29 14:25 ` Manivannan Sadhasivam
2025-09-23 11:36 ` [PATCH v3 2/5] dt-bindings: PCI: Add Andes QiLai PCIe support Randolph Lin
2025-09-23 11:36 ` [PATCH v3 3/5] riscv: dts: andes: Add PCIe node into the QiLai SoC Randolph Lin
2025-09-23 11:36 ` [PATCH v3 4/5] PCI: andes: Add Andes QiLai SoC PCIe host driver support Randolph Lin
2025-09-23 15:54 ` Bjorn Helgaas
2025-09-23 15:54 ` Bjorn Helgaas
2025-09-23 11:36 ` [PATCH v3 5/5] MAINTAINERS: Add maintainers for Andes QiLai PCIe driver Randolph Lin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250926211023.GA2128495@bhelgaas \
--to=helgaas@kernel.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=ben717@andestech.com \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=inochiama@gmail.com \
--cc=jingoohan1@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=namcao@linutronix.de \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=randolph.sklin@gmail.com \
--cc=randolph@andestech.com \
--cc=robh@kernel.org \
--cc=shradha.t@samsung.com \
--cc=thippeswamy.havalige@amd.com \
--cc=tim609@andestech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.