summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2025-04-09drm/i915/wm: convert i9xx_wm.h external interfaces to struct intel_displayJani Nikula5-32/+37
Going forward, struct intel_display is the main display device data pointer. Convert the i9xx_wm.h interface to struct intel_display. With this, we can make intel_wm.c independent of i915_drv.h. v2: Also remove i915_drv.h, fix commit message Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/3e30634d85c0e0aac9c95f9a2f928131ba400271.1744119460.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/wm: convert skl_watermarks.c internally to struct intel_displayJani Nikula1-286/+250
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of skl_watermarks.c to struct intel_display. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/61ae2013c5db962e90e072be7d37d630cb7dfc34.1744119460.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/wm: convert skl_watermark.h external interfaces to struct intel_displayJani Nikula9-91/+89
Going forward, struct intel_display is the main display device data pointer. Convert the skl_watermark.h interface to struct intel_display. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/cd2b1863dee25b69b4766090dd183a7467c4edea.1744119460.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/wm: convert intel_wm.c internally to struct intel_displayJani Nikula1-61/+61
Going forward, struct intel_display is the main display device data pointer. Convert as much as possible of intel_wm.c to struct intel_display. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/6106c0313190ee904c7f7737d0b78b61983eed91.1744119460.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/wm: convert intel_wm.h external interfaces to struct intel_displayJani Nikula9-68/+80
Going forward, struct intel_display is the main display device data pointer. Convert the intel_wm.h interface as well as the hooks in struct intel_wm_funcs to struct intel_display. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/1085900b4e46bbb514e6918c321639ac380331ce.1744119460.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/dsi: unify naming and simplify checks for dphy paramsJani Nikula1-60/+22
Unify the naming of the data and clock lane timing parameters, and simplify their bounds checks. Drop the debug messages on out of bounds parameters as excessive. Clarify the comment while at it. Cc: William Tseng <william.tseng@intel.com> Reviewed-by: William Tseng <william.tseng@intel.com> Tested-by: William Tseng <william.tseng@intel.com> Link: https://lore.kernel.org/r/d1a75ae7b9d93a0b50976b5de45ba2ca798991ad.1743682608.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/dsi: separate clock and data lane prepare timingJani Nikula1-8/+8
The history of why the max of VBT clock and data lane prepare timing parameter is used for both instead of each individually is unknown. Separate them to follow what the Windows driver does. Cc; William Tseng <william.tseng@intel.com> Reviewed-by: William Tseng <william.tseng@intel.com> Tested-by: William Tseng <william.tseng@intel.com> Link: https://lore.kernel.org/r/079a26d0aae79f299aee0397dad2d6519cd55071.1743682608.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/huc: Fix fence not released on early probe errorsJanusz Krzysztofik3-6/+7
HuC delayed loading fence, introduced with commit 27536e03271da ("drm/i915/huc: track delayed HuC load with a fence"), is registered with object tracker early on driver probe but unregistered only from driver remove, which is not called on early probe errors. Since its memory is allocated under devres, then released anyway, it may happen to be allocated again to the fence and reused on future driver probes, resulting in kernel warnings that taint the kernel: <4> [309.731371] ------------[ cut here ]------------ <3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915] <4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0 ... <4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1 ... <4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0 ... <4> [309.731728] Call Trace: <4> [309.731730] <TASK> ... <4> [309.731949] __debug_object_init+0x17b/0x1c0 <4> [309.731957] debug_object_init+0x34/0x50 <4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915] <4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915] <4> [309.732468] intel_uc_init_early+0x61/0x680 [i915] <4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915] <4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915] <4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915] <4> [309.733075] i915_pci_probe+0xe6/0x220 [i915] <4> [309.733198] local_pci_probe+0x44/0xb0 <4> [309.733203] pci_device_probe+0xf4/0x270 <4> [309.733209] really_probe+0xee/0x3c0 <4> [309.733215] __driver_probe_device+0x8c/0x180 <4> [309.733219] driver_probe_device+0x24/0xd0 <4> [309.733223] __driver_attach+0x10f/0x220 <4> [309.733230] bus_for_each_dev+0x7d/0xe0 <4> [309.733236] driver_attach+0x1e/0x30 <4> [309.733239] bus_add_driver+0x151/0x290 <4> [309.733244] driver_register+0x5e/0x130 <4> [309.733247] __pci_register_driver+0x7d/0x90 <4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915] <4> [309.733413] i915_init+0x34/0x120 [i915] <4> [309.733655] do_one_initcall+0x62/0x3f0 <4> [309.733667] do_init_module+0x97/0x2a0 <4> [309.733671] load_module+0x25ff/0x2890 <4> [309.733688] init_module_from_file+0x97/0xe0 <4> [309.733701] idempotent_init_module+0x118/0x330 <4> [309.733711] __x64_sys_finit_module+0x77/0x100 <4> [309.733715] x64_sys_call+0x1f37/0x2650 <4> [309.733719] do_syscall_64+0x91/0x180 <4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e <4> [309.733792] </TASK> ... <4> [309.733806] ---[ end trace 0000000000000000 ]--- That scenario is most easily reproducible with igt@i915_module_load@reload-with-fault-injection. Fix the issue by moving the cleanup step to driver release path. Fixes: 27536e03271da ("drm/i915/huc: track delayed HuC load with a fence") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13592 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://lore.kernel.org/r/20250402172057.209924-2-janusz.krzysztofik@linux.intel.com (cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/vrr: Add vrr.vsync_{start, end} in vrr_params_changedAnkit Nautiyal1-1/+3
Add the missing vrr parameters in vrr_params_changed() helper. This ensures that changes in vrr.vsync_{start,end} trigger a call to appropriate helpers to update the VRR registers. Fixes: e8cd188e91bb ("drm/i915/display: Compute vrr_vsync params") Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.10+ Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250404080540.2059511-1-ankit.k.nautiyal@intel.com (cherry picked from commit ced5e64f011cb5cd541988442997ceaa7385827e) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-08drm/i915/huc: Fix fence not released on early probe errorsJanusz Krzysztofik3-6/+7
HuC delayed loading fence, introduced with commit 27536e03271da ("drm/i915/huc: track delayed HuC load with a fence"), is registered with object tracker early on driver probe but unregistered only from driver remove, which is not called on early probe errors. Since its memory is allocated under devres, then released anyway, it may happen to be allocated again to the fence and reused on future driver probes, resulting in kernel warnings that taint the kernel: <4> [309.731371] ------------[ cut here ]------------ <3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915] <4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0 ... <4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1 ... <4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0 ... <4> [309.731728] Call Trace: <4> [309.731730] <TASK> ... <4> [309.731949] __debug_object_init+0x17b/0x1c0 <4> [309.731957] debug_object_init+0x34/0x50 <4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915] <4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915] <4> [309.732468] intel_uc_init_early+0x61/0x680 [i915] <4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915] <4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915] <4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915] <4> [309.733075] i915_pci_probe+0xe6/0x220 [i915] <4> [309.733198] local_pci_probe+0x44/0xb0 <4> [309.733203] pci_device_probe+0xf4/0x270 <4> [309.733209] really_probe+0xee/0x3c0 <4> [309.733215] __driver_probe_device+0x8c/0x180 <4> [309.733219] driver_probe_device+0x24/0xd0 <4> [309.733223] __driver_attach+0x10f/0x220 <4> [309.733230] bus_for_each_dev+0x7d/0xe0 <4> [309.733236] driver_attach+0x1e/0x30 <4> [309.733239] bus_add_driver+0x151/0x290 <4> [309.733244] driver_register+0x5e/0x130 <4> [309.733247] __pci_register_driver+0x7d/0x90 <4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915] <4> [309.733413] i915_init+0x34/0x120 [i915] <4> [309.733655] do_one_initcall+0x62/0x3f0 <4> [309.733667] do_init_module+0x97/0x2a0 <4> [309.733671] load_module+0x25ff/0x2890 <4> [309.733688] init_module_from_file+0x97/0xe0 <4> [309.733701] idempotent_init_module+0x118/0x330 <4> [309.733711] __x64_sys_finit_module+0x77/0x100 <4> [309.733715] x64_sys_call+0x1f37/0x2650 <4> [309.733719] do_syscall_64+0x91/0x180 <4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e <4> [309.733792] </TASK> ... <4> [309.733806] ---[ end trace 0000000000000000 ]--- That scenario is most easily reproducible with igt@i915_module_load@reload-with-fault-injection. Fix the issue by moving the cleanup step to driver release path. Fixes: 27536e03271da ("drm/i915/huc: track delayed HuC load with a fence") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13592 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://lore.kernel.org/r/20250402172057.209924-2-janusz.krzysztofik@linux.intel.com
2025-04-07drm/i915/dp_mst: Rename intel_dp::mst.active_links to mst.active_streamsImre Deak2-7/+7
intel_dp::mst.active_links actually indicates the number of MST streams, not the number of MST links (one MST link carrying one or more MST streams), rename the field accordingly. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250404150310.1156696-7-imre.deak@intel.com
2025-04-07drm/i915/dp_mst: Use intel_dp_mst_active_streams() instead of open-coding itImre Deak3-6/+7
Use intel_dp_mst_active_streams() everywhere, instead of open-coding it. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250404150310.1156696-6-imre.deak@intel.com
2025-04-07drm/i915/dp_mst: Rename intel_dp_mst_encoder_active_links() to ↵Imre Deak4-21/+20
intel_dp_mst_active_streams() It's not clear which encoder intel_dp_mst_encoder_active_links() refers to (primary/stream), but there is also no reason to call the queried property an encoder property; remove encoder from the name. Also it's the number of MST streams being queried, vs. the number of MST links (there is one MST link carrying one or more MST streams), so rename link to stream as well. While at it pass intel_dp to the function, which is more logical and makes it easier to re-use the function later (without the need to get the digital port pointer). Also move the function earlier, next to the related ones. Suggested-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250404150310.1156696-5-imre.deak@intel.com
2025-04-07drm/i915/dp_mst: Remove stream count assert from intel_dp_check_mst_status()Imre Deak1-2/+0
There doesn't seem to be a reason to assert for a non-negative stream counter in intel_dp_check_mst_status() in particular, remove it. There is now an equivalent assert in intel_dp_mst_dec_active_streams(). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250404150310.1156696-4-imre.deak@intel.com
2025-04-07drm/i915/dp_mst: Add intel_dp_mst_{inc, dec}_active_streams()Imre Deak1-16/+27
Add helpers to increment/decrement the active MST stream count, instead of open-coding these. In mst_stream_pre_enable(), the increment will happen earlier, this is ok, since nothing depends on the counter between the two points. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250404150310.1156696-3-imre.deak@intel.com
2025-04-07drm/i915/dp: Rename intel_dp::link_trained to link.activeImre Deak6-12/+12
The intel_dp::link_trained flag indicates whether the link is active, regardless of whether the link training passed or failed. For clarity rename the flag to 'active'. While at it move the flag under intel_dp::link. Suggested-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250404150310.1156696-2-imre.deak@intel.com
2025-04-07drm/i915/vrr: Add vrr.vsync_{start, end} in vrr_params_changedAnkit Nautiyal1-1/+3
Add the missing vrr parameters in vrr_params_changed() helper. This ensures that changes in vrr.vsync_{start,end} trigger a call to appropriate helpers to update the VRR registers. Fixes: e8cd188e91bb ("drm/i915/display: Compute vrr_vsync params") Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.10+ Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250404080540.2059511-1-ankit.k.nautiyal@intel.com
2025-04-07drm/i915/xe2hpd: Identify the memory type for SKUs with GDDR + ECCVivek Kasireddy3-1/+18
Some SKUs of Xe2_HPD platforms (such as BMG) have GDDR memory type with ECC enabled. We need to identify this scenario and add a new case in xelpdp_get_dram_info() to handle it. In addition, the derating value needs to be adjusted accordingly to compensate for the limited bandwidth. Bspec: 64602 Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 3adcf970dc7e ("drm/xe/bmg: Drop force_probe requirement") Cc: stable@vger.kernel.org Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250324-tip-v2-1-38397de319f8@intel.com (cherry picked from commit 327e30123cafcb45c0fc5843da0367b90332999d) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-07drm/i915/dp: Reject HBR3 when sink doesn't support TPS4Ville Syrjälä1-7/+42
According to the DP spec TPS4 is mandatory for HBR3. We have however seen some broken eDP sinks that violate this and declare support for HBR3 without TPS4 support. At least in the case of the icl Dell XPS 13 7390 this results in an unstable output. Reject HBR3 when TPS4 supports is unavailable on the sink. v2: Leave breadcrumbs in dmesg to avoid head scratching (Jani) Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306210740.11886-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 38188a7f575dacba1120a59fd5d62c7f3313c0fa) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-07drm/i915/gvt: fix unterminated-string-initialization warningJani Nikula1-3/+4
Initializing const char opregion_signature[16] = OPREGION_SIGNATURE (which is "IntelGraphicsMem") drops the NUL termination of the string. This is intentional, but the compiler doesn't know this. Switch to initializing header->signature directly from the string litaral, with sizeof destination rather than source. We don't treat the signature as a string other than for initialization; it's really just a blob of binary data. Add a static assert for good measure to cross-check the sizes. Reported-by: Kees Cook <kees@kernel.org> Closes: https://lore.kernel.org/r/20250310222355.work.417-kees@kernel.org Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13934 Tested-by: Nicolas Chauvet <kwizart@gmail.com> Tested-by: Damian Tometzki <damian@riscv-rocks.de> Cc: stable@vger.kernel.org Reviewed-by: Zhenyu Wang <zhenyuw.linux@gmail.com> Link: https://lore.kernel.org/r/20250327124739.2609656-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 4f8207469094bd04aad952258ceb9ff4c77b6bfa) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-07drm/i915: Disable RPG during live selftestBadal Nilawar2-15/+22
The Forcewake timeout issue has been observed on Gen 12.0 and above. To address this, disable Render Power-Gating (RPG) during live self-tests for these generations. The temporary workaround 'drm/i915/mtl: do not enable render power-gating on MTL' disables RPG globally, which is unnecessary since the issues were only seen during self-tests. v2: take runtime pm wakeref Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/9413 Fixes: 25e7976db86b ("drm/i915/mtl: do not enable render power-gating on MTL") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Karthik Poosa <karthik.poosa@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250310152821.2931678-1-sk.anirban@intel.com (cherry picked from commit 0a4ae87706c6d15d14648e428c3a76351f823e48) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-07drm/i915: Fix scanline_offset for LNL+ and BMG+Ville Syrjälä1-1/+3
Turns out LNL+ and BMG+ no longer have the weird extra scanline offset for HDMI outputs. Fix intel_crtc_scanline_offset() accordingly so that scanline evasion/etc. works correctly on HDMI outputs on these new platforms. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250207215406.19348-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com> (cherry picked from commit fede97b72b957b46260ca98fc924ba2b916e50d7) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-07i915: Use writeback_iter()Matthew Wilcox (Oracle)1-24/+8
Convert from an inefficient loop to the standard writeback iterator. Signed-off-by: "Matthew Wilcox (Oracle)" <willy@infradead.org> Link: https://lore.kernel.org/r/20250402150005.2309458-7-willy@infradead.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-04-06Merge tag 'timers-cleanups-2025-04-06' of ↵Linus Torvalds8-12/+12
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer cleanups from Thomas Gleixner: "A set of final cleanups for the timer subsystem: - Convert all del_timer[_sync]() instances over to the new timer_delete[_sync]() API and remove the legacy wrappers. Conversion was done with coccinelle plus some manual fixups as coccinelle chokes on scoped_guard(). - The final cleanup of the hrtimer_init() to hrtimer_setup() conversion. This has been delayed to the end of the merge window, so that all patches which have been merged through other trees are in mainline and all new users are catched. Doing this right before rc1 ensures that new code which is merged post rc1 is not introducing new instances of the original functionality" * tag 'timers-cleanups-2025-04-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: tracing/timers: Rename the hrtimer_init event to hrtimer_setup hrtimers: Rename debug_init_on_stack() to debug_setup_on_stack() hrtimers: Rename debug_init() to debug_setup() hrtimers: Rename __hrtimer_init_sleeper() to __hrtimer_setup_sleeper() hrtimers: Remove unnecessary NULL check in hrtimer_start_range_ns() hrtimers: Make callback function pointer private hrtimers: Merge __hrtimer_init() into __hrtimer_setup() hrtimers: Switch to use __htimer_setup() hrtimers: Delete hrtimer_init() treewide: Convert new and leftover hrtimer_init() users treewide: Switch/rename to timer_delete[_sync]()
2025-04-06Merge tag 'drm-next-2025-04-05' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds2-1/+6
Pull drm fixes from Dave Airlie: "Weekly fixes, mostly from the end of last week, this week was very quiet, maybe you scared everyone away. It's mostly amdgpu, and xe, with some i915, adp and bridge bits, since I think this is overly quiet I'd expect rc2 to be a bit more lively. bridge: - tda998x: Select CONFIG_DRM_KMS_HELPER amdgpu: - Guard against potential division by 0 in fan code - Zero RPM support for SMU 14.0.2 - Properly handle SI and CIK support being disabled - PSR fixes - DML2 fixes - DP Link training fix - Vblank fixes - RAS fixes - Partitioning fix - SDMA fix - SMU 13.0.x fixes - Rom fetching fix - MES fixes - Queue reset fix xe: - Fix NULL pointer dereference on error path - Add missing HW workaround for BMG - Fix survivability mode not triggering - Fix build warning when DRM_FBDEV_EMULATION is not set i915: - Bounds check for scalers in DSC prefill latency computation - Fix build by adding a missing include adp: - Fix error handling in plane setup" # -----BEGIN PGP SIGNATURE----- * tag 'drm-next-2025-04-05' of https://gitlab.freedesktop.org/drm/kernel: (34 commits) drm/i2c: tda998x: select CONFIG_DRM_KMS_HELPER drm/amdgpu/gfx12: fix num_mec drm/amdgpu/gfx11: fix num_mec drm/amd/pm: Add gpu_metrics_v1_8 drm/amdgpu: Prefer shadow rom when available drm/amd/pm: Update smu metrics table for smu_v13_0_6 drm/amd/pm: Remove host limit metrics support Remove unnecessary firmware version check for gc v9_4_2 drm/amdgpu: stop unmapping MQD for kernel queues v3 Revert "drm/amdgpu/sdma_v4_4_2: update VM flush implementation for SDMA" drm/amdgpu: Parse all deferred errors with UMC aca handle drm/amdgpu: Update ta ras block drm/amdgpu: Add NPS2 to DPX compatible mode drm/amdgpu: Use correct gfx deferred error count drm/amd/display: Actually do immediate vblank disable drm/amd/display: prevent hang on link training fail Revert "drm/amd/display: dml2 soc dscclk use DPM table clk setting" drm/amd/display: Increase vblank offdelay for PSR panels drm/amd: Handle being compiled without SI or CIK support better drm/amd/pm: Add zero RPM enabled OD setting support for SMU14.0.2 ...
2025-04-05treewide: Switch/rename to timer_delete[_sync]()Thomas Gleixner8-12/+12
timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree over and remove the historical wrapper inlines. Conversion was done with coccinelle plus manual fixups where necessary. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2025-04-04drm/i915: Eliminate intel_compute_sagv_mask()Ville Syrjälä1-40/+24
intel_compute_sagv_mask() has become pointless. Just inline its contents into the existing loop in skl_compute_wm(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-15-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Skip bw stuff if per-crtc sagv state doesn't changeVille Syrjälä2-3/+16
If there are no changes to intel_crtc_can_enable_sagv() there is no need to do all the sagv bw_state recomputation. The only slight caveat here is hw state takeover where we initially disable SAGV, and want it to get re-enabled once we've determined that it's safe to do so. That can now be achieved by having intel_crtc_can_enable_sagv() reject SAGV as long as the crtc_state->inherited flag is set. Once the flag gets cleared (during initial commit for inactive pipes, during the first userspace commit for active pipes), we will naturally recompute all the sagv related state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-14-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Make intel_bw_modeset_checks() internal to intel_bw_atomic_check()Ville Syrjälä3-11/+10
Now that all the sagv computation has been moved from the skl+ watermark code into intel_bw_atomic_check() there is no point in calling intel_bw_modeset_checks() before the wm computation. Hide it within intel_bw_atomic_check(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Make intel_bw_check_sagv_mask() internal to intel_bw.cVille Syrjälä3-7/+8
The only thing between the current intel_bw_check_sagv_mask() call site and intel_bw_atomic_check() is skl_wm_add_affected_planes() which no longer depends on the sagv mask, so we can make life a lot less confusing by calling intel_bw_check_sagv_mask() from intel_bw_atomic_check() instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-12-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Extract intel_bw_check_sagv_mask()Ville Syrjälä4-27/+46
Move the bw_state->pipe_sagv_reject computation into intel_bw.c where it belongs. Previously we had a complicated dance between watermarks and sagv which required this to be computed earlier, but that was changed in commit 5e8146251f7b ("extract intel_bw_check_sagv_mask()") which allows the whole thing to be cleaned up quite a bit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-11-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Extract intel_bw_modeset_checks()Ville Syrjälä4-9/+36
Pull the new_bw_state->active_pipes computation out from intel_compute_sagv_mask() and move it into the intel_bw.c (which is arguably the correct place for it). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Drop force_check_qgvVille Syrjälä2-12/+6
Remove the force_check_qgv flag and just fill the pipe_sagv_reject bitmask properly during readout. This will cause the initial commit to re-enable SAGV if possible. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Flag even inactive crtcs as "inherited"Ville Syrjälä2-11/+14
I want to use the crtc_state->inherited flag to clean up some of the early SAGV handling. To make that work nicely I need to flag even the inactive crtcs as "inherited". Since we can't expect user space to perform any real commits on inactive crtcs we'll clear the flag already during initial_commit(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Do more bw readoutVille Syrjälä2-0/+7
Update a bunch of bw related stuff during readout: - bw_state->dbuf_bw possible now that the wm readout has given us access to the plane ddb data - cdclk_state->bw_min_cdclk Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Avoid triggering unwanted cdclk changes due to dbuf bandwidth changesVille Syrjälä1-4/+13
Currently intel_bw_calc_min_cdclk() always adds the bw_state to the atomic state. Not only does it result in potentially redundant work later, it's also currently causing unwanted cdclk changes during driver load. Check if the dbuf bw is actually changing before we decide to pull in the bw state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Pass intel_dbuf_bw to skl_*_calc_dbuf_bw() explicitlyVille Syrjälä1-7/+6
Make skl_*_calc_dbuf_bw() a bit lower level passing in the to be mutated dbuf_bw struct in explicitly. This will allow more reuse later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Extract intel_dbuf_bw_changed()Ville Syrjälä1-6/+17
Extract the struct intel_dbuf_bw comparison into a small helper. We'll get more users later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: s/intel_crtc_bw/intel_dbuf_bw/Ville Syrjälä1-12/+12
Rename the intel_crtc_bw struct to intel_dbuf_bw to better reflect what it does. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Drop the cached per-pipe min_cdclk[] from bw stateVille Syrjälä2-10/+8
intel_bw_crtc_min_cdclk() only depends on the pipe data rate, which we already have stashed in bw_state->data_rate[]. So stashing the resulting min_cdclk[] as well is redundant. Get rid of it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04Merge tag 'x86-urgent-2025-04-04' of ↵Linus Torvalds1-6/+0
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: - Fix a performance regression on AMD iGPU and dGPU drivers, related to the unintended activation of DMA bounce buffers that regressed game performance if KASLR disturbed things just enough - Fix a copy_user_generic() performance regression on certain older non-FSRM/ERMS CPUs - Fix a Clang build warning due to a semantic merge conflict the Kunit tree generated with the x86 tree - Fix FRED related system hang during S4 resume - Remove an unused API * tag 'x86-urgent-2025-04-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/fred: Fix system hang during S4 resume with FRED enabled x86/platform/iosf_mbi: Remove unused iosf_mbi_unregister_pmic_bus_access_notifier() x86/mm/init: Handle the special case of device private pages in add_pages(), to not increase max_pfn and trigger dma_addressing_limited() bounce buffers x86/tools: Drop duplicate unlikely() definition in insn_decoder_test.c x86/uaccess: Improve performance by aligning writes to 8 bytes in copy_user_generic(), on non-FSRM/ERMS CPUs
2025-04-03Merge tag 'drm-intel-next-fixes-2025-03-25' of ↵Dave Airlie2-1/+6
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next drm/i915 fixes for v6.15 merge window: - Bounds check for scalers in DSC prefill latency computation - Fix build by adding a missing include Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/878qota36x.fsf@intel.com
2025-04-02drm/i915/dp: Reject HBR3 when sink doesn't support TPS4Ville Syrjälä1-7/+42
According to the DP spec TPS4 is mandatory for HBR3. We have however seen some broken eDP sinks that violate this and declare support for HBR3 without TPS4 support. At least in the case of the icl Dell XPS 13 7390 this results in an unstable output. Reject HBR3 when TPS4 supports is unavailable on the sink. v2: Leave breadcrumbs in dmesg to avoid head scratching (Jani) Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306210740.11886-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-04-02drm/i915/psr: Prevent DP Panel Replay as well when CRC is enableJouni Högander1-6/+6
We are seeing timeouts in opening CRC fd when testing on setup where DP Panel Replay can be enabled. Fix these by checking if CRC is enabled for DP Panel Replay as well. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250331090747.2964028-1-jouni.hogander@intel.com
2025-04-02drm/i915: Eliminate the initial_plane_phys_{smem,lmem}() duplicationVille Syrjälä1-73/+2
initial_plane_phys_lmem() and initial_plane_phys_smem() are now identical. Remove one of them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313140838.29742-11-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-04-02drm/i915: Use intel_memory_region_type_is_local() in the BIOS FB takeoverVille Syrjälä1-4/+6
Replace the hardcoded PTE vs. memory region is_local checks in the BIOS FB takeover with intel_memory_region_type_is_local(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313140838.29742-10-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-04-02drm/i915: Lookup the memory region first in the BIOS FB takeoverVille Syrjälä1-18/+18
When doing the BIOS FB takeover let's look up the appropriate memory region first. If it doesn't exist there's not much point in doing the PTE read/etc either. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313140838.29742-9-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-04-02drm/i915: Use a nicer way to lookup the memory region in BIOS FB takeoverVille Syrjälä1-7/+21
Use intel_memory_region_by_type() to find the appropriate memory region for the BIOS FB takeover. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313140838.29742-8-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-04-02drm/i915: Verify the BIOS FB first PTE on non-LMEMBAR systemsVille Syrjälä1-2/+29
Now that we have intel_ggtt_read_entry() we can easily read out the first PTE of the BIOS FB and verify that it looks correct. We'll also use the extracted dma address to figure out where in stolen the FB lives (so far we've just assumed that it sits at offset 0, and in practice that does seem to be true, but better safe than sorry). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313140838.29742-7-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-04-02drm/i915: Use intel_ggtt_read_entry() in the BIOS FB takeoverVille Syrjälä1-7/+10
Use intel_ggtt_read_entry() instead of open coding the PTE read/decode in the BIOS FB takeover code. So far this codepath only covers platforms with LMEMBAR. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313140838.29742-6-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-22 23:18:47 +0300