nirgo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chadmed has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
balrog has quit [Ping timeout: 480 seconds]
bmrgz[m] has quit [Server closed connection]
bmrgz[m] has joined #asahi-dev
balrog has joined #asahi-dev
lewurm has quit [Server closed connection]
lewurm has joined #asahi-dev
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi-dev
PhilippvK has joined #asahi-dev
<marcan>
pushed SMC stuff I had to smc/work; going to work on hooking up the GPIOs to PCIe now
phiologe has quit [Ping timeout: 480 seconds]
<marcan>
jannau, sven: why not just have a property in the DART node that tells the driver to not reset it and inherit the iova mappings (the driver should then verify that none of them are in the normal RAM range, and complain loudly about firmware bugs if they are)
<marcan>
that works for both locked and non-locked DARTs then, it'd basically implement the same thing
<marcan>
(except for non-locked DARTs we can move the TTBR if we want to)
<marcan>
after all, we need this for locked DARTs anwyay
<marcan>
(a subset)
<marcan>
*superset
<marcan>
firmware leaving behind mappings in normal RAM space is a bug anyway
<marcan>
prior stages should always clean up
<marcan>
for DARTs for devices that can be shut down, the TTBRs should be torn down entirely; for DARTs that need to stay alive (DCP and DISP0), all mappings in normal RAM should be removed
<marcan>
I added code to m1n1 to clean up DART page tables that are allocated out of the heap on exit, for DCP/DISP0
<marcan>
in fact this feature is sort of orthogonal to locked DART support; there should be an apple,inherit-mappings thing or something, and that would be set both for DCP and DISP0; it would mean on startup we walk the page tables and validate/absorb those mappings
<marcan>
then if the DART is not locked, we just set a TTBR as usual replacing the existing one (and from that point on we don't care about the firmware-allocated PTs)
<marcan>
if the DART is locked we atomically copy out the top level PT on top of the existing one, then use that instead
<marcan>
and that's orthogonal to whether the mappings got inherited or not (though in practice there's no case where they aren't and the DART is locked of course)
LorenzKofler[m] has quit [Server closed connection]
LorenzKofler[m] has joined #asahi-dev
drwhax[m]1 has quit [Server closed connection]
drwhax[m]1 has joined #asahi-dev
jbowen has joined #asahi-dev
as400[m] has quit [Server closed connection]
as400[m] has joined #asahi-dev
latko[m] has quit [Server closed connection]
latko[m] has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
l3k[m] has quit [Server closed connection]
l3k[m] has joined #asahi-dev
Sebhl[m] has quit [Server closed connection]
Sebhl[m] has joined #asahi-dev
dsrt^ has joined #asahi-dev
_jannau_ has quit [Server closed connection]
_jannau_ has joined #asahi-dev
RianSouzaSantos[m] has quit [Server closed connection]
<jannau>
I'm under the impression that sven thinks upstream will not like/accept it
<jannau>
this currently is controlled by the dart being locked, the disp0 dart is soft-locked by a property in the dtb
<jannau>
decoupling locked form inherit-mapping would not be a problem
jbowen has quit [Ping timeout: 480 seconds]
<sven>
I briefly talked with robin who maintains the iopgtbl code and he was not very happy about reading out mappings and iirc called that something like a last resort
<sven>
It also requires a bit of hacking because for DCP we’ll need to switch from the default dma domain to an unmanaged domain
<jannau>
the only problem I see with having the memory-regions/mappings in the dtb is that there are no bindings to express that
<jannau>
I'm working on a proposal that would work for dart/dcp: using reserved-memory and define how it should be mapped in the iommu node
<sven>
yeah, I think he then pointed me to that thread on the iommu list that’s been in flight for months now because no one cares enough to see it through ;)
<sven>
hrm, i guess if we do have to fall back to apple,inherit-mappins we could read them out in probe, stash them somewhere and the re-create them when a domain is attached before overwriting the TTBR though
jeffmiw has quit [Ping timeout: 480 seconds]
joske has joined #asahi-dev
joske has quit [Quit: Leaving]
<marcan>
I mean, what's the advantage of putting this in the DT vs reading out mappings?
<marcan>
in principle the firmware could decide to do whatever crazy mappings it wants all within reserved memory, and we'd have to preserve that
<sven>
i'm also fine with apple,inherit-mappings and making sure those mappings don't point to normal RAM fwiw
ybk[m] has quit [Server closed connection]
ybk[m] has joined #asahi-dev
<sven>
if we do that we'd need to adjust iopgtbl to allow walking the pagetable and returning the mappings and then re-create them on every domain attach (which we need for the switch from DMA to UNMANAGED and also if we wanted to support re-probing because that also cycles the iommu domain iirc)
IsfarSifat[m] has quit [Server closed connection]
IsfarSifat[m] has joined #asahi-dev
wollymilkcap[m] has quit [Server closed connection]
wollymilkcap[m] has joined #asahi-dev
jbowen has joined #asahi-dev
sppdqd[m] has quit [Server closed connection]
sppdqd[m] has joined #asahi-dev
josipknezovic[m] has quit [Server closed connection]
josipknezovic[m] has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #asahi-dev
<kettenis>
marcan: we still don't really have a clue what the 0x800000 on the wifi gpios is about is it?
<j`ey>
marcan: I noticed the smcgpio doesnt have an of_match_table, obviously it's still WIP, but is that just missing, or does it get probed some other way?
NotHere[m] has quit [Server closed connection]
NotHere[m] has joined #asahi-dev
citruscitrus[m] has quit [Server closed connection]
citruscitrus[m] has joined #asahi-dev
dsrt^ has quit [Remote host closed the connection]
dsrt^ has joined #asahi-dev
rethematrix[m] has quit [Server closed connection]
rethematrix[m] has joined #asahi-dev
long[m] has quit [Server closed connection]
long[m] has joined #asahi-dev
matthewayers[m] has quit [Server closed connection]
matthewayers[m] has joined #asahi-dev
ryanhrob[m] has quit [Server closed connection]
ryanhrob[m] has joined #asahi-dev
roxiun[m] has quit [Server closed connection]
roxiun[m] has joined #asahi-dev
dsrt^ has quit [Ping timeout: 480 seconds]
dsrt^ has joined #asahi-dev
<j`ey>
ah no, I figure it out, smc_core.c has a bunch of drivers in apple_smc_devs
mariogrip[m] has quit [Server closed connection]
mariogrip[m] has joined #asahi-dev
nirusu[m] has quit [Server closed connection]
nirusu[m] has joined #asahi-dev
dsrt^ has quit [Ping timeout: 480 seconds]
ghantaz[m] has quit [Server closed connection]
ghantaz[m] has joined #asahi-dev
sproede[m] has quit [Server closed connection]
sproede[m] has joined #asahi-dev
Rhys[m] is now known as Rhys[m]1
Rhys[m]1 is now known as Rhys[m]12
Rhys[m]12 has quit [Quit: Reconnecting]
Rhys[m]12 has joined #asahi-dev
gladiac has quit [Quit: Ping timeout (120 seconds)]
gladiac has joined #asahi-dev
<marcan>
kettenis: we don't, I'm just going to ignore it for now. seems to work fine without it.
<marcan>
wouldn't even be that surprising if it's useless and some legacy thing even
<alyssa>
if I'm not mistaken, your examples for the big-endian machine are all backwards?
<alyssa>
%p4ch should be different for big/little, whereas %p4cl and %p4cb should be the same?
<alyssa>
unless I don't understand what the &(u32) notation means?
<phire>
Am I right in assuming that 0x1507008000 is a userspace pointer?
<phire>
hv_translate returns 0
<sven>
that's certainly not a kernel pointer
<sven>
what are you looking at? it's a bit too large for something mapped through DART
<sven>
(though, some DARTs may support >32bit on the Max/Pro)
<phire>
This is a pointer that's being passed into AGX (I think)
<sven>
ah, could be something mapped through the GPU's IOMMU then
<phire>
which there doesn't seem to be any details about in the adt
<sven>
yeah, that node is just a hack
<sven>
the kext that attaches to it just calls back into the main GPU kexy
<sven>
*kext
<alyssa>
phire: ah the GART
<phire>
is that it's name?
kaprests has quit [Server closed connection]
kaprests has joined #asahi-dev
<alyssa>
Yep
<alyssa>
as opposed to DART
<alyssa>
Apple are... quite creative when it comes to naming.
<phire>
Do we know anything about it? Can we assume it's just a more specialized DART
<phire>
or might it be something completly difrent
<sven>
i briefly looked at the strings of the kext and it sounded very different
<phire>
which kext?
<sven>
the agx kext, i'd have to look up its name
<sven>
but it had strings about GART
<chadmed>
would it be a GART in the tradtitional sense?
<sven>
absolutely not :D
<phire>
IOGraphicsFamily.kext doesn't mention it
<sven>
AGXG13X.kext
<sven>
not sure if that's the correct one but it has some strings about "Gart"
<sven>
"AGXSecureGart""
<phire>
that's it
<kettenis>
what is a "GART in the traditional sense"?
<chadmed>
graphics address remapping table
<chadmed>
but no, theyve just reused the acronym for something different in a graphics device. real genius stuff.
<phire>
They refer to "GartTables" in the string
<chadmed>
ioreg also lists AGXGart/AGXSecureGart classes in IOKit
<sven>
yes, that's the stub kext that just forwards everything to the real gpu driver
<phire>
the strings seem to indicate that the firmware is in charge of Gart
<phire>
but I haven't seen any messages to the firmware with enough entropy to even setup Gart
<phire>
so I'm missing a communication channel
<alyssa>
phire: I would expect gart to be registers direct to the CPU no?
<alyssa>
Programming the MMU sounds like the kernel's job
<phire>
That's what I would have thought
<alyssa>
but it's missing in the DT?
<sven>
let's move to -re :)
jbowen has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
jbowen has quit [Ping timeout: 480 seconds]
nirgo has joined #asahi-dev
jbowen has joined #asahi-dev
yuyichao has joined #asahi-dev
Gaspare has joined #asahi-dev
Major_Biscuit has quit [Ping timeout: 480 seconds]
m6wiq has joined #asahi-dev
<povik>
the ADMAC peripheral appears to have four independent interrupt line outputs
<povik>
and e.g. /arm-io/admac-sio has only the second line wired to AIC
<povik>
how do i express this in devicetree?
<povik>
options:
<povik>
(1) interrupt-names containing one of four names
<povik>
(2) vendor property
<povik>
(3) there's something called interrupt-map in pci bindings, may apply here
<povik>
i like (1) but binding documentation discourages looking interrupts by name, not having fixed order in interrupts=
<povik>
(later i will confirm this in an experiment, but by looking at ADT i see that /arm-io/admac-aop-audio, another ADMAC instance, exposes different output to AIC, so this can't be hardcoded)
<povik>
and in case of (2) i accept naming suggestions, if there's standard nomenclature for this kind of thing better than apple,interrupt-line
<povik>
fwiw apple seems to call this irq-destination-index
<kettenis>
I don't understand, there is only a single interrupt listed for those admac controllers
<povik>
yes, from the register map you can tell there are four independent interrupt outputs on ADMAC
<povik>
and the one selected by irq-destination-index is the one listed
<kettenis>
so you mean for the other ADMAC you have to look at the register at offset 0x0030 to get the mask of channels that have interrupts pending?
<povik>
actually it would be 0x0038, if i am not mistaken, as opposed to 0x0034 on the ADMAC we know
<povik>
that's in effect what this is
<kettenis>
wait, index 1 maps to 0x0038 and index 2 maps to 0x0034?
<povik>
no the other way
<povik>
index 1 is on /arm-io/admac-sio, where we look at 0x34
<povik>
2 on the other, we look at 0x38
<povik>
yeah, seems to check out with the driver code
<povik>
or are you looking at 0x38 in your driver and it works? that would we weird
<kettenis>
oh wait, audio is on admac-sio and admac-aop-audio is used for something else...
<povik>
microphones :-)
<povik>
you know what. let me do one other thing then i will do the experiment
<kettenis>
well, I think the interrupts property can only describe interrupts that are actually connected to the interrupt controller
<kettenis>
so you'll need another property to describe which register to look at
Gaspare has quit [Quit: Gaspare]
<povik>
uh, this isn't so easy enabling all the power domains for admac-aop-audio
Deewiant has joined #asahi-dev
<povik>
fu, that took longer than expected, anyway let's poke
<povik>
let's see where those AIC registers are again
<povik>
yeah, one should look at 0x38 for /arm-io/admac-aop-audio
<povik>
behaves as postulated
j`ey has quit [Server closed connection]
j`ey has joined #asahi-dev
<kettenis>
well, that isn't an AIC register
<povik>
no, but i am looking at HW_STATE register in AIC to confirm which interrupt line it reflects
<povik>
"which of 0x30, 0x34, 0x38, 0x3c will reflect what the AIC's HW_STATE does?"
<povik>
(i am having the cause and effect in reverse here but you get the idea)