summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
10 daysdrm/xe/sysctrl: Add helper to check oCode firmware readinessAnoop Vijay
Add xe_sysctrl_is_oobmsm_fw_ready(), a convenience wrapper around xe_sysctrl_check_app_status() to check oCode application readiness. Signed-off-by: Anoop Vijay <anoop.c.vijay@intel.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260904134935.674507-6-anoop.c.vijay@intel.com
10 daysdrm/xe/sysctrl: Add helper to query application statusAnoop Vijay
Add xe_sysctrl_check_app_status() to query the state of a System Controller application using get_app_status_by_id mailbox command. The helper maps xe_sysctrl_app_id values to firmware application IDs and returns the reported application state. Add a convenience wrapper to check diag firmware application readiness. Signed-off-by: Anoop Vijay <anoop.c.vijay@intel.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260904134935.674507-5-anoop.c.vijay@intel.com
10 daysdrm/bridge: ti-sn65dsi83: Support LVDS Channel B on SN65DSI84Esben Haabendal
Add support for using SN65DSI84 in single-link mode with output to LVDS Channel B. Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Esben Haabendal <esben@geanix.com> Link: https://patch.msgid.link/20260831-ti-sn65dsi83-fixes-v5-2-e712765d6c4f@geanix.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
10 daysdrm/i915: Fix memory leak in query_perf_config_list()Thorsten Blum
When krealloc() fails, free the original oa_config_ids before returning to avoid a memory leak. Fixes: 4f6ccc74a85c ("drm/i915: add support for perf configuration queries") Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Cc: <stable@vger.kernel.org> # v5.5+ Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patch.msgid.link/20260823205028.178597-2-thorsten.blum@linux.dev
10 daysdrm/ci: Update xfails for kms_cursor_legacy regressionRob Clark
These four started failing with some change not merged thru the msm tree. Update xfails to reflect reality. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
10 daysdrm/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 (cherry picked from commit 434514b6fe731e873808297c268fc52cdf4a1ce6) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
10 daysdrm/xe: Guard page-fault worker with runtime PM checkVarun Gupta
During VM teardown, the VM's runtime PM reference is dropped asynchronously, allowing the device to autosuspend while stale page faults belonging to the now-dead VM are still queued. When the page-fault worker later tries to ack one of these, it calls into guc_ct_send_locked() on an already-suspended device, tripping:   Assertion `!xe_pm_runtime_suspended(xe)` failed!   WARNING at xe_device.c:1267 xe_device_assert_mem_access+0x11c/0x140 [xe] A live VM/exec queue always holds a PM reference while it has outstanding work, so if the device is suspended at ack time, the owning context is already gone and the fault is stale. Take a runtime PM reference across the entire pagefault queue worker to safely deliver acks for torn-down VMs. v3: - Move PM ref to the generic xe_pagefault_queue_work using guard(xe_pm_runtime)(xe) instead of tracking it in the GuC backend(Matt Brost). v2: - Hold PM ref across the entire batch (begin/end) instead of per-ack. This prevents the device from autosuspending mid-batch, which would leave write_only acks written but the end flush skipped, and skip counter++, desyncing the cadence check.(Himal) - Add a comment explaining stale faults.(Himal) Fixes: f289f7807119 ("drm/xe: Add xe_guc_pagefault layer") Signed-off-by: Varun Gupta <varun.gupta@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patch.msgid.link/20260907050011.497181-2-varun.gupta@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit fcc2431d2213dc4d04250c4f1ae87d9c3ae0d455) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo: Added xe_device struct for compatibility while cherry-picking]
10 daysdrm/bridge: ti-sn65dsi83: Fix error handling in sn65dsi83_reset_work()Esben Haabendal
The error handling of sn65dsi83_reset_pipe() in sn65dsi83_reset_work() has seen a couple of changes that seems to cause a bit of confusion. While sn65dsi83_reset_work() has implemented an early exit if sn65dsi83_reset_pipe() fails since it was added, when a commit from Maxime Ripard switched to use drm_bridge_helper_reset_crtc() [1] the sn65dsi83_reset_pipe() function would no longer return an error code, so the early exit was then a no-op, and even on sn65dsi83_reset_pipe() failure, enable_irq() has been called. When drm_bridge_enter()/drm_bridge_exit() resource protection was added, the drm_bridge_exit() incidentally was always called, which is the correct approach. But only because the early exit in sn65dsi83_reset_pipe() was never hit because sn65dsi83_reset_pipe() always returns 0. In order get back to a situation where enable_irq() is not called on sn65dsi83_reset_pipe() failure, which should help protect against irq storms, we need to reintroduce a non-zero return value from sn65dsi83_reset_pipe() on error, and fix sn65dsi83_reset_work() so that we always exit the DRM bridge critical section with drm_bridge_exit(). [1] commit e17fadff7ab9 ("drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtc") [2] commit d2e8d1bc840b ("drm/bridge: ti-sn65dsi83: protect device resources on unplug") Fixes: e17fadff7ab9 ("drm/bridge: ti-sn65dsi83: Switch to drm_bridge_helper_reset_crtc") Cc: stable@vger.kernel.org Signed-off-by: Esben Haabendal <esben@geanix.com> Reviewed-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260831-ti-sn65dsi83-fixes-v5-1-e712765d6c4f@geanix.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
10 daysdrm/bridge: analogix_dp: Add support for optional data-lanes mappingDamon Ding
Parse the optional 'data-lanes' device tree property to support custom physical lane mapping configuration. If no valid configuration is found, fall back to the default lane map (0, 1, 2, 3) automatically and keep the driver running. Lane mapping is mainly used for below scenarios: 1. Correct PCB lane swap and differential line routing crossover without hardware changes; 2. Adapt mismatched lane pin definitions between SoC and eDP panel; 3. Support multiple panel hardware variants on the same board by configuring data-lanes in device tree only. Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260828065153.590802-6-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
10 daysdrm/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>
10 daysdrm/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>
10 daysdrm/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
10 daysdrm/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
10 daysdrm/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
10 daysdrm/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
10 daysdrm/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
10 daysdrm/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
10 daysdrm/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
10 daysdrm/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
10 daysdrm/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
10 daysdrm/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>
10 daysdrm/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>
11 daysdrm/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>
11 daysdrm/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>
11 daysdrm/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
11 daysdrm/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
11 daysdrm/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
11 daysdrm/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
11 daysdrm/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
11 daysdrm/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
11 daysdrm/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
11 daysdrm/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
11 daysdrm/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
11 daysMerge 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>
11 daysMerge 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
11 daysMerge 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
11 daysdrm/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>
11 daysdrm/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>
11 daysdrm/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>
11 daysdrm/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>
11 daysdrm/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
11 daysdrm/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
11 daysdrm/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
11 daysdrm/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
11 daysdrm/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
11 daysdrm/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
12 daysdrm/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
12 daysdrm/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
12 daysdrm/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
12 daysdrm/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
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-19 17:14:25 +0000