The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.

Since this bypasses the GPIO subsystem we have to ensure that another
driver won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.

This fixes smsc911x ethernet support for tobi and igep OMAP3 boards
and OMAP4 SDP SPI based ethernet that use a GPIO as an interrupt line.

Cc: stable@vger.kernel.org
Acked-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NGeorge Cherian <george.cherian@ti.com>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Tested-by: NLars Poeschel <poeschel@lemonage.de>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NKevin Hilman <khilman@linaro.org>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The GPIO OMAP controller pins can be used as IRQ and GPIO
independently so is necessary to keep track GPIO pins and
IRQ lines usage separately to make sure that the bank will
always be enabled while being used.

Also move gpio_is_input() definition in preparation for the
next patch that setups the controller's irq_chip driver when
a caller requests an interrupt line.

Cc: stable@vger.kernel.org
Acked-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NGeorge Cherian <george.cherian@ti.com>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Tested-by: NLars Poeschel <poeschel@lemonage.de>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NKevin Hilman <khilman@linaro.org>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Replace a comma between expression statements by a semicolon.  This changes
the semantics of the code, but given the current indentation appears to be
what is intended.

A simplified version of the semantic patch that performs this
transformation is as follows: (http://coccinelle.lip6.fr/)

// <smpl>
@r@
expression e1,e2,e;
type T;
identifier i;
@@

 e1
-,
+;
 e2;
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This reverts commit 0e970cec.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This reverts commit b4419e1a.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This reverts commit 949eb1a4.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The OMAP GPIO driver check if the chip has an associated
Device Tree node using the struct gpio_chip of_node member.

But this is only build if CONFIG_OF_GPIO is defined which
leads to the following error when using omap1_defconfig:

linux/drivers/gpio/gpio-omap.c: In function 'omap_gpio_chip_init':
linux/drivers/gpio/gpio-omap.c:1080:17: error: 'struct gpio_chip' has no member named 'of_node'
linux/drivers/gpio/gpio-omap.c: In function 'omap_gpio_irq_map':
linux/drivers/gpio/gpio-omap.c:1116:16: error: 'struct gpio_chip' has no member named 'of_node'
Reported-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
has to be made to initialize the OMAP GPIO bank before a driver
request the IRQ. Otherwise the call to request_irq() fails.

Drives should not be aware of this neither care wether an IRQ line
is a GPIO or not. They should just request the IRQ and this has to
be handled by the irq_chip driver.

With the current OMAP GPIO DT binding, if we define:

    gpio6: gpio@49058000 {
    	   compatible = "ti,omap3-gpio";
	   reg = <0x49058000 0x200>;
	   interrupts = <34>;
	   ti,hwmods = "gpio6";
	   gpio-controller;
	   #gpio-cells = <2>;
	   interrupt-controller;
	   #interrupt-cells = <2>;
    };

	   interrupt-parent = <&gpio6>;
           interrupts = <16 8>;

The GPIO is correctly mapped as an IRQ but a call to gpio_request()
is never made. Since a call to the custom IRQ domain .map function
handler is made for each GPIO used as an IRQ, the GPIO can be setup
and configured as input there automatically.

Changes since v3:
  - Use bank->chip.of_node instead of_have_populated_dt() to check
    DT or legacy boot as suggested by Jean-Christophe PLAGNIOL-VILLARD
  - Add a comment that this is just a temporary solution until and
    that it has to be removed once is handled by the IRQ core.

Changes since v2:
 - Only make the call to gpio_request_one() conditional in the DT
   case as suggested by Grant Likely.

Changes since v1:
  - Split the irq domain mapping function handler and the GPIO
    request in two different patches.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When a GPIO is defined as an interrupt line using Device
Tree, a call to irq_create_of_mapping() is made that calls
irq_create_mapping(). So, is not necessary to do the mapping
for all OMAP GPIO lines and explicitly call irq_create_mapping()
on the driver probe() when booting with Device Tree.

Add a custom IRQ domain .map function handler that will be
called by irq_create_mapping() to map the GPIO lines used as IRQ.
This also allows to execute needed setup code such as configuring
a GPIO as input and enabling the GPIO bank.

Changes since v3:
  - Use bank->chip.of_node instead of_have_populated_dt() to check
    DT or legacy boot as suggested by Jean-Christophe PLAGNIOL-VILLARD

Changes since v2:
  - Unconditionally do the IRQ setup in the .map() function and
    only call irq_create_mapping() in the gpio chip init to avoid
    code duplication as suggested by Grant Likely.

Changes since v1:
  - Split the addition of the .map function handler and the
    automatic gpio request in two different patches.
  - Add GPIO IRQ setup logic to the irq domain mapping function.
  - Only call irq_create_mapping for every GPIO on legacy boot.
  - Only setup a GPIO IRQ on the .map function for DeviceTree boot.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit ede4d7a5 ("gpio/omap: convert gpio irq domain to linear mapping")
converted the OMAP GPIO driver to use a linear mapping for the GPIO IRQ
domain instead of using a legacy mapping. Not using a legacy mapping has
a number of benefits but it requires the platform to support SPARSE_IRQ
which currently is not supported on OMAP1.

So this change caused a regression on OMAP1 platforms [1].

Since this issue is not present on all OMAP2+ platforms, there is no need to
revert the driver to use legacy domain mapping for all the platforms.

[1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89005.htmlSigned-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The bug fix 352a2d5b "gpio/omap: ensure gpio context is initialised"
has caused a new warning for omap1_defconfig:

drivers/gpio/gpio-omap.c:1465:13: warning: 'omap_gpio_init_context' defined but not used [-Wunused-function]
 static void omap_gpio_init_context(struct gpio_bank *p) {}
             ^

The solution is to mark the stub function as 'static inline' so
it gets left out of the build when unused.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit a2797bea (gpio/omap: force restore if context loss is not
detectable) broke gpio support for OMAP when booting with device-tree
because a restore of the gpio context being performed without ever
initialising the gpio context. In other words, the context restored was
bad.

This problem could also occur in the non device-tree case, however, it
is much less likely because when booting without device-tree we can
detect context loss via a platform specific API and so context restore
is performed less often.

Nevertheless we should ensure that the gpio context is initialised
on the first pm-runtime resume for gpio banks that could lose their
state regardless of whether we are booting with device-tree or not.

The context loss count was being initialised on the first pm-runtime
suspend following a resume, by populating the get_count_loss_count()
function pointer after the first pm-runtime resume. To make the code
more readable and logical, initialise the context loss count on the
first pm-runtime resume if the context is not yet valid.
Reported-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When booting with device-tree the function pointer for detecting context
loss is not populated. Ideally, the pm_runtime framework should be
enhanced to allow a means for reporting context/state loss and we could
avoid populating such function pointers altogether. In the interim until
a generic non-device specific solution is in place, force a restore of
the gpio bank when enabling the gpio controller.

Adds a new device-tree property for the OMAP GPIO controller to indicate
if the GPIO controller is located in a power-domain that never loses
power and hence will always maintain its logic state.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The OMAP GPIO interrupt service routine is checking each bit in the
GPIO interrupt status register to see which bits are set. It is not
efficient to check every bit especially if only a few bits are set.
Therefore, instead of checking every bit use the __ffs() function,
which returns the location of the first set bit, to find all the set
bits.

This optimisation was suggested-by and developed in collaboration
with Felipe Balbi.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

68942edb (gpio/omap: fix wakeups
on level-triggered GPIOs) already restores the fallingdetect and
risingdetect contexts in *_runtime_resume(). These registers were
modified in *_runtime_suspend() to include even those configured
as level-triggered since only edge-triggered gpios can generate
wakeup events. Therefore, the old context restores of the same
registers present later in the code is not needed any more.
Remove them.
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently the IRQ domain is not freed once allocated, in the case where
omap_gpio_probe() fails. Therefore, ensure we free the domain if the
probe does fail. Furthermore, the local variable "ret" is not needed
and so remove this.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fix :
 gpio/gpio-omap.c:697: ERROR: space required before the open parenthesis '('
Signed-off-by: NLaurent Navet <laurent.navet@gmail.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

These functions have been introduced by commit 10a8c383 (irq: introduce
entry and exit functions for chained handlers) in asm/mach/irq.h. This
patch moves them to linux/irqchip/chained_irq.h so that generic irqchip
drivers do not rely on architecture specific header files.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Tested-by: NMarc Zyngier <marc.zyngier@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Rob Herring <rob.herring@calxeda.com>

For OMAP devices, if a gpio is being used as an interrupt source but has
not been requested by calling gpio_request(), a call to request_irq()
may cause the kernel hang because the gpio bank may be disabled and
hence the register access will fail. To prevent such hangs, test for
this case and warn if this is detected.
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NJavier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Currently the OMAP GPIO driver uses a legacy mapping for the GPIO IRQ
domain. This is not necessary because we do not need to assign a
specific interrupt number to the GPIO IRQ domain. Therefore, convert
the OMAP GPIO driver to use a linear mapping instead.

Please note that this also allows to simplify the logic in the OMAP
gpio_irq_handler() routine, by using irq_find_mapping() to obtain the
virtual irq number from the GPIO bank and bank index.
Reported-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NJavier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

  'const static ' is not a common order, better to use 'static const' instead.

building:
  make EXTRA_CFLAGS=-W ARCH=arm

  drivers/gpio/gpio-omap.c:1479:
    warning: 'static' is not at beginning of declaration
  drivers/gpio/gpio-omap.c:1485:
    warning: 'static' is not at beginning of declaration
  drivers/gpio/gpio-omap.c:1491:
    warning: 'static' is not at beginning of declaration
Signed-off-by: NChen Gang <gang.chen@asianux.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This change was originally titled "gpio/omap: fix off-mode bug: clear debounce
clock enable mask on free/reset". The title has been updated slightly to
reflect (what should be) the final fix.

When a GPIO is freed or shutdown, we need to ensure that any debounce settings
are cleared and if the GPIO is the only GPIO in the bank that is currently
using debounce, then disable the debounce clock as well to save power.

Currently, the debounce settings are not cleared on a GPIO free or shutdown and
so during a context restore on subsequent off-mode transition, the previous
debounce values are restored from the shadow copies (bank->context.debounce*)
leading to mismatch state between driver state and hardware state.

This was discovered when board code was doing

  gpio_request_one()
  gpio_set_debounce()
  gpio_free()

which was leaving the GPIO debounce settings in a confused state.  If that GPIO
bank is subsequently used with off-mode enabled, bogus state would be restored,
leaving GPIO debounce enabled which then prevented the CORE powerdomain from
transitioning.

To fix this, introduce a new function called _clear_gpio_debounce() to clear
any debounce settings when the GPIO is freed or shutdown. If this GPIO is the
last debounce-enabled GPIO in the bank, the debounce will also be cut.

Please note that we cannot use _gpio_dbck_disable() to disable the debounce
clock because this has been specifically created for the gpio suspend path
and is intended to shutdown the debounce clock while debounce is enabled.

Special thanks to Kevin Hilman for root causing the bug. This fix is a
collaborative effort with inputs from Kevin Hilman, Grazvydas Ignotas and
Santosh Shilimkar.

Testing:
- This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio,
  enabling debounce and then freeing the gpio and checking the register
  contents, the saved register context and the debounce clock state.
- Kevin Hilman tested on 37xx/EVM board which configures GPIO debounce for the
  ads7846 touchscreen in its board file using the above sequence, and so was
  failing off-mode tests in dynamic idle. Verified that off-mode tests are
  passing with this patch.

V5 changes:
- Corrected author
Reported-by: NPaul Walmsley <paul@pwsan.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

A pointer to "pdev->dev" is already stored in "dev", so use it in
devm_kzalloc.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Acked-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This way we can remove includes of plat/gpio.h which won't work
with the single zImage support.

Note that we also remove the cpu_class_is_omap2() check
in gpio-omap.c as the drivers should not call it as we need to
make it local to arch/arm/mach-omap2 for single zImage support.

While at it, arrange the related includes in the standard way.

Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-mtd@lists.infradead.org
Cc: alsa-devel@alsa-project.org
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Since of_device_id.data is declared as a pointer to const data a few
more consts can be added in this driver.
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

This prepares *of_device_id.data becoming const. Without this change
the following warning would occur:

	drivers/gpio/gpio-omap.c: In function 'omap_gpio_probe':
	drivers/gpio/gpio-omap.c:1060: warning: assignment discards qualifiers from pointer target type
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Since the bank->dbck initialization in a one time operation there
is no need to keep this within gpio_debounce(). Therefore, moving
clk_get(bank->dbck) to omap_gpio_mod_init(). Since the value of
bank->dbck would be NULL at the beginning, this check has been
removed.
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Reported-by: NPaul Walmsley <paul@pwsan.com>
Reviewed-by: NJon Hunter <jon-hunter@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently the gpio _runtime_resume/suspend functions are calling the
get_context_loss_count() platform function if the function is populated for
a gpio bank. This function is used to determine if the gpio bank logic state
needs to be restored due to a power transition. This function will be populated
for all banks, but it should only be called for banks that have the
"loses_context" variable set. It is pointless to call this if loses_context is
false as we know the context will never be lost and will not need restoring.

For all OMAP2+ devices gpio bank-0 is in an always-on power domain and so will
never lose context. We found that the get_context_loss_count() was being called
for bank-0 during the probe and returning 1 instead of 0 indicating that the
context had been lost. This was causing the context restore function to be
called at probe time for this bank and because the context had never been saved,
was restoring an invalid state. This ultimately resulted in a crash [1].

This issue is a regression that was exposed by commit 1b128703 (gpio/omap: fix
missing check in *_runtime_suspend()).

There are multiple bugs here that need to be addressed ...

1. Why the always-on power domain returns a context loss count of 1? This needs
   to be fixed in the power domain code [2]. However, the gpio driver should not
   assume the loss count is 0 to begin with.
2. The omap gpio driver should never be calling get_context_loss_count for a
   gpio bank in a always-on domain. This is pointless and adds unneccessary
   overhead.
3. The OMAP gpio driver assumes that the initial power domain context loss count
   will be 0 at the time the gpio driver is probed. However, it could be
   possible that this is not the case and an invalid context restore could be
   performed during the probe. To avoid this only populate the
   get_context_loss_count() function pointer after the initial call to
   pm_runtime_get() has occurred. This will ensure that the first
   pm_runtime_put() initialised the loss count correctly.

This patch addresses issues 2 and 3 above.

[1] http://marc.info/?l=linux-omap&m=134065775323775&w=2
[2] http://marc.info/?l=linux-omap&m=134100413303810&w=2

Cc: Kevin Hilman <khilman@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Linus Walleij <linus.walleij@stericsson.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Franky Lin <frankyl@broadcom.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: NeilBrown <neilb@suse.de>
Reported-by: NFranky Lin <frankyl@broadcom.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NFranky Lin <frankyl@broadcom.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Tested-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

It seems that currently GPIO module is not working correctly during idle
when debounce is enabled - the system almost never responds to button
presses (observed on OMAP3530 ES2.1 and OMAP3630 ES1.2 pandora boards).
Even though wakeups are probably working, it seems that the GPIO module
itself is unable to detect input events and generate interrupts.
OMAP35x TRM also states that:
  "If the debounce clock is inactive, the debounce cell gates all
   input signals and thus cannot be used."

So whenever we are disabling debounce clocks (for PM or other reasons),
be sure the module's debounce feature is disabled too.

Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

commit 1b128703 (gpio/omap: fix missing check in *_runtime_suspend())
broke wakeups on level-triggered GPIOs by adding the enabled
non-wakeup GPIO check before the workaround that enables wakeups
on level-triggered IRQs, effectively disabling that workaround.

To fix, move the enabled non-wakeup GPIO check after the
level-triggered IRQ workaround.
Reported-by: NTony Lindgren <tony@atomide.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Tested-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

The fix in commit 1b128703 (gpio/omap: fix missing check in
*_runtime_suspend()) exposed another bug in the context restore path.

Currently, the per-bank context restore happens whenever the context
loss count is different in runtime suspend and runtime resume *and*
whenever the per-bank contex_loss_count == 0:

	if (context_lost_cnt_after != bank->context_loss_count ||
					!context_lost_cnt_after) {
		omap_gpio_restore_context(bank);

Restoring context when the context_lost_cnt_after == 0 is clearly
wrong, since this will be true until the first off-mode transition
(which could be never, if off-mode is never enabled.)  This check
causes the context to be restored on *every* runtime PM transition.

Before commit 1b128703 (gpio/omap: fix missing check in
*_runtime_suspend()), this code was never executed in non-OFF mode, so
there were never spurious context restores happening.  After that
change though, spurious context restores could happen.

To fix, simply remove the !context_lost_cnt_after check. It is not
needed.

This bug was found when noticing that the smc911x NIC on 3530/Overo
was not working, and git bisect tracked it down to this patch.  It
seems that the spurious context restore was causing the smsc911x to
not be properly probed on this platform.
Tested-by: NTony Lindgren <tony@atomide.com>
Acked-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

We do checking for bank->enabled_non_wakeup_gpios in order
to skip redundant operations. Somehow, the check got missed
while doing the cleanup series.

Just to make sure that we do context restore correctly in
*_runtime_resume(), the bank->workaround_enabled check is
moved after context restore. Otherwise, it would prevent
context restore when bank->enabled_non_wakeup_gpios is 0.

Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Add register offsets for GPIO_IRQSTATUS_RAW_0, GPIO_IRQSTATUS_RAW_0
which are present on OMAP4+ processors. Now we can distinguish
conditions applicable to OMAP4,5 and those specific to OMAP24xx
and OMAP3xxx.

Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Both omap_gpio_suspend() and omap_gpio_resume() does programming
of wakeup_en register.
_gpio_rmw(base, bank->regs->wkup_en, 0xffffffff, 0);
_gpio_rmw(base, bank->regs->wkup_en, bank->context.wake_en, 1);

This is redundant in omap_gpio_suspend() because wakeup_en
register automatically gets initialized in _set_gpio_wakeup()
and set_gpio_trigger() while being called either from
chip.irq_set_wake() or chip.irq_set_type().

This is also redundant in omap_gpio_resume() because wakeup_en
register is programmed in omap_gpio_restore_context() called
which is called from runtime resume callback.

Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

commit 672e302e (ARM: OMAP: use edge/level handlers from generic IRQ
framework) removed retrigger support in favor of using generic IRQ
framework.  This patch cleans up some unused remnants of that removal.

Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

There is no more need to have saved_wakeup because bank->context.wake_en
already holds that value. So getting rid of read/write operation associated
with this field.

Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Since we already have bank->context.wake_en to keep track
of gpios which are wakeup enabled, there is no need to have
this field any more.

Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Since we already have context.fallingdetect and context.risingdetect
there is no more need to have these additional fields. Also, getting
rid of extra reads associated with them.

Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>