It just came to my mind that it’s not entirely true - there has been some work on suspend done in the past. It needs a different ATF branch than the one we’re using right now - I know that it worked for me in the past with an older kernel (haven’t tried with recent ones). However, as it is right now it breaks the DRAM frequency scaling, which makes the device use quite a lot of power when not suspended, so that’s a rather poor tradeoff and is the reason why it’s not used at the moment. It also needs some adjustments of the device tree to make sure the modem stays on during suspend (this one shouldn’t be hard though).
You should be able to use s2idle already if you want to make sure your cores stay idle, although it seems like there’s something buggy in the USB path as suspending the USB core currently makes it consume slightly more power than when it’s on 
Therefore we currently don’t suspend it at runtime at all, but it gets suspended at s2idle which makes it consume a bit more power than when not suspended. Fixing that is part of runtime power management work.
So, the first step to make s2ram a reality is to produce one common (and preferably upstreamed) ATF branch that works with both DRAM scaling and suspend. We want that to eventually happen for other reasons as well, so we’ll likely get there at some point (this is also something that NXP itself expressed interest in working on at some point, so it may even happen without our involvement giving us more time to work on phone specific stuff :)).
I disagree. It’s not just a unspecified “optimization work”, there are clear and tangible things still to be done in runtime PM - like the USB core not being suspended that I mentioned above, or DP core never suspending after the first use etc. This directly influences suspend as well, since the kernel is using the same code to shut the devices off. Since in suspend everything gets turned down at the same time, there are more opportunities to make some hacks and broad assumptions that won’t hold when suspending peripherals selectively (Librem 5’s power paths are pretty complex for a mobile phone). Therefore I believe that making sure the runtime PM is in good state before putting the focus on suspend is a better approach, since good runtime PM state makes the work on suspend much easier; while going the other way around (focusing on suspend first) may make further runtime PM work harder.
I do understand that from the user perspective it may be better to have at least some form of suspend available earlier - but that’s short-term thinking. We want to maintain software for this device for years as close to mainline as possible, so we’ll naturally gravitate towards long-term thinking and give things like ease of maintenance much greater weight than some other phone manufacturers on the market.
