Santosh Shilimkar <santosh.shilimkar@xxxxxx> writes: >> -----Original Message----- >> From: Kevin Hilman [mailto:khilman@xxxxxx] >> Sent: Friday, March 11, 2011 7:13 AM >> To: Santosh Shilimkar >> Cc: linux-omap@xxxxxxxxxxxxxxx; rnayak@xxxxxx; linux-arm- >> kernel@xxxxxxxxxxxxxxxxxxx >> Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and >> CPUilde support. >> >> Hi Santosh, >> >> Santosh Shilimkar <santosh.shilimkar@xxxxxx> writes: > [....] > >> >> This series doesn't boot on ES1 (boot log below.) Do we need to >> totally prevent WFI on ES1? >> >> Also, if we want a CPUidle enabled kernel to boot on all silicon, it >> will need a omap_rev() check during init to ensure it doesn't >> override the default idle path. >> > Make sense. Will try it on ES1.0 silicon. > > > [....] > >> > off-mode debugfs control: >> > enable: $echo 1 > /proc/sys/debug/pm_debug/enable_off_mode >> > disable: $echo 0 > /proc/sys/debug/pm_debug/enable_off_mode >> >> Without enabling off-mode, I took CPU1 offline and see that it >> immediatly goes off. This makes sense based on the HW, but not in >> light >> of the enable_off_mode flag. For OMAP4, maybe it makes sense to not >> have the enable_off_mode flag at all? We'll be getting rid of it >> on OMAP3 as soon as the constraints framework is ready, so maybe it >> makes sense to just go without it for OMAP4? >> > Actually that's expected since enable_off_mode flag doesn't manage CPUX > power domain states and they are always hit OFF. CSWR isn't > supported on CPUX power domains as captured in the series. But > I agree with you that it might be confusing. > > [...] >> More confusion: another test (also with CPUidle enabled), I see that >> the MPU and DSS are also hitting off-mode: >> > This behavior changed when we dropped enable_off_mode flag to updated > C-states in favor of prepare() hooks. DSS showing OFF mode is because > of debug counter issue. DSS PD doesn't support previous power state > which these counter code is trying to read. There are couple of > patches from Rajendra and Thara do address this counter issues but > they are bit of hacky. May be we can get them on the list to discuss > further. > > So just to summaries, on OMAP$ 'enable_off_mode' flag is > used __only__ in Suspend. CPUx power domain always hit OFF > mode no matter what is state of this flag because CSWR isn't > supported on these PD's. If it's useful only in suspend, then it's redundant with the <debugfs>/pm_debug/*_pwrdm/suspend controls which allow per-pwrdm control over next states. > We could remove this flag as well but thought that this might be > useful especially when we add CORE RET, DEVICE OFF support. I'd rather see working off-mode be a requirement for getting OMAP4 drivers supported. Also, we can still test suspend/resume with off-mode disabled by using the above debugfs controls. > May be we keep this till the constraint frameworks comes in and > then drop it once for all. I am ok with whatever direction you > decide here. I prefer to drop it completely for OMAP4. Kevin -- 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
