[PATCH v2 4/4] drm/i915: convert get_user_pages() --> pin_user_pages()
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Signed-off-by: John Hubbard
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 22 -
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 7ffd7afeb7a5..b55ac7563189 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -471,7 +471,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
down_read(>mmap_sem);
locked = 1;
}
- ret = get_user_pages_remote
+ ret = pin_user_pages_remote
(work->task, mm,
obj->userptr.ptr + pinned * PAGE_SIZE,
npages - pinned,
@@ -507,7 +507,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
}
mutex_unlock(>mm.lock);
- release_pages(pvec, pinned);
+ unpin_user_pages(pvec, pinned);
kvfree(pvec);
i915_gem_object_put(obj);
@@ -564,6 +564,7 @@ static int i915_gem_userptr_get_pages(struct
drm_i915_gem_object *obj)
struct sg_table *pages;
bool active;
int pinned;
+ unsigned int gup_flags = 0;
/* If userspace should engineer that these pages are replaced in
* the vma between us binding this page into the GTT and completion
@@ -598,11 +599,14 @@ static int i915_gem_userptr_get_pages(struct
drm_i915_gem_object *obj)
GFP_KERNEL |
__GFP_NORETRY |
__GFP_NOWARN);
- if (pvec) /* defer to worker if malloc fails */
- pinned = __get_user_pages_fast(obj->userptr.ptr,
- num_pages,
-
!i915_gem_object_is_readonly(obj),
- pvec);
+ /* defer to worker if malloc fails */
+ if (pvec) {
+ if (!i915_gem_object_is_readonly(obj))
+ gup_flags |= FOLL_WRITE;
+ pinned = pin_user_pages_fast_only(obj->userptr.ptr,
+ num_pages, gup_flags,
+ pvec);
+ }
}
active = false;
@@ -620,7 +624,7 @@ static int i915_gem_userptr_get_pages(struct
drm_i915_gem_object *obj)
__i915_gem_userptr_set_active(obj, true);
if (IS_ERR(pages))
- release_pages(pvec, pinned);
+ unpin_user_pages(pvec, pinned);
kvfree(pvec);
return PTR_ERR_OR_ZERO(pages);
@@ -675,7 +679,7 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj,
}
mark_page_accessed(page);
- put_page(page);
+ unpin_user_page(page);
}
obj->mm.dirty = false;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] mm/gup: refactor and de-duplicate gup_fast() code
There were two nearly identical sets of code for gup_fast()
style of walking the page tables with interrupts disabled.
This has lead to the usual maintenance problems that arise from
having duplicated code.
There is already a core internal routine in gup.c for gup_fast(),
so just enhance it very slightly: allow skipping the fall-back
to "slow" (regular) get_user_pages(), via the new FOLL_FAST_ONLY
flag. Then, just call internal_get_user_pages_fast() from
__get_user_pages_fast(), and adjust the API to match pre-existing
API behavior.
There is a change in behavior from this refactoring: the nested
form of interrupt disabling is used in all gup_fast() variants
now. That's because there is only one place that interrupt disabling
for page walking is done, and so the safer form is required. This
should, if anything, eliminate possible (rare) bugs, because the
non-nested form of enabling interrupts was fragile at best.
Signed-off-by: John Hubbard
---
include/linux/mm.h | 1 +
mm/gup.c | 63 ++
2 files changed, 31 insertions(+), 33 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a5594ac9ebe3..84b601cab699 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2782,6 +2782,7 @@ struct page *follow_page(struct vm_area_struct *vma,
unsigned long address,
#define FOLL_LONGTERM 0x1 /* mapping lifetime is indefinite: see below */
#define FOLL_SPLIT_PMD 0x2 /* split huge pmd before returning */
#define FOLL_PIN 0x4 /* pages must be released via unpin_user_page */
+#define FOLL_FAST_ONLY 0x8 /* gup_fast: prevent fall-back to slow gup */
/*
* FOLL_PIN and FOLL_LONGTERM may be used in various combinations with each
diff --git a/mm/gup.c b/mm/gup.c
index 4502846d57f9..4564b0dc7d0b 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2694,10 +2694,12 @@ static int internal_get_user_pages_fast(unsigned long
start, int nr_pages,
struct page **pages)
{
unsigned long addr, len, end;
+ unsigned long flags;
int nr_pinned = 0, ret = 0;
if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM |
- FOLL_FORCE | FOLL_PIN | FOLL_GET)))
+ FOLL_FORCE | FOLL_PIN | FOLL_GET |
+ FOLL_FAST_ONLY)))
return -EINVAL;
start = untagged_addr(start) & PAGE_MASK;
@@ -2710,15 +2712,26 @@ static int internal_get_user_pages_fast(unsigned long
start, int nr_pages,
if (unlikely(!access_ok((void __user *)start, len)))
return -EFAULT;
+ /*
+* Disable interrupts. The nested form is used, in order to allow full,
+* general purpose use of this routine.
+*
+* With interrupts disabled, we block page table pages from being
+* freed from under us. See struct mmu_table_batch comments in
+* include/asm-generic/tlb.h for more details.
+*
+* We do not adopt an rcu_read_lock(.) here as we also want to
+* block IPIs that come from THPs splitting.
+*/
if (IS_ENABLED(CONFIG_HAVE_FAST_GUP) &&
gup_fast_permitted(start, end)) {
- local_irq_disable();
+ local_irq_save(flags);
gup_pgd_range(addr, end, gup_flags, pages, _pinned);
- local_irq_enable();
+ local_irq_restore(flags);
ret = nr_pinned;
}
- if (nr_pinned < nr_pages) {
+ if (nr_pinned < nr_pages && !(gup_flags & FOLL_FAST_ONLY)) {
/* Try to get the remaining pages with get_user_pages */
start += nr_pinned << PAGE_SHIFT;
pages += nr_pinned;
@@ -2750,45 +2763,29 @@ static int internal_get_user_pages_fast(unsigned long
start, int nr_pages,
int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages)
{
- unsigned long len, end;
- unsigned long flags;
- int nr_pinned = 0;
+ int nr_pinned;
/*
* Internally (within mm/gup.c), gup fast variants must set FOLL_GET,
* because gup fast is always a "pin with a +1 page refcount" request.
+*
+* FOLL_FAST_ONLY is required in order to match the API description of
+* this routine: no fall back to regular ("slow") GUP.
*/
- unsigned int gup_flags = FOLL_GET;
+ unsigned int gup_flags = FOLL_GET | FOLL_FAST_ONLY;
if (write)
gup_flags |= FOLL_WRITE;
- start = untagged_addr(start) & PAGE_MASK;
- len = (unsigned long) nr_pages << PAGE_SHIFT;
- end = start + len;
-
- if (end <= start)
- return 0;
- if (unlikely(!access_ok((void __user *)start, len)))
- return 0;
-
+ nr_pinned = internal_get_user_pages_fast(start, nr_pages, gup_flags,
+
[PATCH v2 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()
The purpose of posting this series is to launch a test in the intel-gfx-ci tree. (The patches have already been merged into Andrew's linux-mm tree.) This applies to today's linux.git (note the base-commit tag at the bottom). Changes since V1: * Fixed a bug in the refactoring patch: added FOLL_FAST_ONLY to the list of gup_flags *not* to WARN() on. This lead to a failure in the first intel-gfx-ci test run [1]. [1] https://lore.kernel.org/r/159008745422.32320.5724805750977048...@build.alporthouse.com Original cover letter: This needs to go through Andrew's -mm tree, due to adding a new gup.c routine. However, I would really love to have some testing from the drm/i915 folks, because I haven't been able to run-time test that part of it. Otherwise, though, the series has passed my basic run time testing: some LTP tests, some xfs and etx4 non-destructive xfstests, and an assortment of other smaller ones: vm selftests, io_uring_register, a few more. But that's only on one particular machine. Also, cross-compile tests for half a dozen arches all pass. Details: In order to convert the drm/i915 driver from get_user_pages() to pin_user_pages(), a FOLL_PIN equivalent of __get_user_pages_fast() was required. That led to refactoring __get_user_pages_fast(), with the following goals: 1) As above: provide a pin_user_pages*() routine for drm/i915 to call, in place of __get_user_pages_fast(), 2) Get rid of the gup.c duplicate code for walking page tables with interrupts disabled. This duplicate code is a minor maintenance problem anyway. 3) Make it easy for an upcoming patch from Souptick, which aims to convert __get_user_pages_fast() to use a gup_flags argument, instead of a bool writeable arg. Also, if this series looks good, we can ask Souptick to change the name as well, to whatever the consensus is. My initial recommendation is: get_user_pages_fast_only(), to match the new pin_user_pages_only(). John Hubbard (4): mm/gup: move __get_user_pages_fast() down a few lines in gup.c mm/gup: refactor and de-duplicate gup_fast() code mm/gup: introduce pin_user_pages_fast_only() drm/i915: convert get_user_pages() --> pin_user_pages() drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 22 +-- include/linux/mm.h | 3 + mm/gup.c| 153 3 files changed, 109 insertions(+), 69 deletions(-) base-commit: 051143e1602d90ea71887d92363edd539d411de5 -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] mm/gup: introduce pin_user_pages_fast_only()
This is the FOLL_PIN equivalent of __get_user_pages_fast(),
except with a more descriptive name, and gup_flags instead of
a boolean "write" in the argument list.
Signed-off-by: John Hubbard
---
include/linux/mm.h | 2 ++
mm/gup.c | 36
2 files changed, 38 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 84b601cab699..98be7289d7e9 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1820,6 +1820,8 @@ extern int mprotect_fixup(struct vm_area_struct *vma,
*/
int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
+int pin_user_pages_fast_only(unsigned long start, int nr_pages,
+unsigned int gup_flags, struct page **pages);
/*
* per-process(per-mm_struct) statistics.
*/
diff --git a/mm/gup.c b/mm/gup.c
index 4564b0dc7d0b..6fa9b2016a53 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2859,6 +2859,42 @@ int pin_user_pages_fast(unsigned long start, int
nr_pages,
}
EXPORT_SYMBOL_GPL(pin_user_pages_fast);
+/*
+ * This is the FOLL_PIN equivalent of __get_user_pages_fast(). Behavior is the
+ * same, except that this one sets FOLL_PIN instead of FOLL_GET.
+ *
+ * The API rules are the same, too: no negative values may be returned.
+ */
+int pin_user_pages_fast_only(unsigned long start, int nr_pages,
+unsigned int gup_flags, struct page **pages)
+{
+ int nr_pinned;
+
+ /*
+* FOLL_GET and FOLL_PIN are mutually exclusive. Note that the API
+* rules require returning 0, rather than -errno:
+*/
+ if (WARN_ON_ONCE(gup_flags & FOLL_GET))
+ return 0;
+ /*
+* FOLL_FAST_ONLY is required in order to match the API description of
+* this routine: no fall back to regular ("slow") GUP.
+*/
+ gup_flags |= (FOLL_PIN | FOLL_FAST_ONLY);
+ nr_pinned = internal_get_user_pages_fast(start, nr_pages, gup_flags,
+pages);
+ /*
+* This routine is not allowed to return negative values. However,
+* internal_get_user_pages_fast() *can* return -errno. Therefore,
+* correct for that here:
+*/
+ if (nr_pinned < 0)
+ nr_pinned = 0;
+
+ return nr_pinned;
+}
+EXPORT_SYMBOL_GPL(pin_user_pages_fast_only);
+
/**
* pin_user_pages_remote() - pin pages of a remote process (task != current)
*
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] mm/gup: move __get_user_pages_fast() down a few lines in gup.c
This is in order to avoid a forward declaration of
internal_get_user_pages_fast(), in the next patch.
This is code movement only--all generated code should
be identical.
Signed-off-by: John Hubbard
---
mm/gup.c | 112 +++
1 file changed, 56 insertions(+), 56 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 50cd9323efff..4502846d57f9 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2666,62 +2666,6 @@ static bool gup_fast_permitted(unsigned long start,
unsigned long end)
}
#endif
-/*
- * Like get_user_pages_fast() except it's IRQ-safe in that it won't fall back
to
- * the regular GUP.
- * Note a difference with get_user_pages_fast: this always returns the
- * number of pages pinned, 0 if no pages were pinned.
- *
- * If the architecture does not support this function, simply return with no
- * pages pinned.
- */
-int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
- struct page **pages)
-{
- unsigned long len, end;
- unsigned long flags;
- int nr_pinned = 0;
- /*
-* Internally (within mm/gup.c), gup fast variants must set FOLL_GET,
-* because gup fast is always a "pin with a +1 page refcount" request.
-*/
- unsigned int gup_flags = FOLL_GET;
-
- if (write)
- gup_flags |= FOLL_WRITE;
-
- start = untagged_addr(start) & PAGE_MASK;
- len = (unsigned long) nr_pages << PAGE_SHIFT;
- end = start + len;
-
- if (end <= start)
- return 0;
- if (unlikely(!access_ok((void __user *)start, len)))
- return 0;
-
- /*
-* Disable interrupts. We use the nested form as we can already have
-* interrupts disabled by get_futex_key.
-*
-* With interrupts disabled, we block page table pages from being
-* freed from under us. See struct mmu_table_batch comments in
-* include/asm-generic/tlb.h for more details.
-*
-* We do not adopt an rcu_read_lock(.) here as we also want to
-* block IPIs that come from THPs splitting.
-*/
-
- if (IS_ENABLED(CONFIG_HAVE_FAST_GUP) &&
- gup_fast_permitted(start, end)) {
- local_irq_save(flags);
- gup_pgd_range(start, end, gup_flags, pages, _pinned);
- local_irq_restore(flags);
- }
-
- return nr_pinned;
-}
-EXPORT_SYMBOL_GPL(__get_user_pages_fast);
-
static int __gup_longterm_unlocked(unsigned long start, int nr_pages,
unsigned int gup_flags, struct page **pages)
{
@@ -2794,6 +2738,62 @@ static int internal_get_user_pages_fast(unsigned long
start, int nr_pages,
return ret;
}
+/*
+ * Like get_user_pages_fast() except it's IRQ-safe in that it won't fall back
to
+ * the regular GUP.
+ * Note a difference with get_user_pages_fast: this always returns the
+ * number of pages pinned, 0 if no pages were pinned.
+ *
+ * If the architecture does not support this function, simply return with no
+ * pages pinned.
+ */
+int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
+ struct page **pages)
+{
+ unsigned long len, end;
+ unsigned long flags;
+ int nr_pinned = 0;
+ /*
+* Internally (within mm/gup.c), gup fast variants must set FOLL_GET,
+* because gup fast is always a "pin with a +1 page refcount" request.
+*/
+ unsigned int gup_flags = FOLL_GET;
+
+ if (write)
+ gup_flags |= FOLL_WRITE;
+
+ start = untagged_addr(start) & PAGE_MASK;
+ len = (unsigned long) nr_pages << PAGE_SHIFT;
+ end = start + len;
+
+ if (end <= start)
+ return 0;
+ if (unlikely(!access_ok((void __user *)start, len)))
+ return 0;
+
+ /*
+* Disable interrupts. We use the nested form as we can already have
+* interrupts disabled by get_futex_key.
+*
+* With interrupts disabled, we block page table pages from being
+* freed from under us. See struct mmu_table_batch comments in
+* include/asm-generic/tlb.h for more details.
+*
+* We do not adopt an rcu_read_lock(.) here as we also want to
+* block IPIs that come from THPs splitting.
+*/
+
+ if (IS_ENABLED(CONFIG_HAVE_FAST_GUP) &&
+ gup_fast_permitted(start, end)) {
+ local_irq_save(flags);
+ gup_pgd_range(start, end, gup_flags, pages, _pinned);
+ local_irq_restore(flags);
+ }
+
+ return nr_pinned;
+}
+EXPORT_SYMBOL_GPL(__get_user_pages_fast);
+
/**
* get_user_pages_fast() - pin user pages in memory
* @start: starting user address
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] video: fbdev: fix error handling for get_user_pages_fast()
Dealing with the return value of get_user_pages*() variants has a few
classic pitfalls, and this driver found one of them: the return value
might be zero, positive, or -errno. And if positive, it might be fewer
pages than were requested. And if fewer pages than requested, then
the caller should return (via put_page()) the pages that *were*
pinned.
This driver was doing that *except* that it had a problem with the
-errno case, which was being stored in an unsigned int, and which
would case an interesting mess if it ever happened: nr_pages would be
interpreted as a spectacularly huge unsigned value, rather than a
small negative value. Also, it was unnecessarily overriding a
potentially informative -errno, with -EINVAL, in some cases.
Instead: clamp the nr_pages to zero or positive, so that the error
handling works. And return the -errno value from get_user_pages*(),
unchanged, if we get one. And explain this with comments, seeing as
how it is error-prone.
Cc: Bartlomiej Zolnierkiewicz
Cc: Arnd Bergmann
Cc: Daniel Vetter
Cc: Gustavo A. R. Silva
Cc: Jani Nikula
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: John Hubbard
---
drivers/video/fbdev/pvr2fb.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/pvr2fb.c b/drivers/video/fbdev/pvr2fb.c
index f18d457175d9..ceb6ef590597 100644
--- a/drivers/video/fbdev/pvr2fb.c
+++ b/drivers/video/fbdev/pvr2fb.c
@@ -654,8 +654,22 @@ static ssize_t pvr2fb_write(struct fb_info *info, const
char *buf,
ret = get_user_pages_fast((unsigned long)buf, nr_pages, FOLL_WRITE,
pages);
if (ret < nr_pages) {
- nr_pages = ret;
- ret = -EINVAL;
+ if (ret < 0) {
+ /*
+* Clamp the unsigned nr_pages to zero so that the
+* error handling works. And leave ret at whatever
+* -errno value was returned from GUP.
+*/
+ nr_pages = 0;
+ } else {
+ nr_pages = ret;
+ /*
+* Use -EINVAL to represent a mildly desperate guess at
+* why we got fewer pages (maybe even zero pages) than
+* requested.
+*/
+ ret = -EINVAL;
+ }
goto out_unmap;
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] video: fbdev: fix error handling, convert to pin_user_pages*()
Hi, Note that I have only compile-tested this series, although that does also include cross-compiling for a few other arches. I'm hoping that this posting will lead to some run-time testing. Also: the proposed fix does not have a "Fixes:" tag, nor does it Cc stable. That's because the issue has been there since the dawn of git history for the kernel. If it's gone unnoticed this long, then there is clearly no need for the relatively fast track of putting it into stable, IMHO. But please correct me if that's wrong. Cc: Bartlomiej Zolnierkiewicz Cc: Arnd Bergmann Cc: Daniel Vetter Cc: Gustavo A. R. Silva Cc: Jani Nikula Cc: dri-devel@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org John Hubbard (2): video: fbdev: fix error handling for get_user_pages_fast() video: fbdev: convert get_user_pages() --> pin_user_pages() drivers/video/fbdev/pvr2fb.c | 24 ++-- 1 file changed, 18 insertions(+), 6 deletions(-) base-commit: 051143e1602d90ea71887d92363edd539d411de5 -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] video: fbdev: convert get_user_pages() --> pin_user_pages()
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Cc: Bartlomiej Zolnierkiewicz
Cc: Arnd Bergmann
Cc: Daniel Vetter
Cc: Gustavo A. R. Silva
Cc: Jani Nikula
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: John Hubbard
---
drivers/video/fbdev/pvr2fb.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/pvr2fb.c b/drivers/video/fbdev/pvr2fb.c
index ceb6ef590597..2d9f69b93392 100644
--- a/drivers/video/fbdev/pvr2fb.c
+++ b/drivers/video/fbdev/pvr2fb.c
@@ -652,7 +652,7 @@ static ssize_t pvr2fb_write(struct fb_info *info, const
char *buf,
if (!pages)
return -ENOMEM;
- ret = get_user_pages_fast((unsigned long)buf, nr_pages, FOLL_WRITE,
pages);
+ ret = pin_user_pages_fast((unsigned long)buf, nr_pages, FOLL_WRITE,
pages);
if (ret < nr_pages) {
if (ret < 0) {
/*
@@ -712,9 +712,7 @@ static ssize_t pvr2fb_write(struct fb_info *info, const
char *buf,
ret = count;
out_unmap:
- for (i = 0; i < nr_pages; i++)
- put_page(pages[i]);
-
+ unpin_user_pages(pages, nr_pages);
kfree(pages);
return ret;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm/gup: fixup gup.c for "mm/gup: refactor and de-duplicate gup_fast() code"
On 2020-05-21 19:46, Chris Wilson wrote:
Quoting John Hubbard (2020-05-22 00:38:41)
Include FOLL_FAST_ONLY in the list of flags to *not* WARN()
on, in internal_get_user_pages_fast().
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jani Nikula
Cc: "Joonas Lahtinen"
Cc: Matthew Auld
Cc: Matthew Wilcox
Cc: Rodrigo Vivi
Cc: Souptick Joarder
Cc: Tvrtko Ursulin
Signed-off-by: John Hubbard
---
Hi Andrew, Chris,
Andrew: This is a fixup that applies to today's (20200521) linux-next.
In that tree, this fixes up:
commit dfb8dfe80808 ("mm/gup: refactor and de-duplicate gup_fast() code")
Chris: I'd like to request another CI run for the drm/i915 changes, so
for that, would you prefer that I post a v2 of the series [1], or
is it easier for you to just apply this patch here, on top of [2]?
If you post your series again with this patch included to intel-gfx, CI
will pick it up. Or I'll do that in the morning.
-Chris
OK, perfect. I'll post a version for linux.git in a moment here.
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm/gup: fixup gup.c for "mm/gup: refactor and de-duplicate gup_fast() code"
Quoting John Hubbard (2020-05-22 00:38:41)
> Include FOLL_FAST_ONLY in the list of flags to *not* WARN()
> on, in internal_get_user_pages_fast().
>
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jani Nikula
> Cc: "Joonas Lahtinen"
> Cc: Matthew Auld
> Cc: Matthew Wilcox
> Cc: Rodrigo Vivi
> Cc: Souptick Joarder
> Cc: Tvrtko Ursulin
> Signed-off-by: John Hubbard
> ---
>
> Hi Andrew, Chris,
>
> Andrew: This is a fixup that applies to today's (20200521) linux-next.
> In that tree, this fixes up:
>
> commit dfb8dfe80808 ("mm/gup: refactor and de-duplicate gup_fast() code")
>
> Chris: I'd like to request another CI run for the drm/i915 changes, so
> for that, would you prefer that I post a v2 of the series [1], or
> is it easier for you to just apply this patch here, on top of [2]?
If you post your series again with this patch included to intel-gfx, CI
will pick it up. Or I'll do that in the morning.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] nouveau-next 5.8
Hey Dave, Daniel, - HD audio fixes on recent systems - vGPU detection (fail probe if we're on one, for now) - Interlaced mode fixes (mostly avoidance on Turing, which doesn't support it) - SVM improvements/fixes - NVIDIA format modifier support - Misc other fixes. Thanks, Ben. The following changes since commit c41219fda6e04255c44d37fd2c0d898c1c46abf1: Merge tag 'drm-intel-next-fixes-2020-05-20' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2020-05-21 10:44:33 +1000) are available in the Git repository at: git://github.com/skeggsb/nouveau linux-5.8 for you to fetch changes up to dc455f4c888365595c0a13da445e092422d55b8d: drm/nouveau/dispnv50: fix runtime pm imbalance on error (2020-05-22 11:13:53 +1000) Ben Skeggs (14): drm/nouveau: fix out-of-tree module build drm/nouveau/acr: ensure falcon providing acr functions is bootstrapped first drm/nouveau/core: add nvkm_subdev_new_() for bare subdevs drm/nouveau/ibus: use nvkm_subdev_new_() drm/nouveau/gr/gk20a: move MODULE_FIRMWARE firmware definitions drm/nouveau: remove open-coded version of remove_conflicting_pci_framebuffers() drm/nouveau/bios: move ACPI _ROM handling drm/nouveau/disp/gv100-: expose capabilities class drm/nouveau/device: use regular PRI accessors in chipset detection drm/nouveau/disp/nv50-: increase timeout on pio channel free() polling drm/nouveau/disp/hda/gt215-: pass head to nvkm_ior.hda.eld() drm/nouveau/disp/hda/gf119-: add HAL for programming device entry in SF drm/nouveau/disp/hda/gf119-: select HDA device entry based on bound head drm/nouveau/disp/hda/gv100-: NV_PDISP_SF_AUDIO_CNTRL0 register moved Colin Ian King (1): drm/nouveau/core/memory: remove redundant assignments to variable ret Dinghao Liu (4): drm/nouveau/debugfs: fix runtime pm imbalance on error drm/nouveau: fix runtime pm imbalance on error drm/nouveau: fix runtime pm imbalance on error drm/nouveau/dispnv50: fix runtime pm imbalance on error James Jones (4): drm: Generalized NV Block Linear DRM format mod drm/nouveau/kms: Add format mod prop to base/ovly/nvdisp drm/nouveau/kms: Check framebuffer size against bo drm/nouveau/kms: Support NVIDIA format modifiers Kai-Heng Feng (1): drm/nouveau: Use generic helper to check _PR3 presence Karol Herbst (3): drm/nouveau/device: rework mmio mapping code to get rid of second map drm/nouveau/device: detect if changing endianness failed drm/nouveau/device: detect vGPUs Lyude Paul (5): drm/nouveau/kms/nv50-: Initialize core channel in nouveau_display_create() drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing support drm/nouveau/kms/gv100-: Add support for interlaced modes drm/nouveau/kms/nv50-: Move 8BPC limit for MST into nv50_mstc_get_modes() drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST Ralph Campbell (3): drm/nouveau/svm: map pages after migration drm/nouveau/nouveau/hmm: fix nouveau_dmem_chunk allocations drm/nouveau/nouveau/hmm: fix migrate zero page to GPU Takashi Iwai (1): drm/nouveau/kms: Fix regression by audio component transition Thomas Zimmermann (4): drm/nouveau/kms: Remove unused fields from struct nouveau_framebuffer drm/nouveau/kms: Move struct nouveau_framebuffer.vma to struct nouveau_fbdev drm/nouveau/kms: Remove field nvbo from struct nouveau_framebuffer drm/nouveau/kms: Remove struct nouveau_framebuffer Zheng Bin (1): drm/nouveau/mmu: Remove unneeded semicolon Zou Wei (1): drm/nouveau/acr: Use kmemdup instead of kmalloc and memcpy drivers/gpu/drm/nouveau/Kbuild| 10 +- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 19 ++-- drivers/gpu/drm/nouveau/dispnv04/disp.c | 21 ++-- drivers/gpu/drm/nouveau/dispnv04/overlay.c| 21 ++-- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +- drivers/gpu/drm/nouveau/dispnv50/core.h | 7 ++ drivers/gpu/drm/nouveau/dispnv50/core507d.c | 15 +++ drivers/gpu/drm/nouveau/dispnv50/core827d.c | 1 + drivers/gpu/drm/nouveau/dispnv50/core907d.c | 1 + drivers/gpu/drm/nouveau/dispnv50/core917d.c | 1 + drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 26 + drivers/gpu/drm/nouveau/dispnv50/corec57d.c | 1 + drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 137 drivers/gpu/drm/nouveau/dispnv50/disp.h | 5 + drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 5 +- drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 5 +- drivers/gpu/drm/nouveau/dispnv50/pior507d.c | 8 ++
[PATCH] drm/radeon/dpm: Replace one-element array and use struct_size() helper
The current codebase makes use of one-element arrays in the following
form:
struct something {
int length;
u8 data[1];
};
struct something *instance;
instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);
but the preferred mechanism to declare variable-length types such as
these ones is a flexible array member[1][2], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on. So, replace
the one-element array with a flexible-array member.
Also, make use of the new struct_size() helper to properly calculate the
size of struct NISLANDS_SMC_SWSTATE.
This issue was found with the help of Coccinelle and, audited and fixed
_manually_.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdgpu/si_dpm.h | 2 +-
drivers/gpu/drm/radeon/ni_dpm.c | 7 ---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.h
b/drivers/gpu/drm/amd/amdgpu/si_dpm.h
index 6b7d292b919f3..bc0be6818e218 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.h
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.h
@@ -781,7 +781,7 @@ struct NISLANDS_SMC_SWSTATE
uint8_t levelCount;
uint8_t padding2;
uint8_t padding3;
-NISLANDS_SMC_HW_PERFORMANCE_LEVEL levels[1];
+NISLANDS_SMC_HW_PERFORMANCE_LEVEL levels[];
};
typedef struct NISLANDS_SMC_SWSTATE NISLANDS_SMC_SWSTATE;
diff --git a/drivers/gpu/drm/radeon/ni_dpm.c b/drivers/gpu/drm/radeon/ni_dpm.c
index b57c37ddd164c..7d81dde509dc9 100644
--- a/drivers/gpu/drm/radeon/ni_dpm.c
+++ b/drivers/gpu/drm/radeon/ni_dpm.c
@@ -2685,11 +2685,12 @@ static int ni_upload_sw_state(struct radeon_device
*rdev,
struct rv7xx_power_info *pi = rv770_get_pi(rdev);
u16 address = pi->state_table_start +
offsetof(NISLANDS_SMC_STATETABLE, driverState);
- u16 state_size = sizeof(NISLANDS_SMC_SWSTATE) +
- ((NISLANDS_MAX_SMC_PERFORMANCE_LEVELS_PER_SWSTATE - 1) *
sizeof(NISLANDS_SMC_HW_PERFORMANCE_LEVEL));
+ NISLANDS_SMC_SWSTATE *smc_state;
+ u16 state_size = struct_size(smc_state, levels,
+ NISLANDS_MAX_SMC_PERFORMANCE_LEVELS_PER_SWSTATE);
int ret;
- NISLANDS_SMC_SWSTATE *smc_state = kzalloc(state_size, GFP_KERNEL);
+ smc_state = kzalloc(state_size, GFP_KERNEL);
if (smc_state == NULL)
return -ENOMEM;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] mm/gup: fixup gup.c for "mm/gup: refactor and de-duplicate gup_fast() code"
Include FOLL_FAST_ONLY in the list of flags to *not* WARN()
on, in internal_get_user_pages_fast().
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jani Nikula
Cc: "Joonas Lahtinen"
Cc: Matthew Auld
Cc: Matthew Wilcox
Cc: Rodrigo Vivi
Cc: Souptick Joarder
Cc: Tvrtko Ursulin
Signed-off-by: John Hubbard
---
Hi Andrew, Chris,
Andrew: This is a fixup that applies to today's (20200521) linux-next.
In that tree, this fixes up:
commit dfb8dfe80808 ("mm/gup: refactor and de-duplicate gup_fast() code")
Chris: I'd like to request another CI run for the drm/i915 changes, so
for that, would you prefer that I post a v2 of the series [1], or
is it easier for you to just apply this patch here, on top of [2]?
[1] https://lore.kernel.org/r/20200519002124.2025955-1-jhubb...@nvidia.com
[2]
https://lore.kernel.org/r/158985123351.31239.10766458886430429...@emeril.freedesktop.org
thanks,
John Hubbard
NVIDIA
mm/gup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/gup.c b/mm/gup.c
index dd8895f2fafa1..ada6aa79576dc 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2724,7 +2724,8 @@ static int internal_get_user_pages_fast(unsigned long
start, int nr_pages,
int nr_pinned = 0, ret = 0;
if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM |
- FOLL_FORCE | FOLL_PIN | FOLL_GET)))
+ FOLL_FORCE | FOLL_PIN | FOLL_GET |
+ FOLL_FAST_ONLY)))
return -EINVAL;
start = untagged_addr(start) & PAGE_MASK;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
> On 5/21/20 10:42 AM, Ira Weiny wrote:
> > On Thu, May 21, 2020 at 09:05:41AM -0700, Guenter Roeck wrote:
> >> On 5/19/20 10:13 PM, Ira Weiny wrote:
> >>> On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> >> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com
> wrote:
> >>> From: Ira Weiny
> >>>
> >>> The kunmap_atomic clean up failed to remove one set of
> >>> pagefault/preempt enables when vaddr is not in the fixmap.
> >>>
> >>> Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate
> >>> code")
> >>> Signed-off-by: Ira Weiny
> >>
> >> microblazeel works with this patch,
> >
> > Awesome... Andrew in my rush yesterday I should have put a
> > reported by on the patch for Guenter as well.
> >
> > Sorry about that Guenter,
>
> No worries.
>
> > Ira
> >
> >> as do the nosmp sparc32 boot tests, but sparc32 boot tests with
> >> SMP enabled still fail with lots of messages such as:
> >>
> >> BUG: Bad page state in process swapper/0 pfn:006a1
> >> page:f0933420 refcount:0 mapcount:1 mapping:(ptrval) index:0x1
> >> flags: 0x0()
> >> raw: 0100 0122 0001
> >> page dumped because: nonzero mapcount
> Modules
> >> linked in:
> >> CPU: 0 PID: 1 Comm: swapper/0 Tainted: GB
> >> 5.7.0-rc6-next-
> 20200518-2-gb178d2d56f29 #1
> >> [f00e7ab8 :
> >> bad_page+0xa8/0x108 ]
> >> [f00e8b54 :
> >> free_pcppages_bulk+0x154/0x52c ]
> >> [f00ea024 :
> >> free_unref_page+0x54/0x6c ]
> >> [f00ed864 :
> >> free_reserved_area+0x58/0xec ]
> >> [f0527104 :
> >> kernel_init+0x14/0x110 ]
> >> [f000b77c :
> >> ret_from_kernel_thread+0xc/0x38 ]
> >> [ :
> >> 0x0 ]
> >>
> >> Code path leading to that message is different but always the
> >> same from free_unref_page().
> >>>
> >>> Actually it occurs to me that the patch consolidating kmap_prot is
> >>> odd for sparc 32 bit...
> >>>
> >>> Its a long shot but could you try reverting this patch?
> >>>
> >>> 4ea7d2419e3f kmap: consolidate kmap_prot definitions
> >>>
> >>
> >> That is not easy to revert, unfortunately, due to several follow-up
> patches.
> >
> > I have gotten your sparc tests to run and they all pass...
> >
> > 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh
> > Build reference: v5.7-rc4-17-g852b6f2edc0f
> >
>
> That doesn't look like it is linux-next, which I guess means that something
> else in linux-next breaks it. What is your qemu version ?
Ah yea that was just 5.7-rc4 with my patch set applied. Yes must be something
else or an interaction with my patch set.
Did I see another email with Mike which may fix this?
Ira
>
> Thanks,
> Guenter
>
> > Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed
> > Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed
> > Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed
> > Building sparc32:SS-4:nosmp:initrd ... running . passed
> > Building sparc32:SS-5:nosmp:scsi:hd ... running . passed
> > Building sparc32:SS-10:nosmp:scsi:cd ... running . passed
> > Building sparc32:SS-20:nosmp:scsi:hd ... running . passed
> > Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed
> > Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . passed
> > Building sparc32:SS-4:smp:scsi:hd ... running . passed
> > Building sparc32:SS-5:smp:scsi:cd ... running . passed
> > Building sparc32:SS-10:smp:scsi:hd ... running . passed
> > Building sparc32:SS-20:smp:scsi:hd ... running . passed
> > Building sparc32:SS-600MP:smp:scsi:hd ... running . passed
> > Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed
> >
> > Is there another test I need to run?
> >
> > Ira
> >
> >
> >>
> >> Guenter
> >>
> >>> Alternately I will need to figure out how to run the sparc on qemu here...
> >>>
> >>> Thanks very much for all the testing though! :-D
> >>>
> >>> Ira
> >>>
> >>
> >> Still testing ppc images.
> >>
>
> ppc image tests are passing with this patch.
>
> Guenter
> >>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-5.7
Hi Dave, Daniel, Fixes for 5.7. The following changes since commit 5a3f610877e9d08968ea7237551049581f02b163: drm/edid: Add Oculus Rift S to non-desktop list (2020-05-20 12:56:49 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.7-2020-05-21 for you to fetch changes up to 31ecebee9c36d5e5e113a357a655d993fa916174: drm/amd/display: Defer cursor lock until after VUPDATE (2020-05-20 17:32:13 -0400) amd-drm-fixes-5.7-2020-05-21: amdgpu: - DP fix - Floating point fix - Fix cursor stutter issue Nicholas Kazlauskas (1): drm/amd/display: Defer cursor lock until after VUPDATE Rodrigo Siqueira (1): drm/amd/display: Remove dml_common_def file Vladimir Stempen (1): drm/amd/display: DP training to set properly SCRAMBLING_DISABLE drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 27 + .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 69 +- .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.h | 5 ++ drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c | 1 + drivers/gpu/drm/amd/display/dc/dcn20/dcn20_init.c | 1 + drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c | 1 + drivers/gpu/drm/amd/display/dc/dml/Makefile| 2 - .../display/dc/dml/dcn20/display_rq_dlg_calc_20.h | 1 - .../dc/dml/dcn20/display_rq_dlg_calc_20v2.h| 1 - .../display/dc/dml/dcn21/display_rq_dlg_calc_21.h | 2 +- .../gpu/drm/amd/display/dc/dml/display_mode_lib.h | 6 +- .../gpu/drm/amd/display/dc/dml/display_mode_vba.h | 2 - .../amd/display/dc/dml/display_rq_dlg_helpers.h| 1 - .../amd/display/dc/dml/dml1_display_rq_dlg_calc.h | 2 - .../gpu/drm/amd/display/dc/dml/dml_common_defs.c | 43 -- .../gpu/drm/amd/display/dc/dml/dml_common_defs.h | 37 .../gpu/drm/amd/display/dc/dml/dml_inline_defs.h | 15 - drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h | 5 ++ 18 files changed, 126 insertions(+), 95 deletions(-) delete mode 100644 drivers/gpu/drm/amd/display/dc/dml/dml_common_defs.c delete mode 100644 drivers/gpu/drm/amd/display/dc/dml/dml_common_defs.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vblank: Fix -Wformat compile warnings on some arches
On Thu, May 21, 2020 at 04:46:47PM -0400, Lyude Paul wrote:
> On some architectures like ppc64le and aarch64, compiling with
> -Wformat=1 will throw the following warnings:
>
> In file included from drivers/gpu/drm/drm_vblank.c:33:
> drivers/gpu/drm/drm_vblank.c: In function 'drm_update_vblank_count':
> drivers/gpu/drm/drm_vblank.c:273:16: warning: format '%llu' expects
> argument of type 'long long unsigned int', but argument 4 has type
> 'long int' [-Wformat=]
> DRM_DEBUG_VBL("updating vblank count on crtc %u:"
> ^~~
> ./include/drm/drm_print.h:407:22: note: in definition of macro
> 'DRM_DEBUG_VBL'
> drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__)
> ^~~
> drivers/gpu/drm/drm_vblank.c:274:22: note: format string is defined here
>" current=%llu, diff=%u, hw=%u hw_last=%u\n",
> ~~~^
> %lu
>
> So, fix that with a typecast.
>
> Signed-off-by: Lyude Paul
> Co-developed-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_vblank.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index acb3c3f65b579..1a96db2dd16fa 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -342,7 +342,7 @@ static void drm_update_vblank_count(struct drm_device
> *dev, unsigned int pipe,
>
> DRM_DEBUG_VBL("updating vblank count on crtc %u:"
> " current=%llu, diff=%u, hw=%u hw_last=%u\n",
> - pipe, atomic64_read(>count), diff,
> + pipe, (unsigned long long)atomic64_read(>count),
> diff,
> cur_vblank, vblank->last);
While touching this you could consider introducing drm_dbg_vbl().
An maybe as a follow-up patch replace all logging in this file with the drm_*
variants.
Sam
>
> if (diff == 0) {
> --
> 2.26.2
>
> ___
> 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] drm/vblank: Fix -Wformat compile warnings on some arches
On some architectures like ppc64le and aarch64, compiling with
-Wformat=1 will throw the following warnings:
In file included from drivers/gpu/drm/drm_vblank.c:33:
drivers/gpu/drm/drm_vblank.c: In function 'drm_update_vblank_count':
drivers/gpu/drm/drm_vblank.c:273:16: warning: format '%llu' expects
argument of type 'long long unsigned int', but argument 4 has type
'long int' [-Wformat=]
DRM_DEBUG_VBL("updating vblank count on crtc %u:"
^~~
./include/drm/drm_print.h:407:22: note: in definition of macro
'DRM_DEBUG_VBL'
drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__)
^~~
drivers/gpu/drm/drm_vblank.c:274:22: note: format string is defined here
" current=%llu, diff=%u, hw=%u hw_last=%u\n",
~~~^
%lu
So, fix that with a typecast.
Signed-off-by: Lyude Paul
Co-developed-by: Dave Airlie
---
drivers/gpu/drm/drm_vblank.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index acb3c3f65b579..1a96db2dd16fa 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -342,7 +342,7 @@ static void drm_update_vblank_count(struct drm_device *dev,
unsigned int pipe,
DRM_DEBUG_VBL("updating vblank count on crtc %u:"
" current=%llu, diff=%u, hw=%u hw_last=%u\n",
- pipe, atomic64_read(>count), diff,
+ pipe, (unsigned long long)atomic64_read(>count),
diff,
cur_vblank, vblank->last);
if (diff == 0) {
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Solved: [PATCH 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()
On 2020-05-21 12:11, John Hubbard wrote: On 2020-05-21 11:57, Chris Wilson wrote: Quoting John Hubbard (2020-05-19 01:21:20) This needs to go through Andrew's -mm tree, due to adding a new gup.c routine. However, I would really love to have some testing from the drm/i915 folks, because I haven't been able to run-time test that part of it. CI hit <4> [185.667750] WARNING: CPU: 0 PID: 1387 at mm/gup.c:2699 internal_get_user_pages_fast+0x63a/0xac0 OK, what happened here is that it's WARN()'ing due to passing in the new FOLL_FAST_ONLY flag, which was not added to the whitelist. So the fix is easy, and should be applied to the refactoring patch. I'll send out a v2 of the series, which will effectively have this applied: diff --git a/mm/gup.c b/mm/gup.c index 6cbe98c93466..4f0ca3f849d1 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -2696,7 +2696,8 @@ static int internal_get_user_pages_fast(unsigned long start, int nr_pages, int nr_pinned = 0, ret = 0; if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM | - FOLL_FORCE | FOLL_PIN | FOLL_GET))) + FOLL_FORCE | FOLL_PIN | FOLL_GET | + FOLL_FAST_ONLY))) return -EINVAL; start = untagged_addr(start) & PAGE_MASK; <4> [185.667752] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp snd_hda_intel snd_intel_dspcfg crct10dif_pclmul snd_hda_codec crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel cdc_ether usbnet mii snd_pcm e1000e mei_me ptp pps_core mei intel_lpss_pci prime_numbers <4> [185.667774] CPU: 0 PID: 1387 Comm: gem_userptr_bli Tainted: G U 5.7.0-rc5-CI-Patchwork_17704+ #1 <4> [185.66] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019 <4> [185.667782] RIP: 0010:internal_get_user_pages_fast+0x63a/0xac0 <4> [185.667785] Code: 24 40 08 48 39 5c 24 38 49 89 df 0f 85 74 fc ff ff 48 83 44 24 50 08 48 39 5c 24 58 49 89 dc 0f 85 e0 fb ff ff e9 14 fe ff ff <0f> 0b b8 ea ff ff ff e9 36 fb ff ff 4c 89 e8 48 21 e8 48 39 e8 0f <4> [185.667789] RSP: 0018:c90001133c38 EFLAGS: 00010206 <4> [185.667792] RAX: RBX: RCX: 8884999ee800 <4> [185.667795] RDX: 000c0001 RSI: 0100 RDI: 7f419e774000 <4> [185.667798] RBP: 888453dbf040 R08: R09: 0001 <4> [185.667800] R10: R11: R12: 888453dbf380 <4> [185.667803] R13: 8884999ee800 R14: 888453dbf3e8 R15: 0040 <4> [185.667806] FS: 7f419e875e40() GS:88849fe0() knlGS: <4> [185.667808] CS: 0010 DS: ES: CR0: 80050033 <4> [185.667811] CR2: 7f419e873000 CR3: 000458bd2004 CR4: 00760ef0 <4> [185.667814] PKRU: 5554 <4> [185.667816] Call Trace: <4> [185.667912] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] <4> [185.667918] ? mark_held_locks+0x49/0x70 <4> [185.667998] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] <4> [185.668073] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] and then panicked, across a range of systems. -Chris btw, the panic seems to indicate an additional, pre-existing problem: i915_gem_userptr_get_pages(), in this case at least, is not able to recover from a get_user_pages/pin_user_pages failure. thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()
On 2020-05-21 11:57, Chris Wilson wrote: Quoting John Hubbard (2020-05-19 01:21:20) This needs to go through Andrew's -mm tree, due to adding a new gup.c routine. However, I would really love to have some testing from the drm/i915 folks, because I haven't been able to run-time test that part of it. CI hit <4> [185.667750] WARNING: CPU: 0 PID: 1387 at mm/gup.c:2699 internal_get_user_pages_fast+0x63a/0xac0 <4> [185.667752] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp snd_hda_intel snd_intel_dspcfg crct10dif_pclmul snd_hda_codec crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel cdc_ether usbnet mii snd_pcm e1000e mei_me ptp pps_core mei intel_lpss_pci prime_numbers <4> [185.667774] CPU: 0 PID: 1387 Comm: gem_userptr_bli Tainted: G U 5.7.0-rc5-CI-Patchwork_17704+ #1 <4> [185.66] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019 <4> [185.667782] RIP: 0010:internal_get_user_pages_fast+0x63a/0xac0 <4> [185.667785] Code: 24 40 08 48 39 5c 24 38 49 89 df 0f 85 74 fc ff ff 48 83 44 24 50 08 48 39 5c 24 58 49 89 dc 0f 85 e0 fb ff ff e9 14 fe ff ff <0f> 0b b8 ea ff ff ff e9 36 fb ff ff 4c 89 e8 48 21 e8 48 39 e8 0f <4> [185.667789] RSP: 0018:c90001133c38 EFLAGS: 00010206 <4> [185.667792] RAX: RBX: RCX: 8884999ee800 <4> [185.667795] RDX: 000c0001 RSI: 0100 RDI: 7f419e774000 <4> [185.667798] RBP: 888453dbf040 R08: R09: 0001 <4> [185.667800] R10: R11: R12: 888453dbf380 <4> [185.667803] R13: 8884999ee800 R14: 888453dbf3e8 R15: 0040 <4> [185.667806] FS: 7f419e875e40() GS:88849fe0() knlGS: <4> [185.667808] CS: 0010 DS: ES: CR0: 80050033 <4> [185.667811] CR2: 7f419e873000 CR3: 000458bd2004 CR4: 00760ef0 <4> [185.667814] PKRU: 5554 <4> [185.667816] Call Trace: <4> [185.667912] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] <4> [185.667918] ? mark_held_locks+0x49/0x70 <4> [185.667998] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] <4> [185.668073] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] and then panicked, across a range of systems. -Chris Thanks for this report! I'm looking into it now. thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()
Quoting John Hubbard (2020-05-19 01:21:20) > This needs to go through Andrew's -mm tree, due to adding a new gup.c > routine. However, I would really love to have some testing from the > drm/i915 folks, because I haven't been able to run-time test that part > of it. CI hit <4> [185.667750] WARNING: CPU: 0 PID: 1387 at mm/gup.c:2699 internal_get_user_pages_fast+0x63a/0xac0 <4> [185.667752] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp snd_hda_intel snd_intel_dspcfg crct10dif_pclmul snd_hda_codec crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel cdc_ether usbnet mii snd_pcm e1000e mei_me ptp pps_core mei intel_lpss_pci prime_numbers <4> [185.667774] CPU: 0 PID: 1387 Comm: gem_userptr_bli Tainted: G U 5.7.0-rc5-CI-Patchwork_17704+ #1 <4> [185.66] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019 <4> [185.667782] RIP: 0010:internal_get_user_pages_fast+0x63a/0xac0 <4> [185.667785] Code: 24 40 08 48 39 5c 24 38 49 89 df 0f 85 74 fc ff ff 48 83 44 24 50 08 48 39 5c 24 58 49 89 dc 0f 85 e0 fb ff ff e9 14 fe ff ff <0f> 0b b8 ea ff ff ff e9 36 fb ff ff 4c 89 e8 48 21 e8 48 39 e8 0f <4> [185.667789] RSP: 0018:c90001133c38 EFLAGS: 00010206 <4> [185.667792] RAX: RBX: RCX: 8884999ee800 <4> [185.667795] RDX: 000c0001 RSI: 0100 RDI: 7f419e774000 <4> [185.667798] RBP: 888453dbf040 R08: R09: 0001 <4> [185.667800] R10: R11: R12: 888453dbf380 <4> [185.667803] R13: 8884999ee800 R14: 888453dbf3e8 R15: 0040 <4> [185.667806] FS: 7f419e875e40() GS:88849fe0() knlGS: <4> [185.667808] CS: 0010 DS: ES: CR0: 80050033 <4> [185.667811] CR2: 7f419e873000 CR3: 000458bd2004 CR4: 00760ef0 <4> [185.667814] PKRU: 5554 <4> [185.667816] Call Trace: <4> [185.667912] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] <4> [185.667918] ? mark_held_locks+0x49/0x70 <4> [185.667998] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] <4> [185.668073] ? i915_gem_userptr_get_pages+0x1c6/0x290 [i915] and then panicked, across a range of systems. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: arm-smmu: Add sc7180 compatible string
On Mon, May 18, 2020 at 01:59:49PM -0700, Doug Anderson wrote: > On Mon, May 18, 2020 at 7:39 AM Will Deacon wrote: > > On Fri, May 15, 2020 at 12:05:39PM -0700, Doug Anderson wrote: > > > On Fri, May 1, 2020 at 3:30 AM Sharat Masetty > > > wrote: > > > > > > > > This patch simply adds a new compatible string for SC7180 platform. > > > > > > > > Signed-off-by: Sharat Masetty > > > > --- > > > > Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > > > > b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > > > > index 6515dbe..986098b 100644 > > > > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > > > > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > > > > @@ -28,6 +28,7 @@ properties: > > > >- enum: > > > >- qcom,msm8996-smmu-v2 > > > >- qcom,msm8998-smmu-v2 > > > > + - qcom,sc7180-smmu-v2 > > > >- qcom,sdm845-smmu-v2 > > > >- const: qcom,smmu-v2 > > > > > > Is anything blocking this patch from landing now? > > > > I thought updates to the bindings usually went via Rob and the device-tree > > tree, but neither of those are on cc. > > > > Perhaps resend with that fixed? > > Ah, I guess I wasn't familiar with how things worked for this file, or > maybe things have changed recently? I'm used to most bindings going > through the same tree as the drivers that use them. Usually if things > are at all complicated maintainers wait for an Ack from Rob (so he > should have been CCed for sure) and then land. Just to clear this up: I'm happy to take DT stuff like this, but preferably with Rob's ack so that I know that (a) it's not a load of rubbish and (b) it probably won't conflict with his tree. So having the DT folks omitted from the CC list just rings alarm bells for me. > In this case it actually looks like Bjorn landed it in the Qualcomm > and I just didn't realize it. That seems like it should be fine since > it's in the middle of a clause that's all Qualcomm and the change > shouldn't be controversial in any way. :-) Ok! Will ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207833] New: Brightness control not working on ASUS TUF FA506IU (AMD Ryzen 7 4800H / Nvidia GTX 1660 Ti)
https://bugzilla.kernel.org/show_bug.cgi?id=207833 Bug ID: 207833 Summary: Brightness control not working on ASUS TUF FA506IU (AMD Ryzen 7 4800H / Nvidia GTX 1660 Ti) Product: Drivers Version: 2.5 Kernel Version: 5.6.12-1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: julen.pa...@outlook.es Regression: No Hello, I've just bought an ASUS TUF FA506IU with and AMD Ryzen 7 4800H / Nvidia GTX 1660 Ti setup. Even if this is quite new hardware, I'd say that the only thing that is not working at all is the brightness control. It's not working with the function keys, nor from the energy settings, nor with xbacklight. Actually, it's working a little; I can find a subtle difference between the max value and the last 5 values, but that's it. Setting it to the minimum still makes it way too bright. I've noticed that this could be a range mismatch between "brightness" and "max_brightness", and "actual_brightness". First are in 8 bit ranges, whereas the actual brightness is in 16 bit range. I've tried some luck patching the kernel to return an 8-bit value (https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c#L299), but doing just that doesn't work (even if the "actual_brightness" was showing an 8 bit value). In my case, the full path is "/sys/class/backlight/amdgpu_bl1/". I've also tried different acpi_backlight parameters with no luck. I leave the output of lsmod | grep asus: asus_wmi 40960 0 sparse_keymap 16384 1 asus_wmi rfkill 28672 9 asus_wmi,bluetooth,cfg80211 battery24576 1 asus_wmi wmi36864 2 asus_wmi,wmi_bmof asus_wireless 20480 0 inxi -F: System:Host: TUF-FA506IU Kernel: 5.6.12-1-MANJARO x86_64 bits: 64 Desktop: KDE Plasma 5.18.5 Distro: Manjaro Linux Machine: Type: Laptop System: ASUSTeK product: TUF Gaming FA506IU_FA506IU v: 1.0 serial: Mobo: ASUSTeK model: FA506IU v: 1.0 serial: UEFI: American Megatrends v: FA506IU.302 date: 03/04/2020 Battery: ID-1: BAT1 charge: 47.9 Wh condition: 47.9/48.1 Wh (100%) CPU: Topology: 8-Core model: AMD Ryzen 7 4800H with Radeon Graphics bits: 64 type: MT MCP L2 cache: 4096 KiB Speed: 2405 MHz min/max: 1400/2900 MHz Core speeds (MHz): 1: 1875 2: 2497 3: 1397 4: 1397 5: 1397 6: 1397 7: 1397 8: 1397 9: 1397 10: 1396 11: 2963 12: 1673 13: 1800 14: 1548 15: 1397 16: 1396 Graphics: Device-1: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] driver: nvidia v: 440.82 Device-2: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.8 driver: amdgpu,nvidia resolution: 1920x1080~144Hz, 2560x1440~60Hz OpenGL: renderer: AMD RENOIR (DRM 3.36.0 5.6.12-1-MANJARO LLVM 10.0.0) v: 4.6 Mesa 20.0.6 Audio: Device-1: NVIDIA TU116 High Definition Audio driver: snd_hda_intel Device-2: Advanced Micro Devices [AMD/ATI] driver: snd_hda_intel Device-3: Advanced Micro Devices [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor driver: N/A Device-4: Advanced Micro Devices [AMD] Family 17h HD Audio driver: snd_hda_intel Sound Server: ALSA v: k5.6.12-1-MANJARO Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 IF: enp2s0 state: down mac: a8:5e:45:36:94:32 Device-2: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter driver: rtw_pci IF: wlp3s0 state: up mac: 70:66:55:09:8c:e3 Drives:Local Storage: total: 476.94 GiB used: 32.41 GiB (6.8%) ID-1: /dev/nvme0n1 vendor: Kingston model: OM8PCP3512F-AB size: 476.94 GiB Partition: ID-1: / size: 48.97 GiB used: 25.95 GiB (53.0%) fs: ext4 dev: /dev/nvme0n1p5 ID-2: /home size: 108.67 GiB used: 6.46 GiB (5.9%) fs: ext4 dev: /dev/nvme0n1p7 ID-3: swap-1 size: 3.03 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/nvme0n1p8 Sensors: Message: No sensors data was found. Is sensors configured? Info: Processes: 349 Uptime: 27m Memory: 7.20 GiB used: 3.04 GiB (42.2%) Shell: zsh inxi: 3.0.37 -- 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] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Thu, May 21, 2020 at 09:05:41AM -0700, Guenter Roeck wrote:
> On 5/19/20 10:13 PM, Ira Weiny wrote:
> > On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> >> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> >>> On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > The kunmap_atomic clean up failed to remove one set of pagefault/preempt
> > enables when vaddr is not in the fixmap.
> >
> > Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
> > Signed-off-by: Ira Weiny
>
> microblazeel works with this patch,
> >>>
> >>> Awesome... Andrew in my rush yesterday I should have put a reported by
> >>> on the
> >>> patch for Guenter as well.
> >>>
> >>> Sorry about that Guenter,
> >>
> >> No worries.
> >>
> >>> Ira
> >>>
> as do the nosmp sparc32 boot tests,
> but sparc32 boot tests with SMP enabled still fail with lots of messages
> such as:
>
> BUG: Bad page state in process swapper/0 pfn:006a1
> page:f0933420 refcount:0 mapcount:1 mapping:(ptrval) index:0x1
> flags: 0x0()
> raw: 0100 0122 0001
>
> page dumped because: nonzero mapcount
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Tainted: GB
> 5.7.0-rc6-next-20200518-2-gb178d2d56f29 #1
> [f00e7ab8 :
> bad_page+0xa8/0x108 ]
> [f00e8b54 :
> free_pcppages_bulk+0x154/0x52c ]
> [f00ea024 :
> free_unref_page+0x54/0x6c ]
> [f00ed864 :
> free_reserved_area+0x58/0xec ]
> [f0527104 :
> kernel_init+0x14/0x110 ]
> [f000b77c :
> ret_from_kernel_thread+0xc/0x38 ]
> [ :
> 0x0 ]
>
> Code path leading to that message is different but always the same
> from free_unref_page().
> >
> > Actually it occurs to me that the patch consolidating kmap_prot is odd for
> > sparc 32 bit...
> >
> > Its a long shot but could you try reverting this patch?
> >
> > 4ea7d2419e3f kmap: consolidate kmap_prot definitions
> >
>
> That is not easy to revert, unfortunately, due to several follow-up patches.
I have gotten your sparc tests to run and they all pass...
08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh
Build reference: v5.7-rc4-17-g852b6f2edc0f
Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed
Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed
Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed
Building sparc32:SS-4:nosmp:initrd ... running . passed
Building sparc32:SS-5:nosmp:scsi:hd ... running . passed
Building sparc32:SS-10:nosmp:scsi:cd ... running . passed
Building sparc32:SS-20:nosmp:scsi:hd ... running . passed
Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed
Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . passed
Building sparc32:SS-4:smp:scsi:hd ... running . passed
Building sparc32:SS-5:smp:scsi:cd ... running . passed
Building sparc32:SS-10:smp:scsi:hd ... running . passed
Building sparc32:SS-20:smp:scsi:hd ... running . passed
Building sparc32:SS-600MP:smp:scsi:hd ... running . passed
Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed
Is there another test I need to run?
Ira
>
> Guenter
>
> > Alternately I will need to figure out how to run the sparc on qemu here...
> >
> > Thanks very much for all the testing though! :-D
> >
> > Ira
> >
>
> Still testing ppc images.
>
> >>
> >> ppc image tests are passing with this patch.
> >>
> >> Guenter
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL v2] mediatek drm next for 5.8
Hi, Dave: Dave Airlie 於 2020年5月20日 週三 下午1:47寫道： > > On Wed, 20 May 2020 at 15:44, Dave Airlie wrote: > > > > On Mon, 18 May 2020 at 10:06, Chun-Kuang Hu wrote: > > > > > > Hi, Dave & Daniel: > > > > > > This include dpi pin mode swap, config mipi_tx current and impedance, > > > and some fixup. I drop drm_bridge patches in this version. > > > > > > The following changes since commit > > > 8f3d9f354286745c751374f5f1fcafee6b3f3136: > > > Linux 5.7-rc1 (2020-04-12 12:35:55 -0700) > > > are available in the Git repository at: > > > https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git > > > tags/mediatek-drm-next-5.8 > > > for you to fetch changes up to 007d274a017bb4e2ef7b922c2f54f40cf2073664: > > > > Did you edit this by hand or pass it through some mailserver that > > chewed it up, I had to reconstruct this pull from the above bits, I've > > no idea why it's so messed up in the first place. > > and why does it contain an unexplained backmerge? > > Merge tag 'v5.7-next-drm-stable' of > ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux > into mediatek-drm-next > > Please don't ever backmerge fixes into next pull, without a long > explaination or if you really need it ask us first, > > Please resend this again cleaned up. OK, to make things easier, I just resend and cleaned up. If one day I need a backmerge fixes, I would ask you first. Regards, Chun-Kuang. > > Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL v2] mediatek drm next for 5.8
Hi, Dave: Dave Airlie 於 2020年5月20日 週三 下午1:44寫道： > > On Mon, 18 May 2020 at 10:06, Chun-Kuang Hu wrote: > > > > Hi, Dave & Daniel: > > > > This include dpi pin mode swap, config mipi_tx current and impedance, > > and some fixup. I drop drm_bridge patches in this version. > > > > The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136: > > Linux 5.7-rc1 (2020-04-12 12:35:55 -0700) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git > > tags/mediatek-drm-next-5.8 > > for you to fetch changes up to 007d274a017bb4e2ef7b922c2f54f40cf2073664: > > Did you edit this by hand or pass it through some mailserver that > chewed it up, I had to reconstruct this pull from the above bits, I've > no idea why it's so messed up in the first place. The idea is that gmail would wrap words, so I change to use 'git send-email' in v3. Regards, Chun-Kuang. > > Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #54 from michael (lkb...@deegan.id.au) --- It seems that since kernel 5.6 (or at least Debian's version thereof), I no longer need to fiddle with /sys/class/drm/card0/device/hwmon/hwmon3/pwm1_enable. The default value (1) seems to do the right thing now. Progress! Mind you, lmsensors is still unable to report fan speed, and gives nonsensical values for crit/hyst temperatures. I have a feeling that further improvements to power management may be possible too. amdgpu-pci-0100 Adapter: PCI adapter vddgfx: +1.00 V fan1: N/A (min =0 RPM, max =0 RPM) edge: +73.0°C (crit = +104000.0°C, hyst = -273.1°C) power1: 58.21 W (cap = 208.00 W) -- 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] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote: > > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote: > > > as do the nosmp sparc32 boot tests, > > > but sparc32 boot tests with SMP enabled still fail with lots of messages > > > such as: > > > > > > BUG: Bad page state in process swapper/0 pfn:006a1 > > > page:f0933420 refcount:0 mapcount:1 mapping:(ptrval) index:0x1 > > > flags: 0x0() > > > raw: 0100 0122 0001 > > > > > > page dumped because: nonzero mapcount > > > Modules linked in: > > > CPU: 0 PID: 1 Comm: swapper/0 Tainted: GB > > > 5.7.0-rc6-next-20200518-2-gb178d2d56f29 #1 > > > [f00e7ab8 : > > > bad_page+0xa8/0x108 ] > > > [f00e8b54 : > > > free_pcppages_bulk+0x154/0x52c ] > > > [f00ea024 : > > > free_unref_page+0x54/0x6c ] > > > [f00ed864 : > > > free_reserved_area+0x58/0xec ] > > > [f0527104 : > > > kernel_init+0x14/0x110 ] > > > [f000b77c : > > > ret_from_kernel_thread+0xc/0x38 ] > > > [ : > > > 0x0 ] > > > > > > Code path leading to that message is different but always the same > > > from free_unref_page(). > > > > > > Still testing ppc images. > > > > > ppc image tests are passing with this patch. How about sparc? I finally got your scripts to run on sparc and everything looks to be passing? Are we all good now? Thanks again! Ira ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/4] arm: dts: mt7623: add display subsystem related device nodes
Hi Frank,
On 16/04/2019 16:58, Frank Wunderlich wrote:
> From: Ryder Lee
>
> Add display subsystem related device nodes for MT7623.
>
> Cc: CK Hu
> Signed-off-by: chunhui dai
> Signed-off-by: Bibby Hsieh
> Signed-off-by: Ryder Lee
>
> additional fixes:
>
> [hdmi,dts] fixed dts-warnings
> author: Bibby Hsieh
>
> [dtsi] fix dpi0-node
> author: Ryder Lee
>
> Signed-off-by: Frank Wunderlich
> Tested-by: Frank Wunderlich
> =2D--
> arch/arm/boot/dts/mt7623.dtsi | 177 ++
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 85 +
> arch/arm/boot/dts/mt7623n-rfb-emmc.dts| 85 +
> 3 files changed, 347 insertions(+)
>
[...]
>
> + display_components: dispsys@1400 {
> + compatible =3D "mediatek,mt7623-mmsys",
> + "mediatek,mt2701-mmsys";
> + reg =3D <0 0x1400 0 0x1000>;
> + power-domains =3D < MT2701_POWER_DOMAIN_DISP>;
> + };
> +
mmsys problem is fixed now, so feel free to rebase your patches on linux-next or
my for-next branch and resend.
Would love to see graphics being supported on the bananapi-r2.
Regards,
Matthias
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: fbtft: fb_st7789v: make HSD20_IPS numeric and not a string
From: Colin Ian King
Currently HSD20_IPS is defined as "true" and will always result in a
non-zero result even if it is defined as "false" because it is an array
and that will never be zero. Fix this by defining it as an integer 1
rather than a literal string.
Addessses-Coverity: ("Array compared against 0")
Fixes: f03c9b788472 ("staging: fbtft: fb_st7789v: Initialize the Display")
Signed-off-by: Colin Ian King
---
drivers/staging/fbtft/fb_st7789v.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fb_st7789v.c
b/drivers/staging/fbtft/fb_st7789v.c
index ebc17e05ecd0..3a280cc1892c 100644
--- a/drivers/staging/fbtft/fb_st7789v.c
+++ b/drivers/staging/fbtft/fb_st7789v.c
@@ -24,7 +24,7 @@
"D0 05 0A 09 08 05 2E 44 45 0F 17 16 2B 33\n" \
"D0 05 0A 09 08 05 2E 43 45 0F 16 16 2B 33"
-#define HSD20_IPS "true"
+#define HSD20_IPS 1
/**
* enum st7789v_command - ST7789V display controller commands
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/hdcp: Avoid duplicate HDCP enables
On Thu, May 21, 2020 at 5:36 AM Anshuman Gupta wrote:
>
> On 2020-05-21 at 10:27:21 +0530, Ramalingam C wrote:
> > On 2020-05-20 at 15:47:44 -0400, Sean Paul wrote:
> > > From: Sean Paul
> > >
> > > If userspace sets the CP property to DESIRED while it's already ENABLED,
> > > the driver will try to re-enable HDCP. On some displays, this will
> > > result in R0' mismatches. I'm guessing this is because the display is
> > > still sending back Ri instead of re-authenticating.
> > >
> > > At any rate, we can fix this inefficiency easily enough by just nooping
> > > the DESIRED property set if HDCP is already ENABLED.
> AFAIU may below patch also solves above issue implicitly.
> https://patchwork.freedesktop.org/patch/365758/?series=72251=4
> Besides that +1 for below Ram comment, it would be better if such type of
> duplicate
> enable request should filter by drm_atomic_connector_set_property().
Thanks Anshuman, I didn't see that patch. Indeed that seems like it
accomplishes the same thing.
Let's drop this.
Sean
> Thanks,
> Anshuman Gupta.
>
> > Sean,
> >
> > This will skip the hdcp enable.
> >
> > But at present too we will be getting below WARN_ON from intel_hdcp_enable,
> > to indicate userspace is going wrong with request.
> > drm_WARN_ON(_priv->drm,
> > hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
> >
> > And if we need to filter this out, could we validate the incoming hdcp
> > request at
> > drm_atomic_connector_set_property() itself? No point in going into the
> > atomic commit without a valid request. something like
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index a1e5e262bae2..d98b2eeae78d 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -746,6 +746,12 @@ static int drm_atomic_connector_set_property(struct
> > drm_connector *connector,
> > DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
> > return -EINVAL;
> > }
> > + if (config->content_protection_property ==
> > + DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> > + val == DRM_MODE_CONTENT_PROTECTION_DESIRED) {
> > + DRM_DEBUG_KMS("Redundant req for content
> > protection\n");
> > + return -EINVAL;
> > + }
> > state->content_protection = val;
> > } else if (property == config->hdcp_content_type_property) {
> > state->hdcp_content_type = val;
> >
> > -Ram
> >
> > >
> > > Signed-off-by: Sean Paul
> > > ---
> > >
> > > I suspect this is the actual root cause I was chasing with
> > > "drm/i915/hdcp: Add additional R0' wait". I was able to reproduce the
> > > R0` messages by marking HDCP desired while it was already enabled. This
> > > _should_ work, but it seems like some displays handle it more graciously
> > > than others.
> > >
> > >
> > > drivers/gpu/drm/i915/display/intel_hdcp.c | 10 +++---
> > > 1 file changed, 7 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > index 2cbc4619b4ce..f770fe0c5595 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > @@ -2156,12 +2156,16 @@ void intel_hdcp_atomic_check(struct drm_connector
> > > *connector,
> > > }
> > >
> > > /*
> > > -* Nothing to do if the state didn't change, or HDCP was activated
> > > since
> > > -* the last commit. And also no change in hdcp content type.
> > > +* Nothing to do if content type is unchanged and one of:
> > > +* - state didn't change
> > > +* - HDCP was activated since the last commit
> > > +* - attempting to set to desired while already enabled
> > > */
> > > if (old_cp == new_cp ||
> > > (old_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
> > > -new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED)) {
> > > +new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
> > > + (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> > > +new_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
> > > if (old_state->hdcp_content_type ==
> > > new_state->hdcp_content_type)
> > > return;
> > > --
> > > Sean Paul, Software Engineer, Google / Chromium OS
> > >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 13/25] dma-buf: Use sequence counter with associated wound/wait mutex
Am 21.05.20 um 02:09 schrieb Ahmed S. Darwish: On Wed, May 20, 2020, Christian König wrote: Am 19.05.20 um 23:45 schrieb Ahmed S. Darwish: A sequence counter write side critical section must be protected by some form of locking to serialize writers. If the serialization primitive is not disabling preemption implicitly, preemption has to be explicitly disabled before entering the sequence counter write side critical section. The dma-buf reservation subsystem uses plain sequence counters to manage updates to reservations. Writer serialization is accomplished through a wound/wait mutex. Acquiring a wound/wait mutex does not disable preemption, so this needs to be done manually before and after the write side critical section. Use the newly-added seqcount_ww_mutex_t instead: - It associates the ww_mutex with the sequence count, which enables lockdep to validate that the write side critical section is properly serialized. - It removes the need to explicitly add preempt_disable/enable() around the write side critical section because the write_begin/end() functions for this new data type automatically do this. If lockdep is disabled this ww_mutex lock association is compiled out and has neither storage size nor runtime overhead. Mhm, is the dma_resv object the only user of this new seqcount_ww_mutex variant ? If yes we are trying to get rid of this sequence counter for quite some time, so I would rather invest the additional time to finish this. In this patch series, each extra "seqcount with associated lock" data type costs us, exactly: - 1 typedef definition, seqcount_ww_mutex_t - 1 static initializer, SEQCNT_WW_MUTEX_ZERO() - 1 runtime initializer, seqcount_ww_mutex_init() Definitions for the typedef and the 2 initializers above are template-code one liners. In this case I'm perfectly fine with this. The logic which automatically disables preemption upon entering a seqcount_ww_mutex_t write side critical section is also already shared with seqcount_mutex_t and any future, preemptible, associated lock. So, yes, dma-resv is the only user of seqcount_ww_mutex. But even in that case, given the one liner template code nature of seqcount_ww_mutex_t logic, it does not make sense to block the dma_resv and amdgpu change until at some point in the future the sequence counter is completely removed. **If and when** the sequence counter gets removed, please just remove the seqcount_ww_mutex_t data type with it. It will be extremely simple. Completely agree, just wanted to prevent that we now add a lot of code which gets removed again ~3 month from now. Regards, Christian. Regards, Christian. Thanks, -- Ahmed S. Darwish Linutronix GmbH ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/amdkfd: Fix large framesize for kfd_smi_ev_read()
On 05/20, Felix Kuehling wrote: > Am 2020-05-20 um 9:53 a.m. schrieb Aurabindo Pillai: > > The buffer allocated is of 1024 bytes. Allocate this from > > heap instead of stack. > > > > Also remove check for stack size since we're allocating from heap > > > > Signed-off-by: Aurabindo Pillai > > Tested-by: Amber Lin > > See one comment inline. With that fixed, the patch is > > Reviewed-by: Felix Kuehling > > > > --- > > drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 26 +++-- > > 1 file changed, 19 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c > > b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c > > index f5fd18eacf0d..5aebe169f8c6 100644 > > --- a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c > > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c > > @@ -77,9 +77,11 @@ static ssize_t kfd_smi_ev_read(struct file *filep, char > > __user *user, > > int ret; > > size_t to_copy; > > struct kfd_smi_client *client = filep->private_data; > > - unsigned char buf[MAX_KFIFO_SIZE]; > > + unsigned char *buf; > > > > - BUILD_BUG_ON(MAX_KFIFO_SIZE > 1024); > > + buf = kzalloc(MAX_KFIFO_SIZE * sizeof(*buf), GFP_KERNEL); > > kzalloc is not necessary here, you could use kmalloc. The part of that > allocation that matters will be overwritten by kfifo_out. > > Regards, > Felix > > Thank you Felix, Alex for the review. I shall make that change and submit it. Thanks & Regards, Aurabindo signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] arm64: dts: mt8183: Add gce setting in display node
On 21/05/2020 12:47, Bibby Hsieh wrote:
> On Thu, 2020-05-21 at 12:10 +0200, Matthias Brugger wrote:
>> On 14/02/2020 11:06, Matthias Brugger wrote:
>>>
>>>
>>> On 14/02/2020 05:49, Bibby Hsieh wrote:
In order to use GCE function, we need add some information
into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
Signed-off-by: Bibby Hsieh
Signed-off-by: Yongqiang Niu
---
>>>
>>> For the next time please provide some context on which patches this are
>>> based
>>> on. Bet below the '---' with a link.
>>>
>>> For this time, on which patch/series is this based? :)
>>
>> Bibby can you please help and rebase the patch against my for-next branch
>> [1].
>> I'm then happy to queue it. Not sure if we can make it for v5.8 as we are
>> really
>> late, but we could try :)
>
> Hi, Matthias,
>
> NP, but this patch[1] is depends on another patch [2].
> Should I rebase them together into your for-next branch?
>
I see and [2] one depends on the scpsys driver.
Then maybe better wait until we have the scpsys driver accepted.
Regards,
Matthias
> [1] https://patchwork.kernel.org/patch/11385863/
> [2] https://patchwork.kernel.org/patch/11316277/
>
> Bibby
>
>>
>> Thanks!
>> Matthias
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next
>>
>>>
>>> Thanks,
>>> Matthias
>>>
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index be4428c92f35..8b522b039a37 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "mt8183-pinfunc.h"
/ {
@@ -664,6 +665,9 @@
reg = <0 0x1400 0 0x1000>;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
#clock-cells = <1>;
+ mboxes = < 0 CMDQ_THR_PRIO_HIGHEST>,
+ < 1 CMDQ_THR_PRIO_HIGHEST>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0
0x1000>;
};
ovl0: ovl@14008000 {
@@ -672,6 +676,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_OVL0>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0x8000
0x1000>;
};
ovl_2l0: ovl@14009000 {
@@ -680,6 +685,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_OVL0_2L>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0x9000
0x1000>;
};
ovl_2l1: ovl@1400a000 {
@@ -688,6 +694,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_OVL1_2L>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xa000
0x1000>;
};
rdma0: rdma@1400b000 {
@@ -697,6 +704,7 @@
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_RDMA0>;
mediatek,rdma_fifo_size = <5120>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xb000
0x1000>;
};
rdma1: rdma@1400c000 {
@@ -706,6 +714,7 @@
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_RDMA1>;
mediatek,rdma_fifo_size = <2048>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xc000
0x1000>;
};
color0: color@1400e000 {
@@ -715,6 +724,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_COLOR0>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xe000
0x1000>;
};
ccorr0: ccorr@1400f000 {
@@ -723,6 +733,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_CCORR0>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xf000
0x1000>;
};
aal0: aal@1401 {
@@ -732,6 +743,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_AAL0>;
+
Re: [PATCH v2 2/2] drm/udl: Use GEM vmap/mmap function from SHMEM helpers
Den 19.05.2020 10.04, skrev Thomas Zimmermann:
> The udl driver contains an implementation of GEM vmap and mmap
> operations that is identical to the common SHMEM helper; except
> that udl's code uses cached pages by default.
>
> Convert udl to regular SHMEM helper functions. There's no reason
> to have udl behave differently from all other SHMEM drivers. The
> udl driver uses the SHMEM helper to enable caching.
>
> v2:
> * implement .gem_create_object with SHMEM helper
>
> Signed-off-by: Thomas Zimmermann
> ---
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index d1aa50fd6d65a..96d4317a2c1bd 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -37,8 +37,8 @@ DEFINE_DRM_GEM_FOPS(udl_driver_fops);
> static struct drm_driver driver = {
> .driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET,
>
> - /* gem hooks */
> - .gem_create_object = udl_driver_gem_create_object,
> + /* GEM hooks */
> + .gem_create_object = drm_gem_shmem_create_object_cached,
>
> .fops = _driver_fops,
> DRM_GEM_SHMEM_DRIVER_OPS,
You could add a DRM_GEM_SHMEM_CACHED_DRIVER_OPS macro and use that instead.
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: add docs for standard CRTC properties
This patch adds docs for the ACTIVE and MODE_ID CRTC properties. Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Ville Syrjala Cc: Pekka Paalanen Cc: Michel Dänzer Cc: Daniel Stone --- Thanks for the review Daniel! I rejiggered your suggestions a little to move some ACTIVE bits into the ACTIVE description. Documentation/gpu/drm-kms.rst | 6 ++ drivers/gpu/drm/drm_crtc.c| 27 +++ 2 files changed, 33 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 397314d08f77..975cfeb8a353 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -460,6 +460,12 @@ HDMI Specific Connector Properties .. kernel-doc:: drivers/gpu/drm/drm_connector.c :doc: HDMI connector properties +Standard CRTC Properties + + +.. kernel-doc:: drivers/gpu/drm/drm_crtc.c + :doc: standard CRTC properties + Plane Composition Properties diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 4936e1080e41..fafb8d3c3235 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -204,6 +204,33 @@ struct dma_fence *drm_crtc_create_fence(struct drm_crtc *crtc) return fence; } +/** + * DOC: standard CRTC properties + * + * DRM CRTCs have a few standardized properties: + * + * ACTIVE: + * Atomic property for setting the power state of the CRTC. When set to 1 the + * CRTC will actively display content. When set to 0 the CRTC will be powered + * off. There is no expectation that user-space will reset CRTC resources like + * the mode and planes when setting ACTIVE to 0. + * + * User-space can rely on an ACTIVE change to 1 to never fail an atomic test + * as long as no other property has changed. If a change to ACTIVE fails an + * atomic test, this is a driver bug. For this reason setting ACTIVE to 0 must + * not release internal resources (like reserved memory bandwidth or clock + * generators). + * + * Note that the legacy DPMS property on connectors is internally routed to + * control this property for atomic drivers. + * MODE_ID: + * Atomic property for setting the CRTC display timings. The value is the ID + * of a blob containing the DRM mode info. To disable the CRTC, user-space + * must set this property to 0. + * + * Setting MODE_ID to 0 will release reserved resources for the CRTC. + */ + /** * drm_crtc_init_with_planes - Initialise a new CRTC object with *specified primary and cursor planes. -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5, 32/32] drm/mediatek: add support for mediatek SOC MT8183
On 29/08/2019 16:50, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch add support for mediatek SOC MT8183
> 1.ovl_2l share driver with ovl
> 2.rdma1 share drive with rdma0, but fifo size is different
> 3.add mt8183 mutex private data, and mmsys private data
> 4.add mt8183 main and external path module for crtc create
>
> Signed-off-by: Yongqiang Niu
After a long time the mmsys problem is fixed [1], so pelase rebase your series
on linux-next and resend.
Thanks a lot!
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=for-next=1f9adbc72824ff07bbffd776d8b51f91f5a82c18
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 +
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 27 -
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 69
>
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 ++
> 5 files changed, 161 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 53f3883..94c80c2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -373,11 +373,29 @@ static int mtk_disp_ovl_remove(struct platform_device
> *pdev)
> .fmt_rgb565_is_0 = true,
> };
>
> +static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT8173,
> + .gmc_bits = 10,
> + .layer_nr = 4,
> + .fmt_rgb565_is_0 = true,
> +};
> +
> +static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT8173,
> + .gmc_bits = 10,
> + .layer_nr = 2,
> + .fmt_rgb565_is_0 = true,
> +};
> +
> static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> { .compatible = "mediatek,mt2701-disp-ovl",
> .data = _ovl_driver_data},
> { .compatible = "mediatek,mt8173-disp-ovl",
> .data = _ovl_driver_data},
> + { .compatible = "mediatek,mt8183-disp-ovl",
> + .data = _ovl_driver_data},
> + { .compatible = "mediatek,mt8183-disp-ovl-2l",
> + .data = _ovl_2l_driver_data},
> {},
> };
> MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index 9a6f0a2..24945fe 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -62,6 +62,7 @@ struct mtk_disp_rdma {
> struct mtk_ddp_comp ddp_comp;
> struct drm_crtc *crtc;
> const struct mtk_disp_rdma_data *data;
> + u32 fifo_size;
> };
>
> static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
> @@ -130,10 +131,16 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
> unsigned int width,
> unsigned int threshold;
> unsigned int reg;
> struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
> + u32 rdma_fifo_size;
>
> rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xfff, width);
> rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_1, 0xf, height);
>
> + if (rdma->fifo_size)
> + rdma_fifo_size = rdma->fifo_size;
> + else
> + rdma_fifo_size = RDMA_FIFO_SIZE(rdma);
> +
> /*
>* Enable FIFO underflow since DSI and DPI can't be blocked.
>* Keep the FIFO pseudo size reset default of 8 KiB. Set the
> @@ -142,7 +149,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
> unsigned int width,
>*/
> threshold = width * height * vrefresh * 4 * 7 / 100;
> reg = RDMA_FIFO_UNDERFLOW_EN |
> - RDMA_FIFO_PSEUDO_SIZE(RDMA_FIFO_SIZE(rdma)) |
> + RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) |
> RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
> writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
> }
> @@ -284,6 +291,18 @@ static int mtk_disp_rdma_probe(struct platform_device
> *pdev)
> return comp_id;
> }
>
> + if (of_find_property(dev->of_node, "mediatek,rdma_fifo_size", )) {
> + ret = of_property_read_u32(dev->of_node,
> +"mediatek,rdma_fifo_size",
> +>fifo_size);
> + if (ret) {
> + dev_err(dev, "Failed to get rdma fifo size\n");
> + return ret;
> + }
> +
> + priv->fifo_size *= SZ_1K;
> + }
> +
> ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
> _disp_rdma_funcs);
> if (ret) {
> @@ -328,11 +347,17 @@ static int mtk_disp_rdma_remove(struct platform_device
> *pdev)
> .fifo_size = SZ_8K,
> };
>
> +static const struct mtk_disp_rdma_data mt8183_rdma_driver_data = {
> + .fifo_size = 5 * SZ_1K,
> +};
> +
>
Re: [PATCH 1/3] arm64: dts: mt8183: Add gce setting in display node
On Thu, 2020-05-21 at 12:10 +0200, Matthias Brugger wrote:
> On 14/02/2020 11:06, Matthias Brugger wrote:
> >
> >
> > On 14/02/2020 05:49, Bibby Hsieh wrote:
> >> In order to use GCE function, we need add some information
> >> into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
> >>
> >> Signed-off-by: Bibby Hsieh
> >> Signed-off-by: Yongqiang Niu
> >> ---
> >
> > For the next time please provide some context on which patches this are
> > based
> > on. Bet below the '---' with a link.
> >
> > For this time, on which patch/series is this based? :)
>
> Bibby can you please help and rebase the patch against my for-next branch [1].
> I'm then happy to queue it. Not sure if we can make it for v5.8 as we are
> really
> late, but we could try :)
Hi, Matthias,
NP, but this patch[1] is depends on another patch [2].
Should I rebase them together into your for-next branch?
[1] https://patchwork.kernel.org/patch/11385863/
[2] https://patchwork.kernel.org/patch/11316277/
Bibby
>
> Thanks!
> Matthias
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next
>
> >
> > Thanks,
> > Matthias
> >
> >> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16
> >> 1 file changed, 16 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> >> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> >> index be4428c92f35..8b522b039a37 100644
> >> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> >> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> >> @@ -9,6 +9,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include "mt8183-pinfunc.h"
> >>
> >> / {
> >> @@ -664,6 +665,9 @@
> >>reg = <0 0x1400 0 0x1000>;
> >>power-domains = < MT8183_POWER_DOMAIN_DISP>;
> >>#clock-cells = <1>;
> >> + mboxes = < 0 CMDQ_THR_PRIO_HIGHEST>,
> >> + < 1 CMDQ_THR_PRIO_HIGHEST>;
> >> + mediatek,gce-client-reg = < SUBSYS_1400 0
> >> 0x1000>;
> >>};
> >>
> >>ovl0: ovl@14008000 {
> >> @@ -672,6 +676,7 @@
> >>interrupts = ;
> >>power-domains = < MT8183_POWER_DOMAIN_DISP>;
> >>clocks = < CLK_MM_DISP_OVL0>;
> >> + mediatek,gce-client-reg = < SUBSYS_1400 0x8000
> >> 0x1000>;
> >>};
> >>
> >>ovl_2l0: ovl@14009000 {
> >> @@ -680,6 +685,7 @@
> >>interrupts = ;
> >>power-domains = < MT8183_POWER_DOMAIN_DISP>;
> >>clocks = < CLK_MM_DISP_OVL0_2L>;
> >> + mediatek,gce-client-reg = < SUBSYS_1400 0x9000
> >> 0x1000>;
> >>};
> >>
> >>ovl_2l1: ovl@1400a000 {
> >> @@ -688,6 +694,7 @@
> >>interrupts = ;
> >>power-domains = < MT8183_POWER_DOMAIN_DISP>;
> >>clocks = < CLK_MM_DISP_OVL1_2L>;
> >> + mediatek,gce-client-reg = < SUBSYS_1400 0xa000
> >> 0x1000>;
> >>};
> >>
> >>rdma0: rdma@1400b000 {
> >> @@ -697,6 +704,7 @@
> >>power-domains = < MT8183_POWER_DOMAIN_DISP>;
> >>clocks = < CLK_MM_DISP_RDMA0>;
> >>mediatek,rdma_fifo_size = <5120>;
> >> + mediatek,gce-client-reg = < SUBSYS_1400 0xb000
> >> 0x1000>;
> >>};
> >>
> >>rdma1: rdma@1400c000 {
> >> @@ -706,6 +714,7 @@
> >>power-domains = < MT8183_POWER_DOMAIN_DISP>;
> >>clocks = < CLK_MM_DISP_RDMA1>;
> >>mediatek,rdma_fifo_size = <2048>;
> >> + mediatek,gce-client-reg = < SUBSYS_1400 0xc000
> >> 0x1000>;
> >>};
> >>
> >>color0: color@1400e000 {
> >> @@ -715,6 +724,7 @@
> >>interrupts = ;
> >>power-domains = < MT8183_POWER_DOMAIN_DISP>;
> >>clocks = < CLK_MM_DISP_COLOR0>;
> >> + mediatek,gce-client-reg = < SUBSYS_1400 0xe000
> >> 0x1000>;
> >>};
> >>
> >>ccorr0: ccorr@1400f000 {
> >> @@ -723,6 +733,7 @@
> >>interrupts = ;
> >>power-domains = < MT8183_POWER_DOMAIN_DISP>;
> >>clocks = < CLK_MM_DISP_CCORR0>;
> >> + mediatek,gce-client-reg = < SUBSYS_1400 0xf000
> >> 0x1000>;
> >>};
> >>
> >>aal0: aal@1401 {
> >> @@ -732,6 +743,7 @@
> >>interrupts = ;
> >>power-domains = < MT8183_POWER_DOMAIN_DISP>;
> >>clocks = < CLK_MM_DISP_AAL0>;
> >> + mediatek,gce-client-reg = < SUBSYS_1401 0
> >> 0x1000>;
> >>};
> >>
> >>gamma0: gamma@14011000 {
> >> @@ -741,6 +753,7 @@
> >>interrupts = ;
>
Re: [PATCH] drm/i915/gt: Initialize reserved and unspecified MOCS indices
Quoting Ayaz A Siddiqui (2020-05-21 11:41:52)
> In order to avoid functional breakage of mis-programmed applications that
> have grown to depend on unused MOCS entries. It has been decided to
> program those entries to be equal to fully cached ("L3 + LLC") entry.
"It has been" appears to be you have decided, since there isn't even a
reference to the previous threads on this topic, or any other
discussion.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/gt: Initialize reserved and unspecified MOCS indices
In order to avoid functional breakage of mis-programmed applications that
have grown to depend on unused MOCS entries. It has been decided to
program those entries to be equal to fully cached ("L3 + LLC") entry.
These reserved and unspecified entries should not be used as they may be
changed to less performant variants with better coherency in the future
if more entries are needed.
Signed-off-by: Ayaz A Siddiqui
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 93 ++--
1 file changed, 89 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 632e08a4592b..1089bd5fdba2 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -234,10 +234,6 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
L3_1_UC)
static const struct drm_i915_mocs_entry tgl_mocs_table[] = {
- /* Base - Error (Reserved for Non-Use) */
- MOCS_ENTRY(0, 0x0, 0x0),
- /* Base - Reserved */
- MOCS_ENTRY(1, 0x0, 0x0),
GEN11_MOCS_ENTRIES,
@@ -265,6 +261,95 @@ static const struct drm_i915_mocs_entry tgl_mocs_table[] =
{
MOCS_ENTRY(61,
LE_1_UC | LE_TC_1_LLC,
L3_3_WB),
+
+ /* NOTE:
+* Reserved and unspecified MOCS indices have been set to (L3 + LCC).
+* These reserved entry should never be used, they may be chanaged
+* to low performant variants with better coherency in the future if
+* more entries are needed.
+*/
+
+ /* Reserved index 0 and 1 */
+ MOCS_ENTRY(0, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(1, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+
+ /* Reserved index 16 and 17 */
+ MOCS_ENTRY(16, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(17, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+
+ /* Reserved index 24 and 25 */
+ MOCS_ENTRY(24, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(25, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+
+ /* Unspecified indices 26 to 47 */
+ MOCS_ENTRY(26, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(27, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(28, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(29, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(30, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(31, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(32, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(33, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(34, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(35, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(36, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(37, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(38, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(39, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(40, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(41, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(42, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(43, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(44, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(45, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(46, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(47, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+
+ /* Unspecified indices 52 to 59 */
+ MOCS_ENTRY(52, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(53, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(54, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(55, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(56, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(57, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(58, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB),
+ MOCS_ENTRY(59, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
+ L3_3_WB)
};
static const struct
Re: [PATCH 1/3] arm64: dts: mt8183: Add gce setting in display node
On 14/02/2020 11:06, Matthias Brugger wrote:
>
>
> On 14/02/2020 05:49, Bibby Hsieh wrote:
>> In order to use GCE function, we need add some information
>> into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
>>
>> Signed-off-by: Bibby Hsieh
>> Signed-off-by: Yongqiang Niu
>> ---
>
> For the next time please provide some context on which patches this are based
> on. Bet below the '---' with a link.
>
> For this time, on which patch/series is this based? :)
Bibby can you please help and rebase the patch against my for-next branch [1].
I'm then happy to queue it. Not sure if we can make it for v5.8 as we are really
late, but we could try :)
Thanks!
Matthias
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next
>
> Thanks,
> Matthias
>
>> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> index be4428c92f35..8b522b039a37 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> @@ -9,6 +9,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include "mt8183-pinfunc.h"
>>
>> / {
>> @@ -664,6 +665,9 @@
>> reg = <0 0x1400 0 0x1000>;
>> power-domains = < MT8183_POWER_DOMAIN_DISP>;
>> #clock-cells = <1>;
>> +mboxes = < 0 CMDQ_THR_PRIO_HIGHEST>,
>> + < 1 CMDQ_THR_PRIO_HIGHEST>;
>> +mediatek,gce-client-reg = < SUBSYS_1400 0
>> 0x1000>;
>> };
>>
>> ovl0: ovl@14008000 {
>> @@ -672,6 +676,7 @@
>> interrupts = ;
>> power-domains = < MT8183_POWER_DOMAIN_DISP>;
>> clocks = < CLK_MM_DISP_OVL0>;
>> +mediatek,gce-client-reg = < SUBSYS_1400 0x8000
>> 0x1000>;
>> };
>>
>> ovl_2l0: ovl@14009000 {
>> @@ -680,6 +685,7 @@
>> interrupts = ;
>> power-domains = < MT8183_POWER_DOMAIN_DISP>;
>> clocks = < CLK_MM_DISP_OVL0_2L>;
>> +mediatek,gce-client-reg = < SUBSYS_1400 0x9000
>> 0x1000>;
>> };
>>
>> ovl_2l1: ovl@1400a000 {
>> @@ -688,6 +694,7 @@
>> interrupts = ;
>> power-domains = < MT8183_POWER_DOMAIN_DISP>;
>> clocks = < CLK_MM_DISP_OVL1_2L>;
>> +mediatek,gce-client-reg = < SUBSYS_1400 0xa000
>> 0x1000>;
>> };
>>
>> rdma0: rdma@1400b000 {
>> @@ -697,6 +704,7 @@
>> power-domains = < MT8183_POWER_DOMAIN_DISP>;
>> clocks = < CLK_MM_DISP_RDMA0>;
>> mediatek,rdma_fifo_size = <5120>;
>> +mediatek,gce-client-reg = < SUBSYS_1400 0xb000
>> 0x1000>;
>> };
>>
>> rdma1: rdma@1400c000 {
>> @@ -706,6 +714,7 @@
>> power-domains = < MT8183_POWER_DOMAIN_DISP>;
>> clocks = < CLK_MM_DISP_RDMA1>;
>> mediatek,rdma_fifo_size = <2048>;
>> +mediatek,gce-client-reg = < SUBSYS_1400 0xc000
>> 0x1000>;
>> };
>>
>> color0: color@1400e000 {
>> @@ -715,6 +724,7 @@
>> interrupts = ;
>> power-domains = < MT8183_POWER_DOMAIN_DISP>;
>> clocks = < CLK_MM_DISP_COLOR0>;
>> +mediatek,gce-client-reg = < SUBSYS_1400 0xe000
>> 0x1000>;
>> };
>>
>> ccorr0: ccorr@1400f000 {
>> @@ -723,6 +733,7 @@
>> interrupts = ;
>> power-domains = < MT8183_POWER_DOMAIN_DISP>;
>> clocks = < CLK_MM_DISP_CCORR0>;
>> +mediatek,gce-client-reg = < SUBSYS_1400 0xf000
>> 0x1000>;
>> };
>>
>> aal0: aal@1401 {
>> @@ -732,6 +743,7 @@
>> interrupts = ;
>> power-domains = < MT8183_POWER_DOMAIN_DISP>;
>> clocks = < CLK_MM_DISP_AAL0>;
>> +mediatek,gce-client-reg = < SUBSYS_1401 0
>> 0x1000>;
>> };
>>
>> gamma0: gamma@14011000 {
>> @@ -741,6 +753,7 @@
>> interrupts = ;
>> power-domains = < MT8183_POWER_DOMAIN_DISP>;
>> clocks = < CLK_MM_DISP_GAMMA0>;
>> +mediatek,gce-client-reg = < SUBSYS_1401 0x1000
>> 0x1000>;
>> };
>>
>> dither0: dither@14012000 {
>> @@ -749,6 +762,7 @@
>> interrupts = ;
>> power-domains = < MT8183_POWER_DOMAIN_DISP>;
>> clocks = <
Re: [PATCH] drm/i915/hdcp: Avoid duplicate HDCP enables
On 2020-05-21 at 10:27:21 +0530, Ramalingam C wrote:
> On 2020-05-20 at 15:47:44 -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > If userspace sets the CP property to DESIRED while it's already ENABLED,
> > the driver will try to re-enable HDCP. On some displays, this will
> > result in R0' mismatches. I'm guessing this is because the display is
> > still sending back Ri instead of re-authenticating.
> >
> > At any rate, we can fix this inefficiency easily enough by just nooping
> > the DESIRED property set if HDCP is already ENABLED.
AFAIU may below patch also solves above issue implicitly.
https://patchwork.freedesktop.org/patch/365758/?series=72251=4
Besides that +1 for below Ram comment, it would be better if such type of
duplicate
enable request should filter by drm_atomic_connector_set_property().
Thanks,
Anshuman Gupta.
> Sean,
>
> This will skip the hdcp enable.
>
> But at present too we will be getting below WARN_ON from intel_hdcp_enable,
> to indicate userspace is going wrong with request.
> drm_WARN_ON(_priv->drm,
> hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
>
> And if we need to filter this out, could we validate the incoming hdcp
> request at
> drm_atomic_connector_set_property() itself? No point in going into the
> atomic commit without a valid request. something like
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index a1e5e262bae2..d98b2eeae78d 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -746,6 +746,12 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
> return -EINVAL;
> }
> + if (config->content_protection_property ==
> + DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> + val == DRM_MODE_CONTENT_PROTECTION_DESIRED) {
> + DRM_DEBUG_KMS("Redundant req for content
> protection\n");
> + return -EINVAL;
> + }
> state->content_protection = val;
> } else if (property == config->hdcp_content_type_property) {
> state->hdcp_content_type = val;
>
> -Ram
>
> >
> > Signed-off-by: Sean Paul
> > ---
> >
> > I suspect this is the actual root cause I was chasing with
> > "drm/i915/hdcp: Add additional R0' wait". I was able to reproduce the
> > R0` messages by marking HDCP desired while it was already enabled. This
> > _should_ work, but it seems like some displays handle it more graciously
> > than others.
> >
> >
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index 2cbc4619b4ce..f770fe0c5595 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -2156,12 +2156,16 @@ void intel_hdcp_atomic_check(struct drm_connector
> > *connector,
> > }
> >
> > /*
> > -* Nothing to do if the state didn't change, or HDCP was activated since
> > -* the last commit. And also no change in hdcp content type.
> > +* Nothing to do if content type is unchanged and one of:
> > +* - state didn't change
> > +* - HDCP was activated since the last commit
> > +* - attempting to set to desired while already enabled
> > */
> > if (old_cp == new_cp ||
> > (old_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
> > -new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED)) {
> > +new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
> > + (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> > +new_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
> > if (old_state->hdcp_content_type ==
> > new_state->hdcp_content_type)
> > return;
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH linux-next] drm/msm/a6xx: a6xx_hfi_send_start() can be static
Fixes: 8167e6fa76c8 ("drm/msm/a6xx: HFI v2 for A640 and A650")
Signed-off-by: kbuild test robot
---
a6xx_hfi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_hfi.c
b/drivers/gpu/drm/msm/adreno/a6xx_hfi.c
index f9db69e771214..9921e632f1ca2 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_hfi.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_hfi.c
@@ -342,7 +342,7 @@ static int a6xx_hfi_send_test(struct a6xx_gmu *gmu)
NULL, 0);
}
-int a6xx_hfi_send_start(struct a6xx_gmu *gmu)
+static int a6xx_hfi_send_start(struct a6xx_gmu *gmu)
{
struct a6xx_hfi_msg_start msg = { 0 };
@@ -350,7 +350,7 @@ int a6xx_hfi_send_start(struct a6xx_gmu *gmu)
NULL, 0);
}
-int a6xx_hfi_send_core_fw_start(struct a6xx_gmu *gmu)
+static int a6xx_hfi_send_core_fw_start(struct a6xx_gmu *gmu)
{
struct a6xx_hfi_msg_core_fw_start msg = { 0 };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH linux-next] drm/msm/dpu: dpu_setup_dspp_pcc() can be static
Fixes: 4259ff7ae509 ("drm/msm/dpu: add support for pcc color block in dpu
driver")
Signed-off-by: kbuild test robot
---
dpu_hw_dspp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
index b5189cece3c66..a7a24539921f3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
@@ -22,7 +22,7 @@
#define PCC_BLUE_G_OFF 0x24
#define PCC_BLUE_B_OFF 0x30
-void dpu_setup_dspp_pcc(struct dpu_hw_dspp *ctx,
+static void dpu_setup_dspp_pcc(struct dpu_hw_dspp *ctx,
struct dpu_hw_pcc_cfg *cfg)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
