1. 30 1月, 2012 2 次提交
  2. 18 1月, 2012 1 次提交
  3. 04 1月, 2012 1 次提交
  4. 17 12月, 2011 1 次提交
  5. 11 11月, 2011 1 次提交
  6. 04 11月, 2011 1 次提交
  7. 01 11月, 2011 1 次提交
  8. 20 9月, 2011 1 次提交
  9. 10 8月, 2011 1 次提交
  10. 04 8月, 2011 1 次提交
  11. 30 7月, 2011 1 次提交
  12. 30 6月, 2011 2 次提交
  13. 29 6月, 2011 1 次提交
    • J
      drm/i915: load a ring frequency scaling table v3 · 23b2f8bb
      Jesse Barnes 提交于
      The ring frequency scaling table tells the PCU to treat certain GPU
      frequencies as if they were a given CPU frequency for purposes of
      scaling the ring frequency.  Normally the PCU will scale the ring
      frequency based on the CPU P-state, but with the table present, it will
      also take the GPU frequency into account.
      
      The main downside of keeping the ring frequency high while the CPU is
      at a low frequency (or asleep altogether) is increased power
      consumption.  But then if you're keeping your GPU busy, you probably
      want the extra performance.
      
      v2:
        - add units to debug table header (from Eric)
        - use tsc_khz as a fallback if the cpufreq driver doesn't give us a freq
          (from Chris)
      v3:
        - fix comments & debug output
        - remove unneeded force wake get/put
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Tested-by: NEric Anholt <eric@anholt.net>
      Reviewed-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      23b2f8bb
  14. 05 6月, 2011 1 次提交
  15. 18 5月, 2011 1 次提交
  16. 14 5月, 2011 1 次提交
  17. 11 5月, 2011 5 次提交
  18. 23 3月, 2011 1 次提交
  19. 06 3月, 2011 1 次提交
  20. 08 2月, 2011 1 次提交
  21. 28 1月, 2011 1 次提交
  22. 19 1月, 2011 2 次提交
  23. 13 1月, 2011 1 次提交
  24. 12 1月, 2011 5 次提交
  25. 18 12月, 2010 1 次提交
  26. 15 12月, 2010 1 次提交
    • Y
      drm/i915: Add self-refresh support on Sandybridge · 1398261a
      Yuanhan Liu 提交于
      Add the support of memory self-refresh on Sandybridge, which is now
      support 3 levels of watermarks and the source of the latency values
      for watermarks has changed.
      
      On Sandybridge, the LP0 WM value is not hardcoded any more. All the
      latency value is now should be extracted from MCHBAR SSKPD register.
      And the MCHBAR base address is changed, too.
      
      For the WM values, if any calculated watermark values is larger than
      the maximum value that can be programmed into the associated watermark
      register, that watermark must be disabled.
      Signed-off-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
      [ickle: remove duplicate compute routines and fixup for checkpatch]
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      1398261a
  27. 06 12月, 2010 1 次提交
  28. 05 12月, 2010 1 次提交
  29. 25 11月, 2010 1 次提交