[OpenWrt-Devel] [PATCH v5] kernel: lantiq: add support for SMP IRQ routing

[Petr Cvek]

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(&ltq_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 at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel