Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
MIME-Version: 1.0
References: <20230821061315.3416836-1-zhoubinbin@loongson.cn>
 <e62185ca-cdf6-bde9-ad46-f4150db9ed6d@linaro.org> <CAMpQs4JhfuB4=s9VFc+xmw_+8h5u2EwPdM_0x2vO_=SYabAAxw@mail.gmail.com>
 <6ba31912-6738-6156-d5f4-3c8d3a3ca7bc@linaro.org> <CAMpQs4+GiExt9uMmV1pf8gg8rFwWxbLkx9mdW7hY9xxXDOza3Q@mail.gmail.com>
 <d11873a1-b552-71f5-1100-7464687f8bb4@linaro.org> <a084e6e9-46b0-42ef-b500-69c114ae11b2@flygoat.com>
 <86wmxcejav.wl-maz@kernel.org> <c7898abf-34ca-d0b4-fd0c-935100dcd3f2@flygoat.com>
 <86pm2ye2si.wl-maz@kernel.org> <CAMpQs4LjePLy5RFMz2S=1sa9Zme_UrJmKKRog0LAg_ZhA07TMA@mail.gmail.com>
In-Reply-To: <CAMpQs4LjePLy5RFMz2S=1sa9Zme_UrJmKKRog0LAg_ZhA07TMA@mail.gmail.com>
From:   Jonas Gorski <jonas.gorski@gmail.com>
Date:   Tue, 17 Oct 2023 17:05:33 +0200
Message-ID: <CAOiHx=mq3hw-LFerb9UzU7VSnLypnvPuo1GomCnN=p0u3xN1Ug@mail.gmail.com>
Subject: Re: [PATCH v2] dt-bindings: interrupt-controller: loongson,liointc:
 Fix warnings about liointc-2.0
To:     Binbin Zhou <zhoubb.aaron@gmail.com>
Cc:     Marc Zyngier <maz@kernel.org>,
        Jiaxun Yang <jiaxun.yang@flygoat.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
        Binbin Zhou <zhoubinbin@loongson.cn>,
        Huacai Chen <chenhuacai@loongson.cn>,
        Thomas Gleixner <tglx@linutronix.de>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Huacai Chen <chenhuacai@kernel.org>,
        loongson-kernel@lists.loongnix.cn, devicetree@vger.kernel.org,
        Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        linux-mips@vger.kernel.org, diasyzhang@tencent.com,
        linux-kernel@vger.kernel.org, frowand.list@gmail.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, 16 Oct 2023 at 13:26, Binbin Zhou <zhoubb.aaron@gmail.com> 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