linux-kernel - Re: [RFC PATCH 2/2] drm/panthor: add initial mt8196 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAPaKu7SU5P-SkJj6aHi3ERekM4nnrv1p1joi1ZZ-pq0ZxytP8w@mail.gmail.com>
Date: Fri, 5 Sep 2025 10:02:23 -0700
From: Chia-I Wu <olvaffe@...il.com>
To: Florent Tomasin <florent.tomasin@....com>
Cc: Boris Brezillon <boris.brezillon@...labora.com>, Steven Price <steven.price@....com>, 
	Liviu Dudau <liviu.dudau@....com>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Matthias Brugger <matthias.bgg@...il.com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, dri-devel@...ts.freedesktop.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org
Subject: Re: [RFC PATCH 2/2] drm/panthor: add initial mt8196 support

On Fri, Sep 5, 2025 at 2:18 AM Florent Tomasin <florent.tomasin@....com> wrote:
>
>
>
> On 05/09/2025 00:06, Chia-I Wu wrote:
> > On Wed, Sep 3, 2025 at 11:02 PM Boris Brezillon
> > <boris.brezillon@...labora.com> wrote:
> >>
> >> On Wed,  3 Sep 2025 15:55:04 -0700
> >> Chia-I Wu <olvaffe@...il.com> wrote:
> >>
> >>> diff --git a/drivers/gpu/drm/panthor/Makefile b/drivers/gpu/drm/panthor/Makefile
> >>> index 02db21748c125..75e92c461304b 100644
> >>> --- a/drivers/gpu/drm/panthor/Makefile
> >>> +++ b/drivers/gpu/drm/panthor/Makefile
> >>> @@ -12,4 +12,6 @@ panthor-y := \
> >>>       panthor_mmu.o \
> >>>       panthor_sched.o
> >>>
> >>> +panthor-$(CONFIG_DRM_PANTHOR_SOC_MT8196) += panthor_soc_mt8196.o
> >>
> >> Based on the stuff you describe (ASN hash, core mask read from an nvmem
> >> cell, extra clks/regulators?), I don't think we need per-soc source
> >> files and per-soc config options. If it becomes too HW specific (no
> >> abstraction to make it SoC-agnostic), we can reconsider the per-SoC
> >> file approach, but I believe it can all live in panthor_drv.c for now.
> > That's about right except no extra clk/regulator is needed.
> >
> > gpueb on mt8196 is yet another mcu running on its own fw.  It can
> > provide clk/regulator to panthor and no change is needed from panthor.
> > But it can also do dvfs autonomously, in which case panthor needs to
> > be modified to make clk/regulator/devfreq optional.  I think the
> > latter is where Nicolas Frattaroli is going and requires more invasive
> > integration.
>
> Hi Chia-I Wu,
>
> I beleive the changes your are proposing need to be treated as 3
> different features:
>
> 1. Handling of ASN hash
> 2. clk/regulator registration
> 3. Core Mask control in Panthor
>
> * For 1. since it is a GPU HW property, have you considered
> handling it in the DTB as HW quirk?
>
> Pass the value of the register from the DTB, then Panthor
> driver applies a mask to filter the bits and then configre the HW regs
It is a soc-specific quirk and was suggested to be dealt with using
compatible string

  https://lore.kernel.org/lkml/ac4838eb-7613-4642-a007-577a9f665984@arm.com/

>
> > The clk/regulator provider on MT8196 is GPUEB, whose driver[1] needs to
> > be cleaned up and upstreamed separately.
>
> * For 2. Have you considered making the GPUEB MTK driver act as
> a clock/regulator supplier?
That's what the linked commit does

  https://gitlab.freedesktop.org/olv/kernel/-/commit/170d5fc90f817dc90bde54b32872c59cf5c77779

>
> Without a clocks, the driver won't be able to support
> instrumenation.
>
> And without a regulator or clock, how will system/runtime PM
> suspend/resume be handled in the driver?
>
> * For 3. I think this is a more complex topic and other vendors may
> have different needs.
>
> At first glance, `panthor_soc_data` does not seem to be sufficient
> to cope with other vendors.
>
> What would be the protocole used to communicate wth MCU?
> Can the MCU update the core mask on its own?
> Will the core mask change at runtime?
>
> If the core mask is static, what about adding a DTB entry?
AFAICT, gpueb reads the shader core mask from efuse and writes it to
an memory address (together with other info) specified by the gpueb
driver.  How the gpueb driver makes the mask available to panthor is
tbd, but it should be a very small change to panthor (unless we want
the gpueb driver to be a part of pantor).

I was told by the vendor that the shader core mask does not change
after boot, but can vary in unspecified ways.


>
> Kind regards,
> Florent