From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from forward501a.mail.yandex.net (forward501a.mail.yandex.net [178.154.239.81]) (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 4B7E4223708 for ; Mon, 16 Feb 2026 14:41:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.154.239.81 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771252894; cv=none; b=ohYtIKXkMc0fOCNMtv1qFdJGFen5xgTVdf+0a/nzZm3oyMLaVPJfCy1w/DeRYk7Z1pIodm85DVRwn/tTaesRt2q8LcfpVk2wY8YvUx1JUXSJtFg79XkU6svuRc8dHOdgCAr1ZFZ3+4CnbQ1f22zL0L097iNaY/nrFWXF9USgx/c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771252894; c=relaxed/simple; bh=gkjJIqfhmGqNPqAMLy8cYQxU0uwo82hp34p+AIZU+sQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=XyZ5ERL7yvJWepCbhEuFPkYF9Vrol/2aSQfdnI2emPzWVCfvoYNJPhsuFhrAzZ8AJDEuSe2Q9kclMCzmwYK/fMNbkQece12R9q43i1NwtlAXjTp8oJM1C9pJ80KjSdR3gILNfWeXLoC9qFtMcarX87jSWIhhkjagM+/jy2yzxJU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=onurozkan.dev; spf=pass smtp.mailfrom=onurozkan.dev; dkim=pass (1024-bit key) header.d=onurozkan.dev header.i=@onurozkan.dev header.b=NyvCOl3o; arc=none smtp.client-ip=178.154.239.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=onurozkan.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=onurozkan.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=onurozkan.dev header.i=@onurozkan.dev header.b="NyvCOl3o" Received: from mail-nwsmtp-smtp-production-main-84.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-84.vla.yp-c.yandex.net [IPv6:2a02:6b8:c1f:1311:0:640:df31:0]) by forward501a.mail.yandex.net (Yandex) with ESMTPS id 0B3A68095D; Mon, 16 Feb 2026 17:41:23 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-84.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id 9fZpnRiGtW20-b1bTBWDR; Mon, 16 Feb 2026 17:41:21 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onurozkan.dev; s=mail; t=1771252882; bh=F2UA0yW+NVCi0Rj+zD3YngWiaGKgRpmAvZ4q7nxAizA=; h=Cc:Message-ID:Subject:Date:References:To:From:In-Reply-To; b=NyvCOl3o32x+iw1Q465tLwUlGI6/pT7B+o8ykON6zPRVCpP9TWHQVo66Dl0dXUpYO XEjlGZ5m3fQsjtEv8rMvU1yImXWRtRnxzzZotGxdsv9PNj1r0BsVLrp8K4LdU+VB1L ZfkUfT5iG17ey+b/r53LyB2iWI72kZkpO+NQZFKc= Authentication-Results: mail-nwsmtp-smtp-production-main-84.vla.yp-c.yandex.net; dkim=pass header.i=@onurozkan.dev Date: Mon, 16 Feb 2026 17:41:07 +0300 From: Onur =?UTF-8?B?w5Z6a2Fu?= To: Boris Brezillon 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: <20260216174107.1b9c03a4@nimda> In-Reply-To: <20260216103743.626c71e3@fedora> References: <20260215100302.136719-1-work@onurozkan.dev> <20260215100302.136719-2-work@onurozkan.dev> <20260216103743.626c71e3@fedora> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-pc-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 Mon, 16 Feb 2026 10:37:43 +0100 Boris Brezillon wrote: > On Sun, 15 Feb 2026 13:02:51 +0300 > 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 > > 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 *ptdev) > > * 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")) { >=20 > Rather than checking for specific compats here, let's go for > a dont_need_sram_supply bool in panthor_soc_data. >=20 Makes sense. > > + ret =3D devm_regulator_get_enable_optional(dev, > > "sram"); >=20 > If we assume SRAM supply is mandatory, should this be > devm_regulator_get_enable() instead? > That was the first thing I did but when I tested it, it didn't work as expected because devm_regulator_get_enable() fell back to the dummy regulator without returning an error. Regards, Onur =20 > > + 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); >=20