Matt Roper [Thu, 6 Apr 2023 23:56:16 +0000 (16:56 -0700)]
drm/xe: Move engine masks into IP descriptor structures
Break the top-level platform_engine_mask field into separate
hw_engine_mask fields in the graphics and media structures. Since
hardware has more flexibility to mix-and-match IP versions going
forward, this allows each IP to list exactly which engines it provides;
the final per-GT engine list can then be constructured from those:
* On platforms without a standalone media GT (i.e., media IP versions
prior to 13), the primary GT's engine list is the union of the
graphics IP's engine list and the media IP's engine list.
* Otherwise, GT0's engine list is the graphics IP's engine list.
* For GT1 and beyond, the type of GT determines which IP's engine list
is used.
Matt Roper [Thu, 6 Apr 2023 23:56:15 +0000 (16:56 -0700)]
drm/xe: Move most platform traits to graphics IP
Most of the traits currently in the device descriptor structures are
either tied to the graphics IP or should be inferred from the graphics
IP. This becomes important on MTL and beyond where IP versions are
supposed to be detected from the hardware's GMD_ID registers rather than
mapped from PCI devid.
Engine masks are left where they are for now; they'll be dealt with
separately in a future patch.
Matt Roper [Thu, 6 Apr 2023 23:56:14 +0000 (16:56 -0700)]
drm/xe: Set require_force_probe in each platform's description
Set require_force_probe explicitly in each platform's description
structure rather than embedding it within the FOO_FEATURES macros. Even
though we expect all platforms currently supported by the Xe driver to
be under force_probe protection, this will help prepare for some other
upcoming restructuring.
Matt Roper [Thu, 6 Apr 2023 23:56:13 +0000 (16:56 -0700)]
drm/xe: Start splitting xe_device_desc into graphics/media structures
Rather than storing all characteristics for an entire platform in the
xe_device_desc structure, create secondary graphics and media structures
to hold traits and feature flags specific to those IPs. This will
eventually allow us to assign the graphics and media characteristics at
runtime based on the contents of the relevant GMD_ID registers.
For now, just move the IP versions into the new structures to keep
things simple. Other IP-specific fields will migrate to these
structures in future patches.
Note that there's one functional change introduced by this: previously
PVC was recognized as media version 12.60. That's technically true, but
in practice the media engines are fused off on all production hardware.
By simply not assigning a media IP structure to PVC it will effectively
be treated as IP version 0.0 now (which the rest of the driver should
treat as non-existent media).
v2:
- Split the new structures out to their own header. This will ease the
addition of KUnit tests later.
Lucas De Marchi [Wed, 5 Apr 2023 22:47:25 +0000 (15:47 -0700)]
drm/xe: Always log GuC/HuC firmware versions
When debugging issues related to GuC/HuC, it's important to know what is
the firmware version being used. The version from the filename can't be
relied upon, also because it normally only contains the major version
(except for the ones under experimental support).
Log the version from the blob after reading the CSS header. Example:
xe 0000:03:00.0: [drm] Using GuC firmware (70.5) from i915/dg2_guc_70.bin
Lucas De Marchi [Fri, 24 Mar 2023 05:17:54 +0000 (22:17 -0700)]
drm/xe: Update GuC/HuC firmware autoselect logic
Update the logic to autoselect GuC/HuC for the platforms with the
following improvements:
- Document what is the firmware file that is expected to be
loaded and what is checked from blob headers
- When the platform is under force-probe it's desired to enforce
the full-version requirement so the correct firmware is used
before widespread adoption and backward-compatibility
commitments
- Directory from which we expect firmware blobs to be available in
upstream linux-firmware repository depends on the platform: for
the ones supported by i915 it uses the i915/ directory, but the ones
expected to be supported by xe, it's on the xe/ directory. This
means that for platforms in the intersection, the firmware is
loaded from a different directory, but that is not much important
in the firmware repo and it avoids firmware duplication.
- Make the table with the firmware definitions clearly state the
versions being expected. Now with macros to select the version it's
possible to choose between full-version/major-version for GuC and
full-version/no-version for HuC. These are similar to the macros used
in i915, but implemented in a slightly different way to avoid
duplicating the macros for each firmware/type and functionality,
besides adding the support for different directories.
- There is no check added regarding force-probe since xe should
reuse the same firmware files published for i915 for past
platforms. This can be improved later with additional
kunit checking against a hardcoded list of platforms that
falls in this category.
- As mentioned in the TODO, the major version fallback was not
implemented before as currently each platform only supports one
major. That can be easily added later.
- GuC version for MTL and PVC were updated to 70.6.4, using the exact
full version, while the
After this the GuC firmware used by PVC changes to pvc_guc_70.5.2.bin
since it's using a file not published yet.
Lucas De Marchi [Sat, 1 Apr 2023 08:51:51 +0000 (01:51 -0700)]
drm/xe: Add test for GT workarounds and tunings
In order to avoid mistakes when populating the workarounds, it's good to
be able to test if the entries added are all compatible for a certain
platform. The platform itself is not needed as long as we create fake
devices with enough configuration for the RTP helpers to process the
tables. Common mistakes that can be avoided:
- Entries clashing the bitfields being updated
- Register type being mixed (MCR vs regular / masked vs regular)
- Unexpected errors while adding the reg_sr entry
To test, inject a duplicate entry in gt_was, but with platform == tigerlake
rather than the currenct graphics version check:
Lucas De Marchi [Sat, 1 Apr 2023 08:51:50 +0000 (01:51 -0700)]
drm/xe: Add basic unit tests for rtp
Add some basic unit tests for rtp. This is intended to prove the
functionality of the rtp itself, like coalescing entries, rejecting
non-disjoint values, etc.
Contrary to the other tests in xe, this is a unit test to test the
sw-side only, so it can be executed on any machine - it doesn't interact
with the real hardware. Running it produces the following output:
$ ./tools/testing/kunit/kunit.py run --raw_output-kunit \
--kunitconfig drivers/gpu/drm/xe/.kunitconfig xe_rtp
...
[01:26:27] Starting KUnit Kernel (1/1)...
KTAP version 1
1..1
KTAP version 1
# Subtest: xe_rtp
1..1
KTAP version 1
# Subtest: xe_rtp_process_tests
ok 1 coalesce-same-reg
ok 2 no-match-no-add
ok 3 no-match-no-add-multiple-rules
ok 4 two-regs-two-entries
ok 5 clr-one-set-other
ok 6 set-field
[drm:xe_reg_sr_add] *ERROR* Discarding save-restore reg 0001 (clear: 00000001, set: 00000001, masked: no): ret=-22
ok 7 conflict-duplicate
[drm:xe_reg_sr_add] *ERROR* Discarding save-restore reg 0001 (clear: 00000003, set: 00000000, masked: no): ret=-22
ok 8 conflict-not-disjoint
[drm:xe_reg_sr_add] *ERROR* Discarding save-restore reg 0001 (clear: 00000002, set: 00000002, masked: no): ret=-22
[drm:xe_reg_sr_add] *ERROR* Discarding save-restore reg 0001 (clear: 00000001, set: 00000001, masked: yes): ret=-22
ok 9 conflict-reg-type
# xe_rtp_process_tests: pass:9 fail:0 skip:0 total:9
ok 1 xe_rtp_process_tests
# Totals: pass:9 fail:0 skip:0 total:9
ok 1 xe_rtp
...
Note that the ERRORs in the kernel log are expected since it's testing
incompatible entries.
v2:
- Use parameterized table for tests (Michał Winiarski)
- Move everything to the xe_rtp_test.ko and only add a few exports to the
right namespace
- Add more tests to cover FIELD_SET, CLR, partially true rules, etc
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Maarten Lankhorst<maarten.lankhorst@linux.intel.com> # v1 Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://lore.kernel.org/r/20230401085151.1786204-7-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Sat, 1 Apr 2023 08:51:49 +0000 (01:51 -0700)]
drm/xe/reg_sr: Save errors for kunit integration
When there's an entry that is dropped when xe_reg_sr_add(), there's
not much we can do other than reporting the error - it's for certain a
driver issue or conflicting workarounds/tunings. Save the number of
errors to be used later by kunit to report where it happens.
Lucas De Marchi [Sat, 1 Apr 2023 08:51:48 +0000 (01:51 -0700)]
drm/xe: Generalize fake device creation
Instead of requiring tests to initialize a fake device an keep it in
sync with xe_pci.c when it's platform-dependent, export a function from
xe_pci.c to be used and piggy back on the device info creation. For
simpler tests that don't need any specific platform and just need a fake
xe device to pass around, xe_pci_fake_device_init_any() can be used.
Lucas De Marchi [Sat, 1 Apr 2023 08:51:47 +0000 (01:51 -0700)]
drm/xe: Use symbol namespace for kunit tests
Instead of simply using EXPORT_SYMBOL() to export the functions needed
in xe.ko to be be called across modules, use EXPORT_SYMBOL_IF_KUNIT()
which will export the symbol under the EXPORTED_FOR_KUNIT_TESTING
namespace.
This avoids accidentally "leaking" these functions and letting them be
called from outside the kunit tests. If these functiosn are accidentally
called from another module, they receive a modpost error like below:
ERROR: modpost: module XXXXXXX uses symbol
xe_ccs_migrate_kunit from namespace EXPORTED_FOR_KUNIT_TESTING,
but does not import it.
Lucas De Marchi [Sat, 1 Apr 2023 08:51:46 +0000 (01:51 -0700)]
drm/xe: Move test infra out of xe_pci.[ch]
Move code out of xe_pci.[ch] into tests/*.[ch], like is done in other
similar compilation units. Even if this is not part of "tests for
xe_pci.c", they are functions exported and required by other tests. It's
better not to clutter the module headers and sources with them.
Lucas De Marchi [Sat, 1 Apr 2023 08:51:45 +0000 (01:51 -0700)]
drm/xe: Extract function to initialize xe->info
Extract the part setting up from xe->info from xe_pci_probe() into its
own function. This pairs nicely with the display counterpart, avoids
info initialization to be placed elsewhere and helps future
improvements to build fake devices for tests.
While at it, normalize the names a little bit: the _get() suffix may be
mistaken by lock-related operation, so rename the function to
"find_subplatform()". Also rename the variable to subplatform_desc to
make it easier to understand, even if longer.
Matt Roper [Sat, 1 Apr 2023 00:21:06 +0000 (17:21 -0700)]
drm/xe/irq: Don't clobber display interrupts on multi-tile platforms
Although our only multi-tile platform today (PVC) doesn't support
display, it's possible that some future multi-tile platform will.
If/when this happens, display interrupts (both traditional display and
ASLE backlight interrupts raised as a Gunit interrupt) should be
delivered to the primary tile. Save away tile0's master_ctl value so
that it can still be used for display interrupt handling after the GT
loop.
Matt Roper [Sat, 1 Apr 2023 00:21:05 +0000 (17:21 -0700)]
drm/xe/irq: Drop commented-out code for non-existent media engines
Although the hardware team has set aside some register bits for extra
media engines, no platform supported by the Xe driver today has VCS4-7
or VECS2-3. Drop the corresponding code (which was already commented
out); we can bring it back easily enough if such engines show up on a
future platform.
Matt Roper [Sat, 1 Apr 2023 00:21:03 +0000 (17:21 -0700)]
drm/xe/irq: Rename and clarify top-level interrupt handling routines
Platforms supported by the Xe driver handle top-level interrupts in one
of two ways:
- Xe_LP platforms only have a "graphics master" register and lack a
"master tile" register, so top-level interrupt detection and
enable/disable happens in the graphics master.
- Xe_LP+ (aka DG1) and beyond have a "master tile" interrupt register
that controls the enable/disable of top-level interrupts and must
also be consulted to determine which tiles have received interrupts
before the driver moves on the process the graphics master register.
For functions that are only relevant to the first set of platforms,
rename the function prefix to Xe_LP since "gen11" doesn't make sense in
the Xe driver. Also add some comments briefly describing the two
top-level handlers.
Matt Roper [Sat, 1 Apr 2023 00:21:02 +0000 (17:21 -0700)]
drm/xe/irq: Drop unnecessary GEN11_ and GEN12_ register prefixes
Any interrupt registers that were introduced by platforms i915
considered to be "gen11" or "gen12" are present on all platforms that
the Xe driver supports; drop the unnecessary prefixes.
While working in the area, also convert a few open-coded bit
manipulations over to REG_BIT and REG_FIELD_GET notation.
Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230401002106.588656-5-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo: removed display. That was later squashed to the xe Display patch]
Matt Roper [Sat, 1 Apr 2023 00:21:01 +0000 (17:21 -0700)]
drm/xe/irq: Drop IRQ_INIT and IRQ_RESET macros
It's no longer necessary to wrap these operations in macros; a simple
function will suffice. Also switch to function names that more clearly
describe what operation is being performed: unmask_and_enable() and
mask_and_disable().
Matt Roper [Sat, 1 Apr 2023 00:21:00 +0000 (17:21 -0700)]
drm/xe/irq: Add helpers to find ISR/IIR/IMR/IER registers
For cases where IRQ_INIT and IRQ_RESET are used, the relevant interrupt
registers are always consecutive and ordered ISR, IMR, IIR, IER. Adding
helpers to look these up from a base offset will let us eliminate some
of the CPP pasting and simplify other upcoming patches.
v2:
- s/_REGS/_OFFSET/ for consistency. (Lucas)
- Move IMR/IIR/IER helpers into xe_irq.c; they aren't needed anywhere
else. (Lucas)
Matt Roper [Sat, 1 Apr 2023 00:20:59 +0000 (17:20 -0700)]
drm/xe/irq: Drop gen3_ prefixes
"Gen" terminology should be avoided in the Xe driver and "gen3" refers
to platforms that are 9 (!!) graphics generations earlier than the
oldest supported by the Xe driver, so this prefix really doesn't make
sense.
There are a couple issues, but the main one is due to TTM has only
one TTM_PL_TT region, but since pvc has 2 tiles and tries to setup
1 TTM_PL_TT each tile. The second will overwrite the first one.
During unload time, the first tile will reset the TTM_PL_TT manger
and when the second tile is trying to free Bo and it will generate
the null reference since the TTM manage is already got reset to 0.
The fix is to use one global TTM_PL_TT manager.
v2: make gtt mgr global and change the name to sys_mgr
Cc: Stuart Summers <stuart.summers@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Vivi, Rodrigo <rodrigo.vivi@intel.com> Signed-off-by: Bruce Chang <yu.bruce.chang@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Fri, 31 Mar 2023 23:09:02 +0000 (16:09 -0700)]
drm/xe: Fix platform order
Platform order in enum xe_platform started to be used by some parts of
the code, like the GuC/HuC firmware loading logic. The order itself is
not very important, but it's better to follow a convention: as was
documented in the comment above the enum, reorder the platforms by
graphics version. While at it, remove the gen terminology.
v2:
- Use "graphics version" instead of chronological order (Matt Roper)
- Also change pciidlist to follow the same order
- Remove "gen" from comments around enum xe_platform
In xe_migrate_sanity_kunit test, use correct expected value as
the expected value was not only used for the xe_migrate_clear(),
but also for the xe_migrate_copy() operation.
v2: Add 'Fixes' tag and update commit text
Fixes: 11a2407ed5f0 ("drm/xe: Stop accepting value in xe_migrate_clear") Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Fri, 24 Mar 2023 05:17:52 +0000 (22:17 -0700)]
drm/xe: Remove unused revid from firmware name
The rev field is always 0 so it ends up never used. In i915 it was
introduced because of CML: up to rev 5 it reuses the guc and huc
firmware blobs from KBL. After that there is a specific firmware for
that platform. This can be reintroduced later if ever needed.
With the removal of revid the packed attribute in
uc_fw_platform_requirement, which is there only for reducing the space
these tables take, can also be removed since it has even more limited
usefulness: currently there's only padding of 2 bytes. Remove the
attribute to avoid the unaligned access.
Matt Roper [Wed, 29 Mar 2023 17:33:34 +0000 (10:33 -0700)]
drm/xe: Don't emit extra MI_BATCH_BUFFER_END in WA batchbuffer
The MI_BATCH_BUFFER_END is already added automatically by
__xe_bb_create_job(); including it in the construction of the workaround
batchbuffer results in an unnecessary duplicate.
Matt Roper [Wed, 29 Mar 2023 17:33:33 +0000 (10:33 -0700)]
drm/xe: Adjust batchbuffer space warning when creating a job
We should WARN (not BUG) when creating a job if the batchbuffer does not
have sufficient space and padding. The hardware prefetch requirements
should also be considered.
Matt Roper [Wed, 29 Mar 2023 17:33:32 +0000 (10:33 -0700)]
drm/xe: Include hardware prefetch buffer in batchbuffer allocations
The hardware prefetches several cachelines of data from batchbuffers
before they are parsed. This prefetching only stops when the parser
encounters an MI_BATCH_BUFFER_END instruction (or a nested
MI_BATCH_BUFFER_START), so we must ensure that there is enough padding
at the end of the batchbuffer to prevent the prefetcher from running
past the end of the allocation and potentially faulting.
Matthew Auld [Thu, 23 Mar 2023 11:59:22 +0000 (11:59 +0000)]
drm/xe/bo: refactor try_add_vram
Get rid of some of the duplication here. In a future patch we need to
also consider [fpfn, lpfn], so better adjust in only one place.
Suggested-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Auld [Thu, 23 Mar 2023 11:59:21 +0000 (11:59 +0000)]
drm/xe: add XE_BO_CREATE_VRAM_MASK
So we don't have to keep repeating VRAM0 | VRAM1. Also if there are ever
more instances, then we have less places to update.
Suggested-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Fri, 24 Mar 2023 21:04:15 +0000 (14:04 -0700)]
drm/xe/mtl: Handle PAT_INDEX offset jump
Starting with MTL, the number of entries in the PAT table increased to
16. The register offset jumped between index 7 and index 8, so a slight
adjustment is needed to ensure the PAT_INDEX macros select the proper
offset for the upper half of the table.
Note that although there are 16 registers in the hardware, the driver is
currently only asked to program the first 5, and we leave the rest at
their hardware default values. That means we don't actually touch the
upper half of the PAT table in the driver today and this patch won't
have any functional effect [yet].
Matt Roper [Fri, 24 Mar 2023 21:04:14 +0000 (14:04 -0700)]
drm/xe/mtl: Fix PAT table coherency settings
Re-sync our MTL PAT table with the bspec. 1-way coherency should only
be set on table entry 3. We do not want an incorrect setting here to
accidentally paper over other bugs elsewhere in the driver.
Matt Roper [Fri, 24 Mar 2023 21:04:12 +0000 (14:04 -0700)]
drm/xe/pat: Handle unicast vs MCR PAT registers
The PAT_INDEX registers are MCR registers on some platforms and unicast
on others. On MTL the handling even varies between GTs: the primary GT
uses MCR registers while the media GT uses unicast registers. Let's add
proper MCR programming on the relevant platforms/GTs.
Given that we PAT tables to change pretty regularly on future platforms,
we'll make PAT programming an exception to the usual model of assuming
new platforms should inherit the previous platform's behavior. Instead
we'll raise a warning if the current platform isn't handled in the
if/else ladder. This should help prevent subtle cache misbehavior if we
forget to add the table for a new platform.
Matt Roper [Fri, 24 Mar 2023 21:04:11 +0000 (14:04 -0700)]
drm/xe/pat: Use table-based programming of PAT settings
Provide per-platform tables of PAT values rather than per-platform
functions. This will simplify the handling of unicast vs MCR registers
in the upcoming patches.
Matthew Brost [Fri, 24 Mar 2023 16:33:36 +0000 (09:33 -0700)]
drm/xe: Decrement fault mode counts in xe_vm_close_and_put
Rather waiting for the VM to be destroyed (all refs to VM go to zero),
drop the fault mode counts when the VM is closed in xe_vm_close_and_put.
This avoids a window where user space can create a faulting VM, close
it, and a subsequent creation of a non-faulting VM fails.
Intel Vulkan driver needs to know what is the maximum priority to fill
a device info struct for applications.
Right now we getting this information by creating a engine and setting
priorities from min to high to know what is the maximum priority for
running process but this leads to info messages to be printed to
dmesg:
xe 0000:03:00.0: [drm] Ioctl argument check failed at drivers/gpu/drm/xe/xe_engine.c:178: value == DRM_SCHED_PRIORITY_HIGH && !capable(CAP_SYS_NICE)
It does not cause any harm but when executing a test suite like
crucible it causes thousands of those messages to be printed.
So here adding one more property to drm_xe_query_config to fetch the
max engine priority.
Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Anusha Srivatsa [Thu, 23 Mar 2023 22:46:51 +0000 (15:46 -0700)]
drm/xe: Load HuC on Alderlake S
Alderlake S uses TGL HuC.
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230323224651.1187366-3-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Anusha Srivatsa [Thu, 23 Mar 2023 22:46:50 +0000 (15:46 -0700)]
drm/xe/huc: Support for loading unversiond HuC
Follow the new direction of firmware and add macro
support for loading unversioned HuC. Keep HuC
versioned loading support as well for platforms
that fall under force_probe support
Add check to ensure driver does not do any version check
for HuC if going through unversioned load.
v2: unversioned firmware to be the default for platforms
not under force_probe. Maintain versioned firmware macro support
for platforms under force-probe protection.
v3: Minor style and naming adjustments (Lucas)
Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230323224651.1187366-2-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Within a class the GuC will hault scheduling if the head of the queue
can't be scheduled the queue will block. This can lead to deadlock if
BCS0-7 all have faults and another engine on BCS0-7 is at head of the
GuC scheduling queue as the migration engine used to fix tthe fault will
be blocked. To work around this set the migration engine to the highest
priority when servicing page faults.
v2 (Maarten): Set priority to kernel once at creation
Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Brian Welty <brian.welty@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Brost [Thu, 23 Mar 2023 16:25:00 +0000 (09:25 -0700)]
drm/xe: Use BO's GT to determine dma_offset when programming PTEs
Rather than using the passed in GT, use the BO's GT determine dma_offset
when programming PTEs as these two GT's could differ (i.e. mapping a BO
from a remote GT). The BO's GT is correct GT to use as this where BO
resides, while the passed in GT is where the mapping is created.
v2:
(Thomas) - Kernel doc, extra new line
(CI) - Rebase to tip
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Auld [Tue, 21 Mar 2023 11:44:07 +0000 (11:44 +0000)]
drm/xe/buddy: add compatible and intersects hooks
Copy this from i915. We need .compatible for vram -> vram transfers, so
they don't just get nooped by ttm, if need to move something from
mappable to non-mappble or vice versa. The .intersects is needed for
eviction, to determine if a victim resource is worth eviction. e.g if we
need mappable space there is no point in evicting a resource that has
zero mappable pages.
Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Auld [Tue, 21 Mar 2023 11:44:06 +0000 (11:44 +0000)]
drm/xe/buddy: add visible tracking
Replace the allocation code with the i915 version. This simplifies the
code a little, and importantly we get the accounting at the mgr level,
which is useful for debug (and maybe userspace), plus per resource
tracking so we can easily check if a resource is using one or pages in
the mappable part of vram (useful for eviction), or if the resource is
completely within the mappable portion (useful for checking if the
resource can be safely CPU mapped).
v2: Fix missing PAGE_SHIFT
v3: (Gwan-gyeong Mun)
- Fix incorrect usage of ilog2(mm.chunk_size).
- Fix calculation when checking for impossible allocation sizes, also
check much earlier.
v4: (Gwan-gyeong Mun)
- Fix calculation when extending the [fpfn, lpfn] range due to the
roundup_pow_of_two().
v5: (Gwan-gyeong Mun)
- Move the check for running out of mappable VRAM to before doing any of
the roundup_pow_of_two().
v6: (Jani)
- Stop abusing BUG_ON(). We can easily just use WARN_ON() here and
return a proper error to the caller, which is much nicer if we ever
trigger these.
Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Although xe_migrate_clear() has a value argument, currently the driver
is only passing 0 at all the places this function is invoked with the
exception the kunit tests are using the parameter to validate this
function with different values.
xe_migrate_clear() is failing on platforms with link copy engines
because xe_migrate_clear() via emit_clear() is using the blitter
instruction XY_FAST_COLOR_BLT to clear the memory. But this instruction
is not supported by link copy engine.
So the solution is to use the alternate instruction MEM_SET when
platform contains link copy engine. But MEM_SET instruction accepts only
8-bit value for setting whereas the value agrument of xe_migrate_clear()
is 32-bit.
So instead of spreading this limitation around all invocations of
xe_migrate_clear() and causing more confusion, it was decided to not
accept any value itself as driver does not really need this currently.
All the kunit tests are adapted as per the new function prototype.
This will be followed by a patch to add support for link copy engines.
Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Auld [Tue, 14 Mar 2023 08:58:40 +0000 (08:58 +0000)]
drm/xe/buddy: remove the virtualized start
Hopefully not needed anymore. We can add a .compatible() hook once we
need to differentiate between mappable and non-mappable vram. If the
allocation is not contiguous then the start value is kind of
meaningless, so rather just mark as invalid.
In upstream, TTM wants to eventually remove the ttm_resource.start
usage.
References: 544432703b2f ("drm/ttm: Add new callbacks to ttm res mgr") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Auld [Tue, 14 Mar 2023 08:58:39 +0000 (08:58 +0000)]
drm/xe/vram: start tracking the io_size
First step towards supporting small-bar is to track the io_size for
vram. We can longer assume that the io_size == vram size. This way we
know how much is CPU accessible via the BAR, and how much is not.
Effectively giving us a two tiered vram, where in some later patches we
can support different allocation strategies depending on if the memory
needs to be CPU accessible or not.
Note as this stage we still clamp the vram size to the usable vram size.
Only in the final patch do we turn this on for real, and allow distinct
io_size and vram_size.
v2: (Lucas):
- Improve the commit message, plus improve the kernel-doc for the
io_size to give a better sense of what it actually is.
Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Thomas Hellström [Tue, 14 Mar 2023 14:56:44 +0000 (15:56 +0100)]
drm/xe/vm: Defer vm rebind until next exec if nothing to execute
If all compute engines of a vm in compute mode are idle,
defer a rebind to the next exec to avoid the VM unnecessarily trying
to make memory resident and compete with other VMs for available
memory space.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Thomas Hellström [Fri, 10 Mar 2023 11:03:47 +0000 (12:03 +0100)]
drm/xe: Introduce xe_engine_is_idle()
Introduce xe_engine_is_idle, and replace the static function in
xe_migrate.c.
The latter had two flaws. First the seqno == 1 test might return a false
true value each time the seqno counter wrapped, Second, the
cur_seqno == next_seqno test would never return true.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Thomas Hellström [Fri, 10 Mar 2023 16:56:55 +0000 (17:56 +0100)]
drm/xe/migrate: Update cpu page-table updates
Don't wait for GPU to be able to update page-tables using CPU. Putting
ourselves to sleep may be more of a problem than using GPU for
page-table updates. Also allow the vm to be NULL since the migrate
kunit test uses NULL for vm.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/xe/xe_uc_fw: Use firmware files from standard locations
The GuC/HuC firmware files used by Xe drivers are the same as
used by i915. Use the already-known location to find those
firmware files, for a couple of reasons:
1. Avoid having the same firmware placed on two different
places on MODULE_FIRMWARE(), if both 915 and xe drivers
are compiled;
2. Having firmware files located on different locations may end
creating bigger initramfs, as the same files will be copied
twice my mkinitrd/dracut/...;
3. this is the place where those firmware files are located at
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
Upstream doesn't expect them to have on other places;
4. When built with display support, DMC firmware will be
loaded from i915/ directory. It is very confusing to have
some firmware files on a different place for the same driver.
Cc: Matthew Brost <matthew.brost@intel.com> Cc: Lucas de Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
[ Mostly agree with the direction of "use the firmware blobs from
upstream at their current location for these platforms". Previous
directory was not wrong as the plan was to have it handled in the
upstream firmware repo. For future platforms the location can be
changed if the support is only in xe ] Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230310081338.3275583-1-mauro.chehab@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Jani Nikula [Thu, 9 Mar 2023 12:21:33 +0000 (14:21 +0200)]
drm/xe/irq: the irq handler local variable need not be static
It's just a local variable.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Tue, 14 Mar 2023 00:30:11 +0000 (17:30 -0700)]
drm/xe: Add missing LRC workarounds for graphics 1200
Synchronize LRC workarounds for graphics version 1200 with i915 up to
commit 7cdae9e9ee5e ("drm/i915: Move DG2 tuning to the right function").
These were probably missed for TGL/RKL before because in i915 it uses a
!IS_DG1() condition. Avoid a similar issue by just checking the
graphics version 1200 since DG1 is 1210.
Lucas De Marchi [Tue, 14 Mar 2023 00:30:09 +0000 (17:30 -0700)]
drm/xe: Add missing DG2 lrc workarounds
Synchronize with i915 the DG2 lrc workarounds as of
commit 4d14d7717f19 ("drm/i915/selftest: Fix ktime_get() and h/w access
order").
A few simplifications were done when the WA should be applied to some
steps of a subplatform and all the steppings of the other subplatforms.
In this case, it was simply applied to all the steppings, which only
means applying it to a few more A* steppings.
The implementation of the workaround 16011186671 triggers a bug in the
RTP infra: it's not possible to set the flag the usual way when having
multiple actions in the entry. This may be fixed later, but for now it's
sufficient to just set the flag directly without the helper macro.
Lucas De Marchi [Tue, 14 Mar 2023 00:30:08 +0000 (17:30 -0700)]
drm/xe: Add missing DG2 lrc tunings
Synchronize with i915 the DG2 tunings as of
commit 4d14d7717f19 ("drm/i915/selftest: Fix ktime_get() and h/w access
order").
Contrary to the tuning "gang timer" for TGL, there is no quick
justification for why the read back is disabled in i915. Keep it
with that flag for now. That can be tentatively removed later when the
read values are checked.
v2: Use XEHP_FF_MODE2 instead of GEN12_FF_MODE2 (Matt Roper)
Lucas De Marchi [Tue, 14 Mar 2023 00:30:07 +0000 (17:30 -0700)]
drm/xe: Add missing DG2 engine workarounds
Synchronize with i915 the DG2 gt workarounds as of
commit 4d14d7717f19 ("drm/i915/selftest: Fix ktime_get() and h/w access
order").
A few simplifications were done when the WA should be applied to
some steps of a subplatform and all the steppings of the other
subplatforms. This happened with Wa_1509727124, Wa_22012856258 and a few
others. In figure the pre-production steppings will be removed, so this
can be already simplified a little bit.
v2:
- Make 1308578152 conditional on first gslice fused off
- Add the missing Wa_1608949956/Wa_14010198302 (Matt Roper)
v3:
- Do not duplicate the implementation of 18019627453 since it's
already covered by other WA numbers in graphics versions 1200 and
1210
Lucas De Marchi [Tue, 14 Mar 2023 00:30:03 +0000 (17:30 -0700)]
drm/xe: Reorder WAs to consider the platform
Now that number of platforms is growing, it's getting hard to know the
workarounds for each platform. Split the entries inside the same table
so the workarounds checking IP version are listed first, followed by
each platform. Next step when it grows too much is to split in smaller
tables.
Lucas De Marchi [Tue, 14 Mar 2023 00:30:02 +0000 (17:30 -0700)]
drm/xe/debugfs: Dump register save-restore tables
Add debugfs entry to dump the final tables with register save-restore
information.
For the workarounds, this has a format a little bit different than when the
values are applied because we don't want to read the values from the HW
when dumping via debugfs. For whitelist it just re-uses the print
function added for when the whitelist is being built.
Lucas De Marchi [Tue, 14 Mar 2023 00:30:01 +0000 (17:30 -0700)]
drm/xe: Print whitelist while applying
Besides printing the various register save-restore, it's also useful to
know the register being allowed/denied access from unprivileged batch
buffers. Print them during device probe.
Lucas De Marchi [Tue, 14 Mar 2023 00:30:00 +0000 (17:30 -0700)]
drm/xe/reg_sr: Tweak verbosity for register printing
If there is no register to save-restore or whitelist, just return. This
drops some noise from the log, particurlarly for platforms with several
engines like PVC:
On a PVC system it should show something like below. Whitelist calls
are still there since they aren't actually empty - driver just doesn't
print each individual entry. This will be fixed in future.
Lucas De Marchi [Tue, 14 Mar 2023 00:29:59 +0000 (17:29 -0700)]
drm/xe/rtp: Add match helper for gslice fused off
Add match helper to detect when the first gslice is fused off, as needed
by future workarounds.
v2:
- Add warning if called on a platform without geometry pipeline
(Matt Roper)
- Hardcode 4 as the number of gslices, which matches all the currently
supported platforms. PVC doesn't have geometry pipeline and
shouldn't use this function (Matt Roper)
Matthew Auld [Tue, 14 Mar 2023 08:58:38 +0000 (08:58 +0000)]
drm/xe: add xe_ttm_stolen_cpu_access_needs_ggtt()
xe_ttm_stolen_cpu_inaccessible() was originally meant to just cover the
case where stolen is not directly CPU accessible on some older
integrated platforms, and as such a GGTT mapping was also required for
CPU access (as per the check in xe_bo_create_pin_map_at()).
However with small-bar systems on dgfx we have one more case where
stolen is also inaccessible, however here we don't have any fallback
GGTT mode for CPU access. Fix the check in xe_bo_create_pin_map_at() to
make this distinction clear. In such a case the later vmap() will fail
anyway.
v2: fix kernel-doc warning
v3: Simplify further and remove cpu_inaccessible()
Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Auld [Tue, 14 Mar 2023 08:58:37 +0000 (08:58 +0000)]
drm/xe: one more s/lmem/vram/
Looks to have been introduced in some very recent changes, in-between
merging the driver wide s/lmem/vram/.
Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Jani Nikula [Thu, 9 Mar 2023 12:17:46 +0000 (14:17 +0200)]
drm/xe: make compound literal initialization const
Be careful about having const in the compound literal initialization to
keep the initializers in rodata. Here, the impact is 1.8k of mutable
data moved to rodata.
add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-1804 (-1804)
Data old new delta
__compound_literal 1804 - -1804
Total: Before=42425, After=40621, chg -4.25%
add/remove: 0/0 grow/shrink: 1/0 up/down: 1804/0 (1804)
RO Data old new delta
__compound_literal 7696 9500 +1804
Total: Before=138535, After=140339, chg +1.30%
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230309121746.479146-1-jani.nikula@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Wed, 1 Mar 2023 09:31:12 +0000 (01:31 -0800)]
drm/xe/pvc: Remove A* steppings
The PVC pre-production A* steppings are not going to be supported in xe
driver - the steppings are important for the WAs and since we are not
adding the pre-productions ones, there is no need to add the stepping.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Wed, 1 Mar 2023 09:31:09 +0000 (01:31 -0800)]
drm/xe: Name LRC wa after the engine it belongs
This makes it easier when printing the register-save-restore values
to know what is the engine.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Wed, 1 Mar 2023 09:31:08 +0000 (01:31 -0800)]
drm/xe: Remove dump function from reg_sr
The dump function was originally added with the idea that it could be
re-used both for printing the reg-sr data and saving it to pass to GuC
via ADS. This was not used by the GuC integration, so remove it now to
give place to a new debug.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Wed, 1 Mar 2023 09:31:07 +0000 (01:31 -0800)]
drm/xe/rtp: Add match for render reset domain
This allows to create WA/tuning rules that match the first engine that
is either of compute or render class. This matters for platforms that
don't have a render engine and that may have arbitrary compute engines
fused off: some register programming need to be added to one of those
engines.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Wed, 1 Mar 2023 09:31:06 +0000 (01:31 -0800)]
drm/xe/rtp: Move match function from wa to rtp
Match functions are generally useful for other parts of the code (e.g.
xe_tuning.c). Move and rename the single one available to create a place
where similar match functions can be added.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Sat, 4 Mar 2023 06:30:04 +0000 (22:30 -0800)]
drm/xe: Constify xe_dss_mask_group_ffs()
Due to how xe_dss_mask_t is implemented, the type is a pointer. Since
this is only used for looking up the bits, make it const so it can be
used together with a const gt passed around.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Sat, 4 Mar 2023 06:26:55 +0000 (22:26 -0800)]
drm/xe: Allow const propagation in gt_to_xe()
Replace the inline function with a _Generic() so gt_to_xe() can work
with a const struct xe_gt*, which leads to a const struct xe *.
This allows a const gt being passed around and when the xe device is
needed, compiler won't issue a warning that calling gt_to_xe() would
discard the const. Rather, just propagate the const to the xe pointer
being returned.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Thu, 9 Mar 2023 02:18:57 +0000 (18:18 -0800)]
drm/xe/mcr: Document how to initialize group/instance
Add a sentence about the initialization so it's clear for newcomers how
to tweak the init functions for new platforms.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Tue, 7 Mar 2023 00:40:27 +0000 (16:40 -0800)]
drm/xe/mcr: Add L3BANK steering for DG2
Some register ranges with replication type L3BANK were missing from the
driver table. The following warning was triggering when adding a
workaround touching the register 0xb188:
xe 0000:03:00.0: Did not find MCR register 0xb188 in any MCR steering table
Add the L3BANK ranges according to the spec.
v2:
- Fix typo in one of the ranges: s/0x00BCFF/0x008CFF/ (Matt Roper)
- Add termination rule in the init function for L3BANK (Matt Roper)
Bspec: 66534 Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Thu, 9 Mar 2023 00:55:30 +0000 (16:55 -0800)]
drm/xe: Add support for CCS engine fusing
For Xe_HP platforms that can have multiple CCS engines, the
presence/absence of each CCS is inferred by the presence/absence of any
DSS in the corresponding quadrant of the GT's DSS mask.
This handling is only needed on platforms that can have more than one
CCS. The CCS is never fused off on platforms like MTL that can only
have one.
v2:
- Add extra warnings to try to catch mistakes where the register counts
in get_num_dss_regs() are updated without corresponding updates to
the register parameters passed to load_dss_mask(). (Lucas)
- Add kerneldoc for xe_gt_topology_has_dss_in_quadrant() and clarify
why we care about quadrants of the DSS space. (Lucas)
- Ensure CCS engine counting treats engine mask as 64-bit. (Lucas)
Matt Roper [Thu, 9 Mar 2023 00:55:29 +0000 (16:55 -0800)]
drm/xe: Separate engine fuse handling into dedicated functions
The single function to handle fuse registers for all types of engines is
becoming a bit long and hard to follow (and we haven't even added the
compute engines yet). Let's split it into dedicated functions for each
engine class.
v2:
- Add note about BCS0 always being present. (Bala)
- Add forcewake assertion to read_copy_fuses. (Bala)
Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230309005530.3140173-1-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Auld [Wed, 8 Mar 2023 12:30:08 +0000 (12:30 +0000)]
drm/xe: s/lmem/vram/
This seems to be the preferred nomenclature in xe. Currently we are
intermixing vram and lmem, which is confusing.
v2 (Gwan-gyeong Mun & Lucas):
- Rather apply to the entire driver
Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Wed, 8 Mar 2023 00:55:08 +0000 (16:55 -0800)]
drm/xe/guc: Handle regset overflow check for entire GT
Checking whether a single engine's register save/restore entries
overflow the expected/pre-allocated GuC ADS regset area isn't terribly
useful; we actually want to check whether the combined entries from all
engines on the GT overflow the regset space.
projects / mirror_ubuntu-kernels.git / log