diff options
author | Paul Burton <paulburton@kernel.org> | 2024-10-28 18:59:26 +0100 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2024-10-30 15:41:18 +0100 |
commit | 322a9063876890895cb8308cc6f59de312e8aad5 (patch) | |
tree | 41859cfb5d2109bd45b74c5a548099bac9190c68 /tools/perf/scripts/python/export-to-postgresql.py | |
parent | c7c0d13d1d308b6e2a3d69274b38fca0167081df (diff) |
irqchip/mips-gic: Multi-cluster support
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. Access to
registers in the GICs of remote clusters is possible 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
mips_cm_lock_other() abstraction builds upon.
It is expected that external interrupts are connected identically on all
clusters. That is, if there is 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. For the most part, the GIC can be treated as though it is
still truly global, so long as interrupts in the cluster are configured
properly.
Introduce support for such multi-cluster systems in the MIPS GIC irqchip
driver. A newly introduced gic_irq_lock_cluster() function allows:
1) Configure access to a GIC in a remote cluster via the redirect
register block, using mips_cm_lock_other().
Or:
2) Detect that the interrupt in question is affine to the local
cluster and plain old GIC register access to the GIC in the
local cluster should be used.
It is possible to access the local cluster's GIC registers via the
redirect block, but keeping the special case for them is both good for
performance (because we avoid the locking & indirection overhead of
using the redirect block) and necessary to maintain compatibility with
systems using CM revisions prior to 3.5 which don't support the redirect
block.
The gic_irq_lock_cluster() function relies upon an IRQs effective
affinity in order to discover which cluster the IRQ is affine to. In
order to track this & allow it to be updated at an appropriate point
during gic_set_affinity() select the generic support for effective
affinity using CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK.
gic_set_affinity() is the one function which gains much complexity. It
now deconfigures routing to any VP(E), ie. CPU, on the old cluster when
moving affinity to a new cluster.
gic_shared_irq_domain_map() moves its update of the IRQs effective
affinity to before its use of gic_irq_lock_cluster(), to ensure that
operation is on the cluster the IRQ is affine to.
The remaining changes are straightforward use of the gic_irq_lock_cluster()
function to select between local cluster & remote cluster code-paths when
configuring interrupts.
Signed-off-by: Paul Burton <paulburton@kernel.org>
Signed-off-by: Chao-ying Fu <cfu@wavecomp.com>
Signed-off-by: Dragan Mladjenovic <dragan.mladjenovic@syrmia.com>
Signed-off-by: Aleksandar Rikalo <arikalo@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Serge Semin <fancer.lancer@gmail.com>
Tested-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/all/20241028175935.51250-5-arikalo@gmail.com
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions