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
|
|
|
/*
|
2018-06-27 15:26:09 -04:00
|
|
|
* Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
|
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_DRV_H__
|
|
|
|
#define __MSM_DRV_H__
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/clk.h>
|
|
|
|
#include <linux/cpufreq.h>
|
2023-01-10 15:14:42 -08:00
|
|
|
#include <linux/devfreq.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 <linux/module.h>
|
2014-03-03 14:19:12 -05:00
|
|
|
#include <linux/component.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 <linux/platform_device.h>
|
|
|
|
#include <linux/pm.h>
|
|
|
|
#include <linux/pm_runtime.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/iommu.h>
|
|
|
|
#include <linux/types.h>
|
2015-06-09 14:17:22 +05:30
|
|
|
#include <linux/of_graph.h>
|
2015-11-18 12:15:14 +05:30
|
|
|
#include <linux/of_device.h>
|
2019-05-14 15:46:51 -07:00
|
|
|
#include <linux/sizes.h>
|
2018-06-27 15:26:09 -04:00
|
|
|
#include <linux/kthread.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
|
|
|
|
2014-11-08 13:21:06 -05:00
|
|
|
#include <drm/drm_atomic.h>
|
|
|
|
#include <drm/drm_atomic_helper.h>
|
2024-12-30 08:00:33 -08:00
|
|
|
#include <drm/drm_print.h>
|
2019-01-17 22:03:34 +01:00
|
|
|
#include <drm/drm_probe_helper.h>
|
2022-05-11 12:40:47 +10:00
|
|
|
#include <drm/display/drm_dsc.h>
|
2013-07-19 12:59:32 -04:00
|
|
|
#include <drm/msm_drm.h>
|
2014-09-23 15:46:53 +02:00
|
|
|
#include <drm/drm_gem.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
|
|
|
|
2022-08-07 10:28:48 -07:00
|
|
|
extern struct fault_attr fail_gem_alloc;
|
|
|
|
extern struct fault_attr fail_gem_iova;
|
|
|
|
|
2024-09-24 09:13:14 +02:00
|
|
|
struct drm_fb_helper;
|
|
|
|
struct drm_fb_helper_surface_size;
|
|
|
|
|
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_kms;
|
2013-07-19 12:59:32 -04:00
|
|
|
struct msm_gpu;
|
2013-11-16 12:56:06 -05:00
|
|
|
struct msm_mmu;
|
2016-05-07 23:11:25 +05:30
|
|
|
struct msm_mdss;
|
2014-05-30 14:47:38 -04:00
|
|
|
struct msm_rd_state;
|
2014-05-30 14:49:43 -04:00
|
|
|
struct msm_perf_state;
|
2014-05-30 14:47:38 -04:00
|
|
|
struct msm_gem_submit;
|
2016-03-15 17:22:13 -04:00
|
|
|
struct msm_fence_context;
|
2021-05-28 01:03:30 +03:00
|
|
|
struct msm_disp_state;
|
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
|
|
|
|
2018-06-27 14:55:25 -04:00
|
|
|
#define MAX_CRTCS 8
|
|
|
|
|
2018-08-29 13:49:47 -04:00
|
|
|
#define FRAC_16_16(mult, div) (((mult) << 16) / (div))
|
|
|
|
|
2021-10-16 15:18:41 -07:00
|
|
|
enum msm_dp_controller {
|
|
|
|
MSM_DP_CONTROLLER_0,
|
|
|
|
MSM_DP_CONTROLLER_1,
|
|
|
|
MSM_DP_CONTROLLER_2,
|
2022-12-07 14:00:02 -08:00
|
|
|
MSM_DP_CONTROLLER_3,
|
2021-10-16 15:18:41 -07:00
|
|
|
MSM_DP_CONTROLLER_COUNT,
|
|
|
|
};
|
|
|
|
|
2023-07-04 05:21:18 +03:00
|
|
|
enum msm_dsi_controller {
|
|
|
|
MSM_DSI_CONTROLLER_0,
|
|
|
|
MSM_DSI_CONTROLLER_1,
|
|
|
|
MSM_DSI_CONTROLLER_COUNT,
|
|
|
|
};
|
|
|
|
|
2017-10-20 11:07:01 -06:00
|
|
|
#define MSM_GPU_MAX_RINGS 4
|
2018-06-27 15:26:09 -04: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_drm_private {
|
|
|
|
|
2016-05-17 16:19:32 -04:00
|
|
|
struct drm_device *dev;
|
|
|
|
|
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_kms *kms;
|
2022-04-19 18:53:44 +03:00
|
|
|
int (*kms_init)(struct drm_device *dev);
|
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
|
|
|
|
2014-03-03 14:19:12 -05:00
|
|
|
/* subordinate devices, if present: */
|
2014-11-04 13:33:14 -05:00
|
|
|
struct platform_device *gpu_pdev;
|
|
|
|
|
2013-07-19 12:59:32 -04:00
|
|
|
/* when we have more than one 'msm_gpu' these need to be an array: */
|
|
|
|
struct msm_gpu *gpu;
|
2021-11-09 10:11:02 -08:00
|
|
|
|
2018-11-14 17:08:04 -05:00
|
|
|
/* gpu is only set on open(), but we need this info earlier */
|
|
|
|
bool is_a2xx;
|
2021-04-23 15:08:20 -04:00
|
|
|
bool has_cached_coherent;
|
2013-07-19 12:59:32 -04:00
|
|
|
|
2017-09-15 09:04:52 -04:00
|
|
|
struct msm_rd_state *rd; /* debugfs to dump all submits */
|
|
|
|
struct msm_rd_state *hangrd; /* debugfs to dump hanging submits */
|
2014-05-30 14:49:43 -04:00
|
|
|
struct msm_perf_state *perf;
|
2014-05-30 14:47:38 -04:00
|
|
|
|
2024-03-01 10:53:45 -08:00
|
|
|
/**
|
|
|
|
* total_mem: Total/global amount of memory backing GEM objects.
|
|
|
|
*/
|
|
|
|
atomic64_t total_mem;
|
|
|
|
|
2021-03-31 18:27:20 -07:00
|
|
|
/**
|
|
|
|
* List of all GEM objects (mainly for debugfs, protected by obj_lock
|
|
|
|
* (acquire before per GEM object lock)
|
|
|
|
*/
|
|
|
|
struct list_head objects;
|
|
|
|
struct mutex obj_lock;
|
|
|
|
|
|
|
|
/**
|
2022-08-02 08:51:43 -07:00
|
|
|
* lru:
|
2020-10-23 09:51:14 -07:00
|
|
|
*
|
2022-08-02 08:51:43 -07:00
|
|
|
* The various LRU's that a GEM object is in at various stages of
|
|
|
|
* it's lifetime. Objects start out in the unbacked LRU. When
|
|
|
|
* pinned (for scannout or permanently mapped GPU buffers, like
|
|
|
|
* ringbuffer, memptr, fw, etc) it moves to the pinned LRU. When
|
|
|
|
* unpinned, it moves into willneed or dontneed LRU depending on
|
|
|
|
* madvise state. When backing pages are evicted (willneed) or
|
|
|
|
* purged (dontneed) it moves back into the unbacked LRU.
|
2021-04-05 10:45:29 -07:00
|
|
|
*
|
2022-08-02 08:51:43 -07:00
|
|
|
* The dontneed LRU is considered by the shrinker for objects
|
|
|
|
* that are candidate for purging, and the willneed LRU is
|
|
|
|
* considered for objects that could be evicted.
|
2020-10-23 09:51:14 -07:00
|
|
|
*/
|
2022-08-02 08:51:43 -07:00
|
|
|
struct {
|
|
|
|
/**
|
|
|
|
* unbacked:
|
|
|
|
*
|
|
|
|
* The LRU for GEM objects without backing pages allocated.
|
|
|
|
* This mostly exists so that objects are always is one
|
|
|
|
* LRU.
|
|
|
|
*/
|
|
|
|
struct drm_gem_lru unbacked;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pinned:
|
|
|
|
*
|
|
|
|
* The LRU for pinned GEM objects
|
|
|
|
*/
|
|
|
|
struct drm_gem_lru pinned;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* willneed:
|
|
|
|
*
|
|
|
|
* The LRU for unpinned GEM objects which are in madvise
|
|
|
|
* WILLNEED state (ie. can be evicted)
|
|
|
|
*/
|
|
|
|
struct drm_gem_lru willneed;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* dontneed:
|
|
|
|
*
|
|
|
|
* The LRU for unpinned GEM objects which are in madvise
|
|
|
|
* DONTNEED state (ie. can be purged)
|
|
|
|
*/
|
|
|
|
struct drm_gem_lru dontneed;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* lock:
|
|
|
|
*
|
|
|
|
* Protects manipulation of all of the LRUs.
|
|
|
|
*/
|
|
|
|
struct mutex lock;
|
|
|
|
} lru;
|
2019-03-20 10:09:08 -07:00
|
|
|
|
2016-05-27 11:16:28 -04:00
|
|
|
struct notifier_block vmap_notifier;
|
2023-09-11 17:44:20 +08:00
|
|
|
struct shrinker *shrinker;
|
2016-05-17 16:19:32 -04:00
|
|
|
|
2022-11-14 11:30:41 -08:00
|
|
|
/**
|
|
|
|
* hangcheck_period: For hang detection, in ms
|
|
|
|
*
|
|
|
|
* Note that in practice, a submit/job will get at least two hangcheck
|
|
|
|
* periods, due to checking for progress being implemented as simply
|
|
|
|
* "have the CP position registers changed since last time?"
|
|
|
|
*/
|
2021-06-07 12:44:41 +02:00
|
|
|
unsigned int hangcheck_period;
|
2021-11-09 10:11:05 -08:00
|
|
|
|
2023-01-10 15:14:42 -08:00
|
|
|
/** gpu_devfreq_config: Devfreq tuning config for the GPU. */
|
|
|
|
struct devfreq_simple_ondemand_data gpu_devfreq_config;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gpu_clamp_to_idle: Enable clamping to idle freq when inactive
|
|
|
|
*/
|
|
|
|
bool gpu_clamp_to_idle;
|
|
|
|
|
2021-11-09 10:11:05 -08:00
|
|
|
/**
|
|
|
|
* disable_err_irq:
|
|
|
|
*
|
|
|
|
* Disable handling of GPU hw error interrupts, to force fallback to
|
|
|
|
* sw hangcheck timer. Written (via debugfs) by igt tests to test
|
|
|
|
* the sw hangcheck mechanism.
|
|
|
|
*/
|
|
|
|
bool disable_err_irq;
|
drm/msm: Temporarily disable stall-on-fault after a page fault
When things go wrong, the GPU is capable of quickly generating millions
of faulting translation requests per second. When that happens, in the
stall-on-fault model each access will stall until it wins the race to
signal the fault and then the RESUME register is written. This slows
processing page faults to a crawl as the GPU can generate faults much
faster than the CPU can acknowledge them. It also means that all
available resources in the SMMU are saturated waiting for the stalled
transactions, so that other transactions such as transactions generated
by the GMU, which shares translation resources with the GPU, cannot
proceed. This causes a GMU watchdog timeout, which leads to a failed
reset because GX cannot collapse when there is a transaction pending and
a permanently hung GPU.
On older platforms with qcom,smmu-v2, it seems that when one transaction
is stalled subsequent faulting transactions are terminated, which avoids
this problem, but the MMU-500 follows the spec here.
To work around these problems, disable stall-on-fault as soon as we get a
page fault until a cooldown period after pagefaults stop. This allows
the GMU some guaranteed time to continue working. We only use
stall-on-fault to halt the GPU while we collect a devcoredump and we
always terminate the transaction afterward, so it's fine to miss some
subsequent page faults. We also keep it disabled so long as the current
devcoredump hasn't been deleted, because in that case we likely won't
capture another one if there's a fault.
After this commit HFI messages still occasionally time out, because the
crashdump handler doesn't run fast enough to let the GMU resume, but the
driver seems to recover from it. This will probably go away after the
HFI timeout is increased.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/654891/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-05-20 15:08:59 -04:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @fault_stall_lock:
|
|
|
|
*
|
|
|
|
* Serialize changes to stall-on-fault state.
|
|
|
|
*/
|
|
|
|
spinlock_t fault_stall_lock;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @fault_stall_reenable_time:
|
|
|
|
*
|
|
|
|
* If stall_enabled is false, when to reenable stall-on-fault.
|
|
|
|
* Protected by @fault_stall_lock.
|
|
|
|
*/
|
|
|
|
ktime_t stall_reenable_time;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @stall_enabled:
|
|
|
|
*
|
|
|
|
* Whether stall-on-fault is currently enabled. Protected by
|
|
|
|
* @fault_stall_lock.
|
|
|
|
*/
|
|
|
|
bool stall_enabled;
|
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
|
|
|
};
|
|
|
|
|
2024-04-20 07:01:05 +03:00
|
|
|
const struct msm_format *mdp_get_format(struct msm_kms *kms, uint32_t format, uint64_t modifier);
|
|
|
|
|
2019-08-29 09:45:16 -07:00
|
|
|
struct msm_pending_timer;
|
|
|
|
|
2020-10-19 14:10:53 -07:00
|
|
|
int msm_atomic_init_pending_timer(struct msm_pending_timer *timer,
|
2019-08-29 09:45:16 -07:00
|
|
|
struct msm_kms *kms, int crtc_idx);
|
2020-10-19 14:10:53 -07:00
|
|
|
void msm_atomic_destroy_pending_timer(struct msm_pending_timer *timer);
|
2018-02-28 14:19:05 -05:00
|
|
|
void msm_atomic_commit_tail(struct drm_atomic_state *state);
|
2023-02-13 03:11:44 -08:00
|
|
|
int msm_atomic_check(struct drm_device *dev, struct drm_atomic_state *state);
|
2016-11-04 13:51:42 -04:00
|
|
|
struct drm_atomic_state *msm_atomic_state_alloc(struct drm_device *dev);
|
2014-11-08 13:21:06 -05:00
|
|
|
|
2020-01-23 14:59:34 +01:00
|
|
|
int msm_crtc_enable_vblank(struct drm_crtc *crtc);
|
|
|
|
void msm_crtc_disable_vblank(struct drm_crtc *crtc);
|
|
|
|
|
2018-06-27 15:26:09 -04:00
|
|
|
int msm_register_mmu(struct drm_device *dev, struct msm_mmu *mmu);
|
|
|
|
void msm_unregister_mmu(struct drm_device *dev, struct msm_mmu *mmu);
|
|
|
|
|
2025-06-29 13:12:58 -07:00
|
|
|
struct drm_gpuvm *msm_kms_init_vm(struct drm_device *dev);
|
2018-11-14 17:08:04 -05:00
|
|
|
bool msm_use_mmu(struct drm_device *dev);
|
|
|
|
|
2013-07-19 12:59:32 -04:00
|
|
|
int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
|
2025-06-29 13:13:18 -07:00
|
|
|
struct drm_file *file);
|
|
|
|
int msm_ioctl_vm_bind(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file);
|
2013-07-19 12:59:32 -04:00
|
|
|
|
2021-06-14 08:06:18 -07:00
|
|
|
#ifdef CONFIG_DEBUG_FS
|
|
|
|
unsigned long msm_gem_shrinker_shrink(struct drm_device *dev, unsigned long nr_to_scan);
|
|
|
|
#endif
|
|
|
|
|
2023-09-11 17:44:20 +08:00
|
|
|
int msm_gem_shrinker_init(struct drm_device *dev);
|
2016-05-17 16:19:32 -04:00
|
|
|
void msm_gem_shrinker_cleanup(struct drm_device *dev);
|
|
|
|
|
2013-09-28 11:28:35 -04:00
|
|
|
struct sg_table *msm_gem_prime_get_sg_table(struct drm_gem_object *obj);
|
2022-02-04 09:05:41 -08:00
|
|
|
int msm_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map);
|
|
|
|
void msm_gem_prime_vunmap(struct drm_gem_object *obj, struct iosys_map *map);
|
2025-06-29 13:13:24 -07:00
|
|
|
struct drm_gem_object *msm_gem_prime_import(struct drm_device *dev, struct dma_buf *buf);
|
2013-09-28 11:28:35 -04:00
|
|
|
struct drm_gem_object *msm_gem_prime_import_sg_table(struct drm_device *dev,
|
2014-01-09 11:03:14 +01:00
|
|
|
struct dma_buf_attachment *attach, struct sg_table *sg);
|
2025-06-29 13:13:07 -07:00
|
|
|
struct dma_buf *msm_gem_prime_export(struct drm_gem_object *obj, int flags);
|
2013-09-28 11:28:35 -04:00
|
|
|
int msm_gem_prime_pin(struct drm_gem_object *obj);
|
|
|
|
void msm_gem_prime_unpin(struct drm_gem_object *obj);
|
2018-11-07 15:35:52 -07:00
|
|
|
|
2025-06-29 13:12:54 -07:00
|
|
|
int msm_framebuffer_prepare(struct drm_framebuffer *fb, bool needs_dirtyfb);
|
|
|
|
void msm_framebuffer_cleanup(struct drm_framebuffer *fb, bool needed_dirtyfb);
|
|
|
|
uint32_t msm_framebuffer_iova(struct drm_framebuffer *fb, int plane);
|
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 drm_gem_object *msm_framebuffer_bo(struct drm_framebuffer *fb, int plane);
|
|
|
|
const struct msm_format *msm_framebuffer_format(struct drm_framebuffer *fb);
|
|
|
|
struct drm_framebuffer *msm_framebuffer_create(struct drm_device *dev,
|
drm: Pass the format info to .fb_create()
Pass along the format information from the top to .fb_create()
so that we can avoid redundant (and somewhat expensive) lookups
in the drivers.
Done with cocci (with some manual fixups):
@@
identifier func =~ ".*create.*";
identifier dev, file, mode_cmd;
@@
struct drm_framebuffer *func(
struct drm_device *dev,
struct drm_file *file,
+ const struct drm_format_info *info,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
...
(
- const struct drm_format_info *info = drm_get_format_info(...);
|
- const struct drm_format_info *info;
...
- info = drm_get_format_info(...);
)
<...
- if (!info)
- return ...;
...>
}
@@
identifier func =~ ".*create.*";
identifier dev, file, mode_cmd;
@@
struct drm_framebuffer *func(
struct drm_device *dev,
struct drm_file *file,
+ const struct drm_format_info *info,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
...
}
@find@
identifier fb_create_func =~ ".*create.*";
identifier dev, file, mode_cmd;
@@
struct drm_framebuffer *fb_create_func(
struct drm_device *dev,
struct drm_file *file,
+ const struct drm_format_info *info,
const struct drm_mode_fb_cmd2 *mode_cmd);
@@
identifier find.fb_create_func;
expression dev, file, mode_cmd;
@@
fb_create_func(dev, file
+ ,info
,mode_cmd)
@@
expression dev, file, mode_cmd;
@@
drm_gem_fb_create(dev, file
+ ,info
,mode_cmd)
@@
expression dev, file, mode_cmd;
@@
drm_gem_fb_create_with_dirty(dev, file
+ ,info
,mode_cmd)
@@
expression dev, file_priv, mode_cmd;
identifier info, fb;
@@
info = drm_get_format_info(...);
...
fb = dev->mode_config.funcs->fb_create(dev, file_priv
+ ,info
,mode_cmd);
@@
identifier dev, file_priv, mode_cmd;
@@
struct drm_mode_config_funcs {
...
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
struct drm_file *file_priv,
+ const struct drm_format_info *info,
const struct drm_mode_fb_cmd2 *mode_cmd);
...
};
v2: Fix kernel docs (Laurent)
Fix commit msg (Geert)
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
Cc: Dmitry Baryshkov <lumag@kernel.org>
Cc: Sean Paul <sean@poorly.run>
Cc: Marijn Suijten <marijn.suijten@somainline.org>
Cc: Marek Vasut <marex@denx.de>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Biju Das <biju.das.jz@bp.renesas.com>
Cc: Sandy Huang <hjc@rock-chips.com>
Cc: "Heiko Stübner" <heiko@sntech.de>
Cc: Andy Yan <andy.yan@rock-chips.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Mikko Perttunen <mperttunen@nvidia.com>
Cc: Dave Stevenson <dave.stevenson@raspberrypi.com>
Cc: "Maíra Canal" <mcanal@igalia.com>
Cc: Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Cc: Gurchetan Singh <gurchetansingh@chromium.org>
Cc: Chia-I Wu <olvaffe@gmail.com>
Cc: Zack Rusin <zack.rusin@broadcom.com>
Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: virtualization@lists.linux.dev
Cc: spice-devel@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250701090722.13645-5-ville.syrjala@linux.intel.com
2025-07-01 12:07:07 +03:00
|
|
|
struct drm_file *file, const struct drm_format_info *info,
|
|
|
|
const struct drm_mode_fb_cmd2 *mode_cmd);
|
2017-07-11 10:40:13 -04:00
|
|
|
struct drm_framebuffer * msm_alloc_stolen_fb(struct drm_device *dev,
|
|
|
|
int w, int h, int p, uint32_t format);
|
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
|
|
|
|
2025-07-05 13:02:31 +03:00
|
|
|
#ifdef CONFIG_DRM_MSM_KMS_FBDEV
|
2024-09-24 09:13:14 +02:00
|
|
|
int msm_fbdev_driver_fbdev_probe(struct drm_fb_helper *helper,
|
|
|
|
struct drm_fb_helper_surface_size *sizes);
|
|
|
|
#define MSM_FBDEV_DRIVER_OPS \
|
|
|
|
.fbdev_probe = msm_fbdev_driver_fbdev_probe
|
2023-04-03 14:45:38 +02:00
|
|
|
#else
|
2024-09-24 09:13:14 +02:00
|
|
|
#define MSM_FBDEV_DRIVER_OPS \
|
|
|
|
.fbdev_probe = NULL
|
2023-04-03 14:45:38 +02:00
|
|
|
#endif
|
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
|
|
|
|
2013-12-01 12:12:54 -05:00
|
|
|
struct hdmi;
|
2022-04-19 18:53:45 +03:00
|
|
|
#ifdef CONFIG_DRM_MSM_HDMI
|
2016-02-22 22:08:35 +01:00
|
|
|
int msm_hdmi_modeset_init(struct hdmi *hdmi, struct drm_device *dev,
|
2014-11-04 13:33:14 -05:00
|
|
|
struct drm_encoder *encoder);
|
2016-02-22 22:08:35 +01:00
|
|
|
void __init msm_hdmi_register(void);
|
|
|
|
void __exit msm_hdmi_unregister(void);
|
2022-04-19 18:53:45 +03:00
|
|
|
#else
|
|
|
|
static inline int msm_hdmi_modeset_init(struct hdmi *hdmi, struct drm_device *dev,
|
|
|
|
struct drm_encoder *encoder)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
static inline void __init msm_hdmi_register(void) {}
|
|
|
|
static inline void __exit msm_hdmi_unregister(void) {}
|
|
|
|
#endif
|
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
|
|
|
|
2015-03-31 14:36:33 -04:00
|
|
|
struct msm_dsi;
|
|
|
|
#ifdef CONFIG_DRM_MSM_DSI
|
2021-10-25 17:15:36 +02:00
|
|
|
int dsi_dev_attach(struct platform_device *pdev);
|
|
|
|
void dsi_dev_detach(struct platform_device *pdev);
|
2015-03-31 14:36:33 -04:00
|
|
|
void __init msm_dsi_register(void);
|
|
|
|
void __exit msm_dsi_unregister(void);
|
|
|
|
int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct drm_device *dev,
|
2017-01-16 09:42:03 +05:30
|
|
|
struct drm_encoder *encoder);
|
2021-05-28 01:03:30 +03:00
|
|
|
void msm_dsi_snapshot(struct msm_disp_state *disp_state, struct msm_dsi *msm_dsi);
|
2021-07-17 15:40:11 +03:00
|
|
|
bool msm_dsi_is_cmd_mode(struct msm_dsi *msm_dsi);
|
|
|
|
bool msm_dsi_is_bonded_dsi(struct msm_dsi *msm_dsi);
|
|
|
|
bool msm_dsi_is_master_dsi(struct msm_dsi *msm_dsi);
|
2023-08-22 10:42:05 -07:00
|
|
|
bool msm_dsi_wide_bus_enabled(struct msm_dsi *msm_dsi);
|
2022-07-11 13:04:32 +03:00
|
|
|
struct drm_dsc_config *msm_dsi_get_dsc_config(struct msm_dsi *msm_dsi);
|
2024-06-13 20:05:09 +03:00
|
|
|
const char *msm_dsi_get_te_source(struct msm_dsi *msm_dsi);
|
2015-03-31 14:36:33 -04:00
|
|
|
#else
|
|
|
|
static inline void __init msm_dsi_register(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
static inline void __exit msm_dsi_unregister(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
static inline int msm_dsi_modeset_init(struct msm_dsi *msm_dsi,
|
2017-01-16 09:42:03 +05:30
|
|
|
struct drm_device *dev,
|
|
|
|
struct drm_encoder *encoder)
|
2015-03-31 14:36:33 -04:00
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2021-05-28 01:03:30 +03:00
|
|
|
static inline void msm_dsi_snapshot(struct msm_disp_state *disp_state, struct msm_dsi *msm_dsi)
|
|
|
|
{
|
|
|
|
}
|
2021-07-17 15:40:11 +03:00
|
|
|
static inline bool msm_dsi_is_cmd_mode(struct msm_dsi *msm_dsi)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
static inline bool msm_dsi_is_bonded_dsi(struct msm_dsi *msm_dsi)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
static inline bool msm_dsi_is_master_dsi(struct msm_dsi *msm_dsi)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
2023-08-22 10:42:05 -07:00
|
|
|
static inline bool msm_dsi_wide_bus_enabled(struct msm_dsi *msm_dsi)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
2022-04-06 15:10:19 +05:30
|
|
|
|
2022-07-11 13:04:32 +03:00
|
|
|
static inline struct drm_dsc_config *msm_dsi_get_dsc_config(struct msm_dsi *msm_dsi)
|
2022-04-06 15:10:19 +05:30
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
2024-06-13 20:05:09 +03:00
|
|
|
|
|
|
|
static inline const char *msm_dsi_get_te_source(struct msm_dsi *msm_dsi)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
2015-03-31 14:36:33 -04:00
|
|
|
#endif
|
|
|
|
|
2025-07-05 13:02:30 +03:00
|
|
|
struct msm_dp;
|
2020-08-27 14:16:55 -07:00
|
|
|
#ifdef CONFIG_DRM_MSM_DP
|
|
|
|
int __init msm_dp_register(void);
|
|
|
|
void __exit msm_dp_unregister(void);
|
|
|
|
int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
|
2024-02-22 11:40:04 -08:00
|
|
|
struct drm_encoder *encoder, bool yuv_supported);
|
2021-04-27 03:18:25 +03:00
|
|
|
void msm_dp_snapshot(struct msm_disp_state *disp_state, struct msm_dp *dp_display);
|
2024-02-22 11:40:01 -08:00
|
|
|
bool msm_dp_is_yuv_420_enabled(const struct msm_dp *dp_display,
|
|
|
|
const struct drm_display_mode *mode);
|
|
|
|
bool msm_dp_needs_periph_flush(const struct msm_dp *dp_display,
|
|
|
|
const struct drm_display_mode *mode);
|
2022-02-25 13:23:12 -08:00
|
|
|
bool msm_dp_wide_bus_available(const struct msm_dp *dp_display);
|
2020-09-12 14:08:13 -07:00
|
|
|
|
2020-08-27 14:16:55 -07:00
|
|
|
#else
|
|
|
|
static inline int __init msm_dp_register(void)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
static inline void __exit msm_dp_unregister(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
static inline int msm_dp_modeset_init(struct msm_dp *dp_display,
|
|
|
|
struct drm_device *dev,
|
2024-02-22 11:40:04 -08:00
|
|
|
struct drm_encoder *encoder,
|
|
|
|
bool yuv_supported)
|
2020-08-27 14:16:55 -07:00
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2020-08-27 14:16:58 -07:00
|
|
|
|
2021-05-28 01:03:30 +03:00
|
|
|
static inline void msm_dp_snapshot(struct msm_disp_state *disp_state, struct msm_dp *dp_display)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2024-02-22 11:40:01 -08:00
|
|
|
static inline bool msm_dp_is_yuv_420_enabled(const struct msm_dp *dp_display,
|
|
|
|
const struct drm_display_mode *mode)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool msm_dp_needs_periph_flush(const struct msm_dp *dp_display,
|
|
|
|
const struct drm_display_mode *mode)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2022-02-25 13:23:12 -08:00
|
|
|
static inline bool msm_dp_wide_bus_available(const struct msm_dp *dp_display)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2020-08-27 14:16:55 -07:00
|
|
|
#endif
|
|
|
|
|
2022-04-19 18:53:45 +03:00
|
|
|
#ifdef CONFIG_DRM_MSM_MDP4
|
2022-04-19 18:53:43 +03:00
|
|
|
void msm_mdp4_register(void);
|
|
|
|
void msm_mdp4_unregister(void);
|
2022-04-19 18:53:45 +03:00
|
|
|
#else
|
|
|
|
static inline void msm_mdp4_register(void) {}
|
|
|
|
static inline void msm_mdp4_unregister(void) {}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_DRM_MSM_MDP5
|
2022-04-19 18:53:43 +03:00
|
|
|
void msm_mdp_register(void);
|
|
|
|
void msm_mdp_unregister(void);
|
2022-04-19 18:53:45 +03:00
|
|
|
#else
|
|
|
|
static inline void msm_mdp_register(void) {}
|
|
|
|
static inline void msm_mdp_unregister(void) {}
|
2020-08-27 14:16:55 -07:00
|
|
|
#endif
|
|
|
|
|
2022-04-19 18:53:45 +03:00
|
|
|
#ifdef CONFIG_DRM_MSM_DPU
|
2022-04-19 18:53:43 +03:00
|
|
|
void msm_dpu_register(void);
|
|
|
|
void msm_dpu_unregister(void);
|
2022-04-19 18:53:45 +03:00
|
|
|
#else
|
|
|
|
static inline void msm_dpu_register(void) {}
|
|
|
|
static inline void msm_dpu_unregister(void) {}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_DRM_MSM_MDSS
|
2022-04-19 18:53:43 +03:00
|
|
|
void msm_mdss_register(void);
|
|
|
|
void msm_mdss_unregister(void);
|
2022-04-19 18:53:45 +03:00
|
|
|
#else
|
|
|
|
static inline void msm_mdss_register(void) {}
|
|
|
|
static inline void msm_mdss_unregister(void) {}
|
|
|
|
#endif
|
drm/msm/mdp5: Create a separate MDP5 device
In order to have a tree-like device hierarchy between MDSS and its
sub-blocks (MDP5, DSI, HDMI, eDP etc), we need to create a separate
device/driver for MDP5. Currently, MDP5 and MDSS are squashed
together are are tied to the top level platform_device, which is
also the one used to create drm_device.
The mdp5_kms_init code is split into two parts. The part where device
resources are allocated are associated with the MDP5 driver's probe,
the rest is executed later when we initialize modeset.
With this change, unlike MDP4, the MDP5 platform_device isn't tied to
the top level drm_device anymore. The top level drm_device is now
associated with a platform device that corresponds to MDSS wrapper
hardware.
Create mdp5_init/destroy funcs that will be used by the MDP5 driver
probe/remove. Use the HW_VERSION register in the MDP5 register address
space. Both the MDSS and MDP VERSION registers give out identical
version info.
The older mdp5_kms_init code is left as is for now, this would be removed
later when we have all the pieces to support the new device hierarchy.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-05-30 16:36:50 +05:30
|
|
|
|
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
|
|
|
#ifdef CONFIG_DEBUG_FS
|
|
|
|
void msm_framebuffer_describe(struct drm_framebuffer *fb, struct seq_file *m);
|
2014-05-30 14:47:38 -04:00
|
|
|
int msm_debugfs_late_init(struct drm_device *dev);
|
|
|
|
int msm_rd_debugfs_init(struct drm_minor *minor);
|
2017-03-07 21:49:22 +01:00
|
|
|
void msm_rd_debugfs_cleanup(struct msm_drm_private *priv);
|
2019-01-17 14:17:36 -08:00
|
|
|
__printf(3, 4)
|
2017-09-15 10:46:45 -04:00
|
|
|
void msm_rd_dump_submit(struct msm_rd_state *rd, struct msm_gem_submit *submit,
|
|
|
|
const char *fmt, ...);
|
2014-05-30 14:49:43 -04:00
|
|
|
int msm_perf_debugfs_init(struct drm_minor *minor);
|
2017-03-07 21:49:22 +01:00
|
|
|
void msm_perf_debugfs_cleanup(struct msm_drm_private *priv);
|
2014-05-30 14:47:38 -04:00
|
|
|
#else
|
|
|
|
static inline int msm_debugfs_late_init(struct drm_device *dev) { return 0; }
|
2019-01-17 14:17:36 -08:00
|
|
|
__printf(3, 4)
|
2020-08-27 14:16:55 -07:00
|
|
|
static inline void msm_rd_dump_submit(struct msm_rd_state *rd,
|
|
|
|
struct msm_gem_submit *submit,
|
|
|
|
const char *fmt, ...) {}
|
2017-03-20 10:39:25 +01:00
|
|
|
static inline void msm_rd_debugfs_cleanup(struct msm_drm_private *priv) {}
|
|
|
|
static inline void msm_perf_debugfs_cleanup(struct msm_drm_private *priv) {}
|
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
|
|
|
|
|
2017-01-30 11:30:58 -05:00
|
|
|
struct clk *msm_clk_get(struct platform_device *pdev, const char *name);
|
2018-08-06 11:33:21 -06:00
|
|
|
|
|
|
|
struct clk *msm_clk_bulk_get_clock(struct clk_bulk_data *bulk, int count,
|
|
|
|
const char *name);
|
2022-01-06 02:26:59 +03:00
|
|
|
void __iomem *msm_ioremap(struct platform_device *pdev, const char *name);
|
2021-04-27 03:18:27 +03:00
|
|
|
void __iomem *msm_ioremap_size(struct platform_device *pdev, const char *name,
|
2022-01-06 02:26:59 +03:00
|
|
|
phys_addr_t *size);
|
|
|
|
void __iomem *msm_ioremap_quiet(struct platform_device *pdev, const char *name);
|
2024-02-08 17:01:09 +02:00
|
|
|
void __iomem *msm_ioremap_mdss(struct platform_device *mdss_pdev,
|
|
|
|
struct platform_device *dev,
|
|
|
|
const char *name);
|
2022-01-06 02:27:00 +03:00
|
|
|
|
2022-08-05 14:56:30 +03:00
|
|
|
struct icc_path *msm_icc_get(struct device *dev, const char *name);
|
|
|
|
|
2022-01-06 02:27:00 +03:00
|
|
|
static inline void msm_rmw(void __iomem *addr, u32 mask, u32 or)
|
|
|
|
{
|
2024-04-10 23:52:52 +02:00
|
|
|
u32 val = readl(addr);
|
2022-01-06 02:27:00 +03:00
|
|
|
|
|
|
|
val &= ~mask;
|
2024-04-10 23:52:52 +02:00
|
|
|
writel(val | or, addr);
|
2022-01-06 02:27:00 +03: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
|
|
|
|
2021-09-27 16:04:53 -07:00
|
|
|
/**
|
|
|
|
* struct msm_hrtimer_work - a helper to combine an hrtimer with kthread_work
|
|
|
|
*
|
|
|
|
* @timer: hrtimer to control when the kthread work is triggered
|
|
|
|
* @work: the kthread work
|
|
|
|
* @worker: the kthread worker the work will be scheduled on
|
|
|
|
*/
|
|
|
|
struct msm_hrtimer_work {
|
|
|
|
struct hrtimer timer;
|
|
|
|
struct kthread_work work;
|
|
|
|
struct kthread_worker *worker;
|
|
|
|
};
|
|
|
|
|
|
|
|
void msm_hrtimer_queue_work(struct msm_hrtimer_work *work,
|
|
|
|
ktime_t wakeup_time,
|
|
|
|
enum hrtimer_mode mode);
|
|
|
|
void msm_hrtimer_work_init(struct msm_hrtimer_work *work,
|
|
|
|
struct kthread_worker *worker,
|
|
|
|
kthread_work_func_t fn,
|
|
|
|
clockid_t clock_id,
|
|
|
|
enum hrtimer_mode mode);
|
|
|
|
|
2024-12-30 08:00:33 -08:00
|
|
|
/* Helper for returning a UABI error with optional logging which can make
|
|
|
|
* it easier for userspace to understand what it is doing wrong.
|
|
|
|
*/
|
|
|
|
#define UERR(err, drm, fmt, ...) \
|
|
|
|
({ DRM_DEV_DEBUG_DRIVER((drm)->dev, fmt, ##__VA_ARGS__); -(err); })
|
|
|
|
|
2016-11-01 17:42:33 -04:00
|
|
|
#define DBG(fmt, ...) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__)
|
|
|
|
#define VERB(fmt, ...) if (0) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__)
|
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
|
|
|
|
|
|
|
static inline int align_pitch(int width, int bpp)
|
|
|
|
{
|
|
|
|
int bytespp = (bpp + 7) / 8;
|
|
|
|
/* adreno needs pitch aligned to 32 pixels: */
|
|
|
|
return bytespp * ALIGN(width, 32);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* for the generated headers: */
|
|
|
|
#define INVALID_IDX(idx) ({BUG(); 0;})
|
2013-07-19 12:59:32 -04:00
|
|
|
#define fui(x) ({BUG(); 0;})
|
2021-05-30 15:44:23 -07:00
|
|
|
#define _mesa_float_to_half(x) ({BUG(); 0;})
|
2013-07-19 12:59:32 -04: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
|
|
|
|
|
|
|
#define FIELD(val, name) (((val) & name ## __MASK) >> name ## __SHIFT)
|
|
|
|
|
|
|
|
/* for conditionally setting boolean flag(s): */
|
|
|
|
#define COND(bool, val) ((bool) ? (val) : 0)
|
|
|
|
|
2016-03-16 14:57:22 -04:00
|
|
|
static inline unsigned long timeout_to_jiffies(const ktime_t *timeout)
|
|
|
|
{
|
|
|
|
ktime_t now = ktime_get();
|
|
|
|
|
2025-01-13 07:48:41 -08:00
|
|
|
if (ktime_compare(*timeout, now) <= 0)
|
|
|
|
return 0;
|
2016-03-16 14:57:22 -04:00
|
|
|
|
2025-01-13 07:48:41 -08:00
|
|
|
ktime_t rem = ktime_sub(*timeout, now);
|
|
|
|
s64 remaining_jiffies = ktime_divns(rem, NSEC_PER_SEC / HZ);
|
2023-03-24 15:00:13 -07:00
|
|
|
return clamp(remaining_jiffies, 1LL, (s64)INT_MAX);
|
2016-03-16 14:57:22 -04: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
|
|
|
|
2022-04-19 18:53:43 +03:00
|
|
|
/* Driver helpers */
|
|
|
|
|
|
|
|
extern const struct component_master_ops msm_drm_ops;
|
|
|
|
|
2023-10-09 21:10:34 +03:00
|
|
|
int msm_kms_pm_prepare(struct device *dev);
|
|
|
|
void msm_kms_pm_complete(struct device *dev);
|
2022-04-19 18:53:43 +03:00
|
|
|
|
2025-07-05 13:02:34 +03:00
|
|
|
int msm_gpu_probe(struct platform_device *pdev,
|
|
|
|
const struct component_ops *ops);
|
|
|
|
void msm_gpu_remove(struct platform_device *pdev,
|
|
|
|
const struct component_ops *ops);
|
2022-04-19 18:53:46 +03:00
|
|
|
int msm_drv_probe(struct device *dev,
|
2023-10-09 20:48:37 +03:00
|
|
|
int (*kms_init)(struct drm_device *dev),
|
|
|
|
struct msm_kms *kms);
|
2023-10-09 21:10:36 +03:00
|
|
|
void msm_kms_shutdown(struct platform_device *pdev);
|
2022-04-19 18:53:43 +03:00
|
|
|
|
2024-02-08 17:01:10 +02:00
|
|
|
bool msm_disp_drv_should_bind(struct device *dev, bool dpu_driver);
|
2022-04-19 18:53:43 +03:00
|
|
|
|
2025-07-05 13:02:35 +03:00
|
|
|
bool msm_gpu_no_components(void);
|
|
|
|
|
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_DRV_H__ */
|