kernel/linux.git/drivers/gpu/drm/msm/msm_gpu_devfreq.c, branch v6.6.132

drm/msm/gpu: Fix crash when throttling GPU immediately during boot

2025-07-06T09:00:14+00:00

commit b71717735be48d7743a34897e9e44a0b53e30c0e upstream. There is a small chance that the GPU is already hot during boot. In that case, the call to of_devfreq_cooling_register() will immediately try to apply devfreq cooling, as seen in the following crash: Unable to handle kernel paging request at virtual address 0000000000014110 pc : a6xx_gpu_busy+0x1c/0x58 [msm] lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm] Call trace: a6xx_gpu_busy+0x1c/0x58 [msm] (P) devfreq_simple_ondemand_func+0x3c/0x150 devfreq_update_target+0x44/0xd8 qos_max_notifier_call+0x30/0x84 blocking_notifier_call_chain+0x6c/0xa0 pm_qos_update_target+0xd0/0x110 freq_qos_apply+0x3c/0x74 apply_constraint+0x88/0x148 __dev_pm_qos_update_request+0x7c/0xcc dev_pm_qos_update_request+0x38/0x5c devfreq_cooling_set_cur_state+0x98/0xf0 __thermal_cdev_update+0x64/0xb4 thermal_cdev_update+0x4c/0x58 step_wise_manage+0x1f0/0x318 __thermal_zone_device_update+0x278/0x424 __thermal_cooling_device_register+0x2bc/0x308 thermal_of_cooling_device_register+0x10/0x1c of_devfreq_cooling_register_power+0x240/0x2bc of_devfreq_cooling_register+0x14/0x20 msm_devfreq_init+0xc4/0x1a0 [msm] msm_gpu_init+0x304/0x574 [msm] adreno_gpu_init+0x1c4/0x2e0 [msm] a6xx_gpu_init+0x5c8/0x9c8 [msm] adreno_bind+0x2a8/0x33c [msm] ... At this point we haven't initialized the GMU at all yet, so we cannot read the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag accordingly. This means the df->suspended flag does not match the actual devfreq state after initialization and msm_devfreq_get_dev_status() will end up accessing GMU registers, causing the crash. Fix this by setting df->suspended correctly during initialization. Cc: stable@vger.kernel.org Fixes: 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy") Signed-off-by: Stephan Gerhold Reviewed-by: Douglas Anderson Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/650772/ Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman

drm/msm/gpu: Check the status of registration to PM QoS

2024-12-09T09:32:06+00:00

[ Upstream commit 8f32ddd87e499ba6d2dc74ce30b6932baf1e1fc3 ] There is a need to check the returned value of the registration function. In case of returned error, print that and stop the init process. Fixes: 7c0ffcd40b16 ("drm/msm/gpu: Respect PM QoS constraints") Signed-off-by: Lukasz Luba Patchwork: https://patchwork.freedesktop.org/patch/620336/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin

drm/msm/adreno: Use OPP for every GPU generation

2023-03-20T18:04:59+00:00

Some older GPUs (namely a2xx with no opp tables at all and a320 with downstream-remnants gpu pwrlevels) used not to have OPP tables. They both however had just one frequency defined, making it extremely easy to construct such an OPP table from within the driver if need be. Do so and switch all clk_set_rate calls on core_clk to their OPP counterparts. Reviewed-by: Dmitry Baryshkov Signed-off-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/523784/ Link: https://lore.kernel.org/r/20230223-topic-opp-v3-3-5f22163cd1df@linaro.org Signed-off-by: Rob Clark

drm/msm/gpu: Add default devfreq thresholds

2023-01-16T19:03:25+00:00

Setup more appropriate devfreq tuning thresholds. Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/517788/ Link: https://lore.kernel.org/r/20230110231447.1939101-4-robdclark@gmail.com Reviewed-by: Chia-I Wu

drm/msm/gpu: Bypass PM QoS constraint for idle clamp

2023-01-16T18:40:24+00:00

Change idle freq clamping back to the direct method, bypassing PM QoS requests. The problem with using PM QoS requests is they call (indirectly) the governors ->get_target_freq() which goes thru a get_dev_status() cycle. The problem comes when the GPU becomes active again and we remove the idle-clamp request, we go through another get_dev_status() cycle for the period that the GPU has been idle, which triggers the governor to lower the target freq excessively. This partially reverts commit 7c0ffcd40b16 ("drm/msm/gpu: Respect PM QoS constraints"), but preserves the use of boost QoS request, so that it will continue to play nicely with other QoS requests such as a cooling device. This also mostly undoes commit 78f815c1cf8f ("drm/msm: return the average load over the polling period") Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/517785/ Link: https://lore.kernel.org/r/20230110231447.1939101-3-robdclark@gmail.com Reviewed-by: Chia-I Wu

drm/msm/gpu: Add devfreq tuning debugfs

2023-01-16T18:40:18+00:00

Make the handful of tuning knobs available visible via debugfs. v2: select DEVFREQ_GOV_SIMPLE_ONDEMAND because for some reason struct devfreq_simple_ondemand_data depends on this Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/517784/ Link: https://lore.kernel.org/r/20230110231447.1939101-2-robdclark@gmail.com Reviewed-by: Chia-I Wu

drm/msm/gpu: Drop qos request if devm_devfreq_add_device() fails

2022-08-15T17:19:18+00:00

In the event that devm_devfreq_add_device() fails the device's qos freq list is left referencing df->idle_freq and df->boost_freq. Attempting to initialize devfreq again after a probe deferral will then cause invalid memory accesses in dev_pm_qos_add_request(). Fix this by dropping the requests in the error path. Fixes: 7c0ffcd40b16 ("drm/msm/gpu: Respect PM QoS constraints") Signed-off-by: Bjorn Andersson Reviewed-by: Rob Clark Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/493001/ Link: https://lore.kernel.org/r/20220708162632.3529864-1-bjorn.andersson@linaro.org Signed-off-by: Rob Clark

drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy

2022-07-06T15:38:06+00:00

From testing on sc7180-trogdor devices, reading the GMU registers needs the GMU clocks to be enabled. Those clocks get turned on in a6xx_gmu_resume(). Confusingly enough, that function is called as a result of the runtime_pm of the GPU "struct device", not the GMU "struct device". Unfortunately the current a6xx_gpu_busy() grabs a reference to the GMU's "struct device". The fact that we were grabbing the wrong reference was easily seen to cause crashes that happen if we change the GPU's pm_runtime usage to not use autosuspend. It's also believed to cause some long tail GPU crashes even with autosuspend. We could look at changing it so that we do pm_runtime_get_if_in_use() on the GPU's "struct device", but then we run into a different problem. pm_runtime_get_if_in_use() will return 0 for the GPU's "struct device" the whole time when we're in the "autosuspend delay". That is, when we drop the last reference to the GPU but we're waiting a period before actually suspending then we'll think the GPU is off. One reason that's bad is that if the GPU didn't actually turn off then the cycle counter doesn't lose state and that throws off all of our calculations. Let's change the code to keep track of the suspend state of devfreq. msm_devfreq_suspend() is always called before we actually suspend the GPU and msm_devfreq_resume() after we resume it. This means we can use the suspended state to know if we're powered or not. NOTE: one might wonder when exactly our status function is called when devfreq is supposed to be disabled. The stack crawl I captured was: msm_devfreq_get_dev_status devfreq_simple_ondemand_func devfreq_update_target qos_notifier_call qos_max_notifier_call blocking_notifier_call_chain pm_qos_update_target freq_qos_apply apply_constraint __dev_pm_qos_update_request dev_pm_qos_update_request msm_devfreq_idle_work Fixes: eadf79286a4b ("drm/msm: Check for powered down HW in the devfreq callbacks") Signed-off-by: Douglas Anderson Reviewed-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/489124/ Link: https://lore.kernel.org/r/20220610124639.v4.1.Ie846c5352bc307ee4248d7cab998ab3016b85d06@changeid Signed-off-by: Rob Clark

drm/msm: Use div64_ul instead of do_div

2022-07-05T03:01:11+00:00

Fix following coccicheck warning: drivers/gpu/drm/msm/msm_gpu_devfreq.c:72:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_ul instead. Use div64_ul instead of do_div to avoid a possible truncation. Signed-off-by: Wan Jiabing Reviewed-by: Dmitry Baryshkov Acked-by: Tvrtko Ursulin Patchwork: https://patchwork.freedesktop.org/patch/483499/ Link: https://lore.kernel.org/r/20220426132126.686447-1-wanjiabing@vivo.com Signed-off-by: Dmitry Baryshkov

drm/msm: return the average load over the polling period

2022-04-21T22:05:23+00:00

simple_ondemand interacts poorly with clamp_to_idle. It only looks at the load since the last get_dev_status call, while it should really look at the load over polling_ms. When clamp_to_idle true, it almost always picks the lowest frequency on active because the gpu is idle between msm_devfreq_idle/msm_devfreq_active. This logic could potentially be moved into devfreq core. Fixes: 7c0ffcd40b16 ("drm/msm/gpu: Respect PM QoS constraints") Signed-off-by: Chia-I Wu Cc: Rob Clark Link: https://lore.kernel.org/r/20220416003314.59211-3-olvaffe@gmail.com Signed-off-by: Rob Clark