Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Rodrigo Vivi]

Rodrigo Vivi  writes:

> "Pandiyan, Dhinakaran"  writes:
>
>> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
>>> Hi Andy,
>>>
>>> thanks for getting involved with PSR and sorry for not replying sooner.
>>>
>>> I first saw this patch on that bugzilla entry but only now I stop to
>>> really think why I have written the code that way.
>>>
>>> So some clarity below.
>>>
>>> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
>>> > The current PSR code has a two call sites that each schedule delayed
>>> > work to activate PSR.  As far as I can tell, each call site intends
>>> > to keep PSR inactive for the given amount of time and then allow it
>>> > to be activated.
>>> >
>>> > The call sites are:
>>> >
>>> >  - intel_psr_enable(), which explicitly states in a comment that
>>> >it's trying to keep PSR off a short time after the dispay is
>>> >initialized as a workaround.
>>>
>>> First of all I really want to kill this call here and remove the
>>> FIXME. It was an ugly hack that I added to solve a corner case
>>> that was leaving me with blank screens when activating so sooner.
>>>
>>> >
>>> >  - intel_psr_flush().  There isn't an explcit explanation, but the
>>> >intent is presumably to keep PSR off until the display has been
>>> >idle for 100ms.
>>>
>>> The reason for 100 is kind of ugly-nonsense-empirical value
>>> I concluded from VLV/CHV experience.
>>> On platforms with HW tracking HW waits few identical frames
>>> until really activating PSR. VLV/CHV activation is immediate.
>>> But HW is also different and there it seemed that hw needed a
>>> few more time before starting the transitions.
>>> Furthermore I didn't want to add that so quickly because I didn't
>>> want to take the risk of killing battery with software tracking
>>> when doing transitions so quickly using software tracking.
>>>
>>> >
>>> > The current code doesn't actually accomplish either of these goals.
>>> > Rather than keeping PSR inactive for the given amount of time, it
>>> > will schedule PSR for activation after the given time, with the
>>> > earliest target time in such a request winning.
>>>
>>> Putting that way I was asking myself how that hack had ever fixed
>>> my issue. Because the way you explained here seems obvious that it
>>> wouldn't ever fix my bug or any other.
>>>
>>> So I applied your patch and it made even more sense (without considering
>>> the fact I want to kill the first call anyways).
>>>
>>> So I came back, removed your patch and tried to understand how did
>>> it ever worked.
>>>
>>> So, the thing is that intel_psr_flush will never be really executed
>>> if intel_psr_enable wasn't executed. That is guaranteed by:
>>>
>>> mutex_lock(_priv->psr.lock);
>>> if (!dev_priv->psr.enabled) {
>>>
>>> So, intel_psr_enable will be for sure the first one to schedule the
>>> work delayed to the ugly higher delay.
>>>
>>> >
>>> > In other words, if intel_psr_enable() is immediately followed by
>>> > intel_psr_flush(), then PSR will be activated after 100ms even if
>>> > intel_psr_enable() wanted a longer delay.  And, if the screen is
>>> > being constantly updated so that intel_psr_flush() is called once
>>> > per frame at 60Hz, PSR will still be activated once every 100ms.
>>>
>>> During this time you are right, many calls of intel_psr_exit
>>> coming from flush functions can be called... But none of
>>> them will schedule the work with 100 delay.
>>>
>>> they will skip on
>>> if (!work_busy(_priv->psr.work.work))
>>
>> Wouldn't work_busy() return false until the work is actually queued
>> which is 100ms after calling schedule_delayed_work()?
>
> That's not my understanding of work_busy man.
>
> "work_busy - test whether a work is currently pending or running"
>
> I consider it as pending one...
>
> But yeap... it was a long time ago that I did this so I'm not sure...

I wouldn't be able to sleep today if I hand't experiment this.

So, I move the hacked scheduled to 10s and forced psr_activate 10ms
after that and the result is this:


[   11.757909] [drm:intel_psr_enable [i915]] *ERROR* I915-DEBUG:
Scheduling 10s
[   11.778586] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work busy!
...
a bunch more of Work busy
...
[   21.980643] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work busy!
[   21.983060] [drm:intel_psr_work [i915]] *ERROR* I915-DEBUG: Work running
[   21.986353] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Scheduling 
normal 100ms

So, the schedules are working as expected, I'm not crazy and I will be
able to sleep :)

(I will also attach my patch and dmesg to the bugzilla entry and close
the bug.)

But again, thank you very much for jumping here on PSR and activelly
working to improve the code. I really appreciate that.

Oh well... maybe I won't be able to sleep... I could swear this hack
here was for SKL, but when doing the patch I noticed that the hack is
for gen < 9... I will have to check some git 

[PATCH 3/3] drm/ttm: check if free mem space is under the lower limit

[Roger He]

the free mem space and the lower limit both include two parts:
system memory and swap space.

For the OOM triggered by TTM, that is the case as below:
first swap space is full of swapped out pages and soon
system memory also is filled up with ttm pages. and then
any memory allocation request will run into OOM.

to cover two cases:
a. if no swap disk at all or free swap space is under swap mem
   limit but available system mem is bigger than sys mem limit,
   allow TTM allocation;

b. if the available system mem is less than sys mem limit but
   free swap space is bigger than swap mem limit, allow TTM
   allocation.

v2: merge two memory limit(swap and system) into one
v3: keep original behavior except ttm_opt_ctx->flags with
TTM_OPT_FLAG_FORCE_ALLOC
v4: always set force_alloc as ttm_opt_ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC

Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_memory.c | 33 
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 20 ---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 30 +
 include/drm/ttm/ttm_memory.h |  5 +
 4 files changed, 69 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 154719b..7e8d3ec 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TTM_MEMORY_ALLOC_RETRIES 4
 
@@ -375,6 +376,11 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
 
si_meminfo();
 
+   /* lower limit of swap space and 256MB is enough */
+   glob->lower_mem_limit = 256 << 8;
+   /* lower limit of ram and keep consistent with each zone->emer_mem */
+   glob->lower_mem_limit += si.totalram >> 2;
+
ret = ttm_mem_init_kernel_zone(glob, );
if (unlikely(ret != 0))
goto out_no_zone;
@@ -469,6 +475,33 @@ void ttm_mem_global_free(struct ttm_mem_global *glob,
 }
 EXPORT_SYMBOL(ttm_mem_global_free);
 
+/*
+ * check if the available mem is under lower memory limit
+ *
+ * a. if no swap disk at all or free swap space is under swap_mem_limit
+ * but available system mem is bigger than sys_mem_limit, allow TTM
+ * allocation;
+ *
+ * b. if the available system mem is less than sys_mem_limit but free
+ * swap disk is bigger than swap_mem_limit, allow TTM allocation.
+ */
+bool
+ttm_check_under_lowerlimit(struct ttm_mem_global *glob, bool force_alloc)
+{
+   bool ret = false;
+   uint64_t available;
+
+   if (force_alloc)
+   return false;
+
+   available = get_nr_swap_pages() + si_mem_available();
+   if (available < glob->lower_mem_limit)
+   ret = true;
+
+   return ret;
+}
+EXPORT_SYMBOL(ttm_check_under_lowerlimit);
+
 static int ttm_mem_global_reserve(struct ttm_mem_global *glob,
  struct ttm_mem_zone *single_zone,
  uint64_t amount, bool reserve,
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 5edcd89..a5bfdc2 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1094,7 +1094,7 @@ ttm_pool_unpopulate_helper(struct ttm_tt *ttm, unsigned 
mem_count_update)
 int ttm_pool_populate(struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
 {
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
-   unsigned i;
+   unsigned i, unpopulate_count = 0;
int ret;
 
if (ttm->state != tt_unpopulated)
@@ -1102,17 +1102,19 @@ int ttm_pool_populate(struct ttm_tt *ttm, struct 
ttm_operation_ctx *ctx)
 
ret = ttm_get_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
ttm->caching_state);
-   if (unlikely(ret != 0)) {
-   ttm_pool_unpopulate_helper(ttm, 0);
-   return ret;
-   }
+   if (unlikely(ret != 0))
+   goto error_populate;
+
+   if (ttm_check_under_lowerlimit(mem_glob,
+  ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC))
+   goto error_populate;
 
for (i = 0; i < ttm->num_pages; ++i) {
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
PAGE_SIZE, ctx);
if (unlikely(ret != 0)) {
-   ttm_pool_unpopulate_helper(ttm, i);
-   return -ENOMEM;
+   unpopulate_count = i;
+   goto error_populate;
}
}
 
@@ -1126,6 +1128,10 @@ int ttm_pool_populate(struct ttm_tt *ttm, struct 
ttm_operation_ctx *ctx)
 
ttm->state = tt_unbound;
return 0;
+
+error_populate:
+   ttm_pool_unpopulate_helper(ttm, unpopulate_count);
+   return -ENOMEM;
 }
 EXPORT_SYMBOL(ttm_pool_populate);
 
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 

[PATCH 2/3] drm/ttm: add input parameter force_alloc for ttm_bo_force_list_clean

[Roger He]

if it is  true, allocate TTM pages regardless of zone global memory
account limit. For example suspend, We should avoid TTM memory
allocate failure to lead to whole process fail.

Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a907311..685baad 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1342,15 +1342,17 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
 EXPORT_SYMBOL(ttm_bo_create);
 
 static int ttm_bo_force_list_clean(struct ttm_bo_device *bdev,
-  unsigned mem_type)
+   unsigned mem_type, bool force_alloc)
 {
-   struct ttm_operation_ctx ctx = { false, false };
+   struct ttm_operation_ctx ttm_opt_ctx = { false, false };
struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_bo_global *glob = bdev->glob;
struct dma_fence *fence;
int ret;
unsigned i;
 
+   if (force_alloc)
+   ttm_opt_ctx.flags = TTM_OPT_FLAG_FORCE_ALLOC;
/*
 * Can't use standard list traversal since we're unlocking.
 */
@@ -1359,7 +1361,8 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(>lru[i])) {
spin_unlock(>lru_lock);
-   ret = ttm_mem_evict_first(bdev, mem_type, NULL, );
+   ret = ttm_mem_evict_first(bdev, mem_type, NULL,
+ _opt_ctx);
if (ret)
return ret;
spin_lock(>lru_lock);
@@ -1403,7 +1406,7 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned 
mem_type)
 
ret = 0;
if (mem_type > 0) {
-   ret = ttm_bo_force_list_clean(bdev, mem_type);
+   ret = ttm_bo_force_list_clean(bdev, mem_type, true);
if (ret) {
pr_err("Cleanup eviction failed\n");
return ret;
@@ -1433,7 +1436,7 @@ int ttm_bo_evict_mm(struct ttm_bo_device *bdev, unsigned 
mem_type)
return 0;
}
 
-   return ttm_bo_force_list_clean(bdev, mem_type);
+   return ttm_bo_force_list_clean(bdev, mem_type, true);
 }
 EXPORT_SYMBOL(ttm_bo_evict_mm);
 
-- 
2.7.4

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

[PATCH 1/3] drm/ttm: add bit flag TTM_OPT_FLAG_FORCE_ALLOC

[Roger He]

set TTM_OPT_FLAG_FORCE_ALLOC when we are servicing for page
fault routine.

for ttm_mem_global_reserve if in page fault routine, allow the gtt
pages reservation always. because page fault routing already grabbed
system memory and the allowance of this exception is harmless.
Otherwise, it will trigger OOM killer.

v2: keep original behavior except ttm bo with flag no_retry
v3: forward the ttm_operation_ctx to ttm_mem_global_reserve

Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_bo_vm.c  |  6 --
 drivers/gpu/drm/ttm/ttm_memory.c | 18 ++
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  1 -
 include/drm/ttm/ttm_bo_api.h |  4 +++-
 4 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 716e724..313398a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -224,7 +224,7 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
cvma.vm_page_prot = ttm_io_prot(bo->mem.placement,
cvma.vm_page_prot);
} else {
-   struct ttm_operation_ctx ctx = {
+   struct ttm_operation_ctx ttm_opt_ctx = {
.interruptible = false,
.no_wait_gpu = false
};
@@ -233,8 +233,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
cvma.vm_page_prot = ttm_io_prot(bo->mem.placement,
cvma.vm_page_prot);
 
+   if (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY)
+   ttm_opt_ctx.flags = TTM_OPT_FLAG_FORCE_ALLOC;
/* Allocate all page at once, most common usage */
-   if (ttm->bdev->driver->ttm_tt_populate(ttm, )) {
+   if (ttm->bdev->driver->ttm_tt_populate(ttm, _opt_ctx)) {
ret = VM_FAULT_OOM;
goto out_io_unlock;
}
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index aa0c381..154719b 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -471,7 +471,8 @@ EXPORT_SYMBOL(ttm_mem_global_free);
 
 static int ttm_mem_global_reserve(struct ttm_mem_global *glob,
  struct ttm_mem_zone *single_zone,
- uint64_t amount, bool reserve)
+ uint64_t amount, bool reserve,
+ struct ttm_operation_ctx *ctx)
 {
uint64_t limit;
int ret = -ENOMEM;
@@ -479,6 +480,15 @@ static int ttm_mem_global_reserve(struct ttm_mem_global 
*glob,
struct ttm_mem_zone *zone;
 
spin_lock(>lock);
+   /*
+* to cover two special cases:
+* a. if serving page_fault allow reservation anyway since
+* it already allocated system pages. Otherwise it will trigger OOM.
+* b. if serving suspend, allow reservation anyway as well.
+*/
+   if (ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC)
+   goto force_reserve;
+
for (i = 0; i < glob->num_zones; ++i) {
zone = glob->zones[i];
if (single_zone && zone != single_zone)
@@ -491,6 +501,7 @@ static int ttm_mem_global_reserve(struct ttm_mem_global 
*glob,
goto out_unlock;
}
 
+force_reserve:
if (reserve) {
for (i = 0; i < glob->num_zones; ++i) {
zone = glob->zones[i];
@@ -516,9 +527,8 @@ static int ttm_mem_global_alloc_zone(struct ttm_mem_global 
*glob,
 {
int count = TTM_MEMORY_ALLOC_RETRIES;
 
-   while (unlikely(ttm_mem_global_reserve(glob,
-  single_zone,
-  memory, true)
+   while (unlikely(ttm_mem_global_reserve(glob, single_zone,
+  memory, true, ctx)
!= 0)) {
if (ctx->no_wait_gpu)
return -ENOMEM;
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index b122f6e..354e0e1 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -944,7 +944,6 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
i = 0;
 
type = ttm_to_type(ttm->page_flags, ttm->caching_state);
-
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
if (ttm->page_flags & TTM_PAGE_FLAG_DMA32)
goto skip_huge;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 872ff6c..2142639 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -278,7 +278,9 @@ struct ttm_operation_ctx {
 };
 
 /* Allow eviction of reserved BOs */
-#define TTM_OPT_FLAG_ALLOW_RES_EVICT   0x1
+#define 

[drm] fc71681342: BUG:unable_to_handle_kernel

[kernel test robot]

FYI, we noticed the following commit (built with gcc-4.9):

commit: fc7168134273b29c0bd2e2fcdf5fdc286154a042 ("drm: Multiple Null pointer 
dereference [null-pointer-deref] (CWE 476) problems:")
url: 
https://github.com/0day-ci/linux/commits/Joe-Moriarty/drm-Multiple-Null-pointer-dereference-null-pointer-deref-CWE-476-problems/20180209-061841
base: git://people.freedesktop.org/~airlied/linux.git drm-next

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -m 420M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | 24b8ef699e | fc71681342 |
+--+++
| boot_successes   | 8  | 0  |
| boot_failures| 0  | 16 |
| BUG:unable_to_handle_kernel  | 0  | 16 |
| Oops:#[##]   | 0  | 16 |
| EIP:drm_debugfs_create_files | 0  | 16 |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 16 |
+--+++



[   21.192567] BUG: unable to handle kernel NULL pointer dereference at 0014
[   21.193562] IP: drm_debugfs_create_files+0x53/0x1b0
[   21.194252] *pde =  
[   21.194669] Oops:  [#1] PREEMPT SMP
[   21.195193] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.15.0-rc8-01510-gfc71681 #145
[   21.196288] EIP: drm_debugfs_create_files+0x53/0x1b0
[   21.197035] EFLAGS: 00210206 CPU: 0
[   21.197564] EAX: 1000 EBX:  ECX: 7808a801 EDX: 8e362038
[   21.198460] ESI: 904f9d88 EDI: 7adfa7e0 EBP: 782b9db0 ESP: 782b9d84
[   21.199369]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
[   21.200085] CR0: 80050033 CR2: 0014 CR3: 040de000 CR4: 06d0
[   21.200508] Call Trace:
[   21.200508]  ? drm_debugfs_init+0x89/0x2a0
[   21.200508]  ? pci_read+0x23/0x30
[   21.200508]  ? pci_read_config_byte+0x5d/0x70
[   21.200508]  ? drm_minor_register+0x6f/0x140
[   21.200508]  ? drm_dev_register+0x2e/0x2b0
[   21.200508]  ? drm_get_pci_dev+0x109/0x260
[   21.200508]  ? bochs_pci_probe+0xe0/0x130
[   21.200508]  ? pci_device_probe+0x10e/0x1d0
[   21.200508]  ? driver_probe_device+0x464/0x500
[   21.200508]  ? __driver_attach+0x179/0x180
[   21.200508]  ? driver_probe_device+0x500/0x500
[   21.200508]  ? bus_for_each_dev+0x58/0xb0
[   21.200508]  ? driver_attach+0x19/0x20
[   21.200508]  ? driver_probe_device+0x500/0x500
[   21.200508]  ? bus_add_driver+0x1a7/0x360
[   21.200508]  ? driver_register+0xb0/0x1a0
[   21.200508]  ? qxl_init+0x50/0x50
[   21.200508]  ? __pci_register_driver+0x50/0x60
[   21.200508]  ? bochs_init+0x44/0x46
[   21.200508]  ? do_one_initcall+0x9b/0x1a2
[   21.200508]  ? parse_args+0x1d0/0x2e0
[   21.200508]  ? kernel_init_freeable+0xce/0x1ab
[   21.200508]  ? kernel_init_freeable+0xeb/0x1ab
[   21.200508]  ? rest_init+0xb0/0xb0
[   21.200508]  ? kernel_init+0xe/0x1b0
[   21.200508]  ? rest_init+0xb0/0xb0
[   21.200508]  ? ret_from_fork+0x2b/0x40
[   21.200508] Code: 89 c7 c7 45 f0 00 00 00 00 8b 45 08 83 c0 1c 89 45 e8 8b 
45 08 83 c0 14 89 45 e4 eb 35 8d 74 26 00 8d bc 27 00 00 00 00 8b 5d d8 <8b> 53 
14 8b 9a c0 00 00 00 21 c3 39 c3 74 1f ff 05 e8 29 c4 7b
[   21.200508] EIP: drm_debugfs_create_files+0x53/0x1b0 SS:ESP: 0068:782b9d84
[   21.200508] CR2: 0014
[   21.200508] ---[ end trace 8c335b4abb722b1c ]---


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
lkp
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.15.0-rc8 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2

RE: [PATCH 3/4] drm/ttm: add input parameter force_alloc for ttm_bo_evict_mm

[He, Roger]

I can't think of an use case when we don't want this to succeed.

That is true. seems I can simplify more here.

Thanks
Roger(Hongbo.He)
-Original Message-
From: Koenig, Christian 
Sent: Thursday, February 08, 2018 8:58 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/4] drm/ttm: add input parameter force_alloc for 
ttm_bo_evict_mm

Am 08.02.2018 um 10:06 schrieb Roger He:
> if true, allocate TTM pages regardless of zone global memory account 
> limit. For suspend, We should avoid TTM memory allocate failure then 
> result in suspend failure.

Why the extra parameter for amdgpu_bo_evict_vram ?

I can't think of an use case when we don't want this to succeed.

Christian.

>
> Signed-off-by: Roger He 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c |  2 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  4 ++--
>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |  4 ++--
>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |  2 +-
>   drivers/gpu/drm/nouveau/nouveau_drm.c   |  2 +-
>   drivers/gpu/drm/qxl/qxl_object.c|  4 ++--
>   drivers/gpu/drm/radeon/radeon_device.c  |  6 +++---
>   drivers/gpu/drm/radeon/radeon_object.c  |  5 +++--
>   drivers/gpu/drm/radeon/radeon_object.h  |  3 ++-
>   drivers/gpu/drm/ttm/ttm_bo.c| 16 ++--
>   drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  6 +++---
>   include/drm/ttm/ttm_bo_api.h|  5 -
>   12 files changed, 34 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index ee76b46..59ee12c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -763,7 +763,7 @@ static int amdgpu_debugfs_evict_vram(struct seq_file *m, 
> void *data)
>   struct drm_device *dev = node->minor->dev;
>   struct amdgpu_device *adev = dev->dev_private;
>   
> - seq_printf(m, "(%d)\n", amdgpu_bo_evict_vram(adev));
> + seq_printf(m, "(%d)\n", amdgpu_bo_evict_vram(adev, true));
>   return 0;
>   }
>   
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index e3fa3d7..3c5f9ca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2168,7 +2168,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool 
> suspend, bool fbcon)
>   }
>   }
>   /* evict vram memory */
> - amdgpu_bo_evict_vram(adev);
> + amdgpu_bo_evict_vram(adev, true);
>   
>   amdgpu_fence_driver_suspend(adev);
>   
> @@ -2178,7 +2178,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool 
> suspend, bool fbcon)
>* This second call to evict vram is to evict the gart page table
>* using the CPU.
>*/
> - amdgpu_bo_evict_vram(adev);
> + amdgpu_bo_evict_vram(adev, true);
>   
>   pci_save_state(dev->pdev);
>   if (suspend) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index 0338ef6..db813f9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -803,14 +803,14 @@ int amdgpu_bo_unpin(struct amdgpu_bo *bo)
>   return r;
>   }
>   
> -int amdgpu_bo_evict_vram(struct amdgpu_device *adev)
> +int amdgpu_bo_evict_vram(struct amdgpu_device *adev, bool 
> +force_alloc)
>   {
>   /* late 2.6.33 fix IGP hibernate - we need pm ops to do this correct */
>   if (0 && (adev->flags & AMD_IS_APU)) {
>   /* Useless to evict on IGP chips */
>   return 0;
>   }
> - return ttm_bo_evict_mm(>mman.bdev, TTM_PL_VRAM);
> + return ttm_bo_evict_mm(>mman.bdev, TTM_PL_VRAM, force_alloc);
>   }
>   
>   static const char *amdgpu_vram_names[] = { diff --git 
> a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> index c2b02f5..6724cdc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> @@ -227,7 +227,7 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32 
> domain,
>u64 min_offset, u64 max_offset,
>u64 *gpu_addr);
>   int amdgpu_bo_unpin(struct amdgpu_bo *bo); -int 
> amdgpu_bo_evict_vram(struct amdgpu_device *adev);
> +int amdgpu_bo_evict_vram(struct amdgpu_device *adev, bool 
> +force_alloc);
>   int amdgpu_bo_init(struct amdgpu_device *adev);
>   void amdgpu_bo_fini(struct amdgpu_device *adev);
>   int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo, diff --git 
> a/drivers/gpu/drm/nouveau/nouveau_drm.c 
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 8d4a5be..c9627ef 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -702,7 +702,7 @@ 

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #16 from Matthew Scheirer  ---
I get this as well with a 290 on 4.15 ONLY when DC is enabled. Its a dirty
enough taint to leave btrfs volumes in inconsistent states so its straight
crashing the kernel.

Feb 08 17:06:08 system kernel: RSP: 002b:7f56c62fc1a8 EFLAGS: 0246
Feb 08 17:06:08 system kernel: amdgpu :01:00.0: swiotlb buffer is full (sz:
2097152 bytes)
Feb 08 17:06:08 system kernel: swiotlb: coherent allocation failed for device
:01:00.0 size=2097152
Feb 08 17:06:08 system kernel: CPU: 5 PID: 2216 Comm: Compositor Tainted: G
  O 4.15.1-2-ARCH #1
Feb 08 17:06:08 system kernel: Hardware name: ASUS All Series/Z87I-DELUXE, BIOS
1204 11/26/2014
Feb 08 17:06:08 system kernel: Call Trace:
Feb 08 17:06:08 system kernel:  dump_stack+0x5c/0x85
Feb 08 17:06:08 system kernel:  swiotlb_alloc_coherent+0xe0/0x150
Feb 08 17:06:08 system kernel:  ttm_dma_pool_get_pages+0x1f3/0x5c0 [ttm]
Feb 08 17:06:08 system kernel:  ttm_dma_populate+0x24a/0x340 [ttm]
Feb 08 17:06:08 system kernel:  ttm_tt_bind+0x29/0x60 [ttm]
Feb 08 17:06:08 system kernel:  ttm_bo_handle_move_mem+0x5da/0x610 [ttm]
Feb 08 17:06:08 system kernel:  ttm_bo_validate+0x135/0x150 [ttm]
Feb 08 17:06:08 system kernel:  ttm_bo_init_reserved+0x3a7/0x480 [ttm]
Feb 08 17:06:08 system kernel:  amdgpu_bo_do_create+0x1b4/0x420 [amdgpu]
Feb 08 17:06:08 system kernel:  ? amdgpu_fill_buffer+0x310/0x310 [amdgpu]
Feb 08 17:06:08 system kernel:  amdgpu_bo_create+0x50/0x210 [amdgpu]
Feb 08 17:06:08 system kernel:  ? ttm_eu_backoff_reservation+0x4d/0x70 [ttm]
Feb 08 17:06:08 system kernel:  amdgpu_gem_object_create+0x7f/0x110 [amdgpu]
Feb 08 17:06:08 system kernel:  amdgpu_gem_create_ioctl+0x1e6/0x280 [amdgpu]
Feb 08 17:06:08 system kernel:  ? page_add_file_rmap+0x11/0x140
Feb 08 17:06:08 system kernel:  ? amdgpu_gem_object_close+0x1e0/0x1e0 [amdgpu]
Feb 08 17:06:08 system kernel:  drm_ioctl_kernel+0x5b/0xb0 [drm]
Feb 08 17:06:08 system kernel:  drm_ioctl+0x2d5/0x370 [drm]
Feb 08 17:06:08 system kernel:  ? amdgpu_gem_object_close+0x1e0/0x1e0 [amdgpu]
Feb 08 17:06:08 system kernel:  ? __handle_mm_fault+0xd30/0x1260
Feb 08 17:06:08 system kernel:  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
Feb 08 17:06:08 system kernel:  do_vfs_ioctl+0xa4/0x630
Feb 08 17:06:08 system kernel:  ? __do_page_fault+0x29d/0x500
Feb 08 17:06:08 system kernel:  ? SyS_futex+0x12d/0x180
Feb 08 17:06:08 system kernel:  SyS_ioctl+0x74/0x80
Feb 08 17:06:08 system kernel:  ? do_page_fault+0x32/0x110
Feb 08 17:06:08 system kernel:  entry_SYSCALL_64_fastpath+0x20/0x83
Feb 08 17:06:08 system kernel: RIP: 0033:0x7f56f7570d87

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

[PATCH 3/3] drm/radeon: only enable swiotlb path when need v2

[Chunming Zhou]

swiotlb expands our card accessing range, but its path always is slower
than ttm pool allocation.
So add condition to use it.
v2: move a bit later

Change-Id: I1802645833155a9cd808913f863981173a82145f
Signed-off-by: Chunming Zhou 
Reviewed-by: Monk Liu 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon.h| 1 +
 drivers/gpu/drm/radeon/radeon_device.c | 2 ++
 drivers/gpu/drm/radeon/radeon_ttm.c| 6 +++---
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d34887873dea..4a2eb409aacc 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2387,6 +2387,7 @@ struct radeon_device {
struct radeon_dummy_pagedummy_page;
boolshutdown;
boolneed_dma32;
+   boolneed_swiotlb;
boolaccel_working;
boolfastfb_working; /* IGP feature*/
boolneeds_reset, in_reset;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 8d3e3d2e0090..7f40c6f7c4dd 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1378,6 +1379,7 @@ int radeon_device_init(struct radeon_device *rdev,
pci_set_consistent_dma_mask(rdev->pdev, DMA_BIT_MASK(32));
pr_warn("radeon: No coherent DMA available\n");
}
+   rdev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
 
/* Registers mapping */
/* TODO: block userspace mapping of io register */
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index a0a839bc39bf..c1e3862a48a4 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -756,7 +756,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm,
 #endif
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (rdev->need_swiotlb && swiotlb_nr_tbl()) {
return ttm_dma_populate(>ttm, rdev->dev, ctx);
}
 #endif
@@ -788,7 +788,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
 #endif
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (rdev->need_swiotlb && swiotlb_nr_tbl()) {
ttm_dma_unpopulate(>ttm, rdev->dev);
return;
}
@@ -1155,7 +1155,7 @@ static int radeon_ttm_debugfs_init(struct radeon_device 
*rdev)
count = ARRAY_SIZE(radeon_ttm_debugfs_list);
 
 #ifdef CONFIG_SWIOTLB
-   if (!swiotlb_nr_tbl())
+   if (!(rdev->need_swiotlb && swiotlb_nr_tbl()))
--count;
 #endif
 
-- 
2.14.1

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

[PATCH 2/3] drm/amdgpu: only enable swiotlb alloc when need v2

[Chunming Zhou]

get the max io mapping address of system memory to see if it is over
our card accessing range.
v2: move checking later

Change-Id: Ibc38dbd34a20af5b4a4b1ed154c14e1c58aa4c55
Signed-off-by: Chunming Zhou 
Reviewed-by: Monk Liu 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c   | 2 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   | 2 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c   | 3 +++
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c   | 2 ++
 6 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 257424dd8a52..627a06185368 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1437,6 +1437,7 @@ struct amdgpu_device {
const struct amdgpu_asic_funcs  *asic_funcs;
boolshutdown;
boolneed_dma32;
+   boolneed_swiotlb;
boolaccel_working;
struct work_struct  reset_work;
struct notifier_block   acpi_nb;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 95f990140f2a..a021de9629ad 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1018,7 +1018,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
}
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (adev->need_swiotlb && swiotlb_nr_tbl()) {
return ttm_dma_populate(>ttm, adev->dev, ctx);
}
 #endif
@@ -1045,7 +1045,7 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
adev = amdgpu_ttm_adev(ttm->bdev);
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (adev->need_swiotlb && swiotlb_nr_tbl()) {
ttm_dma_unpopulate(>ttm, adev->dev);
return;
}
@@ -2007,7 +2007,7 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
count = ARRAY_SIZE(amdgpu_ttm_debugfs_list);
 
 #ifdef CONFIG_SWIOTLB
-   if (!swiotlb_nr_tbl())
+   if (!(adev->need_swiotlb && swiotlb_nr_tbl()))
--count;
 #endif
 
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
index 5eacc0819b66..1945fe842188 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "gmc_v6_0.h"
 #include "amdgpu_ucode.h"
@@ -866,6 +867,7 @@ static int gmc_v6_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
dev_warn(adev->dev, "amdgpu: No coherent DMA available.\n");
}
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
 
r = gmc_v6_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index ce7f484f86f9..761def04f93f 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "cikd.h"
 #include "cik.h"
@@ -1014,6 +1015,7 @@ static int gmc_v7_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
pr_warn("amdgpu: No coherent DMA available\n");
}
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
 
r = gmc_v7_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index f53f3936fd4f..2489be7ad62b 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "gmc_v8_0.h"
 #include "amdgpu_ucode.h"
@@ -1101,6 +1102,7 @@ static int gmc_v8_0_sw_init(void *handle)
 */
adev->need_dma32 = false;
dma_bits = adev->need_dma32 ? 32 : 40;
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
r = pci_set_dma_mask(adev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
adev->need_dma32 = true;
@@ -1112,6 +1114,7 @@ static int gmc_v8_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
pr_warn("amdgpu: No coherent DMA available\n");
}
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
 
r = gmc_v8_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 2c60981d2eec..0f4a9a8575a4 100644
--- 

[PATCH 1/3] drm: add func to get max iomem address v2

[Chunming Zhou]

it will be used to check if the driver needs swiotlb
v2: Don't use inline, instead, move function to drm_memory.c (Mechel Daenzer 
)

Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou 
Reviewed-by: Monk Liu 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/drm_memory.c | 13 +
 include/drm/drm_cache.h  |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index fc0ebd273ef8..7ca500b8c399 100644
--- a/drivers/gpu/drm/drm_memory.c
+++ b/drivers/gpu/drm/drm_memory.c
@@ -149,3 +149,16 @@ void drm_legacy_ioremapfree(struct drm_local_map *map, 
struct drm_device *dev)
iounmap(map->handle);
 }
 EXPORT_SYMBOL(drm_legacy_ioremapfree);
+
+u64 drm_get_max_iomem(void)
+{
+   struct resource *tmp;
+   u64 max_iomem = 0;
+
+   for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
+   max_iomem = max(max_iomem,  tmp->end);
+   }
+
+   return max_iomem;
+}
+EXPORT_SYMBOL(drm_get_max_iomem);
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index beab0f0d0cfb..bfe1639df02d 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -38,6 +38,8 @@
 void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
 void drm_clflush_sg(struct sg_table *st);
 void drm_clflush_virt_range(void *addr, unsigned long length);
+u64 drm_get_max_iomem(void);
+
 
 static inline bool drm_arch_can_wc_memory(void)
 {
-- 
2.14.1

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

[Bug 104963] MSI MoBo A88XM-E35 GPU Trinity A8-5600K (Aruba HD7560D) Boot loop without radeon.dpm=0

[bugzilla-daemon]

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

--- Comment #3 from Will  ---
Chiming in to say I've had the same issue for an extremely frustratingly long
time. I haven't been able to run anything newer than 14.04 on this machine
until today. I can confirm that the radeon.dpm setting doesn't seem to matter,
it's nomodeset that lets me boot.

I've got the same motherboard, an MSI A88XM-345 on the latest (hah, 2014,
E7721AMS V25.6) BIOS, and an A8-6600K APU.

-- 
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 1/9] dt-bindings: add binding for Rockchip hdmi phy using an Innosilicon IP

[Rob Herring]

On Mon, Feb 05, 2018 at 03:34:27PM +0100, Heiko Stuebner wrote:
> From: Zheng Yang 
> 
> The phy is used so far in two Rockchip socs the rk3228 and the rk3328.
> 
> Signed-off-by: Zheng Yang 
> Signed-off-by: Heiko Stuebner 
> ---
>  .../bindings/phy/phy-rockchip-inno-hdmi.txt| 42 
> ++
>  1 file changed, 42 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/phy-rockchip-inno-hdmi.txt

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

Re: [PATCH v1 1/2] dt-bindings/display/panel: otm8009a: Add optional power-supply property

[Rob Herring]

On Mon, Feb 05, 2018 at 10:45:31AM +0100, Philippe Cornu wrote:
> Some boards use a dedicated voltage regulator for this panel.
> Add & document this related optional power-supply property.
> 
> Signed-off-by: Philippe Cornu 
> ---
>  Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [RFC v2 02/10] drm: drm_fourcc: Introduce macro-pixel info to drm_format_info

[Hyun Kwon]

Hi Daniel,

On Tue, 2018-01-30 at 02:27:07 -0800, Daniel Vetter wrote:
> On Thu, Jan 25, 2018 at 06:03:59PM -0800, Hyun Kwon wrote:
> > Multiple pixels can be grouped as a single unit and form a 'macro-pixel'.
> > This is to model formats where multiple pixels are stored together
> > in a specific way, likely byte-algined. For example, if 3 - 10 bit
> > pixels are stored in 32 bit, the 32 bit stroage can be treated as
> > a single macro-pixel with 3 pixels. This aligns non-byte addressable
> > formats with drm core where bpp is expected to be multiple of 8 bit.
> > 
> > Add 'ppm', pixels per macro-pixel, to note how many pixels are grouped
> > in a macro-pixel. 'bpm', bits per macro-pixel, specifies how many bits
> > are in a macro-pixel as there can be some extra padding bits.
> > 
> > Signed-off-by: Hyun Kwon 
> 
> Another thought: If we require that a format description has either cpp or
> the macro-pixel stuff set (but not both), then we could avoid changing the
> entire table. Calculating the width in bytes would first use cpp, and if
> that's 0, try to compute the width using the macro-pixel stuff. And if
> that's also 0, then WARN_ON (since it's a kernel bug).

That certainly will minimize the change. Thanks a lot for suggestion! I will
address your comments in next version.

Thanks,
-hyun

> -Daniel
> 
> > ---
> > v2
> > - Introduce macro-pixel over scaling factors
> > ---
> > ---
> >  drivers/gpu/drm/drm_fourcc.c | 136 
> > +--
> >  include/drm/drm_fourcc.h |   9 +++
> >  2 files changed, 77 insertions(+), 68 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index b891fe0..8fc1e35 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -105,74 +105,74 @@ EXPORT_SYMBOL(drm_get_format_name);
> >  const struct drm_format_info *__drm_format_info(u32 format)
> >  {
> > static const struct drm_format_info formats[] = {
> > -   { .format = DRM_FORMAT_C8,  .depth = 8,  
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGB332,  .depth = 8,  
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGR233,  .depth = 8,  
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_XRGB,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_XBGR,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGBX,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGRX,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_ARGB,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_ABGR,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGBA,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGRA,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_XRGB1555,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_XBGR1555,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGBX5551,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGRX5551,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_ARGB1555,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_ABGR1555,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGBA5551,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGRA5551,.depth = 15, 
> > .num_planes = 1, 

Re: [RFC v2 02/10] drm: drm_fourcc: Introduce macro-pixel info to drm_format_info

[Hyun Kwon]

Hi Daniel,

On Tue, 2018-01-30 at 02:22:40 -0800, Daniel Vetter wrote:
> On Thu, Jan 25, 2018 at 06:03:59PM -0800, Hyun Kwon wrote:
> > Multiple pixels can be grouped as a single unit and form a 'macro-pixel'.
> > This is to model formats where multiple pixels are stored together
> > in a specific way, likely byte-algined. For example, if 3 - 10 bit
> > pixels are stored in 32 bit, the 32 bit stroage can be treated as
> > a single macro-pixel with 3 pixels. This aligns non-byte addressable
> > formats with drm core where bpp is expected to be multiple of 8 bit.
> > 
> > Add 'ppm', pixels per macro-pixel, to note how many pixels are grouped
> > in a macro-pixel. 'bpm', bits per macro-pixel, specifies how many bits
> > are in a macro-pixel as there can be some extra padding bits.
> 
> Should we mandate that macro-pixels are always byte-aligned? This would
> mean cpm for characters per macro-pixel would be more meaningful.
> 

Agreed. That would simplify stuff and be more clean.

> > 
> > Signed-off-by: Hyun Kwon 
> > ---
> > v2
> > - Introduce macro-pixel over scaling factors
> > ---
> > ---
> >  drivers/gpu/drm/drm_fourcc.c | 136 
> > +--
> >  include/drm/drm_fourcc.h |   9 +++
> >  2 files changed, 77 insertions(+), 68 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index b891fe0..8fc1e35 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -105,74 +105,74 @@ EXPORT_SYMBOL(drm_get_format_name);
> >  const struct drm_format_info *__drm_format_info(u32 format)
> >  {
> > static const struct drm_format_info formats[] = {
> > -   { .format = DRM_FORMAT_C8,  .depth = 8,  
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGB332,  .depth = 8,  
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGR233,  .depth = 8,  
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_XRGB,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_XBGR,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGBX,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGRX,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_ARGB,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_ABGR,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGBA,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGRA,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },

[snip]

> + { .format = DRM_FORMAT_NV16,.depth = 0,  
> .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm =  { 1, 1, 0 
> }, .bpm = { 8, 16, 0 }, .hsub = 2, .vsub = 1 },
> > +   { .format = DRM_FORMAT_NV61,.depth = 0,  
> > .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm =  { 1, 1, 0 
> > }, .bpm = { 8, 16, 0 }, .hsub = 2, .vsub = 1 },
> > +   { .format = DRM_FORMAT_NV24,.depth = 0,  
> > .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm =  { 1, 1, 0 
> > }, .bpm = { 8, 16, 0 }, .hsub = 1, .vsub = 1 },
> > +   { .format = DRM_FORMAT_NV42,.depth = 0,  
> > .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm =  { 1, 1, 0 
> > }, .bpm = { 8, 16, 0 }, .hsub = 1, .vsub = 1 },
> > +   { .format = DRM_FORMAT_YUYV,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm =  { 1, 0, 0 
> > }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > +   { .format = DRM_FORMAT_YVYU,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm =  { 1, 0, 0 
> > }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > +   { .format = DRM_FORMAT_UYVY,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm =  { 1, 0, 0 
> > }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > +   { .format = DRM_FORMAT_VYUY,.depth = 0,  
> > .num_planes = 1, .cpp = 

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Rodrigo Vivi]

"Pandiyan, Dhinakaran"  writes:

> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
>> Hi Andy,
>> 
>> thanks for getting involved with PSR and sorry for not replying sooner.
>> 
>> I first saw this patch on that bugzilla entry but only now I stop to
>> really think why I have written the code that way.
>> 
>> So some clarity below.
>> 
>> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
>> > The current PSR code has a two call sites that each schedule delayed
>> > work to activate PSR.  As far as I can tell, each call site intends
>> > to keep PSR inactive for the given amount of time and then allow it
>> > to be activated.
>> >
>> > The call sites are:
>> >
>> >  - intel_psr_enable(), which explicitly states in a comment that
>> >it's trying to keep PSR off a short time after the dispay is
>> >initialized as a workaround.
>> 
>> First of all I really want to kill this call here and remove the
>> FIXME. It was an ugly hack that I added to solve a corner case
>> that was leaving me with blank screens when activating so sooner.
>> 
>> >
>> >  - intel_psr_flush().  There isn't an explcit explanation, but the
>> >intent is presumably to keep PSR off until the display has been
>> >idle for 100ms.
>> 
>> The reason for 100 is kind of ugly-nonsense-empirical value
>> I concluded from VLV/CHV experience.
>> On platforms with HW tracking HW waits few identical frames
>> until really activating PSR. VLV/CHV activation is immediate.
>> But HW is also different and there it seemed that hw needed a
>> few more time before starting the transitions.
>> Furthermore I didn't want to add that so quickly because I didn't
>> want to take the risk of killing battery with software tracking
>> when doing transitions so quickly using software tracking.
>> 
>> >
>> > The current code doesn't actually accomplish either of these goals.
>> > Rather than keeping PSR inactive for the given amount of time, it
>> > will schedule PSR for activation after the given time, with the
>> > earliest target time in such a request winning.
>> 
>> Putting that way I was asking myself how that hack had ever fixed
>> my issue. Because the way you explained here seems obvious that it
>> wouldn't ever fix my bug or any other.
>> 
>> So I applied your patch and it made even more sense (without considering
>> the fact I want to kill the first call anyways).
>> 
>> So I came back, removed your patch and tried to understand how did
>> it ever worked.
>> 
>> So, the thing is that intel_psr_flush will never be really executed
>> if intel_psr_enable wasn't executed. That is guaranteed by:
>> 
>> mutex_lock(_priv->psr.lock);
>>  if (!dev_priv->psr.enabled) {
>> 
>> So, intel_psr_enable will be for sure the first one to schedule the
>> work delayed to the ugly higher delay.
>> 
>> >
>> > In other words, if intel_psr_enable() is immediately followed by
>> > intel_psr_flush(), then PSR will be activated after 100ms even if
>> > intel_psr_enable() wanted a longer delay.  And, if the screen is
>> > being constantly updated so that intel_psr_flush() is called once
>> > per frame at 60Hz, PSR will still be activated once every 100ms.
>> 
>> During this time you are right, many calls of intel_psr_exit
>> coming from flush functions can be called... But none of
>> them will schedule the work with 100 delay.
>> 
>> they will skip on
>> if (!work_busy(_priv->psr.work.work))
>
> Wouldn't work_busy() return false until the work is actually queued
> which is 100ms after calling schedule_delayed_work()?

That's not my understanding of work_busy man.

"work_busy - test whether a work is currently pending or running"

I consider it as pending one...

But yeap... it was a long time ago that I did this so I'm not sure...

>
> For e.g, flushes at 0, 16, 32...96 will have work_busy() returning false
> until 100ms.
>
> The first psr_work will end up getting scheduled at 100ms, which I
> believe is not what we want. 
>
>
> However, I think 
>
>   if (dev_priv->psr.busy_frontbuffer_bits)
>   goto unlock;
>
>   intel_psr_activate(intel_dp);
>
> in psr_work might prevent activate being called at 100ms if an
> invalidate happened to be called before that.
>
>
>
>
>> 
>> So, the higher delayed *hack* will be respected and PSR won't get
>> activated before that.
>> 
>> On the other hand you might ask what if,
>> for some strange reason,
>> (intel_dp->panel_power_cycle_delay * 5) is lesser than 100.
>> Well, on this case this would be ok, because it happens only
>> once and only on gen > 9 where hw tracking will wait the minimal
>> number of frames before the actual transition to PSR.
>> 
>> In either cases I believe we are safe.
>> 
>> Thanks,
>> Rodrigo.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Pandiyan, Dhinakaran]

On Thu, 2018-02-08 at 17:01 -0800, Andy Lutomirski wrote:
> 
> 
> > On Feb 8, 2018, at 4:39 PM, Pandiyan, Dhinakaran 
> >  wrote:
> > 
> > 
> >> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
> >> Hi Andy,
> >> 
> >> thanks for getting involved with PSR and sorry for not replying sooner.
> >> 
> >> I first saw this patch on that bugzilla entry but only now I stop to
> >> really think why I have written the code that way.
> >> 
> >> So some clarity below.
> >> 
> >>> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
> >>> The current PSR code has a two call sites that each schedule delayed
> >>> work to activate PSR.  As far as I can tell, each call site intends
> >>> to keep PSR inactive for the given amount of time and then allow it
> >>> to be activated.
> >>> 
> >>> The call sites are:
> >>> 
> >>> - intel_psr_enable(), which explicitly states in a comment that
> >>>   it's trying to keep PSR off a short time after the dispay is
> >>>   initialized as a workaround.
> >> 
> >> First of all I really want to kill this call here and remove the
> >> FIXME. It was an ugly hack that I added to solve a corner case
> >> that was leaving me with blank screens when activating so sooner.
> >> 
> >>> 
> >>> - intel_psr_flush().  There isn't an explcit explanation, but the
> >>>   intent is presumably to keep PSR off until the display has been
> >>>   idle for 100ms.
> >> 
> >> The reason for 100 is kind of ugly-nonsense-empirical value
> >> I concluded from VLV/CHV experience.
> >> On platforms with HW tracking HW waits few identical frames
> >> until really activating PSR. VLV/CHV activation is immediate.
> >> But HW is also different and there it seemed that hw needed a
> >> few more time before starting the transitions.
> >> Furthermore I didn't want to add that so quickly because I didn't
> >> want to take the risk of killing battery with software tracking
> >> when doing transitions so quickly using software tracking.
> >> 
> >>> 
> >>> The current code doesn't actually accomplish either of these goals.
> >>> Rather than keeping PSR inactive for the given amount of time, it
> >>> will schedule PSR for activation after the given time, with the
> >>> earliest target time in such a request winning.
> >> 
> >> Putting that way I was asking myself how that hack had ever fixed
> >> my issue. Because the way you explained here seems obvious that it
> >> wouldn't ever fix my bug or any other.
> >> 
> >> So I applied your patch and it made even more sense (without considering
> >> the fact I want to kill the first call anyways).
> >> 
> >> So I came back, removed your patch and tried to understand how did
> >> it ever worked.
> >> 
> >> So, the thing is that intel_psr_flush will never be really executed
> >> if intel_psr_enable wasn't executed. That is guaranteed by:
> >> 
> >> mutex_lock(_priv->psr.lock);
> >>if (!dev_priv->psr.enabled) {
> >> 
> >> So, intel_psr_enable will be for sure the first one to schedule the
> >> work delayed to the ugly higher delay.
> >> 
> >>> 
> >>> In other words, if intel_psr_enable() is immediately followed by
> >>> intel_psr_flush(), then PSR will be activated after 100ms even if
> >>> intel_psr_enable() wanted a longer delay.  And, if the screen is
> >>> being constantly updated so that intel_psr_flush() is called once
> >>> per frame at 60Hz, PSR will still be activated once every 100ms.
> >> 
> >> During this time you are right, many calls of intel_psr_exit
> >> coming from flush functions can be called... But none of
> >> them will schedule the work with 100 delay.
> >> 
> >> they will skip on
> >> if (!work_busy(_priv->psr.work.work))
> 
> As below, the first call will.  Then, 100ms later, the work will fire.  Then 
> the next flush will schedule it again, etc.
> 
> > 
> > Wouldn't work_busy() return false until the work is actually queued
> > which is 100ms after calling schedule_delayed_work()?
> > 
> > For e.g, flushes at 0, 16, 32...96 will have work_busy() returning false
> > until 100ms.
> > 
> > The first psr_work will end up getting scheduled at 100ms, which I
> > believe is not what we want. 
> 
> Indeed.  I stuck some printks in and this seems to be what happens.
> 
> > 
> > 
> > However, I think 
> > 
> >if (dev_priv->psr.busy_frontbuffer_bits)
> >goto unlock;
> > 
> >intel_psr_activate(intel_dp);
> > 
> > in psr_work might prevent activate being called at 100ms if an
> > invalidate happened to be called before that.
> > 
> 
> On my system, invalidate is never called.
I noticed the same in console mode with fbdev, there are no invalidates.

>   Even if it were called, that check would only help if we got lucky and the 
> work fired after invalidate and before the subsequent flush.
> 
Agreed. This dependency on invalidate sure looks wrong. 

> > 
> > 
> > 
> >> 
> >> So, the higher delayed *hack* will be respected and PSR won't get
> >> activated before that.
> >> 
> >> On the other hand you 

[Bug 105018] Kernel panic when waking up after screen goes blank.

[bugzilla-daemon]

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

ragnaros39...@yandex.com changed:

   What|Removed |Added

   Keywords||regression
   Priority|medium  |high

-- 
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 105018] Kernel panic when waking up after screen goes blank.

[bugzilla-daemon]

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

Bug ID: 105018
   Summary: Kernel panic when waking up after screen goes blank.
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ragnaros39...@yandex.com

I'm currently running on latest Manjaro XFCE with the 4.15 kernel just
released, and I found that the system would crash when trying to wake up after
the screen went blank.

The system is an AMD Laptop (ASUS ROG STRIX GL702ZC), and the problem is 100%
reproducible with the following steps:

- Lock the screen, leave the screen blank for at least 3-5 minutes.
- Try wake the screen up, like moving the mouse cursor.

At first I did not find the cause, but after looking into the journalctl I was
able to find something that appears to be a kernel panic. It existed since the
beginning, with the 4.14 kernel, and remained unsolved even after upgrading to
4.15 kernel.

Feb 07 11:48:59 linuxsys kernel: BUG: unable to handle kernel NULL pointer
dereference at   (null)
Feb 07 11:48:59 linuxsys kernel: IP: dce110_vblank_set+0x4f/0xb0 [amdgpu]
Feb 07 11:48:59 linuxsys kernel: PGD 7e2ac2067 P4D 7e2ac2067 PUD 7e2a7e067 PMD
0 
Feb 07 11:48:59 linuxsys kernel: Oops:  [#1] PREEMPT SMP NOPTI
Feb 07 11:48:59 linuxsys kernel: Modules linked in: vmw_vsock_vmci_transport
vsock rfcomm fuse bnep vmnet(O) arc4 amdkfd nls_iso8859_1 amd_iommu_v2
nls_cp437 vfat fat amdgpu iwlmvm uvcvideo mac80211 videobuf2_vmalloc
edac_mce_amd btusb vide
Feb 07 11:48:59 linuxsys kernel:  rng_core cryptd pcspkr k10temp i2c_piix4
shpchp battery wmi thermal ac tpm_crb tpm_tis tpm_tis_core video tpm
asus_wireless i2c_hid button acpi_cpufreq sch_fq_codel vmmon(O) vmw_vmci
vboxnetflt(O) vboxnetad
Feb 07 11:48:59 linuxsys kernel: CPU: 15 PID: 1467 Comm: xfwm4 Tainted: G  
 W  O 4.15.0-1-MANJARO #1
Feb 07 11:48:59 linuxsys kernel: Hardware name: ASUSTeK COMPUTER INC.
GL702ZC/GL702ZC, BIOS GL702ZC.303 12/15/2017
Feb 07 11:48:59 linuxsys kernel: RIP: 0010:dce110_vblank_set+0x4f/0xb0 [amdgpu]
Feb 07 11:48:59 linuxsys kernel: RSP: 0018:b4e388c7bbe0 EFLAGS: 00010002
Feb 07 11:48:59 linuxsys kernel: RAX: 9b458850c000 RBX: 0001
RCX: 
Feb 07 11:48:59 linuxsys kernel: RDX:  RSI: 000c
RDI: 
Feb 07 11:48:59 linuxsys kernel: RBP: 9b4b2f4168e0 R08: 
R09: 
Feb 07 11:48:59 linuxsys kernel: R10: 7fff89afe9f0 R11: 9b4b2b86ac40
R12: 9b4b38511a80
Feb 07 11:48:59 linuxsys kernel: R13: c12bbba0 R14: 9b4b281f
R15: 9b4b3ab4cb68
Feb 07 11:48:59 linuxsys kernel: FS:  7f0bdae66980()
GS:9b4b3e9c() knlGS:
Feb 07 11:48:59 linuxsys kernel: CS:  0010 DS:  ES:  CR0:
80050033
Feb 07 11:48:59 linuxsys kernel: CR2:  CR3: 0007d96c8000
CR4: 003406e0
Feb 07 11:48:59 linuxsys kernel: Call Trace:
Feb 07 11:48:59 linuxsys kernel:  amdgpu_dm_set_crtc_irq_state+0x31/0x60
[amdgpu]
Feb 07 11:48:59 linuxsys kernel:  amdgpu_irq_update+0x55/0x90 [amdgpu]
Feb 07 11:48:59 linuxsys kernel:  drm_vblank_enable+0x84/0x100 [drm]
Feb 07 11:48:59 linuxsys kernel:  drm_vblank_get+0x8d/0xb0 [drm]
Feb 07 11:48:59 linuxsys kernel:  drm_wait_vblank_ioctl+0x12a/0x690 [drm]
Feb 07 11:48:59 linuxsys kernel:  ? unix_stream_recvmsg+0x53/0x70
Feb 07 11:48:59 linuxsys kernel:  ? drm_legacy_modeset_ctl_ioctl+0x100/0x100
[drm]
Feb 07 11:48:59 linuxsys kernel:  drm_ioctl_kernel+0x5b/0xb0 [drm]
Feb 07 11:48:59 linuxsys kernel:  drm_ioctl+0x2d5/0x370 [drm]
Feb 07 11:48:59 linuxsys kernel:  ? drm_legacy_modeset_ctl_ioctl+0x100/0x100
[drm]
Feb 07 11:48:59 linuxsys kernel:  ? do_iter_write+0xdc/0x190
Feb 07 11:48:59 linuxsys kernel:  ? vfs_writev+0xb9/0x110
Feb 07 11:48:59 linuxsys kernel:  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
Feb 07 11:48:59 linuxsys kernel:  do_vfs_ioctl+0xa4/0x630
Feb 07 11:48:59 linuxsys kernel:  ? __sys_recvmsg+0x4e/0x90
Feb 07 11:48:59 linuxsys kernel:  ? __sys_recvmsg+0x7d/0x90
Feb 07 11:48:59 linuxsys kernel:  SyS_ioctl+0x74/0x80
Feb 07 11:48:59 linuxsys kernel:  entry_SYSCALL_64_fastpath+0x20/0x83
Feb 07 11:48:59 linuxsys kernel: RIP: 0033:0x7f0bd74b3d87
Feb 07 11:48:59 linuxsys kernel: RSP: 002b:7fff89afea38 EFLAGS: 0246
Feb 07 11:48:59 linuxsys kernel: Code: e8 17 20 04 00 83 e8 4e 0f b6 d0 48 89
d0 48 c1 e0 05 48 01 d0 48 c1 e0 05 49 03 86 60 01 00 00 84 db 48 8b b8 78 02
00 00 74 18 <48> 8b 07 be 02 00 00 00 48 8b 80 d8 00 00 00 e8 6d 43 7e ee 84 
Feb 07 11:48:59 linuxsys kernel: RIP: dce110_vblank_set+0x4f/0xb0 [amdgpu] RSP:
b4e388c7bbe0
Feb 07 11:48:59 linuxsys kernel: CR2: 
Feb 07 11:48:59 linuxsys kernel: ---[ end trace 36522610c84ff0f3 ]---

The cause 

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Andy Lutomirski]

> On Feb 8, 2018, at 4:39 PM, Pandiyan, Dhinakaran 
>  wrote:
> 
> 
>> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
>> Hi Andy,
>> 
>> thanks for getting involved with PSR and sorry for not replying sooner.
>> 
>> I first saw this patch on that bugzilla entry but only now I stop to
>> really think why I have written the code that way.
>> 
>> So some clarity below.
>> 
>>> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
>>> The current PSR code has a two call sites that each schedule delayed
>>> work to activate PSR.  As far as I can tell, each call site intends
>>> to keep PSR inactive for the given amount of time and then allow it
>>> to be activated.
>>> 
>>> The call sites are:
>>> 
>>> - intel_psr_enable(), which explicitly states in a comment that
>>>   it's trying to keep PSR off a short time after the dispay is
>>>   initialized as a workaround.
>> 
>> First of all I really want to kill this call here and remove the
>> FIXME. It was an ugly hack that I added to solve a corner case
>> that was leaving me with blank screens when activating so sooner.
>> 
>>> 
>>> - intel_psr_flush().  There isn't an explcit explanation, but the
>>>   intent is presumably to keep PSR off until the display has been
>>>   idle for 100ms.
>> 
>> The reason for 100 is kind of ugly-nonsense-empirical value
>> I concluded from VLV/CHV experience.
>> On platforms with HW tracking HW waits few identical frames
>> until really activating PSR. VLV/CHV activation is immediate.
>> But HW is also different and there it seemed that hw needed a
>> few more time before starting the transitions.
>> Furthermore I didn't want to add that so quickly because I didn't
>> want to take the risk of killing battery with software tracking
>> when doing transitions so quickly using software tracking.
>> 
>>> 
>>> The current code doesn't actually accomplish either of these goals.
>>> Rather than keeping PSR inactive for the given amount of time, it
>>> will schedule PSR for activation after the given time, with the
>>> earliest target time in such a request winning.
>> 
>> Putting that way I was asking myself how that hack had ever fixed
>> my issue. Because the way you explained here seems obvious that it
>> wouldn't ever fix my bug or any other.
>> 
>> So I applied your patch and it made even more sense (without considering
>> the fact I want to kill the first call anyways).
>> 
>> So I came back, removed your patch and tried to understand how did
>> it ever worked.
>> 
>> So, the thing is that intel_psr_flush will never be really executed
>> if intel_psr_enable wasn't executed. That is guaranteed by:
>> 
>> mutex_lock(_priv->psr.lock);
>>if (!dev_priv->psr.enabled) {
>> 
>> So, intel_psr_enable will be for sure the first one to schedule the
>> work delayed to the ugly higher delay.
>> 
>>> 
>>> In other words, if intel_psr_enable() is immediately followed by
>>> intel_psr_flush(), then PSR will be activated after 100ms even if
>>> intel_psr_enable() wanted a longer delay.  And, if the screen is
>>> being constantly updated so that intel_psr_flush() is called once
>>> per frame at 60Hz, PSR will still be activated once every 100ms.
>> 
>> During this time you are right, many calls of intel_psr_exit
>> coming from flush functions can be called... But none of
>> them will schedule the work with 100 delay.
>> 
>> they will skip on
>> if (!work_busy(_priv->psr.work.work))

As below, the first call will.  Then, 100ms later, the work will fire.  Then 
the next flush will schedule it again, etc.

> 
> Wouldn't work_busy() return false until the work is actually queued
> which is 100ms after calling schedule_delayed_work()?
> 
> For e.g, flushes at 0, 16, 32...96 will have work_busy() returning false
> until 100ms.
> 
> The first psr_work will end up getting scheduled at 100ms, which I
> believe is not what we want. 

Indeed.  I stuck some printks in and this seems to be what happens.

> 
> 
> However, I think 
> 
>if (dev_priv->psr.busy_frontbuffer_bits)
>goto unlock;
> 
>intel_psr_activate(intel_dp);
> 
> in psr_work might prevent activate being called at 100ms if an
> invalidate happened to be called before that.
> 

On my system, invalidate is never called.  Even if it were called, that check 
would only help if we got lucky and the work fired after invalidate and before 
the subsequent flush.

> 
> 
> 
>> 
>> So, the higher delayed *hack* will be respected and PSR won't get
>> activated before that.
>> 
>> On the other hand you might ask what if,
>> for some strange reason,
>> (intel_dp->panel_power_cycle_delay * 5) is lesser than 100.
>> Well, on this case this would be ok, because it happens only
>> once and only on gen > 9 where hw tracking will wait the minimal
>> number of frames before the actual transition to PSR.
>> 
>> In either cases I believe we are safe.
>> 
>> Thanks,
>> Rodrigo.
___
dri-devel mailing list

[RFC][PATCH v3] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

[John Stultz]

This allows for importing buffers allocated from the
hikey and hikey960 gralloc implelementations.

Feedback or comments would be greatly appreciated!

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Change-Id: I81abdd4d1dc7d9f2ef31078c91679b532d3262fd
Signed-off-by: John Stultz 
---
The full patchset I'm testing with can be found here:
https://github.com/johnstultz-work/drm_hwcomposer/commits/drm_hwc

v2:
* Make platformhisi and the generic importer exclusive in the build
* Fixup vendor check
v3:
* Unify format conversions
* Subclass the platformdrmgeneric importer implementation to reduce
  code duplication
* Rework to avoid board specific logic (tweak gralloc to be consistent
  between the two)
---
 Android.mk   |  13 +
 platformdrmgeneric.h |   2 +-
 platformhisi.cpp | 132 +++
 platformhisi.h   |  48 +++
 4 files changed, 194 insertions(+), 1 deletion(-)
 create mode 100644 platformhisi.cpp
 create mode 100644 platformhisi.h

diff --git a/Android.mk b/Android.mk
index ee5b8bf..f37e4c3 100644
--- a/Android.mk
+++ b/Android.mk
@@ -74,7 +74,20 @@ LOCAL_CPPFLAGS += \
-DHWC2_USE_CPP11 \
-DHWC2_INCLUDE_STRINGIFICATION
 
+
+ifeq ($(TARGET_PRODUCT),hikey960)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER
+LOCAL_SRC_FILES += platformhisi.cpp
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc960/
+else
+ifeq ($(TARGET_PRODUCT),hikey)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER
+LOCAL_SRC_FILES += platformhisi.cpp
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc/
+else
 LOCAL_CPPFLAGS += -DUSE_DRM_GENERIC_IMPORTER
+endif
+endif
 
 LOCAL_MODULE := hwcomposer.drm
 LOCAL_MODULE_TAGS := optional
diff --git a/platformdrmgeneric.h b/platformdrmgeneric.h
index 8376580..fbe059b 100644
--- a/platformdrmgeneric.h
+++ b/platformdrmgeneric.h
@@ -35,8 +35,8 @@ class DrmGenericImporter : public Importer {
   int ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t *bo) override;
   int ReleaseBuffer(hwc_drm_bo_t *bo) override;
 
- private:
   uint32_t ConvertHalFormatToDrm(uint32_t hal_format);
+ private:
 
   DrmResources *drm_;
 
diff --git a/platformhisi.cpp b/platformhisi.cpp
new file mode 100644
index 000..5f17c20
--- /dev/null
+++ b/platformhisi.cpp
@@ -0,0 +1,132 @@
+/*
+ * Copyright (C) 2015 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#define LOG_TAG "hwc-platform-hisi"
+
+#include "drmresources.h"
+#include "platform.h"
+#include "platformhisi.h"
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "gralloc_priv.h"
+
+
+namespace android {
+
+#ifdef USE_HISI_IMPORTER
+// static
+Importer *Importer::CreateInstance(DrmResources *drm) {
+  HisiImporter *importer = new HisiImporter(drm);
+  if (!importer)
+return NULL;
+
+  int ret = importer->Init();
+  if (ret) {
+ALOGE("Failed to initialize the hisi importer %d", ret);
+delete importer;
+return NULL;
+  }
+  return importer;
+}
+#endif
+
+HisiImporter::HisiImporter(DrmResources *drm) : DrmGenericImporter(drm), 
drm_(drm) {
+}
+
+HisiImporter::~HisiImporter() {
+}
+
+int HisiImporter::Init() {
+  int ret = hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
+  (const hw_module_t **)_);
+  if (ret) {
+ALOGE("Failed to open gralloc module %d", ret);
+return ret;
+  }
+
+  if (strcasecmp(gralloc_->common.author, "ARM Ltd."))
+ALOGW("Using non-ARM gralloc module: %s/%s\n", gralloc_->common.name,
+  gralloc_->common.author);
+
+  return 0;
+}
+
+EGLImageKHR HisiImporter::ImportImage(EGLDisplay egl_display, buffer_handle_t 
handle) {
+  private_handle_t const *hnd = reinterpret_cast < private_handle_t const 
*>(handle);
+  if (!hnd)
+return NULL;
+  EGLint attr[] = {
+EGL_WIDTH, hnd->width,
+EGL_HEIGHT, hnd->height,
+EGL_LINUX_DRM_FOURCC_EXT, 
(EGLint)DrmGenericImporter::ConvertHalFormatToDrm(hnd->req_format),
+EGL_DMA_BUF_PLANE0_FD_EXT, hnd->share_fd,
+EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
+EGL_DMA_BUF_PLANE0_PITCH_EXT, hnd->byte_stride,
+EGL_NONE,
+  };
+  return eglCreateImageKHR(egl_display, EGL_NO_CONTEXT, 

[Bug 104142] Stack trace in runpm when Tonga card powers down

[bugzilla-daemon]

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

--- Comment #5 from JohnDoe  ---
I ran into this bug when upgrading to 4.15.1. Anything I can do to 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

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Pandiyan, Dhinakaran]

On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
> Hi Andy,
> 
> thanks for getting involved with PSR and sorry for not replying sooner.
> 
> I first saw this patch on that bugzilla entry but only now I stop to
> really think why I have written the code that way.
> 
> So some clarity below.
> 
> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
> > The current PSR code has a two call sites that each schedule delayed
> > work to activate PSR.  As far as I can tell, each call site intends
> > to keep PSR inactive for the given amount of time and then allow it
> > to be activated.
> >
> > The call sites are:
> >
> >  - intel_psr_enable(), which explicitly states in a comment that
> >it's trying to keep PSR off a short time after the dispay is
> >initialized as a workaround.
> 
> First of all I really want to kill this call here and remove the
> FIXME. It was an ugly hack that I added to solve a corner case
> that was leaving me with blank screens when activating so sooner.
> 
> >
> >  - intel_psr_flush().  There isn't an explcit explanation, but the
> >intent is presumably to keep PSR off until the display has been
> >idle for 100ms.
> 
> The reason for 100 is kind of ugly-nonsense-empirical value
> I concluded from VLV/CHV experience.
> On platforms with HW tracking HW waits few identical frames
> until really activating PSR. VLV/CHV activation is immediate.
> But HW is also different and there it seemed that hw needed a
> few more time before starting the transitions.
> Furthermore I didn't want to add that so quickly because I didn't
> want to take the risk of killing battery with software tracking
> when doing transitions so quickly using software tracking.
> 
> >
> > The current code doesn't actually accomplish either of these goals.
> > Rather than keeping PSR inactive for the given amount of time, it
> > will schedule PSR for activation after the given time, with the
> > earliest target time in such a request winning.
> 
> Putting that way I was asking myself how that hack had ever fixed
> my issue. Because the way you explained here seems obvious that it
> wouldn't ever fix my bug or any other.
> 
> So I applied your patch and it made even more sense (without considering
> the fact I want to kill the first call anyways).
> 
> So I came back, removed your patch and tried to understand how did
> it ever worked.
> 
> So, the thing is that intel_psr_flush will never be really executed
> if intel_psr_enable wasn't executed. That is guaranteed by:
> 
> mutex_lock(_priv->psr.lock);
>   if (!dev_priv->psr.enabled) {
> 
> So, intel_psr_enable will be for sure the first one to schedule the
> work delayed to the ugly higher delay.
> 
> >
> > In other words, if intel_psr_enable() is immediately followed by
> > intel_psr_flush(), then PSR will be activated after 100ms even if
> > intel_psr_enable() wanted a longer delay.  And, if the screen is
> > being constantly updated so that intel_psr_flush() is called once
> > per frame at 60Hz, PSR will still be activated once every 100ms.
> 
> During this time you are right, many calls of intel_psr_exit
> coming from flush functions can be called... But none of
> them will schedule the work with 100 delay.
> 
> they will skip on
> if (!work_busy(_priv->psr.work.work))

Wouldn't work_busy() return false until the work is actually queued
which is 100ms after calling schedule_delayed_work()?

For e.g, flushes at 0, 16, 32...96 will have work_busy() returning false
until 100ms.

The first psr_work will end up getting scheduled at 100ms, which I
believe is not what we want. 


However, I think 

if (dev_priv->psr.busy_frontbuffer_bits)
goto unlock;

intel_psr_activate(intel_dp);

in psr_work might prevent activate being called at 100ms if an
invalidate happened to be called before that.




> 
> So, the higher delayed *hack* will be respected and PSR won't get
> activated before that.
> 
> On the other hand you might ask what if,
> for some strange reason,
> (intel_dp->panel_power_cycle_delay * 5) is lesser than 100.
> Well, on this case this would be ok, because it happens only
> once and only on gen > 9 where hw tracking will wait the minimal
> number of frames before the actual transition to PSR.
> 
> In either cases I believe we are safe.
> 
> Thanks,
> Rodrigo.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau 30bpp / deep color status

[Ilia Mirkin]

On Wed, Feb 7, 2018 at 12:01 PM, Ville Syrjälä
 wrote:
> On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote:
>> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote:
>> > In case anyone's curious about 30bpp framebuffer support, here's the
>> > current status:
>> >
>> > Kernel:
>> >
>> > Ben and I have switched the code to using a 256-based LUT for Kepler+,
>> > and I've also written a patch to cause the addfb ioctl to use the
>> > proper format. You can pick this up at:
>> >
>> > https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
>> > https://patchwork.freedesktop.org/patch/202322/
>> >
>> > With these two, you should be able to use "X -depth 30" again on any
>> > G80+ GPU to bring up a screen (as you could in kernel 4.9 and
>> > earlier). However this still has some deficiencies, some of which I've
>> > addressed:
>> >
>> > xf86-video-nouveau:
>> >
>> > DRI3 was broken, and Xv was broken. Patches available at:
>> >
>> > https://github.com/imirkin/xf86-video-nouveau/commits/master
>> >
>> > mesa:
>> >
>> > The NVIDIA hardware (pre-Kepler) can only do XBGR scanout. Further the
>> > nouveau KMS doesn't add XRGB scanout for Kepler+ (although it could).
>> > Mesa was only enabled for XRGB, so I've piped XBGR through all the
>> > same places:
>> >
>> > https://github.com/imirkin/mesa/commits/30bpp
>> >
>> > libdrm:
>> >
>> > For testing, I added a modetest gradient pattern split horizontally.
>> > Top half is 10bpc, bottom half is 8bpc. This is useful for seeing
>> > whether you're really getting 10bpc, or if things are getting
>> > truncated along the way. Definitely hacky, but ... wasn't intending on
>> > upstreaming it anyways:
>> >
>> > https://github.com/imirkin/drm/commit/9b8776f58448b5745675c3a7f5eb2735e3989441
>> >
>> > -
>> >
>> > Results with the patches (tested on a GK208B and a "deep color" TV over 
>> > HDMI):
>> >  - modetest with a 10bpc gradient shows up smoother than an 8bpc
>> > gradient. However it's still dithered to 8bpc, not "real" 10bpc.
>> >  - things generally work in X -- dri2 and dri3, xv, and obviously
>> > regular X rendering / acceleration
>> >  - lots of X software can't handle 30bpp modes (mplayer hates it for
>> > xv and x11 rendering, aterm bails on shading the root pixmap, probably
>> > others)
>> >
>> > I'm also told that with DP, it should actually send the higher-bpc
>> > data over the wire. With HDMI, we're still stuck at 24bpp for now
>> > (although the hardware can do 36bpp as well). This is why my gradient
>> > result above was still dithered.
>> >
>> > Things to do - mostly nouveau specific, but probably some general
>> > infra needed too:
>> >  - Figure out how to properly expose the 1024-sized LUT
>>
>> We have the properties in the kernel. Not sure if x11 could expose it
>> to clients somehow, or would we just have to interpolate the missing
>> bits in the ddx?
>
> Oh, and I think we're going to have to come up with a fancier uapi for
> this stuff because in the future the input points may not be evenly
> spaced (for HDR stuff). Also the hardware may provide various different
> modes for the gamma LUTs with different tradeoffs. So we may even want
> to somehow try to enumerate the different modes and let userspace pick
> the mode that best suits its needs.

That's already the case -- NVIDIA actually has like 5 different LUT
modes on recent chips.

https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml#L25






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

[Bug 92827] Tonga: No Sound over HDMI with connected AV receiver

[bugzilla-daemon]

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

--- Comment #10 from Michael Zapf  ---
I now believe there is a general problem with amdgpu's new DC. 

On another system, without an AV receiver in the chain, my display resolution
is reset to 1368x768 when I turn off the monitor and back on. That's a really
mess (not only my desktop after that). I have to reboot to get the full
resolution again; killing X or unplugging the monitor does not restore it.

Seems as if I have to turn off DC again and wait for a fix. 

I have this issue in my office (RX460) and on my second PC (RX580),
reproduceably, all running openSUSE Tumbleweed, 4.15.1.

-- 
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: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Rodrigo Vivi]

Hi Andy,

thanks for getting involved with PSR and sorry for not replying sooner.

I first saw this patch on that bugzilla entry but only now I stop to
really think why I have written the code that way.

So some clarity below.

On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
> The current PSR code has a two call sites that each schedule delayed
> work to activate PSR.  As far as I can tell, each call site intends
> to keep PSR inactive for the given amount of time and then allow it
> to be activated.
>
> The call sites are:
>
>  - intel_psr_enable(), which explicitly states in a comment that
>it's trying to keep PSR off a short time after the dispay is
>initialized as a workaround.

First of all I really want to kill this call here and remove the
FIXME. It was an ugly hack that I added to solve a corner case
that was leaving me with blank screens when activating so sooner.

>
>  - intel_psr_flush().  There isn't an explcit explanation, but the
>intent is presumably to keep PSR off until the display has been
>idle for 100ms.

The reason for 100 is kind of ugly-nonsense-empirical value
I concluded from VLV/CHV experience.
On platforms with HW tracking HW waits few identical frames
until really activating PSR. VLV/CHV activation is immediate.
But HW is also different and there it seemed that hw needed a
few more time before starting the transitions.
Furthermore I didn't want to add that so quickly because I didn't
want to take the risk of killing battery with software tracking
when doing transitions so quickly using software tracking.

>
> The current code doesn't actually accomplish either of these goals.
> Rather than keeping PSR inactive for the given amount of time, it
> will schedule PSR for activation after the given time, with the
> earliest target time in such a request winning.

Putting that way I was asking myself how that hack had ever fixed
my issue. Because the way you explained here seems obvious that it
wouldn't ever fix my bug or any other.

So I applied your patch and it made even more sense (without considering
the fact I want to kill the first call anyways).

So I came back, removed your patch and tried to understand how did
it ever worked.

So, the thing is that intel_psr_flush will never be really executed
if intel_psr_enable wasn't executed. That is guaranteed by:

mutex_lock(_priv->psr.lock);
if (!dev_priv->psr.enabled) {

So, intel_psr_enable will be for sure the first one to schedule the
work delayed to the ugly higher delay.

>
> In other words, if intel_psr_enable() is immediately followed by
> intel_psr_flush(), then PSR will be activated after 100ms even if
> intel_psr_enable() wanted a longer delay.  And, if the screen is
> being constantly updated so that intel_psr_flush() is called once
> per frame at 60Hz, PSR will still be activated once every 100ms.

During this time you are right, many calls of intel_psr_exit
coming from flush functions can be called... But none of
them will schedule the work with 100 delay.

they will skip on
if (!work_busy(_priv->psr.work.work))

So, the higher delayed *hack* will be respected and PSR won't get
activated before that.

On the other hand you might ask what if,
for some strange reason,
(intel_dp->panel_power_cycle_delay * 5) is lesser than 100.
Well, on this case this would be ok, because it happens only
once and only on gen > 9 where hw tracking will wait the minimal
number of frames before the actual transition to PSR.

In either cases I believe we are safe.

Thanks,
Rodrigo.

>
> Rewrite the code so that it does what was intended.  This adds
> a new function intel_psr_schedule(), which will enable PSR after
> the requested time but no sooner.
>
> Signed-off-by: Andy Lutomirski 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  9 +++--
>  drivers/gpu/drm/i915/i915_drv.h |  4 ++-
>  drivers/gpu/drm/i915/intel_psr.c| 69 
> -
>  3 files changed, 71 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index c65e381b85f3..b67db93f905d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2663,8 +2663,13 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
>   seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
>  dev_priv->psr.busy_frontbuffer_bits);
> - seq_printf(m, "Re-enable work scheduled: %s\n",
> -yesno(work_busy(_priv->psr.work.work)));
> +
> + if (timer_pending(_priv->psr.activate_timer))
> + seq_printf(m, "Activate scheduled: yes, in %ldms\n",
> +(long)(dev_priv->psr.earliest_activate - jiffies) *
> +1000 / HZ);
> + else
> + seq_printf(m, "Re-enable scheduled: no\n");
>
>   if (HAS_DDI(dev_priv)) {
>   

Re: [PATCH v3 4/4] amdgpu/dc/calcs: Support clang option for stack alignment

[Matthias Kaehlcke]

El Thu, Feb 08, 2018 at 04:44:21PM -0500 Harry Wentland ha dit:

> On 2018-02-08 04:03 PM, Harry Wentland wrote:
> > On 2018-02-08 03:53 PM, Matthias Kaehlcke wrote:
> >> calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
> >> a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
> >> instead, which expects as parameter the alignment in bytes, and not a
> >> power of two like -mpreferred-stack-boundary.
> >>
> >> Probe for both compiler options and use the correct one, similar to
> >> what is done in arch/x86/Makefile.
> >>
> >> Signed-off-by: Matthias Kaehlcke 
> > 
> > Series is
> > Reviewed-by: Harry Wentland 
> 
> ... and merged to amd-staging-drm-next.

Thanks!

> I had to resolve a small conflict with patches 1 & 2. Not a big deal but 
> curious what development branch you use. We normally use this for amd-gfx 
> development: 
> https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next 
> (although it might be a bit behind our internal dev tree).

I typically use Linus' tree as base, will try to remember to check
future patches against amd-staging-drm-next.

> >> ---
> >> Changes in v3:
> >> - patch added
> >>
> >> Note to self: if this patterns proliferates further we probably want to
> >> put the evaluation of the correct compiler flag in some common place.
> >>
> >>  drivers/gpu/drm/amd/display/dc/calcs/Makefile | 8 +++-
> >>  1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
> >> b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> >> index af0f452f3c9f..95f332ee3e7e 100644
> >> --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> >> +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> >> @@ -24,7 +24,13 @@
> >>  # It calculates Bandwidth and Watermarks values for HW programming
> >>  #
> >>  
> >> -calcs_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
> >> +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
> >> +  cc_stack_align := -mpreferred-stack-boundary=4
> >> +else ifneq ($(call cc-option, -mstack-alignment=16),)
> >> +  cc_stack_align := -mstack-alignment=16
> >> +endif
> >> +
> >> +calcs_ccflags := -mhard-float -msse $(cc_stack_align)
> >>  
> >>  CFLAGS_dcn_calcs.o := $(calcs_ccflags)
> >>  CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
> >>
> > ___
> > 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 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Laurent Pinchart]

Hi Kieran,

On Thursday, 8 February 2018 01:30:43 EET Kieran Bingham wrote:
> On 07/02/18 21:59, Laurent Pinchart wrote:
> > On Wednesday, 7 February 2018 17:14:09 EET Kieran Bingham wrote:
> >> On 29/01/18 10:26, Laurent Pinchart wrote:
> >>> On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote:
>  The ADV7511 has four 256-byte maps that can be accessed via the main
>  I²C ports. Each map has it own I²C address and acts as a standard slave
>  device on the I²C bus.
>  
>  Allow a device tree node to override the default addresses so that
>  address conflicts with other devices on the same bus may be resolved at
>  the board description level.
>  
>  Signed-off-by: Kieran Bingham 
>  ---
>  
>   .../bindings/display/bridge/adi,adv7511.txt| 10 +-
> >>> 
> >>> I don't mind personally, but device tree maintainers usually ask for DT
> >>> bindings changes to be split to a separate patch.
> >>> 
>   drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36++-
>   3 files changed, 37 insertions(+), 13 deletions(-)
>  
>  diff --git
>  a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>  b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>  index 0047b1394c70..f6bb9f6d3f48 100644
>  --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>  +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>  
>  @@ -70,6 +70,9 @@ Optional properties:
> rather than generate its own timings for HDMI output.
>   - clocks: from common clock binding: reference to the CEC clock.
>   - clock-names: from common clock binding: must be "cec".
>  +- reg-names : Names of maps with programmable addresses.
>  +It can contain any map needing a non-default address.
>  +Possible maps names are : "main", "edid", "cec", "packet"
> >>> 
> >>> Is the reg-names property (and the additional maps) mandatory or
> >>> optional ? If mandatory you should also update the existing DT sources
> >>> that use those bindings.
> >> 
> >> They are currently optional. I do prefer it that way - but perhaps due to
> >> an issue mentioned below we might need to make this driver mandatory ?>> 
> >> 
> >>> If optional you should define which I2C addresses will be used when
> >>> the maps are not specified (and in that case I think we should go for
> >>> the addresses listed as default in the datasheet, which correspond to
> >>> the current driver implementation when the main address is 0x3d/0x7a).
> >> 
> >> The current addresses do not correspond to the datasheet, even when the
> >> implementation main address is set to 0x3d.
> > 
> > Don't they ? The driver currently uses the following (8-bit) I2C
> > addresses:
> > 
> > EDID:   main + 4  = 0x7e (0x3f)
> > Packet: main - 10 = 0x70 (0x38)
> > CEC:main - 2  = 0x78 (0x3c)
> > 
> > Those are the default addresses according to section 4.1 of the ADV7511W
> > programming guide (rev. B), and they match the ones you set in this patch.
> 
> Sorry - I was clearly subtracting 8bit values from a 7bit address in my
> failed assertion, to both you and Archit.

No worries.

> >> Thus, in my opinion - they are currently 'wrong' - but perhaps changing
> >> them is considered breakage too.
> >> 
> >> A particular issue will arise here too - as on this device - when the
> >> device is in low-power mode (after probe, before use) - the maps will
> >> respond on their *hardware default* addresses (the ones implemented in
> >> this patch), and thus consume that address on the I2C bus regardless of
> >> their settings in the driver.
> > 
> > We've discussed this previously and I share you concern. Just to make sure
> > I remember correctly, did all the secondary maps reset to their default
> > addresses, or just the EDID map ?
> 
> The following responds on the bus when programmed at alternative addresses,
> and in low power mode. The responses are all 0, but that's still going to
> conflict with other hardware if it tries to use the 'un-used' addresses.
> 
> Packet (0x38),
> Main (0x39),
> Fixed (set to 0 by software, but shows up at 0x3e)
> and EDID (0x3f).
> 
> So actually it's only the CEC which don't respond when in "low-power-mode".
> 
> As far as I can see, (git grep  -B3 adi,adv75) - The r8a7792-wheat.dts is
> the only instance of a device using 0x3d, which means that Sergei's patch
> changed the behaviour of all the existing devices before that.
> 
> Thus - this patch could be seen to be a 'correction' back to the original
> behaviour for all devices except the Wheat, and possibly devices added after
> Sergei's patch went in.
> 
> However - by my understanding, - any device which has only one ADV75(3,1)+
> should use the hardware defined addresses (the hardware defaults will be
> conflicting on the 

Re: [PATCH v3 4/4] amdgpu/dc/calcs: Support clang option for stack alignment

[Harry Wentland]

On 2018-02-08 04:03 PM, Harry Wentland wrote:
> On 2018-02-08 03:53 PM, Matthias Kaehlcke wrote:
>> calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
>> a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
>> instead, which expects as parameter the alignment in bytes, and not a
>> power of two like -mpreferred-stack-boundary.
>>
>> Probe for both compiler options and use the correct one, similar to
>> what is done in arch/x86/Makefile.
>>
>> Signed-off-by: Matthias Kaehlcke 
> 
> Series is
> Reviewed-by: Harry Wentland 

... and merged to amd-staging-drm-next.

I had to resolve a small conflict with patches 1 & 2. Not a big deal but 
curious what development branch you use. We normally use this for amd-gfx 
development: 
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next (although 
it might be a bit behind our internal dev tree).

Harry

> 
> Harry
> 
>> ---
>> Changes in v3:
>> - patch added
>>
>> Note to self: if this patterns proliferates further we probably want to
>> put the evaluation of the correct compiler flag in some common place.
>>
>>  drivers/gpu/drm/amd/display/dc/calcs/Makefile | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
>> b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
>> index af0f452f3c9f..95f332ee3e7e 100644
>> --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
>> +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
>> @@ -24,7 +24,13 @@
>>  # It calculates Bandwidth and Watermarks values for HW programming
>>  #
>>  
>> -calcs_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
>> +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
>> +cc_stack_align := -mpreferred-stack-boundary=4
>> +else ifneq ($(call cc-option, -mstack-alignment=16),)
>> +cc_stack_align := -mstack-alignment=16
>> +endif
>> +
>> +calcs_ccflags := -mhard-float -msse $(cc_stack_align)
>>  
>>  CFLAGS_dcn_calcs.o := $(calcs_ccflags)
>>  CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
>>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] meson: include headers in root directory in ext_libdrm

[Dylan Baker]

Which is used in wraps.
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 1342a5b3..4aaeb7e1 100644
--- a/meson.build
+++ b/meson.build
@@ -294,7 +294,7 @@ libdrm = shared_library(
 
 ext_libdrm = declare_dependency(
   link_with : libdrm,
-  include_directories : inc_drm,
+  include_directories : [inc_root, inc_drm],
 )
 
 install_headers('libsync.h', 'xf86drm.h', 'xf86drmMode.h')
-- 
2.16.0

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

[PATCH] drm/amdkfd: Delete an error message for a failed memory allocation in kfd_topology_init()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 22:23:57 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index 19ce59028d6b..610e3d4ac575 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -1019,7 +1019,6 @@ int kfd_topology_init(void)
crat_image = kmalloc(image_size, GFP_KERNEL);
if (!crat_image) {
ret = -ENOMEM;
-   pr_err("No memory for allocating CRAT image\n");
goto err;
}
ret = kfd_topology_get_crat_acpi(crat_image, _size);
-- 
2.16.1

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

Re: [PATCH v3 4/4] amdgpu/dc/calcs: Support clang option for stack alignment

[Harry Wentland]

On 2018-02-08 03:53 PM, Matthias Kaehlcke wrote:
> calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
> a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
> instead, which expects as parameter the alignment in bytes, and not a
> power of two like -mpreferred-stack-boundary.
> 
> Probe for both compiler options and use the correct one, similar to
> what is done in arch/x86/Makefile.
> 
> Signed-off-by: Matthias Kaehlcke 

Series is
Reviewed-by: Harry Wentland 

Harry

> ---
> Changes in v3:
> - patch added
> 
> Note to self: if this patterns proliferates further we probably want to
> put the evaluation of the correct compiler flag in some common place.
> 
>  drivers/gpu/drm/amd/display/dc/calcs/Makefile | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
> b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> index af0f452f3c9f..95f332ee3e7e 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> @@ -24,7 +24,13 @@
>  # It calculates Bandwidth and Watermarks values for HW programming
>  #
>  
> -calcs_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
> +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
> + cc_stack_align := -mpreferred-stack-boundary=4
> +else ifneq ($(call cc-option, -mstack-alignment=16),)
> + cc_stack_align := -mstack-alignment=16
> +endif
> +
> +calcs_ccflags := -mhard-float -msse $(cc_stack_align)
>  
>  CFLAGS_dcn_calcs.o := $(calcs_ccflags)
>  CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 0/1] Parfait changes

[Joe Moriarty]

The following patch(s) are bugs found by the static compiler
'Parfait'.  Care was taken to make sure false positive results
were removed from this patchset.

Parfait Overview


https://labs.oracle.com/pls/apex/f?p=labs:49:P49_PROJECT_ID:13

Joe Moriarty (1):
  drm: Multiple Null pointer dereference [null-pointer-deref] (CWE 476)
problems:

 drivers/gpu/drm/drm_dp_mst_topology.c |  8 +---
 drivers/gpu/drm/drm_drv.c | 38 +++
 drivers/gpu/drm/drm_edid.c|  2 ++
 drivers/gpu/drm/drm_vblank.c  |  6 +++---
 4 files changed, 44 insertions(+), 10 deletions(-)

-- 
2.15.0

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

[PATCH v3 3/4] amdgpu/dc/dml: Support clang option for stack alignment

[Matthias Kaehlcke]

DML uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.

Probe for both compiler options and use the correct one, similar to
what is done in arch/x86/Makefile.

Reported-by: Guenter Roeck 
Signed-off-by: Matthias Kaehlcke 
---
Changes in v3:
- adapted use of variable instead of subdir-ccflags-y

 drivers/gpu/drm/amd/display/dc/dml/Makefile | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 96b337a03172..782886cac61c 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -24,7 +24,13 @@
 # It provides the general basic services required by other DAL
 # subcomponents.
 
-dml_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
+ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
+   cc_stack_align := -mpreferred-stack-boundary=4
+else ifneq ($(call cc-option, -mstack-alignment=16),)
+   cc_stack_align := -mstack-alignment=16
+endif
+
+dml_ccflags := -mhard-float -msse $(cc_stack_align)
 
 CFLAGS_display_mode_vba.o := $(dml_ccflags)
 CFLAGS_display_mode_lib.o := $(dml_ccflags)
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 4/4] amdgpu/dc/calcs: Support clang option for stack alignment

[Matthias Kaehlcke]

calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.

Probe for both compiler options and use the correct one, similar to
what is done in arch/x86/Makefile.

Signed-off-by: Matthias Kaehlcke 
---
Changes in v3:
- patch added

Note to self: if this patterns proliferates further we probably want to
put the evaluation of the correct compiler flag in some common place.

 drivers/gpu/drm/amd/display/dc/calcs/Makefile | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
index af0f452f3c9f..95f332ee3e7e 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
@@ -24,7 +24,13 @@
 # It calculates Bandwidth and Watermarks values for HW programming
 #
 
-calcs_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
+ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
+   cc_stack_align := -mpreferred-stack-boundary=4
+else ifneq ($(call cc-option, -mstack-alignment=16),)
+   cc_stack_align := -mstack-alignment=16
+endif
+
+calcs_ccflags := -mhard-float -msse $(cc_stack_align)
 
 CFLAGS_dcn_calcs.o := $(calcs_ccflags)
 CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 1/4] amdgpu/dc/dml: Consolidate redundant CFLAGS

[Matthias Kaehlcke]

Use a variable for common CFLAGS instead of specifying the same flags
for every source file.

Signed-off-by: Matthias Kaehlcke 
---
Changes in v3:
- Use variable for compiler options instead of subdir-ccflags-y

 drivers/gpu/drm/amd/display/dc/dml/Makefile | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 3488af2b5786..96b337a03172 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -24,15 +24,16 @@
 # It provides the general basic services required by other DAL
 # subcomponents.
 
-CFLAGS_display_mode_vba.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_display_mode_lib.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_display_pipe_clocks.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_display_rq_dlg_calc.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_dml1_display_rq_dlg_calc.o := -mhard-float -msse 
-mpreferred-stack-boundary=4
-CFLAGS_display_rq_dlg_helpers.o := -mhard-float -msse 
-mpreferred-stack-boundary=4
-CFLAGS_soc_bounding_box.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_dml_common_defs.o := -mhard-float -msse -mpreferred-stack-boundary=4
+dml_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
 
+CFLAGS_display_mode_vba.o := $(dml_ccflags)
+CFLAGS_display_mode_lib.o := $(dml_ccflags)
+CFLAGS_display_pipe_clocks.o := $(dml_ccflags)
+CFLAGS_display_rq_dlg_calc.o := $(dml_ccflags)
+CFLAGS_dml1_display_rq_dlg_calc.o := $(dml_ccflags)
+CFLAGS_display_rq_dlg_helpers.o := $(dml_ccflags)
+CFLAGS_soc_bounding_box.o := $(dml_ccflags)
+CFLAGS_dml_common_defs.o := $(dml_ccflags)
 
 DML = display_mode_lib.o display_rq_dlg_calc.o \
  display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 2/4] amdgpu/dc/calcs: Consolidate redundant CFLAGS

[Matthias Kaehlcke]

Use a variable for common CFLAGS instead of specifying the same flags
for every source file.

Signed-off-by: Matthias Kaehlcke 
---
Changes in v3:
- patch added

 drivers/gpu/drm/amd/display/dc/calcs/Makefile | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
index 7959e382ed28..af0f452f3c9f 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
@@ -24,9 +24,11 @@
 # It calculates Bandwidth and Watermarks values for HW programming
 #
 
-CFLAGS_dcn_calcs.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_dcn_calc_auto.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_dcn_calc_math.o := -mhard-float -msse -mpreferred-stack-boundary=4 
-Wno-tautological-compare
+calcs_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
+
+CFLAGS_dcn_calcs.o := $(calcs_ccflags)
+CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
+CFLAGS_dcn_calc_math.o := $(calcs_ccflags) -Wno-tautological-compare
 
 BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o
 
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH 3/3] drm/amd/powerplay/hwmgr: Delete an unnecessary return statement in three functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 21:10:58 +0100

The script "checkpatch.pl" pointed information out like the following.

WARNING: void function return statements are not generally useful

Thus remove such a statement in the affected functions.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 3 ---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 1 -
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index 2681c9317d25..e07b32491092 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -653,8 +653,6 @@ void phm_trim_voltage_table_to_fit_state_table(uint32_t 
max_vol_steps,
vol_table->entries[i] = vol_table->entries[i + diff];
 
vol_table->count = max_vol_steps;
-
-   return;
 }
 
 int phm_reset_single_dpm_table(void *table,
@@ -906,7 +904,6 @@ void hwmgr_init_default_caps(struct pp_hwmgr *hwmgr)
 
phm_cap_set(hwmgr->platform_descriptor.platformCaps,

PHM_PlatformCaps_FanSpeedInTableIsRPM);
-   return;
 }
 
 int hwmgr_set_user_specify_caps(struct pp_hwmgr *hwmgr)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 2d55dabc77d4..fcdb3563d860 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -3618,7 +3618,6 @@ static uint32_t vega10_find_highest_dpm_level(
 static void vega10_apply_dal_minimum_voltage_request(
struct pp_hwmgr *hwmgr)
 {
-   return;
 }
 
 static int vega10_get_soc_index_for_max_uclk(struct pp_hwmgr *hwmgr)
-- 
2.16.1

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

[PATCH 2/3] drm/amd/powerplay/hwmgr: Adjust layout for source code from five if statements

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 21:01:24 +0100

The script "checkpatch.pl" pointed information out like the following.

WARNING: Comparisons should place the constant on the right side
of the test
WARNING: else is not generally useful after a break or return

Thus fix the affected source code places.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c   | 33 +++-
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c  | 31 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c |  5 ++--
 3 files changed, 33 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
index c0699b884894..870c517f2057 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
@@ -1772,37 +1772,34 @@ static int cz_read_sensor(struct pp_hwmgr *hwmgr, int 
idx,
return 0;
case AMDGPU_PP_SENSOR_UVD_VCLK:
if (!cz_hwmgr->uvd_power_gated) {
-   if (uvd_index >= CZ_MAX_HARDWARE_POWERLEVELS) {
+   if (uvd_index >= CZ_MAX_HARDWARE_POWERLEVELS)
return -EINVAL;
-   } else {
-   vclk = uvd_table->entries[uvd_index].vclk;
-   *((uint32_t *)value) = vclk;
-   return 0;
-   }
+
+   vclk = uvd_table->entries[uvd_index].vclk;
+   *((uint32_t *)value) = vclk;
+   return 0;
}
*((uint32_t *)value) = 0;
return 0;
case AMDGPU_PP_SENSOR_UVD_DCLK:
if (!cz_hwmgr->uvd_power_gated) {
-   if (uvd_index >= CZ_MAX_HARDWARE_POWERLEVELS) {
+   if (uvd_index >= CZ_MAX_HARDWARE_POWERLEVELS)
return -EINVAL;
-   } else {
-   dclk = uvd_table->entries[uvd_index].dclk;
-   *((uint32_t *)value) = dclk;
-   return 0;
-   }
+
+   dclk = uvd_table->entries[uvd_index].dclk;
+   *((uint32_t *)value) = dclk;
+   return 0;
}
*((uint32_t *)value) = 0;
return 0;
case AMDGPU_PP_SENSOR_VCE_ECCLK:
if (!cz_hwmgr->vce_power_gated) {
-   if (vce_index >= CZ_MAX_HARDWARE_POWERLEVELS) {
+   if (vce_index >= CZ_MAX_HARDWARE_POWERLEVELS)
return -EINVAL;
-   } else {
-   ecclk = vce_table->entries[vce_index].ecclk;
-   *((uint32_t *)value) = ecclk;
-   return 0;
-   }
+
+   ecclk = vce_table->entries[vce_index].ecclk;
+   *((uint32_t *)value) = ecclk;
+   return 0;
}
*((uint32_t *)value) = 0;
return 0;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index ded33ed03f11..2681c9317d25 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -813,24 +813,23 @@ int 
phm_initializa_dynamic_state_adjustment_rule_settings(struct pp_hwmgr *hwmgr
/* initialize vddc_dep_on_dal_pwrl table */
table_size = sizeof(uint32_t) + 4 * sizeof(struct 
phm_clock_voltage_dependency_record);
table_clk_vlt = kzalloc(table_size, GFP_KERNEL);
-
-   if (NULL == table_clk_vlt) {
+   if (!table_clk_vlt)
return -ENOMEM;
-   } else {
-   table_clk_vlt->count = 4;
-   table_clk_vlt->entries[0].clk = PP_DAL_POWERLEVEL_ULTRALOW;
-   table_clk_vlt->entries[0].v = 0;
-   table_clk_vlt->entries[1].clk = PP_DAL_POWERLEVEL_LOW;
-   table_clk_vlt->entries[1].v = 720;
-   table_clk_vlt->entries[2].clk = PP_DAL_POWERLEVEL_NOMINAL;
-   table_clk_vlt->entries[2].v = 810;
-   table_clk_vlt->entries[3].clk = PP_DAL_POWERLEVEL_PERFORMANCE;
-   table_clk_vlt->entries[3].v = 900;
-   if (pptable_info != NULL)
-   pptable_info->vddc_dep_on_dal_pwrl = table_clk_vlt;
-   hwmgr->dyn_state.vddc_dep_on_dal_pwrl = table_clk_vlt;
-   }
 
+   table_clk_vlt->count = 4;
+   table_clk_vlt->entries[0].clk = PP_DAL_POWERLEVEL_ULTRALOW;
+   table_clk_vlt->entries[0].v = 0;
+   table_clk_vlt->entries[1].clk = PP_DAL_POWERLEVEL_LOW;
+   table_clk_vlt->entries[1].v = 720;

[PATCH 1/3] drm/amd/powerplay/hwmgr: Delete an error message for a failed memory allocation in three functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 20:32:39 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 4 +---
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 1 -
 drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 4 +---
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
index b314d09d41af..c0699b884894 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
@@ -286,10 +286,8 @@ static int cz_init_dynamic_state_adjustment_rule_settings(
struct phm_clock_voltage_dependency_table *table_clk_vlt =
kzalloc(table_size, GFP_KERNEL);
 
-   if (NULL == table_clk_vlt) {
-   pr_err("Can not allocate memory!\n");
+   if (!table_clk_vlt)
return -ENOMEM;
-   }
 
table_clk_vlt->count = 8;
table_clk_vlt->entries[0].clk = PP_DAL_POWERLEVEL_0;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index 0229f774f7a9..ded33ed03f11 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -815,7 +815,6 @@ int 
phm_initializa_dynamic_state_adjustment_rule_settings(struct pp_hwmgr *hwmgr
table_clk_vlt = kzalloc(table_size, GFP_KERNEL);
 
if (NULL == table_clk_vlt) {
-   pr_err("Can not allocate space for vddc_dep_on_dal_pwrl! \n");
return -ENOMEM;
} else {
table_clk_vlt->count = 4;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
index 569073e3a5a1..967b93e56113 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
@@ -107,10 +107,8 @@ static int rv_init_dynamic_state_adjustment_rule_settings(
struct phm_clock_voltage_dependency_table *table_clk_vlt =
kzalloc(table_size, GFP_KERNEL);
 
-   if (NULL == table_clk_vlt) {
-   pr_err("Can not allocate memory!\n");
+   if (!table_clk_vlt)
return -ENOMEM;
-   }
 
table_clk_vlt->count = 8;
table_clk_vlt->entries[0].clk = PP_DAL_POWERLEVEL_0;
-- 
2.16.1

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

[PATCH 0/3] drm/amd/powerplay/hwmgr: Adjustments for eight function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 21:37:42 +0100

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete an error message for a failed memory allocation in three functions
  Adjust layout for source code from five if statements
  Delete an unnecessary return statement in three functions

 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 37 ++
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 35 +---
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c   |  5 +--
 drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c |  4 +--
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c |  1 -
 5 files changed, 35 insertions(+), 47 deletions(-)

-- 
2.16.1

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

[Bug 104919] R9285 4.17-wip locks/vmfaults since drm/amdgpu: revert "drm/amdgpu: use AMDGPU_GEM_CREATE_VRAM_CLEARED for VM PD/PTs" v2

[bugzilla-daemon]

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

Andy Furniss  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Andy Furniss  ---
Fix is in affected kernels.

-- 
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 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly

[Maxime Ripard]

On Wed, Feb 07, 2018 at 01:49:59PM +0100, Giulio Benetti wrote:
> Hi,
> 
> Il 07/02/2018 11:39, Maxime Ripard ha scritto:
> > On Wed, Jan 24, 2018 at 08:37:28PM +0100, Giulio Benetti wrote:
> > Also, how was it tested? This seems quite weird that we haven't caught
> > that one sooner, and I'm a bit worried about the possible regressions
> > here.
> 
>  It sounds really strange to me too,
>  because everybody under uboot use "sync:3"(HIGH).
>  I will retry to measure,
>  unfortunately at home I don't have a scope,
>  but I think I'm going to have one soon, because of this. :)
> >>>
> >>> Here I am with scope captures and tcon0 registers dump:
> >>> tcon0_regs => https://pasteboard.co/H4r8Zcs.png
> >>> dclk_d0 => https://pasteboard.co/H4r8QRe.png
> >>> dclk_de => https://pasteboard.co/H4r8zh4R.png
> >>> dclk_vsnc => https://pasteboard.co/H4r8Hye.png
> >>>
> >>> As you can see circled in reg on registers,
> >>> TCON0_IO_POL_REG = 0x.
> >>> But on all the waveforms you can see:
> >>> - dclk_d0: clock phase is 0, but it starts with falling edge, otherwise
> >>> the rising front overlaps dclk rising edge(not good), so to me this is
> >>> falling, then I mean it Negative.
> >>> - dclk_de: de pulse is clearly negative, even if register is 0 and its'
> >>> polarity bit is 0.
> >>> - dclk_vsnc: same as dclk_de
> >>> - dclk_hsync: I didn't take scope screenshot but I can assure you it's
> >>> negative.
> >>>
> >>> You can also check all the other registers about TCON0.
> >>>
> >>> Now I proceed testing it on A33, maybe the peripheral is slightly
> >>> different between Axx SoCs, if I find it that way,
> >>> it should be only a check about SoC or peripheral ID,
> >>> and treat polarity as it should be done.
> >>
> >> Here I am with A33 waveforms:
> >> tcon0_regs => https://pasteboard.co/H4rXfN0M.png
> >> dclk_d0 => https://pasteboard.co/H4rVXwy.png
> >> dclk_de => https://pasteboard.co/H4rWDt8.png
> >> dclk_vsnc => https://pasteboard.co/H4rWRACu.png
> >> dclk_hsync => https://pasteboard.co/H4rWK6I.png
> >>
> >> It behaves the same way as A20, so as I mean IO polarity,
> >> all signals(except D0-D23), are inverted.
> >> For A33 I've used A33-OLinuXino.
> >> For A20 our LiNova1.
> > 
> > If you have an A33 handy, you probably want to read that mail:
> > https://lists.freedesktop.org/archives/dri-devel/2017-July/147951.html
> > 
> > Especially the 90-phase part.
> 
> Here is a summary of different SoCs TCON:
> With DCLK_Sel:
> 0x0 => normal phase
> 0x1 => 1/3 phase
> 0x2 => 2/3 phase
> 
> A10, A20

Have you tested the option 4 and 5 there too?

> With DCLK_Sel:
> 0x0 => normal phase
> 0x1 => 1/3 phase
> 0x2 => 2/3 phase
> 0x5 => DCLK/2 phase 0
> 0x4 => DCLK/2 phase 90
> 
> A31, A31s, A33, A80, A83T

Ok, great, so Chen-Yu was right :)

I guess the option 5 (DCLK/2 phase 0) is still to early, just like
you've shown in the previous captures?

> Also I've found that TCON1 has not this feature,
> nor first, nor second case(at least is not described on user manuals).

At lot of things are not described, unfortunately...

> So I could handle differently according to SoC.
> Unfortunately there is not TCON register keeping IP version,
> so the only way I see is to create a long if-or statement to understand
> which kind of TCON we're using.

You can base that on the compatible, and add a field in the
sun4i_tcon_quirks structure, that will avoid the if statements you
mentionned.

> But what sounds not the best to me, is that DCLK is divided by 2 if
> using phase 90. So we need to reconsider also bitclock driver according
> to this.
> I don't know if it make sense.
> 
> IMHO, I would keep only:
> - As normal => "0x1 => 1/3 phase"

So that would mean sampling at raising edge on this one??

> - As inverted => "0x0 => normal phase"

And falling edge?

If so, and if remember the captures properly, the sampling would occur
right before the rise, and not really around the fall.

Would 2/3 be better here?

> According to scope captures above on both A20 and A33.
> Unfortunately I don't have other boards for the other SoCs to take captures.
> 
> What do you think?

I guess we can make that part applicable to all SoCs, we haven't seen
any significant differences on those part.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


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

[Bug 197327] radeon 0000:01:00.0: failed VCE resume (-110).

[bugzilla-daemon]

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

--- Comment #5 from Eugene (ken20...@ukr.net) ---
Created attachment 274071
  --> https://bugzilla.kernel.org/attachment.cgi?id=274071=edit
dmesg_GA-MA790FX-DQ6

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

[Bug 197327] radeon 0000:01:00.0: failed VCE resume (-110).

[bugzilla-daemon]

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

Eugene (ken20...@ukr.net) changed:

   What|Removed |Added

 CC||ken20...@ukr.net

--- Comment #4 from Eugene (ken20...@ukr.net) ---
$ uname -a
Linux GA-MA790FX-DQ6 4.13.0-32-generic #35~16.04.1-Ubuntu SMP Thu Jan 25
10:13:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ lspci | grep -i vga
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland
PRO [Radeon R7 240/340]

$ dmesg | grep -i "failed VCE resume" -A7 -B20
[1.890001] [TTM] Initializing DMA pool allocator
[1.890025] [drm] radeon: 1024M of VRAM memory ready
[1.890026] [drm] radeon: 2048M of GTT memory ready.
[1.890034] [drm] Loading oland Microcode
[1.890191] [drm] Internal thermal controller with fan control
[1.890268] [drm] probing gen 2 caps for device 1002:5978 = 300d02/0
[1.897887] [drm] radeon: dpm initialized
[1.903155] [drm] Found VCE firmware/feedback version 50.0.1 / 17!
[1.903218] [drm] GART: num cpu pages 524288, num gpu pages 524288
[1.906208] [drm] probing gen 2 caps for device 1002:5978 = 300d02/0
[1.906211] [drm] PCIE gen 2 link speeds already enabled
[1.912329] r8169 :03:00.0 enp3s0: renamed from eth1
[1.921990] [drm] PCIE GART of 2048M enabled (table at 0x001D6000).
[1.922107] radeon :01:00.0: WB enabled
[1.922110] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x4c00 and cpu addr 0x99599f7e5c00
[1.922112] radeon :01:00.0: fence driver on ring 1 use gpu addr
0x4c04 and cpu addr 0x99599f7e5c04
[1.922114] radeon :01:00.0: fence driver on ring 2 use gpu addr
0x4c08 and cpu addr 0x99599f7e5c08
[1.922115] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x4c0c and cpu addr 0x99599f7e5c0c
[1.922116] radeon :01:00.0: fence driver on ring 4 use gpu addr
0x4c10 and cpu addr 0x99599f7e5c10
[1.922515] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x00075a18 and cpu addr 0xb8da41435a18
[2.022790] radeon :01:00.0: failed VCE resume (-110).
[2.022848] firewire_ohci :06:0e.0: added OHCI v1.10 device as card 0, 4
IR + 8 IT contexts, quirks 0x2
[2.022858] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.022859] [drm] Driver supports precise vblank timestamp query.
[2.022860] radeon :01:00.0: radeon: MSI limited to 32-bit
[2.022908] radeon :01:00.0: radeon: using MSI.
[2.022946] [drm] radeon: irq initialized.
[2.026917] ata9.00: ATAPI: Optiarc DVD RW AD-7170A, 1.02, max UDMA/66

P.S. dmesg is in attachment

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

Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector

[Rob Herring]

On Thu, Feb 08, 2018 at 10:27:54AM +0100, Andrzej Hajda wrote:
> On 07.02.2018 22:43, Rob Herring wrote:
> > On Mon, Feb 05, 2018 at 10:06:35AM +0100, Andrzej Hajda wrote:
> >> On 05.02.2018 07:08, Rob Herring wrote:
> >>> On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
>  These bindings allow to describe most known standard USB connectors
>  and it should be possible to extend it if necessary.
>  USB connectors, beside USB can be used to route other protocols,
>  for example UART, Audio, MHL. In such case every device passing data
>  through the connector should have appropriate graph bindings.
> 
>  Signed-off-by: Andrzej Hajda 
>  ---
>  v2:
>  - moved connector type(A,B,C) to compatible string (Rob),
>  - renamed size property to type (Rob),
>  - changed type description to be less confusing (Laurent),
>  - removed vendor specific compatibles (implied by graph port number),
> >>> How so? More below...
> >>>
>  - added requirement of connector being a child of IC (Rob),
>  - removed max-mode (subtly suggested by Rob, it should be detected anyway
>    by USB Controller in runtime, downside is that device is not able to
>    report its real capabilities, maybe better would be to make it 
>  optional(?)),
>  - assigned port numbers to data buses (Rob).
> 
>  Regards
>  Andrzej
> 
>  Signed-off-by: Andrzej Hajda 
>  ---
>   .../bindings/connector/usb-connector.txt   | 48 
>  ++
>   1 file changed, 48 insertions(+)
>   create mode 100644 
>  Documentation/devicetree/bindings/connector/usb-connector.txt
> 
>  diff --git 
>  a/Documentation/devicetree/bindings/connector/usb-connector.txt 
>  b/Documentation/devicetree/bindings/connector/usb-connector.txt
>  new file mode 100644
>  index ..02020f5d760a
>  --- /dev/null
>  +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>  @@ -0,0 +1,48 @@
>  +USB Connector
>  +=
>  +
>  +USB connector node represents physical USB connector. It should be
>  +a child of USB interface controller.
>  +
>  +Required properties:
>  +- compatible: describes type of the connector, must be one of:
>  +"usb-a-connector", "usb-b-connector", "usb-c-connector",
> >>> Nit: one per line.
> >>>
>  +
>  +Optional properties:
>  +- label: symbolic name for the connector
>  +- type: size of the connector, should be specified in case of USB-A, 
>  USB-B
>  +  non-standard (large) connector sizes: "mini", "micro"
>  +
>  +Required nodes:
>  +- any data bus to the connector should be modeled using the OF graph 
>  bindings
>  +  specified in bindings/graph.txt, unless the bus is between parent 
>  node and
>  +  the connector. Since single connector can have multpile data buses 
>  every bus
>  +  has assigned OF graph port number as follows:
>  +0: High Speed (HS), present in all connectors,
>  +1: Super Speed (SS), present in SS capable connectors,
>  +2: Sideband use (SBU), present in USB-C,
>  +3: Mobile High-Definition Link (MHL), present in 11-pin Samsung 
>  micro-USB
> >>> This is un-muxed unlike Type-C where the signals are muxed with USB SS. 
> >>> That makes me think the Samsung connector should have its own compatible 
> >>> string.
> >> Do you mean, sth like:
> >>     connector {
> >>             compatible = "samsung,usb-connector-11pin";
> >>             label = "micro-USB";
> >>             ports {
> >>                     #address-cells = <1>;
> >>                     #size-cells = <0>;
> >>
> >>                     port@3 {
> >>                             reg = <3>;
> >>                             musb_con_mhl_in: endpoint {
> >>                                     remote-endpoint = <_out>;
> >>                             };
> >>                     };
> >>     };
> > Yes, basically.
> >
> >> Or should I add "usb-b-connector" extra compatible and "type" property?
> > type would be micro? I think type and "usb-b-connector" are fine if this 
> > is a superset like a USB3 SS micro connector.
> >
> >> I slightly prefer my approach(less different bindings), but I am also OK
> >> with the above.
> > How do you know it is a Samsung connector then? Just because you have 
> > port 3? I think it is better to be explicit.
> 
> OK.
> 
> >
> >>> Can we go ahead and define the video modes of Type-C? Normally, if 2 
> >>> data streams are mutually exclusive, then they are a single port with 2 
> >>> endpoints. So we'd either have 2 endpoints on port 1 or we stick with 
> >>> port 3 is always video. We can still know what is mutually exclusive 
> >>> based on the compatible. 
> >> I am sorry, I do not understand what you mean. Port 3 is present only in
> >> 11-pin Samsung 

Re: [Freedreno] [PATCH 4/8] drm/msm/gpu: Convert the GPU show function to use the GPU state

[Rob Clark]

On Thu, Feb 8, 2018 at 12:31 PM, Jordan Crouse  wrote:
> Convert the existing GPU show function to use the GPU state to
> dump the information rather than reading it directly from the hardware.
> This will require an additional step to capture the state before
> dumping it for the existing nodes but it will greatly facilitate reusing
> the same code for dumping a previously captured state from a GPU hang.
>
> Signed-off-by: Jordan Crouse 
> ---
>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 11 +--
>  drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 12 +---
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 18 +-
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 30 +-
>  drivers/gpu/drm/msm/adreno/adreno_gpu.h |  4 ++--
>  drivers/gpu/drm/msm/msm_debugfs.c   | 21 +++--
>  drivers/gpu/drm/msm/msm_gpu.h   |  3 ++-
>  7 files changed, 35 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> index c351292..4b9284a 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -410,15 +410,6 @@ static irqreturn_t a3xx_irq(struct msm_gpu *gpu)
> ~0   /* sentinel */
>  };
>
> -#ifdef CONFIG_DEBUG_FS
> -static void a3xx_show(struct msm_gpu *gpu, struct seq_file *m)
> -{
> -   seq_printf(m, "status:   %08x\n",
> -   gpu_read(gpu, REG_A3XX_RBBM_STATUS));
> -   adreno_show(gpu, m);
> -}
> -#endif
> -
>  /* would be nice to not have to duplicate the _show() stuff with printk(): */
>  static void a3xx_dump(struct msm_gpu *gpu)
>  {
> @@ -463,7 +454,7 @@ static struct msm_gpu_state *a3xx_gpu_state_get(struct 
> msm_gpu *gpu)
> .irq = a3xx_irq,
> .destroy = a3xx_destroy,
>  #ifdef CONFIG_DEBUG_FS
> -   .show = a3xx_show,
> +   .show = adreno_show,
>  #endif
> .gpu_state_get = a3xx_gpu_state_get,
> .gpu_state_put = adreno_gpu_state_put,
> diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> index faf5d60..b8dcbb1 100644
> --- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> @@ -454,16 +454,6 @@ static irqreturn_t a4xx_irq(struct msm_gpu *gpu)
> ~0 /* sentinel */
>  };
>
> -#ifdef CONFIG_DEBUG_FS
> -static void a4xx_show(struct msm_gpu *gpu, struct seq_file *m)
> -{
> -   seq_printf(m, "status:   %08x\n",
> -   gpu_read(gpu, REG_A4XX_RBBM_STATUS));
> -   adreno_show(gpu, m);
> -
> -}
> -#endif
> -
>  static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
>  {
> struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
> @@ -550,7 +540,7 @@ static int a4xx_get_timestamp(struct msm_gpu *gpu, 
> uint64_t *value)
> .irq = a4xx_irq,
> .destroy = a4xx_destroy,
>  #ifdef CONFIG_DEBUG_FS
> -   .show = a4xx_show,
> +   .show = adreno_show,
>  #endif
> .gpu_state_get = a4xx_gpu_state_get,
> .gpu_state_put = adreno_gpu_state_put,
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 08f2579..b0910bb 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -1215,22 +1215,6 @@ static struct msm_gpu_state *a5xx_gpu_state_get(struct 
> msm_gpu *gpu)
> return state;
>  }
>
> -#ifdef CONFIG_DEBUG_FS
> -static void a5xx_show(struct msm_gpu *gpu, struct seq_file *m)
> -{
> -   seq_printf(m, "status:   %08x\n",
> -   gpu_read(gpu, REG_A5XX_RBBM_STATUS));
> -
> -   /*
> -* Temporarily disable hardware clock gating before going into
> -* adreno_show to avoid issues while reading the registers
> -*/
> -   a5xx_set_hwcg(gpu, false);
> -   adreno_show(gpu, m);
> -   a5xx_set_hwcg(gpu, true);
> -}
> -#endif
> -
>  static struct msm_ringbuffer *a5xx_active_ring(struct msm_gpu *gpu)
>  {
> struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> @@ -1260,7 +1244,7 @@ static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t 
> *value)
> .irq = a5xx_irq,
> .destroy = a5xx_destroy,
>  #ifdef CONFIG_DEBUG_FS
> -   .show = a5xx_show,
> +   .show = adreno_show,
> .debugfs_init = a5xx_debugfs_init,
>  #endif
> .gpu_busy = a5xx_gpu_busy,
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 35b77f0..af776f1 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -437,38 +437,34 @@ void adreno_gpu_state_put(struct msm_gpu_state *state)
>  }
>
>  #ifdef CONFIG_DEBUG_FS
> -void adreno_show(struct msm_gpu *gpu, struct seq_file 

Re: [PATCH v2 1/2] amdgpu/dc/dml: Consolidate redundant CFLAGS

[Matthias Kaehlcke]

El Thu, Feb 08, 2018 at 09:33:53AM -0500 Harry Wentland ha dit:

> On 2018-02-07 08:51 PM, Matthias Kaehlcke wrote:
> > Use subdir-ccflags instead of specifying the same flags for every source
> > file.
> > 
> > Signed-off-by: Matthias Kaehlcke 
> > Reviewed-by: Guenter Roeck 
> > ---
> > Changes in v2:
> > - added 'Reviewed-by: Guenter Roeck ' tag
> > 
> >  drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 +-
> >  1 file changed, 1 insertion(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
> > b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> > index 3488af2b5786..b8cadf833e71 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> > @@ -24,15 +24,7 @@
> >  # It provides the general basic services required by other DAL
> >  # subcomponents.
> >  
> > -CFLAGS_display_mode_vba.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_display_mode_lib.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_display_pipe_clocks.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_display_rq_dlg_calc.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_dml1_display_rq_dlg_calc.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_display_rq_dlg_helpers.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_soc_bounding_box.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_dml_common_defs.o := -mhard-float -msse -mpreferred-stack-boundary=4
> > -
> > +subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4
> 
> Are you sure this will only apply to dc/dml?
> 
> The way the amdgpu build is setup I've seen this flag apply to all of amdgpu, 
> even if specified in a subdirectories build file. The reason being that 
> amdgpu/Makefile recursively includes all other Makefiles in the module.
> 
> According to kbuild/makefiles.txt this will have effect for the kbuild file 
> where it's present and all subdirectories:
> 
> https://www.kernel.org/doc/Documentation/kbuild/makefiles.txt:
> > subdir-ccflags-y, subdir-asflags-y
> > The two flags listed above are similar to ccflags-y and asflags-y.
> > The difference is that the subdir- variants have effect for the kbuild
> > file where they are present and all subdirectories.
> > Options specified using subdir-* are added to the commandline before
> > the options specified using the non-subdir variants.
> > 
> > Example:
> > subdir-ccflags-y := -Werror

Thanks, I didn't realize the recursive inclusion from amdgpu/Makefile,
in this case using subdir-ccflags-y indeed isn't a good idea.

> For your 2nd patch you probably want to make a dml_cflags variable
> that's set different for clang and gcc, and then still set it for
> all files in DML individually.

Yep, that was my first impulse and then I remembered
subdir-ccflags-y. Will go back to that.

> You'll probably also have to do the same for dc/calcs/Makefile.

Thanks for the heads up!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/6] dt-bindings: Add panel-timing subnode to simple-panel

[Rob Herring]

On Thu, Feb 8, 2018 at 11:48 AM, Sean Paul  wrote:
> This patch adds a new subnode to simple-panel allowing us to override
> the typical timing expressed in the panel's display_timing.
>
> Changes in v2:
>  - Split out the binding into a new patch (Rob)
>  - display-timings is a new section (Rob)
>  - Use the full display-timings subnode instead of picking the timing
>out (Rob/Thierry)
> Changes in v3:
>  - Go back to using the timing subnode directly, but rename to
>panel-timing (Rob)
>
> Cc: Doug Anderson 
> Cc: Eric Anholt 
> Cc: Heiko Stuebner 
> Cc: Jeffy Chen 
> Cc: Rob Herring 
> Cc: Stéphane Marchesin 
> Cc: Thierry Reding 
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Sean Paul 
> ---
>  .../bindings/display/panel/simple-panel.txt| 30 
> ++
>  1 file changed, 30 insertions(+)

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

Re: [PATCH v3 2/6] dt-bindings: Add headings to simple-panel bindings

[Rob Herring]

On Thu, Feb 8, 2018 at 11:48 AM, Sean Paul  wrote:
> In preparation for a new subnode section in a follow-on patch, add
> explicit headings to the existings sections for simple-panel.
>
> Changes in v2:
>  - Added
> Changes in v3:
>  - None
>
> Cc: Doug Anderson 
> Cc: Eric Anholt 
> Cc: Heiko Stuebner 
> Cc: Jeffy Chen 
> Cc: Rob Herring 
> Cc: Stéphane Marchesin 
> Cc: Thierry Reding 
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Sean Paul 
> ---
>  Documentation/devicetree/bindings/display/panel/simple-panel.txt | 4 
>  1 file changed, 4 insertions(+)

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

Re: [PATCH v3 1/6] dt-bindings: Clarify timing subnode use as panel-timing

[Rob Herring]

On Thu, Feb 8, 2018 at 11:48 AM, Sean Paul  wrote:
> Add a note in the documentation explaining when it's appropriate to use
> the display-timings subnode on its own, as well as the preferred name to
> use (panel-timing).
>
> Changes in v3:
>  - Added
>
> Cc: Doug Anderson 
> Cc: Eric Anholt 
> Cc: Heiko Stuebner 
> Cc: Jeffy Chen 
> Cc: Rob Herring 
> Cc: Stéphane Marchesin 
> Cc: Thierry Reding 
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Sean Paul 
> ---
>  Documentation/devicetree/bindings/display/panel/display-timing.txt | 5 +
>  1 file changed, 5 insertions(+)

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

[PATCH] drm_fb_cma_helper: Delete an error message for a failed memory allocation in drm_fbdev_cma_init_with_funcs()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 19:30:06 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 186d00adfb5f..59f0d8dbfa61 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -408,10 +408,9 @@ struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct 
drm_device *dev,
int ret;
 
fbdev_cma = kzalloc(sizeof(*fbdev_cma), GFP_KERNEL);
-   if (!fbdev_cma) {
-   dev_err(dev->dev, "Failed to allocate drm fbdev.\n");
+   if (!fbdev_cma)
return ERR_PTR(-ENOMEM);
-   }
+
fbdev_cma->fb_funcs = funcs;
 
helper = _cma->fb_helper;
-- 
2.16.1

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

[PATCH v1 1/1] drm: Multiple Null pointer dereference [null-pointer-deref] (CWE 476) problems:

[Joe Moriarty]

The Parfait (version 2.1.0) static code analysis tool found multiple NULL
pointer derefernce problems.

- drivers/gpu/drm/drm_dp_mst_topology.c
The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt()
could result in a NULL pointer being returned to port->mstb due to a
failure to allocate memory for port->mstb.

- drivers/gpu/drm/drm_drv.c
Any calls to drm_minor_get_slot() could result in the return of a NULL
pointer when an invalid DRM device type is encountered.  2 helper
functions where added for pointer manipulation (drm_minor_get_slot()
and drm_minor_set_minor()) along with checks for valid pointers for
struct drm_device variables throughout this module.

- drivers/gpu/drm/drm_edid.c
The call to drm_cvt_mode() in function drm_mode_std() for the
HDTV hack resulted in the possibility of accessing a NULL pointer
if drm_mode_std() returned NULL.  A check for this added right after
the call to drm_cvt_mode() in this particular area of code.

- drivers/gpu/drm/drm_vblank.c
Null pointer checks were added to return values from calls to
drm_crtc_from_index().  There is a possibility, however minute, that
crtc->index may not be found when trying to find the struct crtc
from it's assigned index given in drm_crtc_init_with_planes().
3 return checks for NULL where added.

Signed-off-by: Joe Moriarty 
Reviewed-by: Steven Sistare 
---
 drivers/gpu/drm/drm_dp_mst_topology.c |  8 +---
 drivers/gpu/drm/drm_drv.c | 38 +++
 drivers/gpu/drm/drm_edid.c|  2 ++
 drivers/gpu/drm/drm_vblank.c  |  6 +++---
 4 files changed, 44 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 70dcfa58d3c2..ec503d416062 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1082,10 +1082,12 @@ static bool drm_dp_port_setup_pdt(struct 
drm_dp_mst_port *port)
lct = drm_dp_calculate_rad(port, rad);
 
port->mstb = drm_dp_add_mst_branch_device(lct, rad);
-   port->mstb->mgr = port->mgr;
-   port->mstb->port_parent = port;
+   if (port->mstb) {
+   port->mstb->mgr = port->mgr;
+   port->mstb->port_parent = port;
 
-   send_link = true;
+   send_link = true;
+   }
break;
}
return send_link;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9acc1e157813..938eee77f014 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -99,10 +99,36 @@ static struct drm_minor **drm_minor_get_slot(struct 
drm_device *dev,
case DRM_MINOR_CONTROL:
return >control;
default:
+   DRM_ERROR("Error in %s: Invalid dev, type = %d\n",
+ __func__, type);
return NULL;
}
 }
 
+static inline int drm_minor_set_minor(struct drm_device *dev,
+ unsigned int type,
+ struct drm_minor *minor)
+{
+   struct drm_minor **slot = drm_minor_get_slot(dev, type);
+   int retval = -ENODEV;
+
+   if (slot) {
+   retval = 0;
+   *slot = minor;
+   }
+   return retval;
+}
+
+static inline struct drm_minor *drm_minor_get_minor(struct drm_device *dev,
+   unsigned int type)
+{
+   struct drm_minor **slot = drm_minor_get_slot(dev, type);
+
+   if (slot)
+   return *slot;
+   return NULL;
+}
+
 static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
 {
struct drm_minor *minor;
@@ -137,8 +163,9 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned 
int type)
goto err_index;
}
 
-   *drm_minor_get_slot(dev, type) = minor;
-   return 0;
+   r = drm_minor_set_minor(dev, type, minor);
+   if (r == 0)
+   return r;
 
 err_index:
spin_lock_irqsave(_minor_lock, flags);
@@ -155,6 +182,9 @@ static void drm_minor_free(struct drm_device *dev, unsigned 
int type)
unsigned long flags;
 
slot = drm_minor_get_slot(dev, type);
+   if (!slot)
+   return
+
minor = *slot;
if (!minor)
return;
@@ -177,7 +207,7 @@ static int drm_minor_register(struct drm_device *dev, 
unsigned int type)
 
DRM_DEBUG("\n");
 
-   minor = *drm_minor_get_slot(dev, type);
+   minor = drm_minor_get_slot(dev, type);
if (!minor)
return 0;
 
@@ -209,7 +239,7 @@ static void drm_minor_unregister(struct drm_device *dev, 
unsigned int type)
struct drm_minor *minor;
unsigned long flags;
 
-   minor = *drm_minor_get_slot(dev, type);
+   minor = drm_minor_get_slot(dev, type);
if (!minor 

[PATCH] drm/exynos: g2d: Delete an error message for a failed memory allocation in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 18:42:51 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 2b8bf2dd6387..5eb0d3292525 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -286,7 +286,6 @@ static int g2d_init_cmdlist(struct g2d_data *g2d)
 
node = kcalloc(G2D_CMDLIST_NUM, sizeof(*node), GFP_KERNEL);
if (!node) {
-   dev_err(dev, "failed to allocate memory\n");
ret = -ENOMEM;
goto err;
}
@@ -1358,10 +1357,9 @@ int exynos_g2d_exec_ioctl(struct drm_device *drm_dev, 
void *data,
return -EFAULT;
 
runqueue_node = kmem_cache_alloc(g2d->runqueue_slab, GFP_KERNEL);
-   if (!runqueue_node) {
-   dev_err(dev, "failed to allocate memory\n");
+   if (!runqueue_node)
return -ENOMEM;
-   }
+
run_cmdlist = _node->run_cmdlist;
event_list = _node->event_list;
INIT_LIST_HEAD(run_cmdlist);
-- 
2.16.1

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

Re: [PATCH 1/8] include: Move ascii85 functions from i915 to linux/ascii85.h

[Chris Wilson]

Quoting Jordan Crouse (2018-02-08 17:31:50)
> The i915 DRM driver very cleverly used ascii85 encoding for their
> GPU state file. Move the encode functions to a general header file to
> support other drivers that might be interested in the same
> functionality.
> 
> [v2 - Update the API to be cleaner for the caller suggested by
> Chris Wilson]
> 
> Signed-off-by: Jordan Crouse 
> ---
> @@ -545,19 +523,15 @@ static void print_error_obj(struct 
> drm_i915_error_state_buf *m,
>  
> err_compression_marker(m);
> for (page = 0; page < obj->page_count; page++) {
> -   int i, len;
> +   int i;
> +   long len = PAGE_SIZE;

Please keep len = PAGE_SIZE below, so that the computation of len is
grouped. In fact, just ignore the s/int/long/ here as we know it is
bounded to int.

With that,
Reviewed-by: Chris Wilson 

Pick a tree where you want this applied...
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/6] dt-bindings: Clarify timing subnode use as panel-timing

[Sean Paul]

Add a note in the documentation explaining when it's appropriate to use
the display-timings subnode on its own, as well as the preferred name to
use (panel-timing).

Changes in v3:
 - Added

Cc: Doug Anderson 
Cc: Eric Anholt 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 Documentation/devicetree/bindings/display/panel/display-timing.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/display-timing.txt 
b/Documentation/devicetree/bindings/display/panel/display-timing.txt
index 58fa3e48481d..78222ced1874 100644
--- a/Documentation/devicetree/bindings/display/panel/display-timing.txt
+++ b/Documentation/devicetree/bindings/display/panel/display-timing.txt
@@ -80,6 +80,11 @@ The parameters are defined as:
   |  |v|  |   |
   +--+-+--+---+
 
+Note: In addition to being used as subnode(s) of display-timings, the timing
+  subnode may also be used on its own. This is appropriate if only one mode
+  need be conveyed. In this case, the node should be named 'panel-timing'.
+
+
 Example:
 
display-timings {
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 2/6] dt-bindings: Add headings to simple-panel bindings

[Sean Paul]

In preparation for a new subnode section in a follow-on patch, add
explicit headings to the existings sections for simple-panel.

Changes in v2:
 - Added
Changes in v3:
 - None

Cc: Doug Anderson 
Cc: Eric Anholt 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 Documentation/devicetree/bindings/display/panel/simple-panel.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt 
b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index 16d8ff088b7d..45a457ad38f0 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -1,4 +1,8 @@
 Simple display panel
+
+
+panel node
+--
 
 Required properties:
 - power-supply: See panel-common.txt
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 0/6] drm/panel: simple: Add mode support to devicetree

[Sean Paul]

Hello!

Here's v3 of the set. I've reintroduced the single display timing node
in the dt binding from v1, and left the improved docs and patch split
from v2. I've also added a patch to clarify that a single display timing
node should always be named panel-timing, which was feedback from v1.

Cover letter from v1 (was the same in v2) is here:
https://lists.freedesktop.org/archives/dri-devel/2018-February/164886.html

Thanks for the reviews so far,

Sean


Sean Paul (6):
  dt-bindings: Clarify timing subnode use as panel-timing
  dt-bindings: Add headings to simple-panel bindings
  dt-bindings: Add panel-timing subnode to simple-panel
  drm/panel: simple: Add ability to override typical timing
  drm/panel: simple: Use display_timing for lq123p1jx31
  arm64: dts: rockchip: Specify override mode for kevin panel

 .../bindings/display/panel/display-timing.txt  |  5 ++
 .../bindings/display/panel/simple-panel.txt| 34 
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts  | 14 
 drivers/gpu/drm/panel/panel-simple.c   | 94 ++
 4 files changed, 132 insertions(+), 15 deletions(-)

-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 5/6] drm/panel: simple: Use display_timing for lq123p1jx31

[Sean Paul]

Convert the sharp lq123p1jx31 from using a fixed mode to specifying a
display timing with min/typ/max values. This allows us to capture the
timings set forth in the datasheet as well as the additional values that
we've cleared with the display vendor to avoid interference with the
digitizer on the Samsung Chromebook Plus (kevin).

A follow-on patch will specify the override mode for kevin devices.

Changes in v2:
 - None
Changes in v3:
 - None

Cc: Doug Anderson 
Cc: Eric Anholt 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 87488392bca1..6de9c39bc182 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1806,23 +1806,22 @@ static const struct panel_desc sharp_lq101k1ly04 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
 };
 
-static const struct drm_display_mode sharp_lq123p1jx31_mode = {
-   .clock = 252750,
-   .hdisplay = 2400,
-   .hsync_start = 2400 + 48,
-   .hsync_end = 2400 + 48 + 32,
-   .htotal = 2400 + 48 + 32 + 80,
-   .vdisplay = 1600,
-   .vsync_start = 1600 + 3,
-   .vsync_end = 1600 + 3 + 10,
-   .vtotal = 1600 + 3 + 10 + 33,
-   .vrefresh = 60,
-   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+static const struct display_timing sharp_lq123p1jx31_timing = {
+   .pixelclock = { 25275, 25275, 266604720 },
+   .hactive = { 2400, 2400, 2400 },
+   .hfront_porch = { 48, 48, 48 },
+   .hback_porch = { 80, 80, 84 },
+   .hsync_len = { 32, 32, 32 },
+   .vactive = { 1600, 1600, 1600 },
+   .vfront_porch = { 3, 3, 3 },
+   .vback_porch = { 33, 33, 120 },
+   .vsync_len = { 10, 10, 10 },
+   .flags = DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_HSYNC_LOW,
 };
 
 static const struct panel_desc sharp_lq123p1jx31 = {
-   .modes = _lq123p1jx31_mode,
-   .num_modes = 1,
+   .timings = _lq123p1jx31_timing,
+   .num_timings = 1,
.bpc = 8,
.size = {
.width = 259,
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 3/6] dt-bindings: Add panel-timing subnode to simple-panel

[Sean Paul]

This patch adds a new subnode to simple-panel allowing us to override
the typical timing expressed in the panel's display_timing.

Changes in v2:
 - Split out the binding into a new patch (Rob)
 - display-timings is a new section (Rob)
 - Use the full display-timings subnode instead of picking the timing
   out (Rob/Thierry)
Changes in v3:
 - Go back to using the timing subnode directly, but rename to
   panel-timing (Rob)

Cc: Doug Anderson 
Cc: Eric Anholt 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 .../bindings/display/panel/simple-panel.txt| 30 ++
 1 file changed, 30 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt 
b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index 45a457ad38f0..7788b9ce160b 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -12,6 +12,24 @@ Optional properties:
 - enable-gpios: GPIO pin to enable or disable the panel
 - backlight: phandle of the backlight device attached to the panel
 
+panel-timing subnode
+
+
+This optional subnode is for devices which require a mode differing from the
+panel's "typical" display timing as programmed in the simple-panel driver.
+Overriding the driver mode must only be done in the following scenario:
+ - The restrictions motivating the override cannot be applied to the platform's
+   display driver (ie: it must be specific to the device not the platform)
+ - The panel must not have a fixed mode attributed to it in the driver
+ - The panel must provide at list one display_timing range by which the 
override
+   mode can be validated against
+ - The override mode will use the 'typ' values from the panel-timings subnode
+ - You must provide all required properties for the panel-timing subnode
+
+Format information on the panel-timing subnode can be found in
+display-timing.txt.
+
+
 Example:
 
panel: panel {
@@ -22,4 +40,16 @@ Example:
enable-gpios = < 90 0>;
 
backlight = <>;
+
+   panel-timing {
+   clock-frequency = <266604720>;
+   hactive = <2400>;
+   hfront-porch = <48>;
+   hback-porch = <84>;
+   hsync-len = <32>;
+   vactive = <1600>;
+   vfront-porch = <3>;
+   vback-porch = <120>;
+   vsync-len = <10>;
+   };
};
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 4/6] drm/panel: simple: Add ability to override typical timing

[Sean Paul]

This patch adds the ability to override the typical display timing for a
given panel. This is useful for devices which have timing constraints
that do not apply across the entire display driver (eg: to avoid
crosstalk between panel and digitizer on certain laptops). The rules are
as follows:

- panel must not specify fixed mode (since the override mode will
  either be the same as the fixed mode, or we'll be unable to
  check the bounds of the overried)
- panel must specify at least one display_timing range which will be
  used to ensure the override mode fits within its bounds

Changes in v2:
 - Parse the full display-timings node (using the native-mode) (Rob)
Changes in v3:
 - No longer parse display-timings subnode, use panel-timing (Rob)

Cc: Doug Anderson 
Cc: Eric Anholt 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/panel/panel-simple.c | 67 +++-
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5591984a392b..87488392bca1 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -34,6 +34,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 struct panel_desc {
@@ -87,6 +88,8 @@ struct panel_simple {
struct i2c_adapter *ddc;
 
struct gpio_desc *enable_gpio;
+
+   struct drm_display_mode override_mode;
 };
 
 static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
@@ -99,11 +102,22 @@ static int panel_simple_get_fixed_modes(struct 
panel_simple *panel)
struct drm_connector *connector = panel->base.connector;
struct drm_device *drm = panel->base.drm;
struct drm_display_mode *mode;
+   bool has_override = panel->override_mode.type;
unsigned int i, num = 0;
 
if (!panel->desc)
return 0;
 
+   if (has_override) {
+   mode = drm_mode_duplicate(drm, >override_mode);
+   if (mode) {
+   drm_mode_probed_add(connector, mode);
+   num++;
+   } else {
+   dev_err(drm->dev, "failed to add override mode\n");
+   }
+   }
+
for (i = 0; i < panel->desc->num_timings; i++) {
const struct display_timing *dt = >desc->timings[i];
struct videomode vm;
@@ -120,7 +134,7 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
 
mode->type |= DRM_MODE_TYPE_DRIVER;
 
-   if (panel->desc->num_timings == 1)
+   if (panel->desc->num_timings == 1 && !has_override)
mode->type |= DRM_MODE_TYPE_PREFERRED;
 
drm_mode_probed_add(connector, mode);
@@ -291,10 +305,58 @@ static const struct drm_panel_funcs panel_simple_funcs = {
.get_timings = panel_simple_get_timings,
 };
 
+#define PANEL_SIMPLE_BOUNDS_CHECK(to_check, bounds, field) \
+   (to_check->field.typ >= bounds->field.min && \
+to_check->field.typ <= bounds->field.max)
+static void panel_simple_add_override_mode(struct device *dev,
+  struct panel_simple *panel,
+  const struct display_timing *ot)
+{
+   const struct panel_desc *desc = panel->desc;
+   struct videomode vm;
+   int i;
+
+   if (desc->num_modes) {
+   dev_err(dev, "Reject override mode: panel has a fixed mode\n");
+   return;
+   }
+   if (!desc->num_timings) {
+   dev_err(dev, "Reject override mode: no timings specified\n");
+   return;
+   }
+
+   for (i = 0; i < panel->desc->num_timings; i++) {
+   const struct display_timing *dt = >desc->timings[i];
+
+   if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hback_porch) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hsync_len) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vactive) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vfront_porch) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vback_porch) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vsync_len))
+   continue;
+
+   if (ot->flags != dt->flags)
+   continue;
+
+   videomode_from_timing(ot, );
+   drm_display_mode_from_videomode(, >override_mode);
+   panel->override_mode.type |= 

[PATCH v3 6/6] arm64: dts: rockchip: Specify override mode for kevin panel

[Sean Paul]

This patch adds an override mode for kevin devices. The mode increases
both back porches to allow a pixel clock of 2kHz as opposed to the
'typical' value of 252750kHz. This is needed to avoid interference with
the touch digitizer on these laptops.

Changes in v2:
 - Wrap the timing in display-timings node to match binding (Rob/Thierry)
Changes in v3:
 - Unwrap the timing from display-timings and rename panel-timing (Rob)

Cc: Doug Anderson 
Cc: Eric Anholt 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 191a6bcb1704..658411ce37ea 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -98,6 +98,20 @@
backlight = <>;
power-supply = <_disp>;
 
+   panel-timing {
+   clock-frequency = <266604720>;
+   hactive = <2400>;
+   hfront-porch = <48>;
+   hback-porch = <84>;
+   hsync-len = <32>;
+   hsync-active = <0>;
+   vactive = <1600>;
+   vfront-porch = <3>;
+   vback-porch = <120>;
+   vsync-len = <10>;
+   vsync-active = <0>;
+   };
+
ports {
panel_in_edp: endpoint {
remote-endpoint = <_out_panel>;
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH 7/8] drm/msm/adreno: Add ringbuffer data to the GPU state

[Jordan Crouse]

Add the contents of each ringbuffer to the GPU state and dump the
data in the crash file encoded with ascii85. To save space only
the used portions of the ringbuffer are dumped.

Signed-off-by: Jordan Crouse 
---
 Documentation/gpu/drm-msm-crash-dump.txt |  5 
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 40 
 drivers/gpu/drm/msm/msm_gpu.h|  2 ++
 3 files changed, 47 insertions(+)

diff --git a/Documentation/gpu/drm-msm-crash-dump.txt 
b/Documentation/gpu/drm-msm-crash-dump.txt
index ec56640..3f54b44 100644
--- a/Documentation/gpu/drm-msm-crash-dump.txt
+++ b/Documentation/gpu/drm-msm-crash-dump.txt
@@ -22,6 +22,11 @@ ringbuffer:   # Ringbuffer data. There will be a sequence 
for each ringbuffer
retired-fence:  # [decimal] THe last fence retired on the ring
rptr:   # [decimal] The current read pointer (rptr) for the ring
wptr:   # [decimal] The current write pointer (wptr) for the ring
+   size:   # [decimal] The maximum size of the ring programmed in the
+   # hardware
+   data:   # [ascii85] The contents of the ring encoded as ascii85.
+  # Only the unused portions of the ring will be printed (up
+   # to a maximum of 'size' bytes
 registers:# Sets of register values. This section can be used multiple
   # times for different ranges of registers. Each register will be
   # on its own line.
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 920db2e..e9b7b36 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 
 #include "adreno_gpu.h"
 #include "msm_gem.h"
@@ -397,10 +398,29 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
do_gettimeofday(>time);
 
for (i = 0; i < gpu->nr_rings; i++) {
+   int size = 0, j;
+
state->ring[i].fence = gpu->rb[i]->memptrs->fence;
state->ring[i].seqno = gpu->rb[i]->seqno;
state->ring[i].rptr = get_rptr(adreno_gpu, gpu->rb[i]);
state->ring[i].wptr = get_wptr(gpu->rb[i]);
+
+   /*
+* Only copy used parts of the ring buffers (this should save
+* data size for lightly used rings)
+*/
+   for(j = 0; j < MSM_GPU_RINGBUFFER_SZ >> 2; j++)
+   if (gpu->rb[i]->start[j])
+   size = j;
+
+   if (size) {
+   state->ring[i].data = kmalloc((size + 1) << 2, 
GFP_KERNEL);
+   if (state->ring[i].data) {
+   memcpy(state->ring[i].data, gpu->rb[i]->start,
+   (size + 1) << 2);
+   state->ring[i].data_size = (size + 1) << 2;
+   }
+   }
}
 
/* Count the number of registers */
@@ -431,9 +451,13 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
 
 static void adreno_gpu_state_destroy(struct kref *kref)
 {
+   int i;
struct msm_gpu_state *state = container_of(kref,
struct msm_gpu_state, ref);
 
+   for(i = 0; i < ARRAY_SIZE(state->ring); i++)
+   kfree(state->ring[i].data);
+
kfree(state->comm);
kfree(state->cmd);
kfree(state->registers);
@@ -473,6 +497,22 @@ void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state 
*state,
drm_printf(p, "retired-fence: %d\n", state->ring[i].fence);
drm_printf(p, "rptr: %d\n", state->ring[i].rptr);
drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
+   drm_printf(p, "size: %d\n", MSM_GPU_RINGBUFFER_SZ);
+
+   if (state->ring[i].data && state->ring[i].data_size) {
+   u32 *ptr = (u32 *) state->ring[i].data;
+   char out[ASCII85_BUFSZ];
+   long len = ascii85_encode_len(state->ring[i].data_size);
+   int j;
+
+   drm_printf(p, "data: !!ascii85 |\n");
+   drm_printf(p, " ");
+
+   for(j = 0; j < len; j++)
+   drm_printf(p, ascii85_encode(ptr[j], out));
+
+   drm_printf(p, "\n");
+   }
}
 
drm_printf(p, "registers:\n");
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index e65f507..48f7b21 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -190,6 +190,8 @@ struct msm_gpu_state {
u32 seqno;
u32 rptr;
u32 wptr;
+   void *data;
+   int data_size;
} 

[PATCH 8/8] drm/msm/adreno: Add a5xx specific registers for the GPU state

[Jordan Crouse]

HLSQ, SP and TP registers are only accessible from a special
aperture and to make matters worse the aperture is blocked from
the CPU on targets that can support secure rendering. Luckily the
GPU hardware has its own purpose built register dumper that can
access the registers from the aperture.  Add a5xx specific code
to program the crashdumper and retrieve the wayward registers
and dump them for the crash state.

Also, remove a block of registers the regular CPU accessible
list that aren't useful for debug which helps reduce the size
of the crash state file by a goodly amount.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |   8 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |   8 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 235 ++--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  23 ++--
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |   4 +-
 5 files changed, 247 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 4b9284a..6dd2b13 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -420,10 +420,12 @@ static void a3xx_dump(struct msm_gpu *gpu)
 
 static struct msm_gpu_state *a3xx_gpu_state_get(struct msm_gpu *gpu)
 {
-   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+   struct msm_gpu_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
 
-   if (IS_ERR(state))
-   return state;
+   if (!state)
+   return ERR_PTR(-ENOMEM);
+
+   adreno_gpu_state_get(gpu, state);
 
state->rbbm_status = gpu_read(gpu, REG_A3XX_RBBM_STATUS);
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index b8dcbb1..093ca30 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -456,10 +456,12 @@ static irqreturn_t a4xx_irq(struct msm_gpu *gpu)
 
 static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
 {
-   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+   struct msm_gpu_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
 
-   if (IS_ERR(state))
-   return state;
+   if (!state)
+   return ERR_PTR(-ENOMEM);
+
+   adreno_gpu_state_get(gpu, state);
 
state->rbbm_status = gpu_read(gpu, REG_A4XX_RBBM_STATUS);
 
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index b0910bb..764407c 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "msm_gem.h"
 #include "msm_mmu.h"
 #include "a5xx_gpu.h"
@@ -1123,8 +1124,9 @@ static irqreturn_t a5xx_irq(struct msm_gpu *gpu)
0xE800, 0xE806, 0xE810, 0xE89A, 0xE8A0, 0xE8A4, 0xE8AA, 0xE8EB,
0xE900, 0xE905, 0xEB80, 0xEB8F, 0xEBB0, 0xEBB0, 0xEC00, 0xEC05,
0xEC08, 0xECE9, 0xECF0, 0xECF0, 0xEA80, 0xEA80, 0xEA82, 0xEAA3,
-   0xEAA5, 0xEAC2, 0xA800, 0xA8FF, 0xAC60, 0xAC60, 0xB000, 0xB97F,
-   0xB9A0, 0xB9BF, ~0
+   0xEAA5, 0xEAC2, 0xA800, 0xA800, 0xA820, 0xA828, 0xA840, 0xA87D,
+   0XA880, 0xA88D, 0xA890, 0xA8A3, 0xA8D0, 0xA8D8, 0xA8E0, 0xA8F5,
+   0xAC60, 0xAC60, ~0,
 };
 
 static void a5xx_dump(struct msm_gpu *gpu)
@@ -1195,24 +1197,231 @@ static int a5xx_get_timestamp(struct msm_gpu *gpu, 
uint64_t *value)
return 0;
 }
 
+struct a5xx_crashdumper {
+   void *ptr;
+   struct drm_gem_object *bo;
+   u64 iova;
+};
+
+struct a5xx_gpu_state {
+   struct msm_gpu_state base;
+   u32 *hlsqregs;
+};
+
+#define gpu_poll_timeout(gpu, addr, val, cond, interval, timeout) \
+   readl_poll_timeout((gpu)->mmio + ((addr) << 2), val, cond, \
+   interval, timeout)
+
+static int a5xx_crashdumper_init(struct msm_gpu *gpu,
+   struct a5xx_crashdumper *dumper)
+{
+   dumper->ptr = msm_gem_kernel_new_locked(gpu->dev,
+   SZ_1M, MSM_BO_UNCACHED, gpu->aspace,
+   >bo, >iova);
+
+   if (IS_ERR(dumper->ptr))
+   return PTR_ERR(dumper->ptr);
+
+   return 0;
+}
+
+static void a5xx_crashdumper_free(struct msm_gpu *gpu,
+   struct a5xx_crashdumper *dumper)
+{
+   msm_gem_put_iova(dumper->bo, gpu->aspace);
+   msm_gem_put_vaddr(dumper->bo);
+
+   drm_gem_object_unreference(dumper->bo);
+}
+
+static int a5xx_crashdumper_run(struct msm_gpu *gpu,
+   struct a5xx_crashdumper *dumper)
+{
+   u32 val;
+
+   if (IS_ERR_OR_NULL(dumper->ptr))
+   return -EINVAL;
+
+   gpu_write64(gpu, REG_A5XX_CP_CRASH_SCRIPT_BASE_LO,
+   REG_A5XX_CP_CRASH_SCRIPT_BASE_HI, dumper->iova);
+
+   gpu_write(gpu, REG_A5XX_CP_CRASH_DUMP_CNTL, 1);
+
+   return gpu_poll_timeout(gpu, REG_A5XX_CP_CRASH_DUMP_CNTL, val,
+   val & 0x04, 100, 1);
+}
+
+/*
+ * These are a list 

[PATCH 5/8] drm/msm/gpu: Capture the GPU state on a GPU hang

[Jordan Crouse]

Capture the GPU state on a GPU hang and store it for later playback
via the devcoredump facility. Only one crash state is stored at a
time on the assumption that the first hang is usually the most
interesting. The existing crash state can be cleared after capturing
it and then a new one will be captured on the next hang.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/Kconfig |   1 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  34 +++
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |   4 +-
 drivers/gpu/drm/msm/msm_debugfs.c   |   7 ++-
 drivers/gpu/drm/msm/msm_gpu.c   | 103 +---
 drivers/gpu/drm/msm/msm_gpu.h   |  38 +++-
 6 files changed, 161 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 38cbde9..843a9d4 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -12,6 +12,7 @@ config DRM_MSM
select SHMEM
select TMPFS
select QCOM_SCM
+   select WANT_DEV_COREDUMP
select SND_SOC_HDMI_CODEC if SND_SOC
select SYNC_FILE
select PM_OPP
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index af776f1..e86238ce 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -392,6 +392,8 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
if (!state)
return ERR_PTR(-ENOMEM);
 
+   kref_init(>ref);
+
do_gettimeofday(>time);
 
for (i = 0; i < gpu->nr_rings; i++) {
@@ -427,18 +429,28 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
return state;
 }
 
-void adreno_gpu_state_put(struct msm_gpu_state *state)
+static void adreno_gpu_state_destroy(struct kref *kref)
 {
-   if (IS_ERR_OR_NULL(state))
-   return;
+   struct msm_gpu_state *state = container_of(kref,
+   struct msm_gpu_state, ref);
 
+   kfree(state->comm);
+   kfree(state->cmd);
kfree(state->registers);
kfree(state);
 }
 
+int adreno_gpu_state_put(struct msm_gpu_state *state)
+{
+   if (IS_ERR_OR_NULL(state))
+   return 1;
+
+   return kref_put(>ref, adreno_gpu_state_destroy);
+}
+
 #ifdef CONFIG_DEBUG_FS
 void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
-   struct seq_file *m)
+   struct drm_printer *p)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int i;
@@ -446,23 +458,23 @@ void adreno_show(struct msm_gpu *gpu, struct 
msm_gpu_state *state,
if (IS_ERR_OR_NULL(state))
return;
 
-   seq_printf(m, "status:   %08x\n", state->rbbm_status);
-   seq_printf(m, "revision: %d (%d.%d.%d.%d)\n",
+   drm_printf(p, "status:   %08x\n", state->rbbm_status);
+   drm_printf(p, "revision: %d (%d.%d.%d.%d)\n",
adreno_gpu->info->revn, adreno_gpu->rev.core,
adreno_gpu->rev.major, adreno_gpu->rev.minor,
adreno_gpu->rev.patchid);
 
for (i = 0; i < gpu->nr_rings; i++) {
-   seq_printf(m, "rb %d: fence:%d/%d\n", i,
+   drm_printf(p, "rb %d: fence:%d/%d\n", i,
state->ring[i].fence, state->ring[i].seqno);
 
-   seq_printf(m, "  rptr: %d\n", state->ring[i].rptr);
-   seq_printf(m, "rb wptr:  %d\n", state->ring[i].wptr);
+   drm_printf(p, "  rptr: %d\n", state->ring[i].rptr);
+   drm_printf(p, "rb wptr:  %d\n", state->ring[i].wptr);
}
 
-   seq_printf(m, "IO:region %s  0002\n", gpu->name);
+   drm_printf(p, "IO:region %s  0002\n", gpu->name);
for (i = 0; i < state->nr_registers; i++) {
-   seq_printf(m, "IO:R %08x %08x\n",
+   drm_printf(p, "IO:R %08x %08x\n",
state->registers[i * 2] << 2,
state->registers[(i * 2) + 1]);
}
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 815ae98..077bf11 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -216,7 +216,7 @@ void adreno_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
 bool adreno_idle(struct msm_gpu *gpu, struct msm_ringbuffer *ring);
 #ifdef CONFIG_DEBUG_FS
 void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
-   struct seq_file *m);
+   struct drm_printer *p);
 #endif
 void adreno_dump_info(struct msm_gpu *gpu);
 void adreno_dump(struct msm_gpu *gpu);
@@ -229,7 +229,7 @@ int adreno_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
 void adreno_gpu_cleanup(struct adreno_gpu *gpu);
 
 struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu *gpu);
-void 

[PATCH 3/8] drm/msm/gpu: Capture the state of the GPU

[Jordan Crouse]

Add the infrastructure to capture the state current state of the
GPU and store it in memory. This is useful for storing the state
of a hung GPU so it can be dumped later.

For now grab the same basic ringbuffer information and registers
that are provided by the debugfs 'gpu' node but obviously this can
be extended to capture a much larger set of GPU information.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 15 +
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 14 +
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 22 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 54 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  3 ++
 drivers/gpu/drm/msm/msm_gpu.h   | 19 
 6 files changed, 127 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 1dd84d3..c351292 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -426,6 +426,19 @@ static void a3xx_dump(struct msm_gpu *gpu)
gpu_read(gpu, REG_A3XX_RBBM_STATUS));
adreno_dump(gpu);
 }
+
+static struct msm_gpu_state *a3xx_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+
+   if (IS_ERR(state))
+   return state;
+
+   state->rbbm_status = gpu_read(gpu, REG_A3XX_RBBM_STATUS);
+
+   return state;
+}
+
 /* Register offset defines for A3XX */
 static const unsigned int a3xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_AXXX_CP_RB_BASE),
@@ -452,6 +465,8 @@ static void a3xx_dump(struct msm_gpu *gpu)
 #ifdef CONFIG_DEBUG_FS
.show = a3xx_show,
 #endif
+   .gpu_state_get = a3xx_gpu_state_get,
+   .gpu_state_put = adreno_gpu_state_put,
},
 };
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 2884b1b..faf5d60 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -464,6 +464,18 @@ static void a4xx_show(struct msm_gpu *gpu, struct seq_file 
*m)
 }
 #endif
 
+static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+
+   if (IS_ERR(state))
+   return state;
+
+   state->rbbm_status = gpu_read(gpu, REG_A4XX_RBBM_STATUS);
+
+   return state;
+}
+
 /* Register offset defines for A4XX, in order of enum adreno_regs */
 static const unsigned int a4xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_A4XX_CP_RB_BASE),
@@ -540,6 +552,8 @@ static int a4xx_get_timestamp(struct msm_gpu *gpu, uint64_t 
*value)
 #ifdef CONFIG_DEBUG_FS
.show = a4xx_show,
 #endif
+   .gpu_state_get = a4xx_gpu_state_get,
+   .gpu_state_put = adreno_gpu_state_put,
},
.get_timestamp = a4xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index a4f68af..08f2579 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1195,6 +1195,26 @@ static int a5xx_get_timestamp(struct msm_gpu *gpu, 
uint64_t *value)
return 0;
 }
 
+static struct msm_gpu_state *a5xx_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct msm_gpu_state *state;
+
+   /*
+* Temporarily disable hardware clock gating before going into
+* adreno_show to avoid issues while reading the registers
+*/
+   a5xx_set_hwcg(gpu, false);
+
+   state = adreno_gpu_state_get(gpu);
+
+   if (!IS_ERR(state))
+   state->rbbm_status = gpu_read(gpu, REG_A5XX_RBBM_STATUS);
+
+   a5xx_set_hwcg(gpu, true);
+
+   return state;
+}
+
 #ifdef CONFIG_DEBUG_FS
 static void a5xx_show(struct msm_gpu *gpu, struct seq_file *m)
 {
@@ -1244,6 +1264,8 @@ static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t 
*value)
.debugfs_init = a5xx_debugfs_init,
 #endif
.gpu_busy = a5xx_gpu_busy,
+   .gpu_state_get = a5xx_gpu_state_get,
+   .gpu_state_put = adreno_gpu_state_put,
},
.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 87133c6c..35b77f0 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -382,6 +382,60 @@ bool adreno_idle(struct msm_gpu *gpu, struct 
msm_ringbuffer *ring)
return false;
 }
 
+struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct msm_gpu_state *state;
+   int i, count = 0;
+
+   state = kzalloc(sizeof(*state), GFP_KERNEL);
+   if (!state)
+   return 

[RFC v3 0/8] drm/msm: GPU crash state

[Jordan Crouse]

This is revision 3 of my stack implementing a GPU crash state for drm/msm
(https://patchwork.freedesktop.org/series/36097/).

The goal is to store and provide enough information to debug software
and hardware issues on the Adreno hardware in a semi human-readable
format that can also be parsed by scripts.

So far this is a relatively basic dump of registers and data but future patches
will add more details and target specific information.

You can see an example of the output for a simple invalid opcode error on the
db820c here: https://hastebin.com/olaruyakaz.bash

v3: Make recommended changes to ascii85 per Chris Wilson. Use devcoredump to
dump crash states as suggested by Bjorn Andersson and add a new drm_print
facility to facilitate that. Remove the now obsolete 'crash' debugfs node.
Add documentation for the crash dump output.

v2: Convert output to yaml, use ascii85 to dump ringbuffer contents.

Jordan Crouse (8):
  include: Move ascii85 functions from i915 to linux/ascii85.h
  drm: drm_printer: Add printer for devcoredump
  drm/msm/gpu: Capture the state of the GPU
  drm/msm/gpu: Convert the GPU show function to use the GPU state
  drm/msm/gpu: Capture the GPU state on a GPU hang
  drm/msm/adreno: Convert the show/crash file format
  drm/msm/adreno: Add ringbuffer data to the GPU state
  drm/msm/adreno: Add a5xx specific registers for the GPU state

 Documentation/gpu/drm-msm-crash-dump.txt |  34 +
 drivers/gpu/drm/drm_print.c  |  54 +++
 drivers/gpu/drm/i915/i915_gpu_error.c|  38 +
 drivers/gpu/drm/msm/Kconfig  |   1 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c|  28 ++--
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c|  20 ++-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c| 239 +--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 146 ---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h  |   7 +-
 drivers/gpu/drm/msm/msm_debugfs.c|  24 +++-
 drivers/gpu/drm/msm/msm_gpu.c| 103 +++--
 drivers/gpu/drm/msm/msm_gpu.h|  58 +++-
 include/drm/drm_print.h  |  27 
 include/linux/ascii85.h  |  39 +
 14 files changed, 721 insertions(+), 97 deletions(-)
 create mode 100644 Documentation/gpu/drm-msm-crash-dump.txt
 create mode 100644 include/linux/ascii85.h

-- 
1.9.1

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

[PATCH 4/8] drm/msm/gpu: Convert the GPU show function to use the GPU state

[Jordan Crouse]

Convert the existing GPU show function to use the GPU state to
dump the information rather than reading it directly from the hardware.
This will require an additional step to capture the state before
dumping it for the existing nodes but it will greatly facilitate reusing
the same code for dumping a previously captured state from a GPU hang.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 11 +--
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 12 +---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 18 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 30 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  4 ++--
 drivers/gpu/drm/msm/msm_debugfs.c   | 21 +++--
 drivers/gpu/drm/msm/msm_gpu.h   |  3 ++-
 7 files changed, 35 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c351292..4b9284a 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -410,15 +410,6 @@ static irqreturn_t a3xx_irq(struct msm_gpu *gpu)
~0   /* sentinel */
 };
 
-#ifdef CONFIG_DEBUG_FS
-static void a3xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
-   seq_printf(m, "status:   %08x\n",
-   gpu_read(gpu, REG_A3XX_RBBM_STATUS));
-   adreno_show(gpu, m);
-}
-#endif
-
 /* would be nice to not have to duplicate the _show() stuff with printk(): */
 static void a3xx_dump(struct msm_gpu *gpu)
 {
@@ -463,7 +454,7 @@ static struct msm_gpu_state *a3xx_gpu_state_get(struct 
msm_gpu *gpu)
.irq = a3xx_irq,
.destroy = a3xx_destroy,
 #ifdef CONFIG_DEBUG_FS
-   .show = a3xx_show,
+   .show = adreno_show,
 #endif
.gpu_state_get = a3xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index faf5d60..b8dcbb1 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -454,16 +454,6 @@ static irqreturn_t a4xx_irq(struct msm_gpu *gpu)
~0 /* sentinel */
 };
 
-#ifdef CONFIG_DEBUG_FS
-static void a4xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
-   seq_printf(m, "status:   %08x\n",
-   gpu_read(gpu, REG_A4XX_RBBM_STATUS));
-   adreno_show(gpu, m);
-
-}
-#endif
-
 static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
 {
struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
@@ -550,7 +540,7 @@ static int a4xx_get_timestamp(struct msm_gpu *gpu, uint64_t 
*value)
.irq = a4xx_irq,
.destroy = a4xx_destroy,
 #ifdef CONFIG_DEBUG_FS
-   .show = a4xx_show,
+   .show = adreno_show,
 #endif
.gpu_state_get = a4xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 08f2579..b0910bb 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1215,22 +1215,6 @@ static struct msm_gpu_state *a5xx_gpu_state_get(struct 
msm_gpu *gpu)
return state;
 }
 
-#ifdef CONFIG_DEBUG_FS
-static void a5xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
-   seq_printf(m, "status:   %08x\n",
-   gpu_read(gpu, REG_A5XX_RBBM_STATUS));
-
-   /*
-* Temporarily disable hardware clock gating before going into
-* adreno_show to avoid issues while reading the registers
-*/
-   a5xx_set_hwcg(gpu, false);
-   adreno_show(gpu, m);
-   a5xx_set_hwcg(gpu, true);
-}
-#endif
-
 static struct msm_ringbuffer *a5xx_active_ring(struct msm_gpu *gpu)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -1260,7 +1244,7 @@ static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t 
*value)
.irq = a5xx_irq,
.destroy = a5xx_destroy,
 #ifdef CONFIG_DEBUG_FS
-   .show = a5xx_show,
+   .show = adreno_show,
.debugfs_init = a5xx_debugfs_init,
 #endif
.gpu_busy = a5xx_gpu_busy,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 35b77f0..af776f1 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -437,38 +437,34 @@ void adreno_gpu_state_put(struct msm_gpu_state *state)
 }
 
 #ifdef CONFIG_DEBUG_FS
-void adreno_show(struct msm_gpu *gpu, struct seq_file *m)
+void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
+   struct seq_file *m)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int i;
 
+   if (IS_ERR_OR_NULL(state))
+   return;
+
+   seq_printf(m, "status:   %08x\n", state->rbbm_status);

[PATCH 2/8] drm: drm_printer: Add printer for devcoredump

[Jordan Crouse]

Add a drm printer suitable for use with the read callback for
devcoredump or any other file operation read() function that
isn't otherwise covered by seq_file.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/drm_print.c | 54 +
 include/drm/drm_print.h | 27 +++
 2 files changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 781518f..f6efde4 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -30,6 +30,60 @@
 #include 
 #include 
 
+void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf)
+{
+   struct drm_print_iterator *iterator = p->arg;
+
+   ssize_t len;
+
+   if (!iterator->remain)
+   return;
+
+   if (iterator->offset < iterator->start) {
+   char *buf;
+   ssize_t copy;
+
+   /* Figure out how big the string will be */
+   len = snprintf(NULL, 0, "%pV", vaf);
+
+   if (iterator->offset + len <= iterator->start) {
+   iterator->offset += len;
+   return;
+   }
+
+   /* Print the string into a temporary buffer */
+   buf = kmalloc(len + 1,
+   GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
+   if (!buf)
+   return;
+
+   snprintf(buf, len + 1, "%pV", vaf);
+
+   copy = len - (iterator->start - iterator->offset);
+
+   if (copy > iterator->remain)
+   copy = iterator->remain;
+
+   /* Copy out the bit of the string that we need */
+   memcpy(iterator->data,
+   buf + (iterator->start - iterator->offset), copy);
+
+   iterator->offset = iterator->start + copy;
+   iterator->remain -= copy;
+
+   kfree(buf);
+   } else {
+   ssize_t pos = iterator->offset - iterator->start;
+
+   len = scnprintf(((char *) iterator->data) + pos,
+   iterator->remain, "%pV", vaf);
+
+   iterator->offset += len;
+   iterator->remain -= len;
+   }
+}
+EXPORT_SYMBOL(__drm_printfn_coredump);
+
 void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf)
 {
seq_printf(p->arg, "%pV", vaf);
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 2a4a42e..29eee51 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -73,6 +73,7 @@ struct drm_printer {
const char *prefix;
 };
 
+void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf);
@@ -104,6 +105,32 @@ struct drm_printer {
 #define drm_printf_indent(printer, indent, fmt, ...) \
drm_printf((printer), "%.*s" fmt, (indent), "\t\t\t\t\tX", 
##__VA_ARGS__)
 
+struct drm_print_iterator {
+   void *data;
+
+   ssize_t start;
+   ssize_t offset;
+   ssize_t remain;
+};
+
+/**
+ * drm_coredump_printer - construct a _printer that can output to a buffer
+ * from the read function for devcoredump
+ * @iter: A pointer to a struct drm_print_iterator for the read instance
+ *
+ * RETURNS:
+ * The _printer object
+ */
+static inline struct drm_printer
+drm_coredump_printer(struct drm_print_iterator *iter)
+{
+   struct drm_printer p = {
+   .printfn = __drm_printfn_coredump,
+   .arg = iter,
+   };
+   return p;
+}
+
 /**
  * drm_seq_file_printer - construct a _printer that outputs to _file
  * @f:  the  seq_file to output to
-- 
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: Convert the show/crash file format

[Jordan Crouse]

Convert the format of the 'show' debugfs file and the crash
dump to a  format resembling YAML. This should be easier to
parse and be more flexible for future changes and expansions.

Signed-off-by: Jordan Crouse 
---
 Documentation/gpu/drm-msm-crash-dump.txt | 29 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 23 ++-
 2 files changed, 43 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/gpu/drm-msm-crash-dump.txt

diff --git a/Documentation/gpu/drm-msm-crash-dump.txt 
b/Documentation/gpu/drm-msm-crash-dump.txt
new file mode 100644
index 000..ec56640
--- /dev/null
+++ b/Documentation/gpu/drm-msm-crash-dump.txt
@@ -0,0 +1,29 @@
+# drm/msm GPU crash dump format
+#
+# This is a description of the format of the drm/msm GPU crash dump format that
+# can be read from /sys/kernel/dri/X/show or from devcoredump following a GPU
+# hang or fault
+
+---
+kernel:   # [string] The kernel version as printed by UTS_RELEASE
+module:   # [string] The module that generated the crash dump
+time: # [seconds.microseconds] The kernel time at crash
+comm: # [string] comm string for the binary that generated the fault
+  # (if known)
+cmdline:  # [string] the cmdline for the binary that generated the fault
+  # (if known)
+revision: # [ id core.major.minor.patchlevel] The GPU id followed by the
+  # individual components of the id separated by dots
+rbbm-status:  # [hex] The current value of RBBM_STATUS which shows what GPU
+  # components were in use at the time of the crash
+ringbuffer:   # Ringbuffer data. There will be a sequence for each ringbuffer
+  -id: # [decimal] Ringbuffer identifier (0 based index)
+   last-fence: # [decimal] The last fence issued on the ring
+   retired-fence:  # [decimal] THe last fence retired on the ring
+   rptr:   # [decimal] The current read pointer (rptr) for the ring
+   wptr:   # [decimal] The current write pointer (wptr) for the ring
+registers:# Sets of register values. This section can be used multiple
+  # times for different ranges of registers. Each register will be
+  # on its own line.
+  - [offset, value] # offset: [hex] byte offset of the register
+# value: [hex] value of the register
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index e86238ce..920db2e 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -458,23 +458,28 @@ void adreno_show(struct msm_gpu *gpu, struct 
msm_gpu_state *state,
if (IS_ERR_OR_NULL(state))
return;
 
-   drm_printf(p, "status:   %08x\n", state->rbbm_status);
drm_printf(p, "revision: %d (%d.%d.%d.%d)\n",
adreno_gpu->info->revn, adreno_gpu->rev.core,
adreno_gpu->rev.major, adreno_gpu->rev.minor,
adreno_gpu->rev.patchid);
 
-   for (i = 0; i < gpu->nr_rings; i++) {
-   drm_printf(p, "rb %d: fence:%d/%d\n", i,
-   state->ring[i].fence, state->ring[i].seqno);
+   drm_printf(p, "rbbm-status: 0x%08x\n", state->rbbm_status);
+
+   drm_printf(p, "ringbuffer:\n");
 
-   drm_printf(p, "  rptr: %d\n", state->ring[i].rptr);
-   drm_printf(p, "rb wptr:  %d\n", state->ring[i].wptr);
+   for (i = 0; i < gpu->nr_rings; i++) {
+   drm_printf(p, "  - id: %d\n", i);
+   drm_printf(p, "last-fence: %d\n", state->ring[i].seqno);
+   drm_printf(p, "retired-fence: %d\n", state->ring[i].fence);
+   drm_printf(p, "rptr: %d\n", state->ring[i].rptr);
+   drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
}
 
-   drm_printf(p, "IO:region %s  0002\n", gpu->name);
-   for (i = 0; i < state->nr_registers; i++) {
-   drm_printf(p, "IO:R %08x %08x\n",
+   drm_printf(p, "registers:\n");
+   drm_printf(p, "  - [offset, value]\n");
+
+   for(i = 0; i < state->nr_registers; i++) {
+   drm_printf(p, "  - [0x%04x, 0x%08x]\n",
state->registers[i * 2] << 2,
state->registers[(i * 2) + 1]);
}
-- 
1.9.1

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

[PATCH 1/8] include: Move ascii85 functions from i915 to linux/ascii85.h

[Jordan Crouse]

The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.

[v2 - Update the API to be cleaner for the caller suggested by
Chris Wilson]

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 38 ++
 include/linux/ascii85.h   | 39 +++
 2 files changed, 45 insertions(+), 32 deletions(-)
 create mode 100644 include/linux/ascii85.h

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9440593..8bc72c7 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i915_drv.h"
 
@@ -502,35 +503,12 @@ void i915_error_printf(struct drm_i915_error_state_buf 
*e, const char *f, ...)
va_end(args);
 }
 
-static int
-ascii85_encode_len(int len)
-{
-   return DIV_ROUND_UP(len, 4);
-}
-
-static bool
-ascii85_encode(u32 in, char *out)
-{
-   int i;
-
-   if (in == 0)
-   return false;
-
-   out[5] = '\0';
-   for (i = 5; i--; ) {
-   out[i] = '!' + in % 85;
-   in /= 85;
-   }
-
-   return true;
-}
-
 static void print_error_obj(struct drm_i915_error_state_buf *m,
struct intel_engine_cs *engine,
const char *name,
struct drm_i915_error_object *obj)
 {
-   char out[6];
+   char out[ASCII85_BUFSZ];
int page;
 
if (!obj)
@@ -545,19 +523,15 @@ static void print_error_obj(struct 
drm_i915_error_state_buf *m,
 
err_compression_marker(m);
for (page = 0; page < obj->page_count; page++) {
-   int i, len;
+   int i;
+   long len = PAGE_SIZE;
 
-   len = PAGE_SIZE;
if (page == obj->page_count - 1)
len -= obj->unused;
len = ascii85_encode_len(len);
 
-   for (i = 0; i < len; i++) {
-   if (ascii85_encode(obj->pages[page][i], out))
-   err_puts(m, out);
-   else
-   err_puts(m, "z");
-   }
+   for (i = 0; i < len; i++)
+   error_puts(m, ascii85_encode(obj->pages[page][i], out));
}
err_puts(m, "\n");
 }
diff --git a/include/linux/ascii85.h b/include/linux/ascii85.h
new file mode 100644
index 000..322bbed
--- /dev/null
+++ b/include/linux/ascii85.h
@@ -0,0 +1,39 @@
+
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (c) 2008 Intel Corporation
+ * Copyright (c) The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _ASCII85_H_
+#define _ASCII85_H_
+
+#include 
+
+#define ASCII85_BUFSZ 6
+
+static inline long
+ascii85_encode_len(long len)
+{
+   return DIV_ROUND_UP(len, 4);
+}
+
+static inline char *
+ascii85_encode(u32 in, char *out)
+{
+   int i;
+
+   if (in == 0)
+   return "z";
+
+   out[5] = '\0';
+   for (i = 5; i--; ) {
+   out[i] = '!' + in % 85;
+   in /= 85;
+   }
+
+   return out;
+}
+
+#endif
-- 
1.9.1

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

Re: [PATCH v2] drm/bridge/synopsys: dsi: Adopt SPDX identifiers

[Laurent Pinchart]

Hi Philippe,

Thank you for the patch.

On Thursday, 8 February 2018 16:58:05 EET Philippe Cornu wrote:
> Add SPDX identifiers to the Synopsys DesignWare MIPI DSI
> host controller driver.
> 
> Signed-off-by: Philippe Cornu 

Reviewed-by: Laurent Pinchart 

> ---
> Changes in v2: Update to "GPL-2.0+" following comments from Laurent
> Pinchart, Benjamin Gaignard & Philippe Ombredanne.
> 
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index
> 7bac101c285c..99f0e4f51716 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -1,12 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
>   * Copyright (C) STMicroelectronics SA 2017
>   *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
>   * Modified by Philippe Cornu 
>   * This generic Synopsys DesignWare MIPI DSI host driver is based on the
>   * Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.


-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm/amdgpu: add new device to use atpx quirk

[Alex Deucher]

On Thu, Feb 8, 2018 at 4:46 AM, Kai-Heng Feng
 wrote:
> The affected system (0x0813) is pretty similar to another one (0x0812),
> it also needs to use ATPX power control.
>
> Signed-off-by: Kai-Heng Feng 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> index e2c3c5ec42d1..c53095b3b0fb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> @@ -568,6 +568,7 @@ static const struct amdgpu_px_quirk 
> amdgpu_px_quirk_list[] = {
> /* HG _PR3 doesn't seem to work on this A+A weston board */
> { 0x1002, 0x6900, 0x1002, 0x0124, AMDGPU_PX_QUIRK_FORCE_ATPX },
> { 0x1002, 0x6900, 0x1028, 0x0812, AMDGPU_PX_QUIRK_FORCE_ATPX },
> +   { 0x1002, 0x6900, 0x1028, 0x0813, AMDGPU_PX_QUIRK_FORCE_ATPX },
> { 0, 0, 0, 0, 0 },
>  };
>
> --
> 2.15.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -EPROBE_DEFER and failed DSI panel probe

[Boris Brezillon]

+Thierry and Archit for the drm_panel/panel_bridge bits.

Hi all,

I'm resurrecting this thread because Eric asked me to find a solution
to this problem :-).

On Mon, 20 Nov 2017 08:53:05 +0100
Andrzej Hajda  wrote:

> On 18.11.2017 02:16, Eric Anholt wrote:
> > Andrzej Hajda  writes:
> >  
> >> On 16.11.2017 21:27, Eric Anholt wrote:  
> >>> Andrzej Hajda  writes:
> >>>  
>  On 15.11.2017 21:26, Eric Anholt wrote:  
> > I'm happy to have the DSI panel finally working on VC4 (just waiting on
> > https://lists.freedesktop.org/archives/dri-devel/2017-October/156407.html),
> > but now I've got another problem to solve.  It would be great if I could
> > include the DSI panel in our upstream DT, so that it automatically
> > worked when you plugged one in.  However, right now we return
> > -EPROBE_DEFER during bind unless the panel has actually shown up.  This
> > means that if you don't have the panel actually connected, you get this
> > sequence at startup:
> >
> > [   10.719929] [drm] Initialized
> > [   10.829510] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi 
> > mapping ok
> > [   10.844043] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops 
> > [vc4])
> > [   10.848626] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops 
> > [vc4])
> > [   10.850214] vc4-drm soc:gpu: failed to bind 3f70.dsi (ops 
> > vc4_dsi_ops [vc4]): -517
> > [   10.856559] vc4-drm soc:gpu: master bind failed: -517
> >
> > [...]
> >
> > [   10.967718] rpi_touchscreen 3-0045: Atmel I2C read failed: -6
> >
> > Once the panel driver fails to probe, we never get asked to re-bind vc4,
> > and drm_of_find_panel_or_bridge looks like it would just give us
> > -EPROBE_DEFER again since the panel still wasn't registered.

Well, that's not surprising since I2C is not an hotplug-friendly bus.
So, if you declare a device in the DT, and this device is not accessible
(returns I2C errors), that means there's no device at all, and there's
no reason for the I2C core to retry later.

> >
> > Does anyone have any suggestions for handling this?  
>  I guess you should call component_add only when all required resources
>  are present(including panel), I suppose moving it to vc4_dsi_host_attach
>  should help.  
> >>> How can I decide when the panel driver has tried to probe and failed,
> >>> versus not tried to probe yet?  find_panel_or_bridge gives me
> >>> -EPROBE_DEFER either way.

We could have a fake/dummy panel object that is registered to the
panel list when we know the device will never be available (because
it's simply not connected to the control bus). This way, instead of
-EPROBE_DEFER, the drm_panel layer could return -ENODEV. But still,
this alone won't solve your problem, because, AFAICT, the way the VC4
dev registration work is: "bind all components of the display pipeline,
and if there's one missing, do not register the DRM device". So, you'd
have to change that for: "only wait for mandatory elements", and then
declare the DSI panel as optional (don't know how to encode that in
the DT).

> >>>  
>  On the other side I am curious why EPROBE_DEFER from bind does not fail
>  probing of some component (the last one probed), with proper error
>  propagation it should cause defer_probing of one of the components or
>  master, and probe/bind should be retried after panel's probe.  
> >>> The panel probe failed, though, so there's no trigger to re-probe other
> >>> drivers.  
> >> OK, I misunderstood your problem. And after 2nd read I am not sure what
> >> do you want to achieve exactly?
> >>
> >> Do you want to 'hotplug' DSI panel? Or just make it working with and
> >> without the panel. In 2nd case other paths (HDMI) should still work, I
> >> guess.  
> > Yeah, the second thing.  I would like to use a single DT to describe a
> > platform where the panel may or may not be present, so the panel driver
> > (panel-raspberrypi-touchscreen.c) will throw an error from the I2C part
> > of the probe or not instead of creating the DSI device and attaching the
> > panel.
> >  
> >> Lets assume that you are interested in the latter case. There could be
> >> multiple solutions more or less hacky:
> >>
> >> 1. Use connector's HPD infrastructure to signal presence of the panel,
> >> ie. in mipi_dsi::host_(attach|detach) callback you grab the panel and
> >> change connector status to connected|disconnected and calls
> >> drm_kms_helper_hotplug_event, it is done this way in 
> >> exynos_dsi_host_attach.  
> > This is basically what I had before all the review reworks, and the
> > regression from this state is keeping me from merging the current driver
> > downstream.
> >
> > This option is unfortunate because we'll have forced *some* output on at
> > boot time, and then when the panel driver shows up later we don't resize
> > the 

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

--- Comment #26 from Bong Cosca  ---
(In reply to Michel Dänzer from comment #25)
> 
> Where do you see that?

Xorg.0.log

-- 
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 v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

On 02/08/2018 02:11 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> [ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]
> 
> On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
>> On 02/01/2018 07:41 PM, Farhan Ali wrote:
>>> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on 
>>> HAS_IOMEM.")'
>>> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
>>> "Graphics support" menu for S390. But if we enable VT layer for S390,
>>> we would also need to enable the dummy console. So let's remove the
>>> HAS_IOMEM dependency.
>>>
>>> Move this dependency to Opencores framebuffer driver which would fail to 
>>> build
>>> with CONFIG_HAS_IOMEM disabled:
>>>
>>> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> "Graphics support" menu covers other things (i.e. DRM), I assume that
> they were also checked to not break due to this change?
> 
> Moreover it seems that after this change "Graphics support" menu will
> be also enabled (besides s390) for score, tile and um architectures,
> I assume that this is okay?

I can add this patch to my next tree (after merge window) and check for
any errors from all the build bots.

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

Re: [PATCH] drm/bridge/synopsys: dsi: Adopt SPDX identifiers

[Philippe CORNU]

Hi Laurent, Benjamin & Philippe,

I sent an updated version of the patch following your comments
Big thank you,

Philippe :-)

On 02/08/2018 03:09 PM, Philippe Ombredanne wrote:
> Benjamin,
> 
> On Wed, Jan 24, 2018 at 9:57 AM, Benjamin Gaignard
>  wrote:
>> 2018-01-24 0:32 GMT+01:00 Laurent Pinchart 
>> :
>>> Hi Philippe,
>>>
>>> On Tuesday, 23 January 2018 12:25:51 EET Philippe CORNU wrote:
 On 01/23/2018 12:30 AM, Laurent Pinchart wrote:
> On Monday, 22 January 2018 12:26:08 EET Philippe Cornu wrote:
>> Add SPDX identifiers to the Synopsys DesignWare MIPI DSI
>> host controller driver.
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>>
>>drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +-
>>1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index
>> 46b0e73404d1..e06836dec77c 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> @@ -1,12 +1,8 @@
>> +// SPDX-License-Identifier: GPL-2.0
>
> According to Documentation/process/license-rules.txt this would change
> the existing license. The correct identifier is GPL-2.0+.

 You are right, I did not put the correct identifier :(

 After reading more spdx.org, I wonder if the correct value should be
 GPL-2.0-or-later instead of GPL-2.0+

 https://spdx.org/licenses/GPL-2.0-or-later.html
 https://spdx.org/licenses/GPL-2.0+.html

 What is your opinion?
>>>
>>> I agree in principle, and I've even asked for that before, but I've been 
>>> told
>>> that we should stick to the license identifiers defined in Documentation/
>>> process/license-rules.txt. The file might get updated to use 
>>> GPL-2.0-or-later
>>> and GPL-2.0-only later, and kernel sources will likely then get patched in 
>>> one
>>> go.
>>
>> + Philippe O. to check what I'm writing just below.
>>
>> In -next branch I only see reference to GPL-2.0+ identifier so for me
>> it fine to use it here.
>> Is that right ? or should we use GPL-2.0-or-later keyword ?
> 
> 
> Sorry for the late reply!
> IMHO it is essential to stick to what is in the kernel doc, meaning
> that you should not use the GPL-2.0-or-later identifier until it is
> part of the kernel doc. Otherwise this is going to be a mess ;)
> Consistency matters a lot.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/2] drm/stm: ltdc: add non-alpha color formats

[Philippe CORNU]

Hi Benjamin,
and many thanks for having applied the 2 patches.
Philippe :-)

On 02/08/2018 10:40 AM, Benjamin Gaignard wrote:
> 2018-02-06 10:12 GMT+01:00 Yannick FERTRE :
>> Reviewed-by: Yannick Fertré 
>>
>>
>> On 02/01/2018 11:42 AM, Philippe Cornu wrote:
>>> ltdc supports natively some color formats with alpha (like
>>> ARGB, ARGB1555, ARGB...). Related non-alpha formats are
>>> supported too (ARGB->XRGB, ARGB->XRGB...) by
>>> adjusting ltdc blending factors.
>>>
>>> Note: Wayland/Weston requests by default the non-alpha XRGB
>>> color format.
>>>
>>> Signed-off-by: Philippe Cornu 
> 
> Applied on drm-misc-next
> 
> Benjamin
>>> ---
>>>drivers/gpu/drm/stm/ltdc.c | 33 +++--
>>>1 file changed, 31 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
>>> index 90b3de516c91..f6f26fc0ae9e 100644
>>> --- a/drivers/gpu/drm/stm/ltdc.c
>>> +++ b/drivers/gpu/drm/stm/ltdc.c
>>> @@ -328,6 +328,26 @@ static inline u32 to_drm_pixelformat(enum ltdc_pix_fmt 
>>> pf)
>>>}
>>>}
>>>
>>> +static inline u32 get_pixelformat_without_alpha(u32 drm)
>>> +{
>>> + switch (drm) {
>>> + case DRM_FORMAT_ARGB:
>>> + return DRM_FORMAT_XRGB;
>>> + case DRM_FORMAT_RGBA:
>>> + return DRM_FORMAT_RGBX;
>>> + case DRM_FORMAT_ARGB1555:
>>> + return DRM_FORMAT_XRGB1555;
>>> + case DRM_FORMAT_RGBA5551:
>>> + return DRM_FORMAT_RGBX5551;
>>> + case DRM_FORMAT_ARGB:
>>> + return DRM_FORMAT_XRGB;
>>> + case DRM_FORMAT_RGBA:
>>> + return DRM_FORMAT_RGBX;
>>> + default:
>>> + return 0;
>>> + }
>>> +}
>>> +
>>>static irqreturn_t ltdc_irq_thread(int irq, void *arg)
>>>{
>>>struct drm_device *ddev = arg;
>>> @@ -680,6 +700,9 @@ static void ltdc_plane_atomic_update(struct drm_plane 
>>> *plane,
>>>
>>>/* Specifies the blending factors */
>>>val = BF1_PAXCA | BF2_1PAXCA;
>>> + if (!fb->format->has_alpha)
>>> + val = BF1_CA | BF2_1CA;
>>> +
>>>reg_update_bits(ldev->regs, LTDC_L1BFCR + lofs,
>>>LXBFCR_BF2 | LXBFCR_BF1, val);
>>>
>>> @@ -747,8 +770,8 @@ static struct drm_plane *ltdc_plane_create(struct 
>>> drm_device *ddev,
>>>struct device *dev = ddev->dev;
>>>struct drm_plane *plane;
>>>unsigned int i, nb_fmt = 0;
>>> - u32 formats[NB_PF];
>>> - u32 drm_fmt;
>>> + u32 formats[NB_PF * 2];
>>> + u32 drm_fmt, drm_fmt_no_alpha;
>>>int ret;
>>>
>>>/* Get supported pixel formats */
>>> @@ -757,6 +780,12 @@ static struct drm_plane *ltdc_plane_create(struct 
>>> drm_device *ddev,
>>>if (!drm_fmt)
>>>continue;
>>>formats[nb_fmt++] = drm_fmt;
>>> +
>>> + /* Add the no-alpha related format if any & supported */
>>> + drm_fmt_no_alpha = get_pixelformat_without_alpha(drm_fmt);
>>> + if (!drm_fmt_no_alpha)
>>> + continue;
>>> + formats[nb_fmt++] = drm_fmt_no_alpha;
>>>}
>>>
>>>plane = devm_kzalloc(dev, sizeof(*plane), GFP_KERNEL);
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/bridge/synopsys: dsi: Adopt SPDX identifiers

[Philippe Cornu]

Add SPDX identifiers to the Synopsys DesignWare MIPI DSI
host controller driver.

Signed-off-by: Philippe Cornu 
---
Changes in v2: Update to "GPL-2.0+" following comments from Laurent
Pinchart, Benjamin Gaignard & Philippe Ombredanne.

 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 7bac101c285c..99f0e4f51716 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -1,12 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
  * Copyright (C) STMicroelectronics SA 2017
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
  * Modified by Philippe Cornu 
  * This generic Synopsys DesignWare MIPI DSI host driver is based on the
  * Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
-- 
2.15.1

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

[PATCH 3/3] drm/gma500: Delete an unnecessary return statement in oaktrail_crtc_hdmi_dpms()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 15:17:48 +0100

The script "checkpatch.pl" pointed information out like the following.

WARNING: void function return statements are not generally useful

Thus remove such a statement in the affected function.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/gma500/oaktrail_hdmi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c 
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index dbc58e5130bb..24c7c6edfca5 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -484,8 +484,6 @@ void oaktrail_crtc_hdmi_dpms(struct drm_crtc *crtc, int 
mode)
 
/* LNC Chicken Bits - Squawk! */
REG_WRITE(0x70400, 0x4000);
-
-   return;
 }
 
 static void oaktrail_hdmi_dpms(struct drm_encoder *encoder, int mode)
-- 
2.16.1

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

[PATCH 2/3] drm/gma500: Improve four size determinations

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 15:08:39 +0100

Replace the specification of data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/gma500/framebuffer.c   | 3 +--
 drivers/gpu/drm/gma500/oaktrail_hdmi.c | 6 +++---
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 3ff320f3ff47..ad96a542d137 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -525,11 +525,10 @@ static int psb_fbdev_destroy(struct drm_device *dev, 
struct psb_fbdev *fbdev)
 
 int psb_fbdev_init(struct drm_device *dev)
 {
-   struct psb_fbdev *fbdev;
struct drm_psb_private *dev_priv = dev->dev_private;
int ret;
+   struct psb_fbdev *fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
 
-   fbdev = kzalloc(sizeof(struct psb_fbdev), GFP_KERNEL);
if (!fbdev)
return -ENOMEM;
 
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c 
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index d9a6d54b6641..dbc58e5130bb 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -637,11 +637,11 @@ void oaktrail_hdmi_init(struct drm_device *dev,
struct drm_connector *connector;
struct drm_encoder *encoder;
 
-   gma_encoder = kzalloc(sizeof(struct gma_encoder), GFP_KERNEL);
+   gma_encoder = kzalloc(sizeof(*gma_encoder), GFP_KERNEL);
if (!gma_encoder)
return;
 
-   gma_connector = kzalloc(sizeof(struct gma_connector), GFP_KERNEL);
+   gma_connector = kzalloc(sizeof(*gma_connector), GFP_KERNEL);
if (!gma_connector)
goto failed_connector;
 
@@ -689,7 +689,7 @@ void oaktrail_hdmi_setup(struct drm_device *dev)
if (!pdev)
return;
 
-   hdmi_dev = kzalloc(sizeof(struct oaktrail_hdmi_dev), GFP_KERNEL);
+   hdmi_dev = kzalloc(sizeof(*hdmi_dev), GFP_KERNEL);
if (!hdmi_dev)
goto out;
 
-- 
2.16.1

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

[PATCH 1/3] drm/gma500: Delete an error message for a failed memory allocation in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 14:55:49 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/gma500/framebuffer.c   | 4 +---
 drivers/gpu/drm/gma500/oaktrail_hdmi.c | 5 +
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index cb0a2ae916e0..3ff320f3ff47 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -530,10 +530,8 @@ int psb_fbdev_init(struct drm_device *dev)
int ret;
 
fbdev = kzalloc(sizeof(struct psb_fbdev), GFP_KERNEL);
-   if (!fbdev) {
-   dev_err(dev->dev, "no memory\n");
+   if (!fbdev)
return -ENOMEM;
-   }
 
dev_priv->fbdev = fbdev;
 
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c 
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 8b2eb32ee988..d9a6d54b6641 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -690,11 +690,8 @@ void oaktrail_hdmi_setup(struct drm_device *dev)
return;
 
hdmi_dev = kzalloc(sizeof(struct oaktrail_hdmi_dev), GFP_KERNEL);
-   if (!hdmi_dev) {
-   dev_err(dev->dev, "failed to allocate memory\n");
+   if (!hdmi_dev)
goto out;
-   }
-
 
ret = pci_enable_device(pdev);
if (ret) {
-- 
2.16.1

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

[Bug 105005] No image after downtime (RX460)

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer  ---
(In reply to Dmitry from comment #7)
> After rebooting done due to this problem. Without the screen it is
> problematic to do, immediately after.

If you have another computer, you can do it via ssh.


> 4.14.15-1

Any chance you can use git bisect to isolate the change between 4.14 and 4.15
which introduced the problem?

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

[PATCH 0/3] GPU-DRM-GMA500: Adjustments for four function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 15:27:38 +0100

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete an error message for a failed memory allocation in two functions
  Improve four size determinations
  Delete an unnecessary return statement in oaktrail_crtc_hdmi_dpms()

 drivers/gpu/drm/gma500/framebuffer.c   |  7 ++-
 drivers/gpu/drm/gma500/oaktrail_hdmi.c | 13 -
 2 files changed, 6 insertions(+), 14 deletions(-)

-- 
2.16.1

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

Re: [PATCH v2 1/2] amdgpu/dc/dml: Consolidate redundant CFLAGS

[Harry Wentland]

On 2018-02-07 08:51 PM, Matthias Kaehlcke wrote:
> Use subdir-ccflags instead of specifying the same flags for every source
> file.
> 
> Signed-off-by: Matthias Kaehlcke 
> Reviewed-by: Guenter Roeck 
> ---
> Changes in v2:
> - added 'Reviewed-by: Guenter Roeck ' tag
> 
>  drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
> b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> index 3488af2b5786..b8cadf833e71 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> @@ -24,15 +24,7 @@
>  # It provides the general basic services required by other DAL
>  # subcomponents.
>  
> -CFLAGS_display_mode_vba.o := -mhard-float -msse -mpreferred-stack-boundary=4
> -CFLAGS_display_mode_lib.o := -mhard-float -msse -mpreferred-stack-boundary=4
> -CFLAGS_display_pipe_clocks.o := -mhard-float -msse 
> -mpreferred-stack-boundary=4
> -CFLAGS_display_rq_dlg_calc.o := -mhard-float -msse 
> -mpreferred-stack-boundary=4
> -CFLAGS_dml1_display_rq_dlg_calc.o := -mhard-float -msse 
> -mpreferred-stack-boundary=4
> -CFLAGS_display_rq_dlg_helpers.o := -mhard-float -msse 
> -mpreferred-stack-boundary=4
> -CFLAGS_soc_bounding_box.o := -mhard-float -msse -mpreferred-stack-boundary=4
> -CFLAGS_dml_common_defs.o := -mhard-float -msse -mpreferred-stack-boundary=4
> -
> +subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4

Are you sure this will only apply to dc/dml?

The way the amdgpu build is setup I've seen this flag apply to all of amdgpu, 
even if specified in a subdirectories build file. The reason being that 
amdgpu/Makefile recursively includes all other Makefiles in the module.

According to kbuild/makefiles.txt this will have effect for the kbuild file 
where it's present and all subdirectories:

https://www.kernel.org/doc/Documentation/kbuild/makefiles.txt:
> subdir-ccflags-y, subdir-asflags-y
>   The two flags listed above are similar to ccflags-y and asflags-y.
>   The difference is that the subdir- variants have effect for the kbuild
>   file where they are present and all subdirectories.
>   Options specified using subdir-* are added to the commandline before
>   the options specified using the non-subdir variants.
> 
>   Example:
>   subdir-ccflags-y := -Werror

For your 2nd patch you probably want to make a dml_cflags variable that's set 
different for clang and gcc, and then still set it for all files in DML 
individually.

You'll probably also have to do the same for dc/calcs/Makefile.

Thanks for finding a good solution for supporting clang. It's been on my list 
but I haven't had time to find the right flag yet.

Harry

>  
>  DML = display_mode_lib.o display_rq_dlg_calc.o \
> display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 0/2] drm/panel: Add support for Raydium rm68200 panel

[Philippe Cornu]

The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280
TFT LCD panel connected using a MIPI-DSI video interface.

Philippe Cornu (2):
  dt-bindings/display/panel: Add support for Raydium rm68200 dsi panel
  drm/panel: Add support for Raydium rm68200 panel driver

 .../bindings/display/panel/raydium,rm68200.txt |  25 ++
 drivers/gpu/drm/panel/Kconfig  |   8 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-raydium-rm68200.c  | 464 +
 4 files changed, 498 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
 create mode 100755 drivers/gpu/drm/panel/panel-raydium-rm68200.c

-- 
2.15.1

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

[PATCH v1 1/2] dt-bindings/display/panel: Add support for Raydium rm68200 dsi panel

[Philippe Cornu]

The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280
TFT LCD panel connected using a MIPI-DSI video interface.

Signed-off-by: Philippe Cornu 
---
 .../bindings/display/panel/raydium,rm68200.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt 
b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
new file mode 100644
index ..cbb79ef3bfc9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
@@ -0,0 +1,25 @@
+Raydium Semiconductor Corporation RM68200 5.5" 720p MIPI-DSI TFT LCD panel
+
+The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD
+panel connected using a MIPI-DSI video interface.
+
+Required properties:
+  - compatible: "raydium,rm68200"
+  - reg: the virtual channel number of a DSI peripheral
+
+Optional properties:
+  - reset-gpios: a GPIO spec for the reset pin (active low).
+  - power-supply: phandle of the regulator that provides the supply voltage.
+  - backlight: phandle of the backlight device attached to the panel.
+
+Example:
+ {
+   ...
+   panel@0 {
+   compatible = "raydium,rm68200";
+   reg = <0>;
+   reset-gpios = < 15 GPIO_ACTIVE_LOW>;
+   power-supply = <>;
+   backlight = <_backlight>;
+   };
+};
-- 
2.15.1

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

[PATCH v1 2/2] drm/panel: Add support for Raydium rm68200 panel driver

[Philippe Cornu]

This patch adds Raydium Semiconductor Corporation rm68200
5.5" 720x1280 TFT LCD panel driver (MIPI-DSI video mode).

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/panel/Kconfig |   8 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-raydium-rm68200.c | 464 ++
 3 files changed, 473 insertions(+)
 create mode 100755 drivers/gpu/drm/panel/panel-raydium-rm68200.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 988048ebcc22..08d99dd46765 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -108,6 +108,14 @@ config DRM_PANEL_RASPBERRYPI_TOUCHSCREEN
  Pi 7" Touchscreen.  To compile this driver as a module,
  choose M here.
 
+config DRM_PANEL_RAYDIUM_RM68200
+   tristate "Raydium rm68200 720x1280 dsi 2dl video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for Raydium rm68200
+ 720x1280 dsi 2dl video mode panel
+
 config DRM_PANEL_SAMSUNG_S6E3HA2
tristate "Samsung S6E3HA2 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 3d2a88d0e965..f26efc11d746 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) += 
panel-raspberrypi-touchscreen.o
+obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c 
b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
new file mode 100755
index ..f3e15873d05a
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
@@ -0,0 +1,464 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) STMicroelectronics SA 2017
+ *
+ * Authors: Philippe Cornu 
+ *  Yannick Fertre 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "raydium_rm68200"
+
+/*** Manufacturer Command Set ***/
+#define MCS_CMD_MODE_SW0xFE /* CMD Mode Switch */
+#define MCS_CMD1_UCS   0x00 /* User Command Set (UCS = CMD1) */
+#define MCS_CMD2_P00x01 /* Manufacture Command Set Page0 (CMD2 P0) */
+#define MCS_CMD2_P10x02 /* Manufacture Command Set Page1 (CMD2 P1) */
+#define MCS_CMD2_P20x03 /* Manufacture Command Set Page2 (CMD2 P2) */
+#define MCS_CMD2_P30x04 /* Manufacture Command Set Page3 (CMD2 P3) */
+
+/* CMD2 P0 commands (Display Options and Power) */
+#define MCS_STBCTR 0x12 /* TE1 Output Setting Zig-Zag Connection */
+#define MCS_SGOPCTR0x16 /* Source Bias Current */
+#define MCS_SDCTR  0x1A /* Source Output Delay Time */
+#define MCS_INVCTR 0x1B /* Inversion Type */
+#define MCS_EXT_PWR_IC 0x24 /* External PWR IC Control */
+#define MCS_SETAVDD0x27 /* PFM Control for AVDD Output */
+#define MCS_SETAVEE0x29 /* PFM Control for AVEE Output */
+#define MCS_BT2CTR 0x2B /* DDVDL Charge Pump Control */
+#define MCS_BT3CTR 0x2F /* VGH Charge Pump Control */
+#define MCS_BT4CTR 0x34 /* VGL Charge Pump Control */
+#define MCS_VCMCTR 0x46 /* VCOM Output Level Control */
+#define MCS_SETVGN 0x52 /* VG M/S N Control */
+#define MCS_SETVGP 0x54 /* VG M/S P Control */
+#define MCS_SW_CTRL0x5F /* Interface Control for PFM and MIPI */
+
+/* CMD2 P2 commands (GOA Timing Control) - no description in datasheet */
+#define GOA_VSTV1  0x00
+#define GOA_VSTV2  0x07
+#define GOA_VCLK1  0x0E
+#define GOA_VCLK2  0x17
+#define GOA_VCLK_OPT1  0x20
+#define GOA_BICLK1 0x2A
+#define GOA_BICLK2 0x37
+#define GOA_BICLK3 0x44
+#define GOA_BICLK4 0x4F
+#define GOA_BICLK_OPT1 0x5B
+#define GOA_BICLK_OPT2 0x60
+#define MCS_GOA_GPO1   0x6D
+#define MCS_GOA_GPO2   0x71
+#define MCS_GOA_EQ 0x74
+#define MCS_GOA_CLK_GALLON 0x7C
+#define MCS_GOA_FS_SEL00x7E
+#define MCS_GOA_FS_SEL10x87
+#define MCS_GOA_FS_SEL20x91
+#define MCS_GOA_FS_SEL30x9B
+#define MCS_GOA_BS_SEL00xAC
+#define MCS_GOA_BS_SEL10xB5
+#define MCS_GOA_BS_SEL20xBF
+#define MCS_GOA_BS_SEL30xC9
+#define MCS_GOA_BS_SEL40xD3
+
+/* CMD2 P3 commands (Gamma) */
+#define MCS_GAMMA_VP   0x60 /* Gamma VP1~VP16 */
+#define MCS_GAMMA_VN   0x70 /* Gamma VN1~VN16 */
+
+struct rm68200 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct gpio_desc 

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

Stratos Zolotas  changed:

   What|Removed |Added

 CC||str...@gmail.com

--- Comment #15 from Stratos Zolotas  ---
Created attachment 137234
  --> https://bugs.freedesktop.org/attachment.cgi?id=137234=edit
dmesg with RX460

Hello,

I have the same messages with one RX460 coming from X and plasmashell on my
system. Running 4.15.0 and mesa 18.0.0 on opensuse Tumbleweed. I'm attaching
some lines from dmesg.

Regards,
Stratos

-- 
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 v3] Fix loading of module radeonfb on PowerMac

[Bartlomiej Zolnierkiewicz]

On Wednesday, January 31, 2018 08:51:23 PM Mathieu Malaterre wrote:
> Bartlomiej,
> 
> On Wed, Jan 31, 2018 at 12:57 PM, Bartlomiej Zolnierkiewicz
>  wrote:
> > On Tuesday, January 30, 2018 02:14:10 PM Mathieu Malaterre wrote:
> >> Bartlomiej,
> >>
> >> On Wed, Jan 3, 2018 at 3:47 PM, Bartlomiej Zolnierkiewicz
> >>  wrote:
> >> >
> >> > On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
> >> >> When the linux kernel is build with (typical kernel ship with Debian
> >> >> installer):
> >> >>
> >> >> CONFIG_FB_OF=y
> >> >> CONFIG_VT_HW_CONSOLE_BINDING=y
> >> >> CONFIG_FB_RADEON=m
> >> >>
> >> >> The offb driver takes precedence over module radeonfb. It is then
> >> >> impossible to load the module, error reported is:
> >> >>
> >> >> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
> >> >> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
> >> >> 0x9800-0x9fff pref]
> >> >> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
> >> >> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
> >> >>
> >> >> This patch reproduce the behavior of the module radeon, so as to make it
> >> >> possible to load radeonfb when offb is first loaded.
> >> >>
> >> >> It should be noticed that `offb_destroy` is never called which explain 
> >> >> the
> >> >> need to skip error detection on the radeon side.
> >> >
> >> > This still needs to be explained more, from my last mail:
> >> >
> >> > "The last put_fb_info() on fb_info should call ->fb_destroy
> >> > (offb_destroy in our case) and remove_conflicting_framebuffers()
> >> > is calling put_fb_info() so there is some extra reference on
> >> > fb_info somewhere preventing it from going away.
> >> >
> >> > Please look into fixing this."
> >>
> >> I am not familiar with the fb stuff internals but here is what I see:
> >>
> >> # modprobe radeonfb
> >>
> >> leads to:
> >>
> >> [   52.058546] bus: 'pci': add driver radeonfb
> >> [   52.058588] bus: 'pci': driver_probe_device: matched device
> >> :00:10.0 with driver radeonfb
> >> [   52.058595] bus: 'pci': really_probe: probing driver radeonfb with
> >> device :00:10.0
> >> [   52.058608] devices_kset: Moving :00:10.0 to end of list
> >> [   52.058613] radeonfb_pci_register BEGIN
> >> [   52.058634] radeonfb :00:10.0: enabling device (0006 -> 0007)
> >> 
> >> [   52.058666] checking generic (9c008000 96000) vs hw (9800 800)
> >> [   52.058667] fb: switching to radeonfb from OFfb ATY,RockHo
> >> [   52.058844] Console: switching to colour dummy device 80x25
> >> [   52.058860] device: 'fb0': device_unregister
> >> [   52.058956] PM: Removing info for No Bus:fb0
> >> [   52.059014] device: 'fb0': device_create_release
> >> 
> >> 
> >> [   52.059048] device: 'vtcon1': device_unregister
> >> [   52.059076] PM: Removing info for No Bus:vtcon1
> >> [   52.059091] device: 'vtcon1': device_create_release
> >> [   52.059107] radeonfb :00:10.0: BAR 0: can't reserve [mem
> >> 0x9800-0x9fff pref]
> >> [   52.256151] aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC
> >> to: a000
> >> [   52.256157] radeonfb (:00:10.0): Found 32768k of DDR 64 bits
> >> wide videoram
> >>
> >> I can confirm that offb_destroy is never called (not sure exactly
> >> why), but in any case the call to radeon_kick_out_firmware_fb happen
> >> much earlier, at least before the put_fb_info.
> >
> > It is okay, put_fb_info() is called indirectly by 
> > radeon_kick_out_firmware_fb()
> >
> > radeon_kick_out_firmware_fb()
> > remove_conflicting_framebuffers()
> > do_remove_conflicting_framebuffers()
> > do_unregister_framebuffer()
> > put_fb_info()
> >
> > offb_destroy() is not called because there is an extra reference on old
> > fb_info (->count == 2):
> >
> > static void put_fb_info(struct fb_info *fb_info)
> > {
> > if (!atomic_dec_and_test(_info->count))
> > return;
> > if (fb_info->fbops->fb_destroy)
> > fb_info->fbops->fb_destroy(fb_info);
> > }
> >
> > The question is why there is an extra reference, probably user-space
> > is still holding the fb_info reference obtained in fb_open() call and
> > fb_release() is never called. Besides not calling fbops->fb_destroy()
> > this also causes missing call of fbops->fb_release() (in fb_release())
> > which some fb drivers are implementing (but not offb.c).
> >
> >> Could you describe a bit more the chain of calls you were thinking of ?
> >
> > Please add WARN_ON(1) to get_fb_info() and put_fb_info() so we can check
> > from the stacktrace if it is actually fb_open() that holds the extra
> > old fb_info reference.
> >
> > drivers/video/fbdev/core/fbmem.c:
> >
> > static struct fb_info *get_fb_info(unsigned int idx)
> > {
> > struct fb_info *fb_info;
> >
> > if (idx >= FB_MAX)
> > 

Re: [PATCH] drm/bridge/synopsys: dsi: use adjusted_mode in mode_set

[Laurent Pinchart]

Hi Philippe,

On Saturday, 3 February 2018 00:41:26 EET Philippe CORNU wrote:
> On 01/29/2018 11:40 AM, Laurent Pinchart wrote:
> > On Monday, 29 January 2018 12:17:37 EET Philippe CORNU wrote:
> >> On 01/29/2018 10:46 AM, Laurent Pinchart wrote:
> >>> On Thursday, 25 January 2018 17:55:04 EET Philippe Cornu wrote:
>  The "adjusted_mode" clock value (ie the real pixel clock) is more
>  accurate than "mode" clock value (ie the panel/bridge requested
>  clock value). It offers a better preciseness for timing
>  computations and allows to reduce the extra dsi bandwidth in
>  burst mode (from ~20% to ~10-12%, hw platform dependant).
> 
>  Signed-off-by: Philippe Cornu 
> >>>
> >>> The adjusted mode is documented as
> >>>
> >>>   /**
> >>>* @adjusted_mode:
> >>>*
> >>>* Internal display timings which can be used by the driver to handle
> >>>* differences between the mode requested by userspace in @mode and
> >>>what
> >>>* is actually programmed into the hardware. It is purely driver
> >>>* implementation defined what exactly this adjusted mode means.
> >>>Usually
> >>>* it is used to store the hardware display timings used between the
> >>>* CRTC and encoder blocks.
> >>>*/
> >>>
> >>> This is easy to handle when the CRTC and encoder are controlled by the
> >>> same driver, as the field is "implementation defined" by a single
> >>> driver. However, when using bridges, there are two drivers involved, and
> >>> they must both agree to meaningfully use the adjusted mode. I can't see
> >>> how to do so without standardizing the meaning of the adjusted mode
> >>> field.
> >>
> >> This is exactly the reason why my first implementation used the dsi
> >> bridge "optional pixel clock" instead of the adjusted_mode (see [1])
> >>
> >> But after digging more into the drm source code, I think using
> >> adjusted_mode instead of the pixel clock here brings more advantages
> >> because:
> >> * adjusted_mode is an argument of bridge mode_set() probably for being
> >> used in any manner, maybe like this :)
> >> * if the bridge "user" (crtc or a master bridge drivers) does not need
> >> to modify its adjusted_mode then mode & adjusted_mode mode_set()
> >> arguments will have the same values so "no consequence" for the bridge.
> >> * if the bridge "user" (crtc or master bridge drivers) needs to adjust
> >> any value of the mode then this adjustment is available for the bridge.
> > 
> > Remember that there can be multiple chained bridges, and a single
> > adjusted mode field.
> > 
> >> * rockchip crtc updates a part of the mode (the clock), stm is doing the
> >> same (see [2]) but any future "user" of the dw_mipi_dsi bridge can
> >> adjust something else (blankings...) and the dw_mipi_dsi bridge will be
> >> then aware of...
> >>
> >> But maybe it is a wrong usage of the "adjusted_mode offer"...
> > 
> > I don't disagree that there's a need for using adjusted values, but I
> > believe we need to create a clear API to do so. Using the adjust_mode
> > field as-is when it's clearly documented as being implementation-defined
> > is asking for trouble. 
> 
> Laurent, do you think we can use "adjusted mode" here in this small 
> patch as the actual 2 "users" of this bridge (rockchip & stm) use both 
> "adjusted mode" in their crtc?

The Synopsys DSI driver might only be used by two display controller drivers 
today, it is nonetheless a standard bridge driver that should not make any 
assumption of a particular use of the adjusted_mode in particular display 
controller drivers. To use the adjusted_mode value in bridge drivers we need 
to standardize its usage, otherwise we'll end up with incompatibilities 
between bridge drivers and display controller drivers.

> >> [1] https://patchwork.freedesktop.org/patch/200240/
> >> [2] https://patchwork.freedesktop.org/patch/200720/
> >>
> >>> Daniel, what's your opinion on this ?
> 
> Daniel, any opinion on the adjusted_mode usage?
> 
>  ---
>  Note: This patch replaces "drm/bridge/synopsys: dsi: add optional
>  pixel clock"
> 
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>  b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index
>  ed8af32f8e52..b926b62e9e33 100644
>  --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>  +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>  @@ -707,20 +707,20 @@ static void dw_mipi_dsi_bridge_mode_set(struct
>  drm_bridge *bridge,
> 
>   clk_prepare_enable(dsi->pclk);
> 
>  -ret = phy_ops->get_lane_mbps(priv_data, mode, dsi->mode_flags,
>  +ret = phy_ops->get_lane_mbps(priv_data, adjusted_mode,
>  dsi->mode_flags,
>    dsi->lanes, dsi->format, 
>  >lane_mbps);
> if (ret)
>   

Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Bartlomiej Zolnierkiewicz]

Hi,

[ dri-devel ML & arch/[score,um] Maintainers added to Cc: ]

On Friday, February 02, 2018 08:59:57 AM Christian Borntraeger wrote:
> On 02/01/2018 07:41 PM, Farhan Ali wrote:
> > The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on 
> > HAS_IOMEM.")'
> > added the HAS_IOMEM dependecy for "Graphics support". This disabled the
> > "Graphics support" menu for S390. But if we enable VT layer for S390,
> > we would also need to enable the dummy console. So let's remove the
> > HAS_IOMEM dependency.
> >
> > Move this dependency to Opencores framebuffer driver which would fail to 
> > build
> > with CONFIG_HAS_IOMEM disabled:
> > 
> > ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!

"Graphics support" menu covers other things (i.e. DRM), I assume that
they were also checked to not break due to this change?

Moreover it seems that after this change "Graphics support" menu will
be also enabled (besides s390) for score, tile and um architectures,
I assume that this is okay?

> > Signed-off-by: Farhan Ali 
> > Tested-by: Dong Jia Shi 
> 
> This also enables several PCI based graphic device driver on s390.
> This makes no sense but they all compile fine so I guess this is ok.
> 
> I think patch 2 and 3 are clearly for the s390 tree, patch 1 seems trivial
> Also ccing Bart. Can we maybe get an ack to carry this patch also via the s390
> tree?
> 
> 
> > ---
> >  drivers/video/Kconfig   | 1 -
> >  drivers/video/fbdev/Kconfig | 2 +-
> >  2 files changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index 3c20af9..41e7ba9 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -3,7 +3,6 @@
> >  #
> > 
> >  menu "Graphics support"
> > -   depends on HAS_IOMEM
> > 
> >  config HAVE_FB_ATMEL
> > bool
> > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > index 2f615b7..ec9c9ce 100644
> > --- a/drivers/video/fbdev/Kconfig
> > +++ b/drivers/video/fbdev/Kconfig
> > @@ -966,7 +966,7 @@ config FB_PVR2
> > 
> >  config FB_OPENCORES
> > tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
> > -   depends on FB && HAS_DMA
> > +   depends on FB && HAS_DMA && HAS_IOMEM
> > select FB_CFB_FILLRECT
> > select FB_CFB_COPYAREA
> > select FB_CFB_IMAGEBLIT

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [PATCH 3/4] drm/ttm: add input parameter force_alloc for ttm_bo_evict_mm

[Christian König]

Am 08.02.2018 um 10:06 schrieb Roger He:

if true, allocate TTM pages regardless of zone global memory
account limit. For suspend, We should avoid TTM memory allocate
failure then result in suspend failure.


Why the extra parameter for amdgpu_bo_evict_vram ?

I can't think of an use case when we don't want this to succeed.

Christian.



Signed-off-by: Roger He 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c |  2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  4 ++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |  4 ++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |  2 +-
  drivers/gpu/drm/nouveau/nouveau_drm.c   |  2 +-
  drivers/gpu/drm/qxl/qxl_object.c|  4 ++--
  drivers/gpu/drm/radeon/radeon_device.c  |  6 +++---
  drivers/gpu/drm/radeon/radeon_object.c  |  5 +++--
  drivers/gpu/drm/radeon/radeon_object.h  |  3 ++-
  drivers/gpu/drm/ttm/ttm_bo.c| 16 ++--
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  6 +++---
  include/drm/ttm/ttm_bo_api.h|  5 -
  12 files changed, 34 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index ee76b46..59ee12c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -763,7 +763,7 @@ static int amdgpu_debugfs_evict_vram(struct seq_file *m, 
void *data)
struct drm_device *dev = node->minor->dev;
struct amdgpu_device *adev = dev->dev_private;
  
-	seq_printf(m, "(%d)\n", amdgpu_bo_evict_vram(adev));

+   seq_printf(m, "(%d)\n", amdgpu_bo_evict_vram(adev, true));
return 0;
  }
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

index e3fa3d7..3c5f9ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2168,7 +2168,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool 
suspend, bool fbcon)
}
}
/* evict vram memory */
-   amdgpu_bo_evict_vram(adev);
+   amdgpu_bo_evict_vram(adev, true);
  
  	amdgpu_fence_driver_suspend(adev);
  
@@ -2178,7 +2178,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool suspend, bool fbcon)

 * This second call to evict vram is to evict the gart page table
 * using the CPU.
 */
-   amdgpu_bo_evict_vram(adev);
+   amdgpu_bo_evict_vram(adev, true);
  
  	pci_save_state(dev->pdev);

if (suspend) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 0338ef6..db813f9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -803,14 +803,14 @@ int amdgpu_bo_unpin(struct amdgpu_bo *bo)
return r;
  }
  
-int amdgpu_bo_evict_vram(struct amdgpu_device *adev)

+int amdgpu_bo_evict_vram(struct amdgpu_device *adev, bool force_alloc)
  {
/* late 2.6.33 fix IGP hibernate - we need pm ops to do this correct */
if (0 && (adev->flags & AMD_IS_APU)) {
/* Useless to evict on IGP chips */
return 0;
}
-   return ttm_bo_evict_mm(>mman.bdev, TTM_PL_VRAM);
+   return ttm_bo_evict_mm(>mman.bdev, TTM_PL_VRAM, force_alloc);
  }
  
  static const char *amdgpu_vram_names[] = {

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index c2b02f5..6724cdc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -227,7 +227,7 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32 
domain,
 u64 min_offset, u64 max_offset,
 u64 *gpu_addr);
  int amdgpu_bo_unpin(struct amdgpu_bo *bo);
-int amdgpu_bo_evict_vram(struct amdgpu_device *adev);
+int amdgpu_bo_evict_vram(struct amdgpu_device *adev, bool force_alloc);
  int amdgpu_bo_init(struct amdgpu_device *adev);
  void amdgpu_bo_fini(struct amdgpu_device *adev);
  int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 8d4a5be..c9627ef 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -702,7 +702,7 @@ nouveau_do_suspend(struct drm_device *dev, bool runtime)
}
  
  	NV_DEBUG(drm, "evicting buffers...\n");

-   ttm_bo_evict_mm(>ttm.bdev, TTM_PL_VRAM);
+   ttm_bo_evict_mm(>ttm.bdev, TTM_PL_VRAM, true);
  
  	NV_DEBUG(drm, "waiting for kernel channels to go idle...\n");

if (drm->cechan) {
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index f6b80fe..d8d26c8 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -350,10 +350,10 @@ int qxl_bo_check_id(struct qxl_device *qdev, struct 
qxl_bo *bo)
  
  int 

Re: [PATCH 2/4] drm/ttm: add bit flag TTM_OPT_FLAG_FORCE_ALLOC

[Christian König]

Am 08.02.2018 um 10:05 schrieb Roger He:

set TTM_OPT_FLAG_FORCE_ALLOC when we are servicing for page
fault routine.

for ttm_mem_global_reserve if in page fault routine, allow the gtt
pages reservation always. because page fault routing already grabbed
system memory and the allowance of this exception is harmless.
Otherwise, it will trigger OOM killer.

the subsequent patche will use this.

v2: keep original behavior except ttm bo with flag no_retry

Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_bo_vm.c  | 6 --
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1 -
  include/drm/ttm/ttm_bo_api.h | 4 +++-
  3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 716e724..f10b8a0 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -224,7 +224,7 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
cvma.vm_page_prot = ttm_io_prot(bo->mem.placement,
cvma.vm_page_prot);
} else {
-   struct ttm_operation_ctx ctx = {
+   struct ttm_operation_ctx ttm_opt_ctx = {
.interruptible = false,
.no_wait_gpu = false
};
@@ -233,8 +233,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
cvma.vm_page_prot = ttm_io_prot(bo->mem.placement,
cvma.vm_page_prot);
  
+		if (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY)

+   ttm_opt_ctx.flags |= TTM_OPT_FLAG_FORCE_ALLOC;


Can't we always set the TTM_OPT_FLAG_FORCE_ALLOC flag here?

I don't see a reason why we should ever not set it.

Christian.


/* Allocate all page at once, most common usage */
-   if (ttm->bdev->driver->ttm_tt_populate(ttm, )) {
+   if (ttm->bdev->driver->ttm_tt_populate(ttm, _opt_ctx)) {
ret = VM_FAULT_OOM;
goto out_io_unlock;
}
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index b122f6e..354e0e1 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -944,7 +944,6 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
i = 0;
  
  	type = ttm_to_type(ttm->page_flags, ttm->caching_state);

-
  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
if (ttm->page_flags & TTM_PAGE_FLAG_DMA32)
goto skip_huge;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 872ff6c..2142639 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -278,7 +278,9 @@ struct ttm_operation_ctx {
  };
  
  /* Allow eviction of reserved BOs */

-#define TTM_OPT_FLAG_ALLOW_RES_EVICT   0x1
+#define TTM_OPT_FLAG_ALLOW_RES_EVICT   0x1
+/* when serving page fault or suspend, allow alloc anyway */
+#define TTM_OPT_FLAG_FORCE_ALLOC   0x2
  
  /**

   * ttm_bo_reference - reference a struct ttm_buffer_object


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

[PATCH v4 5/6] drm/omap: dss: Move platform_device_register from core.c to dss.c probe

[Jyri Sarha]

Register the omapdrm device when we know that dss device probe going
to succeed. This avoids DSS6 and DSS2 omapdrm device registration from
colliding with each other.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/dss/core.c | 26 ++
 drivers/gpu/drm/omapdrm/dss/dss.c  | 19 +++
 2 files changed, 21 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
index acef7ec..6c9f667 100644
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ b/drivers/gpu/drm/omapdrm/dss/core.c
@@ -45,36 +45,14 @@
 #endif
 };
 
-static struct platform_device *omap_drm_device;
-
 static int __init omap_dss_init(void)
 {
-   int r;
-
-   r = platform_register_drivers(omap_dss_drivers,
- ARRAY_SIZE(omap_dss_drivers));
-   if (r)
-   goto err_reg;
-
-   omap_drm_device = platform_device_register_simple("omapdrm", 0, NULL, 
0);
-   if (IS_ERR(omap_drm_device)) {
-   r = PTR_ERR(omap_drm_device);
-   goto err_reg;
-   }
-
-   return 0;
-
-err_reg:
-   platform_unregister_drivers(omap_dss_drivers,
-   ARRAY_SIZE(omap_dss_drivers));
-
-   return r;
+   return platform_register_drivers(omap_dss_drivers,
+ARRAY_SIZE(omap_dss_drivers));
 }
 
 static void __exit omap_dss_exit(void)
 {
-   platform_device_unregister(omap_drm_device);
-
platform_unregister_drivers(omap_dss_drivers,
ARRAY_SIZE(omap_dss_drivers));
 }
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 04300b2..3cfe4a7 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -1298,6 +1298,17 @@ static int dss_video_pll_probe(struct platform_device 
*pdev)
{ /* sentinel */ }
 };
 
+static struct platform_device *omap_drm_device = NULL;
+
+static int initialize_omapdrm_device(void)
+{
+   omap_drm_device = platform_device_register_simple("omapdrm", 0, NULL, 
0);
+   if (IS_ERR(omap_drm_device))
+   return PTR_ERR(omap_drm_device);
+
+   return 0;
+}
+
 static int dss_bind(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -1359,6 +1370,10 @@ static int dss_bind(struct device *dev)
if (r)
goto err_component;
 
+   r = initialize_omapdrm_device();
+   if (r)
+   goto err_omapdrm_device;
+
dss_debugfs_create_file("dss", dss_dump_regs);
 
pm_set_vt_switch(0);
@@ -1368,6 +1383,8 @@ static int dss_bind(struct device *dev)
 
return 0;
 
+err_omapdrm_device:
+   component_unbind_all(>dev, NULL);
 err_component:
 err_runtime_get:
pm_runtime_disable(>dev);
@@ -1390,6 +1407,8 @@ static void dss_unbind(struct device *dev)
 
omapdss_set_is_initialized(false);
 
+   platform_device_unregister(omap_drm_device);
+
component_unbind_all(>dev, NULL);
 
if (dss.video1_pll)
-- 
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 v4 4/6] drm/omap: move common stuff from dss.h to omapdss.h

[Jyri Sarha]

From: Tomi Valkeinen 

The new DSS6 driver needs some structs and defines which are currently
in dss.h, which is for the old DSS driver.

Move the required structs and defines from dss.h to omapdss.h.

Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/dss/dss.h | 37 ---
 drivers/gpu/drm/omapdrm/dss/omapdss.h | 37 +++
 2 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
b/drivers/gpu/drm/omapdrm/dss/dss.h
index 6374e57e..7347cb9 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -65,14 +65,6 @@
pr_warn("omapdss: " format, ##__VA_ARGS__)
 #endif
 
-/* OMAP TRM gives bitfields as start:end, where start is the higher bit
-   number. For example 7:0 */
-#define FLD_MASK(start, end)   (((1 << ((start) - (end) + 1)) - 1) << (end))
-#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end))
-#define FLD_GET(val, start, end) (((val) & FLD_MASK(start, end)) >> (end))
-#define FLD_MOD(orig, val, start, end) \
-   (((orig) & ~FLD_MASK(start, end)) | FLD_VAL(val, start, end))
-
 enum dss_model {
DSS_MODEL_OMAP2,
DSS_MODEL_OMAP3,
@@ -81,12 +73,6 @@ enum dss_model {
DSS_MODEL_DRA7,
 };
 
-enum dss_io_pad_mode {
-   DSS_IO_PAD_MODE_RESET,
-   DSS_IO_PAD_MODE_RFBI,
-   DSS_IO_PAD_MODE_BYPASS,
-};
-
 enum dss_hdmi_venc_clk_source_select {
DSS_VENC_TV_CLK = 0,
DSS_HDMI_M_PCLK = 1,
@@ -209,29 +195,6 @@ struct dss_reg_field {
u8 start, end;
 };
 
-struct dispc_clock_info {
-   /* rates that we get with dividers below */
-   unsigned long lck;
-   unsigned long pck;
-
-   /* dividers */
-   u16 lck_div;
-   u16 pck_div;
-};
-
-struct dss_lcd_mgr_config {
-   enum dss_io_pad_mode io_pad_mode;
-
-   bool stallmode;
-   bool fifohandcheck;
-
-   struct dispc_clock_info clock_info;
-
-   int video_port_width;
-
-   int lcden_sig_polarity;
-};
-
 struct seq_file;
 struct platform_device;
 
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 4b2068e..8395d5b 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -624,6 +624,43 @@ static inline bool omapdss_device_is_enabled(struct 
omap_dss_device *dssdev)
 struct omap_dss_device *
 omapdss_of_find_source_for_first_ep(struct device_node *node);
 
+/* OMAP TRM gives bitfields as start:end, where start is the higher bit
+   number. For example 7:0 */
+#define FLD_MASK(start, end)   (((1 << ((start) - (end) + 1)) - 1) << (end))
+#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end))
+#define FLD_GET(val, start, end) (((val) & FLD_MASK(start, end)) >> (end))
+#define FLD_MOD(orig, val, start, end) \
+   (((orig) & ~FLD_MASK(start, end)) | FLD_VAL(val, start, end))
+
+enum dss_io_pad_mode {
+   DSS_IO_PAD_MODE_RESET,
+   DSS_IO_PAD_MODE_RFBI,
+   DSS_IO_PAD_MODE_BYPASS,
+};
+
+struct dispc_clock_info {
+   /* rates that we get with dividers below */
+   unsigned long lck;
+   unsigned long pck;
+
+   /* dividers */
+   u16 lck_div;
+   u16 pck_div;
+};
+
+struct dss_lcd_mgr_config {
+   enum dss_io_pad_mode io_pad_mode;
+
+   bool stallmode;
+   bool fifohandcheck;
+
+   struct dispc_clock_info clock_info;
+
+   int video_port_width;
+
+   int lcden_sig_polarity;
+};
+
 void omapdss_set_is_initialized(bool set);
 
 struct device_node *dss_of_port_get_parent_device(struct device_node *port);
-- 
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 v3 3/3] drm/omap: Make omapdss API more generic

[Tomi Valkeinen]

On 08/02/18 13:43, Jyri Sarha wrote:
> Argh, sorry I forgot about these in the previous post. (And the comment
> for "drm/omap: Fail probe if irq registration fails").
> 
> On 02/08/18 10:53, Tomi Valkeinen wrote:
>> On 07/02/18 16:11, Jyri Sarha wrote:
>>> The new omapdss API is HW independent and cleans up some of the DSS5
>>> specific hacks from the omapdrm side and gets rid off the DSS5 IRQ
>>> register bits and replace them with HW independent generic u64 based
>>> macros. The new macros make it more straight forward to implement the
>>> 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 
>> 
>>
>> Can you add a comment here that describes the layout of the u64 irq bits
>> container.
> Would this do:
> 
> /*
>  * Based on the above 2 defines the bellow defines describe following
>  * u64 IRQ bits:
>  * bit group |dev |mrg0|mrg1|mrg2|mrg3|mrg4|mrg5|mrg6|mrg7| olv0-7 
> | |
>  * bit use   |D   |FEOL|FEOL|FEOL|FEOL|FEOL|FEOL|FEOL|FEOL||| |
> | | | |
>  * bit number|0-3 |4-7 |8-11|    12-35    |  36-43  | 
> 44-63  |
>  *
>  * device bits: D = OCP error
>  * mgr bits:    F = frame done, E = vsync even, O = vsync odd,
>  * ovl bits:    U = fifo underflow
>  */

I think it would be enough just saying that first 4 bits are reserved
for generic irqs, then 8 managers each with 4 bits, and then 8 overlays
with 1 bit. The defines below are readable, but if there's a comment
with a hint on how to decipher them, everything becomes much clearer.

But now that you already wrote a full description, it's fine =).
Although more work to change it later.

>>> +#define DSS_IRQ_DEVICE_OCP_ERR BIT_ULL(0)
>>> +
>>> +#define DSS_IRQ_MGR_BIT_N(ch, bit) (4 + 4 * ch + bit)
>>> +#define DSS_IRQ_OVL_BIT_N(ovl, bit) \
>>> +   (DSS_IRQ_MGR_BIT_N(DSS_MAX_CHANNELS, 0) + 1 * ovl + bit)
>>> +
>>> +#define DSS_IRQ_MGR_BIT(ch, bit)   BIT_ULL(DSS_IRQ_MGR_BIT_N(ch, bit))
>>> +#define DSS_IRQ_OVL_BIT(ovl, bit)  BIT_ULL(DSS_IRQ_OVL_BIT_N(ovl, bit))
>>> +
>>> +#define DSS_IRQ_MGR_MASK(ch) \
>>> +   GENMASK_ULL(DSS_IRQ_MGR_BIT_N(ch, 3), DSS_IRQ_MGR_BIT_N(ch, 0))
>>> +#define DSS_IRQ_OVL_MASK(ovl) \
>>> +   GENMASK_ULL(DSS_IRQ_OVL_BIT_N(ovl, 0), DSS_IRQ_OVL_BIT_N(ovl, 0))
>>> +
>>> +#define DSS_IRQ_MGR_FRAME_DONE(ch) DSS_IRQ_MGR_BIT(ch, 0)
>>> +#define DSS_IRQ_MGR_VSYNC_EVEN(ch) DSS_IRQ_MGR_BIT(ch, 1)
>>> +#define DSS_IRQ_MGR_VSYNC_ODD(ch)  DSS_IRQ_MGR_BIT(ch, 2)
>>> +#define DSS_IRQ_MGR_SYNC_LOST(ch)  DSS_IRQ_MGR_BIT(ch, 3)
>>> +
>>> +#define DSS_IRQ_OVL_FIFO_UNDERFLOW(ovl)DSS_IRQ_OVL_BIT(ovl, 0)
>>>  
>>>  struct omap_dss_device;
>>>  struct dss_lcd_mgr_config;
>>> @@ -678,9 +670,8 @@ void dss_mgr_unregister_framedone_handler(enum 
>>> omap_channel channel,
>>>  /* dispc ops */
>>>  
>>>  struct dispc_ops {
>>> -   u32 (*read_irqstatus)(void);
>>> -   void (*clear_irqstatus)(u32 mask);
>>> -   void (*write_irqenable)(u32 mask);
>>> +   u64 (*read_and_clear_irqstatus)(void);
>>> +   void (*write_irqenable)(u64 enable);
>>>  
>>> int (*request_irq)(irq_handler_t handler, void *dev_id);
>>> void (*free_irq)(void *dev_id);
>>> @@ -694,13 +685,12 @@ struct dispc_ops {
>>> const char *(*get_ovl_name)(enum omap_plane_id plane);
>>> const char *(*get_mgr_name)(enum omap_channel channel);
>>>  
>>> +   bool (*mgr_has_framedone)(enum omap_channel channel);
>>> +
>>> u32 (*get_memory_bandwidth_limit)(void);
>>>  
>>> void (*mgr_enable)(enum omap_channel channel, bool enable);
>>> bool (*mgr_is_enabled)(enum omap_channel channel);
>>> -   u32 (*mgr_get_vsync_irq)(enum omap_channel channel);
>>> -   u32 (*mgr_get_framedone_irq)(enum omap_channel channel);
>>> -   u32 (*mgr_get_sync_lost_irq)(enum omap_channel channel);
>>> bool (*mgr_go_busy)(enum omap_channel channel);
>>> void (*mgr_go)(enum omap_channel channel);
>>> void (*mgr_set_lcd_config)(enum omap_channel channel,
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
>>> b/drivers/gpu/drm/omapdrm/omap_crtc.c
>>> index fee8a63..f7e1668 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
>>> @@ -149,7 +149,7 @@ static void omap_crtc_set_enabled(struct drm_crtc 
>>> *crtc, bool enable)
>>> struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>>> enum omap_channel channel = omap_crtc->channel;
>>> struct omap_irq_wait *wait;
>>> -   u32 framedone_irq, vsync_irq;
>>> +   u64 vsync_irq, framedone_irq;
>>> int ret;
>>>  
>>> if (WARN_ON(omap_crtc->enabled == enable))
>>> @@ -169,8 +169,10 @@ static void omap_crtc_set_enabled(struct drm_crtc 
>>> *crtc, bool enable)
>>> omap_crtc->ignore_digit_sync_lost = true;
>>> }
>>>  
>>> -   framedone_irq = priv->dispc_ops->mgr_get_framedone_irq(channel);
>>> -   vsync_irq = priv->dispc_ops->mgr_get_vsync_irq(channel);
>>> +
>>> +   vsync_irq = (DSS_IRQ_MGR_VSYNC_EVEN(channel) |
>>> +

[Bug 105005] No image after downtime (RX460)

[bugzilla-daemon]

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

--- Comment #7 from Dmitry  ---
After rebooting done due to this problem. Without the screen it is problematic
to do, immediately after.

4.14.15-1

-- 
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 v3 3/3] drm/omap: Make omapdss API more generic

[Jyri Sarha]

Argh, sorry I forgot about these in the previous post. (And the comment
for "drm/omap: Fail probe if irq registration fails").

On 02/08/18 10:53, Tomi Valkeinen wrote:
> On 07/02/18 16:11, Jyri Sarha wrote:
>> The new omapdss API is HW independent and cleans up some of the DSS5
>> specific hacks from the omapdrm side and gets rid off the DSS5 IRQ
>> register bits and replace them with HW independent generic u64 based
>> macros. The new macros make it more straight forward to implement the
>> 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 
> 
>
> Can you add a comment here that describes the layout of the u64 irq bits
> container.
Would this do:

/*
 * Based on the above 2 defines the bellow defines describe following
 * u64 IRQ bits:
 * bit group |dev |mrg0|mrg1|mrg2|mrg3|mrg4|mrg5|mrg6|mrg7| olv0-7 
| |
 * bit use   |D   |FEOL|FEOL|FEOL|FEOL|FEOL|FEOL|FEOL|FEOL||| |
| | | |
 * bit number|0-3 |4-7 |8-11|    12-35    |  36-43  | 
44-63  |
 *
 * device bits: D = OCP error
 * mgr bits:    F = frame done, E = vsync even, O = vsync odd,
 * ovl bits:    U = fifo underflow
 */

>> +#define DSS_IRQ_DEVICE_OCP_ERR  BIT_ULL(0)
>> +
>> +#define DSS_IRQ_MGR_BIT_N(ch, bit)  (4 + 4 * ch + bit)
>> +#define DSS_IRQ_OVL_BIT_N(ovl, bit) \
>> +(DSS_IRQ_MGR_BIT_N(DSS_MAX_CHANNELS, 0) + 1 * ovl + bit)
>> +
>> +#define DSS_IRQ_MGR_BIT(ch, bit)BIT_ULL(DSS_IRQ_MGR_BIT_N(ch, bit))
>> +#define DSS_IRQ_OVL_BIT(ovl, bit)   BIT_ULL(DSS_IRQ_OVL_BIT_N(ovl, bit))
>> +
>> +#define DSS_IRQ_MGR_MASK(ch) \
>> +GENMASK_ULL(DSS_IRQ_MGR_BIT_N(ch, 3), DSS_IRQ_MGR_BIT_N(ch, 0))
>> +#define DSS_IRQ_OVL_MASK(ovl) \
>> +GENMASK_ULL(DSS_IRQ_OVL_BIT_N(ovl, 0), DSS_IRQ_OVL_BIT_N(ovl, 0))
>> +
>> +#define DSS_IRQ_MGR_FRAME_DONE(ch)  DSS_IRQ_MGR_BIT(ch, 0)
>> +#define DSS_IRQ_MGR_VSYNC_EVEN(ch)  DSS_IRQ_MGR_BIT(ch, 1)
>> +#define DSS_IRQ_MGR_VSYNC_ODD(ch)   DSS_IRQ_MGR_BIT(ch, 2)
>> +#define DSS_IRQ_MGR_SYNC_LOST(ch)   DSS_IRQ_MGR_BIT(ch, 3)
>> +
>> +#define DSS_IRQ_OVL_FIFO_UNDERFLOW(ovl) DSS_IRQ_OVL_BIT(ovl, 0)
>>  
>>  struct omap_dss_device;
>>  struct dss_lcd_mgr_config;
>> @@ -678,9 +670,8 @@ void dss_mgr_unregister_framedone_handler(enum 
>> omap_channel channel,
>>  /* dispc ops */
>>  
>>  struct dispc_ops {
>> -u32 (*read_irqstatus)(void);
>> -void (*clear_irqstatus)(u32 mask);
>> -void (*write_irqenable)(u32 mask);
>> +u64 (*read_and_clear_irqstatus)(void);
>> +void (*write_irqenable)(u64 enable);
>>  
>>  int (*request_irq)(irq_handler_t handler, void *dev_id);
>>  void (*free_irq)(void *dev_id);
>> @@ -694,13 +685,12 @@ struct dispc_ops {
>>  const char *(*get_ovl_name)(enum omap_plane_id plane);
>>  const char *(*get_mgr_name)(enum omap_channel channel);
>>  
>> +bool (*mgr_has_framedone)(enum omap_channel channel);
>> +
>>  u32 (*get_memory_bandwidth_limit)(void);
>>  
>>  void (*mgr_enable)(enum omap_channel channel, bool enable);
>>  bool (*mgr_is_enabled)(enum omap_channel channel);
>> -u32 (*mgr_get_vsync_irq)(enum omap_channel channel);
>> -u32 (*mgr_get_framedone_irq)(enum omap_channel channel);
>> -u32 (*mgr_get_sync_lost_irq)(enum omap_channel channel);
>>  bool (*mgr_go_busy)(enum omap_channel channel);
>>  void (*mgr_go)(enum omap_channel channel);
>>  void (*mgr_set_lcd_config)(enum omap_channel channel,
>> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
>> b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> index fee8a63..f7e1668 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> @@ -149,7 +149,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
>> bool enable)
>>  struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>>  enum omap_channel channel = omap_crtc->channel;
>>  struct omap_irq_wait *wait;
>> -u32 framedone_irq, vsync_irq;
>> +u64 vsync_irq, framedone_irq;
>>  int ret;
>>  
>>  if (WARN_ON(omap_crtc->enabled == enable))
>> @@ -169,8 +169,10 @@ static void omap_crtc_set_enabled(struct drm_crtc 
>> *crtc, bool enable)
>>  omap_crtc->ignore_digit_sync_lost = true;
>>  }
>>  
>> -framedone_irq = priv->dispc_ops->mgr_get_framedone_irq(channel);
>> -vsync_irq = priv->dispc_ops->mgr_get_vsync_irq(channel);
>> +
>> +vsync_irq = (DSS_IRQ_MGR_VSYNC_EVEN(channel) |
>> + DSS_IRQ_MGR_VSYNC_ODD(channel));
>> +framedone_irq = DSS_IRQ_MGR_FRAME_DONE(channel);
>>  
>>  if (enable) {
>>  wait = omap_irq_wait_init(dev, vsync_irq, 1);
>> @@ -184,7 +186,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
>> bool enable)
>>   * even and odd frames.
>>   */
>>  
>> -if (framedone_irq)
>> +if (priv->dispc_ops->mgr_has_framedone(channel))
> Is it valid to do DSS_IRQ_MGR_FRAME_DONE(channel) above, even if 

[PATCH] dma-buf/sw_sync: Fix kerneldoc warnings

[Chris Wilson]

drivers/dma-buf/sw_sync.c:248: warning: No description found for parameter 'obj'
drivers/dma-buf/sw_sync.c:248: warning: No description found for parameter 
'value'
drivers/dma-buf/sw_sync.c:248: warning: Excess function parameter 'parent' 
description in 'sync_pt_create'
drivers/dma-buf/sw_sync.c:248: warning: Excess function parameter 'inc' 
description in 'sync_pt_create'

Signed-off-by: Chris Wilson 
---
 drivers/dma-buf/sw_sync.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 7779bdbd18d1..3d78ca89a605 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -235,10 +235,10 @@ static void sync_timeline_signal(struct sync_timeline 
*obj, unsigned int inc)
 
 /**
  * sync_pt_create() - creates a sync pt
- * @parent:fence's parent sync_timeline
- * @inc:   value of the fence
+ * @obj:   parent sync_timeline
+ * @value: value of the fence
  *
- * Creates a new sync_pt as a child of @parent.  @size bytes will be
+ * Creates a new sync_pt (fence) as a child of @parent.  @size bytes will be
  * allocated allowing for implementation specific data to be kept after
  * the generic sync_timeline struct. Returns the sync_pt object or
  * NULL in case of error.
-- 
2.16.1

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