1. 01 Jun, 2012 3 commits
  2. 31 May, 2012 7 commits
  3. 30 May, 2012 11 commits
    • Paulo Zanoni's avatar
      drm/i915: add some barriers when changing DIPs · 9d9740f0
      Paulo Zanoni authored
      
      
      On IVB and older, we basically have two registers: the control and the
      data register. We write a few consecutitve times to the control
      register, and we need these writes to arrive exactly in the specified
      order.
      
      Also, when we're changing the data register, we need to guarantee that
      anything written to the control register already arrived (since
      changing the control register can change where the data register
      points to). Also, we need to make sure all the writes to the data
      register happen exactly in the specified order, and we also *can't*
      read the data register during this process, since reading and/or
      writing it will change the place it points to.
      
      So invoke the "better safe than sorry" rule and just be careful and
      put barriers everywhere :)
      
      On HSW we still have a control register that we write many times, but
      we have many data registers.
      Demanded-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9d9740f0
    • Paulo Zanoni's avatar
      drm/i915: remove comment about HSW HDMI DIPs · c30b6110
      Paulo Zanoni authored
      
      
      HSW support is now just like all the other generations: we send AVI
      and SPD InfoFrames. There are other DIPs for HSW, but there are other
      DIPs for the previous generations too. For each gen, we can see which
      DIPs are missing by looking at the 'set_infoframes' function: we
      explicitly disable the DIPs we're not using.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c30b6110
    • Paulo Zanoni's avatar
      drm/i915: don't set SDVO_BORDER_ENABLE when we're HDMI · b659c3db
      Paulo Zanoni authored
      
      
      The register that controls the HDMI port can be used to control the
      sDVO port. Some bits are defined only for sDVO, and SDVO_BORDER_ENABLE
      is one of those: HDMI ports that can't be used in sDVO mode don't even
      have this bit defined in their specifications.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b659c3db
    • 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
  4. 25 May, 2012 5 commits
    • Chris Wilson's avatar
      drm/i915/hdmi: Fix reg values for g4x_hdmi_connected · eeafaaca
      Chris Wilson authored
      Paulo pointed out that gen4 re-used the SDVO registers for HDMI (the
      separate HDMI registers where introduced with the first PCH) and so
      g4x_hdmi_connected() never selected the right bit and always returned
      disconnected.
      
      Regression in
      
      commit 8ec22b21
      
      
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri May 11 18:01:34 2012 +0100
      
          drm/i915/hdmi: Query the live connector status bit for G4x
      
      Cc: Paulo Zanoni <przanoni@gmail.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Tested-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      eeafaaca
    • Ben Widawsky's avatar
      drm/i915: s/i915_wait_request/i915_wait_seqno/g · 199b2bc2
      Ben Widawsky authored
      
      
      Wait request is poorly named IMO. After working with these functions for
      some time, I feel it's much clearer to name the functions more
      appropriately.
      
      Of course we must update the callers to use the new name as well.
      
      This leaves room within our namespace for a *real* wait request function
      at some point.
      
      Note to maintainer: this patch is optional.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      199b2bc2
    • Ben Widawsky's avatar
      drm/i915: wait render timeout ioctl · 23ba4fd0
      Ben Widawsky authored
      
      
      This helps implement GL_ARB_sync but stops short of allowing full blown
      sync objects. Finally we can use the new timed seqno waiting function
      to allow userspace to wait on a buffer object with a timeout. This
      implements that interface.
      
      The IOCTL will take as input a buffer object handle, and a timeout in
      nanoseconds (flags is currently optional but will likely be used for
      permutations of flush operations). Users may specify 0 nanoseconds to
      instantly check.
      
      The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any
      non-zero timeout parameter the wait ioctl will wait for the given number
      of nanoseconds on an object becoming unbusy. Since the wait itself does
      so holding struct_mutex the object may become re-busied before this
      completes. A similar but shorter race condition exists in the busy
      ioctl.
      
      v2: ETIME/ERESTARTSYS instead of changing to EBUSY, and EGAIN (Chris)
      Flush the object from the gpu write domain (Chris + Daniel)
      Fix leaked refcount in good case (Chris)
      Naturally align ioctl struct (Chris)
      
      v3: Drop lock after getting seqno to avoid ugly dance (Chris)
      
      v4: check for 0 timeout after olr check to allow polling (Chris)
      
      v5: Updated the comment. (Chris)
      
      v6: Return -ETIME instead of -EBUSY when timeout_ns is 0 (Daniel)
      Fix the commit message comment to be less ugly (Ben)
      Add a warning to check the return timespec (Ben)
      
      v7: Use DRM_AUTH for the ioctl. (Eugeni)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      23ba4fd0
    • Ben Widawsky's avatar
      drm/i915: improve i915_wait_request_begin trace · f3fd3768
      Ben Widawsky authored
      
      
      The trace events adds whether or not the wait was blocking. Blocking in
      this case means to hold struct_mutex (ie. no new work can be submitted
      during the wait). The information is inherently racy.
      
      The blocking information is racy since mutex_is_locked doesn't check
      that the current thread holds the lock. The only other option would be
      to pass the boolean information of whether or not the class was blocking
      down through the stack which is less desirable.
      
      v2: Don't do a trace event per loop. (Chris)
      Only get blocking/non-blocking info (Chris)
      
      v3: updated comment in code as well as commit msg (Daniel)
      Add "(NB)" to trace information to remind us in 6 months (Ben)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f3fd3768
    • Ben Widawsky's avatar
      drm/i915: timeout parameter for seqno wait · 5c81fe85
      Ben Widawsky authored
      
      
      Insert a wait parameter in the code so we can possibly timeout on a
      seqno wait if need be. The code should be functionally the same as
      before because all the callers will continue to retry if an arbitrary
      timeout elapses.
      
      We'd like to have nanosecond granularity, but the only way to do this is
      with hrtimer, and that doesn't fit well with the needs of this code.
      
      v2: Fix rebase error (Chris)
      Return proper time even in wedged + signal case (Chris + Ben)
      Use timespec constructs (Ben)
      Didn't take Daniel's advice regarding the Frankenstein-ness of the
        function. I did try his advice, but in the end I liked the way the
        original code looked, better.
      
      v3: Make wakeups far less frequent for infinite waits (Chris)
      
      v4: Remove dummy_wait variable (Daniel)
      Use raw monotonic time instead of jiffies (made the code a bit cleaner) (Ben)
      Added a couple of warnings (Ben)
      
      v5: Remove warnings (Daniel)
      Use more accurate time diff for default case (Daniel)
      Bikeshed for setting the return timespec in timeout case (Daniel)
      s/jiffies/time in one of the comments
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5c81fe85
  5. 22 May, 2012 2 commits
  6. 21 May, 2012 5 commits
  7. 20 May, 2012 4 commits
  8. 19 May, 2012 3 commits