On ke, 2008-08-06 at 12:12 -0500, ext Woodruff, Richard wrote:
> > I would say no, we don't need the CONFIG_SYSOFFMODE option.
> 
> One point is if you try an go to 0v on something under and ES2.1 you
> will end up with crashes after a while.  Some kind of conditional is
> needed unless we get to drop the non-production chip versions.

OK. We can replace the macros with run-time checks. But for ES2.1
suspending to 0V should be safe, right?

> 
> Before ES2.1 there is a ROM code bug which will trip up the context
> restore.

So ES2.0 is also affected, good to know.

> 
> Really, it would be good to schedule some time to kill ES1 support.
> The chip is so different its really just baggage.  With cheap and
> available OMAP3's out there they are really not viable.

I've got ES2.0, so no objections from me. Anyone want to confess still
using ES1.0? Tony, what do you think?

> 
> As to C state, I'm not sure, just yet.  If we end up with too many of
> them there is some overhead in determining thresholds, then trying to
> tweak a governor to choose them smartly?  It's a little while before
> this code get to that point, but the process seem to be a bit time
> consuming on internal.

OK, so I think we go with the user selectable "sysoff_while_idle" sysfs
interface and not mess up the C-states. I see Rajendra posted a
refreshed set of patches, so maybe we'll have the C-states in mainline
soon.

regards,
Kalle

> 
> Regards,
> Richard W.
> 
> --
> 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
--
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

Reply via email to