On Thu, 2022-07-07 at 16:39 +0200, Thomas Bogendoerfer wrote: > On Thu, Jul 07, 2022 at 02:57:15PM +0200, Martin Blumenstingl wrote: > > On Thu, Jul 7, 2022 at 12:11 PM Thomas Bogendoerfer > > <tsbogend@xxxxxxxxxxxxxxxx> wrote: > > [...] > > > > - why can MIPS CPU interrupt 6 and 7 be enabled unconditionally while > > > > 2-5 cannot be enabled unconditionally? > > > > > > 7 is timer interrupt and is usually wired for 34K cpus and 6 is > > > performance counter hopefully handled as well. And I agree that > > > this still isn't the best approach here > > Thanks for this explanation! > > > > > > - seeing that there's also a mips_gic_present() check in the opposite > > > > case of what Aleksander's patch modifies: does this indicate that > > > > unmasking CPU interrupt lines for VPE 1 is not handled by the MIPS CPU > > > > interrupt controller driver at all at this point (and if so: do you > > > > have any suggestions how to properly fix this)? > > > > > > I haven't checked how GIC is integrated. Iirc it does something similair > > > to Lantiq's irq controller and hides all CPU internal interrupts behind > > > it. > > > > > > So I see two solutions for your problem. > > > > > > 1. Add "mti,cpu-interrupt-controller" to the DT and wire it up > > I think this is the preferred way. I tried this before (if you are > > curious, see [0] and [1]) and it didn't work. > > Are you aware of any MIPS SoC with upstream drivers which do have > > working IRQs on VPE 1? > > I don't know of such SoC. Looking at the comment in vsmp_init_secondary() > > /* This is Malta specific: IPI,performance and timer interrupts */ > > there is probably some Malta board using it. > > > Or can you point me to the code in > > drivers/irqchip/irq-mips-cpu.c that's responsible for enabling the > > interrupts on VPE 1 (is it simply unmask_mips_irq)? > > IMHO there is the problem, irq-mips-cpu.c can only do CPU irq operations > on the same CPU. I've checked MIPS MT specs and it's possible do > modify CP0 registers between VPEs. Using that needs changes in > irq-mips-cpu.c. But mabye that's not woth the effort as probably > all SMP cabable platforms have some multi processort capable > interrupt controller implemented. Maybe I'm not getting this right, but as I understand vsmp_init_secondary() is run on VPE1, changing the local c0_status on that VPE. When unmask_mips_irq() is called from code running on VPE1, I would expect it does the same thing: enable the requested irq on VPE1 by modifying the local c0_status register. Since these IRQs can be configured VPE, aren't these then also per-cpu interrupts? I have been wondering if a cascaded IRQ controller needs to take special care with such per-cpu interrupts, but haven't been able to figure that out until now. Sorry if the above doesn't make much sense, but like Aleksander I've been struggling with this and would like to understand what the proper solution is. Best, Sander > I thought about another way solve the issue. By introducing a > new function in smp-mt.c which sets the value of the interrupt > mask for the secondary CPU, which is then used in vsmp_init_secondary(). > Not sure if this is worth the effort compared to a .boot_secondary > override. > > Thomas. >
