openwrt/staging/blogic.git
5 years agoRevert "drm/amd/display: make clk_mgr call enable_pme_wa"
Alex Deucher [Mon, 17 Jun 2019 18:04:43 +0000 (13:04 -0500)]
Revert "drm/amd/display: make clk_mgr call enable_pme_wa"

This reverts commit a1651530a3bacf1d796fdb7bc587faef9f305d36.

Revert this to apply the version that includes DCN2 support.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agoRevert "drm/amd/display: Enable fast plane updates when state->allow_modeset = true"
Nicholas Kazlauskas [Thu, 20 Jun 2019 12:30:09 +0000 (08:30 -0400)]
Revert "drm/amd/display: Enable fast plane updates when state->allow_modeset = true"

This reverts commit ebc8c6f18322ad54275997a888ca1731d74b711f.

There are still missing corner cases with cursor interaction and these
fast plane updates on Picasso and Raven2 leading to endless PSTATE
warnings for typical desktop usage depending on the userspace.

This change should be reverted until these issues have been resolved.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110949
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <david.francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu/sriov: fix Tonga load driver failed
Jack Zhang [Thu, 20 Jun 2019 05:44:47 +0000 (13:44 +0800)]
drm/amdgpu/sriov: fix Tonga load driver failed

Tonga sriov need to use smu to load firmware.
Remove sriov flag because the default return value is zero.

Signed-off-by: Jack Zhang <Jack.Zhang1@amd.com>
Reviewed-by: Trigger Huang <Trigger.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: add pmu counters
Jonathan Kim [Thu, 20 Jun 2019 03:56:25 +0000 (23:56 -0400)]
drm/amdgpu: add pmu counters

adding perf event counters

Signed-off-by: Jonathan Kim <Jonathan.Kim@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: update df_v3_6 for xgmi perfmons (v2)
Jonathan Kim [Thu, 20 Jun 2019 03:37:59 +0000 (23:37 -0400)]
drm/amdgpu: update df_v3_6 for xgmi perfmons (v2)

add pmu attribute groups and structures for perf events.
add sysfs to track available df perfmon counters
fix overflow handling in perfmon counter reads.

v2: squash in fix (Alex)

Signed-off-by: Jonathan Kim <Jonathan.Kim@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Fix null-deref on vega20 with xgmi
Roman Li [Tue, 18 Jun 2019 15:25:25 +0000 (11:25 -0400)]
drm/amd/display: Fix null-deref on vega20 with xgmi

[Why]
After clkmgr rework it gets initialized after resource pool.
The clkmgr is used in resource pool init for xgmi path.
That causes driver crash on Vega20 with xgmi due to NULL deref.

[How]
Move xgmi compensation code to dce121_clk_mgr_construct()
That also allows to make dce121_clock_patch_xgmi_ss_info()
internal static function.

Signed-off-by: Roman Li <Roman.Li@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: Add procfs-style information for KFD processes
Kent Russell [Thu, 13 Jun 2019 13:55:40 +0000 (09:55 -0400)]
drm/amdkfd: Add procfs-style information for KFD processes

Add a folder structure to /sys/class/kfd/kfd/ called proc which contains
subfolders, each representing an active KFD process' PID, containing 1
file: pasid.

Signed-off-by: Kent Russell <kent.russell@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: improve HMM error -ENOMEM and -EBUSY handling
Philip Yang [Fri, 14 Jun 2019 18:03:36 +0000 (14:03 -0400)]
drm/amdgpu: improve HMM error -ENOMEM and -EBUSY handling

Under memory pressure, hmm_range_fault may return error code -ENOMEM
or -EBUSY, change pr_info to pr_debug to remove unnecessary kernel log
message because we will retry restore again.

Call get_user_pages_done if TTM get user pages failed will have
WARN_ONCE kernel calling stack dump log.

Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/amdgpu: cast mem->num_pages to 64-bits when shifting (v2)
Tom St Denis [Fri, 14 Jun 2019 15:47:21 +0000 (11:47 -0400)]
drm/amd/amdgpu: cast mem->num_pages to 64-bits when shifting (v2)

On 32-bit hosts mem->num_pages is 32-bits and can overflow
when shifted.  Add a cast to avoid this.

(v2): Style fix.

Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: Do error injection even vram reserve fails
xinhui pan [Fri, 14 Jun 2019 08:06:10 +0000 (16:06 +0800)]
drm/amdgpu: Do error injection even vram reserve fails

As long as the address is mapped with vram, we can do an error
injection.

Signed-off-by: xinhui pan <xinhui.pan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: wait to fetch the vbios until after common init
Alex Deucher [Mon, 17 Jun 2019 14:37:45 +0000 (09:37 -0500)]
drm/amdgpu: wait to fetch the vbios until after common init

We need the asic_funcs set for the get rom callbacks in some
cases.

Tested-by: Kent Russell <kent.russell@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/powerplay: Delete a redundant memory setting in vega20_set_default_od8_settti...
Markus Elfring [Mon, 17 Jun 2019 12:24:14 +0000 (14:24 +0200)]
drm/amd/powerplay: Delete a redundant memory setting in vega20_set_default_od8_setttings()

The memory was set to zero already by a call of the function “kzalloc”.
Thus remove an extra call of the function “memset” for this purpose.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Delete a redundant memory setting in amdgpu_dm_irq_register_interrupt()
Markus Elfring [Mon, 17 Jun 2019 11:56:39 +0000 (13:56 +0200)]
drm/amd/display: Delete a redundant memory setting in amdgpu_dm_irq_register_interrupt()

The memory was set to zero already by a call of the function “kzalloc”.
Thus remove an extra call of the function “memset” for this purpose.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: fix error handling in df_v3_6_pmc_start
Arnd Bergmann [Mon, 17 Jun 2019 12:51:45 +0000 (14:51 +0200)]
drm/amdgpu: fix error handling in df_v3_6_pmc_start

When df_v3_6_pmc_get_ctrl_settings() fails for some reason, we
store uninitialized data in a register, as gcc points out:

drivers/gpu/drm/amd/amdgpu/df_v3_6.c: In function 'df_v3_6_pmc_start':
drivers/gpu/drm/amd/amdgpu/amdgpu.h:1012:29: error: 'lo_val' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 #define WREG32_PCIE(reg, v) adev->pcie_wreg(adev, (reg), (v))
                             ^~~~
drivers/gpu/drm/amd/amdgpu/df_v3_6.c:334:39: note: 'lo_val' was declared here
  uint32_t lo_base_addr, hi_base_addr, lo_val, hi_val;
                                       ^~~~~~

Make it return a proper error code that we can catch in the caller.

Fixes: 992af942a6cf ("drm/amdgpu: add df perfmon regs and funcs for xgmi")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Add missing newline at end of file
Geert Uytterhoeven [Mon, 17 Jun 2019 14:37:28 +0000 (16:37 +0200)]
drm/amd/display: Add missing newline at end of file

"git diff" says:

    \ No newline at end of file

after modifying the file.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/powerplay: detect version of smu backend (v2)
Prike Liang [Fri, 14 Jun 2019 04:06:35 +0000 (12:06 +0800)]
drm/amd/powerplay: detect version of smu backend (v2)

Print the backend type.

v2: whitespace fixes (Alex)

Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: Fix sdma queue allocate race condition
Oak Zeng [Sat, 15 Jun 2019 00:27:58 +0000 (19:27 -0500)]
drm/amdkfd: Fix sdma queue allocate race condition

SDMA queue allocation requires the dqm lock as it modify
the global dqm members. Enclose it in the dqm_lock.

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Philip Yang <philip.yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: Fix a circular lock dependency
Oak Zeng [Sat, 15 Jun 2019 01:10:45 +0000 (20:10 -0500)]
drm/amdkfd: Fix a circular lock dependency

The idea to break the circular lock dependency is to temporarily drop
dqm lock before calling allocate_mqd. See callstack #1 below.

[   59.510149] [drm] Initialized amdgpu 3.30.0 20150101 for 0000:04:00.0 on minor 0

[  513.604034] ======================================================
[  513.604205] WARNING: possible circular locking dependency detected
[  513.604375] 4.18.0-kfd-root #2 Tainted: G        W
[  513.604530] ------------------------------------------------------
[  513.604699] kswapd0/611 is trying to acquire lock:
[  513.604840] 00000000d254022e (&dqm->lock_hidden){+.+.}, at: evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.605150]
               but task is already holding lock:
[  513.605307] 00000000961547fc (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe4/0x250
[  513.605540]
               which lock already depends on the new lock.

[  513.605747]
               the existing dependency chain (in reverse order) is:
[  513.605944]
               -> #4 (&anon_vma->rwsem){++++}:
[  513.606106]        __vma_adjust+0x147/0x7f0
[  513.606231]        __split_vma+0x179/0x190
[  513.606353]        mprotect_fixup+0x217/0x260
[  513.606553]        do_mprotect_pkey+0x211/0x380
[  513.606752]        __x64_sys_mprotect+0x1b/0x20
[  513.606954]        do_syscall_64+0x50/0x1a0
[  513.607149]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  513.607380]
               -> #3 (&mapping->i_mmap_rwsem){++++}:
[  513.607678]        rmap_walk_file+0x1f0/0x280
[  513.607887]        page_referenced+0xdd/0x180
[  513.608081]        shrink_page_list+0x853/0xcb0
[  513.608279]        shrink_inactive_list+0x33b/0x700
[  513.608483]        shrink_node_memcg+0x37a/0x7f0
[  513.608682]        shrink_node+0xd8/0x490
[  513.608869]        balance_pgdat+0x18b/0x3b0
[  513.609062]        kswapd+0x203/0x5c0
[  513.609241]        kthread+0x100/0x140
[  513.609420]        ret_from_fork+0x24/0x30
[  513.609607]
               -> #2 (fs_reclaim){+.+.}:
[  513.609883]        kmem_cache_alloc_trace+0x34/0x2e0
[  513.610093]        reservation_object_reserve_shared+0x139/0x300
[  513.610326]        ttm_bo_init_reserved+0x291/0x480 [ttm]
[  513.610567]        amdgpu_bo_do_create+0x1d2/0x650 [amdgpu]
[  513.610811]        amdgpu_bo_create+0x40/0x1f0 [amdgpu]
[  513.611041]        amdgpu_bo_create_reserved+0x249/0x2d0 [amdgpu]
[  513.611290]        amdgpu_bo_create_kernel+0x12/0x70 [amdgpu]
[  513.611584]        amdgpu_ttm_init+0x2cb/0x560 [amdgpu]
[  513.611823]        gmc_v9_0_sw_init+0x400/0x750 [amdgpu]
[  513.612491]        amdgpu_device_init+0x14eb/0x1990 [amdgpu]
[  513.612730]        amdgpu_driver_load_kms+0x78/0x290 [amdgpu]
[  513.612958]        drm_dev_register+0x111/0x1a0
[  513.613171]        amdgpu_pci_probe+0x11c/0x1e0 [amdgpu]
[  513.613389]        local_pci_probe+0x3f/0x90
[  513.613581]        pci_device_probe+0x102/0x1c0
[  513.613779]        driver_probe_device+0x2a7/0x480
[  513.613984]        __driver_attach+0x10a/0x110
[  513.614179]        bus_for_each_dev+0x67/0xc0
[  513.614372]        bus_add_driver+0x1eb/0x260
[  513.614565]        driver_register+0x5b/0xe0
[  513.614756]        do_one_initcall+0xac/0x357
[  513.614952]        do_init_module+0x5b/0x213
[  513.615145]        load_module+0x2542/0x2d30
[  513.615337]        __do_sys_finit_module+0xd2/0x100
[  513.615541]        do_syscall_64+0x50/0x1a0
[  513.615731]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  513.615963]
               -> #1 (reservation_ww_class_mutex){+.+.}:
[  513.616293]        amdgpu_amdkfd_alloc_gtt_mem+0xcf/0x2c0 [amdgpu]
[  513.616554]        init_mqd+0x223/0x260 [amdgpu]
[  513.616779]        create_queue_nocpsch+0x4d9/0x600 [amdgpu]
[  513.617031]        pqm_create_queue+0x37c/0x520 [amdgpu]
[  513.617270]        kfd_ioctl_create_queue+0x2f9/0x650 [amdgpu]
[  513.617522]        kfd_ioctl+0x202/0x350 [amdgpu]
[  513.617724]        do_vfs_ioctl+0x9f/0x6c0
[  513.617914]        ksys_ioctl+0x66/0x70
[  513.618095]        __x64_sys_ioctl+0x16/0x20
[  513.618286]        do_syscall_64+0x50/0x1a0
[  513.618476]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  513.618695]
               -> #0 (&dqm->lock_hidden){+.+.}:
[  513.618984]        __mutex_lock+0x98/0x970
[  513.619197]        evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.619459]        kfd_process_evict_queues+0x3b/0xb0 [amdgpu]
[  513.619710]        kgd2kfd_quiesce_mm+0x1c/0x40 [amdgpu]
[  513.620103]        amdgpu_amdkfd_evict_userptr+0x38/0x70 [amdgpu]
[  513.620363]        amdgpu_mn_invalidate_range_start_hsa+0xa6/0xc0 [amdgpu]
[  513.620614]        __mmu_notifier_invalidate_range_start+0x70/0xb0
[  513.620851]        try_to_unmap_one+0x7fc/0x8f0
[  513.621049]        rmap_walk_anon+0x121/0x290
[  513.621242]        try_to_unmap+0x93/0xf0
[  513.621428]        shrink_page_list+0x606/0xcb0
[  513.621625]        shrink_inactive_list+0x33b/0x700
[  513.621835]        shrink_node_memcg+0x37a/0x7f0
[  513.622034]        shrink_node+0xd8/0x490
[  513.622219]        balance_pgdat+0x18b/0x3b0
[  513.622410]        kswapd+0x203/0x5c0
[  513.622589]        kthread+0x100/0x140
[  513.622769]        ret_from_fork+0x24/0x30
[  513.622957]
               other info that might help us debug this:

[  513.623354] Chain exists of:
                 &dqm->lock_hidden --> &mapping->i_mmap_rwsem --> &anon_vma->rwsem

[  513.623900]  Possible unsafe locking scenario:

[  513.624189]        CPU0                    CPU1
[  513.624397]        ----                    ----
[  513.624594]   lock(&anon_vma->rwsem);
[  513.624771]                                lock(&mapping->i_mmap_rwsem);
[  513.625020]                                lock(&anon_vma->rwsem);
[  513.625253]   lock(&dqm->lock_hidden);
[  513.625433]
                *** DEADLOCK ***

[  513.625783] 3 locks held by kswapd0/611:
[  513.625967]  #0: 00000000f14edf84 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x30
[  513.626309]  #1: 00000000961547fc (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe4/0x250
[  513.626671]  #2: 0000000067b5cd12 (srcu){....}, at: __mmu_notifier_invalidate_range_start+0x5/0xb0
[  513.627037]
               stack backtrace:
[  513.627292] CPU: 0 PID: 611 Comm: kswapd0 Tainted: G        W         4.18.0-kfd-root #2
[  513.627632] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[  513.627990] Call Trace:
[  513.628143]  dump_stack+0x7c/0xbb
[  513.628315]  print_circular_bug.isra.37+0x21b/0x228
[  513.628581]  __lock_acquire+0xf7d/0x1470
[  513.628782]  ? unwind_next_frame+0x6c/0x4f0
[  513.628974]  ? lock_acquire+0xec/0x1e0
[  513.629154]  lock_acquire+0xec/0x1e0
[  513.629357]  ? evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.629587]  __mutex_lock+0x98/0x970
[  513.629790]  ? evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.630047]  ? evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.630309]  ? evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.630562]  evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.630816]  kfd_process_evict_queues+0x3b/0xb0 [amdgpu]
[  513.631057]  kgd2kfd_quiesce_mm+0x1c/0x40 [amdgpu]
[  513.631288]  amdgpu_amdkfd_evict_userptr+0x38/0x70 [amdgpu]
[  513.631536]  amdgpu_mn_invalidate_range_start_hsa+0xa6/0xc0 [amdgpu]
[  513.632076]  __mmu_notifier_invalidate_range_start+0x70/0xb0
[  513.632299]  try_to_unmap_one+0x7fc/0x8f0
[  513.632487]  ? page_lock_anon_vma_read+0x68/0x250
[  513.632690]  rmap_walk_anon+0x121/0x290
[  513.632875]  try_to_unmap+0x93/0xf0
[  513.633050]  ? page_remove_rmap+0x330/0x330
[  513.633239]  ? rcu_read_unlock+0x60/0x60
[  513.633422]  ? page_get_anon_vma+0x160/0x160
[  513.633613]  shrink_page_list+0x606/0xcb0
[  513.633800]  shrink_inactive_list+0x33b/0x700
[  513.633997]  shrink_node_memcg+0x37a/0x7f0
[  513.634186]  ? shrink_node+0xd8/0x490
[  513.634363]  shrink_node+0xd8/0x490
[  513.634537]  balance_pgdat+0x18b/0x3b0
[  513.634718]  kswapd+0x203/0x5c0
[  513.634887]  ? wait_woken+0xb0/0xb0
[  513.635062]  kthread+0x100/0x140
[  513.635231]  ? balance_pgdat+0x3b0/0x3b0
[  513.635414]  ? kthread_delayed_work_timer_fn+0x80/0x80
[  513.635626]  ret_from_fork+0x24/0x30
[  513.636042] Evicting PASID 32768 queues
[  513.936236] Restoring PASID 32768 queues
[  524.708912] Evicting PASID 32768 queues
[  524.999875] Restoring PASID 32768 queues

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Philip Yang <philip.yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agoRevert "drm/amdkfd: Fix a circular lock dependency"
Oak Zeng [Sat, 15 Jun 2019 00:39:55 +0000 (19:39 -0500)]
Revert "drm/amdkfd: Fix a circular lock dependency"

This reverts commit 06b89b38f3cc518a761164f9f958a9607bbb3587.
This fix is not proper. allocate_mqd can't be moved before
allocate_sdma_queue as it depends on q->properties->sdma_id
set in later.

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Philip Yang <philip.yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agoRevert "drm/amdkfd: Fix sdma queue allocate race condition"
Oak Zeng [Sat, 15 Jun 2019 00:32:51 +0000 (19:32 -0500)]
Revert "drm/amdkfd: Fix sdma queue allocate race condition"

This reverts commit f77dac6cd62e5d4bcadd740620af1218bfb54cc6.
This fix is not proper. allocate_mqd can't be moved before
allocate_sdma_queue as it depends on q->properties->sdma_id
set in later.

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Philip Yang <philip.yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: explicitly set mmGDS_VMID0_BASE to 0
James Zhu [Mon, 10 Jun 2019 17:23:41 +0000 (13:23 -0400)]
drm/amdgpu: explicitly set mmGDS_VMID0_BASE to 0

Explicitly set mmGDS_VMID0_BASE to 0. Also update
GDS_VMID0_BASE/_SIZE with direct register writes.

Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: fix compilation error
Hariprasad Kelam [Thu, 13 Jun 2019 02:32:08 +0000 (08:02 +0530)]
drm/amd/display: fix compilation error

this patch fixes below compilation error

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In
function ‘dcn10_apply_ctx_for_surface’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2378:3:
error: implicit declaration of function ‘udelay’
[-Werror=implicit-function-declaration]
   udelay(underflow_check_delay_us);

Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agoamdgpu_dm: no need to check return value of debugfs_create functions
Greg Kroah-Hartman [Thu, 13 Jun 2019 13:20:12 +0000 (15:20 +0200)]
amdgpu_dm: no need to check return value of debugfs_create functions

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: David Francis <David.Francis@amd.com>
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Cc: Anthony Koo <Anthony.Koo@amd.com>
Cc: hersen wu <hersenxs.wu@amd.com>
Cc: "Leo (Hanghong) Ma" <hanghong.ma@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agoamdkfd: no need to check return value of debugfs_create functions
Greg Kroah-Hartman [Thu, 13 Jun 2019 13:19:45 +0000 (15:19 +0200)]
amdkfd: no need to check return value of debugfs_create functions

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Oded Gabbay <oded.gabbay@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agoamdgpu: no need to check return value of debugfs_create functions
Greg Kroah-Hartman [Thu, 13 Jun 2019 13:19:19 +0000 (15:19 +0200)]
amdgpu: no need to check return value of debugfs_create functions

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: xinhui pan <xinhui.pan@amd.com>
Cc: Evan Quan <evan.quan@amd.com>
Cc: Feifei Xu <Feifei.Xu@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agoradeon: no need to check return value of debugfs_create functions
Greg Kroah-Hartman [Thu, 13 Jun 2019 11:56:31 +0000 (13:56 +0200)]
radeon: no need to check return value of debugfs_create functions

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: bump the DRM version for GDS ENOMEM fixes
Marek Olšák [Wed, 5 Jun 2019 02:48:29 +0000 (22:48 -0400)]
drm/amdgpu: bump the DRM version for GDS ENOMEM fixes

So userspace knows when this fix is available.

Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: return 0 by default in amdgpu_pm_load_smu_firmware
Alex Deucher [Tue, 11 Jun 2019 14:45:51 +0000 (09:45 -0500)]
drm/amdgpu: return 0 by default in amdgpu_pm_load_smu_firmware

Fixes SI cards running on amdgpu.

Fixes: 1929059893022 ("drm/amd/amdgpu: add RLC firmware to support raven1 refresh")
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=110883
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: Reserve space for shared fence
Oak Zeng [Tue, 11 Jun 2019 16:15:00 +0000 (11:15 -0500)]
drm/amdgpu: Reserve space for shared fence

Call reservation_object_reserve_shared to reserve
space for shared fence. Otherwise it will trigger
BUG_ON condition in reservation_object_add_shared_fence.

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Acked-by: Christian Konig <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/amdgpu: Bail out of BO node creation if not enough VRAM (v3)
Tom St Denis [Mon, 10 Jun 2019 13:53:58 +0000 (09:53 -0400)]
drm/amd/amdgpu: Bail out of BO node creation if not enough VRAM (v3)

(v2): Return 0 and set mem->mm_node to NULL.
(v3): Use atomic64_add_return instead.

Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: register pm sysfs for sriov (v2)
Yintian Tao [Wed, 5 Jun 2019 12:40:08 +0000 (20:40 +0800)]
drm/amdgpu: register pm sysfs for sriov (v2)

we need register pm sysfs for virt in order
to support dpm level modification because
smu ip block will not be added under SRIOV

v2: whitespace fixes (Alex)

Signed-off-by: Yintian Tao <yttao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: Add device to topology after it is completely inited
Oak Zeng [Mon, 10 Jun 2019 19:44:07 +0000 (14:44 -0500)]
drm/amdkfd: Add device to topology after it is completely inited

We can't have devices that are not completely initialized in kfd topology.
Otherwise it is a race condition when user access not completely
initialized device. This also addresses a kfd_topology_add_device accessing
NULL dqm pointer issue.

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: Initialize HSA_CAP_ATS_PRESENT capability in topology codes
Oak Zeng [Mon, 10 Jun 2019 20:22:35 +0000 (15:22 -0500)]
drm/amdkfd: Initialize HSA_CAP_ATS_PRESENT capability in topology codes

Move HSA_CAP_ATS_PRESENT initialization logic from kfd iommu codes to
kfd topology codes. This removes kfd_iommu_device_init's dependency
on kfd_topology_add_device. Also remove duplicate code setting the
same.

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: Fix sdma queue allocate race condition
Oak Zeng [Thu, 6 Jun 2019 18:19:06 +0000 (13:19 -0500)]
drm/amdkfd: Fix sdma queue allocate race condition

SDMA queue allocation requires the dqm lock at it modify
the global dqm members. Move up the dqm_lock so sdma
queue allocation is enclosed in the critical section. Move
mqd allocation out of critical section to avoid circular
lock dependency.

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: Fix a circular lock dependency
Oak Zeng [Tue, 4 Jun 2019 02:44:55 +0000 (21:44 -0500)]
drm/amdkfd: Fix a circular lock dependency

The idea to break the circular lock dependency is to move allocate_mqd
out of dqm lock protection. See callstack #1 below.

[   59.510149] [drm] Initialized amdgpu 3.30.0 20150101 for 0000:04:00.0 on minor 0

[  513.604034] ======================================================
[  513.604205] WARNING: possible circular locking dependency detected
[  513.604375] 4.18.0-kfd-root #2 Tainted: G        W
[  513.604530] ------------------------------------------------------
[  513.604699] kswapd0/611 is trying to acquire lock:
[  513.604840] 00000000d254022e (&dqm->lock_hidden){+.+.}, at: evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.605150]
               but task is already holding lock:
[  513.605307] 00000000961547fc (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe4/0x250
[  513.605540]
               which lock already depends on the new lock.

[  513.605747]
               the existing dependency chain (in reverse order) is:
[  513.605944]
               -> #4 (&anon_vma->rwsem){++++}:
[  513.606106]        __vma_adjust+0x147/0x7f0
[  513.606231]        __split_vma+0x179/0x190
[  513.606353]        mprotect_fixup+0x217/0x260
[  513.606553]        do_mprotect_pkey+0x211/0x380
[  513.606752]        __x64_sys_mprotect+0x1b/0x20
[  513.606954]        do_syscall_64+0x50/0x1a0
[  513.607149]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  513.607380]
               -> #3 (&mapping->i_mmap_rwsem){++++}:
[  513.607678]        rmap_walk_file+0x1f0/0x280
[  513.607887]        page_referenced+0xdd/0x180
[  513.608081]        shrink_page_list+0x853/0xcb0
[  513.608279]        shrink_inactive_list+0x33b/0x700
[  513.608483]        shrink_node_memcg+0x37a/0x7f0
[  513.608682]        shrink_node+0xd8/0x490
[  513.608869]        balance_pgdat+0x18b/0x3b0
[  513.609062]        kswapd+0x203/0x5c0
[  513.609241]        kthread+0x100/0x140
[  513.609420]        ret_from_fork+0x24/0x30
[  513.609607]
               -> #2 (fs_reclaim){+.+.}:
[  513.609883]        kmem_cache_alloc_trace+0x34/0x2e0
[  513.610093]        reservation_object_reserve_shared+0x139/0x300
[  513.610326]        ttm_bo_init_reserved+0x291/0x480 [ttm]
[  513.610567]        amdgpu_bo_do_create+0x1d2/0x650 [amdgpu]
[  513.610811]        amdgpu_bo_create+0x40/0x1f0 [amdgpu]
[  513.611041]        amdgpu_bo_create_reserved+0x249/0x2d0 [amdgpu]
[  513.611290]        amdgpu_bo_create_kernel+0x12/0x70 [amdgpu]
[  513.611584]        amdgpu_ttm_init+0x2cb/0x560 [amdgpu]
[  513.611823]        gmc_v9_0_sw_init+0x400/0x750 [amdgpu]
[  513.612491]        amdgpu_device_init+0x14eb/0x1990 [amdgpu]
[  513.612730]        amdgpu_driver_load_kms+0x78/0x290 [amdgpu]
[  513.612958]        drm_dev_register+0x111/0x1a0
[  513.613171]        amdgpu_pci_probe+0x11c/0x1e0 [amdgpu]
[  513.613389]        local_pci_probe+0x3f/0x90
[  513.613581]        pci_device_probe+0x102/0x1c0
[  513.613779]        driver_probe_device+0x2a7/0x480
[  513.613984]        __driver_attach+0x10a/0x110
[  513.614179]        bus_for_each_dev+0x67/0xc0
[  513.614372]        bus_add_driver+0x1eb/0x260
[  513.614565]        driver_register+0x5b/0xe0
[  513.614756]        do_one_initcall+0xac/0x357
[  513.614952]        do_init_module+0x5b/0x213
[  513.615145]        load_module+0x2542/0x2d30
[  513.615337]        __do_sys_finit_module+0xd2/0x100
[  513.615541]        do_syscall_64+0x50/0x1a0
[  513.615731]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  513.615963]
               -> #1 (reservation_ww_class_mutex){+.+.}:
[  513.616293]        amdgpu_amdkfd_alloc_gtt_mem+0xcf/0x2c0 [amdgpu]
[  513.616554]        init_mqd+0x223/0x260 [amdgpu]
[  513.616779]        create_queue_nocpsch+0x4d9/0x600 [amdgpu]
[  513.617031]        pqm_create_queue+0x37c/0x520 [amdgpu]
[  513.617270]        kfd_ioctl_create_queue+0x2f9/0x650 [amdgpu]
[  513.617522]        kfd_ioctl+0x202/0x350 [amdgpu]
[  513.617724]        do_vfs_ioctl+0x9f/0x6c0
[  513.617914]        ksys_ioctl+0x66/0x70
[  513.618095]        __x64_sys_ioctl+0x16/0x20
[  513.618286]        do_syscall_64+0x50/0x1a0
[  513.618476]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  513.618695]
               -> #0 (&dqm->lock_hidden){+.+.}:
[  513.618984]        __mutex_lock+0x98/0x970
[  513.619197]        evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.619459]        kfd_process_evict_queues+0x3b/0xb0 [amdgpu]
[  513.619710]        kgd2kfd_quiesce_mm+0x1c/0x40 [amdgpu]
[  513.620103]        amdgpu_amdkfd_evict_userptr+0x38/0x70 [amdgpu]
[  513.620363]        amdgpu_mn_invalidate_range_start_hsa+0xa6/0xc0 [amdgpu]
[  513.620614]        __mmu_notifier_invalidate_range_start+0x70/0xb0
[  513.620851]        try_to_unmap_one+0x7fc/0x8f0
[  513.621049]        rmap_walk_anon+0x121/0x290
[  513.621242]        try_to_unmap+0x93/0xf0
[  513.621428]        shrink_page_list+0x606/0xcb0
[  513.621625]        shrink_inactive_list+0x33b/0x700
[  513.621835]        shrink_node_memcg+0x37a/0x7f0
[  513.622034]        shrink_node+0xd8/0x490
[  513.622219]        balance_pgdat+0x18b/0x3b0
[  513.622410]        kswapd+0x203/0x5c0
[  513.622589]        kthread+0x100/0x140
[  513.622769]        ret_from_fork+0x24/0x30
[  513.622957]
               other info that might help us debug this:

[  513.623354] Chain exists of:
                 &dqm->lock_hidden --> &mapping->i_mmap_rwsem --> &anon_vma->rwsem

[  513.623900]  Possible unsafe locking scenario:

[  513.624189]        CPU0                    CPU1
[  513.624397]        ----                    ----
[  513.624594]   lock(&anon_vma->rwsem);
[  513.624771]                                lock(&mapping->i_mmap_rwsem);
[  513.625020]                                lock(&anon_vma->rwsem);
[  513.625253]   lock(&dqm->lock_hidden);
[  513.625433]
                *** DEADLOCK ***

[  513.625783] 3 locks held by kswapd0/611:
[  513.625967]  #0: 00000000f14edf84 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x30
[  513.626309]  #1: 00000000961547fc (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe4/0x250
[  513.626671]  #2: 0000000067b5cd12 (srcu){....}, at: __mmu_notifier_invalidate_range_start+0x5/0xb0
[  513.627037]
               stack backtrace:
[  513.627292] CPU: 0 PID: 611 Comm: kswapd0 Tainted: G        W         4.18.0-kfd-root #2
[  513.627632] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[  513.627990] Call Trace:
[  513.628143]  dump_stack+0x7c/0xbb
[  513.628315]  print_circular_bug.isra.37+0x21b/0x228
[  513.628581]  __lock_acquire+0xf7d/0x1470
[  513.628782]  ? unwind_next_frame+0x6c/0x4f0
[  513.628974]  ? lock_acquire+0xec/0x1e0
[  513.629154]  lock_acquire+0xec/0x1e0
[  513.629357]  ? evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.629587]  __mutex_lock+0x98/0x970
[  513.629790]  ? evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.630047]  ? evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.630309]  ? evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.630562]  evict_process_queues_nocpsch+0x26/0x140 [amdgpu]
[  513.630816]  kfd_process_evict_queues+0x3b/0xb0 [amdgpu]
[  513.631057]  kgd2kfd_quiesce_mm+0x1c/0x40 [amdgpu]
[  513.631288]  amdgpu_amdkfd_evict_userptr+0x38/0x70 [amdgpu]
[  513.631536]  amdgpu_mn_invalidate_range_start_hsa+0xa6/0xc0 [amdgpu]
[  513.632076]  __mmu_notifier_invalidate_range_start+0x70/0xb0
[  513.632299]  try_to_unmap_one+0x7fc/0x8f0
[  513.632487]  ? page_lock_anon_vma_read+0x68/0x250
[  513.632690]  rmap_walk_anon+0x121/0x290
[  513.632875]  try_to_unmap+0x93/0xf0
[  513.633050]  ? page_remove_rmap+0x330/0x330
[  513.633239]  ? rcu_read_unlock+0x60/0x60
[  513.633422]  ? page_get_anon_vma+0x160/0x160
[  513.633613]  shrink_page_list+0x606/0xcb0
[  513.633800]  shrink_inactive_list+0x33b/0x700
[  513.633997]  shrink_node_memcg+0x37a/0x7f0
[  513.634186]  ? shrink_node+0xd8/0x490
[  513.634363]  shrink_node+0xd8/0x490
[  513.634537]  balance_pgdat+0x18b/0x3b0
[  513.634718]  kswapd+0x203/0x5c0
[  513.634887]  ? wait_woken+0xb0/0xb0
[  513.635062]  kthread+0x100/0x140
[  513.635231]  ? balance_pgdat+0x3b0/0x3b0
[  513.635414]  ? kthread_delayed_work_timer_fn+0x80/0x80
[  513.635626]  ret_from_fork+0x24/0x30
[  513.636042] Evicting PASID 32768 queues
[  513.936236] Restoring PASID 32768 queues
[  524.708912] Evicting PASID 32768 queues
[  524.999875] Restoring PASID 32768 queues

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: Separate mqd allocation and initialization
Oak Zeng [Tue, 4 Jun 2019 02:25:52 +0000 (21:25 -0500)]
drm/amdkfd: Separate mqd allocation and initialization

Introduce a new mqd allocation interface and split the original
init_mqd function into two functions: allocate_mqd and init_mqd.
Also renamed uninit_mqd to free_mqd. This is preparation work to
fix a circular lock dependency.

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: Refactor create_queue_nocpsch
Oak Zeng [Fri, 31 May 2019 21:05:59 +0000 (16:05 -0500)]
drm/amdkfd: Refactor create_queue_nocpsch

This is prepare work to fix a circular lock dependency.
No logic change

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: Only load sdma mqd when queue is active
Oak Zeng [Mon, 3 Jun 2019 17:28:13 +0000 (12:28 -0500)]
drm/amdkfd: Only load sdma mqd when queue is active

Also calls load_mqd with current->mm struct. The mm
struct is used to read back user wptr of the queue.

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: Only initialize sdma vm for sdma queues
Oak Zeng [Fri, 31 May 2019 20:07:42 +0000 (15:07 -0500)]
drm/amdkfd: Only initialize sdma vm for sdma queues

Don't do the same for compute queues

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: use new HMM APIs and helpers
Philip Yang [Wed, 29 May 2019 13:52:16 +0000 (09:52 -0400)]
drm/amdgpu: use new HMM APIs and helpers

HMM provides new APIs and helps in kernel 5.2-rc1 to simplify driver
path. The old hmm APIs are deprecated and will be removed in future.

Below are changes in driver:

1. Change hmm_vma_fault to hmm_range_register and hmm_range_fault which
supports range with multiple vmas, remove the multiple vmas handle path
and data structure.
2. Change hmm_vma_range_done to hmm_range_unregister.
3. Use default flags to avoid pre-fill pfn arrays.
4. Use new hmm_device_ helpers.

Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: Fix bounds checking in amdgpu_ras_is_supported()
Dan Carpenter [Sat, 8 Jun 2019 09:23:57 +0000 (12:23 +0300)]
drm/amdgpu: Fix bounds checking in amdgpu_ras_is_supported()

The "block" variable can be set by the user through debugfs, so it can
be quite large which leads to shift wrapping here.  This means we report
a "block" as supported when it's not, and that leads to array overflows
later on.

This bug is not really a security issue in real life, because debugfs is
generally root only.

Fixes: 36ea1bd2d084 ("drm/amdgpu: add debugfs ctrl node")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: Add CHIP_VEGAM to amdgpu_amdkfd_device_probe
Kent Russell [Tue, 11 Jun 2019 12:33:49 +0000 (08:33 -0400)]
drm/amdgpu: Add CHIP_VEGAM to amdgpu_amdkfd_device_probe

We have the rest of the support in the kerne, but we don't actually boot KFD
on the device without this change

Signed-off-by: Kent Russell <kent.russell@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: fix pm_load_smu_firmware for SR-IOV
Trigger Huang [Tue, 11 Jun 2019 10:32:14 +0000 (18:32 +0800)]
drm/amdgpu: fix pm_load_smu_firmware for SR-IOV

For SR-IOV VF, powerplay may not be supported, in this case,
error '-EINVAL' should not be returned.

Signed-off-by: Trigger Huang <Trigger.Huang@amd.com>
Reviewed-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: set link->dongle_max_pix_clk to 0 on a disconnect
Samson Tam [Tue, 28 May 2019 18:44:40 +0000 (14:44 -0400)]
drm/amd/display: set link->dongle_max_pix_clk to 0 on a disconnect

[Why]
Found issue in EDID Emulation where if we connect a display using
 a passive HDMI-DP dongle, disconnect it and then try to emulate
 a display using DP, we could not see 4K modes.  This was because
 on a disconnect, dongle_max_pix_clk was still set so when we
 emulate using DP, in dc_link_validate_mode_timing(), it would
 think we were still using a dongle and limit the modes we support.

[How]
In dc_link_detect(), set dongle_max_pix_clk to 0 when we detect
 a hotplug out ( if new_connection_type = dc_connection_none ).

Signed-off-by: Samson Tam <Samson.Tam@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: make clk_mgr call enable_pme_wa
Su Sung Chung [Thu, 30 May 2019 18:59:03 +0000 (14:59 -0400)]
drm/amd/display: make clk_mgr call enable_pme_wa

refactor a code so we will call clk_mgr's enable_pme_wa function so we
can use pme_wa for future asics. This way we don't need to worry about
different ASIC since clk_mgr already have that information

Signed-off-by: Su Sung Chung <Su.Chung@amd.com>
Reviewed-by: Eric Yang <eric.yang2@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Do not grant POST_LT_ADJ when TPS4 is used
abdoulaye berthe [Mon, 27 May 2019 15:38:26 +0000 (11:38 -0400)]
drm/amd/display: Do not grant POST_LT_ADJ when TPS4 is used

[Description]

The spec does not allow POST_LT_ADJ_GRANTED to be set when TPS4 is used.

Signed-off-by: abdoulaye berthe <abdoulaye.berthe@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: S3 Resume time increase after decoupling DPMS from fast boot
SivapiriyanKumarasamy [Tue, 28 May 2019 20:36:42 +0000 (16:36 -0400)]
drm/amd/display: S3 Resume time increase after decoupling DPMS from fast boot

[Why]
We incorrectly began powering down the display at boot/resume whenever
fast boot was not possible. This should not be done in the case where there
exists a stream for the eDP since this implies that we want to turn it on.

[How]
Add check for eDP stream to decide whether to power off edp.

Signed-off-by: SivapiriyanKumarasamy <sivapiriyan.kumarasamy@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: Reza Amini <Reza.Amini@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Use stream opp_id instead of hubp
Wesley Chalmers [Wed, 29 May 2019 18:38:53 +0000 (14:38 -0400)]
drm/amd/display: Use stream opp_id instead of hubp

[WHY]
By the time output csc matrix is being programmed, stream connection to
OPP has been established, but this information has not been relayed back
to HUBP.

Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Gamma logic limitations causing unintended use of RAM over ROM.
Harmanprit Tatla [Mon, 27 May 2019 18:22:30 +0000 (14:22 -0400)]
drm/amd/display: Gamma logic limitations causing unintended use of RAM over ROM.

[Why]
Our existing logic in deciding whether to use RAM or ROM
depends on whether we are dealing with an identity gamma ramp.

[How]
In addition to the is_identity flag
a new is_logical_identity flag has been
added. The is_identity flag now denotes
whether the OS gamma is an RGB256 identity
and the new logical identity will inidicate
that the given gamma ramp regardless of its
type is identity.

Signed-off-by: Harmanprit Tatla <harmanprit.tatla@amd.com>
Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Acked-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Add Underflow Asserts to dc
Thomas Lim [Mon, 29 Apr 2019 20:05:42 +0000 (16:05 -0400)]
drm/amd/display: Add Underflow Asserts to dc

[Why]
For debugging underflow issues it can be useful to have asserts when the
underflow initially occurs.

[How]
Read the underflow status registers after actions that have a high risk
of causing underflow and assert that no underflow occurred. If underflow
occurred, clear the bit.

Signed-off-by: Thomas Lim <Thomas.Lim@amd.com>
Reviewed-by: Eric Yang <eric.yang2@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: move vmid determination logic out of dc
Dmytro Laktyushkin [Wed, 22 May 2019 22:05:41 +0000 (18:05 -0400)]
drm/amd/display: move vmid determination logic out of dc

Currently vmid is decided internally inside dc. This makes it
difficult to use vmid use with external components.

This change moves vmid logic outside dc and allowing vmid to be
passed in as a parameter to DC.

Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Remove superflous error message
Jordan Lazare [Mon, 27 May 2019 16:07:19 +0000 (12:07 -0400)]
drm/amd/display: Remove superflous error message

[Why]
VBios sometimes reports incorrect object type as encoder instead of
connector

[How]
Change error message to debug message

Signed-off-by: Jordan Lazare <Jordan.Lazare@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Clean up scdc_test_data struct
Chris Park [Fri, 24 May 2019 20:40:30 +0000 (16:40 -0400)]
drm/amd/display: Clean up scdc_test_data struct

These are no longer needed, Also added RESERVED bits.

Signed-off-by: Chris Park <Chris.Park@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Acked-by: Harry Wentland <Harry.Wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: 3.2.35
Aric Cyr [Mon, 27 May 2019 15:27:11 +0000 (11:27 -0400)]
drm/amd/display: 3.2.35

Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: 3.2.34
Aric Cyr [Mon, 27 May 2019 15:11:17 +0000 (11:11 -0400)]
drm/amd/display: 3.2.34

Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: fix gamma logic breaking driver unload
Krunoslav Kovac [Mon, 27 May 2019 14:57:24 +0000 (10:57 -0400)]
drm/amd/display: fix gamma logic breaking driver unload

Using this logic breaks driver unload, this is a temporary fix
a followup patch will properly fix this

Signed-off-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: fix issue with eDP not detected on driver load
Anthony Koo [Thu, 23 May 2019 01:17:38 +0000 (21:17 -0400)]
drm/amd/display: fix issue with eDP not detected on driver load

[Why]
HPD not going to be high if Panel VDD is off
And all AUX transaction will fail :(

[How]
1. Power on VDD before attempting detection if it isn't already on
2. Improve the robustness by having a retry mechanism on the
first DPCD read after VDD on. If a particular board always holds
HPD high incorrectly, the AUX access may fail, so we can retry
in those scenarios. This change would only improve logic
since it prevents AUX failure leading to bad resolution on internal
panel.
3. We should never need to re-detect internal panel, so logic
is re-arranged a bit to skip earlier.

Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Rework CRTC color management
Nicholas Kazlauskas [Thu, 9 May 2019 16:14:58 +0000 (12:14 -0400)]
drm/amd/display: Rework CRTC color management

[Why]
To prepare for the upcoming DRM plane color management properties
we need to correct a lot of wrong behavior and assumptions made for
CRTC color management.

The documentation added by this commit in amdgpu_dm_color explains
how the HW color pipeline works and its limitations with the DRM
interface.

The current implementation does the following wrong:
- Implicit sRGB DGM when no CRTC DGM is set
- Implicit sRGB RGM when no CRTC RGM is set
- No way to specify a non-linear DGM matrix that produces correct output
- No way to specify a correct RGM when a linear DGM is used

We had workarounds for passing kms_color tests but not all of the
behavior we had wrong was covered by these tests (especially when
it comes to non-linear DGM). Testing both DGM and RGM at the same time
isn't something kms_color tests well either.

[How]
The specifics for how color management works in AMDGPU and the new
behavior can be found by reading the documentation added to
amdgpu_dm_color.c from this patch.

All of the incorrect cases from the old implementation have been
addressed for the atomic interface, but there still a few TODOs for
the legacy one.

Note: this does cause regressions for kms_color@pipe-a-ctm-* over HDMI.

The result looks correct from visual inspection but the CRC no longer
matches. For reference, the test was previously doing the following:

linear degamma -> CTM -> sRGB regamma -> RGB to YUV (709) -> ...

Now the test is doing:

linear degamma -> CTM -> linear regamma -> RGB to YUV (709) -> ...

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Use macro for invalid OPP ID
Wesley Chalmers [Thu, 23 May 2019 15:54:12 +0000 (11:54 -0400)]
drm/amd/display: Use macro for invalid OPP ID

[WHY]
This is meant to make it clearer that 0xf is not a valid OPP ID, and
that code making use of OPP IDs should not accept this value.

Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: add audio related regs
Charlene Liu [Thu, 23 May 2019 19:27:43 +0000 (15:27 -0400)]
drm/amd/display: add audio related regs

Signed-off-by: Charlene Liu <charlene.liu@amd.com>
Reviewed-by: Chris Park <Chris.Park@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: add i2c_hw_Status check to make sure as HW I2c in use
Derek Lai [Wed, 22 May 2019 06:49:23 +0000 (14:49 +0800)]
drm/amd/display: add i2c_hw_Status check to make sure as HW I2c in use

1. Add i2c_hw_Status check to make sure when HW i2c is in use.
2. Don't reset HW engine in is_hw_busy() and instead do this in
process_transaction() because SW i2c does not check if hw i2c is in use

Signed-off-by: Derek Lai <Derek.Lai@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Dont aser if DP_DPHY_INTERNAL_CTRL
Eric Bernstein [Mon, 3 Jun 2019 14:55:41 +0000 (10:55 -0400)]
drm/amd/display: Dont aser if DP_DPHY_INTERNAL_CTRL

No need to assert just return

Signed-off-by: Eric Bernstein <eric.bernstein@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: 3.2.33
Aric Cyr [Fri, 17 May 2019 22:40:19 +0000 (18:40 -0400)]
drm/amd/display: 3.2.33

Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: add some math functions for dcn_calc_math
Charlene Liu [Fri, 17 May 2019 02:52:46 +0000 (22:52 -0400)]
drm/amd/display: add some math functions for dcn_calc_math

Implement floor, ceil, and fabs

Signed-off-by: Charlene Liu <charlene.liu@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Copy stream updates onto streams
Nicholas Kazlauskas [Tue, 14 May 2019 13:19:01 +0000 (09:19 -0400)]
drm/amd/display: Copy stream updates onto streams

[Why]
Almost every function in DC that works with stream state expects that
the current state on the stream is the one that it should be writing
out. These functions are typically triggered by specifying a particular
stream update - but the actual contents of the stream update itself
are ignored, leaving it to the DM to actually update the stream state
itself.

The problem with doing this in DM is a matter of timing. On Linux
most of this is incorrectly done in atomic check, when we actually want
it to be done during atomic commit tail while access to DC is locked.

To give an example, a commit requesting to modify color management
state for DM could come in, be rejected, but still have modified
the actual system state for the stream since it's shared memory. The
next time color management gets programmed it'll use the rejected
color management info - which might not even still be around if it's
a custom transfer function.

So a reasonable place to perform this is within DC itself and this is
the model that's currently in use for surface updates. DC can even
compare the current system state to the incoming surface update to
determine update level, something that can't currnetly be done with the
framework for stream updates.

[How]
Duplicate the framework used for surface updates for stream updates
as well. Copy all the updates after checking the update type.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Update link rate from DPCD 10
Wesley Chalmers [Thu, 16 May 2019 16:40:25 +0000 (12:40 -0400)]
drm/amd/display: Update link rate from DPCD 10

[WHY]
Some panels return a link rate of 0 (unknown) in DPCD 0. In this case,
an appropriate mode cannot be set, and certain panels will show
corruption as they are forced to use a mode they do not support.

[HOW]
Read DPCD 10 in the case where supported link rate from DPCD 0 is
unknown, and pass that value on to the reported link rate.
This re-introduces behaviour present in previous versions that appears
to have been accidentally removed.

Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: fix resource saving missing when power state switch
Tao.Huang [Mon, 6 May 2019 08:26:54 +0000 (16:26 +0800)]
drm/amd/display: fix resource saving missing when power state switch

Signed-off-by: Tao.Huang <Tao.Huang@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Set default ABM level to module parameter
Nicholas Kazlauskas [Thu, 6 Jun 2019 12:53:12 +0000 (08:53 -0400)]
drm/amd/display: Set default ABM level to module parameter

[Why]
The module parameter to specify the default ABM level is now defined,
so hook it up in DM.

[How]
On connector reset specify the default level. DC will program this as
part of the modeset since it gets passed onto the stream in
dm_update_crtc_state.

It's only set for eDP connectors, but it doesn't matter if this is
specified for connectors or hardware that doesn't support ABM.

It's DC's responsibility to check that ABM can be set or adjusted, and
DC does check that the DMCU firmware is running and if there's backlight
control available.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <david.francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: Add module parameter for specifying default ABM level
Nicholas Kazlauskas [Thu, 6 Jun 2019 12:44:37 +0000 (08:44 -0400)]
drm/amdgpu: Add module parameter for specifying default ABM level

[Why]
It's non trivial to configure or specify an ABM reduction level for
userspace outside of X. There is also no method to specify the default
ABM value at boot time.

A parameter should be added to configure this.

[How]
Expose a module parameter that can specify the default ABM level to
use for eDP connectors on DC enabled hardware that loads the DMCU
firmware.

The default is still disabled (0), but levels can range from 1-4. Levels
control how much the backlight can be reduced, with being the least
amount of reduction and four being the most reduction.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <david.francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: drop the incorrect soft_reset for SRIOV
Monk Liu [Fri, 7 Jun 2019 10:56:18 +0000 (18:56 +0800)]
drm/amdgpu: drop the incorrect soft_reset for SRIOV

It's incorrect to do soft reset for SRIOV, when GFX
hang the WREG would stuck there becuase it goes KIQ way.

the GPU reset counter is incorrect: always increase twice
for each timedout

Signed-off-by: Monk Liu <Monk.Liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: Add GDS clearing workaround in later init for gfx9
James Zhu [Fri, 7 Jun 2019 16:19:05 +0000 (12:19 -0400)]
drm/amdgpu: Add GDS clearing workaround in later init for gfx9

Since Hardware bug, GDS exist ECC error after cold boot up,
adding GDS clearing workaround in later init for gfx9.

Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Enable fast plane updates when state->allow_modeset = true
Nicholas Kazlauskas [Fri, 7 Jun 2019 15:16:55 +0000 (11:16 -0400)]
drm/amd/display: Enable fast plane updates when state->allow_modeset = true

[Why]
Whenever the a modeset is allowed (but not neccessarily required) we
currently recreate all the planes in the state. Most IGT tests and
legacy IOCTLs create atomic commits with this flag set, so the pipes
are often unnecessarily reprogrammed.

Poor performance and stuttering can occur when many of these commits
are frequently issued.

This flag was needed when the appropriate conditions for checking
whether the planes needed a reset were not in place, but
should_reset_plane should cover everything needed now.

[How]
Drop the check for state->allow_modeset in should_reset_plane.

All planes on a CRTC should reset in the following conditions:
- The CRTC needs a modeset
- The CRTC degamma changes
- Planes are added or removed to the CRTC

These conditions are all covered in should_reset_plane.

We still can't drop the format change check in should_reset_plane since
fill_dc_plane_info_and_addr isn't called when validating the state, so
we can't tell if a FULL update is needed or not.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <david.francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Use current connector state if NULL when checking bpc
Nicholas Kazlauskas [Wed, 5 Jun 2019 16:33:59 +0000 (12:33 -0400)]
drm/amd/display: Use current connector state if NULL when checking bpc

[Why]
The old logic for checking which output depth to use relied on using
the current connector state rather than the new proposed state. This
was a problem when performing atomic commits since we weren't verifying
it against the incoming max_requested_bpc.

But switching this to only use the new state and not the current state
breaks filtering modes - it'll always assume that the maximum bpc
supported by the display is in use, which will cause certain modes
like 1440p@144Hz to be filtered even when using 8bpc.

[How]
Still use the connector->state if we aren't passed an explicit state.
This will respect the max_bpc the user currently has when filtering
modes.

Also remember to reset the default max_requested_bpc to 8 whenever
connector reset is called to retain old behavior when using the new
property.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110845
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/amdgpu: remove vram_page_split kernel option (v3)
Tom St Denis [Tue, 4 Jun 2019 13:36:57 +0000 (09:36 -0400)]
drm/amd/amdgpu: remove vram_page_split kernel option (v3)

This option is no longer needed.  The default code paths
are now the only option.

v2: Add HPAGE support and a default for non contiguous maps
v3: Misread 512 pages as MiB ...

Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Always allocate initial connector state state
Nicholas Kazlauskas [Tue, 4 Jun 2019 19:21:14 +0000 (15:21 -0400)]
drm/amd/display: Always allocate initial connector state state

[Why]
Unlike our regular connectors, MST connectors don't start off with
an initial connector state. This causes a NULL pointer dereference to
occur when attaching the bpc property since it tries to modify the
connector state.

We need an initial connector state on the connector to avoid the crash.

[How]
Use our reset helper to allocate an initial state and reset the values
to their defaults. We were already doing this before, just not for
MST connectors.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Add connector debugfs for "output_bpc"
Nicholas Kazlauskas [Mon, 3 Jun 2019 17:44:37 +0000 (13:44 -0400)]
drm/amd/display: Add connector debugfs for "output_bpc"

[Why]
This will be useful for verifying whether we enter the correct output
color depth from IGT.

[How]
Locks the connector and associated CRTC if available and outputs
the current and maximum output bpc values.

Example:

cat /sys/kernel/debug/dri/0/DP-1/output_bpc
Current: 8
Maximum: 10

v2: Drop unneeded connector status check

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/amdgpu: add RLC firmware to support raven1 refresh
Prike Liang [Mon, 27 May 2019 08:05:50 +0000 (16:05 +0800)]
drm/amd/amdgpu: add RLC firmware to support raven1 refresh

Use SMU firmware version to indentify the raven1 refresh device and
then load homologous RLC FW.

Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Suggested-by: Huang Rui<Ray.Huang@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/powerplay: add set_power_profile_mode for raven1_refresh
Chengming Gui [Mon, 13 May 2019 09:41:19 +0000 (17:41 +0800)]
drm/amd/powerplay: add set_power_profile_mode for raven1_refresh

add gfxoff_state_changed_by_workload to control gfxoff
when set power_profile_mode

Signed-off-by: Chengming Gui <Jack.Gui@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: Hardcode reg access using L1 security
Trigger Huang [Mon, 3 Jun 2019 08:48:17 +0000 (16:48 +0800)]
drm/amdgpu: Hardcode reg access using L1 security

Under Vega10 SR-IOV VF, L1 register access mode should be enabled by
default as the non-security VF will no longer be supported.

Signed-off-by: Trigger Huang <Trigger.Huang@amd.com>
Reviewed-by: Emily Deng <Emily.Deng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu/{uvd,vcn}: fetch ring's read_ptr after alloc
Shirish S [Tue, 4 Jun 2019 15:55:03 +0000 (21:25 +0530)]
drm/amdgpu/{uvd,vcn}: fetch ring's read_ptr after alloc

[What]
readptr read always returns zero, since most likely
these blocks are either power or clock gated.

[How]
fetch rptr after amdgpu_ring_alloc() which informs
the power management code that the block is about to be
used and hence the gating is turned off.

Signed-off-by: Louis Li <Ching-shih.Li@amd.com>
Signed-off-by: Shirish S <shirish.s@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2)
Louis Li [Fri, 24 May 2019 22:39:47 +0000 (06:39 +0800)]
drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2)

[What]
vce ring test fails consistently during resume in s3 cycle, due to
mismatch read & write pointers.
On debug/analysis its found that rptr to be compared is not being
correctly updated/read, which leads to this failure.
Below is the failure signature:
[drm:amdgpu_vce_ring_test_ring] *ERROR* amdgpu: ring 12 test failed
[drm:amdgpu_device_ip_resume_phase2] *ERROR* resume of IP block <vce_v3_0> failed -110
[drm:amdgpu_device_resume] *ERROR* amdgpu_device_ip_resume failed (-110).

[How]
fetch rptr appropriately, meaning move its read location further down
in the code flow.
With this patch applied the s3 failure is no more seen for >5k s3 cycles,
which otherwise is pretty consistent.

V2: remove reduntant fetch of rptr

Signed-off-by: Louis Li <Ching-shih.Li@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: Implement queue priority controls for gfx9
Jay Cornwall [Tue, 19 Jun 2018 15:17:30 +0000 (10:17 -0500)]
drm/amdkfd: Implement queue priority controls for gfx9

Ported from gfx8, no changes in register setup.

Signed-off-by: Jay Cornwall <Jay.Cornwall@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: CP queue priority controls
Oak Zeng [Tue, 7 Feb 2017 21:40:14 +0000 (15:40 -0600)]
drm/amdkfd: CP queue priority controls

Translate queue priority into pipe priority and write to MQDs.
The priority values are used to perform queue and pipe arbitration.

Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdkfd: Simplify eviction state logic
Felix Kuehling [Wed, 1 May 2019 22:20:13 +0000 (18:20 -0400)]
drm/amdkfd: Simplify eviction state logic

Always mark evicted queues with q->properties.is_evicted = true, even
queues that are inactive for other reason. This simplifies maintaining
the eviction state as it doesn't require updating is_evicted when other
queue activation conditions change.

On the other hand, we now need to check those other queue activation
conditions whenever an evicted queues is restored. To minimize code
duplication, move the queue activation check into a macro so it can be
maintained in one central place.

Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Philip Cox <Philip.Cox@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: Fixed missing to clear some EDC count
James Zhu [Tue, 4 Jun 2019 16:49:02 +0000 (12:49 -0400)]
drm/amdgpu: Fixed missing to clear some EDC count

EDC counts are related to instance and se. They are not the same
for different type of EDC. EDC clearing are changed to base on
individual EDC's instance and SE number.

Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Add back missing hw translate init for DCN1_01
Nicholas Kazlauskas [Fri, 31 May 2019 16:05:26 +0000 (12:05 -0400)]
drm/amd/display: Add back missing hw translate init for DCN1_01

[Why]
DCN_VERSION_1_01 is no longer handled in the dal_hw_translate_init
switch since it was inadvertently dropped in the patch that removed the
unnecessary DCN1_01 guards.

This caused numerous regressions on DCN1_01 when loading the driver.

[How]
Add it back.

Fixes: 97df424fe7a7 ("drm/amd/display: Drop DCN1_01 guards")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amd/display: Don't set mode_changed=false if the stream was removed
Nicholas Kazlauskas [Tue, 11 Jun 2019 16:54:05 +0000 (11:54 -0500)]
drm/amd/display: Don't set mode_changed=false if the stream was removed

[Why]
When switching from vt to desktop with EDID emulation we can receive
an atomic commit such that we have a crtc where mode_changed = true.

During the dm_update_crtc_state disable pass we remove the stream from
the context and free it on the dm_new_crtc_state.

During the enable pass we compare the new provisional stream to the
dm_old_crtc_state->stream and determine that the stream is unchanged
and no scaling has been changed.

Following this, new_crtc_state->mode_changed is then set to false.
The connectors haven't changed and the CRTC active state hasn't changed
so drm_atomic_crtc_needs_modeset returns false, so we jump to
skip_modeset and we hit:

BUG_ON(dm_new_crtc_state->stream == NULL);

...since the old stream is gone from the context and the new stream is
also still NULL.

[How]
Ensure that we still a stream to reuse before checking if we can reuse
the old stream without a full modeset.

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: stop removing BOs from the LRU v3
Christian König [Fri, 10 May 2019 14:09:48 +0000 (16:09 +0200)]
drm/amdgpu: stop removing BOs from the LRU v3

This avoids OOM situations when we have lots of threads
submitting at the same time.

v3: apply this to the whole driver, not just CS

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: create GDS, GWS and OA in system domain
Christian König [Thu, 16 May 2019 08:25:35 +0000 (10:25 +0200)]
drm/amdgpu: create GDS, GWS and OA in system domain

And only move them in on validation. This allows for better control
when multiple processes are fighting over those resources.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu: drop some validation failure messages
Christian König [Fri, 17 May 2019 07:31:44 +0000 (09:31 +0200)]
drm/amdgpu: drop some validation failure messages

The messages about amdgpu_cs_list_validate are duplicated because the
caller will complain into the logs as well and we can also get
interrupted by a signal here.

Also fix the the caller to not report -EAGAIN from validation.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agodrm/amdgpu/psp: udpate ta_ras interface header
Hawking Zhang [Fri, 31 May 2019 14:53:38 +0000 (22:53 +0800)]
drm/amdgpu/psp: udpate ta_ras interface header

ras ta interface header need to be updated to match with latest ta fw updates

Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5 years agoMerge tag 'omapdrm-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux...
Daniel Vetter [Tue, 11 Jun 2019 11:29:33 +0000 (13:29 +0200)]
Merge tag 'omapdrm-5.3' of git://git./linux/kernel/git/tomba/linux into drm-next

omapdrm changes for 5.3

- Add support for DSI command mode displays

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a709f57d-6909-8550-3932-d84e0b5bc3ef@ti.com
5 years agoMerge tag 'du-next-20190608-2' of git://linuxtv.org/pinchartl/media into drm-next
Daniel Vetter [Tue, 11 Jun 2019 08:08:48 +0000 (10:08 +0200)]
Merge tag 'du-next-20190608-2' of git://linuxtv.org/pinchartl/media into drm-next

R-Car DU changes for v5.3:

- R8A774A1 SoC support
- LVDS dual-link mode support
- Support for additional formats
- Misc fixes

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190608134652.GE4786@pendragon.ideasonboard.com
5 years agodrm/omap: add support for manually updated displays
Sebastian Reichel [Thu, 23 May 2019 20:07:56 +0000 (22:07 +0200)]
drm/omap: add support for manually updated displays

This adds the required infrastructure for manually updated displays,
such as DSI command mode panels. While those panels often support
partial updates we currently always do a full refresh.

The display will be refreshed when something calls the dirty callback,
such as libdrm's drmModeDirtyFB(). This is currently being done at least
by the kernel console and Xorg (with modesetting driver) in their
default configuration. Weston does not implement this and the fbdev
backend does not work (display will not update). Weston's DRM backend
uses double buffering and the page flip will also trigger a display
refresh.

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
5 years agodrm/omap: add framedone interrupt support
Sebastian Reichel [Thu, 23 May 2019 20:07:55 +0000 (22:07 +0200)]
drm/omap: add framedone interrupt support

This prepares framedone interrupt handling for
manual display update support.

Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
5 years agodrm/omap: don't check dispc timings for DSI
Sebastian Reichel [Thu, 23 May 2019 20:07:54 +0000 (22:07 +0200)]
drm/omap: don't check dispc timings for DSI

While most display types only forward their VM to the DISPC, this
is not true for DSI. DSI calculates the VM for DISPC based on its
own, but it's not identical. Actually the DSI VM is not even a valid
DISPC VM making this check fail. Let's restore the old behaviour
and avoid checking the DISPC VM for DSI here.

Fixes: 7c27fa57ef31 ("drm/omap: Call dispc timings check operation directly")
Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
5 years agodrm/omap: use DRM_DEBUG_DRIVER instead of CORE
Sebastian Reichel [Thu, 23 May 2019 20:07:53 +0000 (22:07 +0200)]
drm/omap: use DRM_DEBUG_DRIVER instead of CORE

This macro is only used by omapdrm, which should print
debug messages using the DRIVER category instead of the
default CORE category.

Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
5 years agodrm/omap: Use dev_get_drvdata()
Kefeng Wang [Tue, 23 Apr 2019 07:50:01 +0000 (15:50 +0800)]
drm/omap: Use dev_get_drvdata()

Using dev_get_drvdata directly.

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
5 years agodrm/omap: remove open-coded drm_invalid_op()
Emil Velikov [Wed, 22 May 2019 15:02:18 +0000 (16:02 +0100)]
drm/omap: remove open-coded drm_invalid_op()

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
5 years agodrm/omap: Make sure device_id tables are NULL terminated
Thomas Meyer [Mon, 27 May 2019 20:41:15 +0000 (22:41 +0200)]
drm/omap: Make sure device_id tables are NULL terminated

Make sure (of/i2c/platform)_device_id tables are NULL terminated.

Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>