Re: [RFC PATCH 0/2] drm/panthor: initial mt8196 support

[Nicolas Frattaroli <nicolas.frattaroli@collabora.com>]

Hi,

On Thursday, 4 September 2025 00:55:02 Central European Summer Time Chia-I Wu wrote:
> MediaTek MT8196 has Mali-G925-Immortalis, for which panthor gained
> support recently. But the soc also requires custom ASN hash to be
> enabled. This series introduces panthor_soc_data for per-soc data and
> uses it to enable custom ASN hash on MT8196.
> 
> The clk/regulator provider on MT8196 is GPUEB, whose driver[1] needs to
> be cleaned up and upstreamed separately.

I'm currently working on this, I'm at a functional 800 LoC driver vs the
more than 30k LoC of the downstream... thing. I intend to send it in as
an RFC once the clock stuff lands, and I get some responses wrt to
figuring out what's still missing from linux-next aside from the DT to
get basic boot working so that I don't send in something that I
accidentally shredded during a rebase without noticing.

Cleaning up the downstream driver is a fool's errand, it's like 6?
separate drivers, with lots of global state (and no locking), without
using the common clock framework, and relying on abusing -supply DT
properties to force a certain probe order to make all the race
conditions it would otherwise have turn out fine. A lot of it is
code that seems dead, or wrappers wrapping wrappers that have nothing
to do with how the hardware actually works.

My solution adds a small mailbox driver for the GPUEB, and also adds
a new module that lives in the panthor tree and registers itself with
panthor's devfreq stuff to be a "devfreq provider". The motivation
for making it devfreq instead of a clock+regulator provider is that
the GPUEB seems to have several quite devfreq-like parts to it that
I am not yet using, namely setting a job completion target time and
several methods of limiting performance.

As it stands it can set the OPP, but boosting above 1.43 GHz does
not seem to stick. The boosting stuff may be done by the four or
five other ways it has to set some frequency target.

I'm hoping I can send this in maybe next week or the week after. If
things remain blocked by then it'll be compile-tested in its current
form only and lack some clock stuff.

Kind regards,
Nicolas Frattaroli

> 
> This initial support also lacks support for some hw configs. On some
> configs, panthor is expected to query a mask from efuse to mask out
> unavailable shader cores from ptdev->gpu_info.shader_present. This
> requires extending panthor_soc_data with a callback to read the mask.
> 
> This is an RFC because the dependent drivers are not ready yet. But I
> would like to gather opinions on having panthor_soc_data for
> soc-specific data and having CONFIG_DRM_PANTHOR_SOC_MT8196 for
> soc-specific code.
> 
> [1] https://gitlab.freedesktop.org/olv/kernel/-/commit/170d5fc90f817dc90bde54b32872c59cf5c77779
> 
> Chia-I Wu (2):
>   dt-bindings: gpu: mali-valhall-csf: add MediaTek MT8196 compatible
>   drm/panthor: add initial mt8196 support
> 
>  .../bindings/gpu/arm,mali-valhall-csf.yaml    |  1 +
>  drivers/gpu/drm/panthor/Kconfig               |  6 +++++
>  drivers/gpu/drm/panthor/Makefile              |  2 ++
>  drivers/gpu/drm/panthor/panthor_device.c      |  2 ++
>  drivers/gpu/drm/panthor/panthor_device.h      |  4 +++
>  drivers/gpu/drm/panthor/panthor_drv.c         |  4 +++
>  drivers/gpu/drm/panthor/panthor_gpu.c         | 26 ++++++++++++++++++-
>  drivers/gpu/drm/panthor/panthor_regs.h        |  4 +++
>  drivers/gpu/drm/panthor/panthor_soc.h         | 26 +++++++++++++++++++
>  drivers/gpu/drm/panthor/panthor_soc_mt8196.c  |  9 +++++++
>  10 files changed, 83 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/panthor/panthor_soc.h
>  create mode 100644 drivers/gpu/drm/panthor/panthor_soc_mt8196.c
> 
>