All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@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, pjw@kernel.org,
	randolph.sklin@gmail.com, tim609@andestech.com
Subject: Re: [PATCH v6 1/5] PCI: dwc: Allow adjusting the number of ob/ib windows in glue driver
Date: Tue, 14 Oct 2025 11:43:53 +0200	[thread overview]
Message-ID: <aO4bWRqX_4rXud25@ryzen> (raw)
In-Reply-To: <20251003023527.3284787-2-randolph@andestech.com>

On Fri, Oct 03, 2025 at 10:35:23AM +0800, Randolph Lin wrote:
> The number of ob/ib windows is determined through write-read loops
> on registers in the core driver. Some glue drivers need to adjust
> the number of ob/ib windows to meet specific requirements,such as

Missing space after comma.


> hardware limitations. This change allows the glue driver to adjust
> the number of ob/ib windows to satisfy platform-specific constraints.
> The glue driver may adjust the number of ob/ib windows, but the values
> must stay within hardware limits.

Could we please get a better explaination than "satisfy platform-specific
constraints" ?

Your PCIe controller is synthesized with a certain number of {in,out}bound
windows, and I assume that dw_pcie_iatu_detect() correctly detects the number
of {in,out}bound windows, and initializes num_ob_windows/num_ib_windows
accordingly.

So, is the problem that because of some errata, you cannot use all the
{in,out}bound windows of the iATU?

Because it is hard to understand what kind of "hardware limit" that would
cause your SoC to not be able to use all the available {in,out}bound windows.

Because it is simply a mapping in the iATU (internal Address Translation Unit).

In fact, in many cases, e.g. the NVMe EPF driver, then number of {in,out}bound
windows is a major limiting factor of how many outstanding I/Os you can have,
so usually, you really want to be able to use the maximum that the hardware
supports.


TL;DR: to modify this common code, I think your reasoning has to be more
detailed.



Kind regards,
Niklas

WARNING: multiple messages have this Message-ID (diff)
From: Niklas Cassel <cassel@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, pjw@kernel.org,
	randolph.sklin@gmail.com, tim609@andestech.com
Subject: Re: [PATCH v6 1/5] PCI: dwc: Allow adjusting the number of ob/ib windows in glue driver
Date: Tue, 14 Oct 2025 11:43:53 +0200	[thread overview]
Message-ID: <aO4bWRqX_4rXud25@ryzen> (raw)
In-Reply-To: <20251003023527.3284787-2-randolph@andestech.com>

On Fri, Oct 03, 2025 at 10:35:23AM +0800, Randolph Lin wrote:
> The number of ob/ib windows is determined through write-read loops
> on registers in the core driver. Some glue drivers need to adjust
> the number of ob/ib windows to meet specific requirements,such as

Missing space after comma.


> hardware limitations. This change allows the glue driver to adjust
> the number of ob/ib windows to satisfy platform-specific constraints.
> The glue driver may adjust the number of ob/ib windows, but the values
> must stay within hardware limits.

Could we please get a better explaination than "satisfy platform-specific
constraints" ?

Your PCIe controller is synthesized with a certain number of {in,out}bound
windows, and I assume that dw_pcie_iatu_detect() correctly detects the number
of {in,out}bound windows, and initializes num_ob_windows/num_ib_windows
accordingly.

So, is the problem that because of some errata, you cannot use all the
{in,out}bound windows of the iATU?

Because it is hard to understand what kind of "hardware limit" that would
cause your SoC to not be able to use all the available {in,out}bound windows.

Because it is simply a mapping in the iATU (internal Address Translation Unit).

In fact, in many cases, e.g. the NVMe EPF driver, then number of {in,out}bound
windows is a major limiting factor of how many outstanding I/Os you can have,
so usually, you really want to be able to use the maximum that the hardware
supports.


TL;DR: to modify this common code, I think your reasoning has to be more
detailed.



Kind regards,
Niklas

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2025-10-14  9:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-03  2:35 [PATCH v6 0/5] Add support for Andes Qilai SoC PCIe controller Randolph Lin
2025-10-03  2:35 ` Randolph Lin
2025-10-03  2:35 ` [PATCH v6 1/5] PCI: dwc: Allow adjusting the number of ob/ib windows in glue driver Randolph Lin
2025-10-03  2:35   ` Randolph Lin
2025-10-14  9:43   ` Niklas Cassel [this message]
2025-10-14  9:43     ` Niklas Cassel
2025-10-16 11:12     ` Randolph Lin
2025-10-16 11:12       ` Randolph Lin
2025-10-16 11:54       ` Niklas Cassel
2025-10-16 11:54         ` Niklas Cassel
2025-10-20 11:35         ` Randolph Lin
2025-10-20 11:35           ` Randolph Lin
2025-10-03  2:35 ` [PATCH v6 2/5] dt-bindings: PCI: Add Andes QiLai PCIe support Randolph Lin
2025-10-03  2:35   ` Randolph Lin
2025-10-06 18:52   ` Rob Herring
2025-10-06 18:52     ` Rob Herring
2025-10-03  2:35 ` [PATCH v6 3/5] riscv: dts: andes: Add PCIe node into the QiLai SoC Randolph Lin
2025-10-03  2:35   ` Randolph Lin
2025-10-03  2:35 ` [PATCH v6 4/5] PCI: andes: Add Andes QiLai SoC PCIe host driver support Randolph Lin
2025-10-03  2:35   ` Randolph Lin
2025-10-03  2:35 ` [PATCH v6 5/5] MAINTAINERS: Add maintainers for Andes QiLai PCIe driver Randolph Lin
2025-10-03  2:35   ` Randolph Lin
  -- strict thread matches above, loose matches on Subject: below --
2025-10-09 14:09 [PATCH v6 4/5] PCI: andes: Add Andes QiLai SoC PCIe host driver support kernel test robot
2025-10-14  7:33 ` Dan Carpenter
2025-10-14  7:33 ` Dan Carpenter

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=aO4bWRqX_4rXud25@ryzen \
    --to=cassel@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=pjw@kernel.org \
    --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.