[PATCH v3 00/17] Imagination Technologies PowerVR DRM driver

[Frank Binns]

Hi Nikolaus,

On Fri, 2023-06-16 at 16:06 +0200, H. Nikolaus Schaller wrote:
> Hi Linus,
> thanks for sharing this conversation with me.
> 
> > Am 16.06.2023 um 14:29 schrieb Linus Walleij <linus.walleij at linaro.org>:
> > 
> > Hi Sarah,
> > 
> > thanks for starting this long awaited work!
> > 
> > On Tue, Jun 13, 2023 at 5:20 PM Sarah Walker <sarah.walker at imgtec.com> wrote:
> > 
> > > This patch series adds the initial DRM driver for Imagination Technologies PowerVR
> > > GPUs, starting with those based on our Rogue architecture. It's worth pointing
> > > out that this is a new driver, written from the ground up, rather than a
> > > refactored version of our existing downstream driver (pvrsrvkm).
> 
> Great!
> 
> > This seems to be a fairly good starting point, a bit of trade-off
> > between latest-and-greatest
> > and recent enough devices that need aftermarket support.
> > 
> > I assume you are aware of the community existing around Series 5
> > (should be the immediate
> > predecessor to Rogue?):
> > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx
> > 
> > I don't know how active those people are these days, but I can see that a branch
> 
> Well, there hasn't been much progress due to lack of documentation and compatibility
> issues of user-space code. Just keeping the code compatible to latest upstream kernels.
> 
> But at least for OMAP3 and OMAP5 processors people are actively using this work.
> 
> There is even a gaming console (www.pyra-handheld.com) in active production
> with a strong need for an up-to-date SGX544 driver running on OMAP5.
> 
> > was updated for v6.4-rc3 just three weeks ago.
> > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/pvrsrvkm-6.4-rc3
> > 
> > I think it would be good for community building to make sure that you get these
> > people involved in reviewing, especially neutral stuff like device tree bindings
> > but also to make sure no architectural choices are done that will make it hard
> > to retrofit a proper driver for the older engines if this community
> > decide to work
> > on it.
> 
> Some questions to the author of the new driver:
> - are there plans to support SGX5 (the predecessor of Rogue6)?

We don't currently have any plans to support SGX. Our main focus is currently on
Rogue and then we'll move onto Volcanic.

> - will this be able to run the existing firmware and user-space code of pvrsrvkm?

I'm afraid not. The interface for existing firmware and userspace code were
designed with different requirements in mind and don't cater to the kernel's
strict compatibility guarantees. As such, the uapi for this new driver is
very different to pvrsrvkm's, although naturally there are similarities:
https://gitlab.freedesktop.org/sarah-walker-imgtec/powervr/-/blob/dev/v3/include/uapi/drm/pvr_drm.h

We've also worked with our firmware team to make changes to the firmware
interface to better support this new driver. Specifically, parts of the firmware
interface are no longer conditional on the GPU feature set / hardware
workarounds, meaning we now have a single interface which can work across all
existing Rogue GPUs, which makes things a lot easier for this new kernel driver.

> - or will it have new firmware and user-space code for these older chips?
> - or will there be open user-space code for SGX (and Rogue)?

We're using the same Rogue firmware as our closed source driver, just with
modifications to the interface to cater for this new kernel driver. In terms of
userspace, we already have a Vulkan driver upstreamed to Mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/imagination/vulkan

and will be working to enable GLES support via Mesa's Zink GL(ES)-to-Vulkan
translation layer. This naturally limits support to Series 6 onwards, as
anything older isn't capable of supporting Vulkan.

> 
> > Specifically I would ask that the DT bindings include all old and new PowerVR
> > hardware in one go, unless they have very specific hardware definition needs,
> > which I doubt.
> 
> Our current bindings for all SoC with a SGX5 GPU inside and which have at least
> some official Linux support are here:
> 
> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/omap-pvr-soc-glue-v8/Documentation/devicetree/bindings/gpu/img%2Cpvrsgx.yaml
> 
> There was an attempt to upstream at least this plus glue code (i.e. device tree
> sources) some years ago but there was no consensus about the number and names of
> clocks that should be included in such a bindings document.

I've taken a look and your bindings look very similar to the ones we've come up
with. If you decide to attempt to upstream these again, please feel free to CC
me, Sarah and Donald (all on this email chain) so we can provide some feedback.

> 
> > Also I think they could use your help to get the proper firmware for the older
> > hardware licensed properly from Imagination and included into linux-firmware
> > so they do not need to ship files on the side.
> 
> Indeed, this and some "universal" user-space code would help a lot. Currently
> we have collected a lot of binaries for several architectures (e.g. Intel, OMAP, JZ4780),
> but all from different DDK versions and very different assumptions about system
> library versions.

The way the SGX driver was designed means that it has to be built for a specific
GPU, the version of the firmware, userspace driver(s) & kernel driver have to
exactly match and the build configuration has to match as well. Essentially, we
don't have "universal" userspace code ourselves. With our focus being on Rogue
and beyond, we don't currently have any plans to work on this.

Thanks
Frank

> 
> > Yours,
> > Linus Walleij
> 
> Best regards,
> Nikolaus Schaller
>