1. 13 1月, 2016 2 次提交
  2. 22 12月, 2015 1 次提交
  3. 19 12月, 2015 5 次提交
    • D
      drm/i915: Update DRIVER_DATE to 20151218 · 7447a2b2
      Daniel Vetter 提交于
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7447a2b2
    • M
      drm/i915/skl: Default to noncoherent access up to F0 · e238659d
      Mika Kuoppala 提交于
      The workarounds for disabling hdc invalidation and also forcing
      context to be non coherent, are advised to be used up until rev D0.
      
      However as it was found that rev F0, without the
      WaForceEnableNonCoherent might system hang if the mesa
      tried to use coherent mode.
      
      As these two workarounds are about non coherent access, are
      grouped in scope and they point the same HSD, increase the
      scope of both to set default behaviour to non coherent access.
      
      References: HSD: gen9lp/2131413
      References: http://lists.freedesktop.org/archives/mesa-dev/2015-November/101515.html
      Cc: Ben Widawsky <benjamin.widawsky@intel.com>
      Cc: Francisco Jerez <currojerez@riseup.net>
      Reviewed-by: NFrancisco Jerez <currojerez@riseup.net>
      Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1450448093-22906-1-git-send-email-mika.kuoppala@intel.com
      e238659d
    • C
      drm/i915: Only spin whilst waiting on the current request · 821485dc
      Chris Wilson 提交于
      Limit busywaiting only to the request currently being processed by the
      GPU. If the request is not currently being processed by the GPU, there
      is a very low likelihood of it being completed within the 2 microsecond
      spin timeout and so we will just be wasting CPU cycles.
      
      v2: Check for logical inversion when rebasing - we were incorrectly
      checking for this request being active, and instead busywaiting for
      when the GPU was not yet processing the request of interest.
      
      v3: Try another colour for the seqno names.
      v4: Another colour for the function names.
      
      v5: Remove the forced coherency when checking for the active request. On
      reflection and plenty of recent experimentation, the issue is not a
      cache coherency problem - but an irq/seqno ordering problem (timing issue).
      Here, we do not need the w/a to force ordering of the read with an
      interrupt.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Eero Tamminen <eero.t.tamminen@intel.com>
      Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-4-git-send-email-chris@chris-wilson.co.uk
      821485dc
    • C
      drm/i915: Limit the busy wait on requests to 5us not 10ms! · ca5b721e
      Chris Wilson 提交于
      When waiting for high frequency requests, the finite amount of time
      required to set up the irq and wait upon it limits the response rate. By
      busywaiting on the request completion for a short while we can service
      the high frequency waits as quick as possible. However, if it is a slow
      request, we want to sleep as quickly as possible. The tradeoff between
      waiting and sleeping is roughly the time it takes to sleep on a request,
      on the order of a microsecond. Based on measurements of synchronous
      workloads from across big core and little atom, I have set the limit for
      busywaiting as 10 microseconds. In most of the synchronous cases, we can
      reduce the limit down to as little as 2 miscroseconds, but that leaves
      quite a few test cases regressing by factors of 3 and more.
      
      The code currently uses the jiffie clock, but that is far too coarse (on
      the order of 10 milliseconds) and results in poor interactivity as the
      CPU ends up being hogged by slow requests. To get microsecond resolution
      we need to use a high resolution timer. The cheapest of which is polling
      local_clock(), but that is only valid on the same CPU. If we switch CPUs
      because the task was preempted, we can also use that as an indicator that
       the system is too busy to waste cycles on spinning and we should sleep
      instead.
      
      __i915_spin_request was introduced in
      commit 2def4ad9 [v4.2]
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Apr 7 16:20:41 2015 +0100
      
           drm/i915: Optimistically spin for the request completion
      
      v2: Drop full u64 for unsigned long - the timer is 32bit wraparound safe,
      so we can use native register sizes on smaller architectures. Mention
      the approximate microseconds units for elapsed time and add some extra
      comments describing the reason for busywaiting.
      
      v3: Raise the limit to 10us
      v4: Now 5us.
      Reported-by: NJens Axboe <axboe@kernel.dk>
      Link: https://lkml.org/lkml/2015/11/12/621Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Eero Tamminen <eero.t.tamminen@intel.com>
      Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-3-git-send-email-chris@chris-wilson.co.uk
      ca5b721e
    • C
      drm/i915: Break busywaiting for requests on pending signals · 91b0c352
      Chris Wilson 提交于
      The busywait in __i915_spin_request() does not respect pending signals
      and so may consume the entire timeslice for the task instead of
      returning to userspace to handle the signal.
      
      In the worst case this could cause a delay in signal processing of 20ms,
      which would be a noticeable jitter in cursor tracking. If a higher
      resolution signal was being used, for example to provide fairness of a
      server timeslices between clients, we could expect to detect some
      unfairness between clients (i.e. some windows not updating as fast as
      others). This issue was noticed when inspecting a report of poor
      interactivity resulting from excessively high __i915_spin_request usage.
      
      Fixes regression from
      commit 2def4ad9 [v4.2]
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Apr 7 16:20:41 2015 +0100
      
           drm/i915: Optimistically spin for the request completion
      
      v2: Try to assess the impact of the bug
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc; "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Eero Tamminen <eero.t.tamminen@intel.com>
      Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-2-git-send-email-chris@chris-wilson.co.uk
      91b0c352
  4. 18 12月, 2015 3 次提交
  5. 17 12月, 2015 19 次提交
  6. 16 12月, 2015 10 次提交