linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Frank Li <Frank.li@nxp.com>
Cc: "Marc Zyngier" <maz@kernel.org>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Anup Patel" <apatel@ventanamicro.com>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	imx@lists.linux.dev, dlemoal@kernel.org, jdmason@kudzu.us,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v13 4/9] irqchip/gic-v3-its: Add DOMAIN_BUS_DEVICE_PCI_EP_MSI support
Date: Thu, 19 Dec 2024 21:43:15 +0100	[thread overview]
Message-ID: <Z2SFYwC7KC-qiZD2@ryzen> (raw)
In-Reply-To: <Z2R/S4y3fF2Dw4Ye@lizhi-Precision-Tower-5810>

On Thu, Dec 19, 2024 at 03:17:15PM -0500, Frank Li wrote:
> 
> Thank you very much. I update msi part, so endpoint controller node align
> host controller node.
> 
> It should be
> msi-map = <0x0000 &its1 0x0000 0x1000>;
> 
> So if your hardware support multi physical function, your can create more
> than one pci_test func. Previous version only support one EP func.

I see. That seems like an improvement.
I will need to ask Rockchip maintainer to drop my msi-parent patch for PCIe
EP node then. (Which is currently queued up in for-6.14)

However, for the PCIe host node, rk3588 has:
iommu-map = <0x0000 &mmu600_pcie 0x0000 0x1000>;

For the PCIe endpoint node, rk3588 has:
iommus = <&mmu600_pcie 0x0000>;

https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?h=v6.14-armsoc/dts64&id=da92d3dfc871e821a1bface3ba5afcf8cda19805

Is it fine that for the PCIe EP node, we specify iommu mapping using:
iommus = <&mmu600_pcie 0x0000>;
but the ITS/MSI map will be:
msi-map = <0x0000 &its1 0x0000 0x1000>;

isn't this a bit inconsistent?

The physical function is the "F" in the BDF.
Does this mean that:
iommus = <&mmu600_pcie 0x0000>;
the IOMMU will not be able to distinguish different PCI physical functions
from the same PCI device? So two different physical functions on the same
PCI device share the same IOMMU mappings?


Kind regards,
Niklas


  reply	other threads:[~2024-12-19 21:55 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-18 23:08 [PATCH v13 0/9] PCI: EP: Add RC-to-EP doorbell with platform MSI controller Frank Li
2024-12-18 23:08 ` [PATCH v13 1/9] genirq/msi: Provide DOMAIN_BUS_PLATFORM_PCI_EP_MSI Frank Li
2024-12-18 23:08 ` [PATCH v13 2/9] PCI: EP: Add helper function pci_epf_msi_domain_get_msi_rid() Frank Li
2024-12-18 23:08 ` [PATCH v13 3/9] irqchip/gic-v3-its: Add helper function its_pmsi_prepare_devid() Frank Li
2024-12-18 23:08 ` [PATCH v13 4/9] irqchip/gic-v3-its: Add DOMAIN_BUS_DEVICE_PCI_EP_MSI support Frank Li
2024-12-19 10:52   ` Marc Zyngier
2024-12-19 17:02     ` Frank Li
2024-12-19 20:10       ` Niklas Cassel
2024-12-19 20:17         ` Frank Li
2024-12-19 20:43           ` Niklas Cassel [this message]
2024-12-19 20:53             ` Frank Li
2025-01-06 16:38       ` Frank Li
2025-01-06 17:13         ` Marc Zyngier
2025-01-06 18:20           ` Frank Li
2025-01-13 16:11             ` Frank Li
2025-01-20 21:20               ` Frank Li
2024-12-18 23:08 ` [PATCH v13 5/9] PCI: endpoint: Add RC-to-EP doorbell support using platform MSI controller Frank Li
2024-12-18 23:08 ` [PATCH v13 6/9] PCI: endpoint: Add pci_epf_align_inbound_addr() helper for address alignment Frank Li
2024-12-18 23:08 ` [PATCH v13 7/9] PCI: endpoint: pci-epf-test: Add doorbell test support Frank Li
2024-12-18 23:08 ` [PATCH v13 8/9] misc: pci_endpoint_test: Add doorbell test case Frank Li
2024-12-18 23:08 ` [PATCH v13 9/9] tools: PCI: Add 'B' option for test doorbell Frank Li

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=Z2SFYwC7KC-qiZD2@ryzen \
    --to=cassel@kernel.org \
    --cc=Frank.li@nxp.com \
    --cc=apatel@ventanamicro.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=dlemoal@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=imx@lists.linux.dev \
    --cc=jdmason@kudzu.us \
    --cc=kishon@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=maz@kernel.org \
    --cc=rafael@kernel.org \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).