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
prev parent 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