An error occurred fetching the project authors.
  1. 11 May, 2016 1 commit
  2. 10 May, 2016 1 commit
  3. 09 May, 2016 3 commits
    • Chris Wilson's avatar
      drm/i915: Store a i915 backpointer from engine, and use it · c033666a
      Chris Wilson authored
         text	   data	    bss	    dec	    hex	filename
      6309351	3578714	 696320	10584385	 a18141	vmlinux
      6308391	3578714	 696320	10583425	 a17d81	vmlinux
      
      Almost 1KiB of code reduction.
      
      v2: More s/INTEL_INFO()->gen/INTEL_GEN()/ and IS_GENx() conversions
      
         text	   data	    bss	    dec	    hex	filename
      6304579	3578778	 696320	10579677	 a16edd	vmlinux
      6303427	3578778	 696320	10578525	 a16a5d	vmlinux
      
      Now over 1KiB!
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1462545621-30125-3-git-send-email-chris@chris-wilson.co.uk
      c033666a
    • Tvrtko Ursulin's avatar
      drm/i915: Small display interrupt handlers tidy · 91d14251
      Tvrtko Ursulin authored
      I have noticed some of our interrupt handlers use both dev and
      dev_priv while they could get away with only dev_priv in the
      huge majority of cases.
      
      Tidying that up had a cascading effect on changing functions
      prototypes, so relatively big churn factor, but I think it is
      for the better.
      
      For example even where changes cascade out of i915_irq.c, for
      functions prefixed with intel_, genX_ or <plat>_, it makes more
      sense to take dev_priv directly anyway.
      
      This allows us to eliminate local variables and intermixed usage
      of dev and dev_priv where only one is good enough.
      
      End result is shrinkage of both source and the resulting binary.
      
      i915.ko:
      
       - .text         000b0899
       + .text         000b0619
      
      Or if we look at the Gen8 display irq chain:
      
       -00000000000006ad t gen8_irq_handler
       +0000000000000663 t gen8_irq_handler
         -0000000000000028 T intel_opregion_asle_intr
         +0000000000000024 T intel_opregion_asle_intr
         -000000000000008c t ilk_hpd_irq_handler
         +000000000000007f t ilk_hpd_irq_handler
         -0000000000000116 T intel_check_page_flip
         +0000000000000112 T intel_check_page_flip
         -000000000000011a T intel_prepare_page_flip
         +0000000000000119 T intel_prepare_page_flip
         -0000000000000014 T intel_finish_page_flip_plane
         +0000000000000013 T intel_finish_page_flip_plane
         -0000000000000053 t hsw_pipe_crc_irq_handler
         +000000000000004c t hsw_pipe_crc_irq_handler
         -000000000000022e t cpt_irq_handler
         +0000000000000213 t cpt_irq_handler
      
      So small shrinkage but it is all fast paths so doesn't harm.
      
      Situation is similar in other interrupt handlers as well.
      
      v2: Tidy intel_queue_rps_boost_for_request as well. (Chris Wilson)
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      91d14251
    • Ville Syrjälä's avatar
      drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT · d6199256
      Ville Syrjälä authored
      DP dual mode type 1 DVI adaptors aren't required to implement any
      registers, so it's a bit hard to detect them. The best way would
      be to check the state of the CONFIG1 pin, but we have no way to
      do that. So as a last resort, check the VBT to see if the HDMI
      port is in fact a dual mode capable DP port.
      
      v2: Deal with VBT code reorganization
          Deal with DRM_DP_DUAL_MODE_UNKNOWN
          Reduce DEVICE_TYPE_DP_DUAL_MODE_BITS a bit
          Accept both DP and HDMI dvo_port in VBT as my BSW
          at least declare its DP port as HDMI :(
      v3: Ignore DEVICE_TYPE_NOT_HDMI_OUTPUT (Shashank)
      
      Cc: stable@vger.kernel.org
      Cc: Tore Anderson <tore@fud.no>
      Reported-by: default avatarTore Anderson <tore@fud.no>
      Fixes: 7a0baa62 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1462362322-31278-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: default avatarShashank Sharma <shashank.sharma@intel.com>
      d6199256
  4. 08 May, 2016 1 commit
  5. 05 May, 2016 1 commit
  6. 04 May, 2016 1 commit
  7. 02 May, 2016 1 commit
  8. 29 Apr, 2016 10 commits
  9. 28 Apr, 2016 9 commits
  10. 25 Apr, 2016 3 commits
  11. 20 Apr, 2016 1 commit
  12. 15 Apr, 2016 2 commits
  13. 14 Apr, 2016 6 commits
    • Chris Wilson's avatar
      drm/i915: Late request cancellations are harmful · aa9b7810
      Chris Wilson authored
      Conceptually, each request is a record of a hardware transaction - we
      build up a list of pending commands and then either commit them to
      hardware, or cancel them. However, whilst building up the list of
      pending commands, we may modify state outside of the request and make
      references to the pending request. If we do so and then cancel that
      request, external objects then point to the deleted request leading to
      both graphical and memory corruption.
      
      The easiest example is to consider object/VMA tracking. When we mark an
      object as active in a request, we store a pointer to this, the most
      recent request, in the object. Then we want to free that object, we wait
      for the most recent request to be idle before proceeding (otherwise the
      hardware will write to pages now owned by the system, or we will attempt
      to read from those pages before the hardware is finished writing). If
      the request was cancelled instead, that wait completes immediately. As a
      result, all requests must be committed and not cancelled if the external
      state is unknown.
      
      All that remains of i915_gem_request_cancel() users are just a couple of
      extremely unlikely allocation failures, so remove the API entirely.
      
      A consequence of committing all incomplete requests is that we generate
      excess breadcrumbs and fill the ring much more often with dummy work. We
      have completely undone the outstanding_last_seqno optimisation.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93907Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-16-git-send-email-chris@chris-wilson.co.uk
      aa9b7810
    • Chris Wilson's avatar
      drm/i915: Prevent leaking of -EIO from i915_wait_request() · f4457ae7
      Chris Wilson authored
      Reporting -EIO from i915_wait_request() has proven very troublematic
      over the years, with numerous hard-to-reproduce bugs cropping up in the
      corner case of where a reset occurs and the code wasn't expecting such
      an error.
      
      If the we reset the GPU or have detected a hang and wish to reset the
      GPU, the request is forcibly complete and the wait broken. Currently, we
      report either -EAGAIN or -EIO in order for the caller to retreat and
      restart the wait (if appropriate) after dropping and then reacquiring
      the struct_mutex (essential to allow the GPU reset to proceed). However,
      if we take the view that the request is complete (no further work will
      be done on it by the GPU because it is dead and soon to be reset), then
      we can proceed with the task at hand and then drop the struct_mutex
      allowing the reset to occur. This transfers the burden of checking
      whether it is safe to proceed to the caller, which in all but one
      instance it is safe - completely eliminating the source of all spurious
      -EIO.
      
      Of note, we only have two API entry points where we expect that
      userspace can observe an EIO. First is when submitting an execbuf, if
      the GPU is terminally wedged, then the operation cannot succeed and an
      -EIO is reported. Secondly, existing userspace uses the throttle ioctl
      to detect an already wedged GPU before starting using HW acceleration
      (or to confirm that the GPU is wedged after an error condition). So if
      the GPU is wedged when the user calls throttle, also report -EIO.
      
      v2: Split more carefully the change to i915_wait_request() and assorted
      ABI from the reset handling.
      v3: Add a couple of WARN_ON(EIO) to the interruptible modesetting code
      so that we don't start to leak EIO there in future (and break our hang
      resistant modesetting).
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-9-git-send-email-chris@chris-wilson.co.uk
      Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-1-git-send-email-chris@chris-wilson.co.uk
      f4457ae7
    • Chris Wilson's avatar
      drm/i915: Store the reset counter when constructing a request · 299259a3
      Chris Wilson authored
      As the request is only valid during the same global reset epoch, we can
      record the current reset_counter when constructing the request and reuse
      it when waiting upon that request in future. This removes a very hairy
      atomic check serialised by the struct_mutex at the time of waiting and
      allows us to transfer those waits to a central dispatcher for all
      waiters and all requests.
      
      PS: With per-engine resets, we obviously cannot assume a global reset
      epoch for the requests - a per-engine epoch makes the most sense. The
      challenge then is how to handle checking in the waiter for when to break
      the wait, as the fine-grained reset may also want to requeue the
      request (i.e. the assumption that just because the epoch changes the
      request is completed may be broken - or we just avoid breaking that
      assumption with the fine-grained resets).
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-7-git-send-email-chris@chris-wilson.co.uk
      299259a3
    • Chris Wilson's avatar
      drm/i915: Tighten reset_counter for reset status · d98c52cf
      Chris Wilson authored
      In the reset_counter, we use two bits to track a GPU hang and reset. The
      low bit is a "reset-in-progress" flag that we set to signal when we need
      to break waiters in order for the recovery task to grab the mutex. As
      soon as the recovery task has the mutex, we can clear that flag (which
      we do by incrementing the reset_counter thereby incrementing the gobal
      reset epoch). By clearing that flag when the recovery task holds the
      struct_mutex, we can forgo a second flag that simply tells GEM to ignore
      the "reset-in-progress" flag.
      
      The second flag we store in the reset_counter is whether the
      reset failed and we consider the GPU terminally wedged. Whilst this flag
      is set, all access to the GPU (at least through GEM rather than direct mmio
      access) is verboten.
      
      PS: Fun is in store, as in the future we want to move from a global
      reset epoch to a per-engine reset engine with request recovery.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-6-git-send-email-chris@chris-wilson.co.uk
      d98c52cf
    • Chris Wilson's avatar
      drm/i915: Hide the atomic_read(reset_counter) behind a helper · c19ae989
      Chris Wilson authored
      This is principally a little bit of syntatic sugar to hide the
      atomic_read()s throughout the code to retrieve the current reset_counter.
      It also provides the other utility functions to check the reset state on the
      already read reset_counter, so that (in later patches) we can read it once
      and do multiple tests rather than risk the value changing between tests.
      
      v2: Be more strict on converting existing i915_reset_in_progress() over to
      the more verbose i915_reset_in_progress_or_wedged().
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-4-git-send-email-chris@chris-wilson.co.uk
      c19ae989
    • Chris Wilson's avatar
      drm/i915: Add GEM debugging Kconfig option · d501b1d2
      Chris Wilson authored
      Currently there is a #define to enable extra BUG_ON for debugging
      requests and associated activities. I want to expand its use to cover
      all of GEM internals (so that we can saturate the code with asserts).
      We can add a Kconfig option to make it easier to enable - with the usual
      caveats of not enabling unless explicitly requested.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-3-git-send-email-chris@chris-wilson.co.uk
      d501b1d2