RE: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements

RE: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org 
>[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Adam Belay
>Sent: Tuesday, August 29, 2006 1:51 PM
>To: Brown, Len
>Cc: ACPI ML; Linux Kernel ML; Dominik Brodowski; Arjan van de Ven
>Subject: [RFC][PATCH 1/2] ACPI: Idle Processor PM Improvements
>
>Hi All,
>
>This patch improves the ACPI c-state selection algorithm.  It also
>includes a major cleanup and simplification of the processor idle code.
>
>The new implementation considers the full menu of available c-states.
>Just as the previous implementation, decisions are primarily based on
>the residency time of the last c-state entry.  This is generally an
>effective metric because it allows for detection of interrupt activity.
>However, the new algorithm differs in that it does not promote 
>or demote
>through the c-states in succession.  Rather, it immediately jumps to
>whatever c-state has the best expected power consumption advantage for
>the predicted residency time (i.e. the previously measured residency).
>If the residency time is too short during a deep c-state 
>entry, then the
>cost of entering the state outweighs any power consumption advantage.
>Similarly, if a shallow c-state is entered and resident for an
>excessively long duration, then a potential opportunity to save more
>power is missed.
>
>The changes in this patch allow the ACPI idle processor mechanism to
>react more quickly to sudden bursts of activity because it can jump
>directly to whatever c-state is appropriate.  However, because of the
>"menu" nature of c-state selection, the code works best when ACPI
>implementations expose all of the c-states supported by hardware.
>
>The bus master activity mechanism has undergone similar improvements.
>During capability detection, the deepest c-state that allows bus master
>activity is determined.  BM_STS is then polled each time the ACPI code
>prepares to enter a c-state.  If bus master activity is detected, then
>the previously mentioned bus master capable c-state becomes the deepest
>c-state allowed for that quantum.  In contrast, the old implementation
>would permit bus master activity to cause a promotion from one C3-type
>state to the next shallower C3-type state, imposing 
>unnecessary latency.
>As a further optimization, BM_STS is cleared each time
>acpi_processor_idle() is entered.  This prevents any stale bus master
>status from affecting c-state policy, as it may have occurred long ago
>during scheduled work.
>
>Finally, it's worth mentioning that the bulk of c-state policy
>calculations have been moved to take place before c-states are entered.
>This should further reduce exit latency when returning from a c-state.
>
>This algorithm has not yet been carefully benchmarked (e.g. bltk or
>power meters).  However, I can say with some confidence that it saves a
>small amount more power during an idle workload and a larger 
>amount more
>power during typical user-input oriented workloads such as word
>processing.
>
>I would really appreciate any comments, suggestions, or testing.
>

Nice changes. Will test and let you know how it goes.

While we are at cleaning up the code, I think it will be much better to 
move out C-state policy out of this acpi code altogether. We should have

just a generic interface, where any low level driver (acpi) can 
register/unregister a idle routine with latency, power and other 
characteristics (BM_STS). That way the policy can be generic and 
out of ACPI code. We had a patch earlier that does something like this
here:
http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg00129.html
http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg00130.html
But, that did not go anywhere at that time. Probably we can do some 
cleanup like that, along with this patch....

Thanks,
Venki

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

[Matthew Garrett]

On Wed, Aug 30, 2006 at 11:40:16AM -0700, Pallipadi, Venkatesh wrote:

(Added devel@laptop.org to the Cc:)

> While we are at cleaning up the code, I think it will be much better to 
> move out C-state policy out of this acpi code altogether. We should have

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. At the 
moment that would cost us deeper C states, so an interface to allow a 
platform driver to register and provide the same functionality without 
code duplication would be helpful.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[Bjorn Helgaas]

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.

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

[Jim Gettys]

[-- Attachment #1: Type: text/plain, Size: 4700 bytes --]

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:

Our screen consumes of order 1/10th the power of a conventional flat
panel, and can consume a half watt or so (yes, we now have working
screens; this is not mythological hardware; I got my own personal first
hand look at prototype display running this afternoon :-); I always do
line new toys...).  

Even though the base machine may take only a couple watts of power
(Geode GX + the rest of the base logic), 2-3 watts is too much power to
use; a small child can generate only 7-10 watts.  So if we want a decent
"learn" to "generate" ratio, we have to do better than the 2-4 to 1
ratio we might get conventionally.  In January, we saw this staring us
in the face, and knew we had to do better, or we'd have just told a good
fraction of the kids in the world they can't have the advantages of a
computer.  Our goal has always been a 10 to 1 ratio, for at least the
most important use cases (e.g. reading).

OK, what to do?  We built a chip that lets us suspend the processor and
keep the screen alive, and chose a wireless chip that will let us keep
the mesh network alive, and we intend to suspend/resume the processor
to/from RAM at the drop of a hat.  This gets our idle consumption from
about 2.5-3 watts (with screen and wireless on), to under one watt.
We'd need resume to be as close to imperceptible as possible; touch a
key or the touchpad, the machine resumes so fast as you don't notice.

In short, we have novel hardware: we can have our screen on, and suspend
the processor to RAM, and use a half a watt.  We can have our wireless
forwarding packets in our mesh networks, with the processor suspended,
consuming under 400mw (we hope 300mw by the time we ship).  Both on, and
we're still under one watt.

For keyboard activity, human perception is in the 100-200 millisecond
range; for some other stuff, it is even less much than that.  So that's
the necessity; now the invention.

I've done a straw pole among kernel gurus at OLS and elsewhere on how
fast Linux might be able to resume. I've gotten answers of typically
"one second".

But, on other platforms (see attached), I have data I've measured myself
showing Linux going from resume from RAM to *scheduling user level
processes* 100 times faster than that, on a wimpy 200mhz ARM processor.
Yes, Matilda, Linux can, on non-braindead hardware, resume all the way
to scheduling user processes in 10 milliseconds on a 200mhz processor.

This will, for most use cases (you are reading, or your machine is
sitting there between bursts of activity), likely double / triple /
quadruple our battery life depending on what you are doing.  Note that
on a conventional machine, with a conventional display, you'd not see
this large an improvement.  Worst case, of course, it will make no
difference at all (e.g. watching a video).

Clearly we can't do any better than what our hardware allows
(stabilization of power supplies, PLL's, etc).  I should have data on
that very shortly, now that I can measure it on LinuxBIOS pretty
directly.  For those of you building chips and systems: please make the
hardware restart time as fast as possible: it matters.  The CPU doesn't
have to go full speed instantly; just get it going at some speed as
quickly as you can.

Conventional PC's with conventional BIOS's using ACPI don't do anything
like as well. So, guess what?  We don't plan to use a conventional
commercial BIOS, (we're using LinuxBIOS and Linux as Bootloader) and
will do whatever it takes (including ignoring however much of ACPI turns
out to be necessary) to get our resume down to what we know is possible.
ACPI is mostly an x86 aberration; on most architectures it does not
exist.  So it does not require contorting Linux to not use ACPI, to the
extent we find it necessary.  Most of *real* power management is done by
Linux, and not by ACPI.

Boy, human powered machines really *do* focus the mind on power
management ;-).
                              Regards,
                                     - Jim Gettys

-- 
Jim Gettys
One Laptop Per Child


[-- Attachment #2: Attached message - Linux resume time on iPAQ (Linux resume can be *really* fast). --]
[-- Type: message/rfc822, Size: 5396 bytes --]

From: Jim Gettys <jg@laptop.org>
To: OLPC Developer's List <devel@laptop.org>
Subject: Linux resume time on iPAQ (Linux resume can be *really* fast).
Date: Fri, 14 Jul 2006 20:21:05 -0400
Message-ID: <1152922866.6001.332.camel@localhost.localdomain>


The iPAQ is by far the closest device we have to modeling the OLPC
system, though the one I chose is less than 1/2 the integer performance
of our machine. It has roughly comparable peripherals to the OLPC
system, and unified graphics as the Geode (just a dumb frame buffer on
the SA1100).

Here's the test:

I have a simple C program written for me by Joshua Wise that just writes
characters to /dev/tty.  It can either do so continuously, or open and
close the device between each character.  In the former case, you get
metronome like character output, as the characters are all interrupt
driven out of the kernel character buffers; in the latter case, the
close/open sequence enables the operating system to reschedule the
process as it sees fit.  This is a much more interesting test.

I reconfirmed the data with Mike Bove this afternoon.

A: suspend on the iPAQ is amazingly fast; we could see no significant
delay from emitting a character to power off of the machine.

B: resume is also very fast, if not quite so fast (of order a few up to
10 milliseconds).

Here's the the measurement methodology:

I suspend the iPAQ.

I wait some amount of time.

I resume the iPAQ.  Conveniently, there happens to be a debug message
emitted by the bootloader right when it transfers control to Linux.

1) The iPAQ does nothing for anywhere between 280-400ms after resume
starts; we do not know (or care) what the cause actually is. We theorize
that it has some built in delay on how long the power supply takes to
stabilize or some such strangeness.   This will be a combination of
whatever hardware delays force us + any bootloader/BIOS delays.

2) within some few milliseconds of actually resuming (like of order 10
ms), Linux is in user space executing code, and some characters again
appear on the serial port.

3) There then appears to be an approximately 180ms gap before characters
again start appearing on the output port.  

The resume is triggering processes in user space; if I kill the cardmgr
process, used for hotplug of PCMCIA, this gap goes away.  There may be
very simple solutions too: e.g. running those processes at reduced
priority, but probably better is to try to arrange hotplug to work in
some other fashion.

Conclusion
==========

Linux can resume *really, really, really* fast, if the hardware lets it,
and the device drivers don't have bad delays built into them.  

If they do have such bad delays, we might have to do Mark's fast
suspend/resume scheme, or something driver specific. I really like
Mark's fast suspend/resume idea, and on some big systems (or with really
bad hardware that has multiple very long delays, it may be a godsend). 

We *will* have to do something about this user space behavior, which is
not at all surprising. One option might be to only attempt hotplug when
the lid is closed, or when you invoke some application, rather than on
resume from save to RAM; or it may be possible to do this on USB
provided hotplug events (but I haven't read the Geode errata sheet for a
while).

So: 
  o we need to vet the drivers we are using to see if any of them have
long built in delays on resume.  If our hardware is really braindead, we
might still have to do something about parallelizing the resume code.
The most likely driver to have problems with is clearly going to be USB,
and we need USB to talk to the Marvell chip.
  o The iPAQ is running Linux 2.4 which does not have a
particularly decent scheduler; it doesn't follow that we'll necessarily
see the same complete starvation of the original process (though we very
well might). We certainly don't want to be triggering hotplug at the
rate we'd like to suspend/resume.

Next step: perform the same tests on the OLPC system and see what that
tells us.  This is just now to the point of becoming feasible.
                               Regards,
                                 - Jim

-- 
Jim Gettys
One Laptop Per Child

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

[Len Brown]

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

-Len

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

[Matthew Garrett]

On Thu, Aug 31, 2006 at 11:53:04PM -0400, Len Brown wrote:

> The Geode doesn't suport any C-states -- so ACPI wouldn't help them there anyway.

Are you sure of that? The docs I have here suggest C1 and C2, but it's 
possible that that's just the companion chip and they aren't implemented 
in the CPU.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ACPI: Idle Processor PM Improvements

[Jordan Crouse]

On 01/09/06 05:12 +0100, Matthew Garrett wrote:
> On Thu, Aug 31, 2006 at 11:53:04PM -0400, Len Brown wrote:
> 
> > The Geode doesn't suport any C-states -- so ACPI wouldn't help them there anyway.
> 
> Are you sure of that? The docs I have here suggest C1 and C2, but it's 
> possible that that's just the companion chip and they aren't implemented 
> in the CPU.

C1 is essentially suspend on hlt.  We have something called Automatic Hardware
Clock Gating that kicks in when the blocks go unused, so that saves a bit
more power (especially in the south bridge) then we would with just a simple
hlt.  In any event, this already happens without the assistance of ACPI.

The 5536 has support for a C2 state as well, but I don't know if that
has any effect on the GX or not.

Jordan

-- 
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<www.amd.com/embeddedprocessors>

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

[Carl-Daniel Hailfinger]

Len Brown wrote:
> 
> 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".

OLPC has no IDE/SATA devices, just 512 MB of onboard NAND flash.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

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

[Andi Kleen]

Len Brown <len.brown@intel.com> writes:
> 
> 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".

What are these gaping holes? SATA seems to work at least on many
drivers with an out of tree patch (that will hopefully be merged soon)
And IDE mostly works too except for HPA on thinkpads (which can be
disabled in the BIOS). While certainly not perfect it doesn't seem
that bad to me.

-Andi


-- 
VGER BF report: H 0

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

[Alan Cox]

Ar Gwe, 2006-09-01 am 23:52 +0200, ysgrifennodd Andi Kleen:
> What are these gaping holes? SATA seems to work at least on many
> drivers with an out of tree patch (that will hopefully be merged soon)

SATA ought to be pretty good now. 

> And IDE mostly works too except for HPA on thinkpads (which can be
> disabled in the BIOS). While certainly not perfect it doesn't seem
> that bad to me.

IDE also fails for various chipsets where PLLs need a recalibration or
setup needs redoing, and some users report things like floating IRQ 14
hangs on suspend or resume.

HPA now has a -mm proposed patch.

Alan


-- 
VGER BF report: H 0

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

[Pavel Machek]

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.

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

[Pavel Machek]

Hi!

> In short, we have novel hardware: we can have our screen on, and suspend
> the processor to RAM, and use a half a watt.  We can have our wireless
> forwarding packets in our mesh networks, with the processor suspended,
> consuming under 400mw (we hope 300mw by the time we ship).  Both on, and
> we're still under one watt.
> 
> For keyboard activity, human perception is in the 100-200 millisecond
> range; for some other stuff, it is even less much than that.  So that's
> the necessity; now the invention.
> 
> I've done a straw pole among kernel gurus at OLS and elsewhere on how
> fast Linux might be able to resume. I've gotten answers of typically
> "one second".
> 
> But, on other platforms (see attached), I have data I've measured myself
> showing Linux going from resume from RAM to *scheduling user level
> processes* 100 times faster than that, on a wimpy 200mhz ARM processor.
> Yes, Matilda, Linux can, on non-braindead hardware, resume all the way
> to scheduling user processes in 10 milliseconds on a 200mhz processor.

2.4 and 2.6 are *very* different here. You'll probably need to optimize freezer
in 2.6 a bit...
							Pavel
-- 
Thanks for all the (sleeping) penguins.

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

[Jim Gettys]

On Mon, 2006-09-04 at 13:09 +0000, Pavel Machek wrote:

> 
> 2.4 and 2.6 are *very* different here. You'll probably need to optimize freezer
> in 2.6 a bit...
> 						

Among other problems: e.g. 2.4 did not automatically do a VT switch; 2.6
does; we'll have to have a way to signal "we're a sane display driver;
don't switch away from me on suspend".
                                 - Jim

-- 
Jim Gettys
One Laptop Per Child

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

[Pavel Machek]

Hi!

> > 2.4 and 2.6 are *very* different here. You'll probably need to optimize freezer
> > in 2.6 a bit...
> > 						
> 
> Among other problems: e.g. 2.4 did not automatically do a VT switch; 2.6
> does; we'll have to have a way to signal "we're a sane display driver;
> don't switch away from me on suspend".

Not like that, please.

You are using X running over framebuffer, right? So that kernel is
controlling the graphics hardware. In such case it is safe to avoid VT
switch.
									Pavel
-- 
Thanks, Sharp!

Re: ACPI: Idle Processor PM Improvements

[Jordan Crouse]

On 06/09/06 12:37 +0200, Pavel Machek wrote:
> Hi!
> 
> > > 2.4 and 2.6 are *very* different here. You'll probably need to optimize freezer
> > > in 2.6 a bit...
> > > 						
> > 
> > Among other problems: e.g. 2.4 did not automatically do a VT switch; 2.6
> > does; we'll have to have a way to signal "we're a sane display driver;
> > don't switch away from me on suspend".
> 
> Not like that, please.
> 
> You are using X running over framebuffer, right? So that kernel is
> controlling the graphics hardware. In such case it is safe to avoid VT
> switch.

Actually not - the Geode GX has full 2D hardware acceleration with a complete
X driver to match.  No Xfbdev here.

Jordan

Pavel
-- 
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<www.amd.com/embeddedprocessors>

Re: ACPI: Idle Processor PM Improvements

[Pavel Machek]

On Wed 2006-09-06 08:58:49, Jordan Crouse wrote:
> On 06/09/06 12:37 +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > > 2.4 and 2.6 are *very* different here. You'll probably need to optimize freezer
> > > > in 2.6 a bit...
> > > > 						
> > > 
> > > Among other problems: e.g. 2.4 did not automatically do a VT switch; 2.6
> > > does; we'll have to have a way to signal "we're a sane display driver;
> > > don't switch away from me on suspend".
> > 
> > Not like that, please.
> > 
> > You are using X running over framebuffer, right? So that kernel is
> > controlling the graphics hardware. In such case it is safe to avoid VT
> > switch.
> 
> Actually not - the Geode GX has full 2D hardware acceleration with a complete
> X driver to match.  No Xfbdev here.

Ok, so what is needed is message to X "we are suspending", and X needs
to respond "okay, I'm ready, no need for console switch".

Alternatively, hack kernel to take control from X without actually
switching consoles. That should be possible even with current
interface.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: ACPI: Idle Processor PM Improvements

[Jim Gettys]

On Tue, 2006-09-12 at 11:21 +0200, Pavel Machek wrote:

> Ok, so what is needed is message to X "we are suspending", and X needs
> to respond "okay, I'm ready, no need for console switch".

This presumes an external agent to X controlling the fast
suspend/resume, with messages having to flow to and from X, and to and
from the kernel, with the kernel in the middle.

Another simpler option is X itself just telling the kernel to suspend
without console switch, as the handoff of the display to the DCON chip
has to be done with X and with an interrupt signaling completion of the
handoff.  This would be triggered by an inactivity timeout in the X
server.

I'm not sure which is best right now: generality vs. simplicity.  We
just got samples of hardware to do some prototyping on in the last two
weeks. (see wiki.laptop.org for photographs of our screen and the DCON
in action).

> 
> Alternatively, hack kernel to take control from X without actually
> switching consoles. That should be possible even with current
> interface.

This would require saving/restoring all graphics state in the kernel
(and X already has that state internally).  Feasible, but seems like
duplication of effort.  I haven't checked if there are any write-only
registers in the Geode (though, thankfully, this kind of brain damage is
rarer than it once was).  This then begs interesting kernel/X
synchronization issues, of course.
                                     - Jim


> 								Pavel
-- 
Jim Gettys
One Laptop Per Child

Re: ACPI: Idle Processor PM Improvements

[Mitch Bradley]

Jim Gettys wrote:
>
>  I haven't checked if there are any write-only
> registers in the Geode (though, thankfully, this kind of brain damage is
> rarer than it once was). 
I've been going through the Geode and 5536 specs with a fine-toothed 
comb, and so far haven't seen any write-only registers apart from the 
ones in the ISA legacy devices.

Re: ACPI: Idle Processor PM Improvements

[Jordan Crouse]

On 12/09/06 14:14 -0400, Jim Gettys wrote:
> > Alternatively, hack kernel to take control from X without actually
> > switching consoles. That should be possible even with current
> > interface.
> 
> This would require saving/restoring all graphics state in the kernel
> (and X already has that state internally).  Feasible, but seems like
> duplication of effort.  I haven't checked if there are any write-only
> registers in the Geode (though, thankfully, this kind of brain damage is
> rarer than it once was).  This then begs interesting kernel/X
> synchronization issues, of course.

We don't need any kernel output during suspend or resume.  Thus, if the VT
doesn't change, then the kernel doesn't need worry about saving or restoring 
the graphics state, and thats the way it should be, IMHO.
Whoever owns the current VT should be in charge of saving and restoring 
the registers.

So, we would need some way of indicating the "ownership" of the VT.  And
in reality, we really only to know if the framebuffer console owns it or
not, so a boolean would suffice.  In the past, I've used KD_TEXT and 
KD_GRAPHICS for this purpose.  As an example, on the Geode LX, I assume
that if the vc_mode is KD_GRAPHICS, then we don't own it, and we don't
do 2D accelerations.  If the mode is KD_TEXT then we are free to use the
2D engine.   All I needed to add ws a notifier chain to let the framebuffer
know when the mode switched, and I was happy.  I'm not sure if thats the
smartest way to handle it permanently, but it works in a pinch.

Jordan

-- 
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<www.amd.com/embeddedprocessors>

Re: ACPI: Idle Processor PM Improvements

[Pavel Machek]

On Tue 2006-09-12 14:18:05, Jordan Crouse wrote:
> On 12/09/06 14:14 -0400, Jim Gettys wrote:
> > > Alternatively, hack kernel to take control from X without actually
> > > switching consoles. That should be possible even with current
> > > interface.
> > 
> > This would require saving/restoring all graphics state in the kernel
> > (and X already has that state internally).  Feasible, but seems like
> > duplication of effort.  I haven't checked if there are any write-only
> > registers in the Geode (though, thankfully, this kind of brain damage is
> > rarer than it once was).  This then begs interesting kernel/X
> > synchronization issues, of course.
> 
> We don't need any kernel output during suspend or resume.  Thus, if the VT
> doesn't change, then the kernel doesn't need worry about saving or restoring 
> the graphics state, and thats the way it should be, IMHO.
> Whoever owns the current VT should be in charge of saving and restoring 
> the registers.
> 
> So, we would need some way of indicating the "ownership" of the VT.  And
> in reality, we really only to know if the framebuffer console owns it or
> not, so a boolean would suffice.  In the past, I've used KD_TEXT and 
> KD_GRAPHICS for this purpose.  As an example, on the Geode LX, I assume
> that if the vc_mode is KD_GRAPHICS, then we don't own it, and we don't
> do 2D accelerations.  If the mode is KD_TEXT then we are free to use the
> 2D engine.   All I needed to add ws a notifier chain to let the framebuffer
> know when the mode switched, and I was happy.  I'm not sure if thats the
> smartest way to handle it permanently, but it works in a pinch.

KD_TEXT vs. KD_GRAPHICS looks like the way to go. Just tell X you want
console back, but then don't actually redraw/switch consoles. We
probably want that on normal PCs, too... console switch for
suspend-to-RAM looks ugly.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: ACPI: Idle Processor PM Improvements

[Pavel Machek]

On Tue 2006-09-12 14:14:30, Jim Gettys wrote:
> On Tue, 2006-09-12 at 11:21 +0200, Pavel Machek wrote:
> 
> > Ok, so what is needed is message to X "we are suspending", and X needs
> > to respond "okay, I'm ready, no need for console switch".
> 
> This presumes an external agent to X controlling the fast
> suspend/resume, with messages having to flow to and from X, and to and
> from the kernel, with the kernel in the middle.
> 
> Another simpler option is X itself just telling the kernel to suspend
> without console switch, as the handoff of the display to the DCON chip
> has to be done with X and with an interrupt signaling completion of the
> handoff.  This would be triggered by an inactivity timeout in the X
> server.

Whoa... that's a hack.. but yes, you can probably do that, and I think
kernel even has neccessary interfaces already. (They were needed for
uswsusp).

> > Alternatively, hack kernel to take control from X without actually
> > switching consoles. That should be possible even with current
> > interface.
> 
> This would require saving/restoring all graphics state in the kernel
> (and X already has that state internally).  Feasible, but seems like

Hmm, save/restore graphics state from the kernel would of course be
clean solution, but you should have that anyway... what if someone
suspends without X running?

And of course you can just cheat, and not do kernel save-state on your
system.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: ACPI: Idle Processor PM Improvements

[Jim Gettys]

On Thu, 2006-09-14 at 11:18 +0200, Pavel Machek wrote:
> On Tue, 2006-09-12 at 11:21 +0200, Pavel Machek wrote:
> > 
> > > Ok, so what is needed is message to X "we are suspending", and X
> needs
> > > to respond "okay, I'm ready, no need for console switch".
> > 
> > This presumes an external agent to X controlling the fast
> > suspend/resume, with messages having to flow to and from X, and to
> and
> > from the kernel, with the kernel in the middle.
> > 
> > Another simpler option is X itself just telling the kernel to suspend
> > without console switch, as the handoff of the display to the DCON chip
> > has to be done with X and with an interrupt signaling completion of the
> > handoff.  This would be triggered by an inactivity timeout in the X
> > server.
> 
> Whoa... that's a hack.. but yes, you can probably do that, and I think
> kernel even has neccessary interfaces already. (They were needed for
> uswsusp).

Glad you like it ;-).  Dunno which way we'll go yet, though it will get
to the top of the pile to implement this fall.  I suspect we may go this
route to get going, but explore the more general solution as we get more
sophisticated power management policies and standards in place.

> 
> > > Alternatively, hack kernel to take control from X without actually
> > > switching consoles. That should be possible even with current
> > > interface.
> > 
> > This would require saving/restoring all graphics state in the kernel
> > (and X already has that state internally).  Feasible, but seems like
> 
> Hmm, save/restore graphics state from the kernel would of course be
> clean solution, but you should have that anyway... what if someone
> suspends without X running?

X knows its graphics state; it has to remember it all to know when it
has to be changed; on resume, resume can reinit the graphics state to
what the console wants/needs.

If you VT switch back to X, X can restore the graphics state to what it
remembers.

> 
> And of course you can just cheat, and not do kernel save-state on your
> system.

Yup, though it isn't clear to me I'd call it cheating.  In some ways,
what I just described to handle suspends when X is not running is really
robust and simple.  And you don't have divided responsibility for
remembering the state. Simple == good in my book.

                                  - Jim

-- 
Jim Gettys
One Laptop Per Child

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

[Jim Gettys]

On Wed, 2006-09-06 at 12:37 +0200, Pavel Machek wrote:
> Hi!
> 
> > > 2.4 and 2.6 are *very* different here. You'll probably need to optimize freezer
> > > in 2.6 a bit...
> > > 						
> > 
> > Among other problems: e.g. 2.4 did not automatically do a VT switch; 2.6
> > does; we'll have to have a way to signal "we're a sane display driver;
> > don't switch away from me on suspend".
> 
> Not like that, please.
> 
> You are using X running over framebuffer, right? So that kernel is
> controlling the graphics hardware. In such case it is safe to avoid VT
> switch.

It should be perfectly safe.

The Geode has significantly more than dumb frame buffer support, even
though it can't support 3D in hardware (we do get blit and alpha
blending, and YUV->RGB support in hardware).

We have an fbdev driver for the hardware (in fact, have to finally have
a decent driver in general, as the transfer to and from DCON controlled
display has to happen at interrupt time).  We won't be doing thing evil
in X behind the operating system's back the way most XF86 drivers do,
but very much the way display drivers supported X before the strange
notion of completely OS independent drivers without any kernel support
twisted the way XF86 drivers usually work.  Ah, back to the future
(past)....
                                        - Jim


-- 
Jim Gettys
One Laptop Per Child

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

[Pavel Machek]

On Wed 2006-09-06 11:19:09, Jim Gettys wrote:
> On Wed, 2006-09-06 at 12:37 +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > > 2.4 and 2.6 are *very* different here. You'll probably need to optimize freezer
> > > > in 2.6 a bit...
> > > > 						
> > > 
> > > Among other problems: e.g. 2.4 did not automatically do a VT switch; 2.6
> > > does; we'll have to have a way to signal "we're a sane display driver;
> > > don't switch away from me on suspend".
> > 
> > Not like that, please.
> > 
> > You are using X running over framebuffer, right? So that kernel is
> > controlling the graphics hardware. In such case it is safe to avoid VT
> > switch.
> 
> It should be perfectly safe.

Okay, but per-driver flag is wrong way to go (see the other mail).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html