Repository navigation
Conversation
The layer mixer count is picked purely from the mode width, via the MAX_HDISPLAY_SPLIT threshold. Width is only half of what constrains a mixer: it also processes one pixel per core clock cycle, so a mode narrow enough to stay under the width threshold can still demand a higher pixel rate than one mixer sustains. A 1080 wide panel at a few hundred Hz is enough to get there. Such a mode is currently given a single mixer and then has to be clocked past the maximum core clock rate, which that mixer cannot do. Factor the decision out into dpu_crtc_num_lm_for_mode() and have it ask for a second mixer when the adjusted mode clock does not fit the maximum core clock rate, in addition to the existing width test. Modes that already fit within one mixer are unaffected, so the only decisions that change are the ones that could not be driven as they were. Assisted-by: LLM Link: https://lore.kernel.org/all/20261008-lm_fixes_final-v4-1-fa986071c3c1@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
…g mode clock dpu_crtc_mode_valid() halves the adjusted mode clock whenever the hardware has a 3d_mux block, assuming the mode will be driven by two layer mixers. Modes no wider than MAX_HDISPLAY_SPLIT are driven by a single mixer, so for those the check permits twice the pixel rate the datapath can sustain. Divide by the mixer count the mode will really be driven by, as reported by dpu_crtc_num_lm_for_mode(). Split modes still get the halved rate, single mixer modes are held to what one mixer sustains, and parts without a 3d_mux divide by one. Assisted-by: LLM Link: https://lore.kernel.org/all/20261008-lm_fixes_final-v4-2-fa986071c3c1@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
LM block doesn't have a hardware buffer (unlike PINGPONG and DSC encoders). As such, don't use ephemeral max_mixer_width and MAX_HDISPLAY_SPLIT to validate requested modes. Instead use PP and DSC buffer widths. While on the DPU 8.x+ supports a max linewidth of 8960 for PINGPONG_0, there is some additional logic that needs to be added to the resource manager to specifically try and reserve PINGPONG_0 for modes that are greater than 5k. The layer-mixer count for a merge-capable, non-DSC mode is chosen by dpu_crtc_num_lm_for_mode(); feed the PINGPONG/DSC derived width to it as the split threshold in place of the removed MAX_HDISPLAY_SPLIT, so the pixel-rate floor added earlier keeps high-refresh modes that now fit within a single PINGPONG buffer split across two mixers. [MP: rebased on msm-next; fed PINGPONG/DSC width into dpu_crtc_num_lm_for_mode() instead of open-coding the width test] Link: https://lore.kernel.org/all/20261008-lm_fixes_final-v4-3-fa986071c3c1@oss.qualcomm.com/ Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Tested-by: Xilin Wu <sophon@radxa.com> [DB: reworked to drop catalog changes, updated commit message] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
…width Maximum width of the writeback mode is limited by the hardware buffer in the WB block rather than by the LM properties (LM doesn't have an actual buffer). Use the actual hardware limit (the writeback maxlinewidth) to filter modes. Link: https://lore.kernel.org/all/20261008-lm_fixes_final-v4-4-fa986071c3c1@oss.qualcomm.com/ Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> [DB: fixed commit message] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
Remove the now-unused max_mixer_width field from the HW catalog. It doesn't represent an actual hardware constraint. [MP: rebased on msm-next; also drop the field from the milos, eliza and kaanapali catalogs added since v3] Link: https://lore.kernel.org/all/20261008-lm_fixes_final-v4-5-fa986071c3c1@oss.qualcomm.com/ Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> [Mahadevan: dropped dpu_10_2_milos.h and dpu_12_4_eliza.h hunks, not present in qcom-6.18.y] Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
…o source split Layer mixers without DPU_MIXER_SOURCESPLIT stage one pipe per blend level, so a plane is fetched by a single pipe of at most max_linewidth pixels. max_mixer_width used to reject wider modes. Now that the mode is checked against the PINGPONG width (4096/5120), keep max_linewidth as an extra bound when source split isn't available. Assisted-by: LLM Link: https://lore.kernel.org/all/20261008-lm_fixes_final-v4-6-fa986071c3c1@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
|
Merge Check Failed: CR Not Eligible for Merge CR 4703533 is not eligible for merge. The parent software image for kernel.qli.2.0 is not development complete. Entity: Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations. |
PR #1258 — validate-patchPR: #1258
Final Summary
|
PR #1258 — checker-log-analyzerPR: #1258
Detailed report: Full report
|
…PU < 5.0 Before DPU 5.0, the layer mixer places the higher priority SSPP on the left of a source-split pair. Priority follows the SSPP index (VIG, RGB, DMA), while allocation prefers DMA, RGB, then VIG. Swap the two SSPPs when the right one has the lower index. Both are reserved with the same requirements. Same-SSPP parallel multirect already puts RECT_0, the higher priority rectangle, on the left. Fixes: 8c62a31 ("drm/msm/dpu: allow using two SSPP blocks for a single plane") Assisted-by: LLM Link: https://lore.kernel.org/all/20261010-pipe_order-v1-1-9d8bd29fd78a@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
DPU 5.0 introduced SRC_SPLIT_ORDER in bit 4 of SSPP_SRC_OP_MODE and SSPP_SRC_OP_MODE_REC1. For source-split pairs using legacy CTL routing, this field identifies the left source with 0 and the right source with 1. Add a setup_src_split_order() operation for the SSPP register layout used on DPU 5.0 through 12.x. Select SSPP_SRC_OP_MODE for SOLO or RECT0 and SSPP_SRC_OP_MODE_REC1 for RECT1, and update only the ordering bit. Assisted-by: LLM Link: https://lore.kernel.org/all/20261010-pipe_order-v1-2-9d8bd29fd78a@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
Virtual planes can use two SSPPs when a plane exceeds the single-pipe width or clock limit and parallel multirect cannot be used. Program SRC_SPLIT_ORDER during mixer setup from the pipes' destination X positions. Set the bit for the right source and clear it for the left source or a source without a sibling. Fixes: 8c62a31 ("drm/msm/dpu: allow using two SSPP blocks for a single plane") Assisted-by: LLM Link: https://lore.kernel.org/all/20261010-pipe_order-v1-3-9d8bd29fd78a@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
DPU 13.x places the SSPP op-mode register in separate REC0 and REC1 banks. Add the source split order operation for this layout, using the shared helper to update SRC_SPLIT_ORDER in the selected bank. Assisted-by: LLM Link: https://lore.kernel.org/all/20261010-pipe_order-v1-4-9d8bd29fd78a@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
quicmahap
changed the title
336bc96 to
92f4551
Compare
92f4551 to
cffd975
Compare
PR #1258 — validate-patchPR: #1258
Final Summary
|
PR #1258 — checker-log-analyzerPR: #1258
Detailed report: Full report
|
Test Matrix
|
Test Matrix
|
Test Matrix
|
|
[kernel-checker] failures, after reviewing them, these appear to be expected cases or false positives rather than actual issues: 1.WARNING: Assisted-by expects 'AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]' format Assisted-by: LLM 2.From: Jessica Zhang jesszhan0024@gmail.com Signed-off-by: Jessica Zhang jessica.zhang@oss.qualcomm.com
|
Test Matrix
|
5 participants
CRs-Fixed: 4703533
This PR carries the existing 6-commit layer-mixer (LM) allocation and mode-limit series, followed by the 4-commit pipe-ordering fix.
LM series:
LM series: https://lore.kernel.org/all/20261008-lm_fixes_final-v4-0-fa986071c3c1@oss.qualcomm.com/
Pipe-ordering series:
Pipe-ordering series: https://lore.kernel.org/all/20261010-pipe_order-v1-0-9d8bd29fd78a@oss.qualcomm.com/