1. 07 9月, 2017 6 次提交
  2. 04 9月, 2017 1 次提交
  3. 01 9月, 2017 4 次提交
  4. 29 8月, 2017 1 次提交
    • C
      drm/i915: Recreate vmapping even when the object is pinned · a575c676
      Chris Wilson 提交于
      Sometimes we know we are the only user of the bo, but since we take a
      protective pin_pages early on, an attempt to change the vmap on the
      object is denied because it is busy. i915_gem_object_pin_map() cannot
      tell from our single pin_count if the operation is safe. Instead we must
      pass that information down from the caller in the manner of
      I915_MAP_OVERRIDE.
      
      This issue has existed from the introduction of the mapping, but was
      never noticed as the only place where this conflict might happen is for
      cached kernel buffers (such as allocated by i915_gem_batch_pool_get()).
      Until recently there was only a single user (the cmdparser) so no
      conflicts ever occurred. However, we now use it to allocate batches for
      different operations (using MAP_WC on !llc for writes) in addition to the
      existing shadow batch (using MAP_WB for reads).
      
      We could either keep both mappings cached, or use a different write
      mechanism if we detect a MAP_WB already exists (i.e. clflush
      afterwards), but as we haven't seen this issue in the wild (it requires
      hitting the GPU reloc path in addition to the cmdparser) for simplicity
      just allow the mappings to be recreated.
      
      v2: Include the i915_MAP_OVERRIDE bit in the enum so the compiler knows
      about all the valid values.
      
      Fixes: 7dd4f672 ("drm/i915: Async GPU relocation processing")
      Testcase: igt/gem_lut_handle # byt, completely by accident
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170828104631.8606-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      a575c676
  5. 26 8月, 2017 1 次提交
  6. 25 8月, 2017 1 次提交
  7. 23 8月, 2017 1 次提交
  8. 19 8月, 2017 1 次提交
  9. 18 8月, 2017 2 次提交
  10. 17 8月, 2017 1 次提交
  11. 15 8月, 2017 3 次提交
    • C
      drm/i915: Handle full s64 precision for wait-ioctl · b8050148
      Chris Wilson 提交于
      The wait-ioctl is optionally supplied a timeout with nanosecond
      precision in a s64 field. We use nsecs_to_jiffies64() to convert that
      into the jiffies consumed by the scheduler, but internally
      nsecs_to_jiffies64() does not guard against overflow (as it's purpose is
      for use by the scheduler and not drivers!). So we must guard against the
      overflow ourselves, and in the process note that we may then return
      much earlier than the timeout selected by the user, so don't report
      ETIME unless we do hit the timeout. (Woe betold us though if the user
      waits for a year (32bit) and the request is still not complete!)
      
      v2: Refine overflow detection (to not include an overffow itself)
      Reported-by: NJason Ekstrand <jason.ekstrand@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170811105731.9482-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      b8050148
    • C
      drm/i915: Split obj->cache_coherent to track r/w · b8f55be6
      Chris Wilson 提交于
      Another month, another story in the cache coherency saga. This time, we
      come to the realisation that i915_gem_object_is_coherent() has been
      reporting whether we can read from the target without requiring a cache
      invalidate; but we were using it in places for testing whether we could
      write into the object without requiring a cache flush. So split the
      tracking into two, one to decide before reads, one after writes.
      
      See commit e27ab73d ("drm/i915: Mark CPU cache as dirty on every
      transition for CPU writes") for the previous entry in this saga.
      
      v2: Be verbose
      v3: Remove unused function (i915_gem_object_is_coherent)
      v4: Fix inverted coherency check prior to execbuf (from v2)
      v5: Add comment for nasty code where we are optimising on gcc's behalf.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101109
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101555
      Testcase: igt/kms_mmap_write_crc
      Testcase: igt/kms_pwrite_crc
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Dongwon Kim <dongwon.kim@intel.com>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Tested-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170811111116.10373-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      b8f55be6
    • T
      drm/i915: Enable guest i915 full ppgtt functionality · 8a4ab66f
      Tina Zhang 提交于
      Enable the guest i915 full ppgtt functionality when host can provide this
      capability. vgt_caps is introduced to guest i915 driver to get the vgpu
      capabilities from the device model. VGT_CPAS_FULL_PPGTT is one of the
      capabilities type to let guest i915 dirver know that the guest i915 full
      ppgtt is supported by device model.
      
      Notice that the minor version of pvinfo isn't bumped because of this
      vgt_caps introduction, due to older guest would be broken by simply
      increasing the pvinfo version. Although the pvinfo minor version doesn't
      increase, the compatibility won't be blocked. The compatibility is ensured
      by checking the value of caps field in pvinfo. Zero means no full ppgtt
      support and BIT(2) means this feature is provided.
      
      Changes since v1:
      - Use u32 instead of uint32_t (Joonas)
      - Move VGT_CAPS_FULL_PPGTT introduction to this patch and use #define
        instead of enum (Joonas)
      - Rewrite the vgpu full ppgtt capability checking logic. (Joonas)
      - Some coding style refine. (Joonas)
      
      Changes since v2:
      - Divide the whole patch set into two separate patch series, with one
        patch in i915 side to check guest i915 full ppgtt capability and enable
        it when this capability is supported by the device model, and the other
        one in gvt side which fixs the blocking issue and enables the device
        model to provide the capability to guest. And this patch focuses on guest
        i915 side. (Joonas)
      - Change the title from "introduce vgt_caps to pvinfo" to
        "Enable guest i915 full ppgtt functionality". (Tina)
      
      Change since v3:
      - Add some comments about pvinfo caps and version. (Joonas)
      
      Change since v4:
      - Tested by Tina Zhang.
      
      Change since v5:
      - Add limitation about supporting 32bit full ppgtt.
      
      Change since v6:
      - Change the fallback to 48bit full ppgtt if i915.ppgtt_enable=2. (Zhenyu)
      
      Change in v9:
      - Remove the fixme comment due to no plan for 32bit full ppgtt
        support. (Zhenyu)
      - Reorder the patch-set to fix compiling issue with git-bisect. (Zhenyu)
      - Add print log when forcing guest 48bit full ppgtt. (Zhenyu)
      
      v10:
      - Update against Joonas's has_full_ppgtt and has_full_48bit_ppgtt disconnect
        change. (Zhenyu)
      
      Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> # in v2
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tina Zhang <tina.zhang@intel.com>
      Signed-off-by: NTina Zhang <tina.zhang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      8a4ab66f
  12. 14 8月, 2017 1 次提交
    • D
      drm/i915: More surgically unbreak the modeset vs reset deadlock · 9db529aa
      Daniel Vetter 提交于
      There's no reason to entirely wedge the gpu, for the minimal deadlock
      bugfix we only need to unbreak/decouple the atomic commit from the gpu
      reset. The simplest way to fix that is by replacing the
      unconditional fence wait a the top of commit_tail by a wait which
      completes either when the fences are done (normal case, or when a
      reset doesn't need to touch the display state). Or when the gpu reset
      needs to force-unblock all pending modeset states.
      
      The lesser source of deadlocks is when we try to pin a new framebuffer
      and run into a stall. There's a bunch of places this can happen, like
      eviction, changing the caching mode, acquiring a fence on older
      platforms. And we can't just break the depency loop and keep going,
      the only way would be to break out and restart. But the problem with
      that approach is that we must stall for the reset to complete before
      we grab any locks, and with the atomic infrastructure that's a bit
      tricky. The only place is the ioctl code, and we don't want to insert
      code into e.g. the BUSY ioctl. Hence for that problem just create a
      critical section, and if any code is in there, wedge the GPU. For the
      steady-state this should never be a problem.
      
      Note that in both cases TDR itself keeps working, so from a userspace
      pov this trickery isn't observable. Users themselvs might spot a short
      glitch while the rendering is catching up again, but that's still
      better than pre-TDR where we've thrown away all the rendering,
      including innocent batches. Also, this fixes the regression TDR
      introduced of making gpu resets deadlock-prone when we do need to
      touch the display.
      
      One thing I noticed is that gpu_error.flags seems to use both our own
      wait-queue in gpu_error.wait_queue, and the generic wait_on_bit
      facilities. Not entirely sure why this inconsistency exists, I just
      picked one style.
      
      A possible future avenue could be to insert the gpu reset in-between
      ongoing modeset changes, which would avoid the momentary glitch. But
      that's a lot more work to implement in the atomic commit machinery,
      and given that we only need this for pre-g4x hw, of questionable
      utility just for the sake of polishing gpu reset even more on those
      old boxes. It might be useful for other features though.
      
      v2: Rebase onto 4.13 with a s/wait_queue_t/struct wait_queue_entry/.
      
      v3: Really emabarrassing fixup, I checked the wrong bit and broke the
      unbreak/wakeup logic.
      
      v4: Also handle deadlocks in pin_to_display.
      
      v5: Review from Michel:
      - Fixup the BUILD_BUG_ON
      - Don't forget about the overlay
      
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v2)
      Cc: Michel Thierry <michel.thierry@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170808080828.23650-3-daniel.vetter@ffwll.chReviewed-by: NMichel Thierry <michel.thierry@intel.com>
      9db529aa
  13. 12 8月, 2017 2 次提交
  14. 04 8月, 2017 3 次提交
  15. 31 7月, 2017 1 次提交
  16. 27 7月, 2017 7 次提交
  17. 21 7月, 2017 1 次提交
  18. 20 7月, 2017 1 次提交
  19. 19 7月, 2017 1 次提交
  20. 17 7月, 2017 1 次提交