aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpio/gpio-omap.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2016-04-26gpio: omap: fix irq triggering in smart-idle wakeup modeGrygorii Strashko1-40/+2
Now GPIO IRQ loss is observed on dra7-evm after suspend/resume cycle in the following case: extcon_usb1(id_irq) -> pcf8575.gpio1 -> omapgpio6.gpio11 -> gic the extcon_usb1 is wake up source and it enables IRQ wake up for id_irq by calling enable/disable_irq_wake() during suspend/resume which, in turn, causes execution of omap_gpio_wake_enable(). And omap_gpio_wake_enable() will set/clear corresponding bit in GPIO_IRQWAKEN_x register. omapgpio6 configuration after boot - wakeup is enabled for GPIO IRQs by default from omap_gpio_irq_type: GPIO_IRQSTATUS_SET_0 | 0x00000400 GPIO_IRQSTATUS_CLR_0 | 0x00000400 GPIO_IRQWAKEN_0 | 0x00000400 GPIO_RISINGDETECT | 0x00000000 GPIO_FALLINGDETECT | 0x00000400 omapgpio6 configuration after after suspend/resume cycle: GPIO_IRQSTATUS_SET_0 | 0x00000400 GPIO_IRQSTATUS_CLR_0 | 0x00000400 GPIO_IRQWAKEN_0 | 0x00000000 <--- GPIO_RISINGDETECT | 0x00000000 GPIO_FALLINGDETECT | 0x00000400 As result, system will start to lose interrupts from pcf8575 GPIO expander, because when OMAP GPIO IP is in smart-idle wakeup mode, there is no guarantee that transition(s) on input non wake up GPIO pin will trigger asynchronous wake-up request to PRCM and then IRQ generation. IRQ will be generated when GPIO is in active mode - for example, some time after accessing GPIO bank registers IRQs will be generated normally, but issue will happen again once PRCM will put GPIO in low power smart-idle wakeup mode. Note 1. Issue is not reproduced if debounce clk is enabled for GPIO bank. Note 2. Issue hardly reproducible if GPIO pins group contains both wakeup/non-wakeup gpios - for example, it will be hard to reproduce issue with pin2 if GPIO_IRQWAKEN_0=0x1 GPIO_IRQSTATUS_SET_0=0x3 GPIO_FALLINGDETECT = 0x3 (TRM "Power Saving by Grouping the Edge/Level Detection"). Note 3. There nothing common bitween System wake up and OMAP GPIO bank IP wake up logic - the last one defines how the GPIO bank ON-IDLE-ON transition will happen inside SoC under control of PRCM. Hence, fix the problem by removing omap_set_gpio_wakeup() function completely and so keeping always in sync GPIO IRQ mask/unmask (IRQSTATUS_SET) and wake up enable (GPIO_IRQWAKEN) bits; and adding IRQCHIP_MASK_ON_SUSPEND flag in OMAP GPIO irqchip. That way non wakeup GPIO IRQs will be properly masked/unmask by IRQ PM core during suspend/resume cycle. Cc: Roger Quadros <rogerq@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-03-09gpio: omap: drop dev field from gpio_bank structureGrygorii Strashko1-28/+29
GPIO chip structure already has "parent" field which is used for the same purpose as "dev" field in gpio_bank structure - store pointer on GPIO device. Hence, drop duplicated "dev" field from gpio_bank structure. 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>
2016-01-05gpio: omap: use gpiochip data pointerLinus Walleij1-10/+10
This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Tony Lindgren <tony@atomide.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-12-21Merge tag 'v4.4-rc6' into develLinus Walleij1-2/+0
Linux 4.4-rc6
2015-11-30gpio: omap: drop omap1 mpuio specific irq_mask/unmask callbacksGrygorii Strashko1-2/+0
Originally OMAP MPUIO GPIO irqchip was implemented using Generic irq chip, but after set of reworks Generic irq chip code was replaced by common OMAP GPIO implementation and finally removed by commit d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts"). Unfortunately, above commit left .irq_mask/unmask callbacks assigned as below for MPUIO GPIO case: irqc->irq_mask = irq_gc_mask_set_bit; irqc->irq_unmask = irq_gc_mask_clr_bit; This now causes boot failure on OMAP1 platforms, after commit 450fa54cfd66 ("gpio: omap: convert to use generic irq handler") which forces these callbacks to be called during GPIO IRQs mapping from gpiochip_irq_map: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 75 [#1] ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 4.4.0-rc1-e3-los_afe0c+-00002-g25379c0-dirty #1 Hardware name: Amstrad E3 (Delta) task: c1836000 ti: c1838000 task.ti: c1838000 PC is at irq_gc_mask_set_bit+0x1c/0x60 LR is at __irq_do_set_handler+0x118/0x15c pc : [<c004848c>] lr : [<c0047d4c>] psr: 600000d3 sp : c1839c90 ip : c1862c64 fp : c1839c9c r10: 00000000 r9 : c0411950 r8 : c0411bbc r7 : 00000000 r6 : c185c310 r5 : c00444e8 r4 : c185c300 r3 : c1854b50 r2 : 00000000 r1 : 00000000 r0 : c185c310 Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 0000317f Table: 10004000 DAC: 00000057 Process swapper (pid: 1, stack limit = 0xc1838190) Stack: (0xc1839c90 to 0xc183a000) [...] Backtrace: [<c0048470>] (irq_gc_mask_set_bit) from [<c0047d4c>] (__irq_do_set_handler+0x118/0x15c) [<c0047c34>] (__irq_do_set_handler) from [<c0047dd4>] (__irq_set_handler+0x44/0x5c) r6:00000000 r5:c00444e8 r4:c185c300 [<c0047d90>] (__irq_set_handler) from [<c0047e1c>] (irq_set_chip_and_handler_name+0x30/0x34) r7:00000050 r6:00000000 r5:c00444e8 r4:00000050 [<c0047dec>] (irq_set_chip_and_handler_name) from [<c01b345c>] (gpiochip_irq_map+0x3c/0x8c) r7:00000050 r6:00000000 r5:00000050 r4:c1862c64 [<c01b3420>] (gpiochip_irq_map) from [<c0049670>] (irq_domain_associate+0x7c/0x1c4) r5:c185c310 r4:c185cb00 [<c00495f4>] (irq_domain_associate) from [<c0049894>] (irq_domain_add_simple+0x98/0xc0) r8:c0411bbc r7:c185cb00 r6:00000050 r5:00000010 r4:00000001 [<c00497fc>] (irq_domain_add_simple) from [<c01b3328>] (_gpiochip_irqchip_add+0x64/0x10c) r7:c1862c64 r6:c0419280 r5:c1862c64 r4:c1854b50 [<c01b32c4>] (_gpiochip_irqchip_add) from [<c01b79f4>] (omap_gpio_probe+0x2fc/0x63c) r5:c1854b50 r4:c1862c10 [<c01b76f8>] (omap_gpio_probe) from [<c01fcf58>] (platform_drv_probe+0x2c/0x64) r10:00000000 r9:c03e45e8 r8:00000000 r7:c0419294 r6:c0411984 r5:c0419294 r4:c0411950 [<c01fcf2c>] (platform_drv_probe) from [<c01fb668>] (really_probe+0x160/0x29c) Hence, fix it by remove obsolete callbacks assignment. After this change omap_gpio_mask_irq()/omap_gpio_unmask_irq() will be used for MPUIO IRQs masking, but this now happens anyway from omap_gpio_irq_startup/shutdown(). Cc: Tony Lindgren <tony@atomide.com> Fixes: commit d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts") Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-11-19gpio: change member .dev to .parentLinus Walleij1-2/+2
The name .dev in a struct is normally reserved for a struct device that is let us say a superclass to the thing described by the struct. struct gpio_chip stands out by confusingly using a struct device *dev to point to the parent device (such as a platform_device) that represents the hardware. As we want to give gpio_chip:s real devices, this is not working. We need to rename this member to parent. This was done by two coccinelle scripts, I guess it is possible to combine them into one, but I don't know such stuff. They look like this: @@ struct gpio_chip *var; @@ -var->dev +var->parent and: @@ struct gpio_chip var; @@ -var.dev +var.parent and: @@ struct bgpio_chip *var; @@ -var->gc.dev +var->gc.parent Plus a few instances of bgpio that I couldn't figure out how to teach Coccinelle to rewrite. This patch hits all over the place, but I *strongly* prefer this solution to any piecemal approaches that just exercise patch mechanics all over the place. It mainly hits drivers/gpio and drivers/pinctrl which is my own backyard anyway. Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Alek Du <alek.du@intel.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-10-16gpio: omap: fix static checker warningGrygorii Strashko1-1/+1
This patch fixes below static checker warning by changing type of irq field in struct gpio_bank from u16 to int. drivers/gpio/gpio-omap.c:1191 omap_gpio_probe() warn: assigning (-6) to unsigned variable 'bank->irq' drivers/gpio/gpio-omap.c 1188 bank->irq = platform_get_irq(pdev, 0); 1189 if (bank->irq <= 0) { bank->irq is u16. 1190 if (!bank->irq) 1191 bank->irq = -ENXIO; Does not work. 1192 if (bank->irq != -EPROBE_DEFER) Does not work. 1193 dev_err(dev, 1194 "can't get irq resource ret=%d\n", bank->irq); 1195 return bank->irq; 1196 } Fixes: commit 89d18e3af8b9: "gpio: omap: switch to use platform_get_irq" Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-10-02gpio: omap: convert to use generic irq handlerGrygorii Strashko1-28/+27
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>
2015-10-02gpio: omap: move pm runtime in irq_chip.irq_bus_lock/sync_unlockGrygorii Strashko1-10/+15
The PM runtime API can't be used in atomic contex on -RT even if it's configured as irqsafe. As result, below error report can be seen when PM runtime API called from IRQ chip's callbacks irq_startup/irq_shutdown/irq_set_type, because they are protected by RAW spinlock: BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917 in_atomic(): 1, irqs_disabled(): 128, pid: 96, name: insmod 3 locks held by insmod/96: #0: (&dev->mutex){......}, at: [<c04752c8>] __driver_attach+0x54/0xa0 #1: (&dev->mutex){......}, at: [<c04752d4>] __driver_attach+0x60/0xa0 #2: (class){......}, at: [<c00a408c>] __irq_get_desc_lock+0x60/0xa4 irq event stamp: 1834 hardirqs last enabled at (1833): [<c06ab2a4>] _raw_spin_unlock_irqrestore+0x88/0x90 hardirqs last disabled at (1834): [<c06ab068>] _raw_spin_lock_irqsave+0x2c/0x64 softirqs last enabled at (0): [<c003d220>] copy_process.part.52+0x410/0x19d8 softirqs last disabled at (0): [< (null)>] (null) Preemption disabled at:[< (null)>] (null) CPU: 1 PID: 96 Comm: insmod Tainted: G W O 4.1.3-rt3-00618-g57e2387-dirty #184 Hardware name: Generic DRA74X (Flattened Device Tree) [<c00190f4>] (unwind_backtrace) from [<c0014734>] (show_stack+0x20/0x24) [<c0014734>] (show_stack) from [<c06a62ec>] (dump_stack+0x88/0xdc) [<c06a62ec>] (dump_stack) from [<c006ca44>] (___might_sleep+0x198/0x2a8) [<c006ca44>] (___might_sleep) from [<c06ab6d4>] (rt_spin_lock+0x30/0x70) [<c06ab6d4>] (rt_spin_lock) from [<c04815ac>] (__pm_runtime_resume+0x68/0xa4) [<c04815ac>] (__pm_runtime_resume) from [<c04123f4>] (omap_gpio_irq_type+0x188/0x1d8) [<c04123f4>] (omap_gpio_irq_type) from [<c00a64e4>] (__irq_set_trigger+0x68/0x130) [<c00a64e4>] (__irq_set_trigger) from [<c00a7bc4>] (irq_set_irq_type+0x44/0x6c) [<c00a7bc4>] (irq_set_irq_type) from [<c00abbf8>] (irq_create_of_mapping+0x120/0x174) [<c00abbf8>] (irq_create_of_mapping) from [<c0577b74>] (of_irq_get+0x48/0x58) [<c0577b74>] (of_irq_get) from [<c0540a14>] (i2c_device_probe+0x54/0x15c) [<c0540a14>] (i2c_device_probe) from [<c04750dc>] (driver_probe_device+0x184/0x2c8) [<c04750dc>] (driver_probe_device) from [<c0475310>] (__driver_attach+0x9c/0xa0) [<c0475310>] (__driver_attach) from [<c0473238>] (bus_for_each_dev+0x7c/0xb0) [<c0473238>] (bus_for_each_dev) from [<c0474af4>] (driver_attach+0x28/0x30) [<c0474af4>] (driver_attach) from [<c0474760>] (bus_add_driver+0x154/0x200) [<c0474760>] (bus_add_driver) from [<c0476348>] (driver_register+0x88/0x108) [<c0476348>] (driver_register) from [<c0541600>] (i2c_register_driver+0x3c/0x90) [<c0541600>] (i2c_register_driver) from [<bf003018>] (pcf857x_init+0x18/0x24 [gpio_pcf857x]) [<bf003018>] (pcf857x_init [gpio_pcf857x]) from [<c000998c>] (do_one_initcall+0x128/0x1e8) [<c000998c>] (do_one_initcall) from [<c06a4220>] (do_init_module+0x6c/0x1bc) [<c06a4220>] (do_init_module) from [<c00dd0c8>] (load_module+0x18e8/0x21c4) [<c00dd0c8>] (load_module) from [<c00ddaa0>] (SyS_init_module+0xfc/0x158) [<c00ddaa0>] (SyS_init_module) from [<c000ff40>] (ret_fast_syscall+0x0/0x54) The IRQ chip interface defines only two callbacks which are executed in non-atomic contex - irq_bus_lock/irq_bus_sync_unlock, so lets move PM runtime calls there. 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>
2015-09-18Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds1-1/+1
Pull irq updates from Thomas Gleixner: "This is a rather large update post rc1 due to the final steps of cleanups and API changes which had to wait for the preparatory patches to hit your tree. - Regression fixes for ARM GIC irqchips - Regression fixes and lockdep anotations for renesas irq chips - The leftovers of the cleanup and preparatory patches which have been ignored by maintainers - Final conversions of the newly merged users of obsolete APIs - Final removal of obsolete APIs - Final removal of ARM artifacts which had been introduced during the conversion of ARM to the generic interrupt code. - Final split of the irq_data into chip specific and common data to reflect the needs of hierarchical irq domains. - Treewide removal of the first argument of interrupt flow handlers, i.e. the irq number, which is not used by the majority of handlers and simple to retrieve from the other argument the irq descriptor. - A few comment updates and build warning fixes" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (40 commits) arm64: Remove ununsed set_irq_flags ARM: Remove ununsed set_irq_flags sh: Kill off set_irq_flags usage irqchip: Kill off set_irq_flags usage gpu/drm: Kill off set_irq_flags usage genirq: Remove irq argument from irq flow handlers genirq: Move field 'msi_desc' from irq_data into irq_common_data genirq: Move field 'affinity' from irq_data into irq_common_data genirq: Move field 'handler_data' from irq_data into irq_common_data genirq: Move field 'node' from irq_data into irq_common_data irqchip/gic-v3: Use IRQD_FORWARDED_TO_VCPU flag irqchip/gic: Use IRQD_FORWARDED_TO_VCPU flag genirq: Provide IRQD_FORWARDED_TO_VCPU status flag genirq: Simplify irq_data_to_desc() genirq: Remove __irq_set_handler_locked() pinctrl/pistachio: Use irq_set_handler_locked gpio: vf610: Use irq_set_handler_locked powerpc/mpc8xx: Use irq_set_handler_locked() powerpc/ipic: Use irq_set_handler_locked() powerpc/cpm2: Use irq_set_handler_locked() ...
2015-09-16genirq: Remove irq argument from irq flow handlersThomas Gleixner1-1/+1
Most interrupt flow handlers do not use the irq argument. Those few which use it can retrieve the irq number from the irq descriptor. Remove the argument. Search and replace was done with coccinelle and some extra helper scripts around it. Thanks to Julia for her help! Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Julia Lawall <Julia.Lawall@lip6.fr> Cc: Jiang Liu <jiang.liu@linux.intel.com>
2015-09-14gpio: omap: Fix GPIO numbering for deferred probeTony Lindgren1-1/+3
If gpio-omap probe fails with -EPROBE_DEFER, the GPIO numbering keeps increasing. Only increase the gpio count if gpiochip_add() was successful as otherwise the numbers will increase for each probe attempt. Cc: Javier Martinez Canillas <javier@dowhile0.org> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Santosh Shilimkar <ssantosh@kernel.org> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-09-14gpio: omap: Fix gpiochip_add() handling for deferred probeTony Lindgren1-1/+4
Currently we gpio-omap breaks if gpiochip_add() returns -EPROBE_DEFER: [ 0.570000] gpiochip_add: GPIOs 0..31 (gpio) failed to register [ 0.570000] omap_gpio 48310000.gpio: Could not register gpio chip -517 ... [ 3.670000] omap_gpio 48310000.gpio: Unbalanced pm_runtime_enable! Let's fix the issue by adding the missing pm_runtime_put() on error. Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Javier Martinez Canillas <javier@dowhile0.org> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Santosh Shilimkar <ssantosh@kernel.org> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-08-26gpio: omap: fix clk_prepare/unprepare usageGrygorii Strashko1-9/+18
As per CCF documentation (clk.txt) the clk_prepare/unprepare APIs are not allowed in atomic context. But now OMAP GPIO driver uses them while applying debounce settings and as part of PM runtime irqsafe operations: - omap_gpio_debounce() is holding the lock with IRQs off. + omap2_set_gpio_debounce() + clk_prepare_enable() + clk_prepare() this one might sleep. - pm_runtime_get_sync() is holding the lock with IRQs off + omap_gpio_runtime_suspend() + raw_spin_lock_irqsave() + omap_gpio_dbck_disable() + clk_disable_unprepare() Hence, fix it by moeving dbclk prepare/unprepare in OMAP GPIO omap_gpio_probe/omap_gpio_remove. Also, while here, ensure that debounce functionality is disabled if clk_get() failed, because otherwise kernel will carsh in omap2_set_gpio_debounce(). Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-08-26gpio: omap: protect regs access in omap_gpio_irq_handlerGrygorii Strashko1-0/+8
The access to HW registers has to be be protected in omap_gpio_irq_handler(), as it may race with code executed on another CPUs. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-08-26gpio: omap: fix omap2_set_gpio_debounceGrygorii Strashko1-9/+10
According to TRMs: Required input line stable = (the value of the GPIO_DEBOUNCINGTIME[7:0].DEBOUNCETIME + 1) × 31, where the value of the GPIO_DEBOUNCINGTIME[7:0].DEBOUNCETIME bit field is from 0 to 255. But now omap2_set_gpio_debounce() will calculate debounce time and behave incorrectly in the following cases: 1) requested debounce time is !0 and <32 calculated DEBOUNCETIME = 0x1 == 62 us; expected value of DEBOUNCETIME = 0x0 == 31us 2) requested debounce time is 0 calculated DEBOUNCETIME = 0x1 == 62 us; expected: disable debounce and DEBOUNCETIME = 0x0 3) requested debounce time is >32 and <63 calculated DEBOUNCETIME = 0x0 and debounce will be disabled; expected: enable debounce and DEBOUNCETIME = 0x1 == 62 us Hence, rework omap2_set_gpio_debounce() to fix above cases: 1) introduce local variable "enable" and use it to identify when debounce need to be enabled or disabled. Disable debounce if requested debounce time is 0. 2) use below formula for debounce time calculation: debounce = (DIV_ROUND_UP(debounce, 31) - 1) & 0xFF; Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-08-26gpio: omap: switch to use platform_get_irqGrygorii Strashko1-5/+8
Switch OMAP GPIO driver to use platform_get_irq(), because it is not recommened to use platform_get_resource(pdev, IORESOURCE_IRQ, ..) for requesting IRQ resources any more, as they can be not ready yet in case of DT-boot. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-08-26gpio: omap: remove wrong irq_domain_remove usage in probeGrygorii Strashko1-1/+0
The bank->chip.irqdomain is uninitialized at the moment when irq_domain_remove() is called, so remove this call. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-08-13gpio: omap: Fix missing raw locks conversionAxel Lin1-1/+1
Fix below build warning: CC drivers/gpio/gpio-omap.o drivers/gpio/gpio-omap.c: In function 'omap_gpio_irq_type': drivers/gpio/gpio-omap.c:504:3: warning: passing argument 1 of 'spin_unlock_irqrestore' from incompatible pointer type [enabled by default] include/linux/spinlock.h:360:29: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *' Fixes: commit 4dbada2be460 ("gpio: omap: use raw locks for locking") Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-08-13Merge tag 'v4.2-rc4' into develLinus Walleij1-1/+4
Linux 4.2-rc4
2015-07-27gpio: omap: use raw locks for lockingSebastian Andrzej Siewior1-40/+40
This patch converts gpio_bank.lock from a spin_lock into a raw_spin_lock. The call path is to access this lock is always under a raw_spin_lock, for instance - __setup_irq() holds &desc->lock with irq off + __irq_set_trigger() + omap_gpio_irq_type() - handle_level_irq() (runs with irqs off therefore raw locks) + mask_ack_irq() + omap_gpio_mask_irq() This fixes the obvious backtrace on -RT. However the locking vs context is not and this is not limited to -RT: - omap_gpio_irq_type() is called with IRQ off and has an conditional call to pm_runtime_get_sync() which may sleep. Either it may happen or it may not happen but pm_runtime_get_sync() should not be called with irqs off. - omap_gpio_debounce() is holding the lock with IRQs off. + omap2_set_gpio_debounce() + clk_prepare_enable() + clk_prepare() this one might sleep. The number of users of gpiod_set_debounce() / gpio_set_debounce() looks low but still this is not good. Acked-by: Javier Martinez Canillas <javier@dowhile0.org> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-07-16gpio: omap: prevent module from being unloaded while in useGrygorii Strashko1-0/+1
OMAP GPIO driver allowed to be built as loadable module, but it doesn't set owner field in GPIO chip structure. As result, module_get/put() API is not working and it's possible to unload OMAP driver while in use: omap_gpio 48051000.gpio: REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED Hence, add missing configuration. Cc: Tony Lindgren <tony@atomide.com> Fixes: cac089f9026e ('gpio: omap: Allow building as a loadable module') Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-07-16gpio: omap: add missed spin_unlock_irqrestore in omap_gpio_irq_typeGrygorii Strashko1-1/+3
Add missed spin_unlock_irqrestore in omap_gpio_irq_type when omap_set_gpio_triggering() is failed. It fixes static checker warning: drivers/gpio/gpio-omap.c:523 omap_gpio_irq_type() warn: inconsistent returns 'spin_lock:&bank->lock'. This fixes commit: 1562e4618ded ('gpio: omap: fix error handling in omap_gpio_irq_type') Reported-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-07-14gpio: Use irq_desc_get_xxx() to avoid redundant lookup of irq_descJiang Liu1-1/+1
Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we already have a pointer to corresponding irq_desc. Preparatory patch for the removal of the 'irq' argument from irq flow handlers. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-07-14gpio/omap: Use irq_set_handler_locked()Thomas Gleixner1-2/+2
Use irq_set_handler_locked() as it avoids a redundant lookup of the irq descriptor. Search and replacement was done with coccinelle: Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Julia Lawall <julia.lawall@lip6.fr> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: linux-gpio@vger.kernel.org
2015-06-01gpio: omap: rework omap_gpio_irq_startup to handle current pin state properlyGrygorii Strashko1-1/+13
The omap_gpio_irq_startup() can be called at time when: - corresponding GPIO has been requested already and in this case it has to be configured as input already. If not - return with -EINVAL and do not try to re-configure it as it could be unsafe. - corresponding GPIO is free: reconfigure GPIO as input. In addition, call omap_enable_gpio_module directly as all needed checks are already present inside it. Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-06-01gpio: omap: rework omap_gpio_request to touch only gpio specific registersGrygorii Strashko1-8/+1
The GPIO Chip and GPIO IRQ Chip functionality are essentially orthogonal, so GPIO Chip implementation shouldn't touch GPIO IRQ specific registers and vise versa. Hence, rework omap_gpio_request: - don't reset GPIO IRQ triggering type to IRQ_TYPE_NONE, because GPIO irqchip should be responsible for that; - call directly omap_enable_gpio_module as all needed checks are already present inside it. Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-06-01gpio: omap: rework omap_x_irq_shutdown to touch only irqs specific registersGrygorii Strashko1-10/+5
The GPIO Chip and GPIO IRQ Chip functionality are essentially orthogonal, so GPIO IRQ Chip implementation shouldn't touch GPIO specific registers and vise versa. Hence, rework omap_gpio_irq_shutdown and try to touch only irqs specific registers: - don't configure GPIO as input (it, actually, should be already configured as input). - don't clear debounce configuration if GPIO is still used as GPIO. We need to take in to account here commit c9c55d921115 ("gpio/omap: fix off-mode bug: clear debounce settings on free/reset"). Also remove omap_reset_gpio() function as it is not used any more. Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-06-01gpio: omap: fix error handling in omap_gpio_irq_typeGrygorii Strashko1-4/+12
The GPIO bank will be kept powered in case if input parameters are invalid or error occurred in omap_gpio_irq_type. Hence, fix it by ensuring that GPIO bank will be unpowered in case of errors and add additional check of value returned from omap_set_gpio_triggering(). Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-06-01gpio: omap: fix omap_gpio_free to not clean up irq configurationGrygorii Strashko1-1/+4
This patch fixes following issue: - GPIOn is used as IRQ by some dev, for example PCF8575.INT -> gpio6.11 - PCFx driver knows nothing about type of IRQ line (GPIO or not) so it doesn't request gpio and just do request_irq() - If gpio6.11 will be exported through the sysfs and then un-xeported then IRQs from PCFx will not be received any more, because IRQ configuration for gpio6.11 will be cleaned up unconditionally in omap_gpio_free. Fix this by removing all GPIO IRQ specific code from omap_gpio_free() and also do GPIO clean up (change direction to 'in' and disable debounce) only if corresponding GPIO is not used as IRQ too. GPIO IRQ will be properly cleaned up by GPIO irqchip code. Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-12Merge tag 'v4.1-rc3' into develLinus Walleij1-39/+9
Linux 4.1-rc3
2015-05-06gpio: omap: Allow building as a loadable moduleTony Lindgren1-0/+24
We currently get all kinds of errors building the omap gpio driver as a module starting with: undefined reference to `omap2_gpio_resume_after_idle' undefined reference to `omap2_gpio_prepare_for_idle' ... Let's fix the issue by adding inline functions to the header. Note that we can now also remove the two unused functions for omap_set_gpio_debounce and omap_set_gpio_debounce_time. Then doing rmmod on the module produces further warnings because of missing exit related functions. Let's add those. And finally, we can make the Kconfig entry just a tristate option that's selected for omaps. Cc: Javier Martinez Canillas <javier@dowhile0.org> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@linaro.org> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-06gpio: omap: Fix regression for MPUIO interruptsTony Lindgren1-39/+9
At some point with all the GPIO clean-up we've broken the MPUIO interrupts. Those are just a little bit different from the GPIO interrupts, so we can fix it up just by setting different irqchip functions for it. And then we can just remove all old code trying to do the same. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Javier Martinez Canillas <javier@dowhile0.org> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@linaro.org> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-27gpio: omap: get rid of GPIO_INDEX() macroGrygorii Strashko1-9/+0
Now OMAP GPIO driver prepared for GPIO_INDEX() macro removing. Do It ;) Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Acked-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-27gpio: omap: get rid of omap_irq_to_gpio()Grygorii Strashko1-12/+5
Now OMAP GPIO driver prepared for omap_irq_to_gpio() removing. Do it ;) Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Acked-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-27gpio: omap: get rid of GPIO_BIT() macroGrygorii Strashko1-1/+0
Now OMAP GPIO driver prepared for GPIO_BIT() macro removing. Do it ;) Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Acked-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-27gpio: omap: convert gpio irq functions to use GPIO offsetGrygorii Strashko1-33/+34
Convert GPIO IRQ functions to use GPIO offset instead of system GPIO numbers. This allows to drop unneeded conversations between system GPIO <-> GPIO offset which are done in many places and many times. It is safe to do now because: - gpiolib always passes GPIO offset to GPIO controller - OMAP GPIO driver converted to use IRQ domain, so struct irq_data->hwirq contains GPIO offset This is preparation step before removing: #define GPIO_INDEX(bank, gpio) #define GPIO_BIT(bank, gpio) int omap_irq_to_gpio() Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Acked-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-27gpio: omap: drop 'gpio' param from omap_gpio_init_irq()Grygorii Strashko1-7/+5
The 'gpio' parameter isn't needed any more as it duplicates 'offset' parameter, so drop it. Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Acked-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-27gpio: omap: convert debounce functions switch to use gpio offsetGrygorii Strashko1-7/+7
Convert debounce functions to use GPIO offset instead of system GPIO numbers. This allows to drop unneeded conversations between system GPIO <-> GPIO offset which are done in many places and many times. It is safe to do now because: - gpiolib always passes GPIO offset to GPIO controller - OMAP GPIO driver converted to use IRQ domain This is preparation step before removing: #define GPIO_INDEX(bank, gpio) #define GPIO_BIT(bank, gpio) int omap_irq_to_gpio() Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Acked-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-27gpio: omap: simplify omap_set_gpio_dataout_x()Grygorii Strashko1-5/+5
Both functions omap_set_gpio_dataout_reg() and omap_set_gpio_dataout_mask() accept GPIO offset as 'gpio' input parameter, so rename it to 'offset' and drop usage of GPIO_BIT() macro. Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Acked-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-27gpio: omap: convert omap_gpio_is_input() to use gpio offsetGrygorii Strashko1-6/+4
Convert omap_gpio_is_input() to use GPIO offset instead of mask and, in such way, make code simpler and remove few lines of code. Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Acked-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-09gpio: omap: irq_shutdown: remove unnecessary call of gpiochip_unlock_as_irqGrygorii Strashko1-1/+0
GPIOLib core implemnts irqchip->irq_request/release_resources callbacks internally and these callbacks already contain clalls of gpiochip_lock/unlock_as_irq(). Hence, remove unnecessary call of gpiochip_unlock_as_irq() from omap_gpio_irq_shutdown(). Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-26gpio: omap: Fix bad device access with setup_irq()Tony Lindgren1-6/+33
Similar to omap_gpio_irq_type() let's make sure that the GPIO is usable as an interrupt if the platform init code did not call gpio_request(). Otherwise we can get invalid device access after setup_irq(): WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x214/0x340() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access ... [<c05f21e4>] (__irq_svc) from [<c05f1974>] (_raw_spin_unlock_irqrestore+0x34/0x44) [<c05f1974>] (_raw_spin_unlock_irqrestore) from [<c00914a8>] (__setup_irq+0x244/0x530) [<c00914a8>] (__setup_irq) from [<c00917d4>] (setup_irq+0x40/0x8c) [<c00917d4>] (setup_irq) from [<c0039c8c>] (omap_system_dma_probe+0x1d4/0x2b4) [<c0039c8c>] (omap_system_dma_probe) from [<c03b2200>] (platform_drv_probe+0x44/0xa4) ... We can fix this the same way omap_gpio_irq_type() is handling it. Note that the long term solution is to change the gpio-omap driver to handle the banks as separate driver instances. This will allow us to rely on just runtime PM for tracking the bank specific state. Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Javier Martinez Canillas <javier@dowhile0.org> Cc: Kevin Hilman <khilman@kernel.org> Cc: Santosh Shilimkar <ssantosh@kernel.org> Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-12-14Merge tag 'gpio-v3.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpioLinus Torvalds1-1/+1
Pull take two of the GPIO updates: "Same stuff as last time, now with a fixup patch for the previous compile error plus I ran a few extra rounds of compile-testing. This is the bulk of GPIO changes for the v3.19 series: - A new API that allows setting more than one GPIO at the time. This is implemented for the new descriptor-based API only and makes it possible to e.g. toggle a clock and data line at the same time, if the hardware can do this with a single register write. Both consumers and drivers need new calls, and the core will fall back to driving individual lines where needed. Implemented for the MPC8xxx driver initially - Patched the mdio-mux-gpio and the serial mctrl driver that drives modems to use the new multiple-setting API to set several signals simultaneously - Get rid of the global GPIO descriptor array, and instead allocate descriptors dynamically for each GPIO on a certain GPIO chip. This moves us closer to getting rid of the limitation of using the global, static GPIO numberspace - New driver and device tree bindings for 74xx ICs - New driver and device tree bindings for the VF610 Vybrid - Support the RCAR r8a7793 and r8a7794 - Guidelines for GPIO device tree bindings trying to get things a bit more strict with the advent of combined device properties - Suspend/resume support for the MVEBU driver - A slew of minor fixes and improvements" * tag 'gpio-v3.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (33 commits) gpio: mcp23s08: fix up compilation error gpio: pl061: document gpio-ranges property for bindings file gpio: pl061: hook request if gpio-ranges avaiable gpio: mcp23s08: Add option to configure IRQ output polarity as active high gpio: fix deferred probe detection for legacy API serial: mctrl_gpio: use gpiod_set_array function mdio-mux-gpio: Use GPIO descriptor interface and new gpiod_set_array function gpio: remove const modifier from gpiod_get_direction() gpio: remove gpio_descs global array gpio: mxs: implement get_direction callback gpio: em: Use dynamic allocation of GPIOs gpio: Check if base is positive before calling gpio_is_valid() gpio: mcp23s08: Add simple IRQ support for SPI devices gpio: mcp23s08: request a shared interrupt gpio: mcp23s08: Do not free unrequested interrupt gpio: rcar: Add r8a7793 and r8a7794 support gpio-mpc8xxx: add mpc8xxx_gpio_set_multiple function gpiolib: allow simultaneous setting of multiple GPIO outputs gpio: mvebu: add suspend/resume support gpio: gpio-davinci: remove duplicate check on resource ..
2014-12-04gpio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PMRafael J. Wysocki1-4/+4
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks depending on CONFIG_PM_RUNTIME may now be changed to depend on CONFIG_PM. Replace CONFIG_PM_RUNTIME with CONFIG_PM in drivers/gpio/gpio-omap.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Javier Martinez Canillas <javier@dowhile0.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2014-10-28gpio: rename gpio_lock_as_irq to gpiochip_lock_as_irqAlexandre Courbot1-1/+1
This function actually operates on a gpio_chip, so its prefix should reflect that fact for consistency with other functions defined in gpio/driver.h. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-09-23gpio: omap: Fix interrupt namesNishanth Menon1-14/+17
When viewing the /proc/interrupts, there is no information about which GPIO bank a specific gpio interrupt is hooked on to. This is more than a bit irritating as such information can esily be provided back to the user and at times, can be crucial for debug. So, instead of displaying something like: 31: 0 0 GPIO 0 palmas 32: 0 0 GPIO 27 mmc0 Display the following with appropriate device name: 31: 0 0 4ae10000.gpio 0 palmas 32: 0 0 4805d000.gpio 27 mmc0 This requires that we create irq_chip instance specific for each GPIO bank which is trivial to achieve. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Acked-by: Kevin Hilman <khilman@linaro.org> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-09-23gpio: remove remaining users of gpiochip_remove() retvalLinus Walleij1-1/+1
Some drivers accidentally still use the return value from gpiochip_remove(). Get rid of them so we can simplify this function and get rid of the return value. Cc: Abdoulaye Berthe <berthe.ab@gmail.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-07-09gpio: omap: Add an omap prefix to all functionsJavier Martinez Canillas1-131/+137
The GPIO OMAP driver didn't have a consistent naming scheme for all its functions. Some of them had an omap prefix while others didn't. There are many advantages on having a separate namespace for driver functions so let's add an "omap" prefix to all of them. Signed-off-by: Javier Martinez Canillas <jmartinez@softcrates.net> Acked-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-07-09gpio: omap: Remove unneeded includeJavier Martinez Canillas1-1/+0
The <linux/irqchip/chained_irq.h> header is already included when selecting GPIOLIB_IRQCHIP so there is no need to do it in the driver. This is a left over from commit fb655f5 ("gpio: omap: convert driver to use gpiolib irqchip"). Signed-off-by: Javier Martinez Canillas <jmartinez@softcrates.net> Acked-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.