- 09 Mar, 2017 8 commits
-
-
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:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> 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:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1488974407-25175-1-git-send-email-maarten.lankhorst@linux.intel.com Fixes: c331879c ("drm/i915: skylake sprite plane scaling using shared scalers") Cc: <stable@vger.kernel.org> # v4.2+ Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [mlankhorst: Add missing tags, point to the correct offending commit]
-
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:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
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 19 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 <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170301095226.30584-6-daniel.vetter@ffwll.ch
-
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:
-
Bing Niu authored
under virtualization enviroment, it is possible guest update pipe registers across vblank intervals due to overhead of mmio traps or vm schedule out. However, it is safe since those pipe update happen in virual registers and will not be committed to hardware. suppress that atomic commit error message under virtualization case to avoid confusing user. v2: per ville's comment: return early and against Maarten's patch v3: coding style clean Signed-off-by:
Bing Niu <bing.niu@intel.com> Acked-by:
-
Ville Syrjälä 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 bfd16b2a ("drm/i915: Make updating pipe without modeset atomic.") 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. Cc: stable@vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: bfd16b2a ("drm/i915: Make updating pipe without modeset atomic.") Signed-off-by:
-
Daniel Vetter authored
Backmerge drm-next to get at all the good stuff in drm-misc. We need that because: - drm_connector_list_iter conversion for i915 needs the core patches. - Maarten's patches to use the new atomic state iterators also need the core patches. - We need the new link status property to complete the DP retraining work, merging through 2 branches wasn't a good idea and we had to partially backtrack. - Chris needs reservation_object_trylock and we want to roll out kref_read everywhere. Signed-off-by: -
git://github.com/skeggsb/linuxDave Airlie authored
- Re-architecture of the code to handle proprietary fw, more abstracted to support the multitude of differences that NVIDIA introduce - Support in the said code for GP10x ACR and GR fw, giving acceleration support \o/ - Fix for GTX 970 GPUs that are in an odd MMU configuration * 'linux-4.12' of git://github.com/skeggsb/linux: (60 commits) drm/nouveau/fb/gf100-: rework ram detection drm/nouveau/fb/gm200: split ram implementation from gm107 drm/nouveau/fb/gf108: split implementation from gf100 drm/nouveau/fb/gf100-: modify constructors to allow more customisation drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm drm/nouveau/i2c/g94-: return REPLY_M value on reads drm/nouveau/i2c: modify aux interface to return length actually transferred drm/nouveau/gp10x: enable secboot and GR drm/nouveau/gr/gp102: initial support drm/nouveau/falcon: support for gp10x msgqueue drm/nouveau/secboot: add gp102/gp104/gp106/gp107 support drm/nouveau/secboot: put HS code loading code into own file drm/nouveau/secboot: support for r375 ACR drm/nouveau/secboot: support for r367 ACR drm/nouveau/secboot: support for r364 ACR drm/nouveau/secboot: workaround bug when starting SEC2 firmware drm/nouveau/secboot: support standard NVIDIA HS binaries drm/nouveau/secboot: support for unload blob bootloader drm/nouveau/secboot: let callers interpret return value of blobs drm/nouveau/secboot: support for different load and unload falcons ...
-
git://anongit.freedesktop.org/git/drm-intelDave Airlie authored
4 weeks worth of stuff since I was traveling&lazy: - lspcon improvements (Imre) - proper atomic state for cdclk handling (Ville) - gpu reset improvements (Chris) - lots and lots of polish around fences, requests, waiting and everything related all over (both gem and modeset code), from Chris - atomic by default on gen5+ minus byt/bsw (Maarten did the patch to flip the default, really this is a massive joint team effort) - moar power domains, now 64bit (Ander) - big pile of in-kernel unit tests for various gem subsystems (Chris), including simple mock objects for i915 device and and the ggtt manager. - i915_gpu_info in debugfs, for taking a snapshot of the current gpu state. Same thing as i915_error_state, but useful if the kernel didn't notice something is stick. From Chris. - bxt dsi fixes (Umar Shankar) - bxt w/a updates (Jani) - no more struct_mutex for gem object unreference (Chris) - some execlist refactoring (Tvrtko) - color manager support for glk (Ander) - improve the power-well sync code to better take over from the firmware (Imre) - gem tracepoint polish (Tvrtko) - lots of glk fixes all around (Ander) - ctx switch improvements (Chris) - glk dsi support&fixes (Deepak M) - dsi fixes for vlv and clanups, lots of them (Hans de Goede) - switch to i915.ko types in lots of our internal modeset code (Ander) - byt/bsw atomic wm update code, yay (Ville) * tag 'drm-intel-next-2017-03-06' of git://anongit.freedesktop.org/git/drm-intel: (432 commits) drm/i915: Update DRIVER_DATE to 20170306 drm/i915: Don't use enums for hardware engine id drm/i915: Split breadcrumbs spinlock into two drm/i915: Refactor wakeup of the next breadcrumb waiter drm/i915: Take reference for signaling the request from hardirq drm/i915: Add FIFO underrun tracepoints drm/i915: Add cxsr toggle tracepoint drm/i915: Add VLV/CHV watermark/FIFO programming tracepoints drm/i915: Add plane update/disable tracepoints drm/i915: Kill level 0 wm hack for VLV/CHV drm/i915: Workaround VLV/CHV sprite1->sprite0 enable underrun drm/i915: Sanitize VLV/CHV watermarks properly drm/i915: Only use update_wm_{pre,post} for pre-ilk platforms drm/i915: Nuke crtc->wm.cxsr_allowed drm/i915: Compute proper intermediate wms for vlv/cvh drm/i915: Skip useless watermark/FIFO related work on VLV/CHV when not needed drm/i915: Compute vlv/chv wms the atomic way drm/i915: Compute VLV/CHV FIFO sizes based on the PM2 watermarks drm/i915: Plop vlv/chv fifo sizes into crtc state drm/i915: Plop vlv wm state into crtc_state ...
-
- 07 Mar, 2017 13 commits
-
-
Chris Wilson authored
Before we instantiate/pin the backing store for our use, we can prepopulate the shmemfs filp efficiently using a write into the pagecache. We avoid the penalty of instantiating all the pages, important if the user is just writing to a few and never uses the object on the GPU, and using a direct write into shmemfs allows it to avoid the cost of retrieving a page (mostly the clear-before-use, but in theory we could curtail swapin) before it is overwritten. This can be extended later to provide additional specialisation for other backends (other than shmemfs). For now it provides a defense against very large write-only allocations from exhausting all of system memory. v2: Smelling fixes. Fixes: fe115628 ("drm/i915: Implement pwrite without struct-mutex") References: https://bugs.freedesktop.org/show_bug.cgi?id=99107Signed-off-by:
-
Chris Wilson authored
Once the object has been truncated, it is unrecoverable. To facilitate detection of this state store the error in obj->mm.pages. This is required for the next patch which should be applied to v4.10 (via stable), so we also need to mark this patch for backporting. In that regard, let's consider this to be a fix/improvement too. v2: Avoid dereferencing the ERR_PTR when freeing the object. Fixes: 1233e2db ("drm/i915: Move object backing storage manipulation to its own locking") Signed-off-by:
-
Paulo Zanoni authored
Move the {skl,bxt}_{i,uni}nit_cdclk declarations to the place where the intel_cdclk.c functions are declared since these functions have moved there. Signed-off-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487712207-17181-1-git-send-email-paulo.r.zanoni@intel.com
-
Paulo Zanoni authored
The IS_G4X macro is defined as IS_G45 || IS_GM45. We have two points in our code where we have an if statement checking for GM45 followed by an else if statement checking for IS_G4X. This can be confusing since the IS_G4X check won't be catching the previously-checked GM45. Someone quickly trying to check which functions run on each platform may end up getting confused while reading the code. Fix the potential confusion by limiting the else if statements to only check for the platform that was not already checked earlier in the if ladder. Signed-off-by:
-
Chris Wilson authored
In order for the missed-irq update to take effect, the device must be idle. So when the user updates the fault injection via debugfs, idle the device. v2: Idle is explicitly required for setting test_irq, and good behaviour for clearing the missed_irq. v3: Use matching types; expanding to more than ulong rings is left as an exercise to the reader. Testcase: igt/drv_missed_irq Signed-off-by:
-
Jani Nikula authored
No functional changes. Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Bob Paauwe <bob.j.paauwe@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/fadc3b0de70d2c7db7a6ecbe7121328483330f04.1488810382.git.jani.nikula@intel.com
-
Jani Nikula authored
Emphasize that the VBT file is nowadays more about initializing and running stuff based on the VBT contents, not so much about being a "panel driver". No functional changes. Reviewed-by:
-
Jani Nikula authored
The hook names reflect more the phase in the mode set sequence the hooks are called in than what they actually do in terms of the specific encoder. Stick to that scheme, and rename intel_dsi_pre_disable to intel_dsi_disable. Unify the comments around this while at it. No functional changes. v2: Add more sense in the enable/disable hook comments (Ville) Reviewed-by:
-
Jani Nikula authored
Use the prefix intel_dsi_vbt for all the DSI VBT functions. No functional changes. Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by:
-
Jani Nikula authored
Now that we've stopped using the drm_panel hooks, there aren't any benefits left with using the drm_panel framework. Remove the rest of the drm_panel use. No functional changes. Reviewed-by:
-
Jani Nikula authored
Commit 18a00095 ("drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences") started calling the VBT sequence functions directly instead of using the drm_panel hooks. Remove the last drm_panel hook by calling vbt_panel_get_modes() directly. No functional changes. Reviewed-by:
-
Jani Nikula authored
Fact is, there are no other panel drivers except the VBT based one. Simplify the code and maintenance. No functional changes. Reviewed-by:
-
Chris Wilson authored
To prevent having to preserve the drm_crtc_state as we clear the intel_crtc_state, only memset our extended state. Fixes: drivers/gpu/drm/i915/intel_display.c: In function ‘clear_intel_crtc_state’: drivers/gpu/drm/i915/intel_display.c:11301:1: error: the frame size of 1056 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] v2: Add a comment and BUILD_BUG_ON to explain the memset() Signed-off-by:
-
