summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2026-05-27drm/xe: Restore IDLEDLY regiter on engine resetBalasubramani Vivekanandan
Wa_16023105232 programs the register IDLEDLY. The register is reset whenever the engine is reset. Therefore it should be added to the GuC save-restore register list for it to be restored after reset. Fixes: 7c53ff050ba8 ("drm/xe: Apply Wa_16023105232") Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260522163531.1365540-2-balasubramani.vivekanandan@intel.com Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
2026-05-27drm/dp: Add DSC virtual DPCD quirk for Realtek MST branch deviceImre Deak
The ASUS DC301 USB-C dock containing a Realtek MST branch device supports the DSC decompression functionality on each of the dock's downstream connectors, even though there is no discoverable peer-to-peer virtual device in the MST topology (which the DP Standard requires/suggests to control the DSC functionality on a per-DFP basis). Add the DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD quirk for this branch device as well to enable the DSC decompression functionality on all DFP connectors of the dock, similarly to how this is done for dock's containing older Synaptics branch devices. Cc: Lyude Paul <lyude@redhat.com> Reported-and-tested-by: Shawn C Lee <shawn.c.lee@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260525125516.2794636-1-imre.deak@intel.com
2026-05-27drm/xe/pm: Do early initialization in init_early()Michal Wajdeczko
There is no need nor gain in splitting mutex or list initializations between two init functions as all of this is just pure software state and all this could be done at once. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20260526195452.20545-8-michal.wajdeczko@intel.com
2026-05-27drm/xe/pm: Don't access device in init_early()Michal Wajdeczko
We should separate software-only state initialization from anything else that requires access to the device's hardware. Extract d3cold capability detection into a new function. Add simple kernel-doc for updated functions here. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20260526195452.20545-7-michal.wajdeczko@intel.com
2026-05-27drm/xe: Separate early xe_device initializationMichal Wajdeczko
We would like to initialize more of the xe_device struct also from the kunit code, as it should be safe to use most of the generic drm or xe components without doing any additional tweaks. Separate early xe initialization code to a new function, so it can be reused. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20260526195452.20545-6-michal.wajdeczko@intel.com
2026-05-27drm/xe: Move xe->info.devid|revid initializationMichal Wajdeczko
The xe_info_init_early() is a place where we initialize those of the xe->info fields that do not require any additional hardware probes. Move the initialization of the devid/revid also there, but to avoid breaking the kunit helper, which also calls this function, keep their initialization separate in sub-function so we can easily stub it when running the kunit test. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20260526195452.20545-5-michal.wajdeczko@intel.com
2026-05-27drm/xe: Move xe->info.force_execlist initializationMichal Wajdeczko
The xe_info_init_early() is a place where we initialize those of the xe->info fields that do not require any additional hardware probes. Move the initialization of the force_execlist flag there. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20260526195452.20545-4-michal.wajdeczko@intel.com
2026-05-27drm/xe: Drop unused param from xe_device_create()Michal Wajdeczko
We never used or need anything from the struct pci_device_id there. And while around, add simple kernel-doc for this function. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20260526195452.20545-3-michal.wajdeczko@intel.com
2026-05-27drm/xe: Use raw device ID to find sub-platform descriptorMichal Wajdeczko
We don't need the partially initialized xe_device pointer to find the sub-platform descriptor, as for the descriptor lookup only the device ID is required and it can be obtained directly from the pci_dev. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20260526195452.20545-2-michal.wajdeczko@intel.com
2026-05-27drm/i915/power: drop resume parameter from intel_display_power_init_hw()Jani Nikula
intel_power_domains_resume() calling intel_display_power_init_hw() with the resume parameter is an internal implementation detail. Hide it inside intel_display_power.c, and provide a clean external interface without the parameter. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/63666514d457f548c69ccd35c02f2b8200ca08a1.1779800132.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/i915/power: rename intel_power_domains_*() to intel_display_power_*()Jani Nikula
It's confusing that intel_display_power.[ch] exposes two groups of interfaces, one named intel_power_domains_*() and one intel_display_power_*(). Unify on the latter, based on the file name, but also because it's more generic. This makes the caller side easier to follow. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/8fae4b0e3476aeffb0164215b7e0f0ae1d825f72.1779800132.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/i915/power: make intel_power_domains_{suspend, resume}() staticJani Nikula
intel_power_domains_suspend() and intel_power_domains_resume() are only used inside intel_display_power.c. Make them static. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/bfb5f09794b6b5035839d0182d22980119da2165.1779800132.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/i915/display: stop passing i to for_each_pipe_crtc_modeset_{enable, ↵Jani Nikula
disable}() Refactor for_each_pipe_crtc_modeset_{enable,disable}() and their underlying for_each_crtc_in_masks{,_reverse}() helpers to utilize __UNIQUE_ID() to avoid having to pass the for loop variable to them. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/2270d4a10663bb55d5b16902b02798234f440517.1778659089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/i915/display: stop passing i to for_each_*_intel_crtc_in_state() macrosJani Nikula
None of the for_each_*_intel_crtc_in_state() macros or their users actually need the CRTC index i variable anymore. Remove them. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/edb9dc76cb9cad50622a1f425abaf076d1509888.1778659089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/i915/display: pass struct intel_display to all for_each_intel_crtc*() macrosJani Nikula
Now that the for_each_intel_crtc*() iterator macros primarily use display->pipe_list for iteration, it's more convenient to pass struct intel_display to them directly instead of struct drm_device. Make it so. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/90ec6b84d772a4842d4816efc10042ec4403e996.1778659089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/i915/display: always pass display->drm to for_each_intel_crtc*()Jani Nikula
In preparation for always passing struct intel_display to for_each_intel_crtc*() family of iterators, start off by unifying their usage to always having struct intel_display *display around, and passing display->drm to them. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/447a5b2309e213abb849601727d45b406d440c88.1778659089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/i915/display: switch from drm_for_each_crtc() to for_each_intel_crtc()Jani Nikula
intel_has_pending_fb_unpin() has the last direct user of drm_for_each_crtc() in i915. Switch to for_each_intel_crtc() to ensure pipe order iteration in all cases. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/8ee4320cd15bc35a8b40676faae6db4b33eb50eb.1778659089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/{i915, xe}: move xe_display_flush_cleanup_work() to i915 displayJani Nikula
xe_display_flush_cleanup_work() is a bit of an oddball function in xe display code. There shouldn't be anything this specific or xe specific. While I'm not sure what the correct refactor for the function should be, move it to shared display code for starters, next to the eerily similar but slightly different intel_has_pending_fb_unpin() that is only called from i915 core. The main goal here is to unblock some refactors on for_each_intel_crtc(). v2: Add FIXME comment (Ville) Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260525110553.651208-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-26drm/xe: Assign queue name in time for drm_sched_initTvrtko Ursulin
Currently the queue name is only assigned after the drm scheduler instance has been created. This loses information with all logging or debug workqueue facilities so lets re-order things a bit so the name gets assigned in time. To be able to assign a GuC ID early we split the allocation into reservation and publish phases. First, with the submission state lock held, we reserve the ID in the GuC ID manager, which serves as an authoritative source of truth. Then we can drop the lock and reserve entries in the exec queue lookup XArray. This can be lockless since the NULL entries are invisible both to the kernel and userspace. Only after the queue has been fully created we replace the reserved entries with the queue pointer, which can be done locklessly for single width queues. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260523103418.61832-1-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-05-26drm/panel: fix kernel-doc warning for devm_drm_panel_add()Dongyang Jin
Use the correct kernel-doc notation for struct members to eliminate kernel-doc warnings: Warning: drivers/gpu/drm/drm_panel.c:119 function parameter 'dev' not described in 'devm_drm_panel_add' Warning: drivers/gpu/drm/drm_panel.c:119 function parameter 'dev' not described in 'devm_drm_panel_add' Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605210648.RI4ufD66-lkp@intel.com/ Signed-off-by: Dongyang Jin <jindongyang@kylinos.cn> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260521094545.3039207-1-jindongyang@kylinos.cn
2026-05-26drm/panel: simple: add NEC NL6448BC33-70CSteffen Trumtrar
Add NEC NL6448BC33-70C 10.4" 640x480 LCD module support. Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260518-v7-1-topic-panel-simple-nl6448bc33-v3-2-21ea14a6e835@pengutronix.de
2026-05-26drm/panel: simple: Add AM-1280800W8TZQW-T00HDario Binacchi
Add Ampire, AM-1280800W8TZQW-T00H 10.1" TFT LCD panel timings. Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260515082232.1766586-2-dario.binacchi@amarulasolutions.com
2026-05-26drm/i915: relocate intel_hpd_cancel_work() callJani Nikula
The i915 and xe calls to display, in particular for probe/cleanup/suspend/resume, need to be unified. It does not help to have the related calls scattered around. As a small step forward, relocate the intel_hpd_cancel_work() call from intel_irq_uninstall() to i915_driver_remove(). Note that the other intel_irq_uninstall() call sites don't need the call, as they're on error paths where hotplug hasn't been enabled yet. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260516101852.1373108-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-26drm/bridge: ite-it66121: Select HDMI or DVI mode based on sink typeJavier Martinez Canillas
The driver unconditionally sets the transmission mode to HDMI, which leads to display output not working with DVI monitors. Check the connector's display information sink type to identify the correct mode to configure the bridge. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260523-it66121-fix-dvi-mode-v5-v5-3-33b4468162f9@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-26drm/bridge: ite-it66121: Move .mode_set logic to .atomic_enableJavier Martinez Canillas
Move the existing .mode_set logic to the .atomic_enable callback. The former is deprecated and drivers are supposed to use the latter instead. Also, drop the struct it66121_ctx.connector field because the connector can be accessed through the atomic state and there is no need to store it anymore. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260523-it66121-fix-dvi-mode-v5-v5-2-33b4468162f9@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-26drm/bridge: ite-it66121: Switch to the HDMI connector helpersJavier Martinez Canillas
Instead of open coding the HDMI AVI Infoframes buffer management, use the helpers provided by the HDMI connector framework. Also, add callbacks to implement HDMI Vendor Specific Infoframe and Audio InfoFrame support. The driver was not sending these before, but they are required when using the HDMI helpers. These were implemented following the IT66121 Programming Guide. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260523-it66121-fix-dvi-mode-v5-v5-1-33b4468162f9@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-26drm/i915/psr: Use DC_OFF wake reference to block DC6 on vblank enableJouni Högander
We are observing following warnings: *ERROR* power well DC_off state mismatch (refcount 0/enabled 1) gen9_dc_off_power_well_enabled is considering target state DC_STATE_DISABLE as DC_OFF power well being enabled. Fix this by using wakeref for the purpose. To achieve this we need to modify notification code as well. Currently it is possible that PSR gets notified vblank enable/disable twice on same status. This is currently not a problem as it is just triggering call to intel_display_power_set_target_dc_state with same target state as a parameter. When using wakeref this becomes a problem due to reference counting. Fix this storing vbank status on last notification and use that to ensure there are no more than one notification with same vblank status. v2: ensure there is no subsequent notifications with same status Fixes: aa451abcffb5 ("drm/i915/display: Prevent DC6 while vblank is enabled for Panel Replay") Cc: <stable@vger.kernel.org> # v6.13+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260520104944.239797-2-jouni.hogander@intel.com (cherry picked from commit 35485ac56d878192a3829a58cb26503125ec7104) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-05-26drm/i915/psr: Block DC states on vblank enable when Panel Replay supportedJouni Högander
Currently we are blocking DC states only when Panel Replay is enabled on vblank enable. It may happen that Panel Replay is getting enabled when vblank is already enabled. Fix this by blocking DC states always if Panel Replay is supported. While at it take care of possible dual eDP case by looping all encoders supporting PSR. Fixes: 0c427ac78a1d ("drm/i915/psr: Add interface to notify PSR of vblank enable/disable") Cc: <stable@vger.kernel.org> # v6.16+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260520104944.239797-1-jouni.hogander@intel.com (cherry picked from commit eb5911f990554f7ce947dd53df00c114362e4465) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-05-26drm/i915/color: Fix HDR pre-CSC LUT programming loopPranay Samala
The integer lut programming loop never executes completely due to incorrect condition (i++ > 130). Fix to properly program 129th+ entries for values > 1.0. Cc: <stable@vger.kernel.org> #v6.19 Fixes: 82caa1c8813f ("drm/i915/color: Program Pre-CSC registers") Signed-off-by: Pranay Samala <pranay.samala@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260519075308.383877-1-pranay.samala@intel.com (cherry picked from commit f33862ec3e8849ad7c0a3dd46719083b13ade248) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-05-26drm/i915/aux: use polling when irqs are unavailableMichał Grzelak
PTL with physically disconnected display was observed to have 40s longer execution time when testing xe_fault_injection@xe_guc_mmio_send_recv. The issue has not been seen when reverting commit 40a9f77a28fa ("Revert "drm/i915/dp: change aux_ctl reg read to polling read""). Apparently the configuration suffers from not having AUX enabled when using interrupts. One probable cause can be xe enabling interrupts too late: interrupts need memory allocations which currently can't be done before the display FB takeover is done. As for now, use polling for AUX in case interrupts are unavailable. Fixes: 40a9f77a28fa ("Revert "drm/i915/dp: change aux_ctl reg read to polling read"") Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260416163744.288107-1-michal.grzelak@intel.com (cherry picked from commit 05e0550b65cd1604bd515fbc65f522bce4c10a87) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-05-26drm/i915: Fix potential UAF in TTM object purgeJanusz Krzysztofik
TLDR: The bo->ttm object might be changed by calling ttm_bo_validate(), move casting it to an i915_tt object later to actually get the right pointer. A user reported hitting the following bug under heavy use on DG2: [26620.095550] Oops: general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 1 SMP NOPTI [26620.095556] CPU: 2 UID: 0 PID: 631 Comm: Xorg Not tainted 6.18.8 #1 PREEMPT(lazy) [26620.095558] Hardware name: ASRock B850M Steel Legend WiFi/B850M Steel Legend WiFi, BIOS 3.50 09/18/2025 [26620.095559] RIP: 0010:i915_ttm_purge+0x84/0x100 [i915] [26620.095604] Code: 00 00 00 48 8d 54 24 10 48 89 e6 48 89 fb e8 83 aa ae ff 85 c0 75 6f 48 83 bb a8 01 00 00 00 74 2c 48 8b 45 78 48 85 c0 74 23 <48> 8b 78 20 48 c7 c2 ff ff ff ff 31 f6 e8 7a 73 e3 e0 48 8b 7d 78 [26620.095605] RSP: 0018:ffffc90005fd7430 EFLAGS: 00010282 [26620.095607] RAX: a56b6b6b6b6b6b6b RBX: ffff8881f46c3dc0 RCX: 0000000000000000 [26620.095608] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 00000000ffffffff [26620.095609] RBP: ffff888289610f00 R08: 0000000000000001 R09: ffff88823b022000 [26620.095609] R10: ffff888103029b28 R11: ffff8881fc7f3800 R12: ffff88810b6150d0 [26620.095609] R13: ffff888289610f00 R14: 0000000000000000 R15: ffff8881f46c3dc0 [26620.095610] FS: 00007f1004d86900(0000) GS:ffff88901c858000(0000) knlGS:0000000000000000 [26620.095611] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [26620.095611] CR2: 00007f0fdf489000 CR3: 000000035b0c1000 CR4: 0000000000750ef0 [26620.095612] PKRU: 55555554 [26620.095612] Call Trace: [26620.095615] <TASK> [26620.095615] i915_ttm_move+0x2b9/0x420 [i915] [26620.095642] ? ttm_tt_init+0x65/0x80 [ttm] [26620.095644] ? i915_ttm_tt_create+0xc6/0x150 [i915] [26620.095667] ttm_bo_handle_move_mem+0xb6/0x160 [ttm] [26620.095669] ttm_bo_evict+0x100/0x150 [ttm] [26620.095671] ? preempt_count_add+0x64/0xa0 [26620.095673] ? _raw_spin_lock+0xe/0x30 [26620.095675] ? _raw_spin_unlock+0xd/0x30 [26620.095675] ? i915_gem_object_evictable+0xb7/0xd0 [i915] [26620.095704] ttm_bo_evict_cb+0x6e/0xd0 [ttm] [26620.095705] ttm_lru_walk_for_evict+0xa6/0x200 [ttm] [26620.095708] ttm_bo_alloc_resource+0x185/0x4f0 [ttm] [26620.095709] ? init_object+0x62/0xd0 [26620.095712] ttm_bo_validate+0x7a/0x180 [ttm] [26620.095713] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095714] __i915_ttm_get_pages+0xb0/0x170 [i915] [26620.095737] i915_ttm_get_pages+0x9f/0x150 [i915] [26620.095759] ? i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095786] ? alloc_debug_processing+0xd0/0x100 [26620.095787] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095788] ? i915_vma_instance+0xa0/0x4e0 [i915] [26620.095822] __i915_gem_object_get_pages+0x2f/0x40 [i915] [26620.095848] i915_vma_pin_ww+0x706/0x980 [i915] [26620.095875] ? i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095904] eb_validate_vmas+0x170/0xa00 [i915] [26620.095930] i915_gem_do_execbuffer+0x1201/0x2b40 [i915] [26620.095953] ? alloc_debug_processing+0xd0/0x100 [26620.095954] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095955] ? i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.095977] ? __wake_up_sync_key+0x32/0x50 [26620.095979] ? i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.096001] ? __slab_alloc.isra.0+0x67/0xc0 [26620.096003] i915_gem_execbuffer2_ioctl+0x11a/0x240 [i915] Results from decode_stacktrace.sh pointed to dereference of a file pointer field of a i915 TTM page vector container associated with an object being purged on eviction. That path is taken when the object is marked as no longer needed. Code analysis revealed a possibility of the i915 TTM page vector container being replaced with a new instance inside a function that purges content of the object, should it be still busy. That function is called, indirectly via a more general function that changes the object's placement and caching policy, before the problematic dereference, but still after a pointer to the container is captured, rendering the pointer no longer valid. Fix the issue by capturing the pointer to the container only after its potential replacement. v2: Move the container_of() inside the if block (Sebastian), - a simplified version of the commit description that explains briefly why the change is necessary (Christian). Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/14882 Fixes: 7ae034590ceae ("drm/i915/ttm: add tt shmem backend") Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: stable@vger.kernel.org # v5.17+ Cc: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20260508122612.469227-2-janusz.krzysztofik@linux.intel.com (cherry picked from commit 4462966a93eb185849b7f174f0d0de53476d00a4) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-05-26drm: verisilicon: fix build failure of cursor plane codeIcenowy Zheng
The cursor plane patch was stalled for a too long time that the struct drm_atomic_state parameter of atomic modeset hooks has been changed to struct drm_atomic_commit. Fix this by replacing the parameter's type. All helpers that retrieve information from this struct are also changed so simply replacing the type works. Fixes: 8c4ae2189125 ("drm: verisilicon: add support for cursor planes") Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260525153618.1336239-1-zhengxingda@iscas.ac.cn
2026-05-26Merge tag 'exynos-drm-next-for-v7.2' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next New feature and cleanup for Exynos fbdev - Move fbdev emulation to DRM client buffers . Reuses standard ADDFB2/GEM paths and simplifies cleanup. - Use DRM format helpers for geometry and size . Applies 4CC-based format/pitch/size calculation with stronger checks and PAGE_SIZE alignment. . Sets screen_size and fix.smem_len from actual allocated size. Exynos DRM internal cleanup - Adopt DRM core DMA tracking and drop redundant code . Removes private DMA tracking, exynos_drm_gem_prime_import(), and obsolete iommu_dma_init_domain() stub. - Reduce duplication and tighten local scope . Replaces MAX_FB_BUFFER with DRM_FORMAT_MAX_PLANES. . Drops redundant exynos_drm_gem.size and internalizes local-only helpers. Bug fix for Exynos fbdev behavior - Fix screen_buffer offset handling . Keeps screen_buffer at framebuffer base and avoids applying scanout offset. . Includes Fixes and stable Cc for backporting. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Inki Dae <inki.dae@samsung.com> Link: https://patch.msgid.link/20260521143624.56906-1-inki.dae@samsung.com
2026-05-26Merge tag 'mediatek-drm-next-20260521' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next - 20260521 1. hdmi: Convert DRM_ERROR() to drm_err() 2. Simplify mtk_crtc allocation 3. mtk_dpi: Open-code drm_simple_encoder_init() 4. Convert legacy DRM logging to drm_* helpers in mtk_dsi.c 5. dsi: Add compatible for mt8167-dsi Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patch.msgid.link/20260521140841.5103-1-chunkuang.hu@kernel.org
2026-05-26Merge tag 'drm-xe-next-2026-05-21' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - drm/xe/oa: Fix exec_queue leak on width check in stream open (Shuicheng Lin) - drm/xe/memirq: Drop cached iosys_map for MEMIRQ status (Michal Wajdeczko) - drm/xe/memirq: Drop cached iosys_map for MEMIRQ mask (Michal Wajdeczko) - drm/xe/memirq: Dump all source pages if MSI-X (Michal Wajdeczko) - drm/xe/memirq: Update diagnostic message (Michal Wajdeczko) - drm/xe/memirq: Reduce buffer size (Michal Wajdeczko) - drm/xe/memirq: Use IRQ page from HW engine definition (Michal Wajdeczko) - drm/xe/memirq: Update GuC initialization and IRQ handler (Michal Wajdeczko) - drm/xe/memirq: Make page layout macros private (Michal Wajdeczko) - drm/xe: Add IRQ page to HW engine definition (Michal Wajdeczko) - drm/xe/guc: Use xe_device_is_l2_flush_optimized() (Gustavo Sousa) - drm/xe/multi_queue: Fix secondary queue error case (Niranjana Vishwanathapura) - drm/xe/reg_sr: Do sanity check for MCR vs non-MCR (Gustavo Sousa) - drm/xe/mcr: Extract reg_in_steering_type_ranges() (Gustavo Sousa) - drm/xe/kunit: Use KUNIT_EXPECT_EQ() in xe_wa_gt() (Gustavo Sousa) - drm/xe: Extract xe_hw_engine_setup_reg_lrc() (Gustavo Sousa) - drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN4 (Gustavo Sousa) - drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN1 (Gustavo Sousa) - drm/xe: Define CACHE_MODE_1 as MCR register (Gustavo Sousa) - drm/xe/pf: Fix CFI failure in debugfs access (Mohanram Meenakshisundaram) - drm/xe/vf: Fix signature of print functions (Michal Wajdeczko) - drm/xe: Make drm_driver const (Michal Wajdeczko) - drm/xe/display: Drop xe_display_driver_set_hooks() (Michal Wajdeczko) - drm/xe/display: Add macro with display driver features (Michal Wajdeczko) - drm/xe/display: Add macro with display driver ops (Michal Wajdeczko) - drm/xe/display: Prefer forward declarations (Michal Wajdeczko) - drm/xe/display: Drop xe_display_driver_remove() stub (Michal Wajdeczko) - drm/xe: Drop unused drm/drm_atomic_helper.h include (Michal Wajdeczko) - drm/xe/sriov: Mark NVL as SR-IOV capable (Jakub Kolakowski) - drm/xe/gt_idle: Use NSEC_PER_MSEC instead of float literal (Shuicheng Lin) - drm/xe/gsc: Fix double-free of managed BO in error path (Shuicheng Lin) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/ag9RLujZiYYnSc_F@fedora
2026-05-26Merge tag 'drm-misc-next-2026-05-21' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v7.2-rc1: UAPI Changes: - Add VIRTIO_GPU_F_BLOB_ALIGNMENT flag. Cross-subsystem Changes: - Add common TMDS character rate constants to video/hdmi and use those in bridge drivers. Core Changes: - Fix leak in drm_syncobj_find_fence. - Fix OOB reads related to DP-MST. - Create drm_get_bridge_by_endpoint and convert drivers to use it in preparation of hotplug. Driver Changes: - Assorted bugfixes and cleanups to accel/ethosu, imagination, virtio, rockchip. - Expandable device heap support to amdxdna, bridge/chipone-icn6211. - Add Surface Pro 12 panels. - Convert ite-it6211 to use drm hdmi audio helpers. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/f4034e3c-8290-49e1-9410-dc1f449265f4@linux.intel.com
2026-05-25drm/i915/dp: Detect changes in common link parametersImre Deak
Detect DPRX capability changes without a long HPD or RX_CAP_CHANGED signal and queue a corresponding link params reset. Besides detecting the above unexpected capability changes, this also avoids races between queuing and handling a deferred link params reset. v2: (Ville) - Query/set intel_dp::reset_link_params instead of using helpers for these. - Assert matching types for old/new common rate elements as well. - Add TODO: for adding a struct tracking both rates and number of rates. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260522160514.2628249-5-imre.deak@intel.com
2026-05-25drm/i915/dp: Cache max common lane countImre Deak
Cache the maximum common lane count together with the common link rates. This is safe because the cached value is updated: - during driver probe, before the connector is registered and can be used for mode validation or modesetting - during resume, before output HW state readout can query it - during connector detection, right after updating the sink/link capabilities Caching the value allows detecting max common lane count changes in a follow-up change and keeps the tracking of max common lane count aligned with that of common rates. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260522160514.2628249-4-imre.deak@intel.com
2026-05-25drm/i915/dp: Add helper to set common link paramsImre Deak
Add intel_dp_set_common_link_params() to prepare for updating the maximum common lane count together with the common rates. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260522160514.2628249-3-imre.deak@intel.com
2026-05-25drm/i915/dp: Reset link params after a DPRX capability changeImre Deak
There is no reason to distinguish between DPRX capability changes signaled via a long HPD and via an RX_CAP_CHANGED HPD IRQ. Both cases result in reading out the DPRX capabilities and updating the corresponding sink and common capabilities cached in intel_dp, however only the long HPD resets the link training/recovery state and MST link probe parameters correspondingly. The link training/recovery state may contain reduced maximum link rate/lane count values left over from a previous link training failure. Based on the above after an RX_CAP_CHANGED increased the link rate, lane count parameters the maximum link rate/lane count in the link training/recovery state may remain below these, leaving the newly added valid configurations unavailable for subsequent modesets in an inconsistent way. Handle RX_CAP_CHANGED IRQs the same way as long HPDs and reset the link recovery state and MST link probe parameters in that case as well. v2: Set intel_dp::reset_link_params instead of using a helper for this. (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260522160514.2628249-2-imre.deak@intel.com
2026-05-25drm/hyperv: validate VMBus packet size in receive callbackBerkant Koc
hyperv_receive_sub() reads msg->vid_hdr.type and dispatches into one of four message-type branches without knowing how many bytes the host wrote into hv->recv_buf. The completion path then runs memcpy(hv->init_buf, msg, VMBUS_MAX_PACKET_SIZE), so the consumer that wakes on wait_for_completion_timeout() can read up to 16 KiB of residue from a prior message as if it were the response payload. Pass bytes_recvd into hyperv_receive_sub() and reject any packet that does not cover the pipe + synthvid header. A single switch on msg->vid_hdr.type then computes the type-specific payload size: the three completion-driving types (SYNTHVID_VERSION_RESPONSE, SYNTHVID_RESOLUTION_RESPONSE, SYNTHVID_VRAM_LOCATION_ACK) fall through to a shared exit that requires that size before memcpy/complete, while SYNTHVID_FEATURE_CHANGE validates its own payload and returns before reading is_dirt_needed. Unknown types are dropped. SYNTHVID_RESOLUTION_RESPONSE is variable length: the host fills resolution_count entries, not the full SYNTHVID_MAX_RESOLUTION_COUNT array. Validate the fixed prefix first so resolution_count can be read, bound it against the array, then require only the count-sized array, so the shorter responses the host actually sends are accepted. Only run the sub-handler when vmbus_recvpacket() returned success. The memcpy length is bytes_recvd, which is bounded by VMBUS_MAX_PACKET_SIZE only on a successful receive; on -ENOBUFS vmbus_recvpacket() instead reports the required length, which can exceed hv->recv_buf, so copying bytes_recvd would read and write past the 16 KiB buffers. Gating on the success return keeps the copy bounded. The nonzero-return path is itself a malformed-message case and is now logged rather than silently skipped; channel recovery is not attempted. Rejected packets are reported via drm_err_ratelimited() rather than silently dropped, matching the CoCo-hardened pattern in hv_kvp_onchannelcallback(). Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Cc: stable@vger.kernel.org # 5.14+ Signed-off-by: Berkant Koc <me@berkoc.com> Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/8200dbc199c7a9b75ac7e8af6c748d2189b5ebd5.1779542874.git.me@berkoc.com
2026-05-25drm/hyperv: validate resolution_count and fix WIN8 fallbackBerkant Koc
A SYNTHVID_RESOLUTION_RESPONSE with resolution_count > 64 walks past the supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT] array in the parse loop. Bound resolution_count against the array size, folded into the existing zero-check. When the WIN10 resolution probe fails, the caller in hyperv_connect_vsp() left hv->screen_*_max / preferred_* unpopulated, which sets mode_config.max_width / max_height to 0 and makes drm_internal_framebuffer_create() reject every userspace framebuffer with -EINVAL. The pre-WIN10 branch had the same gap for preferred_width / preferred_height. Use a single post-probe fallback guarded by screen_width_max == 0 so both paths converge on the WIN8 defaults. Signed-off-by: Berkant Koc <me@berkoc.com> Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Cc: stable@vger.kernel.org # 5.14+ Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/6945b22419c7d404b4954a113de2ac9c900dba93.1779542874.git.me@berkoc.com
2026-05-25drm/i915/psr: Allow SCL=0 on platforms with always-on VRR TGAnkit Nautiyal
For Legacy timing generator, if there are no panel replay/sel_update or other SRD constraints, the Set context latency (SCL) window should be at least 1. However, for VRR timing generator the SCL window can be 0. It has other guardband constraints, but that are checked during guardband computation. Allow SCL to be 0 for platforms that have VRR TG always on. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260517142753.2813959-3-ankit.k.nautiyal@intel.com
2026-05-25drm/i915/psr: Simplify the conditions for SCL computationAnkit Nautiyal
'needs_sel_update' is common for both display version branches, so check it once and keep the version specific checks as separate early returns. v2: Split into separate early returns. (Jani) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260517142753.2813959-2-ankit.k.nautiyal@intel.com
2026-05-25drm/i915/display: Handle odd position for planar formats in selective fetchJouni Högander
Since Lunarlake there is no restriction planar planes has to be even positions. Due to this we may end up having odd offset for UV-plane in selective fetch configuration. Add handling for this case into selective fetch configuration. Bspec: 68927 Suggested-by: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Vidya Srinivas <vidya.srinivas@intel.com> Link: https://patch.msgid.link/20260512080022.2527094-1-jouni.hogander@intel.com
2026-05-25drm/i915/psr: Use DC_OFF wake reference to block DC6 on vblank enableJouni Högander
We are observing following warnings: *ERROR* power well DC_off state mismatch (refcount 0/enabled 1) gen9_dc_off_power_well_enabled is considering target state DC_STATE_DISABLE as DC_OFF power well being enabled. Fix this by using wakeref for the purpose. To achieve this we need to modify notification code as well. Currently it is possible that PSR gets notified vblank enable/disable twice on same status. This is currently not a problem as it is just triggering call to intel_display_power_set_target_dc_state with same target state as a parameter. When using wakeref this becomes a problem due to reference counting. Fix this storing vbank status on last notification and use that to ensure there are no more than one notification with same vblank status. v2: ensure there is no subsequent notifications with same status Fixes: aa451abcffb5 ("drm/i915/display: Prevent DC6 while vblank is enabled for Panel Replay") Cc: <stable@vger.kernel.org> # v6.13+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260520104944.239797-2-jouni.hogander@intel.com
2026-05-25drm/i915/psr: Block DC states on vblank enable when Panel Replay supportedJouni Högander
Currently we are blocking DC states only when Panel Replay is enabled on vblank enable. It may happen that Panel Replay is getting enabled when vblank is already enabled. Fix this by blocking DC states always if Panel Replay is supported. While at it take care of possible dual eDP case by looping all encoders supporting PSR. Fixes: 0c427ac78a1d ("drm/i915/psr: Add interface to notify PSR of vblank enable/disable") Cc: <stable@vger.kernel.org> # v6.16+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260520104944.239797-1-jouni.hogander@intel.com
2026-05-25drm/exec, drm/xe, drm/amdgpu: Add an accessor for struct drm_exec::ticketThomas Hellström
Drivers were accessing this drm_exec member directly. While that may seem harmless, it will require action if the drm_exec utility is made a subclass of a dma-resv transaction utility as outlined in the cover-letter. Provide an accessor, drm_exec_ticket() to avoid that. v2: - Fix amdgpu compile error (Intel CI) - Update the commit message. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260520101616.41284-5-thomas.hellstrom@linux.intel.com
2026-05-25drm/exec, drm/xe: Avoid abusing the drm_exec retry pointerThomas Hellström
The xe driver was using the drm_exec retry pointer directly to restart the locking loop after out-of-memory errors. This is relying on undocumented behaviour. Instead add a drm_exec_retry() macro that can be used in this situation, and that also warns if the struct drm_exec is not newly (re-)initialized. Use that macro in xe. v2: - Only allow if the drm_exec context is newly initialized. (Christian) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260520101616.41284-4-thomas.hellstrom@linux.intel.com
2026-05-25drm/exec: Remove the index parameter from drm_exec_for_each_locked_obj[_reverse]Thomas Hellström
Nobody makes any use of it. Possible internal future users can instead use the _index variable. External users shouldn't use it since the array it's pointing into is internal drm_exec state. v2: - Use a unique id for the loop variable (Christian) 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> Link: https://patch.msgid.link/20260520101616.41284-2-thomas.hellstrom@linux.intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-12 01:06:56 +0000