1. 20 Jun, 2012 1 commit
  2. 18 Jun, 2012 8 commits
  3. 16 Jun, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915/crt: Do not rely upon the HPD presence pin · aaa37730
      Daniel Vetter authored
      VGA hotplug detection "works" by measuring the resistance across
      certain pins. A lot of kvm switches fumble this and wire up cheap
      resistors with the wrong resistance or don't bother at all.
      
      To accomodate these, also try to detect a connected monitor by trying
      to grab the edid. Contrary to !HAS_HOTPLUG platforms we don't bother
      with an actual load-detection cycle when the output is life - that
      would be actual work to implement because things moved around. This is
      the big difference to Chris Wilson's original approach:
      
      commit 9e612a00
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu May 31 13:08:53 2012 +0100
      
          drm/i915/crt: Do not rely upon the HPD presence pin
      
      This blew up on Linus' machine because it errornously detected a vga
      screen (without and edid and hence only the default modes), leading to
      it's prompt removal:
      
      commit 8f53369b
      Author: Linus Torvalds <torvalds@linux-foundation.org>
      Date:   Fri Jun 8 14:53:06 2012 -0700
      
          Revert "drm/i915/crt: Do not rely upon the HPD presence pin"
      
      Some digging around in Bspec shows the reason why load detect doesn't work on
      newer chips - the legacy VGA load detect bit isn't wired up any longer:
      
      Public Snb Bspec, Vol3 Part1, 1.1.1 ST00 Input Status 0, bit4:
      
      "RGB Comparator / Sense. This bit is here for compatibility and will
      always return one. Monitor detection must be done be done through the
      programming of registers in the MMIO space.
      0 = Below threshold
      1 = Above threshold"
      
      v2: Add a comment in the code that load detect on hotplug capable
      machines is broken and pimp the commit message with a quote of Bspec
      to show why.
      Reported-and-tested-by: default avatarMatthieu LAVIE <boiteamadmax@hotmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      aaa37730
  4. 14 Jun, 2012 14 commits
    • Ben Widawsky's avatar
      drm/i915: reset the GPU on context fini · 8e96d9c4
      Ben Widawsky authored
      It's the only way we know how to make the GPU actually forget about the
      default context.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      8e96d9c4
    • Ben Widawsky's avatar
      drm/i915/context: switch contexts with execbuf2 · 6e0a69db
      Ben Widawsky authored
      Use the rsvd1 field in execbuf2 to specify the context ID associated
      with the workload. This will allow the driver to do the proper context
      switch when/if needed.
      
      v2: Add checks for context switches on rings not supporting contexts.
      Before the code would silently ignore such requests.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      6e0a69db
    • Ben Widawsky's avatar
      drm/i915/context: create & destroy ioctls · 84624813
      Ben Widawsky authored
      Add the interfaces to allow user space to create and destroy contexts.
      Contexts are destroyed automatically if the file descriptor for the dri
      device is closed.
      
      Following convention as usual here causes checkpatch warnings.
      
      v2: with is_initialized, no longer need to init at create
      drop the context switch on create (daniel)
      
      v3: Use interruptible lock (Chris)
      return -ENODEV in !GEM case (Chris)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      84624813
    • Ben Widawsky's avatar
      drm/i915: switch to default context on idle · f2ef6eb1
      Ben Widawsky authored
      To keep things as sane as possible, switch to the default context before
      idling. This should help free context objects, as well as put things in
      a more well defined state before suspending.
      
      v2: remove seqno from context switch call (daniel)
      return error on failed context switch instead of WARN+continue (daniel)
      
      v3: move idling to i915_gpu idle (from i915_gem_idle) (Chris)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      f2ef6eb1
    • Ben Widawsky's avatar
      drm/i915: add ccid to error state · b9a3906b
      Ben Widawsky authored
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      b9a3906b
    • Ben Widawsky's avatar
      drm/i915: use the default context · dfabbcb4
      Ben Widawsky authored
      With the code to do HW context switches in place have the driver load the
      default context for the render ring when the driver loads.
      
      The default context will be an ever present context that is available to
      switch to at any time for the given ring.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      dfabbcb4
    • Ben Widawsky's avatar
      drm/i915: possibly invalidate TLB before context switch · 12b0286f
      Ben Widawsky authored
      From http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol1_Part3.pdf
      
      [DevSNB] If Flush TLB invalidation Mode is enabled it's the driver's
      responsibility to invalidate the TLBs at least once after the previous
      context switch after any GTT mappings changed (including new GTT
      entries).  This can be done by a pipelined PIPE_CONTROL with TLB inv bit
      set immediately before MI_SET_CONTEXT.
      
      On GEN7 the invalidation mode is explicitly set, but this appears to be
      lacking for GEN6. Since I don't know the history on this, I've decided
      to dynamically read the value at ring init time, and use that value
      throughout.
      
      v2: better comment (daniel)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      12b0286f
    • Ben Widawsky's avatar
      drm/i915: PIPE_CONTROL_TLB_INVALIDATE · cc0f6398
      Ben Widawsky authored
      This has showed up in several other patches. It's required for the next
      context workaround.
      
      I tested this one on its own and saw no differences in basic tests
      (performance or otherwise). This patch is relatively likely to cause
      regressions, hence why it's split out.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      cc0f6398
    • Ben Widawsky's avatar
      drm/i915: Ivybridge MI_ARB_ON_OFF context w/a · e37ec39b
      Ben Widawsky authored
      The workaround itself applies to gen7 only (according to the docs) and
      as Eric Anholt points out shouldn't be required since we don't use HW
      scheduling features, and therefore arbitration. Though since it is a
      small, and simple addition, and we don't really understand the issue,
      just do it.
      
      FWIW, I eventually want to play with some of the arbitration stuff, and
      I'd hate to forget about this.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      e37ec39b
    • Daniel Vetter's avatar
      drm/i915: ensure context objects are bound to the global gtt · 3af7b857
      Daniel Vetter authored
      This way round we don't introduce and ugly layering violations and use
      the interface as I planned to use it.
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      3af7b857
    • Ben Widawsky's avatar
      drm/i915: context switch implementation · e0556841
      Ben Widawsky authored
      Implement the context switch code as well as the interfaces to do the
      context switch. This patch also doesn't match 1:1 with the RFC patches.
      The main difference is that from Daniel's responses the last context
      object is now stored instead of the last context. This aids in allows us
      to free the context data structure, and context object independently.
      
      There is room for optimization: this code will pin the context object
      until the next context is active. The optimal way to do it is to
      actually pin the object, move it to the active list, do the context
      switch, and then unpin it. This allows the eviction code to actually
      evict the context object if needed.
      
      The context switch code is missing workarounds, they will be implemented
      in future patches.
      
      v2: actually do obj->dirty=1 in switch (daniel)
      Modified comment around above
      Remove flags to context switch (daniel)
      Move mi_set_context code to i915_gem_context.c (daniel)
      Remove seqno , use lazy request instead (daniel)
      
      v3: use i915_gem_request_next_seqno instead of
            outstanding_lazy_request (Daniel)
      remove id's from trace events (Daniel)
      Put the context BO in the instruction domain (Daniel)
      Don't unref the BO is context switch fails (Chris)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      e0556841
    • Ben Widawsky's avatar
      drm/i915: context basic create & destroy · 40521054
      Ben Widawsky authored
      Invent an abstraction for a hw context which is passed around through
      the core functions. The main bit a hw context holds is the buffer object
      which backs the context. The rest of the members are just helper
      functions. Specifically the ring member, which could likely go away if
      we decide to never implement whatever other hw context support exists.
      
      Of note here is the introduction of the 64k alignment constraint for the
      BO. If contexts become heavily used, we should consider tweaking this
      down to 4k. Until the contexts are merged and tested a bit though, I
      think 64k is a nice start (based on docs).
      
      Since we don't yet switch contexts, there is really not much complexity
      here. Creation/destruction works pretty much as one would expect. An idr
      is used to generate the context id numbers which are unique per file
      descriptor.
      
      v2: add DRM_DEBUG_DRIVERS to distinguish ENOMEM failures (ben)
      convert a BUG_ON to WARN_ON, default destruction is still fatal (ben)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      40521054
    • Ben Widawsky's avatar
      drm/i915: preliminary context support · 254f965c
      Ben Widawsky authored
      Very basic code for context setup/destruction in the driver.
      
      Adds the file i915_gem_context.c This file implements HW context
      support. On gen5+ a HW context consists of an opaque GPU object which is
      referenced at times of context saves and restores.  With RC6 enabled,
      the context is also referenced as the GPU enters and exists from RC6
      (GPU has it's own internal power context, except on gen5).  Though
      something like a context does exist for the media ring, the code only
      supports contexts for the render ring.
      
      In software, there is a distinction between contexts created by the
      user, and the default HW context. The default HW context is used by GPU
      clients that do not request setup of their own hardware context. The
      default context's state is never restored to help prevent programming
      errors. This would happen if a client ran and piggy-backed off another
      clients GPU state.  The default context only exists to give the GPU some
      offset to load as the current to invoke a save of the context we
      actually care about. In fact, the code could likely be constructed,
      albeit in a more complicated fashion, to never use the default context,
      though that limits the driver's ability to swap out, and/or destroy
      other contexts.
      
      All other contexts are created as a request by the GPU client. These
      contexts store GPU state, and thus allow GPU clients to not re-emit
      state (and potentially query certain state) at any time. The kernel
      driver makes certain that the appropriate commands are inserted.
      
      There are 4 entry points into the contexts, init, fini, open, close.
      The names are self-explanatory except that init can be called during
      reset, and also during pm thaw/resume. As we expect our context to be
      preserved across these events, we do not reinitialize in this case.
      
      As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
      considered too big is arbitrary. The reason for this is even though
      context sizes are increasing with every generation, they have yet to
      eclipse even 32k. If we somehow read back way more than that, it
      probably means BIOS has done something strange, or we're running on a
      platform that wasn't designed for this.
      
      v2: rename load/unload to init/fini (daniel)
      remove ILK support for get_size() (indirectly daniel)
      add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
      added comments (Ben)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      254f965c
    • Ben Widawsky's avatar
      drm/i915: CXT_SIZE register offsets added · fe1cc68f
      Ben Widawsky authored
      The GPUs can have different default context layouts, and the sizes could
      vary based on platform or BIOS. In order to back the context object with
      a properly sized BO, we must read this register in order to find out a
      sufficient size.
      
      Thankfully (sarcarm!), the register moves and changes meanings
      throughout generations.
      
      CTX and CXT differences are intentional as that is how it is in the
      documentation (prior to GEN6 it was CXT).
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      fe1cc68f
  5. 13 Jun, 2012 3 commits
  6. 12 Jun, 2012 11 commits
  7. 06 Jun, 2012 2 commits