For mst2.0#514
Open
YongxingMou wants to merge 117 commits intoqualcomm-linux:qcom-6.18.yfrom
Open
Conversation
YongxingMou
requested review from
a team,
mukeshojha-linux,
quic-tingweiz and
shashim-quic
We have drm_crtc_vblank_waitqueue() to get the wait_queue_head_t pointer for a vblank. Use it instead of poking at dev->vblank[] directly. Due to the macro maze of wait_event_timeout() that uses the address-of operator on the argument, we have to pass it in with the indirection operator. Cc: Rob Clark <robin.clark@oss.qualcomm.com> Cc: Dmitry Baryshkov <lumag@kernel.org> Cc: Abhinav Kumar <abhinav.kumar@linux.dev> Cc: Jessica Zhang <jesszhan0024@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: Marijn Suijten <marijn.suijten@somainline.org> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/5917fd537f4a775a1c135a68f294df3917980943.1762513240.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 95eacb8)
Describe the Universal Bandwidth Compression (UBWC) configuration for the new Glymur platform. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251014-glymur-display-v2-7-ff935e2f88c5@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add the ubwc configuration for Kaanapali chipset. This chipset brings support for UBWC v6 version. The rest of the configurations remains as usual. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250930-kaana-gpu-support-v1-1-73530b0700ed@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
…ixers() 'mixer' is only zeroed and is not use. Remove it. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Acked-By: Mahesh Bharadwaj Kannan <mahesh.kannan@oss.qualcomm.com> Fixes: ae4d721 ("drm/msm/dpu: add an API to reset the encoder related hw blocks") Patchwork: https://patchwork.freedesktop.org/patch/679854/ Link: https://lore.kernel.org/r/8e3b2fbbf5440aa219feb667f5423c7479eb2656.1760040536.git.christophe.jaillet@wanadoo.fr Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit 762dd3e)
Current code only supports usage cases with one pair of mixers at most. To support quad-pipe usage case, two pairs of mixers need to be reserved. The lm_count for all pairs is cleared if a peer allocation fails in current implementation. Reset the current lm_count to an even number instead of completely clearing it. This prevents all pairs from being cleared in cases where multiple LM pairs are needed. Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/675400/ Link: https://lore.kernel.org/r/20250918-v6-16-rc2-quad-pipe-upstream-4-v16-1-ff6232e3472f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit 74c4efe)
There are 2 interfaces and 4 pingpong in quad pipe. Map the 2nd interface to 3rd PP instead of the 2nd PP. Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/675402/ Link: https://lore.kernel.org/r/20250918-v6-16-rc2-quad-pipe-upstream-4-v16-2-ff6232e3472f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit e4f87fd)
Add pipe as trace argument in trace_dpu_crtc_setup_mixer() to ease converting pipe into pipe array later. Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/675404/ Link: https://lore.kernel.org/r/20250918-v6-16-rc2-quad-pipe-upstream-4-v16-3-ff6232e3472f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit 2c94547)
There are 2 pipes in a drm plane at most currently, while 4 pipes are required for quad-pipe case. Generalize the handling to pipe pair and ease handling to another pipe pair later. Store pipes in array with removing dedicated r_pipe. Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/675406/ Link: https://lore.kernel.org/r/20250918-v6-16-rc2-quad-pipe-upstream-4-v16-4-ff6232e3472f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit fb4c972)
… mixer The stage contains configuration for a mixer pair. Currently the plane supports just one stage and 2 pipes. Quad-pipe support will require handling 2 stages and 4 pipes at the same time. In preparation for that add a separate define, PIPES_PER_PLANE, to denote number of pipes that can be used by the plane. Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/675408/ Link: https://lore.kernel.org/r/20250918-v6-16-rc2-quad-pipe-upstream-4-v16-5-ff6232e3472f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit 5d45171)
Currently MAX_CHANNELS_PER_ENC is defined as 2, because 2 channels are supported at most in one encoder. The case of 4 channels per encoder is to be added. To avoid breaking current WB usage case, use dedicated WB definition before 4 WB usage case is supported in future. Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/675410/ Link: https://lore.kernel.org/r/20250918-v6-16-rc2-quad-pipe-upstream-4-v16-6-ff6232e3472f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit aed7564)
Currently, only 2 pipes are used at most for a plane. A stage structure describes the configuration for a mixer pair. So only one stage is needed for current usage cases. The quad-pipe case will be added in future and 2 stages are used in the case. So extend the stage to an array with array size STAGES_PER_PLANE and blend pipes per mixer pair with configuration in the stage structure. Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/675412/ Link: https://lore.kernel.org/r/20250918-v6-16-rc2-quad-pipe-upstream-4-v16-7-ff6232e3472f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit c11684c)
Currently, SSPPs are assigned to a maximum of two pipes. However, quad-pipe usage scenarios require four pipes and involve configuring two stages. In quad-pipe case, the first two pipes share a set of mixer configurations and enable multi-rect mode when certain conditions are met. The same applies to the subsequent two pipes. Assign SSPPs to the pipes in each stage using a unified method and to loop the stages accordingly. Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/675414/ Link: https://lore.kernel.org/r/20250918-v6-16-rc2-quad-pipe-upstream-4-v16-8-ff6232e3472f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit cf63d61)
The content of every half of screen is sent out via one interface in dual-DSI case. The content for every interface is blended by a LM pair in quad-pipe case, thus a LM pair should not blend any content that cross the half of screen in this case. Clip plane into pipes per left and right half screen ROI if topology is quad pipe case. The clipped rectangle on every half of screen is futher handled by two pipes if its width exceeds a limit for a single pipe. Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/675416/ Link: https://lore.kernel.org/r/20250918-v6-16-rc2-quad-pipe-upstream-4-v16-9-ff6232e3472f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit 5978864)
To support high-resolution cases that exceed the width limitation of a pair of SSPPs, or scenarios that surpass the maximum MDP clock rate, additional pipes are necessary to enable parallel data processing within the SSPP width constraints and MDP clock rate. Request 4 mixers and 4 DSCs for high-resolution cases where both DSC and dual interfaces are enabled. More use cases can be incorporated later if quad-pipe capabilities are required. Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/675418/ Link: https://lore.kernel.org/r/20250918-v6-16-rc2-quad-pipe-upstream-4-v16-10-ff6232e3472f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit d7ec936)
Add DPU version v12.2 support for the Glymur platform. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/683721/ Link: https://lore.kernel.org/r/20251027-glymur-display-v3-5-aa13055818ac@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit e2aeb8d)
The Qualcomm Glymur platform comes with 4 DisplayPort controllers, which have a different core revision compared to all previous platforms. Describe them and add the compatible. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/683722/ Link: https://lore.kernel.org/r/20251027-glymur-display-v3-6-aa13055818ac@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit 244fe8c)
Fix all kernel-doc warnings in msm_disp_snapshot.h: msm_disp_snapshot.h:53: warning: Function parameter or struct member 'blocks' not described in 'msm_disp_state' msm_disp_snapshot.h:69: warning: Function parameter or struct member 'node' not described in 'msm_disp_state_block' msm_disp_snapshot.h:69: warning: Excess struct member 'drm_dev' description in 'msm_disp_state_block' msm_disp_snapshot.h:95: warning: No description found for return value of 'msm_disp_snapshot_state_sync' msm_disp_snapshot.h:100: warning: bad line: msm_disp_snapshot.h:117: warning: bad line: msm_disp_snapshot.h:125: warning: bad line: msm_disp_snapshot.h:142: warning: Excess function parameter 'name' description in 'msm_disp_snapshot_add_block' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/687132/ Link: https://lore.kernel.org/r/20251111060353.1972869-1-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit e149847)
Use %ptSp instead of open coded variants to print content of struct timespec64 in human readable format. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20251113150217.3030010-7-andriy.shevchenko@linux.intel.com Signed-off-by: Petr Mladek <pmladek@suse.com> (cherry picked from commit 9d2a48c)
Correct and add kernel-doc comments to eliminate all warnings: Warning: ../drivers/gpu/drm/msm/disp/mdp_format.h:27 This comment starts with '/**', but isn't a kernel-doc comment. Warning: ../drivers/gpu/drm/msm/disp/mdp_format.h:64 struct member 'bpc_a' not described in 'msm_format' Warning: ../drivers/gpu/drm/msm/disp/mdp_format.h:64 struct member 'bpc_b_cb' not described in 'msm_format' Warning: ../drivers/gpu/drm/msm/disp/mdp_format.h:64 struct member 'bpc_g_y' not described in 'msm_format' Warning: ../drivers/gpu/drm/msm/disp/mdp_format.h:64 struct member 'bpc_r_cr' not described in 'msm_format' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695650/ Link: https://lore.kernel.org/r/20251219184638.1813181-2-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit a50d877)
Correct and add kernel-doc comments to eliminate all warnings: Warning: ../drivers/gpu/drm/msm/dp/dp_debug.h:31 expecting prototype for msm_dp_debug_get(). Prototype was for msm_dp_debug_init() instead Warning: ../drivers/gpu/drm/msm/dp/dp_drm.c:24 function parameter 'connector' not described in 'msm_dp_bridge_detect' Warning: ../drivers/gpu/drm/msm/dp/dp_link.h:90 expecting prototype for mdss_dp_test_bit_depth_to_bpp(). Prototype was for msm_dp_link_bit_depth_to_bpp() instead Warning: ../drivers/gpu/drm/msm/dp/dp_link.h:126 function parameter 'aux' not described in 'msm_dp_link_get' Warning: ../drivers/gpu/drm/msm/dp/dp_link.h:126 function parameter 'dev' not described in 'msm_dp_link_get' Warning: ../drivers/gpu/drm/msm/dp/dp_panel.h:70 function parameter 'bw_code' not described in 'is_link_rate_valid' Warning: ../drivers/gpu/drm/msm/dp/dp_panel.h:84 expecting prototype for msm_dp_link_is_lane_count_valid(). Prototype was for is_lane_count_valid() instead Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695647/ Link: https://lore.kernel.org/r/20251219184638.1813181-3-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit 23bee88)
Correct and add kernel-doc comments to eliminate all warnings: Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.h:91 Incorrect use of kernel-doc format: * Enable the CDM module Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.h:97 Incorrect use of kernel-doc format: * Enable/disable the connection with pingpong Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695651/ Link: https://lore.kernel.org/r/20251219184638.1813181-4-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit ce26953)
Correct and add kernel-doc comments to eliminate all warnings: Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:18 cannot understand function prototype: 'enum dpu_ctl_mode_sel' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:58 struct member 'wb' not described in 'dpu_hw_intf_cfg' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:66 Incorrect use of kernel-doc format: * kickoff hw operation for Sw controlled interfaces Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:73 Incorrect use of kernel-doc format: * check if the ctl is started Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:80 Incorrect use of kernel-doc format: * kickoff prepare is in progress hw operation for sw Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:88 Incorrect use of kernel-doc format: * Clear the value of the cached pending_flush_mask Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:96 Incorrect use of kernel-doc format: * Query the value of the cached pending_flush_mask Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:103 Incorrect use of kernel-doc format: * OR in the given flushbits to the cached pending_flush_mask Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:112 Incorrect use of kernel-doc format: * OR in the given flushbits to the cached pending_(wb_)flush_mask Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:121 Incorrect use of kernel-doc format: * OR in the given flushbits to the cached pending_(cwb_)flush_mask Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:130 Incorrect use of kernel-doc format: * OR in the given flushbits to the cached pending_(intf_)flush_mask Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:139 Incorrect use of kernel-doc format: * OR in the given flushbits to the cached pending_(periph_)flush_mask Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:148 Incorrect use of kernel-doc format: * OR in the given flushbits to the cached pending_(merge_3d_)flush_mask Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:157 Incorrect use of kernel-doc format: * OR in the given flushbits to the cached pending_flush_mask Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:166 Incorrect use of kernel-doc format: * OR in the given flushbits to the cached pending_flush_mask Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:175 Incorrect use of kernel-doc format: * OR in the given flushbits to the cached pending_flush_mask Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:185 Incorrect use of kernel-doc format: * OR in the given flushbits to the cached pending_(dsc_)flush_mask Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:194 Incorrect use of kernel-doc format: * OR in the given flushbits to the cached pending_(cdm_)flush_mask Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:202 Incorrect use of kernel-doc format: * Write the value of the pending_flush_mask to hardware Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:208 Incorrect use of kernel-doc format: * Read the value of the flush register Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:215 Incorrect use of kernel-doc format: * Setup ctl_path interface config Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:223 Incorrect use of kernel-doc format: * reset ctl_path interface config Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:244 Incorrect use of kernel-doc format: * Set all blend stages to disabled Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:250 Incorrect use of kernel-doc format: * Configure layer mixer to pipe configuration Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:262 Incorrect use of kernel-doc format: * Set active pipes attached to this CTL Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:270 Incorrect use of kernel-doc format: * Set active layer mixers attached to this CTL Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:277 struct member 'trigger_start' not described in 'dpu_hw_ctl_ops' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:277 struct member 'is_started' not described in 'dpu_hw_ctl_ops' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:277 struct member 'trigger_pending' not described in 'dpu_hw_ctl_ops' [many here] Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:319 struct member 'pending_periph_flush_mask' not described in 'dpu_hw_ctl' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:319 struct member 'pending_merge_3d_flush_mask' not described in 'dpu_hw_ctl' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:319 struct member 'pending_dspp_flush_mask' not described in 'dpu_hw_ctl' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h:327 expecting prototype for dpu_hw_ctl(). Prototype was for to_dpu_hw_ctl() instead Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695649/ Link: https://lore.kernel.org/r/20251219184638.1813181-5-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit 686f6aa)
Correct or add kernel-doc comments to eliminate all warnings: Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.h:30 Cannot find identifier on line: * Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cwb.h:61 expecting prototype for dpu_hw_cwb(). Prototype was for to_dpu_hw_cwb() instead Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695664/ Link: https://lore.kernel.org/r/20251219184638.1813181-6-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit 70e66a0)
Correct or add kernel-doc comments to eliminate all warnings: Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h:23 Incorrect use of kernel-doc format: * dsc_disable - disable dsc Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h:29 Incorrect use of kernel-doc format: * dsc_config - configures dsc encoder Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h:41 Incorrect use of kernel-doc format: * dsc_config_thresh - programs panel thresholds Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h:50 struct member 'dsc_disable' not described in 'dpu_hw_dsc_ops' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h:50 struct member 'dsc_config' not described in 'dpu_hw_dsc_ops' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h:50 struct member 'dsc_config_thresh' not described in 'dpu_hw_dsc_ops' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h:50 struct member 'dsc_bind_pingpong_blk' not described in 'dpu_hw_dsc_ops' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695658/ Link: https://lore.kernel.org/r/20251219184638.1813181-7-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit 9d22d53)
Correct or add kernel-doc comments to eliminate all warnings: Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h:33 expecting prototype for struct dpu_hw_pcc. Prototype was for struct dpu_hw_pcc_cfg instead Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h:42 Incorrect use of kernel-doc format: * setup_pcc - setup dspp pcc Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h:48 struct member 'setup_pcc' not described in 'dpu_hw_dspp_ops' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h:76 expecting prototype for dpu_hw_dspp(). Prototype was for to_dpu_hw_dspp() instead Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695652/ Link: https://lore.kernel.org/r/20251219184638.1813181-8-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit 399f434)
Correct or add kernel-doc comments to eliminate all warnings: Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h:76 duplicate section name 'Return' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h:112 Incorrect use of kernel-doc format: * Disable autorefresh if enabled Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h:118 struct member 'setup_timing_gen' not described in 'dpu_hw_intf_ops' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h:118 struct member 'setup_prg_fetch' not described in 'dpu_hw_intf_ops' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h:118 struct member 'enable_timing' not described in 'dpu_hw_intf_ops' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h:118 struct member 'get_status' not described in 'dpu_hw_intf_ops' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h:118 struct member 'get_line_count' not described in 'dpu_hw_intf_ops' Warning: drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h:118 struct member 'disable_autorefresh' not described in 'dpu_hw_intf_ops' dpu_hw_intf.h:119: warning: Excess struct member 'get_vsync_info' description in 'dpu_hw_intf_ops' dpu_hw_intf.h:119: warning: Excess struct member 'setup_autorefresh' description in 'dpu_hw_intf_ops' dpu_hw_intf.h:119: warning: Excess struct member 'get_autorefresh' description in 'dpu_hw_intf_ops' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/695646/ Link: https://lore.kernel.org/r/20251219184638.1813181-9-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (cherry picked from commit f6d7545)
dp_bridge helpers take drm_bridge as an input and extract the dp_display object to be used in the dp_display module. Rather than doing it in a roundabout way, directly pass the dp_display object to these helpers so that the MST bridge can also re-use the same helpers. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-11-b20518dea8de@oss.qualcomm.com/
For MST, the link setup should only be done once when multiple sinks are enabled, while stream setup may run multiple times for each sink. Split the link-related preparation out of msm_dp_display_atomic_enable() so it can be called separately before the per-stream enable path. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-12-b20518dea8de@oss.qualcomm.com/
With MST, each DP controller can handle multiple streams. There shall be one dp_panel for each stream but the dp_display object shall be shared among them. To represent this abstraction, create a stream_id for each DP panel which shall be set by the MST stream. For SST, default this to stream 0. Use the stream ID to control the pixel clock of that respective stream by extending the clock handles and state tracking of the DP pixel clock to an array of max supported streams. The maximum streams currently is 4. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-13-b20518dea8de@oss.qualcomm.com/
…port Introduce the `mst_streams` field in each DP controller descriptor to specify the number of supported MST streams. Most platforms support 2 or 4 MST streams, while platforms without MST support default to a single stream (`DEFAULT_STREAM_COUNT = 1`). Also accounts for platforms with asymmetric stream support, e.g., DP0 supporting 4 streams and DP1 supporting 2. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-14-b20518dea8de@oss.qualcomm.com/
…locks Add support for additional pixel register blocks (p1, p2, p3) to enable 4‑stream MST pixel clocks. Introduce the helper functions msm_dp_read_pn and msm_dp_write_pn for pixel register programming. All pixel clocks share the same register layout but use different base addresses. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-15-b20518dea8de@oss.qualcomm.com/
Use the dp_panel's stream_id to adjust the offsets for stream 1 which will be used for MST in the dp_catalog. Stream 1 share the same link clk with stream 0 with different reg offset. Also add additional register defines for stream 1. Streams 2 and 3 are not covered here, as they use separate link clocks and require separate handling. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-16-b20518dea8de@oss.qualcomm.com/
To support 4-stream MST, the link clocks for stream 3 and stream 4 are controlled by MST_2_LCLK and MST_3_LCLK which share the same register definitions but use different base addresses. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-17-b20518dea8de@oss.qualcomm.com/
Whenever virtual channel slot allocation changes, the DP source must send the action control trigger sequence to notify the sink about the same. This would be applicable during the start and stop of the pixel stream. Add the infrastructure to be able to send ACT packets for the DP controller when operating in MST mode. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-18-b20518dea8de@oss.qualcomm.com/
Add support to program the MST enable bit in the mainlink control register when an MST session is active or being disabled. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-19-b20518dea8de@oss.qualcomm.com/
DP stream is transmitted in transfer units only for SST case, there is no need to calculate and program TU parameters for MST case. Skip the TU programming for MST cases. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-20-b20518dea8de@oss.qualcomm.com/
DP MST streams share 64 MTP slots in a time-multiplexed manner. This patch adds support for calculating the rate governor, slot allocation, and slot reservation in the DP controller. Each MST stream can reserve its slots by calling dp_display_set_stream_info() from its bridge callbacks. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-21-b20518dea8de@oss.qualcomm.com/
…roller The VC Payload Fill (VCPF) sequence is inserted by the DP controller when stream symbols are absent, typically before a stream is disabled. This patch adds support for triggering the VCPF sequence in the MSM DP controller. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-22-b20518dea8de@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
…se cases As per the hardware programming guide, MST_FIFO_CONSTANT_FILL must always be programmed when operating in MST mode. This patch ensures the register is configured accordingly. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-23-b20518dea8de@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Move the common disable steps out of the sink_count check to make the flow easier to follow. No functional change intended. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-24-b20518dea8de@oss.qualcomm.com/
Pass struct msm_dp_panel to the display enable/disable helpers to make them easier to reuse for MST stream handling. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-25-b20518dea8de@oss.qualcomm.com/
…ccept a panel Currently the dp_display bridge helpers, in particular the dp_display_enable()/dp_display_disable() use the cached panel. To be able to re-use these helpers for MST use-case abstract the helpers to use the panel which is passed in to them. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-26-b20518dea8de@oss.qualcomm.com/
…display For DP MST, the link clock and power domain resources stay on until both streams have been disabled OR we receive hotplug. Introduce an active_stream_cnt to track the number of active streams and necessary state handling. Replace the power_on variable with active_stream_cnt as power_on boolean works only for a single stream. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-27-b20518dea8de@oss.qualcomm.com/
…tive The bridge detect function is only applicable for SST. In MST mode, connector detection is handled by MST bridges. This patch skips detection for the SST bridge when MST is active. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
If the DP controller is capable of supporting multiple streams then initialize the DP sink in MST mode by programming the DP_MSTM_CTRL DPCD register to enable MST mode. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-29-b20518dea8de@oss.qualcomm.com/
Add an API dp_display_get_panel() to initialize and return a DP panel to be used by DP MST module. Since some of the fields of DP panel are private, dp_display module needs to initialize these parts and return the panel back. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-30-b20518dea8de@oss.qualcomm.com/
In MST mode, multiple streams share the same DP link. Track a prepared state so msm_dp_display_prepare() runs only once per link and repeated calls are skipped. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-31-b20518dea8de@oss.qualcomm.com/
Simply initialize MST encoders for MST-capable DP controllers, and introduce msm_dp_get_mst_max_stream to query MST streams. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-32-b20518dea8de@oss.qualcomm.com/
…ller For each MST capable DP controller, initialize a dp_mst module to manage its DP MST operations. The DP MST module for each controller is the central entity to manage its topology related operations as well as interfacing with the rest of the DP driver. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-33-b20518dea8de@oss.qualcomm.com/
Add dp_mst_drm to manage the DP MST bridge operations similar to the dp_drm file which manages the SST bridge operations. Each MST encoder creates one bridge and each bridge is bound to its own dp_panel abstraction to manage the operations of its pipeline. Keep the connector/panel association in bridge private state for atomic assignment and release, and mirror it in the bridge object for runtime bridge callbacks. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-34-b20518dea8de@oss.qualcomm.com/
…aths Call drm_dp_mst_atomic_check() from msm_atomic_check() so MST-specific state, such as connector and topology changes, is validated as part of the atomic check. Hook the MST helpers into atomic_commit_setup() and atomic_commit_tail() to support non-blocking atomic commits for DisplayPort MST, and ensure MST commits properly wait for dependencies. For SST, non-blocking commits are already handled via commit_tail(), which waits for dependencies in the DRM core. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-35-b20518dea8de@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Introduce an MST connector abstraction for DP MST, with each MST connector associated with a DP panel and connected through a DRM bridge to an MST encoder. The connector is only used for MST helper callbacks, such as detect, get_modes, and get_encoder. Display enable/disable, hotplug handling, and modeset sequencing continue to be handled by the bridge path. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-36-b20518dea8de@oss.qualcomm.com/
Add HPD callback for the MST module which shall be invoked from the dp_display's HPD handler to perform MST specific operations in case of HPD. In MST case, route the HPD messages to MST module. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-37-b20518dea8de@oss.qualcomm.com/
Use msm_dp_get_mst_intf_id() to get the interface ID for the DP MST controller as the intf_id is unique for each MST stream of each DP controller. For DSI/eDP/DP SST, the stream_id is always 0, so existing behavior remains unchanged. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260410-msm-dp-mst-v4-38-b20518dea8de@oss.qualcomm.com/
…r 0 and 1 This change enables SA8775P support for Multi-Stream Transport (MST), allowing each controller to handle up to two or four DisplayPort streams. As all necessary code for MST support was already implemented in the previous series of patches. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20250825-msm-dp-mst-v3-38-01faacfcdedd@oss.qualcomm.com/
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add support for Multi-stream transport for MSM chipsets that allow
a single instance of DP controller to send multiple streams.
This series has been validated on sa8775p ride platform using multiple
MST dongles and also daisy chain method on both DP0 and DP1 upto 1080P.
With 4x4K monitors, due to lack of layer mixers that combination will not
work but this can be supported as well after some rework on the DPU side.
In addition, SST was re-validated with all these changes to ensure there
were no regressions.
CRs-Fixed:4511768