1. 28 Apr, 2012 1 commit
  2. 11 Apr, 2012 1 commit
  3. 01 Apr, 2012 1 commit
  4. 27 Feb, 2012 1 commit
    • Chris Wilson's avatar
      drm/i915: Remove use of the autoreported ringbuffer HEAD position · 5d031e5b
      Chris Wilson authored
      This is a revert of 6aa56062.
      This was originally introduced to workaround reads of the ringbuffer
      registers returning 0 on SandyBridge causing hangs due to ringbuffer
      overflow. The root cause here was reads through the GT powerwell require
      the forcewake dance, something we only learnt of later. Now it appears
      that reading the reported head position from the HWS is returning
      garbage, leading once again to hangs.
      For example, on q35 the autoreported head reports:
        [  217.975608] head now 00010000, actual 00010000
        [  436.725613] head now 00200000, actual 00200000
        [  462.956033] head now 00210000, actual 00210010
        [  485.501409] head now 00400000, actual 00400020
        [  508.064280] head now 00410000, actual 00410000
        [  530.576078] head now 00600000, actual 00600020
        [  553.273489] head now 00610000, actual 00610018
      which appears reasonably sane. In contrast, if we look at snb:
        [  141.970680] head now 00e10000, actual 00008238
        [  141.974062] head now 02734000, actual 000083c8
        [  141.974425] head now 00e10000, actual 00008488
        [  141.980374] head now 032b5000, actual 000088b8
        [  141.980885] head now 03271000, actual 00008950
        [  142.040628] head now 02101000, actual 00008b40
        [  142.180173] head now 02734000, actual 00009050
        [  142.181090] head now 00000000, actual 00000ae0
        [  142.183737] head now 02734000, actual 00009050
      In addition, the automatic reporting of the head position is scheduled
      to be defeatured in the future. It has no more utility, remove it.
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45492
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
  5. 15 Feb, 2012 1 commit
    • Chris Wilson's avatar
      drm/i915: Record the tail at each request and use it to estimate the head · a71d8d94
      Chris Wilson authored
      By recording the location of every request in the ringbuffer, we know
      that in order to retire the request the GPU must have finished reading
      it and so the GPU head is now beyond the tail of the request. We can
      therefore provide a conservative estimate of where the GPU is reading
      from in order to avoid having to read back the ring buffer registers
      when polling for space upon starting a new write into the ringbuffer.
      A secondary effect is that this allows us to convert
      intel_ring_buffer_wait() to use i915_wait_request() and so consolidate
      upon the single function to handle the complicated task of waiting upon
      the GPU. A necessary precaution is that we need to make that wait
      uninterruptible to match the existing conditions as all the callers of
      intel_ring_begin() have not been audited to handle ERESTARTSYS
      By using a conservative estimate for the head, and always processing all
      outstanding requests first, we prevent a race condition between using
      the estimate and direct reads of I915_RING_HEAD which could result in
      the value of the head going backwards, and the tail overflowing once
      again. We are also careful to mark any request that we skip over in
      order to free space in ring as consumed which provides a
      self-consistency check.
      Given sufficient abuse, such as a set of unthrottled GPU bound
      cairo-traces, avoiding the use of I915_RING_HEAD gives a 10-20% boost on
      Sandy Bridge (i5-2520m):
        firefox-paintball  18927ms -> 15646ms: 1.21x speedup
        firefox-fishtank   12563ms -> 11278ms: 1.11x speedup
      which is a mild consolation for the performance those traces achieved from
      exploiting the buggy autoreported head.
      v2: Add a few more comments and make request->tail a conservative
      estimate as suggested by Daniel Vetter.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: resolve conflicts with retirement defering and the lack of
      the autoreport head removal (that will go in through -fixes).]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  6. 13 Feb, 2012 2 commits
    • Daniel Vetter's avatar
      drm/i915: enable forcewake voodoo also for gen6 · 99ffa162
      Daniel Vetter authored
      We still have reports of missed irqs even on Sandybridge with the
      HWSTAM workaround in place. Testing by the bug reporter gets rid of
      them with the forcewake voodoo and no HWSTAM writes.
      Because I've slightly botched the rebasing I've left out the ACTHD
      readback which is also required to get IVB working. Seems to still
      work on the tester's machine, so I think we should go with the more
      minmal approach on SNB. Especially since I've only found weak evidence
      for holding forcewake while waiting for an interrupt to arrive, but
      none for the ACTHD readback.
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45181
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45332
      Tested-by: Nicolas Kalkhof nkalkhof()at()web.de
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Daniel Vetter's avatar
      drm/i915: fixup seqno allocation logic for lazy_request · 53d227f2
      Daniel Vetter authored
      Currently we reserve seqnos only when we emit the request to the ring
      (by bumping dev_priv->next_seqno), but start using it much earlier for
      ring->oustanding_lazy_request. When 2 threads compete for the gpu and
      run on two different rings (e.g. ddx on blitter vs. compositor)
      hilarity ensued, especially when we get constantly interrupted while
      reserving buffers.
      Breakage seems to have been introduced in
      commit 6f392d54
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Sat Aug 7 11:01:22 2010 +0100
          drm/i915: Use a common seqno for all rings.
      This patch fixes up the seqno reservation logic by moving it into
      i915_gem_next_request_seqno. The ring->add_request functions now
      superflously still return the new seqno through a pointer, that will
      be refactored in the next patch.
      Note that with this change we now unconditionally allocate a seqno,
      even when ->add_request might fail because the rings are full and the
      gpu died. But this does not open up a new can of worms because we can
      already leave behind an outstanding_request_seqno if e.g. the caller
      gets interrupted with a signal while stalling for the gpu in the
      eviciton paths. And with the bugfix we only ever have one seqno
      allocated per ring (and only that ring), so there are no ordering
      issues with multiple outstanding seqnos on the same ring.
      v2: Keep i915_gem_get_seqno (but move it to i915_gem.c) to make it
      clear that we only have one seqno counter for all rings. Suggested by
      Chris Wilson.
      v3: As suggested by Chris Wilson use i915_gem_next_request_seqno
      instead of ring->oustanding_lazy_request to make the follow-up
      refactoring more clearly correct. Also improve the commit message
      with issues discussed on irc.
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45181
      Tested-by: Nicolas Kalkhof nkalkhof()at()web.de
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  7. 29 Jan, 2012 2 commits
  8. 25 Jan, 2012 1 commit
  9. 20 Jan, 2012 1 commit
  10. 19 Jan, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: paper over missed irq issues with force wake voodoo · 4cd53c0c
      Daniel Vetter authored
      Two things seem to do the trick on my ivb machine here:
      - prevent the gt from powering down while waiting for seqno
        notification interrupts by grabbing the force_wake in get_irq (and
        dropping it in put_irq again).
      - ordering writes from the ring's CS by reading a CS register, ACTHD
        seems to work.
      Only the blt&bsd ring on ivb seem to be massively affected by this,
      but for paranoia do this dance also on the render ring and on snb
      (i.e. all gpus with forcewake).
      Tested with Eric's glCopyPixels loop which without this patch scores a
      missed irq every few seconds.
      This patch needs my forcewake rework to use a spinlock instead of
      After crawling through docs a lot I've found the following nugget:
      Internal doc "SNB GT PM Programming Guide", Section 4.3.1:
      "GT does not generate interrupts while in RC6 (by design)"
      So it looks like rc6 and irq generation are indeed related.
      v2: Improve the comment per Eugeni Dodonov's suggestion.
      v3: Add the documentation snipped. Also restrict the w/a to ivb only
      for -fixes, as suggested by Keith Packard.
      Cc: stable@kernel.org
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Kenneth Graunke <kenneth@whitecape.org>
      Cc: Eugeni Dodonov <eugeni.dodonov@intel.com>
      Tested-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
  11. 03 Jan, 2012 3 commits
  12. 20 Oct, 2011 3 commits
  13. 21 Sep, 2011 1 commit
    • Ben Widawsky's avatar
      drm/i915: Dumb down the semaphore logic · c8c99b0f
      Ben Widawsky authored
      While I think the previous code is correct, it was hard to follow and
      hard to debug. Since we already have a ring abstraction, might as well
      use it to handle the semaphore updates and compares.
      I don't expect this code to make semaphores better or worse, but you
      never know...
      Remove magic per Keith's suggestions.
      Ran Daniel's gem_ring_sync_loop test on this.
      Ignored one of Keith's suggestions.
      Removed some bloat per Daniel's recommendation.
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Keith Packard <keithp@keithp.com>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
  14. 19 Sep, 2011 1 commit
  15. 19 Aug, 2011 1 commit
  16. 22 Jul, 2011 1 commit
    • Keith Packard's avatar
      drm/i915: Initialize RCS ring status page address in intel_render_ring_init_dri · f3234706
      Keith Packard authored
      Physically-addressed hardware status pages are initialized early in
      the driver load process by i915_init_phys_hws. For UMS environments,
      the ring structure is not initialized until the X server starts. At
      that point, the entire ring structure is re-initialized with all new
      values. Any values set in the ring structure (including
      ring->status_page.page_addr) will be lost when the ring is
      This patch moves the initialization of the status_page.page_addr value
      to intel_render_ring_init_dri.
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      Cc: stable@kernel.org
  17. 09 Jun, 2011 1 commit
  18. 16 May, 2011 2 commits
  19. 13 May, 2011 2 commits
  20. 10 May, 2011 3 commits
  21. 23 Mar, 2011 1 commit
    • Chris Wilson's avatar
      drm/i915: Restore missing command flush before interrupt on BLT ring · 36d527de
      Chris Wilson authored
      We always skipped flushing the BLT ring if the request flush did not
      include the RENDER domain. However, this neglects that we try to flush
      the COMMAND domain after every batch and before the breadcrumb interrupt
      (to make sure the batch is indeed completed prior to the interrupt
      firing and so insuring CPU coherency). As a result of the missing flush,
      incoherency did indeed creep in, most notable when using lots of command
      buffers and so potentially rewritting an active command buffer (i.e.
      the GPU was still executing from it even though the following interrupt
      had already fired and the request/buffer retired).
      As all ring->flush routines now have the same preconditions, de-duplicate
      and move those checks up into i915_gem_flush_ring().
      Fixes gem_linear_blit.
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35284
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: mengmeng.meng@intel.com
  22. 07 Feb, 2011 1 commit
  23. 02 Feb, 2011 1 commit
  24. 27 Jan, 2011 1 commit
  25. 25 Jan, 2011 1 commit
  26. 20 Jan, 2011 4 commits
    • Linus Torvalds's avatar
      i915: Fix i915 suspend delay · d7b9935a
      Linus Torvalds authored
      During system suspend, the "wait for ring buffer to empty" loop would
      always time out after three seconds, because the faster cached ring
      buffer head read would always return zero.  Force the slow-and-careful
      PIO read on all but the first iterations of the loop to fix it.
      This also removes the unused (and useless) 'actual_head' variable that
      tried to approximate doing this, but did it incorrectly.
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: DRI mailing list <dri-devel@lists.freedesktop.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Chris Wilson's avatar
      drm/i915/ringbuffer: Fix use of stale HEAD position whilst polling for space · c7dca47b
      Chris Wilson authored
      During suspend, Linus found that his machine would hang for 3 seconds,
      and identified that intel_ring_buffer_wait() was the culprit:
      "Because from looking at the code, I get the notion that
      "intel_read_status_page()" may not be exact. But what happens if that
      inexact value matches our cached ring->actual_head, so we never even
      try to read the exact case? Does it _stay_ inexact for arbitrarily
      long times? If so, we might wait for the ring to empty forever (well,
      until the timeout - the behavior I see), even though the ring really
      _is_ empty."
      As the reported HEAD position is only updated every time it crosses a
      64k boundary, whilst draining the ring it is indeed likely to remain one
      value. If that value matches the last known HEAD position, we never read
      the true value from the register and so trigger a timeout.
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
    • Chris Wilson's avatar
      drm/i915/ringbuffer: Kill an annoyingly frequent debug message · c0c06bd2
      Chris Wilson authored
      This is better handled through the tracepoints and just clutters the
      debug logs.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
    • Chris Wilson's avatar
      drm/i915: Initialise ring vfuncs for old DRI paths · e8616b6c
      Chris Wilson authored
      We weren't setting up the vfunc table when initialising the old DRI
      ringbuffer, leading to such OOPSes as:
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: [<(null)>] (null)
      PGD 10c441067 PUD 1185e5067 PMD 0
      Oops: 0010 [#1] PREEMPT SMP
      last sysfs file: /sys/class/dmi/id/chassis_asset_tag
      CPU 3
      Modules linked in: i915 drm_kms_helper drm fb fbdev i2c_algo_bit
      cfbcopyarea video backlight output cfbimgblt cfbfillrect autofs4 ipv6
      nfs lockd fscache nfs_acl auth_rpcgss sunrpc coretemp hwmon_vid mousedev
      usbhid hid option usb_wwan snd_hda_codec_via asus_atk0110 atl1e
      usbserial snd_hda_intel snd_hda_codec firmware_class snd_hwdep snd_pcm
      snd_seq snd_timer snd_seq_device processor parport_pc thermal snd
      thermal_sys parport 8250_pnp button rng_core rtc_cmos shpchp hwmon
      rtc_core ehci_hcd pci_hotplug uhci_hcd soundcore tpm_tis i2c_i801
      rtc_lib tpm serio_raw snd_page_alloc tpm_bios i2c_core usbcore psmouse
      intel_agp sg pcspkr sr_mod evdev cdrom ext3 jbd mbcache dm_mod sd_mod
      ata_piix libata scsi_mod unix
      Jan 18 15:49:29 lithui kernel:
      Pid: 3605, comm: Xorg Not tainted #5 P5KPL-CM/System Product
      RIP: 0010:[<0000000000000000>]  [<(null)>] (null)
      RSP: 0018:ffff8801150d1d40  EFLAGS: 00010202
      RAX: 000000000001ffff RBX: ffff88011a011b00 RCX: 000000000001a704
      RDX: ffff880118566028 RSI: ffff880118566028 RDI: ffff880117876800
      RBP: ffff8801150d1d48 R08: ffff8801195fe300 R09: 00000000c0086444
      R10: 0000000000000001 R11: 0000000000003206 R12: ffff880117876800
      R13: ffff880118566000 R14: ffff880117876820 R15: ffff8801150d1df8
      FS:  00007f1038d456e0(0000) GS:ffff880001780000(0000)
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 00000001187e7000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process Xorg (pid: 3605, threadinfo ffff8801150d0000, task
      ffffffffa043b8e6 ffff8801150d1d98 ffffffffa041768b dead000000000000
      <0> 0000000000000048 00007f1023f2a000 0000000000000044 0000000000000008
      <0> ffff88010d26bd80 ffff880117876800 ffff8801150d1df8 ffff8801150d1ea8
      Call Trace:
      [<ffffffffa043b8e6>] ? intel_ring_advance+0x16/0x20 [i915]
      [<ffffffffa041768b>] i915_irq_emit+0x15b/0x240 [i915]
      [<ffffffffa03ea7b1>] drm_ioctl+0x1f1/0x460 [drm]
      [<ffffffffa0417530>] ? i915_irq_emit+0x0/0x240 [i915]
      [<ffffffff810dd8f1>] ? do_sync_read+0xd1/0x120
      [<ffffffff81025b1f>] ? do_page_fault+0x1df/0x3d0
      [<ffffffff810ed5c7>] do_vfs_ioctl+0x97/0x550
      [<ffffffff8115c2ea>] ? security_file_permission+0x7a/0x90
      [<ffffffff810edb19>] sys_ioctl+0x99/0xa0
      [<ffffffff810024ab>] system_call_fastpath+0x16/0x1b
      Code:  Bad RIP value.
      RIP  [<(null)>] (null)
      RSP <ffff8801150d1d40>
      CR2: 0000000000000000
      Reported-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29153
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=23172
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@kernel.org
  27. 11 Jan, 2011 1 commit