1. 12 10月, 2017 1 次提交
    • C
      drm/i915/userptr: Drop struct_mutex before cleanup · 7c781423
      Chris Wilson 提交于
      Purely to silence lockdep, as we know that no bo can exist at this time
      and so the inversion is impossible. Nevertheless, lockdep currently
      warns on unload:
      
      [  137.522565] WARNING: possible circular locking dependency detected
      [  137.522568] 4.14.0-rc4-CI-CI_DRM_3209+ #1 Tainted: G     U
      [  137.522570] ------------------------------------------------------
      [  137.522572] drv_module_relo/1532 is trying to acquire lock:
      [  137.522574]  ("i915-userptr-acquire"){+.+.}, at: [<ffffffff8109a831>] flush_workqueue+0x91/0x540
      [  137.522581]
                     but task is already holding lock:
      [  137.522583]  (&dev->struct_mutex){+.+.}, at: [<ffffffffa014fb3f>] i915_gem_fini+0x3f/0xc0 [i915]
      [  137.522605]
                     which lock already depends on the new lock.
      
      [  137.522608]
                     the existing dependency chain (in reverse order) is:
      [  137.522611]
                     -> #3 (&dev->struct_mutex){+.+.}:
      [  137.522615]        __lock_acquire+0x1420/0x15e0
      [  137.522618]        lock_acquire+0xb0/0x200
      [  137.522621]        __mutex_lock+0x86/0x9b0
      [  137.522623]        mutex_lock_interruptible_nested+0x1b/0x20
      [  137.522640]        i915_mutex_lock_interruptible+0x51/0x130 [i915]
      [  137.522657]        i915_gem_fault+0x20b/0x720 [i915]
      [  137.522660]        __do_fault+0x1e/0x80
      [  137.522662]        __handle_mm_fault+0xa08/0xed0
      [  137.522664]        handle_mm_fault+0x156/0x300
      [  137.522666]        __do_page_fault+0x2c5/0x570
      [  137.522668]        do_page_fault+0x28/0x250
      [  137.522671]        page_fault+0x22/0x30
      [  137.522672]
                     -> #2 (&mm->mmap_sem){++++}:
      [  137.522677]        __lock_acquire+0x1420/0x15e0
      [  137.522679]        lock_acquire+0xb0/0x200
      [  137.522682]        down_read+0x3e/0x70
      [  137.522699]        __i915_gem_userptr_get_pages_worker+0x141/0x240 [i915]
      [  137.522701]        process_one_work+0x233/0x660
      [  137.522704]        worker_thread+0x4e/0x3b0
      [  137.522706]        kthread+0x152/0x190
      [  137.522708]        ret_from_fork+0x27/0x40
      [  137.522710]
                     -> #1 ((&work->work)){+.+.}:
      [  137.522714]        __lock_acquire+0x1420/0x15e0
      [  137.522717]        lock_acquire+0xb0/0x200
      [  137.522719]        process_one_work+0x206/0x660
      [  137.522721]        worker_thread+0x4e/0x3b0
      [  137.522723]        kthread+0x152/0x190
      [  137.522725]        ret_from_fork+0x27/0x40
      [  137.522727]
                     -> #0 ("i915-userptr-acquire"){+.+.}:
      [  137.522731]        check_prev_add+0x430/0x840
      [  137.522733]        __lock_acquire+0x1420/0x15e0
      [  137.522735]        lock_acquire+0xb0/0x200
      [  137.522738]        flush_workqueue+0xb4/0x540
      [  137.522740]        drain_workqueue+0xd4/0x1b0
      [  137.522742]        destroy_workqueue+0x1c/0x200
      [  137.522758]        i915_gem_cleanup_userptr+0x15/0x20 [i915]
      [  137.522770]        i915_gem_fini+0x5f/0xc0 [i915]
      [  137.522782]        i915_driver_unload+0x122/0x180 [i915]
      [  137.522794]        i915_pci_remove+0x19/0x30 [i915]
      [  137.522797]        pci_device_remove+0x39/0xb0
      [  137.522800]        device_release_driver_internal+0x15d/0x220
      [  137.522803]        driver_detach+0x40/0x80
      [  137.522805]        bus_remove_driver+0x58/0xd0
      [  137.522807]        driver_unregister+0x2c/0x40
      [  137.522809]        pci_unregister_driver+0x36/0xb0
      [  137.522828]        i915_exit+0x1a/0x8b [i915]
      [  137.522831]        SyS_delete_module+0x18c/0x1e0
      [  137.522834]        entry_SYSCALL_64_fastpath+0x1c/0xb1
      [  137.522835]
                     other info that might help us debug this:
      
      [  137.522838] Chain exists of:
                       "i915-userptr-acquire" --> &mm->mmap_sem --> &dev->struct_mutex
      
      [  137.522844]  Possible unsafe locking scenario:
      
      [  137.522846]        CPU0                    CPU1
      [  137.522848]        ----                    ----
      [  137.522850]   lock(&dev->struct_mutex);
      [  137.522852]                                lock(&mm->mmap_sem);
      [  137.522854]                                lock(&dev->struct_mutex);
      [  137.522857]   lock("i915-userptr-acquire");
      [  137.522859]
                      *** DEADLOCK ***
      
      [  137.522862] 3 locks held by drv_module_relo/1532:
      [  137.522864]  #0:  (&dev->mutex){....}, at: [<ffffffff8161d47b>] device_release_driver_internal+0x2b/0x220
      [  137.522869]  #1:  (&dev->mutex){....}, at: [<ffffffff8161d489>] device_release_driver_internal+0x39/0x220
      [  137.522873]  #2:  (&dev->struct_mutex){+.+.}, at: [<ffffffffa014fb3f>] i915_gem_fini+0x3f/0xc0 [i915]
      [  137.522888]
                     stack backtrace:
      [  137.522891] CPU: 0 PID: 1532 Comm: drv_module_relo Tainted: G     U          4.14.0-rc4-CI-CI_DRM_3209+ #1
      [  137.522894] Hardware name:                  /NUC7i5BNB, BIOS BNKBL357.86A.0048.2017.0704.1415 07/04/2017
      [  137.522897] Call Trace:
      [  137.522900]  dump_stack+0x68/0x9f
      [  137.522902]  print_circular_bug+0x235/0x3c0
      [  137.522905]  ? lockdep_init_map_crosslock+0x20/0x20
      [  137.522908]  check_prev_add+0x430/0x840
      [  137.522919]  ? i915_gem_fini+0x5f/0xc0 [i915]
      [  137.522922]  ? __kernel_text_address+0x12/0x40
      [  137.522925]  ? __save_stack_trace+0x66/0xd0
      [  137.522928]  __lock_acquire+0x1420/0x15e0
      [  137.522930]  ? __lock_acquire+0x1420/0x15e0
      [  137.522933]  ? lockdep_init_map_crosslock+0x20/0x20
      [  137.522936]  ? __this_cpu_preempt_check+0x13/0x20
      [  137.522938]  lock_acquire+0xb0/0x200
      [  137.522940]  ? flush_workqueue+0x91/0x540
      [  137.522943]  flush_workqueue+0xb4/0x540
      [  137.522945]  ? flush_workqueue+0x91/0x540
      [  137.522948]  ? __mutex_unlock_slowpath+0x43/0x2c0
      [  137.522951]  ? trace_hardirqs_on_caller+0xe3/0x1b0
      [  137.522954]  drain_workqueue+0xd4/0x1b0
      [  137.522956]  ? drain_workqueue+0xd4/0x1b0
      [  137.522958]  destroy_workqueue+0x1c/0x200
      [  137.522975]  i915_gem_cleanup_userptr+0x15/0x20 [i915]
      [  137.522987]  i915_gem_fini+0x5f/0xc0 [i915]
      [  137.523000]  i915_driver_unload+0x122/0x180 [i915]
      [  137.523015]  i915_pci_remove+0x19/0x30 [i915]
      [  137.523018]  pci_device_remove+0x39/0xb0
      [  137.523021]  device_release_driver_internal+0x15d/0x220
      [  137.523023]  driver_detach+0x40/0x80
      [  137.523026]  bus_remove_driver+0x58/0xd0
      [  137.523028]  driver_unregister+0x2c/0x40
      [  137.523030]  pci_unregister_driver+0x36/0xb0
      [  137.523049]  i915_exit+0x1a/0x8b [i915]
      [  137.523052]  SyS_delete_module+0x18c/0x1e0
      [  137.523055]  entry_SYSCALL_64_fastpath+0x1c/0xb1
      [  137.523057] RIP: 0033:0x7f7bd0609287
      [  137.523059] RSP: 002b:00007ffef694bc18 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
      [  137.523062] RAX: ffffffffffffffda RBX: ffffffff81493f33 RCX: 00007f7bd0609287
      [  137.523065] RDX: 0000000000000001 RSI: 0000000000000800 RDI: 0000564f999f9fc8
      [  137.523067] RBP: ffffc90005c4ff88 R08: 0000000000000000 R09: 0000000000000080
      [  137.523069] R10: 00007f7bd20ef8c0 R11: 0000000000000246 R12: 0000000000000000
      [  137.523072] R13: 00007ffef694be00 R14: 0000000000000000 R15: 0000000000000000
      [  137.523075]  ? __this_cpu_preempt_check+0x13/0x20
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171011141857.14161-1-chris@chris-wilson.co.ukReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7c781423
  2. 11 10月, 2017 4 次提交
  3. 05 10月, 2017 4 次提交
    • C
      drm/i915/scheduler: Support user-defined priorities · ac14fbd4
      Chris Wilson 提交于
      Use a priority stored in the context as the initial value when
      submitting a request. This allows us to change the default priority on a
      per-context basis, allowing different contexts to be favoured with GPU
      time at the expense of lower importance work. The user can adjust the
      context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
      values being higher priority (they will be serviced earlier, after their
      dependencies have been resolved). Any prerequisite work for an execbuf
      will have its priority raised to match the new request as required.
      
      Normal users can specify any value in the range of -1023 to 0 [default],
      i.e. they can reduce the priority of their workloads (and temporarily
      boost it back to normal if so desired).
      
      Privileged users can specify any value in the range of -1023 to 1023,
      [default is 0], i.e. they can raise their priority above all overs and
      so potentially starve the system.
      
      Note that the existing schedulers are not fair, nor load balancing, the
      execution is strictly by priority on a first-come, first-served basis,
      and the driver may choose to boost some requests above the range
      available to users.
      
      This priority was originally based around nice(2), but evolved to allow
      clients to adjust their priority within a small range, and allow for a
      privileged high priority range.
      
      For example, this can be used to implement EGL_IMG_context_priority
      https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt
      
      	EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
              the context to be created. This attribute is a hint, as an
              implementation may not support multiple contexts at some
              priority levels and system policy may limit access to high
              priority contexts to appropriate system privilege level. The
              default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
              EGL_CONTEXT_PRIORITY_MEDIUM_IMG."
      
      so we can map
      
      	PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
      	PRIORITY_MED -> 0 [default]
      	PRIORITY_LOW -> -1023
      
      They also map onto the priorities used by VkQueue (and a VkQueue is
      essentially a timeline, our i915_gem_context under full-ppgtt).
      
      v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/
      v3: Report min/max user priorities as defines in the uapi, and rebase
      internal priorities on the exposed values.
      
      Testcase: igt/gem_exec_schedule
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-9-chris@chris-wilson.co.uk
      ac14fbd4
    • C
      drm/i915/execlists: Preemption! · beecec90
      Chris Wilson 提交于
      When we write to ELSP, it triggers a context preemption at the earliest
      arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other
      operations and the explicit MI_ARB_CHECK). If this is to the same
      context, it triggers a LITE_RESTORE where the RING_TAIL is merely
      updated (used currently to chain requests from the same context
      together, avoiding bubbles). However, if it is to a different context, a
      full context-switch is performed and it will start to execute the new
      context saving the image of the old for later execution.
      
      Previously we avoided preemption by only submitting a new context when
      the old was idle. But now we wish embrace it, and if the new request has
      a higher priority than the currently executing request, we write to the
      ELSP regardless, thus triggering preemption, but we tell the GPU to
      switch to our special preemption context (not the target). In the
      context-switch interrupt handler, we know that the previous contexts
      have finished execution and so can unwind all the incomplete requests
      and compute the new highest priority request to execute.
      
      It would be feasible to avoid the switch-to-idle intermediate by
      programming the ELSP with the target context. The difficulty is in
      tracking which request that should be whilst maintaining the dependency
      change, the error comes in with coalesced requests. As we only track the
      most recent request and its priority, we may run into the issue of being
      tricked in preempting a high priority request that was followed by a
      low priority request from the same context (e.g. for PI); worse still
      that earlier request may be our own dependency and the order then broken
      by preemption. By injecting the switch-to-idle and then recomputing the
      priority queue, we avoid the issue with tracking in-flight coalesced
      requests. Having tried the preempt-to-busy approach, and failed to find
      a way around the coalesced priority issue, Michal's original proposal to
      inject an idle context (based on handling GuC preemption) succeeds.
      
      The current heuristic for deciding when to preempt are only if the new
      request is of higher priority, and has the privileged priority of
      greater than 0. Note that the scheduler remains unfair!
      
      v2: Disable for gen8 (bdw/bsw) as we need additional w/a for GPGPU.
      Since, the feature is now conditional and not always available when we
      have a scheduler, make it known via the HAS_SCHEDULER GETPARAM (now a
      capability mask).
      v3: Stylistic tweaks.
      v4: Appease Joonas with a snippet of kerneldoc, only to fuel to fire of
      the preempt vs preempting debate.
      Suggested-by: NMichal Winiarski <michal.winiarski@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michal Winiarski <michal.winiarski@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Ben Widawsky <benjamin.widawsky@intel.com>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-8-chris@chris-wilson.co.uk
      beecec90
    • C
      drm/i915: Expand I915_PARAM_HAS_SCHEDULER into a capability bitmask · bf64e0b0
      Chris Wilson 提交于
      In the next few patches, we wish to enable different features for the
      scheduler, some which may subtlety change ABI (e.g. allow requests to be
      reordered under different circumstances). So we need to make sure
      userspace is cognizant of the changes (if they care), by which we employ
      the usual method of a GETPARAM. We already have an
      I915_PARAM_HAS_SCHEDULER (which notes the existing ability to reorder
      requests to avoid bubbles), and now we wish to extend that to be a
      bitmask to describe the different capabilities implemented.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-7-chris@chris-wilson.co.uk
      bf64e0b0
    • S
      drm/i915/uc: Create intel_uc_init_mmio · 1fc556fa
      Sagar Arun Kamble 提交于
      This patch adds new function intel_uc_init_mmio which will initialize
      MMIO access related variables prior to uc load/init.
      
      v2: Removed unnecessary export of guc_send_init_regs. Created
      intel_uc_init_mmio that currently wraps guc_init_send_regs. (Michal)
      
      v3 (Michal): add kerneldoc (Joonas)
      Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171004153327.32608-4-michal.wajdeczko@intel.com
      1fc556fa
  4. 02 10月, 2017 1 次提交
  5. 28 9月, 2017 1 次提交
  6. 22 9月, 2017 1 次提交
  7. 07 9月, 2017 2 次提交
  8. 06 9月, 2017 1 次提交
  9. 23 8月, 2017 1 次提交
    • R
      drm/i915/cfl: Coffee Lake works on Kaby Lake PCH. · eb371933
      Rodrigo Vivi 提交于
      Coffee Lake CPU on Kaby Lake PCH is possible.
      It does exist, and it does work.
      
      The only missed case was this warning here noticed
      by Wendy who could get one system with this configuration
      and reported the issue for us:
      
      Hardware Configuration
      Board ID KBL S DDR4 UDIMM EV CRB
      Processor    Intel® Processor code named Coffee Lake S, (6+2), 6 cores 12 threads, GT2, A0 (Internal) (QNJ4)
      
      [ 3.220585] WARNING: CPU: 10 PID: 206 at drivers/gpu/drm/i915/i915_drv.c:340 i915_driver_load+0x1210/0x1660 [i915]
      [ 3.221312] Modules linked in: hid_generic usbhid i915 i2c_algo_bit drm_kms_helper e1000e syscopyarea sysfillrect sysimgblt nvme fb_sys_fops ptp ahci i2c_hid drm pps_core nvme_core libahci wmi hid video
      [ 3.222050] CPU: 10 PID: 206 Comm: systemd-udevd Not tainted 4.13.0-rc5-intel-next+ #1
      [ 3.222706] Hardware name: Intel Corporation Kabylake Client platform/KBL S DDR4 UDIMM EV CRB, BIOS KBLSE2R1.R00.X089.P00.1705051000 05/05/2017
      
      Cc: Wendy Wang <wendy.wang@intel.com>
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170821235056.9015-1-rodrigo.vivi@intel.com
      eb371933
  10. 15 8月, 2017 1 次提交
  11. 08 8月, 2017 1 次提交
  12. 04 8月, 2017 2 次提交
  13. 27 7月, 2017 4 次提交
  14. 21 7月, 2017 1 次提交
  15. 19 7月, 2017 3 次提交
  16. 06 7月, 2017 1 次提交
  17. 03 7月, 2017 1 次提交
    • V
      drm/i915: Disable MSI for all pre-gen5 · ce3f7163
      Ville Syrjälä 提交于
      We have pretty clear evidence that MSIs are getting lost on g4x and
      somehow the interrupt logic doesn't seem to recover from that state
      even if we try hard to clear the IIR.
      
      Disabling IER around the normal IIR clearing in the irq handler isn't
      sufficient to avoid this, so the problem really seems to be further
      up the interrupt chain. This should guarantee that there's always
      an edge if any IIR bits are set after the interrupt handler is done,
      which should normally guarantee that the CPU interrupt is generated.
      That approach seems to work perfectly on VLV/CHV, but apparently
      not on g4x.
      
      MSI is documented to be broken on 965gm at least. The chipset spec
      says MSI is defeatured because interrupts can be delayed or lost,
      which fits well with what we're seeing on g4x. Previously we've
      already disabled GMBUS interrupts on g4x because somehow GMBUS
      manages to raise legacy interrupts even when MSI is enabled.
      
      Since there's such widespread MSI breakahge all over in the pre-gen5
      land let's just give up on MSI on these platforms.
      
      Seqno reporting might be negatively affected by this since the legcy
      interrupts aren't guaranteed to be ordered with the seqno writes,
      whereas MSI interrupts may be? But an occasioanlly missed seqno
      seems like a small price to pay for generally working interrupts.
      
      Cc: stable@vger.kernel.org
      Cc: Diego Viola <diego.viola@gmail.com>
      Tested-by: NDiego Viola <diego.viola@gmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170626203051.28480-1-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      (cherry picked from commit e38c2da0)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      ce3f7163
  18. 27 6月, 2017 1 次提交
    • V
      drm/i915: Disable MSI for all pre-gen5 · e38c2da0
      Ville Syrjälä 提交于
      We have pretty clear evidence that MSIs are getting lost on g4x and
      somehow the interrupt logic doesn't seem to recover from that state
      even if we try hard to clear the IIR.
      
      Disabling IER around the normal IIR clearing in the irq handler isn't
      sufficient to avoid this, so the problem really seems to be further
      up the interrupt chain. This should guarantee that there's always
      an edge if any IIR bits are set after the interrupt handler is done,
      which should normally guarantee that the CPU interrupt is generated.
      That approach seems to work perfectly on VLV/CHV, but apparently
      not on g4x.
      
      MSI is documented to be broken on 965gm at least. The chipset spec
      says MSI is defeatured because interrupts can be delayed or lost,
      which fits well with what we're seeing on g4x. Previously we've
      already disabled GMBUS interrupts on g4x because somehow GMBUS
      manages to raise legacy interrupts even when MSI is enabled.
      
      Since there's such widespread MSI breakahge all over in the pre-gen5
      land let's just give up on MSI on these platforms.
      
      Seqno reporting might be negatively affected by this since the legcy
      interrupts aren't guaranteed to be ordered with the seqno writes,
      whereas MSI interrupts may be? But an occasioanlly missed seqno
      seems like a small price to pay for generally working interrupts.
      
      Cc: stable@vger.kernel.org
      Cc: Diego Viola <diego.viola@gmail.com>
      Tested-by: NDiego Viola <diego.viola@gmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170626203051.28480-1-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e38c2da0
  19. 26 6月, 2017 1 次提交
  20. 23 6月, 2017 4 次提交
  21. 21 6月, 2017 4 次提交