2019-06-03 07:44:50 +02:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
drm/msm: basic KMS driver for snapdragon
The snapdragon chips have multiple different display controllers,
depending on which chip variant/version. (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.) And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.
To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.
The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently. But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge. This
would remove the 'msm_connector' base class. But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..
This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-06-26 12:44:06 -04:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2013 Red Hat
|
|
|
|
* Author: Rob Clark <robdclark@gmail.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __MSM_GEM_H__
|
|
|
|
#define __MSM_GEM_H__
|
|
|
|
|
2025-06-29 13:13:16 -07:00
|
|
|
#include "msm_mmu.h"
|
2017-03-07 10:02:52 -07:00
|
|
|
#include <linux/kref.h>
|
2019-08-11 10:06:32 +02:00
|
|
|
#include <linux/dma-resv.h>
|
2023-11-20 16:38:51 -08:00
|
|
|
#include "drm/drm_exec.h"
|
2025-06-29 13:12:56 -07:00
|
|
|
#include "drm/drm_gpuvm.h"
|
2021-07-27 18:06:14 -07:00
|
|
|
#include "drm/gpu_scheduler.h"
|
drm/msm: basic KMS driver for snapdragon
The snapdragon chips have multiple different display controllers,
depending on which chip variant/version. (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.) And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.
To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.
The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently. But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge. This
would remove the 'msm_connector' base class. But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..
This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-06-26 12:44:06 -04:00
|
|
|
#include "msm_drv.h"
|
|
|
|
|
2021-04-05 10:45:24 -07:00
|
|
|
/* Make all GEM related WARN_ON()s ratelimited.. when things go wrong they
|
|
|
|
* tend to go wrong 1000s of times in a short timespan.
|
|
|
|
*/
|
|
|
|
#define GEM_WARN_ON(x) WARN_RATELIMIT(x, "%s", __stringify(x))
|
|
|
|
|
2015-03-03 15:04:25 -05:00
|
|
|
/* Additional internal-use only BO flags: */
|
|
|
|
#define MSM_BO_STOLEN 0x10000000 /* try to use stolen/splash memory */
|
2020-04-23 17:09:14 -04:00
|
|
|
#define MSM_BO_MAP_PRIV 0x20000000 /* use IOMMU_PRIV when mapping */
|
2015-03-03 15:04:25 -05:00
|
|
|
|
2025-06-29 13:13:19 -07:00
|
|
|
/**
|
|
|
|
* struct msm_gem_vm_log_entry - An entry in the VM log
|
|
|
|
*
|
|
|
|
* For userspace managed VMs, a log of recent VM updates is tracked and
|
|
|
|
* captured in GPU devcore dumps, to aid debugging issues caused by (for
|
|
|
|
* example) incorrectly synchronized VM updates
|
|
|
|
*/
|
|
|
|
struct msm_gem_vm_log_entry {
|
|
|
|
const char *op;
|
|
|
|
uint64_t iova;
|
|
|
|
uint64_t range;
|
|
|
|
int queue_id;
|
|
|
|
};
|
|
|
|
|
2025-06-29 13:12:56 -07:00
|
|
|
/**
|
|
|
|
* struct msm_gem_vm - VM object
|
|
|
|
*
|
|
|
|
* A VM object representing a GPU (or display or GMU or ...) virtual address
|
|
|
|
* space.
|
|
|
|
*
|
|
|
|
* In the case of GPU, if per-process address spaces are supported, the address
|
|
|
|
* space is split into two VMs, which map to TTBR0 and TTBR1 in the SMMU. TTBR0
|
|
|
|
* is used for userspace objects, and is unique per msm_context/drm_file, while
|
|
|
|
* TTBR1 is the same for all processes. (The kernel controlled ringbuffer and
|
|
|
|
* a few other kernel controlled buffers live in TTBR1.)
|
|
|
|
*
|
|
|
|
* The GPU TTBR0 vm can be managed by userspace or by the kernel, depending on
|
|
|
|
* whether userspace supports VM_BIND. All other vm's are managed by the kernel.
|
|
|
|
* (Managed by kernel means the kernel is responsible for VA allocation.)
|
|
|
|
*
|
|
|
|
* Note that because VM_BIND allows a given BO to be mapped multiple times in
|
|
|
|
* a VM, and therefore have multiple VMA's in a VM, there is an extra object
|
|
|
|
* provided by drm_gpuvm infrastructure.. the drm_gpuvm_bo, which is not
|
|
|
|
* embedded in any larger driver structure. The GEM object holds a list of
|
|
|
|
* drm_gpuvm_bo, which in turn holds a list of msm_gem_vma. A linked vma
|
|
|
|
* holds a reference to the vm_bo, and drops it when the vma is unlinked.
|
|
|
|
* So we just need to call drm_gpuvm_bo_obtain() to return a ref to an
|
|
|
|
* existing vm_bo, or create a new one. Once the vma is linked, the ref
|
|
|
|
* to the vm_bo can be dropped (since the vma is holding one).
|
|
|
|
*/
|
2025-06-29 13:12:49 -07:00
|
|
|
struct msm_gem_vm {
|
2025-06-29 13:12:56 -07:00
|
|
|
/** @base: Inherit from drm_gpuvm. */
|
|
|
|
struct drm_gpuvm base;
|
|
|
|
|
2025-06-29 13:13:14 -07:00
|
|
|
/**
|
|
|
|
* @sched: Scheduler used for asynchronous VM_BIND request.
|
|
|
|
*
|
|
|
|
* Unused for kernel managed VMs (where all operations are synchronous).
|
|
|
|
*/
|
|
|
|
struct drm_gpu_scheduler sched;
|
|
|
|
|
2025-06-29 13:13:25 -07:00
|
|
|
/**
|
|
|
|
* @prealloc_throttle: Used to throttle VM_BIND ops if too much pre-
|
|
|
|
* allocated memory is in flight.
|
|
|
|
*
|
|
|
|
* Because we have to pre-allocate pgtable pages for the worst case
|
|
|
|
* (ie. new mappings do not share any PTEs with existing mappings)
|
|
|
|
* we could end up consuming a lot of resources transiently. The
|
|
|
|
* prealloc_throttle puts an upper bound on that.
|
|
|
|
*/
|
|
|
|
struct {
|
|
|
|
/** @wait: Notified when preallocated resources are released */
|
|
|
|
wait_queue_head_t wait;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @in_flight: The # of preallocated pgtable pages in-flight
|
|
|
|
* for queued VM_BIND jobs.
|
|
|
|
*/
|
|
|
|
atomic_t in_flight;
|
|
|
|
} prealloc_throttle;
|
|
|
|
|
2025-06-29 13:12:56 -07:00
|
|
|
/**
|
|
|
|
* @mm: Memory management for kernel managed VA allocations
|
|
|
|
*
|
|
|
|
* Only used for kernel managed VMs, unused for user managed VMs.
|
|
|
|
*
|
|
|
|
* Protected by @mm_lock.
|
2016-09-28 19:58:32 -04:00
|
|
|
*/
|
|
|
|
struct drm_mm mm;
|
2025-06-29 13:12:56 -07:00
|
|
|
|
|
|
|
/** @mmu: The mmu object which manages the pgtables */
|
2016-09-28 19:58:32 -04:00
|
|
|
struct msm_mmu *mmu;
|
2020-08-17 15:01:45 -07:00
|
|
|
|
2025-06-29 13:13:18 -07:00
|
|
|
/** @mmu_lock: Protects access to the mmu */
|
|
|
|
struct mutex mmu_lock;
|
|
|
|
|
2025-06-29 13:12:56 -07:00
|
|
|
/**
|
|
|
|
* @pid: For address spaces associated with a specific process, this
|
2020-08-17 15:01:45 -07:00
|
|
|
* will be non-NULL:
|
|
|
|
*/
|
|
|
|
struct pid *pid;
|
2022-02-01 08:16:12 -08:00
|
|
|
|
2025-06-29 13:13:14 -07:00
|
|
|
/** @last_fence: Fence for last pending work scheduled on the VM */
|
|
|
|
struct dma_fence *last_fence;
|
|
|
|
|
2025-06-29 13:13:19 -07:00
|
|
|
/** @log: A log of recent VM updates */
|
|
|
|
struct msm_gem_vm_log_entry *log;
|
|
|
|
|
|
|
|
/** @log_shift: length of @log is (1 << @log_shift) */
|
|
|
|
uint32_t log_shift;
|
|
|
|
|
|
|
|
/** @log_idx: index of next @log entry to write */
|
|
|
|
uint32_t log_idx;
|
|
|
|
|
2025-06-29 13:12:56 -07:00
|
|
|
/** @faults: the number of GPU hangs associated with this address space */
|
2022-02-01 08:16:12 -08:00
|
|
|
int faults;
|
2022-04-11 14:58:39 -07:00
|
|
|
|
2025-06-29 13:12:56 -07:00
|
|
|
/** @managed: is this a kernel managed VM? */
|
|
|
|
bool managed;
|
2025-06-29 13:13:06 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @unusable: True if the VM has turned unusable because something
|
|
|
|
* bad happened during an asynchronous request.
|
|
|
|
*
|
|
|
|
* We don't try to recover from such failures, because this implies
|
|
|
|
* informing userspace about the specific operation that failed, and
|
|
|
|
* hoping the userspace driver can replay things from there. This all
|
|
|
|
* sounds very complicated for little gain.
|
|
|
|
*
|
|
|
|
* Instead, we should just flag the VM as unusable, and fail any
|
|
|
|
* further request targeting this VM.
|
|
|
|
*
|
|
|
|
* As an analogy, this would be mapped to a VK_ERROR_DEVICE_LOST
|
|
|
|
* situation, where the logical device needs to be re-created.
|
|
|
|
*/
|
|
|
|
bool unusable;
|
2016-09-28 19:58:32 -04:00
|
|
|
};
|
2025-06-29 13:12:56 -07:00
|
|
|
#define to_msm_vm(x) container_of(x, struct msm_gem_vm, base)
|
2016-09-28 19:58:32 -04:00
|
|
|
|
2025-06-29 13:12:58 -07:00
|
|
|
struct drm_gpuvm *
|
2025-06-29 13:12:56 -07:00
|
|
|
msm_gem_vm_create(struct drm_device *drm, struct msm_mmu *mmu, const char *name,
|
|
|
|
u64 va_start, u64 va_size, bool managed);
|
2022-04-11 14:58:30 -07:00
|
|
|
|
2025-06-29 13:13:14 -07:00
|
|
|
void msm_gem_vm_close(struct drm_gpuvm *gpuvm);
|
2025-06-29 13:13:19 -07:00
|
|
|
void msm_gem_vm_unusable(struct drm_gpuvm *gpuvm);
|
2025-06-29 13:13:14 -07:00
|
|
|
|
2022-04-11 14:58:38 -07:00
|
|
|
struct msm_fence_context;
|
|
|
|
|
2025-06-29 13:12:56 -07:00
|
|
|
#define MSM_VMA_DUMP (DRM_GPUVA_USERBITS << 0)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct msm_gem_vma - a VMA mapping
|
|
|
|
*
|
|
|
|
* Represents a combination of a GEM object plus a VM.
|
|
|
|
*/
|
2016-09-28 19:58:32 -04:00
|
|
|
struct msm_gem_vma {
|
2025-06-29 13:12:56 -07:00
|
|
|
/** @base: inherit from drm_gpuva */
|
|
|
|
struct drm_gpuva base;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @node: mm node for VA allocation
|
|
|
|
*
|
|
|
|
* Only used by kernel managed VMs
|
|
|
|
*/
|
2016-09-28 19:58:32 -04:00
|
|
|
struct drm_mm_node node;
|
2025-06-29 13:12:56 -07:00
|
|
|
|
|
|
|
/** @mapped: Is this VMA mapped? */
|
2018-11-07 15:35:48 -07:00
|
|
|
bool mapped;
|
2016-09-28 19:58:32 -04:00
|
|
|
};
|
2025-06-29 13:12:56 -07:00
|
|
|
#define to_msm_vma(x) container_of(x, struct msm_gem_vma, base)
|
2016-09-28 19:58:32 -04:00
|
|
|
|
2025-06-29 13:12:58 -07:00
|
|
|
struct drm_gpuva *
|
|
|
|
msm_gem_vma_new(struct drm_gpuvm *vm, struct drm_gem_object *obj,
|
2025-06-29 13:13:00 -07:00
|
|
|
u64 offset, u64 range_start, u64 range_end);
|
2025-06-29 13:13:20 -07:00
|
|
|
void msm_gem_vma_unmap(struct drm_gpuva *vma, const char *reason);
|
2025-06-29 13:13:00 -07:00
|
|
|
int msm_gem_vma_map(struct drm_gpuva *vma, int prot, struct sg_table *sgt);
|
2025-06-29 13:12:58 -07:00
|
|
|
void msm_gem_vma_close(struct drm_gpuva *vma);
|
2022-04-11 14:58:30 -07:00
|
|
|
|
drm/msm: basic KMS driver for snapdragon
The snapdragon chips have multiple different display controllers,
depending on which chip variant/version. (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.) And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.
To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.
The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently. But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge. This
would remove the 'msm_connector' base class. But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..
This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-06-26 12:44:06 -04:00
|
|
|
struct msm_gem_object {
|
|
|
|
struct drm_gem_object base;
|
|
|
|
|
|
|
|
uint32_t flags;
|
|
|
|
|
2016-05-17 15:44:49 -04:00
|
|
|
/**
|
2023-03-20 07:43:30 -07:00
|
|
|
* madv: are the backing pages purgeable?
|
|
|
|
*
|
|
|
|
* Protected by obj lock and LRU lock
|
2016-05-17 15:44:49 -04:00
|
|
|
*/
|
|
|
|
uint8_t madv;
|
|
|
|
|
2016-05-27 11:16:28 -04:00
|
|
|
/**
|
|
|
|
* count of active vmap'ing
|
|
|
|
*/
|
|
|
|
uint8_t vmap_count;
|
|
|
|
|
2021-03-31 18:27:20 -07:00
|
|
|
/**
|
|
|
|
* Node in list of all objects (mainly for debugfs, protected by
|
|
|
|
* priv->obj_lock
|
|
|
|
*/
|
|
|
|
struct list_head node;
|
|
|
|
|
drm/msm: basic KMS driver for snapdragon
The snapdragon chips have multiple different display controllers,
depending on which chip variant/version. (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.) And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.
To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.
The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently. But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge. This
would remove the 'msm_connector' base class. But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..
This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-06-26 12:44:06 -04:00
|
|
|
struct page **pages;
|
|
|
|
struct sg_table *sgt;
|
|
|
|
void *vaddr;
|
|
|
|
|
2018-11-07 15:35:52 -07:00
|
|
|
char name[32]; /* Identifier to print for the debugfs files */
|
2020-09-22 20:25:26 +05:30
|
|
|
|
2023-11-06 10:50:26 -08:00
|
|
|
/* userspace metadata backchannel */
|
|
|
|
void *metadata;
|
|
|
|
u32 metadata_size;
|
|
|
|
|
2023-03-20 07:43:30 -07:00
|
|
|
/**
|
|
|
|
* pin_count: Number of times the pages are pinned
|
|
|
|
*
|
|
|
|
* Protected by LRU lock.
|
|
|
|
*/
|
2021-04-05 10:45:29 -07:00
|
|
|
int pin_count;
|
2025-06-29 13:13:24 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @vma_ref: Reference count of VMA users.
|
|
|
|
*
|
|
|
|
* With the vm_bo/vma holding a reference to the GEM object, we'd
|
|
|
|
* otherwise have to actively tear down a VMA when, for example,
|
|
|
|
* a buffer is unpinned for scanout, vs. the pre-drm_gpuvm approach
|
|
|
|
* where a VMA did not hold a reference to the BO, but instead was
|
|
|
|
* implicitly torn down when the BO was freed.
|
|
|
|
*
|
|
|
|
* To regain the lazy VMA teardown, we use the @vma_ref. It is
|
|
|
|
* incremented for any of the following:
|
|
|
|
*
|
|
|
|
* 1) the BO is exported as a dma_buf
|
|
|
|
* 2) the BO has open userspace handle
|
|
|
|
*
|
|
|
|
* All of those conditions will hold an reference to the BO,
|
|
|
|
* preventing it from being freed. So lazily keeping around the
|
|
|
|
* VMA will not prevent the BO from being freed. (Or rather, the
|
|
|
|
* reference loop is harmless in this case.)
|
|
|
|
*
|
|
|
|
* When the @vma_ref drops to zero, then kms->vm VMA will be
|
|
|
|
* torn down.
|
|
|
|
*/
|
|
|
|
atomic_t vma_ref;
|
drm/msm: basic KMS driver for snapdragon
The snapdragon chips have multiple different display controllers,
depending on which chip variant/version. (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.) And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.
To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.
The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently. But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge. This
would remove the 'msm_connector' base class. But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..
This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-06-26 12:44:06 -04:00
|
|
|
};
|
|
|
|
#define to_msm_bo(x) container_of(x, struct msm_gem_object, base)
|
|
|
|
|
2025-06-29 13:13:24 -07:00
|
|
|
void msm_gem_vma_get(struct drm_gem_object *obj);
|
|
|
|
void msm_gem_vma_put(struct drm_gem_object *obj);
|
|
|
|
|
2020-10-23 09:51:05 -07:00
|
|
|
uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj);
|
2025-06-29 13:12:59 -07:00
|
|
|
int msm_gem_prot(struct drm_gem_object *obj);
|
2025-06-29 13:12:58 -07:00
|
|
|
int msm_gem_pin_vma_locked(struct drm_gem_object *obj, struct drm_gpuva *vma);
|
2022-05-27 10:23:40 -07:00
|
|
|
void msm_gem_unpin_locked(struct drm_gem_object *obj);
|
2023-03-20 07:43:31 -07:00
|
|
|
void msm_gem_unpin_active(struct drm_gem_object *obj);
|
2025-06-29 13:12:58 -07:00
|
|
|
struct drm_gpuva *msm_gem_get_vma_locked(struct drm_gem_object *obj,
|
|
|
|
struct drm_gpuvm *vm);
|
|
|
|
int msm_gem_get_iova(struct drm_gem_object *obj, struct drm_gpuvm *vm,
|
|
|
|
uint64_t *iova);
|
|
|
|
int msm_gem_set_iova(struct drm_gem_object *obj, struct drm_gpuvm *vm,
|
|
|
|
uint64_t iova);
|
2020-10-23 09:51:05 -07:00
|
|
|
int msm_gem_get_and_pin_iova_range(struct drm_gem_object *obj,
|
2025-06-29 13:12:58 -07:00
|
|
|
struct drm_gpuvm *vm, uint64_t *iova,
|
|
|
|
u64 range_start, u64 range_end);
|
|
|
|
int msm_gem_get_and_pin_iova(struct drm_gem_object *obj, struct drm_gpuvm *vm,
|
|
|
|
uint64_t *iova);
|
|
|
|
void msm_gem_unpin_iova(struct drm_gem_object *obj, struct drm_gpuvm *vm);
|
2023-08-02 15:21:51 -07:00
|
|
|
void msm_gem_pin_obj_locked(struct drm_gem_object *obj);
|
2025-06-29 13:13:18 -07:00
|
|
|
struct page **msm_gem_get_pages_locked(struct drm_gem_object *obj, unsigned madv);
|
2024-02-27 11:14:51 +01:00
|
|
|
struct page **msm_gem_pin_pages_locked(struct drm_gem_object *obj);
|
|
|
|
void msm_gem_unpin_pages_locked(struct drm_gem_object *obj);
|
2020-10-23 09:51:05 -07:00
|
|
|
int msm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
|
|
|
|
struct drm_mode_create_dumb *args);
|
|
|
|
int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
|
|
|
|
uint32_t handle, uint64_t *offset);
|
2020-10-23 09:51:06 -07:00
|
|
|
void *msm_gem_get_vaddr_locked(struct drm_gem_object *obj);
|
2020-10-23 09:51:05 -07:00
|
|
|
void *msm_gem_get_vaddr(struct drm_gem_object *obj);
|
|
|
|
void *msm_gem_get_vaddr_active(struct drm_gem_object *obj);
|
2020-10-23 09:51:06 -07:00
|
|
|
void msm_gem_put_vaddr_locked(struct drm_gem_object *obj);
|
2020-10-23 09:51:05 -07:00
|
|
|
void msm_gem_put_vaddr(struct drm_gem_object *obj);
|
|
|
|
int msm_gem_madvise(struct drm_gem_object *obj, unsigned madv);
|
2022-08-02 08:51:37 -07:00
|
|
|
bool msm_gem_active(struct drm_gem_object *obj);
|
2020-10-23 09:51:05 -07:00
|
|
|
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t *timeout);
|
|
|
|
int msm_gem_cpu_fini(struct drm_gem_object *obj);
|
|
|
|
int msm_gem_new_handle(struct drm_device *dev, struct drm_file *file,
|
|
|
|
uint32_t size, uint32_t flags, uint32_t *handle, char *name);
|
|
|
|
struct drm_gem_object *msm_gem_new(struct drm_device *dev,
|
|
|
|
uint32_t size, uint32_t flags);
|
2025-06-29 13:12:58 -07:00
|
|
|
void *msm_gem_kernel_new(struct drm_device *dev, uint32_t size, uint32_t flags,
|
|
|
|
struct drm_gpuvm *vm, struct drm_gem_object **bo,
|
|
|
|
uint64_t *iova);
|
|
|
|
void msm_gem_kernel_put(struct drm_gem_object *bo, struct drm_gpuvm *vm);
|
2020-10-23 09:51:05 -07:00
|
|
|
struct drm_gem_object *msm_gem_import(struct drm_device *dev,
|
|
|
|
struct dma_buf *dmabuf, struct sg_table *sgt);
|
|
|
|
__printf(2, 3)
|
|
|
|
void msm_gem_object_set_name(struct drm_gem_object *bo, const char *fmt, ...);
|
2021-03-31 18:27:21 -07:00
|
|
|
|
2021-04-05 10:45:28 -07:00
|
|
|
#ifdef CONFIG_DEBUG_FS
|
2021-03-31 18:27:21 -07:00
|
|
|
struct msm_gem_stats {
|
|
|
|
struct {
|
|
|
|
unsigned count;
|
|
|
|
size_t size;
|
2021-04-05 10:45:28 -07:00
|
|
|
} all, active, resident, purgeable, purged;
|
2021-03-31 18:27:21 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
void msm_gem_describe(struct drm_gem_object *obj, struct seq_file *m,
|
|
|
|
struct msm_gem_stats *stats);
|
2020-10-23 09:51:05 -07:00
|
|
|
void msm_gem_describe_objects(struct list_head *list, struct seq_file *m);
|
|
|
|
#endif
|
|
|
|
|
2020-10-23 09:51:03 -07:00
|
|
|
static inline void
|
|
|
|
msm_gem_lock(struct drm_gem_object *obj)
|
|
|
|
{
|
2020-10-23 09:51:10 -07:00
|
|
|
dma_resv_lock(obj->resv, NULL);
|
2020-10-23 09:51:03 -07:00
|
|
|
}
|
|
|
|
|
2025-06-29 13:13:22 -07:00
|
|
|
static inline bool __must_check
|
|
|
|
msm_gem_trylock(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
return dma_resv_trylock(obj->resv);
|
|
|
|
}
|
|
|
|
|
2020-10-23 09:51:03 -07:00
|
|
|
static inline int
|
|
|
|
msm_gem_lock_interruptible(struct drm_gem_object *obj)
|
|
|
|
{
|
2020-10-23 09:51:10 -07:00
|
|
|
return dma_resv_lock_interruptible(obj->resv, NULL);
|
2020-10-23 09:51:03 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
msm_gem_unlock(struct drm_gem_object *obj)
|
|
|
|
{
|
2020-10-23 09:51:10 -07:00
|
|
|
dma_resv_unlock(obj->resv);
|
2020-10-23 09:51:03 -07:00
|
|
|
}
|
|
|
|
|
2025-06-29 13:12:57 -07:00
|
|
|
/**
|
|
|
|
* msm_gem_lock_vm_and_obj() - Helper to lock an obj + VM
|
|
|
|
* @exec: the exec context helper which will be initalized
|
|
|
|
* @obj: the GEM object to lock
|
|
|
|
* @vm: the VM to lock
|
|
|
|
*
|
|
|
|
* Operations which modify a VM frequently need to lock both the VM and
|
|
|
|
* the object being mapped/unmapped/etc. This helper uses drm_exec to
|
|
|
|
* acquire both locks, dealing with potential deadlock/backoff scenarios
|
|
|
|
* which arise when multiple locks are involved.
|
|
|
|
*/
|
|
|
|
static inline int
|
|
|
|
msm_gem_lock_vm_and_obj(struct drm_exec *exec,
|
|
|
|
struct drm_gem_object *obj,
|
2025-06-29 13:12:58 -07:00
|
|
|
struct drm_gpuvm *vm)
|
2025-06-29 13:12:57 -07:00
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
drm_exec_init(exec, 0, 2);
|
|
|
|
drm_exec_until_all_locked (exec) {
|
2025-06-29 13:12:58 -07:00
|
|
|
ret = drm_exec_lock_obj(exec, drm_gpuvm_resv_obj(vm));
|
|
|
|
if (!ret && (obj->resv != drm_gpuvm_resv(vm)))
|
2025-06-29 13:12:57 -07:00
|
|
|
ret = drm_exec_lock_obj(exec, obj);
|
|
|
|
drm_exec_retry_on_contention(exec);
|
|
|
|
if (GEM_WARN_ON(ret))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-08-02 08:51:48 -07:00
|
|
|
static inline void
|
|
|
|
msm_gem_assert_locked(struct drm_gem_object *obj)
|
2020-10-23 09:51:03 -07:00
|
|
|
{
|
2022-06-13 13:50:32 -07:00
|
|
|
/*
|
|
|
|
* Destroying the object is a special case.. msm_gem_free_object()
|
|
|
|
* calls many things that WARN_ON if the obj lock is not held. But
|
|
|
|
* acquiring the obj lock in msm_gem_free_object() can cause a
|
|
|
|
* locking order inversion between reservation_ww_class_mutex and
|
|
|
|
* fs_reclaim.
|
|
|
|
*
|
|
|
|
* This deadlock is not actually possible, because no one should
|
|
|
|
* be already holding the lock when msm_gem_free_object() is called.
|
|
|
|
* Unfortunately lockdep is not aware of this detail. So when the
|
|
|
|
* refcount drops to zero, we pretend it is already locked.
|
|
|
|
*/
|
2022-08-02 08:51:48 -07:00
|
|
|
lockdep_assert_once(
|
|
|
|
(kref_read(&obj->refcount) == 0) ||
|
|
|
|
(lockdep_is_held(&obj->resv->lock.base) != LOCK_STATE_NOT_HELD)
|
|
|
|
);
|
2022-08-02 08:51:47 -07:00
|
|
|
}
|
|
|
|
|
2021-04-06 08:18:16 -07:00
|
|
|
/* imported/exported objects are not purgeable: */
|
|
|
|
static inline bool is_unpurgeable(struct msm_gem_object *msm_obj)
|
2021-03-31 18:27:19 -07:00
|
|
|
{
|
2025-03-17 14:06:44 +01:00
|
|
|
return drm_gem_is_imported(&msm_obj->base) || msm_obj->pin_count;
|
2021-03-31 18:27:19 -07:00
|
|
|
}
|
|
|
|
|
2016-05-17 16:19:32 -04:00
|
|
|
static inline bool is_purgeable(struct msm_gem_object *msm_obj)
|
|
|
|
{
|
|
|
|
return (msm_obj->madv == MSM_MADV_DONTNEED) && msm_obj->sgt &&
|
2021-04-06 08:18:16 -07:00
|
|
|
!is_unpurgeable(msm_obj);
|
2016-05-17 16:19:32 -04:00
|
|
|
}
|
|
|
|
|
2016-05-27 11:16:28 -04:00
|
|
|
static inline bool is_vunmapable(struct msm_gem_object *msm_obj)
|
|
|
|
{
|
2022-08-02 08:51:47 -07:00
|
|
|
msm_gem_assert_locked(&msm_obj->base);
|
2016-05-27 11:16:28 -04:00
|
|
|
return (msm_obj->vmap_count == 0) && msm_obj->vaddr;
|
|
|
|
}
|
|
|
|
|
2021-04-05 10:45:29 -07:00
|
|
|
static inline bool is_unevictable(struct msm_gem_object *msm_obj)
|
|
|
|
{
|
2021-04-26 16:53:25 -07:00
|
|
|
return is_unpurgeable(msm_obj) || msm_obj->vaddr;
|
2021-04-05 10:45:29 -07:00
|
|
|
}
|
|
|
|
|
2020-10-23 09:51:07 -07:00
|
|
|
void msm_gem_purge(struct drm_gem_object *obj);
|
2021-04-05 10:45:29 -07:00
|
|
|
void msm_gem_evict(struct drm_gem_object *obj);
|
2020-10-23 09:51:07 -07:00
|
|
|
void msm_gem_vunmap(struct drm_gem_object *obj);
|
2017-06-13 16:52:54 -06:00
|
|
|
|
2013-07-19 12:59:32 -04:00
|
|
|
/* Created per submit-ioctl, to track bo's and cmdstream bufs, etc,
|
|
|
|
* associated with the cmdstream submission for synchronization (and
|
2021-07-27 18:06:06 -07:00
|
|
|
* make it easier to unwind when things go wrong, etc).
|
2013-07-19 12:59:32 -04:00
|
|
|
*/
|
|
|
|
struct msm_gem_submit {
|
2021-07-27 18:06:14 -07:00
|
|
|
struct drm_sched_job base;
|
2020-10-23 09:51:17 -07:00
|
|
|
struct kref ref;
|
2013-07-19 12:59:32 -04:00
|
|
|
struct drm_device *dev;
|
|
|
|
struct msm_gpu *gpu;
|
2025-06-29 13:12:58 -07:00
|
|
|
struct drm_gpuvm *vm;
|
2017-10-20 11:06:57 -06:00
|
|
|
struct list_head node; /* node in ring submit list */
|
2023-11-20 16:38:51 -08:00
|
|
|
struct drm_exec exec;
|
2017-10-20 11:06:57 -06:00
|
|
|
uint32_t seqno; /* Sequence number of the submit on the ring */
|
2021-07-27 18:06:14 -07:00
|
|
|
|
|
|
|
/* Hw fence, which is created when the scheduler executes the job, and
|
|
|
|
* is signaled when the hw finishes (via seqno write from cmdstream)
|
|
|
|
*/
|
|
|
|
struct dma_fence *hw_fence;
|
|
|
|
|
|
|
|
/* Userspace visible fence, which is signaled by the scheduler after
|
|
|
|
* the hw_fence is signaled.
|
|
|
|
*/
|
|
|
|
struct dma_fence *user_fence;
|
|
|
|
|
2021-07-27 18:06:12 -07:00
|
|
|
int fence_id; /* key into queue->fence_idr */
|
2017-10-20 11:06:55 -06:00
|
|
|
struct msm_gpu_submitqueue *queue;
|
2016-05-03 10:10:15 -04:00
|
|
|
struct pid *pid; /* submitting process */
|
2023-11-20 16:38:48 -08:00
|
|
|
bool bos_pinned : 1;
|
|
|
|
bool fault_dumped:1;/* Limit devcoredump dumping to one per submit */
|
|
|
|
bool in_rb : 1; /* "sudo" mode, copy cmds into RB */
|
2017-10-20 11:06:57 -06:00
|
|
|
struct msm_ringbuffer *ring;
|
2013-07-19 12:59:32 -04:00
|
|
|
unsigned int nr_cmds;
|
|
|
|
unsigned int nr_bos;
|
2018-11-02 09:25:21 -06:00
|
|
|
u32 ident; /* A "identifier" for the submit for logging */
|
2013-07-19 12:59:32 -04:00
|
|
|
struct {
|
|
|
|
uint32_t type;
|
|
|
|
uint32_t size; /* in dwords */
|
2016-11-11 12:06:46 -05:00
|
|
|
uint64_t iova;
|
2020-10-23 09:51:08 -07:00
|
|
|
uint32_t offset;/* in dwords */
|
2014-05-30 14:47:38 -04:00
|
|
|
uint32_t idx; /* cmdstream buffer idx in bos[] */
|
2020-10-23 09:51:08 -07:00
|
|
|
uint32_t nr_relocs;
|
|
|
|
struct drm_msm_gem_submit_reloc *relocs;
|
2016-06-01 14:17:40 -04:00
|
|
|
} *cmd; /* array of size nr_cmds */
|
2013-07-19 12:59:32 -04:00
|
|
|
struct {
|
|
|
|
uint32_t flags;
|
2019-03-20 10:09:10 -07:00
|
|
|
union {
|
2023-08-02 15:21:50 -07:00
|
|
|
struct drm_gem_object *obj;
|
2019-03-20 10:09:10 -07:00
|
|
|
uint32_t handle;
|
|
|
|
};
|
2025-06-29 13:12:56 -07:00
|
|
|
struct drm_gpuvm_bo *vm_bo;
|
2016-11-11 12:06:46 -05:00
|
|
|
uint64_t iova;
|
2020-03-05 04:54:51 -06:00
|
|
|
} bos[];
|
2013-07-19 12:59:32 -04:00
|
|
|
};
|
|
|
|
|
2021-07-27 18:06:14 -07:00
|
|
|
static inline struct msm_gem_submit *to_msm_submit(struct drm_sched_job *job)
|
|
|
|
{
|
|
|
|
return container_of(job, struct msm_gem_submit, base);
|
|
|
|
}
|
|
|
|
|
2020-10-23 09:51:17 -07:00
|
|
|
void __msm_gem_submit_destroy(struct kref *kref);
|
|
|
|
|
|
|
|
static inline void msm_gem_submit_get(struct msm_gem_submit *submit)
|
|
|
|
{
|
|
|
|
kref_get(&submit->ref);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void msm_gem_submit_put(struct msm_gem_submit *submit)
|
|
|
|
{
|
|
|
|
kref_put(&submit->ref, __msm_gem_submit_destroy);
|
|
|
|
}
|
|
|
|
|
2021-07-27 18:06:11 -07:00
|
|
|
void msm_submit_retire(struct msm_gem_submit *submit);
|
|
|
|
|
drm/msm: basic KMS driver for snapdragon
The snapdragon chips have multiple different display controllers,
depending on which chip variant/version. (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.) And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.
To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.
The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently. But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge. This
would remove the 'msm_connector' base class. But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..
This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-06-26 12:44:06 -04:00
|
|
|
#endif /* __MSM_GEM_H__ */
|