diff options
author | Lukas Wunner <lukas@wunner.de> | 2018-10-27 11:15:33 +0300 |
---|---|---|
committer | Linus Walleij <linus.walleij@linaro.org> | 2018-11-05 11:33:33 +0300 |
commit | 3c7b30f704b6f5e53eed6bf89cf2c8d1b38b02c0 (patch) | |
tree | ce412b70c84691d0abff8eff4bab5fb842851387 /drivers/pinctrl/mediatek/pinctrl-moore.c | |
parent | 623f788d0e7c6ef68d1f42595345bc6c78167702 (diff) | |
download | linux-3c7b30f704b6f5e53eed6bf89cf2c8d1b38b02c0.tar.xz |
pinctrl: bcm2835: Use raw spinlock for RT compatibility
The BCM2835 pinctrl driver acquires a spinlock in its ->irq_enable,
->irq_disable and ->irq_set_type callbacks. Spinlocks become sleeping
locks with CONFIG_PREEMPT_RT_FULL=y, therefore invocation of one of the
callbacks in atomic context may cause a hard lockup if at least two GPIO
pins in the same bank are used as interrupts. The issue doesn't occur
with just a single interrupt pin per bank because the lock is never
contended. I'm experiencing such lockups with GPIO 8 and 28 used as
level-triggered interrupts, i.e. with ->irq_disable being invoked on
reception of every IRQ.
The critical section protected by the spinlock is very small (one bitop
and one RMW of an MMIO register), hence converting to a raw spinlock
seems a better trade-off than converting the driver to threaded IRQ
handling (which would increase latency to handle an interrupt).
Cc: Mathias Duckeck <m.duckeck@kunbus.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Julia Cartwright <julia@ni.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Diffstat (limited to 'drivers/pinctrl/mediatek/pinctrl-moore.c')
0 files changed, 0 insertions, 0 deletions