All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Frank Li <Frank.Li@nxp.com>
Cc: "Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Anup Patel" <apatel@ventanamicro.com>,
	"Marc Zyngier" <maz@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Arnd Bergmann" <arnd@arndb.de>, "Shuah Khan" <shuah@kernel.org>,
	"Richard Zhu" <hongxing.zhu@nxp.com>,
	"Lucas Stach" <l.stach@pengutronix.de>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Fabio Estevam" <festevam@gmail.com>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Niklas Cassel" <cassel@kernel.org>,
	dlemoal@kernel.org, jdmason@kudzu.us,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
	linux-kselftest@vger.kernel.org, imx@lists.linux.dev,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v17 04/15] dt-bindings: PCI: pci-ep: Add support for iommu-map and msi-map
Date: Fri, 11 Apr 2025 09:38:40 -0500	[thread overview]
Message-ID: <20250411143840.GA3153754-robh@kernel.org> (raw)
In-Reply-To: <20250407-ep-msi-v17-4-633ab45a31d0@nxp.com>

On Mon, Apr 07, 2025 at 03:50:54PM -0400, Frank Li wrote:
> Document the use of (msi|iommu)-map for PCI Endpoint (EP) controllers,
> which can use MSI as a doorbell mechanism. Each EP controller can support
> up to 8 physical functions and 65,536 virtual functions.
> 
> Define how to construct device IDs using function bits [2:0] and virtual
> function index bits [31:3], enabling (msi|iommu)-map to associate each
> child device with a specific (msi|iommu)-specifier.
> 
> The EP cannot rely on PCI Requester ID (RID) because the RID is determined
> by the PCI topology of the host system. Since the EP may be connected to
> different PCI hosts, the RID can vary between systems and is therefore not
> a reliable identifier.
> 
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> Change from v16 to v17
> - new patch
> ---
>  Documentation/devicetree/bindings/pci/pci-ep.yaml | 67 +++++++++++++++++++++++
>  1 file changed, 67 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci-ep.yaml b/Documentation/devicetree/bindings/pci/pci-ep.yaml
> index f75000e3093db..a1a5b9b8ef859 100644
> --- a/Documentation/devicetree/bindings/pci/pci-ep.yaml
> +++ b/Documentation/devicetree/bindings/pci/pci-ep.yaml
> @@ -53,6 +53,73 @@ properties:
>        must be unique.
>      $ref: /schemas/types.yaml#/definitions/uint32
>  
> +  msi-map:

Not that the rest of the file is alphabetized, but put i before m.

> +    description: |
> +      Maps a Device ID to an MSI and associated MSI specifier data.
> +
> +      A PCI Endpoint (EP) can use MSI as a doorbell function. This is achieved by
> +      mapping the MSI controller's address into PCI BAR<n>. The PCI Root Complex
> +      can write to this BAR<n>, triggering the EP to generate IRQ. This notifies
> +      the EP-side driver of an event, eliminating the need for the driver to
> +      continuously poll for status changes.
> +
> +      However, the EP cannot rely on Requester ID (RID) because the RID is
> +      determined by the PCI topology of the host system. Since the EP may be
> +      connected to different PCI hosts, the RID can vary between systems and is
> +      therefore not a reliable identifier.
> +
> +      Each EP can support up to 8 physical functions and up to 65,536 virtual
> +      functions. To uniquely identify each child device, a device ID is defined
> +      as
> +         - Bits [2:0] for the function number (func)
> +         - Bits [18:3] for the virtual function index (vfunc)
> +
> +      The resulting device ID is computed as:
> +
> +        (func & 0x7) | (vfunc << 3)
> +
> +      The property is an arbitrary number of tuples of
> +      (device-id-base, msi, msi-base,length).
> +
> +      Any Device ID id in the interval [id-base, id-base + length) is
> +      associated with the listed MSI, with the MSI specifier
> +      (id - id-base + msi-base).
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +    items:
> +      items:
> +        - description: The Device ID base matched by the entry
> +          maximum: 0x7ffff
> +        - description: phandle to msi-controller node
> +        - description: (optional) The msi-specifier produced for the first
> +            Device ID matched by the entry. Currently, msi-specifier is 0 or
> +            1 cells.
> +        - description: The length of consecutive Device IDs following the
> +            Device ID base
> +          maximum: 0x80000
> +
> +  msi-map-mask:
> +    description: A mask to be applied to each Device ID prior to being
> +      mapped to an msi-specifier per the msi-map property.
> +    $ref: /schemas/types.yaml#/definitions/uint32

maximum: 0x7ffff ?

> +
> +  iommu-map:
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +    items:
> +      items:
> +        - description: Device ID (see msi-map) base
> +          maximum: 0x7ffff
> +        - description: phandle to IOMMU
> +        - description: IOMMU specifier base (currently always 1 cell)
> +        - description: Number of Device IDs
> +          maximum: 0x80000
> +
> +  iommu-map-mask:
> +    description:
> +      A mask to be applied to each Device ID prior to being mapped to an
> +      IOMMU specifier per the iommu-map property.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    maximum: 0xffff

0x7ffff ?

> +
>  required:
>    - compatible
>  
> 
> -- 
> 2.34.1
> 

  reply	other threads:[~2025-04-11 14:38 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-07 19:50 [PATCH v17 00/15] PCI: EP: Add RC-to-EP doorbell with platform MSI controller Frank Li
2025-04-07 19:50 ` [PATCH v17 01/15] platform-msi: Add msi_remove_device_irq_domain() in platform_device_msi_free_irqs_all() Frank Li
2025-04-07 19:50 ` [PATCH v17 02/15] irqdomain: Add IRQ_DOMAIN_FLAG_MSI_IMMUTABLE and irq_domain_is_msi_immutable() Frank Li
2025-04-07 19:50 ` [PATCH v17 03/15] irqchip/gic-v3-its: Set IRQ_DOMAIN_FLAG_MSI_IMMUTABLE for ITS Frank Li
2025-04-07 19:50 ` [PATCH v17 04/15] dt-bindings: PCI: pci-ep: Add support for iommu-map and msi-map Frank Li
2025-04-11 14:38   ` Rob Herring [this message]
2025-04-07 19:50 ` [PATCH v17 05/15] irqchip/gic-v3-its: Add support for device tree msi-map and msi-mask Frank Li
2025-04-07 19:50 ` [PATCH v17 06/15] PCI: endpoint: Set ID and of_node for function driver Frank Li
2025-04-07 19:50 ` [PATCH v17 07/15] PCI: endpoint: Add RC-to-EP doorbell support using platform MSI controller Frank Li
2025-04-07 19:50 ` [PATCH v17 08/15] PCI: endpoint: pci-ep-msi: Add MSI address/data pair mutable check Frank Li
2025-04-07 19:50 ` [PATCH v17 09/15] PCI: endpoint: Add pci_epf_align_inbound_addr() helper for address alignment Frank Li
2025-04-07 19:51 ` [PATCH v17 10/15] PCI: endpoint: pci-epf-test: Add doorbell test support Frank Li
2025-04-07 19:51 ` [PATCH v17 11/15] misc: pci_endpoint_test: Add doorbell test case Frank Li
2025-04-07 19:51 ` [PATCH v17 12/15] selftests: pci_endpoint: " Frank Li
2025-04-07 19:51 ` [PATCH v17 13/15] pci: imx6: Add helper function imx_pcie_add_lut_by_rid() Frank Li
2025-04-07 19:51 ` [PATCH v17 14/15] pci: imx6: Add LUT setting for MSI/IOMMU in Endpoint mode Frank Li
2025-04-07 19:51 ` [PATCH v17 15/15] arm64: dts: imx95: Add msi-map for pci-ep device 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=20250411143840.GA3153754-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=Frank.Li@nxp.com \
    --cc=apatel@ventanamicro.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=dakr@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=festevam@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hongxing.zhu@nxp.com \
    --cc=imx@lists.linux.dev \
    --cc=jdmason@kudzu.us \
    --cc=kernel@pengutronix.de \
    --cc=kishon@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=kw@linux.com \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=maz@kernel.org \
    --cc=rafael@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=shuah@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 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.