[PATCH 04/23] irqchip/rvid: Add PCI MSI support

[Marc Zyngier]

Hi Jonathan,

On Fri, 04 Sep 2020 15:15:38 +0100,
Jonathan Cameron <Jonathan.Cameron at Huawei.com> wrote:
> 
> On Thu,  3 Sep 2020 16:25:51 +0100
> Marc Zyngier <maz at kernel.org> wrote:
> 
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> Few minor comments inline.
> 
> Thanks,
> 
> Jonathan
> 
> > ---
> >  drivers/irqchip/irq-rvid.c | 182 +++++++++++++++++++++++++++++++++++++
> >  1 file changed, 182 insertions(+)
> > 
> > diff --git a/drivers/irqchip/irq-rvid.c b/drivers/irqchip/irq-rvid.c
> > index 953f654e58d4..250f95ad1a09 100644
> > --- a/drivers/irqchip/irq-rvid.c
> > +++ b/drivers/irqchip/irq-rvid.c
> > @@ -12,12 +12,19 @@
> >  #include <linux/irq.h>
> >  #include <linux/irqchip.h>
> >  #include <linux/irqdomain.h>
> > +#include <linux/msi.h>
> >  
> >  #include <linux/irqchip/irq-rvic.h>
> >  
> >  struct rvid_data {
> >  	struct fwnode_handle	*fwnode;
> >  	struct irq_domain	*domain;
> > +	struct irq_domain	*msi_domain;
> > +	struct irq_domain	*pci_domain;
> > +	unsigned long		*msi_map;
> > +	struct mutex		msi_lock;
> > +	u32			msi_base;
> > +	u32			msi_nr;
> >  };
> >  
> >  static struct rvid_data rvid;
> > @@ -209,6 +216,177 @@ static const struct irq_domain_ops rvid_irq_domain_ops = {
> >  	.deactivate	= rvid_irq_domain_deactivate,
> >  };
> >  
> > +#ifdef CONFIG_PCI_MSI
> > +/*
> > + * The MSI irqchip is completely transparent. The only purpose of the
> > + * corresponding irq domain is to provide the MSI allocator, and feed
> > + * the allocated inputs to the main rVID irq domain for mapping at the
> > + * rVIC level.
> > + */
> > +static struct irq_chip rvid_msi_chip = {
> > +	.name			= "rvid-MSI",
> > +	.irq_mask		= irq_chip_mask_parent,
> > +	.irq_unmask		= irq_chip_unmask_parent,
> > +	.irq_eoi		= irq_chip_eoi_parent,
> > +	.irq_get_irqchip_state	= irq_chip_get_parent_state,
> > +	.irq_set_irqchip_state	= irq_chip_set_parent_state,
> > +	.irq_retrigger		= irq_chip_retrigger_hierarchy,
> > +	.irq_set_type		= irq_chip_set_type_parent,
> > +	.irq_set_affinity	= irq_chip_set_affinity_parent,
> > +};
> > +
> > +static int rvid_msi_domain_alloc(struct irq_domain *domain, unsigned int virq,
> > +				 unsigned int nr_irqs, void *arg)
> > +{
> > +	int ret, hwirq, i;
> > +
> > +	mutex_lock(&rvid.msi_lock);
> > +	hwirq = bitmap_find_free_region(rvid.msi_map, rvid.msi_nr,
> > +					get_count_order(nr_irqs));
> > +	mutex_unlock(&rvid.msi_lock);
> > +
> > +	if (hwirq < 0)
> > +		return -ENOSPC;
> > +
> > +	for (i = 0; i < nr_irqs; i++) {
> > +		/* Use the rVID domain to map the input to something */
> > +		struct irq_fwspec fwspec = (struct irq_fwspec) {
> > +			.fwnode		= domain->parent->fwnode,
> > +			.param_count	= 1,
> > +			.param[0]	= rvid.msi_base + hwirq + i,
> > +		};
> > +
> > +		ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, &fwspec);
> > +		if (WARN_ON(ret))
> > +			goto out;
> > +
> > +		irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
> > +					      &rvid_msi_chip, &rvid);
> > +	}
> > +
> > +	return 0;
> > +
> > +out:
> 
> I missed this on previous patch, but doesn't the error path need to undo the
> irq_domain_alloc_irqs_parent part? irq_domain_free_irqs_parent()

Yes, this indeed needs some rework.

[...]

> > +static void __init rvid_msi_setup(struct device_node *np)
> > +{
> > +	if (!of_property_read_bool(np, "msi-controller"))
> > +		return;
> > +
> > +	if (of_property_read_u32_index(np, "msi-range", 0, &rvid.msi_base) ||
> > +	    of_property_read_u32_index(np, "msi-range", 1, &rvid.msi_nr)) {
> 
> Looks like msi-range isn't defined in any existing bindings, or my grep
> fu is broken today.

As hinted at in the cover letter, there is no binding whatsoever for
now, and all the properties are totally made up.

As for the use of "msi-range", most bindings are using some ad-hoc
descriptions of their *outputs* to the downstream irqchip. What I am
describing here is the range of *inputs* into the rVID that can be
used for MSIs.

It we wanted to use an abstraction similar to what exists in the
physical world, then the MSI widget would be a separate component
upstream of the rVID itself. In a way the driver works like that
already (there is a separate MSI domain sitting atop the rVID domain),
and it wouldn't be a big deal to switch to that. We'd need a property
describing the output range of the widget, similar in essence to what
is required for the GICv3 MBI ranges.

Thanks,

	M.

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