1. 24 10月, 2014 3 次提交
  2. 16 10月, 2014 1 次提交
    • V
      drm/i915: Don't trust the DP_DETECT bit for eDP ports on CHV · e17ac6db
      Ville Syrjälä 提交于
      On CHV the display DDC pins may be muxed to an alternate function if
      there's no need for DDC on a specific port, which is the case for eDP
      ports since there's no way to plug in a DP++ HDMI dongle.
      
      This causes problems when trying to determine if the port is present
      since the the DP_DETECTED bit is the latched state of the DDC SDA pin
      at boot. If the DDC pins are muxed to an alternate function the bit
      may indicate that the port isn't present.
      
      To work around this look at the VBT as well as the DP_DETECTED bit
      to determine if we should attempt registering an eDP port. Do this
      only for ports B and C since port D doesn't support eDP (no PPS/BLC).
      
      In theory someone could also wire up a normal DP port w/o DDC lines.
      That would just mean that simple DP++ HDMI dongles wouldn't work
      on such a port. With this change we would still fail to register
      such DP ports. But let's hope no one wires their board in such a way,
      and if they do we can extend the VBT checks to cover normal DP ports
      as well.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84265Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      e17ac6db
  3. 06 10月, 2014 1 次提交
  4. 03 10月, 2014 1 次提交
  5. 01 10月, 2014 4 次提交
  6. 29 9月, 2014 1 次提交
  7. 24 9月, 2014 7 次提交
  8. 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
  9. 19 9月, 2014 15 次提交
  10. 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
  11. 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
  12. 03 9月, 2014 3 次提交