summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-03-24drm/amdgpu: use DISCOVERY_TMR_SIZE in ACPI TMR fallbackJesse.Zhang
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
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
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
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
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
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
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
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
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
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ä
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ä
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ä
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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>
2026-03-24drm/imagination: Switch reset_reason fields from enum to u32Alexandru Dadu
Update the reset_reason fwif structure fields from enum to u32 to remove any ambiguity from the interface (enum is not a fixed size thus is unfit for the purpose of the data type). Fixes: a26f067feac1f ("drm/imagination: Add FWIF headers") 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-2-1a66049a9a65@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-03-24drm/imagination: Add missing rogue context reset reasonsAlexandru Dadu
Update the context reset reason enum with the missing reset reasons in the 6-11 value gap: - CDM Mission/safety checksum mismatch; - TRP checksum mismatch; - GPU ECC error (corrected, OK); - GPU ECC error (uncorrected, HWR); - FW ECC error (corrected, OK); - FW ECC error (uncorrected, ERR); 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-1-1a66049a9a65@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-03-24drm/i915/lt_phy: Replace crtc compute clockMika Kahola
The existing DPLL compute clock callback for the XE3PLPD platform (`xe3plpd_crtc_compute_clock`) was specific to that platform. Replace it with the more generic Haswell (`hsw_crtc_compute_clock`) implementation so that the compute clock path does not rely on the XE3PLPD hook. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260312080657.2648265-25-mika.kahola@intel.com
2026-03-24drm/i915/lt_phy: Enable dpll framework for xe3plpdMika Kahola
xe3plpd platform is supported by dpll framework remove a separate check for hw comparison and rely solely on dpll framework hw comparison. Finally, all required hooks are now in place so initialize PLL manager for xe3plpd platform and remove the redirections to the legacy code paths for clock enable/disable as well as state mismatch checks that are no longer needed. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260312101415.2669387-1-mika.kahola@intel.com
2026-03-24drm/i915/lt_phy: Remove LT PHY specific state verificationMika Kahola
Remove LT PHY specific state verification as DPLL framework has state verification check. v2: Reuse intel_lt_phy_pll_compare_hw_state() as only config[0] and config[0] parameters are reliable with LT PHY (Suraj) v3: Rephrase handling of LT PHY case when verifying the state (CI) v4: Fix checkpatch warning of line length exceeding 100 columns Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260312080657.2648265-23-mika.kahola@intel.com
2026-03-24drm/i915/lt_phy: Add xe3plpd Thunderbolt PLL hooksMika Kahola
Add the PLL hooks for the TBT PLL on xe3plpd. These are simple stubs similar to the TBT PLL on earlier platforms, since this PLL is always on from the display POV - so no PLL enable/disable programming is required as opposed to the non-TBT PLLs - and the clocks for different link rates are enabled/disabled at a different level, via the intel_encoder::enable_clock()/disable_clock() interface. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260312080657.2648265-22-mika.kahola@intel.com
2026-03-24drm/i915/lt_phy: Get encoder configuration for xe3plpd platformMika Kahola
Reuse mtl_ddi_*_get_config functions now that all hooks are in place. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260312080657.2648265-21-mika.kahola@intel.com
2026-03-24drm/i915/lt_phy: Readout lane countMika Kahola
Readout lane count back from HW. Reuse existing function for Cx0 for LT PHY case with minor modification to add lanes as function parameters. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260312080657.2648265-20-mika.kahola@intel.com
2026-03-24drm/i915/lt_phy: Dump lane count for HW stateMika Kahola
To increase debuggability add lane count as part of HW state dump. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260312080657.2648265-19-mika.kahola@intel.com
2026-03-24drm/i915/lt_phy: Add .disable_clock hook on DDIMika Kahola
Add new pll_disable_clock functions so that they can be hooked up to dpll->disable. This is just a wrapper over the exitisting intel_xe3plpd_pll_disable to make it compatible With dpll->disable function v2: Revise commit message (Suraj) Drop wrapper for TBT clock disabling and reuse intel_mtl_pll_disable_clock() for DDI clock disabling hook (Suraj) Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260312080657.2648265-18-mika.kahola@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-13 12:52:43 +0000