1. 24 11月, 2015 5 次提交
    • R
      drm/i915: Remove PSR Perf Counter for SKL+ · 05eec3c2
      Rodrigo Vivi 提交于
      Whenever DMC firmware put the HW into DC State a bunch
      of registers including this perf counter is reset to 0.
      
      Even with PSR active and working we could still read
      "Performance_Counter: 0" what will misslead people to believe
      PSR is broken. For instance on SKL we can only see PC10
      residency with screen on if PSR is working properly.
      However Performance_Counter was showing 0.
      
      Even if it restored properly on DC6 exit we don't want to
      give users the wrong impression that PSR is not working
      while we know for sure it is.
      
      So, it is better to remove this counter information while
      we don't have a better way to track PSR residency.
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NDurgadoss R <durgadoss.r@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      05eec3c2
    • R
      drm/i915: PSR: Mask LPSP hw tracking back again. · bb929cbc
      Rodrigo Vivi 提交于
      When we introduced PSR we let LPSP masked allowing us to get PSR
      independently from the audio runtime PM. However in one of the
      attempts to get PSR enabled by default one user reported one specific
      case where he would miss screen updates if scrolling the firefox in a
      Gnome environment when i915 runtime pm was enabled. So for
      this specific case that (I could never create an i-g-t test case)
      we decided to remove the LPSP mask and let HW tracking taking care of
      this case. The mask got removed later by my
      commit 09108b90 ("drm/i915: PSR: Remove Low Power HW tracking mask.")
      
      So we started depending on audio driver again, what is bad.
      
      With previous commit
      "drm/i915: PSR: Let's rely more on frontbuffer tracking."
      we transfered the PSR exit responsability totally to SW frontbuffer
      tracking. So now can safelly shut off a bit the HW tracking, or
      at least this case that makes us to depend on other drivers.
      
      v2: Update commit message since this patch by itself doesn't solve
          the bugzilla entries.
      
      v3: Another attempt to improve commit message.
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Tested-by: NBrian Norris <briannorris@chromium.org>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: Damien Lespiau damien.lespiau@intel.com
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      bb929cbc
    • R
      drm/i915: PSR: Let's rely more on frontbuffer tracking. · 921ec285
      Rodrigo Vivi 提交于
      The ultimate goal here is to remove the dependency we
      currently have on audio driver power to get PSR working.
      Since with audio driver runtime PM disabled the Hardware tracking
      believes graphics is fully active and prevent PSR Entry, or
      in other words continuously exit PSR.
      
      So, the idea is to transfer the PSR exit responsability
      from the HW tracking to the SW tracking (frontbuffer tracking),
      who is really mature right now.
      
      However with LPSP masked out there might be cases where we could
      miss exit from HW tracking since it can be relying on this,
      like a specific case reported at our mailing list who
      user reported he would miss screen updates if scrolling firefox
      in a Gnome environment when i915 runtimepm was enabled.
      
      So before masking out LPSP again to make us independent from
      the audio driver we need to make sure that all our cases
      are coverred from the frontbuffer tracking perspective,
      where the flush means invalidate and flush.
      
      Without this patch for HSW, BDW and SKL we just do the
      invalidate part when the flush wasn't originated by a page flip
      because we were trusting the HW tracking for the flip case.
      
      So let's rely more on frontbuffer tracking and do the
      invalidation regardless the origin as expected for all platforms.
      
      v2: Improve commit message as suggested by Paulo.
      
      v3: Another attempt to let commit message more clear.
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: Damien Lespiau damien.lespiau@intel.com
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      921ec285
    • R
      drm/i915: Remove duplicated dpcd write on hsw_psr_enable_sink. · ca1a9533
      Rodrigo Vivi 提交于
      Commit (89251b17) intended to remove this line and let only one
      DP_PSR_EN_CFG set, but it was wrong and this call is now duplicated
      at the code.
      
      Also "& ~DP_PSR_MAIN_LINK_ACTIVE" doesn't do anything at all. It
      was like that since I introduced this call but probably the idea
      was to be informative and make clear statement that we were not using
      the link standby. So it is better to remove this one here and let
      the code a bit cleaner.
      
      v2: Improve commit message as requested by Paulo.
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Tested-by: NBrian Norris <briannorris@chromium.org>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: Damien Lespiau damien.lespiau@intel.com
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ca1a9533
    • T
      drm/i915: Remove incorrect warning in context cleanup · 408952d4
      Tvrtko Ursulin 提交于
      Commit e9f24d5f
      Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Date:   Mon Oct 5 13:26:36 2015 +0100
      
          drm/i915: Clean up associated VMAs on context destruction
      
      Added a warning based on an incorrect assumption that all VMAs
      in a VM will be on the inactive list at the point last reference
      to a context and VM is dropped.
      
      This is not true because i915_gem_object_retire__read will not
      put VMA on the inactive list until all activities on the object
      in question (in all VMs) have been retired.
      
      As a consequence, whether or not a context/VM will be destroyed
      with its VMAs still on the active list, can depend on completely
      unrelated activities using the same object from a different
      context or engine.
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92638
      Testcase: igt/gem_request_retire/retire-vma-not-inactive
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1448025816-25584-1-git-send-email-tvrtko.ursulin@linux.intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      408952d4
  2. 23 11月, 2015 5 次提交
  3. 20 11月, 2015 5 次提交
  4. 19 11月, 2015 17 次提交
  5. 18 11月, 2015 8 次提交