On Mon, 16 Oct 2023 at 13:26, Binbin Zhou <zhoubb.aaron@xxxxxxxxx> wrote:
>
> Hi all:
>
> Sorry, it's been a while since the last discussion.
>
> Previously, Krzysztof suggested using the standard "interrupt-map"
> attribute instead of the "loongson,parent_int_map" attribute, which I
> tried to implement, but the downside of this approach seems to be
> obvious.
>
> First of all, let me explain again the interrupt routing of the
> loongson liointc.
> For example, the Loongson-2K1000 has 64 interrupt sources, each with
> the following 8-bit interrupt routing registers (main regs attribute
> in dts):
>
> +----+-------------------------------------------------------------------+
> | bit | description
> |
> +----+-------------------------------------------------------------------+
> | 3:0 | Processor core to route |
> | 7:4 | Routed processor core interrupt pins (INT0--INT3) |
> +-----+------------------------------------------------------------------+
>
> The "loongson,parent_int_map" attribute is to describe the routed
> interrupt pins to cpuintc.
>
> However, the "interrupt-map" attribute is not supposed to be used for
> interrupt controller in the normal case. Though since commit
> 041284181226 ("of/irq: Allow matching of an interrupt-map local to an
> interrupt controller"), the "interrupt-map" attribute can be used in
> interrupt controller nodes. Some interrupt controllers were found not
> to work properly later, so in commit de4adddcbcc2 ("of/irq: Add a
> quirk for controllers with their own definition of interrupt-map"), a
> quirk was added for these interrupt controllers. As we can see from
> the commit message, this is a bad solution in itself.
>
> Similarly, if we choose to use the "interrupt-map" attribute in the
> interrupt controller, we have to use this unfriendly solution (quirk).
> Because we hope of_irq_parse_raw() stops at the liointc level rather
> than goto its parent level.
>
> So, I don't think it's a good choice to use a bad solution as a replacement.
>
> Do you have any other ideas?
Assuming this is changeable at runtime, this sounds to me like this
mapping/routing could easily be exposed as irqchip cpu affinity. Then
userspace can apply all the performance optimizations it wants (and
can easily update them without fiddling with the kernel/dts).
And then there would be no need to hardcode/describe it in the dts(i) at all.
Best Regards,
Jonas
