Akhil P Oommen [Fri, 27 Mar 2026 00:14:06 +0000 (05:44 +0530)]
drm/msm/adreno: Expose a PARAM to check AQE support
AQE (Applicaton Qrisc Engine) is required to support VK ray-pipeline. Two
conditions should be met to use this HW:
1. AQE firmware should be loaded and programmed
2. Preemption support
Expose a new MSM_PARAM to allow userspace to query its support.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714685/
Message-ID: <20260327-a8xx-gpu-batch2-v2-17-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:14:05 +0000 (05:44 +0530)]
drm/msm/a6xx: Enable Preemption on X2-85
Add the save-restore register lists and set the necessary quirk flags
in the catalog to enable the Preemption feature on Adreno X2-85 GPU.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714684/
Message-ID: <20260327-a8xx-gpu-batch2-v2-16-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:14:04 +0000 (05:44 +0530)]
drm/msm/a8xx: Preemption support for A840
The programing sequence related to preemption is unchanged from A7x. But
there is some code churn due to register shuffling in A8x. So, split out
the common code into a header file for code sharing and add/update
additional changes required to support preemption feature on A8x GPUs.
Finally, enable the preemption quirk in A840's catalog to enable this
feature.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714682/
Message-ID: <20260327-a8xx-gpu-batch2-v2-15-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:14:03 +0000 (05:44 +0530)]
drm/msm/a8xx: Implement IFPC support for A840
Implement pwrup reglist support and add the necessary register
configurations to enable IFPC support on A840
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714679/
Message-ID: <20260327-a8xx-gpu-batch2-v2-14-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:14:02 +0000 (05:44 +0530)]
drm/msm/a6xx: Add SKU detection support for X2-85
Add the Speedbin table to the catalog to enable SKU detection support
for X2-85 GPU found in Glymur chipset. As this chipset support the SOFT
FUSE mechanism, enable the ADRENO_QUIRK_SOFTFUSE quirk too.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714677/
Message-ID: <20260327-a8xx-gpu-batch2-v2-13-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:14:01 +0000 (05:44 +0530)]
drm/msm/a6xx: Add soft fuse detection support
Recent chipsets like Glymur supports a new mechanism for SKU detection.
A new CX_MISC register exposes the combined (or final) speedbin value
from both HW fuse register and the Soft Fuse register. Implement this new
SKU detection along with a new quirk to identify the GPUs that has soft
fuse support.
There is a side effect of this patch on A4x and older series. The
speedbin field in the MSM_PARAM_CHIPID will be 0 instead of 0xffff. This
should be okay as Mesa correctly handles it. Speedbin was not even a
thing when those GPUs' support were added.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714676/
Message-ID: <20260327-a8xx-gpu-batch2-v2-12-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:14:00 +0000 (05:44 +0530)]
drm/msm/a8xx: Add SKU table for A840
Add the SKU table in the catalog for A840 GPU. This data helps to pick
the correct bin from the OPP table based on the speed_bin fuse value.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714673/
Message-ID: <20260327-a8xx-gpu-batch2-v2-11-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:13:59 +0000 (05:43 +0530)]
drm/msm/a6xx: Update HFI definitions
Update the HFI definitions to support additional GMU based power
features.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714671/
Message-ID: <20260327-a8xx-gpu-batch2-v2-10-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:13:58 +0000 (05:43 +0530)]
drm/msm/a6xx: Use packed structs for HFI
HFI related structs define the ABI between the KMD and the GMU firmware.
So, use packed structures to avoid unintended compiler inserted padding.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714669/
Message-ID: <20260327-a8xx-gpu-batch2-v2-9-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:13:56 +0000 (05:43 +0530)]
drm/msm/a6xx: Add support for Debug HFI Q
Add the Debug HFI Queue which contains the F2H messages posted from the
GMU firmware. Having this data in coredump is useful to debug firmware
issues.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714666/
Message-ID: <20260327-a8xx-gpu-batch2-v2-7-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:13:55 +0000 (05:43 +0530)]
drm/msm/a6xx: Fix gpu init from secure world
A7XX_GEN2 and newer GPUs requires initialization of few configurations
related to features/power from secure world. The SCM call to do this
should be triggered after GDSC and clocks are enabled. So, keep this
sequence to a6xx_gmu_resume instead of the probe.
Also, simplify the error handling in a6xx_gmu_resume() using 'goto'
labels.
Fixes: 14b27d5df3ea ("drm/msm/a7xx: Initialize a750 "software fuse"") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714664/
Message-ID: <20260327-a8xx-gpu-batch2-v2-6-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:13:53 +0000 (05:43 +0530)]
drm/msm/a6xx: Correct OOB usage
During the GMU resume sequence, using another OOB other than OOB_GPU may
confuse the internal state of GMU firmware. To align more strictly with
the downstream sequence, move the sysprof related OOB setup after the
OOB_GPU is cleared.
Fixes: 62cd0fa6990b ("drm/msm/adreno: Disable IFPC when sysprof is active") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714659/
Message-ID: <20260327-a8xx-gpu-batch2-v2-4-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:13:52 +0000 (05:43 +0530)]
drm/msm/a6xx: Switch to preemption safe AO counter
CP_ALWAYS_ON_COUNTER is not save-restored during preemption, so it won't
provide accurate data about the 'submit' when preemption is enabled.
Switch to CP_ALWAYS_ON_CONTEXT which is preemption safe.
Fixes: e7ae83da4a28 ("drm/msm/a6xx: Implement preemption for a7xx targets") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714657/
Message-ID: <20260327-a8xx-gpu-batch2-v2-3-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:13:51 +0000 (05:43 +0530)]
drm/msm/a8xx: Fix the ticks used in submit traces
GMU_ALWAYS_ON_COUNTER_* registers got moved in A8x, but currently, A6x
register offsets are used in the submit traces instead of A8x offsets.
To fix this, refactor a bit and use adreno_gpu->funcs->get_timestamp()
everywhere.
While we are at it, update a8xx_gmu_get_timestamp() to use the GMU AO
counter.
Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714655/
Message-ID: <20260327-a8xx-gpu-batch2-v2-2-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Fri, 27 Mar 2026 00:13:50 +0000 (05:43 +0530)]
drm/msm/a6xx: Use barriers while updating HFI Q headers
To avoid harmful compiler optimizations and IO reordering in the HW, use
barriers and READ/WRITE_ONCE helpers as necessary while accessing the HFI
queue index variables.
Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/714653/
Message-ID: <20260327-a8xx-gpu-batch2-v2-1-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Yasuaki Torimaru [Wed, 25 Mar 2026 11:46:34 +0000 (20:46 +0900)]
drm/msm/gem: fix error handling in msm_ioctl_gem_info_get_metadata()
msm_ioctl_gem_info_get_metadata() always returns 0 regardless of
errors. When copy_to_user() fails or the user buffer is too small,
the error code stored in ret is ignored because the function
unconditionally returns 0. This causes userspace to believe the
ioctl succeeded when it did not.
Additionally, kmemdup() can return NULL on allocation failure, but
the return value is not checked. This leads to a NULL pointer
dereference in the subsequent copy_to_user() call.
Add the missing NULL check for kmemdup() and return ret instead of 0.
Note that the SET counterpart (msm_ioctl_gem_info_set_metadata)
correctly returns ret.
Fixes: 9902cb999e4e ("drm/msm/gem: Add metadata") Cc: stable@vger.kernel.org Signed-off-by: Yasuaki Torimaru <yasuakitorimaru@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/714478/
Message-ID: <20260325114635.383241-1-yasuakitorimaru@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Rob Clark [Wed, 25 Mar 2026 18:41:05 +0000 (11:41 -0700)]
drm/msm/shrinker: Fix can_block() logic
The intention here was to allow blocking if DIRECT_RECLAIM or if called
from kswapd and KSWAPD_RECLAIM is set.
Reported by Claude code review: https://lore.gitlab.freedesktop.org/drm-ai-reviews/review-patch9-20260309151119.290217-10-boris.brezillon@collabora.com/ on a panthor patch which had copied similar logic.
Reported-by: Boris Brezillon <boris.brezillon@collabora.com> Fixes: 7860d720a84c ("drm/msm: Fix build break with recent mm tree") Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Patchwork: https://patchwork.freedesktop.org/patch/714238/
Message-ID: <20260325184106.1259528-1-robin.clark@oss.qualcomm.com>
Rob Clark [Tue, 24 Mar 2026 22:05:17 +0000 (15:05 -0700)]
drm/msm: Disallow foreign mapping of _NO_SHARE
This restriction applies to mapping of _NO_SHARE objs in the kms vm as
well as importing/exporting BOs. Since the DPU has it's own VM, scanout
counts as "exporting" a BO from outside of it's host VM.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/713897/
Message-ID: <20260324220519.1221471-1-robin.clark@oss.qualcomm.com>
Rob Clark [Mon, 16 Mar 2026 18:44:42 +0000 (11:44 -0700)]
drm/msm/vma: Avoid lock in VM_BIND fence signaling path
Use msm_gem_unpin_active(), similar to what is used in the GEM_SUBMIT
path. This avoids needing to hold the obj lock, and the end result is
the same. (As with GEM_SUBMIT, we know the fence isn't signaled yet.)
Reported-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/712230/
Message-ID: <20260316184442.673558-1-robin.clark@oss.qualcomm.com>
Rob Clark [Mon, 16 Mar 2026 18:34:33 +0000 (11:34 -0700)]
drm/msm/adreno: Change chip_id format
The "ipv4-style" %u.%u.%u.%u used to make sense when the chip_id was
simply encoding gen.major.minor.patch. But this hasn't been true for
at least a couple years.
Switch to %08x, which is still easy enough to read for older devices,
and much easier to read with the new scheme.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/712222/
Message-ID: <20260316183436.671482-2-robin.clark@oss.qualcomm.com>
dt-bindings: display/msm/gpu: Drop redundant reg-names in one if:then:
Top-level reg-names defines already proper order for "reg-names" with
minItems: 1, so no need to repeat it again in one of "if:then:" cases.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: David Heidelberg <david@ixit.cz> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org>
Patchwork: https://patchwork.freedesktop.org/patch/707987/
Message-ID: <20260301142033.88851-2-krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Anna Maniscalco [Tue, 10 Feb 2026 16:29:42 +0000 (17:29 +0100)]
drm/msm: always recover the gpu
Previously, in case there was no more work to do, recover worker
wouldn't trigger recovery and would instead rely on the gpu going to
sleep and then resuming when more work is submitted.
Recover_worker will first increment the fence of the hung ring so, if
there's only one job submitted to a ring and that causes an hang, it
will early out.
There's no guarantee that the gpu will suspend and resume before more
work is submitted and if the gpu is in a hung state it will stay in that
state and probably trigger a timeout again.
Just stop checking and always recover the gpu.
Signed-off-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Cc: stable@vger.kernel.org
Patchwork: https://patchwork.freedesktop.org/patch/704066/
Message-ID: <20260210-recovery_suspend_fix-v1-1-00ed9013da04@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Signed-off-by: Richard Acayan <mailingradian@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/703803/
Message-ID: <20260210014603.1372-2-mailingradian@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Forbid recover/fault worker to enter memory reclaim (under
gpu->lock) to address this deadlock scenario.
Cc: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Reviewed-by: Rob Clark <rob.clark@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/700978/
Message-ID: <20260127073341.2862078-1-senozhatsky@chromium.org> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
drm/msm/dsi: Add support for RGB101010 pixel format
Add video and command mode destination format mappings for RGB101010,
and extend the VID_CFG0 DST_FORMAT bitfield to 3 bits to accommodate
the new format value.
Make sure this is guarded behind MSM_DSI_6G_VER >= V2.1.0 as anything
older does not support this.
Required for 10 bit panels such as the BOE BF068MWM-TD0 found on the
Nothing Phone (3a).
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/713721/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-5-ff6afc904115@pm.me Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
drm/msm/dsi: rename MSM8998 DSI version from V2_2_0 to V2_0_0
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>
Add MIPI_DSI_FMT_RGB101010 for 30 bit (10,10,10 RGB) pixel format,
corresponding to the packed 30 bit pixel stream defined in MIPI DSI
v1.3 Section 8.8.17.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Patchwork: https://patchwork.freedesktop.org/patch/713714/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-1-ff6afc904115@pm.me
[Acked by Maxime to be merged through msm-next on IRC on dri-devel]
[DB: moved RGB101010 to the end of enum mipi_dsi_pixel_format] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Jun Nie [Thu, 12 Mar 2026 08:28:12 +0000 (16:28 +0800)]
drm/msm/dpu: support plane splitting in quad-pipe case
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>
Jun Nie [Thu, 12 Mar 2026 08:28:11 +0000 (16:28 +0800)]
drm/msm/dpu: Defer SSPP allocation until CRTC check
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.
Jun Nie [Thu, 12 Mar 2026 08:28:10 +0000 (16:28 +0800)]
drm/msm/dpu: Extract plane splitting into a dedicated function
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.
Dmitry Baryshkov [Fri, 27 Feb 2026 18:36:46 +0000 (20:36 +0200)]
drm/msm/dpu: drop VBIF index from the struct dpu_hw_vbif
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.
Dmitry Baryshkov [Fri, 27 Feb 2026 18:36:45 +0000 (20:36 +0200)]
drm/msm/dpu: drop VBIF index from the VBIF params
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.
Dmitry Baryshkov [Fri, 27 Feb 2026 18:36:44 +0000 (20:36 +0200)]
drm/msm/dpu: drop vbif_idx from WB configuration
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.
Dmitry Baryshkov [Fri, 27 Feb 2026 18:36:42 +0000 (20:36 +0200)]
drm/msm/dpu: replace VBIF-related array with bare pointers
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.
Dmitry Baryshkov [Fri, 27 Feb 2026 18:36:40 +0000 (20:36 +0200)]
drm/msm/dpu: drop VBIF_NRT handling
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
Pengyu Luo [Sat, 7 Mar 2026 11:12:49 +0000 (19:12 +0800)]
drm/msm/dsi: fix hdisplay calculation for CMD mode panel
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.
Pengyu Luo [Sat, 7 Mar 2026 11:12:48 +0000 (19:12 +0800)]
drm/msm/dsi: fix bits_per_pclk
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.
drm/msm/dpu: fix vblank IRQ registration before atomic_mode_set
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:
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.
drm/msm/hdmi: Avoid double error print on msm_hdmi_get_phy() failure
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.
drm/msm/hdmi: Fix wrong CTRL1 register used in writing info frames
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>
Konrad Dybcio [Tue, 10 Mar 2026 13:20:25 +0000 (14:20 +0100)]
drm/msm/mdss: Add a TODO for better managing the MDSS clock power state
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.
Yuanjie Yang [Mon, 9 Mar 2026 06:37:20 +0000 (14:37 +0800)]
drm/msm/dpu: fix mismatch between power and frequency
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>
dt-bindings: display/msm: qcom,eliza-mdss: Add Eliza SoC
Add MDSS/MDP display subsystem for Qualcomm Eliza SoC, being overall a
minor revision change against SM8750, but coming with few different
components, like different DSI PHY, missing DP1 and added HDMI.
The binding does not include HDMI description yet.
dt-bindings: display/msm: dsi-phy-7nm: Add Eliza SoC
Add DSI PHY 4nm v5.2.4 for the Qualcomm Eliza SoC, fully compatible with
SM8650. Note that this DSI PHY, unlike the Eliza MDSS DSI, is not
compatible with SM8750.
dt-bindings: display/msm: dp-controller: Add Eliza SoC
Add DisplayPort controller for Qualcomm Eliza SoC fully compatible with
SM8650. The device looks very similar to SM8750 (same DP TX block
v1.5.1) but with a differences in DP PHY: Eliza and SM8650 use DP PHY
4nm v7.0, SM8750 uses 3nm v8.0.
Konrad Dybcio [Mon, 2 Mar 2026 13:41:26 +0000 (14:41 +0100)]
drm/msm/mdp5: Remove MSM8974v1
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.
Dmitry Baryshkov [Sat, 28 Feb 2026 17:20:37 +0000 (19:20 +0200)]
drm/msm: add missing MODULE_DEVICE_ID definitions
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.
Dmitry Baryshkov [Thu, 26 Feb 2026 13:49:02 +0000 (15:49 +0200)]
drm/msm/dpu: enable virtual planes by default
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>
Pengyu Luo [Thu, 26 Feb 2026 12:29:58 +0000 (20:29 +0800)]
drm/msm/dsi/phy: rename DSI_PHY_7NM_QUIRK_PRE_V4_1 to DSI_PHY_7NM_QUIRK_V4_0
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)
Dmitry Baryshkov [Mon, 12 Jan 2026 03:23:31 +0000 (05:23 +0200)]
drm/msm/dpu: use full scale alpha in _dpu_crtc_setup_blend_cfg()
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.
Dmitry Baryshkov [Mon, 12 Jan 2026 03:23:30 +0000 (05:23 +0200)]
drm/msm/dpu: simplify bg_alpha selection
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.
Vignesh Raman [Tue, 10 Feb 2026 07:11:32 +0000 (12:41 +0530)]
drm/ci: uprev mesa
Uprev mesa to adapt to the latest changes in Mesa CI, such as:
- LAVA overlay-based firmware handling
- Container/job rule separation
- Removal of the python-artifacts job
- Use lava-job-submitter container to submit jobs
- Use of the Alpine container for LAVA jobs
- Various other CI improvements
- Remove bare-metal jobs and disable apq8016 and apq8096 jobs,
as these have been migrated to the Collabora LAVA farm
- Fix issues with rebase with external fixes branch
- Update expectation files
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Co-developed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Vignesh Raman [Tue, 10 Feb 2026 07:11:31 +0000 (12:41 +0530)]
drm/ci: i915: cml: update runner tag
asus-C436FA-Flip-hatch has fewer devices available in the LAVA lab and
drm-ci uses only 2 DUTs, causing tests to time out. Update drm-ci to
use puff instead of hatch so the tests can run on 5 DUTs.
Also increase parallel count for amly jobs to 3.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Vignesh Raman [Tue, 10 Feb 2026 07:11:30 +0000 (12:41 +0530)]
drm/ci: reduce sm8350-hdk parallel jobs from 4 to 2
The sm8350-hdk jobs are short and each test takes around 2–3 minutes and
the full job completes in about 10 minutes. Running 4 parallel jobs uses
4 devices at once, which is not needed. Set parallel to 2 to reduce
device usage.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Pengyu Luo [Fri, 6 Mar 2026 16:32:38 +0000 (00:32 +0800)]
drm/msm/dsi: fix pclk rate calculation for bonded dsi
Recently, we round up new_hdisplay once at most, for bonded dsi, we
may need twice, since they are independent links, we should round up
each half separately. This also aligns with the hdisplay we program
later in dsi_timing_setup()
Pengyu Luo [Thu, 26 Feb 2026 12:29:57 +0000 (20:29 +0800)]
drm/msm/dsi/phy: fix hardware revision
The hardware revision for TSMC 3nm-based Qualcomm SOCs should be 7.2,
this can be confirmed from REG_DSI_7nm_PHY_CMN_REVISION_ID0, the value
is 0x27, which means hardware revision is 7.2
No functional change.
Fixes: 1337d7ebfb6d ("drm/msm/dsi/phy: Add support for SM8750") 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/707414/ Link: https://lore.kernel.org/r/20260226122958.22555-2-mitltlatltl@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Abel Vesa [Tue, 3 Mar 2026 09:03:11 +0000 (11:03 +0200)]
dt-bindings: display: msm: Fix reg ranges and clocks on Glymur
The Glymur platform has four DisplayPort controllers. The hardware
supports four streams (MST) per controller. However, on Glymur the first
three controllers only have two streams wired to the display subsystem,
while the fourth controller operates in single-stream mode.
Add a dedicated clause for the Glymur compatible to require the register
ranges for all four stream blocks, while allowing either one pixel clock
(for the single-stream controller) or two pixel clocks (for the remaining
controllers).
Update the Glymur MDSS schema example by adding the missing p2, p3,
mst2link and mst3link register blocks. Without these, the bindings
validation fails. Also replace the made-up register addresses with the
actual addresses from the first controller to match the SoC devicetree
description.
Cc: stable@vger.kernel.org # v6.19 Fixes: 8f63bf908213 ("dt-bindings: display: msm: Document the Glymur DiplayPort controller") Fixes: 1aee577bbc60 ("dt-bindings: display: msm: Document the Glymur Mobile Display SubSystem") Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/708518/ Link: https://lore.kernel.org/r/20260303-glymur-fix-dp-bindings-reg-clocks-v4-1-1ebd9c7c2cee@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Akhil P Oommen [Thu, 5 Mar 2026 18:21:16 +0000 (23:51 +0530)]
drm/msm/a8xx: Fix ubwc config related to swizzling
To disable l2/l3 swizzling in A8x, set the respective bits in both
GRAS_NC_MODE_CNTL and RB_CCU_NC_MODE_CNTL registers. This is required
for Glymur where it is recommended to keep l2/l3 swizzling disabled.
Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Message-ID: <20260305-a8xx-ubwc-fix-v1-1-d99b6da4c5a9@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Akhil P Oommen [Wed, 25 Feb 2026 07:41:57 +0000 (13:11 +0530)]
drm/msm/a6xx: Fix the bogus protect error on X2-85
Update the X2-85 gpu's register protect count configuration with the
correct count_max value to avoid blocking the entire MMIO region from the
UMD.
Protect configurations are a bit complicated on A8xx. There are 2 set of
protect registers with different counts: Global and Pipe-specific. The
last-span-unbound feature is available only on the Pipe-specific protect
registers. Due to this, we cannot use the BUILD_BUG sanity check for A8x
protect configurations, so remove the A840 entry from there.
Fixes: 01ff3bf27215 ("drm/msm/a8xx: Add support for Adreno X2-85 GPU") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/706944/
Message-ID: <20260225-glymur-protect-fix-v1-1-0deddedf9277@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Pengyu Luo [Sat, 14 Feb 2026 10:51:28 +0000 (18:51 +0800)]
drm/msm/dsi: fix hdisplay calculation when programming dsi registers
Recently, the hdisplay calculation is working for 3:1 compressed ratio
only. If we have a video panel with DSC BPP = 8, and BPC = 10, we still
use the default bits_per_pclk = 24, then we get the wrong hdisplay. We
can draw the conclusion by cross-comparing the calculation with the
calculation in dsi_adjust_pclk_for_compression().
Since CMD mode does not use this, we can remove
!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO) safely.
Thomas Weißschuh [Mon, 23 Feb 2026 07:16:55 +0000 (08:16 +0100)]
drm/msm/dpu: Don't use %pK through printk (again)
In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log.
Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
Furthermore, restricted pointers ("%pK") were never meant to be used
through printk(). They can still unintentionally leak raw pointers or
acquire sleeping locks in atomic contexts.
Switch to the regular pointer formatting which is safer and
easier to reason about.
This was previously fixed in this driver in commit 1ba9fbe40337
("drm/msm: Don't use %pK through printk") but an additional usage
was reintroduced in commit 39a750ff5fc9 ("drm/msm/dpu: Add DSPP GC
driver to provide GAMMA_LUT DRM property")
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Fixes: 39a750ff5fc9 ("drm/msm/dpu: Add DSPP GC driver to provide GAMMA_LUT DRM property") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/706229/ Link: https://lore.kernel.org/r/20260223-restricted-pointers-msm-v1-1-14c0b451e372@linutronix.de Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Dmitry Baryshkov [Fri, 13 Feb 2026 23:02:59 +0000 (01:02 +0200)]
Revert "drm/msm/dpu: try reserving the DSPP-less LM first"
This reverts commit 42f62cd79578 ("drm/msm/dpu: try reserving the
DSPP-less LM first"). It seems on later DPUs using higher LMs require
some additional setup or conflicts with the hardware defaults. Val (and
other developers) reported blue screen on Hamoa (X1E80100) laptops.
Revert the offending commit until we understand, what is the issue.
sunliming [Fri, 30 Jan 2026 05:36:15 +0000 (13:36 +0800)]
drm/msm/dpu: Fix smatch warnings about variable dereferenced before check
Fix below smatch warnings:
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp_v13.c:161 dpu_hw_sspp_setup_pe_config_v13()
warn: variable dereferenced before check 'ctx' (see line 159)
Kees Cook [Fri, 6 Feb 2026 22:21:52 +0000 (14:21 -0800)]
drm/msm: Adjust msm_iommu_pagetable_prealloc_allocate() allocation type
In preparation for making the kmalloc family of allocators type aware,
we need to make sure that the returned type from the allocation matches
the type of the variable being assigned. (Before, the allocator would
always return "void *", which can be implicitly cast to any pointer type.)
The assigned type is "void **" but the returned type will be "void ***".
These are the same allocation size (pointer size), but the types do not
match. Adjust the allocation type to match the assignment.
Dmitry Baryshkov [Wed, 21 Jan 2026 08:41:24 +0000 (10:41 +0200)]
drm/ci: ignore Gamma test failures on Qualcomm SC7180
It seems, on SC7180 color conversion results are not included into the
CRC calculation (unlike SM8350). The fails for SC7180 already lists CTM
tests. Add gamma-related tests too.
drm/msm/dpu: Add DSPP GC driver to provide GAMMA_LUT DRM property
Add support for DSPP GC block in DPU driver for Qualcomm SoCs.
Expose the GAMMA_LUT DRM property, which is needed to enable
night light and basic screen color calibration.
I used LineageOS downstream kernel as a reference and found the LUT
format by trial-and-error on OnePlus 6.
Tested on oneplus-enchilada (sdm845-mainline 6.16-dev) and xiaomi-tissot
(msm8953-mainline 6.12/main).
projects / thirdparty / kernel / linux.git / log
