aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2017-11-01drm/amd/powerplay: wrong control mode cause the fan spins faster unnecessarilyEvan Quan1-1/+1
The fan control mode can either be FDO_PWM_MODE_STATIC or FDO_PWM_MODE_STATIC_RPM. Setting it as AMD_FAN_CTRL_AUTO will cause the fan spin faster wrongly. This can be reproduced by: '# cat /sys/class/hwmon/hwmon0/pwm1 38 '# cat /sys/class/hwmon/hwmon0/pwm1_enable 2 '# echo "2" > /sys/class/hwmon/hwmon0/pwm1_enable '# cat /sys/class/hwmon/hwmon0/pwm1 122 The fan speed get faster wrongly even with its original mode echo back. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2017-11-01drm/amd/powerplay: fix memory leak of hardcoded pptableEric Huang1-0/+3
Signed-off-by: Eric Huang <[email protected]> Reviewed-by: Rex Zhu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-11-01drm/amdgpu:add fw-vram-usage for atomfirmwareMonk Liu1-4/+18
otherwise PF & VF exchange is broken Signed-off-by: Monk Liu <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-11-02Backmerge tag 'v4.14-rc7' into drm-nextDave Airlie30-140/+179
Linux 4.14-rc7 Requested by Ben Skeggs for nouveau to avoid major conflicts, and things were getting a bit conflicty already, esp around amdgpu reverts.
2017-11-02Merge tag 'drm-hisilicon-next-2017-11-01' of github.com:xin3liang/linux into ↵Dave Airlie1-0/+3
drm-next For 4.15 * tag 'drm-hisilicon-next-2017-11-01' of github.com:xin3liang/linux: drm/hisilicon: Ensure LDI regs are properly configured.
2017-11-02Merge tag 'drm-intel-fixes-2017-11-01' of ↵Dave Airlie7-35/+57
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Fixes for Stable: - Fix KBL Blank Screen (Jani) - Fix FIFO Underrun on SNB (Maarten) Other fixes: - Fix GPU Hang on i915gm (Chris) - Fix gem_tiled_pread_pwrite IGT case (Chris) - Cancel modeset retry work during modeset clean-up (Manasi) * tag 'drm-intel-fixes-2017-11-01' of git://anongit.freedesktop.org/drm/drm-intel: drm/i915: Check incoming alignment for unfenced buffers (on i915gm) drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr) drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects) drm/i915/edp: read edp display control registers unconditionally drm/i915: Do not rely on wm preservation for ILK watermarks drm/i915: Cancel the modeset retry work during modeset cleanup
2017-11-02Merge tag 'drm-msm-next-2017-11-01' of ↵Dave Airlie42-702/+1945
git://people.freedesktop.org/~robclark/linux into drm-next + preemption support for a5xx[1][2] + display fixes for 8x96 (snapdragon 820) including fixes for 4k scanout (hwpipe assignment re-work to handle multiple hwpipe assigned to plane for wide scanout) + async cursor plane updates and fixes + refactor adreno_bind/hwinit.. still defer fw loading until device open, but move clk/irq/etc to probe/bind time to fix issues when fw isn't present in filesys + clk/dt bindings cleanups w/ backward compat via msm_clk_get() (dt docs part ack'ed by Rob Herring) + fw loading re-work with helper to handle either /lib/firmware/qcom/$fw or /lib/firmware/$fw.. background, we've started landing fw for some of generations in linux-firmware, but there is a preference to put fw files under 'qcom' subdirectory, which is not what was done on android or for people who copied fw from android. So now we first look in qcom subdir and then fallback to the original location. + bunch of GPU debugging enhancements, to dump full cmdline of processes that trigger faults, and to add a new debugfs to capture cmdstream of just submits that triggered faults.. both quite useful for piglit ;-) * tag 'drm-msm-next-2017-11-01' of git://people.freedesktop.org/~robclark/linux: (38 commits) drm/msm: use %z format modifier for printing size_t drm/msm/mdp5: Don't use async plane update path if plane visibility changes drm/msm/mdp5: mdp5_crtc: Restore cursor state only if LM cursors are enabled drm/msm/mdp5: Update mdp5_pipe_assign to spit out both planes drm/msm/mdp5: Prepare mdp5_pipe_assign for some rework drm/msm: remove mdp5_cursor_plane_funcs drm/msm: update cursors asynchronously through atomic drm/msm/atomic: switch to drm_atomic_helper_check drm/msm/mdp5: restore cursor state when enabling crtc drm/msm/mdp5: don't use autosuspend drm/msm/mdp5: ignore planes that are not visible drm/msm: dump submits which triggered gpu hang drm/msm: preserve IOVAs in submit's bo table drm/msm/rd: allow adding addition msg to top of dump drm/msm: split rd debugfs file drm/msm: add special _get_vaddr_active() for cmdstream dumps drm/msm: show task cmdline in gpu recovery messages drm/msm: dump a rd GPUADDR header for all buffers in the command drm/msm: Removed unused struct_mutex_task drm/msm: Implement preemption for A5XX targets ...
2017-11-01drm/amdkfd: Minor cleanupsFelix Kuehling3-7/+7
These were missed previously when rebasing changes for upstreaming. v2: Remove redundant sched_policy conditions Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2017-11-01drm/amdkfd: Update queue_count before mapping queuesFelix Kuehling1-9/+11
map_queues_cpsch uses the queue_count to decide whether to upload a new runlist. So update the counter before calling it. Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2017-11-01drm/amdkfd: Cleanup DQM ASIC-specific opsYong Zhao4-43/+27
Remove empty initialize function. Rename register_process to update_qpd to avoid confusion with the non-ASIC-specific register_process. Shorten ops_asic_specific to asic_ops. Signed-off-by: Yong Zhao <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2017-11-01drm/amdkfd: Register/Deregister process on qpd resolutionBen Goz1-3/+6
Process registration needs to happen on each device. So use per-device queue lists to determine when to register/deregister the process. Signed-off-by: Ben Goz <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2017-11-01drm/amdkfd: Fix debug unregister procedure on process terminationYair Shachar2-12/+29
Take the dbgmgr lock and unregister before destroying the debug manager. Do this before destroying the queues. v2: Correct locking order in kfd_ioctl_dbg_register to ake sure the process mutex and dbgmgr mutex are always taken in the same order. Signed-off-by: Yair Shachar <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2017-11-01drm/amdkfd: Avoid calling amd_iommu_unbind_pasid() when suspendingYong Zhao1-9/+5
When kfd suspending on APU, we do not need to call amd_iommu_unbind_pasid(), because pasid will be unbound automatically when power goes off. On the other hand, calling amd_iommu_unbind_pasid() will trigger kfd_process_iommu_unbind_callback() if the process is not terminating. By design, kfd_process_iommu_unbind_callback() should only be called for process terminating. So we would rather not to call amd_iommu_unbind_pasid() when suspending. Signed-off-by: Yong Zhao <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2017-11-01drm/amdkfd: Disable CP/SDMA ring/doorbell in MQDJay Cornwall2-30/+11
The MQD represents an inactive context and should not have ring or doorbell enable bits set. Doing so interferes with HWS which streams the MQD onto the HQD. If enable bits are set this activates the ring or doorbell before the HQD is fully configured. Signed-off-by: Jay Cornwall <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2017-11-01drm/amdkfd: Clean up the data structure in kfd_processYong Zhao2-24/+0
A list of per-process queues is maintained in the kfd_process_queue_manager, so the queues array in kfd_process is redundant and in fact unused. Signed-off-by: Yong Zhao <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2017-11-01drm: gma500: Convert timers to use timer_setup()Kees Cook1-5/+3
In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Cc: Patrik Jakobsson <[email protected]> Cc: David Airlie <[email protected]> Cc: [email protected] Signed-off-by: Kees Cook <[email protected]> Acked-by: Daniel Vetter <[email protected]>
2017-11-01drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issueSinclair Yeh1-1/+1
This is an extension of Commit 7c20d213dd3c ("drm/vmwgfx: Work around mode set failure in 2D VMs") With Wayland desktop and atomic mode set, during the mode setting process there is a moment when two framebuffer sized surfaces are being pinned. This was not an issue with Xorg. Since this only happens during a mode change, there should be no performance impact by increasing allowable mem_size. Signed-off-by: Sinclair Yeh <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Cc: [email protected]
2017-11-01drm/vmwgfx: constify vmw_fence_opsArvind Yadav1-1/+1
vmw_fence_ops are not supposed to change at runtime. Functions "dma_fence_init" working with const vmw_fence_ops provided by <linux/dma-fence.h>. So mark the non-const structs as const. Signed-off-by: Arvind Yadav <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]>
2017-11-01drm/i915: Check incoming alignment for unfenced buffers (on i915gm)Chris Wilson1-0/+4
In case the object has changed tiling between calls to execbuf, we need to check if the existing offset inside the GTT matches the new tiling constraint. We even need to do this for "unfenced" tiled objects, where the 3D commands use an implied fence and so the object still needs to match the physical fence restrictions on alignment (only required for gen2 and early gen3). In commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array"), the idea was to remove the second guessing and only set the NEEDS_MAP flag when required. However, the entire check for an unusable offset for fencing was removed and not just the secondary check. I.e. /* avoid costly ping-pong once a batch bo ended up non-mappable */ if (entry->flags & __EXEC_OBJECT_NEEDS_MAP && !i915_vma_is_map_and_fenceable(vma)) return !only_mappable_for_reloc(entry->flags); was entirely removed as the ping-pong between execbuf passes was fixed, but its primary purpose in forcing unaligned unfenced access to be rebound was forgotten. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103502 Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Joonas Lahtinen <[email protected]> (cherry picked from commit 1d033beb20d6d5885587a02a393b6598d766a382) Signed-off-by: Rodrigo Vivi <[email protected]>
2017-11-01drm/msm: use %z format modifier for printing size_tArnd Bergmann1-1/+1
The return type of ARRAY_SIZE() is size_t, so we have to use %zu instead of %lu to avoid this warning: drivers/gpu/drm/msm/msm_gpu.c: In function 'msm_gpu_init': drivers/gpu/drm/msm/msm_gpu.c:742:31: error: format '%lu' expects argument of type 'long unsigned int', but argument 7 has type 'unsigned int' [-Werror=format=] The warning it otherwise harmless as size_t is always the same size as unsigned long in all supported architectures, but gcc doesn't know that. Fixes: c2fceabca6d5 ("drm/msm: Support multiple ringbuffers") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-11-01drm/hisilicon: Ensure LDI regs are properly configured.Peter Griffin1-0/+3
This patch fixes the following soft lockup: BUG: soft lockup - CPU#0 stuck for 23s! [weston:307] On weston idle-timeout the IP is powered down and reset asserted. On weston resume we get a massive vblank IRQ storm due to the LDI registers having lost some state. This state loss is caused by ade_crtc_atomic_begin() not calling ade_ldi_set_mode(). With this patch applied resuming from Weston idle-timeout works well. Signed-off-by: Peter Griffin <[email protected]> Tested-by: John Stultz <[email protected]> Cc: [email protected] Reviewed-by: Xinliang Liu <[email protected]> Signed-off-by: Xinliang Liu <[email protected]>
2017-11-01Merge branch 'linux-4.14' of git://github.com/skeggsb/linux into drm-fixesDave Airlie1-3/+3
single nouveau regression fix. * 'linux-4.14' of git://github.com/skeggsb/linux: drm/nouveau/kms/nv50: use the correct state for base channel notifier setup
2017-11-01drm/nouveau/kms/nv50: use the correct state for base channel notifier setupBen Skeggs1-3/+3
Fixes: 857263 ("drm/nouveau: Handle drm_atomic_helper_swap_state failure") Signed-off-by: Ben Skeggs <[email protected]> Tested-by: Lyude Paul <[email protected]> Reviewed by: Lyude Paul <[email protected]>
2017-10-31drm/radeon: fix atombios on big endianRoman Kapl2-40/+36
The function for byteswapping the data send to/from atombios was buggy for num_bytes not divisible by four. The function must be aware of the fact that after byte-swapping the u32 units, valid bytes might end up after the num_bytes boundary. This patch was tested on kernel 3.12 and allowed us to sucesfully use DisplayPort on and Radeon SI card. Namely it fixed the link training and EDID readout. The function is patched both in radeon and amd drivers, since the functions and the fixes are identical. Signed-off-by: Roman Kapl <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2017-10-31drm/ttm:fix memory leak due to individualizeMonk Liu1-1/+4
after individualize we need manually call reservation_object_fini() if all fences on resv signaled during test, otherwise kmemory leak Signed-off-by: Monk Liu <[email protected]> Reviewed-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2017-10-31drm/amdgpu: fix error handling in amdgpu_bo_do_createChristian König1-3/+3
The bo structure is freed up in case of an error, so we can't do any accounting if that happens. Signed-off-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> CC: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2017-10-31drm/ttm: once more fix ttm_buffer_object_transferChristian König1-0/+1
When the mutex is locked just in the moment we copy it we end up with a warning that we release a locked mutex. Fix this by properly reinitializing the mutex. Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> CC: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2017-10-31drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_allChris Wilson1-1/+1
To acquire all modeset locks requires a ww_ctx to be allocated. As this is the legacy path and the allocation small, to reduce the changes required (and complex untested error handling) to the legacy drivers, we simply assume that the allocation succeeds. At present, it relies on the too-small-to-fail rule, but syzbot found that by injecting a failure here we would hit the WARN. Document that this allocation must succeed with __GFP_NOFAIL. Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-10-30drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr)Chris Wilson1-0/+2
Kasan spotted [IGT] gem_tiled_pread_pwrite: exiting, ret=0 ================================================================== BUG: KASAN: use-after-free in __i915_gem_object_reset_page_iter+0x15c/0x170 [i915] Read of size 8 at addr ffff8801359da310 by task kworker/3:2/182 CPU: 3 PID: 182 Comm: kworker/3:2 Tainted: G U 4.14.0-rc6-CI-Custom_3340+ #1 Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017 Workqueue: events __i915_gem_free_work [i915] Call Trace: dump_stack+0x68/0xa0 print_address_description+0x78/0x290 ? __i915_gem_object_reset_page_iter+0x15c/0x170 [i915] kasan_report+0x23d/0x350 __asan_report_load8_noabort+0x19/0x20 __i915_gem_object_reset_page_iter+0x15c/0x170 [i915] ? i915_gem_object_truncate+0x100/0x100 [i915] ? lock_acquire+0x380/0x380 __i915_gem_object_put_pages+0x30d/0x530 [i915] __i915_gem_free_objects+0x551/0xbd0 [i915] ? lock_acquire+0x13e/0x380 __i915_gem_free_work+0x4e/0x70 [i915] process_one_work+0x6f6/0x1590 ? pwq_dec_nr_in_flight+0x2b0/0x2b0 worker_thread+0xe6/0xe90 ? pci_mmcfg_check_reserved+0x110/0x110 kthread+0x309/0x410 ? process_one_work+0x1590/0x1590 ? kthread_create_on_node+0xb0/0xb0 ret_from_fork+0x27/0x40 Allocated by task 1801: save_stack_trace+0x1b/0x20 kasan_kmalloc+0xee/0x190 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0xdc/0x2e0 radix_tree_node_alloc.constprop.12+0x48/0x330 __radix_tree_create+0x274/0x480 __radix_tree_insert+0xa2/0x610 i915_gem_object_get_sg+0x224/0x670 [i915] i915_gem_object_get_page+0xb5/0x1c0 [i915] i915_gem_pread_ioctl+0x822/0xf60 [i915] drm_ioctl_kernel+0x13f/0x1c0 drm_ioctl+0x6cf/0x980 do_vfs_ioctl+0x184/0xf30 SyS_ioctl+0x41/0x70 entry_SYSCALL_64_fastpath+0x1c/0xb1 Freed by task 37: save_stack_trace+0x1b/0x20 kasan_slab_free+0xaf/0x190 kmem_cache_free+0xbf/0x340 radix_tree_node_rcu_free+0x79/0x90 rcu_process_callbacks+0x46d/0xf40 __do_softirq+0x21c/0x8d3 The buggy address belongs to the object at ffff8801359da0f0 which belongs to the cache radix_tree_node of size 576 The buggy address is located 544 bytes inside of 576-byte region [ffff8801359da0f0, ffff8801359da330) The buggy address belongs to the page: page:ffffea0004d67600 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0 flags: 0x8000000000008100(slab|head) raw: 8000000000008100 0000000000000000 0000000000000000 0000000100110011 raw: ffffea0004b52920 ffffea0004b38020 ffff88015b416a80 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8801359da200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8801359da280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8801359da300: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc ^ ffff8801359da380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8801359da400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint which looks like the slab containing the radixtree iter was freed as we traversed the tree, taking the rcu read lock across the loop should prevent that (deferring all the frees until the end). Reported-by: Tomi Sarvela <[email protected]> Fixes: d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matthew Auld <[email protected]> (cherry picked from commit 547da76b5777859f98bb78e6b57f19463f803c04) Signed-off-by: Rodrigo Vivi <[email protected]>
2017-10-30drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects)Chris Wilson1-0/+2
Kasan spotted [IGT] gem_tiled_pread_pwrite: exiting, ret=0 ================================================================== BUG: KASAN: use-after-free in __i915_gem_object_reset_page_iter+0x15c/0x170 [i915] Read of size 8 at addr ffff8801359da310 by task kworker/3:2/182 CPU: 3 PID: 182 Comm: kworker/3:2 Tainted: G U 4.14.0-rc6-CI-Custom_3340+ #1 Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017 Workqueue: events __i915_gem_free_work [i915] Call Trace: dump_stack+0x68/0xa0 print_address_description+0x78/0x290 ? __i915_gem_object_reset_page_iter+0x15c/0x170 [i915] kasan_report+0x23d/0x350 __asan_report_load8_noabort+0x19/0x20 __i915_gem_object_reset_page_iter+0x15c/0x170 [i915] ? i915_gem_object_truncate+0x100/0x100 [i915] ? lock_acquire+0x380/0x380 __i915_gem_object_put_pages+0x30d/0x530 [i915] __i915_gem_free_objects+0x551/0xbd0 [i915] ? lock_acquire+0x13e/0x380 __i915_gem_free_work+0x4e/0x70 [i915] process_one_work+0x6f6/0x1590 ? pwq_dec_nr_in_flight+0x2b0/0x2b0 worker_thread+0xe6/0xe90 ? pci_mmcfg_check_reserved+0x110/0x110 kthread+0x309/0x410 ? process_one_work+0x1590/0x1590 ? kthread_create_on_node+0xb0/0xb0 ret_from_fork+0x27/0x40 Allocated by task 1801: save_stack_trace+0x1b/0x20 kasan_kmalloc+0xee/0x190 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0xdc/0x2e0 radix_tree_node_alloc.constprop.12+0x48/0x330 __radix_tree_create+0x274/0x480 __radix_tree_insert+0xa2/0x610 i915_gem_object_get_sg+0x224/0x670 [i915] i915_gem_object_get_page+0xb5/0x1c0 [i915] i915_gem_pread_ioctl+0x822/0xf60 [i915] drm_ioctl_kernel+0x13f/0x1c0 drm_ioctl+0x6cf/0x980 do_vfs_ioctl+0x184/0xf30 SyS_ioctl+0x41/0x70 entry_SYSCALL_64_fastpath+0x1c/0xb1 Freed by task 37: save_stack_trace+0x1b/0x20 kasan_slab_free+0xaf/0x190 kmem_cache_free+0xbf/0x340 radix_tree_node_rcu_free+0x79/0x90 rcu_process_callbacks+0x46d/0xf40 __do_softirq+0x21c/0x8d3 The buggy address belongs to the object at ffff8801359da0f0 which belongs to the cache radix_tree_node of size 576 The buggy address is located 544 bytes inside of 576-byte region [ffff8801359da0f0, ffff8801359da330) The buggy address belongs to the page: page:ffffea0004d67600 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0 flags: 0x8000000000008100(slab|head) raw: 8000000000008100 0000000000000000 0000000000000000 0000000100110011 raw: ffffea0004b52920 ffffea0004b38020 ffff88015b416a80 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8801359da200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8801359da280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8801359da300: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc ^ ffff8801359da380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8801359da400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint which looks like the slab containing the radixtree iter was freed as we traversed the tree, taking the rcu read lock across the loop should prevent that (deferring all the frees until the end). Reported-by: Tomi Sarvela <[email protected]> Fixes: 96d776345277 ("drm/i915: Use a radixtree for random access to the object's backing storage") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Matthew Auld <[email protected]> (cherry picked from commit bea6e987c1ff358224e7bef7084be7650f5d1c38) Signed-off-by: Rodrigo Vivi <[email protected]>
2017-10-30drm/i915/edp: read edp display control registers unconditionallyJani Nikula1-3/+10
Per my reading of the eDP spec, DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in DP_EDP_CONFIGURATION_CAP should be set if the eDP display control registers starting at offset DP_EDP_DPCD_REV are "enabled". Currently we check the bit before reading the registers, and DP_EDP_DPCD_REV is the only way to detect eDP revision. Turns out there are (likely buggy) displays that require eDP 1.4+ features, such as supported link rates and link rate select, but do not have the bit set. Read the display control registers unconditionally. They are supposed to read zero anyway if they are not supported, so there should be no harm in this. This fixes the referenced bug by enabling the eDP version check, and thus reading of the supported link rates. The panel in question has 0 in DP_MAX_LINK_RATE which is only supported in eDP 1.4+. Without the supported link rates method we default to RBR which is insufficient for the panel native mode. As a curiosity, the panel also has a bogus value of 0x12 in DP_EDP_DPCD_REV, but that passes our check for >= DP_EDP_14 (which is 0x03). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103400 Reported-and-tested-by: Nicolas P. <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: [email protected] Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Manasi Navare <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 0501a3b0eb01ac2209ef6fce76153e5d6b07034e) Signed-off-by: Rodrigo Vivi <[email protected]>
2017-10-30drm/i915: Do not rely on wm preservation for ILK watermarksMaarten Lankhorst2-31/+21
The original intent was to preserve watermarks as much as possible in intel_pipe_wm.raw_wm, and put the validated ones in intel_pipe_wm.wm. It seems this approach is insufficient and we don't always preserve the raw watermarks, so just use the atomic iterator we're already using to get a const pointer to all bound planes on the crtc. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102373 Signed-off-by: Maarten Lankhorst <[email protected]> Cc: [email protected] #v4.8+ Acked-by: Ville Syrjälä <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 28283f4f359cd7cfa9e65457bb98c507a2cd0cd0) Signed-off-by: Rodrigo Vivi <[email protected]>
2017-10-30drm/i915: Cancel the modeset retry work during modeset cleanupManasi Navare1-1/+18
During modeset cleanup on driver unload we may have a pending hotplug work. This needs to be canceled early during the teardown so that it does not fire after we have freed the connector. We do this after drm_kms_helper_poll_fini(dev) since this might trigger modeset retry work due to link retrain and before intel_fbdev_fini() since this work requires the lock from fbdev. If this is not done we may see something like: DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) ------------[ cut here ]------------ WARNING: CPU: 4 PID: 5010 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x4e/0x60 Modules linked in: i915(-) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm vgem ax88179_178 +a usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e ptp pps_core prime_numbers i2c_hid +[last unloaded: snd_hda_intel] CPU: 4 PID: 5010 Comm: drv_module_relo Tainted: G U 4.14.0-rc3-CI-CI_DRM_3186+ #1 Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWX1.R00.X104.A03.1709140524 09/14/2017 task: ffff8803c827aa40 task.stack: ffffc90000520000 RIP: 0010:mutex_destroy+0x4e/0x60 RSP: 0018:ffffc90000523d58 EFLAGS: 00010292 RAX: 000000000000002a RBX: ffff88044fbef648 RCX: 0000000000000000 RDX: 0000000080000001 RSI: 0000000000000001 RDI: ffffffff810f0cf0 RBP: ffffc90000523d60 R08: 0000000000000001 R09: 0000000000000001 R10: 000000000f21cb81 R11: 0000000000000000 R12: ffff88044f71efc8 R13: ffffffffa02b3d20 R14: ffffffffa02b3d90 R15: ffff880459b29308 FS: 00007f5df4d6e8c0(0000) GS:ffff88045d300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055ec51f00a18 CR3: 0000000451782006 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: drm_fb_helper_fini+0xd9/0x130 intel_fbdev_destroy+0x12/0x60 [i915] intel_fbdev_fini+0x28/0x30 [i915] intel_modeset_cleanup+0x45/0xa0 [i915] i915_driver_unload+0x92/0x180 [i915] i915_pci_remove+0x19/0x30 [i915] i915_driver_unload+0x92/0x180 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x39/0xb0 device_release_driver_internal+0x15d/0x220 driver_detach+0x40/0x80 bus_remove_driver+0x58/0xd0 driver_unregister+0x2c/0x40 pci_unregister_driver+0x36/0xb0 i915_exit+0x1a/0x8b [i915] SyS_delete_module+0x18c/0x1e0 entry_SYSCALL_64_fastpath+0x1c/0xb1 RIP: 0033:0x7f5df3286287 RSP: 002b:00007fff8e107cc8 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: ffffffff81493a03 RCX: 00007f5df3286287 RDX: 0000000000000001 RSI: 0000000000000800 RDI: 0000564c7be02e48 RBP: ffffc90000523f88 R08: 0000000000000000 R09: 0000000000000080 R10: 00007f5df4d6e8c0 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fff8e107eb0 R14: 0000000000000000 R15: 0000000000000000 Or a GPF like: general protection fault: 0000 [#1] PREEMPT SMP Modules linked in: i915(-) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm vgem ax88179_178 +a usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e ptp pps_core prime_numbers i2c_hid +[last unloaded: snd_hda_intel] CPU: 0 PID: 82 Comm: kworker/0:1 Tainted: G U W 4.14.0-rc3-CI-CI_DRM_3186+ #1 Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWX1.R00.X104.A03.1709140524 09/14/2017 Workqueue: events intel_dp_modeset_retry_work_fn [i915] task: ffff88045a5caa40 task.stack: ffffc90000378000 RIP: 0010:drm_setup_crtcs+0x143/0xbf0 RSP: 0018:ffffc9000037bd20 EFLAGS: 00010202 RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000002 RCX: 0000000000000001 RDX: 0000000000000001 RSI: 0000000000000780 RDI: 00000000ffffffff RBP: ffffc9000037bdb8 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000780 R11: 0000000000000000 R12: 0000000000000002 R13: ffff88044fbef4e8 R14: 0000000000000780 R15: 0000000000000438 FS: 0000000000000000(0000) GS:ffff88045d200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055ec51ee5168 CR3: 000000044c89d003 CR4: 00000000003606f0 Call Trace: drm_fb_helper_hotplug_event.part.18+0x7e/0xc0 drm_fb_helper_hotplug_event+0x1a/0x20 intel_fbdev_output_poll_changed+0x1a/0x20 [i915] drm_kms_helper_hotplug_event+0x27/0x30 intel_dp_modeset_retry_work_fn+0x77/0x80 [i915] process_one_work+0x233/0x660 worker_thread+0x206/0x3b0 kthread+0x152/0x190 ? process_one_work+0x660/0x660 ? kthread_create_on_node+0x40/0x40 ret_from_fork+0x27/0x40 Code: 06 00 00 45 8b 45 20 31 db 45 31 e4 45 85 c0 0f 8e 91 06 00 00 44 8b 75 94 44 8b 7d 90 49 8b 45 28 49 63 d4 44 89 f6 41 83 c4 01 <48> 8b 04 d0 44 +89 fa 48 8b 38 48 8b 87 a8 01 00 00 ff 50 20 01 RIP: drm_setup_crtcs+0x143/0xbf0 RSP: ffffc9000037bd20 ---[ end trace 08901ff1a77d30c7 ]--- v2: * Rename it to intel_hpd_poll_fini() and call drm_kms_helper_fini() inside it as the first step before cancel work (Chris Wilson) * Add GPF trace in commit message and make the function static (Maarten Lankhorst) Suggested-by: Maarten Lankhorst <[email protected]> Suggested-by: Chris Wilson <[email protected]> Fixes: 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link training failure") Cc: Chris Wilson <[email protected]> Cc: Tony Cheng <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Ville Syrjala <[email protected]> Cc: Manasi Navare <[email protected]> Cc: Maarten Lankhorst <[email protected]> Signed-off-by: Manasi Navare <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> (cherry picked from commit 886c6b8692ba5f71b578097524b3b082e2e02119) Signed-off-by: Rodrigo Vivi <[email protected]>
2017-10-30drm/radeon: deprecate and remove KFD interfaceChristian König9-985/+4
To quote Felix: "For testing KV with current user mode stack, please use amdgpu. I don't expect this to work with radeon and I'm not planning to spend any effort on making radeon work with a current user mode stack." Only compile tested, but should be straight forward. Signed-off-by: Christian König <[email protected]> Signed-off-by: Oded Gabbay <[email protected]>
2017-10-28drm/msm/mdp5: Don't use async plane update path if plane visibility changesArchit Taneja1-0/+25
When a plane moves out of bounds (i.e, outside the crtc clip region), the plane state's "visible" parameter changes to false. When this happens, we (a) release the hwpipe resources away from it, and (b) unstage the corresponding hwpipe(s) from the Layer Mixers in the CRTC. (a) requires use to acquire the global atomic state and assign a new hwpipe. (b) requires us to re-configure the Layer Mixer, which is done in the CRTC. We don't want to do these things in the async plane update path, so return an error if the new state's "visible" isn't the same as the current state's "visible". Cc: Gustavo Padovan <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-10-28drm/msm/mdp5: mdp5_crtc: Restore cursor state only if LM cursors are enabledArchit Taneja1-29/+37
MDP5 on newer SoCs support cursor planes (i.e, cursor SSPPs). They are a separate entity unlike the cursors within LM. Do not try to restore the MDP5 LM cursor registers, or the corresponding CTL bits if we are not using LM cursors. Also, since we've introduced a new variable 'lm_cursor_enabled', we can now use it to avoid creating a different sets of crtc_funcs for CRTCs with LM cursors and CRTCs with cursor planes. Fixes: "drm/msm/mdp5: restore cursor state when enabling crtc" Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-10-28drm/msm/mdp5: Update mdp5_pipe_assign to spit out both planesArchit Taneja3-20/+57
We currently call mdp5_pipe_assign() twice to assign the left and right hwpipes for our drm_plane. When merging 2 hwpipes, there are a few constraints that we need to keep in mind: - Only the same types of SSPPs are preferred. I.e, a RGB pipe should be paired with another RGB pipe, VIG with VIG etc. - The hwpipe staged on the left should have a higher priority than the hwpipe staged on the right. The priorities are as follows: VIG0 > VIG1 > VIG2 > VIG3 RGB0 > RGB1 > RGB2 > RGB3 DMA0 > DMA1 We can't apply these constraints easily if mdp5_pipe_assign() is called twice. Update mdp5_pipe_assign() to find both hwpipes in one go, and add the extra constraints needed. Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-10-28drm/msm/mdp5: Prepare mdp5_pipe_assign for some reworkArchit Taneja3-27/+27
mdp5_pipe_assign currently returns the hwpipe pointer for the drm_plane. Return it indirectly by setting a pointer passed as an argument. This is needed because we want the func to find out the right hwpipe too. Signed-off-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-10-28drm/msm: remove mdp5_cursor_plane_funcsGustavo Padovan1-22/+3
After converting legacy cursor updates to atomic async commits mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now. Cc: Rob Clark <[email protected]> Cc: Archit Taneja <[email protected]> Signed-off-by: Gustavo Padovan <[email protected]> Tested-by: Archit Taneja <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2017-10-28drm/msm: update cursors asynchronously through atomicGustavo Padovan2-88/+75
Add support to async updates of cursors by using the new atomic interface for that. Basically what this commit does is do what mdp5_update_cursor_plane_legacy() did but through atomic. v5: call drm_atomic_helper_async_check() from the check hook v4: add missing atomic async commit call to msm_atomic_commit(Archit Taneja) v3: move size checks back to drivers (Ville Syrjälä) v2: move fb setting to core and use new state (Eric Anholt) Cc: Rob Clark <[email protected]> Cc: Archit Taneja <[email protected]> Signed-off-by: Gustavo Padovan <[email protected]> Tested-by: Archit Taneja <[email protected]> (v4) [added comment about not hitting async update path if hwpipes are re-assigned or global state is touched] Signed-off-by: Rob Clark <[email protected]>
2017-10-28drm/msm/atomic: switch to drm_atomic_helper_checkRob Clark3-32/+1
Signed-off-by: Rob Clark <[email protected]>
2017-10-28drm/msm/mdp5: restore cursor state when enabling crtcRob Clark1-32/+68
Since we enabled runtime PM, we cannot count on cursor registers to retain their values. This can result in situations where we think the cursor is enabled when we enable the CRTC but it is trying to scan out null (and the rest of cursor position/size is lost), resulting in faults and generally angering the hw when coming out of DPMS with a cursor enabled. stable backport note: reverting 774e39ee3572 is also a suitable fix Fixes: 774e39ee3572 drm/msm/mdp5: Set up runtime PM for MDSS Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Archit Taneja <[email protected]>
2017-10-28drm/msm/mdp5: don't use autosuspendRob Clark5-13/+13
It's only likely to paper over bugs. Unlike the gpu, where we want to keep things alive a bit longer in expectation of the next frame's submit, when the display is shut down we can power off immediately. Signed-off-by: Rob Clark <[email protected]> Acked-by: Archit Taneja <[email protected]>
2017-10-28drm/msm/mdp5: ignore planes that are not visibleRob Clark1-0/+8
Signed-off-by: Rob Clark <[email protected]>
2017-10-28drm/msm: dump submits which triggered gpu hangRob Clark1-20/+27
Note we need to move update_fences() to after msm_rd_dump_submit(), otherwise the bo's referenced by the submit may no longer be valid. Signed-off-by: Rob Clark <[email protected]>
2017-10-28drm/msm: preserve IOVAs in submit's bo tableRob Clark1-5/+6
We need this if we want to dump the submit after cleanup (ie. from hang or fault). But in the backoff/unpin case we want to clear them. So add a flag so we can skip clearing the IOVAs in at cleanup. Signed-off-by: Rob Clark <[email protected]>
2017-10-28drm/msm/rd: allow adding addition msg to top of dumpRob Clark3-4/+16
For faults or hangs, it is nice to be able to include a bit more information. Signed-off-by: Rob Clark <[email protected]>
2017-10-28drm/msm: split rd debugfs fileRob Clark3-29/+79
Split into two instances, the existing $debugfs/rd which continues to dump all submits, and $debugfs/hangrd which will be used to dump just submits that cause gpu hangs (and eventually faults, but that will require some iommu framework enhancements). Signed-off-by: Rob Clark <[email protected]>
2017-10-28drm/msm: add special _get_vaddr_active() for cmdstream dumpsRob Clark3-3/+22
Prep work for adding a debugfs file that dumps just submits which trigger hangs/faults. In this case the bo may already be in the MADV_DONTNEED state, but will be still on the active list (since the submit hasn't completed yet). So the normal check that the bo is in the WILLNEED state does not apply. (But of course the bo should definitely not be in the PURGED state!) Signed-off-by: Rob Clark <[email protected]>
2017-10-28drm/msm: show task cmdline in gpu recovery messagesRob Clark1-12/+43
Now that freedreno gallium driver defaults to using submit_queue task (render reordering), just showing task->comm is not so useful (ie. it is always "flush_queue:0"), so also dump the cmdline. This should also be more useful for piglit/shader_runner. Signed-off-by: Rob Clark <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.