1. 03 Dec, 2012 4 commits
  2. 30 Nov, 2012 13 commits
  3. 29 Nov, 2012 23 commits
    • Luis R. Rodriguez's avatar
      i915: convert struct spinlock to spinlock_t · 99057c81
      Luis R. Rodriguez authored
      spinlock_t should always be used.
      
        LD      drivers/gpu/drm/i915/built-in.o
        CHECK   drivers/gpu/drm/i915/i915_drv.c
        CC [M]  drivers/gpu/drm/i915/i915_drv.o
        CHECK   drivers/gpu/drm/i915/i915_dma.c
        CC [M]  drivers/gpu/drm/i915/i915_dma.o
        CHECK   drivers/gpu/drm/i915/i915_irq.c
        CC [M]  drivers/gpu/drm/i915/i915_irq.o
        CHECK   drivers/gpu/drm/i915/i915_debugfs.c
      drivers/gpu/drm/i915/i915_debugfs.c:558:31: warning: dereference of noderef expression
      drivers/gpu/drm/i915/i915_debugfs.c:558:39: warning: dereference of noderef expression
      drivers/gpu/drm/i915/i915_debugfs.c:558:51: warning: dereference of noderef expression
      drivers/gpu/drm/i915/i915_debugfs.c:558:63: warning: dereference of noderef expression
        CC [M]  drivers/gpu/drm/i915/i915_debugfs.o
        CHECK   drivers/gpu/drm/i915/i915_suspend.c
        CC [M]  drivers/gpu/drm/i915/i915_suspend.o
        CHECK   drivers/gpu/drm/i915/i915_gem.c
      drivers/gpu/drm/i915/i915_gem.c:3703:14: warning: incorrect type in assignment (different base types)
      drivers/gpu/drm/i915/i915_gem.c:3703:14:    expected unsigned int [unsigned] [usertype] mask
      drivers/gpu/drm/i915/i915_gem.c:3703:14:    got restricted gfp_t
      drivers/gpu/drm/i915/i915_gem.c:3706:22: warning: invalid assignment: &=
      drivers/gpu/drm/i915/i915_gem.c:3706:22:    left side has type unsigned int
      drivers/gpu/drm/i915/i915_gem.c:3706:22:    right side has type restricted gfp_t
      drivers/gpu/drm/i915/i915_gem.c:3707:22: warning: invalid assignment: |=
      drivers/gpu/drm/i915/i915_gem.c:3707:22:    left side has type unsigned int
      drivers/gpu/drm/i915/i915_gem.c:3707:22:    right side has type restricted gfp_t
      drivers/gpu/drm/i915/i915_gem.c:3711:39: warning: incorrect type in argument 2 (different base types)
      drivers/gpu/drm/i915/i915_gem.c:3711:39:    expected restricted gfp_t [usertype] mask
      drivers/gpu/drm/i915/i915_gem.c:3711:39:    got unsigned int [unsigned] [usertype] mask
        CC [M]  drivers/gpu/drm/i915/i915_gem.o
        CHECK   drivers/gpu/drm/i915/i915_gem_context.c
        CC [M]  drivers/gpu/drm/i915/i915_gem_context.o
        CHECK   drivers/gpu/drm/i915/i915_gem_debug.c
        CC [M]  drivers/gpu/drm/i915/i915_gem_debug.o
        CHECK   drivers/gpu/drm/i915/i915_gem_evict.c
        CC [M]  drivers/gpu/drm/i915/i915_gem_evict.o
        CHECK   drivers/gpu/drm/i915/i915_gem_execbuffer.c
        CC [M]  drivers/gpu/drm/i915/i915_gem_execbuffer.o
        CHECK   drivers/gpu/drm/i915/i915_gem_gtt.c
        CC [M]  drivers/gpu/drm/i915/i915_gem_gtt.o
        CHECK   drivers/gpu/drm/i915/i915_gem_stolen.c
        CC [M]  drivers/gpu/drm/i915/i915_gem_stolen.o
        CHECK   drivers/gpu/drm/i915/i915_gem_tiling.c
        CC [M]  drivers/gpu/drm/i915/i915_gem_tiling.o
        CHECK   drivers/gpu/drm/i915/i915_sysfs.c
        CC [M]  drivers/gpu/drm/i915/i915_sysfs.o
        CHECK   drivers/gpu/drm/i915/i915_trace_points.c
        CC [M]  drivers/gpu/drm/i915/i915_trace_points.o
        CHECK   drivers/gpu/drm/i915/intel_display.c
      drivers/gpu/drm/i915/intel_display.c:1736:9: warning: mixing different enum types
      drivers/gpu/drm/i915/intel_display.c:1736:9:     int enum transcoder  versus
      drivers/gpu/drm/i915/intel_display.c:1736:9:     int enum pipe
      drivers/gpu/drm/i915/intel_display.c:3659:48: warning: mixing different enum types
      drivers/gpu/drm/i915/intel_display.c:3659:48:     int enum pipe  versus
      drivers/gpu/drm/i915/intel_display.c:3659:48:     int enum transcoder
        CC [M]  drivers/gpu/drm/i915/intel_display.o
        CHECK   drivers/gpu/drm/i915/intel_crt.c
        CC [M]  drivers/gpu/drm/i915/intel_crt.o
        CHECK   drivers/gpu/drm/i915/intel_lvds.c
        CC [M]  drivers/gpu/drm/i915/intel_lvds.o
        CHECK   drivers/gpu/drm/i915/intel_bios.c
      drivers/gpu/drm/i915/intel_bios.c:706:60: warning: incorrect type in initializer (different address spaces)
      drivers/gpu/drm/i915/intel_bios.c:706:60:    expected struct vbt_header *vbt
      drivers/gpu/drm/i915/intel_bios.c:706:60:    got void [noderef] <asn:2>*vbt
      drivers/gpu/drm/i915/intel_bios.c:726:42: warning: incorrect type in argument 1 (different address spaces)
      drivers/gpu/drm/i915/intel_bios.c:726:42:    expected void const *<noident>
      drivers/gpu/drm/i915/intel_bios.c:726:42:    got unsigned char [noderef] [usertype] <asn:2>*
      drivers/gpu/drm/i915/intel_bios.c:727:40: warning: cast removes address space of expression
      drivers/gpu/drm/i915/intel_bios.c:738:24: warning: cast removes address space of expression
        CC [M]  drivers/gpu/drm/i915/intel_bios.o
        CHECK   drivers/gpu/drm/i915/intel_ddi.c
      drivers/gpu/drm/i915/intel_ddi.c:87:6: warning: symbol 'intel_prepare_ddi_buffers' was not declared. Should it be static?
      drivers/gpu/drm/i915/intel_ddi.c:1036:34: warning: mixing different enum types
      drivers/gpu/drm/i915/intel_ddi.c:1036:34:     int enum pipe  versus
      drivers/gpu/drm/i915/intel_ddi.c:1036:34:     int enum transcoder
        CC [M]  drivers/gpu/drm/i915/intel_ddi.o
      drivers/gpu/drm/i915/intel_ddi.c: In function ‘intel_ddi_setup_hw_pll_state’:
      drivers/gpu/drm/i915/intel_ddi.c:1129:2: warning: ‘port’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      drivers/gpu/drm/i915/intel_ddi.c:1111:12: note: ‘port’ was declared here
        CHECK   drivers/gpu/drm/i915/intel_dp.c
        CC [M]  drivers/gpu/drm/i915/intel_dp.o
        CHECK   drivers/gpu/drm/i915/intel_hdmi.c
        CC [M]  drivers/gpu/drm/i915/intel_hdmi.o
        CHECK   drivers/gpu/drm/i915/intel_sdvo.c
        CC [M]  drivers/gpu/drm/i915/intel_sdvo.o
        CHECK   drivers/gpu/drm/i915/intel_modes.c
        CC [M]  drivers/gpu/drm/i915/intel_modes.o
        CHECK   drivers/gpu/drm/i915/intel_panel.c
        CC [M]  drivers/gpu/drm/i915/intel_panel.o
        CHECK   drivers/gpu/drm/i915/intel_pm.c
      drivers/gpu/drm/i915/intel_pm.c:2173:1: warning: symbol 'mchdev_lock' was not declared. Should it be static?
        CC [M]  drivers/gpu/drm/i915/intel_pm.o
        CHECK   drivers/gpu/drm/i915/intel_i2c.c
        CC [M]  drivers/gpu/drm/i915/intel_i2c.o
        CHECK   drivers/gpu/drm/i915/intel_fb.c
        CC [M]  drivers/gpu/drm/i915/intel_fb.o
        CHECK   drivers/gpu/drm/i915/intel_tv.c
        CC [M]  drivers/gpu/drm/i915/intel_tv.o
        CHECK   drivers/gpu/drm/i915/intel_dvo.c
        CC [M]  drivers/gpu/drm/i915/intel_dvo.o
        CHECK   drivers/gpu/drm/i915/intel_ringbuffer.c
        CC [M]  drivers/gpu/drm/i915/intel_ringbuffer.o
        CHECK   drivers/gpu/drm/i915/intel_overlay.c
        CC [M]  drivers/gpu/drm/i915/intel_overlay.o
        CHECK   drivers/gpu/drm/i915/intel_sprite.c
        CC [M]  drivers/gpu/drm/i915/intel_sprite.o
        CHECK   drivers/gpu/drm/i915/intel_opregion.c
        CC [M]  drivers/gpu/drm/i915/intel_opregion.o
        CHECK   drivers/gpu/drm/i915/dvo_ch7xxx.c
        CC [M]  drivers/gpu/drm/i915/dvo_ch7xxx.o
        CHECK   drivers/gpu/drm/i915/dvo_ch7017.c
        CC [M]  drivers/gpu/drm/i915/dvo_ch7017.o
        CHECK   drivers/gpu/drm/i915/dvo_ivch.c
        CC [M]  drivers/gpu/drm/i915/dvo_ivch.o
        CHECK   drivers/gpu/drm/i915/dvo_tfp410.c
        CC [M]  drivers/gpu/drm/i915/dvo_tfp410.o
        CHECK   drivers/gpu/drm/i915/dvo_sil164.c
        CC [M]  drivers/gpu/drm/i915/dvo_sil164.o
        CHECK   drivers/gpu/drm/i915/dvo_ns2501.c
        CC [M]  drivers/gpu/drm/i915/dvo_ns2501.o
        CHECK   drivers/gpu/drm/i915/i915_gem_dmabuf.c
        CC [M]  drivers/gpu/drm/i915/i915_gem_dmabuf.o
        CHECK   drivers/gpu/drm/i915/i915_ioc32.c
        CC [M]  drivers/gpu/drm/i915/i915_ioc32.o
        CHECK   drivers/gpu/drm/i915/intel_acpi.c
        CC [M]  drivers/gpu/drm/i915/intel_acpi.o
        LD [M]  drivers/gpu/drm/i915/i915.o
        Building modules, stage 2.
        MODPOST 1 modules
        CC      drivers/gpu/drm/i915/i915.mod.o
        LD [M]  drivers/gpu/drm/i915/i915.ko
      
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: intel-gfx@lists.freedesktop.org
      Cc: dri-devel@lists.freedesktop.org
      Reported-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@do-not-panic.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      99057c81
    • Paulo Zanoni's avatar
      drm/i915: kill intel_dp_link_clock() · 9fa5f652
      Paulo Zanoni authored
      Use drm_dp_bw_code_to_link_rate insead. It's the same thing, but
      supports DP_LINK_BW_5_4 and is also used by the other drivers.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9fa5f652
    • Paulo Zanoni's avatar
      drm/i915: invert the log inside intel_prepare_ddi · 0d536cb4
      Paulo Zanoni authored
      Do an early return in case we don't have DDI instead of having the
      whole function inside an "if" statement.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0d536cb4
    • Paulo Zanoni's avatar
      drm/i915: add HAS_DDI check · affa9354
      Paulo Zanoni authored
      And use it whenever we call code that uses the DDIs. We already have
      intel_ddi.c and prefix every function with intel_ddi_something instead of
      haswell_something, so I think replacing the checks with HAS_DDI makes more
      sense. Just a cosmetical change, yes I know, but I have this OCD...
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      affa9354
    • Paulo Zanoni's avatar
      drm/i915: remove Haswell code from ironlake_fdi_pll_enable · 20749730
      Paulo Zanoni authored
      This function is not called on Haswell anymore.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      20749730
    • Paulo Zanoni's avatar
      drm/i915: intel_prepare_ddi_buffers should be static · c1f63f9d
      Paulo Zanoni authored
      It's not even declared on header files.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c1f63f9d
    • Daniel Vetter's avatar
      drm/i915: optimize the shmem_pwrite slowpath handling · 8dcf015e
      Daniel Vetter authored
      Since we drop dev->struct_mutex when going through the slowpath, the
      object might have been moved out of the cpu domain. Hence we need to
      clflush the entire object to ensure that after the ioctl returns,
      everything is coherent again (interwoven writes are ill-defined
      anyway).
      
      But we only need to do this if we start in the cpu domain and the
      object requires flushing for coherency. So don't do the flushing if
      the object is coherent anyway or if we've done in-line clfushing
      already.
      
      v2: i915_gem_clflush_object already checks whether the object is
      coherent and if so, drops the flushing. Hence we don't need to check
      that ourselves, simplifying the condition.
      
      v3: Reorder the checks for better clarity (and adjust the comment
      accordingly), suggested by Chris Wilson.
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      8dcf015e
    • Daniel Vetter's avatar
      drm/i915: simplify shmem pwrite/pread slowpath handling · a39a6805
      Daniel Vetter authored
      The shmem paths for pwrite/pread used a clever trick to hold onto a
      single page when dropping the big dev->struct_mutex for the slowpath.
      But this ran the risk of reinstating (or not completely purging) the
      backing storage when dropping purgeable objects.
      
      Hence the code needed to keep track of whether it ever dropped the
      lock, and if it did, manually check whether it needs to re-purge the
      backing storage. But thanks to the pages pin count introduced in
      
      commit a5570178
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Sep 4 21:02:54 2012 +0100
      
          drm/i915: Pin backing pages whilst exporting through a dmabuf vmap
      
      which allowed us to pin the backing storage and remove that page
      reference trick from shmem_pwrite/read in
      
      commit f60d7f0c
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Sep 4 21:02:56 2012 +0100
      
          drm/i915: Pin backing pages for pread
      
      and
      
      commit 755d2218
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Sep 4 21:02:55 2012 +0100
      
          drm/i915: Pin backing pages for pwrite
      
      we can now abolish this check. The slowpath cleanup completely
      disappears from pread, and for pwrite we're only left with the domain
      fixup in case someone moved the object out of the cpu domain from
      under us. A follow-on patch will optimize that a notch more.
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a39a6805
    • Daniel Vetter's avatar
      drm/i915: enable intel_lvds->pre_pll_enable for ilk+, too · 62810e5a
      Daniel Vetter authored
      Only two things needed adjustment:
      - pipe select for PCH_CPT
      - There's no dithering bit on ilk+ in the lvds ctl reg
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      62810e5a
    • Daniel Vetter's avatar
      drm/i915: move intel_update_lvds to intel_lvds->pre_pll_enable · fc683091
      Daniel Vetter authored
      A few things needed to change:
      - HAS_PCH_SPLIT since ilk+ is not yet converted to this.
      - s/LVDS/intel_lvds->reg/ to prep for ilk conversion
      - replace the clock.p2 == 7 check with a is_dual_link check
      - s/adjusted_mode/intel_lvds->fixed_mode
      
      v2: Rebase on top of Jani Nikula's panel rework. I'm wondering whether
      we shouldn't add an attached_panel pointer to intel_encoder, to
      replace the encoder private ->attached_connector pointers, since
      that's essentially what we need.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      fc683091
    • Daniel Vetter's avatar
      drm/i915: add intel_lvds->reg · 7dec0606
      Daniel Vetter authored
      To ditch at least some of the PCH_SPLIT ? PCH_LVDS : LVDS code ...
      
      v2: Rebase on top of Jani Nikula's panel rework.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7dec0606
    • Daniel Vetter's avatar
      drm/i915: track is_dual_link in intel_lvds · 13c7d870
      Daniel Vetter authored
      Yeah, all users (both the clock selection special cases and the lvds
      pin pair stuff) are still in common code, but this will change.
      
      v2: Rebase on top of Jani Nikula's panel rework.
      
      v3: Incorporate review from Paulo Zanoni:
      - s/__is_dual_link_lvds/compute_is_dual_link_lvds
      - kill dev_priv->lvds_val
      - drop spurious whitespace change
      
      v4: Add a debug printk to display the dual-link status, as suggested
      by Paulo Zanoni in review.
      
      Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v3)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      13c7d870
    • Daniel Vetter's avatar
      drm/i915: move is_dual_link_lvds to intel_lvds.c · 1974cad0
      Daniel Vetter authored
      Just a prep patch to make this a property of intel_lvds. Makes more
      sense, removes clutter from intel_display.c and eventually I want to
      move all the encoder special cases wrt clock handling to encoders
      anyway.
      
      v2: Add an intel_ prefixe to is_dual_link_lvds since it's non-static
      now.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1974cad0
    • Daniel Vetter's avatar
      drm/i915: replace ad-hoc dual-link lvds checks · a210b028
      Daniel Vetter authored
      ... with is_dual_link_lvds introduced in
      
      commit b0354385
      Author: Takashi Iwai <tiwai@suse.de>
      Date:   Tue Mar 20 13:07:05 2012 +0100
      
          drm/i915: Check VBIOS value for determining LVDS dual channel mode, too
      
      All these checks predate this commit and have simply been overlooked.
      Since we don't support switching between single-link and dual-link
      modes anyway, this different checks could at best only get in the way
      of refactorings, and in the worst case cause inconsistencies.
      
      v2: Update the comment, we now have a solid way to figure out whether
      we need dual-link lvds or not (falling back to vbt values as a last
      resort). We still don't know how to switch between dual-link and
      single link so leave that part intact. I'm not sure though whether
      switching between these two modes makes any sense - we always drive
      the panel at its fixed mode (with a fixed bpc) anyway ...
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a210b028
    • Daniel Vetter's avatar
      drm/i915: add encoder->pre_pll_enable callback · dafd226c
      Daniel Vetter authored
      Currently we have two encoder specific bits in the common mode_set
      functions:
      - lvds pin pair enabling
      - dp m/n setting and computation
      
      Now the lvds stuff needs to happen before the pll is enabled. Since
      that is done in the crtc_mode_set functions, we need to add a new
      callback to be able to move them to the encoder code (where they
      belong). The dp m/n stuff is a giant mess anyway (since it also
      confuses itself with the fdi link m/n handling), so that needs to be
      handled separately.
      
      I think that we can move the pll enabling down quite a bit, which
      might allow us to eventually merge encoder->pre_enable with this new
      pre_pll_enable callback. But for now this will allow us to clean
      things up a bit.
      
      Note that vlv doesn't support lvds, hence we don't need to change
      anything in there.
      
      v2: Fixup commit message, both suggested from Paulo Zanoni.
      - dp m/n doesn't need to happen before pll enabling
      - lvds doesn't exist on vlv, hence no changes required in the vlv pll
        function.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      dafd226c
    • Chris Wilson's avatar
      drm/i915/debugfs: Prune a couple of superfluous leading zeros from bo domains · 04b97b34
      Chris Wilson authored
      As we do not have any domains occupying the high bits, there is no point
      in always printing the leading 00.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      04b97b34
    • Ville Syrjälä's avatar
      drm/i915: Kill i915_gem_execbuffer_wait_for_flips() · ca9c46c5
      Ville Syrjälä authored
      As per Chris Wilson's suggestion make
      i915_gem_execbuffer_wait_for_flips() go away.
      
      This was used to stall the GPU ring while there are pending
      page flips involving the relevant BO. Ie. while the BO is still
      being scanned out by the display controller.
      
      The recommended alternative is to use the page flip events to
      wait for the page flips to fully complete before reusing the BO
      of the old front buffer. Or use more buffers.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: default avatarKristian Høgsberg <krh@bitplanet.net>
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: don't remove obj->pending_flips, still required due to
      reorder patches.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ca9c46c5
    • Daniel Vetter's avatar
      drm/i915: remove duplicate register #defines · f930ddd0
      Daniel Vetter authored
      Somehow a chunk of unused register defines ended up in the middle of
      the PLL defines. They go back to the original kms merging.
      
      The only used #define is SR01, move it to the register name together
      with the other legacy vga stuff.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f930ddd0
    • Mika Kuoppala's avatar
      drm/i915: Set sync_seqno properly after seqno wrap · 7b01e260
      Mika Kuoppala authored
      i915_gem_handle_seqno_wrap() will zero all sync_seqnos but as the
      wrap can happen inside ring->sync_to(), pre wrap seqno was
      carried over and overwrote the zeroed sync_seqno.
      
      When wrap is handled, all outstanding requests will be retired and
      objects moved to inactive queue, causing their last_read_seqno to be zero.
      Use this to update the sync_seqno correctly.
      
      RING_SYNC registers after wrap will contain pre wrap values which
      are >= seqno. So injecting the semaphore wait into ring completes
      immediately.
      
      Original idea for using last_read_seqno from Chris Wilson.
      Signed-off-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7b01e260
    • Chris Wilson's avatar
      drm/i915: Include the last semaphore sync point in the error-state · df2b23d9
      Chris Wilson authored
      Should be useful to know what the driver thought the other ring's seqno
      was when it last used a semaphore.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      df2b23d9
    • Chris Wilson's avatar
      drm/i915: Rearrange code to only have a single method for waiting upon the ring · 3e960501
      Chris Wilson authored
      Replace the wait for the ring to be clear with the more common wait for
      the ring to be idle. The principle advantage is one less exported
      intel_ring_wait function, and the removal of a hardcoded value.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      3e960501
    • Chris Wilson's avatar
      drm/i915: Simplify flushing activity on the ring · b662a066
      Chris Wilson authored
      As we now always preallocate the seqno before writing to the ring, we
      can trivially test if we have any pending activity on the ring by
      inspecting the olr. This makes it then possible to flush operations that
      are not normally associated with a request, like power-management.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b662a066
    • Chris Wilson's avatar
      drm/i915: Preallocate next seqno before touching the ring · 9d773091
      Chris Wilson authored
      Based on the work by Mika Kuoppala, we realised that we need to handle
      seqno wraparound prior to committing our changes to the ring. The most
      obvious point then is to grab the seqno inside intel_ring_begin(), and
      then to reuse that seqno for all ring operations until the next request.
      As intel_ring_begin() can fail, the callers must already be prepared to
      handle such failure and so we can safely add further checks.
      
      This patch looks like it should be split up into the interface
      changes and the tweaks to move seqno wrapping from the execbuffer into
      the core seqno increment. However, I found no easy way to break it into
      incremental steps without introducing further broken behaviour.
      
      v2: Mika found a silly mistake and a subtle error in the existing code;
      inside i915_gem_retire_requests() we were resetting the sync_seqno of
      the target ring based on the seqno from this ring - which are only
      related by the order of their allocation, not retirement. Hence we were
      applying the optimisation that the rings were synchronised too early,
      fortunately the only real casualty there is the handling of seqno
      wrapping.
      
      v3: Do not forget to reset the sync_seqno upon module reinitialisation,
      ala resume.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=863861
      Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> [v2]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9d773091