07:52 <kholk> for system sleep (cpus going down, etc), MT8173 and 8173C should be handled the very same way AFAIK - so that's pretty strange.

07:52 <kholk> that'd be the same for MT6795 as well, and I can assure you that one sleeps like a baby :-)

07:55 <mps> kholk: I use s2idle on mt8173, that works stable

08:02 <kholk> hmm.. but still, I don't see why suspend deep shouldn't still work fine

08:03 <mps> well, I tried to bisect but didn't found anything

08:03 <kholk> if it was a firmware (deeper sleep states management) issue, I think s2idle would also fail, as we're still requesting the same states

08:03 <kholk> so that must be "a kernel thing"

08:04 <mps> I remember that deep sleep worked in some old 5.x kernel series but forgot exact version

08:04 <kholk> I'm not sure what's happening, because deep should be .. deeper .. than s2idle....

08:05 <kholk> yeah well, "some old 5.x" kernel would be too old to really try to bisect

08:05 <mps> yes, deep is deeper ofc

08:05 <kholk> yeah and I really don't get why deep should use more power (-> should make something fail and disallow some sleep state) than s2idle...

08:06 <kholk> because then all of the suspend callbacks are still being called in s2i

08:06 <mps> ime, s2idle use more power

08:06 <kholk> for device drivers

08:06 <kholk> the only thing that comes to mind is something with the ChromeOS EC

08:07 <mps> for example on apple silicon only s2idle works and it drains about 10-15% battery over night

08:07 <kholk> I had something vaguely similar with MT8195, but again vaguely - the EC would complain and resume the system immediately *unless forced to not resume it*

08:07 <kholk> but if you force not to resume the system, it's going to keep the CPU awake anyway and drain your battery

08:08 <kholk> .......but again, you must *force it* to do that otherwise it won't... (hence why I said "vaguely similar")....

08:08 <mps> right

08:08 <kholk> well, apple silicon is different, as much as qualcomm, rockchip, etc are :-)

08:09 <mps> on macos battery drain over night is negligible

08:09 <kholk> in any case... to resolve the MT8195 issue, that was about a clock missing from a LARB or a power domain (don't remember)

08:09 <kholk> that would make it impossible to correctly turn off one of the LARBs for VCODEC before sleep

08:10 <kholk> hence it was staying in this kind of error state, and the SoC would go crazy about it, EC would detect that and disallow full sleep

08:10 <kholk> it could be possible that something like this is actually happening on 8173... I mean, I don't feel like excluding such possibility

08:10 <mps> do you ec_tool compiled to check internals

08:11 <kholk> oh regarding that 8195 thing, I didn't need any special tool

08:11 <kholk> I used the SuzyQ

08:11 <kholk> there's an EC console, and the EC clearly SCREAMS a big NO over the UART

08:12 <kholk> there's also a way to get the EC logs from Linux, without any uart-blahblah-cable as far as I remember

08:12 <kholk> (sysfs or debugfs)

08:12 <kholk> you can `cat somewhere/something` and get it like that

08:12 <mps> I use ec_tool to examine and control EC

08:12 <kholk> (sorry about the somewhere-something, I don't really remembed what)

08:12 <kholk> *remember

08:13 <kholk> well yeah, that's another way of doing things :-)

08:13 <kholk> (probably better than mine)

08:13 <mps> for example with ec_tool I set max charge current

08:14 <kholk> yeah, I'm sure you can do "all the cool stuff" with that one :_)

08:17 <mps> iirc, suspend2ram worked in 5.9 or even in 5.12

08:19 <mps> #linux-mediatek.2021-07-14.log:2021-07-14 20:46......... mps| nice, with kernel 5.13.2 now elm chromebook (mt8173) suspends fine but resume doesn't work. it crashes