summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-09-09drm/bridge: analogix_dp: Add validation for samsung,lane-count propertyDamon Ding
Add validity check for samsung,lane-count to ensure DT-provided lane count values are specification-compliant. Suggested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Link: https://patch.msgid.link/20260828065153.590802-5-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-09-09drm/bridge: analogix_dp: Restore mandatory samsung DP DT propertiesDamon Ding
Revert the change that made samsung,link-rate and samsung,lane-count optional for Exynos DP. Add error checking to fail probe early if the required DT properties are missing. If these properties are missing, video_info->max_link_rate and video_info->max_lane_count remain zero, and so do link_train.link_rate and link_train.lane_count used in the subsequent link training flow, resulting in link training failure. There is no way at all a device can work without these properties. Here is the code flow when either max_link_rate or max_lane_count is 0: analogix_dp_commit() -> analogix_dp_full_link_train(dp, max_lanes = 0, max_rate = 0) analogix_dp_full_link_train(max_lanes, max_rate): // Read sink capabilities via DPCD and sanitize them link_rate = read_dpcd(DP_MAX_LINK_RATE); // >= 0x06 after fixup lane_count = read_dpcd(DP_MAX_LANE_COUNT); // >= 1 after fixup // Clamp by the limits from DT if (link_rate > max_rate) // 0x06 > 0, always true link_rate = max_rate; // link_rate = 0 if (lane_count > max_lanes) // 1 > 0, always true lane_count = max_lanes; // lane_count = 0 // Configure TX with the zeroed values set_link_bandwidth(link_rate = 0) // writel() is only executed for bwtype == 0x06/0x0a, // so LINK_BW_SET is never written and stays at // reset value; phy_configure() gets link_rate = 0. set_lane_count(lane_count = 0) // writel(0, ANALOGIX_DP_LANE_COUNT_SET) enables 0 lanes; // phy_configure() is called with lanes = 0. // Program sink for link training drm_dp_dpcd_write(DP_LINK_BW_SET, {link_rate = 0/lane_count = 0}) // DP spec requires link rate in {0x06, 0x0a, 0x14} and // lane count in {1, 2, 4}. Writing zeros is illegal, so // the sink cannot enter the training state. // Training loop for (lane = 0; lane < lane_count /* 0 */; lane++) // loop body never executes; training_lane[] stays // uninitialized and no training register is programmed Since the sanitized sink values are always non-zero (link_rate >= 0x06, lane_count >= 1), the clamping with a zero maximum unconditionally forces the training parameters to zero. Clock recovery can never be achieved, so link training fails deterministically. Consequently, making these properties mandatory again cannot break any existing device: a DT without them could never have worked in the first place. Failing probe early with a clear error message is more helpful than a silent link training failure at runtime. Fixes: 0d0abd894ead ("drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288") Cc: stable@vger.kernel.org Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Link: https://patch.msgid.link/20260828065153.590802-4-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-09-09drm/gma500: Create the primary plane in the driverShixiong Ou
drm_crtc_init() creates the primary plane from a fixed format list that includes ARGB8888. The display engine programs the primary plane with DISPPLANE_32BPP_NO_ALPHA, so it does not support per-pixel alpha and must not advertise alpha formats. Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns about this at probe time. Replace drm_crtc_init() with a driver-owned primary plane that advertises only XRGB8888. The plane is allocated by drmm_universal_plane_alloc() and the "pixel blend mode" property is not needed because no format with alpha is exposed. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patch.msgid.link/20260903071149.423579-1-oushixiong1025@163.com
2026-09-09drm/xe: convert PCI barrier mmap to use xe_mmio_gemMatthew Auld
Convert the PCI barrier mmap over to use xe_mmio_gem, which is a good match for this functionality. This has the following advantages: 1. Removes a bunch of code. 2. Replaces the fragile hard coded fake offset design. 3. Adds the first user for xe_mmio_gem, which is preferred over nuking it. There are also potentially other upcoming usecases wanting this type of functionality, so having standard component to do this would be good. There shouldn't be any big functional change here. From userspace pov, they still query the fake offset like before, just that now it is no longer hard coded in the KMD. v2 (Thomas): - Prefer scoped_guard(). Also, just annotate ALL locations, even if not strictly needed. Reflect that in the kernel-doc. This will also shut up static analysis tools. Assisted-by: LLM Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260908165046.1393557-18-matthew.auld@intel.com
2026-09-09drm/xe/mmio_gem: reject VM_EXEC and drop VM_DONTCOPYMatthew Auld
Hardware MMIO registers should never be executable; reject VM_EXEC at mmap time and clear VM_MAYEXEC to prevent later mprotect attempts. Also drop VM_DONTCOPY so that child processes across fork() can inherit the mapping and lazily fault in the PFNs, matching standard DRM GEM semantics and making the existing drm_gem_vm_open() callback functional. This aligns with existing PCI_BARRIER, which will use this in the next patch. We don't want any noticeable behaviour change there, since this will be user visible. This will also be the first user. Assisted-by: LLM Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260908165046.1393557-17-matthew.auld@intel.com
2026-09-09drm/xe/mmio_gem: fix destroy flowIlia Levi
xe_mmio_gem_destroy() currently frees the GEM object directly, bypassing reference counting. Since existing VMAs hold a reference and the fault handler accesses the object through vma->vm_private_data, this is use-after-free. Additionally, nothing prevents the fault handler from installing PTEs to the real MMIO after destroy. Fix this with proper synchronization and refcounting. Also, do not set vm_pgoff to zero. Many DRM drivers do this because helpers like dma_mmap_pages() interpret vm_pgoff as an intra-buffer page offset; leaving the DRM fake offset there would break these helpers. Those drivers can get away with zeroing it because they map eagerly - all PTEs are established before mmap returns, so vm_pgoff is never consulted again. Our driver does not use such helpers and the newly introduced call to drm_vma_node_unmap() relies on vm_pgoff being untouched. v2: (Matt Auld) - use dma_resv lock to serialize fault handler with destroy - SIGBUS on access after destroy Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-16-matthew.auld@intel.com
2026-09-09drm/xe/mmio_gem: cache the dummy page per objectIlia Levi
Currently, when the fault handler provides a dummy page, it allocates a new one on every invocation and ties its lifetime to the drm_device via drmm_add_action_or_reset(). Concurrent faults after hot-unplug therefore accumulate pages that persist until device teardown. Cache a single dummy page in the xe_mmio_gem object and use dma_resv lock to protect its allocation. Free it with the object. v2: use dma_resv lock to protect the allocation (Matt Auld) Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-15-matthew.auld@intel.com
2026-09-09drm/xe/mmio_gem: Revoke drm_vma_node on xe_mmio_gem destroyShuicheng Lin
xe_mmio_gem_create() calls drm_vma_node_allow() but nothing ever calls drm_vma_node_revoke(). The drm_vma_offset_file rb-tree entry allocated by drm_vma_node_allow() is not freed by drm_gem_object_release(), so it is leaked on every create/destroy cycle. Add a struct drm_file * parameter to xe_mmio_gem_destroy() and call drm_vma_node_revoke() from there, mirroring the drm_vma_node_allow() call in xe_mmio_gem_create(). Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Suggested-by: Ilia Levi <ilia.levi@intel.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Ilia Levi <ilia.levi@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-14-matthew.auld@intel.com
2026-09-09drm/xe/mmio_gem: simplify fault handler loopIlia Levi
Make the iteration over the addresses in the VMA more explicit. No functional change, as the VMA matches the GEM object exactly. Signed-off-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-13-matthew.auld@intel.com
2026-09-09drm/xe/mmio_gem: use write-back mapping for dummy pageIlia Levi
Currently vmf_insert_pfn() maps the dummy page as UC, inheriting the VMA's page protection which was set for the real MMIO region. This conflicts with the direct map's WB mapping of the same page, creating a cache type alias which is architecturally undefined on some platforms. Use vmf_insert_pfn_prot() with a WB pgprot instead. Also simplify to fault in the requested page instead of the whole VMA. Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260525125801.975038-6-ilia.levi%40intel.com Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-12-matthew.auld@intel.com
2026-09-09drm/xe/mmio_gem: forbid VMA splitIlia Levi
The fault handler assumes it always operates on a VMA spanning the entire GEM object. This does not hold when the VMA has been split, e.g. by a partial munmap or mprotect. In that case the handler may map wrong physical pages or cause SIGBUS. Handle this by forbidding VMA split, as partial unmaps are not deemed useful for MMIO GEMs. Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Ilia Levi <ilia.levi@intel.com> Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-11-matthew.auld@intel.com
2026-09-09drm/bridge: lontium: Drop redundant vendor prefix from I2C device nameKrzysztof Kozlowski
Device names for i2c_device_id are not OF compatibles and have a meaning only for in-tree users (which there are no except the driver itself), thus vendor prefix in this name is completely redundant. It is actually a discouraged pattern because for OF platforms it allows matching driver by I2C bus, instead of OF, thus hiding incomplete way of obtaining driver match data (lack of i2c_get_match_data() usage). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260825143921.512966-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-09-09drm/bridge: tc358768: Enforce input bus flags via atomic_checkLeonardo Costa
The tc358768 declares static bridge timings requiring pixel data to be sampled on the positive clock edge. However, the DRM core default propagation simply copies the output-side bus flags, coming from the next bridge, connector or panel, to the input side. If the propagated flags are incompatible with the bridge ones, the data is wrongly sampled, typically resulting in visual artifacts on the panel. Implement the atomic_check hook, replacing the mutually exclusive mode_fixup, and set the bridge state input bus flags to the ones required by the tc358768. The sync polarity defaulting previously done in mode_fixup is carried over into atomic_check unchanged. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Cc: stable@vger.kernel.org Signed-off-by: Leonardo Costa <leonardo.costa@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Swamil Jain <s-jain1@ti.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260706132440.1594239-1-leoreis.costa@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-09-08drm/drm_exec: fix up contended obj when num_objects is 0Sunil Khatri
drm_exec_prepare_array() silently returns success without calling drm_exec_lock_contended() when num_objects is zero. This breaks the invariant upheld by drm_exec_lock_obj(), where every entry point into the locking sequence must first attempt to lock any previously contended object before proceeding. Drivers that chain multiple drm_exec_prepare_array() calls per drm_exec_until_all_locked() iteration (e.g. amdgpu's userq signal/wait ioctls, which prepare separate read and write BO arrays) can pass an empty array for one of the two calls. If contention is hit while preparing the non-empty array, exec->contended is set and the loop retries; on retry, the empty-array call preceding it is a no-op that never clears exec->contended, so drm_exec_retry_on_contention() immediately jumps back to the top of the loop without ever reaching the call that would resolve the contention. This spins forever. Fix it by having drm_exec_prepare_array() call drm_exec_lock_contended() directly when num_objects is zero, so a pending contended object dont loop infinitely. Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") CC: stable@vger.kernel.org # v6.6+ Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Link: https://lore.kernel.org/r/20260908091729.2749399-1-sunil.khatri@amd.com Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2026-09-08drm/xe: Add multi_queue_active_lrca debugfsVarun Gupta
Add a per-GT debugfs file, multi_queue_active_lrca, that prints, for every engine supporting multi-queue, the currently active queue ID (CSMQDEBUG) and the LRCA of the exec queue occupying that slot within the running multi-queue group. RING_CURRENT_LRCA only reports the primary queue's LRCA for the group and does not update to reflect the active queue in multi-queue mode, which makes it hard to tell which queue is actually running when debugging multi-queue CSB/context-switch issues. Resolve the active LRCA by matching the primary LRCA against each queue's group and picking the queue at the reported active_id position. v4: - Extracted multi_queue_active_lrca into a dedicated multi_queue_debugfs_list to prevent debugfs node registration on platforms lacking multi-queue support entirely, via xe_gt_has_multi_queue() gating. (Tejas) v3: - Use xe_exec_queue_get_lrc() instead of raw pointer dereference to safely handle concurrent multi-queue group creation and avoid race conditions (Sashiko) v2: - Maintain alphabetical order for includes and pf_only_debugfs_list (Tejas) - Export and reuse xe_lrc_get_multi_queue_active_queue_id() instead of duplicate MMIO read (Tejas) Bspec: 60321, 73976 Signed-off-by: Varun Gupta <varun.gupta@intel.com> Link: https://patch.msgid.link/20260908033417.1019602-2-varun.gupta@intel.com Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2026-09-08drm/amd/display: Drop KUnit tests for removed parse_hdmi_amd_vsdb()Rodrigo Vivi
parse_hdmi_amd_vsdb() was removed when HDMI FreeSync detection moved to the common EDID parser, but its declaration and KUnit tests remained, breaking modpost: ERROR: modpost: "parse_hdmi_amd_vsdb" [...connector_test.ko] undefined! Remove the stale declaration and the three dead test cases. Fixes: f65198b3d073 ("drm/amd/display: Use HDMI FreeSync range from common EDID parser") Cc: Alex Huang <Alex.Huang2@amd.com> Cc: Mario Limonciello <superm1@kernel.org> Assisted-by: Copilot:Claude-Opus-5 Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260820142802.1342066-2-rodrigo.vivi@intel.com
2026-09-08drm/logicvc: Drop the select of the nonexistent CONFIG_DRM_KMS_DMA_HELPERKarl Mehltretter
CONFIG_DRM_KMS_CMA_HELPER was removed by commit 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option"). When commit 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") later renamed the select in this Kconfig to CONFIG_DRM_KMS_DMA_HELPER, no symbol of that name existed, and git log -S finds no Kconfig file that has defined one since. The select is silently ignored. The driver already selects CONFIG_DRM_GEM_DMA_HELPER, which is what it needs. Remove the dead line. Fixes: 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") Assisted-by: LLM Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260905080344.34077-1-kmehltretter@gmail.com
2026-09-08drm/adp: Drop the select of the nonexistent CONFIG_DRM_KMS_DMA_HELPERKarl Mehltretter
There is no Kconfig symbol CONFIG_DRM_KMS_DMA_HELPER. The former CONFIG_DRM_KMS_CMA_HELPER was removed by commit 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option") before this driver was added, so the select does nothing. The driver already selects CONFIG_DRM_GEM_DMA_HELPER, which is what it needs. Remove the dead line. Fixes: 332122eba628 ("drm: adp: Add Apple Display Pipe driver") Assisted-by: LLM Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260905080426.34224-1-kmehltretter@gmail.com
2026-09-08drm/vboxvideo: create blend mode property on planesQinyun Tan
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. Both the vboxvideo primary and cursor planes expose ARGB8888 and trip this on driver load. VirtualBox draws the cursor through the host windowing system, which treats the guest-supplied pointer shape as straight (non-pre-multiplied) alpha: the host frontend loads the pixels verbatim into an unpremultiplied ARGB image before handing them to the host cursor APIs. This corresponds to DRM_MODE_BLEND_COVERAGE. Expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_COVERAGE to make these semantics explicit and silence the warning. The primary plane's alpha channel is ignored by the host (opaque blit) and it is the bottom-most plane anyway; advertise the same value there for consistency. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260901083234.1828755-5-qinyuntan@linux.alibaba.com
2026-09-08drm/virtio: create blend mode property on cursor planeQinyun Tan
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. The virtio-gpu cursor plane (HOST_ARGB8888) trips this. The virtio-gpu specification does not define the cursor alpha semantics. The host forwards the cursor pixels verbatim to its display frontends, and the remote cursor protocols among them (SPICE alpha cursors, the VNC "Cursor With Alpha" encoding) both define pre-multiplied alpha, matching what userspace has always assumed when the property is not attached. Expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_PREMULTI to make these semantics explicit and silence the warning. The primary plane only exposes HOST_XRGB8888, so the call is gated to the cursor. No functional change. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260901083234.1828755-4-qinyuntan@linux.alibaba.com
2026-09-08drm/qxl: create blend mode property on primary and cursor planesQinyun Tan
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. Both the qxl primary and cursor planes expose ARGB8888 and trip this on driver load. qxl submits cursors as SPICE_CURSOR_TYPE_ALPHA, which the SPICE protocol explicitly defines as a "pre-multiplied ARGB8888 pixmap" (Spice Protocol, "Cursor channel definition" section [1]). This matches the blend mode userspace has always assumed when the property is not attached. Expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_PREMULTI to make these semantics explicit and silence the warning. The primary plane is the bottom-most plane so its blend mode has no visible effect; advertise the same value there for consistency. No functional change. [1] https://www.spice-space.org/spice-protocol.html Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260901083234.1828755-3-qinyuntan@linux.alibaba.com
2026-09-08drm/ast: create blend mode property on cursor planeQinyun Tan
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. The ast cursor plane (ARGB4444, ARGB8888) trips this on driver load: [PLANE:37:plane-1] pixel format with alpha exposed but blend mode not setup WARNING: drivers/gpu/drm/drm_mode_config.c:872 at drm_mode_config_validate+0x48f/0x510 [drm] ... Call Trace: drm_dev_register+0x1ce/0x290 [drm] ast_pci_probe+0x19d/0x3f0 [ast] local_pci_probe+0x41/0x90 Per Thomas Zimmermann's review, the ASPEED documentation describes the hardware cursor as blending with straight (non-pre-multiplied) alpha, which corresponds to DRM_MODE_BLEND_COVERAGE. Expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_COVERAGE to make the hardware semantics explicit and silence the warning. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260901083234.1828755-2-qinyuntan@linux.alibaba.com
2026-09-08drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batchesThomas Hellström
emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to flush the L2/HDC data cache before fence signalling, but it never requests a flush of the LSC untyped L1 data cache via the 'Untyped Data-Port Cache Flush Enable' bit in PIPE_CONTROL DWord0[11]. Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented to also flush/invalidate the untyped L1 cache, but only depending on how HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling between HDC Pipeline Flush and the untyped L1 cache flush no longer holds in practice, regardless of how HDC_CHICKEN0 is programmed, so relying on it is not safe on newer platforms such as BMG. Mesa's Vulkan driver (anv) has been assuming the kernel flushes both caches between submissions, and hit user-visible corruption in apps such as Llama.cpp because of this gap; it now works around it by flushing both caches again from userspace at the end of every command buffer. Correctness between submissions on the same queue is userspace's responsibility and belongs in Mesa, not the kernel. However, for security we must ensure stale data can't leak through the untyped L1 dataport cache once memory is reclaimed or evicted, which requires the KMD to flush it before releasing memory for reuse. Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for DG2 via Wa_22010960976/Wa_14013347512) to reliably keep HDC Pipeline Flush coupled to the untyped L1 cache flush, so those platforms are unaffected. Mesa's own anv driver found that on MTL the HW disconnected the two independently of how HDC_CHICKEN0 is programmed, and could not bring the old behavior back even by writing the register by hand; see Mesa commit 7c2ff46a4fc3 ("anv: don't prevent L1 untyped cache flush in 3D mode"). The kernel can't reliably request the flush from the CS on MTL either, so restrict the new PIPE_CONTROL bit to GRAPHICS_VERx100 >= 2000 (Xe2 and later), where it can be relied on. Explicitly set PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together with PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush() on Xe2 and later, so the L1 data cache is known clean before memory is released for reuse, without depending on undocumented platform-specific HDC_CHICKEN0 behavior. Bspec: 56551 Link: https://gitlab.freedesktop.org/mesa/mesa/-/commit/7c2ff46a4fc3e537573ac9503057e0cd29b6fff3 Fixes: 9f8f93bee3ef ("drm/xe: Emit a render cache flush after each rcs/ccs batch") Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/8909 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: intel-xe@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.8+ Assisted-by: GitHub_Copilot:claude-sonnet-5 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260903114552.48634-1-thomas.hellstrom@linux.intel.com
2026-09-08drm/sched: Create a fake device for KUnit testsShixiong Ou
The DRM scheduler KUnit tests pass NULL for the dev field in drm_sched_init_args, which NULL-pointer dereferences in the drm_sched_job trace event via dev_name() on sched->dev. Give the mock scheduler a device with kunit_device_register(), which is also cleaned up at test exit. A per-function counter keeps the device names unique, since some tests create several mock schedulers. Fixes: 5a99350794fe ("drm/sched: Add scheduler unit testing infrastructure and some basic tests") Cc: stable@vger.kernel.org Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Acked-by: Maxime Ripard <mripard@kernel.org> [phasta: removed static variable init to 0 again] Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260908055941.351486-1-oushixiong1025@163.com
2026-09-08Merge drm/drm-fixes into drm-misc-fixesThomas Zimmermann
Backmerging to get drm-misc-fixes up to v7.3-rc2. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2026-09-08Merge tag 'drm-intel-next-2026-09-03' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Xe related: - Some clean-ups around drm/xe/display (Jani) Display in general: - Regular clean-ups (Jani) - Enable CMRR (Content Match Refresh Rate) in fixed-RR VRR path (Mitul) - Switch DG2 Multi-protocol PLL (MPLLB) to the DPLL framework (Mika) - DP-HDMI PCON DSC fixes (Ankit) - Remove duplicated call introduced by a bad cherry-pick (Chaitanya) - Limit invalid joiner combinations harder (Jani) - Fix value being written to DDI_CLK_VALFREQ (Suraj) - Harden some bit-shifting operations (Luca) - Clear SEL_FETCH_PLANE_CTL on plane disable (Nemesa) - Update CURSOR_BUF/WM masks (Suraj) - CDCLK related fixes and refactor specially around PCODE interaction (Ville) - Reduce clock_gating interface between core and display (Luca) - Gate UHBR SST SDP splitting on sink capability (Mitul) - Enable joiner cursor fast updates (Nemesa) - Cear the Panel Replay error status register (Jake) - Add HDMI TMDS audio bandwidth check (Chaitanya) - Reset use_flipq when duplicating crtc state (Mika) Beyond display: - Guard against NULL driver_data (Deepanshu) - Rename GEN6_PCODE_DATA to match spec (Michal) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/apmWNIUJ5lmsvNzc@intel.com
2026-09-08Merge tag 'drm-misc-next-2026-09-03' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v7.4: UAPI Changes: colorop: - provide DRM_COLOR_OP_FIXED_MATRIX Cross-subsystem Changes: cgroups: - fix typos dma-buf: - fix typos sound: - adapt to changes in omapdrm Core Changes: atomic: - convert most of DRM from state reset callbacks to atomic_create_state - remove drm_simple_encoder_init(); update drivers buddy: - improve dirty-page tracking clients: - log: Improve vmap handling display: - export HDMI SCDC status data via debugfs edid: - parse AMD VSDB entries - parse ALLM/VRR capabilities log: - add drm_warn_ratelimited() sched: - add missing locking Driver Changes: amd: - display: Use AMD VSDB for FreeSync - display: Implement YUV-to-RGB with fixed-matrix colorop amdxdma: - various fixes ast: - support 256-byte EDID data bridge: - clean up redundant error reporting - ti-sn65dsi83: Simplify error condition logic hyperv_drm: - remove support for pre-Win10 hosts komeda: - fix usage of GLB_CORE_ID nouveau: - improve runtime PM on R570 GSP firmware - various fixes throughout the driver - dispnv50: Support 2.147 GHz pixel clock in GB20x omap: - report HDMI hotplug events to ASoC HDMI codec panel: - panel-edp: Support MNE007QS3-F, TM140VDXP15, and KD116N36-30NB-A001 - samsung-s6d16d0: Use mipi_dsi_*_multi() functions - support Ilitek ILI7836A OLED plus DT bindings - support Novatek NT36532 plus DT bindings - convert several drivers to managed cleanup - fix Kconfig selections panthor: - provide gpu_cache_flush tracepoint - improve dma_fence signalling latency - improve locking qaic: - reject BOs that exceed maximum page count - add missing include statements verisilicon: - fix hardware cursor offsets vkms: - implement YUV-to-RGB with fixed-matrix colorop Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260903130548.GA91506@2a02-2455-9062-2500-3419-2212-e55c-8a45.dyn6.pyur.net
2026-09-08drm/xe/gt: Report GT reset failure using SIGIDArvind Yadav
Route the GT reset failure log through the structured SIGID logging helper. Failure to complete the full graphics reset means GT reset did not finish as expected. Use the GT component, which maps to XE_SIGID_GT_TDR, and pass the reset errno value to the helper. Also update the message to describe the actual failure. The driver does not clear GRDOM_FULL directly. The reset should complete and clear it within the timeout. Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Suggested-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20260903054610.3640788-5-arvind.yadav@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2026-09-08drm/xe/svm: Report terminal page-fault failures using SIGIDArvind Yadav
Use structured SIGID logging for SVM page-fault errors after retries are exhausted. Report these failures with the PAGEFAULT component, which maps to XE_SIGID_MEM_FAULT. Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Suggested-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20260903054610.3640788-4-arvind.yadav@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2026-09-08drm/xe/guc: Report reset failure using SIGIDArvind Yadav
Route the GuC submission engine reset failure through the structured SIGID logging helper. Use the GUCSUBMIT component, which maps to XE_SIGID_GT_TDR, and pass -EIO as the errno value. Cc: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20260903054610.3640788-3-arvind.yadav@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2026-09-08drm/xe/log: Add GUCSUBMIT componentArvind Yadav
The proper SIGID for GuC submission failures is GT_TDR, but using the generic GT component may hide the real source of the report. Add GUCSUBMIT as a DRIVER component and map it to XE_SIGID_GT_TDR. Cc: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20260903054610.3640788-2-arvind.yadav@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2026-09-07drm/gpusvm: keep an IOVA mapped range dma address inlineHonglei Huang
dma_iova_try_alloc() reserves one contiguous IOVA for the whole range and links each page at the next offset, so the device addresses run contiguously from entry 0 and one entry describes them all. A 2 MiB range of 4 KiB pages then drops the same 8 KiB array as a THP backed one. Fold only when state_offset covers the full range, which proves no device page was mapped in between, and only single page entries, so the order kept is 0 and stays true. Widening it instead would tell a consumer to use a huge page for npages separate CPU pages, which hangs Vega20 on amdgpu. The kept entry no longer bounds the segment, so skip the unmap walk when it has nothing to do, keyed off dpagemap rather than the flags, which are not published yet on the error unwind. Consumers need the same distinction, so drm_gpusvm_pages_first_dma() returns it alongside the array from one read of the flags; xe passes it to xe_res_first_dma(). Suggested-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260905133142.3628027-7-honghuan@amd.com
2026-09-07drm/gpusvm: keep a single DMA mapping inline for THPHonglei Huang
drm_gpusvm_get_pages() sizes the dma_addr array for one drm_pagemap_addr per page, but the mapping loop advances by page order, so a range backed by one huge page needs a single entry. For a 2 MiB THP that is an 8 KiB array holding 16 bytes of address. Union that entry with the array pointer, discriminated by a new inline_dma_mapping flag. When drm_gpusvm_dma_map_pages() ends up with one entry it stores it inline and frees the array, after the last error unwind, which still walks the array form. An unchecked dma_addr read is now type confusion rather than a compile error, so reads go through the new drm_gpusvm_pages_first_dma() accessor, including the two xe_pt_stage_bind() paths. Only get_pages() and the free path write the union, never the notifier, and both run under the driver lock that every address reader already holds. The unlocked short circuit in drm_gpusvm_pages_valid_unlocked() goes for the same reason: it cannot resolve the union, and every instance it rejects has to be reset before the allocation loop reuses it. Suggested-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260905133142.3628027-6-honghuan@amd.com
2026-09-07drm/gpusvm: make the DMA mapping step in get_pages() optionalHonglei Huang
Some drivers (e.g. AMDXDNA) only need the CPU pages faulted in and tracked by the notifier, no need DMA mapping. Add a drm_gpusvm_ctx::no_dma_map flag. When set, get_pages() does the shared HMM fault and records notifier_seq, but skips svm_pages->drm validation, the dma_addr allocation and drm_gpusvm_dma_map_pages(). With no mapping state to check, the fault is redone on every call. The default (no_dma_map == 0) is unchanged. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260905133142.3628027-5-honghuan@amd.com
2026-09-07drm/gpusvm: let drm_gpusvm_get_pages() map an array of pagesHonglei Huang
With the N:1 drm_gpusvm_pages layout, one CPU range mirrored on several drm_devices, the caller had to invoke get_pages() once per device and repeat the HMM fault every time. Make get_pages() take a contiguous array of drm_gpusvm_pages plus a count: fault once, then DMA map each instance by drm_gpusvm_dma_map_pages() under a single read_retry gate. xe range and userptr callers are updated. Document the N:1 array usage in the Overview, showing how get_pages() and drm_gpusvm_range_set_unmapped() take the whole array and its count while the unmap and free paths stay per-instance. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260905133142.3628027-4-honghuan@amd.com
2026-09-07drm/gpusvm: extract drm_gpusvm_dma_map_pages() helperHonglei Huang
Move the per-device DMA mapping loop of drm_gpusvm_get_pages() into a helper drm_gpusvm_dma_map_pages(). The mapping logic is only moved, not changed, so there is no functional change. The helper maps the already-faulted pfns into one drm_gpusvm_pages instance under the notifier lock and unwinds its own partial mapping on error. The HMM fault and the notifier retry loop stay in get_pages() common code rather than being pushed down to drivers, so no driver has to reimplement the subtle fault and retry logic. With the mapping isolated per instance, get_pages() can later fault once and DMA map an array of drm_gpusvm_pages plus a count, one per owning drm_device. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260905133142.3628027-3-honghuan@amd.com
2026-09-07drm/gpusvm: move dma_addr allocation before the notifier lockHonglei Huang
The dma_addr allocation was in a lazy allocation flow, it needs unlock and goto map_pages. The allocation only needs npages, so just do it before taking the lock. Drop the map_pages label and the relock flow, so the sequence becomes fault, allocate, then lock, validate, map and unlock. No functional change intended. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260905133142.3628027-2-honghuan@amd.com
2026-09-08drm/i915/bios: remove VS/PE-O warningMichał Grzelak
There is not much use of warning when port asks to override default VS/PE since it is already logged. Remove drm_WARN() and child_device from print_ddi_port() since drm_WARN() was the only user of it. Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-9-michal.grzelak@intel.com
2026-09-08drm/i915: override Combo's VS/PE when requestedMichał Grzelak
Add accessor function for Combo to read requested table from VBT #57. Parse the requested table and transform data into port's buffer. Actual data is fully stored in the lowest byte although each entry is 4 bytes wide. Thus convert u32 into u8 and store the data. For EHL, in cases when eDP encoder uses low vswing, choose 3rd table if encoder supports HBR3. Otherwise use 2nd table for eDP using low vswing. In cases when eDP encoder does not use low vswing, choose 2nd table if encoder supports mode higher or including HBR2. Otherwise use 1st table for eDP not using low vswing. For external DP follow same path and use same indices as in eDP without low vswing case. For JSL, always use 1st table for external DP. For eDPs not using low vswing use 1st table as well. In cases when eDP encoder uses low vswing, choose 1st table if encoder supports HBR3. When encoder supports HBR2 choose 3rd table. When encoder supports modes lower than HBR2 choose 2nd table. There are no changes to intel_ddi_dp_level() since selection of correct row of intel_ddi_buf_trans_entry is same as when no override request has been done. Looking from other OSes, in case when encoder does not support DP we could theoretically use 1st table. However, as of now, use default tables. v11->v12 - don't set vspeo->num_entries per PHY/platform - check for low vswing eDP for EHL (Sashiko) - reverse order of indices for JSL (Sashiko) v10->v11 - initialize local variables at declaration block (Jani) - branch with 'else` instead of initializing twice (Jani) v9->v10 - call dedicated VS/PE-O vfunc - drop deconstifying default tables (Suraj, Jani) - cache `entries` into const field after data is overwritten (Jani) v8->v9 - deconstify intel_ddi_buf_trans_entry v6->v7 - handle VS/PE-O's VBT details in intel_bios_* functions (Jani) - remove vspeo's cast to (void *) (Jani) - call encoder->get_buf_trans() once (Jani) - return NULL from intel_bios_get_* when using default (Jani) - validate VS/PE-O in intel_bios.c (Jani) - check devdata->vspeo if VS/PE-O was requested - inline {jsl,ehl}_combo_get_vspeo_buf_trans() - remove temporarily LT v4->v5 - blend index computation with table parsing - remove enums entirely - add spaces around operators (Suraj) - remove spaces after type casting (Suraj) - remove INTEL_DISPLAY_STATE_WARN (Suraj) Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260907122742.2512901-1-michal.grzelak@intel.com
2026-09-08drm/i915: override Snps's VS/PE when requestedMichał Grzelak
Add accessor functions for Snps to read requested table from VBT #57. Parse the requested table and transform data into port's buffer. Actual data is fully stored in the lowest byte although each entry is 4 bytes wide. Thus convert u32 into u8 and store the data. For C20, use 6th table if encoder supports DP 2.0 or higher. Otherwise use 5th table for DP. For C20, tables 1-4 are not used at all and are most likely to be zeroed. 5th table is used for any mode below DP 2.0 (exclusive). 6th table is used for any mode above DP 2.0 (inclusive). For C10, use 2nd table for external DP if encoder supports any mode beyond or including HBR2. Use 1st table if external DP encoder supports anything lower than HBR2. For eDP, use 4th table if encoder supports HBR3. Otherwise use 3rd table for eDP. For C10, 1st table is used for external DP with modes below HBR2 (exclusive). 2nd table is used for external DP with modes higher than HBR2 (inclusive). 3rd table is used for eDP with modes lower than HBR3 (exclusive). 4th table is used for eDP with modes higher than HBR3 (inclusive). Indices for other tables have not yet been observed to be used as of now. There are no changes to intel_ddi_dp_level() since selection of correct row of intel_ddi_buf_trans_entry is same as when no override request has been done. v11->v12 - don't set vspeo->num_entries per PHY - don't refer to 1st table as fallback for non-DP for C10 (Sashiko) v10->v11 - remove no-longer-relevant check for NULL devdata (Jani) - initialize local variables at declaration block (Jani) - branch with 'else` instead of initializing twice (Jani) - use blank line before 'return` (Jani) v9->v10 - call dedicated VS/PE-O vfunc - drop deconstifying default tables (Suraj, Jani) - cache `entries` into const field after data is overwritten (Jani) v8->v9 - init vspeo before using it - deconstify intel_ddi_buf_trans_entry v7->v8 - remove comments (Suraj) - add check for LT (Suraj) v6->v7 - handle VS/PE-O's VBT details in intel_bios_* functions (Jani) - remove vspeo's cast to (void *) (Jani) - check devdata->vspeo if VS/PE-O was requested - call encoder->get_buf_trans() once (Jani) - return NULL from intel_bios_get_* when using default (Jani) - validate VS/PE-O in intel_bios.c (Jani) - inline mtl_{c10,c20}_get_vspeo_buf_trans() - remove temporarily LT v4->v5 - blend index computation with table parsing - remove enums entirely - change funcs prefix from snps_ to mtl_ (Suraj) - add spaces around operators (Suraj) - remove spaces after type casting (Suraj) - remove INTEL_DISPLAY_STATE_WARN (Suraj) v3->v4 - stick to solely changing VBT data into current structures (Jani) - move iterator declaration to declaration block (Suraj) v2->v3 - remove unnecessary braces from if block (Suraj) - return -EINVAL instead of -1 (Suraj) Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-7-michal.grzelak@intel.com
2026-09-08drm/i915/buf_trans: add vfunc for VS/PE-OMichał Grzelak
Choosing correct table for Vswing / Pre-emphasis Override is platform specific. It also requires different checks that are already used for choosing predefined tables. Add new get_buf_trans_override() vfunc into intel_encoder returning deparsed table from VBT#57. In next patches, set it inside already present if-ladder from intel_ddi_buf_trans_init() instead of duplicating it. Note that get_buf_trans() cannot be overwritten since there are cases when we need to rollback although VS/PE-O was requested, eg. DP is not connected or feature is not yet implemented for the platform. Assume that vfunc returns NULL on rollback and return predefined tables. Suggested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-6-michal.grzelak@intel.com
2026-09-08drm/i915/bios: de/allocate VS/PE-O buffers for each portMichał Grzelak
Every devdata needs VS/PE-O dedicated buffers since each port can request an override. Add intel_ddi_buf_trans{,_entry} pointers into intel_bios_encoder_data. Allocate struct intel_ddi_buf_trans{,_entry} for the port if VS/PE-O was requested and is supported. Keep NULL in vspeo if any allocation failed or VS/PE-O was not requested. It will be used later for checking if override should actually take place. Note that we theoretically could store intel_ddi_buf_trans_entry inside `entries` field of newly allocated intel_ddi_buf_trans. However it will be impossible to overwrite the buffer during intel_ddi_get_buf_trans() without discarding const qualifier of `entries` field. This would involve either void casting or deconstifying entries field and in turn all predefined tables as well. Thus add a separate non-const qualified field into intel_bios_encoder_data for the buffer, which after overwriting will be promoted to be const qualified. Deallocate the buffer as well as entries if requested. v11->v12 - set vspeo->num_entries once (Sashiko) - free allocated vspeo->entries (Sashiko) v9->v10 - add separate non-const field for `entries` caching - cache `entries` into const field after data is overwritten (Jani) v4->v5 - set devdata->vspeo->num_entries in intel_bios.c Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-5-michal.grzelak@intel.com
2026-09-08drm/i915/bios: print VS/PE-O port infoMichał Grzelak
Issue a debug message when port asks to override default Vswing / Preemphasis tables. Add helper intel_bios_encoder_requests_vspeo() to check if port requests for overriding default VS/PE tables. v6->v7 - expand VS/PE-O acronym in debug logging (Jani) v3->v4 - change debug message when requesting VS/PE-O (Suraj) Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-4-michal.grzelak@intel.com
2026-09-08drm/i915/bios: store VBT #57's metadata in intel_vbt_dataMichał Grzelak
Store tables, number of tables, number of rows and number of columns in intel_vbt_data when search for the VBT #57 has succeeded. Structurize all VS/PE-O relevant metadata inside anonymous struct named as vspeo. Presence of C20 or newer PHY causes each table to contain 16 rows. Each table contains 10 rows in case C20 PHY is absent. Use display version to determine number of rows since there is no helper in intel_bios.c to check presence of any C20+ PHY. pre-MTL platforms should have 10 rows while MTL+ should have 16 rows. v5->v6 - add Bspec (Suraj) v3->v4 - remove unnecessary init of VS/PE-O metadata (Suraj) - add helper for computing number of rows (Suraj) - fix num_rows's type (Jani, Suraj) - declare num_rows (Suraj) Bspec: 68963 Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-3-michal.grzelak@intel.com
2026-09-08drm/i915/bios: search for VBT #57 by defaultMichał Grzelak
Start searching for Vswing / Preemphasis Override Block during VBT parsing at init_bdb_blocks(). Check for failure since pre-ICL GOPs do not contain the block. Check also if VBT version is appropriately up-to-date. v6->v7 - parse VBT#57 before blocks dependent on child device list (Jani) - remove debug message (Suraj) v3->v4 - add Bspec (Suraj) Bspec: 32063 Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-2-michal.grzelak@intel.com
2026-09-08Merge tag 'drm-xe-next-2026-08-31-1' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Cross-subsystem Changes: - MAINTAINERS: Add entries for drm_ras (Rodrigo) - alerts and controller enabling modifications (Heikki) Core Changes: - Introduce cold reset recovery method (Mallesh) - Add drm_ras netlink error event support (Riana) - Introduce error threshold to drm_ras (Raag) Driver Changes: - Remove sysfs entry on idr_alloc failure in xe_oa_add_config_ioctl (Lu) - match argument naming with PCODE_DATAx (Grzelak) - fix stale GGTT mappings on unmap (Tangudu) - Introduce error threshold to drm_ras (Raag) - Add debugfs knob to control GPGPU preemption granularity (Varun) - fix vecs config for powergating info (Ashutosh) - Read mailbox phase bit from hardware (Anoop) - alerts and controller enabling modifications (Heikki) - Use int instead of u32 for mailbox status (Umesh) - Reject page faults from non-fault-mode scratch VMs (Arvind) - Add CCS to the powergating info print (Balasubramani) - Do not apply WA 14025883347 to media 3503 (Daniele) - don't WARN on kernel job timeout when device already wedged (Nitin) - handle exec queue teardown after hot-unplug (Nitin) - Allow debugging PCI errors (Raag) - Add structured SIGID error logging infrastructure (Wajdeczko, Rodrigo) - Enable package and vram temperatures for CRI (Karthik) - Introduce cold reset recovery method (Mallesh) - fix error message in xe_migrate_sanity_test (Dan Carpenter) - Add drm_ras netlink error event support (Riana) - Fix a bug in pc_adjust_freq_bounds() (Vinay) - Fix xe_device_probe() failure (Raag) - Page fault cleanups (Wajdeczko) - OA memory fixes (Linmao) - document sentinel and make CTX_TIMESTAMP read TOCTOU-safe (Gajendra) - Move has_drm_ras check to drm_ras layer (Raag) - add termination on resume (Daniele) - Add _locked variants of some config functions (Wajdeczko) - Order ring writes before ring tail updates (Brost) - Parallel page fault handling (Brost) - handle CRI+ power interval encoding (Karthik) - allocate UM queues in a separate UC BO (Jia) - Fix boot-time ras error processing (Raag) - VF migration for multi-queue (Niranjana) - Apply RCS/CCS yield policy to SR-IOV VFs (Marcin) - Fix memory leak in exec_queue_set_hang_replay_state (Winiarski) - Use IBC v3 on PTL (Vinay) - Reduce MERT debug log spam (Lukasz, Piotr) - Validate sysctrl response (Raag) - Changes for Xe3p_HPM media (Ashutosh) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/apYbnrklyk6nNO7Q@gsse-cloud1.jf.intel.com
2026-09-07drm/msm/adreno: Only check for PAS when a zap shader is presentPaul Hollinsky
Commit 0be72be03ca7 ("drm/msm: Switch to generic PAS TZ APIs") replaced the qcom_scm_is_available() check in adreno_zap_shader_load() with qcom_pas_is_available(). These are not equivalent: the former reports whether the SCM transport is up, the latter whether the TrustZone firmware implements the peripheral authentication service. On SC7180 Chromebooks (trogdor) TZ does not implement PAS at all. SCM call-availability queries return 0 for every PAS command while other services answer normally: svc 0x06 cmd 0x01 IS_CALL_AVAIL -> 1 svc 0x02 cmd 0x01 PAS_INIT_IMAGE -> 0 svc 0x02 cmd 0x05 PAS_AUTH_RESET -> 0 svc 0x02 cmd 0x07 PAS_IS_SUPPORTED -> 0 svc 0x0c cmd 0x16 MP_ASSIGN -> 1 svc 0x05 cmd 0x01 IO_READ -> 1 so qcom_scm_probe() never registers a PAS backend and qcom_pas_is_available() is false for the lifetime of the boot. That on its own need not matter, because sc7180-trogdor.dtsi does /delete-node/ &gpu_zap_shader;, and the intended path for such a board is for zap_shader_load_mdt() to find no zap-shader child, clear zap_available, return -ENODEV, and let the caller fall back to SECVID_TRUST_CNTL. The problem is the ordering. zap_available is a static initialised to true and is only ever cleared inside zap_shader_load_mdt(), but adreno_zap_shader_load() consults PAS before calling it. The discovery that decides whether a zap shader is needed at all can therefore never run, the flag is never cleared, and every call returns -EPROBE_DEFER: adreno 5000000.gpu: [drm:adreno_zap_shader_load] *ERROR* PAS is not available msm_dpu ae01000.display-controller: [drm:adreno_load_gpu] *ERROR* gpu hw init failed: -517 Nothing retries that deferral, either. adreno_zap_shader_load() is called from a6xx_hw_init() rather than from probe, so the -EPROBE_DEFER is not a probe return value: it propagates up until adreno_load_gpu() returns NULL. load_gpu() re-attempts on every DRM open while priv->gpu is NULL, each open fails identically, and PAS cannot become available in between - which is why the error repeats and userspace stays on llvmpipe. Move the availability check into zap_shader_load_mdt(), behind the zap-shader node lookup, so the driver only consults PAS once it knows it needs PAS. Boards with no zap-shader node take the intended -ENODEV fallback without ever asking, and boards that do have one keep the qcom_pas_is_available() gate. Fixes: 0be72be03ca7 ("drm/msm: Switch to generic PAS TZ APIs") Link: https://lore.kernel.org/r/20260808034716.58888-1-phollinsky@holtechnik.com Signed-off-by: Paul Hollinsky <phollinsky@holtechnik.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/747583/ Message-ID: <20260821081325.89088-1-phollinsky@holtechnik.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-09-07Merge tag 'rust-dma-7.4-rc1' of ↵Danilo Krummrich
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core into drm-rust-next rust: dma: tie DMA allocations to the device's bound lifetime DMA allocations carry device resources (e.g. IOMMU mappings) that must not outlive the device's bound lifetime. Add lifetime parameters to the DMA allocation types (Coherent, CoherentBox, CoherentHandle) to enforce at compile time that they are freed before the device is unbound. Since DMA types with lifetime parameters are exposed through debugfs in the nova-core driver, first drop the unnecessary T: 'static bound from the debugfs ScopedDir file creation methods by formalizing a type invariant on FileOps. This is a stable tag for other trees to merge. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-07Merge patch series "rust: dma: tie DMA allocations to the device's bound ↵Danilo Krummrich
lifetime" Danilo Krummrich <dakr@kernel.org> says: DMA allocations carry device resources (e.g. IOMMU mappings) that must not outlive the device's bound lifetime. Add lifetime parameters to the DMA allocation types (Coherent, CoherentBox, CoherentHandle) to enforce at compile time that they are freed before the device is unbound. Since DMA types with lifetime parameters are exposed through debugfs in the nova-core driver, first drop the unnecessary T: 'static bound from the debugfs ScopedDir file creation methods by formalizing a type invariant on FileOps. Link: https://patch.msgid.link/20260830193824.471089-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-07Merge 7.3-rc2 into driver-core-nextGreg Kroah-Hartman
We need the driver-core fixes in here as well to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>