An error occurred fetching the project authors.
  1. 09 Aug, 2012 3 commits
  2. 25 Jul, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: add port parameter to intel_hdmi_init · 08d644ad
      Daniel Vetter authored
      Instead of having a giant if cascade to figure this out according to
      the passed-in register. We could do quite a bit more cleaning up and
      all by using the port at more places, but I think this should be part
      of a bigger rework to introduce a struct intel_digital_port which
      would keep track of all these things. I guess this will be part of
      some haswell-DP-induced refactoring.
      
      For now this rips out the big cascade, which is what annoyed me so
      much.
      
      v2: Add port variable name back for the func decl (I've tried to trick
      myself below the 80 char limit).
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      08d644ad
  3. 05 Jul, 2012 1 commit
  4. 30 May, 2012 1 commit
    • Paulo Zanoni's avatar
      drm/i915: add set_infoframes to struct intel_hdmi · 687f4d06
      Paulo Zanoni authored
      We need a function that is able to fully 'set' the state of the DIP
      registers to a known state.
      
      Currently, we have the write_infoframe function that is called twice:
      once for AVI and once for SPD. The problem is that write_infoframe
      tries to keep the state of the DIP register as it is, changing only
      the minimum necessary bits. The second problem is that
      write_infoframe does twice (once for each time it is called) some
      work that should be done only once (like waiting for vblank and
      setting the port). If we add even more DIPs, it will do even more
      repeated work.
      
      This patch only adds the infrastructure keeping the code behavior the
      same as before.
      
      v2: add static keywords
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      687f4d06
  5. 19 May, 2012 5 commits
    • Eugeni Dodonov's avatar
      drm/i915: prepare HDMI link for Haswell · 72662e10
      Eugeni Dodonov authored
      On Haswell, we need to properly train the DDI buffers prior to enabling
      HDMI, and enable the required clocks with correct dividers for the desired
      frequency.
      
      Also, we cannot simple reuse HDMI routines from previous generations of
      GPU, as most of HDMI-specific stuff is being done via the DDI port
      programming instead of HDMI-specific registers.
      
      This commit take advantage of the WR PLL clock table which is in a
      separate (previous) commit to select the right divisors for each mode.
      Signed-off-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      72662e10
    • Eugeni Dodonov's avatar
      drm/i915: add WR PLL programming table · 12a13a33
      Eugeni Dodonov authored
      This table is used for programming WR PLL clocks, used by HDMI and DVI outputs.
      I split it into a separate patch to simplify the HDMI enabling patch which was
      getting huge.
      
      Note that this table is a temporary solution for WR PLL programming. It
      will be reworked into a more exact algorithm at a later stage. But for
      now, it provides the most accurate clock setting solution, so we use it
      here.
      Signed-off-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      12a13a33
    • Eugeni Dodonov's avatar
      drm/i915: detect digital outputs on Haswell · 0e72a5b5
      Eugeni Dodonov authored
      Digital port detection on Haswell is indicated by the presence of a bit in
      DDI_BUF_CTL for port A, and by a different register for ports B, C and D.
      So we check for those bits during the initialization time and let the hdmi
      function know about those.
      
      Note that this bit does not indicates whether the output is DP or HDMI.
      However, the DDI buffers can be programmed in a way that is shared between
      DP/HDMI and FDI/HDMI except for PORT E.
      
      So for now, we detect those digital outputs as being HDMI, but proper DP
      support is still pending.
      
      Note that DDI A can only drive eDP, so we do not handle it here for hdmi
      initialization.
      
      v2: simplify Haswell handling logic
      
      v3: use generic function for handling digital outputs.
      Signed-off-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0e72a5b5
    • Eugeni Dodonov's avatar
      drm/i915: support DDI training in FDI mode · c82e4d26
      Eugeni Dodonov authored
      Starting with Haswell, DDI ports can work in FDI mode to support
      connectivity with the outputs located on the PCH.
      
      This commit adds support for such connections in the intel_ddi module, and
      provides Haswell-specific functionality to make it work.
      
      v2: simplify the commit as per Daniel Vetter suggestion.
      Signed-off-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c82e4d26
    • Eugeni Dodonov's avatar
      drm/i915: initialize DDI buffer translations · 45244b87
      Eugeni Dodonov authored
      DDI is introduced starting with Haswell GPU generation. So to simplify its
      management in the future, we also add intel_ddi.c to hold all the
      DDI-related items.
      
      Buffer translations for DDI links must be initialized prior to enablement.
      For FDI and DP, first 9 pairs of values are used to select the connection
      parameters. HDMI uses the last pair of values and ignores the first 9
      pairs. So we program HDMI values in both cases, which allows HDMI to work
      over both FDI and DP-friendly buffers.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      45244b87