> -----Original Message----- > 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. > 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 -- 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
