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

Merlijn Wajer merlijn at
Sun Feb 10 17:14:11 CET 2019


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
> 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. :)



> 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:
> 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]):
> 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: 
> 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 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]:
> [2]:

More information about the Kernel mailing list