From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8674D2737F9 for ; Thu, 11 Jun 2026 15:34:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781192069; cv=none; b=AWmoQI4BmPp/6kz8l0z1yRB1CYd5Xl85V7K5MQvKf51e/MB1QlnDuEhRHmvBsJBooDpC4y+mtbxVVt5U8GSF90IQeJ9dV3Nx+LjuUh+pnOEdeloJJBRrzVaUBjfQRP7Gt8y9DVeeO63eO84J5tid4Rq8WJ+P6aXIQYZNIQw8v+U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781192069; c=relaxed/simple; bh=/sCwt4VmnlRUdYpbYUPm3IxE68ROI+yaC/qYgEqdhvY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=XDohw08RIfGbZCjeYVRzoTq+c6w8j8maXd2V5UCrFL1a6kTsUp3gA/89EE/scXG75fB6nHdeLEal26Zvl50orRPNn3VhmFtdFJVtcQYGHILhf/sJF+fwIgQ4a8Fu5xfn4Wkg8xyEm5dLos0nBUda1JLADGjHrtq+/G5krOhKudQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=dMInVyTV; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="dMInVyTV" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2EEBF25E2; Thu, 11 Jun 2026 08:34:22 -0700 (PDT) Received: from [10.1.29.27] (e122027.cambridge.arm.com [10.1.29.27]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D34C43FB90; Thu, 11 Jun 2026 08:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1781192066; bh=/sCwt4VmnlRUdYpbYUPm3IxE68ROI+yaC/qYgEqdhvY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=dMInVyTVVvVKK5+JgcfXSesZeVnF8c53JrVjC34Rv2nIwPYlCpDsE8TpduOEdv822 jBpEwAe8XS0lvSFLbdcyLZIZbjR4G75zBM6e7lHEOvDEMA5l046U0k+HfXa/U50kdf Xxvqrub3wetr7nKmvQRMgFhYZdKZdhmng3pO5j/E= Message-ID: Date: Thu, 11 Jun 2026 16:34:22 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 08/18] drm/panthor: Skip devfreq when no OPP table is present To: Karunika Choo , dri-devel@lists.freedesktop.org Cc: nd@arm.com, Boris Brezillon , Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , linux-kernel@vger.kernel.org References: <20260528150546.3168527-1-karunika.choo@arm.com> <20260528150546.3168527-9-karunika.choo@arm.com> From: Steven Price Content-Language: en-GB In-Reply-To: <20260528150546.3168527-9-karunika.choo@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28/05/2026 16:05, Karunika Choo wrote: > On Mali v15 AM systems, frequency scaling is handled outside panthor by > the AM_GOVERNOR block, so the GPU DT node may not provide an OPP table. > > Make panthor_devfreq_init() return early when operating-points-v2 is > absent, and guard the devfreq helper paths against a missing devfreq > instance. > > This keeps devfreq enabled for existing platforms while allowing v15 AM > systems to probe without a local devfreq setup. > > Signed-off-by: Karunika Choo > --- > drivers/gpu/drm/panthor/panthor_devfreq.c | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/panthor/panthor_devfreq.c b/drivers/gpu/drm/panthor/panthor_devfreq.c > index 2249b41ca4af..c3252ce54437 100644 > --- a/drivers/gpu/drm/panthor/panthor_devfreq.c > +++ b/drivers/gpu/drm/panthor/panthor_devfreq.c > @@ -148,6 +148,9 @@ int panthor_devfreq_init(struct panthor_device *ptdev) > unsigned long freq = ULONG_MAX; > int ret; > > + if (!device_property_read_bool(ptdev->base.dev, "operating-points-v2")) Don't you want device_property_present() here? I'm also a little wary of encoding operating-points-v2 as the check - e.g. it potentially breaks if there's ever a "-v3" or some other way of describing the opps. Can we use the -ENODEV returned from the devm_pm_opp functions instead? > + return 0; > + > pdevfreq = drmm_kzalloc(&ptdev->base, sizeof(*ptdev->devfreq), GFP_KERNEL); > if (!pdevfreq) > return -ENOMEM; > @@ -267,7 +270,7 @@ void panthor_devfreq_resume(struct panthor_device *ptdev) > { > struct panthor_devfreq *pdevfreq = ptdev->devfreq; > > - if (!pdevfreq->devfreq) > + if (!pdevfreq || !pdevfreq->devfreq) > return; > > panthor_devfreq_reset(pdevfreq); > @@ -279,7 +282,7 @@ void panthor_devfreq_suspend(struct panthor_device *ptdev) > { > struct panthor_devfreq *pdevfreq = ptdev->devfreq; > > - if (!pdevfreq->devfreq) > + if (!pdevfreq || !pdevfreq->devfreq) > return; > > drm_WARN_ON(&ptdev->base, devfreq_suspend_device(pdevfreq->devfreq)); > @@ -290,7 +293,7 @@ void panthor_devfreq_record_busy(struct panthor_device *ptdev) > struct panthor_devfreq *pdevfreq = ptdev->devfreq; > unsigned long irqflags; > > - if (!pdevfreq->devfreq) > + if (!pdevfreq || !pdevfreq->devfreq) > return; > > spin_lock_irqsave(&pdevfreq->lock, irqflags); > @@ -306,7 +309,7 @@ void panthor_devfreq_record_idle(struct panthor_device *ptdev) > struct panthor_devfreq *pdevfreq = ptdev->devfreq; > unsigned long irqflags; > > - if (!pdevfreq->devfreq) > + if (!pdevfreq || !pdevfreq->devfreq) > return; > > spin_lock_irqsave(&pdevfreq->lock, irqflags); > @@ -323,7 +326,7 @@ unsigned long panthor_devfreq_get_freq(struct panthor_device *ptdev) > unsigned long freq = 0; > int ret; > > - if (!pdevfreq->devfreq) > + if (!pdevfreq || !pdevfreq->devfreq) > return 0; This has the unfortunate effect of reporting a bogus frequency in panthor_gpu_show_fdinfo(). We should avoid reporting a frequency at all if we don't know it. Or of course even better report the actual frequency the governor block has set. Thanks, Steve > > ret = pdevfreq->devfreq->profile->get_cur_freq(ptdev->base.dev, &freq);