Dne 19. 05. 19 v 23:45 Hauke Mehrtens napsal(a): > > Have you seen such feature in any other upstream IRQ driver? > This automatic assignment of IRQs to VPEs looks a little bit strange to > me, but I am also not an expter on IRQs. >
Yes loongson64 has it in ht_irqdispatch(): https://elixir.bootlin.com/linux/v5.0-rc4/source/arch/mips/loongson64/loongson-3/irq.c#L65 MIPS GIC is using cpumask_first part in gic_unmask_irq(): https://elixir.bootlin.com/linux/v5.0-rc4/source/drivers/irqchip/irq-mips-gic.c#L184 General IRQ driver of powerpc has the similar code used further in mpic_set_affinity(), but that may be because of its architecture (there probably isn't IRQ HW balancer in lantiq). There will be probably other examples with slightly different code. >> ++ vpe = cpumask_next(smp_processor_id(), >> ++ irq_data_get_effective_affinity_mask(d)); >> ++ >> ++ /* >> ++ * There is a theoretical race condition if affinity gets changed >> ++ * meanwhile, but it would only caused a wrong VPE to be used until >> ++ * the next IRQ enable. Also the SoC has only 2 VPEs which fits >> ++ * the single u32. You can move spinlock before first mask readout >> ++ * and add it to ltq_icu_irq_set_affinity. >> ++ */ >> ++ >> ++ if (vpe >= nr_cpu_ids) >> ++ vpe = cpumask_first(irq_data_get_effective_affinity_mask(d)); >> ++#else >> ++ vpe = cpumask_first(irq_data_get_effective_affinity_mask(d)); >> ++#endif >> ++ >> ++ /* This shouldn't be even possible, maybe during CPU hotplug spam */ >> ++ if (unlikely(vpe >= nr_cpu_ids)) >> ++ vpe = smp_processor_id(); >> ++ >> ++ raw_spin_lock_irqsave(<q_icu_lock, flags); >> ++ >> ++ /* bugfix for fake interrupts? from UGW 3.x kernel */ >> ++ ltq_icu_w32(vpe, im, BIT(offset), LTQ_ICU_ISR); > > It could be that some (broken) bootloader does not deactivate all the > IRQs when the control is given to Linux. Do you need this change, > otherwise I would just deactivate all IRQs in the probe function. > I will run further tests, but I think when I've put an assert for an active status bit I've got few IRQs logged. I will repeat the tests. I have a slight suspicion the status bit doesn't work correctly when an interrupt arrives and line is disabled (it behaved weird when I was trying to identify the second ICU, but I may be wrong). >> ++++ b/arch/mips/boot/dts/ar9.dtsi 2019-05-17 04:58:17.080815930 +0200 >> ++ reg = <0x80200 0xc8>; /* ICU0 */ >> ++ /* TODO AR9 should have ICU1 (like VR9) too */ > > Yes this is similar to VR9. > >> ++++ b/arch/mips/boot/dts/falcon.dtsi 2019-05-17 05:00:42.536997478 >> +0200 >> ++ /* TODO I don't know if there is another ICU */ > > The 2. ICU is at 0x80300, size is 0xe0 for both ICUs. > Thanks, gonna put the addresses there. Petr _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
