Hi Liviu, On Mon, 16 Feb 2026 13:59:27 +0000 Liviu Dudau <[email protected]> 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 <[email protected]> wrote: > > > > > > > >> On Sun, Feb 15, 2026 at 4:04 AM Onur Özkan <[email protected]> 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
