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

[Boris Brezillon <boris.brezillon@collabora.com>]

Hi Liviu,

On Mon, 16 Feb 2026 13:59:27 +0000
Liviu Dudau <liviu.dudau@arm.com> wrote:

> On Mon, Feb 16, 2026 at 01:43:19PM +0100, Nicolas Frattaroli wrote:
> > On Monday, 16 February 2026 12:44:39 Central European Standard Time AngeloGioacchino Del Regno wrote:  
> > > Il 16/02/26 10:44, Boris Brezillon ha scritto:  
> > > > Hello Adam,
> > > > 
> > > > On Sun, 15 Feb 2026 16:21:34 -0600
> > > > Adam Ford <aford173@gmail.com> wrote:
> > > >   
> > > >> On Sun, Feb 15, 2026 at 4:04 AM Onur Özkan <work@onurozkan.dev> wrote:  
> > > >>>
> > > >>> 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