1. 05 11月, 2014 2 次提交
    • P
      drm/i915: run hsw_disable_pc8() later on resume · efee833a
      Paulo Zanoni 提交于
      We want to run intel_uncore_early_sanitize() before we touch any
      registers, because on BDW, when we resume, the FPGA_DBG_RM_NOCLAIM bit
      is set, so we need to clear it - through intel_uncore_early_sanitize()
      - before we do anything else. With the current code, we don't clear
      the bit before our first register access, so we print a WARN
      complaining about an unclaimed register error.
      
      v1: Was called "drm/i915: run intel_uncore_early_sanitize earlier on
      resume"
      v2: Was called "drm/i915: run intel_uncore_early_sanitize earlier on
      resume on non-VLV"
      v3: This one, on top of the intel_resume_prepare() rework.
      v4: Rebase.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      efee833a
    • P
      drm/i915: kill intel_resume_prepare() · 1a5df187
      Paulo Zanoni 提交于
      Because, really, the abstraction is not working for us. It is nice for
      VLV, but doesn't add anything useful on SNB/HSW/BDW. We want to change
      this code due to a recently-discovered bug, but we can't seem to find
      a nice solution that repects the current abstraction. So let's kill
      intel_resume_prepare() and its friends, and add an equivalent
      implementation to both its callers.
      
      Also, look at the diffstat!
      
      v2: - Rebase.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1a5df187
  2. 24 10月, 2014 18 次提交
  3. 03 10月, 2014 1 次提交
  4. 01 10月, 2014 2 次提交
  5. 24 9月, 2014 4 次提交
  6. 19 9月, 2014 3 次提交
  7. 10 9月, 2014 1 次提交
  8. 03 9月, 2014 4 次提交
  9. 26 8月, 2014 1 次提交
  10. 20 8月, 2014 1 次提交
  11. 18 8月, 2014 2 次提交
    • I
      drm/i915: make sure VDD is turned off during system suspend · 07f9cd0b
      Imre Deak 提交于
      Atm we may leave eDP VDD enabled during system suspend after the CRTCs
      are disabled through an HPD->DPCD read event. So disable VDD during
      suspend at a point when no HPDs can occur.
      
      Note that runtime suspend doesn't have the same problem, since there the
      RPM ref held by VDD provides already the needed serialization.
      
      v2:
      - add note to commit message about the runtime suspend path (Ville)
      - use edp_panel_vdd_off_sync(), so we can keep the WARN in
        edp_panel_vdd_off() (Ville)
      v3:
      - rebased on -fixes (for_each_intel_encoder()->list_for_each_entry())
        (Imre)
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2)
      Cc: stable@vger.kernel.org (3.16+)
      [Jani: fix sparse warning reported by Fengguang Wu]
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      07f9cd0b
    • I
      drm/i915: cancel hotplug and dig_port work during suspend and unload · 1d0d343a
      Imre Deak 提交于
      Make sure these work handlers don't run after we system suspend or
      unload the driver. Note that we don't cancel the handlers during runtime
      suspend. That could lead to a lockup, since we take a runtime PM ref
      from the handlers themselves. Fortunaltely canceling there is not needed
      since the RPM ref itself provides for the needed serialization.
      
      v2:
      - fix the order of canceling dig_port_work wrt. hotplug_work (Ville)
      - zero out {long,short}_hpd_port_mask and hpd_event_bits for speed
        (Ville)
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Cc: stable@vger.kernel.org (3.16+)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      1d0d343a
  12. 14 8月, 2014 1 次提交
    • S
      drm/i915: Sharing platform specific sequence between runtime and system suspend/ resume paths · 016970be
      Sagar Kamble 提交于
      On VLV, post S0i3 during i915_drm_thaw following issue is observed during ring
      initialization.
      
      [ 335.604039] [drm:stop_ring] ERROR render ring :timed out trying to stop ring
      [ 336.607340] [drm:stop_ring] ERROR render ring :timed out trying to stop ring
      [ 336.607345] [drm:init_ring_common] ERROR failed to set render ring head to zero ctl 00000000 head 00000000 tail 00000000 start 00000000
      [ 337.610645] [drm:stop_ring] ERROR bsd ring :timed out trying to stop ring
      [ 338.613952] [drm:stop_ring] ERROR bsd ring :timed out trying to stop ring
      [ 338.613956] [drm:init_ring_common] ERROR failed to set bsd ring head to zero ctl 00000000 head 00000000 tail 00000000 start 00000000
      [ 339.617256] [drm:stop_ring] ERROR render ring :timed out trying to stop ring
      [ 339.617258] -----------[ cut here ]-----------
      [ 339.617267] WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_ringbuffer.c:1666 intel_cleanup_ring+0xe6/0xf0()
      [ 339.617396] --[ end trace 5ef5ed1a3c92e2a6 ]--
      [ 339.617428] [drm:__i915_drm_thaw] ERROR failed to re-initialize GPU, declaring wedged!
      
      This is happening since wake is not enabled and Gunit registers are not restored.
      For this system suspend/resume paths need to follow save/restore and additional
      platform specific setup in suspend_complete and resume_prepare.
      
      suspend_complete is shared unconditionaly for VLV, HSW, BDW. resume_prepare for
      HSW and BDW has pc8 disabling which is needed during thaw_early so sharing
      uncondtionally. For VLV and SNB runtime resume specific sequence exists.
      
      Cc: Imre Deak <imre.deak@intel.com>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Goel, Akash <akash.goel@intel.com>
      Signed-off-by: NSagar Kamble <sagar.a.kamble@intel.com>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      016970be