1. 11 2月, 2012 1 次提交
    • D
      drm/i915: fixup interlaced vertical timings confusion, part 1 · ca9bfa7e
      Daniel Vetter 提交于
      We have a pretty decent confusion about vertical timings of interlaced
      modes. Peter Ross has written a patch that makes interlace modes work
      on a lot more platforms/output combinations by doubling the vertical
      timings.
      
      The issue with that patch is that core drm _does_ support specifying
      whether we want these vertical timings in fields or frames, we just
      haven't managed to consistently use this facility. The relavant
      function is drm_mode_set_crtcinfo, which fills in the crtc timing
      information.
      
      The first thing to note is that the drm core keeps interlaced modes in
      frames, but displays modelines in fields. So when the crtc modeset
      helper copies over the mode into adjusted_mode it will already contain
      vertical timings in half-frames. The result is that the fixup code in
      intel_crtc_mode_fixup doesn't actually do anything (in most cases at
      least).
      
      Now gen3+ natively supports interlaced modes and wants the vertical
      timings in frames. Which is what sdvo already fixes up, at least under
      some conditions.
      
      There are a few other place that demand vertical timings in fields
      but never actually deal with interlaced modes, so use frame timings
      for consistency, too. These are:
      - lvds panel,
      - dvo encoders - dvo is the only way gen2 could support interlaced
        mode, but currently we don't support any encoders that do.
      - tv out - despite that the tv dac sends out an interlaced signal it
        expects a progressive mode pipe configuration.
      All these encoders enforce progressive modes by resetting
      interlace_allowed.
      
      Hence we always want crtc vertical timings in frames. Enforce this in
      our crtc mode_fixup function and rip out any redudant timing
      computations from the encoders' mode_fixup function.
      
      v2-4: Adjust the vertical timings a bit.
      
      v5: Split out the 'subtract-one for interlaced' fixes.
      
      v6: Clarify issues around tv-out and gen2.
      Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Tested-by: NChristopher Egert <cme3000@gmail.com>
      Tested-by: NAlfonso Fiore <alfonso.fiore@gmail.com>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ca9bfa7e
  2. 07 1月, 2012 2 次提交
  3. 20 9月, 2011 1 次提交
  4. 14 7月, 2011 2 次提交
  5. 11 5月, 2011 2 次提交
  6. 13 4月, 2011 3 次提交
  7. 11 2月, 2011 1 次提交
  8. 08 2月, 2011 1 次提交
  9. 05 12月, 2010 1 次提交
  10. 23 9月, 2010 1 次提交
  11. 21 9月, 2010 1 次提交
  12. 14 9月, 2010 1 次提交
  13. 13 9月, 2010 1 次提交
  14. 12 9月, 2010 1 次提交
  15. 10 9月, 2010 2 次提交
  16. 08 9月, 2010 4 次提交
  17. 07 9月, 2010 1 次提交
  18. 22 8月, 2010 1 次提交
  19. 10 8月, 2010 1 次提交
  20. 02 8月, 2010 2 次提交
  21. 20 7月, 2010 1 次提交
  22. 20 4月, 2010 1 次提交
  23. 13 4月, 2010 2 次提交
  24. 10 4月, 2010 2 次提交
  25. 26 3月, 2010 1 次提交
    • E
      drm/i915: Rename intel_output to intel_encoder. · 21d40d37
      Eric Anholt 提交于
      The intel_output naming is inherited from the UMS code, which had a
      structure of screen -> CRTC -> output.  The DRM code has an additional
      notion of encoder/connector, so the structure is screen -> CRTC ->
      encoder -> connector.  This is a useful structure for SDVO encoders
      which can support multiple connectors (each of which requires
      different programming in the one encoder and could be connected to
      different CRTCs), or for DVI-I, where multiple encoders feed into the
      connector for whether it's used for digital or analog.  Most of our
      code is encoder-related, so transition it to talking about encoders
      before we start trying to distinguish connectors.
      
      This patch is produced by sed s/intel_output/intel_encoder/ over the
      driver.
      Signed-off-by: NEric Anholt <eric@anholt.net>
      21d40d37
  26. 08 1月, 2010 1 次提交
  27. 17 12月, 2009 1 次提交
  28. 02 12月, 2009 1 次提交