summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-11-24drm/amd/pm: fix amdgpu_irq enabled counter unbalanced on smu v11.0Yang Wang
v1: - fix amdgpu_irq enabled counter unbalanced issue on smu_v11_0_disable_thermal_alert. v2: - re-enable smu thermal alert to make amdgpu irq counter balance for smu v11.0 if in runpm state [75582.361561] ------------[ cut here ]------------ [75582.361565] WARNING: CPU: 42 PID: 533 at drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c:639 amdgpu_irq_put+0xd8/0xf0 [amdgpu] ... [75582.362211] Tainted: [E]=UNSIGNED_MODULE [75582.362214] Hardware name: GIGABYTE MZ01-CE0-00/MZ01-CE0-00, BIOS F14a 08/14/2020 [75582.362218] Workqueue: pm pm_runtime_work [75582.362225] RIP: 0010:amdgpu_irq_put+0xd8/0xf0 [amdgpu] [75582.362556] Code: 31 f6 31 ff e9 c9 bf cf c2 44 89 f2 4c 89 e6 4c 89 ef e8 db fc ff ff 5b 41 5c 41 5d 41 5e 5d 31 d2 31 f6 31 ff e9 a8 bf cf c2 <0f> 0b eb c3 b8 fe ff ff ff eb 97 e9 84 e8 8b 00 0f 1f 84 00 00 00 [75582.362560] RSP: 0018:ffffd50d51297b80 EFLAGS: 00010246 [75582.362564] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 [75582.362568] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [75582.362570] RBP: ffffd50d51297ba0 R08: 0000000000000000 R09: 0000000000000000 [75582.362573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8e72091d2008 [75582.362576] R13: ffff8e720af80000 R14: 0000000000000000 R15: ffff8e720af80000 [75582.362579] FS: 0000000000000000(0000) GS:ffff8e9158262000(0000) knlGS:0000000000000000 [75582.362582] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [75582.362585] CR2: 000074869d040c14 CR3: 0000001e37a3e000 CR4: 00000000003506f0 [75582.362588] Call Trace: [75582.362591] <TASK> [75582.362597] smu_v11_0_disable_thermal_alert+0x17/0x30 [amdgpu] [75582.362983] smu_smc_hw_cleanup+0x79/0x4f0 [amdgpu] [75582.363375] smu_suspend+0x92/0x110 [amdgpu] [75582.363762] ? gfx_v10_0_hw_fini+0xd5/0x150 [amdgpu] [75582.364098] amdgpu_ip_block_suspend+0x27/0x80 [amdgpu] [75582.364377] ? timer_delete_sync+0x10/0x20 [75582.364384] amdgpu_device_ip_suspend_phase2+0x190/0x450 [amdgpu] [75582.364665] amdgpu_device_suspend+0x1ae/0x2f0 [amdgpu] [75582.364948] amdgpu_pmops_runtime_suspend+0xf3/0x1f0 [amdgpu] [75582.365230] pci_pm_runtime_suspend+0x6d/0x1f0 [75582.365237] ? __pfx_pci_pm_runtime_suspend+0x10/0x10 [75582.365242] __rpm_callback+0x4c/0x190 [75582.365246] ? srso_return_thunk+0x5/0x5f [75582.365252] ? srso_return_thunk+0x5/0x5f [75582.365256] ? ktime_get_mono_fast_ns+0x43/0xe0 [75582.365263] rpm_callback+0x6e/0x80 [75582.365267] rpm_suspend+0x124/0x5f0 [75582.365271] ? srso_return_thunk+0x5/0x5f [75582.365275] ? __schedule+0x439/0x15e0 [75582.365281] ? srso_return_thunk+0x5/0x5f [75582.365285] ? __queue_delayed_work+0xb8/0x180 [75582.365293] pm_runtime_work+0xc6/0xe0 [75582.365297] process_one_work+0x1a1/0x3f0 [75582.365303] worker_thread+0x2ba/0x3d0 [75582.365309] kthread+0x107/0x220 [75582.365313] ? __pfx_worker_thread+0x10/0x10 [75582.365318] ? __pfx_kthread+0x10/0x10 [75582.365323] ret_from_fork+0xa2/0x120 [75582.365328] ? __pfx_kthread+0x10/0x10 [75582.365332] ret_from_fork_asm+0x1a/0x30 [75582.365343] </TASK> [75582.365345] ---[ end trace 0000000000000000 ]--- [75582.365350] amdgpu 0000:05:00.0: amdgpu: Fail to disable thermal alert! [75582.365379] amdgpu 0000:05:00.0: amdgpu: suspend of IP block <smu> failed -22 Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-24drm/amd/amdgpu: reserve vm invalidation engine for uni_mesMichael Chen
Reserve vm invalidation engine 6 when uni_mes enabled. It is used in processing tlb flush request from host. Signed-off-by: Michael Chen <michael.chen@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Shaoyun liu <Shaoyun.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-24drm/edp-panel: Add touchscreen panel used by Lenovo X13sDaniel Thompson
After (checks watch) a little over two years I finally investigated the boot warning on my Thinkpad X13s and it was caused by the conservative timings warning in panel-edp.c . The X13s was sold with a variety of different panel versions; I have the 300 nit multi-touch variant. I have been unable to secure panel documentation so the I copied the timings from NV133WUM-N63. The raw EDID is: 00 ff ff ff ff ff ff 00 09 e5 84 0a 00 00 00 00 1e 1f 01 04 a5 1d 12 78 03 5c 70 a6 51 4c 9c 26 0e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 74 3c 80 a0 70 b0 28 40 30 20 36 00 1e b3 10 00 00 1a 00 00 00 fd 00 28 3c 4b 4b 10 01 0a 20 20 20 20 20 20 00 00 00 fe 00 42 4f 45 20 48 46 0a 20 20 20 20 20 20 00 00 00 fe 00 4e 56 31 33 33 57 55 4d 2d 54 30 31 0a 00 51 Signed-off-by: Daniel Thompson <daniel@riscstar.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20251121-x13s-touchscreen-loopup-v2-1-75b03838e28f@riscstar.com
2025-11-24drm/bridge: simple: add ASL CS5263 DP-to-HDMI bridgeEttore Chimenti
Add support for the transparent ASL CS5263 DP-to-HDMI bridge. Signed-off-by: Ettore Chimenti <ettore.chimenti@linaro.org> Signed-off-by: Georg Gottleuber <ggo@tuxedocomputers.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251121142623.251118-4-ggo@tuxedocomputers.com
2025-11-24drm: sti: fix device leaks at component probeJohan Hovold
Make sure to drop the references taken to the vtg devices by of_find_device_by_node() when looking up their driver data during component probe. Note that holding a reference to a platform device does not prevent its driver data from going away so there is no point in keeping the reference after the lookup helper returns. Fixes: cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure") Cc: stable@vger.kernel.org # 4.16 Cc: Benjamin Gaignard <benjamin.gaignard@collabora.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20250922122012.27407-1-johan@kernel.org Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
2025-11-21drm/xe: Fix conversion from clock ticks to millisecondsHarish Chegondi
When tick counts are large and multiplication by MSEC_PER_SEC is larger than 64 bits, the conversion from clock ticks to milliseconds can go bad. Use mul_u64_u32_div() instead. Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Suggested-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Fixes: 49cc215aad7f ("drm/xe: Add xe_gt_clock_interval_to_ms helper") Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/1562f1b62d5be3fbaee100f09107f3cc49e40dd1.1763408584.git.harish.chegondi@intel.com
2025-11-21drm/i915/cx0: Read out power-down state of both PHY lanes for reversed lanesImre Deak
For a port used with lane reversal enabled the first two TX lanes will be enabled in PHY lane#1 instead of PHY lane#0. At the moment the HW readout will read out the power-down state for these two TX lanes from PHY lane#0 incorrectly. The display HW lane reversal feature (vs. the similar TCSS lane swap) is only used for TypeC legacy mode and for non-TypeC PHYs. Since in both of these cases the display owns both PHY lanes, both of these PHY lanes' state can be read out. Do that to fix cases when lane reversal is used with 1 or 2 active TX lanes. While at it add an assert to the PLL enable function about the above assumption on when lane reversal can be used. Cc: Mika Kahola <mika.kahola@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Fixes: 230d4c748113 ("drm/i915/cx0: Track the Cx0 PHY enabled lane count in the PLL state") Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251120172358.1282765-5-imre.deak@intel.com
2025-11-21drm/i915/cx0: Read out power-down state of both TXs in PHY lane 0Imre Deak
If the number of used lanes is 1 or 2 then the power-down state of both TX lanes in PHY lane 0 should be read out. If 1 lane is used only 1 TX lane will be checked, make sure both TXs are checked in this case. Cc: Mika Kahola <mika.kahola@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Fixes: 230d4c748113 ("drm/i915/cx0: Track the Cx0 PHY enabled lane count in the PLL state") Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251120172358.1282765-4-imre.deak@intel.com
2025-11-21drm/i915/cx0: Use intel_port_to_tc() instead of open coding itImre Deak
Use intel_port_to_tc() in mtl_port_to_pll_id(), instead of open coding the same. v2: s/USe/Use in commit message. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251120172358.1282765-3-imre.deak@intel.com
2025-11-21drm/i915/tc: Add separate intel_tc_phy_port_to_tc() for TC DDI/PHY portsImre Deak
intel_port_to_tc() returns the PORT_TC1..6 -> TC_PORT_1..6 mapping only for DDI ports that are connected to a TypeC PHY. In some cases this mapping is also required for TypeC DDI ports which are not connected to a TypeC PHY. Such DDI ports are the PORT_TC1..4 ports on RKL/ADLS/BMG. Add a separate intel_tc_phy_to_tc() helper to return the mapping for ports connected to a TypeC PHY, and make all the current users - which expect this semantic - call this helper. A follow-up change will need to get the same mapping for TypeC DDI ports not connected to a TypeC PHY, leave intel_port_to_tc() exported for that. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251120172358.1282765-2-imre.deak@intel.com
2025-11-21drm/i915/cx0: Fix port to PLL ID mapping on BMGImre Deak
The intel_port_to_tc() call in mtl_port_to_pll_id() assumed that all TypeC DDI ports are connected to a TypeC PHY. This is not true on BMG where all the ports - including the PORT_TC1..4 TypeC DDI ports - are connected to a non-TypeC PHY. For these ports intel_port_to_tc() returns TC_PORT_NONE, which results in an incorrect port -> PLL ID mapping. Fix this up by using the expected PORT_TC1..4 port -> TC_PORT_1..4 tc_port mapping on BMG as well. Fixes: ca1eda5cd476c ("drm/i915/cx0: Add MTL+ .get_dplls hook") Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251120172358.1282765-1-imre.deak@intel.com
2025-11-21drm/xe/guc_ct: Cleanup ifdef'ryLucas De Marchi
Better split CONFIG_DRM_XE_DEBUG and CONFIG_DRM_XE_DEBUG_GUC optional parts from the main code, creating smaller ct_dead_* and fast_req_* interfaces. Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20251119152157.1675188-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-21drm/xe/guc: Fix stack_depot usageLucas De Marchi
Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: [] BUG: kernel NULL pointer dereference, address: 0000000000000000 [] Workqueue: drm_sched_run_job_work [gpu_sched] [] RIP: 0010:stack_depot_save_flags+0x172/0x870 [] Call Trace: [] <TASK> [] fast_req_track+0x58/0xb0 [xe] Fixes: 16b7e65d299d ("drm/xe/guc: Track FAST_REQ H2Gs to report where errors came from") Tested-by: Sagar Ghuge <sagar.ghuge@intel.com> Cc: stable@vger.kernel.org # v6.17+ Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20251118-fix-debug-guc-v1-1-9f780c6bedf8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-21drm/imagination: Document pvr_device.power memberMatt Coster
Automated testing caught this missing doc comment; add something suitable (and useful). Fixes: 330e76d31697 ("drm/imagination: Add power domain control") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20251106152448.453b53ad@canb.auug.org.au/ Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20251121-device-power-doc-fix-v2-1-3417779f36c7@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-11-21drm/i915/psr: Reject async flips when selective fetch is enabledVille Syrjälä
The selective fetch code doesn't handle asycn flips correctly. There is a nonsense check for async flips in intel_psr2_sel_fetch_config_valid() but that only gets called for modesets/fastsets and thus does nothing for async flips. Currently intel_async_flip_check_hw() is very unhappy as the selective fetch code pulls in planes that are not even async flips capable. Reject async flips when selective fetch is enabled, until someone fixes this properly (ie. disable selective fetch while async flips are being issued). Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251105171015.22234-1-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-11-21drm/xe/guc: Fix resource leak in xe_guc_ct_init_noalloc()Shuicheng Lin
xe_guc_ct_init_noalloc() allocates the CT workqueue and other helpers before it tries to initialize ct->lock. If drmm_mutex_init() fails we currently bail out without releasing those resources because the guc_ct_fini() hasn’t been registered yet. Since destroy_workqueue() in guc_ct_fini() may flush the workqueue, which in turn can take the ct lock, the initialization sequence is restructured to first initialize the ct->lock, then set up all CT state, and finally register guc_ct_fini(). v2: guc_ct_fini() does take ct lock. (Matt) v3: move primelockdep() together with drmm_mutex_init(). (Lucas) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/20251110184522.1581001-2-shuicheng.lin@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-21drm/xe: Fix memory leak when handling pagefault vmaMika Kuoppala
When the pagefault handling code was moved to a new file, an extra drm_exec_init() was added to the VMA path. This call is unnecessary because xe_validation_ctx_init() already performs a drm_exec_init(), resulting in a memory leak reported by kmemleak. Remove the redundant drm_exec_init() from the VMA pagefault handling code. Fixes: fb544b844508 ("drm/xe: Implement xe_pagefault_queue_work") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: intel-xe@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251120161435.3674556-1-mika.kuoppala@linux.intel.com
2025-11-21drm/bridge: sii902x: Fix HDMI detection with DRM_BRIDGE_ATTACH_NO_CONNECTORDevarsh Thakkar
The sii902x driver was caching HDMI detection state in a sink_is_hdmi field and checking it in mode_set() to determine whether to set HDMI or DVI output mode. This approach had two problems: 1. With DRM_BRIDGE_ATTACH_NO_CONNECTOR (used by modern display drivers like TIDSS), the bridge's get_modes() is never called. Instead, the drm_bridge_connector helper calls the bridge's edid_read() and updates the connector itself. This meant sink_is_hdmi was never populated, causing the driver to default to DVI mode and breaking HDMI audio. 2. The mode_set() callback doesn't receive atomic state or connector pointer, making it impossible to check connector->display_info.is_hdmi directly at that point. Fix this by moving the HDMI vs DVI decision from mode_set() to atomic_enable(), where we can access the connector via drm_atomic_get_new_connector_for_encoder(). This works for both connector models: - With DRM_BRIDGE_ATTACH_NO_CONNECTOR: Returns the drm_bridge_connector created by the display driver, which has already been updated by the helper's call to drm_edid_connector_update() - Without DRM_BRIDGE_ATTACH_NO_CONNECTOR (legacy): Returns the connector embedded in sii902x struct, which gets updated by the bridge's own get_modes() Fixes: 3de47e1309c2 ("drm/bridge: sii902x: use display info is_hdmi") Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251030151635.3019864-1-devarsht@ti.com
2025-11-21drm/bridge: it66121: Add minimal it66122 supportNishanth Menon
The IT66122 is a pin compatible replacement for the IT66122. Based on empirical testing, the new device looks to be compatible with IT66121. However due to a lack of public data sheet at this time beyond overall feature list[1] (which seems to add additional features vs ITT66121), it is hard to determine that additional register operations required to enable additional features. So, introduce the device as a new compatible that we will detect based on vid/pid match, with explicit id that can be used to extend the driver capability as information becomes available later on. [1] https://www.ite.com.tw/en/product/cate1/IT66122 Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251029150636.3118628-6-nm@ti.com
2025-11-21drm/bridge: it66121: Use vid/pid to detect the type of chipNishanth Menon
The driver knows exactly which version of the chip is present since the vid/pid is used to enforce a compatibility. Given that some devices like IT66121 has potentially been replaced with IT66122 mid production for many platforms, it makes no sense to use the vid/pid as an enforcement for compatibility. Instead, detect the ID of the actual chip in use by matching the corresponding vid/pid and drop the compatible specific lookup table. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251029150636.3118628-5-nm@ti.com
2025-11-21drm/bridge: it66121: Sort the compatiblesNishanth Menon
Keep the compatibles sorted alpha-numerically. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251029150636.3118628-4-nm@ti.com
2025-11-21drm/bridge: it66121: Drop ftrace like dev_dbg() printsNishanth Menon
Drop the ftrace like dev_dbg() that checkpatch --strict complains about: WARNING: Unnecessary ftrace-like logging - prefer using ftrace + dev_dbg(dev, "%s\n", __func__); WARNING: Unnecessary ftrace-like logging - prefer using ftrace + dev_dbg(dev, "%s\n", __func__); WARNING: Unnecessary ftrace-like logging - prefer using ftrace + dev_dbg(dev, "%s\n", __func__); Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251029150636.3118628-3-nm@ti.com
2025-11-21drm/xe/vga: use the same intel_gmch_vga_set_decode() as i915Jani Nikula
Drop the #ifdef I915, and use the same intel_gmch_vga_set_decode() for both i915 and xe. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/f4121e6c70bac6c26ef3cf51aaf72822f2cb2d54.1763578288.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-21drm/i915: merge soc/intel_gmch.[ch] to display/intel_vga.cJani Nikula
The sole user of the remaining functions in intel_gmch.[ch] is in intel_vga.c. Move everything there. Since intel_gmch.c hasn't been part of xe, use a dummy function relocated from xe_display_misc.c, with #ifdef. This is purely to keep this change non-functional. This allows us to remove soc/intel_gmch.[ch] from i915, compat soc/intel_gmch.h from xe, and xe_display_misc.c from xe. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/b0f853ad7eae686738defa9e8f08a8848df8f226.1763578288.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-21drm/i915/gmch: convert intel_gmch.c to struct intel_displayJani Nikula
Convert intel_gmch.[ch] to struct intel_display. Remove the final dependency on struct drm_i915_private and i915_drv.h. This is in preparation of moving the code under display/. intel_gmch_vga_set_state() is only used internally, make it static while at it. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/a4b317656eef0781d4f53ae337083fb05ce602bc.1763578288.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-21drm/i915/gmch: switch to use pci_bus_{read,write}_config_word()Jani Nikula
Switch to use pci_bus_{read,write}_config_word(), and stop using i915->gmch.pdev reference for the bridge. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/5c432540e254108bf73dbdec347d69ad87682fc9.1763578288.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-21drm/i915/gmch: split out i915_gmch.[ch] from socJani Nikula
Most of the soc/intel_gmch.[ch] code is i915 core specific. Split it out to i915_gmch.[ch]. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/f4f8cc931ef2a5958cebe3ca44d40aedad01626f.1763578288.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-21drm/xe: remove remaining platform checks from compat i915_drv.hJani Nikula
With xe no longer building anything from soc/, we can remove the compat platform checks from i915_drv.h, reducing the file to just the to_i915() pointer conversion helper. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/a9947337f81e04db342bae6af727e4f75f9818ae.1763578288.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-21drm/i915: move intel_rom.[ch] from soc/ to display/Jani Nikula
The sole user of intel_rom.[ch] has always been in display. Move them under display. This allows us to remove the compat soc/intel_rom.h from xe, as well as the Makefile rules to build anything from soc/. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/352ec255a6e9b81c7d1e35d8fbf7018d4049d4d3.1763578288.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-21drm/i915: move dram_info to struct intel_displayJani Nikula
With all of dram code under display, also move dram_info to struct intel_display. This further cleans up struct xe_device from display related members. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/cbbca93003952ea24ae60e66d79d901dba78ccd8.1763578288.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-21drm/i915/dram: convert to struct intel_displayJani Nikula
Convert everything except uncore access to struct intel_display. Converting the graphics version checks to display version checks needs a tweak for display version 13, which have graphics version 12. While at it, convert logging to drm_dbg_kms(). v2: Handle display version 13 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251120161846.3128999-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-21drm/xe: remove MISSING_CASE() from compat i915_utils.hJani Nikula
There are no longer users for MISSING_CASE() in the compat i915_utils.h. Remove it to prevent new users from showing up. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/b967e605ff9d9ad459f3d12a9dfc9244458d83a1.1763578288.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-21drm/i915: move intel_dram.[ch] from soc/ to display/Jani Nikula
The remaining users of intel_dram.[ch] are all in display. Move them under display. This allows us to remove the compat soc/intel_dram.h from xe. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/4c0fbdab989a70d287536a7eafb002dc836ced12.1763578288.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-21drm/i915: split out i915_freq.[ch]Jani Nikula
The i915 core only needs three rather specific functions from soc/intel_dram.[ch]: i9xx_fsb_freq(), ilk_fsb_freq(), and ilk_mem_freq(). Add new i915_freq.[ch] and duplicate those functions for i915 to reduce the dependency on soc/ code. Wile duplication in general is bad, here it's a tradeoff to simplify the i915, xe and display interactions. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/7bac1b194afdc20cd45e625a0a32fcbcd0b1136e.1763578288.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-21drm/i915/edram: extract i915_edram.[ch] for edram detectionJani Nikula
While edram detection ostensibly belongs with the rest of the dram stuff in soc/intel_dram.c, it's only required by i915 core, not display. Extract it to a separate i915_edram.[ch] file. This allows us to drop the edram_size_mb member from struct xe_device. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/612edb7b70755655fbf193ba8af1c539fb93b698.1763578288.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-21Merge tag 'mediatek-drm-next-20251120' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next - 20251120 1. Fix probe resource leaks 2. Add support for MT8195/88 HDMIv2 and DDCv2 3. Fix CCORR mtk_ctm_s31_32_to_s1_n function issue 4. Fix device node reference leak in mtk_dp_dt_parse() Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patch.msgid.link/20251119233202.10034-1-chunkuang.hu@kernel.org
2025-11-21Merge tag 'drm-xe-fixes-2025-11-21' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Fix out-of-bounds access with BIT() (Shuicheng Lin) - Fix kunit test checking wrong condition (Matt Roper) - Drop duplicate kconfig select (Shuicheng Lin) - Fix guc2host irq handler with MSI-X (Venkata Ramana Nayana) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/uadbrmftcud3wg32c6tje7mmfcr7wgmpnkzxwubk6fletahje2@coek2ciunkvz
2025-11-21Merge tag 'amd-drm-fixes-6.18-2025-11-20' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.18-2025-11-20: amdgpu: - DTBCLK gating fix - EDID fetching retry improvements - HDMI HPD debounce filtering - DCN 2.0 cursor fix - DP MST PBN fix - VPE fix - GC 11 fix - PRT fix - MMIO remap page fix - SR-IOV fix radeon: - Fence deadlock fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20251120164110.1077973-1-alexander.deucher@amd.com
2025-11-21drm/gem: Use vmemdup_array_user in drm_gem_objects_lookupTvrtko Ursulin
Use a helper to shrink the code and separate the user and kernel slabs for better security. While at it lets remove the useless debug message. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: André Almeida <andrealmeid@igalia.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251112092732.23584-1-tvrtko.ursulin@igalia.com
2025-11-21Merge tag 'drm-misc-fixes-2025-11-20' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: atomic: - Return error codes on failed blob creation for planes nouveau: - Fix memory leak tegra: - Fix device ref counting - Fix pid ref counting - Revert booting on Pixel C Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251120151308.GA589436@linux.fritz.box
2025-11-21drm/xe/oa: Fix potential UAF in xe_oa_add_config_ioctl()Sanjay Yadav
In xe_oa_add_config_ioctl(), we accessed oa_config->id after dropping metrics_lock. Since this lock protects the lifetime of oa_config, an attacker could guess the id and call xe_oa_remove_config_ioctl() with perfect timing, freeing oa_config before we dereference it, leading to a potential use-after-free. Fix this by caching the id in a local variable while holding the lock. v2: (Matt A) - Dropped mutex_unlock(&oa->metrics_lock) ordering change from xe_oa_remove_config_ioctl() Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6614 Fixes: cdf02fe1a94a7 ("drm/xe/oa/uapi: Add/remove OA config perf ops") Cc: <stable@vger.kernel.org> # v6.11+ Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251118114859.3379952-2-sanjay.kumar.yadav@intel.com (cherry picked from commit 28aeaed130e8e587fd1b73b6d66ca41ccc5a1a31) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-11-21drm/xe/pf: Check for fence error on VRAM save/restoreMichał Winiarski
The code incorrectly assumes that the VRAM save/restore fence is valid. Fix it by checking for error. Fixes: 49cf1b9b609fe ("drm/xe/pf: Handle VRAM migration data as part of PF control") Suggested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251114122339.1791026-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 78ff838a8ab78b3cd438e382ff5204b93db3237e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-11-21drm/xe/pf: Drop the VF VRAM BO reference on successful restoreMichał Winiarski
The reference is only dropped on error. Fix it by adding the missing xe_bo_put(). Fixes: 49cf1b9b609fe ("drm/xe/pf: Handle VRAM migration data as part of PF control") Reported-by: Adam Miszczak <adam.miszczak@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251114100713.1776073-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit dab751b4240f0f0eadea81f93ff0b439379bc6ae) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-11-21drm/xe/pf: Fix kernel-doc warning in migration_save_consumeMichał Winiarski
The kernel-doc for xe_sriov_pf_migration_save_consume() contained multiple "Return:" sections, causing a warning. Fix it by removing the extra line. Fixes: 67df4a5cbc583 ("drm/xe/pf: Add data structures and handlers for migration rings") Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251114134030.1795947-1-michal.winiarski@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 562b0f254d8b1515a1c8d2a650f940d4f719300e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-11-21Merge tag 'drm-msm-next-2025-11-18' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/msm into drm-next Changes for v6.19: GPU: - Gen8 support: A840 (Kaanapali) and X2-85 (Glymur) - A612 support - A few NULL check fixes MDSS: - Added support for Glymur and QCS8300 platforms DPU: - Enabled Quad-Pipe support, unlocking higher resolutions support - Added support for Glymur platform - Documented DPU on QCS8300 platform as supported - Misc small fixes DisplayPort: - Added support for Glymur platform - Added support lame remapping inside DP block - Documented DisplayPort controller on QCS8300 and SM6150/QCS615 as supported Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <rob.clark@oss.qualcomm.com> Link: https://patch.msgid.link/CACSVV00sFi65XrZipHCU3C0bYji7vgu7OgWvLeOQ1Cg475_pUA@mail.gmail.com
2025-11-21Merge tag 'v6.18-rc6' into drm-nextDave Airlie
Linux 6.18-rc6 Backmerge in order to merge msm next Signed-off-by: Dave Airlie <airlied@redhat.com>
2025-11-20drm/xe/oa: Fix potential UAF in xe_oa_add_config_ioctl()Sanjay Yadav
In xe_oa_add_config_ioctl(), we accessed oa_config->id after dropping metrics_lock. Since this lock protects the lifetime of oa_config, an attacker could guess the id and call xe_oa_remove_config_ioctl() with perfect timing, freeing oa_config before we dereference it, leading to a potential use-after-free. Fix this by caching the id in a local variable while holding the lock. v2: (Matt A) - Dropped mutex_unlock(&oa->metrics_lock) ordering change from xe_oa_remove_config_ioctl() Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6614 Fixes: cdf02fe1a94a7 ("drm/xe/oa/uapi: Add/remove OA config perf ops") Cc: <stable@vger.kernel.org> # v6.11+ Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251118114859.3379952-2-sanjay.kumar.yadav@intel.com
2025-11-20Merge tag 'drm-rust-next-2025-11-18' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/rust/kernel into drm-next Cross-subsystem Changes: Rust - Make slice::as_flattened usable on all supported versions of rustc. - Add FromBytes::from_bytes_prefix() method. Core Changes: - Update Tyr in MAINTAINERS file. - Remove redundant device ptr from Rust GEM object. - Change how AlwaysRefCounted is implemented for GEM objects. - Add deferred vm_bo cleanup to GPUVM and use it in Panthor. Driver Changes: Nova Core - Introduction of bitfield! macro, with support for different storage sizes and custom visibility. - Introduction of safe converters between integer types for which the conversion is lossless. - GSP initialized up to fully booted state on Ampere. - Use more future-proof register for GPU identification. - Various simplifications and optimizations. Nova - Select NOVA_CORE. - Depend on CONFIG_64BIT. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/aRxtJC0D1pQUepF4@google.com
2025-11-19drm/amdgpu: Add sriov vf check for VCN per queue reset support.Shikang Fan
Add SRIOV check when setting VCN ring's supported reset mask. Signed-off-by: Shikang Fan <shikang.fan@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ee9b603ad43f9870eb75184f9fb0a84f8c3cc852) Cc: stable@vger.kernel.org
2025-11-19drm/amdgpu/ttm: Fix crash when handling MMIO_REMAP in PDE flagsSrinivasan Shanmugam
The MMIO_REMAP BO is a special 4K IO page that does not have a ttm_tt behind it. However, amdgpu_ttm_tt_pde_flags() was treating it like normal TT/doorbell/preempt memory and unconditionally accessed ttm->caching. For the MMIO_REMAP BO, ttm is NULL, so this leads to a NULL pointer dereference when computing PDE flags. Fix this by checking that ttm is non-NULL before reading ttm->caching. This prevents the crash for MMIO_REMAP and also makes the code more defensive if other BOs ever come through without a ttm_tt. Fixes: fb5a52dbe9fe ("drm/amdgpu: Implement TTM handling for MMIO_REMAP placement") Suggested-by: Jesse Zhang <Jesse.Zhang@amd.com> Suggested-by: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com> Tested-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 0db94da5a0a1cacda080b9ec8425fcbe4babc141)