Linux-Kernel Archive: Re: [PATCH v2 06/12] irqchip: mips-gic: Multi-cluster support Re: [PATCH v2 06/12] irqchip: mips-gic: Multi-cluster support From: Marc Zyngier Date: Thu Jun 09 2022 - 07:55:05 EST Next message: Dmitry Vyukov: "Re: [PATCH 3/8] perf/hw_breakpoint: Optimize constant number of breakpoint slots" Previous message: Peter Zijlstra: "Re: [PATCH v7] sched/fair: Consider cpu affinity when allowing NUMA imbalance in find_idlest_group" In reply to: Jiaxun Yang: "Re: [PATCH v2 06/12] irqchip: mips-gic: Multi-cluster support" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Thu, 09 Jun 2022 11:14:01 +0100, "Jiaxun Yang"
wrote: > > > > 在2022年6月8日六月 上午7:05，Marc Zyngier写道： > > On Tue, 07 Jun 2022 19:23:02 +0100, > > Jiaxun Yang wrote: > >> > >> > >> > >> 在 2022/6/6 12:47, Marc Zyngier 写道: > >> > On Wed, 25 May 2022 13:10:24 +0100, > >> > Dragan Mladjenovic wrote: > >> >> From: Paul Burton > >> >> > >> >> 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? > > > > 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 “Masked” when vector register of > a interrupt is cleared. > > It means implementation will guarantee interrupt will be dropped > when it’s routed to nowhere. Ah, right, that makes more sense. Thanks, M. -- Without deviation from the norm, progress is not possible. Next message: Dmitry Vyukov: "Re: [PATCH 3/8] perf/hw_breakpoint: Optimize constant number of breakpoint slots" Previous message: Peter Zijlstra: "Re: [PATCH v7] sched/fair: Consider cpu affinity when allowing NUMA imbalance in find_idlest_group" In reply to: Jiaxun Yang: "Re: [PATCH v2 06/12] irqchip: mips-gic: Multi-cluster support" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
