On Sun, 03 Jul 2022 19:15:11 +0100, Sander Vanheule <sander@xxxxxxxxxxxxx> wrote: > > Hi Aleksander, > > Since this is IRQ related: +CC Marc Zyngier > > On Sat, 2022-07-02 at 21:07 +0200, Aleksander Jan Bajkowski wrote: > > This patch is needed to handle interrupts by the second VPE on > > the Lantiq xRX200, xRX300 and xRX330 SoCs. In these chips, 32 ICU > > interrupts are connected to each hardware line. The SoC supports > > a total of 160 interrupts. Currently changing smp_affinity to the > > second VPE hangs interrupts. > > > > This problem affects multithreaded SoCs with a custom interrupt > > controller. Chips with 1004Kc core and newer use the MIPS GIC. > > > > Also CC'ed Birger Koblitz and Sander Vanheule. Both are working > > on support for Realtek RTL930x chips with 34Kc core and Birger > > has added a patch in OpenWRT that also enables all interrupt > > lines. So it looks like this patch is useful for more SoCs. > > > > Tested on lantiq xRX200 and xRX330. > > > > Signed-off-by: Aleksander Jan Bajkowski <olek2@xxxxx> > > Thanks for bringing up this issue. Like you say OpenWrt carries a > similar patch, and I also carry a patch on my tree to enable all CPU > IRQ lines. > > Indiscriminately enabling all IRQ lines doesn't sit quite right with > me though, since I would expect these to be enabled > on-demand. I.e. when a peripheral requests an IRQ, or when an IRQ > controller is cascaded into one of the CPU's interrupt lines. If I > understand correctly, the IRQ mask/unmask functions in > drivers/irqchip/irq-mips-cpu.c should do this. But this is only enabling interrupts at the CPU level, right? And the irqchip is still in control of the masking of the individual interrupts? If both assertions are true, then this patch seems OK. If it just let any interrupt through without any control, then this is wrong. So which one is it? M. -- Without deviation from the norm, progress is not possible.
