Lucas De Marchi [Wed, 20 Dec 2023 16:19:23 +0000 (08:19 -0800)]
drm/xe: Remove uninitialized variable from warning
"err" is not initialized when failing to create and add the freq0 sysfs
file. Remove it from the message. This fixes the following warning with
clang:
../drivers/gpu/drm/xe/xe_gt_freq.c:202:30: error: variable 'err' is uninitialized when used here [-Werror,-Wuninitialized]
kobject_name(gt->sysfs), err);
^~~
Fixes: bef52b5c7a19 ("drm/xe: Create a xe_gt_freq component for raw management and sysfs") Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://lore.kernel.org/r/20231220161923.3740489-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
As part of the FW definitions, we declare each blob as required via the
MODULE_FIRMWARE() macro. This causes the initramfs update (or equivalent
process) to look for the blobs on disk when the kernel is installed;
therefore, we need to make sure that all FWs we define are available in
linux-firmware.
We currently don't plan to push the PVC blob to linux-firmware, while the
LNL one will only be pushed once we have machines in CI to test it, so we
need to remove them from the list for now.
Rodrigo Vivi [Mon, 18 Dec 2023 13:47:02 +0000 (08:47 -0500)]
drm/xe: Fix build without CONFIG_FAULT_INJECTION
Ideally this header could be included without the CONFIG_FAULT_INJECTION
and it would take care itself for the includes it needs.
So, let's temporary workaround this by moving this below and including
only when CONFIG_FAULT_INJECTION is selected to avoid build breakages.
Another solution would be us including the linux/types.h as well, but
this creates unnecessary cases.
Reference: https://lore.kernel.org/all/20230816134748.979231-1-himal.prasad.ghimiray@intel.com/ Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Oded Gabbay <ogabbay@kernel.org> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Rodrigo Vivi [Mon, 11 Dec 2023 16:30:56 +0000 (11:30 -0500)]
MAINTAINERS: Updates to Intel DRM
Introduce the Maintainers of the new drm/xe driver for upcoming
Intel GPUs.
Since it has a shared display with drm/i915, let's also create a
dedicated block to group display related files. But without any
substantial change to the i915 side. The display patches will
continue to flow through i915 from drm-intel-next branches for now.
Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Oded Gabbay <ogabbay@kernel.org> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Francois Dugast [Fri, 15 Dec 2023 15:45:51 +0000 (15:45 +0000)]
drm/xe/uapi: Move CPU_CACHING defines before doc
Move those defines to align on the rule used elsewhere in the file which
was introduced by commit 4f082f2c3a37 ("drm/xe: Move defines before
relevant fields").
Francois Dugast [Fri, 15 Dec 2023 15:45:50 +0000 (15:45 +0000)]
drm/xe/uapi: Add examples of user space code
Complete the documentation of some structs by adding functional
examples of user space code. Those examples are intentionally kept
very simple. Put together, they provide a foundation for a minimal
application that executes a job using the Xe driver.
v2: Remove use of DRM_XE_VM_BIND_FLAG_ASYNC (Francois Dugast)
Francois Dugast [Fri, 15 Dec 2023 15:45:49 +0000 (15:45 +0000)]
drm/xe/uapi: Add block diagram of a device
In order to make proper use the uAPI, a prerequisite is to understand
some key concepts about the discrete GPU devices which are supported
by the Xe driver. For example, some structs defined in the uAPI are an
abstraction of a hardware component with a specific role.
This diagram helps to build a mental representation of a device how it
is seen by the Xe driver. As written in the documentation, it does not
intend to be a literal representation of an existing device. A lot
more information could be added but the intention for the overview is
to keep it simple, and go into detail as needed in other sections.
v2: Add GT1 inside Tile0 (José Roberto de Souza)
Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Mateusz Naklicki <mateusz.naklicki@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Rodrigo Vivi [Fri, 15 Dec 2023 15:45:48 +0000 (15:45 +0000)]
drm/xe/uapi: Document the memory_region bitmask
The uAPI should stay generic in regarding to the bitmask. It is
the userspace responsibility to check for the type/class of the
memory, without any assumption.
Also add comments inside the code to explain how it is actually
constructed so we don't accidentally change the assignment of
the instance and the masks.
No functional change in this patch. It only explains and document
the memory_region masks. A further follow-up work with the
organization of all memory regions around struct xe_mem_regions
is desired, but not part of this patch.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Mateusz Naklicki <mateusz.naklicki@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com>
Rodrigo Vivi [Fri, 15 Dec 2023 15:45:47 +0000 (15:45 +0000)]
drm/xe/uapi: More uAPI documentation additions and cosmetic updates
No functional change in this patch.
Let's ensure all of our structs are documented and with a certain
standard. Also, let's have an overview and list of IOCTLs as the
very beginning of the generated HTML doc.
v2: Nits (Lucas De Marchi)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Mateusz Naklicki <mateusz.naklicki@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com>
Rodrigo Vivi [Fri, 15 Dec 2023 15:45:46 +0000 (15:45 +0000)]
drm/xe/uapi: Order sections
This patch doesn't modify any text or uapi entries themselves.
It only move things up and down aiming a better organization of the uAPI.
While fixing the documentation I noticed that query_engine_cs_cycles
was in the middle of the memory_region info. Then I noticed more
mismatches on the order when compared to the order of the IOCTL
and QUERY entries declaration. So this patch aims to bring some
order to the uAPI so it gets easier to read and the documentation
generated in the end is able to tell a consistent story.
Overall order:
1. IOCTL definition
2. Extension definition and helper structs
3. IOCTL's Query structs in the order of the Query's entries.
4. The rest of IOCTL structs in the order of IOCTL declaration.
5. uEvents
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Mateusz Naklicki <mateusz.naklicki@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com>
Francois Dugast [Fri, 15 Dec 2023 15:45:45 +0000 (15:45 +0000)]
drm/xe/uapi: Make constant comments visible in kernel doc
As there is no direct way to make comments of constants directly
visible in the kernel doc, move them to the description of the
structure where they can be used. By doing so they appear in the
"Description" section of the struct documentation.
Add a documentation on the content and format of when using query type
DRM_XE_DEVICE_QUERY_HWCONFIG. The list of keys can be found in IGT
under lib/intel_hwconfig_types.h.
Francois Dugast [Fri, 15 Dec 2023 15:45:41 +0000 (15:45 +0000)]
drm/xe/uapi: Add missing documentation for struct members
This removes the documentation build warnings below:
include/uapi/drm/xe_drm.h:828: warning: Function parameter or \
member 'pad2' not described in 'drm_xe_vm_bind_op'
include/uapi/drm/xe_drm.h:875: warning: Function parameter or \
member 'pad2' not described in 'drm_xe_vm_bind'
include/uapi/drm/xe_drm.h:1006: warning: Function parameter or \
member 'handle' not described in 'drm_xe_sync'
include/uapi/drm/xe_drm.h:1006: warning: Function parameter or \
member 'timeline_value' not described in 'drm_xe_sync'
Matthew Brost [Fri, 15 Dec 2023 15:45:39 +0000 (15:45 +0000)]
drm/xe/uapi: Remove sync binds
Remove concept of async vs sync VM bind queues, rather make all binds
async.
The following bits have dropped from the uAPI:
DRM_XE_ENGINE_CLASS_VM_BIND_ASYNC
DRM_XE_ENGINE_CLASS_VM_BIND_SYNC
DRM_XE_VM_CREATE_FLAG_ASYNC_DEFAULT
DRM_XE_VM_BIND_FLAG_ASYNC
To implement sync binds the UMD is expected to use the out-fence
interface.
v2: Send correct version
v3: Drop drm_xe_syncs
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Mateusz Naklicki <mateusz.naklicki@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Francois Dugast [Fri, 15 Dec 2023 15:45:36 +0000 (15:45 +0000)]
drm/xe/uapi: Remove DRM_XE_UFENCE_WAIT_MASK_*
Those are just possible values for the comparison mask but they are not
specific magic values. Let's keep them as examples in the documentation
but remove them from the uAPI.
Suggested-by: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Mateusz Naklicki <mateusz.naklicki@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The exec_queue_set_property feature was removed in a previous
commit 0f1d88f27864 ("drm/xe/uapi: Kill exec_queue_set_property") and
is no longer usable, struct drm_xe_exec_queue_set_property does not
exist anymore, so let's remove this.
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Mateusz Naklicki <mateusz.naklicki@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Bommu Krishnaiah [Fri, 15 Dec 2023 15:45:34 +0000 (15:45 +0000)]
drm/xe/uapi: Return correct error code for xe_wait_user_fence_ioctl
Currently xe_wait_user_fence_ioctl is not checking exec_queue state
and blocking until timeout, with this patch wakeup the blocking wait
if exec_queue reset happen and returning proper error code
Signed-off-by: Bommu Krishnaiah <krishnaiah.bommu@intel.com> Cc: Oak Zeng <oak.zeng@intel.com> Cc: Kempczynski Zbigniew <Zbigniew.Kempczynski@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Mateusz Naklicki <mateusz.naklicki@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Bommu Krishnaiah [Fri, 15 Dec 2023 15:45:33 +0000 (15:45 +0000)]
drm/xe/uapi: add exec_queue_id member to drm_xe_wait_user_fence structure
remove the num_engines/instances members from drm_xe_wait_user_fence
structure and add a exec_queue_id member
Right now this is only checking if the engine list is sane and nothing
else. In the end every operation with this IOCTL is a soft check.
So, let's formalize that and only use this IOCTL to wait on the fence.
exec_queue_id member will help to user space to get proper error code
from kernel while in exec_queue reset
Signed-off-by: Bommu Krishnaiah <krishnaiah.bommu@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Acked-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Mateusz Naklicki <mateusz.naklicki@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com>
When CONFIG_DRM_I915_DEBUG is not set, a dummy
__i915_inject_probe_error() is provided on the xe side. Use the same
logic as in drivers/gpu/drm/i915/i915_utils.c to ifdef it out. This
fixes the build with W=1 and without that config:
CC [M] drivers/gpu/drm/xe/display/ext/i915_utils.o
../drivers/gpu/drm/xe/display/ext/i915_utils.c:19:5: error: no previous prototype for ‘__i915_inject_probe_error’ [-Werror=missing-prototypes]
19 | int __i915_inject_probe_error(struct drm_i915_private *i915, int err,
| ^~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-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>
Lucas De Marchi [Thu, 14 Dec 2023 21:39:53 +0000 (13:39 -0800)]
drm/xe/bo: Remove unusued variable
bo is not used since all the checks are against tbo. Fix warning:
../drivers/gpu/drm/xe/xe_bo.c: In function ‘xe_evict_flags’:
../drivers/gpu/drm/xe/xe_bo.c:250:23: error: variable ‘bo’ set but not used [-Werror=unused-but-set-variable]
250 | struct xe_bo *bo;
Signed-off-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>
Lucas De Marchi [Thu, 14 Dec 2023 21:39:52 +0000 (13:39 -0800)]
drm/xe: Return error if drm_buddy_init() fails
Fix warning:
../drivers/gpu/drm/xe/xe_ttm_vram_mgr.c: In function ‘__xe_ttm_vram_mgr_init’:
../drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:340:13: error: variable ‘err’ set but not used [-Werror=unused-but-set-variable]
340 | int err;
| ^~~
Check for the error return and return it, like done by other drivers.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Thu, 14 Dec 2023 18:47:05 +0000 (10:47 -0800)]
drm/xe: Move GSC HECI base offsets out of register header
These offsets are only used to setup the auxiliary device BAR
information and are never used for driver read/write operations. Move
them to the GSC HECI file where they're actually used.
Matt Roper [Thu, 14 Dec 2023 18:47:04 +0000 (10:47 -0800)]
drm/xe: Move engine base offsets to engine register header
These offsets are primarily used as parameters for the engine register
definitions, so it makes more sense to define them in the engine header
rather than the general register header.
Matt Roper [Thu, 14 Dec 2023 18:47:02 +0000 (10:47 -0800)]
drm/xe: Move some per-engine register definitions to the engine header
Although we only work with the RCS instances today, the
FF_SLICE_CS_CHICKEN1[1,2] CS_DEBUG_MODE1, CS_CHICKEN1, and
FF_THREAD_MODE registers all have instances on both the RCS and CCS
engines. Convert these to parameterized macros and move them to the
engine register header.
- Clear flat ccs during user bo creation.
- copy ccs meta data between flat ccs and bo during eviction and
restore.
- Add a bool field ccs_cleared in bo, true means ccs region of bo is
already cleared.
v2:
- Rebase.
v3:
- Maintain order of xe_bo_move_notify for ttm_bo_type_sg.
v4:
- xe_migrate_copy can be used to copy src to dst bo on igfx too.
Add a bool which handles only ccs metadata copy.
v5:
- on dgfx ccs should be cleared even if the bo is not compression enabled.
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
- The XY_CTRL_SURF_COPY_BLT instruction operating on ccs data expects
size in pages of main memory for which CCS data should be copied.
- The bitfield representing copy size in XY_CTRL_SURF_COPY_BLT has
shifted one bit higher in the instruction.
v2:
- Fix the num_pages for ccs size calculation.
- Address nits (Thomas)
v3:
- Use FIELD_PREP and FIELD_FIT instead of shifts and numbers.(Matt)
Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/xe/xe2: Allocate extra pages for ccs during bo create
Incase of bo move from PL_TT to PL_SYSTEM these pages will be used to
store ccs metadata from flat ccs. And during bo move to PL_TT from
PL_SYSTEM the metadata will be copied from extra pages to flat ccs. This
copy of ccs metadata ensures ccs remains unaltered between swapping out
of bo to disk and its restore to PL_TT.
Bspec:58796
v2:
- For dgfx ensure system bit is not set.
- Modify comments.(Thomas)
v3:
- Separate out patch to modify main memory to ccs memory ratio.(Matt)
v4:
- Update description for commit message.
- Make bo allocation routine more readable.(Matt)
Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/xe/xe2: Determine bios enablement for flat ccs on igfx
If bios disables flat ccs on igfx make has_flat_ccs as 0 and notify
via drm_dbg.
Bspec:59255
v2:
- Release forcewake.
- Add registers in order.
- drop dgfx condition and only add it back in the future
when the support for an Xe2 dgpu will be added.
- Use drm_dbg instead of drm_info. (Matt)
v3:
- Address nit(Matt)
Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The engine register header wound up with two definitions for
RING_MAX_NONPRIV_SLOTS, likely due to a rebase mistake. Keep the
definition that's in an appropriate place (i.e., with the
FORCE_TO_NONPRIV register definition) and remove the other.
Matthew Brost [Tue, 5 Dec 2023 18:39:54 +0000 (10:39 -0800)]
drm/xe: Allow num_batch_buffer / num_binds == 0 in IOCTLs
The idea being out-syncs can signal indicating all previous operations
on the bind queue are complete. An example use case of this would be
support for implementing vkQueueWaitIdle easily.
All in-syncs are waited on before signaling out-syncs. This is
implemented by forming a composite software fence of in-syncs and
installing this fence in the out-syncs and exec queue last fence slot.
The last fence must be added as a dependency for jobs on user exec
queues as it is possible for the last fence to be a composite software
fence (unordered, ioctl with zero bb or binds) rather than hardware
fence (ordered, previous job on queue).
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Thomas Hellström [Tue, 12 Dec 2023 10:01:44 +0000 (11:01 +0100)]
drm/xe: Use DRM_GPUVM_RESV_PROTECTED for gpuvm
Use DRM_GPUVM_RESV_PROTECTED to use corse-grained locking for the
evict and external object list.
Since we are already holding the relevant RESV locks, for now at least,
we don't need the fine-grained locking.
drm/xe: Fix lockdep warning in xe_force_wake calls
Use spin_lock_irqsave, spin_unlock_irqrestore
Fix for below:
[13994.811263] ========================================================
[13994.811295] WARNING: possible irq lock inversion dependency detected
[13994.811326] 6.6.0-rc3-xe #2 Tainted: G U
[13994.811358] --------------------------------------------------------
[13994.811388] swapper/0/0 just changed the state of lock:
[13994.811416] ffff895c7e044db8 (&cpuctx_lock){-...}-{2:2}, at:
__perf_event_read+0xb7/0x3a0
[13994.811494] but this lock took another, HARDIRQ-unsafe lock in the
past:
[13994.811528] (&fw->lock){+.+.}-{2:2}
[13994.811544]
and interrupts could create inverse lock ordering between
them.
[13994.811606]
other info that might help us debug this:
[13994.811636] Possible interrupt unsafe locking scenario:
Currently scratch PTEs are write-enabled and points to a single scratch
page. This has the side effect that buggy applications with out-of-bounds
memory accesses may not notice the bad access since what's written may
be read back.
Instead use NULL PTEs as scratch PTEs. These always return 0 when reading,
and writing has no effect. As a slight benefit, we can also use huge NULL
PTEs.
One drawback pointed out is that debugging may be hampered since previously
when inspecting the content of the scratch page, it might be possible to
detect writes to out-of-bound addresses and possibly also
from where the out-of-bounds address originated. However since the scratch
page-table structure is kept, it will be easy to add back the single
RW-enabled scratch page under a debug define if needed.
Also update the kerneldoc accordingly and move the function to create the
scratch page-tables from xe_pt.c to xe_pt.h since it is accessing
vm structure internals and this also makes it possible to make it static.
v2:
- Don't try to encode scratch PTEs larger than 1GiB.
- Move xe_pt_create_scratch(), Update kerneldoc.
v3:
- Rebase.
Cc: Brian Welty <brian.welty@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> #for general direction. Reviewed-by: Brian Welty <brian.welty@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231209151843.7903-3-thomas.hellstrom@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Add a define for the highest level for which we can encode a huge PTE,
and use it for page-table building. Also update an assert that checks that
we don't try to encode for larger sizes.
Rodrigo Vivi [Fri, 8 Dec 2023 05:11:51 +0000 (00:11 -0500)]
drm/xe: Create a xe_gt_freq component for raw management and sysfs
Goals of this new xe_gt_freq component:
1. Detach sysfs controls and raw freq management from GuC SLPC.
2. Create a directory that could later be aligned with devfreq.
3. Encapsulate all the freq control in a single directory. Although
we only have one freq domain per GT, already start with a numbered
freq0 directory so it could be expanded in the future if multiple
domains or PLL are needed.
Note: Although in the goal #1, the raw freq management control is
mentioned, this patch only starts by the sysfs control. The RP freq
configuration and init freq selection are still under the guc_pc, but
should be moved to this component in a follow-up patch.
v2: - Add /tile# to the doc and remove unnecessary kobject_put (Riana)
- s/ssize_t/int on some ret variables (Vinay)
Mika Kuoppala [Tue, 5 Dec 2023 14:41:42 +0000 (16:41 +0200)]
drm/xe/vm: Avoid asid lookup if none allocated
The destroy path can and will get called for incomplete
vm objects on error paths, where the asid is not yet allocated.
This leads to lookup fail and assert triggered.
Fix this by not asserting of asid existence if vm never
got assigned one.
Cc: Ohad Sharabi <osharabi@habana.ai> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Tue, 5 Dec 2023 14:52:35 +0000 (06:52 -0800)]
drm/xe: Rename info.supports_* to info.has_*
Rename supports_mmio_ext and supports_usm to use a has_ prefix so the
flags are grouped together. This settles on just one variant for
positive info matching ("has_") and one for negative ("skip_").
Also make sure the has_* flags are grouped together in xe_pci.c.
Michal Wajdeczko [Tue, 28 Nov 2023 15:15:06 +0000 (16:15 +0100)]
drm/xe/kunit: Enable CONFIG_PCI_IOV in .kunitconfig
We will add kunit tests for the PF specific code that is by default
enabled only under CONFIG_PCI_IOV. Update our .kunitconfig to allow
running those test cases by our CI.
Michal Wajdeczko [Tue, 28 Nov 2023 15:15:03 +0000 (16:15 +0100)]
drm/xe: Define DRM_XE_DEBUG_SRIOV config
We will be using extra logs during enabling of the SR-IOV features
or when adding support for new platforms. Define separate config
flag to keep that low level logs disabled if we're not debugging.
Allow user to configure the CCS mode setting through a
'ccs_mode' sysfs interface. Also report the current
CCS mode configuration and number of compute slices
available through this interface.
v2: Rebase, make it platform agnostic
v3: Separte out num_cslices sysfs interface and make
xe_gt_ccs_mode_sysfs_init() return void
Disable dynamic HW load balancing of compute resource assignment
to engines and instead enabled fixed mode of mapping compute
resources to engines on all platforms with more than one compute
engine.
By default enable only one CCS engine with all compute slices
assigned to it. This is the desired configuration for common
workloads.
PVC platform supports only the fixed CCS mode (workaround 16016805146).
v2: Rebase, make it platform agnostic
v3: Minor code refactoring
This workaround applies to graphics 20.04 on all engines.
Workaround has three parts :
1. Pipe flush before MI_ATOMIC - This part isn't relevant to Xe
(at least not right now) since we don't use MI_ATOMIC anywhere
in the kernel mode driver.
2. Memory-based interrupt masking - Memory-based interrupt processing
isn't supported on physical functions, only virtual functions,
according to bspec 60352. So this is probably only relevant once
SRIOV support lands in the driver.
3. Disabling CSB/timestamp updates to the ghwsp and pphwsp - Workaround
is added by this change.
The CSB reports to gHWSP and ppHWSP have been discussed as part
of a different topic on some internal threads and we've confirmed
that neither the KMD nor the GuC firmware use those for anything,
so disabling them is always "safe" and should have no functional
or performance impact on system operation. The same is true for
the timestamp updates in the ppHWSP as well. Given that, it might
make sense to just combine these two workarounds into a single
record (and single patch) and apply it on all steppings. Disabling
the reports for RCS on higher steppings doesn't have any kind of
negative impact and will simplify the overall situation.
V3(MattR):
- Combine WA apply same WA for all engines, no performance impact
V2(MattR):
- Mention detail in commit message
- Reorder bit define
- Improve bit naming
- Remove workaround part which isnt relevant
HuC authentication via GSC is performed by submitting the appropriate
PXP packet to the GSC FW. This packet can trigger a "pending" reply from
the FW, so we need to handle that and resubmit. Note that the auth via
GSC can only be performed if the HuC has already been authenticated by
the GuC.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Vivaik Balasubrawmanian <vivaik.balasubrawmanian@intel.com> Reviewed-by: Vivaik Balasubrawmanian <vivaik.balasubrawmanian@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Starting on MTL, the HuC is authenticated twice, once via GuC (same as
with older integrated platforms) and once via GSC; the first
authentication allows the HuC to be used for clear-media workloads,
while the second one unlocks support for protected content.
Ahead of adding the authentication flow via GSC, this patch adds support
for differentiating the 2 auth steps and checking if they're complete.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Vivaik Balasubrawmanian <vivaik.balasubrawmanian@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Tue, 5 Dec 2023 13:39:53 +0000 (05:39 -0800)]
drm/xe/kunit: Add stub to read_gmdid
Currently it's not possible to test the WAs for platforms using gmdid
since they don't have the IP information on the descriptor struct. In
order to allow that, add a stub function for read_gmdid() that is
activated when the test executes, replacing the iomap and read of the
real register.
Lucas De Marchi [Tue, 5 Dec 2023 13:39:52 +0000 (05:39 -0800)]
drm/xe/kunit: Move fake pci data to test-priv
Instead of passing as parameter to xe_pci_fake_device_init(), use
test->priv to pass parameters down the call stack. The main advantage is
that then the data is readily available on other functions by using
kunit_get_current_test().
This is a preparation to fix the initialization of fake devices when
they were supposed to be using GMD_ID.
Lucas De Marchi [Tue, 5 Dec 2023 13:39:51 +0000 (05:39 -0800)]
drm/xe/kunit: Remove handling of XE_TEST_SUBPLATFORM_ANY
The only user passing XE_TEST_SUBPLATFORM_ANY is
xe_pci_fake_device_init_any(), but then the function would return
earlier when handling XE_TEST_PLATFORM_ANY. Platforms without a
subplatform use XE_SUBPLATFORM_NONE.
Lucas De Marchi [Tue, 5 Dec 2023 15:58:20 +0000 (07:58 -0800)]
drm/xe: Expand XE_REG_OPTION_MASKED documentation
Expand documentation and add an example to make clear this isn't about
generic masks in registers. Also, fix the doc regarding read operations:
the mask part has no effect on them.
Thomas Hellström [Mon, 27 Nov 2023 15:03:30 +0000 (16:03 +0100)]
drm/xe/uapi: Use LR abbrev for long-running vms
Currently we're using "compute mode" for long running VMs using
preempt-fences for memory management, and "fault mode" for long
running VMs using page faults.
Change this to use the terminology "long-running" abbreviated as LR for
long-running VMs. These VMs can then either be in preempt-fence mode or
fault mode. The user can force fault mode at creation time, but otherwise
the driver can choose to use fault- or preempt-fence mode for long-running
vms depending on the device capabilities. Initially unless fault-mode is
specified, the driver uses preempt-fence mode.
v2:
- Fix commit message wording and the documentation around
CREATE_FLAG_LR_MODE and CREATE_FLAG_FAULT_MODE
Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Rodrigo Vivi [Wed, 22 Nov 2023 14:38:33 +0000 (14:38 +0000)]
drm/xe/uapi: Move xe_exec after xe_exec_queue
Although the exec ioctl is a very important one, it makes no sense
to explain xe_exec before explaining the exec_queue. So, let's
move this down to help bring a better flow on the documentation
and code readability.
It is important to highlight that this patch is changing all
the ioctl numbers in a non-backward compatible way. However, we
are doing this final uapi clean-up before we submit our first
pull-request to be part of the upstream Kernel. Once we get
there, no other change like this will ever happen and all the
backward compatibility will be respected.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Rodrigo Vivi [Wed, 22 Nov 2023 14:38:32 +0000 (14:38 +0000)]
drm/xe/uapi: Fix various struct padding for 64b alignment
Let's respect Documentation/process/botching-up-ioctls.rst
and add the proper padding for a 64b alignment with all as
well as all the required checks and settings for the pads
and the reserved entries.
v2: Fix remaining holes and double check with pahole (Jose)
Ensure with pahole that both 32b and 64b have exact same
layout (Thomas)
Do not set query's pad and reserved bits to zero since it
is redundant and already done by kzalloc (Matt)
v3: Fix alignment after rebase (José Roberto de Souza)
v4: Fix pad check (Francois Dugast)
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Rodrigo Vivi [Wed, 22 Nov 2023 14:38:31 +0000 (14:38 +0000)]
drm/xe/uapi: Add Tile ID information to the GT info query
As an information only. So Userspace can use this information
and be able to correlate different GTs.
Make API symmetric between Engine and GT info.
There's no need right now to include a tile_query entry
since there's no other information that we need from tile
that is not already exposed through different queries.
However, this could be added later if we have different Tile
information that could matter to userspace. But let's keep
the API ready for a direct reference to Tile ID based on
the GT entry.
Signed-off-by: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Rodrigo Vivi [Wed, 22 Nov 2023 14:38:29 +0000 (14:38 +0000)]
drm/xe/uapi: Crystal Reference Clock updates
First of all, let's remove the duplication.
But also, let's rename it to remove the word 'frequency'
out of it. In general, the first thing people think of frequency
is the frequency in which the GTs are operating to execute the
GPU instructions.
While this frequency here is a crystal reference clock frequency
which is the base of everything else, and in this case of this
uAPI it is used to calculate a better and precise timestamp.
v2: (Suggested by Jose) Remove the engine_cs and keep the GT info one
since it might be useful for other SRIOV cases where the engine_cs
will be zeroed. So, grabbing from the GT_LIST should be cleaner.
v3: Keep comment on put_user() call (José Roberto de Souza)
Cc: Matt Roper <matthew.d.roper@intel.com>
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Jose Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Rodrigo Vivi [Wed, 22 Nov 2023 14:38:28 +0000 (14:38 +0000)]
drm/xe/uapi: Kill tile_mask
It is currently unused, so by the rules it cannot go upstream.
Also there was the desire to convert that to align with the
engine_class_instance selection, but the consensus on that one
is to remain with the global gt_id. So we are keeping the gt_id
there, not converting to a generic sched_group and also killing
this tile_mask and only using the default behavior of 0 that is
to create a mapping / page_table entry on every tile, similar
to what i915.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Francois Dugast [Wed, 22 Nov 2023 14:38:26 +0000 (14:38 +0000)]
drm/xe/uapi: Align on a common way to return arrays (engines)
The uAPI provides queries which return arrays of elements. As of now
the format used in the struct is different depending on which element
is queried. Fix this for engines by applying the pattern below:
Instead of directly returning an array of struct
drm_xe_query_engine_info, a new struct drm_xe_query_engines is
introduced. It contains itself an array of struct drm_xe_engine
which holds the information about each engine.
v2: Use plural for struct drm_xe_query_engines as multiple engines
are returned (José Roberto de Souza)
Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Francois Dugast [Wed, 22 Nov 2023 14:38:25 +0000 (14:38 +0000)]
drm/xe/uapi: Align on a common way to return arrays (gt)
The uAPI provides queries which return arrays of elements. As of now
the format used in the struct is different depending on which element
is queried. However, aligning on the new common pattern:
... would mean bringing back the name "gts" which is avoided per commit fca54ba12470 ("drm/xe/uapi: Rename gts to gt_list") so make an exception
for gt and leave gt_list. Also, this change removes "query" in the
name of struct drm_xe_query_gt as it is not returned from the query
IOCTL. There is no functional change.
v2: Leave gt_list (Matt Roper)
Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Francois Dugast [Wed, 22 Nov 2023 14:38:24 +0000 (14:38 +0000)]
drm/xe/uapi: Align on a common way to return arrays (memory regions)
The uAPI provides queries which return arrays of elements. As of now
the format used in the struct is different depending on which element
is queried. Fix this for memory regions by applying the pattern below:
For xe bo creation we request passing size which matches system or
vram minimum page alignment. This way we want to ensure userspace
is aware of region constraints and not aligned allocations will be
rejected returning EINVAL.
v2:
- Rebase, Update uAPI documentation. (Thomas)
v3:
- Adjust the dma-buf kunit test accordingly. (Thomas)
v4:
- Fixed rebase conflicts and updated commit message. (Francois)
Signed-off-by: Mauro Carvalho Chehab <mauro.chehab@linux.intel.com> Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/xe: Make DRM_XE_DEVICE_QUERY_ENGINES future proof
We have at least 2 future features(OA and future media engines
capabilities) that will require Xe to provide more information about
engines to UMDs.
But this information should not just be added to
drm_xe_engine_class_instance for a couple of reasons:
- drm_xe_engine_class_instance is used as input to other structs/uAPIs
and those uAPIs don't care about any of these future new engine fields
- those new fields are useless information after initialization for
some UMDs, so it should not need to carry that around
So here my proposal is to make DRM_XE_DEVICE_QUERY_ENGINES return an
array of drm_xe_query_engine_info that contain
drm_xe_engine_class_instance and 3 u64s to be used for future features.
Matthew Auld [Mon, 4 Dec 2023 10:51:27 +0000 (10:51 +0000)]
drm/xe: add some debug info for d3cold
From the CI logs we want to easily know if the machine is capable and
allowed to enter d3cold, and can therefore potentially trigger the
d3cold RPM suspend and resume path.
drm/xe/guc: Split GuC params used for "hwconfig" and "post-hwconfig"
Move params that are not used for initial "hwconfig" load to
"post-hwconfig" phase.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/xe/uc: Store firmware binary in system-memory backed BO
The firmware loading for GuC is about to be moved, and will happen much
earlier in the probe process, when local-memory is not yet available.
While this has the potential to make the firmware loading process
slower, this is only happening during probe and full device reset.
Since both are not hot-paths - store all UC-like firmware in system
memory.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
projects / mirror_ubuntu-kernels.git / log