Santosh Shilimkar <[email protected]> writes: > Kevin, > >> -----Original Message----- >> From: [email protected] [mailto:linux- >> [email protected]] On Behalf Of Kevin Hilman >> Sent: Friday, March 11, 2011 9:22 PM >> To: Santosh Shilimkar >> Cc: [email protected]; linux-arm- >> [email protected]; Rajendra Nayak >> Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend,CPU-hotplug and >> CPUilde support. >> > > [....] > >> > >> > 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. >> > OK. Lets do that. > > Just to not miss your point here, what I understood here > is default suspend state on OMAP$B will be off mode. > > We still keep "enable_off_mode" flag for testing so that we > can disable off mode to debug regressions. > > Is that right?
No, I want to drop "enable_off_mode" all together for OMAP4. If you want to change any powerdomain's default next_state, you can use the <debugfs>/pm_debug/*_pwrdm/suspend controls. Kevin -- 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
