Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 09 3月, 2017 14 次提交
    • M
      drm/i915: use correct node for handling cache domain eviction · fe65cbdb
      由 Matthew Auld 提交于 
      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: NMatthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170306235414.23407-3-matthew.auld@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      fe65cbdb
    • M
      drm/i915/selftests: don't leak the gem object · a5dd8f5a
      由 Matthew Auld 提交于 
      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: NMatthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170306235414.23407-2-matthew.auld@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      a5dd8f5a
    • C
      drm/i915/userptr: Disallow wrapping GTT into a userptr · 1c8782dd
      由 Chris Wilson 提交于 
      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: NMichał Winiarski <michal.winiarski@intel.com>
Testcase: igt/gem_userptr_blits/map-fixed-invalidate-gup
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170308215903.24171-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      1c8782dd
    • C
      drm/i915/userptr: Only flush the workqueue if required · d151e9ce
      由 Chris Wilson 提交于 
      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: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170307205851.32578-2-chris@chris-wilson.co.ukReviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      d151e9ce
    • C
      drm/i915/userptr: Deactivate a failed userptr if the worker reports an EFAULT · 42953b3c
      由 Chris Wilson 提交于 
      If the worker fails, it no longer has pages to release and can be
immediately removed from the invalidate-tree.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170307205851.32578-1-chris@chris-wilson.co.ukReviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      42953b3c
    • D
      drm/i915: Fix up verify_encoder_state · 86b04268
      由 Daniel Vetter 提交于 
      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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301095226.30584-6-daniel.vetter@ffwll.ch
      86b04268
    • D
      drm/i915: use for_each_intel_connector_iter in intel_display.c · f9e905ca
      由 Daniel Vetter 提交于 
      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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301095226.30584-5-daniel.vetter@ffwll.ch
      f9e905ca
    • D
      drm/i915: Make intel_get_pipe_from_connector atomic · 51ec53da
      由 Daniel Vetter 提交于 
      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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301095226.30584-4-daniel.vetter@ffwll.ch
      51ec53da
    • D
      drm/i915: use drm_connector_list_iter in intel_opregion.c · f57c8421
      由 Daniel Vetter 提交于 
      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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301095226.30584-3-daniel.vetter@ffwll.ch
      f57c8421
    • D
      drm/i915: use drm_connector_list_iter in intel_hotplug.c · cc3ca4f3
      由 Daniel Vetter 提交于 
      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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301095226.30584-2-daniel.vetter@ffwll.ch
      cc3ca4f3
    • D
      drm/i915: Use drm_connector_list_iter in debugfs · 3f6a5e1e
      由 Daniel Vetter 提交于 
      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: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301095226.30584-1-daniel.vetter@ffwll.ch
      3f6a5e1e
    • C
      drm/i915: Check for an invalid seqno before __i915_gem_request_started · 5b5554c5
      由 Chris Wilson 提交于 
      __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: NMichał Winiarski <michal.winiarski@intel.com>
Fixes: 754c9fd5 ("drm/i915: Protect the request->global_seqno with the engine->timeline lock")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170308142238.22994-1-chris@chris-wilson.co.ukReviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      5b5554c5
    • C
      drm/i915: Purge i915_gem_object_is_dead() · f166244a
      由 Chris Wilson 提交于 
      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: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170308132629.7987-2-chris@chris-wilson.co.uk
      f166244a
    • C
      drm/i915: Avoiding recursing on ww_mutex inside shrinker · 03d1cac6
      由 Chris Wilson 提交于 
      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: NJan 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: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170308132629.7987-1-chris@chris-wilson.co.uk
      03d1cac6
  3. 08 3月, 2017 15 次提交
  5. 07 3月, 2017 11 次提交