On Sat, 2010-05-29 at 11:10 -0500, James Bottomley wrote: > > If current hardware can't cope, too friggin bad, get better hardware. > > > > But the truth is, all your OMAP phones really can deal with it. > > That's rubbish and you know it. We do software workarounds for hardware > problems all the time ... try doing a git grep -i errata in arch x86, or > imagine a USB subsystem that only supported sane standards conforming > devices: that would have an almost zero intersect with the current USB > device market. > > The job of the kernel is to accommodate hardware as best it can ... > sometimes it might not be able to, but most of the time it does a pretty > good job. Sure, and if x86 could wake from S3 on a keypress/mouse movement etc.. you could use S3 as idle state.. not sure people would love the wakeup-latency, but that's a QoS matter. But if there simply are no suitable wakeup sources from an idle state (S3 really is nothing more than a hardware idle state) then it might not be suitable for transparent idle modes and no amount of software hackery will solve that. So what I'm saying is, if your hardware can't generate the needed wakeup events, the auto-suspend stuff won't work either. If it can it can be implemented as a regular idle mode. > The facts are that C states and S states are different and are entered > differently. For some omap hardware, the power consumption in the > lowest C state (with all the ancillary power control) is the same as S3, > that's fine, suspend from idle works as well as suspend to ram modulo > bad apps. For quite a lot of MSM hardware, the lowest C state power > consumption is quite a bit above S3. Wth is MSM? But really, why can't existing hardware get shipped with existing hacks, and for future hardware that does behave we have a proper solution? -- 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
