[OLPC-devel] Re: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements
Pavel Machek
pavel at ucw.cz
Mon Sep 4 09:13:23 EDT 2006
On Thu 31-08-06 23:53:04, Len Brown wrote:
> On Thursday 31 August 2006 20:30, Jim Gettys wrote:
> > On Thu, 2006-08-31 at 17:13 -0600, Bjorn Helgaas wrote:
> > > On Wednesday 30 August 2006 13:43, Matthew Garrett wrote:
> > > > That would be helpful. For the One Laptop Per Child project (or whatever
> > > > it's called today), it would be advantageous to run without acpi.
> > >
> > > Out of curiosity, what is the motivation for running without acpi?
> > > It costs a lot to diverge from the mainstream in areas like that,
> > > so there must be a big payoff. But maybe if OLPC depends on acpi
> > > being smarter about power or code size or whatever, those improvements
> > > could be made and everybody would benefit.
> >
> > Good question; I see Matthew beat me to part of the explanation, but
> > here is more detail:
>
> I recommended that the OLPC guys not use ACPI.
>
> I do not think it would benefit their system. Although it is an i386
> instruction set, their system is more like an embedded device than
> like a traditional laptop.
>
> The Geode doesn't suport any C-states -- so ACPI wouldn't help them there anyway.
>
> As Jim wrote, OLPC plans to suspend-to-ram from idle, and to keep video running,
> so ACPI wouldn't help them on that either.
>
> Re: optimizing suspend/resume speed
> I expect suspend/resume speed has more to do with devices than with ACPI.
> But frankly, with gaping functionality holes in Linux suspend/resume support such as
> IDE and SATA, I think that optimizing for suspend/resume speed on a mainstream laptop
> is somewhat "forward looking".
Well, list of hardware where s2ram works okay is long and growing...
of course, help is always wanted. And yes, it would be nice if someone
optimized suspend/resume speed. There are somelow-hanging fruits
there.
--
Thanks for all the (sleeping) penguins.
More information about the Devel
mailing list