I am reasonably new to OMAP Linux so feel free to point me to the
correct mailing list/documentation...
Is it possible to use cpuidle for OMAP3530 when using GPIO with
debouncing enabled?
Some background:
I have an LogicPD SOM-LV 3530 evaluation kit. This has an OMAP3530
connected to a touchscreen controller (tsc2004) via GPIO153.
This GPIO requires debouncing:
omap_set_gpio_debounce(153, 1);
omap_set_gpio_debounce_time(153, 0xa);
This GPIO is also set as a wake source (as described in the comment in
arch/arm/plat-omap/gpio.c:gpio_wake_enable()):
enable_irq_wake(OMAP_GPIO_IRQ(153));
When using the PM-branch (the latest copy as of 17-Dec-09) I notice that
this can cause problems if cpuidle is enabled.
According to my understanding the following is happening:
- When cpuidle is enabled the kernel attempts to idle.
- This causes the OMAP3530 to attempt to enter PWRDM_POWER_RET.
- This causes the GPIO driver to disable the debounce clock (otherwise
per_pwrdm cannot enter retention).
- The system enters retention.
- Some time later the GPIO is toggled by a touch on the screen and the
system wakes, but this GPIO is not debounced (as the debounce clock
is not yet running).
This is a problem as I then get false "clicks" on the touchscreen. This
happens for *every* click because as soon as processing of one click has
finished cpuidle places the chip back in to retention.
This is less of a problem if I do not use cpuidle, and only enter
retention when I choose (echo "mem" > /sys/power/state). I still get
false clicks when waking but can mitigate this as I know they will
happen.
So, in general:
- Is it not possible to have a GPIO which requires debouncing as
a wake source?
- Are hardware debounced GPIOs generally a bad idea when using cpuidle?
- And a more general question, does the kernel provide features to
debounce a GPIO in software (rather than using the hardware)?
Cheers,
Joe Woodward
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
