Re: [RFC PATCH 08/18] drm/panthor: Skip devfreq when no OPP table is present

[Boris Brezillon <boris.brezillon@collabora.com>]

On Mon, 8 Jun 2026 15:39:56 +0100
Karunika Choo <karunika.choo@arm.com> wrote:

> On 08/06/2026 15:08, Boris Brezillon wrote:
> > On Thu, 28 May 2026 16:05:36 +0100
> > Karunika Choo <karunika.choo@arm.com> 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?

Yep, the clk is exposed and I believe the current clk rate is
properly reflected when clk_get_rate() is called, but the clk framework
only issues notification for rate change requests going through
clk_set_rate(), there's no way for a clk provider to report a rate
change AFAIK.