* Tony Lindgren <tony@xxxxxxxxxxx> [160408 10:52]: > * Grygorii Strashko <grygorii.strashko@xxxxxx> [160408 10:17]: > > > > It can't :( It can't generate IRQ when state of ext_wakeup line has > > been changed. > > Hmm to me it certainly seems it should be capable of generating and RTC > interrupt as we have EXT_WAKEUP_STATUS register containing four bits, > one for each wakeup line. So I played a bit with RTC last night and the RTC_PMIC_REG options.. And I came to the same conclusion as Grygorii pretty much. It looks like an interrupt, except it can't generate any interrupts. Sorry for not believing it earlier. It might still be a good idea to confirm this with some hardware folks at TI, maybe newer versions could add support for an interrupt. The EXT_WAKEUP configuration only seems to affect pmic_pwr_enable pin if configured right. Depending on the PMIC, we could use a shared interrupt for handling the ext wakeup line changes in the RTC driver. The ext wakeup lines are not really GPIOs either as we can't monitor the wakeup line states, they are just trigger and then hold the state until cleared. If we ever need to provide the state of the wakeup lines to the other drivers, we could still use GPIO, input, or pinctrl. All these allow adding interrupt support for the cases that allow sharing the interrupt with PMIC. I guess we should just pick the framework that already has support for configuring the debounce time for a pin. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
