Re: [PATCH] drm/mediatek: Optimize functions which do not need to return
Bernard Zhao 於 2020年10月13日 週二 下午4:55寫道：
>
> Function mtk_hdmi_aud_set_input always return 0, no need to
> keep the return value. Functions mtk_hdmi_aud_enable_packet &
> mtk_hdmi_aud_on_off_hw_ncts are the same, these two functions
> just call next functions. Maybe it`s a bit better to just call
> the inner function.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 27 +++
> 1 file changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index a97725680d4e..f1d987df0550 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -870,19 +870,8 @@ static void mtk_hdmi_video_set_display_mode(struct
> mtk_hdmi *hdmi,
> mtk_hdmi_hw_msic_setting(hdmi, mode);
> }
>
> -static int mtk_hdmi_aud_enable_packet(struct mtk_hdmi *hdmi, bool enable)
> -{
> - mtk_hdmi_hw_send_aud_packet(hdmi, enable);
> - return 0;
> -}
>
> -static int mtk_hdmi_aud_on_off_hw_ncts(struct mtk_hdmi *hdmi, bool on)
> -{
> - mtk_hdmi_hw_ncts_enable(hdmi, on);
> - return 0;
> -}
> -
> -static int mtk_hdmi_aud_set_input(struct mtk_hdmi *hdmi)
> +static void mtk_hdmi_aud_set_input(struct mtk_hdmi *hdmi)
> {
> enum hdmi_aud_channel_type chan_type;
> u8 chan_count;
> @@ -912,8 +901,6 @@ static int mtk_hdmi_aud_set_input(struct mtk_hdmi *hdmi)
> chan_count = mtk_hdmi_aud_get_chnl_count(chan_type);
> mtk_hdmi_hw_aud_set_i2s_chan_num(hdmi, chan_type, chan_count);
> mtk_hdmi_hw_aud_set_input_type(hdmi, hdmi->aud_param.aud_input_type);
> -
> - return 0;
> }
>
> static int mtk_hdmi_aud_set_src(struct mtk_hdmi *hdmi,
> @@ -921,7 +908,7 @@ static int mtk_hdmi_aud_set_src(struct mtk_hdmi *hdmi,
> {
> unsigned int sample_rate = hdmi->aud_param.codec_params.sample_rate;
>
> - mtk_hdmi_aud_on_off_hw_ncts(hdmi, false);
> + mtk_hdmi_hw_ncts_enable(hdmi, false);
> mtk_hdmi_hw_aud_src_disable(hdmi);
> mtk_hdmi_clear_bits(hdmi, GRL_CFG2, CFG2_ACLK_INV);
>
> @@ -959,7 +946,7 @@ static int mtk_hdmi_aud_output_config(struct mtk_hdmi
> *hdmi,
> struct drm_display_mode *display_mode)
> {
> mtk_hdmi_hw_aud_mute(hdmi);
> - mtk_hdmi_aud_enable_packet(hdmi, false);
> + mtk_hdmi_hw_send_aud_packet(hdmi, false);
>
> mtk_hdmi_aud_set_input(hdmi);
> mtk_hdmi_aud_set_src(hdmi, display_mode);
> @@ -968,8 +955,8 @@ static int mtk_hdmi_aud_output_config(struct mtk_hdmi
> *hdmi,
>
> usleep_range(50, 100);
>
> - mtk_hdmi_aud_on_off_hw_ncts(hdmi, true);
> - mtk_hdmi_aud_enable_packet(hdmi, true);
> + mtk_hdmi_hw_ncts_enable(hdmi, true);
> + mtk_hdmi_hw_send_aud_packet(hdmi, true);
> mtk_hdmi_hw_aud_unmute(hdmi);
> return 0;
> }
> @@ -1097,13 +1084,13 @@ static int mtk_hdmi_output_init(struct mtk_hdmi *hdmi)
>
> static void mtk_hdmi_audio_enable(struct mtk_hdmi *hdmi)
> {
> - mtk_hdmi_aud_enable_packet(hdmi, true);
> + mtk_hdmi_hw_send_aud_packet(hdmi, true);
> hdmi->audio_enable = true;
> }
>
> static void mtk_hdmi_audio_disable(struct mtk_hdmi *hdmi)
> {
> - mtk_hdmi_aud_enable_packet(hdmi, false);
> + mtk_hdmi_hw_send_aud_packet(hdmi, false);
> hdmi->audio_enable = false;
> }
>
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/7] 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: Daniel Mentz
Cc: Chris Goldsworthy
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
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/Makefile | 1 -
drivers/dma-buf/heaps/heap-helpers.c | 270 ---
drivers/dma-buf/heaps/heap-helpers.h | 53 --
3 files changed, 324 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 d0696cf937af..
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ /dev/null
@@ -1,270 +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(>lock);
- buffer->vmap_cnt = 0;
- buffer->vaddr = NULL;
- buffer->pagecount = 0;
- buffer->pages = NULL;
- INIT_LIST_HEAD(>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 = _helper_ops;
- exp_info.size = buffer->size;
- exp_info.flags = fd_flags;
- exp_info.priv = buffer;
-
- return dma_buf_export(_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(>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(>list);
-
- attachment->priv = a;
-
- mutex_lock(>lock);
- list_add(>list, >attachments);
- mutex_unlock(>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(>lock);
- list_del(>list);
- mutex_unlock(>lock);
-
- sg_free_table(>table);
- kfree(a);
-}
-
-static
-struct sg_table *dma_heap_map_dma_buf(struct
[PATCH v4 2/7] 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: Daniel Mentz
Cc: Chris Goldsworthy
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
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
v2:
* Fix unused return value and locking issue Reported-by:
kernel test robot
Julia Lawall
* Make cma_heap_buf_ops static suggested by
kernel test robot
* Fix uninitialized return in cma Reported-by:
kernel test robot
* Minor cleanups
v3:
* Use the new sgtable mapping functions, as Suggested-by:
Daniel Mentz
v4:
* Spelling fix suggested by BrianS
---
drivers/dma-buf/heaps/cma_heap.c | 317 ++-
1 file changed, 267 insertions(+), 50 deletions(-)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 626cf7fd033a..d6fab7cdeaf9 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(>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(>list);
+
+ attachment->priv = a;
+
+ mutex_lock(>lock);
+ list_add(>list, >attachments);
+ mutex_unlock(>lock);
+
+ return 0;
+}
+
+static void cma_heap_detach(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(>lock);
+ list_del(>list);
+ mutex_unlock(>lock);
+
+ sg_free_table(>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 = >table;
+ int ret;
+
+ ret = dma_map_sgtable(attachment->dev, table, direction, 0);
+ if (ret)
+ return 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_sgtable(attachment->dev, table, direction, 0);
+}
+
+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;
+
+ if
[PATCH v4 1/7] 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: Daniel Mentz
Cc: Chris Goldsworthy
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
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
v2:
* Fix locking issue and an unused return value Reported-by:
kernel test robot
Julia Lawall
* Make system_heap_buf_ops static Reported-by:
kernel test robot
v3:
* Use the new sgtable mapping functions, as Suggested-by:
Daniel Mentz
v4:
* Make sys_heap static (indirectly) Reported-by:
kernel test robot
* Spelling fix suggested by BrianS
---
drivers/dma-buf/heaps/system_heap.c | 344
1 file changed, 298 insertions(+), 46 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 0bf688e3c023..5c44f9c06807 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,321 @@
#include
#include
#include
-#include
-#include
+#include
+
+static struct dma_heap *sys_heap;
-#include "heap-helpers.h"
+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 *sys_heap;
+struct dma_heap_attachment {
+ struct device *dev;
+ struct sg_table *table;
+ struct list_head list;
+};
-static void system_heap_free(struct heap_helper_buffer *buffer)
+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->orig_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(>sg_table);
+ if (IS_ERR(table)) {
+ kfree(a);
+ return -ENOMEM;
+ }
+
+ a->table = table;
+ a->dev = attachment->dev;
+ INIT_LIST_HEAD(>list);
+
+ attachment->priv = a;
+
+ mutex_lock(>lock);
+ list_add(>list, >attachments);
+ mutex_unlock(>lock);
+
+ return 0;
+}
+
+static void system_heap_detach(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(>lock);
+ list_del(>list);
+ mutex_unlock(>lock);
+
+ sg_free_table(a->table);
+ kfree(a->table);
+ kfree(a);
+}
- for (pg = 0; pg < buffer->pagecount; pg++)
- __free_page(buffer->pages[pg]);
- kfree(buffer->pages);
+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;
+ int ret;
+
+ ret = dma_map_sgtable(attachment->dev, table, direction, 0);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return table;
+}
+
+static void
[PATCH v4 4/7] 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: Daniel Mentz
Cc: Chris Goldsworthy
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
Reviewed-by: Brian Starkey
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 d6fab7cdeaf9..d7f5d3d7a0c0 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(>list);
+ a->mapped = false;
attachment->priv = a;
@@ -102,6 +104,7 @@ static struct sg_table *cma_heap_map_dma_buf(struct
dma_buf_attachment *attachme
ret = dma_map_sgtable(attachment->dev, table, direction, 0);
if (ret)
return ERR_PTR(-ENOMEM);
+ a->mapped = true;
return table;
}
@@ -109,6 +112,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_sgtable(attachment->dev, table, direction, 0);
}
@@ -123,6 +129,8 @@ static int cma_heap_dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
mutex_lock(>lock);
list_for_each_entry(a, >attachments, list) {
+ if (!a->mapped)
+ continue;
dma_sync_sgtable_for_cpu(a->dev, >table, direction);
}
mutex_unlock(>lock);
@@ -141,6 +149,8 @@ static int cma_heap_dma_buf_end_cpu_access(struct dma_buf
*dmabuf,
mutex_lock(>lock);
list_for_each_entry(a, >attachments, list) {
+ if (!a->mapped)
+ continue;
dma_sync_sgtable_for_device(a->dev, >table, direction);
}
mutex_unlock(>lock);
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 5c44f9c06807..15b36bc862b1 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -37,6 +37,7 @@ struct dma_heap_attachment {
struct device *dev;
struct sg_table *table;
struct list_head list;
+ bool mapped;
};
static struct sg_table *dup_sg_table(struct sg_table *table)
@@ -84,6 +85,7 @@ static int system_heap_attach(struct dma_buf *dmabuf,
a->table = table;
[PATCH v4 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap
This adds a heap that allocates non-contiguous buffers that are
marked as writecombined, so they are not cached by the CPU.
This is useful, as most graphics buffers are usually not touched
by the CPU or only written into once by the CPU. So when mapping
the buffer over and over between devices, we can skip the CPU
syncing, which saves a lot of cache management overhead, greatly
improving performance.
For folk using ION, there was a ION_FLAG_CACHED flag, which
signaled if the returned buffer should be CPU cacheable or not.
With DMA-BUF heaps, we do not yet have such a flag, and by default
the current heaps (system and cma) produce CPU cachable buffers.
So for folks transitioning from ION to DMA-BUF Heaps, this fills
in some of that missing functionality.
There has been a suggestion to make this functionality a flag
(DMAHEAP_FLAG_UNCACHED?) on the system heap, similar to how
ION used the ION_FLAG_CACHED. But I want to make sure an
_UNCACHED flag would truely be a generic attribute across all
heaps. So far that has been unclear, so having it as a separate
heap seemes better for now. (But I'm open to discussion on this
point!)
This is a rework of earlier efforts to add a uncached system heap,
done utilizing the exisitng system heap, adding just a bit of
logic to handle the uncached case.
Feedback would be very welcome!
Many thanks to Liam Mark for his help to get this working.
Pending opensource users of this code include:
* AOSP HiKey960 gralloc:
- https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519
- Visibly improves performance over the system heap
* AOSP Codec2 (possibly, needs more review):
-
https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
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
---
v4:
* Make sys_uncached_heap static, as
Reported-by: kernel test robot
* Fix wrong return value, caught by smatch
Reported-by: kernel test robot
Reported-by: Dan Carpenter
* Ensure we call flush/invalidate_kernel_vmap_range() in the
uncached cases to try to address feedback about VIVT caches
from Christoph
* Reorder a few lines as suggested by BrianS
* Avoid holding the initial mapping for the lifetime of the buffer
as suggested by BrianS
* Fix a unlikely race between allocate and updating the dma_mask
that BrianS noticed.
---
drivers/dma-buf/heaps/system_heap.c | 111
1 file changed, 95 insertions(+), 16 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index ef4b2c1032df..a328c76249d2 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -22,6 +22,7 @@
#include
static struct dma_heap *sys_heap;
+static struct dma_heap *sys_uncached_heap;
struct system_heap_buffer {
struct dma_heap *heap;
@@ -31,6 +32,8 @@ struct system_heap_buffer {
struct sg_table sg_table;
int vmap_cnt;
void *vaddr;
+
+ bool uncached;
};
struct dma_heap_attachment {
@@ -38,6 +41,8 @@ struct dma_heap_attachment {
struct sg_table *table;
struct list_head list;
bool mapped;
+
+ bool uncached;
};
#define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
@@ -94,7 +99,7 @@ static int system_heap_attach(struct dma_buf *dmabuf,
a->dev = attachment->dev;
INIT_LIST_HEAD(>list);
a->mapped = false;
-
+ a->uncached = buffer->uncached;
attachment->priv = a;
mutex_lock(>lock);
@@ -124,9 +129,13 @@ static struct sg_table *system_heap_map_dma_buf(struct
dma_buf_attachment *attac
{
struct dma_heap_attachment *a = attachment->priv;
struct sg_table *table = a->table;
+ int attr = 0;
int ret;
- ret = dma_map_sgtable(attachment->dev, table, direction, 0);
+ if (a->uncached)
+ attr = DMA_ATTR_SKIP_CPU_SYNC;
+
+ ret = dma_map_sgtable(attachment->dev, table, direction, attr);
if (ret)
return ERR_PTR(ret);
@@ -139,9 +148,12 @@ static void system_heap_unmap_dma_buf(struct
dma_buf_attachment *attachment,
enum dma_data_direction direction)
{
struct dma_heap_attachment *a = attachment->priv;
+ int attr = 0;
+ if (a->uncached)
+ attr = DMA_ATTR_SKIP_CPU_SYNC;
a->mapped = false;
- dma_unmap_sgtable(attachment->dev, table, direction, 0);
+ dma_unmap_sgtable(attachment->dev, table, direction, attr);
}
static int system_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
@@ -155,10 +167,12 @@
[PATCH v4 6/7] dma-buf: dma-heap: Keep track of the heap device struct
Keep track of the heap device struct.
This will be useful for special DMA allocations
and actions.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
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/dma-heap.c | 33 +
include/linux/dma-heap.h | 9 +
2 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9dbdcf..72c746755d89 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -30,6 +30,7 @@
* @heap_devt heap device node
* @list list head connecting to list of heaps
* @heap_cdev heap char device
+ * @heap_dev heap device struct
*
* Represents a heap of memory from which buffers can be made.
*/
@@ -40,6 +41,7 @@ struct dma_heap {
dev_t heap_devt;
struct list_head list;
struct cdev heap_cdev;
+ struct device *heap_dev;
};
static LIST_HEAD(heap_list);
@@ -190,10 +192,21 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
return heap->priv;
}
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap)
+{
+ return heap->heap_dev;
+}
+
struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
{
struct dma_heap *heap, *h, *err_ret;
- struct device *dev_ret;
unsigned int minor;
int ret;
@@ -247,16 +260,20 @@ struct dma_heap *dma_heap_add(const struct
dma_heap_export_info *exp_info)
goto err1;
}
- dev_ret = device_create(dma_heap_class,
- NULL,
- heap->heap_devt,
- NULL,
- heap->name);
- if (IS_ERR(dev_ret)) {
+ heap->heap_dev = device_create(dma_heap_class,
+ NULL,
+ heap->heap_devt,
+ NULL,
+ heap->name);
+ if (IS_ERR(heap->heap_dev)) {
pr_err("dma_heap: Unable to create device\n");
- err_ret = ERR_CAST(dev_ret);
+ err_ret = ERR_CAST(heap->heap_dev);
goto err2;
}
+
+ /* Make sure it doesn't disappear on us */
+ heap->heap_dev = get_device(heap->heap_dev);
+
/* Add heap to the list */
mutex_lock(_list_lock);
list_add(>list, _list);
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 454e354d1ffb..82857e096910 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -50,6 +50,15 @@ struct dma_heap_export_info {
*/
void *dma_heap_get_drvdata(struct dma_heap *heap);
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap);
+
/**
* dma_heap_add - adds a heap to dmabuf heaps
* @exp_info: information needed to register this heap
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/7] 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: Daniel Mentz
Cc: Chris Goldsworthy
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
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
v3:
* Use page_size() rather then opencoding it
---
drivers/dma-buf/heaps/system_heap.c | 83 ++---
1 file changed, 65 insertions(+), 18 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 15b36bc862b1..ef4b2c1032df 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -40,6 +40,14 @@ struct dma_heap_attachment {
bool mapped;
};
+#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;
@@ -270,8 +278,11 @@ static void system_heap_dma_buf_release(struct dma_buf
*dmabuf)
int i;
table = >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);
}
@@ -289,6 +300,26 @@ static 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,
@@ -296,11 +327,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);
@@ -312,25 +345,35 @@ static int system_heap_allocate(struct dma_heap *heap,
buffer->heap = heap;
buffer->len = len;
- table = >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();
+ 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;
+ goto free_buffer;
+
+ list_add_tail(>lru, );
+ size_remaining -= page_size(page);
+ max_order = compound_order(page);
+ i++;
+ }
+
+ table = >sg_table;
+ if (sg_alloc_table(table, i, GFP_KERNEL))
+ goto free_buffer;
+
+ sg = table->sgl;
+ list_for_each_entry_safe(page, tmp_page, , lru) {
sg_set_page(sg, page, page_size(page), 0);
sg = sg_next(sg);
+ list_del(>lru);
}
/* create the dmabuf */
@@ -350,14
[PATCH v4 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
Hey All, So this is another revision of my patch series to performance optimizations to the dma-buf system heap. 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 an optimization that Ørjan Eide implemented for ION that avoids calling sync on attachments that don't have a mapping. Next, an optimization to use larger order pages for the system heap. This change brings us closer to the current performance of the ION allocation code (though there still is a gap due to ION using a mix of deferred-freeing and page pools, I'll be looking at integrating those eventually). Finally, a reworked version of my uncached system heap implementation I was submitting a few weeks back. Since it duplicated a lot of the now reworked system heap code, I realized it would be much simpler to add the functionality to the system_heap implementaiton itself. While not improving the core allocation performance, the uncached heap allocations do result in *much* improved performance on HiKey960 as it avoids a lot of flushing and invalidating buffers that the cpu doesn't touch often. Feedback on these would be great! thanks -john New in v4: * Make sys_heap static (indirectly) Reported-by: kernel test robot * Spelling fixes suggested by BrianS * Make sys_uncached_heap static, as Reported-by: kernel test robot * Fix wrong return value, caught by smatch Reported-by: kernel test robot Reported-by: Dan Carpenter * Ensure we call flush/invalidate_kernel_vmap_range() in the uncached cases to try to address feedback about VIVT caches from Christoph * Reorder a few lines as suggested by BrianS * Avoid holding the initial mapping for the lifetime of the buffer as suggested by BrianS * Fix a unlikely race between allocate and updating the dma_mask that BrianS noticed. Cc: Sumit Semwal Cc: Liam Mark Cc: Laura Abbott Cc: Brian Starkey Cc: Hridya Valsaraju Cc: Suren Baghdasaryan Cc: Sandeep Patil Cc: Daniel Mentz Cc: Chris Goldsworthy 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 (7): 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: heaps: Skip sync if not mapped dma-buf: system_heap: Allocate higher order pages if available dma-buf: dma-heap: Keep track of the heap device struct dma-buf: system_heap: Add a system-uncached heap re-using the system heap drivers/dma-buf/dma-heap.c | 33 +- drivers/dma-buf/heaps/Makefile | 1 - drivers/dma-buf/heaps/cma_heap.c | 327 +++--- drivers/dma-buf/heaps/heap-helpers.c | 270 --- drivers/dma-buf/heaps/heap-helpers.h | 53 --- drivers/dma-buf/heaps/system_heap.c | 488 --- include/linux/dma-heap.h | 9 + 7 files changed, 749 insertions(+), 432 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
RE: [PATCH v5 3/5] RDMA/uverbs: Add uverbs command for dma-buf based MR registration
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, October 16, 2020 5:18 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH v5 3/5] RDMA/uverbs: Add uverbs command for dma-buf based
> MR registration
>
> On Thu, Oct 15, 2020 at 03:02:55PM -0700, Jianxin Xiong wrote:
> > Implement a new uverbs ioctl method for memory registration with file
> > descriptor as an extra parameter.
> >
> > Signed-off-by: Jianxin Xiong
> > Reviewed-by: Sean Hefty
> > Acked-by: Michael J. Ruhl
> > Acked-by: Christian Koenig
> > Acked-by: Daniel Vetter
> > drivers/infiniband/core/uverbs_std_types_mr.c | 112
> > ++
> > include/uapi/rdma/ib_user_ioctl_cmds.h| 14
> > 2 files changed, 126 insertions(+)
> >
> > diff --git a/drivers/infiniband/core/uverbs_std_types_mr.c
> > b/drivers/infiniband/core/uverbs_std_types_mr.c
> > index 9b22bb5..e54459f 100644
> > +++ b/drivers/infiniband/core/uverbs_std_types_mr.c
> > @@ -1,5 +1,6 @@
> > /*
> > * Copyright (c) 2018, Mellanox Technologies inc. All rights reserved.
> > + * Copyright (c) 2020, Intel Corporation. All rights reserved.
> > *
> > * This software is available to you under a choice of one of two
> > * licenses. You may choose to be licensed under the terms of the
> > GNU @@ -178,6 +179,85 @@ static int UVERBS_HANDLER(UVERBS_METHOD_QUERY_MR)(
> > return IS_UVERBS_COPY_ERR(ret) ? ret : 0; }
> >
> > +static int UVERBS_HANDLER(UVERBS_METHOD_REG_DMABUF_MR)(
> > + struct uverbs_attr_bundle *attrs)
> > +{
> > + struct ib_uobject *uobj =
> > + uverbs_attr_get_uobject(attrs,
> > UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
> > + struct ib_pd *pd =
> > + uverbs_attr_get_obj(attrs, UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE);
> > + struct ib_device *ib_dev = pd->device;
> > +
> > + u64 start, length, virt_addr;
> > + u32 fd, access_flags;
> > + struct ib_mr *mr;
> > + int ret;
> > +
> > + if (!ib_dev->ops.reg_user_mr_dmabuf)
> > + return -EOPNOTSUPP;
> > +
> > + ret = uverbs_copy_from(, attrs,
> > + UVERBS_ATTR_REG_DMABUF_MR_ADDR);
>
> This should be called OFFSET uniformly here and in all the call chain below.
> Not start and not addr.
Right now it does mean the starting address, but that can be changed.
>
> > + if (ret)
> > + return ret;
> > +
> > + ret = uverbs_copy_from(, attrs,
> > + UVERBS_ATTR_REG_DMABUF_MR_LENGTH);
> > + if (ret)
> > + return ret;
> > +
> > + ret = uverbs_copy_from(_addr, attrs,
> > + UVERBS_ATTR_REG_DMABUF_MR_HCA_VA);
>
> I've been trying to call this IOVA
IOVA sounds good to me.
>
> Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v5 1/5] RDMA/umem: Support importing dma-buf as user memory region
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, October 16, 2020 5:28 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH v5 1/5] RDMA/umem: Support importing dma-buf as user
> memory region
>
> On Thu, Oct 15, 2020 at 03:02:45PM -0700, Jianxin Xiong wrote:
> > +struct ib_umem *ib_umem_dmabuf_get(struct ib_device *device,
> > + unsigned long addr, size_t size,
> > + int dmabuf_fd, int access,
> > + const struct ib_umem_dmabuf_ops *ops) {
> > + struct dma_buf *dmabuf;
> > + struct ib_umem_dmabuf *umem_dmabuf;
> > + struct ib_umem *umem;
> > + unsigned long end;
> > + long ret;
> > +
> > + if (check_add_overflow(addr, (unsigned long)size, ))
> > + return ERR_PTR(-EINVAL);
> > +
> > + if (unlikely(PAGE_ALIGN(end) < PAGE_SIZE))
> > + return ERR_PTR(-EINVAL);
> > +
> > + if (unlikely(!ops || !ops->invalidate || !ops->update))
> > + return ERR_PTR(-EINVAL);
> > +
> > + umem_dmabuf = kzalloc(sizeof(*umem_dmabuf), GFP_KERNEL);
> > + if (!umem_dmabuf)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + umem_dmabuf->ops = ops;
> > + INIT_WORK(_dmabuf->work, ib_umem_dmabuf_work);
> > +
> > + umem = _dmabuf->umem;
> > + umem->ibdev = device;
> > + umem->length = size;
> > + umem->address = addr;
>
> addr here is offset within the dma buf, but this code does nothing with it.
>
The current code assumes 0 offset, and 'addr' is the nominal starting address
of the
buffer. If this is to be changed to offset, then yes, some more handling is
needed
as you mentioned below.
> dma_buf_map_attachment gives a complete SGL for the entire DMA buf, but
> offset/length select a subset.
>
> You need to edit the sgls to make them properly span the sub-range and follow
> the peculiar rules for how SGLs in ib_umem's have to be
> constructed.
>
> Who validates that the total dma length of the SGL is exactly equal to
> length? That is really important too.
>
> Also, dma_buf_map_attachment() does not do the correct dma mapping for RDMA,
> eg it does not use ib_dma_map(). This is not a problem
> for mlx5 but it is troublesome to put in the core code.
ib_dma_map() uses dma_map_single(), GPU drivers use dma_map_resource() for
dma_buf_map_attachment(). They belong to the same family, but take different
address type (kernel address vs MMIO physical address). Could you elaborate what
the problem could be for non-mlx5 HCAs?
>
> Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap
On Fri, Oct 16, 2020 at 12:03 PM John Stultz wrote: > On Thu, Oct 8, 2020 at 4:51 AM Brian Starkey wrote: > > On Sat, Oct 03, 2020 at 04:02:57AM +, John Stultz wrote: > > > @@ -426,6 +487,16 @@ static int system_heap_create(void) > > > if (IS_ERR(sys_heap)) > > > return PTR_ERR(sys_heap); > > > > > > + exp_info.name = "system-uncached"; > > > + exp_info.ops = _uncached_heap_ops; > > > + exp_info.priv = NULL; > > > + > > > + sys_uncached_heap = dma_heap_add(_info); > > > + if (IS_ERR(sys_uncached_heap)) > > > + return PTR_ERR(sys_heap); > > > + > > > > In principle, there's a race here between the heap getting registered > > to sysfs and the dma_mask getting updated. > > > > I don't think it would cause a problem in practice, but with the API > > as it is, there's no way to avoid it - so I wonder if the > > dma_heap_get_dev() accessor isn't the right API design. > > Hrm. I guess to address your concern we would need split > dma_heap_add() into something like: > dma_heap_create() > dma_heap_add() > > Which breaks the creation of the heap with the registering it to the > subsystem, so some attributes can be tweaked inbetween? Looking at this some more, this approach isn't going to work. We create the device and then we call dma_coerce_mask_and_coherent() on it, but as soon as the device is created it seems possible for userland to directly access it. Again, though, as you mentioned this isn't terribly likely in practice. The best thing I can think of for now is to have the uncached heap's allocate pointer initially point to a dummy function that returns EBUSY and then after we update the dma mask then we can set it to the real alloc. I'll go with that for now, but let me know if you have other suggestions. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/8] drm/i915/dp: Program source OUI on eDP panels
On Wed, Sep 16, 2020 at 10:19 AM Lyude Paul wrote:
>
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will just read zeroes.
>
> We also take care not to reprogram the source OUI if it already matches
> what we expect. This is just to be careful so that we don't accidentally
> take the panel out of any backlight control modes we found it in.
>
> v2:
> * Add careful parameter to intel_edp_init_source_oui() to avoid
> re-writing the source OUI if it's already been set during driver
> initialization
>
> Signed-off-by: Lyude Paul
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
Hi Lyude,
Sorry for a late reply.
Whole series is:
Tested-by: Vasily Khoruzhick
Regards,
Vasily
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4bd10456ad188..7db2b6a3cd52e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3424,6 +3424,29 @@ void intel_dp_sink_set_decompression_state(struct
> intel_dp *intel_dp,
> enable ? "enable" : "disable");
> }
>
> +static void
> +intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 oui[] = { 0x00, 0xaa, 0x01 };
> + u8 buf[3] = { 0 };
> +
> + /*
> +* During driver init, we want to be careful and avoid changing the
> source OUI if it's
> +* already set to what we want, so as to avoid clearing any state by
> accident
> +*/
> + if (careful) {
> + if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf,
> sizeof(buf)) < 0)
> + drm_err(>drm, "Failed to read source OUI\n");
> +
> + if (memcmp(oui, buf, sizeof(oui)) == 0)
> + return;
> + }
> +
> + if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui,
> sizeof(oui)) < 0)
> + drm_err(>drm, "Failed to write source OUI\n");
> +}
> +
> /* If the sink supports it, try to set the power state appropriately */
> void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> {
> @@ -3443,6 +3466,10 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int
> mode)
> } else {
> struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
>
> + /* Write the source OUI as early as possible */
> + if (intel_dp_is_edp(intel_dp))
> + intel_edp_init_source_oui(intel_dp, false);
> +
> /*
> * When turning on, we need to retry for 1ms to give the sink
> * time to wake up.
> @@ -4607,6 +4634,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> intel_dp_get_dsc_sink_cap(intel_dp);
>
> + /*
> +* If needed, program our source OUI so we can make various
> Intel-specific AUX services
> +* available (such as HDR backlight controls)
> +*/
> + intel_edp_init_source_oui(intel_dp, true);
> +
> return true;
> }
>
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/bios/init: make two const arrays static, makes object smaller
From: Colin Ian King
Don't populate const arrays on the stack but instead make them
static. Makes the object code smaller by 7 bytes.
Before:
textdata bss dec hex filename
1040418284 0 112325 1b6c5 drm/nouveau/nvkm/subdev/bios/init.o
After:
textdata bss dec hex filename
1038748444 0 112318 1b6be drm/nouveau/nvkm/subdev/bios/init.o
(gcc version 10.2.0)
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index 9de74f41dcd2..dc8625eff20a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -546,9 +546,9 @@ init_tmds_reg(struct nvbios_init *init, u8 tmds)
* CR58 for CR57 = 0 to index a table of offsets to the basic
* 0x6808b0 address, and then flip the offset by 8.
*/
- const int pramdac_offset[13] = {
+ static const int pramdac_offset[13] = {
0, 0, 0x8, 0, 0x2000, 0, 0, 0, 0x2008, 0, 0, 0, 0x2000 };
- const u32 pramdac_table[4] = {
+ static const u32 pramdac_table[4] = {
0x6808b0, 0x6808b8, 0x6828b0, 0x6828b8 };
if (tmds >= 0x80) {
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] dss:use devm_platform_ioremap_resource_byname
Hi Zhang Qilong
On Wed, Sep 16, 2020 at 07:13:53PM +0800, Qilong Zhang wrote:
> Use the devm_platform_ioremap_resource_byname() helper instead of
> calling platform_get_resource_byname() and devm_ioremap_resource()
> separately.
>
> Signed-off-by: Zhang Qilong
Thanks, applied to drm-misc-next. The patch will appear in -next in a
few weeks.
While applying I had to update a few things:
- checkpatch warning due to indent
- warning for unused variable
- subject, should start with "omapfb:" like other patches touching the
same driver.
I also got a warning because you name differs in your mail and your
s-o-b. "Zhang Qilong" is not the same as "Qilong Zhang".
It would be nice if you for next submission have the same name in both
places.
The patch itself was fine - nice simplifications.
Sam
> ---
> .../video/fbdev/omap2/omapfb/dss/hdmi4_core.c | 10 +
> .../video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 10 +
> .../video/fbdev/omap2/omapfb/dss/hdmi_phy.c | 10 +
> .../video/fbdev/omap2/omapfb/dss/hdmi_pll.c | 9 +---
> .../video/fbdev/omap2/omapfb/dss/video-pll.c | 21 +++
> 5 files changed, 7 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c
> b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c
> index 7ca1803bf161..726c190862d4 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c
> @@ -875,15 +875,7 @@ void hdmi4_audio_stop(struct hdmi_core_data *core,
> struct hdmi_wp_data *wp)
>
> int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data
> *core)
> {
> - struct resource *res;
> -
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core");
> - if (!res) {
> - DSSERR("can't get CORE mem resource\n");
> - return -EINVAL;
> - }
> -
> - core->base = devm_ioremap_resource(>dev, res);
> + core->base = devm_platform_ioremap_resource_byname(pdev, "core");
> if (IS_ERR(core->base)) {
> DSSERR("can't ioremap CORE\n");
> return PTR_ERR(core->base);
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
> b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
> index 2f6ff14a48d9..eda29d3032e1 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
> @@ -887,15 +887,7 @@ int hdmi5_audio_config(struct hdmi_core_data *core,
> struct hdmi_wp_data *wp,
>
> int hdmi5_core_init(struct platform_device *pdev, struct hdmi_core_data
> *core)
> {
> - struct resource *res;
> -
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core");
> - if (!res) {
> - DSSERR("can't get CORE IORESOURCE_MEM HDMI\n");
> - return -EINVAL;
> - }
> -
> - core->base = devm_ioremap_resource(>dev, res);
> + core->base = devm_platform_ioremap_resource_byname(pdev, "core");
> if (IS_ERR(core->base)) {
> DSSERR("can't ioremap HDMI core\n");
> return PTR_ERR(core->base);
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
> b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
> index 9c645adba9e2..6fbfeb01b315 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
> @@ -207,19 +207,11 @@ static const struct hdmi_phy_features
> *hdmi_phy_get_features(void)
>
> int hdmi_phy_init(struct platform_device *pdev, struct hdmi_phy_data *phy)
> {
> - struct resource *res;
> -
> phy_feat = hdmi_phy_get_features();
> if (!phy_feat)
> return -ENODEV;
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy");
> - if (!res) {
> - DSSERR("can't get PHY mem resource\n");
> - return -EINVAL;
> - }
> -
> - phy->base = devm_ioremap_resource(>dev, res);
> + phy->base = devm_platform_ioremap_resource_byname(pdev, "phy");
> if (IS_ERR(phy->base)) {
> DSSERR("can't ioremap TX PHY\n");
> return PTR_ERR(phy->base);
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
> b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
> index 4991be031b0b..eb984dfe 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
> @@ -220,17 +220,10 @@ int hdmi_pll_init(struct platform_device *pdev, struct
> hdmi_pll_data *pll,
> struct hdmi_wp_data *wp)
> {
> int r;
> - struct resource *res;
>
> pll->wp = wp;
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pll");
> - if (!res) {
> - DSSERR("can't get PLL mem resource\n");
> - return -EINVAL;
> - }
> -
> - pll->base = devm_ioremap_resource(>dev, res);
> + pll->base = devm_platform_ioremap_resource_byname(pdev, "pll");
> if
Re: [PATCH -next] fbdev: nvidia: use for_each_child_of_node() macro
Hi Qinglang Miao
On Wed, Sep 16, 2020 at 02:21:23PM +0800, Qinglang Miao wrote:
> Use for_each_child_of_node() macro instead of open coding it.
>
> Signed-off-by: Qinglang Miao
Applied to drm-misc-next.
Sam
> ---
> drivers/video/fbdev/nvidia/nv_of.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/nvidia/nv_of.c
> b/drivers/video/fbdev/nvidia/nv_of.c
> index 5f3e5179c..d20b8779b 100644
> --- a/drivers/video/fbdev/nvidia/nv_of.c
> +++ b/drivers/video/fbdev/nvidia/nv_of.c
> @@ -42,8 +42,7 @@ int nvidia_probe_of_connector(struct fb_info *info, int
> conn, u8 **out_edid)
> const char *pname;
> int len;
>
> - for (dp = NULL;
> - (dp = of_get_next_child(parent, dp)) != NULL;) {
> + for_each_child_of_node(parent, dp) {
> pname = of_get_property(dp, "name", NULL);
> if (!pname)
> continue;
> --
> 2.23.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 0/2] Add initial support for slimport anx7625
Hi Xin Ji On Fri, Sep 18, 2020 at 06:18:19PM +0800, Xin Ji wrote: > Hi all, > > The following series add support for the Slimport ANX7625 transmitter, a > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > device. Thanks for all the iterations on this series. Driver looks good and I have applied it to drm-misc-next. Expect it to appear in -next in a few weeks. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ast: Avoid to access BMC addressing when P2A is disabled
On Sat, Oct 17, 2020 at 07:01:38AM +1000, David Airlie wrote: > On Fri, Oct 16, 2020 at 6:03 PM KuoHsiang Chou > wrote: > > > > The patch is upstreamed > > 1. For RHEL7.x, because its native kernel is suggested to update > >from 3.10 to 4.9 on 2 ODM's platform. > > 2. For AST2600. > > 3. For ASTDP. > > 4. v1.11 > > Hi, > > I've cc'ed Thomas who is maintaining this upstream, but this patch in > it's current form isn't acceptable, Maybe Thomas can provide more > detailed info, but the basic rules are > > One patch should do one thing. > Patches should be bisectable so any issues can be tracked down easier. > Fixes should be separated from new code. > New features and chip support should be separate. I noticed the patch included drmP.h - which has been gone for a while. So on top of what Dave wrote it should build (and work) on the latest kernel. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] omapfb: panel-sony-acx565akm: simplify the return expression of acx565akm_connect()
Hi Qinglang Miao
On Mon, Sep 21, 2020 at 09:10:52PM +0800, Qinglang Miao wrote:
> Simplify the return expression.
>
> Signed-off-by: Qinglang Miao
Applied this and the following patch to drm-misc-next.
Note: I did not touch the drm/* patches, I expect someone else to pick
them up. As they are quite old maybe try to resend them.
Sam
> ---
> .../fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
> b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
> index 1293515e4..8d8b5ff7d 100644
> --- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
> +++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
> @@ -506,16 +506,11 @@ static int acx565akm_connect(struct omap_dss_device
> *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> struct omap_dss_device *in = ddata->in;
> - int r;
>
> if (omapdss_device_is_connected(dssdev))
> return 0;
>
> - r = in->ops.sdi->connect(in, dssdev);
> - if (r)
> - return r;
> -
> - return 0;
> + return in->ops.sdi->connect(in, dssdev);
> }
>
> static void acx565akm_disconnect(struct omap_dss_device *dssdev)
> --
> 2.23.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] omapfb: connector-hdmi: simplify the return expression of hdmic_connect
Hi Qinglang Miao
On Mon, Sep 21, 2020 at 09:10:51PM +0800, Qinglang Miao wrote:
> Simplify the return expression.
>
> Signed-off-by: Qinglang Miao
I dropped the changes to gpio-cs5535.c when I applied this patch to
drm-misc-next. It looks like an accident that it was included here.
Sam
> ---
> drivers/gpio/gpio-cs5535.c | 6 +-
> drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c | 7 +--
> 2 files changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpio/gpio-cs5535.c b/drivers/gpio/gpio-cs5535.c
> index 53b24e3ae..57b9ddffd 100644
> --- a/drivers/gpio/gpio-cs5535.c
> +++ b/drivers/gpio/gpio-cs5535.c
> @@ -345,12 +345,8 @@ static int cs5535_gpio_probe(struct platform_device
> *pdev)
> mask_orig, mask);
>
> /* finally, register with the generic GPIO API */
> - err = devm_gpiochip_add_data(>dev, _gpio_chip.chip,
> + return devm_gpiochip_add_data(>dev, _gpio_chip.chip,
>_gpio_chip);
> - if (err)
> - return err;
> -
> - return 0;
> }
>
> static struct platform_driver cs5535_gpio_driver = {
> diff --git a/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
> b/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
> index 49551afbd..670b9c6eb 100644
> --- a/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
> +++ b/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
> @@ -50,18 +50,13 @@ static int hdmic_connect(struct omap_dss_device *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> struct omap_dss_device *in = ddata->in;
> - int r;
>
> dev_dbg(ddata->dev, "connect\n");
>
> if (omapdss_device_is_connected(dssdev))
> return 0;
>
> - r = in->ops.hdmi->connect(in, dssdev);
> - if (r)
> - return r;
> -
> - return 0;
> + return in->ops.hdmi->connect(in, dssdev);
> }
>
> static void hdmic_disconnect(struct omap_dss_device *dssdev)
> --
> 2.23.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] omapfb: simplify the return expression of panel_dpi_connect
Hi Liu Shixin
On Mon, Sep 21, 2020 at 04:24:43PM +0800, Liu Shixin wrote:
> Simplify the return expression.
>
> Signed-off-by: Liu Shixin
Thanks.
Applied this and the following two patches to drm-misc-next.
They will appear in -next in a few weeks.
Sam
> ---
> drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
> b/drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
> index 37c9f5bfaefe..ff3d1e8e1e7b 100644
> --- a/drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
> @@ -37,16 +37,11 @@ static int panel_dpi_connect(struct omap_dss_device
> *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> struct omap_dss_device *in = ddata->in;
> - int r;
>
> if (omapdss_device_is_connected(dssdev))
> return 0;
>
> - r = in->ops.dpi->connect(in, dssdev);
> - if (r)
> - return r;
> -
> - return 0;
> + return in->ops.dpi->connect(in, dssdev);
> }
>
> static void panel_dpi_disconnect(struct omap_dss_device *dssdev)
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] omapfb: connector-analog-tv: simplify the return expression of tvc_connect()
On Mon, Sep 21, 2020 at 09:10:49PM +0800, Qinglang Miao wrote:
> Simplify the return expression.
>
> Signed-off-by: Qinglang Miao
Thanks, applied to drm-misc-next.
Sam
> ---
> .../fbdev/omap2/omapfb/displays/connector-analog-tv.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
> b/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
> index 63bd13ba4..a9fd732f8 100644
> --- a/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
> +++ b/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
> @@ -47,18 +47,13 @@ static int tvc_connect(struct omap_dss_device *dssdev)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> struct omap_dss_device *in = ddata->in;
> - int r;
>
> dev_dbg(ddata->dev, "connect\n");
>
> if (omapdss_device_is_connected(dssdev))
> return 0;
>
> - r = in->ops.atv->connect(in, dssdev);
> - if (r)
> - return r;
> -
> - return 0;
> + return in->ops.atv->connect(in, dssdev);
> }
>
> static void tvc_disconnect(struct omap_dss_device *dssdev)
> --
> 2.23.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/bridge: lvds-codec: Add support for regulator
Hi Biju, Laurent
On Tue, Sep 22, 2020 at 01:55:26PM +0300, Laurent Pinchart wrote:
> From: Biju Das
>
> Add the support for enabling optional regulator that may be used as VCC
> source.
>
> Signed-off-by: Biju Das
> Reviewed-by: Laurent Pinchart
> [Replaced 'error' variable with 'ret']
> [Renamed regulator from 'vcc' to 'power']
> Signed-off-by: Laurent Pinchart
Applied to drm-misc-next.
Biju, could you make a follow-up patch that introduces dev_err_probe()
where appropriate? I did not fix up the code but this was a good
candidate.
Sam
> ---
> Changes since v2:
>
> - Use the correct regulator name
> ---
> drivers/gpu/drm/bridge/lvds-codec.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> b/drivers/gpu/drm/bridge/lvds-codec.c
> index f19d9f7a5db2..f52ccffc1bd1 100644
> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> @@ -10,13 +10,16 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
>
> struct lvds_codec {
> + struct device *dev;
> struct drm_bridge bridge;
> struct drm_bridge *panel_bridge;
> + struct regulator *vcc;
> struct gpio_desc *powerdown_gpio;
> u32 connector_type;
> };
> @@ -38,6 +41,14 @@ static int lvds_codec_attach(struct drm_bridge *bridge,
> static void lvds_codec_enable(struct drm_bridge *bridge)
> {
> struct lvds_codec *lvds_codec = to_lvds_codec(bridge);
> + int ret;
> +
> + ret = regulator_enable(lvds_codec->vcc);
> + if (ret) {
> + dev_err(lvds_codec->dev,
> + "Failed to enable regulator \"vcc\": %d\n", ret);
> + return;
> + }
>
> if (lvds_codec->powerdown_gpio)
> gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
> @@ -46,9 +57,15 @@ static void lvds_codec_enable(struct drm_bridge *bridge)
> static void lvds_codec_disable(struct drm_bridge *bridge)
> {
> struct lvds_codec *lvds_codec = to_lvds_codec(bridge);
> + int ret;
>
> if (lvds_codec->powerdown_gpio)
> gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 1);
> +
> + ret = regulator_disable(lvds_codec->vcc);
> + if (ret)
> + dev_err(lvds_codec->dev,
> + "Failed to disable regulator \"vcc\": %d\n", ret);
> }
>
> static const struct drm_bridge_funcs funcs = {
> @@ -63,12 +80,24 @@ static int lvds_codec_probe(struct platform_device *pdev)
> struct device_node *panel_node;
> struct drm_panel *panel;
> struct lvds_codec *lvds_codec;
> + int ret;
>
> lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
> if (!lvds_codec)
> return -ENOMEM;
>
> + lvds_codec->dev = >dev;
> lvds_codec->connector_type = (uintptr_t)of_device_get_match_data(dev);
> +
> + lvds_codec->vcc = devm_regulator_get(lvds_codec->dev, "power");
> + if (IS_ERR(lvds_codec->vcc)) {
> + ret = PTR_ERR(lvds_codec->vcc);
> + if (ret != -EPROBE_DEFER)
> + dev_err(lvds_codec->dev,
> + "Unable to get \"vcc\" supply: %d\n", ret);
> + return ret;
> + }
> +
> lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
>GPIOD_OUT_HIGH);
> if (IS_ERR(lvds_codec->powerdown_gpio))
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ast: Avoid to access BMC addressing when P2A is disabled
On Fri, Oct 16, 2020 at 6:03 PM KuoHsiang Chou wrote: > > The patch is upstreamed > 1. For RHEL7.x, because its native kernel is suggested to update >from 3.10 to 4.9 on 2 ODM's platform. > 2. For AST2600. > 3. For ASTDP. > 4. v1.11 Hi, I've cc'ed Thomas who is maintaining this upstream, but this patch in it's current form isn't acceptable, Maybe Thomas can provide more detailed info, but the basic rules are One patch should do one thing. Patches should be bisectable so any issues can be tracked down easier. Fixes should be separated from new code. New features and chip support should be separate. https://www.kernel.org/doc/html/v5.9/process/submitting-patches.html Please maybe work with Thomas on having a better upstream development process for ast chipsets. Thanks, Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: use kobj_to_dev()
Hi Wang Qing
On Tue, Sep 22, 2020 at 08:14:24PM +0800, Wang Qing wrote:
> Use kobj_to_dev() instead of container_of()
>
> Signed-off-by: Wang Qing
Thanks, applied to drm-misc-next. Patch will appear in -next in a few
weeks.
Sam
> ---
> drivers/video/fbdev/aty/radeon_base.c | 4 ++--
> drivers/video/fbdev/udlfb.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/aty/radeon_base.c
> b/drivers/video/fbdev/aty/radeon_base.c
> index 3fe509c..878c39a
> --- a/drivers/video/fbdev/aty/radeon_base.c
> +++ b/drivers/video/fbdev/aty/radeon_base.c
> @@ -2200,7 +2200,7 @@ static ssize_t radeon_show_edid1(struct file *filp,
> struct kobject *kobj,
>struct bin_attribute *bin_attr,
>char *buf, loff_t off, size_t count)
> {
> - struct device *dev = container_of(kobj, struct device, kobj);
> + struct device *dev = kobj_to_dev(kobj);
> struct fb_info *info = dev_get_drvdata(dev);
> struct radeonfb_info *rinfo = info->par;
>
> @@ -2212,7 +2212,7 @@ static ssize_t radeon_show_edid2(struct file *filp,
> struct kobject *kobj,
>struct bin_attribute *bin_attr,
>char *buf, loff_t off, size_t count)
> {
> - struct device *dev = container_of(kobj, struct device, kobj);
> + struct device *dev = kobj_to_dev(kobj);
> struct fb_info *info = dev_get_drvdata(dev);
> struct radeonfb_info *rinfo = info->par;
>
> diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
> index 5b014b4..f9b3c1c
> --- a/drivers/video/fbdev/udlfb.c
> +++ b/drivers/video/fbdev/udlfb.c
> @@ -1457,7 +1457,7 @@ static ssize_t edid_show(
> struct file *filp,
> struct kobject *kobj, struct bin_attribute *a,
>char *buf, loff_t off, size_t count) {
> - struct device *fbdev = container_of(kobj, struct device, kobj);
> + struct device *fbdev = kobj_to_dev(kobj);
> struct fb_info *fb_info = dev_get_drvdata(fbdev);
> struct dlfb_data *dlfb = fb_info->par;
>
> @@ -1479,7 +1479,7 @@ static ssize_t edid_store(
> struct file *filp,
> struct kobject *kobj, struct bin_attribute *a,
> char *src, loff_t src_off, size_t src_size) {
> - struct device *fbdev = container_of(kobj, struct device, kobj);
> + struct device *fbdev = kobj_to_dev(kobj);
> struct fb_info *fb_info = dev_get_drvdata(fbdev);
> struct dlfb_data *dlfb = fb_info->par;
> int ret;
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] video: Remove set but not used variable
Hi Li Heng
On Thu, Sep 24, 2020 at 10:18:26PM +0800, Li Heng wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/video/fbdev/sis/300vtbl.h:1064:28: warning:
> ‘SiS300_CHTVVCLKSONTSC’ defined but not used [-Wunused-const-variable=]
>
> Reported-by: Hulk Robot
> Signed-off-by: Li Heng
Thanks, now applied to drm-misc-next.
Sam
> ---
> drivers/video/fbdev/sis/300vtbl.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/sis/300vtbl.h
> b/drivers/video/fbdev/sis/300vtbl.h
> index e4b4a26..26b19f7 100644
> --- a/drivers/video/fbdev/sis/300vtbl.h
> +++ b/drivers/video/fbdev/sis/300vtbl.h
> @@ -1061,8 +1061,6 @@ static const unsigned char SiS300_CHTVVCLKUNTSC[] = {
> 0x29,0x29,0x29,0x29,0x2a,
>
> static const unsigned char SiS300_CHTVVCLKONTSC[] = {
> 0x2c,0x2c,0x2c,0x2c,0x2d,0x2b };
>
> -static const unsigned char SiS300_CHTVVCLKSONTSC[] = {
> 0x2c,0x2c,0x2c,0x2c,0x2d,0x2b };
> -
> static const unsigned char SiS300_CHTVVCLKUPAL[] = {
> 0x2f,0x2f,0x2f,0x2f,0x2f,0x31 };
>
> static const unsigned char SiS300_CHTVVCLKOPAL[] = {
> 0x2f,0x2f,0x2f,0x2f,0x30,0x32 };
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: rm68200: fix mode to 50fps
Hi Yannick
On Fri, Sep 25, 2020 at 04:16:18PM +0200, Yannick Fertre wrote:
> Compute new timings to get a framerate of 50fps with a pixel clock
> @54Mhz.
>
> Signed-off-by: Yannick Fertre
Thanks, applied to drm-misc-next.
Sorry for taking so long time.
Sam
> ---
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v5 4/5] RDMA/mlx5: Support dma-buf based userspace memory region
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, October 16, 2020 11:58 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH v5 4/5] RDMA/mlx5: Support dma-buf based userspace memory
> region
>
> On Fri, Oct 16, 2020 at 06:40:01AM +, Xiong, Jianxin wrote:
> > > > + if (!mr)
> > > > + return -EINVAL;
> > > > +
> > > > + return mlx5_ib_update_xlt(mr, 0, mr->npages, PAGE_SHIFT, flags);
> > > > +}
> > > > +
> > > > +static struct ib_umem_dmabuf_ops mlx5_ib_umem_dmabuf_ops = {
> > > > + .init = mlx5_ib_umem_dmabuf_xlt_init,
> > > > + .update = mlx5_ib_umem_dmabuf_xlt_update,
> > > > + .invalidate = mlx5_ib_umem_dmabuf_xlt_invalidate,
> > > > +};
> > >
> > > I'm not really convinced these should be ops, this is usually a bad
> > > design pattern.
> > >
> > > Why do I need so much code to extract the sgl from the dma_buf? I
> > > would prefer the dma_buf layer simplify this, not by adding a wrapper
> > > around it in the IB core code...
> > >
> >
> > We just need a way to call a device specific function to update the
> > NIC's translation table. I considered three ways: (1) ops registered
> > with ib_umem_get_dmabuf;
> > (2) a single function pointer registered with ib_umem_get_dmabuf; (3)
> > a method in 'struct ib_device'. Option (1) was chosen here with no
> > strong reason. We could consolidate the three functions of the ops into
> > one, but then we will need to
> > define commands or flags for different update operations.
>
> I'd rather the driver directly provide the dma_buf ops.. Inserting layers
> that do nothing be call other layers is usually a bad idea. I didn't look
> carefully yet at how that would be arranged.
I can work along that direction. One change I can see is that the umem_dmabuf
structure
will need to be exposed to the device driver (currently it's private to the
core).
>
> > > > + ncont = npages;
> > > > + order = ilog2(roundup_pow_of_two(ncont));
> > >
> > > We still need to deal with contiguity here, this ncont/npages is just
> > > obfuscation.
> >
> > Since the pages can move, we can't take advantage of contiguity here.
> > This handling is similar to the ODP case. The variables 'ncont' and
> > 'page_shift' here are not necessary.
> > They are kept just for the sake of signifying the semantics of the
> > following functions that use them.
>
> Well, in this case we can manage it, and the performance boost is high enough
> we need to. The work on mlx5 to do it is a bit inovlved
> though.
Maybe as a future enhancement?
>
> > > > + err = ib_umem_dmabuf_init_mapping(umem, mr);
> > > > + if (err) {
> > > > + dereg_mr(dev, mr);
> > > > + return ERR_PTR(err);
> > > > + }
> > >
> > > Did you test the page fault path at all? Looks like some xarray code
> > > is missing here, and this is also missing the related complex teardown
> > > logic.
> > >
> > > Does this mean you didn't test the pagefault_dmabuf_mr() at all?
> >
> > Thanks for the hint. I was unable to get the test runs reaching the
> > pagefault_dmabuf_mr() function. Now I have found the reason. Along the
> > path of all the page fault handlers, the array "odp_mkeys" is checked
> > against the mr key. Since the dmabuf mr keys are not in the list the
> > handler is never called.
> >
> > On the other hand, it seems that pagefault_dmabuf_mr() is not needed at all.
> > The pagefault is gracefully handled by retrying until the work thread
> > finished programming the NIC.
>
> This is a bug of some kind, pagefaults that can't find a mkey in the xarray
> should cause completion with error.
>
> Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
Please fix the checkpatch errors, you can run it locally by running "dim
checkpatch drm-tip/drm-tip..HEAD", search for instructions of how to fetch
and setup dim.
Also no need to CC drm-devel for patches that only touches i915, drm-devel is
for drivers that don't have it's own list and for changes in drm
subsystem that affects all other drm based drivers.
On Wed, 2020-10-14 at 20:29 +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP.
>
> BSpec: 21257
>
> Cc: Souza Jose
> Signed-off-by: Tejas Upadhyay
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 87 +++-
> 1 file changed, 85 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index bb0b9930958f..7ab694c6d8df 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
> ehl_combo_phy_ddi_translations_dp[] = {
> { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> };
>
>
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
> +
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr2[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
> +
> struct icl_mg_phy_ddi_buf_trans {
> u32 cri_txdeemph_override_11_6;
> u32 cri_txdeemph_override_5_0;
> @@ -1162,6 +1190,57 @@ ehl_get_combo_buf_trans(struct intel_encoder *encoder,
> return ehl_get_combo_buf_trans_dp(encoder, crtc_state,
> n_entries);
> }
>
>
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state,
> + int *n_entries)
> +{
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
> + return icl_combo_phy_ddi_translations_hdmi;
> +}
> +
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans_dp(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state,
> + int *n_entries)
> +{
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
> + return icl_combo_phy_ddi_translations_dp_hbr2;
> +}
> +
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans_edp(struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state,
> +int *n_entries)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + if (dev_priv->vbt.edp.low_vswing) {
> + if (crtc_state->port_clock > 27) {
> + *n_entries =
> ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr2);
> + return jsl_combo_phy_ddi_translations_edp_hbr2;
> + } else {
> + *n_entries =
> ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr);
> + return jsl_combo_phy_ddi_translations_edp_hbr;
> + }
> + }
> +
> + return jsl_get_combo_buf_trans_dp(encoder, crtc_state, n_entries);
> +}
> +
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans(struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state,
> +
RE: [PATCH v5 1/5] RDMA/umem: Support importing dma-buf as user memory region
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, October 16, 2020 12:00 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH v5 1/5] RDMA/umem: Support importing dma-buf as user
> memory region
>
> On Thu, Oct 15, 2020 at 03:02:45PM -0700, Jianxin Xiong wrote:
>
> > +static void ib_umem_dmabuf_invalidate_cb(struct dma_buf_attachment
> > +*attach) {
> > + struct ib_umem_dmabuf *umem_dmabuf = attach->importer_priv;
> > +
> > + dma_resv_assert_held(umem_dmabuf->attach->dmabuf->resv);
> > +
> > + ib_umem_dmabuf_unmap_pages(_dmabuf->umem, true);
> > + queue_work(ib_wq, _dmabuf->work);
>
> Do we really want to queue remapping or should it wait until there is a page
> fault?
Queuing remapping here has performance advantage because it reduces the chance
of getting the page fault.
>
> What do GPUs do?
>
> Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v5 2/2] drm/bridge: hx8837: add a Himax HX8837 display controller driver
Hi Lubomir.
On Sat, Sep 26, 2020 at 02:07:19AM +0200, Lubomir Rintel wrote:
> Himax HX8837 is used to drive the LCD panel on OLPC platforms.
>
> It controls the panel backlight and is able to refresh it when the LCD
> controller (and the rest of the plaform) is powered off.
>
> It also converts regular RGB color data from the LCDC so that it looks
> reasonable on the OLPC LCD panel with a monochromatic layer on top of a
> layer that can either reflect light (b/w sunlight readable mode) or light
> pattern of red, green and blue pixels.
>
> At this point, the driver is rather basic. The self-refresh mode is not
> supported. There's no way of independently controlling the color swizzling,
> antialiasing or b/w conversion, but it probably isn't too useful either.
>
> There's another driver for the same hardware on OLPC XO-1.5 and XO-1.75
> in drivers/staging/olpc_dcon. The display on that hardware doesn't utilize
> DRM, so this driver doesn't replace the other one yet.
>
> Signed-off-by: Lubomir Rintel
A little feedback follows.
Sam
>
> ---
> Changes since v3:
> - Added this patch, in place of a driver derived from
> drivers/staging/olpc_dcon. Compared to the previous one this
> implements the bare minimum, without the fancy stuff such as
> self-refresh that need more work/thinking.
>
> drivers/gpu/drm/bridge/Kconfig| 13 ++
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/himax-hx8837.c | 325 ++
> 3 files changed, 339 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/himax-hx8837.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index ef91646441b16..6a923dd56c1d5 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
> on ARM-based platforms. Saying Y here when this driver is not needed
> will not cause any issue.
>
> +config DRM_HIMAX_HX8837
> +tristate "HiMax HX8837 OLPC Display Controller"
> + depends on OF
> + depends on OLPC || ARCH_MMP || COMPILE_TEST
> + select DRM_KMS_HELPER
> +select BACKLIGHT_LCD_SUPPORT
> +select BACKLIGHT_CLASS_DEVICE
> +help
> + Enable support for HiMax HX8837 Display Controller as found in the
> + OLPC XO laptops.
> +
> + If your laptop doesn't have green ears, say "N"
There is a mixture of tabs and spaces for indent - use tabs only (and
tabs + 2 spaces for the help text).
> +
> config DRM_LONTIUM_LT9611
> tristate "Lontium LT9611 DSI/HDMI bridge"
> select SND_SOC_HDMI_CODEC if SND_SOC
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 2b3aff104e466..21f72df3260db 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -2,6 +2,7 @@
> obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
> obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
> +obj-$(CONFIG_DRM_HIMAX_HX8837) += himax-hx8837.o
Please add in alphabetical order.
> obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
> obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> megachips-stdp-ge-b850v3-fw.o
> diff --git a/drivers/gpu/drm/bridge/himax-hx8837.c
> b/drivers/gpu/drm/bridge/himax-hx8837.c
> new file mode 100644
> index 0..1e97fcb8ce505
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/himax-hx8837.c
> @@ -0,0 +1,325 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * HiMax HX8837 Display Controller Driver
> + *
> + * Datasheet: http://wiki.laptop.org/images/0/09/DCON_datasheet_HX8837-A.pdf
> + *
> + * Copyright (C) 2020 Lubomir Rintel
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
In blocks are good but please add them in alphabetical order.
> +
> +#define bridge_to_hx8837_priv(x) \
> + container_of(x, struct hx8837_priv, bridge)
> +
> +/* DCON registers */
> +enum {
> + DCON_REG_ID = 0x00,
> + DCON_REG_MODE = 0x01,
> + DCON_REG_HRES = 0x02,
> + DCON_REG_HTOTAL = 0x03,
> + DCON_REG_HSYNC_WIDTH= 0x04,
> + DCON_REG_VRES = 0x05,
> + DCON_REG_VTOTAL = 0x06,
> + DCON_REG_VSYNC_WIDTH= 0x07,
> + DCON_REG_TIMEOUT= 0x08,
> + DCON_REG_SCAN_INT = 0x09,
> + DCON_REG_BRIGHT = 0x0a,
> + DCON_REG_MEM_OPT_A = 0x41,
> + DCON_REG_MEM_OPT_B = 0x42,
> +};
> +
> +/* DCON_REG_MODE */
> +enum {
> + MODE_PASSTHRU = BIT(0),
> + MODE_SLEEP = BIT(1),
> + MODE_SLEEP_AUTO = BIT(2),
> + MODE_BL_ENABLE = BIT(3),
> + MODE_BLANK = BIT(4),
> + MODE_CSWIZZLE = BIT(5),
> + MODE_COL_AA = BIT(6),
> +
[Bug 209721] No output after AMDGPU loads.
https://bugzilla.kernel.org/show_bug.cgi?id=209721 --- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Haxk20 from comment #4) > That fixes it. Would be nice to see it in the next drm-fixes. Already queued up: https://patchwork.freedesktop.org/patch/395141/ -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209721] No output after AMDGPU loads.
https://bugzilla.kernel.org/show_bug.cgi?id=209721 --- Comment #5 from Haxk20 (haxk...@gmail.com) --- I will keep the bug opened until it is in linus tree -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209721] No output after AMDGPU loads.
https://bugzilla.kernel.org/show_bug.cgi?id=209721 --- Comment #4 from Haxk20 (haxk...@gmail.com) --- (In reply to Alex Deucher from comment #2) > Does this patch fix it? > https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5. > 10=44264591a8c4da7090a4bfd10e04f4cb8fe60afe That fixes it. Would be nice to see it in the next drm-fixes. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v7 0/6] Add Unisoc's drm kms module
Hi Kevin, > v7: > 1. Fix DTC unit name warnings > 2. Fix the problem of maintainers > 3. Call drmm_mode_config_init to mode config init > 4. Embed drm_device in sprd_drm and use devm_drm_dev_alloc > 5. Replace DRM_XXX with drm_xxx on KMS module, but not suitable for other > subsystems > 6. Remove plane_update stuff, dpu handles all the HW update in > crtc->atomic_flush > 7. Dsi Code structure adjustment, all move to "sprd/" I can see some of my feedback from last round of review is not addressed. There were makefile fixes and then I asked for a high-level intro. Can you please revisit last round of review feedback to check what was missed. Sam > > Kevin Tang (6): > dt-bindings: display: add Unisoc's drm master bindings > drm/sprd: add Unisoc's drm kms master > dt-bindings: display: add Unisoc's dpu bindings > drm/sprd: add Unisoc's drm display controller driver > dt-bindings: display: add Unisoc's mipi dsi bindings > drm/sprd: add Unisoc's drm mipi dsi driver > > .../display/sprd/sprd,display-subsystem.yaml | 39 + > .../bindings/display/sprd/sprd,sharkl3-dpu.yaml| 83 ++ > .../display/sprd/sprd,sharkl3-dsi-host.yaml| 98 ++ > .../display/sprd/sprd,sharkl3-dsi-phy.yaml | 75 + > drivers/gpu/drm/Kconfig|2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/sprd/Kconfig | 13 + > drivers/gpu/drm/sprd/Makefile | 12 + > drivers/gpu/drm/sprd/dpu_r2p0.c| 636 + > drivers/gpu/drm/sprd/dw_dsi_ctrl.c | 792 +++ > drivers/gpu/drm/sprd/dw_dsi_ctrl.h | 1475 > > drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c | 276 > drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h | 34 + > drivers/gpu/drm/sprd/megacores_pll.c | 315 + > drivers/gpu/drm/sprd/megacores_pll.h | 146 ++ > drivers/gpu/drm/sprd/sprd_dphy.c | 335 + > drivers/gpu/drm/sprd/sprd_dphy.h | 39 + > drivers/gpu/drm/sprd/sprd_dpu.c| 501 +++ > drivers/gpu/drm/sprd/sprd_dpu.h| 217 +++ > drivers/gpu/drm/sprd/sprd_drm.c| 263 > drivers/gpu/drm/sprd/sprd_drm.h| 20 + > drivers/gpu/drm/sprd/sprd_dsi.c| 1102 +++ > drivers/gpu/drm/sprd/sprd_dsi.h| 105 ++ > 23 files changed, 6579 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml > create mode 100644 > Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml > create mode 100644 > Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml > create mode 100644 > Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-phy.yaml > create mode 100644 drivers/gpu/drm/sprd/Kconfig > create mode 100644 drivers/gpu/drm/sprd/Makefile > create mode 100644 drivers/gpu/drm/sprd/dpu_r2p0.c > create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.c > create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.h > create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c > create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h > create mode 100644 drivers/gpu/drm/sprd/megacores_pll.c > create mode 100644 drivers/gpu/drm/sprd/megacores_pll.h > create mode 100644 drivers/gpu/drm/sprd/sprd_dphy.c > create mode 100644 drivers/gpu/drm/sprd/sprd_dphy.h > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h > create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c > create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h > create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.c > create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.h > > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: ti-sn65dsi86: remove redundant null check
Hi Yu Wang
On Wed, Sep 30, 2020 at 08:18:59AM +, Xu Wang wrote:
> Because clk_disable_unprepare already checked NULL clock parameter,
> so the additional checks are unnecessary, just remove it
>
> Signed-off-by: Xu Wang
Thanks, applied to drm-misc-next. I will appear in linux-next in a few
weeks.
Sam
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 5b6e19ecbc84..1b01836f1eb1 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -819,8 +819,7 @@ static void ti_sn_bridge_post_disable(struct drm_bridge
> *bridge)
> {
> struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
>
> - if (pdata->refclk)
> - clk_disable_unprepare(pdata->refclk);
> + clk_disable_unprepare(pdata->refclk);
>
> pm_runtime_put_sync(pdata->dev);
> }
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap
On Thu, Oct 8, 2020 at 4:51 AM Brian Starkey wrote: > On Sat, Oct 03, 2020 at 04:02:57AM +, John Stultz wrote: > > @@ -215,8 +236,12 @@ static void *system_heap_do_vmap(struct > > system_heap_buffer *buffer) > > struct page **pages = vmalloc(sizeof(struct page *) * npages); > > struct page **tmp = pages; > > struct sg_page_iter piter; > > + pgprot_t pgprot = PAGE_KERNEL; > > void *vaddr; > > > > + if (buffer->uncached) > > + pgprot = pgprot_writecombine(PAGE_KERNEL); > > I think this should go after the 'if (!pages)' check. Best to get the > allocation failure check as close to the allocation as possible IMO. Sounds good. Changed in my tree. > > @@ -393,6 +424,16 @@ static int system_heap_allocate(struct dma_heap *heap, > > /* just return, as put will call release and that will free */ > > return ret; > > } > > + > > + /* > > + * For uncached buffers, we need to initially flush cpu cache, since > > + * the __GFP_ZERO on the allocation means the zeroing was done by the > > + * cpu and thus it is likely cached. Map (and implicitly flush) it out > > + * now so we don't get corruption later on. > > + */ > > + if (buffer->uncached) > > + dma_map_sgtable(dma_heap_get_dev(heap), table, > > DMA_BIDIRECTIONAL, 0); > > Do we have to keep this mapping around for the entire lifetime of the > buffer? Yea, I guess we can just map and unmap it right there. It will look a little absurd, but that sort of aligns with your next point. > Also, this problem (and solution) keeps lingering around. It really > feels like there should be a better way to solve "clean the linear > mapping all the way to DRAM", but I don't know what that should be. Yea, something better here would be nice... > > @@ -426,6 +487,16 @@ static int system_heap_create(void) > > if (IS_ERR(sys_heap)) > > return PTR_ERR(sys_heap); > > > > + exp_info.name = "system-uncached"; > > + exp_info.ops = _uncached_heap_ops; > > + exp_info.priv = NULL; > > + > > + sys_uncached_heap = dma_heap_add(_info); > > + if (IS_ERR(sys_uncached_heap)) > > + return PTR_ERR(sys_heap); > > + > > In principle, there's a race here between the heap getting registered > to sysfs and the dma_mask getting updated. > > I don't think it would cause a problem in practice, but with the API > as it is, there's no way to avoid it - so I wonder if the > dma_heap_get_dev() accessor isn't the right API design. Hrm. I guess to address your concern we would need split dma_heap_add() into something like: dma_heap_create() dma_heap_add() Which breaks the creation of the heap with the registering it to the subsystem, so some attributes can be tweaked inbetween? I'll see about taking a stab at this, but I'll probably submit my updated series sooner with this un-addressed so I can get some further review. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
On Thu, Oct 8, 2020 at 4:36 AM Brian Starkey wrote: > > Hi John, > > On Sat, Oct 03, 2020 at 04:02:50AM +, John Stultz wrote: > > Hey All, > > ... > > > > > I did add to this series a reworked version of my uncached > > system heap implementation I was submitting a few weeks back. > > Since it duplicated a lot of the now reworked system heap code, > > I realized it would be much simpler to add the functionality to > > the system_heap implementaiton itself. > > That looks like a neat approach to me. Referencing your previous > thread, I like the separate heap (as you have done), rather than a > generic "cached"/"noncached" flag on all heaps. > Sounds good! I really appreciate the feedback on this. > > While not improving the core allocation performance, the > > uncached heap allocations do result in *much* improved > > performance on HiKey960 as it avoids a lot of flushing and > > invalidating buffers that the cpu doesn't touch often. > > > > Feedback on these would be great! > > Minor nit: s/detatch/detach/ on both heaps, but other than that > you can add my r-b to patches 1-5. Doh! Thanks for the spelling catch! Thanks again! > As you've said, it does feel like there's some room for > de-duplication, but that will be easier to work out once the > implementations settle. > > I've a couple of comments for the uncached heap, but I'm not confident > I understand the implications of having the non-cached alias enough to > say if it looks OK or not. Thanks so much! -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: ti-sn65dsi86: Add retries for link training
Hi Douglas.
On Fri, Oct 02, 2020 at 02:03:51PM -0700, Douglas Anderson wrote:
> On some panels hooked up to the ti-sn65dsi86 bridge chip we found that
> link training was failing. Specifically, we'd see:
>
> ti_sn65dsi86 2-002d: [drm:ti_sn_bridge_enable] *ERROR* Link training
> failed, link is off (-5)
>
> The panel was hooked up to a logic analyzer and it was found that, as
> part of link training, the bridge chip was writing a 0x1 to DPCD
> address 00600h and the panel responded NACK. As can be seen in header
> files, the write of 0x1 to DPCD address 0x600h means we were trying to
> write the value DP_SET_POWER_D0 to the register DP_SET_POWER. The
> panel vendor says that a NACK in this case is not unexpected and means
> "not ready, try again".
>
> In testing, we found that this panel would respond with a NACK in
> about 1/25 times. Adding the retry logic worked fine and the most
> number of tries needed was 3. Just to be safe, we'll add 10 tries
> here and we'll add a little blurb to the logs if we ever need more
> than 5.
>
> Signed-off-by: Douglas Anderson
I have picked this patch up and applied to drm-misc-next now.
Sam
> ---
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 40 +++
> 1 file changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index ecdf9b01340f..6e12cda69b54 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -106,6 +106,8 @@
> #define SN_NUM_GPIOS 4
> #define SN_GPIO_PHYSICAL_OFFSET 1
>
> +#define SN_LINK_TRAINING_TRIES 10
> +
> /**
> * struct ti_sn_bridge - Platform data for ti-sn65dsi86 driver.
> * @dev: Pointer to our device.
> @@ -673,6 +675,7 @@ static int ti_sn_link_training(struct ti_sn_bridge
> *pdata, int dp_rate_idx,
> {
> unsigned int val;
> int ret;
> + int i;
>
> /* set dp clk frequency value */
> regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,
> @@ -689,19 +692,34 @@ static int ti_sn_link_training(struct ti_sn_bridge
> *pdata, int dp_rate_idx,
> goto exit;
> }
>
> - /* Semi auto link training mode */
> - regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
> - ret = regmap_read_poll_timeout(pdata->regmap, SN_ML_TX_MODE_REG, val,
> -val == ML_TX_MAIN_LINK_OFF ||
> -val == ML_TX_NORMAL_MODE, 1000,
> -500 * 1000);
> - if (ret) {
> - *last_err_str = "Training complete polling failed";
> - } else if (val == ML_TX_MAIN_LINK_OFF) {
> - *last_err_str = "Link training failed, link is off";
> - ret = -EIO;
> + /*
> + * We'll try to link train several times. As part of link training
> + * the bridge chip will write DP_SET_POWER_D0 to DP_SET_POWER. If
> + * the panel isn't ready quite it might respond NAK here which means
> + * we need to try again.
> + */
> + for (i = 0; i < SN_LINK_TRAINING_TRIES; i++) {
> + /* Semi auto link training mode */
> + regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
> + ret = regmap_read_poll_timeout(pdata->regmap,
> SN_ML_TX_MODE_REG, val,
> + val == ML_TX_MAIN_LINK_OFF ||
> + val == ML_TX_NORMAL_MODE, 1000,
> + 500 * 1000);
> + if (ret) {
> + *last_err_str = "Training complete polling failed";
> + } else if (val == ML_TX_MAIN_LINK_OFF) {
> + *last_err_str = "Link training failed, link is off";
> + ret = -EIO;
> + continue;
> + }
> +
> + break;
> }
>
> + /* If we saw quite a few retries, add a note about it */
> + if (!ret && i > SN_LINK_TRAINING_TRIES / 2)
> + DRM_DEV_INFO(pdata->dev, "Link training needed %d retries\n",
> i);
> +
> exit:
> /* Disable the PLL if we failed */
> if (ret)
> --
> 2.28.0.806.g8561365e88-goog
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Fri, Oct 16, 2020 at 1:29 AM Greg Kroah-Hartman wrote: > > On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > > The ION android code has long been marked to be removed, now that we > > > dma-buf support merged into the real part of the kernel. > > > > > > It was thought that we could wait to remove the ion kernel at a later > > > time, but as the out-of-tree Android fork of the ion code has diverged > > > quite a bit, and any Android device using the ion interface uses that > > > forked version and not this in-tree version, the in-tree copy of the > > > code is abandonded and not used by anyone. > > > > > > Combine this abandoned codebase with the need to make changes to it in > > > order to keep the kernel building properly, which then causes merge > > > issues when merging those changes into the out-of-tree Android code, and > > > you end up with two different groups of people (the in-kernel-tree > > > developers, and the Android kernel developers) who are both annoyed at > > > the current situation. Because of this problem, just drop the in-kernel > > > copy of the ion code now, as it's not used, and is only causing problems > > > for everyone involved. > > > > > > Cc: "Arve Hjønnevåg" > > > Cc: "Christian König" > > > Cc: Christian Brauner > > > Cc: Christoph Hellwig > > > Cc: Hridya Valsaraju > > > Cc: Joel Fernandes > > > Cc: John Stultz > > > Cc: Laura Abbott > > > Cc: Martijn Coenen > > > Cc: Shuah Khan > > > Cc: Sumit Semwal > > > Cc: Suren Baghdasaryan > > > Cc: Todd Kjos > > > Cc: de...@driverdev.osuosl.org > > > Cc: dri-devel@lists.freedesktop.org > > > Cc: linaro-mm-...@lists.linaro.org > > > Signed-off-by: Greg Kroah-Hartman > > > > We discussed this at the Android MC on Monday and the plan was to > > remove it after the next LTS release. > > As 5.10 will be the next LTS release, I have now merged it to my > "testing" branch to go into 5.11-rc1. Sounds great! Thanks so much for waiting a bit on this, I really appreciate it! -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: Fix bus_flags handling
Hi Marek.
On Sat, Oct 03, 2020 at 01:07:26AM +0200, Marek Vasut wrote:
> The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW
> or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode.
So after reading this paragrahp I assumed this patch would fix this, alas
there is no changes to drm_modes.c.
Rather than introducing hacks could we try to fix the root cause here?
Root cause - as you point out is that there is missing some flags in
the conversion.
Another point is that the stm driver could drop the use of
drm_display_mode_to_videomode() - all the information is available in
drm_display_mode
and using drm_display_mode_to_videomode() does not help much.
If the point is to have easier access to hsync and friendns maybe we
should have a few helpers operating direct on display_mode and not this
conversion to video_mode which is something that belongs to fbdev and
should IMO not be used inside a drm driver.
Sam
> Therefore, no
> matter what polarity the next bridge or display might require, these flags
> are never set, and thus the LTDC GCR_DEPOL and GCR_PCPOL bits are never set,
> and the LTDC behaves as if both DISPLAY_FLAGS_PIXDATA_POSEDGE and
> DISPLAY_FLAGS_DE_HIGH were always set.
>
> The fix for this problem is taken almost verbatim from MXSFB driver. In
> case there is a bridge attached to the LTDC, the bridge might have extra
> polarity requirements, so extract bus_flags from the bridge and use them
> for LTDC configuration. Otherwise, extract bus_flags from the connector,
> which is the display.
>
> Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver")
> Signed-off-by: Marek Vasut
> Cc: Alexandre Torgue
> Cc: Antonio Borneo
> Cc: Benjamin Gaignard
> Cc: Maxime Coquelin
> Cc: Philippe Cornu
> Cc: Sam Ravnborg
> Cc: Vincent Abriou
> Cc: Yannick Fertre
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> To: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/stm/ltdc.c | 22 --
> drivers/gpu/drm/stm/ltdc.h | 2 ++
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 07c73079293c..a282a1553497 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -546,11 +546,17 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc
> *crtc)
> struct drm_device *ddev = crtc->dev;
> struct drm_display_mode *mode = >state->adjusted_mode;
> struct videomode vm;
> + u32 bus_flags = 0;
> u32 hsync, vsync, accum_hbp, accum_vbp, accum_act_w, accum_act_h;
> u32 total_width, total_height;
> u32 val;
> int ret;
>
> + if (ldev->bridge)
> + bus_flags = ldev->bridge->timings->input_bus_flags;
> + else if (ldev->connector)
> + bus_flags = ldev->connector->display_info.bus_flags;
> +
> if (!pm_runtime_active(ddev->dev)) {
> ret = pm_runtime_get_sync(ddev->dev);
> if (ret) {
> @@ -586,10 +592,10 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc
> *crtc)
> if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
> val |= GCR_VSPOL;
>
> - if (vm.flags & DISPLAY_FLAGS_DE_LOW)
> + if (bus_flags & DRM_BUS_FLAG_DE_LOW)
> val |= GCR_DEPOL;
>
> - if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> + if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
> val |= GCR_PCPOL;
>
> reg_update_bits(ldev->regs, LTDC_GCR,
> @@ -1098,6 +1104,8 @@ static const struct drm_encoder_helper_funcs
> ltdc_encoder_helper_funcs = {
>
> static int ltdc_encoder_init(struct drm_device *ddev, struct drm_bridge
> *bridge)
> {
> + struct ltdc_device *ldev = ddev->dev_private;
> + struct drm_connector_list_iter iter;
> struct drm_encoder *encoder;
> int ret;
>
> @@ -1119,6 +1127,16 @@ static int ltdc_encoder_init(struct drm_device *ddev,
> struct drm_bridge *bridge)
> return -EINVAL;
> }
>
> + ldev->bridge = bridge;
> +
> + /*
> + * Get hold of the connector. This is a bit of a hack, until the bridge
> + * API gives us bus flags and formats.
> + */
> + drm_connector_list_iter_begin(ddev, );
> + ldev->connector = drm_connector_list_iter_next();
> + drm_connector_list_iter_end();
> +
> DRM_DEBUG_DRIVER("Bridge encoder:%d created\n", encoder->base.id);
>
> return 0;
> diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
> index f153b908c70e..d0d2c81de29a 100644
> --- a/drivers/gpu/drm/stm/ltdc.h
> +++ b/drivers/gpu/drm/stm/ltdc.h
> @@ -38,6 +38,8 @@ struct ltdc_device {
> u32 irq_status;
> struct fps_info plane_fpsi[LTDC_MAX_LAYER];
> struct drm_atomic_state *suspend_state;
> + struct drm_bridge *bridge;
> + struct drm_connector *connector;
> };
>
> int ltdc_load(struct drm_device *ddev);
> --
> 2.28.0
>
>
Re: [PATCH v2 6/8] dt-bindings: usb: convert mediatek,mtk-xhci.txt to YAML schema
On Tue, Oct 13, 2020 at 04:52:05PM +0800, Chunfeng Yun wrote: > Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml > There's some refactoring of usb-hcd.yaml and XHCI schema under review and this may need some refactoring on top of it. > Signed-off-by: Chunfeng Yun > --- > v2: new patch > --- > .../bindings/usb/mediatek,mtk-xhci.txt| 121 > .../bindings/usb/mediatek,mtk-xhci.yaml | 180 ++ > 2 files changed, 180 insertions(+), 121 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt > create mode 100644 > Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > new file mode 100644 > index ..ea696c8f1269 > --- /dev/null > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > @@ -0,0 +1,180 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +# Copyright (c) 2020 MediaTek > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/usb/mediatek,mtk-xhci.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MediaTek USB3 xHCI Device Tree Bindings > + > +maintainers: > + - Chunfeng Yun > + > +allOf: > + - $ref: "usb-hcd.yaml" > + > +description: | > + There are two scenarios: > + case 1: only supports xHCI driver; > + case 2: supports dual-role mode, and the host is based on xHCI driver. > + > +properties: > + #common properties for both case 1 and case 2 > + compatible: > +items: > + - enum: > + - mediatek,mt2712-xhci > + - mediatek,mt7622-xhci > + - mediatek,mt7629-xhci > + - mediatek,mt8173-xhci > + - mediatek,mt8183-xhci > + - const: mediatek,mtk-xhci > + > + reg: > +minItems: 1 > +maxItems: 2 > +items: > + - description: the registers of xHCI MAC > + - description: the registers of IP Port Control > + > + reg-names: > +minItems: 1 > +maxItems: 2 > +items: > + - const: mac > + - const: ippc #optional, only needed for case 1. > + > + interrupts: > +maxItems: 1 > + > + power-domains: > +description: A phandle to USB power domain node to control USB's MTCMOS > +maxItems: 1 > + > + clocks: > +minItems: 1 > +maxItems: 5 > +items: > + - description: Controller clock used by normal mode > + - description: Reference clock used by low power mode etc > + - description: Mcu bus clock for register access > + - description: DMA bus clock for data transfer > + - description: controller clock > + > + clock-names: > +minItems: 1 > +maxItems: 5 > +items: > + - const: sys_ck #required, the following ones are optional > + - const: ref_ck > + - const: mcu_ck > + - const: dma_ck > + - const: xhci_ck > + > + phys: > +$ref: /usb/usb-hcd.yaml# That doesn't look right... > + > + vusb33-supply: > +description: Regulator of USB AVDD3.3v > + > + vbus-supply: > +description: Regulator of USB VBUS5v > + > + usb3-lpm-capable: > +description: supports USB3.0 LPM > +type: boolean > + > + imod-interval-ns: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: | > + Interrupt moderation interval value, it is 8 times as much as that > + defined in the xHCI spec on MTK's controller. > +default: 5000 > + > + #the following properties are only used for case 1 > + pinctrl-0: > +description: A phandle to the default pinctrl state. > + > + pinctrl-names: > +description: A pinctrl state named "default" must be defined. > + See pinctrl/pinctrl-bindings.txt > +const: default Don't need pinctrl-* properties. They are always allowed. > + > + wakeup-source: > +description: enable USB remote wakeup, see power/wakeup-source.txt > +type: boolean > + > + mediatek,syscon-wakeup: > +$ref: /schemas/types.yaml#/definitions/phandle-array > +maxItems: 1 > +description: | > + A phandle to syscon used to access the register of the USB wakeup glue > + layer between xHCI and SPM, the field should always be a multiple of > + 3 cells long. A multiple of 3? How would there be more than 3 cells? > + > + items: > +- description: > +The first cell represents a phandle to syscon > +- description: > +The second cell represents the register base address of the glue > +layer in syscon > +- description: > +The third cell represents the hardware version of the glue layer, > +1 is used by mt8173 etc, 2 is used by mt2712 etc > + enum: [1, 2] > + > + mediatek,u3p-dis-msk: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: The mask to disable u3ports, bit0 for u3port0, > + bit1 for u3port1, ... etc > + > +
Re: [PATCH v2 5/8] dt-bindings: usb: convert mediatek, musb.txt to YAML schema
On Tue, 13 Oct 2020 16:52:04 +0800, Chunfeng Yun wrote: > Convert mediatek,musb.txt to YAML schema mediatek,musb.yaml > > Cc: Min Guo > Signed-off-by: Chunfeng Yun > --- > v2: new patch > --- > .../devicetree/bindings/usb/mediatek,musb.txt | 57 - > .../bindings/usb/mediatek,musb.yaml | 113 ++ > 2 files changed, 113 insertions(+), 57 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt > create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/8] dt-bindings: phy: convert HDMI PHY binding to YAML schema
On Tue, 13 Oct 2020 16:52:03 +0800, Chunfeng Yun wrote: > Convert HDMI PHY binding to YAML schema mediatek,ufs-phy.yaml > > Signed-off-by: Chunfeng Yun > --- > v2: fix binding check warning of reg in example > --- > .../display/mediatek/mediatek,hdmi.txt| 17 +--- > .../bindings/phy/mediatek,hdmi-phy.yaml | 90 +++ > 2 files changed, 91 insertions(+), 16 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/8] dt-bindings: phy: convert phy-mtk-ufs.txt to YAML schema
On Tue, 13 Oct 2020 16:52:02 +0800, Chunfeng Yun wrote: > Convert phy-mtk-ufs.txt to YAML schema mediatek,ufs-phy.yaml > > Signed-off-by: Chunfeng Yun > --- > v2: fix binding check warning of reg in example > --- > .../bindings/phy/mediatek,ufs-phy.yaml| 64 +++ > .../devicetree/bindings/phy/phy-mtk-ufs.txt | 38 --- > 2 files changed, 64 insertions(+), 38 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml > delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly
On Fri, Oct 16, 2020 at 7:02 PM Melissa Wen wrote: > > On 10/16, Daniel Vetter wrote: > > On Fri, Oct 16, 2020 at 12:38 PM Simon Ser wrote: > > > > > > > The only thing we support is xrgb. > > > > > > > > Signed-off-by: Daniel Vetter > > > > Cc: Rodrigo Siqueira > > > > Cc: Melissa Wen > > > > Cc: Haneen Mohammed > > > > Cc: Daniel Vetter > > > > --- > > > > drivers/gpu/drm/vkms/vkms_drv.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c > > > > b/drivers/gpu/drm/vkms/vkms_drv.c > > > > index 726801ab44d4..eb4007443706 100644 > > > > --- a/drivers/gpu/drm/vkms/vkms_drv.c > > > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > > > > @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device > > > > *vkmsdev) > > > > dev->mode_config.max_height = YRES_MAX; > > > > dev->mode_config.cursor_width = 512; > > > > dev->mode_config.cursor_height = 512; > > > > - dev->mode_config.preferred_depth = 24; > > > > + dev->mode_config.preferred_depth = 32; > > > > > > Are you sure xrgb's depth is 32 and not 24? Looking at drmdb [1], > > > *all* > > > drivers set it to 24. > > > > Uh there's a problem I think. Depth should indeed stay at 24, the > > problem is that fb helpers directly take that to be the bpp parameter, > > which is a different thing. And if you look at how most drivers set up > > that, they pick 32. > > > > I guess I need to revert this here, and unconfuse the fb helpers about > > depth vs bpp. > > Hi guys, > > Perhaps it deserves to be pointed out: the documentation says > "preferred_depth: preferred RBG(sic) pixel depth, used by fb helpers", > and looking to fb helpers, preferred_depth is only used by > generic_setup, as bits by pixel (if I didn't miss something there). > > In fact, the alpha channel is not used for final display (perhaps in the > future); however, I saw another driver with a change similar to this > here and, possibly like me, following the same misunderstanding. Yeah the problem is that preferred_depth is depth, and that means 24 bit for XRGB. But bpp as used by fb helpers would be 32 bit for XRGB. I think the real fix here is to switch this entire mess over to using drm_fourcc codes directly, at least for atomic drivers. Which nowadays are most. Interim I'm not sure whether we should revert my patch (it breaks fbdev) or switch preferred_depth to 0, which means we get the default every, and that means both fbdev helpers and userspace will pick XRGB. -Daniel > Melissa > > > > Maybe best would be to just switch over to preferred drm_fourcc format > > code, or maybe just pick this up from the first format the primary > > plane supports. > > > > This is all getting slightly tricky and a lot more work :-/ > > -Daniel > > -- > > 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 v2 2/8] dt-bindings: phy: convert phy-mtk-tphy.txt to YAML schema
On Tue, Oct 13, 2020 at 04:52:01PM +0800, Chunfeng Yun wrote: > Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml > > Signed-off-by: Chunfeng Yun > --- > v2: modify description and compatible > --- > .../bindings/phy/mediatek,tphy.yaml | 263 ++ > .../devicetree/bindings/phy/phy-mtk-tphy.txt | 162 --- > 2 files changed, 263 insertions(+), 162 deletions(-) > create mode 100755 Documentation/devicetree/bindings/phy/mediatek,tphy.yaml Also, need to fix the mode. > delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/8] dt-bindings: phy: convert phy-mtk-tphy.txt to YAML schema
On Tue, Oct 13, 2020 at 04:52:01PM +0800, Chunfeng Yun wrote: > Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml > > Signed-off-by: Chunfeng Yun > --- > v2: modify description and compatible > --- > .../bindings/phy/mediatek,tphy.yaml | 263 ++ > .../devicetree/bindings/phy/phy-mtk-tphy.txt | 162 --- > 2 files changed, 263 insertions(+), 162 deletions(-) > create mode 100755 Documentation/devicetree/bindings/phy/mediatek,tphy.yaml > delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt > > diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml > b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml > new file mode 100755 > index ..56ad8be69095 > --- /dev/null > +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml > @@ -0,0 +1,263 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +# Copyright (c) 2020 MediaTek > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/phy/mediatek,tphy.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MediaTek T-PHY Controller Device Tree Bindings > + > +maintainers: > + - Chunfeng Yun > + > +description: | > + The T-PHY controller supports physical layer functionality for a number of > + controllers on MediaTek SoCs, includes USB2.0, USB3.0, PCIe and SATA. > + > + Layout differences of banks between T-PHY V1 (mt8173/mt2701) and > + T-PHY V2 (mt2712) when works on USB mode: > + --- > + Version 1: > + portoffsetbank > + shared 0xSPLLC > + 0x0100FMREG > + u2 port00x0800U2PHY_COM > + u3 port00x0900U3PHYD > + 0x0a00U3PHYD_BANK2 > + 0x0b00U3PHYA > + 0x0c00U3PHYA_DA > + u2 port10x1000U2PHY_COM > + u3 port10x1100U3PHYD > + 0x1200U3PHYD_BANK2 > + 0x1300U3PHYA > + 0x1400U3PHYA_DA > + u2 port20x1800U2PHY_COM > + ... > + > + Version 2: > + portoffsetbank > + u2 port00xMISC > + 0x0100FMREG > + 0x0300U2PHY_COM > + u3 port00x0700SPLLC > + 0x0800CHIP > + 0x0900U3PHYD > + 0x0a00U3PHYD_BANK2 > + 0x0b00U3PHYA > + 0x0c00U3PHYA_DA > + u2 port10x1000MISC > + 0x1100FMREG > + 0x1300U2PHY_COM > + u3 port10x1700SPLLC > + 0x1800CHIP > + 0x1900U3PHYD > + 0x1a00U3PHYD_BANK2 > + 0x1b00U3PHYA > + 0x1c00U3PHYA_DA > + u2 port20x2000MISC > + ... > + > + SPLLC shared by u3 ports and FMREG shared by u2 ports on V1 are put back > + into each port; a new bank MISC for u2 ports and CHIP for u3 ports are > + added on V2. > + > +properties: > + $nodename: > + pattern: "^t-phy@[0-9a-f]+$" Wrong indentation. Should be 1 less. > + > + compatible: > +oneOf: > + - items: > + - enum: > + - mediatek,mt2701-tphy > + - mediatek,mt7623-tphy > + - mediatek,mt7622-tphy > + - mediatek,mt8516-tphy > + - const: mediatek,generic-tphy-v1 > + - items: > + - enum: > + - mediatek,mt2712-tphy > + - mediatek,mt7629-tphy > + - mediatek,mt8183-tphy > + - const: mediatek,generic-tphy-v2 > + - const: mediatek,mt2701-u3phy > +deprecated: true > + - const: mediatek,mt2712-u3phy > +deprecated: true > + - const: mediatek,mt8173-u3phy > + > + reg: > +description: | Don't need '|' if there's no formatting to preserve. > + Register shared by multiple ports, exclude port's private register. > + It is needed for T-PHY V1, such as mt2701 and mt8173, but not for > + T-PHY V2, such as mt2712. > +maxItems: 1 > + > + "#address-cells": > + enum: [1, 2] > + > + "#size-cells": > + enum: [1, 2] Wrong indent. > + > + # Used with non-empty value if optional 'reg' is not provided. > + # The format of the value is an arbitrary number of triplets of > + # (child-bus-address, parent-bus-address, length). > + ranges: true > + > + mediatek,src-ref-clk-mhz: > +description: > + Frequency of reference clock for slew rate calibrate > +$ref: /schemas/types.yaml#/definitions/uint32 > +default: 26 > + > + mediatek,src-coef: > +description: > + Coefficient for slew rate calibrate, depends on SoC process > +$ref: /schemas/types.yaml#/definitions/uint32 > +default: 28 > + > +# Required child node: > +patternProperties: > + "^usb-phy@[0-9a-f]+$": > +type: object > +description: | > + A sub-node is required for each port the controller provides. > + Address range information including the usual
Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly
On 10/16, Daniel Vetter wrote: > On Fri, Oct 16, 2020 at 12:38 PM Simon Ser wrote: > > > > > The only thing we support is xrgb. > > > > > > Signed-off-by: Daniel Vetter > > > Cc: Rodrigo Siqueira > > > Cc: Melissa Wen > > > Cc: Haneen Mohammed > > > Cc: Daniel Vetter > > > --- > > > drivers/gpu/drm/vkms/vkms_drv.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c > > > b/drivers/gpu/drm/vkms/vkms_drv.c > > > index 726801ab44d4..eb4007443706 100644 > > > --- a/drivers/gpu/drm/vkms/vkms_drv.c > > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > > > @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device > > > *vkmsdev) > > > dev->mode_config.max_height = YRES_MAX; > > > dev->mode_config.cursor_width = 512; > > > dev->mode_config.cursor_height = 512; > > > - dev->mode_config.preferred_depth = 24; > > > + dev->mode_config.preferred_depth = 32; > > > > Are you sure xrgb's depth is 32 and not 24? Looking at drmdb [1], *all* > > drivers set it to 24. > > Uh there's a problem I think. Depth should indeed stay at 24, the > problem is that fb helpers directly take that to be the bpp parameter, > which is a different thing. And if you look at how most drivers set up > that, they pick 32. > > I guess I need to revert this here, and unconfuse the fb helpers about > depth vs bpp. Hi guys, Perhaps it deserves to be pointed out: the documentation says "preferred_depth: preferred RBG(sic) pixel depth, used by fb helpers", and looking to fb helpers, preferred_depth is only used by generic_setup, as bits by pixel (if I didn't miss something there). In fact, the alpha channel is not used for final display (perhaps in the future); however, I saw another driver with a change similar to this here and, possibly like me, following the same misunderstanding. Melissa > > Maybe best would be to just switch over to preferred drm_fourcc format > code, or maybe just pick this up from the first format the primary > plane supports. > > This is all getting slightly tricky and a lot more work :-/ > -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 v2 1/8] dt-bindings: phy: convert phy-mtk-xsphy.txt to YAML schema
On Tue, Oct 13, 2020 at 04:52:00PM +0800, Chunfeng Yun wrote: > Convert phy-mtk-xsphy.txt to YAML schema mediatek,xsphy.yaml > > Signed-off-by: Chunfeng Yun > --- > v2: modify description and compatible definition suggested by Rob > --- > .../bindings/phy/mediatek,xsphy.yaml | 200 ++ > .../devicetree/bindings/phy/phy-mtk-xsphy.txt | 109 -- > 2 files changed, 200 insertions(+), 109 deletions(-) > create mode 100644 Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml > delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt > > diff --git a/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml > b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml > new file mode 100644 > index ..86511f19277a > --- /dev/null > +++ b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml > @@ -0,0 +1,200 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +# Copyright (c) 2020 MediaTek > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/phy/mediatek,xsphy.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MediaTek XS-PHY Controller Device Tree Bindings > + > +maintainers: > + - Chunfeng Yun > + > +description: | > + The XS-PHY controller supports physical layer functionality for USB3.1 > + GEN2 controller on MediaTek SoCs. > + > + Banks layout of xsphy > + -- > + portoffsetbank > + u2 port00xMISC > + 0x0100FMREG > + 0x0300U2PHY_COM > + u2 port10x1000MISC > + 0x1100FMREG > + 0x1300U2PHY_COM > + u2 port20x2000MISC > + ... > + u31 common 0x3000DIG_GLB > + 0x3100PHYA_GLB > + u31 port0 0x3400DIG_LN_TOP > + 0x3500DIG_LN_TX0 > + 0x3600DIG_LN_RX0 > + 0x3700DIG_LN_DAIF > + 0x3800PHYA_LN > + u31 port1 0x3a00DIG_LN_TOP > + 0x3b00DIG_LN_TX0 > + 0x3c00DIG_LN_RX0 > + 0x3d00DIG_LN_DAIF > + 0x3e00PHYA_LN > + ... > + DIG_GLB & PHYA_GLB are shared by U31 ports. > + > +properties: > + $nodename: > +pattern: "^xs-phy@[0-9a-f]+$" > + > + compatible: > +items: > + - enum: > + - mediatek,mt3611-xsphy > + - mediatek,mt3612-xsphy > + - const: mediatek,xsphy > + > + reg: > +description: | > + Register shared by multiple U3 ports, exclude port's private register, > + if only U2 ports provided, shouldn't use the property. > +maxItems: 1 > + > + "#address-cells": > + enum: [1, 2] > + > + "#size-cells": > + enum: [1, 2] > + > + ranges: true > + > + mediatek,src-ref-clk-mhz: > +description: > + Frequency of reference clock for slew rate calibrate > +$ref: /schemas/types.yaml#/definitions/uint32 Properties with a standard unit suffix don't need a type. > +default: 26 > + > + mediatek,src-coef: > +description: > + Coefficient for slew rate calibrate, depends on SoC process > +$ref: /schemas/types.yaml#/definitions/uint32 > +default: 17 > + > +# Required child node: > +patternProperties: > + "^usb-phy@[0-9a-f]+$": > +type: object > +description: | > + A sub-node is required for each port the controller provides. > + Address range information including the usual 'reg' property > + is used inside these nodes to describe the controller's topology. > + > +properties: > + reg: > +maxItems: 1 > + > + clocks: > +items: > + - description: Reference clock, (HS is 48Mhz, SS/P is 24~27Mhz) > + > + clock-names: > +items: > + - const: ref > + > + "#phy-cells": > +const: 1 > +description: | > + The cells contain the following arguments. > + > + - description: The PHY type > + enum: > +- PHY_TYPE_USB2 > +- PHY_TYPE_USB3 > + > + #The following optional vendor properties are only for debug or HQA > test > + mediatek,eye-src: > +description: > + The value of slew rate calibrate (U2 phy) > +$ref: /schemas/types.yaml#/definitions/uint32 > +minimum: 1 > +maximum: 7 > + > + mediatek,eye-vrt: > +description: > + The selection of VRT reference voltage (U2 phy) > +$ref: /schemas/types.yaml#/definitions/uint32 > +minimum: 1 > +maximum: 7 > + > + mediatek,eye-term: > +description: > + The selection of HS_TX TERM reference voltage (U2 phy) > +$ref: /schemas/types.yaml#/definitions/uint32 > +minimum: 1 > +maximum: 7 > + > + mediatek,efuse-intr: > +description: > + The selection of Internal Resistor (U2/U3 phy) > +$ref: /schemas/types.yaml#/definitions/uint32 > +
Re: [PATCH v2 0/3] drm: commit_work scheduling
On Thu, Oct 8, 2020 at 1:24 AM Ville Syrjälä wrote: > > On Wed, Oct 07, 2020 at 09:44:09AM -0700, Rob Clark wrote: > > On Mon, Oct 5, 2020 at 5:15 AM Ville Syrjälä > > wrote: > > > > > > On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote: > > > > On Fri, Oct 2, 2020 at 4:05 AM Ville Syrjälä > > > > wrote: > > > > > > > > > > On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote: > > > > > > On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote: > > > > > > > On Thu, Oct 1, 2020 at 5:15 PM Rob Clark > > > > > > > wrote: > > > > > > > > > > > > > > > > I'm leaning towards converting the other drivers over to use the > > > > > > > > per-crtc kwork, and then dropping the 'commit_work` from atomic > > > > > > > > state. > > > > > > > > I can add a patch to that, but figured I could postpone that > > > > > > > > churn > > > > > > > > until there is some by-in on this whole idea. > > > > > > > > > > > > > > i915 has its own commit code, it's not even using the current > > > > > > > commit > > > > > > > helpers (nor the commit_work). Not sure how much other fun there > > > > > > > is. > > > > > > > > > > > > I don't think we want per-crtc threads for this in i915. Seems > > > > > > to me easier to guarantee atomicity across multiple crtcs if > > > > > > we just commit them from the same thread. > > > > > > > > > > Oh, and we may have to commit things in a very specific order > > > > > to guarantee the hw doesn't fall over, so yeah definitely per-crtc > > > > > thread is a no go. > > > > > > > > If I'm understanding the i915 code, this is only the case for modeset > > > > commits? I suppose we could achieve the same result by just deciding > > > > to pick the kthread of the first CRTC for modeset commits. I'm not > > > > really so much concerned about parallelism for modeset. > > > > > > I'm not entirely happy about the random differences between modesets > > > and other commits. Ideally we wouldn't need any. > > > > > > Anyways, even if we ignore modesets we still have the issue with > > > atomicity guarantees across multiple crtcs. So I think we still > > > don't want per-crtc threads, rather it should be thread for each > > > commit. > > > > I don't really see any other way to solve the priority inversion other > > than per-CRTC kthreads. > > What's the problem with just something like a dedicated commit > thread pool? partly, I was trying to avoid re-implementing workqueue. And partly the thread-pool approach seems like it would be harder for userspace to find the tasks which need priority adjustment. But each CRTC is essentially a FIFO, pageflip N+1 on a given CRTC will happen after pageflip N. BR, -R > > I've been thinking about it a bit more, and > > my conclusion is: > > > > (1) There isn't really any use for the N+1'th commit to start running > > before the kthread_work for the N'th commit completes, so I don't mind > > losing the unbound aspect of the workqueue approach > > (2) For cases where there does need to be serialization between > > commits on different CRTCs, since there is a per-CRTC kthread, you > > could achieve this with locking > > > > Since i915 isn't using the atomic helpers here, I suppose it is an > > option for i915 to just continue doing what it is doing. > > > > And I could ofc just stop using the atomic commit helper and do the > > kthreads thing in msm. But my first preference would be that the > > commit helper does generally the right thing. > > > > BR, > > -R > > -- > Ville Syrjälä > Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] drm/bridge: lvds-codec: Add support for pixel data sampling edge select
Hi Marek.
On Sat, Oct 03, 2020 at 01:08:23AM +0200, Marek Vasut wrote:
> The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
> select input pixel data sampling edge. Add DT property "pixelclk-active",
> same as the one used by display timings, and configure bus flags based on
> this DT property.
Why is it that this information cannot come from the panel driver?
The property tell when data are sampled and the FIN3385 Parallel-to-LVDS
is the one that transmit the data - not then one that samples the data.
Correct?
Sam
>
> Signed-off-by: Marek Vasut
> Cc: Alexandre Torgue
> Cc: Andrzej Hajda
> Cc: Antonio Borneo
> Cc: Benjamin Gaignard
> Cc: Biju Das
> Cc: Laurent Pinchart
> Cc: Maxime Coquelin
> Cc: Philippe Cornu
> Cc: Sam Ravnborg
> Cc: Vincent Abriou
> Cc: Yannick Fertre
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> To: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/bridge/lvds-codec.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> b/drivers/gpu/drm/bridge/lvds-codec.c
> index f52ccffc1bd1..bc941d4fb5b9 100644
> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> @@ -19,6 +19,7 @@ struct lvds_codec {
> struct device *dev;
> struct drm_bridge bridge;
> struct drm_bridge *panel_bridge;
> + struct drm_bridge_timings timings;
> struct regulator *vcc;
> struct gpio_desc *powerdown_gpio;
> u32 connector_type;
> @@ -80,6 +81,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
> struct device_node *panel_node;
> struct drm_panel *panel;
> struct lvds_codec *lvds_codec;
> + u32 val;
> int ret;
>
> lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
> @@ -124,6 +126,12 @@ static int lvds_codec_probe(struct platform_device *pdev)
> if (IS_ERR(lvds_codec->panel_bridge))
> return PTR_ERR(lvds_codec->panel_bridge);
>
> + if (!of_property_read_u32(dev->of_node, "pixelclk-active", )) {
> + lvds_codec->timings.input_bus_flags = val ?
> + DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE :
> + DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE;
> + }
> +
> /*
>* The panel_bridge bridge is attached to the panel's of_node,
>* but we need a bridge attached to our of_node for our user
> @@ -131,6 +139,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
>*/
> lvds_codec->bridge.of_node = dev->of_node;
> lvds_codec->bridge.funcs =
> + lvds_codec->bridge.timings = _codec->timings;
> drm_bridge_add(_codec->bridge);
>
> platform_set_drvdata(pdev, lvds_codec);
> --
> 2.28.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209721] No output after AMDGPU loads.
https://bugzilla.kernel.org/show_bug.cgi?id=209721 --- Comment #3 from Haxk20 (haxk...@gmail.com) --- Will build it in and report back. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203471] Tearing on Raven Ridge and RX560X PRIME setup even with Vsync enabled
https://bugzilla.kernel.org/show_bug.cgi?id=203471 --- Comment #23 from Haxk20 (haxk...@gmail.com) --- For people wondering yes this is still an issue. The bug is 1 year old now. scatter/gather support has been enabled in the kernel for a long time now yet its still broken. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209721] No output after AMDGPU loads.
https://bugzilla.kernel.org/show_bug.cgi?id=209721 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- Does this patch fix it? https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.10=44264591a8c4da7090a4bfd10e04f4cb8fe60afe -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209721] No output after AMDGPU loads.
https://bugzilla.kernel.org/show_bug.cgi?id=209721 --- Comment #1 from Haxk20 (haxk...@gmail.com) --- The HEAD of the kernel is current head on mainline. That is "9ff9b0d392ea08090cd1780fb196f36dbb586529" -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209721] New: No output after AMDGPU loads.
https://bugzilla.kernel.org/show_bug.cgi?id=209721 Bug ID: 209721 Summary: No output after AMDGPU loads. Product: Drivers Version: 2.5 Kernel Version: Linux Master branch Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: haxk...@gmail.com Regression: No I sadly cant even get an dmesg from journalctl or anything. when i enable loglevel8 it shows me that fb0 is giving word to AMDGPU module and then screen goes black turns back on but no output at all. System Specs: Acer Nitro 5 AN515-42 GPUs: AMD Vega 8 (iGPU in Ryzen 5 2500U) AMD Radeon RX560X (dGPU) If there is any way you know of to be able to grab logs i will gladly do it. It should be noted that 5.9 tag works just fine. So the bug was introduced in one of the drm-next merges. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v3] drm/msm: Fix race condition in msm driver with async layer updates
On Fri, Oct 16, 2020 at 7:11 AM Krishna Manikandan
wrote:
>
> When there are back to back commits with async cursor update,
> there is a case where second commit can program the DPU hw
> blocks while first didn't complete flushing config to HW.
>
> Synchronize the compositions such that second commit waits
> until first commit flushes the composition.
>
> This change also introduces per crtc commit lock, such that
> commits on different crtcs are not blocked by each other.
>
> Changes in v2:
> - Use an array of mutexes in kms to handle commit
> lock per crtc. (Rob Clark)
>
> Changes in v3:
> - Add wrapper functions to handle lock and unlock of
> commit_lock for each crtc. (Rob Clark)
>
> Signed-off-by: Krishna Manikandan
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_atomic.c | 37 -
> drivers/gpu/drm/msm/msm_kms.h| 6 --
> 2 files changed, 28 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_atomic.c
> b/drivers/gpu/drm/msm/msm_atomic.c
> index 561bfa4..575e9af 100644
> --- a/drivers/gpu/drm/msm/msm_atomic.c
> +++ b/drivers/gpu/drm/msm/msm_atomic.c
> @@ -55,16 +55,32 @@ static void vblank_put(struct msm_kms *kms, unsigned
> crtc_mask)
> }
> }
>
> +static void lock_crtcs(struct msm_kms *kms, unsigned int crtc_mask)
> +{
> + struct drm_crtc *crtc;
> +
> + for_each_crtc_mask(kms->dev, crtc, crtc_mask)
> + mutex_lock(>commit_lock[drm_crtc_index(crtc)]);
> +}
> +
> +static void unlock_crtcs(struct msm_kms *kms, unsigned int crtc_mask)
> +{
> + struct drm_crtc *crtc;
> +
> + for_each_crtc_mask(kms->dev, crtc, crtc_mask)
> + mutex_unlock(>commit_lock[drm_crtc_index(crtc)]);
> +}
> +
> static void msm_atomic_async_commit(struct msm_kms *kms, int crtc_idx)
> {
> unsigned crtc_mask = BIT(crtc_idx);
>
> trace_msm_atomic_async_commit_start(crtc_mask);
>
> - mutex_lock(>commit_lock);
> + lock_crtcs(kms, crtc_mask);
>
> if (!(kms->pending_crtc_mask & crtc_mask)) {
> - mutex_unlock(>commit_lock);
> + unlock_crtcs(kms, crtc_mask);
> goto out;
> }
>
> @@ -79,7 +95,6 @@ static void msm_atomic_async_commit(struct msm_kms *kms,
> int crtc_idx)
> */
> trace_msm_atomic_flush_commit(crtc_mask);
> kms->funcs->flush_commit(kms, crtc_mask);
> - mutex_unlock(>commit_lock);
>
> /*
> * Wait for flush to complete:
> @@ -90,9 +105,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms,
> int crtc_idx)
>
> vblank_put(kms, crtc_mask);
>
> - mutex_lock(>commit_lock);
> kms->funcs->complete_commit(kms, crtc_mask);
> - mutex_unlock(>commit_lock);
> + unlock_crtcs(kms, crtc_mask);
> kms->funcs->disable_commit(kms);
>
> out:
> @@ -189,12 +203,11 @@ void msm_atomic_commit_tail(struct drm_atomic_state
> *state)
> * Ensure any previous (potentially async) commit has
> * completed:
> */
> + lock_crtcs(kms, crtc_mask);
> trace_msm_atomic_wait_flush_start(crtc_mask);
> kms->funcs->wait_flush(kms, crtc_mask);
> trace_msm_atomic_wait_flush_finish(crtc_mask);
>
> - mutex_lock(>commit_lock);
> -
> /*
> * Now that there is no in-progress flush, prepare the
> * current update:
> @@ -232,8 +245,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state
> *state)
> }
>
> kms->funcs->disable_commit(kms);
> - mutex_unlock(>commit_lock);
> -
> + unlock_crtcs(kms, crtc_mask);
> /*
> * At this point, from drm core's perspective, we
> * are done with the atomic update, so we can just
> @@ -260,8 +272,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state
> *state)
> */
> trace_msm_atomic_flush_commit(crtc_mask);
> kms->funcs->flush_commit(kms, crtc_mask);
> - mutex_unlock(>commit_lock);
> -
> + unlock_crtcs(kms, crtc_mask);
> /*
> * Wait for flush to complete:
> */
> @@ -271,9 +282,9 @@ void msm_atomic_commit_tail(struct drm_atomic_state
> *state)
>
> vblank_put(kms, crtc_mask);
>
> - mutex_lock(>commit_lock);
> + lock_crtcs(kms, crtc_mask);
> kms->funcs->complete_commit(kms, crtc_mask);
> - mutex_unlock(>commit_lock);
> + unlock_crtcs(kms, crtc_mask);
> kms->funcs->disable_commit(kms);
>
> drm_atomic_helper_commit_hw_done(state);
> diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
> index 1cbef6b..2049847 100644
> --- a/drivers/gpu/drm/msm/msm_kms.h
> +++ b/drivers/gpu/drm/msm/msm_kms.h
> @@ -155,7 +155,7 @@ struct msm_kms {
> * For async commit, where ->flush_commit() and later happens
> * from the crtc's pending_timer close to end of the
Re: [PATCH 1/2] drm/adi: axi-hdmi-tx: Add support for AXI HDMI TX IP core
Hi Bogdan On Mon, Oct 05, 2020 at 05:12:08PM +0300, Bogdan Togorean wrote: > From: Lars-Peter Clausen > > The AXI HDMI HDL driver is the driver for the HDL graphics core which is > used on various FPGA designs. It's mostly used to interface with the > ADV7511 driver on some Zynq boards (e.g. ZC702 & ZedBoard). > > Link: > https://wiki.analog.com/resources/tools-software/linux-drivers/drm/hdl-axi-hdmi > Link: https://wiki.analog.com/resources/fpga/docs/axi_hdmi_tx Thanks for submitting the driver - a few high level comments after browsing the driver: - Use drmm_mode_config_init() to utilize new cleanup - Look at other uses of drm_driver - there is macros that makes this much simpler / smaller - Use devm_drm_dev_alloc() to allocate axi_hdmi_tx_private To do so embed drm_device in axi_hdmi_tx_private - which is the way to do it today - Do not use ddev->dev_private, it is deprecated - Use dev_err_probe() when you risk to see a PROBE_DEFER - In all include blocks sort the include alphabetically - Use the new interface to drm_bridge_attach() - where display driver creates the connector - See if the Kconfig selects can be trimmed - the framebuffer releated selects looks wrong (others get it wrong too) - Check if you can use the simple encoder - see drm_simple_encoder_init() If this is a simple one plane, one crtc display driver then it should use the drm_simple_* support. Or the changelog should explain why not. We want the drivers as simple as we can - and they shall use as much of the helper infrastructure as they can. We continue to develop the helper infrastructure so it is expected that there is some lacking behind as is the case here. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/tidss: Set bus_format correctly from bridge/connector
When there is a chain of bridges attached to the encoder,
the bus_format should be ideally set from the input format of the
first bridge in the chain.
Use the bridge state to get the negotiated bus_format.
If the bridge does not support format negotiation, error out
and fail.
Signed-off-by: Nikhil Devshatwar
---
drivers/gpu/drm/tidss/tidss_encoder.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_encoder.c
b/drivers/gpu/drm/tidss/tidss_encoder.c
index e278a9c89476..ae7f134754b7 100644
--- a/drivers/gpu/drm/tidss/tidss_encoder.c
+++ b/drivers/gpu/drm/tidss/tidss_encoder.c
@@ -22,6 +22,7 @@ static int tidss_encoder_atomic_check(struct drm_encoder
*encoder,
struct drm_device *ddev = encoder->dev;
struct tidss_crtc_state *tcrtc_state = to_tidss_crtc_state(crtc_state);
struct drm_display_info *di = _state->connector->display_info;
+ struct drm_bridge_state *bstate;
struct drm_bridge *bridge;
bool bus_flags_set = false;
@@ -41,14 +42,19 @@ static int tidss_encoder_atomic_check(struct drm_encoder
*encoder,
break;
}
- if (!di->bus_formats || di->num_bus_formats == 0) {
- dev_err(ddev->dev, "%s: No bus_formats in connected display\n",
- __func__);
+ /* Copy the bus_format from the input_bus_format of first bridge */
+ bridge = drm_bridge_chain_get_first_bridge(encoder);
+ bstate = drm_atomic_get_new_bridge_state(crtc_state->state, bridge);
+ if (bstate)
+ tcrtc_state->bus_format = bstate->input_bus_cfg.format;
+
+ if (tcrtc_state->bus_format == 0 ||
+ tcrtc_state->bus_format == MEDIA_BUS_FMT_FIXED) {
+
+ dev_err(ddev->dev, "Bridge connected to the encoder did not
specify media bus format\n");
return -EINVAL;
}
- // XXX any cleaner way to set bus format and flags?
- tcrtc_state->bus_format = di->bus_formats[0];
if (!bus_flags_set)
tcrtc_state->bus_flags = di->bus_flags;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm: bridge: Propagate the bus flags from bridge->timings
When the next bridge does not specify any bus flags, use the bridge->timings->input_bus_flags as fallback when propagating bus flags from next bridge to current bridge. Signed-off-by: Nikhil Devshatwar --- drivers/gpu/drm/drm_bridge.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index 64f0effb52ac..8353723323ab 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -975,6 +975,13 @@ drm_atomic_bridge_propagate_bus_flags(struct drm_bridge *bridge, * duplicate the "dummy propagation" logic. */ bridge_state->input_bus_cfg.flags = output_flags; + + /* +* Use the bridge->timings->input_bus_flags as fallback if the next bridge +* does not specify the flags +*/ + if (!bridge_state->input_bus_cfg.flags) + bridge_state->input_bus_cfg.flags = bridge->timings->input_bus_flags; } /** -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/bridge: tfp410: Support format negotiation
With new connector model, tfp410 will not create the connector and
SoC driver will rely on format negotiation to setup the encoder format.
Support format negotiations hooks in the drm_bridge_funcs.
Use helper functions for state management.
Support one of the two RGB formats as selected from DT bindings.
Signed-off-by: Nikhil Devshatwar
---
drivers/gpu/drm/bridge/ti-tfp410.c | 32 ++
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index ba3fa2a9b8a4..b65e48e080c7 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -204,12 +204,44 @@ static enum drm_mode_status tfp410_mode_valid(struct
drm_bridge *bridge,
return MODE_OK;
}
+static u32 *tfp410_get_input_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ u32 output_fmt,
+ unsigned int *num_input_fmts)
+{
+ struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ /*
+* This bridge does not support media_bus_format conversion
+* Propagate only if supported
+*/
+ if (output_fmt != dvi->bus_format && output_fmt != MEDIA_BUS_FMT_FIXED)
+ return NULL;
+
+ input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ *num_input_fmts = 1;
+ input_fmts[0] = dvi->bus_format;
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs tfp410_bridge_funcs = {
.attach = tfp410_attach,
.detach = tfp410_detach,
.enable = tfp410_enable,
.disable= tfp410_disable,
.mode_valid = tfp410_mode_valid,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_get_input_bus_fmts = tfp410_get_input_bus_fmts,
};
static const struct drm_bridge_timings tfp410_default_timings = {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/tidss: Move to newer connector model
To be able to support connector operations across multiple
bridges, it is recommended that the connector should be
created by the SoC driver instead of the bridges.
Modify the tidss modesetting initialization sequence to
create the connector and attach bridges with flag
DRM_BRIDGE_ATTACH_NO_CONNECTOR
Signed-off-by: Nikhil Devshatwar
---
drivers/gpu/drm/tidss/tidss_drv.h | 3 +++
drivers/gpu/drm/tidss/tidss_kms.c | 15 ++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.h
b/drivers/gpu/drm/tidss/tidss_drv.h
index 7de4bba52e6f..cfbf85a4d92b 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.h
+++ b/drivers/gpu/drm/tidss/tidss_drv.h
@@ -27,6 +27,9 @@ struct tidss_device {
unsigned int num_planes;
struct drm_plane *planes[TIDSS_MAX_PLANES];
+ unsigned int num_connectors;
+ struct drm_connector *connectors[TIDSS_MAX_PORTS];
+
spinlock_t wait_lock; /* protects the irq masks */
dispc_irq_t irq_mask; /* enabled irqs in addition to wait_list */
};
diff --git a/drivers/gpu/drm/tidss/tidss_kms.c
b/drivers/gpu/drm/tidss/tidss_kms.c
index 09485c7f0d6f..51c24b4a6a21 100644
--- a/drivers/gpu/drm/tidss/tidss_kms.c
+++ b/drivers/gpu/drm/tidss/tidss_kms.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -192,6 +193,7 @@ static int tidss_dispc_modeset_init(struct tidss_device
*tidss)
for (i = 0; i < num_pipes; ++i) {
struct tidss_plane *tplane;
struct tidss_crtc *tcrtc;
+ struct drm_connector *connector;
struct drm_encoder *enc;
u32 hw_plane_id = feat->vid_order[tidss->num_planes];
int ret;
@@ -222,11 +224,22 @@ static int tidss_dispc_modeset_init(struct tidss_device
*tidss)
return PTR_ERR(enc);
}
- ret = drm_bridge_attach(enc, pipes[i].bridge, NULL, 0);
+ ret = drm_bridge_attach(enc, pipes[i].bridge, NULL,
+ DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret) {
dev_err(tidss->dev, "bridge attach failed: %d\n", ret);
return ret;
}
+
+ connector = drm_bridge_connector_init(>ddev, enc);
+ if (IS_ERR(connector)) {
+ dev_err(tidss->dev, "bridge_connector create failed\n");
+ return PTR_ERR(connector);
+ }
+
+ tidss->connectors[tidss->num_connectors++] = connector;
+
+ drm_connector_attach_encoder(connector, enc);
}
/* create overlay planes of the leftover planes */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm/tidss: Use new connector model for tidss
This series moves the tidss to using new connectoe model, where the SoC driver (tidss) creates the connector and all the bridges are attached with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR Since the bridges do not create the connector, the bus format and bus_flag is set after the format negotiation. Support format negotiations in the tfp410 and mhdp bridge drivers. Nikhil Devshatwar (5): drm/tidss: Move to newer connector model drm/tidss: Set bus_format correctly from bridge/connector drm: bridge: Propagate the bus flags from bridge->timings drm/bridge: tfp410: Support format negotiation drm/bridge: mhdp8564: Support format negotiation .../drm/bridge/cadence/cdns-mhdp8546-core.c | 29 + drivers/gpu/drm/bridge/ti-tfp410.c| 32 +++ drivers/gpu/drm/drm_bridge.c | 7 drivers/gpu/drm/tidss/tidss_drv.h | 3 ++ drivers/gpu/drm/tidss/tidss_encoder.c | 16 +++--- drivers/gpu/drm/tidss/tidss_kms.c | 15 - 6 files changed, 96 insertions(+), 6 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/bridge: mhdp8564: Support format negotiation
With new connector model, mhdp bridge will not create the connector and
SoC driver will rely on format negotiation to setup the encoder format.
Support format negotiations hooks in the drm_bridge_funcs.
Support a single format for input.
Signed-off-by: Nikhil Devshatwar
---
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 29 +++
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index d0c65610ebb5..230f6e28f82f 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -2078,6 +2078,34 @@ cdns_mhdp_bridge_atomic_reset(struct drm_bridge *bridge)
return _mhdp_state->base;
}
+static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ u32 output_fmt,
+ unsigned int *num_input_fmts)
+{
+ u32 *input_fmts;
+ u32 default_bus_format = MEDIA_BUS_FMT_RGB121212_1X36;
+
+ *num_input_fmts = 0;
+
+ /*
+* This bridge does not support media_bus_format conversion
+* Propagate only if supported
+*/
+ if (output_fmt != default_bus_format && output_fmt !=
MEDIA_BUS_FMT_FIXED)
+ return NULL;
+
+ input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ *num_input_fmts = 1;
+ input_fmts[0] = default_bus_format;
+ return input_fmts;
+}
+
static int cdns_mhdp_atomic_check(struct drm_bridge *bridge,
struct drm_bridge_state *bridge_state,
struct drm_crtc_state *crtc_state,
@@ -2142,6 +2170,7 @@ static const struct drm_bridge_funcs
cdns_mhdp_bridge_funcs = {
.atomic_duplicate_state = cdns_mhdp_bridge_atomic_duplicate_state,
.atomic_destroy_state = cdns_mhdp_bridge_atomic_destroy_state,
.atomic_reset = cdns_mhdp_bridge_atomic_reset,
+ .atomic_get_input_bus_fmts = cdns_mhdp_get_input_bus_fmts,
.detect = cdns_mhdp_bridge_detect,
.get_edid = cdns_mhdp_bridge_get_edid,
.hpd_enable = cdns_mhdp_bridge_hpd_enable,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/panel: mantix panel reset fixes
Hi Guido. On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote: > > The first patch in this series fixes dereferencing a NULL mode in the error > path. The second one extends the resets to not only reset RESX but also > TP_RSTN > since otherwise the display will stay completely blank. I didn't spot that > before initial submission since the reset line was bound to the touch > controller and although that failed to probe it came far enough to deassert > the > reset line (at an arbitrary point in time during boot) and hence we got a > picture. Since touch and panel are on the same IC they're not completely > independent and i might have to turn the whole thing into an MFD at some point > but this series gets the panel to a reliably working state on boot and on fb > blank/unblank. > > Since the reset-gpios are active low we can deassert in prepare and assert in > unprepare simplifying the code making sure lines are kept low when the > panel is off. > > The binding were not part of a stable kernel so I hope it's okay to not worry > about backward compatibility. > > Changes from v1: > - As per review comments by Fabio Estevam > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/ >- Fix typo in commit messages > - As per review comments by Rob Herring >https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/ >- Don't use an array of reset lines > > Guido Günther (3): > drm/panel: mantix: Don't dereference NULL mode > drm/panel: mantix: Fix panel reset > dt-binding: display: Require two resets on mantix panel All applied to drm-misc-next and pushed out. And then I remembered you had commit right - sigh. Sam > > .../display/panel/mantix,mlaf057we51-x.yaml | 4 +++ > .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 25 +-- > 2 files changed, 21 insertions(+), 8 deletions(-) > > -- > 2.28.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document that user-space should avoid parsing EDIDs
On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote: > On Fri, 9 Oct 2020 17:20:18 +0300 > Ville Syrjälä wrote: > > > On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote: > > > On Fri, 9 Oct 2020 16:10:25 +0300 > > > Ville Syrjälä wrote: > > > > > > > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote: > > > > > Hi, > > > > > > > > > > On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote: > > > > > > > > > > > User-space should avoid parsing EDIDs for metadata already exposed > > > > > > via > > > > > > other KMS interfaces and properties. For instance, user-space > > > > > > should not > > > > > > try to extract a list of modes from the EDID: the kernel might > > > > > > mutate > > > > > > the mode list (because of link capabilities or quirks for instance). > > > > > > > > > > > > Other metadata not exposed by KMS can be parsed by user-space. This > > > > > > includes for instance monitor identification (make/model/serial) and > > > > > > supported color-spaces. > > > > > > > > > > So I take it the only way to get modes is through the connector's list > > > > > of modes. That sounds reasonable enough to me, but I think to properly > > > > > handle colour (e.g. CEA modes have different behaviour for > > > > > limited/full range depending on which VIC they correspond to IIRC) > > > > > > > > If the mode has a VIC and that VIC is not 1, then it's limited range, > > > > otherwise full range. There are fortunately no cases where you would > > > > have the same exact timings corresponding to different quantization > > > > range depending on the VIC. > > > > > > > > And the only reason the same timings could correspond to multiple VICs > > > > is aspect ratio. Which is already exposed via the mode flags, assuming > > > > the appropriate client cap is enabled. > > > > > > > > So I think the only reason to expose the VIC would be if userspace is > > > > non-lazy and wants to manage its colors presicely, but is otherwise lazy > > > > and doesn't want to figure out what the VIC of the mode is on its own. > > > > > > What would "figure out what the VIC of the mode is" require in userspace? > > > > > > A database of all VIC modes and then compare if the detailed timings > > > match? > > > > > > Is that also how the kernel recognises that userspace wants to set a > > > certain VIC mode instead of some arbitrary mode? > > > > Yes and yes. > > > > Note that atm we also don't have a way for userspace to say that it > > wants to signal limited range to the sink but wants the kernel > > to not do the full->limited range conversion. Ie. no way for userspace > > to pass in pixels that are already in limited range. There was a patch > > for that posted quite long ago, but it didn't go in. > > Thanks for the heads-up. > > If userspace uses all available KMS color management properties > (CTM, LUTs, etc.) *and* the video mode implies limited range on the > cable, at what point in the pixel pipeline does that conversion from > full to limited range occur? It should be the last step. There is a slight snag on some Intel platforms that the gamma LUT is sitting after the CSC unit, and currently we use the CSC for the range compression. On glk in particular I *think* we currently just do the wrong thing do the range compression before gamma. The same probably applies to hsw+ when both gamma and degamma are used at the same time. But that is clearly buggy, and we should fix it to either: a) return an error, which isn't super awesome since then you can't do gamma+limited range at the same time on glk, nor gamma+degamma+limited range on hsw+. b) for the glk case we could use the hw degamma LUT for the gamma, which isn't great becasue the hw gamma and degamma LUTs are quite different beasts, and so the hw degamma LUT might not be able to do exactly what we need. On hsw+ we do use this trick already to get the gamma+limited range right, but on these platforms the hw gamma and degamma LUTs have identical capabilities. c) do the range compression with the hw gamma LUT instead, which of course means we have to combine the user gamma and range compression into the same gamma LUT. So I think c) is what it should be. Would just need to find the time to implement it, and figure out how to not totally mess up our driver's hw state checker. Hmm, except this won't help at all with YCbCr output since we need to apply gamma before the RGB->YCbCr conversion (which uses the same CSC again). Argh. So YCbCr output would still need option b). Thankfully icl+ fixed all this by adding a dedicated output CSC unit which sits after the gamma LUT in the pipeline. And pre-hsw is almost fine as well since the hw has a dedicated fixed function thing for the range compression. So the only snag on pre-hsw is the YCbCr+degamma+gamma case. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org
Re: [PATCH 1/2] arm64: dts: qcom: sc7180: Add gpu cooling support
On 10/16/2020 3:49 AM, Matthias Kaehlcke wrote:
Hi,
On Thu, Oct 15, 2020 at 12:07:01AM +0530, man...@codeaurora.org wrote:
On 2020-10-14 18:59, Akhil P Oommen wrote:
On 10/9/2020 10:27 PM, Matthias Kaehlcke wrote:
On Fri, Oct 09, 2020 at 08:05:10AM -0700, Doug Anderson wrote:
Hi,
On Thu, Oct 8, 2020 at 10:10 AM Akhil P Oommen
wrote:
Add cooling-cells property and the cooling maps for the gpu tzones
to support GPU cooling.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 29
++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index d46b383..40d6a28 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2,7 +2,7 @@
/*
* SC7180 SoC device tree source
*
- * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019-20, The Linux Foundation. All rights
reserved.
*/
#include
@@ -1885,6 +1885,7 @@
iommus = <_smmu 0>;
operating-points-v2 = <_opp_table>;
qcom,gmu = <>;
+ #cooling-cells = <2>;
Presumably we should add this to the devicetree bindings, too?
Yes, thanks for catching this. Will update in the next patch.
interconnects = <_noc
MASTER_GFX3D _virt SLAVE_EBI1>;
interconnect-names = "gfx-mem";
@@ -3825,16 +3826,16 @@
};
gpuss0-thermal {
- polling-delay-passive = <0>;
+ polling-delay-passive = <100>;
Why did you make this change? I'm pretty sure that we _don't_ want
this since we're using interrupts for the thermal sensor. See commit
22337b91022d ("arm64: dts: qcom: sc7180: Changed polling mode in
Thermal-zones node").
I was going to ask the same, this shouldn't be needed.
As per our understanding unlike "polling-delay", this delay property is
intended to activate polling thread on post trip threshold violation and it
is irrespective of sensor is capable for trip interrupt or not.
This polling is more of governor related. Below are the few references from
Documentation/code which tells polling-delay-passive is needed for IPA for
better IPA performance.
As per Power allocator documentations
1.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/driver-api/thermal/power_allocator.rst?h=v5.4.71#n264
"The power allocator governor's PID controller works best if there is a
periodic tick. If you have a driver that calls
`thermal_zone_device_update()` (or anything that ends up calling the
governor's `throttle()` function) repetitively, the governor response
won't be very good. Note that this is not particular to this
governor, step-wise will also misbehave if you call its throttle()
faster than the normal thermal framework tick (due to interrupts for
example) as it will overreact"
2. In Power allocator code, when switch_on/control trip temp violation, it
is enabling passive counter to activate passive polling @
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/thermal/power_allocator.c?h=v5.4.71#n634
3. while calculating derivative term, it is using passive_delay @
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/thermal/power_allocator.c?h=v5.4.71#n243
4. Sensor interrupt will work if temperature is fluctuating between
trip_temp and hysteresis. But say a case where we are not enabling
polling-delay-passive. In this case if current temperature > control_temp
trip(2nd passive trip) and
temperature trend is still raising, then sensor high trip will be disabled
(OR configured for critical trip threshold). No more trip interrupt from
sensor until it reaches critical trip or falls below control_temp
hysteresis.
How the governor re-evaluate its next mitigation without passive polling
thread here ?
I think the same is required for CPU thermal zone as well.
Thanks for the explication and pointers!
I ran some tests to re-confirm. For that I lowered the trip point temperatures
of CPU6 to 60/70, to make it easier to trigger throttling without necessarily
affecting the other CPUs. Further I enabled tracing for the events
'thermal_temperature',
'thermal_zone_trip' and 'thermal_power_allocator'. With that I ran a CPU
intensive task on CPU6.
Without polling-delay the trace log looks like this:
irq/40-c263000.-157 [000] 48.035986: thermal_temperature:
thermal_zone=cpu6-thermal id=6 temp_prev=57800 temp=6
irq/40-c263000.-157 [000] 48.036029: thermal_power_allocator_pid:
thermal_zone_id=6 err=1 err_integral=0 p=2402 i=0 d=0 output=1776
irq/40-c263000.-157 [000] 48.036036: thermal_power_allocator:
thermal_zone_id=6 req_power={{0x96}} total_req_power=150
granted_power={{0x6f0}}
Re: [PATCH v4 10/10] drm/fb_helper: Support framebuffers in I/O memory
On Fri, Oct 16, 2020 at 02:19:42PM +0200, Thomas Zimmermann wrote: > Hi > > On Fri, 16 Oct 2020 14:03:47 +0200 Sam Ravnborg wrote: > > > Hi Thomas. > > > > On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote: > > > At least sparc64 requires I/O-specific access to framebuffers. This > > > patch updates the fbdev console accordingly. > > > > > > For drivers with direct access to the framebuffer memory, the callback > > > functions in struct fb_ops test for the type of memory and call the rsp > > > fb_sys_ of fb_cfb_ functions. > > > > > > For drivers that employ a shadow buffer, fbdev's blit function retrieves > > > the framebuffer address as struct dma_buf_map, and uses dma_buf_map > > > interfaces to access the buffer. > > > > > > The bochs driver on sparc64 uses a workaround to flag the framebuffer as > > > I/O memory and avoid a HW exception. With the introduction of struct > > > dma_buf_map, this is not required any longer. The patch removes the rsp > > > code from both, bochs and fbdev. > > > > > > v4: > > > * move dma_buf_map changes into separate patch (Daniel) > > > * TODO list: comment on fbdev updates (Daniel) > > > > > > Signed-off-by: Thomas Zimmermann > > > > The original workaround fixed it so we could run qemu with the > > -nographic option. > > > > So I went ahead and tried to run quemu version: > > v5.0.0-1970-g0b100c8e72-dirty. > > And with the BOCHS driver built-in. > > > > With the following command line: > > qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -nographic > > > > Behaviour was the same before and after applying this patch. > > (panic due to VFS: Unable to mount root fs on unknown-block(0,0)) > > So I consider it fixed for real now and not just a workaround. > > > > I also tested with: > > qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -serial > > stdio > > > > and it worked in both cases too. > > FTR, you booted a kernel and got graphics output. The error is simply that > there was no disk to mount? The short version "Yes". The longer version: With "qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -serial stdio" I got graphical output - one penguin. With "qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -nographic" I got no graphical output, as implied by the -nographic option. But the boot continued - where it would panic before when we accessed IO memory as system memory. In both cases I got an error because I had not specified any rootfs, so qemu failed to mount any rootfs. So expected. Sam > > Best regards > Thomas > > > > > All the comments above so future-me have an easier time finding how to > > reproduce. > > > > Tested-by: Sam Ravnborg > > > > Sam > > > > > --- > > > Documentation/gpu/todo.rst| 19 ++- > > > drivers/gpu/drm/bochs/bochs_kms.c | 1 - > > > drivers/gpu/drm/drm_fb_helper.c | 217 -- > > > include/drm/drm_mode_config.h | 12 -- > > > 4 files changed, 220 insertions(+), 29 deletions(-) > > > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > > index 7e6fc3c04add..638b7f704339 100644 > > > --- a/Documentation/gpu/todo.rst > > > +++ b/Documentation/gpu/todo.rst > > > @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup() > > > > > > > > > Most drivers can use drm_fbdev_generic_setup(). Driver have to implement > > > -atomic modesetting and GEM vmap support. Current generic fbdev emulation > > > -expects the framebuffer in system memory (or system-like memory). > > > +atomic modesetting and GEM vmap support. Historically, generic fbdev > > > emulation +expected the framebuffer in system memory or system-like > > > memory. By employing +struct dma_buf_map, drivers with frambuffers in I/O > > > memory can be supported +as well. > > > > > > Contact: Maintainer of the driver you plan to convert > > > > > > Level: Intermediate > > > > > > +Reimplement functions in drm_fbdev_fb_ops without fbdev > > > +--- > > > + > > > +A number of callback functions in drm_fbdev_fb_ops could benefit from > > > +being rewritten without dependencies on the fbdev module. Some of the > > > +helpers could further benefit from using struct dma_buf_map instead of > > > +raw pointers. > > > + > > > +Contact: Thomas Zimmermann , Daniel Vetter > > > + > > > +Level: Advanced > > > + > > > + > > > drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup > > > - > > > > > > diff --git a/drivers/gpu/drm/bochs/bochs_kms.c > > > b/drivers/gpu/drm/bochs/bochs_kms.c index 13d0d04c4457..853081d186d5 > > > 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c > > > +++ b/drivers/gpu/drm/bochs/bochs_kms.c > > > @@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs) > > >
Re: [PATCH v4 10/10] drm/fb_helper: Support framebuffers in I/O memory
Hi On Fri, 16 Oct 2020 14:03:47 +0200 Sam Ravnborg wrote: > Hi Thomas. > > On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote: > > At least sparc64 requires I/O-specific access to framebuffers. This > > patch updates the fbdev console accordingly. > > > > For drivers with direct access to the framebuffer memory, the callback > > functions in struct fb_ops test for the type of memory and call the rsp > > fb_sys_ of fb_cfb_ functions. > > > > For drivers that employ a shadow buffer, fbdev's blit function retrieves > > the framebuffer address as struct dma_buf_map, and uses dma_buf_map > > interfaces to access the buffer. > > > > The bochs driver on sparc64 uses a workaround to flag the framebuffer as > > I/O memory and avoid a HW exception. With the introduction of struct > > dma_buf_map, this is not required any longer. The patch removes the rsp > > code from both, bochs and fbdev. > > > > v4: > > * move dma_buf_map changes into separate patch (Daniel) > > * TODO list: comment on fbdev updates (Daniel) > > > > Signed-off-by: Thomas Zimmermann > > The original workaround fixed it so we could run qemu with the > -nographic option. > > So I went ahead and tried to run quemu version: > v5.0.0-1970-g0b100c8e72-dirty. > And with the BOCHS driver built-in. > > With the following command line: > qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -nographic > > Behaviour was the same before and after applying this patch. > (panic due to VFS: Unable to mount root fs on unknown-block(0,0)) > So I consider it fixed for real now and not just a workaround. > > I also tested with: > qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -serial > stdio > > and it worked in both cases too. FTR, you booted a kernel and got graphics output. The error is simply that there was no disk to mount? Best regards Thomas > > All the comments above so future-me have an easier time finding how to > reproduce. > > Tested-by: Sam Ravnborg > > Sam > > > --- > > Documentation/gpu/todo.rst| 19 ++- > > drivers/gpu/drm/bochs/bochs_kms.c | 1 - > > drivers/gpu/drm/drm_fb_helper.c | 217 -- > > include/drm/drm_mode_config.h | 12 -- > > 4 files changed, 220 insertions(+), 29 deletions(-) > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > index 7e6fc3c04add..638b7f704339 100644 > > --- a/Documentation/gpu/todo.rst > > +++ b/Documentation/gpu/todo.rst > > @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup() > > > > > > Most drivers can use drm_fbdev_generic_setup(). Driver have to implement > > -atomic modesetting and GEM vmap support. Current generic fbdev emulation > > -expects the framebuffer in system memory (or system-like memory). > > +atomic modesetting and GEM vmap support. Historically, generic fbdev > > emulation +expected the framebuffer in system memory or system-like > > memory. By employing +struct dma_buf_map, drivers with frambuffers in I/O > > memory can be supported +as well. > > > > Contact: Maintainer of the driver you plan to convert > > > > Level: Intermediate > > > > +Reimplement functions in drm_fbdev_fb_ops without fbdev > > +--- > > + > > +A number of callback functions in drm_fbdev_fb_ops could benefit from > > +being rewritten without dependencies on the fbdev module. Some of the > > +helpers could further benefit from using struct dma_buf_map instead of > > +raw pointers. > > + > > +Contact: Thomas Zimmermann , Daniel Vetter > > + > > +Level: Advanced > > + > > + > > drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup > > - > > > > diff --git a/drivers/gpu/drm/bochs/bochs_kms.c > > b/drivers/gpu/drm/bochs/bochs_kms.c index 13d0d04c4457..853081d186d5 > > 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c > > +++ b/drivers/gpu/drm/bochs/bochs_kms.c > > @@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs) > > bochs->dev->mode_config.preferred_depth = 24; > > bochs->dev->mode_config.prefer_shadow = 0; > > bochs->dev->mode_config.prefer_shadow_fbdev = 1; > > - bochs->dev->mode_config.fbdev_use_iomem = true; > > bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = > > true; > > bochs->dev->mode_config.funcs = _mode_funcs; > > diff --git a/drivers/gpu/drm/drm_fb_helper.c > > b/drivers/gpu/drm/drm_fb_helper.c index 6212cd7cde1d..462b0c130ebb 100644 > > --- a/drivers/gpu/drm/drm_fb_helper.c > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > @@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct > > work_struct *work) } > > > > static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper > > *fb_helper, > > - struct drm_clip_rect *clip) > > +
Re: [PATCH v4 10/10] drm/fb_helper: Support framebuffers in I/O memory
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_ops test for the type of memory and call the rsp
> fb_sys_ of fb_cfb_ functions.
>
> For drivers that employ a shadow buffer, fbdev's blit function retrieves
> the framebuffer address as struct dma_buf_map, and uses dma_buf_map
> interfaces to access the buffer.
>
> The bochs driver on sparc64 uses a workaround to flag the framebuffer as
> I/O memory and avoid a HW exception. With the introduction of struct
> dma_buf_map, this is not required any longer. The patch removes the rsp
> code from both, bochs and fbdev.
>
> v4:
> * move dma_buf_map changes into separate patch (Daniel)
> * TODO list: comment on fbdev updates (Daniel)
>
> Signed-off-by: Thomas Zimmermann
The original workaround fixed it so we could run qemu with the
-nographic option.
So I went ahead and tried to run quemu version:
v5.0.0-1970-g0b100c8e72-dirty.
And with the BOCHS driver built-in.
With the following command line:
qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -nographic
Behaviour was the same before and after applying this patch.
(panic due to VFS: Unable to mount root fs on unknown-block(0,0))
So I consider it fixed for real now and not just a workaround.
I also tested with:
qemu-system-sparc64 -m 512 -kernel vmlinux -append console=ttyS0 -serial stdio
and it worked in both cases too.
All the comments above so future-me have an easier time finding how to
reproduce.
Tested-by: Sam Ravnborg
Sam
> ---
> Documentation/gpu/todo.rst| 19 ++-
> drivers/gpu/drm/bochs/bochs_kms.c | 1 -
> drivers/gpu/drm/drm_fb_helper.c | 217 --
> include/drm/drm_mode_config.h | 12 --
> 4 files changed, 220 insertions(+), 29 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 7e6fc3c04add..638b7f704339 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup()
>
>
> Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
> -atomic modesetting and GEM vmap support. Current generic fbdev emulation
> -expects the framebuffer in system memory (or system-like memory).
> +atomic modesetting and GEM vmap support. Historically, generic fbdev
> emulation
> +expected the framebuffer in system memory or system-like memory. By employing
> +struct dma_buf_map, drivers with frambuffers in I/O memory can be supported
> +as well.
>
> Contact: Maintainer of the driver you plan to convert
>
> Level: Intermediate
>
> +Reimplement functions in drm_fbdev_fb_ops without fbdev
> +---
> +
> +A number of callback functions in drm_fbdev_fb_ops could benefit from
> +being rewritten without dependencies on the fbdev module. Some of the
> +helpers could further benefit from using struct dma_buf_map instead of
> +raw pointers.
> +
> +Contact: Thomas Zimmermann , Daniel Vetter
> +
> +Level: Advanced
> +
> +
> drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
> -
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 13d0d04c4457..853081d186d5 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs)
> bochs->dev->mode_config.preferred_depth = 24;
> bochs->dev->mode_config.prefer_shadow = 0;
> bochs->dev->mode_config.prefer_shadow_fbdev = 1;
> - bochs->dev->mode_config.fbdev_use_iomem = true;
> bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
>
> bochs->dev->mode_config.funcs = _mode_funcs;
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 6212cd7cde1d..462b0c130ebb 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct
> work_struct *work)
> }
>
> static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
> - struct drm_clip_rect *clip)
> + struct drm_clip_rect *clip,
> + struct dma_buf_map *dst)
> {
> struct drm_framebuffer *fb = fb_helper->fb;
> unsigned int cpp = fb->format->cpp[0];
> size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
> void *src = fb_helper->fbdev->screen_buffer + offset;
> - void *dst = fb_helper->buffer->map.vaddr + offset;
Re: [PATCH v6 44/80] docs: gpu: i915.rst: Fix several C duplication warnings
On 13/10/2020 14:53, Mauro Carvalho Chehab wrote: As reported by Sphinx: ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_wait_unlocked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1169: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_poll_wait'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1189: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_read'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2669: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_enable'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2734: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_disable'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2820: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_init'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3010: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_read'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3098: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_poll_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3129: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_poll'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3152: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_enable_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3181: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_disable_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3273: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3296: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_destroy_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3321: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_release'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3379: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_open_ioctl_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3534: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'read_properties_unlocked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3717: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_open_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3760: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_register'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3789: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_unregister'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4009: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_add_config_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4162: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_remove_config_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4260: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_init'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4423: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_fini'. With Sphinx 3, C declarations can't be duplicated anymore, so let's exclude those from the other internals found on i915_perf.c file. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Lionel Landwerlin --- Documentation/gpu/i915.rst | 29 + 1 file changed, 25 insertions(+), 4 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 33cc6ddf8f64..cff1f154b473 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -636,15 +636,36 @@ i915 Perf Observation Architecture Stream ..
Re: [PATCH v6 44/80] docs: gpu: i915.rst: Fix several C duplication warnings
On 16/10/2020 14:50, Jani Nikula wrote: On Fri, 16 Oct 2020, Lionel Landwerlin wrote: On 16/10/2020 14:37, Mauro Carvalho Chehab wrote: Em Fri, 16 Oct 2020 14:01:07 +0300 Joonas Lahtinen escreveu: + Lionel Can you please take a look at best resolving the below problem. Maybe we should eliminate the duplicate declarations? Updating such a list manually seems error prone to me. For Kernel 5.10, IMO the best is to apply this patch as-is, as any other thing would need to be postponed, and we want 5.10 free of doc warnings. That's odd... Most of the functions are documented. Is it that we're missing the "()" after the function name maybe? The problem is we first include named functions, and then go on to include everything again, duplicating the documentation for the named functions. BR, Jani. Thanks, now the patch makes sense. -Lionel -Lionel Yet, when I wrote this one, I almost took a different approach: to implement something like @*group (or \*group) directives that exists on doxygen: https://www.doxygen.nl/manual/grouping.html If something like that gets added to kernel-doc syntax, then one could do something like: /** * DOC: some foo description * @group foo */ /** * foo1 - do some foo things * @group foo ... */ /** * foo2 - do some other foo things * @group foo ... */ /** * bar - do bar things * @group bar ... */ And then, at kernel-doc markup: FOO === .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c :group: foo BAR === .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c :group: bar I suspect that something like that would be a lot easier to maintain. Once having someone like that implemented, it should be easy to also have something like this: OTHERS == .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c :export: :not-grouped: in order to pick other functions that aren't grouped. I suspect that implementing something like that at kernel-doc.pl won't be hard. Regards, Mauro Regards, Joonas Quoting Mauro Carvalho Chehab (2020-10-13 14:53:59) As reported by Sphinx: ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_wait_unlocked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1169: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_poll_wait'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1189: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_read'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2669: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_enable'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2734: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_disable'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2820: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_init'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3010: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_read'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3098: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_poll_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3129: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_poll'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3152: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_enable_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3181: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_disable_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3273: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3296: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_destroy_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3321: WARNING: Duplicate C declaration, also defined in
Re: [PATCH v6 44/80] docs: gpu: i915.rst: Fix several C duplication warnings
On 13/10/2020 14:53, Mauro Carvalho Chehab wrote: As reported by Sphinx: ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_wait_unlocked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1169: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_poll_wait'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1189: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_read'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2669: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_enable'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2734: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_disable'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2820: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_init'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3010: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_read'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3098: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_poll_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3129: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_poll'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3152: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_enable_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3181: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_disable_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3273: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3296: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_destroy_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3321: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_release'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3379: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_open_ioctl_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3534: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'read_properties_unlocked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3717: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_open_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3760: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_register'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3789: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_unregister'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4009: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_add_config_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4162: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_remove_config_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4260: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_init'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:4423: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_fini'. With Sphinx 3, C declarations can't be duplicated anymore, so let's exclude those from the other internals found on i915_perf.c file. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Lionel Landwerlin --- Documentation/gpu/i915.rst | 29 + 1 file changed, 25 insertions(+), 4 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 33cc6ddf8f64..cff1f154b473 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -636,15 +636,36 @@ i915 Perf Observation Architecture Stream ..
[Bug 209673] divide_error in amdgpu freezes screen
https://bugzilla.kernel.org/show_bug.cgi?id=209673 cornelius.riemenschnei...@googlemail.com changed: What|Removed |Added Kernel Version|5.8.14-arch1-1 |5.9.0 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209673] divide_error in amdgpu freezes screen
https://bugzilla.kernel.org/show_bug.cgi?id=209673 --- Comment #9 from cornelius.riemenschnei...@googlemail.com --- Created attachment 293037 --> https://bugzilla.kernel.org/attachment.cgi?id=293037=edit crashing dmesg #6 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209673] divide_error in amdgpu freezes screen
https://bugzilla.kernel.org/show_bug.cgi?id=209673 --- Comment #8 from cornelius.riemenschnei...@googlemail.com --- Created attachment 293035 --> https://bugzilla.kernel.org/attachment.cgi?id=293035=edit crashing dmesg #5 I compiled my own 5.9.0 kernel without any arch linux specific patches, and just had two crashes (#5 and 6) within 10 minutes. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 44/80] docs: gpu: i915.rst: Fix several C duplication warnings
On Fri, 16 Oct 2020, Lionel Landwerlin wrote: > On 16/10/2020 14:37, Mauro Carvalho Chehab wrote: >> Em Fri, 16 Oct 2020 14:01:07 +0300 >> Joonas Lahtinen escreveu: >> >>> + Lionel >>> >>> Can you please take a look at best resolving the below problem. >>> >>> Maybe we should eliminate the duplicate declarations? Updating such >>> a list manually seems error prone to me. >> For Kernel 5.10, IMO the best is to apply this patch as-is, as any >> other thing would need to be postponed, and we want 5.10 free of >> doc warnings. > > > That's odd... Most of the functions are documented. Is it that we're > missing the "()" after the function name maybe? The problem is we first include named functions, and then go on to include everything again, duplicating the documentation for the named functions. BR, Jani. > > > -Lionel > > >> >> Yet, when I wrote this one, I almost took a different approach: >> to implement something like @*group (or \*group) directives that >> exists on doxygen: >> >> https://www.doxygen.nl/manual/grouping.html >> >> If something like that gets added to kernel-doc syntax, then >> one could do something like: >> >> /** >> * DOC: some foo description >> * @group foo >> */ >> >> /** >> * foo1 - do some foo things >> * @group foo >> ... >> */ >> >> /** >> * foo2 - do some other foo things >> * @group foo >> ... >> */ >> >> /** >> * bar - do bar things >> * @group bar >> ... >> */ >> >> >> And then, at kernel-doc markup: >> >> FOO >> === >> >> .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c >> :group: foo >> >> >> BAR >> === >> .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c >> :group: bar >> >> >> I suspect that something like that would be a lot easier to maintain. >> >> Once having someone like that implemented, it should be easy to also >> have something like this: >> >> OTHERS >> == >> .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c >> :export: >> :not-grouped: >> >> in order to pick other functions that aren't grouped. >> >> I suspect that implementing something like that at kernel-doc.pl >> won't be hard. >> >> Regards, >> Mauro >> >>> Regards, Joonas >>> >>> Quoting Mauro Carvalho Chehab (2020-10-13 14:53:59) As reported by Sphinx: ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_wait_unlocked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1169: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_poll_wait'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1189: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_read'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2669: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_enable'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2734: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_disable'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2820: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_init'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3010: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_read'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3098: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_poll_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3129: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_poll'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3152: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_enable_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3181: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_disable_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3273: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_ioctl'. ./Documentation/gpu/i915:646:
Re: [PATCH] drm/drm_vblank: use drm_warn_once() to warn undefined mode timing
On Fri, Oct 16, 2020 at 11:30:04AM +0200, Daniel Vetter wrote:
> On Fri, Oct 16, 2020 at 10:54 AM Shawn Guo wrote:
> >
> > On Fri, Oct 16, 2020 at 09:58:46AM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 16, 2020 at 9:13 AM Shawn Guo wrote:
> > > >
> > > > Commit 5caa0feafcc6 ("drm/vblank: Lock down vblank->hwmode more") added
> > > > WARN_ON_ONCE() for atomic drivers to warn the case that vsync is enabled
> > > > before a mode has been set on CRTC. This happens sometimes during the
> > > > initial mode setting of a CRTC. It also happens on Android running HWC2
> > > > backed with drm_hwcomposer, where HWC2::SetVsyncEnabled could be called
> > > > before the atomic mode setting on CRTC happens.
> > > >
> > > > In this case, there is nothing really bad to happen as kernel function
> > > > returns as no-op. So using WARN() version might be overkilled,
> > > > considering some user space crash reporting services may treat kernel
> > > > WARNINGS as crashes. Let's drop WARN_ON_ONCE() and change
> > > > drm_dbg_core()
> > > > to drm_warn_once() for warning undefined mode timing.
> > >
> > > This indicates a bug in your driver. Please fix it there, not by
> > > shutting up the core code complaining about that. Either you're
> > > getting vblank timestamps when the vblank isn't set up yet
> > > (drm_crtc_vblank_on/off) or there's some other race going on in your
> > > driver code resulting in this.
> >
> > Thanks for the comment, Daniel.
> >
> > I'm hitting this warning on an Android running drm_hwcomposer. I'm
> > indeed getting vblank timestamps request before drm_crtc_vblank_on() is
> > called. I'm not sure this is a bug or race condition in the driver
> > code, as both vblank timestamps and on/off requests are coming from user
> > space ioctl for my case. @Sean, that means the problem is in Android
> > drm_hwcomposer code?
>
> vblank request when the crtc is off should be rejected. Most drivers
> got this wrong before I added the required drm_crtc_vblank_reset()
> into atomic helpers in 51f644b40b4b ("drm/atomic-helper: reset vblank
> on crtc reset")
>
> Please make sure you have that, and that drm_crtc_vblank_reset is run
> at driver load time. If the crtc is off, vblank ioctl should be
> rejected. So this is definitely not a userspace bug, still a driver
> bug. In general, userspace is not allowed to do anything that results
> in dmesg spam at normal log levels. Anytime that happens it's a kernel
> bug. And if it's a warning in core code, it's most likely a driver bug
> since the core code tends to be better debugged about these things.
> But there's ofc exceptions.
Indeed! Adding drm_crtc_vblank_reset() into driver crtc reset hook
removes the WARNING for me. Really appreciate your comments, Daniel!
Shawn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 44/80] docs: gpu: i915.rst: Fix several C duplication warnings
On 16/10/2020 14:37, Mauro Carvalho Chehab wrote: Em Fri, 16 Oct 2020 14:01:07 +0300 Joonas Lahtinen escreveu: + Lionel Can you please take a look at best resolving the below problem. Maybe we should eliminate the duplicate declarations? Updating such a list manually seems error prone to me. For Kernel 5.10, IMO the best is to apply this patch as-is, as any other thing would need to be postponed, and we want 5.10 free of doc warnings. That's odd... Most of the functions are documented. Is it that we're missing the "()" after the function name maybe? -Lionel Yet, when I wrote this one, I almost took a different approach: to implement something like @*group (or \*group) directives that exists on doxygen: https://www.doxygen.nl/manual/grouping.html If something like that gets added to kernel-doc syntax, then one could do something like: /** * DOC: some foo description * @group foo */ /** * foo1 - do some foo things * @group foo ... */ /** * foo2 - do some other foo things * @group foo ... */ /** * bar - do bar things * @group bar ... */ And then, at kernel-doc markup: FOO === .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c :group: foo BAR === .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c :group: bar I suspect that something like that would be a lot easier to maintain. Once having someone like that implemented, it should be easy to also have something like this: OTHERS == .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c :export: :not-grouped: in order to pick other functions that aren't grouped. I suspect that implementing something like that at kernel-doc.pl won't be hard. Regards, Mauro Regards, Joonas Quoting Mauro Carvalho Chehab (2020-10-13 14:53:59) As reported by Sphinx: ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_wait_unlocked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1169: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_poll_wait'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1189: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_read'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2669: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_enable'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2734: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_disable'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:2820: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_oa_stream_init'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3010: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_read'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3098: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_poll_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3129: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_poll'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3152: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_enable_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3181: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_disable_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3273: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_ioctl'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3296: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_destroy_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3321: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_release'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3379: WARNING: Duplicate C declaration, also defined in 'gpu/i915'. Declaration is 'i915_perf_open_ioctl_locked'. ./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:3534:
Re: [PATCH v6 44/80] docs: gpu: i915.rst: Fix several C duplication warnings
Em Fri, 16 Oct 2020 14:01:07 +0300 Joonas Lahtinen escreveu: > + Lionel > > Can you please take a look at best resolving the below problem. > > Maybe we should eliminate the duplicate declarations? Updating such > a list manually seems error prone to me. For Kernel 5.10, IMO the best is to apply this patch as-is, as any other thing would need to be postponed, and we want 5.10 free of doc warnings. Yet, when I wrote this one, I almost took a different approach: to implement something like @*group (or \*group) directives that exists on doxygen: https://www.doxygen.nl/manual/grouping.html If something like that gets added to kernel-doc syntax, then one could do something like: /** * DOC: some foo description * @group foo */ /** * foo1 - do some foo things * @group foo ... */ /** * foo2 - do some other foo things * @group foo ... */ /** * bar - do bar things * @group bar ... */ And then, at kernel-doc markup: FOO === .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c :group: foo BAR === .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c :group: bar I suspect that something like that would be a lot easier to maintain. Once having someone like that implemented, it should be easy to also have something like this: OTHERS == .. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c :export: :not-grouped: in order to pick other functions that aren't grouped. I suspect that implementing something like that at kernel-doc.pl won't be hard. Regards, Mauro > > Regards, Joonas > > Quoting Mauro Carvalho Chehab (2020-10-13 14:53:59) > > As reported by Sphinx: > > > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:1147: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_oa_wait_unlocked'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:1169: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_oa_poll_wait'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:1189: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_oa_read'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:2669: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_oa_stream_enable'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:2734: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_oa_stream_disable'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:2820: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_oa_stream_init'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:3010: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_perf_read'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:3098: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_perf_poll_locked'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:3129: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_perf_poll'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:3152: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_perf_enable_locked'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:3181: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_perf_disable_locked'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:3273: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_perf_ioctl'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:3296: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_perf_destroy_locked'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:3321: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_perf_release'. > > ./Documentation/gpu/i915:646: > > ./drivers/gpu/drm/i915/i915_perf.c:3379: WARNING: Duplicate C declaration, > > also defined in 'gpu/i915'. > > Declaration is 'i915_perf_open_ioctl_locked'. > >
Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly
On Fri, Oct 16, 2020 at 12:38 PM Simon Ser wrote: > > > The only thing we support is xrgb. > > > > Signed-off-by: Daniel Vetter > > Cc: Rodrigo Siqueira > > Cc: Melissa Wen > > Cc: Haneen Mohammed > > Cc: Daniel Vetter > > --- > > drivers/gpu/drm/vkms/vkms_drv.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c > > b/drivers/gpu/drm/vkms/vkms_drv.c > > index 726801ab44d4..eb4007443706 100644 > > --- a/drivers/gpu/drm/vkms/vkms_drv.c > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > > @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device > > *vkmsdev) > > dev->mode_config.max_height = YRES_MAX; > > dev->mode_config.cursor_width = 512; > > dev->mode_config.cursor_height = 512; > > - dev->mode_config.preferred_depth = 24; > > + dev->mode_config.preferred_depth = 32; > > Are you sure xrgb's depth is 32 and not 24? Looking at drmdb [1], *all* > drivers set it to 24. Uh there's a problem I think. Depth should indeed stay at 24, the problem is that fb helpers directly take that to be the bpp parameter, which is a different thing. And if you look at how most drivers set up that, they pick 32. I guess I need to revert this here, and unconfuse the fb helpers about depth vs bpp. Maybe best would be to just switch over to preferred drm_fourcc format code, or maybe just pick this up from the first format the primary plane supports. This is all getting slightly tricky and a lot more work :-/ -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 v4 10/10] drm/fb_helper: Support framebuffers in I/O memory
Hi
On Fri, 16 Oct 2020 12:58:54 +0200 Sam Ravnborg wrote:
> Hi Thomas.
>
> On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> > At least sparc64 requires I/O-specific access to framebuffers. This
> > patch updates the fbdev console accordingly.
> >
> > For drivers with direct access to the framebuffer memory, the callback
> > functions in struct fb_ops test for the type of memory and call the rsp
> > fb_sys_ of fb_cfb_ functions.
> >
> > For drivers that employ a shadow buffer, fbdev's blit function retrieves
> > the framebuffer address as struct dma_buf_map, and uses dma_buf_map
> > interfaces to access the buffer.
> >
> > The bochs driver on sparc64 uses a workaround to flag the framebuffer as
> > I/O memory and avoid a HW exception. With the introduction of struct
> > dma_buf_map, this is not required any longer. The patch removes the rsp
> > code from both, bochs and fbdev.
> >
> > v4:
> > * move dma_buf_map changes into separate patch (Daniel)
> > * TODO list: comment on fbdev updates (Daniel)
>
> I have been offline for a while so have not followed all the threads on
> this. So may comments below may well be addressed but I failed to see
> it.
>
> If the point about fb_sync is already addressed/considered then:
> Reviewed-by: Sam Ravnborg
It has not been brought up yet. See below.
>
>
> > Signed-off-by: Thomas Zimmermann
> > ---
> > Documentation/gpu/todo.rst| 19 ++-
> > drivers/gpu/drm/bochs/bochs_kms.c | 1 -
> > drivers/gpu/drm/drm_fb_helper.c | 217 --
> > include/drm/drm_mode_config.h | 12 --
> > 4 files changed, 220 insertions(+), 29 deletions(-)
> >
> > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > index 7e6fc3c04add..638b7f704339 100644
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup()
> >
> >
> > Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
> > -atomic modesetting and GEM vmap support. Current generic fbdev emulation
> > -expects the framebuffer in system memory (or system-like memory).
> > +atomic modesetting and GEM vmap support. Historically, generic fbdev
> > emulation +expected the framebuffer in system memory or system-like
> > memory. By employing +struct dma_buf_map, drivers with frambuffers in I/O
> > memory can be supported +as well.
> >
> > Contact: Maintainer of the driver you plan to convert
> >
> > Level: Intermediate
> >
> > +Reimplement functions in drm_fbdev_fb_ops without fbdev
> > +---
> > +
> > +A number of callback functions in drm_fbdev_fb_ops could benefit from
> > +being rewritten without dependencies on the fbdev module. Some of the
> > +helpers could further benefit from using struct dma_buf_map instead of
> > +raw pointers.
> > +
> > +Contact: Thomas Zimmermann , Daniel Vetter
> > +
> > +Level: Advanced
> > +
> > +
> > drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
> > -
> >
> > diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> > b/drivers/gpu/drm/bochs/bochs_kms.c index 13d0d04c4457..853081d186d5
> > 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c
> > +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> > @@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs)
> > bochs->dev->mode_config.preferred_depth = 24;
> > bochs->dev->mode_config.prefer_shadow = 0;
> > bochs->dev->mode_config.prefer_shadow_fbdev = 1;
> > - bochs->dev->mode_config.fbdev_use_iomem = true;
> > bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order =
> > true;
> > bochs->dev->mode_config.funcs = _mode_funcs;
> Good to see this workaround gone again!
>
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c index 6212cd7cde1d..462b0c130ebb 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct
> > work_struct *work) }
> >
> > static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper
> > *fb_helper,
> > - struct drm_clip_rect *clip)
> > + struct drm_clip_rect *clip,
> > + struct dma_buf_map *dst)
> > {
> > struct drm_framebuffer *fb = fb_helper->fb;
> > unsigned int cpp = fb->format->cpp[0];
> > size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
> > void *src = fb_helper->fbdev->screen_buffer + offset;
> > - void *dst = fb_helper->buffer->map.vaddr + offset;
> > size_t len = (clip->x2 - clip->x1) * cpp;
> > unsigned int y;
> >
> > - for (y = clip->y1; y < clip->y2; y++) {
> > - if (!fb_helper->dev->mode_config.fbdev_use_iomem)
> > -
Re: [PATCH v4 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
>
> Signed-off-by: Thomas Zimmermann
> ---
> include/linux/dma-buf-map.h | 72 +++--
> 1 file changed, 62 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
> index 2e8bbecb5091..6ca0f304dda2 100644
> --- a/include/linux/dma-buf-map.h
> +++ b/include/linux/dma-buf-map.h
> @@ -32,6 +32,14 @@
> * accessing the buffer. Use the returned instance and the helper functions
> * to access the buffer's memory in the correct way.
> *
> + * 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.
> + *
> * 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,
> @@ -51,6 +59,14 @@
> *
> * dma_buf_map_set_vaddr_iomem( 0xdeadbeaf);
> *
> + * 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.
> + *
> + * .. code-block:: c
> + *
> + * dma_buf_map_clear();
> + *
> * Test if a mapping is valid with either dma_buf_map_is_set() or
> * dma_buf_map_is_null().
> *
> @@ -73,17 +89,19 @@
> * if (dma_buf_map_is_equal(_map, _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.
> + * A set up instance of struct dma_buf_map can be used to access or
> manipulate
> + * the buffer memory. Depending on the location of the memory, the provided
> + * helpers will pick the correct operations. Data can be copied into the
> memory
> + * with dma_buf_map_memcpy_to(). The address can be manipulated with
> + * dma_buf_map_incr().
> *
> - * 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.
> + * .. code-block:: c
> + *
> + * const void *src = ...; // source buffer
> + * size_t len = ...; // length of src
> + *
> + * dma_buf_map_memcpy_to(, src, len);
> + * dma_buf_map_incr(, len); // go to first byte after the memcpy
> */
>
> /**
> @@ -210,4 +228,38 @@ static inline void dma_buf_map_clear(struct dma_buf_map
> *map)
> }
> }
>
> +/**
> + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
> + * @dst: The dma-buf mapping structure
> + * @src: The source buffer
> + * @len: The number of byte in src
> + *
> + * Copies data into a dma-buf mapping. The source buffer is in system
> + * memory. Depending on the buffer's location, the helper picks the correct
> + * method of accessing the memory.
> + */
> +static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const void
> *src, size_t len)
> +{
> + if (dst->is_iomem)
> + memcpy_toio(dst->vaddr_iomem, src, len);
> + else
> + memcpy(dst->vaddr, src, len);
sparc64 needs "#include " to build as is does not get
this via io.h
Sam
> +}
> +
> +/**
> + * dma_buf_map_incr - Increments the address stored in a dma-buf mapping
> + * @map: The dma-buf mapping structure
> + * @incr:The number of bytes to increment
> + *
> + * Increments the address stored in a dma-buf mapping. Depending on the
> + * buffer's location, the correct value will be updated.
> + */
> +static inline void dma_buf_map_incr(struct dma_buf_map *map, size_t incr)
> +{
> + if (map->is_iomem)
> + map->vaddr_iomem += incr;
> + else
> + map->vaddr += incr;
> +}
> +
> #endif /* __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 v6 44/80] docs: gpu: i915.rst: Fix several C duplication warnings
+ Lionel Can you please take a look at best resolving the below problem. Maybe we should eliminate the duplicate declarations? Updating such a list manually seems error prone to me. Regards, Joonas Quoting Mauro Carvalho Chehab (2020-10-13 14:53:59) > As reported by Sphinx: > > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:1147: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_oa_wait_unlocked'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:1169: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_oa_poll_wait'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:1189: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_oa_read'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:2669: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_oa_stream_enable'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:2734: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_oa_stream_disable'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:2820: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_oa_stream_init'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:3010: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_read'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:3098: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_poll_locked'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:3129: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_poll'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:3152: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_enable_locked'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:3181: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_disable_locked'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:3273: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_ioctl'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:3296: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_destroy_locked'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:3321: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_release'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:3379: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_open_ioctl_locked'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:3534: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'read_properties_unlocked'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:3717: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_open_ioctl'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:3760: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_register'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:3789: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_unregister'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:4009: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_add_config_ioctl'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:4162: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_remove_config_ioctl'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:4260: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_init'. > ./Documentation/gpu/i915:646: > ./drivers/gpu/drm/i915/i915_perf.c:4423: WARNING: Duplicate C declaration, > also defined in 'gpu/i915'. > Declaration is 'i915_perf_fini'. > > With Sphinx 3, C declarations can't be duplicated anymore, > so let's exclude those from the other internals found on > i915_perf.c file. > > Signed-off-by:
Re: [PATCH v4 10/10] drm/fb_helper: Support framebuffers in I/O memory
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_ops test for the type of memory and call the rsp
> fb_sys_ of fb_cfb_ functions.
>
> For drivers that employ a shadow buffer, fbdev's blit function retrieves
> the framebuffer address as struct dma_buf_map, and uses dma_buf_map
> interfaces to access the buffer.
>
> The bochs driver on sparc64 uses a workaround to flag the framebuffer as
> I/O memory and avoid a HW exception. With the introduction of struct
> dma_buf_map, this is not required any longer. The patch removes the rsp
> code from both, bochs and fbdev.
>
> v4:
> * move dma_buf_map changes into separate patch (Daniel)
> * TODO list: comment on fbdev updates (Daniel)
I have been offline for a while so have not followed all the threads on
this. So may comments below may well be addressed but I failed to see
it.
If the point about fb_sync is already addressed/considered then:
Reviewed-by: Sam Ravnborg
> Signed-off-by: Thomas Zimmermann
> ---
> Documentation/gpu/todo.rst| 19 ++-
> drivers/gpu/drm/bochs/bochs_kms.c | 1 -
> drivers/gpu/drm/drm_fb_helper.c | 217 --
> include/drm/drm_mode_config.h | 12 --
> 4 files changed, 220 insertions(+), 29 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 7e6fc3c04add..638b7f704339 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup()
>
>
> Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
> -atomic modesetting and GEM vmap support. Current generic fbdev emulation
> -expects the framebuffer in system memory (or system-like memory).
> +atomic modesetting and GEM vmap support. Historically, generic fbdev
> emulation
> +expected the framebuffer in system memory or system-like memory. By employing
> +struct dma_buf_map, drivers with frambuffers in I/O memory can be supported
> +as well.
>
> Contact: Maintainer of the driver you plan to convert
>
> Level: Intermediate
>
> +Reimplement functions in drm_fbdev_fb_ops without fbdev
> +---
> +
> +A number of callback functions in drm_fbdev_fb_ops could benefit from
> +being rewritten without dependencies on the fbdev module. Some of the
> +helpers could further benefit from using struct dma_buf_map instead of
> +raw pointers.
> +
> +Contact: Thomas Zimmermann , Daniel Vetter
> +
> +Level: Advanced
> +
> +
> drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
> -
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 13d0d04c4457..853081d186d5 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs)
> bochs->dev->mode_config.preferred_depth = 24;
> bochs->dev->mode_config.prefer_shadow = 0;
> bochs->dev->mode_config.prefer_shadow_fbdev = 1;
> - bochs->dev->mode_config.fbdev_use_iomem = true;
> bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
>
> bochs->dev->mode_config.funcs = _mode_funcs;
Good to see this workaround gone again!
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 6212cd7cde1d..462b0c130ebb 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct
> work_struct *work)
> }
>
> static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
> - struct drm_clip_rect *clip)
> + struct drm_clip_rect *clip,
> + struct dma_buf_map *dst)
> {
> struct drm_framebuffer *fb = fb_helper->fb;
> unsigned int cpp = fb->format->cpp[0];
> size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
> void *src = fb_helper->fbdev->screen_buffer + offset;
> - void *dst = fb_helper->buffer->map.vaddr + offset;
> size_t len = (clip->x2 - clip->x1) * cpp;
> unsigned int y;
>
> - for (y = clip->y1; y < clip->y2; y++) {
> - if (!fb_helper->dev->mode_config.fbdev_use_iomem)
> - memcpy(dst, src, len);
> - else
> - memcpy_toio((void __iomem *)dst, src, len);
> + dma_buf_map_incr(dst, offset); /* go to first pixel within clip rect */
>
> + for (y = clip->y1; y < clip->y2; y++) {
> +
Re: [PATCH] video: fbdev: sh_mobile_lcdcfb: Remove redundant null check before clk_prepare_enable/clk_disable_unprepare
On Thu, 15 Oct 2020 10:10:15 +0200 Thomas Zimmermann
wrote:
> On Wed, 14 Oct 2020 08:57:22 + Xu Wang wrote:
>
> > Because clk_prepare_enable() and clk_disable_unprepare() already checked
> > NULL clock parameter, so the additional checks are unnecessary, just
> > remove them.
> >
> > Signed-off-by: Xu Wang
>
> Reviewed-by: Thomas Zimmermann
>
Merged into drm-misc-next. Thanks!
> > ---
> > drivers/video/fbdev/sh_mobile_lcdcfb.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> > b/drivers/video/fbdev/sh_mobile_lcdcfb.c index c1043420dbd3..c0952cc96bdb
> > 100644 --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> > +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> > @@ -341,8 +341,7 @@ static void lcdc_wait_bit(struct sh_mobile_lcdc_priv
> > *priv, static void sh_mobile_lcdc_clk_on(struct sh_mobile_lcdc_priv *priv)
> > {
> > if (atomic_inc_and_test(>hw_usecnt)) {
> > - if (priv->dot_clk)
> > - clk_prepare_enable(priv->dot_clk);
> > + clk_prepare_enable(priv->dot_clk);
> > pm_runtime_get_sync(priv->dev);
> > }
> > }
> > @@ -351,8 +350,7 @@ static void sh_mobile_lcdc_clk_off(struct
> > sh_mobile_lcdc_priv *priv) {
> > if (atomic_sub_return(1, >hw_usecnt) == -1) {
> > pm_runtime_put(priv->dev);
> > - if (priv->dot_clk)
> > - clk_disable_unprepare(priv->dot_clk);
> > + clk_disable_unprepare(priv->dot_clk);
> > }
> > }
> >
>
>
>
--
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
Hi Sam
On Fri, 16 Oct 2020 12:08:54 +0200 Sam Ravnborg wrote:
> Hi Thomas.
>
> On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> > To do framebuffer updates, one needs memcpy from system memory and a
> > pointer-increment function. Add both interfaces with documentation.
> >
> > Signed-off-by: Thomas Zimmermann
>
> Looks good.
> Reviewed-by: Sam Ravnborg
Thanks. If you have the time, may I ask you to test this patchset on the
bochs/sparc64 system that failed with the original code?
Best regards
Thomas
>
> > ---
> > include/linux/dma-buf-map.h | 72 +++--
> > 1 file changed, 62 insertions(+), 10 deletions(-)
> >
> > diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
> > index 2e8bbecb5091..6ca0f304dda2 100644
> > --- a/include/linux/dma-buf-map.h
> > +++ b/include/linux/dma-buf-map.h
> > @@ -32,6 +32,14 @@
> > * accessing the buffer. Use the returned instance and the helper
> > functions
> > * to access the buffer's memory in the correct way.
> > *
> > + * 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.
> > + *
> > * 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,
> > @@ -51,6 +59,14 @@
> > *
> > * dma_buf_map_set_vaddr_iomem( 0xdeadbeaf);
> > *
> > + * 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.
> > + *
> > + * .. code-block:: c
> > + *
> > + * dma_buf_map_clear();
> > + *
> > * Test if a mapping is valid with either dma_buf_map_is_set() or
> > * dma_buf_map_is_null().
> > *
> > @@ -73,17 +89,19 @@
> > * if (dma_buf_map_is_equal(_map, _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.
> > + * A set up instance of struct dma_buf_map can be used to access or
> > manipulate
> > + * the buffer memory. Depending on the location of the memory, the
> > provided
> > + * helpers will pick the correct operations. Data can be copied into the
> > memory
> > + * with dma_buf_map_memcpy_to(). The address can be manipulated with
> > + * dma_buf_map_incr().
> > *
> > - * 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.
> > + * .. code-block:: c
> > + *
> > + * const void *src = ...; // source buffer
> > + * size_t len = ...; // length of src
> > + *
> > + * dma_buf_map_memcpy_to(, src, len);
> > + * dma_buf_map_incr(, len); // go to first byte after the
> > memcpy */
> >
> > /**
> > @@ -210,4 +228,38 @@ static inline void dma_buf_map_clear(struct
> > dma_buf_map *map) }
> > }
> >
> > +/**
> > + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
> > + * @dst: The dma-buf mapping structure
> > + * @src: The source buffer
> > + * @len: The number of byte in src
> > + *
> > + * Copies data into a dma-buf mapping. The source buffer is in system
> > + * memory. Depending on the buffer's location, the helper picks the
> > correct
> > + * method of accessing the memory.
> > + */
> > +static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const
> > void *src, size_t len) +{
> > + if (dst->is_iomem)
> > + memcpy_toio(dst->vaddr_iomem, src, len);
> > + else
> > + memcpy(dst->vaddr, src, len);
> > +}
> > +
> > +/**
> > + * dma_buf_map_incr - Increments the address stored in a dma-buf mapping
> > + * @map: The dma-buf mapping structure
> > + * @incr: The number of bytes to increment
> > + *
> > + * Increments the address stored in a dma-buf mapping. Depending on the
> > + * buffer's location, the correct value will be updated.
> > + */
> > +static inline void dma_buf_map_incr(struct dma_buf_map *map, size_t incr)
> > +{
> > + if (map->is_iomem)
> > + map->vaddr_iomem += incr;
>
Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly
> The only thing we support is xrgb. > > Signed-off-by: Daniel Vetter > Cc: Rodrigo Siqueira > Cc: Melissa Wen > Cc: Haneen Mohammed > Cc: Daniel Vetter > --- > drivers/gpu/drm/vkms/vkms_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c > index 726801ab44d4..eb4007443706 100644 > --- a/drivers/gpu/drm/vkms/vkms_drv.c > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device *vkmsdev) > dev->mode_config.max_height = YRES_MAX; > dev->mode_config.cursor_width = 512; > dev->mode_config.cursor_height = 512; > - dev->mode_config.preferred_depth = 24; > + dev->mode_config.preferred_depth = 32; Are you sure xrgb's depth is 32 and not 24? Looking at drmdb [1], *all* drivers set it to 24. [1]: https://drmdb.emersion.fr/capabilities > dev->mode_config.helper_private = _mode_config_helpers; > > return vkms_output_init(vkmsdev, 0); > -- > 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly
On 10/15, Daniel Vetter wrote: > On Mon, Oct 12, 2020 at 09:59:22AM -0300, Melissa Wen wrote: > > On 10/10, Daniel Vetter wrote: > > > The only thing we support is xrgb. > > > > > > Signed-off-by: Daniel Vetter > > > Cc: Rodrigo Siqueira > > > Cc: Melissa Wen > > > Cc: Haneen Mohammed > > > Cc: Daniel Vetter > > > --- > > > drivers/gpu/drm/vkms/vkms_drv.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c > > > b/drivers/gpu/drm/vkms/vkms_drv.c > > > index 726801ab44d4..eb4007443706 100644 > > > --- a/drivers/gpu/drm/vkms/vkms_drv.c > > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > > > @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device > > > *vkmsdev) > > > dev->mode_config.max_height = YRES_MAX; > > > dev->mode_config.cursor_width = 512; > > > dev->mode_config.cursor_height = 512; > > > - dev->mode_config.preferred_depth = 24; > > > + dev->mode_config.preferred_depth = 32; > > nice catch! > > > > > dev->mode_config.helper_private = _mode_config_helpers; > > > > > > return vkms_output_init(vkmsdev, 0); > > > -- > > > 2.28.0 > > > > > Thanks, > > > > Reviewed-by: Melissa Wen > > I merged the first 2 patches of this series, but noticed that you didn't > reply with a r-b tag on the 3rd patch. Is that intentional or just > oversight? Hi Daniel, Initially, it was intentional because I was following the feedback and still wanted to check it out better, then I forgot to come back to comment. My fault, but it's done now. Thanks for the touch, Melissa > > Thanks, 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 3/3] drm/vkms: fbdev emulation support
Hi, Thanks for this improvement. I could see that it increased the IGT test coverage, including now the fbdev test cases. On 10/10, Daniel Vetter wrote: > Hooray for generic fbdev support, making this a oneliner. We just > needed to fix preferred_depth fixed and the vmap support added first. I consider that including in the msg that, with this patch, both fbdev test cases [info and mmap] are passing would be interesting for future debugs. > > Signed-off-by: Daniel Vetter > Cc: Rodrigo Siqueira > Cc: Melissa Wen > Cc: Haneen Mohammed > Cc: Daniel Vetter > --- > drivers/gpu/drm/vkms/vkms_drv.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c > index 6221e5040264..cc09e2df5cb1 100644 > --- a/drivers/gpu/drm/vkms/vkms_drv.c > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > @@ -169,6 +169,8 @@ static int __init vkms_init(void) > if (ret) > goto out_devres; > > + drm_fbdev_generic_setup(_device->drm, 0); > + > return 0; > > out_devres: > -- > 2.28.0 > Looks good to me, Reviewed-by: Melissa Wen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
>
> Signed-off-by: Thomas Zimmermann
Looks good.
Reviewed-by: Sam Ravnborg
> ---
> include/linux/dma-buf-map.h | 72 +++--
> 1 file changed, 62 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
> index 2e8bbecb5091..6ca0f304dda2 100644
> --- a/include/linux/dma-buf-map.h
> +++ b/include/linux/dma-buf-map.h
> @@ -32,6 +32,14 @@
> * accessing the buffer. Use the returned instance and the helper functions
> * to access the buffer's memory in the correct way.
> *
> + * 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.
> + *
> * 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,
> @@ -51,6 +59,14 @@
> *
> * dma_buf_map_set_vaddr_iomem( 0xdeadbeaf);
> *
> + * 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.
> + *
> + * .. code-block:: c
> + *
> + * dma_buf_map_clear();
> + *
> * Test if a mapping is valid with either dma_buf_map_is_set() or
> * dma_buf_map_is_null().
> *
> @@ -73,17 +89,19 @@
> * if (dma_buf_map_is_equal(_map, _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.
> + * A set up instance of struct dma_buf_map can be used to access or
> manipulate
> + * the buffer memory. Depending on the location of the memory, the provided
> + * helpers will pick the correct operations. Data can be copied into the
> memory
> + * with dma_buf_map_memcpy_to(). The address can be manipulated with
> + * dma_buf_map_incr().
> *
> - * 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.
> + * .. code-block:: c
> + *
> + * const void *src = ...; // source buffer
> + * size_t len = ...; // length of src
> + *
> + * dma_buf_map_memcpy_to(, src, len);
> + * dma_buf_map_incr(, len); // go to first byte after the memcpy
> */
>
> /**
> @@ -210,4 +228,38 @@ static inline void dma_buf_map_clear(struct dma_buf_map
> *map)
> }
> }
>
> +/**
> + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
> + * @dst: The dma-buf mapping structure
> + * @src: The source buffer
> + * @len: The number of byte in src
> + *
> + * Copies data into a dma-buf mapping. The source buffer is in system
> + * memory. Depending on the buffer's location, the helper picks the correct
> + * method of accessing the memory.
> + */
> +static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const void
> *src, size_t len)
> +{
> + if (dst->is_iomem)
> + memcpy_toio(dst->vaddr_iomem, src, len);
> + else
> + memcpy(dst->vaddr, src, len);
> +}
> +
> +/**
> + * dma_buf_map_incr - Increments the address stored in a dma-buf mapping
> + * @map: The dma-buf mapping structure
> + * @incr:The number of bytes to increment
> + *
> + * Increments the address stored in a dma-buf mapping. Depending on the
> + * buffer's location, the correct value will be updated.
> + */
> +static inline void dma_buf_map_incr(struct dma_buf_map *map, size_t incr)
> +{
> + if (map->is_iomem)
> + map->vaddr_iomem += incr;
> + else
> + map->vaddr += incr;
> +}
> +
> #endif /* __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] omapfb/dss: Remove redundant null check before clk_prepare_enable/clk_disable_unprepare
On Thu, 15 Oct 2020 10:08:27 +0200 Thomas Zimmermann
wrote:
> On Wed, 14 Oct 2020 08:49:20 + Xu Wang wrote:
>
> > Because clk_prepare_enable() and clk_disable_unprepare() already checked
> > NULL clock parameter, so the additional checks are unnecessary, just
> > remove them.
> >
> > Signed-off-by: Xu Wang
>
> Reviewed-by: Thomas Zimmermann
>
Merged into drm-misc-next. Thanks!
> > ---
> > drivers/video/fbdev/omap2/omapfb/dss/venc.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> > b/drivers/video/fbdev/omap2/omapfb/dss/venc.c index
> > 0b0ad20afd63..8895fb8493d8 100644 ---
> > a/drivers/video/fbdev/omap2/omapfb/dss/venc.c +++
> > b/drivers/video/fbdev/omap2/omapfb/dss/venc.c @@ -890,8 +890,7 @@ static
> > int venc_remove(struct platform_device *pdev)
> > static int venc_runtime_suspend(struct device *dev)
> > {
> > - if (venc.tv_dac_clk)
> > - clk_disable_unprepare(venc.tv_dac_clk);
> > + clk_disable_unprepare(venc.tv_dac_clk);
> >
> > dispc_runtime_put();
> >
> > @@ -906,8 +905,7 @@ static int venc_runtime_resume(struct device *dev)
> > if (r < 0)
> > return r;
> >
> > - if (venc.tv_dac_clk)
> > - clk_prepare_enable(venc.tv_dac_clk);
> > + clk_prepare_enable(venc.tv_dac_clk);
> >
> > return 0;
> > }
>
>
>
--
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb/dss: Remove redundant null check before clk_prepare_enable/clk_disable_unprepare
On Thu, 15 Oct 2020 10:08:27 +0200 Thomas Zimmermann
wrote:
> On Wed, 14 Oct 2020 08:49:20 + Xu Wang wrote:
>
> > Because clk_prepare_enable() and clk_disable_unprepare() already checked
> > NULL clock parameter, so the additional checks are unnecessary, just
> > remove them.
> >
> > Signed-off-by: Xu Wang
>
> Reviewed-by: Thomas Zimmermann
>
Merged into drm-misc-next. Thanks!
> > ---
> > drivers/video/fbdev/omap2/omapfb/dss/venc.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> > b/drivers/video/fbdev/omap2/omapfb/dss/venc.c index
> > 0b0ad20afd63..8895fb8493d8 100644 ---
> > a/drivers/video/fbdev/omap2/omapfb/dss/venc.c +++
> > b/drivers/video/fbdev/omap2/omapfb/dss/venc.c @@ -890,8 +890,7 @@ static
> > int venc_remove(struct platform_device *pdev)
> > static int venc_runtime_suspend(struct device *dev)
> > {
> > - if (venc.tv_dac_clk)
> > - clk_disable_unprepare(venc.tv_dac_clk);
> > + clk_disable_unprepare(venc.tv_dac_clk);
> >
> > dispc_runtime_put();
> >
> > @@ -906,8 +905,7 @@ static int venc_runtime_resume(struct device *dev)
> > if (r < 0)
> > return r;
> >
> > - if (venc.tv_dac_clk)
> > - clk_prepare_enable(venc.tv_dac_clk);
> > + clk_prepare_enable(venc.tv_dac_clk);
> >
> > return 0;
> > }
>
>
>
--
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
Am 15.10.20 um 19:52 schrieb Thomas Zimmermann:
Hi
On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter wrote:
On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in
kernel address space. The mapping's address is returned as struct
dma_buf_map. Each function is a simplified version of TTM's existing
kmap code. Both functions respect the memory's location ani/or
writecombine flags.
On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(),
two helpers that convert a GEM object into the TTM BO and forward the
call to TTM's vmap/vunmap. These helpers can be dropped into the rsp
GEM object callbacks.
v4:
* drop ttm_kmap_obj_to_dma_buf() in favor of vmap helpers
(Daniel, Christian)
Bunch of minor comments below, but over all look very solid to me.
Yeah I think just duplicating the ttm bo map stuff for vmap is indeed the
cleanest. And then we can maybe push the combinatorial monster into
vmwgfx, which I think is the only user after this series. Or perhaps a
dedicated set of helpers to map an invidual page (again using the
dma_buf_map stuff).
From a quick look, I'd say it should be possible to have the same interface
for kmap/kunmap as for vmap/vunmap (i.e., parameters are bo and dma-buf-map).
All mapping state can be deduced from this. And struct ttm_bo_kmap_obj can be
killed off entirely.
Yes, that would be rather nice to have.
Thanks,
Christian.
Best regards
Thomas
I'll let Christian with the details, but at a high level this is
definitely
Acked-by: Daniel Vetter
Thanks a lot for doing all this.
-Daniel
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++
drivers/gpu/drm/ttm/ttm_bo_util.c| 72
include/drm/drm_gem_ttm_helper.h | 6 +++
include/drm/ttm/ttm_bo_api.h | 28 +++
include/linux/dma-buf-map.h | 20
5 files changed, 164 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
b/drivers/gpu/drm/drm_gem_ttm_helper.c index 0e4fb9ba43ad..db4c14d78a30
100644 --- a/drivers/gpu/drm/drm_gem_ttm_helper.c
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -49,6 +49,44 @@ void drm_gem_ttm_print_info(struct drm_printer *p,
unsigned int indent, }
EXPORT_SYMBOL(drm_gem_ttm_print_info);
+/**
+ * drm_gem_ttm_vmap() - vmap _buffer_object
+ * @gem: GEM object.
+ * @map: [out] returns the dma-buf mapping.
+ *
+ * Maps a GEM object with ttm_bo_vmap(). This function can be used as
+ * _gem_object_funcs.vmap callback.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int drm_gem_ttm_vmap(struct drm_gem_object *gem,
+struct dma_buf_map *map)
+{
+ struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ return ttm_bo_vmap(bo, map);
+
+}
+EXPORT_SYMBOL(drm_gem_ttm_vmap);
+
+/**
+ * drm_gem_ttm_vunmap() - vunmap _buffer_object
+ * @gem: GEM object.
+ * @map: dma-buf mapping.
+ *
+ * Unmaps a GEM object with ttm_bo_vunmap(). This function can be used
as
+ * _gem_object_funcs.vmap callback.
+ */
+void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
+ struct dma_buf_map *map)
+{
+ struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ ttm_bo_vunmap(bo, map);
+}
+EXPORT_SYMBOL(drm_gem_ttm_vunmap);
+
/**
* drm_gem_ttm_mmap() - mmap _buffer_object
* @gem: GEM object.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c index bdee4df1f3f2..80c42c774c7d
100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -526,6 +527,77 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
}
EXPORT_SYMBOL(ttm_bo_kunmap);
+int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ struct ttm_resource *mem = >mem;
+ int ret;
+
+ ret = ttm_mem_io_reserve(bo->bdev, mem);
+ if (ret)
+ return ret;
+
+ if (mem->bus.is_iomem) {
+ void __iomem *vaddr_iomem;
+ unsigned long size = bo->num_pages << PAGE_SHIFT;
Please use uint64_t here and make sure to cast bo->num_pages before
shifting.
We have an unit tests of allocating a 8GB BO and that should work on a
32bit machine as well :)
+
+ if (mem->bus.addr)
+ vaddr_iomem = (void *)(((u8 *)mem->bus.addr));
+ else if (mem->placement & TTM_PL_FLAG_WC)
I've just nuked the TTM_PL_FLAG_WC flag in drm-misc-next. There is a new
mem->bus.caching enum as replacement.
+ vaddr_iomem = ioremap_wc(mem->bus.offset,
size);
+ else
+ vaddr_iomem = ioremap(mem->bus.offset, size);
+
+ if (!vaddr_iomem)
+ return -ENOMEM;
[Bug 209713] New: amdgpu drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:483 dcn10_get_dig_frontend+0x9e/0xc0 [amdgpu] when resuming from S3 state
https://bugzilla.kernel.org/show_bug.cgi?id=209713 Bug ID: 209713 Summary: amdgpu drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_l ink_encoder.c:483 dcn10_get_dig_frontend+0x9e/0xc0 [amdgpu] when resuming from S3 state Product: Drivers Version: 2.5 Kernel Version: 5.8.13-arch1-1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: s...@lahfa.xyz Regression: No Created attachment 293025 --> https://bugzilla.kernel.org/attachment.cgi?id=293025=edit parts of dmesg where the call trace happens during the resume from S3 sleep state. I'm thinking that this bug is a regression since I haven't seen this call trace before on kernel older than 5.8.12-arch1-1 but I have yet to confirm this. The call trace may also happen only in a very specific way, my current computer has a USB-C Dock that is plugged in and the call trace happened when the USB-C was plugged in and the computer was suspended, then resumed. It is a Lenovo Thinkpad T495 model 20NKS28F00 with an AMD Ryzen 7 3700U and a Vega Radeon RX 10. Further comments will confirm if the call trace happens only when the USB-C Dock is plugged. As well as if this call trace happens on kernels older than 5.8.12-arch1-1. The computer does resume successfully and there is a like a minor screen glitch for a millisecond so it's not a very severe bug. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/drm_vblank: use drm_warn_once() to warn undefined mode timing
On Fri, Oct 16, 2020 at 10:54 AM Shawn Guo wrote:
>
> On Fri, Oct 16, 2020 at 09:58:46AM +0200, Daniel Vetter wrote:
> > On Fri, Oct 16, 2020 at 9:13 AM Shawn Guo wrote:
> > >
> > > Commit 5caa0feafcc6 ("drm/vblank: Lock down vblank->hwmode more") added
> > > WARN_ON_ONCE() for atomic drivers to warn the case that vsync is enabled
> > > before a mode has been set on CRTC. This happens sometimes during the
> > > initial mode setting of a CRTC. It also happens on Android running HWC2
> > > backed with drm_hwcomposer, where HWC2::SetVsyncEnabled could be called
> > > before the atomic mode setting on CRTC happens.
> > >
> > > In this case, there is nothing really bad to happen as kernel function
> > > returns as no-op. So using WARN() version might be overkilled,
> > > considering some user space crash reporting services may treat kernel
> > > WARNINGS as crashes. Let's drop WARN_ON_ONCE() and change drm_dbg_core()
> > > to drm_warn_once() for warning undefined mode timing.
> >
> > This indicates a bug in your driver. Please fix it there, not by
> > shutting up the core code complaining about that. Either you're
> > getting vblank timestamps when the vblank isn't set up yet
> > (drm_crtc_vblank_on/off) or there's some other race going on in your
> > driver code resulting in this.
>
> Thanks for the comment, Daniel.
>
> I'm hitting this warning on an Android running drm_hwcomposer. I'm
> indeed getting vblank timestamps request before drm_crtc_vblank_on() is
> called. I'm not sure this is a bug or race condition in the driver
> code, as both vblank timestamps and on/off requests are coming from user
> space ioctl for my case. @Sean, that means the problem is in Android
> drm_hwcomposer code?
vblank request when the crtc is off should be rejected. Most drivers
got this wrong before I added the required drm_crtc_vblank_reset()
into atomic helpers in 51f644b40b4b ("drm/atomic-helper: reset vblank
on crtc reset")
Please make sure you have that, and that drm_crtc_vblank_reset is run
at driver load time. If the crtc is off, vblank ioctl should be
rejected. So this is definitely not a userspace bug, still a driver
bug. In general, userspace is not allowed to do anything that results
in dmesg spam at normal log levels. Anytime that happens it's a kernel
bug. And if it's a warning in core code, it's most likely a driver bug
since the core code tends to be better debugged about these things.
But there's ofc exceptions.
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
[Bug 209673] divide_error in amdgpu freezes screen
https://bugzilla.kernel.org/show_bug.cgi?id=209673 --- Comment #7 from cornelius.riemenschnei...@googlemail.com --- Created attachment 293011 --> https://bugzilla.kernel.org/attachment.cgi?id=293011=edit crashing dmesg #4 And it crashed again. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/drm_vblank: use drm_warn_once() to warn undefined mode timing
On Fri, Oct 16, 2020 at 09:58:46AM +0200, Daniel Vetter wrote:
> On Fri, Oct 16, 2020 at 9:13 AM Shawn Guo wrote:
> >
> > Commit 5caa0feafcc6 ("drm/vblank: Lock down vblank->hwmode more") added
> > WARN_ON_ONCE() for atomic drivers to warn the case that vsync is enabled
> > before a mode has been set on CRTC. This happens sometimes during the
> > initial mode setting of a CRTC. It also happens on Android running HWC2
> > backed with drm_hwcomposer, where HWC2::SetVsyncEnabled could be called
> > before the atomic mode setting on CRTC happens.
> >
> > In this case, there is nothing really bad to happen as kernel function
> > returns as no-op. So using WARN() version might be overkilled,
> > considering some user space crash reporting services may treat kernel
> > WARNINGS as crashes. Let's drop WARN_ON_ONCE() and change drm_dbg_core()
> > to drm_warn_once() for warning undefined mode timing.
>
> This indicates a bug in your driver. Please fix it there, not by
> shutting up the core code complaining about that. Either you're
> getting vblank timestamps when the vblank isn't set up yet
> (drm_crtc_vblank_on/off) or there's some other race going on in your
> driver code resulting in this.
Thanks for the comment, Daniel.
I'm hitting this warning on an Android running drm_hwcomposer. I'm
indeed getting vblank timestamps request before drm_crtc_vblank_on() is
called. I'm not sure this is a bug or race condition in the driver
code, as both vblank timestamps and on/off requests are coming from user
space ioctl for my case. @Sean, that means the problem is in Android
drm_hwcomposer code?
Shawn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208981] trace with B550I AORUS PRO AX and AMD Ryzen 5 PRO 4650G
https://bugzilla.kernel.org/show_bug.cgi?id=208981 --- Comment #9 from florian.laro...@googlemail.com --- Hello, Am Mi., 14. Okt. 2020 um 11:44 Uhr schrieb : > - Kernel 5.8.14 and 5.9 with mostly Gentoo kernel config > - AMD Ryzen 7 PRO 4750G CPU+iGPU > - ASRock A520M-ITX/ac mainboard + ECC UDIMM memory > > The trace mentioned above disappeared when I updated BIOS (v. 1.20 from > 2020/9/18, it contains AGESA 1.0.8.0). However, I'm still not able to run > ROCm I have updated my motherboard Gigabyte B550I AORUS PRO AX to BIOS F10 from 09/18/2020 with AMD AGESA ComboV2 1.0.8.1. The trace is still present, so this issue is still open for me. > OpenCL (tried various versions, including 3.7 and 3.8), system either hangs, > or > (if the program is killed early) dmesg shows > > Evicting PASID 0x8001 queues > > BTW, clinfo causes GPU resets, and leaves 99% GPU utilization, while dmesg > shows something like > > qcm fence wait loop timeout expired > The cp might be in an unrecoverable state due to an unsuccessful queues > preemption > amdgpu: Failed to evict process queues > amdgpu: Failed to quiesce KFD > amdgpu :07:00.0: amdgpu: GPU reset begin! > [drm] free PSP TMP buffer > amdgpu :07:00.0: amdgpu: GPU reset succeeded, trying to resume > ...(and similarly for kernel 5.9.0) > > It is probably an off-topic, but it seems to be related to amdgpu driver, and > I > don't know how to move forward (and somebody reported that ROCk 3.7 driver > works well with APU Renoir). Seems this is all unrelated to my bug-report. best regards, Florian La Roche -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
