Andreas Fenkart <andreas.fenkart@xxxxxxxxxxxxxxxxxxx> writes: > OMAP4430 TRM chap. 25.4.5.2 > To reduce dynamic consumption, an efficient idle scheme is based on the > following: > • An efficient local autoclock gating for each module > • The implementation of control sideband signals between the PRCM module > and each module > This enhanced idle control allows clocks to be activated and deactivated > safely without requiring complex software management. The idle mode > request, idle acknowledge, and wake-up request are sideband signals > between the PRCM module and the general-purpose interface > > OMAP4430 TRM chap. 25.4.6.2 > There must be a correlation between the wake-up enable and interrupt > enable register. If a GPIO pin has a wake-up configured on it, it must > also have the corresponding interrupt enabled. Otherwise, it is possible > there is a wake-up event, but after exiting the IDLE state, no interrupt > is generated; the corresponding bit from the interrupt status register is > not cleared, and the module does not acknowledge a future idle request. > > Up to now _set_gpio_triggering() is also handling the wake-up enable > register. According the TRM this should be in sync with the interrupt > enable. Wakeup is still enabled by default, since the module would not > wake from idle otherwise. > The enabled_wakeup_gpios was introduced to remember an explicit > _set_gpio_wakeup beyond a mask/unmask cycle. Calling the flag flag > disabled_wakeup_gpios would spare the problem of initializing it, but > feels very unnatural to read. There's a lot of description here, but it still fails to describe the problem that is being solved and the motiviation for this change. > Wakeup functionality is completely untested, since the AM335x > lacks a IRQWAKEN register. So in addtion to a better description of the problem, and the changes, this needs much broader testing, including on platforms with off-mode. Kevin -- 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
