can openmoko be in suspend and keep the backlight on?

[Joerg Reisenweber]

[Nils Faerber Mi  25. November 2009]:
> Lars-Peter Clausen schrieb:
> > Timo Juhani Lindfors wrote:
> >> Hi,
> > 
> >> just out of curiosity, is it possible to suspend the main cpu but
> >> still keep the display backlight on? (I have no practical use for
> >> this, it would be useful only if we could keep screen contents
> >> visible too).
> > 
> > Yes it could be done, but whould be quite hackish. For screen content
> > the glamo needs to be running too.
> 
> And glamo gets the contents from where? The DRAM?

I think glamo has its own RAM


> The DRAM cannot go 
> into self-refresh and thus the CPU suspend mode only saves very little
> power.

Don't know if glamo can work with DRAM in sleep mode.


> Keeping the display kind of on is a feature of certain displays that
> have their own display controller, where you can do partial updates, the
> controller can disable parts of the display RAM or updates, etc. while
> the CPU can be almost or fully sleeping. This is what IMHO Nokia does
> with most of their S60 smartphones. Quite different hardware architecture.
> What we can also backward guess from what we know how the N810, N800 and
> 770 work, the Nokia smartphones, except for the new N900, 

Why do you think N900 is different?


> will do very 
> aggressive downscaling of CPU frequencies and features. 

Actually they do zero clock.


> As far as I know 
> the tablets do almost never go into what we know as "suspend to RAM".

Maemo never does this by default. You can force it and it even kinda works


> They are always ticking but very very slowly.

No, they almost never tick at all, just sitting there static and waiting for 
an interrupt to happen which cranks up clock in almost zero time.


> This has the dramatic 
> advantage that the CPU can be active all the time and can do e.g. screen
> updates from time to time without having to go through a resume-suspend
> cycle. 

Well, they need to set DRAM to sleep mode as well. That's a rather quick 
action though


> Very clever. But this requires heavy CPU support which most 
> smartphone CPUs that run Linux lack, like S3C we are using in the
> Freerunner or the OMAP3 that is now used in the Nokia N900.

OMAP3 has same cute SmartReflex™ power management and zero clock as the OMAP2 
in the NITs
see 
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12796&contentId=36505

 
> This also makes a lot of other uses pretty hard, like "always on"
> becomes a real issue. Every time a potentially interesting network
> packet arrives the CPU has to be woken up and is forced through the
> resume-suspend cycle, eating lots of power. The kernel currently lacks
> infrastructure for a "almost awake" state that would saveus from having
> to through all resume functions before finding out that the resume was
> actually not as interesting as it looked.

Yes, a fast early re-suspend is essential for those usecases


> For the HTC G1 (Android) I found that they use a different scheme - they
> simply delay the suspend. After pressing the power button the display
> goes off immediately so the user gets the notion of suspend but the
> device stays awake for some additional time, especially if WiFi is used.
> If there is nothing happening for a certain amount of time, I think
> something like 5 minutes, it really suspends, switching off the WiFi and
> handing internet connection over to GSM/3G. This again is able to
> wake-up the CPU upon certain network events.
> 
> Back in the iPaq days the guys at CRL implemented something similar for
> battery charging, I think it was for the iPaqs 3870 and later, since
> there the CPU controlled the charging. When gone into suspend, what
> should happen? Stop charging? So they suspended but set a timer to
> expire every, say, ten seconds which would wake up the CPU. If the
> wakeup reason was this special timer then only the charging logic got
> triggered and the kernel went into suspend again directly afterwards.
> The user would not notice this at all.

basically we could do same on FR (except we don't need kernel or userland for 
charging)


cheers
jOERG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/hardware/attachments/20091126/22f9b302/attachment.pgp