If the ITS or the redistributors report their shareability as zero,
then it is important to make sure they will no generate any cacheable
traffic, as this is unlikely to produce the expected result.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1427465705-17126-5-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The ITS driver sometime mixes up the use of GICR_PROPBASE bitfields
for the GICR_PENDBASE register, and GITS_BASER for GICR_CBASE.
This does not lead to any observable bug because similar bits are
at the same location, but this just make the code even harder to
understand...
This patch provides the required #defines and fixes the mixup.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1427465705-17126-4-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
When building ITS commands which have the device ID in it, we
should mask off the whole upper 32 bits of the first command word
before inserting the new value in there.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1427465705-17126-3-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
With a monolithic GICv3, redistributors are addressed using a linear
number, while a distributed implementation uses physical addresses.
When encoding a target address into a command, we strip the lower
16 bits, as redistributors are always 64kB aligned. This works
perfectly well with a distributed implementation, but has the
silly effect of always encoding target 0 in the monolithic case
(unless you have more than 64k CPUs, of course).
The obvious fix is to shift the linear target number by 16 when
computing the target address, so that we don't loose any precious
bit.
Reported-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1427465705-17126-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
It's unsafe to change the configurations of an activated ITS directly
since this will lead to unpredictable results. This patch guarantees
the ITSes being initialized are quiescent.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Yun Wu <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-12-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Define macros for GITS_CTLR fields to avoid using magic numbers.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Yun Wu <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-11-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
When required size of Device Table is out of the page allocator's
capability, the whole ITS will fail in probing. This actually is
not the hardware's problem and is mainly a limitation of the kernel
page allocator. This patch will keep ITS going on to the next
initializaion stage with an explicit warning.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Yun Wu <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-10-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The field of page size in register GITS_BASERn might be read-only
if an implementation only supports a single, fixed page size. But
currently the ITS driver will throw out an error when PAGE_SIZE
is less than the minimum size supported by an ITS. So addressing
this problem by using 64KB pages as default granule for all the
ITS base tables.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
[maz: fixed bug breaking non Device Table allocations]
Signed-off-by: Yun Wu <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-9-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Some kind of brain-dead implementations chooses to insert ITEes in
rapid sequence of disabled ITEes, and an un-zeroed ITT will confuse
ITS on judging whether an ITE is really enabled or not. Considering
the implementations are still supported by the GICv3 architecture,
in which ITT is not required to be zeroed before being handled to
hardware, we do the favor in ITS driver.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Yun Wu <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-8-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
When compiled with CONFIG_LOCKDEP, the kernel shouts badly, saying
that my locking is unsafe. I'm afraid the kernel is right:
CPU0 CPU1
---- ----
lock(&its->lock);
local_irq_disable();
lock(&irq_desc_lock_class);
lock(&its->lock);
<Interrupt>
lock(&irq_desc_lock_class);
*** DEADLOCK ***
The fix is to always take its->lock with interrupts disabled.
Reported-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-5-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The current PCI/MSI support in the GICv3 ITS doesn't really deal
with systems where different PCI devices end-up using the same
RequesterID (as it would be the case with non-transparent bridges,
for example). It is likely that none of these devices would
actually generate any interrupt, as the ITS is programmed with
the device's own ID, and not that of the bridge.
A solution to this is to iterate over the PCI hierarchy to
discover what the device aliases too. We also use this
to discover the upper bound of the number of MSIs that this
sub-hierarchy can generate.
With this in place, PCI aliases can be supported.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-4-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The ITS table allocator is only allocating a single page per table.
This works fine for most things, but leads to silent lack of
interrupt delivery if we end-up with a device that has an ID that is
out of the range defined by a single page of memory. Even worse, depending
on the page size, behaviour changes, which is not a very good experience.
A solution is actually to allocate memory for the full range of ID that
the ITS supports. A massive waste memory wise, but at least a safe bet.
Tested on a Phytium SoC.
Tested-by: Chen Baozi <chenbaozi@kylinos.com.cn>
Acked-by: Chen Baozi <chenbaozi@kylinos.com.cn>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-3-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
We skip initialisation of ITS in case the device-tree has no
corresponding description, but we are still accessing to ITS bits while
setting CPU interface what leads to the kernel panic:
ITS: No ITS available, not enabling LPIs
CPU0: found redistributor 0 region 0:0x000000002f100000
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = ffffffc0007fb000
[00000000] *pgd=00000000fc407003, *pud=00000000fc407003, *pmd=00000000fc408003, *pte=006000002f000707
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc2+ #318
Hardware name: FVP Base (DT)
task: ffffffc00077edb0 ti: ffffffc00076c000 task.ti: ffffffc00076c000
PC is at its_cpu_init+0x2c/0x320
LR is at gic_cpu_init+0x168/0x1bc
It happens in gic_rdists_supports_plpis() because gic_rdists is NULL.
The gic_rdists is set to non-NULL only when ITS node is presented in
the device-tree.
Fix this by moving the call to gic_rdists_supports_plpis() inside the
!list_empty(&its_nodes) block, because it is that list that guards the
validity of the rest of the information in this driver.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
arm64 defconfig spits out the following compiler warning from the ITS
driver:
In file included from include/linux/bitmap.h:9:0,
from drivers/irqchip/irq-gic-v3-its.c:18:
drivers/irqchip/irq-gic-v3-its.c: In function ‘its_create_device’:
include/linux/kernel.h:716:17: warning: comparison of distinct pointer types lacks a cast
(void) (&_max1 == &_max2); \
^
drivers/irqchip/irq-gic-v3-its.c:1056:12: note: in expansion of macro ‘max’
nr_ites = max(2, roundup_pow_of_two(nvecs));
Fix the warning by specifying the decimal constant `2' explicitly as an
unsigned long type.
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1418825469-30529-1-git-send-email-will.deacon@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
When issuing a MAPD command, one of the parameters passed to the ITS
is the number of EventID bits used to index the per-device Interrupt
Translation Table (ITT). Crucially, this is the number of bits
*minus one*.
This has two consequences:
- The size of the ITT has to be a strict power of two, no matter
how many different events the device is actually going to generate.
- It is impossible to express an ITT with a single entry, as you
would have to tell the ITS to "use zero bit from the EventID",
and that clashes with "minus one" above.
Fix this by allocating the ITT with the number of vectors rounded up
to the next power of two, with a minimum of two entries.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Yun Wu (Abel) <wuyun.wu@huawei.com>
Cc: Robert Richter <robert.richter@caviumnetworks.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The ITS code could do a bit less in the alloc/free paths, and a bit
more in the activate/deactivate methods, giving a better separation
between software allocation and HW programing.
Suggested-by: Wuyun Wu (Abel) <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Yun Wu (Abel) <wuyun.wu@huawei.com>
Cc: Robert Richter <robert.richter@caviumnetworks.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Fix stupid thinko on the path freeing the interrupts, where only
the first interrupt would get reset, and none of the others.
This should only affect multi-MSI allocations.
Reported-by: Wuyun Wu (Abel) <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Robert Richter <robert.richter@caviumnetworks.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The ITS has a notion of "device" that can write to it in order to
generate an interrupt.
Conversly, the driver maintains a per-ITS list of devices, together
with their configuration information, and uses this to configure
the HW.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1416839720-18400-9-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The interrupt translation is driven by a set of tables (device,
ITT, and collection) to be in the end delivered to a CPU. Also,
the redistributors rely on a couple of tables (configuration, and
pending) to deliver the interrupts to the CPUs.
This patch adds the required allocators for these tables.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1416839720-18400-8-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
LPIs are the type of interrupts that are used by the ITS. Given
the size of the namespace (anywhere between 16 and 32bit), interrupt
IDs are allocated in chunks of 32.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1416839720-18400-7-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The ITS is configured through a number commands that the driver
issues to the HW using a memory-based circular buffer.
This patch implements the subset of commands that are required
for Linux.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1416839720-18400-5-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Marc Zyngier