- Mar 26, 2022
-
-
Tushar Patel authored
Compute-only GPUs have more than 8 VMIDs allocated to KFD. Fix this by passing correct number of VMIDs to HWS v2: squash in warning fix (Alex) Signed-off-by:
Tushar Patel <tushar.patel@amd.com> Reviewed-by:
Felix Kuehling <felix.kuehling@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Charlene Liu authored
[why and how] TMDS does not need destructive verify link Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
Alan Liu <HaoPing.Liu@amd.com> Acked-by:
Alex Hung <alex.hung@amd.com> Signed-off-by:
Charlene Liu <Charlene.Liu@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
-
Gabe Teeger authored
[why] When we enter FREESYNC_STATE_VIDEO, we want to use the extra vblank portion to enter zstate if possible. [how] When we enter freesync, a full update is triggered and the new vtotal with extra lines is passed to dml in a stream update. The time gained from extra vblank lines is calculated in microseconds. We allow zstate entry if the time gained is greater than 5 ms, which is the current policy. Furthermore, an optimized value for min_dst_y_next_start is calculated and written to its register. When exiting freesync, another full update is triggered and default values are restored. Reviewed-by:
Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by:
Gabe Teeger <gabe.teeger@amd.com> Tested-by:
-
Emily Deng authored
Correct the code error for setting register UVD_GFX10_ADDR_CONFIG. Need to use inst_idx, or it only will set VCN0. Signed-off-by:
Emily Deng <Emily.Deng@amd.com> Reviewed-by:
James Zhu <James.Zhu@amd.com> Signed-off-by:
-
Leo (Hanghong) Ma authored
[Why & How] The latest HDMI SPEC has updated the VTEM packet structure, so change the VTEM Infopacket defined in the driver side to align with the SPEC. Reviewed-by:
Chris Park <Chris.Park@amd.com> Acked-by:
Leo (Hanghong) Ma <hanghong.ma@amd.com> Tested-by:
-
Oliver Logush authored
[why] Needed to support dcn315 Reviewed-by:
Oliver Logush <oliver.logush@amd.com> Tested-by:
-
Chiawen Huang authored
[Why] disable/enable leads FEC mismatch between hw/sw FEC state. [How] check FEC status to fastboot on/off. Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
Chiawen Huang <chiawen.huang@amd.com> Tested-by:
-
Rodrigo Siqueira authored
Linux kernel enabled more compilation restrictions related to the stack size, which caused compilation failures in our code. This commit reduces the allocation size by allocating the required memory dynamically. Reviewed-by:
Harry Wentland <Harry.Wentland@amd.com> Reviewed-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Tested-by:
-
Charlene Liu authored
[why] for the case edid change only changed audio format. driver still need to update stream. Reviewed-by:
Alvin Lee <Alvin.Lee2@amd.com> Reviewed-by:
-
Nicholas Kazlauskas authored
[Why] It changed since dcn30 but the hubbub31 constructor hasn't been modified to reflect this. [How] Update the value in the constructor to 0x6 so we're checking the right bits for p-state allow. It worked before by accident, but can falsely assert 0 depending on HW state transitions. The most frequent of which appears to be when all pipes turn off during IGT tests. Cc: Harry Wentland <harry.wentland@amd.com> Fixes: e7031d82 ("drm/amd/display: Add pstate verification and recovery for DCN31") Signed-off-by:
Eric Yang <Eric.Yang2@amd.com> Acked-by:
-
Stanley.Yang authored
It must check asic whether support smu before call smu powerplay function, otherwise it may cause null point on no support smu asic. Signed-off-by:
Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Lang Yu authored
It is a hardware issue that VCN can't handle a GTT backing stored TMZ buffer on CHIP_RAVEN series ASIC. Move such a TMZ buffer to VRAM domain before command submission as a workaround. v2: - Use patch_cs_in_place callback. v3: - Bail out early if unsecure IBs. Suggested-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Lang Yu <Lang.Yu@amd.com> Reviewed-by:
-
Alex Deucher authored
If the GPU is passed through to a guest VM, use the PCI BAR for CPU FB access rather than the physical address of carve out. The physical address is not valid in a guest. v2: Fix HDP handing as suggested by Michel Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Signed-off-by:
-
Dan Carpenter authored
This post-op should be a pre-op so that we do not pass -1 as the bit number to test_bit(). The current code will loop downwards from 63 to -1. After changing to a pre-op, it loops from 63 to 0. Fixes: 71c37505 ("drm/amdgpu/gfx: move more common KIQ code to amdgpu_gfx.c") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Yifan Zhang authored
If GFX DPM is disbaled, Stable pstate Test in amdgpu_test fails. Check GFX DPM statue before change clock level Log: [ 46.595274] [drm] Initialized amdgpu 3.46.0 20150101 for 0000:02:00.0 on minor 0 [ 46.599929] fbcon: amdgpudrmfb (fb0) is primary device [ 46.785753] Console: switching to colour frame buffer device 240x67 [ 46.811765] amdgpu 0000:02:00.0: [drm] fb0: amdgpudrmfb frame buffer device [ 131.398407] amdgpu 0000:02:00.0: amdgpu: Failed to set performance level! Signed-off-by:
Yifan Zhang <yifan1.zhang@amd.com> Acked-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Guchun Chen authored
Use amdgpu_bo_free_kernel instead of amdgpu_bo_unref to perform a proper cleanup of PDB bo. v2: update subject to be more accurate Signed-off-by:
Guchun Chen <guchun.chen@amd.com> Reviewed-by:
-
Guchun Chen authored
On GPUs with RAS enabled, below call trace is observed when suspending or shutting down device. The cause is we have enabled memory wipe flag for BOs on such GPUs by default, and such BOs will go to memory wipe by amdgpu_fill_buffer, however, because ring is off already, it fails to clean up the memory and throw this error message. So add a suspend/shutdown check before wipping memory. [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear memory with ring turned off. v2: fix coding style issue Fixes: fc6ea4be ("drm/amdgpu: Wipe all VRAM on free when RAS is enabled") Signed-off-by:
-
- Mar 22, 2022
-
-
Aurabindo Pillai authored
[Why&How] Add a dedicated AMDGPU specific ID for use with newer ASICs that support USB-C output Signed-off-by:
Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by:
-
- Mar 21, 2022
-
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.18-2022-03-18' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.18-2022-03-18: amdgpu: - Aldebaran fixes - SMU 13.0.5 fixes - DCN 3.1.5 fixes - DCN 3.1.6 fixes - Pipe split fixes - More display FP cleanup - DP 2.0 UHBR fix - DC GPU reset fix - DC deep color ratio fix - SMU robustness fixes - Runtime PM fix for APUs - IGT reload fixes - SR-IOV fix - Misc fixes and cleanups amdkfd: - CRIU fixes - SVM fixes UAPI: - Properly handle SDMA transfers with CRIU Proposed user mode change: https://github.com/checkpoint-restore/criu/pull/1709 Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220318203717.5833-1-alexander.deucher@amd.com
-
- Mar 18, 2022
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2022-03-17' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Do not re-enable PSR after it was marked as not reliable (Jose) - Add missing boundary check in vm_access to avoid out-of-bounds access (Mastan) - Naming fix for HPD short pulse handling for eDP (Jose) Signed-off-by:
-
- Mar 16, 2022
-
-
José Roberto de Souza authored
If a error happens and sink_not_reliable is set, PSR should be disabled for good but that is not happening. It would be disabled by the function handling the PSR error but then on the next fastset it would be enabled again in _intel_psr_post_plane_update(). It would only be disabled for good in the next modeset where has_psr will be set false. v2: - release psr lock before continue Fixes: 9ce5884e ("drm/i915/display: Only keep PSR enabled if there is active planes") Reported-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Reported-by:
Charlton Lin <charlton.lin@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311185149.110527-2-jose.souza@intel.com (cherry picked from commit 15f26bdc ) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
José Roberto de Souza authored
Commit 13ea6db2 ("drm/i915/edp: Ignore short pulse when panel powered off") completely broke short pulse handling for eDP as it is usually generated by sink when it is displaying image and there is some error or status that source needs to handle. When power panel is enabled, this state is enough to power aux transactions and VDD override is disabled, so intel_pps_have_power() is always returning false causing short pulses to be ignored. So here better naming this function that intends to check if aux lines are powered to avoid the endless cycle mentioned in the commit being fixed and fixing the check for what it is intended. v2: - renamed to intel_pps_have_panel_power_or_vdd() - fixed indentation Fixes: 13ea6db2 ("drm/i915/edp: Ignore short pulse when panel powered off") Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: amd-gfx@lists.freedesktop.org Reviewed-by: -
Ville Syrjälä authored
struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Cc: Alex Deucher <alexander.deucher@amd.com> Cc: amd-gfx@lists.freedesktop.org Signed-off-by: -
Paul Menzel authored
Remove the boilerplate of declaring a variable and using an if else statement by using the ternary operator. Reviewed-by:
Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by:
-
Ville Syrjälä authored
These on stack copies of the modes appear to be pointless. Just look at the originals directly. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: amd-gfx@lists.freedesktop.org Cc: Nikola Cornij <nikola.cornij@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by:
-
Dan Carpenter authored
Smatch complains that the dev_err_ratelimited() is indented one tab more than the surrounding lines. drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:174 __smu_cmn_reg_print_error() warn: inconsistent indenting It looks like it's not a bug, just that the indenting needs to be cleaned up. Reviewed-by:
Luben Tuikov <luben.tuikov@amd.com> Signed-off-by:
-
Julia Lawall authored
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by:
-
Julia Lawall authored
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by:
-
Julia Lawall authored
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by:
-
Yongqiang Sun authored
MI25 SRIOV guest driver loading failed due to allocated memory overlaps with firmware reserved area. Allocate stolen reserved memory for MI25 SRIOV specifically to avoid the memory overlap. Reviewed-by:
Yongqiang Sun <yongqiang.sun@amd.com> Signed-off-by:
-
Yongqiang Sun authored
Some ASICs need reserved memory for firmware or other components, which is not allowed to be used by driver. amdgpu_gmc_get_reserved_allocation is to handle additional areas. To avoid any missing calling, merged amdgpu_gmc_get_reserved_allocation to amdgpu_gmc_get_vbios_allocations. Acked-by:
-
Philip Yang authored
Migrate vram to ram may fail to find the vma if process is exiting and vma is removed, evict svm bo worker sets prange->svm_bo to NULL and warn svm_bo ref count != 1 only if migrating vram to ram successfully. Signed-off-by:
Philip Yang <Philip.Yang@amd.com> Reviewed-by:
-
Tianci Yin authored
[why] On Renoir, vcn ring test failed on the second time insmod in the reload test. After investigation, it proves that vcn only can disable dpg under dpg unpause mode (dpg unpause mode is default for dec only, dpg pause mode is for dec/enc). [how] unpause dpg in dpg stopping procedure. Reviewed-by:
Tianci Yin <tianci.yin@amd.com> Signed-off-by:
-
Lang Yu authored
Only GFX ring, SDMA ring and VCN decode ring support secure submission at the moment. Suggested-by:
-
yipechai authored
The reported warnings are as follows: 1.warning:no-previous-prototype-for-amdgpu_hdp_ras_fini. 2.warning:no-previous-prototype-for-amdgpu_mmhub_ras_fini. Amdgpu_hdp_ras_fini and amdgpu_mmhub_ras_fini are unused in the code, they are the only functions in amdgpu_hdp.c and amdgpu_mmhub.c. After removing these two functions, both amdgpu_hdp.c and amdgpu_mmhub.c are empty, so these two files can be deleted to fix the warning. Signed-off-by:
yipechai <YiPeng.Chai@amd.com> Reviewed-by:
Tao Zhou <tao.zhou1@amd.com> Signed-off-by:
-
Aric Cyr authored
This version brings along following fixes: - Added I2C escape to support query exist - Functionality to get pipe from stream context - debugfs entry fixes - Block zstate when more than one plane enabled - Update to engine ddc - Reading lante status during LT fixes - Null point filters - [FW Promotion] Release 0.0.108.0 Acked-by:Agustin Gutierrez <agustin.gutierrez@amd.com> Signed-off-by:
-
Anthony Koo authored
Reviewed-by:
-
Charlene Liu authored
[why] DCN31 has this in zstate save/restore sequence. need for non_zstate supported ASIC [how] add this PANEL_PWRSEQ_REF_DIV2 to existing panel_cntl_hw_init structure. Reviewed-by:
-
Becle Lee authored
[Why] Underflow occurred while hubp ret pipe read is idle and the second pipe is powered up and added. Flickering and underflow are only observed on Pollock. [How] Check the hubp ret pipe read prior to unlock pipes. Reviewed-by:
Hersen Wu <hersenxs.wu@amd.com> Reviewed-by:
Becle Lee <becle.lee@amd.com> Tested-by:
-
