1. 30 1月, 2016 2 次提交
  2. 27 1月, 2016 3 次提交
    • I
      drm/i915: Sanitize i915_gem_load() init and clean-up · d64aa096
      Imre Deak 提交于
      Factor out common clean-up code for the GEM load time init function.
      Also rename i915_gem_load() to i915_gem_load_init() to have a better
      match with its new clean-up function.
      
      No functional change.
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NDavid Weinehall <david.weinehall@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1453209992-25995-5-git-send-email-imre.deak@intel.com
      d64aa096
    • I
      drm/i915: Sanitize GEM shrinker init and clean-up · a8a40589
      Imre Deak 提交于
      Factor out the common GEM shrinker clean-up code and call the shrinker
      init function from the same function from where the corresponding
      shrinker clean-up function is called. Also add sanity checking to the
      shrinker and OOM registration calls.
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NDavid Weinehall <david.weinehall@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1453209992-25995-4-git-send-email-imre.deak@intel.com
      a8a40589
    • D
      Revert "drm/i915: Fix context/engine cleanup order" · 9a15a873
      Daniel Vetter 提交于
      This reverts commit 1803c035.
      
      It seems to blow up on module unload due to a use-after free hitting a
      BUG_ON with CONFIG_DEBUG_SG. Quoting from Tvrtko's mail:
      
      "I've decoded the instructions and it pointed to SG_MAGIC checking:
      
      488b8098010000  mov 0x198(%rax),%rax
      ba21436587      mov $0x87654321,%edx
      488b00          mov (%rax),%rax       *** CRASH
      
      "Grep showed 0x87654321 is SG_MAGIC, so likely candidate for this code
      pattern is:
      
      static inline struct page *sg_page(struct scatterlist *sg)
      {
          BUG_ON(sg->sg_magic != SG_MAGIC);
          BUG_ON(sg_is_chain(sg));
          return (struct page *)((sg)->page_link & ~0x3);
      }
      
      "Which would mean the offender is in intel_logical_ring_cleanup is most
      likely:
      
      ...
          if (ring->status_page.obj) {
              kunmap(sg_page(ring->status_page.obj->pages->sgl));
              ring->status_page.obj = NULL;
          }
      ...
      
      "I think that the i915_gem_context_fini will do a final unref on
      dev_priv->kernel_context and then the ring buff has a copy which is
      left dangling because:
      
          lrc_setup_hardware_status_page(ring,
              dev_priv->kernel_context->engine[ring->id].state);
      
      and:
      
      ring->status_page.obj = default_ctx_obj;
      
      "Where default_ctx_obj == dev_priv->kernel_context->engine[ring->id].state
      So indeed looks like the unload ordering is the trigger.  In fact it
      is almost the same fragility wrt/ kernel_context hidden dependency I
      expressed my worry about in an e-mail yesterday or so. It only shows
      if CONFIG_DEBUG_SG is set, otherwise it accesses freed memory and
      probably just survives."
      
      This causes serious trouble in our CI system since it took out all
      gen8+ machines. Not yet clear why this wasn't caught in pre-merge
      testing.
      
      Backtrace from CI, for posterity:
      
      [  163.737836] general protection fault: 0000 [#1] PREEMPT SMP
      [  163.737849] Modules linked in: ax88179_178a usbnet mii snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915(-) x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mei_me mei i2c_hid e1000e ptp pps_core [last unloaded: snd_hda_intel]
      [  163.737902] CPU: 0 PID: 5812 Comm: rmmod Tainted: G     U  W       4.5.0-rc1-gfxbench+ #1
      [  163.737911] Hardware name: System manufacturer System Product Name/Z170M-PLUS, BIOS 0505 11/16/2015
      [  163.737920] task: ffff8800bb99cf80 ti: ffff88022ff2c000 task.ti: ffff88022ff2c000
      [  163.737928] RIP: 0010:[<ffffffffa018f723>]  [<ffffffffa018f723>] intel_logical_ring_cleanup+0x83/0x100 [i915]
      [  163.737969] RSP: 0018:ffff88022ff2fd30  EFLAGS: 00010282
      [  163.737975] RAX: 6b6b6b6b6b6b6b6b RBX: ffff8800bb2f31b8 RCX: 0000000000000002
      [  163.737982] RDX: 0000000087654321 RSI: 000000000000000d RDI: ffff8800bb2f31f0
      [  163.737989] RBP: ffff88022ff2fd40 R08: 0000000000000000 R09: 0000000000000001
      [  163.737996] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800bb2f0000
      [  163.738003] R13: ffff8800bb2f8fc8 R14: ffff8800bb285668 R15: 000055af1ae55210
      [  163.738010] FS:  00007f187014b700(0000) GS:ffff88023bc00000(0000) knlGS:0000000000000000
      [  163.738021] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  163.738030] CR2: 0000558f84e4cbc8 CR3: 000000022cd55000 CR4: 00000000003406f0
      [  163.738039] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  163.738048] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  163.738057] Stack:
      [  163.738062]  ffff8800bb2f31b8 ffff8800bb2f0000 ffff88022ff2fd70 ffffffffa0180414
      [  163.738079]  ffff8800bb2f0000 ffff8800bb285668 ffff8800bb2856c8 ffffffffa0242460
      [  163.738094]  ffff88022ff2fd98 ffffffffa0202d30 ffff8800bb285668 ffff8800bb285668
      [  163.738109] Call Trace:
      [  163.738140]  [<ffffffffa0180414>] i915_gem_cleanup_engines+0x34/0x60 [i915]
      [  163.738185]  [<ffffffffa0202d30>] i915_driver_unload+0x150/0x270 [i915]
      [  163.738198]  [<ffffffff815100f4>] drm_dev_unregister+0x24/0xa0
      [  163.738208]  [<ffffffff815106ce>] drm_put_dev+0x1e/0x60
      [  163.738225]  [<ffffffffa01412a0>] i915_pci_remove+0x10/0x20 [i915]
      [  163.738237]  [<ffffffff8143d9b4>] pci_device_remove+0x34/0xb0
      [  163.738249]  [<ffffffff81533d15>] __device_release_driver+0x95/0x140
      [  163.738259]  [<ffffffff81533eb6>] driver_detach+0xb6/0xc0
      [  163.738268]  [<ffffffff81532de3>] bus_remove_driver+0x53/0xd0
      [  163.738278]  [<ffffffff815348d7>] driver_unregister+0x27/0x50
      [  163.738289]  [<ffffffff8143ca15>] pci_unregister_driver+0x25/0x70
      [  163.738299]  [<ffffffff81511de4>] drm_pci_exit+0x74/0x90
      [  163.738337]  [<ffffffffa02034a9>] i915_exit+0x20/0x1a5 [i915]
      [  163.738349]  [<ffffffff8110400f>] SyS_delete_module+0x18f/0x1f0
      [  163.738361]  [<ffffffff817b8a9b>] entry_SYSCALL_64_fastpath+0x16/0x73
      [  163.738370] Code: ff d0 48 89 df e8 de a1 fd ff 48 8d 7b 38 e8 25 ab fd ff 48 8b 83 90 00 00 00 48 85 c0 74 25 48 8b 80 98 01 00 00 ba 21 43 65 87 <48> 8b 00 48 39 10 75 3c f6 40 08 01 75 38 48 c7 83 90 00 00 00
      [  163.738459] RIP  [<ffffffffa018f723>] intel_logical_ring_cleanup+0x83/0x100 [i915]
      [  163.738498]  RSP <ffff88022ff2fd30>
      [  163.738507] ---[ end trace 68f69ce4740fa44f ]---
      
      Cc: Nick Hoath <nicholas.hoath@intel.com>
      Cc: Dave Gordon <david.s.gordon@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Tested-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      9a15a873
  3. 26 1月, 2016 1 次提交
    • N
      drm/i915: Fix context/engine cleanup order · 1803c035
      Nick Hoath 提交于
      Swap the order of context & engine cleanup, so that contexts are cleaned
      up first, and *then* engines. This is a more sensible order anyway, but
      in particular has become necessary since the 'intel_ring_initialized()
      must be simple and inline' patch, which now uses ring->dev as an
      'initialised' flag, so it can now be NULL after engine teardown. This
      in turn can cause a problem in the context code, which (used to) check
      the ring->dev->struct_mutex -- causing a fault if ring->dev was NULL.
      
      Also rename the cleanup function to reflect what it actually does
      (cleanup engines, not a ringbuffer), and fix an annoying whitespace issue.
      
      v2: Also make the fix in i915_load_modeset_init, not just in
          i915_driver_unload (Chris Wilson)
      v3: Had extra stuff in it.
      v4: Reverted extra stuff (so we're back to v2).
          Rebased and updated commentary above (Dave Gordon).
      Signed-off-by: NNick Hoath <nicholas.hoath@intel.com>
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1453405067-32890-3-git-send-email-david.s.gordon@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1803c035
  4. 25 1月, 2016 2 次提交
    • A
      drm/i915/gen9: Add framework to whitelist specific GPU registers · 33136b06
      Arun Siluvery 提交于
      Some of the HW registers are privileged and cannot be written to from
      non-privileged batch buffers coming from userspace unless they are added to
      the HW whitelist. This whitelist is maintained by HW and it is different from
      SW whitelist. Userspace need write access to them to implement preemption
      related WA.
      
      The reason for using this approach is, the register bits that control
      preemption granularity at the HW level are not context save/restored; so even
      if we set these bits always in kernel they are going to change once the
      context is switched out.  We can consider making them non-privileged by
      default but these registers also contain other chicken bits which should not
      be allowed to be modified.
      
      In the later revisions controlling bits are save/restored at context level but
      in the existing revisions these are exported via other debug registers and
      should be on the whitelist. This patch adds changes to provide HW with a list
      of registers to be whitelisted. HW checks this list during execution and
      provides access accordingly.
      
      HW imposes a limit on the number of registers on whitelist and it is
      per-engine.  At this point we are only enabling whitelist for RCS and we don't
      foresee any requirement for other engines.
      
      The registers to be whitelisted are added using generic workaround list
      mechanism, even these are only enablers for userspace workarounds. But by
      sharing this mechanism we get some test assets without additional cost (Mika).
      
      v2: rebase
      
      v3: parameterize RING_FORCE_TO_NONPRIV() as _MMIO() should be limited to
      i915_reg.h (Ville), drop inline for wa_ring_whitelist_reg (Mika).
      
      v4: improvements suggested by Chris Wilson.
      Clarify that this is HW whitelist and different from the one maintained in
      driver. This list is engine specific but it gets initialized along with other
      WA which is RCS specific thing, so make it clear that we are not doing any
      cross engine setup during initialization.
      Make HW whitelist count of each engine available in debugfs.
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1453412634-29238-2-git-send-email-arun.siluvery@linux.intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      33136b06
    • D
      drm/i915: Update DRIVER_DATE to 20160124 · 947eaebc
      Daniel Vetter 提交于
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      947eaebc
  5. 21 1月, 2016 3 次提交
  6. 20 1月, 2016 1 次提交
  7. 18 1月, 2016 2 次提交
  8. 14 1月, 2016 1 次提交
  9. 12 1月, 2016 1 次提交
  10. 11 1月, 2016 1 次提交
  11. 08 1月, 2016 2 次提交
  12. 07 1月, 2016 2 次提交
    • M
      drm/i915: Use plane state for primary plane updates. · a8d201af
      Maarten Lankhorst 提交于
      Pass in the atomic states to allow for proper updates.
      This removes uses of intel_crtc->config and direct access
      to plane->state.
      
      This breaks the last bit of kgdboc, but that appears to be dead code.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1452164052-21752-7-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      a8d201af
    • M
      drm/i915: Add two-stage ILK-style watermark programming (v10) · 396e33ae
      Matt Roper 提交于
      In addition to calculating final watermarks, let's also pre-calculate a
      set of intermediate watermark values at atomic check time.  These
      intermediate watermarks are a combination of the watermarks for the old
      state and the new state; they should satisfy the requirements of both
      states which means they can be programmed immediately when we commit the
      atomic state (without waiting for a vblank).  Once the vblank does
      happen, we can then re-program watermarks to the more optimal final
      value.
      
      v2: Significant rebasing/rewriting.
      
      v3:
       - Move 'need_postvbl_update' flag to CRTC state (Daniel)
       - Don't forget to check intermediate watermark values for validity
         (Maarten)
       - Don't due async watermark optimization; just do it at the end of the
         atomic transaction, after waiting for vblanks.  We do want it to be
         async eventually, but adding that now will cause more trouble for
         Maarten's in-progress work.  (Maarten)
       - Don't allocate space in crtc_state for intermediate watermarks on
         platforms that don't need it (gen9+).
       - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
         now that ilk_update_wm is gone.
      
      v4:
       - Add a wm_mutex to cover updates to intel_crtc->active and the
         need_postvbl_update flag.  Since we don't have async yet it isn't
         terribly important yet, but might as well add it now.
       - Change interface to program watermarks.  Platforms will now expose
         .initial_watermarks() and .optimize_watermarks() functions to do
         watermark programming.  These should lock wm_mutex, copy the
         appropriate state values into intel_crtc->active, and then call
         the internal program watermarks function.
      
      v5:
       - Skip intermediate watermark calculation/check during initial hardware
         readout since we don't trust the existing HW values (and don't have
         valid values of our own yet).
       - Don't try to call .optimize_watermarks() on platforms that don't have
         atomic watermarks yet.  (Maarten)
      
      v6:
       - Rebase
      
      v7:
       - Further rebase
      
      v8:
       - A few minor indentation and line length fixes
      
      v9:
       - Yet another rebase since Maarten's patches reworked a bunch of the
         code (wm_pre, wm_post, etc.) that this was previously based on.
      
      v10:
       - Move wm_mutex to dev_priv to protect against racing commits against
         disjoint CRTC sets. (Maarten)
       - Drop unnecessary clearing of cstate->wm.need_postvbl_update (Maarten)
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1452108870-24204-1-git-send-email-matthew.d.roper@intel.comSigned-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      396e33ae
  13. 06 1月, 2016 1 次提交
    • M
      drm/i915: Sanitize watermarks after hardware state readout (v4) · d93c0372
      Matt Roper 提交于
      Although we can do a good job of reading out hardware state, the
      graphics firmware may have programmed the watermarks in a creative way
      that doesn't match how i915 would have chosen to program them.  We
      shouldn't trust the firmware's watermark programming, but should rather
      re-calculate how we think WM's should be programmed and then shove those
      values into the hardware.
      
      We can do this pretty easily by creating a dummy top-level state,
      running it through the check process to calculate all the values, and
      then just programming the watermarks for each CRTC.
      
      v2:  Move watermark sanitization after our BIOS fb reconstruction; the
           watermark calculations that we do here need to look at pstate->fb,
           which isn't setup yet in intel_modeset_setup_hw_state(), even
           though we have an enabled & visible plane.
      
      v3:
       - Don't move 'active = optimal' watermark assignment; we just undo
         that change in the next patch anyway.  (Ville)
       - Move atomic helper locking fix to separate patch.  (Maarten)
      
      v4:
       - Grab connection_mutex before calling atomic helper to duplicate
         state.  The connector loop inside the helper will throw a WARN
         if we don't hold something to protect the connector list (and the
         helper itself doesn't try to lock the list).
       - Make failure to calculate watermarks for inherited state a WARN()
         since it probably indicates a serious problem in either our state
         readout code or our watermark code for this platform.
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      d93c0372
  14. 05 1月, 2016 1 次提交
  15. 22 12月, 2015 6 次提交
  16. 21 12月, 2015 1 次提交
  17. 19 12月, 2015 3 次提交
  18. 17 12月, 2015 6 次提交
  19. 16 12月, 2015 1 次提交