We are using Colibri V50 in Linux environment (version 2.6) on a Iris carrier board . We will soon migrate to a custom carrier board. We would like to know if pin (PTB10/ SODIMM45) could be configured as both a GPIO and also a wake source?
Sorry I meant PTB 19 / SODIMM 45 in my question above
By default SODIMM PIN 45 is used as GPIO for wake-up. Since it is configured to be used as wake-up GPIO one cannot access it via sysfs GPIO.
Are you saying that we cannot use any other pin except SODIMM pin 45 for wake up?
No, I don’t understand it that way. As a matter of fact as stated in the data sheet section 5.2.1 Wakeup Source there are up to 15 possible wake-up sources available. He just means that by default SODIMM pin 45 is used as a GPIO key and can not be used as a regular GPIO. Of course you may use any of them wake-up capable pins as regular GPIOs instead as well.
Is it a hardware or a driver limitation that the same pin cannot be used as both system wake and runtime GPIO?
It looks as though the restriction might be created by virtue of the use of an element in the gpio_keys DT node to indicate that wakeup action is desired. As soon as the system is awakened that purpose has been fulfilled.
Whether or not the current driver supports this, would it in principle be possible to flag a gpio DT node as a wake source rather than having to register it as a gpio_key node? Alternately, could a device tree overlay be used to delete the gpio_key node upon wakeup?
No, you missunderstood my comment. Pins can very well be used as a wake-up source as well as a GPIO. What @bhuvan.tx meant was that GPIO keys can not be used as sysfs GPIOs at the same time. Of course for such custom wake-up pin configurations one will have to modify the device tree one way or another.
It is an intentional driver limitation (avoiding concurrent/conflicting use).
Afaik, there is no generic way to specify a GPIO as wakeable in the device tree. And it seems that a GPIO which is exported through sysfs can also not be defined as wakeable, although there have been patches on the mailing list which do exactly that, but it seems they never made it into the kernel. So the GPIO keys solution is the best way to do this so far. Note that you should be able to read the state of the GPIO through the Linux input event (this Stackoverflow article seems to have a reasonable example for that).
From kernel space you should be able to enable the wakeup capabilities of a GPIO pin by defining it as interrupt source and using the irq_set_irq_wake API.
The overlay idea sounds interesting but also like a bit of over engineering to me. You can use the normal bind/unbind method through sysfs, this seems to work here:
echo gpio-keys > /sys/bus/platform/drivers/gpio-keys/unbind
echo 41 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio41/direction
echo 1 > /sys/class/gpio/gpio41/value
echo 41 > /sys/class/gpio/unexport
echo gpio-keys > /sys/bus/platform/drivers/gpio-keys/bind