1. 30 May, 2012 8 commits
    • Paulo Zanoni's avatar
      drm/i915: don't write 0 to DIP control at HDMI init · 9d32d165
      Paulo Zanoni authored
      At this time, the HDMI port is enabled, and the DIP control register
      specification says we need to disable the port *before* disabling the
      DIPs. Also, while doing this we risk telling the HW to send the AVI
      DIPs once (not every VSync), which really seems to confuse the HW and
      trigger bugs where the DIPs are not sent.
      
      This code was here just to set the DIP register to a 'known state'
      before using it, but since now the set_infoframes functions already
      set the control registers to a known state, this code can go away.
      
      Also, the previous code disables *all* the DIP registers for *each*
      HDMI port, so we end disabling each DIP register more than once.
      
      This patch solves a problem I can reproduce on my IVB machine. When I
      boot it with just a single HDMI monitor, the AVI InfoFrames are not
      sent. With this patch, the InfoFrames are sent. Previously, I wrote a
      patch to 'touch the DIP registers after we enable the HDMI port' to
      solve this same problem, but that patch doesn't seem to be needed
      anymore after this patch.
      
      All this patch does is revert a chunk of the following commit:
      
          commit 64a8fc01
          Author: Jesse Barnes <jbarnes@virtuousgeek.org>
          Date:   Thu Sep 22 11:16:00 2011 +0530
      
              drm/i915: fix ILK+ infoframe support
      
      So bugs that can be bisected to that commit may be fixed now.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43256
      
      
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9d32d165
    • Paulo Zanoni's avatar
      drm/i915: disable DIP while changing the port · 72b78c9d
      Paulo Zanoni authored
      
      
      The register specification says we need to do this.
      
      V2: Only write the register if the port is enabled.
      
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      72b78c9d
    • Paulo Zanoni's avatar
      drm/i915: explicitly disable the DIPs we're not using · 0dd87d20
      Paulo Zanoni authored
      
      
      From this point on, the 'set_infoframe' functions always set the DIP
      registers to a known state, so anything done will always be undone at
      the modeset.
      
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0dd87d20
    • Paulo Zanoni's avatar
      drm/i915: don't wait for vblank while writing InfoFrames · 5cde2a62
      Paulo Zanoni authored
      
      
      This function is called when the pipe is disabled, so it always gets
      the 50ms timeout.
      
      This function is called once for each InfoFrame, so we actually get a
      100ms timeout. Will be more if we add more InfoFrames.
      
      Also, the spec says we need to "wait for a VSync to ensure completion
      of any pending DIP transmissions", not for a VBlank. OTOH, the
      register documentation suggests that the DIPs are sent *during* the
      VSync, so shouldn't we be waiting until *after* the VSync to ensure
      all DIPs are sent?
      
      So this wait_for_vblank seems, besides useless, totally wrong.
      
      If we ever want to change some specific InfoFrame on-the-fly (outside
      of the modeset code), the code that changes the InfoFrame will have to
      do the waiting itself, and properly.
      
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5cde2a62
    • Paulo Zanoni's avatar
      drm/i915: enable DIP before enabling each InfoFrame · 822974ae
      Paulo Zanoni authored
      
      
      So the write_infoframe function can assume the DIP is on.
      
      V2: Be more defensive and add WARN().
      
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      822974ae
    • Paulo Zanoni's avatar
      drm/i915: only set the HDMI port on the DIP once · f278d972
      Paulo Zanoni authored
      
      
      Not once for each InfoFrame. Now we have a function that allows us to
      do this.
      
      [danvet: Paulo clarified on irc that a later bugfix patch needs this
      cleanup.]
      
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f278d972
    • Paulo Zanoni's avatar
      drm/i915: properly alternate between DVI and HDMI · 0c14c7f9
      Paulo Zanoni authored
      
      
      This solves problems that happen when you alternate between HDMI and
      DVI on the same port. I can reproduce these problems using DP->HDMI
      and DP->DVI adapters on a DP port.
      
      When you first plug HDMI and then plug DVI, you need to stop sending
      DIPs, even if the port is in DVI mode (see the HDMI register spec). If
      you don't stop sending DIPs, you'll see a pink vertical line on the
      left side of the screen, some modes will give you a black screen, some
      modes won't work correctly.
      
      When you first plug DVI and then plug HDMI, you need to properly
      enable the DIPs, otherwise the HW won't send them. After spending a
      lot of time investigating this, I concluded that if the DIPs are
      disabled, we should not write to the DIP register again because when
      we do this, we also set the AVI InfoFrame frequency to "once", and
      this seems to really confuse our hardware. Since this problem was not
      exactly easy to debug, I'm adopting the defensive behavior and not
      just avoing the "disable twice" sequence, but also explicitly
      selecting the AVI InfoFrame and setting its frequency to a correct
      one.
      
      Also, move the "is_dvi" check from intel_set_infoframe to the
      set_infoframes functions since now they're going to be the first ones
      to deal with the DIP registers.
      
      This patch adds the code to fix the problem, but it depends on the
      removal of some code that can't be removed right now and will come
      later in the patch series. The patch that we need is:
        - drm/i915: don't write 0 to DIP control at HDMI init
      
      [danvet: Paulo clarified that this additional patch is only required
      to make the fix complete, this patch here alone doesn't introduce a
      regression but only partially solves the problem of randomly clearing
      the dip registers.]
      
      V2: Be even more defensive by selecting AVI and setting its frequency
      outside the "is_dvi" check.
      
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0c14c7f9
    • 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
  2. 25 May, 2012 1 commit
  3. 21 May, 2012 1 commit
  4. 20 May, 2012 2 commits
  5. 19 May, 2012 5 commits
  6. 08 May, 2012 12 commits
  7. 03 May, 2012 2 commits
  8. 28 Mar, 2012 2 commits
  9. 14 Feb, 2012 1 commit
  10. 10 Feb, 2012 1 commit
  11. 19 Dec, 2011 1 commit
  12. 21 Oct, 2011 1 commit
  13. 20 Oct, 2011 2 commits
  14. 21 Sep, 2011 1 commit
    • Wu Fengguang's avatar
      drm/i915: pass ELD to HDMI/DP audio driver · e0dac65e
      Wu Fengguang authored
      
      
      Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
      SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
      
      ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
      capabilities of the plugged monitor. It's built and passed to audio
      driver in 2 steps:
      
      (1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]
      
      (2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
          ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver
      
      This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
      Test scheme: plug in the HDMI/DP monitor, and run
      
              cat /proc/asound/card0/eld*
      
      to check if the monitor name, HDMI/DP type, etc. show up correctly.
      
      Minor imperfection: the GEN5_AUD_CNTL_ST/DIP_Port_Select field always
      reads 0 (reserved). Without knowing the port number, I worked it around
      by setting the ELD_valid bit for ALL the three ports. It's tested to not
      be a problem, because the audio driver will find invalid ELD data and
      hence rightfully abort, even when it sees the ELD_valid indicator.
      
      Thanks to Zhenyu and Pierre-Louis for a lot of valuable help and testing.
      
      CC: Zhao Yakui <yakui.zhao@intel.com>
      CC: Wang Zhenyu <zhenyu.z.wang@intel.com>
      CC: Jeremy Bush <contractfrombelow@gmail.com>
      CC: Christopher White <c.white@pulseforce.com>
      CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
      CC: Paul Menzel <paulepanter@users.sourceforge.net>
      Signed-off-by: default avatarWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      e0dac65e