summaryrefslogtreecommitdiffstats
path: root/drivers/pinctrl/meson/pinctrl-meson.c
diff options
context:
space:
mode:
authorMika Westerberg <mika.westerberg@linux.intel.com>2015-05-12 12:35:37 +0200
committerLinus Walleij <linus.walleij@linaro.org>2015-05-12 13:54:32 +0200
commite6c906dedb8a332ece0e789980eef340fdcd9e20 (patch)
treefeb3ee45359a9c96a45309887066c4b315d8f16e /drivers/pinctrl/meson/pinctrl-meson.c
parentLinux 4.1-rc3 (diff)
downloadlinux-e6c906dedb8a332ece0e789980eef340fdcd9e20.tar.xz
linux-e6c906dedb8a332ece0e789980eef340fdcd9e20.zip
pinctrl: cherryview: Read triggering type from HW if not set when requested
If a driver does not set interrupt triggering type when it calls request_irq(), it means use the pin as the hardware/firmware has configured it. There are some drivers doing this. One example is drivers/input/serio/i8042.c that requests the interrupt like: error = request_irq(I8042_KBD_IRQ, i8042_interrupt, IRQF_SHARED, "i8042", i8042_platform_device); It assumes the interrupt is already properly configured. This is true in case of interrupts connected to the IO-APIC. However, some Intel Braswell/Cherryview based machines use a GPIO here instead for the internal keyboard controller. This is a problem because even if the pin/interrupt is properly configured, the irqchip ->irq_set_type() will never be called as the triggering flags are 0. Because of that we do not have correct interrupt flow handler set for the interrupt. Fix this by adding a custom ->irq_startup() that checks if the interrupt has no triggering type set and in that case read the type directly from the hardware and install correct flow handler along with the mapping. Reported-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com> Reported-by: Freddy Paul <freddy.paul@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Diffstat (limited to 'drivers/pinctrl/meson/pinctrl-meson.c')
0 files changed, 0 insertions, 0 deletions