1. 10 1月, 2017 3 次提交
  2. 09 1月, 2017 1 次提交
  3. 07 1月, 2017 2 次提交
  4. 06 1月, 2017 1 次提交
  5. 05 1月, 2017 2 次提交
  6. 02 1月, 2017 1 次提交
  7. 31 12月, 2016 4 次提交
  8. 26 12月, 2016 1 次提交
  9. 24 12月, 2016 2 次提交
  10. 22 12月, 2016 1 次提交
  11. 20 12月, 2016 2 次提交
    • I
      drm/i915/gen9: Fix PCODE polling during CDCLK change notification · 2c7d0602
      Imre Deak 提交于
      commit 848496e5
      Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Date:   Wed Jul 13 16:32:03 2016 +0300
      
          drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
      
      increased the timeout to match the spec, but we still see a timeout on
      at least one SKL. A CDCLK change request following the failed one will
      succeed nevertheless.
      
      I could reproduce this problem easily by running kms_pipe_crc_basic in a
      loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
      the worst case - when the pre-emption happened right after calculating
      timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
      once which failed and so _wait_for() timed out. As opposed to this the
      spec says to keep retrying the request for at most a 3ms period.
      
      To fix this send the first request explicitly to guarantee that there is
      3ms between the first and last request. Though this matches the spec, I
      noticed that in rare cases this can still time out if we sent only a few
      requests (in the worst case 2) _and_ PCODE is busy for some reason even
      after a previous request and a 3ms delay. To work around this retry the
      polling with pre-emption disabled to maximize the number of requests.
      Also increase the timeout to 10ms to account for interrupts that could
      reduce the number of requests. With this change I couldn't trigger
      the problem.
      
      v2:
      - Use 1ms poll period instead of 10us. (Chris)
      v3:
      - Poll with pre-emption disabled to increase the number of request
        attempts. (Ville, Chris)
      - Factor out a helper to poll, it's also needed by the next patch.
      v4:
      - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
        reply is generic. (Ville)
      v5:
      - List the request specific timeout values as code comment. (Ville)
      v6:
      - Try the poll first with preemption enabled.
      - Add code comment about first request being queued by PCODE. (Art)
      - Add timeout_base_ms argument. (Ville)
      v7:
      - Clarify code comment about first queued request. (Chris)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Art Runyan <arthur.j.runyan@intel.com>
      Cc: <stable@vger.kernel.org> # v4.2- : 3b2c1710 : drm/i915: Wait up to 3ms
      Cc: <stable@vger.kernel.org> # v4.2-
      Fixes: 5d96d8af ("drm/i915/skl: Deinit/init the display at suspend/resume")
      Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
      Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-1-git-send-email-imre.deak@intel.com
      (cherry picked from commit a0b8a1fe)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      2c7d0602
    • R
      drm/i915: Expand is_lp backwards to gen8_lp and gen7_lp. · 8727dc09
      Rodrigo Vivi 提交于
      Valleyview/Baytrail (gen7_lp) and Cherryview/Braswell (gen8_lp)
      are both Atom platforms like Broxton/Apollolake and Geminilake.
      
      So let's expand this is_lp back to these platforms and
      create the IS_LP(dev_priv) so we can start simplifying a bit
      our if/else for platform lists.
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1482096988-400-1-git-send-email-rodrigo.vivi@intel.com
      8727dc09
  12. 19 12月, 2016 3 次提交
  13. 17 12月, 2016 1 次提交
  14. 15 12月, 2016 1 次提交
  15. 12 12月, 2016 1 次提交
  16. 09 12月, 2016 2 次提交
    • R
      drm/i915/perf: More documentation hooked to i915.rst · 16d98b31
      Robert Bragg 提交于
      This adds a 'Perf' section to i915.rst with the following sub sections:
      - Overview
      - Comparison with Core Perf
      - i915 Driver Entry Points
      - i915 Perf Stream
      - i915 Perf Observation Architecture Stream
      - All i915 Perf Internals
      
      v2:
          section headers in i915.rst (Daniel Vetter)
          missing symbol docs + other fixups (Matthew Auld)
      Signed-off-by: NRobert Bragg <robert@sixbynine.org>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161207214033.3581-1-robert@sixbynine.org
      16d98b31
    • I
      drm/i915/gen9: Fix PCODE polling during CDCLK change notification · a0b8a1fe
      Imre Deak 提交于
      commit 848496e5
      Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Date:   Wed Jul 13 16:32:03 2016 +0300
      
          drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
      
      increased the timeout to match the spec, but we still see a timeout on
      at least one SKL. A CDCLK change request following the failed one will
      succeed nevertheless.
      
      I could reproduce this problem easily by running kms_pipe_crc_basic in a
      loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
      the worst case - when the pre-emption happened right after calculating
      timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
      once which failed and so _wait_for() timed out. As opposed to this the
      spec says to keep retrying the request for at most a 3ms period.
      
      To fix this send the first request explicitly to guarantee that there is
      3ms between the first and last request. Though this matches the spec, I
      noticed that in rare cases this can still time out if we sent only a few
      requests (in the worst case 2) _and_ PCODE is busy for some reason even
      after a previous request and a 3ms delay. To work around this retry the
      polling with pre-emption disabled to maximize the number of requests.
      Also increase the timeout to 10ms to account for interrupts that could
      reduce the number of requests. With this change I couldn't trigger
      the problem.
      
      v2:
      - Use 1ms poll period instead of 10us. (Chris)
      v3:
      - Poll with pre-emption disabled to increase the number of request
        attempts. (Ville, Chris)
      - Factor out a helper to poll, it's also needed by the next patch.
      v4:
      - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
        reply is generic. (Ville)
      v5:
      - List the request specific timeout values as code comment. (Ville)
      v6:
      - Try the poll first with preemption enabled.
      - Add code comment about first request being queued by PCODE. (Art)
      - Add timeout_base_ms argument. (Ville)
      v7:
      - Clarify code comment about first queued request. (Chris)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Art Runyan <arthur.j.runyan@intel.com>
      Cc: <stable@vger.kernel.org> # v4.2- : 3b2c1710 : drm/i915: Wait up to 3ms
      Cc: <stable@vger.kernel.org> # v4.2-
      Fixes: 5d96d8af ("drm/i915/skl: Deinit/init the display at suspend/resume")
      Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
      Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-1-git-send-email-imre.deak@intel.com
      a0b8a1fe
  17. 08 12月, 2016 3 次提交
  18. 07 12月, 2016 8 次提交
  19. 06 12月, 2016 1 次提交
    • C
      drm/i915: Fix i915_gem_evict_for_vma (soft-pinning) · 172ae5b4
      Chris Wilson 提交于
      Soft-pinning depends upon being able to check for availabilty of an
      interval and evict overlapping object from a drm_mm range manager very
      quickly. Currently it uses a linear list, and so performance is dire and
      not suitable as a general replacement. Worse, the current code will oops
      if it tries to evict an active buffer.
      
      It also helps if the routine reports the correct error codes as expected
      by its callers and emits a tracepoint upon use.
      
      For posterity since the wrong patch was pushed (i.e. that missed these
      key points and had known bugs), this is the changelog that should have
      been on commit 506a8e87 ("drm/i915: Add soft-pinning API for
      execbuffer"):
      
      Userspace can pass in an offset that it presumes the object is located
      at. The kernel will then do its utmost to fit the object into that
      location. The assumption is that userspace is handling its own object
      locations (for example along with full-ppgtt) and that the kernel will
      rarely have to make space for the user's requests.
      
      This extends the DRM_IOCTL_I915_GEM_EXECBUFFER2 to do the following:
      * if the user supplies a virtual address via the execobject->offset
        *and* sets the EXEC_OBJECT_PINNED flag in execobject->flags, then
        that object is placed at that offset in the address space selected
        by the context specifier in execbuffer.
      * the location must be aligned to the GTT page size, 4096 bytes
      * as the object is placed exactly as specified, it may be used by this
        execbuffer call without relocations pointing to it
      
      It may fail to do so if:
      * EINVAL is returned if the object does not have a 4096 byte aligned
        address
      * the object conflicts with another pinned object (either pinned by
        hardware in that address space, e.g. scanouts in the aliasing ppgtt)
        or within the same batch.
        EBUSY is returned if the location is pinned by hardware
        EINVAL is returned if the location is already in use by the batch
      * EINVAL is returned if the object conflicts with its own alignment (as meets
        the hardware requirements) or if the placement of the object does not fit
        within the address space
      
      All other execbuffer errors apply.
      
      Presence of this execbuf extension may be queried by passing
      I915_PARAM_HAS_EXEC_SOFTPIN to DRM_IOCTL_I915_GETPARAM and checking for
      a reported value of 1 (or greater).
      
      v2: Combine the hole/adjusted-hole ENOSPC checks
      v3: More color, more splitting, more blurb.
      
      Fixes: 506a8e87 ("drm/i915: Add soft-pinning API for execbuffer")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161205142941.21965-2-chris@chris-wilson.co.uk
      172ae5b4