01-02-2019 09:21 AM - edited 01-02-2019 09:32 AM
I have a piece of code that works, however I do not understand something about the interrupt number.
The code goes something like this...
#define BUS_NAME "platform"
#define IPI_DEV_NAME "ff340000.ipi"
struct metal_device *ipiDevice;
metal_device_open(BUS_NAME, IPI_DEV_NAME, &ipiDevice);
printf("IRQ = 0x%08X\n", ipiDevice->irq_info);
Which prints this on the console...
IRQ = 0x00000005
Question. Where does the value 5 come from please?
The dtsi for the ipi looks like this...
compatible = "ipi_uio";
reg = <0x0 0xff340000 0x0 0x1000>;
interrupts = <0 29 4>;
01-02-2019 09:34 AM
This shows an example that you can see the 'ID' being set. (e.g. the value that gets returned in irq_info)
Hope that helps
If so, please mark as Solution Accepted (Kudos are also nice :-)
01-02-2019 09:58 AM - edited 01-02-2019 09:58 AM
Thanks a bunch for your response, but no that does not help.
In that document the setting is in a libmetal static definition.
I am using this code in Linux so it is just...
init lib metal
open the device
print the irq_info
So the question still is... where does it get the value 5 from?
01-03-2019 02:14 AM
IPI -> Inter Processor Interrupts
These IPIs are based on work load from once core to other core.
Basically these are defined in arch/arm/kernel/irq.c
In fact, IRQ number got in linux with request_irq() is different
from IRQ generated from Hardware.
It needs bit of IRQ Sub system knowledge,
1st step: request_irq() in Linux
2nd stsp: struct irq , do_irq() etc..
3rd step: Linux IRQ Domain Mapping: Hirechary mapping,Linear mapping, Tree mapping
This IRQ domain mapping change the Linux Irq no. to different IRQ no.
Linux irq no. passed to IRQ controller or Mux IRQ controller, then it will pass to SoC ,
4th Step: SoC will take signal from Mux IRQ controller and identifes this signal is from which Device (I/O)
and sent to GIC (Generic Interrupt Controller)
5th Step: GIC maintains Vector Table, Vector table maintains collection of addresses, proper address will be identified by Vectro table and so address calls the corrspending IRQ function and sent it to
CPU Providing LR address as return address for IRQ Function.
6th Step: There are two types of Interrupts, Shared peripheral Interrupts, Private Peripheral Interrupts
Shared Interrupts are shared by all Cores & Private Peripheral Interrupts are local to each core.
7th Step: In your case, metal_****() function will be handled by either Shared or Private interrupts based on work load , & it is decided by scheduler.
8th Step: The IRQ no. you have seen is same as .dtsi file if it is handled by private peripheral interrupt
or it will (irq no+32 ), if it handled by Shared peripheral interrupts.
So it is completely different that what Linux request_irq() is showing , what actually it is printing through
pr_info or printk.
I hope the concept is clear for you,
Please provide Kudos if you are ok with the reply.
Thanks & Regards