1. 18 4月, 2013 3 次提交
  2. 06 4月, 2013 2 次提交
    • D
      drm/i915: revert eDP bpp clamping code changes · 57c21963
      Daniel Vetter 提交于
      The behaviour around handling the eDP bpp value from vbt has been
      slightly changed in
      
      commit 36008365
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Wed Mar 27 00:44:59 2013 +0100
      
          drm/i915: convert DP autodither code to new infrastructure
      
      The old behaviour was that we used the plane's bpp (usually 24bpp) for
      computing the dp link bw, but set up the pipe with the bpp value from
      vbt if available. This takes the vbt bpp override into account even
      for the dp link bw configuration.
      
      On Paulo's hsw machine this resulted in a slower link clock and a
      black screen - but the mode actually /should/ fit even with the lower
      clock. Until we've cleared up simply stay bug-for-bug compatible with
      the old code.
      
      While at it, also restore a debug message lost in:
      
      commit 4e53c2e0
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Wed Mar 27 00:44:58 2013 +0100
      
          drm/i915: precompute pipe bpp before touching the hw
      
      Cc: Paulo Zanoni <przanoni@gmail.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      57c21963
    • D
      Revert "drm/i915: fix DP get_hw_state return value" · 2af8898b
      Daniel Vetter 提交于
      This reverts commit deb18211.
      
      It completely breaks the logic, since when we fall through to the end
      of the function we actually _have_ figured out the correct pipe.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2af8898b
  3. 03 4月, 2013 7 次提交
  4. 28 3月, 2013 5 次提交
  5. 27 3月, 2013 1 次提交
  6. 23 3月, 2013 1 次提交
  7. 18 3月, 2013 2 次提交
    • T
      drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n() · 9d1a455b
      Takashi Iwai 提交于
      The eDP output on HP Z1 is still broken when X is started even after
      fixing the infinite link-train loop.  The regression was introduced in
      3.6 kernel for cleaning up the mode clock handling code in intel_dp.c
      by the commit [71244653: drm/i915: adjusted_mode->clock in the dp
      mode_fix].
      
      In the past, the clock of the reference mode was modified in
      intel_dp_mode_fixup() in the case of eDP fixed clock, and this clock was
      used for calculating in intel_dp_set_m_n().  This override was removed,
      thus the wrong mode clock is used for the calculation, resulting in a
      psychedelic smoking output in the end.
      
      This patch corrects the clock to be used in the place.
      
      v1->v2: Use intel_edp_target_clock() for checking eDP fixed clock
      instead of open code as in ironlake_set_m_n().
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9d1a455b
    • T
      Revert "drm/i915: try to train DP even harder" · 3b4f819d
      Takashi Iwai 提交于
      This reverts commit 0d710688.
      
      Not only that the commit introduces a bogus check (voltage_tries == 5
      will never meet at the inserted code path), it brings the i915 driver
      into an endless dp-train loop on HP Z1 desktop machine with IVY+eDP.
      
      At least reverting this commit recovers the framebuffer (but X is
      still broken by other reasons...)
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3b4f819d
  8. 07 3月, 2013 2 次提交
  9. 04 3月, 2013 1 次提交
  10. 22 2月, 2013 1 次提交
  11. 20 2月, 2013 3 次提交
  12. 15 2月, 2013 1 次提交
  13. 14 2月, 2013 1 次提交
  14. 31 1月, 2013 1 次提交
  15. 25 1月, 2013 1 次提交
  16. 21 1月, 2013 1 次提交
    • D
      drm/i915: use drm_modeset_lock_all · a0e99e68
      Daniel Vetter 提交于
      Two exceptions:
      - debugfs files only read information which is not related to crtc, so
        can stay on the modeset_config lock.
      - Same holds for the edp vdd work in intel_dp.c. Add a corresponding
        WARN_ON and a comment next to the intel_dp struct fields for
        documentation.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a0e99e68
  17. 20 1月, 2013 2 次提交
    • V
      drm/i915: Add "Automatic" mode for the "Broadcast RGB" property · 55bc60db
      Ville Syrjälä 提交于
      Add a new "Automatic" mode to the "Broadcast RGB" range property.
      When selected the driver automagically selects between full range and
      limited range output.
      
      Based on CEA-861 [1] guidelines, limited range output is selected if the
      mode is a CEA mode, except 640x480. Otherwise full range output is used.
      Additionally DVI monitors should most likely default to full range
      always.
      
      As per DP1.2a [2] DisplayPort should always use full range for 18bpp, and
      otherwise will follow CEA-861 rules.
      
      NOTE: The default value for the property will now be "Automatic"
      so some people may be affected in case they're relying on the
      current full range default.
      
      [1] CEA-861-E - 5.1 Default Encoding Parameters
      [2] VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
      
      v2: Use has_hdmi_sink to check if a HDMI monitor is present
      v3: Add information about relevant spec chapters
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      55bc60db
    • V
      drm/i915: Fix RGB color range property for PCH platforms · 3685a8f3
      Ville Syrjälä 提交于
      The RGB color range select bit on the DP/SDVO/HDMI registers
      disappeared when PCH was introduced, and instead a new PIPECONF bit
      was added that performs the same function.
      
      Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
      it in the encoder mode_fixup if limited color range is requested.
      Set the the PIPECONF bit 13 based on the flag.
      
      Experimentation showed that simply toggling the bit while the pipe is
      active doesn't work. We need to restart the pipe, which luckily already
      happens.
      
      The DP/SDVO/HDMI bit 8 is marked MBZ in the docs, so avoid setting it,
      although it doesn't seem to do any harm in practice.
      
      TODO:
      - the PIPECONF bit too seems to have disappeared from HSW. Need a
        volunteer to test if it's just a documentation issue or if it's really
        gone. If the bit is gone and no easy replacement is found, then I suppose
        we may need to use the pipe CSC unit to perform the range compression.
      
      v2: Use mode private_flags instead of intel_encoder virtual functions
      v3: Moved the intel_dp color_range handling after bpc check to help
          later patches
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3685a8f3
  18. 16 1月, 2013 1 次提交
  19. 21 12月, 2012 1 次提交
  20. 17 12月, 2012 1 次提交
  21. 14 12月, 2012 2 次提交