Did someone say my name? :D

It's not exactly that "nobody is working on it". There was some initial work on suspend done already, you can flash a different ATF branch and get it to suspend and resume just fine - it's not used by default as currently you have to choose between suspend or DRAM frequency scaling. It's just not the top priority right now, because we're focusing on runtime power management and other promised features like DisplayPort first and there are still some things to do before it actually makes more sense to go back to suspend.

If we worked on suspend instead of runtime PM for the past half a year, we would probably now have 100h+ suspend time that would go down to 2-3h as soon as you kept ssh connection open or did anything else that would prevent it from suspending. Or even actually used the phone.

Also, just being able to suspend is one thing; but there's a ton of work still needed to properly utilize suspend from userspace, so you can still keep things like IM or e-mail notifications working transparently. The less power the phone uses when not suspended, the better - at this moment, suspend would be just a band-aid.

I'm looking forward to your product succeeding, so please don't take this comment antagonistically.

Have you considered how much good press the suspend time got the Pinephone? And how it is one of the key features people talk about - as in, how long the phone will last? And how in these threads people keep asking you about it? And how you could have that good press?

From your comments I worry you are only looking to release such a feature when you've fully implemented every system involving it. I realise this is very easy for me to say from a backseat position, but maybe bump it up the release schedule, and then those that do have librem 5s could at least have a 103 hour tablets that sat in their pockets, not a 5 hour paperweight that sat on their shelves until they wanted to charge it and play with it again. If nothing else, it will completely change the y scale on your bar charts.

I've been very much enjoying the updates around the librem 5 and hope everything goes well for your product.

We have a limited workforce and we have to prioritize. I'll take a reasonably working phone that easily works for a full work day on battery (like the one we have right now) over a phone that sleeps for many hours but burns through the battery fast as soon as you want it to actually do anything.

Focusing on suspend time first may be worth it marketing-wise, but in my personal opinion that would be kinda deceptive.

This is a reason why working with the community is better than doing it all yourself.

Madness. It should be priority #1 now that the phone calls are working.

It needs a full-stack integration to work properly, it's an immense amount of work. The Linux kernel is great at lots of things, but being good at scaling back power usage is not one of them. You'd want to be able to have timers that will wake the machine up form suspension that application developers can use and throttling of radios. The device has to be suspended, but you should still be able to receive calls. MacOS does this impressively well (try pinging your Macbook as it's slowly nodding off, and see the response time increase). Better still, you can ping a macbook over WiFi that's completely suspended - SSH and other services won't work, but the kernel will still be there and do some I/O - this requires some kind of a power-level aware system in the kernel that can coordinate with device drivers and have userspace interfaces for registering applications that might want to receive data when the machine should be suspended. The designwork required to achieve this with Linux and it's ecosystem is far more than the capable but small team at Librem can reasonably achieve, not because the team is small, but because this would require a lot of coordination between different upstreams.

It's definitely a huge amount of work... there are many wrinkles to it, eg, if integrated to the radio firmware, it can do things like wake on specific network traffic and then go back to sleep if it understands the nature of the wake reason only extended to handle that network traffic on the cpu. But then if eg, the ssh session has keepalive enabled, there has to be infrastructure to schedule doing that coupled with another limited-scope wake and go back down afterwards.

Last time I worked on this kind of thing there was great kernelside suspend support that works, but in terms of userland there was no generic linux arrangements for this kind of finegrained management of it.

I also understand the point that for users, atm they just see no ability to defer when they will use the phone while it's still needed to receive calls, which is fatal. It seems properly solving this needs a new, separate userland project somewhere.