Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 12 9月, 2022 2 次提交
  3. 26 8月, 2022 2 次提交
  5. 17 6月, 2022 1 次提交
  7. 25 5月, 2022 2 次提交
  9. 10 4月, 2022 1 次提交
  11. 07 4月, 2022 1 次提交
    • L
      drm/i915/uncore: Warn on previous unclaimed accesses · 4b276ed3
      由 Lucas De Marchi 提交于 
      Since gen6 we use FPGA_DBG register to detect unclaimed MMIO registers.
This register is in the display engine IP and can only ever detect
unclaimed accesses to registers in this area. However sometimes there
are reports of this triggering for registers in other areas, which
should not be possible.

Right now we always warn after the read/write of registers going through
unclaimed_reg_debug(). However places using __raw_uncore_* may be
triggering the unclaimed access and those being later accounted to a
different register. Let's warn both before and after the read/write
with a slightly different message, so it's clear if the register
reported in the warning is actually the culprit.

Commit dda96033 ("drm/i915: Just clear the mmiodebug before a
register access") attempted to solve the same issue by removing the
warning when if FPGA_DBG flags before the mmio read/write. However, it
doesn't solve it completely as FPGA_DBG may remain set when reading
registers outside display. So in the end the check after the mmio
read/write triggers the warning pointing to the wrong register.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405001149.2675226-1-lucas.demarchi@intel.com
      4b276ed3
  13. 21 3月, 2022 1 次提交
  15. 16 3月, 2022 1 次提交
  17. 17 2月, 2022 1 次提交
  19. 02 2月, 2022 1 次提交
  21. 26 1月, 2022 1 次提交
    • T
      drm/i915: Flush TLBs before releasing backing store · 7938d615
      由 Tvrtko Ursulin 提交于 
      We need to flush TLBs before releasing backing store otherwise userspace
is able to encounter stale entries if a) it is not declaring access to
certain buffers and b) it races with the backing store release from a
such undeclared execution already executing on the GPU in parallel.

The approach taken is to mark any buffer objects which were ever bound
to the GPU and to trigger a serialized TLB flush when their backing
store is released.

Alternatively the flushing could be done on VMA unbind, at which point
we would be able to ascertain whether there is potential a parallel GPU
execution (which could race), but essentially it boils down to paying
the cost of TLB flushes potentially needlessly at VMA unbind time (when
the backing store is not known to be going away so not needed for
safety), versus potentially needlessly at backing store relase time
(since we at that point cannot tell whether there is anything executing
on the GPU which uses that object).

Thereforce simplicity of implementation has been chosen for now with
scope to benchmark and refine later as required.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reported-by: NSushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NDave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7938d615
  23. 21 1月, 2022 1 次提交
  25. 12 1月, 2022 1 次提交
  27. 18 12月, 2021 1 次提交
  29. 11 11月, 2021 1 次提交
  31. 27 10月, 2021 1 次提交
  33. 04 10月, 2021 1 次提交
  35. 29 9月, 2021 1 次提交
  37. 23 9月, 2021 1 次提交
  39. 22 9月, 2021 6 次提交
  41. 11 8月, 2021 6 次提交
  43. 04 8月, 2021 1 次提交
    • M
      drm/i915/dg2: Add forcewake table · e0531636
      由 Matt Roper 提交于 
      The DG2 forcewake table is very similar to the one used by XeHP SDV (and
both platforms are even presented as a single table in the bspec).  For
the most part DG2 starts using a few additional ranges that were
'reserved' on XeHP SDV and stops using some others.  However there is a
single range (0xd800-0xd87f) that needs to be handled differently
between the two platforms (it needs GT wake on XeHP SDV, but render wake
on DG2) so unless we want to wake both domains (which could waste power)
or define new types of forcewake domains for this special case we need
to have separate tables for the two platforms.  Let's define the ranges
for both platforms with a parameterized macro so that we don't actually
need to duplicate everything in the code.

It should be fine for DG2 to re-use the Xe_HP shadow register list so we
can continue to use the 'xehpsdv' MMIO write functions and don't need to
spin up a separate DG2 instance.

Bspec: 66534
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210729170008.2836648-4-matthew.d.roper@intel.com
      e0531636
  45. 24 7月, 2021 1 次提交
  47. 08 7月, 2021 1 次提交
  49. 18 6月, 2021 1 次提交
  51. 07 6月, 2021 1 次提交
  53. 21 4月, 2021 1 次提交