Re: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4

2020-05-14 Thread Christian König 

The first application to open the autodump node gets the right to use it.

All others only get -EBUSY until the first application is done with the 
hardware.


Christian.

Am 15.05.20 um 04:40 schrieb Zhao, Jiange:


[AMD Official Use Only - Internal Distribution Only]


Hi Dennis,

This node/feature is for UMR extension. It is designed for a single user.

Jiange

*From:* Li, Dennis 
*Sent:* Thursday, May 14, 2020 11:15 PM
*To:* Koenig, Christian ; Zhao, Jiange 
; amd-gfx@lists.freedesktop.org 

*Cc:* Deucher, Alexander ; Pelloux-prayer, 
Pierre-eric ; Kuehling, Felix 
; Liu, Monk ; Zhang, Hawking 

*Subject:* RE: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu 
reset v4


[AMD Official Use Only - Internal Distribution Only]

Hi, Jiange,

How to handle the case that multi-apps do the auto dump? This patch 
seems not multi-process safety.


Best Regards

Dennis Li

*From:*amd-gfx  *On Behalf Of 
*Christian König

*Sent:* Thursday, May 14, 2020 4:29 PM
*To:* Zhao, Jiange ; amd-gfx@lists.freedesktop.org
*Cc:* Deucher, Alexander ; Pelloux-prayer, 
Pierre-eric ; Kuehling, Felix 
; Liu, Monk ; Zhang, Hawking 

*Subject:* Re: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu 
reset v4


Hi Jiange,

it probably won't hurt, but I would just drop that. You need roughly 4 
billion GPU resets until the UINT_MAX-1 becomes zero again.


Christian.

Am 14.05.20 um 09:14 schrieb Zhao, Jiange:

[AMD Official Use Only - Internal Distribution Only]

Hi Christian,

wait_for_completion_interruptible_timeout() would decrease
autodump.dumping.done to UINT_MAX-1.

complete_all() here would restore autodump.dumping to the state as
in amdgpu_debugfs_autodump_init().

I want to make sure every open() deals with the same situation.

Jiange



*From:* Christian König 

*Sent:* Thursday, May 14, 2020 3:01 PM
*To:* Zhao, Jiange 
; amd-gfx@lists.freedesktop.org

 
*Cc:* Pelloux-prayer, Pierre-eric

; Zhao, Jiange
 ; Kuehling,
Felix  ;
Deucher, Alexander 
; Koenig, Christian
 ; Liu,
Monk  ; Zhang, Hawking
 
*Subject:* Re: [PATCH] drm/amdgpu: Add autodump debugfs node for
gpu reset v4

Am 14.05.20 um 07:29 schrieb jia...@amd.com :
> From: Jiange Zhao  
>
> When GPU got timeout, it would notify an interested part
> of an opportunity to dump info before actual GPU reset.
>
> A usermode app would open 'autodump' node under debugfs system
> and poll() for readable/writable. When a GPU reset is due,
> amdgpu would notify usermode app through wait_queue_head and give
> it 10 minutes to dump info.
>
> After usermode app has done its work, this 'autodump' node is
closed.
> On node closure, amdgpu gets to know the dump is done through
> the completion that is triggered in release().
>
> There is no write or read callback because necessary info can be
> obtained through dmesg and umr. Messages back and forth between
> usermode app and amdgpu are unnecessary.
>
> v2: (1) changed 'registered' to 'app_listening'
>  (2) add a mutex in open() to prevent race condition
>
> v3 (chk): grab the reset lock to avoid race in autodump_open,
>    rename debugfs file to amdgpu_autodump,
>    provide autodump_read as well,
>    style and code cleanups
>
> v4: add 'bool app_listening' to differentiate situations, so that
>  the node can be reopened; also, there is no need to wait for
>  completion when no app is waiting for a dump.
>
> v5: change 'bool app_listening' to 'enum amdgpu_autodump_state'
>  add 'app_state_mutex' for race conditions:
>    (1)Only 1 user can open this file node
>    (2)wait_dump() can only take effect after poll() executed.
>    (3)eliminated the race condition between release() and
>   wait_dump()
>
> v6: removed 'enum amdgpu_autodump_state' and 'app_state_mutex'
>  removed state checking in amdgpu_debugfs_wait_dump
>  Improve on top of version 3 so that the node can be reopened.
>
> v7: move reinit_completion into open() so that only one user
>  can open it.
>
> Signed-off-by: Jiange Zhao 

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 +
>   drivers/gpu/drm/amd/

[PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

2020-05-14 Thread Mario Kleiner 
Testing on a Polaris11 gpu with DCE-11.2 suggests that it
seems to work fine there, so optimistically enable it for
DCE-11 and later.

Signed-off-by: Mario Kleiner 
---
 drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 2 +-
 drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2 +-
 drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
index 9597fc79d7fa..a043ddae5149 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
@@ -410,7 +410,7 @@ static const struct dc_plane_cap plane_cap = {
.pixel_format_support = {
.argb = true,
.nv12 = false,
-   .fp16 = false
+   .fp16 = true
},
 
.max_upscale_factor = {
diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
index 4a7796de2ff5..51b3fe502670 100644
--- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
@@ -411,7 +411,7 @@ static const struct dc_plane_cap plane_cap = {
.pixel_format_support = {
.argb = true,
.nv12 = false,
-   .fp16 = false
+   .fp16 = true
},
 
.max_upscale_factor = {
diff --git a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
index 9a9764cbd78d..8f362e8c1787 100644
--- a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
@@ -516,7 +516,7 @@ static const struct dc_plane_cap plane_cap = {
.pixel_format_support = {
.argb = true,
.nv12 = false,
-   .fp16 = false
+   .fp16 = true
},
 
.max_upscale_factor = {
-- 
2.20.1

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

[PATCH 1/2] drm/amd/display: Expose support for xBGR ordered fp16 formats.

2020-05-14 Thread Mario Kleiner 
Expose support for DRM_FORMAT_ABGR16161616F and
DRM_FORMAT_XBGR16161616F to the DRM core, complementing
the already existing xRGB ordered fp16 formats.

These are especially useful for creating presentable
swapchains in Vulkan for VK_FORMAT_R16G16B16A16_SFLOAT.

Signed-off-by: Mario Kleiner 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++
 1 file changed, 6 insertions(+)

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 48f2b3710e7c..bd0c9eda8f93 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3651,6 +3651,10 @@ fill_dc_plane_info_and_addr(struct amdgpu_device *adev,
case DRM_FORMAT_ARGB16161616F:
plane_info->format = SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616F;
break;
+   case DRM_FORMAT_XBGR16161616F:
+   case DRM_FORMAT_ABGR16161616F:
+   plane_info->format = SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616F;
+   break;
default:
DRM_ERROR(
"Unsupported screen format %s\n",
@@ -5566,6 +5570,8 @@ static int get_plane_formats(const struct drm_plane 
*plane,
if (plane_cap && plane_cap->pixel_format_support.fp16) {
formats[num_formats++] = DRM_FORMAT_XRGB16161616F;
formats[num_formats++] = DRM_FORMAT_ARGB16161616F;
+   formats[num_formats++] = DRM_FORMAT_XBGR16161616F;
+   formats[num_formats++] = DRM_FORMAT_ABGR16161616F;
}
break;
 
-- 
2.20.1

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

fp16 support in xBGR order, and for DCE-11+

2020-05-14 Thread Mario Kleiner 
Hi,

two patches. The first one adds the xBGR ordered variants of fp16
in addition to the xRGB ordered variants that were merged just
very recently.

These variants are required for direct scanout of OpenGL and Vulkan
rendered content, as both OpenGL (GL_RGBA16F) and Vulkan
(VK_FORMAT_R16G16B16A16_SFLOAT) expect RGBA channel order for fp16,
instead of the previously exposed BGRA fp16 ordering.

I have a proof of concept patch against the amdvlk Vulkan driver
that allows fp16 rendering and presentation with this format, but
not with the xRGB format. Nicholas already has the test patch in
his inbox. Results look visually correct, also when used on a HDR
monitor.

I also tested with Patch 2/2 on top on a Polaris11 gpu with DCE-11.2
display engine, and also got correct results, so maybe it makes sense
to enable fp16 scanout support also for DCE and not only DCN?
Patch 2/2 does not enable fp16 on DCE 10 or DCE 8, because i don't
have hardware to test it. But it would be nice to expose fp16 on all
supported display engines.

Thanks,
-mario


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

Re: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4

2020-05-14 Thread Zhao, Jiange 
[AMD Official Use Only - Internal Distribution Only]

Hi Dennis,

This node/feature is for UMR extension. It is designed for a single user.

Jiange

From: Li, Dennis 
Sent: Thursday, May 14, 2020 11:15 PM
To: Koenig, Christian ; Zhao, Jiange 
; amd-gfx@lists.freedesktop.org 

Cc: Deucher, Alexander ; Pelloux-prayer, Pierre-eric 
; Kuehling, Felix ; 
Liu, Monk ; Zhang, Hawking 
Subject: RE: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4


[AMD Official Use Only - Internal Distribution Only]



Hi, Jiange,

  How to handle the case that multi-apps do the auto dump? This patch seems 
not multi-process safety.



Best Regards

Dennis Li

From: amd-gfx  On Behalf Of Christian 
König
Sent: Thursday, May 14, 2020 4:29 PM
To: Zhao, Jiange ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Pelloux-prayer, Pierre-eric 
; Kuehling, Felix ; 
Liu, Monk ; Zhang, Hawking 
Subject: Re: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4



Hi Jiange,

it probably won't hurt, but I would just drop that. You need roughly 4 billion 
GPU resets until the UINT_MAX-1 becomes zero again.

Christian.

Am 14.05.20 um 09:14 schrieb Zhao, Jiange:

[AMD Official Use Only - Internal Distribution Only]



Hi Christian,



wait_for_completion_interruptible_timeout() would decrease 
autodump.dumping.done to UINT_MAX-1.



complete_all() here would restore autodump.dumping to the state as in 
amdgpu_debugfs_autodump_init().



I want to make sure every open() deals with the same situation.



Jiange



From: Christian König 

Sent: Thursday, May 14, 2020 3:01 PM
To: Zhao, Jiange ; 
amd-gfx@lists.freedesktop.org 

Cc: Pelloux-prayer, Pierre-eric 
;
 Zhao, Jiange ; Kuehling, 
Felix ; Deucher, 
Alexander ; 
Koenig, Christian ; 
Liu, Monk ; Zhang, Hawking 

Subject: Re: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4



Am 14.05.20 um 07:29 schrieb jia...@amd.com:
> From: Jiange Zhao 
>
> When GPU got timeout, it would notify an interested part
> of an opportunity to dump info before actual GPU reset.
>
> A usermode app would open 'autodump' node under debugfs system
> and poll() for readable/writable. When a GPU reset is due,
> amdgpu would notify usermode app through wait_queue_head and give
> it 10 minutes to dump info.
>
> After usermode app has done its work, this 'autodump' node is closed.
> On node closure, amdgpu gets to know the dump is done through
> the completion that is triggered in release().
>
> There is no write or read callback because necessary info can be
> obtained through dmesg and umr. Messages back and forth between
> usermode app and amdgpu are unnecessary.
>
> v2: (1) changed 'registered' to 'app_listening'
>  (2) add a mutex in open() to prevent race condition
>
> v3 (chk): grab the reset lock to avoid race in autodump_open,
>rename debugfs file to amdgpu_autodump,
>provide autodump_read as well,
>style and code cleanups
>
> v4: add 'bool app_listening' to differentiate situations, so that
>  the node can be reopened; also, there is no need to wait for
>  completion when no app is waiting for a dump.
>
> v5: change 'bool app_listening' to 'enum amdgpu_autodump_state'
>  add 'app_state_mutex' for race conditions:
>(1)Only 1 user can open this file node
>(2)wait_dump() can only take effect after poll() executed.
>(3)eliminated the race condition between release() and
>   wait_dump()
>
> v6: removed 'enum amdgpu_autodump_state' and 'app_state_mutex'
>  removed state checking in amdgpu_debugfs_wait_dump
>  Improve on top of version 3 so that the node can be reopened.
>
> v7: move reinit_completion into open() so that only one user
>  can open it.
>
> Signed-off-by: Jiange Zhao 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 +
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 79 -
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |  6 ++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  2 +
>   4 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 2a806cb55b78..9e8eeddfe7ce 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -992,6 +992,8 @@ struct amdgpu_device {
>charproduct_number[16];
>charproduct_name[32];
>char

[PATCH] drm/amdkfd: Track SDMA utilization per process

2020-05-14 Thread Mukul Joshi 
Track SDMA usage on a per process basis and report it through sysfs.
The value in the sysfs file indicates the amount of time SDMA has
been in-use by this process since the creation of the process.
This value is in microsecond granularity.

Signed-off-by: Mukul Joshi 
---
 .../drm/amd/amdkfd/kfd_device_queue_manager.c |  57 
 .../drm/amd/amdkfd/kfd_device_queue_manager.h |   2 +
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  16 ++-
 drivers/gpu/drm/amd/amdkfd/kfd_process.c  | 130 --
 4 files changed, 193 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index e9c4867abeff..49f72d0f7be7 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -153,6 +153,52 @@ void decrement_queue_count(struct device_queue_manager 
*dqm,
dqm->active_cp_queue_count--;
 }
 
+int read_sdma_queue_counter(struct queue *q, uint64_t *val)
+{
+   int ret;
+   uint64_t tmp = 0;
+
+   if (!q || !val)
+   return -EINVAL;
+   /*
+* SDMA activity counter is stored at queue's RPTR + 0x8 location.
+*/
+   if (!access_ok((const void __user *)((uint64_t)q->properties.read_ptr +
+   sizeof(uint64_t)), sizeof(uint64_t))) {
+   pr_err("Can't access sdma queue activity counter\n");
+   return -EFAULT;
+   }
+
+   ret = get_user(tmp, (uint64_t *)((uint64_t)(q->properties.read_ptr) +
+   sizeof(uint64_t)));
+   if (!ret) {
+   *val = tmp;
+   }
+
+   return ret;
+}
+
+static int update_sdma_queue_past_activity_stats(struct kfd_process_device 
*pdd,
+struct queue *q)
+{
+   int ret;
+   uint64_t val = 0;
+
+   if (!pdd)
+   return -ENODEV;
+
+   ret = read_sdma_queue_counter(q, &val);
+   if (ret) {
+   pr_err("Failed to read SDMA queue counter for queue: %d\n",
+   q->properties.queue_id);
+   return ret;
+   }
+
+   WRITE_ONCE(pdd->sdma_past_activity_counter, 
pdd->sdma_past_activity_counter + val);
+
+   return ret;
+}
+
 static int allocate_doorbell(struct qcm_process_device *qpd, struct queue *q)
 {
struct kfd_dev *dev = qpd->dqm->dev;
@@ -487,6 +533,12 @@ static int destroy_queue_nocpsch_locked(struct 
device_queue_manager *dqm,
if (retval == -ETIME)
qpd->reset_wavefronts = true;
 
+   /* Get the SDMA queue stats */
+if ((q->properties.type == KFD_QUEUE_TYPE_SDMA) ||
+(q->properties.type == KFD_QUEUE_TYPE_SDMA_XGMI)) {
+update_sdma_queue_past_activity_stats(qpd_to_pdd(qpd), q);
+}
+
mqd_mgr->free_mqd(mqd_mgr, q->mqd, q->mqd_mem_obj);
 
list_del(&q->list);
@@ -1468,6 +1520,11 @@ static int destroy_queue_cpsch(struct 
device_queue_manager *dqm,
}
}
 
+   /* Get the SDMA queue stats */
+   if ((q->properties.type == KFD_QUEUE_TYPE_SDMA) ||
+   (q->properties.type == KFD_QUEUE_TYPE_SDMA_XGMI)) {
+   update_sdma_queue_past_activity_stats(qpd_to_pdd(qpd), q);
+   }
/*
 * Unconditionally decrement this counter, regardless of the queue's
 * type
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
index 4afa015c69b1..894bcf877f9e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
@@ -251,4 +251,6 @@ static inline void dqm_unlock(struct device_queue_manager 
*dqm)
mutex_unlock(&dqm->lock_hidden);
 }
 
+int read_sdma_queue_counter(struct queue *q, uint64_t *val);
+
 #endif /* KFD_DEVICE_QUEUE_MANAGER_H_ */
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index f70f789c3cb3..fae139b77c0a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -633,7 +633,14 @@ enum kfd_pdd_bound {
PDD_BOUND_SUSPENDED,
 };
 
-#define MAX_VRAM_FILENAME_LEN 11
+#define MAX_SYSFS_FILENAME_LEN 11
+
+/*
+ * SDMA counter runs at 100MHz frequency.
+ * We display SDMA activity in microsecond granularity in sysfs.
+ * As a result, the divisor is 100.
+ */
+#define SDMA_ACTIVITY_DIVISOR  100
 
 /* Data that is per-process-per device. */
 struct kfd_process_device {
@@ -681,7 +688,12 @@ struct kfd_process_device {
/* VRAM usage */
uint64_t vram_usage;
struct attribute attr_vram;
-   char vram_filename[MAX_VRAM_FILENAME_LEN];
+   char vram_filename[MAX_SYSFS_FILENAME_LEN];
+
+   /* SDMA activity tracking */
+   uint64_t sdma_past_activity_counter;
+   struct attribute attr_sd

[PATCH AUTOSEL 5.4 37/49] drm/amd/display: Prevent dpcd reads with passive dongles

2020-05-14 Thread Sasha Levin 
From: Aurabindo Pillai 

[ Upstream commit e6142dd511425cb827b5db869f489eb81f5f994d ]

[why]
During hotplug, a DP port may be connected to the sink through
passive adapter which does not support DPCD reads. Issuing reads
without checking for this condition will result in errors

[how]
Ensure the link is in aux_mode before initiating operation that result
in a DPCD read.

Signed-off-by: Aurabindo Pillai 
Reviewed-by: Harry Wentland 
Acked-by: Aurabindo Pillai 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c   | 17 +++--
 1 file changed, 11 insertions(+), 6 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 be61ae1430ed9..c9c2984138263 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1422,17 +1422,22 @@ amdgpu_dm_update_connector_after_detect(struct 
amdgpu_dm_connector *aconnector)
dc_sink_retain(aconnector->dc_sink);
if (sink->dc_edid.length == 0) {
aconnector->edid = NULL;
-   drm_dp_cec_unset_edid(&aconnector->dm_dp_aux.aux);
+   if (aconnector->dc_link->aux_mode) {
+   drm_dp_cec_unset_edid(
+   &aconnector->dm_dp_aux.aux);
+   }
} else {
aconnector->edid =
-   (struct edid *) sink->dc_edid.raw_edid;
-
+   (struct edid *)sink->dc_edid.raw_edid;
 
drm_connector_update_edid_property(connector,
-   aconnector->edid);
-   drm_dp_cec_set_edid(&aconnector->dm_dp_aux.aux,
-   aconnector->edid);
+  aconnector->edid);
+
+   if (aconnector->dc_link->aux_mode)
+   drm_dp_cec_set_edid(&aconnector->dm_dp_aux.aux,
+   aconnector->edid);
}
+
amdgpu_dm_update_freesync_caps(connector, aconnector->edid);
 
} else {
-- 
2.20.1

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

[PATCH AUTOSEL 5.6 44/62] drm/amd/display: Update DCN2.1 DV Code Revision

2020-05-14 Thread Sasha Levin 
From: Sung Lee 

[ Upstream commit b95e51eb9f2ee7b6d6c3203a2f75122349aa77be ]

[WHY & HOW]
There is a problem in hscale_pixel_rate, the bug
causes DCN to be more optimistic (more likely to underflow)
in upscale cases during prefetch.
This commit ports the fix from DV code to address these issues.

Signed-off-by: Sung Lee 
Reviewed-by: Dmytro Laktyushkin 
Acked-by: Aurabindo Pillai 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 .../drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c
index a38baa73d4841..b8ec08e3b7a36 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c
@@ -1200,7 +1200,7 @@ static void dml_rq_dlg_get_dlg_params(
min_hratio_fact_l = 1.0;
min_hratio_fact_c = 1.0;
 
-   if (htaps_l <= 1)
+   if (hratio_l <= 1)
min_hratio_fact_l = 2.0;
else if (htaps_l <= 6) {
if ((hratio_l * 2.0) > 4.0)
@@ -1216,7 +1216,7 @@ static void dml_rq_dlg_get_dlg_params(
 
hscale_pixel_rate_l = min_hratio_fact_l * dppclk_freq_in_mhz;
 
-   if (htaps_c <= 1)
+   if (hratio_c <= 1)
min_hratio_fact_c = 2.0;
else if (htaps_c <= 6) {
if ((hratio_c * 2.0) > 4.0)
@@ -1522,8 +1522,8 @@ static void dml_rq_dlg_get_dlg_params(
 
disp_dlg_regs->refcyc_per_vm_group_vblank   = 
get_refcyc_per_vm_group_vblank(mode_lib, e2e_pipe_param, num_pipes, pipe_idx) * 
refclk_freq_in_mhz;
disp_dlg_regs->refcyc_per_vm_group_flip = 
get_refcyc_per_vm_group_flip(mode_lib, e2e_pipe_param, num_pipes, pipe_idx) * 
refclk_freq_in_mhz;
-   disp_dlg_regs->refcyc_per_vm_req_vblank = 
get_refcyc_per_vm_req_vblank(mode_lib, e2e_pipe_param, num_pipes, pipe_idx) * 
refclk_freq_in_mhz;
-   disp_dlg_regs->refcyc_per_vm_req_flip   = 
get_refcyc_per_vm_req_flip(mode_lib, e2e_pipe_param, num_pipes, pipe_idx) * 
refclk_freq_in_mhz;
+   disp_dlg_regs->refcyc_per_vm_req_vblank = 
get_refcyc_per_vm_req_vblank(mode_lib, e2e_pipe_param, num_pipes, pipe_idx) * 
refclk_freq_in_mhz * dml_pow(2, 10);
+   disp_dlg_regs->refcyc_per_vm_req_flip   = 
get_refcyc_per_vm_req_flip(mode_lib, e2e_pipe_param, num_pipes, pipe_idx) * 
refclk_freq_in_mhz * dml_pow(2, 10);
 
// Clamp to max for now
if (disp_dlg_regs->refcyc_per_vm_group_vblank >= (unsigned 
int)dml_pow(2, 23))
-- 
2.20.1

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

[PATCH AUTOSEL 5.6 45/62] drm/amd/display: fix counter in wait_for_no_pipes_pending

2020-05-14 Thread Sasha Levin 
From: Roman Li 

[ Upstream commit 80797dd6f1a525d1160c463d6a9f9d29af182cbb ]

[Why]
Wait counter is not being reset for each pipe.

[How]
Move counter reset into pipe loop scope.

Signed-off-by: Roman Li 
Reviewed-by: Zhan Liu 
Acked-by: Aurabindo Pillai 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 5 ++---
 1 file changed, 2 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 188e51600070b..b3987124183a7 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -803,11 +803,10 @@ static void disable_dangling_plane(struct dc *dc, struct 
dc_state *context)
 static void wait_for_no_pipes_pending(struct dc *dc, struct dc_state *context)
 {
int i;
-   int count = 0;
-   struct pipe_ctx *pipe;
PERF_TRACE();
for (i = 0; i < MAX_PIPES; i++) {
-   pipe = &context->res_ctx.pipe_ctx[i];
+   int count = 0;
+   struct pipe_ctx *pipe = &context->res_ctx.pipe_ctx[i];
 
if (!pipe->plane_state)
continue;
-- 
2.20.1

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

[PATCH AUTOSEL 5.6 46/62] drm/amd/display: Prevent dpcd reads with passive dongles

2020-05-14 Thread Sasha Levin 
From: Aurabindo Pillai 

[ Upstream commit e6142dd511425cb827b5db869f489eb81f5f994d ]

[why]
During hotplug, a DP port may be connected to the sink through
passive adapter which does not support DPCD reads. Issuing reads
without checking for this condition will result in errors

[how]
Ensure the link is in aux_mode before initiating operation that result
in a DPCD read.

Signed-off-by: Aurabindo Pillai 
Reviewed-by: Harry Wentland 
Acked-by: Aurabindo Pillai 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c   | 17 +++--
 1 file changed, 11 insertions(+), 6 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 8136a58deb393..f98c42150b4f3 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1941,17 +1941,22 @@ amdgpu_dm_update_connector_after_detect(struct 
amdgpu_dm_connector *aconnector)
dc_sink_retain(aconnector->dc_sink);
if (sink->dc_edid.length == 0) {
aconnector->edid = NULL;
-   drm_dp_cec_unset_edid(&aconnector->dm_dp_aux.aux);
+   if (aconnector->dc_link->aux_mode) {
+   drm_dp_cec_unset_edid(
+   &aconnector->dm_dp_aux.aux);
+   }
} else {
aconnector->edid =
-   (struct edid *) sink->dc_edid.raw_edid;
-
+   (struct edid *)sink->dc_edid.raw_edid;
 
drm_connector_update_edid_property(connector,
-   aconnector->edid);
-   drm_dp_cec_set_edid(&aconnector->dm_dp_aux.aux,
-   aconnector->edid);
+  aconnector->edid);
+
+   if (aconnector->dc_link->aux_mode)
+   drm_dp_cec_set_edid(&aconnector->dm_dp_aux.aux,
+   aconnector->edid);
}
+
amdgpu_dm_update_freesync_caps(connector, aconnector->edid);
 
} else {
-- 
2.20.1

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

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

2020-05-14 Thread Alex Deucher 
On Thu, May 14, 2020 at 10:15 AM Daniel Stone  wrote:
>
> Hi,
>
> On Thu, 14 May 2020 at 14:36, Alex Deucher  wrote:
> > On Thu, May 14, 2020 at 5:42 AM Daniel Stone  wrote:
> > > Did this ever go through uAPI review? It's been pushed to the kernel
> > > before Mesa review was complete. Even then, Mesa only uses it when
> > > behind a magic environment variable, rather than through the EGL
> > > extensions which have been specifically designed for protected content
> > > (EGL_EXT_protected_content, protected_surface, etc). The winsys
> > > usecase was based on a Wayland system which seems like it will only
> > > work when composition bypass is available - not using any of the
> > > Wayland protected-content extensions, and it's completely unclear what
> > > will happen if composition bypass can't actually be achieved.
> > >
> > > I don't think this should be landing before all those open questions
> > > have been answered. We're trying to come up with a good and coherent
> > > story for handling protected content, and I'd rather not see AMD
> > > landing its own uAPI which might completely contradict that.
> >
> > Well, the patches have been public for months and we have a UAPI and
> > mesa userspace which works for our use cases and the mesa side has
> > been merged and the recent comments on the MR didn't seem like show
> > stoppers.
>
> As a generic compositor author, it's pretty important for me to
> understand what happens when trying to access protected content. Does
> the import simply fail? Does it sample rubbish? Does my context
> killed? etc.

Unless you are a GPU engine in secure mode, you'll just get garbage.
You specify what mode you want each engine to operate in when you
submit work to the GPU.

>
> > I don't disagree with your point, but I feel like agreeing
> > on a what we want to do for EGL protected content could drag out for
> > months or years.
>
> I don't really see what the problem is, but it would've been nice if
> it was at least attempted, rather than just parachuted in ... I know
> I'm going to end up getting bug reports about it for Wayland/Weston,
> and then all of a sudden it's become my problem that this was just
> dropped in as a vendor-specific feature in a vendor-specific island.

I'm not sure what you mean by parachuted in.  The patches for both the
kernel and mesa were send out to their respective review mediums a
number of times and there were actually a number of revisions as we
worked through issues that came up.  We were certainly not trying to
"sneak" this in.

I didn't realize anyone was actually seriously working on this at the
moment either until you brought it up.  What is the current status?
Does anyone else have anything similar in progress?

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

RE: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4

2020-05-14 Thread Li, Dennis 
[AMD Official Use Only - Internal Distribution Only]

Hi, Jiange,
  How to handle the case that multi-apps do the auto dump? This patch seems 
not multi-process safety.

Best Regards
Dennis Li
From: amd-gfx  On Behalf Of Christian 
König
Sent: Thursday, May 14, 2020 4:29 PM
To: Zhao, Jiange ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Pelloux-prayer, Pierre-eric 
; Kuehling, Felix ; 
Liu, Monk ; Zhang, Hawking 
Subject: Re: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4

Hi Jiange,

it probably won't hurt, but I would just drop that. You need roughly 4 billion 
GPU resets until the UINT_MAX-1 becomes zero again.

Christian.

Am 14.05.20 um 09:14 schrieb Zhao, Jiange:

[AMD Official Use Only - Internal Distribution Only]

Hi Christian,

wait_for_completion_interruptible_timeout() would decrease 
autodump.dumping.done to UINT_MAX-1.

complete_all() here would restore autodump.dumping to the state as in 
amdgpu_debugfs_autodump_init().

I want to make sure every open() deals with the same situation.

Jiange

From: Christian König 

Sent: Thursday, May 14, 2020 3:01 PM
To: Zhao, Jiange ; 
amd-gfx@lists.freedesktop.org 

Cc: Pelloux-prayer, Pierre-eric 
;
 Zhao, Jiange ; Kuehling, 
Felix ; Deucher, 
Alexander ; 
Koenig, Christian ; 
Liu, Monk ; Zhang, Hawking 

Subject: Re: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4

Am 14.05.20 um 07:29 schrieb jia...@amd.com:
> From: Jiange Zhao 
>
> When GPU got timeout, it would notify an interested part
> of an opportunity to dump info before actual GPU reset.
>
> A usermode app would open 'autodump' node under debugfs system
> and poll() for readable/writable. When a GPU reset is due,
> amdgpu would notify usermode app through wait_queue_head and give
> it 10 minutes to dump info.
>
> After usermode app has done its work, this 'autodump' node is closed.
> On node closure, amdgpu gets to know the dump is done through
> the completion that is triggered in release().
>
> There is no write or read callback because necessary info can be
> obtained through dmesg and umr. Messages back and forth between
> usermode app and amdgpu are unnecessary.
>
> v2: (1) changed 'registered' to 'app_listening'
>  (2) add a mutex in open() to prevent race condition
>
> v3 (chk): grab the reset lock to avoid race in autodump_open,
>rename debugfs file to amdgpu_autodump,
>provide autodump_read as well,
>style and code cleanups
>
> v4: add 'bool app_listening' to differentiate situations, so that
>  the node can be reopened; also, there is no need to wait for
>  completion when no app is waiting for a dump.
>
> v5: change 'bool app_listening' to 'enum amdgpu_autodump_state'
>  add 'app_state_mutex' for race conditions:
>(1)Only 1 user can open this file node
>(2)wait_dump() can only take effect after poll() executed.
>(3)eliminated the race condition between release() and
>   wait_dump()
>
> v6: removed 'enum amdgpu_autodump_state' and 'app_state_mutex'
>  removed state checking in amdgpu_debugfs_wait_dump
>  Improve on top of version 3 so that the node can be reopened.
>
> v7: move reinit_completion into open() so that only one user
>  can open it.
>
> Signed-off-by: Jiange Zhao 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 +
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 79 -
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |  6 ++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  2 +
>   4 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 2a806cb55b78..9e8eeddfe7ce 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -992,6 +992,8 @@ struct amdgpu_device {
>charproduct_number[16];
>charproduct_name[32];
>charserial[16];
> +
> + struct amdgpu_autodump  autodump;
>   };
>
>   static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device 
> *bdev)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index 1a4894fa3693..efee3f1adecf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -27,7 +27,7 @@
>   #include 
>   #include 
>   #include 
> -
> +#includ

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

2020-05-14 Thread Daniel Stone 
Hi,

On Thu, 14 May 2020 at 14:36, Alex Deucher  wrote:
> On Thu, May 14, 2020 at 5:42 AM Daniel Stone  wrote:
> > Did this ever go through uAPI review? It's been pushed to the kernel
> > before Mesa review was complete. Even then, Mesa only uses it when
> > behind a magic environment variable, rather than through the EGL
> > extensions which have been specifically designed for protected content
> > (EGL_EXT_protected_content, protected_surface, etc). The winsys
> > usecase was based on a Wayland system which seems like it will only
> > work when composition bypass is available - not using any of the
> > Wayland protected-content extensions, and it's completely unclear what
> > will happen if composition bypass can't actually be achieved.
> >
> > I don't think this should be landing before all those open questions
> > have been answered. We're trying to come up with a good and coherent
> > story for handling protected content, and I'd rather not see AMD
> > landing its own uAPI which might completely contradict that.
>
> Well, the patches have been public for months and we have a UAPI and
> mesa userspace which works for our use cases and the mesa side has
> been merged and the recent comments on the MR didn't seem like show
> stoppers.

As a generic compositor author, it's pretty important for me to
understand what happens when trying to access protected content. Does
the import simply fail? Does it sample rubbish? Does my context
killed? etc.

> I don't disagree with your point, but I feel like agreeing
> on a what we want to do for EGL protected content could drag out for
> months or years.

I don't really see what the problem is, but it would've been nice if
it was at least attempted, rather than just parachuted in ... I know
I'm going to end up getting bug reports about it for Wayland/Weston,
and then all of a sudden it's become my problem that this was just
dropped in as a vendor-specific feature in a vendor-specific island.

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

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

2020-05-14 Thread Alex Deucher 
On Thu, May 14, 2020 at 5:42 AM Daniel Stone  wrote:
>
> Hi Alex,
>
> On Thu, 30 Apr 2020 at 22:30, Alex Deucher  wrote:
> > UAPI:
> > - Add amdgpu UAPI for encrypted GPU memory
> >   Used by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4401
>
> Did this ever go through uAPI review? It's been pushed to the kernel
> before Mesa review was complete. Even then, Mesa only uses it when
> behind a magic environment variable, rather than through the EGL
> extensions which have been specifically designed for protected content
> (EGL_EXT_protected_content, protected_surface, etc). The winsys
> usecase was based on a Wayland system which seems like it will only
> work when composition bypass is available - not using any of the
> Wayland protected-content extensions, and it's completely unclear what
> will happen if composition bypass can't actually be achieved.
>
> I don't think this should be landing before all those open questions
> have been answered. We're trying to come up with a good and coherent
> story for handling protected content, and I'd rather not see AMD
> landing its own uAPI which might completely contradict that.

Well, the patches have been public for months and we have a UAPI and
mesa userspace which works for our use cases and the mesa side has
been merged and the recent comments on the MR didn't seem like show
stoppers.  I don't disagree with your point, but I feel like agreeing
on a what we want to do for EGL protected content could drag out for
months or years.  Our UAPI is pretty straight forward and pretty much
matches how our hw works and what we already do for other GPUVM
mapping attributes like read/write/execute.  I don't see the current
UAPI being a blocker for any future protected content work, but of
course we can't be sure until it actually happens.

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

Re: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4

2020-05-14 Thread Christian König 

Am 14.05.20 um 11:18 schrieb jia...@amd.com:

From: Jiange Zhao 

When GPU got timeout, it would notify an interested part
of an opportunity to dump info before actual GPU reset.

A usermode app would open 'autodump' node under debugfs system
and poll() for readable/writable. When a GPU reset is due,
amdgpu would notify usermode app through wait_queue_head and give
it 10 minutes to dump info.

After usermode app has done its work, this 'autodump' node is closed.
On node closure, amdgpu gets to know the dump is done through
the completion that is triggered in release().

There is no write or read callback because necessary info can be
obtained through dmesg and umr. Messages back and forth between
usermode app and amdgpu are unnecessary.

v2: (1) changed 'registered' to 'app_listening'
 (2) add a mutex in open() to prevent race condition

v3 (chk): grab the reset lock to avoid race in autodump_open,
   rename debugfs file to amdgpu_autodump,
   provide autodump_read as well,
   style and code cleanups

v4: add 'bool app_listening' to differentiate situations, so that
 the node can be reopened; also, there is no need to wait for
 completion when no app is waiting for a dump.

v5: change 'bool app_listening' to 'enum amdgpu_autodump_state'
 add 'app_state_mutex' for race conditions:
(1)Only 1 user can open this file node
(2)wait_dump() can only take effect after poll() executed.
(3)eliminated the race condition between release() and
   wait_dump()

v6: removed 'enum amdgpu_autodump_state' and 'app_state_mutex'
 removed state checking in amdgpu_debugfs_wait_dump
 Improve on top of version 3 so that the node can be reopened.

v7: move reinit_completion into open() so that only one user
 can open it.

v8: remove complete_all() from amdgpu_debugfs_wait_dump().

Signed-off-by: Jiange Zhao 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 78 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |  6 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  2 +
  4 files changed, 87 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 2a806cb55b78..9e8eeddfe7ce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -992,6 +992,8 @@ struct amdgpu_device {
charproduct_number[16];
charproduct_name[32];
charserial[16];
+
+   struct amdgpu_autodump  autodump;
  };
  
  static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device *bdev)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 1a4894fa3693..d33cb344be69 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -27,7 +27,7 @@
  #include 
  #include 
  #include 
-
+#include 
  #include 
  
  #include "amdgpu.h"

@@ -74,8 +74,82 @@ int amdgpu_debugfs_add_files(struct amdgpu_device *adev,
return 0;
  }
  
+int amdgpu_debugfs_wait_dump(struct amdgpu_device *adev)

+{
+#if defined(CONFIG_DEBUG_FS)
+   unsigned long timeout = 600 * HZ;
+   int ret;
+
+   wake_up_interruptible(&adev->autodump.gpu_hang);
+
+   ret = 
wait_for_completion_interruptible_timeout(&adev->autodump.dumping, timeout);
+   if (ret == 0) {
+   pr_err("autodump: timeout, move on to gpu recovery\n");
+   return -ETIMEDOUT;
+   }
+#endif
+   return 0;
+}
+
  #if defined(CONFIG_DEBUG_FS)
  
+static int amdgpu_debugfs_autodump_open(struct inode *inode, struct file *file)

+{
+   struct amdgpu_device *adev = inode->i_private;
+   int ret;
+
+   file->private_data = adev;
+
+   mutex_lock(&adev->lock_reset);
+   if (adev->autodump.dumping.done) {
+   reinit_completion(&adev->autodump.dumping);
+   ret = 0;
+   } else {
+   ret = -EBUSY;
+   }
+   mutex_unlock(&adev->lock_reset);
+
+   return ret;
+}
+
+static int amdgpu_debugfs_autodump_release(struct inode *inode, struct file 
*file)
+{
+   struct amdgpu_device *adev = file->private_data;
+
+   complete_all(&adev->autodump.dumping);
+   return 0;
+}
+
+static unsigned int amdgpu_debugfs_autodump_poll(struct file *file, struct 
poll_table_struct *poll_table)
+{
+   struct amdgpu_device *adev = file->private_data;
+
+   poll_wait(file, &adev->autodump.gpu_hang, poll_table);
+
+   if (adev->in_gpu_reset)
+   return POLLIN | POLLRDNORM | POLLWRNORM;
+
+   return 0;
+}
+
+static const struct file_operations autodump_debug_fops = {
+   .owner = THIS_MODULE,
+   .open = amdgpu_debugfs_autodump_open,
+   .poll = amdgpu_debugfs_autodump_poll,
+   .rele

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

2020-05-14 Thread Daniel Stone 
Hi Alex,

On Thu, 30 Apr 2020 at 22:30, Alex Deucher  wrote:
> UAPI:
> - Add amdgpu UAPI for encrypted GPU memory
>   Used by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4401

Did this ever go through uAPI review? It's been pushed to the kernel
before Mesa review was complete. Even then, Mesa only uses it when
behind a magic environment variable, rather than through the EGL
extensions which have been specifically designed for protected content
(EGL_EXT_protected_content, protected_surface, etc). The winsys
usecase was based on a Wayland system which seems like it will only
work when composition bypass is available - not using any of the
Wayland protected-content extensions, and it's completely unclear what
will happen if composition bypass can't actually be achieved.

I don't think this should be landing before all those open questions
have been answered. We're trying to come up with a good and coherent
story for handling protected content, and I'd rather not see AMD
landing its own uAPI which might completely contradict that.

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

[PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4

2020-05-14 Thread jianzh 
From: Jiange Zhao 

When GPU got timeout, it would notify an interested part
of an opportunity to dump info before actual GPU reset.

A usermode app would open 'autodump' node under debugfs system
and poll() for readable/writable. When a GPU reset is due,
amdgpu would notify usermode app through wait_queue_head and give
it 10 minutes to dump info.

After usermode app has done its work, this 'autodump' node is closed.
On node closure, amdgpu gets to know the dump is done through
the completion that is triggered in release().

There is no write or read callback because necessary info can be
obtained through dmesg and umr. Messages back and forth between
usermode app and amdgpu are unnecessary.

v2: (1) changed 'registered' to 'app_listening'
(2) add a mutex in open() to prevent race condition

v3 (chk): grab the reset lock to avoid race in autodump_open,
  rename debugfs file to amdgpu_autodump,
  provide autodump_read as well,
  style and code cleanups

v4: add 'bool app_listening' to differentiate situations, so that
the node can be reopened; also, there is no need to wait for
completion when no app is waiting for a dump.

v5: change 'bool app_listening' to 'enum amdgpu_autodump_state'
add 'app_state_mutex' for race conditions:
(1)Only 1 user can open this file node
(2)wait_dump() can only take effect after poll() executed.
(3)eliminated the race condition between release() and
   wait_dump()

v6: removed 'enum amdgpu_autodump_state' and 'app_state_mutex'
removed state checking in amdgpu_debugfs_wait_dump
Improve on top of version 3 so that the node can be reopened.

v7: move reinit_completion into open() so that only one user
can open it.

v8: remove complete_all() from amdgpu_debugfs_wait_dump().

Signed-off-by: Jiange Zhao 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 78 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |  6 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  2 +
 4 files changed, 87 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 2a806cb55b78..9e8eeddfe7ce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -992,6 +992,8 @@ struct amdgpu_device {
charproduct_number[16];
charproduct_name[32];
charserial[16];
+
+   struct amdgpu_autodump  autodump;
 };
 
 static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device *bdev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 1a4894fa3693..d33cb344be69 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include 
 
 #include "amdgpu.h"
@@ -74,8 +74,82 @@ int amdgpu_debugfs_add_files(struct amdgpu_device *adev,
return 0;
 }
 
+int amdgpu_debugfs_wait_dump(struct amdgpu_device *adev)
+{
+#if defined(CONFIG_DEBUG_FS)
+   unsigned long timeout = 600 * HZ;
+   int ret;
+
+   wake_up_interruptible(&adev->autodump.gpu_hang);
+
+   ret = 
wait_for_completion_interruptible_timeout(&adev->autodump.dumping, timeout);
+   if (ret == 0) {
+   pr_err("autodump: timeout, move on to gpu recovery\n");
+   return -ETIMEDOUT;
+   }
+#endif
+   return 0;
+}
+
 #if defined(CONFIG_DEBUG_FS)
 
+static int amdgpu_debugfs_autodump_open(struct inode *inode, struct file *file)
+{
+   struct amdgpu_device *adev = inode->i_private;
+   int ret;
+
+   file->private_data = adev;
+
+   mutex_lock(&adev->lock_reset);
+   if (adev->autodump.dumping.done) {
+   reinit_completion(&adev->autodump.dumping);
+   ret = 0;
+   } else {
+   ret = -EBUSY;
+   }
+   mutex_unlock(&adev->lock_reset);
+
+   return ret;
+}
+
+static int amdgpu_debugfs_autodump_release(struct inode *inode, struct file 
*file)
+{
+   struct amdgpu_device *adev = file->private_data;
+
+   complete_all(&adev->autodump.dumping);
+   return 0;
+}
+
+static unsigned int amdgpu_debugfs_autodump_poll(struct file *file, struct 
poll_table_struct *poll_table)
+{
+   struct amdgpu_device *adev = file->private_data;
+
+   poll_wait(file, &adev->autodump.gpu_hang, poll_table);
+
+   if (adev->in_gpu_reset)
+   return POLLIN | POLLRDNORM | POLLWRNORM;
+
+   return 0;
+}
+
+static const struct file_operations autodump_debug_fops = {
+   .owner = THIS_MODULE,
+   .open = amdgpu_debugfs_autodump_open,
+   .poll = amdgpu_debugfs_autodump_poll,
+   .release = amdgpu_debugfs_autodump_release,
+};
+
+static void amdgpu_debugfs_autodump_init(struct amdgpu_device *adev

Re: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4

2020-05-14 Thread Christian König 

Hi Jiange,

it probably won't hurt, but I would just drop that. You need roughly 4 
billion GPU resets until the UINT_MAX-1 becomes zero again.


Christian.

Am 14.05.20 um 09:14 schrieb Zhao, Jiange:


[AMD Official Use Only - Internal Distribution Only]


Hi Christian,

wait_for_completion_interruptible_timeout() would decrease 
autodump.dumping.done to UINT_MAX-1.


complete_all() here would restore autodump.dumping to the state as in 
amdgpu_debugfs_autodump_init().


I want to make sure every open() deals with the same situation.

Jiange

*From:* Christian König 
*Sent:* Thursday, May 14, 2020 3:01 PM
*To:* Zhao, Jiange ; 
amd-gfx@lists.freedesktop.org 
*Cc:* Pelloux-prayer, Pierre-eric 
; Zhao, Jiange 
; Kuehling, Felix ; 
Deucher, Alexander ; Koenig, Christian 
; Liu, Monk ; Zhang, 
Hawking 
*Subject:* Re: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu 
reset v4

Am 14.05.20 um 07:29 schrieb jia...@amd.com:
> From: Jiange Zhao 
>
> When GPU got timeout, it would notify an interested part
> of an opportunity to dump info before actual GPU reset.
>
> A usermode app would open 'autodump' node under debugfs system
> and poll() for readable/writable. When a GPU reset is due,
> amdgpu would notify usermode app through wait_queue_head and give
> it 10 minutes to dump info.
>
> After usermode app has done its work, this 'autodump' node is closed.
> On node closure, amdgpu gets to know the dump is done through
> the completion that is triggered in release().
>
> There is no write or read callback because necessary info can be
> obtained through dmesg and umr. Messages back and forth between
> usermode app and amdgpu are unnecessary.
>
> v2: (1) changed 'registered' to 'app_listening'
>  (2) add a mutex in open() to prevent race condition
>
> v3 (chk): grab the reset lock to avoid race in autodump_open,
>    rename debugfs file to amdgpu_autodump,
>    provide autodump_read as well,
>    style and code cleanups
>
> v4: add 'bool app_listening' to differentiate situations, so that
>  the node can be reopened; also, there is no need to wait for
>  completion when no app is waiting for a dump.
>
> v5: change 'bool app_listening' to 'enum amdgpu_autodump_state'
>  add 'app_state_mutex' for race conditions:
>    (1)Only 1 user can open this file node
>    (2)wait_dump() can only take effect after poll() executed.
>    (3)eliminated the race condition between release() and
>   wait_dump()
>
> v6: removed 'enum amdgpu_autodump_state' and 'app_state_mutex'
>  removed state checking in amdgpu_debugfs_wait_dump
>  Improve on top of version 3 so that the node can be reopened.
>
> v7: move reinit_completion into open() so that only one user
>  can open it.
>
> Signed-off-by: Jiange Zhao 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 +
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 79 -
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |  6 ++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  2 +
>   4 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h

> index 2a806cb55b78..9e8eeddfe7ce 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -992,6 +992,8 @@ struct amdgpu_device {
>    char product_number[16];
>    char product_name[32];
>    char    serial[16];
> +
> + struct amdgpu_autodump  autodump;
>   };
>
>   static inline struct amdgpu_device *amdgpu_ttm_adev(struct 
ttm_bo_device *bdev)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c

> index 1a4894fa3693..efee3f1adecf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -27,7 +27,7 @@
>   #include 
>   #include 
>   #include 
> -
> +#include 
>   #include 
>
>   #include "amdgpu.h"
> @@ -74,8 +74,83 @@ int amdgpu_debugfs_add_files(struct amdgpu_device 
*adev,

>    return 0;
>   }
>
> +int amdgpu_debugfs_wait_dump(struct amdgpu_device *adev)
> +{
> +#if defined(CONFIG_DEBUG_FS)
> + unsigned long timeout = 600 * HZ;
> + int ret;
> +
> + wake_up_interruptible(&adev->autodump.gpu_hang);
> +
> + ret = 
wait_for_completion_interruptible_timeout(&adev->autodump.dumping, 
timeout);

> + complete_all(&adev->autodump.dumping);

Sorry that I'm mentioning this only now. But what is this complete_all()
here good for?

I mean we already waited for completion, didn't we?

Christian.

> + if (ret == 0) {
> + pr_err("autodump: timeout, move on to gpu recovery\n");
> + return -ETIMEDOUT;
> + }
> +#endif
> + return 0;
> +}
> +
>   #if defined(CONFIG_DEBUG_FS)
>
> +static int amdgpu_debugfs_autodump_open(struct inode *inode, struct 
file *file)

Re: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4

2020-05-14 Thread Zhao, Jiange 
[AMD Official Use Only - Internal Distribution Only]

Hi Christian,

wait_for_completion_interruptible_timeout() would decrease 
autodump.dumping.done to UINT_MAX-1.

complete_all() here would restore autodump.dumping to the state as in 
amdgpu_debugfs_autodump_init().

I want to make sure every open() deals with the same situation.

Jiange

From: Christian K?nig 
Sent: Thursday, May 14, 2020 3:01 PM
To: Zhao, Jiange ; amd-gfx@lists.freedesktop.org 

Cc: Pelloux-prayer, Pierre-eric ; Zhao, 
Jiange ; Kuehling, Felix ; 
Deucher, Alexander ; Koenig, Christian 
; Liu, Monk ; Zhang, Hawking 

Subject: Re: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4

Am 14.05.20 um 07:29 schrieb jia...@amd.com:
> From: Jiange Zhao 
>
> When GPU got timeout, it would notify an interested part
> of an opportunity to dump info before actual GPU reset.
>
> A usermode app would open 'autodump' node under debugfs system
> and poll() for readable/writable. When a GPU reset is due,
> amdgpu would notify usermode app through wait_queue_head and give
> it 10 minutes to dump info.
>
> After usermode app has done its work, this 'autodump' node is closed.
> On node closure, amdgpu gets to know the dump is done through
> the completion that is triggered in release().
>
> There is no write or read callback because necessary info can be
> obtained through dmesg and umr. Messages back and forth between
> usermode app and amdgpu are unnecessary.
>
> v2: (1) changed 'registered' to 'app_listening'
>  (2) add a mutex in open() to prevent race condition
>
> v3 (chk): grab the reset lock to avoid race in autodump_open,
>rename debugfs file to amdgpu_autodump,
>provide autodump_read as well,
>style and code cleanups
>
> v4: add 'bool app_listening' to differentiate situations, so that
>  the node can be reopened; also, there is no need to wait for
>  completion when no app is waiting for a dump.
>
> v5: change 'bool app_listening' to 'enum amdgpu_autodump_state'
>  add 'app_state_mutex' for race conditions:
>(1)Only 1 user can open this file node
>(2)wait_dump() can only take effect after poll() executed.
>(3)eliminated the race condition between release() and
>   wait_dump()
>
> v6: removed 'enum amdgpu_autodump_state' and 'app_state_mutex'
>  removed state checking in amdgpu_debugfs_wait_dump
>  Improve on top of version 3 so that the node can be reopened.
>
> v7: move reinit_completion into open() so that only one user
>  can open it.
>
> Signed-off-by: Jiange Zhao 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 +
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 79 -
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |  6 ++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  2 +
>   4 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 2a806cb55b78..9e8eeddfe7ce 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -992,6 +992,8 @@ struct amdgpu_device {
>charproduct_number[16];
>charproduct_name[32];
>charserial[16];
> +
> + struct amdgpu_autodump  autodump;
>   };
>
>   static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device 
> *bdev)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index 1a4894fa3693..efee3f1adecf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -27,7 +27,7 @@
>   #include 
>   #include 
>   #include 
> -
> +#include 
>   #include 
>
>   #include "amdgpu.h"
> @@ -74,8 +74,83 @@ int amdgpu_debugfs_add_files(struct amdgpu_device *adev,
>return 0;
>   }
>
> +int amdgpu_debugfs_wait_dump(struct amdgpu_device *adev)
> +{
> +#if defined(CONFIG_DEBUG_FS)
> + unsigned long timeout = 600 * HZ;
> + int ret;
> +
> + wake_up_interruptible(&adev->autodump.gpu_hang);
> +
> + ret = 
> wait_for_completion_interruptible_timeout(&adev->autodump.dumping, timeout);
> + complete_all(&adev->autodump.dumping);

Sorry that I'm mentioning this only now. But what is this complete_all()
here good for?

I mean we already waited for completion, didn't we?

Christian.

> + if (ret == 0) {
> + pr_err("autodump: timeout, move on to gpu recovery\n");
> + return -ETIMEDOUT;
> + }
> +#endif
> + return 0;
> +}
> +
>   #if defined(CONFIG_DEBUG_FS)
>
> +static int amdgpu_debugfs_autodump_open(struct inode *inode, struct file 
> *file)
> +{
> + struct amdgpu_device *adev = inode->i_private;
> + int ret;
> +
> + file->private_data = adev;
> +
> + mutex_lock(&adev->lock_reset);
> + if (adev->autodump.dumping.done

Re: [PATCH] drm/amdgpu: Add autodump debugfs node for gpu reset v4

2020-05-14 Thread Christian König 

Am 14.05.20 um 07:29 schrieb jia...@amd.com:

From: Jiange Zhao 

When GPU got timeout, it would notify an interested part
of an opportunity to dump info before actual GPU reset.

A usermode app would open 'autodump' node under debugfs system
and poll() for readable/writable. When a GPU reset is due,
amdgpu would notify usermode app through wait_queue_head and give
it 10 minutes to dump info.

After usermode app has done its work, this 'autodump' node is closed.
On node closure, amdgpu gets to know the dump is done through
the completion that is triggered in release().

There is no write or read callback because necessary info can be
obtained through dmesg and umr. Messages back and forth between
usermode app and amdgpu are unnecessary.

v2: (1) changed 'registered' to 'app_listening'
 (2) add a mutex in open() to prevent race condition

v3 (chk): grab the reset lock to avoid race in autodump_open,
   rename debugfs file to amdgpu_autodump,
   provide autodump_read as well,
   style and code cleanups

v4: add 'bool app_listening' to differentiate situations, so that
 the node can be reopened; also, there is no need to wait for
 completion when no app is waiting for a dump.

v5: change 'bool app_listening' to 'enum amdgpu_autodump_state'
 add 'app_state_mutex' for race conditions:
(1)Only 1 user can open this file node
(2)wait_dump() can only take effect after poll() executed.
(3)eliminated the race condition between release() and
   wait_dump()

v6: removed 'enum amdgpu_autodump_state' and 'app_state_mutex'
 removed state checking in amdgpu_debugfs_wait_dump
 Improve on top of version 3 so that the node can be reopened.

v7: move reinit_completion into open() so that only one user
 can open it.

Signed-off-by: Jiange Zhao 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 79 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h |  6 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  2 +
  4 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 2a806cb55b78..9e8eeddfe7ce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -992,6 +992,8 @@ struct amdgpu_device {
charproduct_number[16];
charproduct_name[32];
charserial[16];
+
+   struct amdgpu_autodump  autodump;
  };
  
  static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device *bdev)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 1a4894fa3693..efee3f1adecf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -27,7 +27,7 @@
  #include 
  #include 
  #include 
-
+#include 
  #include 
  
  #include "amdgpu.h"

@@ -74,8 +74,83 @@ int amdgpu_debugfs_add_files(struct amdgpu_device *adev,
return 0;
  }
  
+int amdgpu_debugfs_wait_dump(struct amdgpu_device *adev)

+{
+#if defined(CONFIG_DEBUG_FS)
+   unsigned long timeout = 600 * HZ;
+   int ret;
+
+   wake_up_interruptible(&adev->autodump.gpu_hang);
+
+   ret = 
wait_for_completion_interruptible_timeout(&adev->autodump.dumping, timeout);
+   complete_all(&adev->autodump.dumping);


Sorry that I'm mentioning this only now. But what is this complete_all() 
here good for?


I mean we already waited for completion, didn't we?

Christian.


+   if (ret == 0) {
+   pr_err("autodump: timeout, move on to gpu recovery\n");
+   return -ETIMEDOUT;
+   }
+#endif
+   return 0;
+}
+
  #if defined(CONFIG_DEBUG_FS)
  
+static int amdgpu_debugfs_autodump_open(struct inode *inode, struct file *file)

+{
+   struct amdgpu_device *adev = inode->i_private;
+   int ret;
+
+   file->private_data = adev;
+
+   mutex_lock(&adev->lock_reset);
+   if (adev->autodump.dumping.done) {
+   reinit_completion(&adev->autodump.dumping);
+   ret = 0;
+   } else {
+   ret = -EBUSY;
+   }
+   mutex_unlock(&adev->lock_reset);
+
+   return ret;
+}
+
+static int amdgpu_debugfs_autodump_release(struct inode *inode, struct file 
*file)
+{
+   struct amdgpu_device *adev = file->private_data;
+
+   complete_all(&adev->autodump.dumping);
+   return 0;
+}
+
+static unsigned int amdgpu_debugfs_autodump_poll(struct file *file, struct 
poll_table_struct *poll_table)
+{
+   struct amdgpu_device *adev = file->private_data;
+
+   poll_wait(file, &adev->autodump.gpu_hang, poll_table);
+
+   if (adev->in_gpu_reset)
+   return POLLIN | POLLRDNORM | POLLWRNORM;
+
+   return 0;
+}
+
+static const struct file_operations autodump_debug_fops = {
+   .owner = THIS_M