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

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Matt,

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

> 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

> 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?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds