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

drm/msm/dpu: cast crtc_clk calculation to u64 in _dpu_core_perf_calc_clk()

2024-12-05T12:53:19+00:00

[ Upstream commit 20c7b42d9dbd048019bfe0af39229e3014007a98 ]

There may be a potential integer overflow issue in
_dpu_core_perf_calc_clk(). crtc_clk is defined as u64, while
mode->vtotal, mode->hdisplay, and drm_mode_vrefresh(mode) are defined as
a smaller data type. The result of the calculation will be limited to
"int" in this case without correct casting. In screen with high
resolution and high refresh rate, integer overflow may happen.
So, we recommend adding an extra cast to prevent potential
integer overflow.

Fixes: c33b7c0389e1 ("drm/msm/dpu: add support for clk and bw scaling for display")
Signed-off-by: Zichen Xie 
Reviewed-by: Abhinav Kumar 
Patchwork: https://patchwork.freedesktop.org/patch/622206/
Link: https://lore.kernel.org/r/20241029194209.23684-1-zichenxie0106@gmail.com
Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Sasha Levin

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

2024-12-05T12:53:17+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 IRQF_NO_AUTOEN flag in request_irq()

2024-12-05T12:53:17+00:00

[ Upstream commit 394679f322649d06fea3c646ba65f5a0887f52c3 ]

disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable when request IRQ.

Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Jinjie Ruan 
Patchwork: https://patchwork.freedesktop.org/patch/614075/
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin

drm/msm/dpu: drop LM_3 / LM_4 on MSM8998

2024-12-05T12:53:16+00:00

[ Upstream commit c59afe50773d5c972f6684f9bbd9a2ddb2fb92fa ]

On the MSM8998 platform ther are no LM_3 and LM_4 blocks. Drop them from
the MSM8998 catalog.

Fixes: 94391a14fc27 ("drm/msm/dpu1: Add MSM8998 to hw catalog")
Reported-by: Abhinav Kumar 
Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Patchwork: https://patchwork.freedesktop.org/patch/612585/
Link: https://lore.kernel.org/r/20240905-dpu-fix-sdm845-catalog-v1-3-3363d03998bd@linaro.org
Signed-off-by: Sasha Levin

drm/msm/dpu: drop LM_3 / LM_4 on SDM845

2024-12-05T12:53:15+00:00

[ Upstream commit d39271061d67c6fcbe8f361c532b493069232cf8 ]

On the SDM845 platform ther are no LM_3 and LM_4 blocks. Drop them from
the SDM845 catalog.

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Patchwork: https://patchwork.freedesktop.org/patch/612586/
Link: https://lore.kernel.org/r/20240905-dpu-fix-sdm845-catalog-v1-2-3363d03998bd@linaro.org
Signed-off-by: Sasha Levin

drm/msm/dpu: on SDM845 move DSPP_3 to LM_5 block

2024-12-05T12:53:15+00:00

[ Upstream commit 768a272d5357269b17b4b06dd8647e21bdc0ca3c ]

On the SDM845 platform the DSPP_3 is used by the LM_5. Correct
corresponding entries in the sdm845_lm array.

Fixes: c72375172194 ("drm/msm/dpu/catalog: define DSPP blocks found on sdm845")
Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
Patchwork: https://patchwork.freedesktop.org/patch/612584/
Link: https://lore.kernel.org/r/20240905-dpu-fix-sdm845-catalog-v1-1-3363d03998bd@linaro.org
Signed-off-by: Sasha Levin

drm/msm/a6xx+: Insert a fence wait before SMMU table update

2024-11-01T01:02:29+00:00

[ Upstream commit 77ad507dbb7ec1ecd60fc081d03616960ef596fd ]

The CP_SMMU_TABLE_UPDATE _should_ be waiting for idle, but on some
devices (x1-85, possibly others), it seems to pass that barrier while
there are still things in the event completion FIFO waiting to be
written back to memory.

Work around that by adding a fence wait before context switch.  The
CP_EVENT_WRITE that writes the fence is the last write from a submit,
so seeing this value hit memory is a reliable indication that it is
safe to proceed with the context switch.

v2: Only emit CP_WAIT_TIMESTAMP on a7xx, as it is not supported on a6xx.
    Conversely, I've not been able to reproduce this issue on a6xx, so
    hopefully it is limited to a7xx, or perhaps just certain a7xx
    devices.

Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support")
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/63
Signed-off-by: Rob Clark 
Reviewed-by: Akhil P Oommen 
Signed-off-by: Abhinav Kumar 
Signed-off-by: Sasha Levin

drm/msm/dpu: don't always program merge_3d block

2024-11-01T01:02:29+00:00

[ Upstream commit f87f3b80abaf7949e638dd17dfdc267066eb52d5 ]

Only program the merge_3d block for the video phys encoder when the 3d
blend mode is not NONE

Fixes: 3e79527a33a8 ("drm/msm/dpu: enable merge_3d support on sm8150/sm8250")
Suggested-by: Abhinav Kumar 
Signed-off-by: Jessica Zhang 
Patchwork: https://patchwork.freedesktop.org/patch/619095/
Link: https://lore.kernel.org/r/20241009-merge3d-fix-v1-1-0d0b6f5c244e@quicinc.com
Signed-off-by: Abhinav Kumar 
Signed-off-by: Sasha Levin

drm/msm/dpu: Don't always set merge_3d pending flush

2024-11-01T01:02:29+00:00

[ Upstream commit 40dad89cb86ce824f2080441b2a6b7aedf695329 ]

Don't set the merge_3d pending flush bits if the mode_3d is
BLEND_3D_NONE.

Always flushing merge_3d can cause timeout issues when there are
multiple commits with concurrent writeback enabled.

This is because the video phys enc waits for the hw_ctl flush register
to be completely cleared [1] in its wait_for_commit_done(), but the WB
encoder always sets the merge_3d pending flush during each commit
regardless of if the merge_3d is actually active.

This means that the hw_ctl flush register will never be 0 when there are
multiple CWB commits and the video phys enc will hit vblank timeout
errors after the first CWB commit.

[1] commit fe9df3f50c39 ("drm/msm/dpu: add real wait_for_commit_done()")

Fixes: 3e79527a33a8 ("drm/msm/dpu: enable merge_3d support on sm8150/sm8250")
Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback")
Signed-off-by: Jessica Zhang 
Reviewed-by: Dmitry Baryshkov 
Patchwork: https://patchwork.freedesktop.org/patch/619092/
Link: https://lore.kernel.org/r/20241009-mode3d-fix-v1-1-c0258354fadc@quicinc.com
Signed-off-by: Abhinav Kumar 
Signed-off-by: Sasha Levin

drm/msm: Allocate memory for disp snapshot with kvzalloc()

2024-11-01T01:02:28+00:00

[ Upstream commit e4a45582db1b792c57bdb52c45958264f7fcfbdc ]

With the "drm/msm: add a display mmu fault handler" series [1] we saw
issues in the field where memory allocation was failing when
allocating space for registers in msm_disp_state_dump_regs().
Specifically we were seeing an order 5 allocation fail. It's not
surprising that order 5 allocations will sometimes fail after the
system has been up and running for a while.

There's no need here for contiguous memory. Change the allocation to
kvzalloc() which should make it much less likely to fail.

[1] https://lore.kernel.org/r/20240628214848.4075651-1-quic_abhinavk@quicinc.com/

Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot")
Signed-off-by: Douglas Anderson 
Reviewed-by: Abhinav Kumar 
Patchwork: https://patchwork.freedesktop.org/patch/619658/
Link: https://lore.kernel.org/r/20241014093605.2.I72441365ffe91f3dceb17db0a8ec976af8139590@changeid
Signed-off-by: Abhinav Kumar 
Signed-off-by: Sasha Levin