- 10 Nov, 2022 6 commits
-
-
Tong Liu01 authored
Move TMR region from top of FB to 2MB for FFBM, so we need to reserve TMR region firstly to make sure TMR can be allocated at 2MB Signed-off-by:
Tong Liu01 <Tong.Liu01@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Tao Zhou authored
The initialized status indicates RAS TA is loaded, but in some cases (such as RAS fatal error) RAS TA could be destroyed although it's not unloaded. Hence we load RAS TA unconditionally here. Signed-off-by:
Tao Zhou <tao.zhou1@amd.com> Reviewed-by:
Candice Li <candice.li@amd.com> Signed-off-by:
-
Kenneth Feng authored
skip disabling all smu features on smu_v13_0_10 in suspend Signed-off-by:
Kenneth Feng <kenneth.feng@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Yifan Zhang authored
If discovery is set to 2 in module parameters explicitly, the intention is to use the discovery file in FW rather than the one in BIOS, usually because the latter is incorrect. This patch to force read discovery file if set discovery=2. Signed-off-by:
Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by:
Tim Huang <Tim.Huang@amd.com> Signed-off-by:
-
Andrew Davis authored
Most Kconfig options to enable a driver are in the Kconfig file inside the relevant directory, move these two to the same. Signed-off-by:
Andrew Davis <afd@ti.com> Reviewed-by:
-
Takashi Iwai authored
This patch adds the support for the notification of HD-audio hotplug via the already existing drm_audio_component framework to radeon driver. This allows us more reliable hotplug notification and ELD transfer without accessing HD-audio bus; it's more efficient, and more importantly, it works without waking up the runtime PM. The implementation is rather simplistic: radeon driver provides the get_eld ops for HD-audio, and it notifies the audio hotplug via pin_eld_notify callback upon each radeon_audio_enable() call. The pin->id is referred as the port number passed to the notifier callback, and the corresponding connector is looked through the encoder list in the get_eld callback in turn. The bind and unbind callbacks handle the device-link so that it assures the PM call order. Also, as a gratis bonus, this patch "fixes" the regression by the recent change in HD-audio to be more strict for the HDMI/DP connection, too. Since the HD-audio HDMI/DP codec requires both the connection bit and the valid ELD to be provided, it started failing on some RADEON gfx boards where the ELD update performed instably. As this change switches the communication to a direct way between the audio and the graphics drivers, now the system receives the proper ELD, and the HDMI/DP hotplug starts working again. [ v2: fix the logic in radeon_audio_component_get_eld to walk the connector list since that is where the EDID lives and we can derive the encoder from the connector because the encoder has not been assigned at this point (i.e., during monitor probe). v3: the component binding is moved outside radeon_audio_init() and _fini(), as those are called from suspend/resume, too. Drop modeset lock calls that caused Oops. Moved Kconfig change so that it can be applied on older kernels. v4: revive drm_modeset_lock*() again, add the missing device_link_remove() call at unbinding v5: squash in mutex fix v6: squash in fix for audio get_eld callback ] Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1569Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
- 09 Nov, 2022 34 commits
-
-
Felix Kuehling authored
The same BO may need different MTYPEs and SNOOP flags in PTEs depending on its current location relative to the mapping GPU. Setting MTYPEs from clients ahead of time is not practical for coherent memory sharing. Instead determine the correct MTYPE for the desired coherence model and current BO location when updating the page tables. To maintain backwards compatibility with MTYPE-selection in AMDGPU_VA_OP_MAP, the coherence-model-based MTYPE selection is only applied if it chooses an MTYPE other than MTYPE_NC (the default). Add two AMDGPU_GEM_CREATE_... flags to indicate the coherence model. The default if no flag is specified is non-coherent (i.e. coarse-grained coherent at dispatch boundaries). Update amdgpu_amdkfd_gpuvm.c to use this new method to choose the correct MTYPE depending on the current memory location. v2: * check that bo is not NULL (e.g. PRT mappings) * Fix missing ~ bitmask in gmc_v11_0.c v3: * squash in "drm/amdgpu: Inherit coherence flags on dmabuf import" Suggested-by:
Felix Kuehling <Felix.Kuehling@amd.com> Acked-by:
-
Hamza Mahfooz authored
Currently, we are calling fill_dc_dirty_rects() even if PSR isn't supported by the relevant link in amdgpu_dm_commit_planes(), this is undesirable especially because when drm.debug is enabled we are printing messages in fill_dc_dirty_rects() that are only useful for debugging PSR (and confusing otherwise). So, we can instead limit the filling of dirty rectangles to only when PSR is enabled. Reviewed-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by:
Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by:
-
LongJun Tang authored
In dcn*_clock_source_create when dcn*_clk_src_construct fails allocated clk_src needs release. A local attack could use this to cause memory exhaustion. Signed-off-by:
LongJun Tang <tanglongjun@kylinos.cn> Signed-off-by:
-
Paulo Miguel Almeida authored
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in structs _ATOM_GPIO_PIN_ASSIGNMENT, _ATOM_DISPLAY_OBJECT_PATH, _ATOM_DISPLAY_OBJECT_PATH_TABLE, _ATOM_OBJECT_TABLE and refactor the rest of the code accordingly. Important to mention is that doing a build before/after this patch results in no functional binary output differences. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/238 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] Signed-off-by:
Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> Signed-off-by:
-
Hanjun Guo authored
When the radeon driver reads the bios information from ACPI table in radeon_acpi_vfct_bios(), it misses to call acpi_put_table() to release the ACPI memory after the init, so add acpi_put_table() properly to fix the memory leak. v2: fix text formatting (Alex) Fixes: 268ba0a9 ("drm/radeon: implement ACPI VFCT vbios fetch (v3)") Signed-off-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
-
Harsh Jain authored
change guarantees that gfxoff is allowed before moving further in s2idle sequence to add more reliablity about gfxoff in amdgpu IP's suspend flow Signed-off-by:
Harsh Jain <harsh.jain@amd.com> Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Luben Tuikov authored
Abstract RAS I2C EEPROM addresses from chip names, and set their macro definition names to the address they set, not the chip they attach to. Since most chips either use I2C EEPROM address 0 or 40000h for the RAS table start offset, this leaves us with only two macro definitions as opposed to five, and removes the redundancy of four. Cc: Candice Li <candice.li@amd.com> Cc: Tao Zhou <tao.zhou1@amd.com> Cc: Alex Deucher <Alexander.Deucher@amd.com> Signed-off-by:
Luben Tuikov <luben.tuikov@amd.com> Reviewed-by:
Kent Russell <kent.russell@amd.com> Reviewed-by:
-
Luben Tuikov authored
Remove redundant EEPROM_I2C_MADDR_54H address, since we already have it represented (ARCTURUS), and since we don't include the I2C device type identifier in EEPROM memory addresses, i.e. that high up in the device abstraction--we only use EEPROM memory addresses, as memory is continuously represented by EEPROM device(s) on the I2C bus. Add a comment describing what these memory addresses are, how they come about and how they're usually extracted from the device address byte. Cc: Candice Li <candice.li@amd.com> Cc: Tao Zhou <tao.zhou1@amd.com> Cc: Alex Deucher <Alexander.Deucher@amd.com> Fixes: c9bdc6c3 ("drm/amdgpu: Add EEPROM I2C address support for ip discovery") Signed-off-by:
-
Ma Jun authored
kfd_fill_cache_non_crat_info() is only used in kfd_topology.c, so make it as static. Signed-off-by:
Ma Jun <Jun.Ma2@amd.com> Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Kenneth Feng authored
enable mode1 reset and prioritize debug port on smu_v13_0_10 as a more reliable message processing v2 - move mode1 reset callback to smu_v13_0_0_ppt.c Signed-off-by:
Yang Wang <kevinyang.wang@amd.com> Signed-off-by:
-
Ma Jun authored
Fix the memory overrun issue caused by wrong array size. Signed-off-by:
coverity-bot <keescook+coverity-bot@chromium.org> Addresses-Coverity-ID: 1527133 ("Memory - corruptions") Fixes: c0cc999f ("drm/amdkfd: Fix the warning of array-index-out-of-bounds") Signed-off-by:
-
Guchun Chen authored
Still avoid intermittent failure. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Acked-by:
-
Philip Yang authored
Re-take the eviction lock immediately again after the allocation is completed, to fix circular locking warning with drm_buddy allocator. Move amdgpu_vm_eviction_lock/unlock/trylock to amdgpu_vm.h as they are called from multiple files. Signed-off-by:
Philip Yang <Philip.Yang@amd.com> Reviewed-by:
-
Philip Yang authored
Get below kernel WARNING backtrace when pressing ctrl-C to kill kfdtest application. If amdgpu_cs_parser_bos returns error after taking bo_list_mutex, as caller amdgpu_cs_ioctl will not unlock bo_list_mutex, this generates the kernel WARNING. Add unlock bo_list_mutex after amdgpu_cs_parser_bos error handling to cleanup bo_list userptr bo. WARNING: kfdtest/2930 still has locks held! 1 lock held by kfdtest/2930: (&list->bo_list_mutex){+.+.}-{3:3}, at: amdgpu_cs_ioctl+0xce5/0x1f10 [amdgpu] stack backtrace: dump_stack_lvl+0x44/0x57 get_signal+0x79f/0xd00 arch_do_signal_or_restart+0x36/0x7b0 exit_to_user_mode_prepare+0xfd/0x1b0 syscall_exit_to_user_mode+0x19/0x40 do_syscall_64+0x40/0x80 Signed-off-by: -
Aric Cyr authored
DC version 3.2.211 brings along the following fixes: - Wait for VBLANK during pipe programming - Adding HDMI SCDC DEVICE_ID define - Cursor update refactor: PSR-SU support condition - Update 709 gamma to 2.222 as stated in the standerd - Consider dp cable id only when data is non zero - Waiting for 1 frame to fix the flash issue on PSR1 - Update SR watermarks for DCN314 - Allow tuning DCN314 bounding box - Zeromem mypipe heap struct before using it - Use min transition for SubVP into MPO - Disable phantom OTG after enable for plane disable - Disable DRR actions during state commit - Fix fallback issues for DP LL 1.4a tests - Fix FCLK deviation and tool compile issues - Fix reg timeout in enc314_enable_fifo - Fix gpio port mapping issue - Only update link settings after successful MST link train - Enforce minimum prefetch time for low memclk on DCN32 - Set correct EOTF and Gamut flag in VRR info - Add margin for max vblank time for SubVP + DRR - Populate DP2.0 output type for DML pipe Acked-by:
Alan Liu <HaoPing.Liu@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
-
Asher Song authored
This reverts commit 4545ae2e. The origin patch "drm/amdgpu: getting fan speed pwm for vega10 properly" works fine. Test failure is caused by test case self. Signed-off-by:
Asher Song <Asher.Song@amd.com> Reviewed-by:
-
Rajneesh Bhardwaj authored
amdgpu_ttm_tt_set_userptr() is also called by the KFD as part of initializing the user pages for userptr BOs and also while initializing the GPUVM for a KFD process so update the function description. Reviewed-by:
Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com> Signed-off-by:
-
George Shen authored
[Why] DCN3.2 DML logic uses a new output type for DP2.0, which will enable validation to pass for higher BW timings that require DP2.0 link rates. [How] Populate the DML pipe with DP2.0 output type if the signal type of the pipe_ctx is 128b/132b. Reviewed-by:
Alvin Lee <Alvin.Lee2@amd.com> Acked-by:
Jasdeep Dhillon <jasdeep.dhillon@amd.com> Signed-off-by:
George Shen <george.shen@amd.com> Tested-by:
-
Alvin Lee authored
[Description] - Incorporate FW delays as port of max VTOTAL calculated for SubVP + DRR cases (since it is part of the microschedule). - Also add margin for the max VTOTAL possible for SubVP + DRR cases. - Due to rounding errors in FW (integer arithmetic), the microschedule calculation can get pushed to the next frame (incorrectly) in cases where we use the max VTOTAL possible to complete the MCLK switch. - When the rounding error occurs, we are only off by 1-2 lines, use 40us margin which is working consistently. Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Reviewed-by:
-
Mike Hsieh authored
[Why] FreeSync always use G2.2 EOTF and Native gamut [How] Set EOTF and Gamut flags accordingly Reviewed-by:
Krunoslav Kovac <Krunoslav.Kovac@amd.com> Acked-by:
Mike Hsieh <Mike.Hsieh@amd.com> Tested-by:
-
Dillon Varone authored
[WHY?] Data return times when using lowest memclk can be <= 60us, which can cause underflow on high bandwidth displays with a workload. [HOW?] Enforce a minimum prefetch time during validation for low memclk modes. Reviewed-by:
Dillon Varone <Dillon.Varone@amd.com> Tested-by:
-
Michael Strauss authored
[WHY] Currently driver reduces verified link caps on DPIA devices if a link is trained at a link rate below the max rate verified during link detection. This blocks high bandwidth modes after setting a low bandwidth mode. [HOW] Only update link rate after a successful link train if link is MST. Reviewed-by:
Mustapha Ghaddar <Mustapha.Ghaddar@amd.com> Acked-by:
Michael Strauss <michael.strauss@amd.com> Tested-by:
-
Steve Su authored
[Why] 1. Port of gpio has different mapping. [How] 1. Add a dummy entry in mapping table. 2. Fix incorrect mask bit field access. Reviewed-by:
Steve Su <steve.su@amd.com> Tested-by:
-
Nicholas Kazlauskas authored
[Why] The link enablement sequence can end up resetting the encoder while the PHY symclk isn't yet on. This means that waiting for symclk on will timeout, along with the reset bit never asserting high. This causes unnecessary delay when enabling the link and produces a warning affecting multiple IGT tests. [How] Don't wait for the symclk to be on here because firmware already does. Don't wait for reset if we know the symclk isn't on. Split the reset into a helper function that checks the bit and decides whether or not a delay is sufficient. Reviewed-by:
Roman Li <Roman.Li@amd.com> Acked-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Tested-by:
-
Chaitanya Dhere authored
[Why] Recent backports from open source do not have header inclusion pattern that is consistent with inclusion style in the rest of the file. This breaks the internal tool builds as well. A recent commit erronously modified the original DML formula for calculating ActiveClockChangeLatencyHidingY. This resulted in a FCLK deviation from the golden values. [How] Change the way in which display_mode_vba.h is included so that it is consistent with the inclusion style in rest of the file which also fixes the tool build. Restore the DML formula to its original state to fix the FCLK deviation. Reviewed-by:
Aurabindo Pillai <Aurabindo.Pillai@amd.com> Reviewed-by:
Chaitanya Dhere <chaitanya.dhere@amd.com> Tested-by:
-
Mustapha Ghaddar authored
[WHY] Unlike DP or USBC, the USB4 link does not get its own encoder and has to share therefore verify_caps is skipped. [HOW] Fix the fallback logic for automated tests and take that into consideration for LT and LS. Reviewed-by:
-
Wesley Chalmers authored
[WHY] Committing a state while performing DRR actions can cause underflow. [HOW] Disabled features performing DRR actions during state commit. Need to follow-up on why DRR actions affect state commit. Reviewed-by:
Wesley Chalmers <Wesley.Chalmers@amd.com> Tested-by:
-
Alvin Lee authored
[Description] - Need to disable phantom OTG after it's enabled in order to restore it to it's original state. - If it's enabled and then an MCLK switch comes in we may not prefetch the correct data since the phantom OTG could already be in the middle of the frame. Reviewed-by:
-
Alvin Lee authored
[Description] - For SubVP transitioning into MPO, we want to use a minimal transition to prevent transient underflow - Transitioning a phantom pipe directly into a "real" pipe can result in underflow due to the HUBP still having it's "phantom" programming when HUBP is unblanked (have to wait for next VUPDATE of the new OTG) - Also ensure subvp pipe lock is acquired early enough for programming in dc_commit_state_no_check - When disabling phantom planes, enable phantom OTG first so the disable gets the double buffer update Reviewed-by:
-
Aurabindo Pillai authored
[Why&How] Bug was caused when moving variable from stack to heap because it was reusable and garbage was left over, so we need to zero mem. Reviewed-by:
Martin Leung <Martin.Leung@amd.com> Acked-by:
-
Nicholas Kazlauskas authored
[Why] We're missing the helpers from dcn20 that would allow overriding these with DC debug options. [How] Use dcn20_patch_bounding_box to support overriding all the relevant values. Reviewed-by:
-
Nicholas Kazlauskas authored
[Why & How] New values requested by hardware after fine-tuning. Update for all memory types. Reviewed-by:
-
Ryan Lin authored
[Why] Needs more frames waiting before the PSR_Exit sending for the specific TCON. [How] Add relock_delay_frame_cnt to control how many frames waiting are needed before the PSR_Exit sending. The default value is 0. The Driver side can set this variable for specific TCONs. Reviewed-by:
Robin Chen <robin.chen@amd.com> Acked-by:
Ryan Lin <tsung-hua.lin@amd.com> Tested-by:
-
Wenjing Liu authored
Cable ID is a DP2 feature to identify max certified link rate that a cable can carry. The cable identification method requires both cable and display hardware support. Since the specs comes late, it is anticipated that the first round of DP2 cables and displays may not be fully compatible to reliably return cable ID data. Therefore the decision of our cable id policy is that if the cable can return non zero cable id data, we will take cable's link rate capability into account. However if we get zero data, the cable link rate capability is considered inconclusive. In this case, we will not take cable's capability into account to avoid of over limiting hardware capability from users. The max overall link rate capability is still determined after actual dp pre-training. Cable id is considered as an auxiliary method of determining max link bandwidth capability. Reviewed-by:
Wenjing Liu <wenjing.liu@amd.com> Tested-by:
-
