1. 24 9月, 2014 3 次提交
  2. 05 9月, 2014 2 次提交
    • C
      drm/i915: Decouple the stuck pageflip on modeset · 9c787942
      Chris Wilson 提交于
      If we successfully confuse the hardware, and cause it to drop a queued
      pageflip, we wait for 60s and issue a warning before continuing on with
      the modeset. However, this leaves the pending pageflip still stuck
      indefinitely. Pretend to userspace that it does complete, and let us
      start afresh following the modeset.
      
      v2: Rebase after refactor
      v3: Rebase, rebase.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      References: https://bugs.freedesktop.org/show_bug.cgi?id=82612Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9c787942
    • C
      drm/i915: Check for a stalled page flip after each vblank · d6bbafa1
      Chris Wilson 提交于
      Long ago, back in the racy haydays of 915gm interrupt handling, page
      flips would occasionally go astray and leave the hardware stuck, and the
      display not updating. This annoyed people who relied on their systems
      being able to display continuously updating information 24/7, and so
      some code to detect when the driver missed the page flip completion
      signal was added. Until recently, it was presumed that the interrupt
      handling was now flawless, but once again Simon Farnsworth has found a
      system whose display will stall. Reinstate the pageflip stall detection,
      which works by checking to see if the hardware has been updated to the
      new framebuffer address following each vblank. If the hardware is
      scanning out from the new framebuffer, but we still think the flip is
      pending, then we kick our driver into submision.
      
      This is a continuation of the effort started with
      commit 4e5359cd
      Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
      Date:   Wed Sep 1 17:47:52 2010 +0100
      
          drm/i915: Avoid pageflipping freeze when we miss the flip prepare interrupt
      
      This now includes a belt-and-braces approach to make sure the driver
      (or the hardware) doesn't miss an interrupt and cause us to stop
      updating the display should the unthinkable happen and the pageflip fail - i.e.
      that the user is able to continue submitting flips.
      
      v2: Cleanup, refactor, and rename
      v3: Only start counting vblanks after the flip command has been seen by
          the hardware.
      v4: Record the seqno after we touch the ring, or else there may be no
          seqno allocated yet.
      v5: Rebase on mmio-flip.
      v6: Rebase, rebase.
      Reported-by: NSimon Farnsworth <simon@farnz.org.uk>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75502Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [v4]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d6bbafa1
  3. 04 9月, 2014 1 次提交
    • V
      drm/i915: Fix edp vdd locking · e39b999a
      Ville Syrjälä 提交于
      Introduce a new mutex (pps_mutex) to protect the power sequencer
      state. For now this state includes want_panel_vdd as well as the
      power sequencer registers.
      
      We need a single mutex (as opposed to per port) because later on we
      will need to deal with VLV/CHV which have multiple power sequencer
      which can be reassigned to different ports.
      
      v2: Add the locking to intel_dp_encoder_suspend too (Imre)
      v3: Take care intel_edp_backlight_power() and
          _intel_edp_backlight_on/off(), deal with reboot notifier
          vlv_power_sequencer_pipe() call (Imre)
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e39b999a
  4. 03 9月, 2014 22 次提交
  5. 26 8月, 2014 3 次提交
    • V
      drm/i915: Move intel_ddi_set_vc_payload_alloc(false) to haswell_crtc_disable() · a4bf214f
      Ville Syrjälä 提交于
      Somehow the intel_ddi_set_vc_payload_alloc(false) call has ended up
      in ironlake_crtc_disable() rather than haswell_crtc_disable(). Move it
      to the correct place.
      
      intel_ddi_disable_transcoder_func() already disables the vc payload
      allocation so this doesn't actually do anything more. The spec
      says we should wait for some kind of ack after frobbing the bit. We
      don't appear to do that currently, but if and when someone decides
      that we should do it, intel_ddi_set_vc_payload_alloc() would appear
      to be be the right place for it. So having the function call in
      haswell_crtc_disable() seems like the right thing for the future
      even if it does nothing currently.
      
      Cc: Dave Airlie <airlied@redhat.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      a4bf214f
    • P
      drm/i915: fix plane/cursor handling when runtime suspended · d6dd6843
      Paulo Zanoni 提交于
      If we're runtime suspended and try to use the plane interfaces, we
      will get a lot of WARNs saying we did the wrong thing.
      
      We need to get runtime PM references to pin the objects, and to
      change the fences. The pin functions are the ideal places for
      this, but intel_crtc_cursor_set_obj() doesn't call them, so we also
      have to add get/put calls inside it. There is no problem if we runtime
      suspend right after these functions are finished, because the
      registers written are forwarded to system memory.
      
      Note: for a complete fix of the cursor-dpms test case, we also need
      the patch named "drm/i915: Don't try to enable cursor from setplane
      when crtc is disabled".
      
      v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
      v3: - Make get/put also surround the fence and unpin calls (Daniel and
            Ville).
          - Merge all the plane changes into a single patch since they're
            the same fix.
          - Add the comment requested by Daniel.
      v4: - Remove spurious whitespace (Ville).
      v5: - Remove intel_crtc_update_cursor() chunk since Ville did an
            equivalent fix in another patch (Ville).
      v6: - Remove unpin chunk: it will be on a separate patch (Ville,
            Chris, Daniel).
      v7: - Same thing, new color.
      
      Testcase: igt/pm_rpm/cursor
      Testcase: igt/pm_rpm/cursor-dpms
      Testcase: igt/pm_rpm/legacy-planes
      Testcase: igt/pm_rpm/legacy-planes-dpms
      Testcase: igt/pm_rpm/universal-planes
      Testcase: igt/pm_rpm/universal-planes-dpms
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82603
      Cc: stable@vger.kernel.org
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      d6dd6843
    • S
      drm/i915: Ignore VBT backlight presence check on Acer C720 (4005U) · dfb3d47b
      Scot Doyle 提交于
      commit c675949e
      Author: Jani Nikula <jani.nikula@intel.com>
      Date:   Wed Apr 9 11:31:37 2014 +0300
      
          drm/i915: do not setup backlight if not available according to VBT
      
      prevents backlight setup on the Acer C720 (Core i3 4005U CPU), which has a
      misconfigured VBT. Apply quirk to ignore the VBT backlight presence check
      during backlight setup.
      Signed-off-by: NScot Doyle <lkml14@scotdoyle.com>
      Tested-by: NTyler Cleveland <siralucardt@openmailbox.org>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org (3.15+)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      dfb3d47b
  6. 18 8月, 2014 5 次提交
    • 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
    • I
      drm/i915: fix HPD IRQ reenable work cancelation · 6323751d
      Imre Deak 提交于
      Atm, the HPD IRQ reenable timer can get rearmed right after it's
      canceled. Also to access the HPD IRQ mask registers we need to wake up
      the HW.
      
      Solve both issues by converting the reenable timer to a delayed work and
      grabbing a runtime PM reference in the work. By this we can also forgo
      canceling the timer during runtime suspend, since the only important
      thing there is that the HW is awake when we write the registers and
      that's ensured by the RPM ref. So do the cancelation only during driver
      unload time; this is also a requirement for an upcoming patch where we
      want to cancel all HPD related works only during system suspend and
      driver unload time, but not during runtime suspend.
      
      Note that there is still a race between the HPD IRQ reenable work and
      drm_irq_uninstall() during driver unload, where the work can reenable
      the HPD IRQs disabled by drm_irq_uninstall(). This isn't a problem since
      the HPD IRQs will still be effectively masked by the first level
      interrupt mask.
      
      v2-3:
      - unchanged
      v4:
      - use proper API for changing the expiration time for an already pending
        delayed work (Jani)
      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+)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      6323751d
    • V
      drm/i915: Don't try to enable cursor from setplane when crtc is disabled · 1add143c
      Ville Syrjälä 提交于
      Make sure the cursor gets fully clipped when enabling it on a disabled
      crtc via setplane. This will prevent the lower level code from
      attempting to enable the cursor in hardware.
      
      Cc: Paulo Zanoni <przanoni@gmail.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      1add143c
    • V
      drm/i915: Skip load detect when intel_crtc->new_enable==true · a459249c
      Ville Syrjälä 提交于
      During suspend we turn off the crtcs, but leave the staged config in
      place so that we can restore the display(s) to their previous state on
      resume.
      
      During resume when we attempt to apply the force pipe A quirk we use the
      load detect mechanism. That doesn't check whether there was an already
      staged configuration for the crtc since that's not even possible during
      normal runtime load detection. But during resume it is possible, and if
      we just blindly go and overwrite the staged crtc configuration for the
      load detection we can no longer restore the display to the correct
      state.
      
      Even worse, we don't even clear all the staged connector->encoder->crtc
      links so we may end up using a cloned setup for the load detection, and
      after we're done we just clear the links related to the VGA output
      leaving the links for the other outputs in place. This will eventually
      result in calling intel_set_mode() with mode==NULL but with valid
      connector->encoder->crtc links which will result in dereferencing the
      NULL mode since the code thinks it will have to a modeset.
      
      To avoid these problems don't use any crtc with new_enabled==true for
      load detection.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org (for 3.16)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      a459249c
    • V
      drm/i915: Fix locking for intel_enable_pipe_a() · 208bf9fd
      Ville Syrjälä 提交于
      intel_enable_pipe_a() gets called with all the modeset locks already
      held (by drm_modeset_lock_all()), so trying to grab the same
      locks using another drm_modeset_acquire_ctx is going to fail miserably.
      
      Move most of the drm_modeset_acquire_ctx handling (init/drop/fini)
      out from intel_{get,release}_load_detect_pipe() into the callers
      (intel_{crt,tv}_detect()). Only the actual locking and backoff
      handling is left in intel_get_load_detect_pipe(). And in
      intel_enable_pipe_a() we just share the mode_config.acquire_ctx from
      drm_modeset_lock_all() which is already holding all the relevant locks.
      
      It's perfectly legal to lock the same ww_mutex multiple times using the
      same ww_acquire_ctx. drm_modeset_lock() will convert the returned
      -EALREADY into 0, so the caller doesn't need to do antyhing special.
      
      Fixes a hang on resume on my 830.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      208bf9fd
  7. 15 8月, 2014 1 次提交
  8. 13 8月, 2014 3 次提交