1. 01 8月, 2018 1 次提交
  2. 20 7月, 2018 1 次提交
  3. 16 7月, 2018 1 次提交
  4. 19 6月, 2018 2 次提交
  5. 24 5月, 2018 1 次提交
  6. 20 3月, 2018 1 次提交
  7. 07 3月, 2018 1 次提交
  8. 22 2月, 2018 1 次提交
  9. 16 2月, 2018 3 次提交
  10. 15 2月, 2018 1 次提交
    • R
      drm/i915/cnl: Remove alpha_support protection · ccf74400
      Rodrigo Vivi 提交于
      We now have a stable cnl on our CI and it seems mostly
      green without big risks of blank screen or anything
      blowing up on linux installations in the future.
      
      As a reminder i915.alpha_support was created to protect
      future linux installation's iso images that might contain a
      kernel from the enabling time of the new platform. Without this
      protection most of linux installation was recommending
      nomodeset option during installation that was getting stick
      there after installation.
      
      Specifically, alpha support says nothing about the development
      state of the hardware, and everything about the state of the
      driver in a kernel release.
      
      This is semantically no different from the old
      preliminary_hw_support flag, but the old one was all too often
      interpreted as (preliminary hw) support instead of the intended
      (preliminary) hw support, and it was misleading for everyone.
      Hence the rename.
      
      v2: Fix the typos and include more history about the parameter
      rename on commit message. (Jani)
      
      Reference: https://intel-gfx-ci.01.org/tree/drm-tip/fi-cnl-y3.html
      Cc: James Ausmus <james.ausmus@intel.com>
      Cc: Lucas De Marchi <lucas.demarchi@intel.com>
      Cc: Jani Saarinen <jani.saarinen@intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Acked-by: NJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180214204205.4446-1-rodrigo.vivi@intel.com
      ccf74400
  11. 01 2月, 2018 1 次提交
  12. 31 1月, 2018 1 次提交
  13. 29 1月, 2018 1 次提交
  14. 20 1月, 2018 1 次提交
  15. 21 12月, 2017 1 次提交
  16. 01 12月, 2017 1 次提交
  17. 19 10月, 2017 1 次提交
  18. 18 10月, 2017 1 次提交
  19. 07 10月, 2017 3 次提交
  20. 05 10月, 2017 1 次提交
    • C
      drm/i915/execlists: Preemption! · beecec90
      Chris Wilson 提交于
      When we write to ELSP, it triggers a context preemption at the earliest
      arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other
      operations and the explicit MI_ARB_CHECK). If this is to the same
      context, it triggers a LITE_RESTORE where the RING_TAIL is merely
      updated (used currently to chain requests from the same context
      together, avoiding bubbles). However, if it is to a different context, a
      full context-switch is performed and it will start to execute the new
      context saving the image of the old for later execution.
      
      Previously we avoided preemption by only submitting a new context when
      the old was idle. But now we wish embrace it, and if the new request has
      a higher priority than the currently executing request, we write to the
      ELSP regardless, thus triggering preemption, but we tell the GPU to
      switch to our special preemption context (not the target). In the
      context-switch interrupt handler, we know that the previous contexts
      have finished execution and so can unwind all the incomplete requests
      and compute the new highest priority request to execute.
      
      It would be feasible to avoid the switch-to-idle intermediate by
      programming the ELSP with the target context. The difficulty is in
      tracking which request that should be whilst maintaining the dependency
      change, the error comes in with coalesced requests. As we only track the
      most recent request and its priority, we may run into the issue of being
      tricked in preempting a high priority request that was followed by a
      low priority request from the same context (e.g. for PI); worse still
      that earlier request may be our own dependency and the order then broken
      by preemption. By injecting the switch-to-idle and then recomputing the
      priority queue, we avoid the issue with tracking in-flight coalesced
      requests. Having tried the preempt-to-busy approach, and failed to find
      a way around the coalesced priority issue, Michal's original proposal to
      inject an idle context (based on handling GuC preemption) succeeds.
      
      The current heuristic for deciding when to preempt are only if the new
      request is of higher priority, and has the privileged priority of
      greater than 0. Note that the scheduler remains unfair!
      
      v2: Disable for gen8 (bdw/bsw) as we need additional w/a for GPGPU.
      Since, the feature is now conditional and not always available when we
      have a scheduler, make it known via the HAS_SCHEDULER GETPARAM (now a
      capability mask).
      v3: Stylistic tweaks.
      v4: Appease Joonas with a snippet of kerneldoc, only to fuel to fire of
      the preempt vs preempting debate.
      Suggested-by: NMichal Winiarski <michal.winiarski@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michal Winiarski <michal.winiarski@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Ben Widawsky <benjamin.widawsky@intel.com>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-8-chris@chris-wilson.co.uk
      beecec90
  21. 04 10月, 2017 3 次提交
  22. 03 10月, 2017 1 次提交
  23. 22 9月, 2017 1 次提交
  24. 20 9月, 2017 1 次提交
  25. 15 9月, 2017 1 次提交
  26. 07 9月, 2017 3 次提交
  27. 01 9月, 2017 2 次提交
  28. 22 8月, 2017 1 次提交
  29. 27 7月, 2017 1 次提交
    • C
      drm/i915: Disable per-engine reset for Broxton · 2b49e721
      Chris Wilson 提交于
      Triggering a GPU reset for one engine affects another, notably
      corrupting the context status buffer (CSB) effectively losing track of
      inflight requests.
      
      Adding a few printks:
      diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
      index ad41836fa5e5..a969456bc0fa 100644
      --- a/drivers/gpu/drm/i915/i915_drv.c
      +++ b/drivers/gpu/drm/i915/i915_drv.c
      @@ -1953,6 +1953,7 @@ int i915_reset_engine(struct intel_engine_cs *engine)
                      goto out;
              }
      
      +       pr_err("Resetting %s\n", engine->name);
              ret = intel_gpu_reset(engine->i915, intel_engine_flag(engine));
              if (ret) {
                      /* If we fail here, we expect to fallback to a global reset */
      diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
      index 716e5c9ea222..a72bc35d0870 100644
      --- a/drivers/gpu/drm/i915/intel_lrc.c
      +++ b/drivers/gpu/drm/i915/intel_lrc.c
      @@ -355,6 +355,7 @@ static void execlists_submit_ports(struct intel_engine_cs *engine)
                                      execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
                              port_set(&port[n], port_pack(rq, count));
                              desc = execlists_update_context(rq);
      +                       pr_err("%s: in (rq=%x) ctx=%d\n", engine->name, rq->global_seqno, upper_32_bits(desc));
                              GEM_DEBUG_EXEC(port[n].context_id = upper_32_bits(desc));
                      } else {
                              GEM_BUG_ON(!n);
      @@ -594,9 +595,23 @@ static void intel_lrc_irq_handler(unsigned long data)
                              if (!(status & GEN8_CTX_STATUS_COMPLETED_MASK))
                                      continue;
      
      +                       pr_err("%s: out CSB (%x head=%d, tail=%d), ctx=%d, rq=%d\n",
      +                                       engine->name,
      +                                       readl(csb_mmio),
      +                                       head, tail,
      +                                       readl(buf+2*head+1),
      +                                       port->context_id);
      +
                              /* Check the context/desc id for this event matches */
      -                       GEM_DEBUG_BUG_ON(readl(buf + 2 * head + 1) !=
      -                                        port->context_id);
      +                       if (readl(buf + 2 * head + 1) != port->context_id) {
      +                               pr_err("%s: BUG CSB (%x head=%d, tail=%d), ctx=%d, rq=%d\n",
      +                                               engine->name,
      +                                               readl(csb_mmio),
      +                                               head, tail,
      +                                               readl(buf+2*head+1),
      +                                               port->context_id);
      +                               BUG();
      +                       }
      
                              rq = port_unpack(port, &count);
                              GEM_BUG_ON(count == 0);
      
      Results in:
      
      [ 6423.006602] Resetting rcs0
      [ 6423.009080] rcs0: in (rq=fffffe70) ctx=1
      [ 6423.009216] rcs0: in (rq=fffffe6f) ctx=3
      [ 6423.009542] rcs0: out CSB (2 head=1, tail=2), ctx=3, rq=3
      [ 6423.009619] Resetting bcs0
      [ 6423.009980] rcs0: BUG CSB (0 head=1, tail=2), ctx=0, rq=3
      
      Note that this bug may be affect all machines and not just Broxton,
      Broxton is just the first machine on which I have confirmed this bug.
      
      Fixes: 142bc7d9 ("drm/i915: Modify error handler for per engine hang recovery")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Acked-by: NMichel Thierry <michel.thierry@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-13-chris@chris-wilson.co.ukSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2b49e721
  30. 07 7月, 2017 1 次提交