1. 12 Jun, 2012 10 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 2 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