linux-stable.git/drivers/gpu/drm/msm, branch linux-6.15.y

drm/msm: Add error handling for krealloc in metadata setup

2025-08-20T16:36:07+00:00

[ Upstream commit 1c8c354098ea9d4376a58c96ae6b65288a6f15d8 ]

Function msm_ioctl_gem_info_set_metadata() now checks for krealloc
failure and returns -ENOMEM, avoiding potential NULL pointer dereference.
Explicitly avoids __GFP_NOFAIL due to deadlock risks and allocation constraints.

Signed-off-by: Yuan Chen 
Patchwork: https://patchwork.freedesktop.org/patch/661235/
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin

drm/msm: use trylock for debugfs

2025-08-20T16:36:07+00:00

[ Upstream commit 0a1ff88ec5b60b41ba830c5bf08b6cd8f45ab411 ]

This resolves a potential deadlock vs msm_gem_vm_close().  Otherwise for
_NO_SHARE buffers msm_gem_describe() could be trying to acquire the
shared vm resv, while already holding priv->obj_lock.  But _vm_close()
might drop the last reference to a GEM obj while already holding the vm
resv, and msm_gem_free_object() needs to grab priv->obj_lock, a locking
inversion.

OTOH this is only for debugfs and it isn't critical if we undercount by
skipping a locked obj.  So just use trylock() and move along if we can't
get the lock.

Signed-off-by: Rob Clark 
Signed-off-by: Rob Clark 
Tested-by: Antonino Maniscalco 
Reviewed-by: Antonino Maniscalco 
Patchwork: https://patchwork.freedesktop.org/patch/661525/
Signed-off-by: Sasha Levin

drm/msm: Update register xml

2025-08-20T16:36:07+00:00

[ Upstream commit 6733d8276ac02a8790e571d2af4a69a9039d0522 ]

Sync register xml from mesa commit eb3e0b7164a3 ("freedreno/a6xx: Split
descriptors out into their own file").

Signed-off-by: Rob Clark 
Acked-by: Dmitry Baryshkov 
Patchwork: https://patchwork.freedesktop.org/patch/662470/
Signed-off-by: Sasha Levin

drm/msm/dpu: Fill in min_prefill_lines for SC8180X

2025-08-15T10:16:27+00:00

[ Upstream commit 5136acc40afc0261802e5cb01b04f871bf6d876b ]

Based on the downstream release, predictably same value as for SM8150.

Signed-off-by: Konrad Dybcio 
Fixes: f3af2d6ee9ab ("drm/msm/dpu: Add SC8180x to hw catalog")
Reviewed-by: Dmitry Baryshkov 
Patchwork: https://patchwork.freedesktop.org/patch/657794/
Link: https://lore.kernel.org/r/20250610-topic-dpu_8180_mpl-v1-1-f480cd22f11c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Sasha Levin

drm/msm: Fix another leak in the submit error path

2025-07-10T14:08:47+00:00

[ Upstream commit f681c2aa8676a890eacc84044717ab0fd26e058f ]

put_unused_fd() doesn't free the installed file, if we've already done
fd_install().  So we need to also free the sync_file.

Signed-off-by: Rob Clark 
Patchwork: https://patchwork.freedesktop.org/patch/653583/
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin

drm/msm: Fix a fence leak in submit error path

2025-07-10T14:08:46+00:00

[ Upstream commit 5d319f75ccf7f0927425a7545aa1a22b3eedc189 ]

In error paths, we could unref the submit without calling
drm_sched_entity_push_job(), so msm_job_free() will never get
called.  Since drm_sched_job_cleanup() will NULL out the
s_fence, we can use that to detect this case.

Signed-off-by: Rob Clark 
Patchwork: https://patchwork.freedesktop.org/patch/653584/
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin

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

2025-07-06T09:04:21+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/a7xx: Call CP_RESET_CONTEXT_STATE

2025-06-27T10:13:36+00:00

[ Upstream commit 2b520c6104f34e3a548525173c38ebca4402cac3 ]

Calling this packet is necessary when we switch contexts because there
are various pieces of state used by userspace to synchronize between BR
and BV that are persistent across submits and we need to make sure that
they are in a "safe" state when switching contexts. Otherwise a
userspace submission in one context could cause another context to
function incorrectly and hang, effectively a denial of service (although
without leaking data). This was missed during initial a7xx bringup.

Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support")
Signed-off-by: Connor Abbott 
Patchwork: https://patchwork.freedesktop.org/patch/654924/
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin

drm/msm: Fix CP_RESET_CONTEXT_STATE bitfield names

2025-06-27T10:13:36+00:00

[ Upstream commit b1c9e797ad37d188675505b66a3a4bbeea5d9560 ]

Based on kgsl.

Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support")
Signed-off-by: Connor Abbott 
Patchwork: https://patchwork.freedesktop.org/patch/654922/
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin

drm/msm/dsi/dsi_phy_10nm: Fix missing initial VCO rate

2025-06-27T10:13:36+00:00

[ Upstream commit 8a48e35becb214743214f5504e726c3ec131cd6d ]

Driver unconditionally saves current state on first init in
dsi_pll_10nm_init(), but does not save the VCO rate, only some of the
divider registers.  The state is then restored during probe/enable via
msm_dsi_phy_enable() -> msm_dsi_phy_pll_restore_state() ->
dsi_10nm_pll_restore_state().

Restoring calls dsi_pll_10nm_vco_set_rate() with
pll_10nm->vco_current_rate=0, which basically overwrites existing rate of
VCO and messes with clock hierarchy, by setting frequency to 0 to clock
tree.  This makes anyway little sense - VCO rate was not saved, so
should not be restored.

If PLL was not configured configure it to minimum rate to avoid glitches
and configuring entire in clock hierarchy to 0 Hz.

Suggested-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/sz4kbwy5nwsebgf64ia7uq4ee7wbsa5uy3xmlqwcstsbntzcov@ew3dcyjdzmi2/
Signed-off-by: Krzysztof Kozlowski 
Fixes: a4ccc37693a2 ("drm/msm/dsi_pll_10nm: restore VCO rate during
Reviewed-by: Dmitry Baryshkov 
Patchwork: https://patchwork.freedesktop.org/patch/654796/
Link: https://lore.kernel.org/r/20250520111325.92352-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Sasha Levin