summaryrefslogtreecommitdiffstats
path: root/tools/include
diff options
context:
space:
mode:
authorGrygorii Strashko <grygorii.strashko@ti.com>2015-09-25 12:28:03 -0700
committerLinus Walleij <linus.walleij@linaro.org>2015-10-02 13:08:21 -0700
commit450fa54cfd66e3dda6eda26256637ee8928af12a (patch)
treee2cfa718761339afad7d8a816aaae72caf106e37 /tools/include
parentaca82d1cbb49af34b69ecd4571a0fe48ad9247c1 (diff)
downloadblackbird-op-linux-450fa54cfd66e3dda6eda26256637ee8928af12a.tar.gz
blackbird-op-linux-450fa54cfd66e3dda6eda26256637ee8928af12a.zip
gpio: omap: convert to use generic irq handler
This patch converts TI OMAP GPIO driver to use generic irq handler instead of chained IRQ handler. This way OMAP GPIO driver will be compatible with RT kernel where it will be forced thread IRQ handler while in non-RT kernel it still will be executed in HW IRQ context. As part of this change the IRQ wakeup configuration is applied to GPIO Bank IRQ as it now will be under control of IRQ PM Core during suspend. There are also additional benefits: - on-RT kernel there will be no complains any more about PM runtime usage in atomic context "BUG: sleeping function called from invalid context"; - GPIO bank IRQs will appear in /proc/interrupts and its usage statistic will be visible; - GPIO bank IRQs could be configured through IRQ proc_fs interface and, as result, could be a part of IRQ balancing process if needed; - GPIO bank IRQs will be under control of IRQ PM Core during suspend to RAM. Disadvantage: - additional runtime overhed as call chain till omap_gpio_irq_handler() will be longer now - necessity to use wa_lock in omap_gpio_irq_handler() to W/A warning in handle_irq_event_percpu() WARNING: CPU: 1 PID: 35 at kernel/irq/handle.c:149 handle_irq_event_percpu+0x51c/0x638() This patch doesn't fully follows recommendations provided by Sebastian Andrzej Siewior [1], because It's required to go through and check all GPIO IRQ pin states as fast as possible and pass control to handle_level_irq or handle_edge_irq. handle_level_irq or handle_edge_irq will perform actions specific for IRQ triggering type and wakeup corresponding registered threaded IRQ handler (at least it's expected to be threaded). IRQs can be lost if handle_nested_irq() will be used, because excecution time of some pin specific GPIO IRQ handler can be very significant and require accessing ext. devices (I2C). Idea of such kind reworking was also discussed in [2]. [1] http://www.spinics.net/lists/linux-omap/msg120665.html [2] http://www.spinics.net/lists/linux-omap/msg119516.html Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Austin Schuh <austin@peloton-tech.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Diffstat (limited to 'tools/include')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud