summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-04-09drm/xe/xe_sysctrl: Drop redundant endian conversions in mailbox header macrosAnoop Vijay
Remove unnecessary le32_to_cpu() conversions from XE_SYSCTRL_APP_HDR_* macros. Fixes: 37ace5254a2b ("drm/xe/xe_sysctrl: Add ABI and mailbox interface headers") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202604010228.Z20DhK4g-lkp@intel.com/ Signed-off-by: Anoop Vijay <anoop.c.vijay@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://patch.msgid.link/20260408110759.1407342-2-anoop.c.vijay@intel.com
2026-04-09drm/xe: switch xe_pagefault_queue_init() to using bitmap_weighted_or()Yury Norov
The function calls bitmap_or() immediately followed by bitmap_weight(). Switch to using the dedicated bitmap_weighted_or() and save one bitmap traverse. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Yury Norov <ynorov@nvidia.com>
2026-04-09drm/i915/wm: Allow SAGV with multiple pipes on pre-iclVille Syrjälä
There was never any documented reason for limiting SAGV to single active pipe configuration on pre-icl. Allow SAGV with multiple active pipes. At least my CFL NUC seems happy with this when using multiple displays. The machine actually has working SAGV because the memory clock can be observed changing via SA_PERF_STATUS/mchbar:0x5918. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260324134843.2364-10-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2026-04-09drm/i915/wm: Reduce copy-pasta in skl_print_plane_wm_changes()Ville Syrjälä
skl_print_plane_wm_changes() is rather ugly with the copy-pasted massive printk arguments. Reduce the duplication a bit by defining a few FMT/ARG macros. Still ugly, but perhaps a bit less fragile. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260324134843.2364-9-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2026-04-09drm/i915/wm: Verify 'ddb_y' as well as 'ddb'Ville Syrjälä
Verify the pre-icl NV12 Y color plane DDB entry. Thus far we've only verified the RGB/UV DDB entry. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260324134843.2364-8-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2026-04-09drm/i915/wm: Extract skl_ddb_entry_verify()Ville Syrjälä
Extract the DDB entry verification to a helper function. We'll have another caller soon. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260324134843.2364-7-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2026-04-09drm/i915/wm: Extract skl_wm_level_verify()Ville Syrjälä
Reduce duplicated code by extracting the code to verify a single WM level to a common function. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260324134843.2364-6-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2026-04-09drm/i915/wm: Verify the correct plane DDB entryVille Syrjälä
Actually verify the DDB entry for the plane we're looking at instead of always verifying the cursor DDB. Fixes: 7d4561722c3b ("drm/i915: Tweak plane ddb allocation tracking") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260324134843.2364-5-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2026-04-09drm/i915/wm: Consolidate SAGV pipe active/interlace checks to common codeVille Syrjälä
There are no differences between the platforms when considering whether SAGV can be used when the pipe is inactive or using an interlaced mode. Consolidate the checks to common code. Note that we weren't even checking for interlaced modes on TGL+, but since we've previously soft defeatured interlaced modes on TGL+ that was more or less fine. The hardware does still have the capability though, and in case we ever decide to resurrect it having the check seems like a good idea. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260324134843.2364-4-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2026-04-09drm/i915/wm: Don't compute separate SAGV watermarks for RKLVille Syrjälä
RKL is supposed to use the old SKL/ICL method for determining whether the watermarks tolerate SAGV or not, not the TGL+ method. Make it so. BSpec: 49325 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260324134843.2364-3-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2026-04-09drm/i915/wm: Reject SAGV consistently when block_time_us==0Ville Syrjälä
We have three ways for the platform to indicate that SAGV is not supported: - pcode returns zero block time - pcode returns only a single QGV point (icl+) - pcode rejects the SAGV enable/disable command (pre-icl) We don't currently consider all those factors when computing pipe_sagv_reject, meaning we might still try to enable SAGV when we should not. I think one plausible scenario is when pcode returns a zero block time, and all the pipes are disabled. In that case intel_crtc_can_enable_sagv() will return true for all pipes, and thus we might try to enable SAGV despite pcode indicating that it's not supported. Make sure pipe_sagv_reject will consistently reject SAGV when our cached block time is zero. That will cover all the aforementioned mechanisms by which SAGV can be disabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260324134843.2364-2-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2026-04-09drm/bridge: drm_bridge_get/put(): document NULL pointer behaviourLuca Ceresoli
drm_bridge_get and drm_bridge_put() do nothing when they are passed a NULL pointer, and they do so since their initial addition in commit 30d1b37d4c02 ("drm/bridge: add support for refcounting"). This allows simpler code in various places when using these functions. However it's not documented, so it's not clear whether it is part of the API "contract" or just a current implementation detail that might change in the future. There is no visible reason to remove this NULL check, so document it, making it part of the contract, letting users count on it. Reviewed-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20260324-drm-bridge-alloc-getput-document-null-check-v1-1-fb0877c49d7e@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09Merge tag 'topic/step-2026-04-09' of ↵Rodrigo Vivi
https://gitlab.freedesktop.org/drm/i915/kernel into drm-xe-next topic/step to unify xe and i915 on common steppings header and enum Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/cc1ff0a476ff457e88251e22b83c1a45ada11ecc@intel.com
2026-04-09drm/atomic: Increase timeout in drm_atomic_helper_wait_for_vblanks()Thomas Zimmermann
Increase the timeout for vblank events from 100 ms to 1000 ms. This is the same fix as in commit f050da08a4ed ("drm/vblank: Increase timeout in drm_wait_one_vblank()") for another vblank timeout. After merging generic DRM vblank timers [1] and converting several DRM drivers for virtual hardware, these drivers synchronize their vblank events to the display refresh rate. This can trigger timeouts within the DRM framework. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/dri-devel/20250904145806.430568-1-tzimmermann@suse.de/ # [1] Reported-by: syzbot+fcede535e7eb57cf5b43@syzkaller.appspotmail.com Closes: https://lore.kernel.org/dri-devel/69381d6c.050a0220.4004e.0017.GAE@google.com/ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 74afeb812850 ("drm/vblank: Add vblank timer") Link: https://patch.msgid.link/20251209143325.102056-1-tzimmermann@suse.de
2026-04-09drm/omap: dss: convert to of_drm_find_and_get_bridge()Luca Ceresoli
of_drm_find_bridge() is deprecated. Move to its replacement of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it is put when done. omapdss_device_init_output() can take one bridge pointer in out->bridge or two pointers in out->bridge and out->next_bridge. Ensure each has a corresponding drm_bridge_get() and add drm_bridge_put() calls in the cleanup code. Also slightly change the initial code assigning out->panel and out->bridge to ensure and clarify that either out->panel or out->bridge is set in the function prologue, not both. If both were set, the 'if (out->panel){...}' code that follows would overwrite out->bridge without having put the reference. Finally, take a reference in case a panel_bridge is added using drm_panel_bridge_add(). This ensures we always need to put a reference, which came either from of_drm_find_and_get_bridge() or by the drm_panel_bridge_add+drm_bridge_get() branch. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260402-drm-bridge-alloc-getput-drm_of_find_bridge-4-v4-4-421781c8c061@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/kmb/dsi: convert to of_drm_find_and_get_bridge()Luca Ceresoli
of_drm_find_bridge() is deprecated. Move to its replacement of_drm_find_and_get_bridge() which gets a bridge reference. This driver has global variables for the DSI host and DSI device, and code to allocate them on probe but no code to free them when on remove. So it does not at all support removal, and not even multiple instances. For this reason putting the reference would be pointless here. Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260402-drm-bridge-alloc-getput-drm_of_find_bridge-4-v4-2-421781c8c061@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/bridge: analogix_dp: Remove unused struct drm_connector* for ↵Damon Ding
&analogix_dp_plat_data.attach() For both Rockchip and Exynos sides, the struct drm_connector* is never used in callback &analogix_dp_plat_data.attach(). After applying drm_bridge_connector helper, this parameter will no longer be used at all. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260409065301.446670-10-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/bridge: analogix_dp: Remove unused &analogix_dp_plat_data.get_modes()Damon Ding
The callback &analogix_dp_plat_data.get_modes() is not implemented by either Rockchip side or Exynos side. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-9-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/bridge: analogix_dp: Move the color format check to .atomic_check() for ↵Damon Ding
Rockchip platforms For Rockchip platforms, the YUV color formats are currently unsupported. This compatibility check was previously implemented in &analogix_dp_plat_data.get_modes(). Moving color format check to &drm_connector_helper_funcs.atomic_check() would get rid of &analogix_dp_plat_data.get_modes() and be more reasonable than before. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-8-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/bridge: analogix_dp: Remove redundant &analogix_dp_plat_data.skip_connectorDamon Ding
The &analogix_dp_plat_data.skip_connector related check can be replaced by &analogix_dp_plat_data.bridge. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-7-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/exynos: exynos_dp: Apply of-display-mode-bridge to parse the ↵Damon Ding
display-timings node If there is neither a panel nor a bridge, the display timing can be parsed from the display-timings node under the dp node. In order to get rid of &analogix_dp_plat_data.get_modes() and make the codes more consistent, apply DRM of-display-mode-bridge to parse display timings. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-6-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/exynos: exynos_dp: Remove unused &exynos_dp_device.connectorDamon Ding
The &exynos_dp_device.connector is assigned in exynos_dp_bridge_attach() but never used. It should make sense to remove it. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-5-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/exynos: exynos_dp: Remove &exynos_dp_device.ptn_bridgeDamon Ding
Use &analogix_dp_plat_data.bridge instead of &exynos_dp_device.ptn_bridge directly. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-4-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/bridge: Move legacy bridge driver out of imx directory for ↵Damon Ding
multi-platform use As suggested by Dmitry, the DRM legacy bridge driver can be pulled out of imx/ subdir for multi-platform use. The driver is also renamed to make it more generic and suitable for platforms other than i.MX. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588 Link: https://patch.msgid.link/20260409065301.446670-3-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-04-09drm/i915/gem: Drop check for changed VM in EXECBUFJoonas Lahtinen
Since the introduction of d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") it has not been possible for VM to change after context creation so the check will never fail. Sima's analysis: This check was added in f7ce8639f6ff ("drm/i915/gem: Split the context's obj:vma lut into its own mutex") but without any hint in the commit message as to why. In another hunk of that commit there's a hint though in __eb_add_lut: /* user racing with ctx set-vm */ This would mean that this bug was introduced in e0695db7298e ("drm/i915: Create/destroy VM (ppGTT) for use with contexts"), which allowed to change the gem_ctx->vm at runtime, opening up the race that was partially fixed in the earlier referenced commit about a year later. But it cannot be exploited anymore in anything remotely recent because with the introduction of proto-contexts we've made gem_ctx->vm invariant again, exactly to preemptively close all these potential issues. Specifically d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") is the vm specific part of the proto-context work. v3: - Include Sima's analysis and WARN_ON_ONCE v4: - Focus only on latest mainline codebase References: https://lore.kernel.org/all/20260324151741.29338-1-sosohero200@gmail.com/ Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Linus Torvalds <torvalds@linuxfoundation.org> Cc: Simona Vetter <simona.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Cc: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patch.msgid.link/20260409053111.8914-1-joonas.lahtinen@linux.intel.com (cherry picked from commit f6d4afc9ec6a0bc326151b35a7a3369369180079) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-04-09drm/i915/gem: Drop check for changed VM in EXECBUFJoonas Lahtinen
Since the introduction of d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") it has not been possible for VM to change after context creation so the check will never fail. Sima's analysis: This check was added in f7ce8639f6ff ("drm/i915/gem: Split the context's obj:vma lut into its own mutex") but without any hint in the commit message as to why. In another hunk of that commit there's a hint though in __eb_add_lut: /* user racing with ctx set-vm */ This would mean that this bug was introduced in e0695db7298e ("drm/i915: Create/destroy VM (ppGTT) for use with contexts"), which allowed to change the gem_ctx->vm at runtime, opening up the race that was partially fixed in the earlier referenced commit about a year later. But it cannot be exploited anymore in anything remotely recent because with the introduction of proto-contexts we've made gem_ctx->vm invariant again, exactly to preemptively close all these potential issues. Specifically d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") is the vm specific part of the proto-context work. v3: - Include Sima's analysis and WARN_ON_ONCE v4: - Focus only on latest mainline codebase References: https://lore.kernel.org/all/20260324151741.29338-1-sosohero200@gmail.com/ Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Linus Torvalds <torvalds@linuxfoundation.org> Cc: Simona Vetter <simona.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Cc: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patch.msgid.link/20260409053111.8914-1-joonas.lahtinen@linux.intel.com
2026-04-09drm/vram: remove DRM_VRAM_MM_FILE_OPERATIONS from docsThadeu Lima de Souza Cascardo
Commit 02f64b2d8605 ("drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONS") dropped DRM_VRAM_MM_FILE_OPERATIONS in preference for using DEFINE_DRM_GEM_OPS. However, it was not dropped from the kernel docs. Use DEFINE_DRM_GEM_OPS in the illustration on how to define a struct file_operations for such a DRM driver and remove any reference to DRM_VRAM_MM_FILE_OPERATIONS. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 02f64b2d8605 ("drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONS") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260408-drm_gem_vram_helper_docs-v1-1-4d667a768f75@igalia.com
2026-04-09drm/fb-helper: Fix a locking bug in an error pathBart Van Assche
The name of the function __drm_fb_helper_initial_config_and_unlock() and also the comment above that function make it clear that all code paths in this function should unlock fb_helper->lock before returning. Add a mutex_unlock() call in the only code path where it is missing. This has been detected by the Clang thread-safety analyzer. Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Christian König <christian.koenig@amd.com> # radeon Cc: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # msm Cc: Javier Martinez Canillas <javierm@redhat.com> Fixes: 63c971af4036 ("drm/fb-helper: Allocate and release fb_info in single place") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260403205355.1181984-1-bvanassche@acm.org
2026-04-09drm/i915/display: switch to including common step file directlyJani Nikula
Instead of using the proxy intel_step.h in display, just include the common step file directly where needed. This allows us to remove the compat intel_step.h header. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/83b5f13b7f863b9cbc61499bcff22af5cd822a0b.1774875688.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-09drm/xe/step: switch from enum xe_step to intel_step namingJani Nikula
Remove the xe_step macro, and use the enum intel_step name directly. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/87530eaa2052ae4a3c97c7fb87e261d1f73341a7.1774875688.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-09drm/xe/step: switch to the shared step definitions with i915Jani Nikula
Use the shared stepping enums from include/drm/intel/step.h. For now, define xe_step as intel_step to avoid mass renames at the same time. For compat, we can remove the reverse macro. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/8173d9d753b343ba127d86277344248a6b1d0c3f.1774875688.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-09drm/i915/dmc: Reduce wakelock hold timeDibin Moolakadan Subrahmanian
__intel_dmc_wl_release() schedules delayed work which releases the DMC wakelock after a fixed timeout of 50 ms. Until the delayed work runs, the wakelock remains held and prevents entry into deeper DC states. Reduce DMC_WAKELOCK_HOLD_TIME from 50 ms to 5 ms. This should allow the system to enter deeper DC states sooner once MMIO activity settles down. Changes in v2: - Drop detailed explanation from commit message and keep it concise (Suraj Kandpal, Luca Coelho) Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260407105102.3730973-1-dibin.moolakadan.subrahmanian@intel.com
2026-04-09drm/i915/dp: Don't use DP link min bpp for the FRL link bandwidth checkVille Syrjälä
intel_dp_mode_min_link_bpp_x16() gives us the min bpp for the DP link before the PCON, however intel_dp_mode_valid_downstream() is trying to check for sufficient bandwidth on the HDMI FRL link after the PCON. So the use of intel_dp_mode_min_link_bpp_x16() here is incorrect. Presumably even with FRL HDMI still can't go below 8bpc, so we should just use that to give us the minimum required FRL bandwidth. And this needs to account for the sink format (for 4:2:0 sub-sampling) since that is what will be flowing over the HDMI link. Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407183015.16256-1-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
2026-04-09Merge tag 'drm-rust-next-2026-04-06' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/rust/kernel into drm-next DRM Rust changes for v7.1-rc1 (2nd) Nova (Core): - Don't create intermediate (mutable) references to the whole command queue buffer, which is potential undefined behavior. - Add missing padding to the falcon firmware DMA buffer to prevent DMA transfers going out of range of the DMA buffer. - Actually set the default values in the bitfield Default implementation. - Use u32::from_le_bytes() instead of manual bit shifts to parse the PCI ROM header. - Fix a missing colon in the SEC2 boot debug message. Signed-off-by: Dave Airlie <airlied@redhat.com> From: "Danilo Krummrich" <dakr@kernel.org> Link: https://patch.msgid.link/DHN5GMSIBKO2.2AYOLXDU4X19S@kernel.org
2026-04-09Merge drm/drm-next into drm-intel-nextJani Nikula
Backmerge to unblock a topic branch for i915 and xe. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-08Merge drm/drm-next into drm-xe-nextRodrigo Vivi
Sync drm-xe-next with drm-next to unblock some topic branches. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-04-08drm/xe/tlb: Init range tilemask err to zeroJonathan Cavitt
Initialize err = 0 in xe_tlb_inval_range_tilemask_submit to prevent a possible uninitialized value return in the case where the tile_mask somehow doesn't match any available tile ids. This targets a static analysis issue. Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260316162003.64643-2-jonathan.cavitt@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-04-08Use xe_map_resource_to_region helper instead of direct accessTejas Upadhyay
Renaming: The helper function res_to_mem_region is now xe_map_resource_to_region. Abstraction: The patch removes instances where block->private was accessed directly to obtain VRAM region data allowing VRAM manager to own block->private for future use cases. V2(MattB): Add more detail about patch also adjust variable placement Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260407055107.2782450-2-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2026-04-08drm/panthor: Fix kernel-doc in panthor_sched.c so it's visibleSteven Price
Various substructures defined in panthor_sched.c have kernel-doc which is silently ignored because it doesn't include the full path to the member. Fix these issues so that the kernel-doc text is actually output by including the name of the parent. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260408091242.799074-1-steven.price@arm.com
2026-04-08drm/i915/casf: Integrate the sharpness filter properly into the scaler codeVille Syrjälä
The sharpness filter is just a special mode of the pipe scaler. It doesn't warrant all this special casing everywhere. Just integrate it properly into the scaler code so that it's treated no different from the other pipe scaler uses (scaling,centering, YCbCr 4:2:0 output). v2: Also reject scaling_filter vs. sharpness Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-10-ville.syrjala@linux.intel.com
2026-04-08drm/i915/pfit: Call intel_pfit_compute_config() unconditionally on (e)DP/HDMIVille Syrjälä
We now have three different reasons for calling intel_pfit_compute_config(): - actual pfit scaling/centering - YCbCr 4:2:0 output - sharpness filter So let's just call intel_pfit_compute_config() unconditionally from both the DP and HDMI code. Both gmch and ilk+ pfit code should be capable of judging whether anything actually needs the pfit. The only slightly questionable thing in the gmch code is the dithering knob, but that's only a thing on gen2/3 which don't even have HDMI/DP outputs, and so not an issue here. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-9-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: Remove redundant argument from intel_casf_filter_lut_load()Ville Syrjälä
intel_casf_filter_lut_load() can find the crtc from the crtc_state. No need to pass in both. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-8-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: Constify crtc_stateVille Syrjälä
Make the crtc_state const everywhere in the sharpness filter code where it doesn't need to be mutated. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-7-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: Handle CASF in skl_scaler_get_filter_select()Ville Syrjälä
Nuke the duplicate CASF_SCALER_FILTER_SELECT and just have skl_scaler_get_filter_select() return the proper value for sharpness filter use. It is the same "use programmable coefficients" value we already use for the nearest neighbor filtering. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-6-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: Extract scaler_has_casf()Ville Syrjälä
Extract a small helper to determine if the scaler supports the sharpness filter or not. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-5-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: Move the casf state to better placeVille Syrjälä
The casf state is placed inside the 'hw' state for some reason. That is only really meant for things we have to duplicate from the uapi state. The rest can live on its own in our actual state. And since casf is just one aspect of the pfit/pipe scaler the proper place for it seems to be under pch_pfit. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-4-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: Make a proper hw state copy of the sharpness_strengthVille Syrjälä
Make a copy of the uapi.sharpness_strength property value in our hw state. This is how we deal with having proper state for joined pipes. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-3-ville.syrjala@linux.intel.com
2026-04-08drm/i915/casf: s/casf_enable/enable/Ville Syrjälä
The 'casf_enable' boolean is already inside a casf specific structure, so drop the extra 'casf_' namespace from the bool. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407175244.19654-2-ville.syrjala@linux.intel.com
2026-04-08drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeatSebastian Brzezinka
A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <TASK> <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] </TASK> ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15880 Fixes: 058179e72e09 ("drm/i915/gt: Replace hangcheck by heartbeats") Cc: <stable@vger.kernel.org> # v5.5+ Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/d4c1c14255688dd07cc8044973c4f032a8d1559e.1775038106.git.sebastian.brzezinka@intel.com (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-04-08drm/imagination: Minor improvements to job submission code documentationAlessio Belle
Mixed list of clarifications and typo fixes. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20260330-job-submission-fixes-cleanup-v1-8-7de8c09cef8c@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>