Messages in this thread | | | From | "Gupta, Nipun" <> | Subject | RE: [RFC PATCH 1/2] irqchip: cdx-bus: add cdx-MSI domain with gic-its domain as parent | Date | Thu, 4 Aug 2022 09:18:19 +0000 |
| |
[AMD Official Use Only - General]
> -----Original Message----- > From: Marc Zyngier <maz@kernel.org> > Sent: Thursday, August 4, 2022 2:20 PM > To: Gupta, Nipun <Nipun.Gupta@amd.com> > Cc: linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; > gregkh@linuxfoundation.org; rafael@kernel.org; tglx@linutronix.de; > okaya@kernel.org; Anand, Harpreet <harpreet.anand@amd.com>; Simek, > Michal <michal.simek@amd.com>; Agarwal, Nikhil > <nikhil.agarwal@amd.com> > Subject: Re: [RFC PATCH 1/2] irqchip: cdx-bus: add cdx-MSI domain with gic- > its domain as parent > > [CAUTION: External Email] > > On Wed, 03 Aug 2022 13:26:54 +0100, > Nipun Gupta <mailto:nipun.gupta@amd.com> wrote: > > > > Devices on cdx bus are dynamically detected and registered using > > platform_device_register API. As these devices are not linked to > > of node they need a separate MSI domain for handling device ID > > to be provided to the GIC ITS domain. > > > > Signed-off-by: Nipun Gupta <mailto:nipun.gupta@amd.com> > > Signed-off-by: Nikhil Agarwal <mailto:nikhil.agarwal@amd.com> > > --- > > CONFIG_CDX_BUS and device tree bindings for xlnx,cdx-controller-1.0 > > would be added as part of CDX bus patches > > > > drivers/irqchip/Makefile | 1 + > > drivers/irqchip/irq-gic-v3-its-cdx-msi.c | 113 +++++++++++++++++++++++ > > include/linux/cdx/cdx.h | 15 +++ > > 3 files changed, 129 insertions(+) > > create mode 100644 drivers/irqchip/irq-gic-v3-its-cdx-msi.c > > create mode 100644 include/linux/cdx/cdx.h > > > > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile > > index 5b67450a9538..623adb8a1f20 100644 > > --- a/drivers/irqchip/Makefile > > +++ b/drivers/irqchip/Makefile > > @@ -115,3 +115,4 @@ obj-$(CONFIG_WPCM450_AIC) += irq- > wpcm450-aic.o > > obj-$(CONFIG_IRQ_IDT3243X) += irq-idt3243x.o > > obj-$(CONFIG_APPLE_AIC) += irq-apple-aic.o > > obj-$(CONFIG_MCHP_EIC) += irq-mchp-eic.o > > +obj-$(CONFIG_CDX_BUS) += irq-gic-v3-its-cdx-msi.o > > diff --git a/drivers/irqchip/irq-gic-v3-its-cdx-msi.c b/drivers/irqchip/irq-gic- > v3-its-cdx-msi.c > > new file mode 100644 > > index 000000000000..eb17b74efdc5 > > --- /dev/null > > +++ b/drivers/irqchip/irq-gic-v3-its-cdx-msi.c > > @@ -0,0 +1,113 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * AMD CDX bus driver MSI support > > + * > > + * Copyright(C) 2022 Xilinx Inc. > > + */ > > + > > +#include <linux/irq.h> > > +#include <linux/msi.h> > > +#include <linux/of.h> > > +#include <linux/of_address.h> > > +#include <linux/of_device.h> > > +#include <linux/of_irq.h> > > +#include <linux/cdx/cdx.h> > > + > > +static struct irq_chip its_msi_irq_chip = { > > + .name = "ITS-fMSI", > > + .irq_mask = irq_chip_mask_parent, > > + .irq_unmask = irq_chip_unmask_parent, > > + .irq_eoi = irq_chip_eoi_parent, > > + .irq_set_affinity = msi_domain_set_affinity > > +}; > > + > > +static int its_cdx_msi_prepare(struct irq_domain *msi_domain, > > + struct device *dev, > > + int nvec, msi_alloc_info_t *info) > > +{ > > + struct msi_domain_info *msi_info; > > + struct cdx_device_data *dev_data; > > + u32 dev_id; > > + > > + dev_data = dev->platform_data; > > + dev_id = dev_data->dev_id; > > + > > + /* Set the device Id to be passed to the GIC-ITS */ > > + info->scratchpad[0].ul = dev_id; > > + > > + msi_info = msi_get_domain_info(msi_domain->parent); > > + > > + /* Allocate at least 32 MSIs, and always as a power of 2 */ > > + nvec = max_t(int, 32, roundup_pow_of_two(nvec)); > > + return msi_info->ops->msi_prepare(msi_domain->parent, dev, nvec, > info); > > +} > > + > > +static struct msi_domain_ops its_cdx_msi_ops __ro_after_init = { > > + .msi_prepare = its_cdx_msi_prepare, > > +}; > > + > > +static struct msi_domain_info its_cdx_msi_domain_info = { > > + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | > MSI_FLAG_USE_DEF_CHIP_OPS), > > + .ops = &its_cdx_msi_ops, > > + .chip = &its_msi_irq_chip, > > +}; > > + > > +static const struct of_device_id cdx_device_id[] = { > > + {.compatible = "xlnx,cdx-controller-1.0", }, > > What is this? If this is supposed to represent am ITS, it really > should say so.
This is a CDX bus controller, not an ITS. This will be added as a part of device-tree documentation when we add formal CDX bus patches. CDX is an upcoming AMD bus, supporting dynamically discovered FPGA devices.
> > > + {}, > > +}; > > + > > +struct irq_domain *get_parent(struct fwnode_handle *handle) > > +{ > > + return irq_find_matching_fwnode(handle, DOMAIN_BUS_NEXUS); > > +} > > + > > +static void __init its_cdx_msi_init_one(struct device_node *np, > > + const char *name) > > +{ > > + struct irq_domain *parent; > > + struct irq_domain *cdx_msi_domain; > > + struct fwnode_handle *fwnode_handle; > > + struct device_node *parent_node; > > + > > + parent_node = of_parse_phandle(np, "msi-parent", 0); > > + > > + parent = get_parent(of_node_to_fwnode(parent_node)); > > + if (!parent || !msi_get_domain_info(parent)) { > > + pr_err("%s: unable to locate ITS domain\n", name); > > + return; > > + } > > + > > + fwnode_handle = of_node_to_fwnode(np); > > + cdx_msi_domain = platform_msi_create_irq_domain(fwnode_handle, > > + &its_cdx_msi_domain_info, > > + parent); > > + if (!cdx_msi_domain) { > > + pr_err("%s: unable to create cdx bus domain\n", name); > > + return; > > + } > > + > > + pr_info("cdx bus MSI: %s domain created\n", name); > > +} > > + > > +static void __init its_cdx_of_msi_init(void) > > +{ > > + struct device_node *np; > > + > > + for (np = of_find_matching_node(NULL, cdx_device_id); np; > > + np = of_find_matching_node(np, cdx_device_id)) { > > + if (!of_device_is_available(np)) > > + continue; > > + > > + its_cdx_msi_init_one(np, np->full_name); > > + } > > +} > > + > > +static int __init its_cdx_msi_init(void) > > +{ > > + its_cdx_of_msi_init(); > > + > > + return 0; > > +} > > + > > +early_initcall(its_cdx_msi_init); > > I really don't think we should have any more of this muck. Yes, the > other busses are also doing that, but here's our chance to do > something better. > > Why can't the *bus* driver (I assume there is one) perform these > tasks? It would really help if this patch was shown in context, > because I have no idea how this fits in the grand scheme of things.
Agree, bus driver could do this stuff, and I was considering it too, but as this was the norm so added these changes in this IRQ chip :).
Bus driver is not out yet, and we have pushed these as RFC changes for early feedback (mentioned in the cover letter), but yes, these patches would be clubbed as a part of overall changes.
And we can move it as a part of bus driver itself. I hope that suits?
Thanks, Nipun
> > Thanks, > > M. > > -- > Without deviation from the norm, progress is not possible.
| |