Re: [PATCH 1/1] drm/ttm: Ignore signaled move fences

[Christian König]

Am 05.03.21 um 02:21 schrieb Felix Kuehling:

Am 2021-03-01 um 10:09 a.m. schrieb Christian König:

Am 27.02.21 um 04:45 schrieb Felix Kuehling:

Move fences that have already signaled should not prevent memory
allocations with no_wait_gpu.

Signed-off-by: Felix Kuehling 

Reviewed-by: Christian König 

I work on this on Alex's rebased amd-staging-drm-next. Should this go
into any other branches?


I have a branch with stuff for 5.13 which I want to push to 
drm-misc-next as soon as 5.12-rc1 is out.


Going to add this one here to that collection as well unless you say 
that this is really a bug fix and we need it earlier.


Regards,
Christian.



Thanks,
   Felix



---
   drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3a10bebb75d6..de1ec838cf8b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -730,8 +730,9 @@ static int ttm_bo_add_move_fence(struct
ttm_buffer_object *bo,
   return 0;
     if (no_wait_gpu) {
+    ret = dma_fence_is_signaled(fence) ? 0 : -EBUSY;
   dma_fence_put(fence);
-    return -EBUSY;
+    return ret;
   }
     dma_resv_add_shared_fence(bo->base.resv, fence);


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

Re: [PATCH] drm/amdgpu: Fix some unload driver issues

[Christian König]

Am 05.03.21 um 02:20 schrieb Emily Deng:

When unloading driver after killing some applications, it will hit sdma
flush tlb job timeout which is called by ttm_bo_delay_delete. So
to avoid the job submit after fence driver fini, call 
ttm_bo_lock_delayed_workqueue
before fence driver fini. And also put drm_sched_fini before waiting fence.


Good catch, Reviewed-by: Christian König  for 
this part.



Set adev->gart.ptr to null to fix null pointer when calling amdgpu_gart_unbind
in amdgpu_bo_fini which is after gart_fini.


For that one I'm wondering if we shouldn't rather rework or double check 
the tear down order.


On the other hand the hardware should be idle by now (this comes after 
the fence_driver_fini, doesn't it?) and it looks cleaner on it's own.


Regards,
Christian.



Signed-off-by: Emily Deng 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  | 5 +++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c   | 1 +
  3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a11760ec3924..de0597d34588 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3594,6 +3594,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
  {
dev_info(adev->dev, "amdgpu: finishing device.\n");
flush_delayed_work(&adev->delayed_init_work);
+   ttm_bo_lock_delayed_workqueue(&adev->mman.bdev);
adev->shutdown = true;
  
  	kfree(adev->pci_state);

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 143a14f4866f..6d16f58ac91e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -531,6 +531,8 @@ void amdgpu_fence_driver_fini(struct amdgpu_device *adev)
  
  		if (!ring || !ring->fence_drv.initialized)

continue;
+   if (!ring->no_scheduler)
+   drm_sched_fini(&ring->sched);
r = amdgpu_fence_wait_empty(ring);
if (r) {
/* no need to trigger GPU reset as we are unloading */
@@ -539,8 +541,7 @@ void amdgpu_fence_driver_fini(struct amdgpu_device *adev)
if (ring->fence_drv.irq_src)
amdgpu_irq_put(adev, ring->fence_drv.irq_src,
   ring->fence_drv.irq_type);
-   if (!ring->no_scheduler)
-   drm_sched_fini(&ring->sched);
+
del_timer_sync(&ring->fence_drv.fallback_timer);
for (j = 0; j <= ring->fence_drv.num_fences_mask; ++j)
dma_fence_put(ring->fence_drv.fences[j]);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index 23823a57374f..f1ede4b43d07 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -202,6 +202,7 @@ void amdgpu_gart_table_vram_free(struct amdgpu_device *adev)
return;
}
amdgpu_bo_unref(&adev->gart.bo);
+   adev->gart.ptr = NULL;
  }
  
  /*


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

RE: [PATCH] drm/amd/pm: correct the watermark settings for Polaris

[Xu, Feifei]

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Feifei Xu 

-Original Message-
From: amd-gfx  On Behalf Of Evan Quan
Sent: Friday, March 5, 2021 2:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Georgios Toptsidis 
; Quan, Evan ; Chen, Guchun 

Subject: [PATCH] drm/amd/pm: correct the watermark settings for Polaris

The "/ 10" should be applied to the right-hand operand instead of the left-hand 
one.

Change-Id: Ie730a1981aa5dee45cd6c3efccc7fb0f088cd679
Signed-off-by: Evan Quan 
Noticed-by: Georgios Toptsidis 
---
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
index c57dc9ae81f2..a2681fe875ed 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
@@ -5216,10 +5216,10 @@ static int smu7_set_watermarks_for_clocks_ranges(struct 
pp_hwmgr *hwmgr,
 for (j = 0; j < dep_sclk_table->count; j++) {
 valid_entry = false;
 for (k = 0; k < watermarks->num_wm_sets; k++) {
-if (dep_sclk_table->entries[i].clk / 10 >= 
watermarks->wm_clk_ranges[k].wm_min_eng_clk_in_khz &&
-dep_sclk_table->entries[i].clk / 10 < 
watermarks->wm_clk_ranges[k].wm_max_eng_clk_in_khz &&
-dep_mclk_table->entries[i].clk / 10 >= 
watermarks->wm_clk_ranges[k].wm_min_mem_clk_in_khz &&
-dep_mclk_table->entries[i].clk / 10 < 
watermarks->wm_clk_ranges[k].wm_max_mem_clk_in_khz) {
+if (dep_sclk_table->entries[i].clk >= 
watermarks->wm_clk_ranges[k].wm_min_eng_clk_in_khz / 10 &&
+dep_sclk_table->entries[i].clk < 
watermarks->wm_clk_ranges[k].wm_max_eng_clk_in_khz / 10 &&
+dep_mclk_table->entries[i].clk >= 
watermarks->wm_clk_ranges[k].wm_min_mem_clk_in_khz / 10 &&
+dep_mclk_table->entries[i].clk <
+watermarks->wm_clk_ranges[k].wm_max_mem_clk_in_khz / 10) {
 valid_entry = true;
 table->DisplayWatermark[i][j] = watermarks->wm_clk_ranges[k].wm_set_id;
 break;
--
2.29.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7CFeifei.Xu%40amd.com%7C629b5ae589cd43f4506f08d8df9f80d2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637505223446156243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I7hiICVKpvwlZtmT302%2BLJJPo8RLa6yu37EuJDOotHg%3D&reserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amd/pm: correct the watermark settings for Polaris

[Evan Quan]

The "/ 10" should be applied to the right-hand operand instead of
the left-hand one.

Change-Id: Ie730a1981aa5dee45cd6c3efccc7fb0f088cd679
Signed-off-by: Evan Quan 
Noticed-by: Georgios Toptsidis 
---
 drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
index c57dc9ae81f2..a2681fe875ed 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
@@ -5216,10 +5216,10 @@ static int smu7_set_watermarks_for_clocks_ranges(struct 
pp_hwmgr *hwmgr,
for (j = 0; j < dep_sclk_table->count; j++) {
valid_entry = false;
for (k = 0; k < watermarks->num_wm_sets; k++) {
-   if (dep_sclk_table->entries[i].clk / 10 >= 
watermarks->wm_clk_ranges[k].wm_min_eng_clk_in_khz &&
-   dep_sclk_table->entries[i].clk / 10 < 
watermarks->wm_clk_ranges[k].wm_max_eng_clk_in_khz &&
-   dep_mclk_table->entries[i].clk / 10 >= 
watermarks->wm_clk_ranges[k].wm_min_mem_clk_in_khz &&
-   dep_mclk_table->entries[i].clk / 10 < 
watermarks->wm_clk_ranges[k].wm_max_mem_clk_in_khz) {
+   if (dep_sclk_table->entries[i].clk >= 
watermarks->wm_clk_ranges[k].wm_min_eng_clk_in_khz / 10 &&
+   dep_sclk_table->entries[i].clk < 
watermarks->wm_clk_ranges[k].wm_max_eng_clk_in_khz / 10 &&
+   dep_mclk_table->entries[i].clk >= 
watermarks->wm_clk_ranges[k].wm_min_mem_clk_in_khz / 10 &&
+   dep_mclk_table->entries[i].clk < 
watermarks->wm_clk_ranges[k].wm_max_mem_clk_in_khz / 10) {
valid_entry = true;
table->DisplayWatermark[i][j] = 
watermarks->wm_clk_ranges[k].wm_set_id;
break;
-- 
2.29.0

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

RE: [PATCH] drm/amd/amdgpu: add fini virt data exchange to ip_suspend

[Zhang, Jack (Jian)]

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Jack Zhang 


-Original Message-
From: Jingwen Chen 
Sent: Friday, March 5, 2021 2:12 PM
To: amd-gfx@lists.freedesktop.org
Cc: Chen, Horace ; Zhang, Jack (Jian) 
; Chen, JingWen 
Subject: [PATCH] drm/amd/amdgpu: add fini virt data exchange to ip_suspend

[Why]
when try to shutdown guest vm in sriov mode, virt data exchange is not fini. 
After vram lost, trying to write vram could hang cpu.

[How]
add fini virt data exchange in ip_suspend

Signed-off-by: Jingwen Chen 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a11760ec3924..bec725b50c1b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2774,8 +2774,10 @@ int amdgpu_device_ip_suspend(struct amdgpu_device *adev) 
 {
 int r;

-if (amdgpu_sriov_vf(adev))
+if (amdgpu_sriov_vf(adev)) {
+amdgpu_virt_fini_data_exchange(adev);
 amdgpu_virt_request_full_gpu(adev, false);
+}

 r = amdgpu_device_ip_suspend_phase1(adev);
 if (r)
--
2.25.1

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

[PATCH] drm/amd/amdgpu: add fini virt data exchange to ip_suspend

[Jingwen Chen]

[Why]
when try to shutdown guest vm in sriov mode, virt data
exchange is not fini. After vram lost, trying to write
vram could hang cpu.

[How]
add fini virt data exchange in ip_suspend

Signed-off-by: Jingwen Chen 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a11760ec3924..bec725b50c1b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2774,8 +2774,10 @@ int amdgpu_device_ip_suspend(struct amdgpu_device *adev)
 {
int r;
 
-   if (amdgpu_sriov_vf(adev))
+   if (amdgpu_sriov_vf(adev)) {
+   amdgpu_virt_fini_data_exchange(adev);
amdgpu_virt_request_full_gpu(adev, false);
+   }
 
r = amdgpu_device_ip_suspend_phase1(adev);
if (r)
-- 
2.25.1

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

RE: [PATCH] drm/amd/amdgpu: fini data exchange when req_gpu_fini in SRIOV

[Zhang, Jack (Jian)]

[AMD Official Use Only - Internal Distribution Only]

Please comments what the issue is without this change.

/Jack
-Original Message-
From: Jingwen Chen 
Sent: Friday, March 5, 2021 12:44 PM
To: amd-gfx@lists.freedesktop.org
Cc: Chen, Horace ; Zhang, Jack (Jian) 
; Chen, JingWen 
Subject: [PATCH] drm/amd/amdgpu: fini data exchange when req_gpu_fini in SRIOV

Do fini data exchange everytime req_gpu_fini in SRIOV

Signed-off-by: Jingwen Chen 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c   | 3 +++
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a11760ec3924..e3ed52f66414 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3601,10 +3601,8 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
 /* make sure IB test finished before entering exclusive mode
  * to avoid preemption on IB test
  * */
-if (amdgpu_sriov_vf(adev)) {
+if (amdgpu_sriov_vf(adev))
 amdgpu_virt_request_full_gpu(adev, false);
-amdgpu_virt_fini_data_exchange(adev);
-}

 /* disable all interrupts */
 amdgpu_irq_disable_all(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index 3dd7eec52344..af1e5d8fc2b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -114,6 +114,9 @@ int amdgpu_virt_request_full_gpu(struct amdgpu_device 
*adev, bool init)
 struct amdgpu_virt *virt = &adev->virt;
 int r;

+if (!init)
+amdgpu_virt_fini_data_exchange(adev);
+
 if (virt->ops && virt->ops->req_full_gpu) {
 r = virt->ops->req_full_gpu(adev, init);
 if (r)
--
2.25.1

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

RE: [PATCH] drm/amdkfd: Fix UBSAN shift-out-of-bounds warning

[Lazar, Lijo]

[AMD Public Use]



-Original Message-
From: amd-gfx  On Behalf Of Anson Jacob
Sent: Friday, March 5, 2021 1:39 AM
To: amd-gfx@lists.freedesktop.org
Cc: Jacob, Anson ; Deucher, Alexander 
; Kuehling, Felix 
Subject: [PATCH] drm/amdkfd: Fix UBSAN shift-out-of-bounds warning

If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up doing a 
shift operation where the number of bits shifted equals number of bits in the 
operand. This behaviour is undefined.

Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the count is >= 
number of bits in the operand.

Bug: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2F-%2Fissues%2F1472&data=04%7C01%7Clijo.lazar%40amd.com%7Cc731ee10b10b4728138808d8df496648%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637504853648181515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iNLxyPbJfbuUeKFA6ygwcBGDSRJcfgOGjMFNHwGzun0%3D&reserved=0
Reported-by: Lyude Paul 
Signed-off-by: Anson Jacob 
Reviewed-by: Alex Deucher 
Reviewed-by: Felix Kuehling 
---
 .../drm/amd/amdkfd/kfd_device_queue_manager.c   | 17 +++--
 1 file changed, 15 insertions(+), 2 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 c37e9c4b1fb4..e7a3c496237f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -1128,6 +1128,9 @@ static int set_sched_resources(struct 
device_queue_manager *dqm)
 
 static int initialize_cpsch(struct device_queue_manager *dqm)  {
+   uint64_t num_sdma_queues;
+   uint64_t num_xgmi_sdma_queues;
+
pr_debug("num of pipes: %d\n", get_pipes_per_mec(dqm));
 
mutex_init(&dqm->lock_hidden);
@@ -1136,8 +1139,18 @@ static int initialize_cpsch(struct device_queue_manager 
*dqm)
dqm->active_cp_queue_count = 0;
dqm->gws_queue_count = 0;
dqm->active_runlist = false;
-   dqm->sdma_bitmap = ~0ULL >> (64 - get_num_sdma_queues(dqm));
-   dqm->xgmi_sdma_bitmap = ~0ULL >> (64 - get_num_xgmi_sdma_queues(dqm));
+
+   num_sdma_queues = get_num_sdma_queues(dqm);
+   if (num_sdma_queues >= BITS_PER_TYPE(dqm->sdma_bitmap))

< > No assumption about bitmap size here

+   dqm->sdma_bitmap = ULLONG_MAX;

<> This assumes/fixes the max size. In that case why not make the earlier check 
also consistent?

+   else
+   dqm->sdma_bitmap = (BIT_ULL(num_sdma_queues) - 1);
+
+   num_xgmi_sdma_queues = get_num_xgmi_sdma_queues(dqm);
+   if (num_xgmi_sdma_queues >= BITS_PER_TYPE(dqm->xgmi_sdma_bitmap))
+   dqm->xgmi_sdma_bitmap = ULLONG_MAX;
+   else
+   dqm->xgmi_sdma_bitmap = (BIT_ULL(num_xgmi_sdma_queues) - 1);
 
INIT_WORK(&dqm->hw_exception_work, kfd_process_hw_exception);
 
--
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Clijo.lazar%40amd.com%7Cc731ee10b10b4728138808d8df496648%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637504853648191471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EpuPBBf03EMa0S7rOqI8JieOmcT3GvsnsQMaYujGgeY%3D&reserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] gpu: drm: swsmu: fix error return code of smu_v11_0_set_allowed_mask()

[Jia-Ju Bai]

When bitmap_empty() or feature->feature_num triggers an error, 
no error return code of smu_v11_0_set_allowed_mask() is assigned.
To fix this bug, ret is assigned with -EINVAL as error return code.

Reported-by: TOTE Robot 
Signed-off-by: Jia-Ju Bai 
---
 drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
index 90585461a56e..82731a932308 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
@@ -747,8 +747,10 @@ int smu_v11_0_set_allowed_mask(struct smu_context *smu)
int ret = 0;
uint32_t feature_mask[2];
 
-   if (bitmap_empty(feature->allowed, SMU_FEATURE_MAX) || 
feature->feature_num < 64)
+   if (bitmap_empty(feature->allowed, SMU_FEATURE_MAX) || 
feature->feature_num < 64) {
+   ret = -EINVAL;
goto failed;
+   }
 
bitmap_copy((unsigned long *)feature_mask, feature->allowed, 64);
 
-- 
2.17.1

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

[PATCH] drm/amd/amdgpu: fini data exchange when req_gpu_fini in SRIOV

[Jingwen Chen]

Do fini data exchange everytime req_gpu_fini in SRIOV

Signed-off-by: Jingwen Chen 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c   | 3 +++
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a11760ec3924..e3ed52f66414 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3601,10 +3601,8 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
/* make sure IB test finished before entering exclusive mode
 * to avoid preemption on IB test
 * */
-   if (amdgpu_sriov_vf(adev)) {
+   if (amdgpu_sriov_vf(adev))
amdgpu_virt_request_full_gpu(adev, false);
-   amdgpu_virt_fini_data_exchange(adev);
-   }
 
/* disable all interrupts */
amdgpu_irq_disable_all(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index 3dd7eec52344..af1e5d8fc2b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -114,6 +114,9 @@ int amdgpu_virt_request_full_gpu(struct amdgpu_device 
*adev, bool init)
struct amdgpu_virt *virt = &adev->virt;
int r;
 
+   if (!init)
+   amdgpu_virt_fini_data_exchange(adev);
+
if (virt->ops && virt->ops->req_full_gpu) {
r = virt->ops->req_full_gpu(adev, init);
if (r)
-- 
2.25.1

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

RE: [PATCH] gpu: drm: swsmu: fix error return code of smu_v11_0_set_allowed_mask()

[Quan, Evan]

[AMD Public Use]

Thanks. Reviewed-by: Evan Quan 

-Original Message-
From: Jia-Ju Bai  
Sent: Friday, March 5, 2021 11:54 AM
To: Deucher, Alexander ; Koenig, Christian 
; airl...@linux.ie; dan...@ffwll.ch; Quan, Evan 
; Zhang, Hawking ; Wang, Kevin(Yang) 
; Gao, Likun 
Cc: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
linux-ker...@vger.kernel.org; Jia-Ju Bai 
Subject: [PATCH] gpu: drm: swsmu: fix error return code of 
smu_v11_0_set_allowed_mask()

When bitmap_empty() or feature->feature_num triggers an error, no error return 
code of smu_v11_0_set_allowed_mask() is assigned.
To fix this bug, ret is assigned with -EINVAL as error return code.

Reported-by: TOTE Robot 
Signed-off-by: Jia-Ju Bai 
---
 drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
index 90585461a56e..82731a932308 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
@@ -747,8 +747,10 @@ int smu_v11_0_set_allowed_mask(struct smu_context *smu)
int ret = 0;
uint32_t feature_mask[2];
 
-   if (bitmap_empty(feature->allowed, SMU_FEATURE_MAX) || 
feature->feature_num < 64)
+   if (bitmap_empty(feature->allowed, SMU_FEATURE_MAX) || 
feature->feature_num < 64) {
+   ret = -EINVAL;
goto failed;
+   }
 
bitmap_copy((unsigned long *)feature_mask, feature->allowed, 64);
 
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [amdgpu] Can compute kernels with different VMIDs run concurrently on the gpu hardware

[Felix Kuehling]

Am 2021-03-04 um 3:03 a.m. schrieb Smith John:
> Hi! I noticed that kernels with different VMIDs have different GPU
> address spaces. I was wondering if it is possible for these kernels to
> run concurrently on the same GPU, or they need to be serialized even
> when there are free CUs.

They can run concurrently. That's the point of having multiple VMIDs in
the first place.

Regards,
  Felix


>
> ___
> 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/amdkfd: Move set_trap_handler out of dqm->ops

[Felix Kuehling]

Am 2021-03-04 um 10:12 p.m. schrieb Jay Cornwall:
> Trap handler is set per-process per-device and is unrelated
> to queue management.
>
> Move implementation closer to TMA setup code.
>
> Signed-off-by: Jay Cornwall 

Reviewed-by: Felix Kuehling 


> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  |  6 +
>  .../drm/amd/amdkfd/kfd_device_queue_manager.c | 22 ---
>  .../drm/amd/amdkfd/kfd_device_queue_manager.h |  5 -
>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  4 
>  drivers/gpu/drm/amd/amdkfd/kfd_process.c  | 19 
>  5 files changed, 24 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> index 8cc51cec988a..6802c616e10e 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> @@ -556,11 +556,7 @@ static int kfd_ioctl_set_trap_handler(struct file *filep,
>   goto out;
>   }
>  
> - if (dev->dqm->ops.set_trap_handler(dev->dqm,
> - &pdd->qpd,
> - args->tba_addr,
> - args->tma_addr))
> - err = -EINVAL;
> + kfd_process_set_trap_handler(&pdd->qpd, args->tba_addr, args->tma_addr);
>  
>  out:
>   mutex_unlock(&p->mutex);
> 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 c37e9c4b1fb4..6bb778f24441 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -1596,26 +1596,6 @@ static bool set_cache_memory_policy(struct 
> device_queue_manager *dqm,
>   return retval;
>  }
>  
> -static int set_trap_handler(struct device_queue_manager *dqm,
> - struct qcm_process_device *qpd,
> - uint64_t tba_addr,
> - uint64_t tma_addr)
> -{
> - uint64_t *tma;
> -
> - if (dqm->dev->cwsr_enabled) {
> - /* Jump from CWSR trap handler to user trap */
> - tma = (uint64_t *)(qpd->cwsr_kaddr + KFD_CWSR_TMA_OFFSET);
> - tma[0] = tba_addr;
> - tma[1] = tma_addr;
> - } else {
> - qpd->tba_addr = tba_addr;
> - qpd->tma_addr = tma_addr;
> - }
> -
> - return 0;
> -}
> -
>  static int process_termination_nocpsch(struct device_queue_manager *dqm,
>   struct qcm_process_device *qpd)
>  {
> @@ -1859,7 +1839,6 @@ struct device_queue_manager 
> *device_queue_manager_init(struct kfd_dev *dev)
>   dqm->ops.create_kernel_queue = create_kernel_queue_cpsch;
>   dqm->ops.destroy_kernel_queue = destroy_kernel_queue_cpsch;
>   dqm->ops.set_cache_memory_policy = set_cache_memory_policy;
> - dqm->ops.set_trap_handler = set_trap_handler;
>   dqm->ops.process_termination = process_termination_cpsch;
>   dqm->ops.evict_process_queues = evict_process_queues_cpsch;
>   dqm->ops.restore_process_queues = restore_process_queues_cpsch;
> @@ -1878,7 +1857,6 @@ struct device_queue_manager 
> *device_queue_manager_init(struct kfd_dev *dev)
>   dqm->ops.initialize = initialize_nocpsch;
>   dqm->ops.uninitialize = uninitialize;
>   dqm->ops.set_cache_memory_policy = set_cache_memory_policy;
> - dqm->ops.set_trap_handler = set_trap_handler;
>   dqm->ops.process_termination = process_termination_nocpsch;
>   dqm->ops.evict_process_queues = evict_process_queues_nocpsch;
>   dqm->ops.restore_process_queues =
> 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 16262e5d93f5..aee033b1d148 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> @@ -121,11 +121,6 @@ struct device_queue_manager_ops {
>  void __user *alternate_aperture_base,
>  uint64_t alternate_aperture_size);
>  
> - int (*set_trap_handler)(struct device_queue_manager *dqm,
> - struct qcm_process_device *qpd,
> - uint64_t tba_addr,
> - uint64_t tma_addr);
> -
>   int (*process_termination)(struct device_queue_manager *dqm,
>   struct qcm_process_device *qpd);
>  
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
> b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> index e2ebd5a1d4de..8f839154bf1f 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> @@ -944,6 +944,10 @@ bool interrupt_is_wanted(struct kfd_dev *dev,
>  /* amdkfd Apertures */
>  int kfd_init_apertu

[PATCH] drm/amdkfd: Move set_trap_handler out of dqm->ops

[Jay Cornwall]

Trap handler is set per-process per-device and is unrelated
to queue management.

Move implementation closer to TMA setup code.

Signed-off-by: Jay Cornwall 
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  |  6 +
 .../drm/amd/amdkfd/kfd_device_queue_manager.c | 22 ---
 .../drm/amd/amdkfd/kfd_device_queue_manager.h |  5 -
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  4 
 drivers/gpu/drm/amd/amdkfd/kfd_process.c  | 19 
 5 files changed, 24 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 8cc51cec988a..6802c616e10e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -556,11 +556,7 @@ static int kfd_ioctl_set_trap_handler(struct file *filep,
goto out;
}
 
-   if (dev->dqm->ops.set_trap_handler(dev->dqm,
-   &pdd->qpd,
-   args->tba_addr,
-   args->tma_addr))
-   err = -EINVAL;
+   kfd_process_set_trap_handler(&pdd->qpd, args->tba_addr, args->tma_addr);
 
 out:
mutex_unlock(&p->mutex);
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 c37e9c4b1fb4..6bb778f24441 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -1596,26 +1596,6 @@ static bool set_cache_memory_policy(struct 
device_queue_manager *dqm,
return retval;
 }
 
-static int set_trap_handler(struct device_queue_manager *dqm,
-   struct qcm_process_device *qpd,
-   uint64_t tba_addr,
-   uint64_t tma_addr)
-{
-   uint64_t *tma;
-
-   if (dqm->dev->cwsr_enabled) {
-   /* Jump from CWSR trap handler to user trap */
-   tma = (uint64_t *)(qpd->cwsr_kaddr + KFD_CWSR_TMA_OFFSET);
-   tma[0] = tba_addr;
-   tma[1] = tma_addr;
-   } else {
-   qpd->tba_addr = tba_addr;
-   qpd->tma_addr = tma_addr;
-   }
-
-   return 0;
-}
-
 static int process_termination_nocpsch(struct device_queue_manager *dqm,
struct qcm_process_device *qpd)
 {
@@ -1859,7 +1839,6 @@ struct device_queue_manager 
*device_queue_manager_init(struct kfd_dev *dev)
dqm->ops.create_kernel_queue = create_kernel_queue_cpsch;
dqm->ops.destroy_kernel_queue = destroy_kernel_queue_cpsch;
dqm->ops.set_cache_memory_policy = set_cache_memory_policy;
-   dqm->ops.set_trap_handler = set_trap_handler;
dqm->ops.process_termination = process_termination_cpsch;
dqm->ops.evict_process_queues = evict_process_queues_cpsch;
dqm->ops.restore_process_queues = restore_process_queues_cpsch;
@@ -1878,7 +1857,6 @@ struct device_queue_manager 
*device_queue_manager_init(struct kfd_dev *dev)
dqm->ops.initialize = initialize_nocpsch;
dqm->ops.uninitialize = uninitialize;
dqm->ops.set_cache_memory_policy = set_cache_memory_policy;
-   dqm->ops.set_trap_handler = set_trap_handler;
dqm->ops.process_termination = process_termination_nocpsch;
dqm->ops.evict_process_queues = evict_process_queues_nocpsch;
dqm->ops.restore_process_queues =
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 16262e5d93f5..aee033b1d148 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
@@ -121,11 +121,6 @@ struct device_queue_manager_ops {
   void __user *alternate_aperture_base,
   uint64_t alternate_aperture_size);
 
-   int (*set_trap_handler)(struct device_queue_manager *dqm,
-   struct qcm_process_device *qpd,
-   uint64_t tba_addr,
-   uint64_t tma_addr);
-
int (*process_termination)(struct device_queue_manager *dqm,
struct qcm_process_device *qpd);
 
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index e2ebd5a1d4de..8f839154bf1f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -944,6 +944,10 @@ bool interrupt_is_wanted(struct kfd_dev *dev,
 /* amdkfd Apertures */
 int kfd_init_apertures(struct kfd_process *process);
 
+void kfd_process_set_trap_handler(struct qcm_process_device *qpd,
+ uint64_t tba_addr,
+ uint64_t tm

Re: [PATCH 1/1] drm/ttm: Ignore signaled move fences

[Felix Kuehling]

Am 2021-03-01 um 10:09 a.m. schrieb Christian König:
> Am 27.02.21 um 04:45 schrieb Felix Kuehling:
>> Move fences that have already signaled should not prevent memory
>> allocations with no_wait_gpu.
>>
>> Signed-off-by: Felix Kuehling 
>
> Reviewed-by: Christian König 

I work on this on Alex's rebased amd-staging-drm-next. Should this go
into any other branches?

Thanks,
  Felix


>
>> ---
>>   drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index 3a10bebb75d6..de1ec838cf8b 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -730,8 +730,9 @@ static int ttm_bo_add_move_fence(struct
>> ttm_buffer_object *bo,
>>   return 0;
>>     if (no_wait_gpu) {
>> +    ret = dma_fence_is_signaled(fence) ? 0 : -EBUSY;
>>   dma_fence_put(fence);
>> -    return -EBUSY;
>> +    return ret;
>>   }
>>     dma_resv_add_shared_fence(bo->base.resv, fence);
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu: Fix some unload driver issues

[Emily Deng]

When unloading driver after killing some applications, it will hit sdma
flush tlb job timeout which is called by ttm_bo_delay_delete. So
to avoid the job submit after fence driver fini, call 
ttm_bo_lock_delayed_workqueue
before fence driver fini. And also put drm_sched_fini before waiting fence.

Set adev->gart.ptr to null to fix null pointer when calling amdgpu_gart_unbind
in amdgpu_bo_fini which is after gart_fini.

Signed-off-by: Emily Deng 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  | 5 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c   | 1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a11760ec3924..de0597d34588 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3594,6 +3594,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
 {
dev_info(adev->dev, "amdgpu: finishing device.\n");
flush_delayed_work(&adev->delayed_init_work);
+   ttm_bo_lock_delayed_workqueue(&adev->mman.bdev);
adev->shutdown = true;
 
kfree(adev->pci_state);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 143a14f4866f..6d16f58ac91e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -531,6 +531,8 @@ void amdgpu_fence_driver_fini(struct amdgpu_device *adev)
 
if (!ring || !ring->fence_drv.initialized)
continue;
+   if (!ring->no_scheduler)
+   drm_sched_fini(&ring->sched);
r = amdgpu_fence_wait_empty(ring);
if (r) {
/* no need to trigger GPU reset as we are unloading */
@@ -539,8 +541,7 @@ void amdgpu_fence_driver_fini(struct amdgpu_device *adev)
if (ring->fence_drv.irq_src)
amdgpu_irq_put(adev, ring->fence_drv.irq_src,
   ring->fence_drv.irq_type);
-   if (!ring->no_scheduler)
-   drm_sched_fini(&ring->sched);
+
del_timer_sync(&ring->fence_drv.fallback_timer);
for (j = 0; j <= ring->fence_drv.num_fences_mask; ++j)
dma_fence_put(ring->fence_drv.fences[j]);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index 23823a57374f..f1ede4b43d07 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -202,6 +202,7 @@ void amdgpu_gart_table_vram_free(struct amdgpu_device *adev)
return;
}
amdgpu_bo_unref(&adev->gart.bo);
+   adev->gart.ptr = NULL;
 }
 
 /*
-- 
2.25.1

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

Re: [PATCH v2 3/3] drm/amdgpu: drm/amdkfd: add amdgpu_kfd_bo struct

[Felix Kuehling]

Am 2021-03-03 um 7:04 a.m. schrieb Christian König:
> Am 03.03.21 um 10:25 schrieb Nirmoy Das:
>> Implement a new struct based on amdgpu_bo base class
>> for BOs created by kfd device so that kfd related memeber
>> of amdgpu_bo can be moved there.
>
> You should probably restructure which patch has which code in it here.
>
> The first one adds the general infrastructure and makes the necessary
> modification to allow allocating BO structures with different
> structure size.
>
> And the second then adds the amdgpu_kfd_bo structure so that the KFD
> can use it.
>
> You should also double check with Felix if we don't support importing
> BOs from elsewhere here and if that approach is correct.

We do support importing graphics BOs into KFD processes.

Regards,
  Felix


>
> Regards,
> Christian.
>
>>
>> v2: rename AMDGPU_GEM_USER_KFD -> AMDGPU_GEM_CREATE_KFD
>>
>> Signed-off-by: Nirmoy Das 
>> ---
>>   .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  | 10 --
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c    |  3 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c    | 32 ++-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.h    |  8 -
>>   4 files changed, 40 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> index 57798707cd5f..1f52ae4de609 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> @@ -1152,6 +1152,7 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
>>   struct sg_table *sg = NULL;
>>   uint64_t user_addr = 0;
>>   struct amdgpu_bo *bo;
>> +    struct amdgpu_kfd_bo *kbo;
>>   struct amdgpu_bo_param bp;
>>   u32 domain, alloc_domain;
>>   u64 alloc_flags;
>> @@ -1227,17 +1228,20 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
>>   bp.flags = alloc_flags;
>>   bp.type = bo_type;
>>   bp.resv = NULL;
>> -    ret = amdgpu_kfd_bo_create(adev, &bp, &bo);
>> +    ret = amdgpu_kfd_bo_create(adev, &bp, &kbo);
>>   if (ret) {
>>   pr_debug("Failed to create BO on domain %s. ret %d\n",
>>   domain_string(alloc_domain), ret);
>>   goto err_bo_create;
>>   }
>> +
>> +    bo = &kbo->bo;
>>   if (bo_type == ttm_bo_type_sg) {
>>   bo->tbo.sg = sg;
>>   bo->tbo.ttm->sg = sg;
>>   }
>> -    bo->kfd_bo = *mem;
>> +
>> +    kbo->kfd_bo = *mem;
>>   (*mem)->bo = bo;
>>   if (user_addr)
>>   bo->flags |= AMDGPU_AMDKFD_USERPTR_BO;
>> @@ -1261,7 +1265,7 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
>>
>>   allocate_init_user_pages_failed:
>>   remove_kgd_mem_from_kfd_bo_list(*mem, avm->process_info);
>> -    amdgpu_bo_unref(&bo);
>> +    amdgpu_kfd_bo_unref(&kbo);
>>   /* Don't unreserve system mem limit twice */
>>   goto err_reserve_limit;
>>   err_bo_create:
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
>> index 1da67cf812b1..eaaf4940abcb 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
>> @@ -102,6 +102,7 @@ static bool amdgpu_mn_invalidate_hsa(struct
>> mmu_interval_notifier *mni,
>>    unsigned long cur_seq)
>>   {
>>   struct amdgpu_bo *bo = container_of(mni, struct amdgpu_bo,
>> notifier);
>> +    struct amdgpu_kfd_bo *kbo = container_of(bo, struct
>> amdgpu_kfd_bo, bo);
>>   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
>>
>>   if (!mmu_notifier_range_blockable(range))
>> @@ -111,7 +112,7 @@ static bool amdgpu_mn_invalidate_hsa(struct
>> mmu_interval_notifier *mni,
>>
>>   mmu_interval_set_seq(mni, cur_seq);
>>
>> -    amdgpu_amdkfd_evict_userptr(bo->kfd_bo, bo->notifier.mm);
>> +    amdgpu_amdkfd_evict_userptr(kbo->kfd_bo, bo->notifier.mm);
>>   mutex_unlock(&adev->notifier_lock);
>>
>>   return true;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> index 1b41b4870c99..787eb99119a2 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> @@ -551,8 +551,10 @@ static int amdgpu_bo_do_create(struct
>> amdgpu_device *adev,
>>
>>   acc_size = ttm_bo_dma_acc_size(&adev->mman.bdev, size,
>>  sizeof(struct amdgpu_bo));
>> +    if (bp->bo_ptr_size < sizeof(struct amdgpu_bo))
>> +    bp->bo_ptr_size = sizeof(struct amdgpu_bo);
>>
>> -    bo = kzalloc(sizeof(struct amdgpu_bo), GFP_KERNEL);
>> +    bo = kzalloc(bp->bo_ptr_size, GFP_KERNEL);
>>   if (bo == NULL)
>>   return -ENOMEM;
>>   drm_gem_private_object_init(adev_to_drm(adev), &bo->tbo.base,
>> size);
>> @@ -714,35 +716,37 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
>>
>>   int amdgpu_kfd_bo_create(struct amdgpu_device *adev,
>>    struct amdgpu_bo_param *bp,
>> - struct amdgpu_bo **bo_ptr)
>> 

Re: [PATCH] drm/amdgpu: add DMUB trace event IRQ source define

[Harry Wentland]

On 2021-03-04 2:43 p.m., Leo (Hanghong) Ma wrote:

[Why & How]
We use DMCUB outbox0 interrupt to log DMCUB trace buffer events
as Linux kernel traces, so need to add some irq source related
defination in the header files;

Signed-off-by: Leo (Hanghong) Ma 


Reviewed-by: Harry Wentland 

Harry


---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 1 +
  drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h | 2 ++
  2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 1624c2bc8285..f01b75ec6c60 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -912,6 +912,7 @@ struct amdgpu_device {
struct amdgpu_irq_src   vupdate_irq;
struct amdgpu_irq_src   pageflip_irq;
struct amdgpu_irq_src   hpd_irq;
+   struct amdgpu_irq_src   dmub_trace_irq;
  
  	/* rings */

u64 fence_context;
diff --git a/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h 
b/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
index ac9fa3a9bd07..e2bffcae273a 100644
--- a/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
+++ b/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
@@ -1130,5 +1130,7 @@
  #define DCN_1_0__SRCID__HUBP6_FLIP_AWAY_INTERRUPT 0x63// Flip_away 
interrupt is generated when all data for old surface is returned and old 
surface is not used again after the surface flip.HUBP6_IHC_FLIP_AWAY_INTERRUPT  
  DISP_INTERRUPT_STATUS_CONTINUE17Level / Pulse
  #define DCN_1_0__SRCID__HUBP7_FLIP_AWAY_INTERRUPT 0x64// Flip_away 
interrupt is generated when all data for old surface is returned and old 
surface is not used again after the surface flip.HUBP7_IHC_FLIP_AWAY_INTERRUPT  
  DISP_INTERRUPT_STATUS_CONTINUE17Level / Pulse
  
+#define DCN_1_0__SRCID__DMCUB_OUTBOX_HIGH_PRIORITY_READY_INT   0x68

+#define DCN_1_0__CTXID__DMCUB_OUTBOX_HIGH_PRIORITY_READY_INT   6
  
  #endif // __IRQSRCS_DCN_1_0_H__



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

Re: PROBLEM: random desktop freezes, kmsg errors "Failed to parse relocation -12" and "failed to pin new rbo buffer before flip"

[Lucas Werkmeister]

I tried the branch for a few hours now and it seems to solve the issue
(including, at least mostly, the “weaker” 5.16 version) – thanks a lot!

Cheers, Lucas

On 04.03.21 12:28, Christian König wrote:
> Hi Lucas,
> 
> that sounds strongly as an known issue. Could you please test the
> drm-misc-fixes branch (https://cgit.freedesktop.org/drm/drm-misc/) and
> see if the problem still occurs?
> 
> Thanks in advance,
> Christian.
> 
> Am 03.03.21 um 21:02 schrieb Lucas Werkmeister:
>> Hi all,
>>
>> on Linux 5.11.1 and 5.11.2 (but not 5.10.16), my Gnome desktop (Radeon
>> R7 260X GPU) occasionally (usually after a few hours) freezes
>> completely; when it happens, I can still switch to a TTY (Ctrl+Alt+F3)
>> and back to the frozen desktop (Ctrl+Alt+F2), but I haven’t found a way
>> to “rescue” the desktop from the command line, and ultimately have to
>> reboot. When that happens, the journal is filled with many copies of
>> these kernel messages:
>>
>>> [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse relocation -12!
>>> radeon :01:00.0: 641f4713 pin failed
>>> [drm:radeon_crtc_page_flip_target [radeon]] *ERROR* failed to pin new
>>> rbo buffer before flip
>> I have uploaded the kernel logs of one affected boot, in systemd journal
>> export format, at
>> .
>>
>>
>> Keywords: drm, radeon, amd, graphics
>>
>> Kernel version:
>> $ cat /proc/version
>> Linux version 5.11.2-arch1-1 (linux@archlinux) (gcc (GCC) 10.2.0, GNU ld
>> (GNU Binutils) 2.36.1) #1 SMP PREEMPT Fri, 26 Feb 2021 18:26:41 +
>>
>> Kernel .config file (from /proc/config.gz):
>> 
>>
>>
>> Most recent kernel version which did not have the bug: 5.10.16 [though
>> this has a similar issue, where the desktop also freezes but then
>> unfreezes either on its own or when I switch to a TTY and back; I
>> haven’t reported this yet, and don’t know if it’s related or not]
>>
>> I have not yet found a way to systematically reproduce this. It seems to
>> happen more frequently when there is more load on the system, or on the
>> graphics card (e.g. fullscreen video playback, desktop recording).
>>
>> ver_linux output:
>>
>> Linux theoden 5.11.2-arch1-1 #1 SMP PREEMPT Fri, 26 Feb 2021 18:26:41
>> + x86_64 GNU/Linux
>>
>> GNU C   10.2.0
>> GNU Make    4.3
>> Binutils    2.36.1
>> Util-linux  2.36.2
>> Mount   2.36.2
>> Module-init-tools   28
>> E2fsprogs   1.46.2
>> Jfsutils    1.1.15
>> Reiserfsprogs   3.6.27
>> Xfsprogs    5.10.0
>> Quota-tools 4.06
>> Bison   3.7.3
>> Flex    2.6.4
>> Linux C++ Library   6.0.28
>> Linux C Library 2.33
>> Dynamic linker (ldd)    2.33
>> Procps  3.3.17
>> Kbd 2.4.0
>> Console-tools   2.4.0
>> Sh-utils    8.32
>> Udev    247
>> Modules Loaded  ac97_bus aesni_intel agpgart amdgpu at24 cbc
>> cdrom cec coretemp crc16 crc32c_generic crc32c_intel crc32_pclmul
>> crct10dif_pclmul cryptd crypto_simd crypto_user dm_bio_prison dm_bufio
>> dm_cache dm_cache_smq dm_crypt dm_mod dm_persistent_data drm
>> drm_kms_helper drm_ttm_helper e1000e encrypted_keys ext4 fat fb_sys_fops
>> fuse ghash_clmulni_intel glue_helper gpu_sched i2c_algo_bit i2c_i801
>> i2c_smbus intel_cstate intel_pmc_bxt intel_powerclamp intel_rapl_common
>> intel_rapl_msr intel_uncore ip_tables irqbypass iTCO_vendor_support
>> iTCO_wdt jbd2 joydev kvm kvm_intel ledtrig_audio libcrc32c lpc_ich
>> mac_hid mbcache mc mei mei_hdcp mei_me mei_wdt mousedev nls_iso8859_1
>> pcspkr radeon rapl rfkill rng_core sg snd snd_compress snd_hda_codec
>> snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec_realtek
>> snd_hda_core snd_hda_intel snd_hwdep snd_intel_dspcfg snd_pcm
>> snd_pcm_dmaengine snd_rawmidi snd_seq_device snd_soc_core snd_timer
>> snd_usb_audio snd_usbmidi_lib soundcore soundwire_bus soundwire_cadence
>> soundwire_generic_allocation soundwire_intel sr_mod syscopyarea
>> sysfillrect sysimgblt tpm trusted ttm uas usbhid usb_storage uvcvideo
>> vfat video videobuf2_common videob

[PATCH] drm/amdgpu: Verify bo size can fit framebuffer size on init.

[Mark Yacoub]

From: Mark Yacoub 

To initialize the framebuffer, use drm_gem_fb_init_with_funcs which
verifies that the BO size can fit the FB size by calculating the minimum
expected size of each plane.

The bug was caught using igt-gpu-tools test: kms_addfb_basic.too-high
and kms_addfb_basic.bo-too-small

Tested on ChromeOS Zork by turning on the display and running a YT
video.

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: Sean Paul 
Signed-off-by: Mark Yacoub 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 66 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h|  8 +++
 3 files changed, 62 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 48cb33e5b3826..554038e5bbf6a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -870,18 +870,59 @@ static int amdgpu_display_get_fb_info(const struct 
amdgpu_framebuffer *amdgpu_fb
return r;
 }
 
-int amdgpu_display_framebuffer_init(struct drm_device *dev,
-   struct amdgpu_framebuffer *rfb,
-   const struct drm_mode_fb_cmd2 *mode_cmd,
-   struct drm_gem_object *obj)
+int amdgpu_display_gem_fb_init(struct drm_device *dev,
+  struct amdgpu_framebuffer *rfb,
+  const struct drm_mode_fb_cmd2 *mode_cmd,
+  struct drm_gem_object *obj)
 {
-   int ret, i;
+   int ret;
rfb->base.obj[0] = obj;
drm_helper_mode_fill_fb_struct(dev, &rfb->base, mode_cmd);
ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs);
if (ret)
-   goto fail;
+   goto err;
+
+   ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj);
+   if (ret)
+   goto err;
+
+   return 0;
+err:
+   drm_err(dev, "Failed to init gem fb: %d\n", ret);
+   rfb->base.obj[0] = NULL;
+   return ret;
+}
+
+int amdgpu_display_gem_fb_verify_and_init(
+   struct drm_device *dev, struct amdgpu_framebuffer *rfb,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
+   struct drm_gem_object *obj)
+{
+   int ret;
+   rfb->base.obj[0] = obj;
+   // Verify that bo size can fit the fb size.
+   ret = drm_gem_fb_init_with_funcs(dev, &rfb->base, file_priv, mode_cmd,
+&amdgpu_fb_funcs);
+   if (ret)
+   goto err;
 
+   ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj);
+   if (ret)
+   goto err;
+
+   return 0;
+err:
+   drm_err(dev, "Failed to verify and init gem fb: %d\n", ret);
+   rfb->base.obj[0] = NULL;
+   return ret;
+}
+
+int amdgpu_display_framebuffer_init(struct drm_device *dev,
+   struct amdgpu_framebuffer *rfb,
+   const struct drm_mode_fb_cmd2 *mode_cmd,
+   struct drm_gem_object *obj)
+{
+   int ret, i;
/*
 * This needs to happen before modifier conversion as that might change
 * the number of planes.
@@ -891,13 +932,13 @@ int amdgpu_display_framebuffer_init(struct drm_device 
*dev,
drm_dbg_kms(dev, "Plane 0 and %d have different BOs: %u 
vs. %u\n",
i, mode_cmd->handles[0], 
mode_cmd->handles[i]);
ret = -EINVAL;
-   goto fail;
+   return ret;
}
}
 
ret = amdgpu_display_get_fb_info(rfb, &rfb->tiling_flags, 
&rfb->tmz_surface);
if (ret)
-   goto fail;
+   return ret;
 
if (dev->mode_config.allow_fb_modifiers &&
!(rfb->base.flags & DRM_MODE_FB_MODIFIERS)) {
@@ -905,7 +946,7 @@ int amdgpu_display_framebuffer_init(struct drm_device *dev,
if (ret) {
drm_dbg_kms(dev, "Failed to convert tiling flags 0x%llX 
to a modifier",
rfb->tiling_flags);
-   goto fail;
+   return ret;
}
}
 
@@ -915,10 +956,6 @@ int amdgpu_display_framebuffer_init(struct drm_device *dev,
}
 
return 0;
-
-fail:
-   rfb->base.obj[0] = NULL;
-   return ret;
 }
 
 struct drm_framebuffer *
@@ -953,7 +990,8 @@ amdgpu_display_user_framebuffer_create(struct drm_device 
*dev,
return ERR_PTR(-ENOMEM);
}
 
-   ret = amdgpu_display_framebuffer_init(dev, amdgpu_fb, mode_cmd, obj);
+   ret = amdgpu_display_gem_fb_verify_and_init(dev, amdgpu_fb, file_priv,
+   mode_cmd, obj);
if (ret) {
kfree(amdgpu_fb);
drm_gem_object_pu

[PATCH] drm/amdkfd: Fix UBSAN shift-out-of-bounds warning

[Anson Jacob]

If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up
doing a shift operation where the number of bits shifted equals
number of bits in the operand. This behaviour is undefined.

Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the
count is >= number of bits in the operand.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472
Reported-by: Lyude Paul 
Signed-off-by: Anson Jacob 
Reviewed-by: Alex Deucher 
Reviewed-by: Felix Kuehling 
---
 .../drm/amd/amdkfd/kfd_device_queue_manager.c   | 17 +++--
 1 file changed, 15 insertions(+), 2 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 c37e9c4b1fb4..e7a3c496237f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -1128,6 +1128,9 @@ static int set_sched_resources(struct 
device_queue_manager *dqm)
 
 static int initialize_cpsch(struct device_queue_manager *dqm)
 {
+   uint64_t num_sdma_queues;
+   uint64_t num_xgmi_sdma_queues;
+
pr_debug("num of pipes: %d\n", get_pipes_per_mec(dqm));
 
mutex_init(&dqm->lock_hidden);
@@ -1136,8 +1139,18 @@ static int initialize_cpsch(struct device_queue_manager 
*dqm)
dqm->active_cp_queue_count = 0;
dqm->gws_queue_count = 0;
dqm->active_runlist = false;
-   dqm->sdma_bitmap = ~0ULL >> (64 - get_num_sdma_queues(dqm));
-   dqm->xgmi_sdma_bitmap = ~0ULL >> (64 - get_num_xgmi_sdma_queues(dqm));
+
+   num_sdma_queues = get_num_sdma_queues(dqm);
+   if (num_sdma_queues >= BITS_PER_TYPE(dqm->sdma_bitmap))
+   dqm->sdma_bitmap = ULLONG_MAX;
+   else
+   dqm->sdma_bitmap = (BIT_ULL(num_sdma_queues) - 1);
+
+   num_xgmi_sdma_queues = get_num_xgmi_sdma_queues(dqm);
+   if (num_xgmi_sdma_queues >= BITS_PER_TYPE(dqm->xgmi_sdma_bitmap))
+   dqm->xgmi_sdma_bitmap = ULLONG_MAX;
+   else
+   dqm->xgmi_sdma_bitmap = (BIT_ULL(num_xgmi_sdma_queues) - 1);
 
INIT_WORK(&dqm->hw_exception_work, kfd_process_hw_exception);
 
-- 
2.25.1

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

[PATCH] drm/amdgpu: add DMUB trace event IRQ source define

[Leo (Hanghong) Ma]

[Why & How]
We use DMCUB outbox0 interrupt to log DMCUB trace buffer events
as Linux kernel traces, so need to add some irq source related
defination in the header files;

Signed-off-by: Leo (Hanghong) Ma 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 1 +
 drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 1624c2bc8285..f01b75ec6c60 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -912,6 +912,7 @@ struct amdgpu_device {
struct amdgpu_irq_src   vupdate_irq;
struct amdgpu_irq_src   pageflip_irq;
struct amdgpu_irq_src   hpd_irq;
+   struct amdgpu_irq_src   dmub_trace_irq;
 
/* rings */
u64 fence_context;
diff --git a/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h 
b/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
index ac9fa3a9bd07..e2bffcae273a 100644
--- a/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
+++ b/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
@@ -1130,5 +1130,7 @@
 #define DCN_1_0__SRCID__HUBP6_FLIP_AWAY_INTERRUPT  0x63// Flip_away 
interrupt is generated when all data for old surface is returned and old 
surface is not used again after the surface flip.HUBP6_IHC_FLIP_AWAY_INTERRUPT  
  DISP_INTERRUPT_STATUS_CONTINUE17Level / Pulse
 #define DCN_1_0__SRCID__HUBP7_FLIP_AWAY_INTERRUPT  0x64// Flip_away 
interrupt is generated when all data for old surface is returned and old 
surface is not used again after the surface flip.HUBP7_IHC_FLIP_AWAY_INTERRUPT  
  DISP_INTERRUPT_STATUS_CONTINUE17Level / Pulse
 
+#define DCN_1_0__SRCID__DMCUB_OUTBOX_HIGH_PRIORITY_READY_INT   0x68
+#define DCN_1_0__CTXID__DMCUB_OUTBOX_HIGH_PRIORITY_READY_INT   6
 
 #endif // __IRQSRCS_DCN_1_0_H__
-- 
2.17.1

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

RE: [PATCH] Revert "drm/amdgpu: add DMUB trace event IRQ source define"

[Ma, Hanghong]

[AMD Official Use Only - Internal Distribution Only]

Apologies for the noise, and please ignore this one.

Thanks

-Original Message-
From: Leo (Hanghong) Ma 
Sent: Thursday, March 4, 2021 2:31 PM
To: Siqueira, Rodrigo ; amd-gfx@lists.freedesktop.org
Cc: Wentland, Harry ; Ma, Hanghong 
Subject: [PATCH] Revert "drm/amdgpu: add DMUB trace event IRQ source define"

This reverts commit 3590cb311815b3f82af04e2ff1f182ca919af3d3.
The patch is applyed mistakenly before code review.
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 1 -
 drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index f01b75ec6c60..1624c2bc8285 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -912,7 +912,6 @@ struct amdgpu_device {
 struct amdgpu_irq_srcvupdate_irq;
 struct amdgpu_irq_srcpageflip_irq;
 struct amdgpu_irq_srchpd_irq;
-struct amdgpu_irq_srcdmub_trace_irq;

 /* rings */
 u64fence_context;
diff --git a/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h 
b/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
index e2bffcae273a..ac9fa3a9bd07 100644
--- a/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
+++ b/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
@@ -1130,7 +1130,5 @@
 #define DCN_1_0__SRCID__HUBP6_FLIP_AWAY_INTERRUPT0x63// Flip_away interrupt is 
generated when all data for old surface is returned and old surface is not used 
again after the surface 
flip.HUBP6_IHC_FLIP_AWAY_INTERRUPTDISP_INTERRUPT_STATUS_CONTINUE17Level / Pulse
 #define DCN_1_0__SRCID__HUBP7_FLIP_AWAY_INTERRUPT0x64// Flip_away interrupt is 
generated when all data for old surface is returned and old surface is not used 
again after the surface 
flip.HUBP7_IHC_FLIP_AWAY_INTERRUPTDISP_INTERRUPT_STATUS_CONTINUE17Level / Pulse

-#define DCN_1_0__SRCID__DMCUB_OUTBOX_HIGH_PRIORITY_READY_INT   0x68
-#define DCN_1_0__CTXID__DMCUB_OUTBOX_HIGH_PRIORITY_READY_INT   6

 #endif // __IRQSRCS_DCN_1_0_H__
--
2.17.1

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

[PATCH] Revert "drm/amdgpu: add DMUB trace event IRQ source define"

[Leo (Hanghong) Ma]

This reverts commit 3590cb311815b3f82af04e2ff1f182ca919af3d3.
The patch is applyed mistakenly before code review.
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 1 -
 drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index f01b75ec6c60..1624c2bc8285 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -912,7 +912,6 @@ struct amdgpu_device {
struct amdgpu_irq_src   vupdate_irq;
struct amdgpu_irq_src   pageflip_irq;
struct amdgpu_irq_src   hpd_irq;
-   struct amdgpu_irq_src   dmub_trace_irq;
 
/* rings */
u64 fence_context;
diff --git a/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h 
b/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
index e2bffcae273a..ac9fa3a9bd07 100644
--- a/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
+++ b/drivers/gpu/drm/amd/include/ivsrcid/dcn/irqsrcs_dcn_1_0.h
@@ -1130,7 +1130,5 @@
 #define DCN_1_0__SRCID__HUBP6_FLIP_AWAY_INTERRUPT  0x63// Flip_away 
interrupt is generated when all data for old surface is returned and old 
surface is not used again after the surface flip.HUBP6_IHC_FLIP_AWAY_INTERRUPT  
  DISP_INTERRUPT_STATUS_CONTINUE17Level / Pulse
 #define DCN_1_0__SRCID__HUBP7_FLIP_AWAY_INTERRUPT  0x64// Flip_away 
interrupt is generated when all data for old surface is returned and old 
surface is not used again after the surface flip.HUBP7_IHC_FLIP_AWAY_INTERRUPT  
  DISP_INTERRUPT_STATUS_CONTINUE17Level / Pulse
 
-#define DCN_1_0__SRCID__DMCUB_OUTBOX_HIGH_PRIORITY_READY_INT   0x68
-#define DCN_1_0__CTXID__DMCUB_OUTBOX_HIGH_PRIORITY_READY_INT   6
 
 #endif // __IRQSRCS_DCN_1_0_H__
-- 
2.17.1

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

Re: [PATCH] drm/ttm: ioremap buffer according to TTM mem caching setting

[kernel test robot]

Hi Oak,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip linus/master v5.12-rc1 next-20210304]
[cannot apply to tegra-drm/drm/tegra/for-next drm-exynos/exynos-drm-next 
drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Oak-Zeng/drm-ttm-ioremap-buffer-according-to-TTM-mem-caching-setting/20210305-000626
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/e89ba86e56d95eb097cacfac83b667a92acbf56b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Oak-Zeng/drm-ttm-ioremap-buffer-according-to-TTM-mem-caching-setting/20210305-000626
git checkout e89ba86e56d95eb097cacfac83b667a92acbf56b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_vmap':
>> drivers/gpu/drm/ttm/ttm_bo_util.c:508:3: error: expected expression before 
>> 'else'
 508 |   else
 |   ^~~~


vim +/else +508 drivers/gpu/drm/ttm/ttm_bo_util.c

ba4e7d973dd09b Thomas Hellstrom  2009-06-10  485  
43676605f890b2 Thomas Zimmermann 2020-11-03  486  int ttm_bo_vmap(struct 
ttm_buffer_object *bo, struct dma_buf_map *map)
43676605f890b2 Thomas Zimmermann 2020-11-03  487  {
43676605f890b2 Thomas Zimmermann 2020-11-03  488struct ttm_resource 
*mem = &bo->mem;
43676605f890b2 Thomas Zimmermann 2020-11-03  489int ret;
43676605f890b2 Thomas Zimmermann 2020-11-03  490  
43676605f890b2 Thomas Zimmermann 2020-11-03  491ret = 
ttm_mem_io_reserve(bo->bdev, mem);
43676605f890b2 Thomas Zimmermann 2020-11-03  492if (ret)
43676605f890b2 Thomas Zimmermann 2020-11-03  493return ret;
43676605f890b2 Thomas Zimmermann 2020-11-03  494  
43676605f890b2 Thomas Zimmermann 2020-11-03  495if (mem->bus.is_iomem) {
43676605f890b2 Thomas Zimmermann 2020-11-03  496void __iomem 
*vaddr_iomem;
43676605f890b2 Thomas Zimmermann 2020-11-03  497  
43676605f890b2 Thomas Zimmermann 2020-11-03  498if 
(mem->bus.addr)
43676605f890b2 Thomas Zimmermann 2020-11-03  499
vaddr_iomem = (void __iomem *)mem->bus.addr;
43676605f890b2 Thomas Zimmermann 2020-11-03  500else if 
(mem->bus.caching == ttm_write_combined)
e11bfb99d6ece2 Christian König   2020-12-09  501
vaddr_iomem = ioremap_wc(mem->bus.offset,
e11bfb99d6ece2 Christian König   2020-12-09  502
 bo->base.size);
e89ba86e56d95e Oak Zeng  2021-03-04  503else if 
(mem->bus.caching == ttm_cached)
e89ba86e56d95e Oak Zeng  2021-03-04  504  #ifdef CONFIG_X86
e89ba86e56d95e Oak Zeng  2021-03-04  505
vaddr_iomem = ioremap_cache(mem->bus.offset,
e89ba86e56d95e Oak Zeng  2021-03-04  506
  bo->base.size);
e89ba86e56d95e Oak Zeng  2021-03-04  507  #endif
43676605f890b2 Thomas Zimmermann 2020-11-03 @508else
e11bfb99d6ece2 Christian König   2020-12-09  509
vaddr_iomem = ioremap(mem->bus.offset, bo->base.size);
43676605f890b2 Thomas Zimmermann 2020-11-03  510  
43676605f890b2 Thomas Zimmermann 2020-11-03  511if 
(!vaddr_iomem)
43676605f890b2 Thomas Zimmermann 2020-11-03  512return 
-ENOMEM;
43676605f890b2 Thomas Zimmermann 2020-11-03  513  
43676605f890b2 Thomas Zimmermann 2020-11-03  514
dma_buf_map_set_vaddr_iomem(map, vaddr_iomem);
43676605f890b2 Thomas Zimmermann 2020-11-03  515  
43676605f890b2 Thomas Zimmermann 2020-11-03  516} else {
43676605f890b2 Thomas Zimmermann 2020-11-03  517struct 
ttm_operation_ctx ctx = {
43676605f890b2 Thomas Zimmermann 2020-11-03  518
.interruptible = false,
43676605f890b2 Thomas Zimmermann 2020-11-03  519
.no_wait_gpu = false
43676605f890b2 Thomas Zimmermann 2020-11-03  520};
43676605f890b2 Thomas Zimmermann 2020-11-03  521struct ttm_tt 
*ttm = bo->ttm;

Re: [PATCH] drm/ttm: ioremap buffer according to TTM mem caching setting

[kernel test robot]

Hi Oak,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip linus/master v5.12-rc1 next-20210304]
[cannot apply to tegra-drm/drm/tegra/for-next drm-exynos/exynos-drm-next 
drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Oak-Zeng/drm-ttm-ioremap-buffer-according-to-TTM-mem-caching-setting/20210305-000626
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: arm64-randconfig-r021-20210304 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
eec7f8f7b1226be422a76542cb403d02538f453a)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/e89ba86e56d95eb097cacfac83b667a92acbf56b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Oak-Zeng/drm-ttm-ioremap-buffer-according-to-TTM-mem-caching-setting/20210305-000626
git checkout e89ba86e56d95eb097cacfac83b667a92acbf56b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/ttm/ttm_bo_util.c:508:3: error: expected expression
   else
   ^
   1 error generated.


vim +508 drivers/gpu/drm/ttm/ttm_bo_util.c

ba4e7d973dd09b66 Thomas Hellstrom  2009-06-10  485  
43676605f890b218 Thomas Zimmermann 2020-11-03  486  int ttm_bo_vmap(struct 
ttm_buffer_object *bo, struct dma_buf_map *map)
43676605f890b218 Thomas Zimmermann 2020-11-03  487  {
43676605f890b218 Thomas Zimmermann 2020-11-03  488  struct ttm_resource 
*mem = &bo->mem;
43676605f890b218 Thomas Zimmermann 2020-11-03  489  int ret;
43676605f890b218 Thomas Zimmermann 2020-11-03  490  
43676605f890b218 Thomas Zimmermann 2020-11-03  491  ret = 
ttm_mem_io_reserve(bo->bdev, mem);
43676605f890b218 Thomas Zimmermann 2020-11-03  492  if (ret)
43676605f890b218 Thomas Zimmermann 2020-11-03  493  return ret;
43676605f890b218 Thomas Zimmermann 2020-11-03  494  
43676605f890b218 Thomas Zimmermann 2020-11-03  495  if (mem->bus.is_iomem) {
43676605f890b218 Thomas Zimmermann 2020-11-03  496  void __iomem 
*vaddr_iomem;
43676605f890b218 Thomas Zimmermann 2020-11-03  497  
43676605f890b218 Thomas Zimmermann 2020-11-03  498  if 
(mem->bus.addr)
43676605f890b218 Thomas Zimmermann 2020-11-03  499  
vaddr_iomem = (void __iomem *)mem->bus.addr;
43676605f890b218 Thomas Zimmermann 2020-11-03  500  else if 
(mem->bus.caching == ttm_write_combined)
e11bfb99d6ece23b Christian König   2020-12-09  501  
vaddr_iomem = ioremap_wc(mem->bus.offset,
e11bfb99d6ece23b Christian König   2020-12-09  502  
 bo->base.size);
e89ba86e56d95eb0 Oak Zeng  2021-03-04  503  else if 
(mem->bus.caching == ttm_cached)
e89ba86e56d95eb0 Oak Zeng  2021-03-04  504  #ifdef CONFIG_X86
e89ba86e56d95eb0 Oak Zeng  2021-03-04  505  
vaddr_iomem = ioremap_cache(mem->bus.offset,
e89ba86e56d95eb0 Oak Zeng  2021-03-04  506  
  bo->base.size);
e89ba86e56d95eb0 Oak Zeng  2021-03-04  507  #endif
43676605f890b218 Thomas Zimmermann 2020-11-03 @508  else
e11bfb99d6ece23b Christian König   2020-12-09  509  
vaddr_iomem = ioremap(mem->bus.offset, bo->base.size);
43676605f890b218 Thomas Zimmermann 2020-11-03  510  
43676605f890b218 Thomas Zimmermann 2020-11-03  511  if 
(!vaddr_iomem)
43676605f890b218 Thomas Zimmermann 2020-11-03  512  return 
-ENOMEM;
43676605f890b218 Thomas Zimmermann 2020-11-03  513  
43676605f890b218 Thomas Zimmermann 2020-11-03  514  
dma_buf_map_set_vaddr_iomem(map, vaddr_iomem);
43676605f890b218 Thomas Zimmermann 2020-11-03  515  
43676605f890b218 Thomas Zimmermann 2020-11-03  516  } else {
43676605f890b218 Thomas Zimmermann 2020-11-03  517  struct 
ttm_operation_ctx ctx = {
43676605f890b218 Thomas Zimmermann 2020-11-03  518  
.interruptible = false,
43676605f890b218 Thomas Zimmermann 2020-11-03  519  
.no_wait_gpu = false
43676605f890b218 Thomas Z

Re: [PATCH] drm/ttm: ioremap buffer according to TTM mem caching setting

[Christian König]

Am 04.03.21 um 18:40 schrieb Bhardwaj, Rajneesh:


On 3/4/2021 12:31 PM, Christian König wrote:

[CAUTION: External Email]

Am 04.03.21 um 18:01 schrieb Bhardwaj, Rajneesh:

I was wondering if a managed version of such API exists but looks like
none. We only have devm_ioremap_wc but that is valid only for
PAGE_CACHE_MODE_WC whereas ioremap_cache uses _WB. One more small
comment below.


Acked-by: Rajneesh Bhardwaj 

On 3/4/2021 11:04 AM, Oak Zeng wrote:

If tbo.mem.bus.caching is cached, buffer is intended to be mapped
as cached from CPU. Map it with ioremap_cache.

This wasn't necessary before as device memory was never mapped
as cached from CPU side. It becomes necessary for aldebaran as
device memory is mapped cached from CPU.

Signed-off-by: Oak Zeng 
Reviewed-by: Christian Konig 
---
  drivers/gpu/drm/ttm/ttm_bo_util.c | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 031e581..7429464 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -91,6 +91,10 @@ static int ttm_resource_ioremap(struct ttm_device
*bdev,
    if (mem->bus.caching == ttm_write_combined)
  addr = ioremap_wc(mem->bus.offset, bus_size);
+#ifdef CONFIG_X86



Please use #if defined (CONFIG_X86)


Actually #ifdef is usually preferred.


oops, i was referring to IS_ENABLED (CONFIG) and not if defined.


Well, that is indeed a good idea for most config options.

But in this case #ifdef alone should work as well.

Christian.






Christian.




+    else if (mem->bus.caching == ttm_cached)
+    addr = ioremap_cache(mem->bus.offset, bus_size);
+#endif
  else
  addr = ioremap(mem->bus.offset, bus_size);
  if (!addr) {
@@ -372,6 +376,11 @@ static int ttm_bo_ioremap(struct
ttm_buffer_object *bo,
  if (mem->bus.caching == ttm_write_combined)
  map->virtual = ioremap_wc(bo->mem.bus.offset + offset,
    size);
+#ifdef CONFIG_X86
+    else if (mem->bus.caching == ttm_cached)
+    map->virtual = ioremap_cache(bo->mem.bus.offset + offset,
+  size);
+#endif
  else
  map->virtual = ioremap(bo->mem.bus.offset + offset,
 size);
@@ -490,6 +499,11 @@ int ttm_bo_vmap(struct ttm_buffer_object *bo,
struct dma_buf_map *map)
  else if (mem->bus.caching == ttm_write_combined)
  vaddr_iomem = ioremap_wc(mem->bus.offset,
   bo->base.size);
+    else if (mem->bus.caching == ttm_cached)
+#ifdef CONFIG_X86
+    vaddr_iomem = ioremap_cache(mem->bus.offset,
+  bo->base.size);
+#endif
  else
  vaddr_iomem = ioremap(mem->bus.offset, bo->base.size);

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Crajneesh.bhardwaj%40amd.com%7Cc4386544ea10487d3a0c08d8df3363a1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637504759264793970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nM2UtQQdActyapfZSrhfx%2BoJ%2BdszV4Yp62LTehsUWwY%3D&reserved=0 





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

Re: [PATCH] drm/ttm: ioremap buffer according to TTM mem caching setting

[Christian König]

Am 04.03.21 um 18:01 schrieb Bhardwaj, Rajneesh:
I was wondering if a managed version of such API exists but looks like 
none. We only have devm_ioremap_wc but that is valid only for 
PAGE_CACHE_MODE_WC whereas ioremap_cache uses _WB. One more small 
comment below.



Acked-by: Rajneesh Bhardwaj 

On 3/4/2021 11:04 AM, Oak Zeng wrote:

If tbo.mem.bus.caching is cached, buffer is intended to be mapped
as cached from CPU. Map it with ioremap_cache.

This wasn't necessary before as device memory was never mapped
as cached from CPU side. It becomes necessary for aldebaran as
device memory is mapped cached from CPU.

Signed-off-by: Oak Zeng 
Reviewed-by: Christian Konig 
---
  drivers/gpu/drm/ttm/ttm_bo_util.c | 14 ++
  1 file changed, 14 insertions(+)

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

index 031e581..7429464 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -91,6 +91,10 @@ static int ttm_resource_ioremap(struct ttm_device 
*bdev,

    if (mem->bus.caching == ttm_write_combined)
  addr = ioremap_wc(mem->bus.offset, bus_size);
+#ifdef CONFIG_X86



Please use #if defined (CONFIG_X86)


Actually #ifdef is usually preferred.

Christian.




+    else if (mem->bus.caching == ttm_cached)
+    addr = ioremap_cache(mem->bus.offset, bus_size);
+#endif
  else
  addr = ioremap(mem->bus.offset, bus_size);
  if (!addr) {
@@ -372,6 +376,11 @@ static int ttm_bo_ioremap(struct 
ttm_buffer_object *bo,

  if (mem->bus.caching == ttm_write_combined)
  map->virtual = ioremap_wc(bo->mem.bus.offset + offset,
    size);
+#ifdef CONFIG_X86
+    else if (mem->bus.caching == ttm_cached)
+    map->virtual = ioremap_cache(bo->mem.bus.offset + offset,
+  size);
+#endif
  else
  map->virtual = ioremap(bo->mem.bus.offset + offset,
 size);
@@ -490,6 +499,11 @@ int ttm_bo_vmap(struct ttm_buffer_object *bo, 
struct dma_buf_map *map)

  else if (mem->bus.caching == ttm_write_combined)
  vaddr_iomem = ioremap_wc(mem->bus.offset,
   bo->base.size);
+    else if (mem->bus.caching == ttm_cached)
+#ifdef CONFIG_X86
+    vaddr_iomem = ioremap_cache(mem->bus.offset,
+  bo->base.size);
+#endif
  else
  vaddr_iomem = ioremap(mem->bus.offset, bo->base.size);

___
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/ttm: ioremap buffer according to TTM mem caching setting

[Bhardwaj, Rajneesh]

On 3/4/2021 12:31 PM, Christian König wrote:

[CAUTION: External Email]

Am 04.03.21 um 18:01 schrieb Bhardwaj, Rajneesh:

I was wondering if a managed version of such API exists but looks like
none. We only have devm_ioremap_wc but that is valid only for
PAGE_CACHE_MODE_WC whereas ioremap_cache uses _WB. One more small
comment below.


Acked-by: Rajneesh Bhardwaj 

On 3/4/2021 11:04 AM, Oak Zeng wrote:

If tbo.mem.bus.caching is cached, buffer is intended to be mapped
as cached from CPU. Map it with ioremap_cache.

This wasn't necessary before as device memory was never mapped
as cached from CPU side. It becomes necessary for aldebaran as
device memory is mapped cached from CPU.

Signed-off-by: Oak Zeng 
Reviewed-by: Christian Konig 
---
  drivers/gpu/drm/ttm/ttm_bo_util.c | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 031e581..7429464 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -91,6 +91,10 @@ static int ttm_resource_ioremap(struct ttm_device
*bdev,
    if (mem->bus.caching == ttm_write_combined)
  addr = ioremap_wc(mem->bus.offset, bus_size);
+#ifdef CONFIG_X86



Please use #if defined (CONFIG_X86)


Actually #ifdef is usually preferred.


oops, i was referring to IS_ENABLED (CONFIG) and not if defined.




Christian.




+    else if (mem->bus.caching == ttm_cached)
+    addr = ioremap_cache(mem->bus.offset, bus_size);
+#endif
  else
  addr = ioremap(mem->bus.offset, bus_size);
  if (!addr) {
@@ -372,6 +376,11 @@ static int ttm_bo_ioremap(struct
ttm_buffer_object *bo,
  if (mem->bus.caching == ttm_write_combined)
  map->virtual = ioremap_wc(bo->mem.bus.offset + offset,
    size);
+#ifdef CONFIG_X86
+    else if (mem->bus.caching == ttm_cached)
+    map->virtual = ioremap_cache(bo->mem.bus.offset + offset,
+  size);
+#endif
  else
  map->virtual = ioremap(bo->mem.bus.offset + offset,
 size);
@@ -490,6 +499,11 @@ int ttm_bo_vmap(struct ttm_buffer_object *bo,
struct dma_buf_map *map)
  else if (mem->bus.caching == ttm_write_combined)
  vaddr_iomem = ioremap_wc(mem->bus.offset,
   bo->base.size);
+    else if (mem->bus.caching == ttm_cached)
+#ifdef CONFIG_X86
+    vaddr_iomem = ioremap_cache(mem->bus.offset,
+  bo->base.size);
+#endif
  else
  vaddr_iomem = ioremap(mem->bus.offset, bo->base.size);

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Crajneesh.bhardwaj%40amd.com%7Cc4386544ea10487d3a0c08d8df3363a1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637504759264793970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nM2UtQQdActyapfZSrhfx%2BoJ%2BdszV4Yp62LTehsUWwY%3D&reserved=0 




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

Re: [PATCH 2/4] drm/amdgpu/display: don't assert in set backlight function

[Kazlauskas, Nicholas]

On 2021-03-04 1:41 p.m., Alex Deucher wrote:

On Thu, Mar 4, 2021 at 1:33 PM Kazlauskas, Nicholas
 wrote:


On 2021-03-04 12:41 p.m., Alex Deucher wrote:

It just spams the logs.

Signed-off-by: Alex Deucher 


This series in general looks reasonable to me:
Reviewed-by: Nicholas Kazlauskas 


---
   drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 -
   1 file changed, 1 deletion(-)

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 fa9a62dc174b..974b70f21837 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2614,7 +2614,6 @@ bool dc_link_set_backlight_level(const struct dc_link 
*link,
   if (pipe_ctx->plane_state == NULL)
   frame_ramp = 0;
   } else {
- ASSERT(false);


Just a comment on what's actually going on here with this warning:

Technically we can't apply the backlight level without a plane_state in
the context but the panel is also off anyway.

I think there might be a bug here when the panel turns on and we're not
applying values set when it was off but I don't think anyone's reported
this as an issue.

I'm not entirely sure if the value gets cached and reapplied with the
correct value later, but it's something to keep in mind.


It doesn't.  I have additional patches here to cache it:
https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agd5f%2Flinux%2Flog%2F%3Fh%3Dbacklight_wip&data=04%7C01%7Cnicholas.kazlauskas%40amd.com%7Cf259e9290b0e4ffbc87308d8df3d3121%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637504801203988045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4ROSclecKkfu2km3YeeM7sZK%2FP%2BcC8BajHSxJXQQCRw%3D&reserved=0

Alex


That's aligned with my expectations then.

I can take a peek at the branch and help review the patches.

Regards,
Nicholas Kazlauskas





Regards,
Nicholas Kazlauskas


   return false;
   }




___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Cnicholas.kazlauskas%40amd.com%7Cf259e9290b0e4ffbc87308d8df3d3121%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637504801203988045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BbwO5oOXuXFWD%2F8qNTygROj%2B9ZItRsXJb1U7ilcICh4%3D&reserved=0


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

Re: [PATCH 2/4] drm/amdgpu/display: don't assert in set backlight function

[Alex Deucher]

On Thu, Mar 4, 2021 at 1:33 PM Kazlauskas, Nicholas
 wrote:
>
> On 2021-03-04 12:41 p.m., Alex Deucher wrote:
> > It just spams the logs.
> >
> > Signed-off-by: Alex Deucher 
>
> This series in general looks reasonable to me:
> Reviewed-by: Nicholas Kazlauskas 
>
> > ---
> >   drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 -
> >   1 file changed, 1 deletion(-)
> >
> > 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 fa9a62dc174b..974b70f21837 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > @@ -2614,7 +2614,6 @@ bool dc_link_set_backlight_level(const struct dc_link 
> > *link,
> >   if (pipe_ctx->plane_state == NULL)
> >   frame_ramp = 0;
> >   } else {
> > - ASSERT(false);
>
> Just a comment on what's actually going on here with this warning:
>
> Technically we can't apply the backlight level without a plane_state in
> the context but the panel is also off anyway.
>
> I think there might be a bug here when the panel turns on and we're not
> applying values set when it was off but I don't think anyone's reported
> this as an issue.
>
> I'm not entirely sure if the value gets cached and reapplied with the
> correct value later, but it's something to keep in mind.

It doesn't.  I have additional patches here to cache it:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=backlight_wip

Alex

>
> Regards,
> Nicholas Kazlauskas
>
> >   return false;
> >   }
> >
> >
>
> ___
> 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/4] drm/amdgpu/display: don't assert in set backlight function

[Kazlauskas, Nicholas]

On 2021-03-04 12:41 p.m., Alex Deucher wrote:

It just spams the logs.

Signed-off-by: Alex Deucher 


This series in general looks reasonable to me:
Reviewed-by: Nicholas Kazlauskas 


---
  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 -
  1 file changed, 1 deletion(-)

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 fa9a62dc174b..974b70f21837 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2614,7 +2614,6 @@ bool dc_link_set_backlight_level(const struct dc_link 
*link,
if (pipe_ctx->plane_state == NULL)
frame_ramp = 0;
} else {
-   ASSERT(false);


Just a comment on what's actually going on here with this warning:

Technically we can't apply the backlight level without a plane_state in 
the context but the panel is also off anyway.


I think there might be a bug here when the panel turns on and we're not 
applying values set when it was off but I don't think anyone's reported 
this as an issue.


I'm not entirely sure if the value gets cached and reapplied with the 
correct value later, but it's something to keep in mind.


Regards,
Nicholas Kazlauskas


return false;
}
  



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

Re: [PATCH 3/6] amd/display: fail on cursor plane without an underlying plane

[Kazlauskas, Nicholas]

On 2021-03-04 10:35 a.m., Michel Dänzer wrote:

On 2021-03-04 4:09 p.m., Kazlauskas, Nicholas wrote:

On 2021-03-04 4:05 a.m., Michel Dänzer wrote:

On 2021-03-03 8:17 p.m., Daniel Vetter wrote:

On Wed, Mar 3, 2021 at 5:53 PM Michel Dänzer  wrote:


Moreover, in the same scenario plus an overlay plane enabled with a
HW cursor compatible format, if the FB bound to the overlay plane is
destroyed, the common DRM code will attempt to disable the overlay
plane, but dm_check_crtc_cursor will reject that now. I can't remember
exactly what the result is, but AFAIR it's not pretty.


CRTC gets disabled instead. That's why we went with the "always
require primary plane" hack. I think the only solution here would be
to enable the primary plane (but not in userspace-visible state, so
this needs to be done in the dc derived state objects only) that scans
out black any time we're in such a situation with cursor with no
planes.


This is about a scenario described by Nicholas earlier:

Cursor Plane - ARGB

Overlay Plane - ARGB Desktop/UI with cutout for video

Primary Plane - NV12 video

And destroying the FB bound to the overlay plane. The fallback to disable
the CRTC in atomic_remove_fb only kicks in for the primary plane, so it
wouldn't in this case and would fail. Which would in turn trigger the
WARN in drm_framebuffer_remove (and leave the overlay plane scanning out
from freed memory?).


The cleanest solution might be not to allow any formats incompatible with
the HW cursor for the primary plane.


Legacy X userspace doesn't use overlays but Chrome OS does.

This would regress ChromeOS MPO support because it relies on the NV12
video plane being on the bottom.


Could it use the NV12 overlay plane below the ARGB primary plane?


Plane ordering was previously undefined in DRM so we have userspace that 
assumes overlays are on top.


Today we have the z-order property in DRM that defines where it is in 
the stack, so technically it could but we'd also be regressing existing 
behavior on Chrome OS today.






When ChromeOS disables MPO it doesn't do it plane by plane, it does it
in one go from NV12+ARGB -> ARGB8.


Even so, we cannot expect all user space to do the same, and we cannot
allow any user space to trigger a WARN and scanout from freed memory.




The WARN doesn't trigger because there's still a reference on the FB - 
the reference held by DRM since it's still scanning out the overlay. 
Userspace can't reclaim this memory with another buffer allocation 
because it's still in use.


It's a little odd that a disable commit can fail, but I don't think 
there's anything in DRM core that specifies that this can't happen for 
planes.


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

Re: [PATCH] drm/amdgpu: enable TMZ by default on Raven asics

[Christian König]

Am 25.02.21 um 17:44 schrieb Alex Deucher:

This has been stable for a while.

Signed-off-by: Alex Deucher 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  4 ++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 10 ++
  2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 2f71d36d2856..21504ea9085f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -164,7 +164,7 @@ int amdgpu_discovery = -1;
  int amdgpu_mes;
  int amdgpu_noretry = -1;
  int amdgpu_force_asic_type = -1;
-int amdgpu_tmz;
+int amdgpu_tmz = -1; /* auto */
  int amdgpu_reset_method = -1; /* auto */
  int amdgpu_num_kcq = -1;
  
@@ -790,7 +790,7 @@ module_param_named(abmlevel, amdgpu_dm_abm_level, uint, 0444);

   *
   * The default value: 0 (off).  TODO: change to auto till it is completed.
   */
-MODULE_PARM_DESC(tmz, "Enable TMZ feature (-1 = auto, 0 = off (default), 1 = 
on)");
+MODULE_PARM_DESC(tmz, "Enable TMZ feature (-1 = auto (default), 0 = off, 1 = 
on)");
  module_param_named(tmz, amdgpu_tmz, int, 0444);
  
  /**

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index fe1a39ffda72..1a892526d020 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -384,6 +384,16 @@ void amdgpu_gmc_tmz_set(struct amdgpu_device *adev)
  {
switch (adev->asic_type) {
case CHIP_RAVEN:
+   if (amdgpu_tmz == 0) {
+   adev->gmc.tmz_enabled = false;
+   dev_info(adev->dev,
+"Trusted Memory Zone (TMZ) feature disabled (cmd 
line)\n");
+   } else {
+   adev->gmc.tmz_enabled = true;
+   dev_info(adev->dev,
+"Trusted Memory Zone (TMZ) feature enabled\n");
+   }
+   break;
case CHIP_RENOIR:
case CHIP_NAVI10:
case CHIP_NAVI14:


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

Re: [PATCH 17/35] drm/amdkfd: register HMM device private zone

[Felix Kuehling]

Am 2021-03-01 um 3:46 a.m. schrieb Thomas Hellström (Intel):
>
> On 3/1/21 9:32 AM, Daniel Vetter wrote:
>> On Wed, Jan 06, 2021 at 10:01:09PM -0500, Felix Kuehling wrote:
>>> From: Philip Yang 
>>>
>>> Register vram memory as MEMORY_DEVICE_PRIVATE type resource, to
>>> allocate vram backing pages for page migration.
>>>
>>> Signed-off-by: Philip Yang 
>>> Signed-off-by: Felix Kuehling 
>> So maybe I'm getting this all wrong, but I think that the current ttm
>> fault code relies on devmap pte entries (especially for hugepte entries)
>> to stop get_user_pages. But this only works if the pte happens to not
>> point at a range with devmap pages.
>
> I don't think that's in TTM yet, but the proposed fix, yes (see email
> I just sent in another thread),
> but only for huge ptes.
>
>>
>> This patch here changes that, and so probably breaks this devmap pte
>> hack
>> ttm is using?
>>
>> If I'm not wrong here then I think we need to first fix up the ttm
>> code to
>> not use the devmap hack anymore, before a ttm based driver can
>> register a
>> dev_pagemap. Also adding Thomas since that just came up in another
>> discussion.
>
> It doesn't break the ttm devmap hack per se, but it indeed allows gup
> to the range registered, but here's where my lack of understanding why
> we can't allow gup-ing TTM ptes if there indeed is a backing
> struct-page? Because registering MEMORY_DEVICE_PRIVATE implies that,
> right?

I wasn't aware that TTM used devmap at all. If it does, what type of
memory does it use?

MEMORY_DEVICE_PRIVATE is like swapped out memory. It cannot be mapped in
the CPU page table. GUP would cause a page fault to swap it back into
system memory. We are looking into use MEMORY_DEVICE_GENERIC for a
future coherent memory architecture, where device memory can be
coherently accessed by the CPU and GPU.

As I understand it, our DEVICE_PRIVATE registration is not tied to an
actual physical address. Thus your devmap registration and our devmap
registration could probably coexist without any conflict. You'll just
have the overhead of two sets of struct pages for the same memory.

Regards,
  Felix


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

[PATCH 4/4] drm/amd/display: Add a backlight module option

[Alex Deucher]

From: Takashi Iwai 

There seem devices that don't work with the aux channel backlight
control.  For allowing such users to test with the other backlight
control method, provide a new module option, aux_backlight, to specify
enabling or disabling the aux backport support explicitly.  As
default, the aux support is detected by the hardware capability.

v2: make the backlight option generic in case we add future
backlight types (Alex)

BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1180749
BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1438
Signed-off-by: Takashi Iwai 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 4 
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
 3 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 9c0e1d43b470..2673457fba58 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -181,6 +181,7 @@ extern uint amdgpu_dc_feature_mask;
 extern uint amdgpu_freesync_vid_mode;
 extern uint amdgpu_dc_debug_mask;
 extern uint amdgpu_dm_abm_level;
+extern int amdgpu_backlight;
 extern struct amdgpu_mgpu_info mgpu_info;
 extern int amdgpu_ras_enable;
 extern uint amdgpu_ras_mask;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 3a6f52a4b2ec..b3832eb16eb1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -784,6 +784,10 @@ uint amdgpu_dm_abm_level;
 MODULE_PARM_DESC(abmlevel, "ABM level (0 = off (default), 1-4 = backlight 
reduction level) ");
 module_param_named(abmlevel, amdgpu_dm_abm_level, uint, 0444);
 
+int amdgpu_backlight = -1;
+MODULE_PARM_DESC(backlight, "Backlight control (0 = pwm, 1 = aux, -1 auto 
(default))");
+module_param_named(backlight, amdgpu_backlight, bint, 0444);
+
 /**
  * DOC: tmz (int)
  * Trusted Memory Zone (TMZ) is a method to protect data being written
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 fb1ad1426cd1..e91af2efb2ae 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2282,6 +2282,11 @@ static void update_connector_ext_caps(struct 
amdgpu_dm_connector *aconnector)
caps->ext_caps->bits.hdr_aux_backlight_control == 1)
caps->aux_support = true;
 
+   if (amdgpu_backlight == 0)
+   caps->aux_support = false;
+   else if (amdgpu_backlight == 1)
+   caps->aux_support = true;
+
/* From the specification (CTA-861-G), for calculating the maximum
 * luminance we need to use:
 *  Luminance = 50*2**(CV/32)
-- 
2.29.2

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

[PATCH 3/4] drm/amdgpu/display: handle aux backlight in backlight_get_brightness

[Alex Deucher]

Need to fetch it via aux.

Signed-off-by: Alex Deucher 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 +++
 1 file changed, 20 insertions(+), 4 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 175a4cd8b982..fb1ad1426cd1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3273,11 +3273,27 @@ static int amdgpu_dm_backlight_update_status(struct 
backlight_device *bd)
 static int amdgpu_dm_backlight_get_brightness(struct backlight_device *bd)
 {
struct amdgpu_display_manager *dm = bl_get_data(bd);
-   int ret = dc_link_get_backlight_level(dm->backlight_link);
+   struct amdgpu_dm_backlight_caps caps;
+
+   amdgpu_dm_update_backlight_caps(dm);
+   caps = dm->backlight_caps;
 
-   if (ret == DC_ERROR_UNEXPECTED)
-   return bd->props.brightness;
-   return convert_brightness_to_user(&dm->backlight_caps, ret);
+   if (caps.aux_support) {
+   struct dc_link *link = (struct dc_link *)dm->backlight_link;
+   u32 avg, peak;
+   bool rc;
+
+   rc = dc_link_get_backlight_level_nits(link, &avg, &peak);
+   if (!rc)
+   return bd->props.brightness;
+   return convert_brightness_to_user(&caps, avg);
+   } else {
+   int ret = dc_link_get_backlight_level(dm->backlight_link);
+
+   if (ret == DC_ERROR_UNEXPECTED)
+   return bd->props.brightness;
+   return convert_brightness_to_user(&caps, ret);
+   }
 }
 
 static const struct backlight_ops amdgpu_dm_backlight_ops = {
-- 
2.29.2

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

[PATCH 2/4] drm/amdgpu/display: don't assert in set backlight function

[Alex Deucher]

It just spams the logs.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 -
 1 file changed, 1 deletion(-)

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 fa9a62dc174b..974b70f21837 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2614,7 +2614,6 @@ bool dc_link_set_backlight_level(const struct dc_link 
*link,
if (pipe_ctx->plane_state == NULL)
frame_ramp = 0;
} else {
-   ASSERT(false);
return false;
}
 
-- 
2.29.2

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

[PATCH 1/4] drm/amdgpu/display: simplify backlight setting

[Alex Deucher]

Avoid the extra wrapper function.

Signed-off-by: Alex Deucher 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 20 ---
 1 file changed, 4 insertions(+), 16 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 278a11bde30f..175a4cd8b982 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3200,19 +3200,6 @@ static void amdgpu_dm_update_backlight_caps(struct 
amdgpu_display_manager *dm)
 #endif
 }
 
-static int set_backlight_via_aux(struct dc_link *link, uint32_t brightness)
-{
-   bool rc;
-
-   if (!link)
-   return 1;
-
-   rc = dc_link_set_backlight_level_nits(link, true, brightness,
- 
AUX_BL_DEFAULT_TRANSITION_TIME_MS);
-
-   return rc ? 0 : 1;
-}
-
 static int get_brightness_range(const struct amdgpu_dm_backlight_caps *caps,
unsigned *min, unsigned *max)
 {
@@ -3275,9 +3262,10 @@ static int amdgpu_dm_backlight_update_status(struct 
backlight_device *bd)
brightness = convert_brightness_from_user(&caps, bd->props.brightness);
// Change brightness based on AUX property
if (caps.aux_support)
-   return set_backlight_via_aux(link, brightness);
-
-   rc = dc_link_set_backlight_level(dm->backlight_link, brightness, 0);
+   rc = dc_link_set_backlight_level_nits(link, true, brightness,
+ 
AUX_BL_DEFAULT_TRANSITION_TIME_MS);
+   else
+   rc = dc_link_set_backlight_level(dm->backlight_link, 
brightness, 0);
 
return rc ? 0 : 1;
 }
-- 
2.29.2

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

[PATCH 0/4] Backlight fixes

[Alex Deucher]

This builds on the debugging and patches that Takashi did on the
bugs referenced in the patches.  It seems some latops claim to support
aux backlight control, but actually use the old pwm controller.

The code also currently warns in the backlight control function
if there is no pipe assigned, but this is a common case if the
display happens to be off when the backlight level is changed
and it just spams the logs, so remove it.

This set wires up the aux controller to the backlight control,
cleans up the code an bit, removes the assert, and adds an option
to override the backlight type.

@Display team, can you check if there are any quirks or differences
in the backlight control detection on windows?  Presumably this
is properly detected there. The systems in question claim to support
aux backlight control in their DPCDs, but that doesn't seem to work.

Alex Deucher (3):
  drm/amdgpu/display: simplify backlight setting
  drm/amdgpu/display: don't assert in set backlight function
  drm/amdgpu/display: handle aux backlight in backlight_get_brightness

Takashi Iwai (1):
  drm/amd/display: Add a backlight module option

 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  4 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 49 +++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c |  1 -
 4 files changed, 34 insertions(+), 21 deletions(-)

-- 
2.29.2

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

Re: [PATCH] drm/amdgpu: enable TMZ by default on Raven asics

[Alex Deucher]

Ping?

Alex

On Thu, Feb 25, 2021 at 11:44 AM Alex Deucher  wrote:
>
> This has been stable for a while.
>
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  4 ++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 10 ++
>  2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 2f71d36d2856..21504ea9085f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -164,7 +164,7 @@ int amdgpu_discovery = -1;
>  int amdgpu_mes;
>  int amdgpu_noretry = -1;
>  int amdgpu_force_asic_type = -1;
> -int amdgpu_tmz;
> +int amdgpu_tmz = -1; /* auto */
>  int amdgpu_reset_method = -1; /* auto */
>  int amdgpu_num_kcq = -1;
>
> @@ -790,7 +790,7 @@ module_param_named(abmlevel, amdgpu_dm_abm_level, uint, 
> 0444);
>   *
>   * The default value: 0 (off).  TODO: change to auto till it is completed.
>   */
> -MODULE_PARM_DESC(tmz, "Enable TMZ feature (-1 = auto, 0 = off (default), 1 = 
> on)");
> +MODULE_PARM_DESC(tmz, "Enable TMZ feature (-1 = auto (default), 0 = off, 1 = 
> on)");
>  module_param_named(tmz, amdgpu_tmz, int, 0444);
>
>  /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> index fe1a39ffda72..1a892526d020 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> @@ -384,6 +384,16 @@ void amdgpu_gmc_tmz_set(struct amdgpu_device *adev)
>  {
> switch (adev->asic_type) {
> case CHIP_RAVEN:
> +   if (amdgpu_tmz == 0) {
> +   adev->gmc.tmz_enabled = false;
> +   dev_info(adev->dev,
> +"Trusted Memory Zone (TMZ) feature disabled 
> (cmd line)\n");
> +   } else {
> +   adev->gmc.tmz_enabled = true;
> +   dev_info(adev->dev,
> +"Trusted Memory Zone (TMZ) feature 
> enabled\n");
> +   }
> +   break;
> case CHIP_RENOIR:
> case CHIP_NAVI10:
> case CHIP_NAVI14:
> --
> 2.29.2
>
> ___
> 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/ttm: ioremap buffer according to TTM mem caching setting

[Bhardwaj, Rajneesh]

I was wondering if a managed version of such API exists but looks like 
none. We only have devm_ioremap_wc but that is valid only for 
PAGE_CACHE_MODE_WC whereas ioremap_cache uses _WB. One more small 
comment below.



Acked-by: Rajneesh Bhardwaj 

On 3/4/2021 11:04 AM, Oak Zeng wrote:

If tbo.mem.bus.caching is cached, buffer is intended to be mapped
as cached from CPU. Map it with ioremap_cache.

This wasn't necessary before as device memory was never mapped
as cached from CPU side. It becomes necessary for aldebaran as
device memory is mapped cached from CPU.

Signed-off-by: Oak Zeng 
Reviewed-by: Christian Konig 
---
  drivers/gpu/drm/ttm/ttm_bo_util.c | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 031e581..7429464 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -91,6 +91,10 @@ static int ttm_resource_ioremap(struct ttm_device *bdev,
  
  		if (mem->bus.caching == ttm_write_combined)

addr = ioremap_wc(mem->bus.offset, bus_size);
+#ifdef CONFIG_X86



Please use #if defined (CONFIG_X86)


+   else if (mem->bus.caching == ttm_cached)
+   addr = ioremap_cache(mem->bus.offset, bus_size);
+#endif
else
addr = ioremap(mem->bus.offset, bus_size);
if (!addr) {
@@ -372,6 +376,11 @@ static int ttm_bo_ioremap(struct ttm_buffer_object *bo,
if (mem->bus.caching == ttm_write_combined)
map->virtual = ioremap_wc(bo->mem.bus.offset + offset,
  size);
+#ifdef CONFIG_X86
+   else if (mem->bus.caching == ttm_cached)
+   map->virtual = ioremap_cache(bo->mem.bus.offset + 
offset,
+ size);
+#endif
else
map->virtual = ioremap(bo->mem.bus.offset + offset,
   size);
@@ -490,6 +499,11 @@ int ttm_bo_vmap(struct ttm_buffer_object *bo, struct 
dma_buf_map *map)
else if (mem->bus.caching == ttm_write_combined)
vaddr_iomem = ioremap_wc(mem->bus.offset,
 bo->base.size);
+   else if (mem->bus.caching == ttm_cached)
+#ifdef CONFIG_X86
+   vaddr_iomem = ioremap_cache(mem->bus.offset,
+ bo->base.size);
+#endif
else
vaddr_iomem = ioremap(mem->bus.offset, bo->base.size);
  

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

Re: [PATCH] drm/amdgpu/display: restore AUX_DPHY_TX_CONTROL for DCN2.x

[Alex Deucher]

On Wed, Feb 17, 2021 at 11:53 AM Harry Wentland  wrote:
>
> On 2021-02-16 12:28 p.m., Alex Deucher wrote:
> > Commit 098214999c8f added fetching of the AUX_DPHY register
> > values from the vbios, but it also changed the default values
> > in the case when there are no values in the vbios.  This causes
> > problems with displays with high refresh rates.  To fix this,
> > switch back to the original default value for AUX_DPHY_TX_CONTROL.
>
> I don't see how this impacts displays with high refresh rates
> specifically. This is a change that only affects our AUX pre-charge time
> and was provided to us by the HW team. It does depend on another
> register being programmed by the VBIOS/DMCUBFW at boot.
>
> Before we revert this I would like confirmation that this is the root of
> the problem.

Hi Harry, any progress on this?

Thanks,

Alex


>
> Harry
>
> >
> > Fixes: 098214999c8f ("drm/amd/display: Read VBIOS Golden Settings Tbl")
> > Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1426
> > Signed-off-by: Alex Deucher 
> > Cc: Igor Kravchenko 
> > Cc: Aric Cyr 
> > Cc: Aurabindo Pillai 
> > ---
> >   drivers/gpu/drm/amd/display/dc/dcn20/dcn20_link_encoder.c | 3 +--
> >   1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_link_encoder.c 
> > b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_link_encoder.c
> > index fa013496e26b..2f9bfaeaba8d 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_link_encoder.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_link_encoder.c
> > @@ -341,8 +341,7 @@ void enc2_hw_init(struct link_encoder *enc)
> >   } else {
> >   AUX_REG_WRITE(AUX_DPHY_RX_CONTROL0, 0x103d1110);
> >
> > - AUX_REG_WRITE(AUX_DPHY_TX_CONTROL, 0x21c4d);
> > -
> > + AUX_REG_WRITE(AUX_DPHY_TX_CONTROL, 0x21c7a);
> >   }
> >
> >   //AUX_DPHY_TX_REF_CONTROL'AUX_TX_REF_DIV HW default is 0x32;
> >
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/ttm: ioremap buffer according to TTM mem caching setting

[Oak Zeng]

If tbo.mem.bus.caching is cached, buffer is intended to be mapped
as cached from CPU. Map it with ioremap_cache.

This wasn't necessary before as device memory was never mapped
as cached from CPU side. It becomes necessary for aldebaran as
device memory is mapped cached from CPU.

Signed-off-by: Oak Zeng 
Reviewed-by: Christian Konig 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 031e581..7429464 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -91,6 +91,10 @@ static int ttm_resource_ioremap(struct ttm_device *bdev,
 
if (mem->bus.caching == ttm_write_combined)
addr = ioremap_wc(mem->bus.offset, bus_size);
+#ifdef CONFIG_X86
+   else if (mem->bus.caching == ttm_cached)
+   addr = ioremap_cache(mem->bus.offset, bus_size);
+#endif
else
addr = ioremap(mem->bus.offset, bus_size);
if (!addr) {
@@ -372,6 +376,11 @@ static int ttm_bo_ioremap(struct ttm_buffer_object *bo,
if (mem->bus.caching == ttm_write_combined)
map->virtual = ioremap_wc(bo->mem.bus.offset + offset,
  size);
+#ifdef CONFIG_X86
+   else if (mem->bus.caching == ttm_cached)
+   map->virtual = ioremap_cache(bo->mem.bus.offset + 
offset,
+ size);
+#endif
else
map->virtual = ioremap(bo->mem.bus.offset + offset,
   size);
@@ -490,6 +499,11 @@ int ttm_bo_vmap(struct ttm_buffer_object *bo, struct 
dma_buf_map *map)
else if (mem->bus.caching == ttm_write_combined)
vaddr_iomem = ioremap_wc(mem->bus.offset,
 bo->base.size);
+   else if (mem->bus.caching == ttm_cached)
+#ifdef CONFIG_X86
+   vaddr_iomem = ioremap_cache(mem->bus.offset,
+ bo->base.size);
+#endif
else
vaddr_iomem = ioremap(mem->bus.offset, bo->base.size);
 
-- 
2.7.4

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

Re: [PATCH 3/6] amd/display: fail on cursor plane without an underlying plane

[Michel Dänzer]

On 2021-03-04 4:09 p.m., Kazlauskas, Nicholas wrote:
> On 2021-03-04 4:05 a.m., Michel Dänzer wrote:
>> On 2021-03-03 8:17 p.m., Daniel Vetter wrote:
>>> On Wed, Mar 3, 2021 at 5:53 PM Michel Dänzer  wrote:

 Moreover, in the same scenario plus an overlay plane enabled with a
 HW cursor compatible format, if the FB bound to the overlay plane is
 destroyed, the common DRM code will attempt to disable the overlay
 plane, but dm_check_crtc_cursor will reject that now. I can't remember
 exactly what the result is, but AFAIR it's not pretty.
>>>
>>> CRTC gets disabled instead. That's why we went with the "always
>>> require primary plane" hack. I think the only solution here would be
>>> to enable the primary plane (but not in userspace-visible state, so
>>> this needs to be done in the dc derived state objects only) that scans
>>> out black any time we're in such a situation with cursor with no
>>> planes.
>>
>> This is about a scenario described by Nicholas earlier:
>>
>> Cursor Plane - ARGB
>>
>> Overlay Plane - ARGB Desktop/UI with cutout for video
>>
>> Primary Plane - NV12 video
>>
>> And destroying the FB bound to the overlay plane. The fallback to disable
>> the CRTC in atomic_remove_fb only kicks in for the primary plane, so it
>> wouldn't in this case and would fail. Which would in turn trigger the
>> WARN in drm_framebuffer_remove (and leave the overlay plane scanning out
>> from freed memory?).
>>
>>
>> The cleanest solution might be not to allow any formats incompatible with
>> the HW cursor for the primary plane.
> 
> Legacy X userspace doesn't use overlays but Chrome OS does.
> 
> This would regress ChromeOS MPO support because it relies on the NV12
> video plane being on the bottom.

Could it use the NV12 overlay plane below the ARGB primary plane?


> When ChromeOS disables MPO it doesn't do it plane by plane, it does it
> in one go from NV12+ARGB -> ARGB8.

Even so, we cannot expect all user space to do the same, and we cannot
allow any user space to trigger a WARN and scanout from freed memory.


-- 
Earthling Michel Dänzer   |   https://redhat.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 3/6] amd/display: fail on cursor plane without an underlying plane

[Kazlauskas, Nicholas]

On 2021-03-04 4:05 a.m., Michel Dänzer wrote:

On 2021-03-03 8:17 p.m., Daniel Vetter wrote:

On Wed, Mar 3, 2021 at 5:53 PM Michel Dänzer  wrote:


On 2021-02-19 7:58 p.m., Simon Ser wrote:

Make sure there's an underlying pipe that can be used for the
cursor.

Signed-off-by: Simon Ser 
Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Nicholas Kazlauskas 
---
   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++-
   1 file changed, 6 insertions(+), 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 acbe1537e7cf..a5d6010405bf 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9226,9 +9226,14 @@ static int dm_check_crtc_cursor(struct 
drm_atomic_state *state,

   }

   new_cursor_state = drm_atomic_get_new_plane_state(state, 
crtc->cursor);
- if (!new_cursor_state || !new_underlying_state || 
!new_cursor_state->fb)

+ if (!new_cursor_state || !new_cursor_state->fb)
   return 0;

+ if (!new_underlying_state || !new_underlying_state->fb) {
+ drm_dbg_atomic(crtc->dev, "Cursor plane can't be 
enabled without underlying plane\n");

+ return -EINVAL;
+ }
+
   cursor_scale_w = new_cursor_state->crtc_w * 1000 /
    (new_cursor_state->src_w >> 16);
   cursor_scale_h = new_cursor_state->crtc_h * 1000 /



Houston, we have a problem I'm afraid. Adding Daniel.


If the primary plane is enabled with a format which isn't compatible 
with the HW cursor,
and no overlay plane is enabled, the same issues as described in 
b836a274b797
"drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC 
is" can again occur:



* The legacy cursor ioctl fails with EINVAL for a non-0 cursor FB ID
  (which enables the cursor plane).

* If the cursor plane is enabled (e.g. using the legacy cursor ioctl
  during DPMS off), changing the legacy DPMS property value from off to
  on fails with EINVAL.


atomic_check should still be run when the crtc is off, so the legacy
cursor ioctl should fail when dpms off in this case already.


Good point. This could already be problematic though. E.g. mutter treats
EINVAL from the cursor ioctl as the driver not supporting HW cursors at
all, so it falls back to SW cursor and never tries to use the HW cursor
again. (I don't think mutter could hit this particular case with an
incompatible format though, but there might be other similar user space)



Moreover, in the same scenario plus an overlay plane enabled with a
HW cursor compatible format, if the FB bound to the overlay plane is
destroyed, the common DRM code will attempt to disable the overlay
plane, but dm_check_crtc_cursor will reject that now. I can't remember
exactly what the result is, but AFAIR it's not pretty.


CRTC gets disabled instead. That's why we went with the "always
require primary plane" hack. I think the only solution here would be
to enable the primary plane (but not in userspace-visible state, so
this needs to be done in the dc derived state objects only) that scans
out black any time we're in such a situation with cursor with no
planes.


This is about a scenario described by Nicholas earlier:

Cursor Plane - ARGB

Overlay Plane - ARGB Desktop/UI with cutout for video

Primary Plane - NV12 video

And destroying the FB bound to the overlay plane. The fallback to disable
the CRTC in atomic_remove_fb only kicks in for the primary plane, so it
wouldn't in this case and would fail. Which would in turn trigger the
WARN in drm_framebuffer_remove (and leave the overlay plane scanning out
from freed memory?).


The cleanest solution might be not to allow any formats incompatible with
the HW cursor for the primary plane.




Legacy X userspace doesn't use overlays but Chrome OS does.

This would regress ChromeOS MPO support because it relies on the NV12 
video plane being on the bottom.


When ChromeOS disables MPO it doesn't do it plane by plane, it does it 
in one go from NV12+ARGB -> ARGB8.


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

Re: [PATCH] drm/amdgpu/dc: fill in missing call to atom cmd table for pll adjust v2

[Harry Wentland]

On 2021-03-03 10:20 a.m., Alex Deucher wrote:

We set up the parameters, but never called the atom table.

Signed-off-by: Alex Deucher 


Reviewed-by: Harry Wentland 

Harry


---
  .../drm/amd/display/dc/bios/command_table.c   | 21 +++
  1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table.c 
b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
index afc10b954ffa..ad13e4e36d77 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
@@ -1531,6 +1531,27 @@ static enum bp_result adjust_display_pll_v2(
params.ucEncodeMode =
(uint8_t)bp->cmd_helper->encoder_mode_bp_to_atom(
bp_params->signal_type, false);
+
+   if (EXEC_BIOS_CMD_TABLE(AdjustDisplayPll, params)) {
+   /* Convert output pixel clock back 10KHz-->KHz: multiply
+* original pixel clock in KHz by ratio
+* [output pxlClk/input pxlClk] */
+   uint64_t pixel_clk_10_khz_out =
+   (uint64_t)le16_to_cpu(params.usPixelClock);
+   uint64_t pixel_clk = (uint64_t)bp_params->pixel_clock;
+
+   if (pixel_clock_10KHz_in != 0) {
+   bp_params->adjusted_pixel_clock =
+   div_u64(pixel_clk * 
pixel_clk_10_khz_out,
+   pixel_clock_10KHz_in);
+   } else {
+   bp_params->adjusted_pixel_clock = 0;
+   BREAK_TO_DEBUGGER();
+   }
+
+   result = BP_RESULT_OK;
+   }
+
return result;
  }
  


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

RE: [PATCH] drm/amdgpu: simplify the sdma 4_x MGCG/MGLS logic.

[Lazar, Lijo]

[AMD Public Use]

Reviewed-by: Lijo Lazar 

-Original Message-
From: Feifei Xu  
Sent: Thursday, March 4, 2021 12:19 PM
To: amd-gfx@lists.freedesktop.org
Cc: alexdeuc...@gmail.com; Lazar, Lijo ; Xu, Feifei 

Subject: [PATCH] drm/amdgpu: simplify the sdma 4_x MGCG/MGLS logic.

SDMA 4_x asics share the same MGCG/MGLS setting.

Signed-off-by: Feifei Xu 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index 3bede8a70d7e..70d247841d14 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -2271,22 +2271,10 @@ static int sdma_v4_0_set_clockgating_state(void *handle,
if (amdgpu_sriov_vf(adev))
return 0;
 
-   switch (adev->asic_type) {
-   case CHIP_VEGA10:
-   case CHIP_VEGA12:
-   case CHIP_VEGA20:
-   case CHIP_RAVEN:
-   case CHIP_ARCTURUS:
-   case CHIP_RENOIR:
-   case CHIP_ALDEBARAN:
-   sdma_v4_0_update_medium_grain_clock_gating(adev,
-   state == AMD_CG_STATE_GATE);
-   sdma_v4_0_update_medium_grain_light_sleep(adev,
-   state == AMD_CG_STATE_GATE);
-   break;
-   default:
-   break;
-   }
+   sdma_v4_0_update_medium_grain_clock_gating(adev,
+   state == AMD_CG_STATE_GATE);
+   sdma_v4_0_update_medium_grain_light_sleep(adev,
+   state == AMD_CG_STATE_GATE);
return 0;
 }
 
-- 
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amd/pm: remove duplicate XGMI feature mask

[Lazar, Lijo]

[AMD Public Use]

Reviewed-by: Lijo Lazar 

-Original Message-
From: amd-gfx  On Behalf Of Kevin Wang
Sent: Thursday, March 4, 2021 1:05 PM
To: amd-gfx@lists.freedesktop.org
Cc: Wang, Kevin(Yang) 
Subject: [PATCH] drm/amd/pm: remove duplicate XGMI feature mask

replace SMU feature XGMI with XGMI_DPM.
it will cause show to be incorrect in pp_features node.

Signed-off-by: Kevin Wang 
---
 drivers/gpu/drm/amd/pm/inc/smu_types.h| 1 -
 drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/inc/smu_types.h 
b/drivers/gpu/drm/amd/pm/inc/smu_types.h
index aa4822202587..f9f45b6764fa 100644
--- a/drivers/gpu/drm/amd/pm/inc/smu_types.h
+++ b/drivers/gpu/drm/amd/pm/inc/smu_types.h
@@ -282,7 +282,6 @@ enum smu_clk_type {
__SMU_DUMMY_MAP(DS_FCLK),   \
__SMU_DUMMY_MAP(DS_MP1CLK), \
__SMU_DUMMY_MAP(DS_MP0CLK), \
-   __SMU_DUMMY_MAP(XGMI),  \
__SMU_DUMMY_MAP(DPM_GFX_PACE),  \
__SMU_DUMMY_MAP(MEM_VDDCI_SCALING), \
__SMU_DUMMY_MAP(MEM_MVDD_SCALING),  \
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
index f76d1b8aeecc..8189457a3ae6 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
@@ -162,7 +162,7 @@ static const struct cmn2asic_mapping 
arcturus_feature_mask_map[SMU_FEATURE_COUNT
FEA_MAP(DPM_SOCCLK),
FEA_MAP(DPM_FCLK),
FEA_MAP(DPM_MP0CLK),
-   ARCTURUS_FEA_MAP(SMU_FEATURE_XGMI_BIT, FEATURE_DPM_XGMI_BIT),
+   FEA_MAP(DPM_XGMI),
FEA_MAP(DS_GFXCLK),
FEA_MAP(DS_SOCCLK),
FEA_MAP(DS_LCLK),
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Clijo.lazar%40amd.com%7C838a8dcf382b4b16ea4808d8dee022cf%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637504401534512084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k5lb9Ma2MySTzBTPn9qhA6ocdBnd%2Bwa1thaJj2b4lrI%3D&reserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: PROBLEM: random desktop freezes, kmsg errors "Failed to parse relocation -12" and "failed to pin new rbo buffer before flip"

[Christian König]

Hi Lucas,

that sounds strongly as an known issue. Could you please test the 
drm-misc-fixes branch (https://cgit.freedesktop.org/drm/drm-misc/) and 
see if the problem still occurs?


Thanks in advance,
Christian.

Am 03.03.21 um 21:02 schrieb Lucas Werkmeister:

Hi all,

on Linux 5.11.1 and 5.11.2 (but not 5.10.16), my Gnome desktop (Radeon
R7 260X GPU) occasionally (usually after a few hours) freezes
completely; when it happens, I can still switch to a TTY (Ctrl+Alt+F3)
and back to the frozen desktop (Ctrl+Alt+F2), but I haven’t found a way
to “rescue” the desktop from the command line, and ultimately have to
reboot. When that happens, the journal is filled with many copies of
these kernel messages:


[drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse relocation -12!
radeon :01:00.0: 641f4713 pin failed
[drm:radeon_crtc_page_flip_target [radeon]] *ERROR* failed to pin new
rbo buffer before flip

I have uploaded the kernel logs of one affected boot, in systemd journal
export format, at 
.

Keywords: drm, radeon, amd, graphics

Kernel version:
$ cat /proc/version
Linux version 5.11.2-arch1-1 (linux@archlinux) (gcc (GCC) 10.2.0, GNU ld
(GNU Binutils) 2.36.1) #1 SMP PREEMPT Fri, 26 Feb 2021 18:26:41 +

Kernel .config file (from /proc/config.gz):


Most recent kernel version which did not have the bug: 5.10.16 [though
this has a similar issue, where the desktop also freezes but then
unfreezes either on its own or when I switch to a TTY and back; I
haven’t reported this yet, and don’t know if it’s related or not]

I have not yet found a way to systematically reproduce this. It seems to
happen more frequently when there is more load on the system, or on the
graphics card (e.g. fullscreen video playback, desktop recording).

ver_linux output:

Linux theoden 5.11.2-arch1-1 #1 SMP PREEMPT Fri, 26 Feb 2021 18:26:41
+ x86_64 GNU/Linux

GNU C   10.2.0
GNU Make4.3
Binutils2.36.1
Util-linux  2.36.2
Mount   2.36.2
Module-init-tools   28
E2fsprogs   1.46.2
Jfsutils1.1.15
Reiserfsprogs   3.6.27
Xfsprogs5.10.0
Quota-tools 4.06
Bison   3.7.3
Flex2.6.4
Linux C++ Library   6.0.28
Linux C Library 2.33
Dynamic linker (ldd)2.33
Procps  3.3.17
Kbd 2.4.0
Console-tools   2.4.0
Sh-utils8.32
Udev247
Modules Loaded  ac97_bus aesni_intel agpgart amdgpu at24 cbc
cdrom cec coretemp crc16 crc32c_generic crc32c_intel crc32_pclmul
crct10dif_pclmul cryptd crypto_simd crypto_user dm_bio_prison dm_bufio
dm_cache dm_cache_smq dm_crypt dm_mod dm_persistent_data drm
drm_kms_helper drm_ttm_helper e1000e encrypted_keys ext4 fat fb_sys_fops
fuse ghash_clmulni_intel glue_helper gpu_sched i2c_algo_bit i2c_i801
i2c_smbus intel_cstate intel_pmc_bxt intel_powerclamp intel_rapl_common
intel_rapl_msr intel_uncore ip_tables irqbypass iTCO_vendor_support
iTCO_wdt jbd2 joydev kvm kvm_intel ledtrig_audio libcrc32c lpc_ich
mac_hid mbcache mc mei mei_hdcp mei_me mei_wdt mousedev nls_iso8859_1
pcspkr radeon rapl rfkill rng_core sg snd snd_compress snd_hda_codec
snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_core snd_hda_intel snd_hwdep snd_intel_dspcfg snd_pcm
snd_pcm_dmaengine snd_rawmidi snd_seq_device snd_soc_core snd_timer
snd_usb_audio snd_usbmidi_lib soundcore soundwire_bus soundwire_cadence
soundwire_generic_allocation soundwire_intel sr_mod syscopyarea
sysfillrect sysimgblt tpm trusted ttm uas usbhid usb_storage uvcvideo
vfat video videobuf2_common videobuf2_memops videobuf2_v4l2
videobuf2_vmalloc videodev x86_pkg_temp_thermal xhci_pci
xhci_pci_renesas x_tables

CPU: Intel i7-4771, full /proc/cpuinfo at

RE: [PATCH] drm/amd/pm: remove duplicate XGMI feature mask

[Xu, Feifei]

[AMD Official Use Only - Internal Distribution Only]

Series is Acked-by: Feifei Xu 

-Original Message-
From: amd-gfx  On Behalf Of Kevin Wang
Sent: Thursday, March 4, 2021 3:35 PM
To: amd-gfx@lists.freedesktop.org
Cc: Wang, Kevin(Yang) 
Subject: [PATCH] drm/amd/pm: remove duplicate XGMI feature mask

replace SMU feature XGMI with XGMI_DPM.
it will cause show to be incorrect in pp_features node.

Signed-off-by: Kevin Wang 
---
 drivers/gpu/drm/amd/pm/inc/smu_types.h| 1 -
 drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/inc/smu_types.h 
b/drivers/gpu/drm/amd/pm/inc/smu_types.h
index aa4822202587..f9f45b6764fa 100644
--- a/drivers/gpu/drm/amd/pm/inc/smu_types.h
+++ b/drivers/gpu/drm/amd/pm/inc/smu_types.h
@@ -282,7 +282,6 @@ enum smu_clk_type {
__SMU_DUMMY_MAP(DS_FCLK),   \
__SMU_DUMMY_MAP(DS_MP1CLK), \
__SMU_DUMMY_MAP(DS_MP0CLK), \
-   __SMU_DUMMY_MAP(XGMI),  \
__SMU_DUMMY_MAP(DPM_GFX_PACE),  \
__SMU_DUMMY_MAP(MEM_VDDCI_SCALING), \
__SMU_DUMMY_MAP(MEM_MVDD_SCALING),  \
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
index f76d1b8aeecc..8189457a3ae6 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
@@ -162,7 +162,7 @@ static const struct cmn2asic_mapping 
arcturus_feature_mask_map[SMU_FEATURE_COUNT
 FEA_MAP(DPM_SOCCLK),
 FEA_MAP(DPM_FCLK),
 FEA_MAP(DPM_MP0CLK),
-ARCTURUS_FEA_MAP(SMU_FEATURE_XGMI_BIT, FEATURE_DPM_XGMI_BIT),
+FEA_MAP(DPM_XGMI),
 FEA_MAP(DS_GFXCLK),
 FEA_MAP(DS_SOCCLK),
 FEA_MAP(DS_LCLK),
--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7CFeifei.Xu%40amd.com%7Cda4d4b204a46456f7fec08d8dee02282%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637504401527391042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aWb9nQWgyQXwiNOPBMZhEsUu8XJvzpa%2FVHP7JVdzPe4%3D&reserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 3/6] amd/display: fail on cursor plane without an underlying plane

[Michel Dänzer]

On 2021-03-03 8:17 p.m., Daniel Vetter wrote:

On Wed, Mar 3, 2021 at 5:53 PM Michel Dänzer  wrote:


On 2021-02-19 7:58 p.m., Simon Ser wrote:

Make sure there's an underlying pipe that can be used for the
cursor.

Signed-off-by: Simon Ser 
Cc: Alex Deucher 
Cc: Harry Wentland 
Cc: Nicholas Kazlauskas 
---
   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++-
   1 file changed, 6 insertions(+), 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 acbe1537e7cf..a5d6010405bf 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9226,9 +9226,14 @@ static int dm_check_crtc_cursor(struct drm_atomic_state 
*state,
   }

   new_cursor_state = drm_atomic_get_new_plane_state(state, crtc->cursor);
- if (!new_cursor_state || !new_underlying_state || !new_cursor_state->fb)
+ if (!new_cursor_state || !new_cursor_state->fb)
   return 0;

+ if (!new_underlying_state || !new_underlying_state->fb) {
+ drm_dbg_atomic(crtc->dev, "Cursor plane can't be enabled without 
underlying plane\n");
+ return -EINVAL;
+ }
+
   cursor_scale_w = new_cursor_state->crtc_w * 1000 /
(new_cursor_state->src_w >> 16);
   cursor_scale_h = new_cursor_state->crtc_h * 1000 /



Houston, we have a problem I'm afraid. Adding Daniel.


If the primary plane is enabled with a format which isn't compatible with the 
HW cursor,
and no overlay plane is enabled, the same issues as described in b836a274b797
"drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is" can 
again occur:


* The legacy cursor ioctl fails with EINVAL for a non-0 cursor FB ID
  (which enables the cursor plane).

* If the cursor plane is enabled (e.g. using the legacy cursor ioctl
  during DPMS off), changing the legacy DPMS property value from off to
  on fails with EINVAL.


atomic_check should still be run when the crtc is off, so the legacy
cursor ioctl should fail when dpms off in this case already.


Good point. This could already be problematic though. E.g. mutter treats
EINVAL from the cursor ioctl as the driver not supporting HW cursors at
all, so it falls back to SW cursor and never tries to use the HW cursor
again. (I don't think mutter could hit this particular case with an
incompatible format though, but there might be other similar user space)



Moreover, in the same scenario plus an overlay plane enabled with a
HW cursor compatible format, if the FB bound to the overlay plane is
destroyed, the common DRM code will attempt to disable the overlay
plane, but dm_check_crtc_cursor will reject that now. I can't remember
exactly what the result is, but AFAIR it's not pretty.


CRTC gets disabled instead. That's why we went with the "always
require primary plane" hack. I think the only solution here would be
to enable the primary plane (but not in userspace-visible state, so
this needs to be done in the dc derived state objects only) that scans
out black any time we're in such a situation with cursor with no
planes.


This is about a scenario described by Nicholas earlier:

Cursor Plane - ARGB

Overlay Plane - ARGB Desktop/UI with cutout for video

Primary Plane - NV12 video

And destroying the FB bound to the overlay plane. The fallback to disable
the CRTC in atomic_remove_fb only kicks in for the primary plane, so it
wouldn't in this case and would fail. Which would in turn trigger the
WARN in drm_framebuffer_remove (and leave the overlay plane scanning out
from freed memory?).


The cleanest solution might be not to allow any formats incompatible with
the HW cursor for the primary plane.


--
Earthling Michel Dänzer   |   https://redhat.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] drm/ttm: ioremap buffer according to TTM mem caching setting

[Christian König]

I think we should check for CONFIG_X86 instead, but in general it sounds 
like the right approach to me for now.


Regards,
Christian.

Am 03.03.21 um 22:12 schrieb Oak Zeng:

If tbo.mem.bus.caching is cached, buffer is intended to be mapped
as cached from CPU. Map it with ioremap_cache.

This wasn't necessary before as device memory was never mapped
as cached from CPU side. It becomes necessary for aldebaran as
device memory is mapped cached from CPU.

Signed-off-by: Oak Zeng 
Reviewed-by: Christian Konig 
---
  drivers/gpu/drm/ttm/ttm_bo_util.c | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 031e581..7c848e2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -91,6 +91,10 @@ static int ttm_resource_ioremap(struct ttm_device *bdev,
  
  		if (mem->bus.caching == ttm_write_combined)

addr = ioremap_wc(mem->bus.offset, bus_size);
+#ifdef __x86_64__
+   else if (mem->bus.caching == ttm_cached)
+   addr = ioremap_cache(mem->bus.offset, bus_size);
+#endif
else
addr = ioremap(mem->bus.offset, bus_size);
if (!addr) {
@@ -372,6 +376,11 @@ static int ttm_bo_ioremap(struct ttm_buffer_object *bo,
if (mem->bus.caching == ttm_write_combined)
map->virtual = ioremap_wc(bo->mem.bus.offset + offset,
  size);
+#ifdef __x86_64__
+   else if (mem->bus.caching == ttm_cached)
+   map->virtual = ioremap_cache(bo->mem.bus.offset + 
offset,
+ size);
+#endif
else
map->virtual = ioremap(bo->mem.bus.offset + offset,
   size);
@@ -490,6 +499,11 @@ int ttm_bo_vmap(struct ttm_buffer_object *bo, struct 
dma_buf_map *map)
else if (mem->bus.caching == ttm_write_combined)
vaddr_iomem = ioremap_wc(mem->bus.offset,
 bo->base.size);
+   else if (mem->bus.caching == ttm_cached)
+#ifdef __x86_64__
+   vaddr_iomem = ioremap_cache(mem->bus.offset,
+ bo->base.size);
+#endif
else
vaddr_iomem = ioremap(mem->bus.offset, bo->base.size);
  


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

[PATCH] drm/amdgpu/display: Remove unnecessary conversion to bool

[Jiapeng Chong]

Fix the following coccicheck warnings:

./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:956:52-57: WARNING:
conversion to bool not needed here.

./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:8311:16-21: WARNING:
conversion to bool not needed here.

Reported-by: Abaci Robot 
Signed-off-by: Jiapeng Chong 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 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 3e1fd1e..0e6b7415 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -953,7 +953,7 @@ static void event_mall_stutter(struct work_struct *work)
 
 
dc_allow_idle_optimizations(
-   dm->dc, dm->active_vblank_irq_count == 0 ? true : false);
+   dm->dc, dm->active_vblank_irq_count == 0);
 
DRM_DEBUG_DRIVER("Allow idle optimizations (MALL): %d\n", 
dm->active_vblank_irq_count == 0);
 
@@ -8307,8 +8307,7 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
hdcp_update_display(
adev->dm.hdcp_workqueue, 
aconnector->dc_link->link_index, aconnector,
new_con_state->hdcp_content_type,
-   new_con_state->content_protection == 
DRM_MODE_CONTENT_PROTECTION_DESIRED ? true
-   
 : false);
+   new_con_state->content_protection == 
DRM_MODE_CONTENT_PROTECTION_DESIRED);
}
 #endif
 
-- 
1.8.3.1

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

RE: [PATCH] drm/amdgpu: soc15 pcie gen4 support

[Xu, Feifei]

Yes, seems un-necessary in current implementation.
 
Thanks,
Feifei

-Original Message-
From: Lazar, Lijo  
Sent: Thursday, March 4, 2021 3:38 PM
To: Chen, Guchun ; Alex Deucher ; 
Xu, Feifei 
Cc: amd-gfx list ; Zhang, Hawking 

Subject: RE: [PATCH] drm/amdgpu: soc15 pcie gen4 support

[AMD Public Use]

This function is doing nothing, is it necessary to maintain it? Not sure, if 
pcie gen support needs to be enabled specifically in driver.

Thanks,
Lijo

-Original Message-
From: amd-gfx  On Behalf Of Chen, Guchun
Sent: Thursday, March 4, 2021 1:06 PM
To: Alex Deucher ; Xu, Feifei 
Cc: amd-gfx list ; Zhang, Hawking 

Subject: RE: [PATCH] drm/amdgpu: soc15 pcie gen4 support

[AMD Public Use]

How about module parameter check amdgpu_pcie_gen2 in soc15_pcie_gen4_enable? Is 
it necessary to modify it as well?

Regards,
Guchun

-Original Message-
From: amd-gfx  On Behalf Of Alex Deucher
Sent: Thursday, March 4, 2021 11:58 AM
To: Xu, Feifei 
Cc: amd-gfx list ; Zhang, Hawking 

Subject: Re: [PATCH] drm/amdgpu: soc15 pcie gen4 support

On Wed, Mar 3, 2021 at 10:46 PM Feifei Xu  wrote:
>
> Signed-off-by: Feifei Xu 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/soc15.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c 
> b/drivers/gpu/drm/amd/amdgpu/soc15.c
> index 28b991904eaa..437cdc56bdc5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/soc15.c
> +++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
> @@ -569,7 +569,7 @@ static int soc15_set_vce_clocks(struct amdgpu_device 
> *adev, u32 evclk, u32 ecclk
> return 0;
>  }
>
> -static void soc15_pcie_gen3_enable(struct amdgpu_device *adev)
> +static void soc15_pcie_gen4_enable(struct amdgpu_device *adev)
>  {
> if (pci_is_root_bus(adev->pdev->bus))
> return;
> @@ -581,7 +581,8 @@ static void soc15_pcie_gen3_enable(struct amdgpu_device 
> *adev)
> return;
>
> if (!(adev->pm.pcie_gen_mask & (CAIL_PCIE_LINK_SPEED_SUPPORT_GEN2 |
> -   CAIL_PCIE_LINK_SPEED_SUPPORT_GEN3)))
> +   CAIL_PCIE_LINK_SPEED_SUPPORT_GEN3 |
> +   
> + CAIL_PCIE_LINK_SPEED_SUPPORT_GEN4)))
> return;
>
> /* todo */
> @@ -1374,8 +1375,8 @@ static int soc15_common_hw_init(void *handle)  {
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
>
> -   /* enable pcie gen2/3 link */
> -   soc15_pcie_gen3_enable(adev);
> +   /* enable pcie gen2/3/4 link */
> +   soc15_pcie_gen4_enable(adev);
> /* enable aspm */
> soc15_program_aspm(adev);
> /* setup nbio registers */
> --
> 2.25.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Cgu
> chun.chen%40amd.com%7Ca2af451ebb4b43bcc27b08d8dec1b4b5%7C3dd8961fe4884
> e608e11a82d994e183d%7C0%7C0%7C637504270832366776%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C1000&sdata=jaNGe06yp8RXKQxMm%2F%2FdR%2F6DMC4h8viG3KUW3Sz2s7Y%3D&
> amp;reserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Clijo.lazar%40amd.com%7C8f330aec736c4dfe8b3d08d8dee01c35%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637504401425290833%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9r5B6ckebE7FSvUHnZPKplh5c7fDMiK57U2RPnYSeM0%3D&reserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Clijo.lazar%40amd.com%7C8f330aec736c4dfe8b3d08d8dee01c35%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637504401425290833%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9r5B6ckebE7FSvUHnZPKplh5c7fDMiK57U2RPnYSeM0%3D&reserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[amdgpu] Can compute kernels with different VMIDs run concurrently on the gpu hardware

[Smith John]

Hi! I noticed that kernels with different VMIDs have different GPU address
spaces. I was wondering if it is possible for these kernels to run
concurrently on the same GPU, or they need to be serialized even when there
are free CUs.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx