Merge drm/drm-next into drm-misc-next

    PSP

        Platform Security Processor

    RCL

    RLC

      RunList Controller

    SDMA

.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c

   :doc: gpu_metrics

GFXOFF

======

GFXOFF is a feature found in most recent GPUs that saves power at runtime. The

card's RLC (RunList Controller) firmware powers off the gfx engine

dynamically when there is no workload on gfx or compute pipes. GFXOFF is on by

default on supported GPUs.

Userspace can interact with GFXOFF through a debugfs interface:

``amdgpu_gfxoff``

-----------------

Use it to enable/disable GFXOFF, and to check if it's current enabled/disabled::

  $ xxd -l1 -p /sys/kernel/debug/dri/0/amdgpu_gfxoff

  01

- Write 0 to disable it, and 1 to enable it.

- Read 0 means it's disabled, 1 it's enabled.

If it's enabled, that means that the GPU is free to enter into GFXOFF mode as

needed. Disabled means that it will never enter GFXOFF mode.

``amdgpu_gfxoff_status``

------------------------

Read it to check current GFXOFF's status of a GPU::

  $ xxd -l1 -p /sys/kernel/debug/dri/0/amdgpu_gfxoff_status

  02

- 0: GPU is in GFXOFF state, the gfx engine is powered down.

- 1: Transition out of GFXOFF state

- 2: Not in GFXOFF state

- 3: Transition into GFXOFF state

If GFXOFF is enabled, the value will be transitioning around [0, 3], always

getting into 0 when possible. When it's disabled, it's always at 2. Returns

``-EINVAL`` if it's not supported.

/**

 * struct __drm_i915_memory_region_info - Describes one region as known to the

 * driver.

 *

 * Note this is using both struct drm_i915_query_item and struct drm_i915_query.

 * For this new query we are adding the new query id DRM_I915_QUERY_MEMORY_REGIONS

 * at &drm_i915_query_item.query_id.

 */

struct __drm_i915_memory_region_info {

	/** @region: The class:instance pair encoding */

	struct drm_i915_gem_memory_class_instance region;

	/** @rsvd0: MBZ */

	__u32 rsvd0;

	/**

	 * @probed_size: Memory probed by the driver

	 *

	 * Note that it should not be possible to ever encounter a zero value

	 * here, also note that no current region type will ever return -1 here.

	 * Although for future region types, this might be a possibility. The

	 * same applies to the other size fields.

	 */

	__u64 probed_size;

	/**

	 * @unallocated_size: Estimate of memory remaining

	 *

	 * Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable accounting.

	 * Without this (or if this is an older kernel) the value here will

	 * always equal the @probed_size. Note this is only currently tracked

	 * for I915_MEMORY_CLASS_DEVICE regions (for other types the value here

	 * will always equal the @probed_size).

	 */

	__u64 unallocated_size;

	union {

		/** @rsvd1: MBZ */

		__u64 rsvd1[8];

		struct {

			/**

			 * @probed_cpu_visible_size: Memory probed by the driver

			 * that is CPU accessible.

			 *

			 * This will be always be <= @probed_size, and the

			 * remainder (if there is any) will not be CPU

			 * accessible.

			 *

			 * On systems without small BAR, the @probed_size will

			 * always equal the @probed_cpu_visible_size, since all

			 * of it will be CPU accessible.

			 *

			 * Note this is only tracked for

			 * I915_MEMORY_CLASS_DEVICE regions (for other types the

			 * value here will always equal the @probed_size).

			 *

			 * Note that if the value returned here is zero, then

			 * this must be an old kernel which lacks the relevant

			 * small-bar uAPI support (including

			 * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on

			 * such systems we should never actually end up with a

			 * small BAR configuration, assuming we are able to load

			 * the kernel module. Hence it should be safe to treat

			 * this the same as when @probed_cpu_visible_size ==

			 * @probed_size.

			 */

			__u64 probed_cpu_visible_size;

			/**

			 * @unallocated_cpu_visible_size: Estimate of CPU

			 * visible memory remaining

			 *

			 * Note this is only tracked for

			 * I915_MEMORY_CLASS_DEVICE regions (for other types the

			 * value here will always equal the

			 * @probed_cpu_visible_size).

			 *

			 * Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable

			 * accounting.  Without this the value here will always

			 * equal the @probed_cpu_visible_size. Note this is only

			 * currently tracked for I915_MEMORY_CLASS_DEVICE

			 * regions (for other types the value here will also

			 * always equal the @probed_cpu_visible_size).

			 *

			 * If this is an older kernel the value here will be

			 * zero, see also @probed_cpu_visible_size.

			 */

			__u64 unallocated_cpu_visible_size;

		};

	};

};

/**

 * struct __drm_i915_gem_create_ext - Existing gem_create behaviour, with added

 * extension support using struct i915_user_extension.

 *

 * Note that new buffer flags should be added here, at least for the stuff that

 * is immutable. Previously we would have two ioctls, one to create the object

 * with gem_create, and another to apply various parameters, however this

 * creates some ambiguity for the params which are considered immutable. Also in

 * general we're phasing out the various SET/GET ioctls.

 */

struct __drm_i915_gem_create_ext {

	/**

	 * @size: Requested size for the object.

	 *

	 * The (page-aligned) allocated size for the object will be returned.

	 *

	 * Note that for some devices we have might have further minimum

	 * page-size restrictions (larger than 4K), like for device local-memory.

	 * However in general the final size here should always reflect any

	 * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS

	 * extension to place the object in device local-memory. The kernel will

	 * always select the largest minimum page-size for the set of possible

	 * placements as the value to use when rounding up the @size.

	 */

	__u64 size;

	/**

	 * @handle: Returned handle for the object.

	 *

	 * Object handles are nonzero.

	 */

	__u32 handle;

	/**

	 * @flags: Optional flags.

	 *

	 * Supported values:

	 *

	 * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the kernel that

	 * the object will need to be accessed via the CPU.

	 *

	 * Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, and only

	 * strictly required on configurations where some subset of the device

	 * memory is directly visible/mappable through the CPU (which we also

	 * call small BAR), like on some DG2+ systems. Note that this is quite

	 * undesirable, but due to various factors like the client CPU, BIOS etc

	 * it's something we can expect to see in the wild. See

	 * &__drm_i915_memory_region_info.probed_cpu_visible_size for how to

	 * determine if this system applies.

	 *

	 * Note that one of the placements MUST be I915_MEMORY_CLASS_SYSTEM, to

	 * ensure the kernel can always spill the allocation to system memory,

	 * if the object can't be allocated in the mappable part of

	 * I915_MEMORY_CLASS_DEVICE.

	 *

	 * Also note that since the kernel only supports flat-CCS on objects

	 * that can *only* be placed in I915_MEMORY_CLASS_DEVICE, we therefore

	 * don't support I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS together with

	 * flat-CCS.

	 *

	 * Without this hint, the kernel will assume that non-mappable

	 * I915_MEMORY_CLASS_DEVICE is preferred for this object. Note that the

	 * kernel can still migrate the object to the mappable part, as a last

	 * resort, if userspace ever CPU faults this object, but this might be

	 * expensive, and so ideally should be avoided.

	 *

	 * On older kernels which lack the relevant small-bar uAPI support (see

	 * also &__drm_i915_memory_region_info.probed_cpu_visible_size),

	 * usage of the flag will result in an error, but it should NEVER be

	 * possible to end up with a small BAR configuration, assuming we can

	 * also successfully load the i915 kernel module. In such cases the

	 * entire I915_MEMORY_CLASS_DEVICE region will be CPU accessible, and as

	 * such there are zero restrictions on where the object can be placed.

	 */

#define I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS (1 << 0)

	__u32 flags;

	/**

	 * @extensions: The chain of extensions to apply to this object.

	 *

	 * This will be useful in the future when we need to support several

	 * different extensions, and we need to apply more than one when

	 * creating the object. See struct i915_user_extension.

	 *

	 * If we don't supply any extensions then we get the same old gem_create

	 * behaviour.

	 *

	 * For I915_GEM_CREATE_EXT_MEMORY_REGIONS usage see

	 * struct drm_i915_gem_create_ext_memory_regions.

	 *

	 * For I915_GEM_CREATE_EXT_PROTECTED_CONTENT usage see

	 * struct drm_i915_gem_create_ext_protected_content.

	 */

#define I915_GEM_CREATE_EXT_MEMORY_REGIONS 0

#define I915_GEM_CREATE_EXT_PROTECTED_CONTENT 1

	__u64 extensions;

};

==========================

I915 Small BAR RFC Section

==========================

Starting from DG2 we will have resizable BAR support for device local-memory(i.e

I915_MEMORY_CLASS_DEVICE), but in some cases the final BAR size might still be

smaller than the total probed_size. In such cases, only some subset of

I915_MEMORY_CLASS_DEVICE will be CPU accessible(for example the first 256M),

while the remainder is only accessible via the GPU.

I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS flag

----------------------------------------------

New gem_create_ext flag to tell the kernel that a BO will require CPU access.

This becomes important when placing an object in I915_MEMORY_CLASS_DEVICE, where

underneath the device has a small BAR, meaning only some portion of it is CPU

accessible. Without this flag the kernel will assume that CPU access is not

required, and prioritize using the non-CPU visible portion of

I915_MEMORY_CLASS_DEVICE.

.. kernel-doc:: Documentation/gpu/rfc/i915_small_bar.h

   :functions: __drm_i915_gem_create_ext

probed_cpu_visible_size attribute

---------------------------------

New struct__drm_i915_memory_region attribute which returns the total size of the

CPU accessible portion, for the particular region. This should only be

applicable for I915_MEMORY_CLASS_DEVICE. We also report the

unallocated_cpu_visible_size, alongside the unallocated_size.

Vulkan will need this as part of creating a separate VkMemoryHeap with the

VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT set, to represent the CPU visible portion,

where the total size of the heap needs to be known. It also wants to be able to

give a rough estimate of how memory can potentially be allocated.

.. kernel-doc:: Documentation/gpu/rfc/i915_small_bar.h

   :functions: __drm_i915_memory_region_info

Error Capture restrictions

--------------------------

With error capture we have two new restrictions:

    1) Error capture is best effort on small BAR systems; if the pages are not

    CPU accessible, at the time of capture, then the kernel is free to skip

    trying to capture them.

    2) On discrete and newer integrated platforms we now reject error capture

    on recoverable contexts. In the future the kernel may want to blit during

    error capture, when for example something is not currently CPU accessible.

/* SPDX-License-Identifier: MIT */

/*

 * Copyright © 2022 Intel Corporation

 */

/**

 * DOC: I915_PARAM_VM_BIND_VERSION

 *

 * VM_BIND feature version supported.

 * See typedef drm_i915_getparam_t param.

 *

 * Specifies the VM_BIND feature version supported.

 * The following versions of VM_BIND have been defined:

 *

 * 0: No VM_BIND support.

 *

 * 1: In VM_UNBIND calls, the UMD must specify the exact mappings created

 *    previously with VM_BIND, the ioctl will not support unbinding multiple

 *    mappings or splitting them. Similarly, VM_BIND calls will not replace

 *    any existing mappings.

 *

 * 2: The restrictions on unbinding partial or multiple mappings is

 *    lifted, Similarly, binding will replace any mappings in the given range.

 *

 * See struct drm_i915_gem_vm_bind and struct drm_i915_gem_vm_unbind.

 */

#define I915_PARAM_VM_BIND_VERSION	57

/**

 * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND

 *

 * Flag to opt-in for VM_BIND mode of binding during VM creation.

 * See struct drm_i915_gem_vm_control flags.

 *

 * The older execbuf2 ioctl will not support VM_BIND mode of operation.

 * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any

 * execlist (See struct drm_i915_gem_execbuffer3 for more details).

 */

#define I915_VM_CREATE_FLAGS_USE_VM_BIND	(1 << 0)

/* VM_BIND related ioctls */

#define DRM_I915_GEM_VM_BIND		0x3d

#define DRM_I915_GEM_VM_UNBIND		0x3e

#define DRM_I915_GEM_EXECBUFFER3	0x3f

#define DRM_IOCTL_I915_GEM_VM_BIND		DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)

#define DRM_IOCTL_I915_GEM_VM_UNBIND		DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)

#define DRM_IOCTL_I915_GEM_EXECBUFFER3		DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)

/**

 * struct drm_i915_gem_timeline_fence - An input or output timeline fence.

 *

 * The operation will wait for input fence to signal.

 *

 * The returned output fence will be signaled after the completion of the

 * operation.

 */

struct drm_i915_gem_timeline_fence {

	/** @handle: User's handle for a drm_syncobj to wait on or signal. */

	__u32 handle;

	/**

	 * @flags: Supported flags are:

	 *

	 * I915_TIMELINE_FENCE_WAIT:

	 * Wait for the input fence before the operation.

	 *

	 * I915_TIMELINE_FENCE_SIGNAL:

	 * Return operation completion fence as output.

	 */

	__u32 flags;

#define I915_TIMELINE_FENCE_WAIT            (1 << 0)

#define I915_TIMELINE_FENCE_SIGNAL          (1 << 1)

#define __I915_TIMELINE_FENCE_UNKNOWN_FLAGS (-(I915_TIMELINE_FENCE_SIGNAL << 1))

	/**

	 * @value: A point in the timeline.

	 * Value must be 0 for a binary drm_syncobj. A Value of 0 for a

	 * timeline drm_syncobj is invalid as it turns a drm_syncobj into a

	 * binary one.

	 */

	__u64 value;

};

/**

 * struct drm_i915_gem_vm_bind - VA to object mapping to bind.

 *

 * This structure is passed to VM_BIND ioctl and specifies the mapping of GPU

 * virtual address (VA) range to the section of an object that should be bound

 * in the device page table of the specified address space (VM).

 * The VA range specified must be unique (ie., not currently bound) and can

 * be mapped to whole object or a section of the object (partial binding).

 * Multiple VA mappings can be created to the same section of the object

 * (aliasing).

 *

 * The @start, @offset and @length must be 4K page aligned. However the DG2

 * and XEHPSDV has 64K page size for device local memory and has compact page

 * table. On those platforms, for binding device local-memory objects, the

 * @start, @offset and @length must be 64K aligned. Also, UMDs should not mix

 * the local memory 64K page and the system memory 4K page bindings in the same

 * 2M range.

 *

 * Error code -EINVAL will be returned if @start, @offset and @length are not

 * properly aligned. In version 1 (See I915_PARAM_VM_BIND_VERSION), error code

 * -ENOSPC will be returned if the VA range specified can't be reserved.

 *

 * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently

 * are not ordered. Furthermore, parts of the VM_BIND operation can be done

 * asynchronously, if valid @fence is specified.

 */

struct drm_i915_gem_vm_bind {

	/** @vm_id: VM (address space) id to bind */

	__u32 vm_id;

	/** @handle: Object handle */

	__u32 handle;

	/** @start: Virtual Address start to bind */

	__u64 start;

	/** @offset: Offset in object to bind */

	__u64 offset;

	/** @length: Length of mapping to bind */

	__u64 length;

	/**

	 * @flags: Supported flags are:

	 *

	 * I915_GEM_VM_BIND_CAPTURE:

	 * Capture this mapping in the dump upon GPU error.

	 *

	 * Note that @fence carries its own flags.

	 */

	__u64 flags;

#define I915_GEM_VM_BIND_CAPTURE	(1 << 0)

	/**

	 * @fence: Timeline fence for bind completion signaling.

	 *

	 * Timeline fence is of format struct drm_i915_gem_timeline_fence.

	 *

	 * It is an out fence, hence using I915_TIMELINE_FENCE_WAIT flag

	 * is invalid, and an error will be returned.

	 *

	 * If I915_TIMELINE_FENCE_SIGNAL flag is not set, then out fence

	 * is not requested and binding is completed synchronously.

	 */

	struct drm_i915_gem_timeline_fence fence;

	/**

	 * @extensions: Zero-terminated chain of extensions.

	 *

	 * For future extensions. See struct i915_user_extension.

	 */

	__u64 extensions;

};

/**

 * struct drm_i915_gem_vm_unbind - VA to object mapping to unbind.

 *

 * This structure is passed to VM_UNBIND ioctl and specifies the GPU virtual

 * address (VA) range that should be unbound from the device page table of the

 * specified address space (VM). VM_UNBIND will force unbind the specified

 * range from device page table without waiting for any GPU job to complete.

 * It is UMDs responsibility to ensure the mapping is no longer in use before

 * calling VM_UNBIND.

 *

 * If the specified mapping is not found, the ioctl will simply return without

 * any error.

 *

 * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently

 * are not ordered. Furthermore, parts of the VM_UNBIND operation can be done

 * asynchronously, if valid @fence is specified.

 */

struct drm_i915_gem_vm_unbind {

	/** @vm_id: VM (address space) id to bind */

	__u32 vm_id;

	/** @rsvd: Reserved, MBZ */

	__u32 rsvd;

	/** @start: Virtual Address start to unbind */

	__u64 start;

	/** @length: Length of mapping to unbind */

	__u64 length;

	/**

	 * @flags: Currently reserved, MBZ.

	 *

	 * Note that @fence carries its own flags.

	 */

	__u64 flags;

	/**

	 * @fence: Timeline fence for unbind completion signaling.

	 *

	 * Timeline fence is of format struct drm_i915_gem_timeline_fence.

	 *

	 * It is an out fence, hence using I915_TIMELINE_FENCE_WAIT flag

	 * is invalid, and an error will be returned.

	 *

	 * If I915_TIMELINE_FENCE_SIGNAL flag is not set, then out fence

	 * is not requested and unbinding is completed synchronously.

	 */

	struct drm_i915_gem_timeline_fence fence;

	/**

	 * @extensions: Zero-terminated chain of extensions.

	 *

	 * For future extensions. See struct i915_user_extension.

	 */

	__u64 extensions;

};

/**

 * struct drm_i915_gem_execbuffer3 - Structure for DRM_I915_GEM_EXECBUFFER3

 * ioctl.

 *

 * DRM_I915_GEM_EXECBUFFER3 ioctl only works in VM_BIND mode and VM_BIND mode

 * only works with this ioctl for submission.

 * See I915_VM_CREATE_FLAGS_USE_VM_BIND.

 */

struct drm_i915_gem_execbuffer3 {

	/**

	 * @ctx_id: Context id

	 *

	 * Only contexts with user engine map are allowed.

	 */

	__u32 ctx_id;

	/**

	 * @engine_idx: Engine index

	 *

	 * An index in the user engine map of the context specified by @ctx_id.

	 */

	__u32 engine_idx;

	/**

	 * @batch_address: Batch gpu virtual address/es.

	 *

	 * For normal submission, it is the gpu virtual address of the batch

	 * buffer. For parallel submission, it is a pointer to an array of

	 * batch buffer gpu virtual addresses with array size equal to the

	 * number of (parallel) engines involved in that submission (See

	 * struct i915_context_engines_parallel_submit).

	 */

	__u64 batch_address;

	/** @flags: Currently reserved, MBZ */

	__u64 flags;

	/** @rsvd1: Reserved, MBZ */

	__u32 rsvd1;

	/** @fence_count: Number of fences in @timeline_fences array. */

	__u32 fence_count;

	/**

	 * @timeline_fences: Pointer to an array of timeline fences.

	 *

	 * Timeline fences are of format struct drm_i915_gem_timeline_fence.

	 */

	__u64 timeline_fences;

	/** @rsvd2: Reserved, MBZ */

	__u64 rsvd2;

	/**

	 * @extensions: Zero-terminated chain of extensions.

	 *

	 * For future extensions. See struct i915_user_extension.

	 */

	__u64 extensions;

};

/**

 * struct drm_i915_gem_create_ext_vm_private - Extension to make the object

 * private to the specified VM.

 *

 * See struct drm_i915_gem_create_ext.

 */

struct drm_i915_gem_create_ext_vm_private {

#define I915_GEM_CREATE_EXT_VM_PRIVATE		2

	/** @base: Extension link. See struct i915_user_extension. */

	struct i915_user_extension base;

	/** @vm_id: Id of the VM to which the object is private */

	__u32 vm_id;

};