On 08/06/2026 15:08, Boris Brezillon wrote: > On Thu, 28 May 2026 16:05:36 +0100 > Karunika Choo <[email protected]> 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. > > OOC, is this still handled as clock frequency changes? I'm asking > because the recent perfcnt work requires registering clk notifiers to > get an approximation of the number of shader/top-level/coregroup clock > cycles on a given period of time so we an calculate relative GPU > utilization, and so far we've only considered clk notifiers as a way to > get informed of these frequency changes. > > BTW, this is already problematic for the mediatek GPUEB design, where > devfreq stuff is delegated to an MCU, and we don't currently have a way > to get notified when this MCU changes the frequencies. >
I believe we should still support initializing clocks and registering notifiers for them. We are just disabling the devfreq subsystem in this patch. Would mediatek be able to expose a child clock or logical clock from ther GPUEB driver to Panthor so that we can get these notifications? Kind regards, Karunika Choo >> >> 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 <[email protected]> > > Reviewed-by: Boris Brezillon <[email protected]> > >> --- >> 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")) >> + 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; >> >> ret = pdevfreq->devfreq->profile->get_cur_freq(ptdev->base.dev, &freq); >
