[PATCH v13 4/9] irqchip/gic-v3-its: Add DOMAIN_BUS_DEVICE_PCI_EP_MSI support

Marc Zyngier maz at kernel.org
Thu Dec 19 02:52:30 PST 2024


On Wed, 18 Dec 2024 23:08:39 +0000,
Frank Li <Frank.Li at nxp.com> wrote:
> 
>            ┌────────────────────────────────┐
>            │                                │
>            │     PCI Endpoint Controller    │
>            │                                │
>            │   ┌─────┐  ┌─────┐     ┌─────┐ │
> PCI Bus    │   │     │  │     │     │     │ │
> ─────────► │   │Func1│  │Func2│ ... │Func │ │
> Doorbell   │   │     │  │     │     │<n>  │ │
>            │   │     │  │     │     │     │ │
>            │   └──┬──┘  └──┬──┘     └──┬──┘ │
>            │      │        │           │    │
>            └──────┼────────┼───────────┼────┘
>                   │        │           │
>                   ▼        ▼           ▼
>                ┌────────────────────────┐
>                │    MSI Controller      │
>                └────────────────────────┘
> 
> Add domain DOMAIN_BUS_DEVICE_PCI_EP_MSI to allocate MSI domain for Endpoint
> function in PCI Endpoint (EP) controller, So PCI Root Complex (RC) can
> write MSI message to MSI controller to trigger doorbell IRQ for difference
> EP functions.
> 
> Signed-off-by: Frank Li <Frank.Li at nxp.com>
> ---
> change from v12 to v13
> - new patch

This might be v13, but after all this time, I have no idea what you
are trying to do. You keep pasting this non-ASCII drawing in commit
messages, but I still have no idea what this PCI Bus Doorbell
represents.

I appreciate the knowledge shortage is on my end, but it would
definitely help if someone would take the time to explain what this is
all about.

From what I gather, the ITS is actually on an end-point, and get
writes from the host, but that doesn't answer much.

> ---
>  drivers/irqchip/irq-gic-v3-its-msi-parent.c | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its-msi-parent.c b/drivers/irqchip/irq-gic-v3-its-msi-parent.c
> index b2a4b67545b82..16e7d53f0b133 100644
> --- a/drivers/irqchip/irq-gic-v3-its-msi-parent.c
> +++ b/drivers/irqchip/irq-gic-v3-its-msi-parent.c
> @@ -5,6 +5,7 @@
>  // Copyright (C) 2022 Intel
>  
>  #include <linux/acpi_iort.h>
> +#include <linux/pci-ep-msi.h>
>  #include <linux/pci.h>
>  
>  #include "irq-gic-common.h"
> @@ -173,6 +174,19 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
>  	return its_pmsi_prepare_devid(domain, dev, nvec, info, dev_id);
>  }
>  
> +static int its_pci_ep_msi_prepare(struct irq_domain *domain, struct device *dev,
> +				  int nvec, msi_alloc_info_t *info)
> +{
> +	u32 dev_id;
> +	int ret;
> +
> +	ret = pci_epf_msi_domain_get_msi_rid(dev, &dev_id);

What this doesn't express is *how* are the writes conveyed to the ITS.
Specifically, the DevID is normally sampled as sideband information at
during the write transaction.

Obviously, you can't do that over PCI. So there is a lot of
undisclosed assumption about how the ITS is integrated, and how it
samples the DevID.

My conclusion is that this is not as generic as it seems to be. It is
definitely tied to implementation-specific behaviours, none of which
are explained.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.



More information about the linux-arm-kernel mailing list