[Openpvrsgx-devgroup] [PATCH 1/2] drm: pvrsgx: pvr-drv: Fix OCP handling with ioremap and reg access

Ivaylo Dimitrov ivo.g.dimitrov.75 at gmail.com
Sun Oct 24 20:37:50 CEST 2021

On 23.10.21 г. 14:31 ч., Tony Lindgren wrote:
> * H. Nikolaus Schaller <hns at goldelico.com> [211023 11:10]:
>> looks good to me. Unfortunately I can't test the 1.17 setup any more.
>> It looks as if the 1.17 user space code needs a libc version which
>> only became available in Debian Bullseye but some other requirement
>> needs something older that is no longer available in 11.1. So my SD
>> card for the Pyra got broken after an apt-get upgrade. And I would have
>> to look for backports or compiling older versions from source.
> I'm happily using this stuff on Alpine on musl with wlroots and sway.
> So your should be doable with your libc version too. See the recent
> changes this year at [0][1][2][4] below :)
> You can compile your own pvrsrvinit to init the hardware with dlopen
> of libsrv_init.so. Then you can compile your own Mesa with the Chromium
> patches to use with Wayland and wlroots. Ivaylo might have some patches
> for Xorg support coming up soonish.

Yeah, with chromeos pvr mesa, ddk 1.17, latest upstream xorg ang glamor 
replacement(yet-to-be-pushed xf86-video-modesetting-module-gbm) I am 
able to achieve glmark2-es2 score of 25 on n900 (for reference, 
glmark2-es2-drm score is 37). Still place for improvement, but hopefully 
we'll finally have something in an useful shape soon.

>> jz4780 was never tested. As you assume, it is just code available from
>> the TI DDK tree - in the hope that we can make it run some day on the
>> jz4780. This was also blocked by not having a working HDMI output on
>> the CI20 creator board. But now we have something which is close to
>> find acceptance upstream (but slowly).
> OK
>> What we are lacking anyways is proper user-space code for MIPS. There
>> is something for some 1.14 DDK (different patch level from omap3) but
>> not for 1.17.
>> Long ago I had started to set up qemu-system-arm on the jz4780
>> so that we can at least run pvrsrvctl --start from the TI UM code
>> and see if the driver finds, downloads firmware and initializes
>> something but that idea was never completed.
> Heh OK :)
>> I have splitted this into two commits since I run separate branches
>> for the generic part and the DDK specific variants. That makes it
>> easier to add new DDK source tree variants when we find them
> OK thanks.
>> (I think our code-archaeology didn't find anything new in the past
>> two years but we didn't do many excavations :)
> Heh :) Seems we got things into usable shape for some hardware though.
> My current wishlist for Imagination would be something like:
> 1. Load SGX specific firmware using standard Linux firmware functions
>     to get rid of pvrsrvinit user space binary
> 2. Do the rest of the SGX specific init in the kernel module based
>     on the device type
> 3. Open source the remaining code between Mesa and the kernel driver
> That would allow the community to maintain the SGX driver for all
> architectures.
> Regards,
> Tony
> [0] pvrsrvinit.c source
>      https://github.com/IMbackK/pvr-omap4/blob/master/pvrsrvinit.c
> [1] PostmarketOS with Imagination GPUs
>      https://gitlab.com/postmarketOS/pmaports/-/issues/932
> [2] Jonathan Bakker's git tree for ChromeOS Mesa patches
>      https://github.com/xc-racer99/mesa-pvr/tree/mesa-20.3.2-pvr-musl-2
> [3] Chrome OS Mesa patches for Imagination GPUs
>      https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/media-libs/arc-mesa-img/
> [4] WIP wlroots workarounds for SGX
>      https://github.com/tmlind/wlroots/commits/pvr-gles2-v2

More information about the openpvrsgx-devgroup mailing list