Power-related question

[PCXT]

Hello
I have a question about Pyra power management system. I know, there are some pins in schematic for its different functions, but I don't exactly understand their meanings and I don't have much knowledge about power management systems especially in ARM chips.
What is possible to do in terms of power management in Pyra hardware?
- Suspend to RAM?
- Suspend to disk?
- Wake on... ? (RTC? Lid switch?)
Will it be possible to modify what happens in some low-power consumption mode? (I think about scripting it to perform emergency resuming, then suspend-to-disk to save user's data if nothing else can be done and battery is low).

 

[levi]

How does suspend to RAM even work? As I understand it, super low-power suspend by writing the RAM to disc, then spinning the disc down, stop refreshing the RAM, and put the CPU in a practically off state. In 'suspend to RAM' what do you put in the RAM to suspend, or is that a typo?

My understanding is that ARM CPUs have power modes a little like the x86 power modes, at least at a high level. The OMAP3 in the Pandora can be configured to go into a suspend mode (but keeping refreshing the RAM) on lid close, or it's the default behaviour of flicking the power switch. Note it can't do that while receiving charge, as it needs the CPU to monitor the charging process, but the Pyra has a dedicated charging chip which can charge the battery even with not CPU installed, apparently, so it may be possible to suspend on that even while charging.

A friend of mine broke the power switch on their phone years back (ARMv5 sort of time IIRC). Even that used to be able to wake on RTC by setting an alarm then turning the phone 'off'.

 

[Letalis Sonus]

How does suspend to RAM even work? As I understand it, super low-power suspend by writing the RAM to disc, then spinning the disc down, stop refreshing the RAM, and put the CPU in a practically off state. In 'suspend to RAM' what do you put in the RAM to suspend, or is that a typo?

You just described Suspend to disk. Suspend to RAM simply means that pretty much everything but the RAM refreshing is being turned off, on x86 machines this requires a rather delicate cooperation with the BIOS and the device drivers as it obviously requires some intense preparations for being able to do a clean wake up without confusing your hardware. AFAIK you don't have something quite as versatile as that on ARM, but you can already save up so much energy through more common measurements on these embedded SoCs that you wouldn't save much more energy anyway. In a way the Pandora is already doing exactly that if you trigger the power switch.

Using suspend to disk with flash memory is an awful idea...

 

[levi]

Okay, IMO then 'suspend to RAM' is a stupid name as you're not actually transferring anything to RAM (apart I guess from perhaps flushing the caches). But then it wouldn't be the first consumer focussed concept with the wrong name attached.

 

[slaeshjag]

Well, the system suspends, and state stays/goes into RAM... Makes sense to me?

 

[levi]

Indeed, if you can conflate the concepts of things staying where they are with the concept of things going somewhere else, then I'm sure lots of things make sense

 

[slaeshjag]

Well, suspend does require a partial system shutdown, with state required to resume the session saved. And it makes a good contrast as compared to hosing it all to disk, for resuming from a cold boot.

 

[levi]

Yes, thinking on it, if you stop the clock of the CPU then the registers won't be refreshed, and neither will any closely linked caches. So they'd need to be written to a preassigned known bit of RAM which is known to remain powered throughout to have any chance of being recoverable. Then you'd need a special bit of code (probably in the BIOS) which repopulates the registers and then jumps back to the old program address.

On the Pandora and Pyra we don't have this level of 'off' I think, but as letalis said, ARM cores can generally ramp down quite low in terms of current.

 

[Silent-Hunter]

Okay, IMO then 'suspend to RAM' is a stupid name as you're not actually transferring anything to RAM (apart I guess from perhaps flushing the caches). But then it wouldn't be the first consumer focussed concept with the wrong name attached.

How about calling it Suspend in RAM?

 

[PCXT]

Thanks for answers. Now I know a bit more about differences between these architectures.
Linux on x86 suspends to disk very well, and I have such configuration with my laptops for years to hibernate without loosing work or too much battery. Two of notebooks have SSDs, one from ca. 2007 in state of neglect (previous user put a Windows swapfile there) and it works very well. The thing here is to make swap partition for this hibernation and then minimize swappiness to make system not use it nearly at all.
It is not used in everyday basis. It is used if I don't want to suspend (long power-off time) and have lots of work open, so saving/uploading/refreshing/committing it would take some significant time.
About suspend-to-disk, I think that in very portable devices it may be used as a way to save user's work before complete shutdown if battery drains out.

 

[oskda]

Okay, IMO then 'suspend to RAM' is a stupid name as you're not actually transferring anything to RAM (apart I guess from perhaps flushing the caches). But then it wouldn't be the first consumer focussed concept with the wrong name attached.

'suspend to RAM' has his history. Originally not only maintains RAM powered, but also needed to store some hard parameters/memory in RAM (for example params for graphic card, sound card, even graphic memory transferred to RAM in some cases), for when the computer return from suspension, because some hardware of that time doesn't has "suspension mode".

In moderm SOC from mobile world, things are much better, as usually they are designed with very low power modes in mind, so battery last a lot of in that mode.

On other way I think "Suspend to RAM" and "Suspned to Disk" are very clear concepts (and very old, so most of us know them).

Horrible or wrong names are for example "Flight mode" (I have never used it in a plane, or it may be I want to be "offline" in moments I am not in a plane), when the correct one is "Offline mode", used by Nokia before smartphones where common. Here you see an old correct term supplanted by a newer incorrect term.