| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
So far the mirred action has dealt with syntax that handles
mirror/redirection for netdev. A matching packet is redirected or mirrored
to a target netdev.
In this patch we enable mirred to mirror to a tc block as well.
IOW, the new syntax looks as follows:
... mirred <ingress | egress> <mirror | redirect> [index INDEX] < <blockid BLOCKID> | <dev <devname>> >
Examples of mirroring or redirecting to a tc block:
$ tc filter add block 22 protocol ip pref 25 \
flower dst_ip 192.168.0.0/16 action mirred egress mirror blockid 22
$ tc filter add block 22 protocol ip pref 25 \
flower dst_ip 10.10.10.10/32 action mirred egress redirect blockid 22
Co-developed-by: Jamal Hadi Salim <[email protected]>
Signed-off-by: Jamal Hadi Salim <[email protected]>
Co-developed-by: Pedro Tammela <[email protected]>
Signed-off-by: Pedro Tammela <[email protected]>
Signed-off-by: Victor Nogueira <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Virtual ISM devices introduced in SMCv2.1 requires a 128 bit extended
GID vs. the existing ISM 64bit GID. So the 2nd 64 bit of extended GID
should be included in SMC-D linkgroup netlink attribute as well.
Signed-off-by: Wen Gu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This is a comment left over of commit d3d767396a02
("drm/xe/uapi: Remove sync binds").
Fixes: d3d767396a02 ("drm/xe/uapi: Remove sync binds")
Reviewed-by: Rodrigo Vivi <[email protected]>
Cc: Matthew Brost <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
|
|
The ctx in struct lsm_ctx is an array of size ctx_len, tell the compiler
about this using __counted_by() where supported to improve the ability to
detect overflow issues.
Reported-by: Aishwarya TCV <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux into drm-next
This tag contains habanalabs driver changes for v6.8.
The notable changes are:
- uAPI changes:
- Add sysfs entry to allow users to identify a device minor id with its
debugfs path
- Add sysfs entry to expose the device's module id as given to us from
the f/w
- Add signed device information retrieval through the INFO ioctl
- New features and improvements:
- Update documentation of debugfs paths
- Add support for Gaudi2C device (new PCI revision number)
- Add pcie reset prepare/done hooks
- Firmware related fixes and changes:
- Print three instances version numbers of Infineon second stage
- Assume hard-reset is done by f/w upon PCIe AXI drain
- Bug fixes and code cleanups:
- Fix information leak in sec_attest_info()
- Avoid overriding existing undefined opcode data in Gaudi2
- Multiple Queue Manager (QMAN) fixes for Gaudi2
- Set hard reset flag if graceful reset is skipped
- Remove 'get temperature' debug print
- Fix the new Event Queue heartbeat mechanism
Signed-off-by: Dave Airlie <[email protected]>
From: Oded Gabbay <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/ZYFpihZscr/[email protected]
|
|
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next
Introduce a new DRM driver for Intel GPUs
Xe, is a new driver for Intel GPUs that supports both integrated and
discrete platforms. The experimental support starts with Tiger Lake.
i915 will continue be the main production driver for the platforms
up to Meteor Lake and Alchemist. Then the goal is to make this Intel
Xe driver the primary driver for Lunar Lake and newer platforms.
It uses most, if not all, of the key drm concepts, in special: TTM,
drm-scheduler, drm-exec, drm-gpuvm/gpuva and others.
Signed-off-by: Dave Airlie <[email protected]>
[airlied: add an extra X86 check, fix a typo, fix drm_exec_init interface
change].
From: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
UHB AP send supported power type(LPI, SP, VLP)
in beacon and probe response IE and STA should
connect to these AP only if their regulatory support
the AP power type.
Beacon/Probe response are reported to userspace
with reason "STA regulatory not supporting to connect to AP
based on transmitted power type" and it should
not connect to AP.
Signed-off-by: Mukesh Sisodiya <[email protected]>
Reviewed-by: Gregory Greenman <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20231220133549.cbfbef9170a9.I432f78438de18aa9f5c9006be12e41dc34cc47c5@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
FCC-594280 D01 Section B.3 allows peer-to-peer and ad hoc devices to
operate on DFS channels while they operate under the control of a
concurrent DFS master. For example, it is possible to have a P2P GO on a
DFS channel as long as BSS connection is active on the same channel.
Allow such operation by adding additional regulatory flags to indicate
DFS concurrent channels and capable devices. Add the required
relaxations in DFS regulatory checks.
Signed-off-by: Andrei Otcheretianski <[email protected]>
Reviewed-by: Gregory Greenman <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20231220133549.bdfb8a9c7c54.I973563562969a27fea8ec5685b96a3a47afe142f@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
This kernel uevent is getting removed for now. It will come
back later with a better future proof name.
v2: Rebase (Francois Dugast)
Cc: Himal Prasad Ghimiray <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Francois Dugast <[email protected]>
Cc: Aravind Iddamsetty <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Himal Prasad Ghimiray <[email protected]>
Acked-by: Lucas De Marchi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
|
|
Bring those defines close to the context where they can be used. Also
apply indentation as it is done for other subsets of defines.
Reviewed-by: Rodrigo Vivi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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").
Reviewed-by: Rodrigo Vivi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The tail of the provided ring buffer is shared between the kernel and
the application, but the head is private to the kernel as the
application doesn't need to see it. However, this also prevents the
application from knowing how many buffers the kernel has consumed.
Usually this is fine, as the information is inherently racy in that
the kernel could be consuming buffers continually, but for cleanup
purposes it may be relevant to know how many buffers are still left
in the ring.
Add IORING_REGISTER_PBUF_STATUS which will return status for a given
provided buffer ring. Right now it just returns the head, but space
is reserved for more information later in, if needed.
Link: https://github.com/axboe/liburing/discussions/1020
Signed-off-by: Jens Axboe <[email protected]>
|
|
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)
Reviewed-by: Rodrigo Vivi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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 <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
|
|
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.
v2: Remove DRM_XE_UFENCE_WAIT_MASK_* (Francois Dugast)
Reviewed-by: Rodrigo Vivi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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.
Reviewed-by: Rodrigo Vivi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Provide a description of the keys used the struct
drm_xe_query_config info array.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/637
Reviewed-by: Rodrigo Vivi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Document the behavior of the driver for IOCTL DRM_IOCTL_XE_DEVICE_QUERY
depending on the size value provided in struct drm_xe_device_query.
Reviewed-by: Rodrigo Vivi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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'
Reviewed-by: Rodrigo Vivi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Add a comment to each struct to complete documentation, ensure all
struct appear in the kernel doc, and bind structs to IOCTLs.
Reviewed-by: Rodrigo Vivi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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 <[email protected]>
Cc: Thomas Hellström <[email protected]>
Cc: Francois Dugast <[email protected]>
Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Thomas Hellström <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
To ensure consistency and avoid possible later conflicts,
let's add drm_xe prefix to xe_user_extension struct.
Cc: Francois Dugast <[email protected]>
Suggested-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
|
|
PMU uapi is likely to change in the future. Till the uapi is finalized,
remove PMU from Xe. PMU can be re-added after uapi is finalized.
v2: Include xe_drm.h in xe/tests/xe_dma_buf.c (Francois)
Signed-off-by: Ashutosh Dixit <[email protected]>
Acked-by: Aravind Iddamsetty <[email protected]>
Acked-by: Lucas De Marchi <[email protected]>
Reviewed-by: Umesh Nerlige Ramappa <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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 <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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 <[email protected]>
Acked-by: Rodrigo Vivi <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Acked-by: Matthew Brost <[email protected]>
Reviewed-by: Francois Dugast <[email protected]>
Acked-by: José Roberto de Souza <[email protected]>
Acked-by: Mateusz Naklicki <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
|
|
All the properties should be immutable and set upon exec_queue creation
using the existent extension. So, let's kill this useless and dangerous
uapi.
Cc: Francois Dugast <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Cc: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
|
|
The vm_create ioctl function doesn't accept any extension.
Remove this left over.
A backward compatible change.
Cc: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
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 <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Francois Dugast <[email protected]>
Signed-off-by: Thomas Hellström <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
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 <[email protected]>
Cc: Francois Dugast <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Cc: Matt Roper <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
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 <[email protected]>
Umesh Nerlige Ramappa <[email protected]>
Cc: Jose Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
Let's continue on the uapi clean-up with more splits
with stuff into their own exclusive fields instead of
reusing stuff.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
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:
struct drm_xe_query_Xs {
__u32 num_Xs;
struct drm_xe_X Xs[];
...
}
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 <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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:
struct drm_xe_query_Xs {
__u32 num_Xs;
struct drm_xe_X Xs[];
...
}
... 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 <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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:
struct drm_xe_query_Xs {
__u32 num_Xs;
struct drm_xe_X Xs[];
...
}
This removes "query" in the name of struct drm_xe_query_mem_region
as it is not returned from the query IOCTL. There is no functional
change.
v2: Only rename drm_xe_query_mem_region to drm_xe_mem_region
(José Roberto de Souza)
v3: Rename usage to mem_regions in xe_query.c (José Roberto de Souza)
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Zbigniew Kempczyński <[email protected]>
Signed-off-by: Thomas Hellström <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
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.
Reference OA:
https://patchwork.freedesktop.org/patch/558362/?series=121084&rev=6
v2: Reduce reserved[] to 3 u64 (Matthew Brost)
Cc: Francois Dugast <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
[Rodrigo Rebased]
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
Although the flags are about the creation, the memory placement
of the BO deserves a proper dedicated field in the uapi.
Besides getting more clear, it also allows to remove the
'magic' shifts from the flags that was a concern during the
uapi reviews.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
|
|
The bind api is extensible but for a single bind op, there
is not a mechanism to extend. Add extensions field to
struct drm_xe_vm_bind_op.
Cc: Rodrigo Vivi <[email protected]>
Cc: Matthew Brost <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Francois Dugast <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Dominik Grzegorzek <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Allow userspace to directly control the pat_index for a given vm
binding. This should allow directly controlling the coherency, caching
behaviour, compression and potentially other stuff in the future for the
ppGTT binding.
The exact meaning behind the pat_index is very platform specific (see
BSpec or PRMs) but effectively maps to some predefined memory
attributes. From the KMD pov we only care about the coherency that is
provided by the pat_index, which falls into either NONE, 1WAY or 2WAY.
The vm_bind coherency mode for the given pat_index needs to be at least
1way coherent when using cpu_caching with DRM_XE_GEM_CPU_CACHING_WB. For
platforms that lack the explicit coherency mode attribute, we treat
UC/WT/WC as NONE and WB as AT_LEAST_1WAY.
For userptr mappings we lack a corresponding gem object, so the expected
coherency mode is instead implicit and must fall into either 1WAY or
2WAY. Trying to use NONE will be rejected by the kernel. For imported
dma-buf (from a different device) the coherency mode is also implicit
and must also be either 1WAY or 2WAY.
v2:
- Undefined coh_mode(pat_index) can now be treated as programmer
error. (Matt Roper)
- We now allow gem_create.coh_mode <= coh_mode(pat_index), rather than
having to match exactly. This ensures imported dma-buf can always
just use 1way (or even 2way), now that we also bundle 1way/2way into
at_least_1way. We still require 1way/2way for external dma-buf, but
the policy can now be the same for self-import, if desired.
- Use u16 for pat_index in uapi. u32 is massive overkill. (José)
- Move as much of the pat_index validation as we can into
vm_bind_ioctl_check_args. (José)
v3 (Matt Roper):
- Split the pte_encode() refactoring into separate patch.
v4:
- Rebase
v5:
- Check for and reject !coh_mode which would indicate hw reserved
pat_index on xe2.
v6:
- Rebase on removal of coh_mode from uapi. We just need to reject
cpu_caching=wb + pat_index with coh_none.
Testcase: igt@xe_pat
Bspec: 45101, 44235 #xe
Bspec: 70552, 71582, 59400 #xe2
Signed-off-by: Matthew Auld <[email protected]>
Cc: Pallavi Mishra <[email protected]>
Cc: Thomas Hellström <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Matt Roper <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Cc: Filip Hazubski <[email protected]>
Cc: Carl Zhang <[email protected]>
Cc: Effie Yu <[email protected]>
Cc: Zhengguo Xu <[email protected]>
Cc: Francois Dugast <[email protected]>
Tested-by: José Roberto de Souza <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Acked-by: Zhengguo Xu <[email protected]>
Acked-by: Bartosz Dunajski <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Allow userspace to specify the CPU caching mode at object creation.
Modify gem create handler and introduce xe_bo_create_user to replace
xe_bo_create. In a later patch we will support setting the pat_index as
part of vm_bind, where expectation is that the coherency mode extracted
from the pat_index must be least 1way coherent if using cpu_caching=wb.
v2
- s/smem_caching/smem_cpu_caching/ and
s/XE_GEM_CACHING/XE_GEM_CPU_CACHING/. (Matt Roper)
- Drop COH_2WAY and just use COH_NONE + COH_AT_LEAST_1WAY; KMD mostly
just cares that zeroing/swap-in can't be bypassed with the given
smem_caching mode. (Matt Roper)
- Fix broken range check for coh_mode and smem_cpu_caching and also
don't use constant value, but the already defined macros. (José)
- Prefer switch statement for smem_cpu_caching -> ttm_caching. (José)
- Add note in kernel-doc for dgpu and coherency modes for system
memory. (José)
v3 (José):
- Make sure to reject coh_mode == 0 for VRAM-only.
- Also make sure to actually pass along the (start, end) for
__xe_bo_create_locked.
v4
- Drop UC caching mode. Can be added back if we need it. (Matt Roper)
- s/smem_cpu_caching/cpu_caching. Idea is that VRAM is always WC, but
that is currently implicit and KMD controlled. Make it explicit in
the uapi with the limitation that it currently must be WC. For VRAM
+ SYS objects userspace must now select WC. (José)
- Make sure to initialize bo_flags. (José)
v5
- Make to align with the other uapi and prefix uapi constants with
DRM_ (José)
v6:
- Make it clear that zero cpu_caching is only allowed for kernel
objects. (José)
v7: (Oak)
- With all the changes from the original design, it looks we can
further simplify here and drop the explicit coh_mode. We can just
infer the coh_mode from the cpu_caching. i.e reject cpu_caching=wb +
coh_none. It's one less thing for userspace to maintain so seems
worth it.
v8:
- Make sure to also update the kselftests.
Testcase: igt@xe_mmap@cpu-caching
Signed-off-by: Pallavi Mishra <[email protected]>
Co-developed-by: Matthew Auld <[email protected]>
Signed-off-by: Matthew Auld <[email protected]>
Cc: Thomas Hellström <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Matt Roper <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Cc: Filip Hazubski <[email protected]>
Cc: Carl Zhang <[email protected]>
Cc: Effie Yu <[email protected]>
Cc: Zhengguo Xu <[email protected]>
Cc: Francois Dugast <[email protected]>
Cc: Oak Zeng <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Acked-by: Zhengguo Xu <[email protected]>
Acked-by: Bartosz Dunajski <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Let's bring a bit of clarity on this 'region' field that is
part of vm_bind operation struct. Rename and document to make
it more than obvious that it is a region instance and not a
mask and also that it should only be used with the prefetch
operation itself.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
|
|
On one hand the WAIT_OP represents the operation use for waiting such
as ==, !=, > and so on. On the other hand, the mask is applied to the
value used for comparision. Split those two to bring clarity to the uapi.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
|
|
Only cosmetic things. No functional change on this patch.
Define every flag with (1 << n) and use singular FLAG name.
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
|