[PATCH 3/3] perf/arm-ni: Support sharing IRQs within an NI instance

[Will Deacon]

On Mon, May 19, 2025 at 03:57:31PM +0100, Robin Murphy wrote:
> On 19/05/2025 1:29 pm, Will Deacon wrote:
> > On Tue, May 13, 2025 at 04:39:00PM +0100, Robin Murphy wrote:
> > > From: Shouping Wang <allen.wang at hj-micro.com>
> > > 
> > > NI-700 has a distinct PMU interrupt output for each Clock Domain,
> > > however some integrations may still combine these together externally.
> > > The initial driver didn't attempt to support this, in anticipation of a
> > > more general solution for IRQ sharing between system PMU instances, but
> > > that's still a way off, so let's make this intermediate step for now to
> > > at least allow sharing IRQs within an individual NI instance.
> > > 
> > > Now that CPU affinity and migration are cleaned up, it's fairly
> > > straightforward to adopt similar logic to arm-cmn, to identify CDs with
> > > a common interrupt and loop over them directly in the handler.
> > > 
> > > Signed-off-by: Shouping Wang <allen.wang at hj-micro.com>
> > > [ rm: Rework for affinity handling, cosmetics, new commit message ]
> > > Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> > > ---
> > >   drivers/perf/arm-ni.c | 78 ++++++++++++++++++++++++++++---------------
> > >   1 file changed, 51 insertions(+), 27 deletions(-)

[...]

> > > @@ -593,6 +589,30 @@ static void arm_ni_probe_domain(void __iomem *base, struct arm_ni_node *node)
> > >   	node->num_components = readl_relaxed(base + NI_CHILD_NODE_INFO);
> > >   }
> > > +static int arm_ni_init_irqs(struct arm_ni *ni)
> > > +{
> > > +	int err;
> > > +
> > > +	ni_for_each_cd(ni, cd) {
> > > +		for (struct arm_ni_cd *prev = cd; prev-- > ni->cds; ) {
> > > +			if (prev->irq == cd->irq) {
> > > +				prev->irq_friend = cd - prev;
> > 
> > Can't this race with the read of `irq_friend` in the interrupt handler?
> 
> Not in any way that matters. Any IRQ at this point would be a spurious one
> left latched at the interrupt controller after we've already reset all the
> PMUs. The handler can hardly observe a torn partial store of 1 byte, so
> either it'll see a valid irq_friend or none. Either way we'll eventually
> return IRQ_NONE, EOI the phantom IRQ and be done.
> 
> I'm not entertaining the idea of somehow being preempted here for long
> enough for userspace to notice the already-registered PMUs (even though the
> module load hasn't yet finished...), open an event and have it count enough
> to genuinely overflow, because that would be in the order of at least tens
> of seconds if not minutes.

Can't we save ourselves from having to think about that by just having
two loops? That is, set up the friend relationships and enable IRQ
generation in the first pass, then go through and actually request the
interrupts in the second one?

Will