1. 26 6月, 2012 1 次提交
  2. 20 6月, 2012 2 次提交
  3. 14 6月, 2012 2 次提交
    • B
      drm/i915/context: create & destroy ioctls · 84624813
      Ben Widawsky 提交于
      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: NBen Widawsky <ben@bwidawsk.net>
      84624813
    • B
      drm/i915: preliminary context support · 254f965c
      Ben Widawsky 提交于
      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: NBen Widawsky <ben@bwidawsk.net>
      254f965c
  4. 13 6月, 2012 3 次提交
    • D
      drm/i915: kick any firmware framebuffers before claiming the gtt · e188719a
      Daniel Vetter 提交于
      Especially vesafb likes to map everything as uc- (yikes), and if that
      mapping hangs around still while we try to map the gtt as wc the
      kernel will downgrade our request to uc-, resulting in abyssal
      performance.
      
      Unfortunately we can't do this as early as readon does (i.e. as the
      first thing we do when initializing the hw) because our fb/mmio space
      region moves around on a per-gen basis. So I've had to move it below
      the gtt initialization, but that seems to work, too. The important
      thing is that we do this before we set up the gtt wc mapping.
      
      Now an altogether different question is why people compile their
      kernels with vesafb enabled, but I guess making things just work isn't
      bad per se ...
      
      v2:
      - s/radeondrmfb/inteldrmfb/
      - fix up error handling
      
      v3: Kill #ifdef X86, this is Intel after all. Noticed by Ben Widawsky.
      
      v4: Jani Nikula complained about the pointless bool primary
      initialization.
      
      v5: Don't oops if we can't allocate, noticed by Chris Wilson.
      
      v6: Resolve conflicts with agp rework and fixup whitespace.
      Reported-and-tested-by: N"Kilarski, Bernard R" <bernard.r.kilarski@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e188719a
    • D
      drm/i915 + agp/intel-gtt: prep work for direct setup · 14be93dd
      Daniel Vetter 提交于
      To be able to directly set up the intel-gtt code from drm/i915 and
      avoid setting up the fake-agp driver we need to prepare a few things:
      - pass both the bridge and gpu pci_dev to the probe function and add
        code to handle the gpu pdev both being present (for drm/i915) and
        not present (fake agp).
      - add refcounting to the remove function so that unloading drm/i915
        doesn't kill the fake agp driver
      
      v2: Fix up the cleanup and refcount, noticed by Jani Nikula.
      Reviewed-by: NJani Nikula <jani.nikula@linux.intel.com>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      14be93dd
    • D
      drm/i915: stop using dev->agp->base · dd2757f8
      Daniel Vetter 提交于
      For that to work we need to export the base address of the gtt
      mmio window from intel-gtt. Also replace all other uses of
      dev->agp by values we already have at hand.
      Reviewed-by: NJani Nikula <jani.nikula@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      dd2757f8
  5. 06 6月, 2012 1 次提交
  6. 25 5月, 2012 1 次提交
    • B
      drm/i915: wait render timeout ioctl · 23ba4fd0
      Ben Widawsky 提交于
      This helps implement GL_ARB_sync but stops short of allowing full blown
      sync objects. Finally we can use the new timed seqno waiting function
      to allow userspace to wait on a buffer object with a timeout. This
      implements that interface.
      
      The IOCTL will take as input a buffer object handle, and a timeout in
      nanoseconds (flags is currently optional but will likely be used for
      permutations of flush operations). Users may specify 0 nanoseconds to
      instantly check.
      
      The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any
      non-zero timeout parameter the wait ioctl will wait for the given number
      of nanoseconds on an object becoming unbusy. Since the wait itself does
      so holding struct_mutex the object may become re-busied before this
      completes. A similar but shorter race condition exists in the busy
      ioctl.
      
      v2: ETIME/ERESTARTSYS instead of changing to EBUSY, and EGAIN (Chris)
      Flush the object from the gpu write domain (Chris + Daniel)
      Fix leaked refcount in good case (Chris)
      Naturally align ioctl struct (Chris)
      
      v3: Drop lock after getting seqno to avoid ugly dance (Chris)
      
      v4: check for 0 timeout after olr check to allow polling (Chris)
      
      v5: Updated the comment. (Chris)
      
      v6: Return -ETIME instead of -EBUSY when timeout_ns is 0 (Daniel)
      Fix the commit message comment to be less ugly (Ben)
      Add a warning to check the return timespec (Ben)
      
      v7: Use DRM_AUTH for the ioctl. (Eugeni)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      23ba4fd0
  7. 20 5月, 2012 1 次提交
  8. 13 5月, 2012 1 次提交
  9. 03 5月, 2012 17 次提交
  10. 02 5月, 2012 1 次提交
  11. 17 4月, 2012 1 次提交
  12. 13 4月, 2012 1 次提交
    • B
      drm/i915: rc6 in sysfs · 0136db58
      Ben Widawsky 提交于
      Merge rc6 information into the power group for our device. Until now the
      i915 driver has not had any sysfs entries (aside from the connector
      stuff enabled by drm core). Since it seems like we're likely to have
      more in the future I created a new file for sysfs stubs, as well as the
      rc6 sysfs functions which don't really belong elsewhere (perhaps
      i915_suspend, but most of the stuff is in intel_display,c).
      
      displays rc6 modes enabled (as a hex mask):
      cat /sys/class/drm/card0/power/rc6_enable
      
      displays #ms GPU has been in rc6 since boot:
      cat /sys/class/drm/card0/power/rc6_residency_ms
      
      displays #ms GPU has been in deep rc6 since boot:
      cat /sys/class/drm/card0/power/rc6p_residency_ms
      
      displays #ms GPU has been in deepest rc6 since boot:
      cat /sys/class/drm/card0/power/rc6pp_residency_ms
      
      Important note: I've seen on SNB that even when RC6 is *not* enabled the
      rc6 register seems to have a random value in it. I can only guess at the
      reason reason for this. Those writing tools that utilize this value need
      to be careful and probably want to scrutinize the value very carefully.
      
      v2: use common rc6 residency units to milliseconds for the other RC6 types
      
      v3: don't create sysfs files for GEN <= 5
      add a rc6_enable to show a mask of enabled rc6 types
      use unmerge instead of remove for sysfs group
      squash intel_enable_rc6() extraction into this patch
      
      v4: rename sysfs files (Chris)
      
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      CC: Daniel Vetter <daniel.vetter@ffwll.ch>f
      CC: Arjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NBen Widawsky <benjamin.widawsky@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      [danvet: squash in the 64bit division fix by Chris Wilson.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0136db58
  13. 10 4月, 2012 1 次提交
    • D
      drm/i915: refuse to load on gen6+ without kms · 26394d92
      Daniel Vetter 提交于
      Spurred by an irc discussion, let's start to clear up which parts of
      our kms + ums/gem + ums/dri1 + vbios/dri1 kernel driver pieces
      userspace in the wild actually uses.
      
      The idea is that we introduce checks at entry-points (module load
      time, ioctls, ...) first and then reap any obviously dead code in a
      second step.
      
      As a first step refuse to load without kms on chips where userspace
      never supported ums. Now upstream hasn't supported ums on ilk, ever.
      But RHEL had the great idea to backport the kms support to their ums
      driver.
      
      Cc: Dave Airlie <airlied@gmail.com>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      26394d92
  14. 03 4月, 2012 1 次提交
  15. 02 4月, 2012 1 次提交
  16. 29 3月, 2012 1 次提交
  17. 27 3月, 2012 3 次提交
  18. 21 3月, 2012 1 次提交