1. 15 4月, 2016 3 次提交
  2. 06 4月, 2016 1 次提交
  3. 01 4月, 2016 2 次提交
  4. 31 3月, 2016 1 次提交
  5. 22 3月, 2016 3 次提交
  6. 21 3月, 2016 1 次提交
  7. 17 3月, 2016 2 次提交
  8. 16 3月, 2016 2 次提交
  9. 10 3月, 2016 1 次提交
  10. 09 3月, 2016 6 次提交
  11. 07 3月, 2016 1 次提交
  12. 04 3月, 2016 3 次提交
    • V
      drm/i915: Store rawclk_freq in dev_priv · e7dc33f3
      Ville Syrjälä 提交于
      Generalize rawclk handling by storing it in dev_priv.
      
      Presumably our hrawclk readout works at least for CTG and ELK
      since we've been using it for DP AUX on those platforms. There
      are no real docs anymore after configdb vanished, so the only
      reference is the public CTG GMCH spec. What bits are listed in
      that doc match our code. The ELK GMCH spec have no relevant
      details unfortunately.
      
      The PNV situation is less clear. Starting from
      commit aa17cdb4 ("drm/i915: initialize backlight max from VBT")
      we assume that the CTG/ELK hrawclk readout works for PNV as well.
      At least the results *seem* reasonable for one PNV machine (Lenovo
      Ideapad S10-3t). Sadly the PNV GMCH spec doesn't have the goods on
      the relevant register either.
      
      So let's keep assuming it works for PNV,ELK,CTG and read it out on
      those platforms. G33 also has hrawclk according to some notes
      in BSpec, but we don't actually need it for anything, so let's not
      even try to read it out there.
      
      v2: Rebase due to IS_VALLYVIEW vs. IS_CHERRYVIEW split
          Use KHz() all over, and kill off a few useless temp variables
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1456932138-14004-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
      e7dc33f3
    • T
      drm/i915: Do not lie about atomic timeout granularity · 0351b939
      Tvrtko Ursulin 提交于
      Currently the wait_for_atomic_us only allows for a jiffie
      timeout granularity which is not nice towards callers
      requesting small micro-second timeouts.
      
      Re-implement it so micro-second timeout granularity is really
      supported and not just in the name of the macro.
      
      This has another beneficial side effect that it improves
      "gem_latency -n 100" results by approximately 2.5% (throughput
      and latencies) and 3% (CPU usage). (Note this improvement is
      relative to not yet merged execlist lock uncontention patch
      which moves the CSB MMIO outside this lock.)
      
      It also shrinks some hot functions like fw_domains_get by a
      tiny 3%.
      
      v2:
        * Warn when used from non-atomic context (if possible).
        * Warn on too long atomic waits.
      
      v3:
        * Added comment explaining CONFIG_PREEMPT_COUNT.
        * Fixed pre-processor indentation.
        (Chris Wilson)
      
      v4:
       * Commit msg update (gem_latency) and rebase.
      
      v5:
       * Commit message re-wording.
       * Added comment about no need for double cond check. (Chris Wilson)
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      0351b939
    • T
      drm/i915: Add wait_for_us · 3f177625
      Tvrtko Ursulin 提交于
      This is for callers who want micro-second precision but are not
      waiting from the atomic context.
      
      v2:
        * Fix atomic waits. (Dave Gordon)
        * Use USEC_PER_SEC and USEC_PER_MSEC. (Chris Wilson)
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Dave Gordon <david.s.gordon@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      3f177625
  13. 03 3月, 2016 1 次提交
  14. 01 3月, 2016 8 次提交
  15. 25 2月, 2016 2 次提交
  16. 23 2月, 2016 1 次提交
  17. 22 2月, 2016 2 次提交