[Openpvrsgx-devgroup] [PATCH 1/2] drm: pvrsgx: pvr-drv: Fix OCP handling with ioremap and reg access
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  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).
>> 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
>  pvrsrvinit.c source
>  PostmarketOS with Imagination GPUs
>  Jonathan Bakker's git tree for ChromeOS Mesa patches
>  Chrome OS Mesa patches for Imagination GPUs
>  WIP wlroots workarounds for SGX
More information about the openpvrsgx-devgroup