>-----Original Message----- >From: ext Santosh Shilimkar [mailto:[email protected]] >Sent: 19 January, 2011 11:03 >To: Kristo Tero (Nokia-MS/Tampere); Vishwanath Sripathy; linux- >[email protected] >Cc: [email protected]; [email protected] >Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if >doing so would reset an active clockdomain > >> -----Original Message----- >> From: [email protected] [mailto:linux-omap- >> [email protected]] On Behalf Of [email protected] >> Sent: Wednesday, January 19, 2011 2:09 PM >> To: [email protected]; [email protected] >> Cc: [email protected]; [email protected] >> 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.
I'll update the patch desc and resend it in a bit. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
