From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 24C11310625 for ; Mon, 16 Feb 2026 14:20:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771251638; cv=none; b=bTXO+nVcgx6UMd17H/D7VJSe2K2gipJH7GR4Hz4QiBao7Bne0GB63emIyBCA97JLCkAOOw6VmjQ1Gh5tJVGcTisptxZtsv8IO9LoOLm6QPunYYo2LwpZCZjeYKJ6sVWX50/SzRTSAua+o5FtRjrwurBrez0uK7cMqT1iECP7XGE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771251638; c=relaxed/simple; bh=LpONIyurVKlNTOn/3d2FZntrtRRFlJmchmd0RLMCFp4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=EsOWCjfmcPHXxVYPlhXXo4gzkYNQJzzsBEGCbf4RsJZlcb76OvY6ccuEXHGO3hsVK48JAQjqu++xfum9i9B7jMlD+JNrIKm6tGdnj3gK7boHZoVQCLBe2t6JmwOyVCbFgbjYcx7oOct7elx6kULtVZ7Lbet57JJGXVQznEpDvKE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=lv7OKuFv; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="lv7OKuFv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1771251635; bh=LpONIyurVKlNTOn/3d2FZntrtRRFlJmchmd0RLMCFp4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lv7OKuFvFLoZjW/iPvVCHfLw3yaZpQvkh3sCrud39qbidVRk2kcy4bj8BV9HimpzH WdoT65tJex7/y9zX1hnnbFB4PSh+wY7U2a2FhWurd81XyuRCidjy/cd6PtuCtRDOOc 9r2lwRDOBLwVoZHRTDcR2h+aGJ8UREz9vDQUIcy5/zJ6mud4XH9Ddbh4kMCC2R5/aY MfzL7UuvaCA+TpZACzGQ6t8xBAi6Uz8ze2ejrhIkjlYCCrYectziG458moo1lBNsXZ D3nuoqoOCfZfxAyulNvByrAtqFoeRgds6/BGcv3P1Bom4ePkeAjvqY92+C2sj4Gfd8 qIuFqm7x6OCkw== Received: from fedora (unknown [IPv6:2a01:e0a:2c:6930:d919:a6e:5ea1:8a9f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id C40E917E0454; Mon, 16 Feb 2026 15:20:34 +0100 (CET) Date: Mon, 16 Feb 2026 15:20:30 +0100 From: Boris Brezillon To: Liviu Dudau Cc: Nicolas Frattaroli , Adam Ford , AngeloGioacchino Del Regno , Onur =?UTF-8?B?w5Z6a2Fu?= , Steven Price , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Matthias Brugger , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Krzysztof Kozlowski , Mark Brown Subject: Re: [PATCH v1 2/2] drm/panthor: treat sram as mandatory except mt8196 Message-ID: <20260216152030.5f91104e@fedora> In-Reply-To: References: <20260215100302.136719-1-work@onurozkan.dev> <20260216104423.6b5bcc96@fedora> <523c7b99-33a7-410d-8efb-b7bb2f2f416d@collabora.com> <4730819.LvFx2qVVIh@workhorse> Organization: Collabora X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Liviu, On Mon, 16 Feb 2026 13:59:27 +0000 Liviu Dudau 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 Ang= eloGioacchino Del Regno wrote: =20 > > > Il 16/02/26 10:44, Boris Brezillon ha scritto: =20 > > > > Hello Adam, > > > >=20 > > > > On Sun, 15 Feb 2026 16:21:34 -0600 > > > > Adam Ford wrote: > > > > =20 > > > >> On Sun, Feb 15, 2026 at 4:04=E2=80=AFAM Onur =C3=96zkan wrote: =20 > > > >>> > > > >>> 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. =20 > >=20 > > 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. > >=20 > > Catching device trees lacking supplies that are marked as required by > > the binding is done with dtbs_check, not at runtime. =20 >=20 > I'm replying to this thread while I'm also trying to cover some discussio= n in the > DT patch series. >=20 > 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 d= omains > 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 cont= rol 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 wh= ere you > have a separate "sram" power domain that Linux can control. >=20 > 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 m= istake. > Prompted by Mark Brown's reply[1] to Tyr adding 'sram-supply' as an optio= nal > 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 re= ality > what we are enforcing is a dummy supply that is the same as the one the G= PU is using > because most of the systems don't have a specific one. >=20 > So the problem we have is: do we change the upstream binding and make 'sr= am-supply' > optional for every compatible string given that it is unlikely to be prov= ided (and > the code did not enforce it in panthor_devfreq.c anyway from the beginnin= g), or > do we accept that this power domain is important but usually not specifie= d 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