Resume from Power Off

On resume from what Samsung calls Power-OFF, the on-chip ROM
boot
brings in the 4K
block from NAND to the 4K Steppingstone RAM. The present
code for start.S checks
to see if this is a resume (rather than a cold boot). It can
tell this
from GSTATUS2 and
GSTATUS3 which are zeroed on a cold restart and hold their
values in
the Power-Off
state. The present code jumps to the memory location
previously saved
in GSTATUS3
by the code which put the machine into the sleep state
(which I
haven't yet located).

Since these two 32 bit registers are the only resource
available for
resume, it seems a
bit wasteful to use half of them to store a simple vector.
Why not
just store this in
a fixed location in the sleeping SDRAM(like the reset
vector) and
resume from there.
This leaves the full 64 bits available for other uses e.g.
state bits
and counters.

Very little power is consumed by waking up the CPU every
second or so, bringing
in the steppingstone code, and checking whether we should
actually
resume. This is
especially true if we keep the SDRAM in power-down before we
decide to actually
resume. One real use for this (at least on GTA01) is to
examine the Bluetooth
wakeup pins which are on ordinary PIO's and cannot be used
to wakeup the CPU. It
appears that there is a bit of room in this 4K block for
some low
level resume handling like
this.

If more extensive resume processing is necessary, the SDRAM
can be taken out of
power down self-refesh and the further processing can be
done by ram based code
resulting in either a return to power-off or a full resume
of the kernel.

This approach could also be used for some limited processing
of the GSM stream
in the "RESUME" context either prior to or before
resuming the kernel.
This could
result in an immediate capture of some data that might
otherwise be lost.

Just my $0.02

Cheers

Hi Wally!

On Thu, Aug 23, 2007 at 08:47:30PM -0400, Wally Ritchie
wrote:

> Since these two 32 bit registers are the only resource
available for
> resume, it seems a bit wasteful to use half of them to
store a simple
> vector. Why not just store this in a fixed location in
the sleeping
> SDRAM(like the reset vector) and resume from there. 
This leaves the
> full 64 bits available for other uses e.g. state bits
and counters.

Because this is the standard way of how suspend/resume works
in the
mainline linux kernel s3c24xx kernel tree.  And we generally
try to
follow those existing mechanisms and not deviate too much,
unless we
have a very good reason/requirement to do so.

If you feel that this standard suspend/resume way should
change, I
recommend you talk to the S3C24xx architectuure maintainer
(Ben Dooks)
and/or the arm-linux-kernel mailinglists.

Sure, we can do some device specific hacks to squeeze more
into those
registers.  But at the moment we're still in the way of
getting our
product working at all.  "Premature optimization is the
root of all evil".

Thanks for your suggestion, though.

Cheers,
-- 
- Harald Welte <laforgeopenmoko.org>          	
       http://openmoko.org/
============================================================
================
Software for the world's first truly open Free Software
mobile phone