Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: ifd894703:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-692-gb287c361f5-fm-20220603.003-gb287c361
Mime-Version: 1.0
Message-Id: <692f7fc0-4953-408a-93fd-b1fe9b87663c@www.fastmail.com>
In-Reply-To: <87pmjjzo3k.wl-maz@kernel.org>
References: <20220525121030.16054-1-Dragan.Mladjenovic@syrmia.com>
 <20220525121030.16054-7-Dragan.Mladjenovic@syrmia.com>
 <87wndu3tff.wl-maz@kernel.org>
 <0a5dd632-0607-dab6-4de7-1ea248490863@flygoat.com>
 <87pmjjzo3k.wl-maz@kernel.org>
Date:   Thu, 09 Jun 2022 11:14:01 +0100
From:   "Jiaxun Yang" <jiaxun.yang@flygoat.com>
To:     "Marc Zyngier" <maz@kernel.org>
Cc:     "Dragan Mladjenovic" <Dragan.Mladjenovic@syrmia.com>,
        "Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
        "Chao-ying Fu" <cfu@wavecomp.com>,
        "Daniel Lezcano" <daniel.lezcano@linaro.org>,
        "Geert Uytterhoeven" <geert@linux-m68k.org>,
        "Greg Ungerer" <gerg@kernel.org>,
        "Hauke Mehrtens" <hauke@hauke-m.de>,
        "Ilya Lipnitskiy" <ilya.lipnitskiy@gmail.com>,
        linux-kernel@vger.kernel.org,
        "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
        "paulburton@kernel.org" <paulburton@kernel.org>,
        "Peter Zijlstra" <peterz@infradead.org>,
        "Serge Semin" <fancer.lancer@gmail.com>,
        "Thomas Gleixner" <tglx@linutronix.de>,
        "Tiezhu Yang" <yangtiezhu@loongson.cn>
Subject: Re: [PATCH v2 06/12] irqchip: mips-gic: Multi-cluster support
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


=E5=9C=A82022=E5=B9=B46=E6=9C=888=E6=97=A5=E5=85=AD=E6=9C=88 =E4=B8=8A=E5=
=8D=887:05=EF=BC=8CMarc Zyngier=E5=86=99=E9=81=93=EF=BC=9A
> On Tue, 07 Jun 2022 19:23:02 +0100,
> Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>>=20
>>=20
>>=20
>> =E5=9C=A8 2022/6/6 12:47, Marc Zyngier =E5=86=99=E9=81=93:
>> > On Wed, 25 May 2022 13:10:24 +0100,
>> > Dragan Mladjenovic <Dragan.Mladjenovic@syrmia.com> wrote:
>> >> From: Paul Burton <paulburton@kernel.org>
>> >>=20
>> >> The MIPS I6500 CPU & CM (Coherence Manager) 3.5 introduce the conc=
ept of
>> >> multiple clusters to the system. In these systems each cluster con=
tains
>> >> its own GIC, so the GIC isn't truly global any longer. We do have =
the
>> >> ability to access registers in the GICs of remote clusters using a
>> >> redirect register block much like the redirect register blocks pro=
vided
>> >> by the CM & CPC, and configured through the same GCR_REDIRECT regi=
ster
>> >> that we our mips_cm_lock_other() abstraction builds upon.
>> >>=20
>> >> It is expected that external interrupts are connected identically =
to all
>> >> clusters. That is, if we have a device providing an interrupt conn=
ected
>> >> to GIC interrupt pin 0 then it should be connected to pin 0 of eve=
ry GIC
>> >> in the system. This simplifies things somewhat by allowing us for =
the
>> >> most part to treat the GIC as though it is still truly global, so =
long
>> >> as we take care to configure interrupts in the cluster that we wan=
t them
>> >> affine to.
>> > I can see how this can work for level interrupts, but how does this
>> > work for edge interrupts? Is there any guarantee that the interrupt
>> > will be discarded if routed to a cluster where it isn't configured?
>> It is supposed to mask the interrupt out on the GIC which belongs to =
the
>> cluster that the interrupt is not routed to.
>>=20
>> When it's masked out GIC simply won't sense any level change.
>>=20
>> I guess it's sort of guarantee?
>
> Pretty much the opposite. There is a *strong* requirement that a
> masked interrupt can still detect interrupts, so that on unmask the
> interrupt fires (you'd otherwise lose edge interrupts pretty often).
Oops, sorry there is a terminology issue. On MIPS Coherent Manager
manual it uses terminology of =E2=80=9CMasked=E2=80=9D when vector regis=
ter of
a interrupt is cleared.

It means implementation will guarantee interrupt will be dropped
when it=E2=80=99s routed to nowhere.

>
> What does the MIPS GIC arch spec says about this?
Unfortunately GIC is not a arch spec. It=E2=80=99s just a implementation=
 spec
of MIPS Coherent Manager.

Thanks.
- Jiaxun

>
> Thanks,
>
> 	M.
>
> --=20
> Without deviation from the norm, progress is not possible.

--=20
- Jiaxun