summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-05-11drm/panel: Make drm_panel_init() staticAlbert Esteve
Now that all panel drivers use devm_drm_panel_alloc(), there are no external callers of drm_panel_init(). Make it static to prevent new users from bypassing the refcounted allocation path. Remove stale references to drm_panel_init() in kdocs. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-10-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-11drm/panel/startek-kd070fhfid015: Use refcounted allocation in place of ↵Albert Esteve
devm_kzalloc() Move to using the new API devm_drm_panel_alloc() to allocate the panel. In the call to the new API, avoid using explicit type and use __typeof() for more type safety. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-9-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-11drm/panel/truly-nt35597: Use refcounted allocation in place of devm_kzalloc()Albert Esteve
Move to using the new API devm_drm_panel_alloc() to allocate the panel. In the call to the new API, avoid using explicit type and use __typeof() for more type safety. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-8-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-11drm/panel/sharp-ls043t1le01: Use refcounted allocation in place of ↵Albert Esteve
devm_kzalloc() Move to using the new API devm_drm_panel_alloc() to allocate the panel. In the call to the new API, avoid using explicit type and use __typeof() for more type safety. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-7-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-11drm/panel/tdo-tl070wsh30: Use refcounted allocation in place of devm_kzalloc()Albert Esteve
Move to using the new API devm_drm_panel_alloc() to allocate the panel. In the call to the new API, avoid using explicit type and use __typeof() for more type safety. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-6-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-11drm/panel/ilitek-ili9806e: Use refcounted allocation in place of devm_kzalloc()Albert Esteve
Move to using the new API devm_drm_panel_alloc() to allocate the panel. In the call to the new API, avoid using explicit type and use __typeof() for more type safety. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-5-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-11drm/panel/lxd-m9189a: Use refcounted allocation in place of devm_kzalloc()Albert Esteve
Move to using the new API devm_drm_panel_alloc() to allocate the panel. In the call to the new API, avoid using explicit type and use __typeof() for more type safety. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-4-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-11drm/panel/novatek-nt37700f: Use refcounted allocation in place of devm_kzalloc()Albert Esteve
Move to using the new API devm_drm_panel_alloc() to allocate the panel. In the call to the new API, avoid using explicit type and use __typeof() for more type safety. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-3-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-11drm/panel/samsung-s6e63m0: Use refcounted allocation in place of devm_kzalloc()Albert Esteve
Move to using the new API devm_drm_panel_alloc() to allocate the panel. In the call to the new API, avoid using explicit type and use __typeof() for more type safety. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-2-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-11drm/panel/visionox-g2647fb105: Use refcounted allocation in place of ↵Albert Esteve
devm_kzalloc() Move to using the new API devm_drm_panel_alloc() to allocate the panel. In the call to the new API, avoid using explicit type and use __typeof() for more type safety. Also deduplicate the prepare_prev_first assignment that was set both before and after drm_panel_init(). Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-1-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-05-11drm/i915/ddi: Fix cleanup after HDMI connector init failureImre Deak
Perform the missing DDI DP connector cleanup steps after HDMI connector initialization failure during DDI encoder/connector initialization. This fixes the leaked DP MST encoder, AUX state, and connector object. Reported-by: Sashiko <sashiko-bot@kernel.org> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260507065940.2046690-2-imre.deak@intel.com
2026-05-11drm/i915/ddi: Fix cleanup after DP connector init failureImre Deak
Fix the error path during DDI encoder/connector initialization by calling the missing TC port cleanup function. This fixes the leaked TC port state. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260507065940.2046690-1-imre.deak@intel.com
2026-05-11drm/i915/dp: Drop call to intel_panel_fixed_mode() from compute_configAnkit Nautiyal
At the moment, in intel_dp_compute_config(), intel_panel_fixed_mode() is called to check if the panel has any fixed mode or not. If it is an eDP and has the fixed mode, then intel_panel_compute_config() is called. However, the intel_panel_compute_config already checks if the panel supports a fixed mode and returns early if it doesn't. This makes the earlier check in the caller redundant. Remove this extra check for intel_panel_fixed_mode(). Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260430131220.3891497-6-ankit.k.nautiyal@intel.com
2026-05-11drm/i915/intel_sdvo: Drop call to intel_panel_fixed_mode() from compute_configAnkit Nautiyal
Currently, in intel_sdvo_compute_config(), intel_panel_fixed_mode() is called to get the fixed mode. However, since the call is made after intel_panel_compute_config, that copies the selected fixed mode to the adjusted mode, we can directly use the crtc_state->hw.adjusted_mode. So remove the extra call to intel_panel_fixed_mode() and use adjusted mode instead. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260430131220.3891497-5-ankit.k.nautiyal@intel.com
2026-05-11drm/i915/intel_dvo: Drop call to intel_panel_fixed_mode() from compute_configAnkit Nautiyal
The function intel_dvo_compute_config() calls intel_panel_fixed_mode() only to check if there is a valid fixed_mode and based on that it then calls intel_panel_compute_config(). However, since the intel_panel_compute_config() already checks for fixed_mode and we can drop the call to intel_panel_fixed_mode(). Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260430131220.3891497-4-ankit.k.nautiyal@intel.com
2026-05-11drm/i915/intel_panel: Avoid calls to intel_panel_fixed_mode() in mode_validAnkit Nautiyal
Currently, most callers of intel_panel_mode_valid() also call intel_panel_fixed_mode(). This is done either to check for the presence of a fixed mode for the connector or to get the clock of the fixed mode, which is then compared against the max dotclock for the pipe. Since intel_panel_mode_valid() already calls intel_panel_fixed_mode() internally, we can avoid yet another call to intel_panel_fixed_mode() from the caller. Remove the redundant call to intel_panel_fixed_mode() in mode_valid paths. To get the clock for the fixed mode, extend the helper intel_panel_mode_valid() to accept 'target_clock' as an out param. The 'target_clock' can then be used by the callers to check against the max dotclock. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260430131220.3891497-3-ankit.k.nautiyal@intel.com
2026-05-11drm/i915/intel_sdvo: Check fixed_mode->clock against max_dotclock in mode_validAnkit Nautiyal
For LVDS SDVO, mode validation checks the requested mode against the pipe max dotclock, but does not validate the selected fixed mode clock. After intel_panel_mode_valid(), get the fixed mode and validate its clock against the max dotclock. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260430131220.3891497-2-ankit.k.nautiyal@intel.com
2026-05-11drm/i915/hdcp: Skip inactive MST connectors when building stream listSuraj Kandpal
intel_hdcp_required_content_stream() walks every connector on the digital port to populate hdcp_port_data->streams[]. The only filter is connector_status_disconnected, which reflects physical presence on the MST topology, not whether the connector currently drives a stream. On a multi-sink MST setup where only a subset of sinks are modeset, the loop can pick a sibling MST connector that is connected but has no active CRTC / VC payload. intel_conn_to_vcpi() then logs "MST Payload not present" and returns 0, and the bogus StreamID=0 is written to the repeater in RepeaterAuth_Stream_Manage (DPCD 0x693F0). Authentication completes, but the repeater shortly raises LINK_INTEGRITY_FAILURE (RxStatus 0x69493 bit4) because the StreamID does not match any stream on its input. The HDCP check work then tears the link down, the Content Protection property drops back to DESIRED, and userspace observes a spurious HDCP enable failure. Filter the connector iteration to only those with a CRTC assigned in the new atomic state, so intel_conn_to_vcpi() is called for the connector actually being enabled and reads its real VCPI from the MST topology state. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com> Link: https://patch.msgid.link/20260505094022.4064256-1-suraj.kandpal@intel.com
2026-05-09drm/panel-edp: Modify panel name and delay for CMN 0x14d6Terry Hsiao
Correct the panel name for CMN 0x14d6 from N140BGA-EA4 to N140BGA-E54. Additionally, adjust the power sequence delay_200_500_e80_d50 to delay_200_500_e80. CMN N140BGA-E54 00 ff ff ff ff ff ff 00 0d ae d6 14 00 00 00 00 22 21 01 04 95 1f 11 78 03 8e d5 94 57 53 93 27 21 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 da 1d 56 e2 50 00 20 30 2e 1e a6 00 35 ad 10 00 00 1a e7 13 56 e2 50 00 20 30 2e 1e a6 00 35 ad 10 00 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0c 3d ff 0d 3c 7d 11 10 21 7d 00 00 00 00 3d Signed-off-by: Terry Hsiao <terry_hsiao@compal.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260506170607.10813-5-terry_hsiao@compal.corp-partner.google.com
2026-05-09drm/panel-edp: Add CMN N116BCN-EA1, CMN N140HCA-EEK, IVO M140NWFQ R5, IVO ↵Terry Hsiao
R140NWFW R0 The raw EDIDs for each panel: CMN N116BCN-EA1 00 ff ff ff ff ff ff 00 0d ae 69 11 00 00 00 00 0a 24 01 04 95 1a 0e 78 03 67 75 98 59 53 90 27 1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 da 1d 56 e2 50 00 20 30 88 1e ae 00 00 90 10 00 00 1a 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 02 00 0c 3d ff 0d 3c 7d 07 0a 16 7d 00 00 00 00 2e CMN N140HCA-EEK 00 ff ff ff ff ff ff 00 0d ae c7 14 00 00 00 00 2f 23 01 04 a5 1f 11 78 03 28 65 97 59 54 8e 27 1e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 36 36 80 a0 70 38 20 40 30 20 a6 00 35 ad 10 00 00 1a 24 24 80 a0 70 38 20 40 30 20 a6 00 35 ad 10 00 00 1a 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0c 33 ff 0f 3c 96 0c 09 16 96 00 00 00 01 76 70 20 79 02 00 25 01 09 1c 1e 02 1c 1e 02 28 3c 80 81 00 15 74 1a 00 00 03 01 28 3c 00 00 00 00 00 00 3c 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 90 IVO M140NWFQ R5 00 ff ff ff ff ff ff 00 26 cf d5 8c 00 00 00 00 00 20 01 04 a5 1f 11 78 0b 05 f0 97 57 54 8f 28 23 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 9c 36 80 a0 70 38 28 40 18 30 5a 00 35 ae 10 00 00 19 68 24 80 a0 70 38 28 40 18 30 5a 00 35 ae 10 00 00 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0c 33 ff 0f 3c 96 0a 0b 1b 96 00 00 00 01 6c 70 20 79 00 00 25 00 09 ff 21 02 ff 21 02 28 3c 00 81 00 09 68 1a 00 00 01 01 28 3c 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 af IVO R140NWFW R0 00 ff ff ff ff ff ff 00 26 cf e6 8c 00 00 00 00 00 20 01 04 a5 1f 11 78 0b 24 10 97 59 54 8e 27 1e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 38 36 80 a0 70 38 20 40 18 30 3c 00 35 ae 10 00 00 19 22 24 80 a0 70 38 20 40 18 30 3c 00 35 ae 10 00 00 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0f 3d ff 0f 3c 7d 16 11 22 7d 00 00 00 00 24 Signed-off-by: Terry Hsiao <terry_hsiao@compal.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260506170607.10813-4-terry_hsiao@compal.corp-partner.google.com
2026-05-09drm/panel-edp: Add BOE NT140WHM-N4T, BOE NT140WHM-T05, BOE NV140FHM-N40Terry Hsiao
The raw EDIDs for each panel: BOE NT140WHM-N4T 00 ff ff ff ff ff ff 00 09 e5 0d 09 00 00 00 00 01 1e 01 04 95 1f 11 78 03 f8 45 96 57 54 92 28 23 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 a9 1d 56 d0 50 00 24 30 30 20 36 00 35 ae 10 00 00 1a c6 13 56 d0 50 00 24 30 30 20 36 00 35 ae 10 00 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0d 40 ff 0a 3c 7d 11 11 21 7d 00 00 00 00 65 BOE NT140WHM-T05 00 ff ff ff ff ff ff 00 09 e5 85 0b 00 00 00 00 01 21 01 04 95 1f 11 78 03 ea a5 93 5c 58 8f 29 1d 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 c7 1d 56 e2 50 00 1e 30 30 20 36 00 35 ae 10 00 00 1a da 13 56 e2 50 00 1e 30 30 20 36 00 35 ae 10 00 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0d 40 ff 0a 3c 7d 11 11 21 7d 00 00 00 00 4e BOE NV140FHM-N40 00 ff ff ff ff ff ff 00 09 e5 6f 0c 00 00 00 00 19 21 01 04 a5 1f 11 78 03 21 35 97 59 57 8f 29 23 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 c2 37 80 cc 70 38 28 40 6c 30 aa 00 35 ae 10 00 00 1a 2c 25 80 cc 70 38 28 40 6c 30 aa 00 35 ae 10 00 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 0d 36 ff 0a 3c 96 09 0a 19 96 00 00 00 01 57 70 20 79 02 00 25 01 09 8c 2d 02 8c 2d 02 28 3c 80 81 00 10 6f 1a 00 00 03 01 28 3c 00 00 53 4a 53 4a 3c 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e4 90 Signed-off-by: Terry Hsiao <terry_hsiao@compal.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260506170607.10813-3-terry_hsiao@compal.corp-partner.google.com
2026-05-09drm/panel-edp: Add AUO B140XTN07.5, AUO B140HAK03.5, AUO B116XTN02.3, AUO ↵Terry Hsiao
B140XTK02.4, AUO B140HAN07.7 The raw EDIDs for each panel: AUO B140XTN07.5 00 ff ff ff ff ff ff 00 06 af 90 02 00 00 00 00 00 1e 01 04 95 1f 11 78 03 c0 d5 8f 56 58 93 29 20 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ce 1d 56 e2 50 00 1e 30 26 16 36 00 35 ad 10 00 00 18 df 13 56 e2 50 00 1e 30 26 16 36 00 35 ad 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 10 48 ff 0f 3c 7d 48 0f 1b 7d 20 20 20 00 09 AUO B140HAK03.5 00 ff ff ff ff ff ff 00 06 af 9f 3c 00 00 00 00 00 1f 01 04 95 1f 11 78 03 f5 65 8f 55 5a 93 2a 1f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 b0 36 80 a0 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 75 24 80 a0 70 38 24 40 10 10 3e 00 35 ae 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 10 48 ff 0f 3c 7d 14 0e 1e 7d 20 20 20 01 02 70 20 79 02 00 22 00 14 df 22 02 84 7f 07 9f 00 0f 80 0f 00 37 04 23 00 02 00 0d 00 25 00 09 df 22 02 df 22 02 28 3c 80 81 00 10 72 1a 00 00 03 01 28 3c 00 00 60 50 60 50 3c 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 3f 90 AUO B116XTN02.3 00 ff ff ff ff ff ff 00 06 af ba 49 00 00 00 00 00 23 01 04 95 1a 0e 78 02 6b f5 91 55 54 91 27 22 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ce 1d 56 e2 50 00 1e 30 26 16 36 00 00 90 10 00 00 18 df 13 56 e2 50 00 1e 30 26 16 36 00 00 90 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 10 48 ff 0f 3c 7d 50 05 18 7d 20 20 20 00 7f AUO B140XTK02.4 00 ff ff ff ff ff ff 00 06 af a8 67 00 00 00 00 28 20 01 04 95 1f 11 78 03 c0 d5 8f 56 58 93 29 20 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ce 1d 56 e2 50 00 1e 30 26 16 36 00 35 ad 10 00 00 18 df 13 56 e2 50 00 1e 30 26 16 36 00 35 ad 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 10 48 ff 0f 3c 7d 11 23 21 6e 20 20 20 00 8e AUO B140HAN07.7 00 ff ff ff ff ff ff 00 06 af ad c7 00 00 00 00 21 21 01 04 a5 1f 11 78 03 fa 95 92 56 5a 92 2a 20 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 56 37 80 bc 70 38 28 40 10 10 3e 00 35 ae 10 00 00 18 e4 24 80 bc 70 38 28 40 10 10 3e 00 35 ae 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 10 3c ff 0f 3c 96 23 10 28 96 20 20 20 01 66 70 20 79 02 00 22 00 14 5b 29 02 84 7f 07 bb 00 0f 80 0f 00 37 04 27 00 02 00 0d 00 25 01 09 5b 29 02 5b 29 02 28 3c 80 81 00 10 6f 1a 00 00 03 01 28 3c 00 00 8b 11 8b 11 3c 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 c0 90 Signed-off-by: Terry Hsiao <terry_hsiao@compal.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260506170607.10813-2-terry_hsiao@compal.corp-partner.google.com
2026-05-09gpu: nova: Use module names consistentlyCheng-Yang Chou
Update nova/Makefile and nova-core/Makefile so that nova-drm.ko and nova-core.ko are produced, matching the module names set in patch 1. Update drm::DriverInfo with the correct driver name and vendor description. Fix Kconfig help text for both drivers and the debugfs directory name in nova-core to match the new module names. Closes: https://github.com/Rust-for-Linux/linux/issues/1228 Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com> Link: https://patch.msgid.link/20260507185012.1527139-3-yphbchou0911@gmail.com [ Change commit subject to "gpu: nova: Use module names consistently"; slightly adjust commit message. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-09gpu: nova, nova-core: Rename to kebab-caseCheng-Yang Chou
Driver names must follow kernel kebab-case convention before they are exposed as UAPI via driver_override. Rename the nova-drm module from "Nova" to "nova-drm" and the nova-core module from "NovaCore" to "nova-core". Update NOVA_CORE_MODULE_NAME to match the renamed nova-core module. Suggested-by: Gary Guo <gary@garyguo.net> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Acked-by: Timur Tabi <ttabi@nvidia.com> Closes: https://github.com/Rust-for-Linux/linux/issues/1228 Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com> Link: https://patch.msgid.link/20260507185012.1527139-2-yphbchou0911@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-08drm/xe/multi_queue: Whitelist QUEUE_TIMESTAMP registerUmesh Nerlige Ramappa
In a multi-queue use case, when a job is running on the secondary queue, the CTX_TIMESTAMP does not reflect the queues run ticks. Instead, we use the QUEUE TIMESTAMP to check how long the job ran. For user space to see the run ticks for a secondary queue, whitelist the QUEUE_TIMESTAMP register. Compute PR: https://github.com/intel/compute-runtime/pull/923 Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-24-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/multi_queue: Use QUEUE_TIMESTAMP as job timestamp for multi-queueUmesh Nerlige Ramappa
Each queue in a multi queue group has a dedicated timestamp counter. Use this QUEUE TIMESTAMP register to capture the start timestamp for the job. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-23-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/multi_queue: Add trace event for the multi queue timestampUmesh Nerlige Ramappa
Add a trace event for multi queue timestamp capture. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-22-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/multi_queue: Capture queue run times for active queuesUmesh Nerlige Ramappa
If a queue is currently active on the CS, query the QUEUE TIMESTAMP register to get an up to date value of the runtime. To do so, ensure that the primary queue is active and then check if the secondary queue is executing on the CS. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-21-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/lrc: Refactor out engine id to hwe conversionUmesh Nerlige Ramappa
We need to define more helpers that read engine ID specific register, so move that logic outside of get_ctx_timestamp(). Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-20-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/multi_queue: Add helpers to access CS QUEUE TIMESTAMP from lrcUmesh Nerlige Ramappa
In secondary queue LRCs, the QUEUE TIMESTAMP register is saved and restored allowing us to view the individual queue run times. Add helpers to read this value from the LRC. BSpec: 73988 Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-19-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/multi_queue: Store primary LRC and position info in LRCUmesh Nerlige Ramappa
For an LRC belonging to the secondary queue, in order to check if its context group is active, we need to check the LRC of the primary queue. In addition to that we want to compare the secondary queue position to CSMQDEBUG register to check if the queue itself is active. To do so, store primary LRC and position information in the LRC. A note on references involved: - In general the Queue takes a ref on its LRC. - In addition, for multi-queue, a. Primary Queue takes a ref for each Secondary LRC. b. Each Secondary Queue takes a ref to the Primary Queue In the current patch, each LRC in the queue group is storing a pointer to primary LRC. Both primary and secondary LRCs are freed only when primary queue is destroyed. At this time, all secondary queues are already destroyed, so there is no one using secondary LRCs. We should be good without taking any additional references. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-18-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/multi_queue: Refactor check for multi queue support for engine classUmesh Nerlige Ramappa
xe exec queue code is using a check to see if a class of engines support multi queue. This check is also needed by other code, so move it to xe_gt and export it for others. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-17-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/lrc: Refactor xe_lrc_timestamp to simplify logicUmesh Nerlige Ramappa
Use a context_active() helper and simplify the timestamp logic. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-16-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe: Add timestamp_ms to LRC snapshotMatthew Brost
Add a timestamp in milliseconds to the LRC snapshot to make it easier to reason about how long the LRC has been running and the average duration of each job. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-15-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/lrc: Use 64 bit ctx timestamp in the LRC snapshotUmesh Nerlige Ramappa
Use the 64 bit value when available for the context timestamp in the LRC snapshot. Suggested-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-14-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/eustall: Return ENODEV from read if EU stall registers get resetHarish Chegondi
If a reset (GT or engine) happens during EU stall data sampling, all the EU stall registers can get reset to 0. This will result in EU stall data buffers' read and write pointer register values to be out of sync with the cached values. This will result in read() returning invalid data. To prevent this, check the value of a EU stall base register. If it is zero, it indicates a reset may have happened that wiped the register to zero. If this happens, return ENODEV from read() upon which the user space should disable and enable EU stall data sampling or close the fd and open a new fd for a new EU stall data collection session. This patch has been tested by running two IGT tests simultaneously xe_eu_stall and xe_exec_reset. Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Acked-by: Felix Degrood <felix.j.degrood@intel.com> Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/6935698d70b6c7c347ff8b138209d601030c2c9f.1776200094.git.harish.chegondi@intel.com
2026-05-08drm/xe/multi_queue: Refactor CGP_SYNC send pathNiranjana Vishwanathapura
Factor the repeated CGP_SYNC action build-and-send sequence into a new helper guc_exec_queue_send_cgp_sync(). Drop the redundant guc parameter from __register_exec_queue_group() since it can be derived via exec_queue_to_guc(q). Remove xe_guc_exec_queue_group_add() which is now identical to the helper and replace its call site directly. No functional change. Assisted-by: GitHub Copilot:claude-sonnet-4.6 Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260508194428.61819-6-niranjana.vishwanathapura@intel.com
2026-05-08drm/xe/multi_queue: Remove redundant assignment in guc_exec_queue_run_jobNiranjana Vishwanathapura
The 'killed_or_banned_or_wedged = true' assignment is redundant since the variable is never read after that point. Assisted-by: GitHub Copilot:claude-sonnet-4.6 Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260508194428.61819-5-niranjana.vishwanathapura@intel.com
2026-05-08drm/nouveau/gsp: Use kzalloc_flex() for r535 display funcsRosen Penev
struct nvkm_disp_func ends with the user flexible array member. Allocate the r535 display function table with kzalloc_flex() instead of open-coding the size calculation with sizeof(). Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> [dropped nothing-burger sentence from commit message] Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260508052056.1744665-1-rosenp@gmail.com
2026-05-08nouveau/vmm: use kzalloc_flexRosen Penev
Use the proper macro do to these sizeof calculations. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> [fixed style warning from checkpatch] Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260312195529.13002-1-rosenp@gmail.com
2026-05-08drm/nouveau/kms/nvd9-: Remove unused header in crc.cLyude Paul
No functional changes. Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260501215703.820656-2-lyude@redhat.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2026-05-08drm/xe: Make decision to use Xe2-style blitter instructions a feature flagMatt Roper
The blitter engines' MEM_COPY and MEM_SET instructions were added as part of the same hardware change that introduced service copy engines (i.e., BCS1-BCS8) which is why the driver checks for service copy engine presence when deciding whether to use these instructions or the older XY_* instructions. However when making this decision the driver should consider which engines are part of the hardware architecture, not which engines are present/usable on the current device. For graphics IP versions that architecturally include service copy engines (i.e., everything Xe2 and later, plus PVC's Xe_HPC) we should use MEM_SET and MEM_COPY even in if all of the service copy engines wind up getting fused off. I.e., we need to decide based on whether the platform's graphics descriptor contains these engines, rather than whether the usable engine mask contains them. This logic got broken when gt->info.__engine_mask was removed, although in practice that mistake has been harmless so far because there haven't been any hardware SKUs that fuse off all of the service copy engines yet. Replace the incorrect has_service_copy_support() function with a GT feature flag that tracks more accurately whether the new blitter instructions are usable. In addition to fixing incorrect logic if all service copies are fused off, the flag also makes it more obvious what the calling code is trying to do; previously it wasn't terribly obvious why "has service copy engines" was being used as the condition for using different instructions on all copy engine types. The new feature flag is named 'has_xe2_blt_instructions' because we expect this flag to be set for all Xe2 and later platforms (i.e., everything officially supported by the Xe driver). Technically there's also one Xe1-era platform (PVC) that supports these engines/instructions and will set this flag, but this still seems to be the most clear and understandable name for the flag. Fixes: 61549a2ee594 ("drm/xe: Drop __engine_mask") Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patch.msgid.link/20260507-xe2_copy-v1-1-26506381b821@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-05-08drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failureThomas Hellström
When ttm_tt_swapout() fails, the current code calls ttm_resource_add_bulk_move() followed by ttm_resource_move_to_lru_tail() to restore the resource's bulk_move membership. However, ttm_resource_move_to_lru_tail() places the resource at the tail of the LRU list which, relative to the walk cursor's hitch node (placed immediately after the resource when it was yielded), puts the resource *in front of the* the hitch. The next list_for_each_entry_continue() from the hitch finds the same resource again, causing an infinite loop. Fix by deferring del_bulk_move to the success path only. On the success path, TTM_TT_FLAG_SWAPPED has just been set by ttm_tt_swapout() but the resource is still tracked in the bulk_move range, so ttm_resource_del_bulk_move()'s !ttm_resource_unevictable() guard would incorrectly skip the removal. Introduce ttm_resource_del_bulk_move_unevictable() which bypasses that guard. Reported-by: Jatin Kataria <jkataria@netflix.com> Fixes: fc5d96670eb2 ("drm/ttm: Move swapped objects off the manager's LRU list") Cc: Christian König <christian.koenig@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <dri-devel@lists.freedesktop.org> Cc: <stable@vger.kernel.org> # v6.13+ Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Tested-by: Boqun Feng <boqun@kernel.org> Link: https://patch.msgid.link/20260428094442.16985-1-thomas.hellstrom@linux.intel.com
2026-05-08drm/xe: Convert stolen memory over to ttm_range_managerSanjay Yadav
Stolen memory requires physically contiguous allocations for display scanout and compressed framebuffers. The stolen memory manager was sharing the gpu_buddy allocator backend with the VRAM manager, but buddy manages non-contiguous power-of-two blocks making it a poor fit. Stolen memory also has fundamentally different allocation patterns: - Allocation sizes are not power-of-two. Since buddy rounds up to the next power-of-two block size, a ~17MB request can fail even with ~22MB free, because the free space is fragmented across non-fitting power-of-two blocks. - Hardware restrictions prevent using the first 4K page of stolen for certain allocations (e.g., FBC). The display code sets fpfn=1 to enforce this, but when fpfn != 0, gpu_buddy enables GPU_BUDDY_RANGE_ALLOCATION mode which disables the try_harder coalescing path, further reducing allocation success. This combination caused FBC compressed framebuffer (CFB) allocation failures on platforms like NVL/PTL. In case of NVL where stolen memory is ~56MB and the initial plane framebuffer consumes ~34MB at probe time, leaving ~22MB for subsequent allocations. Use ttm_range_man_init_nocheck() to set up a drm_mm-backed TTM resource manager for stolen memory. This reuses the TTM core's ttm_range_manager callbacks, avoiding duplicate implementations. Tested on NVL with a 4K DP display: stolen_mm shows a single ~22MB contiguous free hole after initial plane framebuffer allocation, and FBC successfully allocates its CFB from that region. The corresponding IGT was previously skipped and now passes. v2: - Clarify that stolen memory requires contiguous allocations (Matt B) - Properly handle xe_ttm_resource_visible() for stolen instead of unconditionally returning true (Matt A) v3: - Rebase - Fix xe_display_bo_fbdev_prefer_stolen() to compare in pages, since ttm_range_manager stores stolen->size in pages not bytes (Matt A) v4: - Add kernel-doc for struct xe_ttm_stolen_mgr (Matt B) Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7631 Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Suggested-by: Matthew Auld <matthew.auld@intel.com> Assisted-by: GitHub Copilot:claude-sonnet-4.6 Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260422125502.3088222-2-sanjay.kumar.yadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-05-08Merge drm/drm-next into drm-xe-nextThomas Hellström
Bringing in recent display changes. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-05-08drm/buddy: Integrate lockdep annotations for gpu buddy managerTejas Upadhyay
gpu_buddy APIs are expected to be called with the driver-provided lock held, but there is no runtime enforcement of this contract. Add lockdep annotations to catch locking violations early. Introduce gpu_buddy_driver_set_lock() for the driver to register the lock that protects the buddy manager. Add gpu_buddy_driver_lock_held() assertions to all exported gpu_buddy and drm_buddy APIs that access/modify the manager state. The lock_dep_map field is only compiled in when CONFIG_LOCKDEP is enabled, adding zero overhead to production builds. Wire up xe_ttm_vram_mgr to register its mutex with the buddy manager after initialization. Assisted-by: Copilot:claude-opus-4.6 Suggested-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patch.msgid.link/20260508065544.4049240-2-tejas.upadhyay@intel.com
2026-05-08drm/xe/madvise: Track purgeability with BO-local countersArvind Yadav
xe_bo_recompute_purgeable_state() walks all VMAs of a BO to determine whether the BO can be made purgeable. This makes VMA create/destroy and madvise updates O(n) in the number of mappings. Replace the walk with BO-local counters protected by the BO dma-resv lock: - vma_count tracks the number of VMAs mapping the BO. - willneed_count tracks active WILLNEED holders, including WILLNEED VMAs and active dma-buf exports for non-imported BOs. A DONTNEED BO is promoted back to WILLNEED on a 0->1 transition of willneed_count. A BO is demoted to DONTNEED on a 1->0 transition only when it still has VMAs, preserving the previous behaviour where a BO with no mappings keeps its current madvise state. PURGED remains terminal, preserving the existing "once purged, always purged" rule. Fixes: 4f44961eab84 ("drm/xe/vm: Prevent binding of purged buffer objects") v2: - Use early return for imported BOs in all four helpers to avoid nesting (Matt B). - Group purgeability state into a purgeable sub-struct on struct xe_bo (Matt B). - Reword xe_bo_willneed_put_locked() kernel-doc to explain that a 1->0 transition means all remaining active VMAs are DONTNEED (Matt B). v3: - Move DONTNEED/PURGED reject from vma_lock_and_validate() into xe_vma_create(), gated on attr->purgeable_state == WILLNEED. Fixes vm_bind bypass and partial-unbind rejection on DONTNEED BOs (Matt B). - Drop .check_purged from MAP and REMAP; keep it for PREFETCH and add a comment why (Matt B). - Skip BO validation in vma_lock_and_validate() for non-WILLNEED VMA remnants so cleanup/remap paths do not repopulate DONTNEED/PURGED BOs. Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260506132027.2556046-1-arvind.yadav@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2026-05-08drm: Set old handle to NULL before prime swap in change_handleFrancis, David
There was a potential race condition in change_handle. The ioctl briefly had a single object with two idr entries; a concurrent gem_close could delete the object and remove one of the handles while leaving the other one dangling, which could subsequently be dereferenced for a use-after-free. To fix this, do the same dance that gem_close itself does. (f6cd7daecff5 drm: Release driver references to handle before making it available again) First idr_replace the old handle to NULL. Later, if the prime operations are successful, actually close it. create_tail required a similar dance to avoid a similar problem. (bd46cece51a3 drm/gem: Fix race in drm_gem_handle_create_tail()) It idr_allocs the new handle with NULL, then swaps in the correct object later to avoid races. We don't need to do that here, since the only operations that could race are drm_prime, and change_handle holds the prime lock for the entire duration. v2: cleanups of error paths Signed-off-by: David Francis <David.Francis@amd.com> Co-authored-by: Dave Airlie <airlied@gmail.com> Reported-by: Puttimet Thammasaeng <pwn8official@gmail.com> Tested-by: Vitaly Prosyak <Vitaly.Prosyak@amd.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: stable@vger.kernel.org Cc: Christian Koenig <Christian.Koenig@amd.com> Fixes: 53096728b8910 ("drm: Add DRM prime interface to reassign GEM handle") Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-05-08Merge tag 'amd-drm-fixes-7.1-2026-05-06' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-7.1-2026-05-06: amdgpu: - GFX9 fixes - Hawaii SMU fixes - SDMA4 fix - GART fix - Userq fixes amdkfd: - GPUVM TLB flush fix - Hotplug fix radeon: - Hawaii SMU fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260506154631.1733034-1-alexander.deucher@amd.com
2026-05-08Merge tag 'drm-misc-next-2026-05-07' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v7.2-rc1: UAPI Changes: - Support medium/low power modes in amdxdna. - Support limiting frequency in ivpu. - Document license for drm core uAPI headers. - Add the following DRM formats: P230, Y7, XYYY2101010, T430, XVUY210101010. Cross-subsystem Changes: - Add and improve dt-bindings. - Remove unused dma-fence-array's signal_on_any support. Core Changes: - Do not call drop_master on file close if not master. - Convert drm-bridge and drm/atomic to use drm_printf_indent. - Remove the extra call to drm_connector_attach_encoder after drm_bridge_connector_init(). - Assorted docbook updates. Driver Changes: - Bugfixes in amdxdna, ivpu, mipi-dsi, imagination, nouveau, panthor, bridge/analogix_dp, ipv3, lontium-lt8912b, verisilicon, tve200, etnaviv, panel/focaltech-ota7290b, panel/jadard-jd9365da-h3, bridge/ite-it6263, renesas, xlnx, bridge/cdns-dsi, gma500, bridge/microchip-lvds, mgag200. - Add support for MStar TSUMU88ADT3-LF-1 bridge. - Add support for WaveShare 7, Novatek NT35532, Startek KD070HDFLD092, ChipWealth CH13726A AMOLED, Team Source Display TST070WSNE-196C, Displaytech DT050BTFT-PTS panels. - Improve mipi-dsi shutdown and convert a panasonic panel to use the mipi-dsi wrappers. - Allowing dumping vbios over debugfs in GSP-RM mode. - Update maintainers for ivpu, add reviewer for drm-bridge code and update maintainers for LT8912B DRM HDMI bridge. - Add test pattern support to bridge/ti-sn65dsi83. - Convert vmwgfx to vblank timers. - Add power management to sysfb drm drivers to allow suspend/resume. - Support the aforementioned new drm formats in xlnx/qynqmp. - Fix panel Kconfig dependencies. - Add carveout support for debugging and bringup to amxdna. - Add support for long command tx via videobuffer in bridge/tc358768. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/f73f342d-6efb-416d-81b0-1716bdd98d5f@linux.intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-03 09:41:00 +0000