<alyssa>
Tomorrow will be ~~cleaning up the pile of hacks~~ adding more hacks so I get 4k@60 on linux
<marcan>
you really care about your 4K don't you :p
<alyssa>
Look my chromebook is 2400x1600 on a laptop screen
<alyssa>
so no I am not putting up with 1080 on a 27" monitor
<marcan>
:p
<alyssa>
forefront on the pile of hacks is the mess of a DT i've made
<marcan>
ha
<alyssa>
I uhhh
<alyssa>
have a DCP driver and a KMS driver and they are independent modules with mutual references in their private structs it's not good
<marcan>
heh
<marcan>
they should probably be a single driver tbh :p
<alyssa>
this is a kludge to workaround linux only allowing a device to have a single IOMMU
<alyssa>
because why would a single device need multiple independent IOMMUs? :v
<marcan>
well, you can still have different devices from Linux's point of view, managed by one driver
<alyssa>
sven linked me to your clock gate thing as an example..?
<marcan>
that's kind of different, that's multiple devices sharing one register mapping
<alyssa>
the KMS driver needs to "own" disp0 stream 0, so that way framebuffer memory can be allocated by the DRM core and be automatically mapped with no driver twiddling
<marcan>
but I mean, you can have different drivers in one module that just happen to know about each other and share all kinds of private data
<alyssa>
on the other hand, the DCP module needs to "own" the DCP dart so the rtkit crap can just do dma_alloc_coherent properly
<alyssa>
Hum, alright. That seems sane
<alyssa>
in the DT is that modeled as sibling nodes or as parent/child?
<marcan>
sibling nodes with a reference, like interrupt-parent and such
<alyssa>
Okay, that's what I have now
<marcan>
so pick one that will be the "parent" driver that kicks everything off, then that defers probing until everything else is probed
<alyssa>
although then I needed deferred probe nonsense --- yeah
<marcan>
yeah I think this is all kosher
<alyssa>
alright, won't worry so much then
<marcan>
this is how apple does it anyway so...
<marcan>
there's prior art there too :p
<marcan>
(just they make a mess of it)
<alyssa>
Snrkt
<alyssa>
+ /* XXX: need to validate the DCP is allowed to access */
<alyssa>
oh meant to ask about this
<marcan>
for mappings?
<alyssa>
map_physical, the DCP only calls it with disp0 regs, yeah?
<alyssa>
(Obviously letting a copro map whatever memory it wants defeats the purpose of having an IOMMU)
<marcan>
it only call it right after sr_mapDeviceMemoryWithIndex(PROV, 4, 256, 0x23b3d0000, 0x4000)
<marcan>
which is looking up disp0, yes
<marcan>
so we should just check that it's one of the disp0 ranges I guess
<marcan>
possibly a subset
<alyssa>
👍
<marcan>
in this case it's disp0 index 4, though for us that might be a different index, in which case we'd want a mapping table anyway
<alyssa>
that's what I assumed but am trying to check my assumptions off you since you complained I don't ask enough questions 😋
<marcan>
good :)
<alyssa>
I see no reason not to just include the regs in Apple order in the DT
<marcan>
depends on what they do and what sense they make
<alyssa>
since AFAIK we have no reason to touch those registers ourselves ever
<marcan>
apple do some insane stuff with reg ranges
<marcan>
like mapping pmgr stuff in every goddamn device
<alyssa>
Grumble
<marcan>
also we *might* end up doing hacks on disp0 regs eventually
<marcan>
but for now you can just use the same ranges, sure
<marcan>
eventually I'd probably want a mapping table
<marcan>
like {4, <reference to what we call that range>} and then the map call can just check that what is being mapped is something in that table (resolved)
<alyssa>
<reference> being a reference to a DT name/index/handle/whatever?
<alyssa>
(so the regs are still in the DT, not hardcoded)
<marcan>
yeah, however we choose to represent it
<marcan>
could just be an offset from disp0 base or some disp0 subrange or whatever
<marcan>
yes
<alyssa>
of the disp0 regs only suspicious one is
<alyssa>
addr = 0x0000000071800000
<alyssa>
size = 0x0000000000800000, Container:
<marcan>
I don't see that in disp0?
<alyssa>
oh er that was dispext0 i'm tired
<alyssa>
addr = 0x0000000031800000
<alyssa>
size = 0x0000000000800000, Container:
<marcan>
0x231800000.... is DCP
<marcan>
0x230000000..... is disp0
<marcan>
see the big comment at the top of dcp.py
<marcan>
I did some snooping on the reg ranges
<marcan>
see what I said about the regs being a mess?
<marcan>
apple seriously doesn't care, they have drivers poking other devices' registers *everywhere*