- 21 Nov, 2017 6 commits
-
-
Ville Syrjälä authored
Moving the init_clock_gating() call from intel_modeset_init_hw() to intel_modeset_gem_init() had an unintended effect of not applying some workarounds on resume. This, for example, cause some kind of corruption to appear at the top of my IVB Thinkpad X1 Carbon LVDS screen after hibernation. Fix the problem by explicitly calling init_clock_gating() from the resume path. I really hope this doesn't break something else again. At least the problems reported at https://bugs.freedesktop.org/show_bug.cgi?id=103549 didn't make a comeback, even after a hibernate cycle. v2: Reorder the init_clock_gating vs. modeset_init_hw to match the display reset path (Rodrigo) Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Fixes: 6ac43272 ("drm/i915: Move init_clock_gating() back to where it was") Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171116160215.25715-1-ville.syrjala@linux.intel.comSigned-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 675f7ff3) Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Chris Wilson authored
Commit 21cc6431 ("drm/i915: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM") tried to fixup the check_flush_dependency warning for hitting i915_gem_userptr_mn_invalidate_range_start from within the shrinker, but I failed to notice userptr has 2 similarly named workqueues. I marked up i915-userptr-acquire as WQ_MEM_RECLAIM whereas we only wait upon i915-userptr-release from inside the reclaim paths. [62530.869510] workqueue: PF_MEMALLOC task 7983(gem_shrink) is flushing !WQ_MEM_RECLAIM i915-userptr-release: (null) [62530.869515] ------------[ cut here ]------------ [62530.869519] WARNING: CPU: 1 PID: 7983 at kernel/workqueue.c:2434 check_flush_dependency+0x7f/0x110 [62530.869519] Modules linked in: pegasus mii ip6table_filter ip6_tables bnep iptable_filter snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic binfmt_misc nls_iso8859_1 intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel snd_hda_codec kvm_intel snd_hda_core snd_hwdep kvm snd_pcm irqbypass snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul crc32_pclmul 8250_dw ghash_clmulni_intel snd_seq pcbc snd_seq_device snd_timer btusb aesni_intel btrtl btbcm aes_x86_64 iwlwifi btintel crypto_simd glue_helper cryptd bluetooth snd intel_cstate input_leds idma64 intel_rapl_perf ecdh_generic serio_raw soundcore cfg80211 wmi_bmof virt_dma intel_lpss_pci intel_lpss acpi_als kfifo_buf industrialio winbond_cir soc_button_array rc_core spidev tpm_crb intel_hid acpi_pad mac_hid sparse_keymap [62530.869546] parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic usbhid i915 i2c_algo_bit prime_numbers drm_kms_helper syscopyarea e1000e sysfillrect sysimgblt fb_sys_fops ahci ptp pps_core libahci drm wmi video i2c_hid hid [62530.869557] CPU: 1 PID: 7983 Comm: gem_shrink Tainted: G U W L 4.14.0-rc8-drm-tip-ww45-commit-1342299+ #1 [62530.869558] Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake H DDR4 RVP, BIOS CNLSFWR1.R00.X098.A00.1707301945 07/30/2017 [62530.869559] task: ffffa1049dbeec80 task.stack: ffffae7d05c44000 [62530.869560] RIP: 0010:check_flush_dependency+0x7f/0x110 [62530.869561] RSP: 0018:ffffae7d05c473a0 EFLAGS: 00010286 [62530.869562] RAX: 000000000000006e RBX: ffffa1049540f400 RCX: ffffffffa3e55788 [62530.869562] RDX: 0000000000000000 RSI: 0000000000000092 RDI: 0000000000000202 [62530.869563] RBP: ffffae7d05c473c0 R08: 000000000000006e R09: 000000000038bb0e [62530.869563] R10: 0000000000000000 R11: 000000000000006e R12: ffffa1049dbeec80 [62530.869564] R13: 0000000000000000 R14: 0000000000000000 R15: ffffae7d05c473e0 [62530.869565] FS: 00007f621b129880(0000) GS:ffffa1050b240000(0000) knlGS:0000000000000000 [62530.869566] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [62530.869566] CR2: 00007f6214400000 CR3: 0000000353a17003 CR4: 00000000003606e0 [62530.869567] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [62530.869567] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [62530.869568] Call Trace: [62530.869570] flush_workqueue+0x115/0x3d0 [62530.869573] ? wake_up_process+0x15/0x20 [62530.869596] i915_gem_userptr_mn_invalidate_range_start+0x12f/0x160 [i915] [62530.869614] ? i915_gem_userptr_mn_invalidate_range_start+0x12f/0x160 [i915] [62530.869616] __mmu_notifier_invalidate_range_start+0x55/0x80 [62530.869618] try_to_unmap_one+0x791/0x8b0 [62530.869620] ? call_rwsem_down_read_failed+0x18/0x30 [62530.869622] rmap_walk_anon+0x10b/0x260 [62530.869624] rmap_walk+0x48/0x60 [62530.869625] try_to_unmap+0x93/0xf0 [62530.869626] ? page_remove_rmap+0x2a0/0x2a0 [62530.869627] ? page_not_mapped+0x20/0x20 [62530.869629] ? page_get_anon_vma+0x90/0x90 [62530.869630] ? invalid_mkclean_vma+0x20/0x20 [62530.869631] migrate_pages+0x946/0xaa0 [62530.869633] ? __ClearPageMovable+0x10/0x10 [62530.869635] ? isolate_freepages_block+0x3c0/0x3c0 [62530.869636] compact_zone+0x22f/0x970 [62530.869638] compact_zone_order+0xa3/0xd0 [62530.869640] try_to_compact_pages+0x1a5/0x2a0 [62530.869641] ? try_to_compact_pages+0x1a5/0x2a0 [62530.869643] __alloc_pages_direct_compact+0x50/0x110 [62530.869644] __alloc_pages_slowpath+0x4da/0xf30 [62530.869646] __alloc_pages_nodemask+0x262/0x280 [62530.869648] alloc_pages_vma+0x165/0x1e0 [62530.869649] shmem_alloc_hugepage+0xd0/0x130 [62530.869651] ? __radix_tree_insert+0x45/0x230 [62530.869652] ? __vm_enough_memory+0x29/0x130 [62530.869654] shmem_alloc_and_acct_page+0x10d/0x1e0 [62530.869655] shmem_getpage_gfp+0x426/0xc00 [62530.869657] shmem_fault+0xa0/0x1e0 [62530.869659] ? file_update_time+0x60/0x110 [62530.869660] __do_fault+0x1e/0xc0 [62530.869661] __handle_mm_fault+0xa35/0x1170 [62530.869662] handle_mm_fault+0xcc/0x1c0 [62530.869664] __do_page_fault+0x262/0x4f0 [62530.869666] do_page_fault+0x2e/0xe0 [62530.869667] page_fault+0x22/0x30 [62530.869668] RIP: 0033:0x404335 [62530.869669] RSP: 002b:00007fff7829e420 EFLAGS: 00010216 [62530.869670] RAX: 00007f6210400000 RBX: 0000000000000004 RCX: 0000000000b80000 [62530.869670] RDX: 0000000000002e01 RSI: 0000000000008000 RDI: 0000000000000004 [62530.869671] RBP: 0000000000000019 R08: 0000000000000002 R09: 0000000000000000 [62530.869671] R10: 0000000000000559 R11: 0000000000000246 R12: 0000000008000000 [62530.869672] R13: 00000000004042f0 R14: 0000000000000004 R15: 000000000000007e [62530.869673] Code: 00 8b b0 18 05 00 00 48 8d 8b b0 00 00 00 48 8d 90 c0 06 00 00 4d 89 f0 48 c7 c7 40 c0 c8 a3 c6 05 68 c5 e8 00 01 e8 c2 68 04 00 <0f> ff 4d 85 ed 74 18 49 8b 45 20 48 8b 70 08 8b 86 00 01 00 00 [62530.869691] ---[ end trace 01e01ad0ff5781f8 ]--- Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103739 Fixes: 21cc6431 ("drm/i915: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM") Signed-off-by:
Matthew Auld <matthew.auld@intel.com> (cherry picked from commit 41729bf2) Signed-off-by:
-
Chris Wilson authored
When we call intel_engine_cancel_signaling() to stop reporting when a request is completed via an asynchronous signal, we remove that request from the breadcrumb wait queue. However, we may be concurrently processing that request in the signaler itself, the actual operations on the request's node itself are serialised but we do not actually clear the waiter after removing it from the tree allowing both parties to attempt to do so and corrupting the rbtree. (Previously removing from the breadcrumb wait queue could only be done on behalf of i915_wait_request, so this race could not happen). Reported-by:
"He, Bo" <bo.he@intel.com> Fixes: 9eb143bb ("drm/i915: Allow a request to be cancelled") Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit c534612e) Signed-off-by:
-
Colin Ian King authored
An earlier fix changed the return type from find_bb_size however the integer return is being assigned to a unsigned int so the -ve error check will never be detected. Make bb_size an int to fix this. Detected by CoverityScan CID#1456886 ("Unsigned compared against 0") Fixes: 1e3197d6 ("drm/i915/gvt: Refine error handling for perform_bb_shadow") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> (cherry picked from commit 24f8a29a) Signed-off-by:
-
Hans de Goede authored
intel_uncore_suspend() unregisters the uncore code's PMIC bus access notifier and gets called on both normal and runtime suspend. intel_uncore_resume_early() re-registers the notifier, but only on normal resume. Add a new intel_uncore_runtime_resume() function which only re-registers the notifier and call that on runtime resume. Cc: stable@vger.kernel.org Reported-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoede@redhat.com (cherry picked from commit bedf4d79) Signed-off-by:
-
Hans de Goede authored
assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does: atomic_dec(&dev_priv->pm.wakeref_count); pm_runtime_mark_last_busy(kdev); pm_runtime_put_autosuspend(kdev); And pm_runtime_put_autosuspend calls intel_runtime_suspend from a workqueue, so there is ample of time between the atomic_dec() and intel_runtime_suspend() unregistering the notifier. If the notifier gets called in this windowd assert_rpm_wakelock_held falsely triggers (at this point we're not runtime-suspended yet). This commit adds disable_rpm_wakeref_asserts and enable_rpm_wakeref_asserts calls around the intel_uncore_forcewake_get(FORCEWAKE_ALL) call in i915_pmic_bus_access_notifier fixing the false-positive WARN_ON. Changes in v2: -Reword comment explaining why disabling the wakeref asserts is ok and necessary Cc: stable@vger.kernel.org Reported-by:
FKr <bugs-freedesktop@ubermail.me> Reviewed-by:
-
- 09 Nov, 2017 9 commits
-
-
Chris Wilson authored
When we close the VMA, we unbind it from the ppgtt and tear down the page directory pointing at it. That may trigger us to return WC pages back to the system, requiring conversion back to WB which itself may sleep. That makes i915_vma_close() unsuitable for use inside the RCU read lock, which we need to hold to iterate the radixtree. The fix is quite simple, we can close all the VMA as we close the ppgtt, we only need to do that instead of closing them during destruction of the LUT. v2: Order between closing the LUT and the ppgtt is important; we use the vma inside the LUT as a means of retrieving the object, and so we must clear the LUT before freeing the VMA when closing the ppgtt. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103638 Fixes: 547da76b ("drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr)") Fixes: d1b48c1e ("drm/i915: Replace execbuf vma ht with an idr") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> (cherry picked from commit 94dec871) Signed-off-by:
-
Ville Syrjälä authored
Apparently setting up a bunch of GT registers before we've properly initialized the rest of the GT hardware leads to these setting being lost. So looks like I broke HSW with commit b7048ea1 ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") by doing init_clock_gating() too early. This should actually affect other platforms as well, but apparently not to such a great degree. What I was ultimately after in that commit was to move the ilk_init_lp_watermarks() call earlier. So let's undo the damage and move init_clock_gating() back to where it was, and call ilk_init_lp_watermarks() just before the watermark state readout. This highlights how fragile and messed up our init order really is. I wonder why we even initialize the display before gem. The opposite order would make much more sense to me... v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must be done before all planes might get disabled. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mark Janes <mark.a.janes@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reported-by:
Mark Janes <mark.a.janes@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549 Fixes: b7048ea1 ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.htmlSigned-off-by:
-
Chris Wilson authored
The shared fence array is not autopruning and may continue to grow as an object is shared between new timelines. Take the opportunity when we think the object is idle (we have to confirm that any external fence is also signaled) to decouple all the fences. We apply a similar trick after waiting on an object, see commit e54ca977 ("drm/i915: Remove completed fences after a wait") v2: No longer need to handle the batch pool as a special case. v3: Need to trylock from within i915_vma_retire as this may be called form the shrinker - and we may later try to allocate underneath the reservation lock, so a deadlock is possible. References: https://bugs.freedesktop.org/show_bug.cgi?id=102936 Fixes: d07f0e59 ("drm/i915: Move GEM activity tracking into a common struct reservation_object") Fixes: 80b204bc ("drm/i915: Enable multiple timelines") Signed-off-by:
-
Chris Wilson authored
The handling of contexts are peculiar. Instead of tieing their vma to activity, we pin the context. This means that we cannot simply unbind the context object itself at will (which would normally cause us to wait for the vma to be idle), but must manually idle the GPU and retire requests first. A consequence of this peculiarity is when doing a last desperate attempt to recover memory. If the memory is tied up inside active context objects, we will fail to recover any memory simply by trying to unbind the objects without first doing a wait-for-idle. A side-effect of removing the call to shrinker_lock_uninterruptible() from i915_gem_shrinker_oom() was that we removed an unlocked wait-for-idle, and so lost the "natural" shrinkage of context objects. By replacing that with a locked wait from inside i915_gem_shrink(), we not only replace it with the ability to recover all context objects, but do so for all i915_gem_shrink_all() callers. v2: Switching requires request allocation, which is not permitted from inside the shrinker as it only uses ordinary allocations. References: https://bugs.freedesktop.org/show_bug.cgi?id=102936 Fixes: f2123818 ("drm/i915: Move dev_priv->mm.[un]bound_list to its own lock") Signed-off-by:
-
Chris Wilson authored
An oversight in commit 87701b4b ("drm/i915: Only free the oldest stale object before a fresh allocation") was that not only do we have to serialise concurrent users of llist_del_first(), but we also have to lock llist_del_first() vs llist_del_all(). From llist.h, * This can be summarized as follows: * * | add | del_first | del_all * add | - | - | - * del_first | | L | L * del_all | | | - * * Where, a particular row's operation can happen concurrently with a column's * operation, with "-" being no lock needed, while "L" being lock is needed. This should hopefully explain: <4>[ 89.287106] general protection fault: 0000 [#1] PREEMPT SMP <4>[ 89.287126] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp i915 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core r8169 mii mei_me mei snd_pcm prime_numbers i2c_hid pinctrl_geminilake pinctrl_intel <4>[ 89.287226] CPU: 2 PID: 23 Comm: ksoftirqd/2 Tainted: G U 4.14.0-rc8-CI-CI_DRM_3315+ #1 <4>[ 89.287247] Hardware name: Intel Corp. Geminilake/GLK RVP2 LP4SD (07), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017 <4>[ 89.287270] task: ffff88017ab34ec0 task.stack: ffffc90000128000 <4>[ 89.287290] RIP: 0010:llist_add_batch+0x4/0x20 <4>[ 89.287301] RSP: 0018:ffffc9000012bdb8 EFLAGS: 00010296 <4>[ 89.287314] RAX: ffffffff811017ad RBX: 6e468801a1560000 RCX: ef3e53fceecdeb81 <4>[ 89.287330] RDX: 6e468801a1566130 RSI: ffff880103d73d98 RDI: ffff880103d73d98 <4>[ 89.287346] RBP: ffffc9000012bdb8 R08: ffff88017ab35780 R09: 0000000000000000 <4>[ 89.287361] R10: ffffc9000012bd68 R11: 00000000abb18c3d R12: ffffffffa01369e0 <4>[ 89.287377] R13: ffff88017fd1b8f8 R14: ffff88017ab34ec0 R15: 000000000000000a <4>[ 89.287393] FS: 0000000000000000(0000) GS:ffff88017fd00000(0000) knlGS:0000000000000000 <4>[ 89.287411] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 89.287424] CR2: 00007ff0c0755018 CR3: 000000016df9b000 CR4: 00000000003406e0 <4>[ 89.287440] Call Trace: <4>[ 89.287511] __i915_gem_free_object_rcu+0x20/0x40 [i915] <4>[ 89.287527] rcu_process_callbacks+0x27a/0x730 <4>[ 89.287544] __do_softirq+0xc0/0x4ae <4>[ 89.287559] ? smpboot_thread_fn+0x2d/0x280 <4>[ 89.287571] run_ksoftirqd+0x1f/0x70 <4>[ 89.287582] smpboot_thread_fn+0x18a/0x280 <4>[ 89.287595] kthread+0x114/0x150 <4>[ 89.287605] ? sort_range+0x30/0x30 <4>[ 89.287615] ? kthread_create_on_node+0x40/0x40 <4>[ 89.287628] ret_from_fork+0x27/0x40 <4>[ 89.287641] Code: 0d 48 83 ea 01 4c 89 c1 48 83 fa ff 74 12 48 23 0c d7 74 ed 48 c1 e2 06 48 0f bd c9 48 8d 04 0a 5d c3 90 90 90 90 90 55 48 89 e5 <48> 8b 0a 48 89 0e 48 89 c8 f0 48 0f b1 3a 48 39 c1 75 ed 48 85 <1>[ 89.287774] RIP: llist_add_batch+0x4/0x20 RSP: ffffc9000012bdb8 <4>[ 89.287826] ---[ end trace e775d15174d8ae02 ]--- (Lockless lists are only easy (and lockless) when only using llist_add/llist_del_all!) Fixes: 87701b4b ("drm/i915: Only free the oldest stale object before a fresh allocation") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> (cherry picked from commit f991c492) Signed-off-by:
-
Maarten Lankhorst authored
The watermarks it should calculate against are the old optimal watermarks. The currently active crtc watermarks are pure fiction, and are invalid in case of a nonblocking modeset, page flip enabling/disabling planes or any other reason. When the crtc is disabled or during a modeset the intermediate watermarks don't need to be programmed separately, and could be directly assigned to the optimal watermarks. Changes since v1: - Use intel_atomic_get_old_crtc_state. (ville) Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171019151341.4579-2-maarten.lankhorst@linux.intel.com [mlankhorst: Add cc stable and bugzilla link, since previous patch doesn't fix issue by itself] Cc: stable@vger.kernel.org #v4.8+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102373 (cherry picked from commit b6b178a7) Signed-off-by:
-
Joonas Lahtinen authored
When running under virtualization (vGPU active), we must disable the lazy PPGTT page table initialization optimization introduced by commit 14826673 ("drm/i915: Only initialize partially filled pagetables"). We must do this because GVT-g makes unduly assumptions about guest behaviour, which this optimization breaks. This results in following looking errors in the host: ERROR gvt: guest page write error -22, gfn 0x7ada8, pa 0x7ada89a8, var 0x6, len 1 The real fix is to not to depend on i915 driver behaviour, but instead either rely on only the contracts that i915 has with the hardware, or add some paravirtualization. While the real fix is en route, it won't be finished in time for 4.15, so the best option is to disable the optimization for now when vGPU is active to avoid breaking 4.15 guests in existing VM environments. Fixes: 14826673 ("drm/i915: Only initialize partially filled pagetables") Suggested-by:
Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by:
-
Chris Wilson authored
Originally we set the priority to max upon inserting the request into the execlists queue (and removing it from the scheduler lists). We could then use the prio==INT_MAX as a shortcut within execlists_schedule() to detect the end of the dependency chain. Since commit 1f181225 ("drm/i915/execlists: Keep request->priority for its lifetime") this is no longer true as we use the request completion as an indicator the schedule dependency chain is complete instead. (This allows us to then reschedule requests even when its context is in flight.) However, this makes the GEM_BUG_ON() inside execlists_schedule() racy as we may change the rq->prio at the same time. As the assertion is useful, let's keep the assertion and remove the micro-optimisation. Fixes: 1f181225 ("drm/i915/execlists: Keep request->priority for its lifetime") Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 64b80085) Signed-off-by:
-
Chris Wilson authored
Back in commit a4b2b015 ("drm/i915: Don't mark an execlists context-switch when idle") we noticed the presence of late context-switch interrupts. We were able to filter those out by looking at whether the ELSP remained active, but in commit beecec90 ("drm/i915/execlists: Preemption!") that became problematic as we now anticipate receiving a context-switch event for preemption while ELSP may be empty. To restore the spurious interrupt suppression, add a counter for the expected number of pending context-switches and skip if we do not need to handle this interrupt to make forward progress. v2: Don't forget to switch on for preempt. v3: Reduce the counter to a on/off boolean tracker. Declare the HW as active when we first submit, and idle after the final completion event (with which we confirm the HW says it is idle), and track each source of activity separately. With a finite number of sources, it should aide us in debugging which gets stuck. Fixes: beecec90 ("drm/i915/execlists: Preemption!") Signed-off-by:
-
- 06 Nov, 2017 1 commit
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
some more amd/ttm fixes. * 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux: drm/ttm: Downgrade pr_err to pr_debug for memory allocation failures drm/ttm: Always and only destroy bo->ttm_resv in ttm_bo_release_list drm/amd/amdgpu: Enabling ACP clock in hw_init (v2) drm/amdgpu/virt: don't dereference undefined 'module' struct
-
- 04 Nov, 2017 2 commits
-
-
Michel Dänzer authored
Memory allocation failure should generally be handled gracefully by callers. In particular, with transparent hugepage support, attempts to allocate huge pages can fail under memory pressure, but the callers fall back to allocating individual pages instead. In that case, there would be spurious [TTM] Unable to get page %u error messages in dmesg. Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Michel Dänzer authored
Fixes a use-after-free due to a race condition in ttm_bo_cleanup_refs_and_unlock, which allows one task to reserve a BO and destroy its ttm_resv while another task is waiting for it to signal in reservation_object_wait_timeout_rcu. v2: * Always initialize bo->ttm_resv in ttm_bo_init_reserved (Christian König) Fixes: 0d2bd2ae "drm/ttm: fix memory leak while individualizing BOs" Reviewed-by: Chunming Zhou <david1.zhou@amd.com> # v1 Reviewed-by:
-
- 03 Nov, 2017 3 commits
-
-
Akshu Agrawal authored
Enabling of ACP in hw_init does away with requirement of order of probe on designware_i2s and acp dma driver. designware_i2s reads i2s registers and this use to fail if acp dma driver was not probed prior to it. BUG=:b:62103837 TEST=modprobe snd-soc-acp-pcm modprobe snd-soc-acp-rt5645-mach aplay -l **** List of PLAYBACK Hardware Devices **** card 0: acprt5650 [acprt5650], device 0: RT5645_AIF1 rt5645-aif1-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 v2: use proper device in dev_err to fix warnings (Alex) Signed-off-by:Akshu Agrawal <akshu.agrawal@amd.com> Reviewed-on: https://chromium-review.googlesource.com/670207Reviewed-by:
Jason Clinton <jclinton@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/676628Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
This time really the last i915 batch for v4.15: - PSR state tracking in crtc state (Ville) - Fix eviction when the GGTT is idle but full (Chris) - BDW DP aux channel timeout fix (James) - LSPCON detection fixes (Shashank) - Use for_each_pipe to iterate over pipes (Mika Kahola) - Replace *_reference/unreference() or *_ref/unref with _get/put() (Harsha) - Refactoring and preparation for DDI encoder type cleanup (Ville) - Broadwell DDI FDI buf translation fix (Chris) - Read CSB and CSB write pointer from HWSP in GVT-g VM if available (Weinan) - GuC/HuC firmware loader refactoring (Michal) - Make shrinking more effective and not stall so much (Chris) - Cannonlake PLL fixes (Rodrigo) - DP MST connector error propagation fixes (James) - Convert timers to use timer_setup (Kees Cook) - Skylake plane enable/disable unification (Juha-Pekka) - Fix to actually free driver internal objects when requested (Chris) - DDI buf trans refactoring (Ville) - Skip waking the device to service pwrite (Chris) - Improve DSI VBT backlight parsing abstraction (Madhav) - Cannonlake VBT DDC pin mapping fix (Rodrigo) * tag 'drm-intel-next-2017-10-23' of git://anongit.freedesktop.org/drm/drm-intel: (87 commits) drm/i915: Update DRIVER_DATE to 20171023 drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin. drm/i915: Let's use more enum intel_dpll_id pll_id. drm/i915: Use existing DSI backlight ports info drm/i915: Parse DSI backlight/cabc ports. drm/i915: Skip waking the device to service pwrite drm/i915/crt: split compute_config hook by platforms drm/i915: remove g4x lowfreq_avail and has_pipe_cxsr drm/i915: Drop the redundant hdmi prefix/suffix from a lot of variables drm/i915: Unify error handling for missing DDI buf trans tables drm/i915: Centralize the SKL DDI A/E vs. B/C/D buf trans handling drm/i915: Kill off the BXT buf_trans default_index drm/i915: Pass encoder type to cnl_ddi_vswing_sequence() explicitly drm/i915: Integrate BXT into intel_ddi_dp_voltage_max() drm/i915: Pass the level to intel_prepare_hdmi_ddi_buffers() drm/i915: Pass the encoder type explicitly to skl_set_iboost() drm/i915: Extract intel_ddi_get_buf_trans_hdmi() drm/i915: Relocate intel_ddi_get_buf_trans_*() functions drm/i915: Flush the idle-worker for debugfs/i915_drop_caches drm/i915: adjust get_crtc_fence_y_offset() to use base.y instead of crtc.y ...
-
Arnd Bergmann authored
Accessing the THIS_MODULE directly is only possible when modules are enabled, otherwise we get a build failure: drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c: In function 'amdgpu_virt_init_data_exchange': drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:331:20: error: dereferencing pointer to incomplete type 'struct module' Further, THIS_MODULE is NULL when the driver is built-in, so the code would likely cause a NULL pointer dereference. This adds an #ifdef check to avoid the compile-time error, plus a NULL pointer check before dereferencing THIS_MODULE. It might be better to find a way to avoid using the module version altogether. Fixes: 2dc8f81e ("drm/amdgpu: SR-IOV data exchange between PF&VF") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-By:
Xiangliang Yu <Xiangliang.Yu@amd.com>
-
- 02 Nov, 2017 19 commits
-
-
git://github.com/skeggsb/linuxDave Airlie authored
nouveau next fixes. Fixes arm32 build. * 'linux-4.15' of git://github.com/skeggsb/linux: drm/nouveau/bios/timing: mark expected switch fall-throughs drm/nouveau/devinit/nv04: mark expected switch fall-throughs drm/nouveau/bios: make const arrays hwsq_signature and edid_sig static drm/nouveau/core/memory: fix missing mutex unlock drm/nouveau/mmu: swap out round for ALIGN
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 1260018 Addresses-Coverity-ID: 1260019 Addresses-Coverity-ID: 1260022 Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 143119 Addresses-Coverity-ID: 143120 Addresses-Coverity-ID: 143121 Addresses-Coverity-ID: 143122 Addresses-Coverity-ID: 143123 Addresses-Coverity-ID: 143124 Signed-off-by:
-
Colin Ian King authored
Don't populate arrays hwsq_signature and edid_sig on the stack but instead make them static. Makes the object code smaller by over 190 bytes: Before: text data bss dec hex filename 35676 3312 64 39052 988c nouveau_bios.o After: text data bss dec hex filename 35319 3472 64 38855 97c7 nouveau_bios.o (gcc version 7.2.0 x86_64) Signed-off-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Rounding value is guaranteed to be power-of-two, so this is better anyway. Fixes build on 32-bit. Signed-off-by: -
git://people.freedesktop.org/~gabbayo/linuxDave Airlie authored
- Usermode Events The current events code implemented some data structures (waitqueue, fifo) that were already implemented in the kernel. The patches below addresses this issue by replacing them with the standard kernel implementation. In addition, they simplify allocation of events IDs and memory for the events. The patches also increase the maximum number of events while maintaining compatibility with the older userspace library. - Remove radeon support Because Kaveri is fully supported in amdgpu and because current and future versions of userspace libraries will only support amdgpu, we removed radeon support from kfd. Current users can move to amdgpu while using the same userspace libraries. - Various bug fixes and cleanups * tag 'drm-amdkfd-next-2017-11-02' of git://people.freedesktop.org/~gabbayo/linux: (26 commits) drm/amdkfd: Minor cleanups drm/amdkfd: Update queue_count before mapping queues drm/amdkfd: Cleanup DQM ASIC-specific ops drm/amdkfd: Register/Deregister process on qpd resolution drm/amdkfd: Fix debug unregister procedure on process termination drm/amdkfd: Avoid calling amd_iommu_unbind_pasid() when suspending drm/amdkfd: Disable CP/SDMA ring/doorbell in MQD drm/amdkfd: Clean up the data structure in kfd_process drm/radeon: deprecate and remove KFD interface drm/amdkfd: use a high priority workqueue for IH work drm/amdkfd: wait only for IH work on IH exit drm/amdkfd: increase IH num entries to 8192 drm/amdkfd: use standard kernel kfifo for IH drm/amdkfd: increase limit of signal events to 4096 per process drm/amdkfd: Make event limit dependent on user mode mapping size drm/amdkfd: Use IH context ID for signal lookup drm/amdkfd: Simplify event ID and signal slot management drm/amdkfd: Simplify events page allocator drm/amdkfd: Use wait_queue_t to implement event waiting drm/amdkfd: remove redundant kfd_event_waiter.input_index ...
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Some amdgpu/ttm fixes. * 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux: drm/amd/powerplay: wrong control mode cause the fan spins faster unnecessarily drm/amd/powerplay: fix memory leak of hardcoded pptable drm/amdgpu:add fw-vram-usage for atomfirmware drm/radeon: fix atombios on big endian drm/ttm:fix memory leak due to individualize drm/amdgpu: fix error handling in amdgpu_bo_do_create drm/ttm: once more fix ttm_buffer_object_transfer drm/amd/powerplay: change ASIC temperature reading on Vega10
-
git://github.com/skeggsb/linuxDave Airlie authored
- Pascal temperature sensor support - Improved BAR2 handling, greatly reduces time required to suspend - Rework of the MMU code - Allows us to properly support Pascal's new MMU layout (implemented) - Lays the groundwork for improved userspace APIs later - Misc other fixes * 'linux-4.15' of git://github.com/skeggsb/linux: (151 commits) drm/nouveau/gr/gf100-: don't prevent module load if firmware missing drm/nouveau/mmu: remove old vmm frontend drm/nouveau: improve selection of GPU page size drm/nouveau: switch over to new memory and vmm interfaces drm/nouveau: remove unused nouveau_fence_work() drm/nouveau: queue delayed unmapping of VMAs on client workqueue drm/nouveau: implement per-client delayed workqueue with fence support drm/nouveau: determine memory class for each client drm/nouveau: pass handle of vmm object to channel allocation ioctls drm/nouveau: switch to vmm limit drm/nouveau: allocate vmm object for every client drm/nouveau: replace use of cpu_coherent with memory types drm/nouveau: use nvif_mmu_type to determine BAR1 caching drm/nouveau: fetch memory type indices that we care about for ttm drm/nouveau: consolidate handling of dma mask drm/nouveau: check kind validity against mmu object drm/nouveau: allocate mmu object for every client drm/nouveau: remove trivial cases of nvxx_device() usage drm/nouveau/mmu: define user interfaces to mmu vmm opertaions drm/nouveau/mmu: define user interfaces to mmu memory allocation ...
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Enables the use of Pascal's 2MiB pages for larger buffers. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
VMAs are about to not take references on the VMM they belong to, which means more care is required when handling delayed unmapping. Queuing it on the client workqueue ensures all pending VMA unmaps will have completed before the VMM is destroyed. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by:
-
