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 majordomo@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
