[radeon-alex:amd-staging-drm-next-vangogh 35/47] drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:89:2: warning: initializer overrides prior initialization of this subobject
Hi Huang,
First bad commit (maybe != root cause):
tree: git://people.freedesktop.org/~agd5f/linux.git
amd-staging-drm-next-vangogh
head: 6067a749d66ef3815908c86ee0b08733e391955f
commit: a7479b81da768e2a9022f62c03b51020d59eae6e [35/47] drm/amd/powerplay: add
vangogh ppt into swSMU
config: arm-randconfig-r021-20200925 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c32e69b2ce7abfb151a87ba363ac9e25abf7d417)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-staging-drm-next-vangogh
git checkout a7479b81da768e2a9022f62c03b51020d59eae6e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:89:2: warning:
>> initializer overrides prior initialization of this subobject
>> [-Winitializer-overrides]
MSG_MAP(AllowGfxOff,PPSMC_MSG_AllowGfxOff,
1),
^~
drivers/gpu/drm/amd/amdgpu/../pm/inc/amdgpu_smu.h:646:20: note: expanded
from macro 'MSG_MAP'
[SMU_MSG_##msg] = {1, (index), (valid_in_vf)}
^~~
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:64:2: note:
previous initialization is here
MSG_MAP(AllowGfxOff,PPSMC_MSG_EnableGfxOff,
1),
^~
drivers/gpu/drm/amd/amdgpu/../pm/inc/amdgpu_smu.h:646:20: note: expanded
from macro 'MSG_MAP'
[SMU_MSG_##msg] = {1, (index), (valid_in_vf)}
^~~
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:90:2: warning:
initializer overrides prior initialization of this subobject
[-Winitializer-overrides]
MSG_MAP(DisallowGfxOff, PPSMC_MSG_DisallowGfxOff,
1),
^~
drivers/gpu/drm/amd/amdgpu/../pm/inc/amdgpu_smu.h:646:20: note: expanded
from macro 'MSG_MAP'
[SMU_MSG_##msg] = {1, (index), (valid_in_vf)}
^~~
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:65:2: note:
previous initialization is here
MSG_MAP(DisallowGfxOff, PPSMC_MSG_DisableGfxOff,
1),
^~
drivers/gpu/drm/amd/amdgpu/../pm/inc/amdgpu_smu.h:646:20: note: expanded
from macro 'MSG_MAP'
[SMU_MSG_##msg] = {1, (index), (valid_in_vf)}
^~~
2 warnings generated.
vim +89 drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c
7bbe7263c3598a3 Xiaojian Du 2020-08-27 44
7bbe7263c3598a3 Xiaojian Du 2020-08-27 45 #define FEATURE_MASK(feature)
(1ULL << feature)
7bbe7263c3598a3 Xiaojian Du 2020-08-27 46 #define SMC_DPM_FEATURE ( \
7bbe7263c3598a3 Xiaojian Du 2020-08-27 47
FEATURE_MASK(FEATURE_CCLK_DPM_BIT) | \
7bbe7263c3598a3 Xiaojian Du 2020-08-27 48
FEATURE_MASK(FEATURE_VCN_DPM_BIT)| \
7bbe7263c3598a3 Xiaojian Du 2020-08-27 49
FEATURE_MASK(FEATURE_FCLK_DPM_BIT) | \
7bbe7263c3598a3 Xiaojian Du 2020-08-27 50
FEATURE_MASK(FEATURE_SOCCLK_DPM_BIT) | \
7bbe7263c3598a3 Xiaojian Du 2020-08-27 51
FEATURE_MASK(FEATURE_MP0CLK_DPM_BIT) | \
7bbe7263c3598a3 Xiaojian Du 2020-08-27 52
FEATURE_MASK(FEATURE_LCLK_DPM_BIT) | \
7bbe7263c3598a3 Xiaojian Du 2020-08-27 53
FEATURE_MASK(FEATURE_SHUBCLK_DPM_BIT)| \
7bbe7263c3598a3 Xiaojian Du 2020-08-27 54
FEATURE_MASK(FEATURE_DCFCLK_DPM_BIT)| \
7bbe7263c3598a3 Xiaojian Du 2020-08-27 55
FEATURE_MASK(FEATURE_GFX_DPM_BIT)| \
7bbe7263c3598a3 Xiaojian Du 2020-08-27 56
FEATURE_MASK(FEATURE_ISP_DPM_BIT)| \
7bbe7263c3598a3 Xiaojian Du 2020-08-27 57
FEATURE_MASK(FEATURE_A55_DPM_BIT)| \
7bbe7263c3598a3 Xiaojian Du 2020-08-27 58
FEATURE_MASK(FEATURE_CVIP_DSP_DPM_BIT))
7bbe7263c3598a3 Xiaojian Du 2020-08-27 59
7bbe7263c3598a3 Xiaojian Du 2020-08-27 60 static struct cmn2asic_msg_mapping
vangogh_mes
[PATCH] drm/msm/dp: DisplayPort PHY compliance tests fixup
Bandwidth code was being used as test link rate. Fix this by converting
bandwidth code to test link rate
Do not reset voltage and pre-emphasis level during IRQ HPD attention
interrupt. Also fix pre-emphasis parsing during test link status process
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 3 ---
drivers/gpu/drm/msm/dp/dp_display.c | 1 +
drivers/gpu/drm/msm/dp/dp_link.c| 12 +++-
drivers/gpu/drm/msm/dp/dp_link.h| 1 +
4 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 2e3e1917351f..872b12689e31 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1643,9 +1643,6 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
if (rc)
return rc;
- ctrl->link->phy_params.p_level = 0;
- ctrl->link->phy_params.v_level = 0;
-
while (--link_train_max_retries &&
!atomic_read(&ctrl->dp_ctrl.aborted)) {
rc = dp_ctrl_reinitialize_mainlink(ctrl);
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index e175aa3fd3a9..ae9989ece73f 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -335,6 +335,7 @@ static int dp_display_process_hpd_high(struct
dp_display_private *dp)
dp->dp_display.max_pclk_khz = DP_MAX_PIXEL_CLK_KHZ;
dp->dp_display.max_dp_lanes = dp->parser->max_dp_lanes;
+ dp_link_reset_phy_params_vx_px(dp->link);
rc = dp_ctrl_on_link(dp->ctrl);
if (rc) {
DRM_ERROR("failed to complete DP link training\n");
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp_link.c
index c811da515fb3..49d7fad36fc4 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -869,6 +869,9 @@ static int dp_link_parse_vx_px(struct dp_link_private *link)
drm_dp_get_adjust_request_voltage(link->link_status, 0);
link->dp_link.phy_params.p_level =
drm_dp_get_adjust_request_pre_emphasis(link->link_status, 0);
+
+ link->dp_link.phy_params.p_level >>= DP_TRAIN_PRE_EMPHASIS_SHIFT;
+
DRM_DEBUG_DP("Requested: v_level = 0x%x, p_level = 0x%x\n",
link->dp_link.phy_params.v_level,
link->dp_link.phy_params.p_level);
@@ -911,7 +914,8 @@ static int dp_link_process_phy_test_pattern_request(
link->request.test_lane_count);
link->dp_link.link_params.num_lanes = link->request.test_lane_count;
- link->dp_link.link_params.rate = link->request.test_link_rate;
+ link->dp_link.link_params.rate =
+ drm_dp_bw_code_to_link_rate(link->request.test_link_rate);
ret = dp_link_parse_vx_px(link);
@@ -1156,6 +1160,12 @@ int dp_link_adjust_levels(struct dp_link *dp_link, u8
*link_status)
return 0;
}
+void dp_link_reset_phy_params_vx_px(struct dp_link *dp_link)
+{
+ dp_link->phy_params.v_level = 0;
+ dp_link->phy_params.p_level = 0;
+}
+
u32 dp_link_get_test_bits_depth(struct dp_link *dp_link, u32 bpp)
{
u32 tbd;
diff --git a/drivers/gpu/drm/msm/dp/dp_link.h b/drivers/gpu/drm/msm/dp/dp_link.h
index 49811b6221e5..9dd4dd926530 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.h
+++ b/drivers/gpu/drm/msm/dp/dp_link.h
@@ -135,6 +135,7 @@ static inline u32 dp_link_bit_depth_to_bpc(u32 tbd)
}
}
+void dp_link_reset_phy_params_vx_px(struct dp_link *dp_link);
u32 dp_link_get_test_bits_depth(struct dp_link *dp_link, u32 bpp);
int dp_link_process_request(struct dp_link *dp_link);
int dp_link_get_colorimetry_config(struct dp_link *dp_link);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 5/6] dma-buf: system_heap: Add pagepool support to system heap
Reuse/abuse the pagepool code from the network code to speed
up allocation performance.
This is similar to the ION pagepool usage, but tries to
utilize generic code instead of a custom implementation.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/Kconfig | 1 +
drivers/dma-buf/heaps/system_heap.c | 32 +
2 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..f13cde4321b1 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -1,6 +1,7 @@
config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
+ select PAGE_POOL
help
Choose this option to enable the system dmabuf heap. The system heap
is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 882a632e9bb7..9f57b4c8ae69 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
struct dma_heap *sys_heap;
@@ -46,6 +47,7 @@ struct dma_heap_attachment {
static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP, LOW_ORDER_GFP};
static const unsigned int orders[] = {8, 4, 0};
#define NUM_ORDERS ARRAY_SIZE(orders)
+struct page_pool *pools[NUM_ORDERS];
static struct sg_table *dup_sg_table(struct sg_table *table)
{
@@ -264,13 +266,17 @@ static void system_heap_dma_buf_release(struct dma_buf
*dmabuf)
struct system_heap_buffer *buffer = dmabuf->priv;
struct sg_table *table;
struct scatterlist *sg;
- int i;
+ int i, j;
table = &buffer->sg_table;
for_each_sg(table->sgl, sg, table->nents, i) {
struct page *page = sg_page(sg);
- __free_pages(page, compound_order(page));
+ for (j = 0; j < NUM_ORDERS; j++) {
+ if (compound_order(page) == orders[j])
+ break;
+ }
+ page_pool_put_full_page(pools[j], page, false);
}
sg_free_table(table);
kfree(buffer);
@@ -300,8 +306,7 @@ static struct page *alloc_largest_available(unsigned long
size,
continue;
if (max_order < orders[i])
continue;
-
- page = alloc_pages(order_flags[i], orders[i]);
+ page = page_pool_alloc_pages(pools[i], order_flags[i]);
if (!page)
continue;
return page;
@@ -406,6 +411,25 @@ static const struct dma_heap_ops system_heap_ops = {
static int system_heap_create(void)
{
struct dma_heap_export_info exp_info;
+ int i;
+
+ for (i = 0; i < NUM_ORDERS; i++) {
+ struct page_pool_params pp;
+
+ memset(&pp, 0, sizeof(pp));
+ pp.order = orders[i];
+ pp.dma_dir = DMA_BIDIRECTIONAL;
+ pools[i] = page_pool_create(&pp);
+
+ if (IS_ERR(pools[i])) {
+ int j;
+
+ pr_err("%s: page pool creation failed!\n", __func__);
+ for (j = 0; j < i; j++)
+ page_pool_destroy(pools[j]);
+ return PTR_ERR(pools[i]);
+ }
+ }
exp_info.name = "system";
exp_info.ops = &system_heap_ops;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 3/6] dma-buf: heaps: Remove heap-helpers code
The heap-helpers code was not as generic as initially hoped
and it is now not being used, so remove it from the tree.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/Makefile | 1 -
drivers/dma-buf/heaps/heap-helpers.c | 271 ---
drivers/dma-buf/heaps/heap-helpers.h | 53 --
3 files changed, 325 deletions(-)
delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c
delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 6e54cdec3da0..974467791032 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,4 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
-obj-y += heap-helpers.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
deleted file mode 100644
index 9f964ca3f59c..
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ /dev/null
@@ -1,271 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "heap-helpers.h"
-
-void init_heap_helper_buffer(struct heap_helper_buffer *buffer,
-void (*free)(struct heap_helper_buffer *))
-{
- buffer->priv_virt = NULL;
- mutex_init(&buffer->lock);
- buffer->vmap_cnt = 0;
- buffer->vaddr = NULL;
- buffer->pagecount = 0;
- buffer->pages = NULL;
- INIT_LIST_HEAD(&buffer->attachments);
- buffer->free = free;
-}
-
-struct dma_buf *heap_helper_export_dmabuf(struct heap_helper_buffer *buffer,
- int fd_flags)
-{
- DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
-
- exp_info.ops = &heap_helper_ops;
- exp_info.size = buffer->size;
- exp_info.flags = fd_flags;
- exp_info.priv = buffer;
-
- return dma_buf_export(&exp_info);
-}
-
-static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
-{
- void *vaddr;
-
- vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, PAGE_KERNEL);
- if (!vaddr)
- return ERR_PTR(-ENOMEM);
-
- return vaddr;
-}
-
-static void dma_heap_buffer_destroy(struct heap_helper_buffer *buffer)
-{
- if (buffer->vmap_cnt > 0) {
- WARN(1, "%s: buffer still mapped in the kernel\n", __func__);
- vunmap(buffer->vaddr);
- }
-
- buffer->free(buffer);
-}
-
-static void *dma_heap_buffer_vmap_get(struct heap_helper_buffer *buffer)
-{
- void *vaddr;
-
- if (buffer->vmap_cnt) {
- buffer->vmap_cnt++;
- return buffer->vaddr;
- }
- vaddr = dma_heap_map_kernel(buffer);
- if (IS_ERR(vaddr))
- return vaddr;
- buffer->vaddr = vaddr;
- buffer->vmap_cnt++;
- return vaddr;
-}
-
-static void dma_heap_buffer_vmap_put(struct heap_helper_buffer *buffer)
-{
- if (!--buffer->vmap_cnt) {
- vunmap(buffer->vaddr);
- buffer->vaddr = NULL;
- }
-}
-
-struct dma_heaps_attachment {
- struct device *dev;
- struct sg_table table;
- struct list_head list;
-};
-
-static int dma_heap_attach(struct dma_buf *dmabuf,
- struct dma_buf_attachment *attachment)
-{
- struct dma_heaps_attachment *a;
- struct heap_helper_buffer *buffer = dmabuf->priv;
- int ret;
-
- a = kzalloc(sizeof(*a), GFP_KERNEL);
- if (!a)
- return -ENOMEM;
-
- ret = sg_alloc_table_from_pages(&a->table, buffer->pages,
- buffer->pagecount, 0,
- buffer->pagecount << PAGE_SHIFT,
- GFP_KERNEL);
- if (ret) {
- kfree(a);
- return ret;
- }
-
- a->dev = attachment->dev;
- INIT_LIST_HEAD(&a->list);
-
- attachment->priv = a;
-
- mutex_lock(&buffer->lock);
- list_add(&a->list, &buffer->attachments);
- mutex_unlock(&buffer->lock);
-
- return 0;
-}
-
-static void dma_heap_detach(struct dma_buf *dmabuf,
- struct dma_buf_attachment *attachment)
-{
- struct dma_heaps_attachment *a = attachment->priv;
- struct heap_helper_buffer *buffer = dmabuf->priv;
-
- mutex_lock(&buffer->lock);
- list_del(&a->list);
- mutex_unlock(&buffer->lock);
-
- sg_free_table(&a->table);
- kfree(a);
-}
-
-static
-struct sg_table *dma_heap_map_dma_
[RFC][PATCH 4/6] dma-buf: system_heap: Allocate higher order pages if available
While the system heap can return non-contiguous pages,
try to allocate larger order pages if possible.
This will allow slight performance gains and make implementing
page pooling easier.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/system_heap.c | 85 ++---
1 file changed, 66 insertions(+), 19 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index ddfa17dc48a8..882a632e9bb7 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -39,6 +39,14 @@ struct dma_heap_attachment {
struct list_head list;
};
+#define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
+ | __GFP_NORETRY) & ~__GFP_RECLAIM) \
+ | __GFP_COMP)
+#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP)
+static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP, LOW_ORDER_GFP};
+static const unsigned int orders[] = {8, 4, 0};
+#define NUM_ORDERS ARRAY_SIZE(orders)
+
static struct sg_table *dup_sg_table(struct sg_table *table)
{
struct sg_table *new_table;
@@ -259,8 +267,11 @@ static void system_heap_dma_buf_release(struct dma_buf
*dmabuf)
int i;
table = &buffer->sg_table;
- for_each_sgtable_sg(table, sg, i)
- __free_page(sg_page(sg));
+ for_each_sg(table->sgl, sg, table->nents, i) {
+ struct page *page = sg_page(sg);
+
+ __free_pages(page, compound_order(page));
+ }
sg_free_table(table);
kfree(buffer);
}
@@ -278,6 +289,26 @@ const struct dma_buf_ops system_heap_buf_ops = {
.release = system_heap_dma_buf_release,
};
+static struct page *alloc_largest_available(unsigned long size,
+ unsigned int max_order)
+{
+ struct page *page;
+ int i;
+
+ for (i = 0; i < NUM_ORDERS; i++) {
+ if (size < (PAGE_SIZE << orders[i]))
+ continue;
+ if (max_order < orders[i])
+ continue;
+
+ page = alloc_pages(order_flags[i], orders[i]);
+ if (!page)
+ continue;
+ return page;
+ }
+ return NULL;
+}
+
static int system_heap_allocate(struct dma_heap *heap,
unsigned long len,
unsigned long fd_flags,
@@ -285,11 +316,13 @@ static int system_heap_allocate(struct dma_heap *heap,
{
struct system_heap_buffer *buffer;
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+ unsigned long size_remaining = len;
+ unsigned int max_order = orders[0];
struct dma_buf *dmabuf;
struct sg_table *table;
struct scatterlist *sg;
- pgoff_t pagecount;
- pgoff_t pg;
+ struct list_head pages;
+ struct page *page, *tmp_page;
int i, ret = -ENOMEM;
buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
@@ -301,25 +334,35 @@ static int system_heap_allocate(struct dma_heap *heap,
buffer->heap = heap;
buffer->len = len;
- table = &buffer->sg_table;
- pagecount = len / PAGE_SIZE;
- if (sg_alloc_table(table, pagecount, GFP_KERNEL))
- goto free_buffer;
-
- sg = table->sgl;
- for (pg = 0; pg < pagecount; pg++) {
- struct page *page;
+ INIT_LIST_HEAD(&pages);
+ i = 0;
+ while (size_remaining > 0) {
/*
* Avoid trying to allocate memory if the process
* has been killed by SIGKILL
*/
if (fatal_signal_pending(current))
- goto free_pages;
- page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ goto free_buffer;
+
+ page = alloc_largest_available(size_remaining, max_order);
if (!page)
- goto free_pages;
- sg_set_page(sg, page, page_size(page), 0);
+ goto free_buffer;
+
+ list_add_tail(&page->lru, &pages);
+ size_remaining -= PAGE_SIZE << compound_order(page);
+ max_order = compound_order(page);
+ i++;
+ }
+
+ table = &buffer->sg_table;
+ if (sg_alloc_table(table, i, GFP_KERNEL))
+ goto free_buffer;
+
+ sg = table->sgl;
+ list_for_each_entry_safe(page, tmp_page, &pages, lru) {
+ sg_set_page(sg, page, PAGE_SIZE << compound_order(page), 0);
sg = sg_next(sg);
+ list_del(&page->lru);
}
/* creat
[RFC][PATCH 2/6] dma-buf: heaps: Move heap-helper logic into the cma_heap implementation
Since the heap-helpers logic ended up not being as generic as
hoped, move the heap-helpers dma_buf_ops implementations into
the cma_heap directly.
This will allow us to remove the heap_helpers code in a following
patch.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/cma_heap.c | 322 ++-
1 file changed, 270 insertions(+), 52 deletions(-)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 626cf7fd033a..3adfdbed0829 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -2,76 +2,291 @@
/*
* DMABUF CMA heap exporter
*
- * Copyright (C) 2012, 2019 Linaro Ltd.
+ * Copyright (C) 2012, 2019, 2020 Linaro Ltd.
* Author: for ST-Ericsson.
+ *
+ * Also utilizing parts of Andrew Davis' SRAM heap:
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
*/
-
#include
-#include
#include
-#include
#include
+#include
+#include
#include
-#include
#include
+#include
+#include
#include
-#include
#include
-#include
+#include
-#include "heap-helpers.h"
struct cma_heap {
struct dma_heap *heap;
struct cma *cma;
};
-static void cma_heap_free(struct heap_helper_buffer *buffer)
+struct cma_heap_buffer {
+ struct cma_heap *heap;
+ struct list_head attachments;
+ struct mutex lock;
+ unsigned long len;
+ struct page *cma_pages;
+ struct page **pages;
+ pgoff_t pagecount;
+ int vmap_cnt;
+ void *vaddr;
+};
+
+struct dma_heap_attachment {
+ struct device *dev;
+ struct sg_table table;
+ struct list_head list;
+};
+
+static int cma_heap_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
{
- struct cma_heap *cma_heap = dma_heap_get_drvdata(buffer->heap);
- unsigned long nr_pages = buffer->pagecount;
- struct page *cma_pages = buffer->priv_virt;
+ struct cma_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a;
+ int ret;
- /* free page list */
- kfree(buffer->pages);
- /* release memory */
- cma_release(cma_heap->cma, cma_pages, nr_pages);
+ a = kzalloc(sizeof(*a), GFP_KERNEL);
+ if (!a)
+ return -ENOMEM;
+
+ ret = sg_alloc_table_from_pages(&a->table, buffer->pages,
+ buffer->pagecount, 0,
+ buffer->pagecount << PAGE_SHIFT,
+ GFP_KERNEL);
+ if (ret) {
+ kfree(a);
+ return ret;
+ }
+
+ a->dev = attachment->dev;
+ INIT_LIST_HEAD(&a->list);
+
+ attachment->priv = a;
+
+ mutex_lock(&buffer->lock);
+ list_add(&a->list, &buffer->attachments);
+ mutex_unlock(&buffer->lock);
+
+ return 0;
+}
+
+static void cma_heap_detatch(struct dma_buf *dmabuf,
+struct dma_buf_attachment *attachment)
+{
+ struct cma_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a = attachment->priv;
+
+ mutex_lock(&buffer->lock);
+ list_del(&a->list);
+ mutex_unlock(&buffer->lock);
+
+ sg_free_table(&a->table);
+ kfree(a);
+}
+
+static struct sg_table *cma_heap_map_dma_buf(struct dma_buf_attachment
*attachment,
+enum dma_data_direction direction)
+{
+ struct dma_heap_attachment *a = attachment->priv;
+ struct sg_table *table = &a->table;
+
+ if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
+ direction))
+ table = ERR_PTR(-ENOMEM);
+ return table;
+}
+
+static void cma_heap_unmap_dma_buf(struct dma_buf_attachment *attachment,
+ struct sg_table *table,
+ enum dma_data_direction direction)
+{
+ dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
+}
+
+static int cma_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
+enum dma_data_direction direction)
+{
+ struct cma_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a;
+ int ret = 0;
+
+ if (buffer->vmap_cnt)
+ invalidate_kernel_vmap_range(buffer->vaddr, buffer->len);
+
+ mutex_lock(&buffer->lock);
+ list_for_each_entry(a, &buffer->attachments, list) {
+ dma_sync_sg_for_cpu(a->dev, a->table.sgl, a->table.nents,
+ direction);
+ }
+ mutex_unlock(&buffer->lock);
+
+
[RFC][PATCH 1/6] dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists
In preparation for some patches to optmize the system
heap code, rework the dmabuf exporter to utilize sgtables rather
then pageslists for tracking the associated pages.
This will allow for large order page allocations, as well as
more efficient page pooling.
In doing so, the system heap stops using the heap-helpers logic
which sadly is not quite as generic as I was hoping it to be, so
this patch adds heap specific implementations of the dma_buf_ops
function handlers.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/system_heap.c | 343
1 file changed, 297 insertions(+), 46 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 0bf688e3c023..ddfa17dc48a8 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -3,7 +3,11 @@
* DMABUF System heap exporter
*
* Copyright (C) 2011 Google, Inc.
- * Copyright (C) 2019 Linaro Ltd.
+ * Copyright (C) 2019, 2020 Linaro Ltd.
+ *
+ * Portions based off of Andrew Davis' SRAM heap:
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
*/
#include
@@ -15,72 +19,320 @@
#include
#include
#include
-#include
-#include
-
-#include "heap-helpers.h"
+#include
struct dma_heap *sys_heap;
-static void system_heap_free(struct heap_helper_buffer *buffer)
+struct system_heap_buffer {
+ struct dma_heap *heap;
+ struct list_head attachments;
+ struct mutex lock;
+ unsigned long len;
+ struct sg_table sg_table;
+ int vmap_cnt;
+ void *vaddr;
+};
+
+struct dma_heap_attachment {
+ struct device *dev;
+ struct sg_table *table;
+ struct list_head list;
+};
+
+static struct sg_table *dup_sg_table(struct sg_table *table)
{
- pgoff_t pg;
+ struct sg_table *new_table;
+ int ret, i;
+ struct scatterlist *sg, *new_sg;
+
+ new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+ if (!new_table)
+ return ERR_PTR(-ENOMEM);
+
+ ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
+ if (ret) {
+ kfree(new_table);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ new_sg = new_table->sgl;
+ for_each_sgtable_sg(table, sg, i) {
+ sg_set_page(new_sg, sg_page(sg), sg->length, sg->offset);
+ new_sg = sg_next(new_sg);
+ }
+
+ return new_table;
+}
+
+static int system_heap_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct system_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a;
+ struct sg_table *table;
+
+ a = kzalloc(sizeof(*a), GFP_KERNEL);
+ if (!a)
+ return -ENOMEM;
+
+ table = dup_sg_table(&buffer->sg_table);
+ if (IS_ERR(table)) {
+ kfree(a);
+ return -ENOMEM;
+ }
+
+ a->table = table;
+ a->dev = attachment->dev;
+ INIT_LIST_HEAD(&a->list);
+
+ attachment->priv = a;
+
+ mutex_lock(&buffer->lock);
+ list_add(&a->list, &buffer->attachments);
+ mutex_unlock(&buffer->lock);
+
+ return 0;
+}
+
+static void system_heap_detatch(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct system_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a = attachment->priv;
+
+ mutex_lock(&buffer->lock);
+ list_del(&a->list);
+ mutex_unlock(&buffer->lock);
+
+ sg_free_table(a->table);
+ kfree(a->table);
+ kfree(a);
+}
+
+static struct sg_table *system_heap_map_dma_buf(struct dma_buf_attachment
*attachment,
+ enum dma_data_direction
direction)
+{
+ struct dma_heap_attachment *a = attachment->priv;
+ struct sg_table *table = a->table;
+
+ if (!dma_map_sg(attachment->dev, table->sgl, table->nents, direction))
+ return ERR_PTR(-ENOMEM);
+
+ return table;
+}
+
+static void system_heap_unmap_dma_buf(struct dma_buf_attachment *attachment,
+ struct sg_table *table,
+ enum dma_data_direction direction)
+{
+ dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
+}
+
+static int system_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
+ enum dma_data_direction
direction)
+{
+ struct system_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a;
+ int ret = 0;
+
+ mutex_loc
[RFC][PATCH 0/6] dma-buf: Performance improvements for system heap
Hey All, So this patch series contains a series of performance optimizations to the dma-buf system heap. Unfortunately, in working these up, I realized the heap-helpers infrastructure we tried to add to miniimize code duplication is not as generic as we intended. For some heaps it makes sense to deal with page lists, for other heaps it makes more sense to track things with sgtables. So this series reworks the system heap to use sgtables, and then consolidates the pagelist method from the heap-helpers into the CMA heap. After which the heap-helpers logic is removed (as it is unused). I'd still like to find a better way to avoid some of the logic duplication in implementing the entire dma_buf_ops handlers per heap. But unfortunately that code is tied somewhat to how the buffer's memory is tracked. After this, the series introduces two optimizations to the the system heap, utilizing large order pages, and adding a page-pool (maybe abusing the pagepool logic from the network code, but it seems silly to reimplement it). I implemented a simple allocation microbenchmark to compare dmabuf heaps vs ion: https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/dma-buf-heap-perf&id=e33aabd34b300f8f8be8d71ec7253dd0abe702f2 With these changes, the allocation path is *much* improved, performing better then ION (though to be fair, the repeated allocating and freeing of the same size buffer is the ideal case for the pagepool logic, so don't read too much into it). I charted some datapoints from the microbenchmark with each of the patches should folks be interested. https://docs.google.com/spreadsheets/d/1-1C8ZQpmkl_0DISkI6z4xelE08MlNAN7oEu34AnO4Ao/edit#gid=0 Finally, a port of a patch that Ørjan Eide implemented for ION that avoids calling sync on attachments that don't have a mapping. Feedback on these would be great! Cc: Sumit Semwal Cc: Liam Mark Cc: Laura Abbott Cc: Brian Starkey Cc: Hridya Valsaraju Cc: Suren Baghdasaryan Cc: Sandeep Patil Cc: Ørjan Eide Cc: Robin Murphy Cc: Ezequiel Garcia Cc: Simon Ser Cc: James Jones Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org John Stultz (6): dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists dma-buf: heaps: Move heap-helper logic into the cma_heap implementation dma-buf: heaps: Remove heap-helpers code dma-buf: system_heap: Allocate higher order pages if available dma-buf: system_heap: Add pagepool support to system heap dma-buf: heaps: Skip sync if not mapped drivers/dma-buf/heaps/Kconfig| 1 + drivers/dma-buf/heaps/Makefile | 1 - drivers/dma-buf/heaps/cma_heap.c | 332 + drivers/dma-buf/heaps/heap-helpers.c | 271 - drivers/dma-buf/heaps/heap-helpers.h | 53 drivers/dma-buf/heaps/system_heap.c | 426 --- 6 files changed, 660 insertions(+), 424 deletions(-) delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 6/6] dma-buf: heaps: Skip sync if not mapped
This patch is basically a port of Ørjan Eide's similar patch for ION
https://lore.kernel.org/lkml/20200414134629.54567-1-orjan.e...@arm.com/
Only sync the sg-list of dma-buf heap attachment when the attachment
is actually mapped on the device.
dma-bufs may be synced at any time. It can be reached from user space
via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when
syncs may be attempted, and dma_buf_end_cpu_access() and
dma_buf_begin_cpu_access() may not be paired.
Since the sg_list's dma_address isn't set up until the buffer is used
on the device, and dma_map_sg() is called on it, the dma_address will be
NULL if sync is attempted on the dma-buf before it's mapped on a device.
Before v5.0 (commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops
into the dma_direct code")) this was a problem as the dma-api (at least
the swiotlb_dma_ops on arm64) would use the potentially invalid
dma_address. How that failed depended on how the device handled physical
address 0. If 0 was a valid address to physical ram, that page would get
flushed a lot, while the actual pages in the buffer would not get synced
correctly. While if 0 is an invalid physical address it may cause a
fault and trigger a crash.
In v5.0 this was incidentally fixed by commit 55897af63091 ("dma-direct:
merge swiotlb_dma_ops into the dma_direct code"), as this moved the
dma-api to use the page pointer in the sg_list, and (for Ion buffers at
least) this will always be valid if the sg_list exists at all.
But, this issue is re-introduced in v5.3 with
commit 449fa54d6815 ("dma-direct: correct the physical addr in
dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old
behaviour and picks the dma_address that may be invalid.
dma-buf core doesn't ensure that the buffer is mapped on the device, and
thus have a valid sg_list, before calling the exporter's
begin_cpu_access.
Logic and commit message originally by: Ørjan Eide
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/cma_heap.c| 10 ++
drivers/dma-buf/heaps/system_heap.c | 10 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 3adfdbed0829..b6ab0392ad9a 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -44,6 +44,7 @@ struct dma_heap_attachment {
struct device *dev;
struct sg_table table;
struct list_head list;
+ bool mapped;
};
static int cma_heap_attach(struct dma_buf *dmabuf,
@@ -68,6 +69,7 @@ static int cma_heap_attach(struct dma_buf *dmabuf,
a->dev = attachment->dev;
INIT_LIST_HEAD(&a->list);
+ a->mapped = false;
attachment->priv = a;
@@ -101,6 +103,7 @@ static struct sg_table *cma_heap_map_dma_buf(struct
dma_buf_attachment *attachme
if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
direction))
table = ERR_PTR(-ENOMEM);
+ a->mapped = true;
return table;
}
@@ -108,6 +111,9 @@ static void cma_heap_unmap_dma_buf(struct
dma_buf_attachment *attachment,
struct sg_table *table,
enum dma_data_direction direction)
{
+ struct dma_heap_attachment *a = attachment->priv;
+
+ a->mapped = false;
dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
}
@@ -123,6 +129,8 @@ static int cma_heap_dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
+ if (!a->mapped)
+ continue;
dma_sync_sg_for_cpu(a->dev, a->table.sgl, a->table.nents,
direction);
}
@@ -142,6 +150,8 @@ static int cma_heap_dma_buf_end_cpu_access(struct dma_buf
*dmabuf,
mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
+ if (!a->mapped)
+ continue;
dma_sync_sg_for_device(a->dev, a->table.sgl, a->table.nents,
direction);
}
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 9f57b4c8ae69..8a523b6fd51a 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -38,6 +38,7 @@ struct dma_heap_attachment {
struct device *dev;
struct sg_table *table;
struct list_head list;
+ bool mapped;
};
#define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
@@ -94,6 +95,7 @@ static int system_heap_attach(struct
[radeon-alex:amd-staging-drm-next-vangogh 35/47] drivers/gpu/drm/amd/amdgpu/../pm/inc/amdgpu_smu.h:646:20: warning: initialized field overwritten
tree: git://people.freedesktop.org/~agd5f/linux.git
amd-staging-drm-next-vangogh
head: 6067a749d66ef3815908c86ee0b08733e391955f
commit: a7479b81da768e2a9022f62c03b51020d59eae6e [35/47] drm/amd/powerplay: add
vangogh ppt into swSMU
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-staging-drm-next-vangogh
git checkout a7479b81da768e2a9022f62c03b51020d59eae6e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=alpha
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:102,
from
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:26:
>> drivers/gpu/drm/amd/amdgpu/../pm/inc/amdgpu_smu.h:646:20: warning:
>> initialized field overwritten [-Woverride-init]
646 | [SMU_MSG_##msg] = {1, (index), (valid_in_vf)}
|^
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:89:2: note: in
expansion of macro 'MSG_MAP'
89 | MSG_MAP(AllowGfxOff,PPSMC_MSG_AllowGfxOff, 1),
| ^~~
drivers/gpu/drm/amd/amdgpu/../pm/inc/amdgpu_smu.h:646:20: note: (near
initialization for 'vangogh_message_map[73]')
646 | [SMU_MSG_##msg] = {1, (index), (valid_in_vf)}
|^
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:89:2: note: in
expansion of macro 'MSG_MAP'
89 | MSG_MAP(AllowGfxOff,PPSMC_MSG_AllowGfxOff, 1),
| ^~~
>> drivers/gpu/drm/amd/amdgpu/../pm/inc/amdgpu_smu.h:646:20: warning:
>> initialized field overwritten [-Woverride-init]
646 | [SMU_MSG_##msg] = {1, (index), (valid_in_vf)}
|^
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:90:2: note: in
expansion of macro 'MSG_MAP'
90 | MSG_MAP(DisallowGfxOff, PPSMC_MSG_DisallowGfxOff,
1),
| ^~~
drivers/gpu/drm/amd/amdgpu/../pm/inc/amdgpu_smu.h:646:20: note: (near
initialization for 'vangogh_message_map[74]')
646 | [SMU_MSG_##msg] = {1, (index), (valid_in_vf)}
|^
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:90:2: note: in
expansion of macro 'MSG_MAP'
90 | MSG_MAP(DisallowGfxOff, PPSMC_MSG_DisallowGfxOff,
1),
| ^~~
In file included from
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:28:
drivers/gpu/drm/amd/amdgpu/../pm/inc/smu_v11_0.h:60:43: warning:
'smu11_thermal_policy' defined but not used [-Wunused-const-variable=]
60 | static const struct smu_temperature_range smu11_thermal_policy[] =
| ^~~~
In file included from
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:26:
drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:197:19: warning:
'no_system_mem_limit' defined but not used [-Wunused-const-variable=]
197 | static const bool no_system_mem_limit;
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:196:19: warning:
'debug_evictions' defined but not used [-Wunused-const-variable=]
196 | static const bool debug_evictions; /* = false */
| ^~~
drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:195:18: warning:
'sched_policy' defined but not used [-Wunused-const-variable=]
195 | static const int sched_policy = KFD_SCHED_POLICY_HWS;
| ^~~~
In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:33,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30,
from
drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26,
from drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:67,
from
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:26:
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:76:32: warning:
'dc_fixpt_ln2_div_2' defined but not used [-Wunused-const-variable=]
76 | static const struct fixed31_32 dc_fixpt_ln2_div_2 = { 1488522236LL };
|^~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:75:32: warning:
'dc_fixpt_ln2' defined but not used [-Wunused-const-variable=]
75 | static const struct fixed31_32 dc_fixpt_ln2 = { 2977044471LL };
|^~~~
[radeon-alex:amd-staging-drm-next-vangogh 494/544] drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:557:6: warning: no previous prototype for function 'amdgpu_virt_update_vf2pf_work_item'
Hi Bokun,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git
amd-staging-drm-next-vangogh
head: 6067a749d66ef3815908c86ee0b08733e391955f
commit: 614e7ac92979c4fe35cca713fa282609839e1be1 [494/544] drm/amdgpu:
Implement new guest side VF2PF message transaction
config: x86_64-randconfig-r035-20200925 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c32e69b2ce7abfb151a87ba363ac9e25abf7d417)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-staging-drm-next-vangogh
git checkout 614e7ac92979c4fe35cca713fa282609839e1be1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:557:6: warning: no previous
>> prototype for function 'amdgpu_virt_update_vf2pf_work_item'
>> [-Wmissing-prototypes]
void amdgpu_virt_update_vf2pf_work_item(struct work_struct *work)
^
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:557:1: note: declare 'static' if
the function is not intended to be used outside of this translation unit
void amdgpu_virt_update_vf2pf_work_item(struct work_struct *work)
^
static
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:586:12: error: no member named
'fw_vram_usage' in 'struct amdgpu_device'
if (adev->fw_vram_usage.va != NULL) {
^
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:591:11: error: no member named
'fw_vram_usage' in 'struct amdgpu_device'
(adev->fw_vram_usage.va +
(AMD_SRIOV_MSG_PF2VF_OFFSET_KB << 10));
^
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:594:11: error: no member named
'fw_vram_usage' in 'struct amdgpu_device'
(adev->fw_vram_usage.va +
(AMD_SRIOV_MSG_VF2PF_OFFSET_KB << 10));
^
1 warning and 3 errors generated.
vim +/amdgpu_virt_update_vf2pf_work_item +557
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
556
> 557 void amdgpu_virt_update_vf2pf_work_item(struct work_struct *work)
558 {
559 struct amdgpu_device *adev = container_of(work, struct
amdgpu_device, virt.vf2pf_work.work);
560
561 amdgpu_virt_read_pf2vf_data(adev);
562 amdgpu_virt_write_vf2pf_data(adev);
563
564 schedule_delayed_work(&(adev->virt.vf2pf_work),
adev->virt.vf2pf_update_interval_ms);
565 }
566
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/msm/dp: fix incorrect function prototype of dp_debug_get()
Fix the incorrect function prototype for dp_debug_get()
in the dp_debug module to address compilation warning.
Also add prototype for msm_dp_debugfs_init() for fixing compilation
issue with other defconfigs.
changes in v2:
- add prototype for msm_dp_debugfs_init()
Fixes: f913454aae8e ("drm/msm/dp: move debugfs node to
/sys/kernel/debug/dri/*/")
Reported-by: kernel test robot
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_debug.h | 2 +-
drivers/gpu/drm/msm/msm_drv.h | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_debug.h
b/drivers/gpu/drm/msm/dp/dp_debug.h
index 377e166fd0ea..7eaedfbb149c 100644
--- a/drivers/gpu/drm/msm/dp/dp_debug.h
+++ b/drivers/gpu/drm/msm/dp/dp_debug.h
@@ -60,7 +60,7 @@ void dp_debug_put(struct dp_debug *dp_debug);
static inline
struct dp_debug *dp_debug_get(struct device *dev, struct dp_panel *panel,
struct dp_usbpd *usbpd, struct dp_link *link,
- struct drm_connector **connector)
+ struct drm_connector **connector, struct drm_minor *minor)
{
return ERR_PTR(-EINVAL);
}
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 319327462b29..9f7849c4ece3 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -435,6 +435,11 @@ static inline void msm_dp_irq_postinstall(struct msm_dp
*dp_display)
{
}
+static inline void msm_dp_debugfs_init(struct msm_dp *dp_display,
+ struct drm_minor *minor)
+{
+}
+
#endif
void __init msm_mdp_register(void);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: remove alloc_vm_area v2
On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote: > this series removes alloc_vm_area, which was left over from the big > vmalloc interface rework. It is a rather arkane interface, basicaly > the equivalent of get_vm_area + actually faulting in all PTEs in > the allocated area. It was originally addeds for Xen (which isn't > modular to start with), and then grew users in zsmalloc and i915 > which seems to mostly qualify as abuses of the interface, especially > for i915 as a random driver should not set up PTE bits directly. > > Note that the i915 patches apply to the drm-tip branch of the drm-tip > tree, as that tree has recent conflicting commits in the same area. Is the drm-tip material in linux-next yet? I'm still seeing a non-trivial reject in there at present. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next-vangogh 494/544] drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:557:6: warning: no previous prototype for function 'amdgpu_virt_update_vf2pf_work_item'
tree: git://people.freedesktop.org/~agd5f/linux.git
amd-staging-drm-next-vangogh
head: 6067a749d66ef3815908c86ee0b08733e391955f
commit: 614e7ac92979c4fe35cca713fa282609839e1be1 [494/544] drm/amdgpu:
Implement new guest side VF2PF message transaction
config: arm-randconfig-r021-20200925 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c32e69b2ce7abfb151a87ba363ac9e25abf7d417)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-staging-drm-next-vangogh
git checkout 614e7ac92979c4fe35cca713fa282609839e1be1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:557:6: warning: no previous
>> prototype for function 'amdgpu_virt_update_vf2pf_work_item'
>> [-Wmissing-prototypes]
void amdgpu_virt_update_vf2pf_work_item(struct work_struct *work)
^
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:557:1: note: declare 'static' if
the function is not intended to be used outside of this translation unit
void amdgpu_virt_update_vf2pf_work_item(struct work_struct *work)
^
static
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:586:12: error: no member named
'fw_vram_usage' in 'struct amdgpu_device'
if (adev->fw_vram_usage.va != NULL) {
^
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:591:11: error: no member named
'fw_vram_usage' in 'struct amdgpu_device'
(adev->fw_vram_usage.va +
(AMD_SRIOV_MSG_PF2VF_OFFSET_KB << 10));
^
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:594:11: error: no member named
'fw_vram_usage' in 'struct amdgpu_device'
(adev->fw_vram_usage.va +
(AMD_SRIOV_MSG_VF2PF_OFFSET_KB << 10));
^
1 warning and 3 errors generated.
vim +/amdgpu_virt_update_vf2pf_work_item +557
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
556
> 557 void amdgpu_virt_update_vf2pf_work_item(struct work_struct *work)
558 {
559 struct amdgpu_device *adev = container_of(work, struct
amdgpu_device, virt.vf2pf_work.work);
560
561 amdgpu_virt_read_pf2vf_data(adev);
562 amdgpu_virt_write_vf2pf_data(adev);
563
564 schedule_delayed_work(&(adev->virt.vf2pf_work),
adev->virt.vf2pf_update_interval_ms);
565 }
566
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: of: fix leak of port_node
Hi Tobias,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.9-rc6 next-20200925]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Tobias-Jordan/drm-of-fix-leak-of-port_node/20200926-063854
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/9acba5320ef136e5d4a3b7563f4b5a362922c818
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Tobias-Jordan/drm-of-fix-leak-of-port_node/20200926-063854
git checkout 9acba5320ef136e5d4a3b7563f4b5a362922c818
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=xtensa
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/drm_of.c: In function 'drm_of_lvds_get_remote_pixels_type':
>> drivers/gpu/drm/drm_of.c:318:16: warning: passing argument 1 of
>> 'of_node_put' discards 'const' qualifier from pointer target type
>> [-Wdiscarded-qualifiers]
318 |of_node_put(port_node);
|^
In file included from include/linux/irqdomain.h:35,
from include/linux/acpi.h:13,
from include/linux/i2c.h:13,
from include/drm/drm_crtc.h:28,
from include/drm/drm_atomic.h:31,
from include/drm/drm_bridge.h:30,
from drivers/gpu/drm/drm_of.c:7:
include/linux/of.h:122:45: note: expected 'struct device_node *' but
argument is of type 'const struct device_node *'
122 | extern void of_node_put(struct device_node *node);
| ^~~~
drivers/gpu/drm/drm_of.c:335:16: warning: passing argument 1 of
'of_node_put' discards 'const' qualifier from pointer target type
[-Wdiscarded-qualifiers]
335 |of_node_put(port_node);
|^
In file included from include/linux/irqdomain.h:35,
from include/linux/acpi.h:13,
from include/linux/i2c.h:13,
from include/drm/drm_crtc.h:28,
from include/drm/drm_atomic.h:31,
from include/drm/drm_bridge.h:30,
from drivers/gpu/drm/drm_of.c:7:
include/linux/of.h:122:45: note: expected 'struct device_node *' but
argument is of type 'const struct device_node *'
122 | extern void of_node_put(struct device_node *node);
| ^~~~
vim +318 drivers/gpu/drm/drm_of.c
302
303 static int drm_of_lvds_get_remote_pixels_type(
304 const struct device_node *port_node)
305 {
306 struct device_node *endpoint = NULL;
307 int pixels_type = -EPIPE;
308
309 for_each_child_of_node(port_node, endpoint) {
310 struct device_node *remote_port;
311 int current_pt;
312
313 if (!of_node_name_eq(endpoint, "endpoint"))
314 continue;
315
316 remote_port = of_graph_get_remote_port(endpoint);
317 if (!remote_port) {
> 318 of_node_put(port_node);
319 return -EPIPE;
320 }
321
322 current_pt =
drm_of_lvds_get_port_pixels_type(remote_port);
323 of_node_put(remote_port);
324 if (pixels_type < 0)
325 pixels_type = current_pt;
326
327 /*
328 * Sanity check, ensure that all remote endpoints have
the same
329 * pixel type. We may lift this restriction later if we
need to
330 * support multiple sinks with different dual-link
331 * configurations by passing the endpoints explicitly to
332 * drm_of_lvds_get_dual_link_pixel_order().
333 */
334 if (!curre
Re: [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()
On Fri, Sep 25, 2020 at 6:08 PM Lyude Paul wrote: > > On Tue, 2020-09-22 at 17:22 -0400, Ilia Mirkin wrote: > > On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote: > > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote: > > > > Can we use 6bpc on arbitrary DP monitors, or is there a capability for > > > > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8? > > > > > > I don't think that display_info.bpc actually implies a minimum bpc, only a > > > maximum bpc iirc (Ville would know the answer to this one). The other > > > thing > > > to > > > note here is that we want to assume the lowest possible bpc here since > > > we're > > > only concerned if the mode passed to ->mode_valid can be set under -any- > > > conditions (including those that require lowering the bpc beyond it's > > > maximum > > > value), so we definitely do want to always use 6bpc here even once we get > > > support for optimizing the bpc based on the available display bandwidth. > > > > Yeah, display_info is the max bpc. But would an average monitor > > support 6bpc? And if it does, does the current link training code even > > try that when display_info.bpc != 6? > > So I did confirm that 6bpc support is mandatory for DP, so yes-6 bpc will > always > work. > > But also, your second comment doesn't really apply here. So: to be clear, > we're > not really concerned here about whether nouveau will actually use 6bpc or not. > In truth I'm not actually sure either if we have any code that uses 6bpc (iirc > we don't), since we don't current optimize bpc. I think it's very possible for > us to use 6bpc for eDP displays if I recall though, but I'm not sure on that. > > But that's also not the point of this code. ->mode_valid() is only used in two > situations in DRM modesetting: when probing connector modes, and when checking > if a mode is valid or not during the atomic check for atomic modesetting. Its > purpose is only to reject display modes that are physically impossible to set > in > hardware due to static hardware constraints. Put another way, we only check > the > given mode against constraints which will always remain constant regardless of > the rest of the display state. An example of a static constraint would be the > max pixel clock supported by the hardware, since on sensible hardware this > never > changes. A dynamic constraint would be something like how much bandwidth is > currently unused on an MST topology, since that value is entirely dependent on > the rest of the display state. > > So - with that said, bpc is technically a dynamic constraint because while a > sink and source both likely have their own bpc limits, any bpc which is equal > or > below that limit can be used depending on what the driver decides - which will > be based on the max_bpc property, and additionally for MST displays it will > also > depend on the available bandwidth on the topology. The only non-dynamic thing > about bpc is that at a minimum, it will be 6 - so any mode that doesn't fit on > the link with a bpc of 6 is guaranteed to be a mode that we'll never be able > to > set and therefore want to prune. > > So, even if we're not using 6 in the majority of situations, I'm fairly > confident it's the right value here. It's also what i915 does as well (and > they > previously had to fix a bug that was the result of assuming a minimum of 8bpc > instead of 6). Here's the situation I'm trying to avoid: 1. Mode is considered "OK" from a bandwidth perspective @6bpc 2. Modesetting logic never tries 6bpc and the modeset fails As long as the two bits of logic agree on what is settable, I'm happy. Cheers, -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 494/499] drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:557:6: warning: no previous prototype for 'amdgpu_virt_update_vf2pf_work_item'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 8f0ba3310c12c3943a8cac39a774e83f55288424
commit: 614e7ac92979c4fe35cca713fa282609839e1be1 [494/499] drm/amdgpu:
Implement new guest side VF2PF message transaction
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-staging-drm-next
git checkout 614e7ac92979c4fe35cca713fa282609839e1be1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=alpha
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:557:6: warning: no previous
>> prototype for 'amdgpu_virt_update_vf2pf_work_item' [-Wmissing-prototypes]
557 | void amdgpu_virt_update_vf2pf_work_item(struct work_struct *work)
| ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c: In function
'amdgpu_virt_init_data_exchange':
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:586:10: error: 'struct
amdgpu_device' has no member named 'fw_vram_usage'
586 | if (adev->fw_vram_usage.va != NULL) {
| ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:591:9: error: 'struct
amdgpu_device' has no member named 'fw_vram_usage'
591 |(adev->fw_vram_usage.va + (AMD_SRIOV_MSG_PF2VF_OFFSET_KB << 10));
| ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:594:9: error: 'struct
amdgpu_device' has no member named 'fw_vram_usage'
594 |(adev->fw_vram_usage.va + (AMD_SRIOV_MSG_VF2PF_OFFSET_KB << 10));
| ^~
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:28:
At top level:
drivers/gpu/drm/amd/amdgpu/amdgpu.h:197:19: warning: 'no_system_mem_limit'
defined but not used [-Wunused-const-variable=]
197 | static const bool no_system_mem_limit;
| ^~~
drivers/gpu/drm/amd/amdgpu/amdgpu.h:196:19: warning: 'debug_evictions'
defined but not used [-Wunused-const-variable=]
196 | static const bool debug_evictions; /* = false */
| ^~~
drivers/gpu/drm/amd/amdgpu/amdgpu.h:195:18: warning: 'sched_policy' defined
but not used [-Wunused-const-variable=]
195 | static const int sched_policy = KFD_SCHED_POLICY_HWS;
| ^~~~
In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:33,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30,
from
drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:67,
from drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:28:
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:76:32: warning:
'dc_fixpt_ln2_div_2' defined but not used [-Wunused-const-variable=]
76 | static const struct fixed31_32 dc_fixpt_ln2_div_2 = { 1488522236LL };
|^~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:75:32: warning:
'dc_fixpt_ln2' defined but not used [-Wunused-const-variable=]
75 | static const struct fixed31_32 dc_fixpt_ln2 = { 2977044471LL };
|^~~~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:74:32: warning:
'dc_fixpt_e' defined but not used [-Wunused-const-variable=]
74 | static const struct fixed31_32 dc_fixpt_e = { 11674931555LL };
|^~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:73:32: warning:
'dc_fixpt_two_pi' defined but not used [-Wunused-const-variable=]
73 | static const struct fixed31_32 dc_fixpt_two_pi = { 26986075409LL };
|^~~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:72:32: warning:
'dc_fixpt_pi' defined but not used [-Wunused-const-variable=]
72 | static const struct fixed31_32 dc_fixpt_pi = { 13493037705LL };
|^~~
vim +/amdgpu_virt_update_vf2pf_work_item +557
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
556
> 557 void amdgpu_virt_update_vf2pf_work_item(struct work_struct *work)
558 {
559 struct amdgpu_device *adev = container_of(work, struct
amdgpu_device, virt.vf2pf_work.work);
560
561 amdgpu_virt_read_pf2vf_data(adev);
562 amdgpu_virt_write_vf2pf_data(adev);
563
564 schedule_delayed_work(&(adev->virt.v
Re: [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()
On Tue, 2020-09-22 at 17:22 -0400, Ilia Mirkin wrote: > On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote: > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote: > > > Can we use 6bpc on arbitrary DP monitors, or is there a capability for > > > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8? > > > > I don't think that display_info.bpc actually implies a minimum bpc, only a > > maximum bpc iirc (Ville would know the answer to this one). The other thing > > to > > note here is that we want to assume the lowest possible bpc here since we're > > only concerned if the mode passed to ->mode_valid can be set under -any- > > conditions (including those that require lowering the bpc beyond it's > > maximum > > value), so we definitely do want to always use 6bpc here even once we get > > support for optimizing the bpc based on the available display bandwidth. > > Yeah, display_info is the max bpc. But would an average monitor > support 6bpc? And if it does, does the current link training code even > try that when display_info.bpc != 6? So I did confirm that 6bpc support is mandatory for DP, so yes-6 bpc will always work. But also, your second comment doesn't really apply here. So: to be clear, we're not really concerned here about whether nouveau will actually use 6bpc or not. In truth I'm not actually sure either if we have any code that uses 6bpc (iirc we don't), since we don't current optimize bpc. I think it's very possible for us to use 6bpc for eDP displays if I recall though, but I'm not sure on that. But that's also not the point of this code. ->mode_valid() is only used in two situations in DRM modesetting: when probing connector modes, and when checking if a mode is valid or not during the atomic check for atomic modesetting. Its purpose is only to reject display modes that are physically impossible to set in hardware due to static hardware constraints. Put another way, we only check the given mode against constraints which will always remain constant regardless of the rest of the display state. An example of a static constraint would be the max pixel clock supported by the hardware, since on sensible hardware this never changes. A dynamic constraint would be something like how much bandwidth is currently unused on an MST topology, since that value is entirely dependent on the rest of the display state. So - with that said, bpc is technically a dynamic constraint because while a sink and source both likely have their own bpc limits, any bpc which is equal or below that limit can be used depending on what the driver decides - which will be based on the max_bpc property, and additionally for MST displays it will also depend on the available bandwidth on the topology. The only non-dynamic thing about bpc is that at a minimum, it will be 6 - so any mode that doesn't fit on the link with a bpc of 6 is guaranteed to be a mode that we'll never be able to set and therefore want to prune. So, even if we're not using 6 in the majority of situations, I'm fairly confident it's the right value here. It's also what i915 does as well (and they previously had to fix a bug that was the result of assuming a minimum of 8bpc instead of 6). > > -ilia > -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/2] drm/rockchip: fix warning from cdn_dp_resume
Commit 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make
cdn_dp_core_suspend/resume static")
introduced the following warning in some builds:
cdn-dp-core.c:1124:12: warning: ‘cdn_dp_resume’ defined but not used
1124 | static int cdn_dp_resume(struct device *dev)
|^
Fix this by defining cdn_dp_resume __maybe_unused
Signed-off-by: Sam Ravnborg
Fixes: 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make
cdn_dp_core_suspend/resume static")
Cc: Enric Balletbo i Serra
Cc: Heiko Stuebner
Cc: Sandy Huang
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: # v5.8+
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index a4a45daf93f2..1162e321aaed 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1121,7 +1121,7 @@ static int cdn_dp_suspend(struct device *dev)
return ret;
}
-static int cdn_dp_resume(struct device *dev)
+static int __maybe_unused cdn_dp_resume(struct device *dev)
{
struct cdn_dp_device *dp = dev_get_drvdata(dev);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/2] drm/rockchip: fix build + warning
Fix a newly introduced build breakge in drm-misc-next Patch 1/2 should be applied to drm-misc-next Also fix a warning in the same driver - the warning is present in v5.8 Patch 2/2 is a drm-misc-fixes candidate Sam Sam Ravnborg (2): drm/rockchip: fix build due to undefined drm_gem_cma_vm_ops drm/rockchip: fix warning from cdn_dp_resume drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/2] drm/rockchip: fix build due to undefined drm_gem_cma_vm_ops
Commit 0d590af3140d ("drm/rockchip: Convert to drm_gem_object_funcs")
introduced the following build error:
rockchip_drm_gem.c:304:13: error: ‘drm_gem_cma_vm_ops’ undeclared here
304 | .vm_ops = &drm_gem_cma_vm_ops,
| ^~
| drm_gem_mmap_obj
Fixed by adding missing include file.
Signed-off-by: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index bb3578469b03..6da15faf0192 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Nouveau wiki migration
Hi everybody, I think it's time to finally move our wiki from the old infrastructure over to gitlab pages. This comes with several benefits: * full control through git over the ikiwiki pipeline (setup files, plugins, system packages, ...) * random users are able to create MRs against the wiki as long as they are willing to create a gitlab account. * possible to migrate over to a different wiki generator or mix and match or whatever. * no CGI stuff on the wiki as we don't use ikiwiki for the git operations anymore To view the migrate wiki visit this URL: https://nouveau.pages.freedesktop.org/wiki/ the gitlab project lives here: https://gitlab.freedesktop.org/nouveau/wiki There are a couple of changes I already made: * convert the perl ikiwiki setup file to yaml: https://gitlab.freedesktop.org/nouveau/wiki/-/blob/master/nouveau.yml * reworked the setup file to throw out unused plugins and adjust settings for gitlab * enabled HTML5 (does change the style slightly, but also fixed some regressions) * pulled in external sources (from the fdo.org server) * moved mdwn files into their own subdirectory For now I changed everything inside one big commit: https://gitlab.freedesktop.org/nouveau/wiki/-/commit/6f2d1669884af186863718ad827f65372a0c5c43 There are a couple of remaining issues/questions: * the gitlab CI pipeline fails quite a bit, which could be annoying * there is a delay between editing and changes going live (usually below a minute though) * should we disallow direct editing of files for project members so we could CI the changes are still valid? Next steps: * verify everything still works * fix remaining issues * final step: point the subdomain to the new gitlab pages URL If anybody else is interested in moving their wikis over, don't hesitate to ask me questions or just copy whatever I did :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH v5 05/38] drm: prime: use sgtable iterators in drm_prime_sg_to_page_addr_arrays()
On Tue, Sep 22, 2020 at 2:28 AM Marek Szyprowski
wrote:
>
> Hi Alex,
>
> On 22.09.2020 01:15, Alex Goins wrote:
> > Tested-by: Alex Goins
> >
> > This change fixes a regression with drm_prime_sg_to_page_addr_arrays() and
> > AMDGPU in v5.9.
>
> Thanks for testing!
>
> > Commit 39913934 similarly revamped AMDGPU to use sgtable helper functions.
> > When
> > it changed from dma_map_sg_attrs() to dma_map_sgtable(), as a side effect it
> > started correctly updating sgt->nents to the return value of
> > dma_map_sg_attrs().
> > However, drm_prime_sg_to_page_addr_arrays() incorrectly uses sgt->nents to
> > iterate over pages, rather than sgt->orig_nents, resulting in it now
> > returning
> > the incorrect number of pages on AMDGPU.
> >
> > I had written a patch that changes drm_prime_sg_to_page_addr_arrays() to use
> > for_each_sgtable_sg() instead of for_each_sg(), iterating using
> > sgt->orig_nents:
> >
> > - for_each_sg(sgt->sgl, sg, sgt->nents, count) {
> > + for_each_sgtable_sg(sgt, sg, count) {
> >
> > This patch takes it further, but still has the effect of fixing the number
> > of
> > pages that drm_prime_sg_to_page_addr_arrays() returns. Something like this
> > should be included in v5.9 to prevent a regression with AMDGPU.
>
> Probably the easiest way to handle a fix for v5.9 would be to simply
> merge the latest version of this patch also to v5.9-rcX:
> https://lore.kernel.org/dri-devel/20200904131711.12950-3-m.szyprow...@samsung.com/
>
>
> This way we would get it fixed and avoid possible conflict in the -next.
> Do you have any AMDGPU fixes for v5.9 in the queue? Maybe you can add
> that patch to the queue? Dave: would it be okay that way?
I think this should go into drm-misc for 5.9 since it's an update to
drm_prime.c. Is that patch ready to merge?
Acked-by: Alex Deucher
Alex
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/nouveau: stop using TTMs fault callback
Tested this on GeForce GT 710
Tested-by: Nirmoy Das
On 9/25/20 4:55 PM, Christian König wrote:
We already implemented the fault handler ourself,
just open code what is necessary here.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 50 ++-
drivers/gpu/drm/nouveau/nouveau_bo.h | 1 +
drivers/gpu/drm/nouveau/nouveau_ttm.c | 10 +++---
3 files changed, 33 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 8d51cfca07c8..1d4b16c0e353 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1226,8 +1226,7 @@ nouveau_ttm_io_mem_free(struct ttm_bo_device *bdev,
struct ttm_resource *reg)
mutex_unlock(&drm->ttm.io_reserve_mutex);
}
-static int
-nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo)
+vm_fault_t nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo)
{
struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
struct nouveau_bo *nvbo = nouveau_bo(bo);
@@ -1243,34 +1242,38 @@ nouveau_ttm_fault_reserve_notify(struct
ttm_buffer_object *bo)
!nvbo->kind)
return 0;
- if (bo->mem.mem_type == TTM_PL_SYSTEM) {
- nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_GART,
-0);
+ if (bo->mem.mem_type != TTM_PL_SYSTEM)
+ return 0;
+
+ nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_GART, 0);
+
+ } else {
+ /* make sure bo is in mappable vram */
+ if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA ||
+ bo->mem.start + bo->mem.num_pages < mappable)
+ return 0;
- ret = nouveau_bo_validate(nvbo, false, false);
- if (ret)
- return ret;
+ for (i = 0; i < nvbo->placement.num_placement; ++i) {
+ nvbo->placements[i].fpfn = 0;
+ nvbo->placements[i].lpfn = mappable;
}
- return 0;
- }
- /* make sure bo is in mappable vram */
- if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA ||
- bo->mem.start + bo->mem.num_pages < mappable)
- return 0;
+ for (i = 0; i < nvbo->placement.num_busy_placement; ++i) {
+ nvbo->busy_placements[i].fpfn = 0;
+ nvbo->busy_placements[i].lpfn = mappable;
+ }
- for (i = 0; i < nvbo->placement.num_placement; ++i) {
- nvbo->placements[i].fpfn = 0;
- nvbo->placements[i].lpfn = mappable;
+ nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_VRAM, 0);
}
- for (i = 0; i < nvbo->placement.num_busy_placement; ++i) {
- nvbo->busy_placements[i].fpfn = 0;
- nvbo->busy_placements[i].lpfn = mappable;
- }
+ ret = nouveau_bo_validate(nvbo, false, false);
+ if (unlikely(ret == -EBUSY || ret == -ERESTARTSYS))
+ return VM_FAULT_NOPAGE;
+ else if (unlikely(ret))
+ return VM_FAULT_SIGBUS;
- nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_VRAM, 0);
- return nouveau_bo_validate(nvbo, false, false);
+ ttm_bo_move_to_lru_tail_unlocked(bo);
+ return 0;
}
static int
@@ -1381,7 +1384,6 @@ struct ttm_bo_driver nouveau_bo_driver = {
.move_notify = nouveau_bo_move_ntfy,
.move = nouveau_bo_move,
.verify_access = nouveau_bo_verify_access,
- .fault_reserve_notify = &nouveau_ttm_fault_reserve_notify,
.io_mem_reserve = &nouveau_ttm_io_mem_reserve,
.io_mem_free = &nouveau_ttm_io_mem_free,
};
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index ff68ded8d590..641ef6298a0e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -89,6 +89,7 @@ void nouveau_bo_placement_set(struct nouveau_bo *, u32 type,
u32 busy);
void nouveau_bo_wr16(struct nouveau_bo *, unsigned index, u16 val);
u32 nouveau_bo_rd32(struct nouveau_bo *, unsigned index);
void nouveau_bo_wr32(struct nouveau_bo *, unsigned index, u32 val);
+vm_fault_t nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo);
void nouveau_bo_fence(struct nouveau_bo *, struct nouveau_fence *, bool
exclusive);
int nouveau_bo_validate(struct nouveau_bo *, bool interruptible,
bool no_wait_gpu);
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 427341753441..edf3bb89a47f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -134,17 +134,19 @@ static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
if (ret)
return ret
Re: [PATCH 3/5] drm/amdgpu: stop using TTMs fault callback
Tested-by: Nirmoy Das
On 9/25/20 4:55 PM, Christian König wrote:
Implement the fault handler ourself using the provided TTM functions.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 20 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 40 +++---
3 files changed, 46 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 63e9c5793c30..80bc7177cd45 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1341,19 +1341,14 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object
*bo)
* Returns:
* 0 for success or a negative error code on failure.
*/
-int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
+vm_fault_t amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
{
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
struct ttm_operation_ctx ctx = { false, false };
- struct amdgpu_bo *abo;
+ struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
unsigned long offset, size;
int r;
- if (!amdgpu_bo_is_amdgpu_bo(bo))
- return 0;
-
- abo = ttm_to_amdgpu_bo(bo);
-
/* Remember that this BO was accessed by the CPU */
abo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
@@ -1367,7 +1362,7 @@ int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
/* Can't move a pinned BO to visible VRAM */
if (abo->tbo.pin_count > 0)
- return -EINVAL;
+ return VM_FAULT_SIGBUS;
/* hurrah the memory is not visible ! */
atomic64_inc(&adev->num_vram_cpu_page_faults);
@@ -1379,15 +1374,18 @@ int amdgpu_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
abo->placement.busy_placement = &abo->placements[1];
r = ttm_bo_validate(bo, &abo->placement, &ctx);
- if (unlikely(r != 0))
- return r;
+ if (unlikely(r == -EBUSY || r == -ERESTARTSYS))
+ return VM_FAULT_NOPAGE;
+ else if (unlikely(r))
+ return VM_FAULT_SIGBUS;
offset = bo->mem.start << PAGE_SHIFT;
/* this should never happen */
if (bo->mem.mem_type == TTM_PL_VRAM &&
(offset + size) > adev->gmc.visible_vram_size)
- return -EINVAL;
+ return VM_FAULT_SIGBUS;
+ ttm_bo_move_to_lru_tail_unlocked(bo);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index e91750e43448..132e5f955180 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -284,7 +284,7 @@ void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
bool evict,
struct ttm_resource *new_mem);
void amdgpu_bo_release_notify(struct ttm_buffer_object *bo);
-int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
+vm_fault_t amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
void amdgpu_bo_fence(struct amdgpu_bo *bo, struct dma_fence *fence,
bool shared);
int amdgpu_bo_sync_wait_resv(struct amdgpu_device *adev, struct dma_resv
*resv,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d3bd2fd448be..399961035ae6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1708,7 +1708,6 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.verify_access = &amdgpu_verify_access,
.move_notify = &amdgpu_bo_move_notify,
.release_notify = &amdgpu_bo_release_notify,
- .fault_reserve_notify = &amdgpu_bo_fault_reserve_notify,
.io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
.io_mem_pfn = amdgpu_ttm_io_mem_pfn,
.access_memory = &amdgpu_ttm_access_memory,
@@ -2088,15 +2087,48 @@ void amdgpu_ttm_set_buffer_funcs_status(struct
amdgpu_device *adev, bool enable)
adev->mman.buffer_funcs_enabled = enable;
}
+static vm_fault_t amdgpu_ttm_fault(struct vm_fault *vmf)
+{
+ struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
+ vm_fault_t ret;
+
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ return ret;
+
+ ret = amdgpu_bo_fault_reserve_notify(bo);
+ if (ret)
+ goto unlock;
+
+ ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
+ TTM_BO_VM_NUM_PREFAULT, 1);
+ if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+ return ret;
+
+unlock:
+ dma_resv_unlock(bo->base.resv);
+ return ret;
+}
+
+static struct vm_operations_struct amdgpu_ttm_vm_ops = {
+ .fault = amdgpu_ttm_fault,
+ .open = ttm_bo_vm_open,
+ .close = ttm_bo_vm_
Re: [PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory
Hi Thomas, On Fri, Sep 25, 2020 at 01:55:57PM +0200, Thomas Zimmermann wrote: > Dma-buf provides vmap() and vunmap() for retriving and releasing mappings > of dma-buf memory in kernel address space. The functions operate with plain > addresses and the assumption is that the memory can be accessed with load > and store operations. This is not the case on some architectures (e.g., > sparc64) where I/O memory can only be accessed with dedicated instructions. > > This patchset introduces struct dma_buf_map, which contains the address of > a buffer and a flag that tells whether system- or I/O-memory instructions > are required. > > Some background: updating the DRM framebuffer console on sparc64 makes the > kernel panic. This is because the framebuffer memory cannot be accessed with > system-memory instructions. We currently employ a workaround in DRM to > address this specific problem. [1] > > To resolve the problem, we'd like to address it at the most common point, > which is the dma-buf framework. The dma-buf mapping ideally knows if I/O > instructions are required and exports this information to it's users. The > new structure struct dma_buf_map stores the buffer address and a flag that > signals I/O memory. Affected users of the buffer (e.g., drivers, frameworks) > can then access the memory accordingly. > > This patchset only introduces struct dma_buf_map, and updates struct dma_buf > and it's interfaces. Further patches can update dma-buf users. For example, > there's a prototype patchset for DRM that fixes the framebuffer problem. [2] > > Further work: TTM, one of DRM's memory managers, already exports an > is_iomem flag of its own. It could later be switched over to exporting struct > dma_buf_map, thus simplifying some code. Several DRM drivers expect their > fbdev console to operate on I/O memory. These could possibly be switched over > to the generic fbdev emulation, as soon as the generic code uses struct > dma_buf_map. > > v3: > * update fastrpc driver (kernel test robot) > * expand documentation (Daniel) > * move documentation into separate patch > v2: > * always clear map parameter in dma_buf_vmap() (Daniel) > * include dma-buf-heaps and i915 selftests (kernel test robot) > * initialize cma_obj before using it in drm_gem_cma_free_object() > (kernel test robot) > > [1] https://lore.kernel.org/dri-devel/20200725191012.ga434...@ravnborg.org/ > [2] > https://lore.kernel.org/dri-devel/20200806085239.4606-1-tzimmerm...@suse.de/ > > Thomas Zimmermann (4): > dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr > dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces > dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces > dma-buf: Document struct dma_buf_map > > Documentation/driver-api/dma-buf.rst | 9 + > drivers/dma-buf/dma-buf.c | 42 ++-- > drivers/dma-buf/heaps/heap-helpers.c | 10 +- > drivers/gpu/drm/drm_gem_cma_helper.c | 20 +- > drivers/gpu/drm/drm_gem_shmem_helper.c| 17 +- > drivers/gpu/drm/drm_prime.c | 15 +- > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 13 +- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 13 +- > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 18 +- > .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 14 +- > drivers/gpu/drm/tegra/gem.c | 23 ++- > .../common/videobuf2/videobuf2-dma-contig.c | 17 +- > .../media/common/videobuf2/videobuf2-dma-sg.c | 19 +- > .../common/videobuf2/videobuf2-vmalloc.c | 21 +- > drivers/misc/fastrpc.c| 6 +- > include/drm/drm_prime.h | 5 +- > include/linux/dma-buf-map.h | 193 ++ > include/linux/dma-buf.h | 11 +- > 18 files changed, 372 insertions(+), 94 deletions(-) > create mode 100644 include/linux/dma-buf-map.h For drivers/media/common/videobuf2 changes: Acked-by: Tomasz Figa Best regards, Tomasz ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.9-rc7
The pull request you sent on Fri, 25 Sep 2020 11:45:04 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-09-25 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/574ec42e1a9c4bfb8b2eef8d801a77e92bcea76a Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
On Thu, 2020-09-24 at 17:46 -0600, Kevin Chowski wrote: > cc back a few others who were unintentionally dropped from the thread > earlier. > > Someone (at Google) helped me dig into this a little more and they > found a document titled "eDP Backlight Brightness bit alignment" sent > out for review in January 2017. I registered for a new account (google > is a member) and have access to the document; here is the URL for > those who also have access: > https://groups.vesa.org/wg/AllMem/document/7786. For what it's worth, > it seems like Lyude's contact Bill Lempesis uploaded this > change-request document, so I think we can reach out to him if we have > further questions. It's actually unclear to me what the status of this > change request is, and whether it's been officially accepted. But I > think it can be seen as some official advice on how we can move > forward here. > > Basically, this is a change request to the spec which acknowledges > that, despite the original spec implying that the > most-significant-bits were relevant here, many implementations used > the least-significant-bits. In defense of most-significant it laid out > some similar arguments to what Ville was saying. But it ends up > saying: > > > Unfortunately, the most common interpretation that we have > > encountered is case 1 in the example above. TCON vendors > > tend to align the valid bits to the LSBs, not the MSBs. > > Instead of changing the default defined functionality (as some earlier > version of this doc apparently suggested), this doc prefers to > allocate two extra bits in EDP_GENERAL_CAPABILITY_2 so that future > backlight devices can specify to the Source how to program them: > > 00: the current functionality, i,e. no defined interpretation > 01: aligned to most-significant bits > 10: aligned to least-significant bits > 11: reserved > > It also says "[Sources] should only need panel-specific workarounds > for the currently available panels." > > So I believe this document is an acknowledgement of many > implementations having their alignment to the least-significant bits, > and (to my eyes) clearly validates that the spec "should" be the > opposite. If we believe the doc's claim that "the most common > interpretation" is least-significant, it seems to me that it would > require more quirks if we made most-significant the default > implementation. > > Ville mentioned at some point earlier that we should try to match the > spec, whereas Lyude mentioned we should prefer to do what the majority > of machines do. What do you both think of this new development? That's how displayport happens to be sometimes :). Definitely isn't the first time something in the spec like this got implemented incorrectly so many times by different vendors that they had to update the spec in response (same thing happened with MST and interleaved sideband messages as of DP 2.0), so I'm really glad we went and actually investigated this. So yes - I think a quirk for this would definitely be a good idea, and IMO we should always lean on the side that more panels implement even if it's not according to spec - so defaulting to the behavior we currently have in the kernel, and adding quirks for panels that were smart enough not to fall for this would probably be the best way to go. That just leaves the challenge of "how do we figure out which panels actually need this and which ones don't?" This might end up being a bit of a challenge, but I've got some ideas on how we might be able to tackle it to the best of our ability based off my discussions with laptop vendors. It seems like some of the homegrown backlight interfaces might help us out here. Note I'm mentioning other laptop vendors here because at least for nouveau, our plan for DPCD backlight support is to move a lot of the code for handling it that currently lives in i915 into shared DRM helpers (which now we'll definitely need to do as a result of these quirks). So, on the x86 front, there's already a few different interfaces in use for laptop panels: * AMD usually uses their own backlight interface, so for AMD-only laptops we can probably safely ignore this * Intel uses their own DPCD backlight interface on most of the _non-ChromeOS_ machines on the market right now afaik based off my discussion with some laptop vendors. For panels that only come up in Intel-only machines, that means we only really need to care about the ChromeOS case here. So-if Google's able to actually survey the devices they're shipping with ChromeOS right now to figure out which ones are using DPCD backlight controls, and which ones need to be MSB aligned - then I'd think we could probably build an accurate quirk list of those panels easily. * This just leaves the nvidia case. Nvidia seems to be one of the only GPU vendors that didn't come up with their own backlight interface over DPCD, and they actually require that the panel support the VESA backlight control interface. Inci
Re: [PATCH v2 4/6] drm/dp: Add LTTPR helpers
On Fri, Sep 25, 2020 at 07:02:47PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 24, 2020 at 09:48:03PM +0300, Imre Deak wrote:
> > Add the helpers and register definitions needed to read out the common
> > and per-PHY LTTPR capabilities and perform link training in the LTTPR
> > non-transparent mode.
> >
> > v2:
> > - Add drm_dp_dpcd_read_phy_link_status() and DP_PHY_LTTPR() here instead
> > of adding these to i915. (Ville)
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Ville Syrjälä
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 244 +++-
> > include/drm/drm_dp_helper.h | 62
> > 2 files changed, 302 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 478dd51f738d..6014c858b06b 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -150,11 +150,8 @@ void drm_dp_link_train_clock_recovery_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE])
> > }
> > EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
> >
> > -void drm_dp_link_train_channel_eq_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE])
> > +static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
> > {
> > - unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > -DP_TRAINING_AUX_RD_MASK;
> > -
> > if (rd_interval > 4)
> > DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
> > rd_interval);
> > @@ -166,8 +163,35 @@ void drm_dp_link_train_channel_eq_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE])
> >
> > usleep_range(rd_interval, rd_interval * 2);
> > }
> > +
> > +void drm_dp_link_train_channel_eq_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE])
> > +{
> > + __drm_dp_link_train_channel_eq_delay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > +DP_TRAINING_AUX_RD_MASK);
> > +}
> > EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
> >
> > +void drm_dp_lttpr_link_train_clock_recovery_delay(void)
> > +{
> > + usleep_range(100, 200);
> > +}
> > +EXPORT_SYMBOL(drm_dp_lttpr_link_train_clock_recovery_delay);
> > +
> > +static u8 dp_lttpr_phy_cap(const u8 phy_cap[DP_LTTPR_PHY_CAP_SIZE], int r)
> > +{
> > + return phy_cap[r - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1];
> > +}
> > +
> > +void drm_dp_lttpr_link_train_channel_eq_delay(const u8
> > phy_cap[DP_LTTPR_PHY_CAP_SIZE])
> > +{
> > + u8 interval = dp_lttpr_phy_cap(phy_cap,
> > +
> > DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1) &
> > + DP_TRAINING_AUX_RD_MASK;
> > +
> > + __drm_dp_link_train_channel_eq_delay(interval);
> > +}
> > +EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
> > +
> > u8 drm_dp_link_rate_to_bw_code(int link_rate)
> > {
> > /* Spec says link_bw = link_rate / 0.27Gbps */
> > @@ -363,6 +387,71 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux
> > *aux,
> > }
> > EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
> >
> > +/**
> > + * drm_dp_dpcd_read_phy_link_status - get the link status information for
> > a DP PHY
> > + * @aux: DisplayPort AUX channel
> > + * @dp_phy: the DP PHY to get the link status for
> > + * @link_status: buffer to return the status in
> > + *
> > + * Fetch the AUX DPCD registers for the DPRX or an LTTPR PHY link status.
> > The
> > + * layout of the returned @link_status matches the DPCD register layout of
> > the
> > + * DPRX PHY link status.
> > + *
> > + * Returns 0 if the information was read successfully or a negative error
> > code
> > + * on failure.
> > + */
> > +int drm_dp_dpcd_read_phy_link_status(struct drm_dp_aux *aux,
> > +enum drm_dp_phy dp_phy,
> > +u8 link_status[DP_LINK_STATUS_SIZE])
> > +{
> > + u8 lttpr_status[DP_LINK_STATUS_SIZE - 1];
> > + int ret;
> > +
> > + if (dp_phy == DP_PHY_DPRX) {
> > + ret = drm_dp_dpcd_read(aux,
> > + DP_LANE0_1_STATUS,
> > + link_status,
> > + DP_LINK_STATUS_SIZE);
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + WARN_ON(ret != DP_LINK_STATUS_SIZE);
> > +
> > + return 0;
> > + }
> > +
> > + ret = drm_dp_dpcd_read(aux,
> > + DP_LANE0_1_STATUS_PHY_REPEATER(dp_phy),
> > + lttpr_status,
> > + sizeof(lttpr_status));
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + WARN_ON(ret != sizeof(lttpr_status));
> > +
> > +#define link_reg(reg) link_status[(reg) - DP_LANE0_1_STATUS]
> > +#define lttpr_reg(reg) lttpr_status[(reg) -
> > DP_LANE0_1_STATUS_PHY_REPEATER1]
> > +
> > + /* Convert the LTTPR to the sink PHY link status layout */
> > + link_reg(DP_LANE0
Re: [PATCH] drm: bridge: cdns-mhdp8546: fix compile warning
On 25/09/2020 15:00, Laurent Pinchart wrote: > On Fri, Sep 25, 2020 at 10:36:44AM +0300, Tomi Valkeinen wrote: >> On 24/09/2020 14:48, Laurent Pinchart wrote: >>> Hi Tomi, >>> >>> Thank you for the patch. >>> >>> On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote: On x64 we get: drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: conversion from 'long unsigned int' to 'unsigned int' changes value from '18446744073709551613' to '4294967293' [-Woverflow] The registers are 32 bit, so fix by casting to u32. >>> >>> I wonder if we need a BIT32 macro... This is a common issue, it would be >>> nice to handle it in the macros that define register fields. >> >> That's probably a good idea. I think >> >> #define BIT32(nr) (1u << (nr)) >> >> should work correct on all archs. Although I'm not quite sure if nr should >> be cast to u32, but in my >> tests a u64 nr doesn't cause type promotion to u64. > > I don't think we need to support nr values larger than 2^32-1 ;-) That's true, but we might have: u64 nr = 1; BIT32(nr) Afaics, we don't need to cast nr to u32, but maybe that's still the safe thing to do. >> Anyway, I'd like to merge this fix as it is to get rid of the warning for >> the merge window. > > Sounds good to me. Was that a reviewed-by? =) Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/6] drm/dp: Add LTTPR helpers
On Thu, Sep 24, 2020 at 09:48:03PM +0300, Imre Deak wrote:
> Add the helpers and register definitions needed to read out the common
> and per-PHY LTTPR capabilities and perform link training in the LTTPR
> non-transparent mode.
>
> v2:
> - Add drm_dp_dpcd_read_phy_link_status() and DP_PHY_LTTPR() here instead
> of adding these to i915. (Ville)
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_helper.c | 244 +++-
> include/drm/drm_dp_helper.h | 62
> 2 files changed, 302 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 478dd51f738d..6014c858b06b 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -150,11 +150,8 @@ void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> }
> EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>
> -void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
> {
> - unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> - DP_TRAINING_AUX_RD_MASK;
> -
> if (rd_interval > 4)
> DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
> rd_interval);
> @@ -166,8 +163,35 @@ void drm_dp_link_train_channel_eq_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
>
> usleep_range(rd_interval, rd_interval * 2);
> }
> +
> +void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + __drm_dp_link_train_channel_eq_delay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_TRAINING_AUX_RD_MASK);
> +}
> EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>
> +void drm_dp_lttpr_link_train_clock_recovery_delay(void)
> +{
> + usleep_range(100, 200);
> +}
> +EXPORT_SYMBOL(drm_dp_lttpr_link_train_clock_recovery_delay);
> +
> +static u8 dp_lttpr_phy_cap(const u8 phy_cap[DP_LTTPR_PHY_CAP_SIZE], int r)
> +{
> + return phy_cap[r - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1];
> +}
> +
> +void drm_dp_lttpr_link_train_channel_eq_delay(const u8
> phy_cap[DP_LTTPR_PHY_CAP_SIZE])
> +{
> + u8 interval = dp_lttpr_phy_cap(phy_cap,
> +
> DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1) &
> + DP_TRAINING_AUX_RD_MASK;
> +
> + __drm_dp_link_train_channel_eq_delay(interval);
> +}
> +EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
> +
> u8 drm_dp_link_rate_to_bw_code(int link_rate)
> {
> /* Spec says link_bw = link_rate / 0.27Gbps */
> @@ -363,6 +387,71 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
> }
> EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>
> +/**
> + * drm_dp_dpcd_read_phy_link_status - get the link status information for a
> DP PHY
> + * @aux: DisplayPort AUX channel
> + * @dp_phy: the DP PHY to get the link status for
> + * @link_status: buffer to return the status in
> + *
> + * Fetch the AUX DPCD registers for the DPRX or an LTTPR PHY link status. The
> + * layout of the returned @link_status matches the DPCD register layout of
> the
> + * DPRX PHY link status.
> + *
> + * Returns 0 if the information was read successfully or a negative error
> code
> + * on failure.
> + */
> +int drm_dp_dpcd_read_phy_link_status(struct drm_dp_aux *aux,
> + enum drm_dp_phy dp_phy,
> + u8 link_status[DP_LINK_STATUS_SIZE])
> +{
> + u8 lttpr_status[DP_LINK_STATUS_SIZE - 1];
> + int ret;
> +
> + if (dp_phy == DP_PHY_DPRX) {
> + ret = drm_dp_dpcd_read(aux,
> +DP_LANE0_1_STATUS,
> +link_status,
> +DP_LINK_STATUS_SIZE);
> +
> + if (ret < 0)
> + return ret;
> +
> + WARN_ON(ret != DP_LINK_STATUS_SIZE);
> +
> + return 0;
> + }
> +
> + ret = drm_dp_dpcd_read(aux,
> +DP_LANE0_1_STATUS_PHY_REPEATER(dp_phy),
> +lttpr_status,
> +sizeof(lttpr_status));
> +
> + if (ret < 0)
> + return ret;
> +
> + WARN_ON(ret != sizeof(lttpr_status));
> +
> +#define link_reg(reg)link_status[(reg) - DP_LANE0_1_STATUS]
> +#define lttpr_reg(reg) lttpr_status[(reg) -
> DP_LANE0_1_STATUS_PHY_REPEATER1]
> +
> + /* Convert the LTTPR to the sink PHY link status layout */
> + link_reg(DP_LANE0_1_STATUS) =
> lttpr_reg(DP_LANE0_1_STATUS_PHY_REPEATER1);
> + link_reg(DP_LANE2_3_STATUS) =
> lttpr_reg(DP_LANE2_3_STATUS_PHY_REPEATER1);
> + link_reg(DP_LANE_ALIGN_STATUS_UPDATED) =
> + lttpr_reg(DP_LANE_ALIGN_STATUS_UPDATED_PHY_REPEATER1);
> +
Re: [PATCH][next] drm/i915: Fix inconsistent IS_ERR and PTR_ERR
Hi all,
Friendly ping: who can take this?
Thanks
--
Gustavo
On 9/10/20 05:21, Gustavo A. R. Silva wrote:
> Fix inconsistent IS_ERR and PTR_ERR in i915_gem_object_copy_blt().
>
> The proper pointer to be passed as argument to PTR_ERR() is vma[1].
>
> This bug was detected with the help of Coccinelle.
>
> Fixes: 6b05030496f7 ("drm/i915: Convert i915_gem_object/client_blt.c to use
> ww locking as well, v2.")
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object_blt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> index d93eb36160c9..aee7ad3cc3c6 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> @@ -364,7 +364,7 @@ int i915_gem_object_copy_blt(struct drm_i915_gem_object
> *src,
>
> vma[1] = i915_vma_instance(dst, vm, NULL);
> if (IS_ERR(vma[1]))
> - return PTR_ERR(vma);
> + return PTR_ERR(vma[1]);
>
> i915_gem_ww_ctx_init(&ww, true);
> intel_engine_pm_get(ce->engine);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: CONFIG_AMDGPU triggers full rebuild
Hi Christian Am 25.09.20 um 16:54 schrieb Christian König: > Maybe MMU notifiers? But honestly I don't know for sure. I checked. In my current config MMU_NOTIFIERS is y and DRM_AMDGPU is n. So it shouldn't have triggered the rebuilds, I guess. Anyway, thanks for trying to help. Best regards Thomas > > Christian. > > Am 25.09.20 um 16:29 schrieb Thomas Zimmermann: >> Hi, >> >> whenever I change the option CONFIG_AMDGPU, I have to rebuild the whole >> kernel. I guess it auto-selects some architecture-specific feature. That >> full rebuild might be avoidable if I could enable that feature permanently. >> >> Any ideas what this could be and how to avoid the full rebuilt? >> >> Best regards >> Thomas >> >> >> ___ >> amd-gfx mailing list >> amd-...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm: Add simplekms driver
Hi Daniel
Am 29.06.20 um 11:06 schrieb Daniel Vetter:
> On Thu, Jun 25, 2020 at 02:00:05PM +0200, Thomas Zimmermann wrote:
>> The simplekms driver is a DRM driver for simplefb framebuffers as
>> provided by the kernel's boot code. This driver enables basic
>> graphical output on many different graphics devices that are provided
>> by the platform (e.g., EFI, VESA, embedded framebuffers).
>>
>> With the kernel's simplefb infrastructure, the kernel receives a
>> pre-configured framebuffer from the system (i.e., firmware, boot
>> loader). It creates a platform device to which simplekms attaches.
>> The system's framebuffer consists of a memory range, size and format.
>> Based on these values, simplekms creates a DRM devices. No actual
>> modesetting is possible.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> MAINTAINERS | 6 +
>> drivers/gpu/drm/tiny/Kconfig | 16 +
>> drivers/gpu/drm/tiny/Makefile| 1 +
>> drivers/gpu/drm/tiny/simplekms.c | 495 +++
>> 4 files changed, 518 insertions(+)
>> create mode 100644 drivers/gpu/drm/tiny/simplekms.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index f17d99164a77..ac517dc8d05d 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -5505,6 +5505,12 @@ S:Orphan / Obsolete
>> F: drivers/gpu/drm/savage/
>> F: include/uapi/drm/savage_drm.h
>>
>> +DRM DRIVER FOR SIMPLE FRAMEBUFFERS
>> +M: Thomas Zimmermann
>> +S: Maintained
>> +T: git git://anongit.freedesktop.org/drm/drm-misc
>> +F: drivers/gpu/drm/tiny/simplekms.c
>> +
>> DRM DRIVER FOR SIS VIDEO CARDS
>> S: Orphan / Obsolete
>> F: drivers/gpu/drm/sis/
>> diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
>> index 2b6414f0fa75..50dbde8bdcb2 100644
>> --- a/drivers/gpu/drm/tiny/Kconfig
>> +++ b/drivers/gpu/drm/tiny/Kconfig
>> @@ -28,6 +28,22 @@ config DRM_GM12U320
>> This is a KMS driver for projectors which use the GM12U320 chipset
>> for video transfer over USB2/3, such as the Acer C120 mini projector.
>>
>> +config DRM_SIMPLEKMS
>> +tristate "Simple framebuffer driver"
>> +depends on DRM
>> +select DRM_GEM_SHMEM_HELPER
>> +select DRM_KMS_HELPER
>> +help
>> + DRM driver for simple platform-provided framebuffers.
>> +
>> + This driver assumes that the display hardware has been initialized
>> + by the firmware or bootloader before the kernel boots. Scanout
>> + buffer, size, and display format must be provided via device tree,
>> + UEFI, VESA, etc.
>> +
>> + On x86 and compatible, you should also select CONFIG_X86_SYSFB to
>> + use UEFI and VESA framebuffers.
>> +
>> config TINYDRM_HX8357D
>> tristate "DRM support for HX8357D display panels"
>> depends on DRM && SPI
>> diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
>> index 6ae4e9e5a35f..e83fbbfa7344 100644
>> --- a/drivers/gpu/drm/tiny/Makefile
>> +++ b/drivers/gpu/drm/tiny/Makefile
>> @@ -2,6 +2,7 @@
>>
>> obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
>> obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
>> +obj-$(CONFIG_DRM_SIMPLEKMS) += simplekms.o
>> obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
>> obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
>> obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
>> diff --git a/drivers/gpu/drm/tiny/simplekms.c
>> b/drivers/gpu/drm/tiny/simplekms.c
>> new file mode 100644
>> index ..dc7cf3983945
>> --- /dev/null
>> +++ b/drivers/gpu/drm/tiny/simplekms.c
>> @@ -0,0 +1,495 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define DRIVER_NAME "simplekms"
>> +#define DRIVER_DESC "DRM driver for simple-framebuffer platform devices"
>> +#define DRIVER_DATE "20200625"
>> +#define DRIVER_MAJOR1
>> +#define DRIVER_MINOR0
>> +
>> +/*
>> + * Assume a monitor resolution of 96 dpi to
>> + * get a somewhat reasonable screen size.
>> + */
>> +#define RES_MM(d) \
>> +(((d) * 254ul) / (96ul * 10ul))
>> +
>> +#define SIMPLEKMS_MODE(hd, vd) \
>> +DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
>> +
>> +/*
>> + * Helpers for simplefb
>> + */
>> +
>> +static int
>> +simplefb_get_validated_int(struct drm_device *dev, const char *name,
>> + uint32_t value)
>> +{
>> +if (value > INT_MAX) {
>> +drm_err(dev, "simplefb: invalid framebuffer %s of %u\n",
>> +name, value);
>> +return -EINVAL;
>> +}
>> +return (int)value;
>> +}
>> +
>> +static int
>> +simplefb_get_validated_int0(struct drm_device *dev, const char *name,
>> +uint32_t value)
>> +{
>> +if (!value) {
>> +drm_err(dev, "simplefb: invalid framebuffer %s of %u\n",
>> +
[PATCH 5/5] drm/ttm: remove fault callback
Another one bites the dust.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 22 --
include/drm/ttm/ttm_bo_driver.h | 3 ---
2 files changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 991ef132e108..87ee8f0ca08e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -290,28 +290,6 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
vm_fault_t ret = VM_FAULT_NOPAGE;
unsigned long address = vmf->address;
- if (bdev->driver->fault_reserve_notify) {
- struct dma_fence *moving = dma_fence_get(bo->moving);
-
- err = bdev->driver->fault_reserve_notify(bo);
- switch (err) {
- case 0:
- break;
- case -EBUSY:
- case -ERESTARTSYS:
- dma_fence_put(moving);
- return VM_FAULT_NOPAGE;
- default:
- dma_fence_put(moving);
- return VM_FAULT_SIGBUS;
- }
-
- if (bo->moving != moving) {
- ttm_bo_move_to_lru_tail_unlocked(bo);
- }
- dma_fence_put(moving);
- }
-
/*
* Wait for buffer data in transit, due to a pipelined
* move.
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 864afa8f6f18..9897a16c0a9d 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -190,9 +190,6 @@ struct ttm_bo_driver {
void (*move_notify)(struct ttm_buffer_object *bo,
bool evict,
struct ttm_resource *new_mem);
- /* notify the driver we are taking a fault on this BO
-* and have reserved it */
- int (*fault_reserve_notify)(struct ttm_buffer_object *bo);
/**
* notify the driver that we're about to swap out this bo
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/nouveau: stop using TTMs fault callback
We already implemented the fault handler ourself,
just open code what is necessary here.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 50 ++-
drivers/gpu/drm/nouveau/nouveau_bo.h | 1 +
drivers/gpu/drm/nouveau/nouveau_ttm.c | 10 +++---
3 files changed, 33 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 8d51cfca07c8..1d4b16c0e353 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1226,8 +1226,7 @@ nouveau_ttm_io_mem_free(struct ttm_bo_device *bdev,
struct ttm_resource *reg)
mutex_unlock(&drm->ttm.io_reserve_mutex);
}
-static int
-nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo)
+vm_fault_t nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo)
{
struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
struct nouveau_bo *nvbo = nouveau_bo(bo);
@@ -1243,34 +1242,38 @@ nouveau_ttm_fault_reserve_notify(struct
ttm_buffer_object *bo)
!nvbo->kind)
return 0;
- if (bo->mem.mem_type == TTM_PL_SYSTEM) {
- nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_GART,
-0);
+ if (bo->mem.mem_type != TTM_PL_SYSTEM)
+ return 0;
+
+ nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_GART, 0);
+
+ } else {
+ /* make sure bo is in mappable vram */
+ if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA ||
+ bo->mem.start + bo->mem.num_pages < mappable)
+ return 0;
- ret = nouveau_bo_validate(nvbo, false, false);
- if (ret)
- return ret;
+ for (i = 0; i < nvbo->placement.num_placement; ++i) {
+ nvbo->placements[i].fpfn = 0;
+ nvbo->placements[i].lpfn = mappable;
}
- return 0;
- }
- /* make sure bo is in mappable vram */
- if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA ||
- bo->mem.start + bo->mem.num_pages < mappable)
- return 0;
+ for (i = 0; i < nvbo->placement.num_busy_placement; ++i) {
+ nvbo->busy_placements[i].fpfn = 0;
+ nvbo->busy_placements[i].lpfn = mappable;
+ }
- for (i = 0; i < nvbo->placement.num_placement; ++i) {
- nvbo->placements[i].fpfn = 0;
- nvbo->placements[i].lpfn = mappable;
+ nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_VRAM, 0);
}
- for (i = 0; i < nvbo->placement.num_busy_placement; ++i) {
- nvbo->busy_placements[i].fpfn = 0;
- nvbo->busy_placements[i].lpfn = mappable;
- }
+ ret = nouveau_bo_validate(nvbo, false, false);
+ if (unlikely(ret == -EBUSY || ret == -ERESTARTSYS))
+ return VM_FAULT_NOPAGE;
+ else if (unlikely(ret))
+ return VM_FAULT_SIGBUS;
- nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_VRAM, 0);
- return nouveau_bo_validate(nvbo, false, false);
+ ttm_bo_move_to_lru_tail_unlocked(bo);
+ return 0;
}
static int
@@ -1381,7 +1384,6 @@ struct ttm_bo_driver nouveau_bo_driver = {
.move_notify = nouveau_bo_move_ntfy,
.move = nouveau_bo_move,
.verify_access = nouveau_bo_verify_access,
- .fault_reserve_notify = &nouveau_ttm_fault_reserve_notify,
.io_mem_reserve = &nouveau_ttm_io_mem_reserve,
.io_mem_free = &nouveau_ttm_io_mem_free,
};
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index ff68ded8d590..641ef6298a0e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -89,6 +89,7 @@ void nouveau_bo_placement_set(struct nouveau_bo *, u32 type,
u32 busy);
void nouveau_bo_wr16(struct nouveau_bo *, unsigned index, u16 val);
u32 nouveau_bo_rd32(struct nouveau_bo *, unsigned index);
void nouveau_bo_wr32(struct nouveau_bo *, unsigned index, u32 val);
+vm_fault_t nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo);
void nouveau_bo_fence(struct nouveau_bo *, struct nouveau_fence *, bool
exclusive);
int nouveau_bo_validate(struct nouveau_bo *, bool interruptible,
bool no_wait_gpu);
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 427341753441..edf3bb89a47f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -134,17 +134,19 @@ static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
if (ret)
return ret;
- nouveau_bo_del_io_reserve_lru(bo);
+ ret = nouveau_ttm_f
[PATCH 1/5] drm/ttm: move SG flag check into ttm_bo_vm_reserve
Just check earlier if a BO can be page faulted in the first place.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 98a006fc30a5..991ef132e108 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -157,6 +157,15 @@ vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
return VM_FAULT_NOPAGE;
}
+ /*
+* Refuse to fault imported pages. This should be handled
+* (if at all) by redirecting mmap to the exporter.
+*/
+ if (bo->ttm && (bo->ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ dma_resv_unlock(bo->base.resv);
+ return VM_FAULT_SIGBUS;
+ }
+
return 0;
}
EXPORT_SYMBOL(ttm_bo_vm_reserve);
@@ -281,13 +290,6 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
vm_fault_t ret = VM_FAULT_NOPAGE;
unsigned long address = vmf->address;
- /*
-* Refuse to fault imported pages. This should be handled
-* (if at all) by redirecting mmap to the exporter.
-*/
- if (bo->ttm && (bo->ttm->page_flags & TTM_PAGE_FLAG_SG))
- return VM_FAULT_SIGBUS;
-
if (bdev->driver->fault_reserve_notify) {
struct dma_fence *moving = dma_fence_get(bo->moving);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/amdgpu: stop using TTMs fault callback
Implement the fault handler ourself using the provided TTM functions.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 20 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 40 +++---
3 files changed, 46 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 63e9c5793c30..80bc7177cd45 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1341,19 +1341,14 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object
*bo)
* Returns:
* 0 for success or a negative error code on failure.
*/
-int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
+vm_fault_t amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
{
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
struct ttm_operation_ctx ctx = { false, false };
- struct amdgpu_bo *abo;
+ struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
unsigned long offset, size;
int r;
- if (!amdgpu_bo_is_amdgpu_bo(bo))
- return 0;
-
- abo = ttm_to_amdgpu_bo(bo);
-
/* Remember that this BO was accessed by the CPU */
abo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
@@ -1367,7 +1362,7 @@ int amdgpu_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
/* Can't move a pinned BO to visible VRAM */
if (abo->tbo.pin_count > 0)
- return -EINVAL;
+ return VM_FAULT_SIGBUS;
/* hurrah the memory is not visible ! */
atomic64_inc(&adev->num_vram_cpu_page_faults);
@@ -1379,15 +1374,18 @@ int amdgpu_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
abo->placement.busy_placement = &abo->placements[1];
r = ttm_bo_validate(bo, &abo->placement, &ctx);
- if (unlikely(r != 0))
- return r;
+ if (unlikely(r == -EBUSY || r == -ERESTARTSYS))
+ return VM_FAULT_NOPAGE;
+ else if (unlikely(r))
+ return VM_FAULT_SIGBUS;
offset = bo->mem.start << PAGE_SHIFT;
/* this should never happen */
if (bo->mem.mem_type == TTM_PL_VRAM &&
(offset + size) > adev->gmc.visible_vram_size)
- return -EINVAL;
+ return VM_FAULT_SIGBUS;
+ ttm_bo_move_to_lru_tail_unlocked(bo);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index e91750e43448..132e5f955180 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -284,7 +284,7 @@ void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
bool evict,
struct ttm_resource *new_mem);
void amdgpu_bo_release_notify(struct ttm_buffer_object *bo);
-int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
+vm_fault_t amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
void amdgpu_bo_fence(struct amdgpu_bo *bo, struct dma_fence *fence,
bool shared);
int amdgpu_bo_sync_wait_resv(struct amdgpu_device *adev, struct dma_resv *resv,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d3bd2fd448be..399961035ae6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1708,7 +1708,6 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.verify_access = &amdgpu_verify_access,
.move_notify = &amdgpu_bo_move_notify,
.release_notify = &amdgpu_bo_release_notify,
- .fault_reserve_notify = &amdgpu_bo_fault_reserve_notify,
.io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
.io_mem_pfn = amdgpu_ttm_io_mem_pfn,
.access_memory = &amdgpu_ttm_access_memory,
@@ -2088,15 +2087,48 @@ void amdgpu_ttm_set_buffer_funcs_status(struct
amdgpu_device *adev, bool enable)
adev->mman.buffer_funcs_enabled = enable;
}
+static vm_fault_t amdgpu_ttm_fault(struct vm_fault *vmf)
+{
+ struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
+ vm_fault_t ret;
+
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ return ret;
+
+ ret = amdgpu_bo_fault_reserve_notify(bo);
+ if (ret)
+ goto unlock;
+
+ ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
+ TTM_BO_VM_NUM_PREFAULT, 1);
+ if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+ return ret;
+
+unlock:
+ dma_resv_unlock(bo->base.resv);
+ return ret;
+}
+
+static struct vm_operations_struct amdgpu_ttm_vm_ops = {
+ .fault = amdgpu_ttm_fault,
+ .open = ttm_bo_vm_open,
+ .close = ttm_bo_vm_close,
+ .access = ttm_bo_vm_access
+};
+
int amdgpu_mmap(s
[PATCH 2/5] drm/radeon: stop using TTMs fault callback
We already implemented the fault handler ourself,
just open code what is necessary here.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_object.c | 22 +++
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 29 ++
3 files changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 689426dd8480..8c285eb118f9 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -775,7 +775,7 @@ void radeon_bo_move_notify(struct ttm_buffer_object *bo,
radeon_update_memory_usage(rbo, new_mem->mem_type, 1);
}
-int radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
+vm_fault_t radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
{
struct ttm_operation_ctx ctx = { false, false };
struct radeon_device *rdev;
@@ -798,7 +798,7 @@ int radeon_bo_fault_reserve_notify(struct ttm_buffer_object
*bo)
/* Can't move a pinned BO to visible VRAM */
if (rbo->tbo.pin_count > 0)
- return -EINVAL;
+ return VM_FAULT_SIGBUS;
/* hurrah the memory is not visible ! */
radeon_ttm_placement_from_domain(rbo, RADEON_GEM_DOMAIN_VRAM);
@@ -812,16 +812,20 @@ int radeon_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
r = ttm_bo_validate(bo, &rbo->placement, &ctx);
if (unlikely(r == -ENOMEM)) {
radeon_ttm_placement_from_domain(rbo, RADEON_GEM_DOMAIN_GTT);
- return ttm_bo_validate(bo, &rbo->placement, &ctx);
- } else if (unlikely(r != 0)) {
- return r;
+ r = ttm_bo_validate(bo, &rbo->placement, &ctx);
+ } else if (likely(!r)) {
+ offset = bo->mem.start << PAGE_SHIFT;
+ /* this should never happen */
+ if ((offset + size) > rdev->mc.visible_vram_size)
+ return VM_FAULT_SIGBUS;
}
- offset = bo->mem.start << PAGE_SHIFT;
- /* this should never happen */
- if ((offset + size) > rdev->mc.visible_vram_size)
- return -EINVAL;
+ if (unlikely(r == -EBUSY || r == -ERESTARTSYS))
+ return VM_FAULT_NOPAGE;
+ else if (unlikely(r))
+ return VM_FAULT_SIGBUS;
+ ttm_bo_move_to_lru_tail_unlocked(bo);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index 27cfb64057fe..d606e9a935e3 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -163,7 +163,7 @@ extern int radeon_bo_check_tiling(struct radeon_bo *bo,
bool has_moved,
extern void radeon_bo_move_notify(struct ttm_buffer_object *bo,
bool evict,
struct ttm_resource *new_mem);
-extern int radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
+extern vm_fault_t radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
extern int radeon_bo_get_surface_reg(struct radeon_bo *bo);
extern void radeon_bo_fence(struct radeon_bo *bo, struct radeon_fence *fence,
bool shared);
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index df5cedb2b632..63e38b05a5bc 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -803,7 +803,6 @@ static struct ttm_bo_driver radeon_bo_driver = {
.move = &radeon_bo_move,
.verify_access = &radeon_verify_access,
.move_notify = &radeon_bo_move_notify,
- .fault_reserve_notify = &radeon_bo_fault_reserve_notify,
.io_mem_reserve = &radeon_ttm_io_mem_reserve,
};
@@ -904,17 +903,29 @@ void radeon_ttm_set_active_vram_size(struct radeon_device
*rdev, u64 size)
static vm_fault_t radeon_ttm_fault(struct vm_fault *vmf)
{
- struct ttm_buffer_object *bo;
- struct radeon_device *rdev;
+ struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
+ struct radeon_device *rdev = radeon_get_rdev(bo->bdev);
vm_fault_t ret;
- bo = (struct ttm_buffer_object *)vmf->vma->vm_private_data;
- if (bo == NULL)
- return VM_FAULT_NOPAGE;
-
- rdev = radeon_get_rdev(bo->bdev);
down_read(&rdev->pm.mclk_lock);
- ret = ttm_bo_vm_fault(vmf);
+
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ goto unlock_mclk;
+
+ ret = radeon_bo_fault_reserve_notify(bo);
+ if (ret)
+ goto unlock_resv;
+
+ ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
+ TTM_BO_VM_NUM_PREFAULT, 1);
+ if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+ goto unlock_mclk;
+
+unlock_resv:
+ dma_resv_unlock(bo->base.resv);
+
+unlock_mclk:
Re: [PATCH 1/9] drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip()
Hi
Am 29.06.20 um 10:40 schrieb Daniel Vetter:
> On Thu, Jun 25, 2020 at 02:00:03PM +0200, Thomas Zimmermann wrote:
>> The memcpy's destination buffer might have a different pitch than the
>> source. Support different pitches as function argument.
>>
>> Signed-off-by: Thomas Zimmermann
>
> Reviewed-by: Daniel Vetter
>
> But I do have questions ... why did we allocate a source drm_framebuffer
> with mismatching pitch? That sounds backwards, especially for simplekms.
There's userspace that allocates framebuffers in tiles of 64x64 pixels.
I think I've seen this with Gnome. So if you have a 800x600 display
mode, the allocated framebuffer has a scanline pitch of 832 pixels and
the final 32 pixels are ignored.
In regular drivers, we can handle this with the VGA offset register [1]
or some equivalent. That's obviously not an option with simplekms, so
the different pitch is required.
Best regards
Thomas
[1]
https://web.stanford.edu/class/cs140/projects/pintos/specs/freevga/vga/crtcreg.htm#13
>
> Would be good to add the reasons why we need this to the commit message,
> I'm sure I'll discover it later on eventually.
> -Daniel
>
>> ---
>> drivers/gpu/drm/drm_format_helper.c| 9 +
>> drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
>> drivers/gpu/drm/tiny/cirrus.c | 2 +-
>> include/drm/drm_format_helper.h| 2 +-
>> 4 files changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_format_helper.c
>> b/drivers/gpu/drm/drm_format_helper.c
>> index c043ca364c86..8d5a683afea7 100644
>> --- a/drivers/gpu/drm/drm_format_helper.c
>> +++ b/drivers/gpu/drm/drm_format_helper.c
>> @@ -52,6 +52,7 @@ EXPORT_SYMBOL(drm_fb_memcpy);
>> /**
>> * drm_fb_memcpy_dstclip - Copy clip buffer
>> * @dst: Destination buffer (iomem)
>> + * @dst_pitch: Number of bytes between two consecutive scanlines within dst
>> * @vaddr: Source buffer
>> * @fb: DRM framebuffer
>> * @clip: Clip rectangle area to copy
>> @@ -59,12 +60,12 @@ EXPORT_SYMBOL(drm_fb_memcpy);
>> * This function applies clipping on dst, i.e. the destination is a
>> * full (iomem) framebuffer but only the clip rect content is copied over.
>> */
>> -void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
>> - struct drm_framebuffer *fb,
>> +void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch,
>> + void *vaddr, struct drm_framebuffer *fb,
>> struct drm_rect *clip)
>> {
>> unsigned int cpp = fb->format->cpp[0];
>> -unsigned int offset = clip_offset(clip, fb->pitches[0], cpp);
>> +unsigned int offset = clip_offset(clip, dst_pitch, cpp);
>> size_t len = (clip->x2 - clip->x1) * cpp;
>> unsigned int y, lines = clip->y2 - clip->y1;
>>
>> @@ -73,7 +74,7 @@ void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
>> for (y = 0; y < lines; y++) {
>> memcpy_toio(dst, vaddr, len);
>> vaddr += fb->pitches[0];
>> -dst += fb->pitches[0];
>> +dst += dst_pitch;
>> }
>> }
>> EXPORT_SYMBOL(drm_fb_memcpy_dstclip);
>> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
>> b/drivers/gpu/drm/mgag200/mgag200_mode.c
>> index f16bd278ab7e..7d4f3a62d885 100644
>> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
>> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
>> @@ -1586,7 +1586,7 @@ mgag200_handle_damage(struct mga_device *mdev, struct
>> drm_framebuffer *fb,
>> if (drm_WARN_ON(dev, !vmap))
>> return; /* BUG: SHMEM BO should always be vmapped */
>>
>> -drm_fb_memcpy_dstclip(mdev->vram, vmap, fb, clip);
>> +drm_fb_memcpy_dstclip(mdev->vram, fb->pitches[0], vmap, fb, clip);
>>
>> drm_gem_shmem_vunmap(fb->obj[0], vmap);
>>
>> diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
>> index 744a8e337e41..2dd9e5e31e3d 100644
>> --- a/drivers/gpu/drm/tiny/cirrus.c
>> +++ b/drivers/gpu/drm/tiny/cirrus.c
>> @@ -327,7 +327,7 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer
>> *fb,
>> goto out_dev_exit;
>>
>> if (cirrus->cpp == fb->format->cpp[0])
>> -drm_fb_memcpy_dstclip(cirrus->vram,
>> +drm_fb_memcpy_dstclip(cirrus->vram, fb->pitches[0],
>>vmap, fb, rect);
>>
>> else if (fb->format->cpp[0] == 4 && cirrus->cpp == 2)
>> diff --git a/include/drm/drm_format_helper.h
>> b/include/drm/drm_format_helper.h
>> index 5f9e37032468..2b5036a5fbe7 100644
>> --- a/include/drm/drm_format_helper.h
>> +++ b/include/drm/drm_format_helper.h
>> @@ -11,7 +11,7 @@ struct drm_rect;
>>
>> void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
>> struct drm_rect *clip);
>> -void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
>> +void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch, void
>> *vaddr,
>> struct drm_framebuffer *fb,
>> struc
Re: CONFIG_AMDGPU triggers full rebuild
Maybe MMU notifiers? But honestly I don't know for sure. Christian. Am 25.09.20 um 16:29 schrieb Thomas Zimmermann: Hi, whenever I change the option CONFIG_AMDGPU, I have to rebuild the whole kernel. I guess it auto-selects some architecture-specific feature. That full rebuild might be avoidable if I could enable that feature permanently. Any ideas what this could be and how to avoid the full rebuilt? Best regards Thomas ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: dsi: Use dev_ based logging
Hi Yannick.
On Fri, Sep 25, 2020 at 12:22:33PM +0200, Yannick Fertre wrote:
> Standardize on the dev_ based logging and drop the include of drm_print.h.
The patchs filas to drop the include mentioned here.
> Remove useless dsi_color_from_mipi function.
IMO the dsi_color_from_mipi() was nice, and inlining the helper
is no gain for readability.
Sam
>
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 87 ++-
> 1 file changed, 45 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index 164f79ef6269..93fa8bfd3127 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -76,6 +76,7 @@ enum dsi_color {
>
> struct dw_mipi_dsi_stm {
> void __iomem *base;
> + struct device *dev;
> struct clk *pllref_clk;
> struct dw_mipi_dsi *dsi;
> u32 hw_version;
> @@ -110,23 +111,6 @@ static inline void dsi_update_bits(struct
> dw_mipi_dsi_stm *dsi, u32 reg,
> dsi_write(dsi, reg, (dsi_read(dsi, reg) & ~mask) | val);
> }
>
> -static enum dsi_color dsi_color_from_mipi(enum mipi_dsi_pixel_format fmt)
> -{
> - switch (fmt) {
> - case MIPI_DSI_FMT_RGB888:
> - return DSI_RGB888;
> - case MIPI_DSI_FMT_RGB666:
> - return DSI_RGB666_CONF2;
> - case MIPI_DSI_FMT_RGB666_PACKED:
> - return DSI_RGB666_CONF1;
> - case MIPI_DSI_FMT_RGB565:
> - return DSI_RGB565_CONF1;
> - default:
> - DRM_DEBUG_DRIVER("MIPI color invalid, so we use rgb888\n");
> - }
> - return DSI_RGB888;
> -}
> -
> static int dsi_pll_get_clkout_khz(int clkin_khz, int idf, int ndiv, int odf)
> {
> int divisor = idf * odf;
> @@ -205,14 +189,14 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
> ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_RRS,
>SLEEP_US, TIMEOUT_US);
> if (ret)
> - DRM_DEBUG_DRIVER("!TIMEOUT! waiting REGU, let's continue\n");
> + dev_dbg(dsi->dev, "!TIMEOUT! waiting REGU, let's continue\n");
>
> /* Enable the DSI PLL & wait for its lock */
> dsi_set(dsi, DSI_WRPCR, WRPCR_PLLEN);
> ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_PLLLS,
>SLEEP_US, TIMEOUT_US);
> if (ret)
> - DRM_DEBUG_DRIVER("!TIMEOUT! waiting PLL, let's continue\n");
> + dev_dbg(dsi->dev, "!TIMEOUT! waiting PLL, let's continue\n");
>
> return 0;
> }
> @@ -221,7 +205,7 @@ static void dw_mipi_dsi_phy_power_on(void *priv_data)
> {
> struct dw_mipi_dsi_stm *dsi = priv_data;
>
> - DRM_DEBUG_DRIVER("\n");
> + dev_dbg(dsi->dev, "\n");
>
> /* Enable the DSI wrapper */
> dsi_set(dsi, DSI_WCR, WCR_DSIEN);
> @@ -231,7 +215,7 @@ static void dw_mipi_dsi_phy_power_off(void *priv_data)
> {
> struct dw_mipi_dsi_stm *dsi = priv_data;
>
> - DRM_DEBUG_DRIVER("\n");
> + dev_dbg(dsi->dev, "\n");
>
> /* Disable the DSI wrapper */
> dsi_clear(dsi, DSI_WCR, WCR_DSIEN);
> @@ -244,6 +228,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
> drm_display_mode *mode,
> {
> struct dw_mipi_dsi_stm *dsi = priv_data;
> unsigned int idf, ndiv, odf, pll_in_khz, pll_out_khz;
> + enum mipi_dsi_pixel_format fmt;
> int ret, bpp;
> u32 val;
>
> @@ -267,11 +252,11 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
> drm_display_mode *mode,
>
> if (pll_out_khz > dsi->lane_max_kbps) {
> pll_out_khz = dsi->lane_max_kbps;
> - DRM_WARN("Warning max phy mbps is used\n");
> + dev_warn(dsi->dev, "Warning max phy mbps is used\n");
> }
> if (pll_out_khz < dsi->lane_min_kbps) {
> pll_out_khz = dsi->lane_min_kbps;
> - DRM_WARN("Warning min phy mbps is used\n");
> + dev_warn(dsi->dev, "Warning min phy mbps is used\n");
> }
>
> /* Compute best pll parameters */
> @@ -281,7 +266,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
> drm_display_mode *mode,
> ret = dsi_pll_get_params(dsi, pll_in_khz, pll_out_khz,
>&idf, &ndiv, &odf);
> if (ret)
> - DRM_WARN("Warning dsi_pll_get_params(): bad params\n");
> + dev_warn(dsi->dev, "Warning dsi_pll_get_params(): bad
> params\n");
>
> /* Get the adjusted pll out value */
> pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
> @@ -297,14 +282,31 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
> drm_display_mode *mode,
> /* Select video mode by resetting DSIM bit */
> dsi_clear(dsi, DSI_WCFGR, WCFGR_DSIM);
>
> + switch (format) {
> + case MIPI_DSI_FMT_RGB888:
> + fmt = DSI_RGB888;
> + break;
> + case MIPI_D
Re: [PATCH 0/3] fbdev: stop using compat_alloc_user_space
On Fri, Sep 25, 2020 at 01:31:51PM +0200, Arnd Bergmann wrote: > On Thu, Sep 24, 2020 at 10:54 PM Sam Ravnborg wrote: > > > > Hi Daniel/Arnd. > > > > On Fri, Sep 18, 2020 at 02:48:08PM +0200, Daniel Vetter wrote: > > > On Fri, Sep 18, 2020 at 12:08:10PM +0200, Arnd Bergmann wrote: > > > > The fbdev code uses compat_alloc_user_space in a few of its > > > > compat_ioctl handlers, which tends to be a bit more complicated > > > > and error-prone than calling the underlying handlers directly, > > > > so I would like to remove it completely. > > > > > > > > This modifies two such functions in fbdev, and removes another > > > > one that is completely unused. > > > > > > > > Arnd > > > > > > > > Arnd Bergmann (3): > > > > fbdev: simplify fb_getput_cmap() > > > > fbdev: sbuslib: remove unused FBIOSCURSOR32 helper > > > > fbdev: sbuslib: remove compat_alloc_user_space usage > > > > > > Looks all good, but we're also kinda looking for a new volunteer for > > > handling fbdev patches ... drm-misc commit rights, still not interested? > > > > Hi Daniel - I read the above as an a-b. And Arnd did not take the bait > > it seems. > > Ah right, I meant to reply but then forgot about it. > > I don't really want commit access, thanks for the offer. > > > Hi Arnd. checkpatch complained about some whitespace, which I fixed > > while applying. > > Will push to drm-misc-next tomorrow unless I hear anything else. > > Great, thanks! Pushed now. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
CONFIG_AMDGPU triggers full rebuild
Hi, whenever I change the option CONFIG_AMDGPU, I have to rebuild the whole kernel. I guess it auto-selects some architecture-specific feature. That full rebuild might be avoidable if I could enable that feature permanently. Any ideas what this could be and how to avoid the full rebuilt? Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: rm68200: fix mode to 50fps
Compute new timings to get a framerate of 50fps with a pixel clock
@54Mhz.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
index 2b9e48b0a491..412c0dbcb2b6 100644
--- a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
+++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
@@ -82,15 +82,15 @@ struct rm68200 {
};
static const struct drm_display_mode default_mode = {
- .clock = 52582,
+ .clock = 54000,
.hdisplay = 720,
- .hsync_start = 720 + 38,
- .hsync_end = 720 + 38 + 8,
- .htotal = 720 + 38 + 8 + 38,
+ .hsync_start = 720 + 48,
+ .hsync_end = 720 + 48 + 9,
+ .htotal = 720 + 48 + 9 + 48,
.vdisplay = 1280,
.vsync_start = 1280 + 12,
- .vsync_end = 1280 + 12 + 4,
- .vtotal = 1280 + 12 + 4 + 12,
+ .vsync_end = 1280 + 12 + 5,
+ .vtotal = 1280 + 12 + 5 + 12,
.flags = 0,
.width_mm = 68,
.height_mm = 122,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
On Thu, 24 Sep 2020 at 14:59, Christoph Hellwig wrote:
>
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver. Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
>
> The only practical difference is that alloc_vm_area prefeaults the
> vmalloc area PTEs, which doesn't seem to be required here for the
> kernel memory case (and could be added to vmap using a flag if actually
> required).
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++
> 2 files changed, 59 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 9afa5c4a6bf006..1e1cb245fca778 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -25,6 +25,7 @@ config DRM_I915
> select CRC32
> select SND_HDA_I915 if SND_HDA_CORE
> select CEC_CORE if CEC_NOTIFIER
> + select VMAP_PFN
> help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 6550c0bc824ea2..b519417667eb4b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct
> drm_i915_gem_object *obj)
> return err;
> }
>
> -static inline pte_t iomap_pte(resource_size_t base,
> - dma_addr_t offset,
> - pgprot_t prot)
> -{
> - return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
> -}
> -
> /* The 'mapping' part of i915_gem_object_pin_map() below */
> -static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> -enum i915_map_type type)
> +static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
> + enum i915_map_type type)
> {
> - unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
> - struct sg_table *sgt = obj->mm.pages;
> - pte_t *stack[32], **mem;
> - struct vm_struct *area;
> + unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
> + struct page *stack[32], **pages = stack, *page;
> + struct sgt_iter iter;
> pgprot_t pgprot;
> + void *vaddr;
>
> - if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
> - return NULL;
> -
> - if (GEM_WARN_ON(type == I915_MAP_WC &&
> - !static_cpu_has(X86_FEATURE_PAT)))
> - return NULL;
> -
> - /* A single page can always be kmapped */
> - if (n_pte == 1 && type == I915_MAP_WB) {
> - struct page *page = sg_page(sgt->sgl);
> -
> + switch (type) {
> + default:
> + MISSING_CASE(type);
> + fallthrough;/* to use PAGE_KERNEL anyway */
> + case I915_MAP_WB:
> /*
> * On 32b, highmem using a finite set of indirect PTE (i.e.
> * vmap) to provide virtual mappings of the high pages.
> @@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct
> drm_i915_gem_object *obj,
> * So if the page is beyond the 32b boundary, make an explicit
> * vmap.
> */
> - if (!PageHighMem(page))
> - return page_address(page);
> - }
> -
> - mem = stack;
> - if (n_pte > ARRAY_SIZE(stack)) {
> - /* Too big for stack -- allocate temporary array instead */
> - mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> - if (!mem)
> - return NULL;
> - }
> -
> - area = alloc_vm_area(obj->base.size, mem);
> - if (!area) {
> - if (mem != stack)
> - kvfree(mem);
> - return NULL;
> - }
> -
> - switch (type) {
> - default:
> - MISSING_CASE(type);
> - fallthrough;/* to use PAGE_KERNEL anyway */
> - case I915_MAP_WB:
> + if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
> + return page_address(sg_page(obj->mm.pages->sgl));
> pgprot = PAGE_KERNEL;
> break;
> case I915_MAP_WC:
> @@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct
> drm_i915_gem_object *obj,
> break;
> }
>
> - if (i915_gem_object_has_struct_page(obj)) {
> - struct sgt_iter iter;
> - struct page *page;
> - pte_t **ptes = mem;
> + if (n_pages > ARRAY_SIZE(stack)) {
> + /* Too big for stack -- allocate tempora
Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
On Fri, Sep 25, 2020 at 3:40 PM Christian König wrote: > > Am 25.09.20 um 15:17 schrieb Daniel Vetter: > > [SNIP] > >> Eviction is not a problem because the driver gets asked where to put an > >> evicted BO and then TTM does all the moving. > > Hm I guess then I don't quite get where you see the ping-pong > > happening, I thought that only happens for evicting stuff. > > No, eviction is the nice case. One step after another. > > E.g. from VRAM to GTT, then from GTT to SYSTEM and then eventually > swapped out. > > > But hey not much actual working experience with ttm over here, I'm just > > reading > > :-) I thought the issue is that ttm wants to evict from $something to > > SYSTEM, and to do that the driver first needs to set a GTT mapping for > > the SYSTEM ttm_resource allocation, so that it can use the > > blitter/sdma engine or whatever to move the data over. But for > > swap-in/validation I'm confused how you can end up with the "wrong" > > placement, that feels like a driver bug. > > The problem happens in the other direction and always directly triggered > by the driver. > > > How exactly can you get into a situation with validation where ttm > > gives you SYSTEM, but not GTT and the driver has to fix that up? I'm > > not really following I think, I guess there's something obvious I'm > > missing. > > For example a buffer which was evicted to SYSTEM needs to be moved back > directly to VRAM. > > Or we want to evacuate all buffers from VRAM to SYSTEM because of > hibernation. > > etc Ok, I think I get it. Eviction always goes one step only in the chain (but maybe multiple times as part of an overall eu validate for all the buffers). But swap in can go the entire length in one go. So yeah demidlayering eviction isn't quite the right thing here, since it's not the problem. -Daniel > > Or should we instead move the entire eviction logic out from ttm into > drivers, building it up from helpers? > >> I've been playing with that thought for a while as well, but then > >> decided against it. > >> > >> The main problem I see is that we sometimes need to evict things from > >> other drivers. > >> > >> E.g. when we overcommitted system memory and move things to swap for > >> example. > > Hm yeah ttm has that limit to avoid stepping into the shrinker, > > directly calling into another driver to keep within the limit while > > ignoring that there's other memory users and caches out there still > > feels wrong, it's kinda a parallel world vs shrinker callbacks. And > > there's nothing stopping you from doing the SYSTEM->SWAP movement from > > a shrinker callback with the locking rules we've established around > > dma_resv (just needs to be a trylock). > > > > So feels a bit backwards if we design ttm eviction around this part of it > > ... > > Ok, that's a good point. Need to think about that a bit more then. > > Then drivers which need gtt for > moving stuff out of vram can do that right away. Also, this would > allow us to implement very fancy eviction algorithms like all the > nonsense we're doing in i915 for gtt handling on gen2/3 (but I really > hope that never ever becomes a thing again in future gpus, so this is > maybe more a what-if kind of thing). Not sure how that would look > like, maybe a special validate function which takes a ttm_resource the > driver already found (through evicting stuff or whatever) and then ttm > just does the move and book-keeping and everything. And drivers would > at first only call validate without allowing any eviction. Ofc anyone > without special needs could use the standard eviction function that > validate already has. > >>> Spinning this a bit more, we could have different default eviction > >>> functions with this, e.g. so all the drivers that need gtt mapping for > >>> moving stuff around can share that code, but with specific&flat > >>> control flow instead of lots of ping-ping. And drivers that don't need > >>> gtt mapping (like i915, we just need dma_map_sg which we assume works > >>> always, or something from the ttm dma page pool, which really always > >>> works) can then use something simpler that's completely flat. > >> Ok you need to explain a bit more what exactly the problem with the GTT > >> eviction is here :) > > So the full set of limitations are > > - range limits > > - power-of-two alignement of start > > - some other (smaller) power of two alignment for size (lol) > > - "color", i.e. different caching modes needs at least one page of > > empty space in-between > > > > Stuffing all that into a generic eviction logic is imo silly. On top > > of that we have the eviction collector where we scan the entire thing > > until we've built up a sufficiently big hole, then evict just these > > buffers. If we don't do this then pretty much any big buffer with > > constraints results in the entire GTT getting evicted. Again something > > that's only worth it if you have ridiculous plac
Re: [Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
On 25/09/2020 14:39, Maor Gottlieb wrote:
On 9/25/2020 3:33 PM, Tvrtko Ursulin wrote:
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
+++ b/tools/testing/scatterlist/main.c
@@ -55,14 +55,13 @@ int main(void)
for (i = 0, test = tests; test->expected_segments; test++,
i++) {
struct page *pages[MAX_PAGES];
struct sg_table st;
- int ret;
+ struct scatterlist *sg;
set_pages(pages, test->pfn, test->num_pages);
- ret = __sg_alloc_table_from_pages(&st, pages,
test->num_pages,
- 0, test->size, test->max_seg,
- GFP_KERNEL);
- assert(ret == test->alloc_ret);
+ sg = __sg_alloc_table_from_pages(&st, pages,
test->num_pages, 0,
+ test->size, test->max_seg, NULL, 0, GFP_KERNEL);
+ assert(PTR_ERR_OR_ZERO(sg) == test->alloc_ret);
Some test coverage for relatively complex code would be very
welcomed. Since
the testing framework is already there, even if it bit-rotted a
bit, but
shouldn't be hard to fix.
A few tests to check append/grow works as expected, in terms of
how the end
table looks like given the initial state and some different page
patterns
added to it. And both crossing and not crossing into sg chaining
scenarios.
This function is basic for all RDMA devices and we are pretty
confident
that the old and new flows are tested thoroughly.
Well, since 0-day is reporting that __i915_gem_userptr_alloc_pages is
crashing on this, it probably does need some tests :\
Jason
It is crashing in the regular old flow which already tested.
However, I will add more tests.
Do you want to take some of the commits from
git://people.freedesktop.org/~tursulin/drm-intel sgtest? It would be
fine by me. I can clean up the commit messages if you want.
I will very appreciate it. Thanks
I've pushed a branch with tidied commit messages and a bit re-ordered to
the same location. You can pull and include in your series:
tools/testing/scatterlist: Rejuvenate bit-rotten test
tools/testing/scatterlist: Show errors in human readable form
And "test fixes for sg append" you can squash (minus the sg_table
zeroing) into your patch.
If this plan does not work for you, I can send two of my patches to lkml
independently. What ever you prefer.
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
Am 25.09.20 um 15:17 schrieb Daniel Vetter: [SNIP] Eviction is not a problem because the driver gets asked where to put an evicted BO and then TTM does all the moving. Hm I guess then I don't quite get where you see the ping-pong happening, I thought that only happens for evicting stuff. No, eviction is the nice case. One step after another. E.g. from VRAM to GTT, then from GTT to SYSTEM and then eventually swapped out. But hey not much actual working experience with ttm over here, I'm just reading :-) I thought the issue is that ttm wants to evict from $something to SYSTEM, and to do that the driver first needs to set a GTT mapping for the SYSTEM ttm_resource allocation, so that it can use the blitter/sdma engine or whatever to move the data over. But for swap-in/validation I'm confused how you can end up with the "wrong" placement, that feels like a driver bug. The problem happens in the other direction and always directly triggered by the driver. How exactly can you get into a situation with validation where ttm gives you SYSTEM, but not GTT and the driver has to fix that up? I'm not really following I think, I guess there's something obvious I'm missing. For example a buffer which was evicted to SYSTEM needs to be moved back directly to VRAM. Or we want to evacuate all buffers from VRAM to SYSTEM because of hibernation. etc Or should we instead move the entire eviction logic out from ttm into drivers, building it up from helpers? I've been playing with that thought for a while as well, but then decided against it. The main problem I see is that we sometimes need to evict things from other drivers. E.g. when we overcommitted system memory and move things to swap for example. Hm yeah ttm has that limit to avoid stepping into the shrinker, directly calling into another driver to keep within the limit while ignoring that there's other memory users and caches out there still feels wrong, it's kinda a parallel world vs shrinker callbacks. And there's nothing stopping you from doing the SYSTEM->SWAP movement from a shrinker callback with the locking rules we've established around dma_resv (just needs to be a trylock). So feels a bit backwards if we design ttm eviction around this part of it ... Ok, that's a good point. Need to think about that a bit more then. Then drivers which need gtt for moving stuff out of vram can do that right away. Also, this would allow us to implement very fancy eviction algorithms like all the nonsense we're doing in i915 for gtt handling on gen2/3 (but I really hope that never ever becomes a thing again in future gpus, so this is maybe more a what-if kind of thing). Not sure how that would look like, maybe a special validate function which takes a ttm_resource the driver already found (through evicting stuff or whatever) and then ttm just does the move and book-keeping and everything. And drivers would at first only call validate without allowing any eviction. Ofc anyone without special needs could use the standard eviction function that validate already has. Spinning this a bit more, we could have different default eviction functions with this, e.g. so all the drivers that need gtt mapping for moving stuff around can share that code, but with specific&flat control flow instead of lots of ping-ping. And drivers that don't need gtt mapping (like i915, we just need dma_map_sg which we assume works always, or something from the ttm dma page pool, which really always works) can then use something simpler that's completely flat. Ok you need to explain a bit more what exactly the problem with the GTT eviction is here :) So the full set of limitations are - range limits - power-of-two alignement of start - some other (smaller) power of two alignment for size (lol) - "color", i.e. different caching modes needs at least one page of empty space in-between Stuffing all that into a generic eviction logic is imo silly. On top of that we have the eviction collector where we scan the entire thing until we've built up a sufficiently big hole, then evict just these buffers. If we don't do this then pretty much any big buffer with constraints results in the entire GTT getting evicted. Again something that's only worth it if you have ridiculous placement constraints like these old intel chips. gen2/3 in i915.ko is maybe a bit extreme, but having the driver in control of the eviction code feels like a much better design than ttm inflicting a one-size-fits-all on everyone. Ofc with defaults and building blocks and all that. Yeah, that makes a lot of sense. Christian. -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm/atomic: Pass the full state to CRTC atomic enable/disable
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to shawnguo/for-next drm-intel/for-linux-next linus/master
anholt/for-next v5.9-rc6 next-20200925]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-vc4-hdmi-Support-the-10-12-bit-output/20200925-151211
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/1ceb933c2a3dd89451b7563e66097d05e1df8d2e
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Maxime-Ripard/drm-vc4-hdmi-Support-the-10-12-bit-output/20200925-151211
git checkout 1ceb933c2a3dd89451b7563e66097d05e1df8d2e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>):
drivers/gpu/drm/imx/dcss/dcss-crtc.c: In function 'dcss_crtc_atomic_enable':
>> drivers/gpu/drm/imx/dcss/dcss-crtc.c:82:42: error: implicit declaration of
>> function 'drm_atomic_get_old_crtc_state'
>> [-Werror=implicit-function-declaration]
82 | struct drm_crtc_state *old_crtc_state =
drm_atomic_get_old_crtc_state(state,
|
^
>> drivers/gpu/drm/imx/dcss/dcss-crtc.c:82:42: warning: initialization of
>> 'struct drm_crtc_state *' from 'int' makes pointer from integer without a
>> cast [-Wint-conversion]
drivers/gpu/drm/imx/dcss/dcss-crtc.c: In function 'dcss_crtc_atomic_disable':
drivers/gpu/drm/imx/dcss/dcss-crtc.c:118:42: warning: initialization of
'struct drm_crtc_state *' from 'int' makes pointer from integer without a cast
[-Wint-conversion]
118 | struct drm_crtc_state *old_crtc_state =
drm_atomic_get_old_crtc_state(state,
|
^
cc1: some warnings being treated as errors
vim +/drm_atomic_get_old_crtc_state +82 drivers/gpu/drm/imx/dcss/dcss-crtc.c
78
79 static void dcss_crtc_atomic_enable(struct drm_crtc *crtc,
80 struct drm_atomic_state *state)
81 {
> 82 struct drm_crtc_state *old_crtc_state =
drm_atomic_get_old_crtc_state(state,
83
crtc);
84 struct dcss_crtc *dcss_crtc = container_of(crtc, struct
dcss_crtc,
85 base);
86 struct dcss_dev *dcss = dcss_crtc->base.dev->dev_private;
87 struct drm_display_mode *mode = &crtc->state->adjusted_mode;
88 struct drm_display_mode *old_mode =
&old_crtc_state->adjusted_mode;
89 struct videomode vm;
90
91 drm_display_mode_to_videomode(mode, &vm);
92
93 pm_runtime_get_sync(dcss->dev);
94
95 vm.pixelclock = mode->crtc_clock * 1000;
96
97 dcss_ss_subsam_set(dcss->ss);
98 dcss_dtg_css_set(dcss->dtg);
99
100 if (!drm_mode_equal(mode, old_mode) || !old_crtc_state->active)
{
101 dcss_dtg_sync_set(dcss->dtg, &vm);
102 dcss_ss_sync_set(dcss->ss, &vm,
103 mode->flags & DRM_MODE_FLAG_PHSYNC,
104 mode->flags & DRM_MODE_FLAG_PVSYNC);
105 }
106
107 dcss_enable_dtg_and_ss(dcss);
108
109 dcss_ctxld_enable(dcss->ctxld);
110
111 /* Allow CTXLD kick interrupt to be disabled when VBLANK is
disabled. */
112 dcss_crtc->disable_ctxld_kick_irq = true;
113 }
114
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
On Fri, Sep 25, 2020 at 06:13:00AM -0400, Peilin Ye wrote:
> Hi all!
>
> On Fri, Sep 25, 2020 at 08:46:04AM +0200, Jiri Slaby wrote:
> > > In order to perform a reliable range check, fbcon_get_font() needs to know
> > > `FONTDATAMAX` for each built-in font under lib/fonts/. Unfortunately, we
> > > do not keep that information in our font descriptor,
> > > `struct console_font`:
> > >
> > > (include/uapi/linux/kd.h)
> > > struct console_font {
> > > unsigned int width, height; /* font size */
> > > unsigned int charcount;
> > > unsigned char *data;/* font data with height fixed to 32 */
> > > };
> > >
> > > To make things worse, `struct console_font` is part of the UAPI, so we
> > > cannot add a new field to keep track of `FONTDATAMAX`.
> >
> > Hi,
> >
> > but you still can define struct kernel_console_font containing struct
> > console_font and the 4 more members you need in the kernel. See below.
> >
> > > Fortunately, the framebuffer layer itself gives us a hint of how to
> > > resolve this issue without changing UAPI. When allocating a buffer for a
> > > user-provided font, fbcon_set_font() reserves four "extra words" at the
> > > beginning of the buffer:
> > >
> > > (drivers/video/fbdev/core/fbcon.c)
> > > new_data = kmalloc(FONT_EXTRA_WORDS * sizeof(int) + size, GFP_USER);
> >
> > I might be missing something (like coffee in the morning), but why don't
> > you just:
> > 1) declare struct font_data as
> > {
> > unsigned sum, char_count, size, refcnt;
> > const unsigned char data[];
> > }
> >
> > Or maybe "struct console_font font" instead of "const unsigned char
> > data[]", if need be.
> >
> > 2) allocate by:
> > kmalloc(struct_size(struct font_data, data, size));
> >
> > 3) use container_of wherever needed
> >
> > That is you name the data on negative indexes using struct as you
> > already have to define one.
> >
> > Then you don't need the ugly macros with negative indexes. And you can
> > pass this structure down e.g. to fbcon_do_set_font, avoiding potential
> > mistakes in accessing data[-1] and similar.
>
> Sorry that I didn't mention it in the cover letter, but yes, I've tried
> this - a new `kernel_console_font` would be much cleaner than negative
> array indexing.
>
> The reason I ended up giving it up was, frankly speaking, these macros
> are being used at about 30 places, and I am not familiar enough with the
> framebuffer and newport_con code, so I wasn't confident how to clean
> them up and plug in `kernel_console_font` properly...
>
> Another reason was that, functions like fbcon_get_font() handle both user
> fonts and built-in fonts, so I wanted a single solution for both of
> them. I think we can't really introduce `kernel_console_font` while
> keeping these macros, that would make the error handling logics etc.
> very messy.
>
> I'm not very sure what to do now. Should I give it another try cleaning
> up all the macros?
>
> And thank you for reviewing this!
I think the only way to make this work is that we have one place which
takes in the userspace uapi struct, and then converts it once into a
kernel_console_font. With all the error checking.
Then all internal code deals in terms of kernel_console_font, with
properly typed and named struct members and helper functions and
everything. And we might need a gradual conversion for this, so that first
we can convert over invidual console drivers, then subsystems, until at
the end we've pushed the conversion from uapi array to kernel_console_font
all the way to the ioctl entry points.
But that's indeed a huge pile of work, and fair warning: fbcon is
semi-orphaned, so by doing this you'll pretty much volunteer for
maintainership :-)
But I'd be very happy to help get this done and throw some maintainership
credentials at you in the proces ...
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
On Fri, Sep 25, 2020 at 11:34 AM Christian König wrote: > > Am 25.09.20 um 10:18 schrieb Daniel Vetter: > > On Fri, Sep 25, 2020 at 10:16 AM Daniel Vetter wrote: > >> On Fri, Sep 25, 2020 at 9:39 AM Christian König > >> wrote: > >>> Am 25.09.20 um 01:14 schrieb Dave Airlie: > On Thu, 24 Sep 2020 at 22:42, Christian König > wrote: > > Am 24.09.20 um 07:18 schrieb Dave Airlie: > >> From: Dave Airlie > >> > >> All the accel moves do the same pattern here, provide a helper > > And exactly that pattern I want to get away from. > Currently this is just refactoring out the helper code in each driver, > but I see > since it calls bo_mem_space we are probably moving a bit in the wrong > direction. > >>> Exactly that's why I'm noting this. > >>> > > See what happens if we (for example) have a VRAM -> SYSTEM move is the > > following: > > > > 1. TTM allocates a new ttm_resource object in the SYSTEM domain. > > 2. We call the driver to move from VRAM to SYSTEM. > > 3. Driver finds that it can't do this and calls TTM to allocate GTT. > > 4. Since we are maybe out of GTT TTM evicts a different BO from GTT to > > SYSTEM and call driver again. > > > > This is a horrible ping/pong between driver/TTM/driver/TTM/driver and we > > should stop that immediately. > > > > My suggestion is that we rewrite how drivers call the ttm_bo_validate() > > function so that we can guarantee that this never happens. > > > > What do you think? > I think that is likely the next step I'd like to take after this > refactor, it's a lot bigger, and I'm not sure how it will look yet. > >>> Agree, yes. I have some ideas in mind for that, but not fully baked > >>> either. > >>> > Do we envision the driver calling validate in a loop but when it can't > find space it tells the driver and the driver does eviction and > recalls validate? > >>> Not in a loop, but more like in a chain. > >>> > >>> My plan is something like this: > >>> Instead of having "normal" and "busy" placement we have a flag in the > >>> context if evictions are allowed or not. > >>> The call to ttm_bo_validate are then replaced with two calls, first > >>> without evictions and if that didn't worked one with evictions. > >>> > >>> Then the normal validate sequence should look like this: > >>> 1. If a BO is in the SYSTEM (or SWAP domain) we validate it to GTT first > >>> with evictions=true. > >>> 2. If a BO should be in VRAM we then validate it to VRAM. If evictions > >>> are only allowed if the GEM flags say that GTT is not desired. > >> That solves the trouble when you move a bo into vram as part of > >> validate. But I'm not seeing how this solves the "need gtt mapping to > >> move something out of vram" problem. > > Eviction is not a problem because the driver gets asked where to put an > evicted BO and then TTM does all the moving. Hm I guess then I don't quite get where you see the ping-pong happening, I thought that only happens for evicting stuff. But hey not much actual working experience with ttm over here, I'm just reading :-) I thought the issue is that ttm wants to evict from $something to SYSTEM, and to do that the driver first needs to set a GTT mapping for the SYSTEM ttm_resource allocation, so that it can use the blitter/sdma engine or whatever to move the data over. But for swap-in/validation I'm confused how you can end up with the "wrong" placement, that feels like a driver bug. How exactly can you get into a situation with validation where ttm gives you SYSTEM, but not GTT and the driver has to fix that up? I'm not really following I think, I guess there's something obvious I'm missing. > >> Or should we instead move the entire eviction logic out from ttm into > >> drivers, building it up from helpers? > > I've been playing with that thought for a while as well, but then > decided against it. > > The main problem I see is that we sometimes need to evict things from > other drivers. > > E.g. when we overcommitted system memory and move things to swap for > example. Hm yeah ttm has that limit to avoid stepping into the shrinker, directly calling into another driver to keep within the limit while ignoring that there's other memory users and caches out there still feels wrong, it's kinda a parallel world vs shrinker callbacks. And there's nothing stopping you from doing the SYSTEM->SWAP movement from a shrinker callback with the locking rules we've established around dma_resv (just needs to be a trylock). So feels a bit backwards if we design ttm eviction around this part of it ... > >> Then drivers which need gtt for > >> moving stuff out of vram can do that right away. Also, this would > >> allow us to implement very fancy eviction algorithms like all the > >> nonsense we're doing in i915 for gtt handling on gen2/3 (but I really > >> hope that never ever becomes a thing again in future gpus, so this is > >> maybe
Re: [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
On 24/09/2020 14:58, Christoph Hellwig wrote:
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which doesn't seem to be required here for the
kernel memory case (and could be added to vmap using a flag if actually
required).
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++
2 files changed, 59 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 9afa5c4a6bf006..1e1cb245fca778 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -25,6 +25,7 @@ config DRM_I915
select CRC32
select SND_HDA_I915 if SND_HDA_CORE
select CEC_CORE if CEC_NOTIFIER
+ select VMAP_PFN
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 6550c0bc824ea2..b519417667eb4b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj)
return err;
}
-static inline pte_t iomap_pte(resource_size_t base,
- dma_addr_t offset,
- pgprot_t prot)
-{
- return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
-}
-
/* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
-enum i915_map_type type)
+static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
+ enum i915_map_type type)
{
- unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
- struct sg_table *sgt = obj->mm.pages;
- pte_t *stack[32], **mem;
- struct vm_struct *area;
+ unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
+ struct page *stack[32], **pages = stack, *page;
+ struct sgt_iter iter;
pgprot_t pgprot;
+ void *vaddr;
- if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
- return NULL;
-
- if (GEM_WARN_ON(type == I915_MAP_WC &&
- !static_cpu_has(X86_FEATURE_PAT)))
- return NULL;
-
- /* A single page can always be kmapped */
- if (n_pte == 1 && type == I915_MAP_WB) {
- struct page *page = sg_page(sgt->sgl);
-
+ switch (type) {
+ default:
+ MISSING_CASE(type);
+ fallthrough;/* to use PAGE_KERNEL anyway */
+ case I915_MAP_WB:
/*
* On 32b, highmem using a finite set of indirect PTE (i.e.
* vmap) to provide virtual mappings of the high pages.
@@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
* So if the page is beyond the 32b boundary, make an explicit
* vmap.
*/
- if (!PageHighMem(page))
- return page_address(page);
- }
-
- mem = stack;
- if (n_pte > ARRAY_SIZE(stack)) {
- /* Too big for stack -- allocate temporary array instead */
- mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
- if (!mem)
- return NULL;
- }
-
- area = alloc_vm_area(obj->base.size, mem);
- if (!area) {
- if (mem != stack)
- kvfree(mem);
- return NULL;
- }
-
- switch (type) {
- default:
- MISSING_CASE(type);
- fallthrough;/* to use PAGE_KERNEL anyway */
- case I915_MAP_WB:
+ if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
+ return page_address(sg_page(obj->mm.pages->sgl));
pgprot = PAGE_KERNEL;
break;
case I915_MAP_WC:
@@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
break;
}
- if (i915_gem_object_has_struct_page(obj)) {
- struct sgt_iter iter;
- struct page *page;
- pte_t **ptes = mem;
+ if (n_pages > ARRAY_SIZE(stack)) {
+ /* Too big for stack -- allocate temporary array instead */
+ pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+ if (!pages)
+ return NULL;
+ }
- for_each_sgt_page(page, iter, sgt)
- **ptes++
Re: [PATCH 06/11] drm/i915: use vmap in shmem_pin_map
On 24/09/2020 14:58, Christoph Hellwig wrote:
shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup. The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap using a flag if
actually required). Switch to use vmap, and use vfree to free both the
vmalloc mapping and the page array, as well as dropping the references
to each page.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 76 +++
1 file changed, 18 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
b/drivers/gpu/drm/i915/gt/shmem_utils.c
index 43c7acbdc79dea..f011ea42487e11 100644
--- a/drivers/gpu/drm/i915/gt/shmem_utils.c
+++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
@@ -49,80 +49,40 @@ struct file *shmem_create_from_object(struct
drm_i915_gem_object *obj)
return file;
}
-static size_t shmem_npte(struct file *file)
-{
- return file->f_mapping->host->i_size >> PAGE_SHIFT;
-}
-
-static void __shmem_unpin_map(struct file *file, void *ptr, size_t n_pte)
-{
- unsigned long pfn;
-
- vunmap(ptr);
-
- for (pfn = 0; pfn < n_pte; pfn++) {
- struct page *page;
-
- page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
- GFP_KERNEL);
- if (!WARN_ON(IS_ERR(page))) {
- put_page(page);
- put_page(page);
- }
- }
-}
-
void *shmem_pin_map(struct file *file)
{
- const size_t n_pte = shmem_npte(file);
- pte_t *stack[32], **ptes, **mem;
- struct vm_struct *area;
- unsigned long pfn;
-
- mem = stack;
- if (n_pte > ARRAY_SIZE(stack)) {
- mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
- if (!mem)
- return NULL;
- }
+ struct page **pages;
+ size_t n_pages, i;
+ void *vaddr;
- area = alloc_vm_area(n_pte << PAGE_SHIFT, mem);
- if (!area) {
- if (mem != stack)
- kvfree(mem);
+ n_pages = file->f_mapping->host->i_size >> PAGE_SHIFT;
+ pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+ if (!pages)
return NULL;
- }
- ptes = mem;
- for (pfn = 0; pfn < n_pte; pfn++) {
- struct page *page;
-
- page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
- GFP_KERNEL);
- if (IS_ERR(page))
+ for (i = 0; i < n_pages; i++) {
+ pages[i] = shmem_read_mapping_page_gfp(file->f_mapping, i,
+ GFP_KERNEL);
+ if (IS_ERR(pages[i]))
goto err_page;
-
- **ptes++ = mk_pte(page, PAGE_KERNEL);
}
- if (mem != stack)
- kvfree(mem);
-
+ vaddr = vmap(pages, n_pages, VM_MAP_PUT_PAGES, PAGE_KERNEL);
+ if (!vaddr)
+ goto err_page;
mapping_set_unevictable(file->f_mapping);
- return area->addr;
-
+ return vaddr;
err_page:
- if (mem != stack)
- kvfree(mem);
-
- __shmem_unpin_map(file, area->addr, pfn);
+ while (--i >= 0)
+ put_page(pages[i]);
+ kvfree(pages);
return NULL;
}
void shmem_unpin_map(struct file *file, void *ptr)
{
mapping_clear_unevictable(file->f_mapping);
- __shmem_unpin_map(file, ptr, shmem_npte(file));
+ vfree(ptr);
}
static int __shmem_rw(struct file *file, loff_t off,
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/11] drm/i915: stop using kmap in i915_gem_object_map
On 24/09/2020 14:58, Christoph Hellwig wrote:
kmap for !PageHighmem is just a convoluted way to say page_address,
and kunmap is a no-op in that case.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index d6eeefab3d018b..6550c0bc824ea2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -162,8 +162,6 @@ static void unmap_object(struct drm_i915_gem_object *obj,
void *ptr)
{
if (is_vmalloc_addr(ptr))
vunmap(ptr);
- else
- kunmap(kmap_to_page(ptr));
}
struct sg_table *
@@ -277,11 +275,10 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
* forever.
*
* So if the page is beyond the 32b boundary, make an explicit
-* vmap. On 64b, this check will be optimised away as we can
-* directly kmap any page on the system.
+* vmap.
*/
if (!PageHighMem(page))
- return kmap(page);
+ return page_address(page);
}
mem = stack;
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
+++ b/tools/testing/scatterlist/main.c
@@ -55,14 +55,13 @@ int main(void)
for (i = 0, test = tests; test->expected_segments; test++,
i++) {
struct page *pages[MAX_PAGES];
struct sg_table st;
- int ret;
+ struct scatterlist *sg;
set_pages(pages, test->pfn, test->num_pages);
- ret = __sg_alloc_table_from_pages(&st, pages,
test->num_pages,
- 0, test->size, test->max_seg,
- GFP_KERNEL);
- assert(ret == test->alloc_ret);
+ sg = __sg_alloc_table_from_pages(&st, pages,
test->num_pages, 0,
+ test->size, test->max_seg, NULL, 0, GFP_KERNEL);
+ assert(PTR_ERR_OR_ZERO(sg) == test->alloc_ret);
Some test coverage for relatively complex code would be very
welcomed. Since
the testing framework is already there, even if it bit-rotted a bit,
but
shouldn't be hard to fix.
A few tests to check append/grow works as expected, in terms of how
the end
table looks like given the initial state and some different page
patterns
added to it. And both crossing and not crossing into sg chaining
scenarios.
This function is basic for all RDMA devices and we are pretty confident
that the old and new flows are tested thoroughly.
Well, since 0-day is reporting that __i915_gem_userptr_alloc_pages is
crashing on this, it probably does need some tests :\
Jason
It is crashing in the regular old flow which already tested.
However, I will add more tests.
Do you want to take some of the commits from
git://people.freedesktop.org/~tursulin/drm-intel sgtest? It would be
fine by me. I can clean up the commit messages if you want.
https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=sgtest&id=79102f4d795c4769431fc44a6cf7ed5c5b1b5214
- this one undoes the bit rot and makes the test just work on the
current kernel.
https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=sgtest&id=b09bfe80486c4d93ee1d8ae17d5b46397b1c6ee1
- this one you probably should squash in your patch. Minus the zeroing
of struct sg_stable since that would hide the issue.
https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=sgtest&id=97f5df37e612f798ced90541eece13e2ef639181
- final commit is optional but I guess handy for debugging.
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
On 25/09/2020 12:58, Jason Gunthorpe wrote: On Fri, Sep 25, 2020 at 12:41:29PM +0100, Tvrtko Ursulin wrote: On 25/09/2020 08:13, Leon Romanovsky wrote: On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote: On 22/09/2020 09:39, Leon Romanovsky wrote: From: Maor Gottlieb Extend __sg_alloc_table_from_pages to support dynamic allocation of SG table from pages. It should be used by drivers that can't supply all the pages at one time. This function returns the last populated SGE in the table. Users should pass it as an argument to the function from the second call and forward. As before, nents will be equal to the number of populated SGEs (chunks). So it's appending and growing the "list", did I get that right? Sounds handy indeed. Some comments/questions below. Yes, we (RDMA) use this function to chain contiguous pages. I will eveluate if i915 could start using it. We have some loops which build page by page and coalesce. Christoph H doesn't like it, but if there are enough cases we should really have a pin_user_pages_to_sg() rather than open code this all over the place. With THP the chance of getting a coalescing SG is much higher, and everything is more efficient with larger SGEs. Right, I was actually referring to i915 sites where we build sg tables out of shmem and plain kernel pages. In those areas we have some open coded coalescing loops (see for instance our shmem_get_pages). Plus a local "trim" to discard the unused entries, since we allocate pessimistically not knowing how coalescing will pan out. This kind of core function which appends pages could replace some of that. Maybe it would be slightly less efficient but I will pencil in to at least evaluate it. Otherwise I do agree that coalescing is a win and in the past I have measured savings in a few MiB range just for struct scatterlist storage. Regards, Tvrtko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 7/7] drm/i915: Add support for enabling link status and recovery
From: Swati Sharma
In this patch enabled support for link status and recovery in i915
driver. HDMI link loss indication to upstream DP source is indicated
via IRQ_HPD. This is followed by reading of HDMI link configuration
status (HDMI_TX_LINK_ACTIVE_STATUS). If the PCON → HDMI 2.1 link status
is off; reinitiate frl link training to recover.
Also, HDMI FRL link error count range for each individual FRL
active lane is indicated by DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 47 +++--
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b6e53e4f06ee..0de4c72e66c1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5893,6 +5893,29 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return link_ok;
}
+static void
+intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp)
+{
+ bool is_active;
+ u8 buf = 0;
+
+ is_active = drm_dp_pcon_hdmi_link_active(&intel_dp->aux);
+ if (intel_dp->frl.is_trained && !is_active) {
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, &buf) < 0)
+ return;
+
+ buf &= ~DP_PCON_ENABLE_HDMI_LINK;
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
+ return;
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
+
+ intel_dp_check_frl_training(intel_dp);
+ drm_dp_pcon_hdmi_frl_link_error_count(&intel_dp->aux,
&intel_dp->attached_connector->base);
+ }
+}
+
static bool
intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
{
@@ -6121,7 +6144,7 @@ intel_dp_hotplug(struct intel_encoder *encoder,
return state;
}
-static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
+static void intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 val;
@@ -6145,6 +6168,23 @@ static void intel_dp_check_service_irq(struct intel_dp
*intel_dp)
drm_dbg_kms(&i915->drm, "Sink specific irq unhandled\n");
}
+static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
+{
+ u8 val;
+
+ if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
+ return;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, &val) != 1 ||
!val)
+ return;
+
+ drm_dp_dpcd_writeb(&intel_dp->aux, DP_LINK_SERVICE_IRQ_VECTOR_ESI0,
val);
+
+ if (val & HDMI_LINK_STATUS_CHANGED)
+ intel_dp_handle_hdmi_link_status_change(intel_dp);
+}
+
/*
* According to DP spec
* 5.1.2:
@@ -6184,7 +6224,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
return false;
}
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
+ intel_dp_check_link_service_irq(intel_dp);
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(&intel_dp->aux);
@@ -6594,7 +6635,7 @@ intel_dp_detect(struct drm_connector *connector,
to_intel_connector(connector)->detect_edid)
status = connector_status_connected;
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
out:
if (status != connector_status_connected && !intel_dp->is_mst)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 2/7] drm/edid: Parse MAX_FRL field from HFVSDB block
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 50 +
include/drm/drm_connector.h | 6 +
2 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 631125b46e04..d468ac91abb6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4849,6 +4849,51 @@ static void drm_parse_vcdb(struct drm_connector
*connector, const u8 *db)
info->rgb_quant_range_selectable = true;
}
+static void drm_parse_hdmi_21_additional_fields(struct drm_connector
*connector,
+ const u8 *db)
+{
+ /* hf_vsdb 7:14 support needs to be added */
+
+u8 max_frl_rate_per_lane;
+struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+max_frl_rate_per_lane = (db[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
+
+switch(max_frl_rate_per_lane) {
+case 0:
+ hdmi->max_lane = 0;
+ hdmi->max_frl_rate_per_lane = 0;
+ break;
+case 1:
+ hdmi->max_lane = 3;
+ hdmi->max_frl_rate_per_lane = 3;
+ break;
+case 2:
+ hdmi->max_lane = 3;
+ hdmi->max_frl_rate_per_lane = 6;
+ break;
+case 3:
+ hdmi->max_lane = 4;
+ hdmi->max_frl_rate_per_lane = 6;
+ break;
+case 4:
+ hdmi->max_lane = 4;
+ hdmi->max_frl_rate_per_lane = 8;
+ break;
+case 5:
+ hdmi->max_lane = 4;
+ hdmi->max_frl_rate_per_lane = 10;
+ break;
+case 6:
+ hdmi->max_lane = 4;
+ hdmi->max_frl_rate_per_lane = 12;
+ break;
+default:
+ DRM_DEBUG_KMS("max frl rate per lane 0x%x, reserved\n",
max_frl_rate_per_lane);
+ break;
+}
+}
+
static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
const u8 *db)
{
@@ -4902,6 +4947,11 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
}
}
+ if (hf_vsdb[7]) {
+ DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
+ drm_parse_hdmi_21_additional_fields(connector, hf_vsdb);
+ }
+
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 928136556174..aa6ae9c17ca4 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,12 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /** @max_frl_rate_per_lane: support fixed rate link */
+ u8 max_frl_rate_per_lane;
+
+ /** @max_lane: supported by sink */
+ u8 max_lane;
};
/**
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 3/7] drm/dp_helper: Add FRL training support for a DP-HDMI2.1 PCON
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 305
include/drm/drm_dp_helper.h | 81 +
2 files changed, 386 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 478dd51f738d..36302d4924f4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2366,3 +2366,308 @@ void drm_dp_vsc_sdp_log(const char *level, struct
device *dev,
#undef DP_SDP_LOG
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+
+/**
+ * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns maximum frl bandwidth supported by PCON in GBPS.
+ **/
+int drm_dp_get_pcon_max_frl_bw(struct drm_dp_aux *aux,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4])
+{
+ int bw;
+ u8 buf;
+
+ buf = port_cap[2];
+ bw = buf & DP_PCON_MAX_FRL_BW;
+
+ switch (bw) {
+ case DP_PCON_MAX_9GBPS:
+ return 9;
+ case DP_PCON_MAX_18GBPS:
+ return 18;
+ case DP_PCON_MAX_24GBPS:
+ return 24;
+ case DP_PCON_MAX_32GBPS:
+ return 32;
+ case DP_PCON_MAX_40GBPS:
+ return 40;
+ case DP_PCON_MAX_48GBPS:
+ return 48;
+ case DP_PCON_MAX_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
+
+/**
+ * drm_dp_get_hdmi_max_frl_bw() - maximum frl supported by HDMI Sink
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns maximum frl bandwidth supported by HDMI in Gbps on success,
+ * else returns negative error code.
+ **/
+int drm_dp_get_hdmi_max_frl_bw(struct drm_dp_aux *aux)
+{
+ u8 buf;
+ int bw, ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_SINK, &buf);
+ if (ret < 0)
+ return ret;
+ bw = buf & DP_HDMI_SINK_LINK_BW;
+
+ switch (bw) {
+ case DP_HDMI_SINK_BW_9GBPS:
+ return 9;
+ case DP_HDMI_SINK_BW_18GBPS:
+ return 18;
+ case DP_HDMI_SINK_BW_24GBPS:
+ return 24;
+ case DP_HDMI_SINK_BW_32GBPS:
+ return 32;
+ case DP_HDMI_SINK_BW_40GBPS:
+ return 40;
+ case DP_HDMI_SINK_BW_48GBPS:
+ return 48;
+ case DP_HDMI_SINK_BW_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_hdmi_max_frl_bw);
+
+/**
+ * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool enable_frl_ready_hpd)
+{
+ int ret;
+ u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
+DP_PCON_ENABLE_LINK_FRL_MODE;
+
+ if (enable_frl_ready_hpd)
+ buf |= DP_PCON_ENABLE_HPD_READY;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
+
+/**
+ * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns true if success, else returns false.
+ **/
+bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, &buf);
+ if (ret < 0)
+ return false;
+
+ if (buf & DP_PCON_FRL_READY)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
+
+/**
+ * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
+ * @aux: DisplayPort AUX channel
+ * max_frl_mask: mask for selecting the bandwidths supported by source,
+ * to be tried by Pcon f/w.
+ * @concurrent_mode: true if concurrent mode or operation is required,
+ * false otherwise.
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+
+int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
+ bool concurrent_mode)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_LINK_CONFIG_1, &buf);
+ if (ret < 0)
+ return ret;
+
+ if (concurrent_mode)
+ buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
+ else
+ buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
+
+ switch (max_frl_gbps) {
+ case 9:
+ buf |= DP_PCON_ENABLE_MAX_BW_9GBPS;
+ break;
+ case 18:
+ buf |= DP_PCON_ENABLE_MAX_BW_18GBPS;
+ break;
+ case 24:
+ buf |= DP_PCON_ENABLE_MAX_BW_24GBPS;
+ break;
+ case 32:
[RFC 6/7] drm/dp_helper: Add support for link status and link recovery
From: Swati Sharma
This patch adds support for link status and link recovery. There
are specific DPCD’s defined for link status check and recovery in
case of any issues. PCON will communicate the same using an IRQ_HPD
to source. HDMI sink would have indicated the same to PCON using
SCDC interrupt mechanism. While source can always read final HDMI
sink’s status using I2C over AUX, it’s easier and faster to read
the PCON’s already read HDMI sink’s status registers.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 33 +
include/drm/drm_dp_helper.h | 16
2 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 36302d4924f4..aac282bc5dfc 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2671,3 +2671,36 @@ int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux,
u8 *frl_trained_mask)
return mode;
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_link_mode);
+
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector)
+{
+ u8 buf, error_count;
+ int i, num_error;
+ struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+ for (i = 0; i < hdmi->max_lane; i++)
+ {
+ if (drm_dp_dpcd_readb(aux, DP_PCON_HDMI_ERROR_STATUS_LN0 + i ,
&buf) < 0)
+ return;
+
+ error_count = buf & DP_PCON_HDMI_ERROR_COUNT_MASK;
+
+ switch(error_count) {
+ case DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS:
+ num_error = 100;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS:
+ num_error = 10;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS:
+ num_error = 3;
+ break;
+ default:
+ num_error = 0;
+ }
+
+ DRM_ERROR("More than %d errors since the last read for lane
%d", num_error, i);
+ }
+}
+EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 58a6600e5698..7b143a2ae5ff 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -946,6 +946,11 @@ struct drm_device;
# define DP_CEC_IRQ (1 << 2)
#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */
+# define RX_CAP_CHANGED (1 << 0)
+# define LINK_STATUS_CHANGED (1 << 1)
+# define STREAM_STATUS_CHANGED (1 << 2)
+# define HDMI_LINK_STATUS_CHANGED(1 << 3)
+# define CONNECTED_OFF_ENTRY_REQUESTED (1 << 4)
#define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */
# define DP_PSR_LINK_CRC_ERROR (1 << 0)
@@ -1130,6 +1135,16 @@ struct drm_device;
#define DP_PROTOCOL_CONVERTER_CONTROL_20x3052 /* DP 1.3 */
# define DP_CONVERSION_TO_YCBCR422_ENABLE (1 << 0) /* DP 1.3 */
+/* PCON Downstream HDMI ERROR Status per Lane */
+#define DP_PCON_HDMI_ERROR_STATUS_LN0 0x3037
+#define DP_PCON_HDMI_ERROR_STATUS_LN1 0x3038
+#define DP_PCON_HDMI_ERROR_STATUS_LN2 0x3039
+#define DP_PCON_HDMI_ERROR_STATUS_LN3 0x303A
+# define DP_PCON_HDMI_ERROR_COUNT_MASK (0x7 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS (1 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS (1 << 1)
+# define DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS (1 << 2)
+
/* HDCP 1.3 and HDCP 2.2 */
#define DP_AUX_HDCP_BKSV 0x68000
#define DP_AUX_HDCP_RI_PRIME 0x68005
@@ -1985,4 +2000,5 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux);
bool drm_dp_pcon_hdmi_link_active(struct drm_dp_aux *aux);
int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux, u8 *frl_trained_mask);
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux, struct
drm_connector *connector);
#endif /* _DRM_DP_HELPER_H_ */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 1/7] drm/edid: Add additional HFVSDB fields for HDMI2.1
From: Swati Sharma
The HDMI2.1 extends HFVSBD (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields that are required for
HDMI2.1.
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
include/drm/drm_edid.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index b27a0e2169c8..3b6371f36676 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,36 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
+/* HDMI 2.1 additional fields */
+#define DRM_EDID_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_FAPA_START_LOCATION (1 << 0)
+#define DRM_EDID_ALLM (1 << 1)
+#define DRM_EDID_FVA (1 << 2)
+
+/* Deep Color specific */
+#define DRM_EDID_DC_30BIT_420 (1 << 0)
+#define DRM_EDID_DC_36BIT_420 (1 << 1)
+#define DRM_EDID_DC_48BIT_420 (1 << 2)
+
+/* VRR specific */
+#define DRM_EDID_CNMVRR(1 << 3)
+#define DRM_EDID_CINEMA_VRR(1 << 4)
+#define DRM_EDID_MDELTA(1 << 5)
+#define DRM_EDID_VRR_MAX_UPPER_MASK0xc0
+#define DRM_EDID_VRR_MAX_LOWER_MASK0xff
+#define DRM_EDID_VRR_MIN_MASK 0x3f
+
+/* DSC specific */
+#define DRM_EDID_DSC_10(1 << 0)
+#define DRM_EDID_DSC_12(1 << 1)
+#define DRM_EDID_DSC_16(1 << 2)
+#define DRM_EDID_DSC_ALL (1 << 3)
+#define DRM_EDID_DSC_NATIVE_420(1 << 6)
+#define DRM_EDID_1P2 (1 << 7)
+#define DRM_EDID_DSC_MAX_FRL_RATE 0xf
+#define DRM_EDID_DSC_MAX_SLICES0xf
+#define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES0x3f
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 5/7] drm/i915: Check for FRL training before DP Link training
This patch calls functions to check FRL training requirements for an HDMI2.1 sink, when connected through PCON. The call is made before the DP link training. In case FRL is not required or failure during FRL training, the TMDS mode is selected for the pcon. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ drivers/gpu/drm/i915/display/intel_dp.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 4d06178cd76c..cf8a8e2a64f7 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3389,6 +3389,8 @@ static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state, if (!is_mst) intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + intel_dp_check_frl_training(intel_dp); + intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true); /* * DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 3a8e69e5bbfb..b6e53e4f06ee 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -4129,6 +4129,7 @@ static void intel_enable_dp(struct intel_atomic_state *state, intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_configure_protocol_converter(intel_dp); + intel_dp_check_frl_training(intel_dp); intel_dp_start_link_train(intel_dp); intel_dp_stop_link_train(intel_dp); @@ -6050,6 +6051,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder, intel_crtc_pch_transcoder(crtc), false); } + intel_dp_check_frl_training(intel_dp); intel_dp_start_link_train(intel_dp); intel_dp_stop_link_train(intel_dp); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 4/7] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 6 +
drivers/gpu/drm/i915/display/intel_dp.c | 202 ++
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
3 files changed, 210 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3d4bf9b6a0a2..9a295a43b189 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1264,6 +1264,11 @@ struct intel_dp_compliance {
u8 test_lane_count;
};
+struct intel_dp_pcon_frl {
+ bool is_trained;
+ int trained_rate_gbps;
+};
+
struct intel_dp {
i915_reg_t output_reg;
u32 DP;
@@ -1312,6 +1317,7 @@ struct intel_dp {
unsigned long last_backlight_off;
ktime_t panel_power_off_time;
+ struct intel_dp_pcon_frl frl;
struct notifier_block edp_notifier;
/*
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index bf1e9cf1c0f3..3a8e69e5bbfb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2869,6 +2869,9 @@ static void intel_dp_prepare(struct intel_encoder
*encoder,
intel_dp->DP |= DP_PIPE_SEL_CHV(crtc->pipe);
else
intel_dp->DP |= DP_PIPE_SEL(crtc->pipe);
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
}
}
@@ -3705,6 +3708,9 @@ static void intel_disable_dp(struct intel_atomic_state
*state,
intel_edp_backlight_off(old_conn_state);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_edp_panel_off(intel_dp);
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
}
static void g4x_disable_dp(struct intel_atomic_state *state,
@@ -3799,6 +3805,202 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
+static int intel_dp_get_max_rate_gbps(struct intel_dp *intel_dp)
+{
+ int max_link_clock, max_lanes, max_rate_khz, max_rate_gbps;
+
+ max_link_clock = intel_dp_max_link_rate(intel_dp);
+ max_lanes = intel_dp_max_lane_count(intel_dp);
+ max_rate_khz = intel_dp_max_data_rate(max_link_clock, max_lanes);
+ max_rate_gbps = 8 * DIV_ROUND_UP(max_rate_khz, 100);
+
+ return max_rate_gbps;
+}
+
+static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
+{
+ int bw_gbps[] = {9, 18, 24, 32, 40, 48};
+ int i;
+
+ for (i = ARRAY_SIZE(bw_gbps) - 1; i >= 0; i--) {
+ if (frl_bw_mask & (1 << i))
+ return bw_gbps[i];
+ }
+ return 0;
+}
+
+static int intel_dp_pcon_set_frl_mask(int max_frl)
+{
+ int max_frl_mask = 0;
+
+ switch (max_frl) {
+ case 48:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_48GBPS;
+ break;
+ case 40:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_40GBPS;
+ break;
+ case 32:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_32GBPS;
+ break;
+ case 24:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_24GBPS;
+ break;
+ case 18:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_18GBPS;
+ break;
+ case 9:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_9GBPS;
+ break;
+ default:
+ max_frl_mask = 0;
+ }
+
+ return max_frl_mask;
+}
+
+static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = &intel_connector->base;
+
+ return (connector->display_info.hdmi.max_frl_rate_per_lane *
+ connector->display_info.hdmi.max_lane);
+}
+
+static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
+{
+#define PCON_EXTENDED_TRAIN_MODE true
+#define PCON_CONCURRENT_MODE true
+#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
+#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
+#define TIMEOUT_FRL_READY_MS 500
+#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
+
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int max_frl, max_pcon_frl, max_sink_frl, max_rate_gbps, max_frl_edid,
ret;
+ u8 max_frl_mask = 0, frl_trained_mask;
+ bool is_active;
+
+ ret = drm_dp_pcon_reset_frl_config(&intel_dp->aux);
+ if (ret < 0)
+ return ret;
+
+ max_rate_gbps = intel_dp_get_max_rate_gbps(intel_dp);
+ drm_dbg(&i915->drm, "Source max rate = %d Gbps\n", max_rat
[RFC 0/7] Add support for DP-HDMI2.1 PCON
This patch series attempts to add support for a DP-HDMI2.1 Protocol Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata E5 to DisplayPort_v2.0: https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid=42299 The details are mentioned in DP to HDMI2.1 PCON Enum/Config improvement slide decks: https://groups.vesa.org/wg/DP/document/folder/1316 This RFC series starts with adding support for FRL (Fixed Rate Link) Training between the PCON and HDMI2.1 sink. As per HDMI2.1 specification, a new data-channel or lane is added in FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4 lanes). With these patches, the HDMI2.1 PCON can be configured to achieve FRL training based on the maximum FRL rate supported by the panel, source and the PCON. The approach is to add the support for FRL training between PCON and HDMI2.1 sink and gradually add other blocks for supporting higher resolutions and other HDMI2.1 features, that can be supported by pcon for the sources that do not natively support HDMI2.1. This is done before the DP Link training between the source and PCON is started. In case of FRL training is not achieved, the PCON will work in the regular TMDS mode, without HDMI2.1 feature support. Any interruption in FRL training between the PCON and HDMI2.1 sink is notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD registers are read and FRL training is re-attempted. Currently, we have tested the FRL training and are able to enable 4K display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting panel. Ankit Nautiyal (3): drm/dp_helper: Add FRL training support for a DP-HDMI2.1 PCON drm/i915: Add support for starting FRL training for HDMI2.1 via PCON drm/i915: Check for FRL training before DP Link training Swati Sharma (4): drm/edid: Add additional HFVSDB fields for HDMI2.1 drm/edid: Parse MAX_FRL field from HFVSDB block drm/dp_helper: Add support for link status and link recovery drm/i915: Add support for enabling link status and recovery drivers/gpu/drm/drm_dp_helper.c | 338 ++ drivers/gpu/drm/drm_edid.c| 50 +++ drivers/gpu/drm/i915/display/intel_ddi.c | 2 + .../drm/i915/display/intel_display_types.h| 6 + drivers/gpu/drm/i915/display/intel_dp.c | 251 - drivers/gpu/drm/i915/display/intel_dp.h | 2 + include/drm/drm_connector.h | 6 + include/drm/drm_dp_helper.h | 97 + include/drm/drm_edid.h| 30 ++ 9 files changed, 779 insertions(+), 3 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: cdns-mhdp8546: fix compile warning
On Fri, Sep 25, 2020 at 03:05:52PM +0300, Tomi Valkeinen wrote: > On 25/09/2020 15:00, Laurent Pinchart wrote: > > On Fri, Sep 25, 2020 at 10:36:44AM +0300, Tomi Valkeinen wrote: > >> On 24/09/2020 14:48, Laurent Pinchart wrote: > >>> Hi Tomi, > >>> > >>> Thank you for the patch. > >>> > >>> On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote: > On x64 we get: > > drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: > conversion from 'long unsigned int' to 'unsigned int' changes value from > '18446744073709551613' to '4294967293' [-Woverflow] > > The registers are 32 bit, so fix by casting to u32. > >>> > >>> I wonder if we need a BIT32 macro... This is a common issue, it would be > >>> nice to handle it in the macros that define register fields. > >> > >> That's probably a good idea. I think > >> > >> #define BIT32(nr) (1u << (nr)) > >> > >> should work correct on all archs. Although I'm not quite sure if nr should > >> be cast to u32, but in my > >> tests a u64 nr doesn't cause type promotion to u64. > > > > I don't think we need to support nr values larger than 2^32-1 ;-) > > That's true, but we might have: > > u64 nr = 1; > BIT32(nr) > > Afaics, we don't need to cast nr to u32, but maybe that's still the safe > thing to do. > > >> Anyway, I'd like to merge this fix as it is to get rid of the warning for > >> the merge window. > > > > Sounds good to me. > > Was that a reviewed-by? =) Acked-by: Laurent Pinchart -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/vc4: crtc: Keep the previously assigned HVS FIFO
Hi Maxime
Sorry for the delay.
On Wed, 23 Sep 2020 at 09:40, Maxime Ripard wrote:
>
> The HVS FIFOs are currently assigned each time we have an atomic_check
> for all the enabled CRTCs.
>
> However, if we are running multiple outputs in parallel and we happen to
> disable the first (by index) CRTC, we end up changing the assigned FIFO
> of the second CRTC without disabling and reenabling the pixelvalve which
> ends up in a stall and eventually a VBLANK timeout.
>
> In order to fix this, we can create a special value for our assigned
> channel to mark it as disabled, and if our CRTC already had an assigned
> channel in its previous state, we keep on using it.
>
> Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
> Signed-off-by: Maxime Ripard
> Tested-by: Dave Stevenson
Reviewed-by: Dave Stevenson
I retested too and had triple output (HDMI-0, HDMI-1, and DPI) working
happily! Switching around resolutions on the HDMI outputs was working
fine. DPI was an Adafruit Kippah and 800x480 LCD, so no options on
resolution.
We may finally have this muxing nailed.
Dave
> ---
>
> Changes from v1:
> - Split away the crtc state reset refactoring
> - Fixed the checkpatch warnings
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 1 +
> drivers/gpu/drm/vc4/vc4_drv.h | 2 ++
> drivers/gpu/drm/vc4/vc4_kms.c | 22 --
> 3 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 7ef20adedee5..482219fb4db2 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -863,6 +863,7 @@ void vc4_crtc_reset(struct drm_crtc *crtc)
> return;
> }
>
> + vc4_crtc_state->assigned_channel = VC4_HVS_CHANNEL_DISABLED;
> __drm_atomic_helper_crtc_reset(crtc, &vc4_crtc_state->base);
> }
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 8c8d96b6289f..90b911fd2a7f 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -532,6 +532,8 @@ struct vc4_crtc_state {
> } margins;
> };
>
> +#define VC4_HVS_CHANNEL_DISABLED ((unsigned int)-1)
> +
> static inline struct vc4_crtc_state *
> to_vc4_crtc_state(struct drm_crtc_state *crtc_state)
> {
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 01fa60844695..149825ff5df8 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -616,7 +616,7 @@ static int
> vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
> {
> unsigned long unassigned_channels = GENMASK(NUM_CHANNELS - 1, 0);
> - struct drm_crtc_state *crtc_state;
> + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> struct drm_crtc *crtc;
> int i, ret;
>
> @@ -629,6 +629,8 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> * modified.
> */
> list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> + struct drm_crtc_state *crtc_state;
> +
> if (!crtc->state->enable)
> continue;
>
> @@ -637,15 +639,23 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> return PTR_ERR(crtc_state);
> }
>
> - for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> - struct vc4_crtc_state *vc4_crtc_state =
> - to_vc4_crtc_state(crtc_state);
> + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> + struct vc4_crtc_state *new_vc4_crtc_state =
> + to_vc4_crtc_state(new_crtc_state);
> struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> unsigned int matching_channels;
>
> - if (!crtc_state->enable)
> + if (old_crtc_state->enable && !new_crtc_state->enable)
> + new_vc4_crtc_state->assigned_channel =
> VC4_HVS_CHANNEL_DISABLED;
> +
> + if (!new_crtc_state->enable)
> continue;
>
> + if (new_vc4_crtc_state->assigned_channel !=
> VC4_HVS_CHANNEL_DISABLED) {
> + unassigned_channels &=
> ~BIT(new_vc4_crtc_state->assigned_channel);
> + continue;
> + }
> +
> /*
> * The problem we have to solve here is that we have
> * up to 7 encoders, connected to up to 6 CRTCs.
> @@ -674,7 +684,7 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> if (matching_channels) {
> unsigned int channel = ffs(matching_channels) - 1;
>
> - vc4_crtc_state->assigned_channel = channel;
> + new_vc4_crtc_state->assigned_channel = channel;
> una
Re: [PATCH] drm/stm: dsi: Use dev_ based logging
On Fri, 2020-09-25 at 12:22 +0200, Yannick Fertre wrote:
> Standardize on the dev_ based logging and drop the include of drm_print.h.
> Remove useless dsi_color_from_mipi function.
[]
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
[]
> - DRM_DEBUG_DRIVER("pll_in %ukHz pll_out %ukHz lane_mbps %uMHz\n",
> - pll_in_khz, pll_out_khz, *lane_mbps);
> + dev_dbg(dsi->dev, "pll_in %ukHz pll_out %ukHz lane_mbps %uMHz\n",
> pll_in_khz, pll_out_khz,
> + *lane_mbps);
The line wrapping change here is pretty pointless and IMO
makes the code harder to read.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: cdns-mhdp8546: fix compile warning
On Fri, Sep 25, 2020 at 10:36:44AM +0300, Tomi Valkeinen wrote: > On 24/09/2020 14:48, Laurent Pinchart wrote: > > Hi Tomi, > > > > Thank you for the patch. > > > > On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote: > >> On x64 we get: > >> > >> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: > >> conversion from 'long unsigned int' to 'unsigned int' changes value from > >> '18446744073709551613' to '4294967293' [-Woverflow] > >> > >> The registers are 32 bit, so fix by casting to u32. > > > > I wonder if we need a BIT32 macro... This is a common issue, it would be > > nice to handle it in the macros that define register fields. > > That's probably a good idea. I think > > #define BIT32(nr) (1u << (nr)) > > should work correct on all archs. Although I'm not quite sure if nr should be > cast to u32, but in my > tests a u64 nr doesn't cause type promotion to u64. I don't think we need to support nr values larger than 2^32-1 ;-) > Anyway, I'd like to merge this fix as it is to get rid of the warning for the > merge window. Sounds good to me. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces
This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to
use struct dma_buf_map. The interfaces used to receive a buffer address.
This address is now given in an instance of the structure.
Users of the functions are updated accordingly. This is only an interface
change. It is currently expected that dma-buf memory can be accessed with
system memory load/store operations.
v2:
* include dma-buf-heaps and i915 selftests (kernel test robot)
* initialize cma_obj before using it in drm_gem_cma_free_object()
(kernel test robot)
Signed-off-by: Thomas Zimmermann
Acked-by: Sumit Semwal
Acked-by: Christian König
Acked-by: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 8 ++---
drivers/dma-buf/heaps/heap-helpers.c | 2 +-
drivers/gpu/drm/drm_gem_cma_helper.c | 9 +++---
drivers/gpu/drm/drm_gem_shmem_helper.c| 3 +-
drivers/gpu/drm/drm_prime.c | 6 ++--
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 5 +--
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 2 +-
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 6 ++--
.../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 4 +--
drivers/gpu/drm/tegra/gem.c | 5 +--
.../common/videobuf2/videobuf2-dma-contig.c | 3 +-
.../media/common/videobuf2/videobuf2-dma-sg.c | 3 +-
.../common/videobuf2/videobuf2-vmalloc.c | 6 ++--
include/drm/drm_prime.h | 2 +-
include/linux/dma-buf-map.h | 32 +--
include/linux/dma-buf.h | 4 +--
16 files changed, 66 insertions(+), 34 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 61bd24d21b38..a6ba4d598f0e 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1236,21 +1236,21 @@ EXPORT_SYMBOL_GPL(dma_buf_vmap);
/**
* dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap.
* @dmabuf:[in]buffer to vunmap
- * @vaddr: [in]vmap to vunmap
+ * @map: [in]vmap pointer to vunmap
*/
-void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map)
{
if (WARN_ON(!dmabuf))
return;
BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
BUG_ON(dmabuf->vmapping_counter == 0);
- BUG_ON(!dma_buf_map_is_vaddr(&dmabuf->vmap_ptr, vaddr));
+ BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map));
mutex_lock(&dmabuf->lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
- dmabuf->ops->vunmap(dmabuf, vaddr);
+ dmabuf->ops->vunmap(dmabuf, map);
dma_buf_map_clear(&dmabuf->vmap_ptr);
}
mutex_unlock(&dmabuf->lock);
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
index aeb9e100f339..fcf4ce3e2cbb 100644
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -251,7 +251,7 @@ static int dma_heap_dma_buf_vmap(struct dma_buf *dmabuf,
struct dma_buf_map *map
return 0;
}
-static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map
*map)
{
struct heap_helper_buffer *buffer = dmabuf->priv;
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 19670b05ead5..2165633c9b9e 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -175,13 +175,12 @@ drm_gem_cma_create_with_handle(struct drm_file *file_priv,
*/
void drm_gem_cma_free_object(struct drm_gem_object *gem_obj)
{
- struct drm_gem_cma_object *cma_obj;
-
- cma_obj = to_drm_gem_cma_obj(gem_obj);
+ struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(gem_obj);
+ struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(cma_obj->vaddr);
if (gem_obj->import_attach) {
if (cma_obj->vaddr)
- dma_buf_vunmap(gem_obj->import_attach->dmabuf,
cma_obj->vaddr);
+ dma_buf_vunmap(gem_obj->import_attach->dmabuf, &map);
drm_prime_gem_destroy(gem_obj, cma_obj->sgt);
} else if (cma_obj->vaddr) {
dma_free_wc(gem_obj->dev->dev, cma_obj->base.size,
@@ -628,7 +627,7 @@ drm_gem_cma_prime_import_sg_table_vmap(struct drm_device
*dev,
obj = drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
if (IS_ERR(obj)) {
- dma_buf_vunmap(attach->dmabuf, map.vaddr);
+ dma_buf_vunmap(attach->dmabuf, &map);
return obj;
}
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 6328cfbb828e..fb11df7aced5 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -337,6 +337,7 @@ EXPO
[PATCH v3 4/4] dma-buf: Document struct dma_buf_map
This patch adds struct dma_buf_map and its helpers to the documentation. A short tutorial is included. v3: * update documentation in a separate patch * expand docs (Daniel) * carry-over acks from patch 1 Signed-off-by: Thomas Zimmermann Reviewed-by: Christian König Reviewed-by: Daniel Vetter Acked-by: Sumit Semwal --- Documentation/driver-api/dma-buf.rst | 9 include/linux/dma-buf-map.h | 72 2 files changed, 81 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 13ea0cc0a3fa..6dbcc4714b0b 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -115,6 +115,15 @@ Kernel Functions and Structures Reference .. kernel-doc:: include/linux/dma-buf.h :internal: +Buffer Mapping Helpers +~~ + +.. kernel-doc:: include/linux/dma-buf-map.h + :doc: overview + +.. kernel-doc:: include/linux/dma-buf-map.h + :internal: + Reservation Objects --- diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h index c173a4abf4ba..fd1aba545fdf 100644 --- a/include/linux/dma-buf-map.h +++ b/include/linux/dma-buf-map.h @@ -8,6 +8,78 @@ #include +/** + * DOC: overview + * + * Calling dma-buf's vmap operation returns a pointer to the buffer's memory. + * Depending on the location of the buffer, users may have to access it with + * I/O operations or memory load/store operations. For example, copying to + * system memory could be done with memcpy(), copying to I/O memory would be + * done with memcpy_toio(). + * + * .. code-block:: c + * + * void *vaddr = ...; // pointer to system memory + * memcpy(vaddr, src, len); + * + * void *vaddr_iomem = ...; // pointer to I/O memory + * memcpy_toio(vaddr, _iomem, src, len); + * + * When using dma-buf's vmap operation, the returned pointer is encoded as + * :c:type:`struct dma_buf_map `. + * :c:type:`struct dma_buf_map ` stores the buffer's address in + * system or I/O memory and a flag that signals the required method of + * accessing the buffer. Use the returned instance and the helper functions + * to access the buffer's memory in the correct way. + * + * Open-coding access to :c:type:`struct dma_buf_map ` is + * considered bad style. Rather then accessing its fields directly, use one + * of the provided helper functions, or implement your own. For example, + * instances of :c:type:`struct dma_buf_map ` can be initialized + * statically with DMA_BUF_MAP_INIT_VADDR(), or at runtime with + * dma_buf_map_set_vaddr(). These helpers will set an address in system memory. + * + * .. code-block:: c + * + * struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(0xdeadbeaf); + * + * dma_buf_map_set_vaddr(&map. 0xdeadbeaf); + * + * Test if a mapping is valid with either dma_buf_map_is_set() or + * dma_buf_map_is_null(). + * + * .. code-block:: c + * + * if (dma_buf_map_is_set(&map) != dma_buf_map_is_null(&map)) + * // always true + * + * Instances of :c:type:`struct dma_buf_map ` can be compared + * for equality with dma_buf_map_is_equal(). Mappings the point to different + * memory spaces, system or I/O, are never equal. That's even true if both + * spaces are located in the same address space, both mappings contain the + * same address value, or both mappings refer to NULL. + * + * .. code-block:: c + * + * struct dma_buf_map sys_map; // refers to system memory + * struct dma_buf_map io_map; // refers to I/O memory + * + * if (dma_buf_map_is_equal(&sys_map, &io_map)) + * // always false + * + * Instances of struct dma_buf_map do not have to be cleaned up, but + * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings + * always refer to system memory. + * + * The type :c:type:`struct dma_buf_map ` and its helpers are + * actually independent from the dma-buf infrastructure. When sharing buffers + * among devices, drivers have to know the location of the memory to access + * the buffers in a safe way. :c:type:`struct dma_buf_map ` + * solves this problem for dma-buf and its users. If other drivers or + * sub-systems require similar functionality, the type could be generalized + * and moved to a more prominent header file. + */ + /** * struct dma_buf_map - Pointer to vmap'ed dma-buf memory. * @vaddr_iomem: The buffer's address if in I/O memory -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr
The new type struct dma_buf_map represents a mapping of dma-buf memory
into kernel space. It contains a flag, is_iomem, that signals users to
access the mapped memory with I/O operations instead of regular loads
and stores.
It was assumed that DMA buffer memory can be accessed with regular load
and store operations. Some architectures, such as sparc64, require the
use of I/O operations to access dma-map buffers that are located in I/O
memory. Providing struct dma_buf_map allows drivers to implement this.
This was specifically a problem when refreshing the graphics framebuffer
on such systems. [1]
As the first step, struct dma_buf stores an instance of struct dma_buf_map
internally. Afterwards, dma-buf's vmap and vunmap interfaces are be
converted. Finally, affected drivers can be fixed.
v3:
* moved documentation into separate patch
* test for NULL pointers with !
[1] https://lore.kernel.org/dri-devel/20200725191012.ga434...@ravnborg.org/
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Reviewed-by: Daniel Vetter
Acked-by: Sumit Semwal
---
drivers/dma-buf/dma-buf.c | 14 +++
include/linux/dma-buf-map.h | 82 +
include/linux/dma-buf.h | 3 +-
3 files changed, 91 insertions(+), 8 deletions(-)
create mode 100644 include/linux/dma-buf-map.h
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 58564d82a3a2..5e849ca241a0 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1207,12 +1207,12 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
mutex_lock(&dmabuf->lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
- BUG_ON(!dmabuf->vmap_ptr);
- ptr = dmabuf->vmap_ptr;
+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
+ ptr = dmabuf->vmap_ptr.vaddr;
goto out_unlock;
}
- BUG_ON(dmabuf->vmap_ptr);
+ BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
ptr = dmabuf->ops->vmap(dmabuf);
if (WARN_ON_ONCE(IS_ERR(ptr)))
@@ -1220,7 +1220,7 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
if (!ptr)
goto out_unlock;
- dmabuf->vmap_ptr = ptr;
+ dmabuf->vmap_ptr.vaddr = ptr;
dmabuf->vmapping_counter = 1;
out_unlock:
@@ -1239,15 +1239,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
- BUG_ON(!dmabuf->vmap_ptr);
+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
BUG_ON(dmabuf->vmapping_counter == 0);
- BUG_ON(dmabuf->vmap_ptr != vaddr);
+ BUG_ON(!dma_buf_map_is_vaddr(&dmabuf->vmap_ptr, vaddr));
mutex_lock(&dmabuf->lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
dmabuf->ops->vunmap(dmabuf, vaddr);
- dmabuf->vmap_ptr = NULL;
+ dma_buf_map_clear(&dmabuf->vmap_ptr);
}
mutex_unlock(&dmabuf->lock);
}
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
new file mode 100644
index ..00143c88feb6
--- /dev/null
+++ b/include/linux/dma-buf-map.h
@@ -0,0 +1,82 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Pointer to dma-buf-mapped memory, plus helpers.
+ */
+
+#ifndef __DMA_BUF_MAP_H__
+#define __DMA_BUF_MAP_H__
+
+#include
+
+/**
+ * struct dma_buf_map - Pointer to vmap'ed dma-buf memory.
+ * @vaddr_iomem: The buffer's address if in I/O memory
+ * @vaddr: The buffer's address if in system memory
+ * @is_iomem: True if the dma-buf memory is located in I/O
+ * memory, or false otherwise.
+ */
+struct dma_buf_map {
+ union {
+ void __iomem *vaddr_iomem;
+ void *vaddr;
+ };
+ bool is_iomem;
+};
+
+/* API transition helper */
+static inline bool dma_buf_map_is_vaddr(const struct dma_buf_map *map, const
void *vaddr)
+{
+ return !map->is_iomem && (map->vaddr == vaddr);
+}
+
+/**
+ * dma_buf_map_is_null - Tests for a dma-buf mapping to be NULL
+ * @map: The dma-buf mapping structure
+ *
+ * Depending on the state of struct dma_buf_map.is_iomem, tests if the
+ * mapping is NULL.
+ *
+ * Returns:
+ * True if the mapping is NULL, or false otherwise.
+ */
+static inline bool dma_buf_map_is_null(const struct dma_buf_map *map)
+{
+ if (map->is_iomem)
+ return !map->vaddr_iomem;
+ return !map->vaddr;
+}
+
+/**
+ * dma_buf_map_is_set - Tests is the dma-buf mapping has been set
+ * @map: The dma-buf mapping structure
+ *
+ * Depending on the state of struct dma_buf_map.is_iomem, tests if the
+ * mapping has been set.
+ *
+ * Returns:
+ * True if the mapping is been set, or false otherwise.
+ */
+static inline bool dma_buf_map_is_set(const struct dma_buf_map *map)
+{
+ return !dma_buf_map_is_null(map);
+}
+
+/**
+ * dma_buf_map_clear - Cle
[PATCH v3 2/4] dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
struct dma_buf_map.
The interfaces used to return a buffer address. This address now gets
stored in an instance of the structure that is given as an additional
argument. The functions return an errno code on errors.
Users of the functions are updated accordingly. This is only an interface
change. It is currently expected that dma-buf memory can be accessed with
system memory load/store operations.
v3:
* update fastrpc driver (kernel test robot)
v2:
* always clear map parameter in dma_buf_vmap() (Daniel)
* include dma-buf-heaps and i915 selftests (kernel test robot)
Signed-off-by: Thomas Zimmermann
Acked-by: Sumit Semwal
Acked-by: Christian König
Acked-by: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 28 +++
drivers/dma-buf/heaps/heap-helpers.c | 8 --
drivers/gpu/drm/drm_gem_cma_helper.c | 13 +
drivers/gpu/drm/drm_gem_shmem_helper.c| 14 ++
drivers/gpu/drm/drm_prime.c | 9 --
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 8 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 11 ++--
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 12 ++--
.../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 10 +--
drivers/gpu/drm/tegra/gem.c | 18
.../common/videobuf2/videobuf2-dma-contig.c | 14 +++---
.../media/common/videobuf2/videobuf2-dma-sg.c | 16 +++
.../common/videobuf2/videobuf2-vmalloc.c | 15 +++---
drivers/misc/fastrpc.c| 6 ++--
include/drm/drm_prime.h | 3 +-
include/linux/dma-buf-map.h | 13 +
include/linux/dma-buf.h | 6 ++--
17 files changed, 143 insertions(+), 61 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5e849ca241a0..61bd24d21b38 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1186,46 +1186,50 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
* dma_buf_vmap - Create virtual mapping for the buffer object into kernel
* address space. Same restrictions as for vmap and friends apply.
* @dmabuf:[in]buffer to vmap
+ * @map: [out] returns the vmap pointer
*
* This call may fail due to lack of virtual mapping address space.
* These calls are optional in drivers. The intended use for them
* is for mapping objects linear in kernel space for high use objects.
* Please attempt to use kmap/kunmap before thinking about these interfaces.
*
- * Returns NULL on error.
+ * Returns 0 on success, or a negative errno code otherwise.
*/
-void *dma_buf_vmap(struct dma_buf *dmabuf)
+int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map)
{
- void *ptr;
+ struct dma_buf_map ptr;
+ int ret = 0;
+
+ dma_buf_map_clear(map);
if (WARN_ON(!dmabuf))
- return NULL;
+ return -EINVAL;
if (!dmabuf->ops->vmap)
- return NULL;
+ return -EINVAL;
mutex_lock(&dmabuf->lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
- ptr = dmabuf->vmap_ptr.vaddr;
+ *map = dmabuf->vmap_ptr;
goto out_unlock;
}
BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
- ptr = dmabuf->ops->vmap(dmabuf);
- if (WARN_ON_ONCE(IS_ERR(ptr)))
- ptr = NULL;
- if (!ptr)
+ ret = dmabuf->ops->vmap(dmabuf, &ptr);
+ if (WARN_ON_ONCE(ret))
goto out_unlock;
- dmabuf->vmap_ptr.vaddr = ptr;
+ dmabuf->vmap_ptr = ptr;
dmabuf->vmapping_counter = 1;
+ *map = dmabuf->vmap_ptr;
+
out_unlock:
mutex_unlock(&dmabuf->lock);
- return ptr;
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_vmap);
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
index d0696cf937af..aeb9e100f339 100644
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -235,7 +235,7 @@ static int dma_heap_dma_buf_end_cpu_access(struct dma_buf
*dmabuf,
return 0;
}
-static void *dma_heap_dma_buf_vmap(struct dma_buf *dmabuf)
+static int dma_heap_dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map
*map)
{
struct heap_helper_buffer *buffer = dmabuf->priv;
void *vaddr;
@@ -244,7 +244,11 @@ static void *dma_heap_dma_buf_vmap(struct dma_buf *dmabuf)
vaddr = dma_heap_buffer_vmap_get(buffer);
mutex_unlock(&buffer->lock);
- return vaddr;
+ if (!vaddr)
+ return -ENOMEM;
+ dma_buf_map_set_vaddr(map, vaddr);
+
+ return 0;
}
static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
diff --git a/drivers/gpu/drm/drm_gem_c
[PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory
Dma-buf provides vmap() and vunmap() for retriving and releasing mappings of dma-buf memory in kernel address space. The functions operate with plain addresses and the assumption is that the memory can be accessed with load and store operations. This is not the case on some architectures (e.g., sparc64) where I/O memory can only be accessed with dedicated instructions. This patchset introduces struct dma_buf_map, which contains the address of a buffer and a flag that tells whether system- or I/O-memory instructions are required. Some background: updating the DRM framebuffer console on sparc64 makes the kernel panic. This is because the framebuffer memory cannot be accessed with system-memory instructions. We currently employ a workaround in DRM to address this specific problem. [1] To resolve the problem, we'd like to address it at the most common point, which is the dma-buf framework. The dma-buf mapping ideally knows if I/O instructions are required and exports this information to it's users. The new structure struct dma_buf_map stores the buffer address and a flag that signals I/O memory. Affected users of the buffer (e.g., drivers, frameworks) can then access the memory accordingly. This patchset only introduces struct dma_buf_map, and updates struct dma_buf and it's interfaces. Further patches can update dma-buf users. For example, there's a prototype patchset for DRM that fixes the framebuffer problem. [2] Further work: TTM, one of DRM's memory managers, already exports an is_iomem flag of its own. It could later be switched over to exporting struct dma_buf_map, thus simplifying some code. Several DRM drivers expect their fbdev console to operate on I/O memory. These could possibly be switched over to the generic fbdev emulation, as soon as the generic code uses struct dma_buf_map. v3: * update fastrpc driver (kernel test robot) * expand documentation (Daniel) * move documentation into separate patch v2: * always clear map parameter in dma_buf_vmap() (Daniel) * include dma-buf-heaps and i915 selftests (kernel test robot) * initialize cma_obj before using it in drm_gem_cma_free_object() (kernel test robot) [1] https://lore.kernel.org/dri-devel/20200725191012.ga434...@ravnborg.org/ [2] https://lore.kernel.org/dri-devel/20200806085239.4606-1-tzimmerm...@suse.de/ Thomas Zimmermann (4): dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces dma-buf: Document struct dma_buf_map Documentation/driver-api/dma-buf.rst | 9 + drivers/dma-buf/dma-buf.c | 42 ++-- drivers/dma-buf/heaps/heap-helpers.c | 10 +- drivers/gpu/drm/drm_gem_cma_helper.c | 20 +- drivers/gpu/drm/drm_gem_shmem_helper.c| 17 +- drivers/gpu/drm/drm_prime.c | 15 +- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 13 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 13 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 18 +- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 14 +- drivers/gpu/drm/tegra/gem.c | 23 ++- .../common/videobuf2/videobuf2-dma-contig.c | 17 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 19 +- .../common/videobuf2/videobuf2-vmalloc.c | 21 +- drivers/misc/fastrpc.c| 6 +- include/drm/drm_prime.h | 5 +- include/linux/dma-buf-map.h | 193 ++ include/linux/dma-buf.h | 11 +- 18 files changed, 372 insertions(+), 94 deletions(-) create mode 100644 include/linux/dma-buf-map.h -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/vc4: crtc: Rework a bit the CRTC state code
On Fri, 25 Sep 2020 at 12:38, Maxime Ripard wrote: > > Hi Dave, > > On Wed, Sep 23, 2020 at 03:59:04PM +0100, Dave Stevenson wrote: > > Hi Maxime > > > > On Wed, 23 Sep 2020 at 09:40, Maxime Ripard wrote: > > > > > > The current CRTC state reset hook in vc4 allocates a vc4_crtc_state > > > structure as a drm_crtc_state, and relies on the fact that vc4_crtc_state > > > embeds drm_crtc_state as its first member, and therefore can be safely > > > casted. > > > > s/casted/cast > > > > > However, this is pretty fragile especially since there's no check for this > > > in place, and we're going to need to access vc4_crtc_state member at reset > > > so this looks like a good occasion to make it more robust. > > > > > > Signed-off-by: Maxime Ripard > > > Tested-by: Dave Stevenson > > > > Based on the issue I perceived with the previous patch, I'm happy. I > > haven't thought about how the framework handles losing the state, but > > that's not the driver's problem. > > > > There is still an implicit assumption that drm_crtc_state is the first > > member from the implementation of to_vc4_crtc_state in vc4_drv.h. To > > make it even more robust that could be a container_of instead. I > > haven't checked for any other places that make the assumption though. > > Good catch, I'll send another patch to fix it > > > Reviewed-by: Dave Stevenson > > Does it apply to the second patch as well? No. I got another interrupt before I'd refreshed my memory over what the second patch was doing and responding to it. I'll do that now (I don't think it changed much from v1) Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
On 25/09/2020 08:13, Leon Romanovsky wrote:
On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
On 22/09/2020 09:39, Leon Romanovsky wrote:
From: Maor Gottlieb
Extend __sg_alloc_table_from_pages to support dynamic allocation of
SG table from pages. It should be used by drivers that can't supply
all the pages at one time.
This function returns the last populated SGE in the table. Users should
pass it as an argument to the function from the second call and forward.
As before, nents will be equal to the number of populated SGEs (chunks).
So it's appending and growing the "list", did I get that right? Sounds handy
indeed. Some comments/questions below.
Yes, we (RDMA) use this function to chain contiguous pages.
I will eveluate if i915 could start using it. We have some loops which
build page by page and coalesce.
[snip]
if (unlikely(ret))
diff --git a/tools/testing/scatterlist/main.c b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
--- a/tools/testing/scatterlist/main.c
+++ b/tools/testing/scatterlist/main.c
@@ -55,14 +55,13 @@ int main(void)
for (i = 0, test = tests; test->expected_segments; test++, i++) {
struct page *pages[MAX_PAGES];
struct sg_table st;
- int ret;
+ struct scatterlist *sg;
set_pages(pages, test->pfn, test->num_pages);
- ret = __sg_alloc_table_from_pages(&st, pages, test->num_pages,
- 0, test->size, test->max_seg,
- GFP_KERNEL);
- assert(ret == test->alloc_ret);
+ sg = __sg_alloc_table_from_pages(&st, pages, test->num_pages, 0,
+ test->size, test->max_seg, NULL, 0, GFP_KERNEL);
+ assert(PTR_ERR_OR_ZERO(sg) == test->alloc_ret);
Some test coverage for relatively complex code would be very welcomed. Since
the testing framework is already there, even if it bit-rotted a bit, but
shouldn't be hard to fix.
A few tests to check append/grow works as expected, in terms of how the end
table looks like given the initial state and some different page patterns
added to it. And both crossing and not crossing into sg chaining scenarios.
This function is basic for all RDMA devices and we are pretty confident
that the old and new flows are tested thoroughly.
We will add proper test in next kernel cycle.
Patch seems to be adding a requirement that all callers of
(__)sg_alloc_table_from_pages pass in zeroed struct sg_table, which
wasn't the case so far.
Have you audited all the callers and/or fixed them? There seems to be
quite a few. Gut feel says problem would probably be better solved in
lib/scatterlist.c and not by making all the callers memset. Should be
possible if you make sure you only read st->nents if prev was passed in?
I've fixed the unit test and with this change the existing tests do
pass. But without zeroing it does fail on the very first, single page,
test scenario.
You can pull the unit test hacks from
git://people.freedesktop.org/~tursulin/drm-intel sgtest.
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: cdns-mhdp8546: fix compile warning
On 24/09/2020 14:48, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote: >> On x64 we get: >> >> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: >> conversion from 'long unsigned int' to 'unsigned int' changes value from >> '18446744073709551613' to '4294967293' [-Woverflow] >> >> The registers are 32 bit, so fix by casting to u32. > > I wonder if we need a BIT32 macro... This is a common issue, it would be > nice to handle it in the macros that define register fields. That's probably a good idea. I think #define BIT32(nr) (1u << (nr)) should work correct on all archs. Although I'm not quite sure if nr should be cast to u32, but in my tests a u64 nr doesn't cause type promotion to u64. Anyway, I'd like to merge this fix as it is to get rid of the warning for the merge window. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr
Hi
Am 23.09.20 um 16:27 schrieb Christian König:
> Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
>> The new type struct dma_buf_map represents a mapping of dma-buf memory
>> into kernel space. It contains a flag, is_iomem, that signals users to
>> access the mapped memory with I/O operations instead of regular loads
>> and stores.
>>
>> It was assumed that DMA buffer memory can be accessed with regular load
>> and store operations. Some architectures, such as sparc64, require the
>> use of I/O operations to access dma-map buffers that are located in I/O
>> memory. Providing struct dma_buf_map allows drivers to implement this.
>> This was specifically a problem when refreshing the graphics framebuffer
>> on such systems. [1]
>>
>> As the first step, struct dma_buf stores an instance of struct
>> dma_buf_map
>> internally. Afterwards, dma-buf's vmap and vunmap interfaces are be
>> converted. Finally, affected drivers can be fixed.
>>
>> [1]
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20200725191012.GA434957%40ravnborg.org%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C54486b9682654f3950b808d85fbcb1d3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637364611338153209&sdata=%2BZm7t8OcgkIxnY%2FdZSLhSbKC7t1y4VW5lINFKwCQv3A%3D&reserved=0
>>
>
> Only two nit picks below, apart from that Reviewed-by: Christian König
>
>
>>
>> Signed-off-by: Thomas Zimmermann
>> Acked-by: Sumit Semwal
>> ---
>> Documentation/driver-api/dma-buf.rst | 3 +
>> drivers/dma-buf/dma-buf.c | 14 ++---
>> include/linux/dma-buf-map.h | 87
>> include/linux/dma-buf.h | 3 +-
>> 4 files changed, 99 insertions(+), 8 deletions(-)
>> create mode 100644 include/linux/dma-buf-map.h
>>
>> diff --git a/Documentation/driver-api/dma-buf.rst
>> b/Documentation/driver-api/dma-buf.rst
>> index 13ea0cc0a3fa..3244c600a9a1 100644
>> --- a/Documentation/driver-api/dma-buf.rst
>> +++ b/Documentation/driver-api/dma-buf.rst
>> @@ -115,6 +115,9 @@ Kernel Functions and Structures Reference
>> .. kernel-doc:: include/linux/dma-buf.h
>> :internal:
>> +.. kernel-doc:: include/linux/dma-buf-map.h
>> + :internal:
>> +
>> Reservation Objects
>> ---
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 58564d82a3a2..5e849ca241a0 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -1207,12 +1207,12 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
>> mutex_lock(&dmabuf->lock);
>> if (dmabuf->vmapping_counter) {
>> dmabuf->vmapping_counter++;
>> - BUG_ON(!dmabuf->vmap_ptr);
>> - ptr = dmabuf->vmap_ptr;
>> + BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>> + ptr = dmabuf->vmap_ptr.vaddr;
>> goto out_unlock;
>> }
>> - BUG_ON(dmabuf->vmap_ptr);
>> + BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
>> ptr = dmabuf->ops->vmap(dmabuf);
>> if (WARN_ON_ONCE(IS_ERR(ptr)))
>> @@ -1220,7 +1220,7 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
>> if (!ptr)
>> goto out_unlock;
>> - dmabuf->vmap_ptr = ptr;
>> + dmabuf->vmap_ptr.vaddr = ptr;
>> dmabuf->vmapping_counter = 1;
>> out_unlock:
>> @@ -1239,15 +1239,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf,
>> void *vaddr)
>> if (WARN_ON(!dmabuf))
>> return;
>> - BUG_ON(!dmabuf->vmap_ptr);
>> + BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>> BUG_ON(dmabuf->vmapping_counter == 0);
>> - BUG_ON(dmabuf->vmap_ptr != vaddr);
>> + BUG_ON(!dma_buf_map_is_vaddr(&dmabuf->vmap_ptr, vaddr));
>> mutex_lock(&dmabuf->lock);
>> if (--dmabuf->vmapping_counter == 0) {
>> if (dmabuf->ops->vunmap)
>> dmabuf->ops->vunmap(dmabuf, vaddr);
>> - dmabuf->vmap_ptr = NULL;
>> + dma_buf_map_clear(&dmabuf->vmap_ptr);
>> }
>> mutex_unlock(&dmabuf->lock);
>> }
>> diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
>> new file mode 100644
>> index ..d4b1bb3cc4b0
>> --- /dev/null
>> +++ b/include/linux/dma-buf-map.h
>> @@ -0,0 +1,87 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Pointer to dma-buf-mapped memory, plus helpers.
>> + */
>> +
>> +#ifndef __DMA_BUF_MAP_H__
>> +#define __DMA_BUF_MAP_H__
>> +
>> +#include
>> +
>> +/**
>> + * struct dma_buf_map - Pointer to vmap'ed dma-buf memory.
>> + * @vaddr_iomem: The buffer's address if in I/O memory
>> + * @vaddr: The buffer's address if in system memory
>> + * @is_iomem: True if the dma-buf memory is located in I/O
>> + * memory, or false otherwise.
>> + *
>> + * Calling dma-buf's vmap operation returns a pointer to the buffer.
>> + * Depending on the location of the buffer, users may have to access it
>> + * with I/O operations or memory load/store operations. struct
>> dma_buf_map
>> + * stores the buffer add
Re: [PATCH 0/3] fbdev: stop using compat_alloc_user_space
On Thu, Sep 24, 2020 at 10:54 PM Sam Ravnborg wrote: > > Hi Daniel/Arnd. > > On Fri, Sep 18, 2020 at 02:48:08PM +0200, Daniel Vetter wrote: > > On Fri, Sep 18, 2020 at 12:08:10PM +0200, Arnd Bergmann wrote: > > > The fbdev code uses compat_alloc_user_space in a few of its > > > compat_ioctl handlers, which tends to be a bit more complicated > > > and error-prone than calling the underlying handlers directly, > > > so I would like to remove it completely. > > > > > > This modifies two such functions in fbdev, and removes another > > > one that is completely unused. > > > > > > Arnd > > > > > > Arnd Bergmann (3): > > > fbdev: simplify fb_getput_cmap() > > > fbdev: sbuslib: remove unused FBIOSCURSOR32 helper > > > fbdev: sbuslib: remove compat_alloc_user_space usage > > > > Looks all good, but we're also kinda looking for a new volunteer for > > handling fbdev patches ... drm-misc commit rights, still not interested? > > Hi Daniel - I read the above as an a-b. And Arnd did not take the bait > it seems. Ah right, I meant to reply but then forgot about it. I don't really want commit access, thanks for the offer. > Hi Arnd. checkpatch complained about some whitespace, which I fixed > while applying. > Will push to drm-misc-next tomorrow unless I hear anything else. Great, thanks! Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/stm: dsi: Use dev_ based logging
Standardize on the dev_ based logging and drop the include of drm_print.h.
Remove useless dsi_color_from_mipi function.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 87 ++-
1 file changed, 45 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 164f79ef6269..93fa8bfd3127 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -76,6 +76,7 @@ enum dsi_color {
struct dw_mipi_dsi_stm {
void __iomem *base;
+ struct device *dev;
struct clk *pllref_clk;
struct dw_mipi_dsi *dsi;
u32 hw_version;
@@ -110,23 +111,6 @@ static inline void dsi_update_bits(struct dw_mipi_dsi_stm
*dsi, u32 reg,
dsi_write(dsi, reg, (dsi_read(dsi, reg) & ~mask) | val);
}
-static enum dsi_color dsi_color_from_mipi(enum mipi_dsi_pixel_format fmt)
-{
- switch (fmt) {
- case MIPI_DSI_FMT_RGB888:
- return DSI_RGB888;
- case MIPI_DSI_FMT_RGB666:
- return DSI_RGB666_CONF2;
- case MIPI_DSI_FMT_RGB666_PACKED:
- return DSI_RGB666_CONF1;
- case MIPI_DSI_FMT_RGB565:
- return DSI_RGB565_CONF1;
- default:
- DRM_DEBUG_DRIVER("MIPI color invalid, so we use rgb888\n");
- }
- return DSI_RGB888;
-}
-
static int dsi_pll_get_clkout_khz(int clkin_khz, int idf, int ndiv, int odf)
{
int divisor = idf * odf;
@@ -205,14 +189,14 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_RRS,
SLEEP_US, TIMEOUT_US);
if (ret)
- DRM_DEBUG_DRIVER("!TIMEOUT! waiting REGU, let's continue\n");
+ dev_dbg(dsi->dev, "!TIMEOUT! waiting REGU, let's continue\n");
/* Enable the DSI PLL & wait for its lock */
dsi_set(dsi, DSI_WRPCR, WRPCR_PLLEN);
ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_PLLLS,
SLEEP_US, TIMEOUT_US);
if (ret)
- DRM_DEBUG_DRIVER("!TIMEOUT! waiting PLL, let's continue\n");
+ dev_dbg(dsi->dev, "!TIMEOUT! waiting PLL, let's continue\n");
return 0;
}
@@ -221,7 +205,7 @@ static void dw_mipi_dsi_phy_power_on(void *priv_data)
{
struct dw_mipi_dsi_stm *dsi = priv_data;
- DRM_DEBUG_DRIVER("\n");
+ dev_dbg(dsi->dev, "\n");
/* Enable the DSI wrapper */
dsi_set(dsi, DSI_WCR, WCR_DSIEN);
@@ -231,7 +215,7 @@ static void dw_mipi_dsi_phy_power_off(void *priv_data)
{
struct dw_mipi_dsi_stm *dsi = priv_data;
- DRM_DEBUG_DRIVER("\n");
+ dev_dbg(dsi->dev, "\n");
/* Disable the DSI wrapper */
dsi_clear(dsi, DSI_WCR, WCR_DSIEN);
@@ -244,6 +228,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
{
struct dw_mipi_dsi_stm *dsi = priv_data;
unsigned int idf, ndiv, odf, pll_in_khz, pll_out_khz;
+ enum mipi_dsi_pixel_format fmt;
int ret, bpp;
u32 val;
@@ -267,11 +252,11 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
if (pll_out_khz > dsi->lane_max_kbps) {
pll_out_khz = dsi->lane_max_kbps;
- DRM_WARN("Warning max phy mbps is used\n");
+ dev_warn(dsi->dev, "Warning max phy mbps is used\n");
}
if (pll_out_khz < dsi->lane_min_kbps) {
pll_out_khz = dsi->lane_min_kbps;
- DRM_WARN("Warning min phy mbps is used\n");
+ dev_warn(dsi->dev, "Warning min phy mbps is used\n");
}
/* Compute best pll parameters */
@@ -281,7 +266,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
ret = dsi_pll_get_params(dsi, pll_in_khz, pll_out_khz,
&idf, &ndiv, &odf);
if (ret)
- DRM_WARN("Warning dsi_pll_get_params(): bad params\n");
+ dev_warn(dsi->dev, "Warning dsi_pll_get_params(): bad
params\n");
/* Get the adjusted pll out value */
pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
@@ -297,14 +282,31 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
/* Select video mode by resetting DSIM bit */
dsi_clear(dsi, DSI_WCFGR, WCFGR_DSIM);
+ switch (format) {
+ case MIPI_DSI_FMT_RGB888:
+ fmt = DSI_RGB888;
+ break;
+ case MIPI_DSI_FMT_RGB666:
+ fmt = DSI_RGB666_CONF2;
+ break;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ fmt = DSI_RGB666_CONF1;
+ break;
+ case MIPI_DSI_FMT_RGB565:
+ fmt = DSI_RGB565_CONF1;
+ break;
+ default:
+ fmt = DSI_RGB888;
+
Re: [PATCH] drm/etnaviv: Drop local dma_parms
On Do, 2020-09-03 at 21:40 +0100, Robin Murphy wrote:
> Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
> for platform devices"), struct platform_device already provides a
> dma_parms structure, so we can save allocating another one.
>
> Signed-off-by: Robin Murphy
Thanks, applied to etnaviv/next.
Regards,
Lucas
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
> 2 files changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index a9a3afaef9a1..79b3bcd9f444 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -535,7 +535,6 @@ static int etnaviv_bind(struct device *dev)
> }
> drm->dev_private = priv;
>
> - dev->dma_parms = &priv->dma_parms;
> dma_set_max_seg_size(dev, SZ_2G);
>
> mutex_init(&priv->gem_lock);
> @@ -585,8 +584,6 @@ static void etnaviv_unbind(struct device *dev)
>
> component_unbind_all(dev, drm);
>
> - dev->dma_parms = NULL;
> -
> etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
>
> drm->dev_private = NULL;
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> index 4d8dc9236e5f..7db607817c0c 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> @@ -33,7 +33,6 @@ struct etnaviv_file_private {
>
> struct etnaviv_drm_private {
> int num_gpus;
> - struct device_dma_parameters dma_parms;
> struct etnaviv_gpu *gpu[ETNA_MAX_PIPES];
> gfp_t shm_gfp_mask;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/etnaviv: add total hi bandwidth perf counters
On Fr, 2020-08-14 at 11:05 +0200, Christian Gmeiner wrote: > This little patch set adds support for the total bandwidth used by HI. The > basic hi bandwidth read-out is quite simple but I needed to add some little > clean-ups to make it nice looking. > > Christian Gmeiner (4): > drm/etnaviv: rename pipe_reg_read(..) > drm/etnaviv: call perf_reg_read(..) > drm/etnaviv: add total hi bandwidth perfcounter > drm/etnaviv: add pipe_select(..) helper > > drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 78 --- > 1 file changed, 55 insertions(+), 23 deletions(-) Thanks, I've applied the whole series to my etnaviv/next branch. regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/etnaviv: add total hi bandwidth perfcounter
On Fr, 2020-08-14 at 11:05 +0200, Christian Gmeiner wrote:
> These two perf counters represent the total read and write
> GPU bandwidth in terms of 64bits.
>
> The used sequence was taken from Vivante kernel driver.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 35 ++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> index 782732e6ce72..b37459f022d7 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> @@ -69,6 +69,29 @@ static u32 pipe_perf_reg_read(struct etnaviv_gpu *gpu,
> return value;
> }
>
> +static u32 pipe_reg_read(struct etnaviv_gpu *gpu,
> + const struct etnaviv_pm_domain *domain,
> + const struct etnaviv_pm_signal *signal)
> +{
> + u32 clock = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL);
> + u32 value = 0;
> + unsigned i;
> +
> + for (i = 0; i < gpu->identity.pixel_pipes; i++) {
> + clock &= ~(VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE__MASK);
> + clock |= VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE(i);
> + gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, clock);
> + value += gpu_read(gpu, signal->data);
> + }
> +
> + /* switch back to pixel pipe 0 to prevent GPU hang */
> + clock &= ~(VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE__MASK);
> + clock |= VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE(0);
> + gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, clock);
> +
> + return value;
> +}
> +
> static u32 hi_total_cycle_read(struct etnaviv_gpu *gpu,
> const struct etnaviv_pm_domain *domain,
> const struct etnaviv_pm_signal *signal)
> @@ -102,8 +125,18 @@ static const struct etnaviv_pm_domain doms_3d[] = {
> .name = "HI",
> .profile_read = VIVS_MC_PROFILE_HI_READ,
> .profile_config = VIVS_MC_PROFILE_CONFIG2,
> - .nr_signals = 5,
> + .nr_signals = 7,
I've tripped across this part. It's something I don't particularly
like, as this value has a risk of getting inconsistent with the actual
array. Maybe we could split out signal array from this initialization,
so we could then use the ARRAY_SIZE macro to initialize this value?
But that's not really related to this patch and can be done in a
follow-up cleanup.
Regards,
Lucas
> .signal = (const struct etnaviv_pm_signal[]) {
> + {
> + "TOTAL_READ_BYTES8",
> + VIVS_HI_PROFILE_READ_BYTES8,
> + &pipe_reg_read,
> + },
> + {
> + "TOTAL_WRITE_BYTES8",
> + VIVS_HI_PROFILE_WRITE_BYTES8,
> + &pipe_reg_read,
> + },
> {
> "TOTAL_CYCLES",
> 0,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
Am 25.09.20 um 10:18 schrieb Daniel Vetter: On Fri, Sep 25, 2020 at 10:16 AM Daniel Vetter wrote: On Fri, Sep 25, 2020 at 9:39 AM Christian König wrote: Am 25.09.20 um 01:14 schrieb Dave Airlie: On Thu, 24 Sep 2020 at 22:42, Christian König wrote: Am 24.09.20 um 07:18 schrieb Dave Airlie: From: Dave Airlie All the accel moves do the same pattern here, provide a helper And exactly that pattern I want to get away from. Currently this is just refactoring out the helper code in each driver, but I see since it calls bo_mem_space we are probably moving a bit in the wrong direction. Exactly that's why I'm noting this. See what happens if we (for example) have a VRAM -> SYSTEM move is the following: 1. TTM allocates a new ttm_resource object in the SYSTEM domain. 2. We call the driver to move from VRAM to SYSTEM. 3. Driver finds that it can't do this and calls TTM to allocate GTT. 4. Since we are maybe out of GTT TTM evicts a different BO from GTT to SYSTEM and call driver again. This is a horrible ping/pong between driver/TTM/driver/TTM/driver and we should stop that immediately. My suggestion is that we rewrite how drivers call the ttm_bo_validate() function so that we can guarantee that this never happens. What do you think? I think that is likely the next step I'd like to take after this refactor, it's a lot bigger, and I'm not sure how it will look yet. Agree, yes. I have some ideas in mind for that, but not fully baked either. Do we envision the driver calling validate in a loop but when it can't find space it tells the driver and the driver does eviction and recalls validate? Not in a loop, but more like in a chain. My plan is something like this: Instead of having "normal" and "busy" placement we have a flag in the context if evictions are allowed or not. The call to ttm_bo_validate are then replaced with two calls, first without evictions and if that didn't worked one with evictions. Then the normal validate sequence should look like this: 1. If a BO is in the SYSTEM (or SWAP domain) we validate it to GTT first with evictions=true. 2. If a BO should be in VRAM we then validate it to VRAM. If evictions are only allowed if the GEM flags say that GTT is not desired. That solves the trouble when you move a bo into vram as part of validate. But I'm not seeing how this solves the "need gtt mapping to move something out of vram" problem. Eviction is not a problem because the driver gets asked where to put an evicted BO and then TTM does all the moving. Or should we instead move the entire eviction logic out from ttm into drivers, building it up from helpers? I've been playing with that thought for a while as well, but then decided against it. The main problem I see is that we sometimes need to evict things from other drivers. E.g. when we overcommitted system memory and move things to swap for example. Then drivers which need gtt for moving stuff out of vram can do that right away. Also, this would allow us to implement very fancy eviction algorithms like all the nonsense we're doing in i915 for gtt handling on gen2/3 (but I really hope that never ever becomes a thing again in future gpus, so this is maybe more a what-if kind of thing). Not sure how that would look like, maybe a special validate function which takes a ttm_resource the driver already found (through evicting stuff or whatever) and then ttm just does the move and book-keeping and everything. And drivers would at first only call validate without allowing any eviction. Ofc anyone without special needs could use the standard eviction function that validate already has. Spinning this a bit more, we could have different default eviction functions with this, e.g. so all the drivers that need gtt mapping for moving stuff around can share that code, but with specific&flat control flow instead of lots of ping-ping. And drivers that don't need gtt mapping (like i915, we just need dma_map_sg which we assume works always, or something from the ttm dma page pool, which really always works) can then use something simpler that's completely flat. Ok you need to explain a bit more what exactly the problem with the GTT eviction is here :) Christian. -Daniel For special BOs, like amdgpus GDS, GWS and OA domain or VMWGFX special domains that will obviously look a bit different. Christian. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C66b5c2bfed8541cd986208d8612b8e1d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637366187002213152&sdata=OPdXMe2rG1Uy%2BZD%2BjYKHfkLc9xVAQ1AL23QbEu3drnE%3D&reserved=0 -- Daniel Vetter Software Engineer, Intel Corporation https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C66b5c2b
Re: [PATCH 2/2] drm/atomic: debug output for EBUSY
On Fri, 25 Sep 2020 10:46:51 +0200 Daniel Vetter wrote: > Hopefully we'll have the drm crash recorder RSN, but meanwhile > compositors would like to know a bit better why they get an EBUSY. > > v2: Move misplaced hunk to the right patch (Pekka) Hi, both patches Acked-by: Pekka Paalanen Thanks, pq pgpZIDBA1GbbF.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Deleted the drm_device declaration
On Fri, Sep 25, 2020 at 04:51:38PM +0800, Tian Tao wrote: > drm_modeset_lock.h already declares struct drm_device, so there's no > need to declare it in vc4_drv.h > > Signed-off-by: Tian Tao Just an aside, when submitting patches please use scripts/get_maintainers.pl to generate the recipient list. Looking through past few patches from you it seems fairly arbitrary and often misses the actual maintainers for a given piece of code, which increases the odds the patch will get lost a lot. E.g. for this one I'm only like the 5th or so fallback person, and the main maintainer isn't on the recipient list. Cheeers, Daniel > --- > drivers/gpu/drm/vc4/vc4_drv.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h > index 8c8d96b..8717a1c 100644 > --- a/drivers/gpu/drm/vc4/vc4_drv.h > +++ b/drivers/gpu/drm/vc4/vc4_drv.h > @@ -19,7 +19,6 @@ > > #include "uapi/drm/vc4_drm.h" > > -struct drm_device; > struct drm_gem_object; > > /* Don't forget to update vc4_bo.c: bo_type_names[] when adding to > -- > 2.7.4 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 11/23] device-dax: Kill dax_kmem_res
On 24.09.20 23:50, Dan Williams wrote: > On Thu, Sep 24, 2020 at 2:42 PM David Hildenbrand wrote: >> >> >> >>> Am 24.09.2020 um 23:26 schrieb Dan Williams : >>> >>> [..] > I'm not suggesting to busy the whole "virtio" range, just the portion > that's about to be passed to add_memory_driver_managed(). I'm afraid I don't get your point. For virtio-mem: Before: 1. Create virtio0 container resource 2. (somewhen in the future) add_memory_driver_managed() - Create resource (System RAM (virtio_mem)), marking it busy/driver managed After: 1. Create virtio0 container resource 2. (somewhen in the future) Create resource (System RAM (virtio_mem)), marking it busy/driver managed 3. add_memory_driver_managed() Not helpful or simpler IMHO. >>> >>> The concern I'm trying to address is the theoretical race window and >>> layering violation in this sequence in the kmem driver: >>> >>> 1/ res = request_mem_region(...); >>> 2/ res->flags = IORESOURCE_MEM; >>> 3/ add_memory_driver_managed(); >>> >>> Between 2/ and 3/ something can race and think that it owns the >>> region. Do I think it will happen in practice, no, but it's still a >>> pattern that deserves come cleanup. >> >> I think in that unlikely event (rather impossible), >> add_memory_driver_managed() should fail, detecting a conflicting (busy) >> resource. Not sure what will happen next ( and did not double-check). > > add_memory_driver_managed() will fail, but the release_mem_region() in > kmem to unwind on the error path will do the wrong thing because that > other driver thinks it got ownership of the region. > I think if somebody would race and claim the region for itself (after we unchecked the BUSY flag), there would be another memory resource below our resource container (e.g., via __request_region()). So, interestingly, the current code will do a release_resource->__release_resource(old, true); which will remove whatever somebody added below the resource. If we were to do a remove_resource->__release_resource(old, false); we would only remove what we temporarily added, relocating anychildren (someone nasty added). But yeah, I don't think we have to worry about this case. >> But yeah, the way the BUSY bit is cleared here is wrong - simply overwriting >> other bits. And it would be even better if we could avoid manually messing >> with flags here. > > I'm ok to leave it alone for now (hasn't been and likely never will be > a problem in practice), but I think it was still worth grumbling Definitely, it gives us a better understanding. > about. I'll leave that part of kmem alone in the upcoming split of > dax_kmem_res removal. Yeah, stuff is more complicated than I would wished, so I guess it's better to leave it alone for now until we actually see issues with somebody else regarding *our* device-owned region (or we're able to come up with a cleanup that keeps all corner cases working for kmem and virtio-mem). -- Thanks, David / dhildenb ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CRTC is currently busy doing a page_flip the
ALLOW_MODESET commit can fail with an EBUSY
- on the other CRTC a normal atomic flip can fail with EBUSY because
of the additional commit inserted by the kernel without userspace's
knowledge
For blocking commits this isn't a problem, because everyone else will
just block until all the CRTC are reconfigured. Only thing userspace
can notice is the dropped frames without any reason for why frames got
dropped.
Consensus is that we need new uapi to handle this properly, but no one
has any idea what exactly the new uapi should look like. Since this
has been shipping for years already compositors need to deal no matter
what, so as a first step just try to enforce this across drivers
better with some checks.
v2: Add comments and a WARN_ON to enforce this only when allowed - we
don't want to silently convert page flips into blocking plane updates
just because the driver is buggy.
v3: Fix inverted WARN_ON (Pekka).
v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
rules for drivers.
v5: Make the WARNING more informative (Daniel)
v6: Add unconditional debug output for compositor hackers to figure
out what's going on when they get an EBUSY (Daniel)
v7: Fix up old/new_crtc_state confusion for real (Pekka/Ville)
References:
https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 58527f151984..aac9122f1da2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
* needed. It will also grab the relevant CRTC lock to make sure that the state
* is consistent.
*
+ * WARNING: Drivers may only add new CRTC states to a @state if
+ * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
+ * not created by userspace through an IOCTL call.
+ *
* Returns:
*
* Either the allocated state or the error code encoded into the pointer. When
@@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
*state)
struct drm_crtc_state *new_crtc_state;
struct drm_connector *conn;
struct drm_connector_state *conn_state;
+ unsigned requested_crtc = 0;
+ unsigned affected_crtc = 0;
int i, ret = 0;
DRM_DEBUG_ATOMIC("checking %p\n", state);
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
+ requested_crtc |= drm_crtc_mask(crtc);
+
for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
if (ret) {
@@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
+ affected_crtc |= drm_crtc_mask(crtc);
+
+ /*
+* For commits that allow modesets drivers can add other CRTCs to the
+* atomic commit, e.g. when they need to reallocate global resources.
+* This can cause spurious EBUSY, which robs compositors of a very
+* effective sanity check for their drawing loop. Therefor only allow
+* drivers to add unrelated CRTC states for modeset commits.
+*
+* FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
+* so compositors know what's going on.
+*/
+ if (affected_crtc != requested_crtc) {
+ DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x,
affected 0x%0x\n",
+requested_crtc, affected_crtc);
+ WARN(!state->allow_modeset, "adding CRTC not allowed without
modesets: requested 0x%x, affected 0x%0x\n",
+requested_crtc, affected_crtc);
+ }
+
return 0;
}
EXPORT_SYMBOL(drm_atomic_check_only);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/atomic: debug output for EBUSY
Hopefully we'll have the drm crash recorder RSN, but meanwhile
compositors would like to know a bit better why they get an EBUSY.
v2: Move misplaced hunk to the right patch (Pekka)
Cc: Sean Paul
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index e8ab7fd1..6b3bfabac26c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1740,8 +1740,11 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
* overridden by a previous synchronous update's state.
*/
if (old_plane_state->commit &&
- !try_wait_for_completion(&old_plane_state->commit->hw_done))
+ !try_wait_for_completion(&old_plane_state->commit->hw_done)) {
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] inflight previous commit
preventing async commit\n",
+ plane->base.id, plane->name);
return -EBUSY;
+ }
return funcs->atomic_async_check(plane, new_plane_state);
}
@@ -1964,6 +1967,9 @@ static int stall_checks(struct drm_crtc *crtc, bool
nonblock)
* commit with nonblocking ones. */
if (!completed && nonblock) {
spin_unlock(&crtc->commit_lock);
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] busy with a
previous commit\n",
+ crtc->base.id, crtc->name);
+
return -EBUSY;
}
} else if (i == 1) {
@@ -2132,8 +2138,12 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
/* Userspace is not allowed to get ahead of the previous
* commit with nonblocking ones. */
if (nonblock && old_conn_state->commit &&
-
!try_wait_for_completion(&old_conn_state->commit->flip_done))
+
!try_wait_for_completion(&old_conn_state->commit->flip_done)) {
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] busy with a
previous commit\n",
+ conn->base.id, conn->name);
+
return -EBUSY;
+ }
/* Always track connectors explicitly for e.g. link retraining.
*/
commit = crtc_or_fake_commit(state, new_conn_state->crtc ?:
old_conn_state->crtc);
@@ -2147,8 +2157,12 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
/* Userspace is not allowed to get ahead of the previous
* commit with nonblocking ones. */
if (nonblock && old_plane_state->commit &&
-
!try_wait_for_completion(&old_plane_state->commit->flip_done))
+
!try_wait_for_completion(&old_plane_state->commit->flip_done)) {
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] busy with a previous
commit\n",
+ plane->base.id, plane->name);
+
return -EBUSY;
+ }
/* Always track planes explicitly for async pageflip support. */
commit = crtc_or_fake_commit(state, new_plane_state->crtc ?:
old_plane_state->crtc);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
On Fri, Sep 25, 2020 at 11:24:46AM +0300, Pekka Paalanen wrote:
> On Wed, 23 Sep 2020 17:18:52 +0200
> Daniel Vetter wrote:
>
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
> >
> > But in nonblocking mode userspace has then no idea this happened,
> > which can lead to spurious EBUSY calls, both:
> > - when that other CRTC is currently busy doing a page_flip the
> > ALLOW_MODESET commit can fail with an EBUSY
> > - on the other CRTC a normal atomic flip can fail with EBUSY because
> > of the additional commit inserted by the kernel without userspace's
> > knowledge
> >
> > For blocking commits this isn't a problem, because everyone else will
> > just block until all the CRTC are reconfigured. Only thing userspace
> > can notice is the dropped frames without any reason for why frames got
> > dropped.
> >
> > Consensus is that we need new uapi to handle this properly, but no one
> > has any idea what exactly the new uapi should look like. Since this
> > has been shipping for years already compositors need to deal no matter
> > what, so as a first step just try to enforce this across drivers
> > better with some checks.
> >
> > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > don't want to silently convert page flips into blocking plane updates
> > just because the driver is buggy.
> >
> > v3: Fix inverted WARN_ON (Pekka).
> >
> > v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
> > rules for drivers.
> >
> > v5: Make the WARNING more informative (Daniel)
> >
> > v6: Add unconditional debug output for compositor hackers to figure
> > out what's going on when they get an EBUSY (Daniel)
>
> ... gmail workaround ...
>
> > ---
> > drivers/gpu/drm/drm_atomic.c | 29 +
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 58527f151984..f1a912e80846 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
> > * needed. It will also grab the relevant CRTC lock to make sure that the
> > state
> > * is consistent.
> > *
> > + * WARNING: Drivers may only add new CRTC states to a @state if
> > + * drm_atomic_state.allow_modeset is set, or if it's a driver-internal
> > commit
> > + * not created by userspace through an IOCTL call.
> > + *
> > * Returns:
> > *
> > * Either the allocated state or the error code encoded into the pointer.
> > When
> > @@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> > struct drm_crtc_state *new_crtc_state;
> > struct drm_connector *conn;
> > struct drm_connector_state *conn_state;
> > + unsigned requested_crtc = 0;
> > + unsigned affected_crtc = 0;
> > int i, ret = 0;
> >
> > DRM_DEBUG_ATOMIC("checking %p\n", state);
> >
> > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > + requested_crtc |= drm_crtc_mask(crtc);
>
> Is "old crtc state" the state that userspace is requesting as the new
> state?
It's a dummy iterator variable we don't care about, all we really want is
to know which crtc are all part of the update. But everyone else also
wants the state.
I'll shuffle the patches so the hunk Ville requested is in the right
patch.
-Daniel
>
> > +
> > for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> > new_plane_state, i) {
> > ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> > if (ret) {
> > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> > }
> > }
> >
> > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > + affected_crtc |= drm_crtc_mask(crtc);
>
> And after driver check processing, the "old crtc state" has been
> modified by the driver to add anything it will necessarily need like
> other CRTCs?
>
> What is "new state" then?
>
> > +
> > + /*
> > +* For commits that allow modesets drivers can add other CRTCs to the
> > +* atomic commit, e.g. when they need to reallocate global resources.
> > +* This can cause spurious EBUSY, which robs compositors of a very
> > +* effective sanity check for their drawing loop. Therefor only allow
> > +* drivers to add unrelated CRTC states for modeset commits.
> > +*
> > +* FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
> > +* so compositors know what's going on.
> > +*/
> > + if (affected_crtc != requested_crtc) {
> > + DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x,
> > affected 0x%0x\n",
> > +requested_crtc, affected_crtc);
> > + WARN(!state->allow_modeset, "adding CRTC not allowed without
>
Re: [PATCH v3 00/22] Convert all remaining drivers to GEM object functions
Hi Am 23.09.20 um 16:33 schrieb Christian König: > Feel free to add an Acked-by: Christian König > to all patches which I haven't explicitly reviewed. Done, thanks. > > I would say we should just push this to drm-misc-next now. It's merged now. Best regards Thomas > > Thanks for the nice cleanup, > Christian. > > Am 23.09.20 um 12:21 schrieb Thomas Zimmermann: >> The GEM and PRIME related callbacks in struct drm_driver are >> deprecated in >> favor of GEM object functions in struct drm_gem_object_funcs. This >> patchset >> converts the remaining drivers to object functions and removes most of >> the >> obsolete interfaces. >> >> Version 3 of this patchset mostly fixes drm_gem_prime_handle_to_fd and >> updates i.MX's dcss driver. The driver was missing from earlier versions >> and still needs review. >> >> Patches #1 to #6, #8 to #17 and #19 to #20 convert DRM drivers to GEM >> object >> functions, one by one. Each patch moves existing callbacks from struct >> drm_driver to an instance of struct drm_gem_object_funcs, and sets these >> funcs when the GEM object is initialized. The expection is >> .gem_prime_mmap. >> There are different ways of how drivers implement the callback, and >> moving >> it to GEM object functions requires a closer review for each. >> >> Patch #18 fixes virtgpu to use GEM object functions where possible. The >> driver recently introduced a function for one of the deprecated >> callbacks. >> >> Patches #7 and #20 convert i.MX's dcss and xlnx to CMA helper macros. >> There's >> no apparent reason why the drivers do the GEM setup on their's own. >> Using CMA >> helper macros adds GEM object functions implicitly. >> >> With most of the GEM and PRIME moved to GEM object functions, related >> code >> in struct drm_driver and in the DRM core/helpers is being removed by >> patch >> #22. >> >> Further testing is welcome. I tested the drivers for which I have HW >> available. These are gma500, i915, nouveau, radeon and vc4. The console, >> Weston and Xorg apparently work with the patches applied. >> >> v3: >> * restore default call to drm_gem_prime_export() in >> drm_gem_prime_handle_to_fd() >> * return -ENOSYS if get_sg_table is not set >> * drop all checks for obj->funcs >> * clean up TODO list and documentation >> v2: >> * moved code in amdgpu and radeon >> * made several functions static in various drivers >> * updated TODO-list item >> * fix virtgpu >> >> Thomas Zimmermann (22): >> drm/amdgpu: Introduce GEM object functions >> drm/armada: Introduce GEM object functions >> drm/etnaviv: Introduce GEM object functions >> drm/exynos: Introduce GEM object functions >> drm/gma500: Introduce GEM object functions >> drm/i915: Introduce GEM object functions >> drm/imx/dcss: Initialize DRM driver instance with CMA helper macro >> drm/mediatek: Introduce GEM object functions >> drm/msm: Introduce GEM object funcs >> drm/nouveau: Introduce GEM object functions >> drm/omapdrm: Introduce GEM object functions >> drm/pl111: Introduce GEM object functions >> drm/radeon: Introduce GEM object functions >> drm/rockchip: Convert to drm_gem_object_funcs >> drm/tegra: Introduce GEM object functions >> drm/vc4: Introduce GEM object functions >> drm/vgem: Introduce GEM object functions >> drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs >> drm/vkms: Introduce GEM object functions >> drm/xen: Introduce GEM object functions >> drm/xlnx: Initialize DRM driver instance with CMA helper macro >> drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver >> >> Documentation/gpu/drm-mm.rst | 4 +- >> Documentation/gpu/todo.rst | 9 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 -- >> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 23 +++-- >> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 5 -- >> drivers/gpu/drm/armada/armada_drv.c | 3 - >> drivers/gpu/drm/armada/armada_gem.c | 12 ++- >> drivers/gpu/drm/armada/armada_gem.h | 2 - >> drivers/gpu/drm/drm_gem.c | 53 >> drivers/gpu/drm/drm_gem_cma_helper.c | 8 +- >> drivers/gpu/drm/drm_prime.c | 14 +-- >> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 --- >> drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - >> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 19 - >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 --- >> drivers/gpu/drm/exynos/exynos_drm_gem.c | 15 >> drivers/gpu/drm/gma500/framebuffer.c | 2 + >> drivers/gpu/drm/gma500/gem.c | 18 +++- >> drivers/gpu/drm/gma500/gem.h | 3 + >> drivers/gpu/drm/gma500/psb_drv.c | 9 -- >> drivers/gpu/drm/gma500/psb_drv.h | 2 - >> drivers/gpu/drm/i915/gem/i915_gem_object.c | 21 - >> drivers/gpu/drm/i915/ge
Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
On Thu, Sep 24, 2020 at 04:09:37PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 24, 2020 at 09:38:22AM -0400, Peilin Ye wrote:
> > Hi all,
> >
> > syzbot has reported [1] a global out-of-bounds read issue in
> > fbcon_get_font(). A malicious user may resize `vc_font.height` to a large
> > value in vt_ioctl(), causing fbcon_get_font() to overflow our built-in
> > font data buffers, declared in lib/fonts/font_*.c:
> >
> > (e.g. lib/fonts/font_8x8.c)
> > #define FONTDATAMAX 2048
> >
> > static const unsigned char fontdata_8x8[FONTDATAMAX] = {
> >
> > /* 0 0x00 '^@' */
> > 0x00, /* */
> > 0x00, /* */
> > 0x00, /* */
> > 0x00, /* */
> > 0x00, /* */
> > 0x00, /* */
> > 0x00, /* */
> > 0x00, /* */
> > [...]
> >
> > In order to perform a reliable range check, fbcon_get_font() needs to know
> > `FONTDATAMAX` for each built-in font under lib/fonts/. Unfortunately, we
> > do not keep that information in our font descriptor,
> > `struct console_font`:
> >
> > (include/uapi/linux/kd.h)
> > struct console_font {
> > unsigned int width, height; /* font size */
> > unsigned int charcount;
> > unsigned char *data;/* font data with height fixed to 32 */
> > };
> >
> > To make things worse, `struct console_font` is part of the UAPI, so we
> > cannot add a new field to keep track of `FONTDATAMAX`.
> >
> > Fortunately, the framebuffer layer itself gives us a hint of how to
> > resolve this issue without changing UAPI. When allocating a buffer for a
> > user-provided font, fbcon_set_font() reserves four "extra words" at the
> > beginning of the buffer:
> >
> > (drivers/video/fbdev/core/fbcon.c)
> > new_data = kmalloc(FONT_EXTRA_WORDS * sizeof(int) + size, GFP_USER);
> > [...]
> > new_data += FONT_EXTRA_WORDS * sizeof(int);
> > FNTSIZE(new_data) = size;
> > FNTCHARCNT(new_data) = charcount;
> > REFCOUNT(new_data) = 0; /* usage counter */
> > [...]
> > FNTSUM(new_data) = csum;
> >
> > Later, to get the size of a data buffer, the framebuffer layer simply
> > calls FNTSIZE() on it:
> >
> > (drivers/video/fbdev/core/fbcon.h)
> > /* Font */
> > #define REFCOUNT(fd)(((int *)(fd))[-1])
> > #define FNTSIZE(fd) (((int *)(fd))[-2])
> > #define FNTCHARCNT(fd) (((int *)(fd))[-3])
> > #define FNTSUM(fd) (((int *)(fd))[-4])
> > #define FONT_EXTRA_WORDS 4
> >
> > Currently, this is only done for user-provided fonts. Let us do the same
> > thing for built-in fonts, prepend these "extra words" (including
> > `FONTDATAMAX`) to their data buffers, so that other subsystems, like the
> > framebuffer layer, can use these macros on all fonts, no matter built-in
> > or user-provided. As an example, this series fixes the syzbot issue in
> > fbcon_get_font():
> >
> > (drivers/video/fbdev/core/fbcon.c)
> > if (font->width <= 8) {
> > j = vc->vc_font.height;
> > + if (font->charcount * j > FNTSIZE(fontdata))
> > + return -EINVAL;
> > [...]
> >
> > Similarly, newport_con also use these macros. It only uses three of them:
> >
> > (drivers/video/console/newport_con.c)
> > /* borrowed from fbcon.c */
> > #define REFCOUNT(fd)(((int *)(fd))[-1])
> > #define FNTSIZE(fd) (((int *)(fd))[-2])
> > #define FNTCHARCNT(fd) (((int *)(fd))[-3])
> > #define FONT_EXTRA_WORDS 3
> >
> > To keep things simple, move all these macro definitions to ,
> > use four words instead of three, and initialize the fourth word in
> > newport_set_font() properly.
> >
> > Many thanks to Greg Kroah-Hartman , who
> > reviewed and improved this series!
> >
> > [1]: KASAN: global-out-of-bounds Read in fbcon_get_font
> >
> > https://syzkaller.appspot.com/bug?id=08b8be45afea11888776f897895aef9ad1c3ecfd
> >
> > Peilin Ye (3):
> > fbdev, newport_con: Move FONT_EXTRA_WORDS macros into linux/font.h
> > Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts
> > fbcon: Fix global-out-of-bounds read in fbcon_get_font()
> >
> > drivers/video/console/newport_con.c | 7 +--
> > drivers/video/fbdev/core/fbcon.c| 12
> > drivers/video/fbdev/core/fbcon.h| 7 ---
> > drivers/video/fbdev/core/fbcon_rotate.c | 1 +
> > drivers/video/fbdev/core/tileblit.c | 1 +
> > include/linux/font.h| 13 +
> > lib/fonts/font_10x18.c | 9 -
> > lib/fonts/font_6x10.c | 9 +
> > lib/fonts/font_6x11.c | 9 -
> > lib/fonts/font_7x14.c | 9 -
> > lib/fonts/font_8x16.c | 9 -
> > lib/fonts/font_8x8.c| 9 -
> > lib/fonts/font_acorn_8x8.c | 9 ++---
> > lib/fonts/font_mini_4x6.c | 8
> > lib/fonts
Re: [PATCH 2/2] drm/atomic: debug output for EBUSY
On Wed, 23 Sep 2020 12:57:37 +0200
Daniel Vetter wrote:
> Hopefully we'll have the drm crash recorder RSN, but meanwhile
> compositors would like to know a bit better why they get an EBUSY.
>
These debug messages will be especially useful with the flight
recorder, but also without. :-)
...
> ---
> drivers/gpu/drm/drm_atomic.c| 4 ++--
> drivers/gpu/drm/drm_atomic_helper.c | 20 +---
> 2 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index e22669b64521..6864e520269d 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1272,7 +1272,7 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
>
> DRM_DEBUG_ATOMIC("checking %p\n", state);
>
> - for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> requested_crtc |= drm_crtc_mask(crtc);
>
> for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> new_plane_state, i) {
> @@ -1322,7 +1322,7 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> }
> }
>
> - for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> affected_crtc |= drm_crtc_mask(crtc);
Oops, these belong in the previous patch?
>
> /*
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index e8ab7fd1..6b3bfabac26c 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1740,8 +1740,11 @@ int drm_atomic_helper_async_check(struct drm_device
> *dev,
>* overridden by a previous synchronous update's state.
>*/
> if (old_plane_state->commit &&
> - !try_wait_for_completion(&old_plane_state->commit->hw_done))
> + !try_wait_for_completion(&old_plane_state->commit->hw_done)) {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] inflight previous commit
> preventing async commit\n",
> + plane->base.id, plane->name);
> return -EBUSY;
> + }
>
> return funcs->atomic_async_check(plane, new_plane_state);
> }
> @@ -1964,6 +1967,9 @@ static int stall_checks(struct drm_crtc *crtc, bool
> nonblock)
>* commit with nonblocking ones. */
> if (!completed && nonblock) {
> spin_unlock(&crtc->commit_lock);
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] busy with a
> previous commit\n",
> + crtc->base.id, crtc->name);
> +
> return -EBUSY;
> }
> } else if (i == 1) {
> @@ -2132,8 +2138,12 @@ int drm_atomic_helper_setup_commit(struct
> drm_atomic_state *state,
> /* Userspace is not allowed to get ahead of the previous
>* commit with nonblocking ones. */
> if (nonblock && old_conn_state->commit &&
> -
> !try_wait_for_completion(&old_conn_state->commit->flip_done))
> +
> !try_wait_for_completion(&old_conn_state->commit->flip_done)) {
> + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] busy with a
> previous commit\n",
> + conn->base.id, conn->name);
> +
> return -EBUSY;
> + }
>
> /* Always track connectors explicitly for e.g. link retraining.
> */
> commit = crtc_or_fake_commit(state, new_conn_state->crtc ?:
> old_conn_state->crtc);
> @@ -2147,8 +2157,12 @@ int drm_atomic_helper_setup_commit(struct
> drm_atomic_state *state,
> /* Userspace is not allowed to get ahead of the previous
>* commit with nonblocking ones. */
> if (nonblock && old_plane_state->commit &&
> -
> !try_wait_for_completion(&old_plane_state->commit->flip_done))
> +
> !try_wait_for_completion(&old_plane_state->commit->flip_done)) {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] busy with a previous
> commit\n",
> + plane->base.id, plane->name);
> +
> return -EBUSY;
> + }
>
> /* Always track planes explicitly for async pageflip support. */
> commit = crtc_or_fake_commit(state, new_plane_state->crtc ?:
> old_plane_state->crtc);
The new debug messages sound good to me.
Thanks,
pq
pgpU8O3LAlXxk.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
On Wed, 23 Sep 2020 17:18:52 +0200
Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
>
> But in nonblocking mode userspace has then no idea this happened,
> which can lead to spurious EBUSY calls, both:
> - when that other CRTC is currently busy doing a page_flip the
> ALLOW_MODESET commit can fail with an EBUSY
> - on the other CRTC a normal atomic flip can fail with EBUSY because
> of the additional commit inserted by the kernel without userspace's
> knowledge
>
> For blocking commits this isn't a problem, because everyone else will
> just block until all the CRTC are reconfigured. Only thing userspace
> can notice is the dropped frames without any reason for why frames got
> dropped.
>
> Consensus is that we need new uapi to handle this properly, but no one
> has any idea what exactly the new uapi should look like. Since this
> has been shipping for years already compositors need to deal no matter
> what, so as a first step just try to enforce this across drivers
> better with some checks.
>
> v2: Add comments and a WARN_ON to enforce this only when allowed - we
> don't want to silently convert page flips into blocking plane updates
> just because the driver is buggy.
>
> v3: Fix inverted WARN_ON (Pekka).
>
> v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
> rules for drivers.
>
> v5: Make the WARNING more informative (Daniel)
>
> v6: Add unconditional debug output for compositor hackers to figure
> out what's going on when they get an EBUSY (Daniel)
... gmail workaround ...
> ---
> drivers/gpu/drm/drm_atomic.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 58527f151984..f1a912e80846 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
> * needed. It will also grab the relevant CRTC lock to make sure that the
> state
> * is consistent.
> *
> + * WARNING: Drivers may only add new CRTC states to a @state if
> + * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
> + * not created by userspace through an IOCTL call.
> + *
> * Returns:
> *
> * Either the allocated state or the error code encoded into the pointer.
> When
> @@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> struct drm_crtc_state *new_crtc_state;
> struct drm_connector *conn;
> struct drm_connector_state *conn_state;
> + unsigned requested_crtc = 0;
> + unsigned affected_crtc = 0;
> int i, ret = 0;
>
> DRM_DEBUG_ATOMIC("checking %p\n", state);
>
> + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + requested_crtc |= drm_crtc_mask(crtc);
Is "old crtc state" the state that userspace is requesting as the new
state?
> +
> for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> new_plane_state, i) {
> ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> if (ret) {
> @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> }
> }
>
> + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + affected_crtc |= drm_crtc_mask(crtc);
And after driver check processing, the "old crtc state" has been
modified by the driver to add anything it will necessarily need like
other CRTCs?
What is "new state" then?
> +
> + /*
> + * For commits that allow modesets drivers can add other CRTCs to the
> + * atomic commit, e.g. when they need to reallocate global resources.
> + * This can cause spurious EBUSY, which robs compositors of a very
> + * effective sanity check for their drawing loop. Therefor only allow
> + * drivers to add unrelated CRTC states for modeset commits.
> + *
> + * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
> + * so compositors know what's going on.
> + */
> + if (affected_crtc != requested_crtc) {
> + DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x,
> affected 0x%0x\n",
> + requested_crtc, affected_crtc);
> + WARN(!state->allow_modeset, "adding CRTC not allowed without
> modesets: requested 0x%x, affected 0x%0x\n",
> + requested_crtc, affected_crtc);
> + }
This hunk looks good to me.
Thanks,
pq
> +
> return 0;
> }
> EXPORT_SYMBOL(drm_atomic_check_only);
pgpUxN89mxQgH.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm: commit_work scheduling
On Thu, Sep 24, 2020 at 05:15:00PM +0100, Qais Yousef wrote: > On 09/24/20 10:49, Daniel Vetter wrote: > > [...] > > > > > I also thought kernel threads can be distinguished from others, so > > > > userspace shouldn't be able to sneak in and get elevated by accident. > > > > > > I guess maybe you could look at the parent? I still would like to > > > think that we could come up with something a bit less shaking than > > > matching thread names by regexp.. > > > > ps marks up kernel threads with [], so there is a way. But I haven't > > looked at what it is exactly that tells kernel threads apart from others. > > > > But aside from that sounds like "match right kernel thread with regex and > > set its scheduler class" is how this is currently done, if I'm > > understanding what Tejun and Peter said correctly. > > > > Not pretty, but also *shrug* ... > > Isn't there a real danger that a sneaky application names its threads to match > this regex and get a free promotion to RT without having the capability to do > so? A sneaky application can't fake being a kernel thread, at least that's what I thought. You need to check for that _and_ that the name matches. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
On Fri, Sep 25, 2020 at 10:16 AM Daniel Vetter wrote: > > On Fri, Sep 25, 2020 at 9:39 AM Christian König > wrote: > > > > Am 25.09.20 um 01:14 schrieb Dave Airlie: > > > On Thu, 24 Sep 2020 at 22:42, Christian König > > > wrote: > > >> Am 24.09.20 um 07:18 schrieb Dave Airlie: > > >>> From: Dave Airlie > > >>> > > >>> All the accel moves do the same pattern here, provide a helper > > >> And exactly that pattern I want to get away from. > > > Currently this is just refactoring out the helper code in each driver, > > > but I see > > > since it calls bo_mem_space we are probably moving a bit in the wrong > > > direction. > > > > Exactly that's why I'm noting this. > > > > > > > >> See what happens if we (for example) have a VRAM -> SYSTEM move is the > > >> following: > > >> > > >> 1. TTM allocates a new ttm_resource object in the SYSTEM domain. > > >> 2. We call the driver to move from VRAM to SYSTEM. > > >> 3. Driver finds that it can't do this and calls TTM to allocate GTT. > > >> 4. Since we are maybe out of GTT TTM evicts a different BO from GTT to > > >> SYSTEM and call driver again. > > >> > > >> This is a horrible ping/pong between driver/TTM/driver/TTM/driver and we > > >> should stop that immediately. > > >> > > >> My suggestion is that we rewrite how drivers call the ttm_bo_validate() > > >> function so that we can guarantee that this never happens. > > >> > > >> What do you think? > > > I think that is likely the next step I'd like to take after this > > > refactor, it's a lot bigger, and I'm not sure how it will look yet. > > > > Agree, yes. I have some ideas in mind for that, but not fully baked either. > > > > > Do we envision the driver calling validate in a loop but when it can't > > > find space it tells the driver and the driver does eviction and > > > recalls validate? > > > > Not in a loop, but more like in a chain. > > > > My plan is something like this: > > Instead of having "normal" and "busy" placement we have a flag in the > > context if evictions are allowed or not. > > The call to ttm_bo_validate are then replaced with two calls, first > > without evictions and if that didn't worked one with evictions. > > > > Then the normal validate sequence should look like this: > > 1. If a BO is in the SYSTEM (or SWAP domain) we validate it to GTT first > > with evictions=true. > > 2. If a BO should be in VRAM we then validate it to VRAM. If evictions > > are only allowed if the GEM flags say that GTT is not desired. > > That solves the trouble when you move a bo into vram as part of > validate. But I'm not seeing how this solves the "need gtt mapping to > move something out of vram" problem. > > Or should we instead move the entire eviction logic out from ttm into > drivers, building it up from helpers? Then drivers which need gtt for > moving stuff out of vram can do that right away. Also, this would > allow us to implement very fancy eviction algorithms like all the > nonsense we're doing in i915 for gtt handling on gen2/3 (but I really > hope that never ever becomes a thing again in future gpus, so this is > maybe more a what-if kind of thing). Not sure how that would look > like, maybe a special validate function which takes a ttm_resource the > driver already found (through evicting stuff or whatever) and then ttm > just does the move and book-keeping and everything. And drivers would > at first only call validate without allowing any eviction. Ofc anyone > without special needs could use the standard eviction function that > validate already has. Spinning this a bit more, we could have different default eviction functions with this, e.g. so all the drivers that need gtt mapping for moving stuff around can share that code, but with specific&flat control flow instead of lots of ping-ping. And drivers that don't need gtt mapping (like i915, we just need dma_map_sg which we assume works always, or something from the ttm dma page pool, which really always works) can then use something simpler that's completely flat. -Daniel > > > For special BOs, like amdgpus GDS, GWS and OA domain or VMWGFX special > > domains that will obviously look a bit different. > > > > Christian. > > > > > > > > Dave. > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
On Fri, Sep 25, 2020 at 9:39 AM Christian König wrote: > > Am 25.09.20 um 01:14 schrieb Dave Airlie: > > On Thu, 24 Sep 2020 at 22:42, Christian König > > wrote: > >> Am 24.09.20 um 07:18 schrieb Dave Airlie: > >>> From: Dave Airlie > >>> > >>> All the accel moves do the same pattern here, provide a helper > >> And exactly that pattern I want to get away from. > > Currently this is just refactoring out the helper code in each driver, but > > I see > > since it calls bo_mem_space we are probably moving a bit in the wrong > > direction. > > Exactly that's why I'm noting this. > > > > >> See what happens if we (for example) have a VRAM -> SYSTEM move is the > >> following: > >> > >> 1. TTM allocates a new ttm_resource object in the SYSTEM domain. > >> 2. We call the driver to move from VRAM to SYSTEM. > >> 3. Driver finds that it can't do this and calls TTM to allocate GTT. > >> 4. Since we are maybe out of GTT TTM evicts a different BO from GTT to > >> SYSTEM and call driver again. > >> > >> This is a horrible ping/pong between driver/TTM/driver/TTM/driver and we > >> should stop that immediately. > >> > >> My suggestion is that we rewrite how drivers call the ttm_bo_validate() > >> function so that we can guarantee that this never happens. > >> > >> What do you think? > > I think that is likely the next step I'd like to take after this > > refactor, it's a lot bigger, and I'm not sure how it will look yet. > > Agree, yes. I have some ideas in mind for that, but not fully baked either. > > > Do we envision the driver calling validate in a loop but when it can't > > find space it tells the driver and the driver does eviction and > > recalls validate? > > Not in a loop, but more like in a chain. > > My plan is something like this: > Instead of having "normal" and "busy" placement we have a flag in the > context if evictions are allowed or not. > The call to ttm_bo_validate are then replaced with two calls, first > without evictions and if that didn't worked one with evictions. > > Then the normal validate sequence should look like this: > 1. If a BO is in the SYSTEM (or SWAP domain) we validate it to GTT first > with evictions=true. > 2. If a BO should be in VRAM we then validate it to VRAM. If evictions > are only allowed if the GEM flags say that GTT is not desired. That solves the trouble when you move a bo into vram as part of validate. But I'm not seeing how this solves the "need gtt mapping to move something out of vram" problem. Or should we instead move the entire eviction logic out from ttm into drivers, building it up from helpers? Then drivers which need gtt for moving stuff out of vram can do that right away. Also, this would allow us to implement very fancy eviction algorithms like all the nonsense we're doing in i915 for gtt handling on gen2/3 (but I really hope that never ever becomes a thing again in future gpus, so this is maybe more a what-if kind of thing). Not sure how that would look like, maybe a special validate function which takes a ttm_resource the driver already found (through evicting stuff or whatever) and then ttm just does the move and book-keeping and everything. And drivers would at first only call validate without allowing any eviction. Ofc anyone without special needs could use the standard eviction function that validate already has. -Daniel > For special BOs, like amdgpus GDS, GWS and OA domain or VMWGFX special > domains that will obviously look a bit different. > > Christian. > > > > > Dave. > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm/omap: use degamma property for gamma table
On Wed, 23 Sep 2020 14:57:24 +0300
Tomi Valkeinen wrote:
> omapdrm supports gamma via GAMMA_LUT property. However, the HW we have
> is:
>
> gamma -> ctm -> out
>
> instead of what the model DRM framework uses:
>
> ctm -> gamma -> out
>
> As the following patches add CTM support for omapdrm, lets first fix the
> gamma.
>
> This patch changes the property from GAMMA_LUT to DEGAMMA_LUT, and uses
> drm_atomic_helper_legacy_degamma_set for gamma_set helper. Thus we will
> have:
>
> degamma -> ctm -> out
>
> and the legacy ioctl will continue working as before.
>
Makes sense to me:
Reviewed-by: Pekka Paalanen
Thanks,
pq
> ---
> drivers/gpu/drm/omapdrm/omap_crtc.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 328a4a74f534..6116af920660 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -573,8 +573,8 @@ static int omap_crtc_atomic_check(struct drm_crtc *crtc,
> {
> struct drm_plane_state *pri_state;
>
> - if (state->color_mgmt_changed && state->gamma_lut) {
> - unsigned int length = state->gamma_lut->length /
> + if (state->color_mgmt_changed && state->degamma_lut) {
> + unsigned int length = state->degamma_lut->length /
> sizeof(struct drm_color_lut);
>
> if (length < 2)
> @@ -614,10 +614,10 @@ static void omap_crtc_atomic_flush(struct drm_crtc
> *crtc,
> struct drm_color_lut *lut = NULL;
> unsigned int length = 0;
>
> - if (crtc->state->gamma_lut) {
> + if (crtc->state->degamma_lut) {
> lut = (struct drm_color_lut *)
> - crtc->state->gamma_lut->data;
> - length = crtc->state->gamma_lut->length /
> + crtc->state->degamma_lut->data;
> + length = crtc->state->degamma_lut->length /
> sizeof(*lut);
> }
> priv->dispc_ops->mgr_set_gamma(priv->dispc, omap_crtc->channel,
> @@ -738,7 +738,7 @@ static const struct drm_crtc_funcs omap_crtc_funcs = {
> .set_config = drm_atomic_helper_set_config,
> .destroy = omap_crtc_destroy,
> .page_flip = drm_atomic_helper_page_flip,
> - .gamma_set = drm_atomic_helper_legacy_gamma_set,
> + .gamma_set = drm_atomic_helper_legacy_degamma_set,
> .atomic_duplicate_state = omap_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> .atomic_set_property = omap_crtc_atomic_set_property,
> @@ -839,7 +839,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> if (priv->dispc_ops->mgr_gamma_size(priv->dispc, channel)) {
> unsigned int gamma_lut_size = 256;
>
> - drm_crtc_enable_color_mgmt(crtc, 0, false, gamma_lut_size);
> + drm_crtc_enable_color_mgmt(crtc, gamma_lut_size, false, 0);
> drm_mode_crtc_set_gamma_size(crtc, gamma_lut_size);
> }
>
pgpE0fZzuj0Tf.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm: add legacy support for using degamma for gamma
On Wed, 23 Sep 2020 14:57:23 +0300
Tomi Valkeinen wrote:
> We currently have drm_atomic_helper_legacy_gamma_set() helper which can
> be used to handle legacy gamma-set ioctl.
> drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
> CTM and DEGAMMA_LUT. This works fine on HW where we have either:
>
> degamma -> ctm -> gamma -> out
>
> or
>
> ctm -> gamma -> out
>
> However, if the HW has gamma table before ctm, the atomic property
> should be DEGAMMA_LUT, and thus we have:
>
> degamma -> ctm -> out
>
> This is fine for userspace which sets gamma table using the properties,
> as the userspace can check for the existence of gamma & degamma, but the
> legacy gamma-set ioctl does not work.
>
> This patch adds a new helper, drm_atomic_helper_legacy_degamma_set(),
> which can be used instead of drm_atomic_helper_legacy_gamma_set() when
> the DEGAMMA_LUT is the underlying property that needs to be set.
>
This sounds and looks right to me fwiw, so
Reviewed-by: Pekka Paalanen
Thanks,
pq
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 81 ++---
> include/drm/drm_atomic_helper.h | 4 ++
> 2 files changed, 65 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9e1ad493e689..5ba359114df6 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3469,24 +3469,11 @@ int drm_atomic_helper_page_flip_target(struct
> drm_crtc *crtc,
> }
> EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
>
> -/**
> - * drm_atomic_helper_legacy_gamma_set - set the legacy gamma correction table
> - * @crtc: CRTC object
> - * @red: red correction table
> - * @green: green correction table
> - * @blue: green correction table
> - * @size: size of the tables
> - * @ctx: lock acquire context
> - *
> - * Implements support for legacy gamma correction table for drivers
> - * that support color management through the DEGAMMA_LUT/GAMMA_LUT
> - * properties. See drm_crtc_enable_color_mgmt() and the containing chapter
> for
> - * how the atomic color management and gamma tables work.
> - */
> -int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> -u16 *red, u16 *green, u16 *blue,
> -uint32_t size,
> -struct drm_modeset_acquire_ctx *ctx)
> +static int legacy_gamma_degamma_set(struct drm_crtc *crtc,
> + u16 *red, u16 *green, u16 *blue,
> + uint32_t size,
> + struct drm_modeset_acquire_ctx *ctx,
> + bool use_degamma)
> {
> struct drm_device *dev = crtc->dev;
> struct drm_atomic_state *state;
> @@ -3525,9 +3512,11 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
> *crtc,
> }
>
> /* Reset DEGAMMA_LUT and CTM properties. */
> - replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
> + replaced = drm_property_replace_blob(&crtc_state->degamma_lut,
> + use_degamma ? blob : NULL);
> replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
> - replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
> + replaced |= drm_property_replace_blob(&crtc_state->gamma_lut,
> + use_degamma ? NULL : blob);
> crtc_state->color_mgmt_changed |= replaced;
>
> ret = drm_atomic_commit(state);
> @@ -3537,8 +3526,60 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
> *crtc,
> drm_property_blob_put(blob);
> return ret;
> }
> +
> +/**
> + * drm_atomic_helper_legacy_gamma_set - set the legacy gamma correction
> table using gamma_lut
> + * @crtc: CRTC object
> + * @red: red correction table
> + * @green: green correction table
> + * @blue: green correction table
> + * @size: size of the tables
> + * @ctx: lock acquire context
> + *
> + * Implements support for legacy gamma correction table for drivers
> + * that support color management through the DEGAMMA_LUT/GAMMA_LUT
> + * properties. See drm_crtc_enable_color_mgmt() and the containing chapter
> for
> + * how the atomic color management and gamma tables work.
> + *
> + * This function uses GAMMA_LUT property for the gamma table. This function
> + * can be used when the driver exposes either only GAMMA_LUT or both
> GAMMA_LUT
> + * and DEGAMMA_LUT.
> + */
> +int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> +u16 *red, u16 *green, u16 *blue,
> +uint32_t size,
> +struct drm_modeset_acquire_ctx *ctx)
> +{
> + return legacy_gamma_degamma_set(crtc, red, green, blue, size, ctx,
> false);
> +}
> EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
>
> +/**
> + * drm_atomic_helpe
Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
Am 25.09.20 um 01:14 schrieb Dave Airlie: On Thu, 24 Sep 2020 at 22:42, Christian König wrote: Am 24.09.20 um 07:18 schrieb Dave Airlie: From: Dave Airlie All the accel moves do the same pattern here, provide a helper And exactly that pattern I want to get away from. Currently this is just refactoring out the helper code in each driver, but I see since it calls bo_mem_space we are probably moving a bit in the wrong direction. Exactly that's why I'm noting this. See what happens if we (for example) have a VRAM -> SYSTEM move is the following: 1. TTM allocates a new ttm_resource object in the SYSTEM domain. 2. We call the driver to move from VRAM to SYSTEM. 3. Driver finds that it can't do this and calls TTM to allocate GTT. 4. Since we are maybe out of GTT TTM evicts a different BO from GTT to SYSTEM and call driver again. This is a horrible ping/pong between driver/TTM/driver/TTM/driver and we should stop that immediately. My suggestion is that we rewrite how drivers call the ttm_bo_validate() function so that we can guarantee that this never happens. What do you think? I think that is likely the next step I'd like to take after this refactor, it's a lot bigger, and I'm not sure how it will look yet. Agree, yes. I have some ideas in mind for that, but not fully baked either. Do we envision the driver calling validate in a loop but when it can't find space it tells the driver and the driver does eviction and recalls validate? Not in a loop, but more like in a chain. My plan is something like this: Instead of having "normal" and "busy" placement we have a flag in the context if evictions are allowed or not. The call to ttm_bo_validate are then replaced with two calls, first without evictions and if that didn't worked one with evictions. Then the normal validate sequence should look like this: 1. If a BO is in the SYSTEM (or SWAP domain) we validate it to GTT first with evictions=true. 2. If a BO should be in VRAM we then validate it to VRAM. If evictions are only allowed if the GEM flags say that GTT is not desired. For special BOs, like amdgpus GDS, GWS and OA domain or VMWGFX special domains that will obviously look a bit different. Christian. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
