summaryrefslogtreecommitdiff
path: root/drivers/pinctrl/mediatek/pinctrl-moore.c
diff options
context:
space:
mode:
authorLukas Wunner <lukas@wunner.de>2018-10-27 11:15:33 +0300
committerLinus Walleij <linus.walleij@linaro.org>2018-11-05 11:33:33 +0300
commit3c7b30f704b6f5e53eed6bf89cf2c8d1b38b02c0 (patch)
treece412b70c84691d0abff8eff4bab5fb842851387 /drivers/pinctrl/mediatek/pinctrl-moore.c
parent623f788d0e7c6ef68d1f42595345bc6c78167702 (diff)
downloadlinux-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