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
baozich1 has joined #asahi-dev
baozich has quit [Read error: Connection reset by peer]
baozich1 is now known as baozich
nsklaus has quit [Quit: ZZZzzz…]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
maria285474 is now known as maria
user982492 has joined #asahi-dev
gabuscus has quit []
gabuscus has joined #asahi-dev
salimterryli has quit [Remote host closed the connection]
nicolas17 has quit [Quit: Konversation terminated!]
pg12 has joined #asahi-dev
pg12_ has quit [Ping timeout: 480 seconds]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-dev
salimterryli has joined #asahi-dev
<marcan> chadmed: now that it's fully charged, I'm getting 22 hours screen off idle (with no peripherals connected) on t6000, so something is wrong if you only get 11h
<marcan> 35 hours in sleep mode
<marcan> (s2idle)
<marcan> the MCC stuff should be at the *lower* level right now, if anything what macOS does is boost it when some cores are fast, but I never saw a difference in benchmarks so I didn't bother
<chadmed_> marcan: at work but did some sneaky ssh, battery currently at 60% with ~11 hr left in it
<marcan> that sounds more like it
<chadmed_> so mustve just been me doing stuff around the desktop with the screen on this morning
<chadmed_> pretty good
<chadmed_> power draw is about 3 W with the screen off
<marcan> yeah, 3.2W here
<marcan> 1.9W in s2idle
<marcan> so at least *some* device PM is helping significantly already :)
<marcan> need to get more of that in
<chadmed_> you havent got the EAS stuff merged in yet right
<marcan> nope
<chadmed_> might be fun to do some desktop use type testing to see what difference that makes with cpuidle
<marcan> yeah :)
<marcan> got a branch?
<chadmed_> https://github.com/chadmed/linux/tree/eas-v2 only needs the latest commit on top of 6.2 because that silly regulator stuff got fixed
<chadmed_> those values should be accurate now, all that interactivity hitching goes away with menu governor and cpuidle
<marcan> heh, now that we have cpuidle we're going to need microwatt numbers for the higher pstates too ;)
<marcan> (the #if 0'd out ones)
<chadmed_> should they Just Work(tm) now with the #if 0 removed or is there more work to get htem to actually hit
<chadmed_> i can test tonight but i was gonna get numbers for t6020
<marcan> I think so yeah
<marcan> you might need to explicitly enable boost/turbo in sysfs
<marcan> might want to play games with core pinning to make sure all but one core in a cluster really are idle, for benchmarking purposes
<marcan> (otherwise boost won't engage)
<marcan> if cur_freq says it's hitting them then it's hitting them (that comes from feedback from the hardware)
<marcan> chadmed_: also the power/exit latency numbers in the cpuidle stuff are BS, I should actually measure that
<marcan> macOS doesn't actually do any cpuidle handling, it just uses auto mode and lets the CPU decide with its own heuristic :)
<marcan> but I assume linux cpuidle can do better (if given appropriate data)
<chadmed_> if we can somehow reduce the number of interrupts fired by the touchpad the pcores would barely ever wake up at the desktop
<marcan> yeah, I need to look into that again
<marcan> should be better on t602x already with MTP though
<marcan> but we can reduce that one even further by supporting memory buffers
<marcan> (which we don't right now)
<marcan> actually no, that wouldn't reduce IRQs, just MMIO traffic
<marcan> since the FIFO is huge enough to whole whole packets, no need for IRQs
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
abd has joined #asahi-dev
<jannau> I'm seeing 4.8W here on t6001, screen off, nothing connected, logged in via ssh
<jannau> 11h idle time from 85% charge state
<jannau> doesn't wake up from suspend
<jannau> 4.2W in s2idle with HV and no_console_suspend
<jannau> wakeup of course works in this config
cylm_ has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
<jannau> and why is my hw uart broken? usb-pd reset works, looks like the device is not sending any data
<jannau> and the studio is again in the state where the aqantia pcie link doesn't come up
kedde2 has joined #asahi-dev
<jannau> serial works if I let m1n1 boot and connect the usb-c afterwards
<jannau> unfortunately no hints why wakeup is broken on the serial
drubrkletern has quit [Remote host closed the connection]
kedde3 has joined #asahi-dev
raveling has joined #asahi-dev
kedde2 has quit [Ping timeout: 480 seconds]
abd has quit [Ping timeout: 480 seconds]
chadmed_ has quit [Quit: Page closed]
<jannau> any volunteers for teaching powertop to handle clusters correctly?
<jannau> looking at the idle stats it looks like linux keeps one performance core not idle
raveling has quit [Ping timeout: 480 seconds]
<jannau> but I'm seeing now 6.3W power use with screen off
<jannau> switching from sddm to a vt with power logging reduces the sys power use from ~10.5W to ~8.5W
CoolStar has quit [Ping timeout: 480 seconds]
CoolStar has joined #asahi-dev
bps has joined #asahi-dev
<marcan> jannau: dynamic backlight. VTs are dark.
<marcan> the system pstate stuff I did might be breaking things on t6001, it was a bit dodgy (that's why there's that min pstate thing, lower hangs for me)
<marcan> it also breaks DCP if left enabled (not enough bandwidth for the display presumably)
<marcan> that's why I do that in noirq, when everything else should be shut down
<marcan> try disabling that driver and seeing if that helps, or removing either of the named reg entries (which will disable that side)
<marcan> apple only touches DCS on t6001, not fabric, I completely guessed that one based on t602x (and I think they only do it when going into real suspend)
bps has quit [Read error: Connection reset by peer]
bps has joined #asahi-dev
raveling has joined #asahi-dev
bps2 has joined #asahi-dev
bps has quit [Ping timeout: 480 seconds]
bps has joined #asahi-dev
bps2 has quit [Read error: Connection reset by peer]
<jannau> marcan: I'm seeing following smc splat on boot with APPLE_SMC and various MACSMC options built-in: https://gist.github.com/jannau/953f3c37056dab2ce935543e42f32ed7
<marcan> jannau: obvious race
<marcan> however, we only enable notifications *after* the init
<marcan> so something is dodgy
<marcan> jannau: can you print the rtkit message?
<marcan> actually wait, if the hid stuff is already probed there's no way that is the race
<marcan> ohh wait yes obvious race
<marcan> okay
<jannau> wakeup is even broken without APPLE_PMGR_MISC
<marcan> okay, that's weird
<jannau> power button works before suspend
<marcan> jannau: pushed fix for the smc thing (only build tested)
<marcan> jannau: is it the cpuidle thing breaking wakeup? I don't think we changed anything else :/
<marcan> unless it's just another pmgr borkage
<chadmed> almost 12 hours off charge and only 60% of the battery gone
nyilas has joined #asahi-dev
<jannau> wakeup still broken with APPLE_CPUIDLE disabled
<jannau> I do not use s2idle so the lat time I tested was before the mailbox rewrite. strange though that it works in the HV
<marcan> this is what machine exactly?
<marcan> does the HV log any dangerous PMGR hooks during a suspend cycle?
<marcan> could also be a race/timing issue somehow
<_jannau_> j314c 14" M1 Max mbp
kaazoo has left #asahi-dev [#asahi-dev]
nsklaus has joined #asahi-dev
<_jannau_> have to try if any of the PMGR hooks trigger during suspend
<marcan> huh, I think I found an autonomous battery charge limit in SMC
<marcan> unfortuantely it's not configurable
<marcan> but I *think* CHWA=1 will limit charge to 75-80%
<marcan> unfortunately that doesn't merge well with the kernel API...
<marcan> maybe we can do something like test the configured limits, and if they're lower or equal to that, just engage that mode in suspend
<marcan> maybe charge_type = "long life" would sort of map to that, but it's intended to mean lower current charging, not outright limits :/
<marcan> though drivers are allowed to round charge_control_end_threshold etc, so maybe we should just ditch the kernel handling entirely and just only allow setting 80 or 100 for that.
<dottedmag> marcan: that's the charge limit applied my macos, right?
<marcan> no, macos uses software handling like linux does AIUI
<marcan> I only found this by looking at SMC firmware
c10l has quit [Quit: Bye o/]
<chadmed> i assumed that the device in pro audio mode is exposed as a single channel by pipewire
kedde4 has joined #asahi-dev
<marcan> :D
kedde3 has quit [Ping timeout: 480 seconds]
<marcan> ohh and this feature was introduced in some newer SMC firmware, 13.0 maybe
<marcan> isn't there on my j314 with 12.4
<j`ey> the CHWA key isnt there at all?
<marcan> not in 12.4 j314 SMC, no
<marcan> it is in 13.3 in j416
<marcan> and the firmware I'm reverse engineering is some early 13.0 beta (last one I have a key for on t8103)
<marcan> (would be really nice to get newer keys...)
<marcan> so I think it got added in 13.0
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
<chadmed> awesome, boost pstates are working
<chadmed> let me cobble together enough hwmon to do opp-microwatt measurements
Galileo-dev has joined #asahi-dev
<_jannau_> or if charging cd
hightower4 has joined #asahi-dev
<_jannau_> err
<chadmed> oh wow idle power is closer to 8 W now, im assuming EAS doesnt like pstates without opp-microwatt
kedde has joined #asahi-dev
<marcan> I expect the boost states to be woefully power-inefficient, so it really shouldn't switch to them until it really knows it needs to
kedde4 has quit [Ping timeout: 480 seconds]
<chadmed> lets see just how bad they are heh
hightower3 has quit [Ping timeout: 480 seconds]
<marcan> also, have we confirmed that the "extra" pstates on t802x are only for j416c? if so we need to adjust the DTs to that end.
chadmed has quit [Remote host closed the connection]
<_jannau_> macos high performance mode is 16" M{1,2} Max only https://support.apple.com/en-us/HT212852
<_jannau_> Mac14,6 is the only device in geekbench with reported frequency higher than 3.5 GHz
<_jannau_> I guess we would have to try on other devices if this is just a software limitation
<marcan> I'm interested in what pstates the devicetree has
galileo has joined #asahi-dev
<marcan> max we have on t8103 is 15/3104, t600x is 15/3228, t8112 17/3504 t6002/j416 19/3696
<marcan> extra pstates on t600x seem unlikely given they ran out of bits in the register
<marcan> *t6001/j416
<marcan> so this sounds like it should be exclusive to that
<marcan> er another typo, let me redo that
<marcan> max we have on t8103 is 15/3204, t600x is 15/3228, t8112 17/3504, t6021/j416 19/3696
<marcan> I should get dinner, I clearly am not thinking right :p
<marcan> bbl
nyilas has quit [Remote host closed the connection]
bcrumb has joined #asahi-dev
Galileo-dev has quit [Quit: Konversation terminated!]
galileo is now known as Galileo-dev
chadmed has joined #asahi-dev
<chadmed> hm my numbers have changed since last time and i think theyre wrong...
<chadmed> 3.3 W per core at the top firestorm pstate seems... low
<chadmed> but thats what the SMC tells me so...
<chadmed> kde reporting ~7h worth of battery watching 1080p30 vp9
bcrumb has quit [Quit: WeeChat 3.8]
baozich has quit [Quit: baozich]
baozich has joined #asahi-dev
<marcan> oh yeah, there's something else...
<marcan> chadmed: might want to hold off on measurements
TexasOct has joined #asahi-dev
<marcan> there's a couple m1n1 changes that might affect that
<marcan> what machine are you testing on?
<chadmed> j314 atm
<chadmed> ill do the mini tomorrow now, its getting late
<marcan> np, let me confirm that I can work around the snafu
<marcan> we were clearing all bits of the pstate registers because I wrote & FOO instead of & ~FOO
<marcan> I think that made us lose at least one bit on pcores and I don't know what it does
<marcan> needs a m1n1 stage1 update to fix "properly" but I can probably just restore the bits in stage2 as a one-off
baozich has quit [Quit: baozich]
baozich has joined #asahi-dev
c10l has joined #asahi-dev
c10l has quit []
c10l has joined #asahi-dev
<chadmed> oh in other news glmark2 scores have doubled for no apparent reason???
<chadmed> same mesa
baozich1 has joined #asahi-dev
baozich has quit [Remote host closed the connection]
baozich1 is now known as baozich
<jannau> suspend (or wakeup) seems to break with no_console_suspend and macsmc_power.log_power=1. wakeup works without no_console_suspend
<marcan> oh, heh
<marcan> well
<marcan> that kind of makes sense because macsmc tries to do a printk when you press the button
<marcan> I'm guessing the console isn't quite right then
<jannau> is the max pstate visible in ioreg? that's probably the fastest way to get results from j41{4,6}{s,c}
<marcan> yes, you can see it in the pmgr stuff
<marcan> ioreg -l -p IODeviceTree | grep voltage-states
<marcan> that should do it
<jannau> voltage-states{5,13}-sram? max value on j474s is 3_504_000_000
<jannau> chadmed: 3840x2160 glmark2 score with cpuidle alone is roughly the same
<chadmed> might be the sus eas numbers, but im getting ~3700 by default whereas last time i did the testing i barely got 2300 with the performance governor and pinning glmark2 to the pcores
baozich has quit [Quit: baozich]
baozich has joined #asahi-dev
<chadmed> resolution doesnt affect it so its still cpu bound
<chadmed> but higher
baozich has quit []
baozich has joined #asahi-dev
landscape15 has joined #asahi-dev
landscape15_ has joined #asahi-dev
<jannau> was the last test already with lina's sync UAPI? results are not fully resolution independent. 800x600 is faster than 4k. nowhere near 17 times faster of course but maybe 2 times
<jannau> probably less than 2
landscape15_ has quit []
landscape15 has quit [Ping timeout: 480 seconds]
<jannau> no, wakeup is again broken
baozich has quit [Ping timeout: 480 seconds]
chadmed has quit [Read error: Connection reset by peer]
chadmed has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
c10l has quit [Ping timeout: 480 seconds]
hightower4 has quit [Ping timeout: 480 seconds]
baozich has joined #asahi-dev
raveling has joined #asahi-dev
baozich has quit [Ping timeout: 480 seconds]
raveling has quit [Ping timeout: 480 seconds]
baozich has joined #asahi-dev
raveling has joined #asahi-dev
Galileo-dev has quit [Remote host closed the connection]
baozich has quit [Ping timeout: 480 seconds]
baozich has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
Guest11450 has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
baozich1 has joined #asahi-dev
baozich has quit [Ping timeout: 480 seconds]
baozich1 is now known as baozich
raveling has joined #asahi-dev
baozich has quit [Ping timeout: 480 seconds]
raveling has quit [Ping timeout: 480 seconds]
<ChaosPrincess> so, how to deal with mipi? Macos just stashes whatever was configured by iboot and reapplies the configs if it comes out of sleep mode. I could make a separate driver, but dw-mipi-dsi kinda looks similar-ish, but the way it is right now, i can't really cause it to do the same series of register writes as macos does.
<marcan> new driver
<marcan> if it's just a save/restore it's not worth using the existing driver
<ChaosPrincess> its save/restore, and i would copy/paste the mipi send/mipi recv functinos
<ChaosPrincess> also might need to put the stash part in m1n1 so i could drop always-on
<_jannau_> you can clear the always-on after you saved the initial config. did we drop that with runtime-pm?
bps has quit [Ping timeout: 480 seconds]
<marcan> ChaosPrincess: no, read the regs in the kernel
<marcan> we don't want to be passing around unnecessary blobs
<marcan> the always-on thing will be fixed in core code eventually
<marcan> it is a known problem, don't design around it
<marcan> and yes you can do what DCP used to do and drop it in the driver (it's a hack but it works), though eventually that won't be necessary
<ChaosPrincess> i can just not bother with trying to survive a reset for now and not disable the mipi link on suspend
<ChaosPrincess> that would make it much easier
roxfan has quit [Ping timeout: 480 seconds]
nela6 has joined #asahi-dev
hightower2 has joined #asahi-dev
nela has quit [Ping timeout: 480 seconds]
nela6 is now known as nela
abd has joined #asahi-dev
nela3 has joined #asahi-dev
abd has quit []
abd has joined #asahi-dev
<marcan> weird, so clpc or something is shutting down the Pcore clusters on this t602x and then they never come back, processes just stay stuck on the ecores
<marcan> maybe it's due to the dodgy power readings?
nela has quit [Ping timeout: 480 seconds]
nela3 is now known as nela
raveling has joined #asahi-dev
<marcan> anyway, I implemented CPU shutdown enough to survive a suspend cycle
<marcan> this happens:
<marcan> [cpu7] Guest is shutting down CPU
<marcan> TTY> HV: Requesting exit of CPU#7 from the guest
<marcan> TTY> HV: Exiting from CPU 7
<marcan> TTY> HV: All CPUs exited
<marcan> Hypervisor exited. Entering shell.
<marcan> >>>
<marcan> unfortunately there's an SMC timer or something triggered that forces a reboot a few seconds later
<marcan> but at least we get to see the entire suspend cycle
<marcan> resume would be... more interesting to implement. I think we'd have to *actually* suspend the CPUs and m1n1 and go through the whole thing for real.
<marcan> pushed the stuff
nela has quit [Ping timeout: 480 seconds]
<jannau> I still can't reproduce the power numbers on t6001/j314. kde lock screen with display turned off: ~5W (CPU takes ~3.3W). s2idle: 2.9W (2.2W CPU)
<marcan> jannau: that looks about right?
<jannau> comparing to 3.2W screen off / 1.9W s2idle from this morning on t6000 and chadmed said 3W something for t6001 with screen off
<jannau> looks roughly like 50% more
<marcan> I expect t6001 to use more power than t6000
hightower2 has quit [Ping timeout: 480 seconds]
roxfan has joined #asahi-dev
<marcan> pushed some sleep mode stuff that doesn't really work
<marcan> or well, I think it puts the system to sleep (after the guest does), but it definitely doesn't come back yet
<marcan> I also don't have working serial right now so I can't debug whether it even tries
<marcan> there's at least one interesting thing I can try though
<marcan> nah, not that easy
<marcan> good night :p
cylm_ has quit [Read error: Connection reset by peer]
cylm_ has joined #asahi-dev
Cyrinux9 has quit []
Cyrinux9 has joined #asahi-dev
cylm has joined #asahi-dev
nela has joined #asahi-dev
cylm_ has quit [Ping timeout: 480 seconds]
djorz has quit [Ping timeout: 480 seconds]
pthariensflame has joined #asahi-dev
nicolas17 has joined #asahi-dev
abd has quit [Ping timeout: 480 seconds]
pthariensflame has quit []
abd has joined #asahi-dev
pthariensflame has joined #asahi-dev
abd has quit [Ping timeout: 480 seconds]
pthariensflame has quit []
djorz has joined #asahi-dev
hightower2 has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
SalimTer- has joined #asahi-dev
abd has joined #asahi-dev
salimterryli has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
raveling has quit [Remote host closed the connection]
abd has quit [Ping timeout: 480 seconds]
SalimTer- has quit [Ping timeout: 480 seconds]
salimterryli has joined #asahi-dev
pharonix71 has quit [Read error: No route to host]
kedde1 has joined #asahi-dev
kedde has quit [Ping timeout: 480 seconds]
bps has joined #asahi-dev
kedde1 has quit [Ping timeout: 480 seconds]
abd has joined #asahi-dev
abd has quit [Read error: Connection reset by peer]
nsklaus has quit [Quit: ZZZzzz…]
bps has quit [Ping timeout: 480 seconds]