Re: [PATCH RFT 0/5] drm/msm: Attach a driver to GMU

[Vladyslav Tymoshchuk <tvlad744@gmail.com>]

Hi Akhil,

On Sun, 26 Jul 2026 21:35:35 +0530, Akhil P Oommen wrote:
> I didn't get a chance to revisit this series after my vacation. I am too
> not aware of any impact outside of those dmesg warnings. Any chance this
> recent rpmh related fix is helping with the deep sleep instead of this
> series:
>
> https://lore.kernel.org/lkml/20260605-assorted-fixes-june-v1-1-2caa04f7287c@oss.qualcomm.com/

A data point from SM8750 (OnePlus Pad 3; the board DT is still local).
My tree is v7.3-rc5 plus board patches, so that fix is already in it
as d9108bfdb746 ("drm/msm/a6xx: Fix stale rpmh votes after suspend").
Without this series the clock controllers still wait for the GMU:

  gxclkctl-kaanapali 3d64000.clock-controller: sync_state() pending due to 3d6c000.gmu
  gcc-sm8750 100000.clock-controller: sync_state() pending due to 3d6c000.gmu
  sm8750-gpucc 3d90000.clock-controller: sync_state() pending due to 3d6c000.gmu

With the series applied these lines are gone, adreno_gmu binds
3d6c000.gmu, the GMU firmware loads, and KWin runs with OpenGL
compositing. I saw no new adreno or GMU errors, including across two
s2idle cycles.

I can't say what the series alone does for suspend on this board: the
interconnect providers here are also held by 1dfa000.crypto (QCE is
BROKEN, the issue Konrad raised in the "crypto: qce - Remove driver"
thread), and I only measured with both resolved.

One note for v2: 5/5 did not apply to a6xx_gpu.c on v7.3-rc5, because
a6xx_gpu_init() there already holds the GMU node with
__free(device_node). I ported that hunk by hand and dropped the
of_node_put().

For the series:

Tested-by: Vladyslav Tymoshchuk <tvlad744@gmail.com> # sm8750-oneplus-erhai

Thanks,
Vladyslav

(I used an AI assistant, Claude, for the analysis and to draft this
mail; the tests ran on my device.)