- 04 Aug, 2020 21 commits
-
-
Dmytro Laktyushkin authored
Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by:
Eric Bernstein <Eric.Bernstein@amd.com> Acked-by:
Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Igor Kravchenko authored
[Why] For ver.4.4 and higher VBIOS contains default setting table. {How] Read Golden Settings Table from VBIOS, apply Aux tuning parameters. Signed-off-by:Igor Kravchenko <Igor.Kravchenko@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
-
Eric Bernstein authored
Signed-off-by:
Chris Park <Chris.Park@amd.com> Acked-by:
-
Eric Bernstein authored
Signed-off-by:
-
Eryk Brol authored
[Why] We need to be able to specify slice height for any connector's DSC [How] Overwrite computed parameters in dsc_cfg, with the value needed/ Overwrites for both SST and MST connectors, but in different places, but the process is identical. Overwrites only if DSC is decided to be enabled on that connector. Signed-off-by:
Eryk Brol <eryk.brol@amd.com> Signed-off-by:
Mikita Lipski <mikita.lipski@amd.com> Reviewed-by:
-
John Clements authored
updated RAS EEPROM init/threshold sequences to check for device support Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Signed-off-by:
John Clements <john.clements@amd.com> Signed-off-by:
-
John Clements authored
enabled GECC error injection and query support Reviewed-by:
-
Monk Liu authored
what: the MQD's save and restore of KCQ (kernel compute queue) cost lots of clocks during world switch which impacts a lot to multi-VF performance how: introduce a paramter to control the number of KCQ to avoid performance drop if there is no kernel compute queue needed notes: this paramter only affects gfx 8/9/10 v2: refine namings v3: choose queues for each ring to that try best to cross pipes evenly. v4: fix indentation some cleanupsin the gfx_compute_queue_acquire() v5: further fix on indentations more cleanupsin gfx_compute_queue_acquire() TODO: in the future we will let hypervisor driver to set this paramter automatically thus no need for user to configure it through modprobe in virtual machine Signed-off-by:
Monk Liu <Monk.Liu@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Guchun Chen authored
During driver's probe, when it hits bad gpu tag in eeprom i2c init calling(the tag was set when reported bad page reaches bad page threshold in last driver's working loop), there are some strategys to deal with the cases: 1. when the module parameter amdgpu_bad_page_threshold = 0, that means page retirement feature is disabled, so just resetting the eeprom is fine. 2. When amdgpu_bad_page_threshold is not 0, and moreover, user sets one bigger valid data in order to make current boot up succeeds, correct eeprom header tag and do not break booting. 3. For other cases, driver's probe will be broken. v2: Just update eeprom header tag instead of resetting the whole table header when user sets one bigger threshold data. v3: Use dev_info/dev_err to print PCI device information, which helps in mGPU case. Signed-off-by:Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Guchun Chen authored
When amdgpu_bad_page_threshold = 0, bad page reservation stuffs are skipped in either UMC ECC irq or page retirement calling of sync flood isr. Signed-off-by:
-
Guchun Chen authored
Bad page information should not be exposed by sysfs when bad page retirement is disabled, so decouple it from ras sysfs group creating, and add one guard before creating. Signed-off-by:
-
Guchun Chen authored
Add one definition for the RAS module's FS name. It's used in both debugfs and sysfs cases. v2: Use static variable instead of macro definition. Signed-off-by:
-
Guchun Chen authored
RAS flags needs to be cleaned as well when user requires one clean eeprom. v2: RAS flags shall be restored after eeprom reset succeeds. Signed-off-by:
-
Guchun Chen authored
When GPU executes recovery and retriving bad GPU tag from external eerpom device, the recovery will be broken and error message is printed as well for user's awareness. v2: Refine warning message in threshold reaching case, and fix spelling typo. v3: Fix explicit calling of bad gpu. v4: Rename function names. Signed-off-by: -
Guchun Chen authored
Once the bad page saved to eeprom reaches the configured threshold, ras recovery will be issued to notify user. v2: Fix spelling typo. Signed-off-by:
-
Guchun Chen authored
Once the ras recovery is issued from eeprom write itself, bad page reservation should be ignored, otherwise, recursive calling of writting to eeprom would happen. Signed-off-by:
-
Guchun Chen authored
When retrieving bad gpu tag from eeprom, GPU init should fail as the GPU needs to be retired for further check. v2: Fix spelling typo, correct the condition to detect bad gpu tag and refine error message. v3: Refine function argument name. v4: Fix missing check of returning value of i2c initialization error case. v5: Use dev_err to print PCI information in dmesg instead of DRM_ERROR. Signed-off-by: -
Guchun Chen authored
This tag will be hired for bad gpu detection in eeprom's access. Signed-off-by:
-
Guchun Chen authored
Bad page threshold value should be valid in the range between -1 and max records length of eeprom. It could determine when saved bad pages exceed threshold value, and proceed corresponding actions. v2: When using the default typical value, it should be min value between typical value and eeprom max records length. v3: drop the case of setting bad_page_cnt_threshold to be 0xFFFFFFFF, as it confuses user. Signed-off-by: -
Guchun Chen authored
bad_page_threshold could be configured to enable/disable the associated bad page retirement feature in RAS. When it's -1, ras will use typical bad page failure value to handle bad page retirement. When it's 0, disable bad page retirement, and no bad page will be recorded and saved. For other valid value, driver will use this manual value as the threshold value of totoal bad pages. v2: correct documentation of this parameter. v3: remove confused statement in documentation. Signed-off-by:
-
Mukul Joshi authored
Event bitmask is a 64-bit mask with only 1 bit set. Sending this event bitmask in KFD SMI event message is both wasteful of memory and potentially limiting to only 64 events. Instead send event index in SMI event message. Please note this change does not break the ABI for the two event types defined so far. The new index is identical to the mask used before. Signed-off-by:
Mukul Joshi <mukul.joshi@amd.com> Suggested-by:
-
- 30 Jul, 2020 19 commits
-
-
Alex Deucher authored
This regressed some working configurations so revert it. Will fix this properly for 5.9 and backport then. This reverts commit 38e0c89a. Signed-off-by:
-
Jiansong Chen authored
Enable GFXOFF for navy_flounder. Signed-off-by:
Jiansong Chen <Jiansong.Chen@amd.com> Reviewed-by:
Likun Gao <Likun.Gao@amd.com> Signed-off-by:
-
Liu ChengZhe authored
1. For Navi12, CHIP_SIENNA_CICHLID, skip tmr load operation; 2. Check pointer before release firmware. v2: use CHIP_SIENNA_CICHLID instead v3: remove local "bool ret"; fix grammer issue v4: use my name instead of "root" v5: fix grammer issue and indent issue Signed-off-by:
Liu ChengZhe <ChengZhe.Liu@amd.com> Reviewed-by:
Luben Tuikov <luben.tuikov@amd.com> Signed-off-by:
-
Liu ChengZhe authored
Assigning false to block->status.hw overwrites PSP's previous hardware status, which causes the PSP to Resume operation after hardware init. Remove this assignment and let the PSP execute Resume operation when it is told to. v2: Remove the braces. v3: Modify the description. Signed-off-by:
-
Daniel Vetter authored
Trying to grab dma_resv_lock while in commit_tail before we've done all the code that leads to the eventual signalling of the vblank event (which can be a dma_fence) is deadlock-y. Don't do that. Here the solution is easy because just grabbing locks to read something races anyway. We don't need to bother, READ_ONCE is equivalent. And avoids the locking issue. v2: Also take into account tmz_surface boolean, plus just delete the old code. Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: linux-rdma@vger.kernel.org Cc: amd-gfx@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Li Heng authored
Remove casting the values returned by memory allocation function. Coccinelle emits WARNING: ./drivers/gpu/drm/amd/powerplay/hwmgr/vega20_processpptables.c:893:37-46: WARNING: casting value returned by memory allocation function to (PPTable_t *) is useless. Signed-off-by:
Li Heng <liheng40@huawei.com> Signed-off-by:
-
Peilin Ye authored
Compiler leaves a 4-byte hole near the end of `dev_info`, causing amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace when `size` is greater than 356. In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which unfortunately does not initialize that 4-byte hole. Fix it by using memset() instead. Cc: stable@vger.kernel.org Fixes: c193fa91 ("drm/amdgpu: information leak in amdgpu_info_ioctl()") Fixes: d38ceaf9 ("drm/amdgpu: add core driver (v4)") Suggested-by:Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by:
-
Mazin Rezk authored
This patch fixes a race condition that causes a use-after-free during amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking commits are requested and the second one finishes before the first. Essentially, this bug occurs when the following sequence of events happens: 1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is deferred to the workqueue. 2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is deferred to the workqueue. 3. Commit #2 starts before commit #1, dm_state #1 is used in the commit_tail and commit #2 completes, freeing dm_state #1. 4. Commit #1 starts after commit #2 completes, uses the freed dm_state 1 and dereferences a freelist pointer while setting the context. Since this bug has only been spotted with fast commits, this patch fixes the bug by clearing the dm_state instead of using the old dc_state for fast updates. In addition, since dm_state is only used for its dc_state and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is found, removing the dm_state should not have any consequences in fast updates. This use-after-free bug has existed for a while now, but only caused a noticeable issue starting from 5.7-rc1 due to 3202fa62 ("slub: relocate freelist pointer to middle of object") moving the freelist pointer from dm_state->base (which was unused) to dm_state->context (which is dereferenced). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207383 Fixes: bd200d19 ("drm/amd/display: Don't replace the dc_state for fast updates") Reported-by:
Duncan <1i5t5.duncan@cox.net> Signed-off-by:
Mazin Rezk <mnrzk@protonmail.com> Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
Jiansong Chen authored
Update GC golden setting for navy_flounder. Signed-off-by:
Tao Zhou <tao.zhou1@amd.com> Signed-off-by:
-
Jiansong Chen authored
It's in accordance with pmfw 65.5.0 for navy_flounder. Signed-off-by:
Kenneth Feng <kenneth.feng@amd.com> Signed-off-by:
-
John Clements authored
add support for umc 8.7 initialization add umc 8.7 source to makefile Reviewed-by:
-
Huang Rui authored
It doesn't expose PPTable descriptor on APU platform. So max/min temperature values cannot be got from APU platform. v2: Stoney needs to skip crit temperature as well. Signed-off-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Kevin Wang <kevin1.wang@amd.com> Signed-off-by:
-
Aric Cyr authored
[Why] Test expects that we also read HPD_IRQ_VECTOR when checking for symbol loss as well lane status. [How] Read bytes 0x200-0x205 instead of just 0x202-0x205 Signed-off-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
-
Aric Cyr authored
Signed-off-by:
-
Eryk Brol authored
[Why] We need to be able to specify slice width for DSC on aconnector [How] Getting slice width parameter from debugfs entry, if it is a valid the value is set in connector's dsc preffered settings structure. Which then overwrites dsc_cfg structure's parameters if DSC is decided to be enabled. Works for both SST and MST. Signed-off-by:
-
Wyatt Wood authored
[Why] Feature requires synchronization of dig, pipe, and cursor locking between driver and fw. [How] Set flag to force psr to use hw lock mgr. Signed-off-by:
Wyatt Wood <wyatt.wood@amd.com> Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
hersen wu authored
[Why] ramp_up_dispclk_with_dpp is to change dispclk, dppclk and dprefclk according to bandwidth requirement. call stack: rv1_update_clocks --> update_clocks --> dcn10_prepare_bandwidth / dcn10_optimize_bandwidth --> prepare_bandwidth / optimize_bandwidth. before change dcn hw, prepare_bandwidth will be called first to allow enough clock, watermark for change, after end of dcn hw change, optimize_bandwidth is executed to lower clock to save power for new dcn hw settings. below is sequence of commit_planes_for_stream: step 1: prepare_bandwidth - raise clock to have enough bandwidth step 2: lock_doublebuffer_enable step 3: pipe_control_lock(true) - make dchubp register change will not take effect right way step 4: apply_ctx_for_surface - program dchubp step 5: pipe_control_lock(false) - dchubp register change take effect step 6: optimize_bandwidth --> dc_post_update_surfaces_to_stream for full_date, optimize clock to save power at end of step 1, dcn clocks (dprefclk, dispclk, dppclk) may be changed for new dchubp configuration. but real dcn hub dchubps are still running with old configuration until end of step 5. this need clocks settings at step 1 should not less than that before step 1. this is checked by two conditions: 1. if (should_set_clock(safe_to_lower , new_clocks->dispclk_khz, clk_mgr_base->clks.dispclk_khz) || new_clocks->dispclk_khz == clk_mgr_base->clks.dispclk_khz) 2. request_dpp_div = new_clocks->dispclk_khz > new_clocks->dppclk_khz the second condition is based on new dchubp configuration. dppclk for new dchubp may be different from dppclk before step 1. for example, before step 1, dchubps are as below: pipe 0: recout=(0,40,1920,980) viewport=(0,0,1920,979) pipe 1: recout=(0,0,1920,1080) viewport=(0,0,1920,1080) for dppclk for pipe0 need dppclk = dispclk new dchubp pipe split configuration: pipe 0: recout=(0,0,960,1080) viewport=(0,0,960,1080) pipe 1: recout=(960,0,960,1080) viewport=(960,0,960,1080) dppclk only needs dppclk = dispclk /2. dispclk, dppclk are not lock by otg master lock. they take effect after step 1. during this transition, dispclk are the same, but dppclk is changed to half of previous clock for old dchubp configuration between step 1 and step 6. This may cause p-state warning intermittently. [How] for new_clocks->dispclk_khz == clk_mgr_base->clks.dispclk_khz, we need make sure dppclk are not changed to less between step 1 and 6. for new_clocks->dispclk_khz > clk_mgr_base->clks.dispclk_khz, new display clock is raised, but we do not know ratio of new_clocks->dispclk_khz and clk_mgr_base->clks.dispclk_khz, new_clocks->dispclk_khz /2 does not guarantee equal or higher than old dppclk. we could ignore power saving different between dppclk = displck and dppclk = dispclk / 2 between step 1 and step 6. as long as safe_to_lower = false, set dpclk = dispclk to simplify condition check. CC: Stable <stable@vger.kernel.org> Signed-off-by:
Hersen Wu <hersenxs.wu@amd.com> Reviewed-by:
-
Anthony Koo authored
Signed-off-by:
-
Eryk Brol authored
[Why] Need a mechanism to force enable DSC on any connector [How] Debugfs entry overwrites newly added connector's dsc preffered settings structure and sets dsc_clock_en flag on it. During the attomic commit, depending if connector is SST or MST, we will enable DSC manually by overwriting stream's DSC flag. Signed-off-by:
-
