Re: [PATCH v1 2/2] drm/panthor: treat sram as mandatory except mt8196

Hi Liviu,

On Mon, 16 Feb 2026 13:59:27 +0000
Liviu Dudau [off-list ref] wrote:

On Mon, Feb 16, 2026 at 01:43:19PM +0100, Nicolas Frattaroli wrote:

quoted

On Monday, 16 February 2026 12:44:39 Central European Standard Time AngeloGioacchino Del Regno wrote:  

quoted

Il 16/02/26 10:44, Boris Brezillon ha scritto:  

quoted

Hello Adam,

On Sun, 15 Feb 2026 16:21:34 -0600
Adam Ford [off-list ref] wrote:
  

quoted

On Sun, Feb 15, 2026 at 4:04 AM Onur Özkan [off-list ref] wrote:  

quoted

If sram-supply is missing, Panthor falls back to a
dummy regulator with a warning. This implicit behavior
hides missing DT wiring behind regulator core fallback.  

This is intentional design of the regulator API. A missing supply will
always result in a dummy regulator. The _optional function bubbles the
missing supply condition up to the caller.

Catching device trees lacking supplies that are marked as required by
the binding is done with dtbs_check, not at runtime.  

I'm replying to this thread while I'm also trying to cover some discussion in the
DT patch series.

What we're trying to solve is this: the Mali GPUs have an L2$+bits power domain
that in upstream ended up being called 'sram' for reasons. The domain is important
both for ultimate power savings (you can turn off most of the other GPU domains
and preserve enough state for the GPU to wake up on an interrupt) and for normal
operations, for obvious reasons. Now, vendors either don't bother to put a
separate domain just for "sram" or go to the extreme of handing over control over
that domain to an MCU that implements aggresive and system-wide policies. We're
trying to cater for all cases, include the (currently hypotetical) one where you
have a separate "sram" power domain that Linux can control.

When we have first upstreamed the bindings, inspired by Panfrost driver, we have
added the sram-supply as mandatory which I think is turning out to be a mistake.
Prompted by Mark Brown's reply[1] to Tyr adding 'sram-supply' as an optional
property, Onur has started this and the DT patch series[2] to enforce the presence
of an 'sram-supply' to reduce the number of warnings in dtbs_check. In reality
what we are enforcing is a dummy supply that is the same as the one the GPU is using
because most of the systems don't have a specific one.

So the problem we have is: do we change the upstream binding and make 'sram-supply'
optional for every compatible string given that it is unlikely to be provided (and
the code did not enforce it in panthor_devfreq.c anyway from the beginning), or
do we accept that this power domain is important but usually not specified and we
go with the current DT patch series that provides one?

My main worry with this approach is that SoC/board bring-up tends to be
an iterative process in practice, and it usually starts with a
bunch of resources forcibly enabled (either in the bootloader
or directly in Linux) because that's easy. Problem is, that's also very
easy to forget defining non-optional resources when the dts[i] is
upstreamed, because everything seems to work just fine. And because of
this DT backward-compat constraint, if get it wrong, and the supply is
needed for real, when we get to implement the real thing we're just
screwed. Having a runtime error preventing the device to probe forces
people to at least think twice before doing something stupid, like
making the SRAM (or L2-cache) supply point to the core supply when they
are two distinct regulator outputs.

Regards,

Boris