[Bug 112017] [CI][SHARDS]igt@kms_frontbuffer_tracking@* - fail - Failed assertion: drm.bufmgr
https://bugs.freedesktop.org/show_bug.cgi?id=112017 --- Comment #4 from CI Bug Log --- The CI Bug Log issue associated to this bug has been updated. ### New filters associated * TGL: igt@kms_psr@*|igt@gem__* - fail - Failed assertion: data.bufmgr - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3573/fi-tgl-u/igt@kms_psr@primary_mmap_gtt.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3573/fi-tgl-u2/igt@kms_psr@primary_mmap_gtt.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb1/igt@kms_psr@psr2_cursor_mmap_gtt.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb1/igt@gem_render_c...@yf-tiled-ccs-to-y-tiled.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb1/igt@kms_psr@psr2_sprite_plane_move.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb1/igt@kms_...@dpms.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb3/igt@kms_psr@primary_mmap_gtt.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb3/igt@kms_psr@sprite_mmap_cpu.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb3/igt@kms_psr@psr2_sprite_plane_onoff.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb4/igt@kms_psr@psr2_cursor_plane_onoff.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb4/igt@kms_psr@psr2_sprite_mmap_cpu.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb4/igt@kms_...@basic.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb6/igt@kms_psr@psr2_no_drrs.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb6/igt@kms_psr@sprite_mmap_gtt.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb6/igt@gem_media_fill.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb7/igt@gem_render_c...@y-tiled-ccs-to-linear.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5226/shard-tglb7/igt@kms_psr@sprite_render.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3573/shard-tglb3/igt@kms_...@basic.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3574/fi-tgl-u/igt@kms_psr@primary_mmap_gtt.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3574/fi-tgl-u2/igt@kms_psr@primary_mmap_gtt.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3575/fi-tgl-u/igt@kms_psr@primary_mmap_gtt.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3575/fi-tgl-u2/igt@kms_psr@primary_mmap_gtt.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 0/5] DMA-BUF Heaps (destaging ION)
Andrew brought up a reasonable concern with the CMA heap enumeration in the previous patch set, and I had a few other minor cleanups to add, so here is yet another pass at the dma-buf heaps patchset Andrew and I have been working on which tries to destage a fair chunk of ION functionality. The patchset implements per-heap devices which can be opened directly and then an ioctl is used to allocate a dmabuf from the heap. The interface is similar, but much simpler then IONs, only providing an ALLOC ioctl. Also, I've provided relatively simple system and cma heaps. I've booted and tested these patches with AOSP on the HiKey960 using the kernel tree here: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap And the userspace changes here: https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 Compared to ION, this patchset is missing the system-contig, carveout and chunk heaps, as I don't have a device that uses those, so I'm unable to do much useful validation there. Additionally we have no upstream users of chunk or carveout, and the system-contig has been deprecated in the common/andoid-* kernels, so this should be ok. I've also removed the stats accounting, since any such accounting should be implemented by dma-buf core or the heaps themselves. New in v12: * To address Andrew's concern about adding all CMA areas, the CMA heap only adds the default CMA region for now. * Minor cleanups and prep for loading heaps from modules * I have patches to add other specified CMA regions, as well as loading heaps from modules in my WIP tree, which I will submit once this set is queued, here: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap-WIP thanks -john Cc: Laura Abbott Cc: Benjamin Gaignard Cc: Sumit Semwal Cc: Liam Mark Cc: Pratik Patel Cc: Brian Starkey Cc: Vincent Donnefort Cc: Sudipto Paul Cc: Andrew F. Davis Cc: Christoph Hellwig Cc: Chenbo Feng Cc: Alistair Strachan Cc: Hridya Valsaraju Cc: Hillf Danton Cc: dri-devel@lists.freedesktop.org Andrew F. Davis (1): dma-buf: Add dma-buf heaps framework John Stultz (4): dma-buf: heaps: Add heap helpers dma-buf: heaps: Add system heap to dmabuf heaps dma-buf: heaps: Add CMA heap to dmabuf heaps kselftests: Add dma-heap test MAINTAINERS | 18 ++ drivers/dma-buf/Kconfig | 11 + drivers/dma-buf/Makefile | 2 + drivers/dma-buf/dma-heap.c| 271 ++ drivers/dma-buf/heaps/Kconfig | 14 + drivers/dma-buf/heaps/Makefile| 4 + drivers/dma-buf/heaps/cma_heap.c | 178 drivers/dma-buf/heaps/heap-helpers.c | 270 + drivers/dma-buf/heaps/heap-helpers.h | 55 drivers/dma-buf/heaps/system_heap.c | 124 include/linux/dma-heap.h | 59 include/uapi/linux/dma-heap.h | 55 tools/testing/selftests/dmabuf-heaps/Makefile | 9 + .../selftests/dmabuf-heaps/dmabuf-heap.c | 238 +++ 14 files changed, 1308 insertions(+) create mode 100644 drivers/dma-buf/dma-heap.c create mode 100644 drivers/dma-buf/heaps/Kconfig create mode 100644 drivers/dma-buf/heaps/Makefile create mode 100644 drivers/dma-buf/heaps/cma_heap.c create mode 100644 drivers/dma-buf/heaps/heap-helpers.c create mode 100644 drivers/dma-buf/heaps/heap-helpers.h create mode 100644 drivers/dma-buf/heaps/system_heap.c create mode 100644 include/linux/dma-heap.h create mode 100644 include/uapi/linux/dma-heap.h create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 2/5] dma-buf: heaps: Add heap helpers
Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported dmabufs.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Hridya Valsaraju
Cc: Hillf Danton
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Reviewed-by: Brian Starkey
Acked-by: Laura Abbott
Tested-by: Ayan Kumar Halder
Signed-off-by: John Stultz
---
v2:
* Removed cache management performance hack that I had
accidentally folded in.
* Removed stats code that was in helpers
* Lots of checkpatch cleanups
v3:
* Uninline INIT_HEAP_HELPER_BUFFER (suggested by Christoph)
* Switch to WARN on buffer destroy failure (suggested by Brian)
* buffer->kmap_cnt decrementing cleanup (suggested by Christoph)
* Extra buffer->vaddr checking in dma_heap_dma_buf_kmap
(suggested by Brian)
* Switch to_helper_buffer from macro to inline function
(suggested by Benjamin)
* Rename kmap->vmap (folded in from Andrew)
* Use vmap for vmapping - not begin_cpu_access (folded in from
Andrew)
* Drop kmap for now, as its optional (folded in from Andrew)
* Fold dma_heap_map_user into the single caller (foled in from
Andrew)
* Folded in patch from Andrew to track page list per heap not
sglist, which simplifies the tracking logic
v4:
* Moved dma-heap.h change out to previous patch
v6:
* Minor cleanups and typo fixes suggested by Brian
v7:
* Removed stray ;
* Make init_heap_helper_buffer lowercase, as suggested by Christoph
* Add dmabuf export helper to reduce boilerplate code
v8:
* Remove unused private_flags value
* Condense dma_heap_buffer and heap_helper_buffer (suggested by
Christoph)
* Fix indentation by using shorter argument names (suggested by
Christoph)
* Add flush_kernel_vmap_range/invalidate_kernel_vmap_range calls
(suggested by Christoph)
* Checkpatch whitespace fixups
v9:
* Minor cleanups suggested by Brian Starkey
v10:
* Fix missing vmalloc.h inclusion in heap helpers (found by
kbuild test robot )
v12:
* Add symbol exports for heaps as modules
---
drivers/dma-buf/Makefile | 1 +
drivers/dma-buf/heaps/Makefile | 2 +
drivers/dma-buf/heaps/heap-helpers.c | 270 +++
drivers/dma-buf/heaps/heap-helpers.h | 55 ++
4 files changed, 328 insertions(+)
create mode 100644 drivers/dma-buf/heaps/Makefile
create mode 100644 drivers/dma-buf/heaps/heap-helpers.c
create mode 100644 drivers/dma-buf/heaps/heap-helpers.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index caee5eb3d351..9c190026bfab 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -2,6 +2,7 @@
obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
dma-resv.o seqno-fence.o
obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
+obj-$(CONFIG_DMABUF_HEAPS) += heaps/
obj-$(CONFIG_SYNC_FILE)+= sync_file.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
obj-$(CONFIG_UDMABUF) += udmabuf.o
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
new file mode 100644
index ..de49898112db
--- /dev/null
+++ b/drivers/dma-buf/heaps/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-y += heap-helpers.o
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
new file mode 100644
index ..fb9835126893
--- /dev/null
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -0,0 +1,270 @@
+// 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;
+}
+EXPORT_SYMBOL_GPL(init_heap_helper_buffer);
+
+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);
+}
+EXPORT_SYMBOL_GPL(heap_helper_export_dmabuf);
+
+static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
+{
+ void *vaddr;
+
+ vaddr =
[PATCH v12 5/5] kselftests: Add dma-heap test
Add very trivial allocation and import test for dma-heaps,
utilizing the vgem driver as a test importer.
A good chunk of this code taken from:
tools/testing/selftests/android/ion/ionmap_test.c
Originally by Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Hridya Valsaraju
Cc: Hillf Danton
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Reviewed-by: Brian Starkey
Acked-by: Laura Abbott
Tested-by: Ayan Kumar Halder
Signed-off-by: John Stultz
---
v2:
* Switched to use reworked dma-heap apis
v3:
* Add simple mmap
* Utilize dma-buf testdev to test importing
v4:
* Rework to use vgem
* Pass in fd_flags to match interface changes
* Skip . and .. dirs
v6:
* Number of style/cleanups suggested by Brian
v7:
* Whitespace fixup for checkpatch
v8:
* More checkpatch whitespace fixups
v9:
* Better handling error returns out to main, suggested
by Brian Starkey
* Switch to using snprintf, suggested by Brian
---
tools/testing/selftests/dmabuf-heaps/Makefile | 9 +
.../selftests/dmabuf-heaps/dmabuf-heap.c | 238 ++
2 files changed, 247 insertions(+)
create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
b/tools/testing/selftests/dmabuf-heaps/Makefile
new file mode 100644
index ..8c4c36e2972d
--- /dev/null
+++ b/tools/testing/selftests/dmabuf-heaps/Makefile
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
+#LDLIBS += -lrt -lpthread -lm
+
+# these are all "safe" tests that don't modify
+# system time or require escalated privileges
+TEST_GEN_PROGS = dmabuf-heap
+
+include ../lib.mk
diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
new file mode 100644
index ..b36dd9f35c19
--- /dev/null
+++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "../../../../include/uapi/linux/dma-heap.h"
+
+#define DEVPATH "/dev/dma_heap"
+
+static int check_vgem(int fd)
+{
+ drm_version_t version = { 0 };
+ char name[5];
+ int ret;
+
+ version.name_len = 4;
+ version.name = name;
+
+ ret = ioctl(fd, DRM_IOCTL_VERSION, );
+ if (ret)
+ return 0;
+
+ return !strcmp(name, "vgem");
+}
+
+static int open_vgem(void)
+{
+ int i, fd;
+ const char *drmstr = "/dev/dri/card";
+
+ fd = -1;
+ for (i = 0; i < 16; i++) {
+ char name[80];
+
+ snprintf(name, 80, "%s%u", drmstr, i);
+
+ fd = open(name, O_RDWR);
+ if (fd < 0)
+ continue;
+
+ if (!check_vgem(fd)) {
+ close(fd);
+ fd = -1;
+ continue;
+ } else {
+ break;
+ }
+ }
+ return fd;
+}
+
+static int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
+{
+ struct drm_prime_handle import_handle = {
+ .fd = dma_buf_fd,
+ .flags = 0,
+ .handle = 0,
+};
+ int ret;
+
+ ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, _handle);
+ if (ret == 0)
+ *handle = import_handle.handle;
+ return ret;
+}
+
+static void close_handle(int vgem_fd, uint32_t handle)
+{
+ struct drm_gem_close close = {
+ .handle = handle,
+ };
+
+ ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, );
+}
+
+static int dmabuf_heap_open(char *name)
+{
+ int ret, fd;
+ char buf[256];
+
+ ret = snprintf(buf, 256, "%s/%s", DEVPATH, name);
+ if (ret < 0) {
+ printf("snprintf failed!\n");
+ return ret;
+ }
+
+ fd = open(buf, O_RDWR);
+ if (fd < 0)
+ printf("open %s failed!\n", buf);
+ return fd;
+}
+
+static int dmabuf_heap_alloc(int fd, size_t len, unsigned int flags,
+int *dmabuf_fd)
+{
+ struct dma_heap_allocation_data data = {
+ .len = len,
+ .fd_flags = O_RDWR | O_CLOEXEC,
+ .heap_flags = flags,
+ };
+ int ret;
+
+ if (!dmabuf_fd)
+ return -EINVAL;
+
+ ret = ioctl(fd, DMA_HEAP_IOC_ALLOC, );
+ if (ret < 0)
+ return ret;
+ *dmabuf_fd = (int)data.fd;
+ return ret;
+}
+
+static void dmabuf_sync(int fd, int start_stop)
+{
+ struct dma_buf_sync sync = {
+
[PATCH v12 3/5] dma-buf: heaps: Add system heap to dmabuf heaps
This patch adds system heap to the dma-buf heaps framework.
This allows applications to get a page-allocator backed dma-buf
for non-contiguous memory.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Hridya Valsaraju
Cc: Hillf Danton
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Reviewed-by: Brian Starkey
Acked-by: Laura Abbott
Tested-by: Ayan Kumar Halder
Signed-off-by: John Stultz
---
v2:
* Switch allocate to return dmabuf fd
* Simplify init code
* Checkpatch fixups
* Droped dead system-contig code
v3:
* Whitespace fixups from Benjamin
* Make sure we're zeroing the allocated pages (from Liam)
* Use PAGE_ALIGN() consistently (suggested by Brian)
* Fold in new registration style from Andrew
* Avoid needless dynamic allocation of sys_heap (suggested by
Christoph)
* Minor cleanups
* Folded in changes from Andrew to use simplified page list
from the heap helpers
v4:
* Optimization to allocate pages in chunks, similar to old
pagepool code
* Use fd_flags when creating dmabuf fd (Suggested by Benjamin)
v5:
* Back out large order page allocations (was leaking memory,
as the page array didn't properly track order size)
v6:
* Minor whitespace change suggested by Brian
* Remove unused variable
v7:
* Use newly lower-cased init_heap_helper_buffer helper
* Add system heap DOS avoidance suggested by Laura from ION code
* Use new dmabuf export helper
v8:
* Make struct dma_heap_ops consts (suggested by Christoph)
* Get rid of needless struct system_heap (suggested by Christoph)
* Condense dma_heap_buffer and heap_helper_buffer (suggested by
Christoph)
* Add forgotten include file to fix build issue on x86
v12:
* Minor tweaks to prep loading heap from module
---
drivers/dma-buf/Kconfig | 2 +
drivers/dma-buf/heaps/Kconfig | 6 ++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/system_heap.c | 124
4 files changed, 133 insertions(+)
create mode 100644 drivers/dma-buf/heaps/Kconfig
create mode 100644 drivers/dma-buf/heaps/system_heap.c
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index bffa58fc3e6e..0613bb7770f5 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -53,4 +53,6 @@ menuconfig DMABUF_HEAPS
allows userspace to allocate dma-bufs that can be shared
between drivers.
+source "drivers/dma-buf/heaps/Kconfig"
+
endmenu
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
new file mode 100644
index ..205052744169
--- /dev/null
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -0,0 +1,6 @@
+config DMABUF_HEAPS_SYSTEM
+ bool "DMA-BUF System Heap"
+ depends on DMABUF_HEAPS
+ help
+ Choose this option to enable the system dmabuf heap. The system heap
+ is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index de49898112db..d1808eca2581 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += heap-helpers.o
+obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
new file mode 100644
index ..455782efbb32
--- /dev/null
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF System heap exporter
+ *
+ * Copyright (C) 2011 Google, Inc.
+ * Copyright (C) 2019 Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "heap-helpers.h"
+
+struct dma_heap *sys_heap;
+
+static void system_heap_free(struct heap_helper_buffer *buffer)
+{
+ pgoff_t pg;
+
+ for (pg = 0; pg < buffer->pagecount; pg++)
+ __free_page(buffer->pages[pg]);
+ kfree(buffer->pages);
+ kfree(buffer);
+}
+
+static int system_heap_allocate(struct dma_heap *heap,
+ unsigned long len,
+ unsigned long fd_flags,
+ unsigned long heap_flags)
+{
+ struct heap_helper_buffer *helper_buffer;
+ struct dma_buf *dmabuf;
+ int ret = -ENOMEM;
+ pgoff_t pg;
+
+ helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
+ if (!helper_buffer)
+ return -ENOMEM;
+
+ init_heap_helper_buffer(helper_buffer, system_heap_free);
+ helper_buffer->flags = heap_flags;
+
[PATCH v12 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
This adds a CMA heap, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.
This code is an evolution of the Android ION implementation, so
thanks to its original author and maintainters:
Benjamin Gaignard, Laura Abbott, and others!
NOTE: This patch only adds the default CMA heap. We will enable
selectively adding other CMA memory regions to the dmabuf heaps
interface with a later patch (which requires a dt binding)
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Hridya Valsaraju
Cc: Hillf Danton
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Reviewed-by: Brian Starkey
Acked-by: Laura Abbott
Tested-by: Ayan Kumar Halder
Signed-off-by: John Stultz
---
v2:
* Switch allocate to return dmabuf fd
* Simplify init code
* Checkpatch fixups
v3:
* Switch to inline function for to_cma_heap()
* Minor cleanups suggested by Brian
* Fold in new registration style from Andrew
* Folded in changes from Andrew to use simplified page list
from the heap helpers
v4:
* Use the fd_flags when creating dmabuf fd (Suggested by
Benjamin)
* Use precalculated pagecount (Suggested by Andrew)
v6:
* Changed variable names to improve clarity, as suggested
by Brian
v7:
* Use newly lower-cased init_heap_helper_buffer helper
* Use new dmabuf export helper
v8:
* Make struct dma_heap_ops const (Suggested by Christoph)
* Condense dma_heap_buffer and heap_helper_buffer (suggested by
Christoph)
* Checkpatch whitespace fixups
v9:
* Removing needless check noted by Brian Starkey
* Rename dma_heap_get_data->dma_heap_get_drvdata suggested
by Hilf Danton
* Check signals after clearing memory pages to avoid doing
needless work if the task is killed as suggested by Hilf
v12:
* Rework to only add the default CMA heap
---
drivers/dma-buf/heaps/Kconfig| 8 ++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/cma_heap.c | 178 +++
3 files changed, 187 insertions(+)
create mode 100644 drivers/dma-buf/heaps/cma_heap.c
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 205052744169..a5eef06c4226 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -4,3 +4,11 @@ config DMABUF_HEAPS_SYSTEM
help
Choose this option to enable the system dmabuf heap. The system heap
is backed by pages from the buddy allocator. If in doubt, say Y.
+
+config DMABUF_HEAPS_CMA
+ bool "DMA-BUF CMA Heap"
+ depends on DMABUF_HEAPS && DMA_CMA
+ help
+ Choose this option to enable dma-buf CMA heap. This heap is backed
+ by the Contiguous Memory Allocator (CMA). If your system has these
+ regions, you should say Y here.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index d1808eca2581..6e54cdec3da0 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
# 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/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
new file mode 100644
index ..064926b5d735
--- /dev/null
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF CMA heap exporter
+ *
+ * Copyright (C) 2012, 2019 Linaro Ltd.
+ * Author: for ST-Ericsson.
+ */
+
+#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 *cma_heap = dma_heap_get_drvdata(buffer->heap);
+ unsigned long nr_pages = buffer->pagecount;
+ struct page *cma_pages = buffer->priv_virt;
+
+ /* free page list */
+ kfree(buffer->pages);
+ /* release memory */
+ cma_release(cma_heap->cma, cma_pages, nr_pages);
+ kfree(buffer);
+}
+
+/* dmabuf heap CMA operations functions */
+static int cma_heap_allocate(struct dma_heap *heap,
+unsigned long len,
+unsigned long fd_flags,
+unsigned long heap_flags)
+{
+ struct cma_heap *cma_heap = dma_heap_get_drvdata(heap);
+ struct heap_helper_buffer *helper_buffer;
+ struct page *cma_pages;
+ size_t size = PAGE_ALIGN(len);
+ unsigned long nr_pages = size >> PAGE_SHIFT;
+ unsigned long align = get_order(size);
+ struct dma_buf *dmabuf;
+ int ret = -ENOMEM;
+ pgoff_t pg;
+
+ if (align >
[PATCH v12 1/5] dma-buf: Add dma-buf heaps framework
From: "Andrew F. Davis" This framework allows a unified userspace interface for dma-buf exporters, allowing userland to allocate specific types of memory for use in dma-buf sharing. Each heap is given its own device node, which a user can allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. This code is an evoluiton of the Android ION implementation, and a big thanks is due to its authors/maintainers over time for their effort: Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard, Laura Abbott, and many other contributors! Cc: Laura Abbott Cc: Benjamin Gaignard Cc: Sumit Semwal Cc: Liam Mark Cc: Pratik Patel Cc: Brian Starkey Cc: Vincent Donnefort Cc: Sudipto Paul Cc: Andrew F. Davis Cc: Christoph Hellwig Cc: Chenbo Feng Cc: Alistair Strachan Cc: Hridya Valsaraju Cc: Hillf Danton Cc: dri-devel@lists.freedesktop.org Reviewed-by: Benjamin Gaignard Reviewed-by: Brian Starkey Acked-by: Laura Abbott Tested-by: Ayan Kumar Halder Signed-off-by: Andrew F. Davis Signed-off-by: John Stultz --- v2: * Folded down fixes I had previously shared in implementing heaps * Make flags a u64 (Suggested by Laura) * Add PAGE_ALIGN() fix to the core alloc funciton * IOCTL fixups suggested by Brian * Added fixes suggested by Benjamin * Removed core stats mgmt, as that should be implemented by per-heap code * Changed alloc to return a dma-buf fd, rather than a buffer (as it simplifies error handling) v3: * Removed scare-quotes in MAINTAINERS email address * Get rid of .release function as it didn't do anything (from Christoph) * Renamed filp to file (suggested by Christoph) * Split out ioctl handling to separate function (suggested by Christoph) * Add comment documenting PAGE_ALIGN usage (suggested by Brian) * Switch from idr to Xarray (suggested by Brian) * Fixup cdev creation (suggested by Brian) * Avoid EXPORT_SYMBOL until we finalize modules (suggested by Brian) * Make struct dma_heap internal only (folded in from Andrew) * Small cleanups suggested by GregKH * Provide class->devnode callback to get consistent /dev/ subdirectory naming (Suggested by Bjorn) v4: * Folded down dma-heap.h change that was in a following patch * Added fd_flags entry to allocation structure and pass it through to heap code for use on dma-buf fd creation (suggested by Benjamin) v5: * Minor cleanups v6: * Improved error path handling, minor whitespace fixes, both suggested by Brian v7: * Longer Kconfig description to quiet checkpatch warnings * Re-add compat_ioctl bits (Hridya noticed 32bit userland wasn't working) v8: * Make struct dma_heap_ops consts (Suggested by Christoph) * Checkpatch whitespace fixups v9: * Minor cleanups suggested by Brian Starkey * Rename dma_heap_get_data->dma_heap_get_drvdata suggested by Hilf Danton v11: * Kconfig text improvements suggested by Randy Dunlap v12: * Add logic to prevent duplicately named heaps being added * Add symbol exports for heaps as modules --- MAINTAINERS | 18 +++ drivers/dma-buf/Kconfig | 9 ++ drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-heap.c| 271 ++ include/linux/dma-heap.h | 59 include/uapi/linux/dma-heap.h | 55 +++ 6 files changed, 413 insertions(+) create mode 100644 drivers/dma-buf/dma-heap.c create mode 100644 include/linux/dma-heap.h create mode 100644 include/uapi/linux/dma-heap.h diff --git a/MAINTAINERS b/MAINTAINERS index a69e6db80c79..591c4c484558 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4939,6 +4939,24 @@ F: include/linux/*fence.h F: Documentation/driver-api/dma-buf.rst T: git git://anongit.freedesktop.org/drm/drm-misc +DMA-BUF HEAPS FRAMEWORK +M: Sumit Semwal +R: Andrew F. Davis +R: Benjamin Gaignard +R: Liam Mark +R: Laura Abbott +R: Brian Starkey +R: John Stultz +S: Maintained +L: linux-me...@vger.kernel.org +L: dri-devel@lists.freedesktop.org +L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) +F: include/uapi/linux/dma-heap.h +F: include/linux/dma-heap.h +F: drivers/dma-buf/dma-heap.c +F: drivers/dma-buf/heaps/* +T: git git://anongit.freedesktop.org/drm/drm-misc + DMA GENERIC OFFLOAD ENGINE SUBSYSTEM M: Vinod Koul L: dmaeng...@vger.kernel.org diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index a23b6752d11a..bffa58fc3e6e 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -44,4 +44,13 @@ config DMABUF_SELFTESTS default n depends on DMA_SHARED_BUFFER +menuconfig DMABUF_HEAPS + bool "DMA-BUF Userland Memory Heaps" + select DMA_SHARED_BUFFER + help + Choose this option to enable the DMA-BUF userland memory heaps. + This options creates per heap chardevs in /dev/dma_heap/ which + allows userspace to allocate dma-bufs that can be shared + between drivers. + endmenu diff --git a/drivers/dma-buf/Makefile
[PATCH] gma/gma500: fix a memory disclosure bug due to uninitialized bytes
`best_clock` is an object that may be sent out. Object `clock`
contains uninitialized bytes that are copied to `best_clock`,
which leads to memory disclosure and information leak.
Signed-off-by: Kangjie Lu
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index f56852a503e8..8b784947ed3b 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -405,6 +405,8 @@ static bool cdv_intel_find_dp_pll(const struct gma_limit_t
*limit,
struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
struct gma_clock_t clock;
+ memset(, 0, sizeof(clock));
+
switch (refclk) {
case 27000:
if (target < 20) {
--
2.17.1
Re: [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic
On 2019-10-17 19:00, Lee Jones wrote:
On Thu, 17 Oct 2019, kgu...@codeaurora.org wrote:
On 2019-10-17 17:56, Lee Jones wrote:
> On Wed, 16 Oct 2019, Kiran Gunda wrote:
>
> > The auto string detection algorithm checks if the current WLED
> > sink configuration is valid. It tries enabling every sink and
> > checks if the OVP fault is observed. Based on this information
> > it detects and enables the valid sink configuration.
> > Auto calibration will be triggered when the OVP fault interrupts
> > are seen frequently thereby it tries to fix the sink configuration.
> >
> > The auto-detection also kicks in when the connected LED string
> > of the display-backlight malfunctions (because of damage) and
> > requires the damaged string to be turned off to prevent the
> > complete panel and/or board from being damaged.
> >
> > Signed-off-by: Kiran Gunda
> > ---
> > drivers/video/backlight/qcom-wled.c | 410
> > +++-
> > 1 file changed, 404 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/video/backlight/qcom-wled.c
> > b/drivers/video/backlight/qcom-wled.c
> > index b5b125c..ff7c409 100644
> > --- a/drivers/video/backlight/qcom-wled.c
> > +++ b/drivers/video/backlight/qcom-wled.c
[...]
> > + if (int_sts & WLED3_CTRL_REG_OVP_FAULT_STATUS)
> > + dev_dbg(wled->dev, "WLED OVP fault detected with SINK
%d\n",
> > + i + 1);
>
> I haven't reviewed the whole patch, but this caught my eye.
>
> I think this should be upgraded to dev_warn().
>
Thought of keeping these messages silent, Because the string
configuration
will be corrected in this
and informing it at end of the auto string detection.
[...]
> > + } else {
> > + dev_warn(wled->dev, "New WLED string configuration found
%x\n",
> > + sink_valid);
>
> Why would the user care about this? Is it not normal?
>
Actually, it comes here if the user provided string configuration in
the
device tree is in-correct.
That's why just informing the user about the right string
configuration,
after the auto string detection.
Then I think we need to be more forthcoming. Tell the user the
configuration is incorrect and what you've done to rectify it.
"XXX is not a valid configuration - using YYY instead"
Sure. Will update it in the next series.
[...]
> > +static int wled_configure_ovp_irq(struct wled *wled,
> > + struct platform_device *pdev)
> > +{
> > + int rc;
> > + u32 val;
> > +
> > + wled->ovp_irq = platform_get_irq_byname(pdev, "ovp");
> > + if (wled->ovp_irq < 0) {
> > + dev_dbg(>dev, "ovp irq is not used\n");
>
> I assume this is optional. What happens if no IRQ is provided?
>
Here OVP IRQ is used to detect the wrong string detection. If it is
not
provided the auto string detection logic won't work.
"OVP IRQ not found - disabling automatic string detection"
Sure. Will update it in the next series.
> If, for instance, polling mode is enabled, maybe something like this
> would be better?
>
> dev_warn(>dev, "No IRQ found, falling back to polling
> mode\n");
[PATCH] drm/gma500: fix memory disclosures due to uninitialized bytes
"clock" may be copied to "best_clock". Initializing best_clock
is not sufficient. The fix initializes clock as well to avoid
memory disclosures and informaiton leaks.
Signed-off-by: Kangjie Lu
---
drivers/gpu/drm/gma500/oaktrail_crtc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c
b/drivers/gpu/drm/gma500/oaktrail_crtc.c
index 167c10767dd4..900e5499249d 100644
--- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
+++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
@@ -129,6 +129,7 @@ static bool mrst_sdvo_find_best_pll(const struct
gma_limit_t *limit,
s32 freq_error, min_error = 10;
memset(best_clock, 0, sizeof(*best_clock));
+ memset(, 0, sizeof(clock));
for (clock.m = limit->m.min; clock.m <= limit->m.max; clock.m++) {
for (clock.n = limit->n.min; clock.n <= limit->n.max;
@@ -185,6 +186,7 @@ static bool mrst_lvds_find_best_pll(const struct
gma_limit_t *limit,
int err = target;
memset(best_clock, 0, sizeof(*best_clock));
+ memset(, 0, sizeof(clock));
for (clock.m = limit->m.min; clock.m <= limit->m.max; clock.m++) {
for (clock.p1 = limit->p1.min; clock.p1 <= limit->p1.max;
--
2.17.1
radeon backtrace on fedora 31
5.3.4-300.fc31.x86_64 seems to be new. https://retrace.fedoraproject.org/faf/reports/2726149/ Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.4-rc4
The pull request you sent on Fri, 18 Oct 2019 06:53:55 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-10-18 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/839e0f04b50441d1f6593070b574b7933e903c7c Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote: > On 10/17/19 3:14 PM, John Stultz wrote: > > But if the objection stands, do you have a proposal for an alternative > > way to enumerate a subset of CMA heaps? > > > When in staging ION had to reach into the CMA framework as the other > direction would not be allowed, so cma_for_each_area() was added. If > DMA-BUF heaps is not in staging then we can do the opposite, and have > the CMA framework register heaps itself using our framework. That way > the CMA system could decide what areas to export or not (maybe based on > a DT property or similar). Ok. Though the CMA core doesn't have much sense of DT details either, so it would probably have to be done in the reserved_mem logic, which doesn't feel right to me. I'd probably guess we should have some sort of dt binding to describe a dmabuf cma heap and from that node link to a CMA node via a memory-region phandle. Along with maybe the default heap as well? Not eager to get into another binding review cycle, and I'm not sure what non-DT systems will do yet, but I'll take a shot at it and iterate. > The end result is the same so we can make this change later (it has to > come after DMA-BUF heaps is in anyway). Well, I'm hesitant to merge code that exposes all the CMA heaps and then add patches that becomes more selective, should anyone depend on the initial behavior. :/ So, , I'll start on the rework for the CMA bits. That said, I'm definitely wanting to make some progress on this patch series, so maybe we can still merge the core/helpers/system heap and just hold the cma heap for a rework on the enumeration bits. That way we can at least get other folks working on switching their vendor heaps from ION. Sumit: Does that sound ok? Assuming no other objections, can you take the v11 set minus the CMA heap patch? thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.4-rc4
Hey Linus, This is this weeks fixes for drm, the dma-resv one is probably the more important one a fair few people have reported it, besides that it's a couple of panfrost, a few i915 and a few amdgpu fixes. One radeon patch to fix some ppc64 related issues caused an x86 regression so is getting reverted for now. Thanks, Dave. drm-fixes-2019-10-18: drm fixes for 5.4-rc4 dma-resv: - shared fences for lima/panfrost ttm: - prefault regression fix - lifetime fix panfrost: - stopped job timeout fix - missing register values amdgpu: - smu7 powerplay fix - bail earlier for cik/si detection - navi SDMA fix radeon: - revert a ppc64 shutdown fix that broke x86 i915: - VBT information handling fix - Circular locking fix - preemption vs resubmission virtual requests fix The following changes since commit 4f5cafb5cb8471e54afdc9054d973535614f7675: Linux 5.4-rc3 (2019-10-13 16:37:36 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-10-18 for you to fetch changes up to 5c1e34b5159ec65bf33e2c1a62fa7158132c10cf: Merge tag 'drm-misc-fixes-2019-10-17' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2019-10-18 06:40:28 +1000) drm fixes for 5.4-rc4 dma-resv: - shared fences for lima/panfrost ttm: - prefault regression fix - lifetime fix panfrost: - stopped job timeout fix - missing register values amdgpu: - smu7 powerplay fix - bail earlier for cik/si detection - navi SDMA fix radeon: - revert a ppc64 shutdown fix that broke x86 i915: - VBT information handling fix - Circular locking fix - preemption vs resubmission virtual requests fix Alex Deucher (2): drm/amdgpu/powerplay: fix typo in mvdd table setup Revert "drm/radeon: Fix EEH during kexec" Chris Wilson (3): drm/i915/execlists: Refactor -EIO markup of hung requests drm/i915/userptr: Never allow userptr into the mappable GGTT drm/i915: Fixup preempt-to-busy vs resubmission of a virtual request Christian König (2): drm/ttm: fix busy reference in ttm_mem_evict_first drm/ttm: fix handling in ttm_bo_add_mem_to_lru Dave Airlie (3): Merge tag 'drm-intel-fixes-2019-10-17' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-fixes-5.4-2019-10-16' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-misc-fixes-2019-10-17' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Hans de Goede (1): drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1 Jeffrey Hugo (1): drm/msm/dsi: Implement reset correctly Kai-Heng Feng (1): drm/edid: Add 6 bpc quirk for SDC panel in Lenovo G50 Qiang Yu (1): dma-buf/resv: fix exclusive fence get Steven Price (2): drm/panfrost: Add missing GPU feature registers drm/panfrost: Handle resetting on timeout better Thomas Hellstrom (1): drm/ttm: Restore ttm prefaulting Ulf Magnusson (1): drm/tiny: Kconfig: Remove always-y THERMAL dep. from TINYDRM_REPAPER Ville Syrjälä (1): drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin Xiaojie Yuan (1): drm/amdgpu/sdma5: fix mask value of POLL_REGMEM packet for pipe sync drivers/dma-buf/dma-resv.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 35 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 35 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 2 +- .../drm/amd/powerplay/smumgr/polaris10_smumgr.c| 2 +- .../gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c| 2 +- drivers/gpu/drm/drm_edid.c | 3 ++ drivers/gpu/drm/i915/display/intel_bios.c | 22 +--- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +++ drivers/gpu/drm/i915/gem/i915_gem_object.h | 6 +++ drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 +- drivers/gpu/drm/i915/gem/i915_gem_userptr.c| 1 + drivers/gpu/drm/i915/gt/intel_lrc.c| 63 +++--- drivers/gpu/drm/i915/i915_gem.c| 3 ++ drivers/gpu/drm/msm/dsi/dsi_host.c | 6 ++- drivers/gpu/drm/panfrost/panfrost_gpu.c| 3 ++ drivers/gpu/drm/panfrost/panfrost_job.c| 16 -- drivers/gpu/drm/radeon/radeon_drv.c| 8 --- drivers/gpu/drm/tiny/Kconfig | 1 - drivers/gpu/drm/ttm/ttm_bo.c | 9 ++-- drivers/gpu/drm/ttm/ttm_bo_vm.c| 16 +++--- 21 files changed, 150 insertions(+), 95 deletions(-)
[PULL] drm-misc-fixes
Hi Dave/Daniel, Guest-Maxime here with a drm-misc-fixes pull. Interesting stuff has been highlighted below in the tag. I realized that we have Steven's stopped job patch in both -next and -fixes, so we'll need to watch out for conflicts when they come together. drm-misc-fixes-2019-10-17: -dma-resv: Change shared_count to post-increment to fix lima crash (Qiang) -ttm: A couple fixes related to lifetime and restore prefault behavior (Christian & Thomas) -panfrost: Fill in missing feature reg values and fix stoppedjob timeouts (Steven) Cc: Qiang Yu Cc: Thomas Hellstrom Cc: Christian König Cc: Steven Price Cheers, Sean The following changes since commit fd70c7755bf0172ddd33b558aef69c322de3b5cf: drm/bridge: tc358767: fix max_tu_symbol value (2019-10-10 11:15:45 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-10-17 for you to fetch changes up to 5b3ec8134f5f9fa1ed0a538441a495521078bbee: drm/panfrost: Handle resetting on timeout better (2019-10-15 11:38:22 -0500) -dma-resv: Change shared_count to post-increment to fix lima crash (Qiang) -ttm: A couple fixes related to lifetime and restore prefault behavior (Christian & Thomas) -panfrost: Fill in missing feature reg values and fix stoppedjob timeouts (Steven) Cc: Qiang Yu Cc: Thomas Hellstrom Cc: Christian König Cc: Steven Price Christian König (2): drm/ttm: fix busy reference in ttm_mem_evict_first drm/ttm: fix handling in ttm_bo_add_mem_to_lru Jeffrey Hugo (1): drm/msm/dsi: Implement reset correctly Kai-Heng Feng (1): drm/edid: Add 6 bpc quirk for SDC panel in Lenovo G50 Qiang Yu (1): dma-buf/resv: fix exclusive fence get Steven Price (2): drm/panfrost: Add missing GPU feature registers drm/panfrost: Handle resetting on timeout better Thomas Hellstrom (1): drm/ttm: Restore ttm prefaulting Ulf Magnusson (1): drm/tiny: Kconfig: Remove always-y THERMAL dep. from TINYDRM_REPAPER drivers/dma-buf/dma-resv.c | 2 +- drivers/gpu/drm/drm_edid.c | 3 +++ drivers/gpu/drm/msm/dsi/dsi_host.c | 6 -- drivers/gpu/drm/panfrost/panfrost_gpu.c | 3 +++ drivers/gpu/drm/panfrost/panfrost_job.c | 16 +++- drivers/gpu/drm/tiny/Kconfig| 1 - drivers/gpu/drm/ttm/ttm_bo.c| 9 + drivers/gpu/drm/ttm/ttm_bo_vm.c | 16 +++- 8 files changed, 34 insertions(+), 22 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
Hello Thierry,
On Thu, Oct 17, 2019 at 05:14:37PM +0200, Thierry Reding wrote:
> On Thu, Oct 17, 2019 at 03:58:25PM +0200, Michal Vokáč wrote:
> > On 17. 10. 19 14:59, Thierry Reding wrote:
> > > On Thu, Oct 17, 2019 at 02:09:17PM +0200, Uwe Kleine-König wrote:
> > > > On Thu, Oct 17, 2019 at 01:11:31PM +0200, Thierry Reding wrote:
> > > > > On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> > > > > > On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > > > > > > On 17. 10. 19 10:10, Uwe Kleine-König wrote:
> > > > > > > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm:
> > > > > > > > Let
> > > > > > > > pwm_get_state() return the last implemented state")) changed the
> > > > > > > > semantic of pwm_get_state() and disclosed an (as it seems)
> > > > > > > > common
> > > > > > > > problem in lowlevel PWM drivers. By not relying on the period
> > > > > > > > and duty
> > > > > > > > cycle being retrievable from a disabled PWM this type of
> > > > > > > > problem is
> > > > > > > > worked around.
> > > > > > > >
> > > > > > > > Apart from this issue only calling the
> > > > > > > > pwm_get_state/pwm_apply_state
> > > > > > > > combo once is also more effective.
> > > > > > > >
> > > > > > > > Signed-off-by: Uwe Kleine-König
> > > > > > > > ---
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > There are now two reports about 01ccf903edd6 breaking a
> > > > > > > > backlight. As
> > > > > > > > far as I understand the problem this is a combination of the
> > > > > > > > backend pwm
> > > > > > > > driver yielding surprising results and the pwm-bl driver doing
> > > > > > > > things
> > > > > > > > more complicated than necessary.
> > > > > > > >
> > > > > > > > So I guess this patch works around these problems. Still it
> > > > > > > > would be
> > > > > > > > interesting to find out the details in the imx driver that
> > > > > > > > triggers the
> > > > > > > > problem. So Adam, can you please instrument the pwm-imx27
> > > > > > > > driver to
> > > > > > > > print *state at the beginning of pwm_imx27_apply() and the end
> > > > > > > > of
> > > > > > > > pwm_imx27_get_state() and provide the results?
> > > > > > > >
> > > > > > > > Note I only compile tested this change.
> > > > > > >
> > > > > > > Hi Uwe,
> > > > > > > I was just about to respond to the "pwm_bl on i.MX6Q broken on
> > > > > > > 5.4-RC1+"
> > > > > > > thread that I have a similar problem when you submitted this
> > > > > > > patch.
> > > > > > >
> > > > > > > So here are my few cents:
> > > > > > >
> > > > > > > My setup is as follows:
> > > > > > > - imx6dl-yapp4-draco with i.MX6Solo
> > > > > > > - backlight is controlled with inverted PWM signal
> > > > > > > - max brightness level = 32, default brightness level set to 32
> > > > > > > in DT.
> > > > > > >
> > > > > > > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm:
> > > > > > > Let
> > > > > > > pwm_get_state() return the last implemented state):
> > > > > > >
> > > > > > > - System boots to userspace and backlight is enabled all the
> > > > > > > time from
> > > > > > > power up.
> > > > > > >
> > > > > > > $ dmesg | grep state
> > > > > > > [1.763381] get state end: -1811360608, enabled: 0
> > > > > >
> > > > > > What is -1811360608? When I wrote "print *state" above, I thought
> > > > > > about
> > > > > > something like:
> > > > > >
> > > > > > pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
> > > > > > __func__, state->period, state->duty_cycle,
> > > > > > state->polarity, state->enabled);
> > > > > >
> > > > > > A quick look into drivers/pwm/pwm-imx27.c shows that this is another
> > > > > > driver that yields duty_cycle = 0 when the hardware is off.
> > > > >
> > > > > It seems to me like the best recourse to fix this for now would be to
> > > > > patch up the drivers that return 0 when the hardware is off by caching
> > > > > the currently configured duty cycle.
> > > > >
> > > > > How about the patch below?
> > > > >
> > > > > Thierry
> > > > >
> > > > > --- >8 ---
> > > > > From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00
> > > > > 2001
> > > > > From: Thierry Reding
> > > > > Date: Thu, 17 Oct 2019 12:56:00 +0200
> > > > > Subject: [PATCH] pwm: imx27: Cache duty cycle register value
> > > > >
> > > > > The hardware register containing the duty cycle value cannot be
> > > > > accessed
> > > > > when the PWM is disabled. This causes the ->get_state() callback to
> > > > > read
> > > > > back a duty cycle value of 0, which can confuse consumer drivers.
> > > > >
> > > > > Signed-off-by: Thierry Reding
> > > > > ---
> > > > > drivers/pwm/pwm-imx27.c | 31 ---
> > > > > 1 file changed, 24 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> > > > > index ae11d8577f18..4113d5cd4c62 100644
> > > > >
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 12:59:20PM +0200, Michal Vokáč wrote:
> On 17. 10. 19 11:48, Michal Vokáč wrote:
> > On 17. 10. 19 10:10, Uwe Kleine-König wrote:
> > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > pwm_get_state() return the last implemented state")) changed the
> > > semantic of pwm_get_state() and disclosed an (as it seems) common
> > > problem in lowlevel PWM drivers. By not relying on the period and duty
> > > cycle being retrievable from a disabled PWM this type of problem is
> > > worked around.
> > >
> > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > combo once is also more effective.
> > >
> > > Signed-off-by: Uwe Kleine-König
> > > ---
> > > Hello,
> > >
> > > There are now two reports about 01ccf903edd6 breaking a backlight. As
> > > far as I understand the problem this is a combination of the backend pwm
> > > driver yielding surprising results and the pwm-bl driver doing things
> > > more complicated than necessary.
> > >
> > > So I guess this patch works around these problems. Still it would be
> > > interesting to find out the details in the imx driver that triggers the
> > > problem. So Adam, can you please instrument the pwm-imx27 driver to
> > > print *state at the beginning of pwm_imx27_apply() and the end of
> > > pwm_imx27_get_state() and provide the results?
> > >
> > > Note I only compile tested this change.
> >
> > Hi Uwe,
> > I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
> > thread that I have a similar problem when you submitted this patch.
> >
> > So here are my few cents:
>
> Once again with updated and more detailed debug messages.
>
> > My setup is as follows:
> > - imx6dl-yapp4-draco with i.MX6Solo
> > - backlight is controlled with inverted PWM signal
> > - max brightness level = 32, default brightness level set to 32 in DT.
> >
> > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
> > pwm_get_state() return the last implemented state):
> >
> > - System boots to userspace and backlight is enabled all the time from
> > power up.
> >
> - $ dmesg | grep pwm_
> [1.761546] pwm_imx27_get_state: period: 992970, duty: 0, polarity:
> 0, enabled: 0
> [5.012352] pwm_imx27_apply: period: 50, duty: 0, polarity: 1,
> enabled: 0
> [5.021143] pwm_imx27_apply: period: 50, duty: 50, polarity:
> 1, enabled: 0
> [5.030182] pwm_imx27_apply: period: 50, duty: 50, polarity:
> 1, enabled: 1
> >
> > - $ cat brightness
> > 32
> >
> > - $ echo 32 > brightness # nothing happens, max. brightness
> >
> > - $ echo 1 > brightness # backlight goes down to lowest level
> [ 93.976354] pwm_imx27_apply: period: 50, duty: 7843, polarity:
> 1, enabled: 1
> >
> > - $ echo 0 > brightness # backlight goes up to max. level, this is
> > # problem of the inverted PWM on i.MX we attempted
> > # to solve some time ago.
> [ 115.496350] pwm_imx27_apply: period: 50, duty: 0, polarity: 1,
> enabled: 0
> >
> > 2. Backlight behavior on v5.4-rc3:
> >
> > - System boots to userspace and backlight is enabled all the time from
> > power up.
> >
> - $ dmesg | grep pwm_
> [1.774071] pwm_imx27_get_state: period: 992970, duty: 0, polarity:
> 0, enabled: 0
> [5.003961] pwm_imx27_apply: period: 50, duty: 0, polarity: 1,
> enabled: 0
> [5.012649] pwm_imx27_get_state: period: 992970, duty: 0, polarity:
> 0, enabled: 0
> [5.021694] pwm_imx27_apply: period: 992970, duty: 992970, polarity:
> 0, enabled: 0
> [5.030732] pwm_imx27_get_state: period: 992970, duty: 0, polarity:
> 0, enabled: 0
> [5.039643] pwm_imx27_apply: period: 992970, duty: 0, polarity: 0,
> enabled: 1
> [5.049605] pwm_imx27_get_state: period: 992970, duty: 0, polarity:
> 0, enabled: 1
> >
> > - $ cat brightness
> > 32
> >
> > - $ echo 32 > brightness # backlight goes down
> [ 707.946970] pwm_imx27_apply: period: 992970, duty: 992970, polarity:
> 0, enabled: 1
> [ 707.958551] pwm_imx27_get_state: period: 992970, duty: 992970,
> polarity: 0, enabled: 1
> >
> > - $ echo 1 > brightness # backlight goes up to high level
> [ 757.516845] pwm_imx27_apply: period: 992970, duty: 15576, polarity:
> 0, enabled: 1
> [ 757.528438] pwm_imx27_get_state: period: 992970, duty: 15576,
> polarity: 0, enabled: 1
> >
> > - $ echo 0 > brightness # backlight goes up to highest level
> [ 783.386838] pwm_imx27_apply: period: 992970, duty: 0, polarity: 0,
> enabled: 0
> [ 783.398025] pwm_imx27_get_state: period: 496485, duty: 0, polarity:
> 0, enabled: 0
> >
> > So the behavior is clearly inverted to how it worked prior to 01ccf903edd6
> > with the weird exception that the initial brightness level 32 is
> > not applied.
> >
> > 3. Backlight behavior
Re: [RFC] drm: Add AMD GFX9+ format modifiers.
On Wed, Oct 16, 2019 at 9:48 AM Bas Nieuwenhuizen
wrote:
> This adds initial format modifiers for AMD GFX9 and newer GPUs.
>
> This is particularly useful to determine if we can use DCC, and whether
> we need an extra display compatible DCC metadata plane.
>
> Design decisions:
> - Always expose a single plane
>This way everything works correctly with images with multiple
> planes.
>
> - Do not add an extra memory region in DCC for putting a bit on whether
> we are in compressed state.
>A decompress on import is cheap enough if already decompressed, and
>I do think in most cases we can avoid it in advance during modifier
>negotiation. The remainder is probably not common enough to worry
>about.
>
> - Explicitly define the sizes as part of the modifier description instead
> of using whatever the current version of radeonsi does.
>This way we can avoid dedicated buffers and we can make sure we keep
>compatibility across mesa versions. I'd like to put some tests on
>this on ac_surface.c so we can learn early in the process if things
>need to be changed. Furthermore, the lack of configurable strides on
>GFX10 means things already go wrong if we do not agree, making a
>custom stride somewhat less useful.
>
The custom stride will be back for 2D images (not for 3D/Array), so
Navi10-14 will be the only hw not supporting the custom stride for 2D. It
might not be worth adding the width and height into the modifier just
because of Navi10-14, though I don't feel strongly about it.
This patch doesn't add the sizes into the description anyway.
The rest looks good.
Marek
>
> - No usage of BO metadata at all for modifier usecases.
>To avoid the requirement of dedicated dma bufs per image. For
>non-modifier based interop we still use the BO metadata, since we
>need to keep compatibility with old mesa and this is used for
>depth/msaa/3d/CL etc. API interop.
>
> - A single FD for all planes.
>Easier in Vulkan / bindless and radeonsi is already transitioning.
>
> - Make a single modifier for DCN1
> It defines things uniquely given bpp, which we can assume, so adding
> more modifier values do not add clarity.
>
> - Not exposing the 4K and 256B tiling modes.
> These are largely only better for something like a cursor or very
> long
> and/or tall images. Are they worth the added complexity to save
> memory?
> For context, at 32bpp, tiles are 128x128 pixels.
>
> - For multiplane images, every plane uses the same tiling.
> On GFX9/GFX10 we can, so no need to make it complicated.
>
> - We use family_id + external_rev to distinguish between incompatible
> GPUs.
> PCI ID is not enough, as RAVEN and RAVEN2 have the same PCI device
> id,
> but different tiling. We might be able to find bigger equivalence
> groups for _X, but especially for DCC I would be uncomfortable
> making it
> shared between GPUs.
>
> - For DCN1 DCC, radeonsi currently uses another texelbuffer with indices
> to reorder. This is not shared.
> Specific to current implementation and does not need to be shared. To
> pave the way to shader-based solution, lets keep this internal to
> each
> driver. This should reduce the modifier churn if any of the driver
> implementations change. (Especially as you'd want to support the old
> implementation for a while to stay compatible with old kernels not
> supporting a new modifier yet).
>
> - No support for rotated swizzling.
> Can be added easily later and nothing in the stack would generate it
> currently.
>
> - Add extra enum values in the definitions.
> This way we can easily switch on modifier without having to pass
> around
> the current GPU everywhere, assuming the modifier has been validated.
> ---
>
> Since my previous attempt for modifiers got bogged down on details for
> the GFX6-GFX8 modifiers in previous discussions, this only attempts to
> define modifiers for GFX9+, which is significantly simpler.
>
> For a final version I'd like to wait until I have written most of the
> userspace + kernelspace so we can actually test it. However, I'd
> appreciate any early feedback people are willing to give.
>
> Initial Mesa amd/common support + tests are available at
> https://gitlab.freedesktop.org/bnieuwenhuizen/mesa/tree/modifiers
>
> I tested the HW to actually behave as described in the descriptions
> on Raven and plan to test on a subset of the others.
>
> include/uapi/drm/drm_fourcc.h | 118 ++
> 1 file changed, 118 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3f987a..9bd286ab2bee 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -756,6 +756,124 @@ extern "C" {
> */
> #define
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
Hello Thierry, On Thu, Oct 17, 2019 at 02:59:32PM +0200, Thierry Reding wrote: > On Thu, Oct 17, 2019 at 02:09:17PM +0200, Uwe Kleine-König wrote: > > On Thu, Oct 17, 2019 at 01:11:31PM +0200, Thierry Reding wrote: > > > diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c > > > index ae11d8577f18..4113d5cd4c62 100644 > > > --- a/drivers/pwm/pwm-imx27.c > > > +++ b/drivers/pwm/pwm-imx27.c > > > [...] > > > > I wonder if it would be more sensible to do this in the pwm core > > instead. Currently there are two drivers known with this problem. I > > wouldn't be surprised if there were more. > > I've inspected all the drivers and didn't spot any beyond cros-ec and > i.MX that have this problem. I took a look, too, and I'd say pwm-atmel.c, pwm-imx-tpm.c, pwm-lpss.c, pwm-meson.c, pwm-sifive.c, pwm-sprd.c and pwm-stm32-lp.c are affected. > So the core would have to rely on state->duty_cycle that is passed in, > but then the offending commit becomes useless because the whole point > was to return the state as written to hardware (rather than the > software state which was being returned before that patch). I like allowing lowlevel drivers to implement the .enabled = false case lazily as there is little value in calculating the needed register values for a request like .duty_cycle = X, .period = Y, .enabled = false even if the next request might be .duty_cycle = X, .period = Y, .enabled = true because quite likely the same calculation is done for the second request again and there is no benefit to save X and Y in the hardware (or the driver if the hardware is incapable) apart from returning it to a consumer who maybe even doesn't care because these values don't tell anything at all about the implemented wave form and so it seems natural to me that the lowlevel driver shouldn't care. > > If we want to move clients to not rely on .period and .duty_cycle for a > > disabled PWM (do we?) a single change in the core is also beneficial > > compared to fixing several lowlevel drivers. > > These are really two orthogonal problems. We don't currently consider > enabled = 0 to be equivalent to duty_cycle = 0 at an API level. I'm not > prepared to do that at this point in the release cycle either. Yeah, I fully agree that we should not do that now. Given the number of affected drivers I opt for reverting and retrying again more carefully later. > What this here has shown is that we have at least two drivers that don't > behave the way they are supposed to according to the API and they break > consumers. If they break for pwm-backlight, it's possible that they will > break for other consumers as well. So the right thing to do is fix the > two drivers that are broken. In my eyes shifting the definition of "expected behaviour" and adapting the core code accordingly to make this invisible to consumers is also a viable option. Also shifting the definition and adapt all consumers not to rely on the old behaviour is fine. But as above, this is not a good idea at the current point in time. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/vi: silence an uninitialized variable warning
On Thu, Oct 17, 2019 at 5:12 AM Dan Carpenter wrote:
>
> Smatch complains that we need to initialized "*cap" otherwise it can
> lead to an uninitialized variable bug in the caller. This seems like a
> reasonable warning and it doesn't hurt to silence it at least.
>
> drivers/gpu/drm/amd/amdgpu/vi.c:767 vi_asic_reset_method() error:
> uninitialized symbol 'baco_reset'.
>
> Fixes: 425db2553e43 ("drm/amdgpu: expose BACO interfaces to upper level from
> PP")
> Signed-off-by: Dan Carpenter
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> index 83196b79edd5..f4ff15378e61 100644
> --- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> +++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> @@ -1421,6 +1421,7 @@ static int pp_get_asic_baco_capability(void *handle,
> bool *cap)
> {
> struct pp_hwmgr *hwmgr = handle;
>
> + *cap = false;
> if (!hwmgr)
> return -EINVAL;
>
> --
> 2.20.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #103 from Shmerl --- I just got a random Firefox freeze with all three above patches applied. So it's clearly not fixed yet (though such hangs are a lot less common than before now): [78836.138723] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! [78841.770422] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout, signaled seq=133096, emitted seq=133098 [78841.770490] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process GPU Process pid 1882 thread firefox-bi:cs0 pid 2034 [78841.770493] [drm] GPU recovery disabled. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #102 from Marko Popovic --- (In reply to Marko Popovic from comment #101) > Created attachment 145766 [details] > APITrace from Rocket League successful launch > > Ok so since it was unable to be reproduced with that 1 frame long trace, > here I'm attaching a trace file that happens when Rocket League launches > successfully... Maybe you guys can get some information out of the trace on > what might cause the SDMA hangs 80% of the time when launching the game. PS: Hang usually occurs immidiately when games try to launch itself. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #101 from Marko Popovic --- Created attachment 145766 --> https://bugs.freedesktop.org/attachment.cgi?id=145766=edit APITrace from Rocket League successful launch Ok so since it was unable to be reproduced with that 1 frame long trace, here I'm attaching a trace file that happens when Rocket League launches successfully... Maybe you guys can get some information out of the trace on what might cause the SDMA hangs 80% of the time when launching the game. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On 10/17/19 3:14 PM, John Stultz wrote: > On Wed, Oct 16, 2019 at 10:41 AM Andrew F. Davis wrote: >> On 10/14/19 5:07 AM, Brian Starkey wrote: >>> Hi Andrew, >>> >>> On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote: The CMA driver that registers these nodes will have to be expanded to export them using this framework as needed. We do something similar to export SRAM nodes: https://lkml.org/lkml/2019/3/21/575 Unlike the system/default-cma driver which can be centralized in the tree, these extra exporters will probably live out in other subsystems and so are added in later steps. Andrew >>> >>> I was under the impression that the "cma_for_each_area" loop in patch >>> 4 would do that (add_cma_heaps). Is it not the case? >>> >> >> For these cma nodes yes, I thought you meant reserved memory areas in >> general. > > Ok, sorry I didn't see this earlier, not only was I still dropped from > the To list, but the copy I got from dri-devel ended up marked as > spam. > >> Just as a side note, I'm not a huge fan of the cma_for_each_area() to >> begin with, it seems a bit out of place when they could be selectively >> added as heaps as needed. Not sure how that will work with cma nodes >> specifically assigned to devices, seems like we could just steal their >> memory space from userspace with this.. > > So this would be a concern with ION as well, since it does the same > thing because being able to allocate from multiple CMA heaps for > device specific purpose is really useful. > And at least with dmabuf heaps each heap can be given its own > permissions so there's less likelihood for any abuse as you describe. > Yes it was a problem with ION also, having individual files per heap does help with some permissions, but my issue is what if I don't want my CMA exported at all, cma_for_each_area() just grabs them all anyway. > And it also allows various device cma nodes to still be allocated from > using the same interface (rather then having to use a custom driver > ioctl for each device). > This is definitely the way to go, it's the implementation of how we get the CMAs to export in the first place that is a bit odd. > But if the objection stands, do you have a proposal for an alternative > way to enumerate a subset of CMA heaps? > When in staging ION had to reach into the CMA framework as the other direction would not be allowed, so cma_for_each_area() was added. If DMA-BUF heaps is not in staging then we can do the opposite, and have the CMA framework register heaps itself using our framework. That way the CMA system could decide what areas to export or not (maybe based on a DT property or similar). The end result is the same so we can make this change later (it has to come after DMA-BUF heaps is in anyway). Andrew > thanks > -john > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Dave/Daniel, Apologies for this being a day late, I wanted to get the dt-bindings for the malidp QoS change before sending this. Most of the volume is incremental this week, there's some new HW features enabled which I've called out below. As for the uapi changes, well it's interesting timing with your RFC the other day :) I think the error code changes are well-scrutinized so I don't have much concern for those. The omap OMAP_BO_MEM_* changes though I don't think have really reached non-TI eyes. There's no link in the commit message to a UAPI implementation and the only reference I could find is libkmsxx which can set them through the python bindings. Since this is TI-specific gunk in TI-specific headers I'm inclined to let it pass, but I would have liked to have this conversation upfront. I figured I'd call this out so you have final say. drm-misc-next-2019-10-17: drm-misc-next for 5.5: UAPI Changes: -omap: -Add OMAP_BO_MEM_* flags to specify how to allocate BO (Tomi) -Reorder OMAP_BO_* #defines, no functional change (Tomi) -Change unsupported error code from EINVAL to EOPNOTSUPP for: (Rodrigo) -drm_wait_vblank_ioctl -drm_crtc_get_sequence_ioctl -drm_crtc_queue_sequence_ioctl Cross-subsystem Changes: -None Core Changes: -Delete drmP.h \o/ (Sam) -kerneldoc clarifications on zpos collisions and plane rects (Simon & Maarten) -dp_helpers: Add link training repeater definitions added in DP 1.4 (Rodrigo) -TODO: Add item to convert fbdev drivers to drm (Thomas) -prime: Add mmap to drm_gem_object_funcs giving more control than vm_ops (Gerd) -shmem/ttm/vram: Use new mmap gem_object callback (Gerd) Driver Changes: -malidp: Add display QoS configuration via devicetree (Wen) -vkms: Add prime import support (Oleg) -panfrost: Properly handle job timeouts when cancelling them (Steven) -rockchip/meson/sun4i(via dw-hdmi): Add Dynamic Range and Mastering infoframe support (Jonas) -mxsfb: Add bridge support to accommodate dsi outputs (Robert) -vboxvideo: Drop hand-rolled implementations and use fbdev emulation, dirtyfb and drm_framebuffer struct from core/core helpers (Thomas) -komeda: Add D71-specific line sizes and respect connector color fmt (Lowry) -lima: Use shmem and reservation lock helpers from gem (Qiang) -rockchip: Add gamma LUT support on vop crtcs (Ezequiel) -omap: -Use refcount_t instead of rolling custom refcounting (Jean-Jacques) Cc: Wen He Cc: Sam Ravnborg Cc: Rodrigo Siqueira Cc: Oleg Vasilev Cc: Steven Price Cc: Jonas Karlman Cc: Maarten Lankhorst Cc: Simon Ser Cc: Robert Chiras Cc: Thomas Zimmermann Cc: Lowry Li Cc: Gerd Hoffmann Cc: Qiang Yu Cc: Tomi Valkeinen Cc: Ezequiel Garcia Cc: Jean-Jacques Hiblot Cheers, Sean The following changes since commit 354c2d310082d1c384213ba76c3757dd3cd8755d: drm: damage_helper: Fix race checking plane->state->fb (2019-10-08 09:41:06 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-10-17 for you to fetch changes up to e30b38b71294849c018322d85e90ec056438fe43: drm/lima: add __GFP_NOWARN flag to all dma_alloc_wc (2019-10-17 23:42:02 +0800) drm-misc-next for 5.5: UAPI Changes: -omap: -Add OMAP_BO_MEM_* flags to specify how to allocate BO (Tomi) -Reorder OMAP_BO_* #defines, no functional change (Tomi) -Change unsupported error code from EINVAL to EOPNOTSUPP for: (Rodrigo) -drm_wait_vblank_ioctl -drm_crtc_get_sequence_ioctl -drm_crtc_queue_sequence_ioctl Cross-subsystem Changes: -None Core Changes: -Delete drmP.h \o/ (Sam) -kerneldoc clarifications on zpos collisions and plane rects (Simon & Maarten) -dp_helpers: Add link training repeater definitions added in DP 1.4 (Rodrigo) -TODO: Add item to convert fbdev drivers to drm (Thomas) -prime: Add mmap to drm_gem_object_funcs giving more control than vm_ops (Gerd) -shmem/ttm/vram: Use new mmap gem_object callback (Gerd) Driver Changes: -malidp: Add display QoS configuration via devicetree (Wen) -vkms: Add prime import support (Oleg) -panfrost: Properly handle job timeouts when cancelling them (Steven) trockchip/meson/sun4i(via dw-hdmi): Add Dynamic Range and Mastering infoframe support (Jonas) -mxsfb: Add bridge support to accommodate dsi outputs (Robert) -vboxvideo: Drop hand-rolled implementations and use fbdev emulation, dirtyfb and drm_framebuffer struct from core/core helpers (Thomas) -komeda: Add D71-specific line sizes and respect connector color fmt (Lowry) -lima: Use shmem and reservation lock helpers from gem (Qiang) -rockchip: Add gamma LUT support on vop crtcs (Ezequiel) -omap: -Use refcount_t instead of rolling custom refcounting (Jean-Jacques) Cc: Wen He Cc: Sam Ravnborg Cc: Rodrigo Siqueira Cc: Oleg Vasilev Cc: Steven Price Cc: Jonas Karlman Cc: Maarten Lankhorst Cc: Simon Ser Cc: Robert
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On Wed, Oct 16, 2019 at 10:41 AM Andrew F. Davis wrote: > On 10/14/19 5:07 AM, Brian Starkey wrote: > > Hi Andrew, > > > > On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote: > >> The CMA driver that registers these nodes will have to be expanded to > >> export them using this framework as needed. We do something similar to > >> export SRAM nodes: > >> > >> https://lkml.org/lkml/2019/3/21/575 > >> > >> Unlike the system/default-cma driver which can be centralized in the > >> tree, these extra exporters will probably live out in other subsystems > >> and so are added in later steps. > >> > >> Andrew > > > > I was under the impression that the "cma_for_each_area" loop in patch > > 4 would do that (add_cma_heaps). Is it not the case? > > > > For these cma nodes yes, I thought you meant reserved memory areas in > general. Ok, sorry I didn't see this earlier, not only was I still dropped from the To list, but the copy I got from dri-devel ended up marked as spam. > Just as a side note, I'm not a huge fan of the cma_for_each_area() to > begin with, it seems a bit out of place when they could be selectively > added as heaps as needed. Not sure how that will work with cma nodes > specifically assigned to devices, seems like we could just steal their > memory space from userspace with this.. So this would be a concern with ION as well, since it does the same thing because being able to allocate from multiple CMA heaps for device specific purpose is really useful. And at least with dmabuf heaps each heap can be given its own permissions so there's less likelihood for any abuse as you describe. And it also allows various device cma nodes to still be allocated from using the same interface (rather then having to use a custom driver ioctl for each device). But if the objection stands, do you have a proposal for an alternative way to enumerate a subset of CMA heaps? thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/8] drm: rcar-du: Add Color Management Module (CMM)
Hi Jacopo, Thank you for your work. On Wed, Oct 16, 2019 at 10:55:40AM +0200, Jacopo Mondi wrote: > Minimal increment to the CMM series, this time should really be the last one. > > Just missing Rob's ack on [1/8] and Laurent's one on [5/8]. > > Changelog is minimal: > CMM > - Remove the cmm_config.enable flag. The cmm_config.table field validity is > used to enable/disable the LUT operations > - Expand comments as suggested by Laurent > > CRTC > - use drm_color_lut_size() to check the LUT table size > - Inline calls to rcar_cmm_enable()/disable() > - Add TODO entries as suggested by Laurent > > For the record, the full series changelog is available at: > https://paste.debian.net/1107427/ > > v5 from yesterday with informations on testing is available at: > https://lkml.org/lkml/2019/10/15/337 > > Geert will you collect for DTS patches for the next release? > I assume the DU changes go through Laurent instead ? I've taken patch 1/8 to 6/8 and 8/8 in my tree. I expected Geert to take 7/8. > Jacopo Mondi (8): > dt-bindings: display: renesas,cmm: Add R-Car CMM documentation > dt-bindings: display, renesas,du: Document cmms property > drm: rcar-du: Add support for CMM > drm: rcar-du: kms: Initialize CMM instances > drm: rcar-du: crtc: Control CMM operations > drm: rcar-du: crtc: Register GAMMA_LUT properties > arm64: dts: renesas: Add CMM units to Gen3 SoCs > drm: rcar-du: kms: Expand comment in vsps parsing routine > > .../bindings/display/renesas,cmm.yaml | 67 ++ > .../bindings/display/renesas,du.txt | 5 + > arch/arm64/boot/dts/renesas/r8a7795.dtsi | 39 > arch/arm64/boot/dts/renesas/r8a7796.dtsi | 31 ++- > arch/arm64/boot/dts/renesas/r8a77965.dtsi | 31 ++- > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 21 ++ > arch/arm64/boot/dts/renesas/r8a77995.dtsi | 21 ++ > drivers/gpu/drm/rcar-du/Kconfig | 7 + > drivers/gpu/drm/rcar-du/Makefile | 1 + > drivers/gpu/drm/rcar-du/rcar_cmm.c| 212 ++ > drivers/gpu/drm/rcar-du/rcar_cmm.h| 58 + > drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 65 ++ > drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 2 + > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 + > drivers/gpu/drm/rcar-du/rcar_du_group.c | 10 + > drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 + > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 82 ++- > drivers/gpu/drm/rcar-du/rcar_du_regs.h| 5 + > 18 files changed, 658 insertions(+), 3 deletions(-) > create mode 100644 Documentation/devicetree/bindings/display/renesas,cmm.yaml > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h > -- Regards, Laurent Pinchart
[Bug 204805] BUG: kernel NULL pointer dereference, address: 0000000000000200
https://bugzilla.kernel.org/show_bug.cgi?id=204805 --- Comment #3 from ilkka.pr...@gmail.com --- SysRq tricks do not work when freezing: Alt + SysRq + b does not reboot. -- 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.1 5/8] drm: rcar-du: crtc: Control CMM operations
Hi Jacopo,
Thank you for the patch.
On Thu, Oct 17, 2019 at 03:44:09PM +0200, Jacopo Mondi wrote:
> Implement CMM handling in the crtc begin and enable atomic callbacks,
> and enable CMM unit through the Display Extensional Functions
> register at group setup time.
>
> Reviewed-by: Laurent Pinchart
> Reviewed-by: Kieran Bingham
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> v6 -> v6.1
> - Drop check for CMM in rcar_du_cmm_check as if the gamma_table property is
> available, a CMM unit for this CRTC was registered
> - Add TODO note to investigate how the activation order of CMM and CRTC
> impact on the first displayed fram
Thank you :-)
> ---
>
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 61 +
> drivers/gpu/drm/rcar-du/rcar_du_group.c | 10
> drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 ++
> 3 files changed, 76 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index 23f1d6cc1719..3f0f16946f42 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -21,6 +21,7 @@
> #include
> #include
>
> +#include "rcar_cmm.h"
> #include "rcar_du_crtc.h"
> #include "rcar_du_drv.h"
> #include "rcar_du_encoder.h"
> @@ -474,6 +475,45 @@ static void rcar_du_crtc_wait_page_flip(struct
> rcar_du_crtc *rcrtc)
> rcar_du_crtc_finish_page_flip(rcrtc);
> }
>
> +/*
> -
> + * Color Management Module (CMM)
> + */
> +
> +static int rcar_du_cmm_check(struct drm_crtc *crtc,
> + struct drm_crtc_state *state)
> +{
> + struct drm_property_blob *drm_lut = state->gamma_lut;
> + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> + struct device *dev = rcrtc->dev->dev;
> +
> + if (!drm_lut)
> + return 0;
> +
> + /* We only accept fully populated LUT tables. */
> + if (drm_color_lut_size(drm_lut) != CM2_LUT_SIZE) {
> + dev_err(dev, "invalid gamma lut size: %lu bytes\n",
> + drm_lut->length);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static void rcar_du_cmm_setup(struct drm_crtc *crtc)
> +{
> + struct drm_property_blob *drm_lut = crtc->state->gamma_lut;
> + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> + struct rcar_cmm_config cmm_config = {};
> +
> + if (!rcrtc->cmm)
> + return;
> +
> + if (drm_lut)
> + cmm_config.lut.table = (struct drm_color_lut *)drm_lut->data;
> +
> + rcar_cmm_setup(rcrtc->cmm, _config);
> +}
> +
> /*
> -
> * Start/Stop and Suspend/Resume
> */
> @@ -619,6 +659,9 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
> if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
> rcar_du_vsp_disable(rcrtc);
>
> + if (rcrtc->cmm)
> + rcar_cmm_disable(rcrtc->cmm);
> +
> /*
>* Select switch sync mode. This stops display operation and configures
>* the HSYNC and VSYNC signals as inputs.
> @@ -642,6 +685,11 @@ static int rcar_du_crtc_atomic_check(struct drm_crtc
> *crtc,
> {
> struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(state);
> struct drm_encoder *encoder;
> + int ret;
> +
> + ret = rcar_du_cmm_check(crtc, state);
> + if (ret)
> + return ret;
>
> /* Store the routes from the CRTC output to the DU outputs. */
> rstate->outputs = 0;
> @@ -667,6 +715,8 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
> *crtc,
> struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(crtc->state);
> struct rcar_du_device *rcdu = rcrtc->dev;
>
> + if (rcrtc->cmm)
> + rcar_cmm_enable(rcrtc->cmm);
> rcar_du_crtc_get(rcrtc);
>
> /*
> @@ -686,6 +736,13 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
> *crtc,
> }
>
> rcar_du_crtc_start(rcrtc);
> +
> + /*
> + * TODO: The chip manual indicates that CMM tables should be written
> + * after the DU channel has been activated. Investigate the impact
> + * of this restriction on the first displayed frame.
> + */
> + rcar_du_cmm_setup(crtc);
> }
>
> static void rcar_du_crtc_atomic_disable(struct drm_crtc *crtc,
> @@ -739,6 +796,10 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc
> *crtc,
>*/
> rcar_du_crtc_get(rcrtc);
>
> + /* If the active state changed, we let .atomic_enable handle CMM. */
> + if (crtc->state->color_mgmt_changed && !crtc->state->active_changed)
> + rcar_du_cmm_setup(crtc);
> +
> if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
> rcar_du_vsp_atomic_begin(rcrtc);
> }
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> b/drivers/gpu/drm/rcar-du/rcar_du_group.c
>
Re: [PATCH 6.1 3/8] drm: rcar-du: Add support for CMM
Hi Jacopo,
Thank you for the patch.
On Thu, Oct 17, 2019 at 03:43:32PM +0200, Jacopo Mondi wrote:
> Add a driver for the R-Car Display Unit Color Correction Module.
>
> In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> to perform image enhancement and color correction.
>
> Add support for CMM through a driver that supports configuration of
> the 1-dimensional LUT table. More advanced CMM features will be
> implemented on top of this initial one.
>
> Reviewed-by: Laurent Pinchart
> Reviewed-by: Kieran Bingham
> Signed-off-by: Jacopo Mondi
>
> ---
> v6 -> v6.1
> - Expand rcar_cmm_setup() function documentation to detail its relationship
> with rcar_cmm_enable() and their call order precedence.
> ---
>
> drivers/gpu/drm/rcar-du/Kconfig| 7 +
> drivers/gpu/drm/rcar-du/Makefile | 1 +
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 217 +
> drivers/gpu/drm/rcar-du/rcar_cmm.h | 58
> 4 files changed, 283 insertions(+)
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
>
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 1529849e217e..539d232790d1 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -13,6 +13,13 @@ config DRM_RCAR_DU
> Choose this option if you have an R-Car chipset.
> If M is selected the module will be called rcar-du-drm.
>
> +config DRM_RCAR_CMM
> + bool "R-Car DU Color Management Module (CMM) Support"
> + depends on DRM && OF
> + depends on DRM_RCAR_DU
> + help
> + Enable support for R-Car Color Management Module (CMM).
> +
> config DRM_RCAR_DW_HDMI
> tristate "R-Car DU Gen3 HDMI Encoder Support"
> depends on DRM && OF
> diff --git a/drivers/gpu/drm/rcar-du/Makefile
> b/drivers/gpu/drm/rcar-du/Makefile
> index 6c2ed9c46467..4d1187ccc3e5 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o \
> rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
> rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
>
> +obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
> obj-$(CONFIG_DRM_RCAR_DU)+= rcar-du-drm.o
> obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> obj-$(CONFIG_DRM_RCAR_LVDS) += rcar_lvds.o
> diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> new file mode 100644
> index ..952316eb202b
> --- /dev/null
> +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> @@ -0,0 +1,217 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * rcar_cmm.c -- R-Car Display Unit Color Management Module
> + *
> + * Copyright (C) 2019 Jacopo Mondi
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "rcar_cmm.h"
> +
> +#define CM2_LUT_CTRL 0x
> +#define CM2_LUT_CTRL_LUT_EN BIT(0)
> +#define CM2_LUT_TBL_BASE 0x0600
> +#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
> +
> +struct rcar_cmm {
> + void __iomem *base;
> +
> + /*
> + * @lut:1D-LUT state
> + * @lut.enabled:1D-LUT enabled flag
> + */
> + struct {
> + bool enabled;
> + } lut;
> +};
> +
> +static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
> +{
> + return ioread32(rcmm->base + reg);
> +}
> +
> +static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32 data)
> +{
> + iowrite32(data, rcmm->base + reg);
> +}
> +
> +/*
> + * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware
> precision
> + * and write to the CMM registers
> + * @rcmm: Pointer to the CMM device
> + * @drm_lut: Pointer to the DRM LUT table
> + */
> +static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
> +const struct drm_color_lut *drm_lut)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < CM2_LUT_SIZE; ++i) {
> + u32 entry = drm_color_lut_extract(drm_lut[i].red, 8) << 16
> + | drm_color_lut_extract(drm_lut[i].green, 8) << 8
> + | drm_color_lut_extract(drm_lut[i].blue, 8);
> +
> + rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
> + }
> +}
> +
> +/*
> + * rcar_cmm_setup() - Configure the CMM unit
> + * @pdev: The platform device associated with the CMM instance
> + * @config: The CMM unit configuration
> + *
> + * Configure the CMM unit with the given configuration. Currently enabling,
> + * disabling and programming of the 1-D LUT unit is supported.
> + *
> + * As rcar_cmm_setup() accesses the CMM registers the unit should be powered
> + * and its functional clock enabled. To guarantee this, before any call to
> + * this function is made, the CMM unit has to be enabled by calling
> + * rcar_cmm_enable() first.
[Bug 111987] Unstable performance (periodic and repeating patterns of fps change) and changing VDDGFX
https://bugs.freedesktop.org/show_bug.cgi?id=111987 --- Comment #17 from Witold Baryluk --- I also tried echo profile_peak > power_dpm_force_performance_level , and initially the sclk stays at the highest level, but after a minute, it does drop just like other profiles. As of of cooling and PSU. I am sure I have plenty of headroom. The hwmon reports ~207W power at highest clock state, but temperature as reported by hwmon stays at 39 deg C. At lower clock states it drops to 37 deg C, and to about 35 deg C at idle. Looks to be just fine to me. My PC case do have extra ventilation, and CPU is pretty much idle. My PSU is Seasonic Prime Titanium (1000W). I have: Motherboard: MSI MEG Creation X399 GPU: AMD Threadripper 2950X at stock, liquid cooled, idle (~5% load), about 46 deg C. RAM: 8x16GB Samsung DDR4 ECC GPU: AMD Radeon Fury X, water cooled NIC: Melanox ConnectX-3 Storage: 2x Samsung PM983 via U.2 Cooling: Plenty of fans in Fractal Define R6 USB-C case. I just opened the case, and verified that two 8-pin PCI-E connectors are connected to GPU and PSU. I also verified that extra (optional, even on multi GPU systems) power connectors to MB are also connected to MB and PSU. GPU radiator is above the GPU, and is not hot to the touch or anything. Fan on it is spinning at max. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 02:18:02PM +0100, Daniel Thompson wrote:
> On Thu, Oct 17, 2019 at 02:19:45PM +0200, Uwe Kleine-König wrote:
> > On Thu, Oct 17, 2019 at 12:47:27PM +0100, Daniel Thompson wrote:
> > > On Thu, Oct 17, 2019 at 10:10:59AM +0200, Uwe Kleine-König wrote:
> > > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > > pwm_get_state() return the last implemented state")) changed the
> > > > semantic of pwm_get_state() and disclosed an (as it seems) common
> > > > problem in lowlevel PWM drivers. By not relying on the period and duty
> > > > cycle being retrievable from a disabled PWM this type of problem is
> > > > worked around.
> > > >
> > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > combo once is also more effective.
> > >
> > > I'm only interested in the second paragraph here.
> > >
> > > There seems to be a reasonable consensus that the i.MX27 and cros-ec
> > > PWM drivers should be fixed for the benefit of other PWM clients.
> > > So we make this change because it makes the pwm-bl better... not to
> > > work around bugs ;-).
> >
> > That's fine, still I think it's fair to explain the motivation of
> > creating this patch.
>
> Maybe.
>
> Whether this patch is a workaround or simply an improvement to pwm-bl
> does need to be clear since it affects whether Lee steers it towards
> v5.4-rcX or linux-next .
Given that there will be a a fix in the pwm subsystem I'd say linux-next
sounds right.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111987] Unstable performance (periodic and repeating patterns of fps change) and changing VDDGFX
https://bugs.freedesktop.org/show_bug.cgi?id=111987 --- Comment #16 from Alex Deucher --- It sounds like the GPU is getting throttled due to power temperature. Is the cooling solution on your GPU clean and working properly? Do you have an adequate power supply? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111987] Unstable performance (periodic and repeating patterns of fps change) and changing VDDGFX
https://bugs.freedesktop.org/show_bug.cgi?id=111987 --- Comment #15 from Witold Baryluk --- Setting echo high > power_dpm_force_performance_level didn't help. It is set to high (verified by reading back from sysfs). gpu_busy_percent is showing me 100 all the time, and sometimes jumps a little lower, maybe 87, 95, then back to 100. Despite all of this the GPU frequency is slowly and gradually dropping down, until it reaches the lowest frequency and then jumps back to maximum. It does look like a bug to me... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: fix max fclk divider for omap36xx
On Sun, Oct 13, 2019 at 10:56 AM Adam Ford wrote:
>
> On Wed, Oct 2, 2019 at 7:25 AM Tomi Valkeinen wrote:
> >
> > The OMAP36xx and AM/DM37x TRMs say that the maximum divider for DSS fclk
> > (in CM_CLKSEL_DSS) is 32. Experimentation shows that this is not
> > correct, and using divider of 32 breaks DSS with a flood or underflows
> > and sync losts. Dividers up to 31 seem to work fine.
> >
> > There is another patch to the DT files to limit the divider correctly,
> > but as the DSS driver also needs to know the maximum divider to be able
> > to iteratively find good rates, we also need to do the fix in the DSS
> > driver.
> >
>
> Tomi,
>
> Is there any way you can do a patch for the FB version for the older
> 4.9 and 4.14 kernels? I think they are still defaulting to the omapfb
> instead of DRM, so the underflow issue still appears by default and
> the patch only impacts the DRM version of the driver. If not, do you
> have any objections if I submit a patch to stable for those two LTS
> branches?
Gentle nudge on this question. I can do the work, but I just
permission so don't overstep.
adam
>
> thanks,
>
> adam
> > Signed-off-by: Tomi Valkeinen
> > Cc: Adam Ford
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/gpu/drm/omapdrm/dss/dss.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c
> > b/drivers/gpu/drm/omapdrm/dss/dss.c
> > index e226324adb69..4bdd63b57100 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/dss.c
> > +++ b/drivers/gpu/drm/omapdrm/dss/dss.c
> > @@ -1083,7 +1083,7 @@ static const struct dss_features omap34xx_dss_feats =
> > {
> >
> > static const struct dss_features omap3630_dss_feats = {
> > .model = DSS_MODEL_OMAP3,
> > - .fck_div_max= 32,
> > + .fck_div_max= 31,
> > .fck_freq_max = 17300,
> > .dss_fck_multiplier = 1,
> > .parent_clk_name= "dpll4_ck",
> > --
> > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 4/6] mdev: introduce virtio device and its device ops
On Thu, 17 Oct 2019 18:48:34 +0800
Jason Wang wrote:
> This patch implements basic support for mdev driver that supports
> virtio transport for kernel virtio driver.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vfio/mdev/mdev_core.c | 12 +++
> include/linux/mdev.h | 4 +
> include/linux/virtio_mdev.h | 151 ++
> 3 files changed, 167 insertions(+)
> create mode 100644 include/linux/virtio_mdev.h
>
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index d0f3113c8071..5834f6b7c7a5 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -57,6 +57,18 @@ void mdev_set_vfio_ops(struct mdev_device *mdev,
> }
> EXPORT_SYMBOL(mdev_set_vfio_ops);
>
> +/* Specify the virtio device ops for the mdev device, this
> + * must be called during create() callback for virtio mdev device.
> + */
> +void mdev_set_virtio_ops(struct mdev_device *mdev,
> + const struct virtio_mdev_device_ops *virtio_ops)
> +{
> + BUG_ON(mdev->class_id);
Nit, this one is a BUG_ON, but the vfio one is a WARN_ON. Thanks,
Alex
> + mdev->class_id = MDEV_CLASS_ID_VIRTIO;
> + mdev->device_ops = virtio_ops;
> +}
> +EXPORT_SYMBOL(mdev_set_virtio_ops);
> +
> const void *mdev_get_dev_ops(struct mdev_device *mdev)
> {
> return mdev->device_ops;
> diff --git a/include/linux/mdev.h b/include/linux/mdev.h
> index 3d29e09e20c9..13e045e09d3b 100644
> --- a/include/linux/mdev.h
> +++ b/include/linux/mdev.h
> @@ -17,6 +17,7 @@
>
> struct mdev_device;
> struct vfio_mdev_device_ops;
> +struct virtio_mdev_device_ops;
>
> /*
> * Called by the parent device driver to set the device which represents
> @@ -111,6 +112,8 @@ void mdev_set_drvdata(struct mdev_device *mdev, void
> *data);
> const guid_t *mdev_uuid(struct mdev_device *mdev);
> void mdev_set_vfio_ops(struct mdev_device *mdev,
> const struct vfio_mdev_device_ops *vfio_ops);
> +void mdev_set_virtio_ops(struct mdev_device *mdev,
> + const struct virtio_mdev_device_ops *virtio_ops);
> const void *mdev_get_dev_ops(struct mdev_device *mdev);
>
> extern struct bus_type mdev_bus_type;
> @@ -127,6 +130,7 @@ struct mdev_device *mdev_from_dev(struct device *dev);
>
> enum {
> MDEV_CLASS_ID_VFIO = 1,
> + MDEV_CLASS_ID_VIRTIO = 2,
> /* New entries must be added here */
> };
>
> diff --git a/include/linux/virtio_mdev.h b/include/linux/virtio_mdev.h
> new file mode 100644
> index ..b965b50f9b24
> --- /dev/null
> +++ b/include/linux/virtio_mdev.h
> @@ -0,0 +1,151 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Virtio mediated device driver
> + *
> + * Copyright 2019, Red Hat Corp.
> + * Author: Jason Wang
> + */
> +#ifndef _LINUX_VIRTIO_MDEV_H
> +#define _LINUX_VIRTIO_MDEV_H
> +
> +#include
> +#include
> +#include
> +
> +#define VIRTIO_MDEV_DEVICE_API_STRING"virtio-mdev"
> +#define VIRTIO_MDEV_F_VERSION_1 0x1
> +
> +struct virtio_mdev_callback {
> + irqreturn_t (*callback)(void *data);
> + void *private;
> +};
> +
> +/**
> + * struct vfio_mdev_device_ops - Structure to be registered for each
> + * mdev device to register the device to virtio-mdev module.
> + *
> + * @set_vq_address: Set the address of virtqueue
> + * @mdev: mediated device
> + * @idx: virtqueue index
> + * @desc_area: address of desc area
> + * @driver_area: address of driver area
> + * @device_area: address of device area
> + * Returns integer: success (0) or error (< 0)
> + * @set_vq_num: Set the size of virtqueue
> + * @mdev: mediated device
> + * @idx: virtqueue index
> + * @num: the size of virtqueue
> + * @kick_vq: Kick the virtqueue
> + * @mdev: mediated device
> + * @idx: virtqueue index
> + * @set_vq_cb: Set the interrupt callback function for
> + * a virtqueue
> + * @mdev: mediated device
> + * @idx: virtqueue index
> + * @cb: virtio-mdev interrupt callback structure
> + * @set_vq_ready:Set ready status for a virtqueue
> + * @mdev: mediated device
> + * @idx: virtqueue index
> + * @ready: ready (true) not ready(false)
> + * @get_vq_ready:Get ready status for a virtqueue
> + * @mdev: mediated device
> + * @idx: virtqueue index
> + * Returns boolean: ready (true) or not (false)
> + * @set_vq_state:Set the state for a
Re: [PATCH V4 3/6] mdev: introduce device specific ops
On Thu, 17 Oct 2019 17:07:55 +0200 Cornelia Huck wrote: > On Thu, 17 Oct 2019 18:48:33 +0800 > Jason Wang wrote: > > > Currently, except for the create and remove, the rest of > > mdev_parent_ops is designed for vfio-mdev driver only and may not help > > for kernel mdev driver. With the help of class id, this patch > > introduces device specific callbacks inside mdev_device > > structure. This allows different set of callback to be used by > > vfio-mdev and virtio-mdev. > > > > Signed-off-by: Jason Wang > > --- > > .../driver-api/vfio-mediated-device.rst | 25 + > > MAINTAINERS | 1 + > > drivers/gpu/drm/i915/gvt/kvmgt.c | 18 --- > > drivers/s390/cio/vfio_ccw_ops.c | 18 --- > > drivers/s390/crypto/vfio_ap_ops.c | 14 +++-- > > drivers/vfio/mdev/mdev_core.c | 18 +-- > > drivers/vfio/mdev/mdev_private.h | 1 + > > drivers/vfio/mdev/vfio_mdev.c | 37 ++--- > > include/linux/mdev.h | 45 > > include/linux/vfio_mdev.h | 52 +++ > > samples/vfio-mdev/mbochs.c| 20 --- > > samples/vfio-mdev/mdpy.c | 20 --- > > samples/vfio-mdev/mtty.c | 18 --- > > 13 files changed, 184 insertions(+), 103 deletions(-) > > create mode 100644 include/linux/vfio_mdev.h > > > > diff --git a/Documentation/driver-api/vfio-mediated-device.rst > > b/Documentation/driver-api/vfio-mediated-device.rst > > index f9a78d75a67a..0cca84d19603 100644 > > --- a/Documentation/driver-api/vfio-mediated-device.rst > > +++ b/Documentation/driver-api/vfio-mediated-device.rst > > @@ -152,11 +152,22 @@ callbacks per mdev parent device, per mdev type, or > > any other categorization. > > Vendor drivers are expected to be fully asynchronous in this respect or > > provide their own internal resource protection.) > > > > -The callbacks in the mdev_parent_ops structure are as follows: > > - > > -* open: open callback of mediated device > > -* close: close callback of mediated device > > -* ioctl: ioctl callback of mediated device > > +As multiple types of mediated devices may be supported, the device > > +must set up the class id and the device specific callbacks in create() > > s/in create()/in the create()/ > > > +callback. E.g for vfio-mdev device it needs to be done through: > > "Each class provides a helper function to do so; e.g. for vfio-mdev > devices, the function to be called is:" > > ? > > > + > > +int mdev_set_vfio_ops(struct mdev_device *mdev, > > + const struct vfio_mdev_ops *vfio_ops); > > + > > +The class id (set to MDEV_CLASS_ID_VFIO) is used to match a device > > "(set by this helper function to MDEV_CLASS_ID_VFIO)" ? > > > +with an mdev driver via its id table. The device specific callbacks > > +(specified in *ops) are obtainable via mdev_get_dev_ops() (for use by > > "(specified in *vfio_ops by the caller)" ? > > > +the mdev bus driver). A vfio-mdev device (class id MDEV_CLASS_ID_VFIO) > > +uses the following device-specific ops: > > + > > +* open: open callback of vfio mediated device > > +* close: close callback of vfio mediated device > > +* ioctl: ioctl callback of vfio mediated device > > * read : read emulation callback > > * write: write emulation callback > > * mmap: mmap emulation callback > > @@ -167,10 +178,6 @@ register itself with the mdev core driver:: > > extern int mdev_register_device(struct device *dev, > > const struct mdev_parent_ops *ops); > > > > -It is also required to specify the class_id in create() callback through:: > > - > > - int mdev_set_class(struct mdev_device *mdev, u16 id); > > - > > I'm wondering if this patch set should start out with introducing > helper functions already (i.e. don't introduce mdev_set_class(), but > start out with mdev_set_class_vfio() which will gain the *vfio_ops > argument in this patch.) Yes, it would be cleaner, but is it really worth the churn? Correct me if I'm wrong, but I think we get to the same point after this patch and aside from the function name itself, the difference is really just that the class_id is briefly exposed to the parent driver, right? Thanks, Alex > > However, the mdev_parent_ops structure is not required in the function call > > that a driver should use to unregister itself with the mdev core driver:: > > > > (...) > > > diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c > > index 3a9c52d71b4e..d0f3113c8071 100644 > > --- a/drivers/vfio/mdev/mdev_core.c > > +++ b/drivers/vfio/mdev/mdev_core.c > > @@ -45,15 +45,23 @@ void mdev_set_drvdata(struct mdev_device *mdev, void > > *data) > > } > > EXPORT_SYMBOL(mdev_set_drvdata); > > > > -/* Specify the class for the mdev device, this must be called during >
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 12:13 PM Thierry Reding
wrote:
>
> On Thu, Oct 17, 2019 at 12:07:21PM -0500, Adam Ford wrote:
> > On Thu, Oct 17, 2019 at 10:14 AM Thierry Reding
> > wrote:
> > >
> > > On Thu, Oct 17, 2019 at 03:58:25PM +0200, Michal Vokáč wrote:
> > > > On 17. 10. 19 14:59, Thierry Reding wrote:
> > > > > On Thu, Oct 17, 2019 at 02:09:17PM +0200, Uwe Kleine-König wrote:
> > > > > > On Thu, Oct 17, 2019 at 01:11:31PM +0200, Thierry Reding wrote:
> > > > > > > On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> > > > > > > > On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > > > > > > > > On 17. 10. 19 10:10, Uwe Kleine-König wrote:
> > > > > > > > > > A previous change in the pwm core (namely 01ccf903edd6
> > > > > > > > > > ("pwm: Let
> > > > > > > > > > pwm_get_state() return the last implemented state"))
> > > > > > > > > > changed the
> > > > > > > > > > semantic of pwm_get_state() and disclosed an (as it seems)
> > > > > > > > > > common
> > > > > > > > > > problem in lowlevel PWM drivers. By not relying on the
> > > > > > > > > > period and duty
> > > > > > > > > > cycle being retrievable from a disabled PWM this type of
> > > > > > > > > > problem is
> > > > > > > > > > worked around.
> > > > > > > > > >
> > > > > > > > > > Apart from this issue only calling the
> > > > > > > > > > pwm_get_state/pwm_apply_state
> > > > > > > > > > combo once is also more effective.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Uwe Kleine-König
> > > > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > > Hello,
> > > > > > > > > >
> > > > > > > > > > There are now two reports about 01ccf903edd6 breaking a
> > > > > > > > > > backlight. As
> > > > > > > > > > far as I understand the problem this is a combination of
> > > > > > > > > > the backend pwm
> > > > > > > > > > driver yielding surprising results and the pwm-bl driver
> > > > > > > > > > doing things
> > > > > > > > > > more complicated than necessary.
> > > > > > > > > >
> > > > > > > > > > So I guess this patch works around these problems. Still it
> > > > > > > > > > would be
> > > > > > > > > > interesting to find out the details in the imx driver that
> > > > > > > > > > triggers the
> > > > > > > > > > problem. So Adam, can you please instrument the pwm-imx27
> > > > > > > > > > driver to
> > > > > > > > > > print *state at the beginning of pwm_imx27_apply() and the
> > > > > > > > > > end of
> > > > > > > > > > pwm_imx27_get_state() and provide the results?
> > > > > > > > > >
> > > > > > > > > > Note I only compile tested this change.
> > > > > > > > >
> > > > > > > > > Hi Uwe,
> > > > > > > > > I was just about to respond to the "pwm_bl on i.MX6Q broken
> > > > > > > > > on 5.4-RC1+"
> > > > > > > > > thread that I have a similar problem when you submitted this
> > > > > > > > > patch.
> > > > > > > > >
> > > > > > > > > So here are my few cents:
> > > > > > > > >
> > > > > > > > > My setup is as follows:
> > > > > > > > > - imx6dl-yapp4-draco with i.MX6Solo
> > > > > > > > > - backlight is controlled with inverted PWM signal
> > > > > > > > > - max brightness level = 32, default brightness level set
> > > > > > > > > to 32 in DT.
> > > > > > > > >
> > > > > > > > > 1. Almost correct backlight behavior before 01ccf903edd6
> > > > > > > > > ("pwm: Let
> > > > > > > > > pwm_get_state() return the last implemented state):
> > > > > > > > >
> > > > > > > > > - System boots to userspace and backlight is enabled all
> > > > > > > > > the time from
> > > > > > > > > power up.
> > > > > > > > >
> > > > > > > > > $ dmesg | grep state
> > > > > > > > > [1.763381] get state end: -1811360608, enabled: 0
> > > > > > > >
> > > > > > > > What is -1811360608? When I wrote "print *state" above, I
> > > > > > > > thought about
> > > > > > > > something like:
> > > > > > > >
> > > > > > > > pr_info("%s: period: %u, duty: %u, polarity: %d, enabled:
> > > > > > > > %d",
> > > > > > > > __func__, state->period, state->duty_cycle,
> > > > > > > > state->polarity, state->enabled);
> > > > > > > >
> > > > > > > > A quick look into drivers/pwm/pwm-imx27.c shows that this is
> > > > > > > > another
> > > > > > > > driver that yields duty_cycle = 0 when the hardware is off.
> > > > > > >
> > > > > > > It seems to me like the best recourse to fix this for now would
> > > > > > > be to
> > > > > > > patch up the drivers that return 0 when the hardware is off by
> > > > > > > caching
> > > > > > > the currently configured duty cycle.
> > > > > > >
> > > > > > > How about the patch below?
> > > > > > >
> > > > > > > Thierry
> > > > > > >
> > > > > > > --- >8 ---
> > > > > > > From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17
> > > > > > > 00:00:00 2001
> > > > > > > From: Thierry Reding
> > > > > > > Date: Thu, 17 Oct 2019 12:56:00 +0200
> > > > > > > Subject: [PATCH] pwm: imx27: Cache duty cycle register value
> > > > > > >
> > > > > > > The
Re: [PATCH] drm/amdgpu/display: fix compile error
This has already been fixed here: https://patchwork.freedesktop.org/patch/336195/ Should be mirrored on Alex's tree soon. Thanks, Leo On 2019-10-17 2:19 a.m., Chen Wandun wrote: > From: Chenwandun > > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:1913:48: > error: struct dc_crtc_timing_flags has no member named DSC >if (res_ctx->pipe_ctx[i].stream->timing.flags.DSC) > ^ > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:1914:73: > error: struct dc_crtc_timing has no member named dsc_cfg >pipes[pipe_cnt].dout.output_bpp = > res_ctx->pipe_ctx[i].stream->timing.dsc_cfg.bits_per_pixel / 16.0; > ^ > Signed-off-by: Chenwandun > --- > drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c > b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c > index 914e378..4f03318 100644 > --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c > +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c > @@ -1910,8 +1910,10 @@ int dcn20_populate_dml_pipes_from_context( > pipes[pipe_cnt].dout.output_bpp = output_bpc * 3; > } > > +#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT > if (res_ctx->pipe_ctx[i].stream->timing.flags.DSC) > pipes[pipe_cnt].dout.output_bpp = > res_ctx->pipe_ctx[i].stream->timing.dsc_cfg.bits_per_pixel / 16.0; > +#endif > > /* todo: default max for now, until there is logic reflecting > this in dc*/ > pipes[pipe_cnt].dout.output_bpc = 12; > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH RESEND] drm/amd/display: Add back missing backlight level rounding
Thanks for the detailed notes! See reply inline.
On 2019-10-15 4:03 p.m., Lukáš Krejčí wrote:
> [Why]
> Having the rounding of the backlight value restored to the way it was
> seemingly gets rid of backlight flickering on certain Stoney Ridge
> laptops.
>
> [How]
> Rescale the backlight level between min and max input signal value and
> round it to a number between 0x0 and 0xFF. Then, use the rounding mode
> that was previously in driver_set_backlight_level() and
> dmcu_set_backlight_level(), i.e. rescale the backlight level between 0x0
> and 0x1000 by multiplying it by 0x101 and use the most significant bit
> of the fraction (or in this case the 8th bit of the value because it's
> the same thing, e.g. C3 * 0x101 = 0xC3C3 and C3 * 0x10101 = 0xC3C3C3) to
> round it.
>
> Fixes: 262485a50fd4 ("drm/amd/display: Expand dc to use 16.16 bit backlight")
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204957
> Signed-off-by: Lukáš Krejčí
> ---
>
> Notes:
> Bug:
> - Can be reproduced on HP 15-rb020nc (Stoney Ridge R2 E2-9000e APU) and
> Acer Aspire 3 A315-21G-91JL (Stoney Ridge R3 A4-9120 APU).
>
> - For me, the bug is inconsistent - it does not happen on every boot,
> but if it does happen, it's usually within three minutes after bootup.
>
> - It concerns the backlight. That means it can be reproduced on the
> framebuffer console.
>
> - Reproduces on Arch Linux (custom built) live CD, linux kernel v5.3.2
> and Ubuntu 19.04, kernel-ppa/mainline v5.0.0-rc1, v5.0.0, v5.3.2,
> v5.3.4,
> v5.4-rc2.
>
> - Can not be reproduced on kernel v5.3.4 with this patch applied or on
> v4.20.0, 4.20.17, 4.19.75 (this bug is a regression).
>
> - The other person that reproduced the issue (see the Bugzilla link
> above) confirmed that the patch works for them too.
>
> Patch:
> - Is the comment modified by this commit correct? Both
> driver_set_backlight_level() and dmcu_set_backlight_level() check the
> 17th bit of `brightness` aka `backlight_pwm_u16_16`, but
> 262485a50fd4532a8d71165190adc7a0a19bcc9e ("drm/amd/display: Expand dc
> to use 16.16 bit backlight") specifically mentions 0x as the max
> backlight value>
> - use_smooth_brightness is false (no DMCU firmware available) on my
> laptop, so the other code path (dmcu_set_backlight_level()) is
> untested.
>
> - I'm not sure why the rounding fixes the issue and whether this
> function is the right place to add back the rounding (and whether it
> even is the right way to solve the issue), so that's why this patch is
> RFC.
We've seen some similar issues when fractional duty cycles are enabled for
backlight pwm.
I attached a hack to the bugzilla ticket that disables it, please give that
patch a shot
first. I'd rather not change this calculation for all panels if the flickering
issue is
only a quirk for some.
Thanks,
Leo
>
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index a52f0b13a2c8..af9a5f46b671 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2083,17 +2083,22 @@ static int amdgpu_dm_backlight_update_status(struct
> backlight_device *bd)
>* The brightness input is in the range 0-255
>* It needs to be rescaled to be between the
>* requested min and max input signal
> - *
> - * It also needs to be scaled up by 0x101 to
> - * match the DC interface which has a range of
> - * 0 to 0x
>*/
> brightness =
> brightness
> - * 0x101
> + * 0x100
> * (caps.max_input_signal - caps.min_input_signal)
> / AMDGPU_MAX_BL_LEVEL
> - + caps.min_input_signal * 0x101;
> + + caps.min_input_signal * 0x100;
> +
> + brightness = (brightness >> 8) + ((brightness >> 7) & 1);
> + /*
> + * It also needs to be scaled up by 0x101 and
> + * rounded off to match the DC interface which
> + * has a range of 0 to 0x1
> + */
> + brightness *= 0x101;
> + brightness += (brightness >> 7) & 1;
>
> if (dc_link_set_backlight_level(dm->backlight_link,
> brightness, 0))
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 12:07:21PM -0500, Adam Ford wrote:
> On Thu, Oct 17, 2019 at 10:14 AM Thierry Reding
> wrote:
> >
> > On Thu, Oct 17, 2019 at 03:58:25PM +0200, Michal Vokáč wrote:
> > > On 17. 10. 19 14:59, Thierry Reding wrote:
> > > > On Thu, Oct 17, 2019 at 02:09:17PM +0200, Uwe Kleine-König wrote:
> > > > > On Thu, Oct 17, 2019 at 01:11:31PM +0200, Thierry Reding wrote:
> > > > > > On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> > > > > > > On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > > > > > > > On 17. 10. 19 10:10, Uwe Kleine-König wrote:
> > > > > > > > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm:
> > > > > > > > > Let
> > > > > > > > > pwm_get_state() return the last implemented state")) changed
> > > > > > > > > the
> > > > > > > > > semantic of pwm_get_state() and disclosed an (as it seems)
> > > > > > > > > common
> > > > > > > > > problem in lowlevel PWM drivers. By not relying on the period
> > > > > > > > > and duty
> > > > > > > > > cycle being retrievable from a disabled PWM this type of
> > > > > > > > > problem is
> > > > > > > > > worked around.
> > > > > > > > >
> > > > > > > > > Apart from this issue only calling the
> > > > > > > > > pwm_get_state/pwm_apply_state
> > > > > > > > > combo once is also more effective.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Uwe Kleine-König
> > > > > > > > >
> > > > > > > > > ---
> > > > > > > > > Hello,
> > > > > > > > >
> > > > > > > > > There are now two reports about 01ccf903edd6 breaking a
> > > > > > > > > backlight. As
> > > > > > > > > far as I understand the problem this is a combination of the
> > > > > > > > > backend pwm
> > > > > > > > > driver yielding surprising results and the pwm-bl driver
> > > > > > > > > doing things
> > > > > > > > > more complicated than necessary.
> > > > > > > > >
> > > > > > > > > So I guess this patch works around these problems. Still it
> > > > > > > > > would be
> > > > > > > > > interesting to find out the details in the imx driver that
> > > > > > > > > triggers the
> > > > > > > > > problem. So Adam, can you please instrument the pwm-imx27
> > > > > > > > > driver to
> > > > > > > > > print *state at the beginning of pwm_imx27_apply() and the
> > > > > > > > > end of
> > > > > > > > > pwm_imx27_get_state() and provide the results?
> > > > > > > > >
> > > > > > > > > Note I only compile tested this change.
> > > > > > > >
> > > > > > > > Hi Uwe,
> > > > > > > > I was just about to respond to the "pwm_bl on i.MX6Q broken on
> > > > > > > > 5.4-RC1+"
> > > > > > > > thread that I have a similar problem when you submitted this
> > > > > > > > patch.
> > > > > > > >
> > > > > > > > So here are my few cents:
> > > > > > > >
> > > > > > > > My setup is as follows:
> > > > > > > > - imx6dl-yapp4-draco with i.MX6Solo
> > > > > > > > - backlight is controlled with inverted PWM signal
> > > > > > > > - max brightness level = 32, default brightness level set to
> > > > > > > > 32 in DT.
> > > > > > > >
> > > > > > > > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm:
> > > > > > > > Let
> > > > > > > > pwm_get_state() return the last implemented state):
> > > > > > > >
> > > > > > > > - System boots to userspace and backlight is enabled all the
> > > > > > > > time from
> > > > > > > > power up.
> > > > > > > >
> > > > > > > > $ dmesg | grep state
> > > > > > > > [1.763381] get state end: -1811360608, enabled: 0
> > > > > > >
> > > > > > > What is -1811360608? When I wrote "print *state" above, I thought
> > > > > > > about
> > > > > > > something like:
> > > > > > >
> > > > > > > pr_info("%s: period: %u, duty: %u, polarity: %d, enabled:
> > > > > > > %d",
> > > > > > > __func__, state->period, state->duty_cycle,
> > > > > > > state->polarity, state->enabled);
> > > > > > >
> > > > > > > A quick look into drivers/pwm/pwm-imx27.c shows that this is
> > > > > > > another
> > > > > > > driver that yields duty_cycle = 0 when the hardware is off.
> > > > > >
> > > > > > It seems to me like the best recourse to fix this for now would be
> > > > > > to
> > > > > > patch up the drivers that return 0 when the hardware is off by
> > > > > > caching
> > > > > > the currently configured duty cycle.
> > > > > >
> > > > > > How about the patch below?
> > > > > >
> > > > > > Thierry
> > > > > >
> > > > > > --- >8 ---
> > > > > > From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00
> > > > > > 2001
> > > > > > From: Thierry Reding
> > > > > > Date: Thu, 17 Oct 2019 12:56:00 +0200
> > > > > > Subject: [PATCH] pwm: imx27: Cache duty cycle register value
> > > > > >
> > > > > > The hardware register containing the duty cycle value cannot be
> > > > > > accessed
> > > > > > when the PWM is disabled. This causes the ->get_state() callback to
> > > > > > read
> > > > > > back a duty cycle value of 0, which can confuse consumer drivers.
> > > > > >
> > > >
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 10:14 AM Thierry Reding
wrote:
>
> On Thu, Oct 17, 2019 at 03:58:25PM +0200, Michal Vokáč wrote:
> > On 17. 10. 19 14:59, Thierry Reding wrote:
> > > On Thu, Oct 17, 2019 at 02:09:17PM +0200, Uwe Kleine-König wrote:
> > > > On Thu, Oct 17, 2019 at 01:11:31PM +0200, Thierry Reding wrote:
> > > > > On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> > > > > > On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > > > > > > On 17. 10. 19 10:10, Uwe Kleine-König wrote:
> > > > > > > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm:
> > > > > > > > Let
> > > > > > > > pwm_get_state() return the last implemented state")) changed the
> > > > > > > > semantic of pwm_get_state() and disclosed an (as it seems)
> > > > > > > > common
> > > > > > > > problem in lowlevel PWM drivers. By not relying on the period
> > > > > > > > and duty
> > > > > > > > cycle being retrievable from a disabled PWM this type of
> > > > > > > > problem is
> > > > > > > > worked around.
> > > > > > > >
> > > > > > > > Apart from this issue only calling the
> > > > > > > > pwm_get_state/pwm_apply_state
> > > > > > > > combo once is also more effective.
> > > > > > > >
> > > > > > > > Signed-off-by: Uwe Kleine-König
> > > > > > > > ---
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > There are now two reports about 01ccf903edd6 breaking a
> > > > > > > > backlight. As
> > > > > > > > far as I understand the problem this is a combination of the
> > > > > > > > backend pwm
> > > > > > > > driver yielding surprising results and the pwm-bl driver doing
> > > > > > > > things
> > > > > > > > more complicated than necessary.
> > > > > > > >
> > > > > > > > So I guess this patch works around these problems. Still it
> > > > > > > > would be
> > > > > > > > interesting to find out the details in the imx driver that
> > > > > > > > triggers the
> > > > > > > > problem. So Adam, can you please instrument the pwm-imx27
> > > > > > > > driver to
> > > > > > > > print *state at the beginning of pwm_imx27_apply() and the end
> > > > > > > > of
> > > > > > > > pwm_imx27_get_state() and provide the results?
> > > > > > > >
> > > > > > > > Note I only compile tested this change.
> > > > > > >
> > > > > > > Hi Uwe,
> > > > > > > I was just about to respond to the "pwm_bl on i.MX6Q broken on
> > > > > > > 5.4-RC1+"
> > > > > > > thread that I have a similar problem when you submitted this
> > > > > > > patch.
> > > > > > >
> > > > > > > So here are my few cents:
> > > > > > >
> > > > > > > My setup is as follows:
> > > > > > > - imx6dl-yapp4-draco with i.MX6Solo
> > > > > > > - backlight is controlled with inverted PWM signal
> > > > > > > - max brightness level = 32, default brightness level set to 32
> > > > > > > in DT.
> > > > > > >
> > > > > > > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm:
> > > > > > > Let
> > > > > > > pwm_get_state() return the last implemented state):
> > > > > > >
> > > > > > > - System boots to userspace and backlight is enabled all the
> > > > > > > time from
> > > > > > > power up.
> > > > > > >
> > > > > > > $ dmesg | grep state
> > > > > > > [1.763381] get state end: -1811360608, enabled: 0
> > > > > >
> > > > > > What is -1811360608? When I wrote "print *state" above, I thought
> > > > > > about
> > > > > > something like:
> > > > > >
> > > > > > pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
> > > > > > __func__, state->period, state->duty_cycle,
> > > > > > state->polarity, state->enabled);
> > > > > >
> > > > > > A quick look into drivers/pwm/pwm-imx27.c shows that this is another
> > > > > > driver that yields duty_cycle = 0 when the hardware is off.
> > > > >
> > > > > It seems to me like the best recourse to fix this for now would be to
> > > > > patch up the drivers that return 0 when the hardware is off by caching
> > > > > the currently configured duty cycle.
> > > > >
> > > > > How about the patch below?
> > > > >
> > > > > Thierry
> > > > >
> > > > > --- >8 ---
> > > > > From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00
> > > > > 2001
> > > > > From: Thierry Reding
> > > > > Date: Thu, 17 Oct 2019 12:56:00 +0200
> > > > > Subject: [PATCH] pwm: imx27: Cache duty cycle register value
> > > > >
> > > > > The hardware register containing the duty cycle value cannot be
> > > > > accessed
> > > > > when the PWM is disabled. This causes the ->get_state() callback to
> > > > > read
> > > > > back a duty cycle value of 0, which can confuse consumer drivers.
> > > > >
> > > > > Signed-off-by: Thierry Reding
> > > > > ---
> > > > > drivers/pwm/pwm-imx27.c | 31 ---
> > > > > 1 file changed, 24 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> > > > > index ae11d8577f18..4113d5cd4c62 100644
> > > > > --- a/drivers/pwm/pwm-imx27.c
> > > > >
Re: [PATCH v4 06/11] drm/ttm: factor out ttm_bo_mmap_vma_setup
Am 17.10.19 um 14:30 schrieb Gerd Hoffmann: > On Thu, Oct 17, 2019 at 11:06:33AM +, Koenig, Christian wrote: >> Am 16.10.19 um 14:18 schrieb Christian König: >>> Am 16.10.19 um 13:51 schrieb Gerd Hoffmann: Factor out ttm vma setup to a new function. Reduces code duplication a bit. v2: don't change vm_flags (moved to separate patch). v4: make ttm_bo_mmap_vma_setup static. Signed-off-by: Gerd Hoffmann >>> Reviewed-by: Christian König for this one >>> and #7 in the series. >> Any objections that I add these two to my drm-ttm-next pull request or >> did you wanted to merge that through some other tree? > Pushed series to drm-misc-next a few minutes ago (before I saw your mail). No, problem. That works for me as well. > > cheers, >Gerd >
Re: [PATCH hmm 00/15] Consolidate the mmu notifier interval_tree and locking
Sending once more as text.
Am 17.10.19 um 18:26 schrieb Yang, Philip:
> On 2019-10-17 4:54 a.m., Christian König wrote:
>> Am 16.10.19 um 18:04 schrieb Jason Gunthorpe:
>>> On Wed, Oct 16, 2019 at 10:58:02AM +0200, Christian König wrote:
Am 15.10.19 um 20:12 schrieb Jason Gunthorpe:
> From: Jason Gunthorpe
>
> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp,
> hfi1,
> scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
> they only use invalidate_range_start/end and immediately check the
> invalidating range against some driver data structure to tell if the
> driver is interested. Half of them use an interval_tree, the others are
> simple linear search lists.
>
> Of the ones I checked they largely seem to have various kinds of races,
> bugs and poor implementation. This is a result of the complexity in how
> the notifier interacts with get_user_pages(). It is extremely
> difficult to
> use it correctly.
>
> Consolidate all of this code together into the core mmu_notifier and
> provide a locking scheme similar to hmm_mirror that allows the user to
> safely use get_user_pages() and reliably know if the page list still
> matches the mm.
That sounds really good, but could you outline for a moment how that is
archived?
>>> It uses the same basic scheme as hmm and rdma odp, outlined in the
>>> revisions to hmm.rst later on.
>>>
>>> Basically,
>>>
>>> seq = mmu_range_read_begin();
>>>
>>> // This is a speculative region
>>> .. get_user_pages()/hmm_range_fault() ..
>> How do we enforce that this get_user_pages()/hmm_range_fault() doesn't
>> see outdated page table information?
>>
>> In other words how the the following race prevented:
>>
>> CPU A CPU B
>> invalidate_range_start()
>> mmu_range_read_begin()
>> get_user_pages()/hmm_range_fault()
>> Updating the ptes
>> invalidate_range_end()
>>
>>
>> I mean get_user_pages() tries to circumvent this issue by grabbing a
>> reference to the pages in question, but that isn't sufficient for the
>> SVM use case.
>>
>> That's the reason why we had this horrible solution with a r/w lock and
>> a linked list of BOs in an interval tree.
>>
>> Regards,
>> Christian.
> get_user_pages/hmm_range_fault() and invalidate_range_start() both are
> called while holding mm->map_sem, so they are always serialized.
Not even remotely.
For calling get_user_pages()/hmm_range_fault() you only need to hold the
mmap_sem in read mode.
And IIRC invalidate_range_start() is sometimes called without holding
the mmap_sem at all.
So again how are they serialized?
Regards,
Christian.
>
> Philip
>>> // Result cannot be derferenced
>>>
>>> take_lock(driver->update);
>>> if (mmu_range_read_retry(, range.notifier_seq) {
>>> // collision! The results are not correct
>>> goto again
>>> }
>>>
>>> // no collision, and now under lock. Now we can de-reference the
>>> pages/etc
>>> // program HW
>>> // Now the invalidate callback is responsible to synchronize against
>>> changes
>>> unlock(driver->update)
>>>
>>> Basically, anything that was using hmm_mirror correctly transisions
>>> over fairly trivially, just with the modification to store a sequence
>>> number to close that race described in the hmm commit.
>>>
>>> For something like AMD gpu I expect it to transition to use dma_fence
>>> from the notifier for coherency right before it unlocks driver->update.
>>>
>>> Jason
>>> ___
>>> amd-gfx mailing list
>>> amd-...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 00/15] Consolidate the mmu notifier interval_tree and locking
Am 17.10.2019 18:26 schrieb "Yang, Philip" :
On 2019-10-17 4:54 a.m., Christian König wrote:
> Am 16.10.19 um 18:04 schrieb Jason Gunthorpe:
>> On Wed, Oct 16, 2019 at 10:58:02AM +0200, Christian König wrote:
>>> Am 15.10.19 um 20:12 schrieb Jason Gunthorpe:
From: Jason Gunthorpe
8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp,
hfi1,
scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
they only use invalidate_range_start/end and immediately check the
invalidating range against some driver data structure to tell if the
driver is interested. Half of them use an interval_tree, the others are
simple linear search lists.
Of the ones I checked they largely seem to have various kinds of races,
bugs and poor implementation. This is a result of the complexity in how
the notifier interacts with get_user_pages(). It is extremely
difficult to
use it correctly.
Consolidate all of this code together into the core mmu_notifier and
provide a locking scheme similar to hmm_mirror that allows the user to
safely use get_user_pages() and reliably know if the page list still
matches the mm.
>>> That sounds really good, but could you outline for a moment how that is
>>> archived?
>> It uses the same basic scheme as hmm and rdma odp, outlined in the
>> revisions to hmm.rst later on.
>>
>> Basically,
>>
>> seq = mmu_range_read_begin();
>>
>> // This is a speculative region
>> .. get_user_pages()/hmm_range_fault() ..
>
> How do we enforce that this get_user_pages()/hmm_range_fault() doesn't
> see outdated page table information?
>
> In other words how the the following race prevented:
>
> CPU A CPU B
> invalidate_range_start()
>mmu_range_read_begin()
>get_user_pages()/hmm_range_fault()
> Updating the ptes
> invalidate_range_end()
>
>
> I mean get_user_pages() tries to circumvent this issue by grabbing a
> reference to the pages in question, but that isn't sufficient for the
> SVM use case.
>
> That's the reason why we had this horrible solution with a r/w lock and
> a linked list of BOs in an interval tree.
>
> Regards,
> Christian.
get_user_pages/hmm_range_fault() and invalidate_range_start() both are
called while holding mm->map_sem, so they are always serialized.
Not even remotely.
For calling get_user_pages()/hmm_range_fault() you only need to hold the
mmap_sem in read mode.
And IIRC invalidate_range_start() is sometimes called without holding the
mmap_sem at all.
So again how are they serialized?
Regards,
Christian.
Philip
>
>> // Result cannot be derferenced
>>
>> take_lock(driver->update);
>> if (mmu_range_read_retry(, range.notifier_seq) {
>> // collision! The results are not correct
>> goto again
>> }
>>
>> // no collision, and now under lock. Now we can de-reference the
>> pages/etc
>> // program HW
>> // Now the invalidate callback is responsible to synchronize against
>> changes
>> unlock(driver->update)
>>
>> Basically, anything that was using hmm_mirror correctly transisions
>> over fairly trivially, just with the modification to store a sequence
>> number to close that race described in the hmm commit.
>>
>> For something like AMD gpu I expect it to transition to use dma_fence
>> from the notifier for coherency right before it unlocks driver->update.
>>
>> Jason
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/mipi_dbi: Use simple right shift instead of double negation
Den 17.10.2019 13.49, skrev Andy Shevchenko: > GCC complains about dubious bitwise OR operand: > > drivers/gpu/drm/drm_mipi_dbi.c:1024:49: warning: dubious: x | !y > CC [M] drivers/gpu/drm/drm_mipi_dbi.o > > As long as buffer is consist of byte (u8) values, we may use > simple right shift and satisfy compiler. It also reduces amount of > operations needed. > > Signed-off-by: Andy Shevchenko > --- Thanks, it's even more readable now, for me at least. And since I don't trust my in-head C compiler/parser, I ran a test and /sys/kernel/debug/dri/0/command returns the same for commands 04H and 09h which are the ones affected by this change. Reviewed-by: Noralf Trønnes Tested-by: Noralf Trønnes This patch hasn't shown up in dri-devel patchwork, I hope it's just a hiccup and it'll show up later since I apply patches from patchwork. I don't see it in the mailinglist archive either, only Sean's replies, not yours. But I do see your replies to other patches. We'll see. If not then I'll have to export it from Windows Thunderbird and fix newlines :/ Noralf. > drivers/gpu/drm/drm_mipi_dbi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c > index 1961f713aaab..445e88b1fc9a 100644 > --- a/drivers/gpu/drm/drm_mipi_dbi.c > +++ b/drivers/gpu/drm/drm_mipi_dbi.c > @@ -1021,7 +1021,7 @@ static int mipi_dbi_typec3_command_read(struct mipi_dbi > *dbi, u8 *cmd, > unsigned int i; > > for (i = 0; i < len; i++) > - data[i] = (buf[i] << 1) | !!(buf[i + 1] & BIT(7)); > + data[i] = (buf[i] << 1) | (buf[i + 1] >> 7); > } > > MIPI_DBI_DEBUG_COMMAND(*cmd, data, len); > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 00/15] Consolidate the mmu notifier interval_tree and locking
On 2019-10-17 4:54 a.m., Christian König wrote:
> Am 16.10.19 um 18:04 schrieb Jason Gunthorpe:
>> On Wed, Oct 16, 2019 at 10:58:02AM +0200, Christian König wrote:
>>> Am 15.10.19 um 20:12 schrieb Jason Gunthorpe:
From: Jason Gunthorpe
8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp,
hfi1,
scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
they only use invalidate_range_start/end and immediately check the
invalidating range against some driver data structure to tell if the
driver is interested. Half of them use an interval_tree, the others are
simple linear search lists.
Of the ones I checked they largely seem to have various kinds of races,
bugs and poor implementation. This is a result of the complexity in how
the notifier interacts with get_user_pages(). It is extremely
difficult to
use it correctly.
Consolidate all of this code together into the core mmu_notifier and
provide a locking scheme similar to hmm_mirror that allows the user to
safely use get_user_pages() and reliably know if the page list still
matches the mm.
>>> That sounds really good, but could you outline for a moment how that is
>>> archived?
>> It uses the same basic scheme as hmm and rdma odp, outlined in the
>> revisions to hmm.rst later on.
>>
>> Basically,
>>
>> seq = mmu_range_read_begin();
>>
>> // This is a speculative region
>> .. get_user_pages()/hmm_range_fault() ..
>
> How do we enforce that this get_user_pages()/hmm_range_fault() doesn't
> see outdated page table information?
>
> In other words how the the following race prevented:
>
> CPU A CPU B
> invalidate_range_start()
> mmu_range_read_begin()
> get_user_pages()/hmm_range_fault()
> Updating the ptes
> invalidate_range_end()
>
>
> I mean get_user_pages() tries to circumvent this issue by grabbing a
> reference to the pages in question, but that isn't sufficient for the
> SVM use case.
>
> That's the reason why we had this horrible solution with a r/w lock and
> a linked list of BOs in an interval tree.
>
> Regards,
> Christian.
get_user_pages/hmm_range_fault() and invalidate_range_start() both are
called while holding mm->map_sem, so they are always serialized.
Philip
>
>> // Result cannot be derferenced
>>
>> take_lock(driver->update);
>> if (mmu_range_read_retry(, range.notifier_seq) {
>> // collision! The results are not correct
>> goto again
>> }
>>
>> // no collision, and now under lock. Now we can de-reference the
>> pages/etc
>> // program HW
>> // Now the invalidate callback is responsible to synchronize against
>> changes
>> unlock(driver->update)
>>
>> Basically, anything that was using hmm_mirror correctly transisions
>> over fairly trivially, just with the modification to store a sequence
>> number to close that race described in the hmm commit.
>>
>> For something like AMD gpu I expect it to transition to use dma_fence
>> from the notifier for coherency right before it unlocks driver->update.
>>
>> Jason
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/15] staging/mgakms: Update matroxfb driver code for DRM
Hi Thomas, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.4-rc3 next-20191014] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/DRM-fbconv-helpers-for-converting-fbdev-drivers/20191015-152231 config: arm64-allyesconfig (attached as .config) compiler: aarch64-linux-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): drivers/staging/mgakms/g450_pll.o: In function `__crc_g450_mnp2f': >> g450_pll.c:(*ABS*+0x3559243b): multiple definition of `__crc_g450_mnp2f' drivers/staging/mgakms/g450_pll.o: In function `__crc_matroxfb_g450_setclk': >> g450_pll.c:(*ABS*+0xb4e884b9): multiple definition of >> `__crc_matroxfb_g450_setclk' drivers/staging/mgakms/g450_pll.o: In function `matroxfb_g450_setclk': >> g450_pll.c:(.text+0x1fe8): multiple definition of `matroxfb_g450_setclk' drivers/video/fbdev/matrox/g450_pll.o:g450_pll.c:(.text+0x1fe8): first defined here drivers/staging/mgakms/g450_pll.o: In function `g450_mnp2f': >> g450_pll.c:(.text+0x0): multiple definition of `g450_mnp2f' drivers/video/fbdev/matrox/g450_pll.o:g450_pll.c:(.text+0x0): first defined here drivers/staging/mgakms/g450_pll.o: In function `matroxfb_g450_setpll_cond': >> g450_pll.c:(.text+0x258): multiple definition of `matroxfb_g450_setpll_cond' drivers/video/fbdev/matrox/g450_pll.o:g450_pll.c:(.text+0x258): first defined here drivers/staging/mgakms/g450_pll.o: In function `__crc_matroxfb_g450_setpll_cond': >> g450_pll.c:(*ABS*+0x92a49e90): multiple definition of >> `__crc_matroxfb_g450_setpll_cond' drivers/staging/mgakms/matroxfb_accel.o: In function `matrox_cfbX_init': >> matroxfb_accel.c:(.text+0x78): multiple definition of `matrox_cfbX_init' drivers/video/fbdev/matrox/matroxfb_accel.o:matroxfb_accel.c:(.text+0x78): first defined here drivers/staging/mgakms/matroxfb_accel.o: In function `__crc_matrox_cfbX_init': >> matroxfb_accel.c:(*ABS*+0x30cc4dd3): multiple definition of >> `__crc_matrox_cfbX_init' drivers/staging/mgakms/matroxfb_base.o: In function `__crc_matroxfb_enable_irq': >> matroxfb_base.c:(*ABS*+0xcf34e848): multiple definition of >> `__crc_matroxfb_enable_irq' drivers/staging/mgakms/matroxfb_base.o: In function `__crc_matroxfb_register_driver': >> matroxfb_base.c:(*ABS*+0x1294ef50): multiple definition of >> `__crc_matroxfb_register_driver' drivers/staging/mgakms/matroxfb_base.o: In function `matroxfb_enable_irq': >> matroxfb_base.c:(.text+0x1130): multiple definition of `matroxfb_enable_irq' drivers/video/fbdev/matrox/matroxfb_base.o:matroxfb_base.c:(.text+0x1108): first defined here drivers/staging/mgakms/matroxfb_base.o: In function `__crc_matroxfb_unregister_driver': >> matroxfb_base.c:(*ABS*+0x6a5fc443): multiple definition of >> `__crc_matroxfb_unregister_driver' drivers/staging/mgakms/matroxfb_base.o: In function `matroxfb_register_driver': >> matroxfb_base.c:(.text+0x3e8): multiple definition of >> `matroxfb_register_driver' drivers/video/fbdev/matrox/matroxfb_base.o:matroxfb_base.c:(.text+0x3c8): first defined here drivers/staging/mgakms/matroxfb_base.o: In function `matroxfb_wait_for_sync': >> matroxfb_base.c:(.text+0x13a0): multiple definition of >> `matroxfb_wait_for_sync' drivers/video/fbdev/matrox/matroxfb_base.o:matroxfb_base.c:(.text+0x1378): first defined here drivers/staging/mgakms/matroxfb_base.o: In function `__crc_matroxfb_wait_for_sync': >> matroxfb_base.c:(*ABS*+0x299ca154): multiple definition of >> `__crc_matroxfb_wait_for_sync' drivers/staging/mgakms/matroxfb_base.o: In function `matroxfb_unregister_driver': >> matroxfb_base.c:(.text+0x540): multiple definition of >> `matroxfb_unregister_driver' drivers/video/fbdev/matrox/matroxfb_base.o:matroxfb_base.c:(.text+0x520): first defined here >> drivers/staging/mgakms/matroxfb_DAC1064.o:(.data+0xc0): multiple definition >> of `matrox_G100' drivers/video/fbdev/matrox/matroxfb_DAC1064.o:(.data+0xc0): first defined here drivers/staging/mgakms/matroxfb_DAC1064.o: In function `__crc_DAC1064_global_init': >> matroxfb_DAC1064.c:(*ABS*+0xd101267): multiple definition of >> `__crc_DAC1064_global_init' drivers/staging/mgakms/matroxfb_DAC1064.o: In function `__crc_DAC1064_global_restore': >> matroxfb_DAC1064.c:(*ABS*+0xf73a4dac): multiple definition of >> `__crc_DAC1064_global_restore' >>
Re: [PATCH v2 15/15] staging/mgakms: Update matroxfb driver code for DRM
Hi Thomas, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.4-rc3 next-20191017] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/DRM-fbconv-helpers-for-converting-fbdev-drivers/20191015-152231 config: x86_64-allyesconfig (attached as .config) compiler: gcc-7 (Debian 7.4.0-13) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): ld: drivers/staging/mgakms/g450_pll.o: in function `__crc_g450_mnp2f': (*ABS*+0x456b8a98): multiple definition of `__crc_g450_mnp2f' ld: drivers/staging/mgakms/g450_pll.o: in function `__crc_matroxfb_g450_setclk': (*ABS*+0x4da4fa96): multiple definition of `__crc_matroxfb_g450_setclk' ld: drivers/staging/mgakms/g450_pll.o: in function `matroxfb_g450_setclk': >> (.text+0x5b0): multiple definition of `matroxfb_g450_setclk'; >> drivers/video/fbdev/matrox/g450_pll.o:(.text+0x5b0): first defined here ld: drivers/staging/mgakms/g450_pll.o: in function `g450_mnp2f': >> (.text+0x0): multiple definition of `g450_mnp2f'; >> drivers/video/fbdev/matrox/g450_pll.o:(.text+0x0): first defined here ld: drivers/staging/mgakms/g450_pll.o: in function `matroxfb_g450_setpll_cond': >> (.text+0x230): multiple definition of `matroxfb_g450_setpll_cond'; >> drivers/video/fbdev/matrox/g450_pll.o:(.text+0x230): first defined here ld: drivers/staging/mgakms/g450_pll.o: in function `__crc_matroxfb_g450_setpll_cond': (*ABS*+0xc16eb42d): multiple definition of `__crc_matroxfb_g450_setpll_cond' ld: drivers/staging/mgakms/matroxfb_accel.o: in function `matrox_cfbX_init': >> (.text+0x0): multiple definition of `matrox_cfbX_init'; >> drivers/video/fbdev/matrox/matroxfb_accel.o:(.text+0x0): first defined here ld: drivers/staging/mgakms/matroxfb_accel.o: in function `__crc_matrox_cfbX_init': (*ABS*+0xad1ca004): multiple definition of `__crc_matrox_cfbX_init' ld: drivers/staging/mgakms/matroxfb_base.o: in function `__crc_matroxfb_enable_irq': (*ABS*+0x2f4ea06b): multiple definition of `__crc_matroxfb_enable_irq' ld: drivers/staging/mgakms/matroxfb_base.o: in function `__crc_matroxfb_register_driver': (*ABS*+0x9eefe8ea): multiple definition of `__crc_matroxfb_register_driver' ld: drivers/staging/mgakms/matroxfb_base.o: in function `matroxfb_enable_irq': >> (.text+0x3d70): multiple definition of `matroxfb_enable_irq'; >> drivers/video/fbdev/matrox/matroxfb_base.o:(.text+0x3d40): first defined here ld: drivers/staging/mgakms/matroxfb_base.o: in function `__crc_matroxfb_unregister_driver': (*ABS*+0xe6ed497): multiple definition of `__crc_matroxfb_unregister_driver' ld: drivers/staging/mgakms/matroxfb_base.o: in function `matroxfb_register_driver': >> (.text+0x7e0): multiple definition of `matroxfb_register_driver'; >> drivers/video/fbdev/matrox/matroxfb_base.o:(.text+0x7e0): first defined here ld: drivers/staging/mgakms/matroxfb_base.o: in function `matroxfb_wait_for_sync': >> (.text+0x41b0): multiple definition of `matroxfb_wait_for_sync'; >> drivers/video/fbdev/matrox/matroxfb_base.o:(.text+0x4180): first defined here ld: drivers/staging/mgakms/matroxfb_base.o: in function `__crc_matroxfb_wait_for_sync': (*ABS*+0xf264a0a8): multiple definition of `__crc_matroxfb_wait_for_sync' ld: drivers/staging/mgakms/matroxfb_base.o: in function `matroxfb_unregister_driver': >> (.text+0x950): multiple definition of `matroxfb_unregister_driver'; >> drivers/video/fbdev/matrox/matroxfb_base.o:(.text+0x950): first defined here >> ld: drivers/staging/mgakms/matroxfb_DAC1064.o:(.data+0x0): multiple >> definition of `matrox_G100'; >> drivers/video/fbdev/matrox/matroxfb_DAC1064.o:(.data+0x0): first defined here ld: drivers/staging/mgakms/matroxfb_DAC1064.o: in function `__crc_DAC1064_global_init': (*ABS*+0x279aabee): multiple definition of `__crc_DAC1064_global_init' ld: drivers/staging/mgakms/matroxfb_DAC1064.o: in function `__crc_DAC1064_global_restore': (*ABS*+0xb0a182ca): multiple definition of `__crc_DAC1064_global_restore' >> ld: drivers/staging/mgakms/matroxfb_DAC1064.o:(.data+0x40): multiple >> definition of `matrox_mystique'; >> drivers/video/fbdev/matrox/matroxfb_DAC1064.o:(.data+0x40): first defined >> here ld: drivers/staging/mgakms/matroxfb_DAC1064.o: in function `__crc_matrox_mystique': (*ABS*+0x82a67894): multiple definition of `__crc_matrox_mystique' ld: drivers/staging/mgakms/matroxfb_D
Re: [Lima] [PATCH v4 0/3] drm/lima: simplify driver by using more drm helpers
Thanks, applied to drm-misc-next. Regards, Qiang On Mon, Oct 14, 2019 at 12:21 PM Vasily Khoruzhick wrote: > > On Thu, Oct 10, 2019 at 7:02 AM Qiang Yu wrote: > > > > By using shared drm helpers: > > 1. drm_gem_(un)lock_reservations > > 2. drm_gem_shmem_helpers > > we can simplify lima driver a lot and benifit from updates to > > these functions. > > > > Patch series is based on drm-misc-next branch > > > > v2: > > Add drm_gem_objects_lookup_user and use it for driver which > > pass user GEM handles in contious array. > > > > v3: > > improve commit comment. > > > > v4: > > Drop drm_gem_objects_lookup refine patches. > > > > Qiang Yu (3): > > drm/lima: use drm_gem_shmem_helpers > > drm/lima: use drm_gem_(un)lock_reservations > > drm/lima: add __GFP_NOWARN flag to all dma_alloc_wc > > LGTM, whole series: > > Reviewed-by: Vasily Khoruzhick > > > drivers/gpu/drm/lima/Kconfig | 1 + > > drivers/gpu/drm/lima/Makefile | 4 +- > > drivers/gpu/drm/lima/lima_device.c| 2 +- > > drivers/gpu/drm/lima/lima_drv.c | 22 +-- > > drivers/gpu/drm/lima/lima_gem.c | 195 ++ > > drivers/gpu/drm/lima/lima_gem.h | 32 - > > drivers/gpu/drm/lima/lima_gem_prime.c | 46 -- > > drivers/gpu/drm/lima/lima_gem_prime.h | 13 -- > > drivers/gpu/drm/lima/lima_mmu.c | 1 - > > drivers/gpu/drm/lima/lima_object.c| 119 > > drivers/gpu/drm/lima/lima_object.h| 35 - > > drivers/gpu/drm/lima/lima_sched.c | 6 +- > > drivers/gpu/drm/lima/lima_vm.c| 87 ++-- > > 13 files changed, 148 insertions(+), 415 deletions(-) > > delete mode 100644 drivers/gpu/drm/lima/lima_gem_prime.c > > delete mode 100644 drivers/gpu/drm/lima/lima_gem_prime.h > > delete mode 100644 drivers/gpu/drm/lima/lima_object.c > > delete mode 100644 drivers/gpu/drm/lima/lima_object.h > > > > -- > > 2.17.1 > > > > ___ > > lima mailing list > > l...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/lima ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 03:58:25PM +0200, Michal Vokáč wrote:
> On 17. 10. 19 14:59, Thierry Reding wrote:
> > On Thu, Oct 17, 2019 at 02:09:17PM +0200, Uwe Kleine-König wrote:
> > > On Thu, Oct 17, 2019 at 01:11:31PM +0200, Thierry Reding wrote:
> > > > On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> > > > > On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > > > > > On 17. 10. 19 10:10, Uwe Kleine-König wrote:
> > > > > > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > > > > > pwm_get_state() return the last implemented state")) changed the
> > > > > > > semantic of pwm_get_state() and disclosed an (as it seems) common
> > > > > > > problem in lowlevel PWM drivers. By not relying on the period and
> > > > > > > duty
> > > > > > > cycle being retrievable from a disabled PWM this type of problem
> > > > > > > is
> > > > > > > worked around.
> > > > > > >
> > > > > > > Apart from this issue only calling the
> > > > > > > pwm_get_state/pwm_apply_state
> > > > > > > combo once is also more effective.
> > > > > > >
> > > > > > > Signed-off-by: Uwe Kleine-König
> > > > > > > ---
> > > > > > > Hello,
> > > > > > >
> > > > > > > There are now two reports about 01ccf903edd6 breaking a
> > > > > > > backlight. As
> > > > > > > far as I understand the problem this is a combination of the
> > > > > > > backend pwm
> > > > > > > driver yielding surprising results and the pwm-bl driver doing
> > > > > > > things
> > > > > > > more complicated than necessary.
> > > > > > >
> > > > > > > So I guess this patch works around these problems. Still it would
> > > > > > > be
> > > > > > > interesting to find out the details in the imx driver that
> > > > > > > triggers the
> > > > > > > problem. So Adam, can you please instrument the pwm-imx27 driver
> > > > > > > to
> > > > > > > print *state at the beginning of pwm_imx27_apply() and the end of
> > > > > > > pwm_imx27_get_state() and provide the results?
> > > > > > >
> > > > > > > Note I only compile tested this change.
> > > > > >
> > > > > > Hi Uwe,
> > > > > > I was just about to respond to the "pwm_bl on i.MX6Q broken on
> > > > > > 5.4-RC1+"
> > > > > > thread that I have a similar problem when you submitted this patch.
> > > > > >
> > > > > > So here are my few cents:
> > > > > >
> > > > > > My setup is as follows:
> > > > > > - imx6dl-yapp4-draco with i.MX6Solo
> > > > > > - backlight is controlled with inverted PWM signal
> > > > > > - max brightness level = 32, default brightness level set to 32
> > > > > > in DT.
> > > > > >
> > > > > > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
> > > > > > pwm_get_state() return the last implemented state):
> > > > > >
> > > > > > - System boots to userspace and backlight is enabled all the time
> > > > > > from
> > > > > > power up.
> > > > > >
> > > > > > $ dmesg | grep state
> > > > > > [1.763381] get state end: -1811360608, enabled: 0
> > > > >
> > > > > What is -1811360608? When I wrote "print *state" above, I thought
> > > > > about
> > > > > something like:
> > > > >
> > > > > pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
> > > > > __func__, state->period, state->duty_cycle,
> > > > > state->polarity, state->enabled);
> > > > >
> > > > > A quick look into drivers/pwm/pwm-imx27.c shows that this is another
> > > > > driver that yields duty_cycle = 0 when the hardware is off.
> > > >
> > > > It seems to me like the best recourse to fix this for now would be to
> > > > patch up the drivers that return 0 when the hardware is off by caching
> > > > the currently configured duty cycle.
> > > >
> > > > How about the patch below?
> > > >
> > > > Thierry
> > > >
> > > > --- >8 ---
> > > > From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00 2001
> > > > From: Thierry Reding
> > > > Date: Thu, 17 Oct 2019 12:56:00 +0200
> > > > Subject: [PATCH] pwm: imx27: Cache duty cycle register value
> > > >
> > > > The hardware register containing the duty cycle value cannot be accessed
> > > > when the PWM is disabled. This causes the ->get_state() callback to read
> > > > back a duty cycle value of 0, which can confuse consumer drivers.
> > > >
> > > > Signed-off-by: Thierry Reding
> > > > ---
> > > > drivers/pwm/pwm-imx27.c | 31 ---
> > > > 1 file changed, 24 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> > > > index ae11d8577f18..4113d5cd4c62 100644
> > > > --- a/drivers/pwm/pwm-imx27.c
> > > > +++ b/drivers/pwm/pwm-imx27.c
> > > > @@ -85,6 +85,13 @@ struct pwm_imx27_chip {
> > > > struct clk *clk_per;
> > > > void __iomem*mmio_base;
> > > > struct pwm_chip chip;
> > > > +
> > > > + /*
> > > > +* The driver cannot read the current duty cycle from the
> > > > hardware if
> > > > +* the hardware
Re: [PATCH V4 3/6] mdev: introduce device specific ops
On Thu, 17 Oct 2019 18:48:33 +0800
Jason Wang wrote:
> Currently, except for the create and remove, the rest of
> mdev_parent_ops is designed for vfio-mdev driver only and may not help
> for kernel mdev driver. With the help of class id, this patch
> introduces device specific callbacks inside mdev_device
> structure. This allows different set of callback to be used by
> vfio-mdev and virtio-mdev.
>
> Signed-off-by: Jason Wang
> ---
> .../driver-api/vfio-mediated-device.rst | 25 +
> MAINTAINERS | 1 +
> drivers/gpu/drm/i915/gvt/kvmgt.c | 18 ---
> drivers/s390/cio/vfio_ccw_ops.c | 18 ---
> drivers/s390/crypto/vfio_ap_ops.c | 14 +++--
> drivers/vfio/mdev/mdev_core.c | 18 +--
> drivers/vfio/mdev/mdev_private.h | 1 +
> drivers/vfio/mdev/vfio_mdev.c | 37 ++---
> include/linux/mdev.h | 45
> include/linux/vfio_mdev.h | 52 +++
> samples/vfio-mdev/mbochs.c| 20 ---
> samples/vfio-mdev/mdpy.c | 20 ---
> samples/vfio-mdev/mtty.c | 18 ---
> 13 files changed, 184 insertions(+), 103 deletions(-)
> create mode 100644 include/linux/vfio_mdev.h
>
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst
> b/Documentation/driver-api/vfio-mediated-device.rst
> index f9a78d75a67a..0cca84d19603 100644
> --- a/Documentation/driver-api/vfio-mediated-device.rst
> +++ b/Documentation/driver-api/vfio-mediated-device.rst
> @@ -152,11 +152,22 @@ callbacks per mdev parent device, per mdev type, or any
> other categorization.
> Vendor drivers are expected to be fully asynchronous in this respect or
> provide their own internal resource protection.)
>
> -The callbacks in the mdev_parent_ops structure are as follows:
> -
> -* open: open callback of mediated device
> -* close: close callback of mediated device
> -* ioctl: ioctl callback of mediated device
> +As multiple types of mediated devices may be supported, the device
> +must set up the class id and the device specific callbacks in create()
s/in create()/in the create()/
> +callback. E.g for vfio-mdev device it needs to be done through:
"Each class provides a helper function to do so; e.g. for vfio-mdev
devices, the function to be called is:"
?
> +
> +int mdev_set_vfio_ops(struct mdev_device *mdev,
> + const struct vfio_mdev_ops *vfio_ops);
> +
> +The class id (set to MDEV_CLASS_ID_VFIO) is used to match a device
"(set by this helper function to MDEV_CLASS_ID_VFIO)" ?
> +with an mdev driver via its id table. The device specific callbacks
> +(specified in *ops) are obtainable via mdev_get_dev_ops() (for use by
"(specified in *vfio_ops by the caller)" ?
> +the mdev bus driver). A vfio-mdev device (class id MDEV_CLASS_ID_VFIO)
> +uses the following device-specific ops:
> +
> +* open: open callback of vfio mediated device
> +* close: close callback of vfio mediated device
> +* ioctl: ioctl callback of vfio mediated device
> * read : read emulation callback
> * write: write emulation callback
> * mmap: mmap emulation callback
> @@ -167,10 +178,6 @@ register itself with the mdev core driver::
> extern int mdev_register_device(struct device *dev,
>const struct mdev_parent_ops *ops);
>
> -It is also required to specify the class_id in create() callback through::
> -
> - int mdev_set_class(struct mdev_device *mdev, u16 id);
> -
I'm wondering if this patch set should start out with introducing
helper functions already (i.e. don't introduce mdev_set_class(), but
start out with mdev_set_class_vfio() which will gain the *vfio_ops
argument in this patch.)
> However, the mdev_parent_ops structure is not required in the function call
> that a driver should use to unregister itself with the mdev core driver::
>
(...)
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index 3a9c52d71b4e..d0f3113c8071 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -45,15 +45,23 @@ void mdev_set_drvdata(struct mdev_device *mdev, void
> *data)
> }
> EXPORT_SYMBOL(mdev_set_drvdata);
>
> -/* Specify the class for the mdev device, this must be called during
> - * create() callback.
> +/* Specify the VFIO device ops for the mdev device, this
> + * must be called during create() callback for VFIO mdev device.
> */
/*
* Specify the mdev device to be a VFIO mdev device, and set the
* VFIO devices ops for it. This must be called from the create()
* callback for VFIO mdev devices.
*/
?
> -void mdev_set_class(struct mdev_device *mdev, u16 id)
> +void mdev_set_vfio_ops(struct mdev_device *mdev,
> +const struct vfio_mdev_device_ops *vfio_ops)
> {
> WARN_ON(mdev->class_id);
> -
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 3:11 AM Uwe Kleine-König
wrote:
>
> A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> pwm_get_state() return the last implemented state")) changed the
> semantic of pwm_get_state() and disclosed an (as it seems) common
> problem in lowlevel PWM drivers. By not relying on the period and duty
> cycle being retrievable from a disabled PWM this type of problem is
> worked around.
>
> Apart from this issue only calling the pwm_get_state/pwm_apply_state
> combo once is also more effective.
Looking at the pwm core file in linunx/master, it looks like we're
checking to see if all items are the same. If they are, we return 0.
This make sense because we're not changing anything.
If anything is different, we're using the cached value because we're
not checking if/what has changed. If we want to change the polarity
or the duty cycle, this appears to me like it would not change because
it just uses the cached value. Somehow it seems to me like we should
just blindly update the state to what we want and let the lower-level
functions cache what they need to prevent the recalculation, but if
we're changing duty cycle or polarity, I am not seeing how that will
be updated.
Both of those appear to be broken depending on which board is having an issue.
adam
>
> Signed-off-by: Uwe Kleine-König
> ---
> Hello,
>
> There are now two reports about 01ccf903edd6 breaking a backlight. As
> far as I understand the problem this is a combination of the backend pwm
> driver yielding surprising results and the pwm-bl driver doing things
> more complicated than necessary.
>
> So I guess this patch works around these problems. Still it would be
> interesting to find out the details in the imx driver that triggers the
> problem. So Adam, can you please instrument the pwm-imx27 driver to
> print *state at the beginning of pwm_imx27_apply() and the end of
> pwm_imx27_get_state() and provide the results?
>
> Note I only compile tested this change.
>
> Best regards
> Uwe
>
> drivers/video/backlight/pwm_bl.c | 34 +++-
> 1 file changed, 12 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index 746eebc411df..ddebd62b3978 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -42,10 +42,8 @@ struct pwm_bl_data {
>
> static void pwm_backlight_power_on(struct pwm_bl_data *pb)
> {
> - struct pwm_state state;
> int err;
>
> - pwm_get_state(pb->pwm, );
> if (pb->enabled)
> return;
>
> @@ -53,9 +51,6 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb)
> if (err < 0)
> dev_err(pb->dev, "failed to enable power supply\n");
>
> - state.enabled = true;
> - pwm_apply_state(pb->pwm, );
> -
> if (pb->post_pwm_on_delay)
> msleep(pb->post_pwm_on_delay);
>
> @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb)
>
> static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> {
> - struct pwm_state state;
> -
> - pwm_get_state(pb->pwm, );
> - if (!pb->enabled)
> - return;
> -
> if (pb->enable_gpio)
> gpiod_set_value_cansleep(pb->enable_gpio, 0);
>
> if (pb->pwm_off_delay)
> msleep(pb->pwm_off_delay);
>
> - state.enabled = false;
> - state.duty_cycle = 0;
> - pwm_apply_state(pb->pwm, );
> -
> regulator_disable(pb->power_supply);
> pb->enabled = false;
> }
>
> -static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
> +static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness, struct
> pwm_state *state)
> {
> unsigned int lth = pb->lth_brightness;
> - struct pwm_state state;
> u64 duty_cycle;
>
> - pwm_get_state(pb->pwm, );
> -
> if (pb->levels)
> duty_cycle = pb->levels[brightness];
> else
> duty_cycle = brightness;
>
> - duty_cycle *= state.period - lth;
> + duty_cycle *= state->period - lth;
> do_div(duty_cycle, pb->scale);
>
> return duty_cycle + lth;
> @@ -122,12 +104,20 @@ static int pwm_backlight_update_status(struct
> backlight_device *bl)
>
> if (brightness > 0) {
> pwm_get_state(pb->pwm, );
> - state.duty_cycle = compute_duty_cycle(pb, brightness);
> + state.duty_cycle = compute_duty_cycle(pb, brightness, );
> + state.enabled = true;
> pwm_apply_state(pb->pwm, );
> +
> pwm_backlight_power_on(pb);
> - } else
> + } else {
> pwm_backlight_power_off(pb);
>
> + pwm_get_state(pb->pwm, );
> + state.enabled = false;
> + state.duty_cycle = 0;
> + pwm_apply_state(pb->pwm, );
> + }
> +
> if
Re: [PATCH V5 2/3] dt-bindings: Add Logic PD Type 28 display panel
On Thu, Oct 17, 2019 at 9:37 AM Rob Herring wrote: > > On Wed, Oct 16, 2019 at 09:55:11AM -0500, Adam Ford wrote: > > On Wed, Oct 16, 2019 at 9:40 AM Laurent Pinchart > > wrote: > > > > > > Hi Adam, > > > > > > Thank you for the patch. > > > > > > On Wed, Oct 16, 2019 at 08:51:46AM -0500, Adam Ford wrote: > > > > This patch adds documentation of device tree bindings for the WVGA panel > > > > Logic PD Type 28 display. > > > > > > > > Signed-off-by: Adam Ford > > > > --- > > > > V5: Replace GPIO_ACTIVE_HIGH with 0 to fix make dt_binding_check -k > > > > V4: Update per Rob H's suggestions and copy other panel yaml example > > > > from 5.4-rc1 > > > > V3: Correct build errors from 'make dt_binding_check' > > > > V2: Use YAML instead of TXT for binding > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/display/panel/logicpd,type28.yaml > > > > b/Documentation/devicetree/bindings/display/panel/logicpd,type28.yaml > > > > new file mode 100644 > > > > index ..2834287b8d88 > > > > --- /dev/null > > > > +++ > > > > b/Documentation/devicetree/bindings/display/panel/logicpd,type28.yaml > > > > @@ -0,0 +1,42 @@ > > > > +# SPDX-License-Identifier: GPL-2.0 > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/display/panel/logicpd,type28.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Logic PD Type 28 4.3" WQVGA TFT LCD panel > > > > + > > > > +maintainers: > > > > + - Adam Ford > > > > + > > > > +allOf: > > > > + - $ref: panel-common.yaml# > > > > + > > > > +properties: > > > > + compatible: > > > > +const: logicpd,type28 > > > > + > > > > + power-supply: true > > > > + enable-gpios: true > > > > + backlight: true > > > > + port: true > > > > + > > > > +required: > > > > + - compatible > > > > > > Should the port be required too ? Apart from that, > > > > I supposed that's true, but I used ampire,am-480272h3tmqw-t01h.yaml as > > the example, and it doesn't list it as a required item. > > Is there anything else I need to address? I feel like I'm trying to > > hit a moving target. > > 'port' can be omitted because the panel can be a child node of > the display controller instead. That's decided by the display controller > binding, not the panel binding. > > Reviewed-by: Rob Herring Thank you. Sorry it took a while to get there. adam > > Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V5 2/3] dt-bindings: Add Logic PD Type 28 display panel
On Wed, Oct 16, 2019 at 09:55:11AM -0500, Adam Ford wrote: > On Wed, Oct 16, 2019 at 9:40 AM Laurent Pinchart > wrote: > > > > Hi Adam, > > > > Thank you for the patch. > > > > On Wed, Oct 16, 2019 at 08:51:46AM -0500, Adam Ford wrote: > > > This patch adds documentation of device tree bindings for the WVGA panel > > > Logic PD Type 28 display. > > > > > > Signed-off-by: Adam Ford > > > --- > > > V5: Replace GPIO_ACTIVE_HIGH with 0 to fix make dt_binding_check -k > > > V4: Update per Rob H's suggestions and copy other panel yaml example > > > from 5.4-rc1 > > > V3: Correct build errors from 'make dt_binding_check' > > > V2: Use YAML instead of TXT for binding > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/panel/logicpd,type28.yaml > > > b/Documentation/devicetree/bindings/display/panel/logicpd,type28.yaml > > > new file mode 100644 > > > index ..2834287b8d88 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/display/panel/logicpd,type28.yaml > > > @@ -0,0 +1,42 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/display/panel/logicpd,type28.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Logic PD Type 28 4.3" WQVGA TFT LCD panel > > > + > > > +maintainers: > > > + - Adam Ford > > > + > > > +allOf: > > > + - $ref: panel-common.yaml# > > > + > > > +properties: > > > + compatible: > > > +const: logicpd,type28 > > > + > > > + power-supply: true > > > + enable-gpios: true > > > + backlight: true > > > + port: true > > > + > > > +required: > > > + - compatible > > > > Should the port be required too ? Apart from that, > > I supposed that's true, but I used ampire,am-480272h3tmqw-t01h.yaml as > the example, and it doesn't list it as a required item. > Is there anything else I need to address? I feel like I'm trying to > hit a moving target. 'port' can be omitted because the panel can be a child node of the display controller instead. That's decided by the display controller binding, not the panel binding. Reviewed-by: Rob Herring Rob
Re: [PATCH v1] drm/mipi_dbi: Use simple right shift instead of double negation
On Thu, Oct 17, 2019 at 05:00:54PM +0300, Andy Shevchenko wrote: > On Thu, Oct 17, 2019 at 09:10:52AM -0400, Sean Paul wrote: > > On Thu, Oct 17, 2019 at 02:49:12PM +0300, Andy Shevchenko wrote: > > > GCC complains about dubious bitwise OR operand: > > > > > > drivers/gpu/drm/drm_mipi_dbi.c:1024:49: warning: dubious: x | !y > > > CC [M] drivers/gpu/drm/drm_mipi_dbi.o > > > > > > As long as buffer is consist of byte (u8) values, we may use > > > simple right shift and satisfy compiler. It also reduces amount of > > > operations needed. > > > > > > Signed-off-by: Andy Shevchenko > > > --- > > > drivers/gpu/drm/drm_mipi_dbi.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/drm_mipi_dbi.c > > > b/drivers/gpu/drm/drm_mipi_dbi.c > > > index 1961f713aaab..445e88b1fc9a 100644 > > > --- a/drivers/gpu/drm/drm_mipi_dbi.c > > > +++ b/drivers/gpu/drm/drm_mipi_dbi.c > > > @@ -1021,7 +1021,7 @@ static int mipi_dbi_typec3_command_read(struct > > > mipi_dbi *dbi, u8 *cmd, > > > unsigned int i; > > > > > > for (i = 0; i < len; i++) > > > - data[i] = (buf[i] << 1) | !!(buf[i + 1] & BIT(7)); > > > + data[i] = (buf[i] << 1) | (buf[i + 1] >> 7); > > > > You should probably have ((buf[i + 1] >> 7) & 0x1) to be super safe. > > This is superfluous as long as buf is declared as u8 (see commit message). > Yeah, I saw that, hence the "super safe" comment. My point is that writing that disclaimer in the commit message doesn't actually protect the operation if the type changes, while masking off the first bit does. > > Do you know anything about this code? It seems like nothing is protecting us > > from overrunning buf in this loop. We're just assuming that len < tr[1].len > > through this loop and I'm not sure what's protecting us from looking where > > we > > shouldn't. > > It I'm not mistaken this is the case, we have it strong less than transfer > length. > Thanks, I looked at the code and you're right. The possible values of tr[1].len are len or len + 1. Sean > > -- > With Best Regards, > Andy Shevchenko > > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] new uapi policy for drm
On Thu, Oct 17, 2019 at 9:58 AM Daniel Vetter wrote: > > On Wed, Oct 16, 2019 at 04:00:25PM -0400, Alex Deucher wrote: > > On Mon, Oct 14, 2019 at 2:16 PM Dave Airlie wrote: > > > > > > I've kicked this around in my head over the past few weeks but wanted > > > to get some feedback on whether it's a good idea or what impact it > > > might have that I haven't considered. > > > > > > We are getting requests via both amdgpu/amdkfd and i915 for new user > > > APIs for userspace drivers that throw code over the wall instead of > > > being open source developed projects, but we are also seeing it for > > > android drivers and kms properties, and we had that i915 crappy crtc > > > background thing that was for Chrome but Chrome didn't want it. > > > > > > Now this presents a couple of issues: > > > > > > a) these projects don't seem to that good at following our development > > > guidelines, avoid developing userspace features in parallel in the > > > open and having good development implementations before submitting > > > upstream. > > > > > > b) these projects don't have experienced userspace developers > > > reviewing their kernel uapis. One big advantage of adding uapis with > > > mesa developers is they have a lot of experience in the area as well. > > > > > > It's leading me to think I want to just stop all uapi submissions via > > > driver trees, and instead mandate that all driver uapi changes are > > > sent in separate git pull requests to dri-devel, I'd try (with some > > > help) to catch all uapi modifications in normal trees, and refuse > > > pulls that modified uapi. > > > > > > At least I'm considered writing the script and refusing and pulls that > > > have a uapi change that doesn't contain a link to the userspace > > > changes required for it in a public developed repo. > > > > > > Thoughts? > > > > This seems like more hassle for questionable benefits. I don't know > > that mesa is really any better than any other driver teams with > > respect to UAPI. This just seems like sort of a arbitrary political > > decision. The people working on mesa have as much of an agenda as > > those working on other projects. Moreover, especially with the > > migration to gitlab and MRs, I feel that mesa development has gotten > > more opaque. Say what you will about mailing lists, but at least you > > could have a drive by view of what's going on. With MRs, you sort of > > have to seek out what to review; if stuff is not tagged with something > > you feel is relevant, you probably won't look at it, so the only > > people likely to review it are the people involved in writing it in > > the first place, which would be the same whether it's mesa or some > > other project. I think all of the projects generally have the best > > intentions at heart, but for better or worse they just have different > > development models. In the case of the AMD throw it over the wall > > stuff, it's not really an anti-open source or community engagement > > issue, it's more of how to we support several OSes, tons of new > > products, several custom projects, etc. while leveraging as much > > shared code as possible. There are ways to make it work, but they are > > usually a pretty heavy lift that not all teams can make. > > I think there's a difference between All Tools Sucks (tm) and the > discussions not even being accessible at all. I do agree that generally > everyone screws up uapi once in a while, and we seem to overall do a not > too shoddy job. So code is probably all ok enough. > > But imo long term code is fungible and really doesn't matter much, the > important stuff is the people and teams who create it, and all the shared > knowledge. That's also were I see the benefit in upstream (for customers > and vendors and everyone), we can learn from each another. As an example, > I've spent lots of time recently reading amdgpu code and how it's used in > userspace. Understanding that without having access to the discussion or > being able to ping people on irc and mailing lists would have been > impossible - lots of questions where I just plain guessed wrong. For the > code-over-wall projects that stuff all simply doesn't exist. It's nigh > impossible to figure out whether uapi makes sense or not if you can't see > all the tradeoffs and discussions that influenced it and why. > > That's also why I think the separate pull won't help at all, since Dave > will still have incomplete information. All he can do with more pulls is > roll the die more often, that's not helping. > > Now short term "moar hw support" is cool and all that, but long term I do > think it's missing the point of upstreaming. It's not that mesa (or any > other cross vendor project, we have a bunch of those on the kms side) is > better at uapi, it's that it's more open and so _much_ easier to > understand how we ended up at a specific place. That's at least my take on > all this. Fair points. I guess I should clarify my thinking. I was assuming that
Re: [PATCH v6 1/8] dt-bindings: display: renesas,cmm: Add R-Car CMM documentation
On Wed, 16 Oct 2019 10:55:41 +0200, Jacopo Mondi wrote: > Add device tree bindings documentation for the Renesas R-Car Display > Unit Color Management Module. > > CMM is the image enhancement module available on each R-Car DU video > channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M excluded). > > Reviewed-by: Kieran Bingham > Reviewed-by: Laurent Pinchart > Signed-off-by: Jacopo Mondi > --- > .../bindings/display/renesas,cmm.yaml | 67 +++ > 1 file changed, 67 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/renesas,cmm.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drivers/staging/fbtft/fb_seps525: New driver for SEPS525 (Syncoam) LCD Controllers
From: Michael Hennerich The SEPS525 is a 160 RGB x 128 Dots, 262K Colors PM-OLED Display Driver and Controller. The controller can be found on the NHD-1.69-160128UGC3 (Newhaven Display International, Inc.). Datasheets: Link: https://www.newhavendisplay.com/appnotes/datasheets/OLEDs/SEPS525.pdf Signed-off-by: Michael Hennerich Co-developed-by: Beniamin Bia Signed-off-by: Beniamin Bia --- MAINTAINERS| 8 ++ drivers/staging/fbtft/Kconfig | 7 + drivers/staging/fbtft/Makefile | 1 + drivers/staging/fbtft/fb_seps525.c | 213 + 4 files changed, 229 insertions(+) create mode 100644 drivers/staging/fbtft/fb_seps525.c diff --git a/MAINTAINERS b/MAINTAINERS index ef00d6210cff..d077d04f9bc5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15389,6 +15389,14 @@ L: linux-wirel...@vger.kernel.org S: Supported F: drivers/staging/wilc1000/ +STAGING - SEPS525 LCD CONTROLLER DRIVERS +M: Michael Hennerich +M: Beniamin Bia +L: linux-fb...@vger.kernel.org +S: Supported +F: drivers/staging/fbtft/fb_seps525.c +F: Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml + STAGING SUBSYSTEM M: Greg Kroah-Hartman T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig index 8ec524a95ec8..55af11ee2f5b 100644 --- a/drivers/staging/fbtft/Kconfig +++ b/drivers/staging/fbtft/Kconfig @@ -112,6 +112,13 @@ config FB_TFT_S6D1121 help Generic Framebuffer support for S6D1121 +config FB_TFT_SEPS525 + tristate "FB driver for the SEPS525 LCD Controller" + depends on FB_TFT + help + Generic Framebuffer support for SEPS525 + Say Y if you have such a display that utilizes this controller. + config FB_TFT_SH1106 tristate "FB driver for the SH1106 OLED Controller" depends on FB_TFT diff --git a/drivers/staging/fbtft/Makefile b/drivers/staging/fbtft/Makefile index 6bc03311c9c7..e7a0cd9166e9 100644 --- a/drivers/staging/fbtft/Makefile +++ b/drivers/staging/fbtft/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_FB_TFT_PCD8544) += fb_pcd8544.o obj-$(CONFIG_FB_TFT_RA8875) += fb_ra8875.o obj-$(CONFIG_FB_TFT_S6D02A1) += fb_s6d02a1.o obj-$(CONFIG_FB_TFT_S6D1121) += fb_s6d1121.o +obj-$(CONFIG_FB_TFT_SEPS525) += fb_seps525.o obj-$(CONFIG_FB_TFT_SH1106) += fb_sh1106.o obj-$(CONFIG_FB_TFT_SSD1289) += fb_ssd1289.o obj-$(CONFIG_FB_TFT_SSD1305) += fb_ssd1305.o diff --git a/drivers/staging/fbtft/fb_seps525.c b/drivers/staging/fbtft/fb_seps525.c new file mode 100644 index ..05882e2cde7f --- /dev/null +++ b/drivers/staging/fbtft/fb_seps525.c @@ -0,0 +1,213 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * FB driver for the NHD-1.69-160128UGC3 (Newhaven Display International, Inc.) + * using the SEPS525 (Syncoam) LCD Controller + * + * Copyright (C) 2016 Analog Devices Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include + +#include "fbtft.h" + +#define DRVNAME"fb_seps525" +#define WIDTH 160 +#define HEIGHT 128 + +#define SEPS525_INDEX 0x00 +#define SEPS525_STATUS_RD 0x01 +#define SEPS525_OSC_CTL 0x02 +#define SEPS525_IREF 0x80 +#define SEPS525_CLOCK_DIV 0x03 +#define SEPS525_REDUCE_CURRENT 0x04 +#define SEPS525_SOFT_RST 0x05 +#define SEPS525_DISP_ONOFF 0x06 +#define SEPS525_PRECHARGE_TIME_R 0x08 +#define SEPS525_PRECHARGE_TIME_G 0x09 +#define SEPS525_PRECHARGE_TIME_B 0x0A +#define SEPS525_PRECHARGE_CURRENT_R 0x0B +#define SEPS525_PRECHARGE_CURRENT_G 0x0C +#define SEPS525_PRECHARGE_CURRENT_B 0x0D +#define SEPS525_DRIVING_CURRENT_R 0x10 +#define SEPS525_DRIVING_CURRENT_G 0x11 +#define SEPS525_DRIVING_CURRENT_B 0x12 +#define SEPS525_DISPLAYMODE_SET 0x13 +#define SEPS525_RGBIF 0x14 +#define SEPS525_RGB_POL 0x15 +#define SEPS525_MEMORY_WRITEMODE 0x16 +#define SEPS525_MX1_ADDR 0x17 +#define SEPS525_MX2_ADDR 0x18 +#define SEPS525_MY1_ADDR 0x19 +#define SEPS525_MY2_ADDR 0x1A +#define SEPS525_MEMORY_ACCESS_POINTER_X 0x20 +#define SEPS525_MEMORY_ACCESS_POINTER_Y 0x21 +#define SEPS525_DDRAM_DATA_ACCESS_PORT 0x22 +#define SEPS525_GRAY_SCALE_TABLE_INDEX 0x50 +#define SEPS525_GRAY_SCALE_TABLE_DATA 0x51 +#define SEPS525_DUTY 0x28 +#define SEPS525_DSL 0x29 +#define SEPS525_D1_DDRAM_FAC 0x2E +#define SEPS525_D1_DDRAM_FAR 0x2F +#define SEPS525_D2_DDRAM_SAC 0x31 +#define SEPS525_D2_DDRAM_SAR 0x32 +#define
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 8:30 AM Adam Ford wrote:
>
> On Thu, Oct 17, 2019 at 6:11 AM Thierry Reding
> wrote:
> >
> > On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> > > On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > > > On 17. 10. 19 10:10, Uwe Kleine-König wrote:
> > > > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > > > pwm_get_state() return the last implemented state")) changed the
> > > > > semantic of pwm_get_state() and disclosed an (as it seems) common
> > > > > problem in lowlevel PWM drivers. By not relying on the period and duty
> > > > > cycle being retrievable from a disabled PWM this type of problem is
> > > > > worked around.
> > > > >
> > > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > > combo once is also more effective.
> > > > >
> > > > > Signed-off-by: Uwe Kleine-König
> > > > > ---
> > > > > Hello,
> > > > >
> > > > > There are now two reports about 01ccf903edd6 breaking a backlight. As
> > > > > far as I understand the problem this is a combination of the backend
> > > > > pwm
> > > > > driver yielding surprising results and the pwm-bl driver doing things
> > > > > more complicated than necessary.
> > > > >
> > > > > So I guess this patch works around these problems. Still it would be
> > > > > interesting to find out the details in the imx driver that triggers
> > > > > the
> > > > > problem. So Adam, can you please instrument the pwm-imx27 driver to
> > > > > print *state at the beginning of pwm_imx27_apply() and the end of
> > > > > pwm_imx27_get_state() and provide the results?
> > > > >
> > > > > Note I only compile tested this change.
> > > >
> > > > Hi Uwe,
> > > > I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
> > > > thread that I have a similar problem when you submitted this patch.
> > > >
> > > > So here are my few cents:
> > > >
> > > > My setup is as follows:
> > > > - imx6dl-yapp4-draco with i.MX6Solo
> > > > - backlight is controlled with inverted PWM signal
> > > > - max brightness level = 32, default brightness level set to 32 in DT.
> > > >
> > > > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
> > > >pwm_get_state() return the last implemented state):
> > > >
> > > > - System boots to userspace and backlight is enabled all the time from
> > > >power up.
> > > >
> > > >$ dmesg | grep state
> > > >[1.763381] get state end: -1811360608, enabled: 0
> > >
> > > What is -1811360608? When I wrote "print *state" above, I thought about
> > > something like:
> > >
> > > pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
> > > __func__, state->period, state->duty_cycle,
> > > state->polarity, state->enabled);
> > >
> > > A quick look into drivers/pwm/pwm-imx27.c shows that this is another
> > > driver that yields duty_cycle = 0 when the hardware is off.
> >
> > It seems to me like the best recourse to fix this for now would be to
> > patch up the drivers that return 0 when the hardware is off by caching
> > the currently configured duty cycle.
> >
> > How about the patch below?
> >
> > Thierry
> >
> > --- >8 ---
> > From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00 2001
> > From: Thierry Reding
> > Date: Thu, 17 Oct 2019 12:56:00 +0200
> > Subject: [PATCH] pwm: imx27: Cache duty cycle register value
> >
> > The hardware register containing the duty cycle value cannot be accessed
> > when the PWM is disabled. This causes the ->get_state() callback to read
> > back a duty cycle value of 0, which can confuse consumer drivers.
> >
> > Signed-off-by: Thierry Reding
Your patch doesn't appear to being the PWM on by default, but I appear
to be able to do stuff without the screen going blank, so I think
we're making some progress. I unrolled the pwm_bl changes, but kept
yours but I am not seeing any ability to change the brightness.
Level 1-7 all appear to me to be the same.
> > ---
> > drivers/pwm/pwm-imx27.c | 31 ---
> > 1 file changed, 24 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> > index ae11d8577f18..4113d5cd4c62 100644
> > --- a/drivers/pwm/pwm-imx27.c
> > +++ b/drivers/pwm/pwm-imx27.c
> > @@ -85,6 +85,13 @@ struct pwm_imx27_chip {
> > struct clk *clk_per;
> > void __iomem*mmio_base;
> > struct pwm_chip chip;
> > +
> > + /*
> > +* The driver cannot read the current duty cycle from the hardware
> > if
> > +* the hardware is disabled. Cache the last programmed duty cycle
> > +* value to return in that case.
> > +*/
> > + unsigned int duty_cycle;
> > };
> >
> > #define to_pwm_imx27_chip(chip)container_of(chip, struct
> > pwm_imx27_chip, chip)
> > @@ -155,14 +162,17 @@ static void pwm_imx27_get_state(struct pwm_chip *chip,
> > tmp = NSEC_PER_SEC * (u64)(period + 2);
> >
Re: [RFC] new uapi policy for drm
On Wed, Oct 16, 2019 at 04:00:25PM -0400, Alex Deucher wrote: > On Mon, Oct 14, 2019 at 2:16 PM Dave Airlie wrote: > > > > I've kicked this around in my head over the past few weeks but wanted > > to get some feedback on whether it's a good idea or what impact it > > might have that I haven't considered. > > > > We are getting requests via both amdgpu/amdkfd and i915 for new user > > APIs for userspace drivers that throw code over the wall instead of > > being open source developed projects, but we are also seeing it for > > android drivers and kms properties, and we had that i915 crappy crtc > > background thing that was for Chrome but Chrome didn't want it. > > > > Now this presents a couple of issues: > > > > a) these projects don't seem to that good at following our development > > guidelines, avoid developing userspace features in parallel in the > > open and having good development implementations before submitting > > upstream. > > > > b) these projects don't have experienced userspace developers > > reviewing their kernel uapis. One big advantage of adding uapis with > > mesa developers is they have a lot of experience in the area as well. > > > > It's leading me to think I want to just stop all uapi submissions via > > driver trees, and instead mandate that all driver uapi changes are > > sent in separate git pull requests to dri-devel, I'd try (with some > > help) to catch all uapi modifications in normal trees, and refuse > > pulls that modified uapi. > > > > At least I'm considered writing the script and refusing and pulls that > > have a uapi change that doesn't contain a link to the userspace > > changes required for it in a public developed repo. > > > > Thoughts? > > This seems like more hassle for questionable benefits. I don't know > that mesa is really any better than any other driver teams with > respect to UAPI. This just seems like sort of a arbitrary political > decision. The people working on mesa have as much of an agenda as > those working on other projects. Moreover, especially with the > migration to gitlab and MRs, I feel that mesa development has gotten > more opaque. Say what you will about mailing lists, but at least you > could have a drive by view of what's going on. With MRs, you sort of > have to seek out what to review; if stuff is not tagged with something > you feel is relevant, you probably won't look at it, so the only > people likely to review it are the people involved in writing it in > the first place, which would be the same whether it's mesa or some > other project. I think all of the projects generally have the best > intentions at heart, but for better or worse they just have different > development models. In the case of the AMD throw it over the wall > stuff, it's not really an anti-open source or community engagement > issue, it's more of how to we support several OSes, tons of new > products, several custom projects, etc. while leveraging as much > shared code as possible. There are ways to make it work, but they are > usually a pretty heavy lift that not all teams can make. I think there's a difference between All Tools Sucks (tm) and the discussions not even being accessible at all. I do agree that generally everyone screws up uapi once in a while, and we seem to overall do a not too shoddy job. So code is probably all ok enough. But imo long term code is fungible and really doesn't matter much, the important stuff is the people and teams who create it, and all the shared knowledge. That's also were I see the benefit in upstream (for customers and vendors and everyone), we can learn from each another. As an example, I've spent lots of time recently reading amdgpu code and how it's used in userspace. Understanding that without having access to the discussion or being able to ping people on irc and mailing lists would have been impossible - lots of questions where I just plain guessed wrong. For the code-over-wall projects that stuff all simply doesn't exist. It's nigh impossible to figure out whether uapi makes sense or not if you can't see all the tradeoffs and discussions that influenced it and why. That's also why I think the separate pull won't help at all, since Dave will still have incomplete information. All he can do with more pulls is roll the die more often, that's not helping. Now short term "moar hw support" is cool and all that, but long term I do think it's missing the point of upstreaming. It's not that mesa (or any other cross vendor project, we have a bunch of those on the kms side) is better at uapi, it's that it's more open and so _much_ easier to understand how we ended up at a specific place. That's at least my take on all this. > All of that said, I think providing a link to the userspace user of > the API is reasonable, but I don't think there have been any egregious > cases of badly designed UAPI that were not caught using the existing > processes. Imo the problem isn't the lack of links, but lack of (public)
[PULL] drm-intel-fixes
Hi Dave and Daniel, Here goes drm-intel-fixes-2019-10-17: - Display fix on handling VBT information. - Important circular locking fix - Fix for preemption vs resubmission on virtual requests - and a prep patch to make this last one to apply cleanly Thanks, Rodrigo. The following changes since commit 4f5cafb5cb8471e54afdc9054d973535614f7675: Linux 5.4-rc3 (2019-10-13 16:37:36 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-10-17 for you to fetch changes up to 0a544a2a728e2e33bb7fc38dd542ecb90ee393eb: drm/i915: Fixup preempt-to-busy vs resubmission of a virtual request (2019-10-16 10:57:33 -0700) - Display fix on handling VBT information. - Important circular locking fix - Fix for preemption vs resubmission on virtual requests - and a prep patch to make this last one to apply cleanly Chris Wilson (3): drm/i915/execlists: Refactor -EIO markup of hung requests drm/i915/userptr: Never allow userptr into the mappable GGTT drm/i915: Fixup preempt-to-busy vs resubmission of a virtual request Ville Syrjälä (1): drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin drivers/gpu/drm/i915/display/intel_bios.c| 22 ++--- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +++ drivers/gpu/drm/i915/gem/i915_gem_object.h | 6 +++ drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 +- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 1 + drivers/gpu/drm/i915/gt/intel_lrc.c | 63 drivers/gpu/drm/i915/i915_gem.c | 3 ++ 7 files changed, 78 insertions(+), 27 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6.1 5/8] drm: rcar-du: crtc: Control CMM operations
Implement CMM handling in the crtc begin and enable atomic callbacks,
and enable CMM unit through the Display Extensional Functions
register at group setup time.
Reviewed-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
v6 -> v6.1
- Drop check for CMM in rcar_du_cmm_check as if the gamma_table property is
available, a CMM unit for this CRTC was registered
- Add TODO note to investigate how the activation order of CMM and CRTC
impact on the first displayed fram
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 61 +
drivers/gpu/drm/rcar-du/rcar_du_group.c | 10
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 ++
3 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 23f1d6cc1719..3f0f16946f42 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -21,6 +21,7 @@
#include
#include
+#include "rcar_cmm.h"
#include "rcar_du_crtc.h"
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
@@ -474,6 +475,45 @@ static void rcar_du_crtc_wait_page_flip(struct
rcar_du_crtc *rcrtc)
rcar_du_crtc_finish_page_flip(rcrtc);
}
+/*
-
+ * Color Management Module (CMM)
+ */
+
+static int rcar_du_cmm_check(struct drm_crtc *crtc,
+struct drm_crtc_state *state)
+{
+ struct drm_property_blob *drm_lut = state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct device *dev = rcrtc->dev->dev;
+
+ if (!drm_lut)
+ return 0;
+
+ /* We only accept fully populated LUT tables. */
+ if (drm_color_lut_size(drm_lut) != CM2_LUT_SIZE) {
+ dev_err(dev, "invalid gamma lut size: %lu bytes\n",
+ drm_lut->length);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void rcar_du_cmm_setup(struct drm_crtc *crtc)
+{
+ struct drm_property_blob *drm_lut = crtc->state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct rcar_cmm_config cmm_config = {};
+
+ if (!rcrtc->cmm)
+ return;
+
+ if (drm_lut)
+ cmm_config.lut.table = (struct drm_color_lut *)drm_lut->data;
+
+ rcar_cmm_setup(rcrtc->cmm, _config);
+}
+
/*
-
* Start/Stop and Suspend/Resume
*/
@@ -619,6 +659,9 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_disable(rcrtc);
+ if (rcrtc->cmm)
+ rcar_cmm_disable(rcrtc->cmm);
+
/*
* Select switch sync mode. This stops display operation and configures
* the HSYNC and VSYNC signals as inputs.
@@ -642,6 +685,11 @@ static int rcar_du_crtc_atomic_check(struct drm_crtc *crtc,
{
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(state);
struct drm_encoder *encoder;
+ int ret;
+
+ ret = rcar_du_cmm_check(crtc, state);
+ if (ret)
+ return ret;
/* Store the routes from the CRTC output to the DU outputs. */
rstate->outputs = 0;
@@ -667,6 +715,8 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(crtc->state);
struct rcar_du_device *rcdu = rcrtc->dev;
+ if (rcrtc->cmm)
+ rcar_cmm_enable(rcrtc->cmm);
rcar_du_crtc_get(rcrtc);
/*
@@ -686,6 +736,13 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
}
rcar_du_crtc_start(rcrtc);
+
+ /*
+* TODO: The chip manual indicates that CMM tables should be written
+* after the DU channel has been activated. Investigate the impact
+* of this restriction on the first displayed frame.
+*/
+ rcar_du_cmm_setup(crtc);
}
static void rcar_du_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -739,6 +796,10 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc
*crtc,
*/
rcar_du_crtc_get(rcrtc);
+ /* If the active state changed, we let .atomic_enable handle CMM. */
+ if (crtc->state->color_mgmt_changed && !crtc->state->active_changed)
+ rcar_du_cmm_setup(crtc);
+
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_atomic_begin(rcrtc);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 9eee47969e77..88a783ceb3e9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -135,6 +135,7 @@ static void rcar_du_group_setup_didsr(struct rcar_du_group
*rgrp)
static void rcar_du_group_setup(struct rcar_du_group *rgrp)
{
struct rcar_du_device *rcdu =
[PATCH 6.1 3/8] drm: rcar-du: Add support for CMM
Add a driver for the R-Car Display Unit Color Correction Module.
In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
to perform image enhancement and color correction.
Add support for CMM through a driver that supports configuration of
the 1-dimensional LUT table. More advanced CMM features will be
implemented on top of this initial one.
Reviewed-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
v6 -> v6.1
- Expand rcar_cmm_setup() function documentation to detail its relationship
with rcar_cmm_enable() and their call order precedence.
---
drivers/gpu/drm/rcar-du/Kconfig| 7 +
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rcar_cmm.c | 217 +
drivers/gpu/drm/rcar-du/rcar_cmm.h | 58
4 files changed, 283 insertions(+)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 1529849e217e..539d232790d1 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -13,6 +13,13 @@ config DRM_RCAR_DU
Choose this option if you have an R-Car chipset.
If M is selected the module will be called rcar-du-drm.
+config DRM_RCAR_CMM
+ bool "R-Car DU Color Management Module (CMM) Support"
+ depends on DRM && OF
+ depends on DRM_RCAR_DU
+ help
+ Enable support for R-Car Color Management Module (CMM).
+
config DRM_RCAR_DW_HDMI
tristate "R-Car DU Gen3 HDMI Encoder Support"
depends on DRM && OF
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 6c2ed9c46467..4d1187ccc3e5 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o \
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
+obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
b/drivers/gpu/drm/rcar-du/rcar_cmm.c
new file mode 100644
index ..952316eb202b
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * rcar_cmm.c -- R-Car Display Unit Color Management Module
+ *
+ * Copyright (C) 2019 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "rcar_cmm.h"
+
+#define CM2_LUT_CTRL 0x
+#define CM2_LUT_CTRL_LUT_ENBIT(0)
+#define CM2_LUT_TBL_BASE 0x0600
+#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
+
+struct rcar_cmm {
+ void __iomem *base;
+
+ /*
+* @lut:1D-LUT state
+* @lut.enabled:1D-LUT enabled flag
+*/
+ struct {
+ bool enabled;
+ } lut;
+};
+
+static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
+{
+ return ioread32(rcmm->base + reg);
+}
+
+static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32 data)
+{
+ iowrite32(data, rcmm->base + reg);
+}
+
+/*
+ * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware precision
+ * and write to the CMM registers
+ * @rcmm: Pointer to the CMM device
+ * @drm_lut: Pointer to the DRM LUT table
+ */
+static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
+ const struct drm_color_lut *drm_lut)
+{
+ unsigned int i;
+
+ for (i = 0; i < CM2_LUT_SIZE; ++i) {
+ u32 entry = drm_color_lut_extract(drm_lut[i].red, 8) << 16
+ | drm_color_lut_extract(drm_lut[i].green, 8) << 8
+ | drm_color_lut_extract(drm_lut[i].blue, 8);
+
+ rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
+ }
+}
+
+/*
+ * rcar_cmm_setup() - Configure the CMM unit
+ * @pdev: The platform device associated with the CMM instance
+ * @config: The CMM unit configuration
+ *
+ * Configure the CMM unit with the given configuration. Currently enabling,
+ * disabling and programming of the 1-D LUT unit is supported.
+ *
+ * As rcar_cmm_setup() accesses the CMM registers the unit should be powered
+ * and its functional clock enabled. To guarantee this, before any call to
+ * this function is made, the CMM unit has to be enabled by calling
+ * rcar_cmm_enable() first.
+ *
+ * TODO: Add support for LUT double buffer operations to avoid updating the
+ * LUT table entries while a frame is being displayed.
+ */
+int rcar_cmm_setup(struct platform_device *pdev,
+ const struct rcar_cmm_config *config)
+{
+ struct rcar_cmm *rcmm = platform_get_drvdata(pdev);
+
+
Re: [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic
On Thu, Oct 17, 2019 at 05:47:47PM +0530, kgu...@codeaurora.org wrote:
> On 2019-10-17 16:59, Daniel Thompson wrote:
> > On Wed, Oct 16, 2019 at 03:43:46PM +0530, Kiran Gunda wrote:
> > > The auto string detection algorithm checks if the current WLED
> > > sink configuration is valid. It tries enabling every sink and
> > > checks if the OVP fault is observed. Based on this information
> > > it detects and enables the valid sink configuration.
> > > Auto calibration will be triggered when the OVP fault interrupts
> > > are seen frequently thereby it tries to fix the sink configuration.
> > >
> > > The auto-detection also kicks in when the connected LED string
> > > of the display-backlight malfunctions (because of damage) and
> > > requires the damaged string to be turned off to prevent the
> > > complete panel and/or board from being damaged.
> > >
> > > Signed-off-by: Kiran Gunda
> >
> > It's a complex bit of code but I'm OK with it in principle. Everything
> > below is about small details and/or nitpicking.
> >
> >
> > > +static void wled_ovp_work(struct work_struct *work)
> > > +{
> > > + struct wled *wled = container_of(work,
> > > + struct wled, ovp_work.work);
> > > + enable_irq(wled->ovp_irq);
> > > +}
> > > +
> >
> > A bit of commenting about why we have to wait 10ms before enabling the
> > OVP interrupt would be appreciated.
> >
> >
> Sure. Will add the comment in the next series.
> > > +static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
> > > +{
> > > + struct wled *wled = _wled;
> > > + int rc;
> > > + u32 int_sts, fault_sts;
> > > +
> > > + rc = regmap_read(wled->regmap,
> > > + wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, _sts);
> > > + if (rc < 0) {
> > > + dev_err(wled->dev, "Error in reading WLED3_INT_RT_STS rc=%d\n",
> > > + rc);
> > > + return IRQ_HANDLED;
> > > + }
> > > +
> > > + rc = regmap_read(wled->regmap, wled->ctrl_addr +
> > > + WLED3_CTRL_REG_FAULT_STATUS, _sts);
> > > + if (rc < 0) {
> > > + dev_err(wled->dev, "Error in reading WLED_FAULT_STATUS rc=%d\n",
> > > + rc);
> > > + return IRQ_HANDLED;
> > > + }
> > > +
> > > + if (fault_sts &
> > > + (WLED3_CTRL_REG_OVP_FAULT_BIT | WLED3_CTRL_REG_ILIM_FAULT_BIT))
> > > + dev_dbg(wled->dev, "WLED OVP fault detected, int_sts=%x
> > > fault_sts= %x\n",
> > > + int_sts, fault_sts);
> > > +
> > > + if (fault_sts & WLED3_CTRL_REG_OVP_FAULT_BIT) {
> > > + mutex_lock(>lock);
> > > + disable_irq_nosync(wled->ovp_irq);
> >
> > We're currently running the threaded ISR for this irq. Do we really need
> > to disable it?
> >
> We need to disable this IRQ, during the auto string detection logic. Because
> in the auto string detection we configure the current sinks one by one and
> check the
> status register for the OVPs and set the right string configuration. We
> enable it later after
> the auto string detection is completed.
This is a threaded oneshot interrupt handler. Why isn't the framework
masking sufficient for you here?
Daniel.
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 6:11 AM Thierry Reding wrote:
>
> On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> > On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > > On 17. 10. 19 10:10, Uwe Kleine-König wrote:
> > > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > > pwm_get_state() return the last implemented state")) changed the
> > > > semantic of pwm_get_state() and disclosed an (as it seems) common
> > > > problem in lowlevel PWM drivers. By not relying on the period and duty
> > > > cycle being retrievable from a disabled PWM this type of problem is
> > > > worked around.
> > > >
> > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > combo once is also more effective.
> > > >
> > > > Signed-off-by: Uwe Kleine-König
> > > > ---
> > > > Hello,
> > > >
> > > > There are now two reports about 01ccf903edd6 breaking a backlight. As
> > > > far as I understand the problem this is a combination of the backend pwm
> > > > driver yielding surprising results and the pwm-bl driver doing things
> > > > more complicated than necessary.
> > > >
> > > > So I guess this patch works around these problems. Still it would be
> > > > interesting to find out the details in the imx driver that triggers the
> > > > problem. So Adam, can you please instrument the pwm-imx27 driver to
> > > > print *state at the beginning of pwm_imx27_apply() and the end of
> > > > pwm_imx27_get_state() and provide the results?
> > > >
> > > > Note I only compile tested this change.
> > >
> > > Hi Uwe,
> > > I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
> > > thread that I have a similar problem when you submitted this patch.
> > >
> > > So here are my few cents:
> > >
> > > My setup is as follows:
> > > - imx6dl-yapp4-draco with i.MX6Solo
> > > - backlight is controlled with inverted PWM signal
> > > - max brightness level = 32, default brightness level set to 32 in DT.
> > >
> > > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
> > >pwm_get_state() return the last implemented state):
> > >
> > > - System boots to userspace and backlight is enabled all the time from
> > >power up.
> > >
> > >$ dmesg | grep state
> > >[1.763381] get state end: -1811360608, enabled: 0
> >
> > What is -1811360608? When I wrote "print *state" above, I thought about
> > something like:
> >
> > pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
> > __func__, state->period, state->duty_cycle, state->polarity,
> > state->enabled);
> >
> > A quick look into drivers/pwm/pwm-imx27.c shows that this is another
> > driver that yields duty_cycle = 0 when the hardware is off.
>
> It seems to me like the best recourse to fix this for now would be to
> patch up the drivers that return 0 when the hardware is off by caching
> the currently configured duty cycle.
>
> How about the patch below?
>
> Thierry
>
> --- >8 ---
> From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00 2001
> From: Thierry Reding
> Date: Thu, 17 Oct 2019 12:56:00 +0200
> Subject: [PATCH] pwm: imx27: Cache duty cycle register value
>
> The hardware register containing the duty cycle value cannot be accessed
> when the PWM is disabled. This causes the ->get_state() callback to read
> back a duty cycle value of 0, which can confuse consumer drivers.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/pwm/pwm-imx27.c | 31 ---
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> index ae11d8577f18..4113d5cd4c62 100644
> --- a/drivers/pwm/pwm-imx27.c
> +++ b/drivers/pwm/pwm-imx27.c
> @@ -85,6 +85,13 @@ struct pwm_imx27_chip {
> struct clk *clk_per;
> void __iomem*mmio_base;
> struct pwm_chip chip;
> +
> + /*
> +* The driver cannot read the current duty cycle from the hardware if
> +* the hardware is disabled. Cache the last programmed duty cycle
> +* value to return in that case.
> +*/
> + unsigned int duty_cycle;
> };
>
> #define to_pwm_imx27_chip(chip)container_of(chip, struct
> pwm_imx27_chip, chip)
> @@ -155,14 +162,17 @@ static void pwm_imx27_get_state(struct pwm_chip *chip,
> tmp = NSEC_PER_SEC * (u64)(period + 2);
> state->period = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
>
> - /* PWMSAR can be read only if PWM is enabled */
> - if (state->enabled) {
> + /*
> +* PWMSAR can be read only if PWM is enabled. If the PWM is disabled,
> +* use the cached value.
> +*/
> + if (state->enabled)
> val = readl(imx->mmio_base + MX3_PWMSAR);
> - tmp = NSEC_PER_SEC * (u64)(val);
> - state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
> - } else {
> - state->duty_cycle = 0;
> - }
> + else
> +
Re: [PATCH] gpu: host1x: make 'host1x_cdma_wait_pushbuffer_space' static
On Thu, Oct 17, 2019 at 12:04:27PM +0100, Ben Dooks (Codethink) wrote: > The host1x_cdma_wait_pushbuffer_space function is not declared > or directly called from outside the file it is in, so make it > static. > > Fixes the following sparse warnign: > drivers/gpu/host1x/cdma.c:235:5: warning: symbol > 'host1x_cdma_wait_pushbuffer_space' was not declared. Should it be static? > > Signed-off-by: Ben Dooks > --- > Cc: Thierry Reding > Cc: dri-devel@lists.freedesktop.org > Cc: linux-te...@vger.kernel.org > --- > drivers/gpu/host1x/cdma.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Applied, thanks. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic
On Thu, 17 Oct 2019, kgu...@codeaurora.org wrote:
> On 2019-10-17 17:56, Lee Jones wrote:
> > On Wed, 16 Oct 2019, Kiran Gunda wrote:
> >
> > > The auto string detection algorithm checks if the current WLED
> > > sink configuration is valid. It tries enabling every sink and
> > > checks if the OVP fault is observed. Based on this information
> > > it detects and enables the valid sink configuration.
> > > Auto calibration will be triggered when the OVP fault interrupts
> > > are seen frequently thereby it tries to fix the sink configuration.
> > >
> > > The auto-detection also kicks in when the connected LED string
> > > of the display-backlight malfunctions (because of damage) and
> > > requires the damaged string to be turned off to prevent the
> > > complete panel and/or board from being damaged.
> > >
> > > Signed-off-by: Kiran Gunda
> > > ---
> > > drivers/video/backlight/qcom-wled.c | 410
> > > +++-
> > > 1 file changed, 404 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/video/backlight/qcom-wled.c
> > > b/drivers/video/backlight/qcom-wled.c
> > > index b5b125c..ff7c409 100644
> > > --- a/drivers/video/backlight/qcom-wled.c
> > > +++ b/drivers/video/backlight/qcom-wled.c
[...]
> > > + if (int_sts & WLED3_CTRL_REG_OVP_FAULT_STATUS)
> > > + dev_dbg(wled->dev, "WLED OVP fault detected with SINK
> > > %d\n",
> > > + i + 1);
> >
> > I haven't reviewed the whole patch, but this caught my eye.
> >
> > I think this should be upgraded to dev_warn().
> >
> Thought of keeping these messages silent, Because the string configuration
> will be corrected in this
> and informing it at end of the auto string detection.
[...]
> > > + } else {
> > > + dev_warn(wled->dev, "New WLED string configuration found %x\n",
> > > + sink_valid);
> >
> > Why would the user care about this? Is it not normal?
> >
> Actually, it comes here if the user provided string configuration in the
> device tree is in-correct.
> That's why just informing the user about the right string configuration,
> after the auto string detection.
Then I think we need to be more forthcoming. Tell the user the
configuration is incorrect and what you've done to rectify it.
"XXX is not a valid configuration - using YYY instead"
[...]
> > > +static int wled_configure_ovp_irq(struct wled *wled,
> > > + struct platform_device *pdev)
> > > +{
> > > + int rc;
> > > + u32 val;
> > > +
> > > + wled->ovp_irq = platform_get_irq_byname(pdev, "ovp");
> > > + if (wled->ovp_irq < 0) {
> > > + dev_dbg(>dev, "ovp irq is not used\n");
> >
> > I assume this is optional. What happens if no IRQ is provided?
> >
> Here OVP IRQ is used to detect the wrong string detection. If it is not
> provided the auto string detection logic won't work.
"OVP IRQ not found - disabling automatic string detection"
> > If, for instance, polling mode is enabled, maybe something like this
> > would be better?
> >
> > dev_warn(>dev, "No IRQ found, falling back to polling
> > mode\n");
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 29/34] backlight/jornada720: Use CONFIG_PREEMPTION
On 2019-10-17 14:23:24 [+0100], Lee Jones wrote: > So what are the OP's expectations in that regard? I see this is a > large set and I am only privy to this patch, thus lack wider > visibility. Does this patch depend on others, or is it independent? > I'm happy to take it, but wish to avoid bisectability issues in the > next release kernel. It is independent, you can apply it to your -next branch. All dependencies are merged. Sebastian
[PATCH 5/5] drm/qxl: allocate small objects top-down
qxl uses small buffer objects for qxl commands.
Allocate them top-down to reduce fragmentation.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_object.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index 927ab917b834..ad336c98a0cf 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -54,9 +54,14 @@ bool qxl_ttm_bo_is_qxl_bo(struct ttm_buffer_object *bo)
void qxl_ttm_placement_from_domain(struct qxl_bo *qbo, u32 domain, bool pinned)
{
u32 c = 0;
- u32 pflag = pinned ? TTM_PL_FLAG_NO_EVICT : 0;
+ u32 pflag = 0;
unsigned int i;
+ if (pinned)
+ pflag |= TTM_PL_FLAG_NO_EVICT;
+ if (qbo->tbo.base.size <= PAGE_SIZE)
+ pflag |= TTM_PL_FLAG_TOPDOWN;
+
qbo->placement.placement = qbo->placements;
qbo->placement.busy_placement = qbo->placements;
if (domain == QXL_GEM_DOMAIN_VRAM)
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/qxl: use DEFINE_DRM_GEM_FOPS()
We have no qxl-specific fops any more.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 65464630ac98..1d601f57a6ba 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -150,15 +150,7 @@ qxl_pci_remove(struct pci_dev *pdev)
drm_dev_put(dev);
}
-static const struct file_operations qxl_fops = {
- .owner = THIS_MODULE,
- .open = drm_open,
- .release = drm_release,
- .unlocked_ioctl = drm_ioctl,
- .poll = drm_poll,
- .read = drm_read,
- .mmap = drm_gem_mmap,
-};
+DEFINE_DRM_GEM_FOPS(qxl_fops);
static int qxl_drm_freeze(struct drm_device *dev)
{
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/qxl: drop verify_access
Not needed any more.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_ttm.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 629ac8e77a21..54cc5a5b607e 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -110,14 +110,6 @@ static void qxl_evict_flags(struct ttm_buffer_object *bo,
*placement = qbo->placement;
}
-static int qxl_verify_access(struct ttm_buffer_object *bo, struct file *filp)
-{
- struct qxl_bo *qbo = to_qxl_bo(bo);
-
- return drm_vma_node_verify_access(>tbo.base.vma_node,
- filp->private_data);
-}
-
static int qxl_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_mem_reg *mem)
{
@@ -269,7 +261,6 @@ static struct ttm_bo_driver qxl_bo_driver = {
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = _evict_flags,
.move = _bo_move,
- .verify_access = _verify_access,
.io_mem_reserve = _ttm_io_mem_reserve,
.io_mem_free = _ttm_io_mem_free,
.move_notify = _bo_move_notify,
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm/qxl: a collection of small tweaks.
Switch qxl driver to the new mmap workflow, some cleanups, reduce memory fragmentation. Series needs latest drm-misc-next to build. Gerd Hoffmann (5): drm/qxl: drop qxl_ttm_fault drm/qxl: switch qxl to _gem_object_funcs.mmap drm/qxl: drop verify_access drm/qxl: use DEFINE_DRM_GEM_FOPS() drm/qxl: allocate small objects top-down drivers/gpu/drm/qxl/qxl_drv.h| 1 - drivers/gpu/drm/qxl/qxl_drv.c| 10 +-- drivers/gpu/drm/qxl/qxl_object.c | 8 - drivers/gpu/drm/qxl/qxl_ttm.c| 50 4 files changed, 8 insertions(+), 61 deletions(-) -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/qxl: drop qxl_ttm_fault
Not sure what this hook is supposed to do. vmf->vma->vm_private_data
should never be NULL, so the extra check in qxl_ttm_fault should have no
effect.
Drop it.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_ttm.c | 27 +--
1 file changed, 1 insertion(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index cbc6c2ba8630..dba925589e17 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -48,24 +48,8 @@ static struct qxl_device *qxl_get_qdev(struct ttm_bo_device
*bdev)
return qdev;
}
-static struct vm_operations_struct qxl_ttm_vm_ops;
-static const struct vm_operations_struct *ttm_vm_ops;
-
-static vm_fault_t qxl_ttm_fault(struct vm_fault *vmf)
-{
- struct ttm_buffer_object *bo;
- vm_fault_t ret;
-
- bo = (struct ttm_buffer_object *)vmf->vma->vm_private_data;
- if (bo == NULL)
- return VM_FAULT_NOPAGE;
- ret = ttm_vm_ops->fault(vmf);
- return ret;
-}
-
int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
{
- int r;
struct drm_file *file_priv = filp->private_data;
struct qxl_device *qdev = file_priv->minor->dev->dev_private;
@@ -77,16 +61,7 @@ int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
DRM_DEBUG_DRIVER("filp->private_data = 0x%p, vma->vm_pgoff = %lx\n",
filp->private_data, vma->vm_pgoff);
- r = ttm_bo_mmap(filp, vma, >mman.bdev);
- if (unlikely(r != 0))
- return r;
- if (unlikely(ttm_vm_ops == NULL)) {
- ttm_vm_ops = vma->vm_ops;
- qxl_ttm_vm_ops = *ttm_vm_ops;
- qxl_ttm_vm_ops.fault = _ttm_fault;
- }
- vma->vm_ops = _ttm_vm_ops;
- return 0;
+ return ttm_bo_mmap(filp, vma, >mman.bdev);
}
static int qxl_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/qxl: switch qxl to _gem_object_funcs.mmap
Wire up the new drm_gem_ttm_mmap() helper function.
Use generic drm_gem_mmap() and remove qxl_mmap().
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 1 -
drivers/gpu/drm/qxl/qxl_drv.c| 2 +-
drivers/gpu/drm/qxl/qxl_object.c | 1 +
drivers/gpu/drm/qxl/qxl_ttm.c| 16
4 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index d4051409ce64..a5cb3864d686 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -355,7 +355,6 @@ int qxl_mode_dumb_mmap(struct drm_file *filp,
/* qxl ttm */
int qxl_ttm_init(struct qxl_device *qdev);
void qxl_ttm_fini(struct qxl_device *qdev);
-int qxl_mmap(struct file *filp, struct vm_area_struct *vma);
/* qxl image */
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 483b4c57554a..65464630ac98 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -157,7 +157,7 @@ static const struct file_operations qxl_fops = {
.unlocked_ioctl = drm_ioctl,
.poll = drm_poll,
.read = drm_read,
- .mmap = qxl_mmap,
+ .mmap = drm_gem_mmap,
};
static int qxl_drm_freeze(struct drm_device *dev)
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index c013c516f561..927ab917b834 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -86,6 +86,7 @@ static const struct drm_gem_object_funcs qxl_object_funcs = {
.get_sg_table = qxl_gem_prime_get_sg_table,
.vmap = qxl_gem_prime_vmap,
.vunmap = qxl_gem_prime_vunmap,
+ .mmap = drm_gem_ttm_mmap,
.print_info = drm_gem_ttm_print_info,
};
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index dba925589e17..629ac8e77a21 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -48,22 +48,6 @@ static struct qxl_device *qxl_get_qdev(struct ttm_bo_device
*bdev)
return qdev;
}
-int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
-{
- struct drm_file *file_priv = filp->private_data;
- struct qxl_device *qdev = file_priv->minor->dev->dev_private;
-
- if (qdev == NULL) {
- DRM_ERROR(
-"filp->private_data->minor->dev->dev_private == NULL\n");
- return -EINVAL;
- }
- DRM_DEBUG_DRIVER("filp->private_data = 0x%p, vma->vm_pgoff = %lx\n",
- filp->private_data, vma->vm_pgoff);
-
- return ttm_bo_mmap(filp, vma, >mman.bdev);
-}
-
static int qxl_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
{
return 0;
--
2.18.1
Re: [PATCH 29/34] backlight/jornada720: Use CONFIG_PREEMPTION
On Thu, 17 Oct 2019, Daniel Thompson wrote: > On Tue, Oct 15, 2019 at 09:18:16PM +0200, Sebastian Andrzej Siewior wrote: > > From: Thomas Gleixner > > > > CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT. > > Both PREEMPT and PREEMPT_RT require the same functionality which today > > depends on CONFIG_PREEMPT. > > > > Switch the Kconfig dependency to CONFIG_PREEMPTION. > > > > Cc: Lee Jones > > Cc: Daniel Thompson > > Cc: Jingoo Han > > Cc: Bartlomiej Zolnierkiewicz > > Cc: dri-devel@lists.freedesktop.org > > Cc: linux-fb...@vger.kernel.org > > Signed-off-by: Thomas Gleixner > > [bigeasy: +LCD_HP700] > > Signed-off-by: Sebastian Andrzej Siewior > > Reviewed-by: Daniel Thompson > > (I know... the review for this particular patch is trivial but an > Acked-by from a maintainer means something specific and it is Lee > Jones who coordinates landing cross sub-system patch sets for > backlight). Right. Thanks Dan. So what are the OP's expectations in that regard? I see this is a large set and I am only privy to this patch, thus lack wider visibility. Does this patch depend on others, or is it independent? I'm happy to take it, but wish to avoid bisectability issues in the next release kernel. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 02:19:45PM +0200, Uwe Kleine-König wrote:
> On Thu, Oct 17, 2019 at 12:47:27PM +0100, Daniel Thompson wrote:
> > On Thu, Oct 17, 2019 at 10:10:59AM +0200, Uwe Kleine-König wrote:
> > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > pwm_get_state() return the last implemented state")) changed the
> > > semantic of pwm_get_state() and disclosed an (as it seems) common
> > > problem in lowlevel PWM drivers. By not relying on the period and duty
> > > cycle being retrievable from a disabled PWM this type of problem is
> > > worked around.
> > >
> > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > combo once is also more effective.
> >
> > I'm only interested in the second paragraph here.
> >
> > There seems to be a reasonable consensus that the i.MX27 and cros-ec
> > PWM drivers should be fixed for the benefit of other PWM clients.
> > So we make this change because it makes the pwm-bl better... not to
> > work around bugs ;-).
>
> That's fine, still I think it's fair to explain the motivation of
> creating this patch.
Maybe.
Whether this patch is a workaround or simply an improvement to pwm-bl
does need to be clear since it affects whether Lee steers it towards
v5.4-rcX or linux-next .
Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/mipi_dbi: Use simple right shift instead of double negation
On Thu, Oct 17, 2019 at 02:49:12PM +0300, Andy Shevchenko wrote: > GCC complains about dubious bitwise OR operand: > > drivers/gpu/drm/drm_mipi_dbi.c:1024:49: warning: dubious: x | !y > CC [M] drivers/gpu/drm/drm_mipi_dbi.o > > As long as buffer is consist of byte (u8) values, we may use > simple right shift and satisfy compiler. It also reduces amount of > operations needed. > > Signed-off-by: Andy Shevchenko > --- > drivers/gpu/drm/drm_mipi_dbi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c > index 1961f713aaab..445e88b1fc9a 100644 > --- a/drivers/gpu/drm/drm_mipi_dbi.c > +++ b/drivers/gpu/drm/drm_mipi_dbi.c > @@ -1021,7 +1021,7 @@ static int mipi_dbi_typec3_command_read(struct mipi_dbi > *dbi, u8 *cmd, > unsigned int i; > > for (i = 0; i < len; i++) > - data[i] = (buf[i] << 1) | !!(buf[i + 1] & BIT(7)); > + data[i] = (buf[i] << 1) | (buf[i + 1] >> 7); You should probably have ((buf[i + 1] >> 7) & 0x1) to be super safe. Do you know anything about this code? It seems like nothing is protecting us from overrunning buf in this loop. We're just assuming that len < tr[1].len through this loop and I'm not sure what's protecting us from looking where we shouldn't. Sean > } > > MIPI_DBI_DEBUG_COMMAND(*cmd, data, len); > -- > 2.23.0 > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 8:05 AM Thierry Reding wrote:
>
> On Thu, Oct 17, 2019 at 07:40:47AM -0500, Adam Ford wrote:
> > On Thu, Oct 17, 2019 at 7:34 AM Adam Ford wrote:
> > >
> > > On Thu, Oct 17, 2019 at 7:19 AM Uwe Kleine-König
> > > wrote:
> > > >
> > > > On Thu, Oct 17, 2019 at 12:47:27PM +0100, Daniel Thompson wrote:
> > > > > On Thu, Oct 17, 2019 at 10:10:59AM +0200, Uwe Kleine-König wrote:
> > > > > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > > > > pwm_get_state() return the last implemented state")) changed the
> > > > > > semantic of pwm_get_state() and disclosed an (as it seems) common
> > > > > > problem in lowlevel PWM drivers. By not relying on the period and
> > > > > > duty
> > > > > > cycle being retrievable from a disabled PWM this type of problem is
> > > > > > worked around.
> > > > > >
> > > > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > > > combo once is also more effective.
> > > > >
> > > > > I'm only interested in the second paragraph here.
> > > > >
> > > > > There seems to be a reasonable consensus that the i.MX27 and cros-ec
> > > > > PWM drivers should be fixed for the benefit of other PWM clients.
> > > > > So we make this change because it makes the pwm-bl better... not to
> > > > > work around bugs ;-).
> > > >
> > > > That's fine, still I think it's fair to explain the motivation of
> > > > creating this patch.
> > > >
> > > > > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > > > > b/drivers/video/backlight/pwm_bl.c
> > > > > > index 746eebc411df..ddebd62b3978 100644
> > > > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > > > @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct
> > > > > > pwm_bl_data *pb)
> > > > > >
> > > > > > static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> > > > > > {
> > > > > > - struct pwm_state state;
> > > > > > -
> > > > > > - pwm_get_state(pb->pwm, );
> > > > > > - if (!pb->enabled)
> > > > > > - return;
> > > > > > -
> > > > >
> > > > > Why remove the pb->enabled check? I thought that was there to ensure
> > > > > we
> > > > > don't mess up the regular reference counts.
> > > >
> > > > I havn't looked yet, but I guess I have to respin. Expect a v2 later
> > > > today.
> > >
> > > I would agree that a high-level fix is better than a series of low
> > > level driver fixes. For what its worth, your V1 patch worked fine on
> > > my i.MX6Q. I can test the V2 patch when its ready.
> >
> > I may have spoken too soon. The patch fixes the display in that it
> > comes on when it previously did not, but changes to brightness do not
> > appear to do anything anymore. I don't have an oscilloscope where I
> > am now, so I cannot verify whether or not the PWM duty cycle changes.
> >
> > To my eye, the following do not appear to change the brightness of the
> > screen:
> > echo 7 >
> > /sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
> > echo 2 >
> > /sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
> > echo 5 >
> > /sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
>
> Hi Adam,
>
> can you try the i.MX PWM patch that I posted earlier instead? I really
> think we need to fix this in the PWM drivers because they are broken.
> pwm-backlight is not. -rc3 is really not a time to work around breakage
> in consumers.
I did try your patch, but it did not appear to make any difference on my i.MX6Q.
>
> If my patch doesn't help, can you try reverting the offending patch? If
> we can't come up with a good fix for the drivers, reverting is the next
> best option.
I am able to get an image after reverting the offending patch. I did
not try playing with brightness levels after reverting.
>
> Thierry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic
On 2019-10-17 17:56, Lee Jones wrote:
On Wed, 16 Oct 2019, Kiran Gunda wrote:
The auto string detection algorithm checks if the current WLED
sink configuration is valid. It tries enabling every sink and
checks if the OVP fault is observed. Based on this information
it detects and enables the valid sink configuration.
Auto calibration will be triggered when the OVP fault interrupts
are seen frequently thereby it tries to fix the sink configuration.
The auto-detection also kicks in when the connected LED string
of the display-backlight malfunctions (because of damage) and
requires the damaged string to be turned off to prevent the
complete panel and/or board from being damaged.
Signed-off-by: Kiran Gunda
---
drivers/video/backlight/qcom-wled.c | 410
+++-
1 file changed, 404 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index b5b125c..ff7c409 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
[...]
+ /* iterate through the strings one by one */
Please use proper English in comments (less a full stop).
In this case, just s/iterate/Iterate/.
Sorry for that ! will fix it in next series.
+ for (i = 0; i < wled->cfg.num_strings; i++) {
+ sink_test = BIT((WLED4_SINK_REG_CURR_SINK_SHFT + i));
+
+ /* Enable feedback control */
+ rc = regmap_write(wled->regmap, wled->ctrl_addr +
+ WLED3_CTRL_REG_FEEDBACK_CONTROL, i + 1);
+ if (rc < 0) {
+ dev_err(wled->dev, "Failed to enable feedback for SINK %d rc =
%d\n",
+ i + 1, rc);
+ goto failed_detect;
+ }
+
+ /* enable the sink */
Here too. And everywhere else.
Will fix it in next series.
+ rc = regmap_write(wled->regmap, wled->sink_addr +
+ WLED4_SINK_REG_CURR_SINK, sink_test);
+ if (rc < 0) {
+ dev_err(wled->dev, "Failed to configure SINK %d
rc=%d\n",
+ i + 1, rc);
+ goto failed_detect;
+ }
+
+ /* Enable the module */
+ rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
+ WLED3_CTRL_REG_MOD_EN,
+ WLED3_CTRL_REG_MOD_EN_MASK,
+ WLED3_CTRL_REG_MOD_EN_MASK);
+ if (rc < 0) {
+ dev_err(wled->dev, "Failed to enable WLED module
rc=%d\n",
+ rc);
+ goto failed_detect;
+ }
+
+ usleep_range(WLED_SOFT_START_DLY_US,
+WLED_SOFT_START_DLY_US + 1000);
+
+ rc = regmap_read(wled->regmap, wled->ctrl_addr +
+WLED3_CTRL_REG_INT_RT_STS, _sts);
+ if (rc < 0) {
+ dev_err(wled->dev, "Error in reading WLED3_CTRL_INT_RT_STS
rc=%d\n",
+ rc);
+ goto failed_detect;
+ }
+
+ if (int_sts & WLED3_CTRL_REG_OVP_FAULT_STATUS)
+ dev_dbg(wled->dev, "WLED OVP fault detected with SINK
%d\n",
+ i + 1);
I haven't reviewed the whole patch, but this caught my eye.
I think this should be upgraded to dev_warn().
Thought of keeping these messages silent, Because the string
configuration will be corrected in this
and informing it at end of the auto string detection.
+ else
+ sink_valid |= sink_test;
+
+ /* Disable the module */
+ rc = regmap_update_bits(wled->regmap,
+ wled->ctrl_addr + WLED3_CTRL_REG_MOD_EN,
+ WLED3_CTRL_REG_MOD_EN_MASK, 0);
+ if (rc < 0) {
+ dev_err(wled->dev, "Failed to disable WLED module
rc=%d\n",
+ rc);
+ goto failed_detect;
+ }
+ }
+
+ if (!sink_valid) {
+ dev_err(wled->dev, "No valid WLED sinks found\n");
+ wled->disabled_by_short = true;
+ goto failed_detect;
+ }
+
+ if (sink_valid == sink_config) {
+ dev_dbg(wled->dev, "WLED auto-detection complete, sink-config=%x
OK!\n",
+ sink_config);
Does this really need to be placed in the kernel log?
Ok. This can be removed. I will remove it in next series.
+ } else {
+ dev_warn(wled->dev, "New WLED string configuration found %x\n",
+sink_valid);
Why would the user care about this? Is it not normal?
Actually, it comes here if the user provided string configuration in the
device tree is
[Bug 111987] Unstable performance (periodic and repeating patterns of fps change) and changing VDDGFX
https://bugs.freedesktop.org/show_bug.cgi?id=111987 --- Comment #14 from Alex Deucher --- You can force the clocks low or high by: echo low > power_dpm_force_performance_level or echo high > power_dpm_force_performance_level setting it to auto will restore the automatic behavior: echo auto > power_dpm_force_performance_level The behavior will depend on the workload. If the workload is really bursty, it may cause the clocks to ramp up and down if there are sufficiently long idle periods between workloads. You can manually adjust the heuristics by selecting the custom profile and tweaking each parameter. See the documentation here: https://dri.freedesktop.org/docs/drm/gpu/amdgpu.html#gpu-power-thermal-controls-and-monitoring -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 07:40:47AM -0500, Adam Ford wrote:
> On Thu, Oct 17, 2019 at 7:34 AM Adam Ford wrote:
> >
> > On Thu, Oct 17, 2019 at 7:19 AM Uwe Kleine-König
> > wrote:
> > >
> > > On Thu, Oct 17, 2019 at 12:47:27PM +0100, Daniel Thompson wrote:
> > > > On Thu, Oct 17, 2019 at 10:10:59AM +0200, Uwe Kleine-König wrote:
> > > > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > > > pwm_get_state() return the last implemented state")) changed the
> > > > > semantic of pwm_get_state() and disclosed an (as it seems) common
> > > > > problem in lowlevel PWM drivers. By not relying on the period and duty
> > > > > cycle being retrievable from a disabled PWM this type of problem is
> > > > > worked around.
> > > > >
> > > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > > combo once is also more effective.
> > > >
> > > > I'm only interested in the second paragraph here.
> > > >
> > > > There seems to be a reasonable consensus that the i.MX27 and cros-ec
> > > > PWM drivers should be fixed for the benefit of other PWM clients.
> > > > So we make this change because it makes the pwm-bl better... not to
> > > > work around bugs ;-).
> > >
> > > That's fine, still I think it's fair to explain the motivation of
> > > creating this patch.
> > >
> > > > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > > > b/drivers/video/backlight/pwm_bl.c
> > > > > index 746eebc411df..ddebd62b3978 100644
> > > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > > @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct
> > > > > pwm_bl_data *pb)
> > > > >
> > > > > static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> > > > > {
> > > > > - struct pwm_state state;
> > > > > -
> > > > > - pwm_get_state(pb->pwm, );
> > > > > - if (!pb->enabled)
> > > > > - return;
> > > > > -
> > > >
> > > > Why remove the pb->enabled check? I thought that was there to ensure we
> > > > don't mess up the regular reference counts.
> > >
> > > I havn't looked yet, but I guess I have to respin. Expect a v2 later
> > > today.
> >
> > I would agree that a high-level fix is better than a series of low
> > level driver fixes. For what its worth, your V1 patch worked fine on
> > my i.MX6Q. I can test the V2 patch when its ready.
>
> I may have spoken too soon. The patch fixes the display in that it
> comes on when it previously did not, but changes to brightness do not
> appear to do anything anymore. I don't have an oscilloscope where I
> am now, so I cannot verify whether or not the PWM duty cycle changes.
>
> To my eye, the following do not appear to change the brightness of the screen:
> echo 7 >
> /sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
> echo 2 >
> /sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
> echo 5 >
> /sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
Hi Adam,
can you try the i.MX PWM patch that I posted earlier instead? I really
think we need to fix this in the PWM drivers because they are broken.
pwm-backlight is not. -rc3 is really not a time to work around breakage
in consumers.
If my patch doesn't help, can you try reverting the offending patch? If
we can't come up with a good fix for the drivers, reverting is the next
best option.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 02:09:17PM +0200, Uwe Kleine-König wrote:
> On Thu, Oct 17, 2019 at 01:11:31PM +0200, Thierry Reding wrote:
> > On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> > > On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > > > On 17. 10. 19 10:10, Uwe Kleine-König wrote:
> > > > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > > > pwm_get_state() return the last implemented state")) changed the
> > > > > semantic of pwm_get_state() and disclosed an (as it seems) common
> > > > > problem in lowlevel PWM drivers. By not relying on the period and duty
> > > > > cycle being retrievable from a disabled PWM this type of problem is
> > > > > worked around.
> > > > >
> > > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > > combo once is also more effective.
> > > > >
> > > > > Signed-off-by: Uwe Kleine-König
> > > > > ---
> > > > > Hello,
> > > > >
> > > > > There are now two reports about 01ccf903edd6 breaking a backlight. As
> > > > > far as I understand the problem this is a combination of the backend
> > > > > pwm
> > > > > driver yielding surprising results and the pwm-bl driver doing things
> > > > > more complicated than necessary.
> > > > >
> > > > > So I guess this patch works around these problems. Still it would be
> > > > > interesting to find out the details in the imx driver that triggers
> > > > > the
> > > > > problem. So Adam, can you please instrument the pwm-imx27 driver to
> > > > > print *state at the beginning of pwm_imx27_apply() and the end of
> > > > > pwm_imx27_get_state() and provide the results?
> > > > >
> > > > > Note I only compile tested this change.
> > > >
> > > > Hi Uwe,
> > > > I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
> > > > thread that I have a similar problem when you submitted this patch.
> > > >
> > > > So here are my few cents:
> > > >
> > > > My setup is as follows:
> > > > - imx6dl-yapp4-draco with i.MX6Solo
> > > > - backlight is controlled with inverted PWM signal
> > > > - max brightness level = 32, default brightness level set to 32 in DT.
> > > >
> > > > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
> > > >pwm_get_state() return the last implemented state):
> > > >
> > > > - System boots to userspace and backlight is enabled all the time from
> > > >power up.
> > > >
> > > >$ dmesg | grep state
> > > >[1.763381] get state end: -1811360608, enabled: 0
> > >
> > > What is -1811360608? When I wrote "print *state" above, I thought about
> > > something like:
> > >
> > > pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
> > > __func__, state->period, state->duty_cycle, state->polarity,
> > > state->enabled);
> > >
> > > A quick look into drivers/pwm/pwm-imx27.c shows that this is another
> > > driver that yields duty_cycle = 0 when the hardware is off.
> >
> > It seems to me like the best recourse to fix this for now would be to
> > patch up the drivers that return 0 when the hardware is off by caching
> > the currently configured duty cycle.
> >
> > How about the patch below?
> >
> > Thierry
> >
> > --- >8 ---
> > From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00 2001
> > From: Thierry Reding
> > Date: Thu, 17 Oct 2019 12:56:00 +0200
> > Subject: [PATCH] pwm: imx27: Cache duty cycle register value
> >
> > The hardware register containing the duty cycle value cannot be accessed
> > when the PWM is disabled. This causes the ->get_state() callback to read
> > back a duty cycle value of 0, which can confuse consumer drivers.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > drivers/pwm/pwm-imx27.c | 31 ---
> > 1 file changed, 24 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> > index ae11d8577f18..4113d5cd4c62 100644
> > --- a/drivers/pwm/pwm-imx27.c
> > +++ b/drivers/pwm/pwm-imx27.c
> > @@ -85,6 +85,13 @@ struct pwm_imx27_chip {
> > struct clk *clk_per;
> > void __iomem*mmio_base;
> > struct pwm_chip chip;
> > +
> > + /*
> > +* The driver cannot read the current duty cycle from the hardware if
> > +* the hardware is disabled. Cache the last programmed duty cycle
> > +* value to return in that case.
> > +*/
> > + unsigned int duty_cycle;
> > };
> >
> > #define to_pwm_imx27_chip(chip)container_of(chip, struct
> > pwm_imx27_chip, chip)
> > @@ -155,14 +162,17 @@ static void pwm_imx27_get_state(struct pwm_chip *chip,
> > tmp = NSEC_PER_SEC * (u64)(period + 2);
> > state->period = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
> >
> > - /* PWMSAR can be read only if PWM is enabled */
> > - if (state->enabled) {
> > + /*
> > +* PWMSAR can be read only if PWM is enabled. If the PWM is disabled,
> > +* use the cached value.
> > +*/
> > + if (state->enabled)
> > val =
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 3:11 AM Uwe Kleine-König
wrote:
>
> A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> pwm_get_state() return the last implemented state")) changed the
> semantic of pwm_get_state() and disclosed an (as it seems) common
> problem in lowlevel PWM drivers. By not relying on the period and duty
> cycle being retrievable from a disabled PWM this type of problem is
> worked around.
>
> Apart from this issue only calling the pwm_get_state/pwm_apply_state
> combo once is also more effective.
>
> Signed-off-by: Uwe Kleine-König
> ---
> Hello,
>
> There are now two reports about 01ccf903edd6 breaking a backlight. As
> far as I understand the problem this is a combination of the backend pwm
> driver yielding surprising results and the pwm-bl driver doing things
> more complicated than necessary.
>
> So I guess this patch works around these problems. Still it would be
> interesting to find out the details in the imx driver that triggers the
> problem. So Adam, can you please instrument the pwm-imx27 driver to
> print *state at the beginning of pwm_imx27_apply() and the end of
> pwm_imx27_get_state() and provide the results?
>
> Note I only compile tested this change.
>
> Best regards
> Uwe
>
> drivers/video/backlight/pwm_bl.c | 34 +++-
> 1 file changed, 12 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index 746eebc411df..ddebd62b3978 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -42,10 +42,8 @@ struct pwm_bl_data {
>
> static void pwm_backlight_power_on(struct pwm_bl_data *pb)
> {
> - struct pwm_state state;
> int err;
>
> - pwm_get_state(pb->pwm, );
> if (pb->enabled)
> return;
>
> @@ -53,9 +51,6 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb)
> if (err < 0)
> dev_err(pb->dev, "failed to enable power supply\n");
>
> - state.enabled = true;
> - pwm_apply_state(pb->pwm, );
> -
> if (pb->post_pwm_on_delay)
> msleep(pb->post_pwm_on_delay);
>
> @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb)
>
> static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> {
> - struct pwm_state state;
> -
> - pwm_get_state(pb->pwm, );
> - if (!pb->enabled)
> - return;
> -
> if (pb->enable_gpio)
> gpiod_set_value_cansleep(pb->enable_gpio, 0);
>
> if (pb->pwm_off_delay)
> msleep(pb->pwm_off_delay);
>
> - state.enabled = false;
> - state.duty_cycle = 0;
> - pwm_apply_state(pb->pwm, );
> -
> regulator_disable(pb->power_supply);
> pb->enabled = false;
> }
>
> -static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
> +static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness, struct
> pwm_state *state)
> {
> unsigned int lth = pb->lth_brightness;
> - struct pwm_state state;
> u64 duty_cycle;
>
> - pwm_get_state(pb->pwm, );
> -
> if (pb->levels)
> duty_cycle = pb->levels[brightness];
> else
> duty_cycle = brightness;
>
> - duty_cycle *= state.period - lth;
> + duty_cycle *= state->period - lth;
> do_div(duty_cycle, pb->scale);
>
> return duty_cycle + lth;
> @@ -122,12 +104,20 @@ static int pwm_backlight_update_status(struct
> backlight_device *bl)
>
> if (brightness > 0) {
> pwm_get_state(pb->pwm, );
> - state.duty_cycle = compute_duty_cycle(pb, brightness);
> + state.duty_cycle = compute_duty_cycle(pb, brightness, );
> + state.enabled = true;
> pwm_apply_state(pb->pwm, );
> +
> pwm_backlight_power_on(pb);
> - } else
> + } else {
> pwm_backlight_power_off(pb);
>
> + pwm_get_state(pb->pwm, );
> + state.enabled = false;
> + state.duty_cycle = 0;
> + pwm_apply_state(pb->pwm, );
Both cases where (brightness > 0) and 'else' contain the
pwm_apply_state() call with the same parameters. Can this be moved
outside of the if statements?
> + }
> +
> if (pb->notify_after)
> pb->notify_after(pb->dev, brightness);
>
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/8] drm: rcar-du: Add support for CMM
Hi Jacopo,
On Thu, Oct 17, 2019 at 02:43:49PM +0200, Jacopo Mondi wrote:
> On Wed, Oct 16, 2019 at 04:45:26PM +0300, Laurent Pinchart wrote:
> > On Wed, Oct 16, 2019 at 10:55:43AM +0200, Jacopo Mondi wrote:
> > > Add a driver for the R-Car Display Unit Color Correction Module.
> > >
> > > In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> > > to perform image enhancement and color correction.
> > >
> > > Add support for CMM through a driver that supports configuration of
> > > the 1-dimensional LUT table. More advanced CMM features will be
> > > implemented on top of this initial one.
> > >
> > > Reviewed-by: Laurent Pinchart
> > > Reviewed-by: Kieran Bingham
> > > Signed-off-by: Jacopo Mondi
> > > ---
> > > drivers/gpu/drm/rcar-du/Kconfig| 7 +
> > > drivers/gpu/drm/rcar-du/Makefile | 1 +
> > > drivers/gpu/drm/rcar-du/rcar_cmm.c | 212 +
> > > drivers/gpu/drm/rcar-du/rcar_cmm.h | 58
> > > 4 files changed, 278 insertions(+)
> > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> > > b/drivers/gpu/drm/rcar-du/Kconfig
> > > index 1529849e217e..539d232790d1 100644
> > > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > > @@ -13,6 +13,13 @@ config DRM_RCAR_DU
> > > Choose this option if you have an R-Car chipset.
> > > If M is selected the module will be called rcar-du-drm.
> > >
> > > +config DRM_RCAR_CMM
> > > + bool "R-Car DU Color Management Module (CMM) Support"
> > > + depends on DRM && OF
> > > + depends on DRM_RCAR_DU
> > > + help
> > > + Enable support for R-Car Color Management Module (CMM).
> > > +
> > > config DRM_RCAR_DW_HDMI
> > > tristate "R-Car DU Gen3 HDMI Encoder Support"
> > > depends on DRM && OF
> > > diff --git a/drivers/gpu/drm/rcar-du/Makefile
> > > b/drivers/gpu/drm/rcar-du/Makefile
> > > index 6c2ed9c46467..4d1187ccc3e5 100644
> > > --- a/drivers/gpu/drm/rcar-du/Makefile
> > > +++ b/drivers/gpu/drm/rcar-du/Makefile
> > > @@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o
> > > \
> > > rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
> > > rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
> > >
> > > +obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
> > > obj-$(CONFIG_DRM_RCAR_DU)+= rcar-du-drm.o
> > > obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> > > obj-$(CONFIG_DRM_RCAR_LVDS) += rcar_lvds.o
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > new file mode 100644
> > > index ..4170626208cf
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > @@ -0,0 +1,212 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * rcar_cmm.c -- R-Car Display Unit Color Management Module
> > > + *
> > > + * Copyright (C) 2019 Jacopo Mondi
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +
> > > +#include "rcar_cmm.h"
> > > +
> > > +#define CM2_LUT_CTRL 0x
> > > +#define CM2_LUT_CTRL_LUT_EN BIT(0)
> > > +#define CM2_LUT_TBL_BASE 0x0600
> > > +#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
> > > +
> > > +struct rcar_cmm {
> > > + void __iomem *base;
> > > +
> > > + /*
> > > + * @lut:1D-LUT state
> > > + * @lut.enabled:1D-LUT enabled flag
> > > + */
> > > + struct {
> > > + bool enabled;
> > > + } lut;
> > > +};
> > > +
> > > +static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
> > > +{
> > > + return ioread32(rcmm->base + reg);
> > > +}
> > > +
> > > +static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32
> > > data)
> > > +{
> > > + iowrite32(data, rcmm->base + reg);
> > > +}
> > > +
> > > +/*
> > > + * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware
> > > precision
> > > + * and write to the CMM registers
> > > + * @rcmm: Pointer to the CMM device
> > > + * @drm_lut: Pointer to the DRM LUT table
> > > + */
> > > +static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
> > > +const struct drm_color_lut *drm_lut)
> > > +{
> > > + unsigned int i;
> > > +
> > > + for (i = 0; i < CM2_LUT_SIZE; ++i) {
> > > + u32 entry = drm_color_lut_extract(drm_lut[i].red, 8) << 16
> > > + | drm_color_lut_extract(drm_lut[i].green, 8) << 8
> > > + | drm_color_lut_extract(drm_lut[i].blue, 8);
> > > +
> > > + rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
> > > + }
> > > +}
> > > +
> > > +/*
> > > + * rcar_cmm_setup() - Configure the CMM unit
> > > + * @pdev: The platform device associated with the CMM instance
> > > + * @config: The CMM unit configuration
> > > + *
> > > + * Configure the
Re: [PATCH v6 3/8] drm: rcar-du: Add support for CMM
Hi Laurent,
On Wed, Oct 16, 2019 at 04:45:26PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Wed, Oct 16, 2019 at 10:55:43AM +0200, Jacopo Mondi wrote:
> > Add a driver for the R-Car Display Unit Color Correction Module.
> >
> > In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> > to perform image enhancement and color correction.
> >
> > Add support for CMM through a driver that supports configuration of
> > the 1-dimensional LUT table. More advanced CMM features will be
> > implemented on top of this initial one.
> >
> > Reviewed-by: Laurent Pinchart
> > Reviewed-by: Kieran Bingham
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/gpu/drm/rcar-du/Kconfig| 7 +
> > drivers/gpu/drm/rcar-du/Makefile | 1 +
> > drivers/gpu/drm/rcar-du/rcar_cmm.c | 212 +
> > drivers/gpu/drm/rcar-du/rcar_cmm.h | 58
> > 4 files changed, 278 insertions(+)
> > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
> > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
> >
> > diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> > b/drivers/gpu/drm/rcar-du/Kconfig
> > index 1529849e217e..539d232790d1 100644
> > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > @@ -13,6 +13,13 @@ config DRM_RCAR_DU
> > Choose this option if you have an R-Car chipset.
> > If M is selected the module will be called rcar-du-drm.
> >
> > +config DRM_RCAR_CMM
> > + bool "R-Car DU Color Management Module (CMM) Support"
> > + depends on DRM && OF
> > + depends on DRM_RCAR_DU
> > + help
> > + Enable support for R-Car Color Management Module (CMM).
> > +
> > config DRM_RCAR_DW_HDMI
> > tristate "R-Car DU Gen3 HDMI Encoder Support"
> > depends on DRM && OF
> > diff --git a/drivers/gpu/drm/rcar-du/Makefile
> > b/drivers/gpu/drm/rcar-du/Makefile
> > index 6c2ed9c46467..4d1187ccc3e5 100644
> > --- a/drivers/gpu/drm/rcar-du/Makefile
> > +++ b/drivers/gpu/drm/rcar-du/Makefile
> > @@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o
> > \
> > rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
> > rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
> >
> > +obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
> > obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
> > obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> > obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > new file mode 100644
> > index ..4170626208cf
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > @@ -0,0 +1,212 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * rcar_cmm.c -- R-Car Display Unit Color Management Module
> > + *
> > + * Copyright (C) 2019 Jacopo Mondi
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include "rcar_cmm.h"
> > +
> > +#define CM2_LUT_CTRL 0x
> > +#define CM2_LUT_CTRL_LUT_ENBIT(0)
> > +#define CM2_LUT_TBL_BASE 0x0600
> > +#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
> > +
> > +struct rcar_cmm {
> > + void __iomem *base;
> > +
> > + /*
> > +* @lut:1D-LUT state
> > +* @lut.enabled:1D-LUT enabled flag
> > +*/
> > + struct {
> > + bool enabled;
> > + } lut;
> > +};
> > +
> > +static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
> > +{
> > + return ioread32(rcmm->base + reg);
> > +}
> > +
> > +static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32 data)
> > +{
> > + iowrite32(data, rcmm->base + reg);
> > +}
> > +
> > +/*
> > + * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware
> > precision
> > + * and write to the CMM registers
> > + * @rcmm: Pointer to the CMM device
> > + * @drm_lut: Pointer to the DRM LUT table
> > + */
> > +static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
> > + const struct drm_color_lut *drm_lut)
> > +{
> > + unsigned int i;
> > +
> > + for (i = 0; i < CM2_LUT_SIZE; ++i) {
> > + u32 entry = drm_color_lut_extract(drm_lut[i].red, 8) << 16
> > + | drm_color_lut_extract(drm_lut[i].green, 8) << 8
> > + | drm_color_lut_extract(drm_lut[i].blue, 8);
> > +
> > + rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
> > + }
> > +}
> > +
> > +/*
> > + * rcar_cmm_setup() - Configure the CMM unit
> > + * @pdev: The platform device associated with the CMM instance
> > + * @config: The CMM unit configuration
> > + *
> > + * Configure the CMM unit with the given configuration. Currently enabling,
> > + * disabling and programming of the 1-D LUT unit is supported.
>
> Did you miss the comment in the previous version about explaining when
> rcar_cmm_setup() can be called (basically
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 7:34 AM Adam Ford wrote:
>
> On Thu, Oct 17, 2019 at 7:19 AM Uwe Kleine-König
> wrote:
> >
> > On Thu, Oct 17, 2019 at 12:47:27PM +0100, Daniel Thompson wrote:
> > > On Thu, Oct 17, 2019 at 10:10:59AM +0200, Uwe Kleine-König wrote:
> > > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > > pwm_get_state() return the last implemented state")) changed the
> > > > semantic of pwm_get_state() and disclosed an (as it seems) common
> > > > problem in lowlevel PWM drivers. By not relying on the period and duty
> > > > cycle being retrievable from a disabled PWM this type of problem is
> > > > worked around.
> > > >
> > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > combo once is also more effective.
> > >
> > > I'm only interested in the second paragraph here.
> > >
> > > There seems to be a reasonable consensus that the i.MX27 and cros-ec
> > > PWM drivers should be fixed for the benefit of other PWM clients.
> > > So we make this change because it makes the pwm-bl better... not to
> > > work around bugs ;-).
> >
> > That's fine, still I think it's fair to explain the motivation of
> > creating this patch.
> >
> > > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > > b/drivers/video/backlight/pwm_bl.c
> > > > index 746eebc411df..ddebd62b3978 100644
> > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct
> > > > pwm_bl_data *pb)
> > > >
> > > > static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> > > > {
> > > > - struct pwm_state state;
> > > > -
> > > > - pwm_get_state(pb->pwm, );
> > > > - if (!pb->enabled)
> > > > - return;
> > > > -
> > >
> > > Why remove the pb->enabled check? I thought that was there to ensure we
> > > don't mess up the regular reference counts.
> >
> > I havn't looked yet, but I guess I have to respin. Expect a v2 later
> > today.
>
> I would agree that a high-level fix is better than a series of low
> level driver fixes. For what its worth, your V1 patch worked fine on
> my i.MX6Q. I can test the V2 patch when its ready.
I may have spoken too soon. The patch fixes the display in that it
comes on when it previously did not, but changes to brightness do not
appear to do anything anymore. I don't have an oscilloscope where I
am now, so I cannot verify whether or not the PWM duty cycle changes.
To my eye, the following do not appear to change the brightness of the screen:
echo 7 >
/sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
echo 2 >
/sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
echo 5 >
/sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
adam
>
> adam
> >
> > Best regards
> > Uwe
> >
> > --
> > Pengutronix e.K. | Uwe Kleine-König|
> > Industrial Linux Solutions | http://www.pengutronix.de/ |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205147] Unable to shut down - radeon_drv.c - radeon_suspend_kms()
https://bugzilla.kernel.org/show_bug.cgi?id=205147 --- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) --- Revert queued: https://lists.freedesktop.org/archives/amd-gfx/2019-October/041381.html Should land this week. -- 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] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 7:19 AM Uwe Kleine-König
wrote:
>
> On Thu, Oct 17, 2019 at 12:47:27PM +0100, Daniel Thompson wrote:
> > On Thu, Oct 17, 2019 at 10:10:59AM +0200, Uwe Kleine-König wrote:
> > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > pwm_get_state() return the last implemented state")) changed the
> > > semantic of pwm_get_state() and disclosed an (as it seems) common
> > > problem in lowlevel PWM drivers. By not relying on the period and duty
> > > cycle being retrievable from a disabled PWM this type of problem is
> > > worked around.
> > >
> > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > combo once is also more effective.
> >
> > I'm only interested in the second paragraph here.
> >
> > There seems to be a reasonable consensus that the i.MX27 and cros-ec
> > PWM drivers should be fixed for the benefit of other PWM clients.
> > So we make this change because it makes the pwm-bl better... not to
> > work around bugs ;-).
>
> That's fine, still I think it's fair to explain the motivation of
> creating this patch.
>
> > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > b/drivers/video/backlight/pwm_bl.c
> > > index 746eebc411df..ddebd62b3978 100644
> > > --- a/drivers/video/backlight/pwm_bl.c
> > > +++ b/drivers/video/backlight/pwm_bl.c
> > > @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct pwm_bl_data
> > > *pb)
> > >
> > > static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> > > {
> > > - struct pwm_state state;
> > > -
> > > - pwm_get_state(pb->pwm, );
> > > - if (!pb->enabled)
> > > - return;
> > > -
> >
> > Why remove the pb->enabled check? I thought that was there to ensure we
> > don't mess up the regular reference counts.
>
> I havn't looked yet, but I guess I have to respin. Expect a v2 later
> today.
I would agree that a high-level fix is better than a series of low
level driver fixes. For what its worth, your V1 patch worked fine on
my i.MX6Q. I can test the V2 patch when its ready.
adam
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König|
> Industrial Linux Solutions | http://www.pengutronix.de/ |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/cirrus: Remove obsolete header file
On Thu, Oct 17, 2019 at 01:34:27PM +0200, Thomas Zimmermann wrote: > The cirrus driver's header file is left over from a recent rewrite. > Remove it. Queued up for drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/qxl: Fix randbuild error
On Tue, Oct 08, 2019 at 10:40:54AM +0800, YueHaibing wrote: > If DEM_QXL is y and DRM_TTM_HELPER is m, building fails: > > drivers/gpu/drm/qxl/qxl_object.o: undefined reference to > `drm_gem_ttm_print_info' > > Select DRM_TTM_HELPER to fix this. Queued up for drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 06/11] drm/ttm: factor out ttm_bo_mmap_vma_setup
On Thu, Oct 17, 2019 at 11:06:33AM +, Koenig, Christian wrote: > Am 16.10.19 um 14:18 schrieb Christian König: > > Am 16.10.19 um 13:51 schrieb Gerd Hoffmann: > >> Factor out ttm vma setup to a new function. > >> Reduces code duplication a bit. > >> > >> v2: don't change vm_flags (moved to separate patch). > >> v4: make ttm_bo_mmap_vma_setup static. > >> > >> Signed-off-by: Gerd Hoffmann > > > > Reviewed-by: Christian König for this one > > and #7 in the series. > > Any objections that I add these two to my drm-ttm-next pull request or > did you wanted to merge that through some other tree? Pushed series to drm-misc-next a few minutes ago (before I saw your mail). cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V7 5/6] backlight: qcom-wled: add support for short circuit handling.
On 2019-10-17 16:39, Daniel Thompson wrote:
On Wed, Oct 16, 2019 at 03:43:45PM +0530, Kiran Gunda wrote:
Handle the short circuit interrupt and check if the short circuit
interrupt is valid. Re-enable the module to check if it goes
away. Disable the module altogether if the short circuit event
persists.
Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
Reviewed-by: Daniel Thompson
Thanks for that !
---
drivers/video/backlight/qcom-wled.c | 132
++--
1 file changed, 128 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index 2807b4b..b5b125c 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -2,6 +2,9 @@
/* Copyright (c) 2015, Sony Mobile Communications, AB.
*/
+#include
+#include
+#include
#include
#include
#include
@@ -56,6 +59,16 @@
#define WLED3_SINK_REG_STR_CABC(n) (0x66 + (n * 0x10))
#define WLED3_SINK_REG_STR_CABC_MASK BIT(7)
+/* WLED4 specific control registers */
+#define WLED4_CTRL_REG_SHORT_PROTECT 0x5e
+#define WLED4_CTRL_REG_SHORT_EN_MASK BIT(7)
+
+#define WLED4_CTRL_REG_SEC_ACCESS 0xd0
+#define WLED4_CTRL_REG_SEC_UNLOCK 0xa5
+
+#define WLED4_CTRL_REG_TEST1 0xe2
+#define WLED4_CTRL_REG_TEST1_EXT_FET_DTEST2 0x09
+
/* WLED4 specific sink registers */
#define WLED4_SINK_REG_CURR_SINK 0x46
#define WLED4_SINK_REG_CURR_SINK_MASK GENMASK(7, 4)
@@ -105,17 +118,23 @@ struct wled_config {
bool cs_out_en;
bool ext_gen;
bool cabc;
+ bool external_pfet;
};
struct wled {
const char *name;
struct device *dev;
struct regmap *regmap;
+ struct mutex lock; /* Lock to avoid race from thread irq handler */
+ ktime_t last_short_event;
u16 ctrl_addr;
u16 sink_addr;
u16 max_string_count;
u32 brightness;
u32 max_brightness;
+ u32 short_count;
+ bool disabled_by_short;
+ bool has_short_detect;
struct wled_config cfg;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
@@ -166,6 +185,9 @@ static int wled_module_enable(struct wled *wled,
int val)
{
int rc;
+ if (wled->disabled_by_short)
+ return -ENXIO;
+
rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
@@ -202,18 +224,19 @@ static int wled_update_status(struct
backlight_device *bl)
bl->props.state & BL_CORE_FBBLANK)
brightness = 0;
+ mutex_lock(>lock);
if (brightness) {
rc = wled->wled_set_brightness(wled, brightness);
if (rc < 0) {
dev_err(wled->dev, "wled failed to set brightness
rc:%d\n",
rc);
- return rc;
+ goto unlock_mutex;
}
rc = wled_sync_toggle(wled);
if (rc < 0) {
dev_err(wled->dev, "wled sync failed rc:%d\n", rc);
- return rc;
+ goto unlock_mutex;
}
}
@@ -221,15 +244,61 @@ static int wled_update_status(struct
backlight_device *bl)
rc = wled_module_enable(wled, !!brightness);
if (rc < 0) {
dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
- return rc;
+ goto unlock_mutex;
}
}
wled->brightness = brightness;
+unlock_mutex:
+ mutex_unlock(>lock);
+
return rc;
}
+#define WLED_SHORT_DLY_MS 20
+#define WLED_SHORT_CNT_MAX 5
+#define WLED_SHORT_RESET_CNT_DLY_USUSEC_PER_SEC
+
+static irqreturn_t wled_short_irq_handler(int irq, void *_wled)
+{
+ struct wled *wled = _wled;
+ int rc;
+ s64 elapsed_time;
+
+ wled->short_count++;
+ mutex_lock(>lock);
+ rc = wled_module_enable(wled, false);
+ if (rc < 0) {
+ dev_err(wled->dev, "wled disable failed rc:%d\n", rc);
+ goto unlock_mutex;
+ }
+
+ elapsed_time = ktime_us_delta(ktime_get(),
+ wled->last_short_event);
+ if (elapsed_time > WLED_SHORT_RESET_CNT_DLY_US)
+ wled->short_count = 1;
+
+ if (wled->short_count > WLED_SHORT_CNT_MAX) {
+ dev_err(wled->dev, "Short trigged %d times, disabling WLED
forever!\n",
+ wled->short_count);
+ wled->disabled_by_short = true;
+ goto unlock_mutex;
+ }
+
+ wled->last_short_event =
Re: [PATCH V7 4/6] backlight: qcom-wled: Add support for WLED4 peripheral.
On 2019-10-17 16:36, Daniel Thompson wrote:
On Wed, Oct 16, 2019 at 03:43:44PM +0530, Kiran Gunda wrote:
WLED4 peripheral is present on some PMICs like pmi8998 and
pm660l. It has a different register map and configurations
are also different. Add support for it.
There is code buried in this patch that looks like it changes the name
that will be handed to the backlight sub-system.
It's purpose needs to be explained in the patch description (or the
code
moved to a new patch).
I will address it in next series.
Daniel.
Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
---
drivers/video/backlight/qcom-wled.c | 263
+++-
1 file changed, 257 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index 45eeda4..2807b4b 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -17,7 +17,7 @@
#define WLED3_SINK_REG_BRIGHT_MAX 0xFFF
-/* WLED3 control registers */
+/* WLED3/WLED4 control registers */
#define WLED3_CTRL_REG_MOD_EN 0x46
#define WLED3_CTRL_REG_MOD_EN_MASKBIT(7)
#define WLED3_CTRL_REG_MOD_EN_SHIFT 7
@@ -31,7 +31,7 @@
#define WLED3_CTRL_REG_ILIMIT 0x4e
#define WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0)
-/* WLED3 sink registers */
+/* WLED3/WLED4 sink registers */
#define WLED3_SINK_REG_SYNC0x47
#define WLED3_SINK_REG_SYNC_CLEAR 0x00
@@ -56,6 +56,28 @@
#define WLED3_SINK_REG_STR_CABC(n) (0x66 + (n * 0x10))
#define WLED3_SINK_REG_STR_CABC_MASK BIT(7)
+/* WLED4 specific sink registers */
+#define WLED4_SINK_REG_CURR_SINK 0x46
+#define WLED4_SINK_REG_CURR_SINK_MASK GENMASK(7, 4)
+#define WLED4_SINK_REG_CURR_SINK_SHFT 4
+
+/* WLED4 specific per-'string' registers below */
+#define WLED4_SINK_REG_STR_MOD_EN(n) (0x50 + (n * 0x10))
+#define WLED4_SINK_REG_STR_MOD_MASK BIT(7)
+
+#define WLED4_SINK_REG_STR_FULL_SCALE_CURR(n) (0x52 + (n * 0x10))
+#define WLED4_SINK_REG_STR_FULL_SCALE_CURR_MASK GENMASK(3, 0)
+
+#define WLED4_SINK_REG_STR_MOD_SRC(n) (0x53 + (n * 0x10))
+#define WLED4_SINK_REG_STR_MOD_SRC_MASK BIT(0)
+#define WLED4_SINK_REG_STR_MOD_SRC_INT0x00
+#define WLED4_SINK_REG_STR_MOD_SRC_EXT0x01
+
+#define WLED4_SINK_REG_STR_CABC(n) (0x56 + (n * 0x10))
+#define WLED4_SINK_REG_STR_CABC_MASK BIT(7)
+
+#define WLED4_SINK_REG_BRIGHT(n) (0x57 + (n * 0x10))
+
struct wled_var_cfg {
const u32 *values;
u32 (*fn)(u32);
@@ -90,6 +112,7 @@ struct wled {
struct device *dev;
struct regmap *regmap;
u16 ctrl_addr;
+ u16 sink_addr;
u16 max_string_count;
u32 brightness;
u32 max_brightness;
@@ -116,6 +139,29 @@ static int wled3_set_brightness(struct wled
*wled, u16 brightness)
return 0;
}
+static int wled4_set_brightness(struct wled *wled, u16 brightness)
+{
+ int rc, i;
+ u16 low_limit = wled->max_brightness * 4 / 1000;
+ u8 v[2];
+
+ /* WLED4's lower limit of operation is 0.4% */
+ if (brightness > 0 && brightness < low_limit)
+ brightness = low_limit;
+
+ v[0] = brightness & 0xff;
+ v[1] = (brightness >> 8) & 0xf;
+
+ for (i = 0; i < wled->cfg.num_strings; ++i) {
+ rc = regmap_bulk_write(wled->regmap, wled->sink_addr +
+ WLED4_SINK_REG_BRIGHT(i), v, 2);
+ if (rc < 0)
+ return rc;
+ }
+
+ return 0;
+}
+
static int wled_module_enable(struct wled *wled, int val)
{
int rc;
@@ -267,6 +313,120 @@ static int wled3_setup(struct wled *wled)
.enabled_strings = {0, 1, 2, 3},
};
+static int wled4_setup(struct wled *wled)
+{
+ int rc, temp, i, j;
+ u16 addr;
+ u8 sink_en = 0;
+ u32 sink_cfg = 0;
+
+ rc = regmap_update_bits(wled->regmap,
+ wled->ctrl_addr + WLED3_CTRL_REG_OVP,
+ WLED3_CTRL_REG_OVP_MASK, wled->cfg.ovp);
+ if (rc < 0)
+ return rc;
+
+ rc = regmap_update_bits(wled->regmap,
+ wled->ctrl_addr + WLED3_CTRL_REG_ILIMIT,
+ WLED3_CTRL_REG_ILIMIT_MASK,
+ wled->cfg.boost_i_limit);
+ if (rc < 0)
+ return rc;
+
+ rc = regmap_update_bits(wled->regmap,
+ wled->ctrl_addr + WLED3_CTRL_REG_FREQ,
+ WLED3_CTRL_REG_FREQ_MASK,
+
Re: [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic
On Wed, 16 Oct 2019, Kiran Gunda wrote:
> The auto string detection algorithm checks if the current WLED
> sink configuration is valid. It tries enabling every sink and
> checks if the OVP fault is observed. Based on this information
> it detects and enables the valid sink configuration.
> Auto calibration will be triggered when the OVP fault interrupts
> are seen frequently thereby it tries to fix the sink configuration.
>
> The auto-detection also kicks in when the connected LED string
> of the display-backlight malfunctions (because of damage) and
> requires the damaged string to be turned off to prevent the
> complete panel and/or board from being damaged.
>
> Signed-off-by: Kiran Gunda
> ---
> drivers/video/backlight/qcom-wled.c | 410
> +++-
> 1 file changed, 404 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/backlight/qcom-wled.c
> b/drivers/video/backlight/qcom-wled.c
> index b5b125c..ff7c409 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
[...]
> + /* iterate through the strings one by one */
Please use proper English in comments (less a full stop).
In this case, just s/iterate/Iterate/.
> + for (i = 0; i < wled->cfg.num_strings; i++) {
> + sink_test = BIT((WLED4_SINK_REG_CURR_SINK_SHFT + i));
> +
> + /* Enable feedback control */
> + rc = regmap_write(wled->regmap, wled->ctrl_addr +
> + WLED3_CTRL_REG_FEEDBACK_CONTROL, i + 1);
> + if (rc < 0) {
> + dev_err(wled->dev, "Failed to enable feedback for SINK
> %d rc = %d\n",
> + i + 1, rc);
> + goto failed_detect;
> + }
> +
> + /* enable the sink */
Here too. And everywhere else.
> + rc = regmap_write(wled->regmap, wled->sink_addr +
> + WLED4_SINK_REG_CURR_SINK, sink_test);
> + if (rc < 0) {
> + dev_err(wled->dev, "Failed to configure SINK %d
> rc=%d\n",
> + i + 1, rc);
> + goto failed_detect;
> + }
> +
> + /* Enable the module */
> + rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
> + WLED3_CTRL_REG_MOD_EN,
> + WLED3_CTRL_REG_MOD_EN_MASK,
> + WLED3_CTRL_REG_MOD_EN_MASK);
> + if (rc < 0) {
> + dev_err(wled->dev, "Failed to enable WLED module
> rc=%d\n",
> + rc);
> + goto failed_detect;
> + }
> +
> + usleep_range(WLED_SOFT_START_DLY_US,
> + WLED_SOFT_START_DLY_US + 1000);
> +
> + rc = regmap_read(wled->regmap, wled->ctrl_addr +
> + WLED3_CTRL_REG_INT_RT_STS, _sts);
> + if (rc < 0) {
> + dev_err(wled->dev, "Error in reading
> WLED3_CTRL_INT_RT_STS rc=%d\n",
> + rc);
> + goto failed_detect;
> + }
> +
> + if (int_sts & WLED3_CTRL_REG_OVP_FAULT_STATUS)
> + dev_dbg(wled->dev, "WLED OVP fault detected with SINK
> %d\n",
> + i + 1);
I haven't reviewed the whole patch, but this caught my eye.
I think this should be upgraded to dev_warn().
> + else
> + sink_valid |= sink_test;
> +
> + /* Disable the module */
> + rc = regmap_update_bits(wled->regmap,
> + wled->ctrl_addr + WLED3_CTRL_REG_MOD_EN,
> + WLED3_CTRL_REG_MOD_EN_MASK, 0);
> + if (rc < 0) {
> + dev_err(wled->dev, "Failed to disable WLED module
> rc=%d\n",
> + rc);
> + goto failed_detect;
> + }
> + }
> +
> + if (!sink_valid) {
> + dev_err(wled->dev, "No valid WLED sinks found\n");
> + wled->disabled_by_short = true;
> + goto failed_detect;
> + }
> +
> + if (sink_valid == sink_config) {
> + dev_dbg(wled->dev, "WLED auto-detection complete,
> sink-config=%x OK!\n",
> + sink_config);
Does this really need to be placed in the kernel log?
> + } else {
> + dev_warn(wled->dev, "New WLED string configuration found %x\n",
> + sink_valid);
Why would the user care about this? Is it not normal?
> + sink_config = sink_valid;
> + }
[...]
> +static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
> +{
> + struct wled *wled = _wled;
> + int rc;
> + u32 int_sts, fault_sts;
> +
> + rc = regmap_read(wled->regmap,
> + wled->ctrl_addr +
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 12:47:27PM +0100, Daniel Thompson wrote:
> On Thu, Oct 17, 2019 at 10:10:59AM +0200, Uwe Kleine-König wrote:
> > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > pwm_get_state() return the last implemented state")) changed the
> > semantic of pwm_get_state() and disclosed an (as it seems) common
> > problem in lowlevel PWM drivers. By not relying on the period and duty
> > cycle being retrievable from a disabled PWM this type of problem is
> > worked around.
> >
> > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > combo once is also more effective.
>
> I'm only interested in the second paragraph here.
>
> There seems to be a reasonable consensus that the i.MX27 and cros-ec
> PWM drivers should be fixed for the benefit of other PWM clients.
> So we make this change because it makes the pwm-bl better... not to
> work around bugs ;-).
That's fine, still I think it's fair to explain the motivation of
creating this patch.
> > diff --git a/drivers/video/backlight/pwm_bl.c
> > b/drivers/video/backlight/pwm_bl.c
> > index 746eebc411df..ddebd62b3978 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct pwm_bl_data
> > *pb)
> >
> > static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> > {
> > - struct pwm_state state;
> > -
> > - pwm_get_state(pb->pwm, );
> > - if (!pb->enabled)
> > - return;
> > -
>
> Why remove the pb->enabled check? I thought that was there to ensure we
> don't mess up the regular reference counts.
I havn't looked yet, but I guess I have to respin. Expect a v2 later
today.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
states.
v2: convert to pci_dev quirk
put a proper technical explanation of the issue as a in-code comment
v3: disable it only for certain combinations of intel and nvidia hardware
v4: simplify quirk by setting flag on the GPU itself
Signed-off-by: Karol Herbst
Cc: Bjorn Helgaas
Cc: Lyude Paul
Cc: Rafael J. Wysocki
Cc: Mika Westerberg
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
---
drivers/pci/pci.c| 7 ++
drivers/pci/quirks.c | 53
include/linux/pci.h | 1 +
3 files changed, 61 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b97d9e10c9cc..02e71e0bcdd7 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -850,6 +850,13 @@ static int pci_raw_set_power_state(struct pci_dev *dev,
pci_power_t state)
|| (state == PCI_D2 && !dev->d2_support))
return -EIO;
+ /*
+* check if we have a bad combination of bridge controller and nvidia
+ * GPU, see quirk_broken_nv_runpm for more info
+*/
+ if (state != PCI_D0 && dev->broken_nv_runpm)
+ return 0;
+
pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, );
/*
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 44c4ae1abd00..0006c9e37b6f 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5268,3 +5268,56 @@ static void quirk_reset_lenovo_thinkpad_p50_nvgpu(struct
pci_dev *pdev)
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, 0x13b1,
PCI_CLASS_DISPLAY_VGA, 8,
quirk_reset_lenovo_thinkpad_p50_nvgpu);
+
+/*
+ * Some Intel PCIe bridges cause devices to disappear from the PCIe bus after
+ * those were put into D3cold state if they were put into a non D0 PCI PM
+ * device state before doing so.
+ *
+ * This leads to various issue different issues which all manifest differently,
+ * but have the same root cause:
+ * - AIML code execution hits an infinite loop (as the coe waits on device
+ *memory to change).
+ * - kernel crashes, as all pci reads return -1, which most code isn't able
+ *to handle well enough.
+ * - sudden shutdowns, as the kernel identified an unrecoverable error after
+ *userspace tries to access the GPU.
+ *
+ * In all cases dmesg will contain at least one line like this:
+ * 'nouveau :01:00.0: Refused to change power state, currently in D3'
+ * followed by a lot of nouveau timeouts.
+ *
+ * ACPI code writes bit 0x80 to the not documented PCI register 0x248 of the
+ * PCIe bridge controller in order to power down the GPU.
+ * Nonetheless, there are other code paths inside the ACPI firmware which use
+ * other registers, which seem to work fine:
+ * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
+ * - 0xb0 bit 0x10 (link disable)
+ * Changing the conditions inside the firmware by poking into the relevant
+ * addresses does resolve the issue, but it seemed to be ACPI private memory
+ * and not any device accessible memory at all, so there is no portable way of
+ * changing the conditions.
+ *
+ * The only systems where this behavior can be seen are hybrid graphics laptops
+ * with a secondary Nvidia Pascal GPU. It cannot be ruled out that this issue
+ * only occurs in combination with listed Intel PCIe bridge controllers and
+ * the mentioned GPUs or if it's only a hw bug in the bridge controller.
+ *
+ * But because this issue was NOT seen on laptops with an Nvidia Pascal GPU
+ * and an Intel Coffee Lake SoC, there is a higher chance of there being a bug
+ * in the bridge controller rather than in the GPU.
+ *
+ * This issue was not able to be reproduced on non laptop systems.
+ */
+
+static void quirk_broken_nv_runpm(struct pci_dev *dev)
+{
+ struct pci_dev *bridge = pci_upstream_bridge(dev);
+
+ if (bridge->vendor == PCI_VENDOR_ID_INTEL &&
+ bridge->device == 0x1901)
+ dev->broken_nv_runpm = 1;
+}
+DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
+ PCI_BASE_CLASS_DISPLAY, 16,
+ quirk_broken_nv_runpm);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index ac8a6c4e1792..903a0b3a39ec 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -416,6 +416,7 @@ struct pci_dev {
unsigned int__aer_firmware_first_valid:1;
unsigned int__aer_firmware_first:1;
unsigned intbroken_intx_masking:1; /* INTx masking can't be used */
+ unsigned intbroken_nv_runpm:1; /* some combinations of intel
bridge controller and nvidia GPUs break rtd3 */
unsigned intio_window_1k:1; /* Intel bridge 1K I/O windows
*/
unsigned intirq_managed:1;
unsigned inthas_secondary_link:1;
--
2.21.0
Re: [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic
On 2019-10-17 16:59, Daniel Thompson wrote:
On Wed, Oct 16, 2019 at 03:43:46PM +0530, Kiran Gunda wrote:
The auto string detection algorithm checks if the current WLED
sink configuration is valid. It tries enabling every sink and
checks if the OVP fault is observed. Based on this information
it detects and enables the valid sink configuration.
Auto calibration will be triggered when the OVP fault interrupts
are seen frequently thereby it tries to fix the sink configuration.
The auto-detection also kicks in when the connected LED string
of the display-backlight malfunctions (because of damage) and
requires the damaged string to be turned off to prevent the
complete panel and/or board from being damaged.
Signed-off-by: Kiran Gunda
It's a complex bit of code but I'm OK with it in principle. Everything
below is about small details and/or nitpicking.
+static void wled_ovp_work(struct work_struct *work)
+{
+ struct wled *wled = container_of(work,
+struct wled, ovp_work.work);
+ enable_irq(wled->ovp_irq);
+}
+
A bit of commenting about why we have to wait 10ms before enabling the
OVP interrupt would be appreciated.
Sure. Will add the comment in the next series.
+static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
+{
+ struct wled *wled = _wled;
+ int rc;
+ u32 int_sts, fault_sts;
+
+ rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, _sts);
+ if (rc < 0) {
+ dev_err(wled->dev, "Error in reading WLED3_INT_RT_STS rc=%d\n",
+ rc);
+ return IRQ_HANDLED;
+ }
+
+ rc = regmap_read(wled->regmap, wled->ctrl_addr +
+WLED3_CTRL_REG_FAULT_STATUS, _sts);
+ if (rc < 0) {
+ dev_err(wled->dev, "Error in reading WLED_FAULT_STATUS rc=%d\n",
+ rc);
+ return IRQ_HANDLED;
+ }
+
+ if (fault_sts &
+ (WLED3_CTRL_REG_OVP_FAULT_BIT | WLED3_CTRL_REG_ILIM_FAULT_BIT))
+ dev_dbg(wled->dev, "WLED OVP fault detected, int_sts=%x fault_sts=
%x\n",
+ int_sts, fault_sts);
+
+ if (fault_sts & WLED3_CTRL_REG_OVP_FAULT_BIT) {
+ mutex_lock(>lock);
+ disable_irq_nosync(wled->ovp_irq);
We're currently running the threaded ISR for this irq. Do we really
need
to disable it?
We need to disable this IRQ, during the auto string detection logic.
Because
in the auto string detection we configure the current sinks one by one
and check the
status register for the OVPs and set the right string configuration. We
enable it later after
the auto string detection is completed.
+
+ if (wled_auto_detection_required(wled))
+ wled_auto_string_detection(wled);
+
+ enable_irq(wled->ovp_irq);
+
+ mutex_unlock(>lock);
+ }
+
+ return IRQ_HANDLED;
+}
+
Snip.
+static int wled_remove(struct platform_device *pdev)
+{
+ struct wled *wled = dev_get_drvdata(>dev);
+
+ cancel_delayed_work_sync(>ovp_work);
+ mutex_destroy(>lock);
Have the irq handlers been disabled at this point?
Ok.. may not be. I will disable the irq's here in next series.
Also, if you want to destroy the mutex shouldn't that code be
introduced in the same patch that introduces the mutex?
Ok.. I will move it to the same patch where the mutex introduced in next
series.
+
+ return 0;
+}
Daniel.
[Bug 107296] WARNING: CPU: 0 PID: 370 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1355 dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=107296
Janpieter Sollie changed:
What|Removed |Added
Attachment #144689|0 |1
is obsolete||
--- Comment #21 from Janpieter Sollie ---
Created attachment 145764
--> https://bugs.freedesktop.org/attachment.cgi?id=145764=edit
dmesg of PPLIB error
still present on linux 5.3, with the following exceptions:
- the values in mV seem to be initialized,
- DRM does not complain about 'Cannot find any crtc or sizes' after GPU adding
- DRM: construct error is gone
So it's going the good way, I guess ...
I investigated the source around dcn_bw_update_from_pplib
And I saw the following code in gpu/drm/amd/display/dc/calcs/dcn_calcs.c
bool res;
/* TODO: This is not the proper way to obtain
fabric_and_dram_bandwidth, should be min(fclk, memclk) */
res = dm_pp_get_clock_levels_by_type_with_voltage(
ctx, DM_PP_CLOCK_TYPE_FCLK, );
kernel_fpu_begin();
if (res)
res = verify_clock_values();
if (res) {
//unimportant, left out
} else
BREAK_TO_DEBUGGER();
=
which probably explains what happens: fclks gets a number of clock values from
dm_pp_get_clock_levels_by_type_with_voltage, setting res to true.
It tries to validate the clock values then, which fails because of the invalid
numbers
After that, it breaks to debugger.
Is it possible the vega11 needs more time to initialize its clock limits?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On Thu, Oct 17, 2019 at 01:11:31PM +0200, Thierry Reding wrote:
> On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> > On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > > On 17. 10. 19 10:10, Uwe Kleine-König wrote:
> > > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > > pwm_get_state() return the last implemented state")) changed the
> > > > semantic of pwm_get_state() and disclosed an (as it seems) common
> > > > problem in lowlevel PWM drivers. By not relying on the period and duty
> > > > cycle being retrievable from a disabled PWM this type of problem is
> > > > worked around.
> > > >
> > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > combo once is also more effective.
> > > >
> > > > Signed-off-by: Uwe Kleine-König
> > > > ---
> > > > Hello,
> > > >
> > > > There are now two reports about 01ccf903edd6 breaking a backlight. As
> > > > far as I understand the problem this is a combination of the backend pwm
> > > > driver yielding surprising results and the pwm-bl driver doing things
> > > > more complicated than necessary.
> > > >
> > > > So I guess this patch works around these problems. Still it would be
> > > > interesting to find out the details in the imx driver that triggers the
> > > > problem. So Adam, can you please instrument the pwm-imx27 driver to
> > > > print *state at the beginning of pwm_imx27_apply() and the end of
> > > > pwm_imx27_get_state() and provide the results?
> > > >
> > > > Note I only compile tested this change.
> > >
> > > Hi Uwe,
> > > I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
> > > thread that I have a similar problem when you submitted this patch.
> > >
> > > So here are my few cents:
> > >
> > > My setup is as follows:
> > > - imx6dl-yapp4-draco with i.MX6Solo
> > > - backlight is controlled with inverted PWM signal
> > > - max brightness level = 32, default brightness level set to 32 in DT.
> > >
> > > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
> > >pwm_get_state() return the last implemented state):
> > >
> > > - System boots to userspace and backlight is enabled all the time from
> > >power up.
> > >
> > >$ dmesg | grep state
> > >[1.763381] get state end: -1811360608, enabled: 0
> >
> > What is -1811360608? When I wrote "print *state" above, I thought about
> > something like:
> >
> > pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
> > __func__, state->period, state->duty_cycle, state->polarity,
> > state->enabled);
> >
> > A quick look into drivers/pwm/pwm-imx27.c shows that this is another
> > driver that yields duty_cycle = 0 when the hardware is off.
>
> It seems to me like the best recourse to fix this for now would be to
> patch up the drivers that return 0 when the hardware is off by caching
> the currently configured duty cycle.
>
> How about the patch below?
>
> Thierry
>
> --- >8 ---
> From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00 2001
> From: Thierry Reding
> Date: Thu, 17 Oct 2019 12:56:00 +0200
> Subject: [PATCH] pwm: imx27: Cache duty cycle register value
>
> The hardware register containing the duty cycle value cannot be accessed
> when the PWM is disabled. This causes the ->get_state() callback to read
> back a duty cycle value of 0, which can confuse consumer drivers.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/pwm/pwm-imx27.c | 31 ---
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> index ae11d8577f18..4113d5cd4c62 100644
> --- a/drivers/pwm/pwm-imx27.c
> +++ b/drivers/pwm/pwm-imx27.c
> @@ -85,6 +85,13 @@ struct pwm_imx27_chip {
> struct clk *clk_per;
> void __iomem*mmio_base;
> struct pwm_chip chip;
> +
> + /*
> + * The driver cannot read the current duty cycle from the hardware if
> + * the hardware is disabled. Cache the last programmed duty cycle
> + * value to return in that case.
> + */
> + unsigned int duty_cycle;
> };
>
> #define to_pwm_imx27_chip(chip) container_of(chip, struct
> pwm_imx27_chip, chip)
> @@ -155,14 +162,17 @@ static void pwm_imx27_get_state(struct pwm_chip *chip,
> tmp = NSEC_PER_SEC * (u64)(period + 2);
> state->period = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
>
> - /* PWMSAR can be read only if PWM is enabled */
> - if (state->enabled) {
> + /*
> + * PWMSAR can be read only if PWM is enabled. If the PWM is disabled,
> + * use the cached value.
> + */
> + if (state->enabled)
> val = readl(imx->mmio_base + MX3_PWMSAR);
> - tmp = NSEC_PER_SEC * (u64)(val);
> - state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
> - } else {
> - state->duty_cycle = 0;
> - }
> + else
> + val =
