1. 23 1月, 2013 2 次提交
  2. 21 1月, 2013 4 次提交
  3. 18 1月, 2013 1 次提交
  4. 17 1月, 2013 1 次提交
    • J
      drm/i915: fix FORCEWAKE posting reads · b5144075
      Jani Nikula 提交于
      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=52411Reported-and-tested-by: NAlexander Bersenev <bay@hackerdom.ru>
      CC: Ben Widawsky <ben@bwidawsk.net>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Reviewed-by: NChris 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: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b5144075
  5. 16 1月, 2013 2 次提交
    • C
      drm/i915: Invalidate the relocation presumed_offsets along the slow path · 262b6d36
      Chris Wilson 提交于
      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=55984Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@fwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      262b6d36
    • J
      drm/i915/eDP: do not write power sequence registers for ghost eDP · f30d26e4
      Jani Nikula 提交于
      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=52601Reported-and-tested-by: NRyan Coe <ryan@rycomotorsports.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f30d26e4
  6. 15 1月, 2013 4 次提交
  7. 14 1月, 2013 5 次提交
  8. 13 1月, 2013 11 次提交
  9. 11 1月, 2013 10 次提交