1. 03 12月, 2014 2 次提交
    • R
      drm/i915: Remove intel_psr_is_enabled function. · e4d59f6b
      Rodrigo Vivi 提交于
      This function was in use to check if PSR feature got enabled.
      However on HSW and BDW we currently force psr exit by disabling
      EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev). So this function was actually
      returning the active/inactive state that is different from the enable/disable
      meaning and had the risk of false negative.
      
      But anyway this check with DRRS was dangerous, since DRRS could try to get enabled
      before PSR gets there. So let's just remove it for now.
      A proper synchronization mechanism must be implemented later probably
      using pipe config.
      
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Reviewed-by: NDurgadoss R <durgadoss.r@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e4d59f6b
    • V
      drm/i915: Grab modeset locks for GPU rest on pre-ctg · 7514747d
      Ville Syrjälä 提交于
      On gen4 and earlier the GPU reset also resets the display, so we should
      protect against concurrent modeset operations. Grab all the modeset locks
      around the entire GPU reset dance, remebering first ti dislogde any
      pending page flip to make sure we don't deadlock. Any pageflip coming
      in between these two steps should fail anyway due to reset_in_progress,
      so this should be safe.
      
      This fixes a lot of failed asserts in the modeset code when there's a
      modeset racing with the reset. Naturally the asserts aren't happy when
      the expected state has disappeared.
      
      v2: Drop UMS checks, complete pending flips after the reset (Daniel)
      
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7514747d
  2. 19 11月, 2014 1 次提交
    • I
      drm/i915: sanitize rps irq enabling · 3cc134e3
      Imre Deak 提交于
      Atm we first enable the RPS interrupts then we clear any pending ones.
      By this we could lose an interrupt arriving after we unmasked it. This
      may not be a problem as the caller should handle such a race, but logic
      still calls for the opposite order. Also we can delay enabling the
      interrupts until after all the RPS initialization is ready with the
      following order:
      
      1. disable left-over RPS (earlier via intel_uncore_sanitize)
      2. clear any pending RPS interrupts
      3. initialize RPS
      4. enable RPS interrupts
      
      This also allows us to do the 2. and 4. step the same way for all
      platforms, so let's follow this order to simplifying things.
      
      Also make sure any queued interrupts are also cleared.
      
      v2:
      - rebase on the GEN9 patches where we don't support RPS yet, so we
        musn't enable RPS interrupts on it (Paulo)
      v3:
      - avoid enabling RPS interrupts on GEN>9 too (Paulo)
      - clarify the RPS init sequence in the log message (Chris)
      - add POSTING_READ to gen6_reset_rps_interrupts() (Paulo)
      - WARN if any PM_IIR bits are set in gen6_enable_rps_interrupts()
        (Paulo)
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3cc134e3
  3. 18 11月, 2014 1 次提交
  4. 14 11月, 2014 6 次提交
  5. 08 11月, 2014 8 次提交
  6. 05 11月, 2014 7 次提交
  7. 24 10月, 2014 4 次提交
  8. 06 10月, 2014 1 次提交
  9. 03 10月, 2014 2 次提交
  10. 01 10月, 2014 5 次提交
  11. 24 9月, 2014 1 次提交
  12. 20 9月, 2014 1 次提交
    • D
      drm/i915: DocBook integration for frontbuffer tracking · b680c37a
      Daniel Vetter 提交于
      I shouldn't ask everyone to do this and fail myself ...
      
      This extracts all the frontbuffer tracking functions into
      intel_frontbuffer.c, adds a DOC overview section and also adds the
      missing kerneldoc for i915_gem_track_fb and also pulls it into the
      same section for convenience.
      
      v2: Don't forget about the header files.
      
      v3: Oops, might check compilation next time around. To make my life
      easier drop the increase_pllclock from set_base_atomic since really,
      it doesn't matter if you see your Oops or kgdb with a tiny bit of lag.
      
      v4: Try to better explain how to actually use this, requested by Paulo
      on irc.
      
      v5: Explain invalidate/flush a bit clearer.
      
      v6: s/business/busyness/
      Acked-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Vandana Kannan <vandana.kannan@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      b680c37a
  13. 19 9月, 2014 1 次提交