summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-03-25drm/msm/dsi: add DSI version >= comparison helperAlexander Koskovich
Add a helper for checking if the DSI hardware version is greater than or equal to a given version, for use in a future change. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Patchwork: https://patchwork.freedesktop.org/patch/713719/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-4-ff6afc904115@pm.me Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dsi: rename MSM8998 DSI version from V2_2_0 to V2_0_0Alexander Koskovich
The MSM8998 DSI controller is v2.0.0 as stated in commit 7b8c9e203039 ("drm/msm/dsi: Add support for MSM8998 DSI controller"). The value was always correct just the name was wrong. Rename and reorder to maintain version sorting. Fixes: 7b8c9e203039 ("drm/msm/dsi: Add support for MSM8998 DSI controller") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Patchwork: https://patchwork.freedesktop.org/patch/713717/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-3-ff6afc904115@pm.me Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/meson: use default case for unsupported DSI pixel formatsAlexander Koskovich
Use default instead of listing unsupported formats explicitly, so the switch statements don't need updating each time a new pixel format is added. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Patchwork: https://patchwork.freedesktop.org/patch/713715/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-2-ff6afc904115@pm.me Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/xe: always keep track of remap prev/nextMatthew Auld
During 3D workload, user is reporting hitting: [ 413.361679] WARNING: drivers/gpu/drm/xe/xe_vm.c:1217 at vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe], CPU#7: vkd3d_queue/9925 [ 413.361944] CPU: 7 UID: 1000 PID: 9925 Comm: vkd3d_queue Kdump: loaded Not tainted 7.0.0-070000rc3-generic #202603090038 PREEMPT(lazy) [ 413.361949] RIP: 0010:vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe] [ 413.362074] RSP: 0018:ffffd4c25c3df930 EFLAGS: 00010282 [ 413.362077] RAX: 0000000000000000 RBX: ffff8f3ee817ed10 RCX: 0000000000000000 [ 413.362078] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 413.362079] RBP: ffffd4c25c3df980 R08: 0000000000000000 R09: 0000000000000000 [ 413.362081] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8f41fbf99380 [ 413.362082] R13: ffff8f3ee817e968 R14: 00000000ffffffef R15: ffff8f43d00bd380 [ 413.362083] FS: 00000001040ff6c0(0000) GS:ffff8f4696d89000(0000) knlGS:00000000330b0000 [ 413.362085] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 413.362086] CR2: 00007ddfc4747000 CR3: 00000002e6262005 CR4: 0000000000f72ef0 [ 413.362088] PKRU: 55555554 [ 413.362089] Call Trace: [ 413.362092] <TASK> [ 413.362096] xe_vm_bind_ioctl+0xa9a/0xc60 [xe] Which seems to hint that the vma we are re-inserting for the ops unwind is either invalid or overlapping with something already inserted in the vm. It shouldn't be invalid since this is a re-insertion, so must have worked before. Leaving the likely culprit as something already placed where we want to insert the vma. Following from that, for the case where we do something like a rebind in the middle of a vma, and one or both mapped ends are already compatible, we skip doing the rebind of those vma and set next/prev to NULL. As well as then adjust the original unmap va range, to avoid unmapping the ends. However, if we trigger the unwind path, we end up with three va, with the two ends never being removed and the original va range in the middle still being the shrunken size. If this occurs, one failure mode is when another unwind op needs to interact with that range, which can happen with a vector of binds. For example, if we need to re-insert something in place of the original va. In this case the va is still the shrunken version, so when removing it and then doing a re-insert it can overlap with the ends, which were never removed, triggering a warning like above, plus leaving the vm in a bad state. With that, we need two things here: 1) Stop nuking the prev/next tracking for the skip cases. Instead relying on checking for skip prev/next, where needed. That way on the unwind path, we now correctly remove both ends. 2) Undo the unmap va shrinkage, on the unwind path. With the two ends now removed the unmap va should expand back to the original size again, before re-insertion. v2: - Update the explanation in the commit message, based on an actual IGT of triggering this issue, rather than conjecture. - Also undo the unmap shrinkage, for the skip case. With the two ends now removed, the original unmap va range should expand back to the original range. v3: - Track the old start/range separately. vma_size/start() uses the va info directly. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7602 Fixes: 8f33b4f054fc ("drm/xe: Avoid doing rebinds") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260318100208.78097-2-matthew.auld@intel.com (cherry picked from commit aec6969f75afbf4e01fd5fb5850ed3e9c27043ac) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-25drm/bridge: analogix_dp: Reuse &link_train.training_lane[] to set DPCD ↵Damon Ding
DP_TRAINING_LANEx_SET In analogix_dp_link_start(), &link_train.training_lane[] is used to set phy PE/VS configurations, and buf[] is initialized with the same values to set DPCD DP_TRAINING_LANEx_SET. It makes sense to reuse &link_train.training_lane[] to set DPCD DP_TRAINING_LANEx_SET, which can remove the redundant assignments and make codes more concise. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20251111022103.1350183-1-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-03-25drm/xe: always keep track of remap prev/nextMatthew Auld
During 3D workload, user is reporting hitting: [ 413.361679] WARNING: drivers/gpu/drm/xe/xe_vm.c:1217 at vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe], CPU#7: vkd3d_queue/9925 [ 413.361944] CPU: 7 UID: 1000 PID: 9925 Comm: vkd3d_queue Kdump: loaded Not tainted 7.0.0-070000rc3-generic #202603090038 PREEMPT(lazy) [ 413.361949] RIP: 0010:vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe] [ 413.362074] RSP: 0018:ffffd4c25c3df930 EFLAGS: 00010282 [ 413.362077] RAX: 0000000000000000 RBX: ffff8f3ee817ed10 RCX: 0000000000000000 [ 413.362078] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 413.362079] RBP: ffffd4c25c3df980 R08: 0000000000000000 R09: 0000000000000000 [ 413.362081] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8f41fbf99380 [ 413.362082] R13: ffff8f3ee817e968 R14: 00000000ffffffef R15: ffff8f43d00bd380 [ 413.362083] FS: 00000001040ff6c0(0000) GS:ffff8f4696d89000(0000) knlGS:00000000330b0000 [ 413.362085] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 413.362086] CR2: 00007ddfc4747000 CR3: 00000002e6262005 CR4: 0000000000f72ef0 [ 413.362088] PKRU: 55555554 [ 413.362089] Call Trace: [ 413.362092] <TASK> [ 413.362096] xe_vm_bind_ioctl+0xa9a/0xc60 [xe] Which seems to hint that the vma we are re-inserting for the ops unwind is either invalid or overlapping with something already inserted in the vm. It shouldn't be invalid since this is a re-insertion, so must have worked before. Leaving the likely culprit as something already placed where we want to insert the vma. Following from that, for the case where we do something like a rebind in the middle of a vma, and one or both mapped ends are already compatible, we skip doing the rebind of those vma and set next/prev to NULL. As well as then adjust the original unmap va range, to avoid unmapping the ends. However, if we trigger the unwind path, we end up with three va, with the two ends never being removed and the original va range in the middle still being the shrunken size. If this occurs, one failure mode is when another unwind op needs to interact with that range, which can happen with a vector of binds. For example, if we need to re-insert something in place of the original va. In this case the va is still the shrunken version, so when removing it and then doing a re-insert it can overlap with the ends, which were never removed, triggering a warning like above, plus leaving the vm in a bad state. With that, we need two things here: 1) Stop nuking the prev/next tracking for the skip cases. Instead relying on checking for skip prev/next, where needed. That way on the unwind path, we now correctly remove both ends. 2) Undo the unmap va shrinkage, on the unwind path. With the two ends now removed the unmap va should expand back to the original size again, before re-insertion. v2: - Update the explanation in the commit message, based on an actual IGT of triggering this issue, rather than conjecture. - Also undo the unmap shrinkage, for the skip case. With the two ends now removed, the original unmap va range should expand back to the original range. v3: - Track the old start/range separately. vma_size/start() uses the va info directly. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7602 Fixes: 8f33b4f054fc ("drm/xe: Avoid doing rebinds") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260318100208.78097-2-matthew.auld@intel.com
2026-03-25drm/gem: Improve drm_gem_objects_lookup() kerneldocTvrtko Ursulin
Make clear that the returned array has to be free using kvfree(). While at it, fix broken reference to non-existant @objs and allow for more error codes on failure. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Cc: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260316093809.97267-1-tvrtko.ursulin@igalia.com [tursulin: fixup spelling]
2026-03-25drm/msm/dpu: support plane splitting in quad-pipe caseJun Nie
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. For non-virtual-plane case, there is always one stage config to serve a LM or LM pair. So the clipping does not occur when interating stages in this case. The plane is mapped to 2 pipes only when width or clock rate exceeds hardware constrain within stage check. 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/711324/ Link: https://lore.kernel.org/r/20260312-msm-next-quad-pipe-split-v19-3-4ffa2b06c996@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/syncobj: Fix xa_alloc allocation flagsTvrtko Ursulin
The xarray conversion blindly and wrongly replaced idr_alloc with xa_alloc and kept the GFP_NOWAIT. It should have been GFP_KERNEL to account for idr_preload it removed. Fix it. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: fec2c3c01f1c ("drm/syncobj: Convert syncobj idr to xarray") Reported-by: Himanshu Girotra <himanshu.girotra@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Himanshu Girotra <himanshu.girotra@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260324111019.22467-1-tvrtko.ursulin@igalia.com
2026-03-25drm/msm/dpu: Defer SSPP allocation until CRTC checkJun Nie
Currently, mapping plane to SSPP occurs during the plane check phase for non-virtual plane case. The SSPP allocation and plane mapping occurs during CRTC check phase for virtual plane case. Defer these SSPP operations until CRTC check stage to unify the 2 cases, and ease later revisement for quad-pipe change. Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/711322/ Link: https://lore.kernel.org/r/20260312-msm-next-quad-pipe-split-v19-2-4ffa2b06c996@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dpu: Extract plane splitting into a dedicated functionJun Nie
dpu_plane_atomic_check_nosspp() currently handles both plane validation and plane splitting. For better simplicity and to facilitate future refactoring, move the splitting logic into its own dedicated function. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Jun Nie <jun.nie@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/711319/ Link: https://lore.kernel.org/r/20260312-msm-next-quad-pipe-split-v19-1-4ffa2b06c996@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dpu: calculate data_width like downstreamAlexander Koskovich
Derive INTF data_width from dce_bytes_per_line rather than timing->width when DSC is enabled. Use DIV_ROUND_UP to avoid rounding errors. Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Pengyu Luo <mitltlatltl@gmail.com> # Lenovo Legion Y700 Gen4 (SM8750) Patchwork: https://patchwork.freedesktop.org/patch/713333/ Link: https://lore.kernel.org/r/20260322-fix-data-width-calc-v2-1-d5f28136bc4e@pm.me Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dpu: drop VBIF index from the struct dpu_hw_vbifDmitry Baryshkov
Since we don't support and don't use VBIF_NRT, VBIF_RT is the only possible VBIF type. To simplify the driver, drop vbif_idx from the VBIF instance structure. As the last users of VBIF_RT and enum dpu_vbif are gone, drop them too. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/707779/ Link: https://lore.kernel.org/r/20260227-drop-vbif-nrt-v1-7-2b97d0438182@oss.qualcomm.com
2026-03-25drm/msm/dpu: drop VBIF index from the VBIF paramsDmitry Baryshkov
Since we don't support and don't use VBIF_NRT, VBIF_RT is the only possible VBIF type. To simplify the driver, drop vbif_idx from the VBIF parameter structures. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/707783/ Link: https://lore.kernel.org/r/20260227-drop-vbif-nrt-v1-6-2b97d0438182@oss.qualcomm.com
2026-03-25drm/msm/dpu: drop vbif_idx from WB configurationDmitry Baryshkov
All MDP / DPU implementations except for MSM8996 use VBIF_RT (or the only VBIF) for WB2. Writeback on MSM8996 is not supported (nor planned to be supported). In order to simplify the driver, drop the field form the struct dpu_wb_cfg. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/707778/ Link: https://lore.kernel.org/r/20260227-drop-vbif-nrt-v1-5-2b97d0438182@oss.qualcomm.com [DB: also handled Eliza platform] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dpu: drop VBIF id, base and name from the catalogDmitry Baryshkov
For all the platforms VBIF id is VBIF_RT, the name and base are also fixed. Drop those fields from the catalog. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/707777/ Link: https://lore.kernel.org/r/20260227-drop-vbif-nrt-v1-4-2b97d0438182@oss.qualcomm.com
2026-03-25drm/msm/dpu: replace VBIF-related array with bare pointersDmitry Baryshkov
As we no longer have multiple VBIF instances, it doesn't make sense to keep VBIF data as arrays. Drop the extra wrapping and keep only a single instance of each of the structures. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/707776/ Link: https://lore.kernel.org/r/20260227-drop-vbif-nrt-v1-3-2b97d0438182@oss.qualcomm.com
2026-03-25drm/msm/dpu: stop declaring VBIFs as an array in catalogDmitry Baryshkov
The driver handles a single VBIF instance, VBIF_RT. Stop declaring VBIFs as an array in the DPU hardware catalog. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/707774/ Link: https://lore.kernel.org/r/20260227-drop-vbif-nrt-v1-2-2b97d0438182@oss.qualcomm.com [DB: handled Eliza platform] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dpu: drop VBIF_NRT handlingDmitry Baryshkov
The second VBIF instance, VBIF_NRT, is only used for the separate inline rotator block. It is unsupported by the DPU driver and will require a separate driver (or separate instance of the DPU device). The only possible user of VBIF_NRT is writeback on MSM8996, however writeback on that platform is currently unsupported and it's not worth keeping extra complexity for the sake of that single legacy platform. None of the hardware catalogs entries actually declare VBIF_NRT, so it is left in its default state. Stop pretending that DPU driver cares about VBIF_NRT and drop it. Reported-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/707773/ Link: https://lore.kernel.org/r/20260227-drop-vbif-nrt-v1-1-2b97d0438182@oss.qualcomm.com
2026-03-25drm/msm/dsi: fix hdisplay calculation for CMD mode panelPengyu Luo
Commit ac47870fd795 ("drm/msm/dsi: fix hdisplay calculation when programming dsi registers") incorrecly broke hdisplay calculation for CMD mode by specifying incorrect number of bytes per transfer, fix it. Fixes: ac47870fd795 ("drm/msm/dsi: fix hdisplay calculation when programming dsi registers") Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/709917/ Link: https://lore.kernel.org/r/20260307111250.105772-2-mitltlatltl@gmail.com [DB: fixed commit message] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dsi: fix bits_per_pclkPengyu Luo
mipi_dsi_pixel_format_to_bpp return dst bpp not src bpp, dst bpp may not be the uncompressed data size. use src bpc * 3 to get src bpp, this aligns with pclk rate calculation. Fixes: ac47870fd795 ("drm/msm/dsi: fix hdisplay calculation when programming dsi registers") Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/709916/ Link: https://lore.kernel.org/r/20260307111250.105772-1-mitltlatltl@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dpu: fix vblank IRQ registration before atomic_mode_setCédric Bellegarde
dpu_encoder_toggle_vblank_for_crtc() can call control_vblank_irq() at any time in response to a userspace vblank request, independently of the atomic commit sequence. If this happens before the encoder's first atomic_mode_set(), irq[INTR_IDX_RDPTR] is still zero. Passing irq_idx=0 to dpu_core_irq_register_callback() is treated as invalid, and DPU_IRQ_REG(0) and DPU_IRQ_BIT(0) produce misleading values of 134217727 and 31 respectively due to unsigned wraparound in the (irq_idx - 1) macros, resulting in the confusing error: [dpu error]invalid IRQ=[134217727, 31] Since irq[INTR_IDX_RDPTR] will be properly populated by atomic_mode_set() and registered by irq_enable() as part of the normal modeset sequence, silently skip the vblank IRQ registration when the index has not yet been initialized. This matches the existing pattern of the master encoder check above it. Signed-off-by: Cédric Bellegarde <cedric.bellegarde@adishatz.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/712752/ Link: https://lore.kernel.org/r/20260318171700.394945-1-cedric.bellegarde@adishatz.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dpu: don't try using 2 LMs if only one DSC is availableDmitry Baryshkov
Current topology code will try using 2 LMs with just one DSC, which breaks cases like SC7280 / Fairphone5. Forbid using 2 LMs split in such a case. Fixes: 1ce69c265a53 ("drm/msm/dpu: move resource allocation to CRTC") Reported-by: Luca Weiss <luca.weiss@fairphone.com> Closes: https://lore.kernel.org/r/DH1IKLU0YZYU.2SW4WYO7H3H4R@fairphone.com/ Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcm6490-fairphone-fp5 Patchwork: https://patchwork.freedesktop.org/patch/712386/ Link: https://lore.kernel.org/r/20260317-fix-3d-dsc-v1-1-88b54f62f659@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/hdmi: Drop redundant 'int' for longsKrzysztof Kozlowski
'long' type is already an integer, so 'int' is redundant. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/711175/ Link: https://lore.kernel.org/r/20260311-drm-msm-hdmi-cleanup-v1-5-c5535245f6de@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/hdmi: Consistently use u32 instead of uint32_tKrzysztof Kozlowski
Linux coding style asks to use kernel types like u32 instead of uint32_t and code already has it in other places, so unify the remaining pieces. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/711172/ Link: https://lore.kernel.org/r/20260311-drm-msm-hdmi-cleanup-v1-4-c5535245f6de@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/hdmi: Simplify with local 'dev' variableKrzysztof Kozlowski
msm_hdmi_dev_probe() function already stores pdev->dev in local variable, so use it directly to make code simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/711171/ Link: https://lore.kernel.org/r/20260311-drm-msm-hdmi-cleanup-v1-3-c5535245f6de@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/hdmi: Avoid double error print on msm_hdmi_get_phy() failureKrzysztof Kozlowski
msm_hdmi_get_phy() already prints error messages on each error path using dev_err_probe(), so final DRM_DEV_ERROR() would duplicate it and possibly flood the dmesg on probe deferrals. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/711168/ Link: https://lore.kernel.org/r/20260311-drm-msm-hdmi-cleanup-v1-2-c5535245f6de@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/hdmi: Simplify with dev_of_node()Krzysztof Kozlowski
Simplify chain of pointer dereferences with dev_of_node() which also checks if 'dev' argument is non-NULL. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/711167/ Link: https://lore.kernel.org/r/20260311-drm-msm-hdmi-cleanup-v1-1-c5535245f6de@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/hdmi: Fix wrong CTRL1 register used in writing info framesKrzysztof Kozlowski
Commit 384d2b03d0a1 ("drm/msm/hdmi: make use of the drm_connector_hdmi framework") changed the unconditional register writes in few places to updates: read, apply mask, write. The new code reads REG_HDMI_INFOFRAME_CTRL1 register, applies fields/mask for HDMI_INFOFRAME_CTRL0 register and finally writes to HDMI_INFOFRAME_CTRL0. This difference between CTRL1 and CTRL0 looks unintended and may result in wrong data being written to HDMI bridge registers. Cc: <stable@vger.kernel.org> Fixes: 384d2b03d0a1 ("drm/msm/hdmi: make use of the drm_connector_hdmi framework") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/711156/ Link: https://lore.kernel.org/r/20260311191620.245394-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/hdmi: make 'msm_hdmi_pm_ops' staticBen Dooks
The struct 'msm_hdmi_pm_ops' is not used outside of the file it is defined in, so make it static. Fixes the following sparse warning: drivers/gpu/drm/msm/hdmi/hdmi.c:432:1: warning: symbol 'msm_hdmi_pm_ops' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/710583/ Link: https://lore.kernel.org/r/20260310132501.195954-1-ben.dooks@codethink.co.uk Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/mdss: Add a TODO for better managing the MDSS clock power stateKonrad Dybcio
There's a small window where the MDP clock could be set to a high rate (say, from the bootloader) without a corresponding RPM(H)PD vote to back it up. This is normally not an issue, but could be, if rmmod fails to shut down the display driver cleanly, and the module is inserted again, or when the providers' .sync_state has timed out. Mark a TODO to fix it one day. Linking the relevant discussion below. Link: https://lore.kernel.org/linux-arm-msm/d5c4eed5-bd87-4156-b178-2d78140ec8a9@oss.qualcomm.com/ Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/710572/ Link: https://lore.kernel.org/r/20260310-topic-mdss_power_todo-v1-1-59457b8b7486@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dsi: add the missing parameter descriptionPengyu Luo
Add a description for is_bonded_dsi in dsi_adjust_pclk_for_compression to match the existing kernel-doc comment. Fixes: e4eb11b34d6c ("drm/msm/dsi: fix pclk rate calculation for bonded dsi") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202603080314.XeqyRZ7A-lkp@intel.com/ Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/710112/ Link: https://lore.kernel.org/r/20260309100254.877801-1-mitltlatltl@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dpu: fix mismatch between power and frequencyYuanjie Yang
During DPU runtime suspend, calling dev_pm_opp_set_rate(dev, 0) drops the MMCX rail to MIN_SVS while the core clock frequency remains at its original (highest) rate. When runtime resume re-enables the clock, this may result in a mismatch between the rail voltage and the clock rate. For example, in the DPU bind path, the sequence could be: cpu0: dev_sync_state -> rpmhpd_sync_state cpu1: dpu_kms_hw_init timeline 0 ------------------------------------------------> t After rpmhpd_sync_state, the voltage performance is no longer guaranteed to stay at the highest level. During dpu_kms_hw_init, calling dev_pm_opp_set_rate(dev, 0) drops the voltage, causing the MMCX rail to fall to MIN_SVS while the core clock is still at its maximum frequency. When the power is re-enabled, only the clock is enabled, leading to a situation where the MMCX rail is at MIN_SVS but the core clock is at its highest rate. In this state, the rail cannot sustain the clock rate, which may cause instability or system crash. Remove the call to dev_pm_opp_set_rate(dev, 0) from dpu_runtime_suspend to ensure the correct vote is restored when DPU resumes. Fixes: b0530eb11913 ("drm/msm/dpu: Use OPP API to set clk/perf state") Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/710077/ Link: https://lore.kernel.org/r/20260309063720.13572-1-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/mdss: Add support for Eliza SoCKrzysztof Kozlowski
Add support for the Qualcomm Eliza SoC platform. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/708874/ Link: https://lore.kernel.org/r/20260304-drm-display-eliza-v2-8-ea0579f62358@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dpu: Add support for Eliza SoCKrzysztof Kozlowski
Add support for DPU (v12.4) on Qualcomm Eliza SoC, with one incomplete/skipped part: HDMI interface (INT_4). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/708879/ Link: https://lore.kernel.org/r/20260304-drm-display-eliza-v2-7-ea0579f62358@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/mdp5: Remove MSM8974v1Konrad Dybcio
To the best of my knowledge, the v1 version of this SoC had been superseded before any device was released on the market. Everywhere else in the kernel, there are assumptions about the SoC being revision 2 or the later MSM8974PRO. Remove the config for that flavor of MDP. To bring the naming in line with the rest of the kernel, remove the v2 suffix from the remaining config. Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/708112/ Link: https://lore.kernel.org/r/20260302-topic-goodnight_8974v1-v1-1-e0006f7a0526@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm: add missing MODULE_DEVICE_ID definitionsDmitry Baryshkov
The drm/msm module bundles several drivers, each of them having a separate OF match table, however only MDSS (subsystem), KMS devices and GPU have corresponding MODULE_DEVICE_ID tables. Add MODULE_DEVICE_ID to the display-related driver and to all other drivers in this module, simplifying userspace job. Fixes: 060530f1ea67 ("drm/msm: use componentised device support") Reported-by: Loïc Minier <loic.minier@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/707960/ Link: https://lore.kernel.org/r/20260228-msm-device-id-v2-1-24b085919444@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dpu: enable virtual planes by defaultDmitry Baryshkov
Turn on the switch and use virtual planes by default, enhancing utilisation of the display pipelines. It is still possible to use legacy implementation by using `msm.dpu_use_virtual_planes=false` kernel boot parameter. Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455, Patchwork: https://patchwork.freedesktop.org/patch/707437/ Link: https://lore.kernel.org/r/20260226-dpu-enable-virt-planes-v2-1-87971236fe86@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/i915: move CNP clock gating init into intel_pchLuca Coelho
Move the CNP PCH clock gating programming into intel_pch_init_clock_gating() and switch the corresponding CFL/CML caller to the display-specific code. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260324080441.154609-5-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-03-25drm/i915: move LPT clock gating init into intel_pchLuca Coelho
Move the LPT PCH clock gating programming into intel_pch_init_clock_gating() and switch the corresponding Haswell/Broadwell callers to the display-specific code. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260324080441.154609-4-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-03-25drm/i915: move CPT clock gating init into intel_pchLuca Coelho
Move the CPT PCH clock gating programming into intel_pch_init_clock_gating() and switch the corresponding IVB callers to the display-specific code. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260324080441.154609-3-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-03-25drm/i915/display: move clock-gating init for IBX to displayLuca Coelho
Add a new function in the display code to help initialize clock-gating without reading display PCH registers directly from non-display code. This adds a mini-framework to deal with display-specific PCH registers and uses it for IBX as a start. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260324080441.154609-2-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-03-25drm/bridge: lt8713sx: avoid 64-bit divisionArnd Bergmann
On 32-bit kernels, 64-bit integers cannot be passed to the division operator: ld.lld-22: error: undefined symbol: __aeabi_uldivmod >>> referenced by lontium-lt8713sx.c >>> drivers/gpu/drm/bridge/lontium-lt8713sx.o:(lt8713sx_firmware_store) in archive vmlinux.a Since this is a constant number used to divide a size_t, just change the type to that as well. Fixes: 4037c6adc1f9 ("drm/bridge: add support for lontium lt8713sx bridge driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260316215920.1993390-1-arnd@kernel.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/bridge: lt8713sx select CONFIG_CRC8Arnd Bergmann
CRC8 needs to be enabled for lt8713sx to build: ld.lld-22: error: undefined symbol: crc8_populate_msb >>> referenced by lontium-lt8713sx.c >>> drivers/gpu/drm/bridge/lontium-lt8713sx.o:(lt8713sx_probe) in archive vmlinux.a Fixes: 4037c6adc1f9 ("drm/bridge: add support for lontium lt8713sx bridge driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260318105130.1969966-1-arnd@kernel.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dsi/phy: rename DSI_PHY_7NM_QUIRK_PRE_V4_1 to DSI_PHY_7NM_QUIRK_V4_0Pengyu Luo
The quirk flag DSI_PHY_7NM_QUIRK_PRE_V4_1 is renamed to DSI_PHY_7NM_QUIRK_V4_0 to better reflect the actual hardware revision it applies to. (Only SM8150 uses it, its hardware revision is 4.0) No functional change. Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/707416/ Link: https://lore.kernel.org/r/20260226122958.22555-3-mitltlatltl@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/msm/dpu: use full scale alpha in _dpu_crtc_setup_blend_cfg()Dmitry Baryshkov
Both _dpu_crtc_setup_blend_cfg() and setup_blend_config_alpha() callbacks embed knowledge about platform's alpha range (8-bit or 10-bit). Make _dpu_crtc_setup_blend_cfg() use full 16-bit values for alpha and reduce alpha only in DPU-specific callbacks. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/697898/ Link: https://lore.kernel.org/r/20260112-dpu-rework-alpha-v2-2-d168785911d5@oss.qualcomm.com
2026-03-25drm/msm/dpu: simplify bg_alpha selectionDmitry Baryshkov
In order to be more obvious in fg_alpha / bg_alpha handling during the blending programming drop the default setting for background alpha value and set it explicitly in all cases. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/697896/ Link: https://lore.kernel.org/r/20260112-dpu-rework-alpha-v2-1-d168785911d5@oss.qualcomm.com
2026-03-25gpu: nova-core: create GSP-RM logging buffers debugfs entriesTimur Tabi
Create read-only debugfs entries for LOGINIT, LOGRM, and LOGINTR, which are the three primary printf logging buffers from GSP-RM. LOGPMU will be added at a later date, as it requires support for its RPC message first. This patch uses the `pin_init_scope` feature to create the entries. `pin_init_scope` solves the lifetime issue over the `DEBUGFS_ROOT` reference by delaying its acquisition until the time the entry is actually initialized. Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Timur Tabi <ttabi@nvidia.com> Tested-by: John Hubbard <jhubbard@nvidia.com> Tested-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260319212658.2541610-7-ttabi@nvidia.com [ Rebase onto Coherent<T> changes. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-25gpu: nova-core: create debugfs root in module initTimur Tabi
Create the 'nova_core' root debugfs entry when the driver loads. Normally, non-const global variables need to be protected by a mutex. Instead, we use unsafe code, as we know the entry is never modified after the driver is loaded. This solves the lifetime issue of the mutex guard, which would otherwise have required the use of `pin_init_scope`. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: John Hubbard <jhubbard@nvidia.com> Tested-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260319212658.2541610-6-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-25gpu: nova-core: Replace module_pci_driver! with explicit module initTimur Tabi
Replace the module_pci_driver! macro with an explicit module initialization using the standard module! macro and InPlaceModule trait implementation. No functional change intended, with the exception that the driver now prints a message when loaded. This change is necessary so that we can create a top-level "nova_core" debugfs entry when the driver is loaded. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: John Hubbard <jhubbard@nvidia.com> Tested-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260319212658.2541610-5-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-06 09:11:32 +0000