On Mon, 8 Jun 2026 15:39:56 +0100 Karunika Choo <[email protected]> wrote:
> 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? 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.
