1. 15 Jul, 2015 2 commits
  2. 14 Jul, 2015 21 commits
  3. 13 Jul, 2015 11 commits
  4. 09 Jul, 2015 6 commits
    • Rodrigo Vivi's avatar
      drm/i915: fbdev restore mode needs to invalidate frontbuffer · d04df732
      Rodrigo Vivi authored
      This fbdev restore mode was another corner case that was now
      calling frontbuffer flip and flush and making we miss
      screen updates with PSR enabled.
      
      So let's also add the invalidate hack here while we don't have
      a reliable dirty fbdev op.
      
      v2: As pointed by Paulo: removed seg fault risk, used fb_helper
          when possible and put brackets on if.
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Testcase: igt/kms_fbcon_fbt/psr
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d04df732
    • Rodrigo Vivi's avatar
      drm/i915: fbdev_set_par reliably invalidating frontbuffer · aba6da3e
      Rodrigo Vivi authored
      fbdev_set_par is called when fbcon is taking over control.
      In the past frontbuffer was being invalidated on
      set_to_gtt_domain, but it moved to set_domain fixing that case,
      but left this behind and broken in
      
      commit 031b698a
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Fri Jun 26 19:35:16 2015 +0200
      
          drm/i915: Unconditionally do fb tracking invalidate in set_domain
      
      Note that even before this commit it wasn't perfect since the
      invalidate was omitted if the fbcon was already in the GTT domain,
      which it usually was.
      
      Since we are also invalidating in other fbdev cases this one
      was masked here. At least until now that I found this corner
      case: On boot with plymouth doing a splash screen
      when returning to the console frontbuffer wans't being invalidated
      causing missed screen updates with PSR enabled.
      
      So this patch fixes this issue.
      
      v2: Make invalidate directly and unconditionally and
          fix commit message indicating the set_domain fix
          as pointed out by Daniel.
      v3: Remove unecessary if(obj) added by mistake
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      [danvet: Try to clarify commit message a bit and make it clear the
      referenced commit made this worse.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      aba6da3e
    • Rodrigo Vivi's avatar
      drm/i915: PSR: Increase idle_frames · 97173eaf
      Rodrigo Vivi authored
      Idle frames the number of identical frames needed
      before panel can enter PSR.
      
      There are some panels that requires up to minimum of 4 idle
      frames available on the market. For these cases usually
      VBT should be used to configure the number of idle frames,
      but unfortunately this isn't always true and VBT isn't being
      set at all.
      
      Let's trust VBT when it is set + 1  and use minimum of 4 + 1
      when VBT isn't set. "+1" covers the "of-by-one" case.
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      97173eaf
    • Rodrigo Vivi's avatar
      drm/i915: PSR: Remove Low Power HW tracking mask. · 09108b90
      Rodrigo Vivi authored
      By Spec we should only mask memup and hotplug detection
      for hardware tracking cases. However we always masked
      LPSP because with power well always enabled on audio
      PSR was never being activated and residency was always
      zeroed.
      
      Apparently audio driver is tying power well management
      and runtime PM for some reason. But with audio runtime
      PM working or with audio completely out of picture
      we should remove this mask, otherwise we have a high
      risk of miss screen updates as faced by Matthew.
      
      WARNING: With this patch if snd_intel_hda driver is
      running and not releasing power well properly PSR will
      constant Exit and Performance Counter will be 0.
      
      But the best thing of this patch is that with one more
      HW tracking working the risks of missed blank screen
      are minimized at most.
      
      This affects just core platforms where PSR exit are also
      helped by HW tracking: Haswell, Broadwell and Skylake
      for now.
      
      v2: Fix commit message explanation. It has nothing to do
      with runtime PM on i915 as previously advertised.
      
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      09108b90
    • Paulo Zanoni's avatar
      drm/i915: fix intel_frontbuffer_flip documentation · cc2e26a7
      Paulo Zanoni authored
      Reported by the kbuild test robot.
      
      Regression introduced by:
      commit fdbff928
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Jun 18 11:23:24 2015 +0200
          drm/i915: Clear fb_tracking.busy_bits also for synchronous flips
      
      (I reviewed this commit, so it's also my fault)
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      cc2e26a7
    • Paulo Zanoni's avatar
      drm/i915: intel_frontbuffer_flush can now be static · b6c2aa51
      Paulo Zanoni authored
      So make it static.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b6c2aa51