- 25 Jul, 2017 29 commits
-
-
Xiangliang Yu authored
VRAM is usually marked write combined, so change ioremap mode from noncache to write combine for reading vbios from VRAM. This will reduce cost time of reading vbios from 188ms to 8ms. Signed-off-by:
Xiangliang Yu <Xiangliang.Yu@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Emily Deng authored
Remove the error message "[drm:amdgpu_irq_disable_all [amdgpu]] *ERROR* error disabling interrupt (-22)". For virtual dce, it only use AMDGPU_CRTC_IRQ_VBLANK1 - AMDGPU_CRTC_IRQ_VBLANK6, and don't use AMDGPU_CRTC_IRQ_VLINE1 - AMDGPU_CRTC_IRQ_VLINE6. And when rmmod amdgpu, it will disable all interrupts, it will return error when the type of crtc irq interrupt is AMDGPU_CRTC_IRQ_VLINE1 - AMDGPU_CRTC_IRQ_VLINE6. BUG: SWDEV-121607 Signed-off-by:
Emily Deng <Emily.Deng@amd.com> Reviewed-by:
-
Alex Deucher authored
Needs to be done when the MC is set up. Acked-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Alex Deucher authored
Needs to be done when the MC is set up. Acked-by:
-
Alex Deucher authored
Needs to be done when the MC is set up. Acked-by:
-
Alex Deucher authored
Needs to be done when the MC is set up. v2: make consistent with other asics Acked-by:
-
Egbert Eich authored
The radeon driver reduces the framebuffer resolution to 8bpp if a device with less than 32MB VRAM is found. This causes the framebuffer to run in 8 bit paletted mode. For a text console this is not an issue as 256 different colors is more than one gets on a VGA text console. However this leads to a poor 8bit pseudo-color visual when running X on fbdev, too, which is quite ugly. In this patch, we try to give some moderate compromise: limit the framebuffer bpp to 8 only when VRAM is 8MB or less, and use 16 bpp otherwise for 32MB or less VRAM. Reviewed-by:
Egbert Eich <eich@suse.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Huang Rui authored
Signed-off-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Rex Zhu authored
Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
-
Alex Deucher authored
The hardware can use huge pages to map 2MB of address space with only one PDE. v2: few cleanups and rebased v3: skip PT updates if we are using the PDE v4: rebased, added support for CPU based updates v5: fix CPU based updates once more v6: fix ndw estimation Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Christian König authored
The fragment bits work differently for Vega10 compared to previous generations. Increase the fragment size to 2MB for now to better handle that. v2: handle the hardware setup as well Signed-off-by:
-
Chunming Zhou authored
Signed-off-by:
Chunming Zhou <David1.Zhou@amd.com> Reviewed-by:
-
Xiangliang Yu authored
Currently, get clock info from default clk of pm if dpm is disable. Buf SRIOV doesn't support dpm and pm, can't get anything from pm. Only get clock info only from default clk of amdgpu for SRIOV. And driver get pm default clk also from amdgpu default clk and never be changed by others. So use amdgpu default clk value for SRIOV and non-dpm cases. Signed-off-by:
-
Emily Deng authored
SRIOV won't do vbios post in guest OS, and the mmMC_VM_FB_LOCATION is pf and vf copy, so still need to program fb location for SRIOV. v2: No need to stop mc, and update gmc_v8_0_vram_gtt_location as well. v3: New line after the stack variables BUG: SWDEV-126629 Signed-off-by:
-
Junwei Zhang authored
Now asd firmware is not ready for psp v10, will enable it when it's available Signed-off-by:
-
Monk Liu authored
1, for sriov, we need 8dw for the gfx fence due to CP behaviour 2, cleanup wrong logic in wptr/rptr wb alloc and free Change-Id: Ifbfed17a4621dae57244942ffac7de1743de0294 Signed-off-by:
Monk Liu <Monk.Liu@amd.com> Signed-off-by:
-
Felix Kuehling authored
Allows gdb to access contents of user mode mapped VRAM BOs. v2: return error for non-VRAM pools Signed-off-by:
-
Felix Kuehling authored
Allows gdb to access contents of user mode mapped BOs. System memory is handled by TTM using kmap. Other memory pools require a new driver callback in ttm_bo_driver. v2: * kmap only one page at a time * swap in BO if needed * make driver callback more generic to handle private memory pools * document callback return value * WARN_ON -> WARN_ON_ONCE Signed-off-by:
-
Eric Huang authored
Signed-off-by:
Eric Huang <JinHuiEric.Huang@amd.com> Acked-by:
-
Zhang, Jerry authored
v2: fix the SOS loading failure for PSP v3.1 Signed-off-by:
-
Nicolai Hähnle authored
Copy the approach taken by gfx8, which simplifies the code, and set the instance index properly. The latter is required for debugging, e.g. for reading wave status by UMR. Signed-off-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by:
-
Junwei Zhang authored
Signed-off-by:
-
Junwei Zhang authored
Signed-off-by:
-
Junwei Zhang authored
Signed-off-by:
-
Junwei Zhang authored
Signed-off-by:
-
Alex Xie authored
In RCU read-side critical sections, blocking or sleeping is prohibited. v2: Unlock RCU for the code path where result==NULL. (David Zhou) Update subject Tested-by and reported by: Dave Airlie <airlied@redhat.com> [ 141.965723] ============================= [ 141.965724] WARNING: suspicious RCU usage [ 141.965726] 4.12.0-rc7 #221 Not tainted [ 141.965727] ----------------------------- [ 141.965728] /home/airlied/devel/kernel/linux-2.6/include/linux/rcupdate.h:531 Illegal context switch in RCU read-side critical section! [ 141.965730] other info that might help us debug this: [ 141.965731] rcu_scheduler_active = 2, debug_locks = 0 [ 141.965732] 1 lock held by amdgpu_cs:0/1332: [ 141.965733] #0: (rcu_read_lock){......}, at: [<ffffffffa01a0d07>] amdgpu_bo_list_get+0x0/0x109 [amdgpu] [ 141.965774] stack backtrace: [ 141.965776] CPU: 6 PID: 1332 Comm: amdgpu_cs:0 Not tainted 4.12.0-rc7 #221 [ 141.965777] Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 R2.0, BIOS 2603 06/26/2015 [ 141.965778] Call Trace: [ 141.965782] dump_stack+0x68/0x92 [ 141.965785] lockdep_rcu_suspicious+0xf7/0x100 [ 141.965788] ___might_sleep+0x56/0x1fc [ 141.965790] __might_sleep+0x68/0x6f [ 141.965793] __mutex_lock+0x4e/0x7b5 [ 141.965817] ? amdgpu_bo_list_get+0xa4/0x109 [amdgpu] [ 141.965820] ? lock_acquire+0x125/0x1b9 [ 141.965844] ? amdgpu_bo_list_set+0x464/0x464 [amdgpu] [ 141.965846] mutex_lock_nested+0x16/0x18 [ 141.965848] ? mutex_lock_nested+0x16/0x18 [ 141.965872] amdgpu_bo_list_get+0xa4/0x109 [amdgpu] [ 141.965895] amdgpu_cs_ioctl+0x4a0/0x17dd [amdgpu] [ 141.965898] ? radix_tree_node_alloc.constprop.11+0x77/0xab [ 141.965916] drm_ioctl+0x264/0x393 [drm] [ 141.965939] ? amdgpu_cs_find_mapping+0x83/0x83 [amdgpu] [ 141.965942] ? trace_hardirqs_on_caller+0x16a/0x186 Signed-off-by:Alex Xie <AlexBin.Xie@amd.com> Reviewed-by:
-
- 14 Jul, 2017 11 commits
-
-
Rex Zhu authored
Signed-off-by:
-
Christian König authored
The test was relaxed a bit to much. Signed-off-by:
Tom St Denis <tom.stdenis@amd.com> Reviewed-and-Tested-by:
Roger He <Hongbo.He@amd.com> Signed-off-by:
-
Christian König authored
No need to try to map them every time. Signed-off-by:
-
Christian König authored
When a BO is moved or destroyed it shouldn't be kmapped any more. Signed-off-by:
-
Christian König authored
No need to do this after every single update. Signed-off-by:
-
Christian König authored
Handy for debugging. Signed-off-by:
-
Alex Deucher authored
Printing a warning into the logs that we will certainly run into a BUG() is completely nonsense, the BUG() is more than noisy enough. Signed-off-by:
-
Christian König authored
We need to wait with the correct owner on unmap operations or otherwise can run into VM faults. Also always wait for the page directory since this is where the reservation object comes from. So rename the function to amdgpu_vm_wait_pd instead as well. Signed-off-by:
-
Christian König authored
We don't have any update fence in that case, so the need for flushing isn't detected automatically. Signed-off-by:
-
Alex Deucher authored
Spreading them causes performance regressions using compute queues on Polaris 11. Cc: Jim Qu <jim.qu@amd.com> Acked-by:
Jim Qu <Jim.Qu@amd.com> Signed-off-by:
-
Jim Qu authored
Signed-off-by:
-
