Linux Documentation
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Koichiro Den <den@valinux.co.jp>, Shawn Lin <shawn.lin@rock-chips.com>
Cc: "Manivannan Sadhasivam" <mani@kernel.org>,
	"Frank Li" <Frank.Li@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	"Vinod Koul" <vkoul@kernel.org>, "Arnd Bergmann" <arnd@arndb.de>,
	"Damien Le Moal" <dlemoal@kernel.org>,
	"Marek Vasut" <marek.vasut+renesas@mailbox.org>,
	"Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>,
	linux-pci@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org
Subject: Re: [PATCH v2 0/3] PCI: endpoint: Add PCI DMA endpoint function (part 3/3)
Date: Tue, 26 May 2026 10:28:07 +0200	[thread overview]
Message-ID: <ahVZl6YRlBB_OBlz@ryzen> (raw)
In-Reply-To: <b5qre4rphbq4datwi3apyh5jy5b7obz4aj3pfn2gzmke6znmib@gpdbheezoi2z>

On Tue, May 26, 2026 at 03:23:57PM +0900, Koichiro Den wrote:
> On Tue, May 26, 2026 at 07:35:06AM +0200, Niklas Cassel wrote:
> 
> Yes, I also think the architecture of this series is much cleaner. The option 2
> series may look like it overloads and complicates vNTB a bit too much, and the
> auxiliary device created from ntb_hw_epf only for the channel delegation purpose
> may look awkward to some.
> 
> The coverage concern is a real downside of this direction though. This is a
> trade-off between a cleaner PCI/DMA model and broader EPC coverage. On my side,
> R-Car Gen4+ is the main target, so the multi-function requirement is acceptable.
> In that sense, I am also curious whether future DWC-based SoCs will typically
> support more than one function or not.

It seems that the number of supported physical functions is controlled by
the configurable PCIe IP-core synthesize parameter CX_NFUNC.


Looking at the code, if the device tree property 'max-functions' is missing,
it will set epc->max_functions to 1:

$ git show f8aed6ec624f

It has been like this since the initial EP support in the DWC driver, added
in 2017.

However, a missing 'max-functions' device tree property does not necessarily
mean that the IP-core was configured with CX_NFUNC == 1.


Right now, I don't see any register to get CX_NFUNC.

Perhaps it is possible to write some code that figures out CX_NFUNC, by
writing different values to the iATU registers, somewhat similar to how we
detect the number of inbound and outbound iATUs:
https://github.com/torvalds/linux/blob/v7.1-rc5/drivers/pci/controller/dwc/pcie-designware.c#L998-L1001



I added EP mode support for the pcie-dw-rockchip driver, but I don't know
the CX_NFUNC parameter value, so I could not add a 'max-functions' property.

While it is possible that some DWC-based PCIe endpoint controllers are
configured with CX_NFUNC == 1, it is also possible that some people simply
did now add a 'max-functions' property, because they did not know the CX_NFUNC
value, just like me.


Shawn Lin, do you perhaps know the CX_NFUNC value for rk3588 and rk3568 ?


Kind regards,
Niklas

      reply	other threads:[~2026-05-26  8:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-25  6:34 [PATCH v2 0/3] PCI: endpoint: Add PCI DMA endpoint function (part 3/3) Koichiro Den
2026-05-25  6:34 ` [PATCH v2 1/3] dmaengine: dw-edma-pcie: Discover endpoint DMA metadata Koichiro Den
2026-05-25  6:34 ` [PATCH v2 2/3] PCI: endpoint: Add DMA endpoint function Koichiro Den
2026-05-25  6:34 ` [PATCH v2 3/3] Documentation: PCI: Add PCI DMA endpoint function documentation Koichiro Den
2026-05-25 18:05   ` Randy Dunlap
2026-05-26  2:18     ` Koichiro Den
2026-05-25  7:05 ` [PATCH v2 0/3] PCI: endpoint: Add PCI DMA endpoint function (part 3/3) Koichiro Den
2026-05-25  8:35   ` Niklas Cassel
2026-05-25 14:03     ` Koichiro Den
2026-05-25 20:32       ` Niklas Cassel
2026-05-26  2:04         ` Koichiro Den
2026-05-26  5:35           ` Niklas Cassel
2026-05-26  6:23             ` Koichiro Den
2026-05-26  8:28               ` Niklas Cassel [this message]

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=ahVZl6YRlBB_OBlz@ryzen \
    --to=cassel@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=den@valinux.co.jp \
    --cc=dlemoal@kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=kishon@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=shawn.lin@rock-chips.com \
    --cc=skhan@linuxfoundation.org \
    --cc=vkoul@kernel.org \
    --cc=yoshihiro.shimoda.uh@renesas.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox