RE: [PATCH 2/4] drm/ttm: add page order support in ttm_pages_put

[He, Roger]

From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Chunming Zhou
Sent: Wednesday, November 22, 2017 2:02 PM
To: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/4] drm/ttm: add page order support in ttm_pages_put




On 2017年11月22日 13:36, Roger He wrote:

Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0

Signed-off-by: Roger He 

---

 drivers/gpu/drm/ttm/ttm_page_alloc.c | 42 +---

 1 file changed, 34 insertions(+), 8 deletions(-)



diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c

index 0a0c653..de64209 100644

--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c

+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c

@@ -285,13 +285,39 @@ static struct ttm_page_pool *ttm_get_pool(int flags, bool 
huge,

 }



 /* set memory back to wb and free the pages. */

-static void ttm_pages_put(struct page *pages[], unsigned npages)

+static void ttm_pages_put(struct page *pages[], unsigned npages,

+unsigned int order)

 {

- unsigned i;

- if (set_pages_array_wb(pages, npages))

-pr_err("Failed to set %d pages to wb!\n", npages);

- for (i = 0; i < npages; ++i)

-__free_page(pages[i]);

+ struct page **pages_to_free = NULL;

+ struct page **pages_array;

+ struct page *p;

+ unsigned int i, j, pages_nr = (1 << order);

+

+ if (order > 0) {

+pages_to_free = kmalloc_array(pages_nr, sizeof(struct page *),

+   GFP_KERNEL);

+if (!pages_to_free) {

+pr_err("Failed to allocate memory for ttm pages put 
operation\n");

+return;

+}

+ }

+

+ for (i = 0; i < npages; ++i) {

+if (order > 0) {

+p = pages[i];

+for (j = 0; j < pages_nr; ++j)

+pages_to_free[j] = p++;

+

+pages_array = pages_to_free;

+} else

+pages_array = pages;

+

+if (set_pages_array_wb(pages_array, pages_nr))
you can use set_pages_wb(pages[i], 1 << order) to instead of creating page 
array marked red, this way, you will not need to kmalloc and patch#3.

and more, if you select set_pages_wb, you also need to clone it in TTM like 
set_pages_array_wb for non-x86 case.

good idea, going to refine code.

Thanks
Roger(Hongbo.He)


Regards,
David Zhou




+pr_err("Failed to set %d pages to wb!\n", pages_nr);

+__free_pages(pages[i], order);

+ }

+

+ kfree(pages_to_free);

 }



 static void ttm_pool_update_free_locked(struct ttm_page_pool *pool,

@@ -354,7 +380,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,

  */

 spin_unlock_irqrestore(>lock, irq_flags);



-ttm_pages_put(pages_to_free, freed_pages);

+ttm_pages_put(pages_to_free, freed_pages, pool->order);

 if (likely(nr_free != FREE_ALL_PAGES))

 nr_free -= freed_pages;



@@ -389,7 +415,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,

  spin_unlock_irqrestore(>lock, irq_flags);



  if (freed_pages)

-ttm_pages_put(pages_to_free, freed_pages);

+ttm_pages_put(pages_to_free, freed_pages, pool->order);

 out:

  if (pages_to_free != static_buf)

 kfree(pages_to_free);

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

Re: [PATCH 2/4] drm/ttm: add page order support in ttm_pages_put

[Chunming Zhou]

On 2017年11月22日 13:36, Roger He wrote:

Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 42 +---
  1 file changed, 34 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 0a0c653..de64209 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -285,13 +285,39 @@ static struct ttm_page_pool *ttm_get_pool(int flags, bool 
huge,
  }
  
  /* set memory back to wb and free the pages. */

-static void ttm_pages_put(struct page *pages[], unsigned npages)
+static void ttm_pages_put(struct page *pages[], unsigned npages,
+   unsigned int order)
  {
-   unsigned i;
-   if (set_pages_array_wb(pages, npages))
-   pr_err("Failed to set %d pages to wb!\n", npages);
-   for (i = 0; i < npages; ++i)
-   __free_page(pages[i]);
+   struct page **pages_to_free = NULL;
+   struct page **pages_array;
+   struct page *p;
+   unsigned int i, j, pages_nr = (1 << order);
+
+   if (order > 0) {
+   pages_to_free = kmalloc_array(pages_nr, sizeof(struct page *),
+   GFP_KERNEL);
+   if (!pages_to_free) {
+   pr_err("Failed to allocate memory for ttm pages put 
operation\n");
+   return;
+   }
+   }
+
+   for (i = 0; i < npages; ++i) {
+ if (order > 0) { + p = pages[i]; + for (j = 0; j < pages_nr; ++j) + 
pages_to_free[j] = p++; + + pages_array = pages_to_free; + } else + 
pages_array = pages; + + if (set_pages_array_wb(pages_array, pages_nr))
you can use set_pages_wb(pages[i], 1 << order) to instead of creating 
page array marked red, this way, you will not need to kmalloc and patch#3.


and more, if you select set_pages_wb, you also need to clone it in TTM 
like set_pages_array_wb for non-x86 case.


Regards,
David Zhou

+   pr_err("Failed to set %d pages to wb!\n", pages_nr);
+   __free_pages(pages[i], order);
+   }
+
+   kfree(pages_to_free);
  }
  
  static void ttm_pool_update_free_locked(struct ttm_page_pool *pool,

@@ -354,7 +380,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
 */
spin_unlock_irqrestore(>lock, irq_flags);
  
-			ttm_pages_put(pages_to_free, freed_pages);

+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
if (likely(nr_free != FREE_ALL_PAGES))
nr_free -= freed_pages;
  
@@ -389,7 +415,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free,

spin_unlock_irqrestore(>lock, irq_flags);
  
  	if (freed_pages)

-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
  out:
if (pages_to_free != static_buf)
kfree(pages_to_free);


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

[PATCH 4/4] drm/ttm: free one in huge pool even shrink request less than one element

[Roger He]

Change-Id: Id8bd4d1ecff9f3ab14355e2dbd1c59b9fe824e01
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 37c2f2f..f80fc5b 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -463,11 +463,13 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
/* OK to use static buffer since global mutex is held. */
nr_free_pool = (nr_free >> pool->order);
-   if (nr_free_pool == 0)
-   continue;
+   if (!nr_free_pool && pool->order)
+   nr_free_pool = 1;
 
shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
freed += ((nr_free_pool - shrink_pages) << pool->order);
+   if (freed >= sc->nr_to_scan)
+   break;
}
mutex_unlock();
return freed;
-- 
2.7.4

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

[PATCH 1/4] drm/ttm: add page order in page pool

[Roger He]

to indicate page order for each element in the pool

Change-Id: Ic609925ca5d2a5d4ad49d6becf505388ce3624cf
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 42 ++--
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 72ea037..0a0c653 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -81,6 +81,7 @@ struct ttm_page_pool {
char*name;
unsigned long   nfrees;
unsigned long   nrefills;
+   unsigned intorder;
 };
 
 /**
@@ -412,6 +413,7 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
struct ttm_page_pool *pool;
int shrink_pages = sc->nr_to_scan;
unsigned long freed = 0;
+   unsigned int nr_free_pool;
 
if (!mutex_trylock())
return SHRINK_STOP;
@@ -421,10 +423,15 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
unsigned nr_free = shrink_pages;
if (shrink_pages == 0)
break;
+
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
/* OK to use static buffer since global mutex is held. */
-   shrink_pages = ttm_page_pool_free(pool, nr_free, true);
-   freed += nr_free - shrink_pages;
+   nr_free_pool = (nr_free >> pool->order);
+   if (nr_free_pool == 0)
+   continue;
+
+   shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
+   freed += ((nr_free_pool - shrink_pages) << pool->order);
}
mutex_unlock();
return freed;
@@ -436,9 +443,12 @@ ttm_pool_shrink_count(struct shrinker *shrink, struct 
shrink_control *sc)
 {
unsigned i;
unsigned long count = 0;
+   struct ttm_page_pool *pool;
 
-   for (i = 0; i < NUM_POOLS; ++i)
-   count += _manager->pools[i].npages;
+   for (i = 0; i < NUM_POOLS; ++i) {
+   pool = &_manager->pools[i];
+   count += (pool->npages << pool->order);
+   }
 
return count;
 }
@@ -932,7 +942,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
 }
 
 static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, gfp_t flags,
-   char *name)
+   char *name, unsigned int order)
 {
spin_lock_init(>lock);
pool->fill_lock = false;
@@ -940,8 +950,18 @@ static void ttm_page_pool_init_locked(struct ttm_page_pool 
*pool, gfp_t flags,
pool->npages = pool->nfrees = 0;
pool->gfp_flags = flags;
pool->name = name;
+   pool->order = order;
 }
 
+/**
+ * Actually if TRANSPARENT_HUGEPAGE not enabled, we will not use
+ * wc_pool_huge and uc_pool_huge, so no matter whatever the page
+ * order are for those two pools
+ */
+#ifndef CONFIG_TRANSPARENT_HUGEPAGE
+#defineHPAGE_PMD_ORDER 9
+#endif
+
 int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
 {
int ret;
@@ -952,23 +972,23 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
 
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
 
-   ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");
+   ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
 
-   ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc");
+   ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc", 0);
 
ttm_page_pool_init_locked(&_manager->wc_pool_dma32,
- GFP_USER | GFP_DMA32, "wc dma");
+ GFP_USER | GFP_DMA32, "wc dma", 0);
 
ttm_page_pool_init_locked(&_manager->uc_pool_dma32,
- GFP_USER | GFP_DMA32, "uc dma");
+ GFP_USER | GFP_DMA32, "uc dma", 0);
 
ttm_page_pool_init_locked(&_manager->wc_pool_huge,
  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP),
- "wc huge");
+ "wc huge", HPAGE_PMD_ORDER);
 
ttm_page_pool_init_locked(&_manager->uc_pool_huge,
  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP)
- , "uc huge");
+ , "uc huge", HPAGE_PMD_ORDER);
 
_manager->options.max_size = max_pages;
_manager->options.small = SMALL_ALLOCATION;
-- 
2.7.4

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

[PATCH 3/4] drm/ttm: add static buffer for ttm_pages_put to support pool shrink

[Roger He]

Change-Id: Ic20c016eb3043d7cfedc2e3648790a017168da6c
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 28 +++-
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index de64209..37c2f2f 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -285,20 +285,27 @@ static struct ttm_page_pool *ttm_get_pool(int flags, bool 
huge,
 }
 
 /* set memory back to wb and free the pages. */
+#define STATIC_BUF_PUT_SIZE 512
 static void ttm_pages_put(struct page *pages[], unsigned npages,
-   unsigned int order)
+   unsigned int order, bool use_static)
 {
+   static struct page *static_buf_put[STATIC_BUF_PUT_SIZE];
struct page **pages_to_free = NULL;
struct page **pages_array;
struct page *p;
unsigned int i, j, pages_nr = (1 << order);
 
+   BUG_ON(use_static && pages_nr > STATIC_BUF_PUT_SIZE);
if (order > 0) {
-   pages_to_free = kmalloc_array(pages_nr, sizeof(struct page *),
-   GFP_KERNEL);
-   if (!pages_to_free) {
-   pr_err("Failed to allocate memory for ttm pages put 
operation\n");
-   return;
+   if (use_static)
+   pages_to_free = static_buf_put;
+   else {
+   pages_to_free = kmalloc_array(pages_nr,
+   sizeof(struct page *), GFP_KERNEL);
+   if (!pages_to_free) {
+   pr_err("Failed to allocate memory for ttm pages 
put operation\n");
+   return;
+   }
}
}
 
@@ -317,7 +324,8 @@ static void ttm_pages_put(struct page *pages[], unsigned 
npages,
__free_pages(pages[i], order);
}
 
-   kfree(pages_to_free);
+   if (!use_static)
+   kfree(pages_to_free);
 }
 
 static void ttm_pool_update_free_locked(struct ttm_page_pool *pool,
@@ -380,7 +388,8 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
 */
spin_unlock_irqrestore(>lock, irq_flags);
 
-   ttm_pages_put(pages_to_free, freed_pages, pool->order);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order,
+   use_static);
if (likely(nr_free != FREE_ALL_PAGES))
nr_free -= freed_pages;
 
@@ -415,7 +424,8 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
spin_unlock_irqrestore(>lock, irq_flags);
 
if (freed_pages)
-   ttm_pages_put(pages_to_free, freed_pages, pool->order);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order,
+   use_static);
 out:
if (pages_to_free != static_buf)
kfree(pages_to_free);
-- 
2.7.4

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

[PATCH 2/4] drm/ttm: add page order support in ttm_pages_put

[Roger He]

Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 42 +---
 1 file changed, 34 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 0a0c653..de64209 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -285,13 +285,39 @@ static struct ttm_page_pool *ttm_get_pool(int flags, bool 
huge,
 }
 
 /* set memory back to wb and free the pages. */
-static void ttm_pages_put(struct page *pages[], unsigned npages)
+static void ttm_pages_put(struct page *pages[], unsigned npages,
+   unsigned int order)
 {
-   unsigned i;
-   if (set_pages_array_wb(pages, npages))
-   pr_err("Failed to set %d pages to wb!\n", npages);
-   for (i = 0; i < npages; ++i)
-   __free_page(pages[i]);
+   struct page **pages_to_free = NULL;
+   struct page **pages_array;
+   struct page *p;
+   unsigned int i, j, pages_nr = (1 << order);
+
+   if (order > 0) {
+   pages_to_free = kmalloc_array(pages_nr, sizeof(struct page *),
+   GFP_KERNEL);
+   if (!pages_to_free) {
+   pr_err("Failed to allocate memory for ttm pages put 
operation\n");
+   return;
+   }
+   }
+
+   for (i = 0; i < npages; ++i) {
+   if (order > 0) {
+   p = pages[i];
+   for (j = 0; j < pages_nr; ++j)
+   pages_to_free[j] = p++;
+
+   pages_array = pages_to_free;
+   } else
+   pages_array = pages;
+
+   if (set_pages_array_wb(pages_array, pages_nr))
+   pr_err("Failed to set %d pages to wb!\n", pages_nr);
+   __free_pages(pages[i], order);
+   }
+
+   kfree(pages_to_free);
 }
 
 static void ttm_pool_update_free_locked(struct ttm_page_pool *pool,
@@ -354,7 +380,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
 */
spin_unlock_irqrestore(>lock, irq_flags);
 
-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
if (likely(nr_free != FREE_ALL_PAGES))
nr_free -= freed_pages;
 
@@ -389,7 +415,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
spin_unlock_irqrestore(>lock, irq_flags);
 
if (freed_pages)
-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
 out:
if (pages_to_free != static_buf)
kfree(pages_to_free);
-- 
2.7.4

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

[Bug 103175] R9285 Unreal tournament perf regression with agd5f 4.15-wip kernels possibly CPU related

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103175

--- Comment #9 from Andy Furniss  ---
possibly this is

https://bugs.freedesktop.org/show_bug.cgi?id=103100

Though I am not sure as I lock soon after startx if on the commit called there

On the commit before I am OK and UT perf is good.

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

[Bug 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102800

--- Comment #14 from Alex Deucher  ---
(In reply to higuita from comment #13)
> Can you give me any pointer how to "call the ACPI _PR3 method"?
> 
> i already install acpi_call, but have no idea how to use it

The pci core should be doing it for you since runtime pm support was added to
pcie ports:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d26d3a8f1b0c442339a235f9508bdad8af91043
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=006d44e49a259b39947366728d65a873a19aadc0

Does adding:
pcie_port_pm=force
to the kernel command line in grub help?

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

[Bug 103838] Random segfaults in applications from radeonsi_dri.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103838

--- Comment #2 from Alex Ford  ---
Created attachment 135654
  --> https://bugs.freedesktop.org/attachment.cgi?id=135654=edit
The application log from the game hackmud (the Unity application)

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

[Bug 103838] Random segfaults in applications from radeonsi_dri.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103838

--- Comment #1 from Alex Ford  ---
Created attachment 135653
  --> https://bugs.freedesktop.org/attachment.cgi?id=135653=edit
The crash log from the Java application ( a minecraft modpack)

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

[Bug 103838] Random segfaults in applications from radeonsi_dri.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103838

Bug ID: 103838
   Summary: Random segfaults in applications from radeonsi_dri.so
   Product: Mesa
   Version: 17.3
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: a...@kobran.org
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 135652
  --> https://bugs.freedesktop.org/attachment.cgi?id=135652=edit
A snippet from /var/log/messages

Starting sometime after 17.2.5, all 17.3.0_rc versions I've tried have caused
some applications to crash randomly. On occasion an application will take
longer to crash, but it almost always does.

My graphics card reports as Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO
[Radeon RX 550] (rev c7)

My distro is Gentoo ~AMD64, and my mesa flags are "classic d3d9 dri3 egl
gallium gbm gles2 llvm nptl opencl osmesa wayland"

I almost never see anything in dmesg or /var/log/messages, with the exception
of a few messages that are attached.

I should add that it seems to only be the application that crashes, I have not
noticed any ill effects on any other part of my system. In addition, it does
not seem to be application or even language dependant, having noticed it in a
Unity game (which is C#) and a Java game.

To reproduce it, I simply start the application and begin using it, after some
time it will simply crash.

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

[Bug 95306] Random Blank(black) screens on "Carrizo"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=95306

--- Comment #69 from Tom  ---
(In reply to Charly from comment #68)
> Hi,
> 
> I made a fresh install of Archlinux (GNU/Linux kernel 4.13.11) on a HP
> Probook 455 G3 with A10-8700p APU and 1x8GB RAM (no dedicated GPU) with the
> default driver (amdgpu open source driver): I experience the issue described
> by Andrew who opened the thread in May 2016. The black screen appears at a
> certain step of the boot. After a cycle of suspend?resune (usually 3 or 4)
> the display turns right and is stable (if no X session is started...) I can
> confirm the issue is not linked to X since it is not installed. The only
> messages for amdgpu in journalctl are 
> 
> amdgpu: [powerplay] min_core_set_clock not set
> 
> but amdgpu.powerplay=0 is not recognized any longer:
> 
> kernel: amdgpu: unknown parameter 'powerplay' ignored.
> 
> Any (new) idea ?
> 
> Can anybody explain what will kermels 4.14 and especially 4.15 will bring us
> (carrizo users)?

There seems to be no solution. I tried several params, combinations of various
things (some even led to quite serious file system corruption) but it had no
positive effect whatsoever. Playing with powerplay/dpm etc. just made my laptop
overheat a lot.

I had some luck with amdgpu-pro in 2016, but it was even less usable. It always
booted successfully but there was mostly pinkish garbage on the screen (±75%)
although I could see the desktop at some places (±25%) and therefore somewhat
use it (login and reboot). Not sure if it is better nowadays, I think it's
worth a try.

Since this issue is here at least since 4.4 I highly doubt 4.14 or 4.15 will
bring the solution.

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

[Bug 95306] Random Blank(black) screens on "Carrizo"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=95306

--- Comment #68 from Charly  ---
Hi,

I made a fresh install of Archlinux (GNU/Linux kernel 4.13.11) on a HP Probook
455 G3 with A10-8700p APU and 1x8GB RAM (no dedicated GPU) with the default
driver (amdgpu open source driver): I experience the issue described by Andrew
who opened the thread in May 2016. The black screen appears at a certain step
of the boot. After a cycle of suspend?resune (usually 3 or 4) the display turns
right and is stable (if no X session is started...) I can confirm the issue is
not linked to X since it is not installed. The only messages for amdgpu in
journalctl are 

amdgpu: [powerplay] min_core_set_clock not set

but amdgpu.powerplay=0 is not recognized any longer:

kernel: amdgpu: unknown parameter 'powerplay' ignored.

Any (new) idea ?

Can anybody explain what will kermels 4.14 and especially 4.15 will bring us 
(carrizo users)?

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

[Bug 103403] [r700] Odd horizontal flickering line every now and then (fractional framebuffer?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103403

mirh  changed:

   What|Removed |Added

Summary|something going on across   |[r700] Odd horizontal
   |the gpu DAC and monitor.|flickering line every now
   ||and then (fractional
   ||framebuffer?)
URL|https://forum.manjaro.org/t |https://forum.manjaro.org/t
   |/ati-graphics-card-drivers- |/ati-graphics-card-drivers-
   |how-to/32784/67 |how-to/32784/57
   Hardware|x86 (IA32)  |x86-64 (AMD64)
Version|XOrg git|unspecified

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

[Bug 103100] Performance regression with various games in drm-next-amd-staging Kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103100

Gregor Münch  changed:

   What|Removed |Added

Summary|Image corruptions,  |Performance regression with
   |instability and performance |various games in
   |regression in drm-next-wip  |drm-next-amd-staging Kernel
   |Kernel  |

--- Comment #3 from Gregor Münch  ---
I did a rather lengthy test with some games:
https://openbenchmarking.org/result/1711211-AL-GAMETEST345

To conclude, it is slower for everything game I tested.
Dota2 Vulkan and Unigine Superposition are one of the larger drops.

This correlates to findings from phoronix btw:
https://www.phoronix.com/scan.php?page=news_item=AMDGPU-DRM-4.15-Early

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

[Bug 103403] something going on across the gpu DAC and monitor.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103403

mirh  changed:

   What|Removed |Added

 Attachment #134999|0   |1
is obsolete||
 CC||m...@protonmail.ch

--- Comment #5 from mirh  ---
Created attachment 135649
  --> https://bugs.freedesktop.org/attachment.cgi?id=135649=edit
*actual* pic of the glitch

I apologize for the newbness of the reporter. 

Hope this way you can better understand the issue. 
I suspect what I put in the title since (after reading similar symptoms in bug
99323 and bug 37696) we could exclude the latter with dpm=0, and the issue
still appearing.

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

[Bug 197925] [amdgpu_dc][carrizo] multiple monitor handling errors

[bugzilla-daemon]

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

--- Comment #1 from kwka...@gmx.com ---
From the initial description, 3) does not occur when external monitor is not
attached.

Also, the backlight can be adjusted manually.

-- 
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

[PATCH 7/8] drm/msm/adreno: a5xx: Explicitly program the CP0 performance counter

[Jordan Crouse]

Even though the default countable for CP0 is CP_ALWAYS_COUNT (0),
program the selector during HW initialization in an effort to be
up front about which counters are programmed and why.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index fdbe9e9..56c2c44 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -597,6 +597,9 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
/* Turn on performance counters */
gpu_write(gpu, REG_A5XX_RBBM_PERFCTR_CNTL, 0x01);
 
+   /* Select CP0 to always count cycles */
+   gpu_write(gpu, REG_A5XX_CP_PERFCTR_CP_SEL_0, PERF_CP_ALWAYS_COUNT);
+
/* Increase VFD cache access so LRZ and other data gets evicted less */
gpu_write(gpu, REG_A5XX_UCHE_CACHE_WAYS, 0x02);
 
-- 
1.9.1

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

[PATCH 1/8] drm/msm/adreno: Call dev_pm_opp_put()

[Jordan Crouse]

We need to call dev_pm_opp_put() to put back the reference
for the OPP struct after calling the various dev_pm_opp_get_*
functions.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a5xx_power.c| 8 +++-
 drivers/gpu/drm/msm/adreno/adreno_device.c | 4 +++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_power.c 
b/drivers/gpu/drm/msm/adreno/a5xx_power.c
index e5700bb..4e4d965 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_power.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_power.c
@@ -103,10 +103,16 @@ static inline uint32_t _get_mvolts(struct msm_gpu *gpu, 
uint32_t freq)
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
struct dev_pm_opp *opp;
+   u32 ret = 0;
 
opp = dev_pm_opp_find_freq_exact(>dev, freq, true);
 
-   return (!IS_ERR(opp)) ? dev_pm_opp_get_voltage(opp) / 1000 : 0;
+   if (!IS_ERR(opp)) {
+   ret = dev_pm_opp_get_voltage(opp) / 1000;
+   dev_pm_opp_put(opp);
+   }
+
+   return ret;
 }
 
 /* Setup thermal limit management */
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 05022ea..e1eb7e1 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -239,8 +239,10 @@ static int adreno_get_pwrlevels(struct device *dev,
 
/* Find the fastest defined rate */
opp = dev_pm_opp_find_freq_floor(dev, );
-   if (!IS_ERR(opp))
+   if (!IS_ERR(opp)) {
config->fast_rate = dev_pm_opp_get_freq(opp);
+   dev_pm_opp_put(opp);
+   }
 
if (!config->fast_rate) {
DRM_DEV_INFO(dev,
-- 
1.9.1

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

[PATCH 3/8] drm/msm/gpu: Remove unused bus scaling code

[Jordan Crouse]

Remove the downstream bus scaling code. It isn't needed for for
compatibility with a downstream or vendor kernel. Get it out of the
way to clear space for devfreq support.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  7 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  5 +
 drivers/gpu/drm/msm/msm_gpu.c   | 39 -
 drivers/gpu/drm/msm/msm_gpu.h   |  7 +-
 4 files changed, 3 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 2f0610f..61e3091 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -480,13 +480,8 @@ int adreno_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
adreno_gpu->rev = config->rev;
 
gpu->fast_rate = config->fast_rate;
-   gpu->bus_freq  = config->bus_freq;
-#ifdef DOWNSTREAM_CONFIG_MSM_BUS_SCALING
-   gpu->bus_scale_table = config->bus_scale_table;
-#endif
 
-   DBG("fast_rate=%u, slow_rate=2700, bus_freq=%u",
-   gpu->fast_rate, gpu->bus_freq);
+   DBG("fast_rate=%u, slow_rate=2700", gpu->fast_rate);
 
adreno_gpu_config.ioname = "kgsl_3d0_reg_memory";
adreno_gpu_config.irqname = "kgsl_3d0_irq";
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 28e3de6..88d1bdf 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -129,10 +129,7 @@ struct adreno_gpu {
 /* platform config data (ie. from DT, or pdata) */
 struct adreno_platform_config {
struct adreno_rev rev;
-   uint32_t fast_rate, bus_freq;
-#ifdef DOWNSTREAM_CONFIG_MSM_BUS_SCALING
-   struct msm_bus_scale_pdata *bus_scale_table;
-#endif
+   uint32_t fast_rate;
 };
 
 #define ADRENO_IDLE_TIMEOUT msecs_to_jiffies(1000)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index fb5a1e0..3d00e7a 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -27,37 +27,6 @@
  * Power Management:
  */
 
-#ifdef DOWNSTREAM_CONFIG_MSM_BUS_SCALING
-#include 
-static void bs_init(struct msm_gpu *gpu)
-{
-   if (gpu->bus_scale_table) {
-   gpu->bsc = msm_bus_scale_register_client(gpu->bus_scale_table);
-   DBG("bus scale client: %08x", gpu->bsc);
-   }
-}
-
-static void bs_fini(struct msm_gpu *gpu)
-{
-   if (gpu->bsc) {
-   msm_bus_scale_unregister_client(gpu->bsc);
-   gpu->bsc = 0;
-   }
-}
-
-static void bs_set(struct msm_gpu *gpu, int idx)
-{
-   if (gpu->bsc) {
-   DBG("set bus scaling: %d", idx);
-   msm_bus_scale_client_update_request(gpu->bsc, idx);
-   }
-}
-#else
-static void bs_init(struct msm_gpu *gpu) {}
-static void bs_fini(struct msm_gpu *gpu) {}
-static void bs_set(struct msm_gpu *gpu, int idx) {}
-#endif
-
 static int enable_pwrrail(struct msm_gpu *gpu)
 {
struct drm_device *dev = gpu->dev;
@@ -143,8 +112,6 @@ static int enable_axi(struct msm_gpu *gpu)
 {
if (gpu->ebi1_clk)
clk_prepare_enable(gpu->ebi1_clk);
-   if (gpu->bus_freq)
-   bs_set(gpu, gpu->bus_freq);
return 0;
 }
 
@@ -152,8 +119,6 @@ static int disable_axi(struct msm_gpu *gpu)
 {
if (gpu->ebi1_clk)
clk_disable_unprepare(gpu->ebi1_clk);
-   if (gpu->bus_freq)
-   bs_set(gpu, 0);
return 0;
 }
 
@@ -756,8 +721,6 @@ int msm_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
gpu->pdev = pdev;
platform_set_drvdata(pdev, gpu);
 
-   bs_init(gpu);
-
gpu->aspace = msm_gpu_create_address_space(gpu, pdev,
config->va_start, config->va_end);
 
@@ -827,8 +790,6 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
 
WARN_ON(!list_empty(>active_list));
 
-   bs_fini(gpu);
-
for (i = 0; i < ARRAY_SIZE(gpu->rb); i++) {
msm_ringbuffer_destroy(gpu->rb[i]);
gpu->rb[i] = NULL;
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index e113d64..0de26b6 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -108,12 +108,7 @@ struct msm_gpu {
struct clk **grp_clks;
int nr_clocks;
struct clk *ebi1_clk, *core_clk, *rbbmtimer_clk;
-   uint32_t fast_rate, bus_freq;
-
-#ifdef DOWNSTREAM_CONFIG_MSM_BUS_SCALING
-   struct msm_bus_scale_pdata *bus_scale_table;
-   uint32_t bsc;
-#endif
+   uint32_t fast_rate;
 
/* Hang and Inactivity Detection:
 */
-- 
1.9.1

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

[PATCH 5/8] drm/msm/adreno: Move clock parsing to adreno_gpu_init()

[Jordan Crouse]

Move the clock parsing to adreno_gpu_init() to allow for target
specific probing and manipulation of the clock tables.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/adreno_device.c | 72 
 drivers/gpu/drm/msm/adreno/adreno_gpu.c| 77 --
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|  1 -
 3 files changed, 73 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 80d26b9..250fa1e 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -17,7 +17,6 @@
  * this program.  If not, see .
  */
 
-#include 
 #include "adreno_gpu.h"
 
 #define ANY_ID 0xff
@@ -196,70 +195,6 @@ static int find_chipid(struct device *dev, struct 
adreno_rev *rev)
return 0;
 }
 
-/* Get legacy powerlevels from qcom,gpu-pwrlevels and populate the opp table */
-static int adreno_get_legacy_pwrlevels(struct device *dev)
-{
-   struct device_node *child, *node;
-   int ret;
-
-   node = of_find_compatible_node(dev->of_node, NULL,
-   "qcom,gpu-pwrlevels");
-   if (!node) {
-   dev_err(dev, "Could not find the GPU powerlevels\n");
-   return -ENXIO;
-   }
-
-   for_each_child_of_node(node, child) {
-   unsigned int val;
-
-   ret = of_property_read_u32(child, "qcom,gpu-freq", );
-   if (ret)
-   continue;
-
-   /*
-* Skip the intentionally bogus clock value found at the bottom
-* of most legacy frequency tables
-*/
-   if (val != 2700)
-   dev_pm_opp_add(dev, val, 0);
-   }
-
-   return 0;
-}
-
-static int adreno_get_pwrlevels(struct device *dev,
-   struct adreno_platform_config *config)
-{
-   unsigned long freq = ULONG_MAX;
-   struct dev_pm_opp *opp;
-   int ret;
-
-   /* You down with OPP? */
-   if (!of_find_property(dev->of_node, "operating-points-v2", NULL))
-   ret = adreno_get_legacy_pwrlevels(dev);
-   else
-   ret = dev_pm_opp_of_add_table(dev);
-
-   if (ret)
-   return ret;
-
-   /* Find the fastest defined rate */
-   opp = dev_pm_opp_find_freq_floor(dev, );
-   if (!IS_ERR(opp)) {
-   config->fast_rate = freq;
-   dev_pm_opp_put(opp);
-   }
-
-   if (!config->fast_rate) {
-   DRM_DEV_INFO(dev,
-   "Could not find clock rate. Using default\n");
-   /* Pick a suitably safe clock speed for any target */
-   config->fast_rate = 2;
-   }
-
-   return 0;
-}
-
 static int adreno_bind(struct device *dev, struct device *master, void *data)
 {
static struct adreno_platform_config config = {};
@@ -272,13 +207,6 @@ static int adreno_bind(struct device *dev, struct device 
*master, void *data)
if (ret)
return ret;
 
-   /* find clock rates: */
-   config.fast_rate = 0;
-
-   ret = adreno_get_pwrlevels(dev, );
-   if (ret)
-   return ret;
-
dev->platform_data = 
set_gpu_pdev(drm, to_platform_device(dev));
 
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 61e3091..b4bac84 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -17,6 +17,7 @@
  * this program.  If not, see .
  */
 
+#include 
 #include "adreno_gpu.h"
 #include "msm_gem.h"
 #include "msm_mmu.h"
@@ -465,6 +466,76 @@ void adreno_wait_ring(struct msm_ringbuffer *ring, 
uint32_t ndwords)
ring->id);
 }
 
+/* Get legacy powerlevels from qcom,gpu-pwrlevels and populate the opp table */
+static int adreno_get_legacy_pwrlevels(struct device *dev)
+{
+   struct device_node *child, *node;
+   int ret;
+
+   node = of_find_compatible_node(dev->of_node, NULL,
+   "qcom,gpu-pwrlevels");
+   if (!node) {
+   dev_err(dev, "Could not find the GPU powerlevels\n");
+   return -ENXIO;
+   }
+
+   for_each_child_of_node(node, child) {
+   unsigned int val;
+
+   ret = of_property_read_u32(child, "qcom,gpu-freq", );
+   if (ret)
+   continue;
+
+   /*
+* Skip the intentionally bogus clock value found at the bottom
+* of most legacy frequency tables
+*/
+   if (val != 2700)
+   dev_pm_opp_add(dev, val, 0);
+   }
+
+   return 0;
+}
+
+static int adreno_get_pwrlevels(struct device *dev,
+   struct msm_gpu *gpu)
+{
+   unsigned long freq = ULONG_MAX;
+   struct 

[PATCH 0/8] msm/gpu: devfreq support

[Jordan Crouse]

Here is a stack of patches to enable devfreq support for Adreno GPUs.
This stack adds support for a5xx only, but it should be trivial to
add support for the other targets.  I'll send the DT changes 
separately.

Jordan Crouse (8):
  drm/msm/adreno: Call dev_pm_opp_put()
  drm/msm/adreno: Remove a useless call to dev_pm_opp_get_freq()
  drm/msm/gpu: Remove unused bus scaling code
  drm/msm/adreno: Cleanup chipid parsing
  drm/msm/adreno: Move clock parsing to adreno_gpu_init()
  drm/msm/adreno: Read the speed bins for a5xx targets
  drm/msm/adreno: a5xx: Explicitly program the CP0 performance counter
  drm/msm/gpu: Add devfreq support for the GPU

 drivers/gpu/drm/msm/adreno/a5xx_gpu.c  |  38 ++
 drivers/gpu/drm/msm/adreno/a5xx_power.c|   8 ++-
 drivers/gpu/drm/msm/adreno/adreno_device.c | 112 ++---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|  83 ++---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|   4 --
 drivers/gpu/drm/msm/msm_gpu.c  | 105 ---
 drivers/gpu/drm/msm/msm_gpu.h  |  14 ++--
 7 files changed, 225 insertions(+), 139 deletions(-)

-- 
1.9.1

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

[PATCH 2/8] drm/msm/adreno: Remove a useless call to dev_pm_opp_get_freq()

[Jordan Crouse]

Calling dev_pm_opp_find_freq_floor() returns the matched frequency
in 'freq'.  We don't need to call dev_pm_opp_get_freq() again
to get the frequency value.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/adreno_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index e1eb7e1..e85a1cc 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -240,7 +240,7 @@ static int adreno_get_pwrlevels(struct device *dev,
/* Find the fastest defined rate */
opp = dev_pm_opp_find_freq_floor(dev, );
if (!IS_ERR(opp)) {
-   config->fast_rate = dev_pm_opp_get_freq(opp);
+   config->fast_rate = freq;
dev_pm_opp_put(opp);
}
 
-- 
1.9.1

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

[PATCH 8/8] drm/msm/gpu: Add devfreq support for the GPU

[Jordan Crouse]

Add support for devfreq to dynamically control the GPU frequency.
By default try to use the 'simple_ondemand' governor which can
adjust the frequency based on GPU load.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 12 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  1 -
 drivers/gpu/drm/msm/msm_gpu.c   | 90 +
 drivers/gpu/drm/msm/msm_gpu.h   |  7 +++
 4 files changed, 109 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 56c2c44..7e09d44 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -600,6 +600,9 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
/* Select CP0 to always count cycles */
gpu_write(gpu, REG_A5XX_CP_PERFCTR_CP_SEL_0, PERF_CP_ALWAYS_COUNT);
 
+   /* Select RBBM0 to countable 6 to get the busy status for devfreq */
+   gpu_write(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_SEL_0, 6);
+
/* Increase VFD cache access so LRZ and other data gets evicted less */
gpu_write(gpu, REG_A5XX_UCHE_CACHE_WAYS, 0x02);
 
@@ -1170,6 +1173,14 @@ static struct msm_ringbuffer *a5xx_active_ring(struct 
msm_gpu *gpu)
return a5xx_gpu->cur_ring;
 }
 
+static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t *value)
+{
+   *value = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
+   REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
+
+   return 0;
+}
+
 static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
@@ -1185,6 +1196,7 @@ static struct msm_ringbuffer *a5xx_active_ring(struct 
msm_gpu *gpu)
 #ifdef CONFIG_DEBUG_FS
.show = a5xx_show,
 #endif
+   .gpu_busy = a5xx_gpu_busy,
},
.get_timestamp = a5xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index b4bac84..de63ff2 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -22,7 +22,6 @@
 #include "msm_gem.h"
 #include "msm_mmu.h"
 
-
 int adreno_get_param(struct msm_gpu *gpu, uint32_t param, uint64_t *value)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 3d00e7a..243e06e 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -21,12 +21,90 @@
 #include "msm_fence.h"
 
 #include 
+#include 
+#include 
 
 
 /*
  * Power Management:
  */
 
+static int msm_devfreq_target(struct device *dev, unsigned long *freq,
+   u32 flags)
+{
+   struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
+   struct dev_pm_opp *opp;
+
+   opp = dev_pm_opp_find_freq_ceil(dev, freq);
+
+   if (!IS_ERR(opp)) {
+   clk_set_rate(gpu->core_clk, *freq);
+   dev_pm_opp_put(opp);
+   }
+
+   return 0;
+}
+
+static int msm_devfreq_get_dev_status(struct device *dev,
+   struct devfreq_dev_status *status)
+{
+   struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
+   u64 cycles;
+   ktime_t time;
+
+   status->current_frequency = (unsigned long) clk_get_rate(gpu->core_clk);
+   gpu->funcs->gpu_busy(gpu, );
+
+   status->busy_time = (cycles - gpu->devfreq.busy_cycles) /
+   (status->current_frequency / 100);
+
+   gpu->devfreq.busy_cycles = cycles;
+
+   time = ktime_get();
+   status->total_time = ktime_us_delta(time, gpu->devfreq.time);
+   gpu->devfreq.time = time;
+
+   return 0;
+}
+
+static int msm_devfreq_get_cur_freq(struct device *dev, unsigned long *freq)
+{
+   struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
+
+   *freq = (unsigned long) clk_get_rate(gpu->core_clk);
+
+   return 0;
+}
+
+static struct devfreq_dev_profile msm_devfreq_profile = {
+   .polling_ms = 10,
+   .target = msm_devfreq_target,
+   .get_dev_status = msm_devfreq_get_dev_status,
+   .get_cur_freq = msm_devfreq_get_cur_freq,
+};
+
+static void msm_devfreq_init(struct msm_gpu *gpu)
+{
+   /* We need target support to do devfreq */
+   if (!gpu->funcs->gpu_busy)
+   return;
+
+   msm_devfreq_profile.initial_freq = gpu->fast_rate;
+
+   /*
+* Don't set the freq_table or max_state and let devfreq build the table
+* from OPP
+*/
+
+   gpu->devfreq.devfreq = devm_devfreq_add_device(>pdev->dev,
+   _devfreq_profile, "simple_ondemand", NULL);
+
+   if (IS_ERR(gpu->devfreq.devfreq)) {
+   dev_err(>pdev->dev, "Couldn't initialize GPU devfreq\n");
+   gpu->devfreq.devfreq = NULL;
+   }
+}
+
 static int enable_pwrrail(struct msm_gpu *gpu)
 {
struct drm_device *dev = gpu->dev;
@@ -140,6 +218,13 @@ int 

[PATCH 4/8] drm/msm/adreno: Cleanup chipid parsing

[Jordan Crouse]

We don't need to convert the chipid to an intermediate value and
then back again into a struct adreno_rev.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/adreno_device.c | 44 +++---
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index e85a1cc..80d26b9 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -153,39 +153,45 @@ static void set_gpu_pdev(struct drm_device *dev,
priv->gpu_pdev = pdev;
 }
 
-static int find_chipid(struct device *dev, u32 *chipid)
+static int find_chipid(struct device *dev, struct adreno_rev *rev)
 {
struct device_node *node = dev->of_node;
const char *compat;
int ret;
+   u32 chipid;
 
/* first search the compat strings for qcom,adreno-XYZ.W: */
ret = of_property_read_string_index(node, "compatible", 0, );
if (ret == 0) {
-   unsigned rev, patch;
+   unsigned int r, patch;
 
-   if (sscanf(compat, "qcom,adreno-%u.%u", , ) == 2) {
-   *chipid = 0;
-   *chipid |= (rev / 100) << 24;  /* core */
-   rev %= 100;
-   *chipid |= (rev / 10) << 16;   /* major */
-   rev %= 10;
-   *chipid |= rev << 8;   /* minor */
-   *chipid |= patch;
+   if (sscanf(compat, "qcom,adreno-%u.%u", , ) == 2) {
+   rev->core = r / 100;
+   r %= 100;
+   rev->major = r / 10;
+   r %= 10;
+   rev->minor = r;
+   rev->patchid = patch;
 
return 0;
}
}
 
/* and if that fails, fall back to legacy "qcom,chipid" property: */
-   ret = of_property_read_u32(node, "qcom,chipid", chipid);
-   if (ret)
+   ret = of_property_read_u32(node, "qcom,chipid", );
+   if (ret) {
+   dev_err(dev, "could not parse qcom,chipid: %d\n", ret);
return ret;
+   }
+
+   rev->core = (chipid >> 24) & 0xff;
+   rev->major = (chipid >> 16) & 0xff;
+   rev->minor = (chipid >> 8) & 0xff;
+   rev->patchid = (chipid & 0xff);
 
dev_warn(dev, "Using legacy qcom,chipid binding!\n");
dev_warn(dev, "Use compatible qcom,adreno-%u%u%u.%u instead.\n",
-   (*chipid >> 24) & 0xff, (*chipid >> 16) & 0xff,
-   (*chipid >> 8) & 0xff, *chipid & 0xff);
+   rev->core, rev->major, rev->minor, rev->patchid);
 
return 0;
 }
@@ -260,17 +266,11 @@ static int adreno_bind(struct device *dev, struct device 
*master, void *data)
const struct adreno_info *info;
struct drm_device *drm = dev_get_drvdata(master);
struct msm_gpu *gpu;
-   u32 val;
int ret;
 
-   ret = find_chipid(dev, );
-   if (ret) {
-   dev_err(dev, "could not find chipid: %d\n", ret);
+   ret = find_chipid(dev, );
+   if (ret)
return ret;
-   }
-
-   config.rev = ADRENO_REV((val >> 24) & 0xff,
-   (val >> 16) & 0xff, (val >> 8) & 0xff, val & 0xff);
 
/* find clock rates: */
config.fast_rate = 0;
-- 
1.9.1

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

[PATCH 6/8] drm/msm/adreno: Read the speed bins for a5xx targets

[Jordan Crouse]

Some 5xx based chipsets have different bins for GPU clock speeds.
Read the fuses (if applicable) and set the appropriate OPP table.
This will only work with OPP v2 tables - the bin will be ignored
for legacy pwrlevel tables.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index a1f4eee..fdbe9e9 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "msm_gem.h"
 #include "msm_mmu.h"
 #include "a5xx_gpu.h"
@@ -1184,6 +1186,25 @@ static struct msm_ringbuffer *a5xx_active_ring(struct 
msm_gpu *gpu)
.get_timestamp = a5xx_get_timestamp,
 };
 
+static void check_speed_bin(struct device *dev)
+{
+   struct nvmem_cell *cell;
+   u32 bin, val;
+
+   cell = nvmem_cell_get(dev, "speed_bin");
+
+   /* If a nvmem cell isn't defined, nothing to do */
+   if (IS_ERR(cell))
+   return;
+
+   bin = *((u32 *) nvmem_cell_read(cell, NULL));
+   nvmem_cell_put(cell);
+
+   val = (1 << bin);
+
+   dev_pm_opp_set_supported_hw(dev, , 1);
+}
+
 struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
 {
struct msm_drm_private *priv = dev->dev_private;
@@ -1210,6 +1231,8 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
 
a5xx_gpu->lm_leakage = 0x4E001A;
 
+   check_speed_bin(>dev);
+
ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 4);
if (ret) {
a5xx_destroy(&(a5xx_gpu->base.base));
-- 
1.9.1

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

Re: [PATCH 1/1] drm/amdkfd: Do not ignore requested queue size during allocation

[Felix Kuehling]

On 2017-11-21 06:44 AM, Oded Gabbay wrote:
> Thanks Felix for catching that, For some reason I remembered  EOP
> buffer should be the same size of the queue.

The EOP queue size is hard-coded to prop.eop_ring_buffer_size =
PAGE_SIZE for kernel queues in initialize in kfd_kernel_queue.c. I'm not
too familiar with the HW/FW details. But I see this comment in
kfd_mqd_manager_vi.c:

/*
 * HW does not clamp this field correctly. Maximum EOP queue size
 * is constrained by per-SE EOP done signal count, which is 8-bit.
 * Limit is 0xFF EOP entries (= 0x7F8 dwords). CP will not submit
 * more than (EOP entry count - 1) so a queue size of 0x800 dwords
 * is safe, giving a maximum field value of 0xA.
 */

With that the maximum possible EOP queue size would be two pages,
regardless of the queue size.

> Then we can remove the queue size parameter from that function ?

Not the way the code is currently organized. Currently struct
kernel_queue_ops is shared for ASIC-independent and ASIC-specific queue
ops. The ASIC-independent initialize function in kfd_kernel_queue.c
still needs this parameter.

That said, the kernel_queue stuff could be cleaned up a bit in general.
IMO the hardware-independent functions don't really need to be called
through function pointers. The ASIC-specific function pointers don't
need to be in the kernel_queue structure, they could be in kfd_dev.

Regards,
  Felix

>
> On Mon, Nov 20, 2017 at 9:22 PM, Felix Kuehling  
> wrote:
>> I think this patch is not correct. The EOP-mem is not associated with
>> the queue size. The EOP buffer is a separate buffer used by the firmware
>> to handle command completion. As I understand it, this allows more
>> concurrency, while still making it look like all commands in the queue
>> are completing in order.
>>
>> Regards,
>>   Felix
>>
>>
>> On 2017-11-19 03:19 AM, Oded Gabbay wrote:
>>> On Thu, Nov 16, 2017 at 11:36 PM, Jan Vesely  wrote:
 Signed-off-by: Jan Vesely 
 ---
  drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c 
 b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c
 index f1d48281e322..b3bee39661ab 100644
 --- a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c
 +++ b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c
 @@ -37,15 +37,16 @@ static bool initialize_vi(struct kernel_queue *kq, 
 struct kfd_dev *dev,
 enum kfd_queue_type type, unsigned int queue_size)
  {
 int retval;
 +   unsigned int size = ALIGN(queue_size, PAGE_SIZE);

 -   retval = kfd_gtt_sa_allocate(dev, PAGE_SIZE, >eop_mem);
 +   retval = kfd_gtt_sa_allocate(dev, size, >eop_mem);
 if (retval != 0)
 return false;

 kq->eop_gpu_addr = kq->eop_mem->gpu_addr;
 kq->eop_kernel_addr = kq->eop_mem->cpu_ptr;

 -   memset(kq->eop_kernel_addr, 0, PAGE_SIZE);
 +   memset(kq->eop_kernel_addr, 0, size);

 return true;
  }
 --
 2.13.6

 ___
 amd-gfx mailing list
 amd-...@lists.freedesktop.org
 https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>> Thanks!
>>> Applied to -next tree
>>> Oded
>>> ___
>>> amd-gfx mailing list
>>> amd-...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

[Emil Velikov]

On 21 November 2017 at 15:07,   wrote:
> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
>> - Document the autoselect process
>>Information about about What, Why, and [ideally] How - analogous to
>>the normal stable nominations.
>>Insert reference to the process in the patch notification email.
>
> I agree with this one, and it'll definitely happen. The story behind
> this is that this is all based on Julia Lawall's work which is well
> documented in a published paper here:
>
> https://soarsmu.github.io/papers/icse12-patch.pdf
>
> I have modified inputs and process, but it essentially is very similar
> to what's described in that paper.
>
> While I have no problem with sharing what I have so far, this is
> still very much work in progress, and things keep constantly changing
> based on comments I receive from reviewers and Greg, so I want to
> reach a more stable point before trying to explain things and change
> my mind the day after :)
>
> If anyone is really interested in seeing the guts of this mess I
> currently have I can push it to github, but bear in mind that in it's
> current state it's very custom to the configuration I have, and is
> a borderline unreadable mix of bash scripts and LUA.
>
> Ideally it'll all get cleaned up and pushed anyways once I feel
> comfortable with the quality of the process.
>
At first I would focus on What and Why. Getting that information out
and publicising it via that blogs, G+, meetings, etc. is essential.
Reference to the current [WIP or not] heuristics is nice but can
follow-up in due time. A placeholder must be available though.

>> - Make the autoselect nominations _more_ distinct than the normal stable 
>> ones.
>>Maintainers will want to put more cognitive effort into the patches.
>
> So this came up before, and the participants of that thread agreed
> that adding "AUTOSEL" in the patch prefix is sufficient. What else
> would you suggest adding?
>
Being consistent [with existing stable nominations style] is good, but
first focus* should be on making it noticeable and distinct.
In other words - do _not_ be consistent.

Flipping the order AUTOSEL PATCH, using WARN, NOTE or just dropping
PATCH should help.
People tend to read PATC. /xx: ... last words of commit message.

Additionally, different template + a big note/warning in the email
body is a good idea. Say:
WARNING: This patch is nominated via the autosel procedure as defined at $ref.

HTH
Emil

* Regardless if autosel patches default to "ACK to merge" or not.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

[Greg KH]

On Tue, Nov 21, 2017 at 12:09:33PM -0500, Josh Boyer wrote:
> On Tue, Nov 21, 2017 at 10:07 AM,   wrote:
> > On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
> >> - Document the autoselect process
> >>Information about about What, Why, and [ideally] How - analogous to
> >>the normal stable nominations.
> >>Insert reference to the process in the patch notification email.
> >
> > I agree with this one, and it'll definitely happen. The story behind
> > this is that this is all based on Julia Lawall's work which is well
> > documented in a published paper here:
> >
> > https://soarsmu.github.io/papers/icse12-patch.pdf
> >
> > I have modified inputs and process, but it essentially is very similar
> > to what's described in that paper.
> >
> > While I have no problem with sharing what I have so far, this is
> > still very much work in progress, and things keep constantly changing
> > based on comments I receive from reviewers and Greg, so I want to
> > reach a more stable point before trying to explain things and change
> > my mind the day after :)
> >
> > If anyone is really interested in seeing the guts of this mess I
> > currently have I can push it to github, but bear in mind that in it's
> > current state it's very custom to the configuration I have, and is
> > a borderline unreadable mix of bash scripts and LUA.
> >
> > Ideally it'll all get cleaned up and pushed anyways once I feel
> > comfortable with the quality of the process.
> >
> >> - Make the autoselect nominations _more_ distinct than the normal stable 
> >> ones.
> >>Maintainers will want to put more cognitive effort into the patches.
> >
> > So this came up before, and the participants of that thread agreed
> > that adding "AUTOSEL" in the patch prefix is sufficient. What else
> > would you suggest adding?
> 
> The root of the concern seems to be around how the stable process
> currently works and how auto-selection plays into that.  When Greg
> sends out the RC, the default model of "if nobody objects, this patch
> will get included in the next stable release" works because a human
> already identified as that needing to be included.  So the review is
> looking for a NAK, but that's overriding another human's explicit
> decision with reasons.  For something that is auto-selected, people
> seem concerned that the default should be flipped.  Perhaps they'd be
> more comfortable if auto-selected packages required a human ACK before
> they are included?

As much fun as that might be, that's going to cut _way_ down on the
number of real bugfixes that get applied to the kernel due to the lag in
responses.  I review all of these patches, as does Sasha, so I think
let's stick with the existing mode of "it passes our review so let's
include it".  Becides, the testing that everyone is doing on the stable
kernels should catch any real problems, right?  :)

But if any subsystems don't want us to include patches this way, just
let us know.  It seems the graphics developers don't want their patches
backported, which is fine, we will leave them alone...

thanks,

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

[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103370

--- Comment #39 from Alex Deucher  ---
Created attachment 135648
  --> https://bugs.freedesktop.org/attachment.cgi?id=135648=edit
workaround for amdgpu

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

[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103370

--- Comment #38 from Alex Deucher  ---
Created attachment 135647
  --> https://bugs.freedesktop.org/attachment.cgi?id=135647=edit
workaround for radeon

workarounds for radeon and amdgpu to fix the issue.

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

Re: [REBASE 2/5] drm: Handle aspect ratio in modeset paths

[Ville Syrjälä]

On Fri, Nov 17, 2017 at 03:00:29PM +0530, Shashank Sharma wrote:
> From: Ankit Nautiyal 
> 
> If the user mode does not support aspect-ratio, and requests for
> a modeset with aspect ratio flags, then the flag bits reprsenting
> aspect ratio must be ignored.

Rejected, not ignored. Rejection should happen when converting
the umode to mode.

And filtering should happen in getcrtc and getblob. The way you're
currently doing things will corrupt the current state, which is
not good.

> Similarly, if user space doesn't set the aspect ratio client cap,
> while preparing a usermode, the aspect-ratio info must not be given
> into it.
> 
> This patch:
> 1. adds a new bit field aspect_ratio_allowed in drm_atomic_state,
>which is set only if the aspect-ratio is supported by the user.
> 2. discards the aspect-ratio info from the user mode while
>preparing kernel mode structure, during modeset, if the
>user does not support aspect ratio.
> 3. avoids setting the aspect-ratio info in user-mode, while
>converting user-mode from the kernel-mode.
> 
> Cc: Ville Syrjala 
> Cc: Shashank Sharma 
> Cc: Jose Abreu 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/drm_atomic.c | 40 +---
>  drivers/gpu/drm/drm_crtc.c   | 19 +++
>  include/drm/drm_atomic.h |  2 ++
>  3 files changed, 54 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 37445d5..b9743af 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -338,18 +338,30 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
> *state,
>   state->mode_blob = NULL;
>  
>   if (mode) {
> - drm_mode_convert_to_umode(, mode);
> + /*
> +  * If the user has not asked for aspect ratio support,
> +  * take a copy of the 'mode' and set the aspect ratio as
> +  * None. This copy is used to prepare the user-mode with no
> +  * aspect-ratio info.
> +  */
> + struct drm_display_mode ar_mode;
> + struct drm_atomic_state *atomic_state = state->state;
> +
> + drm_mode_copy(_mode, mode);
> + if (atomic_state && !atomic_state->allow_aspect_ratio)
> + ar_mode.picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> + drm_mode_convert_to_umode(, _mode);
>   state->mode_blob =
>   drm_property_create_blob(state->crtc->dev,
> -  sizeof(umode),
> -  );
> +  sizeof(umode),
> +  );
>   if (IS_ERR(state->mode_blob))
>   return PTR_ERR(state->mode_blob);
>  
> - drm_mode_copy(>mode, mode);
> + drm_mode_copy(>mode, _mode);
>   state->enable = true;
>   DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
> -  mode->name, state);
> +  ar_mode.name, state);
>   } else {
>   memset(>mode, 0, sizeof(state->mode));
>   state->enable = false;
> @@ -386,10 +398,23 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
> drm_crtc_state *state,
>   memset(>mode, 0, sizeof(state->mode));
>  
>   if (blob) {
> + struct drm_mode_modeinfo *ar_umode;
> + struct drm_atomic_state *atomic_state;
> +
> + /*
> +  * If the user-space does not ask for aspect-ratio
> +  * the aspect ratio bits in the drmModeModeinfo from user,
> +  * does not mean anything. Therefore these bits must be
> +  * discarded.
> +  */
> + ar_umode = (struct drm_mode_modeinfo *) blob->data;
> + atomic_state = state->state;
> + if (atomic_state && !atomic_state->allow_aspect_ratio)
> + ar_umode->flags &= (~DRM_MODE_FLAG_PIC_AR_MASK);
>   if (blob->length != sizeof(struct drm_mode_modeinfo) ||
>   drm_mode_convert_umode(>mode,
> -(const struct drm_mode_modeinfo *)
> - blob->data))
> +(const struct drm_mode_modeinfo *)
> + ar_umode))
>   return -EINVAL;
>  
>   state->mode_blob = drm_property_blob_get(blob);
> @@ -2229,6 +2254,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>  
>   state->acquire_ctx = 
>   state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
> + state->allow_aspect_ratio = 

Re: [REBASE 3/5] drm: Expose modes with aspect ratio, only if requested

[Ville Syrjälä]

On Fri, Nov 17, 2017 at 03:00:30PM +0530, Shashank Sharma wrote:
> From: aknautiy 
> 
> We parse the EDID and add all the modes in the connector's
> modelist. This adds CEA modes with aspect ratio information
> too, regadless of if user space requested this information or
> not.
> 
> This patch prunes the modes with aspect-ratio information, from
> a connector's modelist, if the user-space has not set the aspect
> ratio DRM client cap.
> 
> Cc: Ville Syrjala 
> Cc: Shashank Sharma 
> Cc: Jose Abreu 
> 
> Signed-off-by: aknautiy 
> ---
>  drivers/gpu/drm/drm_connector.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 704fc89..a246bb5 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1285,6 +1285,13 @@ static bool drm_mode_expose_to_userspace(const struct 
> drm_display_mode *mode,
>*/
>   if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
>   return false;
> + /*
> +  * If user-space hasn't configured the driver to expose the modes
> +  * with aspect-ratio, don't expose them.
> +  */
> + if (!file_priv->aspect_ratio_allowed &&
> + mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE)
> + return false;

I don't think we can just blindly drop the modes. We would have to
expose them with the aspect ratio cleared. That could lead to
duplicates, but I'm thinking that shouldn't be a real problem for
userspace. Having to filteri out the duplicates would certainly
complicate things a bit.

>  
>   return true;
>  }
> -- 
> 2.7.4

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

Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

[alexander . levin]

On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
> - Document the autoselect process
>Information about about What, Why, and [ideally] How - analogous to
>the normal stable nominations.
>Insert reference to the process in the patch notification email.

I agree with this one, and it'll definitely happen. The story behind
this is that this is all based on Julia Lawall's work which is well
documented in a published paper here:

https://soarsmu.github.io/papers/icse12-patch.pdf

I have modified inputs and process, but it essentially is very similar
to what's described in that paper.

While I have no problem with sharing what I have so far, this is
still very much work in progress, and things keep constantly changing
based on comments I receive from reviewers and Greg, so I want to
reach a more stable point before trying to explain things and change
my mind the day after :)

If anyone is really interested in seeing the guts of this mess I
currently have I can push it to github, but bear in mind that in it's
current state it's very custom to the configuration I have, and is
a borderline unreadable mix of bash scripts and LUA.

Ideally it'll all get cleaned up and pushed anyways once I feel
comfortable with the quality of the process.

> - Make the autoselect nominations _more_ distinct than the normal stable ones.
>Maintainers will want to put more cognitive effort into the patches.

So this came up before, and the participants of that thread agreed
that adding "AUTOSEL" in the patch prefix is sufficient. What else
would you suggest adding?

-- 

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

Re: [PATCH v2 4/4] drm: omapdrm: Fix DPI on platforms using the DSI VDDS

[H. Nikolaus Schaller]

Hi,

> Am 21.11.2017 um 11:25 schrieb Tomi Valkeinen :
> 
> On 16/11/17 10:50, H. Nikolaus Schaller wrote:
>> From: Laurent Pinchart 
>> 
>> Commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature
>> to dpi code") replaced usage of platform data version with SoC matching
>> to configure DPI VDDS. The SoC match entries were incorrect, they should
>> have matched on the machine name instead of the SoC family. Fix it.
>> 
>> The result was observed on OpenPandora with OMAP3530 where the panel only
>> had the Blue channel and Red were missing. It was not observed on
>> GTA04 with DM3730.
>> 
>> Fixes: d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to 
>> dpi code")
>> Signed-off-by: Laurent Pinchart 
>> Reported-by: H. Nikolaus Schaller 
>> Tested-by: H. Nikolaus Schaller 
>> ---
>> drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
>> b/drivers/gpu/drm/omapdrm/dss/dpi.c
>> index 4ed5fde11313..a91e5f1a0490 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
>> @@ -566,8 +566,8 @@ static int dpi_verify_pll(struct dss_pll *pll)
>> }
>> 
>> static const struct soc_device_attribute dpi_soc_devices[] = {
>> -{ .family = "OMAP3[456]*" },
>> -{ .family = "[AD]M37*" },
>> +{ .machine = "OMAP3[456]*" },
>> +{ .machine = "[AD]M37*" },
>>  { /* sentinel */ }
>> };
>> 
>> 
> 
> I have picked this one.

Fine.

> I think the rest of the patches are more of a
> cleanup, right? And you'll be sending v3 at some point.

Yes. Should we wait for more comments or should I send now?

BR and thanks,
Nikolaus Schaller


> 
> Tomi
> 
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[pull] amdgpu drm-next-4.15

[Alex Deucher]

Hi Dave,

A few more misc fixes for 4.15.  It doesn't look like you pulled
my request from last week.  Those fixes are in this branch as well.

The following changes since commit 451cc55dd17fa5130f05629ac8d90e32facf27f6:

  drm/amd/pp: fix dpm randomly failed on Vega10 (2017-11-15 14:03:45 -0500)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.15

for you to fetch changes up to 446947b44fb8cabc0213ff4efd706931e36b1963:

  drm/amdgpu: fix rmmod KCQ disable failed error (2017-11-21 10:45:05 -0500)


Alex Deucher (2):
  Revert "drm/radeon: dont switch vt on suspend"
  drm/amdgpu: don't skip attributes when powerplay is enabled

Eric Huang (1):
  drm/amd/powerplay: fix unfreeze level smc message for smu7

Monk Liu (2):
  drm/amdgpu:fix memleak in takedown
  drm/amdgpu:fix memleak

Rex Zhu (1):
  drm/amd/pp: fix typecast error in powerplay.

Roger He (1):
  drm/amd/amdgpu: fix over-bound accessing in amdgpu_cs_wait_any_fence

Wang Hongcheng (1):
  drm/amdgpu: fix rmmod KCQ disable failed error

Xiangliang.Yu (1):
  drm/amdgpu: fix kernel hang when starting VNC server

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  | 3 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c  | 4 
 drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c   | 3 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c| 5 -
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   | 8 
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   | 9 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c   | 8 
 drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c | 4 ++--
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c| 2 +-
 drivers/gpu/drm/radeon/radeon_fb.c  | 1 -
 14 files changed, 37 insertions(+), 25 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] reservation: don't wait when timeout=0

[Christian König]

Am 21.11.2017 um 16:58 schrieb Chris Wilson:

Quoting Christian König (2017-11-21 15:49:55)

Am 21.11.2017 um 15:59 schrieb Rob Clark:

On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson  wrote:

Quoting Rob Clark (2017-11-21 14:08:46)

If we are testing if a reservation object's fences have been
signaled with timeout=0 (non-blocking), we need to pass 0 for
timeout to dma_fence_wait_timeout().

Plus bonus spelling correction.

Signed-off-by: Rob Clark 
---
   drivers/dma-buf/reservation.c | 11 +--
   1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a815455d..71f51140a9ad 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
*
* RETURNS
* Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
- * greater than zer on success.
+ * greater than zero on success.
*/
   long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
   bool wait_all, bool intr,
@@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
  goto retry;
  }

-   ret = dma_fence_wait_timeout(fence, intr, ret);
+   /*
+* Note that dma_fence_wait_timeout() will return 1 if
+* the fence is already signaled, so in the wait_all
+* case when we go through the retry loop again, ret
+* will be greater than 0 and we don't want this to
+* cause _wait_timeout() to block
+*/
+   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 0);

One should ask if we should just fix the interface to stop returning
incorrect results (stop "correcting" a completion with 0 jiffies remaining
as 1). A timeout can be distinguished by -ETIME (or your pick of errno).

perhaps -EBUSY, if we go that route (although maybe it should be a
follow-on patch, this one is suitable for backport to stable/lts if
one should so choose..)

I think current approach was chosen to match schedule_timeout() and
other such functions that take a timeout in jiffies.  Not making a
judgement on whether that is a good or bad reason..

We intentionally switched away from that to be in sync with the
wait_event_* interface.

Returning 1 when a function with a zero timeout succeeds is actually
quite common in the kernel.

We actually had this conversation last time, and outside of that it
isn't. Looking at all the convolution to first return 1, then undo the
damage in the caller, it looks pretty silly.


I don't find that very intuitive either, but you would also have to 
handle the error code in the calling function as well.


And it is what the whole kernel does all over the place with it's 
wait_event_* and scheduler timeouts as well.


Regards,
Christian.


-Chris



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

Re: [PATCH] reservation: don't wait when timeout=0

[Chris Wilson]

Quoting Christian König (2017-11-21 15:49:55)
> Am 21.11.2017 um 15:59 schrieb Rob Clark:
> > On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson  
> > wrote:
> >> Quoting Rob Clark (2017-11-21 14:08:46)
> >>> If we are testing if a reservation object's fences have been
> >>> signaled with timeout=0 (non-blocking), we need to pass 0 for
> >>> timeout to dma_fence_wait_timeout().
> >>>
> >>> Plus bonus spelling correction.
> >>>
> >>> Signed-off-by: Rob Clark 
> >>> ---
> >>>   drivers/dma-buf/reservation.c | 11 +--
> >>>   1 file changed, 9 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> >>> index dec3a815455d..71f51140a9ad 100644
> >>> --- a/drivers/dma-buf/reservation.c
> >>> +++ b/drivers/dma-buf/reservation.c
> >>> @@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
> >>>*
> >>>* RETURNS
> >>>* Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
> >>> - * greater than zer on success.
> >>> + * greater than zero on success.
> >>>*/
> >>>   long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
> >>>   bool wait_all, bool intr,
> >>> @@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
> >>> reservation_object *obj,
> >>>  goto retry;
> >>>  }
> >>>
> >>> -   ret = dma_fence_wait_timeout(fence, intr, ret);
> >>> +   /*
> >>> +* Note that dma_fence_wait_timeout() will return 1 if
> >>> +* the fence is already signaled, so in the wait_all
> >>> +* case when we go through the retry loop again, ret
> >>> +* will be greater than 0 and we don't want this to
> >>> +* cause _wait_timeout() to block
> >>> +*/
> >>> +   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 
> >>> 0);
> >> One should ask if we should just fix the interface to stop returning
> >> incorrect results (stop "correcting" a completion with 0 jiffies remaining
> >> as 1). A timeout can be distinguished by -ETIME (or your pick of errno).
> > perhaps -EBUSY, if we go that route (although maybe it should be a
> > follow-on patch, this one is suitable for backport to stable/lts if
> > one should so choose..)
> >
> > I think current approach was chosen to match schedule_timeout() and
> > other such functions that take a timeout in jiffies.  Not making a
> > judgement on whether that is a good or bad reason..
> 
> We intentionally switched away from that to be in sync with the 
> wait_event_* interface.
> 
> Returning 1 when a function with a zero timeout succeeds is actually 
> quite common in the kernel.

We actually had this conversation last time, and outside of that it
isn't. Looking at all the convolution to first return 1, then undo the
damage in the caller, it looks pretty silly.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] reservation: don't wait when timeout=0

[Christian König]

Am 21.11.2017 um 15:59 schrieb Rob Clark:

On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson  wrote:

Quoting Rob Clark (2017-11-21 14:08:46)

If we are testing if a reservation object's fences have been
signaled with timeout=0 (non-blocking), we need to pass 0 for
timeout to dma_fence_wait_timeout().

Plus bonus spelling correction.

Signed-off-by: Rob Clark 
---
  drivers/dma-buf/reservation.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a815455d..71f51140a9ad 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
   *
   * RETURNS
   * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
- * greater than zer on success.
+ * greater than zero on success.
   */
  long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
  bool wait_all, bool intr,
@@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
 goto retry;
 }

-   ret = dma_fence_wait_timeout(fence, intr, ret);
+   /*
+* Note that dma_fence_wait_timeout() will return 1 if
+* the fence is already signaled, so in the wait_all
+* case when we go through the retry loop again, ret
+* will be greater than 0 and we don't want this to
+* cause _wait_timeout() to block
+*/
+   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 0);

One should ask if we should just fix the interface to stop returning
incorrect results (stop "correcting" a completion with 0 jiffies remaining
as 1). A timeout can be distinguished by -ETIME (or your pick of errno).

perhaps -EBUSY, if we go that route (although maybe it should be a
follow-on patch, this one is suitable for backport to stable/lts if
one should so choose..)

I think current approach was chosen to match schedule_timeout() and
other such functions that take a timeout in jiffies.  Not making a
judgement on whether that is a good or bad reason..


We intentionally switched away from that to be in sync with the 
wait_event_* interface.


Returning 1 when a function with a zero timeout succeeds is actually 
quite common in the kernel.


Regards,
Christian.


BR,
-R


-Chris

___
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 1/2] drivers/video/hdmi: allow for larger-than-needed vendor IF

[Ville Syrjälä]

On Mon, Nov 20, 2017 at 04:02:14PM +0100, Hans Verkuil wrote:
> On 11/20/2017 03:51 PM, Ville Syrjälä wrote:
> > On Mon, Nov 20, 2017 at 02:41:28PM +0100, Hans Verkuil wrote:
> >> From: Hans Verkuil 
> >>
> >> Some devices (Windows Intel driver!) send a Vendor InfoFrame that
> >> uses a payload length of 0x1b instead of the length of 5 or 6
> >> that the unpack code expects. The InfoFrame is padded with 0 by
> >> the source.
> > 
> > So it doesn't put any 3D_Metadata stuff in there? We don't see to
> > have code to parse/generate any of that.
> 
> I can't remember if it puts any 3D stuff in there. Let me know if you
> want me to check this later this week.

Would be nice to know.

I guess we should really add code to parse/generate that stuff too,
otherwise we're going to be lying when we unpack an infoframe with that
stuff present.

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

Re: [PATCH] reservation: don't wait when timeout=0

[Rob Clark]

On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson  wrote:
> Quoting Rob Clark (2017-11-21 14:08:46)
>> If we are testing if a reservation object's fences have been
>> signaled with timeout=0 (non-blocking), we need to pass 0 for
>> timeout to dma_fence_wait_timeout().
>>
>> Plus bonus spelling correction.
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  drivers/dma-buf/reservation.c | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
>> index dec3a815455d..71f51140a9ad 100644
>> --- a/drivers/dma-buf/reservation.c
>> +++ b/drivers/dma-buf/reservation.c
>> @@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
>>   *
>>   * RETURNS
>>   * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
>> - * greater than zer on success.
>> + * greater than zero on success.
>>   */
>>  long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
>>  bool wait_all, bool intr,
>> @@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
>> reservation_object *obj,
>> goto retry;
>> }
>>
>> -   ret = dma_fence_wait_timeout(fence, intr, ret);
>> +   /*
>> +* Note that dma_fence_wait_timeout() will return 1 if
>> +* the fence is already signaled, so in the wait_all
>> +* case when we go through the retry loop again, ret
>> +* will be greater than 0 and we don't want this to
>> +* cause _wait_timeout() to block
>> +*/
>> +   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 0);
>
> One should ask if we should just fix the interface to stop returning
> incorrect results (stop "correcting" a completion with 0 jiffies remaining
> as 1). A timeout can be distinguished by -ETIME (or your pick of errno).

perhaps -EBUSY, if we go that route (although maybe it should be a
follow-on patch, this one is suitable for backport to stable/lts if
one should so choose..)

I think current approach was chosen to match schedule_timeout() and
other such functions that take a timeout in jiffies.  Not making a
judgement on whether that is a good or bad reason..

BR,
-R

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

Re: [PATCH] reservation: don't wait when timeout=0

[Chris Wilson]

Quoting Rob Clark (2017-11-21 14:08:46)
> If we are testing if a reservation object's fences have been
> signaled with timeout=0 (non-blocking), we need to pass 0 for
> timeout to dma_fence_wait_timeout().
> 
> Plus bonus spelling correction.
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/dma-buf/reservation.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index dec3a815455d..71f51140a9ad 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
>   *
>   * RETURNS
>   * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
> - * greater than zer on success.
> + * greater than zero on success.
>   */
>  long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
>  bool wait_all, bool intr,
> @@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
> reservation_object *obj,
> goto retry;
> }
>  
> -   ret = dma_fence_wait_timeout(fence, intr, ret);
> +   /*
> +* Note that dma_fence_wait_timeout() will return 1 if
> +* the fence is already signaled, so in the wait_all
> +* case when we go through the retry loop again, ret
> +* will be greater than 0 and we don't want this to
> +* cause _wait_timeout() to block
> +*/
> +   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 0);

One should ask if we should just fix the interface to stop returning
incorrect results (stop "correcting" a completion with 0 jiffies remaining
as 1). A timeout can be distinguished by -ETIME (or your pick of errno).
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] reservation: don't wait when timeout=0

[Christian König]

Am 21.11.2017 um 15:08 schrieb Rob Clark:

If we are testing if a reservation object's fences have been
signaled with timeout=0 (non-blocking), we need to pass 0 for
timeout to dma_fence_wait_timeout().

Plus bonus spelling correction.

Signed-off-by: Rob Clark 


Reviewed-by: Christian König 


---
  drivers/dma-buf/reservation.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a815455d..71f51140a9ad 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
   *
   * RETURNS
   * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
- * greater than zer on success.
+ * greater than zero on success.
   */
  long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
 bool wait_all, bool intr,
@@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
goto retry;
}
  
-		ret = dma_fence_wait_timeout(fence, intr, ret);

+   /*
+* Note that dma_fence_wait_timeout() will return 1 if
+* the fence is already signaled, so in the wait_all
+* case when we go through the retry loop again, ret
+* will be greater than 0 and we don't want this to
+* cause _wait_timeout() to block
+*/
+   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 0);
dma_fence_put(fence);
if (ret > 0 && wait_all && (i + 1 < shared_count))
goto retry;



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

[PATCH] reservation: don't wait when timeout=0

[Rob Clark]

If we are testing if a reservation object's fences have been
signaled with timeout=0 (non-blocking), we need to pass 0 for
timeout to dma_fence_wait_timeout().

Plus bonus spelling correction.

Signed-off-by: Rob Clark 
---
 drivers/dma-buf/reservation.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a815455d..71f51140a9ad 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
  *
  * RETURNS
  * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
- * greater than zer on success.
+ * greater than zero on success.
  */
 long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
 bool wait_all, bool intr,
@@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
goto retry;
}
 
-   ret = dma_fence_wait_timeout(fence, intr, ret);
+   /*
+* Note that dma_fence_wait_timeout() will return 1 if
+* the fence is already signaled, so in the wait_all
+* case when we go through the retry loop again, ret
+* will be greater than 0 and we don't want this to
+* cause _wait_timeout() to block
+*/
+   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 0);
dma_fence_put(fence);
if (ret > 0 && wait_all && (i + 1 < shared_count))
goto retry;
-- 
2.13.6

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

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Christian König]

Hi Boris,

attached are two patches.

The first one is a trivial fix for the infinite loop issue, it now 
correctly aborts the fixup when it can't find address space for the root 
window.


The second is a workaround for your board. It simply checks if there is 
exactly one Processor Function to apply this fix on.


Both are based on linus current master branch. Please test if they fix 
your issue.


Thanks for the help,
Christian.

Am 20.11.2017 um 17:33 schrieb Boris Ostrovsky:

On 11/20/2017 11:07 AM, Christian König wrote:

Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky:

(and then it breaks differently as a Xen guest --- we hung on the last
pci_read_config_dword(), I haven't looked at this at all yet)

Hui? How does this fix applies to a Xen guest in the first place?

Please provide the output of "lspci -nn" and explain further what is
your config with Xen.




This is dom0.

-bash-4.1# lspci -nn
00:00.0 Host bridge [0600]: ATI Technologies Inc RD890 Northbridge only
dual slot (2x16) PCI-e GFX Hydra part [1002:5a10] (rev 02)
00:00.2 Generic system peripheral [0806]: ATI Technologies Inc Device
[1002:5a23]
00:0d.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge
(external gfx1 port B) [1002:5a1e]
00:11.0 SATA controller [0106]: ATI Technologies Inc SB700/SB800 SATA
Controller [AHCI mode] [1002:4391]
00:12.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
OHCI0 Controller [1002:4397]
00:12.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1
Controller [1002:4398]
00:12.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI
Controller [1002:4396]
00:13.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
OHCI0 Controller [1002:4397]
00:13.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1
Controller [1002:4398]
00:13.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI
Controller [1002:4396]
00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller
[1002:4385] (rev 3d)
00:14.3 ISA bridge [0601]: ATI Technologies Inc SB700/SB800 LPC host
controller [1002:439d]
00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge
[1002:4384]
00:14.5 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
OHCI2 Controller [1002:4399]
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1600]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1601]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1602]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1603]
00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1604]
00:18.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1605]
00:19.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1600]
00:19.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1601]
00:19.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1602]
00:19.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1603]
00:19.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1604]
00:19.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1605]
01:04.0 VGA compatible controller [0300]: Matrox Graphics, Inc. MGA
G200eW WPCM450 [102b:0532] (rev 0a)
02:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
Network Connection [8086:10c9] (rev 01)
02:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
Network Connection [8086:10c9] (rev 01)
-bash-4.1#


-boris



>From 9b59f5919b31f1a869ef634481331ef325a992a7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= 
Date: Tue, 21 Nov 2017 11:20:00 +0100
Subject: [PATCH 1/2] x86/PCI: fix infinity loop in search for 64bit BAR
 placement
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Break the loop if we can't find some address space for a 64bit BAR.

Signed-off-by: Christian König 
---
 arch/x86/pci/fixup.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 1e996df687a3..5328e86f73eb 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -696,8 +696,13 @@ static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
 	res->end = 0xfdull - 1;
 
 	/* Just grab the free area behind system memory for this */
-	while ((conflict = request_resource_conflict(_resource, res)))
+	while ((conflict = request_resource_conflict(_resource, res))) {
+		if (conflict->end >= res->end) {
+			kfree(res);
+			return;
+		}
 		res->start = conflict->end + 1;
+	}
 
 	dev_info(>dev, "adding root bus resource %pR\n", res);
 
-- 
2.11.0

>From 2dc4461ba8ec1eb54a49e1e166de9a554556e572 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= 
Date: Tue, 21 Nov 2017 11:08:33 +0100
Subject: [PATCH 2/2] x86/PCI: only enable a 64bit BAR on single socket AMD
 Family 15h 

Re: [PATCH RFC] drm/omap: Make omapdss API more generic, especially the IRQ handling

[Tomi Valkeinen]

Hi,

On 20/11/17 12:10, Jyri Sarha wrote:
> The new omapdss API is HW independent and cleans up some of the
> DSS5 specific hacks from the omapdrm side and get rid off the
> DSS2 IRQ register bits and replace them with HW independent
> struct. This new generic struct makes it more straight forward to
> implement IRQ code for the future DSS versions that do not share
> the same register structure as DSS2 to DSS5 has.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c   | 158 
>  drivers/gpu/drm/omapdrm/dss/dispc.h   |  33 ++
>  drivers/gpu/drm/omapdrm/dss/omapdss.h |  68 ++--
>  drivers/gpu/drm/omapdrm/omap_crtc.c   |  37 +++
>  drivers/gpu/drm/omapdrm/omap_drv.h|   5 +-
>  drivers/gpu/drm/omapdrm/omap_irq.c| 192 
> --
>  drivers/gpu/drm/omapdrm/omap_plane.c  |  18 ++--
>  7 files changed, 346 insertions(+), 165 deletions(-)

You need to split this into smaller pieces. At least the ovl/mgr name,
has_framedone, and irq handling are separate things.

Instead of the struct dss_irq, you can just use a u64 and bitshifting to
achieve the same result, and you don't need those _or _and functions.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm/amdkfd: Do not ignore requested queue size during allocation

[Oded Gabbay]

Thanks Felix for catching that, For some reason I remembered  EOP
buffer should be the same size of the queue.
Then we can remove the queue size parameter from that function ?

On Mon, Nov 20, 2017 at 9:22 PM, Felix Kuehling  wrote:
> I think this patch is not correct. The EOP-mem is not associated with
> the queue size. The EOP buffer is a separate buffer used by the firmware
> to handle command completion. As I understand it, this allows more
> concurrency, while still making it look like all commands in the queue
> are completing in order.
>
> Regards,
>   Felix
>
>
> On 2017-11-19 03:19 AM, Oded Gabbay wrote:
>> On Thu, Nov 16, 2017 at 11:36 PM, Jan Vesely  wrote:
>>> Signed-off-by: Jan Vesely 
>>> ---
>>>  drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c 
>>> b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c
>>> index f1d48281e322..b3bee39661ab 100644
>>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c
>>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c
>>> @@ -37,15 +37,16 @@ static bool initialize_vi(struct kernel_queue *kq, 
>>> struct kfd_dev *dev,
>>> enum kfd_queue_type type, unsigned int queue_size)
>>>  {
>>> int retval;
>>> +   unsigned int size = ALIGN(queue_size, PAGE_SIZE);
>>>
>>> -   retval = kfd_gtt_sa_allocate(dev, PAGE_SIZE, >eop_mem);
>>> +   retval = kfd_gtt_sa_allocate(dev, size, >eop_mem);
>>> if (retval != 0)
>>> return false;
>>>
>>> kq->eop_gpu_addr = kq->eop_mem->gpu_addr;
>>> kq->eop_kernel_addr = kq->eop_mem->cpu_ptr;
>>>
>>> -   memset(kq->eop_kernel_addr, 0, PAGE_SIZE);
>>> +   memset(kq->eop_kernel_addr, 0, size);
>>>
>>> return true;
>>>  }
>>> --
>>> 2.13.6
>>>
>>> ___
>>> amd-gfx mailing list
>>> amd-...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>> Thanks!
>> Applied to -next tree
>> Oded
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

Alex,

Thanks for your fast reply. I have looked in the first bad commit 
e60e1ee60630cafef5e430c2ae364877e061d980 (Merge tag 'drm-for-v4.15') [1].
I have found a lot of kzalloc changes. I am sorry, I don't have any 
experiences with this code. I only know that my Radeon HD6870 doesn't 
have hardware 3D acceleration anymore.


Maybe I could revert the drm_gem_object_init and ttm_bo_init changes but 
the kzalloc changes are too much. I think I need help to solve this issue.


Thanks,
Christian


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e60e1ee60630cafef5e430c2ae364877e061d980



On 21 November 2017 at 05:38AM, Alex Deucher wrote:


If you look at the code, radeon_bo_create() is failing with -ENOMEM in
radeon_wb_init().  If you look at radeon_bo_create(), it can fail for
the following reasons:
1. kzalloc fails
2. drm_gem_object_init fails
3. ttm_bo_init fails

I'd start by looking into what's changed in those areas.

Alex


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



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

[Bug 103107] [CI] igt@gem_ctx_param@invalid-param-[get|set] - Failed assertion: __gem_context_get_param(fd, ) == -22

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103107

--- Comment #6 from Jani Saarinen  ---
Reference: https://patchwork.freedesktop.org/series/33408/

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

Re: [PATCH] omapdrm: hdmi4_cec: fix unsigned int comparison with less than zero

[Tomi Valkeinen]

Hi Colin,

On 17/11/17 20:49, Colin King wrote:
> From: Colin Ian King 
> 
> The two comparisons of the unsigned int ret for -ve error returns is
> always false because ret is unsigned. Fix this by making ret a signed
> int.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c 
> b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> index d86873f2abe6..e626eddf24d5 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> @@ -352,7 +352,7 @@ int hdmi4_cec_init(struct platform_device *pdev, struct 
> hdmi_core_data *core,
>  {
>   const u32 caps = CEC_CAP_TRANSMIT | CEC_CAP_LOG_ADDRS |
>CEC_CAP_PASSTHROUGH | CEC_CAP_RC;
> - unsigned int ret;
> + int ret;
>  
>   core->adap = cec_allocate_adapter(_cec_adap_ops, core,
>   "omap4", caps, CEC_MAX_LOG_ADDRS);
> 

Thanks. There was an earlier patch from Dan Carpenter for this, which I
have applied.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omapdrm: hdmi4_cec: signedness bug in hdmi4_cec_init()

[Tomi Valkeinen]

On 27/10/17 09:27, Dan Carpenter wrote:
> "ret" needs to be signed for the error handling to work.
> 
> Fixes: 8d7f934df8d8 ("omapdrm: hdmi4_cec: add OMAP4 HDMI CEC support")
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c 
> b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> index d86873f2abe6..e626eddf24d5 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> @@ -352,7 +352,7 @@ int hdmi4_cec_init(struct platform_device *pdev, struct 
> hdmi_core_data *core,
>  {
>   const u32 caps = CEC_CAP_TRANSMIT | CEC_CAP_LOG_ADDRS |
>CEC_CAP_PASSTHROUGH | CEC_CAP_RC;
> - unsigned int ret;
> + int ret;
>  
>   core->adap = cec_allocate_adapter(_cec_adap_ops, core,
>   "omap4", caps, CEC_MAX_LOG_ADDRS);
> 

Thanks. I have picked this up.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/4] drm: omapdrm: Fix DPI on platforms using the DSI VDDS

[Tomi Valkeinen]

On 16/11/17 10:50, H. Nikolaus Schaller wrote:
> From: Laurent Pinchart 
> 
> Commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature
> to dpi code") replaced usage of platform data version with SoC matching
> to configure DPI VDDS. The SoC match entries were incorrect, they should
> have matched on the machine name instead of the SoC family. Fix it.
> 
> The result was observed on OpenPandora with OMAP3530 where the panel only
> had the Blue channel and Red were missing. It was not observed on
> GTA04 with DM3730.
> 
> Fixes: d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to 
> dpi code")
> Signed-off-by: Laurent Pinchart 
> Reported-by: H. Nikolaus Schaller 
> Tested-by: H. Nikolaus Schaller 
> ---
>  drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
> b/drivers/gpu/drm/omapdrm/dss/dpi.c
> index 4ed5fde11313..a91e5f1a0490 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -566,8 +566,8 @@ static int dpi_verify_pll(struct dss_pll *pll)
>  }
>  
>  static const struct soc_device_attribute dpi_soc_devices[] = {
> - { .family = "OMAP3[456]*" },
> - { .family = "[AD]M37*" },
> + { .machine = "OMAP3[456]*" },
> + { .machine = "[AD]M37*" },
>   { /* sentinel */ }
>  };
>  
> 

I have picked this one. I think the rest of the patches are more of a
cleanup, right? And you'll be sending v3 at some point.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] omapdrm: hdmi4: Correct the SoC revision matching

[Tomi Valkeinen]

On 20/11/17 11:51, Peter Ujfalusi wrote:
> I believe the intention of the commit 2c9fc9bf45f8
> ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
> was to identify omap4430 ES1.x, omap4430 ES2.x and other OMAP4 revisions,
> like omap4460.
> 
> By using family=OMAP4 in the match the code will treat omap4460 ES1.x in a
> same way as it would treat omap4430 ES1.x
> 
> This breaks HDMI audio on OMAP4460 devices (PandaES for example).
> 
> Correct the match rule so we are not going to get false positive match.
> 
> Fixes: 2c9fc9bf45f8 ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 
> driver")
> 
> CC: sta...@vger.kernel.org # 4.14
> Signed-off-by: Peter Ujfalusi 

Thanks, I have picked this up.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] drm/ttm: free one in huge pool even shrink request less than one element

[Roger He]

Change-Id: Id8bd4d1ecff9f3ab14355e2dbd1c59b9fe824e01
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 90546fd..c194a51 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -453,11 +453,13 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
/* OK to use static buffer since global mutex is held. */
nr_free_pool = (nr_free >> pool->order);
-   if (nr_free_pool == 0)
-   continue;
+   if (!nr_free_pool && pool->order)
+   nr_free_pool = 1;
 
shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
freed += ((nr_free_pool - shrink_pages) << pool->order);
+   if (freed > sc->nr_to_scan)
+   break;
}
mutex_unlock();
return freed;
-- 
2.7.4

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

Re: [PATCH 1/4] drm/ttm: add page order in page pool

[Christian König]

Am 21.11.2017 um 10:32 schrieb Roger He:

to indicate page order for each element in the pool

Change-Id: Ic609925ca5d2a5d4ad49d6becf505388ce3624cf
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 33 ++---
  1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 316f831..2b83c52 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -81,6 +81,7 @@ struct ttm_page_pool {
char*name;
unsigned long   nfrees;
unsigned long   nrefills;
+   unsigned intorder;
  };
  
  /**

@@ -412,6 +413,7 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
struct ttm_page_pool *pool;
int shrink_pages = sc->nr_to_scan;
unsigned long freed = 0;
+   unsigned int nr_free_pool;
  
  	if (!mutex_trylock())

return SHRINK_STOP;
@@ -421,10 +423,15 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
unsigned nr_free = shrink_pages;
if (shrink_pages == 0)
break;
+
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
/* OK to use static buffer since global mutex is held. */
-   shrink_pages = ttm_page_pool_free(pool, nr_free, true);
-   freed += nr_free - shrink_pages;
+   nr_free_pool = (nr_free >> pool->order);
+   if (nr_free_pool == 0)
+   continue;
+
+   shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
+   freed += ((nr_free_pool - shrink_pages) << pool->order);
}
mutex_unlock();
return freed;
@@ -436,9 +443,12 @@ ttm_pool_shrink_count(struct shrinker *shrink, struct 
shrink_control *sc)
  {
unsigned i;
unsigned long count = 0;
+   struct ttm_page_pool *pool;
  
-	for (i = 0; i < NUM_POOLS; ++i)

-   count += _manager->pools[i].npages;
+   for (i = 0; i < NUM_POOLS; ++i) {
+   pool = &_manager->pools[i];
+   count += (pool->npages << pool->order);
+   }
  
  	return count;

  }
@@ -933,7 +943,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
  }
  
  static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, gfp_t flags,

-   char *name)
+   char *name, unsigned int order)
  {
spin_lock_init(>lock);
pool->fill_lock = false;
@@ -941,6 +951,7 @@ static void ttm_page_pool_init_locked(struct ttm_page_pool 
*pool, gfp_t flags,
pool->npages = pool->nfrees = 0;
pool->gfp_flags = flags;
pool->name = name;
+   pool->order = order;
  }
  
  int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)

@@ -953,23 +964,23 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
  
  	_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
  
-	ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");

+   ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
  
-	ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc");

+   ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc", 0);
  
  	ttm_page_pool_init_locked(&_manager->wc_pool_dma32,

- GFP_USER | GFP_DMA32, "wc dma");
+ GFP_USER | GFP_DMA32, "wc dma", 0);
  
  	ttm_page_pool_init_locked(&_manager->uc_pool_dma32,

- GFP_USER | GFP_DMA32, "uc dma");
+ GFP_USER | GFP_DMA32, "uc dma", 0);
  
  	ttm_page_pool_init_locked(&_manager->wc_pool_huge,

  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP),
- "wc huge");
+ "wc huge", HPAGE_PMD_ORDER);
  
  	ttm_page_pool_init_locked(&_manager->uc_pool_huge,

  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP)
- , "uc huge");
+ , "uc huge", HPAGE_PMD_ORDER);


HPAGE_PMD_ORDER isn't defined when huge page support isn't enabled.

That's why I avoided using this here.

Christian.

  
  	_manager->options.max_size = max_pages;

_manager->options.small = SMALL_ALLOCATION;



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

Re: [PATCH 3/4] drm/ttm: add page order support in ttm_pages_put

[Christian König]

Am 21.11.2017 um 10:32 schrieb Roger He:

Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 42 +---
  1 file changed, 34 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 27b2402..90546fd 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -285,13 +285,39 @@ static struct ttm_page_pool *ttm_get_pool(int flags, bool 
huge,
  }
  
  /* set memory back to wb and free the pages. */

-static void ttm_pages_put(struct page *pages[], unsigned npages)
+static void ttm_pages_put(struct page *pages[], unsigned npages,
+   unsigned int order)
  {
-   unsigned i;
-   if (set_pages_array_wb(pages, npages))
-   pr_err("Failed to set %d pages to wb!\n", npages);
-   for (i = 0; i < npages; ++i)
-   __free_page(pages[i]);
+   struct page **pages_to_free = NULL;
+   struct page **pages_array = NULL;
+   struct page *p = NULL;
+   unsigned int i, j, pages_nr = 1 << order;
+
+   if (order > 0) {
+   pages_to_free = kmalloc_array(pages_nr, sizeof(struct page *),
+   GFP_KERNEL);


We can't call kmalloc here, when this function is called by the shrinker 
we are tight on memory anyway.


That's also the reason we have this static buffer dance in 
ttm_page_pool_free() as well.


Christian.


+   if (!pages_to_free) {
+   pr_err("Failed to allocate memory for ttm pages put 
operation\n");
+   return;
+   }
+   }
+
+   for (i = 0; i < npages; ++i) {
+   if (order) {
+   p = pages[i];
+   for (j = 0; j < pages_nr; ++j)
+   pages_to_free[j] = p++;
+
+   pages_array = pages_to_free;
+   } else
+   pages_array = pages;
+
+   if (set_pages_array_wb(pages_array, pages_nr))
+   pr_err("Failed to set %d pages to wb!\n", pages_nr);
+   __free_pages(pages[i], order);
+   }
+
+   kfree(pages_to_free);
  }
  
  static void ttm_pool_update_free_locked(struct ttm_page_pool *pool,

@@ -354,7 +380,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
 */
spin_unlock_irqrestore(>lock, irq_flags);
  
-			ttm_pages_put(pages_to_free, freed_pages);

+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
if (likely(nr_free != FREE_ALL_PAGES))
nr_free -= freed_pages;
  
@@ -389,7 +415,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free,

spin_unlock_irqrestore(>lock, irq_flags);
  
  	if (freed_pages)

-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
  out:
if (pages_to_free != static_buf)
kfree(pages_to_free);



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

Re: [PATCH 2/4] drm/ttm: use NUM_PAGES_TO_ALLOC always

[Christian König]

Am 21.11.2017 um 10:32 schrieb Roger He:

Change-Id: Ide96a1ccad9bb44b0bb0d80e123c2d810ba618ed
Signed-off-by: Roger He 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 2b83c52..27b2402 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -520,8 +520,7 @@ static int ttm_alloc_new_pages(struct list_head *pages, 
gfp_t gfp_flags,
int r = 0;
unsigned i, j, cpages;
unsigned npages = 1 << order;
-   unsigned max_cpages = min(count,
-   (unsigned)(PAGE_SIZE/sizeof(struct page *)));
+   unsigned max_cpages = min(count, (unsigned)NUM_PAGES_TO_ALLOC);
  
  	/* allocate array for page caching change */

caching_array = kmalloc(max_cpages*sizeof(struct page *), GFP_KERNEL);



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

[PATCH 3/4] drm/ttm: add page order support in ttm_pages_put

[Roger He]

Change-Id: Ia55b206d95812c5afcfd6cec29f580758d1f50f0
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 42 +---
 1 file changed, 34 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 27b2402..90546fd 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -285,13 +285,39 @@ static struct ttm_page_pool *ttm_get_pool(int flags, bool 
huge,
 }
 
 /* set memory back to wb and free the pages. */
-static void ttm_pages_put(struct page *pages[], unsigned npages)
+static void ttm_pages_put(struct page *pages[], unsigned npages,
+   unsigned int order)
 {
-   unsigned i;
-   if (set_pages_array_wb(pages, npages))
-   pr_err("Failed to set %d pages to wb!\n", npages);
-   for (i = 0; i < npages; ++i)
-   __free_page(pages[i]);
+   struct page **pages_to_free = NULL;
+   struct page **pages_array = NULL;
+   struct page *p = NULL;
+   unsigned int i, j, pages_nr = 1 << order;
+
+   if (order > 0) {
+   pages_to_free = kmalloc_array(pages_nr, sizeof(struct page *),
+   GFP_KERNEL);
+   if (!pages_to_free) {
+   pr_err("Failed to allocate memory for ttm pages put 
operation\n");
+   return;
+   }
+   }
+
+   for (i = 0; i < npages; ++i) {
+   if (order) {
+   p = pages[i];
+   for (j = 0; j < pages_nr; ++j)
+   pages_to_free[j] = p++;
+
+   pages_array = pages_to_free;
+   } else
+   pages_array = pages;
+
+   if (set_pages_array_wb(pages_array, pages_nr))
+   pr_err("Failed to set %d pages to wb!\n", pages_nr);
+   __free_pages(pages[i], order);
+   }
+
+   kfree(pages_to_free);
 }
 
 static void ttm_pool_update_free_locked(struct ttm_page_pool *pool,
@@ -354,7 +380,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
 */
spin_unlock_irqrestore(>lock, irq_flags);
 
-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
if (likely(nr_free != FREE_ALL_PAGES))
nr_free -= freed_pages;
 
@@ -389,7 +415,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
unsigned nr_free,
spin_unlock_irqrestore(>lock, irq_flags);
 
if (freed_pages)
-   ttm_pages_put(pages_to_free, freed_pages);
+   ttm_pages_put(pages_to_free, freed_pages, pool->order);
 out:
if (pages_to_free != static_buf)
kfree(pages_to_free);
-- 
2.7.4

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

[PATCH 2/4] drm/ttm: use NUM_PAGES_TO_ALLOC always

[Roger He]

Change-Id: Ide96a1ccad9bb44b0bb0d80e123c2d810ba618ed
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 2b83c52..27b2402 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -520,8 +520,7 @@ static int ttm_alloc_new_pages(struct list_head *pages, 
gfp_t gfp_flags,
int r = 0;
unsigned i, j, cpages;
unsigned npages = 1 << order;
-   unsigned max_cpages = min(count,
-   (unsigned)(PAGE_SIZE/sizeof(struct page *)));
+   unsigned max_cpages = min(count, (unsigned)NUM_PAGES_TO_ALLOC);
 
/* allocate array for page caching change */
caching_array = kmalloc(max_cpages*sizeof(struct page *), GFP_KERNEL);
-- 
2.7.4

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

[PATCH 1/4] drm/ttm: add page order in page pool

[Roger He]

to indicate page order for each element in the pool

Change-Id: Ic609925ca5d2a5d4ad49d6becf505388ce3624cf
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 33 ++---
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 316f831..2b83c52 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -81,6 +81,7 @@ struct ttm_page_pool {
char*name;
unsigned long   nfrees;
unsigned long   nrefills;
+   unsigned intorder;
 };
 
 /**
@@ -412,6 +413,7 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
struct ttm_page_pool *pool;
int shrink_pages = sc->nr_to_scan;
unsigned long freed = 0;
+   unsigned int nr_free_pool;
 
if (!mutex_trylock())
return SHRINK_STOP;
@@ -421,10 +423,15 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
unsigned nr_free = shrink_pages;
if (shrink_pages == 0)
break;
+
pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
/* OK to use static buffer since global mutex is held. */
-   shrink_pages = ttm_page_pool_free(pool, nr_free, true);
-   freed += nr_free - shrink_pages;
+   nr_free_pool = (nr_free >> pool->order);
+   if (nr_free_pool == 0)
+   continue;
+
+   shrink_pages = ttm_page_pool_free(pool, nr_free_pool, true);
+   freed += ((nr_free_pool - shrink_pages) << pool->order);
}
mutex_unlock();
return freed;
@@ -436,9 +443,12 @@ ttm_pool_shrink_count(struct shrinker *shrink, struct 
shrink_control *sc)
 {
unsigned i;
unsigned long count = 0;
+   struct ttm_page_pool *pool;
 
-   for (i = 0; i < NUM_POOLS; ++i)
-   count += _manager->pools[i].npages;
+   for (i = 0; i < NUM_POOLS; ++i) {
+   pool = &_manager->pools[i];
+   count += (pool->npages << pool->order);
+   }
 
return count;
 }
@@ -933,7 +943,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
 }
 
 static void ttm_page_pool_init_locked(struct ttm_page_pool *pool, gfp_t flags,
-   char *name)
+   char *name, unsigned int order)
 {
spin_lock_init(>lock);
pool->fill_lock = false;
@@ -941,6 +951,7 @@ static void ttm_page_pool_init_locked(struct ttm_page_pool 
*pool, gfp_t flags,
pool->npages = pool->nfrees = 0;
pool->gfp_flags = flags;
pool->name = name;
+   pool->order = order;
 }
 
 int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
@@ -953,23 +964,23 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
 
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
 
-   ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");
+   ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc", 0);
 
-   ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc");
+   ttm_page_pool_init_locked(&_manager->uc_pool, GFP_HIGHUSER, "uc", 0);
 
ttm_page_pool_init_locked(&_manager->wc_pool_dma32,
- GFP_USER | GFP_DMA32, "wc dma");
+ GFP_USER | GFP_DMA32, "wc dma", 0);
 
ttm_page_pool_init_locked(&_manager->uc_pool_dma32,
- GFP_USER | GFP_DMA32, "uc dma");
+ GFP_USER | GFP_DMA32, "uc dma", 0);
 
ttm_page_pool_init_locked(&_manager->wc_pool_huge,
  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP),
- "wc huge");
+ "wc huge", HPAGE_PMD_ORDER);
 
ttm_page_pool_init_locked(&_manager->uc_pool_huge,
  GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP)
- , "uc huge");
+ , "uc huge", HPAGE_PMD_ORDER);
 
_manager->options.max_size = max_pages;
_manager->options.small = SMALL_ALLOCATION;
-- 
2.7.4

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

[PATCH 0/4] *** fix memory leak for HUGE PAGE ***

[Roger He]

1. add page order into pool to support gtt huge page
2. add page order support when ttm pages put
3. update memory shrinker with order handling


Roger He (4):
  drm/ttm: add page order in page pool
  drm/ttm: use NUM_PAGES_TO_ALLOC always
  drm/ttm: add page order support in ttm_pages_put
  drm/ttm: free one in huge pool even shrink request less than one
element

 drivers/gpu/drm/ttm/ttm_page_alloc.c | 80 ++--
 1 file changed, 59 insertions(+), 21 deletions(-)

-- 
2.7.4

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

[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103370

--- Comment #37 from Robert Liu  ---
(In reply to Robert Liu from comment #36)
> BTW, with 4.13.0-16-generic, I change the max_sclk in drm/radeon/si_dpm.c
> (what we did with Ubuntu kernel 4.4.0-101-generic) from 75000 to 65000, but
> still met the hang issue.
By restricting max_sclk to 65000 and max_mclk to 8, both radeon and amdgpu
do not have the issue.

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

Re: [PATCH] drm/sti: Handle return value of platform_get_irq_byname

[Benjamin Gaignard]

2017-11-17 11:36 GMT+01:00 Arvind Yadav :
> platform_get_irq_byname() can fail here and we must check its return
> value.
>

Applied on drm-misc-next.

Thanks,
Benjamin

> Signed-off-by: Arvind Yadav 
> ---
>  drivers/gpu/drm/sti/sti_hdmi.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> index 30f02d2..adabd41 100644
> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> @@ -1414,6 +1414,11 @@ static int sti_hdmi_probe(struct platform_device *pdev)
> init_waitqueue_head(>wait_event);
>
> hdmi->irq = platform_get_irq_byname(pdev, "irq");
> +   if (hdmi->irq < 0) {
> +   DRM_ERROR("Cannot get HDMI irq\n");
> +   ret = hdmi->irq;
> +   goto release_adapter;
> +   }
>
> ret = devm_request_threaded_irq(dev, hdmi->irq, hdmi_irq,
> hdmi_irq_thread, IRQF_ONESHOT, dev_name(dev), hdmi);
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

[Daniel Vetter]

On Tue, Nov 21, 2017 at 07:39:51AM +1000, Dave Airlie wrote:
> On 20 November 2017 at 23:13, Daniel Vetter  wrote:
> > On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> >> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
> >> > Hi all,
> >> >
> >> > Since I'm going slightly off-topic, I've tweaked the subject line and
> >> > trimmed some of the conversation.
> >> > I believe everyone in the CC list might be interested in the
> >> > following, yet feel free to adjust.
> >> >
> >> > Above all, I'd kindly ask everyone to skim through and draw their 
> >> > conclusions.
> >> > If the ideas put forward have some value - great, if not - let my email 
> >> > rot.
> >> >
> >> > On 17 November 2017 at 13:57, Greg KH  wrote:
> >> >
> >> > >>
> >> > >> I still have no idea how this autoselect picks up patches that do 
> >> > >> *not*
> >> > >> have cc: stable nor Fixes: from us. What information do you have that 
> >> > >> we
> >> > >> don't for making that call?
> >> > >
> >> > > I'll let Sasha describe how he's doing this, but in the end, does it
> >> > > really matter _how_ it is done, vs. the fact that it seems to at least
> >> > > one human reviewer that this is a patch that _should_ be included based
> >> > > on the changelog text and the code patch?
> >> > >
> >> > > By having this review process that Sasha is providing, he's saying
> >> > > "Here's a patch that I think might be good for stable, do you object?"
> >> > >
> >> > > If you do, great, no harm done, all is fine, the patch is dropped.  If
> >> > > you don't object, just ignore the email and the patch gets merged.
> >> > >
> >> > > If you don't want any of this to happen for your subsystem at all, then
> >> > > also fine, just let us know and we will ignore it entirely.
> >> > >
> >> > Let me start with saying that I'm handling the releases for Mesa 3D -
> >> > the project providing OpenGL, Vulkan and many other userspace graphics
> >> > drivers.
> >> > I've been doing that for 3 years now, which admittedly is quite a
> >> > short time relative to the kernel.
> >> >
> >> > There is a procedure quite similar to the kernel, with a few
> >> > differences - see below for details.
> >> > We also autoselect patches, hence my interest in the heuristics
> >> > applied for nominating patches ;-)
> >> >
> >> > That aside, here are some things I've learned from my experience.
> >> > Some of those may not be applicable - hope you'll find them useful:
> >> >
> >> >  - Try to reference developers to existing documentation/procedure.
> >> > Was just reminded that even long standing developers can forget detail X 
> >> > or Y.
> >> >
> >> >  - CC developers for the important stuff - aka do not CC on each 
> >> > accepted patch.
> >> > Accepted patches are merged in pre-release branch and a email with
> >> > accepted/deferred/rejected list is sent.
> >> > Patches that had conflicts merging, and ones that are rejected have
> >> > their author in the CC list.
> >> > Rejected patches have brief description + developers are contacted 
> >> > beforehand.
> >> >
> >> >  - Autoselect patches are merged only with the approval from the
> >> > respective developers.
> >> > IMHO this engages developers into the process, without distracting
> >> > them too much.
> >>
> >> Getting explicit confirmation for autoselected patches sounds like a very
> >> good idea to me. We intentionally limit the amount of patches we cc:
> >> stable, because we simply don't have the manpower around to support stable
> >> fully (i.e. with proper CI and everything). And less backported patches
> >> means fewer regressions, which is more important than fixing someone
> >> else's bug.
> >>
> >> Of course our CI is open, so if someone is supremely bored and wants to
> >> backport more stuff for drm/i915, they could do that. But atm it doesn't
> >> happen, and then having to deal with the fallout is not really great (like
> >> I said, we don't really have anyone dedicated, and I much prefer we
> >> fix/improve upstream).
> >>
> >> For the actual products we're shipping we have dedicated teams doing the
> >> backports. The upstream stable releases essentially have no value for us
> >> from a customer support pov (for drivers, I guess core stuff is an
> >> entirely different matter), there's not a single serious customer or
> >> bigger user using that. It only costs, by spamming us with mails and bug
> >> reports for stuff we didn't even nominate :-)
> >>
> >> Just my 2 cents here, but I think this perpespective matches with other
> >> big drm drivers like amdgpu (I just discussed this exact topic of how
> >> upstream stable is useless with Alex).
> >
> > Just to clarify, this includes non-(directly-)paying customers like 
> > community
> > distros: Either they track the quarterly releases (of both the kernel and
> > userspace) because they care about the latest gpu driver work. Or they
> > want LTS and stability uber alles, and in 

Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

[Daniel Vetter]

On Tue, Nov 21, 2017 at 08:58:51AM +0100, Greg KH wrote:
> On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> > Of course our CI is open, so if someone is supremely bored and wants to
> > backport more stuff for drm/i915, they could do that. But atm it doesn't
> > happen, and then having to deal with the fallout is not really great (like
> > I said, we don't really have anyone dedicated, and I much prefer we
> > fix/improve upstream).
> 
> Any reason you can't add the stable -rc tree to your CI system?

The problem is looking at results and making sure nothing breaks and
sending mails out that patches shouldn't be applied and all that. Keeping
the machines busy is the easy part.

For Linus' -rc/-fixes we do that (including human review of all the stuff
the scripts suggests we need to cherry-pick as fixes), but that's because
we have someone.

Maybe we can/should look into doing the same for the current stable (to
support fedora and other community distros a bit better). But I think
there's no way we can support all the LTS kernels out there and more than
just minimal backports.

> > For the actual products we're shipping we have dedicated teams doing the
> > backports. The upstream stable releases essentially have no value for us
> > from a customer support pov (for drivers, I guess core stuff is an
> > entirely different matter), there's not a single serious customer or
> > bigger user using that. It only costs, by spamming us with mails and bug
> > reports for stuff we didn't even nominate :-)
> 
> Any reason why you aren't sending those backported patches to the stable
> trees so that users of them can benefit from the work you are already
> doing for a limited number of "customers"?

They fail your backporting criteria. Big time, like veeery big time.

Think backporting 1k patches to get some feature. Which then means it's a
frankenkernel without any relation to any shipping stable drm/i915
release, so the backports of the bugfixes are again meaningless and
untested for anything else.

Tbh the easies for us to support is what rhel does for their updates,
which is just copy all of drivers/gpu/ into their old lts kernel and then
fix things up at the seams.

> And if your customers are not using stable kernel releases, what are
> they using for their kernels?

LTS, but with a frankenstein drm/i915. To clarify, all I'm discussing here
is just drm and drm/i915 patches, I think for core code the stable process
works reasonably well (afaiui at least).

> It sounds like you don't want to deal with the "automated" patches for
> the i915 drivers, so that's fine, we will blacklist them and ignore
> them and only deal with the patches you explicitly ask to be backported.
> As it seems like those are hard enough for you all to deal with, given
> the recent regression :)

Yeah that would at least not make it worse.

On the entire problem (that we share with amd folks, see Alex' reply) of
how to ship gpu kernel driver updates to people who care, but don't want
to track latest upstream releases, I'd love to have a solution. I just
don't see one (except tons of manual backport work).

Fundamentally the problem is that the product freeze cycle for core kernel
code (measured in years often) is just plain unsuitable for gfx drivers
(where in userspace we often end up shipping well-tested points from
master because the quarterly releases are too slow).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] lib/rbtree,drm/mm: Add rbtree_replace_node_cached()

[Joonas Lahtinen]

On Fri, 2017-11-10 at 06:26 -0800, Davidlohr Bueso wrote:
> On 2017-11-09 13:24, Chris Wilson wrote:
> > Add a variant of rbtree_replace_node() that maintains the leftmost
> > cached of struct rbtree_root_cached when replacing nodes within the
> > rbtree.
> > 
> > As drm_mm is the only rb_replace_node() being used on an interval tree,
> > the mistake looks fairly self-contained. Furthermore the only user of
> > drm_mm_replace_node() is its testsuite...
> > 
> > Fixes: f808c13fd373 ("lib/interval_tree: fast overlap detection")
> > Testcase: igt/drm_mm/replace
> > Signed-off-by: Chris Wilson 
> > Cc: Davidlohr Bueso 
> > Cc: Jérôme Glisse 
> > Cc: Andrew Morton 
> > Cc: Joonas Lahtinen 
> > Cc: Daniel Vetter 
> 
> Thanks!
> 
> Acked-by: Davidlohr Bueso 

Would you like us to merge this patch through the DRM tree or how would
you like us to proceed?

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 4.9.62: intermittent flicker after upgrade from 4.9.61

[Rainer Fiebig]

Maarten Lankhorst wrote:
> Op 20-11-17 om 09:51 schreef Rainer Fiebig:
>> Jani Nikula wrote:
>>> On Sun, 19 Nov 2017, Greg KH  wrote:
 On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote:
> Greg KH wrote:
>> On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
>>> Greg KH wrote:
 On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
> Greg KH wrote:
>> On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote:
>>> Hi!
>>>
>>> Hopefully the right addressee.
>>>
>>> Encountered two bad backports which cause screen-flicker.
>>> dmesg shows:
>>>
>>> ...
>>> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
>>> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO 
>>> underrun
>>> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
>>> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO 
>>> underrun
>>> ...
>>>
>>> CPU: Intel Core i3 (Clarkdale/Ironlake)
>>>
>>> The backports are:
>>>
>>> - diff --git a/drivers/gpu/drm/i915/intel_pm.c
>>> b/drivers/gpu/drm/i915/intel_pm.c
>>> index 49de476..277a802 100644
>>> - diff --git a/drivers/gpu/drm/i915/intel_drv.h
>>> b/drivers/gpu/drm/i915/intel_drv.h
>>> index a19ec06..3ce9ba3 100644
>>>
>>> After reversing them the flicker is gone, no more messages in 
>>> dmesg. All
>>> else OK so far.
>> So which commit was the one that caused the problem?  I will be glad 
>> to
>> revert it.
>>
>> thanks,
>>
>> greg k-h
>>
>>
> I started by reverting the more complex one first ("index
> 49de476..277a802100644"). But the kernel wouldn't compile then.
 What git commit id is that?  I don't see those ids in the 4.9-stable
 tree.

> So I also reverted "index a19ec06..3ce9ba3 100644". After that the
> kernel compiled just fine and the problems were gone (still are).
 Same here, what git commit id was this?

 thanks,

 greg k-h

>>> OK, no mistake. IIRC, I took the patches (and the IDs) from the
>>> changelog for patch-4.9.62. I've attached both, so you can check 
>>> yourself.
>>>
>>> I've also applied a freshly downloaded patch-4.9.62 to a freshly
>>> expanded 4.9 and re-compiled. The flicker is there. I haven't yet
>>> reverted the two patches but I'm confident that after having done so the
>>> flicker will be gone. If not I'll let you know.
>>>
>>> As a good news: 4.14 is *not* affected. So to me it seems those two
>>> patches are part of sort of a package and can not be backported alone.
>>>
>>> So long!
>>> Rainer Fiebig
>>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>>> b/drivers/gpu/drm/i915/intel_pm.c
>>> index 49de476..277a802 100644
>>> --- a/drivers/gpu/drm/i915/intel_pm.c
>>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>>> @@ -27,6 +27,7 @@
>>>  
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include "i915_drv.h"
>>>  #include "intel_drv.h"
>>>  #include "../../../platform/x86/intel_ips.h"
>>> @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct 
>>> drm_i915_private *dev_priv,
>>>  const struct intel_crtc *intel_crtc,
>>>  int level,
>>>  struct intel_crtc_state *cstate,
>>> -struct intel_plane_state *pristate,
>>> -struct intel_plane_state *sprstate,
>>> -struct intel_plane_state *curstate,
>>> +const struct intel_plane_state 
>>> *pristate,
>>> +const struct intel_plane_state 
>>> *sprstate,
>>> +const struct intel_plane_state 
>>> *curstate,
>>>  struct intel_wm_level *result)
>>>  {
>>> uint16_t pri_latency = dev_priv->wm.pri_latency[level];
>>> @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct 
>>> intel_crtc_state *cstate)
>>> struct intel_pipe_wm *pipe_wm;
>>> struct drm_device *dev = state->dev;
>>> const struct drm_i915_private *dev_priv = to_i915(dev);
>>> -   struct intel_plane *intel_plane;
>>> -   struct intel_plane_state *pristate = NULL;
>>> -   struct intel_plane_state *sprstate = NULL;
>>> -   struct intel_plane_state *curstate = NULL;
>>> +   struct drm_plane *plane;
>>> + 

Re: 4.9.62: intermittent flicker after upgrade from 4.9.61

[Rainer Fiebig]

Maarten Lankhorst wrote:
> Op 20-11-17 om 09:51 schreef Rainer Fiebig:
>> Jani Nikula wrote:
>>> On Sun, 19 Nov 2017, Greg KH  wrote:
 On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote:
> Greg KH wrote:
>> On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
>>> Greg KH wrote:
 On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
> Greg KH wrote:
>> On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote:
>>> Hi!
>>>
>>> Hopefully the right addressee.
>>>
>>> Encountered two bad backports which cause screen-flicker.
>>> dmesg shows:
>>>
>>> ...
>>> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
>>> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO 
>>> underrun
>>> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
>>> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO 
>>> underrun
>>> ...
>>>
>>> CPU: Intel Core i3 (Clarkdale/Ironlake)
>>>
>>> The backports are:
>>>
>>> - diff --git a/drivers/gpu/drm/i915/intel_pm.c
>>> b/drivers/gpu/drm/i915/intel_pm.c
>>> index 49de476..277a802 100644
>>> - diff --git a/drivers/gpu/drm/i915/intel_drv.h
>>> b/drivers/gpu/drm/i915/intel_drv.h
>>> index a19ec06..3ce9ba3 100644
>>>
>>> After reversing them the flicker is gone, no more messages in 
>>> dmesg. All
>>> else OK so far.
>> So which commit was the one that caused the problem?  I will be glad 
>> to
>> revert it.
>>
>> thanks,
>>
>> greg k-h
>>
>>
> I started by reverting the more complex one first ("index
> 49de476..277a802100644"). But the kernel wouldn't compile then.
 What git commit id is that?  I don't see those ids in the 4.9-stable
 tree.

> So I also reverted "index a19ec06..3ce9ba3 100644". After that the
> kernel compiled just fine and the problems were gone (still are).
 Same here, what git commit id was this?

 thanks,

 greg k-h

>>> OK, no mistake. IIRC, I took the patches (and the IDs) from the
>>> changelog for patch-4.9.62. I've attached both, so you can check 
>>> yourself.
>>>
>>> I've also applied a freshly downloaded patch-4.9.62 to a freshly
>>> expanded 4.9 and re-compiled. The flicker is there. I haven't yet
>>> reverted the two patches but I'm confident that after having done so the
>>> flicker will be gone. If not I'll let you know.
>>>
>>> As a good news: 4.14 is *not* affected. So to me it seems those two
>>> patches are part of sort of a package and can not be backported alone.
>>>
>>> So long!
>>> Rainer Fiebig
>>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>>> b/drivers/gpu/drm/i915/intel_pm.c
>>> index 49de476..277a802 100644
>>> --- a/drivers/gpu/drm/i915/intel_pm.c
>>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>>> @@ -27,6 +27,7 @@
>>>  
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include "i915_drv.h"
>>>  #include "intel_drv.h"
>>>  #include "../../../platform/x86/intel_ips.h"
>>> @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct 
>>> drm_i915_private *dev_priv,
>>>  const struct intel_crtc *intel_crtc,
>>>  int level,
>>>  struct intel_crtc_state *cstate,
>>> -struct intel_plane_state *pristate,
>>> -struct intel_plane_state *sprstate,
>>> -struct intel_plane_state *curstate,
>>> +const struct intel_plane_state 
>>> *pristate,
>>> +const struct intel_plane_state 
>>> *sprstate,
>>> +const struct intel_plane_state 
>>> *curstate,
>>>  struct intel_wm_level *result)
>>>  {
>>> uint16_t pri_latency = dev_priv->wm.pri_latency[level];
>>> @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct 
>>> intel_crtc_state *cstate)
>>> struct intel_pipe_wm *pipe_wm;
>>> struct drm_device *dev = state->dev;
>>> const struct drm_i915_private *dev_priv = to_i915(dev);
>>> -   struct intel_plane *intel_plane;
>>> -   struct intel_plane_state *pristate = NULL;
>>> -   struct intel_plane_state *sprstate = NULL;
>>> -   struct intel_plane_state *curstate = NULL;
>>> +   struct drm_plane *plane;
>>> + 

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Boris Ostrovsky]

On 11/20/2017 11:07 AM, Christian König wrote:
> Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky:
>>
>> (and then it breaks differently as a Xen guest --- we hung on the last
>> pci_read_config_dword(), I haven't looked at this at all yet)
>
> Hui? How does this fix applies to a Xen guest in the first place?
>
> Please provide the output of "lspci -nn" and explain further what is
> your config with Xen.
>
>


This is dom0.

-bash-4.1# lspci -nn
00:00.0 Host bridge [0600]: ATI Technologies Inc RD890 Northbridge only
dual slot (2x16) PCI-e GFX Hydra part [1002:5a10] (rev 02)
00:00.2 Generic system peripheral [0806]: ATI Technologies Inc Device
[1002:5a23]
00:0d.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge
(external gfx1 port B) [1002:5a1e]
00:11.0 SATA controller [0106]: ATI Technologies Inc SB700/SB800 SATA
Controller [AHCI mode] [1002:4391]
00:12.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
OHCI0 Controller [1002:4397]
00:12.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1
Controller [1002:4398]
00:12.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI
Controller [1002:4396]
00:13.0 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
OHCI0 Controller [1002:4397]
00:13.1 USB Controller [0c03]: ATI Technologies Inc SB700 USB OHCI1
Controller [1002:4398]
00:13.2 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI
Controller [1002:4396]
00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller
[1002:4385] (rev 3d)
00:14.3 ISA bridge [0601]: ATI Technologies Inc SB700/SB800 LPC host
controller [1002:439d]
00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge
[1002:4384]
00:14.5 USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB
OHCI2 Controller [1002:4399]
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1600]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1601]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1602]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1603]
00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1604]
00:18.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1605]
00:19.0 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1600]
00:19.1 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1601]
00:19.2 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1602]
00:19.3 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1603]
00:19.4 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1604]
00:19.5 Host bridge [0600]: Advanced Micro Devices [AMD] Device [1022:1605]
01:04.0 VGA compatible controller [0300]: Matrox Graphics, Inc. MGA
G200eW WPCM450 [102b:0532] (rev 0a)
02:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
Network Connection [8086:10c9] (rev 01)
02:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
Network Connection [8086:10c9] (rev 01)
-bash-4.1#


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

Re: [PATCH v2 3/4] backlight: tps65217_bl: fix device-tree node lookup

[Johan Hovold]

On Mon, Nov 20, 2017 at 11:34:07AM +, Daniel Thompson wrote:
> 
> 
> On 20/11/17 10:45, Johan Hovold wrote:
> > Fix child-node lookup during probe, which ended up searching the whole
> > device tree depth-first starting at the parent rather than just matching
> > on its children.
> > 
> > This would only cause trouble if the child node is missing while there
> > is an unrelated node named "backlight" elsewhere in the tree.
> > 
> > Fixes: eebfdc17cc6c ("backlight: Add TPS65217 WLED driver")
> > Cc: stable  # 3.7
> > Cc: Matthias Kaehlcke 
> > Signed-off-by: Johan Hovold 
> 
> Didn't I already ack this one?

Indeed you did (same with the previous one). Sorry about forgetting to
add them to v2.

> Acked-by: Daniel Thompson 

Thanks for the acks.

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

[PATCH v2 4/4] backlight: as3711_bl: fix device-tree node leaks

[Johan Hovold]

Two framebuffer device-node names were looked up during probe, but were
only used as flags to indicate the presence of two framebuffer device.

Drop the unused framebuffer name along with a likewise unused device
pointer from the driver data, and update the platform data to pass in
booleans instead of the framebuffer strings. This allows us do drop the
node references acquired during probe, which would otherwise leak.

Note that there are no other in-kernel users of the modified
platform-data fields.

Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support")
Cc: Guennadi Liakhovetski 
Signed-off-by: Johan Hovold 
---
 drivers/video/backlight/as3711_bl.c | 12 ++--
 include/linux/mfd/as3711.h  |  4 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/video/backlight/as3711_bl.c 
b/drivers/video/backlight/as3711_bl.c
index e55304d5cf07..ca544aa764b8 100644
--- a/drivers/video/backlight/as3711_bl.c
+++ b/drivers/video/backlight/as3711_bl.c
@@ -28,8 +28,6 @@ enum as3711_bl_type {
 
 struct as3711_bl_data {
bool powered;
-   const char *fb_name;
-   struct device *fb_dev;
enum as3711_bl_type type;
int brightness;
struct backlight_device *bl;
@@ -273,7 +271,9 @@ static int as3711_backlight_parse_dt(struct device *dev)
 
fb = of_parse_phandle(bl, "su1-dev", 0);
if (fb) {
-   pdata->su1_fb = fb->full_name;
+   of_node_put(fb);
+
+   pdata->su1_fb = true;
 
ret = of_property_read_u32(bl, "su1-max-uA", 
>su1_max_uA);
if (pdata->su1_max_uA <= 0)
@@ -286,7 +286,9 @@ static int as3711_backlight_parse_dt(struct device *dev)
if (fb) {
int count = 0;
 
-   pdata->su2_fb = fb->full_name;
+   of_node_put(fb);
+
+   pdata->su2_fb = true;
 
ret = of_property_read_u32(bl, "su2-max-uA", 
>su2_max_uA);
if (pdata->su2_max_uA <= 0)
@@ -425,7 +427,6 @@ static int as3711_backlight_probe(struct platform_device 
*pdev)
 
if (pdata->su1_fb) {
su = >su1;
-   su->fb_name = pdata->su1_fb;
su->type = AS3711_BL_SU1;
 
max_brightness = min(pdata->su1_max_uA, 31);
@@ -436,7 +437,6 @@ static int as3711_backlight_probe(struct platform_device 
*pdev)
 
if (pdata->su2_fb) {
su = >su2;
-   su->fb_name = pdata->su2_fb;
su->type = AS3711_BL_SU2;
 
switch (pdata->su2_fbprot) {
diff --git a/include/linux/mfd/as3711.h b/include/linux/mfd/as3711.h
index 34cc85864be5..ddd0b953323b 100644
--- a/include/linux/mfd/as3711.h
+++ b/include/linux/mfd/as3711.h
@@ -108,9 +108,9 @@ struct as3711_regulator_pdata {
 };
 
 struct as3711_bl_pdata {
-   const char *su1_fb;
+   bool su1_fb;
int su1_max_uA;
-   const char *su2_fb;
+   bool su2_fb;
int su2_max_uA;
enum as3711_su2_feedback su2_feedback;
enum as3711_su2_fbprot su2_fbprot;
-- 
2.15.0

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

[PATCH v2 3/4] backlight: tps65217_bl: fix device-tree node lookup

[Johan Hovold]

Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.

This would only cause trouble if the child node is missing while there
is an unrelated node named "backlight" elsewhere in the tree.

Fixes: eebfdc17cc6c ("backlight: Add TPS65217 WLED driver")
Cc: stable  # 3.7
Cc: Matthias Kaehlcke 
Signed-off-by: Johan Hovold 
---
 drivers/video/backlight/tps65217_bl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/tps65217_bl.c 
b/drivers/video/backlight/tps65217_bl.c
index 380917c86276..762e3feed097 100644
--- a/drivers/video/backlight/tps65217_bl.c
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -184,11 +184,11 @@ static struct tps65217_bl_pdata *
 tps65217_bl_parse_dt(struct platform_device *pdev)
 {
struct tps65217 *tps = dev_get_drvdata(pdev->dev.parent);
-   struct device_node *node = of_node_get(tps->dev->of_node);
+   struct device_node *node;
struct tps65217_bl_pdata *pdata, *err;
u32 val;
 
-   node = of_find_node_by_name(node, "backlight");
+   node = of_get_child_by_name(tps->dev->of_node, "backlight");
if (!node)
return ERR_PTR(-ENODEV);
 
-- 
2.15.0

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

[PATCH v2 2/4] backlight: max8925_bl: fix device-tree node lookup

[Johan Hovold]

Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.

To make things worse, the parent mfd node was also prematurely freed,
while the child backlight node was leaked.

Fixes: 47ec340cb8e2 ("mfd: max8925: Support dt for backlight")
Cc: stable  # 3.9
Cc: Qing Xu 
Cc: Haojian Zhuang 
Signed-off-by: Johan Hovold 
---
 drivers/video/backlight/max8925_bl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/backlight/max8925_bl.c 
b/drivers/video/backlight/max8925_bl.c
index 7b738d60ecc2..f3aa6088f1d9 100644
--- a/drivers/video/backlight/max8925_bl.c
+++ b/drivers/video/backlight/max8925_bl.c
@@ -116,7 +116,7 @@ static void max8925_backlight_dt_init(struct 
platform_device *pdev)
if (!pdata)
return;
 
-   np = of_find_node_by_name(nproot, "backlight");
+   np = of_get_child_by_name(nproot, "backlight");
if (!np) {
dev_err(>dev, "failed to find backlight node\n");
return;
@@ -125,6 +125,8 @@ static void max8925_backlight_dt_init(struct 
platform_device *pdev)
if (!of_property_read_u32(np, "maxim,max8925-dual-string", ))
pdata->dual_string = val;
 
+   of_node_put(np);
+
pdev->dev.platform_data = pdata;
 }
 
-- 
2.15.0

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

Re: 4.9.62: intermittent flicker after upgrade from 4.9.61

[Rainer Fiebig]

Jani Nikula wrote:
> On Sun, 19 Nov 2017, Greg KH  wrote:
>> On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote:
>>> Greg KH wrote:
 On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
> Greg KH wrote:
>> On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
>>> Greg KH wrote:
 On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote:
> Hi!
>
> Hopefully the right addressee.
>
> Encountered two bad backports which cause screen-flicker.
> dmesg shows:
>
> ...
> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO 
> underrun
> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO 
> underrun
> ...
>
> CPU: Intel Core i3 (Clarkdale/Ironlake)
>
> The backports are:
>
> - diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 49de476..277a802 100644
> - diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index a19ec06..3ce9ba3 100644
>
> After reversing them the flicker is gone, no more messages in dmesg. 
> All
> else OK so far.

 So which commit was the one that caused the problem?  I will be glad to
 revert it.

 thanks,

 greg k-h


>>>
>>> I started by reverting the more complex one first ("index
>>> 49de476..277a802100644"). But the kernel wouldn't compile then.
>>
>> What git commit id is that?  I don't see those ids in the 4.9-stable
>> tree.
>>
>>> So I also reverted "index a19ec06..3ce9ba3 100644". After that the
>>> kernel compiled just fine and the problems were gone (still are).
>>
>> Same here, what git commit id was this?
>>
>> thanks,
>>
>> greg k-h
>>
>
> OK, no mistake. IIRC, I took the patches (and the IDs) from the
> changelog for patch-4.9.62. I've attached both, so you can check yourself.
>
> I've also applied a freshly downloaded patch-4.9.62 to a freshly
> expanded 4.9 and re-compiled. The flicker is there. I haven't yet
> reverted the two patches but I'm confident that after having done so the
> flicker will be gone. If not I'll let you know.
>
> As a good news: 4.14 is *not* affected. So to me it seems those two
> patches are part of sort of a package and can not be backported alone.
>
> So long!
> Rainer Fiebig

> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> b/drivers/gpu/drm/i915/intel_pm.c
> index 49de476..277a802 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -27,6 +27,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include "i915_drv.h"
>  #include "intel_drv.h"
>  #include "../../../platform/x86/intel_ips.h"
> @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct 
> drm_i915_private *dev_priv,
>const struct intel_crtc *intel_crtc,
>int level,
>struct intel_crtc_state *cstate,
> -  struct intel_plane_state *pristate,
> -  struct intel_plane_state *sprstate,
> -  struct intel_plane_state *curstate,
> +  const struct intel_plane_state *pristate,
> +  const struct intel_plane_state *sprstate,
> +  const struct intel_plane_state *curstate,
>struct intel_wm_level *result)
>  {
>   uint16_t pri_latency = dev_priv->wm.pri_latency[level];
> @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct 
> intel_crtc_state *cstate)
>   struct intel_pipe_wm *pipe_wm;
>   struct drm_device *dev = state->dev;
>   const struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_plane *intel_plane;
> - struct intel_plane_state *pristate = NULL;
> - struct intel_plane_state *sprstate = NULL;
> - struct intel_plane_state *curstate = NULL;
> + struct drm_plane *plane;
> + const struct drm_plane_state *plane_state;
> + const struct intel_plane_state *pristate = NULL;
> + const struct intel_plane_state *sprstate = NULL;
> + const struct intel_plane_state *curstate = NULL;
>   int level, max_level = ilk_wm_max_level(dev), usable_level;
>   struct ilk_wm_maximums max;
>  
>   pipe_wm = >wm.ilk.optimal;
>  
> - for_each_intel_plane_on_crtc(dev, 

[PATCH v2 1/4] backlight: as3711_bl: fix device-tree node lookup

[Johan Hovold]

Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.

To make things worse, the parent mfd node was also prematurely freed.

Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support")
Cc: stable  # 3.10
Cc: Guennadi Liakhovetski 
Signed-off-by: Johan Hovold 
---
 drivers/video/backlight/as3711_bl.c | 33 +++--
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/drivers/video/backlight/as3711_bl.c 
b/drivers/video/backlight/as3711_bl.c
index 734a9158946b..e55304d5cf07 100644
--- a/drivers/video/backlight/as3711_bl.c
+++ b/drivers/video/backlight/as3711_bl.c
@@ -262,10 +262,10 @@ static int as3711_bl_register(struct platform_device 
*pdev,
 static int as3711_backlight_parse_dt(struct device *dev)
 {
struct as3711_bl_pdata *pdata = dev_get_platdata(dev);
-   struct device_node *bl =
-   of_find_node_by_name(dev->parent->of_node, "backlight"), *fb;
+   struct device_node *bl, *fb;
int ret;
 
+   bl = of_get_child_by_name(dev->parent->of_node, "backlight");
if (!bl) {
dev_dbg(dev, "backlight node not found\n");
return -ENODEV;
@@ -279,7 +279,7 @@ static int as3711_backlight_parse_dt(struct device *dev)
if (pdata->su1_max_uA <= 0)
ret = -EINVAL;
if (ret < 0)
-   return ret;
+   goto err_put_bl;
}
 
fb = of_parse_phandle(bl, "su2-dev", 0);
@@ -292,7 +292,7 @@ static int as3711_backlight_parse_dt(struct device *dev)
if (pdata->su2_max_uA <= 0)
ret = -EINVAL;
if (ret < 0)
-   return ret;
+   goto err_put_bl;
 
if (of_find_property(bl, "su2-feedback-voltage", NULL)) {
pdata->su2_feedback = AS3711_SU2_VOLTAGE;
@@ -314,8 +314,10 @@ static int as3711_backlight_parse_dt(struct device *dev)
pdata->su2_feedback = AS3711_SU2_CURR_AUTO;
count++;
}
-   if (count != 1)
-   return -EINVAL;
+   if (count != 1) {
+   ret = -EINVAL;
+   goto err_put_bl;
+   }
 
count = 0;
if (of_find_property(bl, "su2-fbprot-lx-sd4", NULL)) {
@@ -334,8 +336,10 @@ static int as3711_backlight_parse_dt(struct device *dev)
pdata->su2_fbprot = AS3711_SU2_GPIO4;
count++;
}
-   if (count != 1)
-   return -EINVAL;
+   if (count != 1) {
+   ret = -EINVAL;
+   goto err_put_bl;
+   }
 
count = 0;
if (of_find_property(bl, "su2-auto-curr1", NULL)) {
@@ -355,11 +359,20 @@ static int as3711_backlight_parse_dt(struct device *dev)
 * At least one su2-auto-curr* must be specified iff
 * AS3711_SU2_CURR_AUTO is used
 */
-   if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO))
-   return -EINVAL;
+   if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO)) {
+   ret = -EINVAL;
+   goto err_put_bl;
+   }
}
 
+   of_node_put(bl);
+
return 0;
+
+err_put_bl:
+   of_node_put(bl);
+
+   return ret;
 }
 
 static int as3711_backlight_probe(struct platform_device *pdev)
-- 
2.15.0

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

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Boris Ostrovsky]

On 10/18/2017 09:58 AM, Christian König wrote:
> From: Christian König 
>
> Most BIOS don't enable this because of compatibility reasons.
>
> Manually enable a 64bit BAR of 64GB size so that we have
> enough room for PCI devices.
>
> v2: style cleanups, increase size, add resource name, set correct flags,
> print message that windows was added
> v3: add defines for all the magic numbers, style cleanups
> v4: add some comment that the BIOS should actually allow this using
> _PRS and _SRS.
> v5: only enable this if CONFIG_PHYS_ADDR_T_64BIT is set
>
> Signed-off-by: Christian König 
> Reviewed-by: Andy Shevchenko 
> ---
>  arch/x86/pci/fixup.c | 80 
> 
>  1 file changed, 80 insertions(+)
>
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index 11e407489db0..7b6bd76713c5 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -618,3 +618,83 @@ static void quirk_apple_mbp_poweroff(struct pci_dev 
> *pdev)
>   dev_info(dev, "can't work around MacBook Pro poweroff issue\n");
>  }
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, 
> quirk_apple_mbp_poweroff);
> +
> +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> +
> +#define AMD_141b_MMIO_BASE(x)(0x80 + (x) * 0x8)
> +#define AMD_141b_MMIO_BASE_RE_MASK   BIT(0)
> +#define AMD_141b_MMIO_BASE_WE_MASK   BIT(1)
> +#define AMD_141b_MMIO_BASE_MMIOBASE_MASK GENMASK(31,8)
> +
> +#define AMD_141b_MMIO_LIMIT(x)   (0x84 + (x) * 0x8)
> +#define AMD_141b_MMIO_LIMIT_MMIOLIMIT_MASK   GENMASK(31,8)
> +
> +#define AMD_141b_MMIO_HIGH(x)(0x180 + (x) * 0x4)
> +#define AMD_141b_MMIO_HIGH_MMIOBASE_MASK GENMASK(7,0)
> +#define AMD_141b_MMIO_HIGH_MMIOLIMIT_SHIFT   16
> +#define AMD_141b_MMIO_HIGH_MMIOLIMIT_MASKGENMASK(23,16)
> +
> +/*
> + * The PCI Firmware Spec, rev 3.2 notes that ACPI should optionally allow
> + * configuring host bridge windows using the _PRS and _SRS methods.
> + *
> + * But this is rarely implemented, so we manually enable a large 64bit BAR 
> for
> + * PCIe device on AMD Family 15h (Models 30h-3fh) Processors here.
> + */
> +static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
> +{
> + struct resource *res, *conflict;
> + u32 base, limit, high;
> + unsigned i;
> +
> + for (i = 0; i < 8; ++i) {
> + pci_read_config_dword(dev, AMD_141b_MMIO_BASE(i), );
> + pci_read_config_dword(dev, AMD_141b_MMIO_HIGH(i), );
> +
> + /* Is this slot free? */
> + if (!(base & (AMD_141b_MMIO_BASE_RE_MASK |
> +   AMD_141b_MMIO_BASE_WE_MASK)))
> + break;
> +
> + base >>= 8;
> + base |= high << 24;
> +
> + /* Abort if a slot already configures a 64bit BAR. */
> + if (base > 0x1)
> + return;
> + }
> + if (i == 8)
> + return;
> +
> + res = kzalloc(sizeof(*res), GFP_KERNEL);
> + if (!res)
> + return;
> +
> + res->name = "PCI Bus :00";
> + res->flags = IORESOURCE_PREFETCH | IORESOURCE_MEM |
> + IORESOURCE_MEM_64 | IORESOURCE_WINDOW;
> + res->start = 0x1ull;
> + res->end = 0xfdull - 1;
> +
> + /* Just grab the free area behind system memory for this */
> + while ((conflict = request_resource_conflict(_resource, res)))
> + res->start = conflict->end + 1;


I get stuck in the infinite loop here.

Presumably because on a multi-socket system we succeed for the first
processor (:00:18.1) and add 'res' to iomem_resource. For
:00:19.1 we find the slot in the 'for' loop above but then we fail
to find a place to add 'res'. And with final sibling being [0 - max
possible addr] we are stuck here.

A possible solution to get out of the loop could be
if (conflict->end >= res->end) {
kfree(res);
return;
   }


but I don't know whether this is what we actually want.

This is a 2-socket

vendor_id: AuthenticAMD
cpu family: 21
model: 1
model name: AMD Opteron(TM) Processor 6272
stepping: 2


(and then it breaks differently as a Xen guest --- we hung on the last
pci_read_config_dword(), I haven't looked at this at all yet)



-boris


> +
> + dev_info(>dev, "adding root bus resource %pR\n", res);
> +
> + base = ((res->start >> 8) & AMD_141b_MMIO_BASE_MMIOBASE_MASK) |
> + AMD_141b_MMIO_BASE_RE_MASK | AMD_141b_MMIO_BASE_WE_MASK;
> + limit = ((res->end + 1) >> 8) & AMD_141b_MMIO_LIMIT_MMIOLIMIT_MASK;
> + high = ((res->start >> 40) & AMD_141b_MMIO_HIGH_MMIOBASE_MASK) |
> + res->end + 1) >> 40) << AMD_141b_MMIO_HIGH_MMIOLIMIT_SHIFT)
> +  & AMD_141b_MMIO_HIGH_MMIOLIMIT_MASK);
> +
> + pci_write_config_dword(dev, AMD_141b_MMIO_HIGH(i), high);
> + 

[PATCH v2 0/4] backlight: fix device-tree node lookups

[Johan Hovold]

A number of drivers have been using the wrong OF helper when doing child-node
lookups during probe. This meant that they were doing tree-wide searches rather
than matching on child nodes and that the parent node could end up being
prematurely freed.

Johan

v2
 - add patch 4/4 which fixes two node leaks in as3711_bl instead of marking
   the leaks using FIXMEs in patch 1/4


Johan Hovold (4):
  backlight: as3711_bl: fix device-tree node lookup
  backlight: max8925_bl: fix device-tree node lookup
  backlight: tps65217_bl: fix device-tree node lookup
  backlight: as3711_bl: fix device-tree node leaks

 drivers/video/backlight/as3711_bl.c   | 45 ++-
 drivers/video/backlight/max8925_bl.c  |  4 +++-
 drivers/video/backlight/tps65217_bl.c |  4 ++--
 include/linux/mfd/as3711.h|  4 ++--
 4 files changed, 36 insertions(+), 21 deletions(-)

-- 
2.15.0

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

Re: 4.9.62: intermittent flicker after upgrade from 4.9.61

[Rainer Fiebig]

Maarten Lankhorst wrote:
> Op 20-11-17 om 09:51 schreef Rainer Fiebig:
>> Jani Nikula wrote:
>>> On Sun, 19 Nov 2017, Greg KH  wrote:
 On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote:
> Greg KH wrote:
>> On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
>>> Greg KH wrote:
 On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
> Greg KH wrote:
>> On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote:
>>> Hi!
>>>
>>> Hopefully the right addressee.
>>>
>>> Encountered two bad backports which cause screen-flicker.
>>> dmesg shows:
>>>
>>> ...
>>> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
>>> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO 
>>> underrun
>>> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
>>> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO 
>>> underrun
>>> ...
>>>
>>> CPU: Intel Core i3 (Clarkdale/Ironlake)
>>>
>>> The backports are:
>>>
>>> - diff --git a/drivers/gpu/drm/i915/intel_pm.c
>>> b/drivers/gpu/drm/i915/intel_pm.c
>>> index 49de476..277a802 100644
>>> - diff --git a/drivers/gpu/drm/i915/intel_drv.h
>>> b/drivers/gpu/drm/i915/intel_drv.h
>>> index a19ec06..3ce9ba3 100644
>>>
>>> After reversing them the flicker is gone, no more messages in 
>>> dmesg. All
>>> else OK so far.
>> So which commit was the one that caused the problem?  I will be glad 
>> to
>> revert it.
>>
>> thanks,
>>
>> greg k-h
>>
>>
> I started by reverting the more complex one first ("index
> 49de476..277a802100644"). But the kernel wouldn't compile then.
 What git commit id is that?  I don't see those ids in the 4.9-stable
 tree.

> So I also reverted "index a19ec06..3ce9ba3 100644". After that the
> kernel compiled just fine and the problems were gone (still are).
 Same here, what git commit id was this?

 thanks,

 greg k-h

>>> OK, no mistake. IIRC, I took the patches (and the IDs) from the
>>> changelog for patch-4.9.62. I've attached both, so you can check 
>>> yourself.
>>>
>>> I've also applied a freshly downloaded patch-4.9.62 to a freshly
>>> expanded 4.9 and re-compiled. The flicker is there. I haven't yet
>>> reverted the two patches but I'm confident that after having done so the
>>> flicker will be gone. If not I'll let you know.
>>>
>>> As a good news: 4.14 is *not* affected. So to me it seems those two
>>> patches are part of sort of a package and can not be backported alone.
>>>
>>> So long!
>>> Rainer Fiebig
>>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>>> b/drivers/gpu/drm/i915/intel_pm.c
>>> index 49de476..277a802 100644
>>> --- a/drivers/gpu/drm/i915/intel_pm.c
>>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>>> @@ -27,6 +27,7 @@
>>>  
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include "i915_drv.h"
>>>  #include "intel_drv.h"
>>>  #include "../../../platform/x86/intel_ips.h"
>>> @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct 
>>> drm_i915_private *dev_priv,
>>>  const struct intel_crtc *intel_crtc,
>>>  int level,
>>>  struct intel_crtc_state *cstate,
>>> -struct intel_plane_state *pristate,
>>> -struct intel_plane_state *sprstate,
>>> -struct intel_plane_state *curstate,
>>> +const struct intel_plane_state 
>>> *pristate,
>>> +const struct intel_plane_state 
>>> *sprstate,
>>> +const struct intel_plane_state 
>>> *curstate,
>>>  struct intel_wm_level *result)
>>>  {
>>> uint16_t pri_latency = dev_priv->wm.pri_latency[level];
>>> @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct 
>>> intel_crtc_state *cstate)
>>> struct intel_pipe_wm *pipe_wm;
>>> struct drm_device *dev = state->dev;
>>> const struct drm_i915_private *dev_priv = to_i915(dev);
>>> -   struct intel_plane *intel_plane;
>>> -   struct intel_plane_state *pristate = NULL;
>>> -   struct intel_plane_state *sprstate = NULL;
>>> -   struct intel_plane_state *curstate = NULL;
>>> +   struct drm_plane *plane;
>>> + 

Re: [PATCH 1/3] backlight: as3711_bl: fix device-tree node lookup

[Johan Hovold]

On Wed, Nov 15, 2017 at 03:39:09PM +0100, Johan Hovold wrote:
> On Wed, Nov 15, 2017 at 02:32:11PM +, Lee Jones wrote:
> > On Wed, 15 Nov 2017, Johan Hovold wrote:
> > 
> > > On Tue, Nov 14, 2017 at 07:48:09PM +, Daniel Thompson wrote:
> > > > On 14/11/17 18:05, Johan Hovold wrote:
> > > > > On Mon, Nov 13, 2017 at 02:16:09PM +, Daniel Thompson wrote:
> > > > >> On 13/11/17 10:20, Johan Hovold wrote:
> > > > >>> Fix child-node lookup during probe, which ended up searching the 
> > > > >>> whole
> > > > >>> device tree depth-first starting at the parent rather than just 
> > > > >>> matching
> > > > >>> on its children.
> > > > >>>
> > > > >>> To make things worse, the parent mfd node was also prematurely 
> > > > >>> freed.
> > > > >>>
> > > > >>> Note that the nodes returned from the two calls to 
> > > > >>> of_parse_phandle()
> > > > >>> are also leaking, but fixing that is a bit more involved as 
> > > > >>> pointers to
> > > > >>> node fields are being stored for later use.
> > > > >>
> > > > >> Is using a devm_kstrdup() to remember the full_name sufficient so get
> > > > >> each of the FIXMEs cleaned up as well?
> > > > > 
> > > > > Yeah, that may be sufficient, but looking closer at this now, it seems
> > > > > the name pointers (su1_fb and su2_fb) are only used as booleans, and 
> > > > > the
> > > > > fb_name pointer in struct as3711_bl_data is never used at all.
> > > > > 
> > > > > So cleaning that up somehow (e.g. and maybe even dropping non-dt
> > > > > probing) would also work.
> > > > > 
> > > > > But since this is a separate, and less critical issue, I think it 
> > > > > needs
> > > > > to be done as a follow up to this one.
> > > > 
> > > > To be honest it was adding the separate and less critical FIXMEs into 
> > > > the patches that attracted my attention in the first place. ;-)
> > > 
> > > Heh. Since I was touching those error paths, I at least wanted to record
> > > somehow there were further issues to be addressed. But feel free to drop
> > > the FIXMEs if you prefer.
> > 
> > In my experience FIXME's tend not to get addressed:
> > 
> > $ git grep -i fixme | wc -l
> > 4431
> > 
> > Submit patches instead. :)
> 
> There may be some truth to that, but I still think it's better to mark
> what is broken (especially since a leaked node is no big deal in this
> case) than to just ignore and forget about it.

I just sent a v2 including a new patch fixing these node leaks instead
of just flagging them. The driver really had no business storing those
node full_name fields in the first place.

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

Re: [PATCHv3] drm: adv7511/33: Fix adv7511_cec_init() failure handling

[Laurent Pinchart]

Hi Hans,

Thank you for the patch.

On Tuesday, 21 November 2017 10:17:43 EET Hans Verkuil wrote:
> If the device tree for a board did not specify a cec clock, then
> adv7511_cec_init would return an error, which would cause adv7511_probe()
> to fail and thus there is no HDMI output.
> 
> There is no need to have adv7511_probe() fail if the CEC initialization
> fails, so just change adv7511_cec_init() to a void function. In addition,
> adv7511_cec_init() should just return silently if the cec clock isn't
> found and show a message for any other errors.
> 
> An otherwise correct cleanup patch from Dan Carpenter turned this broken
> failure handling into a kernel Oops, so bisection points to commit
> 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL") rather
> than 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support").
> 
> Based on earlier patches from Arnd and John.
> 
> Reported-by: Naresh Kamboju 
> Cc: Xinliang Liu 
> Cc: Dan Carpenter 
> Cc: Sean Paul 
> Cc: Archit Taneja 
> Cc: John Stultz 
> Link: https://bugs.linaro.org/show_bug.cgi?id=3345
> Link: https://lkft.validation.linaro.org/scheduler/job/48017#L3551
> Fixes: 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL")
> Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
> Signed-off-by: Hans Verkuil 
> Tested-by: Hans Verkuil 

Reviewed-by: Laurent Pinchart 

> ---
> This rework of Arnd and John's patches goes a bit further and just silently
> exits if there is no cec clock defined in the dts. I'm sure that's the
> reason why the kirin board failed on this. BTW: if the kirin board DOES
> support cec, then it would be nice if it can be hooked up in the dts!
> 
> Tested with my Dragonboard and Renesas Koelsch board. Also tested what
> happens when probing is deferred due to missing cec clock.
> 
> John, can you test this again?
> 
> Changes since v2:
> - reverted adv7511_cec_init back to an int function for EPROBE_DEFER
> - incorporated Laurent's comments
> - moved the adv7511_cec_init call up in the probe function to prevent
>   having to remove the bridge in case of an error.
> 
> Change since my previous RFC PATCH:
> 
> - added static inline adv7511_cec_init to avoid #ifdef in the probe function
> as suggested by John Stultz.
> 
> Regards,
> 
>   Hans
> ---
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h index b4efcbabf7f7..d034b2cb5eee
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -372,9 +372,18 @@ struct adv7511 {
>  };
> 
>  #ifdef CONFIG_DRM_I2C_ADV7511_CEC
> -int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
> -  unsigned int offset);
> +int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511);
>  void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
> +#else
> +static inline int adv7511_cec_init(struct device *dev, struct adv7511
> *adv7511) +{
> + unsigned int offset = adv7511->type == ADV7533 ?
> + ADV7533_REG_CEC_OFFSET : 0;
> +
> + regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
> +  ADV7511_CEC_CTRL_POWER_DOWN);
> + return 0;
> +}
>  #endif
> 
>  #ifdef CONFIG_DRM_I2C_ADV7533
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c index
> b33d730e4d73..a20a45c0b353 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> @@ -300,18 +300,21 @@ static int adv7511_cec_parse_dt(struct device *dev,
> struct adv7511 *adv7511) return 0;
>  }
> 
> -int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
> -  unsigned int offset)
> +int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511)
>  {
> + unsigned int offset = adv7511->type == ADV7533 ?
> + ADV7533_REG_CEC_OFFSET : 0;
>   int ret = adv7511_cec_parse_dt(dev, adv7511);
> 
>   if (ret)
> - return ret;
> + goto err_cec_parse_dt;
> 
>   adv7511->cec_adap = cec_allocate_adapter(_cec_adap_ops,
>   adv7511, dev_name(dev), CEC_CAP_DEFAULTS, ADV7511_MAX_ADDRS);
> - if (IS_ERR(adv7511->cec_adap))
> - return PTR_ERR(adv7511->cec_adap);
> + if (IS_ERR(adv7511->cec_adap)) {
> + ret = PTR_ERR(adv7511->cec_adap);
> + goto err_cec_alloc;
> + }
> 
>   regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset, 0);
>   /* cec soft reset */
> @@ -329,9 +332,18 @@ int adv7511_cec_init(struct device *dev, struct adv7511
> *adv7511, ((adv7511->cec_clk_freq / 75) - 1) << 2);
> 
>

Re: [PATCHv2] drm: adv7511/33: Fix adv7511_cec_init() failure handling

[Hans Verkuil]

On 11/21/2017 07:48 AM, Laurent Pinchart wrote:
> Hi Hans,
> 
> Thank you for the patch.
> 
> On Monday, 20 November 2017 22:57:34 EET Hans Verkuil wrote:
>> If the device tree for a board did not specify a cec clock, then
>> adv7511_cec_init would return an error, which would cause adv7511_probe()
>> to fail and thus there is no HDMI output.
>>
>> There is no need to have adv7511_probe() fail if the CEC initialization
>> fails, so just change adv7511_cec_init() to a void function. In addition,
>> adv7511_cec_init() should just return silently if the cec clock isn't
>> found and show a message for any other errors.
> 
> I don't think that's correct. You at least need to defer probing if the clock 
> is specified in DT but has no provider available yet. For other errors I 
> agree 
> that we can still initialize the ADV7511 in a degraded mode without CEC 
> support, although I would prefer to also error out in case of invalid DT to 
> ensure that DT errors are caught as early as possible.

Ah yes, probe deferring, I forgot about that. I'll make a v3.
The only other possible error is ENOENT for when no CEC clock is defined,
which just means it should continue without CEC (i.e. this is not an error).

I'll make a v3, also incorporating your other comments below.

Regards,

Hans

> 
>> An otherwise correct cleanup patch from Dan Carpenter turned this broken
>> failure handling into a kernel Oops, so bisection points to commit
>> 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL") rather
>> than 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support").
>>
>> Based on earlier patches from Arnd and John.
>>
>> Reported-by: Naresh Kamboju 
>> Cc: Xinliang Liu 
>> Cc: Dan Carpenter 
>> Cc: Sean Paul 
>> Cc: Archit Taneja 
>> Cc: John Stultz 
>> Link: https://bugs.linaro.org/show_bug.cgi?id=3345
>> Link: https://lkft.validation.linaro.org/scheduler/job/48017#L3551
>> Fixes: 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL")
>> Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
>> Signed-off-by: Hans Verkuil 
>> Tested-by: Hans Verkuil 
>> ---
>> This rework of Arnd and John's patches goes a bit further and makes
>> cec_init a void function and just silently exits if there is no cec clock
>> defined in the dts. I'm sure that's the reason why the kirin board failed
>> on this. BTW: if the kirin board DOES support cec, then it would be nice
>> if it can be hooked up in the dts!
>>
>> Tested with my Dragonboard and Renesas Koelsch board.
>>
>> Change since my previous RFC PATCH:
>>
>> - added static inline adv7511_cec_init to avoid #ifdef in the probe function
>> as suggested by John Stultz.
>>
>> Regards,
>>
>>  Hans
>> ---
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> b/drivers/gpu/drm/bridge/adv7511/adv7511.h index 543a5eb91624..16051bfa5578
>> 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> @@ -374,9 +374,17 @@ struct adv7511 {
>>  };
>>
>>  #ifdef CONFIG_DRM_I2C_ADV7511_CEC
>> -int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
>> - unsigned int offset);
>> +void adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
>> +  unsigned int offset);
>>  void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
>> +#else
>> +static inline void adv7511_cec_init(struct device *dev,
>> +struct adv7511 *adv7511,
>> +unsigned int offset)
>> +{
>> +regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
>> + ADV7511_CEC_CTRL_POWER_DOWN);
>> +}
>>  #endif
>>
>>  #ifdef CONFIG_DRM_I2C_ADV7533
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
>> b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c index
>> b33d730e4d73..c1cd471d31fa 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
>> @@ -300,18 +300,20 @@ static int adv7511_cec_parse_dt(struct device *dev,
>> struct adv7511 *adv7511) return 0;
>>  }
>>
>> -int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
>> - unsigned int offset)
>> +void adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
>> +  unsigned int offset)
>>  {
>>  int ret = adv7511_cec_parse_dt(dev, adv7511);
>>
>>  if (ret)
>> -return ret;
>> +goto disable_cec;
>>
>>  adv7511->cec_adap = cec_allocate_adapter(_cec_adap_ops,
>>  adv7511, dev_name(dev), CEC_CAP_DEFAULTS, ADV7511_MAX_ADDRS);
>> -if (IS_ERR(adv7511->cec_adap))
>> -return PTR_ERR(adv7511->cec_adap);
>> +if (IS_ERR(adv7511->cec_adap)) {
>> +ret = PTR_ERR(adv7511->cec_adap);
>> 

[PATCHv3] drm: adv7511/33: Fix adv7511_cec_init() failure handling

[Hans Verkuil]

If the device tree for a board did not specify a cec clock, then
adv7511_cec_init would return an error, which would cause adv7511_probe()
to fail and thus there is no HDMI output.

There is no need to have adv7511_probe() fail if the CEC initialization
fails, so just change adv7511_cec_init() to a void function. In addition,
adv7511_cec_init() should just return silently if the cec clock isn't
found and show a message for any other errors.

An otherwise correct cleanup patch from Dan Carpenter turned this broken
failure handling into a kernel Oops, so bisection points to commit
7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL") rather
than 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support").

Based on earlier patches from Arnd and John.

Reported-by: Naresh Kamboju 
Cc: Xinliang Liu 
Cc: Dan Carpenter 
Cc: Sean Paul 
Cc: Archit Taneja 
Cc: John Stultz 
Link: https://bugs.linaro.org/show_bug.cgi?id=3345
Link: https://lkft.validation.linaro.org/scheduler/job/48017#L3551
Fixes: 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL")
Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Hans Verkuil 
Tested-by: Hans Verkuil 
---
This rework of Arnd and John's patches goes a bit further and just silently
exits if there is no cec clock defined in the dts. I'm sure that's the
reason why the kirin board failed on this. BTW: if the kirin board DOES
support cec, then it would be nice if it can be hooked up in the dts!

Tested with my Dragonboard and Renesas Koelsch board. Also tested what
happens when probing is deferred due to missing cec clock.

John, can you test this again?

Changes since v2:
- reverted adv7511_cec_init back to an int function for EPROBE_DEFER
- incorporated Laurent's comments
- moved the adv7511_cec_init call up in the probe function to prevent
  having to remove the bridge in case of an error.

Change since my previous RFC PATCH:

- added static inline adv7511_cec_init to avoid #ifdef in the probe function
  as suggested by John Stultz.

Regards,

Hans
---
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index b4efcbabf7f7..d034b2cb5eee 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -372,9 +372,18 @@ struct adv7511 {
 };

 #ifdef CONFIG_DRM_I2C_ADV7511_CEC
-int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
-unsigned int offset);
+int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511);
 void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
+#else
+static inline int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511)
+{
+   unsigned int offset = adv7511->type == ADV7533 ?
+   ADV7533_REG_CEC_OFFSET : 0;
+
+   regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
+ADV7511_CEC_CTRL_POWER_DOWN);
+   return 0;
+}
 #endif

 #ifdef CONFIG_DRM_I2C_ADV7533
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
index b33d730e4d73..a20a45c0b353 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
@@ -300,18 +300,21 @@ static int adv7511_cec_parse_dt(struct device *dev, 
struct adv7511 *adv7511)
return 0;
 }

-int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
-unsigned int offset)
+int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511)
 {
+   unsigned int offset = adv7511->type == ADV7533 ?
+   ADV7533_REG_CEC_OFFSET : 0;
int ret = adv7511_cec_parse_dt(dev, adv7511);

if (ret)
-   return ret;
+   goto err_cec_parse_dt;

adv7511->cec_adap = cec_allocate_adapter(_cec_adap_ops,
adv7511, dev_name(dev), CEC_CAP_DEFAULTS, ADV7511_MAX_ADDRS);
-   if (IS_ERR(adv7511->cec_adap))
-   return PTR_ERR(adv7511->cec_adap);
+   if (IS_ERR(adv7511->cec_adap)) {
+   ret = PTR_ERR(adv7511->cec_adap);
+   goto err_cec_alloc;
+   }

regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset, 0);
/* cec soft reset */
@@ -329,9 +332,18 @@ int adv7511_cec_init(struct device *dev, struct adv7511 
*adv7511,
 ((adv7511->cec_clk_freq / 75) - 1) << 2);

ret = cec_register_adapter(adv7511->cec_adap, dev);
-   if (ret) {
-   cec_delete_adapter(adv7511->cec_adap);
-   adv7511->cec_adap = NULL;
-   }
-   return ret;
+   if (ret)
+   goto err_cec_register;
+   return 0;
+
+err_cec_register:
+   

Re: [PATCH 2/2] drm/selftests/mm: Add callsite indicator to common asserts

[Joonas Lahtinen]

On Thu, 2017-11-09 at 21:24 +, Chris Wilson wrote:
> The majority of the asserts (validating nodes and ranges) are shared
> amongst several subtests. This makes identification of which caller
> failed hard; but we uniquely identify them if we include the callsite
> into the assertion error message (a single frame stacktrace).
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Daniel Vetter 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103370

--- Comment #36 from Robert Liu  ---
(In reply to Alex Deucher from comment #33)
> I think Sonny fixed this.  It was due to using the wrong firmware.
> [1.827060] [drm] initializing kernel modesetting (HAINAN 0x1002:0x6665
> 0x1028:0x0844 0xC3).  This chip should be using radeon/banks_k_2_smc.bin smc
> firmware.  Is that available on the test system and kernel?
The firmware radeon/banks_k_2_smc.bin is on the test system.
With Ubuntu kernel 4.4.0-101-generic, I am not pretty sure the radeon driver is
using this firmware.
With Ubuntu kernel 4.13.0-16-generic, I tried both amdgpu and radeon drivers,
but the system hang. as soon as the system hang, the amdgpu_pm_info shows
'invalid dpm profile 15'.

(In reply to Alex Deucher from comment #34)
> The following commits are relevant:
> abb2e3c1ce64c8bba678973800c34ea1dc97c42c
> 6458bd4dfd9414cba5804eb9907fe2a824278c34
> ef736d394e85b1bf1fd65ba5e5257b85f6c82325
> 4e6e98b1e48c9474aed7ce03025ec319b941e26e
These commits would be already included in Ubuntu kernel 4.13.0-16-generic.

(In reply to Alex Deucher from comment #35)
> Does reverting a628392cf03e0eef21b345afbb192cbade041741 fix the issue?
Removing this commit does not fix the issue.


BTW, with 4.13.0-16-generic, I change the max_sclk in drm/radeon/si_dpm.c (what
we did with Ubuntu kernel 4.4.0-101-generic) from 75000 to 65000, but still met
the hang issue.

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