LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Len Brown <lenb@kernel.org>
Cc: jg@laptop.org, Bjorn Helgaas <bjorn.helgaas@hp.com>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	Linux Kernel ML <linux-kernel@vger.kernel.org>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	ACPI ML <linux-acpi@vger.kernel.org>,
	Adam Belay <abelay@novell.com>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
	Arjan van de Ven <arjan@linux.intel.com>,
	devel@laptop.org
Subject: Re: [OLPC-devel] Re: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements
Date: Mon, 4 Sep 2006 13:13:23 +0000	[thread overview]
Message-ID: <20060904131323.GE6279@ucw.cz> (raw)
In-Reply-To: <200608312353.05337.len.brown@intel.com>

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.

  parent reply	other threads:[~2006-09-04 13:13 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
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 [this message]
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

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060904131323.GE6279@ucw.cz \
    --to=pavel@ucw.cz \
    --cc=abelay@novell.com \
    --cc=arjan@linux.intel.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=devel@laptop.org \
    --cc=jg@laptop.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=mjg59@srcf.ucam.org \
    --cc=venkatesh.pallipadi@intel.com \
    --subject='Re: [OLPC-devel] Re: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).