On 8/9/2010 11:37 AM, Nayak, Rajendra wrote:
From: Paul Walmsley [mailto:paul@xxxxxxxxx]
Sent: Monday, August 09, 2010 1:51 PM
(cc Benoît)
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.
The reason I proposed ENAWAKEUP to be always enabled with smart-idle was
with as understanding that we may never have a case wherein the module
is programmed in smart-idle but not expected to assert SWakeup (if it
supports one). I will check up on this if there ever could be such a
case.
This is something that can make sense on OMAP4, because the wakeup
status is de-asserted automatically as soon as the interrupt status is
cleared.
On previous platform, as Paul said, we will have to handle that manually
somewhere, but preferably not in driver directly.
It will not be that straightforward.
instead of exposing 2 more omap device level api;s to the drivers?
Something like this probably needs to be exposed to core code
that would
also set/clear PM_WKEN_* for the appropriate processor
module. Right now
we just set a bunch of these bits directly in pmXXXX.c, and
that needs to
change.
The other issue is that I suspct the module needs to be
enabled in order
for SYSCONFIG writes to succeed; right now the underlying
hwmod code does
not appear to enforce this :-(
At least we have a comment saying that we should do it :-)
We probably just need to ensure that a module is enabled before
accessing the sysconfig.
Regards,
Benoit
But I don't see why drivers would need to call these
functions directly.
Hema, was that your intention? If so, you could you please
explain the
use case?
I have a patch for this and can post it for review in case you
feel it makes sense.
- Paul
--
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
