[Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

Hi Phillipp and all,

> Am 25.02.2019 um 21:42 schrieb Philipp Rossak <embed3d at gmail.com>:
> 
> 
> 
> On 25.02.19 14:12, H. Nikolaus Schaller wrote:
>> Now it compiles for all the omap variants (omap3,4,5). Sunxi is missing some asm header file and
>> jz4780 is missing some uaccess_kernel() function in an asm header. Should not be too difficult to
>> find replacements or API changes. Compile for Intel is not tested.
> 
> I will have a look on the sunxi issue in the next days.

do you already have done some test and got findings/patches/suggestions? Or something where I could help?


I have some progress to get the DDK1.14 on v5.0 running on omap3/4/5.

The main issue so far was that I did not have matching "compatible" entries in the device tree so
that probing the module did not succeed. And I had to port the CONFIG_RESET_CONTROLLER
setup for omap.

But then it started working.


Here on omap5:

	root at letux:~# ./gpu-demo
	autodetected driver package: omap5-sgx544-116
	compatible driver: omap_omap5_sgx544_116
	module name: pvr_omap_omap5_sgx544_116
	pvrsrvctl: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender
	System Version String: None
	Running gles1test1
	gles1test1: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender
	Running gles2test1
	--------------------- started ---------------------
	gles2test1: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender
	Running eglinfo
	eglinfo: symbol lookup error: /usr/local/omap5-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender
	root at letux:~# 

And on omap3:

	root at letux:~# ./gpu-demo
	autodetected driver package: omap3630-sgx530-125
	compatible driver: omap_omap3630_sgx530_125
	module name: pvr_omap_omap3630_sgx530_125
	pvrsrvctl: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender
	System Version String: None
	Running sgx_clipblit_test
	----------------- SGX CLipBlit test -----------------
	---------------------- Start ------------------------
	Call PVRSRVConnect with a valid argument:
	sgx_clipblit_test: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so: undefined symbol: drmOpenRender
	Running gles1test1
	gles1test1: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender
	Running gles2test1
	--------------------- started ---------------------
	gles2test1: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender
	Running eglinfo
	eglinfo: symbol lookup error: /usr/local/omap3-pvrsgx/lib/libsrv_um.so.1: undefined symbol: drmOpenRender
	root at letux:~# 


I am not sure where the user-space library problems come from. I think I have the correct DDK1.14 user space for
omap from

	git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git

but you never know:

	http://e2e.ti.com/support/legacy_forums/embedded/linux/f/354/p/567306/2081687

But maybe it is simply because the -D flags of my in-kernel Makefile are not yet exactly correct.

My old DDK1.9 user space (the one with the sgx_clipblit_test) is still installed on the omap3 machine in parallel,
but obviously it is fundamentally incompatible.

The reason is that the ioctl command codes e.g. PVRSRV_BRIDGE_CORE_CMD_FIRST in pvr_bridge.h differ
between DDK1.9 and DDK1.14.

This is important to remember that this can unfortunately not be considered a stable API between DDK versions.
This might become a big problem for upstreaming, unless there is an independently developed user-space where
we have control over such constants. IMHO we should try to avoid supporting multiple variations here.


Finally I have mirrored my latest code (letux/latest-pvr rebased to v5.0) into our common git repo and started
to write a Wiki home page there:

	https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/wiki

> Regards,
> Philipp

Best regards,
Nikolaus