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

H. Nikolaus Schaller hns at goldelico.com
Mon Nov 22 17:48:17 CET 2021


Hi Lucas,

> Am 22.11.2021 um 02:09 schrieb Lucas Fryzek <lucas.fryzek at hazeco.xyz>:
> 
> 
> 
>> 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:
>> is there progress on getting anything in user-space running?
>> In the meantime I have fixed some minor issues in my 5.16-rc1 driver code. I have pushed it to
>> https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-demo-pvrsgx-jz4780-1.14.3759903
>> So if you have additional fixes (e.g. the dma issue) on top that should go to 5.16-rc2, please let me know for integration.
>> BR and thanks,
>> Nikolaus
> 
> Hello Nikolaus,
> 
> I haven't had a lot of time in the last couple of days to test the userspace libraries.

No problem. Rome wasn't built in a day and we are working on this project for years :)

> I did manage to try kmscube but I don't believe the userland on the older version has support for GBM and that was preventing it from working. I also tried running some of X11 example application that are provided in the userland and had little luck there. I was going to try building that Mesa fork  from Ivaylo's suggestion but haven't had a chance to test that yet.
> 
> I suspect the problem with the userland libraries has to do with device class issue, so if Ivaylo's suggestion doesn't work I am going to invest my effort in trying to get the device class code working.

It may be a cul-de-sac but there is DC related code in e.g. https://git.goldelico.com/?p=letux-kernel.git;a=tree;f=drivers/gpu/drm/pvrsgx/1.14.3699939/eurasia_km/services4/3rdparty;h=f344582180f28cff9463f9930e0d7b26103ff3c7;hb=refs/heads/letux-5.16-rc2

Similar dc_*.c files are in other DDK versions - except 1.15 and later where it was removed. And there are other variants for poulsbo or sunxi.

I think the dc_omap3fb_linux did work a while ago and may be a hint. AFAIR it assumed to use the old non-drm omapfb driver which has gone or is no longer used.
But it has interesting functions like OpenDCDevice(), OMAPLFBInitFBDev(), EnumDCFormats(), ProcessFlip() which all seem to be related to synchronize the framebuffer with SGX drawing.

My conjecture is that it could be possible to write a more generic wrapper between sgx-dc and modern drm based framebuffers...
Maybe even generic for all DDK releases and any hardware.

At least going through the code (and adding some printk) may give hints what is happening and why SGX doesn't find any DC displays.

BR,
Nikolaus



More information about the openpvrsgx-devgroup mailing list