RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain

[Santosh Shilimkar <santosh.shilimkar@ti.com>]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Tero.Kristo@nokia.com
> Sent: Wednesday, January 19, 2011 2:09 PM
> To: vishwanath.bs@ti.com; linux-omap@vger.kernel.org
> Cc: paul@pwsan.com; khilman@deeprootsystems.com
> 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.
>
Now its clear. Reseting other independent clockdomains is
certainly bad from CORE PD OFF to ON behavior .

Please add this additional information to change log.

Regards,
Santosh