linux-toradex.git/drivers/gpio/gpio-omap.c, branch v3.4.4

gpio/omap: fix incorrect initialization of omap_gpio_mod_init

2012-05-10T14:16:15+00:00

Initialization of irqenable, irqstatus registers is the common
operation done in this function for all OMAP platforms, viz. OMAP1,
OMAP2+. The latter _gpio_rmw()'s which supposedly got introduced
wrongly to take care of OMAP2+ platforms were overwriting initially
programmed OMAP1 value breaking functionality on OMAP1.
Somehow incorrect assumption was made that each _gpio_rmw()'s were
mutually exclusive. On close observation it is found that the first
_gpio_rmw() which is supposedly done to take care of OMAP1 platform
is generic enough and takes care of OMAP2+ platform as well.
Therefore remove the latter _gpio_rmw() to irqenable as they are
redundant now.

Writing to ctrl and debounce_en registers for OMAP2+ platforms are
modified to match the original(pre-cleanup) code where the registers
are initialized with 0. In the cleanup series since we are using
_gpio_rmw(reg, 0, 1), instead of __raw_writel(), we are just reading
and writing the same values to ctrl and debounce_en. This is not an
issue for debounce_en register because it has 0x0 as the default value.
But in the case of ctrl register the default value is 0x2 (GATINGRATIO
 = 0x1) so that we end up writing 0x2 instead of intended 0 value.
Therefore changing back to __raw_writel() as this is sufficient for
this case besides simpler to understand.

Also, change irqstatus initalization logic that avoids comparison
with bool, besides making it fit in a single line.

Cc: stable@vger.kernel.org
Cc: Tony Lindgren 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
Cc: Grant Likely 
Reported-by: Janusz Krzysztofik 
Tested-by: Janusz Krzysztofik 
Signed-off-by: Tarun Kanti DebBarma 
Signed-off-by: Kevin Hilman

gpio/omap: fix redundant decoding of gpio offset

2012-03-21T04:51:24+00:00

In gpio_get(), _get_gpio_datain() and _get_gpio_dataout() get rid of
un-necessary operation to compute gpio mask. The gpio offset passed
to gpio_get() is sufficient to do that.

Here is Russell's original comment:
Can someone explain to me this:

static int _get_gpio_datain(struct gpio_bank *bank, int gpio)
{
       void __iomem *reg = bank->base + bank->regs->datain;

       return (__raw_readl(reg) & GPIO_BIT(bank, gpio)) != 0;
}

static int gpio_get(struct gpio_chip *chip, unsigned offset)
{
       struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
       void __iomem *reg = bank->base;
       int gpio = chip->base + offset;
       u32 mask = GPIO_BIT(bank, gpio);

       if (gpio_is_input(bank, mask))
               return _get_gpio_datain(bank, gpio);
       else
               return _get_gpio_dataout(bank, gpio);
}

Given that bank->width on OMAP is either 32 or 16, and GPIO numbers for
any GPIO chip are always aligned to 32 or 16, why does this code bother
adding the chips base gpio number and then modulo the width?

Surely this means if - for argument sake - you registered a GPIO chip
with 8 lines followed by one with 16 lines, GPIO0..7 would be chip 0
bit 0..7, GPIO8..15 would be chip 1 bit 8..15, GPIO16..23 would be
chip 1 bit 0..7.

However, if you registered a GPIO chip with 16 lines first, it would
mean GPIO0..15 would be chip 0 bit 0..15, and GPIO16..31 would be
chip 1 bit 0..15.

Surely this kind of behaviour is not intended?

Is there a reason why the bitmask can't just be (1 << offset) where
offset is passed into these functions as GPIO number - chip->base ?

Reported-by: Russell King - ARM Linux 
Signed-off-by: Tarun Kanti DebBarma 
Reviewed-by: Santosh Shilimkar 
Reviewed-by: Kevin Hilman 
Signed-off-by: Kevin Hilman

gpio/omap: fix incorrect update to context.irqenable1

2012-03-21T04:48:54+00:00

In _enable_gpio_irqbank() when bank->regs->set_irqenable is TRUE,
gpio_mask can be directly set by writing to set_irqenable register
without overwriting current value. In order to ensure the same is
stored in context.irqenable1, we must avoid overwriting it with
gpio_mask at the end of the function. Instead, update irqenable1
appropriately by OR'ing with gpio_mask.
For the case where bank->regs->set_irqenable is FALSE, irqenable1
can be directly overwritten with 'l' which holds correct computed
value.
        if (bank->regs->set_irqenable) {
                reg += bank->regs->set_irqenable;
                l = gpio_mask;
        } else {
                reg += bank->regs->irqenable;
                l = __raw_readl(reg);
                if (bank->regs->irqenable_inv)
                        l &= ~gpio_mask;
                else
                        l |= gpio_mask;
        }

Make similar change for _disable_gpio_irqbank().

Signed-off-by: Tarun Kanti DebBarma 
Reviewed-by: Santosh Shilimkar 
Reviewed-by: Kevin Hilman 
Signed-off-by: Kevin Hilman

gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_*

2012-03-20T10:02:46+00:00

In omap_gpio_runtime_suspend/resume() the context save/restore should
be independent of bank->enabled_non_wakeup_gpios. This was preventing
context restore of GPIO lines which are not wakeup enabled.

Reported-by: Govindraj Raja 
Signed-off-by: Tarun Kanti DebBarma 
Reviewed-by: Santosh Shilimkar 
Reviewed-by: Kevin Hilman 
Signed-off-by: Kevin Hilman

gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg

2012-03-20T09:59:52+00:00

There are two functions, _set_gpio_dataout_reg() and _set_gpio_dataout_mask()
which writes to dataout register and the dataout context must be saved.
It is missing in the first function, _set_gpio_dataout_reg(). Fix this.

Signed-off-by: Tarun Kanti DebBarma 
Reviewed-by: Santosh Shilimkar 
Reviewed-by: Kevin Hilman 
Signed-off-by: Kevin Hilman

gpio/omap: fix _set_gpio_irqenable implementation

2012-03-20T09:59:09+00:00

This function should be capable of both enabling and disabling interrupts
based upon the *enable* parameter. Right now the function only enables
the interrupt and *enable* is not used at all. So add the interrupt
disable capability also using the parameter.

Signed-off-by: Tarun Kanti DebBarma 
Reviewed-by: Santosh Shilimkar 
Acked-by: Felipe Balbi 
Reviewed-by: Kevin Hilman 
Signed-off-by: Kevin Hilman

gpio/omap: fix trigger type to unsigned

2012-03-20T09:59:04+00:00

The GPIO trigger parameter is of type unsigned.
enum {
        IRQ_TYPE_NONE           = 0x00000000,
        IRQ_TYPE_EDGE_RISING    = 0x00000001,
        IRQ_TYPE_EDGE_FALLING   = 0x00000002,
        IRQ_TYPE_EDGE_BOTH      = (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING),
        IRQ_TYPE_LEVEL_HIGH     = 0x00000004,
        IRQ_TYPE_LEVEL_LOW      = 0x00000008,
        IRQ_TYPE_LEVEL_MASK     = (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH),
        IRQ_TYPE_SENSE_MASK     = 0x0000000f,

        IRQ_TYPE_PROBE          = 0x00000010,
...
};
Even though gpio_irq_type(struct irq_data *d, unsigned type) has the right type
of parameter, the subsequent called functions set_gpio_triggering() and
set_gpio_trigger() wrongly makes it signed integer. Fix this.

Signed-off-by: Tarun Kanti DebBarma 
Reviewed-by: Santosh Shilimkar 
Acked-by: Felipe Balbi 
Reviewed-by: Kevin Hilman 
Signed-off-by: Kevin Hilman

gpio/omap: fix wakeup_en register update in _set_gpio_wakeup()

2012-03-20T09:58:58+00:00

There are two ways through which wakeup_en register can be programmed
using gpiolib APIs as shown below. It is seen that in the second case
in _set_gpio_wakeup(), even though bank->suspend_wakeup is updated
correctly, its value is not programmed in wakeup_en register. Fix this.

irq_set_type()->gpio_irq_type()->_set_gpio_triggering()->set_gpio_trigger()
irq_set_wake()->gpio_wake_enable()->_set_gpio_wakeup()

Signed-off-by: Tarun Kanti DebBarma 
Reviewed-by: Kevin Hilman 
Signed-off-by: Kevin Hilman

gpio/omap: Fix section warning for omap_mpuio_alloc_gc()

2012-03-12T17:44:46+00:00

Make omap_mpuio_alloc_gc() __devinit as omap_gpio_chip_init()
is __devinit. Otherwise we get:

WARNING: vmlinux.o(.devinit.text+0xa10): Section mismatch in reference
from the function omap_gpio_chip_init() to the function .init.text:omap_mpuio_alloc_gc()
The function __devinit omap_gpio_chip_init() references
a function __init omap_mpuio_alloc_gc().
If omap_mpuio_alloc_gc is only used by omap_gpio_chip_init then
annotate omap_mpuio_alloc_gc with a matching annotation.

Signed-off-by: Tony Lindgren 
Acked-by: Kevin Hilman 
Signed-off-by: Grant Likely

gpio/omap: fix wakeups on level-triggered GPIOs

2012-03-12T16:16:11+00:00

While both level- and edge-triggered GPIOs are capable of generating
interrupts, only edge-triggered GPIOs are capable of generating a
module-level wakeup to the PRCM (c.f. 34xx NDA TRM section 25.5.3.2.)

In order to ensure that devices using level-triggered GPIOs as
interrupts can also cause wakeups (e.g. from idle), this patch enables
edge-triggering for wakeup-enabled, level-triggered GPIOs when a GPIO
bank is runtime-suspended (which also happens during idle.)

This fixes a problem found in GPMC-connected network cards with GPIO
interrupts (e.g. smsc911x on Zoom3, Overo, ...) where network booting
with NFSroot was very slow since the GPIO IRQs used by the NIC were
not generating PRCM wakeups, and thus not waking the system from idle.
NOTE: until v3.3, this boot-time problem was somewhat masked because
the UART init prevented WFI during boot until the full serial driver
was available.  Preventing WFI allowed regular GPIO interrupts to fire
and this problem was not seen.  After the UART runtime PM cleanups, we
no longer avoid WFI during boot, so GPIO IRQs that were not causing
wakeups resulted in very slow IRQ response times.

Tested on platforms using level-triggered GPIOs for network IRQs using
the SMSC911x NIC: 3530/Overo and 3630/Zoom3.

Reported-by: Tony Lindgren 
Tested-by: Tarun Kanti DebBarma 
Tested-by: Tony Lindgren 
Signed-off-by: Kevin Hilman 
Signed-off-by: Grant Likely