marcan 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
digitalfx1 has joined #asahi
digitalfx has quit [Ping timeout: 480 seconds]
klltkr has joined #asahi
klltkr has quit []
klltkr has joined #asahi
klltkr has quit []
klltkr has joined #asahi
klltkr has quit []
egavinc__ has joined #asahi
egavinc_ has quit [Remote host closed the connection]
bgb_ has joined #asahi
digitalfx1 has quit [Ping timeout: 480 seconds]
digitalfx1 has joined #asahi
kyjus25 has joined #asahi
kyjus25 has quit [Quit: Leaving.]
kyjus25 has joined #asahi
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
hspak0 has joined #asahi
hspak has quit [Ping timeout: 480 seconds]
hspak0 is now known as hspak
kyjus25 has quit [Quit: Leaving.]
Tom__ has joined #asahi
Thomas___ has quit [Ping timeout: 481 seconds]
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
digitalfx1 has quit [Ping timeout: 480 seconds]
digitalfx1 has joined #asahi
digitalfx1 has quit [Ping timeout: 480 seconds]
digitalfx1 has joined #asahi
leifm has quit [Quit: Connection closed for inactivity]
digitalfx1 has quit [Ping timeout: 480 seconds]
digitalfx1 has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
digitalfx1 has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
digitalfx1 has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
artemist has quit [Ping timeout: 483 seconds]
artemist has joined #asahi
VinDuv has joined #asahi
digitalfx1 has quit [Ping timeout: 480 seconds]
digitalfx1 has joined #asahi
r0ni has quit [Ping timeout: 480 seconds]
pugguu has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
VinDuv has quit [Quit: Leaving.]
<maz>
sven: ah, I see you caught my stupid MSI address bug! thanks for that! :D
<maz>
kettenis: ^^
<sven>
mostly kettenis, i just complained ;)
<sven>
but pcie works just fine now
bisko has joined #asahi
<maz>
sven: that's pretty awesome, thanks for pulling everything together. It'd be good to work on a series that enable that upstream.
<sven>
absolutely. i'm almost ready for the next version of the dart driver
artemist has quit [Ping timeout: 480 seconds]
frode_0xa has quit [Quit: leaving]
artemist has joined #asahi
frode_0xa has joined #asahi
frode_0xa has quit []
m42uko_ has joined #asahi
m42uko has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
<jannau>
any idea what might be at mmio address 0x23d2b9000? it is not mentioned in the ADT as far as I can see. mac os writes up to offset 0x20 quite often. at offset 0x0 is counter and it writes increasing values to offset 0x4, 0x8, 0x10 and 0x20
<pipcet[m]>
WDT?
<jannau>
could be, the WDT in the adt is at 0x23d2b8000
<pipcet[m]>
so it seems the ADT isn't entirely accurate :-)
<jannau>
that said, I handle PMC interrupts now in a way to shutdown mac os properly
<pipcet[m]>
jannau: what did you have to do?
<jannau>
trap the PMC msr and wrap the counters on IRQs
<jannau>
I'll prepare a PR
Mary has quit [Quit: Ping timeout (120 seconds)]
<pipcet[m]>
IRQs or FIQs, out of curiosity?
Mary has joined #asahi
<jannau>
FIQ
<jannau>
AIC IRQs are not handled by the hypervisor
<marcan>
jannau: thanks, had that on my TODO
<marcan>
I think you only need to wrap the control reg, right?
<sven>
kettenis: so.. clocks. it looks like we'll have to find a way to do with a single clock node. we discussed assigned-clocks at some point and concluded that wouldn't work, didn't we?
<marcan>
basically just keep a shadow flag for FIQ enable, disable the real one FIQ, re-enable once the guest clears the flag
<marcan>
*real one on FIQ
phiologe has joined #asahi
<jannau>
iirc the counters itself have be wrapped
<jannau>
interrupts are generated as long as bit 48 is set
<jannau>
I'll check. currently I'm shadowing bit 48 for each counter
PhilippvK has quit [Ping timeout: 480 seconds]
bgb_ has quit [Ping timeout: 480 seconds]
<hell__>
jannau: hmmm, now I wonder: if macOS writes to offset 0x20 of 0x23d2b9000 quite often, what happens if one blocks these writes?
<marcan>
jannau: there is an interrupt status bit in the control register
<marcan>
you can disable IRQ generation in the control register until the guest clears the status bit
<marcan>
which is what I was already doing but not shadowing it; the guest asserted because it saw IRQs disabled when it was trying to enable them
<kettenis>
sven: I believe assigned-clocks isn't the appropriate mechanism
<kettenis>
but if the people that matter think it is fine, then I won't object
<kettenis>
or we could add invent properties that have different names but work in a similar way
bgb_ has joined #asahi
grange_c9 has joined #asahi
grange_c has quit [Remote host closed the connection]
grange_c9 is now known as grange_c
<sven>
hm. so assigned-clock-parents is when i e.g. have a clock that can have one out of N parents and i want to select a specific default, isn't it?
<kettenis>
that is my understanding
<sven>
so i think linux actually requires the clock that's specified in assigned-clock-parents to already be a possible parent
<kettenis>
correct
<sven>
doesn't sound like that's the correct mechanism then :/
<sven>
unless i setup clocks 0,...,i-3, i-2, i-1 to be possible parents of clock
<sven>
which sounds like a huge hack
digitalfx1 has quit [Ping timeout: 480 seconds]
<j_ey>
sven: you didnt document force_bypass_offset and force_bypass_len, unsure if intentional?
<sven>
erm.. nope
<sven>
actually, let's make that yes! i obviously skipped that because it's part of the hack! :P
<j_ey>
I mean, thats what I was considering :P
<sven>
i also messed up their name. they should've been called fake_bypass
<sven>
j_ey: let's just go with that story then ;)
bgb_ has quit [Ping timeout: 480 seconds]
<j_ey>
"A single domain is used to represent a single virtual address spaces.", s/spaces/space/ (just if you end up doing a v4..)
digitalfx1 has joined #asahi
<sven>
oh, there'll definitely be a v4
Raqbit1 has joined #asahi
<j_ey>
sven: where are these magic numbers in apple_dart_hw_reset from?
<j_ey>
0x03020100 etc
<sven>
it's just 0,1,2,3,4,5,...
<j_ey>
lol
<j_ey>
it's backwards ok, it looks funky!
digitalfx1 has quit [Ping timeout: 480 seconds]
<sven>
yeah, it's because the hw only allows 32bit writes
crabbedhaloablut has quit [Ping timeout: 480 seconds]
Raqbit has quit [Ping timeout: 480 seconds]
Raqbit1 is now known as Raqbit
<sven>
now that i think about that again... it's probably not required
<sven>
i think iboot doesn't leave any dart with a stream remap around
<j_ey>
it can't hurt to be 'pedantic'?
<sven>
true
<j_ey>
conservative rather
crabbedhaloablut has joined #asahi
<sven>
ah. i also forgot a apple_dart_hw_enable_translation i left in there for debugging
<j_ey>
I was actually going to ask about that
<j_ey>
if you mean the one in the MAX_STREAMS loop
<sven>
yes
<sven>
i wanted to see which streamid pcie uses and a simple way to do that it to setup empty pagetables and enable translation
<j_ey>
and get a fault?
<sven>
yup
<sven>
it doesn't hurt to have that there but the code sequence is kinda dumb then
choozy has joined #asahi
bgb_ has joined #asahi
digitalfx1 has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
pugguu has quit [Ping timeout: 480 seconds]
pugguu has joined #asahi
digitalfx1 has quit [Ping timeout: 480 seconds]
pugguu has quit [Ping timeout: 480 seconds]
pugguu has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
<j_ey>
sven: wondering if apple_dart_tlb_flush_walk deserves a comment? looks like you have to flush a full domain at a time, since you ignore `iova`?
digitalfx1 has joined #asahi
<sven>
yeah, maybe
<sven>
i wonder if there is a way to only flush a certain iova range though
<sven>
there's this 32bit command register that has the flush bit and i doubt that they need 32 commands
<sven>
maybe some parts of it allow to select a subset
<jannau>
marcan: just not enaling PMC irqs and lying to the guest about it works as well
pugguu has quit [Remote host closed the connection]
<kettenis>
the self-referencing clock property doesn't trigger any magic within the linux clock framework?
<sven>
it requires a small hack. i just had to register the clock provider with "empty" clocks before assigning parents.
<sven>
otherwise it would get stuck in a EDEFER loop
<sven>
not sure if the maintainers will like that
<sven>
would that also work with openbsd and u-boot?
bgb_ has joined #asahi
artemist has quit [Ping timeout: 480 seconds]
<kettenis>
will have to check u-boot
<kettenis>
but I think it should be fine
<kettenis>
not much automatic clock processing u-boot
<pipcet[m]>
I may be missing something obvious again, but what's the reason for the self-reference?
<sven>
remember how the clock nodes like corellium did them sometimes had references to each other?
<pipcet[m]>
yes.
<sven>
the linux maintainers ideally want a single node for the clock controller. that self-reference is one way to represent the same thing in the device tree
<pipcet[m]>
no sub-nodes for the clocks?
<sven>
no
pugguu has quit [Ping timeout: 480 seconds]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pugguu has joined #asahi
<kettenis>
I wonder if you should just use a different name for that clocks property
<sven>
hm.. probably
<kettenis>
for example "clock-parents" or maybe "apple,clock-parents"
<kettenis>
could be a simple array of clock numbers
<sven>
i could also just get rid of the... yeah that
<pipcet[m]>
sven: I guess it's the best you can do under those strange circumstances, though I'd just do it right rather than introduce spurious self references
<sven>
pipcet[m]: why do you think the self-reference is spurious?
<pipcet[m]>
sven: because it would go away if we had one phandle representing each clock
<sven>
kettenis: sounds like a discussion for the mailing list though :-)
<pipcet[m]>
it's simply not true that there is a line connecting the pmgr to itself which serves both as input and output line; it's an internal line connecting one part of the pmgr, which should be represented as one node, to another
<kettenis>
sven: yeah, no clock peoplehanging out here it seems
<null>
The two ways this is generally done is either to have discrete nodes or to have the internal relationships between those be inferred from the compatible stirng in the driver
<null>
I haven't been a DT maintainer for a while now, but the self-reference doesn't seem right to me
<kettenis>
we deliberately don't want to have to encode the relationships in the driver
<pipcet[m]>
again, my armchair opinion is one phandle per clock would work best, as sub-nodes of the pmgr with the address in the reg property.
<null>
Sure; I'm just providing context, and I'd generally agree that it's preferable to get the hierarchy in the DT if this isn't really a discrete unit
<sven>
yup, this unit has been around for at least 7 years now with the only difference being the hierarchy and the available clocks
<kettenis>
the one-clock-per-node model still has my preference
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
<sven>
yeah, mine too
<pipcet[m]>
it also matches quite closely what clock-bindings.txt says.
bgb_ has quit [Ping timeout: 480 seconds]
pugguu has quit [Remote host closed the connection]
<kettenis>
sven: I've added the DART interrupts to u-boot
skipwich has joined #asahi
<sven>
nice!
<kettenis>
my problem was related to the commented out clocks, which as a cascading failure resulted in the pci bus numbering being wrong which in turn screwed up the iommu mapping
<kettenis>
making the clocks optional in u-boot fixed that issue
pugguu has joined #asahi
<kettenis>
do you have any thoughts on the PCI RID to DART SID mapping we should use?
<sven>
not yet. so the way i understand it we can actually program a sid mapping using some pcie config regs?
<kettenis>
I mapped everything to SID 1 since SID 0 seems to be a catch-all for all RIDs that aren't mapped explicitly in the PCIe host bridge
<kettenis>
yeah
bisko has joined #asahi
<kettenis>
in the end for the current hardware it doesn't matter all that much since we have separate DARTs for each root port and only one device on each root port
<kettenis>
and everthing is built-in, so no slots where folks can plug in PCIe bridges
<sven>
hm, that may change once we tackle thunderbolt though
<sven>
or is the pcie node for thunderbolt completely different anyway?
bgb_ has joined #asahi
<kettenis>
judging from the corellium code it is largely the same
<kettenis>
only has a sinle root port
<kettenis>
the assiocated DART has more features though it seems
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven>
i think i saw in the ADT that it has at least more sids
<kettenis>
right
<sven>
i wanted to look at it but the MMIO region only returned 0xffff.. for all reads
<sven>
probably needs more magic pokes before it's available
bgb_ has quit [Ping timeout: 480 seconds]
<sven>
hrm. so essentially the pcie hw provides functionality that's similar to what's described in iommu-map, doesn't it?
<kettenis>
yes, the idea is that the driver should program the RID to SID mapping registers to something that matches the iommu-map property
digitalfx1 has quit [Ping timeout: 480 seconds]
digitalfx1 has joined #asahi
bgb_ has joined #asahi
<sven>
makes sense
<kettenis>
then I think there is no real reason to change the pcie DT bindings schema
frode_0xa has joined #asahi
<kettenis>
the example uses SID 1, but we may use 0 in our actual device trees for a bit
<kettenis>
maz: if you have a few spare cycles to look at the way MSIs are done in the binding that would be great