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
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
midou has quit [Read error: No route to host]
midou has joined #asahi-dev
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
hdbngr has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
hdbngr has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
Extern has quit [Quit: WeeChat 4.7.0]
tobhe_ has joined #asahi-dev
tobhe has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
jnn has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
jn has quit [Ping timeout: 480 seconds]
pb17 has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-dev
chrisl has joined #asahi-dev
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
nora has joined #asahi-dev
nora_ has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
Lyude has quit [Read error: Connection reset by peer]
Lyude has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
hdbngr has joined #asahi-dev
chrisl has joined #asahi-dev
hdbngr has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chadmed has quit [Quit: Konversation terminated!]
chrisl has joined #asahi-dev
chadmed has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
hdbngr has joined #asahi-dev
bacarrdy has quit [Remote host closed the connection]
bacarrdy has joined #asahi-dev
chrisl has joined #asahi-dev
hdbngr has quit [Ping timeout: 480 seconds]
bacarrdy has quit [Remote host closed the connection]
bacarrdy has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
hdbngr has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
hdbngr has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
pb17 has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-dev
nafod has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
ddxtanx has quit [Remote host closed the connection]
hdbngr has joined #asahi-dev
bacarrdy has quit [Remote host closed the connection]
<jannau>
posted to #fedora-asahi-devel as well, let's wait a few days before merging it
chrisl has quit [Ping timeout: 480 seconds]
<sven>
yeah, sounds good to me
<sven>
unless there are objections i'd also merge 460 (chickens cleanup) and 469 (atcphy fuses as tunable). is 466 (gpu blobs in m1n1) ready as well now that the gpu dt bindings are upstream?
<sven>
we can always fix any bugs, etc. in main later
chrisl has joined #asahi-dev
<sven>
then probably als 474 (unvendor a bunch of stuff) after the packit thing is merged
<sven>
*also
<jannau>
yes, but to avoid the annoying false failures for every PR
<sven>
yeah
<sven>
oh right, the gpu stuff fails due to packit as well right now
<jannau>
please wait on GPU init one. I need go through all devices again to verify that the paramters are unchanged
<sven>
ok, i'll just ignore that one then and you can merge it whenever you think it's ready :)
<jannau>
and the kernel is not ready either. My plan was to see if we can have at least for a while both variants supported
<sven>
ack
<sven>
what about 471? looks reasonable to me as well
chrisl has quit [Ping timeout: 480 seconds]
<jannau>
469 still needs fuses for t600x and t8112 or?
<sven>
yes, but it won't fail without these
<sven>
so we can always just add them later
<sven>
and the current kernel we ship reads the fuses itself anyway
<jannau>
sure, was more a reminder for myself to add them
<sven>
fair enough
chrisl has joined #asahi-dev
bacarrdy has quit [Ping timeout: 480 seconds]
bacarrdy has joined #asahi-dev
hdbngr has joined #asahi-dev
<sven>
alright, so from the non-stale PRs we have two for pre-M1 support (where i just left comments), the gpu one, the packit one, the rust compiler warnings, and finally https://github.com/AsahiLinux/m1n1/pull/457
<chadmed>
wrt 457 id like some feedback before we merge it obviously. also not sure if we want to do a more modern/rust-y API and bind that back to the libfdt API for C code or just stick with what's in there which is basically 1:1 the libfdt API translated to rust
<sven>
yeah, i wasn't going to suggest to just merge it. just mentioned it because that's the only one no one reviewed so far :)
<sven>
(plus the old stale PRs, i'd just leave them around just in case someone does come back to them. maybe add a stale label or something)
<chadmed>
yeah we can do a label and tag the author asking if theyre gonna come back to it
<chadmed>
ive found that whenever we ask for an S-o-b or minor fixes they usually go AWOL
<sven>
true. doesn't hurt to leave them around though
<jannau>
I think the stale trace PRs are useful to keep as open as that makes them easier to discover
<sven>
ack
<sven>
for the minor fixes I don't care either way
chrisl has quit [Ping timeout: 480 seconds]
<sven>
if someone runs into the same problem they're probably gonna fix it before noticing there's already a stale PR around
<jannau>
even though they are mostly documentation / examples at this point
hdbngr has quit [Ping timeout: 480 seconds]
<sven>
closed one minor fix PR that's been stale for 2 years
<sven>
the rest seems useful to keep around even if no one ever continues working on them
<sven>
chadmed: i'd be in favor for a more rust-y API and then just binding that one back to the C api fwiw
cylm has joined #asahi-dev
chrisl has joined #asahi-dev
<chadmed>
i was thinking of tying the methods related to nodes and headers (getting values, number of children, etc) to impls for their specific structs and leave the top level ADT impl for simply getting references to those nodes/headers
<chadmed>
we can have safe(r) methods to get property values of a specific type rather than expect callees to just blindly cast slices of u8s
chrisl has quit [Ping timeout: 480 seconds]
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
hdbngr has joined #asahi-dev
chrisl has joined #asahi-dev
bacarrdy has quit [Remote host closed the connection]
bacarrdy has joined #asahi-dev
hdbngr has quit [Ping timeout: 480 seconds]
hdbngr has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
<nickchan>
time to setup the m1n1 tethered boot setup I guess I can use the t2 mac as the host
<nickchan>
so I can debug the j314sap
bacarrdy has quit [Ping timeout: 480 seconds]
bacarrdy has joined #asahi-dev
<sven>
looking at the list of stuff left to upstream: rust bindings for rtkit and our mailbox looks like low hanging fruit to me
<nickchan>
macvdmtool won't work with a t2 host but I suppose I could live without that
<sven>
and if someone's looking for something more challenging and ideally has a raspberry pi for testing as well there's the wifi patches
chrisl has joined #asahi-dev
<nickchan>
that pmgr misc state driver sounds sane enough other than the printk("set %d ps to pstate %d\n", dev, pstate);
<nickchan>
if anything should be a pr_debug
hdbngr has quit [Ping timeout: 480 seconds]
<sven>
yeah, that driver would be a good first one for anyone looking to get into upstreaming work
chrisl has quit [Ping timeout: 480 seconds]
<sven>
happy to mentor anyone who wants to give that one a try
hdbngr has joined #asahi-dev
<chadmed>
should we upstream pmgr without first fixing idle pm on the t60xx socs?
<chadmed>
i feel like we should at least figure out what we need to do to it
<sven>
maybe i don't understand that driver, but doesn't it just tweak some registers and save 1W or so in s2idle?
<chadmed>
yes but supposedly it needs to do more stuff for idle pm to work properly on t60xx
<chadmed>
currently those both still pull down like 8-10 W idle
chrisl has joined #asahi-dev
<sven>
hm, i thought that additional power usage was very likely caused by something else
hdbngr has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
<chaos_princess>
sven: temporary hold on bf89fe2, i may or may not revert it
<sven>
is that part of the gpu pr?
<chaos_princess>
no, it may actually be us doing by hand what pmp is supposed to do via firmware
<sven>
oh... that's the pmgr driver
<sven>
fair enough
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
hdbngr has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
hdbngr has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
bigmac has quit [Quit: WeeChat 3.8]
chrisl has joined #asahi-dev
bigmac has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
hdbngr has joined #asahi-dev
chrisl has joined #asahi-dev
nafod has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
hdbngr has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-dev
os has joined #asahi-dev
chrisl has quit [Ping timeout: 480 seconds]
<nickchan>
so I used thunderbolt 4 cable to connect the mbp 2018 15 inch's usb-c port and j314sap's m1n1 proxy together and that does not work but a usb-a to c cable with an adapter worked fine
hdbngr has joined #asahi-dev
chrisl has joined #asahi-dev
<nickchan>
okay a usb2 c to c cable works too
<nickchan>
So I suppose I should stick to that
<nickchan>
wouldn't be surprised if there's some atc mishandling
hdbngr has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
hdbngr has joined #asahi-dev
chrisl has joined #asahi-dev
<jannau>
I don't think the linux driver can do anything about this on j314s side. afaik that's handled by cd3217 fw or possible smc
<jannau>
I've pushed asahi-6.16.0-1 to github. 967 non merge commits compared to v6.16. backl to lkess than 1000 commits from upstream. main contribution are imported rust patches from v6.16, squashing of the 210-gpu branch and other patches upstreamed for v6.16
<jannau>
roughly 1/4 of the 963 commits are in bits/200-dcp which could also be squashed
hdbngr has joined #asahi-dev
bacarrdy has quit [Ping timeout: 480 seconds]
bacarrdy has joined #asahi-dev
nela2 has joined #asahi-dev
hdbngr has quit [Ping timeout: 480 seconds]
bacarrdy has quit [Ping timeout: 480 seconds]
bacarrdy has joined #asahi-dev
bacarrdy has quit [Ping timeout: 480 seconds]
bacarrdy has joined #asahi-dev
<sven>
nice, we're slowly making progress :)
<sven>
i really hope i can get finally get atcphy/usb upstream next
<sven>
(and smc hid and rtc, but that shouldn't be very hard since both drivers are rather small)
<jannau>
I will look at four level dart/iopgtbl and spi-hid + touchpad
<jannau>
I started preparations for those. ideally I'd also like to submit the missing devices (15" m2 air and all t602x based devices) for 6.18
<sven>
that would be nice
<sven>
assuming i get usb in for 6.18, thunderbolt should be doable for 6.19 then
<nickchan>
there's some new weird issues right now with the armv8.0 chips (a7-a10,t2) that causes m1n1 to stop responding on the second msr() in two msr() in a row, sounds like atomics :/
<sven>
(basic and boring thunderbolt that isn't useful fwiw)
<nickchan>
I mean mrs() but both has issues seems anything that ends up calling p.call is problematic
bacarrdy has quit [Ping timeout: 480 seconds]
bacarrdy has joined #asahi-dev
<jannau>
so you're not going to fix PCI hotplug? it looks like nvidia might be struggling with usb4 / thunderbolt for dgx spark as well. it's delayed. nvidia lists just usb-c in their spec and the partner devices list usb3.2
<nickchan>
okay it's not that simple I should look into it more
<sven>
i first want to get the NHI upstream
<sven>
once that's there i'll look into pcie next
<chaos_princess>
basic and boring - just the host-to-host interface thing?
<jannau>
nickchan: are we using LSE atomics?
<sven>
chaos_princess: yup, and maybe usb4 tunneling since that's easy
<sven>
essentially i just don't want to create another situation where there are 30+ downstream patches for tbt again
<sven>
so i'm gonna try and upstream it step by step
<chaos_princess>
yea, a certain someone decided to write a rust driver, and well... :P
<sven>
:D
<sven>
and then once tbt + pcie hotplug is there it's maybe finally time to buy a m3 or m4 for me ;)
siddhartha has joined #asahi-dev
siddhartha has quit [Remote host closed the connection]
<nickchan>
jannau: im looking into the behaivor because I cannot reproduce the behaivor on a8 and a11 but can on a7 and a10
<nickchan>
it's truly weird
<nickchan>
and it was not like this
<jannau>
we're building with "-march=armv8.2-a". did you change that already? not sure what could blow but LSE atomics certainly would
<nickchan>
it was never changed
<nickchan>
okay now that's fun because I have to instruct the compiler to not emit lse atomics while still allowing all those sysreg accesses to happen
bacarrdy has quit [Remote host closed the connection]
bacarrdy has joined #asahi-dev
<nickchan>
and there's inline asm everywhere
bgb has quit [Remote host closed the connection]
bgb has joined #asahi-dev
<nickchan>
this could become an issue down the line for macs too if some newer arm msr needed to be accessed
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
chadmed has quit []
chadmed has joined #asahi-dev
<nickchan>
okay all the inline sysreg accesses that causes issues when compiled with -march=armv8-a is within the hv files
<nickchan>
that makes it a bit easier to deal with
hdbngr has joined #asahi-dev
<nickchan>
ugh there's also PAN register but I suppose I could move that to asm files
bacarrdy has quit [Ping timeout: 480 seconds]
bacarrdy has joined #asahi-dev
<nickchan>
nah there's also a bunch in src/exception.c but linux must be somehow dealing with all of this
hdbngr has quit [Ping timeout: 480 seconds]
<nickchan>
linux uses -Wa,-march=armv8.4-a -DARM64_ASM_ARCH="armv8.4-a" but that still doesn't fix the
<nickchan>
fix the issues here
bacarrdy has quit [Ping timeout: 480 seconds]
bacarrdy has joined #asahi-dev
<nickchan>
got it, add .arch armv8.2-a to all the inline asms and it is fine (the critical ones happen via the sysreg wrapper so it really is just 2)
<tpw_rules>
hi i'm being bothered by device tree differences again. is it possible to have u-boot copy the per-boot/per-device DT stuff to a device tree it loads itself so they can be kept with the kernel instead of m1n1? i made a patch several years ago but the plan was not accepted. maybe things have changed now?
<chaos_princess>
i am not sure how u-boot is involved in that?
<tpw_rules>
it has hooks to patch up a loaded device tree
<nickchan>
unforunately that does not fix the issue so I need to look further, probably good idea to keep the change in makefile though
<chaos_princess>
ok, and how is that related? The per-device data is calculated in m1n1
<jannau>
u-boot would need to copy all the dynamic information m1n1 fills in kboot to the dtb