1. 06 5月, 2012 5 次提交
  2. 03 5月, 2012 2 次提交
  3. 13 4月, 2012 2 次提交
    • D
      drm/i915: re-init modeset hw state after gpu reset · f817586c
      Daniel Vetter 提交于
      After a gpu reset we need to re-init some of the hw state we only
      initialize when modeset is enabled, like rc6, hw contexts or render/GT
      core clock gating and workaround register settings.
      
      Note that this patch has a small change in the resume code:
      - rc6 on gen6+ is only restored for the modeset case (for more
        consistency with other callsites). This is no problem because recent
        kernels refuse to load drm/i915 without kms on gen6+
      - rc6/emon on ilk is only restored for the modeset case. This is no
        problem because rc6 is disabled by default on ilk, and ums on ilk
        has never really been a supported option outside of horrible rhel
        backports.
      
      v2: Chris Wilson noticed that we not only fail to restore the clock
      gating settings after gpu reset.
      
      v3: Move the call to modeset_init_hw in _reset out of the
      struct_mutext protected area - other callers don't hold it, too.
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f817586c
    • B
      drm/i915: use semaphores for the display plane · 2911a35b
      Ben Widawsky 提交于
      In theory this will have performance and power improvements. Performance
      because we don't need to stall when the scanout BO is busy, and power
      because we don't have to stall when the BO is busy (and the ring can
      even go to sleep if the HW supports it).
      
      v2:
      squash 2 patches into 1 (me)
      un-inline the enable_semaphores function (Daniel)
      remove comment about SNB hangs from i915_gem_object_sync (Chris)
      rename intel_enable_semaphores to i915_semaphore_is_enabled (me)
      removed page flip comment; "no why" (Chris)
      
      To address other comments from Daniel (irc):
      update the comment to say 'vt-d is crap, don't enable semaphores'
        - I think you misinterpreted Chris' comment, it already exists.
      checking out whether we can pageflip on the render ring on ivb (didn't
      work on early silicon)
        - We don't want to enable workarounds for early silicon unless we have
          to.
        - I can't find any references in the docs about this.
      optionally use it if the fb is already busy on the render ring
        - This should be how the code already worked, unless I am
          misunderstanding your meaning.
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2911a35b
  4. 12 4月, 2012 1 次提交
  5. 10 4月, 2012 3 次提交
  6. 03 4月, 2012 1 次提交
  7. 02 4月, 2012 2 次提交
  8. 01 4月, 2012 1 次提交
  9. 29 3月, 2012 3 次提交
  10. 24 3月, 2012 1 次提交
  11. 23 3月, 2012 1 次提交
  12. 02 3月, 2012 1 次提交
  13. 12 2月, 2012 2 次提交
  14. 10 2月, 2012 1 次提交
  15. 09 2月, 2012 1 次提交
    • D
      drm/i915: swizzling support for snb/ivb · f691e2f4
      Daniel Vetter 提交于
      We have to do this manually. Somebody had a Great Idea.
      
      I've measured speed-ups just a few percent above the noise level
      (below 5% for the best case), but no slowdows. Chris Wilson measured
      quite a bit more (10-20% above the usual snb variance) on a more
      recent and better tuned version of sna, but also recorded a few
      slow-downs on benchmarks know for uglier amounts of snb-induced
      variance.
      
      v2: Incorporate Ben Widawsky's preliminary review comments and
      elaborate a bit about the performance impact in the changelog.
      
      v3: Add a comment as to why we don't need to check the 3rd memory
      channel.
      
      v4: Fixup whitespace.
      Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NEric Anholt <eric@anholt.net>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f691e2f4
  16. 20 1月, 2012 4 次提交
  17. 18 1月, 2012 1 次提交
  18. 17 1月, 2012 2 次提交
  19. 14 1月, 2012 1 次提交
  20. 04 1月, 2012 1 次提交
    • K
      drm/i915: Clean up multi-threaded forcewake patch · c7dffff7
      Keith Packard 提交于
      We learned that the ECOBUS register was inside the GT power well, and
      so *did* need force wake to be read, so it gets removed from the list
      of 'doesn't need force wake' registers.
      
      That means the code reading ECOBUS after forcing the mt_force_wake
      function to be called needs to use I915_READ_NOTRACE; it doesn't need
      to do more force wake fun as it's already done it manually.
      
      This also adds a comment explaining why the MT forcewake testing code
      only needs to call mt_forcewake_get/put and not disable RC6 manually
      -- the ECOBUS read will return 0 if the device is in RC6 and isn't
      using MT forcewake, causing the test to work correctly.
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      c7dffff7
  21. 17 12月, 2011 2 次提交
  22. 24 11月, 2011 1 次提交
  23. 11 11月, 2011 1 次提交
    • A
      drm: Make the per-driver file_operations struct const · e08e96de
      Arjan van de Ven 提交于
      From fdf1fdebaa00f81de18c227f32f8074c8b352d50 Mon Sep 17 00:00:00 2001
      From: Arjan van de Ven <arjan@linux.intel.com>
      Date: Sun, 30 Oct 2011 19:06:07 -0700
      Subject: [PATCH] drm: Make the per-driver file_operations struct const
      
      The DRM layer keeps a copy of struct file_operations inside its
      big driver struct... which prevents it from being consistent and static.
      For consistency (and the general security objective of having such things
      static), it's desirable to get this fixed.
      
      This patch splits out the file_operations field to its own struct,
      which is then "static const", and just stick a pointer to this into
      the driver struct, making it more consistent with how the rest of the
      kernel does this.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      e08e96de