summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-06-11Merge tag 'vfio-v5.2-rc5' of git://github.com/awilliam/linux-vfioLinus Torvalds
Pull VFIO fixes from Alex Williamson: "Fix mdev device create/remove paths to provide initialized device for parent driver create callback and correct ordering of device removal from bus prior to initiating removal by parent. Also resolve races between parent removal and device create/remove paths (all from Parav Pandit)" * tag 'vfio-v5.2-rc5' of git://github.com/awilliam/linux-vfio: vfio/mdev: Synchronize device create/remove with parent removal vfio/mdev: Avoid creating sysfs remove file on stale device removal vfio/mdev: Improve the create/remove sequence
2019-06-11Merge tag 'for-5.2-rc4-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fix from David Sterba: "One regression fix to TRIM ioctl. The range cannot be used as its meaning can be confusing regarding physical and logical addresses. This confusion in code led to potential corruptions when the range overlapped data. The original patch made it to several stable kernels and was promptly reverted, the version for master branch is different due to additional changes but the change is effectively the same" * tag 'for-5.2-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: Always trim all unallocated space in btrfs_trim_free_extents
2019-06-11selinux: log raw contexts as untrusted stringsOndrej Mosnacek
These strings may come from untrusted sources (e.g. file xattrs) so they need to be properly escaped. Reproducer: # setenforce 0 # touch /tmp/test # setfattr -n security.selinux -v 'kuřecí řízek' /tmp/test # runcon system_u:system_r:sshd_t:s0 cat /tmp/test (look at the generated AVCs) Actual result: type=AVC [...] trawcon=kuřecí řízek Expected result: type=AVC [...] trawcon=6B75C5996563C3AD20C599C3AD7A656B Fixes: fede148324c3 ("selinux: log invalid contexts in AVCs") Cc: stable@vger.kernel.org # v5.1+ Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> Acked-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2019-06-11ptrace: restore smp_rmb() in __ptrace_may_access()Jann Horn
Restore the read memory barrier in __ptrace_may_access() that was deleted a couple years ago. Also add comments on this barrier and the one it pairs with to explain why they're there (as far as I understand). Fixes: bfedb589252c ("mm: Add a user_ns owner to mm_struct and fix ptrace permission checks") Cc: stable@vger.kernel.org Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2019-06-11drm/i915/skl: use ranges for voltage level lookupLucas De Marchi
Like was done for ICL, let's convert the voltage level lookup to use frequency ranges rather than individual frequencies. For deciding the voltage, the individual value doesn't really matter. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190610214847.9865-1-lucas.demarchi@intel.com
2019-06-11drm/i915/cnl: use ranges for voltage level lookupLucas De Marchi
Like was done for ICL, let's convert the voltage level lookup to use frequency ranges rather than individual frequencies. For deciding the voltage, the individual value doesn't really matter. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190610214834.9789-1-lucas.demarchi@intel.com
2019-06-11drm/i915/icl: use ranges for voltage level lookupLucas De Marchi
Spec shows voltage level 0 as 307.2, 312, or lower and suggests to use range checks. Prepare for having other frequencies in these ranges by not comparing the exact frequency. v2: invert checks by comparing biggest cdclk first (suggested by Ville) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190610214819.9703-1-lucas.demarchi@intel.com
2019-06-11drm/amdgpu/{uvd,vcn}: fetch ring's read_ptr after allocShirish S
[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> Cc: stable@vger.kernel.org
2019-06-11drm/amdkfd: Add device to topology after it is completely initedOak Zeng
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>
2019-06-11drm/amdkfd: Initialize HSA_CAP_ATS_PRESENT capability in topology codesOak Zeng
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>
2019-06-11drm/amdkfd: Fix sdma queue allocate race conditionOak Zeng
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>
2019-06-11drm/amdkfd: Fix a circular lock dependencyOak Zeng
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>
2019-06-11drm/amdkfd: Separate mqd allocation and initializationOak Zeng
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>
2019-06-11drm/amdkfd: Refactor create_queue_nocpschOak Zeng
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>
2019-06-11drm/amdkfd: Only load sdma mqd when queue is activeOak Zeng
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>
2019-06-11drm/amdkfd: Only initialize sdma vm for sdma queuesOak Zeng
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>
2019-06-11drm/amdgpu: use new HMM APIs and helpersPhilip Yang
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>
2019-06-11drm/rockchip: dw_hdmi: Handle suspend/resumeDouglas Anderson
On Rockchip rk3288-based Chromebooks when you do a suspend/resume cycle: 1. You lose the ability to detect an HDMI device being plugged in. 2. If you're using the i2c bus built in to dw_hdmi then it stops working. Let's call the core dw-hdmi's suspend/resume functions to restore things. NOTE: in downstream Chrome OS (based on kernel 3.14) we used the "late/early" versions of suspend/resume because we found that the VOP was sometimes resuming before dw_hdmi and then calling into us before we were fully resumed. For now I have gone back to the normal suspend/resume because I can't reproduce the problems. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190604204207.168085-2-dianders@chromium.org
2019-06-11drm: bridge: dw-hdmi: Add hook for resumeDouglas Anderson
On Rockchip rk3288-based Chromebooks when you do a suspend/resume cycle: 1. You lose the ability to detect an HDMI device being plugged in. 2. If you're using the i2c bus built in to dw_hdmi then it stops working. Let's add a hook to the core dw-hdmi driver so that we can call it in dw_hdmi-rockchip in the next commit. NOTE: the exact set of steps I've done here in resume come from looking at the normal dw_hdmi init sequence in upstream Linux plus the sequence that we did in downstream Chrome OS 3.14. Testing show that it seems to work, but if an extra step is needed or something here is not needed we could improve it. As part of this change we'll refactor the hardware init bits of dw-hdmi to happen all in one function and all at the same time. Since we need to init the interrupt mutes before we request the IRQ, this means moving the hardware init earlier in the function, but there should be no problems with that. Also as part of this we now unconditionally init the "i2c" parts of dw-hdmi, but again that ought to be fine. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190604204207.168085-1-dianders@chromium.org
2019-06-11drm/amdgpu: Fix bounds checking in amdgpu_ras_is_supported()Dan Carpenter
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>
2019-06-11drm/amdgpu: Add CHIP_VEGAM to amdgpu_amdkfd_device_probeKent Russell
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>
2019-06-11drm/amdgpu: fix pm_load_smu_firmware for SR-IOVTrigger Huang
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>
2019-06-11drm/amd/display: set link->dongle_max_pix_clk to 0 on a disconnectSamson Tam
[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>
2019-06-11drm/amd/display: make clk_mgr call enable_pme_waSu Sung Chung
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>
2019-06-11drm/amd/display: Do not grant POST_LT_ADJ when TPS4 is usedabdoulaye berthe
[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>
2019-06-11drm/amd/display: S3 Resume time increase after decoupling DPMS from fast bootSivapiriyanKumarasamy
[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>
2019-06-11drm/amd/display: Use stream opp_id instead of hubpWesley Chalmers
[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>
2019-06-11drm/amd/display: Gamma logic limitations causing unintended use of RAM over ROM.Harmanprit Tatla
[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>
2019-06-11drm/amd/display: Add Underflow Asserts to dcThomas Lim
[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>
2019-06-11drm/amd/display: move vmid determination logic out of dcDmytro Laktyushkin
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>
2019-06-11drm/amd/display: Remove superflous error messageJordan Lazare
[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>
2019-06-11drm/amd/display: Clean up scdc_test_data structChris Park
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>
2019-06-11drm/amd/display: 3.2.35Aric Cyr
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>
2019-06-11drm/amd/display: 3.2.34Aric Cyr
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>
2019-06-11drm/amd/display: fix gamma logic breaking driver unloadKrunoslav Kovac
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>
2019-06-11drm/amd/display: fix issue with eDP not detected on driver loadAnthony Koo
[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>
2019-06-11drm/amd/display: Rework CRTC color managementNicholas Kazlauskas
[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>
2019-06-11drm/amd/display: Use macro for invalid OPP IDWesley Chalmers
[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>
2019-06-11drm/amd/display: add audio related regsCharlene Liu
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>
2019-06-11drm/amd/display: add i2c_hw_Status check to make sure as HW I2c in useDerek Lai
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>
2019-06-11drm/amd/display: Dont aser if DP_DPHY_INTERNAL_CTRLEric Bernstein
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>
2019-06-11drm/amd/display: 3.2.33Aric Cyr
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>
2019-06-11drm/amd/display: add some math functions for dcn_calc_mathCharlene Liu
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>
2019-06-11drm/amd/display: Copy stream updates onto streamsNicholas Kazlauskas
[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>
2019-06-11drm/amd/display: Update link rate from DPCD 10Wesley Chalmers
[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>
2019-06-11drm/amd/display: fix resource saving missing when power state switchTao.Huang
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>
2019-06-11drm/amd/display: Set default ABM level to module parameterNicholas Kazlauskas
[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>
2019-06-11drm/amdgpu: Add module parameter for specifying default ABM levelNicholas Kazlauskas
[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>
2019-06-11drm/amdgpu: drop the incorrect soft_reset for SRIOVMonk Liu
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>
2019-06-11drm/amdgpu: Add GDS clearing workaround in later init for gfx9James Zhu
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>
generated by cgit (git 2.34.1) at 2025-09-13 21:28:34 +0000