Re: [PATCH v2 2/2] irqchip/ti-sci-inta: Add support for unmapped event handling

From: Marc Zyngier
Date: Mon Oct 12 2020 - 03:31:49 EST


On 2020-10-09 09:58, Peter Ujfalusi wrote:
Marc,


[...]

The design of irqchip/irq-ti-sci-inta.c, soc/ti/ti_sci_inta_msi.c and
irqchip/irq-ti-sci-intr.c created to handle the interrupt needs present
in K3 devices with NAVSS.
DMSS of newer K3 devices extends and simplifies the NAVSS components and
a big part of that change was done with the INTA and DMAs.
System Firmware also changed to adopt to these changes.

As an example, let's assume that we want an interrupt from a ring.
The high level of the events in this case are:

NAVSS:
1.1 ring generates an internal signal (up or down)
1.2 the ringacc will send a (mapped) Global Event to INTA
1.3 When INTA receives the global event, it will signal it's outgoing
VINT to INTR
1.4 INTR will trigger a host interrupt.

DMSS
1.1 ring generates an internal signal (up or down)
1.2 the DMA (ring is now part of the DMA) will send an unmapped event to
INTA
1.3 When INTA receives the unmapped event, it will send a (mapped)
Global Event to itself
1.4 When INTA receives the global event, it will signal it's outgoing
VINT to INTR
1.5 INTR will trigger a host interrupt.

The API from sysfw is the same to configure the global events and VINT,
but we need to use the INTA's tisci device identification number to let
sysfw know that the Global event number can be programmed into INTA's
unmapped event steering register. The DMA no longer have this register,
it sends unmapped event to INTA.

The unmapped event number is fixed per sources, they will arrive at the
specific unmapped event configuration register of INTA.

INTA itself does not know which source are allocated to be used by
Linux, the allocation is for the DMA resources and only the DMA driver
knows which channels, rings, flows can be used and can ask the INTA MSI
domain to create interrupts for those.

By handling the ti,unmapped-event-sources the INTA driver can make
decision on the correct tisci dev_id to be used for the sysfw API to
where the global event must be configured and the client drivers does
not need to know how things are working under the hood.

There are components in DMSS which use is exactly how they worked within
NAVSS, they are not using unmapped events. Ringacc comes to mind first.

I can add a comment block to explain the nature of unmapped events and
the reason why we need to do what we do.

Would this be acceptable?

That'd be useful, as long as it is shorter than the above.

M.
--
Jazz is not dead. It just smells funny...