ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
flacks_ has joined #dri-devel
flacks has quit [Ping timeout: 480 seconds]
flacks has joined #dri-devel
flacks_ has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
flacks_ has joined #dri-devel
flacks has quit [Ping timeout: 480 seconds]
flacks has joined #dri-devel
Lucretia has quit []
flacks_ has quit [Ping timeout: 480 seconds]
cbaylis has quit [Ping timeout: 480 seconds]
Lightkey has quit [Ping timeout: 480 seconds]
flto has quit [Ping timeout: 480 seconds]
Lightkey has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
boistordu has joined #dri-devel
boistordu_old has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<craftyguy>
what do I need to do in order to get messages from DRM_DEV_INFO printed in the kernel log?
Company has quit [Quit: Leaving]
sneil_ has joined #dri-devel
sneil has quit [Ping timeout: 480 seconds]
sneil has joined #dri-devel
sneil_ has quit [Ping timeout: 480 seconds]
flto has joined #dri-devel
flto has quit [Remote host closed the connection]
flto has joined #dri-devel
flto has quit [Remote host closed the connection]
flto has joined #dri-devel
flto has quit [Remote host closed the connection]
flto has joined #dri-devel
flto has quit [Remote host closed the connection]
agx has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
agx has joined #dri-devel
NiksDev has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
<marcan>
for your amusement, this is the API between the M1's display controller firmware and the OS: https://mrcn.st/p/W4ijTdUF
<marcan>
yes, they really did just move half of the IOKit hardware driver to a coprocessor, and thunked all the method calls in both directions, with a bunch of extra glue for things like memory buffers
<marcan>
mapping this to Linux is going to be... fun.
<HdkR>
That's cute
<marcan>
there's at least two *different* binary-json-like serializations involved
<marcan>
(one is decoded there, the dicts and stuff; the other is used in the big setDCPAVPropChunk blobs which are split due to being too big, so I can't even decode it at the call layer, that needs to be done higher level)
<marcan>
and apparently two or three different property namespaces with different APIs; some named, some use an enum for prop IDs
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<marcan>
also, this ABI changes with each macOS release, which is paired with the firmware (which is loaded by the bootloader)
<marcan>
so that means I'm going to have to declare a subset of firmware "personalities" golden for use with Linux, and we'll only support those, mostly upgrading when there's a reason to (bugfixes or new hardware support)
<marcan>
(dual-boot isn't an issue because this is per-OS-install, so Linux will just, from the machine's POV, be like a macOS install of one of a subset of golden versions)
<marcan>
unfortunately we don't get to control what firmware is loaded, that depends on what was installed when the bootloader was set up, so we need to support old versions so people can still upgrade their kernel without going through bootloader re-provisioning/upgrading
NiksDev has joined #dri-devel
thellstrom has joined #dri-devel
<airlied>
marcan: that is pretty horrific :-P
<marcan>
yup...
<marcan>
so far my plan is to prototype a driver for the display part in my python thing, then once we have the GPU putting triangles on the screen too the same way start thinking about a DRM driver
<marcan>
I'll probably want to auto-generate the marshalling/bindings for this mess to some extent. I'm describing them in Python in a way that I should be able to use them both for tracing, the Python driver, and generating kernel code/whatever I end up going with there
<marcan>
but I still don't know the specifics of what it's going to look like in the end
<marcan>
(also not even sure if it makes sense to put python stuff into the kernel build system, or just submit generator output a la AMD; I've seen Python usage in kbuild but it's rare)
<airlied>
yeah I'd probably suggest just generating the code and landing it post generation, I suppose it depends on whether you are generating a lot of impenetrable C code or just tables to feed some hand written impenetrable C code
<marcan>
it would basically be a bunch of marshalling stuff, so thunks that shove args into a buffer then call the RPC, or thunks that parse args from a buffer then call a callback
<marcan>
I'm not sure how much it varies version to version; haven't seen it be massively different so far, but calls do get added/removed and methods renumbered, so at the very least there will be different ID number tables for different versions, and I'm guessing at some point some structs are likely to change layout
<marcan>
I guess this whole thing *could* be done with varargs and dynamic code and tables instead of static code, but that breaks static checking of the args and I'm not sure it's a good idea... and it doesn't really work for callbacks
<marcan>
unless we use a single "struct args" for callbacks or something, but ugh
danvet has joined #dri-devel
<airlied>
hopefully the same style is useful for at least the accel part of the gpu as well
<airlied>
marcan: any idea if any other devices got the same treatment? or just display?
<marcan>
so the fun thing is there's a *different* RPC interface in use for other DCP endpoints...
<marcan>
which I haven't even started looking yet
<marcan>
I get the feeling this one with all this complexity is special for the DCP, because it's the only place they went full batshit insane and moved random chunks of a class into a copro
<marcan>
I think the others are less crazy and more of a straightforward RPC thing
<marcan>
I don't know what the GPU does quite yet, but I'm hoping it's less crazy
<marcan>
seems like it should be
<marcan>
the underlying mailbox protocol and system endpoints (for things like syslog from the coprocessors and startup and endpoint enumeration) is shared, that will be a common mailbox driver for everything (there's like 8 or more of these things)
<marcan>
it's what they build on top as extra endpoints that changes
<airlied>
marcan: any idea if you could bypass the copro or if it would be worth it?
<marcan>
DCP has one special endpoint which does what I pasted above, and then a bunch of different endpoints dedicated to things like displayport, HDCP, the DP2HDMI chip, etc which I *think* more straightforwardly correspond to complete IOKit drivers (not a method-by-method mess like DCP)
<airlied>
I assume there is an actual mmio device somewhere that is getting registers hit by the copro
<marcan>
airlied: we can, AFAIK, but I'm not sure I want to sign up to write things like DP training code and realtime bandwidth calculations...
<marcan>
plus, there's *another* copro, a cortex-m3 apparently, because I guess DCP wasn't realtime enough, and DCP spins that up
<marcan>
we must go deeper
<marcan>
I'm kind of hoping that this mess will at least make supporting newer hardware/features easier, even if it sucks initially
<marcan>
also, I do have MMIO tracing for the main OS, but not for the copro, and I'm not sure I can touch the copro code
<marcan>
though macOS does seem to have a non-DCP driver for the same hardware, so perhaps if that can be made to work I could trace it all and see what the mmio interface looks like
<marcan>
the DCP firmware is 7MB of stuff (!)
<marcan>
including strings like
<marcan>
GRGB Tunneled as YCbCr422 (Even line red)
<marcan>
GRGB Tunneled as YCbCr422 (Even line blue)