- 10 Oct, 2018 2 commits
-
-
Hersen Wu authored
RV2 resource is limit to 3 pipes. Limitation should apply to all HW blocks instead of front pipe. Signed-off-by:
Hersen Wu <hersenxs.wu@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Roman Li authored
[Why] Wrong index for pstate debug test register [How] Add correct index value for dcn1_01 in hubbub1_construct() Signed-off-by:
Roman Li <Roman.Li@amd.com> Acked-by:
-
- 09 Oct, 2018 38 commits
-
-
Rex Zhu authored
initialize gfx/sdma before dpm features enabled. Acked-by:
Rex Zhu <Rex.Zhu@amd.com> Signed-off-by:
-
Rex Zhu authored
gfx and sdma can be initialized before smu. Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Rex Zhu authored
with this interface, gfx/sdma can be initialized before smu. Reviewed-by:
-
Rex Zhu authored
ucode bo is needed by request_smu_load_fw, the request_smu_load_fw maybe called by gfx/sdma before smu hw init. so move amdgpu_ucode_bo_init to request_smu_lowd_fw from smu hw init. Reviewed-by:
-
Rex Zhu authored
driver don't release the ucode memory when suspend. so don't need to allocate bo when resume back. Reviewed-by:
-
Rex Zhu authored
AMDGPU_FW_LOAD_DIRECT is used for bring up. Now it don't work any more. so remove the support. v2: Add warning message if user select AMDGPU_FW_LOAD_DIRECT/AMDGPU_FW_LOAD_PSP on VI. Reviewed-by:
-
James Zhu authored
Correct VCN cache window definition. The old one is reused from UVD, and it is not fully correct. Signed-off-by:
James Zhu <James.Zhu@amd.com> Acked-by:
Leo Liu <leo.liu@amd.com> Signed-off-by:
-
James Zhu authored
Replace value with defined macro to make code more readable Signed-off-by:
-
James Zhu authored
Use mmUVD_SCRATCH2 tracking decode write point. It will help avoid dpg pause mode hang issue. Signed-off-by:
-
James Zhu authored
The following WREG32_SOC15_DPG_MODE will overwrite register mmUVD_CGC_CTRL. This code can be removed. Signed-off-by:
-
Nick Alcock authored
So a few days ago I started getting sprays of these warnings -- sorry, but because it was a few days ago I'm not sure what I was running at the time (but it was probably either Stellaris or Chromium). Sep 25 22:06:34 mutilate err: : [ 544.718905] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc Sep 25 22:06:34 mutilate err: : [ 544.718909] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Sep 25 22:06:34 mutilate err: : [ 544.719710] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc Sep 25 22:06:34 mutilate err: : [ 544.719714] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Sep 25 22:06:34 mutilate err: : [ 544.719862] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc Sep 25 22:06:34 mutilate err: : [ 544.719865] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Sep 25 22:06:34 mutilate err: : [ 544.720772] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc Sep 25 22:06:34 mutilate err: : [ 544.720778] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Sep 25 22:06:34 mutilate warning: : [ 544.721415] radeon 0000:01:00.0: vbo resource seems too big for the bo followed by a massive stream of "vbo resource seems too big for the bo". The most extreme flood ran from 23:01:58 to 23:02:47 and emitted 91,000 lines of log in that time. This... seems excessive, given that each log message after the first contains more or less no information. So ratelimit these messages. (We probably want to see at least *some* so that the underlying bug can be fixed -- always assuming the bug isn't in unfixable closed-source game code somewhere.) Signed-off-by:
Nick Alcock <nick.alcock@oracle.com> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Christian König authored
Adding a second irq source because of a different src_id is actually a bug. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Christian König authored
That also simplifies handling quite a bit. Signed-off-by:
Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by:
-
Shirish S authored
[Why] 1. we never submit IBs to the KIQ 2. there seems to be ~500ms delay during amdgpu resume spent in KIQ, hence pointing toward interrupts are not working correctly. [How] remove interrupt handling for KIQ. Signed-off-by:
Shirish S <shirish.s@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>i Signed-off-by:
-
Felix Kuehling authored
This mm_struct pointer should never be dereferenced. If running in a user thread, just use current->mm. If running in a kernel worker use get_task_mm to get a safe reference to the mm_struct. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Oded Gabbay <oded.gabbay@gmail.com> Acked-by:
-
Pratik Vishwakarma authored
[Why] 1. We never submit IBs to KIQ. 2. Ring test pass without KIQ's ring also. 3. By skipping we see an improvement of around 500ms in the amdgpu's resume time. [How] skip IB tests for KIQ ring type. Signed-off-by:
Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Reviewed-by:
-
Nathan Chancellor authored
Clang generates a warning when it sees a logical not followed by a conditional operator like ==, >, or <. drivers/gpu/drm/scheduler/sched_entity.c:470:6: warning: logical not is only applied to the left hand side of this comparison [-Wlogical-not-parentheses] if (!spsc_queue_count(&entity->job_queue) == 0 || ^ ~~ drivers/gpu/drm/scheduler/sched_entity.c:470:6: note: add parentheses after the '!' to evaluate the comparison first if (!spsc_queue_count(&entity->job_queue) == 0 || ^ ( ) drivers/gpu/drm/scheduler/sched_entity.c:470:6: note: add parentheses around left hand side expression to silence this warning if (!spsc_queue_count(&entity->job_queue) == 0 || ^ ( ) 1 warning generated. It assumes the author might have made a mistake in their logic: if (!a == b) -> if (!(a == b)) Sometimes that is the case; other times, it's just a super convoluted way of saying 'if (a)' when b = 0: if (!1 == 0) -> if (0 == 0) -> if (true) Alternatively: if (!1 == 0) -> if (!!1) -> if (1) Simplify this comparison so that Clang doesn't complain. Fixes: 35e160e7 ("drm/scheduler: change entities rq even earlier") Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
-
Rex Zhu authored
The request_smu_load_fw of VI is used to load gfx/sdma ip's firmware. Check whether the gfx/sdma firmware have been loaded successfully in this callback function. if failed, driver can exit to avoid gpu hard hung. if successful, clean the flag reload_fw to avoid duplicated fw load. when suspend/resume, driver need to reload fw. so in suspend, reset the reload_fw flag to true to enable load fw when resume. Reviewed-by:
-
Rex Zhu authored
need to know SoftRegsStart value to visit the register UcodeLoadStatus to check fw loading state. Reviewed-by:
-
Rex Zhu authored
if upload firmware failed, no matter how many times the function runs again, the same error will be encountered. so remove the duplicated code. Reviewed-by:
-
Rex Zhu authored
Move in_suspend flag to adev from gfx, so can be used in other ip blocks, also keep consistent with gpu_in_reset flag. Reviewed-by:
-
Rex Zhu authored
On CI/AI, fw was not loaded by smu, but smu's fw still need to be released when driver fini. Reviewed-by:
-
Rex Zhu authored
the struct was not in use any more. Reviewed-by:
-
Rex Zhu authored
don't need to set fan1_enable to read fan sensors. Reviewed-by:
-
Rex Zhu authored
Following lm-sensors 3.0.0, Only enable pwm1 sysfs when fan control mode(pwm1_enable) in manual Reviewed-by:
-
Rex Zhu authored
Add fan1_target for get/set fan speed in RPM unit Add fan1_min/fan1_max for get min, max fan speed in RPM unit Add fan1_enable to enable/disable the fan1 sensor v3: drop the hardcode value of min/max rpm in comments pointed out by Alex. v2: query the min/max rpm gpu support instand of hardcode value. Reviewed-by: -
Rex Zhu authored
so user can query the RPM range Reviewed-by:
-
Rex Zhu authored
For getting the min/max fan speed in RPM units. Reviewed-by:
-
Rex Zhu authored
1. make uvd_v7_0_enc_get_destroy_msg static 2. drop a function variable that always true Reviewed-by:
-
Shirish S authored
In amdgpu_dm_commit_tail(), wait until flip_done() is signaled before we signal hw_done(). [Why] This is to temporarily address a paging error that occurs when a nonblocking commit contends with another commit, particularly in a mirrored display configuration where at least 2 CRTCs are updated. The error occurs in drm_atomic_helper_wait_for_flip_done(), when we attempt to access the contents of new_crtc_state->commit. Here's the sequence for a mirrored 2 display setup (irrelevant steps left out for clarity): **THREAD 1** | **THREAD 2** | Initialize atomic state for flip | | Queue worker | ... | Do work for flip | | Signal hw_done() on CRTC 1 | Signal hw_done() on CRTC 2 | | Wait for flip_done() on CRTC 1 <---- **PREEMPTED BY THREAD 1** Initialize atomic state for cursor | update (1) | | Do cursor update work on both CRTCs | | Clear atomic state (2) | **DONE** | ... | | Wait for flip_done() on CRTC 2 | *ERROR* | The issue starts with (1). When the atomic state is initialized, the current CRTC states are duplicated to be the new_crtc_states, and referenced to be the old_crtc_states. (The new_crtc_states are to be filled with update data.) Some things to note: * Due to the mirrored configuration, the cursor updates on both CRTCs. * At this point, the pflip IRQ has already been handled, and flip_done signaled on all CRTCs. The cursor commit can therefore continue. * The old_crtc_states used by the cursor update are the **same states** as the new_crtc_states used by the flip worker. At (2), the old_crtc_state is freed (*), and the cursor commit completes. We then context switch back to the flip worker, where we attempt to access the new_crtc_state->commit object. This is problematic, as this state has already been freed. (*) Technically, 'state->crtcs[i].state' is freed, which was made to reference old_crtc_state in drm_atomic_helper_swap_state() [How] By moving hw_done() after wait_for_flip_done(), we're guaranteed that the new_crtc_state (from the flip worker's perspective) still exists. This is because any other commit will be blocked, waiting for the hw_done() signal. Note that both the i915 and imx drivers have this sequence flipped already, masking this problem. Signed-off-by:Leo Li <sunpeng.li@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Nathan Chancellor authored
Clang warns when one enumerated type is implicitly converted to another. drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c:315:19: warning: implicit conversion from enumeration type 'enum aux_channel_operation_result' to different enumeration type 'enum aux_transaction_reply' [-Wenum-conversion] reply->status = AUX_CHANNEL_OPERATION_FAILED_HPD_DISCON; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../display/dc/i2caux/dce110/aux_engine_dce110.c:349:19: warning: implicit conversion from enumeration type 'enum aux_channel_operation_result' to different enumeration type 'enum aux_transaction_reply' [-Wenum-conversion] reply->status = AUX_CHANNEL_OPERATION_FAILED_HPD_DISCON; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The current enum is incorrect, it should be from aux_transaction_reply, so use AUX_TRANSACTION_REPLY_HPD_DISCON. Reported-by:Nick Desaulniers <ndesaulniers@google.com> Suggested-by:
-
Nicholas Kazlauskas authored
[Why] The DISPCLK value was previously requested to be 15% higher for all ASICS that went through the dce110 bandwidth code path. As part of a refactoring of dce_clocks and dce110 set_bandwidth this was removed for power saving considerations. This changed caused corruption under certain display configurations. Originally thought to be Vega specific, it was also observed on Polaris. [How] The 15% is brought back but its placement differs from the original patch. This boost should only be enable while DFS bypass is inactive. This (like the Vega patch) is also a workaround that should be removed after the root cause is identified. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
-
Murton Liu authored
[Why] Due to a small pre-fetch window, the active vline timing is a couple of lines off when compared to what it should be. [How] Changed the calculation for the start vline to account for this window. Signed-off-by:
Murton Liu <murton.liu@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
-
Charlene Liu authored
[Description] interlace mode shows wrong vertical timing. Interface timing in Edid is half vertical timing as progressive timing. driver doubled the vertical timing in edid_paser, no need to double in optc again. Signed-off-by:
Charlene Liu <charlene.liu@amd.com> Reviewed-by:
Chris Park <Chris.Park@amd.com> Acked-by:
-
Leo Li authored
[Why] There is no reason why the common data needs to be kept separate. [How] Flatten the struct by moving common data into the DM IRQ struct. Signed-off-by:
David Francis <David.Francis@amd.com> Acked-by:
-
Jun Lei authored
[why] ddc engines were recently changed to be independently tracked from pipe count. the change was reflected in resource constructor but not in destructor. this manifests as a memory leak when pipe harvesting is enabled, since not all constructed ddc engines are freed [how] make destructor symmetric with constructor for all dcX_resource Signed-off-by:
Jun Lei <Jun.Lei@amd.com> Reviewed-by:
-
Tony Cheng authored
Signed-off-by:
Tony Cheng <tony.cheng@amd.com> Reviewed-by:
Steven Chiu <Steven.Chiu@amd.com> Acked-by:
-
Yongqiang Sun authored
[Why] DF keeps awake after S0i3 resume due to DRAM_STATE_CNTL is set by bios command table during dcn init_hw. [How] As a work around, check STATE_CNTL status before init_hw, if it is 0 before init_hw and set to 1 after init_hw, change it to 0. Signed-off-by:
Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by:
-
