Re: [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap

[Christian König]

Am 04.02.21 um 19:38 schrieb Jason Gunthorpe:

On Thu, Feb 04, 2021 at 06:16:27PM +0100, Daniel Vetter wrote:

On Thu, Feb 4, 2021 at 5:13 PM Jason Gunthorpe  wrote:

On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote:

tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.

Since some userspace only runs on integrated devices, where all
buffers are actually all resident system memory, there's a huge
temptation to assume that a struct page is always present and useable
like for any more pagecache backed mmap. This has the potential to
result in a uapi nightmare.

To stop this gap require that DMA buffer mmaps are VM_SPECIAL, which
blocks get_user_pages and all the other struct page based
infrastructure for everyone. In spirit this is the uapi counterpart to
the kernel-internal CONFIG_DMABUF_DEBUG.

Fast gup needs the special flag set on the PTE as well.. Feels weird
to have a special VMA without also having special PTEs?

There's kinda no convenient & cheap way to check for the pte_special
flag. This here should at least catch accidental misuse, people
building their own ptes we can't stop. Maybe we should exclude
VM_MIXEDMAP to catch vm_insert_page in one of these.

Hm looking at code I think we need to require VM_PFNMAP here to stop
vm_insert_page. And looking at the various functions, that seems to be
required (and I guess VM_IO is more for really funky architectures
where io-space is somewhere else?). I guess I should check for
VM_PFNMAP instead of VM_SPECIAL?

Well, you said the goal was to block GUP usage, that won't happen
without the PTE special flag, at least on x86


When is that special flag being set?


So, really, what you are saying is all dmabuf users should always use
vmf_insert_pfn_prot() or something similar - and never insert_page/etc?


Exactly, yes.

Christian.


It might make sense to check the vma flags in all the insert paths, eg
vm_insert_page() can't work with VMAs that should not have struct
pages in them (eg VM_SPECIAl, VM_PFNMAP, !VM_MIXEMAP if I understand
it right)

At least as some VM debug option

Jason


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC][PATCH v6 0/7] Generic page pool & deferred freeing for system dmabuf heap

[John Stultz]

This series is starting to get long, so I figured I'd add a
short cover letter for context.

The point of this series is trying to add both deferred-freeing
logic as well as a page pool to the DMA-BUF system heap.

This is desired, as the combination of deferred freeing along
with the page pool allows us to offload page-zeroing out of
the allocation hot path. This was done originally with ION
and this patch series allows the DMA-BUF system heap to match
ION's system heap allocation performance in a simple
microbenchmark [1] (ION re-added to the kernel for comparision,
running on an x86 vm image):

./dmabuf-heap-bench -i 0 1 system 
Testing dmabuf system vs ion heaptype 0 (flags: 0x1)
-
dmabuf heap: alloc 4096 bytes 5000 times in 86572223 ns  17314 ns/call
ion heap:alloc 4096 bytes 5000 times in 97442526 ns  19488 ns/call
dmabuf heap: alloc 1048576 bytes 5000 times in 196635057 ns  39327 ns/call
ion heap:alloc 1048576 bytes 5000 times in 357323629 ns  71464 ns/call
dmabuf heap: alloc 8388608 bytes 5000 times in 3165445534 ns 633089 ns/call
ion heap:alloc 8388608 bytes 5000 times in 3699591271 ns 739918 ns/call
dmabuf heap: alloc 33554432 bytes 5000 times in 13327402517 ns   2665480 ns/call
ion heap:alloc 33554432 bytes 5000 times in 15292352796 ns   3058470 ns/call

Daniel didn't like earlier attempts to re-use the network
page-pool code to achieve this, and suggested the ttm_pool be
used instead. This required pulling the fairly tightly knit
ttm_pool logic apart, but after many failed attmempts I think
I found a workable abstraction to split out shared logic.

So this series contains a new generic drm_page_pool helper
library, converts the ttm_pool to use it, and then adds the
dmabuf deferred freeing and adds support to the dmabuf system
heap to use both deferred freeing and the new drm_page_pool.

Input would be greatly appreciated. Testing as well, as I don't
have any development hardware that utilizes the ttm pool.

thanks
-john

[1] 
https://android.googlesource.com/platform/system/memory/libdmabufheap/+/refs/heads/master/tests/dmabuf_heap_bench.c

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org

John Stultz (7):
  drm: Add a sharable drm page-pool implementation
  drm: ttm_pool: Rename the ttm_pool_dma structure to ttm_pool_page_dat
  drm: ttm_pool: Rework ttm_pool_free_page to allow us to use it as a
function pointer
  drm: ttm_pool: Rework ttm_pool to use drm_page_pool
  dma-buf: heaps: Add deferred-free-helper library code
  dma-buf: system_heap: Add drm pagepool support to system heap
  dma-buf: system_heap: Add deferred freeing to the system heap

 drivers/dma-buf/heaps/Kconfig|   5 +
 drivers/dma-buf/heaps/Makefile   |   1 +
 drivers/dma-buf/heaps/deferred-free-helper.c | 145 ++
 drivers/dma-buf/heaps/deferred-free-helper.h |  55 
 drivers/dma-buf/heaps/system_heap.c  |  77 -
 drivers/gpu/drm/Kconfig  |   5 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/page_pool.c  | 220 +++
 drivers/gpu/drm/ttm/ttm_pool.c   | 278 ++-
 include/drm/page_pool.h  |  54 
 include/drm/ttm/ttm_pool.h   |  23 +-
 11 files changed, 639 insertions(+), 225 deletions(-)
 create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.c
 create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.h
 create mode 100644 drivers/gpu/drm/page_pool.c
 create mode 100644 include/drm/page_pool.h

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC][PATCH v6 1/7] drm: Add a sharable drm page-pool implementation

[John Stultz]

This adds a shrinker controlled page pool, closely
following the ttm_pool logic, which is abstracted out
a bit so it can be used by other non-ttm drivers.

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/Kconfig |   4 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/page_pool.c | 220 
 include/drm/page_pool.h |  54 +
 4 files changed, 279 insertions(+)
 create mode 100644 drivers/gpu/drm/page_pool.c
 create mode 100644 include/drm/page_pool.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0973f408d75f..d16bf340ed2e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -174,6 +174,10 @@ config DRM_DP_CEC
  Note: not all adapters support this feature, and even for those
  that do support this they often do not hook up the CEC pin.
 
+config DRM_PAGE_POOL
+   bool
+   depends on DRM
+
 config DRM_TTM
tristate
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index fefaff4c832d..877e0111ed34 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,6 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
 drm-$(CONFIG_PCI) += drm_pci.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_DRM_PAGE_POOL) += page_pool.o
 
 drm_vram_helper-y := drm_gem_vram_helper.o
 obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
diff --git a/drivers/gpu/drm/page_pool.c b/drivers/gpu/drm/page_pool.c
new file mode 100644
index ..2139f86e6ca7
--- /dev/null
+++ b/drivers/gpu/drm/page_pool.c
@@ -0,0 +1,220 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DRM page pool system
+ *
+ * Copyright (C) 2020 Linaro Ltd.
+ *
+ * Based on the ION page pool code
+ * Copyright (C) 2011 Google, Inc.
+ * As well as the ttm_pool code
+ * Copyright (C) 2020 Advanced Micro Devices, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static LIST_HEAD(pool_list);
+static DEFINE_MUTEX(pool_list_lock);
+static atomic_long_t total_pages;
+static unsigned long page_pool_max;
+MODULE_PARM_DESC(page_pool_max, "Number of pages in the WC/UC/DMA pool");
+module_param(page_pool_max, ulong, 0644);
+
+void drm_page_pool_set_max(unsigned long max)
+{
+   /* only write once */
+   if (!page_pool_max)
+   page_pool_max = max;
+}
+
+unsigned long drm_page_pool_get_max(void)
+{
+   return page_pool_max;
+}
+
+unsigned long drm_page_pool_get_total(void)
+{
+   return atomic_long_read(&total_pages);
+}
+
+int drm_page_pool_get_size(struct drm_page_pool *pool)
+{
+   int ret;
+
+   spin_lock(&pool->lock);
+   ret = pool->count;
+   spin_unlock(&pool->lock);
+   return ret;
+}
+
+static inline unsigned int drm_page_pool_free_pages(struct drm_page_pool *pool,
+   struct page *page)
+{
+   return pool->free(page, pool->order);
+}
+
+static int drm_page_pool_shrink_one(void);
+
+void drm_page_pool_add(struct drm_page_pool *pool, struct page *page)
+{
+   spin_lock(&pool->lock);
+   list_add_tail(&page->lru, &pool->items);
+   pool->count++;
+   atomic_long_add(1 << pool->order, &total_pages);
+   spin_unlock(&pool->lock);
+
+   mod_node_page_state(page_pgdat(page), NR_KERNEL_MISC_RECLAIMABLE,
+   1 << pool->order);
+
+   /* make sure we don't grow too large */
+   while (page_pool_max && atomic_long_read(&total_pages) > page_pool_max)
+   drm_page_pool_shrink_one();
+}
+EXPORT_SYMBOL_GPL(drm_page_pool_add);
+
+static struct page *drm_page_pool_remove(struct drm_page_pool *pool)
+{
+   struct page *page;
+
+   if (!pool->count)
+   return NULL;
+
+   page = list_first_entry(&pool->items, struct page, lru);
+   pool->count--;
+   atomic_long_sub(1 << pool->order, &total_pages);
+
+   list_del(&page->lru);
+   mod_node_page_state(page_pgdat(page), NR_KERNEL_MISC_RECLAIMABLE,
+   -(1 << pool->order));
+   return page;
+}
+
+struct page *drm_page_pool_fetch(struct drm_page_pool *pool)
+{
+   struct page *page = NULL;
+
+   if (!pool) {
+   WARN_ON(!pool);
+   return NULL;
+   }
+
+   spin_lock(&pool->lock);
+   page = drm_page_pool_remove(pool);
+   spin_unlock(&pool->lock);
+
+   return page;
+}
+EXPORT_SYMBOL_GPL(drm_page_pool_fetch);
+
+struct drm_page_pool *drm_page_pool_create(unsigned int order,
+  

[RFC][PATCH v6 2/7] drm: ttm_pool: Rename the ttm_pool_dma structure to ttm_pool_page_dat

[John Stultz]

This patch simply renames the ttm_pool_dma structure to
ttm_pool_page_dat, as we will extend it to store more then just
dma related info in it.

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/ttm/ttm_pool.c | 37 +-
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 11e0313db0ea..c0274e256be3 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -37,18 +37,17 @@
 #ifdef CONFIG_X86
 #include 
 #endif
-
 #include 
 #include 
 #include 
 
 /**
- * struct ttm_pool_dma - Helper object for coherent DMA mappings
+ * struct ttm_pool_page_dat - Helper object for coherent DMA mappings
  *
  * @addr: original DMA address returned for the mapping
  * @vaddr: original vaddr return for the mapping and order in the lower bits
  */
-struct ttm_pool_dma {
+struct ttm_pool_page_dat {
dma_addr_t addr;
unsigned long vaddr;
 };
@@ -75,7 +74,7 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool 
*pool, gfp_t gfp_flags,
unsigned int order)
 {
unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS;
-   struct ttm_pool_dma *dma;
+   struct ttm_pool_page_dat *dat;
struct page *p;
void *vaddr;
 
@@ -94,15 +93,15 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool 
*pool, gfp_t gfp_flags,
return p;
}
 
-   dma = kmalloc(sizeof(*dma), GFP_KERNEL);
-   if (!dma)
+   dat = kmalloc(sizeof(*dat), GFP_KERNEL);
+   if (!dat)
return NULL;
 
if (order)
attr |= DMA_ATTR_NO_WARN;
 
vaddr = dma_alloc_attrs(pool->dev, (1ULL << order) * PAGE_SIZE,
-   &dma->addr, gfp_flags, attr);
+   &dat->addr, gfp_flags, attr);
if (!vaddr)
goto error_free;
 
@@ -114,12 +113,12 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool 
*pool, gfp_t gfp_flags,
else
p = virt_to_page(vaddr);
 
-   dma->vaddr = (unsigned long)vaddr | order;
-   p->private = (unsigned long)dma;
+   dat->vaddr = (unsigned long)vaddr | order;
+   p->private = (unsigned long)dat;
return p;
 
 error_free:
-   kfree(dma);
+   kfree(dat);
return NULL;
 }
 
@@ -128,7 +127,7 @@ static void ttm_pool_free_page(struct ttm_pool *pool, enum 
ttm_caching caching,
   unsigned int order, struct page *p)
 {
unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS;
-   struct ttm_pool_dma *dma;
+   struct ttm_pool_page_dat *dat;
void *vaddr;
 
 #ifdef CONFIG_X86
@@ -147,11 +146,11 @@ static void ttm_pool_free_page(struct ttm_pool *pool, 
enum ttm_caching caching,
if (order)
attr |= DMA_ATTR_NO_WARN;
 
-   dma = (void *)p->private;
-   vaddr = (void *)(dma->vaddr & PAGE_MASK);
-   dma_free_attrs(pool->dev, (1UL << order) * PAGE_SIZE, vaddr, dma->addr,
+   dat = (void *)p->private;
+   vaddr = (void *)(dat->vaddr & PAGE_MASK);
+   dma_free_attrs(pool->dev, (1UL << order) * PAGE_SIZE, vaddr, dat->addr,
   attr);
-   kfree(dma);
+   kfree(dat);
 }
 
 /* Apply a new caching to an array of pages */
@@ -184,9 +183,9 @@ static int ttm_pool_map(struct ttm_pool *pool, unsigned int 
order,
unsigned int i;
 
if (pool->use_dma_alloc) {
-   struct ttm_pool_dma *dma = (void *)p->private;
+   struct ttm_pool_page_dat *dat = (void *)p->private;
 
-   addr = dma->addr;
+   addr = dat->addr;
} else {
size_t size = (1ULL << order) * PAGE_SIZE;
 
@@ -324,9 +323,9 @@ static unsigned int ttm_pool_shrink(void)
 static unsigned int ttm_pool_page_order(struct ttm_pool *pool, struct page *p)
 {
if (pool->use_dma_alloc) {
-   struct ttm_pool_dma *dma = (void *)p->private;
+   struct ttm_pool_page_dat *dat = (void *)p->private;
 
-   return dma->vaddr & ~PAGE_MASK;
+   return dat->vaddr & ~PAGE_MASK;
}
 
return p->private;
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC][PATCH v6 3/7] drm: ttm_pool: Rework ttm_pool_free_page to allow us to use it as a function pointer

[John Stultz]

This refactors ttm_pool_free_page(), and by adding extra entries
to ttm_pool_page_dat, we then use it for all allocations, which
allows us to simplify the arguments needed to be passed to
ttm_pool_free_page().

This is critical for allowing the free function to be called
by the sharable drm_page_pool logic.

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/ttm/ttm_pool.c | 60 ++
 1 file changed, 32 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index c0274e256be3..eca36678f967 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -44,10 +44,14 @@
 /**
  * struct ttm_pool_page_dat - Helper object for coherent DMA mappings
  *
+ * @pool: ttm_pool pointer the page was allocated by
+ * @caching: the caching value the allocated page was configured for
  * @addr: original DMA address returned for the mapping
  * @vaddr: original vaddr return for the mapping and order in the lower bits
  */
 struct ttm_pool_page_dat {
+   struct ttm_pool *pool;
+   enum ttm_caching caching;
dma_addr_t addr;
unsigned long vaddr;
 };
@@ -71,13 +75,20 @@ static struct shrinker mm_shrinker;
 
 /* Allocate pages of size 1 << order with the given gfp_flags */
 static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t gfp_flags,
-   unsigned int order)
+   unsigned int order, enum ttm_caching 
caching)
 {
unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS;
struct ttm_pool_page_dat *dat;
struct page *p;
void *vaddr;
 
+   dat = kmalloc(sizeof(*dat), GFP_KERNEL);
+   if (!dat)
+   return NULL;
+
+   dat->pool = pool;
+   dat->caching = caching;
+
/* Don't set the __GFP_COMP flag for higher order allocations.
 * Mapping pages directly into an userspace process and calling
 * put_page() on a TTM allocated page is illegal.
@@ -88,15 +99,13 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool 
*pool, gfp_t gfp_flags,
 
if (!pool->use_dma_alloc) {
p = alloc_pages(gfp_flags, order);
-   if (p)
-   p->private = order;
+   if (!p)
+   goto error_free;
+   dat->vaddr = order;
+   p->private = (unsigned long)dat;
return p;
}
 
-   dat = kmalloc(sizeof(*dat), GFP_KERNEL);
-   if (!dat)
-   return NULL;
-
if (order)
attr |= DMA_ATTR_NO_WARN;
 
@@ -123,34 +132,34 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool 
*pool, gfp_t gfp_flags,
 }
 
 /* Reset the caching and pages of size 1 << order */
-static void ttm_pool_free_page(struct ttm_pool *pool, enum ttm_caching caching,
-  unsigned int order, struct page *p)
+static int ttm_pool_free_page(struct page *p, unsigned int order)
 {
unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS;
-   struct ttm_pool_page_dat *dat;
+   struct ttm_pool_page_dat *dat = (void *)p->private;
void *vaddr;
 
 #ifdef CONFIG_X86
/* We don't care that set_pages_wb is inefficient here. This is only
 * used when we have to shrink and CPU overhead is irrelevant then.
 */
-   if (caching != ttm_cached && !PageHighMem(p))
+   if (dat->caching != ttm_cached && !PageHighMem(p))
set_pages_wb(p, 1 << order);
 #endif
 
-   if (!pool || !pool->use_dma_alloc) {
+   if (!dat->pool || !dat->pool->use_dma_alloc) {
__free_pages(p, order);
-   return;
+   goto out;
}
 
if (order)
attr |= DMA_ATTR_NO_WARN;
 
-   dat = (void *)p->private;
vaddr = (void *)(dat->vaddr & PAGE_MASK);
-   dma_free_attrs(pool->dev, (1UL << order) * PAGE_SIZE, vaddr, dat->addr,
+   dma_free_attrs(dat->pool->dev, (1UL << order) * PAGE_SIZE, vaddr, 
dat->addr,
   attr);
+out:
kfree(dat);
+   return 1 << order;
 }
 
 /* Apply a new caching to an array of pages */
@@ -264,7 +273,7 @@ static void ttm_pool_type_fini(struct ttm_pool_type *pt)
mutex_unlock(&shrinker_lock);
 
list_for_each_entry_safe(p, tmp, &pt->pages, lru)
-   ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
+   ttm_pool_free_page(p, pt->order);
 }
 
 /* Return the pool_type to use for the given caching and order */
@@ -307,7 +316,7 @@ static unsigned int ttm_pool_shrink(void)

[RFC][PATCH v6 4/7] drm: ttm_pool: Rework ttm_pool to use drm_page_pool

[John Stultz]

This patch reworks the ttm_pool logic to utilize the recently
added drm_page_pool code.

Basically all the ttm_pool_type structures are replaced with
drm_page_pool pointers, and since the drm_page_pool logic has
its own shrinker, we can remove all of the ttm_pool shrinker
logic.

NOTE: There is one mismatch in the interfaces I'm not totally
happy with. The ttm_pool tracks all of its pooled pages across
a number of different pools, and tries to keep this size under
the specified page_pool_size value. With the drm_page_pool,
there may other users, however there is still one global
shrinker list of pools. So we can't easily reduce the ttm
pool under the ttm specified size without potentially doing
a lot of shrinking to other non-ttm pools. So either we can:
  1) Try to split it so each user of drm_page_pools manages its
 own pool shrinking.
  2) Push the max value into the drm_page_pool, and have it
 manage shrinking to fit under that global max. Then share
 those size/max values out so the ttm_pool debug output
 can have more context.

I've taken the second path in this patch set, but wanted to call
it out so folks could look closely.

Thoughts would be greatly appreciated here!

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/Kconfig|   1 +
 drivers/gpu/drm/ttm/ttm_pool.c | 199 +++--
 include/drm/ttm/ttm_pool.h |  23 +---
 3 files changed, 41 insertions(+), 182 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index d16bf340ed2e..d427abefabfb 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -181,6 +181,7 @@ config DRM_PAGE_POOL
 config DRM_TTM
tristate
depends on DRM && MMU
+   select DRM_PAGE_POOL
help
  GPU memory management subsystem for devices with multiple
  GPU memory types. Will be enabled automatically if a device driver
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index eca36678f967..dbbaf55ca5df 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -37,6 +37,7 @@
 #ifdef CONFIG_X86
 #include 
 #endif
+#include 
 #include 
 #include 
 #include 
@@ -63,15 +64,13 @@ module_param(page_pool_size, ulong, 0644);
 
 static atomic_long_t allocated_pages;
 
-static struct ttm_pool_type global_write_combined[MAX_ORDER];
-static struct ttm_pool_type global_uncached[MAX_ORDER];
+static struct drm_page_pool *global_write_combined[MAX_ORDER];
+static struct drm_page_pool *global_uncached[MAX_ORDER];
 
-static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
-static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
+static struct drm_page_pool *global_dma32_write_combined[MAX_ORDER];
+static struct drm_page_pool *global_dma32_uncached[MAX_ORDER];
 
 static struct mutex shrinker_lock;
-static struct list_head shrinker_list;
-static struct shrinker mm_shrinker;
 
 /* Allocate pages of size 1 << order with the given gfp_flags */
 static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t gfp_flags,
@@ -223,79 +222,26 @@ static void ttm_pool_unmap(struct ttm_pool *pool, 
dma_addr_t dma_addr,
   DMA_BIDIRECTIONAL);
 }
 
-/* Give pages into a specific pool_type */
-static void ttm_pool_type_give(struct ttm_pool_type *pt, struct page *p)
-{
-   spin_lock(&pt->lock);
-   list_add(&p->lru, &pt->pages);
-   spin_unlock(&pt->lock);
-   atomic_long_add(1 << pt->order, &allocated_pages);
-}
-
-/* Take pages from a specific pool_type, return NULL when nothing available */
-static struct page *ttm_pool_type_take(struct ttm_pool_type *pt)
-{
-   struct page *p;
-
-   spin_lock(&pt->lock);
-   p = list_first_entry_or_null(&pt->pages, typeof(*p), lru);
-   if (p) {
-   atomic_long_sub(1 << pt->order, &allocated_pages);
-   list_del(&p->lru);
-   }
-   spin_unlock(&pt->lock);
-
-   return p;
-}
-
-/* Initialize and add a pool type to the global shrinker list */
-static void ttm_pool_type_init(struct ttm_pool_type *pt, struct ttm_pool *pool,
-  enum ttm_caching caching, unsigned int order)
-{
-   pt->pool = pool;
-   pt->caching = caching;
-   pt->order = order;
-   spin_lock_init(&pt->lock);
-   INIT_LIST_HEAD(&pt->pages);
-
-   mutex_lock(&shrinker_lock);
-   list_add_tail(&pt->shrinker_list, &shrinker_list);
-   mutex_unlock(&shrinker_lock);
-}
-
-/* Remove a pool_type from the global shrinker list and free all pages */
-static void ttm_pool_type_fini(struct ttm_pool_type *pt)
-{
-

[RFC][PATCH v6 5/7] dma-buf: heaps: Add deferred-free-helper library code

[John Stultz]

This patch provides infrastructure for deferring buffer frees.

This is a feature ION provided which when used with some form
of a page pool, provides a nice performance boost in an
allocation microbenchmark. The reason it helps is it allows the
page-zeroing to be done out of the normal allocation/free path,
and pushed off to a kthread.

As not all heaps will find this useful, its implemented as
a optional helper library that heaps can utilize.

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
v2:
* Fix sleep in atomic issue from using a mutex, by switching
  to a spinlock as Reported-by: kernel test robot 
* Cleanup API to use a reason enum for clarity and add some documentation
  comments as suggested by Suren Baghdasaryan.
v3:
* Minor tweaks so it can be built as a module
* A few small fixups suggested by Daniel Mentz
v4:
* Tweak from Daniel Mentz to make sure the shrinker
  count/freed values are tracked in pages not bytes
v5:
* Fix up page count tracking as suggested by Suren Baghdasaryan
---
 drivers/dma-buf/heaps/Kconfig|   3 +
 drivers/dma-buf/heaps/Makefile   |   1 +
 drivers/dma-buf/heaps/deferred-free-helper.c | 145 +++
 drivers/dma-buf/heaps/deferred-free-helper.h |  55 +++
 4 files changed, 204 insertions(+)
 create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.c
 create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.h

diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..f7aef8bc7119 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -1,3 +1,6 @@
+config DMABUF_HEAPS_DEFERRED_FREE
+   tristate
+
 config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 974467791032..4e7839875615 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_DMABUF_HEAPS_DEFERRED_FREE) += deferred-free-helper.o
 obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)  += system_heap.o
 obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/deferred-free-helper.c 
b/drivers/dma-buf/heaps/deferred-free-helper.c
new file mode 100644
index ..672c3d5872e9
--- /dev/null
+++ b/drivers/dma-buf/heaps/deferred-free-helper.c
@@ -0,0 +1,145 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Deferred dmabuf freeing helper
+ *
+ * Copyright (C) 2020 Linaro, Ltd.
+ *
+ * Based on the ION page pool code
+ * Copyright (C) 2011 Google, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "deferred-free-helper.h"
+
+static LIST_HEAD(free_list);
+static size_t list_size_pages;
+wait_queue_head_t freelist_waitqueue;
+struct task_struct *freelist_task;
+static DEFINE_SPINLOCK(free_list_lock);
+
+static inline size_t size_to_pages(size_t size)
+{
+   if (!size)
+   return 0;
+   return ((size - 1) >> PAGE_SHIFT) + 1;
+}
+
+void deferred_free(struct deferred_freelist_item *item,
+  void (*free)(struct deferred_freelist_item*,
+   enum df_reason),
+  size_t size)
+{
+   unsigned long flags;
+
+   INIT_LIST_HEAD(&item->list);
+   item->size = size;
+   item->free = free;
+
+   spin_lock_irqsave(&free_list_lock, flags);
+   list_add(&item->list, &free_list);
+   list_size_pages += size_to_pages(size);
+   spin_unlock_irqrestore(&free_list_lock, flags);
+   wake_up(&freelist_waitqueue);
+}
+EXPORT_SYMBOL_GPL(deferred_free);
+
+static size_t free_one_item(enum df_reason reason)
+{
+   unsigned long flags;
+   size_t nr_pages;
+   struct deferred_freelist_item *item;
+
+   spin_lock_irqsave(&free_list_lock, flags);
+   if (list_empty(&free_list)) {
+   spin_unlock_irqrestore(&free_list_lock, flags);
+   return 0;
+   }
+   item = list_first_entry(&free_list, struct deferred_freelist_item, 
list);
+   list_del(&item->list);
+   nr_pages = size_to_pages(item->size);
+   list_size_pages -= nr_pages;
+   spin_unlock_irqrestore(&free_list_lock, flags);
+
+   item->free(item, reason);
+   return nr_pages;
+}
+
+static unsigned long get_freelist_size_pages(void)
+{
+   unsigned long size;
+   unsigned long flags;
+
+   spin_lock_irqsave(&free_list_lock, flags);
+   size = list_size_pages;
+   spin_unlock_irqrestore(&free_list_lock, flags);
+   return size;
+}
+
+static unsigned long freelist_shrink

[RFC][PATCH v6 6/7] dma-buf: system_heap: Add drm pagepool support to system heap

[John Stultz]

Utilize the drm pagepool code to speed up allocation
performance.

This is similar to the ION pagepool usage, but tries to
utilize generic code instead of a custom implementation.

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
v2:
* Fix build issue caused by selecting PAGE_POOL w/o NET
  as Reported-by: kernel test robot 
v3:
* Simplify the page zeroing logic a bit by using kmap_atomic
  instead of vmap as suggested by Daniel Mentz
v5:
* Shift away from networking page pool completely to
  dmabuf page pool implementation
v6:
* Switch again to using the drm_page_pool code shared w/
  ttm_pool
---
 drivers/dma-buf/heaps/Kconfig   |  1 +
 drivers/dma-buf/heaps/system_heap.c | 56 +++--
 2 files changed, 54 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index f7aef8bc7119..7e28934e0def 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -4,6 +4,7 @@ config DMABUF_HEAPS_DEFERRED_FREE
 config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
+   select DRM_PAGE_POOL
help
  Choose this option to enable the system dmabuf heap. The system heap
  is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/system_heap.c 
b/drivers/dma-buf/heaps/system_heap.c
index 17e0e9a68baf..6d39e9f32e36 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include 
+
 static struct dma_heap *sys_heap;
 
 struct system_heap_buffer {
@@ -53,6 +55,7 @@ static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP, 
LOW_ORDER_GFP};
  */
 static const unsigned int orders[] = {8, 4, 0};
 #define NUM_ORDERS ARRAY_SIZE(orders)
+struct drm_page_pool *pools[NUM_ORDERS];
 
 static struct sg_table *dup_sg_table(struct sg_table *table)
 {
@@ -281,18 +284,49 @@ static void system_heap_vunmap(struct dma_buf *dmabuf, 
struct dma_buf_map *map)
dma_buf_map_clear(map);
 }
 
+static int system_heap_free_pages(struct page *p, unsigned int order)
+{
+   __free_pages(p, order);
+   return 1 << order;
+}
+
+static int system_heap_zero_buffer(struct system_heap_buffer *buffer)
+{
+   struct sg_table *sgt = &buffer->sg_table;
+   struct sg_page_iter piter;
+   struct page *p;
+   void *vaddr;
+   int ret = 0;
+
+   for_each_sgtable_page(sgt, &piter, 0) {
+   p = sg_page_iter_page(&piter);
+   vaddr = kmap_atomic(p);
+   memset(vaddr, 0, PAGE_SIZE);
+   kunmap_atomic(vaddr);
+   }
+
+   return ret;
+}
+
 static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
 {
struct system_heap_buffer *buffer = dmabuf->priv;
struct sg_table *table;
struct scatterlist *sg;
-   int i;
+   int i, j;
+
+   /* Zero the buffer pages before adding back to the pool */
+   system_heap_zero_buffer(buffer);
 
table = &buffer->sg_table;
for_each_sg(table->sgl, sg, table->nents, i) {
struct page *page = sg_page(sg);
 
-   __free_pages(page, compound_order(page));
+   for (j = 0; j < NUM_ORDERS; j++) {
+   if (compound_order(page) == orders[j])
+   break;
+   }
+   drm_page_pool_add(pools[j], page);
}
sg_free_table(table);
kfree(buffer);
@@ -323,7 +357,9 @@ static struct page *alloc_largest_available(unsigned long 
size,
if (max_order < orders[i])
continue;
 
-   page = alloc_pages(order_flags[i], orders[i]);
+   page = drm_page_pool_fetch(pools[i]);
+   if (!page)
+   page = alloc_pages(order_flags[i], orders[i]);
if (!page)
continue;
return page;
@@ -428,6 +464,20 @@ static const struct dma_heap_ops system_heap_ops = {
 static int system_heap_create(void)
 {
struct dma_heap_export_info exp_info;
+   int i;
+
+   for (i = 0; i < NUM_ORDERS; i++) {
+   pools[i] = drm_page_pool_create(orders[i],
+   system_heap_free_pages);
+   if (IS_ERR(pools[i])) {
+   int j;
+
+   pr_err("%s: page pool creation failed!\n", __func__);
+   for (j = 0; j < i; j++)
+   drm_page_pool_destroy(pools[j]);
+   return PTR_ERR(pools[i]

[RFC][PATCH v6 7/7] dma-buf: system_heap: Add deferred freeing to the system heap

[John Stultz]

Utilize the deferred free helper library in the system heap.

This provides a nice performance bump and puts the
system heap performance on par with ION.

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
v2:
* Rework deferred-free api to use reason enum as suggested by
  Suren Baghdasaryan
---
 drivers/dma-buf/heaps/Kconfig   |  1 +
 drivers/dma-buf/heaps/system_heap.c | 31 ++---
 2 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 7e28934e0def..10632ccfb4a5 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -5,6 +5,7 @@ config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
select DRM_PAGE_POOL
+   select DMABUF_HEAPS_DEFERRED_FREE
help
  Choose this option to enable the system dmabuf heap. The system heap
  is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/system_heap.c 
b/drivers/dma-buf/heaps/system_heap.c
index 6d39e9f32e36..042244407db5 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -22,6 +22,7 @@
 #include 
 
 #include 
+#include "deferred-free-helper.h"
 
 static struct dma_heap *sys_heap;
 
@@ -33,6 +34,7 @@ struct system_heap_buffer {
struct sg_table sg_table;
int vmap_cnt;
void *vaddr;
+   struct deferred_freelist_item deferred_free;
 };
 
 struct dma_heap_attachment {
@@ -308,30 +310,45 @@ static int system_heap_zero_buffer(struct 
system_heap_buffer *buffer)
return ret;
 }
 
-static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
+static void system_heap_buf_free(struct deferred_freelist_item *item,
+enum df_reason reason)
 {
-   struct system_heap_buffer *buffer = dmabuf->priv;
+   struct system_heap_buffer *buffer;
struct sg_table *table;
struct scatterlist *sg;
int i, j;
 
+   buffer = container_of(item, struct system_heap_buffer, deferred_free);
/* Zero the buffer pages before adding back to the pool */
-   system_heap_zero_buffer(buffer);
+   if (reason == DF_NORMAL)
+   if (system_heap_zero_buffer(buffer))
+   reason = DF_UNDER_PRESSURE; // On failure, just free
 
table = &buffer->sg_table;
for_each_sg(table->sgl, sg, table->nents, i) {
struct page *page = sg_page(sg);
 
-   for (j = 0; j < NUM_ORDERS; j++) {
-   if (compound_order(page) == orders[j])
-   break;
+   if (reason == DF_UNDER_PRESSURE) {
+   __free_pages(page, compound_order(page));
+   } else {
+   for (j = 0; j < NUM_ORDERS; j++) {
+   if (compound_order(page) == orders[j])
+   break;
+   }
+   drm_page_pool_add(pools[j], page);
}
-   drm_page_pool_add(pools[j], page);
}
sg_free_table(table);
kfree(buffer);
 }
 
+static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
+{
+   struct system_heap_buffer *buffer = dmabuf->priv;
+
+   deferred_free(&buffer->deferred_free, system_heap_buf_free, 
buffer->len);
+}
+
 static const struct dma_buf_ops system_heap_buf_ops = {
.attach = system_heap_attach,
.detach = system_heap_detach,
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] Support second Image Signal Processor on rk3399

[Heiko Stübner]

Hi Sebastian,

Am Freitag, 5. Februar 2021, 07:43:35 CET schrieb Sebastian Fricke:
> On 03.02.2021 20:54, Heiko Stübner wrote:
> >Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke:
> >> I have tested your patch set on my nanoPC-T4, here is a complete log
> >> with:
> >> - relevant kernel log entries
> >> - system information
> >> - media ctl output
> >> - sysfs entry information
> >>
> >> https://paste.debian.net/1183874/
> >>
> >> Additionally, to your patchset I have applied the following patches:
> >> https://github.com/initBasti/Linux_kernel_media_tree_fork/commits/dual_cam_setup
> >>
> >> And just to not cause confusion the `media_dev` entries come from this
> >> unmerged series:
> >> https://patchwork.kernel.org/project/linux-media/list/?series=426269
> >>
> >> I have actually been able to stream with both of my cameras at the same
> >> time using the libcamera cam command.
> >> I would like to thank you a lot for making this possible.
> >
> >Thanks for testing a dual camera setup. On my board I could only test
> >the second ISP. And really glad it works for you tool :-) .
> >
> >Out of curiosity, do you also see that green tint in the images the cameras
> >produce?
> 
> Yes, I do. Actually, I currently have two forms of a green tint, on my
> OV13850 everything is quite dark and greenish, which is caused by the
> missing 3A algorithms. On my OV4689, I have big patches of the image
> with bright green color and flickering, I investigated if this is
> connected to the 2nd ISP instance, but that doesn't seem to be the case
> as I have the same results when I switch the CSI ports of the cameras.
> 
> I have found another issue, while testing I discovered following
> issue:
> When I start the system with an HDMI monitor connected, then the camera
> on the 2nd port doesn't work. This is probably because the RX/TX is
> reserved as a TX.
> But it made me wonder because if the system has an RX, a TX, and
> an RX/TX, why isn't the pure TX used by the monitor and the
> cameras take RX and RX/TX?
> Or do you think that this is maybe a malfunction of this patch?

I don't think it is an issue with this specific series, but still puzzling.

I.e. the DPHYs are actually only relevant to the DSI controllers,
with TX0 being connected to DSI0 and TX1RX1 being connected
to DSI1. So having an hdmi display _in theory_ shouldn't matter at all.

Out of curiosity what happens, when you boot without hdmi connected
turn on the cameras, connect the hdmi after this, try the cameras again?


Heiko

> 
> >
> >Thanks
> >Heiko
> 
> Greetings,
> Sebastian
> 
> >
> >
> >> If you like to you can add:
> >> Tested-by: Sebastian Fricke 
> >>
> >> On 02.02.2021 15:56, Heiko Stuebner wrote:
> >> >The rk3399 has two ISPs and right now only the first one is usable.
> >> >The second ISP is connected to the TXRX dphy on the soc.
> >> >
> >> >The phy of ISP1 is only accessible through the DSI controller's
> >> >io-memory, so this series adds support for simply using the dsi
> >> >controller is a phy if needed.
> >> >
> >> >That solution is needed at least on rk3399 and rk3288 but no-one
> >> >has looked at camera support on rk3288 at all, so right now
> >> >only implement the rk3399 specifics.
> >> >
> >> >
> >> >Heiko Stuebner (6):
> >> >  drm/rockchip: dsi: add own additional pclk handling
> >> >  dt-bindings: display: rockchip-dsi: add optional #phy-cells property
> >> >  drm/rockchip: dsi: add ability to work as a phy instead of full dsi
> >> >  arm64: dts: rockchip: add #phy-cells to mipi-dsi1
> >> >  arm64: dts: rockchip: add cif clk-control pinctrl for rk3399
> >> >  arm64: dts: rockchip: add isp1 node on rk3399
> >> >
> >> > .../display/rockchip/dw_mipi_dsi_rockchip.txt |   1 +
> >> > arch/arm64/boot/dts/rockchip/rk3399.dtsi  |  39 ++
> >> > drivers/gpu/drm/rockchip/Kconfig  |   2 +
> >> > .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   | 342 ++
> >> > 4 files changed, 384 insertions(+)
> >> >
> >>
> >
> >
> >
> >
> 




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 211425] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=211425

Andreas (icedragon...@web.de) changed:

   What|Removed |Added

 Kernel Version|5.10.12 |5.10.13

--- Comment #3 from Andreas (icedragon...@web.de) ---
Hi, it is still reproducibility with mainline kernel 5.10.13 - at least it
takes the 20sec time to re-enable the screen - as mentioned in the error
message below.:

[Fr Feb  5 09:00:00 2021] [drm] perform_link_training_with_retries: Link
training attempt 1 of 4 failed
[Fr Feb  5 09:00:21 2021] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
more than 20secs aborting
[Fr Feb  5 09:00:21 2021] [drm:amdgpu_atom_execute_table_locked] *ERROR*
atombios stuck executing B200 (len 3615, WS 8, PS 0) @ 0xB34E
[Fr Feb  5 09:00:21 2021] [drm:amdgpu_atom_execute_table_locked] *ERROR*
atombios stuck executing B0F4 (len 268, WS 4, PS 0) @ 0xB147
[Fr Feb  5 09:00:21 2021] [drm:dcn10_link_encoder_enable_dp_output] *ERROR*
dcn10_link_encoder_enable_dp_output: Failed to execute VBIOS command table!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH v6 3/7] drm: ttm_pool: Rework ttm_pool_free_page to allow us to use it as a function pointer

[Christian König]

Am 05.02.21 um 09:06 schrieb John Stultz:

This refactors ttm_pool_free_page(), and by adding extra entries
to ttm_pool_page_dat, we then use it for all allocations, which
allows us to simplify the arguments needed to be passed to
ttm_pool_free_page().


This is a clear NAK since the peer page data is just a workaround for 
the DMA-API hack to grab pages from there.


Adding this to all pages would increase the memory footprint drastically.

christian.



This is critical for allowing the free function to be called
by the sharable drm_page_pool logic.

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
  drivers/gpu/drm/ttm/ttm_pool.c | 60 ++
  1 file changed, 32 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index c0274e256be3..eca36678f967 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -44,10 +44,14 @@
  /**
   * struct ttm_pool_page_dat - Helper object for coherent DMA mappings
   *
+ * @pool: ttm_pool pointer the page was allocated by
+ * @caching: the caching value the allocated page was configured for
   * @addr: original DMA address returned for the mapping
   * @vaddr: original vaddr return for the mapping and order in the lower bits
   */
  struct ttm_pool_page_dat {
+   struct ttm_pool *pool;
+   enum ttm_caching caching;
dma_addr_t addr;
unsigned long vaddr;
  };
@@ -71,13 +75,20 @@ static struct shrinker mm_shrinker;
  
  /* Allocate pages of size 1 << order with the given gfp_flags */

  static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t 
gfp_flags,
-   unsigned int order)
+   unsigned int order, enum ttm_caching 
caching)
  {
unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS;
struct ttm_pool_page_dat *dat;
struct page *p;
void *vaddr;
  
+	dat = kmalloc(sizeof(*dat), GFP_KERNEL);

+   if (!dat)
+   return NULL;
+
+   dat->pool = pool;
+   dat->caching = caching;
+
/* Don't set the __GFP_COMP flag for higher order allocations.
 * Mapping pages directly into an userspace process and calling
 * put_page() on a TTM allocated page is illegal.
@@ -88,15 +99,13 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool 
*pool, gfp_t gfp_flags,
  
  	if (!pool->use_dma_alloc) {

p = alloc_pages(gfp_flags, order);
-   if (p)
-   p->private = order;
+   if (!p)
+   goto error_free;
+   dat->vaddr = order;
+   p->private = (unsigned long)dat;
return p;
}
  
-	dat = kmalloc(sizeof(*dat), GFP_KERNEL);

-   if (!dat)
-   return NULL;
-
if (order)
attr |= DMA_ATTR_NO_WARN;
  
@@ -123,34 +132,34 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t gfp_flags,

  }
  
  /* Reset the caching and pages of size 1 << order */

-static void ttm_pool_free_page(struct ttm_pool *pool, enum ttm_caching caching,
-  unsigned int order, struct page *p)
+static int ttm_pool_free_page(struct page *p, unsigned int order)
  {
unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS;
-   struct ttm_pool_page_dat *dat;
+   struct ttm_pool_page_dat *dat = (void *)p->private;
void *vaddr;
  
  #ifdef CONFIG_X86

/* We don't care that set_pages_wb is inefficient here. This is only
 * used when we have to shrink and CPU overhead is irrelevant then.
 */
-   if (caching != ttm_cached && !PageHighMem(p))
+   if (dat->caching != ttm_cached && !PageHighMem(p))
set_pages_wb(p, 1 << order);
  #endif
  
-	if (!pool || !pool->use_dma_alloc) {

+   if (!dat->pool || !dat->pool->use_dma_alloc) {
__free_pages(p, order);
-   return;
+   goto out;
}
  
  	if (order)

attr |= DMA_ATTR_NO_WARN;
  
-	dat = (void *)p->private;

vaddr = (void *)(dat->vaddr & PAGE_MASK);
-   dma_free_attrs(pool->dev, (1UL << order) * PAGE_SIZE, vaddr, dat->addr,
+   dma_free_attrs(dat->pool->dev, (1UL << order) * PAGE_SIZE, vaddr, 
dat->addr,
   attr);
+out:
kfree(dat);
+   return 1 << order;
  }
  
  /* Apply a new caching to an array of pages */

@@ -264,7 +273,7 @@ static void ttm_pool_type_fini(struct ttm_pool_type *pt)
mutex_unlock(&shrinker_lock);
  
  	list_for_each_entry_safe(p, tmp, &pt->pages, lru)

- 

Re: [PATCH] drm/komeda: Fix bit check to import to value of proper type

[Steven Price]

+CC the other Komeda maintainers

On 04/02/2021 13:11, carsten.haitz...@foss.arm.com wrote:

From: Carsten Haitzler 

Another issue found by KASAN. The bit finding is buried inside the
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds accesses.
This fixes that.

Signed-off-by: Carsten Haitzler 


Looks fine to me:

Reviewed-by: Steven Price 


---
  .../drm/arm/display/include/malidp_utils.h|  3 ---
  .../drm/arm/display/komeda/komeda_pipeline.c  | 16 +++-
  .../display/komeda/komeda_pipeline_state.c| 19 +++
  3 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/include/malidp_utils.h 
b/drivers/gpu/drm/arm/display/include/malidp_utils.h
index 3bc383d5bf73..49a1d7f3539c 100644
--- a/drivers/gpu/drm/arm/display/include/malidp_utils.h
+++ b/drivers/gpu/drm/arm/display/include/malidp_utils.h
@@ -13,9 +13,6 @@
  #define has_bit(nr, mask) (BIT(nr) & (mask))
  #define has_bits(bits, mask)  (((bits) & (mask)) == (bits))
  
-#define dp_for_each_set_bit(bit, mask) \

-   for_each_set_bit((bit), ((unsigned long *)&(mask)), sizeof(mask) * 8)
-
  #define dp_wait_cond(__cond, __tries, __min_range, __max_range)   \
  ({\
int num_tries = __tries;\
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index 719a79728e24..06c595378dda 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -46,8 +46,9 @@ void komeda_pipeline_destroy(struct komeda_dev *mdev,
  {
struct komeda_component *c;
int i;
+   unsigned long avail_comps = pipe->avail_comps;
  
-	dp_for_each_set_bit(i, pipe->avail_comps) {

+   for_each_set_bit(i, &avail_comps, 32) {
c = komeda_pipeline_get_component(pipe, i);
komeda_component_destroy(mdev, c);
}
@@ -247,6 +248,7 @@ static void komeda_pipeline_dump(struct komeda_pipeline 
*pipe)
  {
struct komeda_component *c;
int id;
+   unsigned long avail_comps = pipe->avail_comps;
  
  	DRM_INFO("Pipeline-%d: n_layers: %d, n_scalers: %d, output: %s.\n",

 pipe->id, pipe->n_layers, pipe->n_scalers,
@@ -258,7 +260,7 @@ static void komeda_pipeline_dump(struct komeda_pipeline 
*pipe)
 pipe->of_output_links[1] ?
 pipe->of_output_links[1]->full_name : "none");
  
-	dp_for_each_set_bit(id, pipe->avail_comps) {

+   for_each_set_bit(id, &avail_comps, 32) {
c = komeda_pipeline_get_component(pipe, id);
  
  		komeda_component_dump(c);

@@ -270,8 +272,9 @@ static void komeda_component_verify_inputs(struct 
komeda_component *c)
struct komeda_pipeline *pipe = c->pipeline;
struct komeda_component *input;
int id;
+   unsigned long supported_inputs = c->supported_inputs;
  
-	dp_for_each_set_bit(id, c->supported_inputs) {

+   for_each_set_bit(id, &supported_inputs, 32) {
input = komeda_pipeline_get_component(pipe, id);
if (!input) {
c->supported_inputs &= ~(BIT(id));
@@ -302,8 +305,9 @@ static void komeda_pipeline_assemble(struct komeda_pipeline 
*pipe)
struct komeda_component *c;
struct komeda_layer *layer;
int i, id;
+   unsigned long avail_comps = pipe->avail_comps;
  
-	dp_for_each_set_bit(id, pipe->avail_comps) {

+   for_each_set_bit(id, &avail_comps, 32) {
c = komeda_pipeline_get_component(pipe, id);
komeda_component_verify_inputs(c);
}
@@ -355,13 +359,15 @@ void komeda_pipeline_dump_register(struct komeda_pipeline 
*pipe,
  {
struct komeda_component *c;
u32 id;
+   unsigned long avail_comps;
  
  	seq_printf(sf, "\n Pipeline-%d ==\n", pipe->id);
  
  	if (pipe->funcs && pipe->funcs->dump_register)

pipe->funcs->dump_register(pipe, sf);
  
-	dp_for_each_set_bit(id, pipe->avail_comps) {

+   avail_comps = pipe->avail_comps;
+   for_each_set_bit(id, &avail_comps, 32) {
c = komeda_pipeline_get_component(pipe, id);
  
  		seq_printf(sf, "\n--%s--\n", c->name);

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index e8b1e15312d8..176cdf411f9f 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -1232,14 +1232,15 @@ komeda_pipeline_unbound_components(struct 
komeda_pipeline *pipe,
struct komeda_pipeline_state *old = priv_to_pipe_st(pipe->obj.state);
struct komeda_component_state *c_st;
struct kom

Re: [PATCH v2 2/2] drm: bridge: Add SN65DSI84 DSI to LVDS bridge

[Jagan Teki]

On Fri, Feb 5, 2021 at 4:50 AM Marek Vasut  wrote:
>
> On 2/4/21 11:29 PM, Laurent Pinchart wrote:
> > Hi Jagan,
> >
> > Thank you for the patch.
> >
> > On Wed, Feb 03, 2021 at 12:42:56PM +0530, Jagan Teki wrote:
> >> SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from
> >> Texas Instruments.
> >>
> >> SN65DSI83, SN65DSI85 are variants of the same family of bridge
> >> controllers.
> >>
> >> Right now the bridge driver is supporting a single link, dual-link
> >> support requires to initiate I2C Channel B registers.
> >
> > MArek Vasut (on CC) has very recently posted a driver for the SN65DSI86.
> > Should the two drivers be merged together ?
>
> Since Jagan's V1 was out first, I will let Jagan pick whatever might be
> useful from the driver I posted, probably the O(1) clock rate
> calculation and some of the regmap stuff, and once there is some merged
> result, I am happy to test it on my hardware. The DSI83 is I think the
> same as DSI84, except with half of the channels.

Thanks. please wait for the v3 series, we can discuss further on top.

Jagan.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/2] dmabuf: Add dmabuf inode number to /proc/*/fdinfo

[Randy Dunlap]

On 2/4/21 6:23 PM, Kalesh Singh wrote:
> If a FD refers to a DMA buffer add the DMA buffer inode number to
> /proc//fdinfo/ and /proc//task//fdindo/.
> 
> The dmabuf inode number allows userspace to uniquely identify the buffer
> and avoids a dependency on /proc//fd/* when accounting per-process
> DMA buffer sizes.
> 
> Signed-off-by: Kalesh Singh 
> ---
> Changes in v3:
>   - Add documentation in proc.rst

Hi,
Thanks for the doc update.

> Changes in v2:
>   - Update patch description
> 
>  Documentation/filesystems/proc.rst | 17 +
>  drivers/dma-buf/dma-buf.c  |  1 +
>  2 files changed, 18 insertions(+)
> 

Acked-by: Randy Dunlap  # for 
Documentation/filesystems/proc.rst


-- 
~Randy

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] dmabuf: Add dmabuf inode number to /proc/*/fdinfo

[Randy Dunlap]

On 2/4/21 3:28 PM, Kalesh Singh wrote:
> If a FD refers to a DMA buffer add the DMA buffer inode number to
> /proc//fdinfo/ and /proc//task//fdindo/.
> 
> The dmabuf inode number allows userspace to uniquely identify the buffer
> and avoids a dependency on /proc//fd/* when accounting per-process
> DMA buffer sizes.
> 
> Signed-off-by: Kalesh Singh 
> ---

Hi,
Please document this change in
Documentation/filesystems/proc.rst.

Thanks.

> 
> Changes in v2: 
>   - Update patch desciption
> 
>  drivers/dma-buf/dma-buf.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 9ad6397aaa97..d869099ede83 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -414,6 +414,7 @@ static void dma_buf_show_fdinfo(struct seq_file *m, 
> struct file *file)
>  {
>   struct dma_buf *dmabuf = file->private_data;
>  
> + seq_printf(m, "dmabuf_inode_no:\t%lu\n", file_inode(file)->i_ino);
>   seq_printf(m, "size:\t%zu\n", dmabuf->size);
>   /* Don't count the temporary reference taken inside procfs seq_show */
>   seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1);
> 


-- 
~Randy

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip

[Chenyang Li]

This patch adds an initial DRM driver for the Loongson LS7A1000
bridge chip(LS7A). The LS7A bridge chip contains two display
controllers, support dual display output. The maximum support for
each channel display is to 1920x1080@60Hz.
At present, DC device detection and DRM driver registration are
completed, the crtc/plane/encoder/connector objects has been
implemented.
On Loongson 3A4000 CPU and 7A1000 system, we have achieved the use
of dual screen, and support dual screen clone mode and expansion
mode.

v4:
- Move the mode_valid function to the crtc.

v3:
- Move the mode_valid function to the connector and optimize it.
- Fix num_crtc calculation method.

v2:
- Complete the case of 32-bit color in CRTC.

Signed-off-by: Chenyang Li 
---
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/loongson/Kconfig  |  14 +
 drivers/gpu/drm/loongson/Makefile |  14 +
 drivers/gpu/drm/loongson/loongson_connector.c |  48 
 drivers/gpu/drm/loongson/loongson_crtc.c  | 241 
 drivers/gpu/drm/loongson/loongson_device.c|  54 
 drivers/gpu/drm/loongson/loongson_drv.c   | 269 ++
 drivers/gpu/drm/loongson/loongson_drv.h   | 131 +
 drivers/gpu/drm/loongson/loongson_encoder.c   |  37 +++
 drivers/gpu/drm/loongson/loongson_plane.c | 102 +++
 11 files changed, 913 insertions(+)
 create mode 100644 drivers/gpu/drm/loongson/Kconfig
 create mode 100644 drivers/gpu/drm/loongson/Makefile
 create mode 100644 drivers/gpu/drm/loongson/loongson_connector.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_crtc.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_device.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_drv.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_drv.h
 create mode 100644 drivers/gpu/drm/loongson/loongson_encoder.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_plane.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0973f408d75f..6ed1b6dc2f25 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -374,6 +374,8 @@ source "drivers/gpu/drm/xen/Kconfig"
 
 source "drivers/gpu/drm/vboxvideo/Kconfig"
 
+source "drivers/gpu/drm/loongson/Kconfig"
+
 source "drivers/gpu/drm/lima/Kconfig"
 
 source "drivers/gpu/drm/panfrost/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index fefaff4c832d..f87da730ea6d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -119,6 +119,7 @@ obj-$(CONFIG_DRM_PL111) += pl111/
 obj-$(CONFIG_DRM_TVE200) += tve200/
 obj-$(CONFIG_DRM_XEN) += xen/
 obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/
+obj-$(CONFIG_DRM_LOONGSON) += loongson/
 obj-$(CONFIG_DRM_LIMA)  += lima/
 obj-$(CONFIG_DRM_PANFROST) += panfrost/
 obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
diff --git a/drivers/gpu/drm/loongson/Kconfig b/drivers/gpu/drm/loongson/Kconfig
new file mode 100644
index ..43eb0c80cc12
--- /dev/null
+++ b/drivers/gpu/drm/loongson/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+config DRM_LOONGSON
+   tristate "DRM support for LS7A1000 bridge chipset"
+   depends on DRM && PCI
+   depends on CPU_LOONGSON64
+   select DRM_KMS_HELPER
+   select DRM_VRAM_HELPER
+   select DRM_TTM
+   select DRM_TTM_HELPER
+   default n
+   help
+ Support the display controllers found on the Loongson LS7A1000
+ bridge.
diff --git a/drivers/gpu/drm/loongson/Makefile 
b/drivers/gpu/drm/loongson/Makefile
new file mode 100644
index ..22d063953b78
--- /dev/null
+++ b/drivers/gpu/drm/loongson/Makefile
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Makefile for loongson drm drivers.
+# This driver provides support for the
+# Direct Rendering Infrastructure (DRI)
+
+ccflags-y := -Iinclude/drm
+loongson-y := loongson_drv.o \
+   loongson_crtc.o \
+   loongson_plane.o \
+   loongson_device.o \
+   loongson_connector.o \
+   loongson_encoder.o
+obj-$(CONFIG_DRM_LOONGSON) += loongson.o
diff --git a/drivers/gpu/drm/loongson/loongson_connector.c 
b/drivers/gpu/drm/loongson/loongson_connector.c
new file mode 100644
index ..6b1f0ffa33bd
--- /dev/null
+++ b/drivers/gpu/drm/loongson/loongson_connector.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include "loongson_drv.h"
+
+static int loongson_get_modes(struct drm_connector *connector)
+{
+   int count;
+
+   count = drm_add_modes_noedid(connector, 1920, 1080);
+   drm_set_preferred_mode(connector, 1024, 768);
+
+   return count;
+}
+
+static const struct drm_connector_helper_funcs loongson_connector_helper = {
+   .get_modes = loongson_get_modes,
+};
+
+static const struct drm_connector_funcs loongson_connector_funcs = {
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .destroy = drm_connector_cleanup,
+   .reset = drm_atomic_h

[PATCH] drm: DRM_FOURCC_STANDALONE macro support

[James Park]

Use DRM_FOURCC_STANDALONE to include drm_fourcc.h without drm.h.

Copy type definitions from drm.h to drm_fourcc.h, and wrap with
DRM_BASIC_TYPED_DEFINED to avoid redundant inclusion.

This will allow code to avoid unnecessary definitions.

Signed-off-by: James Park 
---
 include/uapi/drm/drm.h| 35 ---
 include/uapi/drm/drm_fourcc.h | 35 +++
 2 files changed, 63 insertions(+), 7 deletions(-)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 808b48a..5640062 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -36,23 +36,25 @@
 #ifndef _DRM_H_
 #define _DRM_H_
 
+/**
+ * DRM_BASIC_TYPES_DEFINED section exists in both drm.h and drm_fourcc.h files.
+ * Do not modify the section in one file without updating the other!
+ */
+
+#ifndef DRM_BASIC_TYPES_DEFINED
+#define DRM_BASIC_TYPES_DEFINED
+
 #if defined(__KERNEL__)
 
 #include 
-#include 
-typedef unsigned int drm_handle_t;
 
 #elif defined(__linux__)
 
 #include 
-#include 
-typedef unsigned int drm_handle_t;
 
-#else /* One of the BSDs */
+#else /* Not Linux */
 
 #include 
-#include 
-#include 
 typedef int8_t   __s8;
 typedef uint8_t  __u8;
 typedef int16_t  __s16;
@@ -62,6 +64,25 @@ typedef uint32_t __u32;
 typedef int64_t  __s64;
 typedef uint64_t __u64;
 typedef size_t   __kernel_size_t;
+
+#endif
+
+#endif /* DRM_BASIC_TYPES_DEFINED */
+
+#if defined(__KERNEL__)
+
+#include 
+typedef unsigned int drm_handle_t;
+
+#elif defined(__linux__)
+
+#include 
+typedef unsigned int drm_handle_t;
+
+#else /* One of the BSDs */
+
+#include 
+#include 
 typedef unsigned long drm_handle_t;
 
 #endif
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 723c8e2..5e5f4cf 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -24,7 +24,42 @@
 #ifndef DRM_FOURCC_H
 #define DRM_FOURCC_H
 
+/**
+ * DRM_BASIC_TYPES_DEFINED section exists in both drm.h and drm_fourcc.h files.
+ * Do not modify the section in one file without updating the other!
+ */
+
+#ifndef DRM_BASIC_TYPES_DEFINED
+#define DRM_BASIC_TYPES_DEFINED
+
+#if defined(__KERNEL__)
+
+#include 
+
+#elif defined(__linux__)
+
+#include 
+
+#else /* Not Linux */
+
+#include 
+typedef int8_t   __s8;
+typedef uint8_t  __u8;
+typedef int16_t  __s16;
+typedef uint16_t __u16;
+typedef int32_t  __s32;
+typedef uint32_t __u32;
+typedef int64_t  __s64;
+typedef uint64_t __u64;
+typedef size_t   __kernel_size_t;
+
+#endif
+
+#endif /* DRM_BASIC_TYPES_DEFINED */
+
+#ifndef DRM_FOURCC_STANDALONE
 #include "drm.h"
+#endif
 
 #if defined(__cplusplus)
 extern "C" {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] Support second Image Signal Processor on rk3399

[Sebastian Fricke]

Hey Heiko,

On 03.02.2021 20:54, Heiko Stübner wrote:

Hi Sebastian,

Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke:

Hey Heiko,

I have tested your patch set on my nanoPC-T4, here is a complete log
with:
- relevant kernel log entries
- system information
- media ctl output
- sysfs entry information

https://paste.debian.net/1183874/

Additionally, to your patchset I have applied the following patches:
https://github.com/initBasti/Linux_kernel_media_tree_fork/commits/dual_cam_setup

And just to not cause confusion the `media_dev` entries come from this
unmerged series:
https://patchwork.kernel.org/project/linux-media/list/?series=426269

I have actually been able to stream with both of my cameras at the same
time using the libcamera cam command.
I would like to thank you a lot for making this possible.


Thanks for testing a dual camera setup. On my board I could only test
the second ISP. And really glad it works for you tool :-) .

Out of curiosity, do you also see that green tint in the images the cameras
produce?


Yes, I do. Actually, I currently have two forms of a green tint, on my
OV13850 everything is quite dark and greenish, which is caused by the
missing 3A algorithms. On my OV4689, I have big patches of the image
with bright green color and flickering, I investigated if this is
connected to the 2nd ISP instance, but that doesn't seem to be the case
as I have the same results when I switch the CSI ports of the cameras.

I have found another issue, while testing I discovered following
issue:
When I start the system with an HDMI monitor connected, then the camera
on the 2nd port doesn't work. This is probably because the RX/TX is
reserved as a TX.
But it made me wonder because if the system has an RX, a TX, and
an RX/TX, why isn't the pure TX used by the monitor and the
cameras take RX and RX/TX?
Or do you think that this is maybe a malfunction of this patch?



Thanks
Heiko


Greetings,
Sebastian





If you like to you can add:
Tested-by: Sebastian Fricke 

On 02.02.2021 15:56, Heiko Stuebner wrote:
>The rk3399 has two ISPs and right now only the first one is usable.
>The second ISP is connected to the TXRX dphy on the soc.
>
>The phy of ISP1 is only accessible through the DSI controller's
>io-memory, so this series adds support for simply using the dsi
>controller is a phy if needed.
>
>That solution is needed at least on rk3399 and rk3288 but no-one
>has looked at camera support on rk3288 at all, so right now
>only implement the rk3399 specifics.
>
>
>Heiko Stuebner (6):
>  drm/rockchip: dsi: add own additional pclk handling
>  dt-bindings: display: rockchip-dsi: add optional #phy-cells property
>  drm/rockchip: dsi: add ability to work as a phy instead of full dsi
>  arm64: dts: rockchip: add #phy-cells to mipi-dsi1
>  arm64: dts: rockchip: add cif clk-control pinctrl for rk3399
>  arm64: dts: rockchip: add isp1 node on rk3399
>
> .../display/rockchip/dw_mipi_dsi_rockchip.txt |   1 +
> arch/arm64/boot/dts/rockchip/rk3399.dtsi  |  39 ++
> drivers/gpu/drm/rockchip/Kconfig  |   2 +
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   | 342 ++
> 4 files changed, 384 insertions(+)
>







___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH v6 1/7] drm: Add a sharable drm page-pool implementation

[Christian König]

Am 05.02.21 um 09:06 schrieb John Stultz:

This adds a shrinker controlled page pool, closely
following the ttm_pool logic, which is abstracted out
a bit so it can be used by other non-ttm drivers.

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
  drivers/gpu/drm/Kconfig |   4 +
  drivers/gpu/drm/Makefile|   1 +
  drivers/gpu/drm/page_pool.c | 220 
  include/drm/page_pool.h |  54 +
  4 files changed, 279 insertions(+)
  create mode 100644 drivers/gpu/drm/page_pool.c
  create mode 100644 include/drm/page_pool.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0973f408d75f..d16bf340ed2e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -174,6 +174,10 @@ config DRM_DP_CEC
  Note: not all adapters support this feature, and even for those
  that do support this they often do not hook up the CEC pin.
  
+config DRM_PAGE_POOL

+   bool
+   depends on DRM
+
  config DRM_TTM
tristate
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index fefaff4c832d..877e0111ed34 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,6 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
  drm-$(CONFIG_PCI) += drm_pci.o
  drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
  drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_DRM_PAGE_POOL) += page_pool.o
  
  drm_vram_helper-y := drm_gem_vram_helper.o

  obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
diff --git a/drivers/gpu/drm/page_pool.c b/drivers/gpu/drm/page_pool.c
new file mode 100644
index ..2139f86e6ca7
--- /dev/null
+++ b/drivers/gpu/drm/page_pool.c
@@ -0,0 +1,220 @@
+// SPDX-License-Identifier: GPL-2.0


Please use a BSD/MIT compatible license if you want to copy this from 
the TTM code.



+/*
+ * DRM page pool system
+ *
+ * Copyright (C) 2020 Linaro Ltd.
+ *
+ * Based on the ION page pool code
+ * Copyright (C) 2011 Google, Inc.
+ * As well as the ttm_pool code
+ * Copyright (C) 2020 Advanced Micro Devices, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static LIST_HEAD(pool_list);
+static DEFINE_MUTEX(pool_list_lock);
+static atomic_long_t total_pages;
+static unsigned long page_pool_max;
+MODULE_PARM_DESC(page_pool_max, "Number of pages in the WC/UC/DMA pool");
+module_param(page_pool_max, ulong, 0644);
+
+void drm_page_pool_set_max(unsigned long max)
+{
+   /* only write once */
+   if (!page_pool_max)
+   page_pool_max = max;
+}
+
+unsigned long drm_page_pool_get_max(void)
+{
+   return page_pool_max;
+}
+
+unsigned long drm_page_pool_get_total(void)
+{
+   return atomic_long_read(&total_pages);
+}
+
+int drm_page_pool_get_size(struct drm_page_pool *pool)
+{
+   int ret;
+
+   spin_lock(&pool->lock);
+   ret = pool->count;
+   spin_unlock(&pool->lock);


Maybe use an atomic for the count instead?


+   return ret;
+}
+
+static inline unsigned int drm_page_pool_free_pages(struct drm_page_pool *pool,
+   struct page *page)
+{
+   return pool->free(page, pool->order);
+}
+
+static int drm_page_pool_shrink_one(void);
+
+void drm_page_pool_add(struct drm_page_pool *pool, struct page *page)
+{
+   spin_lock(&pool->lock);
+   list_add_tail(&page->lru, &pool->items);
+   pool->count++;
+   atomic_long_add(1 << pool->order, &total_pages);
+   spin_unlock(&pool->lock);
+
+   mod_node_page_state(page_pgdat(page), NR_KERNEL_MISC_RECLAIMABLE,
+   1 << pool->order);


Hui what? What should that be good for?


+
+   /* make sure we don't grow too large */
+   while (page_pool_max && atomic_long_read(&total_pages) > page_pool_max)
+   drm_page_pool_shrink_one();
+}
+EXPORT_SYMBOL_GPL(drm_page_pool_add);
+
+static struct page *drm_page_pool_remove(struct drm_page_pool *pool)
+{
+   struct page *page;
+
+   if (!pool->count)
+   return NULL;


Better use list_first_entry_or_null instead of checking the count.

This way you can also pull the lock into the function.


+
+   page = list_first_entry(&pool->items, struct page, lru);
+   pool->count--;
+   atomic_long_sub(1 << pool->order, &total_pages);
+
+   list_del(&page->lru);
+   mod_node_page_state(page_pgdat(page), NR_KERNEL_MISC_RECLAIMABLE,
+   -(1 << pool->order));
+   return page;
+}
+
+struct page *drm_page_pool_fetch(struct drm_page_pool *pool)
+{
+   struct page *page = NULL;

Re: [RFC][PATCH v6 4/7] drm: ttm_pool: Rework ttm_pool to use drm_page_pool

[Christian König]

Am 05.02.21 um 09:06 schrieb John Stultz:

This patch reworks the ttm_pool logic to utilize the recently
added drm_page_pool code.

Basically all the ttm_pool_type structures are replaced with
drm_page_pool pointers, and since the drm_page_pool logic has
its own shrinker, we can remove all of the ttm_pool shrinker
logic.

NOTE: There is one mismatch in the interfaces I'm not totally
happy with. The ttm_pool tracks all of its pooled pages across
a number of different pools, and tries to keep this size under
the specified page_pool_size value. With the drm_page_pool,
there may other users, however there is still one global
shrinker list of pools. So we can't easily reduce the ttm
pool under the ttm specified size without potentially doing
a lot of shrinking to other non-ttm pools. So either we can:
   1) Try to split it so each user of drm_page_pools manages its
  own pool shrinking.
   2) Push the max value into the drm_page_pool, and have it
  manage shrinking to fit under that global max. Then share
  those size/max values out so the ttm_pool debug output
  can have more context.

I've taken the second path in this patch set, but wanted to call
it out so folks could look closely.


Option 3: Move the debugging code into the drm_page_pool as well.

I strong think that will be a hard requirement from Daniel for 
upstreaming this.


Christian.



Thoughts would be greatly appreciated here!

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
  drivers/gpu/drm/Kconfig|   1 +
  drivers/gpu/drm/ttm/ttm_pool.c | 199 +++--
  include/drm/ttm/ttm_pool.h |  23 +---
  3 files changed, 41 insertions(+), 182 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index d16bf340ed2e..d427abefabfb 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -181,6 +181,7 @@ config DRM_PAGE_POOL
  config DRM_TTM
tristate
depends on DRM && MMU
+   select DRM_PAGE_POOL
help
  GPU memory management subsystem for devices with multiple
  GPU memory types. Will be enabled automatically if a device driver
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index eca36678f967..dbbaf55ca5df 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -37,6 +37,7 @@
  #ifdef CONFIG_X86
  #include 
  #endif
+#include 
  #include 
  #include 
  #include 
@@ -63,15 +64,13 @@ module_param(page_pool_size, ulong, 0644);
  
  static atomic_long_t allocated_pages;
  
-static struct ttm_pool_type global_write_combined[MAX_ORDER];

-static struct ttm_pool_type global_uncached[MAX_ORDER];
+static struct drm_page_pool *global_write_combined[MAX_ORDER];
+static struct drm_page_pool *global_uncached[MAX_ORDER];
  
-static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];

-static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
+static struct drm_page_pool *global_dma32_write_combined[MAX_ORDER];
+static struct drm_page_pool *global_dma32_uncached[MAX_ORDER];
  
  static struct mutex shrinker_lock;

-static struct list_head shrinker_list;
-static struct shrinker mm_shrinker;
  
  /* Allocate pages of size 1 << order with the given gfp_flags */

  static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t 
gfp_flags,
@@ -223,79 +222,26 @@ static void ttm_pool_unmap(struct ttm_pool *pool, 
dma_addr_t dma_addr,
   DMA_BIDIRECTIONAL);
  }
  
-/* Give pages into a specific pool_type */

-static void ttm_pool_type_give(struct ttm_pool_type *pt, struct page *p)
-{
-   spin_lock(&pt->lock);
-   list_add(&p->lru, &pt->pages);
-   spin_unlock(&pt->lock);
-   atomic_long_add(1 << pt->order, &allocated_pages);
-}
-
-/* Take pages from a specific pool_type, return NULL when nothing available */
-static struct page *ttm_pool_type_take(struct ttm_pool_type *pt)
-{
-   struct page *p;
-
-   spin_lock(&pt->lock);
-   p = list_first_entry_or_null(&pt->pages, typeof(*p), lru);
-   if (p) {
-   atomic_long_sub(1 << pt->order, &allocated_pages);
-   list_del(&p->lru);
-   }
-   spin_unlock(&pt->lock);
-
-   return p;
-}
-
-/* Initialize and add a pool type to the global shrinker list */
-static void ttm_pool_type_init(struct ttm_pool_type *pt, struct ttm_pool *pool,
-  enum ttm_caching caching, unsigned int order)
-{
-   pt->pool = pool;
-   pt->caching = caching;
-   pt->order = order;
-   spin_lock_init(&pt->lock);
-   INIT_LIST_HEAD(&pt->pages);
-
-   mutex_lock(&shrinker_lock);

Re: [PATCH v4] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip

[Huacai Chen]

Hi, Chenyang,

On Fri, Feb 5, 2021 at 4:33 PM Chenyang Li  wrote:
>
> This patch adds an initial DRM driver for the Loongson LS7A1000
> bridge chip(LS7A). The LS7A bridge chip contains two display
> controllers, support dual display output. The maximum support for
> each channel display is to 1920x1080@60Hz.
> At present, DC device detection and DRM driver registration are
> completed, the crtc/plane/encoder/connector objects has been
> implemented.
> On Loongson 3A4000 CPU and 7A1000 system, we have achieved the use
> of dual screen, and support dual screen clone mode and expansion
> mode.
>
> v4:
> - Move the mode_valid function to the crtc.
>
> v3:
> - Move the mode_valid function to the connector and optimize it.
> - Fix num_crtc calculation method.
>
> v2:
> - Complete the case of 32-bit color in CRTC.
>
> Signed-off-by: Chenyang Li 
> ---
>  drivers/gpu/drm/Kconfig   |   2 +
>  drivers/gpu/drm/Makefile  |   1 +
>  drivers/gpu/drm/loongson/Kconfig  |  14 +
>  drivers/gpu/drm/loongson/Makefile |  14 +
>  drivers/gpu/drm/loongson/loongson_connector.c |  48 
>  drivers/gpu/drm/loongson/loongson_crtc.c  | 241 
>  drivers/gpu/drm/loongson/loongson_device.c|  54 
>  drivers/gpu/drm/loongson/loongson_drv.c   | 269 ++
>  drivers/gpu/drm/loongson/loongson_drv.h   | 131 +
>  drivers/gpu/drm/loongson/loongson_encoder.c   |  37 +++
>  drivers/gpu/drm/loongson/loongson_plane.c | 102 +++
>  11 files changed, 913 insertions(+)
>  create mode 100644 drivers/gpu/drm/loongson/Kconfig
>  create mode 100644 drivers/gpu/drm/loongson/Makefile
>  create mode 100644 drivers/gpu/drm/loongson/loongson_connector.c
>  create mode 100644 drivers/gpu/drm/loongson/loongson_crtc.c
>  create mode 100644 drivers/gpu/drm/loongson/loongson_device.c
>  create mode 100644 drivers/gpu/drm/loongson/loongson_drv.c
>  create mode 100644 drivers/gpu/drm/loongson/loongson_drv.h
>  create mode 100644 drivers/gpu/drm/loongson/loongson_encoder.c
>  create mode 100644 drivers/gpu/drm/loongson/loongson_plane.c
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 0973f408d75f..6ed1b6dc2f25 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -374,6 +374,8 @@ source "drivers/gpu/drm/xen/Kconfig"
>
>  source "drivers/gpu/drm/vboxvideo/Kconfig"
>
> +source "drivers/gpu/drm/loongson/Kconfig"
> +
>  source "drivers/gpu/drm/lima/Kconfig"
>
>  source "drivers/gpu/drm/panfrost/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index fefaff4c832d..f87da730ea6d 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -119,6 +119,7 @@ obj-$(CONFIG_DRM_PL111) += pl111/
>  obj-$(CONFIG_DRM_TVE200) += tve200/
>  obj-$(CONFIG_DRM_XEN) += xen/
>  obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/
> +obj-$(CONFIG_DRM_LOONGSON) += loongson/
>  obj-$(CONFIG_DRM_LIMA)  += lima/
>  obj-$(CONFIG_DRM_PANFROST) += panfrost/
>  obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
> diff --git a/drivers/gpu/drm/loongson/Kconfig 
> b/drivers/gpu/drm/loongson/Kconfig
> new file mode 100644
> index ..43eb0c80cc12
> --- /dev/null
> +++ b/drivers/gpu/drm/loongson/Kconfig
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +config DRM_LOONGSON
> +   tristate "DRM support for LS7A1000 bridge chipset"
> +   depends on DRM && PCI
> +   depends on CPU_LOONGSON64
> +   select DRM_KMS_HELPER
> +   select DRM_VRAM_HELPER
> +   select DRM_TTM
> +   select DRM_TTM_HELPER
> +   default n
> +   help
> + Support the display controllers found on the Loongson LS7A1000
> + bridge.
You can use LS7A instead of LS7A1000.

> diff --git a/drivers/gpu/drm/loongson/Makefile 
> b/drivers/gpu/drm/loongson/Makefile
> new file mode 100644
> index ..22d063953b78
> --- /dev/null
> +++ b/drivers/gpu/drm/loongson/Makefile
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Makefile for loongson drm drivers.
> +# This driver provides support for the
> +# Direct Rendering Infrastructure (DRI)
> +
> +ccflags-y := -Iinclude/drm
> +loongson-y := loongson_drv.o \
> +   loongson_crtc.o \
> +   loongson_plane.o \
> +   loongson_device.o \
> +   loongson_connector.o \
> +   loongson_encoder.o
> +obj-$(CONFIG_DRM_LOONGSON) += loongson.o
> diff --git a/drivers/gpu/drm/loongson/loongson_connector.c 
> b/drivers/gpu/drm/loongson/loongson_connector.c
> new file mode 100644
> index ..6b1f0ffa33bd
> --- /dev/null
> +++ b/drivers/gpu/drm/loongson/loongson_connector.c
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include "loongson_drv.h"
> +
> +static int loongson_get_modes(struct drm_connector *connector)
> +{
> +   int count;
> +
> +   count = drm_add_modes_noedid(connector, 1920, 1080);
> +   drm_set_preferred_mode(connector, 1024, 768);
> +

Re: [PATCH] drm/komeda: Fix bit check to import to value of proper type

[James Qian Wang]

On Fri, Feb 05, 2021 at 08:29:32AM +, Steven Price wrote:
> +CC the other Komeda maintainers
> 
> On 04/02/2021 13:11, carsten.haitz...@foss.arm.com wrote:
> > From: Carsten Haitzler 
> > 
> > Another issue found by KASAN. The bit finding is buried inside the
> > dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
> > calls the bit stuff. These bit functions want an unsigned long pointer
> > as input and just dumbly casting leads to out-of-bounds accesses.
> > This fixes that.
> > 
> > Signed-off-by: Carsten Haitzler 
> 
> Looks fine to me:
> 
> Reviewed-by: Steven Price 
>

Thank you for the patch.

Reviewed-by: James Qian Wang 

> > ---
> >   .../drm/arm/display/include/malidp_utils.h|  3 ---
> >   .../drm/arm/display/komeda/komeda_pipeline.c  | 16 +++-
> >   .../display/komeda/komeda_pipeline_state.c| 19 +++
> >   3 files changed, 22 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/display/include/malidp_utils.h 
> > b/drivers/gpu/drm/arm/display/include/malidp_utils.h
> > index 3bc383d5bf73..49a1d7f3539c 100644
> > --- a/drivers/gpu/drm/arm/display/include/malidp_utils.h
> > +++ b/drivers/gpu/drm/arm/display/include/malidp_utils.h
> > @@ -13,9 +13,6 @@
> >   #define has_bit(nr, mask) (BIT(nr) & (mask))
> >   #define has_bits(bits, mask)  (((bits) & (mask)) == (bits))
> > -#define dp_for_each_set_bit(bit, mask) \
> > -   for_each_set_bit((bit), ((unsigned long *)&(mask)), sizeof(mask) * 8)
> > -
> >   #define dp_wait_cond(__cond, __tries, __min_range, __max_range)   \
> >   ({\
> > int num_tries = __tries;\
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c 
> > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
> > index 719a79728e24..06c595378dda 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
> > @@ -46,8 +46,9 @@ void komeda_pipeline_destroy(struct komeda_dev *mdev,
> >   {
> > struct komeda_component *c;
> > int i;
> > +   unsigned long avail_comps = pipe->avail_comps;
> > -   dp_for_each_set_bit(i, pipe->avail_comps) {
> > +   for_each_set_bit(i, &avail_comps, 32) {
> > c = komeda_pipeline_get_component(pipe, i);
> > komeda_component_destroy(mdev, c);
> > }
> > @@ -247,6 +248,7 @@ static void komeda_pipeline_dump(struct komeda_pipeline 
> > *pipe)
> >   {
> > struct komeda_component *c;
> > int id;
> > +   unsigned long avail_comps = pipe->avail_comps;
> > DRM_INFO("Pipeline-%d: n_layers: %d, n_scalers: %d, output: %s.\n",
> >  pipe->id, pipe->n_layers, pipe->n_scalers,
> > @@ -258,7 +260,7 @@ static void komeda_pipeline_dump(struct komeda_pipeline 
> > *pipe)
> >  pipe->of_output_links[1] ?
> >  pipe->of_output_links[1]->full_name : "none");
> > -   dp_for_each_set_bit(id, pipe->avail_comps) {
> > +   for_each_set_bit(id, &avail_comps, 32) {
> > c = komeda_pipeline_get_component(pipe, id);
> > komeda_component_dump(c);
> > @@ -270,8 +272,9 @@ static void komeda_component_verify_inputs(struct 
> > komeda_component *c)
> > struct komeda_pipeline *pipe = c->pipeline;
> > struct komeda_component *input;
> > int id;
> > +   unsigned long supported_inputs = c->supported_inputs;
> > -   dp_for_each_set_bit(id, c->supported_inputs) {
> > +   for_each_set_bit(id, &supported_inputs, 32) {
> > input = komeda_pipeline_get_component(pipe, id);
> > if (!input) {
> > c->supported_inputs &= ~(BIT(id));
> > @@ -302,8 +305,9 @@ static void komeda_pipeline_assemble(struct 
> > komeda_pipeline *pipe)
> > struct komeda_component *c;
> > struct komeda_layer *layer;
> > int i, id;
> > +   unsigned long avail_comps = pipe->avail_comps;
> > -   dp_for_each_set_bit(id, pipe->avail_comps) {
> > +   for_each_set_bit(id, &avail_comps, 32) {
> > c = komeda_pipeline_get_component(pipe, id);
> > komeda_component_verify_inputs(c);
> > }
> > @@ -355,13 +359,15 @@ void komeda_pipeline_dump_register(struct 
> > komeda_pipeline *pipe,
> >   {
> > struct komeda_component *c;
> > u32 id;
> > +   unsigned long avail_comps;
> > seq_printf(sf, "\n Pipeline-%d ==\n", pipe->id);
> > if (pipe->funcs && pipe->funcs->dump_register)
> > pipe->funcs->dump_register(pipe, sf);
> > -   dp_for_each_set_bit(id, pipe->avail_comps) {
> > +   avail_comps = pipe->avail_comps;
> > +   for_each_set_bit(id, &avail_comps, 32) {
> > c = komeda_pipeline_get_component(pipe, id);
> > seq_printf(sf, "\n--%s--\n", c->name);
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c 
> > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > index e8b1e15312d8..176cdf411f9f 100644
> > --- 

Re: [PATCH] drm/komeda: convert sysfs sprintf/snprintf family to sysfs_emit

[James Qian Wang]

On Thu, Feb 04, 2021 at 02:38:28PM +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warning:
> 
> ./drivers/gpu/drm/arm/display/komeda/komeda_dev.c:97:8-16: WARNING: use
> scnprintf or sprintf.
> 
> ./drivers/gpu/drm/arm/display/komeda/komeda_dev.c:88:8-16: WARNING: use
> scnprintf or sprintf.
> 
> ./drivers/gpu/drm/arm/display/komeda/komeda_dev.c:65:8-16: WARNING: use
> scnprintf or sprintf.
> 
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong 
> ---

Looks good to me, thank you for the patch.

Reviewed-by: James Qian Wang 

>  drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index ca891ae..cc7664c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@ -62,7 +62,7 @@ static void komeda_debugfs_init(struct komeda_dev *mdev)
>  {
>   struct komeda_dev *mdev = dev_to_mdev(dev);
>  
> - return snprintf(buf, PAGE_SIZE, "0x%08x\n", mdev->chip.core_id);
> + return sysfs_emit(buf, "0x%08x\n", mdev->chip.core_id);
>  }
>  static DEVICE_ATTR_RO(core_id);
>  
> @@ -85,7 +85,7 @@ static void komeda_debugfs_init(struct komeda_dev *mdev)
>   if (pipe->layers[i]->layer_type == KOMEDA_FMT_RICH_LAYER)
>   config_id.n_richs++;
>   }
> - return snprintf(buf, PAGE_SIZE, "0x%08x\n", config_id.value);
> + return sysfs_emit(buf, "0x%08x\n", config_id.value);
>  }
>  static DEVICE_ATTR_RO(config_id);
>  
> @@ -94,7 +94,7 @@ static void komeda_debugfs_init(struct komeda_dev *mdev)
>  {
>   struct komeda_dev *mdev = dev_to_mdev(dev);
>  
> - return snprintf(buf, PAGE_SIZE, "%lu\n", clk_get_rate(mdev->aclk));
> + return sysfs_emit(buf, "%lu\n", clk_get_rate(mdev->aclk));
>  }
>  static DEVICE_ATTR_RO(aclk_hz);
>  
> -- 
> 1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] drm: Move vmap out of commit tail for SHMEM-based drivers

[Gerd Hoffmann]

  Hi,

> I smoke-tested the code by running fbdev, Xorg and weston with the
> converted mgag200 driver.

Looks sane to me.
Survived cirrus smoke test too.

Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 

take care,
  Gerd

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drivers: gpu: drm: msn: disp: dpu1: Fixed couple of spellings in the file dpu_hw_top.h

[Bhaskar Chowdhury]

s/confguration/configuration/
s/Regsiters/Registers/

Signed-off-by: Bhaskar Chowdhury 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h
index 8018fff5667a..3aa10c89ca1b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h
@@ -30,7 +30,7 @@ struct traffic_shaper_cfg {

 /**
  * struct split_pipe_cfg - pipe configuration for dual display panels
- * @en: Enable/disable dual pipe confguration
+ * @en: Enable/disable dual pipe configuration
  * @mode  : Panel interface mode
  * @intf  : Interface id for main control path
  * @split_flush_en: Allows both the paths to be flushed when master path is
@@ -76,7 +76,7 @@ struct dpu_vsync_source_cfg {
  * @setup_traffic_shaper : programs traffic shaper control
  */
 struct dpu_hw_mdp_ops {
-   /** setup_split_pipe() : Regsiters are not double buffered, thisk
+   /** setup_split_pipe() : Registers are not double buffered, thisk
 * function should be called before timing control enable
 * @mdp  : mdp top context driver
 * @cfg  : upper and lower part of pipe configuration
--
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/panel: simple: add SGD GKTW70SDAD1SD

[Marco Felsch]

On 21-02-04 19:15, Oliver Graute wrote:
> On 02/02/21, Marco Felsch wrote:
> > Hi Oliver,
> > 
> > On 21-02-02 18:35, Oliver Graute wrote:
> > > Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD
> > > to panel-simple.
> > > 
> > > The panel spec from Variscite can be found at:
> > > https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf
> > > 
> > > Signed-off-by: Oliver Graute 
> > > Cc: Marco Felsch 
> > > Cc: Fabio Estevam 
> > > ---
> > > 
> > > v3:
> > > 
> > > - added flags
> > > - added delay
> > 
> > Thanks, did you test the changes?
> > I just picked it from the datasheet.
> 
> yes, it didn't break anything. 

Feel free to add my:

Reviewed-by: Marco Felsch 

PS:
+1 for Fabio's comment ^^

Regards,
  Marco

> 
> Best regards,
> 
> Oliver
> 

-- 
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- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap

[Daniel Vetter]

On Thu, Feb 4, 2021 at 9:59 PM Jason Gunthorpe  wrote:
>
> On Thu, Feb 04, 2021 at 09:19:57PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 4, 2021 at 9:09 PM Jason Gunthorpe  wrote:
> > >
> > > On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote:
> > >
> > > > So I think just checking for VM_PFNMAP after the vma is set up should
> > > > be enough to guarantee we'll only have pte_special ptes in there,
> > > > ever. But I'm not sure, this stuff all isn't really documented much
> > > > and the code is sometimes a maze (to me at least).
> > >
> > > Yes, that makes sense. VM_PFNMAP and !VM_MIXEDMAP seems like the right
> > > check after the VMA is populated
> > >
> > > But how do you stuff special pfns into a VMA outside the fault
> > > handler?
> >
> > Many drivers we have don't have dynamic buffer management (kinda
> > overkill for a few framebuffers on a display-only IP block), so the
> > just remap_pfn_range on ->mmap, and don't have a fault handler at all.
>
> remap_pfn_range() makes sense, do you expect drivers using struct page
> backed memory to call that as well?

All the ones using CMA through dma_alloc_coherent end up in there with
the dma_mmap_wc function. So yeah we have tons already.

The drivers with dynamic memory management all use vm_insert_pfn, even
when the buffer is in system memory and struct page backed. I think
those are the two cases. There's another mmap in drm/i915, but that
should never leave intel-specific userspace, and I think we're also
phasing it out somewhat. Either way, should never show up in a shared
buffer usecase, ever, so I think we can ignore it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] PCI: also set up legacy files only after sysfs init

[Daniel Vetter]

On Thu, Feb 4, 2021 at 10:50 PM Bjorn Helgaas  wrote:
>
> [+cc Oliver, Pali, Krzysztof]
>
> s/also/Also/ in subject
>
> On Thu, Feb 04, 2021 at 05:58:30PM +0100, Daniel Vetter wrote:
> > We are already doing this for all the regular sysfs files on PCI
> > devices, but not yet on the legacy io files on the PCI buses. Thus far
> > now problem, but in the next patch I want to wire up iomem revoke
> > support. That needs the vfs up an running already to make so that
> > iomem_get_mapping() works.
>
> s/now problem/no problem/
> s/an running/and running/
> s/so that/sure that/ ?
>
> iomem_get_mapping() doesn't exist; I don't know what that should be.

Series is based on top of linux-next, where iomem_get_mapping exists.
This patch fixes the 2nd patch in this series, which I had to take out
of my branch because it failed.

> > Wire it up exactly like the existing code. Note that
> > pci_remove_legacy_files() doesn't need a check since the one for
> > pci_bus->legacy_io is sufficient.
>
> I'm not sure exactly what you mean by "the existing code."  I could
> probably figure it out, but it would save time to mention the existing
> function here.

Sorry, I meant the existing code in pci_create_sysfs_dev_files().

> This looks like another instance where we should really apply Oliver's
> idea of converting these to attribute_groups [1].
>
> The cover letter mentions options discussed with Greg in [2], but I
> don't think the "sysfs_initialized" hack vs attribute_groups was part
> of that discussion.

Hm not sure the attribute_groups works. The problem is that I cant set
up the attributes before the vfs layer is initialized, because before
that point the iomem_get_mapping function doesn't return anything
useful (well it crashes), because it needs to have an inode available.

So if you want to set up the attributes earlier, we'd need some kind
of callback, which Greg didn't like.

> It's not absolutely a show-stopper, but it *is* a shame to extend the
> sysfs_initialized hack if attribute_groups could do this more cleanly
> and help solve more than one issue.

So I think I have yet another init ordering problem here, but not sure.
-Daniel

>
> Bjorn
>
> [1] 
> https://lore.kernel.org/r/caosf1chss03dbsdo4pmttmp0tceu5kscn704zewlkgxqzbf...@mail.gmail.com
> [2] 
> https://lore.kernel.org/dri-devel/cakmk7ugrddrbtj0oyzqqc0cgrqwc2f3tfju9vlfm2jjufaz...@mail.gmail.com/
>
> > Signed-off-by: Daniel Vetter 
> > Cc: Stephen Rothwell 
> > Cc: Jason Gunthorpe 
> > Cc: Kees Cook 
> > Cc: Dan Williams 
> > Cc: Andrew Morton 
> > Cc: John Hubbard 
> > Cc: Jérôme Glisse 
> > Cc: Jan Kara 
> > Cc: Dan Williams 
> > Cc: Greg Kroah-Hartman 
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Bjorn Helgaas 
> > Cc: linux-...@vger.kernel.org
> > ---
> >  drivers/pci/pci-sysfs.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > index fb072f4b3176..0c45b4f7b214 100644
> > --- a/drivers/pci/pci-sysfs.c
> > +++ b/drivers/pci/pci-sysfs.c
> > @@ -927,6 +927,9 @@ void pci_create_legacy_files(struct pci_bus *b)
> >  {
> >   int error;
> >
> > + if (!sysfs_initialized)
> > + return;
> > +
> >   b->legacy_io = kcalloc(2, sizeof(struct bin_attribute),
> >  GFP_ATOMIC);
> >   if (!b->legacy_io)
> > @@ -1448,6 +1451,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
> >  static int __init pci_sysfs_init(void)
> >  {
> >   struct pci_dev *pdev = NULL;
> > + struct pci_bus *pbus = NULL;
> >   int retval;
> >
> >   sysfs_initialized = 1;
> > @@ -1459,6 +1463,9 @@ static int __init pci_sysfs_init(void)
> >   }
> >   }
> >
> > + while ((pbus = pci_find_next_bus(pbus)))
> > + pci_create_legacy_files(pbus);
> > +
> >   return 0;
> >  }
> >  late_initcall(pci_sysfs_init);
> > --
> > 2.30.0
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] staging: fbtft replaced udelay with usleep_range

[Mayank Suman]

According to Documentation/timers/timers-howto.rst, usleep_range is
preffered over udelay for >=10us delay.

Signed-off-by: Mayank Suman 
---
 drivers/staging/fbtft/fb_agm1264k-fl.c |  2 +-
 drivers/staging/fbtft/fb_ra8875.c  |  4 ++--
 drivers/staging/fbtft/fb_tinylcd.c |  4 ++--
 drivers/staging/fbtft/fb_upd161704.c   | 18 +-
 drivers/staging/fbtft/fb_watterott.c   |  4 ++--
 5 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index ec97a..9ac523511 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par)
dev_dbg(par->info->device, "%s()\n", __func__);
 
gpiod_set_value(par->gpio.reset, 0);
-   udelay(20);
+   usleep_range(20);
gpiod_set_value(par->gpio.reset, 1);
mdelay(120);
 }
diff --git a/drivers/staging/fbtft/fb_ra8875.c 
b/drivers/staging/fbtft/fb_ra8875.c
index 398bdbf53..61d58efab 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -217,7 +217,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, 
...)
}
len--;
 
-   udelay(100);
+   usleep_range(100);
 
if (len) {
buf = (u8 *)par->buf;
@@ -238,7 +238,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, 
...)
 
/* restore user spi-speed */
par->fbtftops.write = fbtft_write_spi;
-   udelay(100);
+   usleep_range(100);
 }
 
 static int write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
diff --git a/drivers/staging/fbtft/fb_tinylcd.c 
b/drivers/staging/fbtft/fb_tinylcd.c
index 9469248f2..fffd39d96 100644
--- a/drivers/staging/fbtft/fb_tinylcd.c
+++ b/drivers/staging/fbtft/fb_tinylcd.c
@@ -38,10 +38,10 @@ static int init_display(struct fbtft_par *par)
write_reg(par, 0xE5, 0x00);
write_reg(par, 0xF0, 0x36, 0xA5, 0x53);
write_reg(par, 0xE0, 0x00, 0x35, 0x33, 0x00, 0x00, 0x00,
-  0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
+   0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
-   udelay(250);
+   usleep_range(250);
write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
 
return 0;
diff --git a/drivers/staging/fbtft/fb_upd161704.c 
b/drivers/staging/fbtft/fb_upd161704.c
index c77832ae5..bdcfda868 100644
--- a/drivers/staging/fbtft/fb_upd161704.c
+++ b/drivers/staging/fbtft/fb_upd161704.c
@@ -36,27 +36,27 @@ static int init_display(struct fbtft_par *par)
 
/* oscillator start */
write_reg(par, 0x003A, 0x0001); /*Oscillator 0: stop, 1: operation */
-   udelay(100);
+   usleep_range(100);
 
/* y-setting */
write_reg(par, 0x0024, 0x007B); /* amplitude setting */
-   udelay(10);
+   usleep_range(10);
write_reg(par, 0x0025, 0x003B); /* amplitude setting */
write_reg(par, 0x0026, 0x0034); /* amplitude setting */
-   udelay(10);
+   usleep_range(10);
write_reg(par, 0x0027, 0x0004); /* amplitude setting */
write_reg(par, 0x0052, 0x0025); /* circuit setting 1 */
-   udelay(10);
+   usleep_range(10);
write_reg(par, 0x0053, 0x0033); /* circuit setting 2 */
write_reg(par, 0x0061, 0x001C); /* adjustment V10 positive polarity */
-   udelay(10);
+   usleep_range(10);
write_reg(par, 0x0062, 0x002C); /* adjustment V9 negative polarity */
write_reg(par, 0x0063, 0x0022); /* adjustment V34 positive polarity */
-   udelay(10);
+   usleep_range(10);
write_reg(par, 0x0064, 0x0027); /* adjustment V31 negative polarity */
-   udelay(10);
+   usleep_range(10);
write_reg(par, 0x0065, 0x0014); /* adjustment V61 negative polarity */
-   udelay(10);
+   usleep_range(10);
write_reg(par, 0x0066, 0x0010); /* adjustment V61 negative polarity */
 
/* Basical clock for 1 line (BASECOUNT[7:0]) number specified */
@@ -64,7 +64,7 @@ static int init_display(struct fbtft_par *par)
 
/* Power supply setting */
write_reg(par, 0x0019, 0x); /* DC/DC output setting */
-   udelay(200);
+   usleep_range(200);
write_reg(par, 0x001A, 0x1000); /* DC/DC frequency setting */
write_reg(par, 0x001B, 0x0023); /* DC/DC rising setting */
write_reg(par, 0x001C, 0x0C01); /* Regulator voltage setting */
diff --git a/drivers/staging/fbtft/fb_watterott.c 
b/drivers/staging/fbtft/fb_watterott.c
index 76b25df37..580d5329e 100644
--- a/drivers/staging/fbtft/fb_watterott.c
+++ b/drivers/staging/fbtft/fb_watterott.c
@@ -84,7 +84,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
par->txbuf.buf, 10 + par->info->fix.line_length);
if (ret < 0)
   

Re: [pull] amdgpu, amdkfd drm-next-5.12

[Daniel Vetter]

On Fri, Feb 5, 2021 at 5:33 AM Alex Deucher  wrote:
>
> On Thu, Feb 4, 2021 at 6:52 PM Dave Airlie  wrote:
> >
> > On Thu, 4 Feb 2021 at 14:57, Alex Deucher  wrote:
> > >
> > > Hi Dave, Daniel,
> > >
> > > More fixes for 5.12.  Same PR from last week with the issue Felix reported
> > > fixed and a few more additional fixes on top.
> > >
> > > The following changes since commit 
> > > a6b8720c2f85143561c3453e1cf928a2f8586ac0:
> > >
> > >   Merge tag 'amd-drm-next-5.12-2021-01-20' of 
> > > https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-01-20 
> > > 13:08:18 +0100)
> > >
> > This brought an arm32 warning with it, I've applied Arnd's patch to
> > drm-next to fix it.
> >
> > https://patchwork.freedesktop.org/patch/msgid/20210125124849.102037-1-a...@kernel.org
> >
> > However that function has an ifdef around an ifdef that probably could
> > do with cleaning up.
>
> Sorry about that.  Bhawan fixed that up at the time:
> https://patchwork.freedesktop.org/patch/415092/
> Daniel said he picked that up last week:
> https://lists.freedesktop.org/archives/dri-devel/2021-January/294941.html
> but I guess it never landed, otherwise I would have included it in my PR.

Oops sorry, I somehow failed to push that one out :-/

I kinda liked the patch from Bhawan more, since less #ifdef.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging: fbtft replaced udelay with usleep_range

[Greg KH]

On Fri, Feb 05, 2021 at 02:41:13PM +0530, Mayank Suman wrote:
> According to Documentation/timers/timers-howto.rst, usleep_range is
> preffered over udelay for >=10us delay.
> 
> Signed-off-by: Mayank Suman 

ALWAYS test build your patches before sending them out to the world for
review.  You don't want to make maintainers grumpy by breaking the tree
with changes that can not compile, right?  :)

thanks,

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] immutable branch for amba changes targeting v5.12-rc1

[Uwe Kleine-König]

Hello Russell, hello Greg,

On Thu, Feb 04, 2021 at 07:15:51PM +0100, Uwe Kleine-König wrote:
> On Thu, Feb 04, 2021 at 04:59:51PM +, Russell King - ARM Linux admin 
> wrote:
> > On Thu, Feb 04, 2021 at 05:56:50PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Feb 04, 2021 at 04:52:24PM +, Russell King - ARM Linux admin 
> > > wrote:
> > > > On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg Kroah-Hartman wrote:
> > > > > I'm glad to take this through my char/misc tree, as that's where the
> > > > > other coresight changes flow through.  So if no one else objects, I 
> > > > > will
> > > > > do so...
> > > > 
> > > > Greg, did you end up pulling this after all? If not, Uwe produced a v2.
> > > > I haven't merged v2 yet as I don't know what you've done.
> > > 
> > > I thought you merged this?
> > 
> > I took v1, and put it in a branch I've promised in the past not to
> > rebase/rewind. Uwe is now asking for me to take a v2 or apply a patch
> > on top.
> > 
> > The only reason to produce an "immutable" branch is if it's the basis
> > for some dependent work and you need that branch merged into other
> > people's trees... so the whole "lets produce a v2" is really odd
> > workflow... I'm confused about what I should do, and who has to be
> > informed which option I take.
> > 
> > I'm rather lost here too.
> 
> Sorry to have cause this confusion. After I saw that my initial tag
> missed to adapt a driver I wanted to make it easy for you to fix the
> situation.
> So I created a patch to fix it and created a second tag with the patch
> squashed in. Obviously only one of them have to be picked and I hoped
> you (= Russell + Greg) would agree which option to pick.
> 
> My preference would be if you both pick up v2 of the tag to yield a
> history that is bisectable without build problems, but if Russell (who
> already picked up the broken tag) considers his tree immutable and so
> isn't willing to rebase, then picking up the patch is the way to go.

OK, the current state is that Russell applied the patch fixing
drivers/mailbox/arm_mhuv2.c on top of merging my first tag.

So the way forward now is that Greg pulls

git://git.armlinux.org.uk/~rmk/linux-arm.git devel-stable

which currently points to 

860660fd829e ("ARM: 9055/1: mailbox: arm_mhuv2: make remove callback 
return void")

, into his tree that contains the hwtracing changes that conflict with my
changes. @Greg: Is this good enough, or do you require a dedicated tag
to pull that?

I think these conflicting hwtracing changes are not yet in any of Greg's
trees (at least they are not in next).

When I pull

https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git next

(currently pointing to 4e73ff249184 ("coresight: etm4x: Handle accesses
to TRCSTALLCTLR")) into 860660fd829e, I get a conflict in
drivers/hwtracing/coresight/coresight-etm4x-core.c as expected. My
resolution looks as follows:

diff --cc drivers/hwtracing/coresight/coresight-etm4x-core.c
index 82787cba537d,5017d33ba4f5..
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@@ -1703,6 -1906,28 +1906,27 @@@ static int __exit etm4_remove_dev(struc
cpus_read_unlock();
  
coresight_unregister(drvdata->csdev);
+ 
+   return 0;
+ }
+ 
 -static int __exit etm4_remove_amba(struct amba_device *adev)
++static void __exit etm4_remove_amba(struct amba_device *adev)
+ {
+   struct etmv4_drvdata *drvdata = dev_get_drvdata(&adev->dev);
+ 
+   if (drvdata)
 -  return etm4_remove_dev(drvdata);
 -  return 0;
++  etm4_remove_dev(drvdata);
+ }
+ 
+ static int __exit etm4_remove_platform_dev(struct platform_device *pdev)
+ {
+   int ret = 0;
+   struct etmv4_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
+ 
+   if (drvdata)
+   ret = etm4_remove_dev(drvdata);
+   pm_runtime_disable(&pdev->dev);
+   return ret;
  }
  
  static const struct amba_id etm4_ids[] = {

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: anx7625: enable DSI EOTP

[Robert Foss]

On Thu, 4 Feb 2021 at 23:25, Nicolas Boichat  wrote:
>
> On Thu, Feb 4, 2021 at 8:59 PM Andrzej Hajda  wrote:
> >
> >
> > W dniu 04.02.2021 o 13:34, Nicolas Boichat pisze:
> > > On Thu, Feb 4, 2021 at 8:07 PM Robert Foss  wrote:
> > >> Hi Xin,
> > >>
> > >> Thanks for the patch.
> > >>
> > >> On Thu, 28 Jan 2021 at 12:17, Xin Ji  wrote:
> > >>> Enable DSI EOTP feature for fixing some panel screen constance
> > >>> shift issue.
> > >>> Removing MIPI flag MIPI_DSI_MODE_EOT_PACKET to enable DSI EOTP.

Does "constance shift" have a typo? Should it be "constant shift"?

With that sorted out feel free to add my r-b.
Reviewed-by: Robert Foss 

> > >> I don't think I quite understand how removing the
> > >> MIPI_DSI_MODE_EOT_PACKET flag will cause DSI EOTP to be enabled. Could
> > >> you extrapolate on this in the commit message?
> > > That confused me as well, but it turns out that's how the flag is defined:
> > > ```
> > > /* disable EoT packets in HS mode */
> > > #define MIPI_DSI_MODE_EOT_PACKET BIT(9)
> > > ```
> > > (https://protect2.fireeye.com/v1/url?k=5bd95ebd-044267fb-5bd8d5f2-0cc47a3003e8-ce9db8ea264d6901&q=1&e=900556dc-d199-4c18-9432-5c3465a98eae&u=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Finclude%2Fdrm%2Fdrm_mipi_dsi.h%23L129)
> > >
> > > I'm almost tempted to put together a mass patch to rename all of these 
> > > flags...
> >
> >
> > Yes that would be good, many of these flags were just copy pasted from
> > some hw datasheet, without good analysis how to adapt them to the framework.
>
> I'll look into it (but that shouldn't block this patch).

Thanks for clearing this up Nicolas & Andrzej!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances

[Christian König]

Alex how do we want to merge this?

I've just pushed the first patch to drm-misc-next since that needed a 
rebase because it touches other drivers as well.


But the rest is really AMD specific and I'm not sure if the dependent 
stuff is already in there as well.


So if I push it to drm-misc-next you will probably need to merge and if 
I push it to amd-staging-drm-next somebody else might need to merge when 
drm-misc-next is merged.


Ideas?

Christian.

Am 04.02.21 um 19:34 schrieb Leo Liu:

The series are:

Reviewed-and-Tested-by: Leo Liu 


On 2021-02-04 9:44 a.m., Christian König wrote:

The VCN3 instances can do both decode as well as encode.

Share the scheduler load balancing score and remove fixing encode to
only the second instance.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h |  1 +
  drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c   | 11 +++
  2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h

index 13aa417f6be7..d10bc4f0a05f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -211,6 +211,7 @@ struct amdgpu_vcn_inst {
  void    *saved_bo;
  struct amdgpu_ring    ring_dec;
  struct amdgpu_ring    ring_enc[AMDGPU_VCN_MAX_ENC_RINGS];
+    atomic_t    sched_score;
  struct amdgpu_irq_src    irq;
  struct amdgpu_vcn_reg    external;
  struct amdgpu_bo    *dpg_sram_bo;
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c

index 239a4eb52c61..b33f513fd2ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
@@ -171,6 +171,7 @@ static int vcn_v3_0_sw_init(void *handle)
    for (i = 0; i < adev->vcn.num_vcn_inst; i++) {
  volatile struct amdgpu_fw_shared *fw_shared;
+
  if (adev->vcn.harvest_config & (1 << i))
  continue;
  @@ -198,6 +199,8 @@ static int vcn_v3_0_sw_init(void *handle)
  if (r)
  return r;
  +    atomic_set(&adev->vcn.inst[i].sched_score, 0);
+
  ring = &adev->vcn.inst[i].ring_dec;
  ring->use_doorbell = true;
  if (amdgpu_sriov_vf(adev)) {
@@ -209,7 +212,8 @@ static int vcn_v3_0_sw_init(void *handle)
  ring->no_scheduler = true;
  sprintf(ring->name, "vcn_dec_%d", i);
  r = amdgpu_ring_init(adev, ring, 512, 
&adev->vcn.inst[i].irq, 0,

- AMDGPU_RING_PRIO_DEFAULT, NULL);
+ AMDGPU_RING_PRIO_DEFAULT,
+ &adev->vcn.inst[i].sched_score);
  if (r)
  return r;
  @@ -227,11 +231,10 @@ static int vcn_v3_0_sw_init(void *handle)
  } else {
  ring->doorbell_index = 
(adev->doorbell_index.vcn.vcn_ring0_1 << 1) + 2 + j + 8 * i;

  }
-    if (adev->asic_type == CHIP_SIENNA_CICHLID && i != 1)
-    ring->no_scheduler = true;
  sprintf(ring->name, "vcn_enc_%d.%d", i, j);
  r = amdgpu_ring_init(adev, ring, 512, 
&adev->vcn.inst[i].irq, 0,

- AMDGPU_RING_PRIO_DEFAULT, NULL);
+ AMDGPU_RING_PRIO_DEFAULT,
+ &adev->vcn.inst[i].sched_score);
  if (r)
  return r;
  }


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] drm: Move vmap out of commit tail for SHMEM-based drivers

[Thomas Zimmermann]

Hi

Am 05.02.21 um 10:05 schrieb Gerd Hoffmann:

   Hi,


I smoke-tested the code by running fbdev, Xorg and weston with the
converted mgag200 driver.


Looks sane to me.
Survived cirrus smoke test too.

Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 


Thanks a lot! I have on small change to the simple-kms interface for v2. 
But it doesn't make a difference overall.


Best regards
Thomas



take care,
   Gerd



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] immutable branch for amba changes targeting v5.12-rc1

[Greg Kroah-Hartman]

On Fri, Feb 05, 2021 at 10:37:44AM +0100, Uwe Kleine-König wrote:
> Hello Russell, hello Greg,
> 
> On Thu, Feb 04, 2021 at 07:15:51PM +0100, Uwe Kleine-König wrote:
> > On Thu, Feb 04, 2021 at 04:59:51PM +, Russell King - ARM Linux admin 
> > wrote:
> > > On Thu, Feb 04, 2021 at 05:56:50PM +0100, Greg Kroah-Hartman wrote:
> > > > On Thu, Feb 04, 2021 at 04:52:24PM +, Russell King - ARM Linux 
> > > > admin wrote:
> > > > > On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg Kroah-Hartman wrote:
> > > > > > I'm glad to take this through my char/misc tree, as that's where the
> > > > > > other coresight changes flow through.  So if no one else objects, I 
> > > > > > will
> > > > > > do so...
> > > > > 
> > > > > Greg, did you end up pulling this after all? If not, Uwe produced a 
> > > > > v2.
> > > > > I haven't merged v2 yet as I don't know what you've done.
> > > > 
> > > > I thought you merged this?
> > > 
> > > I took v1, and put it in a branch I've promised in the past not to
> > > rebase/rewind. Uwe is now asking for me to take a v2 or apply a patch
> > > on top.
> > > 
> > > The only reason to produce an "immutable" branch is if it's the basis
> > > for some dependent work and you need that branch merged into other
> > > people's trees... so the whole "lets produce a v2" is really odd
> > > workflow... I'm confused about what I should do, and who has to be
> > > informed which option I take.
> > > 
> > > I'm rather lost here too.
> > 
> > Sorry to have cause this confusion. After I saw that my initial tag
> > missed to adapt a driver I wanted to make it easy for you to fix the
> > situation.
> > So I created a patch to fix it and created a second tag with the patch
> > squashed in. Obviously only one of them have to be picked and I hoped
> > you (= Russell + Greg) would agree which option to pick.
> > 
> > My preference would be if you both pick up v2 of the tag to yield a
> > history that is bisectable without build problems, but if Russell (who
> > already picked up the broken tag) considers his tree immutable and so
> > isn't willing to rebase, then picking up the patch is the way to go.
> 
> OK, the current state is that Russell applied the patch fixing
> drivers/mailbox/arm_mhuv2.c on top of merging my first tag.
> 
> So the way forward now is that Greg pulls
> 
>   git://git.armlinux.org.uk/~rmk/linux-arm.git devel-stable
> 
> which currently points to 
> 
>   860660fd829e ("ARM: 9055/1: mailbox: arm_mhuv2: make remove callback 
> return void")
> 
> , into his tree that contains the hwtracing changes that conflict with my
> changes. @Greg: Is this good enough, or do you require a dedicated tag
> to pull that?
> 
> I think these conflicting hwtracing changes are not yet in any of Greg's
> trees (at least they are not in next).
> 
> When I pull
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git next
> 
> (currently pointing to 4e73ff249184 ("coresight: etm4x: Handle accesses
> to TRCSTALLCTLR")) into 860660fd829e, I get a conflict in
> drivers/hwtracing/coresight/coresight-etm4x-core.c as expected. My
> resolution looks as follows:

Ok, my resolution looked a bit different.

Can you pull my char-misc-testing branch and verify I got this all
pulled in correctly?

thanks,

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH v6 0/7] Generic page pool & deferred freeing for system dmabuf heap

[Christian König]

Am 05.02.21 um 09:06 schrieb John Stultz:

This series is starting to get long, so I figured I'd add a
short cover letter for context.

The point of this series is trying to add both deferred-freeing
logic as well as a page pool to the DMA-BUF system heap.

This is desired, as the combination of deferred freeing along
with the page pool allows us to offload page-zeroing out of
the allocation hot path. This was done originally with ION
and this patch series allows the DMA-BUF system heap to match
ION's system heap allocation performance in a simple
microbenchmark [1] (ION re-added to the kernel for comparision,
running on an x86 vm image):

./dmabuf-heap-bench -i 0 1 system
Testing dmabuf system vs ion heaptype 0 (flags: 0x1)
-
dmabuf heap: alloc 4096 bytes 5000 times in 86572223 ns  17314 ns/call
ion heap:alloc 4096 bytes 5000 times in 97442526 ns  19488 ns/call
dmabuf heap: alloc 1048576 bytes 5000 times in 196635057 ns  39327 ns/call
ion heap:alloc 1048576 bytes 5000 times in 357323629 ns  71464 ns/call
dmabuf heap: alloc 8388608 bytes 5000 times in 3165445534 ns 633089 ns/call
ion heap:alloc 8388608 bytes 5000 times in 3699591271 ns 739918 ns/call
dmabuf heap: alloc 33554432 bytes 5000 times in 13327402517 ns   2665480 ns/call
ion heap:alloc 33554432 bytes 5000 times in 15292352796 ns   3058470 ns/call

Daniel didn't like earlier attempts to re-use the network
page-pool code to achieve this, and suggested the ttm_pool be
used instead. This required pulling the fairly tightly knit
ttm_pool logic apart, but after many failed attmempts I think
I found a workable abstraction to split out shared logic.

So this series contains a new generic drm_page_pool helper
library, converts the ttm_pool to use it, and then adds the
dmabuf deferred freeing and adds support to the dmabuf system
heap to use both deferred freeing and the new drm_page_pool.

Input would be greatly appreciated. Testing as well, as I don't
have any development hardware that utilizes the ttm pool.


We can easily do the testing and the general idea sounds solid to me.

I see three major things we need to clean up here.
1. The licensing, you are moving from BSD/MIT to GPL2.
2. Don't add any new overhead to the TTM pool, especially allocating a 
private object per page is a no-go.

3. What are you doing with the reclaim stuff and why?
4. Keeping the documentation would be nice to have.

Regards,
Christian.



thanks
-john

[1] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fsystem%2Fmemory%2Flibdmabufheap%2F%2B%2Frefs%2Fheads%2Fmaster%2Ftests%2Fdmabuf_heap_bench.c&data=04%7C01%7Cchristian.koenig%40amd.com%7C2dc4d6cb3ee246558b9e08d8c9acef9a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637481091933715561%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oMgVsrdlwS%2BqZuuatjTiWDzMU9SiUW5eRar5xwT%2BHYQ%3D&reserved=0

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org

John Stultz (7):
   drm: Add a sharable drm page-pool implementation
   drm: ttm_pool: Rename the ttm_pool_dma structure to ttm_pool_page_dat
   drm: ttm_pool: Rework ttm_pool_free_page to allow us to use it as a
 function pointer
   drm: ttm_pool: Rework ttm_pool to use drm_page_pool
   dma-buf: heaps: Add deferred-free-helper library code
   dma-buf: system_heap: Add drm pagepool support to system heap
   dma-buf: system_heap: Add deferred freeing to the system heap

  drivers/dma-buf/heaps/Kconfig|   5 +
  drivers/dma-buf/heaps/Makefile   |   1 +
  drivers/dma-buf/heaps/deferred-free-helper.c | 145 ++
  drivers/dma-buf/heaps/deferred-free-helper.h |  55 
  drivers/dma-buf/heaps/system_heap.c  |  77 -
  drivers/gpu/drm/Kconfig  |   5 +
  drivers/gpu/drm/Makefile |   1 +
  drivers/gpu/drm/page_pool.c  | 220 +++
  drivers/gpu/drm/ttm/ttm_pool.c   | 278 ++-
  include/drm/page_pool.h  |  54 
  include/drm/ttm/ttm_pool.h   |  23 +-
  11 files changed, 639 insertions(+), 225 deletions(-)
  create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.c
  create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.h
  create mode 100644 drivers/gpu/drm/page_pool.c
  create mode 100644 include/drm/page_pool.h



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] immutable branch for amba changes targeting v5.12-rc1

[Uwe Kleine-König]

On Fri, Feb 05, 2021 at 11:18:17AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 05, 2021 at 10:37:44AM +0100, Uwe Kleine-König wrote:
> > Hello Russell, hello Greg,
> > 
> > On Thu, Feb 04, 2021 at 07:15:51PM +0100, Uwe Kleine-König wrote:
> > > On Thu, Feb 04, 2021 at 04:59:51PM +, Russell King - ARM Linux admin 
> > > wrote:
> > > > On Thu, Feb 04, 2021 at 05:56:50PM +0100, Greg Kroah-Hartman wrote:
> > > > > On Thu, Feb 04, 2021 at 04:52:24PM +, Russell King - ARM Linux 
> > > > > admin wrote:
> > > > > > On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg Kroah-Hartman wrote:
> > > > > > > I'm glad to take this through my char/misc tree, as that's where 
> > > > > > > the
> > > > > > > other coresight changes flow through.  So if no one else objects, 
> > > > > > > I will
> > > > > > > do so...
> > > > > > 
> > > > > > Greg, did you end up pulling this after all? If not, Uwe produced a 
> > > > > > v2.
> > > > > > I haven't merged v2 yet as I don't know what you've done.
> > > > > 
> > > > > I thought you merged this?
> > > > 
> > > > I took v1, and put it in a branch I've promised in the past not to
> > > > rebase/rewind. Uwe is now asking for me to take a v2 or apply a patch
> > > > on top.
> > > > 
> > > > The only reason to produce an "immutable" branch is if it's the basis
> > > > for some dependent work and you need that branch merged into other
> > > > people's trees... so the whole "lets produce a v2" is really odd
> > > > workflow... I'm confused about what I should do, and who has to be
> > > > informed which option I take.
> > > > 
> > > > I'm rather lost here too.
> > > 
> > > Sorry to have cause this confusion. After I saw that my initial tag
> > > missed to adapt a driver I wanted to make it easy for you to fix the
> > > situation.
> > > So I created a patch to fix it and created a second tag with the patch
> > > squashed in. Obviously only one of them have to be picked and I hoped
> > > you (= Russell + Greg) would agree which option to pick.
> > > 
> > > My preference would be if you both pick up v2 of the tag to yield a
> > > history that is bisectable without build problems, but if Russell (who
> > > already picked up the broken tag) considers his tree immutable and so
> > > isn't willing to rebase, then picking up the patch is the way to go.
> > 
> > OK, the current state is that Russell applied the patch fixing
> > drivers/mailbox/arm_mhuv2.c on top of merging my first tag.
> > 
> > So the way forward now is that Greg pulls
> > 
> > git://git.armlinux.org.uk/~rmk/linux-arm.git devel-stable
> > 
> > which currently points to 
> > 
> > 860660fd829e ("ARM: 9055/1: mailbox: arm_mhuv2: make remove callback 
> > return void")
> > 
> > , into his tree that contains the hwtracing changes that conflict with my
> > changes. @Greg: Is this good enough, or do you require a dedicated tag
> > to pull that?
> > 
> > I think these conflicting hwtracing changes are not yet in any of Greg's
> > trees (at least they are not in next).
> > 
> > When I pull
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git next
> > 
> > (currently pointing to 4e73ff249184 ("coresight: etm4x: Handle accesses
> > to TRCSTALLCTLR")) into 860660fd829e, I get a conflict in
> > drivers/hwtracing/coresight/coresight-etm4x-core.c as expected. My
> > resolution looks as follows:
> 
> Ok, my resolution looked a bit different.
> 
> Can you pull my char-misc-testing branch and verify I got this all
> pulled in correctly?

minor side-note: mentioning the repo url would have simplified that test.

I looked at

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 
char-misc-testing

commit 0573d3fa48640f0fa6b105ff92dcb02b94d6c1ab now.

I didn't compile test, but I'm willing to bet your resolution is wrong.
You have no return statement in etm4_remove_dev() but its return type is
int and etm4_remove_amba() still returns int but should return void.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] immutable branch for amba changes targeting v5.12-rc1

[Greg Kroah-Hartman]

On Fri, Feb 05, 2021 at 11:56:15AM +0100, Uwe Kleine-König wrote:
> On Fri, Feb 05, 2021 at 11:18:17AM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Feb 05, 2021 at 10:37:44AM +0100, Uwe Kleine-König wrote:
> > > Hello Russell, hello Greg,
> > > 
> > > On Thu, Feb 04, 2021 at 07:15:51PM +0100, Uwe Kleine-König wrote:
> > > > On Thu, Feb 04, 2021 at 04:59:51PM +, Russell King - ARM Linux 
> > > > admin wrote:
> > > > > On Thu, Feb 04, 2021 at 05:56:50PM +0100, Greg Kroah-Hartman wrote:
> > > > > > On Thu, Feb 04, 2021 at 04:52:24PM +, Russell King - ARM Linux 
> > > > > > admin wrote:
> > > > > > > On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg Kroah-Hartman 
> > > > > > > wrote:
> > > > > > > > I'm glad to take this through my char/misc tree, as that's 
> > > > > > > > where the
> > > > > > > > other coresight changes flow through.  So if no one else 
> > > > > > > > objects, I will
> > > > > > > > do so...
> > > > > > > 
> > > > > > > Greg, did you end up pulling this after all? If not, Uwe produced 
> > > > > > > a v2.
> > > > > > > I haven't merged v2 yet as I don't know what you've done.
> > > > > > 
> > > > > > I thought you merged this?
> > > > > 
> > > > > I took v1, and put it in a branch I've promised in the past not to
> > > > > rebase/rewind. Uwe is now asking for me to take a v2 or apply a patch
> > > > > on top.
> > > > > 
> > > > > The only reason to produce an "immutable" branch is if it's the basis
> > > > > for some dependent work and you need that branch merged into other
> > > > > people's trees... so the whole "lets produce a v2" is really odd
> > > > > workflow... I'm confused about what I should do, and who has to be
> > > > > informed which option I take.
> > > > > 
> > > > > I'm rather lost here too.
> > > > 
> > > > Sorry to have cause this confusion. After I saw that my initial tag
> > > > missed to adapt a driver I wanted to make it easy for you to fix the
> > > > situation.
> > > > So I created a patch to fix it and created a second tag with the patch
> > > > squashed in. Obviously only one of them have to be picked and I hoped
> > > > you (= Russell + Greg) would agree which option to pick.
> > > > 
> > > > My preference would be if you both pick up v2 of the tag to yield a
> > > > history that is bisectable without build problems, but if Russell (who
> > > > already picked up the broken tag) considers his tree immutable and so
> > > > isn't willing to rebase, then picking up the patch is the way to go.
> > > 
> > > OK, the current state is that Russell applied the patch fixing
> > > drivers/mailbox/arm_mhuv2.c on top of merging my first tag.
> > > 
> > > So the way forward now is that Greg pulls
> > > 
> > >   git://git.armlinux.org.uk/~rmk/linux-arm.git devel-stable
> > > 
> > > which currently points to 
> > > 
> > >   860660fd829e ("ARM: 9055/1: mailbox: arm_mhuv2: make remove callback 
> > > return void")
> > > 
> > > , into his tree that contains the hwtracing changes that conflict with my
> > > changes. @Greg: Is this good enough, or do you require a dedicated tag
> > > to pull that?
> > > 
> > > I think these conflicting hwtracing changes are not yet in any of Greg's
> > > trees (at least they are not in next).
> > > 
> > > When I pull
> > > 
> > >   https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git next
> > > 
> > > (currently pointing to 4e73ff249184 ("coresight: etm4x: Handle accesses
> > > to TRCSTALLCTLR")) into 860660fd829e, I get a conflict in
> > > drivers/hwtracing/coresight/coresight-etm4x-core.c as expected. My
> > > resolution looks as follows:
> > 
> > Ok, my resolution looked a bit different.
> > 
> > Can you pull my char-misc-testing branch and verify I got this all
> > pulled in correctly?
> 
> minor side-note: mentioning the repo url would have simplified that test.

Sorry, I thought you had it based on the above info.

> I looked at
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 
> char-misc-testing
> 
> commit 0573d3fa48640f0fa6b105ff92dcb02b94d6c1ab now.
> 
> I didn't compile test, but I'm willing to bet your resolution is wrong.
> You have no return statement in etm4_remove_dev() but its return type is
> int and etm4_remove_amba() still returns int but should return void.

Can you send a patch to fix this up?

thanks,

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: manual merge of the drivers-x86 tree with the drm-misc tree

[Andy Shevchenko]

On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko
 wrote:
>> Today's linux-next merge of the drivers-x86 tree got a conflict in:
>
> Thanks. I already asked Patrik yesterday day if DRM missed to pull an 
> immutable tag I provided. I think they can pull and resolve conflicts 
> themselves. Alternatively it would be easy to resolve by Linus by removing 
> Kconfig lines along with mentioned files,

Patrik, I have sent a PR again, so you may consider pulling it, thanks!

-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: manual merge of the drivers-x86 tree with the drm-misc tree

[Patrik Jakobsson]

On Fri, Feb 5, 2021 at 12:07 PM Andy Shevchenko
 wrote:
>
> On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko
>  wrote:
> >> Today's linux-next merge of the drivers-x86 tree got a conflict in:
> >
> > Thanks. I already asked Patrik yesterday day if DRM missed to pull an 
> > immutable tag I provided. I think they can pull and resolve conflicts 
> > themselves. Alternatively it would be easy to resolve by Linus by removing 
> > Kconfig lines along with mentioned files,
>
> Patrik, I have sent a PR again, so you may consider pulling it, thanks!

Daniel, is this something you can pull into drm or ask one of the
drm-misc maintainers to do?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/3] drm/panfrost: MMU fixes

[Boris Brezillon]

Hello,

Here are 2 fixes and one improvement for the page fault handling. Those
bugs were found while working on indirect draw supports which requires
the allocation of a big heap buffer for varyings, and the vertex/tiler
shaders seem to have access pattern that trigger those issues. I
remember discussing the first issue with Steve or Robin a while back,
but we never hit it before (now we do :)).

The last patch is a perf improvement: no need to re-enable hardware
interrupts if we know the threaded irq handler will be woken up right
away.

Regards,

Boris

Changes in v2:
* Rework the MMU irq handling loop to avoid a goto

Boris Brezillon (3):
  drm/panfrost: Clear MMU irqs before handling the fault
  drm/panfrost: Don't try to map pages that are already mapped
  drm/panfrost: Stay in the threaded MMU IRQ handler until we've handled
all IRQs

 drivers/gpu/drm/panfrost/panfrost_mmu.c | 39 +++--
 1 file changed, 24 insertions(+), 15 deletions(-)

-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/3] drm/panfrost: Clear MMU irqs before handling the fault

[Boris Brezillon]

When a fault is handled it will unblock the GPU which will continue
executing its shader and might fault almost immediately on a different
page. If we clear interrupts after handling the fault we might miss new
faults, so clear them before.

Cc: 
Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
Signed-off-by: Boris Brezillon 
Reviewed-by: Steven Price 
---
 drivers/gpu/drm/panfrost/panfrost_mmu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c 
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 7c1b3481b785..904d63450862 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -593,6 +593,8 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq, 
void *data)
access_type = (fault_status >> 8) & 0x3;
source_id = (fault_status >> 16);
 
+   mmu_write(pfdev, MMU_INT_CLEAR, mask);
+
/* Page fault only */
ret = -1;
if ((status & mask) == BIT(i) && (exception_type & 0xF8) == 
0xC0)
@@ -616,8 +618,6 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq, 
void *data)
access_type, access_type_name(pfdev, 
fault_status),
source_id);
 
-   mmu_write(pfdev, MMU_INT_CLEAR, mask);
-
status &= ~mask;
}
 
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/3] drm/panfrost: Stay in the threaded MMU IRQ handler until we've handled all IRQs

[Boris Brezillon]

Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
in the threaded irq handler as long as we can.

v2:
* Rework the loop to avoid a goto

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panfrost/panfrost_mmu.c | 26 +
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c 
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 21e552d1ac71..0581186ebfb3 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -578,22 +578,20 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int 
irq, void *data)
 {
struct panfrost_device *pfdev = data;
u32 status = mmu_read(pfdev, MMU_INT_RAWSTAT);
-   int i, ret;
+   int ret;
 
-   for (i = 0; status; i++) {
-   u32 mask = BIT(i) | BIT(i + 16);
+   while (status) {
+   u32 as = ffs(status | (status >> 16)) - 1;
+   u32 mask = BIT(as) | BIT(as + 16);
u64 addr;
u32 fault_status;
u32 exception_type;
u32 access_type;
u32 source_id;
 
-   if (!(status & mask))
-   continue;
-
-   fault_status = mmu_read(pfdev, AS_FAULTSTATUS(i));
-   addr = mmu_read(pfdev, AS_FAULTADDRESS_LO(i));
-   addr |= (u64)mmu_read(pfdev, AS_FAULTADDRESS_HI(i)) << 32;
+   fault_status = mmu_read(pfdev, AS_FAULTSTATUS(as));
+   addr = mmu_read(pfdev, AS_FAULTADDRESS_LO(as));
+   addr |= (u64)mmu_read(pfdev, AS_FAULTADDRESS_HI(as)) << 32;
 
/* decode the fault status */
exception_type = fault_status & 0xFF;
@@ -604,8 +602,8 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq, 
void *data)
 
/* Page fault only */
ret = -1;
-   if ((status & mask) == BIT(i) && (exception_type & 0xF8) == 
0xC0)
-   ret = panfrost_mmu_map_fault_addr(pfdev, i, addr);
+   if ((status & mask) == BIT(as) && (exception_type & 0xF8) == 
0xC0)
+   ret = panfrost_mmu_map_fault_addr(pfdev, as, addr);
 
if (ret)
/* terminal fault, print info about the fault */
@@ -617,7 +615,7 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq, 
void *data)
"exception type 0x%X: %s\n"
"access type 0x%X: %s\n"
"source id 0x%X\n",
-   i, addr,
+   as, addr,
"TODO",
fault_status,
(fault_status & (1 << 10) ? "DECODER FAULT" : 
"SLAVE FAULT"),
@@ -626,6 +624,10 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int 
irq, void *data)
source_id);
 
status &= ~mask;
+
+   /* If we received new MMU interrupts, process them before 
returning. */
+   if (!status)
+   status = mmu_read(pfdev, MMU_INT_RAWSTAT);
}
 
mmu_write(pfdev, MMU_INT_MASK, ~0);
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/3] drm/panfrost: Don't try to map pages that are already mapped

[Boris Brezillon]

We allocate 2MB chunks at a time, so it might appear that a page fault
has already been handled by a previous page fault when we reach
panfrost_mmu_map_fault_addr(). Bail out in that case to avoid mapping the
same area twice.

Cc: 
Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
Signed-off-by: Boris Brezillon 
Reviewed-by: Steven Price 
---
 drivers/gpu/drm/panfrost/panfrost_mmu.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c 
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 904d63450862..21e552d1ac71 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -488,8 +488,14 @@ static int panfrost_mmu_map_fault_addr(struct 
panfrost_device *pfdev, int as,
}
bo->base.pages = pages;
bo->base.pages_use_count = 1;
-   } else
+   } else {
pages = bo->base.pages;
+   if (pages[page_offset]) {
+   /* Pages are already mapped, bail out. */
+   mutex_unlock(&bo->base.pages_lock);
+   goto out;
+   }
+   }
 
mapping = bo->base.base.filp->f_mapping;
mapping_set_unevictable(mapping);
@@ -522,6 +528,7 @@ static int panfrost_mmu_map_fault_addr(struct 
panfrost_device *pfdev, int as,
 
dev_dbg(pfdev->dev, "mapped page fault @ AS%d %llx", as, addr);
 
+out:
panfrost_gem_mapping_put(bomapping);
 
return 0;
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging: fbtft replaced udelay with usleep_range

[kernel test robot]

Hi Mayank,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on staging/staging-testing]

url:
https://github.com/0day-ci/linux/commits/Mayank-Suman/staging-fbtft-replaced-udelay-with-usleep_range/20210205-171807
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
06b0c0dce88e2aa2f01343db0f26d214d7f264a0
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/4a777af1cc91dc603b6b92fe06fd94081dc2891e
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Mayank-Suman/staging-fbtft-replaced-udelay-with-usleep_range/20210205-171807
git checkout 4a777af1cc91dc603b6b92fe06fd94081dc2891e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=alpha 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   drivers/staging/fbtft/fb_agm1264k-fl.c: In function 'reset':
>> drivers/staging/fbtft/fb_agm1264k-fl.c:88:2: error: too few arguments to 
>> function 'usleep_range'
  88 |  usleep_range(20);
 |  ^~~~
   In file included from drivers/staging/fbtft/fb_agm1264k-fl.c:12:
   include/linux/delay.h:61:6: note: declared here
  61 | void usleep_range(unsigned long min, unsigned long max);
 |  ^~~~
--
   drivers/staging/fbtft/fb_ra8875.c: In function 'write_reg8_bus8':
>> drivers/staging/fbtft/fb_ra8875.c:220:2: error: too few arguments to 
>> function 'usleep_range'
 220 |  usleep_range(100);
 |  ^~~~
   In file included from drivers/staging/fbtft/fb_ra8875.c:10:
   include/linux/delay.h:61:6: note: declared here
  61 | void usleep_range(unsigned long min, unsigned long max);
 |  ^~~~
   drivers/staging/fbtft/fb_ra8875.c:241:2: error: too few arguments to 
function 'usleep_range'
 241 |  usleep_range(100);
 |  ^~~~
   In file included from drivers/staging/fbtft/fb_ra8875.c:10:
   include/linux/delay.h:61:6: note: declared here
  61 | void usleep_range(unsigned long min, unsigned long max);
 |  ^~~~
--
   drivers/staging/fbtft/fb_tinylcd.c: In function 'init_display':
>> drivers/staging/fbtft/fb_tinylcd.c:44:2: error: too few arguments to 
>> function 'usleep_range'
  44 |  usleep_range(250);
 |  ^~~~
   In file included from drivers/staging/fbtft/fb_tinylcd.c:11:
   include/linux/delay.h:61:6: note: declared here
  61 | void usleep_range(unsigned long min, unsigned long max);
 |  ^~~~
--
   drivers/staging/fbtft/fb_upd161704.c: In function 'init_display':
>> drivers/staging/fbtft/fb_upd161704.c:39:2: error: too few arguments to 
>> function 'usleep_range'
  39 |  usleep_range(100);
 |  ^~~~
   In file included from drivers/staging/fbtft/fb_upd161704.c:16:
   include/linux/delay.h:61:6: note: declared here
  61 | void usleep_range(unsigned long min, unsigned long max);
 |  ^~~~
   drivers/staging/fbtft/fb_upd161704.c:43:2: error: too few arguments to 
function 'usleep_range'
  43 |  usleep_range(10);
 |  ^~~~
   In file included from drivers/staging/fbtft/fb_upd161704.c:16:
   include/linux/delay.h:61:6: note: declared here
  61 | void usleep_range(unsigned long min, unsigned long max);
 |  ^~~~
   drivers/staging/fbtft/fb_upd161704.c:46:2: error: too few arguments to 
function 'usleep_range'
  46 |  usleep_range(10);
 |  ^~~~
   In file included from drivers/staging/fbtft/fb_upd161704.c:16:
   include/linux/delay.h:61:6: note: declared here
  61 | void usleep_range(unsigned long min, unsigned long max);
 |  ^~~~
   drivers/staging/fbtft/fb_upd161704.c:49:2: error: too few arguments to 
function 'usleep_range'
  49 |  usleep_range(10);
 |  ^~~~
   In file included from drivers/staging/fbtft/fb_upd161704.c:16:
   include/linux/delay.h:61:6: note: declared here
  61 | void usleep_range(unsigned long min, unsigned long max);
 |  ^~~~
   drivers/staging/fbtft/fb_upd161704.c:52:2: error: too few arguments to 
function 'usleep_range'
  52 |  usleep_range(10);
 |  ^~~~
   In file included from drivers/staging/fbtft/fb_upd161704.c:16:
   include/linux/delay.h:61:6: note: declared here
  61 | void usleep_range(unsigned long min, unsigned long max);

Re: [PATCH v2 3/3] drm/panfrost: Stay in the threaded MMU IRQ handler until we've handled all IRQs

[Steven Price]

On 05/02/2021 11:17, Boris Brezillon wrote:

Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay
in the threaded irq handler as long as we can.

v2:
* Rework the loop to avoid a goto

Signed-off-by: Boris Brezillon 


Reviewed-by: Steven Price 


---
  drivers/gpu/drm/panfrost/panfrost_mmu.c | 26 +
  1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c 
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 21e552d1ac71..0581186ebfb3 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -578,22 +578,20 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int 
irq, void *data)
  {
struct panfrost_device *pfdev = data;
u32 status = mmu_read(pfdev, MMU_INT_RAWSTAT);
-   int i, ret;
+   int ret;
  
-	for (i = 0; status; i++) {

-   u32 mask = BIT(i) | BIT(i + 16);
+   while (status) {
+   u32 as = ffs(status | (status >> 16)) - 1;
+   u32 mask = BIT(as) | BIT(as + 16);
u64 addr;
u32 fault_status;
u32 exception_type;
u32 access_type;
u32 source_id;
  
-		if (!(status & mask))

-   continue;
-
-   fault_status = mmu_read(pfdev, AS_FAULTSTATUS(i));
-   addr = mmu_read(pfdev, AS_FAULTADDRESS_LO(i));
-   addr |= (u64)mmu_read(pfdev, AS_FAULTADDRESS_HI(i)) << 32;
+   fault_status = mmu_read(pfdev, AS_FAULTSTATUS(as));
+   addr = mmu_read(pfdev, AS_FAULTADDRESS_LO(as));
+   addr |= (u64)mmu_read(pfdev, AS_FAULTADDRESS_HI(as)) << 32;
  
  		/* decode the fault status */

exception_type = fault_status & 0xFF;
@@ -604,8 +602,8 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq, 
void *data)
  
  		/* Page fault only */

ret = -1;
-   if ((status & mask) == BIT(i) && (exception_type & 0xF8) == 
0xC0)
-   ret = panfrost_mmu_map_fault_addr(pfdev, i, addr);
+   if ((status & mask) == BIT(as) && (exception_type & 0xF8) == 
0xC0)
+   ret = panfrost_mmu_map_fault_addr(pfdev, as, addr);
  
  		if (ret)

/* terminal fault, print info about the fault */
@@ -617,7 +615,7 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int irq, 
void *data)
"exception type 0x%X: %s\n"
"access type 0x%X: %s\n"
"source id 0x%X\n",
-   i, addr,
+   as, addr,
"TODO",
fault_status,
(fault_status & (1 << 10) ? "DECODER FAULT" : "SLAVE 
FAULT"),
@@ -626,6 +624,10 @@ static irqreturn_t panfrost_mmu_irq_handler_thread(int 
irq, void *data)
source_id);
  
  		status &= ~mask;

+
+   /* If we received new MMU interrupts, process them before 
returning. */
+   if (!status)
+   status = mmu_read(pfdev, MMU_INT_RAWSTAT);
}
  
  	mmu_write(pfdev, MMU_INT_MASK, ~0);




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/v3d: Add job timeout module param

[Yukimasa Sugizaki]

On 05/02/2021, Eric Anholt  wrote:
> On Thu, Feb 4, 2021 at 10:09 AM Chema Casanova 
> wrote:
>>
>> On 3/9/20 18:48, Yukimasa Sugizaki wrote:
>> > From: Yukimasa Sugizaki 
>> >
>> > The default timeout is 500 ms which is too short for some workloads
>> > including Piglit.  Adding this parameter will help users to run heavier
>> > tasks.
>> >
>> > Signed-off-by: Yukimasa Sugizaki 
>> > ---
>> >   drivers/gpu/drm/v3d/v3d_sched.c | 24 +---
>> >   1 file changed, 13 insertions(+), 11 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/v3d/v3d_sched.c
>> > b/drivers/gpu/drm/v3d/v3d_sched.c
>> > index feef0c749e68..983efb018560 100644
>> > --- a/drivers/gpu/drm/v3d/v3d_sched.c
>> > +++ b/drivers/gpu/drm/v3d/v3d_sched.c
>> > @@ -19,11 +19,17 @@
>> >*/
>> >
>> >   #include 
>> > +#include 
>> >
>> >   #include "v3d_drv.h"
>> >   #include "v3d_regs.h"
>> >   #include "v3d_trace.h"
>> >
>> > +static uint timeout = 500;
>> > +module_param(timeout, uint, 0444);
>> > +MODULE_PARM_DESC(timeout,
>> > + "Timeout for a job in ms (0 means infinity and default is 500
>> > ms)");
>> > +
>>
>> I think that  parameter definition could be included at v3d_drv.c as
>> other drivers do. Then we would have all future parameters together. In
>> that case we would need also to include the extern definition at
>> v3d_drv.h for the driver variable.
>>
>> The param name could be more descriptive like "sched_timeout_ms" in the
>> lima driver.
>>
>> I wonder if it would make sense to have different timeouts parameters
>> for different type of jobs we have. At least this series come from the
>> need additional time to complete compute jobs. This is what amdgpu does,
>> but we probably don't need something such complex.
>>
>> I think it would also make sense to increase our default value for the
>> compute jobs.
>>
>> What do you think?
>>
>> In any case I think that having this general scheduling timeout
>> parameter as other drivers do is a good idea.

I agree with your observations.
I'm going to add bin_timeout_ms, render_timeout_ms, tfu_timeout_ms,
v3d_timeout_ms, and cache_clean_timeout_ms parameters to v3d_drv.c
instead of the sole timeout parameter.
Though not sophisticated, this should be enough.

> Having a param for being able to test if the job completes eventually
> is a good idea, but if tests are triggering timeouts, then you
> probably need to investigate what's going on in the driver -- it's not
> like you want .5second unpreemptible jobs to be easy to produce.
>
> Also, for CS, I wonder if we have another reg besides CSD_CURRENT_CFG4
> we could be looking at for "we're making progress on the job".  Half a
> second with no discernible progress sounds like a bug.

If binning/render/TFU/cache_clean jobs keep running over 0.5 seconds,
then it should be a bug because they normally complete processing
within the period.
However, a CSD job can do anything.
For example, SaschaWillems's ray tracing example requires about 0.7
seconds to compose a frame with compute shader with Igalia's Vulkan
driver.
Another example is our matrix computation library for QPU:
https://github.com/Idein/qmkl6
It requires about 1.1 seconds to multiply two 2048x2048 matrices.
Because in general we do not know what is the expected behavior of a
QPU program and what is not, we also cannot detect a progress the
program is making.
This is why we want to have the timeout parameters to be able to be modified.

Regards,
Y. Sugizaki.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 3/3] drm/bridge: anx7625: add MIPI DPI input feature support

[Robert Foss]

Hey Xin,

On Thu, 28 Jan 2021 at 04:12, Xin Ji  wrote:
>
> Add MIPI rx DPI input support
>
> Reported-by: kernel test robot 
> Signed-off-by: Xin Ji 
> ---
>  drivers/gpu/drm/bridge/analogix/anx7625.c | 326 
> --
>  drivers/gpu/drm/bridge/analogix/anx7625.h |  20 +-
>  2 files changed, 285 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 04536cc..628ae43 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -150,18 +150,18 @@ static int anx7625_write_and(struct anx7625_data *ctx,
> return anx7625_reg_write(ctx, client, offset, (val & (mask)));
>  }
>
> -static int anx7625_write_and_or(struct anx7625_data *ctx,
> -   struct i2c_client *client,
> -   u8 offset, u8 and_mask, u8 or_mask)
> +static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
>  {
> -   int val;
> +   int i, ret;
>
> -   val = anx7625_reg_read(ctx, client, offset);
> -   if (val < 0)
> -   return val;
> +   ret = anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
> +  AUDIO_CONTROL_REGISTER, 0x80);
> +   for (i = 0; i < 13; i++)
> +   ret |= anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
> +VIDEO_BIT_MATRIX_12 + i,
> +0x18 + i);
>
> -   return anx7625_reg_write(ctx, client,
> -offset, (val & and_mask) | (or_mask));
> +   return ret;
>  }
>
>  static int anx7625_read_ctrl_status_p0(struct anx7625_data *ctx)
> @@ -195,6 +195,60 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
> return 0;
>  }
>
> +static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
> +u8 addrh, u8 addrm, u8 addrl,
> +u8 len, u8 *buf)
> +{
> +   struct device *dev = &ctx->client->dev;
> +   int ret;
> +   u8 cmd;
> +
> +   if (len > MAX_DPCD_BUFFER_SIZE) {
> +   DRM_DEV_ERROR(dev, "exceed aux buffer len.\n");
> +   return -EINVAL;
> +   }
> +
> +   cmd = ((len - 1) << 4) | 0x09;
> +
> +   /* Set command and length */
> +   ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> +   AP_AUX_COMMAND, cmd);
> +
> +   /* Set aux access address */
> +   ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> +AP_AUX_ADDR_7_0, addrl);
> +   ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> +AP_AUX_ADDR_15_8, addrm);
> +   ret |= anx7625_write_and(ctx, ctx->i2c.rx_p0_client,
> +AP_AUX_ADDR_19_16, addrh);
> +
> +   /* Enable aux access */
> +   ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
> +   AP_AUX_CTRL_STATUS, AP_AUX_CTRL_OP_EN);
> +
> +   if (ret < 0) {
> +   DRM_DEV_ERROR(dev, "cannot access aux related register.\n");
> +   return -EIO;
> +   }
> +
> +   usleep_range(2000, 2100);
> +
> +   ret = wait_aux_op_finish(ctx);
> +   if (ret) {
> +   DRM_DEV_ERROR(dev, "aux IO error: wait aux op finish.\n");
> +   return ret;
> +   }
> +
> +   ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
> +AP_AUX_BUFF_START, len, buf);
> +   if (ret < 0) {
> +   DRM_DEV_ERROR(dev, "read dpcd register failed\n");
> +   return -EIO;
> +   }
> +
> +   return 0;
> +}
> +
>  static int anx7625_video_mute_control(struct anx7625_data *ctx,
>   u8 status)
>  {
> @@ -219,38 +273,6 @@ static int anx7625_video_mute_control(struct 
> anx7625_data *ctx,
> return ret;
>  }
>
> -static int anx7625_config_audio_input(struct anx7625_data *ctx)
> -{
> -   struct device *dev = &ctx->client->dev;
> -   int ret;
> -
> -   /* Channel num */
> -   ret = anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
> -   AUDIO_CHANNEL_STATUS_6, I2S_CH_2 << 5);
> -
> -   /* FS */
> -   ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
> -   AUDIO_CHANNEL_STATUS_4,
> -   0xf0, AUDIO_FS_48K);
> -   /* Word length */
> -   ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
> -   AUDIO_CHANNEL_STATUS_5,
> -   0xf0, AUDIO_W_LEN_24_24MAX);
> -   /* I2S */
> -   ret |= anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
> -   AUDIO_CHANNEL_STATUS_6, I2S_SLAVE_MODE);
> -   ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client,
> -AUDIO_C

Re: [Linaro-mm-sig] [PATCH 1/2] mm: replace BUG_ON in vm_insert_page with a return of an error

[Suren Baghdasaryan]

On Thu, Feb 4, 2021 at 7:55 AM Alex Deucher  wrote:
>
> On Thu, Feb 4, 2021 at 3:16 AM Christian König  
> wrote:
> >
> > Am 03.02.21 um 22:41 schrieb Suren Baghdasaryan:
> > > [SNIP]
> > >>> How many semi-unrelated buffer accounting schemes does google come up 
> > >>> with?
> > >>>
> > >>> We're at three with this one.
> > >>>
> > >>> And also we _cannot_ required that all dma-bufs are backed by struct
> > >>> page, so requiring struct page to make this work is a no-go.
> > >>>
> > >>> Second, we do not want to all get_user_pages and friends to work on
> > >>> dma-buf, it causes all kinds of pain. Yes on SoC where dma-buf are
> > >>> exclusively in system memory you can maybe get away with this, but
> > >>> dma-buf is supposed to work in more places than just Android SoCs.
> > >> I just realized that vm_inser_page doesn't even work for CMA, it would
> > >> upset get_user_pages pretty badly - you're trying to pin a page in
> > >> ZONE_MOVEABLE but you can't move it because it's rather special.
> > >> VM_SPECIAL is exactly meant to catch this stuff.
> > > Thanks for the input, Daniel! Let me think about the cases you pointed 
> > > out.
> > >
> > > IMHO, the issue with PSS is the difficulty of calculating this metric
> > > without struct page usage. I don't think that problem becomes easier
> > > if we use cgroups or any other API. I wanted to enable existing PSS
> > > calculation mechanisms for the dmabufs known to be backed by struct
> > > pages (since we know how the heap allocated that memory), but sounds
> > > like this would lead to problems that I did not consider.
> >
> > Yeah, using struct page indeed won't work. We discussed that multiple
> > times now and Daniel even has a patch to mangle the struct page pointers
> > inside the sg_table object to prevent abuse in that direction.
> >
> > On the other hand I totally agree that we need to do something on this
> > side which goes beyong what cgroups provide.
> >
> > A few years ago I came up with patches to improve the OOM killer to
> > include resources bound to the processes through file descriptors. I
> > unfortunately can't find them of hand any more and I'm currently to busy
> > to dig them up.
>
> https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html
> I think there was a more recent discussion, but I can't seem to find it.

Thanks for the pointer!
Appreciate the time everyone took to explain the issues.
Thanks,
Suren.

>
> Alex
>
> >
> > In general I think we need to make it possible that both the in kernel
> > OOM killer as well as userspace processes and handlers have access to
> > that kind of data.
> >
> > The fdinfo approach as suggested in the other thread sounds like the
> > easiest solution to me.
> >
> > Regards,
> > Christian.
> >
> > > Thanks,
> > > Suren.
> > >
> > >
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/2] procfs: Allow reading fdinfo with PTRACE_MODE_READ

[Kalesh Singh]

Android captures per-process system memory state when certain low memory
events (e.g a foreground app kill) occur, to identify potential memory
hoggers. In order to measure how much memory a process actually consumes,
it is necessary to include the DMA buffer sizes for that process in the
memory accounting. Since the handle to DMA buffers are raw FDs, it is
important to be able to identify which processes have FD references to
a DMA buffer.

Currently, DMA buffer FDs can be accounted using /proc//fd/* and
/proc//fdinfo -- both are only readable by the process owner,
as follows:
  1. Do a readlink on each FD.
  2. If the target path begins with "/dmabuf", then the FD is a dmabuf FD.
  3. stat the file to get the dmabuf inode number.
  4. Read/ proc//fdinfo/, to get the DMA buffer size.

Accessing other processes’ fdinfo requires root privileges. This limits
the use of the interface to debugging environments and is not suitable
for production builds.  Granting root privileges even to a system process
increases the attack surface and is highly undesirable.

Since fdinfo doesn't permit reading process memory and manipulating
process state, allow accessing fdinfo under PTRACE_MODE_READ_FSCRED.

Suggested-by: Jann Horn 
Signed-off-by: Kalesh Singh 
---
Changes in v2:
  - Update patch description

 fs/proc/base.c |  4 ++--
 fs/proc/fd.c   | 15 ++-
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index b3422cda2a91..a37f9de7103f 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -3160,7 +3160,7 @@ static const struct pid_entry tgid_base_stuff[] = {
DIR("task",   S_IRUGO|S_IXUGO, proc_task_inode_operations, 
proc_task_operations),
DIR("fd", S_IRUSR|S_IXUSR, proc_fd_inode_operations, 
proc_fd_operations),
DIR("map_files",  S_IRUSR|S_IXUSR, proc_map_files_inode_operations, 
proc_map_files_operations),
-   DIR("fdinfo", S_IRUSR|S_IXUSR, proc_fdinfo_inode_operations, 
proc_fdinfo_operations),
+   DIR("fdinfo", S_IRUGO|S_IXUGO, proc_fdinfo_inode_operations, 
proc_fdinfo_operations),
DIR("ns", S_IRUSR|S_IXUGO, proc_ns_dir_inode_operations, 
proc_ns_dir_operations),
 #ifdef CONFIG_NET
DIR("net",S_IRUGO|S_IXUGO, proc_net_inode_operations, 
proc_net_operations),
@@ -3504,7 +3504,7 @@ static const struct inode_operations 
proc_tid_comm_inode_operations = {
  */
 static const struct pid_entry tid_base_stuff[] = {
DIR("fd",S_IRUSR|S_IXUSR, proc_fd_inode_operations, 
proc_fd_operations),
-   DIR("fdinfo",S_IRUSR|S_IXUSR, proc_fdinfo_inode_operations, 
proc_fdinfo_operations),
+   DIR("fdinfo",S_IRUGO|S_IXUGO, proc_fdinfo_inode_operations, 
proc_fdinfo_operations),
DIR("ns",S_IRUSR|S_IXUGO, proc_ns_dir_inode_operations, 
proc_ns_dir_operations),
 #ifdef CONFIG_NET
DIR("net",S_IRUGO|S_IXUGO, proc_net_inode_operations, 
proc_net_operations),
diff --git a/fs/proc/fd.c b/fs/proc/fd.c
index cb51763ed554..585e213301f9 100644
--- a/fs/proc/fd.c
+++ b/fs/proc/fd.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -72,6 +73,18 @@ static int seq_show(struct seq_file *m, void *v)
 
 static int seq_fdinfo_open(struct inode *inode, struct file *file)
 {
+   bool allowed = false;
+   struct task_struct *task = get_proc_task(inode);
+
+   if (!task)
+   return -ESRCH;
+
+   allowed = ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
+   put_task_struct(task);
+
+   if (!allowed)
+   return -EACCES;
+
return single_open(file, seq_show, inode);
 }
 
@@ -307,7 +320,7 @@ static struct dentry *proc_fdinfo_instantiate(struct dentry 
*dentry,
struct proc_inode *ei;
struct inode *inode;
 
-   inode = proc_pid_make_inode(dentry->d_sb, task, S_IFREG | S_IRUSR);
+   inode = proc_pid_make_inode(dentry->d_sb, task, S_IFREG | S_IRUGO);
if (!inode)
return ERR_PTR(-ENOENT);
 
-- 
2.30.0.478.g8a0d178c01-goog

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/2] procfs: Allow reading fdinfo with PTRACE_MODE_READ

[Kalesh Singh]

Android captures per-process system memory state when certain low memory
events (e.g a foreground app kill) occur, to identify potential memory
hoggers. In order to measure how much memory a process actually consumes,
it is necessary to include the DMA buffer sizes for that process in the
memory accounting. Since the handle to DMA buffers are raw FDs, it is
important to be able to identify which processes have FD references to
a DMA buffer.

Currently, DMA buffer FDs can be accounted using /proc//fd/* and
/proc//fdinfo -- both are only readable by the process owner,
as follows:
  1. Do a readlink on each FD.
  2. If the target path begins with "/dmabuf", then the FD is a dmabuf FD.
  3. stat the file to get the dmabuf inode number.
  4. Read/ proc//fdinfo/, to get the DMA buffer size.

Accessing other processes’ fdinfo requires root privileges. This limits
the use of the interface to debugging environments and is not suitable
for production builds.  Granting root privileges even to a system process
increases the attack surface and is highly undesirable.

Since fdinfo doesn't permit reading process memory and manipulating
process state, allow accessing fdinfo under PTRACE_MODE_READ_FSCRED.

Suggested-by: Jann Horn 
Signed-off-by: Kalesh Singh 
---

Changes in v2:
  - Update patch desciption

 fs/proc/base.c |  4 ++--
 fs/proc/fd.c   | 15 ++-
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index b3422cda2a91..a37f9de7103f 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -3160,7 +3160,7 @@ static const struct pid_entry tgid_base_stuff[] = {
DIR("task",   S_IRUGO|S_IXUGO, proc_task_inode_operations, 
proc_task_operations),
DIR("fd", S_IRUSR|S_IXUSR, proc_fd_inode_operations, 
proc_fd_operations),
DIR("map_files",  S_IRUSR|S_IXUSR, proc_map_files_inode_operations, 
proc_map_files_operations),
-   DIR("fdinfo", S_IRUSR|S_IXUSR, proc_fdinfo_inode_operations, 
proc_fdinfo_operations),
+   DIR("fdinfo", S_IRUGO|S_IXUGO, proc_fdinfo_inode_operations, 
proc_fdinfo_operations),
DIR("ns", S_IRUSR|S_IXUGO, proc_ns_dir_inode_operations, 
proc_ns_dir_operations),
 #ifdef CONFIG_NET
DIR("net",S_IRUGO|S_IXUGO, proc_net_inode_operations, 
proc_net_operations),
@@ -3504,7 +3504,7 @@ static const struct inode_operations 
proc_tid_comm_inode_operations = {
  */
 static const struct pid_entry tid_base_stuff[] = {
DIR("fd",S_IRUSR|S_IXUSR, proc_fd_inode_operations, 
proc_fd_operations),
-   DIR("fdinfo",S_IRUSR|S_IXUSR, proc_fdinfo_inode_operations, 
proc_fdinfo_operations),
+   DIR("fdinfo",S_IRUGO|S_IXUGO, proc_fdinfo_inode_operations, 
proc_fdinfo_operations),
DIR("ns",S_IRUSR|S_IXUGO, proc_ns_dir_inode_operations, 
proc_ns_dir_operations),
 #ifdef CONFIG_NET
DIR("net",S_IRUGO|S_IXUGO, proc_net_inode_operations, 
proc_net_operations),
diff --git a/fs/proc/fd.c b/fs/proc/fd.c
index cb51763ed554..585e213301f9 100644
--- a/fs/proc/fd.c
+++ b/fs/proc/fd.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -72,6 +73,18 @@ static int seq_show(struct seq_file *m, void *v)
 
 static int seq_fdinfo_open(struct inode *inode, struct file *file)
 {
+   bool allowed = false;
+   struct task_struct *task = get_proc_task(inode);
+
+   if (!task)
+   return -ESRCH;
+
+   allowed = ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
+   put_task_struct(task);
+
+   if (!allowed)
+   return -EACCES;
+
return single_open(file, seq_show, inode);
 }
 
@@ -307,7 +320,7 @@ static struct dentry *proc_fdinfo_instantiate(struct dentry 
*dentry,
struct proc_inode *ei;
struct inode *inode;
 
-   inode = proc_pid_make_inode(dentry->d_sb, task, S_IFREG | S_IRUSR);
+   inode = proc_pid_make_inode(dentry->d_sb, task, S_IFREG | S_IRUGO);
if (!inode)
return ERR_PTR(-ENOENT);
 
-- 
2.30.0.365.g02bc693789-goog

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging: fbtft replaced udelay with usleep_range

[kernel test robot]

Hi Mayank,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on staging/staging-testing]

url:
https://github.com/0day-ci/linux/commits/Mayank-Suman/staging-fbtft-replaced-udelay-with-usleep_range/20210205-171807
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
06b0c0dce88e2aa2f01343db0f26d214d7f264a0
config: arm64-randconfig-r025-20210205 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
c9439ca36342fb6013187d0a69aef92736951476)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/4a777af1cc91dc603b6b92fe06fd94081dc2891e
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Mayank-Suman/staging-fbtft-replaced-udelay-with-usleep_range/20210205-171807
git checkout 4a777af1cc91dc603b6b92fe06fd94081dc2891e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> drivers/staging/fbtft/fb_ra8875.c:220:18: error: too few arguments to 
>> function call, expected 2, have 1
   usleep_range(100);
   ^
   include/linux/delay.h:61:6: note: 'usleep_range' declared here
   void usleep_range(unsigned long min, unsigned long max);
^
   drivers/staging/fbtft/fb_ra8875.c:241:18: error: too few arguments to 
function call, expected 2, have 1
   usleep_range(100);
   ^
   include/linux/delay.h:61:6: note: 'usleep_range' declared here
   void usleep_range(unsigned long min, unsigned long max);
^
   2 errors generated.
--
>> drivers/staging/fbtft/fb_tinylcd.c:44:18: error: too few arguments to 
>> function call, expected 2, have 1
   usleep_range(250);
   ^
   include/linux/delay.h:61:6: note: 'usleep_range' declared here
   void usleep_range(unsigned long min, unsigned long max);
^
   1 error generated.
--
>> drivers/staging/fbtft/fb_watterott.c:87:19: error: too few arguments to 
>> function call, expected 2, have 1
   usleep_range(300);
   ^
   include/linux/delay.h:61:6: note: 'usleep_range' declared here
   void usleep_range(unsigned long min, unsigned long max);
^
   drivers/staging/fbtft/fb_watterott.c:127:19: error: too few arguments to 
function call, expected 2, have 1
   usleep_range(700);
   ^
   include/linux/delay.h:61:6: note: 'usleep_range' declared here
   void usleep_range(unsigned long min, unsigned long max);
^
   2 errors generated.


vim +220 drivers/staging/fbtft/fb_ra8875.c

   189  
   190  static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
   191  {
   192  va_list args;
   193  int i, ret;
   194  u8 *buf = par->buf;
   195  
   196  /* slow down spi-speed for writing registers */
   197  par->fbtftops.write = write_spi;
   198  
   199  if (unlikely(par->debug & DEBUG_WRITE_REGISTER)) {
   200  va_start(args, len);
   201  for (i = 0; i < len; i++)
   202  buf[i] = (u8)va_arg(args, unsigned int);
   203  va_end(args);
   204  fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, 
par->info->device,
   205u8, buf, len, "%s: ", __func__);
   206  }
   207  
   208  va_start(args, len);
   209  *buf++ = 0x80;
   210  *buf = (u8)va_arg(args, unsigned int);
   211  ret = par->fbtftops.write(par, par->buf, 2);
   212  if (ret < 0) {
   213  va_end(args);
   214  dev_err(par->info->device, "write() failed and returned 
%dn",
   215  ret);
   216  return;
   217  }
   218  len--;
   219  
 > 220  usleep_range(100);
   221  
   222  if (len) {
   223  buf = (u8 *)par->buf;
   224  *buf++ = 0x00;
   225  i = len;
   226  while (i--)
   227  *buf++ = (u8)va_arg(args, unsigned int);
   228  
   229  ret = par->fbtftops.write(par, par->buf, len + 1);
   230  if (ret < 0) {
   231  

[PATCH] drivers: gpu: drm: nouveau: Change not good word with a good one in the file init.c

[Bhaskar Chowdhury]

s/fucking/messing/

Signed-off-by: Bhaskar Chowdhury 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index 9de74f41dcd2..bc2a55a82171 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -446,7 +446,7 @@ init_ram_restrict(struct nvbios_init *init)
 {
/* This appears to be the behaviour of the VBIOS parser, and *is*
 * important to cache the NV_PEXTDEV_BOOT0 on later chipsets to
-* avoid fucking up the memory controller (somehow) by reading it
+* avoid messing up the memory controller (somehow) by reading it
 * on every INIT_RAM_RESTRICT_ZM_GROUP opcode.
 *
 * Preserving the non-caching behaviour on earlier chipsets just
--
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: Autoselect CONFIG_CHECKPOINT_RESTORE for SYS_kcmp

[Chris Wilson]

gallium (iris) depends on os_same_file_description() to disambiguate
screens and so avoid importing the same screen fd twice as two distinct
entities (that share all the kernel resources, so actions on screen
affect the other and would cause random faiure). As they depend on it,
so must we. os_same_file_description() uses SYS_kcmp to check the file
tables for the equivalent struct file, but SYS_kcmp is hidden behind
CONFIG_CHECKPOINT_RESTORE. As this is not default, we must select it for
ourselves to ensure that our userspace is fully supported.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3046
Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 1e1cb245fca7..470a5214bd33 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -21,6 +21,7 @@ config DRM_I915
select ACPI_VIDEO if ACPI
select ACPI_BUTTON if ACPI
select SYNC_FILE
+   select CHECKPOINT_RESTORE # gallium depends on SYS_kcmp
select IOSF_MBI
select CRC32
select SND_HDA_I915 if SND_HDA_CORE
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drivers: drm: nouveau: nvkm: Replace a word with a better phonetic word in the file macros.fuc

[Bhaskar Chowdhury]

s/fuck/heck/


Signed-off-by: Bhaskar Chowdhury 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc 
b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
index 3737bd27f74e..1407a1b16d95 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
@@ -46,7 +46,7 @@
 #define NV_PPWR_INTR_EN_SET_SUBINTR  0x0800
 #define NV_PPWR_INTR_EN_SET_WATCHDOG 0x0002
 #define NV_PPWR_INTR_EN_CLR  0x0014
-#define NV_PPWR_INTR_EN_CLR_MASK/* fuck i hate envyas */ -1
+#define NV_PPWR_INTR_EN_CLR_MASK/* heck, i hate envyas */ 
-1
 #define NV_PPWR_INTR_ROUTE   0x001c
 #define NV_PPWR_TIMER_LOW0x002c
 #define NV_PPWR_WATCHDOG_TIME0x0034
--
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: manual merge of the drivers-x86 tree with the drm-misc tree

[Daniel Vetter]

On Fri, Feb 5, 2021 at 12:14 PM Patrik Jakobsson
 wrote:
>
> On Fri, Feb 5, 2021 at 12:07 PM Andy Shevchenko
>  wrote:
> >
> > On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko
> >  wrote:
> > >> Today's linux-next merge of the drivers-x86 tree got a conflict in:
> > >
> > > Thanks. I already asked Patrik yesterday day if DRM missed to pull an 
> > > immutable tag I provided. I think they can pull and resolve conflicts 
> > > themselves. Alternatively it would be easy to resolve by Linus by 
> > > removing Kconfig lines along with mentioned files,
> >
> > Patrik, I have sent a PR again, so you may consider pulling it, thanks!
>
> Daniel, is this something you can pull into drm or ask one of the
> drm-misc maintainers to do?

We've already created the conflict, and my understanding is that Linus
wants to have visibility into conflict-y stuff and doesn't mind at all
resolving conflicts. Hence for 5.12 I think we're fine as-is.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH rdma-core v2 3/3] configure: Add check for the presence of DRM headers

[Jason Gunthorpe]

On Thu, Feb 04, 2021 at 04:29:14PM -0800, Jianxin Xiong wrote:
> Compilation of pyverbs/dmabuf_alloc.c depends on a few DRM headers
> that are installed by either the kernel-header or the libdrm package.
> The installation is optional and the location is not unique.
> 
> Check the presence of the headers at both the standard locations and
> any location defined by custom libdrm installation. If the headers
> are missing, the dmabuf allocation routines are replaced by stubs that
> return suitable error to allow the related tests to skip.
> 
> Signed-off-by: Jianxin Xiong 
>  CMakeLists.txt  | 15 +++
>  pyverbs/CMakeLists.txt  | 14 --
>  pyverbs/dmabuf_alloc.c  |  8 
>  pyverbs/dmabuf_alloc_stub.c | 39 +++
>  4 files changed, 70 insertions(+), 6 deletions(-)
>  create mode 100644 pyverbs/dmabuf_alloc_stub.c
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 4113423..95aec11 100644
> +++ b/CMakeLists.txt
> @@ -515,6 +515,21 @@ find_package(Systemd)
>  include_directories(${SYSTEMD_INCLUDE_DIRS})
>  RDMA_DoFixup("${SYSTEMD_FOUND}" "systemd/sd-daemon.h")
>  
> +# drm headers
> +
> +# First check the standard locations. The headers could have been installed
> +# by either the kernle-headers package or the libdrm package.
> +find_path(DRM_INCLUDE_DIRS "drm.h" PATH_SUFFIXES "drm" "libdrm")

Is there a reason not to just always call pkg_check_modules?

> +# Then check custom installation of libdrm
> +if (NOT DRM_INCLUDE_DIRS)
> +  pkg_check_modules(DRM libdrm)
> +endif()
> +
> +if (DRM_INCLUDE_DIRS)
> +  include_directories(${DRM_INCLUDE_DIRS})
> +endif()

This needs a hunk at the end:

if (NOT DRM_INCLUDE_DIRS)
  message(STATUS " DMABUF NOT supported (disabling some tests)")
endif()

>  #-
>  # Apply fixups
>  
> diff --git a/pyverbs/CMakeLists.txt b/pyverbs/CMakeLists.txt
> index 6fd7625..922253f 100644
> +++ b/pyverbs/CMakeLists.txt
> @@ -13,8 +13,6 @@ rdma_cython_module(pyverbs ""
>cmid.pyx
>cq.pyx
>device.pyx
> -  dmabuf.pyx
> -  dmabuf_alloc.c
>enums.pyx
>mem_alloc.pyx
>mr.pyx
> @@ -25,6 +23,18 @@ rdma_cython_module(pyverbs ""
>xrcd.pyx
>  )
>  
> +if (DRM_INCLUDE_DIRS)
> +rdma_cython_module(pyverbs ""
> +  dmabuf.pyx
> +  dmabuf_alloc.c
> +)
> +else()
> +rdma_cython_module(pyverbs ""
> +  dmabuf.pyx
> +  dmabuf_alloc_stub.c
> +)
> +endif()

Like this:

if (DRM_INCLUDE_DIRS)
  set(DMABUF_ALLOC dmabuf_alloc.c)
else()
  set(DMABUF_ALLOC dmabuf_alloc_stbub.c)
endif()
rdma_cython_module(pyverbs ""
  dmabuf.pyx
  $(DMABUF_ALLOC)
)

Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel

[Ville Syrjälä]

On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil  wrote:
> >
> > On 01/02/2021 23:13, Ville Syrjälä wrote:
> > > On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> > >> From: Hans Verkuil 
> > >>
> > >> For adapters behind an MST hub use the correct AUX channel.
> > >>
> > >> Signed-off-by: Hans Verkuil 
> > >> [sa...@chromium.org: rebased, removing redundant changes]
> > >> Signed-off-by: Sam McNally 
> > >> ---
> > >>
> > >> (no changes since v1)
> > >>
> > >>  drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
> > >>  1 file changed, 36 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > >> b/drivers/gpu/drm/drm_dp_mst_topology.c
> > >> index 15b6cc39a754..0d753201adbd 100644
> > >> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > >> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > >> @@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct 
> > >> drm_dp_mst_topology_mgr *mgr,
> > >>  drm_dp_mst_topology_put_port(port);
> > >>  }
> > >>
> > >> +static ssize_t
> > >> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
> > >> *msg);
> > >> +
> > >>  static struct drm_dp_mst_port *
> > >>  drm_dp_mst_add_port(struct drm_device *dev,
> > >>  struct drm_dp_mst_topology_mgr *mgr,
> > >> @@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
> > >>  port->port_num = port_number;
> > >>  port->mgr = mgr;
> > >>  port->aux.name = "DPMST";
> > >> +mutex_init(&port->aux.hw_mutex);
> > >> +mutex_init(&port->aux.cec.lock);
> > >>  port->aux.dev = dev->dev;
> > >>  port->aux.is_remote = true;
> > >>
> > >> +port->aux.transfer = drm_dp_mst_aux_transfer;
> > >> +
> > >
> > > This was supposed to be handled via higher levels checking for
> > > is_remote==true.
> >
> > Ah, I suspect this patch can be dropped entirely: it predates commit 
> > 2f221a5efed4
> > ("drm/dp_mst: Add MST support to DP DPCD R/W functions").
> >
> > It looks like that commit basically solved what this older patch attempts 
> > to do
> > as well.
> >
> > Sam, can you test if it works without this patch?
> 
> It almost just works; drm_dp_cec uses whether aux.transfer is non-null
> to filter out non-DP connectors. Using aux.is_remote as another signal
> indicating a DP connector seems plausible. We can drop this patch.

Why would anyone even call this stuff on a non-DP connector?
And where did they even get the struct drm_dp_aux to do so?

> Thanks all!
> >
> > Regards,
> >
> > Hans
> >
> > >
> > >>  /* initialize the MST downstream port's AUX crc work queue */
> > >>  drm_dp_remote_aux_init(&port->aux);
> > >>
> > >> @@ -3503,6 +3510,35 @@ static int drm_dp_send_up_ack_reply(struct 
> > >> drm_dp_mst_topology_mgr *mgr,
> > >>  return 0;
> > >>  }
> > >>
> > >> +static ssize_t
> > >> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
> > >> *msg)
> > >> +{
> > >> +struct drm_dp_mst_port *port =
> > >> +container_of(aux, struct drm_dp_mst_port, aux);
> > >> +int ret;
> > >> +
> > >> +switch (msg->request & ~DP_AUX_I2C_MOT) {
> > >> +case DP_AUX_NATIVE_WRITE:
> > >> +case DP_AUX_I2C_WRITE:
> > >> +case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> > >> +ret = drm_dp_send_dpcd_write(port->mgr, port, msg->address,
> > >> + msg->size, msg->buffer);
> > >
> > > That doesn't make sense to me. I2c writes and DPCD writes
> > > are definitely not the same thing.
> > >
> > > aux->transfer is a very low level thing. I don't think it's the
> > > correct level of abstraction for sideband.
> > >
> > >> +break;
> > >> +
> > >> +case DP_AUX_NATIVE_READ:
> > >> +case DP_AUX_I2C_READ:
> > >> +ret = drm_dp_send_dpcd_read(port->mgr, port, msg->address,
> > >> +msg->size, msg->buffer);
> > >> +break;
> > >> +
> > >> +default:
> > >> +ret = -EINVAL;
> > >> +break;
> > >> +}
> > >> +
> > >> +return ret;
> > >> +}
> > >> +
> > >>  static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8  dp_link_count)
> > >>  {
> > >>  if (dp_link_bw == 0 || dp_link_count == 0)
> > >> --
> > >> 2.28.0.681.g6f77f65b4e-goog
> > >>
> > >> ___
> > >> dri-devel mailing list
> > >> dri-devel@lists.freedesktop.org
> > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> >

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] PCI: Also set up legacy files only after sysfs init

[Daniel Vetter]

We are already doing this for all the regular sysfs files on PCI
devices, but not yet on the legacy io files on the PCI buses. Thus far
no problem, but in the next patch I want to wire up iomem revoke
support. That needs the vfs up and running already to make sure that
iomem_get_mapping() works.

Wire it up exactly like the existing code in
pci_create_sysfs_dev_files(). Note that pci_remove_legacy_files()
doesn't need a check since the one for pci_bus->legacy_io is
sufficient.

An alternative solution would be to implement a callback in sysfs to
set up the address space from iomem_get_mapping() when userspace calls
mmap(). This also works, but Greg didn't really like that just to work
around an ordering issue when the kernel loads initially.

v2: Improve commit message (Bjorn)

Signed-off-by: Daniel Vetter 
Cc: Stephen Rothwell 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Dan Williams 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: Greg Kroah-Hartman 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas 
Cc: linux-...@vger.kernel.org
---
 drivers/pci/pci-sysfs.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index fb072f4b3176..0c45b4f7b214 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -927,6 +927,9 @@ void pci_create_legacy_files(struct pci_bus *b)
 {
int error;
 
+   if (!sysfs_initialized)
+   return;
+
b->legacy_io = kcalloc(2, sizeof(struct bin_attribute),
   GFP_ATOMIC);
if (!b->legacy_io)
@@ -1448,6 +1451,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
 static int __init pci_sysfs_init(void)
 {
struct pci_dev *pdev = NULL;
+   struct pci_bus *pbus = NULL;
int retval;
 
sysfs_initialized = 1;
@@ -1459,6 +1463,9 @@ static int __init pci_sysfs_init(void)
}
}
 
+   while ((pbus = pci_find_next_bus(pbus)))
+   pci_create_legacy_files(pbus);
+
return 0;
 }
 late_initcall(pci_sysfs_init);
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] RFC: dma-buf: Require VM_PFNMAP vma for mmap

[Daniel Vetter]

tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.

Since some userspace only runs on integrated devices, where all
buffers are actually all resident system memory, there's a huge
temptation to assume that a struct page is always present and useable
like for any more pagecache backed mmap. This has the potential to
result in a uapi nightmare.

To stop this gap require that DMA buffer mmaps are VM_PFNMAP, which
blocks get_user_pages and all the other struct page based
infrastructure for everyone. In spirit this is the uapi counterpart to
the kernel-internal CONFIG_DMABUF_DEBUG.

Motivated by a recent patch which wanted to swich the system dma-buf
heap to vm_insert_page instead of vm_insert_pfn.

v2:

Jason brought up that we also want to guarantee that all ptes have the
pte_special flag set, to catch fast get_user_pages (on architectures
that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) would
still allow vm_insert_page, but limiting to VM_PFNMAP will catch that.

From auditing the various functions to insert pfn pte entires
(vm_insert_pfn_prot, remap_pfn_range and all it's callers like
dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, so
this should be the correct flag to check for.

References: 
https://lore.kernel.org/lkml/cakmk7uhi+mg0z0humnt13qccvuturvjpcr0njrl12k-wbwz...@mail.gmail.com/
Cc: Jason Gunthorpe 
Cc: Suren Baghdasaryan 
Cc: Matthew Wilcox 
Cc: John Stultz 
Signed-off-by: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
 drivers/dma-buf/dma-buf.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..06cb1d2e9fdc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -127,6 +127,7 @@ static struct file_system_type dma_buf_fs_type = {
 static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
 {
struct dma_buf *dmabuf;
+   int ret;
 
if (!is_dma_buf_file(file))
return -EINVAL;
@@ -142,7 +143,11 @@ static int dma_buf_mmap_internal(struct file *file, struct 
vm_area_struct *vma)
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
 
-   return dmabuf->ops->mmap(dmabuf, vma);
+   ret = dmabuf->ops->mmap(dmabuf, vma);
+
+   WARN_ON(!(vma->vm_flags & VM_PFNMAP));
+
+   return ret;
 }
 
 static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
@@ -1244,6 +1249,8 @@ EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
 int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
 unsigned long pgoff)
 {
+   int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
 
@@ -1264,7 +1271,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma,
vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
 
-   return dmabuf->ops->mmap(dmabuf, vma);
+   ret = dmabuf->ops->mmap(dmabuf, vma);
+
+   WARN_ON(!(vma->vm_flags & VM_PFNMAP));
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(dma_buf_mmap);
 
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: anx7625: enable DSI EOTP

[Xin Ji]

On Fri, Feb 05, 2021 at 10:43:14AM +0100, Robert Foss wrote:
> On Thu, 4 Feb 2021 at 23:25, Nicolas Boichat  wrote:
> >
> > On Thu, Feb 4, 2021 at 8:59 PM Andrzej Hajda  wrote:
> > >
> > >
> > > W dniu 04.02.2021 o 13:34, Nicolas Boichat pisze:
> > > > On Thu, Feb 4, 2021 at 8:07 PM Robert Foss  
> > > > wrote:
> > > >> Hi Xin,
> > > >>
> > > >> Thanks for the patch.
> > > >>
> > > >> On Thu, 28 Jan 2021 at 12:17, Xin Ji  wrote:
> > > >>> Enable DSI EOTP feature for fixing some panel screen constance
> > > >>> shift issue.
> > > >>> Removing MIPI flag MIPI_DSI_MODE_EOT_PACKET to enable DSI EOTP.
> 
> Does "constance shift" have a typo? Should it be "constant shift"?
> 
> With that sorted out feel free to add my r-b.
> Reviewed-by: Robert Foss 
Hi Robert Foss, thanks, I'll correct it.
Thanks,
Xin
> 
> > > >> I don't think I quite understand how removing the
> > > >> MIPI_DSI_MODE_EOT_PACKET flag will cause DSI EOTP to be enabled. Could
> > > >> you extrapolate on this in the commit message?
> > > > That confused me as well, but it turns out that's how the flag is 
> > > > defined:
> > > > ```
> > > > /* disable EoT packets in HS mode */
> > > > #define MIPI_DSI_MODE_EOT_PACKET BIT(9)
> > > > ```
> > > > (https://protect2.fireeye.com/v1/url?k=5bd95ebd-044267fb-5bd8d5f2-0cc47a3003e8-ce9db8ea264d6901&q=1&e=900556dc-d199-4c18-9432-5c3465a98eae&u=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Finclude%2Fdrm%2Fdrm_mipi_dsi.h%23L129)
> > > >
> > > > I'm almost tempted to put together a mass patch to rename all of these 
> > > > flags...
> > >
> > >
> > > Yes that would be good, many of these flags were just copy pasted from
> > > some hw datasheet, without good analysis how to adapt them to the 
> > > framework.
> >
> > I'll look into it (but that shouldn't block this patch).
> 
> Thanks for clearing this up Nicolas & Andrzej!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] ib-drm-gpio-pdx86-rtc-wdt-v5.12-2

[Andy Shevchenko]

Hi Linus,

This is first part of Intel MID outdated platforms removal. It's collected into
immutable branch with a given tag, please pull to yours subsystems.

(All changes are tagged by the respective maintainers)

Thanks,

With Best Regards,
Andy Shevchenko

The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:

  Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)

are available in the Git repository at:

  git://git.infradead.org/linux-platform-drivers-x86.git 
tags/ib-drm-gpio-pdx86-rtc-wdt-v5.12-2

for you to fetch changes up to ca338fed2a5fce0904d7ab50bec061d2c8a2:

  platform/x86: intel_scu_wdt: Drop mistakenly added const (2021-02-05 12:54:27 
+0200)


ib-drm-gpio-pdx86-rtc-wdt for v5.12-2

First part of Intel MID outdated platforms removal.

The following is an automated git shortlog grouped by driver:

drm/gma500:
 -  Get rid of duplicate NULL checks
 -  Convert to use new SCU IPC API

gpio:
 -  msic: Remove driver for deprecated platform
 -  intel-mid: Remove driver for deprecated platform

intel_mid_powerbtn:
 -  Remove driver for deprecated platform

intel_mid_thermal:
 -  Remove driver for deprecated platform

intel_scu_wdt:
 -  Drop mistakenly added const
 -  Get rid of custom x86 model comparison
 -  Drop SCU notification
 -  Move driver from arch/x86

rtc:
 -  mrst: Remove driver for deprecated platform

watchdog:
 -  intel-mid_wdt: Postpone IRQ handler registration till SCU is ready
 -  intel_scu_watchdog: Remove driver for deprecated platform


Andy Shevchenko (13):
  drm/gma500: Convert to use new SCU IPC API
  drm/gma500: Get rid of duplicate NULL checks
  gpio: intel-mid: Remove driver for deprecated platform
  gpio: msic: Remove driver for deprecated platform
  platform/x86: intel_mid_thermal: Remove driver for deprecated platform
  platform/x86: intel_mid_powerbtn: Remove driver for deprecated platform
  rtc: mrst: Remove driver for deprecated platform
  watchdog: intel_scu_watchdog: Remove driver for deprecated platform
  watchdog: intel-mid_wdt: Postpone IRQ handler registration till SCU is 
ready
  platform/x86: intel_scu_wdt: Move driver from arch/x86
  platform/x86: intel_scu_wdt: Drop SCU notification
  platform/x86: intel_scu_wdt: Get rid of custom x86 model comparison
  platform/x86: intel_scu_wdt: Drop mistakenly added const

 MAINTAINERS|   2 -
 arch/x86/platform/intel-mid/device_libs/Makefile   |   1 -
 drivers/gpio/Kconfig   |  14 -
 drivers/gpio/Makefile  |   1 -
 drivers/gpio/TODO  |   2 +-
 drivers/gpio/gpio-intel-mid.c  | 414 ---
 drivers/gpio/gpio-msic.c   | 314 
 drivers/gpu/drm/gma500/Kconfig |   1 +
 drivers/gpu/drm/gma500/mdfld_device.c  |   2 -
 drivers/gpu/drm/gma500/mdfld_dsi_output.c  |   2 -
 drivers/gpu/drm/gma500/mdfld_output.c  |   8 +-
 drivers/gpu/drm/gma500/oaktrail_device.c   |   3 -
 drivers/gpu/drm/gma500/psb_drv.h   |   3 +
 drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c |  30 +-
 drivers/platform/x86/Kconfig   |  23 +-
 drivers/platform/x86/Makefile  |   3 +-
 drivers/platform/x86/intel_mid_powerbtn.c  | 233 -
 drivers/platform/x86/intel_mid_thermal.c   | 560 -
 .../platform/x86/intel_scu_wdt.c   |  41 +-
 drivers/rtc/Kconfig|  12 -
 drivers/rtc/Makefile   |   1 -
 drivers/rtc/rtc-mrst.c | 521 ---
 drivers/watchdog/Kconfig   |   9 -
 drivers/watchdog/Makefile  |   1 -
 drivers/watchdog/intel-mid_wdt.c   |   8 +-
 drivers/watchdog/intel_scu_watchdog.c  | 533 
 drivers/watchdog/intel_scu_watchdog.h  |  50 --
 27 files changed, 54 insertions(+), 2738 deletions(-)
 delete mode 100644 drivers/gpio/gpio-intel-mid.c
 delete mode 100644 drivers/gpio/gpio-msic.c
 delete mode 100644 drivers/platform/x86/intel_mid_powerbtn.c
 delete mode 100644 drivers/platform/x86/intel_mid_thermal.c
 rename arch/x86/platform/intel-mid/device_libs/platform_mrfld_wdt.c => 
drivers/platform/x86/intel_scu_wdt.c (69%)
 delete mode 100644 drivers/rtc/rtc-mrst.c
 delete mode 100644 drivers/watchdog/intel_scu_watchdog.c
 delete mode 100644 drivers/watchdog/intel_scu_watchdog.h

-- 
With Best Regards,
Andy Shevchenko


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/3] drm/bridge: anx7625: fix not correct return value

[Xin Ji]

On Thu, Feb 04, 2021 at 01:28:30PM +0100, Robert Foss wrote:
> Hi Xin,
> 
> On Thu, 28 Jan 2021 at 04:12, Xin Ji  wrote:
> >
> > At some time, the original code may return non zero value, force return 0
> > if operation finished
> 
> Missing "." at end of line.
Hi Rob, OK, thanks, I'll add it in the next series.
Thanks,
Xin
> 
> Other than that, this patch looks fine. Feel free to add my r-b.
> Reviewed-by: Robert Foss 
> 
> >
> > Signed-off-by: Xin Ji 
> > ---
> >  drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
> > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > index 65cc059..04536cc 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > @@ -189,10 +189,10 @@ static int wait_aux_op_finish(struct anx7625_data 
> > *ctx)
> >AP_AUX_CTRL_STATUS);
> > if (val < 0 || (val & 0x0F)) {
> > DRM_DEV_ERROR(dev, "aux status %02x\n", val);
> > -   val = -EIO;
> > +   return -EIO;
> > }
> >
> > -   return val;
> > +   return 0;
> >  }
> >
> >  static int anx7625_video_mute_control(struct anx7625_data *ctx,
> > --
> > 2.7.4
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: anx7625: enable DSI EOTP

[Xin Ji]

On Fri, Feb 05, 2021 at 12:30:45PM +0100, Robert Foss wrote:
> Hey Xin,
> 
> Thanks for the quick response. I think this is ok.
> 
> But going forward it is easier for maintainers to keep track of
> patches if they're submitted with a version tag. [PATCH] -> [PATCH v2]
> -> [PATCH v3] etc.
> 
> git send-email -v1
> git send-email -v2
> git send-email -v3
> 
> ^^^ does this for you
> 
> 
> Rob.
Hi Rob, thanks, I'll follow the rules in the next upstream.
Thanks,
xin
> 
> On Fri, 5 Feb 2021 at 12:14, Xin Ji  wrote:
> >
> > Enable DSI EOTP feature for fixing some panel screen constant shift issue.
> > Removing MIPI flag MIPI_DSI_MODE_EOT_PACKET to enable DSI EOTP.
> >
> > Reviewed-by: Robert Foss 
> > Signed-off-by: Xin Ji 
> > ---
> >  drivers/gpu/drm/bridge/analogix/anx7625.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
> > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > index 65cc059..e31eeb1b 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > @@ -1334,7 +1334,6 @@ static int anx7625_attach_dsi(struct anx7625_data 
> > *ctx)
> > dsi->format = MIPI_DSI_FMT_RGB888;
> > dsi->mode_flags = MIPI_DSI_MODE_VIDEO   |
> > MIPI_DSI_MODE_VIDEO_SYNC_PULSE  |
> > -   MIPI_DSI_MODE_EOT_PACKET|
> > MIPI_DSI_MODE_VIDEO_HSE;
> >
> > if (mipi_dsi_attach(dsi) < 0) {
> > --
> > 2.7.4
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag

[Sai Prakash Ranjan]

On 2021-02-04 03:16, Will Deacon wrote:

On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote:

On 2021-02-01 23:50, Jordan Crouse wrote:
> On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote:
> > On Mon, Feb 1, 2021 at 3:16 AM Will Deacon  wrote:
> > > On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote:
> > > > On 2021-01-29 14:35, Will Deacon wrote:
> > > > > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan wrote:
> > > > > > +#define IOMMU_LLC(1 << 6)
> > > > >
> > > > > On reflection, I'm a bit worried about exposing this because I think 
it
> > > > > will
> > > > > introduce a mismatched virtual alias with the CPU (we don't even have 
a
> > > > > MAIR
> > > > > set up for this memory type). Now, we also have that issue for the 
PTW,
> > > > > but
> > > > > since we always use cache maintenance (i.e. the streaming API) for
> > > > > publishing the page-tables to a non-coheren walker, it works out.
> > > > > However,
> > > > > if somebody expects IOMMU_LLC to be coherent with a DMA API coherent
> > > > > allocation, then they're potentially in for a nasty surprise due to 
the
> > > > > mismatched outer-cacheability attributes.
> > > > >
> > > >
> > > > Can't we add the syscached memory type similar to what is done on 
android?
> > >
> > > Maybe. How does the GPU driver map these things on the CPU side?
> >
> > Currently we use writecombine mappings for everything, although there
> > are some cases that we'd like to use cached (but have not merged
> > patches that would give userspace a way to flush/invalidate)
> >
>
> LLC/system cache doesn't have a relationship with the CPU cache.  Its
> just a
> little accelerator that sits on the connection from the GPU to DDR and
> caches
> accesses. The hint that Sai is suggesting is used to mark the buffers as
> 'no-write-allocate' to prevent GPU write operations from being cached in
> the LLC
> which a) isn't interesting and b) takes up cache space for read
> operations.
>
> Its easiest to think of the LLC as a bonus accelerator that has no cost
> for
> us to use outside of the unfortunate per buffer hint.
>
> We do have to worry about the CPU cache w.r.t I/O coherency (which is a
> different hint) and in that case we have all of concerns that Will
> identified.
>

For mismatched outer cacheability attributes which Will mentioned, I 
was

referring to [1] in android kernel.


I've lost track of the conversation here :/

When the GPU has a buffer mapped with IOMMU_LLC, is the buffer also 
mapped

into the CPU and with what attributes? Rob said "writecombine for
everything" -- does that mean ioremap_wc() / MEMREMAP_WC?



Rob answered this.

Finally, we need to be careful when we use the word "hint" as 
"allocation
hint" has a specific meaning in the architecture, and if we only 
mismatch on

those then we're actually ok. But I think IOMMU_LLC is more than just a
hint, since it actually drives eviction policy (i.e. it enables 
writeback).


Sorry for the pedantry, but I just want to make sure we're all talking
about the same things!



Sorry for the confusion which probably was caused by my mentioning of
android, NWA(no write allocate) is an allocation hint which we can 
ignore

for now as it is not introduced yet in upstream.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge: anx7625: enable DSI EOTP

[Xin Ji]

Enable DSI EOTP feature for fixing some panel screen constant shift issue.
Removing MIPI flag MIPI_DSI_MODE_EOT_PACKET to enable DSI EOTP.

Reviewed-by: Robert Foss 
Signed-off-by: Xin Ji 
---
 drivers/gpu/drm/bridge/analogix/anx7625.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 65cc059..e31eeb1b 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1334,7 +1334,6 @@ static int anx7625_attach_dsi(struct anx7625_data *ctx)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->mode_flags = MIPI_DSI_MODE_VIDEO   |
MIPI_DSI_MODE_VIDEO_SYNC_PULSE  |
-   MIPI_DSI_MODE_EOT_PACKET|
MIPI_DSI_MODE_VIDEO_HSE;
 
if (mipi_dsi_attach(dsi) < 0) {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] RFC: dma-buf: Require VM_PFNMAP vma for mmap

[Christian König]

Am 05.02.21 um 14:41 schrieb Daniel Vetter:

tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.

Since some userspace only runs on integrated devices, where all
buffers are actually all resident system memory, there's a huge
temptation to assume that a struct page is always present and useable
like for any more pagecache backed mmap. This has the potential to
result in a uapi nightmare.

To stop this gap require that DMA buffer mmaps are VM_PFNMAP, which
blocks get_user_pages and all the other struct page based
infrastructure for everyone. In spirit this is the uapi counterpart to
the kernel-internal CONFIG_DMABUF_DEBUG.

Motivated by a recent patch which wanted to swich the system dma-buf
heap to vm_insert_page instead of vm_insert_pfn.

v2:

Jason brought up that we also want to guarantee that all ptes have the
pte_special flag set, to catch fast get_user_pages (on architectures
that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) would
still allow vm_insert_page, but limiting to VM_PFNMAP will catch that.

 From auditing the various functions to insert pfn pte entires
(vm_insert_pfn_prot, remap_pfn_range and all it's callers like
dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, so
this should be the correct flag to check for.

References: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAKMK7uHi%2BmG0z0HUmNt13QCCvutuRVjpcR0NjRL12k-WbWzkRg%40mail.gmail.com%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7Ca8634bb0be8d4b0de8c108d8c9dbb81c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637481292814972959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8rylgsXhWvQT5zwt1Sc2Nb2IQR%2Fkd16ErIHfZ4PErZI%3D&reserved=0
Cc: Jason Gunthorpe 
Cc: Suren Baghdasaryan 
Cc: Matthew Wilcox 
Cc: John Stultz 
Signed-off-by: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org


Acked-by: Christian König 


---
  drivers/dma-buf/dma-buf.c | 15 +--
  1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..06cb1d2e9fdc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -127,6 +127,7 @@ static struct file_system_type dma_buf_fs_type = {
  static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct 
*vma)
  {
struct dma_buf *dmabuf;
+   int ret;
  
  	if (!is_dma_buf_file(file))

return -EINVAL;
@@ -142,7 +143,11 @@ static int dma_buf_mmap_internal(struct file *file, struct 
vm_area_struct *vma)
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
  
-	return dmabuf->ops->mmap(dmabuf, vma);

+   ret = dmabuf->ops->mmap(dmabuf, vma);
+
+   WARN_ON(!(vma->vm_flags & VM_PFNMAP));
+
+   return ret;
  }
  
  static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)

@@ -1244,6 +1249,8 @@ EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
  int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
 unsigned long pgoff)
  {
+   int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
  
@@ -1264,7 +1271,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,

vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
  
-	return dmabuf->ops->mmap(dmabuf, vma);

+   ret = dmabuf->ops->mmap(dmabuf, vma);
+
+   WARN_ON(!(vma->vm_flags & VM_PFNMAP));
+
+   return ret;
  }
  EXPORT_SYMBOL_GPL(dma_buf_mmap);
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/3] dt-bindings:drm/bridge:anx7625:add vendor define flags

[Xin Ji]

On Thu, Feb 04, 2021 at 01:38:36PM +0100, Robert Foss wrote:
> Hey Xin,
> 
> On Thu, 28 Jan 2021 at 04:10, Xin Ji  wrote:
> >
> > Add 'bus-type' and 'data-lanes' define for port0, add HDCP support
> > flag and DP tx lane0 and lane1 swing register array define.
> >
> > Signed-off-by: Xin Ji 
> > ---
> >  .../bindings/display/bridge/analogix,anx7625.yaml  | 54 
> > +-
> >  1 file changed, 53 insertions(+), 1 deletion(-)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
> > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > index c789784..048deec 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > @@ -34,6 +34,24 @@ properties:
> >  description: used for reset chip control, RESET_N pin B7.
> >  maxItems: 1
> >
> > +  analogix,lane0-swing:
> > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > +maxItems: 20
> > +description:
> > +  an array of swing register setting for DP tx lane0 PHY, please don't
> > +  add this property, or contact vendor.
> > +
> > +  analogix,lane1-swing:
> > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > +maxItems: 20
> > +description:
> > +  an array of swing register setting for DP tx lane1 PHY, please don't
> > +  add this property, or contact vendor.
> > +
> > +  analogix,hdcp-support:
> > +type: boolean
> > +description: indicate the DP tx HDCP support or not.
> > +
> >ports:
> >  $ref: /schemas/graph.yaml#/properties/ports
> >
> > @@ -41,13 +59,45 @@ properties:
> >port@0:
> >  $ref: /schemas/graph.yaml#/properties/port
> >  description:
> > -  Video port for MIPI DSI input.
> > +  Video port for MIPI input.
> 
> Maybe MIPI DSI/DPI input is more correct, since there are a lot of
> other MIPI standards.
Hi Rob, OK, I'll change it in the next series.
Thanks,
Xin
> 
> > +
> > +properties:
> > +  endpoint:
> > +type: object
> > +additionalProperties: false
> > +
> > +# Properties described in
> > +# Documentation/devicetree/bindings/media/video-interfaces.txt
> > +properties:
> > +  remote-endpoint: true
> > +  bus-type: true
> > +  data-lanes: true
> > +
> > +required:
> > +  - remote-endpoint
> > +
> > +required:
> > +  - endpoint
> > +
> >
> >port@1:
> >  $ref: /schemas/graph.yaml#/properties/port
> >  description:
> >Video port for panel or connector.
> >
> > +properties:
> > +  endpoint:
> > +type: object
> > +additionalProperties: false
> > +
> > +# Properties described in
> > +# Documentation/devicetree/bindings/media/video-interfaces.txt
> > +properties:
> > +  remote-endpoint: true
> > +
> > +required:
> > +  - remote-endpoint
> > +
> >  required:
> >- port@0
> >- port@1
> > @@ -81,6 +131,8 @@ examples:
> >  reg = <0>;
> >  anx7625_in: endpoint {
> >  remote-endpoint = <&mipi_dsi>;
> > +bus-type = <5>;
> > +data-lanes = <0 1 2 3>;
> >  };
> >  };
> >
> > --
> > 2.7.4
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] coresight: etm4x: Fix merge resolution for amba rework

[Uwe Kleine-König]

This was non-trivial to get right because commits
c23bc382ef0e ("coresight: etm4x: Refactor probing routine") and
5214b563588e ("coresight: etm4x: Add support for sysreg only devices")
changed the code flow considerably. With this change the driver can be
built again.

Fixes: 0573d3fa4864 ("Merge branch 'devel-stable' of 
git://git.armlinux.org.uk/~rmk/linux-arm into char-misc-next")
Signed-off-by: Uwe Kleine-König 
---
On Fri, Feb 05, 2021 at 12:07:09PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 05, 2021 at 11:56:15AM +0100, Uwe Kleine-König wrote:
> > I didn't compile test, but I'm willing to bet your resolution is wrong.
> > You have no return statement in etm4_remove_dev() but its return type is
> > int and etm4_remove_amba() still returns int but should return void.
> 
> Can you send a patch to fix this up?

Sure, here it comes. As I'm unsure if you want to squash it into the
merge or want to keep it separate I crafted a commit message. If you
prefer squashing feel free to do so.

This change corresponds to the merge resolution I suggested before.

Best regards
Uwe

 drivers/hwtracing/coresight/coresight-etm4x-core.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c 
b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index bc55b261af23..c8ecd91e289e 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -1906,15 +1906,16 @@ static int __exit etm4_remove_dev(struct etmv4_drvdata 
*drvdata)
cpus_read_unlock();
 
coresight_unregister(drvdata->csdev);
+
+   return 0;
 }
 
-static int __exit etm4_remove_amba(struct amba_device *adev)
+static void __exit etm4_remove_amba(struct amba_device *adev)
 {
struct etmv4_drvdata *drvdata = dev_get_drvdata(&adev->dev);
 
if (drvdata)
-   return etm4_remove_dev(drvdata);
-   return 0;
+   etm4_remove_dev(drvdata);
 }
 
 static int __exit etm4_remove_platform_dev(struct platform_device *pdev)
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel

[Hans Verkuil]

On 05/02/2021 14:24, Ville Syrjälä wrote:
> On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
>> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil  wrote:
>>>
>>> On 01/02/2021 23:13, Ville Syrjälä wrote:
 On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> From: Hans Verkuil 
>
> For adapters behind an MST hub use the correct AUX channel.
>
> Signed-off-by: Hans Verkuil 
> [sa...@chromium.org: rebased, removing redundant changes]
> Signed-off-by: Sam McNally 
> ---
>
> (no changes since v1)
>
>  drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
>  1 file changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 15b6cc39a754..0d753201adbd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct 
> drm_dp_mst_topology_mgr *mgr,
>  drm_dp_mst_topology_put_port(port);
>  }
>
> +static ssize_t
> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
> *msg);
> +
>  static struct drm_dp_mst_port *
>  drm_dp_mst_add_port(struct drm_device *dev,
>  struct drm_dp_mst_topology_mgr *mgr,
> @@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
>  port->port_num = port_number;
>  port->mgr = mgr;
>  port->aux.name = "DPMST";
> +mutex_init(&port->aux.hw_mutex);
> +mutex_init(&port->aux.cec.lock);
>  port->aux.dev = dev->dev;
>  port->aux.is_remote = true;
>
> +port->aux.transfer = drm_dp_mst_aux_transfer;
> +

 This was supposed to be handled via higher levels checking for
 is_remote==true.
>>>
>>> Ah, I suspect this patch can be dropped entirely: it predates commit 
>>> 2f221a5efed4
>>> ("drm/dp_mst: Add MST support to DP DPCD R/W functions").
>>>
>>> It looks like that commit basically solved what this older patch attempts 
>>> to do
>>> as well.
>>>
>>> Sam, can you test if it works without this patch?
>>
>> It almost just works; drm_dp_cec uses whether aux.transfer is non-null
>> to filter out non-DP connectors. Using aux.is_remote as another signal
>> indicating a DP connector seems plausible. We can drop this patch.
> 
> Why would anyone even call this stuff on a non-DP connector?
> And where did they even get the struct drm_dp_aux to do so?

This check came in with commit 5ce70c799ac2 ("drm_dp_cec: check that aux
has a transfer function"). It seems nouveau and amdgpu specific.

A better approach would be to fix those drivers to only call these cec
functions for DP outputs. I think I moved the test to drm_dp_cec.c primarily
for robustness (i.e. do nothing if called for a non-DP output). But that
might not be the right approach after all.

Regards,

Hans

> 
>> Thanks all!
>>>
>>> Regards,
>>>
>>> Hans
>>>

>  /* initialize the MST downstream port's AUX crc work queue */
>  drm_dp_remote_aux_init(&port->aux);
>
> @@ -3503,6 +3510,35 @@ static int drm_dp_send_up_ack_reply(struct 
> drm_dp_mst_topology_mgr *mgr,
>  return 0;
>  }
>
> +static ssize_t
> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
> *msg)
> +{
> +struct drm_dp_mst_port *port =
> +container_of(aux, struct drm_dp_mst_port, aux);
> +int ret;
> +
> +switch (msg->request & ~DP_AUX_I2C_MOT) {
> +case DP_AUX_NATIVE_WRITE:
> +case DP_AUX_I2C_WRITE:
> +case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> +ret = drm_dp_send_dpcd_write(port->mgr, port, msg->address,
> + msg->size, msg->buffer);

 That doesn't make sense to me. I2c writes and DPCD writes
 are definitely not the same thing.

 aux->transfer is a very low level thing. I don't think it's the
 correct level of abstraction for sideband.

> +break;
> +
> +case DP_AUX_NATIVE_READ:
> +case DP_AUX_I2C_READ:
> +ret = drm_dp_send_dpcd_read(port->mgr, port, msg->address,
> +msg->size, msg->buffer);
> +break;
> +
> +default:
> +ret = -EINVAL;
> +break;
> +}
> +
> +return ret;
> +}
> +
>  static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8  dp_link_count)
>  {
>  if (dp_link_bw == 0 || dp_link_count == 0)
> --
> 2.28.0.681.g6f77f65b4e-goog
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

>>>
> 

___
dri-

Re: [RFC] Add BPF_PROG_TYPE_CGROUP_IOCTL

[Daniel Vetter]

Hi Kenny

On Wed, Feb 3, 2021 at 8:01 PM Kenny Ho  wrote:
>
> Daniel,
>
> I will have to get back to you later on the details of this because my
> head is currently context switched to some infrastructure and
> Kubernetes/golang work, so I am having a hard time digesting what you
> are saying.  I am new to the bpf stuff so this is about my own
> learning as well as a conversation starter.  The high level goal here
> is to have a path for flexibility via a bpf program.  Not just GPU or
> DRM or CU mask, but devices making decisions via an operator-written
> bpf-prog attached to a cgroup.  More inline.

If you have some pointers on this, I'm happy to do some reading and
learning too.

> On Wed, Feb 3, 2021 at 6:09 AM Daniel Vetter  wrote:
> >
> > On Mon, Feb 01, 2021 at 11:51:07AM -0500, Kenny Ho wrote:
> > > On Mon, Feb 1, 2021 at 9:49 AM Daniel Vetter  wrote:
> > > > - there's been a pile of cgroups proposal to manage gpus at the drm
> > > >   subsystem level, some by Kenny, and frankly this at least looks a bit
> > > >   like a quick hack to sidestep the consensus process for that.
> > > No Daniel, this is quick *draft* to get a conversation going.  Bpf was
> > > actually a path suggested by Tejun back in 2018 so I think you are
> > > mischaracterizing this quite a bit.
> > >
> > > "2018-11-20 Kenny Ho:
> > > To put the questions in more concrete terms, let say a user wants to
> > >  expose certain part of a gpu to a particular cgroup similar to the
> > >  way selective cpu cores are exposed to a cgroup via cpuset, how
> > >  should we go about enabling such functionality?
> > >
> > > 2018-11-20 Tejun Heo:
> > > Do what the intel driver or bpf is doing?  It's not difficult to hook
> > > into cgroup for identification purposes."
> >
> > Yeah, but if you go full amd specific for this, you might as well have a
> > specific BPF hook which is called in amdgpu/kfd and returns you the CU
> > mask for a given cgroups (and figures that out however it pleases).
> >
> > Not a generic framework which lets you build pretty much any possible
> > cgroups controller for anything else using BPF. Trying to filter anything
> > at the generic ioctl just doesn't feel like a great idea that's long term
> > maintainable. E.g. what happens if there's new uapi for command
> > submission/context creation and now your bpf filter isn't catching all
> > access anymore? If it's an explicit hook that explicitly computes the CU
> > mask, then we can add more checks as needed. With ioctl that's impossible.
> >
> > Plus I'm also not sure whether that's really a good idea still, since if
> > cloud companies have to built their own bespoke container stuff for every
> > gpu vendor, that's quite a bad platform we're building. And "I'd like to
> > make sure my gpu is used fairly among multiple tenents" really isn't a
> > use-case that's specific to amd.
>
> I don't understand what you are saying about containers here since
> bpf-progs are not the same as container nor are they deployed from
> inside a container (as far as I know, I am actually not sure how
> bpf-cgroup works with higher level cloud orchestration since folks
> like Docker just migrated to cgroup v2 very recently... I don't think
> you can specify a bpf-prog to load as part of a k8s pod definition.)
> That said, the bit I understand ("not sure whether that's really a
> good ideacloud companies have to built their own bespoke container
> stuff for every gpu vendor...") is in fact the current status quo.  If
> you look into some of the popular ML/AI-oriented containers/apps, you
> will likely see things are mostly hardcoded to CUDA.  Since I work for
> AMD, I wouldn't say that's a good thing but this is just the reality.
> For Kubernetes at least (where my head is currently), the official
> mechanisms are Device Plugins (I am the author for the one for AMD but
> there are a few ones from Intel too, you can confirm with your
> colleagues)  and Node Feature/Labels.  Kubernetes schedules
> pod/container launched by users to the node/servers by the affinity of
> the node resources/labels, and the resources/labels in the pod
> specification created by the users.

Sure the current gpu compute ecosystem is pretty badly fragmented,
forcing higher levels (like containers, but also hpc runtimes, or
anything else) to paper over that with more plugins and abstraction
layers.

That's not really a good excuse that when we upstream these features,
that we should continue with the fragmentation.

> > If this would be something very hw specific like cache assignment and
> > quality of service stuff or things like that, then vendor specific imo
> > makes sense. But for CU masks essentially we're cutting the compute
> > resources up in some way, and I kinda expect everyone with a gpu who cares
> > about isolating workloads with cgroups wants to do that.
>
> Right, but isolating workloads is quality of service stuff and *how*
> compute resources are cut up are vendor specific.
>
> Anyway, as I sa

Re: [PATCH rdma-core v2 3/3] configure: Add check for the presence of DRM headers

[Daniel Vetter]

On Fri, Feb 5, 2021 at 2:22 PM Jason Gunthorpe  wrote:
>
> On Thu, Feb 04, 2021 at 04:29:14PM -0800, Jianxin Xiong wrote:
> > Compilation of pyverbs/dmabuf_alloc.c depends on a few DRM headers
> > that are installed by either the kernel-header or the libdrm package.
> > The installation is optional and the location is not unique.
> >
> > Check the presence of the headers at both the standard locations and
> > any location defined by custom libdrm installation. If the headers
> > are missing, the dmabuf allocation routines are replaced by stubs that
> > return suitable error to allow the related tests to skip.
> >
> > Signed-off-by: Jianxin Xiong 
> >  CMakeLists.txt  | 15 +++
> >  pyverbs/CMakeLists.txt  | 14 --
> >  pyverbs/dmabuf_alloc.c  |  8 
> >  pyverbs/dmabuf_alloc_stub.c | 39 +++
> >  4 files changed, 70 insertions(+), 6 deletions(-)
> >  create mode 100644 pyverbs/dmabuf_alloc_stub.c
> >
> > diff --git a/CMakeLists.txt b/CMakeLists.txt
> > index 4113423..95aec11 100644
> > +++ b/CMakeLists.txt
> > @@ -515,6 +515,21 @@ find_package(Systemd)
> >  include_directories(${SYSTEMD_INCLUDE_DIRS})
> >  RDMA_DoFixup("${SYSTEMD_FOUND}" "systemd/sd-daemon.h")
> >
> > +# drm headers
> > +
> > +# First check the standard locations. The headers could have been installed
> > +# by either the kernle-headers package or the libdrm package.
> > +find_path(DRM_INCLUDE_DIRS "drm.h" PATH_SUFFIXES "drm" "libdrm")
>
> Is there a reason not to just always call pkg_check_modules?

Note that the gpu-specific libraries are split out, so I'd also check
for those just to be sure - I don't know whether all distros package
the uapi headers consistently in libdrm or sometimes also in one of
the libdrm-$vendor packages.
-Daniel

>
> > +# Then check custom installation of libdrm
> > +if (NOT DRM_INCLUDE_DIRS)
> > +  pkg_check_modules(DRM libdrm)
> > +endif()
> > +
> > +if (DRM_INCLUDE_DIRS)
> > +  include_directories(${DRM_INCLUDE_DIRS})
> > +endif()
>
> This needs a hunk at the end:
>
> if (NOT DRM_INCLUDE_DIRS)
>   message(STATUS " DMABUF NOT supported (disabling some tests)")
> endif()
>
> >  #-
> >  # Apply fixups
> >
> > diff --git a/pyverbs/CMakeLists.txt b/pyverbs/CMakeLists.txt
> > index 6fd7625..922253f 100644
> > +++ b/pyverbs/CMakeLists.txt
> > @@ -13,8 +13,6 @@ rdma_cython_module(pyverbs ""
> >cmid.pyx
> >cq.pyx
> >device.pyx
> > -  dmabuf.pyx
> > -  dmabuf_alloc.c
> >enums.pyx
> >mem_alloc.pyx
> >mr.pyx
> > @@ -25,6 +23,18 @@ rdma_cython_module(pyverbs ""
> >xrcd.pyx
> >  )
> >
> > +if (DRM_INCLUDE_DIRS)
> > +rdma_cython_module(pyverbs ""
> > +  dmabuf.pyx
> > +  dmabuf_alloc.c
> > +)
> > +else()
> > +rdma_cython_module(pyverbs ""
> > +  dmabuf.pyx
> > +  dmabuf_alloc_stub.c
> > +)
> > +endif()
>
> Like this:
>
> if (DRM_INCLUDE_DIRS)
>   set(DMABUF_ALLOC dmabuf_alloc.c)
> else()
>   set(DMABUF_ALLOC dmabuf_alloc_stbub.c)
> endif()
> rdma_cython_module(pyverbs ""
>   dmabuf.pyx
>   $(DMABUF_ALLOC)
> )
>
> Jason
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel

[Ville Syrjälä]

On Fri, Feb 05, 2021 at 02:46:44PM +0100, Hans Verkuil wrote:
> On 05/02/2021 14:24, Ville Syrjälä wrote:
> > On Fri, Feb 05, 2021 at 04:17:51PM +1100, Sam McNally wrote:
> >> On Thu, 4 Feb 2021 at 21:19, Hans Verkuil  wrote:
> >>>
> >>> On 01/02/2021 23:13, Ville Syrjälä wrote:
>  On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> > From: Hans Verkuil 
> >
> > For adapters behind an MST hub use the correct AUX channel.
> >
> > Signed-off-by: Hans Verkuil 
> > [sa...@chromium.org: rebased, removing redundant changes]
> > Signed-off-by: Sam McNally 
> > ---
> >
> > (no changes since v1)
> >
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
> >  1 file changed, 36 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 15b6cc39a754..0d753201adbd 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct 
> > drm_dp_mst_topology_mgr *mgr,
> >  drm_dp_mst_topology_put_port(port);
> >  }
> >
> > +static ssize_t
> > +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
> > *msg);
> > +
> >  static struct drm_dp_mst_port *
> >  drm_dp_mst_add_port(struct drm_device *dev,
> >  struct drm_dp_mst_topology_mgr *mgr,
> > @@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
> >  port->port_num = port_number;
> >  port->mgr = mgr;
> >  port->aux.name = "DPMST";
> > +mutex_init(&port->aux.hw_mutex);
> > +mutex_init(&port->aux.cec.lock);
> >  port->aux.dev = dev->dev;
> >  port->aux.is_remote = true;
> >
> > +port->aux.transfer = drm_dp_mst_aux_transfer;
> > +
> 
>  This was supposed to be handled via higher levels checking for
>  is_remote==true.
> >>>
> >>> Ah, I suspect this patch can be dropped entirely: it predates commit 
> >>> 2f221a5efed4
> >>> ("drm/dp_mst: Add MST support to DP DPCD R/W functions").
> >>>
> >>> It looks like that commit basically solved what this older patch attempts 
> >>> to do
> >>> as well.
> >>>
> >>> Sam, can you test if it works without this patch?
> >>
> >> It almost just works; drm_dp_cec uses whether aux.transfer is non-null
> >> to filter out non-DP connectors. Using aux.is_remote as another signal
> >> indicating a DP connector seems plausible. We can drop this patch.
> > 
> > Why would anyone even call this stuff on a non-DP connector?
> > And where did they even get the struct drm_dp_aux to do so?
> 
> This check came in with commit 5ce70c799ac2 ("drm_dp_cec: check that aux
> has a transfer function"). It seems nouveau and amdgpu specific.

I see.

> 
> A better approach would be to fix those drivers to only call these cec
> functions for DP outputs. I think I moved the test to drm_dp_cec.c primarily
> for robustness (i.e. do nothing if called for a non-DP output). But that
> might not be the right approach after all.

Shrug. I guess just extending to check is_remote (or maybe there is
some other member that's always set?) is a good enough short term
solution. Someone may want to have a look at adjusting
amdgpu/nouveau to not need it, but who knows how much work that is.

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: manual merge of the drivers-x86 tree with the drm-misc tree

[Andy Shevchenko]

On Fri, Feb 5, 2021 at 3:05 PM Daniel Vetter  wrote:
> On Fri, Feb 5, 2021 at 12:14 PM Patrik Jakobsson
>  wrote:
> >
> > On Fri, Feb 5, 2021 at 12:07 PM Andy Shevchenko
> >  wrote:
> > >
> > > On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko
> > >  wrote:
> > > >> Today's linux-next merge of the drivers-x86 tree got a conflict in:
> > > >
> > > > Thanks. I already asked Patrik yesterday day if DRM missed to pull an 
> > > > immutable tag I provided. I think they can pull and resolve conflicts 
> > > > themselves. Alternatively it would be easy to resolve by Linus by 
> > > > removing Kconfig lines along with mentioned files,
> > >
> > > Patrik, I have sent a PR again, so you may consider pulling it, thanks!
> >
> > Daniel, is this something you can pull into drm or ask one of the
> > drm-misc maintainers to do?
>
> We've already created the conflict, and my understanding is that Linus
> wants to have visibility into conflict-y stuff and doesn't mind at all
> resolving conflicts. Hence for 5.12 I think we're fine as-is.

Fine with me!

-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] coresight: etm4x: Fix merge resolution for amba rework

[Greg Kroah-Hartman]

On Fri, Feb 05, 2021 at 02:08:47PM +0100, Uwe Kleine-König wrote:
> This was non-trivial to get right because commits
> c23bc382ef0e ("coresight: etm4x: Refactor probing routine") and
> 5214b563588e ("coresight: etm4x: Add support for sysreg only devices")
> changed the code flow considerably. With this change the driver can be
> built again.
> 
> Fixes: 0573d3fa4864 ("Merge branch 'devel-stable' of 
> git://git.armlinux.org.uk/~rmk/linux-arm into char-misc-next")
> Signed-off-by: Uwe Kleine-König 

Now queued up, thanks!

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC/PATCH 07/11] drm/v3d: Get rid of pm code

[Nicolas Saenz Julienne]

Runtime PM doesn't seem to work correctly on this driver. On top of
that, commit 8b6864e3e138 (drm/v3d/v3d_drv: Remove unused static
variable 'v3d_v3d_pm_ops') hints that it most likely never did properly
as the driver's PM ops were not hooked-up.

So, in order to support regular operation with V3D on BCM2711 (Raspberry
Pi 4), get rid of the PM code. PM will be reinstated once we figure out
the underlying issues.

Signed-off-by: Nicolas Saenz Julienne 
---
 drivers/gpu/drm/v3d/v3d_debugfs.c | 18 +-
 drivers/gpu/drm/v3d/v3d_drv.c | 11 ---
 drivers/gpu/drm/v3d/v3d_gem.c |  9 -
 3 files changed, 1 insertion(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c 
b/drivers/gpu/drm/v3d/v3d_debugfs.c
index e76b24bb8828..e1d5f3423059 100644
--- a/drivers/gpu/drm/v3d/v3d_debugfs.c
+++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
@@ -4,7 +4,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -130,11 +129,7 @@ static int v3d_v3d_debugfs_ident(struct seq_file *m, void 
*unused)
struct drm_device *dev = node->minor->dev;
struct v3d_dev *v3d = to_v3d_dev(dev);
u32 ident0, ident1, ident2, ident3, cores;
-   int ret, core;
-
-   ret = pm_runtime_get_sync(v3d->drm.dev);
-   if (ret < 0)
-   return ret;
+   int core;
 
ident0 = V3D_READ(V3D_HUB_IDENT0);
ident1 = V3D_READ(V3D_HUB_IDENT1);
@@ -187,9 +182,6 @@ static int v3d_v3d_debugfs_ident(struct seq_file *m, void 
*unused)
   (misccfg & V3D_MISCCFG_OVRTMUOUT) != 0);
}
 
-   pm_runtime_mark_last_busy(v3d->drm.dev);
-   pm_runtime_put_autosuspend(v3d->drm.dev);
-
return 0;
 }
 
@@ -217,11 +209,6 @@ static int v3d_measure_clock(struct seq_file *m, void 
*unused)
uint32_t cycles;
int core = 0;
int measure_ms = 1000;
-   int ret;
-
-   ret = pm_runtime_get_sync(v3d->drm.dev);
-   if (ret < 0)
-   return ret;
 
if (v3d->ver >= 40) {
V3D_CORE_WRITE(core, V3D_V4_PCTR_0_SRC_0_3,
@@ -245,9 +232,6 @@ static int v3d_measure_clock(struct seq_file *m, void 
*unused)
   cycles / (measure_ms * 1000),
   (cycles / (measure_ms * 100)) % 10);
 
-   pm_runtime_mark_last_busy(v3d->drm.dev);
-   pm_runtime_put_autosuspend(v3d->drm.dev);
-
return 0;
 }
 
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 99e22beea90b..7a3336443a12 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -43,7 +42,6 @@ static int v3d_get_param_ioctl(struct drm_device *dev, void 
*data,
 {
struct v3d_dev *v3d = to_v3d_dev(dev);
struct drm_v3d_get_param *args = data;
-   int ret;
static const u32 reg_map[] = {
[DRM_V3D_PARAM_V3D_UIFCFG] = V3D_HUB_UIFCFG,
[DRM_V3D_PARAM_V3D_HUB_IDENT1] = V3D_HUB_IDENT1,
@@ -69,17 +67,12 @@ static int v3d_get_param_ioctl(struct drm_device *dev, void 
*data,
if (args->value != 0)
return -EINVAL;
 
-   ret = pm_runtime_get_sync(v3d->drm.dev);
-   if (ret < 0)
-   return ret;
if (args->param >= DRM_V3D_PARAM_V3D_CORE0_IDENT0 &&
args->param <= DRM_V3D_PARAM_V3D_CORE0_IDENT2) {
args->value = V3D_CORE_READ(0, offset);
} else {
args->value = V3D_READ(offset);
}
-   pm_runtime_mark_last_busy(v3d->drm.dev);
-   pm_runtime_put_autosuspend(v3d->drm.dev);
return 0;
}
 
@@ -271,10 +264,6 @@ static int v3d_platform_drm_probe(struct platform_device 
*pdev)
return -ENOMEM;
}
 
-   pm_runtime_use_autosuspend(dev);
-   pm_runtime_set_autosuspend_delay(dev, 50);
-   pm_runtime_enable(dev);
-
ret = v3d_gem_init(drm);
if (ret)
goto dma_free;
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 4eb354226972..75582b03470b 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -6,7 +6,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -372,9 +371,6 @@ v3d_job_free(struct kref *ref)
dma_fence_put(job->irq_fence);
dma_fence_put(job->done_fence);
 
-   pm_runtime_mark_last_busy(job->v3d->drm.dev);
-   pm_runtime_put_autosuspend(job->v3d->drm.dev);
-
kfree(job);
 }
 
@@ -441,10 +437,6 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file 
*file_priv,
job->v3d = v3d;
job->free = free;
 
-   ret = pm_runtime_get_sync(v3d->drm.dev);
-   if (ret < 0)
-   return ret;
-
xa_init_flags(&job->deps, XA_FLAGS_ALLOC);
 
ret = drm_syncobj_find_fence

[RFC/PATCH 08/11] drm/v3d: Add support for bcm2711

[Nicolas Saenz Julienne]

Add compatible string and Kconfig options for bcm2711.

Signed-off-by: Nicolas Saenz Julienne 
---
 drivers/gpu/drm/v3d/Kconfig   | 2 +-
 drivers/gpu/drm/v3d/v3d_drv.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig
index 9a5c44606337..b0e048697964 100644
--- a/drivers/gpu/drm/v3d/Kconfig
+++ b/drivers/gpu/drm/v3d/Kconfig
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config DRM_V3D
tristate "Broadcom V3D 3.x and newer"
-   depends on ARCH_BCM || ARCH_BCMSTB || COMPILE_TEST
+   depends on ARCH_BCM || ARCH_BCMSTB || ARCH_BCM2835 || COMPILE_TEST
depends on DRM
depends on COMMON_CLK
depends on MMU
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 7a3336443a12..1504b6f84441 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -184,6 +184,7 @@ static const struct drm_driver v3d_drm_driver = {
 static const struct of_device_id v3d_of_match[] = {
{ .compatible = "brcm,7268-v3d" },
{ .compatible = "brcm,7278-v3d" },
+   { .compatible = "brcm,bcm2711-v3d" },
{},
 };
 MODULE_DEVICE_TABLE(of, v3d_of_match);
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC/PATCH 00/11] Raspberry PI 4 V3D enablement

[Nicolas Saenz Julienne]

This series attempts to enable V3D on BCM2711, the SoC available on the
Raspberry Pi 4 family of boards.

Due to the lack of documentation some things are taken as it from
testing/downstream implementation[1], which I'm hilighting here:

- It's not clear that the following is 100% true, maybe someone can confirm:

"In BCM2711 the new ARGON ASB took over V3D. The old ASB is still
present with the ISP and H264 bits, and V3D is in the same place in the
new ASB as the old one."

- Patch #6 I took as is from the downstream implementation, I can't really
  provide an exact explanation on what changed HW wise.

Ultimately, I need confirmation from the Broadcom folks that they are alright
with patch #7.

With all this, I get a more or less stable experience using mesa 20.3.4 and
X11/Gnome.

Regards,
Nicolas

---

Nicolas Saenz Julienne (11):
  dt-bindings: soc: bcm: bcm2835-pm: Convert bindings to DT schema
  dt-bindings: soc: bcm: brcm,bcm2835-pm: Add support for bcm2711
  ARM: dts: bcm2711: Use proper compatible in PM/Watchdog node
  mfd: bcm2835-pm: Add support for BCM2711
  soc: bcm: bcm2835-power: Add support for BCM2711's ARSAN ASB
  soc: bcm: bcm2835-power: Bypass power_on/off() calls
  drm/v3d: Get rid of pm code
  drm/v3d: Add support for bcm2711
  ARM: dts: bcm2711: Enable V3D
  ARM: configs: Enable DRM_V3D
  arm64: config: Enable DRM_V3D

 .../bindings/soc/bcm/brcm,bcm2835-pm.txt  | 46 ---
 .../bindings/soc/bcm/brcm,bcm2835-pm.yaml | 80 +++
 arch/arm/boot/dts/bcm2711.dtsi| 14 +++-
 arch/arm/configs/multi_v7_defconfig   |  1 +
 arch/arm64/configs/defconfig  |  1 +
 drivers/gpu/drm/v3d/Kconfig   |  2 +-
 drivers/gpu/drm/v3d/v3d_debugfs.c | 18 +
 drivers/gpu/drm/v3d/v3d_drv.c | 12 +--
 drivers/gpu/drm/v3d/v3d_gem.c |  9 ---
 drivers/mfd/bcm2835-pm.c  | 55 ++---
 drivers/soc/bcm/bcm2835-power.c   | 74 +++--
 include/linux/mfd/bcm2835-pm.h|  1 +
 12 files changed, 190 insertions(+), 123 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt
 create mode 100644 
Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml

-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [kraxel:drm-testing 11/15] ERROR: modpost: "drm_gem_vunmap" undefined!

[Thomas Zimmermann]

Am 05.02.21 um 14:22 schrieb Thomas Zimmermann:

All errors (new ones prefixed by >>, old ones prefixed by <<):

ERROR: modpost: "drm_gem_vunmap" [drivers/gpu/drm/drm_kms_helper.ko] 
undefined!
ERROR: modpost: "drm_gem_vmap" [drivers/gpu/drm/drm_kms_helper.ko] 
undefined!


These are in drm_gem.c and build unconditionally. It's not clear to me 
how this can fail. Ideas, anyone?


Oh, they are not exported. Can we export them?



Best regards
Thomas



---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org





--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][V2] drm/mgag200: make a const array static, makes object smaller

[Thomas Zimmermann]

Merged.

Am 04.02.21 um 20:11 schrieb Colin King:

From: Colin Ian King 

Don't populate the const array m_div_val on the stack but instead make
it static. Makes the object code smaller by 29 bytes:

Before:
text   data   bss   dechex filename
   34736   4552 0 39288   9978 
drivers/gpu/drm/mgag200/mgag200_mode.o

After:
text   data   bss   dechex filename
   34625   4616 0 39241   9949 
drivers/gpu/drm/mgag200/mgag200_mode.o

(gcc version 10.2.0)

Signed-off-by: Colin Ian King 
Reviewed-by: Thomas Zimmermann 
---

V2: move static declaration to the top of the declarations

---
  drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 1dfc42170059..c3dfde8cad25 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -706,13 +706,13 @@ static int mga_g200eh_set_plls(struct mga_device *mdev, 
long clock)
  
  static int mga_g200er_set_plls(struct mga_device *mdev, long clock)

  {
+   static const unsigned int m_div_val[] = { 1, 2, 4, 8 };
unsigned int vcomax, vcomin, pllreffreq;
unsigned int delta, tmpdelta;
int testr, testn, testm, testo;
unsigned int p, m, n;
unsigned int computed, vco;
int tmp;
-   const unsigned int m_div_val[] = { 1, 2, 4, 8 };
  
  	m = n = p = 0;

vcomax = 1488000;



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances

[Deucher, Alexander]

[AMD Official Use Only - Internal Distribution Only]

Good question.  I think push it to drm-misc-next for upstream.  We can carry it 
internally in amd-staging-drm-next for internal testing and I can coordinate 
with drm-next.  I think the amdgpu changes are pretty straightforward, so 
shouldn't be too hard keep the merge straight.  I dunno.

Alex


From: Christian König 
Sent: Friday, February 5, 2021 4:58 AM
To: Liu, Leo ; amd-...@lists.freedesktop.org 
; dri-devel@lists.freedesktop.org 
; Deucher, Alexander 

Subject: Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances

Alex how do we want to merge this?

I've just pushed the first patch to drm-misc-next since that needed a
rebase because it touches other drivers as well.

But the rest is really AMD specific and I'm not sure if the dependent
stuff is already in there as well.

So if I push it to drm-misc-next you will probably need to merge and if
I push it to amd-staging-drm-next somebody else might need to merge when
drm-misc-next is merged.

Ideas?

Christian.

Am 04.02.21 um 19:34 schrieb Leo Liu:
> The series are:
>
> Reviewed-and-Tested-by: Leo Liu 
>
>
> On 2021-02-04 9:44 a.m., Christian König wrote:
>> The VCN3 instances can do both decode as well as encode.
>>
>> Share the scheduler load balancing score and remove fixing encode to
>> only the second instance.
>>
>> Signed-off-by: Christian König 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h |  1 +
>>   drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c   | 11 +++
>>   2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> index 13aa417f6be7..d10bc4f0a05f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> @@ -211,6 +211,7 @@ struct amdgpu_vcn_inst {
>>   void*saved_bo;
>>   struct amdgpu_ringring_dec;
>>   struct amdgpu_ringring_enc[AMDGPU_VCN_MAX_ENC_RINGS];
>> +atomic_tsched_score;
>>   struct amdgpu_irq_srcirq;
>>   struct amdgpu_vcn_regexternal;
>>   struct amdgpu_bo*dpg_sram_bo;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> index 239a4eb52c61..b33f513fd2ac 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> @@ -171,6 +171,7 @@ static int vcn_v3_0_sw_init(void *handle)
>> for (i = 0; i < adev->vcn.num_vcn_inst; i++) {
>>   volatile struct amdgpu_fw_shared *fw_shared;
>> +
>>   if (adev->vcn.harvest_config & (1 << i))
>>   continue;
>>   @@ -198,6 +199,8 @@ static int vcn_v3_0_sw_init(void *handle)
>>   if (r)
>>   return r;
>>   +atomic_set(&adev->vcn.inst[i].sched_score, 0);
>> +
>>   ring = &adev->vcn.inst[i].ring_dec;
>>   ring->use_doorbell = true;
>>   if (amdgpu_sriov_vf(adev)) {
>> @@ -209,7 +212,8 @@ static int vcn_v3_0_sw_init(void *handle)
>>   ring->no_scheduler = true;
>>   sprintf(ring->name, "vcn_dec_%d", i);
>>   r = amdgpu_ring_init(adev, ring, 512,
>> &adev->vcn.inst[i].irq, 0,
>> - AMDGPU_RING_PRIO_DEFAULT, NULL);
>> + AMDGPU_RING_PRIO_DEFAULT,
>> + &adev->vcn.inst[i].sched_score);
>>   if (r)
>>   return r;
>>   @@ -227,11 +231,10 @@ static int vcn_v3_0_sw_init(void *handle)
>>   } else {
>>   ring->doorbell_index =
>> (adev->doorbell_index.vcn.vcn_ring0_1 << 1) + 2 + j + 8 * i;
>>   }
>> -if (adev->asic_type == CHIP_SIENNA_CICHLID && i != 1)
>> -ring->no_scheduler = true;
>>   sprintf(ring->name, "vcn_enc_%d.%d", i, j);
>>   r = amdgpu_ring_init(adev, ring, 512,
>> &adev->vcn.inst[i].irq, 0,
>> - AMDGPU_RING_PRIO_DEFAULT, NULL);
>> + AMDGPU_RING_PRIO_DEFAULT,
>> + &adev->vcn.inst[i].sched_score);
>>   if (r)
>>   return r;
>>   }

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances

[Christian König]

The alternative is to wait till drm-misc-next is merged into drm-next, 
then rebase amd-staging-drm-next on top of that (or directly 
drm-misc-next) and push then.


Would give us at least a clean history. Question is rather if we want it 
in 5.12?


Christian.

Am 05.02.21 um 15:50 schrieb Deucher, Alexander:


[AMD Official Use Only - Internal Distribution Only]


Good question.  I think push it to drm-misc-next for upstream.  We can 
carry it internally in amd-staging-drm-next for internal testing and I 
can coordinate with drm-next.  I think the amdgpu changes are pretty 
straightforward, so shouldn't be too hard keep the merge straight.  I 
dunno.


Alex


*From:* Christian König 
*Sent:* Friday, February 5, 2021 4:58 AM
*To:* Liu, Leo ; amd-...@lists.freedesktop.org 
; dri-devel@lists.freedesktop.org 
; Deucher, Alexander 

*Subject:* Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 
instances

Alex how do we want to merge this?

I've just pushed the first patch to drm-misc-next since that needed a
rebase because it touches other drivers as well.

But the rest is really AMD specific and I'm not sure if the dependent
stuff is already in there as well.

So if I push it to drm-misc-next you will probably need to merge and if
I push it to amd-staging-drm-next somebody else might need to merge when
drm-misc-next is merged.

Ideas?

Christian.

Am 04.02.21 um 19:34 schrieb Leo Liu:
> The series are:
>
> Reviewed-and-Tested-by: Leo Liu 
>
>
> On 2021-02-04 9:44 a.m., Christian König wrote:
>> The VCN3 instances can do both decode as well as encode.
>>
>> Share the scheduler load balancing score and remove fixing encode to
>> only the second instance.
>>
>> Signed-off-by: Christian König 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h |  1 +
>>   drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c   | 11 +++
>>   2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> index 13aa417f6be7..d10bc4f0a05f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> @@ -211,6 +211,7 @@ struct amdgpu_vcn_inst {
>>   void    *saved_bo;
>>   struct amdgpu_ring    ring_dec;
>>   struct amdgpu_ring ring_enc[AMDGPU_VCN_MAX_ENC_RINGS];
>> +    atomic_t    sched_score;
>>   struct amdgpu_irq_src    irq;
>>   struct amdgpu_vcn_reg    external;
>>   struct amdgpu_bo    *dpg_sram_bo;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> index 239a4eb52c61..b33f513fd2ac 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> @@ -171,6 +171,7 @@ static int vcn_v3_0_sw_init(void *handle)
>>     for (i = 0; i < adev->vcn.num_vcn_inst; i++) {
>>   volatile struct amdgpu_fw_shared *fw_shared;
>> +
>>   if (adev->vcn.harvest_config & (1 << i))
>>   continue;
>>   @@ -198,6 +199,8 @@ static int vcn_v3_0_sw_init(void *handle)
>>   if (r)
>>   return r;
>>   + atomic_set(&adev->vcn.inst[i].sched_score, 0);
>> +
>>   ring = &adev->vcn.inst[i].ring_dec;
>>   ring->use_doorbell = true;
>>   if (amdgpu_sriov_vf(adev)) {
>> @@ -209,7 +212,8 @@ static int vcn_v3_0_sw_init(void *handle)
>>   ring->no_scheduler = true;
>>   sprintf(ring->name, "vcn_dec_%d", i);
>>   r = amdgpu_ring_init(adev, ring, 512,
>> &adev->vcn.inst[i].irq, 0,
>> - AMDGPU_RING_PRIO_DEFAULT, NULL);
>> + AMDGPU_RING_PRIO_DEFAULT,
>> + &adev->vcn.inst[i].sched_score);
>>   if (r)
>>   return r;
>>   @@ -227,11 +231,10 @@ static int vcn_v3_0_sw_init(void *handle)
>>   } else {
>>   ring->doorbell_index =
>> (adev->doorbell_index.vcn.vcn_ring0_1 << 1) + 2 + j + 8 * i;
>>   }
>> -    if (adev->asic_type == CHIP_SIENNA_CICHLID && i != 1)
>> -    ring->no_scheduler = true;
>>   sprintf(ring->name, "vcn_enc_%d.%d", i, j);
>>   r = amdgpu_ring_init(adev, ring, 512,
>> &adev->vcn.inst[i].irq, 0,
>> - AMDGPU_RING_PRIO_DEFAULT, NULL);
>> + AMDGPU_RING_PRIO_DEFAULT,
>> + &adev->vcn.inst[i].sched_score);
>>   if (r)
>>   return r;
>>   }



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] Support second Image Signal Processor on rk3399

[Heiko Stübner]

Hi Sebastian,

I did some tests myself today as well and can confirm your
hdmi related finding - at least when plugged in on boot.

I tried some combinations of camera vs. hdmi and it seems
really only when hdmi is plugged in on boot

(1)
- boot
- camera
--> works

(2)
- boot
- camera
- hdmi plugged in
- hdmi works
- camera
--> works

(3)
- hdmi plugged in
- boot
- hdmi works
- camera
--> camera doesn't work

(4)
- boot
- hdmi plugged in
- hdmi works
- camera
-> camera works


With a bit of brute-force [0] it seems the camera also works again even
with hdmi connected on boot. So conclusion would be that some clock
is misbehaving.

Now we'll "only" need to find out which one that is.


Heiko


[0]
Don't disable any clock gates

diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 070dc47e95a1..8daf1fc3388c 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -61,6 +61,9 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)
 
set ^= enable;
 
+if (!enable)
+return;
+
if (gate->lock)
spin_lock_irqsave(gate->lock, flags);
else



Am Freitag, 5. Februar 2021, 09:15:47 CET schrieb Heiko Stübner:
> Hi Sebastian,
> 
> Am Freitag, 5. Februar 2021, 07:43:35 CET schrieb Sebastian Fricke:
> > On 03.02.2021 20:54, Heiko Stübner wrote:
> > >Am Mittwoch, 3. Februar 2021, 19:14:22 CET schrieb Sebastian Fricke:
> > >> I have tested your patch set on my nanoPC-T4, here is a complete log
> > >> with:
> > >> - relevant kernel log entries
> > >> - system information
> > >> - media ctl output
> > >> - sysfs entry information
> > >>
> > >> https://paste.debian.net/1183874/
> > >>
> > >> Additionally, to your patchset I have applied the following patches:
> > >> https://github.com/initBasti/Linux_kernel_media_tree_fork/commits/dual_cam_setup
> > >>
> > >> And just to not cause confusion the `media_dev` entries come from this
> > >> unmerged series:
> > >> https://patchwork.kernel.org/project/linux-media/list/?series=426269
> > >>
> > >> I have actually been able to stream with both of my cameras at the same
> > >> time using the libcamera cam command.
> > >> I would like to thank you a lot for making this possible.
> > >
> > >Thanks for testing a dual camera setup. On my board I could only test
> > >the second ISP. And really glad it works for you tool :-) .
> > >
> > >Out of curiosity, do you also see that green tint in the images the cameras
> > >produce?
> > 
> > Yes, I do. Actually, I currently have two forms of a green tint, on my
> > OV13850 everything is quite dark and greenish, which is caused by the
> > missing 3A algorithms. On my OV4689, I have big patches of the image
> > with bright green color and flickering, I investigated if this is
> > connected to the 2nd ISP instance, but that doesn't seem to be the case
> > as I have the same results when I switch the CSI ports of the cameras.
> > 
> > I have found another issue, while testing I discovered following
> > issue:
> > When I start the system with an HDMI monitor connected, then the camera
> > on the 2nd port doesn't work. This is probably because the RX/TX is
> > reserved as a TX.
> > But it made me wonder because if the system has an RX, a TX, and
> > an RX/TX, why isn't the pure TX used by the monitor and the
> > cameras take RX and RX/TX?
> > Or do you think that this is maybe a malfunction of this patch?
> 
> I don't think it is an issue with this specific series, but still puzzling.
> 
> I.e. the DPHYs are actually only relevant to the DSI controllers,
> with TX0 being connected to DSI0 and TX1RX1 being connected
> to DSI1. So having an hdmi display _in theory_ shouldn't matter at all.
> 
> Out of curiosity what happens, when you boot without hdmi connected
> turn on the cameras, connect the hdmi after this, try the cameras again?
> 
> 
> Heiko
> 
> > 
> > >
> > >Thanks
> > >Heiko
> > 
> > Greetings,
> > Sebastian
> > 
> > >
> > >
> > >> If you like to you can add:
> > >> Tested-by: Sebastian Fricke 
> > >>
> > >> On 02.02.2021 15:56, Heiko Stuebner wrote:
> > >> >The rk3399 has two ISPs and right now only the first one is usable.
> > >> >The second ISP is connected to the TXRX dphy on the soc.
> > >> >
> > >> >The phy of ISP1 is only accessible through the DSI controller's
> > >> >io-memory, so this series adds support for simply using the dsi
> > >> >controller is a phy if needed.
> > >> >
> > >> >That solution is needed at least on rk3399 and rk3288 but no-one
> > >> >has looked at camera support on rk3288 at all, so right now
> > >> >only implement the rk3399 specifics.
> > >> >
> > >> >
> > >> >Heiko Stuebner (6):
> > >> >  drm/rockchip: dsi: add own additional pclk handling
> > >> >  dt-bindings: display: rockchip-dsi: add optional #phy-cells property
> > >> >  drm/rockchip: dsi: add ability to work as a phy instead of full dsi
> > >> >  arm64: dts: rockchip: add #phy-cells to mipi-dsi1
> > >> >  arm64: dts: rockchip: add cif clk-control pinctrl for rk3399
> > >> >  arm64: d

[PATCH v2 4/7] drm/mgag200: Move vmap out of commit tail

[Thomas Zimmermann]

Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.

The mapping is provided as GEM shadow-buffered plane. The functions in
the commit tail use the pre-established mapping for damage handling.

Signed-off-by: Thomas Zimmermann 
Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 23 ---
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 1dfc42170059..f871753e898e 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1549,22 +1550,12 @@ mgag200_simple_display_pipe_mode_valid(struct 
drm_simple_display_pipe *pipe,
 
 static void
 mgag200_handle_damage(struct mga_device *mdev, struct drm_framebuffer *fb,
- struct drm_rect *clip)
+ struct drm_rect *clip, const struct dma_buf_map *map)
 {
-   struct drm_device *dev = &mdev->base;
-   struct dma_buf_map map;
-   void *vmap;
-   int ret;
-
-   ret = drm_gem_shmem_vmap(fb->obj[0], &map);
-   if (drm_WARN_ON(dev, ret))
-   return; /* BUG: SHMEM BO should always be vmapped */
-   vmap = map.vaddr; /* TODO: Use mapping abstraction properly */
+   void *vmap = map->vaddr; /* TODO: Use mapping abstraction properly */
 
drm_fb_memcpy_dstclip(mdev->vram, vmap, fb, clip);
 
-   drm_gem_shmem_vunmap(fb->obj[0], &map);
-
/* Always scanout image at VRAM offset 0 */
mgag200_set_startadd(mdev, (u32)0);
mgag200_set_offset(mdev, fb);
@@ -1580,6 +1571,7 @@ mgag200_simple_display_pipe_enable(struct 
drm_simple_display_pipe *pipe,
struct mga_device *mdev = to_mga_device(dev);
struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode;
struct drm_framebuffer *fb = plane_state->fb;
+   struct drm_shadow_plane_state *shadow_plane_state = 
to_drm_shadow_plane_state(plane_state);
struct drm_rect fullscreen = {
.x1 = 0,
.x2 = fb->width,
@@ -1608,7 +1600,7 @@ mgag200_simple_display_pipe_enable(struct 
drm_simple_display_pipe *pipe,
mga_crtc_load_lut(crtc);
mgag200_enable_display(mdev);
 
-   mgag200_handle_damage(mdev, fb, &fullscreen);
+   mgag200_handle_damage(mdev, fb, &fullscreen, 
&shadow_plane_state->map[0]);
 }
 
 static void
@@ -1649,6 +1641,7 @@ mgag200_simple_display_pipe_update(struct 
drm_simple_display_pipe *pipe,
struct drm_device *dev = plane->dev;
struct mga_device *mdev = to_mga_device(dev);
struct drm_plane_state *state = plane->state;
+   struct drm_shadow_plane_state *shadow_plane_state = 
to_drm_shadow_plane_state(state);
struct drm_framebuffer *fb = state->fb;
struct drm_rect damage;
 
@@ -1656,7 +1649,7 @@ mgag200_simple_display_pipe_update(struct 
drm_simple_display_pipe *pipe,
return;
 
if (drm_atomic_helper_damage_merged(old_state, state, &damage))
-   mgag200_handle_damage(mdev, fb, &damage);
+   mgag200_handle_damage(mdev, fb, &damage, 
&shadow_plane_state->map[0]);
 }
 
 static const struct drm_simple_display_pipe_funcs
@@ -1666,7 +1659,7 @@ mgag200_simple_display_pipe_funcs = {
.disable= mgag200_simple_display_pipe_disable,
.check  = mgag200_simple_display_pipe_check,
.update = mgag200_simple_display_pipe_update,
-   .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
+   DRM_GEM_SIMPLE_DISPLAY_PIPE_SHADOW_PLANE_FUNCS,
 };
 
 static const uint32_t mgag200_simple_display_pipe_formats[] = {
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/7] drm/gem: Export drm_gem_vmap() and drm_gem_vunmap()

[Thomas Zimmermann]

The symbols will be required by the upcoming helpers for shadow-buffered
planes.

Signed-off-by: Thomas Zimmermann 
Reported-by: kernel test robot 
---
 drivers/gpu/drm/drm_gem.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index c2ce78c4edc3..9989425e9875 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1212,6 +1212,7 @@ int drm_gem_vmap(struct drm_gem_object *obj, struct 
dma_buf_map *map)
 
return 0;
 }
+EXPORT_SYMBOL(drm_gem_vmap);
 
 void drm_gem_vunmap(struct drm_gem_object *obj, struct dma_buf_map *map)
 {
@@ -1224,6 +1225,7 @@ void drm_gem_vunmap(struct drm_gem_object *obj, struct 
dma_buf_map *map)
/* Always set the mapping to NULL. Callers may rely on this. */
dma_buf_map_clear(map);
 }
+EXPORT_SYMBOL(drm_gem_vunmap);
 
 /**
  * drm_gem_lock_reservations - Sets up the ww context and acquires
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/7] drm: Add additional atomic helpers for shadow-buffered planes

[Thomas Zimmermann]

Several drivers use GEM buffer objects as shadow buffers for the actual
framebuffer memory. Right now, drivers do these vmap operations in their
commit tail, which is actually not allowed by the locking rules for
the dma-buf reservation lock. The involved BO has to be vmapped in the
plane's prepare_fb callback and vunmapped in cleanup_fb.

This patch introduces atomic helpers for such shadow planes. Plane
functions manage the plane state for shadow planes. The provided
implementations for prepare_fb and cleanup_fb vmap and vunmap all BOs of
struct drm_plane_state.fb. The mappings are afterwards available in the
plane's commit-tail functions.

For now, all rsp drivers use the simple KMS helpers, so we add the plane
callbacks and wrappers for simple KMS. The internal plane functions can
later be exported as needed.

v2:
* make duplicate_state interface compatible with
  struct drm_plane_funcs

Signed-off-by: Thomas Zimmermann 
Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 
---
 Documentation/gpu/drm-kms-helpers.rst   |  12 ++
 drivers/gpu/drm/Makefile|   3 +-
 drivers/gpu/drm/drm_gem_atomic_helper.c | 208 
 include/drm/drm_gem_atomic_helper.h |  73 +
 4 files changed, 295 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_gem_atomic_helper.c
 create mode 100644 include/drm/drm_gem_atomic_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index b89ddd06dabb..389892f36185 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -80,6 +80,18 @@ Atomic State Helper Reference
 .. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c
:export:
 
+GEM Atomic Helper Reference
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_atomic_helper.c
+   :doc: overview
+
+.. kernel-doc:: include/drm/drm_gem_atomic_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_atomic_helper.c
+   :export:
+
 Simple KMS Helper Reference
 ===
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 926adef289db..02c229392345 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -44,7 +44,8 @@ drm_kms_helper-y := drm_bridge_connector.o drm_crtc_helper.o 
drm_dp_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
-   drm_scdc_helper.o drm_gem_framebuffer_helper.o \
+   drm_scdc_helper.o drm_gem_atomic_helper.o \
+   drm_gem_framebuffer_helper.o \
drm_atomic_state_helper.o drm_damage_helper.o \
drm_format_helper.o drm_self_refresh_helper.o
 
diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c 
b/drivers/gpu/drm/drm_gem_atomic_helper.c
new file mode 100644
index ..0be3058cb2b8
--- /dev/null
+++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include 
+#include 
+#include 
+#include 
+
+#include "drm_internal.h"
+
+/**
+ * DOC: overview
+ *
+ * The GEM atomic helpers library implements generic atomic-commit
+ * functions for drivers that use GEM objects. Currently, it provides
+ * plane state and framebuffer BO mappings for planes with shadow
+ * buffers.
+ */
+
+/*
+ * Shadow-buffered Planes
+ */
+
+static struct drm_plane_state *
+drm_gem_duplicate_shadow_plane_state(struct drm_plane *plane)
+{
+   struct drm_plane_state *plane_state = plane->state;
+   struct drm_shadow_plane_state *new_shadow_plane_state;
+
+   if (!plane_state)
+   return NULL;
+
+   new_shadow_plane_state = kzalloc(sizeof(*new_shadow_plane_state), 
GFP_KERNEL);
+   if (!new_shadow_plane_state)
+   return NULL;
+   __drm_atomic_helper_plane_duplicate_state(plane, 
&new_shadow_plane_state->base);
+
+   return &new_shadow_plane_state->base;
+}
+
+static void drm_gem_destroy_shadow_plane_state(struct drm_plane *plane,
+  struct drm_plane_state 
*plane_state)
+{
+   struct drm_shadow_plane_state *shadow_plane_state =
+   to_drm_shadow_plane_state(plane_state);
+
+   __drm_atomic_helper_plane_destroy_state(&shadow_plane_state->base);
+   kfree(shadow_plane_state);
+}
+
+static void drm_gem_reset_shadow_plane(struct drm_plane *plane)
+{
+   struct drm_shadow_plane_state *shadow_plane_state;
+
+   if (plane->state) {
+   drm_gem_destroy_shadow_plane_state(plane, plane->state);
+   plane->state = NULL; /* must be set to NULL here */
+   }
+
+   shadow_plane_state = kzalloc(sizeof(*shadow_plane_state), GFP_KERNEL);
+   if (!shadow_plane_state)
+   return;
+   __drm_atomic_helper_plane_reset(plane, &shadow_plane_state->base)

[PATCH v2 7/7] drm/udl: Move vmap out of commit tail

[Thomas Zimmermann]

Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.

The mapping is provided as GEM shadow-buffered plane. The functions in
the commit tail use the pre-established mapping for damage handling.

Signed-off-by: Thomas Zimmermann 
Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 
---
 drivers/gpu/drm/udl/udl_modeset.c | 34 ---
 1 file changed, 13 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
b/drivers/gpu/drm/udl/udl_modeset.c
index 9d34ec9d03f6..8d98bf69d075 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -266,18 +267,17 @@ static int udl_aligned_damage_clip(struct drm_rect *clip, 
int x, int y,
return 0;
 }
 
-static int udl_handle_damage(struct drm_framebuffer *fb, int x, int y,
-int width, int height)
+static int udl_handle_damage(struct drm_framebuffer *fb, const struct 
dma_buf_map *map,
+int x, int y, int width, int height)
 {
struct drm_device *dev = fb->dev;
struct dma_buf_attachment *import_attach = fb->obj[0]->import_attach;
+   void *vaddr = map->vaddr; /* TODO: Use mapping abstraction properly */
int i, ret, tmp_ret;
char *cmd;
struct urb *urb;
struct drm_rect clip;
int log_bpp;
-   struct dma_buf_map map;
-   void *vaddr;
 
ret = udl_log_cpp(fb->format->cpp[0]);
if (ret < 0)
@@ -297,17 +297,10 @@ static int udl_handle_damage(struct drm_framebuffer *fb, 
int x, int y,
return ret;
}
 
-   ret = drm_gem_shmem_vmap(fb->obj[0], &map);
-   if (ret) {
-   DRM_ERROR("failed to vmap fb\n");
-   goto out_dma_buf_end_cpu_access;
-   }
-   vaddr = map.vaddr; /* TODO: Use mapping abstraction properly */
-
urb = udl_get_urb(dev);
if (!urb) {
ret = -ENOMEM;
-   goto out_drm_gem_shmem_vunmap;
+   goto out_dma_buf_end_cpu_access;
}
cmd = urb->transfer_buffer;
 
@@ -320,7 +313,7 @@ static int udl_handle_damage(struct drm_framebuffer *fb, 
int x, int y,
   &cmd, byte_offset, dev_byte_offset,
   byte_width);
if (ret)
-   goto out_drm_gem_shmem_vunmap;
+   goto out_dma_buf_end_cpu_access;
}
 
if (cmd > (char *)urb->transfer_buffer) {
@@ -336,8 +329,6 @@ static int udl_handle_damage(struct drm_framebuffer *fb, 
int x, int y,
 
ret = 0;
 
-out_drm_gem_shmem_vunmap:
-   drm_gem_shmem_vunmap(fb->obj[0], &map);
 out_dma_buf_end_cpu_access:
if (import_attach) {
tmp_ret = dma_buf_end_cpu_access(import_attach->dmabuf,
@@ -375,6 +366,7 @@ udl_simple_display_pipe_enable(struct 
drm_simple_display_pipe *pipe,
struct drm_framebuffer *fb = plane_state->fb;
struct udl_device *udl = to_udl(dev);
struct drm_display_mode *mode = &crtc_state->mode;
+   struct drm_shadow_plane_state *shadow_plane_state = 
to_drm_shadow_plane_state(plane_state);
char *buf;
char *wrptr;
int color_depth = UDL_COLOR_DEPTH_16BPP;
@@ -400,7 +392,7 @@ udl_simple_display_pipe_enable(struct 
drm_simple_display_pipe *pipe,
 
udl->mode_buf_len = wrptr - buf;
 
-   udl_handle_damage(fb, 0, 0, fb->width, fb->height);
+   udl_handle_damage(fb, &shadow_plane_state->map[0], 0, 0, fb->width, 
fb->height);
 
if (!crtc_state->mode_changed)
return;
@@ -435,6 +427,7 @@ udl_simple_display_pipe_update(struct 
drm_simple_display_pipe *pipe,
   struct drm_plane_state *old_plane_state)
 {
struct drm_plane_state *state = pipe->plane.state;
+   struct drm_shadow_plane_state *shadow_plane_state = 
to_drm_shadow_plane_state(state);
struct drm_framebuffer *fb = state->fb;
struct drm_rect rect;
 
@@ -442,17 +435,16 @@ udl_simple_display_pipe_update(struct 
drm_simple_display_pipe *pipe,
return;
 
if (drm_atomic_helper_damage_merged(old_plane_state, state, &rect))
-   udl_handle_damage(fb, rect.x1, rect.y1, rect.x2 - rect.x1,
- rect.y2 - rect.y1);
+   udl_handle_damage(fb, &shadow_plane_state->map[0], rect.x1, 
rect.y1,
+ rect.x2 - rect.x1, rect.y2 - rect.y1);
 }
 
-static const
-struct drm_simple_display_pipe_funcs udl_simple_display_pipe_funcs = {
+static const struct drm_simple_display_pipe_funcs 
udl_simple_display_pipe_funcs = {
.mode_valid = udl_simple_display_pipe_mode_valid,
.enable = udl_

[PATCH v2 5/7] drm/cirrus: Move vmap out of commit tail

[Thomas Zimmermann]

Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.

The mapping is provided as GEM shadow-buffered plane. The functions in
the commit tail use the pre-established mapping for damage handling.

Signed-off-by: Thomas Zimmermann 
Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 
---
 drivers/gpu/drm/tiny/cirrus.c | 43 ++-
 1 file changed, 17 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index a043e602199e..ad922c3ec681 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -33,8 +33,9 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -311,22 +312,15 @@ static int cirrus_mode_set(struct cirrus_device *cirrus,
return 0;
 }
 
-static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
+static int cirrus_fb_blit_rect(struct drm_framebuffer *fb, const struct 
dma_buf_map *map,
   struct drm_rect *rect)
 {
struct cirrus_device *cirrus = to_cirrus(fb->dev);
-   struct dma_buf_map map;
-   void *vmap;
-   int idx, ret;
+   void *vmap = map->vaddr; /* TODO: Use mapping abstraction properly */
+   int idx;
 
-   ret = -ENODEV;
if (!drm_dev_enter(&cirrus->dev, &idx))
-   goto out;
-
-   ret = drm_gem_shmem_vmap(fb->obj[0], &map);
-   if (ret)
-   goto out_dev_exit;
-   vmap = map.vaddr; /* TODO: Use mapping abstraction properly */
+   return -ENODEV;
 
if (cirrus->cpp == fb->format->cpp[0])
drm_fb_memcpy_dstclip(cirrus->vram,
@@ -345,16 +339,12 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
else
WARN_ON_ONCE("cpp mismatch");
 
-   drm_gem_shmem_vunmap(fb->obj[0], &map);
-   ret = 0;
-
-out_dev_exit:
drm_dev_exit(idx);
-out:
-   return ret;
+
+   return 0;
 }
 
-static int cirrus_fb_blit_fullscreen(struct drm_framebuffer *fb)
+static int cirrus_fb_blit_fullscreen(struct drm_framebuffer *fb, const struct 
dma_buf_map *map)
 {
struct drm_rect fullscreen = {
.x1 = 0,
@@ -362,7 +352,7 @@ static int cirrus_fb_blit_fullscreen(struct drm_framebuffer 
*fb)
.y1 = 0,
.y2 = fb->height,
};
-   return cirrus_fb_blit_rect(fb, &fullscreen);
+   return cirrus_fb_blit_rect(fb, map, &fullscreen);
 }
 
 static int cirrus_check_size(int width, int height,
@@ -441,9 +431,10 @@ static void cirrus_pipe_enable(struct 
drm_simple_display_pipe *pipe,
   struct drm_plane_state *plane_state)
 {
struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
+   struct drm_shadow_plane_state *shadow_plane_state = 
to_drm_shadow_plane_state(plane_state);
 
cirrus_mode_set(cirrus, &crtc_state->mode, plane_state->fb);
-   cirrus_fb_blit_fullscreen(plane_state->fb);
+   cirrus_fb_blit_fullscreen(plane_state->fb, &shadow_plane_state->map[0]);
 }
 
 static void cirrus_pipe_update(struct drm_simple_display_pipe *pipe,
@@ -451,16 +442,15 @@ static void cirrus_pipe_update(struct 
drm_simple_display_pipe *pipe,
 {
struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
struct drm_plane_state *state = pipe->plane.state;
+   struct drm_shadow_plane_state *shadow_plane_state = 
to_drm_shadow_plane_state(state);
struct drm_crtc *crtc = &pipe->crtc;
struct drm_rect rect;
 
-   if (pipe->plane.state->fb &&
-   cirrus->cpp != cirrus_cpp(pipe->plane.state->fb))
-   cirrus_mode_set(cirrus, &crtc->mode,
-   pipe->plane.state->fb);
+   if (state->fb && cirrus->cpp != cirrus_cpp(state->fb))
+   cirrus_mode_set(cirrus, &crtc->mode, state->fb);
 
if (drm_atomic_helper_damage_merged(old_state, state, &rect))
-   cirrus_fb_blit_rect(pipe->plane.state->fb, &rect);
+   cirrus_fb_blit_rect(state->fb, &shadow_plane_state->map[0], 
&rect);
 }
 
 static const struct drm_simple_display_pipe_funcs cirrus_pipe_funcs = {
@@ -468,6 +458,7 @@ static const struct drm_simple_display_pipe_funcs 
cirrus_pipe_funcs = {
.check  = cirrus_pipe_check,
.enable = cirrus_pipe_enable,
.update = cirrus_pipe_update,
+   DRM_GEM_SIMPLE_DISPLAY_PIPE_SHADOW_PLANE_FUNCS,
 };
 
 static const uint32_t cirrus_formats[] = {
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 6/7] drm/gm12u320: Move vmap out of commit tail

[Thomas Zimmermann]

Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.

The mapping is provided as GEM shadow-buffered plane. The functions in
the commit tail use the pre-established mapping for damage handling.

Signed-off-by: Thomas Zimmermann 
Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 
---
 drivers/gpu/drm/tiny/gm12u320.c | 28 +---
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
index 33f65f4626e5..0b4f4f2af1ef 100644
--- a/drivers/gpu/drm/tiny/gm12u320.c
+++ b/drivers/gpu/drm/tiny/gm12u320.c
@@ -16,8 +16,9 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -94,6 +95,7 @@ struct gm12u320_device {
struct drm_rect  rect;
int frame;
int draw_status_timeout;
+   struct dma_buf_map src_map;
} fb_update;
 };
 
@@ -250,7 +252,6 @@ static void gm12u320_copy_fb_to_blocks(struct 
gm12u320_device *gm12u320)
 {
int block, dst_offset, len, remain, ret, x1, x2, y1, y2;
struct drm_framebuffer *fb;
-   struct dma_buf_map map;
void *vaddr;
u8 *src;
 
@@ -264,20 +265,14 @@ static void gm12u320_copy_fb_to_blocks(struct 
gm12u320_device *gm12u320)
x2 = gm12u320->fb_update.rect.x2;
y1 = gm12u320->fb_update.rect.y1;
y2 = gm12u320->fb_update.rect.y2;
-
-   ret = drm_gem_shmem_vmap(fb->obj[0], &map);
-   if (ret) {
-   GM12U320_ERR("failed to vmap fb: %d\n", ret);
-   goto put_fb;
-   }
-   vaddr = map.vaddr; /* TODO: Use mapping abstraction properly */
+   vaddr = gm12u320->fb_update.src_map.vaddr; /* TODO: Use mapping 
abstraction properly */
 
if (fb->obj[0]->import_attach) {
ret = dma_buf_begin_cpu_access(
fb->obj[0]->import_attach->dmabuf, DMA_FROM_DEVICE);
if (ret) {
GM12U320_ERR("dma_buf_begin_cpu_access err: %d\n", ret);
-   goto vunmap;
+   goto put_fb;
}
}
 
@@ -321,8 +316,6 @@ static void gm12u320_copy_fb_to_blocks(struct 
gm12u320_device *gm12u320)
if (ret)
GM12U320_ERR("dma_buf_end_cpu_access err: %d\n", ret);
}
-vunmap:
-   drm_gem_shmem_vunmap(fb->obj[0], &map);
 put_fb:
drm_framebuffer_put(fb);
gm12u320->fb_update.fb = NULL;
@@ -410,7 +403,7 @@ static void gm12u320_fb_update_work(struct work_struct 
*work)
GM12U320_ERR("Frame update error: %d\n", ret);
 }
 
-static void gm12u320_fb_mark_dirty(struct drm_framebuffer *fb,
+static void gm12u320_fb_mark_dirty(struct drm_framebuffer *fb, const struct 
dma_buf_map *map,
   struct drm_rect *dirty)
 {
struct gm12u320_device *gm12u320 = to_gm12u320(fb->dev);
@@ -424,6 +417,7 @@ static void gm12u320_fb_mark_dirty(struct drm_framebuffer 
*fb,
drm_framebuffer_get(fb);
gm12u320->fb_update.fb = fb;
gm12u320->fb_update.rect = *dirty;
+   gm12u320->fb_update.src_map = *map;
wakeup = true;
} else {
struct drm_rect *rect = &gm12u320->fb_update.rect;
@@ -452,6 +446,7 @@ static void gm12u320_stop_fb_update(struct gm12u320_device 
*gm12u320)
mutex_lock(&gm12u320->fb_update.lock);
old_fb = gm12u320->fb_update.fb;
gm12u320->fb_update.fb = NULL;
+   dma_buf_map_clear(&gm12u320->fb_update.src_map);
mutex_unlock(&gm12u320->fb_update.lock);
 
drm_framebuffer_put(old_fb);
@@ -564,9 +559,10 @@ static void gm12u320_pipe_enable(struct 
drm_simple_display_pipe *pipe,
 {
struct drm_rect rect = { 0, 0, GM12U320_USER_WIDTH, GM12U320_HEIGHT };
struct gm12u320_device *gm12u320 = to_gm12u320(pipe->crtc.dev);
+   struct drm_shadow_plane_state *shadow_plane_state = 
to_drm_shadow_plane_state(plane_state);
 
gm12u320->fb_update.draw_status_timeout = FIRST_FRAME_TIMEOUT;
-   gm12u320_fb_mark_dirty(plane_state->fb, &rect);
+   gm12u320_fb_mark_dirty(plane_state->fb, &shadow_plane_state->map[0], 
&rect);
 }
 
 static void gm12u320_pipe_disable(struct drm_simple_display_pipe *pipe)
@@ -580,16 +576,18 @@ static void gm12u320_pipe_update(struct 
drm_simple_display_pipe *pipe,
 struct drm_plane_state *old_state)
 {
struct drm_plane_state *state = pipe->plane.state;
+   struct drm_shadow_plane_state *shadow_plane_state = 
to_drm_shadow_plane_state(state);
struct drm_rect rect;
 
if (drm_atomic_helper_damage_merged(old_state, state, &rect))
-   gm12u320_fb_mark_dirty(pipe->plane.state->fb, &rect);
+  

[PATCH v2 0/7] drm: Move vmap out of commit tail for SHMEM-based drivers

[Thomas Zimmermann]

Several SHMEM-based drivers use the BO as shadow buffer for the real
framebuffer memory. Damage handling requires a vmap of the BO memory.
But vmap/vunmap can acquire the dma-buf reservation lock, which is not
allowed in commit tails.

This patchset introduces a set of helpers that implement vmap/vunmap
in the plane's prepare_fb and cleanup_fb; and provide the mapping's
address to commit-tail functions. Wrappers for simple KMS are provides,
as all of the involved drivers are built upon simple-KMS helpers.

Patch 1 adds the support for private plane state to the simple-KMS
helper library.

Patches 2 and 3 provide plane state for shadow-buffered planes. It's a
DRM plane with BO mappings into kernel address space. The involved
helpers take care of the details. The code is independent from GEM
SHMEM and can be used with other shadow-buffered planes. I put all
this in a new file. In a later patch, drm_gem_fb_prepare_fb() et al
could be moved there as well.

Patches 4 to 7 convert each involved driver to the new helpers. The
vmap operations are being removed from commit-tail functions. An
additional benefit is that vmap errors are now detected before the
commit starts. The original commit-tail functions could not
handle failed vmap operations.

I smoke-tested the code by running fbdev, Xorg and weston with the
converted mgag200 driver.

v2:
* export drm_gem_vmap()/_vunmap() (kernel test robot)
* make duplicate_state interface compatible with
  struct drm_plane_funcs

Thomas Zimmermann (7):
  drm/simple-kms: Add plane-state helpers
  drm/gem: Export drm_gem_vmap() and drm_gem_vunmap()
  drm: Add additional atomic helpers for shadow-buffered planes
  drm/mgag200: Move vmap out of commit tail
  drm/cirrus: Move vmap out of commit tail
  drm/gm12u320: Move vmap out of commit tail
  drm/udl: Move vmap out of commit tail

 Documentation/gpu/drm-kms-helpers.rst   |  12 ++
 drivers/gpu/drm/Makefile|   3 +-
 drivers/gpu/drm/drm_gem.c   |   2 +
 drivers/gpu/drm/drm_gem_atomic_helper.c | 208 
 drivers/gpu/drm/drm_simple_kms_helper.c |  40 -
 drivers/gpu/drm/mgag200/mgag200_mode.c  |  23 +--
 drivers/gpu/drm/tiny/cirrus.c   |  43 ++---
 drivers/gpu/drm/tiny/gm12u320.c |  28 ++--
 drivers/gpu/drm/udl/udl_modeset.c   |  34 ++--
 include/drm/drm_gem_atomic_helper.h |  73 +
 include/drm/drm_simple_kms_helper.h |  27 +++
 11 files changed, 412 insertions(+), 81 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_gem_atomic_helper.c
 create mode 100644 include/drm/drm_gem_atomic_helper.h


base-commit: f9173d6435c6a9bb0b0076ebf9122d876da208ae
prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
prerequisite-patch-id: f8140f08b77c49beb6243d9a2a88ebcc7097e391
prerequisite-patch-id: 6bffaf03d01daeb29a0b0ffbc78b415e72907a17
prerequisite-patch-id: 6386ca949b8b677a7eada2672990dab2f84f734f
prerequisite-patch-id: 706e35d0b2185d2332f725e1c22d8ffed910ea7b
prerequisite-patch-id: e30631cc73b905efa477be3f56daf1ff5112fe03
--
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/7] drm/simple-kms: Add plane-state helpers

[Thomas Zimmermann]

Just like regular plane-state helpers, drivers can use these new
callbacks to create and destroy private plane state.

v2:
* make duplicate_state interface compatible with
  struct drm_plane_funcs

Signed-off-by: Thomas Zimmermann 
Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 
---
 drivers/gpu/drm/drm_simple_kms_helper.c | 40 +++--
 include/drm/drm_simple_kms_helper.h | 27 +
 2 files changed, 64 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 6ce8f5cd1eb5..89675d4b7b6c 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -253,13 +253,47 @@ static const struct drm_plane_helper_funcs 
drm_simple_kms_plane_helper_funcs = {
.atomic_update = drm_simple_kms_plane_atomic_update,
 };
 
+static void drm_simple_kms_plane_reset(struct drm_plane *plane)
+{
+   struct drm_simple_display_pipe *pipe;
+
+   pipe = container_of(plane, struct drm_simple_display_pipe, plane);
+   if (!pipe->funcs || !pipe->funcs->reset_plane)
+   return drm_atomic_helper_plane_reset(plane);
+
+   return pipe->funcs->reset_plane(pipe);
+}
+
+static struct drm_plane_state *drm_simple_kms_plane_duplicate_state(struct 
drm_plane *plane)
+{
+   struct drm_simple_display_pipe *pipe;
+
+   pipe = container_of(plane, struct drm_simple_display_pipe, plane);
+   if (!pipe->funcs || !pipe->funcs->duplicate_plane_state)
+   return drm_atomic_helper_plane_duplicate_state(plane);
+
+   return pipe->funcs->duplicate_plane_state(pipe);
+}
+
+static void drm_simple_kms_plane_destroy_state(struct drm_plane *plane,
+  struct drm_plane_state *state)
+{
+   struct drm_simple_display_pipe *pipe;
+
+   pipe = container_of(plane, struct drm_simple_display_pipe, plane);
+   if (!pipe->funcs || !pipe->funcs->destroy_plane_state)
+   drm_atomic_helper_plane_destroy_state(plane, state);
+   else
+   pipe->funcs->destroy_plane_state(pipe, state);
+}
+
 static const struct drm_plane_funcs drm_simple_kms_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
.destroy= drm_plane_cleanup,
-   .reset  = drm_atomic_helper_plane_reset,
-   .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
-   .atomic_destroy_state   = drm_atomic_helper_plane_destroy_state,
+   .reset  = drm_simple_kms_plane_reset,
+   .atomic_duplicate_state = drm_simple_kms_plane_duplicate_state,
+   .atomic_destroy_state   = drm_simple_kms_plane_destroy_state,
.format_mod_supported   = drm_simple_kms_format_mod_supported,
 };
 
diff --git a/include/drm/drm_simple_kms_helper.h 
b/include/drm/drm_simple_kms_helper.h
index e6dbf3161c2f..40b34573249f 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -149,6 +149,33 @@ struct drm_simple_display_pipe_funcs {
 * more details.
 */
void (*disable_vblank)(struct drm_simple_display_pipe *pipe);
+
+   /**
+* @reset_plane:
+*
+* Optional, called by &drm_plane_funcs.reset. Please read the
+* documentation for the &drm_plane_funcs.reset hook for more details.
+*/
+   void (*reset_plane)(struct drm_simple_display_pipe *pipe);
+
+   /**
+* @duplicate_plane_state:
+*
+* Optional, called by &drm_plane_funcs.atomic_duplicate_state.  Please
+* read the documentation for the 
&drm_plane_funcs.atomic_duplicate_state
+* hook for more details.
+*/
+   struct drm_plane_state * (*duplicate_plane_state)(struct 
drm_simple_display_pipe *pipe);
+
+   /**
+* @destroy_plane_state:
+*
+* Optional, called by &drm_plane_funcs.atomic_destroy_state.  Please
+* read the documentation for the &drm_plane_funcs.atomic_destroy_state
+* hook for more details.
+*/
+   void (*destroy_plane_state)(struct drm_simple_display_pipe *pipe,
+   struct drm_plane_state *plane_state);
 };
 
 /**
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances

[Deucher, Alexander]

[AMD Official Use Only - Internal Distribution Only]

I think the virt team probably wants it in amd-staging-drm-next so they can 
start testing it.  5.12 is getting pretty tight.  I'm not sure if there will be 
another drm-misc PR or not for 5.12.  Rebasing amd-staging-drm-next is turning 
into a challenge.  there are always a lot of regressions.  I guess that is an 
argument to rebase more often so we get better internal testing of it.

Alex


From: Koenig, Christian 
Sent: Friday, February 5, 2021 9:53 AM
To: Deucher, Alexander ; Liu, Leo ; 
amd-...@lists.freedesktop.org ; 
dri-devel@lists.freedesktop.org 
Subject: Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances

The alternative is to wait till drm-misc-next is merged into drm-next, then 
rebase amd-staging-drm-next on top of that (or directly drm-misc-next) and push 
then.

Would give us at least a clean history. Question is rather if we want it in 
5.12?

Christian.

Am 05.02.21 um 15:50 schrieb Deucher, Alexander:

[AMD Official Use Only - Internal Distribution Only]

Good question.  I think push it to drm-misc-next for upstream.  We can carry it 
internally in amd-staging-drm-next for internal testing and I can coordinate 
with drm-next.  I think the amdgpu changes are pretty straightforward, so 
shouldn't be too hard keep the merge straight.  I dunno.

Alex


From: Christian König 

Sent: Friday, February 5, 2021 4:58 AM
To: Liu, Leo ; 
amd-...@lists.freedesktop.org 
; 
dri-devel@lists.freedesktop.org 
; 
Deucher, Alexander 
Subject: Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances

Alex how do we want to merge this?

I've just pushed the first patch to drm-misc-next since that needed a
rebase because it touches other drivers as well.

But the rest is really AMD specific and I'm not sure if the dependent
stuff is already in there as well.

So if I push it to drm-misc-next you will probably need to merge and if
I push it to amd-staging-drm-next somebody else might need to merge when
drm-misc-next is merged.

Ideas?

Christian.

Am 04.02.21 um 19:34 schrieb Leo Liu:
> The series are:
>
> Reviewed-and-Tested-by: Leo Liu 
>
>
> On 2021-02-04 9:44 a.m., Christian König wrote:
>> The VCN3 instances can do both decode as well as encode.
>>
>> Share the scheduler load balancing score and remove fixing encode to
>> only the second instance.
>>
>> Signed-off-by: Christian König 
>> 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h |  1 +
>>   drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c   | 11 +++
>>   2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> index 13aa417f6be7..d10bc4f0a05f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
>> @@ -211,6 +211,7 @@ struct amdgpu_vcn_inst {
>>   void*saved_bo;
>>   struct amdgpu_ringring_dec;
>>   struct amdgpu_ringring_enc[AMDGPU_VCN_MAX_ENC_RINGS];
>> +atomic_tsched_score;
>>   struct amdgpu_irq_srcirq;
>>   struct amdgpu_vcn_regexternal;
>>   struct amdgpu_bo*dpg_sram_bo;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> index 239a4eb52c61..b33f513fd2ac 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
>> @@ -171,6 +171,7 @@ static int vcn_v3_0_sw_init(void *handle)
>> for (i = 0; i < adev->vcn.num_vcn_inst; i++) {
>>   volatile struct amdgpu_fw_shared *fw_shared;
>> +
>>   if (adev->vcn.harvest_config & (1 << i))
>>   continue;
>>   @@ -198,6 +199,8 @@ static int vcn_v3_0_sw_init(void *handle)
>>   if (r)
>>   return r;
>>   +atomic_set(&adev->vcn.inst[i].sched_score, 0);
>> +
>>   ring = &adev->vcn.inst[i].ring_dec;
>>   ring->use_doorbell = true;
>>   if (amdgpu_sriov_vf(adev)) {
>> @@ -209,7 +212,8 @@ static int vcn_v3_0_sw_init(void *handle)
>>   ring->no_scheduler = true;
>>   sprintf(ring->name, "vcn_dec_%d", i);
>>   r = amdgpu_ring_init(adev, ring, 512,
>> &adev->vcn.inst[i].irq, 0,
>> - AMDGPU_RING_PRIO_DEFAULT, NULL);
>> + AMDGPU_RING_PRIO_DEFAULT,
>> + &adev->vcn.inst[i].sched_score);
>>   if (r)
>>   return r;
>>   @@ -227,11 +231,10 @@ static int vcn_v3_0_sw_init(void *handle)
>>   } else {
>>   ring->doorbell_index =
>> (adev->doorbell_index.vcn.v

Re: [PATCH v2] drm/qxl: do not run release if qxl failed to init

[Tong Zhang]

On Feb 5, 2021, at 2:43 AM, Gerd Hoffmann  wrote:
> 
> On Thu, Feb 04, 2021 at 11:30:50AM -0500, Tong Zhang wrote:
>> if qxl_device_init() fail, drm device will not be registered,
>> in this case, do not run qxl_drm_release()
> 
> How do you trigger this?
> 

This can be triggered by changing the QXL VGA rom magic value.

In the QEMU source code ./hw/display/qxl.c
or change the QXL_ROM_MAGIC in spice header file

- Tong

> take care,
>  Gerd
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v16 0/4] RDMA: Add dma-buf support

[Daniel Vetter]

On Thu, Feb 04, 2021 at 11:00:32AM -0800, John Hubbard wrote:
> On 2/4/21 10:44 AM, Alex Deucher wrote:
> ...
> > > > The argument is that vram is a scarce resource, but I don't know if
> > > > that is really the case these days.  At this point, we often have as
> > > > much vram as system ram if not more.
> > > 
> > > I thought the main argument was that GPU memory could move at any time
> > > between the GPU and CPU and the DMA buf would always track its current
> > > location?
> > 
> > I think the reason for that is that VRAM is scarce so we have to be
> > able to move it around.  We don't enforce the same limitations for
> > buffers in system memory.  We could just support pinning dma-bufs in
> > vram like we do with system ram.  Maybe with some conditions, e.g.,
> > p2p is possible, and the device has a large BAR so you aren't tying up
> > the BAR window.

Minimally we need cgroups for that vram, so it can be managed. Which is a
bit stuck unfortunately. But if we have cgroups with some pin limit, I
think we can easily lift this.

> Excellent. And yes, we are already building systems in which VRAM is
> definitely not scarce, but on the other hand, those newer systems can
> also handle GPU (and NIC) page faults, so not really an issue. For that,
> we just need to enhance HMM so that it does peer to peer.
> 
> We also have some older hardware with large BAR1 apertures, specifically
> for this sort of thing.
> 
> And again, for slightly older hardware, without pinning to VRAM there is
> no way to use this solution here for peer-to-peer. So I'm glad to see that
> so far you're not ruling out the pinning option.

Since HMM and ZONE_DEVICE came up, I'm kinda tempted to make ZONE_DEVICE
ZONE_MOVEABLE (at least if you don't have a pinned vram contigent in your
cgroups) or something like that, so we could benefit from the work to make
sure pin_user_pages and all these never end up in there?

https://lwn.net/Articles/843326/

Kind inspired by the recent lwn article.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 210849] Black screen after resume from long suspend. Open/Close lid. AMDGPU

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=210849

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #11 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you bisect?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v16 0/4] RDMA: Add dma-buf support

[Jason Gunthorpe]

On Fri, Feb 05, 2021 at 04:39:47PM +0100, Daniel Vetter wrote:

> > And again, for slightly older hardware, without pinning to VRAM there is
> > no way to use this solution here for peer-to-peer. So I'm glad to see that
> > so far you're not ruling out the pinning option.
> 
> Since HMM and ZONE_DEVICE came up, I'm kinda tempted to make ZONE_DEVICE
> ZONE_MOVEABLE (at least if you don't have a pinned vram contigent in your
> cgroups) or something like that, so we could benefit from the work to make
> sure pin_user_pages and all these never end up in there?

ZONE_DEVICE should already not be returned from GUP.

I've understood in the hmm casse the idea was a CPU touch of some
ZONE_DEVICE pages would trigger a migration to CPU memory, GUP would
want to follow the same logic, presumably it comes for free with the
fault handler somehow

Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vblank: Avoid storing a timestamp for the same frame twice

[Daniel Vetter]

On Thu, Feb 04, 2021 at 05:55:28PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > drm_vblank_restore() exists because certain power saving states
> > > can clobber the hardware frame counter. The way it does this is
> > > by guesstimating how many frames were missed purely based on
> > > the difference between the last stored timestamp vs. a newly
> > > sampled timestamp.
> > > 
> > > If we should call this function before a full frame has
> > > elapsed since we sampled the last timestamp we would end up
> > > with a possibly slightly different timestamp value for the
> > > same frame. Currently we will happily overwrite the already
> > > stored timestamp for the frame with the new value. This
> > > could cause userspace to observe two different timestamps
> > > for the same frame (and the timestamp could even go
> > > backwards depending on how much error we introduce when
> > > correcting the timestamp based on the scanout position).
> > > 
> > > To avoid that let's not update the stored timestamp unless we're
> > > also incrementing the sequence counter. We do still want to update
> > > vblank->last with the freshly sampled hw frame counter value so
> > > that subsequent vblank irqs/queries can actually use the hw frame
> > > counter to determine how many frames have elapsed.
> > 
> > Hm I'm not getting the reason for why we store the updated hw vblank
> > counter?
> 
> Because next time a vblank irq happens the code will do:
> diff = current_hw_counter - vblank->last
> 
> which won't work very well if vblank->last is garbage.
> 
> Updating vblank->last is pretty much why drm_vblank_restore()
> exists at all.

Oh sure, _restore has to update this, together with the timestamp.

But your code adds such an update where we update the hw vblank counter,
but not the timestamp, and that feels buggy. Either we're still in the
same frame, and then we should story nothing. Or we advanced, and then we
probably want a new timestampt for that frame too.

Advancing the vblank counter and not advancing the timestamp sounds like a
bug in our code.

> > There's definitely a race when we grab the hw timestamp at a bad time
> > (which can't happen for the irq handler, realistically), so maybe we
> > should first adjust that to make sure we never store anything inconsistent
> > in the vblank state?
> 
> Not sure what race you mean, or what inconsistent thing we store?

For the drm_handle_vblank code we have some fudge so we don't compute
something silly when the irq fires (like it often does) before
top-of-frame. Ofc that fudge is inheritedly racy, if the irq is extremely
delay (almost an entire frame) we'll get it wrong.

In practice it doesn't matter.

Now _restore can be called anytime, so we might end up in situations where
the exact point where we jump to the next frame count, and the exact time
where the hw counter jumps, don't lign up. And I think in that case funny
things can happen, and I'm not sure your approach of "update hw counter
but don't update timestamp" is the right way.

I think if we instead ignore any update if our fudge-corrected timestamp
is roughly the same, then we handle that race correctly and there's no
jumping around.

Cheers, Daniel

> > And when we have that we should be able to pull the inc == 0 check out
> > into _restore(), including comment. Which I think should be cleaner.
> > 
> > Or I'm totally off with why you want to store the hw vblank counter?
> > 
> > > 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Rodrigo Vivi 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/drm_vblank.c | 11 +++
> > >  1 file changed, 11 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > > index 893165eeddf3..e127a7db2088 100644
> > > --- a/drivers/gpu/drm/drm_vblank.c
> > > +++ b/drivers/gpu/drm/drm_vblank.c
> > > @@ -176,6 +176,17 @@ static void store_vblank(struct drm_device *dev, 
> > > unsigned int pipe,
> > >  
> > >   vblank->last = last;
> > >  
> > > + /*
> > > +  * drm_vblank_restore() wants to always update
> > > +  * vblank->last since we can't trust the frame counter
> > > +  * across power saving states. But we don't want to alter
> > > +  * the stored timestamp for the same frame number since
> > > +  * that would cause userspace to potentially observe two
> > > +  * different timestamps for the same frame.
> > > +  */
> > > + if (vblank_count_inc == 0)
> > > + return;
> > > +
> > >   write_seqlock(&vblank->seqlock);
> > >   vblank->time = t_vblank;
> > >   atomic64_add(vblank_count_inc, &vblank->count);
> > > -- 
> > > 2.26.2
> > > 
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> -- 
> Ville Syrjälä
> Intel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_

Re: [PATCH v16 0/4] RDMA: Add dma-buf support

[Daniel Vetter]

On Fri, Feb 05, 2021 at 11:43:19AM -0400, Jason Gunthorpe wrote:
> On Fri, Feb 05, 2021 at 04:39:47PM +0100, Daniel Vetter wrote:
> 
> > > And again, for slightly older hardware, without pinning to VRAM there is
> > > no way to use this solution here for peer-to-peer. So I'm glad to see that
> > > so far you're not ruling out the pinning option.
> > 
> > Since HMM and ZONE_DEVICE came up, I'm kinda tempted to make ZONE_DEVICE
> > ZONE_MOVEABLE (at least if you don't have a pinned vram contigent in your
> > cgroups) or something like that, so we could benefit from the work to make
> > sure pin_user_pages and all these never end up in there?
> 
> ZONE_DEVICE should already not be returned from GUP.
> 
> I've understood in the hmm casse the idea was a CPU touch of some
> ZONE_DEVICE pages would trigger a migration to CPU memory, GUP would
> want to follow the same logic, presumably it comes for free with the
> fault handler somehow

Oh I didn't know this, I thought the proposed p2p direct i/o patches would
just use the fact that underneath ZONE_DEVICE there's "normal" struct
pages. And so I got worried that maybe also pin_user_pages can creep in.
But I didn't read the patches in full detail:

https://lore.kernel.org/linux-block/20201106170036.18713-12-log...@deltatee.com/

But if you're saying that this all needs specific code and all the gup/pup
code we have is excluded, I think we can make sure that we're not ever
building features that requiring time-unlimited pinning of ZONE_DEVICE.
Which I think we want.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel