summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-10-25drm/i915/vrr: Check HAS_VRR() first in intel_vrr_is_capable()Ville Syrjälä1-2/+4
There's no point in doing all the other checks in intel_vrr_is_capable() if the platform doesn't support VRR at all Check HAS_VRR() before wasting time on the other checks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-23-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Update the intel_vrr_extra_vblank_delay() commentVille Syrjälä1-4/+2
The coment in intel_vrr_extra_vblank_delay() is a bit outdated now that we generally got rid of the "vblank delay" stuff. Update the comment to better describe the current state of things. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-22-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Nuke intel_vrr_vmin_flipline()Ville Syrjälä1-7/+2
Now that intel_vrr_flipline_offset() is completely hidden from the higher level VRR code, intel_vrr_vmin_flipline() has become rather pointless. Remove it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-21-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Nuke intel_vrr_vblank_exit_length()Ville Syrjälä1-6/+2
Now that we always populate crtc_state->vrr.guardband even on ICL/TGL intel_vrr_vblank_exit_length() has become rather pointless. Get rid of it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-20-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: s/crtc_state/old_crtc_state/ in intel_vrr_transcoder_disable()Ville Syrjälä1-4/+4
We generally use the 'old_crtc_state' in the disable functions to make it clear these generally get called when the hardware is still using the old crtc state rather than the new crtc state. Rename the intel_vrr_transcoder_disable() 'crtc_state' parameter to 'old_crtc_state' for consistency. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-19-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Move HAS_VRR() check into intel_vrr_set_transcoder_timings()Ville Syrjälä2-2/+4
Reduce the clutter in hsw_configure_cpu_transcoder() a bit by moving the HAS_VRR() check into intel_vrr_set_transcoder_timings(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-18-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Remove redundant HAS_VRR() checksVille Syrjälä1-6/+0
intel_vrr_transcoder_{enable,disable}() already check for intel_vrr_possible(), so the extra HAS_VRR() checks are redundant. Remove them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-17-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Always write TRANS_VRR_CTL in ↵Ville Syrjälä1-9/+3
intel_vrr_set_transcoder_timings() on !always_use_vrr_tg() Currently, depending on vrr.enable, we may write TRANS_VRR_CTL from both intel_vrr_set_transcoder_timings() and intel_vrr_transcoder_enable() on !always_use_vrr_tg() platforms. Streamline this so that we just always write it from intel_vrr_set_transcoder_timings(), and never from intel_vrr_transcoder_enable(). The main benefit is that intel_vrr_transcoder_enable() becomes symmetric to intel_vrr_transcoder_disable(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-16-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Disable VRR TG in intel_vrr_transcoder_disable() only on ↵Ville Syrjälä1-1/+2
always use_vrr_tg() platforms Currently we always disable the VRR timing generator in intel_vrr_transcoder_disable(). But doing so on !always_use_vrr_tg() platforms is redundant since we've alreayd disabled the VRR timing generator earlier in intel_vrr_disable(). Do the disable in intel_vrr_transcoder_disable() only on always_on_vrr_tg() platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-15-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Extract intel_vrr_tg_enable()Ville Syrjälä1-19/+25
Extract the VRR timing generator enable into intel_vrr_tg_enable(), as a counterpart to intel_vrr_tg_disable(). Note that the CMRR part is probably broken, but so are other things in the CMRR implementation, and thus it is currently disabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-14-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Extract intel_vrr_tg_disable()Ville Syrjälä1-23/+19
Now that we always disable the VRR timing generator the same way we can extract the duplicated code into a helper. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-13-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Use trans_vrr_ctl() in intel_vrr_transcoder_disable()Ville Syrjälä1-1/+2
Currently intel_vrr_disable() writes TRANS_VRR_CTL() with trans_vrr_ctl(), whereas intel_vrr_transcoder_disable() always writes just a plain 0. Write trans_vrr_ctl() in both places to unify the code, allowing for more shared code in the future. Since the VRR timing generator will be disabled by the TRANS_VRR_CTL write it doesn't really matter what we write to the register (other than VRR_CTL_VRR_ENABLE that is). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-12-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Move EMP_AS_SDP_TL write into intel_vrr_set_transcoder_timings()Ville Syrjälä1-23/+12
EMP_AS_SDL_TL replaces the TRANS_VRR_VSYNC for the purposes of setting the AS SDP transmission line. Move the EMP_AS_SDL_TL into intel_vrr_set_transcoder_timings() since that's where we write TRANS_VRR_VSYNC as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-11-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Avoid redundant TRANS_PUSH write in intel_vrr_enable()Ville Syrjälä1-3/+3
We keep TRANS_PUSH_EN always set for always_use_vrr_tg() platfforms, so there is no need to write it again in intel_vrr_enable(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-10-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Extract intel_vrr_set_vrr_timings()Ville Syrjälä1-4/+12
Extract intel_vrr_set_vrr_timings() as the counterpart to intel_vrr_set_fixed_rr_timings(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-9-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Move compute_fixed_rr_timings()Ville Syrjälä1-9/+9
Relocate intel_vrr_compute_fixed_rr_timings() next to its VRR and CMRR counterparts. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-8-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i195/vrr: Move crtc_state->vrr.{vmin,vmax} update into ↵Ville Syrjälä1-7/+7
intel_vrr_compute_vrr_timings() The way intel_vrr_compute_*_timings() works is rather confusing. First intel_vrr_compute_config() assigns the computed vmin/vmax into crtc_state->vrr.{vmin,vmax}, and then either intel_vrr_compute_vrr_timings() leaves them untouched or intel_vrr_compute_{cmrr,fixed_rr}_timings() overwrite them with something else. Clean this up by moving all crtc_state->vrr.{vmin,vmax} assignments into intel_vrr_compute_*_timings(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-7-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Reorganize intel_vrr_compute_cmrr_timings() a bitVille Syrjälä1-1/+2
Move the cmrr.enable assignment next to the mode_flags assignment to keep things in a bit more logical order in intel_vrr_compute_cmrr_timings(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-6-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-25drm/i915/vrr: Compute fixed refresh rate timings the same way as CMRR timingsVille Syrjälä1-5/+3
Unify the VRR timing computation stuff a bit having both the fixed refresh rate and CMRR cases assign the crtc_state->vrr stuff in exactly the same way. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-5-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-24drm/i915: Remove the "vblank delay" state dumpVille Syrjälä1-3/+1
The "vblank delay" we are including in the crtc state dump is meaningful only when running with fixed refresh rate timings. With VRR timings one has to look at the VRR state to figure out the same thing. Since we already dump the position of the delayed vblank for both fixed refresh rate and VRR timings, this "vblank delay" thing seems pretty much pointless now. Get rid of it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-4-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-24drm/i915/lrr: Include SCL in lrr_params_changed()Ville Syrjälä1-5/+8
If SCL is changing we need to take the LRR codepath to update it during a fastset. Account for that in lrr_params_changed(). The current code will only notice the SCL change if the position of the delayed vblank also changes. But that might not happen when using the VRR timing generator because the delayed vblank is then defined by the guardband instead of the SCL. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-3-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-24drm/i915/vrr: Fix intel_vrr_always_use_vrr_tg()==true on TGLVille Syrjälä1-0/+6
On TGL the hardware always needs TRANS_VBLANK.VBLANK_START to be programemd with VACTIVE+SCL. Make it so. The current way of programming it with crtc_vblank_start only works for the legacy timing generator, as there the delayed vblank does happen exactly at VACTIVE+SCL. But if one tries to change intel_vrr_always_use_vrr_tg() to always use the VRR timing generator on TGL, crtc_vblank_start will point to the VRR timing generator's delayed vblank, which may not match VACTIVE+SCL. Fortunately the state checker caught the issue right away when I tried intel_vrr_always_use_vrr_tg()==true on TGL. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-2-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-10-24drm/gud: rearrange gud_probe() to prepare for function splittingRuben Wauters1-21/+24
gud_probe() is currently very large and does many things, including pipeline setup and feature detection, as well as having USB functions. This patch re-orders the code in gud_probe() to make it more organised and easier to split apart in the future. Signed-off-by: Ruben Wauters <rubenru09@aol.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20251020140147.5017-1-rubenru09@aol.com/
2025-10-24Merge drm/drm-next into drm-misc-nextThomas Zimmermann184-2295/+4979
Backmerging to get fixes and features of v6.18-rc2. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2025-10-24Merge tag 'drm-xe-fixes-2025-10-23' of ↵Simona Vetter5-69/+49
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes UAPI Changes: - Make madvise autoreset an explicit behavior requested by userspace (Thomas Hellström) Driver Changes: - Drop XE_VMA flag conversion and ensure GPUVA flags are passed around (homas Hellström) - Fix missing wq allocation error checking (Matthew Brost) Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/4p2glnvgifc6osjlvzv23xhsyqhw4diqlfxz54lmg7robv44bi@nwd37zpqfa2l
2025-10-24Merge tag 'drm-intel-fixes-2025-10-23' of ↵Simona Vetter1-12/+13
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Fix panic structure allocation memory leak (Jani) Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/aPojgsvNYOU0tN4U@intel.com
2025-10-24Merge tag 'drm-misc-fixes-2025-10-23' of ↵Simona Vetter3-10/+62
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: panic: - Fix several issues in size calculations panthor: - Fix kernel panic on partial unmap of GPU VA region rockchip: - hdmi: Fix HDP setup Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20251023083449.GA13190@linux-2.fritz.box
2025-10-24Merge tag 'drm-misc-next-2025-10-21' of ↵Simona Vetter100-781/+1552
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.19: UAPI Changes: amdxdna: - Support reading last hardware error Cross-subsystem Changes: dma-buf: - heaps: Create heap per CMA reserved location; Improve user-space documentation Core Changes: atomic: - Clean up and improve state-handling interfaces, update drivers bridge: - Improve ref counting buddy: - Optimize block management Driver Changes: amdxdna: - Fix runtime power management - Support firmware debug output ast: - Set quirks for each chip model atmel-hlcdc: - Set LCDC_ATTRE register in plane disable - Set correct values for plane scaler bochs: - Use vblank timer bridge: - synopsis: Support CEC; Init timer with correct frequency cirrus-qemu: - Use vblank timer imx: - Clean up ivu: - Update JSM API to 3.33.0 - Reset engine on more job errors - Return correct error codes for jobs komeda: - Use drm_ logging functions panel: - edp: Support AUO B116XAN02.0 panfrost: - Embed struct drm_driver in Panfrost device - Improve error handling - Clean up job handling panthor: - Support custom ASN_HASH for mt8196 renesas: - rz-du: Fix dependencies rockchip: - dsi: Add support for RK3368 - Fix LUT size for RK3386 sitronix: - Fix output position when clearing screens qaic: - Support dma-buf exports - Support new firmware's READ_DATA implementation - Replace kcalloc with memdup - Replace snprintf() with sysfs_emit() - Avoid overflows in arithmetics - Clean up - Fixes qxl: - Use vblank timer rockchip: - Clean up mode-setting code vgem: - Fix fence timer deadlock virtgpu: - Use vblank timer Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20251021111837.GA40643@linux.fritz.box
2025-10-24drm/{i915,xe}/fbdev: add intel_fbdev_fb_pitch_align()Jani Nikula4-1/+20
For reasons still unknown, xe appears to require a stride alignment of XE_PAGE_SIZE, and using 64 leads to sporadic failures. Go back to having separate stride alignment for i915 and xe, until the issue is root caused. v2: Add FIXME comment, reference issue with Link (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Maarten Lankhorst <maarten@lankhorst.se> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6220 Fixes: 4a36b339a14a ("drm/xe/fbdev: use the same 64-byte stride alignment as i915") Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/ae51d1e224048bdc87bf7a56d8f5ebd0fbb6a383.1756931441.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20251022161054.708388-1-jani.nikula@intel.com
2025-10-24drm/client: Do not free client memory by defaultThomas Zimmermann1-4/+5
Make no assumption on the allocation of the client's memory. For example, amdgpu stores a client within another data structures, where it cannot be freed by itself. The correct place to free the client's memory is the client's free callback. All existing clients implement this. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20251009132006.45834-5-tzimmermann@suse.de
2025-10-24drm/log: Add free callbackThomas Zimmermann1-3/+11
Free the client memory in the client free callback. Also move the debugging output into the free callback: drm_client_release() puts the reference on the DRM device, so pointers to the device should be considered dangling afterwards. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>> Link: https://lore.kernel.org/r/20251009132006.45834-4-tzimmermann@suse.de
2025-10-24drm/log: Do not hold lock across drm_client_release()Thomas Zimmermann1-1/+1
When calling drm_client_release(), the client is already quiescent. Internal locks should therefore be dropped before the caller releases the client. In the case of the DRM log, concurrency originates from the console or from client events. The console has been unregistered in the previous line. The caller of the unregister callback, drm_log_client_unregister(), holds clientlist_mutex from struct drm_device to protect against concurrent client events. It is therefore safe to release the client without holding locks. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>> Link: https://lore.kernel.org/r/20251009132006.45834-3-tzimmermann@suse.de
2025-10-24drm/client: Add client free callback to unprepare fb_helperThomas Zimmermann13-27/+19
Add free callback to struct drm_client_funcs. Invoke function to free the client memory as part of the release process. Implement free for fbdev emulation. Fbdev emulation allocates and prepares client memory in drm_fbdev_client_setup(). The release happens in fb_destroy from struct fb_ops. Multiple implementations of this callback exist in the various drivers that provide an fbdev implementation. Each of them needs to follow the implementation details of the fbdev setup code. Adding a free callback for the client puts the unprepare and release of the fbdev client in a single place. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # core, msm Acked-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> # omapdrm Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> # gma500 Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20251009132006.45834-2-tzimmermann@suse.de
2025-10-24drm/xe: Check return value of GGTT workqueue allocationMatthew Brost1-0/+3
Workqueue allocation can fail, so check the return value of the GGTT workqueue allocation and fail driver initialization if the allocation fails. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20251022005538.828980-2-matthew.brost@intel.com (cherry picked from commit 1f1314e8e71385bae319e43082b798c11f6648bc) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-24drm/xe/xe3p_xpc: Add MCR steering for NODE and L3BANK rangesMatt Roper4-2/+34
The bspec was originally missing the information related to steering of L3-related ranges. Now that a late-breaking spec update has added the necessary information, implement the steering rules in the code. Note that the sole L3BANK range is the same as the one used on Xe_LPG, so we can re-use the existing table for that MCR type. Bspec: 74418 Fixes: be614ea19dad ("drm/xe/xe3p_xpc: Add MCR steering") Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251021224556.437970-3-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-24drm/xe/xe3p_xpc: Treat all PSMI MCR ranges as "INSTANCE0"Matt Roper2-22/+1
Early versions of the B-spec originally indicated that Xe3p_XPC had two ranges of PSMI registers requiring MCR steering (one starting at 0xB500, one starting at 0xB600), and that reads of registers in these ranges required different grpid values to ensure that a non-terminated value is obtained. A late-breaking spec update has simplified this; both ranges can be safely steered to grpid=0 for reads. Drop the "PSMI19" replication type and related code, and consolidate both register ranges into a single entry in the "INSTANCE0" steering table. Bspec: 74418 Fixes: be614ea19dad ("drm/xe/xe3p_xpc: Add MCR steering") Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251021224556.437970-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-23drm/xe: Use SVM range helpers in PT layerMatthew Brost1-14/+14
We have helpers SVM range start, end, and size. Use them in the PT layer rather than directly looking at the struct. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://lore.kernel.org/r/20251022230122.922382-1-matthew.brost@intel.com
2025-10-23drm/xe/cri: Setup MOCS tableMatt Roper1-0/+26
CRI has a new MOCS table, but uses the same general ops as other Xe2/Xe3 platforms. Bspec: 71582 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patch.msgid.link/20251021-cri-v1-3-bf11e61d9f49@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-23drm/xe/cri: Add CRI platform definitionBalasubramani Vivekanandan2-0/+16
Add platform definition and PCI IDs for Crescent Island. Other platforms use INTEL_VGA_DEVICE since they have a PCI_BASE_CLASS_DISPLAY class. This is not the case for CRI, so just match on devid, which should be sufficient. Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Link: https://lore.kernel.org/r/20251021-cri-v1-1-bf11e61d9f49@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-23drm/xe/migrate: skip bounce buffer path on xe2Matthew Auld1-11/+32
Now that we support MEM_COPY we should be able to use the PAGE_COPY mode, otherwise falling back to BYTE_COPY mode when we have odd sizing/alignment. v2: - Use info.has_mem_copy_instr - Rebase on latest changes. v3 (Matt Brost): - Allow various pitches including 1byte pitch for MEM_COPY Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-8-matthew.auld@intel.com
2025-10-23drm/xe/migrate: support MEM_COPY instructionMatthew Auld5-3/+72
Make this the default on xe2+ when doing a copy. This has a few advantages over the exiting copy instruction: 1) It has a special PAGE_COPY mode that claims to be optimised for page-in/page-out, which is the vast majority of current users. 2) It also has a simple BYTE_COPY mode that supports byte granularity copying without any restrictions. With 2) we can now easily skip the bounce buffer flow when copying buffers with strange sizing/alignment, like for memory_access. But that is left for the next patch. v2 (Matt Brost): - Use device info to check whether device should use the MEM_COPY path. This should fit better with making this a configfs tunable. - And with that also keep old path still functional on xe2 for possible experimentation. - Add a define for PAGE_COPY page-size. v3 (Matt Brost): - Fallback to an actual linear copy for pitch=1. - Also update NVL. BSpec: 57561 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-7-matthew.auld@intel.com
2025-10-23drm/xe/migrate: trim batch buffer sizingMatthew Auld1-3/+3
We have an extra two dwords, but it looks like we should only need one for the extra bb_end. Likely this is just leftover from back when the arb handling was moved into the ring programming. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-6-matthew.auld@intel.com
2025-10-23drm/xe/migrate: fix batch buffer sizingMatthew Auld1-1/+1
In xe_migrate_vram() the copy can straddle page boundaries, so the len might look like a single page, but actually accounting for the offset within the page we will need to emit more than one PTE. Otherwise in some cases the batch buffer will be undersized leading to warnings later. We already have npages so use that instead. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-5-matthew.auld@intel.com
2025-10-23drm/xe/migrate: fix chunk handling for 2M page emitMatthew Auld1-1/+3
On systems with PAGE_SIZE > 4K the chunk will likely be rounded down to zero, if say we have single 2M page, so one huge pte, since we also try to align the chunk to PAGE_SIZE / XE_PAGE_SIZE, which will be 16 on 64K systems. Make the ALIGN_DOWN conditional for 4K PTEs where we can encounter gpu_page_size < PAGE_SIZE. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-4-matthew.auld@intel.com
2025-10-23drm/xe/migrate: rework size restrictions for sram pte emitMatthew Auld1-5/+8
We allow the input size to not be aligned to PAGE_SIZE, which leads to various bugs in build_pt_update_batch_sram() for PAGE_SIZE > 4K systems. For example if ptes is exactly one gpu_page_size then the chunk size is rounded down to zero. The simplest fix looks to be forcing PAGE_SIZE aligned inputs. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-3-matthew.auld@intel.com
2025-10-23drm/xe/migrate: fix offset and len checkMatthew Auld1-3/+4
Restriction here is pitch of 4bytes to match pixel width (32b), and hw restriction where src and dst must be aligned to 64bytes. If any of that is not possible then we need a bounce buffer. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251022163836.191405-2-matthew.auld@intel.com
2025-10-23drm/xe/compat: drop include xe_device.h from i915_drv.hJani Nikula1-1/+0
xe_device.h and xe_device_has_flat_ccs() are no longer needed since commit 3a5c5c472c0e ("drm/i915/display: add HAS_AUX_CCS() feature check"). Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251022121450.452649-2-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-23drm/i915/display: drop a few unnecessary i915_drv.h includesJani Nikula2-2/+2
We've stopped using struct drm_i915_private in intel_fb.c and skl_universal_plane.c, so we can drop the i915_drv.h includes. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251022121450.452649-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-10-23drm/sysfb: Use new CRTC state in begin_fb_accessThomas Zimmermann1-1/+1
Retrieve the CRTC's new state with drm_atomic_get_new_crtc_state() in drm_sysfb_plane_helper_begin_fb_access(). The blit function might be incorrect otherwise. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: cb71de092553 ("drm/sysfb: Lookup blit function during atomic check") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://lore.kernel.org/dri-devel/aPJrs7_u8KcalNsC@intel.com/ Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20251020125227.41308-1-tzimmermann@suse.de
2025-10-22drm/i915/dmc: Set DMC_EVT_CTL_ENABLE for disabled event handlers as wellVille Syrjälä1-11/+11
DMC_EVT_CTL_ENABLE cannot be cleared once set. So currently any event we never enable will have DMC_EVT_CTL_ENABLE cleared, whereas any event which has been enabled even once will have DMC_EVT_CTL_ENABLE set. For that reason assert_dmc_loaded() has a special case to ignore any mismatches in DMC_EVT_CTL_ENABLE. Eliminate the special case by always configuring DMC_EVT_CTL_ENABLE based on the original firmware event definition. Now all event handlers will have DMC_EVT_CTL_ENABLE set, whether or not the event has been enabled in the past. All disabled event handlers will still have the event type set to DMC_EVENT_FALSE so they will not actually trigger despite DMC_EVT_CTL_ENABLE being set. Tested-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251022100718.24803-4-ville.syrjala@linux.intel.com Reviewed-by: Petr Vorel <pvorel@suse.cz> Reviewed-by: Imre Deak <imre.deak@intel.com> Tested-by: Imre Deak <imre.deak@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-04 18:06:45 +0300