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 62E5C17ADE0 for ; Mon, 16 Feb 2026 09:37:51 +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=1771234672; cv=none; b=AuBlaBeq94i7CFVi95BUG0JIsr8Ra3sVtLh2jQOOoqpuavqX0PrRfs9K5TMIwoxuZlJSCyaEDuxW6yB8pvXwa4DBK9/Hwl3KN03pBeaWx807RdYLyxNswPBgtaQxbeDcGDkqCSeCDK9GhBwfOUKPJipUXj4RU+4HylP3ECaU/HA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771234672; c=relaxed/simple; bh=qKKaBe4wf2RPk6OJWEKoKbKnw8/kv7zGYyXRckENEUk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=objTrsIWQC3QH6Mx1gehnSw0d7E3rU9jyRDsDWHXLbvckKzNjnCvWq3Kda76vT7Qf2PY7hALAeZBoGB5y8iHpd6fgT8nppg9aztIVgFCUeu37Z7qOLn4rHuQO8nSwC8VQPEQXY1FmUx1evnnPRI3XhL6SN72/XXajUBXDz1M9aU= 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=I2oKvwoH; 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="I2oKvwoH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1771234669; bh=qKKaBe4wf2RPk6OJWEKoKbKnw8/kv7zGYyXRckENEUk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=I2oKvwoHlI8oSPvQHSJXXW0H+75phIPDMf1wu11+r2nCrG7sPX4d6GeUd373hlnkZ VQY/qoPjgZh3gTS6czi3gfPJ/3Zt/HueoprNTYXysbI8e9vbhlVBajuhoA4PiXo/Fm bem+wpW58TJlZcscN47Hqf/MwSyAZyLoDnSXQG7YcooUur9JbfxiLpVEVTVk1k93r0 6yWlwvjrpobD13y/YZfDS56vsMY2e66Xg+nUIWN/qEeDI+6RKexXCjmaDVy4vENgE8 CUtuE8mfzaSWAU0VUIdkhC2pE7vM2XVE9QUbj+VyXINf1n+nghNXEoqwu13ea9+h66 FwfZ3OG9qPKdQ== 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 E067817E137B; Mon, 16 Feb 2026 10:37:48 +0100 (CET) Date: Mon, 16 Feb 2026 10:37:43 +0100 From: Boris Brezillon To: Onur =?UTF-8?B?w5Z6a2Fu?= Cc: Steven Price , Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Matthias Brugger , AngeloGioacchino Del Regno , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH v1 2/2] drm/panthor: treat sram as mandatory except mt8196 Message-ID: <20260216103743.626c71e3@fedora> In-Reply-To: <20260215100302.136719-2-work@onurozkan.dev> References: <20260215100302.136719-1-work@onurozkan.dev> <20260215100302.136719-2-work@onurozkan.dev> 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 On Sun, 15 Feb 2026 13:02:51 +0300 Onur =C3=96zkan 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. >=20 > Make SRAM handling explicit: require sram-supply for all > Panthor compatibles except mt8196-mali where GPU supplies > are intentionally managed outside Panthor and DT does not > model sram-supply for that compatible. >=20 > This keeps DT power modeling explicit and avoids relying on > dummy-regulator fallback. >=20 > Link: https://lore.kernel.org/all/20260213155937.6af75786@nimda/ > Signed-off-by: Onur =C3=96zkan > --- > drivers/gpu/drm/panthor/panthor_devfreq.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) >=20 > diff --git a/drivers/gpu/drm/panthor/panthor_devfreq.c b/drivers/gpu/drm/= panthor/panthor_devfreq.c > index 2249b41ca4af..5f6075f18fe3 100644 > --- a/drivers/gpu/drm/panthor/panthor_devfreq.c > +++ b/drivers/gpu/drm/panthor/panthor_devfreq.c > @@ -206,12 +206,17 @@ int panthor_devfreq_init(struct panthor_device *ptd= ev) > * But without knowing if it's beneficial or not (in term of power > * consumption), or how much it slows down the suspend/resume steps, > * let's just keep regulators enabled for the device lifetime. > + * > + * Treat sram-supply as mandatory except for mt8196-mali. It manages > + * SRAM outside Panthor so this driver must not require direct control > + * over it. > */ > - ret =3D devm_regulator_get_enable_optional(dev, "sram"); > - if (ret && ret !=3D -ENODEV) { > - if (ret !=3D -EPROBE_DEFER) > + if (!of_device_is_compatible(dev->of_node, "mediatek,mt8196-mali")) { Rather than checking for specific compats here, let's go for a dont_need_sram_supply bool in panthor_soc_data. > + ret =3D devm_regulator_get_enable_optional(dev, "sram"); If we assume SRAM supply is mandatory, should this be devm_regulator_get_enable() instead? > + if (ret) { > DRM_DEV_ERROR(dev, "Couldn't retrieve/enable sram supply\n"); > - return ret; > + return ret; > + } > } > =20 > opp =3D devfreq_recommended_opp(dev, &cur_freq, 0);