1. 15 7月, 2015 4 次提交
  2. 14 7月, 2015 1 次提交
    • P
      drm/i915: Added Programming of the MOCS · 3bbaba0c
      Peter Antoine 提交于
      This change adds the programming of the MOCS registers to the gen 9+
      platforms. The set of MOCS configuration entries introduced by this
      patch is intended to be minimal but sufficient to cover the needs of
      current userspace - i.e. a good set of defaults. It is expected to be
      extended in the future to provide further default values or to allow
      userspace to redefine its private MOCS tables based on its demand for
      additional caching configurations. In this setup, userspace should
      only utilize the first N entries, higher entries are reserved for
      future use.
      
      It creates a fixed register set that is programmed across the different
      engines so that all engines have the same table. This is done as the
      main RCS context only holds the registers for itself and the shared
      L3 values. By trying to keep the registers consistent across the
      different engines it should make the programming for the registers
      consistent.
      
      v2:
      -'static const' for private data structures and style changes.(Matt Turner)
      v3:
      - Make the tables "slightly" more readable. (Damien Lespiau)
      - Updated tables fix performance regression.
      v4:
      - Code formatting. (Chris Wilson)
      - re-privatised mocs code. (Daniel Vetter)
      v5:
      - Changed the name of a function. (Chris Wilson)
      v6:
      - re-based
      - Added Mesa table entry (skylake & broxton) (Francisco Jerez)
      - Tidied up the readability defines (Francisco Jerez)
      - NUMBER of entries defines wrong. (Jim Bish)
      - Added comments to clear up the meaning of the tables (Jim Bish)
      Signed-off-by: NPeter Antoine <peter.antoine@intel.com>
      
      v7 (Francisco Jerez):
      - Don't write L3-specific MOCS_ESC/SCC values into the e/LLC control
        tables.  Prefix L3-specific defines consistently with L3_ and
        e/LLC-specific defines with LE_ to avoid this kind of confusion in
        the future.
      - Change L3CC WT define back to RESERVED (matches my hardware
        documentation and the original patch, probably a misunderstanding
        of my own previous comment).
      - Drop Android tables, define new minimal tables more suitable for the
        open source stack.
      - Add comment that the MOCS tables are part of the kernel ABI.
      - Move intel_logical_ring_begin() and _advance() calls one level down
        (Chris Wilson).
      - Minor formatting and style fixes.
      v8 (Francisco Jerez):
      - Add table size sanity check to emit_mocs_control/l3cc_table() (Chris
        Wilson).
      - Add comment about undefined entries being implicitly set to uncached
        for forwards compatibility.
      v9 (Francisco Jerez):
      - Minor style fixes.
      Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
      Acked-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3bbaba0c
  3. 08 7月, 2015 1 次提交
    • A
      drm/i915: Update wa_ctx_emit() macro as per kernel coding guidelines · 83b8a982
      Arun Siluvery 提交于
      wa_ctx_emit() depends on the name of a local variable; if the name of that
      variable is changed then we get compile errors. In this case it is unlikely
      to be changed as this macro is only used in this set of functions but
      Kernel coding guidelines doesn't recommend doing this. It was my mistake
      as I should have corrected it at the beginning but missed so correct
      this before there are more usages of this macro (Bob Beckett).
      
      https://www.kernel.org/doc/Documentation/CodingStyle,
      Chapter 12, "Things to avoid when using macros", point 2):
      
      "
      2) macros that depend on having a local variable with a magic name:
      
         #define FOO(val) bar(index, val)
      
      might look like a good thing, but it's confusing as hell when one reads the
      code and it's prone to breakage from seemingly innocent changes.
      "
      
      v2: Optimization to avoid multiple evaluation of 'index' in the macro.
      Since we invoke it multiple times, compiler, if it can, should be able to coalesce
      them into a single condition and remove multiple WARN_ON checks (Chris).
      Suggested-by: NRobert Beckett <robert.beckett@intel.com>
      Cc: Robert Beckett <robert.beckett@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Imre Deak <imre.deak@intel.com>
      Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      83b8a982
  4. 06 7月, 2015 9 次提交
  5. 03 7月, 2015 1 次提交
    • J
      drm/i915: Reserve space improvements · 79bbcc29
      John Harrison 提交于
      An earlier patch was added to reserve space in the ring buffer for the
      commands issued during 'add_request()'. The initial version was
      pessimistic in the way it handled buffer wrapping and would cause
      premature wraps and thus waste ring space.
      
      This patch updates the code to better handle the wrap case. It no
      longer enforces that the space being asked for and the reserved space
      are a single contiguous block. Instead, it allows the reserve to be on
      the far end of a wrap operation. It still guarantees that the space is
      available so when the wrap occurs, no wait will happen. Thus the wrap
      cannot fail which is the whole point of the exercise.
      
      Also fixed a merge failure with some comments from the original patch.
      
      v2: Incorporated suggestion by David Gordon to move the wrap code
      inside the prepare function and thus allow a single combined
      wait_for_space() call rather than doing one before the wrap and
      another after. This also makes the prepare code much simpler and
      easier to follow.
      
      v3: Fix for 'effective_size' vs 'size' during ring buffer remainder
      calculations (spotted by Tomas Elf).
      
      For: VIZ-5115
      CC: Daniel Vetter <daniel@ffwll.ch>
      Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: NTomas Elf <tomas.elf@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      79bbcc29
  6. 27 6月, 2015 1 次提交
  7. 26 6月, 2015 1 次提交
  8. 24 6月, 2015 1 次提交
  9. 23 6月, 2015 21 次提交