On 10/23/2026 3:29 AM, Akhil P Oommen wrote: > On 10/20/2026 7:35 AM, Fabricio Akio via B4 Relay wrote: >> On SDM630, SDM660 and MSM8998 the GPU's GX power domain belongs to its >> SMMU, not to the GPU, so GX switches off only once the SMMU suspends as > > This is incorrect. There is no Adreno GPU where SMMU is powered by GX. I > looked > at the DT of SDM630 and I don't understand it. Seems like a creative > workaround > to vote different power domains. > > Please reword GX -> CX here. Adreno SMMU is powered by CX GDSC in every > chipset. > In some chipsets, the core GPU blocks are also powered via CX GDSC. So it > makes sense to do a SW RESET in case CX didn't collapse due to a vote from the > SMMU driver or something.
Ok, the SMMU is on CX. It is the DT that gives it GX, as Konrad also pointed out, and v3 will say so. The message keeps GX, though: with a test DT putting the SMMU on CX alone and the GPU on GX, the CP lost its ring state on all 4 resumes with the SMMU held awake; with the current DT it kept it on all 3. So v3's first sentence becomes: On SDM630, SDM660 and MSM8998 the device tree attaches the GPU's GX power domain to its SMMU, whose own domain is CX, so GX switches off only once the SMMU suspends as well. > Instead of a new API, we can just move msm_devfreq_resume() here. That will > align > with the A6xx sequence. I take that to mean removing the call from msm_gpu_pm_resume(). That reaches A3xx and A4xx as well, so v3 does it in a patch of its own before this one: a4xx_pm_resume() and a new a3xx_pm_resume() wrapper call it right after msm_gpu_pm_resume(), where it ran before, and a5xx_pm_resume() then moves it after the reset. A2xx has no gpu_busy callback, so it has no devfreq. I can only test on A508, so A3xx and A4xx are untested.
