Hi Merlijn, > Am 10.02.2019 um 17:14 schrieb Merlijn Wajer <merlijn@xxxxxxxxxx>: > > 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? Yes, we are rebasing the OMAP3/AM335x (TI Graphics_SDK_5_01_01_02 for omap3/omap4, seems to be IMG DDK 1.10) regularly and are trying to track upstream API changes: http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/omap-pvr But we are not using or testing (due to lack of working omaplfb framebuffer), so that I am not sure if it still works (at least to the level of successfully resetting and downloading firmware) or was harmed by recent upstream changes (e.g. clock framework, hwmods). But if it is no longer working, it should not be too difficult to find our why, since older and working versions are archived for comparison and we can find the upstream version which did break it. We also carry along a patch set of the latest (we are aware of) SGX drivers for OMAP and other platforms (IMG DDK 1.14): http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/latest-pvr but that tree is missing in-kernel Kconfig+Makefiles and SoC integration fixes. And I don't know where to find the matching firmware and library files. > 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). Indeed. The best would IMHO be if it were generally available in mainline/staging [1]. So if there is enough support by the community we could try to get these things pulled by Greg to drivers/staging/pvr for the benefit of everybody. And then we all could work on a single common basis for improvements using the standard tools like kernel git, LKML, linux-next, patchwork etc. IMHO all these efforts so far were stopped because it is so difficult to pull together all the pieces and everyone was starting over from scratch. > 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), Fine! That is much better than what we have on our omap3 devices (because we use omapdrm panel drivers). But N900 is sufficiently similar. So that comparing the diffs might end in a working solution for everyone. > but X11 works with acceleration, although > some issues remain. Cool. > 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. Yes, I also have a Panda ES so I can at least offer testing. > > Ideally we'd use drm+modesetting drivers with dri3wsegl [3], but I have > yet to try to make that work. :) > > Cheers, > Merlijn What would be the process to get something into staging? Who decides about staging generally? Should we just forward this discussion to Greg for comment? BR and thanks for bringing up this topic again! Nikolaus [1]: https://lwn.net/Articles/324279/ > > [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/ >> >> >
