On 02/05/2023 03:56, Jeykumar Sankaran wrote:
On 4/30/2023 1:57 PM, Dmitry Baryshkov wrote:
The function dpu_plane_sspp_update_pipe() contains code to skip enabling
the QoS and OT limitis for CURSOR pipes. However all DPU since sdm845
repurpose DMA SSPP for the cursor planes because they lack the real
CURSOR SSPP. Fix the condition to actually check that the plane is
CURSOR or not.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 43d9fbc0c687..36f6eb71fef8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1124,7 +1124,8 @@ static void dpu_plane_sspp_update_pipe(struct
drm_plane *plane,
_dpu_plane_set_qos_lut(plane, pipe, fmt, pipe_cfg);
_dpu_plane_set_danger_lut(plane, pipe, fmt);
- if (plane->type != DRM_PLANE_TYPE_CURSOR) {
+ if (pipe->sspp->idx == SSPP_CURSOR0 ||
+ pipe->sspp->idx == SSPP_CURSOR1) {
Isn't this differ from the current sequence: The existing sequence
programs QOS for all the non-cursor SSPP's. This patch programs QOS only
for CURSOR SSPP's.
Thanks for the catch! I was thinking about inverting the condition and
ended up overengineering it.
If DMA SSPP's are used for cursor planes, we should ideally remove this
check.
Unfortunately, we also support 8998 (and patches to use CURSOR SSPP were
posted to the mailing list). The plan is to also support some of 1.x
MDP5/DPU units (e.g. 8996), which would also make use of origin CURSOR
planes. So we can not drop this. I'll post v2 fixing the issue.
Jeykumar S.
_dpu_plane_set_qos_ctrl(plane, pipe, true,
DPU_PLANE_QOS_PANIC_CTRL);
_dpu_plane_set_ot_limit(plane, pipe, pipe_cfg, frame_rate);
}
--
With best wishes
Dmitry
