On 22/05/17 20:37, Thomas Petazzoni wrote: > Hello, > > On Mon, 22 May 2017 16:02:33 +0100, Marc Zyngier wrote: > >>> It also says: 87 => 34 En Lv 5, which is the IRQ I'm looking for. >> >> Ah, that one as well. So how is the interrupt routed? Via the ICU, and >> then to the GIC (with several ICU sources mapped on a single SPI)? > > The crypto block being in the CP part, it has a wired interrupt to the > ICU (also in the CP). The ICU then turns this wired interrupt into a > memory write transaction to a register called GICP SPI in the AP, which > triggers a SPI interrupt in the GIC. Is that some kind of Level-triggered MSI, à la GICv3 GICD_SETSPI_NSR? > In the current mainline kernel, the ICU is configured by the firmware > and creates static associations between wired interrupts in the CP and > corresponding SPI interrupts. Therefore the Device Tree currently > reference such SPI interrupts directly. > > However, I have a patch series that I plan to submit hopefully in the > next days that adds an ICU driver, and changes the Device Tree to refer > to the ICU interrupt instead. OK, I'm quite interested to see that, specially if my above hunch is right... > Therefore, I don't think the binding should reference anything else > than the usual info about the interrupts property. That I completely agree with, as long as it doesn't describe anything that is semantically incorrect. Thanks, M. -- Jazz is not dead. It just smells funny...
