ChanServ changed the topic of #asahi-gpu to: Asahi Linux: porting Linux to Apple Silicon macs | GPU / 3D graphics stack black-box RE and development (NO binary reversing) | Keep things on topic | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-gpu
<phire>
What you really want there is EDID override
SSJ_GZ has joined #asahi-gpu
SSJ_GZ has quit [Ping timeout: 480 seconds]
tdsdp^ has joined #asahi-gpu
tdsdp^ has quit [Remote host closed the connection]
chadmed_ is now known as chadmed
kov has quit [Quit: Coyote finally caught me]
dviola has quit [Quit: WeeChat 3.6]
<bluetail>
phire is the process of overriding EDID's more involved? I know there are a couple of scripts to make a new EDID - but you also have to enforce it, which probably includes a couple kernel parameters. I know modeline is pretty obsolete at this point but at least in my experience is more integrated in a way that you can change it on the fly to test
<bluetail>
it out. That said, I will look into EDIDs, perhaps there is a benefit of having those versus passing a modeline.
<marcan>
bluetail: just wait until DCP is done and merged and we have a good understanding of the DP control interfaces
<marcan>
unless you're going to help with that, until that happens, you're just wasting everyone's time hypothesizing about EDIDs and modelines
<marcan>
DCP has a SetVirtualEDIDMode method on some EPIC I think, which will might let you set a custom EDID. I do not see anything to add custom modes.
<marcan>
but this is nowhere near a priority for DCP, so if you're not going to help out yourself, you'll have to wait until we get there
<marcan>
we don't even support any EPIC calls at all in the current driver and likely won't for a while unless it's necessary for external monitor support
<lina>
robher: I have a question about reg mappings. The GPU driver needs to map a bunch of miscellaneous hardware into the GPU firmware page tables (not just the GPU itself, also random temperature sensors, power management, and interrupt related register ranges)
<lina>
In terms of data, it's a sparse list of <phys_start, len, readonly> tuples
<lina>
This is different per SoC. Since I think the driver will need explicit support for each SoC anyway, I'm tempted to just hardcode it in the driver as part of the per-SoC data... but do you think it should be in the device tree instead?
<lina>
This can also somewhat change between firmware versions, but the driver also needs explicit support for each firmware version so being flexible there also doesn't help
<lina>
And since currently we don't mess with the device tree based on firmware in the bootloader, that's probably an argument *not* to include it? Since it would require more complex firmware -> DT mapping in m1n1
<lina>
Note that the driver doesn't use any of those mappings, it only directly uses the firmware coprocessor mailbox/start stuff, and the GPU registers directly in special cases (those would be in the DT as regular reg entries)
<jannau>
the in progress DCP driver maps 1 "foreign" (iirc pmp) address range for the co-processor. So far it is in regs as that's what apple does in their device tree
<jannau>
the coprocessor requests the mapping by index (into apple's regs array)
SSJ_GZ has joined #asahi-gpu
<lina>
That's different from the GPU though. For the GPU, the driver just maps everything ahead of time and tells the firmware what the virtual addresses are.
<lina>
I think for DCP it makes sense to keep that in the DT, since I think the DCP interface is mostly the same for every SoC, at any given firmware version?
<lina>
But the GPU has a whole bunch of per-SoC parameters, so I don't think it's practical to try to make it generic across SoCs with just DT changes...
<jannau>
yes, I haven't seen firmware updates changing this yet. it's a constant address range per SoC