The Suspend Functionality

[Vitel]

According to the latest firmware status from EvilDragon, the suspend to RAM is not working yet.
This is a very serious issue for me.

I see the developers are trying to make Pandora's UI better in different aspects: menus, pnd, skins, wallpapers, etc.
This is useful for many many users, but not for me. I'm not gonna use the default firmware at all. I'm planning to install the Gentoo distribution (Neuvoo project).
However, I guess that everybody wants to use s2ram functionality regardless of the firmware version. Maybe it's better to make s2ram work first rather than UI beauties...

So what is more important for you - all these these UI tweaks or s2ram?

 

[Near_Kstor]

For now, I'll stick with UI.
The main reason for this is that I intend to turn it off when I'm not using it.
And, if I am to pause whatever I'm doing, I can turn off the screen and close the lid. Surely it will already save a lot of power...

Fact is: having a great UI from the very beginning will be a +1 in all Pandora Reviews around the internet, which can bring more users to the second batch, therefore more money to be invested in our beloved OpenPandora project.

 

[Twiitcher]

GUI for me = Useablilty, i.e. I'm not a cmd line guy. S2ram is a feature = longer battery life.

Good GUI / no s2ram = I can use it but it will use more battery faster.......
Bad GUI / s2ram = I have limited use but I can look at it sit on the desk saving power longer...
No contest.

Twiitcher

 

[tristan.clark]

According to the latest firmware status from EvilDragon, the suspend to RAM is not working yet.
This is a very serious issue for me.

I see the developers are trying to make Pandora's UI better in different aspects: menus, pnd, skins, wallpapers, etc.
This is useful for many many users, but not for me. I'm not gonna use the default firmware at all. I'm planning to install the Gentoo distribution (Neuvoo project).
However, I guess that everybody wants to use s2ram functionality regardless of the firmware version. Maybe it's better to make s2ram work first rather than UI beauties...

So what is more important for you - all these these UI tweaks or s2ram?

It will. As with some much of this project to date its going to require more patience..... Painful I know

 

[CoMiKe]

According to the latest firmware status from EvilDragon, the suspend to RAM is not working yet.
This is a very serious issue for me.

I see the developers are trying to make Pandora's UI better in different aspects: menus, pnd, skins, wallpapers, etc.
This is useful for many many users, but not for me. I'm not gonna use the default firmware at all. I'm planning to install the Gentoo distribution (Neuvoo project).
However, I guess that everybody wants to use s2ram functionality regardless of the firmware version. Maybe it's better to make s2ram work first rather than UI beauties...

So what is more important for you - all these these UI tweaks or s2ram?

Even if they spend more time trying to get suspend to RAM to work, it won't be available on lauch.

As skeezix explained in this post, suspend to RAM won't work until ALL Pandora device drivers have support for suspend/resume, and that would take A LOT of time to fix.

Besides of that, only a few people do have enough knowledge to commit the changes needed on device drivers, so there's no reason for people working in the UI to stop doing that and try to fix the drivers in a useless effort.

 

[mali]

It would be really nice if someone with in depth knowledge(preferably one of the OP Team) could explain ARM power consumption and what missing suspend means in case of Pandora. I own an N800 and it lasts for weeks without suspending.

 

[WizardStan]

Suspend to RAM should give you weeks (if not months) of "off" time before running out of juice.
Simply turning off the screen, wifi, and idling all the way down should give us a couple days between recharges, I suspect. This is something that can be done, I believe.
So in order for it to be always on, it needs to be plugged in every few days. For now. I'm ok with this. If you aren't, then (I really hate saying this) you bought the wrong product, or at least at the wrong time; cancel your order and wait for the second batch when this (and many other problems) will have been fixed, or get something more commercial. So long as the hardware is good, the software will follow. Eventually.

 

[kloplop321]

I honestly like the ability to close a device and not have to worry about power consumption more than gui decorations(themes, backgrounds, etc)
Though since the sleeping procedure calls for a couple hardware instructions, I would think that the more hard-core developers should be focused on that more than themes, backgrounds, log in prompts which can be made by the normal community(as you can see in ED's thread)

 

[Vitel]

suspend to RAM won't work until ALL Pandora device drivers have support for suspend/resume

There is a well known workaround for such issues: unload driver on suspend and load it back on resume. TuxOnIce allows us to do this trick. For example, I have some USB-related troubles with my ThinkPad X200:

### modules
UnloadModules ehci_hcd
# UnloadAllModules yes
# UnloadBlacklistedModules yes
LoadModules auto
# LoadModulesFromFile /etc/modules

Yes, this is a dirty trick, it obviously increases the resume time, but it's definitely better than nothing.

 

[hobbyman II]

gosh! workable solution in under 50 minutes from original post, isn't open source wonderful? :lol:

 

[Wolfsclaw]

Simply turning off the screen, wifi, and idling all the way down should give us a couple days between recharges, I suspect. This is something that can be done, I believe.

Would this be equivalent to pushing the top Standby button on the iphone/ipod touch? If so, I'm pretty happy with this. I usually just plug my ipod in every second night, almost never rebooting, at least if i haven't forgotten about recharging or some software issue pushed me to do this.

 

[WizardStan]

gosh! workable solution in under 50 minutes from original post, isn't open source wonderful? :lol:

Not really. Suspending and waking up a driver is not the same as unloading and reloading it.
Consider wifi. When you load it, it loads a config file, and it uses that config file to figure out what network to connect to and how, or whether to connect at all. If you've been wandering, and manually connected to a different network, suspend/resume will remember that different network and will reconnect with all the same parameters. An unload/reload will forget those parameters, leaving you with no network connection.
If you unload/reload the sound driver, it probably disconnects all sound streams. Unless the program is smart enough to reconnect the sound stream, on wakeup you'll no longer have sound in whatever program was running. Suspend/resume the sound module should save the state of all sound streams, and automatically reconnect them when it comes back, so the program itself doesn't need to worry about it.
These are just two things I can think of off the top of my head, but you can imagine how other modules might not work right. How would the video driver handle being reloaded? What about the power management chip? If the OS is in control of it, how can we be sure that unloading and reloading the module won't confuse it and cause problems with charging?
How each module behaves under different circumstances is exactly why the suspend isn't an easy thing to do.

 

[notaz]

Not all drivers can be built as a module, some can but will not reload properly.

 

[atomicthumbs]

As long as it turns off when I close it, I'm fine with suspend not working for now. I waited for my GP2X to start up; I can wait for my Pandora to start up (until January).

 

[Polossatik]

My N800 last indeed for a week or 2 when "idle" (no wifi/BT), so I do not see that this would (in the log run) not be possible for the pandora.
there a plenty of people thinking about this http://lwn.net/Articles/318154/ and you can always have a look at how maemo does stuff (a lot of power managment is still close source, but this might be usefull to check out)

The only main "advantage" of suspend (vs boot) would actually be that all apps stay open, which is of course nice. However I think this could be for most apps easily overcome by having some kind of "startup" launcher or widget style stuff that is automatically loaded.

The boot time (once the boot is optimized) should be IRL quite close to the time need to resume of suspend.

 

[Vitel]

Consider wifi. When you load it, it loads a config file, and it uses that config file to figure out what network to connect to and how, or whether to connect at all. If you've been wandering, and manually connected to a different network, suspend/resume will remember that different network and will reconnect with all the same parameters. An unload/reload will forget those parameters, leaving you with no network connection.
If you unload/reload the sound driver, it probably disconnects all sound streams. Unless the program is smart enough to reconnect the sound stream, on wakeup you'll no longer have sound in whatever program was running. Suspend/resume the sound module should save the state of all sound streams, and automatically reconnect them when it comes back, so the program itself doesn't need to worry about it.
These are just two things I can think of off the top of my head, but you can imagine how other modules might not work right. How would the video driver handle being reloaded? What about the power management chip? If the OS is in control of it, how can we be sure that unloading and reloading the module won't confuse it and cause problems with charging?
How each module behaves under different circumstances is exactly why the suspend isn't an easy thing to do.

That's right, but... I'm not saying that this workaround is a panacea for all troubles. We definitely need to have s2am support in power management driver, keyboard, lcd, etc. These are the P1 drivers. However, waiting for ALL driver to work properly with s2ram may take years or may not happen at all.
Regarding the issues you're pointing to. WiFi interface should be started from scratch anyway. This is just a correct way in general. Consider you're using dhcp to obtain client IP - it may be captured by another device at the time of resuming.

Nevertheless, all these issues can be handled by TuxOnIce (and userspace workarounds in general): stop your music player on suspend and launch it back on resume (OnSuspend/OnResume params in TOI config). The same approach for wifi:

### network
DownInterfaces wlan0 ppp0
UpInterfaces auto

 

[Vitel]

The boot time (once the boot is optimized) should be IRL quite close to the time need to resume of suspend.

Wrong. It takes seconds to resume and minutes to boot up (don't forget about apps you may have running).

 

[WizardStan]

That's right, but... I'm not saying that this workaround is a panacea for all troubles. We definitely need to have s2am support in power management driver, keyboard, lcd, etc. These are the P1 drivers. However, waiting for ALL driver to work properly with s2ram may take years or may not happen at all.
Regarding the issues you're pointing to. WiFi interface should be started from scratch anyway. This is just a correct way in general. Consider you're using dhcp to obtain client IP - it may be captured by another device at the time of resuming.

Nevertheless, all these issues can be handled by TuxOnIce (and userspace workarounds in general): stop your music player on suspend and launch it back on resume (OnSuspend/OnResume params in TOI config). The same approach for wifi:

### network
DownInterfaces wlan0 ppp0
UpInterfaces auto

Aye, good points all. The point I was making though is that we shouldn't be suggesting that something is simple. It could be that simple, but until people actually try some stuff, we won't know. It's times like this that having money (and time) for a dedicated QA team with experience in white box testing would come in handy.
...
I think I just figured out what to do with those 103 boards. People don't mind waiting another month or two for delivery, do they?

 

[Alec]

I can't vote on this because not working on the UI won't really make suspend arrive faster. Working on the UI is completely different from kernel hacking.

 

[Aninhumer]

The boot time (once the boot is optimized) should be IRL quite close to the time need to resume of suspend.

Wrong. It takes seconds to resume and minutes to boot up (don't forget about apps you may have running).

I'm pretty sure it doesn't take "minutes" to boot.
Significantly longer than a resume, but were talking an actual wait vs near instant.