summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-05-22Merge tag 'mediatek-drm-fixes-20260521' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes Mediatek DRM Fixes - 20260521 1. fix sparse warnings Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patch.msgid.link/20260521135649.4681-1-chunkuang.hu@kernel.org
2026-05-22Merge tag 'drm-misc-fixes-2026-05-21' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: amdxdna: - remove mmap and export for ubuf bridge: - chipone-icn6211: managed bridge cleanup - lt66121: acquire reset GPIO - megachips: fix clean up on failed IRQ requests gem: - clean up LRU locking v3d: - fix UAF in error code paths - release GEM-object ref on free'd jobs virtio: - use uninterruptible resv locking in plane updates Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260521071456.GA14644@localhost.localdomain
2026-05-21Merge branch '20260507-ubwc-rework-v4-4-c19593d20c1d@oss.qualcomm.com' of ↵Dmitry Baryshkov
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into HEAD Merge the branch with the soc/qcom changes, required for the next UBWC patches. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-05-21drm/panel-edp: Add LG LP129WT232166 panelJérôme de Bretagne
Add an entry for the eDP LG LP129WT232166 panel used in the Microsoft Surface Pro 9 5G. edid-decode (hex): 00 ff ff ff ff ff ff 00 30 e4 b2 06 a1 25 10 00 00 1f 01 04 a5 1b 12 78 01 ef 70 a7 51 4c a8 26 0e 4f 53 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fd 00 18 78 f1 f1 48 01 0a 20 20 20 20 20 20 00 00 00 fe 00 4c 47 44 5f 4d 50 31 2e 30 5f 0a 20 20 00 00 00 fe 00 4c 50 31 32 39 57 54 32 33 32 31 36 36 01 23 70 13 79 00 00 03 01 14 56 16 01 88 3f 0b 4f 00 07 80 1f 00 7f 07 55 00 47 00 07 00 03 01 14 56 16 01 08 3f 0b 4f 00 07 80 1f 00 7f 07 2b 08 47 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2c 90 Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260520-surface-sp9-5g-for-next-v1-1-9df52552bf87@gmail.com
2026-05-21drm/exynos: Make exynos_drm_framebuffer_init() an internal interfaceThomas Zimmermann
The only caller of exynos_drm_framebuffer_init() is the helper exynos_user_fb_create() from the same source file. Declare the former as static. Tidy up the header's include statements. v2: - clean up the includes in the header file (Chen-Yu) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-05-21drm/exynos: fbdev: Use a DRM client bufferThomas Zimmermann
Replace the internal DRM framebuffer with a DRM client buffer. The client buffer allocates the DRM framebuffer on a file and also uses GEM object handles via the regular ADDFB2 interfaces. Using client-buffer interfaces unifies framebuffer allocation for DRM clients in user space and exynos' internal fbdev emulation. It also simplifies the clean-up side of the fbdev emulation. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-05-21drm/exynos: fbdev: Calculate buffer geometry with format helpersThomas Zimmermann
Replace the geometry and size calculation in exynos' fbdev emulation with DRM format helpers. This consists of a 4CC lookup from the fbdev parameters, format lookup, pitch calculation and size calculation. Then allocate the GEM buffer object for the framebuffer memory from the calculated size. Mmap provides the allocated buffer to user space, so align the buffer size to PAGE_SIZE. Initialize the fields screen_size and fix.smem_len in struct fb_info from the size of the allocated buffer object. This is the real size and can differ from the requested size. v3: - add more error checks to geometry calculations Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-05-21drm/exynos: fbdev: Inline exynos_drm_fbdev_update()Thomas Zimmermann
Inline exynos_drm_fbdev_update() into its only caller. Prepares the code for using DRM client buffers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-05-21drm/exynos: fbdev: Remove offset into screen_bufferThomas Zimmermann
The screen_buffer field in struct fb_info contains the kernel address of the first byte of framebuffer memory. Do not add the display offset. This offset only describes scrolling during scanout. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 19c8b8343d9c ("drm/exynos: fixed overlay data updating.") Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: <stable@vger.kernel.org> # v3.2+
2026-05-21drm/xe/oa: Fix exec_queue leak on width check in stream openShuicheng Lin
In xe_oa_stream_open_ioctl(), when param.exec_q->width > 1 the function returns -EOPNOTSUPP directly, skipping the existing err_exec_q cleanup path. The exec_queue reference obtained by xe_exec_queue_lookup() is leaked. The exec queue holds a reference on the xe_file, which is only dropped during queue teardown. The leaked lookup ref is not on the file's exec_queue xarray, so file close cannot release it. This keeps both the exec queue and the file private state pinned indefinitely. Jump to err_exec_q instead of returning directly so the reference is released. Fixes: f0ed39830e60 ("xe/oa: Fix query mode of operation for OAR/OAC") Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260514203210.593488-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> (cherry picked from commit 339fa0be9e4a5d69fa47e91f4a36574224fb478f) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-05-21drm/exynos/dma: Drop iommu_dma_init_domain() stubChen-Yu Tsai
Commit 1feda5eb77fc ("drm/exynos: Use selected dma_dev default iommu domain instead of a fake one") removed the code around creating a custom IOMMU domain, but forgot to remove the stub. Remove the iommu_dma_init_domain() stub as the function is no longer referenced, and was also made private to the IOMMU DMA code. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-05-21drm/bridge: ite-it66121: Convert to DRM HDMI Audio HelperSen Wang
Convert the IT66121 HDMI bridge driver from manually registering an hdmi-codec platform device to using the DRM HDMI Audio Helper framework via DRM_BRIDGE_OP_HDMI_AUDIO instead. The previous implementation manually allocated hdmi_codec_pdata, registered the platform device, and implemented hdmi_codec_ops callbacks including get_eld. The new approach sets DRM_BRIDGE_OP_HDMI_AUDIO on the bridge, letting the framework handle the codec registration. This also resolves some non-compliance issues with the current audio implementation, such as HDMI audio advertising a non-functional capture stream to userspace. The audio callbacks are converted from hdmi_codec_ops signatures to drm_bridge_funcs hdmi_audio callbacks: - it66121_audio_hw_params -> it66121_hdmi_audio_prepare - it66121_audio_startup -> it66121_hdmi_audio_startup - it66121_audio_shutdown -> it66121_hdmi_audio_shutdown - it66121_audio_mute -> it66121_hdmi_audio_mute_stream The it66121_audio_get_eld, it66121_audio_codec_ops, and it66121_audio_codec_init functions are removed as the framework handles these responsibilities. Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Sen Wang <sen@ti.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260318154636.3230454-1-sen@ti.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-21drm/msm/hdmi: Use the common TMDS char rate constants in 8998 PHYJavier Martinez Canillas
Replace the driver local defines with the shared constants defined in the <linux/hdmi.h> header for the minimum and maximum TMDS character rates. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260520144424.1633354-9-javierm@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-21drm/msm/hdmi: Use the common TMDS char rate constants in 8996 PHYJavier Martinez Canillas
Replace the driver local defines with the shared constants defined in the <linux/hdmi.h> header for the minimum and maximum TMDS character rates. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260520144424.1633354-8-javierm@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-21drm/sun4i: hdmi: Use the common TMDS char rate constantJavier Martinez Canillas
Replace the 165000000 magic number with the shared constant defined in the <linux/hdmi.h> header. The old comment referenced "HDMI <= 1.2" but 165 MHz is actually the maximum TMDS character rate defined by the HDMI 1.0 spec. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260520144424.1633354-7-javierm@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-21drm/sti: hdmi: Use the common TMDS char rate constantsJavier Martinez Canillas
Replace the 340000000 and 165000000 magic numbers with the shared constants defined in the <linux/hdmi.h> header. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260520144424.1633354-6-javierm@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-21drm/bridge: inno-hdmi: Use the common TMDS char rate constantJavier Martinez Canillas
Replace the driver local INNO_HDMI_MIN_TMDS_CLOCK define with the shared constant defined in the <linux/hdmi.h> header. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260520144424.1633354-5-javierm@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-21drm/bridge: dw-hdmi-qp: Use the common TMDS char rate constantJavier Martinez Canillas
Replace the driver local HDMI14_MAX_TMDSCLK define with the shared constant defined in the <linux/hdmi.h> header. The local define incorrectly referenced HDMI 1.4, but the 340 MHz maximum TMDS character rate was actually introduced in HDMI 1.3. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260520144424.1633354-4-javierm@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-21drm/bridge: dw-hdmi: Use the common TMDS char rate constantJavier Martinez Canillas
Replace the driver local HDMI14_MAX_TMDSCLK define with the shared constant defined in the <linux/hdmi.h> header. The local define incorrectly referenced HDMI 1.4, but the 340 MHz maximum TMDS character rate was actually introduced in HDMI 1.3. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260520144424.1633354-3-javierm@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-21drm/rockchip: dw_hdmi: avoid direct dereference of phy->dev.of_nodeVladimir Oltean
The dw_hdmi-rockchip driver validates pixel clock rates against the HDMI PHY's internal clock provider on certain SoCs like RK3328. This is currently achieved by dereferencing hdmi->phy->dev.of_node to obtain the provider node, which violates the Generic PHY API's encapsulation (the goal is for struct phy to be an opaque pointer with a hidden definition, to be interacted with only using API functions or NULL pointer checks, for the case where optional variants of phy_get() did not find a PHY). Refactor dw_hdmi_rockchip_bind() to perform a manual phandle lookup on the "hdmi" PHY index within the controller's DT node. This provides a parallel path to the clock provider's OF node without relying on the internal structure of the struct phy handle. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260505100523.1922388-16-vladimir.oltean@nxp.com
2026-05-21drm: renesas: rz-du: Switch to new VSP APILaurent Pinchart
The vsp1_du_setup_lif() function is deprecated. Use the new vsp1_du_enable() and vsp1_du_disable() functions instead. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by: Biju Das <biju.das.jz@bp.renesas.com> Acked-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260511235637.3468558-5-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-21drm: renesas: rcar-du: Switch to new VSP APILaurent Pinchart
The vsp1_du_setup_lif() function is deprecated. Use the new vsp1_du_enable() and vsp1_du_disable() functions instead. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260511235637.3468558-4-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-21Merge tag 'amd-drm-fixes-7.1-2026-05-20' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-7.1-2026-05-20: amdgpu: - Userq fixes - VPE fix - SMU 15 fix - Misc fixes - VCE fixes - DC bios parsing fixes - DC aux fix - Mode1 reset fix - RAS fixes amdkfd: - Misc fixes radeon: - CS parser fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260520181359.28421-1-alexander.deucher@amd.com
2026-05-21Merge tag 'drm-intel-fixes-2026-05-20' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Fix joiner color pipeline selection [display] (Chaitanya Kumar Borah) - Fix readback for target_rr in Adaptive Sync SDP [dp] (Ankit Nautiyal) - Apply Intel DPCD workaround when SDP on prior line used [psr] (Jouni Högander) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Tvrtko Ursulin <tursulin@igalia.com> Link: https://patch.msgid.link/ag1hKBRKwwv9JOMW@linux
2026-05-21Merge tag 'drm-msm-fixes-2026-05-17' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/msm into drm-fixes Fixes for v7.1: Core: - Fixed bindings for SM8650, SM8750 and Eliza - Don't use UTS_RELEASE directly - Fix typo in clock-names property DPU: - Fixed CWB description on Kaanapali - Fixed scanline strides for YUV UBWC formats - Stopped DSI register dumping to access past the end of region DSI: - Fix dumping unaligned regions GPU: - Fix GMEM_BASE for a6xx gen3 - Fix userspace reachable crash on a2xx-a4xx - Fix sysprof_active for counter collection with IFPC enabled GPUs - Fix shrinker lockdep Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <rob.clark@oss.qualcomm.com> Link: https://patch.msgid.link/CACSVV02cTK7h=d0uqanRE-cj35THDqFjqsTB_2zQV1Mcw77aNw@mail.gmail.com
2026-05-21drm/i915/scaler: eliminate dead codeMichał Grzelak
We short-cut skl_scaler_get_config() when skl_pipe_scaler_get_hw_state() has failed. Remove codepaths that assume scaler_id < 0. Cc: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260509164048.627399-10-michal.grzelak@intel.com
2026-05-21drm/i915/scaler: abstract scaler searching loopMichał Grzelak
Add a helper function hiding the search for scaler_id. Changelog: v2->v3 - keep ctl inside the loop (Ville) - separate impure function call from variable declaration block (Ville) Cc: Nemesa Garg <nemesa.garg@intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260509164048.627399-9-michal.grzelak@intel.com
2026-05-21drm/i915/scaler: unloop scaler readout that is run onceMichał Grzelak
Most of the loop's code is run once because of the continue statement at it's start and break statement at it's end. Kick it out of the loop. While at it, skl_scaler_get_config()'s loop is skipped when specified condition is met and broken when the condition is not met. Equivalently, invert the condition and break the loop. Changelog: v2->v3 - keep ctl inside the loop (Ville) Cc: Nemesa Garg <nemesa.garg@intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260509164048.627399-8-michal.grzelak@intel.com
2026-05-21drm/i915/scaler: remove id in favor of scaler_idMichał Grzelak
id is not really used anywhere in skl_scaler_get_config(). Replace it with scaler_id. Return if no scaler was found. v1->v2 - check if any scaler was found (Ville) Cc: Nemesa Garg <nemesa.garg@intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260509164048.627399-7-michal.grzelak@intel.com
2026-05-21drm/i915/scaler: s/i/scaler_id/ where appropriateMichał Grzelak
Switch from generic iterator naming into more specific scaler_id where it is possible. Cc: Nemesa Garg <nemesa.garg@intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260509164048.627399-6-michal.grzelak@intel.com
2026-05-21drm/i915/casf: rename sumcoeff into sum_coeffMichał Grzelak
Stick to using snake_case in intel_casf_scaler_compute_coeff() where it is possible. Cc: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260509164048.627399-5-michal.grzelak@intel.com
2026-05-21drm/i915: rename t into tapMichał Grzelak
Add more description to the casf_coeff()'s argument and casf_coeff_tap()'s returned value. Do the same for glk_nearest_filter_coef(). v1->v2 - apply the rename to nearest neighbor filter (Ville) Cc: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260509164048.627399-4-michal.grzelak@intel.com
2026-05-21drm/i915/casf: rename *_coef*() into *_coeff*()Michał Grzelak
Stick to the notion of already used *_coeff*() instead of *_coef*(). Rename that way convert_sharpness_coef_binary() and intel_casf_scaler_compute_coef(). v1->v2 - rename intel_casf_scaler_compute_coef() Cc: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260509164048.627399-3-michal.grzelak@intel.com
2026-05-21drm/i915/casf: fix comment typosMichał Grzelak
Remove superfluous whitespace character and fix the spelling. Cc: Nemesa Garg <nemesa.garg@intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260509164048.627399-2-michal.grzelak@intel.com
2026-05-20drm/virtio: use uninterruptible resv lock for plane updatesDeepanshu Kartikey
virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held(): WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list. Both call sites run inside the .atomic_update plane callback, which DRM atomic helpers do not allow to fail (by the time it runs, the commit has been signed off to userspace and there is no clean rollback path). Moving the lock acquisition to .prepare_fb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit. Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses dma_resv_lock() instead of dma_resv_lock_interruptible(). This eliminates the -EINTR failure mode -- the realistic syzbot trigger -- without extending the lock hold across the commit. The helper locks a single BO and rejects nents > 1 with -EINVAL; both fix sites lock exactly one BO. Use it from virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(); check the return value to handle the remaining -ENOMEM case from dma_resv_reserve_fences() by freeing the objs and skipping the plane update for that frame. The framebuffer BOs touched here are not shared with other contexts and lock contention is expected to be brief, so the loss of signal-interruptibility is acceptable. Other callers of virtio_gpu_array_lock_resv() (the ioctl paths) continue to use the interruptible variant. The bug was reported by syzbot, triggered via fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the -ENOMEM branch in dma_resv_reserve_fences(). Reported-by: syzbot+72bd3dd3a5d5f39a0271@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=72bd3dd3a5d5f39a0271 Fixes: 5cfd31c5b3a3 ("drm/virtio: fix virtio_gpu_cursor_plane_update().") Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260519082247.34470-1-kartikey406@gmail.com
2026-05-20drm/virtio: use uninterruptible resv lock for plane updatesDeepanshu Kartikey
virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held(): WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list. Both call sites run inside the .atomic_update plane callback, which DRM atomic helpers do not allow to fail (by the time it runs, the commit has been signed off to userspace and there is no clean rollback path). Moving the lock acquisition to .prepare_fb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit. Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses dma_resv_lock() instead of dma_resv_lock_interruptible(). This eliminates the -EINTR failure mode -- the realistic syzbot trigger -- without extending the lock hold across the commit. The helper locks a single BO and rejects nents > 1 with -EINVAL; both fix sites lock exactly one BO. Use it from virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(); check the return value to handle the remaining -ENOMEM case from dma_resv_reserve_fences() by freeing the objs and skipping the plane update for that frame. The framebuffer BOs touched here are not shared with other contexts and lock contention is expected to be brief, so the loss of signal-interruptibility is acceptable. Other callers of virtio_gpu_array_lock_resv() (the ioctl paths) continue to use the interruptible variant. The bug was reported by syzbot, triggered via fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the -ENOMEM branch in dma_resv_reserve_fences(). Reported-by: syzbot+72bd3dd3a5d5f39a0271@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=72bd3dd3a5d5f39a0271 Fixes: 5cfd31c5b3a3 ("drm/virtio: fix virtio_gpu_cursor_plane_update().") Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260519082247.34470-1-kartikey406@gmail.com
2026-05-20drm/virtio: add VIRTGPU_PARAM_BLOB_ALIGNMENT to paramsSergio Lopez
Add VIRTGPU_PARAM_BLOB_ALIGNMENT as a param that can be read with VIRTGPU_GETPARAM by userspace applications running in the guest to obtain the host's page size and find out the right alignment to be used in shared memory allocations. Signed-off-by: Sergio Lopez <slp@redhat.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260428194450.518296-4-slp@redhat.com
2026-05-20drm/virtio: honor blob_alignment requirementsSergio Lopez
If VIRTIO_GPU_F_BLOB_ALIGNMENT has been negotiated, blob size must be aligned to blob_alignment. Validate this in verify_blob() so that invalid requests are rejected early. Signed-off-by: Sergio Lopez <slp@redhat.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260428194450.518296-3-slp@redhat.com
2026-05-20drm/virtio: support VIRTIO_GPU_F_BLOB_ALIGNMENTSergio Lopez
Support VIRTIO_GPU_F_BLOB_ALIGNMENT, a feature that indicates the device provides a valid blob_alignment field in its configuration, and that both RESOURCE_CREATE_BLOB and RESOURCE_MAP_BLOB requests must be aligned to that value. Signed-off-by: Sergio Lopez <slp@redhat.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260428194450.518296-2-slp@redhat.com
2026-05-20drm/imagination: Fix missing argument in pvr_power_fw_{en,dis}able()Javier Martinez Canillas
Commit 42577ba79fbf ("drm/imagination: Rename FW booted to FW initialised") dropped by mistake the last argument of the functions pvr_power_fw_enable() and pvr_power_fw_disable(), leading to the following compile error: CC [M] drivers/gpu/drm/imagination/pvr_power.o drivers/gpu/drm/imagination/pvr_power.c: In function ‘pvr_power_device_suspend’: drivers/gpu/drm/imagination/pvr_power.c:382:23: error: too few arguments to function ‘pvr_power_fw_disable’; expected 3, have 2 382 | err = pvr_power_fw_disable(pvr_dev, false); | ^~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/imagination/pvr_power.c:93:1: note: declared here 93 | pvr_power_fw_disable(struct pvr_device *pvr_dev, bool hard_reset, bool rpm_suspend) | ^~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/imagination/pvr_power.c: In function ‘pvr_power_device_resume’: drivers/gpu/drm/imagination/pvr_power.c:412:23: error: too few arguments to function ‘pvr_power_fw_enable’; expected 2, have 1 412 | err = pvr_power_fw_enable(pvr_dev); | ^~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/imagination/pvr_power.c:122:1: note: declared here 122 | pvr_power_fw_enable(struct pvr_device *pvr_dev, bool rpm_resume) | ^~~~~~~~~~~~~~~~~~~ make[6]: *** [scripts/Makefile.build:289: drivers/gpu/drm/imagination/pvr_power.o] Error 1 make[5]: *** [scripts/Makefile.build:548: drivers/gpu/drm/imagination] Error 2 make[4]: *** [scripts/Makefile.build:548: drivers/gpu/drm] Error 2 make[3]: *** [scripts/Makefile.build:548: drivers/gpu] Error 2 make[2]: *** [scripts/Makefile.build:548: drivers] Error 2 make[1]: *** [/home/javier/devel/linux/Makefile:2141: .] Error 2 make: *** [Makefile:248: __sub-make] Error 2 Fixes: 42577ba79fbf ("drm/imagination: Rename FW booted to FW initialised") Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20260519131239.1291732-1-javierm@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-20Revert "drm/i915/backlight: Remove try_vesa_interface"Suraj Kandpal
This reverts commit 40d2f5820951dee818d05c14677277048bd85f9f. Removing the try_vesa_interface gate caused a backlight regression on panels whose VBT correctly reports INTEL_BACKLIGHT_DISPLAY_DDI and whose PWM path is the actual backlight control, but whose DPCD optimistically advertises DP_EDP_BACKLIGHT_AUX_ENABLE_CAP / _BRIGHTNESS_AUX_SET_CAP. After the commit such panels silently bind to the VESA AUX backlight funcs; AUX writes complete but the panel ignores them, leaving brightness stuck (no-op backlight). Observed on at least KBL and TGL eDP setups. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260517024709.1016121-1-suraj.kandpal@intel.com
2026-05-20Revert "i915: don't use a vma that didn't match the context VM"Joonas Lahtinen
This reverts commit 5401b9adebc9e5f68df58226f51493ef0e6ceb4d. Superseded by a13edf9b92fc ("drm/i915/gem: Drop check for changed VM in EXECBUF"). Else block is now no-op. Link: https://lore.kernel.org/intel-gfx/CAHk-=whfUM8y3PoFfT21+guKWK-mJmAE=8uLzOT+7HGv5NtqSw@mail.gmail.com/ Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patch.msgid.link/20260518092941.47247-1-joonas.lahtinen@linux.intel.com
2026-05-19drm/i915/dmc_wl: Remove macro HAS_DMC_WAKELOCK()Gustavo Sousa
The macro HAS_DMC_WAKELOCK() is currently only used inside intel_dmc_wl.c and doesn't need to be exposed to the rest of the driver. Furthermore, there is a distinction between the display IP having support for the feature and the driver actually using it, so using HAS_DMC_WAKELOCK() outside of intel_dmc_wl.c would potentially be wrong anyway. Let's drop that macro. If other part of the driver needs to check if the driver is using the DMC wakelock feature, we would need actually to expose the function __intel_dmc_wl_supported(). Since HAS_DMC_WAKELOCK() was kind of self-documenting in the sense that it tells us what display IPs have support for the feature and we are now dropping it, let's also take this opportunity to add a documentation note on the subject. Reviewed-by: Daniel Charles <daniel.charles@intel.com> Link: https://patch.msgid.link/20260429-drop-has_dmc_wakelock-v1-1-62cb6fab1da0@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/i915/bw: Extract get_display_bw_params()Gustavo Sousa
Just like it is done for the platform-specific bandwidth parameters, use a separate function named get_display_bw_params() to return the display IP-specific parameters. This simplifies intel_bw_init_hw() by having just one call for each of the *_get_bw_info() functions. v2: - Prefer to call get_display_bw_params() only once in intel_bw_init_hw() instead of having multiple calls in each of the affected *_get_bw_info() functions. (Jani) v3: - Call get_display_bw_params() only after the check on HAS_DISPLAY(display). (Jani) - Return &gen11_bw_params only if display version is 11. (Matt) v4: - Like done with get_soc_bw_params(), drop drm_WARN() when no display IP is matched. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-5-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/i915/bw: Rename struct intel_sa_info to intel_display_bw_paramsGustavo Sousa
To align with struct intel_platform_bw_params, rename struct intel_sa_info to intel_display_bw_params. Also add comments to contrast their purposes. v2: - Use gen11 and gen12 as prefixes for ICL's and TGL's display-specific parameters variables. (Matt) - Prefer to use "display" instead of "disp" in variable names. (Jani) - Drop the redundant "disp" from the variable names. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-4-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/i915/bw: Deduplicate intel_sa_info instancesGustavo Sousa
Now that intel_sa_info contains bandwidth parameters specific to the display IP, we can drop many duplicates and reuse from previous releases. Let's do that and also simplify intel_bw_init_hw() while at it. v2: - Drop rkl_sa_info and reuse icl_sa_info. (Matt) - Add comment explaining RKL's display's peculiarity on using ICL's parameters. (Matt) - Don't rename xelpdp_sa_info to mtl_sa_info. Renaming of instances to use IP names will be done in upcoming changes. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-3-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/i915/bw: Extract platform-specific parametersGustavo Sousa
We got confirmation from the hardware team that the bandwidth parameters deprogbwlimit and derating are platform-specific and not tied to the display IP. As such, let's make sure that we use platform checks for those. The rest of the members of struct intel_sa_info are tied to the display IP and we will deal with them as a follow-up. v2: - Use good old if-ladder instead of weird-looking pattern "assign ret, check platform, then return ret". (Jani, Matt) - Have a single call site for get_platform_bw_params() and pass the result as parameter to the *_get_bw_info() functions. (Jani) - Avoid using "plat" as abbreviation for "platform". (Jani) - s/_plat_bw_params/_bw_params/, since all of the instances are prefixed with platform names. (Jani) - s/struct intel_platform_bw_params/struct intel_soc_bw_params/. (Matt) - Do not return a default value; prefer to return NULL and intentionally cause a NULL pointer dereference if a platform is missing. (Gustavo) v3: - Call get_soc_bw_params() only after the check on HAS_DISPLAY(display). (Jani) - Combine if-ladder branches for adl_s_bw_params into a single one. (Matt) - Flatten if-ladder by checking for WCL before PTL (as opposed to checking for WCL inside the brace for PTL). (Matt) - Bail out of intel_bw_init_hw() if display version is below 11. (Gustavo) v4: - Drop drm_WARN() when no platform was matched to avoid special-casing DG2 and any other platform that doesn't use SoC-specific parameters. (Jani) - Pass dram_info to get_soc_bw_params() to keep a single call to intel_dram_info(). (Jani) - Don't use 2 separate if-ladders (one for client and another for discrete platforms) and keep a single one for simplicity. (Gustavo) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-2-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/i915/bw: Don't call intel_dram_info() too earlyGustavo Sousa
If we end-up bailing early from intel_bw_init_hw() due to !HAS_DISPLAY(display), the call to intel_dram_info() to initialize dram_info will be meaningless. Move the call to be done after that check. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-1-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/amdgpu: fix handling in amdgpu_userq_createChristian König
Well mostly the same issues the other code had as well: 1. Memory allocation while holding the userq_mutex lock is forbidden! 2. Things were created/started/published in the wrong order. 3. The reset lock was taken in the wrong order and seems to be unecessary in the first place. 4. Error messages on invalid input parameters can spam the logs. 5. Error messages on memory allocation failures are usually superflous as well. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Prike Liang <Prike.Liang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 89e50de5654dbe7a137e03d78629542e17ba7202)
2026-05-19drm/radeon/evergreen_cs: Add missing NULL prefix check in surface checkVitaliy Triang3l Kuzmin
'evergreen_surface_check' is called with a NULL warning prefix when handling potentially recoverable issues or just to compute the alignment requirements, and 'evergreen_surface_check' is called again in case of failure (with the correct prefix, as opposed to NULL), therefore, the initial check must not print a warning, because the surface may be accepted successfully after having been corrected, however if it isn't, the final check will print the warning anyway. The surface check functions specific to array modes already implement this behavior, but the 'evergreen_surface_check' function itself doesn't. This is also supposed to fix the "'%s' directive argument is null [-Werror=format-overflow=]" compiler warning. Fixes: 285484e2d55e ("drm/radeon: add support for evergreen/ni tiling informations v11") Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Vitaliy Triang3l Kuzmin <ml@triang3l.ru> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit e20ea411c99f6968af35fd03e9ee21f70d799144)