linux-toradex.git/drivers/gpio, branch v3.10.19

gpio/lynxpoint: check if the interrupt is enabled in IRQ handler

2013-11-04T12:31:06+00:00

commit 03d152d5582abc8a1c19cb107164c3724bbd4be4 upstream.

Checking LP_INT_STAT is not enough in the interrupt handler because its
contents get updated regardless of whether the pin has interrupt enabled or
not. This causes the driver to loop forever for GPIOs that are pulled up.

Fix this by checking the interrupt enable bit for the pin as well.

Signed-off-by: Mika Westerberg 
Acked-by: Mathias Nyman 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio/omap: auto-setup a GPIO when used as an IRQ

2013-10-13T23:08:31+00:00

commit fac7fa162a19100298d5d91359960037dc5bfca9 upstream.

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.

Acked-by: Stephen Warren 
Tested-by: George Cherian 
Tested-by: Aaro Koskinen 
Tested-by: Lars Poeschel 
Reviewed-by: Kevin Hilman 
Tested-by: Kevin Hilman 
Acked-by: Santosh Shilimkar 
Acked-by: Tony Lindgren 
Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio/omap: maintain GPIO and IRQ usage separately

2013-10-13T23:08:31+00:00

commit fa365e4d729065b5e85165df3dc9699ed47489cc upstream.

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.

Acked-by: Stephen Warren 
Tested-by: George Cherian 
Tested-by: Aaro Koskinen 
Tested-by: Lars Poeschel 
Reviewed-by: Kevin Hilman 
Tested-by: Kevin Hilman 
Acked-by: Santosh Shilimkar 
Acked-by: Tony Lindgren 
Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

gpio/omap: don't use linear domain mapping for OMAP1

2013-06-26T06:13:40+00:00

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.html

Signed-off-by: Javier Martinez Canillas 
Tested-by: Aaro Koskinen 
Signed-off-by: Tony Lindgren

Merge tag 'gpio-fixes-v3.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio

2013-05-24T01:24:10+00:00

Pull GPIO fixes from Linus Walleij:
 - An OMAP fix that makes ethernet work again.
 - Fix for build problem when building the MCP23S08 driver as module.
 - IRQ conflicts in the Langwell driver.
 - Fix IRQ coherency issues in the MXS driver.
 - Return correct errorcode on errorpath when removing GPIO chips.

* tag 'gpio-fixes-v3.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio: Don't override the error code in probe error handling
  gpio: mxs: Use set and clear capabilities of the gpio controller
  gpio-langwell: fix irq conflicts when DT is not used
  gpio: mcp23s08: Fix build error when CONFIG_SPI_MASTER=y && CONFIG_I2C=m
  gpio/omap: ensure gpio context is initialised

gpio: Don't override the error code in probe error handling

2013-05-20T18:27:30+00:00

Otherwise, we return 0 in probe error paths when gpiochip_remove() returns 0.
Also show error message if gpiochip_remove() fails.

Signed-off-by: Axel Lin 
Cc: Tomoya MORINAGA 
Cc: Denis Turischev 
Cc: Lars Poeschel 
Signed-off-by: Linus Walleij

gpio: mxs: Use set and clear capabilities of the gpio controller

2013-05-20T18:14:43+00:00

The current driver doesn't use the set and clear registers found on the
mxs gpio controller.

This leads the generic gpio controller to be using some internal value
to avoid looking up the value stored in the registers, making it behave
pretty much like a cache.

This raises some coherency problem when a gpio is not modified by the
gpio controller, while it can easily be fixed by using the set and clear
registers.

Signed-off-by: Maxime Ripard 
Acked-by: Shawn Guo 
Signed-off-by: Linus Walleij

gpio-langwell: fix irq conflicts when DT is not used

2013-05-20T18:10:22+00:00

When DT is not used IOAPIC does not register irq domain. As result
IOAPIC won't care about gpio-langwell's virq and may cause conflict if
an irq number is equal to gpio-langwell's virq mapped beforehand.

This patch tells gpio_langwell to not ignore irq_base if != 0 and
preferably use it to avoid the conflict.

If DT is used, irq_base can safely be 0.

Signed-off-by: David Cohen 
Acked-by: Mika Westerberg 
Signed-off-by: Linus Walleij

gpio: mcp23s08: Fix build error when CONFIG_SPI_MASTER=y && CONFIG_I2C=m

2013-05-20T17:16:16+00:00

This patch fixes below build error when CONFIG_SPI_MASTER=y && CONFIG_I2C=m &&
CONFIG_GPIO_MCP23S08=y.

  LD      init/built-in.o
drivers/built-in.o: In function `mcp23017_write':
clkdev.c:(.text+0x1e14): undefined reference to `i2c_smbus_write_word_data'
drivers/built-in.o: In function `mcp23017_read':
clkdev.c:(.text+0x1e24): undefined reference to `i2c_smbus_read_word_data'
drivers/built-in.o: In function `mcp23008_write':
clkdev.c:(.text+0x1e8c): undefined reference to `i2c_smbus_write_byte_data'
drivers/built-in.o: In function `mcp23008_read':
clkdev.c:(.text+0x1e98): undefined reference to `i2c_smbus_read_byte_data'
drivers/built-in.o: In function `mcp23008_read_regs':
clkdev.c:(.text+0x1ed0): undefined reference to `i2c_smbus_read_byte_data'
drivers/built-in.o: In function `mcp23s08_init':
clkdev.c:(.init.text+0x30): undefined reference to `i2c_register_driver'
drivers/built-in.o: In function `mcp23s08_exit':
clkdev.c:(.exit.text+0x30): undefined reference to `i2c_del_driver'
make: *** [vmlinux] Error 1

When CONFIG_I2C=m, meaning we can't build the drivers in with I2C support.
Thus don't allow the drivers to be compiled as built-in when CONFIG_I2C=m.

The real fix though is to break the driver apart into a SPI part, an I2C part
and a common part. But that's something for 3.11 while this is something for
3.10/stable.

Signed-off-by: Axel Lin 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Linus Walleij

drivers/gpio: don't check resource with devm_ioremap_resource

2013-05-18T09:55:19+00:00

devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.

Signed-off-by: Wolfram Sang 
Acked-by: Stephen Warren