1. 10 May, 2013 5 commits
  2. 06 May, 2013 12 commits
  3. 03 May, 2013 2 commits
  4. 02 May, 2013 1 commit
  5. 30 Apr, 2013 15 commits
  6. 29 Apr, 2013 5 commits
    • Daniel Vetter's avatar
      drm/i915: hw state readout support for pipe timings · 1bd1bd80
      Daniel Vetter authored
      This does duplicate the logic in intel_crtc_mode_get a bit, but the
      issue is that we also should handle interlace modes and other insanity
      correctly.
      
      Hence I've opted for a sligthly more elaborate route where we first
      read out the crtc timings for the adjusted mode, and then optionally
      (not sure if we really need it) compute the modeline from that.
      
      v2: Also read out the pipe source dimensions into the requested mode.
      
      v3: Rebase on top of the moved cpu_transcoder.
      
      v4: Simplify CHECK_FLAGS logic as suggested by Chris Wilson. Also
      properly #undef that macro again.
      
      Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (v3)
      [danvet: Use the existing mask for interlaced bits, spotted by Mika.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1bd1bd80
    • Daniel Vetter's avatar
      drm/i915: hw state readout support for fdi m/n · 72419203
      Daniel Vetter authored
      We want to use the fdi m/n values to easily compute the adjusted mode
      dotclock on pch ports. Hence make sure the values stored in the pipe
      config are always reliable.
      
      v2: Fixup FDI TU readout.
      
      v3: Rebase on top of moved cpu_transcoder.
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      72419203
    • Daniel Vetter's avatar
      drm/i915: introduce macros to check pipe config properties · 08a24034
      Daniel Vetter authored
      This code will get _really_ repetive, and we'll end up with tons more
      of this kind. So extract the common patterns.
      
      This should also help when we add a lazy pipe_config compare mode for
      fastboot.
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      08a24034
    • Daniel Vetter's avatar
      drm/i915: stop for_each_intel_crtc_masked macro from leaking · 0973f18f
      Daniel Vetter authored
      Spotted while changing related code.
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0973f18f
    • Daniel Vetter's avatar
      drm/i915: implement fdi auto-dithering · e29c22c0
      Daniel Vetter authored
      So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw
      VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit
      into this, among them the default 1080p mode.
      
      The solution is to dither down the pipe a bit so that everything fits,
      which this patch implements.
      
      But ports compute their state under the assumption that the bpp they
      pick will be the one selected, e.g. the display port bw computations
      won't work otherwise. Now we could adjust our code to again up-dither
      to the computed DP link parameters, but that's pointless.
      
      So instead when the pipe needs to adjust parameters we need to retry
      the pipe_config computation at the encoder stage. Furthermore we need
      to inform encoders that they should not increase bandwidth
      requirements if possible. This is required for the hdmi code, which
      prefers the pipe to up-dither to either of the two possible hdmi bpc
      values.
      
      LVDS has a similar requirement, although that's probably only
      theoretical in nature: It's unlikely that we'll ever see an 8bpc
      high-res lvds panel (which is required to hit the 2 fdi lane limit).
      
      eDP is the only thing which could increase the pipe_bpp setting again,
      even when in the retry-loop. This could hit the WARN. Two reasons for
      not bothering:
      - On many eDP panels we'll get a black screen if the bpp settings
        don't match vbt. So failing the modeset is the right thing to do.
        But since that also means it's the only way to light up the panel,
        it should work. So we shouldn't be able to hit this WARN.
      - There are still opens around the eDP panel handling, and maybe we
        need additional tricks. Before that happens it's imo no use trying
        to be too clever.
      Worst case we just need to kill that WARN or maybe fail the compute
      config stage if the eDP connector can't get the bpp setting it wants.
      And since this can only happen with an fdi link in between and so for
      pch eDP panels it's rather unlikely to blow up, if ever.
      
      v2: Rebased on top of a bikeshed from Paulo.
      
      v3: Improve commit message around eDP handling with the stuff
      things with Imre.
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e29c22c0