Hello Jouni, On Tue, 12 Aug 2008, Högander Jouni wrote: > "ext Paul Walmsley" <paul@xxxxxxxxxxx> writes: > > > On Mon, 11 Aug 2008, Högander Jouni wrote: > > > >> "ext Paul Walmsley" <paul@xxxxxxxxxxx> writes: > >> > >> > Could you explain a little further why PER would have a wakeup dependency > >> > on CORE? Is this something that we should only enable under certain > >> > conditions, e.g., latency requirements for a device in PER? > >> > >> This is done to make sure we don't loose any gpio interrupts: GPIO > >> wakeup/interrupt doesn't work for GPIOs in PER domain if PER is not > >> active. > > > > I'm probably misunderstanding something, but ... wouldn't it better to > > just keep PER powerdomain ON all the time when PER GPIOs are enabled for > > interrupts? It seems possible for PER to go to retention or OFF even with > > the CORE wkdep in place, which would result in a period of time where the > > interrupts would be missed, no? > > No, it won't, PER goes sleep state only if CORE goes > too. There is a hardware sleepdep between PER and CORE, thanks to > Rajendra for pointing this out some time ago. This way there are all > the time some wakeup mechanism available for PER gpios > (gpio/iopad). Leaving PER ON would increase consumption. Ah, I see. Do you think we should add a mechanism for the CORE->PER wkdep to be dynamically added and removed, based on whether GPIO2-6 balls are enabled in IO pad wakeup? Conceivably a board could just use GPIO1 (in WKUP), and PER would not need to be awakened along with CORE in those instances, correct? - Paul
