1. 02 9月, 2015 1 次提交
  2. 26 8月, 2015 2 次提交
    • I
      drm/i915/bxt: work around HW coherency issue when accessing GPU seqno · 319404df
      Imre Deak 提交于
      By running igt/store_dword_loop_render on BXT we can hit a coherency
      problem where the seqno written at GPU command completion time is not
      seen by the CPU. This results in __i915_wait_request seeing the stale
      seqno and not completing the request (not considering the lost
      interrupt/GPU reset mechanism). I also verified that this isn't a case
      of a lost interrupt, or that the command didn't complete somehow: when
      the coherency issue occured I read the seqno via an uncached GTT mapping
      too. While the cached version of the seqno still showed the stale value
      the one read via the uncached mapping was the correct one.
      
      Work around this issue by clflushing the corresponding CPU cacheline
      following any store of the seqno and preceding any reading of it. When
      reading it do this only when the caller expects a coherent view.
      
      v2:
      - fix using the proper logical && instead of a bitwise & (Jani, Mika)
      - limit the workaround to A stepping, on later steppings this HW issue
        is fixed
      v3:
      - use a separate get_seqno/set_seqno vfunc (Chris)
      
      Testcase: igt/store_dword_loop_render
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      319404df
    • A
      drm/i915: Change SRM, LRM instructions to use correct length · f1afe24f
      Arun Siluvery 提交于
      MI_STORE_REGISTER_MEM, MI_LOAD_REGISTER_MEM instructions are not really
      variable length instructions unlike MI_LOAD_REGISTER_IMM where it expects
      (reg, addr) pairs so use fixed length for these instructions.
      
      v2: rebase
      
      Cc: Dave Gordon <david.s.gordon@intel.com>
      Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      [danvet: Appease checkpatch as Mika spotted in i915_reg.h - it seems
      terminally unhappy about i915_cmd_parser.c so that would be a separate
      patch.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f1afe24f
  3. 15 8月, 2015 3 次提交
    • A
      drm/i915: Integrate GuC-based command submission · d1675198
      Alex Dai 提交于
      GuC-based submission is mostly the same as execlist mode, up to
      intel_logical_ring_advance_and_submit(), where the context being
      dispatched would be added to the execlist queue; at this point
      we submit the context to the GuC backend instead.
      
      There are, however, a few other changes also required, notably:
      1.  Contexts must be pinned at GGTT addresses accessible by the GuC
          i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the
          PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls.
      
      2.  The GuC's TLB must be invalidated after a context is pinned at
          a new GGTT address.
      
      3.  GuC firmware uses the one page before Ring Context as shared data.
          Therefore, whenever driver wants to get base address of LRC, we
          will offset one page for it. LRC_PPHWSP_PN is defined as the page
          number of LRCA.
      
      4.  In the work queue used to pass requests to the GuC, the GuC
          firmware requires the ring-tail-offset to be represented as an
          11-bit value, expressed in QWords. Therefore, the ringbuffer
          size must be reduced to the representable range (4 pages).
      
      v2:
          Defer adding #defines until needed [Chris Wilson]
          Rationalise type declarations [Chris Wilson]
      
      v4:
          Squashed kerneldoc patch into here [Daniel Vetter]
      
      v5:
          Update request->tail in code common to both GuC and execlist modes.
          Add a private version of lr_context_update(), as sharing the
              execlist version leads to race conditions when the CPU and
              the GuC both update TAIL in the context image.
          Conversion of error-captured HWS page to string must account
              for offset from start of object to actual HWS (LRC_PPHWSP_PN).
      
      Issue: VIZ-4884
      Signed-off-by: NAlex Dai <yu.dai@intel.com>
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d1675198
    • D
      drm/i915: Expose one LRC function for GuC submission mode · 919f1f55
      Dave Gordon 提交于
      GuC submission is basically execlist submission, but with the GuC
      handling the actual writes to the ELSP and the resulting context
      switch interrupts.  So to describe a context for submission via
      the GuC, we need one of the same functions used in execlist mode.
      This commit exposes one such function, changing its name to better
      describe what it does (it's related to logical ring contexts rather
      than to execlists per se).
      
      v2:
          Replaces previous "drm/i915: Move execlists defines from .c to .h"
      
      v3:
          Incorporates a change to one of the functions exposed here that was
              previously part of an internal patch, but which was omitted from
              the version recently committed to drm-intel-nightly:
      	    7a01a0a2 drm/i915/lrc: Update PDPx registers with lri commands
              So we reinstate this change here.
      
      v4:
          Drop v3 change, update function parameters due to collision with
              8ee36152 drm/i915: Convert execlists_ctx_descriptor() for requests
      
      v5:
          Don't expose execlists_update_context() after all. The current
              version is no longer compatible with GuC submission; trying to
              share the execlist version of this function results in both GuC
              and CPU updating TAIL in the context image, with bad results when
              they get out of step. The GuC submission path now has its own
              private version that just updates the ringbuffer start address,
              and not TAIL or PDPx.
      
      v6:
          Rebased
      
      Issue: VIZ-4884
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      919f1f55
    • M
      drm/i915/gen8: Add 4 level switching infrastructure and lrc support · 2dba3239
      Michel Thierry 提交于
      In 64b (48bit canonical) PPGTT addressing, the PDP0 register contains
      the base address to PML4, while the other PDP registers are ignored.
      
      In LRC, the addressing mode must be specified in every context
      descriptor, and the base address to PML4 is stored in the reg state.
      
      v2: PML4 update in legacy context switch is left for historic reasons,
      the preferred mode of operation is with lrc context based submission.
      v3: s/gen8_map_page_directory/gen8_setup_page_directory and
      s/gen8_map_page_directory_pointer/gen8_setup_page_directory_pointer.
      Also, clflush will be needed for bxt. (Akash)
      v4: Squashed lrc-specific code and use a macro to set PML4 register.
      v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
      PDP update in bb_start is only for legacy 32b mode.
      v6: Rebase after final merged version of Mika's ppgtt/scratch
      patches.
      v7: There is no need to update the pml4 register value in
      execlists_update_context. (Akash)
      v8: Move pd and pdp setup functions to a previous patch, they do not
      belong here. (Akash)
      v9: Check USES_FULL_48BIT_PPGTT instead of GEN8_CTX_ADDRESSING_MODE in
      gen8_emit_bb_start to check if emit pdps is needed. (Akash)
      
      Cc: Akash Goel <akash.goel@intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+)
      Reviewed-by: NAkash Goel <akash.goel@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2dba3239
  4. 14 8月, 2015 2 次提交
  5. 21 7月, 2015 1 次提交
    • A
      drm/i915: Add provision to extend Golden context batch · 84e81020
      Arun Siluvery 提交于
      The Golden batch carries 3D state at the beginning so that HW starts with
      a known state. It is carried as a binary blob which is auto-generated from
      source. The idea was it would be easier to maintain and keep the complexity
      out of the kernel which makes sense as we don't really touch it. However if
      you really need to update it then you need to update generator source and
      keep the binary blob in sync with it.
      
      There is a need to patch this in bxt to send one additional command to enable
      a feature. A solution was to patch the binary data with some additional
      data structures (included as part of auto-generator source) but it was
      unnecessarily complicated.
      
      Chris suggested the idea of having a secondary batch and execute two batch
      buffers. It has clear advantages as we needn't touch the base golden batch,
      can customize secondary/auxiliary batch depending on Gen and can be carried
      in the driver with no dependencies.
      
      This patch adds support for this auxiliary batch which is inserted at the
      end of golden batch and is completely independent from it. Thanks to Mika
      for the preliminary review.
      
      v2: Strictly conform to the batch size requirements to cover Gen2 and
      add comments to clarify overflow check in macro (Chris, Mika).
      
      v3: aux_batch_offset was declared as u64, change it to u32 (Chris)
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Armin Reese <armin.c.reese@intel.com>
      Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      84e81020
  6. 15 7月, 2015 4 次提交
  7. 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
  8. 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
  9. 06 7月, 2015 9 次提交
  10. 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
  11. 27 6月, 2015 1 次提交
  12. 26 6月, 2015 1 次提交
  13. 24 6月, 2015 1 次提交
  14. 23 6月, 2015 12 次提交