> Am 11.02.2019 um 07:51 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>: > > 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? One thing already got my attention: we need to prefix all commit messages with e.g. "staging: pvr: " so that they can be distinguished on LKML. I'll prepare that for the next version of our Letux tree. > > 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/ >>> >>> >> > > _______________________________________________ > Kernel mailing list > Kernel@xxxxxxxxxxxxxxxxx > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
