1. 29 10月, 2016 5 次提交
  2. 14 10月, 2016 1 次提交
    • A
      drm/i915: Allocate intel_engine_cs structure only for the enabled engines · 3b3f1650
      Akash Goel 提交于
      With the possibility of addition of many more number of rings in future,
      the drm_i915_private structure could bloat as an array, of type
      intel_engine_cs, is embedded inside it.
      	struct intel_engine_cs engine[I915_NUM_ENGINES];
      Though this is still fine as generally there is only a single instance of
      drm_i915_private structure used, but not all of the possible rings would be
      enabled or active on most of the platforms. Some memory can be saved by
      allocating intel_engine_cs structure only for the enabled/active engines.
      Currently the engine/ring ID is kept static and dev_priv->engine[] is simply
      indexed using the enums defined in intel_engine_id.
      To save memory and continue using the static engine/ring IDs, 'engine' is
      defined as an array of pointers.
      	struct intel_engine_cs *engine[I915_NUM_ENGINES];
      dev_priv->engine[engine_ID] will be NULL for disabled engine instances.
      
      There is a text size reduction of 928 bytes, from 1028200 to 1027272, for
      i915.o file (but for i915.ko file text size remain same as 1193131 bytes).
      
      v2:
      - Remove the engine iterator field added in drm_i915_private structure,
        instead pass a local iterator variable to the for_each_engine**
        macros. (Chris)
      - Do away with intel_engine_initialized() and instead directly use the
        NULL pointer check on engine pointer. (Chris)
      
      v3:
      - Remove for_each_engine_id() macro, as the updated macro for_each_engine()
        can be used in place of it. (Chris)
      - Protect the access to Render engine Fault register with a NULL check, as
        engine specific init is done later in Driver load sequence.
      
      v4:
      - Use !!dev_priv->engine[VCS] style for the engine check in getparam. (Chris)
      - Kill the superfluous init_engine_lists().
      
      v5:
      - Cleanup the intel_engines_init() & intel_engines_setup(), with respect to
        allocation of intel_engine_cs structure. (Chris)
      
      v6:
      - Rebase.
      
      v7:
      - Optimize the for_each_engine_masked() macro. (Chris)
      - Change the type of 'iter' local variable to enum intel_engine_id. (Chris)
      - Rebase.
      
      v8: Rebase.
      
      v9: Rebase.
      
      v10:
      - For index calculation use engine ID instead of pointer based arithmetic in
        intel_engine_sync_index() as engine pointers are not contiguous now (Chris)
      - For appropriateness, rename local enum variable 'iter' to 'id'. (Joonas)
      - Use for_each_engine macro for cleanup in intel_engines_init() and remove
        check for NULL engine pointer in cleanup() routines. (Joonas)
      
      v11: Rebase.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NAkash Goel <akash.goel@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1476378888-7372-1-git-send-email-akash.goel@intel.com
      3b3f1650
  3. 10 10月, 2016 3 次提交
  4. 07 10月, 2016 2 次提交
  5. 05 10月, 2016 3 次提交
  6. 26 9月, 2016 3 次提交
  7. 21 9月, 2016 1 次提交
  8. 15 9月, 2016 1 次提交
  9. 09 9月, 2016 7 次提交
  10. 02 9月, 2016 3 次提交
  11. 15 8月, 2016 7 次提交
  12. 12 8月, 2016 1 次提交
    • C
      drm/i915: Support for creating write combined type vmaps · d31d7cb1
      Chris Wilson 提交于
      vmaps has a provision for controlling the page protection bits, with which
      we can use to control the mapping type, e.g. WB, WC, UC or even WT.
      To allow the caller to choose their mapping type, we add a parameter to
      i915_gem_object_pin_map - but we still only allow one vmap to be cached
      per object. If the object is currently not pinned, then we recreate the
      previous vmap with the new access type, but if it was pinned we report an
      error. This effectively limits the access via i915_gem_object_pin_map to a
      single mapping type for the lifetime of the object. Not usually a problem,
      but something to be aware of when setting up the object's vmap.
      
      We will want to vary the access type to enable WC mappings of ringbuffer
      and context objects on !llc platforms, as well as other objects where we
      need coherent access to the GPU's pages without going through the GTT
      
      v2: Remove the redundant braces around pin count check and fix the marker
           in documentation (Chris)
      
      v3:
      - Add a new enum for the vmalloc mapping type & pass that as an argument to
         i915_object_pin_map. (Tvrtko)
      - Use PAGE_MASK to extract or filter the mapping type info and remove a
         superfluous BUG_ON.(Tvrtko)
      
      v4:
      - Rename the enums and clean up the pin_map function. (Chris)
      
      v5: Drop the VM_NO_GUARD, minor cosmetics.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NAkash Goel <akash.goel@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1471001999-17787-1-git-send-email-chris@chris-wilson.co.uk
      d31d7cb1
  13. 10 8月, 2016 1 次提交
  14. 05 8月, 2016 2 次提交