[PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.
Kevin Hilman
khilman at ti.com
Fri Mar 11 12:50:22 EST 2011
Santosh Shilimkar <santosh.shilimkar at ti.com> writes:
> Kevin,
>
>> -----Original Message-----
>> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-
>> arm-kernel-bounces at lists.infradead.org] On Behalf Of Kevin Hilman
>> Sent: Friday, March 11, 2011 9:22 PM
>> To: Santosh Shilimkar
>> Cc: linux-omap at vger.kernel.org; linux-arm-
>> kernel at lists.infradead.org; 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
More information about the linux-arm-kernel
mailing list