AM5K2E: Balancing of IRQs across several A15 cores

Hello Gunter,

There is an IRQ_CROSSBAR module in the device, which is controlled by registers in the CTRL_MODULE_CORE. The IRQ_CROSSBAR is able to map any of its input signals to any of its outputs. This module is associated with the device interrupt sources. The IRQs from all the device modules are connected to the IRQ_CROSSBAR inputs. Each module IRQ is connected only to one cross-bar input. Each output of the IRQ_CROSSBAR module is connected only to one interrupt line of certain interrupt controller (INTC). Thus, the device IRQs are mapped to the device INTCs through the IRQ_CROSSBAR. Some of these IRQs are mapped by default to certain interrupt lines of one of the device INTCs, but there are IRQs which are not mapped by default to any interrupt line of any device
INTC. All IRQs, connected to the IRQ_CROSSBAR inputs, can be remapped to other interrupt lines of the different device INTCs through the CTRL_CORE_X_IRQ_B_A registers.

See the picture:

FYI: - take a detail look in ti-glsdk_dra7xx-evm_7_00_00_04/board-support/linux/Documentation/devicetree/bindings/arm/omap/crossbar.txt:

IRQ_CROSSBAR definitions are available in following files:

/board-support/linux/drivers/irqchip/irq-crossbar.c:

See the example:

ti,irqs-skip: This is similar to "ti,irqs-reserved", but these are for SOC-specific hard-wiring of those irqs which unexpectedly bypasses the crossbar. These irqs have a crossbar register, but still cannot be used.

 - ti,irqs-safe-map: integer which maps to a safe configuration to use


 crossbar_mpu: @4a020000 {
 compatible = "ti,irq-crossbar";
 reg = <0x4a002a48 0x130>;
 ti,max-irqs = <160>;
 ti,max-crossbar-sources = <MAX_SOURCES>;
 ti,reg-size = <2>;
 ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;

/home/x0170812/ti-glsdk_dra7xx-evm_7_00_00_04/board-support/linux/arch/arm/boot/dts/dra7.dtsi:
 };

 dmacb: dma-crossbar@4a020000 {
 compatible = "ti,dma-crossbar";
 reg = <0x4a002b78 0x100>;
ti,dma-reqs = <160>;
...
 };
 
 /* IRQ for DWC3_3 and DWC3_4 need IRQ crossbar */

omap_dwc3_3: omap_dwc3_3@48900000 {

compatible = "ti,dwc3";

....
 };

 crossbar_mpu: crossbar@4a020000 {
 compatible = "ti,irq-crossbar";
 reg = <0x4a002a48 0x130>;
 ti,max-irqs = <160>;
 ti,max-crossbar-sources = <MAX_SOURCES>;
 ti,reg-size = <2>;
 ti,irqs-reserved = <0 1 2 3 5 6 131 132>;

Best regards,

Yanko

Hi,

thanks for the feedback. I would need to followup again on this subject. Looking at the crossbar described above it sounds to me that this would for example allow the eth0 interrupt to get routed to ALL A15 cores. Then it would be up to the SW to arbitrate and allow a given CORE to run the interrupt handler. Is this the right approach?

The crossbar sounds like the same functionality as what you could get with smp_affinity in the Linux kernel, e.g. if one sets the smp_affinity of the eth0 IRQ to 0x0000000F, then the IRQ should be routed to all 4 cores. Is there a relationship between the crossbar and smp_affinity?

Has someone tested load-balancing of a single interrupt and the handling across 4 cores?

Thanks,
--Gunter

Hello Gunter,

Let's refer to IRQ_CROSSBAR functional description:

There is an IRQ_CROSSBAR module in the device, which is controlled by registers in the CTRL_MODULE_CORE submodule. The IRQ_CROSSBAR is able to map any of its input signals to any of its outputs. This module is associated with the device interrupt sources. The IRQs from all the device modules are connected to the IRQ_CROSSBAR inputs. Each module IRQ is connected only to one cross-bar input. Each output of the IRQ_CROSSBAR module is connected only to one interrupt line of certain interrupt controller (INTC). Thus, the device IRQs are mapped to the device INTCs through the IRQ_CROSSBAR. Some of these IRQs are mapped by default to certain interrupt lines of one of the device INTCs, but there are IRQs which are not mapped by default to any interrupt line of any device INTC. All IRQs, connected to the IRQ_CROSSBAR inputs, can be remapped to other interrupt lines of the different device INTCs through the CTRL_CORE_X_IRQ_B_A registers.

http://www.thegeekstuff.com/2014/01/linux-interrupts/

Yes, I confirm that the definition of smp_affinity sounds like CROSSBAR's one. However CROSSBAR enables the hardware routing of different IRQ signal in SoC.

See the Functional diagram:

Best regards,

Yanko