linux.git/drivers/gpu/drm/xe/xe_query.c, branch v6.8

drm/xe: Don't use __user error pointers

2024-02-01T10:26:50+00:00

The error pointer macros are not aware of __user pointers and as a
consequence sparse warns.

Have the copy_mask() function return an integer instead of a __user
pointer.

Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Cc: Rodrigo Vivi 
Cc: Matthew Brost 
Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Brost 
Link: https://patchwork.freedesktop.org/patch/msgid/20240117134048.165425-5-thomas.hellstrom@linux.intel.com
(cherry picked from commit 78366eed6853aa6a5deccb2eb182f9334d2bd208)
Signed-off-by: Thomas Hellström

drm/xe/uapi: Document the memory_region bitmask

2023-12-21T16:47:01+00:00

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 
Reviewed-by: Lucas De Marchi 
Acked-by: José Roberto de Souza 
Acked-by: Mateusz Naklicki 
Signed-off-by: Francois Dugast

drm/xe/uapi: Fix various struct padding for 64b alignment

2023-12-21T16:45:19+00:00

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 
Cc: Francois Dugast 
Cc: José Roberto de Souza 
Cc: Matt Roper 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Francois Dugast 
Reviewed-by: José Roberto de Souza

drm/xe/uapi: Add Tile ID information to the GT info query

2023-12-21T16:45:19+00:00

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 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: José Roberto de Souza

drm/xe/uapi: Crystal Reference Clock updates

2023-12-21T16:45:19+00:00

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 
Umesh Nerlige Ramappa 
Cc: Jose Souza 

Signed-off-by: Rodrigo Vivi 
Signed-off-by: Francois Dugast 
Reviewed-by: José Roberto de Souza

drm/xe/uapi: Align on a common way to return arrays (engines)

2023-12-21T16:45:19+00:00

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 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: José Roberto de Souza 
Signed-off-by: Rodrigo Vivi

drm/xe/uapi: Align on a common way to return arrays (gt)

2023-12-21T16:45:16+00:00

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 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Matt Roper 
Reviewed-by: José Roberto de Souza 
Signed-off-by: Rodrigo Vivi

drm/xe/uapi: Align on a common way to return arrays (memory regions)

2023-12-21T16:45:16+00:00

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 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: José Roberto de Souza 
Signed-off-by: Rodrigo Vivi

drm/xe: Make DRM_XE_DEVICE_QUERY_ENGINES future proof

2023-12-21T16:45:12+00:00

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 
Cc: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Rodrigo Vivi 
[Rodrigo Rebased]
Signed-off-by: Francois Dugast 
Reviewed-by: José Roberto de Souza

drm/xe/uapi: Standardize the FLAG naming and assignment

2023-12-21T16:44:38+00:00

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 
Signed-off-by: Francois Dugast 
Reviewed-by: Matthew Brost