[Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
H. Nikolaus Schaller
hns at goldelico.com
Tue Jan 23 14:38:22 CET 2018
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)
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/omap-pvr
It consists of two groups of commits (separated by a MAINTAINERS patch):
1. 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
2. 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/binary-armhf/omap3-pvrsgx530-gta04_0.20130811195126_armhf.deb
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
[1]: https://github.com/korena/bbb-workshop
[2]: http://projects.goldelico.com/p/gta04-kernel/
More information about the Letux-kernel
mailing list