summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-01-09drm/amdgpu: enable gfx12 queue reset flagJesse Zhang
Enable the kgq and kcq queue reset flag Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Reviewed-by: Tim Huang <tim.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amd/display: Increase sanitizer frame larger than limit when compile ↵Nathan Chancellor
testing with clang Commit 24909d9ec7c3 ("drm/amd/display: Overwriting dualDPP UBF values before usage") added a new warning in dml2/display_mode_core.c when building allmodconfig with clang: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:6268:13: error: stack frame size (3128) exceeds limit (3072) in 'dml_prefetch_check' [-Werror,-Wframe-larger-than] 6268 | static void dml_prefetch_check(struct display_mode_lib_st *mode_lib) | ^ Commit be4e3509314a ("drm/amd/display: DML21 Reintegration For Various Fixes") introduced one in dml2_core/dml2_core_dcn4_calcs.c with the same configuration: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:7236:13: error: stack frame size (3256) exceeds limit (3072) in 'dml_core_mode_support' [-Werror,-Wframe-larger-than] 7236 | static bool dml_core_mode_support(struct dml2_core_calcs_mode_support_ex *in_out_params) | ^ In the case of the first warning, the stack usage was already at the limit at the parent change, so the offending change was rather innocuous. In the case of the second warning, there was a rather dramatic increase in stack usage compared to the parent: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:7032:13: error: stack frame size (2696) exceeds limit (2048) in 'dml_core_mode_support' [-Werror,-Wframe-larger-than] 7032 | static bool dml_core_mode_support(struct dml2_core_calcs_mode_support_ex *in_out_params) | ^ This is an unfortunate interaction between an issue with stack slot reuse in LLVM that gets exacerbated by sanitization (which gets enabled with all{mod,yes}config) and function calls using a much higher number of parameters than is typical in the kernel, necessitating passing most of these values on the stack. While it is possible that there should be source code changes to address these warnings, this code is difficult to modify for various reasons, as has been noted in other changes that have occurred for similar reasons, such as commit 6740ec97bcdb ("drm/amd/display: Increase frame warning limit with KASAN or KCSAN in dml2"). Increase the frame larger than limit when compile testing with clang and the sanitizers enabled to avoid this breakage in all{mod,yes}config, as they are commonly used and valuable testing targets. While it is not the best to hide this issue, it is not really relevant when compile testing, as the sanitizers are commonly stressful on optimizations and they are only truly useful at runtime, which COMPILE_TEST states will not occur with the current build. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202412121748.chuX4sap-lkp@intel.com/ Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdgpu/pm: Implement SDMA queue reset for different asicJesse Zhang
Implement sdma queue reset by SMU_MSG_ResetSDMA2 Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Suggested-by: Tim Huang <tim.huang@amd.com> Reviewed-by: Tim Huang <tim.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdgpu/pm: add definition PPSMC_MSG_ResetSDMA2Jesse Zhang
add the PPSMC_MSG_ResetSDMA2 definition for smu 13.0.6 Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Reviewed-by: Tim Huang <tim.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdgpu/sdma4.4.2: add apu support in sdma queue resetJesse Zhang
Remove apu check in sdma queue reset. Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/xe/guc: Adding steering info support for GuC register listsJesus Narvaez
The guc_mmio_reg interface supports steering, but it is currently not implemented. This will allow the GuC to control steering of MMIO registers after save-restore and avoid reading from fused off MCR register instances. Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement") Signed-off-by: Jesus Narvaez <jesus.narvaez@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241212190100.3768068-1-jesus.narvaez@intel.com
2025-01-09drm/xe: Fix all typos in xeNitin Gote
Fix all typos in files of xe, reported by codespell tool. Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250106102646.1400146-2-nitin.r.gote@intel.com Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
2025-01-09drm/i915/gt: Prefer IS_ENABLED() instead of defined() on config optionNitin Gote
Use IS_ENABLED() instead of defined() for checking whether a kconfig option is enabled. Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103062651.798249-2-nitin.r.gote@intel.com
2025-01-09drm/xe/dg1: Fix power gate sequence.Rodrigo Vivi
sub-pipe PG is not present on DG1. Setting these bits can disable other power gates and cause GPU hangs on video playbacks. VLK: 16314, 4304 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13381 Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241219235536.454270-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 2f12e9c029315c1400059b2e7fdf53117c09c3a9) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-01-09drm/xe: Fix tlb invalidation when wedgingLucas De Marchi
If GuC fails to load, the driver wedges, but in the process it tries to do stuff that may not be initialized yet. This moves the xe_gt_tlb_invalidation_init() to be done earlier: as its own doc says, it's a software-only initialization and should had been named with the _early() suffix. Move it to be called by xe_gt_init_early(), so the locks and seqno are initialized, avoiding a NULL ptr deref when wedging: xe 0000:03:00.0: [drm] *ERROR* GT0: load failed: status: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01 xe 0000:03:00.0: [drm] *ERROR* GT0: firmware signature verification failed xe 0000:03:00.0: [drm] *ERROR* CRITICAL: Xe has declared device 0000:03:00.0 as wedged. ... BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 UID: 0 PID: 3908 Comm: modprobe Tainted: G U W 6.13.0-rc4-xe+ #3 Tainted: [U]=USER, [W]=WARN Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-S ADP-S DDR5 UDIMM CRB, BIOS ADLSFWI1.R00.3275.A00.2207010640 07/01/2022 RIP: 0010:xe_gt_tlb_invalidation_reset+0x75/0x110 [xe] This can be easily triggered by poking the GuC binary to force a signature failure. There will still be an extra message, xe 0000:03:00.0: [drm] *ERROR* GT0: GuC mmio request 0x4100: no reply 0x4100 but that's better than a NULL ptr deref. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3956 Fixes: c9474b726b93 ("drm/xe: Wedge the entire device") Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103001111.331684-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 5001ef3af8f2c972d6fd9c5221a8457556f8bea6) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-01-09Merge tag 'drm-xe-next-2025-01-07' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next UAPI Changes: - OA new property: 'unblock after N reports' (Ashutosh) i915 display Changes: - UHBR rates for Thunderbolt (Kahola) Driver Changes: - IRQ related fixes and improvements (Ilia) - Revert some changes that break a mesa debug tool (John) - Fix migration issues (Nirmoy) - Enable GuC's WA_DUAL_QUEUE for newer platforms (Daniele) - Move shrink test out of xe_bo (Nirmoy) - SRIOV PF: Use correct function to check LMEM provisioning (Michal) - Fix a false-positive "Missing outer runtime PM protection" warning (Rodrigo) - Make GSCCS disabling message less alarming (Daniele) - Fix DG1 power gate sequence (Rodrigo) - Xe files fixes (Lucas) - Fix a potential TP_printk UAF (Thomas) - OA Fixes (Umesh) - Fix tlb invalidation when wedging (Lucas) - Documentation fix (Lucas) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Z31579j3V3XCPFaK@intel.com
2025-01-09Merge tag 'drm-misc-next-2025-01-06' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.14: UAPI Changes: - Clarify drm memory stats documentation Cross-subsystem Changes: Core Changes: - sched: Documentation fixes, Driver Changes: - amdgpu: Track BO memory stats at runtime - amdxdna: Various fixes - hisilicon: New HIBMC driver - bridges: - Provide default implementation of atomic_check for HDMI bridges - it605: HDCP improvements, MCCS Support Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250106-augmented-kakapo-of-action-0cf000@houat
2025-01-09Merge tag 'mediatek-drm-next-6.14' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next for Linux 6.14 1. dp: Add sdp path reset 2. dp: Support flexible length of DP calibration data Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250104125538.111118-1-chunkuang.hu@kernel.org
2025-01-08drm/xe/slpc: Remove unnecessary force wakesVinay Belgaumkar
FORCEWAKE_ALL is not needed when we are trying to read the cur_freq, we just need to wake up the GT domain. We also do not need a force wake to for a H2G query to obtain min frequency. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241216194119.3017792-1-vinay.belgaumkar@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-08drm/xe: Introduce the RPa informationRodrigo Vivi
RPa is the Achievable frequency, defined by PCODE at runtime based on multiple running conditions. v2: Remove RPA_MASK from i915 file Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241220152936.623627-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-08treewide: Introduce kthread_run_worker[_on_cpu]()Frederic Weisbecker
kthread_create() creates a kthread without running it yet. kthread_run() creates a kthread and runs it. On the other hand, kthread_create_worker() creates a kthread worker and runs it. This difference in behaviours is confusing. Also there is no way to create a kthread worker and affine it using kthread_bind_mask() or kthread_affine_preferred() before starting it. Consolidate the behaviours and introduce kthread_run_worker[_on_cpu]() that behaves just like kthread_run(). kthread_create_worker[_on_cpu]() will now only create a kthread worker without starting it. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
2025-01-08drm/i915/gt: Prevent uninitialized pointer readsApoorva Singh
Initialize rq to NULL to prevent uninitialized pointer reads. Signed-off-by: Apoorva Singh <apoorva.singh@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241227112920.1547592-1-apoorva.singh@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-08Revert "drm/i915/hdcp: Don't enable HDCP1.4 directly from check_link"Suraj Kandpal
This reverts commit 483f7d94a0453564ad9295288c0242136c5f36a0. This needs to be reverted since HDCP even after updating the connector state HDCP property we don't reenable HDCP until the next commit in which the CP Property is set causing compliance to fail. --v2 -Fix build issue [Dnyaneshwar] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103084517.239998-1-suraj.kandpal@intel.com (cherry picked from commit fcf73e20cd1fe60c3ba5f9626f1e8f9cd4511edf) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2025-01-07drm/xe/vf: Don't apply Wa_22019338487 for VFMarcin Bernatowicz
Don't use Wa_22019338487 for VF. Signed-off-by: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com> Cc: Adam Miszczak <adam.miszczak@linux.intel.com> Cc: Jakub Kolakowski <jakub1.kolakowski@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Narasimha C V <narasimha.c.v@intel.com> Cc: Piotr Piorkowski <piotr.piorkowski@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211064211.781820-4-marcin.bernatowicz@linux.intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-01-07drm/xe/rtp: Add match helper to omit SR-IOV VF deviceMarcin Bernatowicz
Add a match helper that allows the application of a workaround when the device is not an SR-IOV VF (Virtual Function) device. Signed-off-by: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com> Cc: Adam Miszczak <adam.miszczak@linux.intel.com> Cc: Jakub Kolakowski <jakub1.kolakowski@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Narasimha C V <narasimha.c.v@intel.com> Cc: Piotr Piorkowski <piotr.piorkowski@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211064211.781820-3-marcin.bernatowicz@linux.intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-01-07drm/xe/vf: Don't check has flat ccs in bios on VFJakub Kolakowski
Don't check for flat ccs from VF-level as VF does not have direct access to the register. If the BIOS disables FlatCCS support (a use-case that will nearly never be used) and the has_flat_ccs flag is set, there shouldn't be any functional impact. The hardware will drop writes to the CCS region, and reads from the CCS region will always return 0. For the native case, the flag is disabled if the BIOS disables it to avoid unnecessary overhead in buffer object (BO) creation and migration. Signed-off-by: Jakub Kolakowski <jakub1.kolakowski@intel.com> Suggested-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Adam Miszczak <adam.miszczak@linux.intel.com> Cc: Jakub Kolakowski <jakub1.kolakowski@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Cc: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Narasimha C V <narasimha.c.v@intel.com> Cc: Piotr Piorkowski <piotr.piorkowski@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211064211.781820-2-marcin.bernatowicz@linux.intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-01-07drm/i915/display: convert global state to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device structure. Convert intel_global_state.[ch] to it. This allows us to make intel_pmdemand.c completely independent of i915_drv.h. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2b5e743b285a86a59ee87085727847c758c8d552.1735662324.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07drm/i915/pmdemand: convert to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device structure. Convert pmdemand to it. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c1d92e9490013d5aba50fc1d1ebc0ee18e82cf7e.1735662324.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07drm/i915/pmdemand: make struct intel_pmdemand_state opaqueJani Nikula
Only intel_pmdemand.c should look inside the struct intel_pmdemand_state. Indeed, this is already the case. Finish the job and make struct intel_pmdemand_state opaque, preventing any direct pokes at the guts of it in the future. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/bc5f418785ecd51454761e9a55f21340470a92e3.1735662324.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07drm/i915/pmdemand: convert to_intel_pmdemand_state() to a functionJani Nikula
In preparation for making struct intel_pmdemand_state an opaque type, convert to_intel_pmdemand_state() to a function. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/10324781f9f7eae5a92506aaa7a40403efd345dd.1735662324.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07drm/i915/dp: compute config for 128b/132b SST w/o DSCJani Nikula
Enable basic 128b/132b SST functionality without compression. Reuse intel_dp_mtp_tu_compute_config() to figure out the TU after we've determined we need to use an UHBR rate. It's slightly complicated as the M/N computation is done in different places in MST and SST paths, so we need to avoid trashing the values later for UHBR. If uncompressed UHBR fails, we drop to compressed non-UHBR, which is quite likely to fail as well. We still lack 128b/132b SST+DSC. We need mst_master_transcoder also for 128b/132b SST. Use cpu_transcoder directly. Enhanced framing is "don't care" for 128b/132b link. v2: mst_master_transcoder, enhanced framing (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/084e4e05bf25a5dd396dd391014943d42b11c88d.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: disable trancoder port select for 128b/132b SSTJani Nikula
128b/1232b SST will have mst_master_transcoder set and matching cpu_transcoder. Ensure disable also for 128b/132b SST. Reviewed-by: Imre Deak <imre.deak@intel.com> Co-developed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/eaf705b3490d828ba33e85f40a7794d58de7c5ad.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: handle 128b/132b SST in intel_ddi_read_func_ctl()Jani Nikula
We'll only ever get here in MST mode from MST stream encoders; the primary encoder's ->get_config() won't be called when we've detected it's MST. v2: Read mst_master_transcoder in 128b/132b SST path (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/436854c0bb6ab5c14c3d3837694ea60ac2fbaba2.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: start distinguishing 128b/132b SST and MST at state readoutJani Nikula
We'll want to distinguish 128b/132b SST and MST modes at state readout. There's a catch, though. From the hardware perspective, 128b/132b SST and MST programming are pretty much the same. And we can't really ask the sink at this point. If we have more than one transcoder in 128b/132b mode associated with the port, we can safely assume it's MST. But for MST with only a single stream enabled, we are pretty much out of luck. Let's fall back to looking at the software state, i.e. intel_dp->is_mst. It should be fine for the state checker, but for hardware takeover at probe, we'll have to trust the GOP has only enabled SST. TODO: Not sure how this *or* our current code handles 128b/132b enabled by GOP. Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/119a773a0d4d74ad204435e462f8d12cb0ea4128.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: enable ACT handling for 128b/132b SSTJani Nikula
Add ACT handling for 128b/132b SST enable/disable. This is preparation for enabling 128b/132b SST. This path is not reachable yet. v2: - Check for !is_hdmi (Imre) - Add disable sequence (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b0226471f9445d988917cee49dbbd93a1493f3c7.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: initialize 128b/132b SST DP2 VFREQ registersJani Nikula
Write the DP2 specific VFREQ registers. This is preparation for enabling 128b/132b SST. This path is not reachable yet. v2: Check for !is_hdmi (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7d90547e9ce01642b722efca0bf81cadb754e790.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: write payload for 128b/132b SSTJani Nikula
Write the payload allocation table for 128b/132b SST. Use VCPID 1 and start from slot 0, with dp_m_n.tu slots. This is preparation for enabling 128b/132b SST. This path is not reachable yet. Indeed, we don't yet compute TU for 128b/132b SST. v2: Handle drm_dp_dpcd_write_payload() failures (Imre) v3: Include drm_dp_helper.h (kernel test robot) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250107095414.1244286-1-jani.nikula@intel.com
2025-01-07drm/i915/ddi: 128b/132b SST also needs DP_TP_CTL_MODE_MSTJani Nikula
It's not very clearly specified, and the hardware bit is ill-named, but 128b/132b SST also needs the MST mode set in the DP_TP_CTL register. This is preparation for enabling 128b/132b SST. This path is not reachable yet. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b29fbba8c979a8bab2bf03088610fe408faaf704.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/ddi: enable 128b/132b TRANS_DDI_FUNC_CTL mode for UHBR SSTJani Nikula
128b/132b SST needs 128b/132b mode enabled in the TRANS_DDI_FUNC_CTL register. This is preparation for enabling 128b/132b SST. This path is not reachable yet. v2: Use the MST path instead of SST to also set transport select (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/122ebeadf4bf0870fc26b7d12abdff88f4be8799.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: adapt intel_dp_mtp_tu_compute_config() for 128b/132b SSTJani Nikula
Handle 128b/132b SST in intel_dp_mtp_tu_compute_config(). The remote bandwidth overhead and time slot allocation are only relevant for MST; SST only needs the local bandwidth and a check that 64 slots isn't exceeded. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b59c94b0aac2c073b0306c0a0040b26330f94260.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: split out a helper for figuring out the TUJani Nikula
Extract intel_dp_mtp_tu_compute_config() for figuring out the TU. Move the link configuration and mst state access to the callers. This will be easier to adapt to 128b/132b SST. v2: Don't add SST stuff here yet Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c3ea8370c9bd3cdc579159e68a63f4ed2fadc66a.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: remove crtc_state->pbnJani Nikula
The crtc_state->pbn member is only used as a temporary variable within mst_stream_find_vcpi_slots_for_bpp(). Remove it as unnecessary. Suggested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/726aaadbd425057dfd854e42417bcf8d69b769d3.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: change return value of mst_stream_find_vcpi_slots_for_bpp()Jani Nikula
The callers of mst_stream_find_vcpi_slots_for_bpp() don't need the returned slots for anything. On the contrary, they need to jump through hoops to just distinguish between success and failure. Just return 0 instead of slots from mst_stream_find_vcpi_slots_for_bpp() for success, and simplify the callers. There's a pointless ret local variable that we can drop in the process. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7b3671a548c893b1bb62151d41f90bb8ce842ccc.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: drop connector parameter from intel_dp_mst_compute_m_n()Jani Nikula
intel_dp_mst_compute_m_n() doesn't need the connector. Remove the parameter. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/eec2e9a2e2dc3d166ac94bb9de691246a14d3945.1735912293.git.jani.nikula@intel.com
2025-01-07drm/i915/mst: drop connector parameter from intel_dp_mst_bw_overhead()Jani Nikula
intel_dp_mst_bw_overhead() doesn't need the connector. Remove the parameter. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e1379aca0748e392d8a232135b823deec783e829.1735912293.git.jani.nikula@intel.com
2025-01-07drm/mst: remove mgr parameter and debug logging from drm_dp_get_vc_payload_bw()Jani Nikula
The struct drm_dp_mst_topology_mgr *mgr parameter is only used for debug logging in case the passed in link rate or lane count are zero. There's no further error checking as such, and the function returns 0. There should be no case where the parameters are zero. The returned value is generally used as a divisor, and if we were hitting this, we'd be seeing division by zero. Just remove the debug logging altogether, along with the mgr parameter, so that the function can be used in non-MST contexts without the topology manager. v2: Also remove drm_dp_mst_helper_tests_init as unnecessary (Imre) Cc: Imre Deak <imre.deak@intel.com> Cc: Lyude Paul <lyude@redhat.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/72d77e7a7fe69c784e9df048b7e6f250fd7599e4.1735912293.git.jani.nikula@intel.com
2025-01-07Merge drm/drm-next into drm-intel-nextJani Nikula
Backmerge to get the DRM DP payload and ACT helpers to drm-intel-next. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07Merge tag 'drm-intel-next-2024-12-11' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Core Changes: - drm/print: add drm_print_hex_dump() Driver Changes: - HDCP fixes and updates for Xe3lpd and for HDCP 1.4 (Suraj) - Add dedicated lock for each sideband (Jani) - New GSC FW for ARL-H and ARL-U (Daniele) - Add support for 3 VDSC engines 12 slices (Ankit) - Sanitize MBUS joining (Ville) - Fixes in DP MST (Imre) - Stop using pixel_format_from_register_bits() to parse VBT (Ville) - Declutter CDCLK code (Ville) - PSR clean up and fixes (Jouni, Jani, Animesh) - DMC wakelock - Fixes and enablement for Xe3_LPD (Gustavo) - Demote source OUI read/write failure logging to debug (Jani) - Potential boot oops fix and some general cleanups (Ville) - Scaler code cleanups (Ville) - More conversion towards struct intel_display and general cleanups (Jani) - Limit max compressed bpp to 18 when forcing DSC (Ankit) - Start to reconcile i915's and xe's display power mgt sequences (Rodrigo) - Some correction in the DP Link Training sequence (Arun) - Avoid setting YUV420_MODE in PIPE_MISC on Xe3lpd (Ankit) - MST and DDI cleanups and refactoring (Jani) - Fixed an typo in i915_gem_gtt.c (Zhang) - Try to make DPT shrinkable again (Ville) - Try to fix CPU MMIO fails during legacy LUT updates (Ville) - Some PPS cleanups (Ville, Jani) - Use seq buf for printing rates (Jani) - Flush DMC wakelock release work at the end of runtime suspend (Gustavo) - Fix NULL pointer dereference in capture_engine (Eugene) - Fix memory leak by correcting cache object name in error handler (Jiasheng) - Small refactor in WM/DPKGC for modifying latency programmed into PKG_C_LATENCY (Suraj) - Add drm_printer based hex dumper and use it (Jani) - Move g4x code to specific g4x functions (Jani) Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Rodrigo Vivi <rodrigo.vivi@intel.com> [sima: conflict in intel_dp_mst.c due to conversion to drm_connector_dynamic_init that landed through drm-misc] Link: https://patchwork.freedesktop.org/patch/msgid/Z1n4VhatZpvT5xKs@intel.com
2025-01-07drm/nouveau/disp: Fix missing backlight control on Macbook 5,1Takashi Iwai
Macbook 5,1 with MCP79 lost its backlight control since the recent change for supporting GSP-RM; it rewrote the whole nv50 backlight control code and each display engine is supposed to have an entry for IOR bl callback, but it didn't cover mcp77. This patch adds the missing bl entry initialization for mcp77 display engine to recover the backlight control. Fixes: 2274ce7e3681 ("drm/nouveau/disp: add output backlight control methods") Cc: stable@vger.kernel.org Link: https://bugzilla.suse.com/show_bug.cgi?id=1223838 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250102114944.11499-1-tiwai@suse.de
2025-01-07drm/i915/display: Adjust Added Wake Time with PKG_C_LATENCYAnimesh Manna
Increase the PKG_C_LATENCY Pkg C Latency field by the added wake time. v1: Initial version. v2: Rebase and cosmetic changes. v3: - Place latency adjustment early to accommodate round-up. [Suraj] - Modify commit description and cosmetic change. [Suraj] WA: 22020432604 Cc: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250106094408.1011063-1-animesh.manna@intel.com
2025-01-07drm/i915/dp: Return early if dsc is required but not supportedAnkit Nautiyal
Currently, when bandwidth is insufficient for a given mode, we attempt to use DSC. This is indicated by a debug print, followed by a check for DSC support. The debug message states that we are trying DSC, but DSC might not be supported, which can give an incorrect picture in the logs if we bail out later. Correct the order for both DP and DP MST to: - Check if DSC is required and supported, and return early if DSC is not supported. - Print a debug message to indicate that DSC will be tried next. Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103031424.1732774-1-ankit.k.nautiyal@intel.com
2025-01-06drm/amdgpu: Add a lock when accessing the buddy trim functionArunpravin Paneer Selvam
When running YouTube videos and Steam games simultaneously, the tester found a system hang / race condition issue with the multi-display configuration setting. Adding a lock to the buddy allocator's trim function would be the solution. <log snip> [ 7197.250436] general protection fault, probably for non-canonical address 0xdead000000000108 [ 7197.250447] RIP: 0010:__alloc_range+0x8b/0x340 [amddrm_buddy] [ 7197.250470] Call Trace: [ 7197.250472] <TASK> [ 7197.250475] ? show_regs+0x6d/0x80 [ 7197.250481] ? die_addr+0x37/0xa0 [ 7197.250483] ? exc_general_protection+0x1db/0x480 [ 7197.250488] ? drm_suballoc_new+0x13c/0x93d [drm_suballoc_helper] [ 7197.250493] ? asm_exc_general_protection+0x27/0x30 [ 7197.250498] ? __alloc_range+0x8b/0x340 [amddrm_buddy] [ 7197.250501] ? __alloc_range+0x109/0x340 [amddrm_buddy] [ 7197.250506] amddrm_buddy_block_trim+0x1b5/0x260 [amddrm_buddy] [ 7197.250511] amdgpu_vram_mgr_new+0x4f5/0x590 [amdgpu] [ 7197.250682] amdttm_resource_alloc+0x46/0xb0 [amdttm] [ 7197.250689] ttm_bo_alloc_resource+0xe4/0x370 [amdttm] [ 7197.250696] amdttm_bo_validate+0x9d/0x180 [amdttm] [ 7197.250701] amdgpu_bo_pin+0x15a/0x2f0 [amdgpu] [ 7197.250831] amdgpu_dm_plane_helper_prepare_fb+0xb2/0x360 [amdgpu] [ 7197.251025] ? try_wait_for_completion+0x59/0x70 [ 7197.251030] drm_atomic_helper_prepare_planes.part.0+0x2f/0x1e0 [ 7197.251035] drm_atomic_helper_prepare_planes+0x5d/0x70 [ 7197.251037] drm_atomic_helper_commit+0x84/0x160 [ 7197.251040] drm_atomic_nonblocking_commit+0x59/0x70 [ 7197.251043] drm_mode_atomic_ioctl+0x720/0x850 [ 7197.251047] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [ 7197.251049] drm_ioctl_kernel+0xb9/0x120 [ 7197.251053] ? srso_alias_return_thunk+0x5/0xfbef5 [ 7197.251056] drm_ioctl+0x2d4/0x550 [ 7197.251058] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [ 7197.251063] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu] [ 7197.251186] __x64_sys_ioctl+0xa0/0xf0 [ 7197.251190] x64_sys_call+0x143b/0x25c0 [ 7197.251193] do_syscall_64+0x7f/0x180 [ 7197.251197] ? srso_alias_return_thunk+0x5/0xfbef5 [ 7197.251199] ? amdgpu_display_user_framebuffer_create+0x215/0x320 [amdgpu] [ 7197.251329] ? drm_internal_framebuffer_create+0xb7/0x1a0 [ 7197.251332] ? srso_alias_return_thunk+0x5/0xfbef5 Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Fixes: 4a5ad08f5377 ("drm/amdgpu: Add address alignment support to DCC buffers") Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 3318ba94e56b9183d0304577c74b33b6b01ce516) Cc: stable@vger.kernel.org
2025-01-06drm/amd/pm: fix BUG: scheduling while atomicKun Liu
atomic scheduling will be triggered in interrupt handler for AC/DC mode switch as following backtrace. Call Trace: <IRQ> dump_stack_lvl __schedule_bug __schedule schedule schedule_preempt_disabled __mutex_lock smu_cmn_send_smc_msg_with_param smu_v13_0_irq_process amdgpu_irq_dispatch amdgpu_ih_process amdgpu_irq_handler __handle_irq_event_percpu handle_irq_event handle_edge_irq __common_interrupt common_interrupt </IRQ> <TASK> asm_common_interrupt Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Kun Liu <Kun.Liu2@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 03cc84b102d1a832e8dfc59344346dedcebcdf42) Cc: stable@vger.kernel.org
2025-01-06drm/amdkfd: wq_release signals dma_fence only when availableZhu Lingshan
kfd_process_wq_release() signals eviction fence by dma_fence_signal() which wanrs if dma_fence is NULL. kfd_process->ef is initialized by kfd_process_device_init_vm() through ioctl. That means the fence is NULL for a new created kfd_process, and close a kfd_process right after open it will trigger the warning. This commit conditionally signals the eviction fence in kfd_process_wq_release() only when it is available. [ 503.660882] WARNING: CPU: 0 PID: 9 at drivers/dma-buf/dma-fence.c:467 dma_fence_signal+0x74/0xa0 [ 503.782940] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu] [ 503.789640] RIP: 0010:dma_fence_signal+0x74/0xa0 [ 503.877620] Call Trace: [ 503.880066] <TASK> [ 503.882168] ? __warn+0xcd/0x260 [ 503.885407] ? dma_fence_signal+0x74/0xa0 [ 503.889416] ? report_bug+0x288/0x2d0 [ 503.893089] ? handle_bug+0x53/0xa0 [ 503.896587] ? exc_invalid_op+0x14/0x50 [ 503.900424] ? asm_exc_invalid_op+0x16/0x20 [ 503.904616] ? dma_fence_signal+0x74/0xa0 [ 503.908626] kfd_process_wq_release+0x6b/0x370 [amdgpu] [ 503.914081] process_one_work+0x654/0x10a0 [ 503.918186] worker_thread+0x6c3/0xe70 [ 503.921943] ? srso_alias_return_thunk+0x5/0xfbef5 [ 503.926735] ? srso_alias_return_thunk+0x5/0xfbef5 [ 503.931527] ? __kthread_parkme+0x82/0x140 [ 503.935631] ? __pfx_worker_thread+0x10/0x10 [ 503.939904] kthread+0x2a8/0x380 [ 503.943132] ? __pfx_kthread+0x10/0x10 [ 503.946882] ret_from_fork+0x2d/0x70 [ 503.950458] ? __pfx_kthread+0x10/0x10 [ 503.954210] ret_from_fork_asm+0x1a/0x30 [ 503.958142] </TASK> [ 503.960328] ---[ end trace 0000000000000000 ]--- Fixes: 967d226eaae8 ("dma-buf: add WARN_ON() illegal dma-fence signaling") Signed-off-by: Zhu Lingshan <lingshan.zhu@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 2774ef7625adb5fb9e9265c26a59dca7b8fd171e) Cc: stable@vger.kernel.org
2025-01-06drm/amd/display: Add check for granularity in dml ceil/floor helpersRoman Li
[Why] Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2() should check for granularity is non zero to avoid assert and divide-by-zero error in dcn_bw_ functions. [How] Add check for granularity 0. Cc: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Roman Li <Roman.Li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec) Cc: stable@vger.kernel.org
generated by cgit (git 2.34.1) at 2025-09-27 00:57:54 +0000