1. 04 9月, 2014 4 次提交
  2. 03 9月, 2014 17 次提交
  3. 18 8月, 2014 3 次提交
  4. 12 8月, 2014 1 次提交
  5. 08 8月, 2014 6 次提交
  6. 07 8月, 2014 3 次提交
  7. 06 8月, 2014 1 次提交
  8. 23 7月, 2014 5 次提交
    • P
      drm/i915: remove useless runtime PM get calls · 4651fb23
      Paulo Zanoni 提交于
      We already call intel_display_power_get, which will get a power
      domain, and every power domain should get a runtime PM reference,
      which will wake up the machine.
      
      v2: - Also touch intel_crt_detect() (Ville).
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      [danvet: Fixup commit message as spotted by Ville.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4651fb23
    • D
      drm/i915: Remove redundant HAS_PSR checks · eeefa889
      Daniel Vetter 提交于
      We only need to check for this in psr_enable, everything else is
      already protect by the dev_priv->psr.enabled checks. Those need the
      psr locking, but these functions are called infrequent enough that the
      locking overhead is negligible.
      
      Suggested by Chris Wilson.
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      eeefa889
    • D
      drm/i915: Fix up PSR frontbuffer tracking · 9ca15301
      Daniel Vetter 提交于
      I've tried to split this up, but all the changes are so tightly
      related that I didn't find a good way to do this without breaking
      bisecting. Essentially this completely changes how psr is glued into
      the overall driver, and there's not much you can do to soften such a
      paradigm change.
      
      - Use frontbuffer tracking bits stuff to separate disable and
        re-enable.
      
      - Don't re-check everything in the psr work. We have now accurate
        tracking for everything, so no need to check for sprites or tiling
        really. Allows us to ditch tons of locks.
      
      - That in turn allows us to properly cancel the work in the disable
        function - no more deadlocks.
      
      - Add a check for HSW sprites and force a flush. Apparently the
        hardware doesn't forward the flushing when updating the sprite base
        address. We can do the same trick everywhere else we have such
        issues, e.g. on baytrail with ... everything.
      
      - Don't re-enable psr with a delay in psr_exit. It really must be
        turned off forever if we detect a gtt write. At least with the
        current frontbuffer render tracking. Userspace can do a busy ioctl
        call or no-op pageflip to re-enable psr.
      
      - Drop redundant checks for crtc and crtc->active - now that they're
        only called from enable this is guaranteed.
      
      - Fix up the hsw port check. eDP can also happen on port D, but the
        issue is exactly that it doesn't work there. So an || check is
        wrong.
      
      - We still schedule the psr work with a delay. The frontbuffer
        flushing interface mandates that we upload the next full frame, so
        need to wait a bit. Once we have single-shot frame uploads we can do
        better here.
      
      v2: Don't enable psr initially, rely upon the fb flush of the initial
      plane setup for that. Gives us more unified code flow and makes the
      crtc enable sequence less a special case.
      
      v3: s/psr_exit/psr_invalidate/ for consistency
      
      v4: Fixup whitespace.
      
      v5: Correctly bail out of psr_invalidate/flush when
      dev_priv->psr.enabled is NULL. Spotted by Rodrigo.
      
      v6:
      - Only schedule work when there's work to do. Fixes WARNINGs reported
        by Rodrigo.
      - Comments Chris requested to clarify the code.
      
      v7: Fix conflict on rebase (Rodrigo)
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v6)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9ca15301
    • D
      drm/i915: Add locking to psr code · f0355c4a
      Daniel Vetter 提交于
      It's not really optional to have locking ...
      
      The ugly part is how much locking the psr work needs since it has to
      recheck everything. Which is way too much. But we need to ditch the
      psr work in it's current form anyway and implement proper frontbuffer
      tracking.
      
      The other nasty bit that had to go was the delayed work cancle in
      psr_exit. Which means a bunch of races just became a bit more likely,
      but mea culpa.
      
      v2: Fixup HAS_PSR checks, resulting in uninitialized mutex issues.
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f0355c4a
    • D
      drm/i915: More checks for psr.enabled · 109fc2ad
      Daniel Vetter 提交于
      We need to make sure that no one else is using this in the
      enable function and also that the work item hasn't raced
      with the disabled function.
      
      v2: Improve bisectability by moving one hunk to an earlier patch.
      
      v3: added missing dev_priv declaration (Rodrigo)
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v2)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      109fc2ad