Re: [PATCH] Revert "drm/imagination: Warn or error on unsupported hardware"

[Matt Coster <Matt.Coster@imgtec.com>]

[-- Attachment #1.1: Type: text/plain, Size: 5306 bytes --]

Hi Geert,

On 11/05/2026 15:43, Geert Uytterhoeven wrote:
> On Mon, 11 May 2026 at 16:06, Matt Coster <Matt.Coster@imgtec.com> wrote:
>> On 11/05/2026 14:28, Geert Uytterhoeven wrote:
>>> Revert commit 1c21f240fbc1e47b94e68abfa2da2c01ed29a74d, as it stopped
>>> the driver from working on various Renesas R-Car SoCs.
>>>
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>> ---
>>> DT binding documentation updates were reviewed by the drm/imagination
>>> maintainers[1][2][3], DTS additions were reviewed and/or acked by the
>>> drm/imagination maintainers[4][5][6], and firmware is available[7].
>>> Note that the GPU nodes were not enabled in board DTS files before, as
>>> not having suitable firmware installed under /lib/firmware could trigger
>>> a crash, not directly related to drm/imagination driver support.  This
>>> was fixed only recently in v7.1-rc3[8], so board enablement[9] is now
>>> unblocked.
>>
>> We will freely acknowledge that the sequencing was not ideal here. This
>> patch should probably have been sent before we started accepting DTS
>> changes for those Renesas platforms. However, the purpose of this patch
>> still stands.
>>
>> We're not saying we never want to list all these platforms as
>> "supported", but we don't want to mislead anyone into thinking the GPU
>> on these platforms will function in any meaningful way just because they
>> now have DTS nodes. We were originally convinved to allow these DTS
>> nodes to be added since it would facilitate active development on these
>> platforms, but this does not mean that we as a team have the bandwidth
>> to do that work ourselves at this time.
>>
>> Our main concern is around the UAPI: we don't know for sure that support
>> for these platforms (which are significantly older than anything we
>> currently support) can be correctly implemented without UAPI changes. To
>> that end, we don't want to back ourselves into a corner where the UAPI
>> cannot be updated at a later date.
> 
> Automotive life cycles are long...

Which is why those cores (that are substantially older than anything
we've been targetting so far) are still relevant. But due to that age,
they're going to have quirks (and often just different hardware blocks)
that we haven't considered yet.

> 
>> There's a similar mechanism in place in userspace: the user must set an
>> environment variable (PVR_I_WANT_A_BROKEN_VULKAN_DRIVER) to use
>> platforms for which we don't promise API conformance, but just like in
>> the kernel, this is not a compile time option and any user and/or
>> developer can enable it if they know what they're doing.
>>
>> As for "it stopped the driver from working", no it didn't. The driver
>> never really worked on those platforms, at least not in any useful way,
>> and certainly not sufficiently for any non-developer user to benefit in
>> any way from it. The only change is that the user must now acknowledge
>> that this is the case to clarify that they shouldn't expect much (if
>> anything) to work. Just to be explicit, "firmware boots" is a loooooong
>> way from "ooh pretty triangles".
> 
> AFAIK, it's working better than just "pretty triangles", e.g. glxgears.
> And people are working on support for more SoCs (both newer and older),
> for which patches (both Linux kernel and MESA) have been posted...
> 
> https://gitlab.freedesktop.org/imagination/linux-firmware/-/work_items/13

This is great! But the patches that have been posted are almost
exclusively just surface level enablement (adding feature tables,
providing firmware blobs, allow-listing compatible strings, etc.), much
like the DTS changes made on the kernel side.

> 
>> Would you prefer a different approach to providing this information to
>> users, perhaps a purely docs-based solution? I'm not convinced that
>> would be as effective at preserving our ability to mutate the UAPI for
>> these as-yet-unsupported platforms.
> 
> One can wonder if it's the kernel's job to block the use of this
> hardware by default?

Our logic was this:

 1. The kernel requires absolute stability in the UAPI
 2. These cores have yet to be tested sufficiently to be confident that
    the current UAPI can accomodate them
 3. Don't allow these cores to be used by default so the UAPI remains
    somewhat malleable on platforms without this confidence.

When we were first looking to send the powervr driver upstream, we were
given a watershed of ~70% Vulkan 1.0 conformance passing to ensure the
UAPI was _probably_ solid enough to be frozen as-is. These cores are
currently nowhere near that mark.

If we can remove these restrictions now and come back later to update
the UAPI _in a way that "breaks" these cores_ (but not really because
they don't work fully yet), then I could go for that; my understanding
is that this is not an option.

We absolutely agree that it's in everyone's interest to have
experimental support in the upstream driver rather than rotting in
downstream forks, but we need to ensure that this is done in a way that
does not lock down the UAPI in a shape that may not actually be useful
for the cores with only experimental support.

Cheers,
Matt

-- 
Matt Coster
E: matt.coster@imgtec.com

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]