Skip to content

K
Kernel

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

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 24 8月, 2022 1 次提交
  3. 09 7月, 2022 2 次提交
  5. 28 6月, 2022 4 次提交
  7. 27 6月, 2022 1 次提交
  9. 09 6月, 2022 1 次提交
    • M
      drm/i915/pvc: Add register steering · e0d7371b
      由 Matt Roper 提交于 
      Ponte Vecchio no longer has MSLICE or LNCF steering, but the bspec does
document several new types of multicast register ranges.  Fortunately,
most of the different MCR types all provide valid values at instance
(0,0) so there's no need to read fuse registers and calculate a
non-terminated instance.  We'll lump all of those range types (BSLICE,
HALFBSLICE, TILEPSMI, CC, and L3BANK) into a single category called
"INSTANCE0" to keep things simple.  We'll also perform explicit steering
for each of these multicast register types, even if the implicit
steering setup for COMPUTE/DSS ranges would have worked too; this is
based on guidance from our hardware architects who suggested that we
move away from implicit steering and start explicitly steer all MCR
register accesses on modern platforms (we'll work on transitioning
COMPUTE/DSS to explicit steering in the future).

Note that there's one additional MCR range type defined in the bspec
(SQIDI) that we don't handle here.  Those ranges use a different
steering control register that we never touch; since instance 0 is also
always a valid setting there, we can just ignore those ranges.

Finally, we'll rename the HAS_MSLICES() macro to HAS_MSLICE_STEERING().
PVC hardware still has units referred to as mslices, but there's no
register steering based on mslice for this platform.

v2:
 - Rebase on other recent changes
 - Swap two table rows to keep table sorted & easy to read.  (Harish)

Bspec: 67609
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NHarish Chegondi <harish.chegondi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608170700.4026648-1-matthew.d.roper@intel.com
      e0d7371b
  11. 02 6月, 2022 1 次提交
  13. 25 5月, 2022 1 次提交
  15. 20 5月, 2022 8 次提交
  17. 11 5月, 2022 1 次提交
  19. 07 5月, 2022 7 次提交
  21. 04 5月, 2022 1 次提交
  23. 22 4月, 2022 1 次提交
  25. 20 4月, 2022 1 次提交
  27. 24 2月, 2022 1 次提交
  29. 23 2月, 2022 1 次提交
    • J
      drm/i915/tgl: Simply subplatform detection · b9ef8939
      由 José Roberto de Souza 提交于 
      In the past we had a need to differentiate TGL U and TGL Y, there
was a different voltage swing table for each subplatform and some PCI
ids of this subplatforms are shared but it turned out that it was a
specification mistake and the voltage swing table was indeed the same
but we went ahead with that patch because we needed to differentiate
TGL U and Y from TGL H and by that time TGL H was embargoed so that
was the perfect way to land it upstream.

Now the embargo for TGL H is long past and now we even have
INTEL_TGL_12_GT1_IDS with all TGL H ids, so we can drop this PCI root
check and only rely in the PCI ids to differentiate TGL U and Y from
TGL H that actually has code differences.

Besides the simplification this will fix issues in virtualization
environments where the PCI root is virtualized and don't have the same
id as actual hardware.

v2:
- add and set INTEL_SUBPLATFORM_UY

Cc: Fred Gao <fred.gao@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Tested-by: NYu He <yu.he@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220222141424.35165-1-jose.souza@intel.com
      b9ef8939
  31. 20 2月, 2022 2 次提交
  33. 02 2月, 2022 1 次提交
  35. 27 1月, 2022 1 次提交
    • D
      drm/i915/wopcm: Handle pre-programmed WOPCM registers · db3b3f3e
      由 Daniele Ceraolo Spurio 提交于 
      Starting from DG2, some of the programming previously done by i915 and
the GuC has been moved to the GSC and the relevant registers are no
longer writable by either CPU or GuC. This is also referred to as GuC
deprivilege.
On the i915 side, this affects the WOPCM registers: these are no longer
programmed by the driver and we do instead expect to find them already
set. This can lead to verification failures because in i915 we cheat a bit
with the WOPCM size defines, to keep the code common across platforms, by
sometimes using a smaller WOPCM size that the actual HW support (which isn't
a problem because the extra size is not needed if the FW fits in the smaller
chunk), while the pre-programmed values can use the actual size.
Given tha the new programming entity is trusted, relax the amount of the
checks done on the pre-programmed values by not limiting the max
programmed size. In the extremely unlikely scenario that the registers
have been misprogrammed, we will still fail later at DMA time.

v2: drop special case for DG2 G10 A0 (Alan)
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Stuart Summers <stuart.summers@intel.com>
Cc: John Harrison <john.c.harrison@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: NAlan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220120212947.3440448-1-daniele.ceraolospurio@intel.com
      db3b3f3e
  37. 20 12月, 2021 1 次提交
  39. 15 12月, 2021 1 次提交
  41. 13 12月, 2021 1 次提交
  43. 10 12月, 2021 1 次提交