ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
darkapex1 has joined #asahi-dev
darkapex has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi-dev
baozich has joined #asahi-dev
chadmed_ has joined #asahi-dev
CoolStar has quit [Quit: Leaving]
CoolStar has joined #asahi-dev
chadmed has quit [Remote host closed the connection]
hightower2 has quit [Read error: Connection reset by peer]
CoolStar has quit [Remote host closed the connection]
CoolStar has joined #asahi-dev
opticron has joined #asahi-dev
CoolStar has quit [Remote host closed the connection]
CoolStar has joined #asahi-dev
CoolStar has quit [Remote host closed the connection]
CoolStar has joined #asahi-dev
CoolStar has quit [Remote host closed the connection]
CoolStar has joined #asahi-dev
CoolStar has quit [Read error: Connection reset by peer]
pg12_ has joined #asahi-dev
CoolStar has joined #asahi-dev
pg12 has quit [Ping timeout: 480 seconds]
<marcan>
soo the core shutdown stuff *does* work on M1... it's just that on M2 the non-retention sleep bit seems to be gone?
<marcan>
so it *always* returns from wfi instead of jumping to RVBAR
<marcan>
that's... interesting.
infinity has joined #asahi-dev
abd has joined #asahi-dev
<chadmed_>
ok something funky is definitely going on with the numbers now. before i was getting almost perfectly quadratic power scaling between pstates and now theres a linear zone and it tapers off at the top????
<chadmed_>
issuing WFI suspend the laws of physics on TSMC N5 it seems
<marcan>
chadmed_: the higher pstates do not increase the voltage, so I would expect linear power on those
<marcan>
I suspect the reason they do that is that they can guarantee sufficient vcore for those iff there is low vdroop from the other cores
abd has quit [Ping timeout: 480 seconds]
<chadmed_>
yeah that makes sense, but i still find it odd that the data has changed so much. my methodology is exactly the same
<chadmed_>
ill do some more digging
<marcan>
re deep sleep, I think what's happening is that on M2 full shutdown only happens with proper full cluster shutdown, and that isn't working properly when I do it (but *is* when macOS does it)
<marcan>
because when I shut down the cores after a guest sleep event, MMIO for the cores goes away (there's a bit for that even, which we both set)
<marcan>
but when I shut them down without macOS involved, they don't
<marcan>
so something else macOS does is allowing the clusters to go into deep sleep
<marcan>
I imagine trying to bring them back after *that* would end up in RVBAR
darkapex1 has quit []
darkapex has joined #asahi-dev
salimterryli has quit [Remote host closed the connection]
cylm has quit [Ping timeout: 480 seconds]
<jannau>
the drm suspend splat is silly. the suspend/resume helpers disable/enable hpd polling unconditionally. our connectors are setup in a way which excludes polling so we do not init it
<jannau>
a quick grep suggest though that it is universally initialized
<jannau>
not sure if polling would help us with dp-altmode but I don't think we can use it since our connectors are functionally tied to dcp
salimterryli has joined #asahi-dev
<jannau>
we don't have any information on the connected display unless dcp is connected to it
<nicolas17>
marcan: your fedi post said only macOS 13 has the charge limiting thing, but I'm on macOS 12.6.5 and the battery icon on the status bar says charging is suspended because I rarely use it on battery
<nicolas17>
(been plugged in for days and it's at 92%)
<marcan>
firmware-based autonomous chage limiting is only on macOS 13
<nicolas17>
ah so this is being done by macOS?
<marcan>
yes
<marcan>
always was
<marcan>
they use (one set of) the binary charge controls
<marcan>
(same one the linux kernel-side limiter does)
<nicolas17>
right, so the OS is telling the SMC "stop charging", while in macOS 13 it can say "stop charging when you reach 80%"
<nicolas17>
I see now
<marcan>
I don't actually know if macOS 13 *uses* that feature, all I know is it's in the firmware
<marcan>
I would sort of expect it's used in suspend at least
<jannau>
or all the charge control daemons written for asahi linux. are we at 3? I lost the count
<marcan>
no, those use a different set of charge controls :)
<marcan>
(there are several)
<marcan>
the one for optimized battery charging has an auto safety trip at 50% where it does autonomously go back to charging, presumably to prevent the battery from outright dying in sleep mode
<marcan>
the ones exposed to userspace in sysfs have no safeties, you can ask it to discharge and it will happily run down your battery to emergency shutdown even while plugged in
<nicolas17>
if I close the lid, for hours... in what state is macOS? is it in something closer to Linux's s2idle or s2ram?
<marcan>
that's... a good question
<marcan>
well, it depends on config
<marcan>
at least on battery with default config, it's s2ram, but I suspenct macOS still periodically wakes up to do stuff and that's how it implements charge control
<marcan>
(among other things because there have been multiple macOS issues with suspend battery drain, probably caused by such wakeups)
<nicolas17>
it's always responsive to network, but I *know* Apple has separate tricks for that (even on Intel), so it's hard to tell when it's really asleep
<marcan>
the wifi implements ARP/ping/mDNS directly on the wifi card, so yeah, they're cheating
<nicolas17>
yeah and there's also the "sleep proxy"
<marcan>
yeah
<nicolas17>
"I suspenct macOS still periodically wakes up to do stuff" I think this is even done on Intel, called "powernap" in marketing and "dark wake" internally
<marcan>
yeah
<marcan>
and the whole s2ram thing would've been way more critical on intel since s2idle on intel is... not great
<marcan>
which is probably why it's designed this way
<marcan>
I think if macOS had been designed around AS from the get go they probably wouldn't have bothered with s2ram, and I still think there's a good chance we can get s2idle to be just about as good
<marcan>
s2idle isn't just "be idle", you still put all devices into low power mode, we save about 1W over plain system idle right now and I'm sure there's more we can do
<nicolas17>
iPhones have "deep sleep", not sure how that compares to laptop s2ram but afaik they fully power off the main CPUs
<marcan>
ultimately the only difference with s2ram is that in s2ram the CPUs go into effectively shutdown and the RAM goes into self-refresh... but there's no reason that wouldn't be achievable with the CPUs in deep sleep if you manage to quiesce all RAM traffic
<marcan>
nicolas17: the ACCs have "deep sleep" but it's not yet clear how much power it saves over CPU deep idle (which also powers down the individual cores)
<marcan>
that's what I enabled in the cpuidle stuff the other day
<marcan>
you can tell this has all been improving with newer hardware from the xnu dumps
<marcan>
back in the day you'd have needed s2ram for good battery
<marcan>
these days the CPUs power down any time they're idle
<nicolas17>
hmm do M* SoCs even have the recfg engine?
infinity has quit [Quit: Connection closed for inactivity]
Dementor has quit [Read error: Connection reset by peer]