RE: [PATCH 4/9] drm/amdgpu: Add a bitmask in amdgpu_ctx_mgr

[Zhu, Rex]

Hi Christian,

We allocate and map csa per ctx,  need to record the used/free vm space.
So use bitmap to manager the reserved vm space.

Also add resv_space_id in ctx.
When amdgpu_ctx_fini, we can clear the bit in the bitmap.


Best Regards
Rex
> -Original Message-
> From: Christian König 
> Sent: Thursday, December 6, 2018 8:34 PM
> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 4/9] drm/amdgpu: Add a bitmask in amdgpu_ctx_mgr
> 
> Am 06.12.18 um 13:14 schrieb Rex Zhu:
> > used to manager the reserverd vm space.
> 
> Why do we need that?
> 
> Christian.
> 
> >
> > Signed-off-by: Rex Zhu 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 8 ++--
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h | 4 +++-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 +-
> >   3 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> > index 8edf54b..8802ff2 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> > @@ -529,10 +529,14 @@ int amdgpu_ctx_wait_prev_fence(struct
> amdgpu_ctx *ctx,
> > return 0;
> >   }
> >
> > -void amdgpu_ctx_mgr_init(struct amdgpu_ctx_mgr *mgr)
> > +int amdgpu_ctx_mgr_init(struct amdgpu_ctx_mgr *mgr)
> >   {
> > mutex_init(>lock);
> > idr_init(>ctx_handles);
> > +   mgr->resv_vm_bitmap =
> kzalloc(DIV_ROUND_UP(AMDGPU_VM_MAX_NUM_CTX, BITS_PER_BYTE),
> GFP_KERNEL);
> > +   if (unlikely(!mgr->resv_vm_bitmap))
> > +   return -ENOMEM;
> > +   return 0;
> >   }
> >
> >   void amdgpu_ctx_mgr_entity_flush(struct amdgpu_ctx_mgr *mgr) @@
> > -601,7 +605,7 @@ void amdgpu_ctx_mgr_fini(struct amdgpu_ctx_mgr
> *mgr)
> > if (kref_put(>refcount, amdgpu_ctx_fini) != 1)
> > DRM_ERROR("ctx %p is still alive\n", ctx);
> > }
> > -
> > +   kfree(mgr->resv_vm_bitmap);
> > idr_destroy(>ctx_handles);
> > mutex_destroy(>lock);
> >   }
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
> > index b3b012c..94ac951 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
> > @@ -38,6 +38,7 @@ struct amdgpu_ctx_entity {
> >   struct amdgpu_ctx {
> > struct kref refcount;
> > struct amdgpu_device*adev;
> > +
> > unsignedreset_counter;
> > unsignedreset_counter_query;
> > uint32_tvram_lost_counter;
> > @@ -56,6 +57,7 @@ struct amdgpu_ctx_mgr {
> > struct mutexlock;
> > /* protected by lock */
> > struct idr  ctx_handles;
> > +   unsigned long   *resv_vm_bitmap;
> >   };
> >
> >   extern const unsigned int
> amdgpu_ctx_num_entities[AMDGPU_HW_IP_NUM];
> > @@ -80,7 +82,7 @@ int amdgpu_ctx_ioctl(struct drm_device *dev, void
> *data,
> >   int amdgpu_ctx_wait_prev_fence(struct amdgpu_ctx *ctx,
> >struct drm_sched_entity *entity);
> >
> > -void amdgpu_ctx_mgr_init(struct amdgpu_ctx_mgr *mgr);
> > +int amdgpu_ctx_mgr_init(struct amdgpu_ctx_mgr *mgr);
> >   void amdgpu_ctx_mgr_entity_fini(struct amdgpu_ctx_mgr *mgr);
> >   void amdgpu_ctx_mgr_entity_flush(struct amdgpu_ctx_mgr *mgr);
> >   void amdgpu_ctx_mgr_fini(struct amdgpu_ctx_mgr *mgr); diff --git
> > a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > index 52e4e90..338a091 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > @@ -988,11 +988,15 @@ int amdgpu_driver_open_kms(struct drm_device
> *dev, struct drm_file *file_priv)
> > mutex_init(>bo_list_lock);
> > idr_init(>bo_list_handles);
> >
> > -   amdgpu_ctx_mgr_init(>ctx_mgr);
> > +   if (amdgpu_ctx_mgr_init(>ctx_mgr))
> > +   goto error_ctx_mgr;
> >
> > file_priv->driver_priv = fpriv;
> > goto out_suspend;
> >
> > +error_ctx_mgr:
> > +   idr_destroy(>bo_list_handles);
> > +   mutex_destroy(>bo_list_lock);
> >   error_vm:
> > amdgpu_vm_fini(adev, >vm);
> >

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

RE: [PATCH 3/9] drm/amdgpu: Use dynamical reserved vm size

[Zhu, Rex]

> -Original Message-
> From: Christian König 
> Sent: Thursday, December 6, 2018 8:33 PM
> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 3/9] drm/amdgpu: Use dynamical reserved vm size
> 
> Am 06.12.18 um 13:14 schrieb Rex Zhu:
> > Use dynamical reserved vm size instand of hardcode.
> >
> > driver always reserve AMDGPU_VA_RESERVED_SIZE at the bottom of VM
> > space.
> >
> > for gfx/sdma mcbp feature,
> > reserve AMDGPU_VA_RESERVED_SIZ * AMDGPU_VM_MAX_NUM_CTX at
> the top of
> > VM space.
> > For sriov, only need to reserve AMDGPU_VA_RESERVED_SIZE at the top.
> >
> > Signed-off-by: Rex Zhu 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c |  8 
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_csa.h |  1 +
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 ++
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  3 +--
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |  1 +
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h  |  1 +
> >   drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c   |  2 +-
> >   drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   |  2 +-
> >   drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c   |  2 +-
> >   9 files changed, 25 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> > index 44b046f..caa71c7 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> > @@ -24,6 +24,14 @@
> >
> >   #include "amdgpu.h"
> >
> > +uint64_t amdgpu_get_reserved_csa_size(struct amdgpu_device *adev) {
> > +   if (amdgpu_sriov_vf(adev))
> > +   return AMDGPU_VA_RESERVED_SIZE;
> > +   else
> > +   return AMDGPU_VA_RESERVED_SIZE *
> AMDGPU_VM_MAX_NUM_CTX;
> 
> Do we really want AMDGPU_VA_RESERVED_SIZE *
> AMDGPU_VM_MAX_NUM_CTX here?
> 
> AMDGPU_CSA_SIZE * AMDGPU_VM_MAX_NUM_CTX should be sufficient I
> think.

Yes, You are right. I will fix this error.
Thanks.


> And we should name the function to amdgpu_csa_get_reserved_vm_space().
> 
> > +}
> > +
> >   uint64_t amdgpu_csa_vaddr(struct amdgpu_device *adev, uint32_t id)
> >   {
> > uint64_t addr = adev->vm_manager.max_pfn <<
> AMDGPU_GPU_PAGE_SHIFT;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.h
> > index aaf1fba..7159d6d 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.h
> > @@ -27,6 +27,7 @@
> >
> >   #define AMDGPU_CSA_SIZE   (128 * 1024)
> >
> > +uint64_t amdgpu_get_reserved_csa_size(struct amdgpu_device *adev);
> >   uint32_t amdgpu_get_total_csa_size(struct amdgpu_device *adev);
> >   uint64_t amdgpu_csa_vaddr(struct amdgpu_device *adev, uint32_t id);
> >   int amdgpu_allocate_static_csa(struct amdgpu_device *adev, struct
> > amdgpu_bo **bo, diff --git
> a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > index 7b3d1eb..4c12de8 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > @@ -557,6 +557,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev,
> void *data,
> > struct ww_acquire_ctx ticket;
> > struct list_head list, duplicates;
> > uint64_t va_flags;
> > +   uint64_t va_reserved, va_top;
> > int r = 0;
> >
> > if (args->va_address < AMDGPU_VA_RESERVED_SIZE) { @@ -565,6
> +566,15
> > @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
> > args->va_address, AMDGPU_VA_RESERVED_SIZE);
> > return -EINVAL;
> > }
> > +   va_top = adev->vm_manager.max_pfn * AMDGPU_GPU_PAGE_SIZE;
> > +   va_reserved = va_top - adev->vm_manager.reserved_vm_size;
> > +
> > +   if (args->va_address > va_reserved && args->va_address < va_top) {
> > +   dev_dbg(>pdev->dev,
> > +   "va_address 0x%LX is in reserved area 0x%LX\n",
> > +   args->va_address, adev-
> >vm_manager.reserved_vm_size);
> > +   return -EINVAL;
> > +   }
> >
> > if (args->va_address >= AMDGPU_GMC_HOLE_START &&
> > args->va_address < AMDGPU_GMC_HOLE_END) { diff --git
> > a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > index f736bda..52e4e90 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_k

Re: [PATCH] drm/amd/powerplay: improve OD code robustness

[Zhu, Rex]

Please add  Signed-off-by in the patch commit.


Except that,


Patch is

Reviewed-by: Rex Zhu 


Best Regards

Rex


From: Yin, Tianci (Rico)
Sent: Tuesday, December 4, 2018 5:01 PM
To: Zhu, Rex; Zhang, Jerry; Li, Pauline; Teng, Rui; Liang, Prike; Zhu, 
Changfeng; Wang, Kevin(Yang); amd-gfx@lists.freedesktop.org
Subject: 答复: [PATCH] drm/amd/powerplay: improve OD code robustness


hi ,


a lower request system clock may cause gpu hang,

add protection code to avoid this kind of issue,

pls help to review.


thanks!


Rico



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

Re: [PATCH -next] drm/amdgpu: Fix return value check in amdgpu_allocate_static_csa()

[Zhu, Rex]

Hi Yongjun,


This issue has been fixed.


Thanks.


Best Regards

Rex




commit 51f1f6f51712aade68cabb145ed8bab4a6c3997e
Author: Rex Zhu 
Date:   Fri Nov 23 18:52:21 2018 +0800

drm/amdgpu: Fix static checker warning

drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c:49 amdgpu_allocate_static_csa()
error: uninitialized symbol 'ptr'.

the test if (!bo) doesn't work, as the bo is a pointer to a pointer.
if bo create failed, the *bo will be set to NULL.
so change to test *bo.

Reviewed-by: Christian König 
Signed-off-by: Rex Zhu 
Signed-off-by: Alex Deucher 





From: Wei Yongjun 
Sent: Tuesday, December 4, 2018 2:39 PM
To: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); 
airl...@linux.ie; Zhu, Rex; Liu, Monk
Cc: Wei Yongjun; amd-gfx@lists.freedesktop.org; 
dri-de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; 
kernel-janit...@vger.kernel.org
Subject: [PATCH -next] drm/amdgpu: Fix return value check in 
amdgpu_allocate_static_csa()

Fix the return value check which testing the wrong variable
in amdgpu_allocate_static_csa().

Fixes: 7946340fa389 ("drm/amdgpu: Move csa related code to separate file")
Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
index 0c590dd..a5fbc6f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
@@ -43,7 +43,7 @@ int amdgpu_allocate_static_csa(struct amdgpu_device *adev, 
struct amdgpu_bo **bo
 r = amdgpu_bo_create_kernel(adev, size, PAGE_SIZE,
 domain, bo,
 NULL, );
-   if (!bo)
+   if (!r)
 return -ENOMEM;

 memset(ptr, 0, size);



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

Re: [PATCH] drm: should break if already get the best size

[Zhu, Rex]

Tested-by: Rex Zhu 


Without this patch, if we search node via rb tree.


For example: we insert  different node with rand size, size range in 
(1-).


the key in root node is 5587.


if we try to find the node with key equal to 5587 or 7381,


Loop:
node->key is 5587
node->key is 2273
node->key is 3706
node->key is 4892
node->key is 5296
node->key is 5461
node->key is 5519
node->key is 5549
node->key is 5570
node->key is 5581
node->key is 5584
node->key is 5585
node->key is 5586
node->key is 5586


Find the best node, key is 5587 (Loop 14 levels)


Loop:
node->key is 5587
node->key is 7381
node->key is 6474
node->key is 7034
node->key is 7228
node->key is 7314
node->key is 7339
node->key is 7349
node->key is 7372
node->key is 7377
node->key is 7378
node->key is 7379
node->key is 7379

find the best node, key is 7381. (Loop 13 levels)



With this patch:

we don't need to go down if we found the right node that size equal to we 
needed.



Best Regards
Rex


From: amd-gfx  on behalf of Monk Liu 

Sent: Thursday, November 22, 2018 8:33 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Monk
Subject: [PATCH] drm: should break if already get the best size

Signed-off-by: Monk Liu 
---
 drivers/gpu/drm/drm_mm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 3cc5fbd..369fd9b 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -318,6 +318,8 @@ static struct drm_mm_node *best_hole(struct drm_mm *mm, u64 
size)
 if (size <= node->hole_size) {
 best = node;
 rb = rb->rb_right;
+   if (size == node->hole_size)
+   break;
 } else {
 rb = rb->rb_left;
 }
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx 
Archives.. Using amd-gfx: To post a message to all the list members, send email 
to amd-gfx@lists.freedesktop.org. You can subscribe to the list, or change your 
existing subscription, in the sections below.


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

RE: [PATCH] drm/amdgpu: refactor smu8_send_msg_to_smc and WARN_ON time out

[Zhu, Rex]

Patch is
Reviewed-by:  Rex Zhu 

Best Regards
Rex

> -Original Message-
> From: amd-gfx  On Behalf Of S,
> Shirish
> Sent: Monday, November 12, 2018 10:48 PM
> To: Zhu, Rex ; Deucher, Alexander
> 
> Cc: Daniel Kurtz ; amd-gfx@lists.freedesktop.org; S,
> Shirish 
> Subject: [PATCH] drm/amdgpu: refactor smu8_send_msg_to_smc and
> WARN_ON time out
> 
> From: Daniel Kurtz 
> 
> This patch refactors smu8_send_msg_to_smc_with_parameter() to include
> smu8_send_msg_to_smc_async() so that all the messages sent to SMU can
> be profiled and appropriately reported if they fail.
> 
> Signed-off-by: Daniel Kurtz 
> Signed-off-by: Shirish S 
> ---
>  drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c | 45
> ++
>  1 file changed, 21 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> index 09b844e..b6e8c89 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> 
> @@ -61,9 +62,13 @@ static uint32_t smu8_get_argument(struct pp_hwmgr
> *hwmgr)
>   mmSMU_MP1_SRBM2P_ARG_0);
>  }
> 
> -static int smu8_send_msg_to_smc_async(struct pp_hwmgr *hwmgr,
> uint16_t msg)
> +/* Send a message to the SMC, and wait for its response.*/ static int
> +smu8_send_msg_to_smc_with_parameter(struct pp_hwmgr *hwmgr,
> + uint16_t msg, uint32_t parameter)
>  {
>   int result = 0;
> + ktime_t t_start;
> + s64 elapsed_us;
> 
>   if (hwmgr == NULL || hwmgr->device == NULL)
>   return -EINVAL;
> @@ -74,28 +79,31 @@ static int smu8_send_msg_to_smc_async(struct
> pp_hwmgr *hwmgr, uint16_t msg)
>   /* Read the last message to SMU, to report actual cause */
>   uint32_t val = cgs_read_register(hwmgr->device,
> 
> mmSMU_MP1_SRBM2P_MSG_0);
> - pr_err("smu8_send_msg_to_smc_async (0x%04x) failed\n",
> msg);
> - pr_err("SMU still servicing msg (0x%04x)\n", val);
> + pr_err("%s(0x%04x) aborted; SMU still servicing msg
> (0x%04x)\n",
> + __func__, msg, val);
>   return result;
>   }
> + t_start = ktime_get();
> +
> + cgs_write_register(hwmgr->device, mmSMU_MP1_SRBM2P_ARG_0,
> parameter);
> 
>   cgs_write_register(hwmgr->device, mmSMU_MP1_SRBM2P_RESP_0,
> 0);
>   cgs_write_register(hwmgr->device, mmSMU_MP1_SRBM2P_MSG_0,
> msg);
> 
> - return 0;
> + result = PHM_WAIT_FIELD_UNEQUAL(hwmgr,
> + SMU_MP1_SRBM2P_RESP_0,
> CONTENT, 0);
> +
> + elapsed_us = ktime_us_delta(ktime_get(), t_start);
> +
> + WARN(result, "%s(0x%04x, %#x) timed out after %lld us\n",
> + __func__, msg, parameter, elapsed_us);
> +
> + return result;
>  }
> 
> -/* Send a message to the SMC, and wait for its response.*/  static int
> smu8_send_msg_to_smc(struct pp_hwmgr *hwmgr, uint16_t msg)  {
> - int result = 0;
> -
> - result = smu8_send_msg_to_smc_async(hwmgr, msg);
> - if (result != 0)
> - return result;
> -
> - return PHM_WAIT_FIELD_UNEQUAL(hwmgr,
> - SMU_MP1_SRBM2P_RESP_0,
> CONTENT, 0);
> + return smu8_send_msg_to_smc_with_parameter(hwmgr, msg, 0);
>  }
> 
>  static int smu8_set_smc_sram_address(struct pp_hwmgr *hwmgr, @@ -
> 135,17 +143,6 @@ static int smu8_write_smc_sram_dword(struct pp_hwmgr
> *hwmgr,
>   return result;
>  }
> 
> -static int smu8_send_msg_to_smc_with_parameter(struct pp_hwmgr
> *hwmgr,
> -   uint16_t msg, uint32_t parameter)
> -{
> - if (hwmgr == NULL || hwmgr->device == NULL)
> - return -EINVAL;
> -
> - cgs_write_register(hwmgr->device, mmSMU_MP1_SRBM2P_ARG_0,
> parameter);
> -
> - return smu8_send_msg_to_smc(hwmgr, msg);
> -}
> -
>  static int smu8_check_fw_load_finish(struct pp_hwmgr *hwmgr,
>  uint32_t firmware)
>  {
> --
> 2.7.4
> 
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amdgpu: log smu version

[Zhu, Rex]

Patch is 
Reviewed-by:  Rex Zhu 

Best Regards
Rex 
> -Original Message-
> From: amd-gfx  On Behalf Of S,
> Shirish
> Sent: Monday, November 12, 2018 2:50 PM
> To: Zhu, Rex ; Deucher, Alexander
> 
> Cc: amd-gfx@lists.freedesktop.org; S, Shirish 
> Subject: [PATCH] drm/amdgpu: log smu version
> 
> This patch prints the version of SMU firmware.
> 
> Signed-off-by: Shirish S 
> ---
>  drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> index 09b844e..1439835 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> @@ -737,6 +737,10 @@ static int smu8_start_smu(struct pp_hwmgr
> *hwmgr)
> 
>   cgs_write_register(hwmgr->device, mmMP0PUB_IND_INDEX, index);
>   hwmgr->smu_version = cgs_read_register(hwmgr->device,
> mmMP0PUB_IND_DATA);
> + pr_info("smu version %02d.%02d.%02d\n",
> + ((hwmgr->smu_version >> 16) & 0xFF),
> + ((hwmgr->smu_version >> 8) & 0xFF),
> + (hwmgr->smu_version & 0xFF));
>   adev->pm.fw_version = hwmgr->smu_version >> 8;
> 
>   return smu8_request_smu_load_fw(hwmgr);
> --
> 2.7.4
> 
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: Fix CSA buffer alloc failed on Vega

[Zhu, Rex]

Got it .

Thanks.


Best Regards

Rex



From: Christian König 
Sent: Monday, November 12, 2018 6:42 PM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Fix CSA buffer alloc failed on Vega

Am 12.11.18 um 11:33 schrieb Rex Zhu:
> Alloc_pte failed when the VA address located in
> the higher arrange of 256T.
>
> so reserve the csa buffer under 128T as a work around.
>
> [  122.979425] amdgpu :03:00.0: va above limit (0xFFF1F >= 
> 0x10)
> [  122.987080] BUG: unable to handle kernel paging request at 880e1a79fff8
>
> Signed-off-by: Rex Zhu 

Well NAK, userspace wants to use the full address space below 128T for SVM.

The problem is rather that you incorrectly use amdgpu_csa_vaddr(). See
the code in amdgpu_driver_open_kms() how to do it correctly:

> uint64_t csa_addr = amdgpu_csa_vaddr(adev) &
> AMDGPU_GMC_HOLE_MASK;
>
> r = amdgpu_map_static_csa(adev, >vm,
> adev->virt.csa_obj,
> >csa_va, csa_addr, AMDGPU_CSA_SIZE);
> if (r)
> goto error_vm;

Christian.


> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 4 ++--
>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +-
>   2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> index fea4555..e2f325b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> @@ -36,9 +36,9 @@ uint64_t amdgpu_csa_vaddr(struct amdgpu_device *adev, 
> uint32_t id)
>   {
>uint64_t addr = adev->vm_manager.max_pfn << AMDGPU_GPU_PAGE_SHIFT;
>
> - addr -= AMDGPU_VA_RESERVED_SIZE * id;
> + addr = min(addr, AMDGPU_GMC_HOLE_START);
>
> - addr = amdgpu_gmc_sign_extend(addr);
> + addr -= (uint64_t)AMDGPU_VA_RESERVED_SIZE * id;
>
>return addr;
>   }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 338a091..ea6a12a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -711,7 +711,7 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
> *data, struct drm_file
>
>dev_info.virtual_address_offset = AMDGPU_VA_RESERVED_SIZE;
>dev_info.virtual_address_max =
> - min(vm_size, AMDGPU_GMC_HOLE_START);
> + min(vm_size, AMDGPU_GMC_HOLE_START - 
> adev->vm_manager.reserved_vm_size);
>
>if (vm_size > AMDGPU_GMC_HOLE_START) {
>dev_info.high_va_offset = AMDGPU_GMC_HOLE_END;

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

Re: [PATCH] drm/amdgpu: fix VM leaf walking

[Zhu, Rex]

That sounds reasonable.

Thanks.


Best Regards

Rex



From: Christian König 
Sent: Friday, October 26, 2018 3:34 PM
To: Zhu, Rex; Deucher, Alexander; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: fix VM leaf walking

Yeah, that came to my mind as well.

But this is the only case where we would use the return value and not use 
cursor->pfn as criteria to abort.

So to be consistent I rather don't want to do this,
Christian.

Am 25.10.18 um 17:43 schrieb Zhu, Rex:

How about add a return value for the function amdgpu_vm_pt_next?

And change the code as:



 ret = amdgpu_vm_pt_next(adev, cursor);
-   while (amdgpu_vm_pt_descendant(adev, cursor));
+   if (!ret)
+   while (amdgpu_vm_pt_descendant(adev, cursor));



Best Regards

Rex

From: amd-gfx 
<mailto:amd-gfx-boun...@lists.freedesktop.org>
 On Behalf Of Zhu, Rex
Sent: Thursday, October 25, 2018 11:34 PM
To: Deucher, Alexander 
<mailto:alexander.deuc...@amd.com>; Christian König 
<mailto:ckoenig.leichtzumer...@gmail.com>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: RE: [PATCH] drm/amdgpu: fix VM leaf walking



Patch is Tested-by:  Rex Zhu rex@amd.com<mailto:rex@amd.com>



Regards

Rex



From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 On Behalf Of Deucher, Alexander
Sent: Thursday, October 25, 2018 11:08 PM
To: Christian König 
mailto:ckoenig.leichtzumer...@gmail.com>>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amdgpu: fix VM leaf walking



Acked-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>





From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Christian König 
mailto:ckoenig.leichtzumer...@gmail.com>>
Sent: Thursday, October 25, 2018 10:38 AM
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: [PATCH] drm/amdgpu: fix VM leaf walking



Make sure we don't try to go down further after the leave walk already
ended. This fixes a crash with a new VM test.

Signed-off-by: Christian König 
mailto:christian.koe...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index db0cbf8d219d..352b30409060 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -542,7 +542,8 @@ static void amdgpu_vm_pt_next_leaf(struct amdgpu_device 
*adev,
struct amdgpu_vm_pt_cursor *cursor)
 {
 amdgpu_vm_pt_next(adev, cursor);
-   while (amdgpu_vm_pt_descendant(adev, cursor));
+   if (cursor->pfn != ~0ll)
+   while (amdgpu_vm_pt_descendant(adev, cursor));
 }

 /**
--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org<mailto: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] Revert "drm/amd/powerplay: Enable/Disable NBPSTATE on On/OFF of UVD"

[Zhu, Rex]

Patch is Acked-by: Rex Zhu 

Regards
Rex

> -Original Message-
> From: S, Shirish
> Sent: Friday, October 26, 2018 12:28 AM
> To: Zhu, Rex ; Agrawal, Akshu
> ; Deucher, Alexander
> 
> Cc: amd-gfx@lists.freedesktop.org; S, Shirish 
> Subject: [PATCH] Revert "drm/amd/powerplay: Enable/Disable NBPSTATE on
> On/OFF of UVD"
> 
> This reverts commit dbd8299c32f6f413f6cfe322fe0308f3cfc577e8.
> 
> Reason for revert:
> This patch sends  msg PPSMC_MSG_Disabl eLowMemoryPstate(0x002e)
> in wrong of sequence to SMU which is before PPSMC_MSG_UVDPowerON
> (0x0008).
> This leads to SMU failing to service the request as it is dependent on UVD to
> be powered ON, since it accesses UVD registers.
> 
> This msg should ideally be sent only when the UVD is about to decode a 4k
> video.
> 
> Signed-off-by: Shirish S 
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> index fef111d..53cf787 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> @@ -1228,17 +1228,14 @@ static int smu8_dpm_force_dpm_level(struct
> pp_hwmgr *hwmgr,
> 
>  static int smu8_dpm_powerdown_uvd(struct pp_hwmgr *hwmgr)  {
> - if (PP_CAP(PHM_PlatformCaps_UVDPowerGating)) {
> - smu8_nbdpm_pstate_enable_disable(hwmgr, true, true);
> + if (PP_CAP(PHM_PlatformCaps_UVDPowerGating))
>   return smum_send_msg_to_smc(hwmgr,
> PPSMC_MSG_UVDPowerOFF);
> - }
>   return 0;
>  }
> 
>  static int smu8_dpm_powerup_uvd(struct pp_hwmgr *hwmgr)  {
>   if (PP_CAP(PHM_PlatformCaps_UVDPowerGating)) {
> - smu8_nbdpm_pstate_enable_disable(hwmgr, false, true);
>   return smum_send_msg_to_smc_with_parameter(
>   hwmgr,
>   PPSMC_MSG_UVDPowerON,
> --
> 2.7.4

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

RE: [PATCH] drm/amdgpu: fix reporting of failed msg sent to SMU

[Zhu, Rex]

Patch is Reviewed-by: Rex Zhu 

Rex
> -Original Message-
> From: amd-gfx  On Behalf Of S,
> Shirish
> Sent: Friday, October 26, 2018 6:37 AM
> To: Deucher, Alexander ; Zhu, Rex
> 
> Cc: amd-gfx@lists.freedesktop.org; S, Shirish 
> Subject: [PATCH] drm/amdgpu: fix reporting of failed msg sent to SMU
> 
> Currently send_msg_to_smc_async() only report which message failed, but
> the actual failing message is the previous one, which SMU is unable to 
> service.
> 
> This patch reads the contents of register where the SMU is stuck and report
> appropriately.
> 
> Signed-off-by: Shirish S 
> ---
>  drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> index f836d30..b1007b8 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
> @@ -64,6 +64,7 @@ static uint32_t smu8_get_argument(struct pp_hwmgr
> *hwmgr)  static int smu8_send_msg_to_smc_async(struct pp_hwmgr
> *hwmgr, uint16_t msg)  {
>   int result = 0;
> + uint32_t = val;
> 
>   if (hwmgr == NULL || hwmgr->device == NULL)
>   return -EINVAL;
> @@ -71,7 +72,11 @@ static int smu8_send_msg_to_smc_async(struct
> pp_hwmgr *hwmgr, uint16_t msg)
>   result = PHM_WAIT_FIELD_UNEQUAL(hwmgr,
>   SMU_MP1_SRBM2P_RESP_0,
> CONTENT, 0);
>   if (result != 0) {
> + /* Read the last message to SMU, to report actual cause */
> + val = cgs_read_register(hwmgr->device,
> + mmSMU_MP1_SRBM2P_MSG_0);
>   pr_err("smu8_send_msg_to_smc_async (0x%04x) failed\n",
> msg);
> + pr_err("SMU still servicing msg (0x%04x)\n", val);
>   return result;
>   }
> 
> --
> 2.7.4
> 
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amdgpu: fix VM leaf walking

[Zhu, Rex]

How about add a return value for the function amdgpu_vm_pt_next?
And change the code as:

 ret = amdgpu_vm_pt_next(adev, cursor);
-   while (amdgpu_vm_pt_descendant(adev, cursor));
+   if (!ret)
+   while (amdgpu_vm_pt_descendant(adev, cursor));

Best Regards
Rex
From: amd-gfx  On Behalf Of Zhu, Rex
Sent: Thursday, October 25, 2018 11:34 PM
To: Deucher, Alexander ; Christian König 
; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: fix VM leaf walking

Patch is Tested-by:  Rex Zhu rex@amd.com<mailto:rex@amd.com>

Regards
Rex

From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 On Behalf Of Deucher, Alexander
Sent: Thursday, October 25, 2018 11:08 PM
To: Christian König 
mailto:ckoenig.leichtzumer...@gmail.com>>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amdgpu: fix VM leaf walking


Acked-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>


From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Christian König 
mailto:ckoenig.leichtzumer...@gmail.com>>
Sent: Thursday, October 25, 2018 10:38 AM
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: [PATCH] drm/amdgpu: fix VM leaf walking

Make sure we don't try to go down further after the leave walk already
ended. This fixes a crash with a new VM test.

Signed-off-by: Christian König 
mailto:christian.koe...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index db0cbf8d219d..352b30409060 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -542,7 +542,8 @@ static void amdgpu_vm_pt_next_leaf(struct amdgpu_device 
*adev,
struct amdgpu_vm_pt_cursor *cursor)
 {
 amdgpu_vm_pt_next(adev, cursor);
-   while (amdgpu_vm_pt_descendant(adev, cursor));
+   if (cursor->pfn != ~0ll)
+   while (amdgpu_vm_pt_descendant(adev, cursor));
 }

 /**
--
2.17.1

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

RE: [PATCH] drm/amdgpu: fix VM leaf walking

[Zhu, Rex]

Patch is Tested-by:  Rex Zhu rex@amd.com<mailto:rex@amd.com>

Regards
Rex

From: amd-gfx  On Behalf Of Deucher, 
Alexander
Sent: Thursday, October 25, 2018 11:08 PM
To: Christian König ; 
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: fix VM leaf walking


Acked-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>


From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Christian König 
mailto:ckoenig.leichtzumer...@gmail.com>>
Sent: Thursday, October 25, 2018 10:38 AM
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: [PATCH] drm/amdgpu: fix VM leaf walking

Make sure we don't try to go down further after the leave walk already
ended. This fixes a crash with a new VM test.

Signed-off-by: Christian König 
mailto:christian.koe...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index db0cbf8d219d..352b30409060 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -542,7 +542,8 @@ static void amdgpu_vm_pt_next_leaf(struct amdgpu_device 
*adev,
struct amdgpu_vm_pt_cursor *cursor)
 {
 amdgpu_vm_pt_next(adev, cursor);
-   while (amdgpu_vm_pt_descendant(adev, cursor));
+   if (cursor->pfn != ~0ll)
+   while (amdgpu_vm_pt_descendant(adev, cursor));
 }

 /**
--
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org<mailto: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/3] drm/amd/powerplay: added hwmon interfaces for setting max/min fan speed

[Zhu, Rex]

I think when user set max/min fan speed, the fan control mode will switch to

manual mode.

so if user need to exit the max/min fan speed, user need to reset to auto mode.


Do we need to let user enter manual mode first before set max/min fan speed?


Best Regards

Rex




From: Quan, Evan
Sent: Wednesday, October 24, 2018 4:47 PM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH 2/3] drm/amd/powerplay: added hwmon interfaces for setting 
max/min fan speed


This can be performed under auto mode.

The settings are always effective unless user resets them back.



Regards,

Evan

From: Zhu, Rex
Sent: 2018年10月24日 16:36
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/amd/powerplay: added hwmon interfaces for setting 
max/min fan speed



One question: how to exit the max/min fan speed and return to auto mode?



Best Regards

Rex







From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Evan Quan mailto:evan.q...@amd.com>>
Sent: Wednesday, October 24, 2018 4:11 PM
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Cc: Quan, Evan
Subject: [PATCH 2/3] drm/amd/powerplay: added hwmon interfaces for setting 
max/min fan speed



New hwmon interfaces for maximum and minimum fan speed setting.

Change-Id: Ic9ec9f2427c6d3425e1c7e7b765d7d01a92f9a26
Signed-off-by: Evan Quan mailto:evan.q...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h   |  6 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 56 ++-
 .../gpu/drm/amd/include/kgd_pp_interface.h|  2 +
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 46 +++
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h |  2 +
 5 files changed, 110 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
index f972cd156795..12c4e461a7bc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
@@ -364,6 +364,12 @@ enum amdgpu_pcie_gen {
 ((adev)->powerplay.pp_funcs->enable_mgpu_fan_boost(\
 (adev)->powerplay.pp_handle))

+#define amdgpu_dpm_set_fan_speed_max_rpm(adev, s) \
+   
((adev)->powerplay.pp_funcs->set_fan_speed_max_rpm)((adev)->powerplay.pp_handle,
 (s))
+
+#define amdgpu_dpm_set_fan_speed_min_rpm(adev, s) \
+   
((adev)->powerplay.pp_funcs->set_fan_speed_min_rpm)((adev)->powerplay.pp_handle,
 (s))
+
 struct amdgpu_dpm {
 struct amdgpu_ps*ps;
 /* number of valid power states */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 8e94255654ed..92da37bb51ba 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1265,6 +1265,32 @@ static ssize_t amdgpu_hwmon_get_fan1_min(struct device 
*dev,
 return snprintf(buf, PAGE_SIZE, "%d\n", min_rpm);
 }

+static ssize_t amdgpu_hwmon_set_fan1_min(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct amdgpu_device *adev = dev_get_drvdata(dev);
+   int err;
+   u32 value;
+
+   /* Can't adjust fan when the card is off */
+   if  ((adev->flags & AMD_IS_PX) &&
+(adev->ddev->switch_power_state != DRM_SWITCH_POWER_ON))
+   return -EINVAL;
+
+   err = kstrtou32(buf, 10, );
+   if (err)
+   return err;
+
+   if (adev->powerplay.pp_funcs->set_fan_speed_min_rpm) {
+   err = amdgpu_dpm_set_fan_speed_min_rpm(adev, value);
+   if (err)
+   return err;
+   }
+
+   return count;
+}
+
 static ssize_t amdgpu_hwmon_get_fan1_max(struct device *dev,
  struct device_attribute *attr,
  char *buf)
@@ -1285,6 +1311,32 @@ static ssize_t amdgpu_hwmon_get_fan1_max(struct device 
*dev,
 return snprintf(buf, PAGE_SIZE, "%d\n", max_rpm);
 }

+static ssize_t amdgpu_hwmon_set_fan1_max(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct amdgpu_device *adev = dev_get_drvdata(dev);
+   int err;
+   u32 value;
+
+   /* Can't adjust fan when the card is off */
+   if  ((adev->flags & AMD_IS_PX) &&
+(adev->ddev->switch_power_state != DRM_SWITCH_POWER_ON))
+   return -EINVAL;
+
+   err = kstrtou32(buf, 10, );
+   if (err)
+   return err;
+
+   if (adev->powerplay.pp_funcs->set_fan_speed_max_rpm) {
+   err = amdgpu_dpm_set_fan_speed_max_rpm(adev

Re: [PATCH 2/2] drm/amd/powerplay: commonize the API for retrieving current clocks

[Zhu, Rex]

Series is:

Reviewed-by: Rex Zhu 


Best Regards

Rex


From: amd-gfx  on behalf of Evan Quan 

Sent: Wednesday, October 24, 2018 4:09 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH 2/2] drm/amd/powerplay: commonize the API for retrieving 
current clocks

So that it can be shared between all clocks.

Change-Id: Ibac99b2aa81c1cb3e988b4eae6c98d32b7f35bed
Signed-off-by: Evan Quan 
---
 .../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 44 +++
 1 file changed, 15 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
index 8a1ee9ce7386..57143d51e3ee 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
@@ -1875,38 +1875,20 @@ static int vega20_get_gpu_power(struct pp_hwmgr *hwmgr,
 return ret;
 }

-static int vega20_get_current_gfx_clk_freq(struct pp_hwmgr *hwmgr, uint32_t 
*gfx_freq)
+static int vega20_get_current_clk_freq(struct pp_hwmgr *hwmgr,
+   PPCLK_e clk_id, uint32_t *clk_freq)
 {
-   uint32_t gfx_clk = 0;
 int ret = 0;

-   *gfx_freq = 0;
+   *clk_freq = 0;

 PP_ASSERT_WITH_CODE((ret = smum_send_msg_to_smc_with_parameter(hwmgr,
-   PPSMC_MSG_GetDpmClockFreq, (PPCLK_GFXCLK << 16))) == 0,
-   "[GetCurrentGfxClkFreq] Attempt to get Current GFXCLK 
Frequency Failed!",
+   PPSMC_MSG_GetDpmClockFreq, (clk_id << 16))) == 0,
+   "[GetCurrentClkFreq] Attempt to get Current Frequency 
Failed!",
 return ret);
-   gfx_clk = smum_get_argument(hwmgr);
+   *clk_freq = smum_get_argument(hwmgr);

-   *gfx_freq = gfx_clk * 100;
-
-   return 0;
-}
-
-static int vega20_get_current_mclk_freq(struct pp_hwmgr *hwmgr, uint32_t 
*mclk_freq)
-{
-   uint32_t mem_clk = 0;
-   int ret = 0;
-
-   *mclk_freq = 0;
-
-   PP_ASSERT_WITH_CODE((ret = smum_send_msg_to_smc_with_parameter(hwmgr,
-   PPSMC_MSG_GetDpmClockFreq, (PPCLK_UCLK << 16))) == 0,
-   "[GetCurrentMClkFreq] Attempt to get Current MCLK 
Frequency Failed!",
-   return ret);
-   mem_clk = smum_get_argument(hwmgr);
-
-   *mclk_freq = mem_clk * 100;
+   *clk_freq = *clk_freq * 100;

 return 0;
 }
@@ -1937,12 +1919,16 @@ static int vega20_read_sensor(struct pp_hwmgr *hwmgr, 
int idx,

 switch (idx) {
 case AMDGPU_PP_SENSOR_GFX_SCLK:
-   ret = vega20_get_current_gfx_clk_freq(hwmgr, (uint32_t *)value);
+   ret = vega20_get_current_clk_freq(hwmgr,
+   PPCLK_GFXCLK,
+   (uint32_t *)value);
 if (!ret)
 *size = 4;
 break;
 case AMDGPU_PP_SENSOR_GFX_MCLK:
-   ret = vega20_get_current_mclk_freq(hwmgr, (uint32_t *)value);
+   ret = vega20_get_current_clk_freq(hwmgr,
+   PPCLK_UCLK,
+   (uint32_t *)value);
 if (!ret)
 *size = 4;
 break;
@@ -2743,7 +2729,7 @@ static int vega20_print_clock_levels(struct pp_hwmgr 
*hwmgr,

 switch (type) {
 case PP_SCLK:
-   ret = vega20_get_current_gfx_clk_freq(hwmgr, );
+   ret = vega20_get_current_clk_freq(hwmgr, PPCLK_GFXCLK, );
 PP_ASSERT_WITH_CODE(!ret,
 "Attempt to get current gfx clk Failed!",
 return ret);
@@ -2760,7 +2746,7 @@ static int vega20_print_clock_levels(struct pp_hwmgr 
*hwmgr,
 break;

 case PP_MCLK:
-   ret = vega20_get_current_mclk_freq(hwmgr, );
+   ret = vega20_get_current_clk_freq(hwmgr, PPCLK_UCLK, );
 PP_ASSERT_WITH_CODE(!ret,
 "Attempt to get current mclk freq Failed!",
 return ret);
--
2.19.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx 
Archives.. Using amd-gfx: To post a message to all the list members, send email 
to amd-gfx@lists.freedesktop.org. You can subscribe to the list, or change your 
existing subscription, in the sections below.


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

Re: [PATCH 3/3] drm/amd/powerplay: support hwmon max/min fan speed setting on Vega20

[Zhu, Rex]

-   percent = current_rpm * 100 / pp_table->FanMaximumRpm;
+   percent = (current_rpm * 100) /
+   hwmgr->thermal_controller.fanInfo.ulMaxRPM;


Better check hwmgr->thermal_controller.fanInfo.ulMaxRPM not equal to 0.


Best Regards

Rex


From: amd-gfx  on behalf of Evan Quan 

Sent: Wednesday, October 24, 2018 4:11 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH 3/3] drm/amd/powerplay: support hwmon max/min fan speed setting 
on Vega20

Added support for hwmon max/min fan speed setting on Vega20.

Change-Id: Ieab42c744d6c54f8b85a71be80f7c6832ae7352b
Signed-off-by: Evan Quan 
---
 .../drm/amd/powerplay/hwmgr/vega20_hwmgr.c|  4 ++
 .../drm/amd/powerplay/hwmgr/vega20_thermal.c  | 56 ++-
 .../drm/amd/powerplay/hwmgr/vega20_thermal.h  |  4 ++
 3 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
index 57143d51e3ee..2513e6be3219 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
@@ -3539,6 +3539,10 @@ static const struct pp_hwmgr_func vega20_hwmgr_funcs = {
 vega20_get_fan_control_mode,
 .set_fan_control_mode =
 vega20_set_fan_control_mode,
+   .set_fan_speed_max_rpm =
+   vega20_fan_ctrl_set_fan_speed_max_rpm,
+   .set_fan_speed_min_rpm =
+   vega20_fan_ctrl_set_fan_speed_min_rpm,
 /* smu memory related */
 .notify_cac_buffer_info =
 vega20_notify_cac_buffer_info,
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_thermal.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_thermal.c
index ede54e87e287..da9fd2168dcb 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_thermal.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_thermal.c
@@ -118,7 +118,6 @@ int vega20_fan_ctrl_get_fan_speed_percent(struct pp_hwmgr 
*hwmgr,
 uint32_t *speed)
 {
 struct vega20_hwmgr *data = (struct vega20_hwmgr *)(hwmgr->backend);
-   PPTable_t *pp_table = &(data->smc_state_table.pp_table);
 uint32_t current_rpm, percent = 0;
 int ret = 0;

@@ -126,7 +125,8 @@ int vega20_fan_ctrl_get_fan_speed_percent(struct pp_hwmgr 
*hwmgr,
 if (ret)
 return ret;

-   percent = current_rpm * 100 / pp_table->FanMaximumRpm;
+   percent = (current_rpm * 100) /
+   hwmgr->thermal_controller.fanInfo.ulMaxRPM;

 *speed = percent > 100 ? 100 : percent;

@@ -208,6 +208,58 @@ int vega20_fan_ctrl_set_fan_speed_rpm(struct pp_hwmgr 
*hwmgr, uint32_t speed)
 return vega20_fan_ctrl_set_static_mode(hwmgr, FDO_PWM_MODE_STATIC_RPM);
 }

+int vega20_fan_ctrl_set_fan_speed_max_rpm(struct pp_hwmgr *hwmgr, uint32_t 
speed)
+{
+   struct vega20_hwmgr *data = (struct vega20_hwmgr *)(hwmgr->backend);
+   struct vega20_od8_settings *od8_settings = &(data->od8_settings);
+   int ret = 0;
+
+   if ((od8_settings->overdrive8_capabilities & OD8_ACOUSTIC_LIMIT_SCLK) &&
+   (speed > 
od8_settings->od8_settings_array[OD8_SETTING_FAN_ACOUSTIC_LIMIT].max_value ||
+speed < 
od8_settings->od8_settings_array[OD8_SETTING_FAN_ACOUSTIC_LIMIT].min_value))
+   return -EINVAL;
+
+   ret = smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetFanMaxRpm,
+   speed);
+   PP_ASSERT_WITH_CODE(!ret,
+   "Set FanMaxRpm Failed!",
+   return ret);
+
+   hwmgr->thermal_controller.fanInfo.ulMinRPM =
+   (speed * hwmgr->thermal_controller.fanInfo.ulMinPWM) / 255;
+
+   return ret;
+}
+
+int vega20_fan_ctrl_set_fan_speed_min_rpm(struct pp_hwmgr *hwmgr, uint32_t 
speed)
+{
+   struct vega20_hwmgr *data = (struct vega20_hwmgr *)(hwmgr->backend);
+   struct vega20_od8_settings *od8_settings = &(data->od8_settings);
+   int ret = 0;
+   uint32_t pwm = 0;
+
+   if ((od8_settings->overdrive8_capabilities & OD8_FAN_SPEED_MIN) &&
+   (speed > 
od8_settings->od8_settings_array[OD8_FAN_SPEED_MIN].max_value ||
+speed < 
od8_settings->od8_settings_array[OD8_FAN_SPEED_MIN].min_value))
+   return -EINVAL;
+
+   if (speed > hwmgr->thermal_controller.fanInfo.ulMaxRPM)
+   return -EINVAL;
+
+   pwm = (speed * 255) / hwmgr->thermal_controller.fanInfo.ulMaxRPM;
+   ret = smum_send_msg_to_smc_with_parameter(hwmgr,
+   PPSMC_MSG_SetFanMinPwm,
+   pwm);
+   PP_ASSERT_WITH_CODE(!ret,
+   "Set FanMinPwm Failed!",
+   return ret);
+
+   hwmgr->thermal_controller.fanInfo.ulMinPWM = pwm;
+
+   return ret;
+}
+
 /**
 * Reads the remote temperature from the SIslands thermal controller.
 *
diff --git 

Re: [PATCH 2/3] drm/amd/powerplay: added hwmon interfaces for setting max/min fan speed

[Zhu, Rex]

One question: how to exit the max/min fan speed and return to auto mode?


Best Regards

Rex




From: amd-gfx  on behalf of Evan Quan 

Sent: Wednesday, October 24, 2018 4:11 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH 2/3] drm/amd/powerplay: added hwmon interfaces for setting 
max/min fan speed

New hwmon interfaces for maximum and minimum fan speed setting.

Change-Id: Ic9ec9f2427c6d3425e1c7e7b765d7d01a92f9a26
Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h   |  6 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 56 ++-
 .../gpu/drm/amd/include/kgd_pp_interface.h|  2 +
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 46 +++
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h |  2 +
 5 files changed, 110 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
index f972cd156795..12c4e461a7bc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
@@ -364,6 +364,12 @@ enum amdgpu_pcie_gen {
 ((adev)->powerplay.pp_funcs->enable_mgpu_fan_boost(\
 (adev)->powerplay.pp_handle))

+#define amdgpu_dpm_set_fan_speed_max_rpm(adev, s) \
+   
((adev)->powerplay.pp_funcs->set_fan_speed_max_rpm)((adev)->powerplay.pp_handle,
 (s))
+
+#define amdgpu_dpm_set_fan_speed_min_rpm(adev, s) \
+   
((adev)->powerplay.pp_funcs->set_fan_speed_min_rpm)((adev)->powerplay.pp_handle,
 (s))
+
 struct amdgpu_dpm {
 struct amdgpu_ps*ps;
 /* number of valid power states */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 8e94255654ed..92da37bb51ba 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1265,6 +1265,32 @@ static ssize_t amdgpu_hwmon_get_fan1_min(struct device 
*dev,
 return snprintf(buf, PAGE_SIZE, "%d\n", min_rpm);
 }

+static ssize_t amdgpu_hwmon_set_fan1_min(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct amdgpu_device *adev = dev_get_drvdata(dev);
+   int err;
+   u32 value;
+
+   /* Can't adjust fan when the card is off */
+   if  ((adev->flags & AMD_IS_PX) &&
+(adev->ddev->switch_power_state != DRM_SWITCH_POWER_ON))
+   return -EINVAL;
+
+   err = kstrtou32(buf, 10, );
+   if (err)
+   return err;
+
+   if (adev->powerplay.pp_funcs->set_fan_speed_min_rpm) {
+   err = amdgpu_dpm_set_fan_speed_min_rpm(adev, value);
+   if (err)
+   return err;
+   }
+
+   return count;
+}
+
 static ssize_t amdgpu_hwmon_get_fan1_max(struct device *dev,
  struct device_attribute *attr,
  char *buf)
@@ -1285,6 +1311,32 @@ static ssize_t amdgpu_hwmon_get_fan1_max(struct device 
*dev,
 return snprintf(buf, PAGE_SIZE, "%d\n", max_rpm);
 }

+static ssize_t amdgpu_hwmon_set_fan1_max(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct amdgpu_device *adev = dev_get_drvdata(dev);
+   int err;
+   u32 value;
+
+   /* Can't adjust fan when the card is off */
+   if  ((adev->flags & AMD_IS_PX) &&
+(adev->ddev->switch_power_state != DRM_SWITCH_POWER_ON))
+   return -EINVAL;
+
+   err = kstrtou32(buf, 10, );
+   if (err)
+   return err;
+
+   if (adev->powerplay.pp_funcs->set_fan_speed_max_rpm) {
+   err = amdgpu_dpm_set_fan_speed_max_rpm(adev, value);
+   if (err)
+   return err;
+   }
+
+   return count;
+}
+
 static ssize_t amdgpu_hwmon_get_fan1_target(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -1628,8 +1680,8 @@ static SENSOR_DEVICE_ATTR(pwm1_enable, S_IRUGO | S_IWUSR, 
amdgpu_hwmon_get_pwm1_
 static SENSOR_DEVICE_ATTR(pwm1_min, S_IRUGO, amdgpu_hwmon_get_pwm1_min, NULL, 
0);
 static SENSOR_DEVICE_ATTR(pwm1_max, S_IRUGO, amdgpu_hwmon_get_pwm1_max, NULL, 
0);
 static SENSOR_DEVICE_ATTR(fan1_input, S_IRUGO, amdgpu_hwmon_get_fan1_input, 
NULL, 0);
-static SENSOR_DEVICE_ATTR(fan1_min, S_IRUGO, amdgpu_hwmon_get_fan1_min, NULL, 
0);
-static SENSOR_DEVICE_ATTR(fan1_max, S_IRUGO, amdgpu_hwmon_get_fan1_max, NULL, 
0);
+static SENSOR_DEVICE_ATTR(fan1_min, S_IRUGO | S_IWUSR, 
amdgpu_hwmon_get_fan1_min, amdgpu_hwmon_set_fan1_min, 0);
+static SENSOR_DEVICE_ATTR(fan1_max, S_IRUGO | S_IWUSR, 
amdgpu_hwmon_get_fan1_max, amdgpu_hwmon_set_fan1_max, 0);
 static 

Re: [PATCH v2] drm/amdgpu: Patch csa mc address in IB packet

[Zhu, Rex]

Thanks David.

I think we can use ring->idx.


Best Regards

Rex




From: Zhou, David(ChunMing)
Sent: Wednesday, October 24, 2018 2:55 PM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: RE: [PATCH v2] drm/amdgpu: Patch csa mc address in IB packet



> -Original Message-
> From: amd-gfx  On Behalf Of Rex
> Zhu
> Sent: Wednesday, October 24, 2018 2:03 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex 
> Subject: [PATCH v2] drm/amdgpu: Patch csa mc address in IB packet
>
> the csa buffer is used by sdma engine to do context save when preemption
> happens. it the mc address is zero, mean the preemtpion feature(MCBP) is
> disabled.
>
> Signed-off-by: Rex Zhu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 13 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h |  2 ++
>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c   |  8 ++--
>  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c   |  8 ++--
>  4 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
> index 0fb9907..24b80bc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
> @@ -40,3 +40,16 @@ struct amdgpu_sdma_instance *
> amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
>
>return NULL;
>  }
> +
> +int amdgpu_get_sdma_index(struct amdgpu_ring *ring, uint32_t *index) {
> + struct amdgpu_device *adev = ring->adev;
> + int i;
> +
> + for (i = 0; i < adev->sdma.num_instances; i++)
> + if (ring == >sdma.instance[i].ring ||
> + ring == >sdma.instance[i].page)
> + return i;
> +
> + return -EINVAL;
> +}

Loop for checking works,  but looks not good.

If you need ring index, you can define them first as enum, and evaluate enum 
index to ring when ring initializing.

Regards,
David Zhou
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h
> index 479a245..314078a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h
> @@ -26,6 +26,7 @@
>
>  /* max number of IP instances */
>  #define AMDGPU_MAX_SDMA_INSTANCES2
> +#define AMDGPU_SDMA_CSA_SIZE (1024)
>
>  enum amdgpu_sdma_irq {
>AMDGPU_SDMA_IRQ_TRAP0 = 0,
> @@ -96,4 +97,5 @@ struct amdgpu_buffer_funcs {  struct
> amdgpu_sdma_instance *  amdgpu_get_sdma_instance(struct amdgpu_ring
> *ring);
>
> +int amdgpu_get_sdma_index(struct amdgpu_ring *ring, uint32_t *index);
>  #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> index f5e6aa2..fdc5d75 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> @@ -424,7 +424,11 @@ static void sdma_v3_0_ring_emit_ib(struct
> amdgpu_ring *ring,
>   bool ctx_switch)
>  {
>unsigned vmid = GET_VMID(job);
> + uint64_t csa_mc_addr = job ? job->csa_mc_addr : 0;
> + uint32_t i = 0;
>
> + if (amdgpu_get_sdma_index(ring, ))
> + return -EINVAL;
>/* IB packet must end on a 8 DW boundary */
>sdma_v3_0_ring_insert_nop(ring, (10 - (lower_32_bits(ring->wptr) &
> 7)) % 8);
>
> @@ -434,8 +438,8 @@ static void sdma_v3_0_ring_emit_ib(struct
> amdgpu_ring *ring,
>amdgpu_ring_write(ring, lower_32_bits(ib->gpu_addr) & 0xffe0);
>amdgpu_ring_write(ring, upper_32_bits(ib->gpu_addr));
>amdgpu_ring_write(ring, ib->length_dw);
> - amdgpu_ring_write(ring, 0);
> - amdgpu_ring_write(ring, 0);
> + amdgpu_ring_write(ring, lower_32_bits(csa_mc_addr + i *
> AMDGPU_SDMA_CSA_SIZE));
> + amdgpu_ring_write(ring, upper_32_bits(csa_mc_addr + i *
> +AMDGPU_SDMA_CSA_SIZE));
>
>  }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
> b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
> index 2282ac1..e69a584 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
> @@ -507,7 +507,11 @@ static void sdma_v4_0_ring_emit_ib(struct
> amdgpu_ring *ring,
>   bool ctx_switch)
>  {
>unsigned vmid = GET_VMID(job);
> + uint64_t csa_mc_addr = job ? job->csa_mc_addr : 0;
> + uint32_t i = 0;
>
> + if (amdgpu_get_sdma_index(ring, ))
> + return -EINVAL;
>/* IB packet must end on a 8 DW boundary */
>sdma_v4_0_ring_insert_nop(ring, (10 - (lower_32_bits(ring->wptr) &
> 7)) % 8);
>
> @@ -517,8 +

Re: [PATCH v2] drm/amdgpu: Patch csa mc address in IB packet

[Zhu, Rex]

Sorry, Please ignore this patch.


Best Regards

Rex



From: Zhou, David(ChunMing)
Sent: Wednesday, October 24, 2018 2:55 PM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: RE: [PATCH v2] drm/amdgpu: Patch csa mc address in IB packet



> -Original Message-
> From: amd-gfx  On Behalf Of Rex
> Zhu
> Sent: Wednesday, October 24, 2018 2:03 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex 
> Subject: [PATCH v2] drm/amdgpu: Patch csa mc address in IB packet
>
> the csa buffer is used by sdma engine to do context save when preemption
> happens. it the mc address is zero, mean the preemtpion feature(MCBP) is
> disabled.
>
> Signed-off-by: Rex Zhu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 13 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h |  2 ++
>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c   |  8 ++--
>  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c   |  8 ++--
>  4 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
> index 0fb9907..24b80bc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
> @@ -40,3 +40,16 @@ struct amdgpu_sdma_instance *
> amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
>
>return NULL;
>  }
> +
> +int amdgpu_get_sdma_index(struct amdgpu_ring *ring, uint32_t *index) {
> + struct amdgpu_device *adev = ring->adev;
> + int i;
> +
> + for (i = 0; i < adev->sdma.num_instances; i++)
> + if (ring == >sdma.instance[i].ring ||
> + ring == >sdma.instance[i].page)
> + return i;
> +
> + return -EINVAL;
> +}

Loop for checking works,  but looks not good.

If you need ring index, you can define them first as enum, and evaluate enum 
index to ring when ring initializing.

Regards,
David Zhou
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h
> index 479a245..314078a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h
> @@ -26,6 +26,7 @@
>
>  /* max number of IP instances */
>  #define AMDGPU_MAX_SDMA_INSTANCES2
> +#define AMDGPU_SDMA_CSA_SIZE (1024)
>
>  enum amdgpu_sdma_irq {
>AMDGPU_SDMA_IRQ_TRAP0 = 0,
> @@ -96,4 +97,5 @@ struct amdgpu_buffer_funcs {  struct
> amdgpu_sdma_instance *  amdgpu_get_sdma_instance(struct amdgpu_ring
> *ring);
>
> +int amdgpu_get_sdma_index(struct amdgpu_ring *ring, uint32_t *index);
>  #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> index f5e6aa2..fdc5d75 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> @@ -424,7 +424,11 @@ static void sdma_v3_0_ring_emit_ib(struct
> amdgpu_ring *ring,
>   bool ctx_switch)
>  {
>unsigned vmid = GET_VMID(job);
> + uint64_t csa_mc_addr = job ? job->csa_mc_addr : 0;
> + uint32_t i = 0;
>
> + if (amdgpu_get_sdma_index(ring, ))
> + return -EINVAL;
>/* IB packet must end on a 8 DW boundary */
>sdma_v3_0_ring_insert_nop(ring, (10 - (lower_32_bits(ring->wptr) &
> 7)) % 8);
>
> @@ -434,8 +438,8 @@ static void sdma_v3_0_ring_emit_ib(struct
> amdgpu_ring *ring,
>amdgpu_ring_write(ring, lower_32_bits(ib->gpu_addr) & 0xffe0);
>amdgpu_ring_write(ring, upper_32_bits(ib->gpu_addr));
>amdgpu_ring_write(ring, ib->length_dw);
> - amdgpu_ring_write(ring, 0);
> - amdgpu_ring_write(ring, 0);
> + amdgpu_ring_write(ring, lower_32_bits(csa_mc_addr + i *
> AMDGPU_SDMA_CSA_SIZE));
> + amdgpu_ring_write(ring, upper_32_bits(csa_mc_addr + i *
> +AMDGPU_SDMA_CSA_SIZE));
>
>  }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
> b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
> index 2282ac1..e69a584 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
> @@ -507,7 +507,11 @@ static void sdma_v4_0_ring_emit_ib(struct
> amdgpu_ring *ring,
>   bool ctx_switch)
>  {
>unsigned vmid = GET_VMID(job);
> + uint64_t csa_mc_addr = job ? job->csa_mc_addr : 0;
> + uint32_t i = 0;
>
> + if (amdgpu_get_sdma_index(ring, ))
> + return -EINVAL;
>/* IB packet must end on a 8 DW boundary */
>sdma_v4_0_ring_insert_nop(ring, (10 - (lower_32_bits(ring->wptr) &
> 7)) % 8);
>
> @@ -517,8 +521,8 @@ static void sdma_v4

Re: [PATCH] drm/amdgpu: Modify the argument of emit_ib interface

[Zhu, Rex]

Ok, I will refine the patch as you suggested.


Thanks.


Best Regards

Rex




From: amd-gfx  on behalf of Koenig, 
Christian 
Sent: Tuesday, October 23, 2018 9:05 PM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Modify the argument of emit_ib interface


Another concern is more and more parameters may be added to the the common 
interface.

Yeah, that is a rather good argument.

Well in this case please add a wrapper for figuring out the VMID and add the 
job before the ib on the parameter list.

Christian.

Am 23.10.18 um 14:55 schrieb Zhu, Rex:

>Yeah, but that can be calculated in the ring specific function. Can't it?


Yes, we should reserve and map the CSA buffer for gfx/compute/sdma together.


Another concern is more and more parameters may be added to the the common 
interface.


Best Regards

Rex



From: amd-gfx 
<mailto:amd-gfx-boun...@lists.freedesktop.org>
 on behalf of Koenig, Christian 
<mailto:christian.koe...@amd.com>
Sent: Tuesday, October 23, 2018 8:47 PM
To: Zhu, Rex; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amdgpu: Modify the argument of emit_ib interface

Am 23.10.18 um 14:43 schrieb Zhu, Rex:

>Maybe indeed provide the CSA address as parameter instead. It doesn't
>really matter that it is unused by most IP block implementations.

>Alternative is to use a wrapper function to get the VMID from the job.


I preferred to use a wrapper function to get vmid.


Because if use CSA address as parameter, we need to check which ring it is.

The csa address is different between sdma/gfx/compute.

Yeah, but that can be calculated in the ring specific function. Can't it?

I mean if I'm not completely mistaken it is just an offset which needs to be 
added to the base CSA address.

Christian.



Best Regards

Rex







From: Christian König 
<mailto:ckoenig.leichtzumer...@gmail.com>
Sent: Tuesday, October 23, 2018 8:09 PM
To: Zhu, Rex; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amdgpu: Modify the argument of emit_ib interface

Am 23.10.18 um 14:01 schrieb Rex Zhu:
> use the point of struct amdgpu_job as the function
> argument instand of vmid, so the other members of
> struct amdgpu_job can be visit in emit_ib function.
>
> Signed-off-by: Rex Zhu <mailto:rex@amd.com>
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   |  3 +--
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  2 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c  |  2 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h  |  2 +-
>   drivers/gpu/drm/amd/amdgpu/cik_sdma.c|  3 ++-
>   drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c|  3 ++-
>   drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c|  6 --
>   drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c|  6 --
>   drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 24 +---
>   drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c   |  4 +++-
>   drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c   |  4 +++-
>   drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c   |  4 +++-
>   drivers/gpu/drm/amd/amdgpu/si_dma.c  |  3 ++-
>   drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c|  2 +-
>   drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c|  2 +-
>   drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c|  8 ++--
>   drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c|  7 +--
>   drivers/gpu/drm/amd/amdgpu/vce_v3_0.c|  4 +++-
>   drivers/gpu/drm/amd/amdgpu/vce_v4_0.c|  4 +++-
>   drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c| 10 +++---
>   20 files changed, 66 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> index b8963b7..0b227ca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> @@ -221,8 +221,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
> num_ibs,
>!amdgpu_sriov_vf(adev)) /* for SRIOV preemption, 
> Preamble CE ib must be inserted anyway */
>continue;
>
> - amdgpu_ring_emit_ib(ring, ib, job ? job->vmid : 0,
> - need_ctx_switch);
> + amdgpu_ring_emit_ib(ring, ib, job, need_ctx_switch);
>need_ctx_switch = false;
>}
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> index 3cb7fb8..0f0f8fb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> @@ -229,7 +229,7 @@ struct amdgpu_ring {
>   #define amdgpu_ring_get_rptr(r) (r)->funcs->get_rptr((r))
>   #define amdgpu_ring_get_wptr(r) (r)->funcs->get_wptr((r))
>   #define amdg

Re: [PATCH] drm/amdgpu: Modify the argument of emit_ib interface

[Zhu, Rex]

>Yeah, but that can be calculated in the ring specific function. Can't it?


Yes, we should reserve and map the CSA buffer for gfx/compute/sdma together.


Another concern is more and more parameters may be added to the the common 
interface.


Best Regards

Rex



From: amd-gfx  on behalf of Koenig, 
Christian 
Sent: Tuesday, October 23, 2018 8:47 PM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Modify the argument of emit_ib interface

Am 23.10.18 um 14:43 schrieb Zhu, Rex:

>Maybe indeed provide the CSA address as parameter instead. It doesn't
>really matter that it is unused by most IP block implementations.

>Alternative is to use a wrapper function to get the VMID from the job.


I preferred to use a wrapper function to get vmid.


Because if use CSA address as parameter, we need to check which ring it is.

The csa address is different between sdma/gfx/compute.

Yeah, but that can be calculated in the ring specific function. Can't it?

I mean if I'm not completely mistaken it is just an offset which needs to be 
added to the base CSA address.

Christian.



Best Regards

Rex







From: Christian König 
<mailto:ckoenig.leichtzumer...@gmail.com>
Sent: Tuesday, October 23, 2018 8:09 PM
To: Zhu, Rex; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amdgpu: Modify the argument of emit_ib interface

Am 23.10.18 um 14:01 schrieb Rex Zhu:
> use the point of struct amdgpu_job as the function
> argument instand of vmid, so the other members of
> struct amdgpu_job can be visit in emit_ib function.
>
> Signed-off-by: Rex Zhu <mailto:rex@amd.com>
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   |  3 +--
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  2 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c  |  2 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h  |  2 +-
>   drivers/gpu/drm/amd/amdgpu/cik_sdma.c|  3 ++-
>   drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c|  3 ++-
>   drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c|  6 --
>   drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c|  6 --
>   drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 24 +---
>   drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c   |  4 +++-
>   drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c   |  4 +++-
>   drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c   |  4 +++-
>   drivers/gpu/drm/amd/amdgpu/si_dma.c  |  3 ++-
>   drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c|  2 +-
>   drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c|  2 +-
>   drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c|  8 ++--
>   drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c|  7 +--
>   drivers/gpu/drm/amd/amdgpu/vce_v3_0.c|  4 +++-
>   drivers/gpu/drm/amd/amdgpu/vce_v4_0.c|  4 +++-
>   drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c| 10 +++---
>   20 files changed, 66 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> index b8963b7..0b227ca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> @@ -221,8 +221,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
> num_ibs,
>!amdgpu_sriov_vf(adev)) /* for SRIOV preemption, 
> Preamble CE ib must be inserted anyway */
>continue;
>
> - amdgpu_ring_emit_ib(ring, ib, job ? job->vmid : 0,
> - need_ctx_switch);
> + amdgpu_ring_emit_ib(ring, ib, job, need_ctx_switch);
>need_ctx_switch = false;
>}
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> index 3cb7fb8..0f0f8fb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> @@ -229,7 +229,7 @@ struct amdgpu_ring {
>   #define amdgpu_ring_get_rptr(r) (r)->funcs->get_rptr((r))
>   #define amdgpu_ring_get_wptr(r) (r)->funcs->get_wptr((r))
>   #define amdgpu_ring_set_wptr(r) (r)->funcs->set_wptr((r))
> -#define amdgpu_ring_emit_ib(r, ib, vmid, c) (r)->funcs->emit_ib((r), (ib), 
> (vmid), (c))
> +#define amdgpu_ring_emit_ib(r, ib, job, c) ((r)->funcs->emit_ib((r), (ib), 
> (job), (c)))
>   #define amdgpu_ring_emit_pipeline_sync(r) 
> (r)->funcs->emit_pipeline_sync((r))
>   #define amdgpu_ring_emit_vm_flush(r, vmid, addr) 
> (r)->funcs->emit_vm_flush((r), (vmid), (addr))
>   #define amdgpu_ring_emit_fence(r, addr, seq, flags) 
> (r)->funcs->emit_fence((r), (addr), (seq), (flags))
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> index 84dd550..8f98641 100644
> --- a/d

Re: [PATCH] drm/amdgpu: Modify the argument of emit_ib interface

[Zhu, Rex]

>Maybe indeed provide the CSA address as parameter instead. It doesn't
>really matter that it is unused by most IP block implementations.

>Alternative is to use a wrapper function to get the VMID from the job.


I preferred to use a wrapper function to get vmid.


Because if use CSA address as parameter, we need to check which ring it is.

The csa address is different between sdma/gfx/compute.


Best Regards

Rex







From: Christian König 
Sent: Tuesday, October 23, 2018 8:09 PM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Modify the argument of emit_ib interface

Am 23.10.18 um 14:01 schrieb Rex Zhu:
> use the point of struct amdgpu_job as the function
> argument instand of vmid, so the other members of
> struct amdgpu_job can be visit in emit_ib function.
>
> Signed-off-by: Rex Zhu 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c   |  3 +--
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  2 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c  |  2 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h  |  2 +-
>   drivers/gpu/drm/amd/amdgpu/cik_sdma.c|  3 ++-
>   drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c|  3 ++-
>   drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c|  6 --
>   drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c|  6 --
>   drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 24 +---
>   drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c   |  4 +++-
>   drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c   |  4 +++-
>   drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c   |  4 +++-
>   drivers/gpu/drm/amd/amdgpu/si_dma.c  |  3 ++-
>   drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c|  2 +-
>   drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c|  2 +-
>   drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c|  8 ++--
>   drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c|  7 +--
>   drivers/gpu/drm/amd/amdgpu/vce_v3_0.c|  4 +++-
>   drivers/gpu/drm/amd/amdgpu/vce_v4_0.c|  4 +++-
>   drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c| 10 +++---
>   20 files changed, 66 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> index b8963b7..0b227ca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> @@ -221,8 +221,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
> num_ibs,
>!amdgpu_sriov_vf(adev)) /* for SRIOV preemption, 
> Preamble CE ib must be inserted anyway */
>continue;
>
> - amdgpu_ring_emit_ib(ring, ib, job ? job->vmid : 0,
> - need_ctx_switch);
> + amdgpu_ring_emit_ib(ring, ib, job, need_ctx_switch);
>need_ctx_switch = false;
>}
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> index 3cb7fb8..0f0f8fb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> @@ -229,7 +229,7 @@ struct amdgpu_ring {
>   #define amdgpu_ring_get_rptr(r) (r)->funcs->get_rptr((r))
>   #define amdgpu_ring_get_wptr(r) (r)->funcs->get_wptr((r))
>   #define amdgpu_ring_set_wptr(r) (r)->funcs->set_wptr((r))
> -#define amdgpu_ring_emit_ib(r, ib, vmid, c) (r)->funcs->emit_ib((r), (ib), 
> (vmid), (c))
> +#define amdgpu_ring_emit_ib(r, ib, job, c) ((r)->funcs->emit_ib((r), (ib), 
> (job), (c)))
>   #define amdgpu_ring_emit_pipeline_sync(r) 
> (r)->funcs->emit_pipeline_sync((r))
>   #define amdgpu_ring_emit_vm_flush(r, vmid, addr) 
> (r)->funcs->emit_vm_flush((r), (vmid), (addr))
>   #define amdgpu_ring_emit_fence(r, addr, seq, flags) 
> (r)->funcs->emit_fence((r), (addr), (seq), (flags))
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> index 84dd550..8f98641 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> @@ -1032,7 +1032,7 @@ int amdgpu_vce_ring_parse_cs_vm(struct amdgpu_cs_parser 
> *p, uint32_t ib_idx)
>*
>*/
>   void amdgpu_vce_ring_emit_ib(struct amdgpu_ring *ring, struct amdgpu_ib *ib,
> -  unsigned vmid, bool ctx_switch)
> + struct amdgpu_job *job, bool ctx_switch)

The indentation here looks wrong on first glance.

Additional to that I would put the job before the IB in the parameter
list because it is the containing object.

>   {
>amdgpu_ring_write(ring, VCE_CMD_IB);
>amdgpu_ring_write(ring, lower_32_bits(ib->gpu_addr));
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h
> 

Re: [PATCH] drm/amdgpu: Fix amdgpu_vm_alloc_pts failed

[Zhu, Rex]

Hi Christian,


You can reproduce this issue by allocate CSA buffer in baremetal and map them 
to reserved VM address.


Please see the attached patch.


Best Regards

Rex




From: Christian König 
Sent: Tuesday, October 23, 2018 5:01 PM
To: Zhu, Rex; Zhang, Jerry; amd-gfx@lists.freedesktop.org; Deucher, Alexander; 
Koenig, Christian
Subject: Re: [PATCH] drm/amdgpu: Fix amdgpu_vm_alloc_pts failed

Hi guys,

yeah the root PD doesn't necessarily have a power of two entries.

But what exactly was the problem with the original code? Why does 0x 
doesn't work?

The only possible explanation I can see is that somebody tried to use an 
address which is above max_pfn, or how did that trigger?

Thanks,
Christian.

Am 23.10.18 um 07:42 schrieb Zhu, Rex:

No, if the vm size is small, there may only on root pd entry.

we need to make sure the mask >= 0;


Maybe this change revert Christian's commit:


commit 72af632549b97ead9251bb155f08fefd1fb6f5c3
Author: Christian König 
<mailto:christian.koe...@amd.com>
Date:   Sat Sep 15 10:02:13 2018 +0200

drm/amdgpu: add amdgpu_vm_entries_mask v2

We can't get the mask for the root directory from the number of entries.

So add a new function to avoid that problem.


Best Regards

Rex



From: amd-gfx 
<mailto:amd-gfx-boun...@lists.freedesktop.org>
 on behalf of Zhang, Jerry(Junwei) 
<mailto:jerry.zh...@amd.com>
Sent: Tuesday, October 23, 2018 1:12 PM
To: Zhu, Rex; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>; Deucher, 
Alexander; Koenig, Christian
Subject: Re: [PATCH] drm/amdgpu: Fix amdgpu_vm_alloc_pts failed

On 10/23/2018 11:29 AM, Rex Zhu wrote:
> when the VA address located in the last PD entries,
> the alloc_pts will faile.
>
> Use the right PD mask instand of hardcode, suggested
> by jerry.zhang.
>
> Signed-off-by: Rex Zhu <mailto:rex@amd.com>

Thanks to verify that.
Feel free to add
Reviewed-by: Junwei Zhang <mailto:jerry.zh...@amd.com>

Also like to get to know some background about these two functions from
Christian.
Perhaps we may make it more simple, e.g. merging them together.

Regards,
Jerry

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 -
>   1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index 054633b..3939013 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -202,8 +202,11 @@ static unsigned amdgpu_vm_num_entries(struct 
> amdgpu_device *adev,
>   static uint32_t amdgpu_vm_entries_mask(struct amdgpu_device *adev,
>   unsigned int level)
>   {
> + unsigned shift = amdgpu_vm_level_shift(adev,
> +adev->vm_manager.root_level);
> +
>if (level <= adev->vm_manager.root_level)
> - return 0x;
> + return (round_up(adev->vm_manager.max_pfn, 1 << shift) >> 
> shift) - 1;
>else if (level != AMDGPU_VM_PTB)
>return 0x1ff;
>else

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx 
Archives.. Using amd-gfx: To post a message to all the list members, send email 
to amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>. You can 
subscribe to the list, or change your existing subscription, in the sections 
below.





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


From a68c029e2bc5f60fd26d1b0705fee2be80b6f604 Mon Sep 17 00:00:00 2001
From: Rex Zhu 
Date: Tue, 23 Oct 2018 17:07:12 +0800
Subject: [PATCH] debug: create and map csa buffer

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 450b0b7..e0d46b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1658,7 +1658,7 @@ static int amdgpu_device_ip_init(struct amdgpu_device *adev)
 			adev->ip_blocks[i].status.hw = true;
 
 			/* right after GMC hw init, we create CSA */
-			if (amdgpu_sriov_vf(adev)) {
+//			if (amdgpu_sriov_vf(adev)) {
 r = amdgpu_allocate_static_

Re: [PATCH] drm/amdgpu: Fix amdgpu_vm_alloc_pts failed

[Zhu, Rex]

No, if the vm size is small, there may only on root pd entry.

we need to make sure the mask >= 0;


Maybe this change revert Christian's commit:


commit 72af632549b97ead9251bb155f08fefd1fb6f5c3
Author: Christian König 
Date:   Sat Sep 15 10:02:13 2018 +0200

drm/amdgpu: add amdgpu_vm_entries_mask v2

We can't get the mask for the root directory from the number of entries.

So add a new function to avoid that problem.


Best Regards

Rex



From: amd-gfx  on behalf of Zhang, 
Jerry(Junwei) 
Sent: Tuesday, October 23, 2018 1:12 PM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org; Deucher, Alexander; Koenig, 
Christian
Subject: Re: [PATCH] drm/amdgpu: Fix amdgpu_vm_alloc_pts failed

On 10/23/2018 11:29 AM, Rex Zhu wrote:
> when the VA address located in the last PD entries,
> the alloc_pts will faile.
>
> Use the right PD mask instand of hardcode, suggested
> by jerry.zhang.
>
> Signed-off-by: Rex Zhu 

Thanks to verify that.
Feel free to add
Reviewed-by: Junwei Zhang 

Also like to get to know some background about these two functions from
Christian.
Perhaps we may make it more simple, e.g. merging them together.

Regards,
Jerry

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 -
>   1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index 054633b..3939013 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -202,8 +202,11 @@ static unsigned amdgpu_vm_num_entries(struct 
> amdgpu_device *adev,
>   static uint32_t amdgpu_vm_entries_mask(struct amdgpu_device *adev,
>   unsigned int level)
>   {
> + unsigned shift = amdgpu_vm_level_shift(adev,
> +adev->vm_manager.root_level);
> +
>if (level <= adev->vm_manager.root_level)
> - return 0x;
> + return (round_up(adev->vm_manager.max_pfn, 1 << shift) >> 
> shift) - 1;
>else if (level != AMDGPU_VM_PTB)
>return 0x1ff;
>else

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx 
Archives.. Using amd-gfx: To post a message to all the list members, send email 
to amd-gfx@lists.freedesktop.org. You can subscribe to the list, or change your 
existing subscription, in the sections below.


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

Re: [PATCH] drm/amdgpu: Fix amdgpu_vm_alloc_pts failed

[Zhu, Rex]

Thanks Jerry.

Good suggestion.

Use the right mask for PD instand of hardcode.

so don't need to revert the whole patch.


Best Regards

Rex



From: Zhang, Jerry
Sent: Tuesday, October 23, 2018 10:02 AM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org; Koenig, Christian
Subject: Re: [PATCH] drm/amdgpu: Fix amdgpu_vm_alloc_pts failed

On 10/23/2018 12:09 AM, Rex Zhu wrote:
> When the va address located in the last pd entry,

Do you mean the root PD?
maybe we need roundup root PD in amdgpu_vm_entries_mask() like
amdgpu_vm_num_entries().

BTW, looks amdgpu_vm_entries_mask() is going to replace the
amdgpu_vm_num_entries()

Jerry
> the alloc_pts will failed.
> caused by
> "drm/amdgpu: add amdgpu_vm_entries_mask v2"
> commit 72af632549b97ead9251bb155f08fefd1fb6f5c3.
>
> Signed-off-by: Rex Zhu 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 34 
> +++---
>   1 file changed, 7 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index 054633b..1a3af72 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -191,26 +191,6 @@ static unsigned amdgpu_vm_num_entries(struct 
> amdgpu_device *adev,
>   }
>
>   /**
> - * amdgpu_vm_entries_mask - the mask to get the entry number of a PD/PT
> - *
> - * @adev: amdgpu_device pointer
> - * @level: VMPT level
> - *
> - * Returns:
> - * The mask to extract the entry number of a PD/PT from an address.
> - */
> -static uint32_t amdgpu_vm_entries_mask(struct amdgpu_device *adev,
> -unsigned int level)
> -{
> - if (level <= adev->vm_manager.root_level)
> - return 0x;
> - else if (level != AMDGPU_VM_PTB)
> - return 0x1ff;
> - else
> - return AMDGPU_VM_PTE_COUNT(adev) - 1;
> -}
> -
> -/**
>* amdgpu_vm_bo_size - returns the size of the BOs in bytes
>*
>* @adev: amdgpu_device pointer
> @@ -419,17 +399,17 @@ static void amdgpu_vm_pt_start(struct amdgpu_device 
> *adev,
>   static bool amdgpu_vm_pt_descendant(struct amdgpu_device *adev,
>struct amdgpu_vm_pt_cursor *cursor)
>   {
> - unsigned mask, shift, idx;
> + unsigned num_entries, shift, idx;
>
>if (!cursor->entry->entries)
>return false;
>
>BUG_ON(!cursor->entry->base.bo);
> - mask = amdgpu_vm_entries_mask(adev, cursor->level);
> + num_entries = amdgpu_vm_num_entries(adev, cursor->level);
>shift = amdgpu_vm_level_shift(adev, cursor->level);
>
>++cursor->level;
> - idx = (cursor->pfn >> shift) & mask;
> + idx = (cursor->pfn >> shift) % num_entries;
>cursor->parent = cursor->entry;
>cursor->entry = >entry->entries[idx];
>return true;
> @@ -1618,7 +1598,7 @@ static int amdgpu_vm_update_ptes(struct 
> amdgpu_pte_update_params *params,
>amdgpu_vm_pt_start(adev, params->vm, start, );
>while (cursor.pfn < end) {
>struct amdgpu_bo *pt = cursor.entry->base.bo;
> - unsigned shift, parent_shift, mask;
> + unsigned shift, parent_shift, num_entries;
>uint64_t incr, entry_end, pe_start;
>
>if (!pt)
> @@ -1673,9 +1653,9 @@ static int amdgpu_vm_update_ptes(struct 
> amdgpu_pte_update_params *params,
>
>/* Looks good so far, calculate parameters for the update */
>incr = AMDGPU_GPU_PAGE_SIZE << shift;
> - mask = amdgpu_vm_entries_mask(adev, cursor.level);
> - pe_start = ((cursor.pfn >> shift) & mask) * 8;
> - entry_end = (mask + 1) << shift;
> + num_entries = amdgpu_vm_num_entries(adev, cursor.level);
> + pe_start = ((cursor.pfn >> shift) & (num_entries - 1)) * 8;
> + entry_end = num_entries << shift;
>entry_end += cursor.pfn & ~(entry_end - 1);
>entry_end = min(entry_end, end);
>

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

RE: [PATCH v2] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were disabled by user

[Zhu, Rex]

> -Original Message-
> From: Christian König 
> Sent: Wednesday, October 17, 2018 3:11 AM
> To: Zhu, Rex ; Koenig, Christian
> ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if
> they were disabled by user
> 
> Am 16.10.2018 um 21:03 schrieb Zhu, Rex:
> >
> >> -Original Message-
> >> From: Koenig, Christian
> >> Sent: Wednesday, October 17, 2018 2:59 AM
> >> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> >> Subject: Re: [PATCH v2] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if
> >> they were disabled by user
> >>
> >> Am 16.10.2018 um 20:54 schrieb Zhu, Rex:
> >>>> -----Original Message-
> >>>> From: Christian König 
> >>>> Sent: Wednesday, October 17, 2018 2:31 AM
> >>>> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> >>>> Subject: Re: [PATCH v2] drm/amdgpu: Poweroff uvd/vce/vcn/acp block
> >>>> if they were disabled by user
> >>>>
> >>>> Am 16.10.2018 um 20:25 schrieb Rex Zhu:
> >>>>> If user disable uvd/vce/vcn/acp blocks via module parameter
> >>>>> ip_block_mask, driver power off thoser blocks to save power.
> >>>>>
> >>>>> v2: power off uvd/vce/vcn/acp via smu.
> >>>> I'm not sure if that is a good idea.
> >>>>
> >>>> The meaning of the flag is to NOT touch the blocks at all, e.g.
> >>>> pretend they don't even exists.
> >>>>
> >>>> Additional to that the ip_block_mask is only for bringup and
> >>>> debugging and not meant for production use and power saving
> >>>> shouldn't
> >> be an issue there.
> >>> Hi Christian,
> >>>
> >>> This is requested by Chrome project. As there is an S3 issue caused
> >>> by VCE,
> >> and they still don't find the root cause.
> >>> And in Chrome project, they don't need to use vce engine.
> >>> So as a workaround, they want to disable vce and power off the vce
> >>> engine
> >> to save power.
> >>
> >> Oh, please not that stupid idea again! In this case that is a clear NAK.
> >>
> >> The mask isn't necessary stable and this module parameter is
> >> absolutely NOT intended for production use!
> >>
> >> If we want to disable a specific block permanently in a project we
> >> should do so by adding a patch to the specific branch and NOT by
> >> abusing ip_block_mask for it.
> > This is also requested by Chrome project. Customer wish all the patches are
> cherry-pick from drm-next/linux kernel tree.
> > Maybe we need to fix the vce issue on time.
> 
> Yeah, completely agree.
> 
> Exactly that's the kind of stuff why Chrome has the restriction to only 
> cherry-
> pick patches from upstream.
> 
> So we can either go ahead and disable VCE upstream as well or we sit down
> and fix the issue.
> 
> Do you have a bug tracker for that?

Yes, there is a ticket: SWDEV-168119

Regards
Rex
 
> Regards,
> Christian.
> 
> >
> > Best Regards
> > Rex
> >
> >> Regards,
> >> Christian.
> >>
> >>> Best Regards
> >>> Rex
> >>>
> >>>> So I would rather say that this is a NAK.
> >>>>
> >>>> Christian.
> >>>>
> >>>>> Reviewed-by: Alex Deucher 
> >>>>> Signed-off-by: Rex Zhu 
> >>>>> ---
> >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 19
> >>>> +++
> >>>>> 1 file changed, 19 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>>>> index 6fe6ea9..ef9fe50 100644
> >>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>>>> @@ -1776,6 +1776,24 @@ static int
> >>>>> amdgpu_device_set_pg_state(struct amdgpu_device *adev, enum
> >>>>> amd_power
> >>>>>
> >>>>> for (j = 0; j < adev->num_ip_blocks; j++) {
> >>>>> i = state == AMD_PG_STATE_GATE ? j : adev-
> >num_ip_blocks
> >>>> -

RE: [PATCH v2] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were disabled by user

[Zhu, Rex]

> -Original Message-
> From: Koenig, Christian
> Sent: Wednesday, October 17, 2018 2:59 AM
> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if
> they were disabled by user
> 
> Am 16.10.2018 um 20:54 schrieb Zhu, Rex:
> >
> >> -Original Message-
> >> From: Christian König 
> >> Sent: Wednesday, October 17, 2018 2:31 AM
> >> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> >> Subject: Re: [PATCH v2] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if
> >> they were disabled by user
> >>
> >> Am 16.10.2018 um 20:25 schrieb Rex Zhu:
> >>> If user disable uvd/vce/vcn/acp blocks via module parameter
> >>> ip_block_mask, driver power off thoser blocks to save power.
> >>>
> >>> v2: power off uvd/vce/vcn/acp via smu.
> >> I'm not sure if that is a good idea.
> >>
> >> The meaning of the flag is to NOT touch the blocks at all, e.g.
> >> pretend they don't even exists.
> >>
> >> Additional to that the ip_block_mask is only for bringup and
> >> debugging and not meant for production use and power saving shouldn't
> be an issue there.
> > Hi Christian,
> >
> > This is requested by Chrome project. As there is an S3 issue caused by VCE,
> and they still don't find the root cause.
> > And in Chrome project, they don't need to use vce engine.
> > So as a workaround, they want to disable vce and power off the vce engine
> to save power.
> 
> Oh, please not that stupid idea again! In this case that is a clear NAK.
> 
> The mask isn't necessary stable and this module parameter is absolutely NOT
> intended for production use!
> 
> If we want to disable a specific block permanently in a project we should do
> so by adding a patch to the specific branch and NOT by abusing
> ip_block_mask for it.

This is also requested by Chrome project. Customer wish all the patches are 
cherry-pick from drm-next/linux kernel tree.
Maybe we need to fix the vce issue on time. 

Best Regards
Rex

> Regards,
> Christian.
> 
> >
> > Best Regards
> > Rex
> >
> >> So I would rather say that this is a NAK.
> >>
> >> Christian.
> >>
> >>> Reviewed-by: Alex Deucher 
> >>> Signed-off-by: Rex Zhu 
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 19
> >> +++
> >>>1 file changed, 19 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> index 6fe6ea9..ef9fe50 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> @@ -1776,6 +1776,24 @@ static int amdgpu_device_set_pg_state(struct
> >>> amdgpu_device *adev, enum amd_power
> >>>
> >>>   for (j = 0; j < adev->num_ip_blocks; j++) {
> >>>   i = state == AMD_PG_STATE_GATE ? j : adev->num_ip_blocks
> >> - j - 1;
> >>> +
> >>> + /* try to power off VCE/UVD/VCN/ACP if they were disabled
> >> by user */
> >>> + if ((adev->ip_blocks[i].version->type ==
> >> AMD_IP_BLOCK_TYPE_UVD ||
> >>> + adev->ip_blocks[i].version->type ==
> >> AMD_IP_BLOCK_TYPE_VCE ||
> >>> + adev->ip_blocks[i].version->type ==
> >> AMD_IP_BLOCK_TYPE_VCN ||
> >>> + adev->ip_blocks[i].version->type ==
> >> AMD_IP_BLOCK_TYPE_ACP) &&
> >>> + adev->powerplay.pp_funcs->set_powergating_by_smu) {
> >>> + if (!adev->ip_blocks[i].status.valid) {
> >>> +
> >>amdgpu_dpm_set_powergating_by_smu(adev, adev-
> >>> ip_blocks[i].version->type, state == AMD_PG_STATE_GATE ?
> >>> +
> >>true : false);
> >>> + if (r) {
> >>> +
> >>DRM_ERROR("set_powergating_state(gate) of IP block <%s> failed
> >> %d\n",
> >>> +   adev->ip_blocks[i].version->funcs-
> >>> name, r);
> >>> + return r;
> >>> + }
> >>> + }
> >>> + }
> >>> +
> >>>   if (!adev->ip_blocks[i].status.late_initialized)
> >>>   continue;
> >>>   /* skip CG for VCE/UVD, it's handled specially */ @@ 
> >>> -1793,6
> >>> +1811,7 @@ static int amdgpu_device_set_pg_state(struct
> >>> +amdgpu_device
> >> *adev, enum amd_power
> >>>   }
> >>>   }
> >>>   }
> >>> +
> >>>   return 0;
> >>>}
> >>>

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

RE: [PATCH v2] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were disabled by user

[Zhu, Rex]

> -Original Message-
> From: Christian König 
> Sent: Wednesday, October 17, 2018 2:31 AM
> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if
> they were disabled by user
> 
> Am 16.10.2018 um 20:25 schrieb Rex Zhu:
> > If user disable uvd/vce/vcn/acp blocks via module parameter
> > ip_block_mask, driver power off thoser blocks to save power.
> >
> > v2: power off uvd/vce/vcn/acp via smu.
> 
> I'm not sure if that is a good idea.
> 
> The meaning of the flag is to NOT touch the blocks at all, e.g. pretend they
> don't even exists.
> 
> Additional to that the ip_block_mask is only for bringup and debugging and
> not meant for production use and power saving shouldn't be an issue there.

Hi Christian,

This is requested by Chrome project. As there is an S3 issue caused by VCE, and 
they still don't find the root cause.
And in Chrome project, they don't need to use vce engine.
So as a workaround, they want to disable vce and power off the vce engine to 
save power.

Best Regards
Rex
 
> So I would rather say that this is a NAK.
> 
> Christian.
> 
> >
> > Reviewed-by: Alex Deucher 
> > Signed-off-by: Rex Zhu 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 19
> +++
> >   1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index 6fe6ea9..ef9fe50 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -1776,6 +1776,24 @@ static int amdgpu_device_set_pg_state(struct
> > amdgpu_device *adev, enum amd_power
> >
> > for (j = 0; j < adev->num_ip_blocks; j++) {
> > i = state == AMD_PG_STATE_GATE ? j : adev->num_ip_blocks
> - j - 1;
> > +
> > +   /* try to power off VCE/UVD/VCN/ACP if they were disabled
> by user */
> > +   if ((adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_UVD ||
> > +   adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_VCE ||
> > +   adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_VCN ||
> > +   adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_ACP) &&
> > +   adev->powerplay.pp_funcs->set_powergating_by_smu) {
> > +   if (!adev->ip_blocks[i].status.valid) {
> > +
>   amdgpu_dpm_set_powergating_by_smu(adev, adev-
> >ip_blocks[i].version->type, state == AMD_PG_STATE_GATE ?
> > +
>   true : false);
> > +   if (r) {
> > +
>   DRM_ERROR("set_powergating_state(gate) of IP block <%s>
> failed %d\n",
> > + adev->ip_blocks[i].version->funcs-
> >name, r);
> > +   return r;
> > +   }
> > +   }
> > +   }
> > +
> > if (!adev->ip_blocks[i].status.late_initialized)
> > continue;
> > /* skip CG for VCE/UVD, it's handled specially */ @@ -1793,6
> > +1811,7 @@ static int amdgpu_device_set_pg_state(struct amdgpu_device
> *adev, enum amd_power
> > }
> > }
> > }
> > +
> > return 0;
> >   }
> >

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

RE: [PATCH] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were disabled by user

[Zhu, Rex]

The code base is different.
And do you set ip_block_mask = 0xeff to diable vce?

Best Regards
Rex

From: S, Shirish
Sent: Wednesday, October 17, 2018 1:25 AM
To: Zhu, Rex ; Deucher, Alexander ; 
amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were 
disabled by user

Nope, I have just cherry-picked this patch.
Is there any dependency?

Regards,
Shirish S

From: Zhu, Rex
Sent: Tuesday, October 16, 2018 12:15 PM
To: S, Shirish mailto:shiris...@amd.com>>; Deucher, 
Alexander mailto:alexander.deuc...@amd.com>>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: RE: [PATCH] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were 
disabled by user

Do you test based on drm-next branch?

Best Regards
Rex

From: S, Shirish
Sent: Wednesday, October 17, 2018 1:12 AM
To: Deucher, Alexander 
mailto:alexander.deuc...@amd.com>>; Zhu, Rex 
mailto:rex@amd.com>>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: RE: [PATCH] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were 
disabled by user

This patch fails on the very first resume as below:
[   53.632732] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   54.653212] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   55.673692] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   56.694203] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   57.714683] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   58.735164] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   59.755643] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   60.776124] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   61.796608] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   62.817092] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   62.837108] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
giving up!!!
[   62.837112] Power gating vce_v3_0 failed
[   62.837118] [drm:amdgpu_device_ip_suspend_phase1] *ERROR* 
set_powergating_state(gate) of IP block  failed -110

I believe there is some more work left to be done with it.

Regards,
Shirish S

From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 On Behalf Of Deucher, Alexander
Sent: Tuesday, October 16, 2018 9:44 AM
To: Zhu, Rex mailto:rex@amd.com>>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were 
disabled by user


Reviewed-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>


From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Rex Zhu mailto:rex@amd.com>>
Sent: Tuesday, October 16, 2018 1:33:46 AM
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>; 
Deucher, Alexander
Cc: Zhu, Rex
Subject: [PATCH] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were 
disabled by user

If user disable uvd/vce/vcn/acp blocks via module
parameter ip_block_mask,
driver power off thoser blocks to save power.

Signed-off-by: Rex Zhu mailto:rex@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 1e4dd09..3ffee08 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1774,6 +1774,24 @@ static int amdgpu_device_set_pg_state(struct 
amdgpu_device *adev, enum amd_power

 for (j = 0; j < adev->num_ip_blocks; j++) {
 i = state == AMD_PG_STATE_GATE ? j : adev->num_ip_blocks - j - 
1;
+
+   /* try to power off VCE/UVD/VCN/ACP if they were disabled by 
user */
+   if ((adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_UVD 
||
+   adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_VCE ||
+   adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_VCN ||
+   adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_ACP) 
&&
+   adev->ip_blocks[i].version->funcs->set_powergating_state) {
+   if (!adev->ip_blocks[i].status.valid) {
+   r = 
adev->ip_blocks[i].version->funcs->set_powergating_state((void *)adev,
+

RE: [PATCH] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were disabled by user

[Zhu, Rex]

Do you test based on drm-next branch?

Best Regards
Rex

From: S, Shirish
Sent: Wednesday, October 17, 2018 1:12 AM
To: Deucher, Alexander ; Zhu, Rex ; 
amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were 
disabled by user

This patch fails on the very first resume as below:
[   53.632732] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   54.653212] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   55.673692] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   56.694203] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   57.714683] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   58.735164] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   59.755643] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   60.776124] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   61.796608] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   62.817092] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
trying to reset the ECPU!!!
[   62.837108] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding, 
giving up!!!
[   62.837112] Power gating vce_v3_0 failed
[   62.837118] [drm:amdgpu_device_ip_suspend_phase1] *ERROR* 
set_powergating_state(gate) of IP block  failed -110

I believe there is some more work left to be done with it.

Regards,
Shirish S

From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 On Behalf Of Deucher, Alexander
Sent: Tuesday, October 16, 2018 9:44 AM
To: Zhu, Rex mailto:rex@amd.com>>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were 
disabled by user


Reviewed-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>


From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Rex Zhu mailto:rex@amd.com>>
Sent: Tuesday, October 16, 2018 1:33:46 AM
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>; 
Deucher, Alexander
Cc: Zhu, Rex
Subject: [PATCH] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were 
disabled by user

If user disable uvd/vce/vcn/acp blocks via module
parameter ip_block_mask,
driver power off thoser blocks to save power.

Signed-off-by: Rex Zhu mailto:rex@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 1e4dd09..3ffee08 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1774,6 +1774,24 @@ static int amdgpu_device_set_pg_state(struct 
amdgpu_device *adev, enum amd_power

 for (j = 0; j < adev->num_ip_blocks; j++) {
 i = state == AMD_PG_STATE_GATE ? j : adev->num_ip_blocks - j - 
1;
+
+   /* try to power off VCE/UVD/VCN/ACP if they were disabled by 
user */
+   if ((adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_UVD 
||
+   adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_VCE ||
+   adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_VCN ||
+   adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_ACP) 
&&
+   adev->ip_blocks[i].version->funcs->set_powergating_state) {
+   if (!adev->ip_blocks[i].status.valid) {
+   r = 
adev->ip_blocks[i].version->funcs->set_powergating_state((void *)adev,
+   
state);
+   if (r) {
+   DRM_ERROR("set_powergating_state(gate) 
of IP block <%s> failed %d\n",
+ 
adev->ip_blocks[i].version->funcs->name, r);
+   return r;
+   }
+   }
+   }
+
 if (!adev->ip_blocks[i].status.late_initialized)
 continue;
 /* skip CG for VCE/UVD, it's handled specially */
@@ -1791,6 +1809,7 @@ static int amdgpu_device_set_pg_state(struct 
amdgpu_device *adev, enum amd_power
 }
 }
 }
+
 return 0;
 }

--
1.9.1

___
amd-g

RE: [PATCH 2/2] drm/amdgpu: skip vm entries checking while in sriov vf

[Zhu, Rex]

> -Original Message-
> From: amd-gfx  On Behalf Of
> Koenig, Christian
> Sent: Friday, October 12, 2018 3:25 PM
> To: Huang, Ray ; Kuehling, Felix
> ; Min, Frank ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 2/2] drm/amdgpu: skip vm entries checking while in sriov
> vf
> 
> Am 12.10.2018 um 06:05 schrieb Huang, Ray:
> >> -Original Message-
> >> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On
> >> Behalf Of Felix Kuehling
> >> Sent: Friday, October 12, 2018 3:46 AM
> >> To: Koenig, Christian ; Min, Frank
> >> ; amd-gfx@lists.freedesktop.org
> >> Subject: Re: [PATCH 2/2] drm/amdgpu: skip vm entries checking while
> >> in sriov vf
> >>
> >> On 2018-10-11 08:32 AM, Christian König wrote:
> >>> Am 11.10.2018 um 14:09 schrieb Frank.Min:
>  vm page table would be allocated while in amdgpu_vm_init by
>  amdgpu_allocate_static_csa for sriov, so the checking here would be
>  skipped.
> >>> NAK, that checking is actually correct and points out that this
> >>> doesn't work correctly.
> >>>
> >>> Fix the function to be able to handle the case when there are
> >>> already mappings in the VM.
> >> KFD and the Thunk assume that they own the entire address space. If
> >> something is already mapped, KFD and the Thunk would not be aware of
> it.
> >>
> >> amdgpu_allocate_static_csa runs during driver initialization, before
> >> there are any VMs. Looks like amdgpu_map_static_csa is the more
> >> important function here, which currently runs in
> amdgpu_driver_open_kms.
> >>
> >> Could amdgpu_map_static_csa be delayed to the first time user mode
> >> maps memory into the VM through GEM APIs? That way it would allow
> >> turning a VM into a compute VM that hasn't been used for any GEM
> >> memory mappings.
> >>
> > Yes. Frank and I found, while we do acquire_process_vm(), the vm->va RB
> trees are always not empty under SRIOV, because amdgpu_map_static_csa()
> will be called while vm inits under SRIOV, that will actually map the CSA BO 
> to
> the VM and insert the node into vm->va before it acquires process VM in KFD.
> 
> Yeah and exactly that will clash with the KFD.
> 
> Could be that it still works initially because the CSA is not mapped at the
> beginning of the address space IIRC, but we need to clean that up in the long
> term.
> 
> We should either delay adding the CSA BO to the VM (probably best done
> during context creation).

Yes, we planed to create sdma csa buffer when context creation.

> Or we start to make nails with heads and move the CSA BO into the context

So we can add the sdma_csa bo/static_csa  in the struct amdgpu_ctx?

Best Regards
Rex

> altogether. We are going to need this anyway for MCBP, so that would be a
> good first step.

> Ray/Frank can anybody of you take care of this?
> 
> Thanks,
> Christian.
> 
> >
> > Thanks,
> > Ray
> >
> >> Regards,
> >>    Felix
> >>
> >>> Christian.
> >>>
>  Change-Id: Id30b86ad15ae509aeed9ed8ab60c259c88af3df5
>  Signed-off-by: Frank.Min 
>  ---
>     drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 9 +
>     1 file changed, 5 insertions(+), 4 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>  b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>  index 6904d79..6066f87 100644
>  --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>  +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>  @@ -3100,11 +3100,12 @@ int amdgpu_vm_make_compute(struct
>  amdgpu_device *adev, struct amdgpu_vm *vm, uns
>     return r;
>       /* Sanity checks */
>  -    if (!RB_EMPTY_ROOT(>va.rb_root) || vm->root.entries) {
>  -    r = -EINVAL;
>  -    goto unreserve_bo;
>  +    if (!amdgpu_sriov_vf(adev)) {
>  +    if (!RB_EMPTY_ROOT(>va.rb_root) || vm->root.entries) {
>  +    r = -EINVAL;
>  +    goto unreserve_bo;
>  +    }
>     }
>  -
>     if (pasid) {
>     unsigned long flags;
> 
> >>> ___
> >>> 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
> 
> ___
> 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 v2 4/5] drm/amdgpu: Fix unnecessary warning in dmesg

[Zhu, Rex]

Ok.


BTW, Maybe we can remove the module parameter amdgpu_fw_load_type suppor .

It is only used for bring up/debug.


Best Regards

Rex



From: Deucher, Alexander
Sent: Wednesday, October 10, 2018 3:31 AM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 4/5] drm/amdgpu: Fix unnecessary warning in dmesg


Maybe just drop the warning altogether?  We only support SMU loading on VI at 
this point.  Otherwise, we'll need to update this if we ever add a new fw 
loading type.


Alex


From: amd-gfx  on behalf of Rex Zhu 

Sent: Tuesday, October 9, 2018 11:36 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH v2 4/5] drm/amdgpu: Fix unnecessary warning in dmesg

Fix the warning message:
"-1 is not supported on VI"
the -1 is the default fw load type, mean auto.

v2: fix typo

Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index 971549f..01d794d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -297,7 +297,7 @@ enum amdgpu_firmware_load_type
 case CHIP_POLARIS11:
 case CHIP_POLARIS12:
 case CHIP_VEGAM:
-   if (load_type != AMDGPU_FW_LOAD_SMU)
+   if (load_type == AMDGPU_FW_LOAD_DIRECT || load_type == 
AMDGPU_FW_LOAD_PSP)
 pr_warning("%d is not supported on VI\n", load_type);
 return AMDGPU_FW_LOAD_SMU;
 case CHIP_VEGA10:
--
1.9.1

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

RE: [PATCH 3/5] drm/amdgpu: Extract the function of fw loading out of powerplay

[Zhu, Rex]

> -Original Message-
> From: Alex Deucher 
> Sent: Wednesday, October 10, 2018 3:28 AM
> To: Zhu, Rex 
> Cc: amd-gfx list 
> Subject: Re: [PATCH 3/5] drm/amdgpu: Extract the function of fw loading out
> of powerplay
> 
> On Tue, Oct 9, 2018 at 8:45 AM Rex Zhu  wrote:
> >
> > So there is no dependence between gfx/sdma/smu.
> > and for Vi, after IH hw_init, driver load all the smu/gfx/sdma fw. for
> > AI, fw loading is controlled by PSP, after psp hw init, we call the
> > function to check smu fw version.
> >
> > Signed-off-by: Rex Zhu 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 30
> ++
> >  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 11 
> >  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  8 --
> >  drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 20 ---
> >  drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  |  1 -
> >  drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c |  8 ++
> > drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c |  5 
> >  7 files changed, 32 insertions(+), 51 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index 4787571..a6766b3 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -1525,6 +1525,24 @@ static int amdgpu_device_ip_early_init(struct
> amdgpu_device *adev)
> > return 0;
> >  }
> >
> > +static int amdgpu_device_fw_loading(struct amdgpu_device *adev,
> > +uint32_t index) {
> > +   int r = 0;
> > +
> > +   if ((adev->asic_type < CHIP_VEGA10
> > +&& (adev->ip_blocks[index].version->type ==
> AMD_IP_BLOCK_TYPE_IH))
> > +|| (adev->asic_type >= CHIP_VEGA10
> > +&& (adev->ip_blocks[index].version->type ==
> > + AMD_IP_BLOCK_TYPE_PSP))) {
> 
> This seems kind of fragile.  If we change the order again at some point, it 
> will
> break.  How about we check whether hw_init/resume is done or not on the
> blocks we care about or move the checks into the callers and only call when
> we need it?

Hi Alex,

How about split hw_init to hw_init_phase1 and hw_init_phase2 as resume?
We loaded fw(call psp_hw_init and start_smu) between phase1 and phase2.


Regards
Rex

> > +   if (adev->powerplay.pp_funcs->load_firmware) {
> > +   r = adev->powerplay.pp_funcs->load_firmware(adev-
> >powerplay.pp_handle);
> > +   if (r) {
> > +   pr_err("firmware loading failed\n");
> > +   return r;
> > +   }
> > +   }
> > +   }
> > +   return 0;
> > +}
> >  /**
> >   * amdgpu_device_ip_init - run init for hardware IPs
> >   *
> > @@ -1595,6 +1613,9 @@ static int amdgpu_device_ip_init(struct
> amdgpu_device *adev)
> > return r;
> > }
> > adev->ip_blocks[i].status.hw = true;
> > +   r = amdgpu_device_fw_loading(adev, i);
> > +   if (r)
> > +   return r;
> > }
> >
> > amdgpu_xgmi_add_device(adev);
> > @@ -2030,6 +2051,9 @@ static int
> amdgpu_device_ip_reinit_early_sriov(struct amdgpu_device *adev)
> > DRM_INFO("RE-INIT: %s %s\n", 
> > block->version->funcs->name,
> r?"failed":"succeeded");
> > if (r)
> > return r;
> > +   r = amdgpu_device_fw_loading(adev, i);
> > +   if (r)
> > +   return r;
> > }
> > }
> >
> > @@ -2098,6 +2122,9 @@ static int
> amdgpu_device_ip_resume_phase1(struct amdgpu_device *adev)
> >   
> > adev->ip_blocks[i].version->funcs->name, r);
> > return r;
> > }
> > +   r = amdgpu_device_fw_loading(adev, i);
> > +   if (r)
> > +   return r;
> > }
> > }
> >
> > @@ -2134,6 +2161,9 @@ static int
> amdgpu_device_ip_resume_phase2(struct amdgpu_device *adev)
> >   a

RE: [PATCH 4/5] drm/amdgpu: Fix unnecessary warning in dmesg

[Zhu, Rex]

> -Original Message-
> From: Michel Dänzer 
> Sent: Tuesday, October 9, 2018 9:19 PM
> To: Zhu, Rex 
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 4/5] drm/amdgpu: Fix unnecessary warning in dmesg
> 
> On 2018-10-09 2:43 p.m., Rex Zhu wrote:
> > Fix the warning message:
> > "-1 is not supported on VI"
> > the -1 is the default fw load type, mean auto.
> >
> > Signed-off-by: Rex Zhu 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > index f2604ac..e5b13b2 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > @@ -297,7 +297,7 @@ enum amdgpu_firmware_load_type
> > case CHIP_POLARIS11:
> > case CHIP_POLARIS12:
> > case CHIP_VEGAM:
> > -   if (load_type != AMDGPU_FW_LOAD_SMU)
> > +   if (load_type != AMDGPU_FW_LOAD_DIRECT || load_type ==
> AMDGPU_FW_LOAD_PSP)
> 
> AMDGPU_FW_LOAD_PSP == 2 != AMDGPU_FW_LOAD_DIRECT == 0
> 
> I suspect you meant something else here.

Yes, it should be
-   if (load_type != AMDGPU_FW_LOAD_SMU)
+   if (load_type == AMDGPU_FW_LOAD_DIRECT || load_type == 
AMDGPU_FW_LOAD_PSP)

Typo when split the patches.
Thanks for pointing it out.

Best Regards
Rex

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

RE: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when suspend

[Zhu, Rex]

> This means we should either separate filling the BO from allocating it (e.g.
> split amdgpu_ucode_init_bo into two functions) and then only call the filling
> function during GPU reset and resume.

Got it. Thanks.
I will refine this function.

Regards
Rex
> -Original Message-
> From: Christian König 
> Sent: Tuesday, October 9, 2018 2:22 AM
> To: Zhu, Rex ; Koenig, Christian
> ; Deucher, Alexander
> ; Alex Deucher 
> Cc: amd-gfx list 
> Subject: Re: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> suspend
> 
> Am 08.10.2018 um 20:15 schrieb Zhu, Rex:
> >
> >> -Original Message-
> >> From: Koenig, Christian
> >> Sent: Tuesday, October 9, 2018 2:03 AM
> >> To: Zhu, Rex ; Deucher, Alexander
> >> ; Alex Deucher 
> >> Cc: amd-gfx list 
> >> Subject: Re: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> >> suspend
> >>
> >> Am 08.10.2018 um 19:58 schrieb Zhu, Rex:
> >>>> -Original Message-
> >>>> From: Christian König 
> >>>> Sent: Tuesday, October 9, 2018 1:32 AM
> >>>> To: Zhu, Rex ; Deucher, Alexander
> >>>> ; Alex Deucher
> 
> >>>> Cc: amd-gfx list 
> >>>> Subject: Re: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> >>>> suspend
> >>>>
> >>>> Am 08.10.2018 um 18:30 schrieb Zhu, Rex:
> >>>>>> -Original Message-
> >>>>>> From: Deucher, Alexander
> >>>>>> Sent: Tuesday, October 9, 2018 12:21 AM
> >>>>>> To: Zhu, Rex ; Alex Deucher
> >>>> 
> >>>>>> Cc: amd-gfx list 
> >>>>>> Subject: RE: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo
> >>>>>> when suspend
> >>>>>>
> >>>>>>> -Original Message-
> >>>>>>> From: amd-gfx  On Behalf
> >> Of
> >>>>>>> Zhu, Rex
> >>>>>>> Sent: Monday, October 8, 2018 11:57 AM
> >>>>>>> To: Alex Deucher 
> >>>>>>> Cc: amd-gfx list 
> >>>>>>> Subject: RE: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo
> >>>>>>> when suspend
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -Original Message-
> >>>>>>>> From: Alex Deucher 
> >>>>>>>> Sent: Thursday, October 4, 2018 11:35 AM
> >>>>>>>> To: Zhu, Rex 
> >>>>>>>> Cc: amd-gfx list 
> >>>>>>>> Subject: Re: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo
> >>>>>>>> when suspend
> >>>>>>>>
> >>>>>>>> On Wed, Oct 3, 2018 at 7:11 AM Rex Zhu 
> wrote:
> >>>>>>>>> driver don't release the ucode memory when suspend. so don't
> >>>>>>>>> need to allocate bo when resume back.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Rex Zhu 
> >>>>>>>>> ---
> >>>>>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 +-
> >>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> >>>>>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> >>>>>>>>> index 9878212..adfeb93 100644
> >>>>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> >>>>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> >>>>>>>>> @@ -434,7 +434,7 @@ int amdgpu_ucode_init_bo(struct
> >>>>>> amdgpu_device
> >>>>>>>> *adev)
> >>>>>>>>>return 0;
> >>>>>>>>>}
> >>>>>>>>>
> >>>>>>>>> -   if (!adev->in_gpu_reset) {
> >>>>>>>>> +   if (!adev->in_gpu_reset && !adev->in_suspend) {
> >>>>>>>>>err = amdgpu_bo_create_kernel(adev,
> >>>>>>>>> adev->firmware.fw_size,
> >>>>>>>> PAGE_SIZE,
> >>>>

RE: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when suspend

[Zhu, Rex]

> -Original Message-
> From: Koenig, Christian
> Sent: Tuesday, October 9, 2018 2:03 AM
> To: Zhu, Rex ; Deucher, Alexander
> ; Alex Deucher 
> Cc: amd-gfx list 
> Subject: Re: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> suspend
> 
> Am 08.10.2018 um 19:58 schrieb Zhu, Rex:
> >
> >> -Original Message-
> >> From: Christian König 
> >> Sent: Tuesday, October 9, 2018 1:32 AM
> >> To: Zhu, Rex ; Deucher, Alexander
> >> ; Alex Deucher 
> >> Cc: amd-gfx list 
> >> Subject: Re: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> >> suspend
> >>
> >> Am 08.10.2018 um 18:30 schrieb Zhu, Rex:
> >>>> -Original Message-
> >>>> From: Deucher, Alexander
> >>>> Sent: Tuesday, October 9, 2018 12:21 AM
> >>>> To: Zhu, Rex ; Alex Deucher
> >> 
> >>>> Cc: amd-gfx list 
> >>>> Subject: RE: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> >>>> suspend
> >>>>
> >>>>> -Original Message-
> >>>>> From: amd-gfx  On Behalf
> Of
> >>>>> Zhu, Rex
> >>>>> Sent: Monday, October 8, 2018 11:57 AM
> >>>>> To: Alex Deucher 
> >>>>> Cc: amd-gfx list 
> >>>>> Subject: RE: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo
> >>>>> when suspend
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From: Alex Deucher 
> >>>>>> Sent: Thursday, October 4, 2018 11:35 AM
> >>>>>> To: Zhu, Rex 
> >>>>>> Cc: amd-gfx list 
> >>>>>> Subject: Re: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo
> >>>>>> when suspend
> >>>>>>
> >>>>>> On Wed, Oct 3, 2018 at 7:11 AM Rex Zhu  wrote:
> >>>>>>> driver don't release the ucode memory when suspend. so don't
> >>>>>>> need to allocate bo when resume back.
> >>>>>>>
> >>>>>>> Signed-off-by: Rex Zhu 
> >>>>>>> ---
> >>>>>>>drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 +-
> >>>>>>>1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> >>>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> >>>>>>> index 9878212..adfeb93 100644
> >>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> >>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> >>>>>>> @@ -434,7 +434,7 @@ int amdgpu_ucode_init_bo(struct
> >>>> amdgpu_device
> >>>>>> *adev)
> >>>>>>>   return 0;
> >>>>>>>   }
> >>>>>>>
> >>>>>>> -   if (!adev->in_gpu_reset) {
> >>>>>>> +   if (!adev->in_gpu_reset && !adev->in_suspend) {
> >>>>>>>   err = amdgpu_bo_create_kernel(adev,
> >>>>>>> adev->firmware.fw_size,
> >>>>>> PAGE_SIZE,
> >>>>>>>   amdgpu_sriov_vf(adev) ?
> >>>>>> AMDGPU_GEM_DOMAIN_VRAM : AMDGPU_GEM_DOMAIN_GTT,
> >>>>>>>
> >>>>>>> >firmware.fw_buf,
> >>>>>> Not sure if we support S3 in SR-IOV, but I think this will break
> >>>>>> it because we'll lose vram contents and not re-init it.
> >>>>> Confirm with SR-IOV team, S3 was not supported in SR-IOV.
> >>>>>
> >>>>>But I still confused why this patch will break the suspend if
> >>>>> in SRIOV
> >> case?
> >>>> Pinned buffers don't get evicted so if we lose VRAM due to a gpu
> >>>> reset or S3, the data is lost.  GTT is retained since the OS manages 
> >>>> that.
> >>> The gart table was unpinned when suspend.so don't need to create the
> >>> bo
> >> again. we still copy the ucode to the bo.
> >>> And in baremetal,  this function can return directly for S3.
> >> That's irrelevant.
> >>
> >> The whole code is buggy since 

RE: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when suspend

[Zhu, Rex]

> -Original Message-
> From: Christian König 
> Sent: Tuesday, October 9, 2018 1:32 AM
> To: Zhu, Rex ; Deucher, Alexander
> ; Alex Deucher 
> Cc: amd-gfx list 
> Subject: Re: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> suspend
> 
> Am 08.10.2018 um 18:30 schrieb Zhu, Rex:
> >
> >> -Original Message-
> >> From: Deucher, Alexander
> >> Sent: Tuesday, October 9, 2018 12:21 AM
> >> To: Zhu, Rex ; Alex Deucher
> 
> >> Cc: amd-gfx list 
> >> Subject: RE: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> >> suspend
> >>
> >>> -Original Message-
> >>> From: amd-gfx  On Behalf Of
> >>> Zhu, Rex
> >>> Sent: Monday, October 8, 2018 11:57 AM
> >>> To: Alex Deucher 
> >>> Cc: amd-gfx list 
> >>> Subject: RE: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> >>> suspend
> >>>
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Alex Deucher 
> >>>> Sent: Thursday, October 4, 2018 11:35 AM
> >>>> To: Zhu, Rex 
> >>>> Cc: amd-gfx list 
> >>>> Subject: Re: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> >>>> suspend
> >>>>
> >>>> On Wed, Oct 3, 2018 at 7:11 AM Rex Zhu  wrote:
> >>>>> driver don't release the ucode memory when suspend. so don't need
> >>>>> to allocate bo when resume back.
> >>>>>
> >>>>> Signed-off-by: Rex Zhu 
> >>>>> ---
> >>>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 +-
> >>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> >>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> >>>>> index 9878212..adfeb93 100644
> >>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> >>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> >>>>> @@ -434,7 +434,7 @@ int amdgpu_ucode_init_bo(struct
> >> amdgpu_device
> >>>> *adev)
> >>>>>  return 0;
> >>>>>  }
> >>>>>
> >>>>> -   if (!adev->in_gpu_reset) {
> >>>>> +   if (!adev->in_gpu_reset && !adev->in_suspend) {
> >>>>>  err = amdgpu_bo_create_kernel(adev,
> >>>>> adev->firmware.fw_size,
> >>>> PAGE_SIZE,
> >>>>>  amdgpu_sriov_vf(adev) ?
> >>>> AMDGPU_GEM_DOMAIN_VRAM : AMDGPU_GEM_DOMAIN_GTT,
> >>>>>  >firmware.fw_buf,
> >>>> Not sure if we support S3 in SR-IOV, but I think this will break it
> >>>> because we'll lose vram contents and not re-init it.
> >>> Confirm with SR-IOV team, S3 was not supported in SR-IOV.
> >>>
> >>>   But I still confused why this patch will break the suspend if in SRIOV
> case?
> >> Pinned buffers don't get evicted so if we lose VRAM due to a gpu
> >> reset or S3, the data is lost.  GTT is retained since the OS manages that.
> > The gart table was unpinned when suspend.so don't need to create the bo
> again. we still copy the ucode to the bo.
> > And in baremetal,  this function can return directly for S3.
> 
> That's irrelevant.
> 
> The whole code is buggy since amdgpu_ucode_fini_bo() will drop the BO
> independent if we are in reset or in suspend.

We don't call amdgpu_ucode_fini_bo when suspend/sriov_reset.

Rex

> The correct handling here is to remove the if all together and make sure
> amdgpu_bo_create_kernel() is ALWAYS called.
> 
> Cause then it is always re-created if it isn't there already.
> 
> Alternatively we could fix up the callers of amdgpu_ucode_init_bo() and
> amdgpu_ucode_fini_bo() to be correctly balanced.
> 
> Christian.
> 
> >
> > Rex
> >
> >
> >> Alex
> >>
> >>> Rex
> >>>
> >>>> Alex
> >>>>
> >>>>> --
> >>>>> 1.9.1
> >>>>>
> >>>>> ___
> >>>>> 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
> > ___
> > 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 1/5] drm/amdgpu: Don't reallocate ucode bo when suspend

[Zhu, Rex]

> -Original Message-
> From: Deucher, Alexander
> Sent: Tuesday, October 9, 2018 12:21 AM
> To: Zhu, Rex ; Alex Deucher 
> Cc: amd-gfx list 
> Subject: RE: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> suspend
> 
> > -Original Message-
> > From: amd-gfx  On Behalf Of
> > Zhu, Rex
> > Sent: Monday, October 8, 2018 11:57 AM
> > To: Alex Deucher 
> > Cc: amd-gfx list 
> > Subject: RE: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> > suspend
> >
> >
> >
> > > -Original Message-
> > > From: Alex Deucher 
> > > Sent: Thursday, October 4, 2018 11:35 AM
> > > To: Zhu, Rex 
> > > Cc: amd-gfx list 
> > > Subject: Re: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> > > suspend
> > >
> > > On Wed, Oct 3, 2018 at 7:11 AM Rex Zhu  wrote:
> > > >
> > > > driver don't release the ucode memory when suspend. so don't need
> > > > to allocate bo when resume back.
> > > >
> > > > Signed-off-by: Rex Zhu 
> > > > ---
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > > > index 9878212..adfeb93 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > > > @@ -434,7 +434,7 @@ int amdgpu_ucode_init_bo(struct
> amdgpu_device
> > > *adev)
> > > > return 0;
> > > > }
> > > >
> > > > -   if (!adev->in_gpu_reset) {
> > > > +   if (!adev->in_gpu_reset && !adev->in_suspend) {
> > > > err = amdgpu_bo_create_kernel(adev,
> > > > adev->firmware.fw_size,
> > > PAGE_SIZE,
> > > > amdgpu_sriov_vf(adev) ?
> > > AMDGPU_GEM_DOMAIN_VRAM : AMDGPU_GEM_DOMAIN_GTT,
> > > > >firmware.fw_buf,
> > >
> > > Not sure if we support S3 in SR-IOV, but I think this will break it
> > > because we'll lose vram contents and not re-init it.
> >
> > Confirm with SR-IOV team, S3 was not supported in SR-IOV.
> >
> >  But I still confused why this patch will break the suspend if in SRIOV 
> > case?
> 
> Pinned buffers don't get evicted so if we lose VRAM due to a gpu reset or S3,
> the data is lost.  GTT is retained since the OS manages that.

The gart table was unpinned when suspend.so don't need to create the bo again. 
we still copy the ucode to the bo.
And in baremetal,  this function can return directly for S3. 

Rex


> Alex
> 
> >
> > Rex
> >
> > > Alex
> > >
> > > > --
> > > > 1.9.1
> > > >
> > > > ___
> > > > 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
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH 4/5] drm/amdgpu: Add fw load in gfx_v8 and sdma_v3

[Zhu, Rex]

Thanks.
I will fix this error in a following patch.

Best Regards
Rex

> -Original Message-
> From: Alex Deucher 
> Sent: Thursday, October 4, 2018 11:33 AM
> To: Zhu, Rex 
> Cc: amd-gfx list 
> Subject: Re: [PATCH 4/5] drm/amdgpu: Add fw load in gfx_v8 and sdma_v3
> 
> On Wed, Oct 3, 2018 at 7:11 AM Rex Zhu  wrote:
> >
> > gfx and sdma can be initialized before smu.
> >
> > Signed-off-by: Rex Zhu 
> 
> I think sdma_v2_4.c needs a similar update for iceland.  With that fixed:
> Reviewed-by: Alex Deucher 
> 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 11 +++
> > drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  8 
> >  2 files changed, 19 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > index 6b1954e..77e05c1 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > @@ -4180,9 +4180,20 @@ static void gfx_v8_0_rlc_start(struct
> > amdgpu_device *adev)
> >
> >  static int gfx_v8_0_rlc_resume(struct amdgpu_device *adev)  {
> > +   int r;
> > +
> > gfx_v8_0_rlc_stop(adev);
> > gfx_v8_0_rlc_reset(adev);
> > gfx_v8_0_init_pg(adev);
> > +
> > +   if (adev->powerplay.pp_funcs->load_firmware) {
> > +   r = adev->powerplay.pp_funcs->load_firmware(adev-
> >powerplay.pp_handle);
> > +   if (r) {
> > +   pr_err("firmware loading failed\n");
> > +   return r;
> > +   }
> > +   }
> > +
> > gfx_v8_0_rlc_start(adev);
> >
> > return 0;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> > b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> > index 6fb3eda..0bdde7f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> > @@ -788,6 +788,14 @@ static int sdma_v3_0_start(struct amdgpu_device
> > *adev)  {
> > int r;
> >
> > +   if (adev->powerplay.pp_funcs->load_firmware) {
> > +   r = adev->powerplay.pp_funcs->load_firmware(adev-
> >powerplay.pp_handle);
> > +   if (r) {
> > +   pr_err("firmware loading failed\n");
> > +   return r;
> > +   }
> > +   }
> > +
> > /* disable sdma engine before programing it */
> > sdma_v3_0_ctx_switch_enable(adev, false);
> > sdma_v3_0_enable(adev, false);
> > --
> > 1.9.1
> >
> > ___
> > 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 1/5] drm/amdgpu: Don't reallocate ucode bo when suspend

[Zhu, Rex]

> -Original Message-
> From: Alex Deucher 
> Sent: Thursday, October 4, 2018 11:35 AM
> To: Zhu, Rex 
> Cc: amd-gfx list 
> Subject: Re: [PATCH 1/5] drm/amdgpu: Don't reallocate ucode bo when
> suspend
> 
> On Wed, Oct 3, 2018 at 7:11 AM Rex Zhu  wrote:
> >
> > driver don't release the ucode memory when suspend. so don't need to
> > allocate bo when resume back.
> >
> > Signed-off-by: Rex Zhu 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > index 9878212..adfeb93 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > @@ -434,7 +434,7 @@ int amdgpu_ucode_init_bo(struct amdgpu_device
> *adev)
> > return 0;
> > }
> >
> > -   if (!adev->in_gpu_reset) {
> > +   if (!adev->in_gpu_reset && !adev->in_suspend) {
> > err = amdgpu_bo_create_kernel(adev, adev->firmware.fw_size,
> PAGE_SIZE,
> > amdgpu_sriov_vf(adev) ?
> AMDGPU_GEM_DOMAIN_VRAM : AMDGPU_GEM_DOMAIN_GTT,
> > >firmware.fw_buf,
> 
> Not sure if we support S3 in SR-IOV, but I think this will break it because 
> we'll
> lose vram contents and not re-init it.

Confirm with SR-IOV team, S3 was not supported in SR-IOV.

 But I still confused why this patch will break the suspend if in SRIOV case?

Rex

> Alex
> 
> > --
> > 1.9.1
> >
> > ___
> > 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 4/5] drm/amdgpu: Add fan RPM setting via sysfs

[Zhu, Rex]

I may misunderstood. 
If for read, we should not  change the mode to manual.
I will revert the change for fan1_input.

Best Regards
Rex

> -Original Message-
> From: Russell, Kent
> Sent: Friday, October 5, 2018 11:55 PM
> To: Zhu, Rex ; Deucher, Alexander
> ; amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH 4/5] drm/amdgpu: Add fan RPM setting via sysfs
> 
> Thanks, I understand. This threw off one of our automated tests that
> suddenly couldn't read the value of the RPMs because the fan control wasn't
> set to manual at the time.
> 
>  Kent
> 
> -Original Message-
> From: Zhu, Rex
> Sent: Friday, October 05, 2018 11:53 AM
> To: Russell, Kent ; Deucher, Alexander
> ; amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH 4/5] drm/amdgpu: Add fan RPM setting via sysfs
> 
> In order to follow the standard sysfs interfaces for hwmon:
> 
> fan[1-*]_enable
>   Enable or disable the sensors.
>   When disabled the sensor read will return -ENODATA.
>   1: Enable
>   0: Disable
>   RW
> 
> When enable, we set the fan control mode to Manual.
> Disable, we set the fan control mode to Auto.
> 
> Regards
> Rex
> 
> > -Original Message-
> > From: Russell, Kent
> > Sent: Friday, October 5, 2018 10:40 PM
> > To: Zhu, Rex ; Deucher, Alexander
> > ; amd-gfx@lists.freedesktop.org
> > Subject: RE: [PATCH 4/5] drm/amdgpu: Add fan RPM setting via sysfs
> >
> > Sorry, I just saw something with this and had a question. Why does the
> > fan control have to be set to manual to read the RPMs?  I understand
> > that it needs to be manual to set the RPMs, but why would we need that
> > to read the current RPMs?
> >
> >  Kent
> >
> > -Original Message-
> > From: amd-gfx  On Behalf Of
> > Zhu, Rex
> > Sent: Monday, October 01, 2018 9:34 AM
> > To: Deucher, Alexander ; amd-
> > g...@lists.freedesktop.org
> > Subject: RE: [PATCH 4/5] drm/amdgpu: Add fan RPM setting via sysfs
> >
> >
> >
> > > -Original Message-
> > > From: Deucher, Alexander
> > > Sent: Monday, October 1, 2018 9:16 PM
> > > To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> > > Cc: Zhu, Rex 
> > > Subject: RE: [PATCH 4/5] drm/amdgpu: Add fan RPM setting via sysfs
> > >
> > > > -Original Message-
> > > > From: amd-gfx  On Behalf Of
> > > > Rex Zhu
> > > > Sent: Sunday, September 30, 2018 2:18 AM
> > > > To: amd-gfx@lists.freedesktop.org
> > > > Cc: Zhu, Rex 
> > > > Subject: [PATCH 4/5] drm/amdgpu: Add fan RPM setting via sysfs
> > > >
> > > > Add fan1_target for get/set fan speed in RPM unit Add
> > > > fan1_min/fan1_max for get min, max fan speed in RPM unit Add
> > > > fan1_enable to enable/disable the fan1 sensor
> > > >
> > > > v2: query the min/max rpm gpu support instand of hardcode.
> > > >
> > > > Signed-off-by: Rex Zhu 
> > > > ---
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h|   3 +
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 190
> > > > -
> > > >  drivers/gpu/drm/amd/include/kgd_pp_interface.h |   1 +
> > > >  drivers/gpu/drm/amd/powerplay/amd_powerplay.c  |  19 +++
> > > >  4 files changed, 210 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > > > index 42568ae..f972cd1 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > > > @@ -278,6 +278,9 @@ enum amdgpu_pcie_gen {  #define
> > > > amdgpu_dpm_get_fan_speed_rpm(adev, s) \
> > > > ((adev)->powerplay.pp_funcs-
> > > > >get_fan_speed_rpm)((adev)->powerplay.pp_handle, (s))
> > > >
> > > > +#define amdgpu_dpm_set_fan_speed_rpm(adev, s) \
> > > > +
> > > > +((adev)->powerplay.pp_funcs->set_fan_speed_rpm)((adev)-
> > > > >powerplay.pp_ha
> > > > +ndle, (s))
> > > > +
> > > >  #define amdgpu_dpm_get_sclk(adev, l) \
> > > > ((adev)->powerplay.pp_funcs->get_sclk((adev)-
> > > > >powerplay.pp_handle, (l)))
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > > > b/drivers/gpu/drm/amd/

RE: [PATCH 4/5] drm/amdgpu: Add fan RPM setting via sysfs

[Zhu, Rex]

In order to follow the standard sysfs interfaces for hwmon:

fan[1-*]_enable
Enable or disable the sensors.
When disabled the sensor read will return -ENODATA.
1: Enable
0: Disable
RW

When enable, we set the fan control mode to Manual.
Disable, we set the fan control mode to Auto.

Regards
Rex

> -Original Message-
> From: Russell, Kent
> Sent: Friday, October 5, 2018 10:40 PM
> To: Zhu, Rex ; Deucher, Alexander
> ; amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH 4/5] drm/amdgpu: Add fan RPM setting via sysfs
> 
> Sorry, I just saw something with this and had a question. Why does the fan
> control have to be set to manual to read the RPMs?  I understand that it
> needs to be manual to set the RPMs, but why would we need that to read
> the current RPMs?
> 
>  Kent
> 
> -Original Message-
> From: amd-gfx  On Behalf Of Zhu,
> Rex
> Sent: Monday, October 01, 2018 9:34 AM
> To: Deucher, Alexander ; amd-
> g...@lists.freedesktop.org
> Subject: RE: [PATCH 4/5] drm/amdgpu: Add fan RPM setting via sysfs
> 
> 
> 
> > -Original Message-
> > From: Deucher, Alexander
> > Sent: Monday, October 1, 2018 9:16 PM
> > To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> > Cc: Zhu, Rex 
> > Subject: RE: [PATCH 4/5] drm/amdgpu: Add fan RPM setting via sysfs
> >
> > > -Original Message-
> > > From: amd-gfx  On Behalf Of
> > > Rex Zhu
> > > Sent: Sunday, September 30, 2018 2:18 AM
> > > To: amd-gfx@lists.freedesktop.org
> > > Cc: Zhu, Rex 
> > > Subject: [PATCH 4/5] drm/amdgpu: Add fan RPM setting via sysfs
> > >
> > > Add fan1_target for get/set fan speed in RPM unit Add
> > > fan1_min/fan1_max for get min, max fan speed in RPM unit Add
> > > fan1_enable to enable/disable the fan1 sensor
> > >
> > > v2: query the min/max rpm gpu support instand of hardcode.
> > >
> > > Signed-off-by: Rex Zhu 
> > > ---
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h|   3 +
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 190
> > > -
> > >  drivers/gpu/drm/amd/include/kgd_pp_interface.h |   1 +
> > >  drivers/gpu/drm/amd/powerplay/amd_powerplay.c  |  19 +++
> > >  4 files changed, 210 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > > index 42568ae..f972cd1 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > > @@ -278,6 +278,9 @@ enum amdgpu_pcie_gen {  #define
> > > amdgpu_dpm_get_fan_speed_rpm(adev, s) \
> > >   ((adev)->powerplay.pp_funcs-
> > > >get_fan_speed_rpm)((adev)->powerplay.pp_handle, (s))
> > >
> > > +#define amdgpu_dpm_set_fan_speed_rpm(adev, s) \
> > > +
> > > +((adev)->powerplay.pp_funcs->set_fan_speed_rpm)((adev)-
> > > >powerplay.pp_ha
> > > +ndle, (s))
> > > +
> > >  #define amdgpu_dpm_get_sclk(adev, l) \
> > >   ((adev)->powerplay.pp_funcs->get_sclk((adev)-
> > > >powerplay.pp_handle, (l)))
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > > index 18d989e..1d85706 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > > @@ -1172,6 +1172,11 @@ static ssize_t
> > > amdgpu_hwmon_get_fan1_input(struct device *dev,
> > >   struct amdgpu_device *adev = dev_get_drvdata(dev);
> > >   int err;
> > >   u32 speed = 0;
> > > + u32 pwm_mode;
> > > +
> > > + pwm_mode = amdgpu_dpm_get_fan_control_mode(adev);
> > > + if (pwm_mode != AMD_FAN_CTRL_MANUAL)
> > > + return -ENODATA;
> > >
> > >   /* Can't adjust fan when the card is off */
> > >   if  ((adev->flags & AMD_IS_PX) &&
> > > @@ -1187,6 +1192,153 @@ static ssize_t
> > > amdgpu_hwmon_get_fan1_input(struct device *dev,
> > >   return sprintf(buf, "%i\n", speed);  }
> > >
> > > +static ssize_t amdgpu_hwmon_get_fan1_min(struct device *dev,
> > > +  struct device_attribute *attr,
> > > +  char *buf)
> > > +{
> > > + struct amdgpu_device *adev = dev_get_drvdata(dev);
> > > + u32

RE: [PATCH 1/6] drm/amdgpu: Remove FW_LOAD_DIRECT type support on VI

[Zhu, Rex]

I will add some warnings in dmesg.
Thanks


Best Regards
Rex


> -Original Message-
> From: Quan, Evan
> Sent: Sunday, September 30, 2018 10:30 AM
> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex 
> Subject: RE: [PATCH 1/6] drm/amdgpu: Remove FW_LOAD_DIRECT type
> support on VI
> 
> Instead of change the fw load type to AMDGPU_FW_LOAD_SMU silently, it's
> better to warn/error out if user specify FW_LOAD_DIRECT load type.
> 
> Regards,
> Evan
> > -Original Message-
> > From: amd-gfx  On Behalf Of Rex
> > Zhu
> > Sent: 2018年9月30日 0:15
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Zhu, Rex 
> > Subject: [PATCH 1/6] drm/amdgpu: Remove FW_LOAD_DIRECT type
> support on
> > VI
> >
> > AMDGPU_FW_LOAD_DIRECT is used for bring up.
> > Now it don't work any more. so remove the support.
> >
> > Signed-off-by: Rex Zhu 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c |   3 -
> >  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 249 ++-
> > ---
> >  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c|  57 +--
> >  3 files changed, 56 insertions(+), 253 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > index 1fa8bc3..fb2bdf3 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > @@ -297,9 +297,6 @@ enum amdgpu_firmware_load_type
> > case CHIP_POLARIS11:
> > case CHIP_POLARIS12:
> > case CHIP_VEGAM:
> > -   if (!load_type)
> > -   return AMDGPU_FW_LOAD_DIRECT;
> > -   else
> > return AMDGPU_FW_LOAD_SMU;
> > case CHIP_VEGA10:
> > case CHIP_RAVEN:
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > index 2aeef2b..c63ede1 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > @@ -1173,64 +1173,61 @@ static int gfx_v8_0_init_microcode(struct
> > amdgpu_device *adev)
> > }
> > }
> >
> > -   if (adev->firmware.load_type == AMDGPU_FW_LOAD_SMU) {
> > -   info = 
> > >firmware.ucode[AMDGPU_UCODE_ID_CP_PFP];
> > -   info->ucode_id = AMDGPU_UCODE_ID_CP_PFP;
> > -   info->fw = adev->gfx.pfp_fw;
> > -   header = (const struct common_firmware_header *)info-
> > >fw->data;
> > -   adev->firmware.fw_size +=
> > -   ALIGN(le32_to_cpu(header->ucode_size_bytes),
> > PAGE_SIZE);
> > -
> > -   info = 
> > >firmware.ucode[AMDGPU_UCODE_ID_CP_ME];
> > -   info->ucode_id = AMDGPU_UCODE_ID_CP_ME;
> > -   info->fw = adev->gfx.me_fw;
> > -   header = (const struct common_firmware_header *)info-
> > >fw->data;
> > -   adev->firmware.fw_size +=
> > -   ALIGN(le32_to_cpu(header->ucode_size_bytes),
> > PAGE_SIZE);
> > -
> > -   info = 
> > >firmware.ucode[AMDGPU_UCODE_ID_CP_CE];
> > -   info->ucode_id = AMDGPU_UCODE_ID_CP_CE;
> > -   info->fw = adev->gfx.ce_fw;
> > -   header = (const struct common_firmware_header *)info-
> > >fw->data;
> > -   adev->firmware.fw_size +=
> > -   ALIGN(le32_to_cpu(header->ucode_size_bytes),
> > PAGE_SIZE);
> > +   info = >firmware.ucode[AMDGPU_UCODE_ID_CP_PFP];
> > +   info->ucode_id = AMDGPU_UCODE_ID_CP_PFP;
> > +   info->fw = adev->gfx.pfp_fw;
> > +   header = (const struct common_firmware_header *)info->fw->data;
> > +   adev->firmware.fw_size +=
> > +   ALIGN(le32_to_cpu(header->ucode_size_bytes),
> > PAGE_SIZE);
> > +
> > +   info = >firmware.ucode[AMDGPU_UCODE_ID_CP_ME];
> > +   info->ucode_id = AMDGPU_UCODE_ID_CP_ME;
> > +   info->fw = adev->gfx.me_fw;
> > +   header = (const struct common_firmware_header *)info->fw->data;
> > +   adev->firmware.fw_size +=
> > +   ALIGN(le32_to_cpu(header->ucode_size_bytes),
> > PAGE_SIZE);
> > +
> > +   info = >firmware.ucode[AMDGPU_UCODE_ID_CP_CE];
> > +   info->ucode_id = AMDGPU_UCODE_ID_CP_CE;
> > +   info->fw = adev->gfx.ce_fw;
> > +   header = (const struct common_firmware_header *)info->fw->data;
> > +   adev->firmware.fw_size +=
> > +   ALIGN(le32_to_cpu(he

RE: [PATCH 3/4] drm/amdgpu: Add fw load in gfx_v8 and sdma_v3.

[Zhu, Rex]

Yes. So the hw ip smu/gfx/sdma have no dependence. We can initialize 
gfx/sdma/smu or sdma/gfx/smu.

In powerplay, if the fw has been loaded successfully, we will skip the fw 
loading.

Rex 

> -Original Message-
> From: Quan, Evan
> Sent: Sunday, September 30, 2018 12:19 PM
> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex 
> Subject: RE: [PATCH 3/4] drm/amdgpu: Add fw load in gfx_v8 and sdma_v3.
> 
> Will the pp_funcs->load_firmware be called twice?
> 
> Regards,
> Evan
> > -Original Message-
> > From: amd-gfx  On Behalf Of Rex
> > Zhu
> > Sent: 2018年9月30日 0:19
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Zhu, Rex 
> > Subject: [PATCH 3/4] drm/amdgpu: Add fw load in gfx_v8 and sdma_v3.
> >
> > gfx and sdma can be initialized before smu.
> >
> > Signed-off-by: Rex Zhu 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 11 +++
> > drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  8 
> >  2 files changed, 19 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > index 6b1954e..77e05c1 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > @@ -4180,9 +4180,20 @@ static void gfx_v8_0_rlc_start(struct
> > amdgpu_device *adev)
> >
> >  static int gfx_v8_0_rlc_resume(struct amdgpu_device *adev)  {
> > +   int r;
> > +
> > gfx_v8_0_rlc_stop(adev);
> > gfx_v8_0_rlc_reset(adev);
> > gfx_v8_0_init_pg(adev);
> > +
> > +   if (adev->powerplay.pp_funcs->load_firmware) {
> > +   r = adev->powerplay.pp_funcs->load_firmware(adev-
> > >powerplay.pp_handle);
> > +   if (r) {
> > +   pr_err("firmware loading failed\n");
> > +   return r;
> > +   }
> > +   }
> > +
> > gfx_v8_0_rlc_start(adev);
> >
> > return 0;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> > b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> > index 6fb3eda..0bdde7f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> > @@ -788,6 +788,14 @@ static int sdma_v3_0_start(struct amdgpu_device
> > *adev)  {
> > int r;
> >
> > +   if (adev->powerplay.pp_funcs->load_firmware) {
> > +   r = adev->powerplay.pp_funcs->load_firmware(adev-
> > >powerplay.pp_handle);
> > +   if (r) {
> > +   pr_err("firmware loading failed\n");
> > +   return r;
> > +   }
> > +   }
> > +
> > /* disable sdma engine before programing it */
> > sdma_v3_0_ctx_switch_enable(adev, false);
> > sdma_v3_0_enable(adev, false);
> > --
> > 1.9.1
> >
> > ___
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH 3/6] drm/amdgpu: Fix cg/pg unexpected disabled when hw init failed

[Zhu, Rex]

> -Original Message-
> From: Quan, Evan
> Sent: Sunday, September 30, 2018 11:03 AM
> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex 
> Subject: RE: [PATCH 3/6] drm/amdgpu: Fix cg/pg unexpected disabled when
> hw init failed
> 
> Comment inline
> 
> > -Original Message-
> > From: amd-gfx  On Behalf Of Rex
> > Zhu
> > Sent: 2018年9月30日 0:15
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Zhu, Rex 
> > Subject: [PATCH 3/6] drm/amdgpu: Fix cg/pg unexpected disabled when hw
> > init failed
> >
> > Check the ip blocks late_initialized state before enable/disable
> > cg/pg, so if hw init failed, cg/pg function will not be executed.
> >
> > Signed-off-by: Rex Zhu 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index 95095a8..94c92f5 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -1656,7 +1656,7 @@ static int amdgpu_device_set_cg_state(struct
> > amdgpu_device *adev,
> >
> > for (j = 0; j < adev->num_ip_blocks; j++) {
> > i = state == AMD_CG_STATE_GATE ? j : adev-
> > >num_ip_blocks - j - 1;
> > -   if (!adev->ip_blocks[i].status.valid)
> > +   if (!adev->ip_blocks[i].status.late_initialized)
> > continue;
> > /* skip CG for VCE/UVD, it's handled specially */
> > if (adev->ip_blocks[i].version->type !=
> AMD_IP_BLOCK_TYPE_UVD && @@
> > -1686,7 +1686,7 @@ static int amdgpu_device_set_pg_state(struct
> > amdgpu_device *adev, enum amd_power
> >
> > for (j = 0; j < adev->num_ip_blocks; j++) {
> > i = state == AMD_PG_STATE_GATE ? j : adev-
> > >num_ip_blocks - j - 1;
> > -   if (!adev->ip_blocks[i].status.valid)
> > +   if (!adev->ip_blocks[i].status.late_initialized)
> > continue;
> > /* skip CG for VCE/UVD, it's handled specially */
> > if (adev->ip_blocks[i].version->type !=
> AMD_IP_BLOCK_TYPE_UVD && @@
> > -1723,7 +1723,7 @@ static int amdgpu_device_ip_late_init(struct
> > amdgpu_device *adev)
> > int i = 0, r;
> >
> > for (i = 0; i < adev->num_ip_blocks; i++) {
> > -   if (!adev->ip_blocks[i].status.valid)
> > +   if (!adev->ip_blocks[i].status.hw)
> [Quan, Evan] typo?
No, In late_init, we check the hw_init status.

Rex
> > continue;
> > if (adev->ip_blocks[i].version->funcs->late_init) {
> > r = adev->ip_blocks[i].version->funcs->late_init((void
> > *)adev); @@ -1732,8 +1732,8 @@ static int
> > amdgpu_device_ip_late_init(struct amdgpu_device *adev)
> >   adev->ip_blocks[i].version->funcs-
> > >name, r);
> > return r;
> > }
> > -   adev->ip_blocks[i].status.late_initialized = true;
> > }
> > +   adev->ip_blocks[i].status.late_initialized = true;
> > }
> >
> > amdgpu_device_set_cg_state(adev, AMD_CG_STATE_GATE);
> > --
> > 1.9.1
> >
> > ___
> > 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 4/5] drm/amdgpu: Add fan RPM setting via sysfs

[Zhu, Rex]

> -Original Message-
> From: Deucher, Alexander
> Sent: Monday, October 1, 2018 9:16 PM
> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex 
> Subject: RE: [PATCH 4/5] drm/amdgpu: Add fan RPM setting via sysfs
> 
> > -Original Message-
> > From: amd-gfx  On Behalf Of Rex
> > Zhu
> > Sent: Sunday, September 30, 2018 2:18 AM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Zhu, Rex 
> > Subject: [PATCH 4/5] drm/amdgpu: Add fan RPM setting via sysfs
> >
> > Add fan1_target for get/set fan speed in RPM unit Add
> > fan1_min/fan1_max for get min, max fan speed in RPM unit Add
> > fan1_enable to enable/disable the fan1 sensor
> >
> > v2: query the min/max rpm gpu support instand of hardcode.
> >
> > Signed-off-by: Rex Zhu 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h|   3 +
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 190
> > -
> >  drivers/gpu/drm/amd/include/kgd_pp_interface.h |   1 +
> >  drivers/gpu/drm/amd/powerplay/amd_powerplay.c  |  19 +++
> >  4 files changed, 210 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > index 42568ae..f972cd1 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > @@ -278,6 +278,9 @@ enum amdgpu_pcie_gen {  #define
> > amdgpu_dpm_get_fan_speed_rpm(adev, s) \
> > ((adev)->powerplay.pp_funcs-
> > >get_fan_speed_rpm)((adev)->powerplay.pp_handle, (s))
> >
> > +#define amdgpu_dpm_set_fan_speed_rpm(adev, s) \
> > +
> > +((adev)->powerplay.pp_funcs->set_fan_speed_rpm)((adev)-
> > >powerplay.pp_ha
> > +ndle, (s))
> > +
> >  #define amdgpu_dpm_get_sclk(adev, l) \
> > ((adev)->powerplay.pp_funcs->get_sclk((adev)-
> > >powerplay.pp_handle, (l)))
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > index 18d989e..1d85706 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > @@ -1172,6 +1172,11 @@ static ssize_t
> > amdgpu_hwmon_get_fan1_input(struct device *dev,
> > struct amdgpu_device *adev = dev_get_drvdata(dev);
> > int err;
> > u32 speed = 0;
> > +   u32 pwm_mode;
> > +
> > +   pwm_mode = amdgpu_dpm_get_fan_control_mode(adev);
> > +   if (pwm_mode != AMD_FAN_CTRL_MANUAL)
> > +   return -ENODATA;
> >
> > /* Can't adjust fan when the card is off */
> > if  ((adev->flags & AMD_IS_PX) &&
> > @@ -1187,6 +1192,153 @@ static ssize_t
> > amdgpu_hwmon_get_fan1_input(struct device *dev,
> > return sprintf(buf, "%i\n", speed);
> >  }
> >
> > +static ssize_t amdgpu_hwmon_get_fan1_min(struct device *dev,
> > +struct device_attribute *attr,
> > +char *buf)
> > +{
> > +   struct amdgpu_device *adev = dev_get_drvdata(dev);
> > +   u32 min_rpm = 0;
> > +   u32 size = sizeof(min_rpm);
> > +   int r;
> > +
> > +   if (!adev->powerplay.pp_funcs->read_sensor)
> > +   return -EINVAL;
> > +
> > +   r = amdgpu_dpm_read_sensor(adev,
> > AMDGPU_PP_SENSOR_MIN_FAN_RPM,
> > +  (void *)_rpm, );
> > +   if (r)
> > +   return r;
> > +
> > +   return snprintf(buf, PAGE_SIZE, "%d\n", min_rpm); }
> > +
> > +static ssize_t amdgpu_hwmon_get_fan1_max(struct device *dev,
> > +struct device_attribute *attr,
> > +char *buf)
> > +{
> > +   struct amdgpu_device *adev = dev_get_drvdata(dev);
> > +   u32 max_rpm = 0;
> > +   u32 size = sizeof(max_rpm);
> > +   int r;
> > +
> > +   if (!adev->powerplay.pp_funcs->read_sensor)
> > +   return -EINVAL;
> > +
> > +   r = amdgpu_dpm_read_sensor(adev,
> > AMDGPU_PP_SENSOR_MAX_FAN_RPM,
> > +  (void *)_rpm, );
> > +   if (r)
> > +   return r;
> > +
> > +   return snprintf(buf, PAGE_SIZE, "%d\n", max_rpm); }
> > +
> > +static ssize_t amdgpu_hwmon_get_fan1_target(struct device *dev,
> > +  struct device_attribute *attr,
> > +  char *buf)
> > +{
> > +   

Re: [PATCH v2] drm/amd/pp: Export load_firmware interface

[Zhu, Rex]

Sorry, Please ignore this patch.




Best Regards

Rex


From: amd-gfx  on behalf of Rex Zhu 

Sent: Thursday, September 27, 2018 9:55 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH v2] drm/amd/pp: Export load_firmware interface

Export this interface for the AMDGPU_FW_LOAD_SMU type.
gfx/sdma can request smu to load firmware.

Split the smu7/8_start_smu function into two functions
1. start_smu, used for load smu firmware in smu7/8 and
   check smu firmware version.
2. request_smu_load_fw, used for load other ip's firmware
   on smu7/8 and add firmware loading staus check.

v2: default fw loading type is via smu for VI, driver call smu
to load all fw at the begin of hw init.

Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/amdgpu/vi.c| 16 ++
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c  | 20 
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c |  4 +-
 .../gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c  | 25 -
 .../drm/amd/powerplay/smumgr/polaris10_smumgr.c|  4 +-
 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 59 +-
 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.h |  3 +-
 drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c | 46 -
 .../gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c| 12 -
 .../gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c|  4 +-
 10 files changed, 86 insertions(+), 107 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 88b57a5..3384a15 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1222,6 +1222,16 @@ static int vi_common_hw_init(void *handle)
 /* enable the doorbell aperture */
 vi_enable_doorbell_aperture(adev, true);

+   if (adev->firmware.load_type == AMDGPU_FW_LOAD_SMU) {
+   if (adev->powerplay.pp_funcs->load_firmware) {
+   amdgpu_ucode_init_bo(adev);
+   if 
(adev->powerplay.pp_funcs->load_firmware(adev->powerplay.pp_handle)) {
+   adev->firmware.load_type = 
AMDGPU_FW_LOAD_DIRECT;
+   amdgpu_ucode_fini_bo(adev);
+   }
+   }
+   }
+
 return 0;
 }

@@ -1235,6 +1245,12 @@ static int vi_common_hw_fini(void *handle)
 if (amdgpu_sriov_vf(adev))
 xgpu_vi_mailbox_put_irq(adev);

+   if (adev->firmware.load_type == AMDGPU_FW_LOAD_SMU) {
+   release_firmware(adev->pm.fw);
+   adev->pm.fw = NULL;
+   amdgpu_ucode_fini_bo(adev);
+   }
+
 return 0;
 }

diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index aff7c14..5dc8fb9 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -109,12 +109,6 @@ static int pp_sw_fini(void *handle)

 hwmgr_sw_fini(hwmgr);

-   if (adev->firmware.load_type == AMDGPU_FW_LOAD_SMU) {
-   release_firmware(adev->pm.fw);
-   adev->pm.fw = NULL;
-   amdgpu_ucode_fini_bo(adev);
-   }
-
 return 0;
 }

@@ -124,9 +118,6 @@ static int pp_hw_init(void *handle)
 struct amdgpu_device *adev = handle;
 struct pp_hwmgr *hwmgr = adev->powerplay.pp_handle;

-   if (adev->firmware.load_type == AMDGPU_FW_LOAD_SMU)
-   amdgpu_ucode_init_bo(adev);
-
 ret = hwmgr_hw_init(hwmgr);

 if (ret)
@@ -275,7 +266,16 @@ static int pp_set_clockgating_state(void *handle,

 static int pp_dpm_load_fw(void *handle)
 {
-   return 0;
+   struct pp_hwmgr *hwmgr = handle;
+   int ret = 0;
+
+   if (!hwmgr || !hwmgr->smumgr_funcs)
+   return -EINVAL;
+
+   if (hwmgr->smumgr_funcs->request_smu_load_fw)
+   ret = hwmgr->smumgr_funcs->request_smu_load_fw(hwmgr);
+
+   return ret;
 }

 static int pp_dpm_fw_loading_complete(void *handle)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
index b6b62a7..ffd7d78 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
@@ -310,8 +310,6 @@ static int fiji_start_smu(struct pp_hwmgr *hwmgr)
 offsetof(SMU73_Firmware_Header, SoftRegisters),
 &(priv->smu7_data.soft_regs_start), 0x4);

-   result = smu7_request_smu_load_fw(hwmgr);
-
 return result;
 }

@@ -2643,7 +2641,7 @@ static int fiji_update_dpm_settings(struct pp_hwmgr 
*hwmgr,
 .smu_fini = _smu_fini,
 .start_smu = _start_smu,
 .check_fw_load_finish = _check_fw_load_finish,
-   .request_smu_load_fw = _reload_firmware,
+   .request_smu_load_fw = _request_smu_load_fw,
 

RE: [PATCH 6/7] drm/amd/pp: Export load_firmware interface

[Zhu, Rex]

> -Original Message-
> From: Alex Deucher 
> Sent: Wednesday, September 26, 2018 11:39 PM
> To: Zhu, Rex 
> Cc: amd-gfx list 
> Subject: Re: [PATCH 6/7] drm/amd/pp: Export load_firmware interface
> 
> On Wed, Sep 26, 2018 at 11:21 AM Zhu, Rex  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Alex Deucher 
> > > Sent: Wednesday, September 26, 2018 10:15 PM
> > > To: Zhu, Rex 
> > > Cc: amd-gfx list 
> > > Subject: Re: [PATCH 6/7] drm/amd/pp: Export load_firmware interface
> > >
> > > On Wed, Sep 26, 2018 at 8:53 AM Rex Zhu  wrote:
> > > >
> > > > Export this interface for the AMDGPU_FW_LOAD_SMU type.
> > > > gfx/sdma can request smu to load firmware.
> > > >
> > > > Split the smu7/8_start_smu function into two functions 1.
> > > > start_smu, used for load smu firmware in smu7/8 and
> > > >check smu firmware version.
> > > > 2. request_smu_load_fw, used for load other ip's firmware
> > > >on smu7/8 and add firmware loading staus check.
> > > >
> > > > Signed-off-by: Rex Zhu 
> > >
> > > Don't we need to convert sdma to use this interface as well?
> >
> > When load firmware via smu, I load all the
> firmwares(rlc/ce/pfp/me/mec/sdma) at one time.
> > So just need to call  the interface when load rlc firmware.
> > We also can load the firmware separately with ucode mask.
> 
> I see.  So we rely on the call from the gfx IP to load all the FWs.
> It might be better to be more explicit.  E.g., if someone disables the gfx IP 
> via
> the ip_block_mask parameter, that would break sdma.

I didn't consider that aspect.
We can load firmware separately with ucode_id.
Or just call this function again in sdma to load all the firmware.
When firmware is loaded , clean the reload_fw in Patch5.


Best Regards
Rex





> Alex
> 
> >
> >
> > > Alex
> > >
> > > > ---
> > > >  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 11 +++-
> > > >  drivers/gpu/drm/amd/powerplay/amd_powerplay.c  | 14 +++--
> > > >  drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c |  4 +-
> > > > .../gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c  | 25 -
> > > >  .../drm/amd/powerplay/smumgr/polaris10_smumgr.c|  4 +-
> > > >  drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 59
> > > > +-
> > > > drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.h |  3 +-
> > > drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c | 46
> --
> > > ---
> > > >  .../gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c| 12 -
> > > >  .../gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c|  4 +-
> > > >  10 files changed, 79 insertions(+), 103 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > > > b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > > > index 2aeef2b..f020f6f 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > > > @@ -4216,10 +4216,17 @@ static int gfx_v8_0_rlc_resume(struct
> > > amdgpu_device *adev)
> > > > if (adev->firmware.load_type == AMDGPU_FW_LOAD_DIRECT) {
> > > > /* legacy rlc firmware loading */
> > > > r = gfx_v8_0_rlc_load_microcode(adev);
> > > > -   if (r)
> > > > -   return r;
> > > > +   } else if (adev->firmware.load_type == AMDGPU_FW_LOAD_SMU
> > > > + &&
> > > adev->powerplay.pp_funcs->load_firmware) {
> > > > +   amdgpu_ucode_init_bo(adev);
> > > > +   r = adev->powerplay.pp_funcs->load_firmware(adev-
> > > >powerplay.pp_handle);
> > > > +   } else {
> > > > +   r = -EINVAL;
> > > > }
> > > >
> > > > +   if (r) {
> > > > +   pr_err("firmware loading failed\n");
> > > > +   return r;
> > > > +   }
> > > > gfx_v8_0_rlc_start(adev);
> > > >
> > > > return 0;
> > > > diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> > > > b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> > > > index aff7c14..3bc825c 100644
> > > > --- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c

RE: [PATCH 6/7] drm/amd/pp: Export load_firmware interface

[Zhu, Rex]

> -Original Message-
> From: Alex Deucher 
> Sent: Wednesday, September 26, 2018 10:15 PM
> To: Zhu, Rex 
> Cc: amd-gfx list 
> Subject: Re: [PATCH 6/7] drm/amd/pp: Export load_firmware interface
> 
> On Wed, Sep 26, 2018 at 8:53 AM Rex Zhu  wrote:
> >
> > Export this interface for the AMDGPU_FW_LOAD_SMU type.
> > gfx/sdma can request smu to load firmware.
> >
> > Split the smu7/8_start_smu function into two functions 1. start_smu,
> > used for load smu firmware in smu7/8 and
> >check smu firmware version.
> > 2. request_smu_load_fw, used for load other ip's firmware
> >on smu7/8 and add firmware loading staus check.
> >
> > Signed-off-by: Rex Zhu 
> 
> Don't we need to convert sdma to use this interface as well?

When load firmware via smu, I load all the firmwares(rlc/ce/pfp/me/mec/sdma) at 
one time.
So just need to call  the interface when load rlc firmware.
We also can load the firmware separately with ucode mask.


> Alex
> 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 11 +++-
> >  drivers/gpu/drm/amd/powerplay/amd_powerplay.c  | 14 +++--
> >  drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c |  4 +-
> > .../gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c  | 25 -
> >  .../drm/amd/powerplay/smumgr/polaris10_smumgr.c|  4 +-
> >  drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 59
> > +-
> > drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.h |  3 +-
> drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c | 46 --
> ---
> >  .../gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c| 12 -
> >  .../gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c|  4 +-
> >  10 files changed, 79 insertions(+), 103 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > index 2aeef2b..f020f6f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > @@ -4216,10 +4216,17 @@ static int gfx_v8_0_rlc_resume(struct
> amdgpu_device *adev)
> > if (adev->firmware.load_type == AMDGPU_FW_LOAD_DIRECT) {
> > /* legacy rlc firmware loading */
> > r = gfx_v8_0_rlc_load_microcode(adev);
> > -   if (r)
> > -   return r;
> > +   } else if (adev->firmware.load_type == AMDGPU_FW_LOAD_SMU &&
> adev->powerplay.pp_funcs->load_firmware) {
> > +   amdgpu_ucode_init_bo(adev);
> > +   r = adev->powerplay.pp_funcs->load_firmware(adev-
> >powerplay.pp_handle);
> > +   } else {
> > +   r = -EINVAL;
> > }
> >
> > +   if (r) {
> > +   pr_err("firmware loading failed\n");
> > +   return r;
> > +   }
> > gfx_v8_0_rlc_start(adev);
> >
> > return 0;
> > diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> > b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> > index aff7c14..3bc825c 100644
> > --- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> > +++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> > @@ -124,9 +124,6 @@ static int pp_hw_init(void *handle)
> > struct amdgpu_device *adev = handle;
> > struct pp_hwmgr *hwmgr = adev->powerplay.pp_handle;
> >
> > -   if (adev->firmware.load_type == AMDGPU_FW_LOAD_SMU)
> > -   amdgpu_ucode_init_bo(adev);
> > -
> > ret = hwmgr_hw_init(hwmgr);
> >
> > if (ret)
> > @@ -275,7 +272,16 @@ static int pp_set_clockgating_state(void *handle,
> >
> >  static int pp_dpm_load_fw(void *handle)  {
> > -   return 0;
> > +   struct pp_hwmgr *hwmgr = handle;
> > +   int ret = 0;
> > +
> > +   if (!hwmgr || !hwmgr->smumgr_funcs)
> > +   return -EINVAL;
> > +
> > +   if (hwmgr->smumgr_funcs->request_smu_load_fw)
> > +   ret = hwmgr->smumgr_funcs->request_smu_load_fw(hwmgr);
> > +
> > +   return ret;
> >  }
> >
> >  static int pp_dpm_fw_loading_complete(void *handle) diff --git
> > a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
> > b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
> > index b6b62a7..ffd7d78 100644
> > --- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
> > @@ -310,8 +310,6 @@ static int fiji_start_smu(struct pp_hwmgr *hwmgr)
> > 

Re: [PATCH] drm/amdgpu: Fix copy error in uvd_v6/7_0.c

[Zhu, Rex]

Ok. I will remove the code.


Best Regards

Rex



From: Christian König 
Sent: Wednesday, September 26, 2018 8:45 PM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Fix copy error in uvd_v6/7_0.c

Am 26.09.2018 um 14:41 schrieb Rex Zhu:
> Signed-off-by: Rex Zhu 

Actually that code can just be removed because uvd_*_enc_get_destroy_msg
is only called with direct=true.

Christian.

> ---
>   drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 2 +-
>   drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c 
> b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
> index 8ef4a53..2ceab76 100644
> --- a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
> @@ -313,7 +313,7 @@ static int uvd_v6_0_enc_get_destroy_msg(struct 
> amdgpu_ring *ring,
>if (direct)
>r = amdgpu_job_submit_direct(job, ring, );
>else
> - r = amdgpu_job_submit(job, >adev->vce.entity,
> + r = amdgpu_job_submit(job, >adev->uvd.entity,
>  AMDGPU_FENCE_OWNER_UNDEFINED, );
>if (r)
>goto err;
> diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c 
> b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
> index a289f6a..31a9665 100644
> --- a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
> @@ -320,7 +320,7 @@ int uvd_v7_0_enc_get_destroy_msg(struct amdgpu_ring 
> *ring, uint32_t handle,
>if (direct)
>r = amdgpu_job_submit_direct(job, ring, );
>else
> - r = amdgpu_job_submit(job, >adev->vce.entity,
> + r = amdgpu_job_submit(job, >adev->uvd.entity,
>  AMDGPU_FENCE_OWNER_UNDEFINED, );
>if (r)
>goto err;

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

RE: [PATCH v2] drm/amdgpu:No action when VCN PG state is unchanged

[Zhu, Rex]

> -Original Message-
> From: amd-gfx  On Behalf Of
> James Zhu
> Sent: Friday, September 21, 2018 10:22 PM
> To: Zhu, Rex ; Koenig, Christian
> ; Zhu, James ; Alex
> Deucher 
> Cc: James Zhu ; amd-gfx list  g...@lists.freedesktop.org>
> Subject: Re: [PATCH v2] drm/amdgpu:No action when VCN PG state is
> unchanged
> 
> 
> 
> On 2018-09-21 10:05 AM, Zhu, Rex wrote:
> > In my understand, when  dpg mode enabled,  we don't need to power
> > up/down VCN via SMU and Also don't need to set vcn power gate/ungate
> state.
> >
> > Just need to enable the dpg mode.
> >
> > If not true, please correct me.
> You are right.  Under DPG mode, vcn_v1_0_start is used to setup DPG mode
> instead of ungating power.
> For code reuse purpose, the function/variable name may have different
> connotation under different mode.

Did your patch base on tip drm-next code?

Rex
 
> James
> >
> > Best Regards
> > Rex
> >
> >
> >
> >
> >
> >> -Original Message-
> >> From: amd-gfx  On Behalf Of
> >> Christian König
> >> Sent: Friday, September 21, 2018 8:53 PM
> >> To: Zhu, James ; Alex Deucher
> >> 
> >> Cc: James Zhu ; Zhu, James ;
> >> amd-gfx list 
> >> Subject: Re: [PATCH v2] drm/amdgpu:No action when VCN PG state is
> >> unchanged
> >>
> >> Am 21.09.2018 um 14:28 schrieb James Zhu:
> >>>
> >>> On 2018-09-20 01:54 PM, Christian König wrote:
> >>>> Am 20.09.2018 um 18:24 schrieb James Zhu:
> >>>>>
> >>>>> On 2018-09-20 11:49 AM, Alex Deucher wrote:
> >>>>>> On Thu, Sep 20, 2018 at 11:27 AM James Zhu 
> >> wrote:
> >>>>>>>
> >>>>>>> On 2018-09-20 11:14 AM, Alex Deucher wrote:
> >>>>>>>> On Thu, Sep 13, 2018 at 4:56 PM James Zhu 
> >> wrote:
> >>>>>>>>> When VCN PG state is unchanged, it is unnecessary to reset
> >>>>>>>>> power gate state
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: James Zhu 
> >>>>>>>>> ---
> >>>>>>>>>     drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h |  1 +
> >>>>>>>>>     drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c   | 12 ++--
> >>>>>>>>>     2 files changed, 11 insertions(+), 2 deletions(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> >>>>>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> >>>>>>>>> index 0b0b863..d2219ab 100644
> >>>>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> >>>>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> >>>>>>>>> @@ -69,6 +69,7 @@ struct amdgpu_vcn {
> >>>>>>>>>    struct amdgpu_ring  ring_jpeg;
> >>>>>>>>>    struct amdgpu_irq_src   irq;
> >>>>>>>>>    unsigned    num_enc_rings;
> >>>>>>>>> +   enum amd_powergating_state cur_state;
> >>>>>>>> Does the default value (0) at init time properly reflect the
> >>>>>>>> default powergating state?  If so,
> >>>>>>>> Acked-by: Alex Deucher 
> >>>>>>> Yes, the below code shows it will be set to 0 during driver load
> >>>>>>> stage.
> >>>>>> Yes, I understand that.  Is 0 (AMD_PG_STATE_GATE) what we want
> as
> >>>>>> the default though?  The first time the code runs are we going to
> >>>>>> do the right thing or is the code going to return early?  IIRC,
> >>>>>> the hw default is ungated.
> >>>>> cur_state is used for tracking driver SW PG state, not HW  PG state.
> >>>>> I though no matter what HW  PG state is after device powers up,
> >>>>> when first vcn ring is scheduled to run,
> >>>>> begin_use->set_powergating_state->vcn_v1_0_start->ungate
> >>>>> power/clock->Boot_VCPU  will be tried.
> >>>>>
> >>>>> For DPG mode, the ungate power/clock , boot VCPU will not actually
> >>>>> be activated during start setup stage, and only be activated
> >>>>> during ring run stage

RE: [PATCH 4/4] drm/amdgpu: Change the gfx/sdma init/fini sequence

[Zhu, Rex]

> -Original Message-
> From: Vishwakarma, Pratik
> Sent: Friday, September 21, 2018 12:34 PM
> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org; Zhou,
> Hang 
> Subject: Re: [PATCH 4/4] drm/amdgpu: Change the gfx/sdma init/fini
> sequence
> 
> On 9/20/2018 3:37 PM, Rex Zhu wrote:
> > initialize gfx/sdma before dpm features enabled.
> > and disable dpm features before gfx/sdma fini.
> >
> > Signed-off-by: Rex Zhu 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/cik.c  | 17 +
> >   drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 11 +--
> >   drivers/gpu/drm/amd/amdgpu/si.c   | 13 +++--
> >   drivers/gpu/drm/amd/amdgpu/soc15.c|  8 
> >   drivers/gpu/drm/amd/amdgpu/vi.c   | 24 
> > 
> >   drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 16 +-
> --
> >   drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c   | 18 --
> >   7 files changed, 54 insertions(+), 53 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c
> > b/drivers/gpu/drm/amd/amdgpu/cik.c
> > index 78ab939..f41f5f5 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/cik.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/cik.c
> > @@ -2002,6 +2002,8 @@ int cik_set_ip_blocks(struct amdgpu_device
> *adev)
> > amdgpu_device_ip_block_add(adev,
> _common_ip_block);
> > amdgpu_device_ip_block_add(adev, _v7_0_ip_block);
> > amdgpu_device_ip_block_add(adev, _ih_ip_block);
> > +   amdgpu_device_ip_block_add(adev, _v7_2_ip_block);
> > +   amdgpu_device_ip_block_add(adev, _sdma_ip_block);
> > if (amdgpu_dpm == -1)
> > amdgpu_device_ip_block_add(adev,
> _smu_ip_block);
> > else
> > @@ -2014,8 +2016,6 @@ int cik_set_ip_blocks(struct amdgpu_device
> *adev)
> >   #endif
> > else
> > amdgpu_device_ip_block_add(adev,
> _v8_2_ip_block);
> > -   amdgpu_device_ip_block_add(adev, _v7_2_ip_block);
> > -   amdgpu_device_ip_block_add(adev, _sdma_ip_block);
> > amdgpu_device_ip_block_add(adev, _v4_2_ip_block);
> > amdgpu_device_ip_block_add(adev, _v2_0_ip_block);
> > break;
> > @@ -2023,6 +2023,8 @@ int cik_set_ip_blocks(struct amdgpu_device
> *adev)
> > amdgpu_device_ip_block_add(adev,
> _common_ip_block);
> > amdgpu_device_ip_block_add(adev, _v7_0_ip_block);
> > amdgpu_device_ip_block_add(adev, _ih_ip_block);
> > +   amdgpu_device_ip_block_add(adev, _v7_3_ip_block);
> > +   amdgpu_device_ip_block_add(adev, _sdma_ip_block);
> > if (amdgpu_dpm == -1)
> > amdgpu_device_ip_block_add(adev,
> _smu_ip_block);
> > else
> > @@ -2035,8 +2037,6 @@ int cik_set_ip_blocks(struct amdgpu_device
> *adev)
> >   #endif
> > else
> > amdgpu_device_ip_block_add(adev,
> _v8_5_ip_block);
> > -   amdgpu_device_ip_block_add(adev, _v7_3_ip_block);
> > -   amdgpu_device_ip_block_add(adev, _sdma_ip_block);
> > amdgpu_device_ip_block_add(adev, _v4_2_ip_block);
> > amdgpu_device_ip_block_add(adev, _v2_0_ip_block);
> > break;
> > @@ -2044,6 +2044,8 @@ int cik_set_ip_blocks(struct amdgpu_device
> *adev)
> > amdgpu_device_ip_block_add(adev,
> _common_ip_block);
> > amdgpu_device_ip_block_add(adev, _v7_0_ip_block);
> > amdgpu_device_ip_block_add(adev, _ih_ip_block);
> > +   amdgpu_device_ip_block_add(adev, _v7_1_ip_block);
> > +   amdgpu_device_ip_block_add(adev, _sdma_ip_block);
> > amdgpu_device_ip_block_add(adev, _smu_ip_block);
> > if (adev->enable_virtual_display)
> > amdgpu_device_ip_block_add(adev,
> _virtual_ip_block); @@
> > -2053,8 +2055,7 @@ int cik_set_ip_blocks(struct amdgpu_device *adev)
> >   #endif
> > else
> > amdgpu_device_ip_block_add(adev,
> _v8_1_ip_block);
> > -   amdgpu_device_ip_block_add(adev, _v7_1_ip_block);
> > -   amdgpu_device_ip_block_add(adev, _sdma_ip_block);
> > +
> > amdgpu_device_ip_block_add(adev, _v4_2_ip_block);
> > amdgpu_device_ip_block_add(adev, _v2_0_ip_block);
> > break;
> > @@ -2063,6 +2064,8 @@ int cik_set_ip_blocks(struct amdgpu_device
> *adev)
> > amdgpu_device_ip_

RE: [PATCH 9/9] drm/amdgpu: print smc feature mask in debugfs amdgpu_pm_info

[Zhu, Rex]

Series is: 
Reviewed-by: Rex Zhu 

Regards
Rex

> -Original Message-
> From: amd-gfx  On Behalf Of Alex
> Deucher
> Sent: Friday, September 21, 2018 11:55 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: [PATCH 9/9] drm/amdgpu: print smc feature mask in debugfs
> amdgpu_pm_info
> 
> Print the enabled smc feature mask in amdgpu_pm_info for debugging.
> 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> index 8c334fc808c2..18d989e0e362 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> @@ -1976,6 +1976,7 @@ void amdgpu_pm_compute_clocks(struct
> amdgpu_device *adev)  static int amdgpu_debugfs_pm_info_pp(struct
> seq_file *m, struct amdgpu_device *adev)  {
>   uint32_t value;
> + uint64_t value64;
>   uint32_t query = 0;
>   int size;
> 
> @@ -2014,6 +2015,10 @@ static int amdgpu_debugfs_pm_info_pp(struct
> seq_file *m, struct amdgpu_device *a
>   seq_printf(m, "GPU Load: %u %%\n", value);
>   seq_printf(m, "\n");
> 
> + /* SMC feature mask */
> + if (!amdgpu_dpm_read_sensor(adev,
> AMDGPU_PP_SENSOR_ENABLED_SMC_FEATURES_MASK, (void *),
> ))
> + seq_printf(m, "SMC Feature Mask: 0x%016llx\n", value64);
> +
>   /* UVD clocks */
>   if (!amdgpu_dpm_read_sensor(adev,
> AMDGPU_PP_SENSOR_UVD_POWER, (void *), )) {
>   if (!value) {
> --
> 2.13.6
> 
> ___
> 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 v2] drm/amdgpu:No action when VCN PG state is unchanged

[Zhu, Rex]

In my understand, when  dpg mode enabled,  we don't need to power up/down VCN 
via SMU and 
Also don't need to set vcn power gate/ungate state.

Just need to enable the dpg mode.

If not true, please correct me.

Best Regards
Rex





> -Original Message-
> From: amd-gfx  On Behalf Of
> Christian König
> Sent: Friday, September 21, 2018 8:53 PM
> To: Zhu, James ; Alex Deucher
> 
> Cc: James Zhu ; Zhu, James ;
> amd-gfx list 
> Subject: Re: [PATCH v2] drm/amdgpu:No action when VCN PG state is
> unchanged
> 
> Am 21.09.2018 um 14:28 schrieb James Zhu:
> >
> >
> > On 2018-09-20 01:54 PM, Christian König wrote:
> >> Am 20.09.2018 um 18:24 schrieb James Zhu:
> >>>
> >>>
> >>> On 2018-09-20 11:49 AM, Alex Deucher wrote:
>  On Thu, Sep 20, 2018 at 11:27 AM James Zhu 
> wrote:
> >
> >
> > On 2018-09-20 11:14 AM, Alex Deucher wrote:
> >> On Thu, Sep 13, 2018 at 4:56 PM James Zhu 
> wrote:
> >>> When VCN PG state is unchanged, it is unnecessary to reset power
> >>> gate state
> >>>
> >>> Signed-off-by: James Zhu 
> >>> ---
> >>>    drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h |  1 +
> >>>    drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c   | 12 ++--
> >>>    2 files changed, 11 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> >>> index 0b0b863..d2219ab 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> >>> @@ -69,6 +69,7 @@ struct amdgpu_vcn {
> >>>   struct amdgpu_ring  ring_jpeg;
> >>>   struct amdgpu_irq_src   irq;
> >>>   unsigned    num_enc_rings;
> >>> +   enum amd_powergating_state cur_state;
> >> Does the default value (0) at init time properly reflect the
> >> default powergating state?  If so,
> >> Acked-by: Alex Deucher 
> > Yes, the below code shows it will be set to 0 during driver load
> > stage.
>  Yes, I understand that.  Is 0 (AMD_PG_STATE_GATE) what we want as
>  the default though?  The first time the code runs are we going to
>  do the right thing or is the code going to return early?  IIRC, the
>  hw default is ungated.
> >>> cur_state is used for tracking driver SW PG state, not HW  PG state.
> >>> I though no matter what HW  PG state is after device powers up, when
> >>> first vcn ring is scheduled to run,
> >>> begin_use->set_powergating_state->vcn_v1_0_start->ungate
> >>> power/clock->Boot_VCPU  will be tried.
> >>>
> >>> For DPG mode, the ungate power/clock , boot VCPU will not actually
> >>> be activated during start setup stage, and only be activated during
> >>> ring run stage.
> >>
> >> Mhm, I wonder if it wouldn't be better to have that functionality one
> >> layer up.
> >>
> >> E.g. in amdgpu_device_ip_set_powergating_state so that it applies to
> >> all IP blocks in the same way.
> > If necessary, I can add support for IP blocks later.
> 
> Yeah, agree. In general I'm not doing much with power management, so
> can't judge if that is a good idea or not.
> 
> Anyway feel free to add my Acked-by to the patch.
> 
> Regards,
> Christian.
> 
> > James
> >>
> >> But on the other hand the correct solution looks good to me as well,
> >> so feel free to add my Acked-by as well.
> >>
> >> Christian.
> >>
> >>>
> >>> James
>  Alex
> > int amdgpu_driver_load_kms(struct drm_device *dev, unsigned long
> > flags)
> > 
> >   adev = kzalloc(sizeof(struct amdgpu_device), GFP_KERNEL);
> >
> > struct amdgpu_device {
> > 
> >   struct amdgpu_vcn    vcn;
> >
> > Best Regards!
> > James zhu
> >>>    };
> >>>
> >>>    int amdgpu_vcn_sw_init(struct amdgpu_device *adev); diff
> >>> --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
> >>> b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
> >>> index 2664bb2..2cde0b4 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
> >>> @@ -1633,12 +1633,20 @@ static int
> >>> vcn_v1_0_set_powergating_state(void *handle,
> >>>    * revisit this when there is a cleaner line between
> >>>    * the smc and the hw blocks
> >>>    */
> >>> +   int ret;
> >>>   struct amdgpu_device *adev = (struct amdgpu_device
> >>> *)handle;
> >>>
> >>> +   if(state == adev->vcn.cur_state)
> >>> +   return 0;
> >>> +
> >>>   if (state == AMD_PG_STATE_GATE)
> >>> -   return vcn_v1_0_stop(adev);
> >>> +   ret = vcn_v1_0_stop(adev);
> >>>   else
> >>> -   return vcn_v1_0_start(adev);
> >>> +   ret = vcn_v1_0_start(adev);
> >>> +
> >>> +   if(!ret)
> >>> +   adev->vcn.cur_state = state;
> >>> +   return ret;
> 

RE: [PATCH 1/3] drm/amd/pp: Avoid divide-by-zero in smu7_fan_ctrl_set_fan_speed_rpm

[Zhu, Rex]

Hi Alex and Evan,

For the fan control via sysfs,  I think we need to clarify the use case.

We support manual/auto fan control mode.

User can set the mode through pwm_enable. 1 mean manual. 2 mean auto
User can set fan speed via pwm1 and fan1_input.

For pwm1, user set the percentage value (0% - 100%)
And can get the pwm1's range via sysfs: pwm1_min, pwm1_max. the range is [0, 
255]. In driver, we transfer to [0% - 100%]

For fan1_input, user set the fan's resolution per minute
No way for user to get the range. On Tonga, the range is (0, 6000]. Not support 
zero-rpm on tonga.

Do we need to add new sysfs to expose the RPM range or just print the range in 
dmesg if user's setting is out of range?

Another question is:

Currently, the default fan control mode is auto.
When user change the fan speed via pwm1 or fan1_input, we switch to manual mode 
automatically.

So if user want to change back to auto fan control mode, they need to echo 2 to 
pwm_enable.

Best Regards
Rex


From: Deucher, Alexander
Sent: Thursday, September 20, 2018 9:52 PM
To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/amd/pp: Avoid divide-by-zero in 
smu7_fan_ctrl_set_fan_speed_rpm


Series is:

Reviewed-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>


From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Rex Zhu mailto:rex@amd.com>>
Sent: Thursday, September 20, 2018 3:14:25 AM
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Cc: Zhu, Rex
Subject: [PATCH 1/3] drm/amd/pp: Avoid divide-by-zero in 
smu7_fan_ctrl_set_fan_speed_rpm

The minRPM speed maybe equal to zero. so need to check
input RPM not equal to 0, otherwise cause divide-by-zero driver crash.

Signed-off-by: Rex Zhu mailto:rex@amd.com>>
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_thermal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_thermal.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_thermal.c
index 44527755..d61a9b4 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_thermal.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_thermal.c
@@ -260,6 +260,7 @@ int smu7_fan_ctrl_set_fan_speed_rpm(struct pp_hwmgr *hwmgr, 
uint32_t speed)
 if (hwmgr->thermal_controller.fanInfo.bNoFan ||
 (hwmgr->thermal_controller.fanInfo.
 ucTachometerPulsesPerRevolution == 0) ||
+   speed == 0 ||
 (speed < hwmgr->thermal_controller.fanInfo.ulMinRPM) ||
 (speed > hwmgr->thermal_controller.fanInfo.ulMaxRPM))
 return 0;
--
1.9.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org<mailto: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/amd/powerplay: enable fan RPM and pwm settings

[Zhu, Rex]

Please see in line.


Regards

Rex



From: amd-gfx  on behalf of Evan Quan 

Sent: Thursday, September 20, 2018 10:26 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander; Quan, Evan
Subject: [PATCH] drm/amd/powerplay: enable fan RPM and pwm settings

Manual fan RPM and pwm setting on vega20 are
available now.

Change-Id: Iad45a169d6984acc091c4efaf46973619fe43a29
Signed-off-by: Evan Quan 
Reviewed-by: Alex Deucher 
Reviewed-by: Rex Zhu 
---
 .../include/asic_reg/thm/thm_11_0_2_offset.h  |  12 ++
 .../include/asic_reg/thm/thm_11_0_2_sh_mask.h |  10 ++
 .../drm/amd/powerplay/hwmgr/vega20_hwmgr.c|  27 
 .../drm/amd/powerplay/hwmgr/vega20_thermal.c  | 148 +-
 .../drm/amd/powerplay/hwmgr/vega20_thermal.h  |  11 +-
 5 files changed, 204 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/include/asic_reg/thm/thm_11_0_2_offset.h 
b/drivers/gpu/drm/amd/include/asic_reg/thm/thm_11_0_2_offset.h
index 510ec3c70626..5ad10408660e 100644
--- a/drivers/gpu/drm/amd/include/asic_reg/thm/thm_11_0_2_offset.h
+++ b/drivers/gpu/drm/amd/include/asic_reg/thm/thm_11_0_2_offset.h
@@ -26,6 +26,18 @@
 #define mmCG_MULT_THERMAL_STATUS   
0x005f
 #define mmCG_MULT_THERMAL_STATUS_BASE_IDX  
0

+#define mmCG_FDO_CTRL0 
0x0067
+#define mmCG_FDO_CTRL0_BASE_IDX
0
+
+#define mmCG_FDO_CTRL1 
0x0068
+#define mmCG_FDO_CTRL1_BASE_IDX
0
+
+#define mmCG_FDO_CTRL2 
0x0069
+#define mmCG_FDO_CTRL2_BASE_IDX
0
+
+#define mmCG_TACH_STATUS   
0x006b
+#define mmCG_TACH_STATUS_BASE_IDX  
0
+
 #define mmTHM_THERMAL_INT_ENA  
0x000a
 #define mmTHM_THERMAL_INT_ENA_BASE_IDX 
0
 #define mmTHM_THERMAL_INT_CTRL 
0x000b
diff --git a/drivers/gpu/drm/amd/include/asic_reg/thm/thm_11_0_2_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/thm/thm_11_0_2_sh_mask.h
index f69533fa6abf..ed1a2c869de5 100644
--- a/drivers/gpu/drm/amd/include/asic_reg/thm/thm_11_0_2_sh_mask.h
+++ b/drivers/gpu/drm/amd/include/asic_reg/thm/thm_11_0_2_sh_mask.h
@@ -28,6 +28,16 @@
 #define CG_MULT_THERMAL_STATUS__CTF_TEMP__SHIFT
   0x9
 #define CG_MULT_THERMAL_STATUS__ASIC_MAX_TEMP_MASK 
   0x01FFL
 #define CG_MULT_THERMAL_STATUS__CTF_TEMP_MASK  
   0x0003FE00L
+#define CG_FDO_CTRL2__TMIN__SHIFT  
   0x0
+#define CG_FDO_CTRL2__TMIN_MASK
   0x00FFL
+#define CG_FDO_CTRL2__FDO_PWM_MODE__SHIFT  
   0xb
+#define CG_FDO_CTRL2__FDO_PWM_MODE_MASK
   0x3800L
+#define CG_FDO_CTRL1__FMAX_DUTY100__SHIFT  
   0x0
+#define CG_FDO_CTRL1__FMAX_DUTY100_MASK
   0x00FFL
+#define CG_FDO_CTRL0__FDO_STATIC_DUTY__SHIFT   
   0x0
+#define CG_FDO_CTRL0__FDO_STATIC_DUTY_MASK 
   0x00FFL
+#define CG_TACH_STATUS__TACH_PERIOD__SHIFT 
   0x0
+#define CG_TACH_STATUS__TACH_PERIOD_MASK   
   0xL

 //THM_THERMAL_INT_ENA
 #define THM_THERMAL_INT_ENA__THERM_INTH_SET__SHIFT 
   0x0
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
index 39069663ac3f..4a80b8101194 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
@@ -2284,6 +2284,25 @@ static uint32_t vega20_get_fan_control_mode(struct 
pp_hwmgr 

Re: [PATCH] drm/amdgpu: add new polaris pci id

[Zhu, Rex]

Reviewed-by: Rex Zhu 

Regards
Rex



From: amd-gfx  on behalf of Alex Deucher 

Sent: Thursday, September 20, 2018 11:05 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander; sta...@vger.kernel.org
Subject: [PATCH] drm/amdgpu: add new polaris pci id

Add new pci id.

Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 14 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  1 +
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index 693ec5ea4950..8816c697b205 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -367,12 +367,14 @@ static int amdgpu_cgs_get_firmware_info(struct cgs_device 
*cgs_device,
 break;
 case CHIP_POLARIS10:
 if (type == CGS_UCODE_ID_SMU) {
-   if ((adev->pdev->device == 0x67df) &&
-   ((adev->pdev->revision == 0xe0) ||
-(adev->pdev->revision == 0xe3) ||
-(adev->pdev->revision == 0xe4) ||
-(adev->pdev->revision == 0xe5) ||
-(adev->pdev->revision == 0xe7) ||
+   if (((adev->pdev->device == 0x67df) &&
+((adev->pdev->revision == 0xe0) ||
+ (adev->pdev->revision == 0xe3) ||
+ (adev->pdev->revision == 0xe4) ||
+ (adev->pdev->revision == 0xe5) ||
+ (adev->pdev->revision == 0xe7) ||
+ (adev->pdev->revision == 0xef))) 
||
+   ((adev->pdev->device == 0x6fdf) &&
  (adev->pdev->revision == 0xef))) {
 info->is_kicker = true;
 strcpy(fw_name, 
"amdgpu/polaris10_k_smc.bin");
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index ff10df4f50d3..b536808f62ec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -837,6 +837,7 @@ static const struct pci_device_id pciidlist[] = {
 {0x1002, 0x67CA, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
 {0x1002, 0x67CC, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
 {0x1002, 0x67CF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
+   {0x1002, 0x6FDF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
 /* Polaris12 */
 {0x1002, 0x6980, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS12},
 {0x1002, 0x6981, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS12},
--
2.13.6

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx 
Archives.. Using amd-gfx: To post a message to all the list members, send email 
to amd-gfx@lists.freedesktop.org. You can subscribe to the list, or change your 
existing subscription, in the sections below.


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

RE: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer

[Zhu, Rex]

Thanks. 
So we still need to check the bo valid before use for the case that if we don't 
know the size when allocate.

Best Regards
Rex

> -Original Message-
> From: Koenig, Christian
> Sent: Tuesday, September 18, 2018 5:34 PM
> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer
> 
> Am 18.09.2018 um 11:27 schrieb Zhu, Rex:
> >
> >> -Original Message-
> >> From: Koenig, Christian
> >> Sent: Tuesday, September 18, 2018 4:41 PM
> >> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> >> Subject: Re: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer
> >>
> >> Am 18.09.2018 um 10:16 schrieb Zhu, Rex:
> >>>> -Original Message-
> >>>> From: Christian König 
> >>>> Sent: Tuesday, September 18, 2018 3:14 PM
> >>>> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> >>>> Subject: Re: [PATCH] drm/amdgpu: don't try to unreserve NULL
> >>>> pointer
> >>>>
> >>>> Am 18.09.2018 um 08:16 schrieb Zhu, Rex:
> >>>>>> -Original Message-
> >>>>>> From: amd-gfx  On Behalf
> >>>>>> Of Christian König
> >>>>>> Sent: Tuesday, September 18, 2018 2:07 AM
> >>>>>> To: amd-gfx@lists.freedesktop.org
> >>>>>> Subject: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer
> >>>>>>
> >>>>>> Don't try to unreserve a BO we doesn't allocated.
> >>>>>>
> >>>>>> Fixes: 07012fdd497e drm/amdgpu: don't allocate zero sized kernel
> >>>>>> BOs
> >>>>>>
> >>>>>> Signed-off-by: Christian König 
> >>>>>> ---
> >>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
> >>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >>>>>> index 84d82d5382f9..c1387efc0c91 100644
> >>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >>>>>> @@ -348,7 +348,8 @@ int amdgpu_bo_create_kernel(struct
> >>>> amdgpu_device
> >>>>>> *adev,
> >>>>>>if (r)
> >>>>>>return r;
> >>>>>> -  amdgpu_bo_unreserve(*bo_ptr);
> >>>>>> +  if (*bo_ptr)
> >>>>>> +  amdgpu_bo_unreserve(*bo_ptr);
> >>>>>>
> >>>>>>return 0;
> >>>>>> }
> >>>>> It is weird.
> >>>>> If we return true for allocate bo with size  0.
> >>>>> Does that mean we need to check all the bo_ptr before we use them.
> >>>> No, allocating a BO with zero size doesn't make much sense and was
> >>>> essentially undefined behavior previously.
> >>>>
> >>>> So now we get a defined behavior, but not necessary the one you
> >> expected.
> >>>> Is that only a rhetorical question or really a problem somewhere?
> >>> Logically, the code is trick.
> >> Yeah, that is not a bad argument.
> >>
> >> But it also makes the function more useful, e.g. we don't need size
> >> checks any more whenever an optional BO is allocated.
> > Yes, the problem is user don't need size check. But user have no way to
> check whether the bo is allocated successfully.
> >
> > Because in size 0 case, the create function also return true.
> > And as you said below, check bo_ptr is not safe either(the *bo_ptr  may be
> not modified at all).
> 
> That is not correct. When size==0 we call amdgpu_bo_unref(bo_ptr), and
> that one sets bo_ptr to NULL.
> 
> When size==0 was possible before, the calling code would have needed to
> check bo_ptr later on anyway.
> 
> In other words what we had before:
> 
> calling_function()
> {
>      if (size) {
>          r = amdgpu_bo_create_kernel(..., size, );
>          if (r)
>              goto error_handling;
>      }
>      
>      if (bo)
>          
> }
> 
> 
> But now that looks like:
> calling_function()
> {
>      r = amdgpu_bo_create_kernel(..., size, );
>      if (r)
>          goto error_handling;
>      
>      if (bo) {
>          
> }
> 
> So we just removed the extra size check of the calling function. I think that 
> is
> a valid usage.
> 
> Christian.
> 
> 
> >
> > Regards
> > Rex
> >
> >
> >
> >
> >>>It also make the  code
> >>> if (r)
> >>>   return r;
> >>> redundant.
> >> Actually that is not correct.
> >>
> >> When an error happens the *bo_ptr is not modified at all. So we could
> >> then try to unreserve a BO which was never reserved.
> > Yes, You ae right.
> >
> >
> >> Christian.
> >>
> >>> Regards
> >>> Rex
> >>>
> >>>> Regards,
> >>>> Christian.
> >>>>
> >>>>> Best Regards
> >>>>> Rex
> >>>>>
> >>>>>> --
> >>>>>> 2.14.1
> >>>>>>
> >>>>>> ___
> >>>>>> amd-gfx mailing list
> >>>>>> amd-gfx@lists.freedesktop.org
> >>>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

RE: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer

[Zhu, Rex]

> -Original Message-
> From: Koenig, Christian
> Sent: Tuesday, September 18, 2018 4:41 PM
> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer
> 
> Am 18.09.2018 um 10:16 schrieb Zhu, Rex:
> >
> >> -Original Message-
> >> From: Christian König 
> >> Sent: Tuesday, September 18, 2018 3:14 PM
> >> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> >> Subject: Re: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer
> >>
> >> Am 18.09.2018 um 08:16 schrieb Zhu, Rex:
> >>>> -Original Message-
> >>>> From: amd-gfx  On Behalf Of
> >>>> Christian König
> >>>> Sent: Tuesday, September 18, 2018 2:07 AM
> >>>> To: amd-gfx@lists.freedesktop.org
> >>>> Subject: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer
> >>>>
> >>>> Don't try to unreserve a BO we doesn't allocated.
> >>>>
> >>>> Fixes: 07012fdd497e drm/amdgpu: don't allocate zero sized kernel
> >>>> BOs
> >>>>
> >>>> Signed-off-by: Christian König 
> >>>> ---
> >>>>drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
> >>>>1 file changed, 2 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >>>> index 84d82d5382f9..c1387efc0c91 100644
> >>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >>>> @@ -348,7 +348,8 @@ int amdgpu_bo_create_kernel(struct
> >> amdgpu_device
> >>>> *adev,
> >>>>  if (r)
> >>>>  return r;
> >>>> -amdgpu_bo_unreserve(*bo_ptr);
> >>>> +if (*bo_ptr)
> >>>> +amdgpu_bo_unreserve(*bo_ptr);
> >>>>
> >>>>  return 0;
> >>>>}
> >>> It is weird.
> >>> If we return true for allocate bo with size  0.
> >>> Does that mean we need to check all the bo_ptr before we use them.
> >> No, allocating a BO with zero size doesn't make much sense and was
> >> essentially undefined behavior previously.
> >>
> >> So now we get a defined behavior, but not necessary the one you
> expected.
> >>
> >> Is that only a rhetorical question or really a problem somewhere?
> > Logically, the code is trick.
> 
> Yeah, that is not a bad argument.
> 
> But it also makes the function more useful, e.g. we don't need size checks
> any more whenever an optional BO is allocated.

Yes, the problem is user don't need size check. But user have no way to check 
whether the bo is allocated successfully.

Because in size 0 case, the create function also return true.
And as you said below, check bo_ptr is not safe either(the *bo_ptr  may be not 
modified at all).

Regards
Rex




> >   It also make the  code
> > if (r)
> > return r;
> > redundant.
> 
> Actually that is not correct.
> 
> When an error happens the *bo_ptr is not modified at all. So we could then
> try to unreserve a BO which was never reserved.

Yes, You ae right.


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

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

RE: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer

[Zhu, Rex]

> -Original Message-
> From: Christian König 
> Sent: Tuesday, September 18, 2018 3:14 PM
> To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer
> 
> Am 18.09.2018 um 08:16 schrieb Zhu, Rex:
> >
> >> -Original Message-
> >> From: amd-gfx  On Behalf Of
> >> Christian König
> >> Sent: Tuesday, September 18, 2018 2:07 AM
> >> To: amd-gfx@lists.freedesktop.org
> >> Subject: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer
> >>
> >> Don't try to unreserve a BO we doesn't allocated.
> >>
> >> Fixes: 07012fdd497e drm/amdgpu: don't allocate zero sized kernel BOs
> >>
> >> Signed-off-by: Christian König 
> >> ---
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
> >>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >> index 84d82d5382f9..c1387efc0c91 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >> @@ -348,7 +348,8 @@ int amdgpu_bo_create_kernel(struct
> amdgpu_device
> >> *adev,
> >>if (r)
> >>return r;
> >> -  amdgpu_bo_unreserve(*bo_ptr);
> >> +  if (*bo_ptr)
> >> +  amdgpu_bo_unreserve(*bo_ptr);
> >>
> >>return 0;
> >>   }
> > It is weird.
> > If we return true for allocate bo with size  0.
> > Does that mean we need to check all the bo_ptr before we use them.
> 
> No, allocating a BO with zero size doesn't make much sense and was
> essentially undefined behavior previously.
> 
> So now we get a defined behavior, but not necessary the one you expected.
> 
> Is that only a rhetorical question or really a problem somewhere?

Logically, the code is trick. It also make the  code
if (r)
return r; 
redundant.

Regards
Rex

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

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

RE: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer

[Zhu, Rex]

> -Original Message-
> From: amd-gfx  On Behalf Of
> Christian König
> Sent: Tuesday, September 18, 2018 2:07 AM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/amdgpu: don't try to unreserve NULL pointer
> 
> Don't try to unreserve a BO we doesn't allocated.
> 
> Fixes: 07012fdd497e drm/amdgpu: don't allocate zero sized kernel BOs
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index 84d82d5382f9..c1387efc0c91 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -348,7 +348,8 @@ int amdgpu_bo_create_kernel(struct amdgpu_device
> *adev,
>   if (r)
>   return r;
> 
> - amdgpu_bo_unreserve(*bo_ptr);
> + if (*bo_ptr)
> + amdgpu_bo_unreserve(*bo_ptr);
> 
>   return 0;
>  }
It is weird. 
If we return true for allocate bo with size  0.
Does that mean we need to check all the bo_ptr before we use them.

Best Regards
Rex
 
> --
> 2.14.1
> 
> ___
> 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/amd/dc: Trigger set power state task when display configuration changes

[Zhu, Rex]

Hi David,

Yes, There is an issue you pointed out on Raven. Because the force_dpm_level 
was added for UMD-P state and the min clocks were hardcode. The display's clock 
requests were ignored.
I will fix this issue.
Thanks.

Best Regards
Rex

From: Francis, David
Sent: Monday, September 17, 2018 9:31 PM
To: Zhu, Rex ; Deucher, Alexander ; 
Wentland, Harry 
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/dc: Trigger set power state task when display 
configuration changes


On Linux, the clocks are already set by the time that function call is reached. 
 amdgpu_pm_compute clocks resets the clocks to their default value.


From: Zhu, Rex
Sent: September 17, 2018 4:12:33 AM
To: Deucher, Alexander; Wentland, Harry; Francis, David
Cc: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: RE: [PATCH] drm/amd/dc: Trigger set power state task when display 
configuration changes


+Harry and David.



Best Regards

Rex



From: Deucher, Alexander
Sent: Friday, September 14, 2018 9:40 PM
To: Zhu, Rex mailto:rex@amd.com>>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amd/dc: Trigger set power state task when display 
configuration changes



Acked-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>



From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Rex Zhu mailto:rex@amd.com>>
Sent: Friday, September 14, 2018 1:57:07 AM
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Cc: Zhu, Rex
Subject: [PATCH] drm/amd/dc: Trigger set power state task when display 
configuration changes



Revert "drm/amd/display: Remove call to amdgpu_pm_compute_clocks"

This reverts commit dcd473770e86517543691bdb227103d6c781cd0a.

when display configuration changes, dc need to update the changes
to powerplay, also need to trigger a power state task.
amdgpu_pm_compute_clocks is the interface to set power state task
either dpm enabled or powerplay enabled

Signed-off-by: Rex Zhu mailto:rex@amd.com>>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
index 6d16b4a..0fab64a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
@@ -105,6 +105,8 @@ bool dm_pp_apply_display_requirements(
 adev->powerplay.pp_funcs->display_configuration_change(
 adev->powerplay.pp_handle,
 >pm.pm_display_cfg);
+
+   amdgpu_pm_compute_clocks(adev);
 }

 return true;
--
1.9.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org<mailto: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/amd/dc: Trigger set power state task when display configuration changes

[Zhu, Rex]

+Harry and David.

Best Regards
Rex

From: Deucher, Alexander
Sent: Friday, September 14, 2018 9:40 PM
To: Zhu, Rex ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/dc: Trigger set power state task when display 
configuration changes


Acked-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>


From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Rex Zhu mailto:rex@amd.com>>
Sent: Friday, September 14, 2018 1:57:07 AM
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Cc: Zhu, Rex
Subject: [PATCH] drm/amd/dc: Trigger set power state task when display 
configuration changes

Revert "drm/amd/display: Remove call to amdgpu_pm_compute_clocks"

This reverts commit dcd473770e86517543691bdb227103d6c781cd0a.

when display configuration changes, dc need to update the changes
to powerplay, also need to trigger a power state task.
amdgpu_pm_compute_clocks is the interface to set power state task
either dpm enabled or powerplay enabled

Signed-off-by: Rex Zhu mailto:rex@amd.com>>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
index 6d16b4a..0fab64a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
@@ -105,6 +105,8 @@ bool dm_pp_apply_display_requirements(
 adev->powerplay.pp_funcs->display_configuration_change(
 adev->powerplay.pp_handle,
 >pm.pm_display_cfg);
+
+   amdgpu_pm_compute_clocks(adev);
 }

 return true;
--
1.9.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org<mailto: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/amd/powerplay: expose vega20 OD features

[Zhu, Rex]

Got it. Thanks Alex.

I think we can simplify the od_clk_voltage on vega20.

When user cat pp_od_clk_voltage
The output can be simplified as:

Sclk:
0  clock_value   voltage_offset
7 clock_valuevoltage_offset
Mclk
3  mclk_value
Range:
sclk {min, max}
mclk {min, max}
voltage{min, max}

for sclk,
user can only set the sclk in dpm level0 and level7, the clock in other levels 
will be recalculated by smu automatically based on user's setting.

For voltage, the avfs is enabled, so the voltage in each level is not a unique 
value.
It is reasonable that export voltage offset to user.
The voltage offset is 0 by default.

The voltage offset in dpm_0, dpm_mid_level, dpm7_level can be configured.
But in order to keep in consistent with sclk's od,
We only let user change the offset in dpm0 and dpm7, for dpm_mid_leve's offset, 
we can calculate in driver by (offset0 + offset7)/2.

For mclk,
Smu just let us change the max clock in dpm3(high level). And the mclk in other 
dpm levels can not be changed.

Any concerns?


Best Regards
Rex

From: Deucher, Alexander
Sent: Wednesday, August 29, 2018 12:03 AM
To: Quan, Evan ; Alex Deucher 
Cc: Zhu, Rex ; amd-gfx list ; 
Xu, Feifei ; Kuehling, Felix ; 
Zhang, Hawking 
Subject: Re: [PATCH] drm/amd/powerplay: expose vega20 OD features


Right.  I'm saying use the same sysfs file (pp_od_clk_voltage) for all devices 
rather than adding a new one.  The output of reading that file will be 
different on each asic that supports a different way of adjusting the clock and 
voltage parameters and the supported inputs will be different.  We do the same 
thing today for pp_power_profile_mode.  Vega10 and smu7 parts have different 
parameters, but we use the same files.  See the attached patch to an example.



Alex


From: Quan, Evan
Sent: Tuesday, August 28, 2018 11:51:16 AM
To: Alex Deucher
Cc: Zhu, Rex; Deucher, Alexander; amd-gfx list; Xu, Feifei; Kuehling, Felix; 
Zhang, Hawking
Subject: Re: [PATCH] drm/amd/powerplay: expose vega20 OD features


Hi Alex,



Sorry, i cannot get your point.



The OD feature sysfs file used by previous ASICs is "pp_od_clk_voltage". And it 
binds to two APIs "amdgpu_get_pp_od_clk_voltage" and 
"amdgpu_set_pp_od_clk_voltage".

static DEVICE_ATTR(pp_od_clk_voltage, S_IRUGO | S_IWUSR,
amdgpu_get_pp_od_clk_voltage,
amdgpu_set_pp_od_clk_voltage);

I was saying we cannot reuse these two APIs for vega20 since we have no way to 
know the exact voltage value for each dpm level(that is what these two APIs 
required). Thus we cannot share the same sysfs file.

Do you mean we can bind the sysfs file to other APIs? How?

Regards,

Evan


From: Alex Deucher mailto:alexdeuc...@gmail.com>>
Sent: Monday, August 27, 2018 10:01:49 PM
To: Quan, Evan
Cc: Zhu, Rex; Deucher, Alexander; amd-gfx list; Xu, Feifei; Kuehling, Felix; 
Zhang, Hawking
Subject: Re: [PATCH] drm/amd/powerplay: expose vega20 OD features

On Mon, Aug 27, 2018 at 12:04 AM Quan, Evan 
mailto:evan.q...@amd.com>> wrote:
>
> Hi @Deucher, Alexander & @Zhu, Rex,
>
>
> I can remove the od setings for power limit and fan speed related since they 
> seem redundant with other sysfs apis.
>
> But for the clock/voltage related, i can not see how to reuse old 
> pp_od_clk_voltage APIs.
>
>
> For the old pp_od_clk_voltage APIs,
>
>  1. they output/input the voltages in their exact values. E.g. "s 1 500 820" 
> will update sclk level 1 to be 500 MHz at 820 mV
>
>  But for vega20, we did not know its original voltage value. The 
> output/input for voltage are just offest from its original value.
>
>  So, if  to reuse these APIs, we will make them have two different 
> explanations(
>
>  on vega20 or later, the voltage is offset. On previous ASICs, the 
> voltage is exact value). I think that will confuse the users.
>
>
>  2. they support voltage set for each level. But for vega20, it supports only 
> three pairs of clock/voltage set. And per suggestion,
>
>  these three pairs should be: voltage offset of minimum clock level, 
> voltage offset for middle clock level  and voltage offset
>
>  for maximum clock level.
>
>
> Also, i believe the future ASICs will also take the vega20 OD ways(that is we 
> need the offset, not the exact value for voltage).
>
>
> So, based on previous considerations, i decide to have new APIs instead of 
> reusing existing ones.

I'm not saying to use the same API.  Use the new API, but expose the
API using the same sysfs file rather than adding a new one.  Same way
we handle the power profiles; E.g., the API is different between smu7
and vega10, but they both use the same sysfs file.

Alex


>
>
> Regards,
>
> Evan
>
> 
> From: Zhu, Rex
> S

RE: [PATCH] drm/amd/powerplay: expose vega20 OD features

[Zhu, Rex]

> -Original Message-
> From: Alex Deucher 
> Sent: Friday, August 24, 2018 11:48 PM
> To: Quan, Evan 
> Cc: amd-gfx list ; Xu, Feifei
> ; Kuehling, Felix ; Deucher,
> Alexander ; Zhu, Rex ;
> Zhang, Hawking 
> Subject: Re: [PATCH] drm/amd/powerplay: expose vega20 OD features
> 
> On Fri, Aug 24, 2018 at 3:45 AM Evan Quan  wrote:
> >
> > Vega20 simplifies the OD logics and it can not fit old OD interfaces.
> > Thus we design new OD interfaces for vega20.
> 
> Please split this into two patches, one to add the internal od8_settings API,
> and one to wire it up to sysfs.  A few more comments below.
> 
> >
> > Change-Id: I888faec46a81287ae24f452ce16b42c1f6d06d7d
> > Signed-off-by: Evan Quan 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h   |   8 +
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 125 
> >  .../gpu/drm/amd/include/kgd_pp_interface.h|   2 +
> >  drivers/gpu/drm/amd/powerplay/amd_powerplay.c |  37 
> >  .../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 191
> +-
> >  drivers/gpu/drm/amd/powerplay/inc/hwmgr.h |   2 +
> >  6 files changed, 362 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > index ff24e1cc5b65..84b3e6f87abf 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
> > @@ -357,6 +357,14 @@ enum amdgpu_pcie_gen {
> > ((adev)->powerplay.pp_funcs->odn_edit_dpm_table(\
> > (adev)->powerplay.pp_handle, type, parameter,
> > size))
> >
> > +#define amdgpu_dpm_get_od8_settings(adev, buf) \
> > +   ((adev)->powerplay.pp_funcs->get_od8_settings(\
> > +   (adev)->powerplay.pp_handle, buf))
> > +
> > +#define amdgpu_dpm_set_od8_settings(adev, parameter, size) \
> > +   ((adev)->powerplay.pp_funcs->set_od8_settings(\
> > +   (adev)->powerplay.pp_handle, parameter, size))
> > +
> >  struct amdgpu_dpm {
> > struct amdgpu_ps*ps;
> > /* number of valid power states */ diff --git
> > a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > index daa55fb06171..94cd7c503372 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > @@ -934,6 +934,121 @@ static ssize_t amdgpu_get_busy_percent(struct
> device *dev,
> > return snprintf(buf, PAGE_SIZE, "%d\n", value);  }
> >
> > +/**
> > + * DOC: pp_od8_settings
> > + *
> > + * The amdgpu driver provides a sysfs API for adjusting the clocks,
> > +voltages,
> > + * power limit, fan speed and temperature. The pp_od8_settings is
> > +used for
> > + * this.
> > + *
> > + * Reading the file will display:
> > + *
> > + * - a name list of the features that are able to be adjusted
> > + *
> > + * - the mininum and maximum allowed value for each supported
> > + *   feature labeled in format of "[mininum - maximum]"
> > + *
> > + * - the current value for each supported feature labeled after
> > + *   ":"
> > + *
> > + * To manually adjust these settings:
> > + *
> > + * - write a string that contains the new value for each supported
> > + *   feature. For those which do not need to be changed, just enter
> > + *   their old value
> > + *
> > + * - make sure the new value is within the allowed ranges between
> > + *   the minimum and maximum
> 
> We should probably also make it a set and commit model like we do for
> previous asics for consistency.  That way you can see the changes, and then
> apply them.
> 
> > + *
> > + * All the possible supported features:
> > + *
> > + * - Gfx clock
> > + *   The min and max frequency can be specified by GfxclkFmin
> > + *   and GfxclkFmax(both in Mhz). Intermediate levels are
> > + *   stretched/shrunk according to ratio in original table.
> > + *
> > + * - Gfx voltage
> > + *   With three pairs of gfx clk(in Mhz) and offset voltage(in mV)
> > + *   combinations specified, smu fw can calibrate the voltage
> > + *   curve automatically.
> > + * - GfxclkFreq1 <-> GfxclkOffsetVolt1
> > + * - GfxclkFreq2 <-> GfxclkOffsetVolt2
> > + * - GfxclkFreq3 <-> GfxclkOffsetVolt3
> > + *
> > + * - Uclk
> > + *   The max memory clock can be specified

RE: [PATCH 3/3] drm/amdgpu: Power on uvd block when hw_fini

[Zhu, Rex]

> -Original Message-
> From: Michel Dänzer 
> Sent: Friday, August 24, 2018 5:31 PM
> To: Zhu, Rex 
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 3/3] drm/amdgpu: Power on uvd block when hw_fini
> 
> On 2018-08-24 10:50 a.m., Rex Zhu wrote:
> > when hw_fini/suspend, smu only need to power on uvd block if uvd pg is
> > supported, don't need to call uvd to do hw_init.
> >
> > v2: fix typo in patch descriptions.
> >
> > Signed-off-by: Rex Zhu 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
> > b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
> > index b497c37..ce81a53 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
> > @@ -65,7 +65,6 @@ static int kv_set_thermal_temperature_range(struct
> amdgpu_device *adev,
> > int min_temp, int max_temp);  static
> int
> > kv_init_fps_limits(struct amdgpu_device *adev);
> >
> > -static void kv_dpm_powergate_uvd(void *handle, bool gate);  static
> > void kv_dpm_powergate_samu(struct amdgpu_device *adev, bool gate);
> > static void kv_dpm_powergate_acp(struct amdgpu_device *adev, bool
> > gate);
> >
> > @@ -1388,7 +1387,8 @@ static void kv_dpm_disable(struct
> amdgpu_device *adev)
> > kv_dpm_powergate_samu(adev, false);
> > if (pi->caps_vce_pg) /* power on the VCE block */
> > amdgpu_kv_notify_message_to_smu(adev,
> PPSMC_MSG_VCEPowerON);
> > -   kv_dpm_powergate_uvd(adev, false);
> > +   if (pi->caps_uvd_pg) /* power off the UVD block */
> > +   amdgpu_kv_notify_message_to_smu(adev,
> PPSMC_MSG_UVDPowerON);
> 
> This comment still seems inconsistent with the code.

Thanks. I will fix it immediately.

Regards
Rex

 
> Apart from that, this series is

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

RE: [PATCH 1/4] drm/amdgpu: add ring soft recovery v3

[Zhu, Rex]

> -Original Message-
> From: amd-gfx  On Behalf Of
> Christian König
> Sent: Thursday, August 23, 2018 7:24 PM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH 1/4] drm/amdgpu: add ring soft recovery v3
> 
> Instead of hammering hard on the GPU try a soft recovery first.
> 
> v2: reorder code a bit
> v3: increase timeout to 10ms, increment GPU reset counter
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c  |  6 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 25
> +
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  4 
>  3 files changed, 35 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> index 265ff90f4e01..d93e31a5c4e7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> @@ -33,6 +33,12 @@ static void amdgpu_job_timedout(struct
> drm_sched_job *s_job)
>   struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
>   struct amdgpu_job *job = to_amdgpu_job(s_job);
> 
> + if (amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence-
> >parent)) {
> + DRM_ERROR("ring %s timeout, but soft recovered\n",
> +   s_job->sched->name);
> + return;
> + }
> +
>   DRM_ERROR("ring %s timeout, signaled seq=%u, emitted seq=%u\n",
> job->base.sched->name, atomic_read(
> >fence_drv.last_seq),
> ring->fence_drv.sync_seq);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> index 5dfd26be1eec..d445acb3d956 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> @@ -383,6 +383,31 @@ void
> amdgpu_ring_emit_reg_write_reg_wait_helper(struct amdgpu_ring *ring,
>   amdgpu_ring_emit_reg_wait(ring, reg1, mask, mask);  }
> 
> +/**
> + * amdgpu_ring_soft_recovery - try to soft recover a ring lockup
> + *
> + * @ring: ring to try the recovery on
> + * @vmid: VMID we try to get going again
> + * @fence: timedout fence
> + *
> + * Tries to get a ring proceeding again when it is stuck.
> + */
> +bool amdgpu_ring_soft_recovery(struct amdgpu_ring *ring, unsigned int
> vmid,
> +struct dma_fence *fence)
> +{
> + ktime_t deadline = ktime_add_us(ktime_get(), 1);
> +
> + if (!ring->funcs->soft_recovery)
> + return false;
> +
> + atomic_inc(>gpu_reset_counter);
> + while (!dma_fence_is_signaled(fence) &&
> +ktime_to_ns(ktime_sub(deadline, ktime_get())) > 0)
> + ring->funcs->soft_recovery(ring, vmid);
Hi Christian,

Is it necessary to add a udelay() here?

Regards
Rex
> + return dma_fence_is_signaled(fence);
> +}
> +
>  /*
>   * Debugfs info
>   */
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> index 409fdd9b9710..9cc239968e40 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> @@ -168,6 +168,8 @@ struct amdgpu_ring_funcs {
>   /* priority functions */
>   void (*set_priority) (struct amdgpu_ring *ring,
> enum drm_sched_priority priority);
> + /* Try to soft recover the ring to make the fence signal */
> + void (*soft_recovery)(struct amdgpu_ring *ring, unsigned vmid);
>  };
> 
>  struct amdgpu_ring {
> @@ -260,6 +262,8 @@ void amdgpu_ring_fini(struct amdgpu_ring *ring);
> void amdgpu_ring_emit_reg_write_reg_wait_helper(struct amdgpu_ring
> *ring,
>   uint32_t reg0, uint32_t val0,
>   uint32_t reg1, uint32_t val1);
> +bool amdgpu_ring_soft_recovery(struct amdgpu_ring *ring, unsigned int
> vmid,
> +struct dma_fence *fence);
> 
>  static inline void amdgpu_ring_clear_ring(struct amdgpu_ring *ring)  {
> --
> 2.14.1
> 
> ___
> 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/3] drm/amdgpu: Power up uvd block when hw_fini

[Zhu, Rex]

> -Original Message-
> From: amd-gfx  On Behalf Of
> Michel Dänzer
> Sent: Thursday, August 23, 2018 6:58 PM
> To: Zhu, Rex 
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 2/3] drm/amdgpu: Power up uvd block when hw_fini
> 
> On 2018-08-23 11:24 a.m., Rex Zhu wrote:
> > when hw_fini/suspend, smu only need to power up uvd block if uvd pg is
> > supported, don't need to call vce to do hw_init.
> 
> Do you really mean VCE here, not UVD?

Yes, thanks for reminding me.


> > diff --git a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
> > b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
> > index a713c8b..8f625d6 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
> > @@ -65,7 +65,6 @@ static int kv_set_thermal_temperature_range(struct
> amdgpu_device *adev,
> > int min_temp, int max_temp);
> static int
> > kv_init_fps_limits(struct amdgpu_device *adev);
> >
> > -static void kv_dpm_powergate_uvd(void *handle, bool gate);  static
> > void kv_dpm_powergate_samu(struct amdgpu_device *adev, bool gate);
> > static void kv_dpm_powergate_acp(struct amdgpu_device *adev, bool
> > gate);
> >
> > @@ -1390,7 +1389,8 @@ static void kv_dpm_disable(struct
> amdgpu_device *adev)
> > kv_dpm_powergate_samu(adev, false);
> > if (pi->caps_vce_pg) /* power on the VCE block */
> > amdgpu_kv_notify_message_to_smu(adev,
> PPSMC_MSG_VCEPowerON);
> > -   kv_dpm_powergate_uvd(adev, false);
> > +   if (pi->caps_uvd_pg) /* power off the UVD block */
> > +   amdgpu_kv_notify_message_to_smu(adev,
> PPSMC_MSG_UVDPowerON);
> 
> The comment should say "power on", shouldn't it?

Maybe. For keep consistent with the smu message.
Will change the comment in v2.

Thanks.
rex


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

RE: [PATCH 1/3] drm/amdgpu: Fix vce initialize failed on Kaveri/Mullins

[Zhu, Rex]

> -Original Message-
> From: Michel Dänzer 
> Sent: Thursday, August 23, 2018 6:59 PM
> To: Zhu, Rex 
> Cc: amd-gfx@lists.freedesktop.org; Kuehling, Felix
> 
> Subject: Re: [PATCH 1/3] drm/amdgpu: Fix vce initialize failed on
> Kaveri/Mullins
> 
> On 2018-08-23 11:24 a.m., Rex Zhu wrote:
> > Forgot to add vce pg support via smu for Kaveri/Mullins.
> >
> > Regresstion issue caused by
> > 'commit 561a5c83eadd ("drm/amd/pp: Unify powergate_uvd/vce/mmhub
> to
> > set_powergating_by_smu")'
> 
> You can replace this paragraph with
> 
> Fixes: 561a5c83eadd ("drm/amd/pp: Unify powergate_uvd/vce/mmhub
>   to set_powergating_by_smu")
> 
> 
> This patch fixes the VCE ring (and also IB) test on this laptop, thanks!
> 
> Unfortunately though, there's still an oops if I let the amdkfd driver load
> together with amdgpu (no issue when loading amdkfd manually later), see
> the attached kernel.log excerpt. This is also a regression in the
> 4.19 drm tree changes. It might be a separate issue, but TBH I don't feel like
> another day or two bisecting right now. :)

Thanks Michel,  I will check the oops issue tomorrow.

Regards
Rex
> 
> Anyway, this series is
> 
> Tested-by: Michel Dänzer 
> 
> 
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amdgpu: Remove duplicated power source update

[Zhu, Rex]

Hi Alex,

We get initial state in amdgpu_device_init.

Best Regards
Rex

 

> -Original Message-
> From: Alex Deucher 
> Sent: Thursday, August 23, 2018 8:37 PM
> To: Zhu, Rex 
> Cc: amd-gfx list ; Wu, Hersen
> 
> Subject: Re: [PATCH] drm/amdgpu: Remove duplicated power source update
> 
> On Thu, Aug 23, 2018 at 2:40 AM Rex Zhu  wrote:
> >
> > when ac/dc switch, driver will be notified by acpi event.
> > then the power source will be updated. so don't need to get power
> > source when set power state.
> 
> Don't we need this to get the initial state?  Maybe we should move this to
> one of the init functions if we don't already check there.
> 
> Alex
> 
> >
> > Signed-off-by: Rex Zhu 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 8 
> >  1 file changed, 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > index daa55fb..3e51e9c 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > @@ -1933,14 +1933,6 @@ void amdgpu_pm_compute_clocks(struct
> amdgpu_device *adev)
> > amdgpu_fence_wait_empty(ring);
> > }
> >
> > -   mutex_lock(>pm.mutex);
> > -   /* update battery/ac status */
> > -   if (power_supply_is_system_supplied() > 0)
> > -   adev->pm.ac_power = true;
> > -   else
> > -   adev->pm.ac_power = false;
> > -   mutex_unlock(>pm.mutex);
> > -
> > if (adev->powerplay.pp_funcs->dispatch_tasks) {
> > if (!amdgpu_device_has_dc_support(adev)) {
> > mutex_lock(>pm.mutex);
> > --
> > 1.9.1
> >
> > ___
> > 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: Regression: Kaveri VCE ring test fails

[Zhu, Rex]

Hi Michel,

Thanks. I know the root cause, and will fix this issue today.

Best Regards
Rex

> -Original Message-
> From: Michel Dänzer 
> Sent: Thursday, August 23, 2018 12:31 AM
> To: Zhu, Rex 
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Regression: Kaveri VCE ring test fails
> 
> 
> Hi Rex,
> 
> 
> I bisected a regression to your "drm/amd/pp: Unify
> powergate_uvd/vce/mmhub to set_powergating_by_smu" change. Since this
> change, the VCE ring test fails on this Kaveri laptop, which prevents the
> amdgpu driver from initializing at all, see the the attached kern.log.
> 
> If I disable VCE via the ip_block_mask module parameter, I get an oops in
> kv_dpm_get_sclk called from amdkfd, see the attached no-vce.log.
> 
> 
> Since the change above landed for 4.19-rc1, the regression should be fixed
> before the final 4.19 release if at all possible.
> 
> 
> Note that before this change, the VCE IB test has always (as far as I
> remember) failed on this machine, see the attached vce-ib-fail.log. But I 
> don't
> care about that too much, as I don't need VCE, and I haven't noticed any
> other issues related to that.
> 
> 
> P.S. Somebody else bisected a Mullins issue to the same commit:
> https://bugs.freedesktop.org/show_bug.cgi?id=107595
> 
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH 2/2] drm/amdgpu: Refine gfx_v9_0_kcq_disable function

[Zhu, Rex]

> -Original Message-
> From: Alex Deucher 
> Sent: Saturday, August 18, 2018 1:26 AM
> To: Zhu, Rex 
> Cc: amd-gfx list 
> Subject: Re: [PATCH 2/2] drm/amdgpu: Refine gfx_v9_0_kcq_disable function
> 
> On Fri, Aug 17, 2018 at 5:35 AM Rex Zhu  wrote:
> >
> > Send all kcq unmap_queue packets and then wait for complete.
> >
> > Signed-off-by: Rex Zhu 
> 
> This series and the gfx8 series are:
> Reviewed-by: Alex Deucher 
> 
> Longer term, we may want to dynamically map and umap compute queues
> as part of scheduling compute work to deal with things like priorities and cu
> masking the the mqds, but that is a future enhancement.

Can we add a backend function in ring_funcs table for unmap_queue.

Rex

> Alex
> 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 33
> > -
> >  1 file changed, 16 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > index bc90f55..f7d97bd 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > @@ -3160,28 +3160,29 @@ static int gfx_v9_0_hw_init(void *handle)
> > return r;
> >  }
> >
> > -static int gfx_v9_0_kcq_disable(struct amdgpu_ring *kiq_ring,struct
> > amdgpu_ring *ring)
> > +static int gfx_v9_0_kcq_disable(struct amdgpu_device *adev)
> >  {
> > -   int r;
> > +   int r, i;
> > +   struct amdgpu_ring *kiq_ring = >gfx.kiq.ring;
> >
> > -   r = amdgpu_ring_alloc(kiq_ring, 6);
> > -   if (r) {
> > +   r = amdgpu_ring_alloc(kiq_ring, 6 * adev->gfx.num_compute_rings);
> > +   if (r)
> > DRM_ERROR("Failed to lock KIQ (%d).\n", r);
> > -   return r;
> > -   }
> >
> > -   /* unmap queues */
> > -   amdgpu_ring_write(kiq_ring, PACKET3(PACKET3_UNMAP_QUEUES, 4));
> > -   amdgpu_ring_write(kiq_ring, /* Q_sel: 0, vmid: 0, engine: 0, num_Q: 
> > 1
> */
> > +   for (i = 0; i < adev->gfx.num_compute_rings; i++) {
> > +   struct amdgpu_ring *ring = >gfx.compute_ring[i];
> > +
> > +   amdgpu_ring_write(kiq_ring,
> PACKET3(PACKET3_UNMAP_QUEUES, 4));
> > +   amdgpu_ring_write(kiq_ring, /* Q_sel: 0, vmid: 0,
> > + engine: 0, num_Q: 1 */
> > 
> > PACKET3_UNMAP_QUEUES_ACTION(1) | /*
> RESET_QUEUES */
> > 
> > PACKET3_UNMAP_QUEUES_QUEUE_SEL(0) |
> > 
> > PACKET3_UNMAP_QUEUES_ENGINE_SEL(0) |
> > 
> > PACKET3_UNMAP_QUEUES_NUM_QUEUES(1));
> > -   amdgpu_ring_write(kiq_ring,
> PACKET3_UNMAP_QUEUES_DOORBELL_OFFSET0(ring->doorbell_index));
> > -   amdgpu_ring_write(kiq_ring, 0);
> > -   amdgpu_ring_write(kiq_ring, 0);
> > -   amdgpu_ring_write(kiq_ring, 0);
> > -
> > +   amdgpu_ring_write(kiq_ring,
> PACKET3_UNMAP_QUEUES_DOORBELL_OFFSET0(ring->doorbell_index));
> > +   amdgpu_ring_write(kiq_ring, 0);
> > +   amdgpu_ring_write(kiq_ring, 0);
> > +   amdgpu_ring_write(kiq_ring, 0);
> > +   }
> > r = amdgpu_ring_test_ring(kiq_ring);
> > if (r)
> > DRM_ERROR("KCQ disable failed\n"); @@ -3192,14
> > +3193,12 @@ static int gfx_v9_0_kcq_disable(struct amdgpu_ring
> > *kiq_ring,struct amdgpu_ring  static int gfx_v9_0_hw_fini(void
> > *handle)  {
> > struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> > -   int i;
> >
> > amdgpu_irq_put(adev, >gfx.priv_reg_irq, 0);
> > amdgpu_irq_put(adev, >gfx.priv_inst_irq, 0);
> >
> > /* disable KCQ to avoid CPC touch memory not valid anymore */
> > -   for (i = 0; i < adev->gfx.num_compute_rings; i++)
> > -   gfx_v9_0_kcq_disable(>gfx.kiq.ring, 
> >gfx.compute_ring[i]);
> > +   gfx_v9_0_kcq_disable(adev);
> >
> > if (amdgpu_sriov_vf(adev)) {
> > gfx_v9_0_cp_gfx_enable(adev, false);
> > --
> > 1.9.1
> >
> > ___
> > 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 v2 1/2] drm/amdgpu: Remove the sriov checking and add firmware checking

[Zhu, Rex]

I have tested the patches on Rv/Vega10/Vega12.

Series is:
Reviewed-and-Tested-by: Rex Zhu 

Best Regards
Rex
> -Original Message-
> From: amd-gfx  On Behalf Of
> Christian König
> Sent: Friday, August 17, 2018 3:23 PM
> To: Deng, Emily ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2 1/2] drm/amdgpu: Remove the sriov checking and add
> firmware checking
> 
> Am 17.08.2018 um 07:40 schrieb Emily Deng:
> > Refine the patch 1, and the lock about invalidate_lock.
> >
> > Unify bare metal and sriov, and add firmware checking for reg write
> > and reg wait unify command.
> >
> > Signed-off-by: Emily Deng 
> 
> Acked-by: Christian König  for this one because I
> can't verify the firmware numbers.
> 
> Reviewed-by: Christian König  for patch #2.
> 
> I can give the two patches a testing on bare metal Vega10 and Raven later
> today if nobody beats me on this.
> 
> Thanks for the patience, that looks *much* better now that we have an
> unified code path, Christian.
> 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h |  2 ++
> >   drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c   | 59
> -
> >   2 files changed, 60 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> > index 53e9e2a..f172e92 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
> > @@ -274,6 +274,8 @@ struct amdgpu_gfx {
> > uint32_trlc_srls_feature_version;
> > uint32_tmec_feature_version;
> > uint32_tmec2_feature_version;
> > +   boolmec_fw_write_wait;
> > +   boolme_fw_write_wait;
> > struct amdgpu_ring
>   gfx_ring[AMDGPU_MAX_GFX_RINGS];
> > unsignednum_gfx_rings;
> > struct amdgpu_ring
>   compute_ring[AMDGPU_MAX_COMPUTE_RINGS];
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > index 4e1e1a0..0cba430 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > @@ -482,6 +482,59 @@ static void gfx_v9_0_init_rlc_ext_microcode(struct
> amdgpu_device *adev)
> > le32_to_cpu(rlc_hdr-
> >reg_list_format_direct_reg_list_length);
> >   }
> >
> > +static void gfx_v9_0_check_fw_write_wait(struct amdgpu_device *adev)
> > +{
> > +   adev->gfx.me_fw_write_wait = false;
> > +   adev->gfx.mec_fw_write_wait = false;
> > +
> > +   switch (adev->asic_type) {
> > +   case CHIP_VEGA10:
> > +   if ((adev->gfx.me_fw_version >= 0x009c) &&
> > +   (adev->gfx.me_feature_version >= 42) &&
> > +   (adev->gfx.pfp_fw_version >=  0x00b1) &&
> > +   (adev->gfx.pfp_feature_version >= 42))
> > +   adev->gfx.me_fw_write_wait = true;
> > +
> > +   if ((adev->gfx.mec_fw_version >=  0x0193) &&
> > +   (adev->gfx.mec_feature_version >= 42))
> > +   adev->gfx.mec_fw_write_wait = true;
> > +   break;
> > +   case CHIP_VEGA12:
> > +   if ((adev->gfx.me_fw_version >= 0x009c) &&
> > +   (adev->gfx.me_feature_version >= 44) &&
> > +   (adev->gfx.pfp_fw_version >=  0x00b2) &&
> > +   (adev->gfx.pfp_feature_version >= 44))
> > +   adev->gfx.me_fw_write_wait = true;
> > +
> > +   if ((adev->gfx.mec_fw_version >=  0x0196) &&
> > +   (adev->gfx.mec_feature_version >= 44))
> > +   adev->gfx.mec_fw_write_wait = true;
> > +   break;
> > +   case CHIP_VEGA20:
> > +   if ((adev->gfx.me_fw_version >= 0x009c) &&
> > +   (adev->gfx.me_feature_version >= 44) &&
> > +   (adev->gfx.pfp_fw_version >=  0x00b2) &&
> > +   (adev->gfx.pfp_feature_version >= 44))
> > +   adev->gfx.me_fw_write_wait = true;
> > +
> > +   if ((adev->gfx.mec_fw_version >=  0x0197) &&
> > +   (adev->gfx.mec_feature_version >= 44))
> > +   adev->gfx.mec_fw_write_wait = true;
> > +   break;
> > +   case CHIP_RAVEN:
> > +   if ((adev->gfx.me_fw_version >= 0x009c) &&
> > +   (adev->gfx.me_feature_version >= 42) &&
> > +   (adev->gfx.pfp_fw_version >=  0x00b1) &&
> > +   (adev->gfx.pfp_feature_version >= 42))
> > +   adev->gfx.me_fw_write_wait = true;
> > +
> > +   if ((adev->gfx.mec_fw_version >=  0x0192) &&
> > +   (adev->gfx.mec_feature_version >= 42))
> > +   adev->gfx.mec_fw_write_wait = true;
> > +   break;
> > +   }
> > +}
> > +
> >   static int gfx_v9_0_init_microcode(struct amdgpu_device *adev)
> >   {
> > const char *chip_name;
> > @@ -716,6 +769,7 @@ static int gfx_v9_0_init_microcode(struct

RE: [PATCH 1/2] drm/amdgpu/sriov: For sriov runtime, use kiq to do invalidate tlb

[Zhu, Rex]

> -Original Message-
> From: Zhu, Rex
> Sent: Thursday, August 16, 2018 1:41 PM
> To: 'Alex Deucher' 
> Cc: Deng, Emily ; amd-gfx list  g...@lists.freedesktop.org>
> Subject: RE: [PATCH 1/2] drm/amdgpu/sriov: For sriov runtime, use kiq to do
> invalidate tlb
> 
> 
> 
> > -Original Message-
> > From: Alex Deucher 
> > Sent: Wednesday, August 15, 2018 10:14 PM
> > To: Zhu, Rex 
> > Cc: Deng, Emily ; amd-gfx list  > g...@lists.freedesktop.org>
> > Subject: Re: [PATCH 1/2] drm/amdgpu/sriov: For sriov runtime, use kiq
> > to do invalidate tlb
> >
> > On Wed, Aug 15, 2018 at 9:56 AM Zhu, Rex  wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: amd-gfx  On Behalf Of
> > > > Emily Deng
> > > > Sent: Wednesday, August 15, 2018 5:48 PM
> > > > To: amd-gfx@lists.freedesktop.org
> > > > Cc: Deng, Emily 
> > > > Subject: [PATCH 1/2] drm/amdgpu/sriov: For sriov runtime, use kiq
> > > > to do invalidate tlb
> > > >
> > > > To avoid the tlb flush not interrupted by world switch, use kiq
> > > > and one command to do tlb invalidate.
> > > >
> > > > v2:
> > > > Add firmware version checking.
> > > >
> > > > v3:
> > > > Refine the code, and move the firmware checking into
> > > > gfx_v9_0_ring_emit_reg_write_reg_wait.
> > > >
> > > > SWDEV-161497
> > >
> > > The "SWDEV-161497" is meanless.
> > > you can describe the issue or just remove the bug number.
> > >
> > > >
> > > > Signed-off-by: Emily Deng 
> > > > ---
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu.h  |  4 +++
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c |  3 --
> > > >  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 15 +++-
> > > >  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c| 61
> > > > 
> > > >  4 files changed, 79 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > > index 07924d4..67b584b 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > > @@ -210,6 +210,10 @@ enum amdgpu_kiq_irq {
> > > >   AMDGPU_CP_KIQ_IRQ_LAST
> > > >  };
> > > >
> > > > +#define MAX_KIQ_REG_WAIT   5000 /* in usecs, 5ms */
> > > > +#define MAX_KIQ_REG_BAILOUT_INTERVAL   5 /* in msecs, 5ms */
> > > > +#define MAX_KIQ_REG_TRY 20
> > > > +
> > > >  int amdgpu_device_ip_set_clockgating_state(void *dev,
> > > >  enum amd_ip_block_type
> > > > block_type,
> > > >  enum
> > > > amd_clockgating_state state); diff --git
> > > > a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > > index 21adb1b6..3885636 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > > @@ -22,9 +22,6 @@
> > > >   */
> > > >
> > > >  #include "amdgpu.h"
> > > > -#define MAX_KIQ_REG_WAIT 5000 /* in usecs, 5ms */
> > > > -#define MAX_KIQ_REG_BAILOUT_INTERVAL 5 /* in msecs, 5ms */ -
> > #define
> > > > MAX_KIQ_REG_TRY 20
> > > >
> > > >  uint64_t amdgpu_csa_vaddr(struct amdgpu_device *adev)  { diff
> > > > --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > > > b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > > > index 76d979e..c9b3db4 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > > > @@ -4348,8 +4348,21 @@ static void
> > > > gfx_v9_0_ring_emit_reg_write_reg_wait(struct amdgpu_ring *ring,
> > > > uint32_t ref,
> > > > uint32_t mask)  {
> > > >   int usepfp = (ring->funcs->type == AMDGPU_RING_TYPE_GFX);
> > > > + struct amdgpu_device *adev = ring->adev;
> > > > + bool fw_version_ok = false;
> > > >
> > > > - if (amdgpu_sriov_vf(ring->adev))
> > > > + if (ring->f

RE: [PATCH 1/2] drm/amdgpu/sriov: For sriov runtime, use kiq to do invalidate tlb

[Zhu, Rex]

> -Original Message-
> From: Alex Deucher 
> Sent: Wednesday, August 15, 2018 10:14 PM
> To: Zhu, Rex 
> Cc: Deng, Emily ; amd-gfx list  g...@lists.freedesktop.org>
> Subject: Re: [PATCH 1/2] drm/amdgpu/sriov: For sriov runtime, use kiq to do
> invalidate tlb
> 
> On Wed, Aug 15, 2018 at 9:56 AM Zhu, Rex  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: amd-gfx  On Behalf Of
> > > Emily Deng
> > > Sent: Wednesday, August 15, 2018 5:48 PM
> > > To: amd-gfx@lists.freedesktop.org
> > > Cc: Deng, Emily 
> > > Subject: [PATCH 1/2] drm/amdgpu/sriov: For sriov runtime, use kiq to
> > > do invalidate tlb
> > >
> > > To avoid the tlb flush not interrupted by world switch, use kiq and
> > > one command to do tlb invalidate.
> > >
> > > v2:
> > > Add firmware version checking.
> > >
> > > v3:
> > > Refine the code, and move the firmware checking into
> > > gfx_v9_0_ring_emit_reg_write_reg_wait.
> > >
> > > SWDEV-161497
> >
> > The "SWDEV-161497" is meanless.
> > you can describe the issue or just remove the bug number.
> >
> > >
> > > Signed-off-by: Emily Deng 
> > > ---
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu.h  |  4 +++
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c |  3 --
> > >  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 15 +++-
> > >  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c| 61
> > > 
> > >  4 files changed, 79 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > index 07924d4..67b584b 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > @@ -210,6 +210,10 @@ enum amdgpu_kiq_irq {
> > >   AMDGPU_CP_KIQ_IRQ_LAST
> > >  };
> > >
> > > +#define MAX_KIQ_REG_WAIT   5000 /* in usecs, 5ms */
> > > +#define MAX_KIQ_REG_BAILOUT_INTERVAL   5 /* in msecs, 5ms */
> > > +#define MAX_KIQ_REG_TRY 20
> > > +
> > >  int amdgpu_device_ip_set_clockgating_state(void *dev,
> > >  enum amd_ip_block_type
> > > block_type,
> > >  enum amd_clockgating_state
> > > state); diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > index 21adb1b6..3885636 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > @@ -22,9 +22,6 @@
> > >   */
> > >
> > >  #include "amdgpu.h"
> > > -#define MAX_KIQ_REG_WAIT 5000 /* in usecs, 5ms */
> > > -#define MAX_KIQ_REG_BAILOUT_INTERVAL 5 /* in msecs, 5ms */ -
> #define
> > > MAX_KIQ_REG_TRY 20
> > >
> > >  uint64_t amdgpu_csa_vaddr(struct amdgpu_device *adev)  { diff --git
> > > a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > > b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > > index 76d979e..c9b3db4 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > > @@ -4348,8 +4348,21 @@ static void
> > > gfx_v9_0_ring_emit_reg_write_reg_wait(struct amdgpu_ring *ring,
> > > uint32_t ref,
> > > uint32_t mask)  {
> > >   int usepfp = (ring->funcs->type == AMDGPU_RING_TYPE_GFX);
> > > + struct amdgpu_device *adev = ring->adev;
> > > + bool fw_version_ok = false;
> > >
> > > - if (amdgpu_sriov_vf(ring->adev))
> > > + if (ring->funcs->type == AMDGPU_RING_TYPE_GFX) {
> > > + if ((adev->gfx.me_fw_version >= 0x009c) && (adev-
> > > >gfx.me_feature_version >= 42))
> > > + if ((adev->gfx.pfp_fw_version >=  0x00b1)
> > > + &&
> > > (adev->gfx.pfp_feature_version >= 42))
> > > + fw_version_ok = true;
> > > + } else {
> > > + if ((adev->gfx.mec_fw_version >=  0x0193) &&
> > > + (adev-
> > > >gfx.mec_feature_version >= 42))
> > > + fw_version_ok = true;
> > > + }
> >
> > Maybe we can add a flag and set the flag when request_firmware.
>

Re: [PATCH v2] drm/amdgpu/sriov: For sriov runtime, use kiq to do invalidate tlb

[Zhu, Rex]

Remove the sriov check, The patch can work on both vega10 and Raven under bare 
metal with tip firmware.


Best Regards

Rex





From: amd-gfx  on behalf of Christian 
König 
Sent: Wednesday, August 15, 2018 3:07 PM
To: Deng, Emily; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/amdgpu/sriov: For sriov runtime, use kiq to do 
invalidate tlb

> As need to let somebody to test all your bare metal test cases, such as 
> vega10, and other asics, as I don't have those environments, and only could 
> test sriov.
That is not much of a problem. We have plenty of people on the mailing
list (including me) who can test this on both Vega10 and Raven.

Just remove the SRIOV check and send the patch out with a request for
testing it on bare metal.

Christian.

Am 15.08.2018 um 04:28 schrieb Deng, Emily:
> Thanks for your review, will send a patch to review again as your suggestion. 
> I think it will be better to use the amdgpu_sriov_vf(adev).
> As need to let somebody to test all your bare metal test cases, such as 
> vega10, and other asics, as I don't have those environments, and only could 
> test sriov.
> If passed those bare metal test cases and fixed the bugs if occurs, then 
> could remove the amdgpu_sriov_vf(adev). Do you think so?
>
> Best wishes
> Emily Deng
>> -Original Message-
>> From: Christian König 
>> Sent: Tuesday, August 14, 2018 8:46 PM
>> To: Deng, Emily ; amd-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH v2] drm/amdgpu/sriov: For sriov runtime, use kiq to do
>> invalidate tlb
>>
>> Am 14.08.2018 um 12:56 schrieb Emily Deng:
>>> To avoid the tlb flush not interrupted by world switch, use kiq and
>>> one command to do tlb invalidate.
>>>
>>> v2:
>>> Add firmware version checking.
>>>
>>> SWDEV-161497
>>>
>>> Signed-off-by: Emily Deng 
>>> ---
>>>drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 63
>> 
>>>drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h |  2 +
>>>drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c|  7 
>>>3 files changed, 72 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
>>> index 21adb1b6..436030c 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
>>> @@ -233,6 +233,69 @@ void amdgpu_virt_kiq_wreg(struct amdgpu_device
>> *adev, uint32_t reg, uint32_t v)
>>>  pr_err("failed to write reg:%x\n", reg);
>>>}
>>>
>>> +signed long  amdgpu_virt_kiq_invalidate_tlb(struct amdgpu_device *adev,
>> struct amdgpu_vmhub *hub,
>>> +   unsigned eng, u32 req, uint32_t vmid)
>> Drop that function here. It is Vega specific and doesn't belong into common
>> code.
>>
>>> +{
>>> +   signed long r, cnt = 0;
>>> +   unsigned long flags;
>>> +   uint32_t seq;
>>> +   struct amdgpu_kiq *kiq = >gfx.kiq;
>>> +   struct amdgpu_ring *ring = >ring;
>>> +   struct drm_amdgpu_info_firmware fw_info;
>>> +
>>> +   if (ring->me == 1) {
>>> +   fw_info.ver = adev->gfx.mec_fw_version;
>>> +   fw_info.feature = adev->gfx.mec_feature_version;
>>> +   } else {
>>> +   fw_info.ver = adev->gfx.mec2_fw_version;
>>> +   fw_info.feature = adev->gfx.mec2_feature_version;
>>> +   }
>>> +
>>> +   if (fw_info.ver <  0x0190 || fw_info.feature < 42)
>>> +   return -EPERM;
>> Please move that check into gfx_v9_0_ring_emit_reg_write_reg_wait().
>>
>>> +
>>> +   BUG_ON(!ring->funcs->emit_reg_write_reg_wait);
>> That check is superfluous.
>>
>>> +
>>> +   spin_lock_irqsave(>ring_lock, flags);
>>> +   amdgpu_ring_alloc(ring, 32);
>>> +   amdgpu_ring_emit_reg_write_reg_wait(ring, hub->vm_inv_eng0_req +
>> eng,
>>> +   hub->vm_inv_eng0_ack + eng,
>>> +   req, 1 << vmid);
>>> +   amdgpu_fence_emit_polling(ring, );
>>> +   amdgpu_ring_commit(ring);
>>> +   spin_unlock_irqrestore(>ring_lock, flags);
>>> +
>>> +   r = amdgpu_fence_wait_polling(ring, seq, MAX_KIQ_REG_WAIT);
>>> +
>>> +   /* don't wait anymore for gpu reset case because this way may
>>> +* block gpu_recover() routine forever, e.g. this virt_kiq_rreg
>>> +* is triggered in TTM and ttm_bo_lock_delayed_workqueue() will
>>> +* never return if we keep waiting in virt_kiq_rreg, which cause
>>> +* gpu_recover() hang there.
>>> +*
>>> +* also don't wait anymore for IRQ context
>>> +* */
>>> +   if (r < 1 && (adev->in_gpu_reset || in_interrupt()))
>>> +   goto failed_kiq;
>>> +
>>> +   if (in_interrupt())
>>> +   might_sleep();
>>> +
>>> +   while (r < 1 && cnt++ < MAX_KIQ_REG_TRY) {
>>> +   msleep(MAX_KIQ_REG_BAILOUT_INTERVAL);
>>> +   r = amdgpu_fence_wait_polling(ring, seq,
>> MAX_KIQ_REG_WAIT);
>>> +   }
>>> +
>>> +   if (cnt > MAX_KIQ_REG_TRY)
>>> +   goto failed_kiq;
>>> +
>>> +   return 0;
>>> +
>>> +failed_kiq:
>>> +   pr_err("failed to invalidate tlb with kiq\n");
>>> +   

Re: [PATCH 3/3] drm/amdgpu/powerplay/vega10: enable AVFS control via ppfeaturemask

[Zhu, Rex]

Series is:

Reviewed-by: Rex Zhu 

Regards
Rex



From: amd-gfx  on behalf of Alex Deucher 

Sent: Saturday, August 11, 2018 2:24 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 3/3] drm/amdgpu/powerplay/vega10: enable AVFS control via 
ppfeaturemask

Allow the user to disable AFVS via ppfeaturemask for debugging.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 704b237ecf70..ca9be583fb62 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -129,7 +129,8 @@ static void vega10_set_default_registry_data(struct 
pp_hwmgr *hwmgr)
 data->registry_data.thermal_support = 1;
 data->registry_data.fw_ctf_enabled = 1;

-   data->registry_data.avfs_support = 1;
+   data->registry_data.avfs_support =
+   hwmgr->feature_mask & PP_AVFS_MASK ? true : false;
 data->registry_data.led_dpm_enabled = 1;

 data->registry_data.vr0hot_enabled = 1;
--
2.13.6

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org
lists.freedesktop.org
Subscribing to amd-gfx: Subscribe to amd-gfx by filling out the following form. 
Use of all freedesktop.org lists is subject to our Code of Conduct.


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

Re: [PATCH] drm/amdpu/vce_v3: skip suspend and resume if powergated

[Zhu, Rex]

I am Ok with the check when call vce_v3_0_hw_fini.


But we may still need to call amdpug_vce_suspend/resume.

and not sure whether need to do ring test when resume back.


Best Regards

Rex


From: S, Shirish
Sent: Friday, August 10, 2018 2:15 PM
To: Deucher, Alexander; Zhu, Rex; Liu, Leo
Cc: amd-gfx@lists.freedesktop.org; S, Shirish
Subject: [PATCH] drm/amdpu/vce_v3: skip suspend and resume if powergated

This patch adds a mechanism by which the VCE 3.0 block
shall check if it was enabled or in use before suspending,
if it was powergated while entering suspend then there
is no need to repeat it in vce_3_0_suspend().
Similarly, if the block was powergated while entering suspend
itself then there is no need to resume it.

By this we not only make the suspend and resume sequence
more efficient, but also optimize the overall amdgpu suspend
and resume time by reducing the ring intialize and tests
for unused IP blocks.

Signed-off-by: Shirish S 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  2 ++
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 21 +
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 07924d4..aa85063 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1035,6 +1035,8 @@ struct amdgpu_device {

 /* vce */
 struct amdgpu_vce   vce;
+   boolis_vce_pg;
+   boolis_vce_disabled;

 /* vcn */
 struct amdgpu_vcn   vcn;
diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
index cc6ce6c..822cfd6 100644
--- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
@@ -326,6 +326,7 @@ static int vce_v3_0_start(struct amdgpu_device *adev)
 WREG32(mmGRBM_GFX_INDEX, mmGRBM_GFX_INDEX_DEFAULT);
 mutex_unlock(>grbm_idx_mutex);

+   adev->is_vce_pg = false;
 return 0;
 }

@@ -355,6 +356,7 @@ static int vce_v3_0_stop(struct amdgpu_device *adev)
 WREG32(mmGRBM_GFX_INDEX, mmGRBM_GFX_INDEX_DEFAULT);
 mutex_unlock(>grbm_idx_mutex);

+   adev->is_vce_pg = true;
 return 0;
 }

@@ -506,6 +508,17 @@ static int vce_v3_0_suspend(void *handle)
 int r;
 struct amdgpu_device *adev = (struct amdgpu_device *)handle;

+   /* Proceed with suspend sequence only if VCE is started
+* Mark the block as being disabled if its stopped.
+*/
+   if (adev->is_vce_pg) {
+   DRM_DEBUG("VCE is already powergated, not suspending\n");
+   adev->is_vce_disabled = true;
+   return 0;
+   }
+
+   adev->is_vce_disabled = false;
+
 r = vce_v3_0_hw_fini(adev);
 if (r)
 return r;
@@ -518,6 +531,14 @@ static int vce_v3_0_resume(void *handle)
 int r;
 struct amdgpu_device *adev = (struct amdgpu_device *)handle;

+   /* Proceed with resume sequence if VCE was enabled
+* while suspending.
+*/
+   if (adev->is_vce_disabled) {
+   DRM_DEBUG("VCE is powergated, not resuming the block\n");
+   return 0;
+   }
+
 r = amdgpu_vce_resume(adev);
 if (r)
 return r;
--
2.7.4

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

Re: [PATCH] drm/amdgpu/powerplay: check vrefresh when when changing displays

[Zhu, Rex]

Patch is Reviewed-by: Rex Zhu 


Thanks.



Best Regards

Rex


From: amd-gfx  on behalf of Alex Deucher 

Sent: Friday, August 10, 2018 4:16:23 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu/powerplay: check vrefresh when when changing 
displays

Compare the current vrefresh in addition to the number of displays
when determining whether or not the smu needs updates when changing
modes. The SMU needs to be updated if the vbi timeout changes due
to a different refresh rate.  Fixes flickering around mode changes
in some cases on polaris parts.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c| 3 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.h| 1 +
 drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c| 1 +
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c  | 3 ++-
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c   | 1 +
 drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 1 +
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c | 1 +
 drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 1 +
 8 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 380f282a64ba..ab759e38e4ea 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -4132,6 +4132,9 @@ 
smu7_check_smc_update_required_for_display_configuration(struct pp_hwmgr *hwmgr)
 if (data->display_timing.num_existing_displays != 
hwmgr->display_config->num_display)
 is_update_required = true;

+   if (data->display_timing.vrefresh != hwmgr->display_config->vrefresh)
+   is_update_required = true;
+
 if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_SclkDeepSleep)) {
 if (data->display_timing.min_clock_in_sr != 
hwmgr->display_config->min_core_set_clock_in_sr &&
 (data->display_timing.min_clock_in_sr >= 
SMU7_MINIMUM_ENGINE_CLOCK ||
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.h 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.h
index 3784ce6e50ab..69d361f8dfca 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.h
@@ -156,6 +156,7 @@ struct smu7_vbios_boot_state {
 struct smu7_display_timing {
 uint32_t  min_clock_in_sr;
 uint32_t  num_existing_displays;
+   uint32_t  vrefresh;
 };

 struct smu7_dpmlevel_enable_mask {
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
index fbe3ef4ee45c..18643e06bc6f 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
@@ -1231,6 +1231,7 @@ static int ci_populate_single_memory_level(
 memory_level->DisplayWatermark = PPSMC_DISPLAY_WATERMARK_LOW;

 data->display_timing.num_existing_displays = 
hwmgr->display_config->num_display;
+   data->display_timing.vrefresh = hwmgr->display_config->vrefresh;

 /* stutter mode not support on ci */

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
index 18048f8e2f13..ec14798e87b6 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
@@ -1210,7 +1210,8 @@ static int fiji_populate_single_memory_level(struct 
pp_hwmgr *hwmgr,
  * PECI_GetNumberOfActiveDisplays(hwmgr->pPECI,
  * &(data->DisplayTiming.numExistingDisplays));
  */
-   data->display_timing.num_existing_displays = 1;
+   data->display_timing.num_existing_displays = 
hwmgr->display_config->num_display;
+   data->display_timing.vrefresh = hwmgr->display_config->vrefresh;

 if (mclk_stutter_mode_threshold &&
 (clock <= mclk_stutter_mode_threshold) &&
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
index 9299b93aa09a..73aa368a454e 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
@@ -1280,6 +1280,7 @@ static int iceland_populate_single_memory_level(
 memory_level->DisplayWatermark = PPSMC_DISPLAY_WATERMARK_LOW;

 data->display_timing.num_existing_displays = 
hwmgr->display_config->num_display;
+   data->display_timing.vrefresh = hwmgr->display_config->vrefresh;

 /* stutter mode not support on iceland */

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
index 1276f168ff68..872d3824337b 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
+++ 

RE: [PATCH 2/2] drm/amdgpu/pp: endian fixes for processpptables.c

[Zhu, Rex]

Series is:

Reviewed-by: Rex Zhu 

Regards
Rex
-Original Message-
From: amd-gfx  On Behalf Of Alex Deucher
Sent: Wednesday, August 8, 2018 5:32 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander 
Subject: [PATCH 2/2] drm/amdgpu/pp: endian fixes for processpptables.c

Properly swap when reading from the vbios.

Signed-off-by: Alex Deucher 
---
 .../gpu/drm/amd/powerplay/hwmgr/processpptables.c  | 30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
index 925e17104f90..77c14671866c 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
@@ -757,8 +757,8 @@ static int init_non_clock_fields(struct pp_hwmgr *hwmgr,
ps->validation.supportedPowerLevels = pnon_clock_info->ucRequiredPower;
 
if (ATOM_PPLIB_NONCLOCKINFO_VER1 < version) {
-   ps->uvd_clocks.VCLK = pnon_clock_info->ulVCLK;
-   ps->uvd_clocks.DCLK = pnon_clock_info->ulDCLK;
+   ps->uvd_clocks.VCLK = le32_to_cpu(pnon_clock_info->ulVCLK);
+   ps->uvd_clocks.DCLK = le32_to_cpu(pnon_clock_info->ulDCLK);
} else {
ps->uvd_clocks.VCLK = 0;
ps->uvd_clocks.DCLK = 0;
@@ -937,8 +937,9 @@ int pp_tables_get_entry(struct pp_hwmgr *hwmgr,
if (entry_index > powerplay_table->ucNumStates)
return -1;
 
-   pstate_entry = (ATOM_PPLIB_STATE *)((unsigned 
long)powerplay_table + powerplay_table->usStateArrayOffset +
-   entry_index * 
powerplay_table->ucStateEntrySize);
+   pstate_entry = (ATOM_PPLIB_STATE *)((unsigned 
long)powerplay_table +
+   
le16_to_cpu(powerplay_table->usStateArrayOffset) +
+   entry_index * 
powerplay_table->ucStateEntrySize);
 
pnon_clock_info = (ATOM_PPLIB_NONCLOCK_INFO *)((unsigned 
long)powerplay_table +

le16_to_cpu(powerplay_table->usNonClockInfoArrayOffset) + @@ -1063,13 +1064,13 
@@ static int init_overdrive_limits(struct pp_hwmgr *hwmgr,
 , , );
 
if ((fw_info->ucTableFormatRevision == 1)
-   && (fw_info->usStructureSize >= 
sizeof(ATOM_FIRMWARE_INFO_V1_4)))
+   && (le16_to_cpu(fw_info->usStructureSize) >= 
+sizeof(ATOM_FIRMWARE_INFO_V1_4)))
result = init_overdrive_limits_V1_4(hwmgr,
powerplay_table,
(const ATOM_FIRMWARE_INFO_V1_4 *)fw_info);
 
else if ((fw_info->ucTableFormatRevision == 2)
-   && (fw_info->usStructureSize >= 
sizeof(ATOM_FIRMWARE_INFO_V2_1)))
+&& (le16_to_cpu(fw_info->usStructureSize) >= 
+sizeof(ATOM_FIRMWARE_INFO_V2_1)))
result = init_overdrive_limits_V2_1(hwmgr,
powerplay_table,
(const ATOM_FIRMWARE_INFO_V2_1 *)fw_info); @@ 
-1303,7 +1304,7 @@ static int init_clock_voltage_dependency(struct pp_hwmgr 
*hwmgr,
if (0 != powerplay_table4->usVddcDependencyOnSCLKOffset) {
table = (ATOM_PPLIB_Clock_Voltage_Dependency_Table *)
(((unsigned long) powerplay_table4) +
-   powerplay_table4->usVddcDependencyOnSCLKOffset);
+
le16_to_cpu(powerplay_table4->usVddcDependencyOnSCLKOffset));
result = get_clock_voltage_dependency_table(hwmgr,
>dyn_state.vddc_dependency_on_sclk, 
table);
}
@@ -1311,7 +1312,7 @@ static int init_clock_voltage_dependency(struct pp_hwmgr 
*hwmgr,
if (result == 0 && (0 != 
powerplay_table4->usVddciDependencyOnMCLKOffset)) {
table = (ATOM_PPLIB_Clock_Voltage_Dependency_Table *)
(((unsigned long) powerplay_table4) +
-   
powerplay_table4->usVddciDependencyOnMCLKOffset);
+
le16_to_cpu(powerplay_table4->usVddciDependencyOnMCLKOffset));
result = get_clock_voltage_dependency_table(hwmgr,
>dyn_state.vddci_dependency_on_mclk, 
table);
}
@@ -1319,7 +1320,7 @@ static int init_clock_voltage_dependency(struct pp_hwmgr 
*hwmgr,
if (result == 0 && (0 != 
powerplay_table4->usVddcDependencyOnMCLKOffset)) {
table = (ATOM_PPLIB_Clock_Voltage_Dependency_Table *)
(((unsigned long) powerplay_table4) +
-   powerplay_table4->usVddcDependencyOnMCLKOffset);
+

Re: [PATCH 3/3] drm/amd/pp: Add gfx power status check support on Rv/Vega12

[Zhu, Rex]

Currently, there is no use case except for debug.

So I will keep the patches in my local.

Thanks.



Best Regards

Rex




From: Alex Deucher 
Sent: Wednesday, August 1, 2018 11:13 PM
To: Zhu, Rex
Cc: Deucher, Alexander; Quan, Evan; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/amd/pp: Add gfx power status check support on 
Rv/Vega12

Does anything use it?  Might be useful for debugging, but I guess you'd 
probably use something like umr in that case.

Alex

On Tue, Jul 31, 2018 at 9:15 PM, Zhu, Rex 
mailto:rex@amd.com>> wrote:

Hi Alex,


Is it necessary to export an interface as "is_gfx_on" in powerplay to amdgpu?

It can show the current power state of gfx ip.



Best Regards

Rex



From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Zhu, Rex mailto:rex@amd.com>>
Sent: Monday, July 30, 2018 11:39 AM
To: Quan, Evan; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>

Subject: Re: [PATCH 3/3] drm/amd/pp: Add gfx power status check support on 
Rv/Vega12


> It means user was told the gfx is on but actually it may switches to gfxoff 
> already.


Correct.

So if the gfx is off, user should disable gfx off feature before they 
read/write the registers via mmio.

if gfx is on, that is not mean the gfx off feature is disabled. it  doesn't 
mean it is safe to visit the registers through mmio.


Best Regards

Rex


From: Quan, Evan
Sent: Monday, July 30, 2018 9:31 AM
To: Zhu, Rex; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 3/3] drm/amd/pp: Add gfx power status check support on 
Rv/Vega12


Since the gfxoff is always in dynamic switch, i do not think the status 
reported to user is reliable. It means user was told the gfx is on but actually 
it may switches to gfxoff already.


Regards,

Evan



From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Rex Zhu mailto:rex@amd.com>>
Sent: Sunday, July 29, 2018 7:42:27 PM
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Cc: Zhu, Rex
Subject: [PATCH 3/3] drm/amd/pp: Add gfx power status check support on Rv/Vega12

As gfx off is supported on Rv/Vega12, so this check is
helpful and necessary when visit gfx regesiter via mmio.

Signed-off-by: Rex Zhu mailto:rex@amd.com>>
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c  | 10 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 31 +-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 26d130a..da1be82 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -296,6 +296,15 @@ static bool smu10_is_gfx_on(struct pp_hwmgr *hwmgr)
 return false;
 }

+static bool smu10_is_hw_ip_on(struct pp_hwmgr *hwmgr,
+   enum amd_ip_block_type client)
+{
+   if (client == AMD_IP_BLOCK_TYPE_GFX)
+   return smu10_is_gfx_on(hwmgr);
+   else /* for other ip, to do */
+   return true;
+}
+
 static int smu10_disable_gfx_off(struct pp_hwmgr *hwmgr)
 {
 struct smu10_hwmgr *smu10_data = (struct smu10_hwmgr 
*)(hwmgr->backend);
@@ -1187,6 +1196,7 @@ static void smu10_powergate_vcn(struct pp_hwmgr *hwmgr, 
bool bgate)
 .smus_notify_pwe = smu10_smus_notify_pwe,
 .display_clock_voltage_request = smu10_display_clock_voltage_request,
 .powergate_gfx = smu10_gfx_off_control,
+   .is_hw_ip_on = smu10_is_hw_ip_on,
 };

 int smu10_init_function_pointers(struct pp_hwmgr *hwmgr)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
index 0789d64..ee44300 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
@@ -45,7 +45,7 @@
 #include "ppinterrupt.h"
 #include "pp_overdriver.h"
 #include "pp_thermal.h"
-
+#include "soc15_common.h"

 static int vega12_force_clock_level(struct pp_hwmgr *hwmgr,
 enum pp_clock_type type, uint32_t mask);
@@ -2320,6 +2320,34 @@ static int vega12_get_thermal_temperature_range(struct 
pp_hwmgr *hwmgr,
 return 0;
 }

+/* GFX HW Power Status can be queried from bits [1:0] of MP1_SMN_EXT_SCRATCH0
+ * 2'b00   GFX is OFF
+ * 2'b01   Transitioning out of GFXOFF state
+ * 2'b10   GFX is ON
+ * 2'b11   Transitioning into GFXOFF state
+*/
+
+static bool vega12_is_gfx_on(struct pp_hwmgr *hwmgr)
+{
+   uint32_t tmp;
+   struct amdgpu_device *adev = hwmgr->adev;
+
+   tmp = RREG32_SOC15(MP1, 0, mmMP1_SMN_EXT_SCRATCH0);
+   if (tmp == 1 || tmp == 2)
+   

Re: [PATCH 3/3] drm/amd/pp: Add gfx power status check support on Rv/Vega12

[Zhu, Rex]

Hi Alex,


Is it necessary to export an interface as "is_gfx_on" in powerplay to amdgpu?

It can show the current power state of gfx ip.



Best Regards

Rex



From: amd-gfx  on behalf of Zhu, Rex 

Sent: Monday, July 30, 2018 11:39 AM
To: Quan, Evan; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/amd/pp: Add gfx power status check support on 
Rv/Vega12


> It means user was told the gfx is on but actually it may switches to gfxoff 
> already.


Correct.

So if the gfx is off, user should disable gfx off feature before they 
read/write the registers via mmio.

if gfx is on, that is not mean the gfx off feature is disabled. it  doesn't 
mean it is safe to visit the registers through mmio.


Best Regards

Rex


From: Quan, Evan
Sent: Monday, July 30, 2018 9:31 AM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/amd/pp: Add gfx power status check support on 
Rv/Vega12


Since the gfxoff is always in dynamic switch, i do not think the status 
reported to user is reliable. It means user was told the gfx is on but actually 
it may switches to gfxoff already.


Regards,

Evan



From: amd-gfx  on behalf of Rex Zhu 

Sent: Sunday, July 29, 2018 7:42:27 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH 3/3] drm/amd/pp: Add gfx power status check support on Rv/Vega12

As gfx off is supported on Rv/Vega12, so this check is
helpful and necessary when visit gfx regesiter via mmio.

Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c  | 10 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 31 +-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 26d130a..da1be82 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -296,6 +296,15 @@ static bool smu10_is_gfx_on(struct pp_hwmgr *hwmgr)
 return false;
 }

+static bool smu10_is_hw_ip_on(struct pp_hwmgr *hwmgr,
+   enum amd_ip_block_type client)
+{
+   if (client == AMD_IP_BLOCK_TYPE_GFX)
+   return smu10_is_gfx_on(hwmgr);
+   else /* for other ip, to do */
+   return true;
+}
+
 static int smu10_disable_gfx_off(struct pp_hwmgr *hwmgr)
 {
 struct smu10_hwmgr *smu10_data = (struct smu10_hwmgr 
*)(hwmgr->backend);
@@ -1187,6 +1196,7 @@ static void smu10_powergate_vcn(struct pp_hwmgr *hwmgr, 
bool bgate)
 .smus_notify_pwe = smu10_smus_notify_pwe,
 .display_clock_voltage_request = smu10_display_clock_voltage_request,
 .powergate_gfx = smu10_gfx_off_control,
+   .is_hw_ip_on = smu10_is_hw_ip_on,
 };

 int smu10_init_function_pointers(struct pp_hwmgr *hwmgr)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
index 0789d64..ee44300 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
@@ -45,7 +45,7 @@
 #include "ppinterrupt.h"
 #include "pp_overdriver.h"
 #include "pp_thermal.h"
-
+#include "soc15_common.h"

 static int vega12_force_clock_level(struct pp_hwmgr *hwmgr,
 enum pp_clock_type type, uint32_t mask);
@@ -2320,6 +2320,34 @@ static int vega12_get_thermal_temperature_range(struct 
pp_hwmgr *hwmgr,
 return 0;
 }

+/* GFX HW Power Status can be queried from bits [1:0] of MP1_SMN_EXT_SCRATCH0
+ * 2'b00   GFX is OFF
+ * 2'b01   Transitioning out of GFXOFF state
+ * 2'b10   GFX is ON
+ * 2'b11   Transitioning into GFXOFF state
+*/
+
+static bool vega12_is_gfx_on(struct pp_hwmgr *hwmgr)
+{
+   uint32_t tmp;
+   struct amdgpu_device *adev = hwmgr->adev;
+
+   tmp = RREG32_SOC15(MP1, 0, mmMP1_SMN_EXT_SCRATCH0);
+   if (tmp == 1 || tmp == 2)
+   return true;
+   else
+   return false;
+}
+
+static bool vega12_is_hw_ip_on(struct pp_hwmgr *hwmgr,
+   enum amd_ip_block_type client)
+{
+   if (client == AMD_IP_BLOCK_TYPE_GFX)
+   return vega12_is_gfx_on(hwmgr);
+   else /* for other ip, to do */
+   return true;
+}
+
 static int vega12_enable_gfx_off(struct pp_hwmgr *hwmgr)
 {
 struct vega12_hwmgr *data =
@@ -2402,6 +2430,7 @@ static int vega12_gfx_off_control(struct pp_hwmgr *hwmgr, 
bool enable)
 .register_irq_handlers = smu9_register_irq_handlers,
 .start_thermal_controller = vega12_start_thermal_controller,
 .powergate_gfx = vega12_gfx_off_control,
+   .is_hw_ip_on = vega12_is_hw_ip_on,
 };

 int vega12_hwmgr_init(struct pp_hwmgr *hwmgr)
--
1.9.1

___
amd-gfx mailing list
amd-gfx@lists.freedesk

Re: [PATCH v2 2/4] drm/amdgpu: Put enable gfx off feature to a delay thread

[Zhu, Rex]

One problem,


I delay 500ms to enable gfx off feature.


Any concern about the delay time?


Best Regards

Rex


From: amd-gfx  on behalf of Rex Zhu 

Sent: Monday, July 30, 2018 5:23 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH v2 2/4] drm/amdgpu: Put enable gfx off feature to a delay thread

delay to enable gfx off feature to avoid gfx on/off frequently
suggested by Alex and Evan.

Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  2 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c|  8 ++--
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 188bc53..ff16689 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -992,6 +992,8 @@ struct amdgpu_gfx {
 boolgfx_off_state; /* true: enabled, 
false: disabled */
 struct mutexgfx_off_mutex;
 uint32_tgfx_off_req_count; /* default 1, 
enable gfx off: dec 1, disable gfx off: add 1 */
+   struct delayed_work gfx_off_delay_work;
+
 /* pipe reservation */
 struct mutexpipe_reserve_mutex;
 DECLARE_BITMAP  (pipe_reserve_bitmap, 
AMDGPU_MAX_COMPUTE_QUEUES);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 122653f..f6a6fb5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1925,6 +1925,19 @@ static void 
amdgpu_device_ip_late_init_func_handler(struct work_struct *work)
 DRM_ERROR("ib ring test failed (%d).\n", r);
 }

+static void amdgpu_device_delay_enable_gfx_off(struct work_struct *work)
+{
+   struct amdgpu_device *adev =
+   container_of(work, struct amdgpu_device, 
gfx.gfx_off_delay_work.work);
+
+   mutex_lock(>gfx.gfx_off_mutex);
+   if (!adev->gfx.gfx_off_state && !adev->gfx.gfx_off_req_count) {
+   if (!amdgpu_dpm_set_powergating_by_smu(adev, 
AMD_IP_BLOCK_TYPE_GFX, true))
+   adev->gfx.gfx_off_state = true;
+   }
+   mutex_unlock(>gfx.gfx_off_mutex);
+}
+
 /**
  * amdgpu_device_ip_suspend_phase1 - run suspend for hardware IPs (phase 1)
  *
@@ -2394,6 +2407,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,

 INIT_DELAYED_WORK(>late_init_work,
   amdgpu_device_ip_late_init_func_handler);
+   INIT_DELAYED_WORK(>gfx.gfx_off_delay_work,
+ amdgpu_device_delay_enable_gfx_off);

 adev->gfx.gfx_off_req_count = 1;
 adev->pm.ac_power = power_supply_is_system_supplied() > 0 ? true : 
false;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index 1cdb264..11d4d9f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -26,6 +26,9 @@
 #include "amdgpu.h"
 #include "amdgpu_gfx.h"

+/* 0.5 second timeout */
+#define GFX_OFF_DELAY_ENABLE msecs_to_jiffies(500)
+
 /*
  * GPU scratch registers helpers function.
  */
@@ -360,6 +363,7 @@ void amdgpu_gfx_off_ctrl(struct amdgpu_device *adev, bool 
enable)
 if (!adev->powerplay.pp_funcs->set_powergating_by_smu)
 return;

+
 mutex_lock(>gfx.gfx_off_mutex);

 if (!enable)
@@ -368,11 +372,11 @@ void amdgpu_gfx_off_ctrl(struct amdgpu_device *adev, bool 
enable)
 adev->gfx.gfx_off_req_count--;

 if (enable && !adev->gfx.gfx_off_state && 
!adev->gfx.gfx_off_req_count) {
-   if (!amdgpu_dpm_set_powergating_by_smu(adev, 
AMD_IP_BLOCK_TYPE_GFX, true))
-   adev->gfx.gfx_off_state = true;
+   schedule_delayed_work(>gfx.gfx_off_delay_work, 
GFX_OFF_DELAY_ENABLE);
 } else if (!enable && adev->gfx.gfx_off_state) {
 if (!amdgpu_dpm_set_powergating_by_smu(adev, 
AMD_IP_BLOCK_TYPE_GFX, false))
 adev->gfx.gfx_off_state = false;
 }
+
 mutex_unlock(>gfx.gfx_off_mutex);
 }
--
1.9.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
Subscribing to amd-gfx: Subscribe to amd-gfx by filling out the following form. 
Use of all freedesktop.org lists is subject to our Code of Conduct.


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

Re: [PATCH 1/4] drm/amdgpu: Add amdgpu_gfx_off_ctrl function

[Zhu, Rex]

>Maybe other clients should also not disable gfx off feature if this flag is 
>not set.


For disable gfx off feature, we just need to check adev->gfx.bin_off, it  mean

the gfx off feature is enabled.


Best Regards

Rex






From: Quan, Evan
Sent: Monday, July 30, 2018 12:32 PM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/amdgpu: Add amdgpu_gfx_off_ctrl function


>This flag should only be set by gfx ip after gfx cg/pg feature enabled.
>Other clients can't enable gfx off feature before this flag is set.


Maybe other clients should also not disable gfx off feature if this flag is not 
set.


Regards,

Evan

________
From: Zhu, Rex
Sent: Monday, July 30, 2018 11:46:00 AM
To: Quan, Evan; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/amdgpu: Add amdgpu_gfx_off_ctrl function


>"adev->gfx.bready_for_off" used for ?


This flag should only be set by gfx ip after gfx cg/pg feature enabled.

Other clients can't enable gfx off feature before this flag is set.


>"adev->gfx.bready_for_off == 0"

For disable gfx off feature, we don't need to care this flag.



Best Regards

Rex


From: Quan, Evan
Sent: Monday, July 30, 2018 11:12 AM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/amdgpu: Add amdgpu_gfx_off_ctrl function



+   if (adev->gfx.bready_for_off && !adev->gfx.bin_off
+   && !adev->gfx.disable_gfx_off_request) {

+   if (!amdgpu_dpm_set_powergating_by_smu(adev, 
AMD_IP_BLOCK_TYPE_GFX, true))
+   adev->gfx.bin_off = true;
+   } else if (!enable && adev->gfx.bin_off) {

What is "adev->gfx.bready_for_off" used for ? Do we need to consider 
"adev->gfx.bready_for_off == 0" case here?
+   if (!amdgpu_dpm_set_powergating_by_smu(adev, 
AMD_IP_BLOCK_TYPE_GFX, false))
+   adev->gfx.bin_off = false;
+   }


Regards,

Evan


From: amd-gfx  on behalf of Rex Zhu 

Sent: Sunday, July 29, 2018 7:35:47 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH 1/4] drm/amdgpu: Add amdgpu_gfx_off_ctrl function

This funciton as the entry of gfx off ctrl feature.
we arbitrat gfx off feature enable/disable in this
function.

Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  7 
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c| 52 ++
 3 files changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 5b7bb58..318961d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -988,6 +988,11 @@ struct amdgpu_gfx {
 /* NGG */
 struct amdgpu_ngg   ngg;

+   /* gfx off */
+   boolbready_for_off;
+   boolbin_off;
+   struct mutexgfx_off_ctrl_mutex;
+   uint32_tdisable_gfx_off_request;
 /* pipe reservation */
 struct mutexpipe_reserve_mutex;
 DECLARE_BITMAP  (pipe_reserve_bitmap, 
AMDGPU_MAX_COMPUTE_QUEUES);
@@ -1815,6 +1820,8 @@ void amdgpu_device_program_register_sequence(struct 
amdgpu_device *adev,
  const u32 array_size);

 bool amdgpu_device_is_px(struct drm_device *dev);
+void amdgpu_gfx_off_ctrl(struct amdgpu_device *adev,
+   enum amd_ip_block_type client, bool enable);
 /* atpx handler */
 #if defined(CONFIG_VGA_SWITCHEROO)
 void amdgpu_register_atpx_handler(void);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 745f760..b40ce6f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2367,6 +2367,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
 mutex_init(>gfx.gpu_clock_mutex);
 mutex_init(>srbm_mutex);
 mutex_init(>gfx.pipe_reserve_mutex);
+   mutex_init(>gfx.gfx_off_ctrl_mutex);
 mutex_init(>grbm_idx_mutex);
 mutex_init(>mn_lock);
 mutex_init(>virt.vf_errors.lock);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index 239bf2a..68fe9c8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -340,3 +340,55 @@ void amdgpu_gfx_compute_mqd_sw_fini(struct amdgpu_device 
*adev)
   >mqd_gpu_addr,
   >mqd_ptr);
 }
+
+/* amdgpu_gfx_off_ctrl - Handle gfx off feature enable/disable
+ *
+ * @adev: amdgpu_device 

Re: [PATCH 2/4] drm/amdgpu: Put enable gfx off feature to a delay thread

[Zhu, Rex]

>I think for disable gfxoff case, you need to use 
>cancle_delayed_work_sync((>gfx.delay_gfx_off_enable). E.g.


This makes code a bit complex.

we don't need to cancel the delay work.


In delay work thread, we also need to get the mutex. and check the request 
count value.

if Other clients have new disable requests before the delay work ran, the count 
will be added by 1.

so in the delay thread, gfx off will not be enabled.


Best Regards

Rex




From: Quan, Evan
Sent: Monday, July 30, 2018 10:26 AM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/4] drm/amdgpu: Put enable gfx off feature to a delay 
thread


-   if (!amdgpu_dpm_set_powergating_by_smu(adev, 
AMD_IP_BLOCK_TYPE_GFX, true))
-   adev->gfx.bin_off = true;
+   schedule_delayed_work(>gfx.delay_gfx_off_enable, 
GFX_OFF_DELAY_ENABLE);
 } else if (!enable && adev->gfx.bin_off) {
 if (!amdgpu_dpm_set_powergating_by_smu(adev, 
AMD_IP_BLOCK_TYPE_GFX, false))
 adev->gfx.bin_off = false;


I think for disable gfxoff case, you need to use 
cancle_delayed_work_sync((>gfx.delay_gfx_off_enable). E.g.


if (!cancle_delayed_work_sync((>gfx.delay_gfx_off_enable) && 
!amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_GFX, false))

 adev->gfx.bin_off = false;


Regards,

Evan


From: amd-gfx  on behalf of Rex Zhu 

Sent: Sunday, July 29, 2018 7:35:48 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH 2/4] drm/amdgpu: Put enable gfx off feature to a delay thread

delay to enable gfx off feature to avoid gfx on/off frequently

Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c|  6 --
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 318961d..b59ac02 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -993,6 +993,7 @@ struct amdgpu_gfx {
 boolbin_off;
 struct mutexgfx_off_ctrl_mutex;
 uint32_tdisable_gfx_off_request;
+   struct delayed_work delay_gfx_off_enable;
 /* pipe reservation */
 struct mutexpipe_reserve_mutex;
 DECLARE_BITMAP  (pipe_reserve_bitmap, 
AMDGPU_MAX_COMPUTE_QUEUES);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b40ce6f..9f8e267 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1925,6 +1925,20 @@ static void 
amdgpu_device_ip_late_init_func_handler(struct work_struct *work)
 DRM_ERROR("ib ring test failed (%d).\n", r);
 }

+static void amdgpu_device_delay_enable_gfx_off(struct work_struct *work)
+{
+   struct amdgpu_device *adev =
+   container_of(work, struct amdgpu_device, 
gfx.delay_gfx_off_enable.work);
+
+   mutex_lock(>gfx.gfx_off_ctrl_mutex);
+   if (adev->gfx.bready_for_off && !adev->gfx.bin_off
+   && adev->gfx.disable_gfx_off_request) {
+   if (!amdgpu_dpm_set_powergating_by_smu(adev, 
AMD_IP_BLOCK_TYPE_GFX, true))
+   adev->gfx.bin_off = true;
+   }
+   mutex_unlock(>gfx.gfx_off_ctrl_mutex);
+}
+
 /**
  * amdgpu_device_ip_suspend_phase1 - run suspend for hardware IPs (phase 1)
  *
@@ -2394,6 +2408,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,

 INIT_DELAYED_WORK(>late_init_work,
   amdgpu_device_ip_late_init_func_handler);
+   INIT_DELAYED_WORK(>gfx.delay_gfx_off_enable,
+ amdgpu_device_delay_enable_gfx_off);

 adev->pm.ac_power = power_supply_is_system_supplied() > 0 ? true : 
false;

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index 68fe9c8..1ea1e8b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -26,6 +26,9 @@
 #include "amdgpu.h"
 #include "amdgpu_gfx.h"

+/* 0.5 second timeout */
+#define GFX_OFF_DELAY_ENABLE msecs_to_jiffies(500)
+
 /*
  * GPU scratch registers helpers function.
  */
@@ -384,8 +387,7 @@ void amdgpu_gfx_off_ctrl(struct amdgpu_device *adev, enum 
amd_ip_block_type clie
  */
 if (adev->gfx.bready_for_off && !adev->gfx.bin_off
 && !adev->gfx.disable_gfx_off_request) {
-   if (!amdgpu_dpm_set_powergating_by_smu(adev, 
AMD_IP_BLOCK_TYPE_G

Re: [PATCH 1/4] drm/amdgpu: Add amdgpu_gfx_off_ctrl function

[Zhu, Rex]

>"adev->gfx.bready_for_off" used for ?


This flag should only be set by gfx ip after gfx cg/pg feature enabled.

Other clients can't enable gfx off feature before this flag is set.


>"adev->gfx.bready_for_off == 0"

For disable gfx off feature, we don't need to care this flag.



Best Regards

Rex


From: Quan, Evan
Sent: Monday, July 30, 2018 11:12 AM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/amdgpu: Add amdgpu_gfx_off_ctrl function



+   if (adev->gfx.bready_for_off && !adev->gfx.bin_off
+   && !adev->gfx.disable_gfx_off_request) {

+   if (!amdgpu_dpm_set_powergating_by_smu(adev, 
AMD_IP_BLOCK_TYPE_GFX, true))
+   adev->gfx.bin_off = true;
+   } else if (!enable && adev->gfx.bin_off) {

What is "adev->gfx.bready_for_off" used for ? Do we need to consider 
"adev->gfx.bready_for_off == 0" case here?
+   if (!amdgpu_dpm_set_powergating_by_smu(adev, 
AMD_IP_BLOCK_TYPE_GFX, false))
+   adev->gfx.bin_off = false;
+   }


Regards,

Evan


From: amd-gfx  on behalf of Rex Zhu 

Sent: Sunday, July 29, 2018 7:35:47 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH 1/4] drm/amdgpu: Add amdgpu_gfx_off_ctrl function

This funciton as the entry of gfx off ctrl feature.
we arbitrat gfx off feature enable/disable in this
function.

Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  7 
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c| 52 ++
 3 files changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 5b7bb58..318961d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -988,6 +988,11 @@ struct amdgpu_gfx {
 /* NGG */
 struct amdgpu_ngg   ngg;

+   /* gfx off */
+   boolbready_for_off;
+   boolbin_off;
+   struct mutexgfx_off_ctrl_mutex;
+   uint32_tdisable_gfx_off_request;
 /* pipe reservation */
 struct mutexpipe_reserve_mutex;
 DECLARE_BITMAP  (pipe_reserve_bitmap, 
AMDGPU_MAX_COMPUTE_QUEUES);
@@ -1815,6 +1820,8 @@ void amdgpu_device_program_register_sequence(struct 
amdgpu_device *adev,
  const u32 array_size);

 bool amdgpu_device_is_px(struct drm_device *dev);
+void amdgpu_gfx_off_ctrl(struct amdgpu_device *adev,
+   enum amd_ip_block_type client, bool enable);
 /* atpx handler */
 #if defined(CONFIG_VGA_SWITCHEROO)
 void amdgpu_register_atpx_handler(void);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 745f760..b40ce6f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2367,6 +2367,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
 mutex_init(>gfx.gpu_clock_mutex);
 mutex_init(>srbm_mutex);
 mutex_init(>gfx.pipe_reserve_mutex);
+   mutex_init(>gfx.gfx_off_ctrl_mutex);
 mutex_init(>grbm_idx_mutex);
 mutex_init(>mn_lock);
 mutex_init(>virt.vf_errors.lock);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index 239bf2a..68fe9c8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -340,3 +340,55 @@ void amdgpu_gfx_compute_mqd_sw_fini(struct amdgpu_device 
*adev)
   >mqd_gpu_addr,
   >mqd_ptr);
 }
+
+/* amdgpu_gfx_off_ctrl - Handle gfx off feature enable/disable
+ *
+ * @adev: amdgpu_device pointer
+ * @enum amd_ip_block_type gfx ip decide when to set ready for gfx off feature
+ * other clients send disable gfx off feature request
+ * @bool enable
+ *
+ * if gfx ip is ready for power off gfx ip, and no other clients's request for
+ * disable gfx off feature, driver will call smu to enable gfx off immediately.
+ * otherwise, driver will wait until the clients cancel the requests.
+ */
+
+void amdgpu_gfx_off_ctrl(struct amdgpu_device *adev, enum amd_ip_block_type 
client, bool enable)
+{
+   if (!(adev->powerplay.pp_feature & PP_GFXOFF_MASK))
+   return; /* gfx off feature is not supported or disabled by user 
via module parameter */
+
+   if (!adev->powerplay.pp_funcs->set_powergating_by_smu)
+   return; /* currently gfx off feature need smu support*/
+
+   mutex_lock(>gfx.gfx_off_ctrl_mutex);
+   if (client =

Re: [PATCH 3/3] drm/amd/pp: Add gfx power status check support on Rv/Vega12

[Zhu, Rex]

> It means user was told the gfx is on but actually it may switches to gfxoff 
> already.


Correct.

So if the gfx is off, user should disable gfx off feature before they 
read/write the registers via mmio.

if gfx is on, that is not mean the gfx off feature is disabled. it  doesn't 
mean it is safe to visit the registers through mmio.


Best Regards

Rex


From: Quan, Evan
Sent: Monday, July 30, 2018 9:31 AM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/amd/pp: Add gfx power status check support on 
Rv/Vega12


Since the gfxoff is always in dynamic switch, i do not think the status 
reported to user is reliable. It means user was told the gfx is on but actually 
it may switches to gfxoff already.


Regards,

Evan



From: amd-gfx  on behalf of Rex Zhu 

Sent: Sunday, July 29, 2018 7:42:27 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH 3/3] drm/amd/pp: Add gfx power status check support on Rv/Vega12

As gfx off is supported on Rv/Vega12, so this check is
helpful and necessary when visit gfx regesiter via mmio.

Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c  | 10 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 31 +-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 26d130a..da1be82 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -296,6 +296,15 @@ static bool smu10_is_gfx_on(struct pp_hwmgr *hwmgr)
 return false;
 }

+static bool smu10_is_hw_ip_on(struct pp_hwmgr *hwmgr,
+   enum amd_ip_block_type client)
+{
+   if (client == AMD_IP_BLOCK_TYPE_GFX)
+   return smu10_is_gfx_on(hwmgr);
+   else /* for other ip, to do */
+   return true;
+}
+
 static int smu10_disable_gfx_off(struct pp_hwmgr *hwmgr)
 {
 struct smu10_hwmgr *smu10_data = (struct smu10_hwmgr 
*)(hwmgr->backend);
@@ -1187,6 +1196,7 @@ static void smu10_powergate_vcn(struct pp_hwmgr *hwmgr, 
bool bgate)
 .smus_notify_pwe = smu10_smus_notify_pwe,
 .display_clock_voltage_request = smu10_display_clock_voltage_request,
 .powergate_gfx = smu10_gfx_off_control,
+   .is_hw_ip_on = smu10_is_hw_ip_on,
 };

 int smu10_init_function_pointers(struct pp_hwmgr *hwmgr)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
index 0789d64..ee44300 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
@@ -45,7 +45,7 @@
 #include "ppinterrupt.h"
 #include "pp_overdriver.h"
 #include "pp_thermal.h"
-
+#include "soc15_common.h"

 static int vega12_force_clock_level(struct pp_hwmgr *hwmgr,
 enum pp_clock_type type, uint32_t mask);
@@ -2320,6 +2320,34 @@ static int vega12_get_thermal_temperature_range(struct 
pp_hwmgr *hwmgr,
 return 0;
 }

+/* GFX HW Power Status can be queried from bits [1:0] of MP1_SMN_EXT_SCRATCH0
+ * 2'b00   GFX is OFF
+ * 2'b01   Transitioning out of GFXOFF state
+ * 2'b10   GFX is ON
+ * 2'b11   Transitioning into GFXOFF state
+*/
+
+static bool vega12_is_gfx_on(struct pp_hwmgr *hwmgr)
+{
+   uint32_t tmp;
+   struct amdgpu_device *adev = hwmgr->adev;
+
+   tmp = RREG32_SOC15(MP1, 0, mmMP1_SMN_EXT_SCRATCH0);
+   if (tmp == 1 || tmp == 2)
+   return true;
+   else
+   return false;
+}
+
+static bool vega12_is_hw_ip_on(struct pp_hwmgr *hwmgr,
+   enum amd_ip_block_type client)
+{
+   if (client == AMD_IP_BLOCK_TYPE_GFX)
+   return vega12_is_gfx_on(hwmgr);
+   else /* for other ip, to do */
+   return true;
+}
+
 static int vega12_enable_gfx_off(struct pp_hwmgr *hwmgr)
 {
 struct vega12_hwmgr *data =
@@ -2402,6 +2430,7 @@ static int vega12_gfx_off_control(struct pp_hwmgr *hwmgr, 
bool enable)
 .register_irq_handlers = smu9_register_irq_handlers,
 .start_thermal_controller = vega12_start_thermal_controller,
 .powergate_gfx = vega12_gfx_off_control,
+   .is_hw_ip_on = vega12_is_hw_ip_on,
 };

 int vega12_hwmgr_init(struct pp_hwmgr *hwmgr)
--
1.9.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
Subscribing to amd-gfx: Subscribe to amd-gfx by filling out the following form. 
Use of all freedesktop.org lists is subject to our Code of Conduct.


___
amd-gfx mailing list
amd-gfx@l

Re: [PATCH 2/3] drm/amd/powerplay: correct the argument for PPSMC_MSG_SetUclkFastSwitch

[Zhu, Rex]

Series is:
Reviewed-by: Rex Zhumailto:re...@amd.com>>


Best Regards
Rex




From: Quan, Evan
Sent: Monday, July 23, 2018 2:38 PM
To: Quan, Evan; amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: RE: [PATCH 2/3] drm/amd/powerplay: correct the argument for 
PPSMC_MSG_SetUclkFastSwitch

Ping ..

> -Original Message-
> From: Evan Quan 
> Sent: Friday, July 20, 2018 10:35 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex ; Quan, Evan 
> Subject: [PATCH 2/3] drm/amd/powerplay: correct the argument for
> PPSMC_MSG_SetUclkFastSwitch
>
> The argument was set wrongly. Fast/slow switch was asked when there is
> actually a slow/fast switch needed.
>
> Change-Id: Ibcfdf741dea1700cc3796f84291606231e732f4b
> Signed-off-by: Evan Quan 
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 +-
> drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> index bf7b8cfebe2b..002ed77a5268 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> @@ -3705,7 +3705,7 @@ static void
> vega10_notify_smc_display_change(struct pp_hwmgr *hwmgr,  {
>smum_send_msg_to_smc_with_parameter(hwmgr,
>PPSMC_MSG_SetUclkFastSwitch,
> - has_disp ? 0 : 1);
> + has_disp ? 1 : 0);
>  }
>
>  int vega10_display_clock_voltage_request(struct pp_hwmgr *hwmgr, diff --
> git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
> index 4ed218dd8ba7..35f96dacb50a 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
> @@ -1334,7 +1334,7 @@ static int vega12_notify_smc_display_change(struct
> pp_hwmgr *hwmgr,
>if (data->smu_features[GNLD_DPM_UCLK].enabled)
>return smum_send_msg_to_smc_with_parameter(hwmgr,
>PPSMC_MSG_SetUclkFastSwitch,
> - has_disp ? 0 : 1);
> + has_disp ? 1 : 0);
>
>return 0;
>  }
> --
> 2.18.0

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

Re: [PATCH 2/2] drm/amdgpu: Power down acp if board uses AZ

[Zhu, Rex]

Hi Alex,


I am Ok with the patch in v2.

just one question,


+if (!adev->acp.acp_cell)
+amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_ACP, true);


Do we need to check adev->acp.acp_cell before poweron/off ACP?




Best Regards

Rex


From: Alex Deucher 
Sent: Friday, July 20, 2018 12:53:37 AM
To: Zhu, Rex
Cc: amd-gfx list
Subject: Re: [PATCH 2/2] drm/amdgpu: Power down acp if board uses AZ


On Thu, Jul 19, 2018 at 11:14 AM, Zhu, Rex 
mailto:rex@amd.com>> wrote:

>We also need to power it back up in hw_fini and suspend and then power
>it back down in resume.

Yes, this logic will be added in acp block.
In this patch, we only power down acp when it was not used and have no inpact 
wen s3.

But I think when the asic comes out of S3/S4, the ACP block will be powered up 
again so it will have to be powered down again to avoid using power after 
resume.  So if the platform uses AZ rather than ACP, we need to handle that 
case and to power ACP back up on hw_fini() in case the driver gets reloaded.  
S4 works similarly.  Something like the attached patch.

Alex



Best Regards
Rex


From: Alex Deucher mailto:alexdeuc...@gmail.com>>
Sent: Thursday, July 19, 2018 9:56 PM
To: Zhu, Rex
Cc: amd-gfx list
Subject: Re: [PATCH 2/2] drm/amdgpu: Power down acp if board uses AZ

On Thu, Jul 19, 2018 at 4:46 AM, Rex Zhu 
mailto:rex@amd.com>> wrote:
> if board uses AZ rather than ACP, we power down acp
> through smu to save power.
>

We also need to power it back up in hw_fini and suspend and then power
it back down in resume.

Alex

> Signed-off-by: Rex Zhu mailto:rex@amd.com>>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> index 71efcf3..4e18a88 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> @@ -35,6 +35,7 @@
>
>  #include "acp_gfx_if.h"
>
> +
>  #define ACP_TILE_ON_MASK   0x03
>  #define ACP_TILE_OFF_MASK  0x02
>  #define ACP_TILE_ON_RETAIN_REG_MASK0x1f
> @@ -289,11 +290,12 @@ static int acp_hw_init(void *handle)
> r = amd_acp_hw_init(adev->acp.cgs_device,
> ip_block->version->major, 
> ip_block->version->minor);
> /* -ENODEV means board uses AZ rather than ACP */
> -   if (r == -ENODEV)
> +   if (r == -ENODEV) {
> +   amdgpu_dpm_set_powergating_by_smu(adev, 
> AMD_IP_BLOCK_TYPE_ACP, true);
> return 0;
> -   else if (r)
> +   } else if (r) {
> return r;
> -
> +   }
> if (adev->rmmio_size == 0 || adev->rmmio_size < 0x5289)
> return -EINVAL;
>
> --
> 1.9.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org<http://lists.freedesktop.org>
Subscribing to amd-gfx: Subscribe to amd-gfx by filling out the following form. 
Use of all freedesktop.org<http://freedesktop.org> lists is subject to our Code 
of Conduct.




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

Re: [PATCH 3/3] drm/amd/powerplay: disallow slow switch if NBPState is disabled

[Zhu, Rex]

Hi Evan，


Changing the title to "Only allow slow switch if NB pstate switch is enabled"   
can make patch more

understandable.



Best Regards

Rex



From: amd-gfx  on behalf of Zhu, Rex 

Sent: Friday, July 20, 2018 4:43 PM
To: Quan, Evan; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/amd/powerplay: disallow slow switch if NBPState is 
disabled


+   bool uclk_switching_disabled =
+(bool)hwmgr->display_config->nb_pstate_switch_disable;


Don't need type convert.


Best Regards

Rex



From: amd-gfx  on behalf of Evan Quan 

Sent: Friday, July 20, 2018 10:35 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan; Zhu, Rex
Subject: [PATCH 3/3] drm/amd/powerplay: disallow slow switch if NBPState is 
disabled

Otherwise there may be potential SMU performance issues.

Change-Id: I05a09bb05407f7b3705d79a1d2c6628385c80461
Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 5 -
 drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 5 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 002ed77a5268..ccb587607b03 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -3779,9 +3779,12 @@ static int 
vega10_notify_smc_display_config_after_ps_adjustment(
 struct PP_Clocks min_clocks = {0};
 uint32_t i;
 struct pp_display_clock_request clock_req;
+   bool uclk_switching_disabled =
+   (bool)hwmgr->display_config->nb_pstate_switch_disable;

 if ((hwmgr->display_config->num_display > 1) &&
-!hwmgr->display_config->multi_monitor_in_sync)
+!hwmgr->display_config->multi_monitor_in_sync &&
+!uclk_switching_disabled)
 vega10_notify_smc_display_change(hwmgr, false);
 else
 vega10_notify_smc_display_change(hwmgr, true);
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
index 35f96dacb50a..e3b11ae8fdb8 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
@@ -1387,9 +1387,12 @@ static int 
vega12_notify_smc_display_config_after_ps_adjustment(
 (struct vega12_hwmgr *)(hwmgr->backend);
 struct PP_Clocks min_clocks = {0};
 struct pp_display_clock_request clock_req;
+   bool uclk_switching_disabled =
+   (bool)hwmgr->display_config->nb_pstate_switch_disable;

 if ((hwmgr->display_config->num_display > 1) &&
-   !hwmgr->display_config->multi_monitor_in_sync)
+!hwmgr->display_config->multi_monitor_in_sync &&
+!uclk_switching_disabled)
 vega12_notify_smc_display_change(hwmgr, false);
 else
 vega12_notify_smc_display_change(hwmgr, true);
--
2.18.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
Subscribing to amd-gfx: Subscribe to amd-gfx by filling out the following form. 
Use of all freedesktop.org lists is subject to our Code of Conduct.


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

Re: [PATCH 1/3] drm/amd/powerplay: slow UCLK switch when multiple displays not in sync

[Zhu, Rex]

Reviewed-by: Rex Zhumailto:re...@amd.com>>


Regards
Rex


From: amd-gfx  on behalf of Evan Quan 

Sent: Friday, July 20, 2018 10:35 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan; Zhu, Rex
Subject: [PATCH 1/3] drm/amd/powerplay: slow UCLK switch when multiple displays 
not in sync

Slow switch for UCLK when there is multiple displays and they are
not in sync.

Change-Id: I8a296400d8b96443cc95518905307fc76c9f9e44
Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 1a0dccb3fac1..bf7b8cfebe2b 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -3780,7 +3780,8 @@ static int 
vega10_notify_smc_display_config_after_ps_adjustment(
 uint32_t i;
 struct pp_display_clock_request clock_req;

-   if (hwmgr->display_config->num_display > 1)
+   if ((hwmgr->display_config->num_display > 1) &&
+!hwmgr->display_config->multi_monitor_in_sync)
 vega10_notify_smc_display_change(hwmgr, false);
 else
 vega10_notify_smc_display_change(hwmgr, true);
--
2.18.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
Subscribing to amd-gfx: Subscribe to amd-gfx by filling out the following form. 
Use of all freedesktop.org lists is subject to our Code of Conduct.


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

Re: [PATCH 3/3] drm/amd/powerplay: disallow slow switch if NBPState is disabled

[Zhu, Rex]

+   bool uclk_switching_disabled =
+(bool)hwmgr->display_config->nb_pstate_switch_disable;


Don't need type convert.


Best Regards

Rex



From: amd-gfx  on behalf of Evan Quan 

Sent: Friday, July 20, 2018 10:35 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan; Zhu, Rex
Subject: [PATCH 3/3] drm/amd/powerplay: disallow slow switch if NBPState is 
disabled

Otherwise there may be potential SMU performance issues.

Change-Id: I05a09bb05407f7b3705d79a1d2c6628385c80461
Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 5 -
 drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 5 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 002ed77a5268..ccb587607b03 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -3779,9 +3779,12 @@ static int 
vega10_notify_smc_display_config_after_ps_adjustment(
 struct PP_Clocks min_clocks = {0};
 uint32_t i;
 struct pp_display_clock_request clock_req;
+   bool uclk_switching_disabled =
+   (bool)hwmgr->display_config->nb_pstate_switch_disable;

 if ((hwmgr->display_config->num_display > 1) &&
-!hwmgr->display_config->multi_monitor_in_sync)
+!hwmgr->display_config->multi_monitor_in_sync &&
+!uclk_switching_disabled)
 vega10_notify_smc_display_change(hwmgr, false);
 else
 vega10_notify_smc_display_change(hwmgr, true);
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
index 35f96dacb50a..e3b11ae8fdb8 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
@@ -1387,9 +1387,12 @@ static int 
vega12_notify_smc_display_config_after_ps_adjustment(
 (struct vega12_hwmgr *)(hwmgr->backend);
 struct PP_Clocks min_clocks = {0};
 struct pp_display_clock_request clock_req;
+   bool uclk_switching_disabled =
+   (bool)hwmgr->display_config->nb_pstate_switch_disable;

 if ((hwmgr->display_config->num_display > 1) &&
-   !hwmgr->display_config->multi_monitor_in_sync)
+!hwmgr->display_config->multi_monitor_in_sync &&
+!uclk_switching_disabled)
 vega12_notify_smc_display_change(hwmgr, false);
 else
 vega12_notify_smc_display_change(hwmgr, true);
--
2.18.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
Subscribing to amd-gfx: Subscribe to amd-gfx by filling out the following form. 
Use of all freedesktop.org lists is subject to our Code of Conduct.


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

Re: [PATCH 2/2] drm/amdgpu: Power down acp if board uses AZ

[Zhu, Rex]

>We also need to power it back up in hw_fini and suspend and then power
>it back down in resume.

Yes, this logic will be added in acp block.
In this patch, we only power down acp when it was not used and have no inpact 
wen s3.

Best Regards
Rex


From: Alex Deucher 
Sent: Thursday, July 19, 2018 9:56 PM
To: Zhu, Rex
Cc: amd-gfx list
Subject: Re: [PATCH 2/2] drm/amdgpu: Power down acp if board uses AZ

On Thu, Jul 19, 2018 at 4:46 AM, Rex Zhu  wrote:
> if board uses AZ rather than ACP, we power down acp
> through smu to save power.
>

We also need to power it back up in hw_fini and suspend and then power
it back down in resume.

Alex

> Signed-off-by: Rex Zhu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> index 71efcf3..4e18a88 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> @@ -35,6 +35,7 @@
>
>  #include "acp_gfx_if.h"
>
> +
>  #define ACP_TILE_ON_MASK   0x03
>  #define ACP_TILE_OFF_MASK  0x02
>  #define ACP_TILE_ON_RETAIN_REG_MASK0x1f
> @@ -289,11 +290,12 @@ static int acp_hw_init(void *handle)
> r = amd_acp_hw_init(adev->acp.cgs_device,
> ip_block->version->major, 
> ip_block->version->minor);
> /* -ENODEV means board uses AZ rather than ACP */
> -   if (r == -ENODEV)
> +   if (r == -ENODEV) {
> +   amdgpu_dpm_set_powergating_by_smu(adev, 
> AMD_IP_BLOCK_TYPE_ACP, true);
> return 0;
> -   else if (r)
> +   } else if (r) {
> return r;
> -
> +   }
> if (adev->rmmio_size == 0 || adev->rmmio_size < 0x5289)
> return -EINVAL;
>
> --
> 1.9.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
Subscribing to amd-gfx: Subscribe to amd-gfx by filling out the following form. 
Use of all freedesktop.org lists is subject to our Code of Conduct.



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

Re: [PATCH] drm/amdgpu/powerplay: use irq source defines for smu7 sources

[Zhu, Rex]

Reviewed-by: Rex Zhumailto:re...@amd.com>>


Best Regards
Rex




From: amd-gfx  on behalf of Alex Deucher 

Sent: Thursday, July 19, 2018 5:08 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu/powerplay: use irq source defines for smu7 sources

Use the newly added irq source defines rather than magic numbers
for smu7 thermal interrupts.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
index 8eea49e4c74d..2aab1b475945 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
@@ -27,6 +27,7 @@
 #include "atom.h"
 #include "ivsrcid/thm/irqsrcs_thm_9_0.h"
 #include "ivsrcid/smuio/irqsrcs_smuio_9_0.h"
+#include "ivsrcid/ivsrcid_vislands30.h"

 uint8_t convert_to_vid(uint16_t vddc)
 {
@@ -545,17 +546,17 @@ int phm_irq_process(struct amdgpu_device *adev,
 uint32_t src_id = entry->src_id;

 if (client_id == AMDGPU_IH_CLIENTID_LEGACY) {
-   if (src_id == 230)
+   if (src_id == VISLANDS30_IV_SRCID_CG_TSS_THERMAL_LOW_TO_HIGH)
 pr_warn("GPU over temperature range detected on PCIe 
%d:%d.%d!\n",
 PCI_BUS_NUM(adev->pdev->devfn),
 PCI_SLOT(adev->pdev->devfn),
 PCI_FUNC(adev->pdev->devfn));
-   else if (src_id == 231)
+   else if (src_id == 
VISLANDS30_IV_SRCID_CG_TSS_THERMAL_HIGH_TO_LOW)
 pr_warn("GPU under temperature range detected on PCIe 
%d:%d.%d!\n",
 PCI_BUS_NUM(adev->pdev->devfn),
 PCI_SLOT(adev->pdev->devfn),
 PCI_FUNC(adev->pdev->devfn));
-   else if (src_id == 83)
+   else if (src_id == VISLANDS30_IV_SRCID_GPIO_19)
 pr_warn("GPU Critical Temperature Fault detected on 
PCIe %d:%d.%d!\n",
 PCI_BUS_NUM(adev->pdev->devfn),
 PCI_SLOT(adev->pdev->devfn),
--
2.13.6

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org
lists.freedesktop.org
Subscribing to amd-gfx: Subscribe to amd-gfx by filling out the following form. 
Use of all freedesktop.org lists is subject to our Code of Conduct.


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

Re: [PATCH] drm/amdgpu/pm: Remove VLA usage

[Zhu, Rex]

Patch has been applied to our internal amd-staging-drm-next tree.


Thanks.


Best Regards

Rex


From: Christian K?nig 
Sent: Tuesday, July 17, 2018 2:58:21 PM
To: Zhu, Rex; Kees Cook; Deucher, Alexander
Cc: Zhou, David(ChunMing); David Airlie; Kuehling, Felix; LKML; amd-gfx list; 
Huang, Ray; Maling list - DRI developers; Koenig, Christian
Subject: Re: [PATCH] drm/amdgpu/pm: Remove VLA usage

Who's tree should this go through?
To answer the question: When Rex is ok with that he pushes it to our internal 
amd-staging-drm-next tree.

Alex then pushes that tree to a public server and at some point sends a pull 
request for inclusion in drm-next.

Regards,
Christian.

Am 17.07.2018 um 08:23 schrieb Zhu, Rex:
Patch is:
Reviewed-by: Rex Zhumailto:re...@amd.com>>



Best Regards
Rex



From: keesc...@google.com<mailto:keesc...@google.com> 
<mailto:keesc...@google.com> on behalf of Kees Cook 
<mailto:keesc...@chromium.org>
Sent: Tuesday, July 17, 2018 11:59 AM
To: Deucher, Alexander
Cc: LKML; Koenig, Christian; Zhou, David(ChunMing); David Airlie; Zhu, Rex; 
Huang, Ray; Kuehling, Felix; amd-gfx list; Maling list - DRI developers
Subject: Re: [PATCH] drm/amdgpu/pm: Remove VLA usage

On Wed, Jun 20, 2018 at 11:26 AM, Kees Cook 
<mailto:keesc...@chromium.org> wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> uses the maximum sane buffer size and removes copy/paste code.
>
> [1] 
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>
> Signed-off-by: Kees Cook <mailto:keesc...@chromium.org>

Friendly ping! Who's tree should this go through?

Thanks!

-Kees

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 100 +++--
>  1 file changed, 42 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> index b455da487782..5eb98cde22ed 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> @@ -593,40 +593,59 @@ static ssize_t amdgpu_get_pp_dpm_sclk(struct device 
> *dev,
> return snprintf(buf, PAGE_SIZE, "\n");
>  }
>
> -static ssize_t amdgpu_set_pp_dpm_sclk(struct device *dev,
> -   struct device_attribute *attr,
> -   const char *buf,
> -   size_t count)
> +/*
> + * Worst case: 32 bits individually specified, in octal at 12 characters
> + * per line (+1 for \n).
> + */
> +#define AMDGPU_MASK_BUF_MAX(32 * 13)
> +
> +static ssize_t amdgpu_read_mask(const char *buf, size_t count, uint32_t 
> *mask)
>  {
> -   struct drm_device *ddev = dev_get_drvdata(dev);
> -   struct amdgpu_device *adev = ddev->dev_private;
> int ret;
> long level;
> -   uint32_t mask = 0;
> char *sub_str = NULL;
> char *tmp;
> -   char buf_cpy[count];
> +   char buf_cpy[AMDGPU_MASK_BUF_MAX + 1];
> const char delimiter[3] = {' ', '\n', '\0'};
> +   size_t bytes;
>
> -   memcpy(buf_cpy, buf, count+1);
> +   *mask = 0;
> +
> +   bytes = min(count, sizeof(buf_cpy) - 1);
> +   memcpy(buf_cpy, buf, bytes);
> +   buf_cpy[bytes] = '\0';
> tmp = buf_cpy;
> while (tmp[0]) {
> -   sub_str =  strsep(, delimiter);
> +   sub_str = strsep(, delimiter);
> if (strlen(sub_str)) {
> ret = kstrtol(sub_str, 0, );
> -
> -   if (ret) {
> -   count = -EINVAL;
> -   goto fail;
> -   }
> -   mask |= 1 << level;
> +   if (ret)
> +   return -EINVAL;
> +   *mask |= 1 << level;
> } else
> break;
> }
> +
> +   return 0;
> +}
> +
> +static ssize_t amdgpu_set_pp_dpm_sclk(struct device *dev,
> +   struct device_attribute *attr,
> +   const char *buf,
> +   size_t count)
> +{
> +   struct drm_device *ddev = dev_get_drvdata(dev);
> +   struct amdgpu_device *adev = ddev->dev_private;
> +   int ret;
> +   uint32_t mask = 0;
> +
> +   ret = amdgpu_read_mask(buf, count, );
> +   if (ret)
> +   return ret;
> +
> if (adev->powerplay.pp_funcs->force_clock_level)
> amdgpu_dpm_force_clock_level(adev, PP_SCLK, mask);
>
> -fail:
> return count;
>  }
>
> @@ -651,32 +670,15 @@ static ssize_t amdgpu_set_pp_dpm_mclk(struct device 
&

Re: [PATCH 1/2] drm/amd/pp: Set Max clock level to display by default

[Zhu, Rex]

>shouldn't we still assign simple_clocks.level to clocks->max_clocks_state if 
>it's non-zero?

Yes, Thanks for your reminding.


Best Regards

Rex




From: Wentland, Harry
Sent: Wednesday, July 18, 2018 2:29 AM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/amd/pp: Set Max clock level to display by default



On 2018-07-17 08:36 AM, Rex Zhu wrote:
> avoid the error in dmesg:
> [drm:dm_pp_get_static_clocks]
> *ERROR* DM_PPLIB: invalid powerlevel state: 0!
>
> Signed-off-by: Rex Zhu 
> ---
>  drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
> b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> index 75c2082..63adcd1 100644
> --- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> +++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> @@ -998,7 +998,7 @@ static int pp_get_display_power_level(void *handle,
>  static int pp_get_current_clocks(void *handle,
>struct amd_pp_clock_info *clocks)
>  {
> - struct amd_pp_simple_clock_info simple_clocks;
> + struct amd_pp_simple_clock_info simple_clocks = { 0 };
>struct pp_clock_info hw_clocks;
>struct pp_hwmgr *hwmgr = handle;
>int ret = 0;
> @@ -1034,7 +1034,8 @@ static int pp_get_current_clocks(void *handle,
>clocks->max_engine_clock_in_sr = hw_clocks.max_eng_clk;
>clocks->min_engine_clock_in_sr = hw_clocks.min_eng_clk;
>
> - clocks->max_clocks_state = simple_clocks.level;
> + if (simple_clocks.level == 0)
> + clocks->max_clocks_state = PP_DAL_POWERLEVEL_7;

shouldn't we still assign simple_clocks.level to clocks->max_clocks_state if 
it's non-zero?

Harry

>
>if (0 == phm_get_current_shallow_sleep_clocks(hwmgr, 
> >current_ps->hardware, _clocks)) {
>clocks->max_engine_clock_in_sr = hw_clocks.max_eng_clk;
> @@ -1137,6 +1138,8 @@ static int pp_get_display_mode_validation_clocks(void 
> *handle,
>if (!hwmgr || !hwmgr->pm_en ||!clocks)
>return -EINVAL;
>
> + clocks->level = PP_DAL_POWERLEVEL_7;
> +
>mutex_lock(>smu_lock);
>
>if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps, 
> PHM_PlatformCaps_DynamicPatchPowerState))
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu/pm: Remove VLA usage

[Zhu, Rex]

Patch is:
Reviewed-by: Rex Zhumailto:re...@amd.com>>



Best Regards
Rex



From: keesc...@google.com  on behalf of Kees Cook 

Sent: Tuesday, July 17, 2018 11:59 AM
To: Deucher, Alexander
Cc: LKML; Koenig, Christian; Zhou, David(ChunMing); David Airlie; Zhu, Rex; 
Huang, Ray; Kuehling, Felix; amd-gfx list; Maling list - DRI developers
Subject: Re: [PATCH] drm/amdgpu/pm: Remove VLA usage

On Wed, Jun 20, 2018 at 11:26 AM, Kees Cook  wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> uses the maximum sane buffer size and removes copy/paste code.
>
> [1] 
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>
> Signed-off-by: Kees Cook 

Friendly ping! Who's tree should this go through?

Thanks!

-Kees

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 100 +++--
>  1 file changed, 42 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> index b455da487782..5eb98cde22ed 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> @@ -593,40 +593,59 @@ static ssize_t amdgpu_get_pp_dpm_sclk(struct device 
> *dev,
> return snprintf(buf, PAGE_SIZE, "\n");
>  }
>
> -static ssize_t amdgpu_set_pp_dpm_sclk(struct device *dev,
> -   struct device_attribute *attr,
> -   const char *buf,
> -   size_t count)
> +/*
> + * Worst case: 32 bits individually specified, in octal at 12 characters
> + * per line (+1 for \n).
> + */
> +#define AMDGPU_MASK_BUF_MAX(32 * 13)
> +
> +static ssize_t amdgpu_read_mask(const char *buf, size_t count, uint32_t 
> *mask)
>  {
> -   struct drm_device *ddev = dev_get_drvdata(dev);
> -   struct amdgpu_device *adev = ddev->dev_private;
> int ret;
> long level;
> -   uint32_t mask = 0;
> char *sub_str = NULL;
> char *tmp;
> -   char buf_cpy[count];
> +   char buf_cpy[AMDGPU_MASK_BUF_MAX + 1];
> const char delimiter[3] = {' ', '\n', '\0'};
> +   size_t bytes;
>
> -   memcpy(buf_cpy, buf, count+1);
> +   *mask = 0;
> +
> +   bytes = min(count, sizeof(buf_cpy) - 1);
> +   memcpy(buf_cpy, buf, bytes);
> +   buf_cpy[bytes] = '\0';
> tmp = buf_cpy;
> while (tmp[0]) {
> -   sub_str =  strsep(, delimiter);
> +   sub_str = strsep(, delimiter);
> if (strlen(sub_str)) {
> ret = kstrtol(sub_str, 0, );
> -
> -   if (ret) {
> -   count = -EINVAL;
> -   goto fail;
> -   }
> -   mask |= 1 << level;
> +   if (ret)
> +   return -EINVAL;
> +   *mask |= 1 << level;
> } else
> break;
> }
> +
> +   return 0;
> +}
> +
> +static ssize_t amdgpu_set_pp_dpm_sclk(struct device *dev,
> +   struct device_attribute *attr,
> +   const char *buf,
> +   size_t count)
> +{
> +   struct drm_device *ddev = dev_get_drvdata(dev);
> +   struct amdgpu_device *adev = ddev->dev_private;
> +   int ret;
> +   uint32_t mask = 0;
> +
> +   ret = amdgpu_read_mask(buf, count, );
> +   if (ret)
> +   return ret;
> +
> if (adev->powerplay.pp_funcs->force_clock_level)
> amdgpu_dpm_force_clock_level(adev, PP_SCLK, mask);
>
> -fail:
> return count;
>  }
>
> @@ -651,32 +670,15 @@ static ssize_t amdgpu_set_pp_dpm_mclk(struct device 
> *dev,
> struct drm_device *ddev = dev_get_drvdata(dev);
> struct amdgpu_device *adev = ddev->dev_private;
> int ret;
> -   long level;
> uint32_t mask = 0;
> -   char *sub_str = NULL;
> -   char *tmp;
> -   char buf_cpy[count];
> -   const char delimiter[3] = {' ', '\n', '\0'};
>
> -   memcpy(buf_cpy, buf, count+1);
> -   tmp = buf_cpy;
> -   while (tmp[0]) {
> -   sub_str =  strsep(, delimiter);
> -   if (strlen(sub_str)) {
> -   ret = kstrtol(sub_str, 0, );
> +   ret = amdgpu_read_mask(buf, count, );
> +   if (ret)
> +   return ret;
>
> -   if (ret) {
> -   count = -EINVAL;
> -   goto fail;
> -   

Re: [PATCH 1/4] drm/amdgpu/pp/smu7: use a local variable for toc indexing

[Zhu, Rex]

Series is:

Reviewed-by: Rex Zhumailto:re...@amd.com>>



Best Regards

Rex


?? Outlook for Android


From: amd-gfx  on behalf of Alex Deucher 

Sent: Thursday, July 12, 2018 10:39:38 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander; sta...@vger.kernel.org
Subject: [PATCH 1/4] drm/amdgpu/pp/smu7: use a local variable for toc indexing

Rather than using the index variable stored in vram.  If
the device fails to come back online after a resume cycle,
reads from vram will return all 1s which will cause a
segfault. Based on a patch from Thomas Martitz .
This avoids the segfault, but we still need to sort out
why the GPU does not come back online after a resume.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105760
Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 23 +++---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
index d644a9bb9078..9f407c48d4f0 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
@@ -381,6 +381,7 @@ int smu7_request_smu_load_fw(struct pp_hwmgr *hwmgr)
 uint32_t fw_to_load;
 int result = 0;
 struct SMU_DRAMData_TOC *toc;
+   uint32_t num_entries = 0;

 if (!hwmgr->reload_fw) {
 pr_info("skip reloading...\n");
@@ -422,41 +423,41 @@ int smu7_request_smu_load_fw(struct pp_hwmgr *hwmgr)
 }

 toc = (struct SMU_DRAMData_TOC *)smu_data->header;
-   toc->num_entries = 0;
 toc->structure_version = 1;

 PP_ASSERT_WITH_CODE(0 == smu7_populate_single_firmware_entry(hwmgr,
-   UCODE_ID_RLC_G, 
>entry[toc->num_entries++]),
+   UCODE_ID_RLC_G, >entry[num_entries++]),
 "Failed to Get Firmware Entry.", return 
-EINVAL);
 PP_ASSERT_WITH_CODE(0 == smu7_populate_single_firmware_entry(hwmgr,
-   UCODE_ID_CP_CE, 
>entry[toc->num_entries++]),
+   UCODE_ID_CP_CE, >entry[num_entries++]),
 "Failed to Get Firmware Entry.", return 
-EINVAL);
 PP_ASSERT_WITH_CODE(0 == smu7_populate_single_firmware_entry(hwmgr,
-   UCODE_ID_CP_PFP, 
>entry[toc->num_entries++]),
+   UCODE_ID_CP_PFP, >entry[num_entries++]),
 "Failed to Get Firmware Entry.", return 
-EINVAL);
 PP_ASSERT_WITH_CODE(0 == smu7_populate_single_firmware_entry(hwmgr,
-   UCODE_ID_CP_ME, 
>entry[toc->num_entries++]),
+   UCODE_ID_CP_ME, >entry[num_entries++]),
 "Failed to Get Firmware Entry.", return 
-EINVAL);
 PP_ASSERT_WITH_CODE(0 == smu7_populate_single_firmware_entry(hwmgr,
-   UCODE_ID_CP_MEC, 
>entry[toc->num_entries++]),
+   UCODE_ID_CP_MEC, >entry[num_entries++]),
 "Failed to Get Firmware Entry.", return 
-EINVAL);
 PP_ASSERT_WITH_CODE(0 == smu7_populate_single_firmware_entry(hwmgr,
-   UCODE_ID_CP_MEC_JT1, 
>entry[toc->num_entries++]),
+   UCODE_ID_CP_MEC_JT1, 
>entry[num_entries++]),
 "Failed to Get Firmware Entry.", return 
-EINVAL);
 PP_ASSERT_WITH_CODE(0 == smu7_populate_single_firmware_entry(hwmgr,
-   UCODE_ID_CP_MEC_JT2, 
>entry[toc->num_entries++]),
+   UCODE_ID_CP_MEC_JT2, 
>entry[num_entries++]),
 "Failed to Get Firmware Entry.", return 
-EINVAL);
 PP_ASSERT_WITH_CODE(0 == smu7_populate_single_firmware_entry(hwmgr,
-   UCODE_ID_SDMA0, 
>entry[toc->num_entries++]),
+   UCODE_ID_SDMA0, >entry[num_entries++]),
 "Failed to Get Firmware Entry.", return 
-EINVAL);
 PP_ASSERT_WITH_CODE(0 == smu7_populate_single_firmware_entry(hwmgr,
-   UCODE_ID_SDMA1, 
>entry[toc->num_entries++]),
+   UCODE_ID_SDMA1, >entry[num_entries++]),
 "Failed to Get Firmware Entry.", return 
-EINVAL);
 if (!hwmgr->not_vf)
 PP_ASSERT_WITH_CODE(0 == 
smu7_populate_single_firmware_entry(hwmgr,
-   UCODE_ID_MEC_STORAGE, 
>entry[toc->num_entries++]),
+   UCODE_ID_MEC_STORAGE, 
>entry[num_entries++]),
 "Failed to Get Firmware Entry.", return 
-EINVAL);

+   toc->num_entries = num_entries;
 

Re: [PATCH 3/3] drm/amdgpu/pp: switch smu callback type for get_argument()

[Zhu, Rex]

Series is:

Reviewed-by: Rex Zhumailto:re...@amd.com>>



Best Regards

Rex


?? Outlook for Android


From: amd-gfx  on behalf of Alex Deucher 

Sent: Friday, July 13, 2018 4:23:06 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 3/3] drm/amdgpu/pp: switch smu callback type for get_argument()

return a uint32_t rather than an int to properly reflect
what the function does.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h   | 2 +-
 drivers/gpu/drm/amd/powerplay/inc/smumgr.h  | 2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c | 2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c  | 4 ++--
 drivers/gpu/drm/amd/powerplay/smumgr/smu9_smumgr.c  | 2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/smu9_smumgr.h  | 2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c   | 2 +-
 7 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h 
b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
index b3363f26039a..d3d96260f440 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
@@ -194,7 +194,7 @@ struct pp_smumgr_func {
 int (*request_smu_load_fw)(struct pp_hwmgr  *hwmgr);
 int (*request_smu_load_specific_fw)(struct pp_hwmgr  *hwmgr,
 uint32_t firmware);
-   int (*get_argument)(struct pp_hwmgr  *hwmgr);
+   uint32_t (*get_argument)(struct pp_hwmgr  *hwmgr);
 int (*send_msg_to_smc)(struct pp_hwmgr  *hwmgr, uint16_t msg);
 int (*send_msg_to_smc_with_parameter)(struct pp_hwmgr  *hwmgr,
   uint16_t msg, uint32_t parameter);
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smumgr.h 
b/drivers/gpu/drm/amd/powerplay/inc/smumgr.h
index 89dfbf53c7e6..82550a8a3a3f 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/smumgr.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/smumgr.h
@@ -80,7 +80,7 @@ enum SMU10_TABLE_ID {
 SMU10_CLOCKTABLE,
 };

-extern int smum_get_argument(struct pp_hwmgr *hwmgr);
+extern uint32_t smum_get_argument(struct pp_hwmgr *hwmgr);

 extern int smum_download_powerplay_table(struct pp_hwmgr *hwmgr, void **table);

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c
index 0a563f6fe9ea..bb07d43f3874 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c
@@ -68,7 +68,7 @@ static int smu10_send_msg_to_smc_without_waiting(struct 
pp_hwmgr *hwmgr,
 return 0;
 }

-static int smu10_read_arg_from_smc(struct pp_hwmgr *hwmgr)
+static uint32_t smu10_read_arg_from_smc(struct pp_hwmgr *hwmgr)
 {
 struct amdgpu_device *adev = hwmgr->adev;

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
index c861d3023474..f7e3bc22bb93 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
@@ -52,10 +52,10 @@ static const enum smu8_scratch_entry firmware_list[] = {
 SMU8_SCRATCH_ENTRY_UCODE_ID_RLC_G,
 };

-static int smu8_get_argument(struct pp_hwmgr *hwmgr)
+static uint32_t smu8_get_argument(struct pp_hwmgr *hwmgr)
 {
 if (hwmgr == NULL || hwmgr->device == NULL)
-   return -EINVAL;
+   return 0;

 return cgs_read_register(hwmgr->device,
 mmSMU_MP1_SRBM2P_ARG_0);
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu9_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smu9_smumgr.c
index aad8f077f33c..079fc8e8f709 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smu9_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu9_smumgr.c
@@ -142,7 +142,7 @@ int smu9_send_msg_to_smc_with_parameter(struct pp_hwmgr 
*hwmgr,
 return 0;
 }

-int smu9_get_argument(struct pp_hwmgr *hwmgr)
+uint32_t smu9_get_argument(struct pp_hwmgr *hwmgr)
 {
 struct amdgpu_device *adev = hwmgr->adev;

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu9_smumgr.h 
b/drivers/gpu/drm/amd/powerplay/smumgr/smu9_smumgr.h
index a8da2815bd89..1462279ca128 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smu9_smumgr.h
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu9_smumgr.h
@@ -27,6 +27,6 @@ bool smu9_is_smc_ram_running(struct pp_hwmgr *hwmgr);
 int smu9_send_msg_to_smc(struct pp_hwmgr *hwmgr, uint16_t msg);
 int smu9_send_msg_to_smc_with_parameter(struct pp_hwmgr *hwmgr,
 uint16_t msg, uint32_t parameter);
-int smu9_get_argument(struct pp_hwmgr *hwmgr);
+uint32_t smu9_get_argument(struct pp_hwmgr *hwmgr);

 #endif
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
index c9837935f0f5..99d5e4f98f49 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
+++ 

Re: [PATCH 2/2] drm/amd/display: make function tables const

[Zhu, Rex]

Hi Christian,


As I am ooo on vocation, Can display team help to check this issue or just 
revert the patch?


I verified on Polaris11 and Vega10. From pp side, this is no difference between 
tonga and polaris10.


Best Regards

Rex




From: Christian König 
Sent: Saturday, July 7, 2018 8:30 PM
To: Zhu, Rex; Wentland, Harry; amd-gfx@lists.freedesktop.org; Michel Dänzer
Cc: Lipski, Mikita
Subject: Re: [PATCH 2/2] drm/amd/display: make function tables const

That's a completely different issue. I'm running into it with just a Tonga in 
my system.

According to my bisecting the problematic patch seems to be:
commit 3fdadbfe1edf4168b2515083af5651c95aeb299d (refs/bisect/bad)
Author: Rex Zhu <mailto:rex@amd.com>
Date:   Thu Jul 5 19:22:50 2018 +0800

drm/amd/pp: Implement get_performance_level for legacy dgpu

display can get clock info through this function.
implement this function for vega10 and old asics.
from vega12, there is no power state management,
so need to add new interface to notify display
the clock info

Reviewed-by: Alex Deucher 
<mailto:alexander.deuc...@amd.com>
Signed-off-by: Rex Zhu <mailto:rex@amd.com>

Please fix and/or revert immediately, cause that is quite a show stopper for my 
testing.

Thanks,
Christian.

Am 07.07.2018 um 03:51 schrieb Zhu, Rex:

Add Michel,


seems Michel found a similar issue. Please see the kern.log.


Best Regards

Rex



From: amd-gfx 
<mailto:amd-gfx-boun...@lists.freedesktop.org>
 on behalf of Harry Wentland 
<mailto:harry.wentl...@amd.com>
Sent: Friday, July 6, 2018 9:32 PM
To: Christian König; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Cc: Lipski, Mikita
Subject: Re: [PATCH 2/2] drm/amd/display: make function tables const

On 2018-07-06 08:22 AM, Christian König wrote:
> It is good practice to make global function tables const to avoid
> accidental override.
>
> Signed-off-by: Christian König 
> <mailto:christian.koe...@amd.com>

Well, this is embarassing. Can't believe I didn't spot this.

Series is
Reviewed-by: Harry Wentland 
<mailto:harry.wentl...@amd.com>

Now I wonder where else we might have this issue. Time to review all of our 
other function pointers.

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c | 6 +++---
>  drivers/gpu/drm/amd/display/dc/dce110/dce110_mem_input_v.c | 2 +-
>  drivers/gpu/drm/amd/display/dc/inc/hw/mem_input.h  | 2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c 
> b/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
> index bae752332a9f..85686d917636 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
> @@ -729,7 +729,7 @@ static bool dce_mi_program_surface_flip_and_addr(
>return true;
>  }
>
> -static struct mem_input_funcs dce_mi_funcs = {
> +static const struct mem_input_funcs dce_mi_funcs = {
>.mem_input_program_display_marks = dce_mi_program_display_marks,
>.allocate_mem_input = dce_mi_allocate_dmif,
>.free_mem_input = dce_mi_free_dmif,
> @@ -741,7 +741,7 @@ static struct mem_input_funcs dce_mi_funcs = {
>.mem_input_is_flip_pending = dce_mi_is_flip_pending
>  };
>
> -static struct mem_input_funcs dce112_mi_funcs = {
> +static const struct mem_input_funcs dce112_mi_funcs = {
>.mem_input_program_display_marks = dce112_mi_program_display_marks,
>.allocate_mem_input = dce_mi_allocate_dmif,
>.free_mem_input = dce_mi_free_dmif,
> @@ -753,7 +753,7 @@ static struct mem_input_funcs dce112_mi_funcs = {
>.mem_input_is_flip_pending = dce_mi_is_flip_pending
>  };
>
> -static struct mem_input_funcs dce120_mi_funcs = {
> +static const struct mem_input_funcs dce120_mi_funcs = {
>.mem_input_program_display_marks = dce120_mi_program_display_marks,
>.allocate_mem_input = dce_mi_allocate_dmif,
>.free_mem_input = dce_mi_free_dmif,
> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_mem_input_v.c 
> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_mem_input_v.c
> index 0564c8e31252..9b9fc3d96c07 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_mem_input_v.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_mem_input_v.c
> @@ -1011,7 +1011,7 @@ void dce110_free_mem_input_v(
>  {
>  }
>
> -static struct mem_input_funcs dce110_mem_input_v_funcs = {
> +static const struct mem_input_funcs dce110_mem_input_v_funcs = {
>.mem_input_program_display_marks =
>dce_mem_input_v_program_display_marks,
>.mem_input_program_chroma_display_marks =
> diff --git a/drivers/gpu/drm/amd/d