Hi,
Adding Philip to Cc too as the sunxi folks too are interested in getting sgx usable with mainline kernels.
* Merlijn Wajer merlijn@wizzup.org [190210 16:12]:
Hi,
On 23/01/2018 14:38, H. Nikolaus Schaller wrote:
Hi all, based on initial work by Moaz Korena [1] and with the help of Adam Ford and Tony Lindgren, I have worked for a while on a new SGX driver for OMAP.
Now, I finally managed to write a master-Makefile that allows to build multiple variants of the sgx driver without having to config the build for a specific single SoC and forces us to choose the SGX version at compile time. This allows to build MULTI_PLATFORM kernels.
This means we currently get three different kernel modules: /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3630_sgx530_125.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_omap3_sgx530_121.ko /lib/modules/4.15.0-rc9-letux+/kernel/drivers/staging/pvr/omap3/pvr_ti335x_sgx530_125.ko
They are for:
- DM3730 based devices (e.g. Torpedo DM3730, BeagleBoard XM, GTA04, Pandora 1GHz)
- OMAP3530 based device (e.g. OpenPandora 600MHz, BeagleBoard C)
- AM335x based devices (e.g. BeagleBone, PocketBeagle)
Regardless of if and how this could be upstreamed, is there a more recent version of this work? I think there is tremendous value in having a combined repo (and combined effort) to get PowerVR to work on top of mainline (even though it might never be merged into mainline).
I have a couple of devices that I'd like to try getting PowerVR to work on. We (Maemo Leste) have it working on the Nokia N900 (forward port of nemo mobile kernel+userspace), but X11 works with acceleration, although some issues remain.
But I would also like to try to get it to work on the Motorola Droid 4 (also omap). And Pawel (in CC) has exynos devices with PowerVR, and he's also trying to get something to work [1] [2]. I also have a Pandaboard ES specifically for this purpose.
Ideally we'd use drm+modesetting drivers with dri3wsegl [3], but I have yet to try to make that work. :)
And just to add some notes I've already mentioned before, there's nothing stopping us from having a generic mainline kernel module for slow 2d acceleration based on what we already have for sgx540 in drivers/gpu/drm/gma500/psb_drv.c.
If anybody is interested in that, grep for PSB_RSGX32 and PSB_WSGX32 in the mainline kernel tree. That way at least the generic parts for regulators, clocking, and interrupt handling could be upstreamed. I think only the SoC specific wrapper hardware is different, the SGX code should be generic.
Regards,
Tony
Cheers, Merlijn
[1] https://github.com/PabloPL/linux/wiki [2] https://github.com/PabloPL/linux/issues/18 [3] https://github.com/TexasInstruments/dri3wsegl
So in combination with proper DT entries the correct driver variant is automatically modprobed during boot. At least for OMAP3.
OMAP4+5 driver code is also included but not yet integrated/fixed.
The DM3730 and AM33xx versions work (up to a certain point I will describe below). OMAP3530 does not properly set up clocks and SoC interconnects.
For the AM335x there is a hack to keep clock running after deasserting reset, but for the OMAP3530 we still have to find the root of the trouble.
What is still missing is the framebuffer backend so the SGX is not told how to write to a display. Traditionally, there was omaplfb but it seems no longer be working. There is also some DRM stuff, but I wasn't able to compile and set it up so far.
So, running the SGX ClipBlit test succeeds until it fails with:
FAIL - PVRSRV_ERROR_NO_DC_DEVICES_FOUND(134)
The latest code is rebased on top of v4.15-rc9 and it suffices to configure for SGX and SGX_OMAP. It can be found here (or in the latest Letux release [2]):
https://github.com/goldelico/gta04-kernel/commits/work/letux-base/hns/gpu/om...
It consists of two groups of commits (separated by a MAINTAINERS patch):
fixes for SoC glue (e.g. clock, hw-mods, pdata-qirks, DT) to get the SGX initialized and access - most of them are already good enough for upstream review
source code for pvrsrvkm from TI GFX SDK (one version for omap3+4 and one for omap4+5) combined with patches and new Makefiles to get it compiled on v4.15
There are also two shell-script tools (Letux/root/sgxdump and Letux/root/gpu-demo) for user-space. They are useful for debugging. A compatible Debian package with the (closed source!) microkernel for SGX, libs and demos for OMAP3-ARMHF can be found here:
http://download.goldelico.com/letux-debian-rootfs/debian/dists/jessie/main/b...
What is the goal of this effort?
In the end we should have a single, generic SGX driver for all OMAP SoC variants sitting in mainline drivers/gpu/pvr. So the goal is to end the era of out-of tree SGX drivers for a significant portion of OMAP processors.
Maybe it could become a driver that even IMG and TI want to support by providing newer (and open source) user-space libraries and tools.
My personal goal so far was to make it a working demonstrator that can be used as a "good" reference for running "git bisect" to identify regressions introduced by future modifications.
What has to be done to polish the code beyond "seems to work"?
I see these topics (but there may be more):
- fix power and clock management weakness
- fix issues with omap3530 (e.g. OpenPandora)
- make code finally completely independent of SoC variant so that all differences are deduced from device tree and a single kernel module serves them all
- get rid of -DSGX530 #ifdef etc.
- remove #if LINUX_VERSION_CODE (unless someone sees need to backport to stable)
- fix backend (omaplfb and/or omapdrm)
- make it work on omap4 / omap5 and sgx540 / sgx544
- fix dmac flush etc. in services4/srvkm/env/linux/osfunc.c
- simplify code where possible
- clean up the code (e.g. replace camel-case function and variable names)
- merge drivers/subdirectories for omap3+4 and omap4+5
- move from drivers/staging/pvr to drivers/gpu/pcr
- support for non-OMAP SoC with PVR/SGX inside
This is far too much work for just a handful of people so a broader community should be involved.
What will be the next steps?
Tony suggested to publish this initial work on LKML and ask for integration into the staging tree. The rationale is that the code needs a lot of polishing and cleanup until it is something good for drivers/gpu. And collaboration on LKML and kernel.org becomes easier than having a private mailing list and git(hub) repo only.
Yes, that would be be a good step and now I think the package is ready to go.
And if someone could provide a fix for the FB/DRM setup it would also be a big step because we then can even demonstrate it by screen movies.
We also need to define maintainers who take care of changes and new patches (since I can't do that alone).
BR, Nikolaus