26 Apr, 2016

1 commit

  • 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
    Signed-off-by: Grygorii Strashko
    Acked-by: Tony Lindgren
    Acked-by: Santosh Shilimkar
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     

09 Mar, 2016

1 commit


05 Jan, 2016

1 commit

  • 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
    Cc: Tony Lindgren
    Acked-by: Santosh Shilimkar
    Signed-off-by: Linus Walleij

    Linus Walleij
     

21 Dec, 2015

1 commit


30 Nov, 2015

1 commit

  • 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 : [] lr : [] 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:
    [] (irq_gc_mask_set_bit) from [] (__irq_do_set_handler+0x118/0x15c)
    [] (__irq_do_set_handler) from [] (__irq_set_handler+0x44/0x5c)
    r6:00000000 r5:c00444e8 r4:c185c300
    [] (__irq_set_handler) from [] (irq_set_chip_and_handler_name+0x30/0x34)
    r7:00000050 r6:00000000 r5:c00444e8 r4:00000050
    [] (irq_set_chip_and_handler_name) from [] (gpiochip_irq_map+0x3c/0x8c)
    r7:00000050 r6:00000000 r5:00000050 r4:c1862c64
    [] (gpiochip_irq_map) from [] (irq_domain_associate+0x7c/0x1c4)
    r5:c185c310 r4:c185cb00
    [] (irq_domain_associate) from [] (irq_domain_add_simple+0x98/0xc0)
    r8:c0411bbc r7:c185cb00 r6:00000050 r5:00000010 r4:00000001
    [] (irq_domain_add_simple) from [] (_gpiochip_irqchip_add+0x64/0x10c)
    r7:c1862c64 r6:c0419280 r5:c1862c64 r4:c1854b50
    [] (_gpiochip_irqchip_add) from [] (omap_gpio_probe+0x2fc/0x63c)
    r5:c1854b50 r4:c1862c10
    [] (omap_gpio_probe) from [] (platform_drv_probe+0x2c/0x64)
    r10:00000000 r9:c03e45e8 r8:00000000 r7:c0419294 r6:c0411984 r5:c0419294
    r4:c0411950
    [] (platform_drv_probe) from [] (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
    Fixes: commit d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts")
    Reported-by: Aaro Koskinen
    Signed-off-by: Grygorii Strashko
    Acked-by: Santosh Shilimkar
    Tested-by: Aaro Koskinen
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     

19 Nov, 2015

1 commit

  • 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
    Cc: Rafał Miłecki
    Cc: Richard Purdie
    Cc: Mauro Carvalho Chehab
    Cc: Alek Du
    Cc: Jaroslav Kysela
    Cc: Takashi Iwai
    Acked-by: Dmitry Torokhov
    Acked-by: Greg Kroah-Hartman
    Acked-by: Lee Jones
    Acked-by: Jiri Kosina
    Acked-by: Hans-Christian Egtvedt
    Acked-by: Jacek Anaszewski
    Signed-off-by: Linus Walleij

    Linus Walleij
     

16 Oct, 2015

1 commit

  • 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 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
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     

03 Oct, 2015

1 commit

  • 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
    Tested-by: Austin Schuh
    Signed-off-by: Grygorii Strashko
    Acked-by: Santosh Shilimkar
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     

02 Oct, 2015

1 commit

  • 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: [] __driver_attach+0x54/0xa0
    #1: (&dev->mutex){......}, at: [] __driver_attach+0x60/0xa0
    #2: (class){......}, at: [] __irq_get_desc_lock+0x60/0xa4
    irq event stamp: 1834
    hardirqs last enabled at (1833): [] _raw_spin_unlock_irqrestore+0x88/0x90
    hardirqs last disabled at (1834): [] _raw_spin_lock_irqsave+0x2c/0x64
    softirqs last enabled at (0): [] 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)
    [] (unwind_backtrace) from [] (show_stack+0x20/0x24)
    [] (show_stack) from [] (dump_stack+0x88/0xdc)
    [] (dump_stack) from [] (___might_sleep+0x198/0x2a8)
    [] (___might_sleep) from [] (rt_spin_lock+0x30/0x70)
    [] (rt_spin_lock) from [] (__pm_runtime_resume+0x68/0xa4)
    [] (__pm_runtime_resume) from [] (omap_gpio_irq_type+0x188/0x1d8)
    [] (omap_gpio_irq_type) from [] (__irq_set_trigger+0x68/0x130)
    [] (__irq_set_trigger) from [] (irq_set_irq_type+0x44/0x6c)
    [] (irq_set_irq_type) from [] (irq_create_of_mapping+0x120/0x174)
    [] (irq_create_of_mapping) from [] (of_irq_get+0x48/0x58)
    [] (of_irq_get) from [] (i2c_device_probe+0x54/0x15c)
    [] (i2c_device_probe) from [] (driver_probe_device+0x184/0x2c8)
    [] (driver_probe_device) from [] (__driver_attach+0x9c/0xa0)
    [] (__driver_attach) from [] (bus_for_each_dev+0x7c/0xb0)
    [] (bus_for_each_dev) from [] (driver_attach+0x28/0x30)
    [] (driver_attach) from [] (bus_add_driver+0x154/0x200)
    [] (bus_add_driver) from [] (driver_register+0x88/0x108)
    [] (driver_register) from [] (i2c_register_driver+0x3c/0x90)
    [] (i2c_register_driver) from [] (pcf857x_init+0x18/0x24 [gpio_pcf857x])
    [] (pcf857x_init [gpio_pcf857x]) from [] (do_one_initcall+0x128/0x1e8)
    [] (do_one_initcall) from [] (do_init_module+0x6c/0x1bc)
    [] (do_init_module) from [] (load_module+0x18e8/0x21c4)
    [] (load_module) from [] (SyS_init_module+0xfc/0x158)
    [] (SyS_init_module) from [] (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
    Tested-by: Austin Schuh
    Signed-off-by: Grygorii Strashko
    Acked-by: Santosh Shilimkar
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     

18 Sep, 2015

1 commit

  • 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()
    ...

    Linus Torvalds
     

16 Sep, 2015

1 commit

  • 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
    Cc: Julia Lawall
    Cc: Jiang Liu

    Thomas Gleixner
     

14 Sep, 2015

2 commits

  • 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
    Cc: Kevin Hilman
    Cc: Santosh Shilimkar
    Reviewed-by: Grygorii Strashko
    Signed-off-by: Tony Lindgren
    Signed-off-by: Linus Walleij

    Tony Lindgren
     
  • 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
    Cc: Javier Martinez Canillas
    Cc: Kevin Hilman
    Cc: Santosh Shilimkar
    Acked-by: Santosh Shilimkar
    Signed-off-by: Tony Lindgren
    Signed-off-by: Linus Walleij

    Tony Lindgren
     

26 Aug, 2015

5 commits

  • 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
    Acked-by: Santosh Shilimkar
    Tested-by: Tony Lindgren
    Signed-off-by: Grygorii Strashko
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • 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
    Acked-by: Santosh Shilimkar
    Tested-by: Tony Lindgren
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • 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 and
    Acked-by: Santosh Shilimkar
    Tested-by: Tony Lindgren
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • 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
    Acked-by: Santosh Shilimkar
    Tested-by: Tony Lindgren
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • The bank->chip.irqdomain is uninitialized at the moment when
    irq_domain_remove() is called, so remove this call.

    Signed-off-by: Grygorii Strashko
    Acked-by: Santosh Shilimkar
    Tested-by: Tony Lindgren
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     

13 Aug, 2015

2 commits

  • 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
    Signed-off-by: Linus Walleij

    Axel Lin
     
  • Linux 4.2-rc4

    Linus Walleij
     

27 Jul, 2015

1 commit

  • 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
    Acked-by: Santosh Shilimkar
    Signed-off-by: Sebastian Andrzej Siewior
    Signed-off-by: Linus Walleij

    Sebastian Andrzej Siewior
     

16 Jul, 2015

2 commits

  • 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
    Fixes: cac089f9026e ('gpio: omap: Allow building as a loadable module')
    Signed-off-by: Grygorii Strashko
    Acked-by: Alexandre Courbot
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • 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
    Signed-off-by: Grygorii Strashko
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     

14 Jul, 2015

2 commits


01 Jun, 2015

5 commits

  • 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
    Tested-by: Tony Lindgren
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • 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
    Tested-by: Tony Lindgren
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • 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
    Tested-by: Tony Lindgren
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • 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
    Tested-by: Tony Lindgren
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • 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
    Tested-by: Tony Lindgren
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     

12 May, 2015

1 commit


06 May, 2015

2 commits

  • 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
    Cc: Kevin Hilman
    Cc: Nishanth Menon
    Signed-off-by: Tony Lindgren
    Reviewed-by: Grygorii Strashko
    Acked-by: Santosh Shilimkar
    Reviewed-by: Felipe Balbi
    Signed-off-by: Linus Walleij

    Tony Lindgren
     
  • 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
    Cc: Javier Martinez Canillas
    Cc: Kevin Hilman
    Cc: Nishanth Menon
    Signed-off-by: Tony Lindgren
    Reviewed-by: Grygorii Strashko
    Acked-by: Santosh Shilimkar
    Reviewed-by: Felipe Balbi
    Signed-off-by: Linus Walleij

    Tony Lindgren
     

27 Mar, 2015

7 commits

  • Now OMAP GPIO driver prepared for GPIO_INDEX() macro removing.
    Do It ;)

    Tested-by: Tony Lindgren
    Tested-by: Aaro Koskinen
    Acked-by: Santosh Shilimkar
    Acked-by: Javier Martinez Canillas
    Signed-off-by: Grygorii Strashko
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • Now OMAP GPIO driver prepared for omap_irq_to_gpio() removing.
    Do it ;)

    Tested-by: Tony Lindgren
    Tested-by: Aaro Koskinen
    Acked-by: Santosh Shilimkar
    Acked-by: Javier Martinez Canillas
    Signed-off-by: Grygorii Strashko
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • Now OMAP GPIO driver prepared for GPIO_BIT() macro removing.
    Do it ;)

    Tested-by: Tony Lindgren
    Tested-by: Aaro Koskinen
    Acked-by: Santosh Shilimkar
    Acked-by: Javier Martinez Canillas
    Signed-off-by: Grygorii Strashko
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • 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
    Tested-by: Aaro Koskinen
    Acked-by: Santosh Shilimkar
    Acked-by: Javier Martinez Canillas
    Signed-off-by: Grygorii Strashko
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • The 'gpio' parameter isn't needed any more as it
    duplicates 'offset' parameter, so drop it.

    Tested-by: Tony Lindgren
    Tested-by: Aaro Koskinen
    Acked-by: Santosh Shilimkar
    Acked-by: Javier Martinez Canillas
    Signed-off-by: Grygorii Strashko
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • 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
    Tested-by: Aaro Koskinen
    Acked-by: Santosh Shilimkar
    Acked-by: Javier Martinez Canillas
    Signed-off-by: Grygorii Strashko
    Signed-off-by: Linus Walleij

    Grygorii Strashko
     
  • 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
    Tested-by: Aaro Koskinen
    Acked-by: Santosh Shilimkar
    Acked-by: Javier Martinez Canillas
    Signed-off-by: Grygorii Strashko
    Signed-off-by: Linus Walleij

    Grygorii Strashko