Skip to content
  1. Jan 21, 2013
    • Dave Airlie's avatar
      ttm: don't destroy old mm_node on memcpy failure · 63054186
      Dave Airlie authored
      
      
      When we are using memcpy to move objects around, and we fail to memcpy
      due to lack of memory to populate or failure to finish the copy, we don't
      want to destroy the mm_node that has been copied into old_copy.
      
      While working on a new kms driver that uses memcpy, if I overallocated bo's
      up to the memory limits, and eviction failed, then machine would oops soon
      after due to having an active bo with an already freed drm_mm embedded in it,
      freeing it a second time didn't end well.
      
      Reviewed-by: default avatarJerome Glisse <jglisse@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      63054186
    • Dave Airlie's avatar
      Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next · ffb5fd53
      Dave Airlie authored
      More important fixes for 3.9:
      - error_state improvements to help debug the new scanline wait code added
        for gen6+ - bug reports started popping up :( patch from Chris Wilson.
      - fix a panel power sequence confusion between the eDP and lvds detection
        code resulting in black screens - regression introduce in 3.8 (Jani
        Nikula)
      - Chris fixed the root-cause of the ilk relocation vs. evict bug.
      - Another piece of cargo-culted rc6 lore from Jani, fixes up a regression
        where a system refused to go into rc6 after suspend sometimes.
      
      * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
        drm/i915: fix FORCEWAKE posting reads
        drm/i915: Invalidate the relocation presumed_offsets along the slow path
        drm/i915/eDP: do not write power sequence registers for ghost eDP
        drm/i915: Record DERRMR, FORCEWAKE and RING_CTL in error-state
      ffb5fd53
    • Dave Airlie's avatar
      Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux into drm-next · a3f5aed4
      Dave Airlie authored
      A number of fixes, and one revert for a patch having some wierd side effects.
      
      * 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux:
        Revert "drm/radeon: do not move bo to different placement at each cs"
        drm/radeon: improve semaphore debugging on lockup
        drm/radeon: allow FP16 color clear registers on r500
        drm/radeon: clear reset flags if engines are idle
      a3f5aed4
  2. Jan 18, 2013
  3. Jan 17, 2013
    • Jani Nikula's avatar
      drm/i915: fix FORCEWAKE posting reads · b5144075
      Jani Nikula authored
      We stopped reading FORCEWAKE for posting reads in
      
      commit 8dee3eea
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Sat Sep 1 22:59:50 2012 -0700
      
          drm/i915: Never read FORCEWAKE
      
      and started using something from the same cacheline instead. On the
      bug reporter's machine this broke entering rc6 states after a
      suspend/resume cycle. It turns out reading ECOBUS as posting read
      worked fine, while GTFIFODBG did not, preventing RC6 states after
      suspend/resume per the bug report referenced below. It's not entirely
      clear why, but clearly GTFIFODBG was nowhere near the same cacheline
      or address range as FORCEWAKE.
      
      Trying out various registers for posting reads showed that all tested
      registers for which NEEDS_FORCE_WAKE() (in i915_drv.c) returns true
      work. Conversely, most (but not quite all) registers for which
      NEEDS_FORCE_WAKE() returns false do not work. Details in the referenced
      bug.
      
      Based on the above, add posting reads on ECOBUS where GTFIFODBG was
      previously relied on.
      
      In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as
      well, but instead of ECOBUS, use FORCEWAKE_ACK_VLV which is in the same
      address range as FORCEWAKE_VLV.
      
      v2: Add more details to the commit message. No functional changes.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411
      
      
      Reported-and-tested-by: default avatarAlexander Bersenev <bay@hackerdom.ru>
      CC: Ben Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      [danvet: add cc: stable and make the commit message a bit clearer that
      this is a regression fix and what exactly broke.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b5144075
  4. Jan 16, 2013
    • Chris Wilson's avatar
      drm/i915: Invalidate the relocation presumed_offsets along the slow path · 262b6d36
      Chris Wilson authored
      In the slow path, we are forced to copy the relocations prior to
      acquiring the struct mutex in order to handle pagefaults. We forgo
      copying the new offsets back into the relocation entries in order to
      prevent a recursive locking bug should we trigger a pagefault whilst
      holding the mutex for the reservations of the execbuffer. Therefore, we
      need to reset the presumed_offsets just in case the objects are rebound
      back into their old locations after relocating for this exexbuffer - if
      that were to happen we would assume the relocations were valid and leave
      the actual pointers to the kernels dangling, instant hang.
      
      Fixes regression from commit bcf50e27
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Sun Nov 21 22:07:12 2010 +0000
      
          drm/i915: Handle pagefaults in execbuffer user relocations
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984
      
      
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@fwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      262b6d36
    • Jani Nikula's avatar
      drm/i915/eDP: do not write power sequence registers for ghost eDP · f30d26e4
      Jani Nikula authored
      Some machines detect an eDP port even if it's not really there, and eDP
      initialization has a fail path for this. Typically such machines have an
      LVDS display instead. A regression introduced in
      
      commit 82ed61fa
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sat Oct 20 20:57:41 2012 +0200
      
          drm/i915: make edp panel power sequence setup more robust
      
      updated the power sequence registers PCH_PP_ON_DELAYS, PCH_PP_OFF_DELAYS,
      and PCH_PP_DIVISOR also in the ghost eDP case, messing up the LVDS display.
      
      Split the power sequencer initialization into two, delaying the register
      updates until after we know the eDP is real.
      
      Note: Keep the PP_CONTROL unlocking in the first part, even if it does not
      update registers, per the commit message of the above mentioned commit.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52601
      
      
      Reported-and-tested-by: default avatarRyan Coe <ryan@rycomotorsports.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f30d26e4
  5. Jan 15, 2013
  6. Jan 14, 2013
  7. Jan 13, 2013
  8. Jan 11, 2013
  9. Jan 10, 2013
    • Linus Torvalds's avatar
      Linux 3.8-rc3 · 9931faca
      Linus Torvalds authored
      v3.8-rc3
      9931faca
    • Steven Rostedt's avatar
      tracing: Fix regression of trace_options file setting · a8dd2176
      Steven Rostedt authored
      
      
      The latest change to allow trace options to be set on the command
      line also broke the trace_options file.
      
      The zeroing of the last byte of the option name that is echoed into
      the trace_option file was removed with the consolidation of some
      of the code. The compare between the option and what was written to
      the trace_options file fails because the string holding the data
      written doesn't terminate with a null character.
      
      A zero needs to be added to the end of the string copied from
      user space.
      
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      a8dd2176