* Lokesh Vutla [off-list ref] [190213 04:23]:

Hi Tony,

On 12/02/19 10:00 PM, Tony Lindgren wrote:

quoted

Hi,

* Lokesh Vutla [off-list ref] [190212 07:43]:

quoted

+The Interrupt Router (INTR) module provides a mechanism to route M
+interrupt inputs to N interrupt outputs, where all M inputs are selectable
+to be driven per N output. There is one register per output (MUXCNTL_N) that
+controls the selection.
+
+
+                                 Interrupt Router
+                             +----------------------+
+                             |  Inputs     Outputs  |
+        +-------+            | +------+             |
+        | GPIO  |----------->| | irq0 |             |       Host IRQ
+        +-------+            | +------+             |      controller
+                             |    .        +-----+  |      +-------+
+        +-------+            |    .        |  0  |  |----->|  IRQ  |
+        | INTA  |----------->|    .        +-----+  |      +-------+
+        +-------+            |    .          .      |
+                             | +------+      .      |
+                             | | irqM |    +-----+  |
+                             | +------+    |  N  |  |
+                             |             +-----+  |
+                             +----------------------+

Is this always one-to-one mapping or can the same interrupt be routed to
multiple targets like to the SoC and some coprocessor?

Yes, it is always one-to-one. Output of INTR can only be attached to one of the
processor.

OK

quoted

quoted

+Configuration of these MUXCNTL_N registers is done by a system controller
+(like the Device Memory and Security Controller on K3 AM654 SoC). System
+controller will keep track of the used and unused registers within the Router.
+Driver should request the system controller to get the range of GIC IRQs
+assigned to the requesting hosts. It is the drivers responsibility to keep
+track of Host IRQs.
+
+Communication between the host processor running an OS and the system
+controller happens through a protocol called TI System Control Interface
+(TISCI protocol). For more details refer:
+Documentation/devicetree/bindings/arm/keystone/ti,sci.txt

Care to describe a bit why the interrupts need to be routed by a system
controller?

K3 architecture defines a heterogeneous system where multiple heterogeneous
cores are serving its own usecases. Given that there are multiple ways in which
a device IRQ can be routed using INTR, like either it can be routed to HLOS
core(A53 int this case) or it can be routed to any other coprocessor available
in the system(like R5). If every sw running in each co-processor is allowed to
program this INTR then there is a high probability that one sw executing on one
core can damage other heterogeneous core.  Mainly to avoid this damage the
configuration of all the INTRs and INTAs are done in a centralized place(sysfw).
Any user for programming its IRQ route should send a message to sysfw with the
parameters. These parameters are policed by sysfw and does the configuration.

OK so maybe update the description along those lines saying it's
a shared piece of hardware between various independent SoC
clusters which may or may not be running Linux.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel