[PATCH] drm/amdgpu: add parameter to allocate high priority contexts v9

2017-04-25 Thread Andres Rodriguez
Add a new context creation parameter to express a global context priority.

The priority ranking in descending order is as follows:
 * AMDGPU_CTX_PRIORITY_HIGH
 * AMDGPU_CTX_PRIORITY_NORMAL
 * AMDGPU_CTX_PRIORITY_LOW

The driver will attempt to schedule work to the hardware according to
the priorities. No latency or throughput guarantees are provided by
this patch.

This interface intends to service the EGL_IMG_context_priority
extension, and vulkan equivalents.

v2: Instead of using flags, repurpose __pad
v3: Swap enum values of _NORMAL _HIGH for backwards compatibility
v4: Validate usermode priority and store it
v5: Move priority validation into amdgpu_ctx_ioctl(), headline reword
v6: add UAPI note regarding priorities requiring CAP_SYS_ADMIN
v7: remove ctx->priority
v8: added AMDGPU_CTX_PRIORITY_LOW, s/CAP_SYS_ADMIN/CAP_SYS_NICE
v9: change the priority parameter to __s32

Reviewed-by: Emil Velikov 
Reviewed-by: Christian König 
Signed-off-by: Andres Rodriguez 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   | 38 ---
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h |  4 ++-
 include/uapi/drm/amdgpu_drm.h |  8 +-
 3 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index b43..af75571 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -25,11 +25,19 @@
 #include 
 #include "amdgpu.h"
 
-static int amdgpu_ctx_init(struct amdgpu_device *adev, struct amdgpu_ctx *ctx)
+static int amdgpu_ctx_init(struct amdgpu_device *adev,
+  enum amd_sched_priority priority,
+  struct amdgpu_ctx *ctx)
 {
unsigned i, j;
int r;
 
+   if (priority < 0 || priority >= AMD_SCHED_PRIORITY_MAX)
+   return -EINVAL;
+
+   if (priority >= AMD_SCHED_PRIORITY_HIGH && !capable(CAP_SYS_NICE))
+   return -EACCES;
+
memset(ctx, 0, sizeof(*ctx));
ctx->adev = adev;
kref_init(>refcount);
@@ -51,7 +59,7 @@ static int amdgpu_ctx_init(struct amdgpu_device *adev, struct 
amdgpu_ctx *ctx)
struct amdgpu_ring *ring = adev->rings[i];
struct amd_sched_rq *rq;
 
-   rq = >sched.sched_rq[AMD_SCHED_PRIORITY_NORMAL];
+   rq = >sched.sched_rq[priority];
r = amd_sched_entity_init(>sched, >rings[i].entity,
  rq, amdgpu_sched_jobs);
if (r)
@@ -90,6 +98,7 @@ static void amdgpu_ctx_fini(struct amdgpu_ctx *ctx)
 
 static int amdgpu_ctx_alloc(struct amdgpu_device *adev,
struct amdgpu_fpriv *fpriv,
+   enum amd_sched_priority priority,
uint32_t *id)
 {
struct amdgpu_ctx_mgr *mgr = >ctx_mgr;
@@ -107,8 +116,9 @@ static int amdgpu_ctx_alloc(struct amdgpu_device *adev,
kfree(ctx);
return r;
}
+
*id = (uint32_t)r;
-   r = amdgpu_ctx_init(adev, ctx);
+   r = amdgpu_ctx_init(adev, priority, ctx);
if (r) {
idr_remove(>ctx_handles, *id);
*id = 0;
@@ -182,11 +192,27 @@ static int amdgpu_ctx_query(struct amdgpu_device *adev,
return 0;
 }
 
+static enum amd_sched_priority amdgpu_to_sched_priority(int amdgpu_priority)
+{
+   switch (amdgpu_priority) {
+   case AMDGPU_CTX_PRIORITY_HIGH:
+   return AMD_SCHED_PRIORITY_HIGH;
+   case AMDGPU_CTX_PRIORITY_NORMAL:
+   return AMD_SCHED_PRIORITY_NORMAL;
+   case AMDGPU_CTX_PRIORITY_LOW:
+   return AMD_SCHED_PRIORITY_LOW;
+   default:
+   WARN(1, "Invalid context priority %d\n", amdgpu_priority);
+   return AMD_SCHED_PRIORITY_NORMAL;
+   }
+}
+
 int amdgpu_ctx_ioctl(struct drm_device *dev, void *data,
 struct drm_file *filp)
 {
int r;
uint32_t id;
+   enum amd_sched_priority priority;
 
union drm_amdgpu_ctx *args = data;
struct amdgpu_device *adev = dev->dev_private;
@@ -194,10 +220,14 @@ int amdgpu_ctx_ioctl(struct drm_device *dev, void *data,
 
r = 0;
id = args->in.ctx_id;
+   priority = amdgpu_to_sched_priority(args->in.priority);
+
+   if (priority >= AMD_SCHED_PRIORITY_MAX)
+   return -EINVAL;
 
switch (args->in.op) {
case AMDGPU_CTX_OP_ALLOC_CTX:
-   r = amdgpu_ctx_alloc(adev, fpriv, );
+   r = amdgpu_ctx_alloc(adev, fpriv, priority, );
args->out.alloc.ctx_id = id;
break;
case AMDGPU_CTX_OP_FREE_CTX:
diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.h 
b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.h
index 8cb41d3..613e682 100644
--- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.h

[RFC] drm/amdgpu: avoid scheduling on fence status query

2017-04-25 Thread Andres Rodriguez
When amdgpu_cs_wait_ioctl is called with a timeout of zero, the caller
is just interested in the current status of the fence.

The default implementation of dma_fence_wait_timeout on an unsignaled
fence will always call schedule_timeout(), even if the timeout is zero.
This may result in significant overhead for clients that heavily use
this interface.

This patch avoids the dma_fence_wait_timeout overhead by directly
checking the fence status.

Signed-off-by: Andres Rodriguez 
---

I'm not sure if we should be working around this issue at the amdgpu
level, or at fixing the dma_fence_default_wait level instead.

Source2 games like dota2 are affected by this overhead. This patch
improves dota2 perf on a i7-6700k+RX480 system from 72fps->81fps.

Patch is for drm-next-4.12-wip since this branch is where we operate
on dma_fences directly.

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 5 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h  | 1 +
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index ec71b93..67a5c9f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1168,7 +1168,10 @@ int amdgpu_cs_wait_ioctl(struct drm_device *dev, void 
*data,
if (IS_ERR(fence))
r = PTR_ERR(fence);
else if (fence) {
-   r = dma_fence_wait_timeout(fence, true, timeout);
+   if (timeout)
+   r = dma_fence_wait_timeout(fence, true, timeout);
+   else
+   r = amdgpu_fence_test_signaled(fence);
dma_fence_put(fence);
} else
r = 1;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 7b60fb7..779a382 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -122,6 +122,11 @@ static u32 amdgpu_fence_read(struct amdgpu_ring *ring)
return seq;
 }
 
+bool amdgpu_fence_test_signaled(struct dma_fence *fence)
+{
+   return test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags);
+}
+
 /**
  * amdgpu_fence_emit - emit a fence on the requested ring
  *
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 93c..6bbd31d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -84,6 +84,7 @@ int amdgpu_fence_driver_start_ring(struct amdgpu_ring *ring,
   unsigned irq_type);
 void amdgpu_fence_driver_suspend(struct amdgpu_device *adev);
 void amdgpu_fence_driver_resume(struct amdgpu_device *adev);
+bool amdgpu_fence_test_signaled(struct dma_fence *fence);
 int amdgpu_fence_emit(struct amdgpu_ring *ring, struct dma_fence **fence);
 void amdgpu_fence_process(struct amdgpu_ring *ring);
 int amdgpu_fence_wait_empty(struct amdgpu_ring *ring);
-- 
2.9.3

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: add parameter to allocate high priority contexts v8

2017-04-25 Thread Alex Deucher
On Tue, Apr 25, 2017 at 4:28 PM, Andres Rodriguez  wrote:
>
>
> On 2017-04-25 02:01 PM, Nicolai Hähnle wrote:
>>
>> On 24.04.2017 18:20, Andres Rodriguez wrote:
>>>
>>> Add a new context creation parameter to express a global context
>>> priority.
>>>
>>> The priority ranking in descending order is as follows:
>>>  * AMDGPU_CTX_PRIORITY_HIGH
>>>  * AMDGPU_CTX_PRIORITY_NORMAL
>>>  * AMDGPU_CTX_PRIORITY_LOW
>>>
>>> The driver will attempt to schedule work to the hardware according to
>>> the priorities. No latency or throughput guarantees are provided by
>>> this patch.
>>>
>>> This interface intends to service the EGL_IMG_context_priority
>>> extension, and vulkan equivalents.
>>>
>>> v2: Instead of using flags, repurpose __pad
>>> v3: Swap enum values of _NORMAL _HIGH for backwards compatibility
>>> v4: Validate usermode priority and store it
>>> v5: Move priority validation into amdgpu_ctx_ioctl(), headline reword
>>> v6: add UAPI note regarding priorities requiring CAP_SYS_ADMIN
>>> v7: remove ctx->priority
>>> v8: added AMDGPU_CTX_PRIORITY_LOW, s/CAP_SYS_ADMIN/CAP_SYS_NICE
>>>
>>> Reviewed-by: Emil Velikov 
>>> Reviewed-by: Christian König 
>>> Signed-off-by: Andres Rodriguez 
>>
>>
>> I didn't follow all the discussion, so feel free to shut me up if this
>> has already been discussed, but...
>>
>>
>> [snip]
>>>
>>> +/* Context priority level */
>>> +#define AMDGPU_CTX_PRIORITY_NORMAL0
>>> +#define AMDGPU_CTX_PRIORITY_LOW1
>>> +/* Selecting a priority above NORMAL requires CAP_SYS_ADMIN */
>>> +#define AMDGPU_CTX_PRIORITY_HIGH2
>>> +#define AMDGPU_CTX_PRIORITY_NUM3
>>
>>
>> I get that normal priority needs to be 0 for backwards compatibility,
>> but having LOW between NORMAL and HIGH is still odd. Have you considered
>> using signed integers as a way to fix that?
>
>
> Thanks for the suggestion, that should make it a lot cleaner.

Maybe make the range -1023 to 1023 for consistency with the similar
proposed interface on Intel?
https://lists.freedesktop.org/archives/intel-gfx/2017-April/126155.html

Alex


>
> Regards,
> Andres
>
>
>>
>> (AMDGPU_CTX_PRIORITY_NUM doesn't seem to be used anywhere...)
>>
>> Cheers,
>> Nicolai
>>
>>
>>> +
>>>  struct drm_amdgpu_ctx_in {
>>>  /** AMDGPU_CTX_OP_* */
>>>  __u32op;
>>>  /** For future use, no flags defined so far */
>>>  __u32flags;
>>>  __u32ctx_id;
>>> -__u32_pad;
>>> +__u32priority;
>>>  };
>>>
>>>  union drm_amdgpu_ctx_out {
>>>  struct {
>>>  __u32ctx_id;
>>>  __u32_pad;
>>>  } alloc;
>>>
>>>  struct {
>>>  /** For future use, no flags defined so far */
>>>  __u64flags;
>>>  /** Number of resets caused by this context so far. */
>>>  __u32hangs;
>>>  /** Reset status since the last call of the ioctl. */
>>>  __u32reset_status;
>>>  } state;
>>>  };
>>>
>>>  union drm_amdgpu_ctx {
>>>  struct drm_amdgpu_ctx_in in;
>>>
>>
>>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 2/2] drm/amdgpu: Fix use of interruptible waiting

2017-04-25 Thread Michel Dänzer
On 26/04/17 06:25 AM, Alex Xie wrote:
> 1. The wait is short. There is not much benefit by
> interruptible waiting.
> 2. In this function and caller functions, the error
> handling for such interrupt is complicated and risky.
> 
> Change-Id: I289674ecd3f5ef20c93fe63e33df6d668b3c2edc
> Signed-off-by: Alex Xie 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 43082bf..c006cc4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -227,7 +227,7 @@ int amdgpu_crtc_prepare_flip(
>   new_abo = gem_to_amdgpu_bo(obj);
>  
>   /* pin the new buffer */
> - r = amdgpu_bo_reserve(new_abo, false);
> + r = amdgpu_bo_reserve(new_abo, true);
>   if (unlikely(r != 0)) {
>   DRM_ERROR("failed to reserve new abo buffer before flip\n");
>   goto cleanup;
> 

I'm afraid we have no choice but to use interruptible here, because this
code runs as part of an ioctl (DRM_IOCTL_MODE_PAGE_FLIP).


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [RFC] drm/amdgpu: avoid scheduling on fence status query

2017-04-25 Thread Michel Dänzer
On 26/04/17 09:28 AM, Andres Rodriguez wrote:
> When amdgpu_cs_wait_ioctl is called with a timeout of zero, the caller
> is just interested in the current status of the fence.
> 
> The default implementation of dma_fence_wait_timeout on an unsignaled
> fence will always call schedule_timeout(), even if the timeout is zero.
> This may result in significant overhead for clients that heavily use
> this interface.
> 
> This patch avoids the dma_fence_wait_timeout overhead by directly
> checking the fence status.
> 
> Signed-off-by: Andres Rodriguez 
> ---
> 
> I'm not sure if we should be working around this issue at the amdgpu
> level, or at fixing the dma_fence_default_wait level instead.

I'd say the latter, assuming it can give the same benefit.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v4)

2017-04-25 Thread Dave Airlie
From: Dave Airlie 

This creates a new command submission chunk for amdgpu
to add in and out sync objects around the submission.

Sync objects are managed via the drm syncobj ioctls.

The command submission interface is enhanced with two new
chunks, one for syncobj pre submission dependencies,
and one for post submission sync obj signalling,
and just takes a list of handles for each.

This is based on work originally done by David Zhou at AMD,
with input from Christian Konig on what things should look like.

In theory VkFences could be backed with sync objects and
just get passed into the cs as syncobj handles as well.

NOTE: this interface addition needs a version bump to expose
it to userspace.

v1.1: keep file reference on import.
v2: move to using syncobjs
v2.1: change some APIs to just use p pointer.
v3: make more robust against CS failures, we now add the
wait sems but only remove them once the CS job has been
submitted.
v4: rewrite names of API and base on new syncobj code.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 81 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  2 +-
 include/uapi/drm/amdgpu_drm.h   |  6 +++
 3 files changed, 87 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index df25b32..e86c832 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "amdgpu_trace.h"
 
@@ -217,6 +218,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void 
*data)
break;
 
case AMDGPU_CHUNK_ID_DEPENDENCIES:
+   case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
+   case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
break;
 
default:
@@ -1008,6 +1011,40 @@ static int amdgpu_process_fence_dep(struct 
amdgpu_cs_parser *p,
return 0;
 }
 
+static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
+uint32_t handle)
+{
+   int r;
+   struct dma_fence *fence;
+   r = drm_syncobj_fence_get(p->filp, handle, );
+   if (r)
+   return r;
+
+   r = amdgpu_sync_fence(p->adev, >job->sync, fence);
+   dma_fence_put(fence);
+
+   return r;
+}
+
+static int amdgpu_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
+struct amdgpu_cs_chunk *chunk)
+{
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_sem *deps;
+
+   deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+   for (i = 0; i < num_deps; ++i) {
+   r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle);
+   if (r)
+   return r;
+   }
+   return 0;
+}
+
 static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
  struct amdgpu_cs_parser *p)
 {
@@ -1022,12 +1059,54 @@ static int amdgpu_cs_dependencies(struct amdgpu_device 
*adev,
r = amdgpu_process_fence_dep(p, chunk);
if (r)
return r;
+   } else if (chunk->chunk_id == AMDGPU_CHUNK_ID_SYNCOBJ_IN) {
+   r = amdgpu_process_syncobj_in_dep(p, chunk);
+   if (r)
+   return r;
}
}
 
return 0;
 }
 
+static int amdgpu_process_syncobj_out_dep(struct amdgpu_cs_parser *p,
+ struct amdgpu_cs_chunk *chunk)
+{
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_sem *deps;
+
+   deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+   for (i = 0; i < num_deps; ++i) {
+   r = drm_syncobj_replace_fence(p->filp, deps[i].handle,
+ p->fence);
+   if (r)
+   return r;
+   }
+   return 0;
+}
+
+static int amdgpu_cs_post_dependencies(struct amdgpu_cs_parser *p)
+{
+   int i, r;
+
+   for (i = 0; i < p->nchunks; ++i) {
+   struct amdgpu_cs_chunk *chunk;
+
+   chunk = >chunks[i];
+
+   if (chunk->chunk_id == AMDGPU_CHUNK_ID_SYNCOBJ_OUT) {
+   r = amdgpu_process_syncobj_out_dep(p, chunk);
+   if (r)
+   return r;
+   }
+   }
+   return 0;
+}
+
 static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
union drm_amdgpu_cs *cs)
 {
@@ -1055,7 +1134,7 @@ static int 

[PATCH 3/5] drm/syncobj: add sync_file interaction.

2017-04-25 Thread Dave Airlie
From: Dave Airlie 

This interface allows importing the fence from a sync_file into
an existing drm sync object, or exporting the fence attached to
an existing drm sync object into a new sync file object.

This should only be used to interact with sync files where necessary.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_syncobj.c | 56 +++
 include/uapi/drm/drm.h|  6 +++--
 2 files changed, 60 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index c24fea0..89bf120 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_internal.h"
 #include 
@@ -279,6 +280,48 @@ static int drm_syncobj_fd_to_handle(struct drm_file 
*file_private,
return 0;
 }
 
+int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
+  int fd, int handle)
+{
+   struct dma_fence *fence = sync_file_get_fence(fd);
+   if (!fence)
+   return -EINVAL;
+
+   return drm_syncobj_replace_fence(file_private, handle, fence);
+}
+
+int drm_syncobj_export_sync_file(struct drm_file *file_private,
+int handle, int *p_fd)
+{
+   int ret;
+   struct dma_fence *fence;
+   struct sync_file *sync_file;
+   int fd = get_unused_fd_flags(O_CLOEXEC);
+
+   if (fd < 0)
+   return fd;
+
+   ret = drm_syncobj_fence_get(file_private, handle, );
+   if (ret)
+   goto err_put_fd;
+
+   sync_file = sync_file_create(fence);
+   if (!sync_file) {
+   ret = -EINVAL;
+   goto err_fence_put;
+   }
+
+   fd_install(fd, sync_file->file);
+
+   dma_fence_put(fence);
+   *p_fd = fd;
+   return 0;
+err_fence_put:
+   dma_fence_put(fence);
+err_put_fd:
+   put_unused_fd(fd);
+   return ret;
+}
 /**
  * drm_syncobj_open - initalizes syncobj file-private structures at devnode 
open time
  * @dev: drm_device which is being opened by userspace
@@ -361,6 +404,12 @@ drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
return -ENODEV;
 
+   if (args->flags & DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_FENCE_SYNC_FILE)
+   return drm_syncobj_export_sync_file(file_private, args->handle,
+   >fd);
+   else if (args->flags)
+   return -EINVAL;
+
return drm_syncobj_handle_to_fd(file_private, args->handle,
>fd);
 }
@@ -374,6 +423,13 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
return -ENODEV;
 
+   if (args->flags & DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE_FENCE)
+   return drm_syncobj_import_sync_file_fence(file_private,
+ args->fd,
+ args->handle);
+   else if (args->flags)
+   return -EINVAL;
+
return drm_syncobj_fd_to_handle(file_private, args->fd,
>handle);
 }
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 7c508d0..a06d370 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -707,13 +707,15 @@ struct drm_syncobj_destroy {
__u32 pad;
 };
 
+#define DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE_FENCE (1 << 0)
+#define DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_FENCE_SYNC_FILE (1 << 0)
 struct drm_syncobj_handle {
__u32 handle;
/** Flags.. only applicable for handle->fd */
-   __u32 flags;
+   __u32 fd_flags;
 
__s32 fd;
-   __u32 pad;
+   __u32 flags;
 };
 
 #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
-- 
2.9.3

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[rfc] drm sync objects (search for spock)

2017-04-25 Thread Dave Airlie
Okay I've gone around the sun with these a few times, and
pretty much implemented what I said last week.

This is pretty much a complete revamp.

1. sync objects are self contained drm objects, they
have a file reference so can be passed between processes.

2. Added a sync object wait interface modelled on the vulkan
fence waiting API.

3. sync_file interaction is explicitly different than
opaque fd passing, you import a sync file state into an
existing syncobj, or create a new sync_file from an
existing syncobj. This means no touching the sync file code
at all. \o/

I haven't used rcu anywhere here, I've used xchg to swap
fence pointers in the hope that's safe. If this does need
rcu'ing I suggest we do it in a follow on patch to minimise
the review pain.

Dave.

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 1/5] drm: introduce sync objects

2017-04-25 Thread Dave Airlie
From: Dave Airlie 

Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.

There is also a generic wait obj API modelled on the vulkan
wait API (with code modelled on some amdgpu code).

These objects can be converted to an opaque fd that can be
passes between processes.

TODO: define sync_file interaction.

Signed-off-by: Dave Airlie 
---
 Documentation/gpu/drm-internals.rst |   3 +
 Documentation/gpu/drm-mm.rst|   6 +
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_fops.c  |   8 +
 drivers/gpu/drm/drm_internal.h  |  13 ++
 drivers/gpu/drm/drm_ioctl.c |  12 ++
 drivers/gpu/drm/drm_syncobj.c   | 374 
 include/drm/drmP.h  |   5 +
 include/drm/drm_drv.h   |   1 +
 include/drm/drm_syncobj.h   | 104 ++
 include/uapi/drm/drm.h  |  25 +++
 11 files changed, 552 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_syncobj.c
 create mode 100644 include/drm/drm_syncobj.h

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index e35920d..2ea3bce 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -98,6 +98,9 @@ DRIVER_ATOMIC
 implement appropriate obj->atomic_get_property() vfuncs for any
 modeset objects with driver specific properties.
 
+DRIVER_SYNCOBJ
+Driver support drm sync objects.
+
 Major, Minor and Patchlevel
 ~~~
 
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index f5760b1..28aebe8 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -483,3 +483,9 @@ DRM Cache Handling
 
 .. kernel-doc:: drivers/gpu/drm/drm_cache.c
:export:
+
+DRM Sync Objects
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
+   :export:
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 3ee9579..b5e565c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -16,7 +16,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
-   drm_dumb_buffers.o drm_mode_config.o
+   drm_dumb_buffers.o drm_mode_config.o drm_syncobj.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index afdf5b1..9a61df2 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -219,6 +219,9 @@ static int drm_open_helper(struct file *filp, struct 
drm_minor *minor)
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_open(dev, priv);
 
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_open(priv);
+
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_init_file_private(>prime);
 
@@ -266,6 +269,8 @@ static int drm_open_helper(struct file *filp, struct 
drm_minor *minor)
 out_prime_destroy:
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_destroy_file_private(>prime);
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_release(priv);
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_release(dev, priv);
put_pid(priv->pid);
@@ -400,6 +405,9 @@ int drm_release(struct inode *inode, struct file *filp)
drm_property_destroy_user_blobs(dev, file_priv);
}
 
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_release(file_priv);
+
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_release(dev, file_priv);
 
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index f37388c..44ef903 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -142,4 +142,17 @@ static inline int drm_debugfs_crtc_crc_add(struct drm_crtc 
*crtc)
 {
return 0;
 }
+
 #endif
+
+/* drm_syncobj.c */
+void drm_syncobj_open(struct drm_file *file_private);
+void drm_syncobj_release(struct drm_file *file_private);
+int drm_syncobj_create_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_private);
+int drm_syncobj_destroy_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
+int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private);
+int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private);

[PATCH 2/5] drm/syncobj: add sync obj wait interface.

2017-04-25 Thread Dave Airlie
From: Dave Airlie 

This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_internal.h |   2 +
 drivers/gpu/drm/drm_ioctl.c|   2 +
 drivers/gpu/drm/drm_syncobj.c  | 162 -
 include/uapi/drm/drm.h |  11 +++
 4 files changed, 176 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 44ef903..a508ad9 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -156,3 +156,5 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
   struct drm_file *file_private);
 int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_private);
+int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 6da7adc..b142466 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -653,6 +653,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
drm_syncobj_fd_to_handle_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e6a99d4..c24fea0 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1,5 +1,7 @@
 /*
  * Copyright 2017 Red Hat
+ * Parts ported from amdgpu (fence wait code).
+ * Copyright 2016 Advanced Micro Devices, Inc.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
@@ -31,10 +33,13 @@
  * that contain an optional fence. The fence can be updated with a new
  * fence, or be NULL.
  *
+ * syncobj's can be waited upon, where it will wait for the underlying
+ * fence.
+ *
  * syncobj's can be export to fd's and back, these fd's are opaque and
  * have no other use case, except passing the syncobj between processes.
  *
- * TODO: sync_file interactions, waiting
+ * TODO: sync_file interactions.
  *
  * Their primary use-case is to implement Vulkan fences and semaphores.
  *
@@ -372,3 +377,158 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
return drm_syncobj_fd_to_handle(file_private, args->fd,
>handle);
 }
+
+/**
+ * calc_timeout - calculate jiffies timeout from absolute value
+ *
+ * @timeout_ns: timeout in ns
+ *
+ * Calculate the timeout in jiffies from an absolute timeout in ns.
+ */
+unsigned long calc_wait_timeout(uint64_t timeout_ns)
+{
+unsigned long timeout_jiffies;
+ktime_t timeout;
+
+/* clamp timeout if it's to large */
+if (((int64_t)timeout_ns) < 0)
+return MAX_SCHEDULE_TIMEOUT;
+
+timeout = ktime_sub(ns_to_ktime(timeout_ns), ktime_get());
+if (ktime_to_ns(timeout) < 0)
+return 0;
+
+timeout_jiffies = nsecs_to_jiffies(ktime_to_ns(timeout));
+/*  clamp timeout to avoid unsigned-> signed overflow */
+if (timeout_jiffies > MAX_SCHEDULE_TIMEOUT )
+return MAX_SCHEDULE_TIMEOUT - 1;
+
+return timeout_jiffies;
+}
+
+static int drm_syncobj_wait_all_fences(struct drm_device *dev,
+  struct drm_file *file_private,
+  struct drm_syncobj_wait *wait,
+  uint32_t *handles)
+{
+   uint32_t i;
+   int ret;
+
+   for (i = 0; i < wait->count_handles; i++) {
+   unsigned long timeout = calc_wait_timeout(wait->timeout_ns);
+   struct dma_fence *fence;
+
+   ret = drm_syncobj_fence_get(file_private, handles[i],
+   );
+   if (ret)
+   return ret;
+
+   if (!fence)
+   continue;
+
+   ret = dma_fence_wait_timeout(fence, true, timeout);
+
+   dma_fence_put(fence);
+   if (ret < 0)
+   return ret;
+   if (ret == 0)
+   break;
+   }
+
+   wait->out_status = (ret > 0);
+   wait->first_signaled = 0;
+   return 0;
+}
+
+static int drm_syncobj_wait_any_fence(struct drm_device *dev,
+ struct drm_file *file_private,
+ 

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

2017-04-25 Thread Michel Dänzer
On 25/04/17 07:26 PM, Ville Syrjälä wrote:
> On Tue, Apr 25, 2017 at 10:12:37AM +0900, Michel Dänzer wrote:
>> On 24/04/17 10:03 PM, Ville Syrjälä wrote:
>>> On Mon, Apr 24, 2017 at 03:57:02PM +0900, Michel Dänzer wrote:
 On 22/04/17 07:05 PM, Ville Syrjälä wrote:
> On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote:
>>   Hi,
>>
 My personal opinion is that formats in drm_fourcc.h should be 
 independent of the CPU byte order and the function 
 drm_mode_legacy_fb_format() and drivers depending on that incorrect 
 assumption be fixed instead.
>>>
>>> The problem is this isn't a kernel-internal thing any more.  With the
>>> addition of the ADDFB2 ioctl the fourcc codes became part of the
>>> kernel/userspace abi ...
>>
>> Ok, added some printk's to the ADDFB and ADDFB2 code paths and tested a
>> bit.  Apparently pretty much all userspace still uses the ADDFB ioctl.
>> xorg (modesetting driver) does.  gnome-shell in wayland mode does.
>> Seems the big transition to ADDFB2 didn't happen yet.
>>
>> I guess that makes changing drm_mode_legacy_fb_format + drivers a
>> reasonable option ...
>
> Yeah, I came to the same conclusion after chatting with some
> folks on irc.
>
> So my current idea is that we change any driver that wants to follow the
> CPU endianness

 This isn't really optional for various reasons, some of which have been
 covered in this discussion.


> to declare support for big endian formats if the CPU is
> big endian. Presumably these are mostly the virtual GPU drivers.
>
> Additonally we'll make the mapping performed by 
> drm_mode_legacy_fb_format()
> driver controlled. That way drivers that got changed to follow CPU
> endianness can return a framebuffer that matches CPU endianness. And
> drivers that expect the GPU endianness to not depend on the CPU
> endianness will keep working as they do now. The downside is that users
> of the legacy addfb ioctl will need to magically know which endianness
> they will get, but that is apparently already the case. And users of
> addfb2 will keep on specifying the endianness explicitly with
> DRM_FORMAT_BIG_ENDIAN vs. 0.

 I'm afraid it's not that simple.

 The display hardware of older (pre-R600 generation) Radeon GPUs does not
 support the "big endian" formats directly. In order to allow userspace
 to access pixel data in native endianness with the CPU, we instead use
 byte-swapping functionality which only affects CPU access.
>>>
>>> OK, I'm getting confused. Based on our irc discussion I got the
>>> impression you don't byte swap CPU accesses.
>>
>> Sorry for the confusion. The radeon kernel driver does support
>> byte-swapping for CPU access to VRAM with pre-R600 GPUs, and this is
>> used for fbdev emulation. What I meant on IRC is that the xf86-video-ati
>> radeon driver doesn't make use of this, mostly because it only applies
>> while a BO is in VRAM, and userspace can't control when that's the case
>> (while a BO isn't being scanned out).
> 
> So that was my other question. So if someone just creates a bo, I presume
> ttm can more or less move it between system memory and vram at any
> time. So if we then mmap the bo, does it mean the CPU will see the bytes
> in different order depending on where the bo happens to live at
> the time the CPU access happens?

If either of the RADEON_TILING_SWAP_16/32BIT flags was set when the BO
was created, yes. That's why the xf86-video-ati radeon driver doesn't
use this functionality.

> And how would that work wih dumb bos?

radeon_mode_dumb_create doesn't set the RADEON_TILING_SWAP_16/32BIT
flags, so no byte swapping is performed for dumb BOs even in VRAM.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 1/2] drm/amdgpu: fix gpu reset crash

2017-04-25 Thread zhoucm1



On 2017年04月25日 21:34, Deucher, Alexander wrote:

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of zhoucm1
> Sent: Monday, April 24, 2017 10:20 PM
> To: Christian König; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 1/2] drm/amdgpu: fix gpu reset crash
>
>
>
> On 2017年04月24日 17:47, Christian König wrote:
> >> The root cause is some ring doesn't have scheduler, like KIQ ring
> >>
> >> Change-Id: I420e84add9cdd9a7fd1f9921b8a5d0afa3dd2058
> >> Signed-off-by: Chunming Zhou 
> >
> > Reviewed-by: Christian König  for both.
> I forgot to add RB when pushing patches, How can I add it again?

I'll add it before sending upstream.

Thanks.

David


Alex

>
> Sorry for that.
> David Zhou
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format

2017-04-25 Thread Gerd Hoffmann
On Di, 2017-04-25 at 12:18 +0900, Michel Dänzer wrote:
> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
> > Return correct fourcc codes on bigendian.  Drivers must be adapted to
> > this change.
> > 
> > Signed-off-by: Gerd Hoffmann 
> 
> Just to reiterate, this won't work for the radeon driver, which programs
> the GPU to use (effectively, per the current definition that these are
> little endian GPU formats) DRM_FORMAT_XRGB with pre-R600 and
> DRM_FORMAT_BGRX with >= R600.

Hmm, ok, how does bigendian fbdev emulation work on pre-R600 then?

> > +#ifdef __BIG_ENDIAN
> > +   switch (bpp) {
> > +   case 8:
> > +   fmt = DRM_FORMAT_C8;
> > +   break;
> > +   case 24:
> > +   fmt = DRM_FORMAT_BGR888;
> > +   break;
> 
> BTW, endianness as a concept cannot apply to 8 or 24 bpp formats.

I could move the 8 bpp case out of the #ifdef somehow, but code
readability will suffer then I think ...

For 24 we have different byte orderings, but yes, you can't switch from
one to the other with byteswapping.  Probably one of the reasons why
this format is pretty much out of fashion these days ...

cheers,
  Gerd

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format

2017-04-25 Thread Michel Dänzer
On 25/04/17 06:52 PM, Ville Syrjälä wrote:
> On Tue, Apr 25, 2017 at 12:18:52PM +0900, Michel Dänzer wrote:
>> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
>>> +#ifdef __BIG_ENDIAN
>>> +   switch (bpp) {
>>> +   case 8:
>>> +   fmt = DRM_FORMAT_C8;
>>> +   break;
>>> +   case 24:
>>> +   fmt = DRM_FORMAT_BGR888;
>>> +   break;
>>
>> BTW, endianness as a concept cannot apply to 8 or 24 bpp formats.
> 
> To 8bpp no, but it can easily apply to 24bpp.

Any byte swapping rips apart the bytes of a 24bpp pixel, so those
formats only make sense as straight array formats.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 4/5] amdgpu/cs: split out fence dependency checking

2017-04-25 Thread Dave Airlie
From: Dave Airlie 

This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.

Reviewed-by: Christian König 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++---
 1 file changed, 47 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 99424cb..df25b32 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -963,56 +963,65 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device *adev,
return 0;
 }
 
-static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
- struct amdgpu_cs_parser *p)
+static int amdgpu_process_fence_dep(struct amdgpu_cs_parser *p,
+   struct amdgpu_cs_chunk *chunk)
 {
struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
-   int i, j, r;
-
-   for (i = 0; i < p->nchunks; ++i) {
-   struct drm_amdgpu_cs_chunk_dep *deps;
-   struct amdgpu_cs_chunk *chunk;
-   unsigned num_deps;
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_dep *deps;
 
-   chunk = >chunks[i];
+   deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_dep);
 
-   if (chunk->chunk_id != AMDGPU_CHUNK_ID_DEPENDENCIES)
-   continue;
+   for (i = 0; i < num_deps; ++i) {
+   struct amdgpu_ring *ring;
+   struct amdgpu_ctx *ctx;
+   struct dma_fence *fence;
 
-   deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
-   num_deps = chunk->length_dw * 4 /
-   sizeof(struct drm_amdgpu_cs_chunk_dep);
+   r = amdgpu_cs_get_ring(p->adev, deps[i].ip_type,
+  deps[i].ip_instance,
+  deps[i].ring, );
+   if (r)
+   return r;
 
-   for (j = 0; j < num_deps; ++j) {
-   struct amdgpu_ring *ring;
-   struct amdgpu_ctx *ctx;
-   struct dma_fence *fence;
+   ctx = amdgpu_ctx_get(fpriv, deps[i].ctx_id);
+   if (ctx == NULL)
+   return -EINVAL;
 
-   r = amdgpu_cs_get_ring(adev, deps[j].ip_type,
-  deps[j].ip_instance,
-  deps[j].ring, );
+   fence = amdgpu_ctx_get_fence(ctx, ring,
+deps[i].handle);
+   if (IS_ERR(fence)) {
+   r = PTR_ERR(fence);
+   amdgpu_ctx_put(ctx);
+   return r;
+   } else if (fence) {
+   r = amdgpu_sync_fence(p->adev, >job->sync,
+ fence);
+   dma_fence_put(fence);
+   amdgpu_ctx_put(ctx);
if (r)
return r;
+   }
+   }
+   return 0;
+}
 
-   ctx = amdgpu_ctx_get(fpriv, deps[j].ctx_id);
-   if (ctx == NULL)
-   return -EINVAL;
+static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
+ struct amdgpu_cs_parser *p)
+{
+   int i, r;
 
-   fence = amdgpu_ctx_get_fence(ctx, ring,
-deps[j].handle);
-   if (IS_ERR(fence)) {
-   r = PTR_ERR(fence);
-   amdgpu_ctx_put(ctx);
-   return r;
+   for (i = 0; i < p->nchunks; ++i) {
+   struct amdgpu_cs_chunk *chunk;
 
-   } else if (fence) {
-   r = amdgpu_sync_fence(adev, >job->sync,
- fence);
-   dma_fence_put(fence);
-   amdgpu_ctx_put(ctx);
-   if (r)
-   return r;
-   }
+   chunk = >chunks[i];
+
+   if (chunk->chunk_id == AMDGPU_CHUNK_ID_DEPENDENCIES) {
+   r = amdgpu_process_fence_dep(p, chunk);
+   if (r)
+   return r;
}
}
 
-- 
2.9.3

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: add parameter to allocate high priority contexts v8

2017-04-25 Thread Andres Rodriguez



On 2017-04-25 06:21 PM, Alex Deucher wrote:

On Tue, Apr 25, 2017 at 4:28 PM, Andres Rodriguez  wrote:



On 2017-04-25 02:01 PM, Nicolai Hähnle wrote:


On 24.04.2017 18:20, Andres Rodriguez wrote:


Add a new context creation parameter to express a global context
priority.

The priority ranking in descending order is as follows:
 * AMDGPU_CTX_PRIORITY_HIGH
 * AMDGPU_CTX_PRIORITY_NORMAL
 * AMDGPU_CTX_PRIORITY_LOW

The driver will attempt to schedule work to the hardware according to
the priorities. No latency or throughput guarantees are provided by
this patch.

This interface intends to service the EGL_IMG_context_priority
extension, and vulkan equivalents.

v2: Instead of using flags, repurpose __pad
v3: Swap enum values of _NORMAL _HIGH for backwards compatibility
v4: Validate usermode priority and store it
v5: Move priority validation into amdgpu_ctx_ioctl(), headline reword
v6: add UAPI note regarding priorities requiring CAP_SYS_ADMIN
v7: remove ctx->priority
v8: added AMDGPU_CTX_PRIORITY_LOW, s/CAP_SYS_ADMIN/CAP_SYS_NICE

Reviewed-by: Emil Velikov 
Reviewed-by: Christian König 
Signed-off-by: Andres Rodriguez 



I didn't follow all the discussion, so feel free to shut me up if this
has already been discussed, but...


[snip]


+/* Context priority level */
+#define AMDGPU_CTX_PRIORITY_NORMAL0
+#define AMDGPU_CTX_PRIORITY_LOW1
+/* Selecting a priority above NORMAL requires CAP_SYS_ADMIN */
+#define AMDGPU_CTX_PRIORITY_HIGH2
+#define AMDGPU_CTX_PRIORITY_NUM3



I get that normal priority needs to be 0 for backwards compatibility,
but having LOW between NORMAL and HIGH is still odd. Have you considered
using signed integers as a way to fix that?



Thanks for the suggestion, that should make it a lot cleaner.


Maybe make the range -1023 to 1023 for consistency with the similar
proposed interface on Intel?
https://lists.freedesktop.org/archives/intel-gfx/2017-April/126155.html

Alex




Sure, that gives us a range to add new priority leves.

Andres



Regards,
Andres




(AMDGPU_CTX_PRIORITY_NUM doesn't seem to be used anywhere...)

Cheers,
Nicolai



+
 struct drm_amdgpu_ctx_in {
 /** AMDGPU_CTX_OP_* */
 __u32op;
 /** For future use, no flags defined so far */
 __u32flags;
 __u32ctx_id;
-__u32_pad;
+__u32priority;
 };

 union drm_amdgpu_ctx_out {
 struct {
 __u32ctx_id;
 __u32_pad;
 } alloc;

 struct {
 /** For future use, no flags defined so far */
 __u64flags;
 /** Number of resets caused by this context so far. */
 __u32hangs;
 /** Reset status since the last call of the ioctl. */
 __u32reset_status;
 } state;
 };

 union drm_amdgpu_ctx {
 struct drm_amdgpu_ctx_in in;





___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: add parameter to allocate high priority contexts v8

2017-04-25 Thread Nicolai Hähnle

On 24.04.2017 18:20, Andres Rodriguez wrote:

Add a new context creation parameter to express a global context priority.

The priority ranking in descending order is as follows:
 * AMDGPU_CTX_PRIORITY_HIGH
 * AMDGPU_CTX_PRIORITY_NORMAL
 * AMDGPU_CTX_PRIORITY_LOW

The driver will attempt to schedule work to the hardware according to
the priorities. No latency or throughput guarantees are provided by
this patch.

This interface intends to service the EGL_IMG_context_priority
extension, and vulkan equivalents.

v2: Instead of using flags, repurpose __pad
v3: Swap enum values of _NORMAL _HIGH for backwards compatibility
v4: Validate usermode priority and store it
v5: Move priority validation into amdgpu_ctx_ioctl(), headline reword
v6: add UAPI note regarding priorities requiring CAP_SYS_ADMIN
v7: remove ctx->priority
v8: added AMDGPU_CTX_PRIORITY_LOW, s/CAP_SYS_ADMIN/CAP_SYS_NICE

>

Reviewed-by: Emil Velikov 
Reviewed-by: Christian König 
Signed-off-by: Andres Rodriguez 


I didn't follow all the discussion, so feel free to shut me up if this 
has already been discussed, but...



[snip]

+/* Context priority level */
+#define AMDGPU_CTX_PRIORITY_NORMAL 0
+#define AMDGPU_CTX_PRIORITY_LOW1
+/* Selecting a priority above NORMAL requires CAP_SYS_ADMIN */
+#define AMDGPU_CTX_PRIORITY_HIGH   2
+#define AMDGPU_CTX_PRIORITY_NUM3


I get that normal priority needs to be 0 for backwards compatibility, 
but having LOW between NORMAL and HIGH is still odd. Have you considered 
using signed integers as a way to fix that?


(AMDGPU_CTX_PRIORITY_NUM doesn't seem to be used anywhere...)

Cheers,
Nicolai



+
 struct drm_amdgpu_ctx_in {
/** AMDGPU_CTX_OP_* */
__u32   op;
/** For future use, no flags defined so far */
__u32   flags;
__u32   ctx_id;
-   __u32   _pad;
+   __u32   priority;
 };

 union drm_amdgpu_ctx_out {
struct {
__u32   ctx_id;
__u32   _pad;
} alloc;

struct {
/** For future use, no flags defined so far */
__u64   flags;
/** Number of resets caused by this context so far. */
__u32   hangs;
/** Reset status since the last call of the ioctl. */
__u32   reset_status;
} state;
 };

 union drm_amdgpu_ctx {
struct drm_amdgpu_ctx_in in;




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm: Harmonize CIK ASIC support in radeon and amdgpu (v2)

2017-04-25 Thread Nicolai Hähnle

On 25.04.2017 08:28, Michel Dänzer wrote:

On 22/04/17 02:05 AM, Felix Kuehling wrote:

__setup doesn't work in modules.


Right. We could build something like
drivers/video/fbdev/core/fb_cmdline.c:video_setup() into the kernel to
handle this, but it's a bit ugly, which is one reason why I was leaning
towards:



s8250_options is only compiled if the driver is not a module.


That doesn't prevent us from using __module_param_call directly, does it?

Although, that still doesn't work as I envision if only one driver's
option is set e.g. in /etc/modprobe.d/*.conf .


So, I'm starting to think we need a shared module for this, which
provides one or multiple module parameters to choose which driver to use
for CIK/SI[0], and provides the result to the amdgpu/radeon drivers.
That might make things easier for amdgpu-pro / other standalone amdgpu
versions in the long run as well, as they could add files to
/etc/modprobe.d/ choosing themselves by default, without having to
blacklist radeon.

What do you guys think?


I suspect that adding an entire module just to select between two other 
modules is the kind of thing that should be discussed in a wider 
audience first.


It is probably the cleanest solution that doesn't require teaching the 
general modprobe architecture about having multiple modules for the same 
PCI ID...


Cheers,
Nicolai





[0] or possibly even more fine-grained in the future




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 00/24] DC Linux Patches Apr 25, 2017

2017-04-25 Thread Harry Wentland
A lot of patches this time around since I haven't gotten around to 
this for a while.

 * Clean up contexts in DC in preparation for DC atomic state tracking
 * Some backports from drm-next tree that won't break on 4.9
 * get_atomic_property implementation
 * Populate YUV plane types in preparation for underlay
 * Bunch of fixes in DC

Charlene Liu (2):
  drm/amd/display: adding FCLK and DPPCLK clock types
  drm/amd/display: use full surface update when stream is NULL

Ding Wang (1):
  drm/amd/display: Fix for tile MST

Dmytro Laktyushkin (1):
  drm/amd/display: update dce8 & 10 bw programming

Eric Cook (1):
  drm/amd/display: FreeSync LFC MIN/MAX update on current frame

Harry Wentland (8):
  drm/amd/display: Allow planes on all crtcs
  drm/amd/display: Remove unused scratch_val_ctx
  drm/amd/display: Get rid of temp_flip_context
  drm/amd/display: Add lock around updating freesync property
  drm/amd/display: pull commit_surfaces out of atomic_commit into helper
function
  drm/amd/display: Copy ctx to current_context instead of assign
  drm/amd/display: Move resource_validate_ctx_destruct to dc.h
  drm/amd/display: Return context from validate_context

Jordan Lazare (1):
  drm/amd/display: Fix missing irq refactor causing potential i2c race

Leon Elazar (2):
  drm/amd/display: Memory was freed twice during disable
  drm/amd/display: set NULL value during removal for remoteSink

Pratik Vishwakarma (1):
  drm/amd/display: get_atomic_property missing for drm_connector_funcs

Shirish S (1):
  drm/amd/display: initialize YUV plane capabilities

Sylvia Tsai (2):
  drm/amd/display: Adding dm controlled signal type in dc_stream
  drm/amd/display: Parse scanline registers

Vitaly Prosyak (1):
  drm/amd/display: Add support for programming stereo sync

Yongqiang Sun (2):
  drm/amd/display: Add same check as reset pipes for programing backend
regs.
  drm/amd/display: change mpo surface update check condition.

Zeyu Fan (1):
  drm/amd/display: Fix hotspot programming during set cursor position.

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  17 +-
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 277 ++---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.h|   6 +
 drivers/gpu/drm/amd/display/dc/core/dc.c   | 108 
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |   3 +
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   |  13 +
 drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c |   3 +
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |  34 +--
 drivers/gpu/drm/amd/display/dc/core/dc_stream.c|  21 +-
 drivers/gpu/drm/amd/display/dc/dc.h|  19 +-
 drivers/gpu/drm/amd/display/dc/dc_hw_types.h   |   7 -
 .../gpu/drm/amd/display/dc/dce/dce_clock_source.c  |   1 -
 drivers/gpu/drm/amd/display/dc/dce/dce_opp.h   |  11 +-
 .../drm/amd/display/dc/dce/dce_stream_encoder.c|  12 +
 .../drm/amd/display/dc/dce/dce_stream_encoder.h|  14 +-
 .../amd/display/dc/dce100/dce100_hw_sequencer.c|  28 +--
 .../amd/display/dc/dce100/dce100_hw_sequencer.h|   7 +-
 .../drm/amd/display/dc/dce100/dce100_resource.c|   1 +
 .../amd/display/dc/dce110/dce110_hw_sequencer.c|  18 +-
 .../drm/amd/display/dc/dce110/dce110_ipp_cursor.c  |  11 +-
 .../display/dc/dce110/dce110_timing_generator.c|  54 ++--
 .../display/dc/dce110/dce110_timing_generator.h|   8 +-
 .../drm/amd/display/dc/dce120/dce120_ipp_cursor.c  |  15 +-
 .../display/dc/dce120/dce120_timing_generator.c|  42 ++--
 .../drm/amd/display/dc/dce80/dce80_hw_sequencer.c  |  19 +-
 drivers/gpu/drm/amd/display/dc/dm_services_types.h |   4 +-
 drivers/gpu/drm/amd/display/dc/inc/core_dc.h   |   2 -
 drivers/gpu/drm/amd/display/dc/inc/dc_link_dp.h|   2 +
 drivers/gpu/drm/amd/display/dc/inc/hw/opp.h|   5 +
 .../gpu/drm/amd/display/dc/inc/hw/stream_encoder.h |   5 +
 .../drm/amd/display/dc/inc/hw/timing_generator.h   |   8 +-
 drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h  |   4 -
 drivers/gpu/drm/amd/display/dc/inc/resource.h  |   6 -
 .../drm/amd/display/modules/freesync/freesync.c|  67 ++---
 34 files changed, 528 insertions(+), 324 deletions(-)

-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 12/24] drm/amd/display: Parse scanline registers

2017-04-25 Thread Harry Wentland
From: Sylvia Tsai 

They could differ between ASIC generations

Change-Id: Ia352ae206273fe3a025579554cae4e3711a26fcc
Signed-off-by: Sylvia Tsai 
Signed-off-by: Harry Wentland 
Acked-by: Harry Wentland 
Reviewed-by: Tony Cheng 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 15 +-
 drivers/gpu/drm/amd/display/dc/core/dc_stream.c| 21 ++---
 drivers/gpu/drm/amd/display/dc/dc.h|  7 ++-
 .../display/dc/dce110/dce110_timing_generator.c| 54 ++
 .../display/dc/dce110/dce110_timing_generator.h|  8 ++--
 .../display/dc/dce120/dce120_timing_generator.c| 42 -
 .../drm/amd/display/dc/inc/hw/timing_generator.h   |  8 ++--
 7 files changed, 89 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 222c3dcfed08..acd4c6751f56 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -109,6 +109,8 @@ static u32 dm_vblank_get_counter(struct amdgpu_device 
*adev, int crtc)
 static int dm_crtc_get_scanoutpos(struct amdgpu_device *adev, int crtc,
u32 *vbl, u32 *position)
 {
+   uint32_t v_blank_start, v_blank_end, h_position, v_position;
+
if ((crtc < 0) || (crtc >= adev->mode_info.num_crtc))
return -EINVAL;
else {
@@ -119,7 +121,18 @@ static int dm_crtc_get_scanoutpos(struct amdgpu_device 
*adev, int crtc,
return 0;
}
 
-   return dc_stream_get_scanoutpos(acrtc->stream, vbl, position);
+   /*
+* TODO rework base driver to use values directly.
+* for now parse it back into reg-format
+*/
+   dc_stream_get_scanoutpos(acrtc->stream,
+_blank_start,
+_blank_end,
+_position,
+_position);
+
+   *position = (v_position) || (h_position << 16);
+   *vbl = (v_blank_start) || (v_blank_end << 16);
}
 
return 0;
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
index bf209f7bbf98..3dbd6c0885d8 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
@@ -282,12 +282,14 @@ uint32_t dc_stream_get_vblank_counter(const struct 
dc_stream *dc_stream)
return 0;
 }
 
-uint32_t dc_stream_get_scanoutpos(
-   const struct dc_stream *dc_stream,
-   uint32_t *vbl,
-   uint32_t *position)
+bool dc_stream_get_scanoutpos(const struct dc_stream *dc_stream,
+ uint32_t *v_blank_start,
+ uint32_t *v_blank_end,
+ uint32_t *h_position,
+ uint32_t *v_position)
 {
uint8_t i;
+   bool ret = false;
struct core_stream *stream = DC_STREAM_TO_CORE(dc_stream);
struct core_dc *core_dc = DC_TO_CORE(stream->ctx->dc);
struct resource_context *res_ctx =
@@ -299,10 +301,17 @@ uint32_t dc_stream_get_scanoutpos(
if (res_ctx->pipe_ctx[i].stream != stream)
continue;
 
-   return tg->funcs->get_scanoutpos(tg, vbl, position);
+   tg->funcs->get_scanoutpos(tg,
+ v_blank_start,
+ v_blank_end,
+ h_position,
+ v_position);
+
+   ret = true;
+   break;
}
 
-   return 0;
+   return ret;
 }
 
 
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 97af8f63eec3..7d548b4d0299 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -484,8 +484,11 @@ uint32_t dc_stream_get_vblank_counter(const struct 
dc_stream *stream);
  * This has a dependency on the caller (amdgpu_get_crtc_scanoutpos)
  * being refactored properly to be dce-specific
  */
-uint32_t dc_stream_get_scanoutpos(
-   const struct dc_stream *stream, uint32_t *vbl, uint32_t 
*position);
+bool dc_stream_get_scanoutpos(const struct dc_stream *stream,
+ uint32_t *v_blank_start,
+ uint32_t *v_blank_end,
+ uint32_t *h_position,
+ uint32_t *v_position);
 
 /*
  * Structure to store surface/stream associations for validation
diff --git 

[PATCH 16/24] drm/amd/display: Get rid of temp_flip_context

2017-04-25 Thread Harry Wentland
If we need to update our context we can allocate memory.
No need to keep temporary memory for this.

Change-Id: Ie91d318a1dd2283fe12e5380f015faa866f93230
Signed-off-by: Harry Wentland 
Acked-by: Harry Wentland 
Reviewed-by: Tony Cheng 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 26 +-
 drivers/gpu/drm/amd/display/dc/inc/core_dc.h |  1 -
 2 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 7b0b7356ae89..e8499e744595 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -409,8 +409,6 @@ static void destruct(struct core_dc *dc)
 
dm_free(dc->current_context);
dc->current_context = NULL;
-   dm_free(dc->temp_flip_context);
-   dc->temp_flip_context = NULL;
 
dm_free(dc->ctx);
dc->ctx = NULL;
@@ -429,9 +427,8 @@ static bool construct(struct core_dc *dc,
}
 
dc->current_context = dm_alloc(sizeof(*dc->current_context));
-   dc->temp_flip_context = dm_alloc(sizeof(*dc->temp_flip_context));
 
-   if (!dc->current_context || !dc->temp_flip_context) {
+   if (!dc->current_context) {
dm_error("%s: failed to create validate ctx\n", __func__);
goto val_ctx_fail;
}
@@ -874,13 +871,9 @@ bool dc_commit_streams(
}
 
resource_validate_ctx_destruct(core_dc->current_context);
+   dm_free(core_dc->current_context);
 
-   if (core_dc->temp_flip_context != core_dc->current_context) {
-   dm_free(core_dc->temp_flip_context);
-   core_dc->temp_flip_context = core_dc->current_context;
-   }
core_dc->current_context = context;
-   memset(core_dc->temp_flip_context, 0, 
sizeof(*core_dc->temp_flip_context));
 
return (result == DC_OK);
 
@@ -1212,7 +1205,7 @@ void dc_update_surfaces_and_stream(struct dc *dc,
new_surfaces[i] = srf_updates[i].surface;
 
/* initialize scratch memory for building context */
-   context = core_dc->temp_flip_context;
+   context = dm_alloc(sizeof(*context));
resource_validate_ctx_copy_construct(
core_dc->current_context, context);
 
@@ -1220,7 +1213,7 @@ void dc_update_surfaces_and_stream(struct dc *dc,
if (!resource_attach_surfaces_to_context(
new_surfaces, surface_count, dc_stream, 
context)) {
BREAK_TO_DEBUGGER();
-   return;
+   goto fail;
}
} else {
context = core_dc->current_context;
@@ -1326,7 +1319,7 @@ void dc_update_surfaces_and_stream(struct dc *dc,
if (update_type == UPDATE_TYPE_FULL) {
if (!core_dc->res_pool->funcs->validate_bandwidth(core_dc, 
context)) {
BREAK_TO_DEBUGGER();
-   return;
+   goto fail;
} else
core_dc->hwss.set_bandwidth(core_dc, context, false);
}
@@ -1418,10 +1411,17 @@ void dc_update_surfaces_and_stream(struct dc *dc,
 
if (core_dc->current_context != context) {
resource_validate_ctx_destruct(core_dc->current_context);
-   core_dc->temp_flip_context = core_dc->current_context;
+   dm_free(core_dc->current_context);
 
core_dc->current_context = context;
}
+   return;
+
+fail:
+   if (core_dc->current_context != context) {
+   resource_validate_ctx_destruct(context);
+   dm_free(context);
+   }
 }
 
 uint8_t dc_get_current_stream_count(const struct dc *dc)
diff --git a/drivers/gpu/drm/amd/display/dc/inc/core_dc.h 
b/drivers/gpu/drm/amd/display/dc/inc/core_dc.h
index ec3edbe20d85..f9363f642f92 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/core_dc.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/core_dc.h
@@ -22,7 +22,6 @@ struct core_dc {
struct core_link *links[MAX_PIPES * 2];
 
struct validate_context *current_context;
-   struct validate_context *temp_flip_context;
struct resource_pool *res_pool;
 
/* Display Engine Clock levels */
-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 14/24] drm/amd/display: FreeSync LFC MIN/MAX update on current frame

2017-04-25 Thread Harry Wentland
From: Eric Cook 

- Update BTR/LFC logic so that V_TOTAL_MIN/MAX will take affect on current frame
- Add in FreeSync update to MPO code path

Change-Id: I12fb498254086fbae8f19b4b3c718104dab62486
Signed-off-by: Eric Cook 
Acked-by: Harry Wentland 
Reviewed-by: Anthony Koo 
---
 .../drm/amd/display/modules/freesync/freesync.c| 67 +-
 1 file changed, 39 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c 
b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index 7a0731e2dbb0..94566c0a0e62 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -641,7 +641,8 @@ static void set_static_ramp_variables(struct core_freesync 
*core_freesync,
 void mod_freesync_handle_v_update(struct mod_freesync *mod_freesync,
const struct dc_stream **streams, int num_streams)
 {
-   unsigned int index, v_total = 0;
+   unsigned int index, v_total, inserted_frame_v_total = 0;
+   unsigned int min_frame_duration_in_ns, vmax, vmin = 0;
struct freesync_state *state;
struct core_freesync *core_freesync = NULL;
 
@@ -665,19 +666,48 @@ void mod_freesync_handle_v_update(struct mod_freesync 
*mod_freesync,
 
/* Only execute if in fullscreen mode */
if (state->fullscreen == true &&
-   core_freesync->map[index].user_enable.enable_for_gaming) {
+   core_freesync->map[index].user_enable.enable_for_gaming &&
+   core_freesync->map[index].caps->btr_supported &&
+   state->btr.btr_active) {
+
+   /* TODO: pass in flag for Pre-DCE12 ASIC
+* in order for frame variable duration to take affect,
+* it needs to be done one VSYNC early, which is at
+* frameCounter == 1.
+* For DCE12 and newer updates to V_TOTAL_MIN/MAX
+* will take affect on current frame
+*/
+   if (state->btr.frames_to_insert == state->btr.frame_counter) {
+
+   min_frame_duration_in_ns = ((unsigned int) (div64_u64(
+   (10ULL * 100),
+   
state->nominal_refresh_rate_in_micro_hz)));
+
+   calc_vmin_vmax(core_freesync, *streams, , );
 
-   if (state->btr.btr_active)
-   if (state->btr.frame_counter > 0)
+   inserted_frame_v_total = vmin;
 
-   state->btr.frame_counter--;
+   if (min_frame_duration_in_ns / 1000)
+   inserted_frame_v_total =
+   
state->btr.inserted_frame_duration_in_us *
+   vmin / (min_frame_duration_in_ns / 
1000);
 
-   if (state->btr.frame_counter == 1) {
+   /* Set length of inserted frames as v_total_max*/
+   vmax = inserted_frame_v_total;
+   vmin = inserted_frame_v_total;
 
-   /* Restore FreeSync */
-   set_freesync_on_streams(core_freesync, streams,
-   num_streams);
+   /* Program V_TOTAL */
+   core_freesync->dc->stream_funcs.adjust_vmin_vmax(
+   core_freesync->dc, streams,
+   num_streams, vmin, vmax);
}
+
+   if (state->btr.frame_counter > 0)
+   state->btr.frame_counter--;
+
+   /* Restore FreeSync */
+   if (state->btr.frame_counter == 0)
+   set_freesync_on_streams(core_freesync, streams, 
num_streams);
}
 
/* If in fullscreen freesync mode or in video, do not program
@@ -1022,8 +1052,6 @@ static void apply_below_the_range(struct core_freesync 
*core_freesync,
unsigned int delta_from_mid_point_in_us_1 = 0x;
unsigned int delta_from_mid_point_in_us_2 = 0x;
unsigned int frames_to_insert = 0;
-   unsigned int inserted_frame_v_total = 0;
-   unsigned int vmin = 0, vmax = 0;
unsigned int min_frame_duration_in_ns = 0;
struct freesync_state *state = _freesync->map[map_index].state;
 
@@ -1101,23 +1129,6 @@ static void apply_below_the_range(struct core_freesync 
*core_freesync,
inserted_frame_duration_in_us =
state->time.min_render_time_in_us;
 
-   /* We need the v_total_min from capability */
-   calc_vmin_vmax(core_freesync, stream, , );
-
-   inserted_frame_v_total = vmin;
-   if (min_frame_duration_in_ns / 1000)
-   inserted_frame_v_total = 

[PATCH 13/24] drm/amd/display: Add support for programming stereo sync

2017-04-25 Thread Harry Wentland
From: Vitaly Prosyak 

Change-Id: I7e9150b3a2a6aa9c99c84abf2960d3a72f5425ee
Signed-off-by: Vitaly Prosyak 
Acked-by: Harry Wentland 
Reviewed-by: Charlene Liu 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_opp.h   | 11 ---
 drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c| 12 
 drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.h| 14 --
 .../gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c|  7 +++
 drivers/gpu/drm/amd/display/dc/inc/hw/opp.h|  5 +
 drivers/gpu/drm/amd/display/dc/inc/hw/stream_encoder.h |  5 +
 6 files changed, 49 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_opp.h 
b/drivers/gpu/drm/amd/display/dc/dce/dce_opp.h
index 03ce9ba50b64..e5045d21a05c 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_opp.h
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_opp.h
@@ -174,7 +174,8 @@ enum dce110_opp_reg_type {
OPP_SF(DCFE_MEM_PWR_CTRL, DCP_LUT_MEM_PWR_DIS, mask_sh),\
OPP_SF(DCFE_MEM_PWR_STATUS, DCP_REGAMMA_MEM_PWR_STATE, mask_sh),\
OPP_SF(FMT_CONTROL, FMT_SPATIAL_DITHER_FRAME_COUNTER_MAX, mask_sh),\
-   OPP_SF(FMT_CONTROL, FMT_SPATIAL_DITHER_FRAME_COUNTER_BIT_SWAP, mask_sh)
+   OPP_SF(FMT_CONTROL, FMT_SPATIAL_DITHER_FRAME_COUNTER_BIT_SWAP, 
mask_sh),\
+   OPP_SF(FMT_CONTROL, FMT_STEREOSYNC_OVERRIDE, mask_sh)
 
 #define OPP_COMMON_MASK_SH_LIST_DCE_100(mask_sh)\
OPP_COMMON_MASK_SH_LIST_DCE_COMMON_BASE(mask_sh),\
@@ -182,7 +183,8 @@ enum dce110_opp_reg_type {
OPP_SF(DCFE_MEM_PWR_CTRL, DCP_LUT_MEM_PWR_DIS, mask_sh),\
OPP_SF(DCFE_MEM_PWR_STATUS, DCP_REGAMMA_MEM_PWR_STATE, mask_sh),\
OPP_SF(FMT_CONTROL, FMT_SPATIAL_DITHER_FRAME_COUNTER_MAX, mask_sh),\
-   OPP_SF(FMT_CONTROL, FMT_SPATIAL_DITHER_FRAME_COUNTER_BIT_SWAP, mask_sh)
+   OPP_SF(FMT_CONTROL, FMT_SPATIAL_DITHER_FRAME_COUNTER_BIT_SWAP, 
mask_sh),\
+   OPP_SF(FMT_CONTROL, FMT_STEREOSYNC_OVERRIDE, mask_sh)
 
 #define OPP_COMMON_MASK_SH_LIST_DCE_112(mask_sh)\
OPP_COMMON_MASK_SH_LIST_DCE_COMMON_BASE(mask_sh),\
@@ -195,7 +197,8 @@ enum dce110_opp_reg_type {
OPP_SF(FMT_CONTROL, FMT_420_PIXEL_PHASE_LOCKED, mask_sh),\
OPP_SF(FMT_CONTROL, FMT_CBCR_BIT_REDUCTION_BYPASS, mask_sh),\
OPP_SF(FMT_CONTROL, FMT_SPATIAL_DITHER_FRAME_COUNTER_MAX, mask_sh),\
-   OPP_SF(FMT_CONTROL, FMT_SPATIAL_DITHER_FRAME_COUNTER_BIT_SWAP, mask_sh)
+   OPP_SF(FMT_CONTROL, FMT_SPATIAL_DITHER_FRAME_COUNTER_BIT_SWAP, 
mask_sh),\
+   OPP_SF(FMT_CONTROL, FMT_STEREOSYNC_OVERRIDE, mask_sh)
 
 #define OPP_COMMON_MASK_SH_LIST_DCE_80(mask_sh)\
OPP_COMMON_MASK_SH_LIST_DCE_COMMON_BASE(mask_sh),\
@@ -244,6 +247,7 @@ enum dce110_opp_reg_type {
OPP_SF(FMT0_FMT_BIT_DEPTH_CONTROL, FMT_TEMPORAL_DITHER_EN, mask_sh),\
OPP_SF(FMT0_FMT_CONTROL, FMT_SPATIAL_DITHER_FRAME_COUNTER_MAX, 
mask_sh),\
OPP_SF(FMT0_FMT_CONTROL, FMT_SPATIAL_DITHER_FRAME_COUNTER_BIT_SWAP, 
mask_sh),\
+   OPP_SF(FMT0_FMT_CONTROL, FMT_STEREOSYNC_OVERRIDE, mask_sh),\
OPP_SF(FMT0_FMT_DITHER_RAND_R_SEED, FMT_RAND_R_SEED, mask_sh),\
OPP_SF(FMT0_FMT_DITHER_RAND_G_SEED, FMT_RAND_G_SEED, mask_sh),\
OPP_SF(FMT0_FMT_DITHER_RAND_B_SEED, FMT_RAND_B_SEED, mask_sh),\
@@ -308,6 +312,7 @@ enum dce110_opp_reg_type {
type FMT_RGB_RANDOM_ENABLE; \
type FMT_SPATIAL_DITHER_FRAME_COUNTER_MAX; \
type FMT_SPATIAL_DITHER_FRAME_COUNTER_BIT_SWAP; \
+   type FMT_STEREOSYNC_OVERRIDE; \
type FMT_RAND_R_SEED; \
type FMT_RAND_G_SEED; \
type FMT_RAND_B_SEED; \
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
index f3e1a293351f..9713def6e481 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c
@@ -1286,6 +1286,17 @@ void dce110_se_hdmi_audio_disable(
dce110_se_enable_audio_clock(enc, false);
 }
 
+
+static void setup_stereo_sync(
+   struct stream_encoder *enc,
+   int tg_inst, bool enable)
+{
+   struct dce110_stream_encoder *enc110 = DCE110STRENC_FROM_STRENC(enc);
+   REG_UPDATE(DIG_FE_CNTL, DIG_STEREOSYNC_SELECT, tg_inst);
+   REG_UPDATE(DIG_FE_CNTL, DIG_STEREOSYNC_GATE_EN, !enable);
+}
+
+
 static const struct stream_encoder_funcs dce110_str_enc_funcs = {
.dp_set_stream_attribute =
dce110_stream_encoder_dp_set_stream_attribute,
@@ -1316,6 +1327,7 @@ static const struct stream_encoder_funcs 
dce110_str_enc_funcs = {
 
.hdmi_audio_setup = dce110_se_hdmi_audio_setup,
.hdmi_audio_disable = dce110_se_hdmi_audio_disable,
+   .setup_stereo_sync  = setup_stereo_sync,
 };
 
 bool dce110_stream_encoder_construct(
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.h 

[PATCH 09/24] drm/amd/display: Allow planes on all crtcs

2017-04-25 Thread Harry Wentland
4.9 kernel will always add the assigned crtc to possible_crtcs on a
plane. This is no longer the case on newer kernels. Make sure we allow
any plane on any crtc.

Change-Id: I7c6ead102e9c0bb4d98160c344278f76418b1cc6
Signed-off-by: Harry Wentland 
Acked-by: Harry Wentland 
Reviewed-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 00b5ff467ded..222c3dcfed08 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1099,7 +1099,7 @@ int amdgpu_dm_initialize_drm_device(struct amdgpu_device 
*adev)
goto fail_free_planes;
}
mode_info->planes[i]->plane_type = mode_info->plane_type[i];
-   if (amdgpu_dm_plane_init(dm, mode_info->planes[i], 1)) {
+   if (amdgpu_dm_plane_init(dm, mode_info->planes[i], 0xff)) {
DRM_ERROR("KMS: Failed to initialize plane\n");
goto fail_free_planes;
}
-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 20/24] drm/amd/display: Copy ctx to current_context instead of assign

2017-04-25 Thread Harry Wentland
Change-Id: Iebcdb340c6ff5938886dc69fd6f005c3ab43c6e2
Signed-off-by: Harry Wentland 
Acked-by: Harry Wentland 
Reviewed-by: Tony Cheng 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index e8499e744595..0d870e9c7c99 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -906,13 +906,13 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
resource_validate_ctx_copy_construct(core_dc->current_context, context);
 
post_surface_trace(dc);
-
for (i = 0; i < context->res_ctx.pool->pipe_count; i++)
if (context->res_ctx.pipe_ctx[i].stream == NULL) {
context->res_ctx.pipe_ctx[i].pipe_idx = i;
core_dc->hwss.power_down_front_end(
core_dc, >res_ctx.pipe_ctx[i]);
}
+
if (!core_dc->res_pool->funcs->validate_bandwidth(core_dc, context)) {
BREAK_TO_DEBUGGER();
return false;
@@ -920,11 +920,10 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
 
core_dc->hwss.set_bandwidth(core_dc, context, true);
 
-   resource_validate_ctx_destruct(core_dc->current_context);
-   if (core_dc->current_context)
-   dm_free(core_dc->current_context);
+   resource_validate_ctx_copy_construct(context, core_dc->current_context);
 
-   core_dc->current_context = context;
+   resource_validate_ctx_destruct(context);
+   dm_free(context);
 
return true;
 }
-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 23/24] drm/amd/display: initialize YUV plane capabilities

2017-04-25 Thread Harry Wentland
From: Shirish S 

This patch populates the YUV surface configurations.

Tests: (On Chromium OS for Stoney Only)
builds without any errors.

Change-Id: Ie6d6782cfe4b7cc470d27b664fcaf287499c00c6
Signed-off-by: Shirish S 
Reviewed-by: Tony Cheng 
Reviewed-by: Harry Wentland 
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 62 --
 1 file changed, 45 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
index f6d41cf29cea..96f3cc1fc694 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
@@ -462,9 +462,6 @@ static void fill_plane_attributes_from_fb(
_flags,
addReq == true ? _location:NULL);
 
-   surface->address.type= PLN_ADDR_TYPE_GRAPHICS;
-   surface->address.grph.addr.low_part  = lower_32_bits(fb_location);
-   surface->address.grph.addr.high_part = upper_32_bits(fb_location);
 
switch (fb->pixel_format) {
case DRM_FORMAT_C8:
@@ -485,11 +482,54 @@ static void fill_plane_attributes_from_fb(
case DRM_FORMAT_ABGR2101010:
surface->format = SURFACE_PIXEL_FORMAT_GRPH_ABGR2101010;
break;
+   case DRM_FORMAT_YUV420:
+   surface->format = SURFACE_PIXEL_FORMAT_VIDEO_420_YCbCr;
+   break;
+   case DRM_FORMAT_YVU420:
+   surface->format = SURFACE_PIXEL_FORMAT_VIDEO_420_YCrCb;
+   break;
default:
DRM_ERROR("Unsupported screen depth %d\n", fb->bits_per_pixel);
return;
}
 
+   if (surface->format < SURFACE_PIXEL_FORMAT_VIDEO_BEGIN) {
+   surface->address.type = PLN_ADDR_TYPE_GRAPHICS;
+   surface->address.grph.addr.low_part = 
lower_32_bits(fb_location);
+   surface->address.grph.addr.high_part = 
upper_32_bits(fb_location);
+   surface->plane_size.grph.surface_size.x = 0;
+   surface->plane_size.grph.surface_size.y = 0;
+   surface->plane_size.grph.surface_size.width = fb->width;
+   surface->plane_size.grph.surface_size.height = fb->height;
+   surface->plane_size.grph.surface_pitch =
+   fb->pitches[0] / (fb->bits_per_pixel / 8);
+   /* TODO: unhardcode */
+   surface->color_space = COLOR_SPACE_SRGB;
+
+   } else {
+   surface->address.type = PLN_ADDR_TYPE_VIDEO_PROGRESSIVE;
+   surface->address.video_progressive.luma_addr.low_part
+   = lower_32_bits(fb_location);
+   surface->address.video_progressive.chroma_addr.high_part
+   = upper_32_bits(fb_location);
+   surface->plane_size.video.luma_size.x = 0;
+   surface->plane_size.video.luma_size.y = 0;
+   surface->plane_size.video.luma_size.width = fb->width;
+   surface->plane_size.video.luma_size.height = fb->height;
+   /* TODO: unhardcode */
+   surface->plane_size.video.luma_pitch = fb->pitches[0] / 4;
+
+   surface->plane_size.video.chroma_size.x = 0;
+   surface->plane_size.video.chroma_size.y = 0;
+   surface->plane_size.video.chroma_size.width = fb->width;
+   surface->plane_size.video.chroma_size.height = fb->height;
+   surface->plane_size.video.chroma_pitch =
+   fb->pitches[0] / 4;
+
+   /* TODO: unhardcode */
+   surface->color_space = COLOR_SPACE_YCBCR709;
+   }
+
memset(>tiling_info, 0, sizeof(surface->tiling_info));
 
/* Fill GFX params */
@@ -540,20 +580,10 @@ static void fill_plane_attributes_from_fb(
surface->tiling_info.gfx9.shaderEnable = 1;
}
 
-
-   surface->plane_size.grph.surface_size.x = 0;
-   surface->plane_size.grph.surface_size.y = 0;
-   surface->plane_size.grph.surface_size.width = fb->width;
-   surface->plane_size.grph.surface_size.height = fb->height;
-   surface->plane_size.grph.surface_pitch =
-   fb->pitches[0] / (fb->bits_per_pixel / 8);
-
surface->visible = true;
surface->scaling_quality.h_taps_c = 0;
surface->scaling_quality.v_taps_c = 0;
 
-   /* TODO: unhardcode */
-   surface->color_space = COLOR_SPACE_SRGB;
/* is this needed? is surface zeroed at allocation? */
surface->scaling_quality.h_taps = 0;
surface->scaling_quality.v_taps = 0;
@@ -1795,10 +1825,8 @@ static uint32_t rgb_formats[] = {
 };
 
 static uint32_t yuv_formats[] = {
-   DRM_FORMAT_YUYV,
-   DRM_FORMAT_YVYU,
-   DRM_FORMAT_UYVY,
-   DRM_FORMAT_VYUY,
+   

[PATCH 19/24] drm/amd/display: pull commit_surfaces out of atomic_commit into helper function

2017-04-25 Thread Harry Wentland
This should make things simpler when we try to rework this later when we
pass validate_context from atomic_check to atomic_commit.

Change-Id: Icbf1514abff4b25163f4a54e73f41310e9bc970c
Signed-off-by: Harry Wentland 
Acked-by: Harry Wentland 
Reviewed-by: Tony Cheng 
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 113 +++--
 1 file changed, 62 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
index 4eb3d819404a..78c346a4affa 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
@@ -2483,6 +2483,67 @@ static void amdgpu_dm_do_flip(
 acrtc->crtc_id);
 }
 
+void dc_commit_surfaces(struct drm_atomic_state *state,
+   struct drm_device *dev, struct amdgpu_display_manager *dm)
+{
+   uint32_t i;
+   struct drm_plane *plane;
+   struct drm_plane_state *old_plane_state;
+
+   /* update planes when needed */
+   for_each_plane_in_state(state, plane, old_plane_state, i) {
+   struct drm_plane_state *plane_state = plane->state;
+   struct drm_crtc *crtc = plane_state->crtc;
+   struct drm_framebuffer *fb = plane_state->fb;
+   struct drm_connector *connector;
+   struct dm_connector_state *dm_state = NULL;
+   enum dm_commit_action action;
+   bool pflip_needed;
+
+   if (!fb || !crtc || !crtc->state->active)
+   continue;
+
+   action = get_dm_commit_action(crtc->state);
+
+   /* Surfaces are created under two scenarios:
+* 1. This commit is not a page flip.
+* 2. This commit is a page flip, and streams are created.
+*/
+   pflip_needed = !state->allow_modeset;
+   if (!pflip_needed || action == DM_COMMIT_ACTION_DPMS_ON
+   || action == DM_COMMIT_ACTION_SET) {
+   list_for_each_entry(connector,
+   >mode_config.connector_list,
+   head) {
+   if (connector->state->crtc == crtc) {
+   dm_state = to_dm_connector_state(
+   connector->state);
+   break;
+   }
+   }
+
+   /*
+* This situation happens in the following case:
+* we are about to get set mode for connector who's only
+* possible crtc (in encoder crtc mask) is used by
+* another connector, that is why it will try to
+* re-assing crtcs in order to make configuration
+* supported. For our implementation we need to make all
+* encoders support all crtcs, then this issue will
+* never arise again. But to guard code from this issue
+* check is left.
+*
+* Also it should be needed when used with actual
+* drm_atomic_commit ioctl in future
+*/
+   if (!dm_state)
+   continue;
+
+   dm_dc_surface_commit(dm->dc, crtc);
+   }
+   }
+}
+
 void amdgpu_dm_atomic_commit_tail(
struct drm_atomic_state *state)
 {
@@ -2654,57 +2715,7 @@ void amdgpu_dm_atomic_commit_tail(
}
 
/* update planes when needed */
-   for_each_plane_in_state(state, plane, old_plane_state, i) {
-   struct drm_plane_state *plane_state = plane->state;
-   struct drm_crtc *crtc = plane_state->crtc;
-   struct drm_framebuffer *fb = plane_state->fb;
-   struct drm_connector *connector;
-   struct dm_connector_state *dm_state = NULL;
-   enum dm_commit_action action;
-   bool pflip_needed;
-
-   if (!fb || !crtc || !crtc->state->active)
-   continue;
-
-   action = get_dm_commit_action(crtc->state);
-
-   /* Surfaces are created under two scenarios:
-* 1. This commit is not a page flip.
-* 2. This commit is a page flip, and streams are created.
-*/
-   pflip_needed = !state->allow_modeset;
-   if (!pflip_needed ||
-action == DM_COMMIT_ACTION_DPMS_ON ||
-action == DM_COMMIT_ACTION_SET) {
-   list_for_each_entry(connector,
- 

[PATCH 21/24] drm/amd/display: Move resource_validate_ctx_destruct to dc.h

2017-04-25 Thread Harry Wentland
This will be needed to clean up context once we add it to private
atomic state.

Change-Id: I8722d0aa9652bf7ea44e7197588f0f8abbaeac58
Signed-off-by: Harry Wentland 
Acked-by: Harry Wentland 
Reviewed-by: Tony Cheng 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c  | 22 +++---
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c |  4 ++--
 drivers/gpu/drm/amd/display/dc/dc.h   |  6 ++
 drivers/gpu/drm/amd/display/dc/inc/resource.h |  6 --
 4 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 0d870e9c7c99..5620fe361173 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -389,7 +389,7 @@ static void allocate_dc_stream_funcs(struct core_dc 
*core_dc)
 
 static void destruct(struct core_dc *dc)
 {
-   resource_validate_ctx_destruct(dc->current_context);
+   dc_resource_validate_ctx_destruct(dc->current_context);
 
destroy_links(dc);
 
@@ -654,7 +654,7 @@ bool dc_validate_resources(
result = core_dc->res_pool->funcs->validate_with_context(
core_dc, set, set_count, 
context);
 
-   resource_validate_ctx_destruct(context);
+   dc_resource_validate_ctx_destruct(context);
dm_free(context);
 
 context_alloc_fail:
@@ -684,7 +684,7 @@ bool dc_validate_guaranteed(
result = core_dc->res_pool->funcs->validate_guaranteed(
core_dc, stream, context);
 
-   resource_validate_ctx_destruct(context);
+   dc_resource_validate_ctx_destruct(context);
dm_free(context);
 
 context_alloc_fail:
@@ -838,7 +838,7 @@ bool dc_commit_streams(
__func__,
result);
BREAK_TO_DEBUGGER();
-   resource_validate_ctx_destruct(context);
+   dc_resource_validate_ctx_destruct(context);
goto fail;
}
 
@@ -870,7 +870,7 @@ bool dc_commit_streams(
context->streams[i]->public.timing.pix_clk_khz);
}
 
-   resource_validate_ctx_destruct(core_dc->current_context);
+   dc_resource_validate_ctx_destruct(core_dc->current_context);
dm_free(core_dc->current_context);
 
core_dc->current_context = context;
@@ -903,7 +903,7 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
dm_error("%s: failed to create validate ctx\n", __func__);
return false;
}
-   resource_validate_ctx_copy_construct(core_dc->current_context, context);
+   dc_resource_validate_ctx_copy_construct(core_dc->current_context, 
context);
 
post_surface_trace(dc);
for (i = 0; i < context->res_ctx.pool->pipe_count; i++)
@@ -920,9 +920,9 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
 
core_dc->hwss.set_bandwidth(core_dc, context, true);
 
-   resource_validate_ctx_copy_construct(context, core_dc->current_context);
+   dc_resource_validate_ctx_copy_construct(context, 
core_dc->current_context);
 
-   resource_validate_ctx_destruct(context);
+   dc_resource_validate_ctx_destruct(context);
dm_free(context);
 
return true;
@@ -1205,7 +1205,7 @@ void dc_update_surfaces_and_stream(struct dc *dc,
 
/* initialize scratch memory for building context */
context = dm_alloc(sizeof(*context));
-   resource_validate_ctx_copy_construct(
+   dc_resource_validate_ctx_copy_construct(
core_dc->current_context, context);
 
/* add surface to context */
@@ -1409,7 +1409,7 @@ void dc_update_surfaces_and_stream(struct dc *dc,
}
 
if (core_dc->current_context != context) {
-   resource_validate_ctx_destruct(core_dc->current_context);
+   dc_resource_validate_ctx_destruct(core_dc->current_context);
dm_free(core_dc->current_context);
 
core_dc->current_context = context;
@@ -1418,7 +1418,7 @@ void dc_update_surfaces_and_stream(struct dc *dc,
 
 fail:
if (core_dc->current_context != context) {
-   resource_validate_ctx_destruct(context);
+   dc_resource_validate_ctx_destruct(context);
dm_free(context);
}
 }
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 2d40864b7b48..2e12a0ba5ddf 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -2050,7 +2050,7 @@ static void set_vsc_info_packet(
/*TODO: stereo 3D support and extend pixel encoding colorimetry*/
 }
 
-void resource_validate_ctx_destruct(struct validate_context *context)

[PATCH 17/24] drm/amd/display: update dce8 & 10 bw programming

2017-04-25 Thread Harry Wentland
From: Dmytro Laktyushkin 

Change-Id: Ie849339294198186c47ce21a26b082edf853762f
Signed-off-by: Dmytro Laktyushkin 
Acked-by: Harry Wentland 
Reviewed-by: Jordan Lazare 
---
 .../amd/display/dc/dce100/dce100_hw_sequencer.c| 28 +++---
 .../amd/display/dc/dce100/dce100_hw_sequencer.h|  7 +++---
 .../drm/amd/display/dc/dce100/dce100_resource.c|  1 +
 .../amd/display/dc/dce110/dce110_hw_sequencer.c|  3 +--
 .../drm/amd/display/dc/dce80/dce80_hw_sequencer.c  | 19 +--
 drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h  |  4 
 6 files changed, 21 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce100/dce100_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dce100/dce100_hw_sequencer.c
index f11044e0245c..dd6f0b1bd8ae 100644
--- a/drivers/gpu/drm/amd/display/dc/dce100/dce100_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce100/dce100_hw_sequencer.c
@@ -28,6 +28,8 @@
 #include "core_types.h"
 #include "hw_sequencer.h"
 #include "dce100_hw_sequencer.h"
+#include "resource.h"
+
 #include "dce110/dce110_hw_sequencer.h"
 
 /* include DCE10 register header files */
@@ -104,7 +106,7 @@ static bool dce100_enable_display_power_gating(
return false;
 }
 
-void dce100_pplib_apply_display_requirements(
+static void dce100_pplib_apply_display_requirements(
struct core_dc *dc,
struct validate_context *context)
 {
@@ -112,6 +114,8 @@ void dce100_pplib_apply_display_requirements(
 
pp_display_cfg->avail_mclk_switch_time_us =

dce110_get_min_vblank_time_us(context);
+   pp_display_cfg->min_memory_clock_khz = context->bw_results.required_yclk
+   / MEMORY_TYPE_MULTIPLIER;
 
dce110_fill_display_configs(context, pp_display_cfg);
 
@@ -122,20 +126,18 @@ void dce100_pplib_apply_display_requirements(
dc->prev_display_config = *pp_display_cfg;
 }
 
-
-
-static void set_displaymarks(
-   const struct core_dc *dc, struct validate_context *context)
-{
-   /* Do nothing until we have proper bandwitdth calcs */
-}
-
-static void set_bandwidth(
+void dce100_set_bandwidth(
struct core_dc *dc,
struct validate_context *context,
bool decrease_allowed)
 {
-   dc->hwss.set_displaymarks(dc, context);
+   if (decrease_allowed || context->dispclk_khz > 
dc->current_context->dispclk_khz) {
+   context->res_ctx.pool->display_clock->funcs->set_clock(
+   context->res_ctx.pool->display_clock,
+   context->dispclk_khz * 115 / 100);
+   dc->current_context->bw_results.dispclk_khz = 
context->dispclk_khz;
+   dc->current_context->dispclk_khz = context->dispclk_khz;
+   }
dce100_pplib_apply_display_requirements(dc, context);
 }
 
@@ -146,10 +148,8 @@ bool dce100_hw_sequencer_construct(struct core_dc *dc)
 {
dce110_hw_sequencer_construct(dc);
 
-   /* TODO: dce80 is empty implementation at the moment*/
dc->hwss.enable_display_power_gating = 
dce100_enable_display_power_gating;
-   dc->hwss.set_displaymarks = set_displaymarks;
-   dc->hwss.set_bandwidth = set_bandwidth;
+   dc->hwss.set_bandwidth = dce100_set_bandwidth;
 
return true;
 }
diff --git a/drivers/gpu/drm/amd/display/dc/dce100/dce100_hw_sequencer.h 
b/drivers/gpu/drm/amd/display/dc/dce100/dce100_hw_sequencer.h
index f51d04a66a49..24433f0e770b 100644
--- a/drivers/gpu/drm/amd/display/dc/dce100/dce100_hw_sequencer.h
+++ b/drivers/gpu/drm/amd/display/dc/dce100/dce100_hw_sequencer.h
@@ -33,9 +33,10 @@ struct validate_context;
 
 bool dce100_hw_sequencer_construct(struct core_dc *dc);
 
-void dce100_pplib_apply_display_requirements(
-   struct core_dc *dc,
-   struct validate_context *context);
+void dce100_set_bandwidth(
+   struct core_dc *dc,
+   struct validate_context *context,
+   bool decrease_allowed);
 
 #endif /* __DC_HWSS_DCE100_H__ */
 
diff --git a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
index 7fae8537e18a..9b365597cec5 100644
--- a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
@@ -771,6 +771,7 @@ bool dce100_validate_bandwidth(
 {
/* TODO implement when needed but for now hardcode max value*/
context->dispclk_khz = 681000;
+   context->bw_results.required_yclk = 25 * MEMORY_TYPE_MULTIPLIER;
 
return true;
 }
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
index 6bf03d680314..2fbf6ddcf3be 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
+++ 

[PATCH 11/24] drm/amd/display: use full surface update when stream is NULL

2017-04-25 Thread Harry Wentland
From: Charlene Liu 

Change-Id: I70cb09ed6bbc3f368aedef36c5a4a4708823606c
Signed-off-by: Charlene Liu 
Acked-by: Harry Wentland 
Reviewed-by: Tony Cheng 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c| 2 +-
 drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 70dc02cf4dbb..6576137ee189 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1155,7 +1155,7 @@ enum surface_update_type 
dc_check_update_surfaces_for_stream(
int i;
enum surface_update_type overall_type = UPDATE_TYPE_FAST;
 
-   if (stream_status->surface_count != surface_count)
+   if (stream_status == NULL || stream_status->surface_count != 
surface_count)
return UPDATE_TYPE_FULL;
 
if (stream_update)
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
index 7430be502efd..1401331080c5 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
@@ -1599,11 +1599,11 @@ enum dc_status dce110_apply_ctx_to_hw(
apply_min_clocks(dc, context, _state, true);
 
if (context->dispclk_khz
-   > dc->current_context->dispclk_khz)
+   > dc->current_context->dispclk_khz) {
context->res_ctx.pool->display_clock->funcs->set_clock(
context->res_ctx.pool->display_clock,
context->dispclk_khz * 115 / 100);
-
+   }
/* program audio wall clock. use HDMI as clock source if HDMI
 * audio active. Otherwise, use DP as clock source
 * first, loop to find any HDMI audio, if not, loop find DP audio
-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 24/24] drm/amd/display: get_atomic_property missing for drm_connector_funcs

2017-04-25 Thread Harry Wentland
From: Pratik Vishwakarma 

DRM_IOCTL_MODE_GETCONNECTOR fails with EINVAL on enabling DRIVER_ATOMIC
With this DRM_IOCTL_MODE_GETCONNECTOR returns all the connector properties.
freesync_property and freesync_capable_property return 0 currently.

TESTS(On Chromium OS on Stoney Only)
* Builds without compilation errors.
* 'atomictest' proceeds after applying patch and fails with vblank event
timed out.
* Chromium OS ui comes up.

Change-Id: Ia020a085e27a95492b15934223f8da8ee6b635bf
Signed-off-by: Pratik Vishwakarma 
Reviewed-by: Tony Cheng 
Reviewed-by: Harry Wentland 
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 53 +-
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.h|  6 +++
 2 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
index 96f3cc1fc694..1ae492c51481 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
@@ -1376,6 +1376,56 @@ int amdgpu_dm_connector_atomic_set_property(
return ret;
 }
 
+int amdgpu_dm_connector_atomic_get_property(
+   struct drm_connector *connector,
+   const struct drm_connector_state *state,
+   struct drm_property *property,
+   uint64_t *val)
+{
+   struct drm_device *dev = connector->dev;
+   struct amdgpu_device *adev = dev->dev_private;
+   struct dm_connector_state *dm_state =
+   to_dm_connector_state(state);
+   int ret = -EINVAL;
+
+   if (property == dev->mode_config.scaling_mode_property) {
+   switch (dm_state->scaling) {
+   case RMX_CENTER:
+   *val = DRM_MODE_SCALE_CENTER;
+   break;
+   case RMX_ASPECT:
+   *val = DRM_MODE_SCALE_ASPECT;
+   break;
+   case RMX_FULL:
+   *val = DRM_MODE_SCALE_FULLSCREEN;
+   break;
+   case RMX_OFF:
+   default:
+   *val = DRM_MODE_SCALE_NONE;
+   break;
+   }
+   ret = 0;
+   } else if (property == adev->mode_info.underscan_hborder_property) {
+   *val = dm_state->underscan_hborder;
+   ret = 0;
+   } else if (property == adev->mode_info.underscan_vborder_property) {
+   *val = dm_state->underscan_vborder;
+   ret = 0;
+   } else if (property == adev->mode_info.underscan_property) {
+   *val = dm_state->underscan_enable;
+   ret = 0;
+   } else if (property == adev->mode_info.freesync_property) {
+   //TODO
+   *val = 0;
+   ret = 0;
+   } else if (property == adev->mode_info.freesync_capable_property) {
+   //TODO
+   *val = 0;
+   ret = 0;
+   }
+   return ret;
+}
+
 void amdgpu_dm_connector_destroy(struct drm_connector *connector)
 {
struct amdgpu_connector *aconnector = to_amdgpu_connector(connector);
@@ -1447,7 +1497,8 @@ static const struct drm_connector_funcs 
amdgpu_dm_connector_funcs = {
.destroy = amdgpu_dm_connector_destroy,
.atomic_duplicate_state = amdgpu_dm_connector_atomic_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-   .atomic_set_property = amdgpu_dm_connector_atomic_set_property
+   .atomic_set_property = amdgpu_dm_connector_atomic_set_property,
+   .atomic_get_property = amdgpu_dm_connector_atomic_get_property
 };
 
 static struct drm_encoder *best_encoder(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.h
index ab6d51dbbf4b..b69c86826b1a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.h
@@ -71,6 +71,12 @@ int amdgpu_dm_connector_atomic_set_property(
struct drm_property *property,
uint64_t val);
 
+int amdgpu_dm_connector_atomic_get_property(
+   struct drm_connector *connector,
+   const struct drm_connector_state *state,
+   struct drm_property *property,
+   uint64_t *val);
+
 int amdgpu_dm_get_encoder_crtc_mask(struct amdgpu_device *adev);
 
 void amdgpu_dm_connector_init_helper(
-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 22/24] drm/amd/display: Return context from validate_context

2017-04-25 Thread Harry Wentland
This will allow us to carry it from check to commit

Change-Id: I367aa586498b2ff1a4bb2527d395a6451054cdf2
Signed-off-by: Harry Wentland 
Acked-by: Harry Wentland 
Reviewed-by: Tony Cheng 
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 26 +++-
 drivers/gpu/drm/amd/display/dc/core/dc.c   | 36 +-
 drivers/gpu/drm/amd/display/dc/dc.h|  5 +++
 3 files changed, 52 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
index 78c346a4affa..f6d41cf29cea 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
@@ -1508,6 +1508,7 @@ int amdgpu_dm_connector_mode_valid(
/* TODO: Unhardcode stream count */
struct dc_stream *stream;
struct amdgpu_connector *aconnector = to_amdgpu_connector(connector);
+   struct validate_context *context;
 
if ((mode->flags & DRM_MODE_FLAG_INTERLACE) ||
(mode->flags & DRM_MODE_FLAG_DBLSCAN))
@@ -1542,8 +1543,13 @@ int amdgpu_dm_connector_mode_valid(
stream->src.height = mode->vdisplay;
stream->dst = stream->src;
 
-   if (dc_validate_resources(adev->dm.dc, _set, 1))
+   context = dc_get_validate_context(adev->dm.dc, _set, 1);
+
+   if (context) {
result = MODE_OK;
+   dc_resource_validate_ctx_destruct(context);
+   dm_free(context);
+   }
 
dc_stream_release(stream);
 
@@ -2975,6 +2981,7 @@ int amdgpu_dm_atomic_check(struct drm_device *dev,
struct amdgpu_device *adev = dev->dev_private;
struct dc *dc = adev->dm.dc;
bool need_to_validate = false;
+   struct validate_context *context;
 
ret = drm_atomic_helper_check(dev, state);
 
@@ -3197,15 +3204,20 @@ int amdgpu_dm_atomic_check(struct drm_device *dev,
}
}
 
-   if (need_to_validate == false || set_count == 0 ||
-   dc_validate_resources(dc, set, set_count))
+   context = dc_get_validate_context(dc, set, set_count);
+
+   if (need_to_validate == false || set_count == 0 || context)
ret = 0;
 
-   for (i = 0; i < set_count; i++) {
-   for (j = 0; j < set[i].surface_count; j++) {
-   dc_surface_release(set[i].surfaces[j]);
-   }
+   if (context) {
+   dc_resource_validate_ctx_destruct(context);
+   dm_free(context);
}
+
+   for (i = 0; i < set_count; i++)
+   for (j = 0; j < set[i].surface_count; j++)
+   dc_surface_release(set[i].surfaces[j]);
+
for (i = 0; i < new_stream_count; i++)
dc_stream_release(new_streams[i]);
 
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 5620fe361173..64b5216fb920 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -635,7 +635,7 @@ static bool is_validation_required(
return false;
 }
 
-bool dc_validate_resources(
+struct validate_context *dc_get_validate_context(
const struct dc *dc,
const struct dc_validation_set set[],
uint8_t set_count)
@@ -644,31 +644,51 @@ bool dc_validate_resources(
enum dc_status result = DC_ERROR_UNEXPECTED;
struct validate_context *context;
 
-   if (!is_validation_required(core_dc, set, set_count))
-   return true;
-
context = dm_alloc(sizeof(struct validate_context));
if(context == NULL)
goto context_alloc_fail;
 
+   if (!is_validation_required(core_dc, set, set_count)) {
+   
dc_resource_validate_ctx_copy_construct(core_dc->current_context, context);
+   return context;
+   }
+
result = core_dc->res_pool->funcs->validate_with_context(
core_dc, set, set_count, 
context);
 
-   dc_resource_validate_ctx_destruct(context);
-   dm_free(context);
-
 context_alloc_fail:
if (result != DC_OK) {
dm_logger_write(core_dc->ctx->logger, LOG_WARNING,
"%s:resource validation failed, dc_status:%d\n",
__func__,
result);
+
+   dc_resource_validate_ctx_destruct(context);
+   dm_free(context);
+   context = NULL;
}
 
-   return (result == DC_OK);
+   return context;
 
 }
 
+bool dc_validate_resources(
+   const struct dc *dc,
+   const struct dc_validation_set set[],
+   uint8_t set_count)
+{
+   struct validate_context *ctx;
+
+   ctx = dc_get_validate_context(dc, set, set_count);
+   

[PATCH 06/24] drm/amd/display: change mpo surface update check condition.

2017-04-25 Thread Harry Wentland
From: Yongqiang Sun 

Change-Id: If787d1384eae0cdee917effc939464e0abc8453d
Signed-off-by: Yongqiang Sun 
Acked-by: Harry Wentland 
Reviewed-by: Tony Cheng 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 9a3507e743cf..203cb9d0c89d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1024,7 +1024,8 @@ static unsigned int pixel_format_to_bpp(enum 
surface_pixel_format format)
 }
 
 static enum surface_update_type get_plane_info_update_type(
-   const struct dc_surface_update *u)
+   const struct dc_surface_update *u,
+   int surface_index)
 {
struct dc_plane_info temp_plane_info = { { { { 0 } } } };
 
@@ -1049,7 +1050,11 @@ static enum surface_update_type 
get_plane_info_update_type(
 
/* Special Validation parameters */
temp_plane_info.format = u->plane_info->format;
-   temp_plane_info.visible = u->plane_info->visible;
+
+   if (surface_index == 0)
+   temp_plane_info.visible = u->plane_info->visible;
+   else
+   temp_plane_info.visible = u->surface->visible;
 
if (memcmp(u->plane_info, _plane_info,
sizeof(struct dc_plane_info)) != 0)
@@ -,7 +1116,8 @@ static enum surface_update_type  
get_scaling_info_update_type(
 
 static enum surface_update_type det_surface_update(
const struct core_dc *dc,
-   const struct dc_surface_update *u)
+   const struct dc_surface_update *u,
+   int surface_index)
 {
const struct validate_context *context = dc->current_context;
enum surface_update_type type = UPDATE_TYPE_FAST;
@@ -1120,7 +1126,7 @@ static enum surface_update_type det_surface_update(
if (!is_surface_in_context(context, u->surface))
return UPDATE_TYPE_FULL;
 
-   type = get_plane_info_update_type(u);
+   type = get_plane_info_update_type(u, surface_index);
if (overall_type < type)
overall_type = type;
 
@@ -1157,7 +1163,7 @@ enum surface_update_type 
dc_check_update_surfaces_for_stream(
 
for (i = 0 ; i < surface_count; i++) {
enum surface_update_type type =
-   det_surface_update(core_dc, [i]);
+   det_surface_update(core_dc, [i], i);
 
if (type == UPDATE_TYPE_FULL)
return type;
-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 05/24] drm/amd/display: Add same check as reset pipes for programing backend regs.

2017-04-25 Thread Harry Wentland
From: Yongqiang Sun 

Change-Id: I195ba4aa84abbc2cfa3c29fe6b6f98bc65ec72e8
Signed-off-by: Yongqiang Sun 
Acked-by: Harry Wentland 
Reviewed-by: Tony Cheng 
---
 drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
index 839c34409c63..7430be502efd 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
@@ -1689,6 +1689,10 @@ enum dc_status dce110_apply_ctx_to_hw(
if (pipe_ctx->stream == pipe_ctx_old->stream)
continue;
 
+   if (pipe_ctx->stream && pipe_ctx_old->stream
+   && !pipe_need_reprogram(pipe_ctx_old, pipe_ctx))
+   continue;
+
if (pipe_ctx->top_pipe)
continue;
 
-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 04/24] drm/amd/display: Adding dm controlled signal type in dc_stream

2017-04-25 Thread Harry Wentland
From: Sylvia Tsai 

- Adding dm controlled signal type in dc_stream
- Adding fallback to dvi signal when output signal is hdmi and the connector
  type is not

Change-Id: Iec44e4035f2b9d1fb862a37bbd4e629515a97337
Signed-off-by: Sylvia Tsai 
Acked-by: Harry Wentland 
Reviewed-by: Sylvia Tsai 
---
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 30 +++
 drivers/gpu/drm/amd/display/dc/dc.h   |  1 +
 2 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 069f588a9e02..2d40864b7b48 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1237,22 +1237,22 @@ static struct audio *find_first_free_audio(struct 
resource_context *res_ctx)
 
 static void update_stream_signal(struct core_stream *stream)
 {
-   const struct dc_sink *dc_sink = stream->public.sink;
-
-   if (dc_sink->sink_signal == SIGNAL_TYPE_NONE)
-   stream->signal = stream->sink->link->public.connector_signal;
-   else if (dc_sink->sink_signal == SIGNAL_TYPE_DVI_SINGLE_LINK ||
-   dc_sink->sink_signal == SIGNAL_TYPE_DVI_DUAL_LINK)
-   /* For asic supports dual link DVI, we should adjust signal type
-* based on timing pixel clock. If pixel clock more than 165Mhz,
-* signal is dual link, otherwise, single link.
-*/
-   if (stream->public.timing.pix_clk_khz > 
TMDS_MAX_PIXEL_CLOCK_IN_KHZ)
-   stream->signal = SIGNAL_TYPE_DVI_DUAL_LINK;
+   if (stream->public.output_signal == SIGNAL_TYPE_NONE) {
+   const struct dc_sink *dc_sink = stream->public.sink;
+
+   if (dc_sink->sink_signal == SIGNAL_TYPE_NONE)
+   stream->signal =
+   stream->sink->link->
+   public.connector_signal;
else
-   stream->signal = SIGNAL_TYPE_DVI_SINGLE_LINK;
-   else
-   stream->signal = dc_sink->sink_signal;
+   stream->signal = dc_sink->sink_signal;
+   } else {
+   stream->signal = stream->public.output_signal;
+   }
+
+   if (stream->signal == SIGNAL_TYPE_DVI_SINGLE_LINK &&
+   stream->public.timing.pix_clk_khz > TMDS_MAX_PIXEL_CLOCK_IN_KHZ)
+   stream->signal = SIGNAL_TYPE_DVI_DUAL_LINK;
 }
 
 bool resource_is_stream_unchanged(
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index a27a6aba0df1..97af8f63eec3 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -411,6 +411,7 @@ enum surface_update_type {
 struct dc_stream {
const struct dc_sink *sink;
struct dc_crtc_timing timing;
+   enum signal_type output_signal;
 
enum dc_color_space output_color_space;
 
-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 15/24] drm/amd/display: Remove unused scratch_val_ctx

2017-04-25 Thread Harry Wentland
Change-Id: If74542b9c3d69f735147747f4a9bc41b0d70477a
Signed-off-by: Harry Wentland 
Acked-by: Harry Wentland 
Reviewed-by: Tony Cheng 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 3 ---
 drivers/gpu/drm/amd/display/dc/inc/core_dc.h | 1 -
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 6576137ee189..7b0b7356ae89 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -411,8 +411,6 @@ static void destruct(struct core_dc *dc)
dc->current_context = NULL;
dm_free(dc->temp_flip_context);
dc->temp_flip_context = NULL;
-   dm_free(dc->scratch_val_ctx);
-   dc->scratch_val_ctx = NULL;
 
dm_free(dc->ctx);
dc->ctx = NULL;
@@ -432,7 +430,6 @@ static bool construct(struct core_dc *dc,
 
dc->current_context = dm_alloc(sizeof(*dc->current_context));
dc->temp_flip_context = dm_alloc(sizeof(*dc->temp_flip_context));
-   dc->scratch_val_ctx = dm_alloc(sizeof(*dc->scratch_val_ctx));
 
if (!dc->current_context || !dc->temp_flip_context) {
dm_error("%s: failed to create validate ctx\n", __func__);
diff --git a/drivers/gpu/drm/amd/display/dc/inc/core_dc.h 
b/drivers/gpu/drm/amd/display/dc/inc/core_dc.h
index 8d87f490dc1c..ec3edbe20d85 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/core_dc.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/core_dc.h
@@ -23,7 +23,6 @@ struct core_dc {
 
struct validate_context *current_context;
struct validate_context *temp_flip_context;
-   struct validate_context *scratch_val_ctx;
struct resource_pool *res_pool;
 
/* Display Engine Clock levels */
-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 07/24] drm/amd/display: set NULL value during removal for remoteSink

2017-04-25 Thread Harry Wentland
From: Leon Elazar 

In MST case during removal of remote sink its descriptor pointer wasn't freed 
corectly.

Change-Id: I1fb201b44cf79d95a02253efe90cf032200c27c3
Signed-off-by: Leon Elazar 
Acked-by: Harry Wentland 
Reviewed-by: Tony Cheng 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 203cb9d0c89d..70dc02cf4dbb 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1787,7 +1787,7 @@ void dc_link_remove_remote_sink(const struct dc_link 
*link, const struct dc_sink
dc_link->remote_sinks[i] = 
dc_link->remote_sinks[i+1];
i++;
}
-
+   dc_link->remote_sinks[i] = NULL;
dc_link->sink_count--;
return;
}
-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 10/24] drm/amd/display: Fix missing irq refactor causing potential i2c race

2017-04-25 Thread Harry Wentland
From: Jordan Lazare 

Change-Id: I3bd022ac9de6a68ba937d4df6396c0c90417eb5c
Signed-off-by: Jordan Lazare 
Reviewed-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
index 36540e1e9281..70826c7739c2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
@@ -31,8 +31,10 @@
 #include 
 #include 
 
+
 #include "amdgpu.h"
 #include "amdgpu_pm.h"
+#include "dm_helpers.h"
 #include "dm_services_types.h"
 
 #include "drm_edid.h"
@@ -3205,13 +3207,16 @@ static bool is_dp_capable_without_timing_msa(
 {
uint8_t dpcd_data;
bool capable = false;
+
if (amdgpu_connector->dc_link &&
-   dc_read_aux_dpcd(
-   dc,
-   amdgpu_connector->dc_link->link_index,
-   DP_DOWN_STREAM_PORT_COUNT,
-   _data, sizeof(dpcd_data)))
+   dm_helpers_dp_read_dpcd(
+   NULL,
+   amdgpu_connector->dc_link,
+   DP_DOWN_STREAM_PORT_COUNT,
+   _data,
+   sizeof(dpcd_data))) {
capable = (dpcd_data & DP_MSA_TIMING_PAR_IGNORED) ? true:false;
+   }
 
return capable;
 }
-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 08/24] drm/amd/display: Fix for tile MST

2017-04-25 Thread Harry Wentland
From: Ding Wang 

- Set stream signal type to be SST when setting non-tile timing on MST
  tiled display.
  - Disable MST on sink after disabling MST link.
  - Enable MST on sink before enabling MST link.

Change-Id: I809c4fb6b7a83d544c4495230ced16909a7c1bef
Signed-off-by: Ding Wang 
Acked-by: Harry Wentland 
Reviewed-by: Jun Lei 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |  3 +++
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   | 13 +
 drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c |  3 +++
 drivers/gpu/drm/amd/display/dc/inc/dc_link_dp.h|  2 ++
 4 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index b878fb9697d7..426f7f8187a6 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -1250,6 +1250,9 @@ static enum dc_status enable_link_dp_mst(struct pipe_ctx 
*pipe_ctx)
if (link->public.cur_link_settings.lane_count != LANE_COUNT_UNKNOWN)
return DC_OK;
 
+   /* set the sink to MST mode before enabling the link */
+   dp_enable_mst_on_sink(link, true);
+
return enable_link_dp(pipe_ctx);
 }
 
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 9f12ba87827a..913b01cd7159 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -2453,3 +2453,16 @@ bool dc_link_dp_set_test_pattern(
 
return true;
 }
+
+void dp_enable_mst_on_sink(struct core_link *link, bool enable)
+{
+   unsigned char mstmCntl;
+
+   core_link_read_dpcd(link, DP_MSTM_CTRL, , 1);
+   if (enable)
+   mstmCntl |= DP_MST_EN;
+   else
+   mstmCntl &= (~DP_MST_EN);
+
+   core_link_write_dpcd(link, DP_MSTM_CTRL, , 1);
+}
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
index 3b814592fd70..316df150c1d9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
@@ -129,6 +129,9 @@ void dp_disable_link_phy_mst(struct core_link *link, enum 
signal_type signal)
return;
 
dp_disable_link_phy(link, signal);
+
+   /* set the sink to SST mode after disabling the link */
+   dp_enable_mst_on_sink(link, false);
 }
 
 bool dp_set_hw_training_pattern(
diff --git a/drivers/gpu/drm/amd/display/dc/inc/dc_link_dp.h 
b/drivers/gpu/drm/amd/display/dc/inc/dc_link_dp.h
index b0cf8e00059c..92c56e6f7588 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/dc_link_dp.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/dc_link_dp.h
@@ -57,4 +57,6 @@ void detect_dp_sink_caps(struct core_link *link);
 
 bool is_dp_active_dongle(const struct core_link *link);
 
+void dp_enable_mst_on_sink(struct core_link *link, bool enable);
+
 #endif /* __DC_LINK_DP_H__ */
-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: add parameter to allocate high priority contexts v8

2017-04-25 Thread Andres Rodriguez



On 2017-04-25 02:01 PM, Nicolai Hähnle wrote:

On 24.04.2017 18:20, Andres Rodriguez wrote:

Add a new context creation parameter to express a global context
priority.

The priority ranking in descending order is as follows:
 * AMDGPU_CTX_PRIORITY_HIGH
 * AMDGPU_CTX_PRIORITY_NORMAL
 * AMDGPU_CTX_PRIORITY_LOW

The driver will attempt to schedule work to the hardware according to
the priorities. No latency or throughput guarantees are provided by
this patch.

This interface intends to service the EGL_IMG_context_priority
extension, and vulkan equivalents.

v2: Instead of using flags, repurpose __pad
v3: Swap enum values of _NORMAL _HIGH for backwards compatibility
v4: Validate usermode priority and store it
v5: Move priority validation into amdgpu_ctx_ioctl(), headline reword
v6: add UAPI note regarding priorities requiring CAP_SYS_ADMIN
v7: remove ctx->priority
v8: added AMDGPU_CTX_PRIORITY_LOW, s/CAP_SYS_ADMIN/CAP_SYS_NICE

Reviewed-by: Emil Velikov 
Reviewed-by: Christian König 
Signed-off-by: Andres Rodriguez 


I didn't follow all the discussion, so feel free to shut me up if this
has already been discussed, but...


[snip]

+/* Context priority level */
+#define AMDGPU_CTX_PRIORITY_NORMAL0
+#define AMDGPU_CTX_PRIORITY_LOW1
+/* Selecting a priority above NORMAL requires CAP_SYS_ADMIN */
+#define AMDGPU_CTX_PRIORITY_HIGH2
+#define AMDGPU_CTX_PRIORITY_NUM3


I get that normal priority needs to be 0 for backwards compatibility,
but having LOW between NORMAL and HIGH is still odd. Have you considered
using signed integers as a way to fix that?


Thanks for the suggestion, that should make it a lot cleaner.

Regards,
Andres



(AMDGPU_CTX_PRIORITY_NUM doesn't seem to be used anywhere...)

Cheers,
Nicolai



+
 struct drm_amdgpu_ctx_in {
 /** AMDGPU_CTX_OP_* */
 __u32op;
 /** For future use, no flags defined so far */
 __u32flags;
 __u32ctx_id;
-__u32_pad;
+__u32priority;
 };

 union drm_amdgpu_ctx_out {
 struct {
 __u32ctx_id;
 __u32_pad;
 } alloc;

 struct {
 /** For future use, no flags defined so far */
 __u64flags;
 /** Number of resets caused by this context so far. */
 __u32hangs;
 /** Reset status since the last call of the ioctl. */
 __u32reset_status;
 } state;
 };

 union drm_amdgpu_ctx {
 struct drm_amdgpu_ctx_in in;





___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH] drm/amdgpu: Fix use of interruptible waiting

2017-04-25 Thread Alex Xie
Either in cgs functions or for callers of cgs functions:
1. The signal interrupt can affect the expected behaviour
2. There is no good mechanism to handle the corresponding error
3. There is no chance of deadlock in these single BO waiting
4. There is no clear benefit for interruptible waiting
5. Future caller of these functions might have same issue.

Change-Id: Ifc0e0ab862f98cdc6cdaef87cd96f11c91d64f27
Signed-off-by: Alex Xie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index a1a2d44..31fe4ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -89,7 +89,7 @@ static int amdgpu_cgs_gmap_kmem(struct cgs_device 
*cgs_device, void *kmem,
   AMDGPU_GEM_DOMAIN_GTT, 0, sg, NULL, );
if (ret)
return ret;
-   ret = amdgpu_bo_reserve(bo, false);
+   ret = amdgpu_bo_reserve(bo, true);
if (unlikely(ret != 0))
return ret;
 
@@ -107,7 +107,7 @@ static int amdgpu_cgs_gunmap_kmem(struct cgs_device 
*cgs_device, cgs_handle_t km
struct amdgpu_bo *obj = (struct amdgpu_bo *)kmem_handle;
 
if (obj) {
-   int r = amdgpu_bo_reserve(obj, false);
+   int r = amdgpu_bo_reserve(obj, true);
if (likely(r == 0)) {
amdgpu_bo_unpin(obj);
amdgpu_bo_unreserve(obj);
@@ -215,7 +215,7 @@ static int amdgpu_cgs_free_gpu_mem(struct cgs_device 
*cgs_device, cgs_handle_t h
struct amdgpu_bo *obj = (struct amdgpu_bo *)handle;
 
if (obj) {
-   int r = amdgpu_bo_reserve(obj, false);
+   int r = amdgpu_bo_reserve(obj, true);
if (likely(r == 0)) {
amdgpu_bo_kunmap(obj);
amdgpu_bo_unpin(obj);
@@ -239,7 +239,7 @@ static int amdgpu_cgs_gmap_gpu_mem(struct cgs_device 
*cgs_device, cgs_handle_t h
min_offset = obj->placements[0].fpfn << PAGE_SHIFT;
max_offset = obj->placements[0].lpfn << PAGE_SHIFT;
 
-   r = amdgpu_bo_reserve(obj, false);
+   r = amdgpu_bo_reserve(obj, true);
if (unlikely(r != 0))
return r;
r = amdgpu_bo_pin_restricted(obj, obj->prefered_domains,
@@ -252,7 +252,7 @@ static int amdgpu_cgs_gunmap_gpu_mem(struct cgs_device 
*cgs_device, cgs_handle_t
 {
int r;
struct amdgpu_bo *obj = (struct amdgpu_bo *)handle;
-   r = amdgpu_bo_reserve(obj, false);
+   r = amdgpu_bo_reserve(obj, true);
if (unlikely(r != 0))
return r;
r = amdgpu_bo_unpin(obj);
@@ -265,7 +265,7 @@ static int amdgpu_cgs_kmap_gpu_mem(struct cgs_device 
*cgs_device, cgs_handle_t h
 {
int r;
struct amdgpu_bo *obj = (struct amdgpu_bo *)handle;
-   r = amdgpu_bo_reserve(obj, false);
+   r = amdgpu_bo_reserve(obj, true);
if (unlikely(r != 0))
return r;
r = amdgpu_bo_kmap(obj, map);
@@ -277,7 +277,7 @@ static int amdgpu_cgs_kunmap_gpu_mem(struct cgs_device 
*cgs_device, cgs_handle_t
 {
int r;
struct amdgpu_bo *obj = (struct amdgpu_bo *)handle;
-   r = amdgpu_bo_reserve(obj, false);
+   r = amdgpu_bo_reserve(obj, true);
if (unlikely(r != 0))
return r;
amdgpu_bo_kunmap(obj);
-- 
1.9.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 1/2] drm/amdgpu: Fix use of interruptible waiting

2017-04-25 Thread Alex Xie
There is no good mechanism to handle the corresponding error.
When signal interrupt happens, unpin is not called.
As a result, inside AMDGPU, the statistic of pin size will be wrong.

Change-Id: I4a06a227c2757c447cec0058ace4b028553658a2
Signed-off-by: Alex Xie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 7cf226d..43082bf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -172,7 +172,7 @@ void amdgpu_crtc_cleanup_flip_ctx(
struct amdgpu_flip_work *work,
struct amdgpu_bo *new_abo)
 {
-   if (unlikely(amdgpu_bo_reserve(new_abo, false) != 0)) {
+   if (unlikely(amdgpu_bo_reserve(new_abo, true) != 0)) {
DRM_ERROR("failed to reserve new abo in error path\n");
amdgpu_flip_work_cleanup(work);
return;
-- 
1.9.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 2/2] drm/amdgpu: Fix use of interruptible waiting

2017-04-25 Thread Alex Xie
1. The wait is short. There is not much benefit by
interruptible waiting.
2. In this function and caller functions, the error
handling for such interrupt is complicated and risky.

Change-Id: I289674ecd3f5ef20c93fe63e33df6d668b3c2edc
Signed-off-by: Alex Xie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 43082bf..c006cc4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -227,7 +227,7 @@ int amdgpu_crtc_prepare_flip(
new_abo = gem_to_amdgpu_bo(obj);
 
/* pin the new buffer */
-   r = amdgpu_bo_reserve(new_abo, false);
+   r = amdgpu_bo_reserve(new_abo, true);
if (unlikely(r != 0)) {
DRM_ERROR("failed to reserve new abo buffer before flip\n");
goto cleanup;
-- 
1.9.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm: Harmonize CIK ASIC support in radeon and amdgpu (v2)

2017-04-25 Thread Michel Dänzer
On 22/04/17 02:05 AM, Felix Kuehling wrote:
> __setup doesn't work in modules.

Right. We could build something like
drivers/video/fbdev/core/fb_cmdline.c:video_setup() into the kernel to
handle this, but it's a bit ugly, which is one reason why I was leaning
towards:


> s8250_options is only compiled if the driver is not a module.

That doesn't prevent us from using __module_param_call directly, does it?

Although, that still doesn't work as I envision if only one driver's
option is set e.g. in /etc/modprobe.d/*.conf .


So, I'm starting to think we need a shared module for this, which
provides one or multiple module parameters to choose which driver to use
for CIK/SI[0], and provides the result to the amdgpu/radeon drivers.
That might make things easier for amdgpu-pro / other standalone amdgpu
versions in the long run as well, as they could add files to
/etc/modprobe.d/ choosing themselves by default, without having to
blacklist radeon.

What do you guys think?


[0] or possibly even more fine-grained in the future

-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 2/2] drm/amd/display: Prevent premature pageflip when comitting in vblank. (v3)

2017-04-25 Thread Michel Dänzer
On 25/04/17 01:54 AM, Mario Kleiner wrote:
> Make sure we do not program a hw pageflip inside vblank 'n' iff the
> atomic flip is comitted while inside the same vblank 'n'. We must
> defer such a flip by one refresh cycle to vblank 'n+1', unless this
> is a DRM_MODE_PAGE_FLIP_ASYNC async pageflip, which must always
> execute as soon as possible.
> 
> Without this, pageflips programmed via X11 GLX_OML_sync_control extensions
> glXSwapBuffersMscOML(..., target_msc, ...); call and/or via DRI3/Present
> PresentPixmap(..., target_msc, ...); request will complete one vblank
> too early whenever target_msc > current_msc + 1, ie. more than 1 vblank
> in the future. In such a case, the call of the pageflip ioctl() would be
> triggered by a queued drmWaitVblank() vblank event, which itself gets
> dispatched inside the vblank one frame before the target_msc vblank.
> 
> Testing with this patch does no longer show any problems with
> OML_sync_control swap scheduling or flip completion timestamps.
> Tested on R9 380 Tonga.
> 
> v2: Add acked/r-b by Harry and Michel.
> v3: Feedback from Andrey: Must not wait an extra frame for
> DRM_MODE_PAGE_FLIP_ASYNC flips.
> 
> Signed-off-by: Mario Kleiner 
> Acked-by: Harry Wentland 
> Reviewed-by: Michel Dänzer 

This patch and v2 of patch 1 pushed to the internal amd-staging-4.9
branch, thanks!


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 1/2] drm/amdgpu: Real return value can be over-written when clean up

2017-04-25 Thread Christian König

Am 24.04.2017 um 21:34 schrieb Alex Xie:

Change-Id: Ib69f035eeb213a1aec5025e0a9f4515065706118
Signed-off-by: Alex Xie 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
index 3453052..76be2d2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
@@ -117,6 +117,11 @@ static void amdgpu_benchmark_move(struct amdgpu_device 
*adev, unsigned size,
}
  
  out_cleanup:

+   /* Check error value now. The value can be overwritten when clean up.*/
+   if (r) {
+   DRM_ERROR("Error while benchmarking BO move.\n");
+   }
+
if (sobj) {
r = amdgpu_bo_reserve(sobj, false);
if (likely(r == 0)) {
@@ -133,10 +138,6 @@ static void amdgpu_benchmark_move(struct amdgpu_device 
*adev, unsigned size,
}
amdgpu_bo_unref();
}
-
-   if (r) {
-   DRM_ERROR("Error while benchmarking BO move.\n");
-   }
  }
  
  void amdgpu_benchmark(struct amdgpu_device *adev, int test_number)



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 2/2] drm/amdgpu: Fix use of interruptible waiting 1. The signal interrupt can affect the expected behaviour. 2. There is no good mechanism to handle the corresponding error. When signal int

2017-04-25 Thread Christian König
You somehow messed up the commit message. Everything got mangled into 
the subject line while sending the mails.


Apart from that the change looks good to me and with the commit message 
fixed is Reviewed-by: Christian König 


Regards,
Christian.

Am 24.04.2017 um 21:34 schrieb Alex Xie:

Change-Id: I6889a4d9dd2703bcf5d448d18f6af51c496a93c9
Signed-off-by: Alex Xie 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
index 76be2d2..75bd76f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
@@ -123,7 +123,7 @@ static void amdgpu_benchmark_move(struct amdgpu_device 
*adev, unsigned size,
}
  
  	if (sobj) {

-   r = amdgpu_bo_reserve(sobj, false);
+   r = amdgpu_bo_reserve(sobj, true);
if (likely(r == 0)) {
amdgpu_bo_unpin(sobj);
amdgpu_bo_unreserve(sobj);
@@ -131,7 +131,7 @@ static void amdgpu_benchmark_move(struct amdgpu_device 
*adev, unsigned size,
amdgpu_bo_unref();
}
if (dobj) {
-   r = amdgpu_bo_reserve(dobj, false);
+   r = amdgpu_bo_reserve(dobj, true);
if (likely(r == 0)) {
amdgpu_bo_unpin(dobj);
amdgpu_bo_unreserve(dobj);



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 1/4] drm/amdgpu: Fix potential issue if reserve function is interrupted If amdgpu_bo_reserve function is interrupted by signal, amdgpu_bo_kunmap function is not called.

2017-04-25 Thread Christian König

All commit messages got mangled into the subject line.

You probably forgot the empty line between subject and commit message 
while creating the commit.


With that fixed the whole series is Reviewed-by: Christian König 
.


Regards,
Christian.

Am 24.04.2017 um 20:29 schrieb Alex Xie:

Change-Id: Ide2b3be6549b3afb8d6116094b5fff495b18addf
Signed-off-by: Alex Xie 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a09ad3cf..051696d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -350,7 +350,7 @@ static void amdgpu_vram_scratch_fini(struct amdgpu_device 
*adev)
if (adev->vram_scratch.robj == NULL) {
return;
}
-   r = amdgpu_bo_reserve(adev->vram_scratch.robj, false);
+   r = amdgpu_bo_reserve(adev->vram_scratch.robj, true);
if (likely(r == 0)) {
amdgpu_bo_kunmap(adev->vram_scratch.robj);
amdgpu_bo_unpin(adev->vram_scratch.robj);



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 1/2] drm/amdgpu: fix gpu reset crash

2017-04-25 Thread Christian König

Am 25.04.2017 um 04:20 schrieb zhoucm1:



On 2017年04月24日 17:47, Christian König wrote:

The root cause is some ring doesn't have scheduler, like KIQ ring

Change-Id: I420e84add9cdd9a7fd1f9921b8a5d0afa3dd2058
Signed-off-by: Chunming Zhou 


Reviewed-by: Christian König  for both. 

I forgot to add RB when pushing patches, How can I add it again?


Does gerrit actually accept the commit in this case?

If not you could add the rb and try to push it again.

If yes you should ping Alex to add it when he upstreams the patch.

(Not so much of an issue Alex is probably taking care of that anyway 
while upstreaming).


Christian.



Sorry for that.
David Zhou



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: validate shadow before restoring from it

2017-04-25 Thread Christian König

Am 25.04.2017 um 05:16 schrieb zhoucm1:



On 2017年04月25日 11:14, Roger.He wrote:

Change-Id: Id925f4e241c4192127880d2017fbf2979aa09fc7
Signed-off-by: Roger.He 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 33 
++

  1 file changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

index f74149c..cebd546 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2468,6 +2468,27 @@ bool amdgpu_need_backup(struct amdgpu_device 
*adev)

  return amdgpu_lockup_timeout > 0 ? true : false;
  }
  +static int amdgpu_bo_validate(struct amdgpu_bo *bo)
+{
+uint32_t domain;
+int r;
+
+if (bo->pin_count)
+return 0;
+
+domain = bo->prefered_domains;
+
+retry:
+amdgpu_ttm_placement_from_domain(bo, domain);
+r = ttm_bo_validate(>tbo, >placement, false, false);
+if (unlikely(r == -ENOMEM) && domain != bo->allowed_domains) {
+domain = bo->allowed_domains;
+goto retry;
+}
+
+return r;
+}
you can move this function to amdgpu_object.c, with that fix, it looks 
ok to me, Reviewed-by: Chunming Zhou 


Yeah, agree. Might even be a good idea to use this helper in amdgpu_cs.c 
as well. IIRC we had something very similar in there as well.


But that should be a separate patch, with the function moved to 
amdgpu_object.c this patch is Reviewed-by: Christian König 
 as well.


Regards,
Christian.




+
  static int amdgpu_recover_vram_from_shadow(struct amdgpu_device *adev,
 struct amdgpu_ring *ring,
 struct amdgpu_bo *bo,
@@ -2485,6 +2506,18 @@ static int 
amdgpu_recover_vram_from_shadow(struct amdgpu_device *adev,

  domain = amdgpu_mem_type_to_domain(bo->tbo.mem.mem_type);
  /* if bo has been evicted, then no need to recover */
  if (domain == AMDGPU_GEM_DOMAIN_VRAM) {
+r = amdgpu_bo_validate(bo->shadow);
+if (r) {
+DRM_ERROR("bo validate failed!\n");
+goto err;
+}
+
+r = amdgpu_ttm_bind(>shadow->tbo, >shadow->tbo.mem);
+if (r) {
+DRM_ERROR("%p bind failed\n", bo->shadow);
+goto err;
+}
+
  r = amdgpu_bo_restore_from_shadow(adev, ring, bo,
   NULL, fence, true);
  if (r) {


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: amdgpu 0000:84:00.0: gpu post error! \\ Fatal error during GPU init

2017-04-25 Thread Dennis Schridde
Hi!

I replaced the AMD FirePro S7150X2 card with a AMD Radeon R5 230 (the only 
other AMD card we had available), to see whether the problem was caused by 
another hardware component of the system.

The kernel boots fine with this card. I see no errors in the log (attached).

--Dennis[0.00] Linux version 4.10.9-coreos-r1 (tf128@c07060) (gcc version 4.9.4 (Gentoo Hardened 4.9.4 p1.0, pie-0.6.4) ) #1 SMP Thu Apr 13 19:02:51 CEST 2017
[0.00] Command line: coreos.config.url=http://192.168.10.27:8080/ignition?uuid=4c4c4544-004c-5610-804c-b8c04f574732=18-66-da-f0-43-18 coreos.autologin coreos.first_boot console=ttyS0,115200n8 console=tty0
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0008dfff] usable
[0.00] BIOS-e820: [mem 0x0008e000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7a288fff] usable
[0.00] BIOS-e820: [mem 0x7a289000-0x7af0afff] reserved
[0.00] BIOS-e820: [mem 0x7af0b000-0x7b93afff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7b93b000-0x7bab3fff] ACPI data
[0.00] BIOS-e820: [mem 0x7bab4000-0x7bae8fff] usable
[0.00] BIOS-e820: [mem 0x7bae9000-0x7bafefff] ACPI data
[0.00] BIOS-e820: [mem 0x7baff000-0x7baf] usable
[0.00] BIOS-e820: [mem 0x7bb0-0x8fff] reserved
[0.00] BIOS-e820: [mem 0xfeda8000-0xfedabfff] reserved
[0.00] BIOS-e820: [mem 0xff31-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00407fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.8 present.
[0.00] DMI: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.2.5 09/06/2016
[0.00] e820: last_pfn = 0x408 max_arch_pfn = 0x4
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT
[0.00] e820: last_pfn = 0x7bb00 max_arch_pfn = 0x4
[0.00] Using GB pages for direct mapping
[0.00] RAMDISK: [mem 0x6abee000-0x7a1eafff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000FE320 24 (v02 DELL  )
[0.00] ACPI: XSDT 0x7BAF9188 D4 (v01 DELL   PE_SC3     0113)
[0.00] ACPI: FACP 0x7BAAC000 F4 (v04 DELL   PE_SC3    DELL 0001)
[0.00] ACPI: DSDT 0x7BA94000 0107EF (v02 DELL   PE_SC3   0003 DELL 0001)
[0.00] ACPI: FACS 0x7B8C2000 40
[0.00] ACPI: MCEJ 0x7BAB1000 000130 (v01 INTEL   0001 INTL 010D)
[0.00] ACPI: SSDT 0x7BAB 0003C6 (v02 DELL   Tpm2Tabl 1000 INTL 20121114)
[0.00] ACPI: TPM2 0x7BAAF000 38 (v04 DELL   EDK2 0002  0113)
[0.00] ACPI: WD__ 0x7BAAE000 000134 (v01 DELL   PE_SC3   0001 DELL 0001)
[0.00] ACPI: SLIC 0x7BAAD000 24 (v01 DELL   PE_SC3   0001 DELL 0001)
[0.00] ACPI: HPET 0x7BAAB000 38 (v01 DELL   PE_SC3   0001 DELL 0001)
[0.00] ACPI: APIC 0x7BAAA000 000AFC (v02 DELL   PE_SC3    DELL 0001)
[0.00] ACPI: MCFG 0x7BAA9000 3C (v01 DELL   PE_SC3   0001 DELL 0001)
[0.00] ACPI: MSCT 0x7BAA8000 90 (v01 DELL   PE_SC3   0001 DELL 0001)
[0.00] ACPI: SLIT 0x7BAA7000 6C (v01 DELL   PE_SC3   0001 DELL 0001)
[0.00] ACPI: SRAT 0x7BAA5000 001130 (v03 DELL   PE_SC3   0001 DELL 0001)
[0.00] ACPI: SSDT 0x7B951000 1424A9 (v02 DELL   PE_SC3   4000 INTL 20121114)
[0.00] ACPI: SSDT 0x7B94E000 002198 (v02 DELL   PE_SC3   0002 INTL 20121114)
[0.00] ACPI: SSDT 0x7B94D000 6E (v02 DELL   PE_SC3   0002 INTL 20121114)
[0.00] ACPI: PRAD 0x7B94C000 000132 (v02 DELL   PE_SC3   0002 INTL 20121114)
[0.00] ACPI: SPCR 0x7BAFE000 50 (v01   )
[0.00] ACPI: DMAR 0x7BAFD000 000120 (v01 DELL   PE_SC3   0001 DELL 0001)
[0.00] ACPI: HEST 0x7BAFC000 00017C (v01 DELL   PE_SC3   0002 DELL 0001)
[0.00] ACPI: BERT 0x7BAFB000 30 (v01 DELL   PE_SC3   0002 DELL 

RE: [PATCH] drm/amdgpu: validate shadow before restoring from it

2017-04-25 Thread He, Hongbo
-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de] 
Sent: Tuesday, April 25, 2017 4:10 PM
To: Zhou, David(ChunMing); He, Hongbo; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: validate shadow before restoring from it

Am 25.04.2017 um 05:16 schrieb zhoucm1:
>
>
> On 2017年04月25日 11:14, Roger.He wrote:
>> Change-Id: Id925f4e241c4192127880d2017fbf2979aa09fc7
>> Signed-off-by: Roger.He 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 33
>> ++
>>   1 file changed, 33 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index f74149c..cebd546 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -2468,6 +2468,27 @@ bool amdgpu_need_backup(struct amdgpu_device
>> *adev)
>>   return amdgpu_lockup_timeout > 0 ? true : false;
>>   }
>>   +static int amdgpu_bo_validate(struct amdgpu_bo *bo)
>> +{
>> +uint32_t domain;
>> +int r;
>> +
>> +if (bo->pin_count)
>> +return 0;
>> +
>> +domain = bo->prefered_domains;
>> +
>> +retry:
>> +amdgpu_ttm_placement_from_domain(bo, domain);
>> +r = ttm_bo_validate(>tbo, >placement, false, false);
>> +if (unlikely(r == -ENOMEM) && domain != bo->allowed_domains) {
>> +domain = bo->allowed_domains;
>> +goto retry;
>> +}
>> +
>> +return r;
>> +}
> you can move this function to amdgpu_object.c, with that fix, it looks 
> ok to me, Reviewed-by: Chunming Zhou 

Yeah, agree. Might even be a good idea to use this helper in amdgpu_cs.c as 
well. IIRC we had something very similar in there as well.

Yes, I have noticed  they have some similar logic code. Later if have time,  I 
will try to do that.  Thanks for your suggestion!

Thanks
Roger(Hongbo.He)

But that should be a separate patch, with the function moved to amdgpu_object.c 
this patch is Reviewed-by: Christian König  as well.

Regards,
Christian.

>
>> +
>>   static int amdgpu_recover_vram_from_shadow(struct amdgpu_device *adev,
>>  struct amdgpu_ring *ring,
>>  struct amdgpu_bo *bo, @@ -2485,6 +2506,18 @@ 
>> static int amdgpu_recover_vram_from_shadow(struct amdgpu_device 
>> *adev,
>>   domain = amdgpu_mem_type_to_domain(bo->tbo.mem.mem_type);
>>   /* if bo has been evicted, then no need to recover */
>>   if (domain == AMDGPU_GEM_DOMAIN_VRAM) {
>> +r = amdgpu_bo_validate(bo->shadow);
>> +if (r) {
>> +DRM_ERROR("bo validate failed!\n");
>> +goto err;
>> +}
>> +
>> +r = amdgpu_ttm_bind(>shadow->tbo, >shadow->tbo.mem);
>> +if (r) {
>> +DRM_ERROR("%p bind failed\n", bo->shadow);
>> +goto err;
>> +}
>> +
>>   r = amdgpu_bo_restore_from_shadow(adev, ring, bo,
>>NULL, fence, true);
>>   if (r) {
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 0/6] *** Dedicated vmid per process v2 ***

2017-04-25 Thread zhoucm1

ping... anyone can give the review?

Thanks,
David Zhou

On 2017年04月24日 13:57, Chunming Zhou wrote:

The current kernel implementation, which grabs the idle VMID from pool when 
emitting the job may:

 The back-to-back submission from one process could use different VMID.
 The submission to different queues from single process could use different 
VMID

It works well in most case but cannot work for the SQ thread trace capture.

The VMID for the submission that set the {SQTT}_BASE, which refers to the 
address of the trace buffer, is stored in shader engine.

If the profiling application have to use different VMIDs to submit IBs in its 
life cycle:

 Some trace is not captured since it actually uses different VMID to submit 
jobs.
 Some part of captured trace may come from different application since they 
are accidentally uses the owner’s VMID to submit jobs.

V2:
1. address Christian's comments:
a. drop context flags for tag process, instead, add vm ioctl.
b. change order of patches.
c. sync waiting only when vm flush needs.

2. address Alex's comments;
bump module version

Chunming Zhou (6):
   drm/amdgpu: add vm ioctl
   drm/amdgpu: add dedicated vmid field in vm struct
   drm/amdgpu: reserve vmid by vm ioctl
   drm/amdgpu: add limitation for dedicated vm number v2
   drm/amdgpu: implement grab dedicated vmid V2
   drm/amdgpu: bump module verion for reserved vmid

  drivers/gpu/drm/amd/amdgpu/amdgpu.h|   1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   3 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|   1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 159 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   5 +
  include/uapi/drm/amdgpu_drm.h  |  20 
  7 files changed, 188 insertions(+), 2 deletions(-)



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 0/6] drm: tackle byteorder issues, take two

2017-04-25 Thread Ville Syrjälä
On Tue, Apr 25, 2017 at 09:49:38AM +0900, Michel Dänzer wrote:
> On 24/04/17 11:26 PM, Ville Syrjälä wrote:
> > On Mon, Apr 24, 2017 at 04:54:25PM +0900, Michel Dänzer wrote:
> >> On 24/04/17 04:36 PM, Gerd Hoffmann wrote:
> >>>
> >   drm: fourcc byteorder: add DRM_FORMAT_CPU_*
> >   drm: fourcc byteorder: add bigendian support to
> > drm_mode_legacy_fb_format
> 
>  As I explained in my last followup in the "[PATCH] drm: fourcc
>  byteorder: brings header file comments in line with reality." thread,
>  the mapping between GPU and CPU formats has to be provided by the
>  driver, it cannot be done statically.
> >>>
> >>> Well, the drm fourcc codes represent the cpu view (i.e. what userspace
> >>> will fill the ADDFB2-created framebuffers with).
> >>
> >> Ville is adamant that they represent the GPU view. This needs to be
> >> resolved one way or the other.
> > 
> > Since the byte swapping can happen either for CPU or display access
> > I guess we can't just consider the GPU and display as a single entity.
> > 
> > We may need to consider several agents:
> > 1. display
> > 2. GPU
> > 3. CPU
> > 4. other DMA
> > 
> > Not sure what we can say about 4. I presume it's going to be like the
> > GPU or the CPU in the sense that it might go through the CPU byte
> > swapping logic or not. I'm just going to ignore it.
> > 
> > Let's say we have the following bytes in memory
> > (in order of increasing address): A,B,C,D
> > We'll assume GPU and display are LE natively. Each component will see
> > the resulting 32bpp  pixel as follows (msb left->lsb right):
> > 
> > LE CPU w/ no byte swapping:
> >  display: DCBA
> >  GPU: DCBA
> >  CPU: DCBA
> >  = everyone agrees
> > 
> > BE CPU w/ no byte swapping:
> >  display: DCBA
> >  GPU: DCBA
> >  CPU: ABCD
> >  = GPU and display agree
> > 
> > BE CPU w/ display byte swapping:
> >  display: ABCD
> >  GPU: DCBA
> >  CPU: ABCD
> >  = CPU and display agree
> > 
> > BE CPU w/ CPU access byte swapping:
> >  display: DCBA
> >  GPU: DCBA
> >  CPU: DCBA
> >  = everyone agrees
> 
> Beware that for this list, you're using a format definition

Actually I'm not using any format definitions here.

> which is
> based on a packed 32-bit value. This does *not* match the current
> DRM_FORMAT_* definitions. E.g. in the last case, display and GPU use
> the same DRM_FORMAT, but the CPU uses the "inverse" one.

I wasn't concerned about the specific drm format, just what kind
of a 32bpp value everyone will see given the same memory contents.

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


Re: [PATCH 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format

2017-04-25 Thread Ville Syrjälä
On Tue, Apr 25, 2017 at 12:18:52PM +0900, Michel Dänzer wrote:
> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
> > Return correct fourcc codes on bigendian.  Drivers must be adapted to
> > this change.
> > 
> > Signed-off-by: Gerd Hoffmann 
> 
> Just to reiterate, this won't work for the radeon driver, which programs
> the GPU to use (effectively, per the current definition that these are
> little endian GPU formats) DRM_FORMAT_XRGB with pre-R600 and
> DRM_FORMAT_BGRX with >= R600.
> 
> 
> > +#ifdef __BIG_ENDIAN
> > +   switch (bpp) {
> > +   case 8:
> > +   fmt = DRM_FORMAT_C8;
> > +   break;
> > +   case 24:
> > +   fmt = DRM_FORMAT_BGR888;
> > +   break;
> 
> BTW, endianness as a concept cannot apply to 8 or 24 bpp formats.

To 8bpp no, but it can easily apply to 24bpp. Same was as it applies to
16bpp. Neither matches the word size of the CPU or anything like that
but still the bytes have to stored in memory in some order.

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


Re: [PATCH 0/6] *** Dedicated vmid per process v2 ***

2017-04-25 Thread Christian König
On my TODO list, but behind about two or three other items I need to 
tackle first.


Christian.

Am 25.04.2017 um 11:07 schrieb zhoucm1:

ping... anyone can give the review?

Thanks,
David Zhou

On 2017年04月24日 13:57, Chunming Zhou wrote:
The current kernel implementation, which grabs the idle VMID from 
pool when emitting the job may:


 The back-to-back submission from one process could use different 
VMID.
 The submission to different queues from single process could use 
different VMID


It works well in most case but cannot work for the SQ thread trace 
capture.


The VMID for the submission that set the {SQTT}_BASE, which refers to 
the address of the trace buffer, is stored in shader engine.


If the profiling application have to use different VMIDs to submit 
IBs in its life cycle:


 Some trace is not captured since it actually uses different VMID 
to submit jobs.
 Some part of captured trace may come from different application 
since they are accidentally uses the owner’s VMID to submit jobs.


V2:
1. address Christian's comments:
a. drop context flags for tag process, instead, add vm ioctl.
b. change order of patches.
c. sync waiting only when vm flush needs.

2. address Alex's comments;
bump module version

Chunming Zhou (6):
   drm/amdgpu: add vm ioctl
   drm/amdgpu: add dedicated vmid field in vm struct
   drm/amdgpu: reserve vmid by vm ioctl
   drm/amdgpu: add limitation for dedicated vm number v2
   drm/amdgpu: implement grab dedicated vmid V2
   drm/amdgpu: bump module verion for reserved vmid

  drivers/gpu/drm/amd/amdgpu/amdgpu.h|   1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   3 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|   1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 159 
-

  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   5 +
  include/uapi/drm/amdgpu_drm.h  |  20 
  7 files changed, 188 insertions(+), 2 deletions(-)



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

2017-04-25 Thread Ville Syrjälä
On Tue, Apr 25, 2017 at 10:12:37AM +0900, Michel Dänzer wrote:
> On 24/04/17 10:03 PM, Ville Syrjälä wrote:
> > On Mon, Apr 24, 2017 at 03:57:02PM +0900, Michel Dänzer wrote:
> >> On 22/04/17 07:05 PM, Ville Syrjälä wrote:
> >>> On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote:
>    Hi,
> 
> >> My personal opinion is that formats in drm_fourcc.h should be 
> >> independent of the CPU byte order and the function 
> >> drm_mode_legacy_fb_format() and drivers depending on that incorrect 
> >> assumption be fixed instead.
> >
> > The problem is this isn't a kernel-internal thing any more.  With the
> > addition of the ADDFB2 ioctl the fourcc codes became part of the
> > kernel/userspace abi ...
> 
>  Ok, added some printk's to the ADDFB and ADDFB2 code paths and tested a
>  bit.  Apparently pretty much all userspace still uses the ADDFB ioctl.
>  xorg (modesetting driver) does.  gnome-shell in wayland mode does.
>  Seems the big transition to ADDFB2 didn't happen yet.
> 
>  I guess that makes changing drm_mode_legacy_fb_format + drivers a
>  reasonable option ...
> >>>
> >>> Yeah, I came to the same conclusion after chatting with some
> >>> folks on irc.
> >>>
> >>> So my current idea is that we change any driver that wants to follow the
> >>> CPU endianness
> >>
> >> This isn't really optional for various reasons, some of which have been
> >> covered in this discussion.
> >>
> >>
> >>> to declare support for big endian formats if the CPU is
> >>> big endian. Presumably these are mostly the virtual GPU drivers.
> >>>
> >>> Additonally we'll make the mapping performed by 
> >>> drm_mode_legacy_fb_format()
> >>> driver controlled. That way drivers that got changed to follow CPU
> >>> endianness can return a framebuffer that matches CPU endianness. And
> >>> drivers that expect the GPU endianness to not depend on the CPU
> >>> endianness will keep working as they do now. The downside is that users
> >>> of the legacy addfb ioctl will need to magically know which endianness
> >>> they will get, but that is apparently already the case. And users of
> >>> addfb2 will keep on specifying the endianness explicitly with
> >>> DRM_FORMAT_BIG_ENDIAN vs. 0.
> >>
> >> I'm afraid it's not that simple.
> >>
> >> The display hardware of older (pre-R600 generation) Radeon GPUs does not
> >> support the "big endian" formats directly. In order to allow userspace
> >> to access pixel data in native endianness with the CPU, we instead use
> >> byte-swapping functionality which only affects CPU access.
> > 
> > OK, I'm getting confused. Based on our irc discussion I got the
> > impression you don't byte swap CPU accesses.
> 
> Sorry for the confusion. The radeon kernel driver does support
> byte-swapping for CPU access to VRAM with pre-R600 GPUs, and this is
> used for fbdev emulation. What I meant on IRC is that the xf86-video-ati
> radeon driver doesn't make use of this, mostly because it only applies
> while a BO is in VRAM, and userspace can't control when that's the case
> (while a BO isn't being scanned out).

So that was my other question. So if someone just creates a bo, I presume
ttm can more or less move it between system memory and vram at any
time. So if we then mmap the bo, does it mean the CPU will see the bytes
in different order depending on where the bo happens to live at
the time the CPU access happens?

And how would that work wih dumb bos? Would they be forced to live in vram?
I see it's passing VRAM as the initial domain, but I can't quickly see
whether that would mean it can't even be moved out.

> 
> 
> > But since you do, how do you deal with mixing 8bpp vs. 16bpp vs. 32bpp?
> 
> The byte-swapping is configured per-BO via the
> RADEON_TILING_SWAP_16/32BIT flags.

Which translates into usage of the surface regs it seems. So I wasn't
totally crazy to think that such things existed :)

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


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

2017-04-25 Thread Christian König

Am 12.04.2017 um 18:55 schrieb Bjorn Helgaas:

[SNIP]

I think the specs would envision this being done via an ACPI _SRS
method on the PNP0A03 host bridge device.  That would be a more
generic path that would work on any host bridge.  Did you explore that
possibility?  I would prefer to avoid adding device-specific code if
that's possible.

I've checked quite a few boards, but none of them actually
implements it this way.

M$ is working on a new ACPI table to enable this vendor neutral, but
I guess that will still take a while.

I want to support this for all AMD CPU released in the past 5 years
or so, so we are going to deal with a bunch of older boards as well.

I've never seen _SRS for host bridges either.  I'm curious about what
sort of new table will be proposed.  It seems like the existing ACPI
resource framework could manage it, but I certainly don't know all the
issues.


No idea either since I'm not involved into that. My job is to get it 
working on the existing hw generations and that alone is enough work :)


My best guess is that MS is going to either make _SRS on the host bridge 
or a pre-configured 64bit window mandatory for the BIOS.



+   pci_bus_add_resource(dev->bus, res, 0);

We would need some sort of printk here to explain how this new window
magically appeared.

Good point, consider this done.

But is this actually the right place of doing it? Or would you
prefer something to be added to the probing code?

I think those fixups are applied a bit later, aren't they?

Logically, this should be done before we enumerate the PCI devices
below the host bridge, so a PCI device fixup is not the ideal place
for it, but it might be the most practical.


Since the modification must be done on a device connected to the root 
bus I run into quite a chicken and egg problem if I try to do it before 
the enumeration.



I could imagine some sort of quirk like the ones in
drivers/pnp/quirks.c that could add the window to the host bridge _CRS
and program the bridge to open it.  But the PCI host bridges aren't
handled through the path that applies those fixups, and it would be
messy to identify your bridges (you currently use PCI vendor/device
IDs, which are only available after enumerating the device).  So this
doesn't seem like a viable strategy.


I've tried that, but gave up rather quickly. Looks like the current 
approach indeed work find even with "pci=realloc", so I'm going to stick 
with that.


Regards,
Christian.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH 1/2] drm/amdgpu: fix gpu reset crash

2017-04-25 Thread Deucher, Alexander
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of zhoucm1
> Sent: Monday, April 24, 2017 10:20 PM
> To: Christian König; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 1/2] drm/amdgpu: fix gpu reset crash
> 
> 
> 
> On 2017年04月24日 17:47, Christian König wrote:
> >> The root cause is some ring doesn't have scheduler, like KIQ ring
> >>
> >> Change-Id: I420e84add9cdd9a7fd1f9921b8a5d0afa3dd2058
> >> Signed-off-by: Chunming Zhou 
> >
> > Reviewed-by: Christian König  for both.
> I forgot to add RB when pushing patches, How can I add it again?

I'll add it before sending upstream.

Alex

> 
> Sorry for that.
> David Zhou
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: amdgpu 0000:84:00.0: gpu post error! \\ Fatal error during GPU init

2017-04-25 Thread Deucher, Alexander
> -Original Message-
> From: Dennis Schridde [mailto:dennis.schri...@uni-heidelberg.de]
> Sent: Tuesday, April 25, 2017 6:31 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: amdgpu :84:00.0: gpu post error! \\ Fatal error during GPU
> init
> 
> On Dienstag, 25. April 2017 10:51:09 CEST Dennis Schridde wrote:
> > I replaced the AMD FirePro S7150X2 card with a AMD Radeon R5 230 (the
> only
> > other AMD card we had available), to see whether the problem was caused
> by
> > another hardware component of the system.
> >
> > The kernel boots fine with this card. I see no errors in the log (attached).
> 
> The kernel used until now as a 4.10.9.
> 
> I tried again using 4.11.0_rc7, which shows the same behaviour.

Does the card work in a different system?

Alex

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx