1. 20 2月, 2013 5 次提交
    • V
      drm/i915: Implement pipe CSC based limited range RGB output · 86d3efce
      Ville Syrjälä 提交于
      HSW no longer has the PIPECONF bit for limited range RGB output.
      Instead the pipe CSC unit must be used to perform that task.
      
      The CSC pre offset are set to 0, since the incoming data is full
      [0:255] range RGB, the coefficients are programmed to compress the
      data into [0:219] range, and then we use either the CSC_MODE black
      screen offset bit, or the CSC post offsets to shift the data to
      the correct [16:235] range.
      
      Also have to change the confiuration of all planes so that the
      data is sent through the pipe CSC unit. For simplicity send the
      plane data through the pipe CSC unit always, and in case full
      range output is requested, the pipe CSC unit is set up with an
      identity transform to pass the plane data through unchanged.
      
      I've been told by some hardware people that the use of the pipe
      CSC unit shouldn't result in any measurable increase in power
      consumption numbers.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      86d3efce
    • V
      drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+ · b9e1faa7
      Ville Syrjälä 提交于
      The bit controlling whether PIPE_CONTROL DW/QW write targets
      the global GTT or PPGTT moved moved from DW 2 bit 2 to
      DW 1 bit 24 on IVB.
      
      I verified on IVB that the fix is in fact effective. Without the fix
      none of the scratch writes actually landed in the pipe control page.
      With the fix the writes show up correctly.
      
      v2: move PIPE_CONTROL_GLOBAL_GTT_IVB setup to where other flags are set
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b9e1faa7
    • D
      drm/i915: Preserve the DDI link reversal configuration · 876a8cdf
      Damien Lespiau 提交于
      Similarly to:
      
        commit 6a0d1df3d3a0d2370541164eb0595fe35dcd6de3
        Author: Damien Lespiau <damien.lespiau@intel.com>
        Date:   Tue Dec 11 15:18:28 2012 +0000
      
            drm/i915: Preserve the FDI line reversal override bit on CPT
      
      DDI port support lane reversal to easy the PCB layouting work. Let's
      preserve the bit configured by the BIOS (until we find how to correctly
      retrieve the information from the VBT, but this does sound more fragile
      then just relying on the BIOS that has, hopefully, been validated
      already.
      Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      876a8cdf
    • D
      drm/i915: Preserve the FDI line reversal override bit on CPT · 3e68320e
      Damien Lespiau 提交于
      The FDI link has supported link reversal to make the PCB layout
      engineer's life easier for quite a while and we have always presered
      this bit as we programmed FDI_RX_CTL with a read/modify/write sequence.
      
      We're trying to take a bit more control over what the BIOS leaves in
      various register and with the introduction of DDI, started to program
      FDI_RX_CTL fully.
      
      There's a fused bit to indicate DMI link reversal and FDI defaults to
      mirroring that configuration. We have a bit to override that behaviour
      that we need to preserve from the BIOS.
      Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3e68320e
    • D
      drm/i915: detect wrong MCH watermark values · 1d7aaa0c
      Daniel Vetter 提交于
      Some early bios versions seem to ship with the wrong tuning values for
      the MCH, possible resulting in pipe underruns under load. Especially
      on DP outputs this can lead to black screen, since DP really doesn't
      like an occasional whack from an underrun.
      
      Unfortunately the registers seem to be locked after boot, so the only
      thing we can do is politely point out issues and suggest a BIOS
      upgrade.
      
      Arthur Runyan pointed us at this issue while discussion DP bugs - thus
      far no confirmation from a bug report yet that it helps. But at least
      some of my machines here have wrong values, so this might be useful in
      understanding bug reports.
      
      v2: After a bit more discussion with Art and Ben we've decided to only
      the check the watermark values, since the OREF ones could be be a
      notch more aggressive on certain machines.
      
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Cc: Runyan, Arthur J <arthur.j.runyan@intel.com>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1d7aaa0c
  2. 15 2月, 2013 1 次提交
  3. 14 2月, 2013 1 次提交
    • B
      drm/i915: Fix RC6VIDS encode/decode · 7083e050
      Ben Widawsky 提交于
      The RC6 VIDS has a linear ramp starting at 250mv, which means any values
      below 250 are invalid. The old buggy macros tried to adjust for this to
      be more flexible, but there is no need. As Dan pointed out the ENCODE
      only ever has one value. The only invalid value for decode is an input
      of 0 which means something is really wonky, and the cases where DECODE
      are used either don't matter (debug values), or would be implicitly
      correct (the check for less than 450).
      
      This patch makes simpler, easier to read macros which are actually
      correct. Maybe this patch can actually fix some bugs now.
      
      Thanks to Dan for catching this. /me hides
      
      Cc: stable@kernel.org
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7083e050
  4. 31 1月, 2013 2 次提交
  5. 28 1月, 2013 1 次提交
  6. 27 1月, 2013 4 次提交
  7. 25 1月, 2013 18 次提交
  8. 23 1月, 2013 1 次提交
  9. 20 1月, 2013 1 次提交
    • 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
  10. 18 1月, 2013 1 次提交
  11. 15 1月, 2013 1 次提交
  12. 18 12月, 2012 1 次提交
  13. 17 12月, 2012 2 次提交
  14. 14 12月, 2012 1 次提交