drm/xe: Strict migration policy for atomic SVM faults

Mixing GPU and CPU atomics does not work unless a strict migration
policy of GPU atomics must be device memory. Enforce a policy of must be
in V

drm/xe: Strict migration policy for atomic SVM faults

Mixing GPU and CPU atomics does not work unless a strict migration
policy of GPU atomics must be device memory. Enforce a policy of must be
in VRAM with a retry loop of 3 attempts, if retry loop fails abort
fault.

Removing always_migrate_to_vram modparam as we now have real migration
policy.

v2:
- Only retry migration on atomics
- Drop alway migrate modparam
v3:
- Only set vram_only on DGFX (Himal)
- Bail on get_pages failure if vram_only and retry count exceeded (Himal)
- s/vram_only/devmem_only
- Update xe_svm_range_is_valid to accept devmem_only argument
v4:
- Fix logic bug get_pages failure
v5:
- Fix commit message (Himal)
- Mention removing always_migrate_to_vram in commit message (Lucas)
- Fix xe_svm_range_is_valid to check for devmem pages
- Bail on devmem_only && !migrate_devmem (Thomas)
v6:
- Add READ_ONCE barriers for opportunistic checks (Thomas)
- Pair READ_ONCE with WRITE_ONCE (Thomas)
v7:
- Adjust comments (Thomas)

Fixes: 2f118c949160 ("drm/xe: Add SVM VRAM migration")
Cc: [email protected]
Signed-off-by: Himal Prasad Ghimiray <[email protected]>
Signed-off-by: Matthew Brost <[email protected]>
Acked-by: Himal Prasad Ghimiray <[email protected]>
Reviewed-by: Thomas Hellström <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
(cherry picked from commit a9ac0fa455b050d03e3032501368048fb284d318)
Signed-off-by: Lucas De Marchi <[email protected]>

show more ...

drm/xe: Add always_migrate_to_vram modparam

Used to show we can bounce memory multiple times which will happen once
a real migration policy is implemented. Can be removed once migration
policy is im

drm/xe: Add always_migrate_to_vram modparam

Used to show we can bounce memory multiple times which will happen once
a real migration policy is implemented. Can be removed once migration
policy is implemented.

v3:
- Pull some changes into the previous patch (Thomas)
- Better commit message (Thomas)

Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Thomas Hellström <[email protected]>
Reviewed-by: Himal Prasad Ghimiray <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/xe: Add modparam for SVM notifier size

Useful to experiment with notifier size and how it affects performance.

v3:
- Pull missing changes including in following patch (Thomas)
v5:
- Spell out

drm/xe: Add modparam for SVM notifier size

Useful to experiment with notifier size and how it affects performance.

v3:
- Pull missing changes including in following patch (Thomas)
v5:
- Spell out power of 2 (Thomas)

Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Thomas Hellström <[email protected]>
Reviewed-by: Himal Prasad Ghimiray <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/xe: Rename enable_display module param

The different approach used by xe regarding the initialization of
display HW has been proved a great addition for early driver bring up:
core xe can be tes

drm/xe: Rename enable_display module param

The different approach used by xe regarding the initialization of
display HW has been proved a great addition for early driver bring up:
core xe can be tested without having all the bits sorted out on the
display side.

On the other hand, the approach exposed by i915-display is to *actively*
disable the display by programming it if needed, i.e. if it was left
enabled by firmware. It also has its use to make sure the HW is actually
disabled and not wasting power.

However having both the way it is in xe doesn't expose a good interface
wrt module params. From modinfo:

disable_display:Disable display (default: false) (bool)
enable_display:Enable display (bool)

Rename enable_display to probe_display to try to convey the message that
the HW is being touched and improve the module param description. To
avoid confusion, the enable_display is renamed everywhere, not only in
the module param. New description for the parameters:

disable_display:Disable display (default: false) (bool)
probe_display:Probe display HW, otherwise it's left untouched (default: true) (bool)

Reviewed-by: Matt Roper <[email protected]>
Acked-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Lucas De Marchi <[email protected]>

show more ...

drm/xe: Force wedged state and block GT reset upon any GPU hang

In many validation situations when debugging GPU Hangs,
it is useful to preserve the GT situation from the moment
that the timeout occ

drm/xe: Force wedged state and block GT reset upon any GPU hang

In many validation situations when debugging GPU Hangs,
it is useful to preserve the GT situation from the moment
that the timeout occurred.

This patch introduces a module parameter that could be used
on situations like this.

If xe.wedged module parameter is set to 2, Xe will be declared
wedged on every single execution timeout (a.k.a. GPU hang) right
after devcoredump snapshot capture and without attempting any
kind of GT reset and blocking entirely any kind of execution.

v2: Really block gt_reset from guc side. (Lucas)
s/wedged/busted (Lucas)

v3: - s/busted/wedged
- Really use global_flags (Dafna)
- More robust timeout handling when wedging it.

v4: A really robust clean exit done by Matt Brost.
No more kernel warns on unbind.

v5: Simplify error message (Lucas)

Cc: Matthew Brost <[email protected]>
Cc: Dafna Hirschfeld <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Alan Previn <[email protected]>
Cc: Himanshu Somaiya <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>

show more ...

drm/xe: Add max_vfs module parameter

We want to have an option to limit the number of the VFs that the
PF driver will be able to manage. With this limit set to zero we
will also have a way to compl

drm/xe: Add max_vfs module parameter

We want to have an option to limit the number of the VFs that the
PF driver will be able to manage. With this limit set to zero we
will also have a way to completely disable the PF functionality.

Since we currently don't support SR-IOV on any platform, we start
with this limit set to zero by default.

Signed-off-by: Michal Wajdeczko <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/xe/gsc: Define GSC FW for MTL

We track GSC FW based on its compatibility version, which is what
determines the interface it supports.
Also add a modparam override like the ones for GuC and HuC.

drm/xe/gsc: Define GSC FW for MTL

We track GSC FW based on its compatibility version, which is what
determines the interface it supports.
Also add a modparam override like the ones for GuC and HuC.

v2: fix module param description (John)

Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Cc: Alan Previn <[email protected]>
Cc: John Harrison <[email protected]>
Reviewed-by: John Harrison <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>

show more ...

drm/xe: Encapsulate all the module parameters

Encapsulate all the module parameters in one single global struct
variable. This also removes the extra xe_module.h from includes.

v2: naming consisten

drm/xe: Encapsulate all the module parameters

Encapsulate all the module parameters in one single global struct
variable. This also removes the extra xe_module.h from includes.

v2: naming consistency as suggested by Jani and Lucas
v3: fix checkpatch errors/warnings
v4: adding blank line after struct declaration

Cc: Jani Nikula <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Signed-off-by: Bommithi Sakeena <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>

show more ...

drm/xe/uc: Add GuC/HuC firmware path overrides

When testing a new binary and/or debugging binary-related issues, it is
useful to have the option to change which binary is loaded without
having to up

drm/xe/uc: Add GuC/HuC firmware path overrides

When testing a new binary and/or debugging binary-related issues, it is
useful to have the option to change which binary is loaded without
having to update and re-compile the kernel. To support this option, this
patch adds 2 new modparams to override the FW path for GuC and HuC. The
HuC modparam can also be set to an empty string to disable HuC loading.

Note that those modparams only take effect on platforms where we already
have a default FW, so we're sure there is support for FW loading and the
kernel isn't going to explode in an undefined path.

v2: simplify comment (John),
rebase on s/guc_submission_enabled/uc_enabled

Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Cc: John Harrison <[email protected]>
Cc: Matthew Brost <[email protected]>
Reviewed-by: John Harrison <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>

show more ...

drm/xe: Invert guc vs execlists parameters and info.

The module parameter should reflect the name of the optional,
experimental and unsafe option, rather than the default one.

Signed-off-by: Rodrig

drm/xe: Invert guc vs execlists parameters and info.

The module parameter should reflect the name of the optional,
experimental and unsafe option, rather than the default one.

Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>

show more ...

drm/xe: Include only relevant header in xe_module.h

Things defined in <linux/init.h> are not really used by that header.
Replace that with <linux/types.h>, to have bool and u32 available.

Signed-of

drm/xe: Include only relevant header in xe_module.h

Things defined in <linux/init.h> are not really used by that header.
Replace that with <linux/types.h>, to have bool and u32 available.

Signed-off-by: Gustavo Sousa <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>

show more ...

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

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 <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Gwan-gyeong Mun <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Acked-by: Lucas De Marchi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>

show more ...

drm/xe: Introduce a new DRM driver for Intel GPUs

Xe, is a new driver for Intel GPUs that supports both integrated and
discrete platforms starting with Tiger Lake (first Intel Xe Architecture).

The

drm/xe: Introduce a new DRM driver for Intel GPUs

Xe, is a new driver for Intel GPUs that supports both integrated and
discrete platforms starting with Tiger Lake (first Intel Xe Architecture).

The code is at a stage where it is already functional and has experimental
support for multiple platforms starting from Tiger Lake, with initial
support implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan
drivers), as well as in NEO (for OpenCL and Level0).

The new Xe driver leverages a lot from i915.

As for display, the intent is to share the display code with the i915
driver so that there is maximum reuse there. But it is not added
in this patch.

This initial work is a collaboration of many people and unfortunately
the big squashed patch won't fully honor the proper credits. But let's
get some git quick stats so we can at least try to preserve some of the
credits:

Co-developed-by: Matthew Brost <[email protected]>
Co-developed-by: Matthew Auld <[email protected]>
Co-developed-by: Matt Roper <[email protected]>
Co-developed-by: Thomas Hellström <[email protected]>
Co-developed-by: Francois Dugast <[email protected]>
Co-developed-by: Lucas De Marchi <[email protected]>
Co-developed-by: Maarten Lankhorst <[email protected]>
Co-developed-by: Philippe Lecluse <[email protected]>
Co-developed-by: Nirmoy Das <[email protected]>
Co-developed-by: Jani Nikula <[email protected]>
Co-developed-by: José Roberto de Souza <[email protected]>
Co-developed-by: Rodrigo Vivi <[email protected]>
Co-developed-by: Dave Airlie <[email protected]>
Co-developed-by: Faith Ekstrand <[email protected]>
Co-developed-by: Daniel Vetter <[email protected]>
Co-developed-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Matthew Brost <[email protected]>

show more ...