Where are Sysevents for interrupt controllers defined?

General Discussion
1

I’ve been working with RPMsg for some time now and wanted to get a better understanding regarding the PRU interrupt controller (PINTC) and the ARM interrupt controller (AINTC).

PINTC has 64 system events. Events 16 to 25 appear to be general purpose and are used for RPMsg. On the other side there is the AINTC with 128 sysevents. 20 to 27 are connected directly to 2 to 8 of the PINTC host. Looking at official examples I know that PINTC sysevent 16 is the “pru0_to_arm” event and 17 is the “arm_to_pru0”. Tracking the host connections to AINTC I can also say that sysevent 20 is responsible for the “pur0_to_arm” interrupt on the ARM side.

I was wondering where the definition of the functionality of these events takes place. The documentation (calling them “pr1_pru_mst_intr[0]_intr_req” for example) makes it clear to me that they’re not “hardwired”, so it must take place somewhere on the operating system. I tried looking at the sourcecode for the remoteproc and rpmsg drivers as well as some device tree overlays, however my search ended up emptyhanded.

It would be nice to have an authoritative document, that says why Sysevent 16 is pru0 to arm, instead of having to shrug and say “trust me bro, that’s how it is in the examples”

2

Hi,

Here are some bits of information I have found so far.

Per SPRUH73Q, section 4.4.2.1. “INTC Overview”, the mapping is configurable:

• Any of the 64 system events can be mapped to any of the 10 channels.
• Any of the 10 channels can be mapped to any of the 10 host interrupts. It is recommended to map
channel “x” to host interrupt “x”, where x is from 0 to 9

Typical RPMSG examples use two interrupts - one from ARM host, and one towards the ARM host:

#define TO_ARM_HOST			18
#define FROM_ARM_HOST			19

In latest remoteproc driver version, there is a special section .pru_irq_map where PRU firmware defines the mapping for one of the interrupts, to be used by the host remoteproc loader:

                {19, 1, 1},     /* {sysevt, channel, host interrupt} */

The other interrupt seems to be defined in DTS:

interrupts = <18 3 3>;

I think that those three values are parsed in pruss_intc_irq_domain_xlate function:

	sys_event = intspec[0];
	channel = intspec[1];
	host = intspec[2];

Regards,
Dimitar

2 Likes
3

Thank you for your reply!

The dts that you linked is exactly what I was looking for. The latest version defines event 16 and 18 as “vring” interrupts, but when I went back to the kernel version that I am currently using there was also a definition for 17 and 19 as “kick”. Do you happen to know where they were moved to?

I also had a look at the newer version of the pru software support package (didn’t use it cause incompatible kernel). It has a bit more documentation and links to an explanation how to add your own interrupts.

4

17 and 19 seem to have been moved into the PRU firmware. There is a special section .pru_irq_map where PRU firmware defines the mapping for one of the interrupts, to be used by the host remoteproc loader. For PRU1:

                {19, 1, 1},     /* {sysevt, channel, host interrupt} */
5

Sorry I probably worded the question poorly.

I understand that the interrupt settings for the pru side got transferred to their own file. I was wondering about the way that the ARM chip triggers the sysevent 19 for example. In the old version of the dts they had event 19 labeld as a kick, but in the newer version that you linked they removed it and I wanted to know where the new definition is.

6

See how kernel function pru_rproc_find_interrupt_map is used to obtain the IRQ map from the PRU firmware image.

Then function pru_handle_intrmap parses the mapping.

I believe that ARM triggers sysevent 19 in kernel function pru_rproc_kick.

Regards,
Dimitar