linux/drivers/gpio, branch v3.5

gpio/gpio-tps65910: gpio_chip.of_node referenced without CONFIG_OF_GPIO defined

2012-07-10T20:53:31Z

commit 626f9914 added code to initialize gpio_chip.of_node, but if CONFIG_OF_GPIO is not defined gps-tps65910 fails to build with an error complaining gpio_chip has no member of_node. I ran into this while doing a allyesconfig build on linux-next. Signed-off-by: Gerard Snitselaar Signed-off-by: Linus Walleij

Merge branch 'kevin' into fixes

2012-07-09T18:02:28Z

gpio: tps65910: initialize of_node of gpio_chip

2012-07-05T13:44:22Z

Initialize the gpio chip's of_node to the device's node to work with DT based system. Signed-off-by: Laxman Dewangan Signed-off-by: Linus Walleij

gpio/mxc: make irqs work for fsl,imx21-gpio devices

2012-07-05T13:40:35Z

The chained handler was set for the platform device with id == 0. When the gpio devices are instantiated by a device tree, all have id == -1 and so the handler was unset resulting in unusable gpio irqs on i.MX21 and i.MX27 (when using oftree). Acked-by: Shawn Guo Cc: Grant Likely Signed-off-by: Uwe Kleine-König Signed-off-by: Linus Walleij

gpio: export devm_gpio_request_one

2012-07-05T12:49:13Z

Without this, modules can't use this API, leading to build failures. Signed-off-by: Stephen Warren Signed-off-by: Linus Walleij

gpiolib: wm8994: Pay attention to the value set when enabling as output

2012-07-05T12:49:10Z

Not paying attention to the value being set is a bad thing because it means that we'll not set the hardware up to reflect what was requested. Not setting the hardware up to reflect what was requested means that the caller won't get the results they wanted. Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij

gpio/msm_v1: CONFIG_GPIO_MSM_V1 is only available on three SoCs

2012-07-05T12:48:59Z

The feature GPIO_MSM_V1 is only available on three SoCs. On all other MSM SoCs the INT_GPIO_GROUP{1,2} is undeclared, but Kconfig does allow such configurations. Therefore the produced configuration is valid, but does not compile. The problem is fixed by adding the missing Kconfig constraints. drivers/gpio/gpio-msm-v1.c: In function âmsm_init_gpioâ: drivers/gpio/gpio-msm-v1.c:629:26: error: 'INT_GPIO_GROUP1' undeclared drivers/gpio/gpio-msm-v1.c:630:26: error: 'INT_GPIO_GROUP2' undeclared Signed-off-by: Christian Dietrich Signed-off-by: Linus Walleij

gpio-sta2x11: don't use pdata if null

2012-07-05T12:48:49Z

If there is no platform data available, the driver shouldn't use the pointer or it will oops. Since things will mostly work nonetheless, (the BIOS may have set up the pins properly), I'd better not fail the probe even in this case. Signed-off-by: Alessandro Rubini Acked-by: Giancarlo Asnaghi Signed-off-by: Linus Walleij

gpio/omap: fix invalid context restore of gpio bank-0

2012-07-03T16:41:39Z

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 1b1287032 (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 Cc: Grant Likely Cc: Linus Walleij Cc: Tarun Kanti DebBarma Cc: Franky Lin Cc: Santosh Shilimkar Cc: NeilBrown Reported-by: Franky Lin Reviewed-by: Santosh Shilimkar Tested-by: Franky Lin Acked-by: Kevin Hilman Tested-by: NeilBrown Signed-off-by: Jon Hunter Signed-off-by: Kevin Hilman

gpio/omap: fix irq loss while in idle with debounce on

2012-06-27T02:08:49Z

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 Signed-off-by: Grazvydas Ignotas Signed-off-by: Kevin Hilman