chaining of interrupt handlers with RISC-V cores

[Mikko Saari]

Hi! I would like to ask if there is more information about the current state of the chaining the interrupt handlers in the RISC-V architecture. If one uses interrupt controller like Xilinx AXI Logicore (open source implementation by Ultra-Embedded), how it should be defined in the device tree and should some modifications to be done in the Linux driver codes themselves. I am a bit confused by the terms like "CLIC, PLIC, APLIC, IMSIC etc..., how should one use them for example in the dual-core RISC-V system that is capable enough to execute the Linux kernels 5.0-6.4. Hopefully this is not a stupid question, there exist much documentation about interrupt controllers but maybe I was not able to read them carefully enough and I am still a bit beginner in the driver development...

Best Regards, Mikko Saari

[Tommy Murphy]

> Hi! I would like to ask if there is more information about the current state of the chaining the interrupt handlers in the RISC-V architecture. 

Is this perhaps part of the remit of the RISC-V Fast Interrupts Technical Group?

https://wiki.riscv.org/plugins/servlet/mobile?contentId=327814#content/view/327814

[Mikko Saari]

Yes, thanks,  I think it should be, I check that. The external Xilinx interrupt controller is succesfully working with RISC-V now for the unicore system but I am searching more information for the multicore system and the peripheral devices  like ethernet.

[Robert Lipe]

Actually, is this an architectural question for this group at all, or is this a plain ole Linux device driver writer question, addressed in several books and such, as the details will be up to the OS in question. (Hint, not everything is Linux...)

On most OSes, it's up to the platform to handle claiming and clearing at the CLIC/PLIC/alphabet soup level, not the individual drivers. I can't imagine a (sensible) world where that would be handled by the individual drivers. If you and I are sharing an interrrupt and you mark it claimed at the platform level, I may never get called or, at the very best, would only be called after the interrupt service train has unloaded and made another pass around the loop of everyone that may be using that interrupt. Also, since your driver should be portable between MIPS, Sparc, Alpha, and Pentium (it's running in a time machine set for 1992, you see...) you wouldn't want' the portable device driver code to know about the details of this level about the platform it's running on at all.

A search of [shared linux interrupts] turns up what looks like several believable answers to what I think is your question.

Good luck

[Mikko Saari]

Thanks for advices! I agree in the driver level the solutions should be generic enough and portable, to as many platforms as possible. However, in my case there is a combination of specific interrupt controllers, and RISC-V processor, even in a bit "hackish" manner, so it might not be necessary or possible to get portable solution for x86, ARM or other architectures.

For example there was a case when Xilinx SPI-controller was defined as a source of interrupts for the Xilinx interrupt controller and that was chained to PLIC of RISC-V core.

Then the problem was everytime SPI was tested in loopback mode, if MOSI sent more than 8 bytes data, the PLIC got stuck. This could be only solved by using direct system calls to modify CSRs of RISCV-core inside the Xilinx interrupt handler. And I guess this is not portable solution at all, not even accepted to the kernel upstream.

But maybe this issue would belong more to Linux driver development than to RISC-V SW.

BR. Mikko