1. 05 Feb, 2014 1 commit
  2. 30 Jan, 2014 2 commits
  3. 29 Jan, 2014 18 commits
  4. 28 Jan, 2014 5 commits
  5. 27 Jan, 2014 2 commits
    • Russell King's avatar
      DRM: armada: fix missing DRM_KMS_FB_HELPER select · bed86f15
      Russell King authored
      Commit 92b6f89f6b8f (drm: Add separate Kconfig option for fbdev helpers)
      happened in parallel with the inclusion of Armada DRM into mainline,
      and so missed this update.  Add the necessary select statement to avoid
      build errors.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      bed86f15
    • Chris Wilson's avatar
      drm/i915: Decouple GPU error reporting from ring initialisation · 372fbb8e
      Chris Wilson authored
      Currently we report through our error state only the rings that have
      been initialised (as detected by ring->obj). This check is done after
      the GPU reset and ring re-initialisation, which means that the software
      state may not be the same as when we captured the hardware error and we
      may not print out any of the vital information for debugging the hang.
      
      This (and the implied object leak) is a regression from
      
      commit 3d57e5bd
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Mon Oct 14 10:01:36 2013 -0700
      
          drm/i915: Do a fuller init after reset
      
      Note that we are already starting to get bug reports with incomplete
      error states from 3.13, which also hampers debugging userspace driver
      issues.
      
      v2: Prevent a NULL dereference on 830gm/845g after a GPU reset where
          the scratch obj may be NULL.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      References: https://bugs.freedesktop.org/show_bug.cgi?id=74094
      Cc: stable@vger.kernel.org # please don't delay since it's a
      vital support/debug feature for the intel gfx stack in general
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      [danvet: Add a bit of fluff to make it clear we need this expedited in
      stable.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      372fbb8e
  6. 25 Jan, 2014 1 commit
    • Stanislaw Gruszka's avatar
      i915: remove pm_qos request on error · 22accca0
      Stanislaw Gruszka authored
      Not removing pm qos request and free memory for it can cause crash,
      when some other driver use pm qos. For example, this oops:
      
      BUG: unable to handle kernel paging request at fffffffffffffff8
      IP: [<ffffffff81307a6b>] plist_add+0x5b/0xd0
      Call Trace:
       [<ffffffff810acf25>] pm_qos_update_target+0x125/0x1e0
       [<ffffffff810ad071>] pm_qos_add_request+0x91/0x100
       [<ffffffffa053ec14>] e1000_open+0xe4/0x5b0 [e1000e]
      
      was caused by earlier i915 probe failure:
      
      [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
      [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00003004 tail 00000000 start 00003000
      [drm:i915_driver_load] *ERROR* failed to init modeset
      i915: probe of 0000:00:02.0 failed with error -5
      
      Bug report:
      http://bugzilla.redhat.com/show_bug.cgi?id=1057533Reported-by: default avatarGiandomenico De Tullio <ghisha@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      [danvet: Drop unnecessary code movement.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      22accca0
  7. 24 Jan, 2014 1 commit
    • Daniel Vetter's avatar
      Revert "drm/i915: Mask reserved bits in display/sprite address registers" · 85ba7b7d
      Daniel Vetter authored
      This reverts commit 446f2545.
      
      I've left the masking in the pageflip code since that seems to be some
      useful piece of preemptive robustness.
      
      Iirc I've merged this patch under the assumption that the BIOS leaves
      some random gunk in the lower bits and gets unhappy if we trample on
      them. We have quite a few case like this, so this made sense.
      
      Now I've just learned that there's actual hardware features bits in
      the low 12 bits, and the kernel needs to preserve them to allow a
      userspace blob to do its job. Given Dave Airlie's clear stance on
      userspace blob drivers I've quickly chatted with him and he doesn't
      seem too happy. So let's revert this.
      
      If there are indeed bits that we must preserve in this range then we
      can ressurrect this patch, but with proper documentation for those
      bits supplied. And we probably also need to think a bit about
      interactions with our driver.
      
      Cc: Armin Reese <armin.c.reese@intel.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Dave Airlie <airlied@linux.ie>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      85ba7b7d
  8. 23 Jan, 2014 10 commits