I have it now, but unfortunately changes nothing, I don't even see it in Xorg log.
You can't just modprobe a kernel driver and have it magically work. The kernel will load it but it will have no idea what it is
for and it is left unused. Unlike USB or PCI devices which can be detected and recognized based on standardized embedded identification, there is no standard way to even detect let alone identify a platform device. These need to be described in Device Tree:
alias: of:N*T*Cmarvell,dove-gpu-subsystem
alias: of:N*T*Cfsl,imx-gpu-subsystem
This shows the kernel will use this driver if it finds a DT node with compatible="marvell,dove-gpu-subsystem" or compatible="fsl,imx-gpu-subsystem". This immediately raises the question why the driver uses different identifiers for these two particular instances of a GC core (e.g. platform-specific quirks?) and whether a third one needs to be added for our use case. I have not inspected the driver but this will need to be done.
Next up is adding the DT node itself, which describes any address ranges, clocks, and interrupts that the driver needs to know about, along with the compatible-property referencing the driver, and any driver-specific properties it might need. It also needs a ti,hwmods property referencing module prcm data embedded in the kernel. This ensures that the power management framework knows how to power the module up/down and enable/disable its clocks, without which any access attempted by the driver will result in a bus error. This hwmod data itself might not yet be in mainline linux hence also needs to be added.
For an example of this, see the two patches
here which add a DT node and hwmod data for SGX. This DT node actually looks really iffy to me since the register range declared does not match the address in the DT node name and does not cover the whole peripheral. It was however copied from some TI tree and apparently does work somehow. If you don't want to dig deeply into how DT and hwmod stuff works, scavenging
existing linux trees for useful scraps is a good strategy.
If you get a kernel panic but aren't sure whether to blame the driver or the DT/hwmod data, you may be able to investigate by using the uio_pdrv_genirq driver (kernel config option CONFIG_UIO_PDRV_GENIRQ): Add the DT node but prevent the driver from loading (by changing/removing the compatible-property in DT or just making sure the kernel can't find the kernel module) so it'll show up in /sys/bus/platform/devices. Say it's named bb2d, then
echo bb2d >/sys/bus/platform/drivers/uio_pdrv_genirq/bind should make it appear as /dev/uio0. If you open this device it will trigger the power management framework to enable the device. If this doesn't crash then you can try to mmap() the device and access some harmless register (e.g. the word at offset 0x20 should be equal to 0x320 indicating a GC320, see TRM). If all of this seems to work then the DT/hwmod data is probably okay and debugging can shift to the driver.
Once you have the driver loading and successfully recognizing the GC320,
then you can start trying to experiment with libetnaviv and stuff that uses it.
What's wrong with TI's GStreamer implementation?
I'm not so much worried about the userspace part as I am about kernel components it will undoubtedly require to load firmware blobs onto and otherwise interact with the hardware subsystems. But who knows, maybe it turns out to be relatively painless