[Openpvrsgx-devgroup] [PATCH] Update pvrsgx 1.14.3759903 to latest kernel

Ivaylo Dimitrov ivo.g.dimitrov.75 at gmail.com
Tue Nov 16 20:03:33 CET 2021



On 16.11.21 г. 19:53 ч., H. Nikolaus Schaller wrote:
> Hi Lucas,
> 
>> Am 16.11.2021 um 01:26 schrieb Lucas Fryzek <lucas.fryzek at hazeco.xyz>:
>>
>>
>>
>>> That is excellent news!
>>> Yes, making kernel and userland build options match is not very difficult. But we have to take care that the changes are only for jz4780.
>>> BTW:  I'll plan to update the letux kernel tree to 5.16-rc1 this week and also rebase and push all the pvrsgx branches to our git tree.
>>> Then I can take a look at the build options to match user-space.
>>> BR,
>>> Nikolaus
>>
>> Hello Nikolaus, I was able to get the kernel mode driver and userland build options to match fairly easily, I just had to add the following build flags to the makefile:
>>
>> ```
>> ccflags-y += -DSGX_FAST_DPM_INIT
>> ccflags-y += -DSGX_FEATURE_SYSTEM_CACHE
>> ccflags-y += -DSUPPORT_ACTIVE_POWER_MANAGEMENT
> 
> Nice!
> 
>> ```
>>
>> I suspect we would like this wrapped around in an if statement if building for the jz4780, correct?
> 
> Yes, although not 100% necessary as we have this DDK version only running on jz4780. But it doesn't harm.
> 
> Well, I have already added that to my tree which I have rebased to v5.16-rc1 and I had to touch it anyways to get it compiled again.
> For example https://lkml.org/lkml/2021/10/27/1073 needs some MODULE_IMPORT_NS(DMA_BUF); and the Makefile also needs an additional -Iinclude/linux now.
> So it were fixes for almost the same files files.
> 
> What I also had to fight with had been some small upstream issues elsewhere, e.g. the -Wimplicit-fallthrough=5 error with GCC 6.3.
> 
> But now I am able to build a kernel driver that confirms your findings below (still dma/cache code just commented out).
> I need to do some clean-up and more tests before I can publish that to the letux git.
> And maybe let it mature a little for the openpvrsrx git.
> 
> Then we can integrate everything you have fixed in addition.
> 
>>
>> Second I tested the pvrsrvctl application using the command `pvrsrvctl --start --no-module` and it seems to start with no error but the other pvr test applications fail with `PVRSRV_ERROR_NO_DC_DEVICES_FOUND`, I attached a full log of the `pvr_blit_test` application that shows the error. I'm not the familiar with the PVR userland, but do you suspect this is a userland issue where the display hasn't been properly attached to the pvr GPU, or is this a KMOD issue where the drm integration for the driver needs to be updated to work properly? If it is a KMOD issue, do you know if the people working on omap hardware had the same problem, and there is existing code that I can use as a reference?
> 
> I think I remember what this is. DC_Devices are "Display Class" devices which is some mechanism to make the SGX aware of a framebuffer.
> The same happened with omap3 several times. Google reports some hits for PVRSRV_ERROR_NO_DC_DEVICES_FOUND.
> 
> AFAIR the issue is that sgx_blit_test doesn't work at all with DRM based drivers and the solution is to try xgles1test1 or xeglinfo. This may require to have X11 running but I am not sure about.
> 
> Well, I can't start X11... Maybe it is because now we now have HDMI and SGX /drv/dri cards. I believe to remember there is no automatic assignment but assumptions.
> 
> It turns out that I have to wait until X11 has started before modprobing our pvrsrvkm.
> 
> Then I tried:
> 
> root at letux:~# xeglinfo
> WSEGL_InitialiseDisplay: DRI2OpenConnection failed
> Unable to initialise egl
>      egl error 'EGL_NOT_INITIALIZED' (0x3001)
> root at letux:~#
> 
> xgles1test1 reports the same.
> 
> This is maybe where Ivo can support.
> 

You may try MESA from leste tree 
(https://github.com/maemo-leste-upstream-forks/mesa/tree/maemo/beowulf-experimental), 
it has x11 support, unfortunately pvr_dri.so there matches DDK 
1.17.4948957. Most probably it will not work, but trying will cost you 
nothing but a time wasted to compile. In case you want to try, you will 
need 'export MESA_LOADER_DRIVER_OVERRIDE=pvr'

On the other hand, you may try to run kmscube or glmark2-es2-drm, both 
use GBM to allocate EGL surfaces, so no x11 support is needed. Keep in 
mind you have to provide the correct card to kmscube (-d parameter).


> BR and thanks,
> Nikolaus
> 
> 
>>
>> ```
>> root at letux:/usr/local/bin# sgx_blit_test
>> ------------------ SGX 3D Blit test -----------------
>> ----------------------- Start -----------------------
>> Call PVRSRVConnect with a valid argument:
>> OK
>> Get number of devices from PVRSRVEnumerateDevices:
>> OK
>> .... Reported 1 devices
>> .... Device Number  | Device Type
>>            0000    | PVRSRV_DEVICE_ID_SGX
>> Attempt to acquire device 0:
>> OK
>> Getting SGX Client info
>> OK
>> .... ui32ProcessID:1337
>> Display Class API: enumerate devices
>> OK
>> PVRSRVEnumerateDeviceClass() returns 0 display device(s)
>> FAIL - PVRSRV_ERROR_NO_DC_DEVICES_FOUND(134)
>> Aborted
>> root at letux:/usr/local/bin#
>> ```
>>
>>
> 


More information about the openpvrsgx-devgroup mailing list