<marcan>
eiln: also just to give you an idea: AIUI the main thing you care about re the DRM/linux interface is how you do memory management and how you do work submission from userspace.
<marcan>
one important question there is how ANE handles multiprocessing
<marcan>
like can it have different user contexts/VMs or is it all one shared address space?
<marcan>
if it's shared then the kernel driver needs to deal with all input/output/etc addresses, which I'm guessing is the case here? (no addresses in untrusted code/kernels from userspace)
<eiln>
there are 8 hw queue slots which can be stacked
<eiln>
but only one main queue that triggers the circuit
<marcan>
but are there separate DART contexts?
<eiln>
I actually have no idea
<marcan>
ok, you probably need to make sure you understand that fairly well before starting to design the linux driver since it completely changes the design
<marcan>
what is the kernel responsible for as far as deciding where data buffers live
<marcan>
can ane programs decide where to do data reads or are the input/output buffers programmed by the driver always?
<eiln>
wait no, I misread
<eiln>
in each hw queue there's a BAR slot
<eiln>
which has a very specific order on mapping the input/output dvas
<eiln>
driver is responsible for packing the BAR
<marcan>
so the driver controls all dvas?
chengsun has quit [Ping timeout: 480 seconds]
<eiln>
when you push a queue you're pushing the dma of the configuration registers
<eiln>
and within the config regs are slots for dvas
<eiln>
and those are configured automatically via BAR
<marcan>
right, and all that is controlled by the driver
<eiln>
yes yes
<marcan>
i.e. there are no dvas in like a compiled program etc
<eiln>
yes
<eiln>
they're all zeroed out
<marcan>
and there's no way for the program to like run a load instruction from an arbitrary address
<eiln>
nope
<marcan>
ok, then it's probably a single VM and you don't need to worry about that, you just need some kind of buffer token thing so userspace apps never even see addresses, just some opaque buffer identifiers
<eiln>
you can diff the binary of the compiled vs. the regs filled in after execution to see how the addrs get configed from BAR
<marcan>
well, drm already has that I think
<marcan>
I need to get some sleep, but some pointers
<marcan>
- it would be helpful if you can write up some prose on how this all works so others have somewhere to start trying to understand it
<marcan>
- might want to also lurk in #dri-devel since that's where the rest of the dri crowd is, as far as using the dri/accel subsystems
<marcan>
- also would be nice to figure out the firmware and its interface and whether it changes from version to version
<marcan>
- and assuming you're using drm/accel... the question is do you want to write the driver in Rust or C :p (if Rust, definitely talk to lina)
<eiln>
awesome, got it.
<eiln>
do you mean the different hw types?
<marcan>
and different firmware versions (from different macos versions) on the same hw
<marcan>
we need to support at least certain cherry-picked versions (like we are on 12.3 on t8102/t600x and 12.4 on t8112 right now), and the list will grow over time
<marcan>
which I guess is conditional on whether we need to use the ASC at all or not, which then brings in the ISP question again
<eiln>
ah I don't have any archives, I'm on 12.6 rn
<marcan>
are you running against m1n1 installed on top of macos, or the asahi m1n1?
<eiln>
asahi
<marcan>
then that's 12.3
<marcan>
but for tracing macos you use m1n1 installed on macos, right?
<eiln>
yes
<marcan>
yeah, so keep in mind, especially once the ASC comes up, that could mean you have interface differences
<eiln>
got it
<eiln>
definitely need to talk to the isp guy though
<marcan>
you'll have to test stuff vs the macos m1n1 first, then see if it works back in 12.3 (if it does, lucky, if not, time to install as 12.3 macos and see what changed)
<marcan>
yeah :)
<eiln>
awesome, thanks for the *s.
<marcan>
also you copied the tunable writes from macos? or from the ADT in the 12.3 m1n1?
<marcan>
because there's a very high chance those change from version to version (since firmware placement in memory depends on the size of every other firmware and things like that)
<marcan>
the DAPF tunables I mean
<marcan>
if those are wrong then there's no chance the firmware will boot ;)
<marcan>
but as I said the stuff in dapf.c should do that "properly" for you
<marcan>
anyway, I should get some sleep, hope that helps a bit!
gff_ has quit [Ping timeout: 480 seconds]
eiln has quit [Remote host closed the connection]
nicolas17 has joined #asahi-re
<amarioguy>
eiln: wait you're working on the ANE support now?
chengsun has joined #asahi-re
Dcow has quit [Remote host closed the connection]
chengsun_ has joined #asahi-re
chengsun has quit [Ping timeout: 480 seconds]
chengsun_ has quit [Quit: Quit]
chengsun has joined #asahi-re
Dcow has joined #asahi-re
chengsun has quit [Ping timeout: 480 seconds]
Dcow has quit [Ping timeout: 480 seconds]
SSJ_GZ has quit [Ping timeout: 480 seconds]
eiln has joined #asahi-re
<eiln>
amarioguy: yes, dug myself into this hole
eiln has quit []
Dcow has joined #asahi-re
eiln has joined #asahi-re
<eiln>
just pushed an initial writeup, looking into dapf rn
eiln has quit []
chengsun has joined #asahi-re
Dcow has quit [Ping timeout: 480 seconds]
chengsun has quit [Ping timeout: 480 seconds]
chengsun has joined #asahi-re
chengsun_ has joined #asahi-re
eiln has joined #asahi-re
<eiln>
calling p.dapf_init("/arm-io/dart-ane") before my writes even messes things up