| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix typos, lingo and other small things identified during uapi
review.
v2: Also fix ALIGNMENT typo at xe_query.c
v3: Do not touch property to get/set. (Francois)
Link: https://lore.kernel.org/all/[email protected]/
Suggested-by: Thomas Hellström <[email protected]>
Cc: Thomas Hellström <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Thomas Hellström <[email protected]>
Reviewed-by: Francois Dugast <[email protected]>
|
|
Fix 2 issues when writing LRC workarounds by copying the same handling
done when processing other RTP entries:
For masked registers, it was not correctly setting the upper 16bits.
Differently than i915, the entry itself doesn't set the upper bits
for masked registers: this is done when applying them. Testing on ADL-P:
Before:
[drm:xe_gt_record_default_lrcs [xe]] LRC WA rcs0 save-restore MMIOs
[drm:xe_gt_record_default_lrcs [xe]] REG[0x2580] = 0x00000002
...
[drm:xe_gt_record_default_lrcs [xe]] REG[0x7018] = 0x00002000
[drm:xe_gt_record_default_lrcs [xe]] REG[0x7300] = 0x00000040
[drm:xe_gt_record_default_lrcs [xe]] REG[0x7304] = 0x00000200
After:
[drm:xe_gt_record_default_lrcs [xe]] LRC WA rcs0 save-restore MMIOs
[drm:xe_gt_record_default_lrcs [xe]] REG[0x2580] = 0x00060002
...
[drm:xe_gt_record_default_lrcs [xe]] REG[0x7018] = 0x20002000
[drm:xe_gt_record_default_lrcs [xe]] REG[0x7300] = 0x00400040
[drm:xe_gt_record_default_lrcs [xe]] REG[0x7304] = 0x02000200
All of these registers are masked registers, so writing to them without
the relevant bits in the upper 16b doesn't have any effect.
Also, this adds support to regular registers; previously it was assumed
that LRC entries would only contain masked registers. However this is
not true. 0x6604 is not a masked register, but used in workarounds for
e.g. ADL-P. See commit 28cf243a341a ("drm/i915/gt: Fix context
workarounds with non-masked regs"). In the same test with ADL-P as
above:
Before:
[drm:xe_gt_record_default_lrcs [xe]] REG[0x6604] = 0xe0000000
After:
[drm:xe_gt_record_default_lrcs [xe]] REG[0x6604] = 0xe0efef6f
As can be seen, now it will read what was in the register rather than
completely overwrite the other bits.
Reviewed-by: Matt Roper <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Just like the GT and engine workarounds, add debug message with the
final value being written to the register for easy debugging.
Reviewed-by: Matt Roper <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Use xe_gt_dbg() instead of drm_dbg() so the GT is added to the log for
easy identification.
Reviewed-by: Matt Roper <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
For all RTP actions, clr_bits is a superset of the bits being modified.
That's also why the check for "changing all bits" can be done with
`clr_bits + 1`. So always use clr_bits for setting the upper bits of a
masked register.
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Use 0 in format string instead of space so it shows as
[drm] *ERROR* Missing PAT table for platform with graphics version 20.04!
instead of
[drm] *ERROR* Missing PAT table for platform with graphics version 20. 4!
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: Gustavo Sousa <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The concern here is that we may have platforms with dedicated media GT,
and we anyway allocate the object on the tile, which just means running
the same test twice (i.e primary vs media GT).
Signed-off-by: Matthew Auld <[email protected]>
Cc: Nirmoy Das <[email protected]>
Reviewed-by: Nirmoy Das <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
We need to sanitize and reset each GT, since xe_bo_evict_all() will
evict everything regardless of GT, which can leave other GTs in a broken
state.
Signed-off-by: Matthew Auld <[email protected]>
Cc: Nirmoy Das <[email protected]>
Reviewed-by: Nirmoy Das <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
This fixes the build without CONFIG_PM_SLEEP such as for riscv.
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
If multiple bind ops in an array of binds touch the same address range
invalid GPUVA operations are generated as each GPUVA operation is
generated based on the orignal GPUVA state. To fix this, after each
GPUVA operations is generated, commit the GPUVA operation updating the
GPUVA state so subsequent bind ops can see a current GPUVA state.
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Add a helper to walk op list in reverse. Xe will make use of this when
unwinding GPUVA operations.
v2: (Rodrigo) reword commit message
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Remap ops have 3 parts: unmap, prev, and next. The commit step can fail
on any of these. Add a flag for each to these so the unwind is only done
the steps that have been committed.
v2: (Rodrigo) Use bit macros
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Rather than open code the shift for values, use BIT macros.
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Matches i915. Assumption going forward is that non-llc + igpu is only a
thing on MTL+ which should have explicit coherency pat_index settings
for COH_NONE, 1WAY and 2WAY.
Signed-off-by: Matthew Auld <[email protected]>
Cc: Pallavi Mishra <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Matt Roper <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: Pallavi Mishra <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
On PVC unloading followed by reloading the module often results in a
completely dead machine (seems to be plaguing CI). Resetting the GuC
like we do at load seems to cure it at least when locally testing this.
v2:
- Move pc_fini into guc_fini. We want to do the GuC reset just after
calling pc_fini, otherwise we encounter communication failures. It
also seems like a good idea to do the reset before we start releasing
the various other GuC resources. In the case of pc_fini there is an
explicit stop, but for other stuff like logs, ads, ctb there is not.
References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/542
References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/597
Signed-off-by: Matthew Auld <[email protected]>
Cc: Matthew Brost <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Reorder vm_id check after the one for VISIBLE_VRAM. This should
prevent returning with locked vm in error scenario.
Signed-off-by: Pallavi Mishra <[email protected]>
Cc: Matthew Auld <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Add patch version info on GuC firmware init. This is required info for
GuC log decoder.
Signed-off-by: Zhanjun Dong <[email protected]>
Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Some copy hardware engine instances are faster than others on PVC.
Use a virtual engine of these plus the reserved instance for the migrate
engine on PVC. The idea being if a fast instance is available it will be
used and the throughput of kernel copies, clears, and pagefault
servicing will be higher.
v2: Use OOB WA, use all copy engines if no WA is required
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Niranjana Vishwanathapura <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Wa_16017236439 requires that we update BCS_SWCTRL
(via indirect context batch buffer) to set 64B
transfers when running on an even-numbered BCS
engine and 256B on an odd-numbered BCS engine.
v2: Move WA from engine_was[] to lrc_was[]
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Tejas Upadhyay <[email protected]>
Signed-off-by: Niranjana Vishwanathapura <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Wa_16017236439 requires the BCS_SWCTRL to be privileged.
v2: Define and use BCS_SWCTRL()
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Niranjana Vishwanathapura <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Actually print the info.resv_space.
Signed-off-by: Matthew Auld <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The current only submission in the driver that doesn't use a vm is the
WA setup. We still pass a vm structure (the migration one), but we don't
actually use it at submission time and we instead have an hack to use
GGTT for this particular engine.
Instead of special-casing the WA engine, we can skip providing a VM and
use that as selector for whether to use GGTT or PPGTT. As part of this
change, we can drop the special engine flag for the WA engine and switch
the WA submission to use the standard job functions instead of dedicated
ones.
v2: rebased on s/engine/exec_queue
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Cc: Matthew Brost <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
If an engine is only destroyed on driver unload, we can skip its
clean-up steps with the GuC because the GuC is going to be tuned off as
well, so it doesn't matter if we're in sync with it or not. Currently,
we apply this optimization to all engines marked as kernel, but this
stops us to supporting kernel engines that don't stick around until
unload. To remove this limitation, add a separate flag to indicate if
the engine is expected to only be destryed on driver unload and use that
to trigger the optimzation.
While at it, add a small comment to explain what each engine flag
represents.
v2: s/XE_BUG_ON/XE_WARN_ON, s/ENGINE/EXEC_QUEUE
v3: rebased
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Cc: Matthew Brost <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Kernel queues can submit privileged batches directly in GGTT, so they
don't always need a vm. The submission front-end already supports
creating and submitting jobs without a vm, but some parts of the
back-end assume the vm is always there. Fix this by handling a lack of
vm in the back-end as well.
v2: s/XE_BUG_ON/XE_WARN_ON, s/engine/exec_queue
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Cc: Matthew Brost <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The only possible 64-bit register writes in the driver come from the
highly questionable MMIO ioctl. That ioctl's register write support
only operates for userspace running as root and cannot be used by any
real userspace; it exists solely to support the "xe_reg" debug tool in
IGT. Since the spec indicates that hardware does not officially support
64-bit register accesses, there's no reason to allow such 64-bit writes,
even for debugging.
Bspec: 60027
Reviewed-by: Lucas De Marchi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Intel hardware officially only supports GTTMMADR register accesses of
32-bits or less (although 64-bit accesses to device memory and PTEs in
the GSM are fine). Even though we do usually seem to get back
reasonable values when performing readq() operations on registers in
BAR0, we shouldn't rely on this violation of the spec working
consistently. It's likely that even when we do get proper register
values back the hardware is internally satisfying the request via a
non-atomic sequence of two 32-bit reads, which can be problematic for
timestamps and counters if rollover of the lower bits is not considered.
Replace xe_mmio_read64() with xe_mmio_read64_2x32() that implements
64-bit register reads as two 32-bit reads and attempts to ensure that
the upper dword has stabilized to avoid problematic rollovers for
counter and timestamp registers.
v2:
- Move function from xe_mmio.h to xe_mmio.c. (Lucas)
- Convert comment to kerneldoc and note that it shouldn't be used on
registers where reads may trigger side effects. (Lucas)
Bspec: 60027
Reviewed-by: Lucas De Marchi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
LNL uses the Xe2 MOCS table introduced in an earlier patch.
Bspec: 71582
Cc: Matt Roper <[email protected]>
Signed-off-by: Balasubramani Vivekanandan <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Define the GuC firmware to load on the platform.
Cc: Balasubramani Vivekanandan <[email protected]>
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
LNL is an integrated GPU based on the Xe2 architecture.
Bspec: 70821
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Balasubramani Vivekanandan <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
As with PVC, Xe2 platforms require that the index of an uncached MOCS
entry be programmed into the GUC_SHIM_CONTROL register. This will
likely be needed on future platforms as well.
Xe2 also extends the size of the MOCS index register field from two bits
to four bits. Since these extra bits were unused on PVC, it should be
safe to just increase the size of the mask.
Bspec: 60592
Cc: Haridhar Kalvala <[email protected]>
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Balasubramani Vivekanandan <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Additional minor change to remove L4_2_RESERVED, which will never be
required.
v2: Make L3/L4 names consistent for GLOB_MOCS defines (Matt Roper)
Bspec: 71582
Cc: Matt Roper <[email protected]>
Signed-off-by: Balasubramani Vivekanandan <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Starting with Xe2, a 5-level page table is always used, regardless of
the actual virtual address range supported by the platform. The two
values need to be tracked separately in the device descriptor since Xe2
platforms only have a 48 bit virtual address range.
Bspec: 59505, 65637, 70817
Cc: Balasubramani Vivekanandan <[email protected]>
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Balasubramani Vivekanandan <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Xe2_LPM media is represented by GMD_ID value 20.00.
It provides 1 VD + 1 VE + 1 SFC.
Bspec: 70821, 70819
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Balasubramani Vivekanandan <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Define a common set of Xe2 graphics feature flags and definitions that
will be used for all platforms in this family.
Several of the feature flags are inherited unchanged from Xe_HP and/or
Xe_HPC platforms:
- dma_mask_size remains 46 (Bspec 70817)
- supports_usm=1 (Bspec 59651)
- has_flatccs=1 (Bspec 58797)
- has_asid=1 (Bspec 59654, 59265, 60288)
- has_range_tlb_invalidate=1 (Bspec 71126)
However some of them still need proper implementation in the driver to
be used, so they are disabled.
Notable Xe2-specific changes:
- All Xe2 platforms use a five-level page table, regardless of the
virtual address space for the platform. (Bspec 59505)
The graphics engine mask represents the Xe2 architecture engines (Bspec
60149), but individual platforms may have a reduced set of usable
engines, as reflected by their fusing.
Cc: Balasubramani Vivekanandan <[email protected]>
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Balasubramani Vivekanandan <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Starting with Xe2, all platforms (including igpu platforms) use FlatCCS
compression rather than AuxCCS. Similar to PVC, any future platforms
that don't support FlatCCS should not attempt to fall back to AuxCCS
programming.
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Balasubramani Vivekanandan <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
On Xe2 platforms, availability of the CCS engines is reflected in the
FUSE4 register.
Bspec: 62483
Cc: Balasubramani Vivekanandan <[email protected]>
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Matt Atwood <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Engine register state layout has changed a bit on Xe2. We'll also
explicitly define a BCS layout to ensure BLIT_SWCTL and BLIT_CCTL are
included.
Bspec: 65182, 60184, 55793
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Matt Atwood <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Xe2 media has a few types of MCR registers, but all except for "GPMXMT"
can safely steer to instance 0,0. GPMXMT follows the same rules that
MTL's OADDRM ranges did, so it can re-use the same enum value.
Bspec: 71186
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Matt Atwood <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Xe2 uses the same steering control register and steering semaphore
register as MTL. As with recent platforms, group/instance 0,0 is
sufficient to target a non-terminated instance for most classes of MCR
registers; the only types of ranges that need to consider platform
fusing to find a non-terminated instance are SLICE/DSS ranges and a new
SQIDI_PSMI type of range.
Note that the range of valid bits in XE2_NODE_ENABLE_MASK may be reduced
for some Xe2 SKUs. However the lowest bits are always valid and only
the lowest instance is obtained via __ffs(), so there's no need to
complicate the masking with extra platform/subplatform checks.
Also note that Wa_14017387313 suggests skipping MCR lock acquisition
around GAM and GAMWKR registers to prevent MCR register accesses in an
interrupt handler from deadlocking when the steering semaphore is
already held outside the interrupt context. At this time Xe never
issues MCR accesses from within an interrupt handler so the workaround
is not currently needed.
v2:
- [0x008700-0x0087FF] range to extend up to 0x887F (Matt Attwood)
- [0x00EF00-0x00F4FF] -> [0x00F000, 0xFFFF] to follow latest
bspec version (Bala)
Bspec: 71185
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Balasubramani Vivekanandan <[email protected]>
Reviewed-by: Matt Atwood <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Xe2 platforms have three DSS fuse registers for both geometry and
compute.
Bspec: 67171, 67537, 67401, 67536
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Matt Atwood <[email protected]>
Reviewed-by: Balasubramani Vivekanandan <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The render and compute context are significantly smaller on Xe2 than on
previous platforms.
Registers:
- Render: 3008 dwords -> 12032 bytes -> round to 3 pages
- Compute: 1424 dwords -> 5696 bytes -> round to 2 pages
We also allocate one additional page for the HWSP, so the total
allocation sizes for render and compute are 4 and 3 pages respectively.
Bspec: 65182, 56578, 55793
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Matt Atwood <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The choice of Y-major tiling format (either the legacy "TileY" or the
newer "Tile4") is based on graphics IP version (12.50 and beyond have
Tile4, earlier platforms have TileY). The tracking in xe was originally
added to allow re-using display from i915. However as of i915 commit
4ebf43d0488f ("drm/i915: Eliminate has_4tile feature flag"), the display
code determines TileY vs Tile4 itself, so this can be removed from xe.
Reviewed-by: Lucas De Marchi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Matt Roper <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
On MTL (and only on MTL) the GSCCS defaults with idle messaging
disabled. This means that, once awoken, the GSCCS will never signal its
idleness to the GT. To allow the GT to enter the proper low-power state,
we need therefore to turn idle messaging on. As part of this, we also
need to set a proper hysteresis value for the engine.
v2: use MEDIA_VERSION() and CLR() for the RTP rule and action, add reg
bit define in descending order (Matt)
Bspec: 71496
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Cc: Vinay Belgaumkar <[email protected]>
Cc: Matt Roper <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The kernel is the only expected user of the GSCCS, so we don't want to
expose it to userspace.
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The ID for the GSC forcewake domain already exists, but we're missing
the register definitions and the domain intialization, so add that in.
v2: move reg definition to be in address order (Matt)
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Like the BCS, the GSCCS doesn't have any special HW that needs handling
when emitting commands, so we can re-use the same emit_job code. To make
it clear that this is now a shared low-level function, it has been
renamed to use the "simple" postfix, instead of "copy", to indicate that
it applies to all engines that don't need any additional engine-specific
handling.
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The GSCCS has its own enable and mask registers. The interrupt identity
for the GSCCS shows OTHER_CLASS instance 6.
Bspec: 54029, 54030
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The first step in introducing the GSCCS is to add all the basic defs for
it (name, mmio base, class/instance, lrc size etc).
Bspec: 60149, 60421, 63752
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The queue name assignment is identical in both GuC and execlists
backends, so we can move it to a common function. This will make adding
a new entry in the next patch slightly cleaner.
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Allow preemption timeout to be specified as a config option.
v2: Change unit to microseconds (Tejas)
v3: Remove get_default_preempt_timeout()
Reviewed-by: Tejas Upadhyay <[email protected]>
Signed-off-by: Niranjana Vishwanathapura <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|