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
raveling has joined #asahi-dev
pbsds has joined #asahi-dev
eslerm has joined #asahi-dev
baahemian has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
raveling has quit [Ping timeout: 480 seconds]
sosys has quit [Remote host closed the connection]
sosys has joined #asahi-dev
baahemian has quit [Quit: baahemian]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
user982492 has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
nepeat_ has quit []
pg12_ has joined #asahi-dev
nepeat has joined #asahi-dev
nepeat has quit []
pg12 has quit [Ping timeout: 480 seconds]
nepeat has joined #asahi-dev
gabuscus has quit []
gabuscus has joined #asahi-dev
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
baozich has joined #asahi-dev
lucic71 has quit [Remote host closed the connection]
sosys has quit [Remote host closed the connection]
sosys has joined #asahi-dev
sosys has quit []
sosys has joined #asahi-dev
sosys has quit []
zzywysm has quit [Remote host closed the connection]
nicolas17 has quit [Quit: Konversation terminated!]
raveling has joined #asahi-dev
newiz has quit [Quit: Konversation terminated!]
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
chadmed_ has quit [Quit: Page closed]
raveling has quit [Ping timeout: 480 seconds]
kedde2 has joined #asahi-dev
abd has joined #asahi-dev
abd has quit [Quit: abd]
abd has joined #asahi-dev
abd has quit []
abd has joined #asahi-dev
abd has quit []
abd has joined #asahi-dev
bps has joined #asahi-dev
<marcan>
kaazoo: there is no 13" M2 Pro
<marcan>
I assume you mean 24"
<marcan>
*14"
<kaazoo>
Sorry, typo. I meant 14"
raveling has joined #asahi-dev
<kaazoo>
What's the best way to compile the dtb files? I cloned the asahi linux repo and checked out t602x/bringup branch. Took kernel config from https://github.com/AsahiLinux/PKGBUILDs/blob/main/linux-asahi/config and compiling the kernel now. Just takes a while, so I wonder if there is an easier way if one just wants to use newer devicetree files.
abd has quit [Remote host closed the connection]
<marcan>
the devicetree is the first thing that gets compiled, but you need the new kernel anyway
<marcan>
just the devicetrees won't get you anywhere
<marcan>
that and I don't think u-boot has the bits to make the keyboard work there yet either
<marcan>
are you planning to help with t602x bringup?
raveling has quit [Ping timeout: 480 seconds]
<kaazoo>
I'm trying to boot as far as possible with the current state of t602x related changes and give feedback. I will also try to help if I can, but I want to understand the current state and open problems first.
<marcan>
what feedback do you plan to give?
<marcan>
we know what works and what's broken
<marcan>
spending time walking people through testing unreleased code is not productive when we could be fixing those things instead
<marcan>
you're welcome to help development out, but please learn how to get a development setup going with a *supported* machine first where stuff will actually work as intended
<jannau>
but it doesn't make sense to try to make a old distro image work with t602x piece by piece
<jannau>
it's a waste of time to try to make the on device boot process work while the bringup is not complete
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
abd has joined #asahi-dev
VinDuv has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
yrlf has quit [Quit: Ping timeout (120 seconds)]
linuxgemini1 has quit []
commandoline has quit [Read error: Connection reset by peer]
linuxgemini1 has joined #asahi-dev
<kaazoo>
OK, I agree with your concerns.
commandoline has joined #asahi-dev
yrlf has joined #asahi-dev
VinDuv has joined #asahi-dev
abd has quit [Remote host closed the connection]
raveling has quit [Ping timeout: 480 seconds]
<marcan>
robher: I'm running the DT checker on our SoC DT tree after updating dtschema and it's complaining about OPPs and cpu-release-addr, but as far as I can tell they are correct. known issue?
<marcan>
pretty sure it's not a regression on our side so I won't block the next SoC pull on it, but would be nice to know what's up
bps has quit [Read error: Connection reset by peer]
bps has joined #asahi-dev
abd has joined #asahi-dev
nsklaus has joined #asahi-dev
abd has quit [Ping timeout: 480 seconds]
nyilas has joined #asahi-dev
raveling has joined #asahi-dev
hightower3 has joined #asahi-dev
hightower2 has quit [Ping timeout: 480 seconds]
<marcan>
ok, I'm tired of waiting for the PSCI conversation to happen / to find time to start it. I'm going to write a dumb cpuidle driver and we can run on that downstream until it does.
nyilas has quit [Remote host closed the connection]
flokli has quit [Quit: WeeChat 3.8]
flokli has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
cylm has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
<marcan>
pushed t602x/bringup with jannau's DCP 13.3 conversion (tested working) and a cpuidle driver
<marcan>
haven't tested actual idle power consumption yet :)
<marcan>
lol, implementing proper cpuidle also caused timekeeping to stop properly during suspend now, which means the SMC power logging doesn't work :D
<marcan>
that also means the battery charge state control won't work unfortunately... we need to figure out something for that
<_jannau_>
CLOCK_BOOTTIME is supposed run during suspend if you can use that there. doesn't help of course for the battery state control when the system is actually suspended
<marcan>
yeah, the problem is actually setting up some kind of periodic timer
<marcan>
it would be nice if we had a way to make SMC annoy us periodically some way, then it could all be done within the driver
<marcan>
alternatively I'm sure the RTC or watchdog could be used for this but ugh, if this is going to be cross-driver we might as well figure out how to do it with core timekeeping and the arch timer
<marcan>
I'm going to pull up the old SMC disasm and see if I find anything useful... though I kind of doubt it, there aren't many event sources to begin with
<marcan>
oooh this is interesting, there's an SMC key for remote management that can trigger system actions (boot, reboot, and even ask the OS to sleep)
<marcan>
it's an outright SMC key though, so... who writes it? it would have to be another coprocessor via SMC sidechannel I think...
<marcan>
but I would expect this to be eventually fired from the Aqantia NICs so... how would that work? do they have an outright SMC sidechannel via i2c or something?
chadmed has quit [Remote host closed the connection]
<_jannau_>
I think there was something in the ADT which hinks how the aqantia nic is connected for the lights out management
<_jannau_>
might be i2c
<_jannau_>
connected to i2c5. aqc-a on the mac studio
chadmed has joined #asahi-dev
<chadmed>
marcan: system idle on j314 is ~5.5-6.1 W which still seems kinda high
<chadmed>
i think its a little bit down but not by a meaningful amount
<chadmed>
the part of the keyboard over the soc is nice and cold now though so it must be other stuff sucking down juice
<chadmed>
interestingly the hitching on various animations around the desktop with EAS is now gone with no other kernel changes so... neat
<marcan>
yeah something is not quite right, I think
<chadmed>
i mean its doing something so thats good
<chadmed>
ive lost my smc power meter patches so ill rebuild those and do some more testing later
<marcan>
the debug mode thing I have isn't enough?
<chadmed>
i want to look at how much power the cores are pulling down without the noise of the rest of the system
<chadmed>
i had some patches that added enough hwmon to get the key that measures that
<marcan>
so testing with the smc debug print thing, it drops about 1W of power when I enable the idle states
<marcan>
which isn't... great but it's not nothing
<marcan>
1.5W of CLVR power usage suggests something is still wrong though, I would expect that to drop to ~0 if things were properly and fully shutting down
<chadmed>
its gotta be more than that surely, at least on this machine the thing is stone cold now idling and watching 1080p30 video barely warms it
<marcan>
this is on t6021 btw, maybe there's something else broken here
<robher>
marcan: I'll look into it.
chipxxx has quit [Ping timeout: 480 seconds]
<marcan>
I should pull down some newer xnu sources and see if there's anything interesting, haven't looked in ages
<kettenis>
marcan: sorry, I started writing things down, but got distracted by other stuff again
<marcan>
no worries, not blaming it on you :)
<marcan>
plus with the linux timekeeping mess we really need cpuidle anyway
<kettenis>
regarding the power savings for deep wfi; I didn't get much savings with that when I played with it under OpenBSD
<kettenis>
This can't power off the cluster completely since the cores still maintain some state
<kettenis>
This "deep" wfi state is probably designed to allow boosting of one of the other cores in the cluster
<marcan>
apple definitely does something to let clusters fully power down, otherwise I wouldn't get 100+ hours of idle battery
<kettenis>
yes, there should be a state where the cores lose all state
<kettenis>
and you need to bring them back up starting from rvbar
<kettenis>
for cpu0 that will require assistence from m1n1
<sven>
I vaguely remember seeing something about that in I think some xnu source code they forgot to censor
<marcan>
I thought that was outright system sleep
<marcan>
I don't think macOS uses that in normal system idle, otherwise the hypervisor would go nuts
<marcan>
I did just find at least one power-related bit we're not setting properly
<sven>
true, maybe that was full sleep
<sven>
it had some reference about some
<sven>
bah
<sven>
*about some engine that brings back the cpu from that state
<kettenis>
marcan: I believe I read somewhere that "deep wfi" dropped a bit more state than the GPRs you save/restore
<kettenis>
things like the pointer authentication keys
<kettenis>
but maybe the linux kernel already saves/restores those
<marcan>
it hasn't exploded yet without doing anything so :)
<marcan>
(and this kernel build should have PAC)
bps has quit [Ping timeout: 480 seconds]
<robher>
marcan: I don't see any new DT warnings on mainline. Is this on an asahi based DT?
<marcan>
no, mainline (well, my asahi-soc/dt branch which includes some new stuff, but nothing related to the warnings)
<robher>
you're on 2023.04?
<marcan>
yes
<marcan>
let me run it again
<robher>
marcan: Do you have ea87f1eb4fd8 ("dt-bindings: arm: Allow 32-bit 'cpu-release-addr' values")? It's in 6.3-rc
<marcan>
yes, that's what was causing it (it was saying it matched both options)
<marcan>
but... now I can't repro it, and I'm confused
<robher>
marcan: might have been a stale processed-schema.json. If dtschema changes, it doesn't get updated.
<marcan>
yeah...
<marcan>
is it possible it was caused by a make race from me using -j<n>?
<marcan>
or that actually
<marcan>
because I think I did a run, then updated dtschema
<marcan>
so that would make sense
<marcan>
(and now that I have switched branches it would get updated)
<marcan>
OK, then I think we're good, I'll try to remember to poke things when I do dtschema updates
raveling has quit [Ping timeout: 480 seconds]
<marcan>
/home/marcan/asahi/git/linux/arch/arm64/boot/dts/apple/t8103-j293.dtb: network@0,0: 'local-mac-address' does not match any of the regexes: 'pinctrl-[0-9]+'
<marcan>
have we always had that one? I swear I saw mention of that before...
<_jannau_>
yes, we always had that one. I need to follow up on the series fixing that
<marcan>
I guess that's a standard prop for ethernet controllers but not wifi
<_jannau_>
yes
<robher>
marcan: I should also put in some sort of check/dependency. That's been on my todon't list for some time now. BTW, runs with TOT dtschema with Linus/next branches can be found here: https://gitlab.com/robherring/linux-dt/-/jobs
<marcan>
thanks :)
bps has joined #asahi-dev
kedde2 has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
kedde2 has joined #asahi-dev
kedde2 has quit [Ping timeout: 480 seconds]
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
i509vcb has quit [Quit: Connection closed for inactivity]
raveling has quit [Ping timeout: 480 seconds]
<marcan>
okaaay, I think it's actually shutting down CPUs. this may have been changed recently.
<marcan>
I think we never noticed because CLPC makes that decision and we've always been disabling that in the hypervisor lately.
kedde2 has joined #asahi-dev
<_jannau_>
or we noticed and started disabling CLPC
<_jannau_>
no, macos just panics with CLPC enabled
<marcan>
CLPC was always causing issues
<marcan>
but it only panics if you have too much tracing and it exceeds max power limits and such
<marcan>
but right now for me on 13.3 t416 it's instead trying to shut down a CPU, and when I made the HV not die on that, it's failing instead
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
abd has joined #asahi-dev
<marcan>
hm, nah, but it's not using deep mode which doesn't seem to be saving any power
<marcan>
this doesn't make any sense... going into deep sleep isn't helping at all with power consumption, but also the power usage is already high *before* even starting the secondaries.
raveling has joined #asahi-dev
<marcan>
I think we must be missing something to enable actually powering down idle clusters
baahemian has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
<_jannau_>
didn't chadmed measure reasonable low power use for idle cpu cores? could it be something t60xx specific? I've seen more than 20h of battery life with j493 without s2idle
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
<marcan>
it's a t600x problem with the P core regulators not shutting down
baahemian has quit [Ping timeout: 480 seconds]
<marcan>
*xx
c10l has quit [Quit: Bye o/]
kedde2 has quit [Ping timeout: 480 seconds]
baahemian has joined #asahi-dev
abd has quit [Ping timeout: 480 seconds]
abd has joined #asahi-dev
i509vcb has joined #asahi-dev
c10l has joined #asahi-dev
<marcan>
argh. it's non-CPU power states.
<marcan>
I just dropped power consumption by another watt by doing that.
<marcan>
fabric and stuff
<marcan>
now how do we deal with this...
raveling has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
<marcan>
aaaand I just found a really dumb bug in m1n1 that may or may not be breaking some things...
raveling has joined #asahi-dev
baahemian has quit [Remote host closed the connection]
<marcan>
not sure how much runtime that would be yet, but it's 66% of t602x so we're doing good!
<marcan>
(ignore Tempty, I didn't let it sit there long enough and it's at 62% anyway)
maximbaz has quit [Quit: bye]
<marcan>
pushed to t602x/bringup
<marcan>
I think I can start merging all that mess back into the bits branches :p
<marcan>
but I really should get some sleep
<marcan>
chadmed, jannau: enjoy :)
maximbaz has joined #asahi-dev
___nick___ has quit [Ping timeout: 480 seconds]
<marcan>
I also changed macsmc-power to log power state on button press, so at least you can see what the latest data was after a suspend cycle (SMC updates once per second so usually you'll catch the previous state)
<marcan>
(if you have logging enabled)
<marcan>
also I'm not sure if this is the right approach, since I don't think macOS does any runtime-PM with this stuff and I think it still gets better power usage. so I won't upstream it for now
<marcan>
it's possible this is just papering over the problem of some device hogging SoC fabric/DRAM bandwidth by forcing the entire thing to slow down
<marcan>
so I guess the next step is to work out the DCS counters
abd has quit [Ping timeout: 480 seconds]
Dementor has quit [Remote host closed the connection]
Dementor has joined #asahi-dev
raveling has quit [Ping timeout: 480 seconds]
<chadmed>
we dont do anything with MCC pstates yet do we? can it be switched down to its lower pstate when all cores are in low pstates or something like that?
<chadmed>
also t6000 ~11 hours of idle time with the screen off where it used to be less than 7 so theres a real improvement
<chadmed>
plasma reading 10 hours of battery as im typing this and wiggling the cursor where it used to be ~6 but really closer to 4
<chadmed>
if the codec s2idle fixes get merged ill start testing opportunistic sleep etc and see how that changes things
kedde2 has quit [Ping timeout: 480 seconds]
bps has quit [Ping timeout: 480 seconds]
nicolas17 has quit [Remote host closed the connection]
nicolas17 has joined #asahi-dev
kedde2 has joined #asahi-dev
kedde2 has quit [Ping timeout: 480 seconds]
chadmed_ has joined #asahi-dev
Retr0id6 has joined #asahi-dev
Retr0id has quit [Read error: Network is unreachable]