1. 26 10月, 2012 7 次提交
    • P
      drm/i915: add TRANSCODER_EDP · a5c961d1
      Paulo Zanoni 提交于
      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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a5c961d1
    • P
      drm/i915: don't call Haswell PCH code when we can't or don't need · 83616634
      Paulo Zanoni 提交于
      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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      83616634
    • P
      drm/i915: simplify intel_crtc_driving_pch · fc316cbe
      Paulo Zanoni 提交于
      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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      fc316cbe
    • P
      drm/i915: fix checks inside haswell_crtc_{enable, disable} · 1f544388
      Paulo Zanoni 提交于
      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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1f544388
    • P
      drm/i915: fix checks inside ironlake_crtc_{enable, disable} · 20474e90
      Paulo Zanoni 提交于
      The last commit forked a Haswell version, so now we remove Haswell
      code from these functions.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      20474e90
    • P
      drm/i915: fork a Haswell version of ironlake_crtc_{enable, disable} · 4f771f10
      Paulo Zanoni 提交于
      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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4f771f10
    • J
      drm/i915: remove an extra #define for DP_RECEIVER_CAP_SIZE · 051f8663
      Jani Nikula 提交于
      Identical #define is now available in include/drm/drm_dp_helper.h, nuke the
      dupe.
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      051f8663
  2. 24 10月, 2012 6 次提交
  3. 23 10月, 2012 20 次提交
  4. 22 10月, 2012 1 次提交
    • D
      Merge tag 'v3.7-rc2' into drm-intel-next-queued · c2fb7916
      Daniel Vetter 提交于
      Linux 3.7-rc2
      
      Backmerge to solve two ugly conflicts:
      - uapi. We've already added new ioctl definitions for -next. Do I need to say more?
      - wc support gtt ptes. We've had to revert this for snb+ for 3.7 and
        also fix a few other things in the code. Now we know how to make it
        work on snb+, but to avoid losing the other fixes do the backmerge
        first before re-enabling wc gtt ptes on snb+.
      
      And a few other minor things, among them git getting confused in
      intel_dp.c and seemingly causing a conflict out of nothing ...
      
      Conflicts:
      	drivers/gpu/drm/i915/i915_reg.h
      	drivers/gpu/drm/i915/intel_display.c
      	drivers/gpu/drm/i915/intel_dp.c
      	drivers/gpu/drm/i915/intel_modes.c
      	include/drm/i915_drm.h
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c2fb7916
  5. 21 10月, 2012 2 次提交
  6. 20 10月, 2012 4 次提交
新手
引导
客服 返回
顶部