[OLPC-devel] Re: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements

[Matthew Garrett <mjg59@srcf.ucam.org>]

On Thu, Aug 31, 2006 at 05:13:20PM -0600, Bjorn Helgaas wrote:

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

The current issues are probably the code size and the somewhat 
specialised needs of OLPC. The hardware is interesting in that the 
framebuffer is designed to carry on reading from memory even if the rest 
of the system is in S3. The aim here is to allow the machine to suspend 
when idle while still giving the impression of being alive. It's 
therefore important that the system come out of suspend as quickly as 
possible in order to avoid spoiling that impression, and suspend as 
quickly as possible in order to maximise the power savings. The 
assumption is that parsing AML is something that would add to these time 
periods without providing any significant extra benefit.

Of course, the other main issue is that providing an ACPI platform would 
require us to actually write a set of ACPI tables. The system is running 
Linuxbios, and every kilobyte that's not used by a static table in the 
BIOS is space that could be used for extra functionality.

I think the basic consensus was that ACPI bought us fairly little other 
than the ability to use the existing suspend/resume code, C state 
transitions and battery monitoring, and that replacing the first was 
probably desirable in any case.
-- 
Matthew Garrett | mjg59@srcf.ucam.org