1. 06 May, 2013 7 commits
  2. 03 May, 2013 2 commits
  3. 02 May, 2013 1 commit
  4. 30 Apr, 2013 15 commits
  5. 29 Apr, 2013 15 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
    • Daniel Vetter's avatar
      drm/i915: fixup 12bpc hdmi dotclock handling · 325b9d04
      Daniel Vetter authored
      We need to multiply the hdmi port dotclock by 1.5x since it's not
      really a dotclock, but the 10/8 encoding bitclock divided by 10.
      
      Also add correct limit checks for the dotclock and reject modes which
      don't fit. HDMI 1.4 would allow more, but our hw doesn't support that
      unfortunately :(
      
      Somehow I suspect 12bpc hdmi output never really worked - we really
      need an i-g-t testcase to check all the different pixel modes and
      outputs.
      
      v2: Fixup the adjusted port clock handling - we need to make sure that
      the fdi link code still gets the real pixelclock.
      
      v3: g4x/vlv don't support 12bpc hdmi output so drop the bogus comment.
      Acked-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      [danvet: Switch dotclock limit check to <= as suggested by Ville.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      325b9d04
    • Daniel Vetter's avatar
      drm/i915: don't count cpu ports for fdi B/C lane sharing · 1e833f40
      Daniel Vetter authored
      This allows us to use all 4 fdi lanes on fdi B when the cpu eDP is
      running on pipe C. Yay!
      
      v2: Encapsulate test into a little helper function, as suggested by
      Chris Wilson.
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1e833f40
    • Daniel Vetter's avatar
      drm/i915: move fdi lane configuration checks ahead · 1857e1da
      Daniel Vetter authored
      This nicely allows us to drop some hacks which have only been used
      to work around modeset failures due to lack of fdi lanes.
      
      v2: Implement proper checking for Haswell platforms - the fdi link to
      the LPT PCH has only 2 lanes. Note that we already filter out
      impossible modes in intel_crt_mode_valid. Unfortunately LPT does not
      support 6bpc on the fdi rx, so we can't pull clever tricks to squeeze
      in a few more modes.
      
      v2: Rebased on top of Ben Widawsky's num_pipes reorg.
      
      v3: Rebase on top of Ville's pipe debug output ocd rampage.
      
      v4: Fixup rebase fail spotted by Ville.
      
      v5: Fixup rebase fail spotted by Imre Deak. I suck.
      
      Cc: Imre Deak <imre.deak@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1857e1da
    • Daniel Vetter's avatar
      drm/i915: Split up ironlake_check_fdi_lanes · ebfd86fd
      Daniel Vetter authored
      Again in preparation to move the configuration checks into the
      pipe_config computation stage of the modeset sequence.
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ebfd86fd
    • Daniel Vetter's avatar
      drm/i915: compute fdi lane config earlier · 877d48d5
      Daniel Vetter authored
      Now that it's split up, we can easily move it around and precompute
      the fdi lane configuration.
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      877d48d5
    • Daniel Vetter's avatar
      drm/i915: split up fdi_set_m_n into computation and hw setup · ca3a0ff8
      Daniel Vetter authored
      And also move the computed m_n values into the pipe_config. This is a
      prep step to move the fdi state computation completely into the
      prepare phase of the modeset sequence. Which will allow us to handle
      fdi link bw constraints in a better way.
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ca3a0ff8
    • Daniel Vetter's avatar
      drm/i915: hw state readout support for pipe_config->fdi_lanes · 627eb5a3
      Daniel Vetter authored
      v2: Introduce some nice #defines for the FDI lane width fields and put
      them to good use. Suggested by Ville.
      
      v3: Fixup the mask vs. shift copy&pasta fail Imre Deak spotted, and
      use the shift #define also in the mask.
      
      Cc: Imre Deak <imre.deak@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      627eb5a3
    • Daniel Vetter's avatar
      drm/i915: move intel_crtc->fdi_lanes to pipe_config · 33d29b14
      Daniel Vetter authored
      We need this for two reasons:
      - Correct handling of shared fdi lanes on ivb with fastboot.
      - Handling fdi link bw limits when we only have two fdi lanes by
        dithering down a bit.
      
      Just search&replace in this patch, no functional change at all.
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      33d29b14
    • Daniel Vetter's avatar
      drm/i915: allow high-bpc modes on DP · 52541e30
      Daniel Vetter authored
      Totally untested due to lack of screens supporting more than 8bpc. But
      now we should have closed all holes in our bpp handling, so this
      should be safe. The last missing piece was 10bpc support for g4x/vlv,
      since we directly use the pipe bpp to feed the display link (and
      anyway, only the cpt has any means to have a pipe bpp != the display
      link bpp).
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      52541e30
    • Daniel Vetter's avatar
      drm/i915: implement high-bpc + pipeconf-dither support for g4x/vlv · ff9ce46e
      Daniel Vetter authored
      The current code is rather ... ugly. The only thing it managed to pull
      off is getting 6bpc on DP working on g4x. Then someone added another
      custom hack for 6bpc eDP on vlv. Fix up this entire mess by properly
      implementing the PIPECONF-based dither/bpc controls on g4x/vlv.
      
      Note that compared to pch based platforms g4x/vlv don't support 12bpc
      modes. g4x is already caught, extend the check for vlv.
      
      The other fixup is to restrict the lvds-specific dithering to early
      gen4 devices - g4x should use the pipeconf dither controls. Note that
      on gen2/3 the dither control is in the panel fitter even.
      
      v2: Don't enable dithering when the pipe is in 10 bpc mode. Quoting
      from Bspec "PIPEACONF - Pipe A Configuration Register, bit 4":
      
      "Programming note: Dithering should only be enabled for 8 bpc or 6
      bpc."
      
      v3: Actually drop the old ugly dither code.
      
      v4: Explain in a short comment why g4x/vlv shouldn't dither for 30 bpp
      pipes (Jesse).
      
      v5: Also clear the dither type correctly as spotted by Ville.
      
      v6: As Ville pointed out we need to indeed set the dithering both in
      the pipeconf register (for DP outputs) and in the LVDS port register
      (for LVDS ouputs). Otherwise LVDS panel will not get properly
      dithered. The old patch got away with this since it forgot to clear
      the LVDS dither bit ...
      
      v7: Remove redundant BPC_MASK clearing, spotted by Ville.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ff9ce46e