Repository navigation
Conversation
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
quicmahap
force-pushed
the
drm-lm-fixes-v4-ubuntu
branch
from
October 10, 2026 14:15
2cf0889 to
461bf94
Compare
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
…0 and SA8775p PCIe PHYs Add vdda-refgen and refgen supply properties to dt-bindings, add the sa8775p_qmp_phy_vreg_l regulator list in the PHY driver, and wire up vdda-qref-supply, vdda-refgen-supply and refgen-supply in board DTS files for QCS8300 (qcs8300-ride, monaco-evk, monaco-monza-som, monaco dtsi) and SA8775p (lemans-evk, lemans-ride-common). Without these supplies the PCIe PHY lacks stable reference clock and voltage, causing initialization timeouts and occasional system crashes. Link: https://lore.kernel.org/all/20260916102023.2054761-1-ziyue.zhang@oss.qualcomm.com/ Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Signed-off-by: Abhishek Reddy Sudugu <abhishek.sudugu@oss.qualcomm.com>
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>
…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 resolute-qcom-devel] 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>
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 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 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 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 Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
quicmahap
force-pushed
the
drm-lm-fixes-v4-ubuntu
branch
from
October 10, 2026 14:15
461bf94 to
899d6a4
Compare
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
Author
|
Closing this incorrect Ubuntu PR. The Ubuntu change is now correctly added on top of the existing Ubuntu PR #147: qualcomm-linux/ubuntu-qcom-kernel#147 |
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
2 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.
CRs-Fixed: 4703533
This Ubuntu/qcom-next PR carries the previous PCIe QREF regulator fix, the 5 existing layer-mixer allocation and mode-limit commits, and the 4-commit pipe-ordering fix.
Previous commits:
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/
PCIe QREF series: https://lore.kernel.org/all/20260916102023.2054761-1-ziyue.zhang@oss.qualcomm.com/