[PATCH v4 5/5] selftests/dma-buf/udmabuf: Add tests to verify data after page migration
Since the memfd pages associated with a udmabuf may be migrated
as part of udmabuf create, we need to verify the data coherency
after successful migration. The new tests added in this patch try
to do just that using 4k sized pages and also 2 MB sized huge
pages for the memfd.
Successful completion of the tests would mean that there is no
disconnect between the memfd pages and the ones associated with
a udmabuf. And, these tests can also be augmented in the future
to test newer udmabuf features (such as handling memfd hole punch).
Cc: Shuah Khan
Cc: David Hildenbrand
Cc: Daniel Vetter
Cc: Mike Kravetz
Cc: Hugh Dickins
Cc: Peter Xu
Cc: Jason Gunthorpe
Cc: Gerd Hoffmann
Cc: Dongwon Kim
Cc: Junxiao Chang
Based-on-patch-by: Mike Kravetz
Signed-off-by: Vivek Kasireddy
---
.../selftests/drivers/dma-buf/udmabuf.c | 151 +-
1 file changed, 147 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/drivers/dma-buf/udmabuf.c
b/tools/testing/selftests/drivers/dma-buf/udmabuf.c
index c812080e304e..d76c813fe652 100644
--- a/tools/testing/selftests/drivers/dma-buf/udmabuf.c
+++ b/tools/testing/selftests/drivers/dma-buf/udmabuf.c
@@ -9,26 +9,132 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#define TEST_PREFIX"drivers/dma-buf/udmabuf"
#define NUM_PAGES 4
+#define NUM_ENTRIES 4
+#define MEMFD_SIZE 1024 /* in pages */
-static int memfd_create(const char *name, unsigned int flags)
+static unsigned int page_size;
+
+static int create_memfd_with_seals(off64_t size, bool hpage)
+{
+ int memfd, ret;
+ unsigned int flags = MFD_ALLOW_SEALING;
+
+ if (hpage)
+ flags |= MFD_HUGETLB;
+
+ memfd = memfd_create("udmabuf-test", flags);
+ if (memfd < 0) {
+ printf("%s: [skip,no-memfd]\n", TEST_PREFIX);
+ exit(77);
+ }
+
+ ret = fcntl(memfd, F_ADD_SEALS, F_SEAL_SHRINK);
+ if (ret < 0) {
+ printf("%s: [skip,fcntl-add-seals]\n", TEST_PREFIX);
+ exit(77);
+ }
+
+ ret = ftruncate(memfd, size);
+ if (ret == -1) {
+ printf("%s: [FAIL,memfd-truncate]\n", TEST_PREFIX);
+ exit(1);
+ }
+
+ return memfd;
+}
+
+static int create_udmabuf_list(int devfd, int memfd, off64_t memfd_size)
+{
+ struct udmabuf_create_list *list;
+ int ubuf_fd, i;
+
+ list = malloc(sizeof(struct udmabuf_create_list) +
+ sizeof(struct udmabuf_create_item) * NUM_ENTRIES);
+ if (!list) {
+ printf("%s: [FAIL, udmabuf-malloc]\n", TEST_PREFIX);
+ exit(1);
+ }
+
+ for (i = 0; i < NUM_ENTRIES; i++) {
+ list->list[i].memfd = memfd;
+ list->list[i].offset = i * (memfd_size / NUM_ENTRIES);
+ list->list[i].size = getpagesize() * NUM_PAGES;
+ }
+
+ list->count = NUM_ENTRIES;
+ list->flags = UDMABUF_FLAGS_CLOEXEC;
+ ubuf_fd = ioctl(devfd, UDMABUF_CREATE_LIST, list);
+ free(list);
+ if (ubuf_fd < 0) {
+ printf("%s: [FAIL, udmabuf-create]\n", TEST_PREFIX);
+ exit(1);
+ }
+
+ return ubuf_fd;
+}
+
+static void write_to_memfd(void *addr, off64_t size, char chr)
+{
+ int i;
+
+ for (i = 0; i < size / page_size; i++) {
+ *((char *)addr + (i * page_size)) = chr;
+ }
+}
+
+static void *mmap_fd(int fd, off64_t size)
{
- return syscall(__NR_memfd_create, name, flags);
+ void *addr;
+
+ addr = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+ if (addr == MAP_FAILED) {
+ printf("%s: ubuf_fd mmap fail\n", TEST_PREFIX);
+ exit(1);
+ }
+
+ return addr;
+}
+
+static int compare_chunks(void *addr1, void *addr2, off64_t memfd_size)
+{
+ off64_t off;
+ int i = 0, j, k = 0, ret = 0;
+ char char1, char2;
+
+ while (i < NUM_ENTRIES) {
+ off = i * (memfd_size / NUM_ENTRIES);
+ for (j = 0; j < NUM_PAGES; j++, k++) {
+ char1 = *((char *)addr1 + off + (j * getpagesize()));
+ char2 = *((char *)addr2 + (k * getpagesize()));
+ if (char1 != char2) {
+ ret = -1;
+ goto err;
+ }
+ }
+ i++;
+ }
+err:
+ munmap(addr1, memfd_size);
+ munmap(addr2, NUM_ENTRIES * NUM_PAGES * getpagesize());
+ return ret;
}
int main(int argc, char *argv[])
{
struct udmabuf_create create;
int devfd, memfd, buf, ret;
- off_t size;
- void *mem;
+ off64_t size;
+ void *addr1, *addr2;
devfd = open("/dev/udmabuf", O_RDWR);
if (devfd < 0) {
@@ -90,6 +196,9 @@ int main(int argc, char *argv[])
}
/* should work */
+
[PATCH v4 3/5] mm/gup: Introduce pin_user_pages_fd() for pinning shmem/hugetlbfs file pages (v4)
For drivers that would like to longterm-pin the pages associated
with a file, the pin_user_pages_fd() API provides an option to
not only pin the pages via FOLL_PIN but also to check and migrate
them if they reside in movable zone or CMA block. This API
currently works with files that belong to either shmem or hugetlbfs.
Files belonging to other filesystems are rejected for now.
The pages need to be located first before pinning them via FOLL_PIN.
If they are found in the page cache, they can be immediately pinned.
Otherwise, they need to be allocated using the filesystem specific
APIs and then pinned.
v2:
- Drop gup_flags and improve comments and commit message (David)
- Allocate a page if we cannot find in page cache for the hugetlbfs
case as well (David)
- Don't unpin pages if there is a migration related failure (David)
- Drop the unnecessary nr_pages <= 0 check (Jason)
- Have the caller of the API pass in file * instead of fd (Jason)
v3: (David)
- Enclose the huge page allocation code with #ifdef CONFIG_HUGETLB_PAGE
(Build error reported by kernel test robot )
- Don't forget memalloc_pin_restore() on non-migration related errors
- Improve the readability of the cleanup code associated with
non-migration related errors
- Augment the comments by describing FOLL_LONGTERM like behavior
- Include the R-b tag from Jason
v4:
- Remove the local variable "page" and instead use 3 return statements
in alloc_file_page() (David)
- Add the R-b tag from David
Cc: David Hildenbrand
Cc: Daniel Vetter
Cc: Mike Kravetz
Cc: Hugh Dickins
Cc: Peter Xu
Cc: Gerd Hoffmann
Cc: Dongwon Kim
Cc: Junxiao Chang
Suggested-by: Jason Gunthorpe
Reviewed-by: Jason Gunthorpe (v2)
Reviewed-by: David Hildenbrand (v3)
Signed-off-by: Vivek Kasireddy
---
include/linux/mm.h | 2 +
mm/gup.c | 108 +
2 files changed, 110 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 418d26608ece..1b675fa35059 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2472,6 +2472,8 @@ long get_user_pages_unlocked(unsigned long start,
unsigned long nr_pages,
struct page **pages, unsigned int gup_flags);
long pin_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
struct page **pages, unsigned int gup_flags);
+long pin_user_pages_fd(struct file *file, pgoff_t start,
+ unsigned long nr_pages, struct page **pages);
int get_user_pages_fast(unsigned long start, int nr_pages,
unsigned int gup_flags, struct page **pages);
diff --git a/mm/gup.c b/mm/gup.c
index 231711efa390..875c51d13ee5 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -3410,3 +3410,111 @@ long pin_user_pages_unlocked(unsigned long start,
unsigned long nr_pages,
&locked, gup_flags);
}
EXPORT_SYMBOL(pin_user_pages_unlocked);
+
+static struct page *alloc_file_page(struct file *file, pgoff_t idx)
+{
+#ifdef CONFIG_HUGETLB_PAGE
+ struct folio *folio;
+ int err;
+
+ if (is_file_hugepages(file)) {
+ folio = alloc_hugetlb_folio_nodemask(hstate_file(file),
+NUMA_NO_NODE,
+NULL,
+GFP_USER);
+ if (folio && folio_try_get(folio)) {
+ err = hugetlb_add_to_page_cache(folio,
+ file->f_mapping,
+ idx);
+ if (err) {
+ folio_put(folio);
+ free_huge_folio(folio);
+ return ERR_PTR(err);
+ }
+ return &folio->page;
+ }
+ return ERR_PTR(-ENOMEM);
+ }
+#endif
+ return shmem_read_mapping_page(file->f_mapping, idx);
+}
+
+/**
+ * pin_user_pages_fd() - pin user pages associated with a file
+ * @file: the file whose pages are to be pinned
+ * @start: starting file offset
+ * @nr_pages: number of pages from start to pin
+ * @pages: array that receives pointers to the pages pinned.
+ * Should be at-least nr_pages long.
+ *
+ * Attempt to pin pages associated with a file that belongs to either shmem
+ * or hugetlb. The pages are either found in the page cache or allocated if
+ * necessary. Once the pages are located, they are all pinned via FOLL_PIN.
+ * And, these pinned pages need to be released either using unpin_user_pages()
+ * or unpin_user_page().
+ *
+ * It must be noted that the pages may be pinned for an indefinite amount
+ * of time. And, in most cases, the duration of time they may stay pinned
+ * would be controlled by the userspace. This behavior is effectively the
+ * same as using FOLL_LONGTERM with other GUP APIs.
+ *
+ * Returns
[PATCH v4 4/5] udmabuf: Pin the pages using pin_user_pages_fd() API (v3)
Using pin_user_pages_fd() will ensure that the pages are pinned
correctly using FOLL_PIN. And, this also ensures that we don't
accidentally break features such as memory hotunplug as it would
not allow pinning pages in the movable zone.
Using this new API also simplifies the code as we no longer have
to deal with extracting individual pages from their mappings. As
a result, we can drop some of the local variables such as page,
hpage, mapping, etc.
v2:
- Adjust to the change in signature of pin_user_pages_fd() by
passing in file * instead of fd.
v3:
- Limit the changes in this patch only to those that are required
for using pin_user_pages_fd()
- Slightly improve the commit message
Cc: David Hildenbrand
Cc: Daniel Vetter
Cc: Mike Kravetz
Cc: Hugh Dickins
Cc: Peter Xu
Cc: Jason Gunthorpe
Cc: Gerd Hoffmann
Cc: Dongwon Kim
Cc: Junxiao Chang
Signed-off-by: Vivek Kasireddy
---
drivers/dma-buf/udmabuf.c | 59 +++
1 file changed, 22 insertions(+), 37 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 1a41c4a069ea..883bd97e4076 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -156,7 +156,8 @@ static void release_udmabuf(struct dma_buf *buf)
put_sg_table(dev, ubuf->sg, DMA_BIDIRECTIONAL);
for (pg = 0; pg < ubuf->pagecount; pg++)
- put_page(ubuf->pages[pg]);
+ unpin_user_page(ubuf->pages[pg]);
+
kfree(ubuf->subpgoff);
kfree(ubuf->pages);
kfree(ubuf);
@@ -217,14 +218,13 @@ static long udmabuf_create(struct miscdevice *device,
{
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
struct file *memfd = NULL;
- struct address_space *mapping = NULL;
struct udmabuf *ubuf;
struct dma_buf *buf;
- pgoff_t pgoff, pgcnt, pgidx, pgbuf = 0, pglimit;
- struct page *page, *hpage = NULL;
+ pgoff_t pgcnt, pgbuf = 0, pglimit, nr_pages;
pgoff_t mapidx, chunkoff, maxchunks;
struct hstate *hpstate;
- int seals, ret = -EINVAL;
+ long ret = -EINVAL;
+ int seals;
u32 i, flags;
ubuf = kzalloc(sizeof(*ubuf), GFP_KERNEL);
@@ -258,8 +258,7 @@ static long udmabuf_create(struct miscdevice *device,
memfd = fget(list[i].memfd);
if (!memfd)
goto err;
- mapping = memfd->f_mapping;
- if (!shmem_mapping(mapping) && !is_file_hugepages(memfd))
+ if (!shmem_file(memfd) && !is_file_hugepages(memfd))
goto err;
seals = memfd_fcntl(memfd, F_GET_SEALS, 0);
if (seals == -EINVAL)
@@ -268,7 +267,7 @@ static long udmabuf_create(struct miscdevice *device,
if ((seals & SEALS_WANTED) != SEALS_WANTED ||
(seals & SEALS_DENIED) != 0)
goto err;
- pgoff = list[i].offset >> PAGE_SHIFT;
+ mapidx = list[i].offset >> PAGE_SHIFT;
pgcnt = list[i].size >> PAGE_SHIFT;
if (is_file_hugepages(memfd)) {
if (!ubuf->subpgoff) {
@@ -286,41 +285,26 @@ static long udmabuf_create(struct miscdevice *device,
~huge_page_mask(hpstate)) >> PAGE_SHIFT;
maxchunks = huge_page_size(hpstate) >> PAGE_SHIFT;
}
- for (pgidx = 0; pgidx < pgcnt; pgidx++) {
+
+ do {
+ nr_pages = shmem_file(memfd) ? pgcnt : 1;
+ ret = pin_user_pages_fd(memfd, mapidx, nr_pages,
+ ubuf->pages + pgbuf);
+ if (ret < 0)
+ goto err;
+
if (is_file_hugepages(memfd)) {
- if (!hpage) {
- hpage = find_get_page_flags(mapping,
mapidx,
-
FGP_ACCESSED);
- if (!hpage) {
- ret = -EINVAL;
- goto err;
- }
- }
- get_page(hpage);
- ubuf->pages[pgbuf] = hpage;
- ubuf->subpgoff[pgbuf++] = chunkoff <<
PAGE_SHIFT;
+ ubuf->subpgoff[pgbuf] = chunkoff << PAGE_SHIFT;
if (++chunkoff == maxchunks) {
- put_page(hpage);
- hpage = NULL;
chunkoff = 0;
mapidx++;
}
- } else {
- mapidx = pgoff + pgidx;
-
[PATCH v4 1/5] udmabuf: Use vmf_insert_pfn and VM_PFNMAP for handling mmap
Add VM_PFNMAP to vm_flags in the mmap handler to ensure that
the mappings would be managed without using struct page.
And, in the vm_fault handler, use vmf_insert_pfn to share the
page's pfn to userspace instead of directly sharing the page
(via struct page *).
Cc: David Hildenbrand
Cc: Daniel Vetter
Cc: Mike Kravetz
Cc: Hugh Dickins
Cc: Peter Xu
Cc: Jason Gunthorpe
Cc: Gerd Hoffmann
Cc: Dongwon Kim
Cc: Junxiao Chang
Suggested-by: David Hildenbrand
Acked-by: David Hildenbrand
Signed-off-by: Vivek Kasireddy
---
drivers/dma-buf/udmabuf.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index c40645999648..820c993c8659 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -35,12 +35,13 @@ static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf)
struct vm_area_struct *vma = vmf->vma;
struct udmabuf *ubuf = vma->vm_private_data;
pgoff_t pgoff = vmf->pgoff;
+ unsigned long pfn;
if (pgoff >= ubuf->pagecount)
return VM_FAULT_SIGBUS;
- vmf->page = ubuf->pages[pgoff];
- get_page(vmf->page);
- return 0;
+
+ pfn = page_to_pfn(ubuf->pages[pgoff]);
+ return vmf_insert_pfn(vma, vmf->address, pfn);
}
static const struct vm_operations_struct udmabuf_vm_ops = {
@@ -56,6 +57,7 @@ static int mmap_udmabuf(struct dma_buf *buf, struct
vm_area_struct *vma)
vma->vm_ops = &udmabuf_vm_ops;
vma->vm_private_data = ubuf;
+ vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
return 0;
}
--
2.39.2
[PATCH v4 0/5] mm/gup: Introduce pin_user_pages_fd() for pinning shmem/hugetlbfs file pages (v4)
The first two patches were previously reviewed but not yet merged. These ones need to be merged first as the fourth patch depends on the changes introduced in them and they also fix bugs seen in very specific scenarios (running Qemu with hugetlb=on, blob=true and rebooting guest VM). The third patch introduces pin_user_pages_fd() API and the fourth patch shows how the udmabuf driver can make use of it to longterm-pin the the pages. The last patch adds two new udmabuf selftests to verify data coherency after potential page migration. v2: - Updated the first patch to include review feedback from David and Jason. The main change in this series is the allocation of page in the case of hugetlbfs if it is not found in the page cache. v3: - Made changes to include review feedback from David to improve the comments and readability of code - Enclosed the hugepage alloc code with #ifdef CONFIG_HUGETLB_PAGE v4: - Augmented the commit message of the udmabuf patch that uses pin_user_pages_fd() - Added previously reviewed but unmerged udmabuf patches to this series Cc: David Hildenbrand Cc: Daniel Vetter Cc: Mike Kravetz Cc: Hugh Dickins Cc: Peter Xu Cc: Jason Gunthorpe Cc: Gerd Hoffmann Cc: Dongwon Kim Cc: Junxiao Chang Vivek Kasireddy (5): udmabuf: Use vmf_insert_pfn and VM_PFNMAP for handling mmap udmabuf: Add back support for mapping hugetlb pages (v3) mm/gup: Introduce pin_user_pages_fd() for pinning shmem/hugetlbfs file pages (v4) udmabuf: Pin the pages using pin_user_pages_fd() API (v3) selftests/dma-buf/udmabuf: Add tests to verify data after page migration drivers/dma-buf/udmabuf.c | 96 --- include/linux/mm.h| 2 + mm/gup.c | 108 + .../selftests/drivers/dma-buf/udmabuf.c | 151 +- 4 files changed, 328 insertions(+), 29 deletions(-) -- 2.39.2
[PATCH v4 2/5] udmabuf: Add back support for mapping hugetlb pages (v3)
A user or admin can configure a VMM (Qemu) Guest's memory to be
backed by hugetlb pages for various reasons. However, a Guest OS
would still allocate (and pin) buffers that are backed by regular
4k sized pages. In order to map these buffers and create dma-bufs
for them on the Host, we first need to find the hugetlb pages where
the buffer allocations are located and then determine the offsets
of individual chunks (within those pages) and use this information
to eventually populate a scatterlist.
Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500 options
were passed to the Host kernel and Qemu was launched with these
relevant options: qemu-system-x86_64 -m 4096m
-device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
-display gtk,gl=on
-object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
-machine memory-backend=mem1
Replacing -display gtk,gl=on with -display gtk,gl=off above would
exercise the mmap handler.
v2: Updated get_sg_table() to manually populate the scatterlist for
both huge page and non-huge-page cases.
v3: s/offsets/subpgoff/g
s/hpoff/mapidx/g
Cc: David Hildenbrand
Cc: Daniel Vetter
Cc: Mike Kravetz
Cc: Hugh Dickins
Cc: Peter Xu
Cc: Jason Gunthorpe
Cc: Gerd Hoffmann
Cc: Dongwon Kim
Cc: Junxiao Chang
Acked-by: Mike Kravetz (v2)
Signed-off-by: Vivek Kasireddy
---
drivers/dma-buf/udmabuf.c | 85 +--
1 file changed, 72 insertions(+), 13 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 820c993c8659..1a41c4a069ea 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -28,6 +29,7 @@ struct udmabuf {
struct page **pages;
struct sg_table *sg;
struct miscdevice *device;
+ pgoff_t *subpgoff;
};
static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf)
@@ -41,6 +43,10 @@ static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf)
return VM_FAULT_SIGBUS;
pfn = page_to_pfn(ubuf->pages[pgoff]);
+ if (ubuf->subpgoff) {
+ pfn += ubuf->subpgoff[pgoff] >> PAGE_SHIFT;
+ }
+
return vmf_insert_pfn(vma, vmf->address, pfn);
}
@@ -90,23 +96,31 @@ static struct sg_table *get_sg_table(struct device *dev,
struct dma_buf *buf,
{
struct udmabuf *ubuf = buf->priv;
struct sg_table *sg;
+ struct scatterlist *sgl;
+ pgoff_t offset;
+ unsigned long i = 0;
int ret;
sg = kzalloc(sizeof(*sg), GFP_KERNEL);
if (!sg)
return ERR_PTR(-ENOMEM);
- ret = sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
- 0, ubuf->pagecount << PAGE_SHIFT,
- GFP_KERNEL);
+
+ ret = sg_alloc_table(sg, ubuf->pagecount, GFP_KERNEL);
if (ret < 0)
- goto err;
+ goto err_alloc;
+
+ for_each_sg(sg->sgl, sgl, ubuf->pagecount, i) {
+ offset = ubuf->subpgoff ? ubuf->subpgoff[i] : 0;
+ sg_set_page(sgl, ubuf->pages[i], PAGE_SIZE, offset);
+ }
ret = dma_map_sgtable(dev, sg, direction, 0);
if (ret < 0)
- goto err;
+ goto err_map;
return sg;
-err:
+err_map:
sg_free_table(sg);
+err_alloc:
kfree(sg);
return ERR_PTR(ret);
}
@@ -143,6 +157,7 @@ static void release_udmabuf(struct dma_buf *buf)
for (pg = 0; pg < ubuf->pagecount; pg++)
put_page(ubuf->pages[pg]);
+ kfree(ubuf->subpgoff);
kfree(ubuf->pages);
kfree(ubuf);
}
@@ -206,7 +221,9 @@ static long udmabuf_create(struct miscdevice *device,
struct udmabuf *ubuf;
struct dma_buf *buf;
pgoff_t pgoff, pgcnt, pgidx, pgbuf = 0, pglimit;
- struct page *page;
+ struct page *page, *hpage = NULL;
+ pgoff_t mapidx, chunkoff, maxchunks;
+ struct hstate *hpstate;
int seals, ret = -EINVAL;
u32 i, flags;
@@ -242,7 +259,7 @@ static long udmabuf_create(struct miscdevice *device,
if (!memfd)
goto err;
mapping = memfd->f_mapping;
- if (!shmem_mapping(mapping))
+ if (!shmem_mapping(mapping) && !is_file_hugepages(memfd))
goto err;
seals = memfd_fcntl(memfd, F_GET_SEALS, 0);
if (seals == -EINVAL)
@@ -253,16 +270,57 @@ static long udmabuf_create(struct miscdevice *device,
goto err;
pgoff = list[i].offset >> PAGE_SHIFT;
pgcnt = list[i].size >> PAGE_SHIFT;
+ if (is_file_hugepages(memfd)) {
+ if (!ubuf->subpgoff) {
+ ubuf->subpgoff = kmalloc_array(ubuf->pagecount,
+
s
Re: [PATCH 09/11] drm/rockchip: vop2: Add support for rk3588
Hi Jonas:
On 11/18/23 07:46, Jonas Karlman wrote:
On 2023-11-14 12:28, Andy Yan wrote:
From: Andy Yan
VOP2 on rk3588:
Four video ports:
VP0 Max 4096x2160
VP1 Max 4096x2160
VP2 Max 4096x2160
VP3 Max 2048x1080
4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support
4 4K Esmart windows with line RGB/YUV support
Signed-off-by: Andy Yan
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 324 ++-
drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 57
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 215
include/dt-bindings/soc/rockchip,vop2.h | 4 +
4 files changed, 593 insertions(+), 7 deletions(-)
[...]
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
index 22288ad7f326..4745a9260cf8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
@@ -34,6 +34,28 @@ static const uint32_t formats_cluster[] = {
DRM_FORMAT_Y210, /* yuv422_10bit non-Linear mode only */
};
+static const uint32_t formats_esmart[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_BGR565,
+ DRM_FORMAT_NV12, /* yuv420_8bit linear mode, 2 plane */
+ DRM_FORMAT_NV21, /* yvu420_8bit linear mode, 2 plane */
+ DRM_FORMAT_NV16, /* yuv422_8bit linear mode, 2 plane */
+ DRM_FORMAT_NV61, /* yvu422_8bit linear mode, 2 plane */
+ DRM_FORMAT_NV24, /* yuv444_8bit linear mode, 2 plane */
+ DRM_FORMAT_NV42, /* yvu444_8bit linear mode, 2 plane */
+ DRM_FORMAT_NV15, /* yuv420_10bit linear mode, 2 plane, no padding */
NV20 and NV30 drm format have now been merged into mainline linux,
please add these missing formats. The patch below adds support for them
to rk356x part of vop2 driver.
Thanks for your reminder and your efforts to make these formats land
mainline. I will add it in the next version.
drm/rockchip: vop2: Add NV20 and NV30 support
https://lore.kernel.org/linux-rockchip/20231025213248.2641962-1-jo...@kwiboo.se/
NV15/NV20/NV30 formats can be tested using modetest from latest main
of libdrm.
modetest: add support for DRM_FORMAT_NV{15,20,30}
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/329
Regards,
Jonas
+ DRM_FORMAT_YVYU, /* yuv422_8bit[YVYU] linear mode */
+ DRM_FORMAT_VYUY, /* yuv422_8bit[VYUY] linear mode */
+ DRM_FORMAT_YUYV, /* yuv422_8bit[YUYV] linear mode */
+ DRM_FORMAT_UYVY, /* yuv422_8bit[UYVY] linear mode */
+};
+
static const uint32_t formats_rk356x_esmart[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
[...]
Re: [PATCH 09/11] drm/rockchip: vop2: Add support for rk3588
On 2023-11-14 12:28, Andy Yan wrote:
> From: Andy Yan
>
> VOP2 on rk3588:
>
> Four video ports:
> VP0 Max 4096x2160
> VP1 Max 4096x2160
> VP2 Max 4096x2160
> VP3 Max 2048x1080
>
> 4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support
> 4 4K Esmart windows with line RGB/YUV support
>
> Signed-off-by: Andy Yan
> ---
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 324 ++-
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 57
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 215
> include/dt-bindings/soc/rockchip,vop2.h | 4 +
> 4 files changed, 593 insertions(+), 7 deletions(-)
>
[...]
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> index 22288ad7f326..4745a9260cf8 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> @@ -34,6 +34,28 @@ static const uint32_t formats_cluster[] = {
> DRM_FORMAT_Y210, /* yuv422_10bit non-Linear mode only */
> };
>
> +static const uint32_t formats_esmart[] = {
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_BGR888,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR565,
> + DRM_FORMAT_NV12, /* yuv420_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV21, /* yvu420_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV16, /* yuv422_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV61, /* yvu422_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV24, /* yuv444_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV42, /* yvu444_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV15, /* yuv420_10bit linear mode, 2 plane, no padding */
NV20 and NV30 drm format have now been merged into mainline linux,
please add these missing formats. The patch below adds support for them
to rk356x part of vop2 driver.
drm/rockchip: vop2: Add NV20 and NV30 support
https://lore.kernel.org/linux-rockchip/20231025213248.2641962-1-jo...@kwiboo.se/
NV15/NV20/NV30 formats can be tested using modetest from latest main
of libdrm.
modetest: add support for DRM_FORMAT_NV{15,20,30}
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/329
Regards,
Jonas
> + DRM_FORMAT_YVYU, /* yuv422_8bit[YVYU] linear mode */
> + DRM_FORMAT_VYUY, /* yuv422_8bit[VYUY] linear mode */
> + DRM_FORMAT_YUYV, /* yuv422_8bit[YUYV] linear mode */
> + DRM_FORMAT_UYVY, /* yuv422_8bit[UYVY] linear mode */
> +};
> +
> static const uint32_t formats_rk356x_esmart[] = {
> DRM_FORMAT_XRGB,
> DRM_FORMAT_ARGB,
[...]
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix phys_base to be relative not absolute
On Tue, Nov 14, 2023 at 10:13:59PM -0500, Rodrigo Vivi wrote:
> On Sun, Nov 05, 2023 at 05:27:03PM +, Paz Zcharya wrote:
> > Fix the value of variable `phys_base` to be the relative offset in
> > stolen memory, and not the absolute offset of the GSM.
>
> to me it looks like the other way around. phys_base is the physical
> base address for the frame_buffer. Setting it to zero doesn't seem
> to make that relative. And also doesn't look right.
>
> >
> > Currently, the value of `phys_base` is set to "Surface Base Address,"
> > which in the case of Meter Lake is 0xfc00_.
>
> I don't believe this is a fixed value. IIRC this comes from the register
> set by video bios, where the idea is to reuse the fb that was used so
> far.
>
> With this in mind I don't understand how that could overflow. Maybe
> the size of the stolen is not right? maybe the size? maybe different
> memory region?
>
Hi Rodrigo, thanks for the great comments.
Apologies for using a wrong/confusing terminology. I think 'phys_base'
is supposed to be the offset in the GEM BO, where base (or
"Surface Base Address") is supposed to be the GTT offset.
Other than what I wrote before, I noticed that the function 'i915_vma_pin'
which calls to 'i915_gem_gtt_reserve' is the one that binds the right
address space in the GTT for that stolen region.
I see that in the function 'i915_vma_insert' (full call stack below),
where if (flags & PIN_OFFSET_FIXED), then when calling 'i915_gem_gtt_reserve'
we add an offset.
Specifically in MeteorLake, and specifically when using GOP driver, this
offset is equal to 0xfc00_. But as you mentioned, this is not strict.
The if statement always renders true because in the function
'initial_plane_vma' we always set
pinctl = PIN_GLOBAL | PIN_OFFSET_FIXED | base;
where pinctl == flags (see file 'intel_plane_initial.c' line 145).
Call stack:
drm_mm_reserve_node
i915_gem_gtt_reserve
i915_vma_insert
i915_vma_pin_ww
i915_vma_pin
initial_plane_vma
intel_alloc_initial_plane_obj
intel_find_initial_plane_obj
Therefore, I believe the variable 'phys_base' in the
function 'initial_plane_vma,' should be the the offset in the GEM BO
and not the GTT offset, and because the base is added later on
in the function 'i915_gem_gtt_reserve', this value should not be
equal to base and be 0.
Hope it makes more sense.
> > This causes the
> > function `i915_gem_object_create_region_at` to fail in line 128, when
> > it attempts to verify that the range does not overflow:
> >
> > if (range_overflows(offset, size, resource_size(&mem->region)))
> > return ERR_PTR(-EINVAL);
> >
> > where:
> > offset = 0xfc00
> > size = 0x8ca000
> > mem->region.end + 1 = 0x440
> > mem->region.start = 0x80
> > resource_size(&mem->region) = 0x3c0
> >
> > call stack:
> > i915_gem_object_create_region_at
> > initial_plane_vma
> > intel_alloc_initial_plane_obj
> > intel_find_initial_plane_obj
> > intel_crtc_initial_plane_config
> >
> > Looking at the flow coming next, we see that `phys_base` is only used
> > once, in function `_i915_gem_object_stolen_init`, in the context of
> > the offset *in* the stolen memory. Combining that with an
> > examinination of the history of the file seems to indicate the
> > current value set is invalid.
> >
> > call stack (functions using `phys_base`)
> > _i915_gem_object_stolen_init
> > __i915_gem_object_create_region
> > i915_gem_object_create_region_at
> > initial_plane_vma
> > intel_alloc_initial_plane_obj
> > intel_find_initial_plane_obj
> > intel_crtc_initial_plane_config
> >
> > [drm:_i915_gem_object_stolen_init] creating preallocated stolen
> > object: stolen_offset=0x, size=0x008ca000
> >
> > Signed-off-by: Paz Zcharya
> > ---
> >
> > drivers/gpu/drm/i915/display/intel_plane_initial.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> > b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> > index a55c09cbd0e4..e696cb13756a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> > +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> > @@ -90,7 +90,7 @@ initial_plane_vma(struct drm_i915_private *i915,
> > "Using phys_base=%pa, based on initial plane
> > programming\n",
> > &phys_base);
> > } else {
> > - phys_base = base;
> > + phys_base = 0;
> > mem = i915->mm.stolen_region;
> > }
> >
> > --
> > 2.42.0.869.gea05f2083d-goog
> >
Re: [PATCH 0/1] Backlight driver for the Apple Studio Display
Did you get a chance to implement V2? I want this in my own install! :) Thank you Sean Aguinaga
Re: [RFT PATCH v2 04/12] drm/nouveau: Call drm_atomic_helper_shutdown() or equiv at shutdown time
Hi, On Fri, Sep 22, 2023 at 2:06 PM Lyude Paul wrote: > > actually very glad to see this because I think I've seen one bug in the wild > as a result of things not getting shut down :) > > Reviewed-by: Lyude Paul > Tested-by: Lyude Paul Any idea of where / how this patch should land. Would you expect me to land it through drm-misc, or would you expect it to go through someone else's tree?
Re: [PATCH v2] drm/i915/gsc: Mark internal GSC engine with reserved uabi class
On 11/16/2023 12:44 AM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
The GSC CS is not exposed to the user, so we skipped assigning a uabi
class number for it. However, the trace logs use the uabi class and
instance to identify the engine, so leaving uabi class unset makes the
GSC CS show up as the RCS in those logs.
Given that the engine is not exposed to the user, we can't add a new
case in the uabi enum, so we insted internally define a kernel
internal class as -1.
At the same time remove special handling for the name and complete
the uabi_classes array so internal class is automatically correctly
assigned.
Engine will show as 65535:0 other0 in the logs/traces which should
be unique enough.
v2:
* Fix uabi class u8 vs u16 type confusion.
Signed-off-by: Tvrtko Ursulin
Fixes: 194babe26bdc ("drm/i915/mtl: don't expose GSC command streamer to the
user")
Cc: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: Matt Roper
Reviewed-by: Daniele Ceraolo Spurio # v1
My r-b stands.
Thanks,
Daniele
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 39 -
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 118164ddbb2e..833987015b8b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -41,12 +41,15 @@ void intel_engine_add_user(struct intel_engine_cs *engine)
llist_add(&engine->uabi_llist, &engine->i915->uabi_engines_llist);
}
-static const u8 uabi_classes[] = {
+#define I915_NO_UABI_CLASS ((u16)(-1))
+
+static const u16 uabi_classes[] = {
[RENDER_CLASS] = I915_ENGINE_CLASS_RENDER,
[COPY_ENGINE_CLASS] = I915_ENGINE_CLASS_COPY,
[VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
[VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
[COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
+ [OTHER_CLASS] = I915_NO_UABI_CLASS, /* Not exposed to users, no uabi
class. */
};
static int engine_cmp(void *priv, const struct list_head *A,
@@ -200,6 +203,7 @@ static void engine_rename(struct intel_engine_cs *engine,
const char *name, u16
void intel_engines_driver_register(struct drm_i915_private *i915)
{
+ u16 name_instance, other_instance = 0;
struct legacy_ring ring = {};
struct list_head *it, *next;
struct rb_node **p, *prev;
@@ -216,27 +220,28 @@ void intel_engines_driver_register(struct
drm_i915_private *i915)
if (intel_gt_has_unrecoverable_error(engine->gt))
continue; /* ignore incomplete engines */
- /*
-* We don't want to expose the GSC engine to the users, but we
-* still rename it so it is easier to identify in the debug logs
-*/
- if (engine->id == GSC0) {
- engine_rename(engine, "gsc", 0);
- continue;
- }
-
GEM_BUG_ON(engine->class >= ARRAY_SIZE(uabi_classes));
engine->uabi_class = uabi_classes[engine->class];
+ if (engine->uabi_class == I915_NO_UABI_CLASS) {
+ name_instance = other_instance++;
+ } else {
+ GEM_BUG_ON(engine->uabi_class >=
+ ARRAY_SIZE(i915->engine_uabi_class_count));
+ name_instance =
+
i915->engine_uabi_class_count[engine->uabi_class]++;
+ }
+ engine->uabi_instance = name_instance;
- GEM_BUG_ON(engine->uabi_class >=
- ARRAY_SIZE(i915->engine_uabi_class_count));
- engine->uabi_instance =
- i915->engine_uabi_class_count[engine->uabi_class]++;
-
- /* Replace the internal name with the final user facing name */
+ /*
+* Replace the internal name with the final user and log facing
+* name.
+*/
engine_rename(engine,
intel_engine_class_repr(engine->class),
- engine->uabi_instance);
+ name_instance);
+
+ if (engine->uabi_class == I915_NO_UABI_CLASS)
+ continue;
rb_link_node(&engine->uabi_node, prev, p);
rb_insert_color(&engine->uabi_node, &i915->uabi_engines);
Re: [PATCH v7 2/3] drm/panel-edp: Add auo_b116xa3_mode
Hi, On Fri, Nov 17, 2023 at 1:51 PM Hsin-Yi Wang wrote: > > Add auo_b116xa3_mode to override the original modes parsed from edid > of the panels 0x405c B116XAK01.0 and 0x615c B116XAN06.1 which result > in glitches on panel. > > Signed-off-by: Hsin-Yi Wang > --- > v6->v7: split usecase to another patch. > --- > drivers/gpu/drm/panel/panel-edp.c | 19 +-- > 1 file changed, 17 insertions(+), 2 deletions(-) Reviewed-by: Douglas Anderson
Re: [PATCH 1/2] drm/scheduler: improve GPU scheduler documentation v2
Hi, On 2023-11-16 09:15, Christian König wrote: > Start to improve the scheduler document. Especially document the > lifetime of each of the objects as well as the restrictions around > DMA-fence handling and userspace compatibility. > > v2: Some improvements suggested by Danilo, add section about error > handling. > > Signed-off-by: Christian König > --- > Documentation/gpu/drm-mm.rst | 36 + > drivers/gpu/drm/scheduler/sched_main.c | 174 + > 2 files changed, 188 insertions(+), 22 deletions(-) > > diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst > index acc5901ac840..112463fa9f3a 100644 > --- a/Documentation/gpu/drm-mm.rst > +++ b/Documentation/gpu/drm-mm.rst > @@ -552,12 +552,48 @@ Overview > .. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c > :doc: Overview > > +Job Object > +-- > + > +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c > + :doc: Job Object > + > +Entity Object > +- > + > +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c > + :doc: Entity Object > + > +Hardware Fence Object > +- > + > +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c > + :doc: Hardware Fence Object > + > +Scheduler Fence Object > +-- > + > +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c > + :doc: Scheduler Fence Object > + > +Scheduler and Run Queue Objects > +--- > + > +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c > + :doc: Scheduler and Run Queue Objects > + > Flow Control > > > .. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c > :doc: Flow Control > > +Error and Timeout handling > +-- > + > +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c > + :doc: Error and Timeout handling > + > Scheduler Function References > - > > diff --git a/drivers/gpu/drm/scheduler/sched_main.c > b/drivers/gpu/drm/scheduler/sched_main.c > index 044a8c4875ba..026123497b0e 100644 > --- a/drivers/gpu/drm/scheduler/sched_main.c > +++ b/drivers/gpu/drm/scheduler/sched_main.c > @@ -24,28 +24,122 @@ > /** > * DOC: Overview > * > - * The GPU scheduler provides entities which allow userspace to push jobs > - * into software queues which are then scheduled on a hardware run queue. > - * The software queues have a priority among them. The scheduler selects the > entities > - * from the run queue using a FIFO. The scheduler provides dependency > handling > - * features among jobs. The driver is supposed to provide callback functions > for > - * backend operations to the scheduler like submitting a job to hardware run > queue, > - * returning the dependencies of a job etc. > - * > - * The organisation of the scheduler is the following: > - * > - * 1. Each hw run queue has one scheduler > - * 2. Each scheduler has multiple run queues with different priorities > - *(e.g., HIGH_HW,HIGH_SW, KERNEL, NORMAL) > - * 3. Each scheduler run queue has a queue of entities to schedule > - * 4. Entities themselves maintain a queue of jobs that will be scheduled on > - *the hardware. > - * > - * The jobs in a entity are always scheduled in the order that they were > pushed. > - * > - * Note that once a job was taken from the entities queue and pushed to the > - * hardware, i.e. the pending queue, the entity must not be referenced > anymore > - * through the jobs entity pointer. > + * The GPU scheduler implements some logic to decide which command submission > + * to push next to the hardware. Another major use case of the GPU scheduler You can't start a 2nd sentence with "Another major use ...", not unless you'd been discussing the other major use for at least a few paragraphs, but not after just once sentence. Get rid of "some" in "some logic", and just say "implements logic to ..." Then 2nd sentence should say, "The GPU scheduler also enforces correct ..." > + * is to enforce correct driver behavior around those command submissions. > + * Because of this it's also used by drivers which don't need the actual > + * scheduling functionality. > + * > + * All callbacks the driver needs to implement are restricted by DMA-fence > + * signaling rules to guarantee deadlock free forward progress. This > especially "deadlock-free" Link to "DMA-fence signaling rules" would be nice to have. Can't mention them, and not provide a link. Naturally someone reading this would immediately ask themselves, "What are the ``DMA-fence signaling rules''?", and if they don't need to ask themselves this, then they probably mostly know all of this here too. > + * means that for normal operation no memory can be allocated in a callback. What callback? Perhaps say, "callback into the driver", or name it/them, as they're in the code. > + * All memory which is needed for pushing the job to the hardware must be "pushing _a_ job" > + * allocated before arming a job
Re: [PATCH 0/1] Backlight driver for the Apple Studio Display
On Fri, 17 Nov 2023, Sean Aguinaga wrote:
Hi,
> Did you get a chance to implement V2?
Yes, v2 is here [1] and v3 is here [2]. Currently I do have the
a few changes on top of v3 that are appended here as a patch. I use it
with DMKS and it works (mostly). I do see the userspace confusion when
the monitor is plugged in after boot.
Its still possible to set it by writing to the brightness file.
Julius
[1] https://lore.kernel.org/dri-devel/20230806091403.10002-1-jul...@zint.sh/
[2] https://lore.kernel.org/dri-devel/20230820094118.20521-1-jul...@zint.sh/
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index b964a820956d..35864cc1afee 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -477,8 +477,7 @@ config BACKLIGHT_HID
depends on HID
help
If you have an external display with VESA compliant HID brightness
- controls then say Y to enable this backlight driver. Currently the
- only supported device is the Apple Studio Display.
+ controls then say Y to enable this backlight driver.
endif # BACKLIGHT_CLASS_DEVICE
diff --git a/drivers/video/backlight/hid_bl.c b/drivers/video/backlight/hid_bl.c
index b40f8f412ee2..38b82de8224f 100644
--- a/drivers/video/backlight/hid_bl.c
+++ b/drivers/video/backlight/hid_bl.c
@@ -4,8 +4,8 @@
#include
#include
-#define APPLE_STUDIO_DISPLAY_VENDOR_ID 0x05ac
-#define APPLE_STUDIO_DISPLAY_PRODUCT_ID 0x1114
+#define APPLE_STUDIO_DISPLAY_VENDOR_ID 0x05ac
+#define APPLE_STUDIO_DISPLAY_PRODUCT_ID0x1114
#define HID_USAGE_MONITOR_CTRL 0x81
#define HID_USAGE_VESA_VCP_BRIGHTNESS 0x820010
@@ -59,7 +59,8 @@ struct hid_bl_data {
static struct hid_field *hid_get_usage_field(struct hid_device *hdev,
unsigned int report_type,
-unsigned int application, unsigned
int usage)
+unsigned int application,
+unsigned int usage)
{
struct hid_report_enum *re = &hdev->report_enum[report_type];
struct hid_report *report;
@@ -82,18 +83,8 @@ static struct hid_field *hid_get_usage_field(struct
hid_device *hdev,
static void hid_bl_remove(struct hid_device *hdev)
{
- struct backlight_device *bl;
- struct hid_bl_data *data;
-
- hid_dbg(hdev, "remove\n");
- bl = hid_get_drvdata(hdev);
- data = bl_get_data(bl);
-
- devm_backlight_device_unregister(&hdev->dev, bl);
hid_hw_close(hdev);
hid_hw_stop(hdev);
- hid_set_drvdata(hdev, NULL);
- devm_kfree(&hdev->dev, data);
}
static int hid_bl_get_brightness_raw(struct hid_bl_data *data)
@@ -105,7 +96,6 @@ static int hid_bl_get_brightness_raw(struct hid_bl_data
*data)
hid_hw_request(data->hdev, field->report, HID_REQ_GET_REPORT);
hid_hw_wait(data->hdev);
result = *field->new_value;
- hid_dbg(data->hdev, "get brightness: %d\n", result);
return result;
}
@@ -128,7 +118,6 @@ static void hid_bl_set_brightness_raw(struct hid_bl_data
*data, int brightness)
*field->value = brightness;
hid_hw_request(data->hdev, field->report, HID_REQ_SET_REPORT);
hid_hw_wait(data->hdev);
- hid_dbg(data->hdev, "set brightness: %d\n", brightness);
}
static int hid_bl_update_status(struct backlight_device *bl)
@@ -157,8 +146,6 @@ static int hid_bl_probe(struct hid_device *hdev, const
struct hid_device_id *id)
struct backlight_properties props;
struct backlight_device *bl;
- hid_dbg(hdev, "probe\n");
-
ret = hid_parse(hdev);
if (ret) {
hid_err(hdev, "parse failed: %d\n", ret);
@@ -203,8 +190,6 @@ static int hid_bl_probe(struct hid_device *hdev, const
struct hid_device_id *id)
goto exit_stop;
}
- hid_dbg(hdev, "Monitor VESA VCP with brightness control\n");
-
ret = hid_hw_open(hdev);
if (ret) {
hid_err(hdev, "hw open failed: %d\n", ret);
@@ -214,7 +199,7 @@ static int hid_bl_probe(struct hid_device *hdev, const
struct hid_device_id *id)
data = devm_kzalloc(&hdev->dev, sizeof(*data), GFP_KERNEL);
if (data == NULL) {
ret = -ENOMEM;
- goto exit_stop;
+ goto exit_close;
}
data->hdev = hdev;
data->min_brightness = input_field->logical_minimum;
@@ -233,16 +218,15 @@ static int hid_bl_probe(struct hid_device *hdev, const
struct hid_device_id *id)
if (IS_ERR(bl)) {
ret = PTR_ERR(bl);
hid_err(hdev, "failed to register backlight: %d\n", ret);
- goto exit_free;
+ goto exit_close;
}
hid_set_drvdata(hdev, bl);
return 0;
-exit_free:
+exit_close:
hid_hw_close(hdev);
- devm_kfree(&hdev->
Re: [PATCH 2/3] fbdev: ssd1307fb: Change "solomon,page-offset" property default value
Andy Shevchenko writes: Hello Andy, > On Thu, Nov 16, 2023 at 07:07:38PM +0100, Javier Martinez Canillas wrote: >> This is used to specify the page start address offset of the display RAM. >> >> The value is used as offset when setting the page start address with the >> SSD130X_SET_PAGE_RANGE command, and the driver currently sets its value to >> 1 if the property is not present in the Device Tree. >> >> But the datasheet mentions that the value on reset for the page start is a >> 0, so it makes more sense to also have 0 as the default value for the page >> offset if the property is not present. >> >> In fact, using a default value of 1 leads to the display not working when >> the fbdev is attached to the framebuffer console. >> >> Reported-by: Sahaj Sarup > > Closes? There's no report in a mailing list or bug tracker to reference. > Fixes? > Since the default has been the same since the driver was merged, it doesn't make that much sense for me to reference that commit. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PULL] drm-fixes for -rc2
The pull request you sent on Fri, 17 Nov 2023 18:02:21 +0100: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-11-17 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e63fe2d35ee095b483adf936747dbc7d85f3de38 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v7 2/3] drm/panel-edp: Add auo_b116xa3_mode
On Fri, Nov 17, 2023 at 1:51 PM Hsin-Yi Wang wrote:
>
> Add auo_b116xa3_mode to override the original modes parsed from edid
> of the panels 0x405c B116XAK01.0 and 0x615c B116XAN06.1 which result
> in glitches on panel.
>
> Signed-off-by: Hsin-Yi Wang
> ---
> v6->v7: split usecase to another patch.
-cc: stable
> ---
> drivers/gpu/drm/panel/panel-edp.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/drivers/gpu/drm/panel/panel-edp.c
> index 33535f6de343..3e144145a6bd 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -983,6 +983,19 @@ static const struct panel_desc auo_b101ean01 = {
> },
> };
>
> +static const struct drm_display_mode auo_b116xa3_mode = {
> + .clock = 70589,
> + .hdisplay = 1366,
> + .hsync_start = 1366 + 40,
> + .hsync_end = 1366 + 40 + 40,
> + .htotal = 1366 + 40 + 40 + 32,
> + .vdisplay = 768,
> + .vsync_start = 768 + 10,
> + .vsync_end = 768 + 10 + 12,
> + .vtotal = 768 + 10 + 12 + 6,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +};
> +
> static const struct drm_display_mode auo_b116xak01_mode = {
> .clock = 69300,
> .hdisplay = 1366,
> @@ -1908,9 +1921,11 @@ static const struct edp_panel_entry edp_panels[] = {
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x239b, &delay_200_500_e50,
> "B116XAN06.1"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x255c, &delay_200_500_e50,
> "B116XTN02.5"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x403d, &delay_200_500_e50,
> "B140HAN04.0"),
> - EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, &auo_b116xak01.delay,
> "B116XAK01.0"),
> + EDP_PANEL_ENTRY2('A', 'U', 'O', 0x405c, &auo_b116xak01.delay,
> "B116XAK01.0",
> +&auo_b116xa3_mode),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x582d, &delay_200_500_e50,
> "B133UAN01.0"),
> - EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, &delay_200_500_e50,
> "B116XAN06.1"),
> + EDP_PANEL_ENTRY2('A', 'U', 'O', 0x615c, &delay_200_500_e50,
> "B116XAN06.1",
> +&auo_b116xa3_mode),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x635c, &delay_200_500_e50,
> "B116XAN06.3"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x639c, &delay_200_500_e50,
> "B140HAK02.7"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, &delay_200_500_e50,
> "B133UAN01.0"),
> --
> 2.43.0.rc0.421.g78406f8d94-goog
>
Re: [PATCH v7 1/3] drm/panel-edp: Add override_edid_mode quirk for generic edp
On Fri, Nov 17, 2023 at 2:06 PM Greg KH wrote: > > On Fri, Nov 17, 2023 at 01:46:32PM -0800, Hsin-Yi Wang wrote: > > Generic edp gets mode from edid. However, some panels report incorrect > > mode in this way, resulting in glitches on panel. Introduce a new quirk > > additional_mode to the generic edid to pick a correct hardcoded mode. > > > > Signed-off-by: Hsin-Yi Wang > > Reviewed-by: Douglas Anderson > > --- > > v6->v7: split usecase to another patch. > > --- > > drivers/gpu/drm/panel/panel-edp.c | 48 +-- > > 1 file changed, 45 insertions(+), 3 deletions(-) > > > > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > for how to do this properly. > Forgot to -cc: stable, these patches don't need to be picked to stable. >
Re: [PATCH v7 1/3] drm/panel-edp: Add override_edid_mode quirk for generic edp
On Fri, Nov 17, 2023 at 01:46:32PM -0800, Hsin-Yi Wang wrote: > Generic edp gets mode from edid. However, some panels report incorrect > mode in this way, resulting in glitches on panel. Introduce a new quirk > additional_mode to the generic edid to pick a correct hardcoded mode. > > Signed-off-by: Hsin-Yi Wang > Reviewed-by: Douglas Anderson > --- > v6->v7: split usecase to another patch. > --- > drivers/gpu/drm/panel/panel-edp.c | 48 +-- > 1 file changed, 45 insertions(+), 3 deletions(-) This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
[PATCH 3/3] drm/amdkfd: Import DMABufs for interop through DRM
Use drm_gem_prime_fd_to_handle to import DMABufs for interop. This
ensures that a GEM handle is created on import and that obj->dma_buf
will be set and remain set as long as the object is imported into KFD.
Signed-off-by: Felix Kuehling
Reviewed-by: Ramesh Errabolu
Reviewed-by: Xiaogang.Chen
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 9 ++-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 64 +--
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 15 ++---
3 files changed, 52 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index c1195eb67057..8da42e0dddcb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -319,11 +319,10 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void
*process_info,
struct dma_fence **ef);
int amdgpu_amdkfd_gpuvm_get_vm_fault_info(struct amdgpu_device *adev,
struct kfd_vm_fault_info *info);
-int amdgpu_amdkfd_gpuvm_import_dmabuf(struct amdgpu_device *adev,
- struct dma_buf *dmabuf,
- uint64_t va, void *drm_priv,
- struct kgd_mem **mem, uint64_t *size,
- uint64_t *mmap_offset);
+int amdgpu_amdkfd_gpuvm_import_dmabuf_fd(struct amdgpu_device *adev, int fd,
+uint64_t va, void *drm_priv,
+struct kgd_mem **mem, uint64_t *size,
+uint64_t *mmap_offset);
int amdgpu_amdkfd_gpuvm_export_dmabuf(struct kgd_mem *mem,
struct dma_buf **dmabuf);
void amdgpu_amdkfd_debug_mem_fence(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index b13d68b7bb28..966272e067b2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1957,8 +1957,7 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
/* Free the BO*/
drm_vma_node_revoke(&mem->bo->tbo.base.vma_node, drm_priv);
- if (!mem->is_imported)
- drm_gem_handle_delete(adev->kfd.client.file, mem->gem_handle);
+ drm_gem_handle_delete(adev->kfd.client.file, mem->gem_handle);
if (mem->dmabuf) {
dma_buf_put(mem->dmabuf);
mem->dmabuf = NULL;
@@ -2314,34 +2313,26 @@ int amdgpu_amdkfd_gpuvm_get_vm_fault_info(struct
amdgpu_device *adev,
return 0;
}
-int amdgpu_amdkfd_gpuvm_import_dmabuf(struct amdgpu_device *adev,
- struct dma_buf *dma_buf,
- uint64_t va, void *drm_priv,
- struct kgd_mem **mem, uint64_t *size,
- uint64_t *mmap_offset)
+static int import_obj_create(struct amdgpu_device *adev,
+struct dma_buf *dma_buf,
+struct drm_gem_object *obj,
+uint64_t va, void *drm_priv,
+struct kgd_mem **mem, uint64_t *size,
+uint64_t *mmap_offset)
{
struct amdgpu_vm *avm = drm_priv_to_vm(drm_priv);
- struct drm_gem_object *obj;
struct amdgpu_bo *bo;
int ret;
- obj = amdgpu_gem_prime_import(adev_to_drm(adev), dma_buf);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
-
bo = gem_to_amdgpu_bo(obj);
if (!(bo->preferred_domains & (AMDGPU_GEM_DOMAIN_VRAM |
- AMDGPU_GEM_DOMAIN_GTT))) {
+ AMDGPU_GEM_DOMAIN_GTT)))
/* Only VRAM and GTT BOs are supported */
- ret = -EINVAL;
- goto err_put_obj;
- }
+ return -EINVAL;
*mem = kzalloc(sizeof(struct kgd_mem), GFP_KERNEL);
- if (!*mem) {
- ret = -ENOMEM;
- goto err_put_obj;
- }
+ if (!*mem)
+ return -ENOMEM;
ret = drm_vma_node_allow(&obj->vma_node, drm_priv);
if (ret)
@@ -2391,8 +2382,41 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct
amdgpu_device *adev,
drm_vma_node_revoke(&obj->vma_node, drm_priv);
err_free_mem:
kfree(*mem);
+ return ret;
+}
+
+int amdgpu_amdkfd_gpuvm_import_dmabuf_fd(struct amdgpu_device *adev, int fd,
+uint64_t va, void *drm_priv,
+struct kgd_mem **mem, uint64_t *size,
+uint64_t *mmap_offset)
+{
+ struct drm_gem_object *obj;
+ uint32_t handle;
+ int ret;
+
+ ret = drm_gem_prime_f
[PATCH 2/3] drm/amdkfd: Export DMABufs from KFD using GEM handles
Create GEM handles for exporting DMABufs using GEM-Prime APIs. The GEM
handles are created in a drm_client_dev context to avoid exposing them
in user mode contexts through a DMABuf import.
Signed-off-by: Felix Kuehling
Reviewed-by: Ramesh Errabolu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 11 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 5 +++
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 33 +++
3 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index b8412202a1b0..aa8b24079070 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -142,6 +142,7 @@ void amdgpu_amdkfd_device_init(struct amdgpu_device *adev)
{
int i;
int last_valid_bit;
+ int ret;
amdgpu_amdkfd_gpuvm_init_mem_limits();
@@ -160,6 +161,12 @@ void amdgpu_amdkfd_device_init(struct amdgpu_device *adev)
.enable_mes = adev->enable_mes,
};
+ ret = drm_client_init(&adev->ddev, &adev->kfd.client, "kfd",
NULL);
+ if (ret) {
+ dev_err(adev->dev, "Failed to init DRM client: %d\n",
ret);
+ return;
+ }
+
/* this is going to have a few of the MSBs set that we need to
* clear
*/
@@ -198,6 +205,10 @@ void amdgpu_amdkfd_device_init(struct amdgpu_device *adev)
adev->kfd.init_complete = kgd2kfd_device_init(adev->kfd.dev,
&gpu_resources);
+ if (adev->kfd.init_complete)
+ drm_client_register(&adev->kfd.client);
+ else
+ drm_client_release(&adev->kfd.client);
amdgpu_amdkfd_total_mem_size += adev->gmc.real_vram_size;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index dac983da961d..c1195eb67057 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include "amdgpu_sync.h"
#include "amdgpu_vm.h"
#include "amdgpu_xcp.h"
@@ -83,6 +84,7 @@ struct kgd_mem {
struct amdgpu_sync sync;
+ uint32_t gem_handle;
bool aql_queue;
bool is_imported;
};
@@ -105,6 +107,9 @@ struct amdgpu_kfd_dev {
/* HMM page migration MEMORY_DEVICE_PRIVATE mapping */
struct dev_pagemap pgmap;
+
+ /* Client for KFD BO GEM handle allocations */
+ struct drm_client_dev client;
};
enum kgd_engine_type {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 41fbc4fd0fac..b13d68b7bb28 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -806,13 +807,22 @@ kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
static int kfd_mem_export_dmabuf(struct kgd_mem *mem)
{
if (!mem->dmabuf) {
- struct dma_buf *ret = amdgpu_gem_prime_export(
- &mem->bo->tbo.base,
+ struct amdgpu_device *bo_adev;
+ struct dma_buf *dmabuf;
+ int r, fd;
+
+ bo_adev = amdgpu_ttm_adev(mem->bo->tbo.bdev);
+ r = drm_gem_prime_handle_to_fd(&bo_adev->ddev,
bo_adev->kfd.client.file,
+ mem->gem_handle,
mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
- DRM_RDWR : 0);
- if (IS_ERR(ret))
- return PTR_ERR(ret);
- mem->dmabuf = ret;
+ DRM_RDWR : 0, &fd);
+ if (r)
+ return r;
+ dmabuf = dma_buf_get(fd);
+ close_fd(fd);
+ if (WARN_ON_ONCE(IS_ERR(dmabuf)))
+ return PTR_ERR(dmabuf);
+ mem->dmabuf = dmabuf;
}
return 0;
@@ -1779,6 +1789,9 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
pr_debug("Failed to allow vma node access. ret %d\n", ret);
goto err_node_allow;
}
+ ret = drm_gem_handle_create(adev->kfd.client.file, gobj,
&(*mem)->gem_handle);
+ if (ret)
+ goto err_gem_handle_create;
bo = gem_to_amdgpu_bo(gobj);
if (bo_type == ttm_bo_type_sg) {
bo->tbo.sg = sg;
@@ -1830,6 +1843,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
err_pin_bo:
err_validate_bo:
remove_kgd_mem_from_kfd_bo_list(*mem, avm->process_info);
+ drm_gem_handle_delete(adev->kfd.client.file, (*mem)->gem_handle);
+err
[PATCH 1/3] Revert "drm/prime: Unexport helpers for fd/handle conversion"
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for KFD to export and import DMABufs
the right way without duplicating the tracking of DMABufs associated with
GEM objects while ensuring that move notifier callbacks are working as
intended.
CC: Christian König
CC: Thomas Zimmermann
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/drm_prime.c | 33 ++---
include/drm/drm_prime.h | 7 +++
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 63b709a67471..834a5e28abbe 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -278,7 +278,7 @@ void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
}
EXPORT_SYMBOL(drm_gem_dmabuf_release);
-/*
+/**
* drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
* @dev: drm_device to import into
* @file_priv: drm file-private structure
@@ -292,9 +292,9 @@ EXPORT_SYMBOL(drm_gem_dmabuf_release);
*
* Returns 0 on success or a negative error code on failure.
*/
-static int drm_gem_prime_fd_to_handle(struct drm_device *dev,
- struct drm_file *file_priv, int prime_fd,
- uint32_t *handle)
+int drm_gem_prime_fd_to_handle(struct drm_device *dev,
+ struct drm_file *file_priv, int prime_fd,
+ uint32_t *handle)
{
struct dma_buf *dma_buf;
struct drm_gem_object *obj;
@@ -360,6 +360,7 @@ static int drm_gem_prime_fd_to_handle(struct drm_device
*dev,
dma_buf_put(dma_buf);
return ret;
}
+EXPORT_SYMBOL(drm_gem_prime_fd_to_handle);
int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -408,7 +409,7 @@ static struct dma_buf *export_and_register_object(struct
drm_device *dev,
return dmabuf;
}
-/*
+/**
* drm_gem_prime_handle_to_fd - PRIME export function for GEM drivers
* @dev: dev to export the buffer from
* @file_priv: drm file-private structure
@@ -421,10 +422,10 @@ static struct dma_buf *export_and_register_object(struct
drm_device *dev,
* The actual exporting from GEM object to a dma-buf is done through the
* &drm_gem_object_funcs.export callback.
*/
-static int drm_gem_prime_handle_to_fd(struct drm_device *dev,
- struct drm_file *file_priv, uint32_t
handle,
- uint32_t flags,
- int *prime_fd)
+int drm_gem_prime_handle_to_fd(struct drm_device *dev,
+ struct drm_file *file_priv, uint32_t handle,
+ uint32_t flags,
+ int *prime_fd)
{
struct drm_gem_object *obj;
int ret = 0;
@@ -506,6 +507,7 @@ static int drm_gem_prime_handle_to_fd(struct drm_device
*dev,
return ret;
}
+EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -864,9 +866,9 @@ EXPORT_SYMBOL(drm_prime_get_contiguous_size);
* @obj: GEM object to export
* @flags: flags like DRM_CLOEXEC and DRM_RDWR
*
- * This is the implementation of the &drm_gem_object_funcs.export functions
- * for GEM drivers using the PRIME helpers. It is used as the default for
- * drivers that do not set their own.
+ * This is the implementation of the &drm_gem_object_funcs.export functions
for GEM drivers
+ * using the PRIME helpers. It is used as the default in
+ * drm_gem_prime_handle_to_fd().
*/
struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj,
int flags)
@@ -962,9 +964,10 @@ EXPORT_SYMBOL(drm_gem_prime_import_dev);
* @dev: drm_device to import into
* @dma_buf: dma-buf object to import
*
- * This is the implementation of the gem_prime_import functions for GEM
- * drivers using the PRIME helpers. It is the default for drivers that do
- * not set their own &drm_driver.gem_prime_import.
+ * This is the implementation of the gem_prime_import functions for GEM drivers
+ * using the PRIME helpers. Drivers can use this as their
+ * &drm_driver.gem_prime_import implementation. It is used as the default
+ * implementation in drm_gem_prime_fd_to_handle().
*
* Drivers must arrange to call drm_prime_gem_destroy() from their
* &drm_gem_object_funcs.free hook when using this function.
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index a7abf9f3e697..2a1d01e5b56b 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -60,12 +60,19 @@ enum dma_data_direction;
struct drm_device;
struct drm_gem_object;
+struct drm_file;
/* core prime functions */
struct dma_buf *drm_gem_dmabuf_export(struct drm_device *dev,
[PATCH v7 3/3] drm/panel-edp: Avoid adding multiple preferred modes
If a non generic edp-panel is under aux-bus, the mode read from edid would
still be selected as preferred and results in multiple preferred modes,
which is ambiguous.
If both hard-coded mode and edid exists, only add mode from hard-coded.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Douglas Anderson
---
v6->v7: no change
---
drivers/gpu/drm/panel/panel-edp.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 3e144145a6bd..825fa2a0d8a5 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -589,6 +589,7 @@ static int panel_edp_get_modes(struct drm_panel *panel,
{
struct panel_edp *p = to_panel_edp(panel);
int num = 0;
+ bool has_hard_coded_modes = p->desc->num_timings || p->desc->num_modes;
bool has_override_edid_mode = p->detected_panel &&
p->detected_panel != ERR_PTR(-EINVAL) &&
p->detected_panel->override_edid_mode;
@@ -599,7 +600,11 @@ static int panel_edp_get_modes(struct drm_panel *panel,
if (!p->edid)
p->edid = drm_get_edid(connector, p->ddc);
- if (p->edid) {
+ /*
+* If both edid and hard-coded modes exists, skip edid modes to
+* avoid multiple preferred modes.
+*/
+ if (p->edid && !has_hard_coded_modes) {
if (has_override_edid_mode) {
/*
* override_edid_mode is specified. Use
@@ -616,12 +621,7 @@ static int panel_edp_get_modes(struct drm_panel *panel,
pm_runtime_put_autosuspend(panel->dev);
}
- /*
-* Add hard-coded panel modes. Don't call this if there are no timings
-* and no modes (the generic edp-panel case) because it will clobber
-* the display_info that was already set by drm_add_edid_modes().
-*/
- if (p->desc->num_timings || p->desc->num_modes)
+ if (has_hard_coded_modes)
num += panel_edp_get_non_edid_modes(p, connector);
else if (!num)
dev_warn(p->base.dev, "No display modes\n");
--
2.43.0.rc0.421.g78406f8d94-goog
[PATCH v7 2/3] drm/panel-edp: Add auo_b116xa3_mode
Add auo_b116xa3_mode to override the original modes parsed from edid
of the panels 0x405c B116XAK01.0 and 0x615c B116XAN06.1 which result
in glitches on panel.
Signed-off-by: Hsin-Yi Wang
---
v6->v7: split usecase to another patch.
---
drivers/gpu/drm/panel/panel-edp.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 33535f6de343..3e144145a6bd 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -983,6 +983,19 @@ static const struct panel_desc auo_b101ean01 = {
},
};
+static const struct drm_display_mode auo_b116xa3_mode = {
+ .clock = 70589,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 40,
+ .hsync_end = 1366 + 40 + 40,
+ .htotal = 1366 + 40 + 40 + 32,
+ .vdisplay = 768,
+ .vsync_start = 768 + 10,
+ .vsync_end = 768 + 10 + 12,
+ .vtotal = 768 + 10 + 12 + 6,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
static const struct drm_display_mode auo_b116xak01_mode = {
.clock = 69300,
.hdisplay = 1366,
@@ -1908,9 +1921,11 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x239b, &delay_200_500_e50,
"B116XAN06.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x255c, &delay_200_500_e50,
"B116XTN02.5"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x403d, &delay_200_500_e50,
"B140HAN04.0"),
- EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, &auo_b116xak01.delay,
"B116XAK01.0"),
+ EDP_PANEL_ENTRY2('A', 'U', 'O', 0x405c, &auo_b116xak01.delay,
"B116XAK01.0",
+&auo_b116xa3_mode),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x582d, &delay_200_500_e50,
"B133UAN01.0"),
- EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, &delay_200_500_e50,
"B116XAN06.1"),
+ EDP_PANEL_ENTRY2('A', 'U', 'O', 0x615c, &delay_200_500_e50,
"B116XAN06.1",
+&auo_b116xa3_mode),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x635c, &delay_200_500_e50,
"B116XAN06.3"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x639c, &delay_200_500_e50,
"B140HAK02.7"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, &delay_200_500_e50,
"B133UAN01.0"),
--
2.43.0.rc0.421.g78406f8d94-goog
[PATCH v7 1/3] drm/panel-edp: Add override_edid_mode quirk for generic edp
Generic edp gets mode from edid. However, some panels report incorrect
mode in this way, resulting in glitches on panel. Introduce a new quirk
additional_mode to the generic edid to pick a correct hardcoded mode.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Douglas Anderson
---
v6->v7: split usecase to another patch.
---
drivers/gpu/drm/panel/panel-edp.c | 48 +--
1 file changed, 45 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index f22677373171..33535f6de343 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -203,6 +203,9 @@ struct edp_panel_entry {
/** @name: Name of this panel (for printing to logs). */
const char *name;
+
+ /** @override_edid_mode: Override the mode obtained by edid. */
+ const struct drm_display_mode *override_edid_mode;
};
struct panel_edp {
@@ -301,6 +304,24 @@ static unsigned int panel_edp_get_display_modes(struct
panel_edp *panel,
return num;
}
+static int panel_edp_override_edid_mode(struct panel_edp *panel,
+ struct drm_connector *connector,
+ const struct drm_display_mode
*override_mode)
+{
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(connector->dev, override_mode);
+ if (!mode) {
+ dev_err(panel->base.dev, "failed to add additional mode\n");
+ return 0;
+ }
+
+ mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+ drm_mode_set_name(mode);
+ drm_mode_probed_add(connector, mode);
+ return 1;
+}
+
static int panel_edp_get_non_edid_modes(struct panel_edp *panel,
struct drm_connector *connector)
{
@@ -568,6 +589,9 @@ static int panel_edp_get_modes(struct drm_panel *panel,
{
struct panel_edp *p = to_panel_edp(panel);
int num = 0;
+ bool has_override_edid_mode = p->detected_panel &&
+ p->detected_panel != ERR_PTR(-EINVAL) &&
+ p->detected_panel->override_edid_mode;
/* probe EDID if a DDC bus is available */
if (p->ddc) {
@@ -575,9 +599,18 @@ static int panel_edp_get_modes(struct drm_panel *panel,
if (!p->edid)
p->edid = drm_get_edid(connector, p->ddc);
-
- if (p->edid)
- num += drm_add_edid_modes(connector, p->edid);
+ if (p->edid) {
+ if (has_override_edid_mode) {
+ /*
+* override_edid_mode is specified. Use
+* override_edid_mode instead of from edid.
+*/
+ num += panel_edp_override_edid_mode(p,
connector,
+
p->detected_panel->override_edid_mode);
+ } else {
+ num += drm_add_edid_modes(connector, p->edid);
+ }
+ }
pm_runtime_mark_last_busy(panel->dev);
pm_runtime_put_autosuspend(panel->dev);
@@ -1849,6 +1882,15 @@ static const struct panel_delay delay_200_150_e200 = {
.delay = _delay \
}
+#define EDP_PANEL_ENTRY2(vend_chr_0, vend_chr_1, vend_chr_2, product_id,
_delay, _name, _mode) \
+{ \
+ .name = _name, \
+ .panel_id = drm_edid_encode_panel_id(vend_chr_0, vend_chr_1,
vend_chr_2, \
+product_id), \
+ .delay = _delay, \
+ .override_edid_mode = _mode \
+}
+
/*
* This table is used to figure out power sequencing delays for panels that
* are detected by EDID. Entries here may point to entries in the
--
2.43.0.rc0.421.g78406f8d94-goog
[PATCH v7 0/3] Use correct mode for edp panel
This series contains 2 part to handle mode selection for edp panel: 1. (patch 1, 2) Add a quirk to override the edid mode for generic edp. 2. (patch 3) If a panel contains hardcoded mode, skip edid mode. Previous versions: v1: https://patchwork.kernel.org/project/dri-devel/cover/20231101212604.1636517-1-hsi...@chromium.org/ v2: https://patchwork.kernel.org/project/dri-devel/cover/20231102221309.1971910-1-hsi...@chromium.org/ v3: https://patchwork.kernel.org/project/dri-devel/cover/20231106202718.2770821-1-hsi...@chromium.org/ v4: https://patchwork.kernel.org/project/dri-devel/cover/20231106210337.2900034-1-hsi...@chromium.org/ v5: https://patchwork.kernel.org/project/dri-devel/cover/2023110723.2928195-1-hsi...@chromium.org/ v6: https://lore.kernel.org/lkml/20231107204611.3082200-2-hsi...@chromium.org/ Hsin-Yi Wang (3): drm/panel-edp: Add override_edid_mode quirk for generic edp drm/panel-edp: Add auo_b116xa3_mode drm/panel-edp: Avoid adding multiple preferred modes drivers/gpu/drm/panel/panel-edp.c | 79 ++- 1 file changed, 68 insertions(+), 11 deletions(-) -- 2.43.0.rc0.421.g78406f8d94-goog
Re: [V3] drm/panel: auo, b101uan08.3: Fine tune the panel power sequence
Hi,
On Mon, Nov 13, 2023 at 8:42 PM Xuxin Xiong
wrote:
>
> For "auo,b101uan08.3" this panel, it is stipulated in the panel spec that
> MIPI needs to keep the LP11 state before the lcm_reset pin is pulled high.
>
> Fixes: 56ad624b4cb5 ("drm/panel: support for auo, b101uan08.3 wuxga dsi video
> mode panel")
> Signed-off-by: Xuxin Xiong
> ---
> Changes in V3:
> - Updated the Fixes tag's style.
> link to V2:
> https://patchwork.kernel.org/project/dri-devel/patch/20231114034505.288569-1-xuxinxi...@huaqin.corp-partner.google.com/
> ---
> Changes in V2:
> - Updated the commit message and added the Fixes tag.
> link to V1:
> https://patchwork.kernel.org/project/dri-devel/patch/20231109092634.1694066-1-xuxinxi...@huaqin.corp-partner.google.com/
> ---
> drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 1 +
> 1 file changed, 1 insertion(+)
In my response to v1 [1] I said you could have just added my
Reviewed-by tag yourself after the problems were fixed. Some
maintainers actually get a bit annoyed when you don't do this, so you
should get in the habit of doing it.
In any case, this looks fine.
Reviewed-by: Douglas Anderson
Pushed to drm-misc-fixes with my tag:
6965809e5269 drm/panel: auo,b101uan08.3: Fine tune the panel power sequence
[1]
https://lore.kernel.org/r/CAD=FV=VxQJFWFaGHD+zpr4dxB85jMQpJiTDAmFZk67CTYNcg=w...@mail.gmail.com/
Re: [PATCH V2 2/5] drm/panel-elida-kd35t133: hold panel in reset for unprepare
On 11/17/2023 11:44 AM, Chris Morgan wrote:
From: Chris Morgan
For devices like the Anbernic RG351M and RG351P the panel is wired to
an always on regulator. When the device suspends and wakes up, there
are some slight artifacts on the screen that go away over time. If
instead we hold the panel in reset status after it is unprepared,
this does not happen.
Fixes: 5b6603360c12 ("drm/panel: add panel driver for Elida KD35T133 panels")
Signed-off-by: Chris Morgan
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
index 6cd8536c09ff..f1fc4a26f447 100644
--- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
+++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
@@ -104,6 +104,8 @@ static int kd35t133_unprepare(struct drm_panel *panel)
return ret;
}
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
regulator_disable(ctx->iovcc);
regulator_disable(ctx->vdd);
--
2.34.1
Re: [PATCH 2/3] fbdev: ssd1307fb: Change "solomon,page-offset" property default value
On Thu, Nov 16, 2023 at 07:07:38PM +0100, Javier Martinez Canillas wrote: > This is used to specify the page start address offset of the display RAM. > > The value is used as offset when setting the page start address with the > SSD130X_SET_PAGE_RANGE command, and the driver currently sets its value to > 1 if the property is not present in the Device Tree. > > But the datasheet mentions that the value on reset for the page start is a > 0, so it makes more sense to also have 0 as the default value for the page > offset if the property is not present. > > In fact, using a default value of 1 leads to the display not working when > the fbdev is attached to the framebuffer console. > > Reported-by: Sahaj Sarup Closes? Fixes? > Signed-off-by: Javier Martinez Canillas -- With Best Regards, Andy Shevchenko
Re: [rft, PATCH v4 00/16] drm/i915/dsi: 4th attempt to get rid of IOSF GPIO
On Thu, Nov 16, 2023 at 09:58:06AM +0100, Hans de Goede wrote: > On 11/3/23 21:18, Andy Shevchenko wrote: > > DSI code for VBT has a set of ugly GPIO hacks, one of which is direct > > talking to GPIO IP behind the actual driver's back. A second attempt > > to fix that is here. > > > > If I understood correctly, my approach should work in the similar way as > > the current IOSF GPIO. > > > > Hans, I believe you have some devices that use this piece of code, > > is it possible to give a test run on (one of) them? > > Ok, this now has been testen on both a BYT and a CHT device which > actually use GPIO controls in their MIPI sequences so this > series is: > > Tested-by: Hans de Goede > > And the code of the entire series also looks good to me: > > Reviewed-by: Hans de Goede > > for the series. Good news so far, thank you! -- With Best Regards, Andy Shevchenko
Re: [rft, PATCH v4 00/16] drm/i915/dsi: 4th attempt to get rid of IOSF GPIO
On Thu, Nov 16, 2023 at 12:15:03PM +0200, Jani Nikula wrote: > On Thu, 16 Nov 2023, Hans de Goede wrote: > > Ok, this now has been testen on both a BYT and a CHT device which > > actually use GPIO controls in their MIPI sequences so this > > series is: > > > > Tested-by: Hans de Goede > > > > And the code of the entire series also looks good to me: > > > > Reviewed-by: Hans de Goede > > > > for the series. > > Thanks Andy & Hans! > > I'll merge this once the test results are in. The BAT results have been > a bit flaky recently, so needed to do a rerun. > > That said, I'm not sure if we have any hardware in CI that would > actually exercise the modifications, so in that sense I trust Hans' > testing much more. Thank you! Should I fix checkpatch warnings CI reported about? -- With Best Regards, Andy Shevchenko
[PATCH V4 3/6] drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support
From: Chris Morgan
Refactor the driver to add support for the powkiddy,rk2023-panel
panel. This panel is extremely similar to the rg353p-panel but
requires a smaller vertical back porch and isn't as tolerant of
higher speeds. Note that while all of these panels are identical in
size (70x57) it is possible future panels may not be.
Tested on my RG351V, RG353P, RG353V, and RK2023.
Signed-off-by: Chris Morgan
Reviewed-by: Jessica Zhang
---
.../gpu/drm/panel/panel-newvision-nv3051d.c | 55 +++
1 file changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
index c44c6945662f..94d89ffd596b 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
@@ -28,6 +28,7 @@ struct nv3051d_panel_info {
unsigned int num_modes;
u16 width_mm, height_mm;
u32 bus_flags;
+ u32 mode_flags;
};
struct panel_nv3051d {
@@ -387,15 +388,7 @@ static int panel_nv3051d_probe(struct mipi_dsi_device *dsi)
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
- MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET;
-
- /*
-* The panel in the RG351V is identical to the 353P, except it
-* requires MIPI_DSI_CLOCK_NON_CONTINUOUS to operate correctly.
-*/
- if (of_device_is_compatible(dev->of_node, "anbernic,rg351v-panel"))
- dsi->mode_flags |= MIPI_DSI_CLOCK_NON_CONTINUOUS;
+ dsi->mode_flags = ctx->panel_info->mode_flags;
drm_panel_init(&ctx->panel, &dsi->dev, &panel_nv3051d_funcs,
DRM_MODE_CONNECTOR_DSI);
@@ -483,16 +476,56 @@ static const struct drm_display_mode
nv3051d_rgxx3_modes[] = {
},
};
-static const struct nv3051d_panel_info nv3051d_rgxx3_info = {
+static const struct drm_display_mode nv3051d_rk2023_modes[] = {
+ {
+ .hdisplay = 640,
+ .hsync_start= 640 + 40,
+ .hsync_end = 640 + 40 + 2,
+ .htotal = 640 + 40 + 2 + 80,
+ .vdisplay = 480,
+ .vsync_start= 480 + 18,
+ .vsync_end = 480 + 18 + 2,
+ .vtotal = 480 + 18 + 2 + 4,
+ .clock = 24150,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ },
+};
+
+static const struct nv3051d_panel_info nv3051d_rg351v_info = {
.display_modes = nv3051d_rgxx3_modes,
.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
.width_mm = 70,
.height_mm = 57,
.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS,
+};
+
+static const struct nv3051d_panel_info nv3051d_rg353p_info = {
+ .display_modes = nv3051d_rgxx3_modes,
+ .num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
+ .width_mm = 70,
+ .height_mm = 57,
+ .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
+};
+
+static const struct nv3051d_panel_info nv3051d_rk2023_info = {
+ .display_modes = nv3051d_rk2023_modes,
+ .num_modes = ARRAY_SIZE(nv3051d_rk2023_modes),
+ .width_mm = 70,
+ .height_mm = 57,
+ .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
};
static const struct of_device_id newvision_nv3051d_of_match[] = {
- { .compatible = "newvision,nv3051d", .data = &nv3051d_rgxx3_info },
+ { .compatible = "anbernic,rg351v-panel", .data = &nv3051d_rg351v_info },
+ { .compatible = "anbernic,rg353p-panel", .data = &nv3051d_rg353p_info },
+ { .compatible = "powkiddy,rk2023-panel", .data = &nv3051d_rk2023_info },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, newvision_nv3051d_of_match);
--
2.34.1
[PATCH V4 6/6] arm64: dts: rockchip: Add Powkiddy RK2023
From: Chris Morgan
Add support for the Powkiddy RK2023. The Powkiddy RK2023 is a handheld
gaming device with a 3.5 inch screen powered by the Rockchip RK3566
SoC. The device looks physically different from the Powkiddy RGB30,
but is functionally identical except for the panel.
Signed-off-by: Chris Morgan
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3566-powkiddy-rk2023.dts | 38 +++
2 files changed, 39 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index a18f33bf0c0e..f969618da352 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rk2023.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-a.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-radxa-cm3-io.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
new file mode 100644
index ..ba32d0793dca
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "rk3566-powkiddy-rk2023.dtsi"
+
+/ {
+ model = "RK2023";
+ compatible = "powkiddy,rk2023", "rockchip,rk3566";
+};
+
+&cru {
+ assigned-clocks = <&pmucru CLK_RTC_32K>, <&cru PLL_GPLL>,
+ <&pmucru PLL_PPLL>, <&cru PLL_VPLL>;
+ assigned-clock-rates = <32768>, <12>,
+ <2>, <11520>;
+};
+
+&dsi0 {
+ panel: panel@0 {
+ compatible = "powkiddy,rk2023-panel", "newvision,nv3051d";
+ reg = <0>;
+ backlight = <&backlight>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rst>;
+ reset-gpios = <&gpio4 RK_PA0 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&vcc3v3_lcd0_n>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
+ };
+};
--
2.34.1
[PATCH V4 1/6] dt-bindings: display: nv3051d: Update NewVision NV3051D compatibles
From: Chris Morgan Update the NewVision NV3051D compatible strings by adding a new panel, the powkiddy,rk2023-panel, and removing another entry, the anbernic,rg353v-panel. The rk2023-panel is similar to the rg353p-panel but has slightly different timings so it needs a new string. The rg353v-panel is duplicate to the rg353p-panel, so remove it. No current devices use it and changes to the driver mean it is no longer valid as a compatible string. Signed-off-by: Chris Morgan Acked-by: Krzysztof Kozlowski --- .../devicetree/bindings/display/panel/newvision,nv3051d.yaml| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml index cce775a87f87..7a634fbc465e 100644 --- a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml +++ b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml @@ -21,7 +21,7 @@ properties: - enum: - anbernic,rg351v-panel - anbernic,rg353p-panel - - anbernic,rg353v-panel + - powkiddy,rk2023-panel - const: newvision,nv3051d reg: true -- 2.34.1
[PATCH V4 4/6] dt-bindings: arm: rockchip: Add Powkiddy RK2023
From: Chris Morgan The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and powered by the Rockchip RK3566 SoC. Group the Powkiddy RK3566 based devices together as they are both extremely similar. Signed-off-by: Chris Morgan Acked-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/arm/rockchip.yaml | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 5f7c6c4aad8f..5b015c4ed775 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -674,9 +674,11 @@ properties: - const: pine64,soquartz - const: rockchip,rk3566 - - description: Powkiddy RGB30 + - description: Powkiddy RK3566 Handheld Gaming Console items: - - const: powkiddy,rgb30 + - enum: + - powkiddy,rgb30 + - powkiddy,rk2023 - const: rockchip,rk3566 - description: Radxa Compute Module 3(CM3) -- 2.34.1
[PATCH V4 0/6] rockchip: Add Powkiddy RK2023
From: Chris Morgan Add support for the Powkiddy RK2023, which is extremely similar to existing Powkiddy RGB30 device. Changes since V3: - Corrected commit subject lines. Changes since V2: - Split "hold panel in reset" to a separate patch for the NV3051D. - Changed replaced common include to a new Powkiddy specific include to better reflect the similarity of these two devices (and so as to not have to delete so many nodes). Changes since V1: - Necessary clock changes have been accepted to mainline, so removed from this series. https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=f1db0865b4628d5e2e85347350c077a71f0629d2 - Combined Powkiddy RK3566 devices in devicetree documentation. Dropped ack from binding as this change is vastly different than the previous update. - Updated panel driver to hold panel in reset status after unprepare. Chris Morgan (6): dt-bindings: display: panel: Update NewVision NV3051D compatibles drm/panel: nv3051d: Hold panel in reset for unprepare nv3051d: Add Powkiddy RK2023 Panel Support dt-bindings: arm: rockchip: Add Powkiddy RK2023 arm64: dts: rockchip: Update powkiddy,rgb30 include to rk2023 DTSI arm: dts: rockchip: Add Powkiddy RK2023 .../devicetree/bindings/arm/rockchip.yaml | 6 +- .../display/panel/newvision,nv3051d.yaml | 2 +- arch/arm64/boot/dts/rockchip/Makefile | 1 + .../dts/rockchip/rk3566-powkiddy-rgb30.dts| 154 +-- .../dts/rockchip/rk3566-powkiddy-rk2023.dts | 38 + .../dts/rockchip/rk3566-powkiddy-rk2023.dtsi | 875 ++ .../gpu/drm/panel/panel-newvision-nv3051d.c | 57 +- 7 files changed, 981 insertions(+), 152 deletions(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dtsi -- 2.34.1
[PATCH V4 5/6] arm64: dts: rockchip: Update powkiddy, rgb30 include to rk2023 DTSI
From: Chris Morgan
The Powkiddy RGB30 device is similar to the Anbernic RGxx3 series,
however there are several differences which require deleting nodes in
order to properly define the hardware. This was deemed unacceptable
for the RK2023, so instead create a common include file for the
Powkiddy RGB30 and the Powkiddy RK2023. The only notable difference
between these Powkiddy devices are the panel in use, the device
name, and the PLL_VPLL frequency necessary to support the different
panels.
Since the RK2023 was released on the market first, name the common
include file after it.
Signed-off-by: Chris Morgan
---
.../dts/rockchip/rk3566-powkiddy-rgb30.dts| 154 +--
.../dts/rockchip/rk3566-powkiddy-rk2023.dtsi | 875 ++
2 files changed, 891 insertions(+), 138 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
index 1ead3c5c24b3..0ac64f043b80 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
@@ -5,67 +5,11 @@
#include
#include
#include
-#include "rk3566-anbernic-rg353x.dtsi"
+#include "rk3566-powkiddy-rk2023.dtsi"
/ {
model = "RGB30";
compatible = "powkiddy,rgb30", "rockchip,rk3566";
-
- aliases {
- mmc1 = &sdmmc0;
- mmc2 = &sdmmc1;
- mmc3 = &sdmmc2;
- };
-
- battery: battery {
- compatible = "simple-battery";
- charge-full-design-microamp-hours = <3151000>;
- charge-term-current-microamp = <30>;
- constant-charge-current-max-microamp = <200>;
- constant-charge-voltage-max-microvolt = <425>;
- factory-internal-resistance-micro-ohms = <117000>;
- voltage-max-design-microvolt = <4172000>;
- voltage-min-design-microvolt = <340>;
-
- ocv-capacity-celsius = <20>;
- ocv-capacity-table-0 = <4172000 100>, <4092000 95>, <4035000
90>, <399 85>,
- <3939000 80>, <3895000 75>, <3852000
70>, <3807000 65>,
- <3762000 60>, <3713000 55>, <3672000
50>, <3647000 45>,
- <3629000 40>, <3613000 35>, <3598000
30>, <3578000 25>,
- <355 20>, <3519000 15>, <3479000
10>, <3438000 5>,
- <340 0>;
- };
-
- /*
-* Channels reversed for speakers. Headphones automatically switch via
hardware when
-* detected with no ability to control output in software. Headphones
appear to be mono
-* (each output channel receives all audio). No microphone support on
3.5mm jack.
-*/
- sound {
- compatible = "simple-audio-card";
- simple-audio-card,name = "rk817_ext";
- simple-audio-card,format = "i2s";
- simple-audio-card,mclk-fs = <256>;
- simple-audio-card,widgets =
- "Headphone", "Headphones";
- simple-audio-card,routing =
- "Headphones", "HPOL",
- "Headphones", "HPOR";
-
- simple-audio-card,codec {
- sound-dai = <&rk817>;
- };
-
- simple-audio-card,cpu {
- sound-dai = <&i2s1_8ch>;
- };
- };
-};
-
-/delete-node/ &adc_keys;
-
-&chosen {
- /delete-property/ stdout-path;
};
&cru {
@@ -75,87 +19,21 @@ &cru {
<2>, <29250>;
};
-&gpio_keys_control {
- button-r1 {
- gpios = <&gpio3 RK_PB3 GPIO_ACTIVE_LOW>;
- label = "TR";
- linux,code = ;
- };
-
- button-r2 {
- gpios = <&gpio3 RK_PB4 GPIO_ACTIVE_LOW>;
- label = "TR2";
- linux,code = ;
- };
-};
-
-/delete-node/ &{/i2c@fdd4/regulator@40};
-
-&i2c0 {
- vdd_cpu: regulator@1c {
- compatible = "tcs,tcs4525";
- reg = <0x1c>;
- fcs,suspend-voltage-selector = <1>;
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <712500>;
- regulator-max-microvolt = <139>;
- regulator-name = "vdd_cpu";
- regulator-ramp-delay = <2300>;
- vin-supply = <&vcc_sys>;
- regulator-state-mem {
- regulator-off-in-suspend;
+&dsi0 {
+ panel: panel@0 {
+ compatible = "powkiddy,rgb30-panel";
+ reg = <0>;
+ backlight = <&backlight>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rst>;
+
[PATCH V4 2/6] drm/panel: nv3051d: Hold panel in reset for unprepare
From: Chris Morgan
Improve the panel's ability to restore from suspend by holding the
panel in suspend after unprepare.
Fixes: b1d39f0f4264 ("drm/panel: Add NewVision NV3051D MIPI-DSI LCD panel")
Signed-off-by: Chris Morgan
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/panel/panel-newvision-nv3051d.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
index 79de6c886292..c44c6945662f 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
@@ -261,6 +261,8 @@ static int panel_nv3051d_unprepare(struct drm_panel *panel)
usleep_range(1, 15000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
regulator_disable(ctx->vdd);
return 0;
--
2.34.1
[PATCH V2 1/5] drm/panel-elida-kd35t133: trival: update panel size from 5.5 to 3.5
From: Chris Morgan The comments at the top of the driver state the panel size incorrectly as 5.5" instead of 3.5". Signed-off-by: Chris Morgan Reviewed-by: Jessica Zhang --- drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c b/drivers/gpu/drm/panel/panel-elida-kd35t133.c index e7be15b68102..6cd8536c09ff 100644 --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Elida kd35t133 5.5" MIPI-DSI panel driver + * Elida kd35t133 3.5" MIPI-DSI panel driver * Copyright (C) 2020 Theobroma Systems Design und Consulting GmbH * * based on -- 2.34.1
[PATCH V2 3/5] drm/panel-elida-kd35t133: drop drm_connector_set_orientation_from_panel
From: Chris Morgan Stop calling drm_connector_set_orientation_from_panel() as its now called by the panel bridge directly when it is initialized. Signed-off-by: Chris Morgan Reviewed-by: Jessica Zhang --- drivers/gpu/drm/panel/panel-elida-kd35t133.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c b/drivers/gpu/drm/panel/panel-elida-kd35t133.c index f1fc4a26f447..29b4ee63d83b 100644 --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c @@ -211,11 +211,6 @@ static int kd35t133_get_modes(struct drm_panel *panel, connector->display_info.width_mm = mode->width_mm; connector->display_info.height_mm = mode->height_mm; drm_mode_probed_add(connector, mode); - /* -* TODO: Remove once all drm drivers call -* drm_connector_set_orientation_from_panel() -*/ - drm_connector_set_panel_orientation(connector, ctx->orientation); return 1; } -- 2.34.1
[PATCH V2 2/5] drm/panel-elida-kd35t133: hold panel in reset for unprepare
From: Chris Morgan
For devices like the Anbernic RG351M and RG351P the panel is wired to
an always on regulator. When the device suspends and wakes up, there
are some slight artifacts on the screen that go away over time. If
instead we hold the panel in reset status after it is unprepared,
this does not happen.
Fixes: 5b6603360c12 ("drm/panel: add panel driver for Elida KD35T133 panels")
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
index 6cd8536c09ff..f1fc4a26f447 100644
--- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
+++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
@@ -104,6 +104,8 @@ static int kd35t133_unprepare(struct drm_panel *panel)
return ret;
}
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
regulator_disable(ctx->iovcc);
regulator_disable(ctx->vdd);
--
2.34.1
[PATCH V2 5/5] drm/panel-elida-kd35t133: Drop prepare/unprepare logic
From: Chris Morgan
Drop the prepare/unprepare logic, as this is now tracked elsewhere
since this commit [1].
[1] commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in
drm_panel")
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
index fea3d9e84905..00791ea81e90 100644
--- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
+++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
@@ -43,7 +43,6 @@ struct kd35t133 {
struct regulator *vdd;
struct regulator *iovcc;
enum drm_panel_orientation orientation;
- bool prepared;
};
static inline struct kd35t133 *panel_to_kd35t133(struct drm_panel *panel)
@@ -91,9 +90,6 @@ static int kd35t133_unprepare(struct drm_panel *panel)
struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
int ret;
- if (!ctx->prepared)
- return 0;
-
ret = mipi_dsi_dcs_set_display_off(dsi);
if (ret < 0)
dev_err(ctx->dev, "failed to set display off: %d\n", ret);
@@ -109,8 +105,6 @@ static int kd35t133_unprepare(struct drm_panel *panel)
regulator_disable(ctx->iovcc);
regulator_disable(ctx->vdd);
- ctx->prepared = false;
-
return 0;
}
@@ -120,9 +114,6 @@ static int kd35t133_prepare(struct drm_panel *panel)
struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
int ret;
- if (ctx->prepared)
- return 0;
-
dev_dbg(ctx->dev, "Resetting the panel\n");
ret = regulator_enable(ctx->vdd);
if (ret < 0) {
@@ -166,8 +157,6 @@ static int kd35t133_prepare(struct drm_panel *panel)
msleep(50);
- ctx->prepared = true;
-
return 0;
disable_iovcc:
--
2.34.1
[PATCH V2 4/5] drm/panel-elida-kd35t133: Drop shutdown logic
From: Chris Morgan
The driver shutdown is duplicate as it calls drm_unprepare and
drm_disable which are called anyway when associated drivers are
shutdown/removed.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
index 29b4ee63d83b..fea3d9e84905 100644
--- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
+++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
@@ -296,27 +296,11 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
return 0;
}
-static void kd35t133_shutdown(struct mipi_dsi_device *dsi)
-{
- struct kd35t133 *ctx = mipi_dsi_get_drvdata(dsi);
- int ret;
-
- ret = drm_panel_unprepare(&ctx->panel);
- if (ret < 0)
- dev_err(&dsi->dev, "Failed to unprepare panel: %d\n", ret);
-
- ret = drm_panel_disable(&ctx->panel);
- if (ret < 0)
- dev_err(&dsi->dev, "Failed to disable panel: %d\n", ret);
-}
-
static void kd35t133_remove(struct mipi_dsi_device *dsi)
{
struct kd35t133 *ctx = mipi_dsi_get_drvdata(dsi);
int ret;
- kd35t133_shutdown(dsi);
-
ret = mipi_dsi_detach(dsi);
if (ret < 0)
dev_err(&dsi->dev, "Failed to detach from DSI host: %d\n", ret);
@@ -337,7 +321,6 @@ static struct mipi_dsi_driver kd35t133_driver = {
},
.probe = kd35t133_probe,
.remove = kd35t133_remove,
- .shutdown = kd35t133_shutdown,
};
module_mipi_dsi_driver(kd35t133_driver);
--
2.34.1
[PATCH V2 0/5] Elida KD35T133 Panel Improvements
From: Chris Morgan Fix a few bugs and clean up no longer needed code on the Elida KD35T133 DSI panel, as used in devices such as the Odroid Go Advance and the Anbernic RG351M. Changes since V1: - Split removal of shutdown logic into a new patch independent of dropping of prepared tracking. - Added fixes to patch holding panel in reset after unprepare. Chris Morgan (5): drm/panel-elida-kd35t133: trival: update panel size from 5.5 to 3.5 drm/panel-elida-kd35t133: hold panel in reset for unprepare drm/panel-elida-kd35t133: drop drm_connector_set_orientation_from_panel drm/panel-elida-kd35t133: Drop shutdown logic drm/panel-elida-kd35t133: Drop prepare/unprepare logic drivers/gpu/drm/panel/panel-elida-kd35t133.c | 37 ++-- 1 file changed, 3 insertions(+), 34 deletions(-) -- 2.34.1
Re: [Intel-gfx] [PATCH v3 02/11] drm/dp_mst: Fix PBN divider calculation for UHBR rates
On Fri, Nov 17, 2023 at 06:21:07PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 17, 2023 at 05:09:27PM +0200, Imre Deak wrote:
> > The current way of calculating the pbn_div value, the link BW per each
> > MTP slot, worked only for DP 1.4 link rates. Fix things up for UHBR
> > rates calculating with the correct channel coding efficiency based on
> > the link rate.
> >
> > v2:
> > - Return the fractional pbn_div value from drm_dp_get_vc_payload_bw().
> > v3:
> > - Fix rounding up quotient while calculating req_slots. (Ville)
> >
> > Cc: Ville Syrjälä
> > Cc: Lyude Paul
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Imre Deak
>
> Reviewed-by: Ville Syrjälä
Dave, Sima, it looks like this whole series is ready for getting merged:
https://patchwork.freedesktop.org/series/126526/
But it has these 3 drm/dp_mst here.
Ack to merge them through drm-intel?
>
> > ---
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 10 +++---
> > include/drm/display/drm_dp_helper.h | 13 +
> > 2 files changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 000d05e80352a..8ca01a6bf645d 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -3585,14 +3585,18 @@ static int drm_dp_send_up_ack_reply(struct
> > drm_dp_mst_topology_mgr *mgr,
> > fixed20_12 drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr
> > *mgr,
> > int link_rate, int link_lane_count)
> > {
> > + int ch_coding_efficiency =
> > +
> > drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(link_rate));
> > fixed20_12 ret;
> >
> > if (link_rate == 0 || link_lane_count == 0)
> > drm_dbg_kms(mgr->dev, "invalid link rate/lane count: (%d /
> > %d)\n",
> > link_rate, link_lane_count);
> >
> > - /* See DP v2.0 2.6.4.2,
> > VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
> > - ret.full = dfixed_const(link_rate * link_lane_count / 54000);
> > + /* See DP v2.0 2.6.4.2, 2.7.6.3
> > VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
> > + ret.full = DIV_ROUND_DOWN_ULL(mul_u32_u32(link_rate * link_lane_count,
> > + ch_coding_efficiency),
> > + (100ULL * 8 * 5400) >> 12);
> >
> > return ret;
> > }
> > @@ -4342,7 +4346,7 @@ int drm_dp_atomic_find_time_slots(struct
> > drm_atomic_state *state,
> > }
> > }
> >
> > - req_slots = DIV_ROUND_UP(pbn, dfixed_trunc(topology_state->pbn_div));
> > + req_slots = DIV_ROUND_UP(dfixed_const(pbn),
> > topology_state->pbn_div.full);
> >
> > drm_dbg_atomic(mgr->dev, "[CONNECTOR:%d:%s] [MST PORT:%p] TU %d ->
> > %d\n",
> >port->connector->base.id, port->connector->name,
> > diff --git a/include/drm/display/drm_dp_helper.h
> > b/include/drm/display/drm_dp_helper.h
> > index c5f1079acb3b1..863b2e7add29e 100644
> > --- a/include/drm/display/drm_dp_helper.h
> > +++ b/include/drm/display/drm_dp_helper.h
> > @@ -252,6 +252,19 @@ drm_edp_backlight_supported(const u8
> > edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE])
> > return !!(edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP);
> > }
> >
> > +/**
> > + * drm_dp_is_uhbr_rate - Determine if a link rate is UHBR
> > + * @link_rate: link rate in 10kbits/s units
> > + *
> > + * Determine if the provided link rate is an UHBR rate.
> > + *
> > + * Returns: %True if @link_rate is an UHBR rate.
> > + */
> > +static inline bool drm_dp_is_uhbr_rate(int link_rate)
> > +{
> > + return link_rate >= 100;
> > +}
> > +
> > /*
> > * DisplayPort AUX channel
> > */
> > --
> > 2.39.2
>
> --
> Ville Syrjälä
> Intel
Re: [PATCH] drm/rockchip: lvds: do not print error message when deferring probe
Hi Quentin,
On Fri, Nov 17, 2023 at 3:31 PM Quentin Schulz wrote:
>
> From: Quentin Schulz
>
> This scary message may happen if the panel or bridge is not probed
> before the LVDS controller is, resulting in some head scratching because
> the LVDS panel is actually working, since a later try will eventually
> find the panel or bridge.
>
> Therefore let's demote this error message into a debug message to not
> scare users unnecessarily.
...
> diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c
> b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> index f0f47e9abf5a..52e2ce2a61a8 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> @@ -577,7 +577,7 @@ static int rockchip_lvds_bind(struct device *dev, struct
> device *master,
> ret = -EINVAL;
> goto err_put_port;
> } else if (ret) {
> - DRM_DEV_ERROR(dev, "failed to find panel and bridge node\n");
> + DRM_DEV_DEBUG(dev, "failed to find panel and bridge node\n");
> ret = -EPROBE_DEFER;
What about using dev_err_probe() instead?
Re: [PATCH v5 09/32] drm/amd/display: add plane 3D LUT driver-specific properties
On 2023-11-16 14:57, Melissa Wen wrote:
Add 3D LUT property for plane color transformations using a 3D lookup
table. 3D LUT allows for highly accurate and complex color
transformations and is suitable to adjust the balance between color
channels. It's also more complex to manage and require more
computational resources.
Since a 3D LUT has a limited number of entries in each dimension we want
to use them in an optimal fashion. This means using the 3D LUT in a
colorspace that is optimized for human vision, such as sRGB, PQ, or
another non-linear space. Therefore, userpace may need one 1D LUT
(shaper) before it to delinearize content and another 1D LUT after 3D
LUT (blend) to linearize content again for blending. The next patches
add these 1D LUTs to the plane color mgmt pipeline.
v3:
- improve commit message about 3D LUT
- describe the 3D LUT entries and size (Harry)
v4:
- advertise 3D LUT max size as the size of a single-dimension
v5:
- get lut3d blob correctly (Joshua)
- fix doc about 3d-lut dimension size (Sebastian)
Signed-off-by: Melissa Wen
Reviewed-by: Harry Wentland
We'll run this series through our testing. If that doesn't show
problems and if I don't see any new comments on the series I'm
planning to merge it through amd-staging-drm-next.
Harry
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 18 ++
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 9 +++
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 14 +++
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 24 +++
4 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index ee67c5adf0f1..57822477408f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -364,6 +364,24 @@ struct amdgpu_mode_info {
* @plane_hdr_mult_property:
*/
struct drm_property *plane_hdr_mult_property;
+ /**
+* @plane_lut3d_property: Plane property for color transformation using
+* a 3D LUT (pre-blending), a three-dimensional array where each
+* element is an RGB triplet. Each dimension has the size of
+* lut3d_size. The array contains samples from the approximated
+* function. On AMD, values between samples are estimated by
+* tetrahedral interpolation. The array is accessed with three indices,
+* one for each input dimension (color channel), blue being the
+* outermost dimension, red the innermost.
+*/
+ struct drm_property *plane_lut3d_property;
+ /**
+* @plane_degamma_lut_size_property: Plane property to define the max
+* size of 3D LUT as supported by the driver (read-only). The max size
+* is the max size of one dimension and, therefore, the max number of
+* entries for 3D LUT array is the 3D LUT size cubed;
+*/
+ struct drm_property *plane_lut3d_size_property;
};
#define AMDGPU_MAX_BL_LEVEL 0xFF
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 38163b7084fa..03b48b331b7c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -776,6 +776,11 @@ struct dm_plane_state {
* TF is needed for any subsequent linear-to-non-linear transforms.
*/
__u64 hdr_mult;
+ /**
+* @lut3d: 3D lookup table blob. The blob (if not NULL) is an array of
+* &struct drm_color_lut.
+*/
+ struct drm_property_blob *lut3d;
};
struct dm_crtc_state {
@@ -861,6 +866,10 @@ void amdgpu_dm_update_freesync_caps(struct drm_connector
*connector,
void amdgpu_dm_trigger_timing_sync(struct drm_device *dev);
+/* 3D LUT max size is 17x17x17 (4913 entries) */
+#define MAX_COLOR_3DLUT_SIZE 17
+#define MAX_COLOR_3DLUT_BITDEPTH 12
+/* 1D LUT size */
#define MAX_COLOR_LUT_ENTRIES 4096
/* Legacy gamm LUT users such as X doesn't like large LUT sizes */
#define MAX_COLOR_LEGACY_LUT_ENTRIES 256
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index b5b34a9209e4..a3b4f6a4c4a8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -231,6 +231,20 @@ amdgpu_dm_create_color_properties(struct amdgpu_device
*adev)
return -ENOMEM;
adev->mode_info.plane_hdr_mult_property = prop;
+ prop = drm_property_create(adev_to_drm(adev),
+ DRM_MODE_PROP_BLOB,
+ "AMD_PLANE_LUT3D", 0);
+ if (!prop)
+ return -ENOMEM;
+ adev->mode_info.plane_lut3d_property = prop;
+
+ prop = drm_property_create_range(adev_to_drm(adev),
+DRM_MODE_PROP_IMMUTABLE,
+
Re: [PATCH v7 6/8] drm/ttm/tests: Test simple BO creation and validation
Hi Karolina,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.7-rc1 next-20231117]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Karolina-Stolarek/drm-ttm-tests-Add-tests-for-ttm_resource-and-ttm_sys_man/20231117-165755
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/fe0d1ba291b12e7b4671bee8b95812ac30a469df.1700207346.git.karolina.stolarek%40intel.com
patch subject: [PATCH v7 6/8] drm/ttm/tests: Test simple BO creation and
validation
config: x86_64-randconfig-122-20231117
(https://download.01.org/0day-ci/archive/20231118/202311180247.4a61hkyg-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20231118/202311180247.4a61hkyg-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202311180247.4a61hkyg-...@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c:98:9: sparse: sparse: cast
>> removes address space '__rcu' of expression
>> drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c:98:9: sparse: sparse: cast
>> removes address space '__rcu' of expression
vim +/__rcu +98 drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
59
60 KUNIT_ARRAY_PARAM(ttm_bo_types, ttm_bo_type_cases,
61ttm_bo_validate_case_desc);
62
63 static void ttm_bo_init_reserved_sys_man(struct kunit *test)
64 {
65 const struct ttm_bo_validate_test_case *params =
test->param_value;
66 struct ttm_test_devices *priv = test->priv;
67 struct ttm_buffer_object *bo;
68 struct ttm_place *place;
69 struct ttm_placement *placement;
70 enum ttm_bo_type bo_type = params->bo_type;
71 struct ttm_operation_ctx ctx = { };
72 uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
73 int err;
74
75 bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
76 KUNIT_ASSERT_NOT_NULL(test, bo);
77
78 place = ttm_place_kunit_init(test, TTM_PL_SYSTEM, 0);
79 placement = ttm_placement_kunit_init(test, place, 1, NULL, 0);
80
81 drm_gem_private_object_init(priv->drm, &bo->base, size);
82
83 err = ttm_bo_init_reserved(priv->ttm_dev, bo, bo_type,
placement,
84 PAGE_SIZE, &ctx, NULL, NULL,
85 &dummy_ttm_bo_destroy);
86 dma_resv_unlock(bo->base.resv);
87
88 KUNIT_EXPECT_EQ(test, err, 0);
89 KUNIT_EXPECT_EQ(test, kref_read(&bo->kref), 1);
90 KUNIT_EXPECT_PTR_EQ(test, bo->bdev, priv->ttm_dev);
91 KUNIT_EXPECT_EQ(test, bo->type, bo_type);
92 KUNIT_EXPECT_EQ(test, bo->page_alignment, PAGE_SIZE);
93 KUNIT_EXPECT_PTR_EQ(test, bo->destroy, &dummy_ttm_bo_destroy);
94 KUNIT_EXPECT_EQ(test, bo->pin_count, 0);
95 KUNIT_EXPECT_NULL(test, bo->bulk_move);
96 KUNIT_EXPECT_NOT_NULL(test, bo->ttm);
97 KUNIT_EXPECT_FALSE(test, ttm_tt_is_populated(bo->ttm));
> 98 KUNIT_EXPECT_NOT_NULL(test, (void *)bo->base.resv->fences);
99 KUNIT_EXPECT_EQ(test, ctx.bytes_moved, size);
100
101 if (bo_type != ttm_bo_type_kernel)
102 KUNIT_EXPECT_TRUE(test,
103
drm_mm_node_allocated(&bo->base.vma_node.vm_node));
104
105 ttm_resource_free(bo, &bo->resource);
106 ttm_bo_put(bo);
107 }
108
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH] dma-buf: Replace strlcpy() with strscpy()
On Thu, Nov 16, 2023 at 11:14 AM Kees Cook wrote:
>
> strlcpy() reads the entire source buffer first. This read may exceed
> the destination size limit. This is both inefficient and can lead
> to linear read overflows if a source string is not NUL-terminated[1].
> Additionally, it returns the size of the source string, not the
> resulting size of the destination string. In an effort to remove strlcpy()
> completely[2], replace strlcpy() here with strscpy().
>
> Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
> [1]
> Link: https://github.com/KSPP/linux/issues/89 [2]
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: Azeem Shaikh
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Kees Cook
Reviewed-by: T.J. Mercier
strscpy returns -E2BIG when it truncates / force null-terminates which
would provide the wrong argument for dynamic_dname, but
dma_buf_set_name{_user} makes sure we have a null-terminated string of
the appropriate maximum size in dmabuf->name.
[PATCH] drm/rockchip: lvds: do not print error message when deferring probe
From: Quentin Schulz
This scary message may happen if the panel or bridge is not probed
before the LVDS controller is, resulting in some head scratching because
the LVDS panel is actually working, since a later try will eventually
find the panel or bridge.
Therefore let's demote this error message into a debug message to not
scare users unnecessarily.
Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
---
drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index f0f47e9abf5a..52e2ce2a61a8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -577,7 +577,7 @@ static int rockchip_lvds_bind(struct device *dev, struct
device *master,
ret = -EINVAL;
goto err_put_port;
} else if (ret) {
- DRM_DEV_ERROR(dev, "failed to find panel and bridge node\n");
+ DRM_DEV_DEBUG(dev, "failed to find panel and bridge node\n");
ret = -EPROBE_DEFER;
goto err_put_port;
}
---
base-commit: 7475e51b87969e01a6812eac713a1c8310372e8a
change-id: 20231117-rk-lvds-defer-msg-b2944b73d791
Best regards,
--
Quentin Schulz
Re: [PATCH v3 1/1] backlight: pwm_bl: Use dev_err_probe
Hello Alexander, On Fri, Nov 17, 2023 at 01:06:25PM +0100, Alexander Stein wrote: > Use dev_err_probe to simplify error paths. Also let dev_err_probe handle > the -EPROBE_DEFER case and add an entry to > /sys/kernel/debug/devices_deferred when deferred. > > Signed-off-by: Alexander Stein Reviewed-by: Uwe Kleine-König Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH] accel/qaic: Update MAX_ORDER use to be inclusive
On 11/3/2023 9:33 AM, Jeffrey Hugo wrote:
MAX_ORDER was redefined so that valid allocations to the page allocator
are in the range of 0..MAX_ORDER, inclusive in the commit
23baf831a32c ("mm, treewide: redefine MAX_ORDER sanely").
We are treating MAX_ORDER as an exclusive value, and thus could be
requesting larger allocations. Update our use to match the redefinition
of MAX_ORDER.
Signed-off-by: Jeffrey Hugo
Reviewed-by: Pranjal Ramajor Asha Kanojiya
Reviewed-by: Carl Vanderlip
Applied to drm-misc-next
-Jeff
[PATCH 1/2] accel/qaic: Increase number of in_reset states
From: Carl Vanderlip
'in_reset' holds the state of the device. As part of bringup, the device
needs to be queried to check if it's in a valid state. Add a new state
that indicates that the device is coming up, but not ready for users
yet. Rename to 'reset_state' to better describe the variable.
Signed-off-by: Carl Vanderlip
Reviewed-by: Pranjal Ramajor Asha Kanojiya
Reviewed-by: Jeffrey Hugo
Signed-off-by: Jeffrey Hugo
---
drivers/accel/qaic/qaic.h | 13 +++--
drivers/accel/qaic/qaic_control.c | 5 +++--
drivers/accel/qaic/qaic_data.c| 16
drivers/accel/qaic/qaic_drv.c | 12 ++--
4 files changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/accel/qaic/qaic.h b/drivers/accel/qaic/qaic.h
index bc40d52dc010..bd0c884e6bf7 100644
--- a/drivers/accel/qaic/qaic.h
+++ b/drivers/accel/qaic/qaic.h
@@ -31,6 +31,15 @@
#define to_drm(qddev) (&(qddev)->drm)
#define to_accel_kdev(qddev) (to_drm(qddev)->accel->kdev) /* Return Linux
device of accel node */
+enum __packed reset_states {
+ /* Device is offline or will be very soon */
+ QAIC_OFFLINE,
+ /* Device is booting, not clear if it's in a usable state */
+ QAIC_BOOT,
+ /* Device is fully operational */
+ QAIC_ONLINE,
+};
+
extern bool datapath_polling;
struct qaic_user {
@@ -121,8 +130,8 @@ struct qaic_device {
struct workqueue_struct *cntl_wq;
/* Synchronizes all the users of device during cleanup */
struct srcu_struct dev_lock;
- /* true: Device under reset; false: Device not under reset */
- boolin_reset;
+ /* Track the state of the device during resets */
+ enum reset_states reset_state;
/* true: single MSI is used to operate device */
boolsingle_msi;
/*
diff --git a/drivers/accel/qaic/qaic_control.c
b/drivers/accel/qaic/qaic_control.c
index 84915824be54..0701d2deee08 100644
--- a/drivers/accel/qaic/qaic_control.c
+++ b/drivers/accel/qaic/qaic_control.c
@@ -1022,7 +1022,8 @@ static void *msg_xfer(struct qaic_device *qdev, struct
wrapper_list *wrappers, u
int xfer_count = 0;
int retry_count;
- if (qdev->in_reset) {
+ /* Allow QAIC_BOOT state since we need to check control protocol
version */
+ if (qdev->reset_state == QAIC_OFFLINE) {
mutex_unlock(&qdev->cntl_mutex);
return ERR_PTR(-ENODEV);
}
@@ -1306,7 +1307,7 @@ int qaic_manage_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_
qdev = usr->qddev->qdev;
qdev_rcu_id = srcu_read_lock(&qdev->dev_lock);
- if (qdev->in_reset) {
+ if (qdev->reset_state != QAIC_ONLINE) {
srcu_read_unlock(&qdev->dev_lock, qdev_rcu_id);
srcu_read_unlock(&usr->qddev_lock, usr_rcu_id);
return -ENODEV;
diff --git a/drivers/accel/qaic/qaic_data.c b/drivers/accel/qaic/qaic_data.c
index 8da81768f2ab..28643a47c405 100644
--- a/drivers/accel/qaic/qaic_data.c
+++ b/drivers/accel/qaic/qaic_data.c
@@ -690,7 +690,7 @@ int qaic_create_bo_ioctl(struct drm_device *dev, void
*data, struct drm_file *fi
qdev = usr->qddev->qdev;
qdev_rcu_id = srcu_read_lock(&qdev->dev_lock);
- if (qdev->in_reset) {
+ if (qdev->reset_state != QAIC_ONLINE) {
ret = -ENODEV;
goto unlock_dev_srcu;
}
@@ -749,7 +749,7 @@ int qaic_mmap_bo_ioctl(struct drm_device *dev, void *data,
struct drm_file *file
qdev = usr->qddev->qdev;
qdev_rcu_id = srcu_read_lock(&qdev->dev_lock);
- if (qdev->in_reset) {
+ if (qdev->reset_state != QAIC_ONLINE) {
ret = -ENODEV;
goto unlock_dev_srcu;
}
@@ -970,7 +970,7 @@ int qaic_attach_slice_bo_ioctl(struct drm_device *dev, void
*data, struct drm_fi
qdev = usr->qddev->qdev;
qdev_rcu_id = srcu_read_lock(&qdev->dev_lock);
- if (qdev->in_reset) {
+ if (qdev->reset_state != QAIC_ONLINE) {
ret = -ENODEV;
goto unlock_dev_srcu;
}
@@ -1341,7 +1341,7 @@ static int __qaic_execute_bo_ioctl(struct drm_device
*dev, void *data, struct dr
qdev = usr->qddev->qdev;
qdev_rcu_id = srcu_read_lock(&qdev->dev_lock);
- if (qdev->in_reset) {
+ if (qdev->reset_state != QAIC_ONLINE) {
ret = -ENODEV;
goto unlock_dev_srcu;
}
@@ -1497,7 +1497,7 @@ void irq_polling_work(struct work_struct *work)
rcu_id = srcu_read_lock(&dbc->ch_lock);
while (1) {
- if (dbc->qdev->in_reset) {
+ if (dbc->qdev->reset_state != QAIC_ONLINE) {
srcu_read_unlock(&dbc->ch_lock, rcu_id);
return;
}
@@ -1687,7 +1687,7 @@ int qaic_wait_bo_ioctl(struct drm_device *dev, void
*data, struct drm_file *file
qdev = usr->qddev
[PATCH 2/2] accel/qaic: Expand DRM device lifecycle
From: Carl Vanderlip
Currently the QAIC DRM device registers itself when the MHI QAIC_CONTROL
channel becomes available. This is when the device is able to process
workloads. However, the DRM driver also provides the debugfs interface
bootlog for the device. If the device fails to boot to the QSM (which
brings up the MHI QAIC_CONTROL channel), the bootlog won't be available for
debugging why it failed to boot.
Change when the DRM device registers itself from when QAIC_CONTROL is
available to when the card is first probed on the PCI bus. Additionally,
make the DRM driver persist through reset/error cases so the driver
doesn't have to be reloaded to access the card again. Send
KOBJ_ONLINE/OFFLINE uevents so userspace can know when DRM device is
ready to handle requests.
Signed-off-by: Carl Vanderlip
Reviewed-by: Pranjal Ramajor Asha Kanojiya
Reviewed-by: Jeffrey Hugo
Signed-off-by: Jeffrey Hugo
---
Documentation/accel/qaic/qaic.rst | 9 +-
drivers/accel/qaic/mhi_controller.c | 2 +-
drivers/accel/qaic/qaic.h | 2 +-
drivers/accel/qaic/qaic_drv.c | 44 +++--
4 files changed, 27 insertions(+), 30 deletions(-)
diff --git a/Documentation/accel/qaic/qaic.rst
b/Documentation/accel/qaic/qaic.rst
index f81020736ebf..efb7771273bb 100644
--- a/Documentation/accel/qaic/qaic.rst
+++ b/Documentation/accel/qaic/qaic.rst
@@ -93,8 +93,15 @@ commands (does not impact QAIC).
uAPI
+QAIC creates an accel device per phsyical PCIe device. This accel device exists
+for as long as the PCIe device is known to Linux.
+
+The PCIe device may not be in the state to accept requests from userspace at
+all times. QAIC will trigger KOBJ_ONLINE/OFFLINE uevents to advertise when the
+device can accept requests (ONLINE) and when the device is no longer accepting
+requests (OFFLINE) because of a reset or other state transition.
+
QAIC defines a number of driver specific IOCTLs as part of the userspace API.
-This section describes those APIs.
DRM_IOCTL_QAIC_MANAGE
This IOCTL allows userspace to send a NNC request to the QSM. The call will
diff --git a/drivers/accel/qaic/mhi_controller.c
b/drivers/accel/qaic/mhi_controller.c
index 5d3cc30009cc..832464f2833a 100644
--- a/drivers/accel/qaic/mhi_controller.c
+++ b/drivers/accel/qaic/mhi_controller.c
@@ -469,7 +469,7 @@ static void mhi_status_cb(struct mhi_controller *mhi_cntrl,
enum mhi_callback re
pci_err(qdev->pdev, "Fatal error received from device.
Attempting to recover\n");
/* this event occurs in non-atomic context */
if (reason == MHI_CB_SYS_ERROR)
- qaic_dev_reset_clean_local_state(qdev, true);
+ qaic_dev_reset_clean_local_state(qdev);
}
static int mhi_reset_and_async_power_up(struct mhi_controller *mhi_cntrl)
diff --git a/drivers/accel/qaic/qaic.h b/drivers/accel/qaic/qaic.h
index bd0c884e6bf7..66f4abf6c4c4 100644
--- a/drivers/accel/qaic/qaic.h
+++ b/drivers/accel/qaic/qaic.h
@@ -283,7 +283,7 @@ void wakeup_dbc(struct qaic_device *qdev, u32 dbc_id);
void release_dbc(struct qaic_device *qdev, u32 dbc_id);
void wake_all_cntl(struct qaic_device *qdev);
-void qaic_dev_reset_clean_local_state(struct qaic_device *qdev, bool
exit_reset);
+void qaic_dev_reset_clean_local_state(struct qaic_device *qdev);
struct drm_gem_object *qaic_gem_prime_import(struct drm_device *dev, struct
dma_buf *dma_buf);
diff --git a/drivers/accel/qaic/qaic_drv.c b/drivers/accel/qaic/qaic_drv.c
index 02fe23248da4..c19bc83b249c 100644
--- a/drivers/accel/qaic/qaic_drv.c
+++ b/drivers/accel/qaic/qaic_drv.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -43,9 +44,6 @@ MODULE_PARM_DESC(datapath_polling, "Operate the datapath in
polling mode");
static bool link_up;
static DEFINE_IDA(qaic_usrs);
-static int qaic_create_drm_device(struct qaic_device *qdev, s32 partition_id);
-static void qaic_destroy_drm_device(struct qaic_device *qdev, s32
partition_id);
-
static void free_usr(struct kref *kref)
{
struct qaic_user *usr = container_of(kref, struct qaic_user, ref_count);
@@ -183,13 +181,6 @@ static int qaic_create_drm_device(struct qaic_device
*qdev, s32 partition_id)
qddev->partition_id = partition_id;
- /*
-* drm_dev_unregister() sets the driver data to NULL and
-* drm_dev_register() does not update the driver data. During a SOC
-* reset drm dev is unregistered and registered again leaving the
-* driver data to NULL.
-*/
- dev_set_drvdata(to_accel_kdev(qddev), drm->accel);
ret = drm_dev_register(drm, 0);
if (ret)
pci_dbg(qdev->pdev, "drm_dev_register failed %d\n", ret);
@@ -203,7 +194,6 @@ static void qaic_destroy_drm_device(struct qaic_device
*qdev, s32 partition_id)
struct drm_device *drm = to_drm(qddev);
struct qaic_user *usr;
- drm_dev_get(drm);
drm_dev_unregister(drm);
qdd
[PATCH 0/2] Convert to persistent DRM devices
The qaic driver currently creates and destroys the DRM devices when the qaic device is in an operational state for userspace. This does not match what other DRM drivers do, and leads to a few race conditions that need to be handled. Instead, create the DRM device when the underlying PCIe device is detected and destroy the DRM device when the underlying device disappears. Use KOBJ_ONLINE/OFFLINE udev events to signal to userspace when the underlying device is ready to accept requests, or has entered a reset state. Carl Vanderlip (2): accel/qaic: Increase number of in_reset states accel/qaic: Expand DRM device lifecycle Documentation/accel/qaic/qaic.rst | 9 +- drivers/accel/qaic/mhi_controller.c | 2 +- drivers/accel/qaic/qaic.h | 15 +++-- drivers/accel/qaic/qaic_control.c | 5 +-- drivers/accel/qaic/qaic_data.c | 16 - drivers/accel/qaic/qaic_drv.c | 50 - 6 files changed, 52 insertions(+), 45 deletions(-) -- 2.40.1
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
Hi, On 2023/11/17 17:03, Dmitry Baryshkov wrote: On Fri, 17 Nov 2023 at 06:24, Sui Jingfeng wrote: Hi, On 2023/11/16 23:23, Dmitry Baryshkov wrote: Then you will need some way (fwnode?) to discover the bridge chain. And at the last point you will get into the device data and/or properties business. No, leave that chance to a more better programmer and forgive me please, too difficult, I'm afraid of not able to solve. Thanks a lot for the trust! From my point of view: no. I respect the fact that the community prefer generic mechanisms. If our approach is not what the community want, can I switch back to my previous solution? I can reduce the duplication of our localized it66121 driver to a minimal, rewrite it until it meets the community's requirement. I know our device looks weird and our approach is not elegant. But at the very least, we could not mess the community's design up by localize. Otherwise, I don't know what is the better approach to solve such a problem. Can I switch back or any other ideas? I keep on repeating: create the i2c device from your root device driver, which parses BIOS data. You didn't focus on solve the problem, You are focus on solving me. How does the method that parsing BIOS data can be generic and applied universally?
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
Hi, On 2023/11/17 17:03, Dmitry Baryshkov wrote: On Fri, 17 Nov 2023 at 06:24, Sui Jingfeng wrote: Hi, On 2023/11/16 23:23, Dmitry Baryshkov wrote: Then you will need some way (fwnode?) to discover the bridge chain. And at the last point you will get into the device data and/or properties business. No, leave that chance to a more better programmer and forgive me please, too difficult, I'm afraid of not able to solve. Thanks a lot for the trust! From my point of view: no. I respect the fact that the community prefer generic mechanisms. If our approach is not what the community want, can I switch back to my previous solution? I can reduce the duplication of our localized it66121 driver to a minimal, rewrite it until it meets the community's requirement. I know our device looks weird and our approach is not elegant. But at the very least, we could not mess the community's design up by localize. Otherwise, I don't know what is the better approach to solve such a problem. Can I switch back or any other ideas? I keep on repeating: create the i2c device from your root device driver, which parses BIOS data. This is not my own problems, currently it66121 (but not only) display bridge driver don't works on X86 either. What we are trying to do is to provide a generic, non-platform dependent solution. It is not only relevant to my driver. In fact, this series made no assumption which hardware/display controller will be the user. I have investigated before respin this patch, there are other hardwares which ship the it66121 display bridge. For example, the Fresco Logic FL2000dx USB 3.0 to VGA display adapter[1][2]. Even the windows have a driver. [1] https://github.com/FrescoLogic/FL2000 [2] https://oemdrivers.com/graphics-fresco-logic-fl2000
Re: [PATCH V2] drm/panel: boe-tv101wum-nl6: Fine tune Himax83102-j02 panel HFP and HBP
Hi,
On Thu, Nov 16, 2023 at 7:25 PM Cong Yang
wrote:
>
> The refresh reported by modetest is 60.46Hz, and the actual measurement
> is 60.01Hz, which is outside the expected tolerance.
Presumably you've swapped the numbers above? The value reported by
modetest is 60.01Hz and the actual measurement is 60.46Hz?
> Adjust hporch and
> pixel clock to fix it. After repair, modetest and actual measurement were
> all 60.01Hz.
>
> Modetest refresh = Pixel CLK/ htotal* vtotal, but measurement frame rate
> is HS->LP cycle time(Vblanking). Measured frame rate is not only affected
> by Htotal/Vtotal/pixel clock, also affecte by Lane-num/PixelBit/LineTime
s/affecte/affected
For me, the important part would be to explain the reason for the
difference. I assume that the DSI controller could not make the mode
that we requested exactly (presumably it's PLL couldn't generate the
exact pixel clock?). This new mode was picked to be achievable by the
DSI controller on the system that the panel is used on.
> /DSI CLK. If you use a different SOC platform mipi controller, you may
> need to readjust these parameters. Now this panel looks like it's only used
> by me on the MTK platform, so let's change this set of parameters.
>
> Fixes: 1bc2ef065f13 ("drm/panel: Support for Starry-himax83102-j02 TDDI
> MIPI-DSI panel")
> Signed-off-by: Cong Yang
> ---
> Chage since V1:
>
> - Update commit message.
>
> V1:
> https://lore.kernel.org/all/20231110094553.2361842-1-yangco...@huaqin.corp-partner.google.com
> ---
> drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
As per discussion in V1, I'm OK with this.
Reviewed-by: Douglas Anderson
I'll probably give it at least another week before applying in case
anyone else wants to speak up. It would be nice if you could send a V3
with a few more touchups to the commit message, especially since the
60.01 and 60.46 numbers were backward (unless I'm mistaken).
-Doug
Re: [PATCH] drm/panel: simple: Fix Innolux G101ICE-L01 bus flags
On 11/17/23 09:40, Maxime Ripard wrote:
On Thu, Nov 16, 2023 at 10:15:31PM +0100, Marek Vasut wrote:
On 10/9/23 10:58, Neil Armstrong wrote:
On 09/10/2023 00:33, Marek Vasut wrote:
Add missing .bus_flags = DRM_BUS_FLAG_DE_HIGH to this panel description,
ones which match both the datasheet and the panel display_timing flags .
Fixes: 1e29b840af9f ("drm/panel: simple: Add Innolux G101ICE-L01 panel")
Signed-off-by: Marek Vasut
---
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jessica Zhang
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 44c11c418cd56..8e4ea15f0e1e5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2318,6 +2318,7 @@ static const struct panel_desc
innolux_g101ice_l01 = {
.disable = 200,
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
Reviewed-by: Neil Armstrong
Maybe it is time to apply ?
The expectation is that you would kind of apply it yourself. Do you have
a drm-misc committer account? If not, you should apply for one, you
definitely qualify.
I do, I'm just not a big fan of applying my own patches, but since there
is a RB, I will do that in a bit.
[PULL] drm-fixes for -rc2
Hi Linus, This is a "blast from the bast" fixes pull, because it contains a bunch of AGP fixes for amdgpu. Otherwise nothing out of the ordinary. Next week is back to Dave unless he's knocked out by some conference bug. Cheers! drm-fixes-2023-11-17: drm-fixes for -rc2 - amdgpu: fixes all over, including a set of AGP fixes - nouvea: GSP + other bugfixes - ivpu build fix - lenovo legion go panel orientation quirk Cheers, Daniel The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86: Linux 6.7-rc1 (2023-11-12 16:19:07 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-11-17 for you to fetch changes up to 86d8f905f24d223e15587365f07849635458c5d9: Merge tag 'amd-drm-fixes-6.7-2023-11-17' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2023-11-17 11:46:07 +0100) drm-fixes for -rc2 - amdgpu: fixes all over, including a set of AGP fixes - nouvea: GSP + other bugfixes - ivpu build fix - lenovo legion go panel orientation quirk Alex Deucher (5): drm/amdgpu/gmc11: fix logic typo in AGP check drm/amdgpu: add a module parameter to control the AGP aperture drm/amdgpu/gmc11: disable AGP aperture drm/amdgpu/gmc10: disable AGP aperture drm/amdgpu/gmc9: disable AGP aperture Arnd Bergmann (1): accel/ivpu: avoid build failure with CONFIG_PM=n Asad Kamal (2): drm/amd/pm: Update metric table for smu v13_0_6 drm/amd/pm: Fill pcie error counters for gpu v1_4 Brenton Simpson (1): drm: panel-orientation-quirks: Add quirk for Lenovo Legion Go Dan Carpenter (2): nouveau/gsp/r535: uninitialized variable in r535_gsp_acpi_mux_id() nouveau/gsp/r535: Fix a NULL vs error pointer bug Daniel Vetter (2): Merge tag 'drm-misc-fixes-2023-11-16' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'amd-drm-fixes-6.7-2023-11-17' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Dave Airlie (2): nouveau: use an rwlock for the event lock. nouveau: don't fail driver load if no display hw present. Duncan Ma (1): drm/amd/display: Negate IPS allow and commit bits Fangzhi Zuo (1): drm/amd/display: Fix DSC not Enabled on Direct MST Sink José Pekkarinen (1): drm/amd/display: fix NULL dereference Le Ma (1): drm/amdgpu: finalizing mem_partitions at the end of GMC v9 sw_fini Lewis Huang (1): drm/amd/display: Change the DMCUB mailbox memory location from FB to inbox Lijo Lazar (1): drm/amd/pm: Don't send unload message for reset Mario Limonciello (1): drm/amd/display: fix a NULL pointer dereference in amdgpu_dm_i2c_xfer() Muhammad Ahmed (1): drm/amd/display: Add null checks for 8K60 lightup Nicholas Kazlauskas (1): drm/amd/display: Guard against invalid RPTR/WPTR being set Nicholas Susanto (1): drm/amd/display: Fix encoder disable logic Paul Hsieh (1): drm/amd/display: Clear dpcd_sink_ext_caps if not set Shiwu Zhang (1): drm/amdgpu: add and populate the port num into xgmi topology info Srinivasan Shanmugam (1): drm/amdgpu: Address member 'ring' not described in 'amdgpu_ vce, uvd_entity_init()' Tianci Yin (1): drm/amd/display: Enable fast plane updates on DCN3.2 and above Victor Lu (1): drm/amdgpu: Do not program VF copy regs in mmhub v1.8 under SRIOV (v2) Yang Wang (1): drm/amdgpu: fix ras err_data null pointer issue in amdgpu_ras.c YuanShang (1): drm/amdgpu: correct chunk_ptr to a pointer to chunk. drivers/accel/ivpu/ivpu_pm.c | 3 -- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 10 + drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 5 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c| 1 + drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 5 ++- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 7 +-- drivers/gpu/drm/amd/amdgpu/mmhub_v1_8.c| 6 +-- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ++- .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 5 +-- .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 29 ++--- .../amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c | 18 drivers/gpu/drm/amd/display/dc/core/dc.c | 6 +-- drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 3 ++ drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 10 ++--- drivers/gpu/drm/amd/display/dc/dc_types.h | 1 + .../display
Re: [PATCH 4/6] drm/amdkfd: Export DMABufs from KFD using GEM handles
Am 16.11.23 um 22:53 schrieb Felix Kuehling:
On 2023-11-07 11:58, Felix Kuehling wrote:
Create GEM handles for exporting DMABufs using GEM-Prime APIs. The GEM
handles are created in a drm_client_dev context to avoid exposing them
in user mode contexts through a DMABuf import.
This patch (and the next one) won't apply upstream because Thomas
Zimmerman just made drm_gem_prime_fd_to_handle and
drm_gem_prime_handle_to_fd private because nobody was using them.
(drm/prime: Unexport helpers for fd/handle conversion)
Is it OK to export those APIs again? Or is there a better way for
drivers to export/import DMABufs without using the GEM ioctls?
Well let me say so: I think it's the least evil approach :)
So yeah, propose a patch to export them again.
Regards,
Christian.
Regards,
Felix
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 11 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 5 +++
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 33 +++
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 +--
4 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 6ab17330a6ed..b0a67f16540a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -142,6 +142,7 @@ void amdgpu_amdkfd_device_init(struct
amdgpu_device *adev)
{
int i;
int last_valid_bit;
+ int ret;
amdgpu_amdkfd_gpuvm_init_mem_limits();
@@ -160,6 +161,12 @@ void amdgpu_amdkfd_device_init(struct
amdgpu_device *adev)
.enable_mes = adev->enable_mes,
};
+ ret = drm_client_init(&adev->ddev, &adev->kfd.client,
"kfd", NULL);
+ if (ret) {
+ dev_err(adev->dev, "Failed to init DRM client: %d\n", ret);
+ return;
+ }
+
/* this is going to have a few of the MSBs set that we need to
* clear
*/
@@ -198,6 +205,10 @@ void amdgpu_amdkfd_device_init(struct
amdgpu_device *adev)
adev->kfd.init_complete = kgd2kfd_device_init(adev->kfd.dev,
&gpu_resources);
+ if (adev->kfd.init_complete)
+ drm_client_register(&adev->kfd.client);
+ else
+ drm_client_release(&adev->kfd.client);
amdgpu_amdkfd_total_mem_size += adev->gmc.real_vram_size;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 68d534a89942..4caf8cece028 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include "amdgpu_sync.h"
#include "amdgpu_vm.h"
@@ -84,6 +85,7 @@ struct kgd_mem {
struct amdgpu_sync sync;
+ uint32_t gem_handle;
bool aql_queue;
bool is_imported;
};
@@ -106,6 +108,9 @@ struct amdgpu_kfd_dev {
/* HMM page migration MEMORY_DEVICE_PRIVATE mapping */
struct dev_pagemap pgmap;
+
+ /* Client for KFD BO GEM handle allocations */
+ struct drm_client_dev client;
};
enum kgd_engine_type {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 0c1cb6048259..4bb8b5fd7598 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include "amdgpu_object.h"
@@ -804,13 +805,22 @@ kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
static int kfd_mem_export_dmabuf(struct kgd_mem *mem)
{
if (!mem->dmabuf) {
- struct dma_buf *ret = amdgpu_gem_prime_export(
- &mem->bo->tbo.base,
+ struct amdgpu_device *bo_adev;
+ struct dma_buf *dmabuf;
+ int r, fd;
+
+ bo_adev = amdgpu_ttm_adev(mem->bo->tbo.bdev);
+ r = drm_gem_prime_handle_to_fd(&bo_adev->ddev,
bo_adev->kfd.client.file,
+ mem->gem_handle,
mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
- DRM_RDWR : 0);
- if (IS_ERR(ret))
- return PTR_ERR(ret);
- mem->dmabuf = ret;
+ DRM_RDWR : 0, &fd);
+ if (r)
+ return r;
+ dmabuf = dma_buf_get(fd);
+ close_fd(fd);
+ if (WARN_ON_ONCE(IS_ERR(dmabuf)))
+ return PTR_ERR(dmabuf);
+ mem->dmabuf = dmabuf;
}
return 0;
@@ -1826,6 +1836,9 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
pr_debug("Failed to allow vma node access. ret %d\n", ret);
goto err_node_allow;
}
+ ret = drm_gem_handle_create(adev->kfd.client.file, gobj,
&(*mem)->gem_handle);
+ if (ret)
+ goto err_gem_handle_create;
bo = gem_to_amdgpu_bo(gobj);
if (bo_type == ttm_bo_type_sg) {
Re: [PATCH v3 02/11] drm/dp_mst: Fix PBN divider calculation for UHBR rates
On Fri, Nov 17, 2023 at 05:09:27PM +0200, Imre Deak wrote:
> The current way of calculating the pbn_div value, the link BW per each
> MTP slot, worked only for DP 1.4 link rates. Fix things up for UHBR
> rates calculating with the correct channel coding efficiency based on
> the link rate.
>
> v2:
> - Return the fractional pbn_div value from drm_dp_get_vc_payload_bw().
> v3:
> - Fix rounding up quotient while calculating req_slots. (Ville)
>
> Cc: Ville Syrjälä
> Cc: Lyude Paul
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 10 +++---
> include/drm/display/drm_dp_helper.h | 13 +
> 2 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 000d05e80352a..8ca01a6bf645d 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3585,14 +3585,18 @@ static int drm_dp_send_up_ack_reply(struct
> drm_dp_mst_topology_mgr *mgr,
> fixed20_12 drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr
> *mgr,
> int link_rate, int link_lane_count)
> {
> + int ch_coding_efficiency =
> +
> drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(link_rate));
> fixed20_12 ret;
>
> if (link_rate == 0 || link_lane_count == 0)
> drm_dbg_kms(mgr->dev, "invalid link rate/lane count: (%d /
> %d)\n",
> link_rate, link_lane_count);
>
> - /* See DP v2.0 2.6.4.2,
> VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
> - ret.full = dfixed_const(link_rate * link_lane_count / 54000);
> + /* See DP v2.0 2.6.4.2, 2.7.6.3
> VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
> + ret.full = DIV_ROUND_DOWN_ULL(mul_u32_u32(link_rate * link_lane_count,
> + ch_coding_efficiency),
> + (100ULL * 8 * 5400) >> 12);
>
> return ret;
> }
> @@ -4342,7 +4346,7 @@ int drm_dp_atomic_find_time_slots(struct
> drm_atomic_state *state,
> }
> }
>
> - req_slots = DIV_ROUND_UP(pbn, dfixed_trunc(topology_state->pbn_div));
> + req_slots = DIV_ROUND_UP(dfixed_const(pbn),
> topology_state->pbn_div.full);
>
> drm_dbg_atomic(mgr->dev, "[CONNECTOR:%d:%s] [MST PORT:%p] TU %d ->
> %d\n",
> port->connector->base.id, port->connector->name,
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index c5f1079acb3b1..863b2e7add29e 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -252,6 +252,19 @@ drm_edp_backlight_supported(const u8
> edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE])
> return !!(edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP);
> }
>
> +/**
> + * drm_dp_is_uhbr_rate - Determine if a link rate is UHBR
> + * @link_rate: link rate in 10kbits/s units
> + *
> + * Determine if the provided link rate is an UHBR rate.
> + *
> + * Returns: %True if @link_rate is an UHBR rate.
> + */
> +static inline bool drm_dp_is_uhbr_rate(int link_rate)
> +{
> + return link_rate >= 100;
> +}
> +
> /*
> * DisplayPort AUX channel
> */
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH v8 0/6] drm: Add support for atomic async page-flip
It seems like commits were re-ordered at some point. I think we need "drm: introduce drm_mode_config.atomic_async_page_flip_not_supported" to come before "drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits" because the latter uses atomic_async_page_flip_not_supported. Similarly, "drm: Refuse to async flip with atomic prop changes" should probably come before that same patch because we don't want to have an intermediary state where we allow user-space to change arbitrary properties. In general, commits should be constructed so that there is no "broken state" in-between: each commit needs to build without errors and not have transient bugs. While reading this again, I think that now that we only allow primary FB_ID to change, we don't need atomic_async_page_flip_not_supported anymore? In other words, allowing async atomic commits on all drivers doesn't require anything more than they support already, because the atomic codepath can't do anything more than the legacy codepath. With that in mind, I also wonder if the new cap is helpful. Since async atomic commits can fail for pretty much any reason, user-space can just try and fallback to something else. The cap could be useful to indicate whether async atomic commits would always fail, but not sure how useful that is? I don't have strong opinions either way.
Re: [PATCH v4 03/11] drm/dp_mst: Add kunit tests for drm_dp_get_vc_payload_bw()
On Fri, Nov 17, 2023 at 05:27:37PM +0200, Imre Deak wrote:
> Add kunit test cases for drm_dp_get_vc_payload_bw() with all the DP1.4
> and UHBR link configurations.
>
> v2:
> - List test cases in decreasing rate,lane count order matching the
> corresponding DP Standard tables. (Ville)
> - Add references to the DP Standard tables.
> v3:
> - Sort the testcases properly.
>
> Cc: Ville Syrjälä
> Cc: Lyude Paul
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> .../gpu/drm/tests/drm_dp_mst_helper_test.c| 147 ++
> 1 file changed, 147 insertions(+)
>
> diff --git a/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
> b/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
> index e3c818dfc0e6d..98d57d28aab6f 100644
> --- a/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
> @@ -68,6 +68,152 @@ static void dp_mst_calc_pbn_mode_desc(const struct
> drm_dp_mst_calc_pbn_mode_test
> KUNIT_ARRAY_PARAM(drm_dp_mst_calc_pbn_mode, drm_dp_mst_calc_pbn_mode_cases,
> dp_mst_calc_pbn_mode_desc);
>
> +struct drm_dp_mst_calc_pbn_div_test {
> + int link_rate;
> + int lane_count;
> + fixed20_12 expected;
> +};
> +
> +#define fp_init(__int, __frac) { \
> + .full = (__int) * (1 << 12) + \
> + (__frac) * (1 << 12) / 10 \
> +}
> +
> +static const struct drm_dp_mst_calc_pbn_div_test
> drm_dp_mst_calc_pbn_div_dp1_4_cases[] = {
> + /*
> + * UHBR rates (DP Standard v2.1 2.7.6.3, specifying the rounded to
> + * closest value to 2 decimal places):
> + * .expected = .link_rate * .lane_count * 0.9671 / 8 / 54 / 100
> + * DP1.4 rates (DP Standard v2.1 2.6.4.2):
> + * .expected = .link_rate * .lane_count * 0.8000 / 8 / 54 / 100
> + *
> + * truncated to 5 decimal places.
> + */
> + {
> + .link_rate = 200,
> + .lane_count = 4,
> + .expected = fp_init(179, 9259), /* 179.09259 */
> + },
> + {
> + .link_rate = 200,
> + .lane_count = 2,
> + .expected = fp_init(89, 54629),
> + },
> + {
> + .link_rate = 200,
> + .lane_count = 1,
> + .expected = fp_init(44, 77314),
> + },
> + {
> + .link_rate = 135,
> + .lane_count = 4,
> + .expected = fp_init(120, 88750),
> + },
> + {
> + .link_rate = 135,
> + .lane_count = 2,
> + .expected = fp_init(60, 44375),
> + },
> + {
> + .link_rate = 135,
> + .lane_count = 1,
> + .expected = fp_init(30, 22187),
> + },
> + {
> + .link_rate = 100,
> + .lane_count = 4,
> + .expected = fp_init(89, 54629),
> + },
> + {
> + .link_rate = 100,
> + .lane_count = 2,
> + .expected = fp_init(44, 77314),
> + },
> + {
> + .link_rate = 100,
> + .lane_count = 1,
> + .expected = fp_init(22, 38657),
> + },
> + {
> + .link_rate = 81,
> + .lane_count = 4,
> + .expected = fp_init(60, 0),
> + },
> + {
> + .link_rate = 81,
> + .lane_count = 2,
> + .expected = fp_init(30, 0),
> + },
> + {
> + .link_rate = 81,
> + .lane_count = 1,
> + .expected = fp_init(15, 0),
> + },
> + {
> + .link_rate = 54,
> + .lane_count = 4,
> + .expected = fp_init(40, 0),
> + },
> + {
> + .link_rate = 54,
> + .lane_count = 2,
> + .expected = fp_init(20, 0),
> + },
> + {
> + .link_rate = 54,
> + .lane_count = 1,
> + .expected = fp_init(10, 0),
> + },
> + {
> + .link_rate = 27,
> + .lane_count = 4,
> + .expected = fp_init(20, 0),
> + },
> + {
> + .link_rate = 27,
> + .lane_count = 2,
> + .expected = fp_init(10, 0),
> + },
> + {
> + .link_rate = 27,
> + .lane_count = 1,
> + .expected = fp_init(5, 0),
> + },
> + {
> + .link_rate = 162000,
> + .lane_count = 4,
> + .expected = fp_init(12, 0),
> + },
> + {
> + .link_rate = 162000,
> + .lane_count = 2,
> + .expected = fp_init(6, 0),
> + },
> + {
> + .link_rate = 162000,
> + .lane_count = 1,
> + .expected = fp_init(3, 0),
> + },
> +};
> +
> +static void drm_test_dp_mst_calc_pbn_div(struct kunit *test)
> +{
> + const struct drm_dp_mst_calc_pbn_div_test *params = test->param_value;
> + /* mgr->dev is only needed by drm_dbg_k
Re: [PATCH] accel/ivpu/37xx: Fix hangs related to MMIO reset
On 11/15/2023 4:10 AM, Jacek Lawrynowicz wrote:
There is no need to call MMIO reset using VPU_37XX_BUTTRESS_VPU_IP_RESET
register. IP will be reset by FLR or by entering d0i3. Also IP reset
during power_up is not needed as the VPU is already in reset.
Removing MMIO reset improves stability as it a partial device reset
that is not safe in some corner cases.
This change also brings back ivpu_boot_pwr_domain_disable() that
helps to properly power down VPU when it is hung by a buggy workload.
Signed-off-by: Jacek Lawrynowicz
Fixes: 828d63042aec ("accel/ivpu: Don't enter d0i3 during FLR")
Reviewed-by: Jeffrey Hugo
[PATCH v4 03/11] drm/dp_mst: Add kunit tests for drm_dp_get_vc_payload_bw()
Add kunit test cases for drm_dp_get_vc_payload_bw() with all the DP1.4
and UHBR link configurations.
v2:
- List test cases in decreasing rate,lane count order matching the
corresponding DP Standard tables. (Ville)
- Add references to the DP Standard tables.
v3:
- Sort the testcases properly.
Cc: Ville Syrjälä
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
.../gpu/drm/tests/drm_dp_mst_helper_test.c| 147 ++
1 file changed, 147 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
b/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
index e3c818dfc0e6d..98d57d28aab6f 100644
--- a/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
@@ -68,6 +68,152 @@ static void dp_mst_calc_pbn_mode_desc(const struct
drm_dp_mst_calc_pbn_mode_test
KUNIT_ARRAY_PARAM(drm_dp_mst_calc_pbn_mode, drm_dp_mst_calc_pbn_mode_cases,
dp_mst_calc_pbn_mode_desc);
+struct drm_dp_mst_calc_pbn_div_test {
+ int link_rate;
+ int lane_count;
+ fixed20_12 expected;
+};
+
+#define fp_init(__int, __frac) { \
+ .full = (__int) * (1 << 12) + \
+ (__frac) * (1 << 12) / 10 \
+}
+
+static const struct drm_dp_mst_calc_pbn_div_test
drm_dp_mst_calc_pbn_div_dp1_4_cases[] = {
+ /*
+* UHBR rates (DP Standard v2.1 2.7.6.3, specifying the rounded to
+* closest value to 2 decimal places):
+* .expected = .link_rate * .lane_count * 0.9671 / 8 / 54 / 100
+* DP1.4 rates (DP Standard v2.1 2.6.4.2):
+* .expected = .link_rate * .lane_count * 0.8000 / 8 / 54 / 100
+*
+* truncated to 5 decimal places.
+*/
+ {
+ .link_rate = 200,
+ .lane_count = 4,
+ .expected = fp_init(179, 9259), /* 179.09259 */
+ },
+ {
+ .link_rate = 200,
+ .lane_count = 2,
+ .expected = fp_init(89, 54629),
+ },
+ {
+ .link_rate = 200,
+ .lane_count = 1,
+ .expected = fp_init(44, 77314),
+ },
+ {
+ .link_rate = 135,
+ .lane_count = 4,
+ .expected = fp_init(120, 88750),
+ },
+ {
+ .link_rate = 135,
+ .lane_count = 2,
+ .expected = fp_init(60, 44375),
+ },
+ {
+ .link_rate = 135,
+ .lane_count = 1,
+ .expected = fp_init(30, 22187),
+ },
+ {
+ .link_rate = 100,
+ .lane_count = 4,
+ .expected = fp_init(89, 54629),
+ },
+ {
+ .link_rate = 100,
+ .lane_count = 2,
+ .expected = fp_init(44, 77314),
+ },
+ {
+ .link_rate = 100,
+ .lane_count = 1,
+ .expected = fp_init(22, 38657),
+ },
+ {
+ .link_rate = 81,
+ .lane_count = 4,
+ .expected = fp_init(60, 0),
+ },
+ {
+ .link_rate = 81,
+ .lane_count = 2,
+ .expected = fp_init(30, 0),
+ },
+ {
+ .link_rate = 81,
+ .lane_count = 1,
+ .expected = fp_init(15, 0),
+ },
+ {
+ .link_rate = 54,
+ .lane_count = 4,
+ .expected = fp_init(40, 0),
+ },
+ {
+ .link_rate = 54,
+ .lane_count = 2,
+ .expected = fp_init(20, 0),
+ },
+ {
+ .link_rate = 54,
+ .lane_count = 1,
+ .expected = fp_init(10, 0),
+ },
+ {
+ .link_rate = 27,
+ .lane_count = 4,
+ .expected = fp_init(20, 0),
+ },
+ {
+ .link_rate = 27,
+ .lane_count = 2,
+ .expected = fp_init(10, 0),
+ },
+ {
+ .link_rate = 27,
+ .lane_count = 1,
+ .expected = fp_init(5, 0),
+ },
+ {
+ .link_rate = 162000,
+ .lane_count = 4,
+ .expected = fp_init(12, 0),
+ },
+ {
+ .link_rate = 162000,
+ .lane_count = 2,
+ .expected = fp_init(6, 0),
+ },
+ {
+ .link_rate = 162000,
+ .lane_count = 1,
+ .expected = fp_init(3, 0),
+ },
+};
+
+static void drm_test_dp_mst_calc_pbn_div(struct kunit *test)
+{
+ const struct drm_dp_mst_calc_pbn_div_test *params = test->param_value;
+ /* mgr->dev is only needed by drm_dbg_kms(), but it's not called for
the test cases. */
+ struct drm_dp_mst_topology_mgr mgr = {};
+
+ KUNIT_EXPECT_EQ(test, drm_dp_get_vc_payload_bw(&mgr, param
Re: [RFC PATCH] drm/imx: ipuv3-plane: Allow preventing sequential DMA bursts
Hello, miquel.ray...@bootlin.com wrote on Fri, 27 Oct 2023 18:20:25 +0200: > Sequential DMA bursts improve NIC/RAM usage thanks to the basic NIC > hardware optimizations available when performing in-order sequential > accesses. This can be further enforced with the IPU DMA locking > mechanism which basically prevents any other IP to access the > interconnect for a longer time while performing up to 8 sequential DMA > bursts. The drawback is a lower availability for short time periods and > delayed accesses which may cause problem with latency-sensible systems > (typically, the network might suffer from high drop rates). This is even > more visible with larger displays requiring even more RAM bandwidth. > > Issues have been observed on IMX6Q. The setup featured a 60Hz 1024x768 > LVDS display just showing a static picture (thus no CPU usage, only > background DMA bringing the picture to the display engine). When > performing full speed iperf3 uplink tests with the FEC, almost no drop > was observed, whereas the drop would raise above 50% when limiting the > bandwidth to 1Mb/s (on a 100Mb/s link). The exact same test with the > display pipeline disabled would show little to no drop. The LP-DDR3 chip > on the module would allow up to ~53MiB each 1/60th of a second, and the > display pipeline consume approximately ~10MiB of this bandwidth, and > thus be active 20% of the time on each time slot. > > One particular feature of the IPU DMA controller (IDMAC) is the ability > to serialize DMA bursts and to lock further interconnect accesses when > doing so. Experimentally, disabling the locking lead to a drop rate from > 50% down to 10%. A few more % could be earned by setting the burst > number to 1. It seems this huge difference could be explained by a > possible hardware conflict between the locking feature and some QoS > logic. Indeed, on IMX6Q, the NIC-301 manages priorities and by default > will elect ENET's requests (priority 2) above IPU's requests (priority > 0). But the QoS seems to only be valid above a certain threshold, which > is: 4 consequent DMA bursts in the case of the IPU. It was indeed > observed that tweaking the number of bursts to be lowered from 8 to 4 > would lead to a significant increase in the Ethernet transfers > stability. IOW, it looks like when the display pipeline performs DMA > transfers, incoming DMA requests from other master devices on the > interconnect are delayed too much (or canceled). > > I have no clue to explain why on the Ethernet MAC side some uDMA > transfers would never reach completion, especially without notification > nor any error. All uplink transfers are properly queued at the FEC level > and more importantly, the corresponding interrupts are fired upon > "proper transmission" and report no error whatsoever (note: there is no > actual way to know the uDMA internal controller could not fetch the > data, only MAC errors could be reported at this stage). > > As a solution, we might want to prevent these DMA bursts from being > queued together. Maybe the IMX6Q is primarily used for its graphics > capabilities, but when the network (and other RAM consuming subsystem) > also matter, it may be relevant to apply this workaround in order to > help them fetching from RAM more reliably. > > Signed-off-by: Miquel Raynal > --- > > Hello, > > This really is an RFC as the bug was also observed on v6.5 but the fix > proposed here was written and tested on a v4.14 kernel. I want to > discuss the approach and ideally get some feedback from imx6 experts who > know the SoC internals before publishing a clean series. There is a lot > of guessing in this workaround, besides the experimental measures I > managed to do. I would be glad if someone could sched any light or > involve knowledgeable people in this conversation. > > The initial report was there and mainly focused on the network > subsystem: > https://lore.kernel.org/netdev/18b72fdb-d24a-a416-ffab-3a15b281a...@katalix.com/T/#md265d6da81b8fb6b85e3adbb399bcda79dfc761c > In this thread I made wrong observations because for speeding up my test > cycles, I dropped the support for: DRM, SND, USB as these subsystems > seemed totally irrelevant. It actually had a strong impact. > > In the end, I really think there is something wrong with the locking of > IPU DMA bursts when mixed with the QoS of the NIC. Further investigation lead to the DDR configuration itself. The system worked perfectly besides the Ethernet drop rate which was abnormally high and it turns out, just changing a bit in the DDR reset pad configuration fixed it. I cannot explain exactly what was the root cause but it is possible that the DDR was in a relatively unstable state due to the power-on/reset procedure not being followed correctly due to the incomplete pad configuration. Here is the U-Boot thread I've started: https://lore.kernel.org/u-boot/20231117150044.1792080-1-miquel.ray...@bootlin.com/ Thanks, Miquèl
[PATCH] drm/msm/gpu: Skip retired submits in recover worker
From: Rob Clark
If we somehow raced with submit retiring, either while waiting for
worker to have a chance to run or acquiring the gpu lock, then the
recover worker should just bail.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 41 +++
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 3fad5d58262f..fd3dceed86f8 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -365,29 +365,31 @@ static void recover_worker(struct kthread_work *work)
DRM_DEV_ERROR(dev->dev, "%s: hangcheck recover!\n", gpu->name);
submit = find_submit(cur_ring, cur_ring->memptrs->fence + 1);
- if (submit) {
- /* Increment the fault counts */
- submit->queue->faults++;
- if (submit->aspace)
- submit->aspace->faults++;
- get_comm_cmdline(submit, &comm, &cmd);
+ /*
+* If the submit retired while we were waiting for the worker to run,
+* or waiting to acquire the gpu lock, then nothing more to do.
+*/
+ if (!submit)
+ goto out_unlock;
- if (comm && cmd) {
- DRM_DEV_ERROR(dev->dev, "%s: offending task: %s (%s)\n",
- gpu->name, comm, cmd);
+ /* Increment the fault counts */
+ submit->queue->faults++;
+ if (submit->aspace)
+ submit->aspace->faults++;
- msm_rd_dump_submit(priv->hangrd, submit,
- "offending task: %s (%s)", comm, cmd);
- } else {
- msm_rd_dump_submit(priv->hangrd, submit, NULL);
- }
+ get_comm_cmdline(submit, &comm, &cmd);
+
+ if (comm && cmd) {
+ DRM_DEV_ERROR(dev->dev, "%s: offending task: %s (%s)\n",
+ gpu->name, comm, cmd);
+
+ msm_rd_dump_submit(priv->hangrd, submit,
+ "offending task: %s (%s)", comm, cmd);
} else {
- /*
-* We couldn't attribute this fault to any particular context,
-* so increment the global fault count instead.
-*/
- gpu->global_faults++;
+ DRM_DEV_ERROR(dev->dev, "%s: offending task: unknown\n",
gpu->name);
+
+ msm_rd_dump_submit(priv->hangrd, submit, NULL);
}
/* Record the crash state */
@@ -440,6 +442,7 @@ static void recover_worker(struct kthread_work *work)
pm_runtime_put(&gpu->pdev->dev);
+out_unlock:
mutex_unlock(&gpu->lock);
msm_gpu_retire(gpu);
--
2.41.0
[PATCH] drm/msm: Reduce fallout of fence signaling vs reclaim hangs
From: Rob Clark
Until various PM devfreq/QoS and interconnect patches land, we could
potentially trigger reclaim from gpu scheduler thread, and under enough
memory pressure that could trigger a sort of deadlock. Eventually the
wait will timeout and we'll move on to consider other GEM objects. But
given that there is still a potential for deadlock/stalling, we should
reduce the timeout to contain the damage.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c
b/drivers/gpu/drm/msm/msm_gem_shrinker.c
index 5a7d48c02c4b..07ca4ddfe4e3 100644
--- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
+++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
@@ -75,7 +75,7 @@ static bool
wait_for_idle(struct drm_gem_object *obj)
{
enum dma_resv_usage usage = dma_resv_usage_rw(true);
- return dma_resv_wait_timeout(obj->resv, usage, false, 1000) > 0;
+ return dma_resv_wait_timeout(obj->resv, usage, false, 10) > 0;
}
static bool
--
2.41.0
[PATCH v3 03/11] drm/dp_mst: Add kunit tests for drm_dp_get_vc_payload_bw()
Add kunit test cases for drm_dp_get_vc_payload_bw() with all the DP1.4
and UHBR link configurations.
v2:
- List test cases in decreasing rate,lane count order matching the
corresponding DP Standard tables. (Ville)
- Add references to the DP Standard tables.
Cc: Ville Syrjälä
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
.../gpu/drm/tests/drm_dp_mst_helper_test.c| 146 ++
1 file changed, 146 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
b/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
index e3c818dfc0e6d..df3f703e4f09a 100644
--- a/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
@@ -68,6 +68,151 @@ static void dp_mst_calc_pbn_mode_desc(const struct
drm_dp_mst_calc_pbn_mode_test
KUNIT_ARRAY_PARAM(drm_dp_mst_calc_pbn_mode, drm_dp_mst_calc_pbn_mode_cases,
dp_mst_calc_pbn_mode_desc);
+struct drm_dp_mst_calc_pbn_div_test {
+ int link_rate;
+ int lane_count;
+ fixed20_12 expected;
+};
+
+#define fp_init(__int, __frac) { \
+ .full = (__int) * (1 << 12) + \
+ (__frac) * (1 << 12) / 10 \
+}
+
+static const struct drm_dp_mst_calc_pbn_div_test
drm_dp_mst_calc_pbn_div_dp1_4_cases[] = {
+ /*
+* UHBR rates: (DP Standard v2.1 2.7.6.3)
+* .expected = .link_rate * .lane_count * 0.9671 / 8 / 54 / 100
+* DP1.4 rates: (DP Standard v2.1 2.6.4.2)
+* .expected = .link_rate * .lane_count * 0.8000 / 8 / 54 / 100
+*
+* truncated to 5 decimal places.
+*/
+ {
+ .link_rate = 200,
+ .lane_count = 4,
+ .expected = fp_init(179, 9259), /* 179.09259 */
+ },
+ {
+ .link_rate = 200,
+ .lane_count = 2,
+ .expected = fp_init(89, 54629),
+ },
+ {
+ .link_rate = 200,
+ .lane_count = 1,
+ .expected = fp_init(44, 77314),
+ },
+ {
+ .link_rate = 100,
+ .lane_count = 4,
+ .expected = fp_init(89, 54629),
+ },
+ {
+ .link_rate = 100,
+ .lane_count = 2,
+ .expected = fp_init(44, 77314),
+ },
+ {
+ .link_rate = 100,
+ .lane_count = 1,
+ .expected = fp_init(22, 38657),
+ },
+ {
+ .link_rate = 135,
+ .lane_count = 4,
+ .expected = fp_init(120, 88750),
+ },
+ {
+ .link_rate = 135,
+ .lane_count = 2,
+ .expected = fp_init(60, 44375),
+ },
+ {
+ .link_rate = 135,
+ .lane_count = 1,
+ .expected = fp_init(30, 22187),
+ },
+ {
+ .link_rate = 81,
+ .lane_count = 4,
+ .expected = fp_init(60, 0),
+ },
+ {
+ .link_rate = 81,
+ .lane_count = 2,
+ .expected = fp_init(30, 0),
+ },
+ {
+ .link_rate = 81,
+ .lane_count = 1,
+ .expected = fp_init(15, 0),
+ },
+ {
+ .link_rate = 54,
+ .lane_count = 4,
+ .expected = fp_init(40, 0),
+ },
+ {
+ .link_rate = 54,
+ .lane_count = 2,
+ .expected = fp_init(20, 0),
+ },
+ {
+ .link_rate = 54,
+ .lane_count = 1,
+ .expected = fp_init(10, 0),
+ },
+ {
+ .link_rate = 27,
+ .lane_count = 4,
+ .expected = fp_init(20, 0),
+ },
+ {
+ .link_rate = 27,
+ .lane_count = 2,
+ .expected = fp_init(10, 0),
+ },
+ {
+ .link_rate = 27,
+ .lane_count = 1,
+ .expected = fp_init(5, 0),
+ },
+ {
+ .link_rate = 162000,
+ .lane_count = 4,
+ .expected = fp_init(12, 0),
+ },
+ {
+ .link_rate = 162000,
+ .lane_count = 2,
+ .expected = fp_init(6, 0),
+ },
+ {
+ .link_rate = 162000,
+ .lane_count = 1,
+ .expected = fp_init(3, 0),
+ },
+};
+
+static void drm_test_dp_mst_calc_pbn_div(struct kunit *test)
+{
+ const struct drm_dp_mst_calc_pbn_div_test *params = test->param_value;
+ /* mgr->dev is only needed by drm_dbg_kms(), but it's not called for
the test cases. */
+ struct drm_dp_mst_topology_mgr mgr = {};
+
+ KUNIT_EXPECT_EQ(test, drm_dp_get_vc_payload_bw(&mgr, params->link_rate,
params->lane_count).full,
+ params->expected.full);
+}
+
+static void dp_mst_calc_
[PATCH v3 02/11] drm/dp_mst: Fix PBN divider calculation for UHBR rates
The current way of calculating the pbn_div value, the link BW per each
MTP slot, worked only for DP 1.4 link rates. Fix things up for UHBR
rates calculating with the correct channel coding efficiency based on
the link rate.
v2:
- Return the fractional pbn_div value from drm_dp_get_vc_payload_bw().
v3:
- Fix rounding up quotient while calculating req_slots. (Ville)
Cc: Ville Syrjälä
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 10 +++---
include/drm/display/drm_dp_helper.h | 13 +
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 000d05e80352a..8ca01a6bf645d 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3585,14 +3585,18 @@ static int drm_dp_send_up_ack_reply(struct
drm_dp_mst_topology_mgr *mgr,
fixed20_12 drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr *mgr,
int link_rate, int link_lane_count)
{
+ int ch_coding_efficiency =
+
drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(link_rate));
fixed20_12 ret;
if (link_rate == 0 || link_lane_count == 0)
drm_dbg_kms(mgr->dev, "invalid link rate/lane count: (%d /
%d)\n",
link_rate, link_lane_count);
- /* See DP v2.0 2.6.4.2,
VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
- ret.full = dfixed_const(link_rate * link_lane_count / 54000);
+ /* See DP v2.0 2.6.4.2, 2.7.6.3
VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
+ ret.full = DIV_ROUND_DOWN_ULL(mul_u32_u32(link_rate * link_lane_count,
+ ch_coding_efficiency),
+ (100ULL * 8 * 5400) >> 12);
return ret;
}
@@ -4342,7 +4346,7 @@ int drm_dp_atomic_find_time_slots(struct drm_atomic_state
*state,
}
}
- req_slots = DIV_ROUND_UP(pbn, dfixed_trunc(topology_state->pbn_div));
+ req_slots = DIV_ROUND_UP(dfixed_const(pbn),
topology_state->pbn_div.full);
drm_dbg_atomic(mgr->dev, "[CONNECTOR:%d:%s] [MST PORT:%p] TU %d ->
%d\n",
port->connector->base.id, port->connector->name,
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index c5f1079acb3b1..863b2e7add29e 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -252,6 +252,19 @@ drm_edp_backlight_supported(const u8
edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE])
return !!(edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP);
}
+/**
+ * drm_dp_is_uhbr_rate - Determine if a link rate is UHBR
+ * @link_rate: link rate in 10kbits/s units
+ *
+ * Determine if the provided link rate is an UHBR rate.
+ *
+ * Returns: %True if @link_rate is an UHBR rate.
+ */
+static inline bool drm_dp_is_uhbr_rate(int link_rate)
+{
+ return link_rate >= 100;
+}
+
/*
* DisplayPort AUX channel
*/
--
2.39.2
Re: [PATCH v3] drm/i915/vma: Fix VMA UAF on destroy against deactivate race
Hi Janusz,
On Thu, Nov 16, 2023 at 03:07:20PM +0100, Janusz Krzysztofik wrote:
> Object debugging tools were sporadically reporting illegal attempts to
> free a still active i915 VMA object from when parking a GPU tile believed
> to be idle.
>
> [161.359441] ODEBUG: free active (active state 0) object: 88811643b958
> object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]
> [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514
> debug_print_object+0x80/0xb0
> ...
> [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted
> 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1
> [161.360314] Hardware name: Intel Corporation Rocket Lake Client
> Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138
> 04/21/2022
> [161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915]
> [161.360592] RIP: 0010:debug_print_object+0x80/0xb0
> ...
> [161.361347] debug_object_free+0xeb/0x110
> [161.361362] i915_active_fini+0x14/0x130 [i915]
> [161.361866] release_references+0xfe/0x1f0 [i915]
> [161.362543] i915_vma_parked+0x1db/0x380 [i915]
> [161.363129] __gt_park+0x121/0x230 [i915]
> [161.363515] intel_wakeref_put_last+0x1f/0x70 [i915]
>
> That has been tracked down to be happening when another thread is
> deactivating the VMA inside __active_retire() helper, after the VMA's
> active counter has been already decremented to 0, but before deactivation
> of the VMA's object is reported to the object debugging tool.
>
> We could prevent from that race by serializing i915_active_fini() with
> __active_retire() via ref->tree_lock, but that wouldn't stop the VMA from
> being used, e.g. from __i915_vma_retire() called at the end of
> __active_retire(), after that VMA has been already freed by a concurrent
> i915_vma_destroy() on return from the i915_active_fini(). Then, we should
> rather fix the issue at the VMA level, not in i915_active.
>
> Since __i915_vma_parked() is called from __gt_park() on last put of the
> GT's wakeref, the issue could be addressed by holding the GT wakeref long
> enough for __active_retire() to complete before that wakeref is released
> and the GT parked.
>
> A VMA associated with a request doesn't acquire a GT wakeref by itself.
> Instead, it depends on a wakeref held directly by the request's active
> intel_context for a GT associated with its VM, and indirectly on that
> intel_context's engine wakeref if the engine belongs to the same GT as the
> VMA's VM. In case of single-tile platforms, at least one of those
> wakerefs is usually held long enough for the request's VMA to be
> deactivated on time, before it is destroyed on last put of its VM GT
> wakeref. However, on multi-tile platforms, a request may use a VMA from a
> tile other than the one that hosts the request's engine, then it is
> protected only with the intel_context's VM GT wakeref.
>
> There was an attempt to fix this issue on 2-tile Meteor Lake by acquiring
> an extra wakeref for a Primary GT from i915_gem_do_execbuffer() -- see
> commit f56fe3e91787 ("drm/i915: Fix a VMA UAF for multi-gt platform").
> However, it occurred insufficient -- the issue was still reported by CI.
> That wakeref was released on exit from i915_gem_do_execbuffer(), then
> potentially before completion of the request and deactivation of its
> associated VMAs.
>
> OTOH, CI reports indicate that single-tile platforms also suffer
> sporadically from the same race.
>
> I believe the issue was introduced by commit d93939730347 ("drm/i915:
> Remove the vma refcount") which moved a call to i915_active_fini() from
> a dropped i915_vma_release(), called on last put of the removed VMA kref,
> to i915_vma_parked() processing path called on last put of a GT wakeref.
> However, its visibility to the object debugging tool was suppressed by a
> bug in i915_active that was fixed two weeks later with commit e92eb246feb9
> ("drm/i915/active: Fix missing debug object activation").
>
> Fix the issue by getting a wakeref for the VMA's tile when activating it,
> and putting that wakeref only after the VMA is deactivated. However,
> exclude global GTT from that processing path, otherwise the GPU never goes
> idle. Since __i915_vma_retire() may be called from atomic contexts, use
> async variant of wakeref put.
>
> Having that fixed, stop explicitly acquiring the extra GT0 wakeref from
> inside i915_gem_do_execbuffer(), and also drop an extra call to
> i915_active_wait(), introduced by commit 7a2280e8dcd2 ("drm/i915: Wait for
> active retire before i915_active_fini()") as another insufficient fix for
> this UAF race.
>
> v3: Identify root cause more precisely, and a commit to blame,
> - identify and drop former workarounds,
> - update commit message and description.
> v2: Get the wakeref before VM mutex to avoid circular locking dependency,
> - drop questionable Fixes: tag.
>
> Fixes: d93939730347 ("drm/i915: Remove the vma refcount")
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/8875
> Signed-off-by
Re: [Intel-gfx] [PATCH v2 03/11] drm/dp_mst: Add kunit tests for drm_dp_get_vc_payload_bw()
On Fri, Nov 17, 2023 at 01:04:02PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 16, 2023 at 03:18:33PM +0200, Imre Deak wrote:
> > Add kunit test cases for drm_dp_get_vc_payload_bw() with all the DP1.4
> > and UHBR link configurations.
> >
> > Cc: Lyude Paul
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Imre Deak
> > ---
> > .../gpu/drm/tests/drm_dp_mst_helper_test.c| 145 ++
> > 1 file changed, 145 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
> > b/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
> > index e3c818dfc0e6d..cafb463124f71 100644
> > --- a/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
> > +++ b/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
> > @@ -68,6 +68,150 @@ static void dp_mst_calc_pbn_mode_desc(const struct
> > drm_dp_mst_calc_pbn_mode_test
> > KUNIT_ARRAY_PARAM(drm_dp_mst_calc_pbn_mode, drm_dp_mst_calc_pbn_mode_cases,
> > dp_mst_calc_pbn_mode_desc);
> >
> > +struct drm_dp_mst_calc_pbn_div_test {
> > + int link_rate;
> > + int lane_count;
> > + fixed20_12 expected;
> > +};
> > +
> > +#define fp_init(__int, __frac) { \
> > + .full = (__int) * (1 << 12) + \
> > + (__frac) * (1 << 12) / 10 \
> > +}
> > +
> > +static const struct drm_dp_mst_calc_pbn_div_test
> > drm_dp_mst_calc_pbn_div_dp1_4_cases[] = {
> > + /*
> > +* DP1.4 rates:
> > +* .expected = .link_rate * .lane_count * 0.8000 / 8 / 54 / 100
> > +* UHBR rates:
> > +* .expected = .link_rate * .lane_count * 0.9671 / 8 / 54 / 100
> > +* truncated to 5 decimal places.
> > +*/
> > + {
> > + .link_rate = 162000,
> > + .lane_count = 1,
> > + .expected = fp_init(3, 0),
> > + },
>
> Would be nice to sort this to match the tables in the spec.
> A bit hard to do a quick visual comparison now.
Ok, makes sense.
> > + {
> > + .link_rate = 162000,
> > + .lane_count = 2,
> > + .expected = fp_init(6, 0),
> > + },
> > + {
> > + .link_rate = 162000,
> > + .lane_count = 4,
> > + .expected = fp_init(12, 0),
> > + },
> > + {
> > + .link_rate = 27,
> > + .lane_count = 1,
> > + .expected = fp_init(5, 0),
> > + },
> > + {
> > + .link_rate = 27,
> > + .lane_count = 2,
> > + .expected = fp_init(10, 0),
> > + },
> > + {
> > + .link_rate = 27,
> > + .lane_count = 4,
> > + .expected = fp_init(20, 0),
> > + },
> > + {
> > + .link_rate = 54,
> > + .lane_count = 1,
> > + .expected = fp_init(10, 0),
> > + },
> > + {
> > + .link_rate = 54,
> > + .lane_count = 2,
> > + .expected = fp_init(20, 0),
> > + },
> > + {
> > + .link_rate = 54,
> > + .lane_count = 4,
> > + .expected = fp_init(40, 0),
> > + },
> > + {
> > + .link_rate = 81,
> > + .lane_count = 1,
> > + .expected = fp_init(15, 0),
> > + },
> > + {
> > + .link_rate = 81,
> > + .lane_count = 2,
> > + .expected = fp_init(30, 0),
> > + },
> > + {
> > + .link_rate = 81,
> > + .lane_count = 4,
> > + .expected = fp_init(60, 0),
> > + },
> > + {
> > + .link_rate = 100,
> > + .lane_count = 1,
> > + .expected = fp_init(22, 38657),
> > + },
> > + {
> > + .link_rate = 100,
> > + .lane_count = 2,
> > + .expected = fp_init(44, 77314),
> > + },
> > + {
> > + .link_rate = 100,
> > + .lane_count = 4,
> > + .expected = fp_init(89, 54629),
> > + },
> > + {
> > + .link_rate = 135,
> > + .lane_count = 1,
> > + .expected = fp_init(30, 22187),
> > + },
> > + {
> > + .link_rate = 135,
> > + .lane_count = 2,
> > + .expected = fp_init(60, 44375),
> > + },
> > + {
> > + .link_rate = 135,
> > + .lane_count = 4,
> > + .expected = fp_init(120, 88750),
> > + },
> > + {
> > + .link_rate = 200,
> > + .lane_count = 1,
> > + .expected = fp_init(44, 77314),
> > + },
> > + {
> > + .link_rate = 200,
> > + .lane_count = 2,
> > + .expected = fp_init(89, 54629),
> > + },
> > + {
> > + .link_rate = 200,
> > + .lane_count = 4,
> > + .expected = fp_init(179, 9259), /* 179.09259 */
> > + },
> > +};
> > +
> > +static void drm_test_dp_mst_calc_pbn_div(struct kunit *test)
> > +{
> > + const struct drm_dp_mst_calc_pbn_div_test *params = test->param_value;
> > + /* mgr->dev is only needed by drm_dbg_kms(), but it's not called for
> > the test cases. */
> > + struct drm_dp_mst_topology_mgr mgr = {};
> > +
> > + KUNIT_EXPECT_EQ(test, drm_dp_ge
Re: [PATCH v2 01/11] drm/dp_mst: Store the MST PBN divider value in fixed point format
On Fri, Nov 17, 2023 at 12:56:36PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 16, 2023 at 03:18:31PM +0200, Imre Deak wrote:
> > On UHBR links the PBN divider is a fractional number, accordingly store
> > it in fixed point format. For now drm_dp_get_vc_payload_bw() always
> > returns a whole number and all callers will use only the integer part of
> > it which should preserve the current behavior. The next patch will fix
> > drm_dp_get_vc_payload_bw() for UHBR rates returning a fractional number
> > for those (also accounting for the channel coding efficiency correctly).
> >
> > Cc: Lyude Paul
> > Cc: Harry Wentland
> > Cc: Alex Deucher
> > Cc: Wayne Lin
> > Cc: amd-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Imre Deak
> > ---
> > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++--
> > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 3 ++-
> > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 +++--
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 22 +--
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ++-
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 +++--
> > include/drm/display/drm_dp_mst_helper.h | 7 +++---
> > 7 files changed, 33 insertions(+), 18 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 74f9f02abcdec..12346b21d0b05 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -85,6 +85,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -6909,8 +6910,8 @@ static int dm_encoder_helper_atomic_check(struct
> > drm_encoder *encoder,
> > if (IS_ERR(mst_state))
> > return PTR_ERR(mst_state);
> >
> > - if (!mst_state->pbn_div)
> > - mst_state->pbn_div =
> > dm_mst_get_pbn_divider(aconnector->mst_root->dc_link);
> > + if (!mst_state->pbn_div.full)
> > + mst_state->pbn_div.full =
> > dfixed_const(dm_mst_get_pbn_divider(aconnector->mst_root->dc_link));
>
> Why doesn't that dfixed stuff return the correct type?
AFAICS a follow up change could make dfixed_init() return the correct
type and then change all
fp.full = dfixed_const(A)
to
fp = dfixed_init(A)
>
> Anyways looks mostly mechanical
> Reviewed-by: Ville Syrjälä
>
> >
> > if (!state->duplicated) {
> > int max_bpc = conn_state->max_requested_bpc;
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > index ed784cf27d396..63024393b516e 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > @@ -31,6 +31,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "dm_services.h"
> > #include "amdgpu.h"
> > @@ -210,7 +211,7 @@ static void dm_helpers_construct_old_payload(
> > struct drm_dp_mst_atomic_payload *old_payload)
> > {
> > struct drm_dp_mst_atomic_payload *pos;
> > - int pbn_per_slot = mst_state->pbn_div;
> > + int pbn_per_slot = dfixed_trunc(mst_state->pbn_div);
> > u8 next_payload_vc_start = mgr->next_start_slot;
> > u8 payload_vc_start = new_payload->vc_start_slot;
> > u8 allocated_time_slots;
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > index 9a58e1a4c5f49..d1ba3ae228b08 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > @@ -27,6 +27,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include "dm_services.h"
> > #include "amdgpu.h"
> > #include "amdgpu_dm.h"
> > @@ -941,10 +942,10 @@ static int increase_dsc_bpp(struct drm_atomic_state
> > *state,
> > link_timeslots_used = 0;
> >
> > for (i = 0; i < count; i++)
> > - link_timeslots_used += DIV_ROUND_UP(vars[i + k].pbn,
> > mst_state->pbn_div);
> > + link_timeslots_used += DIV_ROUND_UP(vars[i + k].pbn,
> > dfixed_trunc(mst_state->pbn_div));
> >
> > fair_pbn_alloc =
> > - (63 - link_timeslots_used) / remaining_to_increase *
> > mst_state->pbn_div;
> > + (63 - link_timeslots_used) / remaining_to_increase *
> > dfixed_trunc(mst_state->pbn_div);
> >
> > if (initial_slack[next_index] > fair_pbn_alloc) {
> > vars[next_index].pbn += fair_pbn_alloc;
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 4d72c9a32026e..000d05e80352a 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/d
Re: Use after free with GEM shadow-buffered planes
Hi Am 15.11.23 um 17:32 schrieb Alyssa Ross: [Originally reported at https://gitlab.freedesktop.org/drm/misc/-/issues/33] The following happens in a cycle: • An atomic state is allocated • A plane state is allocated (drm_gem_duplicate_shadow_plane_state()) • Commit (drm_atomic_helper_commit(), possibly nonblocking / asynchronously) • The previous plane state is freed (drm_gem_destroy_shadow_plane_state()) • The atomic state is put We acquire a reference on the state at https://elixir.bootlin.com/linux/v6.5/source/drivers/gpu/drm/drm_atomic_helper.c#L2057 and release it at https://elixir.bootlin.com/linux/v6.5/source/drivers/gpu/drm/drm_atomic_helper.c#L1833 All new sub-state, such as for planes, should be kept allocated during that time. But what happens if a nonblocking commit doesn't get scheduled until a couple of iterations later in the cycle? Plane states are not refcounted, so by that point, the plane state has been freed, and so commit_tail() will encounter a use after free when it accesses the plane state. I think it's assumed that the old plane state can be gone by the time the commit happens. But why would the new plane state? Did you figure this out in your analysis? I encountered this issue using simpledrm on the Asahi kernel based on v6.5, but none of the files I examined to determine that this is a use-after-free have been modified from mainline. I've also reviewed the diff between my kernel and tip of mainline (8f6f76a6a29f), and didn't see anything that would affect this issue. It could be that we're passing the wrong state at https://elixir.bootlin.com/linux/v6.5/source/drivers/gpu/drm/drm_atomic_helper.c#L2919 in some corner case, but I really don't see how. At least that's how it's supposed to work. I'm still trying to get an idea how you end up with an invalid plane state. Best regards Thomas Here's an example of a use after free. It's been a couple of weeks since I thoroughly investigated this, but from memory, in this case, the plane state has been overwritten by a struct drm_crtc_state. Unable to handle kernel paging request at virtual address 00010049 Mem abort info: ESR = 0x9605 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x0005, ISS2 = 0x CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 16k pages, 48-bit VAs, pgdp=00080e0e31b0 [00010049] pgd=08083d390003, p4d=08083d390003, pud=08083db9c003, pmd= Internal error: Oops: 9605 [#1] PREEMPT SMP Modules linked in: overlay uas usb_storage usbhid rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device bnep des_generic libdes md4 brcmfmac_wcc joydev hci_bcm4377 bluetooth brcmfmac brcmutil cfg80211 hid_magicmouse ecdh_generic ecc rfkill snd_soc_macaudio macsmc_hid macsmc_power macsmc_reboot ofpart spi_nor apple_isp videobuf2_dma_sg snd_soc_cs42l84 snd_soc_tas2764 videobuf2_memops clk_apple_nco snd_soc_apple_mca apple_admac videobuf2_v4l2 videodev videobuf2_common mc hid_apple pwm_apple leds_pwm apple_soc_cpufreq xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog nft_compat nf_tables nfnetlink loop tun tap macvlan bridge stp llc fuse zstd zram dm_crypt xhci_plat_hcd xhci_hcd nvmem_spmi_mfd rtc_macsmc gpio_macsmc tps6598x dockchannel_hid simple_mfd_spmi regmap_spmi nvme_apple phy_apple_atc dwc3 pcie_apple typec pci_host_common udc_core apple_sart macsmc_rtkit apple_rtkit_helper apple_dockchannel macsmc apple_rtkit mfd_core spmi_apple_controller nvmem_apple_efuses pinctrl_apple_gpio spi_apple i2c_apple apple_dart apple_mailbox btrfs xor xor_neon raid6_pq CPU: 0 PID: 1095074 Comm: kworker/u16:11 Tainted: G S 6.5.0-asahi #1-NixOS Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) Workqueue: events_unbound commit_work pstate: 2149 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : drm_gem_fb_vunmap+0x18/0x74 lr : drm_gem_end_shadow_fb_access+0x1c/0x2c sp : 800087ea3d00 x29: 800087ea3d00 x28: x27: x26: 800081325000 x25: fef7 x24: 46c5b560 x23: 01fcaa05 x22: x21: 00010001 x20: 46c5b500 x19: 0001 x18: x17: x16: x15: 2e2d5ab0 x14: 0195 x13: x12: 800081310a80 x11: 0001 x10: 1444e7e23f083897 x9 : 6e82f0b7605f292f x8 : 0001249e0f48 x7 : 0004 x6 : 0190 x5 : 0001 x4 : 93c54440 x3 : 0e968000 x2 : 80008077883c x1 : 9ce37498 x0 : 00010001 Call trace: drm_gem_fb_vunmap+0x18/0x74 drm_gem_end_shadow_fb_access+0x1c/0x2c drm_atomic_helper_cleanup_plan
Re: [Intel-gfx] [PATCH v2 02/11] drm/dp_mst: Fix PBN divider calculation for UHBR rates
On Fri, Nov 17, 2023 at 01:00:58PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 16, 2023 at 03:18:32PM +0200, Imre Deak wrote:
> > The current way of calculating the pbn_div value, the link BW per each
> > MTP slot, worked only for DP 1.4 link rates. Fix things up for UHBR
> > rates calculating with the correct channel coding efficiency based on
> > the link rate.
> >
> > v2:
> > - Return the fractional pbn_div value from drm_dp_get_vc_payload_bw().
> >
> > Cc: Lyude Paul
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 13 ++---
> > include/drm/display/drm_dp_helper.h | 13 +
> > 2 files changed, 23 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 000d05e80352a..3fbd5585d5e6c 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -3585,14 +3585,18 @@ static int drm_dp_send_up_ack_reply(struct
> > drm_dp_mst_topology_mgr *mgr,
> > fixed20_12 drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr
> > *mgr,
> > int link_rate, int link_lane_count)
> > {
> > + int ch_coding_efficiency =
> > +
> > drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(link_rate));
> > fixed20_12 ret;
> >
> > if (link_rate == 0 || link_lane_count == 0)
> > drm_dbg_kms(mgr->dev, "invalid link rate/lane count: (%d /
> > %d)\n",
> > link_rate, link_lane_count);
> >
> > - /* See DP v2.0 2.6.4.2,
> > VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
> > - ret.full = dfixed_const(link_rate * link_lane_count / 54000);
> > + /* See DP v2.0 2.6.4.2, 2.7.6.3
> > VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
> > + ret.full = DIV_ROUND_DOWN_ULL(mul_u32_u32(link_rate * link_lane_count,
> > + ch_coding_efficiency),
> > + (100ULL * 8 * 5400) >> 12);
>
> Seems to produce the correct numbers.
>
> >
> > return ret;
> > }
> > @@ -4315,6 +4319,7 @@ int drm_dp_atomic_find_time_slots(struct
> > drm_atomic_state *state,
> > struct drm_dp_mst_atomic_payload *payload = NULL;
> > struct drm_connector_state *conn_state;
> > int prev_slots = 0, prev_bw = 0, req_slots;
> > + fixed20_12 req_slots_fp;
> >
> > topology_state = drm_atomic_get_mst_topology_state(state, mgr);
> > if (IS_ERR(topology_state))
> > @@ -4342,7 +4347,9 @@ int drm_dp_atomic_find_time_slots(struct
> > drm_atomic_state *state,
> > }
> > }
> >
> > - req_slots = DIV_ROUND_UP(pbn, dfixed_trunc(topology_state->pbn_div));
> > + req_slots_fp.full = dfixed_div((fixed20_12)dfixed_init(pbn),
> > topology_state->pbn_div);
>
> dfixed_div() looks super dodgy. It seems to have some kind of hand
> rolled round to closest behaviour, which would imply that this can
> return a rounded down result.
Yes, dfixed_ceil(dfixed_div(..)) doesn't actually round up the result,
thanks for spotting that. It should be instead:
req_slots = DIV_ROUND_UP(dfixed_const(pbn),
topology_state->pbn_div.full);
Fixing the division similarly in patch 8.
>
> > + req_slots_fp.full = dfixed_ceil(req_slots_fp);
> > + req_slots = dfixed_trunc(req_slots_fp);
> >
> > drm_dbg_atomic(mgr->dev, "[CONNECTOR:%d:%s] [MST PORT:%p] TU %d ->
> > %d\n",
> >port->connector->base.id, port->connector->name,
> > diff --git a/include/drm/display/drm_dp_helper.h
> > b/include/drm/display/drm_dp_helper.h
> > index c5f1079acb3b1..863b2e7add29e 100644
> > --- a/include/drm/display/drm_dp_helper.h
> > +++ b/include/drm/display/drm_dp_helper.h
> > @@ -252,6 +252,19 @@ drm_edp_backlight_supported(const u8
> > edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE])
> > return !!(edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP);
> > }
> >
> > +/**
> > + * drm_dp_is_uhbr_rate - Determine if a link rate is UHBR
> > + * @link_rate: link rate in 10kbits/s units
> > + *
> > + * Determine if the provided link rate is an UHBR rate.
> > + *
> > + * Returns: %True if @link_rate is an UHBR rate.
> > + */
> > +static inline bool drm_dp_is_uhbr_rate(int link_rate)
> > +{
> > + return link_rate >= 100;
> > +}
> > +
> > /*
> > * DisplayPort AUX channel
> > */
> > --
> > 2.39.2
>
> --
> Ville Syrjälä
> Intel
Re: [PATCH v7 0/8] Improve test coverage of TTM
No idea how you managed to do this, but now Amar is CCed on the patches he already tested and *not* CCed on the new ones and the cover letter :) @Amar can you pick up the latest patches from the mailing list and give them another round of testing? I will try to find time to give that some review. Thanks, Christian. Am 17.11.23 um 09:49 schrieb Karolina Stolarek: Add tests for building blocks of the TTM subsystem, such as ttm_resource, ttm_resource_manager, ttm_tt and ttm_buffer_object. This series covers basic functions such as initialization, allocation and clean-up of each struct. Testing of ttm_buffer_object also includes locking and unlocking the object for validation, with special scenarios such as an interrupted wait or deadlock. Some of the test cases check the bulk move mechanism and how it interacts with pinned buffers. This is to be seen if we want to add dedicated testing for bulk move or not. The resource allocation subtests use ttm_sys_manager for now. Resources that don't use system memory will be indirectly tested via tests for ttm_bo_validate()/ttm_bo_init_validate(), using a mock resource manager. Use kunit_tool script to manually run all the tests: $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/ttm/tests To build a kernel with TTM KUnit tests, first enable CONFIG_KUNIT, and then CONFIG_DRM_TTM_KUNIT_TEST. Many thanks, Karolina v7: - Drop size argument from ttm_place_kunit_init(), it's no longer needed - Delete a TODO comment from ttm_bo_validate_tests.c - First evict BOs before calling ttm_resource_manager_set_used() in ttm_mock_manager_fini() - Stop calling ttm_resource_manager_cleanup() as a part of the mock manager fini sequence. It frees a move fence that is allocated via KUnit allocator, which gets freed again as a part of the test cleanup - Set use_tt to true in mock manager and stop passing in the flag for it - Make ttm_dev_empty_funcs static (drivers/gpu/drm/ttm/tests/ttm_tt_test.c:232:25: sparse: sparse: symbol 'ttm_dev_empty_funcs' was not declared. Should it be static?) - Cast bo->base.resv->fences to a generic pointer before it's checked by KUnit (drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c:98:9: sparse: sparse: incompatible types in comparison expression (different base types)) - Clean up mock managers in ttm_bo_validate_move_fence_not_signaled subtest v6: - Include tests for ttm_bo_init_reserved() and ttm_bo_validate(), with a mock resource manager (patches 6-8; no eviction testing) - Add ttm_test_devices_all_init() helper to also init ttm_device instance - Remove fpfn and lpfn from ttm_place_kunit_init() helper -- these fields are neither used nor tested v5: - Actually use the page_flags parameter in ttm_tt_simple_create() v4: - First unreserve the object before calling ww_acquire_fini() in ttm_bo_reserve_double_resv subtest - Silence lockdep in ttm_bo_reserve_deadlock subtest (open to suggestions how to fix it in a different way) - Use a genuine GEM object in ttm_buffer_object instead of an empty one v3: - Instead of modifying the main TTM Makefile, use EXPORT_SYMBOL_FOR_TESTS_ONLY() macro for symbols that are tested but not widely exported. Thanks to this change, TTM tests can be built as modules, even when non-exported functions are used - Change the description of a patch that fixes ttm_pool_pre_populated() v2: - Remove Makefile for KUnit tests and move the definitions to the TTM's one - Switch on CONFIG_DRM_TTM_KUNIT_TEST=m so the tests and TTM module are built as one. This allows building the tests as a module, even if it uses functions that are not exported - Fix ttm_pool_pre_populated(); a wrong flag was passed to ttm_tt_kunit_init() function Karolina Stolarek (8): drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man drm/ttm/tests: Add tests for ttm_tt drm/ttm/tests: Add tests for ttm_bo functions drm/ttm/tests: Fix argument in ttm_tt_kunit_init() drm/ttm/tests: Use an init function from the helpers lib drm/ttm/tests: Test simple BO creation and validation drm/ttm/tests: Add tests with mock resource managers drm/ttm/tests: Add test cases dependent on fence signaling drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/ttm/tests/.kunitconfig| 1 + drivers/gpu/drm/ttm/tests/Makefile| 5 + drivers/gpu/drm/ttm/tests/ttm_bo_test.c | 619 ++ .../gpu/drm/ttm/tests/ttm_bo_validate_test.c | 795 ++ drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 109 ++- drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h | 7 + drivers/gpu/drm/ttm/tests/ttm_mock_manager.c | 206 + drivers/gpu/drm/ttm/tests/ttm_mock_manager.h | 31 + drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 3 +- drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335 drivers/gpu/drm/ttm/tests/ttm_tt_test.c
Re: [PATCH 11/32] hid/picolcd_fb: Set FBINFO_VIRTFB flag
On Thu, 16 Nov 2023 11:27:55 +0100 Javier Martinez Canillas wrote: > Thomas Zimmermann writes: > > > The picolcd_fb driver operates on system memory. Mark the framebuffer > > accordingly. Helpers operating on the framebuffer memory will test > > for the presence of this flag. > > > > Signed-off-by: Thomas Zimmermann > > Cc: "Bruno Prémont" > > Cc: Jiri Kosina > > Cc: Benjamin Tissoires > > Cc: linux-in...@vger.kernel.org > > --- > > drivers/hid/hid-picolcd_fb.c | 1 + > > 1 file changed, 1 insertion(+) > > > > Reviewed-by: Javier Martinez Canillas Acked-by: Bruno Prémont
[PATCH v2] dma-buf: heaps: Introduce cma_heap_add() for non-default CMA heap
From: Kunihiko Hayashi
Currently dma-buf heaps can handle only default CMA. This exposes
__add_cma_heap(), renamed to cma_heap_add(), as a public API to
initialize CMA heaps from a pointer to a CMA region.
At first, the driver calls of_reserved_mem_device_init() to set
memory-region property associated with reserved-memory defined as CMA
to the device. And when the driver calls this cma_heap_add() with the
struct cma attached to the device, the CMA will be added to dma-buf
heaps.
For example, prepare CMA node named "linux,cma@1000" and
specify the node for memory-region property. After the above calls
in the driver, a device file "/dev/dma_heap/linux,cma@1000"
associated with the CMA become available as dma-buf heaps.
Signed-off-by: Kunihiko Hayashi
[quic_jasks...@quicinc.com: Use struct cma as the function argument]
Signed-off-by: Jaskaran Singh
---
Reviving this patch as per discussions on the MediaTek Secure Heap patch
series[1]. There is now a potential client of the cma_heap_add() API.
An unaddressed problem in this patch is the proper parsing of heap
names. Naming convention for fixed address heaps in the devicetree is of
the format "[heap name]@[fixed address]", for example
"audio-heap@88b0". Exposing heaps this way to userspace could
prove erroneous as the usecases fulfilled by these heaps are the same
across individual SoCs. Userspace clients of these heaps might expect a
more consistent interface. Any feedback on this is appreciated.
Changes v1->v2:
- Change the function argument for dma_heap_add_cma() from struct
device to struct cma as per the discussion on [1].
- In lieu of the above point, discard dma_heap_add_cma() and instead
expose the existing __add_cma_heap() as cma_heap_add().
- Make minor modifications to the commit message based on the changes in
this version. Retain most of the original commit message.
v1:
https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunih...@socionext.com/
[1]
https://lore.kernel.org/lkml/20230911023038.30649-1-yong...@mediatek.com/T/#m5184a1e13767bb656a4a3d9bf5a1fd7450e42eb7
drivers/dma-buf/heaps/cma_heap.c | 12 ++--
include/linux/dma-heap.h | 10 ++
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index ee899f8e6721..b3bef8206e8b 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -367,7 +367,14 @@ static const struct dma_heap_ops cma_heap_ops = {
.allocate = cma_heap_allocate,
};
-static int __add_cma_heap(struct cma *cma, void *data)
+/**
+ * cma_heap_add - adds a CMA heap to dmabuf heaps
+ * @cma: pointer to the CMA pool to register the heap for
+ * @data: unused
+ *
+ * Returns 0 on success. Else, returns errno.
+ */
+int cma_heap_add(struct cma *cma, void *data)
{
struct cma_heap *cma_heap;
struct dma_heap_export_info exp_info;
@@ -391,6 +398,7 @@ static int __add_cma_heap(struct cma *cma, void *data)
return 0;
}
+EXPORT_SYMBOL_GPL(cma_heap_add);
static int add_default_cma_heap(void)
{
@@ -398,7 +406,7 @@ static int add_default_cma_heap(void)
int ret = 0;
if (default_cma)
- ret = __add_cma_heap(default_cma, NULL);
+ ret = cma_heap_add(default_cma, NULL);
return ret;
}
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 0c05561cad6e..adcd462825a8 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -12,6 +12,7 @@
#include
#include
+struct cma;
struct dma_heap;
/**
@@ -65,4 +66,13 @@ const char *dma_heap_get_name(struct dma_heap *heap);
*/
struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
+#ifdef CONFIG_DMABUF_HEAPS_CMA
+int cma_heap_add(struct cma *cma, void *data);
+#else
+static inline int cma_heap_add(struct cma *cma, void *data)
+{
+ return -EINVAL;
+}
+#endif /* CONFIG_DMABUF_HEAPS_CMA */
+
#endif /* _DMA_HEAPS_H */
--
2.17.1
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
On Fri, Nov 17, 2023 at 12:24:22PM +0800, Sui Jingfeng wrote: > Hi, > > On 2023/11/16 23:23, Dmitry Baryshkov wrote: > > > > > Then you will need some way (fwnode?) to > > > > > discover the bridge chain. And at the last point you will get into the > > > > > device data and/or properties business. > > > > > > > > > No, leave that chance to a more better programmer and forgive me please, > > > > too difficult, I'm afraid of not able to solve. Thanks a lot for the > > > > trust! > > From my point of view: no. > > I respect the fact that the community prefer generic mechanisms. > If our approach is not what the community want, can I switch back > to my previous solution? By your previous solution, you mean rolling your own bridge driver? If so, then no, it's not acceptable either. > I can reduce the duplication of our localized it66121 driver to a > minimal, rewrite it until it meets the community's requirement. I know > our device looks weird and our approach is not elegant. I'm glad we agree then :) > But at the very least, we could not mess the community's design up by > localize. Otherwise, I don't know what is the better approach to solve > such a problem. I think there's a gap between what we want from you and what you want from us. What we really care about is maintenance. In other words, it's mostly about two things: - Once you and/or your company have moved on to other things, how easy it will be for us to keep that driver in good shape, and how much it will hold back any future development. - If we want to do a big rework, how much your driver will stand in the way. That's pretty much all that we care about, and we will very much prefer not to merge a driver in the first place than to have to maintain it for 10y while it stands in our way and we don't have any real documentation or help. So by making it "not weird" or "elegant" or whatever we can call it, you effectively remove any concern we might have about merging your driver, and there's only an upside (more hardware support and company involvement is good!). So you're making it easy for you too. Maxime signature.asc Description: PGP signature
Re: 6.7/regression/KASAN: null-ptr-deref in amdgpu_ras_reset_error_count+0x2d6
On Thu, Nov 16, 2023 at 11:56 PM Alex Deucher wrote: > > This patch should address the issue: > https://patchwork.freedesktop.org/patch/567101/ > If you still see issues, you may also need this series: > https://patchwork.freedesktop.org/series/126220/ > > Alex Thanks. The first one patch is enough. Tested-on: 7900XTX, 6900XT and 6800M. Tested-by: Mikhail Gavrilov -- Best Regards, Mike Gavrilov.
[PATCH v3 1/1] backlight: pwm_bl: Use dev_err_probe
Use dev_err_probe to simplify error paths. Also let dev_err_probe handle
the -EPROBE_DEFER case and add an entry to
/sys/kernel/debug/devices_deferred when deferred.
Signed-off-by: Alexander Stein
---
Changes in v3:
* Fix alignment on continuation
* Small fixes to commit message
Changes in v2:
* Use dev_err_probe in more places in probe function (as suggested by Uwe)
* Adjusted commit message
drivers/video/backlight/pwm_bl.c | 34 +---
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 289bd9ce4d36d..5bc9c6c075710 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -461,10 +461,9 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
if (!data) {
ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
- if (ret < 0) {
- dev_err(&pdev->dev, "failed to find platform data\n");
- return ret;
- }
+ if (ret < 0)
+ return dev_err_probe(&pdev->dev, ret,
+"failed to find platform data\n");
data = &defdata;
}
@@ -493,24 +492,27 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
GPIOD_ASIS);
if (IS_ERR(pb->enable_gpio)) {
- ret = PTR_ERR(pb->enable_gpio);
+ ret = dev_err_probe(&pdev->dev, PTR_ERR(pb->enable_gpio),
+ "failed to acquire enable GPIO\n");
goto err_alloc;
}
pb->power_supply = devm_regulator_get_optional(&pdev->dev, "power");
if (IS_ERR(pb->power_supply)) {
ret = PTR_ERR(pb->power_supply);
- if (ret == -ENODEV)
+ if (ret == -ENODEV) {
pb->power_supply = NULL;
- else
+ } else {
+ dev_err_probe(&pdev->dev, ret,
+ "failed to acquire power regulator\n");
goto err_alloc;
+ }
}
pb->pwm = devm_pwm_get(&pdev->dev, NULL);
if (IS_ERR(pb->pwm)) {
- ret = PTR_ERR(pb->pwm);
- if (ret != -EPROBE_DEFER)
- dev_err(&pdev->dev, "unable to request PWM\n");
+ ret = dev_err_probe(&pdev->dev, PTR_ERR(pb->pwm),
+ "unable to request PWM\n");
goto err_alloc;
}
@@ -530,8 +532,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
ret = pwm_apply_state(pb->pwm, &state);
if (ret) {
- dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
- ret);
+ dev_err_probe(&pdev->dev, ret,
+ "failed to apply initial PWM state");
goto err_alloc;
}
@@ -568,8 +570,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
ret = pwm_backlight_brightness_default(&pdev->dev, data,
state.period);
if (ret < 0) {
- dev_err(&pdev->dev,
- "failed to setup default brightness table\n");
+ dev_err_probe(&pdev->dev, ret,
+ "failed to setup default brightness
table\n");
goto err_alloc;
}
@@ -597,8 +599,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
bl = backlight_device_register(dev_name(&pdev->dev), &pdev->dev, pb,
&pwm_backlight_ops, &props);
if (IS_ERR(bl)) {
- dev_err(&pdev->dev, "failed to register backlight\n");
- ret = PTR_ERR(bl);
+ ret = dev_err_probe(&pdev->dev, PTR_ERR(bl),
+ "failed to register backlight\n");
goto err_alloc;
}
--
2.34.1
Re: [v7,4/8] drm/ttm/tests: Fix argument in ttm_tt_kunit_init()
Reviewed-by: Dominik Karol Piątkowski
Re: [PATCH v2 4/5] drm/plane: Extend damage tracking kernel-doc
Hi Am 16.11.23 um 16:24 schrieb Pekka Paalanen: On Thu, 16 Nov 2023 13:34:07 +0100 Thomas Zimmermann wrote: Hi Am 16.11.23 um 13:14 schrieb Simon Ser: On Thursday, November 16th, 2023 at 13:06, Thomas Zimmermann wrote: + * Note that there are two types of damage handling: frame damage and buffer + * damage. The type of damage handling implemented depends on a driver's upload + * target. Drivers implementing a per-plane or per-CRTC upload target need to + * handle frame damage while drivers implementing a per-buffer upload target + * need to handle buffer damage. + * + * The existing damage helpers only support the frame damage type, there is no + * buffer age support or similar damage accumulation algorithm implemented yet. + * + * Only drivers handling frame damage can use the mentiored damage helpers to Typo: mentioned + * iterate over the damaged regions. Drivers that handle buffer damage, need to + * set &struct drm_plane_state.ignore_damage_clips as an indication to + * drm_atomic_helper_damage_iter_init() that the damage clips should be ignored. + * In that case, the returned damage rectangle is the &drm_plane_state.src since + * a full plane update should happen. + * + * For more information about the two type of damage, see: + * https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_swap_buffers_with_damage.txt + * https://emersion.fr/blog/2019/intro-to-damage-tracking/ One thought you might want to consider. These URLs are helpful. The only issue I have is that frame damage and buffer damage are user-space concepts. The kernel bug is that damage handling expects the backing storage/upload buffer not to change for a given plane. If the upload buffer changes between page flips, the new upload buffer has to be updated as a whole. Hence no damage handling then. Why would these concepts be specific to user-space? The kernel could better handle buffer damage instead of forcing full damage, by doing something similar to what user-space does. The terms 'frame damage' and 'buffer damage' do not exist in the kernel. The problem can be better described in wording that is common within the context of the kernel drivers. What terms does the kernel use for these two different concepts of damage? None AFAIK. Damage is relative to the plane's backing storage/upload buffer. That's frame damage. We never needed a name for buffer damage as we don't support it. Best regards Thomas Thanks, pq -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [pull] amdgpu drm-fixes-6.7
On Fri, Nov 17, 2023 at 01:34:41AM -0500, Alex Deucher wrote: > Hi Dave, Sima, > > Fixes for 6.7. > > The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86: > > Linux 6.7-rc1 (2023-11-12 16:19:07 -0800) > > are available in the Git repository at: > > https://gitlab.freedesktop.org/agd5f/linux.git > tags/amd-drm-fixes-6.7-2023-11-17 > > for you to fetch changes up to e8c2d3e25b844ad8f7c8b269a7cfd65285329264: > > drm/amdgpu/gmc9: disable AGP aperture (2023-11-17 00:58:41 -0500) Pulled to drm-fixes, thanks! -Sima > > > amd-drm-fixes-6.7-2023-11-17: > > amdgpu: > - DMCUB fixes > - SR-IOV fix > - GMC9 fix > - Documentation fix > - DSC MST fix > - CS chunk parsing fix > - SMU13.0.6 fixes > - 8K tiled display fix > - Fix potential NULL pointer dereferences > - Cursor lag fix > - Backlight fix > - DCN s0ix fix > - XGMI fix > - DCN encoder disable logic fix > - AGP aperture fixes > > > Alex Deucher (5): > drm/amdgpu/gmc11: fix logic typo in AGP check > drm/amdgpu: add a module parameter to control the AGP aperture > drm/amdgpu/gmc11: disable AGP aperture > drm/amdgpu/gmc10: disable AGP aperture > drm/amdgpu/gmc9: disable AGP aperture > > Asad Kamal (2): > drm/amd/pm: Update metric table for smu v13_0_6 > drm/amd/pm: Fill pcie error counters for gpu v1_4 > > Duncan Ma (1): > drm/amd/display: Negate IPS allow and commit bits > > Fangzhi Zuo (1): > drm/amd/display: Fix DSC not Enabled on Direct MST Sink > > José Pekkarinen (1): > drm/amd/display: fix NULL dereference > > Le Ma (1): > drm/amdgpu: finalizing mem_partitions at the end of GMC v9 sw_fini > > Lewis Huang (1): > drm/amd/display: Change the DMCUB mailbox memory location from FB to > inbox > > Lijo Lazar (1): > drm/amd/pm: Don't send unload message for reset > > Mario Limonciello (1): > drm/amd/display: fix a NULL pointer dereference in amdgpu_dm_i2c_xfer() > > Muhammad Ahmed (1): > drm/amd/display: Add null checks for 8K60 lightup > > Nicholas Kazlauskas (1): > drm/amd/display: Guard against invalid RPTR/WPTR being set > > Nicholas Susanto (1): > drm/amd/display: Fix encoder disable logic > > Paul Hsieh (1): > drm/amd/display: Clear dpcd_sink_ext_caps if not set > > Shiwu Zhang (1): > drm/amdgpu: add and populate the port num into xgmi topology info > > Srinivasan Shanmugam (1): > drm/amdgpu: Address member 'ring' not described in 'amdgpu_ vce, > uvd_entity_init()' > > Tianci Yin (1): > drm/amd/display: Enable fast plane updates on DCN3.2 and above > > Victor Lu (1): > drm/amdgpu: Do not program VF copy regs in mmhub v1.8 under SRIOV (v2) > > Yang Wang (1): > drm/amdgpu: fix ras err_data null pointer issue in amdgpu_ras.c > > YuanShang (1): > drm/amdgpu: correct chunk_ptr to a pointer to chunk. > > drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 + > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 10 + > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 5 +++ > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h| 1 + > drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 1 + > drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c| 1 + > drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 2 +- > drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 5 ++- > drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 7 +-- > drivers/gpu/drm/amd/amdgpu/mmhub_v1_8.c| 6 +-- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ++- > .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 5 +-- > .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 29 ++--- > .../amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c | 18 > drivers/gpu/drm/amd/display/dc/core/dc.c | 6 +-- > drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 3 ++ > drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 10 ++--- > drivers/gpu/drm/amd/display/dc/dc_types.h | 1 + > .../display/dc/dcn35/dcn35_dio_stream_encoder.c| 10 ++--- > .../gpu/drm/amd/display/dc/link/link_detection.c | 3 ++ > drivers/gpu/drm/amd/display/dmub/dmub_srv.h| 22 ++ > drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c| 50 > +- > .../amd/pm/swsmu/inc/pmfw_if/smu_v13_0_6_pmfw.h| 10 - > .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 10 - > 26 files changed, 160 insertions(+), 84 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH v2 03/11] drm/dp_mst: Add kunit tests for drm_dp_get_vc_payload_bw()
On Thu, Nov 16, 2023 at 03:18:33PM +0200, Imre Deak wrote:
> Add kunit test cases for drm_dp_get_vc_payload_bw() with all the DP1.4
> and UHBR link configurations.
>
> Cc: Lyude Paul
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Imre Deak
> ---
> .../gpu/drm/tests/drm_dp_mst_helper_test.c| 145 ++
> 1 file changed, 145 insertions(+)
>
> diff --git a/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
> b/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
> index e3c818dfc0e6d..cafb463124f71 100644
> --- a/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_dp_mst_helper_test.c
> @@ -68,6 +68,150 @@ static void dp_mst_calc_pbn_mode_desc(const struct
> drm_dp_mst_calc_pbn_mode_test
> KUNIT_ARRAY_PARAM(drm_dp_mst_calc_pbn_mode, drm_dp_mst_calc_pbn_mode_cases,
> dp_mst_calc_pbn_mode_desc);
>
> +struct drm_dp_mst_calc_pbn_div_test {
> + int link_rate;
> + int lane_count;
> + fixed20_12 expected;
> +};
> +
> +#define fp_init(__int, __frac) { \
> + .full = (__int) * (1 << 12) + \
> + (__frac) * (1 << 12) / 10 \
> +}
> +
> +static const struct drm_dp_mst_calc_pbn_div_test
> drm_dp_mst_calc_pbn_div_dp1_4_cases[] = {
> + /*
> + * DP1.4 rates:
> + * .expected = .link_rate * .lane_count * 0.8000 / 8 / 54 / 100
> + * UHBR rates:
> + * .expected = .link_rate * .lane_count * 0.9671 / 8 / 54 / 100
> + * truncated to 5 decimal places.
> + */
> + {
> + .link_rate = 162000,
> + .lane_count = 1,
> + .expected = fp_init(3, 0),
> + },
Would be nice to sort this to match the tables in the spec.
A bit hard to do a quick visual comparison now.
> + {
> + .link_rate = 162000,
> + .lane_count = 2,
> + .expected = fp_init(6, 0),
> + },
> + {
> + .link_rate = 162000,
> + .lane_count = 4,
> + .expected = fp_init(12, 0),
> + },
> + {
> + .link_rate = 27,
> + .lane_count = 1,
> + .expected = fp_init(5, 0),
> + },
> + {
> + .link_rate = 27,
> + .lane_count = 2,
> + .expected = fp_init(10, 0),
> + },
> + {
> + .link_rate = 27,
> + .lane_count = 4,
> + .expected = fp_init(20, 0),
> + },
> + {
> + .link_rate = 54,
> + .lane_count = 1,
> + .expected = fp_init(10, 0),
> + },
> + {
> + .link_rate = 54,
> + .lane_count = 2,
> + .expected = fp_init(20, 0),
> + },
> + {
> + .link_rate = 54,
> + .lane_count = 4,
> + .expected = fp_init(40, 0),
> + },
> + {
> + .link_rate = 81,
> + .lane_count = 1,
> + .expected = fp_init(15, 0),
> + },
> + {
> + .link_rate = 81,
> + .lane_count = 2,
> + .expected = fp_init(30, 0),
> + },
> + {
> + .link_rate = 81,
> + .lane_count = 4,
> + .expected = fp_init(60, 0),
> + },
> + {
> + .link_rate = 100,
> + .lane_count = 1,
> + .expected = fp_init(22, 38657),
> + },
> + {
> + .link_rate = 100,
> + .lane_count = 2,
> + .expected = fp_init(44, 77314),
> + },
> + {
> + .link_rate = 100,
> + .lane_count = 4,
> + .expected = fp_init(89, 54629),
> + },
> + {
> + .link_rate = 135,
> + .lane_count = 1,
> + .expected = fp_init(30, 22187),
> + },
> + {
> + .link_rate = 135,
> + .lane_count = 2,
> + .expected = fp_init(60, 44375),
> + },
> + {
> + .link_rate = 135,
> + .lane_count = 4,
> + .expected = fp_init(120, 88750),
> + },
> + {
> + .link_rate = 200,
> + .lane_count = 1,
> + .expected = fp_init(44, 77314),
> + },
> + {
> + .link_rate = 200,
> + .lane_count = 2,
> + .expected = fp_init(89, 54629),
> + },
> + {
> + .link_rate = 200,
> + .lane_count = 4,
> + .expected = fp_init(179, 9259), /* 179.09259 */
> + },
> +};
> +
> +static void drm_test_dp_mst_calc_pbn_div(struct kunit *test)
> +{
> + const struct drm_dp_mst_calc_pbn_div_test *params = test->param_value;
> + /* mgr->dev is only needed by drm_dbg_kms(), but it's not called for
> the test cases. */
> + struct drm_dp_mst_topology_mgr mgr = {};
> +
> + KUNIT_EXPECT_EQ(test, drm_dp_get_vc_payload_bw(&mgr, params->link_rate,
> params->lane_count).full,
> + params->expected.full);
> +}
> +
> +static void dp_mst_calc_p
Re: [Intel-gfx] [PATCH v2 02/11] drm/dp_mst: Fix PBN divider calculation for UHBR rates
On Thu, Nov 16, 2023 at 03:18:32PM +0200, Imre Deak wrote:
> The current way of calculating the pbn_div value, the link BW per each
> MTP slot, worked only for DP 1.4 link rates. Fix things up for UHBR
> rates calculating with the correct channel coding efficiency based on
> the link rate.
>
> v2:
> - Return the fractional pbn_div value from drm_dp_get_vc_payload_bw().
>
> Cc: Lyude Paul
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 13 ++---
> include/drm/display/drm_dp_helper.h | 13 +
> 2 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 000d05e80352a..3fbd5585d5e6c 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3585,14 +3585,18 @@ static int drm_dp_send_up_ack_reply(struct
> drm_dp_mst_topology_mgr *mgr,
> fixed20_12 drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr
> *mgr,
> int link_rate, int link_lane_count)
> {
> + int ch_coding_efficiency =
> +
> drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(link_rate));
> fixed20_12 ret;
>
> if (link_rate == 0 || link_lane_count == 0)
> drm_dbg_kms(mgr->dev, "invalid link rate/lane count: (%d /
> %d)\n",
> link_rate, link_lane_count);
>
> - /* See DP v2.0 2.6.4.2,
> VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
> - ret.full = dfixed_const(link_rate * link_lane_count / 54000);
> + /* See DP v2.0 2.6.4.2, 2.7.6.3
> VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
> + ret.full = DIV_ROUND_DOWN_ULL(mul_u32_u32(link_rate * link_lane_count,
> + ch_coding_efficiency),
> + (100ULL * 8 * 5400) >> 12);
Seems to produce the correct numbers.
>
> return ret;
> }
> @@ -4315,6 +4319,7 @@ int drm_dp_atomic_find_time_slots(struct
> drm_atomic_state *state,
> struct drm_dp_mst_atomic_payload *payload = NULL;
> struct drm_connector_state *conn_state;
> int prev_slots = 0, prev_bw = 0, req_slots;
> + fixed20_12 req_slots_fp;
>
> topology_state = drm_atomic_get_mst_topology_state(state, mgr);
> if (IS_ERR(topology_state))
> @@ -4342,7 +4347,9 @@ int drm_dp_atomic_find_time_slots(struct
> drm_atomic_state *state,
> }
> }
>
> - req_slots = DIV_ROUND_UP(pbn, dfixed_trunc(topology_state->pbn_div));
> + req_slots_fp.full = dfixed_div((fixed20_12)dfixed_init(pbn),
> topology_state->pbn_div);
dfixed_div() looks super dodgy. It seems to have some kind of hand
rolled round to closest behaviour, which would imply that this can
return a rounded down result.
> + req_slots_fp.full = dfixed_ceil(req_slots_fp);
> + req_slots = dfixed_trunc(req_slots_fp);
>
> drm_dbg_atomic(mgr->dev, "[CONNECTOR:%d:%s] [MST PORT:%p] TU %d ->
> %d\n",
> port->connector->base.id, port->connector->name,
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index c5f1079acb3b1..863b2e7add29e 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -252,6 +252,19 @@ drm_edp_backlight_supported(const u8
> edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE])
> return !!(edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP);
> }
>
> +/**
> + * drm_dp_is_uhbr_rate - Determine if a link rate is UHBR
> + * @link_rate: link rate in 10kbits/s units
> + *
> + * Determine if the provided link rate is an UHBR rate.
> + *
> + * Returns: %True if @link_rate is an UHBR rate.
> + */
> +static inline bool drm_dp_is_uhbr_rate(int link_rate)
> +{
> + return link_rate >= 100;
> +}
> +
> /*
> * DisplayPort AUX channel
> */
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [PATCH v2 01/11] drm/dp_mst: Store the MST PBN divider value in fixed point format
On Thu, Nov 16, 2023 at 03:18:31PM +0200, Imre Deak wrote:
> On UHBR links the PBN divider is a fractional number, accordingly store
> it in fixed point format. For now drm_dp_get_vc_payload_bw() always
> returns a whole number and all callers will use only the integer part of
> it which should preserve the current behavior. The next patch will fix
> drm_dp_get_vc_payload_bw() for UHBR rates returning a fractional number
> for those (also accounting for the channel coding efficiency correctly).
>
> Cc: Lyude Paul
> Cc: Harry Wentland
> Cc: Alex Deucher
> Cc: Wayne Lin
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Imre Deak
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++--
> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 3 ++-
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 +++--
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 22 +--
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ++-
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 +++--
> include/drm/display/drm_dp_mst_helper.h | 7 +++---
> 7 files changed, 33 insertions(+), 18 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 74f9f02abcdec..12346b21d0b05 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -85,6 +85,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -6909,8 +6910,8 @@ static int dm_encoder_helper_atomic_check(struct
> drm_encoder *encoder,
> if (IS_ERR(mst_state))
> return PTR_ERR(mst_state);
>
> - if (!mst_state->pbn_div)
> - mst_state->pbn_div =
> dm_mst_get_pbn_divider(aconnector->mst_root->dc_link);
> + if (!mst_state->pbn_div.full)
> + mst_state->pbn_div.full =
> dfixed_const(dm_mst_get_pbn_divider(aconnector->mst_root->dc_link));
Why doesn't that dfixed stuff return the correct type?
Anyways looks mostly mechanical
Reviewed-by: Ville Syrjälä
>
> if (!state->duplicated) {
> int max_bpc = conn_state->max_requested_bpc;
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index ed784cf27d396..63024393b516e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> #include "dm_services.h"
> #include "amdgpu.h"
> @@ -210,7 +211,7 @@ static void dm_helpers_construct_old_payload(
> struct drm_dp_mst_atomic_payload *old_payload)
> {
> struct drm_dp_mst_atomic_payload *pos;
> - int pbn_per_slot = mst_state->pbn_div;
> + int pbn_per_slot = dfixed_trunc(mst_state->pbn_div);
> u8 next_payload_vc_start = mgr->next_start_slot;
> u8 payload_vc_start = new_payload->vc_start_slot;
> u8 allocated_time_slots;
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 9a58e1a4c5f49..d1ba3ae228b08 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include "dm_services.h"
> #include "amdgpu.h"
> #include "amdgpu_dm.h"
> @@ -941,10 +942,10 @@ static int increase_dsc_bpp(struct drm_atomic_state
> *state,
> link_timeslots_used = 0;
>
> for (i = 0; i < count; i++)
> - link_timeslots_used += DIV_ROUND_UP(vars[i + k].pbn,
> mst_state->pbn_div);
> + link_timeslots_used += DIV_ROUND_UP(vars[i + k].pbn,
> dfixed_trunc(mst_state->pbn_div));
>
> fair_pbn_alloc =
> - (63 - link_timeslots_used) / remaining_to_increase *
> mst_state->pbn_div;
> + (63 - link_timeslots_used) / remaining_to_increase *
> dfixed_trunc(mst_state->pbn_div);
>
> if (initial_slack[next_index] > fair_pbn_alloc) {
> vars[next_index].pbn += fair_pbn_alloc;
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 4d72c9a32026e..000d05e80352a 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -43,6 +43,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -3578,16 +3579,22 @@ static int drm_dp_send_up_ack_reply(struct
> drm_dp_mst_topology_mgr *mgr,
> * value is in units of PBNs/(timeslots/1 MTP). This value can be used to
> * convert the number of PBNs required for a given stream to the number of
>
Re: [PULL] drm-misc-fixes
On Thu, Nov 16, 2023 at 02:48:52PM +0100, Maarten Lankhorst wrote: > Hi Dave, Daniel, > > Small pull request, mostly nouveau fixes. > > Cheers, > ~Maarten > > Mostly drm-misc-fixes-2023-11-16: > Assorted fixes for v6.7-rc2: > - Nouveau GSP fixes. > - Fix nouveau driver load without display. > - Use rwlock for nouveau's event lock to break a lockdep splat. > - Add orientation quirk for Lenovo Legion Go. > - Fix build failure in IVPU. > The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86: > > Linux 6.7-rc1 (2023-11-12 16:19:07 -0800) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-11-16 Pulled into drm-fixes, thanks! -Sima > > for you to fetch changes up to ae1aadb1eb8d3cbc52e42bee71d67bd4a71f9f07: > > nouveau: don't fail driver load if no display hw present. (2023-11-15 > 18:23:31 +0100) > > > Assorted fixes for v6.7-rc2: > - Nouveau GSP fixes. > - Fix nouveau driver load without display. > - Use rwlock for nouveau's event lock to break a lockdep splat. > - Add orientation quirk for Lenovo Legion Go. > - Fix build failure in IVPU. > > > Arnd Bergmann (1): > accel/ivpu: avoid build failure with CONFIG_PM=n > > Brenton Simpson (1): > drm: panel-orientation-quirks: Add quirk for Lenovo Legion Go > > Dan Carpenter (2): > nouveau/gsp/r535: uninitialized variable in r535_gsp_acpi_mux_id() > nouveau/gsp/r535: Fix a NULL vs error pointer bug > > Dave Airlie (2): > nouveau: use an rwlock for the event lock. > nouveau: don't fail driver load if no display hw present. > > drivers/accel/ivpu/ivpu_pm.c | 3 --- > drivers/gpu/drm/drm_panel_orientation_quirks.c| 6 ++ > drivers/gpu/drm/nouveau/include/nvkm/core/event.h | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_display.c | 5 + > drivers/gpu/drm/nouveau/nvkm/core/event.c | 12 ++-- > drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 6 +++--- > 6 files changed, 22 insertions(+), 14 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v5 0/7] drm: Reuse temporary memory for format conversion
On Fri, 17 Nov 2023 at 11:07, Thomas Zimmermann wrote: > > Hi > > Am 17.11.23 um 10:34 schrieb Maxime Ripard: > > On Mon, Oct 09, 2023 at 04:06:29PM +0200, Thomas Zimmermann wrote: > >> DRM's format-conversion helpers require temporary memory. Pass the > >> buffer from the caller to allow the caller to preallocate the buffer > >> memory. > >> > >> The motivation for this patchset is the recent work on a DRM panic > >> handler. [1] The panic handler requires format conversion to display an > >> error to the screen. But allocating memory during a kernel panic is > >> fragile. The changes in this patchset enable the DRM panic handler to > >> preallocate buffer storage before the panic occurs. > >> > >> Patch 1 adds struct drm_format_conv_state, a simple interface to pass > >> around the buffer storage. Patch 2 adds an instance of the struct to > >> the shadow-plane state. Patch 3 moves the buffer's memory management > >> from the format helpers into their callers within the DRM drivers. Most > >> of the affected drivers use the state instance stored in their shadow- > >> plane state. The shadow-plane code releases the buffer memory > >> automatically. > >> > >> Patches 4 to 7 update three drivers to pre-allocate the format-conversion > >> buffer in their plane's atomic_check function. The drivers thus detect OOM > >> errors before the display update begins. > >> > >> Tested with simpledrm. > > > > So, I just discovered that you merged that series. > > > > You've complained before about "sneaking patches in", and while I was > > disagreeing with you then, this particular instance is definitely a > > strong case for it. You've merged it without telling anyone, and despite > > our ongoing conversation on the v4 that was active more recently than > > the v5. And that you never responded to. > > > > Awesome. > > My apologies. From my point of view, that conversion had ended. I left > the patch set for a while to wait for further comments or questions, but > nothing happened. So I merged it. > > Revert it if you cannot live with the changes. IIRC you found the > reduced number of alloc/free cycles to be irrelevant. But even then, the > patches allow us to move the allocation from atomic_update to > atomic_check, thus detecting allocation failures early. That's an > improvement to me. Just a small comment on this, I didn't read up the full discussion: Yeah allocating memory in atomic_commit after the point of no return is no-go. Usually the best spot is the prepare_fb hooks since that avoids doing expensive allocations for TEST_ONLY commits, but since the allocation is fairly small it probably doesn't matter overall. Well the new-ish begin/end_fb_access helpers would be even better I guess for the atomic flow, but break the panic handler use-case I think. Oh and a bikeshed, _copy() feels a bit like a funny postfix for something that does a state duplication, everywhere else in atomic we put _duplicate into the name for these functions. Cheers, Sima > > Best regards > Thomas > > > > > Maxime > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Frankenstrasse 146, 90461 Nuernberg, Germany > GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman > HRB 36809 (AG Nuernberg) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/print: Handle NULL drm device in __drm_printk()
On Thu, 16 Nov 2023, Luben Tuikov wrote:
> drm_{err,warn,...}() use __drm_printk() which takes a drm device pointer and
> uses the embedded device pointer to print the device. This facility handles
> NULL device pointer, but not NULL drm device pointer. This patch makes
> __drm_printk() also handle a NULL drm device pointer. The printed output is
> identical to if drm->dev had been NULL.
>
> Signed-off-by: Luben Tuikov
Reviewed-by: Jani Nikula
> ---
> include/drm/drm_print.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index a93a387f8a1a15..dd4883df876a6d 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -453,7 +453,7 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct
> device *dev,
>
> /* Helper for struct drm_device based logging. */
> #define __drm_printk(drm, level, type, fmt, ...) \
> - dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
> + dev_##level##type((drm) ? (drm)->dev : NULL, "[drm] " fmt,
> ##__VA_ARGS__)
>
>
> #define drm_info(drm, fmt, ...) \
>
> base-commit: 3b434a3445fff3149128db0169da864d67057325
--
Jani Nikula, Intel
Re: [PATCH v5 0/7] drm: Reuse temporary memory for format conversion
Hi Am 17.11.23 um 10:34 schrieb Maxime Ripard: On Mon, Oct 09, 2023 at 04:06:29PM +0200, Thomas Zimmermann wrote: DRM's format-conversion helpers require temporary memory. Pass the buffer from the caller to allow the caller to preallocate the buffer memory. The motivation for this patchset is the recent work on a DRM panic handler. [1] The panic handler requires format conversion to display an error to the screen. But allocating memory during a kernel panic is fragile. The changes in this patchset enable the DRM panic handler to preallocate buffer storage before the panic occurs. Patch 1 adds struct drm_format_conv_state, a simple interface to pass around the buffer storage. Patch 2 adds an instance of the struct to the shadow-plane state. Patch 3 moves the buffer's memory management from the format helpers into their callers within the DRM drivers. Most of the affected drivers use the state instance stored in their shadow- plane state. The shadow-plane code releases the buffer memory automatically. Patches 4 to 7 update three drivers to pre-allocate the format-conversion buffer in their plane's atomic_check function. The drivers thus detect OOM errors before the display update begins. Tested with simpledrm. So, I just discovered that you merged that series. You've complained before about "sneaking patches in", and while I was disagreeing with you then, this particular instance is definitely a strong case for it. You've merged it without telling anyone, and despite our ongoing conversation on the v4 that was active more recently than the v5. And that you never responded to. Awesome. My apologies. From my point of view, that conversion had ended. I left the patch set for a while to wait for further comments or questions, but nothing happened. So I merged it. Revert it if you cannot live with the changes. IIRC you found the reduced number of alloc/free cycles to be irrelevant. But even then, the patches allow us to move the allocation from atomic_update to atomic_check, thus detecting allocation failures early. That's an improvement to me. Best regards Thomas Maxime -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
On Fri, Nov 17, 2023 at 01:18:49AM +0800, Sui Jingfeng wrote:
>
> On 2023/11/16 23:23, Dmitry Baryshkov wrote:
> > On Thu, 16 Nov 2023 at 14:08, Sui Jingfeng wrote:
> > >
> > > On 2023/11/16 19:53, Sui Jingfeng wrote:
> > > > Hi,
> > > >
> > > >
> > > > On 2023/11/16 19:29, Dmitry Baryshkov wrote:
> > > > > On Thu, 16 Nov 2023 at 13:18, Sui Jingfeng
> > > > > wrote:
> > > > > > Hi,
> > > > > >
> > > > > >
> > > > > > On 2023/11/15 00:30, Dmitry Baryshkov wrote:
> > > > > > > > +
> > > > > > > > + ctx->connector = connector;
> > > > > > > > + }
> > > > > > > >
> > > > > > > >if (ctx->info->id == ID_IT66121) {
> > > > > > > >ret = regmap_write_bits(ctx->regmap,
> > > > > > > > IT66121_CLK_BANK_REG,
> > > > > > > > @@ -1632,16 +1651,13 @@ static const char * const
> > > > > > > > it66121_supplies[] = {
> > > > > > > >"vcn33", "vcn18", "vrf12"
> > > > > > > > };
> > > > > > > >
> > > > > > > > -static int it66121_probe(struct i2c_client *client)
> > > > > > > > +int it66121_create_bridge(struct i2c_client *client, bool
> > > > > > > > of_support,
> > > > > > > > + bool hpd_support, bool audio_support,
> > > > > > > > + struct drm_bridge **bridge)
> > > > > > > > {
> > > > > > > > + struct device *dev = &client->dev;
> > > > > > > >int ret;
> > > > > > > >struct it66121_ctx *ctx;
> > > > > > > > - struct device *dev = &client->dev;
> > > > > > > > -
> > > > > > > > - if (!i2c_check_functionality(client->adapter,
> > > > > > > > I2C_FUNC_I2C)) {
> > > > > > > > - dev_err(dev, "I2C check functionality
> > > > > > > > failed.\n");
> > > > > > > > - return -ENXIO;
> > > > > > > > - }
> > > > > > > >
> > > > > > > >ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> > > > > > > >if (!ctx)
> > > > > > > > @@ -1649,24 +1665,19 @@ static int it66121_probe(struct
> > > > > > > > i2c_client
> > > > > > > > *client)
> > > > > > > >
> > > > > > > >ctx->dev = dev;
> > > > > > > >ctx->client = client;
> > > > > > > > - ctx->info = i2c_get_match_data(client);
> > > > > > > > -
> > > > > > > > - ret = it66121_of_read_bus_width(dev, &ctx->bus_width);
> > > > > > > > - if (ret)
> > > > > > > > - return ret;
> > > > > > > > -
> > > > > > > > - ret = it66121_of_get_next_bridge(dev,
> > > > > > > > &ctx->next_bridge);
> > > > > > > > - if (ret)
> > > > > > > > - return ret;
> > > > > > > > -
> > > > > > > > - i2c_set_clientdata(client, ctx);
> > > > > > > >mutex_init(&ctx->lock);
> > > > > > > >
> > > > > > > > - ret = devm_regulator_bulk_get_enable(dev,
> > > > > > > > ARRAY_SIZE(it66121_supplies),
> > > > > > > > - it66121_supplies);
> > > > > > > > - if (ret) {
> > > > > > > > - dev_err(dev, "Failed to enable power
> > > > > > > > supplies\n");
> > > > > > > > - return ret;
> > > > > > > > + if (of_support) {
> > > > > > > > + ret = it66121_of_read_bus_width(dev,
> > > > > > > > &ctx->bus_width);
> > > > > > > > + if (ret)
> > > > > > > > + return ret;
> > > > > > > > +
> > > > > > > > + ret = it66121_of_get_next_bridge(dev,
> > > > > > > > &ctx->next_bridge);
> > > > > > > > + if (ret)
> > > > > > > > + return ret;
> > > > > > > > + } else {
> > > > > > > > + ctx->bus_width = 24;
> > > > > > > > + ctx->next_bridge = NULL;
> > > > > > > >}
> > > > > > > A better alternative would be to turn OF calls into fwnode calls
> > > > > > > and
> > > > > > > to populate the fwnode properties. See
> > > > > > > drivers/platform/x86/intel/chtwc_int33fe.c for example.
> > > > > > Honestly, I don't want to leave any scratch(breadcrumbs).
> > > > > > I'm worries about that turn OF calls into fwnode calls will leave
> > > > > > something unwanted.
> > > > > >
> > > > > > Because I am not sure if fwnode calls will make sense in the DT
> > > > > > world, while my patch
> > > > > > *still* be useful in the DT world.
> > > > > fwnode calls work for both DT and non-DT cases. In the DT case they
> > > > > work with DT nodes and properties. In the non-DT case, they work with
> > > > > manually populated properties.
> > > > >
> > > > > > Because the newly introduced it66121_create_bridge()
> > > > > > function is a core. I think It's better leave this task to a more
> > > > > > advance programmer.
> > > > > > if there have use case. It can be introduced at a latter time,
> > > > > > probably parallel with
> > > > > > the DT.
> > > > > >
> > > > > > I think DT and/or ACPI is best for integrated devices, but it66121
> > > > > > display bridges is
> > > > > > a i2c slave device. Personally, I think slave device shouldn't be
> > > >
[PULL] drm-misc-next
Hi,
Here's the first drm-misc-next PR for what will become 6.8.
There's one missing SoB on the commit 0da611a87021 ("dma-buf: add
dma_fence_timestamp helper") from the committer. They provided their SoB
on the ML here after the facts:
https://lore.kernel.org/dri-devel/ce94020e-a7d4-4799-b87d-fbea7b14a...@gmail.com/
Maxime
drm-misc-next-2023-11-17:
drm-misc-next for 6.8:
UAPI Changes:
- drm: Introduce CLOSE_FB ioctl
- drm/dp-mst: Documentation for the PATH property
- fdinfo: Do not align to a MB if the size is larger than 1MiB
- virtio-gpu: add explicit virtgpu context debug name
Cross-subsystem Changes:
- dma-buf: Add dma_fence_timestamp helper
Core Changes:
- client: Do not acquire module reference
- edid: split out drm_eld, add SAD helpers
- format-helper: Cache format conversion buffers
- sched: Move from a kthread to a workqueue, rename some internal
functions to make it clearer, implement dynamic job-flow control
- gpuvm: Provide more features to handle GEM objects
- tests: Remove slow kunit tests
Driver Changes:
- ivpu: Update FW API, new debugfs file, a new NOP job submission test
mode, improve suspend/resume, PM improvements, MMU PT optimizations,
firmware profiling frequency support, support for uncached buffers,
switch to gem shmem helpers, replace kthread with threaded
interrupts
- panfrost: PM improvements
- qaic: Allow to run with a single MSI, support host/device time
synchronization, misc improvements
- simplefb: Support memory-regions, support power-domains
- ssd130x: Unitialized variable fixes
- omapdrm: dma-fence lockdep annotation fix
- tidss: dma-fence lockdep annotation fix
- v3d: Support BCM2712 (RaspberryPi5), Support fdinfo and gputop
- panel:
- edp: Support AUO B116XTN02, BOE NT116WHM-N21,836X2, NV116WHM-N49
V8.0, plus a whole bunch of panels used on Mediatek chromebooks.
The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:
Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-11-17
for you to fetch changes up to 3b434a3445fff3149128db0169da864d67057325:
accel/ivpu: Use threaded IRQ to handle JOB done messages (2023-11-16 13:41:49
+0100)
drm-misc-next for 6.8:
UAPI Changes:
- drm: Introduce CLOSE_FB ioctl
- drm/dp-mst: Documentation for the PATH property
- fdinfo: Do not align to a MB if the size is larger than 1MiB
- virtio-gpu: add explicit virtgpu context debug name
Cross-subsystem Changes:
- dma-buf: Add dma_fence_timestamp helper
Core Changes:
- client: Do not acquire module reference
- edid: split out drm_eld, add SAD helpers
- format-helper: Cache format conversion buffers
- sched: Move from a kthread to a workqueue, rename some internal
functions to make it clearer, implement dynamic job-flow control
- gpuvm: Provide more features to handle GEM objects
- tests: Remove slow kunit tests
Driver Changes:
- ivpu: Update FW API, new debugfs file, a new NOP job submission test
mode, improve suspend/resume, PM improvements, MMU PT optimizations,
firmware profiling frequency support, support for uncached buffers,
switch to gem shmem helpers, replace kthread with threaded
interrupts
- panfrost: PM improvements
- qaic: Allow to run with a single MSI, support host/device time
synchronization, misc improvements
- simplefb: Support memory-regions, support power-domains
- ssd130x: Unitialized variable fixes
- omapdrm: dma-fence lockdep annotation fix
- tidss: dma-fence lockdep annotation fix
- v3d: Support BCM2712 (RaspberryPi5), Support fdinfo and gputop
- panel:
- edp: Support AUO B116XTN02, BOE NT116WHM-N21,836X2, NV116WHM-N49
V8.0, plus a whole bunch of panels used on Mediatek chromebooks.
Ajit Pal Singh (1):
accel/qaic: Add support for periodic timesync
Andrzej Kacprowski (4):
accel/ivpu: Add support for VPU_JOB_FLAGS_NULL_SUBMISSION_MASK
accel/ivpu/40xx: Capture D0i3 entry host and device timestamps
accel/ivpu: Pass D0i3 residency time to the VPU firmware
accel/ivpu: Add support for delayed D0i3 entry message
AngeloGioacchino Del Regno (7):
drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()
drm/panfrost: Perform hard reset to recover GPU if soft reset fails
drm/panfrost: Tighten polling for soft reset and power on
drm/panfrost: Implement ability to turn on/off GPU clocks in suspend
drm/panfrost: Set clocks on/off during system sleep on MediaTek SoCs
drm/panfrost: Implement ability to turn on/off regulators in suspend
drm/panfrost: Set regulators on/off during system sleep on MediaTek SoCs
Arnd Bergmann (1):
accel/ivpu: avoid build failure with CONFIG_PM=n
Carl Vanderlip
Re: [PATCH 09/11] drm/rockchip: vop2: Add support for rk3588
On Fri, Nov 17, 2023 at 03:06:35PM +0800, Andy Yan wrote:
> Hi Sebastian:
>
> On 11/16/23 21:47, Sebastian Reichel wrote:
> > Hi,
> >
> > On Thu, Nov 16, 2023 at 06:39:40PM +0800, Andy Yan wrote:
> > > > > vop2->sys_grf = syscon_regmap_lookup_by_phandle(dev->of_node,
> > > > > "rockchip,grf");
> > > > This already lacks an error check, shame on me...
> > > >
> > > > > + vop2->vop_grf = syscon_regmap_lookup_by_phandle(dev->of_node,
> > > > > "rockchip,vop-grf");
> > > > > + vop2->vo1_grf = syscon_regmap_lookup_by_phandle(dev->of_node,
> > > > > "rockchip,vo1-grf");
> > > > > + vop2->sys_pmu = syscon_regmap_lookup_by_phandle(dev->of_node,
> > > > > "rockchip,pmu");
> > > > ... but please don't duplicate that.
> > > It a little difficult to find a proper way to do the check, as not every
> > > soc need all these phandles.
> > >
> > > Do i need check it per soc?
> > I suggest adding a u32 flags to struct vop2_data and then have
> > something like this:
> >
> > if (vop2_data->flags & VOP2_HAS_VOP_GRF) {
> > vop2->vop_grf = syscon_regmap_lookup_by_phandle(dev->of_node,
> > "rockchip,vop-grf");
> > if (IS_ERR(vop2->vop_grf))
> > return dev_err_probe(dev, PTR_ERR(vop2->vop_grf) "cannot get
> > vop-grf");
> > }
> >
> > if (vop2_data->flags & VOP2_HAS_VO1_GRF) {
> > vop2->vo1_grf = syscon_regmap_lookup_by_phandle(dev->of_node,
> > "rockchip,vo1-grf");
> > if (IS_ERR(vop2->vo1_grf))
> > return dev_err_probe(dev, PTR_ERR(vop2->vo1_grf) "cannot get
> > vo1-grf");
> > }
> >
> > ...
>
>
> I can do it like this if Sascha is also happy with it.
Yes, I am.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v5 0/7] drm: Reuse temporary memory for format conversion
On Mon, Oct 09, 2023 at 04:06:29PM +0200, Thomas Zimmermann wrote: > DRM's format-conversion helpers require temporary memory. Pass the > buffer from the caller to allow the caller to preallocate the buffer > memory. > > The motivation for this patchset is the recent work on a DRM panic > handler. [1] The panic handler requires format conversion to display an > error to the screen. But allocating memory during a kernel panic is > fragile. The changes in this patchset enable the DRM panic handler to > preallocate buffer storage before the panic occurs. > > Patch 1 adds struct drm_format_conv_state, a simple interface to pass > around the buffer storage. Patch 2 adds an instance of the struct to > the shadow-plane state. Patch 3 moves the buffer's memory management > from the format helpers into their callers within the DRM drivers. Most > of the affected drivers use the state instance stored in their shadow- > plane state. The shadow-plane code releases the buffer memory automatically. > > Patches 4 to 7 update three drivers to pre-allocate the format-conversion > buffer in their plane's atomic_check function. The drivers thus detect OOM > errors before the display update begins. > > Tested with simpledrm. So, I just discovered that you merged that series. You've complained before about "sneaking patches in", and while I was disagreeing with you then, this particular instance is definitely a strong case for it. You've merged it without telling anyone, and despite our ongoing conversation on the v4 that was active more recently than the v5. And that you never responded to. Awesome. Maxime signature.asc Description: PGP signature
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
On Fri, 17 Nov 2023 at 06:24, Sui Jingfeng wrote: > > Hi, > > On 2023/11/16 23:23, Dmitry Baryshkov wrote: > Then you will need some way (fwnode?) to > discover the bridge chain. And at the last point you will get into the > device data and/or properties business. > > >>> No, leave that chance to a more better programmer and forgive me please, > >>> too difficult, I'm afraid of not able to solve. Thanks a lot for the > >>> trust! > > From my point of view: no. > > > I respect the fact that the community prefer generic mechanisms. > If our approach is not what the community want, can I switch back > to my previous solution? I can reduce the duplication of our > localized it66121 driver to a minimal, rewrite it until it meets > the community's requirement. I know our device looks weird and > our approach is not elegant. But at the very least, we could not > mess the community's design up by localize. Otherwise, I don't know > what is the better approach to solve such a problem. > > Can I switch back or any other ideas? I keep on repeating: create the i2c device from your root device driver, which parses BIOS data. -- With best wishes Dmitry
Re: [PATCH] drm/scheduler: improve GPU scheduler documentation
Am 17.11.23 um 04:18 schrieb Luben Tuikov: On 2023-11-13 07:38, Christian König wrote: Start to improve the scheduler document. Especially document the lifetime of each of the objects as well as the restrictions around DMA-fence handling and userspace compatibility. Thanks Christian for doing this--much needed. Signed-off-by: Christian König --- drivers/gpu/drm/scheduler/sched_main.c | 126 - 1 file changed, 104 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index 506371c42745..36a7c5dc852d 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -24,28 +24,110 @@ /** * DOC: Overview * - * The GPU scheduler provides entities which allow userspace to push jobs - * into software queues which are then scheduled on a hardware run queue. - * The software queues have a priority among them. The scheduler selects the entities - * from the run queue using a FIFO. The scheduler provides dependency handling - * features among jobs. The driver is supposed to provide callback functions for - * backend operations to the scheduler like submitting a job to hardware run queue, - * returning the dependencies of a job etc. So, I don't mind this paragraph, as it provides an overview or the relationship between a DRM GPU scheduler, entities, run-queues, and jobs. - * - * The organisation of the scheduler is the following: - * - * 1. Each hw run queue has one scheduler - * 2. Each scheduler has multiple run queues with different priorities - *(e.g., HIGH_HW,HIGH_SW, KERNEL, NORMAL) - * 3. Each scheduler run queue has a queue of entities to schedule - * 4. Entities themselves maintain a queue of jobs that will be scheduled on - *the hardware. This is also good, and shouldn't have been deleted. - * - * The jobs in a entity are always scheduled in the order that they were pushed. I'd have said here "jobs within an entity". Again shouldn't have been deleted. This is good overall/overview information. I was hoping that I have incorporated all this into the per object description text. Did I miss anything? - * - * Note that once a job was taken from the entities queue and pushed to the - * hardware, i.e. the pending queue, the entity must not be referenced anymore - * through the jobs entity pointer. + * The GPU scheduler implements some logic to decide which command submission + * to push next to the hardware. Another major use case for the GPU scheduler + * is to enforce correct driver behavior around those command submission. The GPU scheduler also enforces correct driver behaviour around those command submissions. + * Because of this it's also used by drivers which don't need the actual + * scheduling functionality. ... but need to push jobs into their firmware/hardware and maintain/keep correct DRM dependencies in the form of "fences". Good point, going to add that. + * + * To fulfill this task the GPU scheduler uses of the following objects: + * + * 1. The job object which contains a bunch of dependencies in the form of Drop "which". Instead of listing what it contains, how it is used, what it does, explain what it is: work/task to be executed by the GPU. _Then_ you can start listing what it contains, how it is used, what it does. + *DMA-fence objects. Drivers can also implement an optional prepare_job + *callback which returns additional dependencies as DMA-fence objects. "can also"? This would usually follow if the other callbacks/etc., have been described and they haven't, so I'd say "Drivers implement an optional prepare_job callback,..." + *It's important to note that this callback must follow the DMA-fence rules, + *so it can't easily allocate memory or grab locks under which memory is + *allocated. Drivers should use this as base class for an object which + *contains the necessary state to push the command submission to the + *hardware. + * + *The lifetime of the job object should at least be from pushing it into the + *scheduler until the scheduler notes through the free callback that a job + *isn't needed any more. Drivers can of course keep their job object alive + *longer than that, but that's outside of the scope of the scheduler + *component. [New paragraph starts describing the job initialization.] Add: Job initialization is split into two parts, + *drm_sched_job_init() and drm_sched_job_arm(). Perhaps we should mention briefly what each one does..? Add: It's important to note that + *after arming a job drivers must follow the DMA-fence rules and can't + *easily allocate memory or takes locks under which memory is allocated. + * + * 2. The entity object which is a container for jobs which should execute Drop "which". "The entity object is a container of ..." + *sequentially. Drivers should create an entity for each individual cont
Re: [PATCH 3/3] drm/ssd130x: Change "solomon,page-offset" property default value
Maxime Ripard writes:
Hello Maxime,
> On Thu, Nov 16, 2023 at 07:07:39PM +0100, Javier Martinez Canillas wrote:
>> This is used to specify the page start address offset of the display RAM.
>>
>> The value is used as offset when setting the page start address with the
>> SSD130X_SET_PAGE_RANGE command, and the driver currently sets its value to
>> 1 if the property is not present in the Device Tree.
>>
>> But the datasheet mentions that the value on reset for the page start is a
>> 0, so it makes more sense to also have 0 as the default value for the page
>> offset if the property is not present.
>
> I can see the argument, but that's a DT ABI breaking change.
>
Yes, I know it's a DT ABI breaking change but what I'm trying to argue is
that the DT binding schema isn't correct to start with. Even the RPi DTBO
for this device (which I guess is used by most people with a SSD1306) has
a property to explicitly set this to 0:
ssd1306: oled@3c{
...
solomon,page-offset = <0>;
...
};
https://github.com/raspberrypi/linux/blob/rpi-6.1.y/arch/arm/boot/dts/overlays/ssd1306-overlay.dts
>> In fact, using a default value of 1 leads to the display not working when
>> the emulated fbdev is attached to the framebuffer console.
>
> Could we fix that one instead? What is the issue about, exactly
>
This is the issue that Sahaj reported:
https://twitter.com/sahajsarup/status/1725088484736766364
I can try to figure out how to make the fbcon to work with a page-offset=1
but didn't investigate since thought that 0 is a much better default. Just
like the maximum resolution is the default if no width and height are set.
> Maxime
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
