1. 04 Sep, 2013 9 commits
    • Shobhit Kumar's avatar
    • Chris Wilson's avatar
      drm/i915: Always prefer CPU relocations with LLC · 2cc86b82
      Chris Wilson authored
      A follow-on to the update of the LLC coherency logic is that we can rely
      on the LLC being coherent with the CS for rewriting batchbuffers
      irrespective of their cache domain. (This should have no effect
      currently as all the batch buffers are expected to be I915_CACHE_LLC and
      so using the cpu relocation path anyway.)
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2cc86b82
    • Daniel Vetter's avatar
      drm/i915: More vma fixups around unbind/destroy · b93dab6e
      Daniel Vetter authored
      The important bugfix here is that we must not unlink the vma when
      we keep it around as a placeholder for the execbuf code. Since then we
      won't find it again when execbuf gets interrupt and restarted and
      create a 2nd vma. And since the code as-is isn't fit yet to deal with
      more than one vma, hilarity ensues.
      
      Specifically the dma map/unmap of the sg table isn't adjusted for
      multiple vmas yet and will blow up like this:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      IP: [<ffffffffa008fb37>] i915_gem_gtt_finish_object+0x73/0xc8 [i915]
      PGD 56bb5067 PUD ad3dd067 PMD 0
      Oops: 0000 [#1] SMP
      Modules linked in: tcp_lp ppdev parport_pc lp parport ipv6 dm_mod dcdbas snd_hda_codec_hdmi pcspkr snd_hda_codec_realtek serio_raw i2c_i801 iTCO_wdt iTCO_vendor_support snd_hda_intel snd_hda_codec lpc_ich snd_hwdep mfd_core snd_pcm snd_page_alloc snd_timer snd soundcore acpi_cpufreq i915 video button drm_kms_helper drm mperf freq_table
      CPU: 1 PID: 16650 Comm: fbo-maxsize Not tainted 3.11.0-rc4_nightlytop_d93f59_debug_20130814_+ #6957
      Hardware name: Dell Inc. OptiPlex 9010/03JR84, BIOS A01 05/04/2012
      task: ffff8800563b3f00 ti: ffff88004bdf4000 task.ti: ffff88004bdf4000
      RIP: 0010:[<ffffffffa008fb37>]  [<ffffffffa008fb37>] i915_gem_gtt_finish_object+0x73/0xc8 [i915]
      RSP: 0018:ffff88004bdf5958  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff8801135e0000 RCX: ffff8800ad3bf8e0
      RDX: ffff8800ad3bf8e0 RSI: 0000000000000000 RDI: ffff8801007ee780
      RBP: ffff88004bdf5978 R08: ffff8800ad3bf8e0 R09: 0000000000000000
      R10: ffffffff86ca1810 R11: ffff880036a17101 R12: ffff8801007ee780
      R13: 0000000000018001 R14: ffff880118c4e000 R15: ffff8801007ee780
      FS:  00007f401a0ce740(0000) GS:ffff88011e280000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000008 CR3: 000000005635c000 CR4: 00000000001407e0
      Stack:
       ffff8801007ee780 ffff88005c253180 0000000000018000 ffff8801135e0000
       ffff88004bdf59a8 ffffffffa0088e55 0000000000000011 ffff8801007eec00
       0000000000018000 ffff880036a17101 ffff88004bdf5a08 ffffffffa0089026
      Call Trace:
       [<ffffffffa0088e55>] i915_vma_unbind+0xdf/0x1ab [i915]
       [<ffffffffa0089026>] __i915_gem_shrink+0x105/0x177 [i915]
       [<ffffffffa0089452>] i915_gem_object_get_pages_gtt+0x108/0x309 [i915]
       [<ffffffffa0085ba9>] i915_gem_object_get_pages+0x61/0x90 [i915]
       [<ffffffffa008f22b>] ? gen6_ppgtt_insert_entries+0x103/0x125 [i915]
       [<ffffffffa008a113>] i915_gem_object_pin+0x1fa/0x5df [i915]
       [<ffffffffa008cdfe>] i915_gem_execbuffer_reserve_object.isra.6+0x8d/0x1bc [i915]
       [<ffffffffa008d156>] i915_gem_execbuffer_reserve+0x229/0x367 [i915]
       [<ffffffffa008dbf6>] i915_gem_do_execbuffer.isra.12+0x4dc/0xf3a [i915]
       [<ffffffff810fc823>] ? might_fault+0x40/0x90
       [<ffffffffa008eb89>] i915_gem_execbuffer2+0x187/0x222 [i915]
       [<ffffffffa000971c>] drm_ioctl+0x308/0x442 [drm]
       [<ffffffffa008ea02>] ? i915_gem_execbuffer+0x3ae/0x3ae [i915]
       [<ffffffff817db156>] ? __do_page_fault+0x3dd/0x481
       [<ffffffff8112fdba>] vfs_ioctl+0x26/0x39
       [<ffffffff811306a2>] do_vfs_ioctl+0x40e/0x451
       [<ffffffff817deda7>] ? sysret_check+0x1b/0x56
       [<ffffffff8113073c>] SyS_ioctl+0x57/0x87
       [<ffffffff8135bbfe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
       [<ffffffff817ded82>] system_call_fastpath+0x16/0x1b
      Code: 48 c7 c6 84 30 0e a0 31 c0 e8 d0 e9 f7 ff bf c6 a7 00 00 e8 07 af 2c e1 41 f6 84 24 03 01 00 00 10 75 44 49 8b 84 24 08 01 00 00 <8b> 50 08 48 8b 30 49 8b 86 b0 04 00 00 48 89 c7 48 81 c7 98 00
      RIP  [<ffffffffa008fb37>] i915_gem_gtt_finish_object+0x73/0xc8 [i915]
       RSP <ffff88004bdf5958>
      CR2: 0000000000000008
      
      As a consequence we need to change the "only one vma for now" check in
      vma_unbind - since vma_destroy isn't always called the obj->vma_list
      might not be empty. Instead check that the vma list is singular at the
      beginning of vma_unbind. This is also more symmetric with bind_to_vm.
      
      This fixes the igt/gem_evict_everything|alignment testcases.
      
      v2:
      - Add a paranoid WARN to mark_free in the eviction code to make sure
        we never try to evict a vma used by the execbuf code right now.
      - Move the check for a temporary execbuf vma into vma_destroy -
        otherwise the failure path cleanup in bind_to_vm will blow up.
      
      Our first attempting at fixing this was
      
      commit 1be81a2f2cfd8789a627401d470423358fba2d76
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Aug 20 12:56:40 2013 +0100
      
          drm/i915: Don't destroy the vma placeholder during execbuffer reservation
      
      Squash with this when merging!
      
      v3: Improvements suggested in Chris' review:
      - Move the WARN_ON in vma_destroy that checks for vmas with an drm_mm
        allocation before the early return.
      - Bail out if we hit the WARN in mark_free to hopefully make the
        kernel survive for long enough to capture it.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68298
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68171
      Tested-by: lu hua <huax.lu@intel.com> (v2)
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b93dab6e
    • Chris Wilson's avatar
      drm/i915: Don't destroy the vma placeholder during execbuffer reservation · aaa05667
      Chris Wilson authored
      The execbuffer handle and exec_link were moved from the object into the
      vma. As the vma may be unbound and destroyed whilst attempting to
      reserve the execbuffer objects (either through a forced unbind to fix up
      a misalignment or through an evict-everything call) we need to prevent
      the free of the i915_vma itself. Otherwise not only is the list of
      objects to reserve corrupt, but we continue to reference stale vma
      entries.
      
      Fixes kernel crash with i-g-t/gem_evict_everything
      
      This regression has been introduced in
      
      commit 04038a515d6eda6dd0857c0ade0b3950d372f4c0
      Author:     Ben Widawsky <ben@bwidawsk.net>
      AuthorDate: Wed Aug 14 11:38:36 2013 +0200
      
          drm/i915: Convert execbuf code to use vmas
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      References: http://www.spinics.net/lists/intel-gfx/msg32038.html
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68298Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      aaa05667
    • Daniel Vetter's avatar
      drm/i915: inline vma_create into lookup_or_create_vma · e656a6cb
      Daniel Vetter authored
      In the execbuf code we don't clean up any vmas which ended up not
      getting bound for code simplicity. To make sure that we don't end up
      creating multiple vma for the same vm kill the somewhat dangerous
      vma_create function and inline it into lookup_or_create.
      
      This is just a safety measure to prevent surprises in the future.
      
      Also update the somewhat confused comment in the execbuf code and
      clarify what kind of magic is going on with a new one.
      
      v2: Keep the function separate as requested by Chris. But give it a __
      prefix for paranoia and move it tighter together with the other vma
      stuff.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e656a6cb
    • Ben Widawsky's avatar
      drm/i915: Convert execbuf code to use vmas · 27173f1f
      Ben Widawsky authored
      In order to transition more of our code over to using a VMA instead of
      an <OBJ, VM> pair - we must have the vma accessible at execbuf time. Up
      until now, we've only had a VMA when actually binding an object.
      
      The previous patch helped handle the distinction on bound vs. unbound.
      This patch will help us catch leaks, and other issues before we actually
      shuffle a bunch of stuff around.
      
      This attempts to convert all the execbuf code to speak in vmas. Since
      the execbuf code is very self contained it was a nice isolated
      conversion.
      
      The meat of the code is about turning eb_objects into eb_vma, and then
      wiring up the rest of the code to use vmas instead of obj, vm pairs.
      
      Unfortunately, to do this, we must move the exec_list link from the obj
      structure. This list is reused in the eviction code, so we must also
      modify the eviction code to make this work.
      
      WARNING: This patch makes an already hotly profiled path slower. The cost is
      unavoidable. In reply to this mail, I will attach the extra data.
      
      v2: Release table lock early, and two a 2 phase vma lookup to avoid
      having to use a GFP_ATOMIC. (Chris)
      
      v3: s/obj_exec_list/obj_exec_link/
      Updates to address
      commit 6d2b8885
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Wed Aug 7 18:30:54 2013 +0100
      
          drm/i915: List objects allocated from stolen memory in debugfs
      
      v4: Use obj = vma->obj for neatness in some places (Chris)
      need_reloc_mappable() should return false if ppgtt (Chris)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      [danvet: Split out prep patches. Also remove a FIXME comment which is
      now taken care of.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      27173f1f
    • Daniel Vetter's avatar
      drm/i915: fix i9xx_crtc_clock_get for multiplied pixels · a2dc53e7
      Daniel Vetter authored
      The dpll actually runs at the port clock so we don't need
      to multiply it again with the pixel multiplier to get the
      adjusted_mode.clock. This is in contrast to the ironlake
      pixel clock readout code which uses the fdi dotclock: That
      one does _not_ run with multiplied pixels.
      
      This issue goes back to the original clock readout code added
      in
      
      commit f1f644dc
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Thu Jun 27 00:39:25 2013 +0300
      
          drm/i915: get mode clock when reading the pipe config v9
      
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a2dc53e7
    • Daniel Vetter's avatar
      drm/i915: handle sdvo input pixel multiplier correctly again · eeb47937
      Daniel Vetter authored
      The sdvo input timing needs to be the actual mode, the sdvo
      encoder automatically adjusts for the need of pixel doubling or
      quadrupling. This was lost in pipe config conversion of the
      pixel multiplier in
      
      commit 6cc5f341
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Wed Mar 27 00:44:53 2013 +0100
      
          drm/i915: add pipe_config->pixel_multiplier
      
      While at it ditch the intel_ prefix from the crtc in
      intel_sdvo_mode_set.
      
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      eeb47937
    • Daniel Vetter's avatar
      drm/i915: fix hpd work vs. flush_work in the pageflip code deadlock · 645416f5
      Daniel Vetter authored
      Historically we've run our own driver hotplug handling in our own
      work-queue, which then launched the drm core hotplug handling in the
      system workqueue. This is important since we flush our own driver
      workqueue in the pageflip code while hodling modeset locks, and only
      the drm hotplug code grabbed these locks. But with
      
      commit 69787f7d
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Tue Oct 23 18:23:34 2012 +0000
      
          drm: run the hpd irq event code directly
      
      this was changed and now we could deadlock in our flip handler if
      there's a hotplug work blocking the progress of the crucial unpin
      works. So this broke the careful deadlock avoidance implemented in
      
      commit b4a98e57
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu Nov 1 09:26:26 2012 +0000
      
          drm/i915: Flush outstanding unpin tasks before pageflipping
      
      Since the rule thus far has been that work items on our own workqueue
      may never grab modeset locks simply restore that rule again.
      
      v2: Add a comment to the declaration of dev_priv->wq to warn readers
      about the tricky implications of using it. Suggested by Chris Wilson.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Stuart Abercrombie <sabercrombie@chromium.org>
      Reported-by: default avatarStuart Abercrombie <sabercrombie@chromium.org>
      References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/26239
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Squash in a comment at the place where we schedule the work.
      Requested after-the-fact by Chris on irc since the hpd work isn't the
      only place we botch this.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      645416f5
  2. 03 Sep, 2013 20 commits
  3. 02 Sep, 2013 6 commits
  4. 01 Sep, 2013 3 commits
    • Dave Airlie's avatar
      drm/nouveau: fix up 32-bit ioctls and device wake up. · 2254f637
      Dave Airlie authored
      Noticed by kbuild test robot.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      2254f637
    • Dave Airlie's avatar
      drm/tegra: fix up page flip flags. · a5b6f74e
      Dave Airlie authored
      This was one level away from where I'd grepped.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      a5b6f74e
    • Dave Airlie's avatar
      Merge branch 'drm-next-3.12' of git://people.freedesktop.org/~agd5f/linux into drm-next · 9c725e5b
      Dave Airlie authored
      Alex writes:
      This is the radeon drm-next request.  Big changes include:
      - support for dpm on CIK parts
      - support for ASPM on CIK parts
      - support for berlin GPUs
      - major ring handling cleanup
      - remove the old 3D blit code for bo moves in favor of CP DMA or sDMA
      - lots of bug fixes
      
      [airlied: fix up a bunch of conflicts from drm_order removal]
      
      * 'drm-next-3.12' of git://people.freedesktop.org/~agd5f/linux: (898 commits)
        drm/radeon/dpm: make sure dc performance level limits are valid (CI)
        drm/radeon/dpm: make sure dc performance level limits are valid (BTC-SI) (v2)
        drm/radeon: gcc fixes for extended dpm tables
        drm/radeon: gcc fixes for kb/kv dpm
        drm/radeon: gcc fixes for ci dpm
        drm/radeon: gcc fixes for si dpm
        drm/radeon: gcc fixes for ni dpm
        drm/radeon: gcc fixes for trinity dpm
        drm/radeon: gcc fixes for sumo dpm
        drm/radeonn: gcc fixes for rv7xx/eg/btc dpm
        drm/radeon: gcc fixes for rv6xx dpm
        drm/radeon: gcc fixes for radeon_atombios.c
        drm/radeon: enable UVD interrupts on CIK
        drm/radeon: fix init ordering for r600+
        drm/radeon/dpm: only need to reprogram uvd if uvd pg is enabled
        drm/radeon: check the return value of uvd_v1_0_start in uvd_v1_0_init
        drm/radeon: split out radeon_uvd_resume from uvd_v4_2_resume
        radeon kms: fix uninitialised hotplug work usage in r100_irq_process()
        drm/radeon/audio: set up the sads on DCE3.2 asics
        drm/radeon: fix handling of variable sized arrays for router objects
        ...
      
      Conflicts:
      	drivers/gpu/drm/i915/i915_dma.c
      	drivers/gpu/drm/i915/i915_gem_dmabuf.c
      	drivers/gpu/drm/i915/intel_pm.c
      	drivers/gpu/drm/radeon/cik.c
      	drivers/gpu/drm/radeon/ni.c
      	drivers/gpu/drm/radeon/r600.c
      9c725e5b
  5. 30 Aug, 2013 2 commits