Hello Benoît, Rajendra, Hema, On Mon, 9 Aug 2010, Cousson, Benoit wrote: > On 8/9/2010 11:37 AM, Nayak, Rajendra wrote: > > > > > From: Paul Walmsley [mailto:paul@xxxxxxxxx] > > > Sent: Monday, August 09, 2010 1:51 PM > > > > > > On Mon, 9 Aug 2010, Nayak, Rajendra wrote: > > > > > > > Does it make sense for the framework itself to enable wakeup > > > > for all devices when the slave port is programmed to be in > > > > Smartidle > > > > > > It seems to me that they are separate mechanisms? If a module is > > > programmed for slave smart-idle, then the module prevents the > > > PRCM from > > > shutting off the module clock(s) until the module is not > > > busy. This seems > > > distinct from ENAWAKEUP, which I thought simply controlled > > > whether the > > > module would assert the SWakeup signal to the PRCM when an > > > external wakeup > > > condition occurred for that module. Is that an accurate summary? > > > > hmm.. the reason I thought the two were related was because the need to > > assert a SWakeup will arise only when the module is programmed in > > smart-idle. > > If the module is either in no-idle (in which case no idle-ack is asserted > > by the module) or force-idle (when the module is forced to idle and > > expected to stay idle) there might not be a need for the module to be > > capable of asserting a SWakeup. > > In fact, the SWakeup is asserted as soon as the module is in idle (idle_ack = > 1) and cannot use the OCP interface to communicate a IRQ_REQ or DMA_REQ. > But the wakeup capability is disabled by setting the SidleMode to Force-Idle, > regardless of the value of Wakeup enable. > Bottom-line is that the SWakeup can be asserted only if the module is in > smart-idle. In that case, it sounds like Rajendra's patch would be useful (to automatically enable ENAWAKEUP during target smart-idle, and disable it during target no-idle or force-idle, would be worthwhile)? One other situation that we should consider would be if it ever makes sense to program a module to target smart-idle, but disable ENAWAKEUP. I suppose it should only be necessary if there is a hardware bug where an IP block generates spurious SWakeups. -- But if we have no current need for this type of workaround, maybe we can just ignore this case and have the ENAWAKEUP bit follow target smart-idle status. Then if such a hardware bug appears, we can separate ENAWAKEUP programming later. Thoughts? - Paul
