summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorLines
2026-03-24drm/amd/display: Fix DCE LVDS handlingAlex Deucher-22/+19
LVDS does not use an HPD pin so it may be invalid. Handle this case correctly in link encoder creation. Fixes: 7c8fb3b8e9ba ("drm/amd/display: Add hpd_source index check for DCE60/80/100/110/112/120 link encoders") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5012 Cc: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Cc: Roman Li <roman.li@amd.com> Reviewed-by: Roman Li <roman.li@amd.com> Reviewed-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu: update outdated comment for renamed amdgpu_fence_driver_init()Kexin Sun-1/+1
The function amdgpu_fence_driver_init() was renamed to amdgpu_fence_driver_sw_init() by commit 067f44c8b459 ("drm/amdgpu: avoid over-handle of fence driver fini in s3 test (v2)"). Update the stale reference in the amdgpu_fence_driver_init_ring() kdoc. Assisted-by: unnamed:deepseek-v3.2 coccinelle Signed-off-by: Kexin Sun <kexinsun@smail.nju.edu.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu/userq: convert comma to semicolonChen Ni-2/+2
Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu: Handle GPU page faults correctly on non-4K page systemsDonet Tom-3/+3
During a GPU page fault, the driver restores the SVM range and then maps it into the GPU page tables. The current implementation passes a GPU-page-size (4K-based) PFN to svm_range_restore_pages() to restore the range. SVM ranges are tracked using system-page-size PFNs. On systems where the system page size is larger than 4K, using GPU-page-size PFNs to restore the range causes two problems: Range lookup fails: Because the restore function receives PFNs in GPU (4K) units, the SVM range lookup does not find the existing range. This will result in a duplicate SVM range being created. VMA lookup failure: The restore function also tries to locate the VMA for the faulting address. It converts the GPU-page-size PFN into an address using the system page size, which results in an incorrect address on non-4K page-size systems. As a result, the VMA lookup fails with the message: "address 0xxxx VMA is removed". This patch passes the system-page-size PFN to svm_range_restore_pages() so that the SVM range is restored correctly on non-4K page systems. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Donet Tom <donettom@linux.ibm.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amd/display: update outdated comments for renamed vblank_control_worker()Kexin Sun-3/+5
The function vblank_control_worker() was renamed to amdgpu_dm_crtc_vblank_control_worker() by commit 6ce4f9ee25ff ("drm/amd/display: Add prefix to amdgpu crtc functions"). Update the two stale references in amdgpu_dm.c. Assisted-by: unnamed:deepseek-v3.2 coccinelle Signed-off-by: Kexin Sun <kexinsun@smail.nju.edu.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amd/display: clean up typecasts and constants in dcn4_calcsAdriano Vero-16/+16
Signed-off-by: Adriano Vero <litaliano00.contact@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu/userq: dont use goto to jump when at end of functionSunil Khatri-3/+1
In function amdgpu_userq_restore_worker we dont need to use goto as we already in the end of function and it will exit naturally. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu: fix syncobj leak for amdgpu_gem_va_ioctl()Prike Liang-0/+5
It requires freeing the syncobj and chain alloction resource. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu/vcn4.0.3: gate per-queue reset by PSP SOS program versionJesse Zhang-1/+18
Add a PSP SOS firmware compatibility check before enabling VCN per-queue reset on vcn_v4_0_3. Per review, program check is sufficient: when PSP SOS program is 0x01, require fw version >= 0x0036015f; otherwise allow per-queue reset. Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Suggested-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Jesse Zhang <Jesse.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amd/pm: Enable VCN reset for pgm=4 with appropriate FW versionJesse.Zhang-0/+1
Extend the VCN reset capability to include pgm=4 variants when the firmware version meets the required threshold (>= 0x04557100). This follows the existing pattern for pgm=0 and pgm=7, ensuring that VCN reset is enabled only on configurations where it is supported by the firmware. Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu: use DISCOVERY_TMR_SIZE in ACPI TMR fallbackJesse.Zhang-1/+1
amdgpu_acpi_get_tmr_info() returns the full TMR region size, not the IP discovery table size. Using tmr_size as discovery.size can lead to oversized allocations and probe failure. In the ACPI fallback path, keep discovery.size as DISCOVERY_TMR_SIZE and only use ACPI data for offset calculation. Fixes: 01bdc7e219c4 ("drm/amdgpu: New interface to get IP discovery binary v3") Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Suggested-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amd/pm: add dedicated dram addr msg for smu v15Yang Wang-4/+6
Add dedicated SMU Dram MSG mapping to avoid conflicts in SMU IP v15 common code for upcoming ASICs. add new smu msg: - SMU_MSG_SetDriverDramAddr - SMU_MSG_SetToolsDramAddr Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amd/pm: disable OD_FAN_CURVE if temp or pwm range invalid for smu v14Yang Wang-1/+32
Forcibly disable the OD_FAN_CURVE feature when temperature or PWM range is invalid, otherwise PMFW will reject this configuration on smu v14.0.2/14.0.3. example: $ sudo cat /sys/bus/pci/devices/<BDF>/gpu_od/fan_ctrl/fan_curve OD_FAN_CURVE: 0: 0C 0% 1: 0C 0% 2: 0C 0% 3: 0C 0% 4: 0C 0% OD_RANGE: FAN_CURVE(hotspot temp): 0C 0C FAN_CURVE(fan speed): 0% 0% $ echo "0 50 40" | sudo tee fan_curve kernel log: [ 969.761627] amdgpu 0000:03:00.0: amdgpu: Fan curve temp setting(50) must be within [0, 0]! [ 1010.897800] amdgpu 0000:03:00.0: amdgpu: Fan curve temp setting(50) must be within [0, 0]! Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdkfd: Fix NULL pointer check order in kfd_ioctl_create_processSrinivasan Shanmugam-3/+3
In kfd_ioctl_create_process(), the pointer 'p' is used before checking if it is NULL. The code accesses p->context_id before validating 'p'. This can lead to a possible NULL pointer dereference. Move the NULL check before using 'p' so that the pointer is validated before access. Fixes the below: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_chardev.c:3177 kfd_ioctl_create_process() warn: variable dereferenced before check 'p' (see line 3174) Fixes: cc6b66d661fd ("amdkfd: introduce new ioctl AMDKFD_IOC_CREATE_PROCESS") Cc: Zhu Lingshan <lingshan.zhu@amd.com> Cc: Felix Kuehling <felix.kuehling@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amd/display: check if ext_caps is valid in BL setupAlex Deucher-1/+1
LVDS connectors don't have extended backlight caps so check if the pointer is valid before accessing it. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5012 Fixes: 1454642960b0 ("drm/amd: Re-introduce property to control adaptive backlight modulation") Cc: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ibSrinivasan Shanmugam-2/+2
amdgpu_amdkfd_submit_ib() submits a GPU job and gets a fence from amdgpu_ib_schedule(). This fence is used to wait for job completion. Currently, the code drops the fence reference using dma_fence_put() before calling dma_fence_wait(). If dma_fence_put() releases the last reference, the fence may be freed before dma_fence_wait() is called. This can lead to a use-after-free. Fix this by waiting on the fence first and releasing the reference only after dma_fence_wait() completes. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:697 amdgpu_amdkfd_submit_ib() warn: passing freed memory 'f' (line 696) Fixes: 9ae55f030dc5 ("drm/amdgpu: Follow up change to previous drm scheduler change.") Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Dan Carpenter <dan.carpenter@linaro.org> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/komeda: Add support for Arm China Linlon-D6Cunyuan Liu-0/+3
Arm China Linlon-D6 is register-compatible with the Mali-D71 display pipeline for the purpose of basic modesetting. On Linlon-D6, the PRODUCT_ID register is located at the same offset as on Mali-D71 and reports 0x0060. The IP also exposes the same Komeda top-level block layout expected by the existing d71_identify() probing flow, so we can reuse the D71 function table to bring up the display engine. Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Cunyuan Liu <cunyuan.liu@cixtech.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260313033119.33686-4-cunyuan.liu@cixtech.com
2026-03-24drm/panthor: extend timestamp query with flagsMarcin Slusarz-6/+128
Flags now control which data user space wants to query, there is more information sources, and there's ability to query duration of multiple timestamp reads. New sources: - CPU's monotonic, - CPU's monotonic raw, - GPU's cycle count These changes should make the implementation of VK_KHR_calibrated_timestamps more accurate and much simpler. Signed-off-by: Marcin Slusarz <marcin.slusarz@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260324132557.1707286-1-marcin.slusarz@arm.com
2026-03-24drm/panthor: correct firmware related messagesChristian Hewitt-2/+2
Some English language corrections to firmware messages. No functional changes. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260323081132.3217646-1-christianshewitt@gmail.com
2026-03-24drm: fix dead default for DRM_TTM_KUNIT_TESTJulian Braha-1/+0
The DRM_TTM_KUNIT_TEST config option should default to KUNIT_ALL_TESTS so that if all tests are enabled then it is included, but currently the 'default KUNIT_ALL_TESTS' statement is shadowed by an unconditional 'default n', meaning that this second default statement is currently dead code. This dead code was found by kconfirm, a static analysis tool for Kconfig. Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20260323124118.1414913-1-julianbraha@gmail.com
2026-03-24drm/i915/de: Implement register polling in the display codeVille Syrjälä-39/+91
The plan is to move all the mmio stuff into the display code itself. As a first step implement the register polling in intel_de.c. Currently i915 and xe implement this stuff in slightly different ways, so there are some functional changes here. Try to go for a reasonable middle ground between the i915 and xe implementations: - the exponential backoff limit is the simpler approach taken by i915 (== just clamp the max sleep duration to 1 ms) - the fast vs. slow timeout handling is similar to i915 where we first try the fast timeout and then again the slow timeout if the condition still isn't satisfied. xe just adds up the timeouts together, which is a bit weird. - the atomic wait variant uses udelay() like xe, whereas i915 has no udelay()s in its atomic loop. As a compromise go for a fixed 1 usec delay for short waits, instead of the somewhat peculiar xe behaviour where it effectively just does one iteration of the loop. - keep the "use udelay() for < 10 usec waits" logic (which more or less mirrors fsleep()), but include an explicit might_sleep() even for these short waits when called from a non-atomic intel_de_wait*() function. This should prevent people from calling the non-atomic functions from the wrong place. Eventually we may want to switch over to poll_timeout*(), but that lacks the exponential backoff, so a bit too radical to change in one go. v2: Initialize ret in intel_de_wait_for_register() to avoid a warning from the compiler. This is actually a false positive since we always have fast_timeout_us!=0 when slow_timeout_us!=0, but the compiler can't see that Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260323094304.8171-1-ville.syrjala@linux.intel.com
2026-03-24drm/i915/de: Move intel_de_wait*() into intel_de.cVille Syrjälä-79/+92
intel_de_wait*() end up doing quite a bit of stuff, so the one function call overhead from them seems insignificant. Move the implementation intel_de.c. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260313111028.25159-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-24drm/i915/de: Introduce intel_de.c and move intel_de_{read,write}8() thereVille Syrjälä-19/+28
intel_de_{read,write}8() aren't performance critical so having them as static inline is pointless. Introduce intel_de.c and move the implementation there. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260313111028.25159-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-24drm/xe/xelp: Expose AuxCCS frame buffer modifiers on Alderlake-PTvrtko Ursulin-0/+8
Now that we have implemented all the related missing bits we can enable the AuxCCS compressed modifiers which were disabled in cf48bddd31de ("drm/i915/display: Disable AuxCCS framebuffers if built for Xe"). Tested with KDE Wayland, on Lenovo Carbon X1 ADL-P: [PLANE:32:plane 1A]: type=PRI uapi: [FB:242] AR30 little-endian (0x30335241),0x100000000000008,2880x1800, visible=visible, src=28 hw: [FB:242] AR30 little-endian (0x30335241),0x100000000000008,2880x1800, visible=yes, src=2880.000 Display is working fine - no artefacts, no DMAR/PIPE faults. v2: * Adjust patch title. (Rodrigo) v3: * Complete rewrite based on the display parent interface. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> References: cf48bddd31de ("drm/i915/display: Disable AuxCCS framebuffers if built for Xe") Cc: Jani Nikula <jani.nikula@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260324084018.20353-13-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-24drm/xe/display: Add support for AuxCCSTvrtko Ursulin-1/+27
Add support for mapping the auxiliary CCS buffer into the DPT page tables. This will allow for better power efficiency by enabling the render compression frame buffer modifiers such as I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS in a following patch. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Michael J. Ruhl <michael.j.ruhl@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260324084018.20353-12-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-24drm/xe/display: Respect remapped plane alignmentTvrtko Ursulin-3/+12
Instead of assuming PAGE_SIZE alignment between the remapped planes respect the value set in the struct intel_remapped_info. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Michael J. Ruhl <michael.j.ruhl@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260324084018.20353-11-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-24drm/xe/display: Change write_dpt_remapped_tiled function signatureTvrtko Ursulin-25/+35
In preparation for adding support for the auxccs plane lets change the function signature of write_dpt_remapped_tiled(). This will enable a tidier way of extending it subsequent patches. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Michael J. Ruhl <michael.j.ruhl@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260324084018.20353-10-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-24drm/xe/display: Move remapped plane loop out of __xe_pin_fb_vma_dptTvrtko Ursulin-14/+20
In preparation for adding support for the auxccs plane lets move the plane iteration loop to its own function. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Michael J. Ruhl <michael.j.ruhl@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260324084018.20353-9-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-24drm/xe/xelp: Add AuxCCS invalidation to the indirect context workaroundsTvrtko Ursulin-0/+23
Following from the i915 reference implementation, we add the AuxCCS invalidation to the indirect context workarounds page. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260324084018.20353-8-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-24drm/xe: Move aux table invalidation to ring opsTvrtko Ursulin-28/+83
Implement the suggestion of moving the aux invalidation from a helper to a ring ops vfunc, together with the suggestion to split the vfunc table of video decode and video enhance engines. With this done the LRC code will be able to access the functionality via the newly added ring ops vfunc. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Suggested-by: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260324084018.20353-7-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-24drm/xe/xelp: Wait for AuxCCS invalidation to completeTvrtko Ursulin-2/+15
On AuxCCS platforms we need to wait for AuxCCS invalidations to complete. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260324084018.20353-6-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-24drm/xe/xelp: Quiesce memory traffic before invalidating AuxCCSTvrtko Ursulin-1/+9
According to i915 commit ad8ebf12217e ("drm/i915/gt: Ensure memory quiesced before invalidation") quiescing of the memory traffic is required before invalidating the AuxCCS tables. Add an extra pipe control flush to achieve that. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260324084018.20353-5-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-24drm/xe/xelpg: Limit AuxCCS ring buffer programming to AlderlakeTvrtko Ursulin-2/+2
At the moment the driver does not support AuxCCS at all due respective modifiers being hidden from userspace. As we are about to start enabling them, starting with Alderlake, let us begin by limiting the ring buffer support to just that initial platform. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260324084018.20353-4-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-24drm/xe: Implement recent spec updates to Wa_16025250150Matt Roper-1/+3
The hardware teams noticed that the originally documented workaround steps for Wa_16025250150 may not be sufficient to fully avoid a hardware issue. The workaround documentation has been augmented to suggest programming one additional register; make the corresponding change in the driver. Fixes: 7654d51f1fd8 ("drm/xe/xe2hpg: Add Wa_16025250150") Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20260319-wa_16025250150_part2-v1-1-46b1de1a31b2@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit a31566762d4075646a8a2214586158b681e94305) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-24drm/xe: Use write-combine mapping when populating DPTTvrtko Ursulin-1/+2
The fallback case for DPT backing store is a buffer object in system memory buffer, which by default use a write-back CPU caching policy. If this fallback gets triggered, and since there is currently no flushing, the DPT writes made when pinning a buffer to display are not guaranteed to be seen by the display engine. To fix this, since both the local memory and the stolen memory DPT placements already use write-combine, let us make the system memory option follow suit by passing down the appropriate flag. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260324084018.20353-3-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-24drm/xe: Rename XE_BO_FLAG_SCANOUT to XE_BO_FLAG_FORCE_WCTvrtko Ursulin-19/+26
Rename XE_BO_FLAG_SCANOUT to XE_BO_FLAG_FORCE_WC so that the usage of the flag can legitimately be expanded to more than just the actual frame- buffer objects. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260324084018.20353-2-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-24drm/display: hdmi: Use drm_output_color_format instead of hdmi_colorspaceMaxime Ripard-179/+202
The hdmi_colorspace enum was defined to represent the colorspace value of the HDMI infoframes. It was later used by some HDMI drivers to express the output format they should be setting up. During the introduction of the HDMI helpers, it then was used to represent it in the drm_connector_hdmi_state structure. However, it's always been somewhat redundant with the DRM_COLOR_FORMAT_* defines, and now with the drm_output_color_format enum. Let's consolidate around drm_output_color_format in drm_connector_hdmi_state to facilitate the current effort to provide a global output format selection mechanism. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-14-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/rockchip: analogix: Convert to drm_output_color_formatMaxime Ripard-2/+2
Now that we introduced a new drm_output_color_format enum to represent what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new enum. The main difference is that while DRM_COLOR_FORMAT_ was a bitmask, drm_output_color_format is a proper enum. However, the enum was done is such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so the transitition is easier. The only thing we need to consider is if the original code meant to use that value as a bitmask, in which case we do need to keep the bit shift, or as a discriminant in which case we don't. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-12-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/mediatek: dp: Convert to drm_output_color_formatMaxime Ripard-2/+2
Now that we introduced a new drm_output_color_format enum to represent what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new enum. The main difference is that while DRM_COLOR_FORMAT_ was a bitmask, drm_output_color_format is a proper enum. However, the enum was done is such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so the transitition is easier. The only thing we need to consider is if the original code meant to use that value as a bitmask, in which case we do need to keep the bit shift, or as a discriminant in which case we don't. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-11-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/arm: komeda: Convert to drm_output_color_formatMaxime Ripard-11/+12
Now that we introduced a new drm_output_color_format enum to represent what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new enum. The main difference is that while DRM_COLOR_FORMAT_ was a bitmask, drm_output_color_format is a proper enum. However, the enum was done is such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so the transitition is easier. The only thing we need to consider is if the original code meant to use that value as a bitmask, in which case we do need to keep the bit shift, or as a discriminant in which case we don't. Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-10-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/bridge: synopsys: dw-hdmi: Convert to drm_output_color_formatMaxime Ripard-8/+8
Now that we introduced a new drm_output_color_format enum to represent what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new enum. The main difference is that while DRM_COLOR_FORMAT_ was a bitmask, drm_output_color_format is a proper enum. However, the enum was done is such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so the transitition is easier. The only thing we need to consider is if the original code meant to use that value as a bitmask, in which case we do need to keep the bit shift, or as a discriminant in which case we don't. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-9-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/bridge: synopsys: dw-dp: Convert to drm_output_color_formatMaxime Ripard-35/+36
Now that we introduced a new drm_output_color_format enum to represent what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new enum. The main difference is that while DRM_COLOR_FORMAT_ was a bitmask, drm_output_color_format is a proper enum. However, the enum was done is such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so the transitition is easier. The only thing we need to consider is if the original code meant to use that value as a bitmask, in which case we do need to keep the bit shift, or as a discriminant in which case we don't. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-8-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/bridge: cadence: Convert to drm_output_color_formatMaxime Ripard-13/+13
Now that we introduced a new drm_output_color_format enum to represent what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new enum. The main difference is that while DRM_COLOR_FORMAT_ was a bitmask, drm_output_color_format is a proper enum. However, the enum was done is such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so the transitition is easier. The only thing we need to consider is if the original code meant to use that value as a bitmask, in which case we do need to keep the bit shift, or as a discriminant in which case we don't. Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-7-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/bridge: analogix: Convert to drm_output_color_formatMaxime Ripard-2/+2
Now that we introduced a new drm_output_color_format enum to represent what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new enum. The main difference is that while DRM_COLOR_FORMAT_ was a bitmask, drm_output_color_format is a proper enum. However, the enum was done is such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so the transitition is easier. The only thing we need to consider is if the original code meant to use that value as a bitmask, in which case we do need to keep the bit shift, or as a discriminant in which case we don't. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-6-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/bridge: adv7511: Convert to drm_output_color_formatMaxime Ripard-1/+1
Now that we introduced a new drm_output_color_format enum to represent what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new enum. The main difference is that while DRM_COLOR_FORMAT_ was a bitmask, drm_output_color_format is a proper enum. However, the enum was done is such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so the transitition is easier. The only thing we need to consider is if the original code meant to use that value as a bitmask, in which case we do need to keep the bit shift, or as a discriminant in which case we don't. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-5-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/amdgpu: display: Convert to drm_output_color_formatMaxime Ripard-2/+2
Now that we introduced a new drm_output_color_format enum to represent what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new enum. The main difference is that while DRM_COLOR_FORMAT_ was a bitmask, drm_output_color_format is a proper enum. However, the enum was done is such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so the transitition is easier. The only thing we need to consider is if the original code meant to use that value as a bitmask, in which case we do need to keep the bit shift, or as a discriminant in which case we don't. Acked-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-4-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/display: hdmi: Convert to drm_output_color_formatMaxime Ripard-4/+4
Now that we introduced a new drm_output_color_format enum to represent what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new enum. The main difference is that while DRM_COLOR_FORMAT_ was a bitmask, drm_output_color_format is a proper enum. However, the enum was done is such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so the transitition is easier. The only thing we need to consider is if the original code meant to use that value as a bitmask, in which case we do need to keep the bit shift, or as a discriminant in which case we don't. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-3-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/edid: Convert to drm_output_color_format enumMaxime Ripard-9/+9
Now that we introduced a new drm_output_color_format enum to represent what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new enum. The main difference is that while DRM_COLOR_FORMAT_ was a bitmask, drm_output_color_format is a proper enum. However, the enum was done is such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so the transitition is easier. The only thing we need to consider is if the original code meant to use that value as a bitmask, in which case we do need to keep the bit shift, or as a discriminant in which case we don't. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-2-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/xe/pf: Add FLR_PREPARE state to VF control flowPiotr Piórkowski-16/+91
Our xe-vfio-pci component relies on the confirmation from the PF that VF FLR processing has finished, but due to the notification latency on the HW/FW side, PF might be unaware yet of the already triggered VF FLR. Update VF state machine with new FLR_PREPARE state that indicate imminent VF FLR notification and treat that as a begin of the FLR sequence. Also introduce function that xe-vfio-pci should call to guarantee correct synchronization. v2: move PREPARE into WIP, update commit msg (Michal) Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Co-developed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260309152449.910636-2-piotr.piorkowski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2026-03-24drm/imagination: Implement handling of context reset notificationAlexandru Dadu-0/+136
The firmware will send the context reset notification message as part of handling hardware recovery (HWR) events deecoding the message and printing via drm_info(). This eliminates the "Unknown FWCCB command" message that was previously printed. Co-developed-by: Sarah Walker <sarah.walker@imgtec.com> Signed-off-by: Sarah Walker <sarah.walker@imgtec.com> Signed-off-by: Alexandru Dadu <alexandru.dadu@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260323-b4-firmware-context-reset-notification-handling-v3-3-1a66049a9a65@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
generated by cgit v1.2.3 (git 2.46.0) at 2026-04-27 22:09:50 +0000