- 13 Mar, 2017 5 commits
-
-
Maarten Lankhorst authored
The watermark code needs to look at the new allocations, so use for_each_new_crtc_in_state everywhere. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489071125-917-4-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
Use for_each_new_plane_in_state, only the new state is needed. Signed-off-by:
-
Maarten Lankhorst authored
Use for_each_new_connector_in_state instead of for_each_connector_in_state. Also make the function static, it's only used inside intel_ddi.c Signed-off-by:
-
Jani Nikula authored
We don't use the error return for anything other than reporting and logging that there is no VBT. We can pull the logging in the function, and remove the error status return. Moreover, if we needed the information for something later on, we'd probably be better off storing the bit in dev_priv, and using it where it's needed, instead of using the error return. While at it, improve the comments. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/438ebbb0d5f0d321c625065b9cc78532a1dab24f.1489152288.git.jani.nikula@intel.com
-
Daniel Vetter authored
Merge tag 'topic/designware-baytrail-2017-03-02' of git://anongit.freedesktop.org/git/drm-intel into drm-intel-next-queued Baytrail PMIC vs. PMU race fixes from Hans de Goede This time the right version (v4), with the compile fix. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
- 12 Mar, 2017 3 commits
-
-
Sagar Arun Kamble authored
Different state is to be maintained for rps.pm_intrmsk_mbz for GuC and Execlists. Updating it inside guc_interrupts_* routines as in those routines GuC load/submission params are sanitized and it should not be set based on HAS_GUC_SCHED during intel_irq_init. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Reviewed-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489199821-6707-3-git-send-email-sagar.a.kamble@intel.comSigned-off-by:
-
Sagar Arun Kamble authored
"pm_intr_keep" is not conveying the intent that it is bitmask of interrupts that must be zero(mbz) in GEN6_PMINTRMSK. Name it "pm_intrmsk_mbz". Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Reviewed-by:
-
Sagar Arun Kamble authored
Like capture of GuC interrupts while enabling GuC submission, release them while disabling GuC submission. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by:
-
- 10 Mar, 2017 9 commits
-
-
Chris Wilson authored
To make our adjustments to RPS requires taking a mutex and potentially sleeping for an unknown duration - until we have completed our adjustments further RPS interrupts are immaterial (they are based on stale thresholds) and we can safely ignore them. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
Currently, we sum the render and media cycles (on different engines) to compute a percentage - but we fail to factor in the duplication into the threshold calculations. This makes us very eager to upclock! If we just consider the maximum busy cycles of either counter, we should have an accurate reflection on whether there are cycles to spare to handle the workload at this frequency. Signed-off-by:
-
Chris Wilson authored
On Baytrail, we manually calculate busyness over the evaluation interval to avoid issues with miscaluations with RC6 enabled. However, it turns out that the DOWN_EI interrupt generator is completely bust - it operates in two modes, continuous or never. Neither of which are conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just compute everything from the UP_EI which does seem to correspond to the desired interval. v2: Fixup gen6_rps_pm_mask() as well v3: Inline vlv_c0_above() to combine the now identical elapsed calculation for up/down and simplify the threshold testing Fixes: 43cf3bf0 ("drm/i915: Improved w/a for rps on Baytrail") Signed-off-by:
-
Chris Wilson authored
Sometimes we want to explicitly page out all available objects from igt, i.e. call i915_gem_shrink_all() and check that subsequent operations succeed. This adds DROP_SHRINK_ALL [0x8] to the set of flags for debugfs/i915_drop_caches for that purpose. Signed-off-by:
-
Chris Wilson authored
We only need to clflush those cachelines that we have validated to be read by the GPU. Userspace typically fills the batch length in correctly, the exceptions tend to be explicit tests within igt. v2: Use ptr_mask_bits() to make Mika happy v3: cmd is not advanced on MI_BBE, so make sure to include an extra dword in the clflush. Signed-off-by:
-
Tvrtko Ursulin authored
In commit 003342a5 ("drm/i915: Keep track of active forcewake domains in a bitmask") I forgot to adjust the newly introduce fw_domains_active state across reset. This caused the assert_forcewakes_inactive to trigger during suspend and resume if there were user held forcewakes. v2: Bitmask checks are required since vfuncs are not always present. v3: Move bitmask tracking to get/put vfunc for simplicity. (Chris Wilson) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 003342a5 ("drm/i915: Keep track of active forcewake domains in a bitmask") Testcase: igt/drv_suspend/forcewake Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: "Paneri, Praveen" <praveen.paneri@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: v4.10+ <stable@vger.kernel.org> Reviewed-by:
-
Shashank Sharma authored
In I915 driver, there are many places where variable name for intel_encoder object is given as 'intel_encoder' whereas it would make more sense to call it just 'encoder' when possible. This patch does this cleanup in file intel_ddi.c. PS: There are few functions where both drm_encoder and intel_encoder are present. For such functions, this patch does nothing. Suggested-by:
Ander Conselvan De Oliveira <conselvan2@gmail.com> Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Acked-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489067021-4709-1-git-send-email-shashank.sharma@intel.com
-
Andrew Morton authored
gcc-4.4.4 has issues with anonymous union initializers. In file included from drivers/gpu/drm/i915/selftests/i915_selftest.c:68: drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:11: error: unknown field 'mock' specified in initializer drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:11: warning: missing braces around initializer drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:11: warning: (near initialization for 'mock_selftests[0].<anonymous>') drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:12: error: unknown field 'mock' specified in initializer drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:13: error: unknown field 'm ... Work around this. Fixes: 953c7f82 ("drm/i915: Provide a hook for selftests") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Reviewed-by:
-
Tvrtko Ursulin authored
In order to ensure no missed interrupts we must first re-direct the interrupts to GuC, and only then re-submit the requests to be replayed after a GPU reset. Otherwise context switch can fire before GuC has been set up to receive it triggering more hangs. v2: Rebase. Signed-off-by:
-
- 09 Mar, 2017 9 commits
-
-
Chris Wilson authored
There is no easily digestible single self-refresh status bit, so don't report one for debugfs/i915_sr_status on gen9+. For the moment this avoids a read of the non-existent WM1_LP_ILK register. Signed-off-by:
-
Sagar Arun Kamble authored
Driver needs to ensure that it doesn't mask the PM interrupts, which are unmasked/needed by GuC firmware. For that, Driver maintains a bitmask of interrupts to be kept unmasked, pm_intr_keep. pm_intr_keep was determined across GuC load. GuC gets loaded in different scenarios and it is not going to change the pm_intr_keep so this patch moves its setup to intel_irq_init. This patch fixes incorrect RPS masking leading to UP interrupts triggered even when at cur_freq=max and inversly for Down interrupts. Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
printks are slow so we should not be doing them from the vblank evade critical section. These could explain why we sometimes seem to blow past our 100 usec deadline. The problem has been there ever since commit c331879c ("drm/i915: skylake sprite plane scaling using shared scalers.") but it may not have been readily visible until commit e1edbd44 ("drm/i915: Complain if we take too long under vblank evasion.") increased our chances of noticing it. Signed-off-by:
-
Matthew Auld authored
Add a selftest to exercise evicting neighbouring nodes that conflict due to page colouring in the GTT. v2: add a peppering of comments Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Matthew Auld authored
It looks like we were incorrectly comparing vma->node against itself instead of the target node, when evicting for a node on systems where we need guard pages between regions with different cache domains. As a consequence we can end up trying to needlessly evict neighbouring nodes, even if they have the same cache domain, and if they were pinned we would fail the eviction. Fixes: 625d988a ("drm/i915: Extract reserving space in the GTT to a helper") Signed-off-by:
-
Matthew Auld authored
For our fake dma objects we can leak the underlying gem object if we fail to pin our "backing storage". [ 39.952618] ============================================================================= [ 39.952625] BUG mock_object (Tainted: G U ): Objects remaining in mock_object on __kmem_cache_shutdown() [ 39.952629] ----------------------------------------------------------------------------- [ 39.952633] Disabling lock debugging due to kernel taint [ 39.952635] INFO: Slab 0xffffea00086c6a00 objects=21 used=1 fp=0xffff88021b1abc00 flags=0x5fff8000008100 [ 39.952640] CPU: 1 PID: 1258 Comm: drv_selftest Tainted: G BU 4.10.0+ #46 [ 39.952641] Hardware name: Apple Inc. MacBookPro11,1/Mac-189A3D4F975D5FFC, BIOS MBP111.88Z.0138.B17.1602221718 02/22/2016 [ 39.952642] Call Trace: [ 39.952648] dump_stack+0x4d/0x6f [ 39.952651] slab_err+0x9d/0xb0 [ 39.952654] ? ksm_migrate_page+0xe0/0xe0 [ 39.952657] ? on_each_cpu_cond+0x9a/0xc0 [ 39.952658] ? __kmalloc+0x1af/0x1c0 [ 39.952660] ? __kmem_cache_shutdown+0x173/0x3e0 [ 39.952661] __kmem_cache_shutdown+0x196/0x3e0 [ 39.952664] kmem_cache_destroy+0xa0/0x150 [ 39.952708] mock_device_release+0x113/0x140 [i915] [ 39.952726] drm_dev_release+0x20/0x40 [drm] [ 39.952735] drm_dev_unref+0x23/0x30 [drm] [ 39.952768] i915_gem_gtt_mock_selftests+0x55/0x70 [i915] [ 39.952803] __run_selftests+0x169/0x1c0 [i915] [ 39.952805] ? 0xffffffffa0151000 [ 39.952840] i915_mock_selftests+0x30/0x60 [i915] [ 39.952869] i915_init+0xc/0x78 [i915] [ 39.952870] ? 0xffffffffa0151000 [ 39.952872] do_one_initcall+0x43/0x170 [ 39.952874] ? __vunmap+0x81/0xd0 [ 39.952875] ? kmem_cache_alloc_trace+0x37/0x170 [ 39.952877] ? do_init_module+0x27/0x1f8 [ 39.952879] do_init_module+0x5f/0x1f8 [ 39.952881] load_module+0x2423/0x29b0 [ 39.952882] ? __symbol_put+0x40/0x40 [ 39.952885] ? kernel_read_file+0x1a3/0x1c0 [ 39.952887] SYSC_finit_module+0xbc/0xf0 [ 39.952889] SyS_finit_module+0xe/0x10 [ 39.952892] entry_SYSCALL_64_fastpath+0x13/0x94 v2: use onion teardown and favour i915_gem_object_put Fixes: 8d28ba45 ("drm/i915: Exercise filling the top/bottom portions of the ppgtt") Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
If we allow the user to convert a GTT mmap address into a userptr, we may end up in recursion hell, where currently we hit a mutex deadlock but other possibilities include use-after-free during the unbind/cancel_userptr. [ 143.203989] gem_userptr_bli D 0 902 898 0x00000000 [ 143.204054] Call Trace: [ 143.204137] __schedule+0x511/0x1180 [ 143.204195] ? pci_mmcfg_check_reserved+0xc0/0xc0 [ 143.204274] schedule+0x57/0xe0 [ 143.204327] schedule_timeout+0x383/0x670 [ 143.204374] ? trace_hardirqs_on_caller+0x187/0x280 [ 143.204457] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 143.204507] ? usleep_range+0x110/0x110 [ 143.204657] ? irq_exit+0x89/0x100 [ 143.204710] ? retint_kernel+0x2d/0x2d [ 143.204794] ? trace_hardirqs_on_caller+0x187/0x280 [ 143.204857] ? _raw_spin_unlock_irq+0x33/0x60 [ 143.204944] wait_for_common+0x1f0/0x2f0 [ 143.205006] ? out_of_line_wait_on_atomic_t+0x170/0x170 [ 143.205103] ? wake_up_q+0xa0/0xa0 [ 143.205159] ? flush_workqueue_prep_pwqs+0x15a/0x2c0 [ 143.205237] wait_for_completion+0x1d/0x20 [ 143.205292] flush_workqueue+0x2e9/0xbb0 [ 143.205339] ? flush_workqueue+0x163/0xbb0 [ 143.205418] ? __schedule+0x533/0x1180 [ 143.205498] ? check_flush_dependency+0x1a0/0x1a0 [ 143.205681] i915_gem_userptr_mn_invalidate_range_start+0x1c7/0x270 [i915] [ 143.205865] ? i915_gem_userptr_dmabuf_export+0x40/0x40 [i915] [ 143.205955] __mmu_notifier_invalidate_range_start+0xc6/0x120 [ 143.206044] ? __mmu_notifier_invalidate_range_start+0x51/0x120 [ 143.206123] zap_page_range_single+0x1c7/0x1f0 [ 143.206171] ? unmap_single_vma+0x160/0x160 [ 143.206260] ? unmap_mapping_range+0xa9/0x1b0 [ 143.206308] ? vma_interval_tree_subtree_search+0x75/0xd0 [ 143.206397] unmap_mapping_range+0x18f/0x1b0 [ 143.206444] ? zap_vma_ptes+0x70/0x70 [ 143.206524] ? __pm_runtime_resume+0x67/0xa0 [ 143.206723] i915_gem_release_mmap+0x1ba/0x1c0 [i915] [ 143.206846] i915_vma_unbind+0x5c2/0x690 [i915] [ 143.206925] ? __lock_is_held+0x52/0x100 [ 143.207076] i915_gem_object_set_tiling+0x1db/0x650 [i915] [ 143.207236] i915_gem_set_tiling_ioctl+0x1d3/0x3b0 [i915] [ 143.207377] ? i915_gem_set_tiling_ioctl+0x5/0x3b0 [i915] [ 143.207457] drm_ioctl+0x36c/0x670 [ 143.207535] ? debug_lockdep_rcu_enabled.part.0+0x1a/0x30 [ 143.207730] ? i915_gem_object_set_tiling+0x650/0x650 [i915] [ 143.207793] ? drm_getunique+0x120/0x120 [ 143.207875] ? __handle_mm_fault+0x996/0x14a0 [ 143.207939] ? vm_insert_page+0x340/0x340 [ 143.208028] ? up_write+0x28/0x50 [ 143.208086] ? vm_mmap_pgoff+0x160/0x190 [ 143.208163] do_vfs_ioctl+0x12c/0xa60 [ 143.208218] ? debug_lockdep_rcu_enabled+0x35/0x40 [ 143.208267] ? ioctl_preallocate+0x150/0x150 [ 143.208353] ? __do_page_fault+0x36a/0x6e0 [ 143.208400] ? mark_held_locks+0x23/0xc0 [ 143.208479] ? up_read+0x1f/0x40 [ 143.208526] ? entry_SYSCALL_64_fastpath+0x5/0xc6 [ 143.208669] ? __fget_light+0xa7/0xc0 [ 143.208747] SyS_ioctl+0x41/0x70 To prevent the possibility of a deadlock, we defer scheduling the worker until after we have proven that given the current mm, the userptr range does not overlap a GGTT mmaping. If another thread tries to remap the GGTT over the userptr before the worker is scheduled, it will be stopped by its invalidate-range flushing the current work, before the deadlock can occur. v2: Improve discussion of how we end up in the deadlock. v3: Don't forget to mark the userptr as active after a successful gup_fast. Rename overlaps_ggtt to noncontiguous_or_overlaps_ggtt. v4: Fix test ordering between invalid GTT mmaping and range completion (Tvrtko) Reported-by:
Michał Winiarski <michal.winiarski@intel.com> Testcase: igt/gem_userptr_blits/map-fixed-invalidate-gup Signed-off-by:
-
Chris Wilson authored
To avoid waiting for work from other invalidate-range threads where not required, only wait on the userptr cancel workqueue if we have added some work to it. Signed-off-by:
-
Chris Wilson authored
If the worker fails, it no longer has pages to release and can be immediately removed from the invalidate-tree. Signed-off-by:
-
- 08 Mar, 2017 14 commits
-
-
Daniel Vetter authored
The trouble here is that looking at all connector->state in the verifier isn't good, because that's run from the commit work, which doesn't hold the connection_mutex. Which means we're only allowed to look at states in our atomic update. The simple fix for future proofing would be to switch over to drm_for_each_connector_in_state, but that has the problem that the verification then fails if not all connectors are in the state. And we also need to be careful to check both old and new encoders, and not screw things up when an encoder gets reassigned. Note that this isn't the full fix, since we still look at connector->state. To fix that, we need Maarten's patch series to switch over to state pointers within drm_atomic_state, but that's a different series. v2: Use oldnew iterator (Maarten). v3: Rebase onto the iter_get/put->iter_begin/end rename. Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
This gets rid of the last users of for_each_intel_connector(), remove that too. At first I wasn't sure whether the 2 loops in the modeset state checker should instead only loop over the connectors in the atomic commit. But we never add connectors to an atomic update if they don't (or won't have) a CRTC assigned, which means there'd be a gap in check coverage. Hence loop over everything on those too. v2: Rebase onto the iter_get/put->iter_begin/end rename. Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
Drive-by fixup while looking at all the connector_list walkers - holding connection_mutex does actually _not_ give you locking to look at the legacy drm_connector->encoder->crtc pointer chain. That one is solely owned by the atomic commit workers. Instead we must inspect the atomic state. Reviewed-by:
-
Daniel Vetter authored
One case where I nuked a now unecessary locking, otherwise all just boring stuff. v2: Rebase onto the iter_get/put->iter_begin/end rename. Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
Nothing special, just rote conversion. v2: Rebase onto the iter_get/put->iter_begin/end rename. Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
While at it also try to reduce the locking a bit to what's really just needed instead of everything that we could possibly lock. Added a new for_each_intel_connector_iter which includes the cast to intel_connector. Otherwise just plain transformation with nothing special going on. v2: Review from Maarten: - Stick with modeset_lock_all in sink_crc, it looks at crtc->state. - Fix up early loop exit in i915_displayport_test_active_write. v3: Rebase onto the iter_get/put->iter_begin/end rename. Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (v2) Signed-off-by:
-
Chris Wilson authored
__i915_gem_request_started() asserts that the seqno is valid, but i915_spin_request() was not checking before querying whether the request had started. Reported-by:
-
Chris Wilson authored
i915_gem_object_is_dead() was a temporary lockdep aide whilst transitioning to a new locking structure for obj->mm. Since commit 1233e2db ("drm/i915: Move object backing storage manipulation to its own locking") it is now unused and should be removed. Signed-off-by:
-
Chris Wilson authored
We have to avoid taking ww_mutex inside the shrinker as we use it as a plain mutex type and so need to avoid recursive deadlocks: [ 602.771969] ================================= [ 602.771970] [ INFO: inconsistent lock state ] [ 602.771973] 4.10.0gpudebug+ #122 Not tainted [ 602.771974] --------------------------------- [ 602.771975] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage. [ 602.771978] kswapd0/40 [HC0[0]:SC0[0]:HE1:SE1] takes: [ 602.771979] (reservation_ww_class_mutex){+.+.?.}, at: [<ffffffffa054680a>] i915_gem_object_wait+0x39a/0x410 [i915] [ 602.772020] {RECLAIM_FS-ON-W} state was registered at: [ 602.772024] mark_held_locks+0x76/0x90 [ 602.772026] lockdep_trace_alloc+0xb8/0xc0 [ 602.772028] __kmalloc_track_caller+0x5d/0x130 [ 602.772031] krealloc+0x89/0xb0 [ 602.772033] reservation_object_reserve_shared+0xaf/0xd0 [ 602.772055] i915_gem_do_execbuffer.isra.35+0x1413/0x18b0 [i915] [ 602.772075] i915_gem_execbuffer2+0x10e/0x1d0 [i915] [ 602.772078] drm_ioctl+0x291/0x480 [ 602.772079] do_vfs_ioctl+0x695/0x6f0 [ 602.772081] SyS_ioctl+0x3c/0x70 [ 602.772084] entry_SYSCALL_64_fastpath+0x18/0xad [ 602.772085] irq event stamp: 5197423 [ 602.772088] hardirqs last enabled at (5197423): [<ffffffff8116751d>] kfree+0xdd/0x170 [ 602.772091] hardirqs last disabled at (5197422): [<ffffffff811674f9>] kfree+0xb9/0x170 [ 602.772095] softirqs last enabled at (5190992): [<ffffffff8107bfe1>] __do_softirq+0x221/0x280 [ 602.772097] softirqs last disabled at (5190575): [<ffffffff8107c294>] irq_exit+0x64/0xc0 [ 602.772099] other info that might help us debug this: [ 602.772100] Possible unsafe locking scenario: [ 602.772101] CPU0 [ 602.772101] ---- [ 602.772102] lock(reservation_ww_class_mutex); [ 602.772104] <Interrupt> [ 602.772105] lock(reservation_ww_class_mutex); [ 602.772107] *** DEADLOCK *** [ 602.772109] 2 locks held by kswapd0/40: [ 602.772110] #0: (shrinker_rwsem){++++..}, at: [<ffffffff811337b5>] shrink_slab.constprop.62+0x35/0x280 [ 602.772116] #1: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0553957>] i915_gem_shrinker_lock+0x27/0x60 [i915] [ 602.772141] stack backtrace: [ 602.772144] CPU: 2 PID: 40 Comm: kswapd0 Not tainted 4.10.0gpudebug+ #122 [ 602.772145] Hardware name: LENOVO 42433ZG/42433ZG, BIOS 8AET64WW (1.44 ) 07/26/2013 [ 602.772147] Call Trace: [ 602.772151] dump_stack+0x68/0xa1 [ 602.772153] print_usage_bug+0x1d4/0x1f0 [ 602.772155] mark_lock+0x390/0x530 [ 602.772157] ? print_irq_inversion_bug+0x200/0x200 [ 602.772159] __lock_acquire+0x405/0x1260 [ 602.772181] ? i915_gem_object_wait+0x39a/0x410 [i915] [ 602.772183] lock_acquire+0x60/0x80 [ 602.772205] ? i915_gem_object_wait+0x39a/0x410 [i915] [ 602.772207] mutex_lock_nested+0x69/0x760 [ 602.772229] ? i915_gem_object_wait+0x39a/0x410 [i915] [ 602.772231] ? kfree+0xdd/0x170 [ 602.772253] ? i915_gem_object_wait+0x163/0x410 [i915] [ 602.772255] ? trace_hardirqs_on_caller+0x18d/0x1c0 [ 602.772256] ? trace_hardirqs_on+0xd/0x10 [ 602.772278] i915_gem_object_wait+0x39a/0x410 [i915] [ 602.772300] i915_gem_object_unbind+0x5e/0x130 [i915] [ 602.772323] i915_gem_shrink+0x22d/0x3d0 [i915] [ 602.772347] i915_gem_shrinker_scan+0x3f/0x80 [i915] [ 602.772349] shrink_slab.constprop.62+0x1ad/0x280 [ 602.772352] shrink_node+0x52/0x80 [ 602.772355] kswapd+0x427/0x5c0 [ 602.772358] kthread+0x122/0x130 [ 602.772360] ? try_to_free_pages+0x270/0x270 [ 602.772362] ? kthread_stop+0x70/0x70 [ 602.772365] ret_from_fork+0x2e/0x40 v2: Add commentary about the pruning being opportunistic Reported-by:Jan Nordholz <jckn@gmx.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99977#c10 Fixes: e54ca977 ("drm/i915: Remove completed fences after a wait") Signed-off-by:
-
Ville Syrjälä authored
DRM_UT_CORE generates way too much noise usually, so having the framebuffer init failures use DRM_UT_CORE is a pain when trying to find out the reason why you failed in creating a framebuffer. Let's use DRM_UT_KMS for these debug messages instead. v2: s/at less than/at most/ in the debug message (Imre) Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170307194210.13400-6-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
intel_fill_fb_info() should pass the correct plane index to _intel_compute_tile_offset() once we start to care about the AUX surface. Signed-off-by:
-
Ville Syrjälä authored
To make life easier let's allow skl_plane_stride() to be called for the AUX surface even when there is no AUX surface. Avoids special cases in the callers. Signed-off-by:
-
Ville Syrjälä authored
Let's try to keep the alignment requirements in one place, and so towards that end let's move the AUX_DIST alignment handling into intel_surf_alignment() alongside the main surface alignment stuff. Signed-off-by:
-
Ville Syrjälä authored
Now that framebuffers can be used even before calling drm_framebuffer_init() we can start to plumb them into more places, instead of passing individual pieces for fb metadata. Signed-off-by:
-
