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
|
|
|
/*
|
|
|
|
* Copyright (C) 2013 Red Hat
|
|
|
|
* Author: Rob Clark <robdclark@gmail.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/shmem_fs.h>
|
2013-09-28 23:28:35 +08:00
|
|
|
#include <linux/dma-buf.h>
|
2016-01-16 08:56:40 +08:00
|
|
|
#include <linux/pfn_t.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
|
|
|
|
2019-08-04 14:55:51 +08:00
|
|
|
#include <drm/drm_prime.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-16 03:35:08 +08:00
|
|
|
#include "msm_fence.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_gem.h"
|
2013-07-20 00:59:32 +08:00
|
|
|
#include "msm_gpu.h"
|
2013-11-17 01:56:06 +08:00
|
|
|
#include "msm_mmu.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
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
static void msm_gem_vunmap_locked(struct drm_gem_object *obj);
|
|
|
|
|
|
|
|
|
2013-11-17 01:56:06 +08:00
|
|
|
static dma_addr_t physaddr(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
struct msm_drm_private *priv = obj->dev->dev_private;
|
|
|
|
return (((dma_addr_t)msm_obj->vram_node->start) << PAGE_SHIFT) +
|
|
|
|
priv->vram.paddr;
|
|
|
|
}
|
|
|
|
|
2015-03-04 04:04:25 +08:00
|
|
|
static bool use_pages(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
return !msm_obj->vram_node;
|
|
|
|
}
|
|
|
|
|
drm/msm: Use the correct dma_sync calls in msm_gem
[subject was: drm/msm: shake fist angrily at dma-mapping]
So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
it falls appart with dma direct ops. The problem is that, depending on
display generation, we can have either set of dma ops (mdp4 and dpu have
iommu wired to mdss node, which maps to toplevel drm device, but mdp5
has iommu wired up to the mdp sub-node within mdss).
Fixes this splat on mdp5 devices:
Unable to handle kernel paging request at virtual address ffffffff80000000
Mem abort info:
ESR = 0x96000144
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000144
CM = 1, WnR = 1
swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000810e4000
[ffffffff80000000] pgd=0000000000000000
Internal error: Oops: 96000144 [#1] SMP
Modules linked in: btqcomsmd btqca bluetooth cfg80211 ecdh_generic ecc rfkill libarc4 panel_simple msm wcnss_ctrl qrtr_smd drm_kms_helper venus_enc venus_dec videobuf2_dma_sg videobuf2_memops drm venus_core ipv6 qrtr qcom_wcnss_pil v4l2_mem2mem qcom_sysmon videobuf2_v4l2 qmi_helpers videobuf2_common crct10dif_ce mdt_loader qcom_common videodev qcom_glink_smem remoteproc bmc150_accel_i2c bmc150_magn_i2c bmc150_accel_core bmc150_magn snd_soc_lpass_apq8016 snd_soc_msm8916_analog mms114 mc nf_defrag_ipv6 snd_soc_lpass_cpu snd_soc_apq8016_sbc industrialio_triggered_buffer kfifo_buf snd_soc_lpass_platform snd_soc_msm8916_digital drm_panel_orientation_quirks
CPU: 2 PID: 33 Comm: kworker/2:1 Not tainted 5.3.0-rc2 #1
Hardware name: Samsung Galaxy A5U (EUR) (DT)
Workqueue: events deferred_probe_work_func
pstate: 80000005 (Nzcv daif -PAN -UAO)
pc : __clean_dcache_area_poc+0x20/0x38
lr : arch_sync_dma_for_device+0x28/0x30
sp : ffff0000115736a0
x29: ffff0000115736a0 x28: 0000000000000001
x27: ffff800074830800 x26: ffff000011478000
x25: 0000000000000000 x24: 0000000000000001
x23: ffff000011478a98 x22: ffff800009fd1c10
x21: 0000000000000001 x20: ffff800075ad0a00
x19: 0000000000000000 x18: ffff0000112b2000
x17: 0000000000000000 x16: 0000000000000000
x15: 00000000fffffff0 x14: ffff000011455d70
x13: 0000000000000000 x12: 0000000000000028
x11: 0000000000000001 x10: ffff00001106c000
x9 : ffff7e0001d6b380 x8 : 0000000000001000
x7 : ffff7e0001d6b380 x6 : ffff7e0001d6b382
x5 : 0000000000000000 x4 : 0000000000001000
x3 : 000000000000003f x2 : 0000000000000040
x1 : ffffffff80001000 x0 : ffffffff80000000
Call trace:
__clean_dcache_area_poc+0x20/0x38
dma_direct_sync_sg_for_device+0xb8/0xe8
get_pages+0x22c/0x250 [msm]
msm_gem_get_and_pin_iova+0xdc/0x168 [msm]
...
Fixes the combination of two patches:
Fixes: 0036bc73ccbe (drm/msm: stop abusing dma_map/unmap for cache)
Fixes: 449fa54d6815 (dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device)
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Rob Clark <robdclark@chromium.org>
[seanpaul changed subject to something more desriptive]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730214633.17820-1-robdclark@gmail.com
2019-07-31 05:46:28 +08:00
|
|
|
/*
|
|
|
|
* Cache sync.. this is a bit over-complicated, to fit dma-mapping
|
|
|
|
* API. Really GPU cache is out of scope here (handled on cmdstream)
|
|
|
|
* and all we need to do is invalidate newly allocated pages before
|
|
|
|
* mapping to CPU as uncached/writecombine.
|
|
|
|
*
|
|
|
|
* On top of this, we have the added headache, that depending on
|
|
|
|
* display generation, the display's iommu may be wired up to either
|
|
|
|
* the toplevel drm device (mdss), or to the mdp sub-node, meaning
|
|
|
|
* that here we either have dma-direct or iommu ops.
|
|
|
|
*
|
|
|
|
* Let this be a cautionary tail of abstraction gone wrong.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void sync_for_device(struct msm_gem_object *msm_obj)
|
|
|
|
{
|
|
|
|
struct device *dev = msm_obj->base.dev->dev;
|
|
|
|
|
2019-09-05 00:56:03 +08:00
|
|
|
if (get_dma_ops(dev) && IS_ENABLED(CONFIG_ARM64)) {
|
drm/msm: Use the correct dma_sync calls in msm_gem
[subject was: drm/msm: shake fist angrily at dma-mapping]
So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
it falls appart with dma direct ops. The problem is that, depending on
display generation, we can have either set of dma ops (mdp4 and dpu have
iommu wired to mdss node, which maps to toplevel drm device, but mdp5
has iommu wired up to the mdp sub-node within mdss).
Fixes this splat on mdp5 devices:
Unable to handle kernel paging request at virtual address ffffffff80000000
Mem abort info:
ESR = 0x96000144
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000144
CM = 1, WnR = 1
swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000810e4000
[ffffffff80000000] pgd=0000000000000000
Internal error: Oops: 96000144 [#1] SMP
Modules linked in: btqcomsmd btqca bluetooth cfg80211 ecdh_generic ecc rfkill libarc4 panel_simple msm wcnss_ctrl qrtr_smd drm_kms_helper venus_enc venus_dec videobuf2_dma_sg videobuf2_memops drm venus_core ipv6 qrtr qcom_wcnss_pil v4l2_mem2mem qcom_sysmon videobuf2_v4l2 qmi_helpers videobuf2_common crct10dif_ce mdt_loader qcom_common videodev qcom_glink_smem remoteproc bmc150_accel_i2c bmc150_magn_i2c bmc150_accel_core bmc150_magn snd_soc_lpass_apq8016 snd_soc_msm8916_analog mms114 mc nf_defrag_ipv6 snd_soc_lpass_cpu snd_soc_apq8016_sbc industrialio_triggered_buffer kfifo_buf snd_soc_lpass_platform snd_soc_msm8916_digital drm_panel_orientation_quirks
CPU: 2 PID: 33 Comm: kworker/2:1 Not tainted 5.3.0-rc2 #1
Hardware name: Samsung Galaxy A5U (EUR) (DT)
Workqueue: events deferred_probe_work_func
pstate: 80000005 (Nzcv daif -PAN -UAO)
pc : __clean_dcache_area_poc+0x20/0x38
lr : arch_sync_dma_for_device+0x28/0x30
sp : ffff0000115736a0
x29: ffff0000115736a0 x28: 0000000000000001
x27: ffff800074830800 x26: ffff000011478000
x25: 0000000000000000 x24: 0000000000000001
x23: ffff000011478a98 x22: ffff800009fd1c10
x21: 0000000000000001 x20: ffff800075ad0a00
x19: 0000000000000000 x18: ffff0000112b2000
x17: 0000000000000000 x16: 0000000000000000
x15: 00000000fffffff0 x14: ffff000011455d70
x13: 0000000000000000 x12: 0000000000000028
x11: 0000000000000001 x10: ffff00001106c000
x9 : ffff7e0001d6b380 x8 : 0000000000001000
x7 : ffff7e0001d6b380 x6 : ffff7e0001d6b382
x5 : 0000000000000000 x4 : 0000000000001000
x3 : 000000000000003f x2 : 0000000000000040
x1 : ffffffff80001000 x0 : ffffffff80000000
Call trace:
__clean_dcache_area_poc+0x20/0x38
dma_direct_sync_sg_for_device+0xb8/0xe8
get_pages+0x22c/0x250 [msm]
msm_gem_get_and_pin_iova+0xdc/0x168 [msm]
...
Fixes the combination of two patches:
Fixes: 0036bc73ccbe (drm/msm: stop abusing dma_map/unmap for cache)
Fixes: 449fa54d6815 (dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device)
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Rob Clark <robdclark@chromium.org>
[seanpaul changed subject to something more desriptive]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730214633.17820-1-robdclark@gmail.com
2019-07-31 05:46:28 +08:00
|
|
|
dma_sync_sg_for_device(dev, msm_obj->sgt->sgl,
|
|
|
|
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
|
|
|
|
} else {
|
|
|
|
dma_map_sg(dev, msm_obj->sgt->sgl,
|
|
|
|
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void sync_for_cpu(struct msm_gem_object *msm_obj)
|
|
|
|
{
|
|
|
|
struct device *dev = msm_obj->base.dev->dev;
|
|
|
|
|
2019-09-05 00:56:03 +08:00
|
|
|
if (get_dma_ops(dev) && IS_ENABLED(CONFIG_ARM64)) {
|
drm/msm: Use the correct dma_sync calls in msm_gem
[subject was: drm/msm: shake fist angrily at dma-mapping]
So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
it falls appart with dma direct ops. The problem is that, depending on
display generation, we can have either set of dma ops (mdp4 and dpu have
iommu wired to mdss node, which maps to toplevel drm device, but mdp5
has iommu wired up to the mdp sub-node within mdss).
Fixes this splat on mdp5 devices:
Unable to handle kernel paging request at virtual address ffffffff80000000
Mem abort info:
ESR = 0x96000144
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000144
CM = 1, WnR = 1
swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000810e4000
[ffffffff80000000] pgd=0000000000000000
Internal error: Oops: 96000144 [#1] SMP
Modules linked in: btqcomsmd btqca bluetooth cfg80211 ecdh_generic ecc rfkill libarc4 panel_simple msm wcnss_ctrl qrtr_smd drm_kms_helper venus_enc venus_dec videobuf2_dma_sg videobuf2_memops drm venus_core ipv6 qrtr qcom_wcnss_pil v4l2_mem2mem qcom_sysmon videobuf2_v4l2 qmi_helpers videobuf2_common crct10dif_ce mdt_loader qcom_common videodev qcom_glink_smem remoteproc bmc150_accel_i2c bmc150_magn_i2c bmc150_accel_core bmc150_magn snd_soc_lpass_apq8016 snd_soc_msm8916_analog mms114 mc nf_defrag_ipv6 snd_soc_lpass_cpu snd_soc_apq8016_sbc industrialio_triggered_buffer kfifo_buf snd_soc_lpass_platform snd_soc_msm8916_digital drm_panel_orientation_quirks
CPU: 2 PID: 33 Comm: kworker/2:1 Not tainted 5.3.0-rc2 #1
Hardware name: Samsung Galaxy A5U (EUR) (DT)
Workqueue: events deferred_probe_work_func
pstate: 80000005 (Nzcv daif -PAN -UAO)
pc : __clean_dcache_area_poc+0x20/0x38
lr : arch_sync_dma_for_device+0x28/0x30
sp : ffff0000115736a0
x29: ffff0000115736a0 x28: 0000000000000001
x27: ffff800074830800 x26: ffff000011478000
x25: 0000000000000000 x24: 0000000000000001
x23: ffff000011478a98 x22: ffff800009fd1c10
x21: 0000000000000001 x20: ffff800075ad0a00
x19: 0000000000000000 x18: ffff0000112b2000
x17: 0000000000000000 x16: 0000000000000000
x15: 00000000fffffff0 x14: ffff000011455d70
x13: 0000000000000000 x12: 0000000000000028
x11: 0000000000000001 x10: ffff00001106c000
x9 : ffff7e0001d6b380 x8 : 0000000000001000
x7 : ffff7e0001d6b380 x6 : ffff7e0001d6b382
x5 : 0000000000000000 x4 : 0000000000001000
x3 : 000000000000003f x2 : 0000000000000040
x1 : ffffffff80001000 x0 : ffffffff80000000
Call trace:
__clean_dcache_area_poc+0x20/0x38
dma_direct_sync_sg_for_device+0xb8/0xe8
get_pages+0x22c/0x250 [msm]
msm_gem_get_and_pin_iova+0xdc/0x168 [msm]
...
Fixes the combination of two patches:
Fixes: 0036bc73ccbe (drm/msm: stop abusing dma_map/unmap for cache)
Fixes: 449fa54d6815 (dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device)
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Rob Clark <robdclark@chromium.org>
[seanpaul changed subject to something more desriptive]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730214633.17820-1-robdclark@gmail.com
2019-07-31 05:46:28 +08:00
|
|
|
dma_sync_sg_for_cpu(dev, msm_obj->sgt->sgl,
|
|
|
|
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
|
|
|
|
} else {
|
|
|
|
dma_unmap_sg(dev, msm_obj->sgt->sgl,
|
|
|
|
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-11-17 01:56:06 +08:00
|
|
|
/* allocate pages from VRAM carveout, used when no IOMMU: */
|
2017-06-14 06:52:54 +08:00
|
|
|
static struct page **get_pages_vram(struct drm_gem_object *obj, int npages)
|
2013-11-17 01:56:06 +08:00
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
struct msm_drm_private *priv = obj->dev->dev_private;
|
|
|
|
dma_addr_t paddr;
|
|
|
|
struct page **p;
|
|
|
|
int ret, i;
|
|
|
|
|
2017-05-17 20:23:12 +08:00
|
|
|
p = kvmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
|
2013-11-17 01:56:06 +08:00
|
|
|
if (!p)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
spin_lock(&priv->vram.lock);
|
2017-02-03 05:04:38 +08:00
|
|
|
ret = drm_mm_insert_node(&priv->vram.mm, msm_obj->vram_node, npages);
|
2017-06-14 06:52:54 +08:00
|
|
|
spin_unlock(&priv->vram.lock);
|
2013-11-17 01:56:06 +08:00
|
|
|
if (ret) {
|
2017-05-17 20:23:12 +08:00
|
|
|
kvfree(p);
|
2013-11-17 01:56:06 +08:00
|
|
|
return ERR_PTR(ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
paddr = physaddr(obj);
|
|
|
|
for (i = 0; i < npages; i++) {
|
|
|
|
p[i] = phys_to_page(paddr);
|
|
|
|
paddr += PAGE_SIZE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return p;
|
|
|
|
}
|
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 page **get_pages(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
|
|
|
|
if (!msm_obj->pages) {
|
|
|
|
struct drm_device *dev = obj->dev;
|
2013-11-17 01:56:06 +08:00
|
|
|
struct page **p;
|
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
|
|
|
int npages = obj->size >> PAGE_SHIFT;
|
|
|
|
|
2015-03-04 04:04:25 +08:00
|
|
|
if (use_pages(obj))
|
drm/gem: remove misleading gfp parameter to get_pages()
drm_gem_get_pages() currently allows passing a 'gfp' parameter that is
passed to shmem combined with mapping_gfp_mask(). Given that the default
mapping_gfp_mask() is GFP_HIGHUSER, it is _very_ unlikely that anyone will
ever make use of that parameter. In fact, all drivers currently pass
redundant flags or 0.
This patch removes the 'gfp' parameter. The only reason to keep it is to
remove flags like __GFP_WAIT. But in its current form, it can only be used
to add flags. So to remove __GFP_WAIT, you'd have to drop it from the
mapping_gfp_mask, which again is stupid as this mask is used by shmem-core
for other allocations, too.
If any driver ever requires that parameter, we can introduce a new helper
that takes the raw 'gfp' parameter. The caller'd be responsible to combine
it with mapping_gfp_mask() in a suitable way. The current
drm_gem_get_pages() helper would then simply use mapping_gfp_mask() and
call the new helper. This is what shmem_read_mapping_pages{_gfp,} does
right now.
Moreover, the gfp-zone flag-usage is not obvious: If you pass a modified
zone, shmem core will WARN() or even BUG(). In other words, the following
must be true for 'gfp' passed to shmem_read_mapping_pages_gfp():
gfp_zone(mapping_gfp_mask(mapping)) == gfp_zone(gfp)
Add a comment to drm_gem_read_pages() explaining that constraint.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
2014-05-25 18:59:47 +08:00
|
|
|
p = drm_gem_get_pages(obj);
|
2013-11-17 01:56:06 +08:00
|
|
|
else
|
|
|
|
p = get_pages_vram(obj, npages);
|
|
|
|
|
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(p)) {
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(dev->dev, "could not get pages: %ld\n",
|
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
|
|
|
PTR_ERR(p));
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
2017-12-04 21:40:15 +08:00
|
|
|
msm_obj->pages = p;
|
|
|
|
|
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
|
|
|
msm_obj->sgt = drm_prime_pages_to_sg(p, npages);
|
2013-09-11 06:56:12 +08:00
|
|
|
if (IS_ERR(msm_obj->sgt)) {
|
2017-12-04 21:40:15 +08:00
|
|
|
void *ptr = ERR_CAST(msm_obj->sgt);
|
|
|
|
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(dev->dev, "failed to allocate sgt\n");
|
2017-12-04 21:40:15 +08:00
|
|
|
msm_obj->sgt = NULL;
|
|
|
|
return ptr;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/* For non-cached buffers, ensure the new pages are clean
|
|
|
|
* because display controller, GPU, etc. are not coherent:
|
|
|
|
*/
|
|
|
|
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
|
drm/msm: Use the correct dma_sync calls in msm_gem
[subject was: drm/msm: shake fist angrily at dma-mapping]
So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
it falls appart with dma direct ops. The problem is that, depending on
display generation, we can have either set of dma ops (mdp4 and dpu have
iommu wired to mdss node, which maps to toplevel drm device, but mdp5
has iommu wired up to the mdp sub-node within mdss).
Fixes this splat on mdp5 devices:
Unable to handle kernel paging request at virtual address ffffffff80000000
Mem abort info:
ESR = 0x96000144
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000144
CM = 1, WnR = 1
swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000810e4000
[ffffffff80000000] pgd=0000000000000000
Internal error: Oops: 96000144 [#1] SMP
Modules linked in: btqcomsmd btqca bluetooth cfg80211 ecdh_generic ecc rfkill libarc4 panel_simple msm wcnss_ctrl qrtr_smd drm_kms_helper venus_enc venus_dec videobuf2_dma_sg videobuf2_memops drm venus_core ipv6 qrtr qcom_wcnss_pil v4l2_mem2mem qcom_sysmon videobuf2_v4l2 qmi_helpers videobuf2_common crct10dif_ce mdt_loader qcom_common videodev qcom_glink_smem remoteproc bmc150_accel_i2c bmc150_magn_i2c bmc150_accel_core bmc150_magn snd_soc_lpass_apq8016 snd_soc_msm8916_analog mms114 mc nf_defrag_ipv6 snd_soc_lpass_cpu snd_soc_apq8016_sbc industrialio_triggered_buffer kfifo_buf snd_soc_lpass_platform snd_soc_msm8916_digital drm_panel_orientation_quirks
CPU: 2 PID: 33 Comm: kworker/2:1 Not tainted 5.3.0-rc2 #1
Hardware name: Samsung Galaxy A5U (EUR) (DT)
Workqueue: events deferred_probe_work_func
pstate: 80000005 (Nzcv daif -PAN -UAO)
pc : __clean_dcache_area_poc+0x20/0x38
lr : arch_sync_dma_for_device+0x28/0x30
sp : ffff0000115736a0
x29: ffff0000115736a0 x28: 0000000000000001
x27: ffff800074830800 x26: ffff000011478000
x25: 0000000000000000 x24: 0000000000000001
x23: ffff000011478a98 x22: ffff800009fd1c10
x21: 0000000000000001 x20: ffff800075ad0a00
x19: 0000000000000000 x18: ffff0000112b2000
x17: 0000000000000000 x16: 0000000000000000
x15: 00000000fffffff0 x14: ffff000011455d70
x13: 0000000000000000 x12: 0000000000000028
x11: 0000000000000001 x10: ffff00001106c000
x9 : ffff7e0001d6b380 x8 : 0000000000001000
x7 : ffff7e0001d6b380 x6 : ffff7e0001d6b382
x5 : 0000000000000000 x4 : 0000000000001000
x3 : 000000000000003f x2 : 0000000000000040
x1 : ffffffff80001000 x0 : ffffffff80000000
Call trace:
__clean_dcache_area_poc+0x20/0x38
dma_direct_sync_sg_for_device+0xb8/0xe8
get_pages+0x22c/0x250 [msm]
msm_gem_get_and_pin_iova+0xdc/0x168 [msm]
...
Fixes the combination of two patches:
Fixes: 0036bc73ccbe (drm/msm: stop abusing dma_map/unmap for cache)
Fixes: 449fa54d6815 (dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device)
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Rob Clark <robdclark@chromium.org>
[seanpaul changed subject to something more desriptive]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730214633.17820-1-robdclark@gmail.com
2019-07-31 05:46:28 +08:00
|
|
|
sync_for_device(msm_obj);
|
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 msm_obj->pages;
|
|
|
|
}
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
static void put_pages_vram(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
struct msm_drm_private *priv = obj->dev->dev_private;
|
|
|
|
|
|
|
|
spin_lock(&priv->vram.lock);
|
|
|
|
drm_mm_remove_node(msm_obj->vram_node);
|
|
|
|
spin_unlock(&priv->vram.lock);
|
|
|
|
|
|
|
|
kvfree(msm_obj->pages);
|
|
|
|
}
|
|
|
|
|
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 void put_pages(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
|
|
|
|
if (msm_obj->pages) {
|
2018-04-04 06:38:45 +08:00
|
|
|
if (msm_obj->sgt) {
|
|
|
|
/* For non-cached buffers, ensure the new
|
|
|
|
* pages are clean because display controller,
|
|
|
|
* GPU, etc. are not coherent:
|
|
|
|
*/
|
|
|
|
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
|
drm/msm: Use the correct dma_sync calls in msm_gem
[subject was: drm/msm: shake fist angrily at dma-mapping]
So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
it falls appart with dma direct ops. The problem is that, depending on
display generation, we can have either set of dma ops (mdp4 and dpu have
iommu wired to mdss node, which maps to toplevel drm device, but mdp5
has iommu wired up to the mdp sub-node within mdss).
Fixes this splat on mdp5 devices:
Unable to handle kernel paging request at virtual address ffffffff80000000
Mem abort info:
ESR = 0x96000144
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000144
CM = 1, WnR = 1
swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000810e4000
[ffffffff80000000] pgd=0000000000000000
Internal error: Oops: 96000144 [#1] SMP
Modules linked in: btqcomsmd btqca bluetooth cfg80211 ecdh_generic ecc rfkill libarc4 panel_simple msm wcnss_ctrl qrtr_smd drm_kms_helper venus_enc venus_dec videobuf2_dma_sg videobuf2_memops drm venus_core ipv6 qrtr qcom_wcnss_pil v4l2_mem2mem qcom_sysmon videobuf2_v4l2 qmi_helpers videobuf2_common crct10dif_ce mdt_loader qcom_common videodev qcom_glink_smem remoteproc bmc150_accel_i2c bmc150_magn_i2c bmc150_accel_core bmc150_magn snd_soc_lpass_apq8016 snd_soc_msm8916_analog mms114 mc nf_defrag_ipv6 snd_soc_lpass_cpu snd_soc_apq8016_sbc industrialio_triggered_buffer kfifo_buf snd_soc_lpass_platform snd_soc_msm8916_digital drm_panel_orientation_quirks
CPU: 2 PID: 33 Comm: kworker/2:1 Not tainted 5.3.0-rc2 #1
Hardware name: Samsung Galaxy A5U (EUR) (DT)
Workqueue: events deferred_probe_work_func
pstate: 80000005 (Nzcv daif -PAN -UAO)
pc : __clean_dcache_area_poc+0x20/0x38
lr : arch_sync_dma_for_device+0x28/0x30
sp : ffff0000115736a0
x29: ffff0000115736a0 x28: 0000000000000001
x27: ffff800074830800 x26: ffff000011478000
x25: 0000000000000000 x24: 0000000000000001
x23: ffff000011478a98 x22: ffff800009fd1c10
x21: 0000000000000001 x20: ffff800075ad0a00
x19: 0000000000000000 x18: ffff0000112b2000
x17: 0000000000000000 x16: 0000000000000000
x15: 00000000fffffff0 x14: ffff000011455d70
x13: 0000000000000000 x12: 0000000000000028
x11: 0000000000000001 x10: ffff00001106c000
x9 : ffff7e0001d6b380 x8 : 0000000000001000
x7 : ffff7e0001d6b380 x6 : ffff7e0001d6b382
x5 : 0000000000000000 x4 : 0000000000001000
x3 : 000000000000003f x2 : 0000000000000040
x1 : ffffffff80001000 x0 : ffffffff80000000
Call trace:
__clean_dcache_area_poc+0x20/0x38
dma_direct_sync_sg_for_device+0xb8/0xe8
get_pages+0x22c/0x250 [msm]
msm_gem_get_and_pin_iova+0xdc/0x168 [msm]
...
Fixes the combination of two patches:
Fixes: 0036bc73ccbe (drm/msm: stop abusing dma_map/unmap for cache)
Fixes: 449fa54d6815 (dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device)
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Rob Clark <robdclark@chromium.org>
[seanpaul changed subject to something more desriptive]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730214633.17820-1-robdclark@gmail.com
2019-07-31 05:46:28 +08:00
|
|
|
sync_for_cpu(msm_obj);
|
2017-12-04 21:40:15 +08:00
|
|
|
|
|
|
|
sg_free_table(msm_obj->sgt);
|
2018-04-04 06:38:45 +08:00
|
|
|
kfree(msm_obj->sgt);
|
|
|
|
}
|
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:25 +08:00
|
|
|
if (use_pages(obj))
|
2013-11-17 01:56:06 +08:00
|
|
|
drm_gem_put_pages(obj, msm_obj->pages, true, false);
|
2017-06-14 06:52:54 +08:00
|
|
|
else
|
|
|
|
put_pages_vram(obj);
|
2013-11-17 01:56:06 +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
|
|
|
msm_obj->pages = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-28 23:28:35 +08:00
|
|
|
struct page **msm_gem_get_pages(struct drm_gem_object *obj)
|
|
|
|
{
|
2017-06-14 06:52:54 +08:00
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
2013-09-28 23:28:35 +08:00
|
|
|
struct page **p;
|
2017-06-14 06:52:54 +08:00
|
|
|
|
|
|
|
mutex_lock(&msm_obj->lock);
|
|
|
|
|
|
|
|
if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
|
|
|
|
mutex_unlock(&msm_obj->lock);
|
|
|
|
return ERR_PTR(-EBUSY);
|
|
|
|
}
|
|
|
|
|
2013-09-28 23:28:35 +08:00
|
|
|
p = get_pages(obj);
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_unlock(&msm_obj->lock);
|
2013-09-28 23:28:35 +08:00
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
|
|
|
void msm_gem_put_pages(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
/* when we start tracking the pin count, then do something here */
|
|
|
|
}
|
|
|
|
|
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
|
|
|
int msm_gem_mmap_obj(struct drm_gem_object *obj,
|
|
|
|
struct vm_area_struct *vma)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
|
|
|
|
vma->vm_flags &= ~VM_PFNMAP;
|
|
|
|
vma->vm_flags |= VM_MIXEDMAP;
|
|
|
|
|
|
|
|
if (msm_obj->flags & MSM_BO_WC) {
|
|
|
|
vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
|
|
|
|
} else if (msm_obj->flags & MSM_BO_UNCACHED) {
|
|
|
|
vma->vm_page_prot = pgprot_noncached(vm_get_page_prot(vma->vm_flags));
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Shunt off cached objs to shmem file so they have their own
|
|
|
|
* address_space (so unmap_mapping_range does what we want,
|
|
|
|
* in particular in the case of mmap'd dmabufs)
|
|
|
|
*/
|
|
|
|
fput(vma->vm_file);
|
|
|
|
get_file(obj->filp);
|
|
|
|
vma->vm_pgoff = 0;
|
|
|
|
vma->vm_file = obj->filp;
|
|
|
|
|
|
|
|
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int msm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = drm_gem_mmap(filp, vma);
|
|
|
|
if (ret) {
|
|
|
|
DBG("mmap failed: %d", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return msm_gem_mmap_obj(vma->vm_private_data, vma);
|
|
|
|
}
|
|
|
|
|
2018-05-22 01:29:48 +08:00
|
|
|
vm_fault_t msm_gem_fault(struct vm_fault *vmf)
|
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
|
|
|
{
|
2017-02-25 06:56:41 +08:00
|
|
|
struct vm_area_struct *vma = vmf->vma;
|
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_gem_object *obj = vma->vm_private_data;
|
2017-06-14 06:52:54 +08:00
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
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 page **pages;
|
|
|
|
unsigned long pfn;
|
|
|
|
pgoff_t pgoff;
|
2018-05-22 01:29:48 +08:00
|
|
|
int err;
|
|
|
|
vm_fault_t 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
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
/*
|
|
|
|
* vm_ops.open/drm_gem_mmap_obj and close get and put
|
|
|
|
* a reference on obj. So, we dont need to hold one here.
|
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-05-22 01:29:48 +08:00
|
|
|
err = mutex_lock_interruptible(&msm_obj->lock);
|
|
|
|
if (err) {
|
|
|
|
ret = VM_FAULT_NOPAGE;
|
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
|
|
|
goto out;
|
2018-05-22 01:29:48 +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
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
|
|
|
|
mutex_unlock(&msm_obj->lock);
|
|
|
|
return VM_FAULT_SIGBUS;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/* make sure we have pages attached now */
|
|
|
|
pages = get_pages(obj);
|
|
|
|
if (IS_ERR(pages)) {
|
2018-05-22 01:29:48 +08:00
|
|
|
ret = vmf_error(PTR_ERR(pages));
|
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
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We don't use vmf->pgoff since that has the fake offset: */
|
2016-12-15 07:07:01 +08:00
|
|
|
pgoff = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
|
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-11-17 01:56:06 +08:00
|
|
|
pfn = page_to_pfn(pages[pgoff]);
|
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-12-15 07:07:01 +08:00
|
|
|
VERB("Inserting %p pfn %lx, pa %lx", (void *)vmf->address,
|
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
|
|
|
pfn, pfn << PAGE_SHIFT);
|
|
|
|
|
2018-05-22 01:29:48 +08:00
|
|
|
ret = vmf_insert_mixed(vma, vmf->address, __pfn_to_pfn_t(pfn, PFN_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
|
|
|
out_unlock:
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_unlock(&msm_obj->lock);
|
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
|
|
|
out:
|
2018-05-22 01:29:48 +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
|
|
|
}
|
|
|
|
|
|
|
|
/** get mmap offset */
|
|
|
|
static uint64_t mmap_offset(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = obj->dev;
|
2017-06-14 06:52:54 +08:00
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
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
|
|
|
int ret;
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
WARN_ON(!mutex_is_locked(&msm_obj->lock));
|
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
|
|
|
|
|
|
|
/* Make it mmapable */
|
|
|
|
ret = drm_gem_create_mmap_offset(obj);
|
|
|
|
|
|
|
|
if (ret) {
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(dev->dev, "could not allocate mmap offset\n");
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
return drm_vma_node_offset_addr(&obj->vma_node);
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
uint64_t offset;
|
2017-06-14 06:52:54 +08:00
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
|
|
|
|
mutex_lock(&msm_obj->lock);
|
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
|
|
|
offset = mmap_offset(obj);
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_unlock(&msm_obj->lock);
|
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 offset;
|
|
|
|
}
|
|
|
|
|
2017-06-14 01:54:13 +08:00
|
|
|
static struct msm_gem_vma *add_vma(struct drm_gem_object *obj,
|
|
|
|
struct msm_gem_address_space *aspace)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
struct msm_gem_vma *vma;
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
WARN_ON(!mutex_is_locked(&msm_obj->lock));
|
|
|
|
|
2017-06-14 01:54:13 +08:00
|
|
|
vma = kzalloc(sizeof(*vma), GFP_KERNEL);
|
|
|
|
if (!vma)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
|
|
vma->aspace = aspace;
|
|
|
|
|
|
|
|
list_add_tail(&vma->list, &msm_obj->vmas);
|
|
|
|
|
|
|
|
return vma;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct msm_gem_vma *lookup_vma(struct drm_gem_object *obj,
|
|
|
|
struct msm_gem_address_space *aspace)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
struct msm_gem_vma *vma;
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
WARN_ON(!mutex_is_locked(&msm_obj->lock));
|
2017-06-14 01:54:13 +08:00
|
|
|
|
|
|
|
list_for_each_entry(vma, &msm_obj->vmas, list) {
|
|
|
|
if (vma->aspace == aspace)
|
|
|
|
return vma;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void del_vma(struct msm_gem_vma *vma)
|
|
|
|
{
|
|
|
|
if (!vma)
|
|
|
|
return;
|
|
|
|
|
|
|
|
list_del(&vma->list);
|
|
|
|
kfree(vma);
|
|
|
|
}
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
/* Called with msm_obj->lock locked */
|
2016-06-01 23:38:28 +08:00
|
|
|
static void
|
|
|
|
put_iova(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
2017-06-14 01:54:13 +08:00
|
|
|
struct msm_gem_vma *vma, *tmp;
|
2016-06-01 23:38:28 +08:00
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
WARN_ON(!mutex_is_locked(&msm_obj->lock));
|
2016-06-01 23:38:28 +08:00
|
|
|
|
2017-06-14 01:54:13 +08:00
|
|
|
list_for_each_entry_safe(vma, tmp, &msm_obj->vmas, list) {
|
2019-06-03 09:01:31 +08:00
|
|
|
if (vma->aspace) {
|
|
|
|
msm_gem_purge_vma(vma->aspace, vma);
|
|
|
|
msm_gem_close_vma(vma->aspace, vma);
|
|
|
|
}
|
2017-06-14 01:54:13 +08:00
|
|
|
del_vma(vma);
|
2016-06-01 23:38:28 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-11-08 06:35:48 +08:00
|
|
|
static int msm_gem_get_iova_locked(struct drm_gem_object *obj,
|
2017-06-13 23:07:08 +08:00
|
|
|
struct msm_gem_address_space *aspace, uint64_t *iova)
|
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_gem_object *msm_obj = to_msm_bo(obj);
|
2017-06-14 01:54:13 +08:00
|
|
|
struct msm_gem_vma *vma;
|
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
|
|
|
int ret = 0;
|
|
|
|
|
2018-11-08 06:35:48 +08:00
|
|
|
WARN_ON(!mutex_is_locked(&msm_obj->lock));
|
2017-06-13 21:15:36 +08:00
|
|
|
|
2017-06-14 01:54:13 +08:00
|
|
|
vma = lookup_vma(obj, aspace);
|
2013-11-17 01:56:06 +08:00
|
|
|
|
2017-06-14 01:54:13 +08:00
|
|
|
if (!vma) {
|
|
|
|
vma = add_vma(obj, aspace);
|
2018-11-08 06:35:48 +08:00
|
|
|
if (IS_ERR(vma))
|
|
|
|
return PTR_ERR(vma);
|
2017-06-14 01:54:13 +08:00
|
|
|
|
2018-11-08 06:35:48 +08:00
|
|
|
ret = msm_gem_init_vma(aspace, vma, obj->size >> PAGE_SHIFT);
|
|
|
|
if (ret) {
|
|
|
|
del_vma(vma);
|
|
|
|
return ret;
|
2017-06-14 01:54:13 +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
|
|
|
}
|
|
|
|
|
2017-06-14 01:54:13 +08:00
|
|
|
*iova = vma->iova;
|
|
|
|
return 0;
|
2018-11-08 06:35:48 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int msm_gem_pin_iova(struct drm_gem_object *obj,
|
|
|
|
struct msm_gem_address_space *aspace)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
struct msm_gem_vma *vma;
|
|
|
|
struct page **pages;
|
2019-01-10 03:25:05 +08:00
|
|
|
int prot = IOMMU_READ;
|
|
|
|
|
|
|
|
if (!(msm_obj->flags & MSM_BO_GPU_READONLY))
|
|
|
|
prot |= IOMMU_WRITE;
|
2018-11-08 06:35:48 +08:00
|
|
|
|
|
|
|
WARN_ON(!mutex_is_locked(&msm_obj->lock));
|
|
|
|
|
|
|
|
if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED))
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
vma = lookup_vma(obj, aspace);
|
|
|
|
if (WARN_ON(!vma))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
pages = get_pages(obj);
|
|
|
|
if (IS_ERR(pages))
|
|
|
|
return PTR_ERR(pages);
|
|
|
|
|
2019-01-10 03:25:05 +08:00
|
|
|
return msm_gem_map_vma(aspace, vma, prot,
|
|
|
|
msm_obj->sgt, obj->size >> PAGE_SHIFT);
|
2018-11-08 06:35:48 +08:00
|
|
|
}
|
|
|
|
|
2018-11-08 06:35:50 +08:00
|
|
|
/* get iova and pin it. Should have a matching put */
|
|
|
|
int msm_gem_get_and_pin_iova(struct drm_gem_object *obj,
|
2018-11-08 06:35:48 +08:00
|
|
|
struct msm_gem_address_space *aspace, uint64_t *iova)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
u64 local;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&msm_obj->lock);
|
|
|
|
|
|
|
|
ret = msm_gem_get_iova_locked(obj, aspace, &local);
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
ret = msm_gem_pin_iova(obj, aspace);
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
*iova = local;
|
2017-06-14 01:54:13 +08:00
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_unlock(&msm_obj->lock);
|
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-11-08 06:35:51 +08:00
|
|
|
/*
|
|
|
|
* Get an iova but don't pin it. Doesn't need a put because iovas are currently
|
|
|
|
* valid for the life of the object
|
|
|
|
*/
|
2018-11-08 06:35:50 +08:00
|
|
|
int msm_gem_get_iova(struct drm_gem_object *obj,
|
|
|
|
struct msm_gem_address_space *aspace, uint64_t *iova)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&msm_obj->lock);
|
|
|
|
ret = msm_gem_get_iova_locked(obj, aspace, iova);
|
|
|
|
mutex_unlock(&msm_obj->lock);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-11-08 22:13:37 +08:00
|
|
|
/* get iova without taking a reference, used in places where you have
|
2018-11-08 06:35:50 +08:00
|
|
|
* already done a 'msm_gem_get_and_pin_iova' or 'msm_gem_get_iova'
|
2014-11-08 22:13:37 +08:00
|
|
|
*/
|
2017-06-13 23:07:08 +08:00
|
|
|
uint64_t msm_gem_iova(struct drm_gem_object *obj,
|
|
|
|
struct msm_gem_address_space *aspace)
|
2014-11-08 22:13:37 +08:00
|
|
|
{
|
2017-06-14 06:52:54 +08:00
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
2017-06-14 01:54:13 +08:00
|
|
|
struct msm_gem_vma *vma;
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_lock(&msm_obj->lock);
|
2017-06-14 01:54:13 +08:00
|
|
|
vma = lookup_vma(obj, aspace);
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_unlock(&msm_obj->lock);
|
2017-06-14 01:54:13 +08:00
|
|
|
WARN_ON(!vma);
|
|
|
|
|
|
|
|
return vma ? vma->iova : 0;
|
2014-11-08 22:13:37 +08:00
|
|
|
}
|
|
|
|
|
2018-11-08 06:35:51 +08:00
|
|
|
/*
|
|
|
|
* Unpin a iova by updating the reference counts. The memory isn't actually
|
|
|
|
* purged until something else (shrinker, mm_notifier, destroy, etc) decides
|
|
|
|
* to get rid of it
|
|
|
|
*/
|
|
|
|
void msm_gem_unpin_iova(struct drm_gem_object *obj,
|
2017-06-13 23:07:08 +08:00
|
|
|
struct msm_gem_address_space *aspace)
|
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-11-08 06:35:51 +08:00
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
struct msm_gem_vma *vma;
|
|
|
|
|
|
|
|
mutex_lock(&msm_obj->lock);
|
|
|
|
vma = lookup_vma(obj, aspace);
|
|
|
|
|
|
|
|
if (!WARN_ON(!vma))
|
|
|
|
msm_gem_unmap_vma(aspace, vma);
|
|
|
|
|
|
|
|
mutex_unlock(&msm_obj->lock);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
int msm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
|
|
|
|
struct drm_mode_create_dumb *args)
|
|
|
|
{
|
|
|
|
args->pitch = align_pitch(args->width, args->bpp);
|
|
|
|
args->size = PAGE_ALIGN(args->pitch * args->height);
|
|
|
|
return msm_gem_new_handle(dev, file, args->size,
|
2018-11-08 06:35:52 +08:00
|
|
|
MSM_BO_SCANOUT | MSM_BO_WC, &args->handle, "dumb");
|
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
|
|
|
}
|
|
|
|
|
|
|
|
int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
|
|
|
|
uint32_t handle, uint64_t *offset)
|
|
|
|
{
|
|
|
|
struct drm_gem_object *obj;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
/* GEM does all our handle to object mapping */
|
2016-05-09 18:04:54 +08:00
|
|
|
obj = drm_gem_object_lookup(file, handle);
|
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 (obj == NULL) {
|
|
|
|
ret = -ENOENT;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
*offset = msm_gem_mmap_offset(obj);
|
|
|
|
|
2018-01-26 11:55:54 +08:00
|
|
|
drm_gem_object_put_unlocked(obj);
|
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
|
|
|
|
|
|
|
fail:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-09-15 20:38:20 +08:00
|
|
|
static void *get_vaddr(struct drm_gem_object *obj, unsigned madv)
|
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_gem_object *msm_obj = to_msm_bo(obj);
|
2017-06-14 06:52:54 +08:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
mutex_lock(&msm_obj->lock);
|
|
|
|
|
2017-09-15 20:38:20 +08:00
|
|
|
if (WARN_ON(msm_obj->madv > madv)) {
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(obj->dev->dev, "Invalid madv state: %u vs %u\n",
|
2017-09-15 20:38:20 +08:00
|
|
|
msm_obj->madv, madv);
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_unlock(&msm_obj->lock);
|
|
|
|
return ERR_PTR(-EBUSY);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* increment vmap_count *before* vmap() call, so shrinker can
|
|
|
|
* check vmap_count (is_vunmapable()) outside of msm_obj->lock.
|
|
|
|
* This guarantees that we won't try to msm_gem_vunmap() this
|
|
|
|
* same object from within the vmap() call (while we already
|
|
|
|
* hold msm_obj->lock)
|
|
|
|
*/
|
|
|
|
msm_obj->vmap_count++;
|
|
|
|
|
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 (!msm_obj->vaddr) {
|
|
|
|
struct page **pages = get_pages(obj);
|
2017-06-14 06:52:54 +08:00
|
|
|
if (IS_ERR(pages)) {
|
|
|
|
ret = PTR_ERR(pages);
|
|
|
|
goto fail;
|
|
|
|
}
|
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
|
|
|
msm_obj->vaddr = vmap(pages, obj->size >> PAGE_SHIFT,
|
|
|
|
VM_MAP, pgprot_writecombine(PAGE_KERNEL));
|
2017-06-14 06:52:54 +08:00
|
|
|
if (msm_obj->vaddr == NULL) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto fail;
|
|
|
|
}
|
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
|
|
|
}
|
2017-06-14 06:52:54 +08:00
|
|
|
|
|
|
|
mutex_unlock(&msm_obj->lock);
|
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 msm_obj->vaddr;
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
fail:
|
|
|
|
msm_obj->vmap_count--;
|
|
|
|
mutex_unlock(&msm_obj->lock);
|
|
|
|
return ERR_PTR(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
|
|
|
}
|
|
|
|
|
2017-09-15 20:38:20 +08:00
|
|
|
void *msm_gem_get_vaddr(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
return get_vaddr(obj, MSM_MADV_WILLNEED);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't use this! It is for the very special case of dumping
|
|
|
|
* submits from GPU hangs or faults, were the bo may already
|
|
|
|
* be MSM_MADV_DONTNEED, but we know the buffer is still on the
|
|
|
|
* active list.
|
|
|
|
*/
|
|
|
|
void *msm_gem_get_vaddr_active(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
return get_vaddr(obj, __MSM_MADV_PURGED);
|
|
|
|
}
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
void msm_gem_put_vaddr(struct drm_gem_object *obj)
|
2016-05-27 04:24:35 +08:00
|
|
|
{
|
2016-05-27 23:16:28 +08:00
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
2017-06-14 06:52:54 +08:00
|
|
|
|
|
|
|
mutex_lock(&msm_obj->lock);
|
2016-05-27 23:16:28 +08:00
|
|
|
WARN_ON(msm_obj->vmap_count < 1);
|
|
|
|
msm_obj->vmap_count--;
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_unlock(&msm_obj->lock);
|
2016-05-27 04:24:35 +08:00
|
|
|
}
|
|
|
|
|
2016-05-18 03:44:49 +08:00
|
|
|
/* Update madvise status, returns true if not purged, else
|
|
|
|
* false or -errno.
|
|
|
|
*/
|
|
|
|
int msm_gem_madvise(struct drm_gem_object *obj, unsigned madv)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_lock(&msm_obj->lock);
|
|
|
|
|
2016-05-18 03:44:49 +08:00
|
|
|
WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
|
|
|
|
|
|
|
|
if (msm_obj->madv != __MSM_MADV_PURGED)
|
|
|
|
msm_obj->madv = madv;
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
madv = msm_obj->madv;
|
|
|
|
|
|
|
|
mutex_unlock(&msm_obj->lock);
|
|
|
|
|
|
|
|
return (madv != __MSM_MADV_PURGED);
|
2016-05-18 03:44:49 +08:00
|
|
|
}
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
void msm_gem_purge(struct drm_gem_object *obj, enum msm_gem_lock subclass)
|
2016-05-18 04:19:32 +08:00
|
|
|
{
|
|
|
|
struct drm_device *dev = obj->dev;
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
|
|
|
|
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
|
|
|
|
WARN_ON(!is_purgeable(msm_obj));
|
|
|
|
WARN_ON(obj->import_attach);
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_lock_nested(&msm_obj->lock, subclass);
|
|
|
|
|
2016-05-18 04:19:32 +08:00
|
|
|
put_iova(obj);
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
msm_gem_vunmap_locked(obj);
|
2016-05-18 04:19:32 +08:00
|
|
|
|
|
|
|
put_pages(obj);
|
|
|
|
|
|
|
|
msm_obj->madv = __MSM_MADV_PURGED;
|
|
|
|
|
|
|
|
drm_vma_node_unmap(&obj->vma_node, dev->anon_inode->i_mapping);
|
|
|
|
drm_gem_free_mmap_offset(obj);
|
|
|
|
|
|
|
|
/* Our goal here is to return as much of the memory as
|
|
|
|
* is possible back to the system as we are called from OOM.
|
|
|
|
* To do this we must instruct the shmfs to drop all of its
|
|
|
|
* backing pages, *now*.
|
|
|
|
*/
|
|
|
|
shmem_truncate_range(file_inode(obj->filp), 0, (loff_t)-1);
|
|
|
|
|
|
|
|
invalidate_mapping_pages(file_inode(obj->filp)->i_mapping,
|
|
|
|
0, (loff_t)-1);
|
2017-06-14 06:52:54 +08:00
|
|
|
|
|
|
|
mutex_unlock(&msm_obj->lock);
|
2016-05-18 04:19:32 +08:00
|
|
|
}
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
static void msm_gem_vunmap_locked(struct drm_gem_object *obj)
|
2016-05-27 23:16:28 +08:00
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
WARN_ON(!mutex_is_locked(&msm_obj->lock));
|
|
|
|
|
2016-05-27 23:16:28 +08:00
|
|
|
if (!msm_obj->vaddr || WARN_ON(!is_vunmapable(msm_obj)))
|
|
|
|
return;
|
|
|
|
|
|
|
|
vunmap(msm_obj->vaddr);
|
|
|
|
msm_obj->vaddr = NULL;
|
|
|
|
}
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
void msm_gem_vunmap(struct drm_gem_object *obj, enum msm_gem_lock subclass)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
|
|
|
|
mutex_lock_nested(&msm_obj->lock, subclass);
|
|
|
|
msm_gem_vunmap_locked(obj);
|
|
|
|
mutex_unlock(&msm_obj->lock);
|
|
|
|
}
|
|
|
|
|
2016-03-16 06:26:28 +08:00
|
|
|
/* must be called before _move_to_active().. */
|
|
|
|
int msm_gem_sync_object(struct drm_gem_object *obj,
|
|
|
|
struct msm_fence_context *fctx, bool exclusive)
|
|
|
|
{
|
2019-08-11 16:06:32 +08:00
|
|
|
struct dma_resv_list *fobj;
|
2016-10-25 20:00:45 +08:00
|
|
|
struct dma_fence *fence;
|
2016-03-16 06:26:28 +08:00
|
|
|
int i, ret;
|
|
|
|
|
2019-08-11 16:06:32 +08:00
|
|
|
fobj = dma_resv_get_list(obj->resv);
|
2016-03-16 06:26:28 +08:00
|
|
|
if (!fobj || (fobj->shared_count == 0)) {
|
2019-08-11 16:06:32 +08:00
|
|
|
fence = dma_resv_get_excl(obj->resv);
|
2016-03-16 06:26:28 +08:00
|
|
|
/* don't need to wait on our own fences, since ring is fifo */
|
|
|
|
if (fence && (fence->context != fctx->context)) {
|
2016-10-25 20:00:45 +08:00
|
|
|
ret = dma_fence_wait(fence, true);
|
2016-03-16 06:26:28 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!exclusive || !fobj)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
for (i = 0; i < fobj->shared_count; i++) {
|
|
|
|
fence = rcu_dereference_protected(fobj->shared[i],
|
2019-08-11 16:06:32 +08:00
|
|
|
dma_resv_held(obj->resv));
|
2016-03-16 06:26:28 +08:00
|
|
|
if (fence->context != fctx->context) {
|
2016-10-25 20:00:45 +08:00
|
|
|
ret = dma_fence_wait(fence, true);
|
2016-03-16 06:26:28 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-07-20 00:59:32 +08:00
|
|
|
void msm_gem_move_to_active(struct drm_gem_object *obj,
|
2016-10-25 20:00:45 +08:00
|
|
|
struct msm_gpu *gpu, bool exclusive, struct dma_fence *fence)
|
2013-07-20 00:59:32 +08:00
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
2016-05-18 03:44:49 +08:00
|
|
|
WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED);
|
2013-07-20 00:59:32 +08:00
|
|
|
msm_obj->gpu = gpu;
|
2016-03-16 06:26:28 +08:00
|
|
|
if (exclusive)
|
2019-08-11 16:06:32 +08:00
|
|
|
dma_resv_add_excl_fence(obj->resv, fence);
|
2013-09-02 01:25:09 +08:00
|
|
|
else
|
2019-08-11 16:06:32 +08:00
|
|
|
dma_resv_add_shared_fence(obj->resv, fence);
|
2013-07-20 00:59:32 +08:00
|
|
|
list_del_init(&msm_obj->mm_list);
|
|
|
|
list_add_tail(&msm_obj->mm_list, &gpu->active_list);
|
|
|
|
}
|
|
|
|
|
|
|
|
void msm_gem_move_to_inactive(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = obj->dev;
|
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
|
|
|
|
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
|
|
|
|
|
|
|
|
msm_obj->gpu = NULL;
|
|
|
|
list_del_init(&msm_obj->mm_list);
|
|
|
|
list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
|
|
|
|
}
|
|
|
|
|
2016-03-16 06:26:28 +08:00
|
|
|
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t *timeout)
|
2013-07-20 00:59:32 +08:00
|
|
|
{
|
2016-03-16 06:26:28 +08:00
|
|
|
bool write = !!(op & MSM_PREP_WRITE);
|
2016-08-29 15:08:26 +08:00
|
|
|
unsigned long remain =
|
|
|
|
op & MSM_PREP_NOSYNC ? 0 : timeout_to_jiffies(timeout);
|
|
|
|
long ret;
|
|
|
|
|
2019-08-11 16:06:32 +08:00
|
|
|
ret = dma_resv_wait_timeout_rcu(obj->resv, write,
|
2016-08-29 15:08:26 +08:00
|
|
|
true, remain);
|
|
|
|
if (ret == 0)
|
|
|
|
return remain == 0 ? -EBUSY : -ETIMEDOUT;
|
|
|
|
else if (ret < 0)
|
|
|
|
return ret;
|
2013-07-20 00:59:32 +08:00
|
|
|
|
|
|
|
/* TODO cache maintenance */
|
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-03-16 06:26:28 +08:00
|
|
|
return 0;
|
2013-07-20 00:59:32 +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
|
|
|
|
2013-07-20 00:59:32 +08:00
|
|
|
int msm_gem_cpu_fini(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
/* TODO cache maintenance */
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_FS
|
2016-10-25 20:00:45 +08:00
|
|
|
static void describe_fence(struct dma_fence *fence, const char *type,
|
2016-03-16 06:26:28 +08:00
|
|
|
struct seq_file *m)
|
|
|
|
{
|
2016-10-25 20:00:45 +08:00
|
|
|
if (!dma_fence_is_signaled(fence))
|
2019-01-10 04:20:15 +08:00
|
|
|
seq_printf(m, "\t%9s: %s %s seq %llu\n", type,
|
2016-03-16 06:26:28 +08:00
|
|
|
fence->ops->get_driver_name(fence),
|
|
|
|
fence->ops->get_timeline_name(fence),
|
|
|
|
fence->seqno);
|
|
|
|
}
|
|
|
|
|
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_gem_describe(struct drm_gem_object *obj, struct seq_file *m)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
2019-08-11 16:06:32 +08:00
|
|
|
struct dma_resv *robj = obj->resv;
|
|
|
|
struct dma_resv_list *fobj;
|
2016-10-25 20:00:45 +08:00
|
|
|
struct dma_fence *fence;
|
2017-06-14 01:54:13 +08:00
|
|
|
struct msm_gem_vma *vma;
|
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
|
|
|
uint64_t off = drm_vma_node_start(&obj->vma_node);
|
2016-05-18 03:44:49 +08:00
|
|
|
const char *madv;
|
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
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_lock(&msm_obj->lock);
|
2016-03-16 06:26:28 +08:00
|
|
|
|
2016-05-18 03:44:49 +08:00
|
|
|
switch (msm_obj->madv) {
|
|
|
|
case __MSM_MADV_PURGED:
|
|
|
|
madv = " purged";
|
|
|
|
break;
|
|
|
|
case MSM_MADV_DONTNEED:
|
|
|
|
madv = " purgeable";
|
|
|
|
break;
|
|
|
|
case MSM_MADV_WILLNEED:
|
|
|
|
default:
|
|
|
|
madv = "";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2018-11-08 06:35:49 +08:00
|
|
|
seq_printf(m, "%08x: %c %2d (%2d) %08llx %p",
|
2013-07-20 00:59:32 +08:00
|
|
|
msm_obj->flags, is_active(msm_obj) ? 'A' : 'I',
|
2016-11-15 00:29:48 +08:00
|
|
|
obj->name, kref_read(&obj->refcount),
|
2016-09-29 07:58:32 +08:00
|
|
|
off, msm_obj->vaddr);
|
|
|
|
|
2018-11-08 06:35:52 +08:00
|
|
|
seq_printf(m, " %08zu %9s %-32s\n", obj->size, madv, msm_obj->name);
|
2016-09-29 07:58:32 +08:00
|
|
|
|
2018-11-08 06:35:49 +08:00
|
|
|
if (!list_empty(&msm_obj->vmas)) {
|
|
|
|
|
2018-11-08 06:35:51 +08:00
|
|
|
seq_puts(m, " vmas:");
|
2018-11-08 06:35:49 +08:00
|
|
|
|
|
|
|
list_for_each_entry(vma, &msm_obj->vmas, list)
|
2019-05-14 07:41:05 +08:00
|
|
|
seq_printf(m, " [%s: %08llx,%s,inuse=%d]",
|
|
|
|
vma->aspace != NULL ? vma->aspace->name : NULL,
|
2018-11-08 06:35:51 +08:00
|
|
|
vma->iova, vma->mapped ? "mapped" : "unmapped",
|
|
|
|
vma->inuse);
|
2018-11-08 06:35:49 +08:00
|
|
|
|
|
|
|
seq_puts(m, "\n");
|
|
|
|
}
|
2016-03-16 06:26:28 +08:00
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
fobj = rcu_dereference(robj->fence);
|
|
|
|
if (fobj) {
|
|
|
|
unsigned int i, shared_count = fobj->shared_count;
|
|
|
|
|
|
|
|
for (i = 0; i < shared_count; i++) {
|
|
|
|
fence = rcu_dereference(fobj->shared[i]);
|
|
|
|
describe_fence(fence, "Shared", m);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fence = rcu_dereference(robj->fence_excl);
|
|
|
|
if (fence)
|
|
|
|
describe_fence(fence, "Exclusive", m);
|
|
|
|
rcu_read_unlock();
|
2017-06-14 06:52:54 +08:00
|
|
|
|
|
|
|
mutex_unlock(&msm_obj->lock);
|
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_gem_describe_objects(struct list_head *list, struct seq_file *m)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj;
|
|
|
|
int count = 0;
|
|
|
|
size_t size = 0;
|
|
|
|
|
2018-11-08 06:35:52 +08:00
|
|
|
seq_puts(m, " flags id ref offset kaddr size madv name\n");
|
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
|
|
|
list_for_each_entry(msm_obj, list, mm_list) {
|
|
|
|
struct drm_gem_object *obj = &msm_obj->base;
|
2018-11-08 06:35:49 +08:00
|
|
|
seq_puts(m, " ");
|
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
|
|
|
msm_gem_describe(obj, m);
|
|
|
|
count++;
|
|
|
|
size += obj->size;
|
|
|
|
}
|
|
|
|
|
|
|
|
seq_printf(m, "Total %d objects, %zu bytes\n", count, size);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2018-02-15 00:14:23 +08:00
|
|
|
/* don't call directly! Use drm_gem_object_put() and friends */
|
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_gem_free_object(struct drm_gem_object *obj)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
2019-03-21 01:09:08 +08:00
|
|
|
struct drm_device *dev = obj->dev;
|
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
|
|
|
|
|
|
|
if (llist_add(&msm_obj->freed, &priv->free_list))
|
|
|
|
queue_work(priv->wq, &priv->free_work);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void free_object(struct msm_gem_object *msm_obj)
|
|
|
|
{
|
|
|
|
struct drm_gem_object *obj = &msm_obj->base;
|
|
|
|
struct drm_device *dev = obj->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
|
|
|
|
|
|
|
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
|
|
|
|
|
2013-07-20 00:59:32 +08:00
|
|
|
/* object should not be on active list: */
|
|
|
|
WARN_ON(is_active(msm_obj));
|
|
|
|
|
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
|
|
|
list_del(&msm_obj->mm_list);
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_lock(&msm_obj->lock);
|
|
|
|
|
2016-06-01 23:38:28 +08:00
|
|
|
put_iova(obj);
|
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-09-28 23:28:35 +08:00
|
|
|
if (obj->import_attach) {
|
|
|
|
if (msm_obj->vaddr)
|
|
|
|
dma_buf_vunmap(obj->import_attach->dmabuf, msm_obj->vaddr);
|
|
|
|
|
|
|
|
/* Don't drop the pages for imported dmabuf, as they are not
|
|
|
|
* ours, just free the array we allocated:
|
|
|
|
*/
|
|
|
|
if (msm_obj->pages)
|
2017-05-17 20:23:12 +08:00
|
|
|
kvfree(msm_obj->pages);
|
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-04-08 01:51:32 +08:00
|
|
|
drm_prime_gem_destroy(obj, msm_obj->sgt);
|
2013-09-28 23:28:35 +08:00
|
|
|
} else {
|
2017-06-14 06:52:54 +08:00
|
|
|
msm_gem_vunmap_locked(obj);
|
2013-09-28 23:28:35 +08:00
|
|
|
put_pages(obj);
|
|
|
|
}
|
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
|
|
|
|
|
|
|
drm_gem_object_release(obj);
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_unlock(&msm_obj->lock);
|
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(msm_obj);
|
|
|
|
}
|
|
|
|
|
2019-03-21 01:09:08 +08:00
|
|
|
void msm_gem_free_work(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct msm_drm_private *priv =
|
|
|
|
container_of(work, struct msm_drm_private, free_work);
|
|
|
|
struct drm_device *dev = priv->dev;
|
|
|
|
struct llist_node *freed;
|
|
|
|
struct msm_gem_object *msm_obj, *next;
|
|
|
|
|
|
|
|
while ((freed = llist_del_all(&priv->free_list))) {
|
|
|
|
|
|
|
|
mutex_lock(&dev->struct_mutex);
|
|
|
|
|
|
|
|
llist_for_each_entry_safe(msm_obj, next,
|
|
|
|
freed, freed)
|
|
|
|
free_object(msm_obj);
|
|
|
|
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
|
|
|
if (need_resched())
|
|
|
|
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
|
|
|
/* convenience method to construct a GEM buffer object, and userspace handle */
|
|
|
|
int msm_gem_new_handle(struct drm_device *dev, struct drm_file *file,
|
2018-11-08 06:35:52 +08:00
|
|
|
uint32_t size, uint32_t flags, uint32_t *handle,
|
|
|
|
char *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
|
|
|
{
|
|
|
|
struct drm_gem_object *obj;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
obj = msm_gem_new(dev, size, flags);
|
|
|
|
|
|
|
|
if (IS_ERR(obj))
|
|
|
|
return PTR_ERR(obj);
|
|
|
|
|
2018-11-08 06:35:52 +08:00
|
|
|
if (name)
|
|
|
|
msm_gem_object_set_name(obj, "%s", 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
|
|
|
ret = drm_gem_handle_create(file, obj, handle);
|
|
|
|
|
|
|
|
/* drop reference from allocate - handle holds it now */
|
2018-01-26 11:55:54 +08:00
|
|
|
drm_gem_object_put_unlocked(obj);
|
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;
|
|
|
|
}
|
|
|
|
|
2013-09-28 23:28:35 +08:00
|
|
|
static int msm_gem_new_impl(struct drm_device *dev,
|
|
|
|
uint32_t size, uint32_t flags,
|
2017-06-14 06:52:54 +08:00
|
|
|
struct drm_gem_object **obj,
|
|
|
|
bool struct_mutex_locked)
|
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_gem_object *msm_obj;
|
|
|
|
|
|
|
|
switch (flags & MSM_BO_CACHE_MASK) {
|
|
|
|
case MSM_BO_UNCACHED:
|
|
|
|
case MSM_BO_CACHED:
|
|
|
|
case MSM_BO_WC:
|
|
|
|
break;
|
|
|
|
default:
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(dev->dev, "invalid cache flag: %x\n",
|
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
|
|
|
(flags & MSM_BO_CACHE_MASK));
|
2013-09-28 23:28:35 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
|
2016-09-29 07:58:32 +08:00
|
|
|
msm_obj = kzalloc(sizeof(*msm_obj), GFP_KERNEL);
|
2013-09-28 23:28:35 +08:00
|
|
|
if (!msm_obj)
|
|
|
|
return -ENOMEM;
|
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
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_init(&msm_obj->lock);
|
|
|
|
|
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
|
|
|
msm_obj->flags = flags;
|
2016-05-18 03:44:49 +08:00
|
|
|
msm_obj->madv = MSM_MADV_WILLNEED;
|
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
|
|
|
INIT_LIST_HEAD(&msm_obj->submit_entry);
|
2017-06-14 01:54:13 +08:00
|
|
|
INIT_LIST_HEAD(&msm_obj->vmas);
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
if (struct_mutex_locked) {
|
|
|
|
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
|
|
|
|
list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
|
|
|
|
} else {
|
|
|
|
mutex_lock(&dev->struct_mutex);
|
|
|
|
list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
}
|
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-09-28 23:28:35 +08:00
|
|
|
*obj = &msm_obj->base;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
static struct drm_gem_object *_msm_gem_new(struct drm_device *dev,
|
|
|
|
uint32_t size, uint32_t flags, bool struct_mutex_locked)
|
2013-09-28 23:28:35 +08:00
|
|
|
{
|
2017-06-13 23:50:05 +08:00
|
|
|
struct msm_drm_private *priv = dev->dev_private;
|
2013-11-17 01:56:06 +08:00
|
|
|
struct drm_gem_object *obj = NULL;
|
2017-06-13 23:50:05 +08:00
|
|
|
bool use_vram = false;
|
2013-09-28 23:28:35 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
size = PAGE_ALIGN(size);
|
|
|
|
|
2018-11-15 06:08:04 +08:00
|
|
|
if (!msm_use_mmu(dev))
|
2017-06-13 23:50:05 +08:00
|
|
|
use_vram = true;
|
2018-11-22 09:52:30 +08:00
|
|
|
else if ((flags & (MSM_BO_STOLEN | MSM_BO_SCANOUT)) && priv->vram.size)
|
2017-06-13 23:50:05 +08:00
|
|
|
use_vram = true;
|
|
|
|
|
|
|
|
if (WARN_ON(use_vram && !priv->vram.size))
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2017-03-08 01:02:51 +08:00
|
|
|
/* Disallow zero sized objects as they make the underlying
|
|
|
|
* infrastructure grumpy
|
|
|
|
*/
|
|
|
|
if (size == 0)
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2019-06-15 04:36:01 +08:00
|
|
|
ret = msm_gem_new_impl(dev, size, flags, &obj, struct_mutex_locked);
|
2013-09-28 23:28:35 +08:00
|
|
|
if (ret)
|
|
|
|
goto fail;
|
|
|
|
|
2017-06-13 23:50:05 +08:00
|
|
|
if (use_vram) {
|
2017-06-14 01:54:13 +08:00
|
|
|
struct msm_gem_vma *vma;
|
2017-06-13 23:50:05 +08:00
|
|
|
struct page **pages;
|
2017-07-30 20:42:36 +08:00
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(obj);
|
|
|
|
|
|
|
|
mutex_lock(&msm_obj->lock);
|
2017-06-13 23:50:05 +08:00
|
|
|
|
2017-06-14 01:54:13 +08:00
|
|
|
vma = add_vma(obj, NULL);
|
2017-07-30 20:42:36 +08:00
|
|
|
mutex_unlock(&msm_obj->lock);
|
2017-06-14 01:54:13 +08:00
|
|
|
if (IS_ERR(vma)) {
|
|
|
|
ret = PTR_ERR(vma);
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
to_msm_bo(obj)->vram_node = &vma->node;
|
|
|
|
|
2017-06-13 23:50:05 +08:00
|
|
|
drm_gem_private_object_init(dev, obj, size);
|
|
|
|
|
|
|
|
pages = get_pages(obj);
|
|
|
|
if (IS_ERR(pages)) {
|
|
|
|
ret = PTR_ERR(pages);
|
|
|
|
goto fail;
|
|
|
|
}
|
2017-06-14 01:54:13 +08:00
|
|
|
|
|
|
|
vma->iova = physaddr(obj);
|
2017-06-13 23:50:05 +08:00
|
|
|
} else {
|
2013-11-17 01:56:06 +08:00
|
|
|
ret = drm_gem_object_init(dev, obj, size);
|
|
|
|
if (ret)
|
|
|
|
goto fail;
|
2019-02-28 14:23:29 +08:00
|
|
|
/*
|
|
|
|
* Our buffers are kept pinned, so allocating them from the
|
|
|
|
* MOVABLE zone is a really bad idea, and conflicts with CMA.
|
|
|
|
* See comments above new_inode() why this is required _and_
|
|
|
|
* expected if you're going to pin these pages.
|
|
|
|
*/
|
|
|
|
mapping_set_gfp_mask(obj->filp->f_mapping, GFP_HIGHUSER);
|
2013-11-17 01:56:06 +08:00
|
|
|
}
|
2013-09-28 23:28:35 +08:00
|
|
|
|
|
|
|
return obj;
|
|
|
|
|
|
|
|
fail:
|
2018-01-26 11:55:54 +08:00
|
|
|
drm_gem_object_put_unlocked(obj);
|
2013-09-28 23:28:35 +08:00
|
|
|
return ERR_PTR(ret);
|
|
|
|
}
|
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
struct drm_gem_object *msm_gem_new_locked(struct drm_device *dev,
|
|
|
|
uint32_t size, uint32_t flags)
|
|
|
|
{
|
|
|
|
return _msm_gem_new(dev, size, flags, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct drm_gem_object *msm_gem_new(struct drm_device *dev,
|
|
|
|
uint32_t size, uint32_t flags)
|
|
|
|
{
|
|
|
|
return _msm_gem_new(dev, size, flags, false);
|
|
|
|
}
|
|
|
|
|
2013-09-28 23:28:35 +08:00
|
|
|
struct drm_gem_object *msm_gem_import(struct drm_device *dev,
|
2016-03-17 00:40:35 +08:00
|
|
|
struct dma_buf *dmabuf, struct sg_table *sgt)
|
2013-09-28 23:28:35 +08:00
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj;
|
|
|
|
struct drm_gem_object *obj;
|
2016-03-17 00:40:35 +08:00
|
|
|
uint32_t size;
|
2013-09-28 23:28:35 +08:00
|
|
|
int ret, npages;
|
|
|
|
|
2013-11-17 01:56:06 +08:00
|
|
|
/* if we don't have IOMMU, don't bother pretending we can import: */
|
2018-11-15 06:08:04 +08:00
|
|
|
if (!msm_use_mmu(dev)) {
|
2018-10-21 01:49:26 +08:00
|
|
|
DRM_DEV_ERROR(dev->dev, "cannot import without IOMMU\n");
|
2013-11-17 01:56:06 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
|
2016-03-17 00:40:35 +08:00
|
|
|
size = PAGE_ALIGN(dmabuf->size);
|
2013-09-28 23:28:35 +08:00
|
|
|
|
2019-06-15 04:36:01 +08:00
|
|
|
ret = msm_gem_new_impl(dev, size, MSM_BO_WC, &obj, false);
|
2013-09-28 23:28:35 +08:00
|
|
|
if (ret)
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
drm_gem_private_object_init(dev, obj, size);
|
|
|
|
|
|
|
|
npages = size / PAGE_SIZE;
|
|
|
|
|
|
|
|
msm_obj = to_msm_bo(obj);
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_lock(&msm_obj->lock);
|
2013-09-28 23:28:35 +08:00
|
|
|
msm_obj->sgt = sgt;
|
2017-05-17 20:23:12 +08:00
|
|
|
msm_obj->pages = kvmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
|
2013-09-28 23:28:35 +08:00
|
|
|
if (!msm_obj->pages) {
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_unlock(&msm_obj->lock);
|
2013-09-28 23:28:35 +08:00
|
|
|
ret = -ENOMEM;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = drm_prime_sg_to_page_addr_arrays(sgt, msm_obj->pages, NULL, npages);
|
2017-06-14 06:52:54 +08:00
|
|
|
if (ret) {
|
|
|
|
mutex_unlock(&msm_obj->lock);
|
2013-09-28 23:28:35 +08:00
|
|
|
goto fail;
|
2017-06-14 06:52:54 +08:00
|
|
|
}
|
2013-09-28 23:28:35 +08:00
|
|
|
|
2017-06-14 06:52:54 +08:00
|
|
|
mutex_unlock(&msm_obj->lock);
|
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 obj;
|
|
|
|
|
|
|
|
fail:
|
2018-01-26 11:55:54 +08:00
|
|
|
drm_gem_object_put_unlocked(obj);
|
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(ret);
|
|
|
|
}
|
2017-07-28 00:42:40 +08:00
|
|
|
|
|
|
|
static void *_msm_gem_kernel_new(struct drm_device *dev, uint32_t size,
|
|
|
|
uint32_t flags, struct msm_gem_address_space *aspace,
|
|
|
|
struct drm_gem_object **bo, uint64_t *iova, bool locked)
|
|
|
|
{
|
|
|
|
void *vaddr;
|
|
|
|
struct drm_gem_object *obj = _msm_gem_new(dev, size, flags, locked);
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (IS_ERR(obj))
|
|
|
|
return ERR_CAST(obj);
|
|
|
|
|
|
|
|
if (iova) {
|
2018-11-08 06:35:50 +08:00
|
|
|
ret = msm_gem_get_and_pin_iova(obj, aspace, iova);
|
2018-11-02 23:25:19 +08:00
|
|
|
if (ret)
|
|
|
|
goto err;
|
2017-07-28 00:42:40 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
vaddr = msm_gem_get_vaddr(obj);
|
2017-10-11 19:36:56 +08:00
|
|
|
if (IS_ERR(vaddr)) {
|
2018-11-08 06:35:51 +08:00
|
|
|
msm_gem_unpin_iova(obj, aspace);
|
2018-11-02 23:25:19 +08:00
|
|
|
ret = PTR_ERR(vaddr);
|
|
|
|
goto err;
|
2017-07-28 00:42:40 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (bo)
|
|
|
|
*bo = obj;
|
|
|
|
|
|
|
|
return vaddr;
|
2018-11-02 23:25:19 +08:00
|
|
|
err:
|
|
|
|
if (locked)
|
|
|
|
drm_gem_object_put(obj);
|
|
|
|
else
|
|
|
|
drm_gem_object_put_unlocked(obj);
|
|
|
|
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
|
2017-07-28 00:42:40 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void *msm_gem_kernel_new(struct drm_device *dev, uint32_t size,
|
|
|
|
uint32_t flags, struct msm_gem_address_space *aspace,
|
|
|
|
struct drm_gem_object **bo, uint64_t *iova)
|
|
|
|
{
|
|
|
|
return _msm_gem_kernel_new(dev, size, flags, aspace, bo, iova, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
void *msm_gem_kernel_new_locked(struct drm_device *dev, uint32_t size,
|
|
|
|
uint32_t flags, struct msm_gem_address_space *aspace,
|
|
|
|
struct drm_gem_object **bo, uint64_t *iova)
|
|
|
|
{
|
|
|
|
return _msm_gem_kernel_new(dev, size, flags, aspace, bo, iova, true);
|
|
|
|
}
|
2018-11-08 06:35:46 +08:00
|
|
|
|
|
|
|
void msm_gem_kernel_put(struct drm_gem_object *bo,
|
|
|
|
struct msm_gem_address_space *aspace, bool locked)
|
|
|
|
{
|
|
|
|
if (IS_ERR_OR_NULL(bo))
|
|
|
|
return;
|
|
|
|
|
|
|
|
msm_gem_put_vaddr(bo);
|
2018-11-08 06:35:51 +08:00
|
|
|
msm_gem_unpin_iova(bo, aspace);
|
2018-11-08 06:35:46 +08:00
|
|
|
|
|
|
|
if (locked)
|
|
|
|
drm_gem_object_put(bo);
|
|
|
|
else
|
|
|
|
drm_gem_object_put_unlocked(bo);
|
|
|
|
}
|
2018-11-08 06:35:52 +08:00
|
|
|
|
|
|
|
void msm_gem_object_set_name(struct drm_gem_object *bo, const char *fmt, ...)
|
|
|
|
{
|
|
|
|
struct msm_gem_object *msm_obj = to_msm_bo(bo);
|
|
|
|
va_list ap;
|
|
|
|
|
|
|
|
if (!fmt)
|
|
|
|
return;
|
|
|
|
|
|
|
|
va_start(ap, fmt);
|
|
|
|
vsnprintf(msm_obj->name, sizeof(msm_obj->name), fmt, ap);
|
|
|
|
va_end(ap);
|
|
|
|
}
|