ChanServ changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
<alyssa>
pipcet[m]: I already started thinking through structuring kernel driver
yuyichao has joined #asahi
<alyssa>
Hmm if I start working on dcp code am i going to be interrupted before i can get anything done
<alyssa>
ohh I have dcplog.txt which gives me references for unit testing the packing code, nice
<marcan>
alyssa: tx/rx are the same, the code is confusing because it plays with the inbuf/outbuf offsets
<marcan>
the packets are all tag,inlen,outlen,inbuf,outbuf
<marcan>
in the same place
<alyssa>
ah, derp, thanks
<marcan>
the other side will issue an ack packet when the call is complete (no offset in the ack, you need to keep track of the stack and ack the most recent call in that channel) which means outbuf is populated
<alyssa>
(Re offsets advancing forever, I assume a real driver just uses a ringbuffer)
<marcan>
hm? no, it's a stack
<alyssa>
....hm?
<alyssa>
git commit -am wt
<marcan>
all commands are at offset 0 until a callback happens and a command gets issued during the callback
<marcan>
then that goes after, then gets popped, back to 0
<marcan>
the other weird thing is the contexts
<alyssa>
ohh. wild, ok.
<marcan>
AP->DCP commands issued during a callback use the CB channel in the mailbox, not CMD, even though the *buffer* is still the same as for CMD
<marcan>
so there are, in effect, 3 contexts
<alyssa>
🤷
<alyssa>
🤔
<marcan>
plain commands, OOB commands (another thread), and async notifications
* alyssa
coughs "overengineered"
<marcan>
plain commands chain like >CMD <CB >CB <CB >CB <CB (and use a pair of buffers, one for each direction)
<marcan>
OOB commands are the same, but different pair of buffers and OOBCMD <OOBCB >OOBCB <OOBCB etc
<marcan>
and then async are just notifications that come in from DCP at any time unsolicited
<alyssa>
r00d of it
* alyssa
puts up "no soliciting" sign
<marcan>
also outbuf includes the retval from the call at the end
<marcan>
(if not void)
<alyssa>
how are InPtr and OutPtr encoded?
<marcan>
those just add a bool nullable flag
<marcan>
InPtr only exists in inbuf, OutPtr only exists in outbuf (null flag only in inbuf)
<marcan>
InOut exists in both
<marcan>
all arrays/etc are fixed length
<marcan>
and the struct is static, so the space is always allocated regardless of whether the pointer is null
<marcan>
there is also an array-of-inptrs in the swap struct, for the surfaces, which is encoded as 4 buffers and also adds 4 null flags
<marcan>
so it's just an InPtr for each element of the array, with its own null flag
<marcan>
(equivalent to 4 discrete params, which is how I did it before I added support for this a couple streams ago)
<marcan>
the Ptr thing is a bit of a misnomer, it really should be called Nullable or something, but that's long
<marcan>
by default structs/arrays can be passed without that, which just means no nullable flag
<marcan>
the python side defaults to in for those, but they can be inout or out too
<marcan>
then they just can't ever be null
<marcan>
obviously for out args they'd still be a pointer at the prototype level
<marcan>
I assume much like us they have some kind of database with the ABI to generate these bindings and specify what's nullable and in/out beyond the C++ prototype
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
skipwich has quit [Remote host closed the connection]
robinp has joined #asahi
<alyssa>
marcan: Ah , got it.
<alyssa>
Better question, uhm, are there actual DART VA pointers in any of the commands?
<alyssa>
I assumed so by the name pointer but if it's just a m1n1-ism for nullable that's a lot easier :)
<alyssa>
dcplog.txt is making a whole lot more sense now :-)
<alyssa>
(Knowing that ptr actually means nullable, and that macOS uses 0xAA for padding instead of 0x00, probably for easier debug)
<alyssa>
Er. Not consistently. Boo.
<marcan>
alyssa: no, there are no meaningful pointers passed anywhere at the dcpep level
<marcan>
I see kernel pointers sometimes, which I assume are just garbage/identifiers and not meaningful to DCP
<marcan>
the only dva is the shared memory base
<marcan>
which is 0xf_00000000 | the DART address
<marcan>
dvas seem to all have that form, I presume that range is where the DART gets mapped from an ASC's perspective
<marcan>
actually I think I saw that mapping explicitly defined in the DAPF (the thing after the DART)
<marcan>
along with direct maps of some MMIO
<marcan>
the "ptr" was intended to mean pointer at the C++ prototype level, not the IPC level :)
<marcan>
you could consider the non-nullable ones references instead of pointers, if you're playing the C++ game, and then my naming scheme almost makes sense :p
aleasto has joined #asahi
<MTecknology>
marcan: How come alyssa hasn't fixed all remaining bugs yet?
<MTecknology>
(ftr - I'm joking, at least half of the backlog is absolute gibberish to me)
Andalu30 has joined #asahi
<sven>
i also kinda expected a fully working linux driver by now
<sven>
marcan: fwiw, there's a DAPF behind the AES engine that we can configure if you want to play with it and confirm that theory
<pipcet[m]>
alyssa: excellent, thank you very much for working on this. I'll just set myself up right here and ask you "are we done yet" every five minutes or so ;-). Have you decided whether you're going to use the mbox protocol, remoteproc/rpmsg, or roll your own yet?
<sven>
we briefly talked about that. we'll have to discuss that with someone who knows the kernel much better than we do
<sven>
mailbox certainly makes sense for the very low-level protocol (think send/recv message). the more interesting question is where the common rtkit stuff should be implemented
<pipcet[m]>
can we combine the two approaches? use a mailbox for, uhm, the mailbox, and implement a remoteproc on top of that?
<sven>
sure, but remoteproc might still not be a good fit because it does a lot of heavy lifting for loading firmware
<sven>
i've also seen something where mailbox was just the mailbox and then there were just some exported functions in drivers/soc or drivers/firmware for talking to that specific mailbox
<pipcet[m]>
the firmware-loading part seem optional and reasonably independent, to me, and the rest of the API fits very well, I think...
bps has joined #asahi
<sven>
it's a little bit more complex. rpoc_boot e.g. usually really wants to load a firmware, but that can be worked around
<sven>
it's really something we need to discuss with someone who has more experience with these subsystems :)
<chadmed>
pipcet: afaict rproc_boot expects a valid ELF and will return not 0 if it doesnt get one unless the remote has already been initialised and given a handle by the subsystem
<chadmed>
but like sven said its probably something worth discussing with rproc gurus
<pipcet[m]>
we're not booting the coprocessors, we're just attaching to them :-). If sven has plans to discuss this with the right people that should happen, though.
aleasto has quit [Quit: Konversation terminated!]
<chadmed>
actually yeah true, we can get an rproc handle using the device tree and thus rproc_boot should just return 0 when it sees that the processor is on and ready to go
<svenpeter[m]>
We could just initialize the state to _DETACHED and then it won’t try to boot the thing
<svenpeter[m]>
But yeah, something I need to discuss with people who actually know these subsystems :)
<svenpeter[m]>
Because we need to do something similar to „boot“ (the whole syslog,… stuff)
kenzie has joined #asahi
<marcan>
sven/alyssa: I can take a look at the kernel side if you want, or leave it up to you, your choice ;)
<marcan>
if you all want to take it completely off of my hands, I'll go look at the installer and GPU ASC instead :p
bps has quit [Ping timeout: 480 seconds]
<svenpeter[m]>
I’m not gonna touch DCP
<svenpeter[m]>
But the stuff we discussed above kinda applies to everything that runs RTKit
atom1[m] has left #asahi [#asahi]
bps has joined #asahi
<marcan>
exactly
Andalu30 has quit [Remote host closed the connection]
<svenpeter[m]>
Happy to get your opinion what should be a mailbox, what should be a remoteproc and what should be something entirely else
Andalu30 has joined #asahi
Andalu30 has quit []
Andalu30 has joined #asahi
bps has quit [Ping timeout: 480 seconds]
bps has joined #asahi
<pipcet[m]>
sven: you can forget about the "persistent bad state" issue, by the way. Not only does your driver continue to work in that state, it actually cures it for the buggy driver, too.
<marcan>
lol
<pipcet[m]>
(I think I know what it is but that seems irrelevant now :-) )
<marcan>
let me guess: not handling syslog messages, which only happen on an unclean shutdown, making it wedge
<svenpeter[m]>
I don’t shut it down cleanly yet either fwiw
bps has quit [Ping timeout: 480 seconds]
Andalu30 has quit [Ping timeout: 480 seconds]
<alyssa>
marcan: If svenpeter[m] finishes the ASC driver I think I can fudge my way through v1 of the DCP driver
<alyssa>
would love to see AGX.kext r/ed in parallel ;-)
<alyssa>
(and that's the linux driver I really want to work on.. dcp is a warmup)
<alyssa>
Hmmm, so I have a fair bit of uninterrupted time today
<alyssa>
Do I...
<alyssa>
A) Do my homework
<j_ey>
B
<alyssa>
B) Write a DCP client in one crazed shitting
<alyssa>
C) Write gay fanfiction
<chadmed>
you shouldnt write drivers on the toilet, no lumber support
<alyssa>
sitting
<chadmed>
lumbar*
frode_0xa has quit [Quit: leaving]
<alyssa>
D) All of the above
<alyssa>
E) None of the above
<alyssa>
F) One of the above
<alyssa>
G) Two of the above
<chadmed>
C, then B, then A
<chadmed>
priorities are important after all
<brentr123[m]>
I recommended c ;)
<chadmed>
A can be safely omitted
<alyssa>
"oh, DCP, I love you" "my fair AGX, how I love you too" "let's get married!" "agxcp forever!"
<alyssa>
(I don't know what gender DCP and AGX are but I'm pretty sure the ship is gay regardless.)
<chadmed>
can they send dirty postcards to each others' mailboxes?
<alyssa>
svenpeter[m]: how does the linux kernel not freeze all the time
<alyssa>
except for the fact there's a tom's hardware article about it
<alyssa>
truly baffling.
<alyssa>
if you have an existing arm64 debian machine, it's just `debootstrap buster debinst-buster http://ftp.au.debian.org/debian/`
<sven>
alyssa: atomic vs. process context
<alyssa>
sven: 👂
<sven>
so for DCP you'll need to hack the DART driver to make it work with the pagetable apple allocated :(
<alyssa>
thanks for volunteering
<j_ey>
sven: why?
<sven>
j_ey: because that DART is locked by the time we get control
<j_ey>
oh :(
<sven>
yeah :/
<sven>
alyssa: very short version: in atomic context (e.g. interrupt handles or inside spin_lock_irqsave) you're not allowed to sleep and if you block in there you can easily hang everything. in process context you can sleep while waiting for something and the kernel will schedule something else to run
<alyssa>
Alright
<kettenis>
won't the kernel pan^H^H^Hoops when you try to sleep in such a critical section?
<sven>
don't think so. i've done that and it worked
<sven>
(for some value of worked)
<sven>
(but then again, i've also made everything hang from process context so maybe don't list to me too much :-))
<sven>
*listen
<sven>
alyssa: and for the mailbox part: just use the mailbox api for now. whatever ends up the correct solution has to be similar either way.
<sven>
i'm not very happy with the current driver i have for that but it'll work
bps has quit [Ping timeout: 480 seconds]
Andalu30 has joined #asahi
Raqbit8 has joined #asahi
Raqbit has quit [Ping timeout: 481 seconds]
Raqbit8 is now known as Raqbit
<pipcet[m]>
there's CONFIG_DEBUG_ATOMIC_SLEEP
bps has joined #asahi
bps has quit [Remote host closed the connection]
bps has joined #asahi
apetresc has quit [Ping timeout: 480 seconds]
Andalu30 has quit [Remote host closed the connection]
Andalu30 has joined #asahi
bps has quit [Ping timeout: 480 seconds]
Andalu30 has quit [Read error: Connection reset by peer]
bps has joined #asahi
roxfan has quit [Ping timeout: 480 seconds]
<alyssa>
sven: 👍
robinp_ has joined #asahi
robinp has quit [Ping timeout: 480 seconds]
bongotrumma has joined #asahi
robinp has joined #asahi
robinp_ has quit [Ping timeout: 480 seconds]
apetresc has joined #asahi
bongotrumma has quit [Ping timeout: 480 seconds]
bps has quit [Ping timeout: 480 seconds]
zimsneexh has joined #asahi
bongotrumma has joined #asahi
zimsneexh has quit []
bps has joined #asahi
bongotrumma has quit [Ping timeout: 480 seconds]
bongotrumma has joined #asahi
bongotrumma has quit [Ping timeout: 480 seconds]
bongotrumma has joined #asahi
bongotrumma has quit [Ping timeout: 480 seconds]
quarkyalice has joined #asahi
apetresc has quit [Ping timeout: 480 seconds]
pinskia has quit [Remote host closed the connection]