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

Tony Lindgren tony at atomide.com
Sat Oct 23 13:31:57 CEST 2021


* 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.

> 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