PedroAraujo[m] has quit [Ping timeout: 240 seconds]
winocm has joined #asahi-dev
konradybcio has joined #asahi-dev
xerpi[m] has joined #asahi-dev
emily has joined #asahi-dev
PedroAraujo[m] has joined #asahi-dev
carlosn has joined #asahi-dev
JTL_ has joined #asahi-dev
bkero_ has joined #asahi-dev
vimal has quit [*.net *.split]
carlosn1 has quit [*.net *.split]
JTL has quit [*.net *.split]
bkero has quit [*.net *.split]
vimal has joined #asahi-dev
carlosn1 has joined #asahi-dev
JTL has joined #asahi-dev
JTL has quit [Max SendQ exceeded]
vimal has quit [Max SendQ exceeded]
carlosn1 has quit [Ping timeout: 254 seconds]
VinDuv has joined #asahi-dev
yuyangchee98[m] has quit [Ping timeout: 244 seconds]
PedroAraujo[m] has quit [Ping timeout: 244 seconds]
xerpi[m] has quit [Ping timeout: 244 seconds]
emily has quit [Ping timeout: 244 seconds]
mofux[m] has quit [Ping timeout: 244 seconds]
ewlsh[m] has quit [Ping timeout: 244 seconds]
bylaws has quit [Ping timeout: 244 seconds]
Eighth_Doctor has quit [Ping timeout: 244 seconds]
<sven>
how very strange. the disp0-dart seems to have two blocks: one DART and one thing the device tree calls SMMU. the usb dart otoh seems to have two blocks and both looks like DART.
<sven>
"DARTLLT" and "DARTBLK"
xerpi[m] has joined #asahi-dev
vimal has joined #asahi-dev
ewlsh[m] has joined #asahi-dev
mofux[m] has joined #asahi-dev
bylaws has joined #asahi-dev
<marcan>
sven: USB3 is... complicated, maybe there are separate DARTs for e.g. host/device mode, or for data and controller shenanigans, or stuff like that?
<sven>
possibly
<marcan>
like I think most xHCI controllers run firmware and stuff, so maybe there's a carve-out for that
<marcan>
are either of them already configured by the time we run?
acelogic has joined #asahi-dev
<sven>
they are power gated by the time we run. I can re-enable power/clocks and then there's some stuff left in the registers, but no valid pagetables as far as I can tell
<sven>
hrm, though I wonder what happens if I enter DFU mode and then reboot
<sven>
hm, nope. no change
<sven>
the audio video encoder seems to have two of these DARTs and another SMMU according to the device tree
<sven>
(assuming that ave actually means audio/video encoder, heh)
yuyangchee98[m] has joined #asahi-dev
PedroAraujo[m] has joined #asahi-dev
emily has joined #asahi-dev
Eighth_Doctor has joined #asahi-dev
encounter[m] has joined #asahi-dev
<sven>
ugh.. I guess there's no way around actually bringing up usb to play around with the device side
maor26 has quit [Ping timeout: 240 seconds]
bkero_ is now known as bkero
bkero has joined #asahi-dev
bkero has quit [Changing host]
<modwizcode>
SMMU is the arm standard iommu thing
<sven>
let's call this one Apple SMMU then, heh
<sven>
I'm quite sure it's not the arm standard thing
<modwizcode>
I wonder if it's related at all though
<modwizcode>
or maybe just abused acronym
<modwizcode>
since SMMU I believe stands for system mmu
<sven>
I haven't found any evidence that this apple smmu even has pagetables
<marcan>
sven: shot in the dark: something something virtualization?
<marcan>
much like this thing has a vGIC for VMs...
<modwizcode>
That was kind of my thought originally
<sven>
I can't even seem to change most registers in there fwiw
<marcan>
maybe there's a lock/enable in the DART side?
<marcan>
that would make sense if it really is a thing meant for VM guests
<sven>
maybe. it's not present for all DARTs in the device tree though
<sven>
usb e.g. doesn't have it
<modwizcode>
The SMMU docs are unusually dense even for ARM, I tried pulling them up for some conceptual/possible functionality reference and it was not helpful
<marcan>
yeah, so maybe just things you might reasonably want to pass to a guest
<marcan>
... like graphics/display
<modwizcode>
USB might have a more complex reassignment method
<sven>
hm, fair enough
<marcan>
I would not expect USB to be passed through
<modwizcode>
I haven't read any specs but isn't there some specific feature of xHCI targeted towards virtualization?
<sven>
we can pretty much ignore it for now anyway, I'm just curious :-)
<marcan>
modwizcode: there is some stuff, yeah
riker77 has quit [Quit: Quitting IRC - gone for good...]
<marcan>
not sure if anything implements it properly though :)
<modwizcode>
I seem to remember that that's maybe why xHCI based things make passing through individual devices much more sane compared to other setups. But it's not the kind of thing I would dig into.
<modwizcode>
Apple has an API for paravirtualized graphics support for virtualization, but it has like... no meaningful docs.
<modwizcode>
I don't even know if there's an API enough to use it yet given the docs on the site.
<modwizcode>
Hmm
<modwizcode>
there's actually seemingly some matching between offsets and some stuff I see in the SMMU linux driver.
<sven>
which ones?
<sven>
the pagetables are very similar fwiw
<modwizcode>
fault address seems to be in the right place
<modwizcode>
16 streams matches up (without an extension you get 16 streams, with extensions you get 16 bits for streams)
riker77 has joined #asahi-dev
<modwizcode>
latter point isn't really that relevant
<sven>
huh, so maybe the arm secification just totally confused me
<modwizcode>
what ARM's SMMU calls context bank is possibly in the correct place but dynamic constants make it hard to tell
<modwizcode>
I could be just seeing what I want to see
<sven>
are you talking about the SMMU or the DART range?
<sven>
hm... maybe DART was inspired by the arm smmu
<sven>
but it certainly doesn't line up with the smmu registers
acelogic has quit [Remote host closed the connection]
<modwizcode>
There's a lot of versions, I think it's kind of like a v1
arvimal has joined #asahi-dev
<sven>
ooookay.. I think the SMMU does some kind of scatter/gather DMA
<modwizcode>
that's exciting
<sven>
I've mapped the whole frame buffer to a single page with DART
<sven>
and then I've tried memset32(0x0000000231302000, 0, 0x20) and varied the size
<sven>
oh, and I set that one page to 0xffffffff to have a white screen
<sven>
and depending on the size I chose in that memset a black contiguous area appears for a brief moment at different places
<sven>
and the size controls, well, the size :-)
vimal has quit [Ping timeout: 240 seconds]
<sven>
yup, and if I memset32(0x0000000231302000, 0x809e0df8, 0x100) and set the buffer at 9e... to 0x88888888 the bar that appears is green
<modwizcode>
Interesting
<sven>
now I wonder if there's a bit to disable the automatic filling of that table
<modwizcode>
Is it actually doing some kind of memory op or is it just more granular mapping? (If I'm understanding things right)
<sven>
the page size still seems to be the same
<sven>
it's a little bit weird. I originally though this is just some kind of cache or something, and it just might still be
<sven>
but the SMMU names makes me suspicious this might be more than just a cache
<modwizcode>
The S has so many possibilities :p
<modwizcode>
Suspicious MMU
<sven>
:D
Thomas__ has quit [Ping timeout: 260 seconds]
Thomas__ has joined #asahi-dev
<modwizcode>
I think you're probably right it's not a cache, based on the fact that not every device has one
<sven>
it's only present for disp0, dispext0 and ave in the device tree
<modwizcode>
My first thought here though is it's some kind of GARt
opticron_ has joined #asahi-dev
<jn__>
(ah, ARM's SMMU has already been mentioned, good)
odmir has quit [*.net *.split]
brandas has quit [*.net *.split]
jaalsa has quit [*.net *.split]
arnd has quit [*.net *.split]
opticron has quit [*.net *.split]
vijfhoek has quit [*.net *.split]
skg has quit [*.net *.split]
commandoline has quit [*.net *.split]
lethalbit has quit [*.net *.split]
krbtgt has quit [*.net *.split]
dlnx`` has quit [*.net *.split]
agraf has quit [*.net *.split]
milek7 has quit [*.net *.split]
odmir has joined #asahi-dev
brandas has joined #asahi-dev
arnd has joined #asahi-dev
lethalbit has joined #asahi-dev
jaalsa has joined #asahi-dev
commandoline has joined #asahi-dev
vijfhoek has joined #asahi-dev
skg has joined #asahi-dev
krbtgt has joined #asahi-dev
milek7 has joined #asahi-dev
dlnx`` has joined #asahi-dev
agraf has joined #asahi-dev
<modwizcode>
sven: Can I get a full dump from the SMMU range?