2019-06-03 13:44:50 +08: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-27 00:44:06 +08:00
|
|
|
/*
|
2021-04-17 04:57:20 +08:00
|
|
|
* Copyright (c) 2016-2018, 2020-2021 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-27 00:44:06 +08:00
|
|
|
* Copyright (C) 2013 Red Hat
|
|
|
|
* Author: Rob Clark <robdclark@gmail.com>
|
|
|
|
*/
|
|
|
|
|
2019-08-04 14:55:51 +08:00
|
|
|
#include <linux/dma-mapping.h>
|
2018-06-28 03:26:09 +08:00
|
|
|
#include <linux/kthread.h>
|
2020-10-24 00:51:14 +08:00
|
|
|
#include <linux/sched/mm.h>
|
2019-08-04 14:55:51 +08:00
|
|
|
#include <linux/uaccess.h>
|
2018-06-28 03:26:09 +08:00
|
|
|
#include <uapi/linux/sched/types.h>
|
2019-08-04 14:55:51 +08:00
|
|
|
|
|
|
|
#include <drm/drm_drv.h>
|
|
|
|
#include <drm/drm_file.h>
|
|
|
|
#include <drm/drm_ioctl.h>
|
|
|
|
#include <drm/drm_prime.h>
|
2016-10-19 18:28:27 +08:00
|
|
|
#include <drm/drm_of.h>
|
2019-08-04 14:55:51 +08:00
|
|
|
#include <drm/drm_vblank.h>
|
2016-10-19 18:28:27 +08:00
|
|
|
|
2021-04-17 04:57:20 +08:00
|
|
|
#include "disp/msm_disp_snapshot.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-27 00:44:06 +08:00
|
|
|
#include "msm_drv.h"
|
2016-03-17 00:56:12 +08:00
|
|
|
#include "msm_debugfs.h"
|
2016-03-16 03:35:08 +08:00
|
|
|
#include "msm_fence.h"
|
2018-11-29 23:27:22 +08:00
|
|
|
#include "msm_gem.h"
|
2013-07-20 00:59:32 +08:00
|
|
|
#include "msm_gpu.h"
|
2013-12-01 05:12:10 +08:00
|
|
|
#include "msm_kms.h"
|
2018-11-15 06:08:04 +08:00
|
|
|
#include "adreno/adreno_gpu.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-27 00:44:06 +08:00
|
|
|
|
2016-06-02 02:02:02 +08:00
|
|
|
/*
|
|
|
|
* MSM driver version:
|
|
|
|
* - 1.0.0 - initial interface
|
|
|
|
* - 1.1.0 - adds madvise, and support for submits with > 4 cmd buffers
|
2016-09-17 06:37:44 +08:00
|
|
|
* - 1.2.0 - adds explicit fence support for submit ioctl
|
2017-10-21 01:06:55 +08:00
|
|
|
* - 1.3.0 - adds GMEM_BASE + NR_RINGS params, SUBMITQUEUE_NEW +
|
|
|
|
* SUBMITQUEUE_CLOSE ioctls, and MSM_INFO_IOVA flag for
|
|
|
|
* MSM_GEM_INFO ioctl.
|
2018-11-29 23:30:04 +08:00
|
|
|
* - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to set/get
|
|
|
|
* GEM object's debug name
|
2019-03-23 04:21:22 +08:00
|
|
|
* - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
|
2020-01-24 07:57:10 +08:00
|
|
|
* - 1.6.0 - Syncobj support
|
2021-03-25 09:23:53 +08:00
|
|
|
* - 1.7.0 - Add MSM_PARAM_SUSPENDS to access suspend count
|
2021-04-24 03:08:20 +08:00
|
|
|
* - 1.8.0 - Add MSM_BO_CACHED_COHERENT for supported GPUs (a6xx)
|
2016-06-02 02:02:02 +08:00
|
|
|
*/
|
|
|
|
#define MSM_VERSION_MAJOR 1
|
2021-04-24 03:08:20 +08:00
|
|
|
#define MSM_VERSION_MINOR 8
|
2016-06-02 02:02:02 +08:00
|
|
|
#define MSM_VERSION_PATCHLEVEL 0
|
|
|
|
|
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-27 00:44:06 +08:00
|
|
|
static const struct drm_mode_config_funcs mode_config_funcs = {
|
|
|
|
.fb_create = msm_framebuffer_create,
|
2017-12-06 02:24:59 +08:00
|
|
|
.output_poll_changed = drm_fb_helper_output_poll_changed,
|
2017-10-26 00:30:51 +08:00
|
|
|
.atomic_check = drm_atomic_helper_check,
|
2018-03-01 03:19:05 +08:00
|
|
|
.atomic_commit = drm_atomic_helper_commit,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct drm_mode_config_helper_funcs mode_config_helper_funcs = {
|
|
|
|
.atomic_commit_tail = msm_atomic_commit_tail,
|
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-27 00:44:06 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
#ifdef CONFIG_DRM_MSM_REGISTER_LOGGING
|
2021-09-06 14:43:15 +08:00
|
|
|
static bool reglog;
|
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-27 00:44:06 +08:00
|
|
|
MODULE_PARM_DESC(reglog, "Enable register read/write logging");
|
|
|
|
module_param(reglog, bool, 0600);
|
|
|
|
#else
|
|
|
|
#define reglog 0
|
|
|
|
#endif
|
|
|
|
|
2015-07-13 14:42:07 +08:00
|
|
|
#ifdef CONFIG_DRM_FBDEV_EMULATION
|
2015-01-31 06:05:41 +08:00
|
|
|
static bool fbdev = true;
|
|
|
|
MODULE_PARM_DESC(fbdev, "Enable fbdev compat layer");
|
|
|
|
module_param(fbdev, bool, 0600);
|
|
|
|
#endif
|
|
|
|
|
2014-09-09 02:24:57 +08:00
|
|
|
static char *vram = "16m";
|
2016-02-04 03:02:04 +08:00
|
|
|
MODULE_PARM_DESC(vram, "Configure VRAM size (for devices without IOMMU/GPUMMU)");
|
2013-11-17 01:56:06 +08:00
|
|
|
module_param(vram, charp, 0);
|
|
|
|
|
2021-09-06 14:43:15 +08:00
|
|
|
bool dumpstate;
|
2016-11-05 23:08:12 +08:00
|
|
|
MODULE_PARM_DESC(dumpstate, "Dump KMS state on errors");
|
|
|
|
module_param(dumpstate, bool, 0600);
|
|
|
|
|
2017-07-07 04:33:44 +08:00
|
|
|
static bool modeset = true;
|
|
|
|
MODULE_PARM_DESC(modeset, "Use kernel modesetting [KMS] (1=on (default), 0=disable)");
|
|
|
|
module_param(modeset, bool, 0600);
|
|
|
|
|
2014-03-04 03:19:12 +08:00
|
|
|
/*
|
|
|
|
* Util/helpers:
|
|
|
|
*/
|
|
|
|
|
2018-08-07 01:33:21 +08:00
|
|
|
struct clk *msm_clk_bulk_get_clock(struct clk_bulk_data *bulk, int count,
|
|
|
|
const char *name)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
char n[32];
|
|
|
|
|
|
|
|
snprintf(n, sizeof(n), "%s_clk", name);
|
|
|
|
|
|
|
|
for (i = 0; bulk && i < count; i++) {
|
|
|
|
if (!strcmp(bulk[i].id, name) || !strcmp(bulk[i].id, n))
|
|
|
|
return bulk[i].clk;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-01-31 00:30:58 +08:00
|
|
|
struct clk *msm_clk_get(struct platform_device *pdev, const char *name)
|
|
|
|
{
|
|
|
|
struct clk *clk;
|
|
|
|
char name2[32];
|
|
|
|
|
|
|
|
clk = devm_clk_get(&pdev->dev, name);
|
|
|
|
if (!IS_ERR(clk) || PTR_ERR(clk) == -EPROBE_DEFER)
|
|
|
|
return clk;
|
|
|
|
|
|
|
|
snprintf(name2, sizeof(name2), "%s_clk", name);
|
|
|
|
|
|
|
|
clk = devm_clk_get(&pdev->dev, name2);
|
|
|
|
if (!IS_ERR(clk))
|
|
|
|
dev_warn(&pdev->dev, "Using legacy clk name binding. Use "
|
|
|
|
"\"%s\" instead of \"%s\"\n", name, name2);
|
|
|
|
|
|
|
|
return clk;
|
|
|
|
}
|
|
|
|
|
2020-11-23 19:19:17 +08:00
|
|
|
static void __iomem *_msm_ioremap(struct platform_device *pdev, const char *name,
|
2021-04-27 08:18:27 +08:00
|
|
|
const char *dbgname, bool quiet, phys_addr_t *psize)
|
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-27 00:44:06 +08:00
|
|
|
{
|
|
|
|
struct resource *res;
|
|
|
|
unsigned long size;
|
|
|
|
void __iomem *ptr;
|
|
|
|
|
|
|
|
if (name)
|
|
|
|
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
|
|
|
|
else
|
|
|
|
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
|
|
|
|
|
|
|
|
if (!res) {
|
2020-06-30 02:19:21 +08:00
|
|
|
if (!quiet)
|
|
|
|
DRM_DEV_ERROR(&pdev->dev, "failed to get memory resource: %s\n", name);
|
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-27 00:44:06 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
|
|
|
|
size = resource_size(res);
|
|
|
|
|
2020-01-06 16:43:50 +08:00
|
|
|
ptr = devm_ioremap(&pdev->dev, res->start, 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-27 00:44:06 +08:00
|
|
|
if (!ptr) {
|
2020-06-30 02:19:21 +08:00
|
|
|
if (!quiet)
|
|
|
|
DRM_DEV_ERROR(&pdev->dev, "failed to ioremap: %s\n", name);
|
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-27 00:44:06 +08:00
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (reglog)
|
2015-04-09 22:39:51 +08:00
|
|
|
printk(KERN_DEBUG "IO:region %s %p %08lx\n", dbgname, ptr, 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-27 00:44:06 +08:00
|
|
|
|
2021-04-27 08:18:27 +08:00
|
|
|
if (psize)
|
|
|
|
*psize = 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-27 00:44:06 +08:00
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
|
2020-06-30 02:19:21 +08:00
|
|
|
void __iomem *msm_ioremap(struct platform_device *pdev, const char *name,
|
|
|
|
const char *dbgname)
|
|
|
|
{
|
2021-04-27 08:18:27 +08:00
|
|
|
return _msm_ioremap(pdev, name, dbgname, false, NULL);
|
2020-06-30 02:19:21 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void __iomem *msm_ioremap_quiet(struct platform_device *pdev, const char *name,
|
|
|
|
const char *dbgname)
|
|
|
|
{
|
2021-04-27 08:18:27 +08:00
|
|
|
return _msm_ioremap(pdev, name, dbgname, true, NULL);
|
2020-06-30 02:19:21 +08:00
|
|
|
}
|
|
|
|
|
2021-04-27 08:18:27 +08:00
|
|
|
void __iomem *msm_ioremap_size(struct platform_device *pdev, const char *name,
|
|
|
|
const char *dbgname, phys_addr_t *psize)
|
2021-04-17 04:57:20 +08:00
|
|
|
{
|
2021-04-27 08:18:27 +08:00
|
|
|
return _msm_ioremap(pdev, name, dbgname, false, psize);
|
2021-04-17 04:57:20 +08: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-27 00:44:06 +08:00
|
|
|
void msm_writel(u32 data, void __iomem *addr)
|
|
|
|
{
|
|
|
|
if (reglog)
|
2015-04-09 22:39:51 +08:00
|
|
|
printk(KERN_DEBUG "IO:W %p %08x\n", addr, data);
|
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-27 00:44:06 +08:00
|
|
|
writel(data, addr);
|
|
|
|
}
|
|
|
|
|
|
|
|
u32 msm_readl(const void __iomem *addr)
|
|
|
|
{
|
|
|
|
u32 val = readl(addr);
|
|
|
|
if (reglog)
|
2017-02-28 20:55:54 +08:00
|
|
|
pr_err("IO:R %p %08x\n", addr, val);
|
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-27 00:44:06 +08:00
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
2020-11-25 15:00:14 +08:00
|
|
|
void msm_rmw(void __iomem *addr, u32 mask, u32 or)
|
|
|
|
{
|
|
|
|
u32 val = msm_readl(addr);
|
|
|
|
|
|
|
|
val &= ~mask;
|
|
|
|
msm_writel(val | or, addr);
|
|
|
|
}
|
|
|
|
|
2021-09-28 07:04:53 +08:00
|
|
|
static enum hrtimer_restart msm_hrtimer_worktimer(struct hrtimer *t)
|
|
|
|
{
|
|
|
|
struct msm_hrtimer_work *work = container_of(t,
|
|
|
|
struct msm_hrtimer_work, timer);
|
|
|
|
|
|
|
|
kthread_queue_work(work->worker, &work->work);
|
|
|
|
|
|
|
|
return HRTIMER_NORESTART;
|
|
|
|
}
|
|
|
|
|
|
|
|
void msm_hrtimer_queue_work(struct msm_hrtimer_work *work,
|
|
|
|
ktime_t wakeup_time,
|
|
|
|
enum hrtimer_mode mode)
|
|
|
|
{
|
|
|
|
hrtimer_start(&work->timer, wakeup_time, 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)
|
|
|
|
{
|
|
|
|
hrtimer_init(&work->timer, clock_id, mode);
|
|
|
|
work->timer.function = msm_hrtimer_worktimer;
|
|
|
|
work->worker = worker;
|
|
|
|
kthread_init_work(&work->work, fn);
|
|
|
|
}
|
|
|
|
|
2021-08-03 17:06:57 +08:00
|
|
|
static irqreturn_t msm_irq(int irq, void *arg)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = arg;
|
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
|
|
|
struct msm_kms *kms = priv->kms;
|
|
|
|
|
|
|
|
BUG_ON(!kms);
|
|
|
|
|
|
|
|
return kms->funcs->irq(kms);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void msm_irq_preinstall(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
|
|
|
struct msm_kms *kms = priv->kms;
|
|
|
|
|
|
|
|
BUG_ON(!kms);
|
|
|
|
|
|
|
|
kms->funcs->irq_preinstall(kms);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int msm_irq_postinstall(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
|
|
|
struct msm_kms *kms = priv->kms;
|
|
|
|
|
|
|
|
BUG_ON(!kms);
|
|
|
|
|
|
|
|
if (kms->funcs->irq_postinstall)
|
|
|
|
return kms->funcs->irq_postinstall(kms);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int msm_irq_install(struct drm_device *dev, unsigned int irq)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (irq == IRQ_NOTCONNECTED)
|
|
|
|
return -ENOTCONN;
|
|
|
|
|
|
|
|
msm_irq_preinstall(dev);
|
|
|
|
|
|
|
|
ret = request_irq(irq, msm_irq, 0, dev->driver->name, dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = msm_irq_postinstall(dev);
|
|
|
|
if (ret) {
|
|
|
|
free_irq(irq, dev);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void msm_irq_uninstall(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
|
|
|
struct msm_kms *kms = priv->kms;
|
|
|
|
|
|
|
|
kms->funcs->irq_uninstall(kms);
|
|
|
|
free_irq(kms->irq, dev);
|
|
|
|
}
|
|
|
|
|
2018-12-15 07:57:55 +08:00
|
|
|
struct msm_vblank_work {
|
|
|
|
struct work_struct work;
|
2015-07-28 01:49:45 +08:00
|
|
|
int crtc_id;
|
|
|
|
bool enable;
|
2018-12-15 07:57:55 +08:00
|
|
|
struct msm_drm_private *priv;
|
2015-07-28 01:49:45 +08:00
|
|
|
};
|
|
|
|
|
2018-12-15 07:57:52 +08:00
|
|
|
static void vblank_ctrl_worker(struct work_struct *work)
|
2015-07-28 01:49:45 +08:00
|
|
|
{
|
2018-12-15 07:57:55 +08:00
|
|
|
struct msm_vblank_work *vbl_work = container_of(work,
|
|
|
|
struct msm_vblank_work, work);
|
|
|
|
struct msm_drm_private *priv = vbl_work->priv;
|
2015-07-28 01:49:45 +08:00
|
|
|
struct msm_kms *kms = priv->kms;
|
|
|
|
|
2018-12-15 07:57:55 +08:00
|
|
|
if (vbl_work->enable)
|
|
|
|
kms->funcs->enable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
|
|
|
|
else
|
|
|
|
kms->funcs->disable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
|
2015-07-28 01:49:45 +08:00
|
|
|
|
2018-12-15 07:57:55 +08:00
|
|
|
kfree(vbl_work);
|
2015-07-28 01:49:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int vblank_ctrl_queue_work(struct msm_drm_private *priv,
|
|
|
|
int crtc_id, bool enable)
|
|
|
|
{
|
2018-12-15 07:57:55 +08:00
|
|
|
struct msm_vblank_work *vbl_work;
|
2015-07-28 01:49:45 +08:00
|
|
|
|
2018-12-15 07:57:55 +08:00
|
|
|
vbl_work = kzalloc(sizeof(*vbl_work), GFP_ATOMIC);
|
|
|
|
if (!vbl_work)
|
2015-07-28 01:49:45 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
|
2018-12-15 07:57:55 +08:00
|
|
|
INIT_WORK(&vbl_work->work, vblank_ctrl_worker);
|
2015-07-28 01:49:45 +08:00
|
|
|
|
2018-12-15 07:57:55 +08:00
|
|
|
vbl_work->crtc_id = crtc_id;
|
|
|
|
vbl_work->enable = enable;
|
|
|
|
vbl_work->priv = priv;
|
2015-07-28 01:49:45 +08:00
|
|
|
|
2018-12-15 07:57:55 +08:00
|
|
|
queue_work(priv->wq, &vbl_work->work);
|
2015-07-28 01:49:45 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
static int msm_drm_uninit(struct 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-27 00:44:06 +08:00
|
|
|
{
|
2016-05-02 13:35:54 +08:00
|
|
|
struct platform_device *pdev = to_platform_device(dev);
|
|
|
|
struct drm_device *ddev = platform_get_drvdata(pdev);
|
|
|
|
struct msm_drm_private *priv = ddev->dev_private;
|
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-27 00:44:06 +08:00
|
|
|
struct msm_kms *kms = priv->kms;
|
2018-06-22 04:06:10 +08:00
|
|
|
struct msm_mdss *mdss = priv->mdss;
|
2018-06-28 03:26:09 +08:00
|
|
|
int i;
|
2015-07-28 01:49:45 +08:00
|
|
|
|
2019-05-25 04:29:13 +08:00
|
|
|
/*
|
|
|
|
* Shutdown the hw if we're far enough along where things might be on.
|
|
|
|
* If we run this too early, we'll end up panicking in any variety of
|
|
|
|
* places. Since we don't register the drm device until late in
|
|
|
|
* msm_drm_init, drm_dev->registered is used as an indicator that the
|
|
|
|
* shutdown will be successful.
|
|
|
|
*/
|
|
|
|
if (ddev->registered) {
|
|
|
|
drm_dev_unregister(ddev);
|
|
|
|
drm_atomic_helper_shutdown(ddev);
|
|
|
|
}
|
|
|
|
|
2015-07-28 01:49:45 +08:00
|
|
|
/* We must cancel and cleanup any pending vblank enable/disable
|
2021-08-03 17:06:57 +08:00
|
|
|
* work before msm_irq_uninstall() to avoid work re-enabling an
|
2015-07-28 01:49:45 +08:00
|
|
|
* irq after uninstall has disabled it.
|
|
|
|
*/
|
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-27 00:44:06 +08:00
|
|
|
|
2018-12-15 07:57:55 +08:00
|
|
|
flush_workqueue(priv->wq);
|
2018-06-28 03:26:09 +08:00
|
|
|
|
2018-12-15 07:57:54 +08:00
|
|
|
/* clean up event worker threads */
|
2018-06-28 03:26:09 +08:00
|
|
|
for (i = 0; i < priv->num_crtcs; i++) {
|
2020-07-21 09:33:03 +08:00
|
|
|
if (priv->event_thread[i].worker)
|
|
|
|
kthread_destroy_worker(priv->event_thread[i].worker);
|
2018-06-28 03:26:09 +08:00
|
|
|
}
|
|
|
|
|
2016-05-18 04:19:32 +08:00
|
|
|
msm_gem_shrinker_cleanup(ddev);
|
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
drm_kms_helper_poll_fini(ddev);
|
|
|
|
|
2017-03-08 04:49:22 +08:00
|
|
|
msm_perf_debugfs_cleanup(priv);
|
|
|
|
msm_rd_debugfs_cleanup(priv);
|
|
|
|
|
2016-02-25 13:49:45 +08:00
|
|
|
#ifdef CONFIG_DRM_FBDEV_EMULATION
|
|
|
|
if (fbdev && priv->fbdev)
|
2016-05-02 13:35:54 +08:00
|
|
|
msm_fbdev_free(ddev);
|
2016-02-25 13:49:45 +08:00
|
|
|
#endif
|
2019-05-25 04:29:13 +08:00
|
|
|
|
2021-04-17 04:57:20 +08:00
|
|
|
msm_disp_snapshot_destroy(ddev);
|
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
drm_mode_config_cleanup(ddev);
|
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-27 00:44:06 +08:00
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
pm_runtime_get_sync(dev);
|
2021-08-03 17:06:57 +08:00
|
|
|
msm_irq_uninstall(ddev);
|
2016-05-02 13:35:54 +08:00
|
|
|
pm_runtime_put_sync(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-27 00:44:06 +08:00
|
|
|
|
2016-11-03 20:06:18 +08:00
|
|
|
if (kms && kms->funcs)
|
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-27 00:44:06 +08:00
|
|
|
kms->funcs->destroy(kms);
|
|
|
|
|
2013-11-17 01:56:06 +08:00
|
|
|
if (priv->vram.paddr) {
|
2016-08-04 04:46:00 +08:00
|
|
|
unsigned long attrs = DMA_ATTR_NO_KERNEL_MAPPING;
|
2013-11-17 01:56:06 +08:00
|
|
|
drm_mm_takedown(&priv->vram.mm);
|
2016-05-02 13:35:54 +08:00
|
|
|
dma_free_attrs(dev, priv->vram.size, NULL,
|
2016-08-04 04:46:00 +08:00
|
|
|
priv->vram.paddr, attrs);
|
2013-11-17 01:56:06 +08:00
|
|
|
}
|
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
component_unbind_all(dev, ddev);
|
2014-03-04 03:19:12 +08:00
|
|
|
|
2018-06-22 04:06:10 +08:00
|
|
|
if (mdss && mdss->funcs)
|
|
|
|
mdss->funcs->destroy(ddev);
|
2016-05-09 00:06:28 +08:00
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
ddev->dev_private = NULL;
|
2018-09-26 19:48:59 +08:00
|
|
|
drm_dev_put(ddev);
|
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-27 00:44:06 +08:00
|
|
|
|
2019-05-25 04:29:13 +08:00
|
|
|
destroy_workqueue(priv->wq);
|
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-27 00:44:06 +08:00
|
|
|
kfree(priv);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-06-28 02:26:24 +08:00
|
|
|
#define KMS_MDP4 4
|
|
|
|
#define KMS_MDP5 5
|
2018-06-28 03:26:09 +08:00
|
|
|
#define KMS_DPU 3
|
2018-06-28 02:26:24 +08:00
|
|
|
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
static int get_mdp_ver(struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
struct device *dev = &pdev->dev;
|
2015-11-18 14:45:14 +08:00
|
|
|
|
|
|
|
return (int) (unsigned long) of_device_get_match_data(dev);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
}
|
|
|
|
|
2015-03-04 04:04:25 +08:00
|
|
|
#include <linux/of_address.h>
|
|
|
|
|
2018-11-15 06:08:04 +08:00
|
|
|
bool msm_use_mmu(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
|
|
|
|
|
|
|
/* a2xx comes with its own MMU */
|
|
|
|
return priv->is_a2xx || iommu_present(&platform_bus_type);
|
|
|
|
}
|
|
|
|
|
2015-03-04 04:04:24 +08:00
|
|
|
static int msm_init_vram(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-27 00:44:06 +08:00
|
|
|
{
|
2015-03-04 04:04:24 +08:00
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
2015-11-18 14:45:14 +08:00
|
|
|
struct device_node *node;
|
2015-03-04 04:04:25 +08:00
|
|
|
unsigned long size = 0;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
/* In the device-tree world, we could have a 'memory-region'
|
|
|
|
* phandle, which gives us a link to our "vram". Allocating
|
|
|
|
* is all nicely abstracted behind the dma api, but we need
|
|
|
|
* to know the entire size to allocate it all in one go. There
|
|
|
|
* are two cases:
|
|
|
|
* 1) device with no IOMMU, in which case we need exclusive
|
|
|
|
* access to a VRAM carveout big enough for all gpu
|
|
|
|
* buffers
|
|
|
|
* 2) device with IOMMU, but where the bootloader puts up
|
|
|
|
* a splash screen. In this case, the VRAM carveout
|
|
|
|
* need only be large enough for fbdev fb. But we need
|
|
|
|
* exclusive access to the buffer to avoid the kernel
|
|
|
|
* using those pages for other purposes (which appears
|
|
|
|
* as corruption on screen before we have a chance to
|
|
|
|
* load and do initial modeset)
|
|
|
|
*/
|
|
|
|
|
|
|
|
node = of_parse_phandle(dev->dev->of_node, "memory-region", 0);
|
|
|
|
if (node) {
|
|
|
|
struct resource r;
|
|
|
|
ret = of_address_to_resource(node, 0, &r);
|
2016-07-04 16:49:50 +08:00
|
|
|
of_node_put(node);
|
2015-03-04 04:04:25 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
size = r.end - r.start;
|
2015-04-09 22:39:51 +08:00
|
|
|
DRM_INFO("using VRAM carveout: %lx@%pa\n", size, &r.start);
|
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-27 00:44:06 +08:00
|
|
|
|
2015-11-18 14:45:14 +08:00
|
|
|
/* if we have no IOMMU, then we need to use carveout allocator.
|
|
|
|
* Grab the entire CMA chunk carved out in early startup in
|
|
|
|
* mach-msm:
|
|
|
|
*/
|
2018-11-15 06:08:04 +08:00
|
|
|
} else if (!msm_use_mmu(dev)) {
|
2015-03-04 04:04:25 +08:00
|
|
|
DRM_INFO("using %s VRAM carveout\n", vram);
|
|
|
|
size = memparse(vram, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (size) {
|
2016-08-04 04:46:00 +08:00
|
|
|
unsigned long attrs = 0;
|
2013-11-17 01:56:06 +08:00
|
|
|
void *p;
|
|
|
|
|
|
|
|
priv->vram.size = size;
|
|
|
|
|
|
|
|
drm_mm_init(&priv->vram.mm, 0, (size >> PAGE_SHIFT) - 1);
|
2017-06-14 06:52:54 +08:00
|
|
|
spin_lock_init(&priv->vram.lock);
|
2013-11-17 01:56:06 +08:00
|
|
|
|
2016-08-04 04:46:00 +08:00
|
|
|
attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
|
|
|
|
attrs |= DMA_ATTR_WRITE_COMBINE;
|
2013-11-17 01:56:06 +08:00
|
|
|
|
|
|
|
/* note that for no-kernel-mapping, the vaddr returned
|
|
|
|
* is bogus, but non-null if allocation succeeded:
|
|
|
|
*/
|
|
|
|
p = dma_alloc_attrs(dev->dev, size,
|
2016-08-04 04:46:00 +08:00
|
|
|
&priv->vram.paddr, GFP_KERNEL, attrs);
|
2013-11-17 01:56:06 +08:00
|
|
|
if (!p) {
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(dev->dev, "failed to allocate VRAM\n");
|
2013-11-17 01:56:06 +08:00
|
|
|
priv->vram.paddr = 0;
|
2015-03-04 04:04:24 +08:00
|
|
|
return -ENOMEM;
|
2013-11-17 01:56:06 +08:00
|
|
|
}
|
|
|
|
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_INFO(dev->dev, "VRAM: %08x->%08x\n",
|
2013-11-17 01:56:06 +08:00
|
|
|
(uint32_t)priv->vram.paddr,
|
|
|
|
(uint32_t)(priv->vram.paddr + size));
|
|
|
|
}
|
|
|
|
|
2015-03-04 04:04:25 +08:00
|
|
|
return ret;
|
2015-03-04 04:04:24 +08:00
|
|
|
}
|
|
|
|
|
2020-11-04 18:04:24 +08:00
|
|
|
static int msm_drm_init(struct device *dev, const struct drm_driver *drv)
|
2015-03-04 04:04:24 +08:00
|
|
|
{
|
2016-05-02 13:35:54 +08:00
|
|
|
struct platform_device *pdev = to_platform_device(dev);
|
|
|
|
struct drm_device *ddev;
|
2015-03-04 04:04:24 +08:00
|
|
|
struct msm_drm_private *priv;
|
|
|
|
struct msm_kms *kms;
|
2018-06-22 04:06:10 +08:00
|
|
|
struct msm_mdss *mdss;
|
2018-06-28 03:26:09 +08:00
|
|
|
int ret, i;
|
2015-03-04 04:04:24 +08:00
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
ddev = drm_dev_alloc(drv, dev);
|
2016-09-21 22:59:19 +08:00
|
|
|
if (IS_ERR(ddev)) {
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(dev, "failed to allocate drm_device\n");
|
2016-09-21 22:59:19 +08:00
|
|
|
return PTR_ERR(ddev);
|
2016-05-02 13:35:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
platform_set_drvdata(pdev, ddev);
|
|
|
|
|
2015-03-04 04:04:24 +08:00
|
|
|
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
|
|
|
|
if (!priv) {
|
2018-06-28 02:35:28 +08:00
|
|
|
ret = -ENOMEM;
|
2018-09-26 19:48:59 +08:00
|
|
|
goto err_put_drm_dev;
|
2015-03-04 04:04:24 +08:00
|
|
|
}
|
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
ddev->dev_private = priv;
|
2016-05-18 04:19:32 +08:00
|
|
|
priv->dev = ddev;
|
2015-03-04 04:04:24 +08:00
|
|
|
|
2018-06-28 03:26:09 +08:00
|
|
|
switch (get_mdp_ver(pdev)) {
|
|
|
|
case KMS_MDP5:
|
|
|
|
ret = mdp5_mdss_init(ddev);
|
|
|
|
break;
|
|
|
|
case KMS_DPU:
|
|
|
|
ret = dpu_mdss_init(ddev);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ret = 0;
|
|
|
|
break;
|
|
|
|
}
|
2018-06-28 02:35:28 +08:00
|
|
|
if (ret)
|
|
|
|
goto err_free_priv;
|
2016-05-09 00:06:28 +08:00
|
|
|
|
2018-06-22 04:06:10 +08:00
|
|
|
mdss = priv->mdss;
|
|
|
|
|
2015-03-04 04:04:24 +08:00
|
|
|
priv->wq = alloc_ordered_workqueue("msm", 0);
|
2021-06-07 18:44:41 +08:00
|
|
|
priv->hangcheck_period = DRM_MSM_HANGCHECK_DEFAULT_PERIOD;
|
2015-03-04 04:04:24 +08:00
|
|
|
|
2021-04-01 09:27:20 +08:00
|
|
|
INIT_LIST_HEAD(&priv->objects);
|
|
|
|
mutex_init(&priv->obj_lock);
|
|
|
|
|
2020-11-17 01:48:51 +08:00
|
|
|
INIT_LIST_HEAD(&priv->inactive_willneed);
|
|
|
|
INIT_LIST_HEAD(&priv->inactive_dontneed);
|
2021-04-06 01:45:29 +08:00
|
|
|
INIT_LIST_HEAD(&priv->inactive_unpinned);
|
2020-10-24 00:51:14 +08:00
|
|
|
mutex_init(&priv->mm_lock);
|
2019-03-21 01:09:08 +08:00
|
|
|
|
2020-10-24 00:51:14 +08:00
|
|
|
/* Teach lockdep about lock ordering wrt. shrinker: */
|
|
|
|
fs_reclaim_acquire(GFP_KERNEL);
|
|
|
|
might_lock(&priv->mm_lock);
|
|
|
|
fs_reclaim_release(GFP_KERNEL);
|
2015-03-04 04:04:24 +08:00
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
drm_mode_config_init(ddev);
|
2014-03-04 03:19:12 +08:00
|
|
|
|
2020-12-30 23:29:42 +08:00
|
|
|
ret = msm_init_vram(ddev);
|
2018-06-28 02:35:28 +08:00
|
|
|
if (ret)
|
|
|
|
goto err_destroy_mdss;
|
2014-03-04 03:19:12 +08:00
|
|
|
|
2020-12-30 23:29:42 +08:00
|
|
|
/* Bind all our sub-components: */
|
|
|
|
ret = component_bind_all(dev, ddev);
|
2015-05-08 03:20:13 +08:00
|
|
|
if (ret)
|
2020-12-30 23:29:42 +08:00
|
|
|
goto err_destroy_mdss;
|
2015-05-08 03:20:13 +08:00
|
|
|
|
2020-09-04 05:04:03 +08:00
|
|
|
dma_set_max_seg_size(dev, UINT_MAX);
|
2020-01-22 03:18:48 +08:00
|
|
|
|
2016-05-18 04:19:32 +08:00
|
|
|
msm_gem_shrinker_init(ddev);
|
|
|
|
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
switch (get_mdp_ver(pdev)) {
|
2018-06-28 02:26:24 +08:00
|
|
|
case KMS_MDP4:
|
2016-05-02 13:35:54 +08:00
|
|
|
kms = mdp4_kms_init(ddev);
|
2016-05-09 00:06:28 +08:00
|
|
|
priv->kms = kms;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
break;
|
2018-06-28 02:26:24 +08:00
|
|
|
case KMS_MDP5:
|
2016-06-14 20:54:54 +08:00
|
|
|
kms = mdp5_kms_init(ddev);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
break;
|
2018-06-28 03:26:09 +08:00
|
|
|
case KMS_DPU:
|
|
|
|
kms = dpu_kms_init(ddev);
|
|
|
|
priv->kms = kms;
|
|
|
|
break;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
default:
|
2018-12-04 23:16:58 +08:00
|
|
|
/* valid only for the dummy headless case, where of_node=NULL */
|
|
|
|
WARN_ON(dev->of_node);
|
|
|
|
kms = NULL;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
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-27 00:44:06 +08:00
|
|
|
if (IS_ERR(kms)) {
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(dev, "failed to load kms\n");
|
2013-09-17 05:19:54 +08:00
|
|
|
ret = PTR_ERR(kms);
|
2018-11-22 09:52:35 +08:00
|
|
|
priv->kms = NULL;
|
2018-06-28 02:35:28 +08:00
|
|
|
goto err_msm_uninit;
|
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-27 00:44:06 +08:00
|
|
|
}
|
|
|
|
|
2018-06-12 05:13:20 +08:00
|
|
|
/* Enable normalization of plane zpos */
|
|
|
|
ddev->mode_config.normalize_zpos = true;
|
|
|
|
|
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-27 00:44:06 +08:00
|
|
|
if (kms) {
|
2019-08-30 00:45:16 +08:00
|
|
|
kms->dev = ddev;
|
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-27 00:44:06 +08:00
|
|
|
ret = kms->funcs->hw_init(kms);
|
|
|
|
if (ret) {
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(dev, "kms hw init failed: %d\n", ret);
|
2018-06-28 02:35:28 +08:00
|
|
|
goto err_msm_uninit;
|
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-27 00:44:06 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
ddev->mode_config.funcs = &mode_config_funcs;
|
2018-03-01 03:19:05 +08:00
|
|
|
ddev->mode_config.helper_private = &mode_config_helper_funcs;
|
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-27 00:44:06 +08:00
|
|
|
|
2018-06-28 03:26:09 +08:00
|
|
|
for (i = 0; i < priv->num_crtcs; i++) {
|
|
|
|
/* initialize event thread */
|
|
|
|
priv->event_thread[i].crtc_id = priv->crtcs[i]->base.id;
|
|
|
|
priv->event_thread[i].dev = ddev;
|
2020-07-21 09:33:03 +08:00
|
|
|
priv->event_thread[i].worker = kthread_create_worker(0,
|
|
|
|
"crtc_event:%d", priv->event_thread[i].crtc_id);
|
|
|
|
if (IS_ERR(priv->event_thread[i].worker)) {
|
2021-05-08 10:28:36 +08:00
|
|
|
ret = PTR_ERR(priv->event_thread[i].worker);
|
drm pull request for 4.21-rc1
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcExwOAAoJEAx081l5xIa+euIP/1NZZvSB+bsCtOwDG8I6uWsS
OU5JUZ8q2dqyyFagRxzlkeSt3uWJqKp5NyNwuc9z/5u6AGF+3/97D0J1lG6Os/st
4abF6NadivYJ4cXhJ1ddIHOFMVDcAsyMWNDb93NwPwncCsQ0jt5FFOsrCyj6BGY+
ihHFlHrIyDrbBGDHz+u1E/EO5WkNnaLDoC+/k2fTRWCNI3bQL3O+orsYTI6S2uvU
lQJnRfYAllgLD2p1k/rrBHcHXBv50roR0e8uhGmbdhGdp5bEW30UGBLHXxQjjSVy
fQCwFwTO8X6zoxU53Zbbk+MVrp+jkTHcGKViHRuLkaHzE5mX26UXDwlXdN32ZUbK
yHOJp+uDaWXX7MIz0LsB9Iqj2+eIUoFaIJMoZTMGVTNvqnTxKnoHnjAtbTH2u258
teFgmy4BIgPgo2kwEnBEZjCapou0Eivyut2wq8bTAB2Fe8LwURJpr3cioTtMLlUO
L5/PoD27eFvBCAeFrQIwF3b2XiQEnBpXocmilEwP1xDMPgoyeePAfIF2iEpDvi0U
jce3rLd2yVvo92xYUgoHkVTD8si/pKKnZ1D0U3+RI6pxK6s0HJEHjcNEMdvdm+2S
4qgvBQV3wlWFkXEK8PR5BHPoLntg18tKon/BTLBjgGkN9E1o9fWs1/s6KQGY4xdo
l3Vvfx2LTdkgEoBssSwB
=wh4W
-----END PGP SIGNATURE-----
Merge tag 'drm-next-2018-12-14' of git://anongit.freedesktop.org/drm/drm
Pull drm updates from Dave Airlie:
"Core:
- shared fencing staging removal
- drop transactional atomic helpers and move helpers to new location
- DP/MST atomic cleanup
- Leasing cleanups and drop EXPORT_SYMBOL
- Convert drivers to atomic helpers and generic fbdev.
- removed deprecated obj_ref/unref in favour of get/put
- Improve dumb callback documentation
- MODESET_LOCK_BEGIN/END helpers
panels:
- CDTech panels, Banana Pi Panel, DLC1010GIG,
- Olimex LCD-O-LinuXino, Samsung S6D16D0, Truly NT35597 WQXGA,
- Himax HX8357D, simulated RTSM AEMv8.
- GPD Win2 panel
- AUO G101EVN010
vgem:
- render node support
ttm:
- move global init out of drivers
- fix LRU handling for ghost objects
- Support for simultaneous submissions to multiple engines
scheduler:
- timeout/fault handling changes to help GPU recovery
- helpers for hw with preemption support
i915:
- Scaler/Watermark fixes
- DP MST + powerwell fixes
- PSR fixes
- Break long get/put shmemfs pages
- Icelake fixes
- Icelake DSI video mode enablement
- Engine workaround improvements
amdgpu:
- freesync support
- GPU reset enabled on CI, VI, SOC15 dGPUs
- ABM support in DC
- KFD support for vega12/polaris12
- SDMA paging queue on vega
- More amdkfd code sharing
- DCC scanout on GFX9
- DC kerneldoc
- Updated SMU firmware for GFX8 chips
- XGMI PSP + hive reset support
- GPU reset
- DC trace support
- Powerplay updates for newer Polaris
- Cursor plane update fast path
- kfd dma-buf support
virtio-gpu:
- add EDID support
vmwgfx:
- pageflip with damage support
nouveau:
- Initial Turing TU104/TU106 modesetting support
msm:
- a2xx gpu support for apq8060 and imx5
- a2xx gpummu support
- mdp4 display support for apq8060
- DPU fixes and cleanups
- enhanced profiling support
- debug object naming interface
- get_iova/page pinning decoupling
tegra:
- Tegra194 host1x, VIC and display support enabled
- Audio over HDMI for Tegra186 and Tegra194
exynos:
- DMA/IOMMU refactoring
- plane alpha + blend mode support
- Color format fixes for mixer driver
rcar-du:
- R8A7744 and R8A77470 support
- R8A77965 LVDS support
imx:
- fbdev emulation fix
- multi-tiled scalling fixes
- SPDX identifiers
rockchip
- dw_hdmi support
- dw-mipi-dsi + dual dsi support
- mailbox read size fix
qxl:
- fix cursor pinning
vc4:
- YUV support (scaling + cursor)
v3d:
- enable TFU (Texture Formatting Unit)
mali-dp:
- add support for linear tiled formats
sun4i:
- Display Engine 3 support
- H6 DE3 mixer 0 support
- H6 display engine support
- dw-hdmi support
- H6 HDMI phy support
- implicit fence waiting
- BGRX8888 support
meson:
- Overlay plane support
- implicit fence waiting
- HDMI 1.4 4k modes
bridge:
- i2c fixes for sii902x"
* tag 'drm-next-2018-12-14' of git://anongit.freedesktop.org/drm/drm: (1403 commits)
drm/amd/display: Add fast path for cursor plane updates
drm/amdgpu: Enable GPU recovery by default for CI
drm/amd/display: Fix duplicating scaling/underscan connector state
drm/amd/display: Fix unintialized max_bpc state values
Revert "drm/amd/display: Set RMX_ASPECT as default"
drm/amdgpu: Fix stub function name
drm/msm/dpu: Fix clock issue after bind failure
drm/msm/dpu: Clean up dpu_media_info.h static inline functions
drm/msm/dpu: Further cleanups for static inline functions
drm/msm/dpu: Cleanup the debugfs functions
drm/msm/dpu: Remove dpu_irq and unused functions
drm/msm: Make irq_postinstall optional
drm/msm/dpu: Cleanup callers of dpu_hw_blk_init
drm/msm/dpu: Remove unused functions
drm/msm/dpu: Remove dpu_crtc_is_enabled()
drm/msm/dpu: Remove dpu_crtc_get_mixer_height
drm/msm/dpu: Remove dpu_dbg
drm/msm: dpu: Remove crtc_lock
drm/msm: dpu: Remove vblank_requested flag from dpu_crtc
drm/msm: dpu: Separate crtc assignment from vblank enable
...
2018-12-26 03:48:26 +08:00
|
|
|
DRM_DEV_ERROR(dev, "failed to create crtc_event kthread\n");
|
2021-07-05 21:43:02 +08:00
|
|
|
ret = PTR_ERR(priv->event_thread[i].worker);
|
2018-10-11 05:11:16 +08:00
|
|
|
goto err_msm_uninit;
|
|
|
|
}
|
|
|
|
|
This tree adds the sched_set_fifo*() encapsulation APIs to remove
static priority level knowledge from non-scheduler code.
The three APIs for non-scheduler code to set SCHED_FIFO are:
- sched_set_fifo()
- sched_set_fifo_low()
- sched_set_normal()
These are two FIFO priority levels: default (high), and a 'low' priority level,
plus sched_set_normal() to set the policy back to non-SCHED_FIFO.
Since the changes affect a lot of non-scheduler code, we kept this in a separate
tree.
When merging to the latest upstream tree there's a conflict in drivers/spi/spi.c,
which can be resolved via:
sched_set_fifo(ctlr->kworker_task);
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAl8pPQIRHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1j0Jw/+LlSyX6gD2ATy3cizGL7DFPZogD5MVKTb
IXbhXH/ACpuPQlBe1+haRLbJj6XfXqbOlAleVKt7eh+jZ1jYjC972RCSTO4566mJ
0v8Iy9kkEeb2TDbYx1H3bnk78lf85t0CB+sCzyKUYFuTrXU04eRj7MtN3vAQyRQU
xJg83x/sT5DGdDTP50sL7lpbwk3INWkD0aDCJEaO/a9yHElMsTZiZBKoXxN/s30o
FsfzW56jqtng771H2bo8ERN7+abwJg10crQU5mIaLhacNMETuz0NZ/f8fY/fydCL
Ju8HAdNKNXyphWkAOmixQuyYtWKe2/GfbHg8hld0jmpwxkOSTgZjY+pFcv7/w306
g2l1TPOt8e1n5jbfnY3eig+9Kr8y0qHkXPfLfgRqKwMMaOqTTYixEzj+NdxEIRX9
Kr7oFAv6VEFfXGSpb5L1qyjIGVgQ5/JE/p3OC3GHEsw5VKiy5yjhNLoSmSGzdS61
1YurVvypSEUAn3DqTXgeGX76f0HH365fIKqmbFrUWxliF+YyflMhtrj2JFtejGzH
Md3RgAzxusE9S6k3gw1ev4byh167bPBbY8jz0w3Gd7IBRKy9vo92h6ZRYIl6xeoC
BU2To1IhCAydIr6hNsIiCSDTgiLbsYQzPuVVovUxNh+l1ZvKV2X+csEHhs8oW4pr
4BRU7dKL2NE=
=/7JH
-----END PGP SIGNATURE-----
Merge tag 'sched-fifo-2020-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull sched/fifo updates from Ingo Molnar:
"This adds the sched_set_fifo*() encapsulation APIs to remove static
priority level knowledge from non-scheduler code.
The three APIs for non-scheduler code to set SCHED_FIFO are:
- sched_set_fifo()
- sched_set_fifo_low()
- sched_set_normal()
These are two FIFO priority levels: default (high), and a 'low'
priority level, plus sched_set_normal() to set the policy back to
non-SCHED_FIFO.
Since the changes affect a lot of non-scheduler code, we kept this in
a separate tree"
* tag 'sched-fifo-2020-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (24 commits)
sched,tracing: Convert to sched_set_fifo()
sched: Remove sched_set_*() return value
sched: Remove sched_setscheduler*() EXPORTs
sched,psi: Convert to sched_set_fifo_low()
sched,rcutorture: Convert to sched_set_fifo_low()
sched,rcuperf: Convert to sched_set_fifo_low()
sched,locktorture: Convert to sched_set_fifo()
sched,irq: Convert to sched_set_fifo()
sched,watchdog: Convert to sched_set_fifo()
sched,serial: Convert to sched_set_fifo()
sched,powerclamp: Convert to sched_set_fifo()
sched,ion: Convert to sched_set_normal()
sched,powercap: Convert to sched_set_fifo*()
sched,spi: Convert to sched_set_fifo*()
sched,mmc: Convert to sched_set_fifo*()
sched,ivtv: Convert to sched_set_fifo*()
sched,drm/scheduler: Convert to sched_set_fifo*()
sched,msm: Convert to sched_set_fifo*()
sched,psci: Convert to sched_set_fifo*()
sched,drbd: Convert to sched_set_fifo*()
...
2020-08-07 02:55:43 +08:00
|
|
|
sched_set_fifo(priv->event_thread[i].worker->task);
|
2018-06-28 03:26:09 +08:00
|
|
|
}
|
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
ret = drm_vblank_init(ddev, priv->num_crtcs);
|
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-27 00:44:06 +08:00
|
|
|
if (ret < 0) {
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(dev, "failed to initialize vblank\n");
|
2018-06-28 02:35:28 +08:00
|
|
|
goto err_msm_uninit;
|
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-27 00:44:06 +08:00
|
|
|
}
|
|
|
|
|
2016-05-18 17:36:03 +08:00
|
|
|
if (kms) {
|
|
|
|
pm_runtime_get_sync(dev);
|
2021-08-03 17:06:57 +08:00
|
|
|
ret = msm_irq_install(ddev, kms->irq);
|
2016-05-18 17:36:03 +08:00
|
|
|
pm_runtime_put_sync(dev);
|
|
|
|
if (ret < 0) {
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(dev, "failed to install IRQ handler\n");
|
2018-06-28 02:35:28 +08:00
|
|
|
goto err_msm_uninit;
|
2016-05-18 17:36:03 +08: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-27 00:44:06 +08:00
|
|
|
}
|
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
ret = drm_dev_register(ddev, 0);
|
|
|
|
if (ret)
|
2018-06-28 02:35:28 +08:00
|
|
|
goto err_msm_uninit;
|
2016-05-02 13:35:54 +08:00
|
|
|
|
2021-09-15 01:48:31 +08:00
|
|
|
if (kms) {
|
|
|
|
ret = msm_disp_snapshot_init(ddev);
|
|
|
|
if (ret)
|
|
|
|
DRM_DEV_ERROR(dev, "msm_disp_snapshot_init failed ret = %d\n", ret);
|
|
|
|
}
|
2016-05-02 13:35:54 +08:00
|
|
|
drm_mode_config_reset(ddev);
|
2014-11-09 02:21:06 +08:00
|
|
|
|
2015-07-13 14:42:07 +08:00
|
|
|
#ifdef CONFIG_DRM_FBDEV_EMULATION
|
2018-12-04 23:16:58 +08:00
|
|
|
if (kms && fbdev)
|
2016-05-02 13:35:54 +08:00
|
|
|
priv->fbdev = msm_fbdev_init(ddev);
|
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-27 00:44:06 +08:00
|
|
|
#endif
|
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
ret = msm_debugfs_late_init(ddev);
|
2014-05-31 02:47:38 +08:00
|
|
|
if (ret)
|
2018-06-28 02:35:28 +08:00
|
|
|
goto err_msm_uninit;
|
2014-05-31 02:47:38 +08:00
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
drm_kms_helper_poll_init(ddev);
|
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-27 00:44:06 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2018-06-28 02:35:28 +08:00
|
|
|
err_msm_uninit:
|
2016-05-02 13:35:54 +08:00
|
|
|
msm_drm_uninit(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-27 00:44:06 +08:00
|
|
|
return ret;
|
2018-06-28 02:35:28 +08:00
|
|
|
err_destroy_mdss:
|
|
|
|
if (mdss && mdss->funcs)
|
|
|
|
mdss->funcs->destroy(ddev);
|
|
|
|
err_free_priv:
|
|
|
|
kfree(priv);
|
2018-09-26 19:48:59 +08:00
|
|
|
err_put_drm_dev:
|
|
|
|
drm_dev_put(ddev);
|
2021-03-26 05:28:22 +08:00
|
|
|
platform_set_drvdata(pdev, NULL);
|
2018-06-28 02:35:28 +08:00
|
|
|
return ret;
|
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-27 00:44:06 +08:00
|
|
|
}
|
|
|
|
|
2016-05-02 13:35:54 +08:00
|
|
|
/*
|
|
|
|
* DRM operations:
|
|
|
|
*/
|
|
|
|
|
2013-07-20 00:59:32 +08:00
|
|
|
static void load_gpu(struct drm_device *dev)
|
|
|
|
{
|
2014-07-11 23:59:22 +08:00
|
|
|
static DEFINE_MUTEX(init_lock);
|
2013-07-20 00:59:32 +08:00
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
|
|
|
|
2014-07-11 23:59:22 +08:00
|
|
|
mutex_lock(&init_lock);
|
|
|
|
|
2014-09-06 01:30:27 +08:00
|
|
|
if (!priv->gpu)
|
|
|
|
priv->gpu = adreno_load_gpu(dev);
|
2013-07-20 00:59:32 +08:00
|
|
|
|
2014-07-11 23:59:22 +08:00
|
|
|
mutex_unlock(&init_lock);
|
2013-07-20 00:59:32 +08:00
|
|
|
}
|
|
|
|
|
2017-10-21 01:06:57 +08:00
|
|
|
static int context_init(struct drm_device *dev, struct drm_file *file)
|
2013-07-20 00:59:32 +08:00
|
|
|
{
|
2021-10-01 01:43:20 +08:00
|
|
|
static atomic_t ident = ATOMIC_INIT(0);
|
2019-05-08 02:02:07 +08:00
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
2013-07-20 00:59:32 +08:00
|
|
|
struct msm_file_private *ctx;
|
|
|
|
|
|
|
|
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
|
|
|
|
if (!ctx)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2021-09-27 02:56:58 +08:00
|
|
|
INIT_LIST_HEAD(&ctx->submitqueues);
|
|
|
|
rwlock_init(&ctx->queuelock);
|
|
|
|
|
2020-08-18 06:01:36 +08:00
|
|
|
kref_init(&ctx->ref);
|
2017-10-21 01:06:57 +08:00
|
|
|
msm_submitqueue_init(dev, ctx);
|
2017-10-21 01:06:55 +08:00
|
|
|
|
2020-08-18 06:01:45 +08:00
|
|
|
ctx->aspace = msm_gpu_create_private_address_space(priv->gpu, current);
|
2013-07-20 00:59:32 +08:00
|
|
|
file->driver_priv = ctx;
|
|
|
|
|
2021-10-01 01:43:20 +08:00
|
|
|
ctx->seqno = atomic_inc_return(&ident);
|
|
|
|
|
2013-07-20 00:59:32 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-10-21 01:06:55 +08:00
|
|
|
static int msm_open(struct drm_device *dev, struct drm_file *file)
|
|
|
|
{
|
|
|
|
/* For now, load gpu on open.. to avoid the requirement of having
|
|
|
|
* firmware in the initrd.
|
|
|
|
*/
|
|
|
|
load_gpu(dev);
|
|
|
|
|
2017-10-21 01:06:57 +08:00
|
|
|
return context_init(dev, file);
|
2017-10-21 01:06:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void context_close(struct msm_file_private *ctx)
|
|
|
|
{
|
|
|
|
msm_submitqueue_close(ctx);
|
2020-08-18 06:01:36 +08:00
|
|
|
msm_file_private_put(ctx);
|
2017-10-21 01:06:55 +08:00
|
|
|
}
|
|
|
|
|
2017-03-08 22:12:46 +08:00
|
|
|
static void msm_postclose(struct drm_device *dev, struct drm_file *file)
|
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-27 00:44:06 +08:00
|
|
|
{
|
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
2013-07-20 00:59:32 +08:00
|
|
|
struct msm_file_private *ctx = file->driver_priv;
|
|
|
|
|
|
|
|
mutex_lock(&dev->struct_mutex);
|
|
|
|
if (ctx == priv->lastctx)
|
|
|
|
priv->lastctx = NULL;
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
2017-10-21 01:06:55 +08:00
|
|
|
context_close(ctx);
|
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-27 00:44:06 +08:00
|
|
|
}
|
|
|
|
|
2020-01-23 21:59:34 +08:00
|
|
|
int msm_crtc_enable_vblank(struct drm_crtc *crtc)
|
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-27 00:44:06 +08:00
|
|
|
{
|
2020-01-23 21:59:34 +08:00
|
|
|
struct drm_device *dev = crtc->dev;
|
|
|
|
unsigned int pipe = crtc->index;
|
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-27 00:44:06 +08:00
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
|
|
|
struct msm_kms *kms = priv->kms;
|
|
|
|
if (!kms)
|
|
|
|
return -ENXIO;
|
2021-05-01 03:30:59 +08:00
|
|
|
drm_dbg_vbl(dev, "crtc=%u", pipe);
|
2015-09-25 00:35:31 +08:00
|
|
|
return vblank_ctrl_queue_work(priv, pipe, true);
|
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-27 00:44:06 +08:00
|
|
|
}
|
|
|
|
|
2020-01-23 21:59:34 +08:00
|
|
|
void msm_crtc_disable_vblank(struct drm_crtc *crtc)
|
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-27 00:44:06 +08:00
|
|
|
{
|
2020-01-23 21:59:34 +08:00
|
|
|
struct drm_device *dev = crtc->dev;
|
|
|
|
unsigned int pipe = crtc->index;
|
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-27 00:44:06 +08:00
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
|
|
|
struct msm_kms *kms = priv->kms;
|
|
|
|
if (!kms)
|
|
|
|
return;
|
2021-05-01 03:30:59 +08:00
|
|
|
drm_dbg_vbl(dev, "crtc=%u", pipe);
|
2015-09-25 00:35:31 +08:00
|
|
|
vblank_ctrl_queue_work(priv, pipe, false);
|
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-27 00:44:06 +08:00
|
|
|
}
|
|
|
|
|
2013-07-20 00:59:32 +08:00
|
|
|
/*
|
|
|
|
* DRM ioctls:
|
|
|
|
*/
|
|
|
|
|
|
|
|
static int msm_ioctl_get_param(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
|
|
|
struct drm_msm_param *args = data;
|
|
|
|
struct msm_gpu *gpu;
|
|
|
|
|
|
|
|
/* for now, we just have 3d pipe.. eventually this would need to
|
|
|
|
* be more clever to dispatch to appropriate gpu module:
|
|
|
|
*/
|
|
|
|
if (args->pipe != MSM_PIPE_3D0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
gpu = priv->gpu;
|
|
|
|
|
|
|
|
if (!gpu)
|
|
|
|
return -ENXIO;
|
|
|
|
|
|
|
|
return gpu->funcs->get_param(gpu, args->param, &args->value);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int msm_ioctl_gem_new(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_msm_gem_new *args = data;
|
2014-03-03 22:42:33 +08:00
|
|
|
|
|
|
|
if (args->flags & ~MSM_BO_FLAGS) {
|
|
|
|
DRM_ERROR("invalid flags: %08x\n", args->flags);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2013-07-20 00:59:32 +08:00
|
|
|
return msm_gem_new_handle(dev, file, args->size,
|
2018-11-08 06:35:52 +08:00
|
|
|
args->flags, &args->handle, NULL);
|
2013-07-20 00:59:32 +08:00
|
|
|
}
|
|
|
|
|
2015-05-11 23:50:03 +08:00
|
|
|
static inline ktime_t to_ktime(struct drm_msm_timespec timeout)
|
|
|
|
{
|
|
|
|
return ktime_set(timeout.tv_sec, timeout.tv_nsec);
|
|
|
|
}
|
2013-07-20 00:59:32 +08:00
|
|
|
|
|
|
|
static int msm_ioctl_gem_cpu_prep(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_msm_gem_cpu_prep *args = data;
|
|
|
|
struct drm_gem_object *obj;
|
2015-05-11 23:50:03 +08:00
|
|
|
ktime_t timeout = to_ktime(args->timeout);
|
2013-07-20 00:59:32 +08:00
|
|
|
int ret;
|
|
|
|
|
2014-03-03 22:42:33 +08:00
|
|
|
if (args->op & ~MSM_PREP_FLAGS) {
|
|
|
|
DRM_ERROR("invalid op: %08x\n", args->op);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-05-09 18:04:54 +08:00
|
|
|
obj = drm_gem_object_lookup(file, args->handle);
|
2013-07-20 00:59:32 +08:00
|
|
|
if (!obj)
|
|
|
|
return -ENOENT;
|
|
|
|
|
2015-05-11 23:50:03 +08:00
|
|
|
ret = msm_gem_cpu_prep(obj, args->op, &timeout);
|
2013-07-20 00:59:32 +08:00
|
|
|
|
2020-05-15 17:51:04 +08:00
|
|
|
drm_gem_object_put(obj);
|
2013-07-20 00:59:32 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int msm_ioctl_gem_cpu_fini(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_msm_gem_cpu_fini *args = data;
|
|
|
|
struct drm_gem_object *obj;
|
|
|
|
int ret;
|
|
|
|
|
2016-05-09 18:04:54 +08:00
|
|
|
obj = drm_gem_object_lookup(file, args->handle);
|
2013-07-20 00:59:32 +08:00
|
|
|
if (!obj)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
ret = msm_gem_cpu_fini(obj);
|
|
|
|
|
2020-05-15 17:51:04 +08:00
|
|
|
drm_gem_object_put(obj);
|
2013-07-20 00:59:32 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-05-09 04:35:01 +08:00
|
|
|
static int msm_ioctl_gem_info_iova(struct drm_device *dev,
|
2020-08-18 06:01:40 +08:00
|
|
|
struct drm_file *file, struct drm_gem_object *obj,
|
|
|
|
uint64_t *iova)
|
2017-05-09 04:35:01 +08:00
|
|
|
{
|
2021-01-03 04:24:37 +08:00
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
2020-08-18 06:01:40 +08:00
|
|
|
struct msm_file_private *ctx = file->driver_priv;
|
2017-05-09 04:35:01 +08:00
|
|
|
|
2021-01-03 04:24:37 +08:00
|
|
|
if (!priv->gpu)
|
2017-05-09 04:35:01 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2018-11-08 06:35:50 +08:00
|
|
|
/*
|
|
|
|
* Don't pin the memory here - just get an address so that userspace can
|
|
|
|
* be productive
|
|
|
|
*/
|
2020-08-18 06:01:40 +08:00
|
|
|
return msm_gem_get_iova(obj, ctx->aspace, iova);
|
2017-05-09 04:35:01 +08:00
|
|
|
}
|
|
|
|
|
2013-07-20 00:59:32 +08:00
|
|
|
static int msm_ioctl_gem_info(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_msm_gem_info *args = data;
|
|
|
|
struct drm_gem_object *obj;
|
2018-11-29 23:27:22 +08:00
|
|
|
struct msm_gem_object *msm_obj;
|
|
|
|
int i, ret = 0;
|
2013-07-20 00:59:32 +08:00
|
|
|
|
2018-11-29 22:54:42 +08:00
|
|
|
if (args->pad)
|
2013-07-20 00:59:32 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2018-11-29 22:54:42 +08:00
|
|
|
switch (args->info) {
|
|
|
|
case MSM_INFO_GET_OFFSET:
|
|
|
|
case MSM_INFO_GET_IOVA:
|
|
|
|
/* value returned as immediate, not pointer, so len==0: */
|
|
|
|
if (args->len)
|
|
|
|
return -EINVAL;
|
|
|
|
break;
|
2018-11-29 23:27:22 +08:00
|
|
|
case MSM_INFO_SET_NAME:
|
|
|
|
case MSM_INFO_GET_NAME:
|
|
|
|
break;
|
2018-11-29 22:54:42 +08:00
|
|
|
default:
|
2013-07-20 00:59:32 +08:00
|
|
|
return -EINVAL;
|
2018-11-29 22:54:42 +08:00
|
|
|
}
|
2013-07-20 00:59:32 +08:00
|
|
|
|
2016-05-09 18:04:54 +08:00
|
|
|
obj = drm_gem_object_lookup(file, args->handle);
|
2013-07-20 00:59:32 +08:00
|
|
|
if (!obj)
|
|
|
|
return -ENOENT;
|
|
|
|
|
2018-11-29 23:27:22 +08:00
|
|
|
msm_obj = to_msm_bo(obj);
|
2017-05-09 04:35:01 +08:00
|
|
|
|
2018-11-29 22:54:42 +08:00
|
|
|
switch (args->info) {
|
|
|
|
case MSM_INFO_GET_OFFSET:
|
|
|
|
args->value = msm_gem_mmap_offset(obj);
|
|
|
|
break;
|
|
|
|
case MSM_INFO_GET_IOVA:
|
2020-08-18 06:01:40 +08:00
|
|
|
ret = msm_ioctl_gem_info_iova(dev, file, obj, &args->value);
|
2018-11-29 22:54:42 +08:00
|
|
|
break;
|
2018-11-29 23:27:22 +08:00
|
|
|
case MSM_INFO_SET_NAME:
|
|
|
|
/* length check should leave room for terminating null: */
|
|
|
|
if (args->len >= sizeof(msm_obj->name)) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
2019-02-14 15:19:27 +08:00
|
|
|
if (copy_from_user(msm_obj->name, u64_to_user_ptr(args->value),
|
2019-02-20 02:40:19 +08:00
|
|
|
args->len)) {
|
|
|
|
msm_obj->name[0] = '\0';
|
2019-02-14 15:19:27 +08:00
|
|
|
ret = -EFAULT;
|
2019-02-20 02:40:19 +08:00
|
|
|
break;
|
|
|
|
}
|
2018-11-29 23:27:22 +08:00
|
|
|
msm_obj->name[args->len] = '\0';
|
|
|
|
for (i = 0; i < args->len; i++) {
|
|
|
|
if (!isprint(msm_obj->name[i])) {
|
|
|
|
msm_obj->name[i] = '\0';
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case MSM_INFO_GET_NAME:
|
|
|
|
if (args->value && (args->len < strlen(msm_obj->name))) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
args->len = strlen(msm_obj->name);
|
|
|
|
if (args->value) {
|
2019-02-14 15:19:27 +08:00
|
|
|
if (copy_to_user(u64_to_user_ptr(args->value),
|
|
|
|
msm_obj->name, args->len))
|
|
|
|
ret = -EFAULT;
|
2018-11-29 23:27:22 +08:00
|
|
|
}
|
|
|
|
break;
|
2017-05-09 04:35:01 +08:00
|
|
|
}
|
2013-07-20 00:59:32 +08:00
|
|
|
|
2020-05-15 17:51:04 +08:00
|
|
|
drm_gem_object_put(obj);
|
2013-07-20 00:59:32 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int msm_ioctl_wait_fence(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
2016-03-16 05:22:13 +08:00
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
2013-07-20 00:59:32 +08:00
|
|
|
struct drm_msm_wait_fence *args = data;
|
2015-05-11 23:50:03 +08:00
|
|
|
ktime_t timeout = to_ktime(args->timeout);
|
2017-10-21 01:06:57 +08:00
|
|
|
struct msm_gpu_submitqueue *queue;
|
|
|
|
struct msm_gpu *gpu = priv->gpu;
|
2021-07-28 09:06:12 +08:00
|
|
|
struct dma_fence *fence;
|
2017-10-21 01:06:57 +08:00
|
|
|
int ret;
|
2014-03-03 22:42:33 +08:00
|
|
|
|
|
|
|
if (args->pad) {
|
|
|
|
DRM_ERROR("invalid pad: %08x\n", args->pad);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2017-10-21 01:06:57 +08:00
|
|
|
if (!gpu)
|
2016-03-16 05:22:13 +08:00
|
|
|
return 0;
|
|
|
|
|
2017-10-21 01:06:57 +08:00
|
|
|
queue = msm_submitqueue_get(file->driver_priv, args->queueid);
|
|
|
|
if (!queue)
|
|
|
|
return -ENOENT;
|
|
|
|
|
2021-07-28 09:06:12 +08:00
|
|
|
/*
|
|
|
|
* Map submitqueue scoped "seqno" (which is actually an idr key)
|
|
|
|
* back to underlying dma-fence
|
|
|
|
*
|
|
|
|
* The fence is removed from the fence_idr when the submit is
|
|
|
|
* retired, so if the fence is not found it means there is nothing
|
|
|
|
* to wait for
|
|
|
|
*/
|
|
|
|
ret = mutex_lock_interruptible(&queue->lock);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
fence = idr_find(&queue->fence_idr, args->fence);
|
|
|
|
if (fence)
|
|
|
|
fence = dma_fence_get_rcu(fence);
|
|
|
|
mutex_unlock(&queue->lock);
|
|
|
|
|
|
|
|
if (!fence)
|
|
|
|
return 0;
|
2017-10-21 01:06:57 +08:00
|
|
|
|
2021-07-28 09:06:12 +08:00
|
|
|
ret = dma_fence_wait_timeout(fence, true, timeout_to_jiffies(&timeout));
|
|
|
|
if (ret == 0) {
|
|
|
|
ret = -ETIMEDOUT;
|
|
|
|
} else if (ret != -ERESTARTSYS) {
|
|
|
|
ret = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
dma_fence_put(fence);
|
2017-10-21 01:06:57 +08:00
|
|
|
msm_submitqueue_put(queue);
|
2021-07-28 09:06:12 +08:00
|
|
|
|
2017-10-21 01:06:57 +08:00
|
|
|
return ret;
|
2013-07-20 00:59:32 +08:00
|
|
|
}
|
|
|
|
|
2016-05-18 03:44:49 +08:00
|
|
|
static int msm_ioctl_gem_madvise(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_msm_gem_madvise *args = data;
|
|
|
|
struct drm_gem_object *obj;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
switch (args->madv) {
|
|
|
|
case MSM_MADV_DONTNEED:
|
|
|
|
case MSM_MADV_WILLNEED:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
obj = drm_gem_object_lookup(file, args->handle);
|
|
|
|
if (!obj) {
|
2020-10-24 00:51:22 +08:00
|
|
|
return -ENOENT;
|
2016-05-18 03:44:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ret = msm_gem_madvise(obj, args->madv);
|
|
|
|
if (ret >= 0) {
|
|
|
|
args->retained = ret;
|
|
|
|
ret = 0;
|
|
|
|
}
|
|
|
|
|
2020-10-24 00:51:22 +08:00
|
|
|
drm_gem_object_put(obj);
|
2016-05-18 03:44:49 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-10-21 01:06:55 +08:00
|
|
|
|
|
|
|
static int msm_ioctl_submitqueue_new(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_msm_submitqueue *args = data;
|
|
|
|
|
|
|
|
if (args->flags & ~MSM_SUBMITQUEUE_FLAGS)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2017-10-21 01:06:57 +08:00
|
|
|
return msm_submitqueue_create(dev, file->driver_priv, args->prio,
|
2017-10-21 01:06:55 +08:00
|
|
|
args->flags, &args->id);
|
|
|
|
}
|
|
|
|
|
2019-03-23 04:21:22 +08:00
|
|
|
static int msm_ioctl_submitqueue_query(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
return msm_submitqueue_query(dev, file->driver_priv, data);
|
|
|
|
}
|
2017-10-21 01:06:55 +08:00
|
|
|
|
|
|
|
static int msm_ioctl_submitqueue_close(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
u32 id = *(u32 *) data;
|
|
|
|
|
|
|
|
return msm_submitqueue_remove(file->driver_priv, id);
|
|
|
|
}
|
|
|
|
|
2013-07-20 00:59:32 +08:00
|
|
|
static const struct drm_ioctl_desc msm_ioctls[] = {
|
2019-05-27 16:17:35 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(MSM_GET_PARAM, msm_ioctl_get_param, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(MSM_GEM_NEW, msm_ioctl_gem_new, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(MSM_GEM_INFO, msm_ioctl_gem_info, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(MSM_GEM_CPU_PREP, msm_ioctl_gem_cpu_prep, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(MSM_GEM_CPU_FINI, msm_ioctl_gem_cpu_fini, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(MSM_GEM_SUBMIT, msm_ioctl_gem_submit, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(MSM_WAIT_FENCE, msm_ioctl_wait_fence, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(MSM_GEM_MADVISE, msm_ioctl_gem_madvise, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_NEW, msm_ioctl_submitqueue_new, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_CLOSE, msm_ioctl_submitqueue_close, DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query, DRM_RENDER_ALLOW),
|
2013-07-20 00:59:32 +08:00
|
|
|
};
|
|
|
|
|
2021-07-06 16:47:53 +08:00
|
|
|
DEFINE_DRM_GEM_FOPS(fops);
|
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-27 00:44:06 +08:00
|
|
|
|
2020-11-04 18:04:24 +08:00
|
|
|
static const struct drm_driver msm_driver = {
|
2019-01-29 18:42:46 +08:00
|
|
|
.driver_features = DRIVER_GEM |
|
2013-09-29 00:01:25 +08:00
|
|
|
DRIVER_RENDER |
|
2015-06-04 22:12:22 +08:00
|
|
|
DRIVER_ATOMIC |
|
2020-01-24 07:57:10 +08:00
|
|
|
DRIVER_MODESET |
|
|
|
|
DRIVER_SYNCOBJ,
|
2013-07-20 00:59:32 +08:00
|
|
|
.open = msm_open,
|
2017-03-08 22:12:46 +08:00
|
|
|
.postclose = msm_postclose,
|
2017-12-06 02:24:59 +08:00
|
|
|
.lastclose = drm_fb_helper_lastclose,
|
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-27 00:44:06 +08:00
|
|
|
.dumb_create = msm_gem_dumb_create,
|
|
|
|
.dumb_map_offset = msm_gem_dumb_map_offset,
|
2013-09-28 23:28:35 +08:00
|
|
|
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
|
|
|
|
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
|
|
|
|
.gem_prime_import_sg_table = msm_gem_prime_import_sg_table,
|
2021-07-06 16:47:53 +08:00
|
|
|
.gem_prime_mmap = drm_gem_prime_mmap,
|
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-27 00:44:06 +08:00
|
|
|
#ifdef CONFIG_DEBUG_FS
|
|
|
|
.debugfs_init = msm_debugfs_init,
|
|
|
|
#endif
|
2013-07-20 00:59:32 +08:00
|
|
|
.ioctls = msm_ioctls,
|
2017-05-09 04:34:59 +08:00
|
|
|
.num_ioctls = ARRAY_SIZE(msm_ioctls),
|
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-27 00:44:06 +08:00
|
|
|
.fops = &fops,
|
|
|
|
.name = "msm",
|
|
|
|
.desc = "MSM Snapdragon DRM",
|
|
|
|
.date = "20130625",
|
2016-06-02 02:02:02 +08:00
|
|
|
.major = MSM_VERSION_MAJOR,
|
|
|
|
.minor = MSM_VERSION_MINOR,
|
|
|
|
.patchlevel = MSM_VERSION_PATCHLEVEL,
|
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-27 00:44:06 +08:00
|
|
|
};
|
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
static int __maybe_unused msm_runtime_suspend(struct 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-27 00:44:06 +08:00
|
|
|
{
|
|
|
|
struct drm_device *ddev = dev_get_drvdata(dev);
|
2018-05-29 03:53:38 +08:00
|
|
|
struct msm_drm_private *priv = ddev->dev_private;
|
2020-06-18 22:01:24 +08:00
|
|
|
struct msm_mdss *mdss = priv->mdss;
|
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-27 00:44:06 +08:00
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
DBG("");
|
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-27 00:44:06 +08:00
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
if (mdss && mdss->funcs)
|
|
|
|
return mdss->funcs->disable(mdss);
|
2018-05-29 03:53:38 +08: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-27 00:44:06 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
static int __maybe_unused msm_runtime_resume(struct 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-27 00:44:06 +08:00
|
|
|
{
|
|
|
|
struct drm_device *ddev = dev_get_drvdata(dev);
|
2018-05-29 03:53:38 +08:00
|
|
|
struct msm_drm_private *priv = ddev->dev_private;
|
2020-06-18 22:01:24 +08:00
|
|
|
struct msm_mdss *mdss = priv->mdss;
|
2018-06-28 03:24:17 +08:00
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
DBG("");
|
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-27 00:44:06 +08:00
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
if (mdss && mdss->funcs)
|
|
|
|
return mdss->funcs->enable(mdss);
|
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-27 00:44:06 +08:00
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
return 0;
|
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-27 00:44:06 +08:00
|
|
|
}
|
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
static int __maybe_unused msm_pm_suspend(struct device *dev)
|
drm/msm/mdp5: Set up runtime PM for MDSS
MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and
other sub-blocks. W.r.t device heirarchy, it's the parent of all these
devices. The power domain of this device is actually tied to the GDSC
hw. When any sub-device enables its PD, MDSS's PD is also enabled.
The suspend/resume ops enable the top level clocks that end at the MDSS
boundary. For now, we're letting them all be optional, since the child
devices anyway hold a ref to these clocks.
Until now, we'd called a runtime_get() during probe, which ensured that
the GDSC was always on. Now that we've set up runtime PM for the children
devices, we can get rid of this hack.
Note: that the MDSS device is the platform_device in msm_drv.c. The
msm_runtime_suspend/resume ops call the funcs that enable/disable
the top level MDSS clocks. This is different from MDP4, where the
platform device created in msm_drv.c represents MDP4 itself. It would
have been nicer to hide these differences by adding new kms funcs, but
runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init
is called).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-07-28 18:47:07 +08:00
|
|
|
{
|
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
if (pm_runtime_suspended(dev))
|
|
|
|
return 0;
|
drm/msm/mdp5: Set up runtime PM for MDSS
MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and
other sub-blocks. W.r.t device heirarchy, it's the parent of all these
devices. The power domain of this device is actually tied to the GDSC
hw. When any sub-device enables its PD, MDSS's PD is also enabled.
The suspend/resume ops enable the top level clocks that end at the MDSS
boundary. For now, we're letting them all be optional, since the child
devices anyway hold a ref to these clocks.
Until now, we'd called a runtime_get() during probe, which ensured that
the GDSC was always on. Now that we've set up runtime PM for the children
devices, we can get rid of this hack.
Note: that the MDSS device is the platform_device in msm_drv.c. The
msm_runtime_suspend/resume ops call the funcs that enable/disable
the top level MDSS clocks. This is different from MDP4, where the
platform device created in msm_drv.c represents MDP4 itself. It would
have been nicer to hide these differences by adding new kms funcs, but
runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init
is called).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-07-28 18:47:07 +08:00
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
return msm_runtime_suspend(dev);
|
|
|
|
}
|
drm/msm/mdp5: Set up runtime PM for MDSS
MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and
other sub-blocks. W.r.t device heirarchy, it's the parent of all these
devices. The power domain of this device is actually tied to the GDSC
hw. When any sub-device enables its PD, MDSS's PD is also enabled.
The suspend/resume ops enable the top level clocks that end at the MDSS
boundary. For now, we're letting them all be optional, since the child
devices anyway hold a ref to these clocks.
Until now, we'd called a runtime_get() during probe, which ensured that
the GDSC was always on. Now that we've set up runtime PM for the children
devices, we can get rid of this hack.
Note: that the MDSS device is the platform_device in msm_drv.c. The
msm_runtime_suspend/resume ops call the funcs that enable/disable
the top level MDSS clocks. This is different from MDP4, where the
platform device created in msm_drv.c represents MDP4 itself. It would
have been nicer to hide these differences by adding new kms funcs, but
runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init
is called).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-07-28 18:47:07 +08:00
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
static int __maybe_unused msm_pm_resume(struct device *dev)
|
|
|
|
{
|
|
|
|
if (pm_runtime_suspended(dev))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return msm_runtime_resume(dev);
|
drm/msm/mdp5: Set up runtime PM for MDSS
MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and
other sub-blocks. W.r.t device heirarchy, it's the parent of all these
devices. The power domain of this device is actually tied to the GDSC
hw. When any sub-device enables its PD, MDSS's PD is also enabled.
The suspend/resume ops enable the top level clocks that end at the MDSS
boundary. For now, we're letting them all be optional, since the child
devices anyway hold a ref to these clocks.
Until now, we'd called a runtime_get() during probe, which ensured that
the GDSC was always on. Now that we've set up runtime PM for the children
devices, we can get rid of this hack.
Note: that the MDSS device is the platform_device in msm_drv.c. The
msm_runtime_suspend/resume ops call the funcs that enable/disable
the top level MDSS clocks. This is different from MDP4, where the
platform device created in msm_drv.c represents MDP4 itself. It would
have been nicer to hide these differences by adding new kms funcs, but
runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init
is called).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-07-28 18:47:07 +08:00
|
|
|
}
|
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
static int __maybe_unused msm_pm_prepare(struct device *dev)
|
drm/msm/mdp5: Set up runtime PM for MDSS
MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and
other sub-blocks. W.r.t device heirarchy, it's the parent of all these
devices. The power domain of this device is actually tied to the GDSC
hw. When any sub-device enables its PD, MDSS's PD is also enabled.
The suspend/resume ops enable the top level clocks that end at the MDSS
boundary. For now, we're letting them all be optional, since the child
devices anyway hold a ref to these clocks.
Until now, we'd called a runtime_get() during probe, which ensured that
the GDSC was always on. Now that we've set up runtime PM for the children
devices, we can get rid of this hack.
Note: that the MDSS device is the platform_device in msm_drv.c. The
msm_runtime_suspend/resume ops call the funcs that enable/disable
the top level MDSS clocks. This is different from MDP4, where the
platform device created in msm_drv.c represents MDP4 itself. It would
have been nicer to hide these differences by adding new kms funcs, but
runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init
is called).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-07-28 18:47:07 +08:00
|
|
|
{
|
|
|
|
struct drm_device *ddev = dev_get_drvdata(dev);
|
2021-03-20 19:56:03 +08:00
|
|
|
struct msm_drm_private *priv = ddev ? ddev->dev_private : NULL;
|
|
|
|
|
|
|
|
if (!priv || !priv->kms)
|
|
|
|
return 0;
|
drm/msm/mdp5: Set up runtime PM for MDSS
MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and
other sub-blocks. W.r.t device heirarchy, it's the parent of all these
devices. The power domain of this device is actually tied to the GDSC
hw. When any sub-device enables its PD, MDSS's PD is also enabled.
The suspend/resume ops enable the top level clocks that end at the MDSS
boundary. For now, we're letting them all be optional, since the child
devices anyway hold a ref to these clocks.
Until now, we'd called a runtime_get() during probe, which ensured that
the GDSC was always on. Now that we've set up runtime PM for the children
devices, we can get rid of this hack.
Note: that the MDSS device is the platform_device in msm_drv.c. The
msm_runtime_suspend/resume ops call the funcs that enable/disable
the top level MDSS clocks. This is different from MDP4, where the
platform device created in msm_drv.c represents MDP4 itself. It would
have been nicer to hide these differences by adding new kms funcs, but
runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init
is called).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-07-28 18:47:07 +08:00
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
return drm_mode_config_helper_suspend(ddev);
|
|
|
|
}
|
drm/msm/mdp5: Set up runtime PM for MDSS
MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and
other sub-blocks. W.r.t device heirarchy, it's the parent of all these
devices. The power domain of this device is actually tied to the GDSC
hw. When any sub-device enables its PD, MDSS's PD is also enabled.
The suspend/resume ops enable the top level clocks that end at the MDSS
boundary. For now, we're letting them all be optional, since the child
devices anyway hold a ref to these clocks.
Until now, we'd called a runtime_get() during probe, which ensured that
the GDSC was always on. Now that we've set up runtime PM for the children
devices, we can get rid of this hack.
Note: that the MDSS device is the platform_device in msm_drv.c. The
msm_runtime_suspend/resume ops call the funcs that enable/disable
the top level MDSS clocks. This is different from MDP4, where the
platform device created in msm_drv.c represents MDP4 itself. It would
have been nicer to hide these differences by adding new kms funcs, but
runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init
is called).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-07-28 18:47:07 +08:00
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
static void __maybe_unused msm_pm_complete(struct device *dev)
|
|
|
|
{
|
|
|
|
struct drm_device *ddev = dev_get_drvdata(dev);
|
2021-03-20 19:56:03 +08:00
|
|
|
struct msm_drm_private *priv = ddev ? ddev->dev_private : NULL;
|
|
|
|
|
|
|
|
if (!priv || !priv->kms)
|
|
|
|
return;
|
drm/msm/mdp5: Set up runtime PM for MDSS
MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and
other sub-blocks. W.r.t device heirarchy, it's the parent of all these
devices. The power domain of this device is actually tied to the GDSC
hw. When any sub-device enables its PD, MDSS's PD is also enabled.
The suspend/resume ops enable the top level clocks that end at the MDSS
boundary. For now, we're letting them all be optional, since the child
devices anyway hold a ref to these clocks.
Until now, we'd called a runtime_get() during probe, which ensured that
the GDSC was always on. Now that we've set up runtime PM for the children
devices, we can get rid of this hack.
Note: that the MDSS device is the platform_device in msm_drv.c. The
msm_runtime_suspend/resume ops call the funcs that enable/disable
the top level MDSS clocks. This is different from MDP4, where the
platform device created in msm_drv.c represents MDP4 itself. It would
have been nicer to hide these differences by adding new kms funcs, but
runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init
is called).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-07-28 18:47:07 +08:00
|
|
|
|
2020-06-18 22:01:24 +08:00
|
|
|
drm_mode_config_helper_resume(ddev);
|
drm/msm/mdp5: Set up runtime PM for MDSS
MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and
other sub-blocks. W.r.t device heirarchy, it's the parent of all these
devices. The power domain of this device is actually tied to the GDSC
hw. When any sub-device enables its PD, MDSS's PD is also enabled.
The suspend/resume ops enable the top level clocks that end at the MDSS
boundary. For now, we're letting them all be optional, since the child
devices anyway hold a ref to these clocks.
Until now, we'd called a runtime_get() during probe, which ensured that
the GDSC was always on. Now that we've set up runtime PM for the children
devices, we can get rid of this hack.
Note: that the MDSS device is the platform_device in msm_drv.c. The
msm_runtime_suspend/resume ops call the funcs that enable/disable
the top level MDSS clocks. This is different from MDP4, where the
platform device created in msm_drv.c represents MDP4 itself. It would
have been nicer to hide these differences by adding new kms funcs, but
runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init
is called).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-07-28 18:47:07 +08: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-27 00:44:06 +08:00
|
|
|
static const struct dev_pm_ops msm_pm_ops = {
|
|
|
|
SET_SYSTEM_SLEEP_PM_OPS(msm_pm_suspend, msm_pm_resume)
|
drm/msm/mdp5: Set up runtime PM for MDSS
MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and
other sub-blocks. W.r.t device heirarchy, it's the parent of all these
devices. The power domain of this device is actually tied to the GDSC
hw. When any sub-device enables its PD, MDSS's PD is also enabled.
The suspend/resume ops enable the top level clocks that end at the MDSS
boundary. For now, we're letting them all be optional, since the child
devices anyway hold a ref to these clocks.
Until now, we'd called a runtime_get() during probe, which ensured that
the GDSC was always on. Now that we've set up runtime PM for the children
devices, we can get rid of this hack.
Note: that the MDSS device is the platform_device in msm_drv.c. The
msm_runtime_suspend/resume ops call the funcs that enable/disable
the top level MDSS clocks. This is different from MDP4, where the
platform device created in msm_drv.c represents MDP4 itself. It would
have been nicer to hide these differences by adding new kms funcs, but
runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init
is called).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-07-28 18:47:07 +08:00
|
|
|
SET_RUNTIME_PM_OPS(msm_runtime_suspend, msm_runtime_resume, NULL)
|
2020-06-18 22:01:24 +08:00
|
|
|
.prepare = msm_pm_prepare,
|
|
|
|
.complete = msm_pm_complete,
|
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-27 00:44:06 +08:00
|
|
|
};
|
|
|
|
|
2014-03-04 03:19:12 +08:00
|
|
|
/*
|
|
|
|
* Componentized driver support:
|
|
|
|
*/
|
|
|
|
|
2015-11-18 14:45:14 +08:00
|
|
|
/*
|
|
|
|
* NOTE: duplication of the same code as exynos or imx (or probably any other).
|
|
|
|
* so probably some room for some helpers
|
2014-03-04 03:19:12 +08:00
|
|
|
*/
|
|
|
|
static int compare_of(struct device *dev, void *data)
|
|
|
|
{
|
|
|
|
return dev->of_node == data;
|
|
|
|
}
|
2013-12-16 05:23:05 +08:00
|
|
|
|
2016-05-19 13:08:39 +08:00
|
|
|
/*
|
|
|
|
* Identify what components need to be added by parsing what remote-endpoints
|
|
|
|
* our MDP output ports are connected to. In the case of LVDS on MDP4, there
|
|
|
|
* is no external component that we need to add since LVDS is within MDP4
|
|
|
|
* itself.
|
|
|
|
*/
|
|
|
|
static int add_components_mdp(struct device *mdp_dev,
|
|
|
|
struct component_match **matchptr)
|
|
|
|
{
|
|
|
|
struct device_node *np = mdp_dev->of_node;
|
|
|
|
struct device_node *ep_node;
|
2016-06-06 16:15:34 +08:00
|
|
|
struct device *master_dev;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* on MDP4 based platforms, the MDP platform device is the component
|
|
|
|
* master that adds other display interface components to itself.
|
|
|
|
*
|
|
|
|
* on MDP5 based platforms, the MDSS platform device is the component
|
|
|
|
* master that adds MDP5 and other display interface components to
|
|
|
|
* itself.
|
|
|
|
*/
|
|
|
|
if (of_device_is_compatible(np, "qcom,mdp4"))
|
|
|
|
master_dev = mdp_dev;
|
|
|
|
else
|
|
|
|
master_dev = mdp_dev->parent;
|
2016-05-19 13:08:39 +08:00
|
|
|
|
|
|
|
for_each_endpoint_of_node(np, ep_node) {
|
|
|
|
struct device_node *intf;
|
|
|
|
struct of_endpoint ep;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = of_graph_parse_endpoint(ep_node, &ep);
|
|
|
|
if (ret) {
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(mdp_dev, "unable to parse port endpoint\n");
|
2016-05-19 13:08:39 +08:00
|
|
|
of_node_put(ep_node);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The LCDC/LVDS port on MDP4 is a speacial case where the
|
|
|
|
* remote-endpoint isn't a component that we need to add
|
|
|
|
*/
|
|
|
|
if (of_device_is_compatible(np, "qcom,mdp4") &&
|
2016-11-17 14:42:03 +08:00
|
|
|
ep.port == 0)
|
2016-05-19 13:08:39 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It's okay if some of the ports don't have a remote endpoint
|
|
|
|
* specified. It just means that the port isn't connected to
|
|
|
|
* any external interface.
|
|
|
|
*/
|
|
|
|
intf = of_graph_get_remote_port_parent(ep_node);
|
2016-11-17 14:42:03 +08:00
|
|
|
if (!intf)
|
2016-05-19 13:08:39 +08:00
|
|
|
continue;
|
|
|
|
|
2018-12-05 02:04:41 +08:00
|
|
|
if (of_device_is_available(intf))
|
|
|
|
drm_of_component_match_add(master_dev, matchptr,
|
|
|
|
compare_of, intf);
|
|
|
|
|
2016-05-19 13:08:39 +08:00
|
|
|
of_node_put(intf);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-06 16:15:34 +08:00
|
|
|
static int compare_name_mdp(struct device *dev, void *data)
|
|
|
|
{
|
|
|
|
return (strstr(dev_name(dev), "mdp") != NULL);
|
|
|
|
}
|
|
|
|
|
2021-03-17 10:56:34 +08:00
|
|
|
static int add_display_components(struct platform_device *pdev,
|
2016-05-19 13:03:57 +08:00
|
|
|
struct component_match **matchptr)
|
|
|
|
{
|
2016-06-06 16:15:34 +08:00
|
|
|
struct device *mdp_dev;
|
2021-03-17 10:56:34 +08:00
|
|
|
struct device *dev = &pdev->dev;
|
2016-06-06 16:15:34 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
/*
|
2018-06-28 03:26:09 +08:00
|
|
|
* MDP5/DPU based devices don't have a flat hierarchy. There is a top
|
|
|
|
* level parent: MDSS, and children: MDP5/DPU, DSI, HDMI, eDP etc.
|
|
|
|
* Populate the children devices, find the MDP5/DPU node, and then add
|
|
|
|
* the interfaces to our components list.
|
2016-06-06 16:15:34 +08:00
|
|
|
*/
|
2021-03-17 10:56:34 +08:00
|
|
|
switch (get_mdp_ver(pdev)) {
|
|
|
|
case KMS_MDP5:
|
|
|
|
case KMS_DPU:
|
2016-06-06 16:15:34 +08:00
|
|
|
ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
|
|
|
|
if (ret) {
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(dev, "failed to populate children devices\n");
|
2016-06-06 16:15:34 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
mdp_dev = device_find_child(dev, NULL, compare_name_mdp);
|
|
|
|
if (!mdp_dev) {
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(dev, "failed to find MDSS MDP node\n");
|
2016-06-06 16:15:34 +08:00
|
|
|
of_platform_depopulate(dev);
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
put_device(mdp_dev);
|
|
|
|
|
|
|
|
/* add the MDP component itself */
|
2016-10-19 18:28:27 +08:00
|
|
|
drm_of_component_match_add(dev, matchptr, compare_of,
|
|
|
|
mdp_dev->of_node);
|
2021-03-17 10:56:34 +08:00
|
|
|
break;
|
|
|
|
case KMS_MDP4:
|
2016-06-06 16:15:34 +08:00
|
|
|
/* MDP4 */
|
|
|
|
mdp_dev = dev;
|
2021-03-17 10:56:34 +08:00
|
|
|
break;
|
2016-06-06 16:15:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ret = add_components_mdp(mdp_dev, matchptr);
|
|
|
|
if (ret)
|
|
|
|
of_platform_depopulate(dev);
|
|
|
|
|
|
|
|
return ret;
|
2016-05-19 13:03:57 +08:00
|
|
|
}
|
|
|
|
|
2016-05-19 16:03:52 +08:00
|
|
|
/*
|
|
|
|
* We don't know what's the best binding to link the gpu with the drm device.
|
|
|
|
* Fow now, we just hunt for all the possible gpus that we support, and add them
|
|
|
|
* as components.
|
|
|
|
*/
|
|
|
|
static const struct of_device_id msm_gpu_match[] = {
|
2017-01-31 00:02:27 +08:00
|
|
|
{ .compatible = "qcom,adreno" },
|
2016-05-19 16:03:52 +08:00
|
|
|
{ .compatible = "qcom,adreno-3xx" },
|
2018-12-04 23:16:58 +08:00
|
|
|
{ .compatible = "amd,imageon" },
|
2016-05-19 16:03:52 +08:00
|
|
|
{ .compatible = "qcom,kgsl-3d0" },
|
|
|
|
{ },
|
|
|
|
};
|
|
|
|
|
2016-05-19 13:03:57 +08:00
|
|
|
static int add_gpu_components(struct device *dev,
|
|
|
|
struct component_match **matchptr)
|
|
|
|
{
|
2016-05-19 16:03:52 +08:00
|
|
|
struct device_node *np;
|
|
|
|
|
|
|
|
np = of_find_matching_node(NULL, msm_gpu_match);
|
|
|
|
if (!np)
|
|
|
|
return 0;
|
|
|
|
|
2019-06-27 02:00:15 +08:00
|
|
|
if (of_device_is_available(np))
|
|
|
|
drm_of_component_match_add(dev, matchptr, compare_of, np);
|
2016-05-19 16:03:52 +08:00
|
|
|
|
|
|
|
of_node_put(np);
|
|
|
|
|
|
|
|
return 0;
|
2016-05-19 13:03:57 +08:00
|
|
|
}
|
|
|
|
|
2014-04-19 18:20:42 +08:00
|
|
|
static int msm_drm_bind(struct device *dev)
|
|
|
|
{
|
2016-05-02 13:35:54 +08:00
|
|
|
return msm_drm_init(dev, &msm_driver);
|
2014-04-19 18:20:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void msm_drm_unbind(struct device *dev)
|
|
|
|
{
|
2016-05-02 13:35:54 +08:00
|
|
|
msm_drm_uninit(dev);
|
2014-04-19 18:20:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct component_master_ops msm_drm_ops = {
|
|
|
|
.bind = msm_drm_bind,
|
|
|
|
.unbind = msm_drm_unbind,
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Platform driver:
|
|
|
|
*/
|
2014-03-04 03:19:12 +08:00
|
|
|
|
2014-04-19 18:20:42 +08:00
|
|
|
static int msm_pdev_probe(struct platform_device *pdev)
|
2014-03-04 03:19:12 +08:00
|
|
|
{
|
2014-04-19 18:20:42 +08:00
|
|
|
struct component_match *match = NULL;
|
2016-05-19 13:03:57 +08:00
|
|
|
int ret;
|
|
|
|
|
2018-12-04 23:16:58 +08:00
|
|
|
if (get_mdp_ver(pdev)) {
|
2021-03-17 10:56:34 +08:00
|
|
|
ret = add_display_components(pdev, &match);
|
2018-12-04 23:16:58 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2015-11-18 14:45:14 +08:00
|
|
|
|
2016-05-19 13:03:57 +08:00
|
|
|
ret = add_gpu_components(&pdev->dev, &match);
|
|
|
|
if (ret)
|
2019-06-18 04:12:51 +08:00
|
|
|
goto fail;
|
2014-03-04 03:19:12 +08:00
|
|
|
|
2016-11-08 02:31:30 +08:00
|
|
|
/* on all devices that I am aware of, iommu's which can map
|
|
|
|
* any address the cpu can see are used:
|
|
|
|
*/
|
|
|
|
ret = dma_set_mask_and_coherent(&pdev->dev, ~0);
|
|
|
|
if (ret)
|
2019-06-18 04:12:51 +08:00
|
|
|
goto fail;
|
|
|
|
|
|
|
|
ret = component_master_add_with_match(&pdev->dev, &msm_drm_ops, match);
|
|
|
|
if (ret)
|
|
|
|
goto fail;
|
2016-11-08 02:31:30 +08:00
|
|
|
|
2019-06-18 04:12:51 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
fail:
|
|
|
|
of_platform_depopulate(&pdev->dev);
|
|
|
|
return ret;
|
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-27 00:44:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int msm_pdev_remove(struct platform_device *pdev)
|
|
|
|
{
|
2014-03-04 03:19:12 +08:00
|
|
|
component_master_del(&pdev->dev, &msm_drm_ops);
|
2016-06-06 16:15:34 +08:00
|
|
|
of_platform_depopulate(&pdev->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-27 00:44:06 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-06-01 19:03:22 +08:00
|
|
|
static void msm_pdev_shutdown(struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
struct drm_device *drm = platform_get_drvdata(pdev);
|
drm/msm: fix shutdown hook in case GPU components failed to bind
If GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.
[ 66.617046] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 66.626066] Mem abort info:
[ 66.628939] ESR = 0x96000006
[ 66.632088] EC = 0x25: DABT (current EL), IL = 32 bits
[ 66.637542] SET = 0, FnV = 0
[ 66.640688] EA = 0, S1PTW = 0
[ 66.643924] Data abort info:
[ 66.646889] ISV = 0, ISS = 0x00000006
[ 66.650832] CM = 0, WnR = 0
[ 66.653890] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000107f81000
[ 66.660505] [0000000000000000] pgd=0000000100bb2003, p4d=0000000100bb2003, pud=0000000100897003, pmd=0000000000000000
[ 66.671398] Internal error: Oops: 96000006 [#1] PREEMPT SMP
[ 66.677115] Modules linked in:
[ 66.680261] CPU: 6 PID: 352 Comm: reboot Not tainted 5.11.0-rc2-00309-g79e3faa756b2 #38
[ 66.688473] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[ 66.695347] pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 66.701507] pc : msm_atomic_commit_tail+0x78/0x4e0
[ 66.706437] lr : commit_tail+0xa4/0x184
[ 66.710381] sp : ffff8000108f3af0
[ 66.713791] x29: ffff8000108f3af0 x28: ffff418c44337000
[ 66.719242] x27: 0000000000000000 x26: ffff418c40a24490
[ 66.724693] x25: ffffd3a842a4f1a0 x24: 0000000000000008
[ 66.730146] x23: ffffd3a84313f030 x22: ffff418c444ce000
[ 66.735598] x21: ffff418c408a4980 x20: 0000000000000000
[ 66.741049] x19: 0000000000000000 x18: ffff800010710fbc
[ 66.746500] x17: 000000000000000c x16: 0000000000000001
[ 66.751954] x15: 0000000000010008 x14: 0000000000000068
[ 66.757405] x13: 0000000000000001 x12: 0000000000000000
[ 66.762855] x11: 0000000000000001 x10: 00000000000009b0
[ 66.768306] x9 : ffffd3a843192000 x8 : ffff418c44337000
[ 66.773757] x7 : 0000000000000000 x6 : 00000000a401b34e
[ 66.779210] x5 : 00ffffffffffffff x4 : 0000000000000000
[ 66.784660] x3 : 0000000000000000 x2 : ffff418c444ce000
[ 66.790111] x1 : ffffd3a841dce530 x0 : ffff418c444cf000
[ 66.795563] Call trace:
[ 66.798075] msm_atomic_commit_tail+0x78/0x4e0
[ 66.802633] commit_tail+0xa4/0x184
[ 66.806217] drm_atomic_helper_commit+0x160/0x390
[ 66.811051] drm_atomic_commit+0x4c/0x60
[ 66.815082] drm_atomic_helper_disable_all+0x1f4/0x210
[ 66.820355] drm_atomic_helper_shutdown+0x80/0x130
[ 66.825276] msm_pdev_shutdown+0x14/0x20
[ 66.829303] platform_shutdown+0x28/0x40
[ 66.833330] device_shutdown+0x158/0x330
[ 66.837357] kernel_restart+0x40/0xa0
[ 66.841122] __do_sys_reboot+0x228/0x250
[ 66.845148] __arm64_sys_reboot+0x28/0x34
[ 66.849264] el0_svc_common.constprop.0+0x74/0x190
[ 66.854187] do_el0_svc+0x24/0x90
[ 66.857595] el0_svc+0x14/0x20
[ 66.860739] el0_sync_handler+0x1a4/0x1b0
[ 66.864858] el0_sync+0x174/0x180
[ 66.868269] Code: 1ac020a0 2a000273 eb02007f 54ffff01 (f9400285)
[ 66.874525] ---[ end trace 20dedb2a3229fec8 ]---
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display platform_driver")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-03-20 19:56:02 +08:00
|
|
|
struct msm_drm_private *priv = drm ? drm->dev_private : NULL;
|
|
|
|
|
|
|
|
if (!priv || !priv->kms)
|
|
|
|
return;
|
2020-06-01 19:03:22 +08:00
|
|
|
|
|
|
|
drm_atomic_helper_shutdown(drm);
|
|
|
|
}
|
|
|
|
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
static const struct of_device_id dt_match[] = {
|
2018-06-28 02:26:24 +08:00
|
|
|
{ .compatible = "qcom,mdp4", .data = (void *)KMS_MDP4 },
|
|
|
|
{ .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
|
2018-06-28 03:26:09 +08:00
|
|
|
{ .compatible = "qcom,sdm845-mdss", .data = (void *)KMS_DPU },
|
2019-11-25 19:59:27 +08:00
|
|
|
{ .compatible = "qcom,sc7180-mdss", .data = (void *)KMS_DPU },
|
2021-04-06 13:09:49 +08:00
|
|
|
{ .compatible = "qcom,sc7280-mdss", .data = (void *)KMS_DPU },
|
2021-03-29 20:00:50 +08:00
|
|
|
{ .compatible = "qcom,sm8150-mdss", .data = (void *)KMS_DPU },
|
|
|
|
{ .compatible = "qcom,sm8250-mdss", .data = (void *)KMS_DPU },
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
{}
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(of, dt_match);
|
|
|
|
|
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-27 00:44:06 +08:00
|
|
|
static struct platform_driver msm_platform_driver = {
|
|
|
|
.probe = msm_pdev_probe,
|
|
|
|
.remove = msm_pdev_remove,
|
2020-06-01 19:03:22 +08:00
|
|
|
.shutdown = msm_pdev_shutdown,
|
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-27 00:44:06 +08:00
|
|
|
.driver = {
|
|
|
|
.name = "msm",
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
.of_match_table = dt_match,
|
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-27 00:44:06 +08:00
|
|
|
.pm = &msm_pm_ops,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __init msm_drm_register(void)
|
|
|
|
{
|
2017-07-07 04:33:44 +08:00
|
|
|
if (!modeset)
|
|
|
|
return -EINVAL;
|
|
|
|
|
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-27 00:44:06 +08:00
|
|
|
DBG("init");
|
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 19:06:50 +08:00
|
|
|
msm_mdp_register();
|
2018-06-28 03:26:09 +08:00
|
|
|
msm_dpu_register();
|
2015-03-27 07:25:17 +08:00
|
|
|
msm_dsi_register();
|
2014-12-13 03:41:17 +08:00
|
|
|
msm_edp_register();
|
2016-02-23 05:08:35 +08:00
|
|
|
msm_hdmi_register();
|
2020-08-28 05:16:55 +08:00
|
|
|
msm_dp_register();
|
2014-09-06 01:06:37 +08:00
|
|
|
adreno_register();
|
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-27 00:44:06 +08:00
|
|
|
return platform_driver_register(&msm_platform_driver);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit msm_drm_unregister(void)
|
|
|
|
{
|
|
|
|
DBG("fini");
|
|
|
|
platform_driver_unregister(&msm_platform_driver);
|
2020-08-28 05:16:55 +08:00
|
|
|
msm_dp_unregister();
|
2016-02-23 05:08:35 +08:00
|
|
|
msm_hdmi_unregister();
|
2014-09-06 01:06:37 +08:00
|
|
|
adreno_unregister();
|
2014-12-13 03:41:17 +08:00
|
|
|
msm_edp_unregister();
|
2015-03-27 07:25:17 +08:00
|
|
|
msm_dsi_unregister();
|
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 19:06:50 +08:00
|
|
|
msm_mdp_unregister();
|
2018-06-28 03:26:09 +08:00
|
|
|
msm_dpu_unregister();
|
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-27 00:44:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
module_init(msm_drm_register);
|
|
|
|
module_exit(msm_drm_unregister);
|
|
|
|
|
|
|
|
MODULE_AUTHOR("Rob Clark <robdclark@gmail.com");
|
|
|
|
MODULE_DESCRIPTION("MSM DRM Driver");
|
|
|
|
MODULE_LICENSE("GPL");
|