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

[Tony Lindgren]

Hi,

Adding Philip to Cc too as the sunxi folks too are interested in getting
sgx usable with mainline kernels.

* Merlijn Wajer <merlijn at 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/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/
> > 
> > 
>