1. 27 Jul, 2012 10 commits
  2. 26 Jul, 2012 11 commits
  3. 25 Jul, 2012 15 commits
  4. 24 Jul, 2012 1 commit
  5. 20 Jul, 2012 3 commits
    • Chris Wilson's avatar
      drm/i915: Make the lock for pageflips interruptible · 79158103
      Chris Wilson authored
      As we take the struct_mutex lock to access the command-stream, there is
      a possibility that we may need to wait for a GPU hang and so should make
      the lock both interruptible and error-checking.
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=50069Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      79158103
    • Paulo Zanoni's avatar
      drm/i915: don't forget the PCH backlight registers · a4f32fc3
      Paulo Zanoni authored
      When we enable/disable the CPU backlight registers we can't forget to
      enable/disable the PCH backlight registers. Since we're using the CPU
      registers we should also unset the override bit.
      
      Fixes a regression on the following commit:
        drm/i915: properly enable the blc controller on the right pipe
      
      The commit just deleted the code that sets the PCH registers, so it
      was relying on the values set by the BIOS. I told my BIOS to boot on
      the DVI monitor instead of the LVDS panel, so I noticed the bug.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a4f32fc3
    • Chris Wilson's avatar
      drm/i915: Insert a flush between batches if the breadcrumb was dropped · 09cf7c9a
      Chris Wilson authored
      If we drop the breadcrumb request after a batch due to a signal for
      example we aim to fix it up at the next opportunity. In this case we
      emit a second batchbuffer with no waits upon the first and so no
      opportunity to insert the missing request, so we need to emit the
      missing flush for coherency. (Note that that invalidating the render
      cache is the same as flushing it, so there should have been no
      observable corruption.)
      
      Note that beside simply adding the missing flush, avoiding potential
      render corruption, this will also fix at least parts of the problem
      introduced by some funny interaction of these two commits:
      
      commit de2b9985
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Wed Jul 4 22:52:50 2012 +0200
      
          drm/i915: don't return a spurious -EIO from intel_ring_begin
      
      which allowed intel_ring_begin to return -ERESTARTSYS and
      
      commit cc889e0f
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Wed Jun 13 20:45:19 2012 +0200
      
          drm/i915: disable flushing_list/gpu_write_list
      
      which essentially disabled the flushing list.
      
      The issue happens when we submit a batch & emit it, but get
      interrupted (thanks to the first patch) while trying to emit the
      flush. On the next batch we still assume that the full gpu domain
      handling is in effect and hence compute the invalidate&flushing
      domains. But thanks to the 2nd patch we totally ignore these and only
      invalidate all gpu domains, presuming that any required flushes have
      been issued already.  Which is wrong and eventually results in us
      updating the new write_domain values with the computed
      pending_write_domain values, which leaves an object with write_domain
      == 0 on the gpu_write_list.
      
      As soon as we try to unbind that object, things blow up.
      
      Fix this by emitting the missing flush according to the new
      ring->gpu_caches_dirty flag.
      
      Note that this does _not_ fix all the current cases where we end up
      with an object on the flushing_list that can't be flushed.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52040Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Add bug explanation to commit message.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      09cf7c9a