1. 26 Oct, 2012 9 commits
    • Paulo Zanoni's avatar
      drm/i915: convert DDI_FUNC_CTL to transcoder · ad80a810
      Paulo Zanoni authored
      Because there's one instance of the register per CPU transcoder and
      not per CPU pipe. This is another register that appeared for the first
      time on Haswell, and even though its Haswell name is
      PIPE_DDI_FUNC_CTL, it will be renamed to TRANS_DDI_FUNC_CTL, so let's
      just use the new naming scheme before it confuses more people.
      
      Notice that there's a big improvement on intel_ddi_get_hw_state due to
      the new TRANSCODER_EDP.
      
      V2: Also rename the register to TRANS_DDI_FUNC_CTL as suggested by
      Damien Lespiau.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ad80a810
    • Paulo Zanoni's avatar
      drm/i915: convert PIPE_CLK_SEL to transcoder · bb523fc0
      Paulo Zanoni authored
      This register appeared in Haswell. It does not have an EDP version
      because the EDP transcoder is always tied to the DDIA clock. Notice
      that if we call PIPE_CLK_SEL(pipe) when pipe is PIPE_A and transcoder
      is TRANSCODER_EDP we might introduce a bug, that's why this is a
      transcoder register even though it does not have an EDP version.
      
      Even though Haswell names this register PIPE_CLK_SEL, it will be
      renamed to TRANS_CLK_SEL in the future, so let's just start using the
      real name that makes more sense and avoids misusage.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      bb523fc0
    • Paulo Zanoni's avatar
      drm/i915: add TRANSCODER_EDP · a5c961d1
      Paulo Zanoni authored
      Before Haswell we used to have the CPU pipes and the PCH transcoders.
      We had the same amount of pipes and transcoders, and there was a 1:1
      mapping between them. After Haswell what we used to call CPU pipe was
      split into CPU pipe and CPU transcoder. So now we have 3 CPU pipes (A,
      B and C), 4 CPU transcoders (A, B, C and EDP) and 1 PCH transcoder
      (only used for VGA).
      
      For all the outputs except for EDP we have an 1:1 mapping on the CPU
      pipes and CPU transcoders, so if you're using CPU pipe A you have to
      use CPU transcoder A. When have an eDP output you have to use
      transcoder EDP and you can attach this CPU transcoder to any of the 3
      CPU pipes. When using VGA you need to select a pair of matching CPU
      pipes/transcoders (A/A, B/B, C/C) and you also need to enable/use the
      PCH transcoder.
      
      For now we're just creating the cpu_transcoder definitions and setting
      cpu_transcoder to TRANSCODER_EDP on DDI eDP code, but none of the
      registers was ported to use transcoder instead of pipe. The goal is to
      keep the code backwards-compatible since on all cases except when
      using eDP we must have pipe == cpu_transcoder.
      
      V2: Comment the haswell_crtc_off chunk, suggested by Damien Lespiau
      and Daniel Vetter.
      
      We currently need the haswell_crtc_off chunk because TRANSCODER_EDP
      can be used by any CRTC, so when you stop using it you have to stop
      saying you're using it, otherwise you may have at some point 2 CRTCs
      claiming they're using TRANSCODER_EDP (a disabled CRTC and an enabled
      one), then the HW state readout code will get completely confused.
      
      In other words:
      
      Imagine the following case:
        xrandr --output eDP1 --auto --crtc 0
        xrandr --output eDP1 --off
        xrandr --output eDP1 --auto --crtc 2
      
      After the last command you could get a "pipe A assertion failure
      (expected off, current on)" because CRTC 0 still claims it's using
      TRANSCODER_EDP, so the HW state readout function will read it
      (through PIPECONF) and expect it to be off, when it's actually on
      because it's being used by CRTC 2.
      
      So when we make "intel_crtc->cpu_transcoder = intel_crtc->pipe" we
      make sure we're pointing to our own original CRTC which is certainly
      not used by any other CRTC.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a5c961d1
    • Paulo Zanoni's avatar
      drm/i915: don't call Haswell PCH code when we can't or don't need · 83616634
      Paulo Zanoni authored
      On Ironlake we have one PCH transcoder and FDI per pipe, so we know
      that if ironlake_crtc_driving_pch returns false we can disable the PCH
      transcoder and we also know that when we disable the crtc we can also
      disable the PCH transcoder.
      
      On Haswell there is only 1 PCH transcoder and FDI and they can be used
      by any CRTC. So if for one specific crtc haswell_crtc_driving_pch
      returns false we can't assert anything about the state of the PCH
      transcoder or the FDI link without checking if any other CRTC is using
      the PCH.
      
      So on this commit remove the "assert_fdi_{t,r}x_disabled" form
      haswell_crtc_enable and also only disable FDI and the PCH transcoder
      if the port being disabled was actually a PCH port (we only have one
      port using PCH: the VGA port).
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      83616634
    • Paulo Zanoni's avatar
      drm/i915: simplify intel_crtc_driving_pch · fc316cbe
      Paulo Zanoni authored
      By forking Ironlake and Haswell functions. The only callers are
      {ironlake,haswell}_crtc_enable anyway, and this way we won't need to
      add other checks on the Haswell version for the next gens.
      
      V2: Even simpler, as pointed by Jani Nikula.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      fc316cbe
    • Paulo Zanoni's avatar
      drm/i915: fix checks inside haswell_crtc_{enable, disable} · 1f544388
      Paulo Zanoni authored
      These functions were forked from their Ironlake versions, so now fix
      the gen checks to reflect the fact that they will only run on Haswell.
      
      It is worth noticing that we are not considering IBX/CPT possible on
      Haswell anymore. So far on Haswell enablement we kept trying to still
      consider IBX/CPT as a possibility with a Haswell CPU, but this was
      never tested, I really doubt it will work with the current code and we
      don't really have plans to support it. Future patches will remove the
      IBX/CPT code from other Haswell functions. Notice that we still have a
      WARN on haswell_crtc_mode_set in case we detect non-LPT PCH.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1f544388
    • Paulo Zanoni's avatar
      drm/i915: fix checks inside ironlake_crtc_{enable, disable} · 20474e90
      Paulo Zanoni authored
      The last commit forked a Haswell version, so now we remove Haswell
      code from these functions.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      20474e90
    • Paulo Zanoni's avatar
      drm/i915: fork a Haswell version of ironlake_crtc_{enable, disable} · 4f771f10
      Paulo Zanoni authored
      The way we enable and disable the PCH on Haswell changed considerably
      since now we have only one PCH transcoder, so we can't keep the same
      asserts and we also can't just unconditionally disable the PCH
      transcoder for non-PCH outputs. So let's fork a Haswell version.
      
      These new functions look exactly the same as the ironlake versions.
      The next patches will introduce the differences.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@gmail.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4f771f10
    • Jani Nikula's avatar
      drm/i915: remove an extra #define for DP_RECEIVER_CAP_SIZE · 051f8663
      Jani Nikula authored
      Identical #define is now available in include/drm/drm_dp_helper.h, nuke the
      dupe.
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      051f8663
  2. 24 Oct, 2012 4 commits
  3. 23 Oct, 2012 3 commits
    • Daniel Vetter's avatar
      drm/i915: make edp panel power sequence setup more robust · 82ed61fa
      Daniel Vetter authored
      3 changes:
      - If a given value is unset, use the maximal limits from the eDP spec.
      - Write back the new values, since otherwise the panel power sequencing
        hw will not dtrt.
      - Revert the early bail-out in case the register values are unset.
      
      The last change reverts
      
      commit bfa3384a
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Tue Apr 10 11:58:04 2012 -0700
      
          drm/i915: check PPS regs for sanity when using eDP
      
      v2:
      - Unlock the PP regs as the very first thing. This is a required w/a
        for cpu eDP on port A, and generally a good idea.
      - Fixup the panel power control port selection bits.
      
      v3: Paulo Zanoni noticed that I've fumbled the computation of the spec
      limit values. Fix them up. We've also noticed that the t8/t9 values in
      the vbt/bios-programmed pp are much larger than any limits. My guess
      is that this is to conceal any backlight enable/disable delays. So by
      using the much shorter limits from the spec, which only concerns the
      sink, we risk that we might display before the backlight is fully on,
      or disable the output while the backlight still has afterglow. I've
      figured I don't care too much, since this will only happen when both
      the pp regs are not programmed, and the vbt tables don't contain
      anything useful.
      
      v4: Don't set the port selection bits on hsw/LPT, they don't exist any
      more.
      
      v5: Fixup spelling issues in comments, as noticed by Jesse Barnes.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Tested-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      82ed61fa
    • Damien Lespiau's avatar
      drm/i915: Don't try to use SPR_SCALE when we don't have a sprite scaler · 2d354c34
      Damien Lespiau authored
      Haswell does not have a scaler in the sprite pipeline anymore, so let's
      ensure:
        1/ We bail out of update_plate() when someone is trying to ask to
           display a scaled framebuffer,
        2/ We never write to the nonexistent SPR_SCALE register
      
      v2: Smash in the fixup from Damien in the disable_plane function.
      
      Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (for v1)
      Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (for v1)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2d354c34
    • Daniel Vetter's avatar
      drm/i915/dp: actually nack test request · 9324cf7f
      Daniel Vetter authored
      ... like the comment says. No idea whether this has any effect, but
      I guess it's better to not lie to the display by acking a test request
      and never following through with it. This goes back to the commit that
      originally introduced this code:
      
      commit a60f0e38
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Thu Oct 20 15:09:17 2011 -0700
      
          drm/i915: add DP test request handling
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Meh'ed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9324cf7f
  4. 22 Oct, 2012 20 commits
  5. 20 Oct, 2012 4 commits