summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-01-09drm/i915/psr: Extend SU area to cover cursor fully if neededJouni Högander
In case early transport is enabled SU area needs to be extended to cover cursor area fully when cursor is in SU area. Bspec: 68927 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-3-jouni.hogander@intel.com
2024-01-09drm: Add eDP 1.5 early transport definitionJouni Högander
Add DP_PSR_ENABLE_SU_REGION_ET to enable panel early transport. Cc: dri-devel@lists.freedesktop.org Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-2-jouni.hogander@intel.com
2024-01-09drm/i915/dp: Fix the max DSC bpc supported by sourceAnkit Nautiyal
Use correct helper for getting max DSC bpc supported by the source. Fixes: 1c56e9a39833 ("drm/i915/dp: Get optimal link config to have best compressed bpp") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Swati Sharma <swati2.sharma@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231213091632.431557-3-ankit.k.nautiyal@intel.com
2024-01-09Merge tag 'amd-drm-next-6.8-2024-01-05' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.8-2024-01-05: amdgpu: - VRR fixes - PSR-SU fixes - SubVP fixes - DCN 3.5 fixes - Documentation updates - DMCUB fixes - DML2 fixes - UMC 12.0 updates - GPUVM fix - Misc code cleanups and whitespace cleanups - DP MST fix - Let KFD sync with GPUVM fences - GFX11 reset fix - SMU 13.0.6 fixes - VSC fix for DP/eDP - Navi12 display fix - RN/CZN system aperture fix - DCN 2.1 bandwidth validation fix - DCN INIT cleanup amdkfd: - SVM fixes - Revert TBA/TMA location change Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240105220522.4976-1-alexander.deucher@amd.com
2024-01-08drm/i915/cdclk: Re-use bxt_cdclk_ctl() when sanitizingGustavo Sousa
The function bxt_cdclk_ctl() is responsible for deriving the value for CDCLK_CTL; use it instead of repeating the same logic. v2: - Use a better commit message body by making it more self-contained and not referring to stuff from the subject line. (Matt) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240105140538.183553-5-gustavo.sousa@intel.com
2024-01-08drm/i915/cdclk: Reorder bxt_sanitize_cdclk()Gustavo Sousa
Make the sequence of steps in bxt_sanitize_cdclk() more logical by grouping things related to the check on the value of CDCLK_CTL into a single "block". Also, this will make an upcoming change replacing that block with a single function call easier to follow. v2: - Improve body of commit message to be more self-contained. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240105140538.183553-4-gustavo.sousa@intel.com
2024-01-08drm/i915/cdclk: Extract bxt_cdclk_ctl()Gustavo Sousa
Extract logic for deriving the value for CDCLK_CTL into bxt_cdclk_ctl(). This makes the code better readable and will be used later in bxt_sanitize_cdclk(). v2: - Improve body of commit message to be more self-contained. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240105140538.183553-3-gustavo.sousa@intel.com
2024-01-08drm/i915/xe2lpd: Update bxt_sanitize_cdclk()Gustavo Sousa
With Xe2_LPD, there were changes to the way CDCLK_CTL must be programmed. Those were reflected on _bxt_set_cdclk() with commit 3d3696c0fed1 ("drm/i915/lnl: Start using CDCLK through PLL"), but bxt_sanitize_cdclk() was left out. This was causing some issues when loading the driver with a pre-existing active display configuration: the driver would mistakenly take the current value of CDCLK_CTL as wrong and the sanitization would be triggered. In a scenario where the display was already configured with a high CDCLKC and had plane(s) enabled, FIFO underrun errors were reported, because the current sanitization code selects the minimum possible CDCLK. Fix that by updating bxt_sanitize_cdclk() to match the changes made in _bxt_set_cdclk(). Ideally, we would have a common function to derive the value for CDCLK_CTL, but that can be done in a future change. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240105140538.183553-2-gustavo.sousa@intel.com
2024-01-08drm/i915/dp: Abort AUX on disconnected native DP portsImre Deak
An AUX transfer on any disconnected DP port results in long timeout/retry delays the same way as this is described for TypeC port in commit a972cd3f0eb5 ("drm/i915/tc: Abort DP AUX transfer on a disconnected TC port") Prevent the delay on non-TypeC ports as well by aborting the transfer if the port is disconnected. For eDP keep the current behavior as the support for HPD signaling is optional for it. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-13-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2024-01-08drm/i915: Filter out glitches on HPD lines during hotplug detectionImre Deak
Glitches deasserting the connector HPD line can lead to incorrectly detecting a disconnect event (a glitch asserting the line will only cause a redundant connect->disconnect transition). The source of such a glitch can be noise on the line or a 0.5ms-1ms MST IRQ_HPD pulse. TypeC ports in the DP-alt or TBT-alt mode filter out these glitches inernally, but for others the driver has to do this. Make it so by polling the HPD line on these connectors for 4 ms. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-12-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2024-01-08drm/i915: Add intel_digital_port lock/unlock hooksImre Deak
Add hooks to intel_digital_port to lock and unlock the port and add a helper to check the connector's detect status while the port is locked already. This simplifies checking the connector detect status in intel_dp_aux_xfer() and intel_digital_port_connected() in the next two patches aborting AUX transfers on all DP connectors (except eDP) and filtering HPD glitches. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-11-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2024-01-08drm/i915: Disable hotplug detection handlers during driver init/shutdownImre Deak
As described in the previous two patches an unexpected connector detection can happen during the init/shutdown sequences. Prevent these by returning the connector's current status from the detection handlers. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-10-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2024-01-08drm/i915: Disable hotplug detection works during driver init/shutdownImre Deak
As described in the previous patch, an unexpected connector detection/modeset started from the intel_hotplug::hotplug_work can happen during the driver init/shutdown sequence. Prevent these by disabling the queuing of and flushing all the intel_hotplug work that can start them at the beginning of the init/shutdown sequence and allow the queuing only while the display is in the initialized state. Other work items - like the intel_connector::modeset_retry_work or the MST probe works - are still enabled and can start a detection/modeset, but after the previous patch these will be rejected. Disabling these works as well is for a follow-up patchset. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-9-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2024-01-08drm/i915: Prevent modesets during driver init/shutdownImre Deak
An unexpected modeset or connector detection by a user (user space or FB console) during the initialization/shutdown sequence is possible either via a hotplug IRQ handling work or via the connector sysfs (status/detect) interface. These modesets/detections should be prevented by disabling/flushing all related hotplug handling work and unregistering the interfaces that can start them at the beginning of the shutdown sequence. Some of this - disabling all related intel_hotplug work - will be done by the next patch, but others - for instance disabling the MST hotplug works - require a bigger rework. It makes sense - for diagnostic purpose, even with all the above work and interface disabled - to detect and reject any such user access. This patch does that for modeset accesses and a follow-up patch for connector detection. During driver loading/unloading/system suspend/shutdown and during system resume after calling intel_display_driver_disable_user_access() or intel_display_driver_resume_access() correspondigly, the current thread is allowed to modeset (as this thread requires to do an initial/restoring modeset or a disabling modeset), other threads (the user threads) are not allowed to modeset. During driver loading/system resume after calling intel_display_driver_enable_user_access() all threads are allowed to modeset. During driver unloading/system suspend/shutdown after calling intel_display_driver_suspend_access() no threads are allowed to modeset (as the HW got disabled and should stay in this state). v2: Call intel_display_driver_suspend_access()/resume_access() only for HAS_DISPLAY(). (CI) v3: (Jouni) - Add commit log comments explaining how the permission of modeset changes during HW init/deinit wrt. to the current and other user processes. Link: https://patchwork.freedesktop.org/patch/msgid/20240104132335.2766434-1-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2024-01-08drm/i915: Suspend the framebuffer console earlier during system suspendImre Deak
Suspend the FB console early during system suspend to prevent new FB probe/modeset cycles interfering with the HW uninitialization steps in a similar way as during driver shutdown as described in the previous patch. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-7-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2024-01-08drm/i915: Suspend the framebuffer console during driver shutdownImre Deak
Suspend the FB console during driver shutdown the same way this is done during system resume. This should prevent any HPD event to trigger a new FB probe/modeset cycle happening in parallel with the display HW disable/uninitialize steps. A preceding FB HPD event handling may be still pending, resulting in a probe/modeset like the above, these will be prevented by a later change in this patchset. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-6-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2024-01-08drm/i915: Disable intel HPD poll after DRM poll init/enableImre Deak
The only purpose of intel_hpd_poll_disable() during driver loading and system resume - at which point polling should be disabled anyway, except for connectors in an IRQ storm, for which the polling will stay enabled - is to force-detect all the connectors. However this detection in i915_hpd_poll_init_work() depends on drm.mode_config.poll_enabled, which will get set in drm_kms_helper_poll_init(), possibly after i915_hpd_poll_init_work() is scheduled. Hence the initial detection of connectors during driver loading may not happen. Fix the above by moving intel_hpd_poll_disable() after i915_hpd_poll_init_work(), the proper place anyway for doing the above detection after all the HW initialization steps are complete. Change the order the same way during system resume as well. The above race condition shouldn't matter here - as drm.mode_config.poll_enabled will be set - but the detection should happen here as well after the HW init steps are done. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-5-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2024-01-08drm/i915: Move audio deinit after disabling pollingImre Deak
Deinitialize audio during driver unload after disabling polling. This is in preparation to do all the display HW init/deinit steps at a point where no HPD IRQ or polling initiated connector detection or modeset can change the HW state. This may still happen here via an HPD IRQ -> hotplug detection work or a connector sysfs (state/detect) access, but these will be prevented by later changes in this patchset. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-4-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2024-01-08drm/i915: Keep the connector polled state disabled after stormImre Deak
If an HPD IRQ storm is detected on a connector during driver loading or system suspend/resume - disabling the IRQ and switching to polling - the polling may get disabled too early - before the intended 2 minute HPD_STORM_REENABLE_DELAY - with the HPD IRQ staying disabled for this duration. One such sequence is: Thread#1 Thread#2 intel_display_driver_probe()-> intel_hpd_init()-> (HPD IRQ gets enabled) . intel_hpd_irq_handler()-> . intel_hpd_irq_storm_detect() . intel_hpd_irq_setup()-> . (HPD IRQ gets disabled) . queue_delayed_work(hotplug.hotplug_work) . ... . i915_hotplug_work_func()-> . intel_hpd_irq_storm_switch_to_polling()-> . (polling enabled) . intel_hpd_poll_disable()-> queue_work(hotplug.poll_init_work) ... i915_hpd_poll_init_work()-> (polling gets disabled, HPD IRQ is still disabled) ... (Connector is neither polled or detected via HPD IRQs for 2 minutes) intel_hpd_irq_storm_reenable_work()-> (HPD IRQ gets enabled) To avoid the above 2 minute state without either polling or enabled HPD IRQ, leave the connector's polling mode unchanged in i915_hpd_poll_init_work() if its HPD IRQ got disabled after an IRQ storm indicated by the connector's HPD_DISABLED pin state. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-3-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2024-01-08drm/i915: Init DRM connector polled field earlyImre Deak
After an HPD IRQ storm on a connector intel_hpd_irq_storm_detect() will set the connector's HPD pin state to HPD_MARK_DISABLED and the IRQ gets disabled. Subsequently intel_hpd_irq_storm_switch_to_polling() will enable polling for these connectors, setting the pin state to HPD_DISABLED, but only if the connector's base.polled field is set to DRM_CONNECTOR_POLL_HPD. intel_hpd_irq_storm_reenable_work() will reenable the IRQ - after 2 minutes - if the pin state is HPD_DISABLED. The connectors will be created with their base.polled field set to 0, which gets initialized only later in i915_hpd_poll_init_work() (using intel_connector::polled). If a storm is detected on a connector after it's created and IRQs are enabled on it - by intel_hpd_init() - and before its bease.polled field is initialized in the above work, the connector's HPD pin will stay in the HPD_MARK_DISABLED state - leaving the IRQ disabled indefinitely - and polling will not get enabled on it as intended. I can't see a reason for initializing base.polled in a delayed manner, so do this already when creating the connector, to prevent the above race condition. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-2-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2024-01-08drm/i915/display: Use helper to select C20 MPLLA/BMika Kahola
We used to select between MPLLA/B with the following state->tx[0] & C20_PHY_USE_MPLLB Since this is used a few places within C20 PLL setting, let's introduce a helper function to clean up the code a bit. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240105112243.224199-1-mika.kahola@intel.com
2024-01-05drm/amd/display: Allow z8/z10 from driverCharlene Liu
Copy StutterPeriod from DML2 into DML1 StutterPeriod parameter. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by: Muhammad Ahmed <ahmed.ahmed@amd.com> Reviewed-by: Aric Cyr <aric.cyr@amd.com> Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: fix bandwidth validation failure on DCN 2.1Melissa Wen
IGT `amdgpu/amd_color/crtc-lut-accuracy` fails right at the beginning of the test execution, during atomic check, because DC rejects the bandwidth state for a fb sizing 64x64. The test was previously working with the deprecated dc_commit_state(). Now using dc_validate_with_context() approach, the atomic check needs to perform a full state validation. Therefore, set fast_validation to false in the dc_validate_global_state call for atomic check. Cc: stable@vger.kernel.org Fixes: b8272241ff9d ("drm/amd/display: Drop dc_commit_state in favor of dc_commit_streams") Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amdgpu: apply the RV2 system aperture fix to RN/CZN as wellAlex Deucher
These chips needs the same fix. This was previously not seen on then since the AGP aperture expanded the system aperture, but this showed up again when AGP was disabled. Reviewed-and-tested-by: Jiadong Zhu <Jiadong.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: Move fixpt_from_s3132 to amdgpu_dmHarry Wentland
Other environments don't like the unary minus operator on an unsigned value. Signed-off-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: Fix recent checkpatch errors in amdgpu_dmHarry Wentland
- Use tabs, not spaces. - Brace and parentheses placement Signed-off-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05Revert "drm/amdkfd: Relocate TBA/TMA to opposite side of VM hole"Kaibo Ma
That commit causes NULL pointer dereferences in dmesgs when running applications using ROCm, including clinfo, blender, and PyTorch, since v6.6.1. Revert it to fix blender again. This reverts commit 96c211f1f9ef82183493f4ceed4e347b52849149. Closes: https://github.com/ROCm/ROCm/issues/2596 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2991 Reviewed-by: Jay Cornwall <jay.cornwall@amd.com> Signed-off-by: Kaibo Ma <ent3rm4n@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: avoid stringop-overflow warnings for dp_decide_lane_settings()Arnd Bergmann
gcc prints a warning about a possible array overflow for a couple of callers of dp_decide_lane_settings() after commit 1b56c90018f0 ("Makefile: Enable -Wstringop-overflow globally"): drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c: In function 'dp_perform_fixed_vs_pe_training_sequence_legacy': drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:426:25: error: 'dp_decide_lane_settings' accessing 4 bytes in a region of size 1 [-Werror=stringop-overflow=] 426 | dp_decide_lane_settings(lt_settings, dpcd_lane_adjust, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 427 | lt_settings->hw_lane_settings, lt_settings->dpcd_lane_settings); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:426:25: note: referencing argument 4 of type 'union dpcd_training_lane[4]' I'm not entirely sure what caused this, but changing the prototype to expect a pointer instead of an array avoids the warnings. Fixes: 7727e7b60f82 ("drm/amd/display: Improve robustness of FIXED_VS link training at DP1 rates") Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: Fix power_helpers.c codestyleMarcelo Mendes Spessoto Junior
Place define macro expression inside () in power_helpers.c file Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: Fix hdcp_log.h codestyleMarcelo Mendes Spessoto Junior
Place HDCP_EVENT_TRACE(hdcp, event) macro content inside do while loop to avoid if-else issues in hdcp_log.h file v2: fix up build (Alex) Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: Fix hdcp2_execution.c codestyleMarcelo Mendes Spessoto Junior
Remove braces for single statement if expressions and change comparison order for hdcp2_execution.c file Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: Fix hdcp_psp.h codestyleMarcelo Mendes Spessoto Junior
Fix identation inside enum and place expressions in define macros inside () for hdcp_psp.h file Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: Fix freesync.c codestyleMarcelo Mendes Spessoto Junior
Remove braces for single statement if expression for freesync.c file Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: Fix hdcp_psp.c codestyleMarcelo Mendes Spessoto Junior
Fix identation for hdcp_psp.c file Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: Fix hdcp1_execution.c codestyleMarcelo Mendes Spessoto Junior
Remove braces from single statement if expression in hdcp1_execution.c file Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/pm/smu7: fix a memleak in smu7_hwmgr_backend_initZhipeng Lu
The hwmgr->backend, (i.e. data) allocated by kzalloc is not freed in the error-handling paths of smu7_get_evv_voltages and smu7_update_edc_leakage_table. However, it did be freed in the error-handling of phm_initializa_dynamic_state_adjustment_rule_settings, by smu7_hwmgr_backend_fini. So the lack of free in smu7_get_evv_voltages and smu7_update_edc_leakage_table is considered a memleak in this patch. Fixes: 599a7e9fe1b6 ("drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu ip version 7.") Fixes: 8f0804c6b7d0 ("drm/amd/pm: add edc leakage controller setting") Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amdkfd: Fix iterator used outside loop in 'kfd_add_peer_prop()'Srinivasan Shanmugam
Fix the following about iterator use: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1456 kfd_add_peer_prop() warn: iterator used outside loop: 'iolink3' Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: 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: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amdgpu: Drop 'fence' check in 'to_amdgpu_amdkfd_fence()'Srinivasan Shanmugam
Return value of container_of(...) can't be null, so null check is not required for 'fence'. Hence drop its NULL check. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c:93 to_amdgpu_amdkfd_fence() warn: can 'fence' even be NULL? Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: 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: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amdkfd: Confirm list is non-empty before utilizing list_first_entry in ↵Srinivasan Shanmugam
kfd_topology.c Before using list_first_entry, make sure to check that list is not empty, if list is empty return -ENODATA. Fixes the below: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1347 kfd_create_indirect_link_prop() warn: can 'gpu_link' even be NULL? drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1428 kfd_add_peer_prop() warn: can 'iolink1' even be NULL? drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1433 kfd_add_peer_prop() warn: can 'iolink2' even be NULL? Fixes: 0f28cca87e9a ("drm/amdkfd: Extend KFD device topology to surface peer-to-peer links") Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Suggested-by: Felix Kuehling <Felix.Kuehling@amd.com> Suggested-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amdgpu: Fix '*fw' from request_firmware() not released in ↵Srinivasan Shanmugam
'amdgpu_ucode_request()' Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:1404 amdgpu_ucode_request() warn: '*fw' from request_firmware() not released on lines: 1404. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Lijo Lazar <lijo.lazar@amd.com> Cc: 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: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in ↵Srinivasan Shanmugam
'amdgpu_mca_smu_get_mca_entry()' Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check 'mca_funcs' (see line 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_funcs *mca_funcs = adev->mca.mca_funcs; 361 int count; 362 363 switch (type) { 364 case AMDGPU_MCA_ERROR_TYPE_UE: 365 count = mca_funcs->max_ue_count; mca_funcs is dereferenced here. 366 break; 367 case AMDGPU_MCA_ERROR_TYPE_CE: 368 count = mca_funcs->max_ce_count; mca_funcs is dereferenced here. 369 break; 370 default: 371 return -EINVAL; 372 } 373 374 if (idx >= count) 375 return -EINVAL; 376 377 if (mca_funcs && mca_funcs->mca_get_mca_entry) ^^^^^^^^^ Checked too late! Cc: Yang Wang <kevinyang.wang@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: 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: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amdgpu: add param to specify fw bo location for front-door loadingLe Ma
This param can help isolating data path issues on new systems in early phase. Signed-off-by: Le Ma <le.ma@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amdgpu: Remove unreachable code in 'atom_skip_src_int()'Srinivasan Shanmugam
Fixes the below: drivers/gpu/drm/amd/amdgpu/atom.c:398 atom_skip_src_int() warn: ignoring unreachable code. Cc: 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: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: Removing duplicate copyright textMarcelo Mendes Spessoto Junior
mod_freesync header file has duplicated copyright boilerplate. Drop the duplicate. Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amdgpu: skip gpu_info fw loading on navi12Alex Deucher
It's no longer required. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2318 Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: add nv12 bounding boxAlex Deucher
This was included in gpu_info firmware, move it into the driver for consistency with other nv1x parts. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2318 Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/display: Fix sending VSC (+ colorimetry) packets for DP/eDP displays ↵Joshua Ashton
without PSR The check for sending the vsc infopacket to the display was gated behind PSR (Panel Self Refresh) being enabled. The vsc infopacket also contains the colorimetry (specifically the container color gamut) information for the stream on modern DP. PSR is typically only supported on mobile phone eDP displays, thus this was not getting sent for typical desktop monitors or TV screens. This functionality is needed for proper HDR10 functionality on DP as it wants BT2020 RGB/YCbCr for the container color space. Cc: stable@vger.kernel.org Cc: Harry Wentland <harry.wentland@amd.com> Cc: Xaver Hugl <xaver.hugl@gmail.com> Cc: Melissa Wen <mwen@igalia.com> Fixes: 15f9dfd545a1 ("drm/amd/display: Register Colorspace property for DP and HDMI") Tested-by: Simon Berz <simon@berz.me> Tested-by: Xaver Hugl <xaver.hugl@kde.org> Signed-off-by: Joshua Ashton <joshua@froggi.es> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05Revert "drm/amdgpu: enable mca debug mode on APU by default"Hawking Zhang
Not needed any more with firmware fixes Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/amd/pm: Add mem_busy_percent for GCv9.4.3 apuAsad Kamal
Expose sysfs entry mem_busy_percent for GC version 9.4.3 APU system Signed-off-by: Asad Kamal <asad.kamal@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-01-05drm/rockchip: vop2: Drop unused if_dclk_rate variableCristian Ciocaltea
Commit 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588") introduced a variable which ended up being unused: rockchip_drm_vop2.c:1688:23: warning: variable ‘if_dclk_rate’ set but not used [-Wunused-but-set-variable] This has been initially used as part of a formula to compute the clock dividers, but eventually it has been replaced by static values. Drop the variable declaration and move its assignment to the comment block, to serve as documentation of how the constants have been generated. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240105174007.98054-1-cristian.ciocaltea@collabora.com