linux-toradex.git/drivers/irqchip, branch v3.12.43

irqchip: gic: Fix core ID calculation when topology is read from DT

2014-07-29T15:01:43+00:00

commit 29e697b11853d3f83b1864ae385abdad4aa2c361 upstream.

Certain GIC implementation, namely those found on earlier, single
cluster, Exynos SoCs, have registers mapped without per-CPU banking,
which means that the driver needs to use different offset for each CPU.

Currently the driver calculates the offset by multiplying value returned
by cpu_logical_map() by CPU offset parsed from DT. This is correct when
CPU topology is not specified in DT and aforementioned function returns
core ID alone. However when DT contains CPU topology, the function
changes to return cluster ID as well, which is non-zero on mentioned
SoCs and so breaks the calculation in GIC driver.

This patch fixes this by masking out cluster ID in CPU offset
calculation so that only core ID is considered. Multi-cluster Exynos
SoCs already have banked GIC implementations, so this simple fix should
be enough.

Reported-by: Lorenzo Pieralisi 
Reported-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Tomasz Figa 
Fixes: db0d4db22a78d ("ARM: gic: allow GIC to support non-banked setups")
Link: https://lkml.kernel.org/r/1405610624-18722-1-git-send-email-t.figa@samsung.com
Signed-off-by: Jason Cooper 
Signed-off-by: Jiri Slaby

irqchip: gic: Add support for cortex a7 compatible string

2014-07-29T15:01:43+00:00

commit a97e8027b1d28eafe6bafe062556c1ec926a49c6 upstream.

Patch 0a68214b "ARM: DT: Add binding for GIC virtualization extentions (VGIC)" added
the "arm,cortex-a7-gic" compatible string, but the corresponding IRQCHIP_DECLARE
was never added to the gic driver.

To let real Cortex-A7 SoCs use it, add the necessary declaration to the device driver.

Signed-off-by: Matthias Brugger 
Link: https://lkml.kernel.org/r/1404388732-28890-1-git-send-email-matthias.bgg@gmail.com
Fixes: 0a68214b76ca ("ARM: DT: Add binding for GIC virtualization extentions (VGIC)")
Signed-off-by: Jason Cooper 
Signed-off-by: Jiri Slaby

irqchip: spear_shirq: Fix interrupt offset

2014-07-18T13:51:08+00:00

commit 4f4366033945419b0c52118c29d3057d7c558765 upstream.

The ras3 block on spear320 claims to have 3 interrupts. In fact it has
one and 6 reserved interrupts. Account the 6 reserved to this block so
it has 7 interrupts total. That matches the datasheet and the device
tree entries.

Broken since commit 80515a5a(ARM: SPEAr3xx: shirq: simplify and move
the shared irq multiplexor to DT). Testing is overrated....

Signed-off-by: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20140619212712.872379208@linutronix.de
Fixes: 80515a5a2e3c ('ARM: SPEAr3xx: shirq: simplify and move the shared irq multiplexor to DT')
Acked-by: Viresh Kumar 
Signed-off-by: Jason Cooper 
Signed-off-by: Jiri Slaby

irqchip: Gic: Support forced affinity setting

2014-06-06T09:40:20+00:00

commit ffde1de64012c406dfdda8690918248b472f24e4 upstream.

To support the affinity setting of per cpu timers in the early startup
of a not yet online cpu, implement the force logic, which disables the
cpu online check.

Tagged for stable to allow a simple fix of the affected SoC clock
event drivers.

Signed-off-by: Thomas Gleixner 
Tested-by: Krzysztof Kozlowski 
Cc: Kyungmin Park 
Cc: Marek Szyprowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tomasz Figa ,
Cc: Daniel Lezcano ,
Cc: Kukjin Kim 
Cc: linux-arm-kernel@lists.infradead.org,
Link: http://lkml.kernel.org/r/20140416143315.916984416@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Jiri Slaby

irq-metag*: stop set_affinity vectoring to offline cpus

2014-03-05T16:13:54+00:00

commit f229006ec6beabf7b844653d92fa61f025fe3dcf upstream.

Fix irq_set_affinity callbacks in the Meta IRQ chip drivers to AND
cpu_online_mask into the cpumask when picking a CPU to vector the
interrupt to.

As Thomas pointed out, the /proc/irq/$N/smp_affinity interface doesn't
filter out offline CPUs, so without this patch if you offline CPU0 and
set an IRQ affinity to 0x3 it vectors the interrupt onto CPU0 even
though it is offline.

Reported-by: Thomas Gleixner 
Signed-off-by: James Hogan 
Cc: Thomas Gleixner 
Cc: linux-metag@vger.kernel.org
Signed-off-by: Jiri Slaby

irqchip: orion: Fix getting generic chip pointer.

2014-03-05T16:13:52+00:00

commit d86e9af6336c0ad586a5dbd70064253d40bbb5ff upstream.

Enabling SPARSE_IRQ shows up a bug in the irq-orion bridge interrupt
handler. The bridge interrupt is implemented using a single generic
chip. Thus the parameter passed to irq_get_domain_generic_chip()
should always be zero.

Signed-off-by: Andrew Lunn 
Acked-by: Sebastian Hesselbarth 
Fixes: 9dbd90f17e4f ("irqchip: Add support for Marvell Orion SoCs")
Signed-off-by: Jason Cooper 
Signed-off-by: Jiri Slaby

irqchip: orion: clear stale interrupts in irq_startup

2014-03-05T16:13:52+00:00

commit e0318ec3bf3f1502cd11b21b1eb00aa355b40b67 upstream.

Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in
IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear
them before unmask. This installs an .irq_startup callback to ensure stale
irqs are cleared before initial unmask.

Signed-off-by: Sebastian Hesselbarth 
Tested-by: Ezequiel Garcia 
Signed-off-by: Jason Cooper 
Signed-off-by: Jiri Slaby

irqchip: orion: use handle_edge_irq on bridge irqs

2014-03-05T16:13:52+00:00

commit 5f40067fc86f0e49329ad4a852c278998ff4394e upstream.

Bridge irqs are edge-triggered, i.e. they get asserted on low-to-high
transitions and not on the level of the downstream interrupt line.
This replaces handle_level_irq by the more appropriate handle_edge_irq.

Signed-off-by: Sebastian Hesselbarth 
Tested-by: Ezequiel Garcia 
Signed-off-by: Jason Cooper 
Signed-off-by: Jiri Slaby

irqchip: orion: clear bridge cause register on init

2014-03-05T16:13:52+00:00

commit 7b119fd1bdc59a8060df5b659b9f7a70e0169fd6 upstream.

It is good practice to mask and clear pending irqs on init. We already
mask all irqs, so also clear the bridge irq cause register.

Signed-off-by: Sebastian Hesselbarth 
Tested-by: Ezequiel Garcia 
Signed-off-by: Jason Cooper 
Signed-off-by: Jiri Slaby

irqchip: armada-370-xp: fix IPI race condition

2014-02-20T19:07:59+00:00

commit a6f089e95b1e08cdea9633d50ad20aa5d44ba64d upstream.

In the Armada 370/XP driver, when we receive an IRQ 0, we read the
list of doorbells that caused the interrupt from register
ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS. This gives the list of IPIs that
were generated. However, instead of acknowledging only the IPIs that
were generated, we acknowledge *all* the IPIs, by writing
~IPI_DOORBELL_MASK in the ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS register.

This creates a race condition: if a new IPI that isn't part of the
ones read into the temporary "ipimask" variable is fired before we
acknowledge all IPIs, then we will simply loose it. This is causing
scheduling hangs on SMP intensive workloads.

It is important to mention that this ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS
register has the following behavior: "A CPU write of 0 clears the bits
in this field. A CPU write of 1 has no effect". This is what allows us
to simply write ~ipimask to acknoledge the handled IPIs.

Notice that the same problem is present in the MSI implementation, but
it will be fixed as a separate patch, so that this IPI fix can be
pushed to older stable versions as appropriate (all the way to 3.8),
while the MSI code only appeared in 3.13.

Signed-off-by: Lior Amsalem 
Signed-off-by: Thomas Petazzoni 
Fixes: 344e873e5657e8dc0 'arm: mvebu: Add IPI support via doorbells'
Cc: Thomas Gleixner 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman