1. 12 Jun, 2012 7 commits
  2. 06 Jun, 2012 4 commits
  3. 04 Jun, 2012 4 commits
  4. 02 Jun, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: extract object active state flushing code · 30dfebf3
      Daniel Vetter authored
      
      
      Both busy_ioctl and the new wait_ioct need to do the same dance (or at
      least should). Some slight changes:
      - busy_ioctl now unconditionally checks for olr. Before emitting a
        require flush would have prevent the olr check and hence required a
        second call to the busy ioctl to really emit the request.
      - the timeout wait now also retires request. Not really required for
        abi-reasons, but makes a notch more sense imo.
      
      I've tested this by pimping the i-g-t test some more and also checking
      the polling behviour of the wait_rendering_timeout ioctl versus what
      busy_ioctl returns.
      
      v2: Too many people complained about unplug, new color is
      flush_active.
      
      v3: Kill the comment about the unplug moniker.
      
      v4: s/un-active/inactive/
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      30dfebf3
  5. 01 Jun, 2012 5 commits
  6. 31 May, 2012 14 commits
  7. 30 May, 2012 5 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