On 1/19/2011 3:03 AM, Shilimkar, Santosh wrote:
From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-
owner@xxxxxxxxxxxxxxx] On Behalf Of Tero.Kristo@xxxxxxxxx
Sent: Wednesday, January 19, 2011 2:09 PM
To: vishwanath.bs@xxxxxx; linux-omap@xxxxxxxxxxxxxxx
Cc: paul@xxxxxxxxx; khilman@xxxxxxxxxxxxxxxxxxx
Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if
doing so would reset an active clockdomain
[...]
If some parts of the chip are busy, then how can Core domain
enter off
state? The necessary condition for Core to enter low power state
is
that
all the clock domains (including DSS, CAM, IVA, USB, PER etc)
should
have
idled. Doesn't it mean that all the modules have idled and
asserted
idleack when Core is entering off state?
Besides these, Core off should reset the modules which are only in
Core
domain. It should not impact other power domains. Also Core domain
modules
which are reset will restore their context when Core comes out of
off
mode. So why are you saying that "If those parts of the chip are
busy,
the reset will disrupt them, causing unpredictable and generally
undesirable results."?
Core off issues reset to peripheral domains when it wakes up, this
is somehow (badly) visible in TRM (look for COREDOMAINWKUP_RST.)
When this reset happens, the peripheral domain shows its reset
status as being high, but the powerdomain itself has not entered off
(previous state can be e.g. RET), thus its context will not be
restored.
That's for that reason that CORE OFF with any other power domain active
is not a supported configuration from the system point of view.
And for that very same reason it was removed on OMAP4 to avoid the OMAP3
confusion. Only CORE OSWR is supported on OMAP4.
CORE OFF should be set only if device OFF is targeted, all the other
combinations are not valid.
Wakeup from CORE off will force a reset in order to ensure that the MPU
and thus the ROM code is executed in order to deal with firewall config.
Regards,
Benoit
--
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
