[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0a5dd632-0607-dab6-4de7-1ea248490863@flygoat.com>
Date: Tue, 7 Jun 2022 19:23:02 +0100
From: Jiaxun Yang <jiaxun.yang@...goat.com>
To: Marc Zyngier <maz@...nel.org>,
Dragan Mladjenovic <Dragan.Mladjenovic@...mia.com>
Cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Chao-ying Fu <cfu@...ecomp.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Greg Ungerer <gerg@...nel.org>,
Hauke Mehrtens <hauke@...ke-m.de>,
Ilya Lipnitskiy <ilya.lipnitskiy@...il.com>,
linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org,
Paul Burton <paulburton@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Serge Semin <fancer.lancer@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Tiezhu Yang <yangtiezhu@...ngson.cn>
Subject: Re: [PATCH v2 06/12] irqchip: mips-gic: Multi-cluster support
在 2022/6/6 12:47, Marc Zyngier 写道:
> On Wed, 25 May 2022 13:10:24 +0100,
> Dragan Mladjenovic <Dragan.Mladjenovic@...mia.com> wrote:
>> From: Paul Burton <paulburton@...nel.org>
>>
>> The MIPS I6500 CPU & CM (Coherence Manager) 3.5 introduce the concept of
>> multiple clusters to the system. In these systems each cluster contains
>> 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 provided
>> by the CM & CPC, and configured through the same GCR_REDIRECT register
>> that we our mips_cm_lock_other() abstraction builds upon.
>>
>> It is expected that external interrupts are connected identically to all
>> clusters. That is, if we have a device providing an interrupt connected
>> to GIC interrupt pin 0 then it should be connected to pin 0 of every 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 want 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.
When it's masked out GIC simply won't sense any level change.
I guess it's sort of guarantee?
Thanks
- Jiaxun
>
> Otherwise, I can imagine plenty of spurious interrupts on affinity
> change.
>
> Thanks,
>
> M.
>
Powered by blists - more mailing lists