LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Len Brown <email@example.com>
Cc: Bjorn Helgaas <firstname.lastname@example.org>,
Matthew Garrett <email@example.com>,
Linux Kernel ML <firstname.lastname@example.org>,
Dominik Brodowski <email@example.com>,
ACPI ML <firstname.lastname@example.org>,
Adam Belay <email@example.com>,
"Pallipadi, Venkatesh" <firstname.lastname@example.org>,
Arjan van de Ven <email@example.com>,
Subject: Re: [OLPC-devel] Re: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements
Date: Thu, 31 Aug 2006 23:53:04 -0400 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
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".
next prev parent reply other threads:[~2006-09-01 3:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-30 18:40 Pallipadi, Venkatesh
2006-08-30 19:43 ` Matthew Garrett
2006-08-31 23:13 ` Bjorn Helgaas
2006-09-01 0:30 ` [OLPC-devel] " Jim Gettys
2006-09-01 3:53 ` Len Brown [this message]
2006-09-01 4:12 ` Matthew Garrett
2006-09-01 15:51 ` Jordan Crouse
2006-09-01 13:14 ` [OLPC-devel] Re: [RFC][PATCH 1/2] " Carl-Daniel Hailfinger
2006-09-01 21:52 ` Andi Kleen
2006-09-01 22:57 ` Alan Cox
2006-09-04 13:13 ` Pavel Machek
2006-09-04 13:09 ` Pavel Machek
2006-09-05 14:31 ` Jim Gettys
2006-09-06 10:37 ` Pavel Machek
2006-09-06 14:58 ` Jordan Crouse
2006-09-12 9:21 ` Pavel Machek
2006-09-12 18:14 ` Jim Gettys
2006-09-12 18:27 ` Mitch Bradley
2006-09-12 20:18 ` Jordan Crouse
2006-09-14 9:20 ` Pavel Machek
2006-09-14 9:18 ` Pavel Machek
2006-09-14 11:29 ` Jim Gettys
2006-09-06 15:19 ` [OLPC-devel] Re: [RFC][PATCH 1/2] " Jim Gettys
2006-09-12 9:21 ` Pavel Machek
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [OLPC-devel] Re: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).