>-----Original Message----- >From: ext Santosh Shilimkar [mailto:santosh.shilimkar@xxxxxx] >Sent: 19 January, 2011 11:03 >To: Kristo Tero (Nokia-MS/Tampere); Vishwanath Sripathy; 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 > >> -----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. 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
