Vishwanath Sripathy had written, on 12/13/2010 08:25 AM, the following:
[...]
+ if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
&&
+ (core_next_state == PWRDM_POWER_OFF))
{
+ pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
+ core_next_state = PWRDM_POWER_RET;
+ }
Since next_state in pwrst_list (for core) is not updated, this is
throwing
up an error "Powerdomain (core_pwrdm) didn't enter target state
0"
when
you off mode is enabled for ES1.1 or lesser (in suspend path). It's
not
really true that Core has not entered target state. It has entered
Retention state which is the actual target state set in
omap_sram_idle.
However it did not enter the state that was passed by
omap3_pm_suspend. Is
this expected behavior?
we could go both ways on this - this patch will(as you noticed)
indicate
that the transition failed on <ES1.2, or we could make it entirely
transparent(by modifying the the pwrst_list - claim we achieved off,
while not really hitting off - I personally dont think that is
correct.
The point I am making is that you cannot distinguish between genuine
off
/retention failure since this message is thrown for both pass and
fail.
May be an additional trace message indicating that system entered
retention instead of off (for ES<1.2) will be useful.
hmm... good point there.
two issues here:
a) omap3_pm_suspend should probably state which state was achieved
as
well in the error message (trivial fix).
b) how do we notify users that it was due to
SDRC_WAKEUP_ERRATUM_i583
that core-off was denied. -> do this in omap3_pm_suspend(when user
attempts actual OFF) OR omap3_pm_off_mode_enable(when user
attempts to
enable OFF mode)?
Any suggestions to allow the same uImage boot on all silicon + allow
cpu_idle + suspend paths not to spew pr_info messages(aka cant add
prints in sram_idle)?
I vote for denying off mode for Core (for ES<1.2) in
omap3_pm_off_mode_enable and throw up a message saying that Core off is
not enabled. Then we will not get this failure message in suspend path
since pwrst_list will have the right state.
Keep in mind - if we disable it in omap3_pm_off_mode_enable - we will
deny OFF wholesale if I understand the logic right- not just core-off -
I kind of think that is extreme.
--
Regards,
Nishanth Menon
--
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
